分类： IT业界
2013-01-17 13:48:39
我公司的业务特点：
我们的产品是为用户提供一套定制的系统，由众多的设备构成，其中核心的包括我们自产设备以及一些外围的外购设备，一个项目的（具体来说就是一个合同）的流程是这样的：a、由市场部门与用户签订合同及技术协议（此部分设计部门也会介入），b、由计划部门对合同进行分解，确定设计工期、生产工期、安装工期等；c、根据与用户签订的技术协议和合同由设计部门负责完成系统设计及材料申报；d、由采购部门和生产部门完成制造与采购工作，并发货；e、工程部门负责现场的安装、调试、验收；f、完成后的项目移交售后部门，售后部门对现场应用情况的跟踪涉及产品的整个寿命期；
应该说流程是清晰的，但公司发展到现在，每年的项目多达200多个，部门也增多到20多个，一个项目涉及到市场、计划、研发、设计、采购、制造、物流、工程、事业部、售后等众多部门，在项目的各个阶段产生大量的信息，OA在项目的审批过程中固化了流程，但对过程信息的传递、跟踪提示、汇总等功能非常的弱，很多问题都出现在项目过程中产生信息的偏差上。
从上面的意义讲，我觉得目前的OA更多的关注了审批流程，而没有项目管理的思想。
我理想中的OA：
1、具有目前的无纸化办公功能，网上审批，流程固化；
2、整个系统的框架以项目为对象，所有的审批都发生在项目过程中（具体的说就是项目的管理界面上，而不是独立的一个个流程），从项目的开始签订，一个子系统的OA就开始运行，随着项目进展涵盖所有过程，也就是以过程为主线，以信息为主要对象，实现项目管理中的申报、审批、反馈、监督等。让后一个节点的介入人员都能看到前面发生的内容（可以赋予权限），把握整个项目的信息，信息的流转不再依靠提交一个个OA，而是已经放在那，供需要的人查看；
3、对于OA来讲，一个OA的结束会随着所有人有的处理完成而结束，但很多情况下事情并未完结，但因为流程结束了，对于执行层面讲，很难再进行后续开展，比如一个改动工作，在所有人同意改动后，这个任务结束了，但涉及改动的具体实施过程，还得重新发起OA ，对于复杂的任务，会发起5～10个OA，（除非允许一个OA长期挂在你的界面上，那就真的乱如麻了），但后续的OA并不能直观的展现前面的工作。面向项目的OA则很容易的做到对前述工作的了解，并能利于领导对于前述工作执行情况的了解，因为真正的效果都是体现在后一个动作中的。在这种环境下，必然会促进前述工作执行者的执行力度，而不像传统OA那样，完成了就完成了，除非查询或跟踪，否则看不到具体执行的质量。而面向项目管理的OA因为具有连贯性。这种连贯性加强了对前一工作内容的了解，加强了对前一工作完成质量的了解。
4、因为面向项目的全过程管理，就有基础完成基于项目的绩效考核体系，这是更高层次的一个要求。
更多关于的资料：