专家评估OA办公系统高失败率四大因素.doc

专家评估：OA办公系统高失败率四大因素自从IBM把群件的概念引入中国，OA软件行业（又名OA、OA系统、OA办公系统、协同软件），先后经历了协同软件理念的洗礼、经历了九思软件（）、东软股份、浪潮软件等专业厂商的推广普及，成百上千的OA系统公司迄今交付的OA系统已经超过20万套，然而不幸的是，很多OA系统，变成了客户发发通知公告和电子邮件的昂贵摆设！高达70%的综合失败率，让客户在OA系统的建设中深受其害，信息主管也因此走马灯似的更换，很多目光短浅的厂商不是下功夫研究如何引导和帮助客户成功，而是潜心专研既得利益、上市圈钱、市场占有率等与客户无关的指标，这进一步加剧了OA办公系统的失败概率，本文作者在OA软件行业从业数年，目睹很多事实和媒体报道，痛定思痛，总结若干导致高失败率的内幕，希望对客户成功组织信息化建设有所裨益，对行业自律和有序发展有所警示。因素一：占地盘，错误的经营理念让很多OA公司抛弃了百年企业的基因 也许是OA公司都太年轻，也许是中国企业普遍不成熟，也许是OA市场发展速度太快，大家都赶着上市，也许，总之，很多OA公司急于抢占地盘，急于圈地，急于在上市前做好包装的需要，很多OA公司在经营策略以占有市场为主要考核指标，对应的宣传攻势往往是“市场占有率第一”、“规模最大”、“员工人数最多”等等。殊不知，百年企业追求的并不是空间的广大，而是时间的长久，也就是百年企业追求的是与客户取得持续的共赢，因此OA系统建设的成功率，品牌的美誉度，才是百年企业的基因。伴随着十二五规划的出台，国家工信部和相关协会部门，也实时的在引导中国企业向更成熟的经营心态上转换，如“2011经济和信息化年会上”，中国软件行业协会、经济和信息化理事会等，联合颁发给九思软件（官网：）“中国管理软件项目成功率第一品牌”，其意图就是树立榜样，引导正确的企业经营理念，改变中国民营企业10年短命的现状。 因素二：技术落伍，不能与时俱进是OA系统失败率的重要成因 从长远来看，随着OA系统的深入应用，用户数和信息量会大幅攀升，安全级别要求也越来越高，组织管理架构也越来越复杂，因此可能涉及到支撑环境的变化，比方说服务器负载均衡、操作系统从windows切换到linux、数据库从mysql迁移到oracle等等，此时，如果CIO在选型时错误的选择了.NET、PHP、Domino等落后的技术路线，那么OA系统的生命力就会到此为止，不得不重构。 总体来看，JAVA已经成为高端产品的不二选择，从调研来看，九思软件（）、中软股份等高端厂商，选择的都是JAVA路线，很多10年前的超大型客户都已经纷纷放弃了Domino，而.NET只有贪图价廉的中小民营企业还在尝试，而PHP已经成为残羹冷炙、无人问津。 当然长期规划，除了在技术路线上要重视，还要重视系统在集成方面的开源性、集成机制，重视OA系统本身的功能扩展是否可以免代码搭建等。因素三：需求失控，是导致OA系统建设失败的导火索绝大多数的协同OA系统的需求，都是发问卷给各部门采集需求，然后再把各家厂商的产品功能堆积而得来的，以这种简单的做加法的形式采集需求，导致了OA系统的建设无法走标准化的成功路线！ 要知道，组织的战略、结构、职能、流程、表单、权限 ，时刻都处于变化中，如同人不能踏入同一条河流一样，再多次的需求会议，也无法将需求定格、无法将需求穷尽，伴随着系统的深入应用，变化来临时，将无所适从。 协同OA系统作为一种基础管理工具，它既是科学的载体，也是艺术的结晶。其应用价值的核心体现，不是在杂七杂八的各种个性化小需求上，而是体现在灵活易变但却混乱中体现秩序的工作流程管理上，也就是说如果工作流程管理模块用的好，那么项目基本就实现了80%的成功；而其他80%的功能用的再好，最终给企业带来的价值不会超过20%。因此放弃那些个性化的、低频率的功能需求，重点考察“工作流引擎”的状况，成为系统成功的关键功能点。 另外值得提醒的是，每个功能点的开发，不只是涉及到编码成本，还将涉及到培训、推广、管理、维护和升级，所有个性化的部分都可能破坏掉系统的整体性、扩展性和可升级性。最后，企业CIO要提醒各部门放下本位主义先找到组织内的共性需求，然后才是关键部门的需求，最后才是重要角色的需求。我们先后研究了协同OA系统的领导厂商，如九思软件（）、中软股份等，仔细评估了他们在工作流技术和协同工作方面技术突破，发现纯B/S图形化流程编辑器，已经可以帮助客户在关键需求的实现上提供帮助。因素四：实施方法陈旧，让OA系统停留在业务管理的外围并最终成为摆设实施被不少CIO理解为软件开放、安装调试、培训、测试、上线这一类的事务，但我们认为这不是实施，至少实施的目标错了，不是结束一个软件的部署过程，而是将软件工具深入到业务管理中去为目的。OA系统的实施方法论，在最近10年，经历过了技术导向、实施导向和应用部门导向三代变迁。其中以技术导向的实施模型是，厂商依据需求，定制开发，这种模式因无法实时响应需求的变化和高成本，导致的结果是项目验收之日，就是项目老化之时；以实施导向的实施模型是，信息中心牵头组织需求调研和实现，这种模式因信息中心无法精准理解应用部门的需求和管理的部门壁垒现象，导致的结果是项目验收之日，就是部门矛盾和摩擦，项目纠结之时；以应用为导向的实施模型是，应用部门牵头组织需求、调研、系统实现和优化，厂商和信息中心负责进行方法咨询、技术指导、系统性能维护和安全保障，这种模式下，因可以精准定位业务需求、实时响应变化，并且规避了管理中的部门壁垒现象，因此项目验收之日，是管理水平全面提升之始。综合来看，应用导向将是回归管理软件的价值本质：为