2005年，暮春，我有幸到一家国内比较著名的第三方物流企业工作，所在部门是软件部。虽然说是软件部，但是部门很小——一个小房子里面有七个办公位置，加上我，竟然还有四个位置是空的。
不过诸君请不要误以为这个公司不重视IT，除了软件部外，其他好几个部门都有从事IT的人员，总共有五十多人！然而这也为后来OA选型的项目失败埋下了伏笔。为什么呢？因为部门重叠，多头分割，难以形成合理的规划和布局；甚至部门之间还会相
互挖墙拆脚，一度场面混乱不堪。
选型开始 由糊涂到明白
OA的选型工作最初由和我同时进公司的那位同事负责，可惜他实在性格太内向了，不善和人交流，毫无工作方法和章程。我们经理没有办法，于是将选型的任务交给了我。
头一次做甲方，感觉确实是很好。但开始的时候，我也没有具体的想法和步骤，只是通过网络搜索做OA的软件供应商，然后打电话给他们的销售和售前来和我们讲。但可惜我们自己都不明白自己的需求，只能记下他们的所讲的功能要点和他们的产品白皮书，无法额外提出太多的问题和自己的意见。
这时我意识到事情这样下去不是个办法，便毫不犹豫地和我的经理建议：暂停寻找OA厂商，先调研我们的需求。经理也明白其中的难处，因为最初一周基本上都是由他是和我一起听软件商的演示。所以很自然地同意了，需求调研也自然而然落到我的肩上。
我拿着先前几家公司的产品白皮书进行了研读，结合我自己在日常办公时的需要和以前用过的OA系统，提炼出了比较详细的调研提纲，用邮件群发给了公司驻全国各地的同事。虽然有点大海捞针的感觉，但是发送的一千多封邮件中，还是有几十个同事回了邮件，并且有热心的同事还列出了自己特别关心的需求。
我把同事反馈回来的邮件都一一研读，并把他们的需求进行了整理和总结，经过一周的调研和总结，终于整理出了一百多条的OA软件需求，由开始的“菜鸟”变成了精通OA功能需求的“大虾”。这些需求基本上覆盖了公司办公各个方面（具体可参见：http://cio.it168.com/t/2007-04-11/200704110940437.shtml）。
仓中有粮了，心里自然不慌。有了这些需求，再和软件供应商谈的时候，就不会被他们牵着鼻子走了，也不怕被他们花花哨哨的各种技术展现弄花了眼。反而在他们的售前来演示的时候，我只需要对着这些需求前后核对一下，打上分，看看满足程度如何，是否易用，以及看看软件商介绍的公司软件的卖点即可。于是我放心大胆地前后叫了十几家OA软件供应商来演讲软件，当然其中还包括各种关系进来的商家。
在明确的需求下，功能的高低毕现。这些进来演示的公司中，有的是给自己企业开发的内部系统，然后包装出来，转身就卖，一看就知道功能呆板；而有些是给政府开发的系统，在界面上做足了工夫，但是看过界面后就知道里面是糊弄人的；有几家确实是商业系统，无论是工作流自定义，以及表单的定义都很灵活和方便，文档的管理也都完善，甚至可以扩充另作他用。
