10.3把好“质”“量”关

　　二次开发必不可少，但也不是越多越好，正如“茅台虽好亦不可贪杯”；在IT项目实施中，CIO一定要把握好二次开发的过程和开发量，从不同实施阶段、开发难度、对改进流程的帮助程度等方面综合考虑二次开发的必要性。总的来说，以下几项值得CIO注意。

　　首先，要把握好二次开发的“量”。二次开发是在软件功能模拟运行的基础上进行的，工作量一般比较大，需要一定开发时间，可能会延误项目实施进程；另一方面，将来还可能影响到软件版本升级。有些软件供应商提供免费或收费很低的系统升级；如果不升级，新版本的长处无法应用；如果升级，则面临着重新进行二次开发的可能。因为软件供应商在进行新版本开发时，根本不会考虑某个特定用户在旧版本上所作的二次开发。一般说来，成熟的商业软件能满足企业95%左右的业务需求，只有5%左右的业务需求需要二次开发来实现；因此二次开发的量也一般在5%左右。其次，要增加或修改软件功能，需要软件供应商提供支持二次开发的工具，还可能需要系统源程序，但并不是每个软件供应商都愿意提供源代码。此类问题一定要在签订合同前考虑周全。另外，正在实施的信息系统与已建信息系统间的接口，一定要由企业自己去开发，尽量不要委托给软件供应商去开发，因为原有信息系统的源代码只有企业自己知道。再次，二次开发要只改格式，不改数据定义。当需要增改字段时，尽量使用系统中已有的备用字段，灵活使用系统的备用字段，以不动数据库为基本原则。

十一、IT隐归“幕后”
【IT168 专稿】瞬息万变的市场，不断调整的政策，经常弄得IT部门苦笑不得。软件刚开发完甚至还没开发完，市场又变了或者政策又调整了，只得从头再来；不仅延长了项目工期，还造成了人力物力的极大浪费，有的单位甚至掉进了“IT黑洞”。软件开发速度如何跟上政策调整速度、市场变化速度？能否以“不变”的信息系统应对“万变”的市场与政策？

11.1管理思想是“万变之源”

　　如果软件开发从CIO给业务部门导入先进管理思想开始，然后用先进的管理思想梳理业务流程，再根据现实需要设定操作者的职责和权限等，开发出的软件就绝对不会仅仅满足于当前需要。

　　软件开发通常从需求分析入手，先找业务部门谈需求，然后IT人员写CODE；但常常CODE刚写完甚至还没写完，业务部门的需求已经变了，IT人员只好从头再来。软件开发速度跟不上市场变化速度，跟不上政策调整速度，着实让不少CIO苦恼不已。除了瘟疫和洪水，历史上还没有什么东西的流行速度比得上计算机和网络，为什么软件开发反而跟不上市场变化、政策调整？

　　从社会发展角度说，目前中国社会还处于从计划经济向市场经济转轨的大背景下，各种政策、法规还在不断完善、调整中，不仅政府机构职能在不断调整，即使政府机构本身也在不断调整、撤并中；另一方面，多数企业正处在快速发展阶段，不仅企业规模在快速膨胀，组织结构、业务板块也在快速调整，对不少企业来说，惟一不变的就是“快速变化”。由于市场、政策在不断变化，而开发IT系统又需要一定周期；如果软件开发仅仅满足于当前业务需求，软件开发速度跟不上市场变化速度、政策调整速度也就不足为奇。但快速变化的只是具体业务，不论企业还是政府，管理思想总是相对稳定的，变动不居的业务体现的是相同的管理思想。不论政府还是企业，如果连管理思想也一日三变，那必将天下大乱。

　　此外，管理软件本身体现的也正是一种管理思想。最早的IT技术纯粹用于计算；PC出现后，无非是把字变成字节来计算；但MRPⅡ出现后，应用信息系统的就不再是一个人，系统运行的逻辑也不再是简单的串行逻辑，而是首先体现为一种管理思想，而管理思想又落实为业务流程、数据规范、操作者的职责和权限等。如果软件开发从CIO给业务部门导入先进管理思想开始，然后用先进的管理思想梳理业务流程，再根据现实需要设定操作者的职责和权限等，开发出的软件就绝对不会仅仅满足于当前需要；在未来的运行过程中，如果由于市场变化、政策调整等而修改业务流程，也只是对个别参数进行调整，并不需要“推翻重来”。

　　“人无远虑，必有近忧。”国家外汇管理局信息中心主任冯菊平说：“作为一个IT管理者，一定要考虑政策前瞻性。政府职能在不断调整，国家外汇管理局的很多监管政策只是业务部门根据一段时间内监管的责任、要求等制定的；而信息系统是长期的，如果仅满足于当前阶段性政策的要求，将冒极大失败的风险。”IT管理者要用尽量长远的眼光处理当前业务需求，技术人员也只有掌握业务发展的方向和改革思路，才能比较周全地考虑具体工作；立足长远考虑当前，系统才能推进得比较快。冯菊平要求信息中心的IT人员在业务部门制定监管政策时就介入进去，不仅熟悉业务部门当前需求，还要通过与业务人员不断沟通，熟悉今后改革的思路，然后再把改革的思路落实为业务流程和数据规范。

　　而联想集团CIO王晓岩则从给业务部门导入先进管理思想开始。起初，联想在推进信息化时，也是一开始就要求业务部门谈需求；但王晓岩发现业务部门谈的往往不是业务流程，而是一些老的作法和期望改进的思路，如果强行要求业务部门说清楚信息系统所包含的管理思想，他们往往把“皮球”踢给咨询顾问，希望咨询顾问帮助说清楚，而实际上又不得不自己说。于是，王晓岩转变了信息化建设思路，从转变观念入手，先导入先进管理思想，然后协助业务部门用先进管理思想梳理业务流程。现在，联想在上大型信息系统前，王晓岩会先把信息系统的功能用管理的语言、业务的语言“翻译”给业务部门，让业务部门认同信息系统所包含的管理思想，然后再讲系统的功能等，最后项目组才与业务部门一起梳理现有业务流程，确定需求分析等。

11.2干水泥和湿水泥的故事

　　在传统管理模式下业务流程就像干水泥，业务人员可以根据需要随时塑造成任何想要的形式；但业务流程一旦用软件固化下来，“干水泥”就变成“凝固了的湿水泥”，原来轻松完成的流程调整变得十分艰难，因为业务部门要想改变流程，必须求助IT人员，甚至求助软件供应商。

　　用相对稳定的管理思想梳理业务流程后开发出的信息系统，躲过了“人生苦短”的“劫难”；但在规范业务流程的同时，也“固化”了业务流程。对业务人员来说，信息系统成了“凝固了的湿水泥”。市场瞬息万变，业务部门需要根据市场变化及时调整业务流程；在传统管理模式下业务流程就像干水泥，业务人员可以根据需要随时塑造成任何想要的形式；但业务流程一旦用软件固化下来，“干水泥”就变成“凝固了的湿水泥”，原来轻松完成的流程调整变得十分艰难，因为业务部门要想改变流程，必须求助IT人员，甚至求助软件供应商，软件“剥夺”了业务人员调整业务流程的“权利”。而且人总有一种惰性，对于一些可干可不干的事情，如果举手投足就能解决的，可能会主动去解决；如果需要求助别人，则可能会选择“偷懒”。长此以往，不仅会影响企业对市场的反应速度，而且会影响业务部门信息化的积极性。如何把业务流程调整的权利“归还”业务部门？

　　任何信息系统上线后，要持久“生存”下去，都需要根据业务发展需要，不断修改完善；但修改的主要是流程，支持流程的数据源则相对稳定，如海关、税务、外汇管理等部门的监管对象是相对稳定的，政策调整仅仅是对不同监管个体的某个监管要素进行调整。从技术角度看，业务流程调整仅仅是数据源的不同排列组合而已。于是，业界逐渐出现了数据库和业务流程分离的趋势。

　　国家外汇管理局信息中心主任冯菊平从建立各业务部门共享的数据库入手，变各个业务部门分别采集数据为信息中心统一采集数据，供各业务部门使用。信息中心建立共享数据库后，将来业务部门调整监管政策时，只要从信息中心的共享数据库内采集数据就可以了，根本不需要对软件系统的数据结构进行调整。

　　为了把流程修改权归还业务部门，多数单位则选择了平台技术。以OA系统为例。早期的OA系统主要是基于Lotus开发的，数据流非常严谨，有利于规范业务流程，但对硬件环境要求较高，而且维护费用较高；后来，有的单位就采用JAVA语言开发OA系统，虽然维护起来容易多了，但由于业务需求千变万化，经常系统刚开发完，政策又改了，市场又变了，相对固定的软件模块无法满足千变万化的业务需求；于是，又把业务流程从软件中分离出来，底层的数据流形成一个应用平台，然后在应用平台上搭建应用模块，以不变的应用平台应对万变的业务需求。换句话说，传统应用软件就像一株株盛开的鲜花，而运行在平台上的应用软件就像一朵朵盛开在大树上的鲜花，应用平台就是鲜花的根。软件供应商通常在应用平台上给用户提供了各种开发工具，在软件使用过程中业务人员可以根据业务需要自己“定置”业务流程，而不需要求助IT人员。但平台技术目前还方兴未艾，只在少数软件企业的少数软件中得到了应用，在ERP、CRM等大型企业管理软件中应用平台技术的还比较鲜见。

　　随着信息化建设地深入，IT将重新隐归“幕后”，担当起电工、摄像、舞美等角色，为在舞台上唱戏的业务部门提供各种技术支持。

第四节 项目管理的艺术

十二、处理好工程和过程的关系

【IT168 专稿】中国信息化有很多成功的工程如“金关工程”、“金税工程”等，还有很多“金”字工程正在浮现；但从根本上说信息化是个“过程”而不是“工程”，不可能“毕其功于一役”。有的企业一上来期望值很高，投巨资搞覆盖生产经营全过程无所不包的大系统，但一遇到挫折又产生畏难情绪，甚至半途而废。信息化“过程”如何才能一帆风顺？不论国家领导还是专家、学者，都一直在强调信息化要“总体规划，分步实施”，首先应制定一个总体规划，在软件选用、网络建设等方面充分考虑未来发展的需要，为今后的信息集成奠定技术基础；然后在总体规划基础，找准切入点，实现重点突破；概括起来就是“信息化是个过程，但切入点是个工程”。

　　在总体规划的基础上，CIO如何找准信息化切入点？先上哪些项目后上哪些些项目？遇到阻力后，如何强力推进信息化？

12.1抓住“矛盾” 急用先上
当客观需要到来时，或是急需解决长期困扰业务管理的难题，或是应对突发事件，比如SARS危机，解决业务上的燃眉之急时，一定要急用先上，不惜加班加点，不求技术上完美，只要能够做成，务必抓住战机拿出成果，增强大家对信息化的信心和决心。

　　信息化是个老大难，但“老大”来了就不再难。要让“老大”的眼睛看过来，CIO的眼睛要先看过去，抓住企业“主要矛盾”，用IT解决“一把手”当前最挠心的难题。随着时间地推移，任何单位的内外部环境总在不断变化，“主要矛盾”也“与时俱进”；但在特定时间内，“主要矛盾”一定是清晰、一致的，而且各部门要通力合作解决当前的“主要矛盾”，才能推动企业迅猛发展。此时，CEO站在全局的立场上综合考虑整个公司的资源和调配；如果CIO仍然只从IT部门出发，推动企业尽快、尽量多地采用信息技术，而较少地把信息技术与当前的“主要矛盾”相结合，可能就难以赢得CEO的支持；相反，如果能通过思路创新去解决CEO当前最挠心的难题，不仅CEO会全力支持信息化，业务部门也会全力配合IT项目地实施。

　　1997年，东南沿海地区走私、骗汇活动猖獗，国家外汇流失到了难以想象的严重程度；打击走私、骗汇活动，成为当时海关上下的头号难题。经过反复考察，海关总署党组成员、总工程师杨国勋发现犯罪分子造假实际上利用了各海关之间以及海关与外汇管理局、国税总局等部门间“不通气”的漏洞，只有电子底账联网才能真正消除造假机会，并提出了建立“电子海关”的想法。相关领导很快采纳了其建议，在海关内部建立跨部门、跨关区联网综合应用的信息化平台，建成了联结海关总署、全国各地直属海关和所有业务现场三级海关的虚拟专网，实现了通关业务现场各环节之间、业务现场与直属海关之间、海关与海关之间的联网。

　　信息系统建设的成功，除了思路创新外，还要善于抓住机遇。在客观需要到来时，或是急需解决长期困扰业务管理的难题，或是应对突发事件，比如SARS危机，解决业务上的燃眉之急时，就一定要急用先上，不惜加班加点，不求技术上完美，只要能够做成，务必抓住战机拿出成果，增强大家对信息化的信心和决心，克服或减少对信息系统建设过程中所带来的权力和利益结构变化的担心。另一方面，信息化本身就是为业务部门服务，如果业务部门有需求时，IT部门不积极配合，等IT部门想做时，可能黄花菜都凉了。

12.2 先网络化 后信息化
实际上，信息系统全部的生命力就在于效益。评什么奖并不是最重要的，只有产生实际效益的项目才能存在和发展；业务部门越容易看到效益，系统实施的难度就越小。

　　实际上，信息系统全部的生命力就在于效益。评什么奖并不是最重要的，只有产生实际效益的项目才能存在和发展；业务部门越容易看到效益，系统实施的难度就越小。当然，信息化效益也要一分为二地看待，有些项目现在看不到明显效益，不一定今后就没有效益，而且可能带来更大的效益。CIO如果要获得成功，就应该尽量多地抓住直接能看到效益的项目去做；这实际上是复杂系统实施的步骤和节奏的问题。

　　进一步说，对于应用和操作者来说，信息系统的运行成本，主要表现为数据录入的工作量，如果原先需要手工做书写、登记工作，则改为数据录入就容易行得通。而录入的数据以后使用的环节和人员越多，则效益和价值就越大。最差的情况是增加了一些人的工作负担，又没人需要、没人过问，系统的运行效益就为负。在立项决策时，对负效益的项目，就暂时不做。

　　按照效益优先的原则，发达国家走过的信息化发展道路，即一般先整合业务开发内部信息管理系统（MIS），再发展联网数据交换和信息共享的做法，在互联网技术大发展的今天，未必是最好的方法。国内企业完全可以利用后发优势，先网络化再内部信息化。因为联网进行数据交换实际上是解决快速、方便、可靠的相互联系机制，并不涉及内部的职责分工、机构配置，可以回避管理水平低下的问题。同时，联网后的综合治理能很快见效。而且，那些没有进行信息化的企业也可以利用国内外网络化多年来积累的开发和应用成果，立即取得综合治理、提高效率、降低成本等各项主要好处，实现后发优势。

　　海关总署在建设电子口岸时，电子海关虽然已初步完成，但其他不少单位还未建立完整的内部信息系统，然而由于海关利用互联网技术和我国电信公网的现在基础，第一个试点应用项目，即进口付汇报关单联网核查仅仅只用了三、四个月时间开发，就于1999年1月1日如期投入使用，并立即切断了假报关单骗汇之路，受到国家领导、企业各界的广泛好评。

12.3“避实击虚” 先破弱敌

　　在战场上，当敌我兵力悬殊时，优秀指战员惯用的战术是“避实击虚”，避开敌人优势兵力，集中自己优势力量狠狠打击小股敌人。当信息化建设遇到困难时，CIO也不妨采用“避实击虚”的战术。

　　从某种意义上说，信息化是一次权力和利益再分配，必然影响到个别人、个别部门的既得利益，尤其是“灰色收益”，必然会遇到各种阻力；“非暴力不合作运动”者有之，公然反对者也有之，“指桑骂槐”者也有之。有的人虽对信息化措施不满意，但由于人微言轻只好忍声吞气地服从；有的部门尤其是采购、企划、销售等关键部门若对信息化措施有异议，IT项目实施难度就会很大甚至夭折。此时，CIO不妨暂时避开关键业务部门，先从人数较少、位置不太重要的部门入手，等IT项目推进到一定程度、效果也逐渐显现时，再对关键部门“动刀”。

　　前几年，东北某客车厂要实行银行代发工资。本来是件“利厂利群”的好事，却遭到了中层领导的集体反对。原来，该客车厂对请假制度管理很严格，任何员工只要请事假每天扣50元、请病假每天扣30元，并从当月工资内扣除。于是，个别中层领导就在请假制度上动起了“手脚”。普通员工只要请假全部记录下来，但月底上报财务部门时所有员工全部全勤；等工资领到部门后，再按实际情况扣除。由银行代发工资后，员工请假所扣工资直接由财务部门扣除，部门领导再也无权过问。于是，中层领导极力反对由银行代发工资，并提出种种理由。信息中心主任钟先生，当时真有点儿一筹莫展，因为没有一个部门领导支持他。后来，钟主任采取了“避实击虚”的战术，先从爱卫会、绿委会等非业务部门做起，因为这些部门人数较少，阻力也相对较小；然后是设计部门、研发部门等人数相对较少的业务部门，半年后爱卫会等部门的员工已尝到了银行代发工资带来的便利，生产、销售等部门也就默认了银行代发工资制度。

“绕过碉堡，直攻山头”

　　不要一味追求完美，先把系统用起来；等业务部门尝到甜头后，会自动对原来的流程等进行改造；相反，如果事事追求完美，可能丢了西瓜拣个芝麻。

　　选定信息化切入点后，在具体推进过程中CIO可能还会遇到各种各样的障碍，延缓系统地应用。就像打仗，要把一次战役打赢，要攻下不少山头；前进路上可能会遇到碉堡，遇到碉堡就喊“同志们，冲啊！”等把碉堡打下来，再往前冲；遇到碉堡再打；打到最后，红旗插上主峰的时候，人也打得差不多了。如果这样搞信息化，肯定不行，因为财力和精力消耗不起，领导的决心和大家的耐心消耗不起，必须绕过障碍直攻目标。

　　宁波富达公司CIO杨文华在推进信息化的过程中，经常采用“绕过碉堡，直攻山头”的策略；遇到困难先绕过去，不论系统开发还是实施目标不求“一步到位”，等系统运行起来后再逐步改进。宁波富达公司下属的舜江水泥厂门口有个电子磅秤，拉水泥的汽车出去是实车，回来是空车，剩下的就是拉出去的水泥。如果磅秤稍微有点不准确，两三天下来，可能就有一车水泥在磅秤的误差中消失了。杨文华要对电子磅秤进行信息化改造，个别员工就极力反对，明确提出“0.5%的误差难以实现”；杨文华说：“0.5%做不到，没关系；先争取做到5%，到年底达到2.5%的误差，明年这个时间再达到0.5%。行不行？” 在做流程改造的时候也同样，不要一味追求完美，先把系统用起来；等业务部门尝到甜头后，会自动对原来的流程进行改造；相反，如果事事追求完美，不仅可能丢了西瓜拣个芝麻，还可能影响企业上下对信息化的信心。

　　当遇到“坚固碉堡”实在绕不过去时，就要“切中要害，精确制导打击”。抽油烟机是宁波富达子公司——玉立电器公司的重要业务之一，但经常有一些个性化需求的定单，如把原来按钮式开关换成电脑开关，或者原来开关放在左边，客户要求放在右边等。按道理，改变生产工艺，必须经过技术部门的认可，增加的成本由财务部门核算；但在传统管理模式的时候根本做不到，如果要转完这些流程，可能几天就过去了。通常收到这样的定单后，生产计划中心主任就凭经验来判断能不能做？如果能做，需要增加多少成本，这件事情就搞定，靠经验、靠一专多能的个别人。建立完善的计算机网络后，生产工艺的变更就可按照完整的流程去处理，该审批的审批，该核算的核算；这样，生产计划中心主任觉得权力没有了，有情绪。杨文华去找他：“像以前那样，出了问题的话，你一个人承担责任；现在好了，大家可以和你一起承担责任；这不是对你权利的侵害，而是与你共担风险。”生产中心主任想了想觉得也有道理，很快接受了杨文华的建议。

十三、需求分析10条法则

【IT168 专稿】历尽千辛万苦，终于签署合同，IT供应商拿到了用户提供的几页“需求书”；然后就凭借自己的理解立即投入开发，等生米熬成粥才发现满足不了用户需求，接下来就是艰难、反复地修改，最后开发人员厌倦了，用户也厌倦了，当然项目款也遥遥无期。这样的案例可谓比比皆是！

　　比起不成功的项目，一个成功的项目在开发者和客户之间往往采取了更多交流方式；IT供应商不仅与终端用户或潜在用户群交流，而且对用户感性、朴素的认识进行抽象，提取出潜在逻辑关系，准确把握客户的真正需求，然后才进行软件开发。作为项目开发者和最终用户之间的“桥梁”，CIO如何推进开发人员和终端用户的“对接”？如何从用户笼统、感性的描述中抽象出潜在逻辑关系？

13.1拨开需求“迷雾”

　　业务部门的主管甚至CIO经常试图代替终端用户说话，但通常又无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中；否则，产品很可能会因缺乏足够的信息而遗留不少隐患。

　　需求分析是软件开发和项目管理的基础，但业务部门经常三言五语就把开发人员“打发”了，业务人员笼统、感性的描述对开发人员来说就像“雾里看花”，一些开发人员只好按照自己的理解去写CODE。要拨开需求分析的“迷雾”，就要先了解需求分析的“程序”。

　　需求分析包括业务需求、用户需求、功能需求、非功能性需求和需求分析报告等。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明；用户需求描述了用户使用产品必须要完成的任务，应在使用实例或方案脚本中予以说明；功能需求定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足业务需求；非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制等；需求分析报告所说明的功能需求充分描述了软件系统所应具有的外部行为，在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

　　业务部门的主管通常阐明“业务需求”，即产品的高层次概念和主要业务内容，为后继工作建立指导性框架；但“业务需求”并不能为开发人员提供开发所需的许多细节说明。“用户需求”必须找系统的最终使用者，他们最清楚要使用该产品完成什么任务和一些非功能性的特性需求，如程序的易用性、健壮性和可靠性等，而这些特性将会使用户很好地接受具有该特点的软件产品。业务部门的主管甚至CIO经常试图代替终端用户说话，但通常又无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中；否则，产品很可能会因缺乏足够的信息而遗留不少隐患。

　　在实际需求分析过程中，由于业务部门工作很忙，经常没有时间或者觉得没有必要与IT人员讨论需求分析，有时甚至希望IT人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则千万不能这样做。

　　优秀的软件产品建立在优秀的需求分析基础上，而优秀的需求分析又源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。

13.2十项基本法则

　　如果CIO尝试着问一些愚蠢问题，例如：“以我的理解，你们收到订单后，会……”。业务人员立刻就会指出你的错误，并开始滔滔不绝谈论业务，这一招就叫“抛砖引玉”。

　　开发人员与业务部门的交流需要好的方法。下面建议10条法则，开发人员和业务部门可以通过评审以下内容并达成共识；如果遇到分歧，可通过协商达成对各自义务的相互了解，以便减少日后的摩擦。

　　①先导入管理思想，再梳理业务流程。

　　“百闻不如一见，百见不如一尝。”没有亲历过信息化建设的人，对信息化的理解总是比较肤浅，甚至包括一些管理层成员。如上ERP系统时，如果一开始就让业务部门谈需求，业务人员谈得通常是当前工作中的困难或者希望实现的功能等；CIO必须从转变观念入手，先给业务部门导入信息系统所包含的管理思想，然后协助业务部门梳理业务流程。

　　②表达要符合业务部门语言习惯

　　需求讨论集中于业务需求和任务，必然使用各种业务术语。如果开发人员是IT厂商，CIO应将有关业务术语教给开发人员，同时还要把IT人员常用的一些术语“翻译”给业务人员，做到交流畅通无阻。

　　③了解业务部门的业务及目标

　　只有充分了解业务部门的具体业务，才能开发出满足其需求的软件。为充分了解业务人员的具体需求，CIO要和开发人员一起到业务部门去观察他们的实际工作流程，甚至与业务部门一起工作一段时间。如果是旧系统切换到新系统，CIO还要亲自用一下目前的旧系统，明白目前系统是怎样工作的，了解其流程情况以及可供改进之处等。

　　④掌握各种沟通技巧

　　需求分析的过程实际上是个沟通的过程，CIO要想方设法吸引业务人员说出其需求。有时候，尝试着问一些“愚蠢”的问题也有助于用户打开话匣子。如果CIO直接要求业务人员写出业务是如何实现的，十有八九无法完成；但如果尝试着问一些实际的问题，例如：“以我的理解，你们收到订单后，会...”。业务人员立刻就会指出你的错误，并滔滔不绝的开始谈论业务，这一招就叫“抛砖引玉”。
⑤对业务需求进行逻辑分析

　　业务人员对需求的表达通常是笼统、感性、琐碎的，CIO要尽量理解业务人员用于表述他们需求的思维过程，充分研究用户执行任务时决策的过程，并抽象出潜在逻辑关系，把一些“常识”性东西用逻辑来实现。例如，当IT人员与护士交流医嘱处理过程时，护士会告诉IT人员，护理级别有特级护理、一级护理、二级护理、三级护理以等；饮食又分流食、半流食、禁食等种类。如果仅仅把护士的要求用计算机语言表达出来，就可能出现同一个病人既是一级护理又是二级护理，既吃流食又吃半流食的可笑情况；这些矛盾的避免原来是靠护士的大脑来判断的常识性问题，而用计算机来判断“常识”是最难的，也是最容易忽视的。经过反复探索，协和医院信息中心主任李包罗抽象出了一个互斥组的概念。特级、一级、二级、三级护理组成一个互斥组，当护士选择特级护理的时候，自然排斥了一级、二级和三级护理。李包罗说：“在与医生、护士沟通的过程中，IT人员不是要成为临床专家或者护理专家，而是要用IT知识去梳理医生护士的要求，变成一种计算机可以实现的概念，超越了手工的功能才会受到业务部门的欢迎。”

　　⑥以通俗的语言编写软件需求报告

　　IT人员应将从业务人员那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法等，然后编写软件需求报告。“需求分析报告”是IT人员和业务人员之间针对要开发的产品内容达成的协议。报告应以一种业务人员认为易于翻阅和理解的方式组织编写；报告中可以大量使用图表，但必须向业务人员解释清楚每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

　　⑦描述产品的使用特性

　　业务人员可以要求IT人员在实现功能需求的同时还注意软件的易用性，因为易用性或质量属性能使客户更准确、高效地完成任务。例如业务人员有时要求产品要“界面友好”或“健壮”、“高效率”，但对IT人员来讲，太主观了并无实用价值。IT人员可以通过询问和调查了解客户所要的“友好、健壮、高效“所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

　　⑧业务人员和IT人员互相尊重

　　如果业务人员与IT人员不能相互尊重，那关于需求的讨论将会遇到障碍。参与需求分析的业务人员有权要求IT人员尊重他们并珍惜他们为项目成功所付出的时间；但业务人员也要尊重IT人员的需求可行性及成本评估。所有软件功能都是有成本的，业务人员所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。IT人员会拒绝或实现不了业务人员的一些要求，业务人员也应该尊重IT人员的意见。

　　⑨有需求变更要立即联系

　　不断的需求变更，会给在预定计划内完成的产品质量带来严重的不利影响，但需求变更又是不可避免的。在开发周期内变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将可能被延误，特别是在主体架构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知IT人员。

⑩需求确认仅仅是以后讨论的“基线”。

　　在“需求分析报告”上签字，通常被认为是业务部门同意需求分析报告的标志性行为，然而在实际操作中，业务人员往往把“签字”看作毫无意义的事情。有时这个领导同意了，那个领导却不同意；即使每个相关人员都签了字，也照样“翻供”，通常的理由是：“他们要我在需求文档的最后一行签名，于是我就签了，否则他们不开始编码！”同样的问题也发生在仅把“签字确认”看作是完成任务的IT人员身上，一旦有需求变更出现，便指着“需求分析报告”说：“您已经在需求分析报告上签字了，所以这都是按照您的要求开发的。”-这两种态度都是不对的，因为业务人员不可能在项目早期就能说清楚所有业务需求，变更需求是必然现象。在“需求分析报告”上签字确认，仅仅是需求分析过程结束的标志，它意味着“需求分析报告”是以后讨论的基线，进一步的变更可在此基线上通过项目定义的变更过程来进行。

　　拨开需求分析的迷雾，将给初步的需求开发工作画上双方都明确的句号，将有助于形成一个持续良好的客户与开发人员的关系，为项目成功奠定坚实的基础

13.3需求分析的风险

　　客户有时会提一些看上去很“酷”，但缺乏实用价值的功能；若要实现这些功能可能要耗费大量时间和成本，造成项目延期，此时CIO要权衡业务需求和项目资源之间的关系，及时决定必须完成哪些需求，舍弃哪些需求。

　　不重视需求分析的项目组将“自食其果”，但重视了并不一定能写出完美的需求分析报告，因为需求分析中还有很多陷阱，稍微不慎CIO就可能掉进业务需求的“陷阱”。需求分析中常见的陷阱有以下几种：

　　首先是无足够用户参与。业务部门经常不明白为什么收集需求和确保需求质量需要费那么多功夫。由于业务部门工作很忙，有时IT人员很难与业务人员坐在一起交流业务需求；即使费了九牛二虎之力坐在一起，业务人员也讲不明白自己的真正需求。为确保需求分析的质量，CIO一方面要让IT人员与尽量多的业务人员交流；另一方面，应让具有代表性的用户在项目早期就直接参与到开发队伍中来，一同经历整个开发过程。

　　其次是业务需求无休无止。业务部门在开发中若不断补充需求，项目就可能越变越大以致于超过计划及预算范围。计划并不总是与项目需求规模与复杂性、风险及需求变更实际情况相一致，使得问题更难解决。要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。另一方面，CIO要确定一个提需求分析的最后时间，不能放任业务人员无休止的提需求分析。
再次是用户需求模棱两可。模棱两可是需求规格说明中最可怕的问题。模棱两可的需求会使开发人员为错误问题而浪费时间，并使测试者无所适从。一位系统测试人员说，他所在的测试组经常对需求理解有误，以致不得不重写许多测试用例并重做许多测试。

　　最后是不必要的“画蛇添足”。“画蛇添足”是指开发人员力图增加一些用户“欣赏”，但需求分析说明中并未涉及的新功能。有时IT人员花了非常大的力气，但用户并不认为这些功能很有用；IT人员应努力使功能简单易用，但不要未经业务人员同意，就自作主张。同样，客户有时也会提一些看上去很“酷”，但缺乏实用价值的功能；若要实现这些功能可能要耗费大量时间和成本，造成项目延期，此时CIO要权衡业务需求和项目资源之间的关系，及时决定必须完成哪些需求，舍弃哪些需求。任何项目都不可能十全十美，也不可能满足用户的所有需求，毕竟项目的成本有限；CIO要弄清这些功能的“来龙去脉”，使得需求分析过程始终注重那些能使用户完成主要任务的核心功能。

十四、像拉小提琴一样实施BPR

【IT168 专稿】会拉小提琴的朋友都知道，学拉小提琴先从分解动作练起，练好分解动作后才能演奏完整的曲子；但要参加乐队演奏，不仅自己要拉好每支曲子，还要前后左右配合好。信息化也一样，在部门级应用阶段信息系统“各自为政”，但到了跨部门应用阶段就整合业务流程，把分散的系统集成在一起，使整个企业协调运作。为什么到了跨部门应用阶段就必须业务流程调整(BPR, Business Process Reengineering)？BPR的基本原则是什么？目前BPR有哪些误区？

14.1信息整合的三个阶段

　　从信息整合的角度看，第一阶段相当于练习拉小提琴的分解动作，第二阶段是用小提琴演奏完整的曲子，第三阶段则是整个乐队的演奏。

　　企业信息的整合大致经历了三个阶段：第一个阶段是简单、分散的应用，主要是用计算机解决特定任务，简化诸如定单输入等业务流程，目的是提高劳动生产率。这个阶段应用最大的问题是破坏了流程的连续性，从而增加了管理成本。第二个阶段是部门应用整合，将分散的任务整合为连续的流程，例如定单输入成为销售管理应用的组成部分，但造成了一个个“信息孤岛”。第三个阶段是跨部门应用整合，强调企业在新的复杂环境下解决问题的综合能力。这就是20世纪90年代兴起的BPR浪潮，主要目标是管理和优化跨部门的业务流程，将分散的部门活动融合成组织良好的、可靠的系统。

　　从信息整合的角度看，第一阶段相当于练习拉小提琴的分解动作，第二阶段是用小提琴演奏完整的曲子，第三阶段则是整个乐队的演奏。正是由于频繁的价格战、市场份额战、产品质量战等迫使企业不断优化、整合业务流程，协调整个企业的资源有效满足顾客的要求。