您的位置: 笔者从保障项目成功的角度归纳出9个问题。这9个问题涉及对OA的初步认知，也涉及对本质的探讨，希望与业界同仁共勉。
2. OA的粘着度
另一项挑战是OA的粘着度,即用户对系统的依赖程度。大部分OA系统都不具备粘着度，要知道无论需求有多周全，都是穷举模式的，而组织行为是无法穷举的，即使一一满足那些穷举的需求，你可能发现仍然有80%的事情无法在OA上处理。过去OA失败的原因就是只做关键性应用，如我们熟知的公文、文档管理、办公室常用的功能等，就算有流程化审批，也只能穷举部分组织级审批，到部门级就太多了，干脆就不做了。他们草率地把80%的无法穷举的应用需求的责任推给了邮件!套用那句“名言”的语法: “如果道歉有用，还需要警察做什么?”如果邮件能解决还要OA干什么?”
OA还有很多挑战，诸如实施风险之类，但最大的挑战还是在产品本身，即易用性和实用性，而大部分人可能对易用性容易理解，但对实用性却没有深入认识，我们通过大量调研，才认识到第二个问题，那是传统OA失败的根本原因之一。
第四问：OA项目成功的要素有哪些?
OA的选型实施范围大、涉及面广，如果想让OA项目成为持续支撑组织发展的基础IT平台，CIO们必须以战略眼光来思考，不能把OA作为急就章项目来看待，在笔者看来成功的要素至少有三点。
1.正确地选择产品或者项目方案。
你必须选择一个可以满足当前需求的产品或项目，否则以后的结果就很难预料，但以自己的需求为导向的选择真的就能成功吗?为什么那么多能够理清自己需求的项目仍然不成功?这是因为没有搞清楚产品和项目对自己的意义。
2.阶段清晰的渐进式实施
常见的对实施的认识大多局限于软件安装、公文流程定义、表单设计等等，大部分都缺乏对实施的整体认识，笔者所在的用友致远在长期的客户实践中，总结了实施三段论(共性应用的二八原则、局部深化、集成应用)，因为涉及到很多方面，限于篇幅，笔者在后面的“如何实施阶段规划”中讨论。
3.持续服务和持续升级
持续升级的好处不说了，说说持续服务。持续的服务也许是供应商的一种良好愿望，但也许只是为了收款时拍胸口的豪言壮语，你必须清楚，一切可持续的事物都不是靠愿望，而是某种内在的东西在支撑。
这部分内容比较简单，但却是影响项目成败的最主要的价值观和方法论的基础，CIO们对此问题的充分认识和正确决策是保障项目成功的关键中的关键。因此下一问中我们先不对上面三个分支问题做出深入的阐述，我们从另一个角度，即那些曾经失败的CIO为何踏入了所谓OA的“CIO陷阱”来了解更多的细节。
第五问：CIO陷阱有哪些?
CIO通常是OA项目的负责人，中国的OA应用发展史可谓“成也CIO败也CIO”，在组织赋予CIO肩负起OA项目建设职责的同时，不少CIO却也还满怀激情地冲向陷阱。
陷阱一：缺乏长期规划
CIO一般有当前的项目规划，而无长期战略规划，为项目的早夭埋下了伏笔。(详情参见第7问: 如何制订实施阶段规划)
陷阱二：需求贪大求全
如果你坚信自己采集的需求是一种客观的需求，是必须被100%满足的需求，你就离失败不远了。那么，如何认识自己的需求?
绝大多数的OA需求都是发问卷给相关人采集汇总而得来的，以这样的形式采集汇总的需求造就了中国过去近20年几乎所有的OA都走项目化，或者看着别人的OA还凑合拿来就用。如果你也是这样整理需求的，那简直就是自杀，这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。
让我们仔细看看这份需求吧!也许每个部门都提出了自己的需求，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包含着个别领导的软件嗜好。依照这种需求，世上没有一套现成的软件能够100%地满足。依据这样的需求开发出来的OA软件，可能功能看上去非常丰富，但实际上却形成了一个个以部门为中心的应用孤岛。第一代的OA都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭?问题到底出在哪?
我们研究发现，这类OA普遍存在一个问题:如果我们要以整个组织高效协同为目标，那么,那个把我们协同在一起的功能是哪个?
请不要轻率地回答这个问题，有人说用公文?公文只有组织中不到10%经常用;文档?文档可以分享，但文档不能主动产生协同;IM(即时通信)?IM并不能进行表单审批;邮件?邮件能完成流程化审批吗?能用邮件来完成组织的日常协同,我们还实施OA项目干什么?
所以你必须从繁杂浩瀚的细节中脱出身来，放下本位主义，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。我们先后研究了中国数十家OA厂商，走访了数十家OA成功或失败的客户，仔细评估了超过200种常见OA的功能菜单，最后找到了那个共性的需求，这就是协同。你在选型的时候一定要看，这个OA是否有这样的一个功能能够满足这个共性需求!
陷阱三：实施急功近利
如果你认为软件只要会编程就能做，那你可就大错特错了!写程序是邻居家的高中男孩就能干的事情。
软件是包含责任关系的商品，需要复杂的支撑体系。软件业已经发展到工程学的水平，拥有严格的环节分工和检验标准。从需求开始，有专业的人员进行需求的采集、提炼、评估，形成应用的“概念设计”;经过评审后，技术高手会充分考虑诸多因素后提出“构架设计”，评审后才会到开发部形成“应用设计”，评审后才会有“代码开发”，然后是“功能测试”，最后才能交给你。这期间，所有的环节都应该是最优秀的人力资源在保障质量，所以你千万不要指望找到一个非常廉价还百依百顺的供应商，根据你的指令快速而完美地帮你达成目标。
