OA失败例子多于成功 最大的风险在企业本身

申请免费试用、咨询电话：400-8352-114

现实中OA失败的例子远远多于成功的例子。

   当你面对领导的信任和同事的期望，承担起建设一个涉及全局的IT应用系统的责任的时候，难免心潮澎湃，涌起建功立业的雄心壮志，希望无论于公于私都将此项目作成职业生涯中的一个里程碑。在这种心态的影响下，你可能不知不觉地滑入了一个新的误区。

   失败案例：当全部需求都被供应商满足了之后，雄心勃勃的项目负责人在上线的头三个月内，被各种细节需求的满足性问题拽得到处团团跑，拼命催促项目开发商供应补丁修正程序，然而，这种未经仔细设计、严格测试的“急就章”式的补丁却带来了更多的bug，熬了多个通宵之后，项目负责人惭愧地向单位领导承认，我们无法在预定的时间上线了，问题多到了各个部门都不满意的程度，原因不能简单地责怪供应商，因为我们在提出需求的时候并没有精确的细节，供应商也是根据口头的沟通达成了对需求的认知，并开发了程序，交付之后才发现，双方还是有太多的细节的细节没有沟通到。

贪大求全：

在“认识需求”一文中我们提到了“汇总式”需求对OA项目建设的副作用，缺乏共性需求的抽象提炼，主次部分，轻重不分，缓急不分，这必将导致前期实施目标点过多，局部各自兴奋，全局一盘散沙的局面，事实上你将成为需求平均主义泛滥的牺牲品，丧失把控实施进度的节奏的能力。

急功近利

如果你认为软件只要会编程就能作，那你可就大错特错了！隔壁邻居家的高中男孩就能干的事情是写程序，属于个人娱乐，和摄影爱好差不多。而软件是包含责任关系的商品，需要复杂的支撑体系。软件业已经发展到工程学的水平，拥有严格的环节分工和检验标准。从需求开始，有专业的人员进行需求的采集、提炼、评估，形成应用的“概念设计”，经过评审后，技术高手会充分考虑诸多因素后提出“构架设计”，评审后才会到开发部形成 “应用设计”，评审后才会有“代码开发”，然后是“功能测试”(诸如白盒测试、黑盒测试、性能测试、压力测试、环境测试、安装测试等)，然后才能交给你。这期间，所有的环节都应该是最优质的人力资源在保障质量，所以你千万不要指望找到一个非常廉价还百依百顺的供应商，根据你的指令快速而完美地帮你达成目标。

片面求新：

   对新技术的片面性追求常常导致项目成为了项目负责人（特别是CIO）自娱自乐的畸形产物，即使探索的精神无可厚非，但是毕竟尝试性的技术探索对于组织应用所期望的稳定性、实用性无疑是高风险和高成本的。不少项目负责人会认为“最新的技术”＝“最先进的技术”。这种认知是非常片面的。

   在我们看来，所谓技术先进性的价值不在于先进本身，而在于先进对扩展性、性能、安全性、集成性、易用性（常被CIO所忽视其实对终端客户的影响排在第一位）等诸多应用的现实价值和升级成本的抑制。所以理性的你，应该认真地去了解具体什么新技术，用在什么地方，并且了解这些新技术为你关注的各种特性带来了什么价值。

所以说，最大的风险在于你自己。