论文部分内容阅读
A企业是一家生产制造厂商，使用一套国外的ERP软件支持整个工厂大部分的运营。A企业的IT部负责这套ERP系统日常维护、流程改进以及其他企业信息化项目的实施工作。由于该ERP系统中Sale Quote(销售报价)模块不能满足绝大部分企业报价流程的需要，A企业决定自行开发，独立推行此子模块。
我们需要这东西么?
在企业中，ERP等IT系统的改善，新功能的开发，子模块的推行，绝大多数都是由最终用户——系统的实际操作者提出的。他们提出来的一般都是系统中确实存在错误或者是不方便的问题，应他们的要求而进行的系统推行最容易，执行最轻松。但是这些需求有相当一部分对企业来说没有太多的价值，甚至是妨碍流程顺利执行的，特别是涉及到多个部门协调的需求。这主要是因为需求提出者最基本的出发点都是基于自身的工作，不能够很好地从整体考虑，甚至仅仅是因为个人工作的习惯不同于系统，就直接提出了系统更改需求。
因此，要求当用户提出某项需求后，将受影响的部门也签署对应的意见是个很好的方法。在这个基础上，要求用户评估满足此需求所或者这个故事能给你一些启发。带来的效益。但是要求用户直接描述效益是个根本不可行的举措，于是IT部门将效益归纳为效率的提高和数据准确性的提高，要求用户将系统满足需求后估计的提高百分比填上。即便如此，聪明的用户都学会了夸大百分比，从而让自己的需求更容易通过。于是，这要求IT部门的系统分析人员进一步全面而深入的了解真实的用户需求。
Sale Quote项目却有些不同，这是由IT部门出于流程改进的目的而提出的。如同大多数EKP产品，A企业所使用的ERP系统SaleQuote集中于产品的价格、费用、付款方式等商业交易方面的管理，但在交给客户的报价单中，总会有不少工程参数数据，这在ERP基本的功能上就存在不足。而A企业的SaleQuote流程中，包括了新产品设计，定价以及样品试制等重要过程，这在ERP系统中是根本没有的，于是IT部门决定重新开发来实施这个项目。
通过实施Sale Quote项目，IT部门预计，A企业将获得收益：
★完善ERP流程；
所有报价单都由系统出具，格式统一；
部门间沟通数据以系统为准，Sale Quote流程可追溯性达到90％以上(因为工程图纸不能带入系统，不可以将追溯性进一步提高)；
采用报价单生命周期管理，加强状态审核控制，杜绝无意或恶意毁坏数据现象，使数据准确率提高至99％以上；
流程电子化，杜绝不按流程行事现象。
在预期效益中没有提到效率提高，这是由ERP软件特点决定的，ERP不是企业协同办公软件，侧重于数据的存储与整合。一般情况下，数据的录入工作是在业务流程完成后再录入系统，所以不能够提升流程的效率。
将项目的预期成本与效益分析递交上去后，很快得到各主管部门经理以及经理层的同意，项目进入到实做阶段。
我们需要什么样的系统?
虽然在立项阶段初步确定了项目的基本范围以及预期效果，但是系统分析的第一步一一明确系统的边界，仍然是个颇费脑筋的问题。
首先要做的当然是和用户仔细沟通现行流程。通常，配合IT部门需求分析的业务部门联系人都是本部门的业务骨干，他们精通业务，熟悉流程，是需求调研的最佳人选。但是因为他们熟悉运作，且富有主见，他们会把他们认为的“系统边界”告诉你，而不会涉及他们认为的“系统外”的东西。因为他们是骨干，是部门内部小组的主管，出于“保护”自身的理由，有意无意地将有可能增加自己工作量的细节“忘记”了。
于是，在每次需求调研会议上，叫上所有相关部门联络人是明智的。在某个联络人发言完毕后，请其他部门联络人补充是否有所遗漏，或者详细描述一下跟其部门相关的那部分工作。很多时候，项目经理都希望每部门参加需求调研的联络人有2人，这样他们可以互相补充遗忘的部分。但基本上都不会有这样的机会，于是只有在私下里和其部门其他人探讨感兴趣的问题，然后再拿到会议上讨论。
每次会后必须要做的一件事一一将详细的会议記录发给与会人，并要求他们签署确认。
在得到用户现行流程的火致框架后，才正式进入系统边界设计。取舍用户需求是件痛苦的抉择。看上去用户所有的需求都可以通过系统来实现，事实上绝大多数也都可以。这时候直接去问用户“你需要什么样的系统?”是个愚蠢的做法。绝大多数用户也不知道他需要什么样的系统，从内心里他甚至不希望有系统增加他的工作量，他最多告诉你“我需要这几个报表，你把它们弄出来就行了。”所以考虑实现用户需求之前不妨问自己几个问题：实现这些需求后会有什么作用，对用户有多大帮助，对企业产生何种效益，实现的成本有多高，实现后的副作用有多大?
经过分析，Sale Quote流程划分为报价(Quotation)，定价(Pricing)，样版(Sample)二三个子模块。
在报价模块主要侧重于实际报价单的记录，以及对超折扣额度的报价审核管理。舍弃了记录客户询价的过程。这是因为首先本项目的重点在于报价，而不是客户询价(Customer Inquiry)，并不是每次询价都会转化为报价；其次，每天产生多次询价而且频繁，包含的信息量很大，不能保证每次询价数据可以及时准确地录入系统。所以，即使询价对分析客户划分，市场趋势有很大的参考意义，还是将其舍弃了。
在定价模块，由于新产品的设计BOM(E-BOM)定价涉及到工程与采购部门间协作，于是将E—BOM各阶段的审核步骤也放在系统中完成，希望可以通过系统完成所有工作流，而彻底甩开纸制工作传递文件。同时记录各阶段工作时间与负责人，用以监控项目进度。
嘿!相信我，这就是你要的!
在得到系统流程以及大体功能分配后，和用户讨论流程是否适合的过程中，更多的时候是说服用户接受系统设计。
为了有效说明设计意图，尽量使用图表是个好习惯。使用何种图表呢?UML(unified ModelLanguage，统一建模语言)看来是不错的选择：多方面多层次多角度的过程描述，统一的图表符号，严格的名词定义。但最大的问题是，用户看得懂么?不要试图教会用户看自己的图表，这个阶段因为图表理解错误对项目的危害是致命的，直接使用用户明白的方式去交流。
于是，项目经理将UML的使用做了一些小小的限定。只给用户看用例图(Use Case)和活动图(Activity)。
用例图的角色(Actor)直接对应 到操作者部门，告诉他你会有那些工作任务，这些工作与哪些工作有关联。不要把用例划分得太细，图表做得太复杂，因为这份图表放在设计说明书的开始，用户一翻开说明书发现自己居然做这么多事情，一下子就产生了抗拒心理，后面的工作就要费劲多了。
活动图，或者叫流程图，全少和用户在一起时这样叫。这张图表体现了系统功能点以及联系，是用户了解设计意图的基本用图，所以一定要详细、明确。同用例图一样，活动图一定要分区，每个分区对应到一个业务部门。系统中每个操作功能都要明确对应到部门。因为报价有个循环的生命周期，所以在有可能的转向分支都要仔细的表示，哪怕这个分支不在系统中完成。
有了图表可以更方便的表述设计意图，但更艰巨的任务是——说服用户接受它!
和用户最容易产生分歧的在于操作功能的分配。因为系统的实现并不总会和实际的操作流程一致，有可能将某部门的操作转移到另一个部门来完成。只要工作量不是特别大，将实际情况以及可能的影响向用户解释清楚，一般都可以达成一致。
然而，在讨论定价模块新增的两个审核步骤时，却出现了一场激烈的争论。
定价(Pricing)是指应客户的要求，设计新产品，并将新产品的价格报给客户，以争取客户订单。新产品的定价过程很简单：工程部进行设计，将设计物料清单(E-BOM)中物料交给采购部定价，所有物料价格累加，乘以一定系数就是新产品报价。为保证设计质量，E-BOM设计完成后会交给高工或者主管审核；同样，采购部也有物料定价的审核。系统设计时将这两个审核作为了独立的功能，要求对E-BOM进行电子化批签。
但是用户却反对这么做，因为他们认为一是增加了系统的操作复杂性；二是需要进行系统批核，如果没有及时批核的話，会影响市场部的报价，影响客户响应速度。项目经理听懂了其中的潜台词一一“你这样会增加我的工作量。如果真因为批核影响报价速度，我可不愿意对付Sales的投诉!”
于是项目经理反复地和他们宣扬电子化流程的好处，如何带来流程的完整性与工作的可控性。告诉他们不一定自己亲自进行审核，可以授权给其他人做的。为了增加可操作性，可以集成公司的电子邮件系统，采用Email来进行下一步工作的通知。就算市场部投诉，也可以很方便地查找是在哪里出了问题……
正在讨论不可开交时，一起事故帮了项目经理一个忙：负责存档E-BOM价格信息的职员在离职时将所有E-BOM报价excel文件全部删除了。于是项目经理终于有了更加理直气壮的理由——“你看，如果有数据审核工作，就没有人可以修改这些数据了，更不要说删除了。嘿!相信我，这就是你要的东西。”
很快地，设计说明书被用户签名通过了。
接下来是紧张的编码，其间又有反反复复的和用户讨论细节，调整方案。终于完成了程序，并且通过了内部测试。该模拟运行测试了。于是项目经理给项目联系人打了个电话：“让我们来玩一下我们的新系统吧!”
首先需要的是一份可行的详细的测试计划。计划明确的规定了x月x日的上午应该使用什么功能，下午应该录入什么数据。不允许存在任何的含糊不清，头尾交迭的时间界定。对于每个功能应该输入何种类型的数据，产生怎样的输出结果也要清楚明白的列出。其中，特别需要强调的，一定是正在使用的真实的数据。当然，此时详细到每个栏位说明系统操作手册已经完成，一早就发到测试人员手上了。
得益于周密的准备，为期2周的模拟运行按照计划顺利展开，系统的大部分功能得到用户测试，流程运行的很顺畅，没有发现重大问题。于是项目经理很乐观地估计，只要再进行一次彻底的用户培训，就可以正常使用系统了。
系统上线以后……
上线的第一天，市场部的开始投诉了，“E-BOM定价太慢了，特别在采购部，都不知道该找谁才知道我这张E-BOM的价格!”
原来采购部的每个采购员只负责某几类物料，一个E-BOM的定价需要多个采购员分别询价才可以得到。之前每张E-BOM表格都交给采购部的专人，由他跟进各物料的询价情况。现在这张纸表格取消了，于是采购部“自然地”将这个专人地工作也取消了。于是导致了市场部客服小姐需要催促多个采购员及时询价及时录入系统才可以得到产品的定价。系统可以提醒采购员工作，但是没白办法让每个采购员都及时将价格输入系统的。
工程部的情况好些，但实际的使用却与设计相差甚远。因为ERP账号数量的限制，负责设计的工程师没有ERP账号，工程部相关的系统数据都是由专门的数据录入小组完成的。于是工程师还是将E—BOM做在纸上，并且通过相关主管的在纸制文件上签名审核通过后，才交给专门的数据输入员录入系统。录入完成后，系统还笨笨地发Email通知工程经理进行系统审核!这不仅仅带来重复的劳动，而且使系统不能正确采集项目的进度时间数据。
应该说，这都不是系统设计上的问题，系统的设计围绕着项目预期效益展开，并很好得实现了项目目的。问题出在系统执行时，没有很好的进行转变，在细节上“掉了链子”，引起了严重的后果。根本上，是实施的问题!
实施并不只是培训用户如何操作系统这么简单，而是要提供一整套业务流程的操作方案，包括系统内的和系统外的。在切换系统前后，需要将所有可能的变化都考虑到，并且做出应对的方案。培训最终用户要耐心仔细，要使他们清楚每个环节每个细节的做法，而不是仅仅告诉他什么时候应该使用什么系统功能。不要相信通过培训，用户就能按照培训的方法去做了。他们经常会忘记，甚至时不时来些“创造性”做法。对待他们，需要一根大棒加上一根胡萝卜。
定价模块的混乱影响到了响应客户的速度，必须马上解决，否则项目可能直接下线。
对于工程部，没有给工程师增加ERP账号，而是要求工程师还是按照原来的操作，只不过要求他们在完成工程审核后，第一时间将结果交给数据录入员输入系统。因为对工程师来说，他不仅仅是构造E-BOM，还要处理工程图纸，技术参数。如果他们不能够将所有工作都放在系统中完成，他们必然会将所有工作完成后再将E-BOM录入系统。这样还是导致了重复工作。更何况这些工程师从来没有接触ERP系统。对工程部的数据录入小组，项目经理建议系统中工程审核人不再是工程经理，而是另外的专人，负责核对系统数据是否和工程师递交的一致。虽然最后工程部并没有更改系统审核人，因为工程经理希望通过审核来大致掌握工程师的工作量，但这已经不是什么问题了，因为工程经理承诺会在4 小时内及时进行批核，并设置了后备的批核人。
对于采购部，项目经理建议将原来取消的E—BOM询价协调人设置回来，作为采购部面向市场部关于报价问题的窗口。又开发一个报表报告未完成报价的工作任务，以作为采购部定期检讨材料。最重要的，说服市场部牵头，逼着采购部做出在收到工程部E—BOM的5个工作日内必须完成定价的承诺。
为了加强市场部对saleQuote的监控力度，项目经理将项目控制报表提供给了他们。这份报表记录了每个Sale Quote在各阶段所耗用的时间，特别强调了超期项目的显示。
经过一周的调整，各部门逐步适应了新的操作流程，再也没有听到用户部门关于系统流程的抱怨。一个月后，新的流程已经成为了固定流程。各个部门都承担了对新同事进行系统培训的工作，IT部偶尔才需要做一些简单的技术支持。
本文作者：耿坚某外资制造型企业系统分析师
联系方式：paul_geng@163．com
细节与沟通
这是一次比较完整的企业内部IT项目实施，涉及了需求分析、系统设计、代码编制、系统推行等各主要过程。从结果上说，是成功的：按计划推进的进度，按预期获得的收益。对于不同企业不同项目来说，要获得内部实施的成功，需要着重注意两点：细节和沟通。
细节的运用，贯穿在本次实施的方方面面。一些典型的方法有：
一、使用明确的数字。比如在立项阶段，要求用户填写需求申请的那两个描述效益的两个百分比，还有收益分析的明确效果提高数字。
二、使用严格的过程定义。比如在需求说明书中明确的系统边界，UML图表。再比如不存在头尾交迭日期的测试计划。
三、关注用户，记录每次沟通。不要放过每次沟通时每个用户的细节。用户在会议上的欲言又止，不同部门用户需求描述的细微差别都有可能影响到需求搜集的准确性；在培训会议上的用户的哈欠、争论都有可能影响到系统的应用效果。千万不要忘记了每次会议都会有决议，都需要记录，都要让人知道。
每个内部实施项目，实施人员都要面对不同部门、职位、性格、利益取向的人进行沟通。在本次项目中，项目经理使用了各种方法来达到有效的沟通。需求分析时，为了得到更全面的信息，要求各部门互相补充，会议后的单独了解；说服各部门主管、经理采纳方案时，讲究从管理的高度，小心处理各方利益得失，并善于利用周围发生的一切事情；問题发生时，借助强势部门一一市场部的力量来推动自己的措施……
成功的IT项目可以总结的还有很多，细节和沟通则是这次项目的主要成功因素。希望不同的人看到这个故事可以得到自己想要的东西。
我们需要这东西么?
在企业中，ERP等IT系统的改善，新功能的开发，子模块的推行，绝大多数都是由最终用户——系统的实际操作者提出的。他们提出来的一般都是系统中确实存在错误或者是不方便的问题，应他们的要求而进行的系统推行最容易，执行最轻松。但是这些需求有相当一部分对企业来说没有太多的价值，甚至是妨碍流程顺利执行的，特别是涉及到多个部门协调的需求。这主要是因为需求提出者最基本的出发点都是基于自身的工作，不能够很好地从整体考虑，甚至仅仅是因为个人工作的习惯不同于系统，就直接提出了系统更改需求。
因此，要求当用户提出某项需求后，将受影响的部门也签署对应的意见是个很好的方法。在这个基础上，要求用户评估满足此需求所或者这个故事能给你一些启发。带来的效益。但是要求用户直接描述效益是个根本不可行的举措，于是IT部门将效益归纳为效率的提高和数据准确性的提高，要求用户将系统满足需求后估计的提高百分比填上。即便如此，聪明的用户都学会了夸大百分比，从而让自己的需求更容易通过。于是，这要求IT部门的系统分析人员进一步全面而深入的了解真实的用户需求。
Sale Quote项目却有些不同，这是由IT部门出于流程改进的目的而提出的。如同大多数EKP产品，A企业所使用的ERP系统SaleQuote集中于产品的价格、费用、付款方式等商业交易方面的管理，但在交给客户的报价单中，总会有不少工程参数数据，这在ERP基本的功能上就存在不足。而A企业的SaleQuote流程中，包括了新产品设计，定价以及样品试制等重要过程，这在ERP系统中是根本没有的，于是IT部门决定重新开发来实施这个项目。
通过实施Sale Quote项目，IT部门预计，A企业将获得收益：
★完善ERP流程；
所有报价单都由系统出具，格式统一；
部门间沟通数据以系统为准，Sale Quote流程可追溯性达到90％以上(因为工程图纸不能带入系统，不可以将追溯性进一步提高)；
采用报价单生命周期管理，加强状态审核控制，杜绝无意或恶意毁坏数据现象，使数据准确率提高至99％以上；
流程电子化，杜绝不按流程行事现象。
在预期效益中没有提到效率提高，这是由ERP软件特点决定的，ERP不是企业协同办公软件，侧重于数据的存储与整合。一般情况下，数据的录入工作是在业务流程完成后再录入系统，所以不能够提升流程的效率。
将项目的预期成本与效益分析递交上去后，很快得到各主管部门经理以及经理层的同意，项目进入到实做阶段。
我们需要什么样的系统?
虽然在立项阶段初步确定了项目的基本范围以及预期效果，但是系统分析的第一步一一明确系统的边界，仍然是个颇费脑筋的问题。
首先要做的当然是和用户仔细沟通现行流程。通常，配合IT部门需求分析的业务部门联系人都是本部门的业务骨干，他们精通业务，熟悉流程，是需求调研的最佳人选。但是因为他们熟悉运作，且富有主见，他们会把他们认为的“系统边界”告诉你，而不会涉及他们认为的“系统外”的东西。因为他们是骨干，是部门内部小组的主管，出于“保护”自身的理由，有意无意地将有可能增加自己工作量的细节“忘记”了。
于是，在每次需求调研会议上，叫上所有相关部门联络人是明智的。在某个联络人发言完毕后，请其他部门联络人补充是否有所遗漏，或者详细描述一下跟其部门相关的那部分工作。很多时候，项目经理都希望每部门参加需求调研的联络人有2人，这样他们可以互相补充遗忘的部分。但基本上都不会有这样的机会，于是只有在私下里和其部门其他人探讨感兴趣的问题，然后再拿到会议上讨论。
每次会后必须要做的一件事一一将详细的会议記录发给与会人，并要求他们签署确认。
在得到用户现行流程的火致框架后，才正式进入系统边界设计。取舍用户需求是件痛苦的抉择。看上去用户所有的需求都可以通过系统来实现，事实上绝大多数也都可以。这时候直接去问用户“你需要什么样的系统?”是个愚蠢的做法。绝大多数用户也不知道他需要什么样的系统，从内心里他甚至不希望有系统增加他的工作量，他最多告诉你“我需要这几个报表，你把它们弄出来就行了。”所以考虑实现用户需求之前不妨问自己几个问题：实现这些需求后会有什么作用，对用户有多大帮助，对企业产生何种效益，实现的成本有多高，实现后的副作用有多大?
经过分析，Sale Quote流程划分为报价(Quotation)，定价(Pricing)，样版(Sample)二三个子模块。
在报价模块主要侧重于实际报价单的记录，以及对超折扣额度的报价审核管理。舍弃了记录客户询价的过程。这是因为首先本项目的重点在于报价，而不是客户询价(Customer Inquiry)，并不是每次询价都会转化为报价；其次，每天产生多次询价而且频繁，包含的信息量很大，不能保证每次询价数据可以及时准确地录入系统。所以，即使询价对分析客户划分，市场趋势有很大的参考意义，还是将其舍弃了。
在定价模块，由于新产品的设计BOM(E-BOM)定价涉及到工程与采购部门间协作，于是将E—BOM各阶段的审核步骤也放在系统中完成，希望可以通过系统完成所有工作流，而彻底甩开纸制工作传递文件。同时记录各阶段工作时间与负责人，用以监控项目进度。
嘿!相信我，这就是你要的!
在得到系统流程以及大体功能分配后，和用户讨论流程是否适合的过程中，更多的时候是说服用户接受系统设计。
为了有效说明设计意图，尽量使用图表是个好习惯。使用何种图表呢?UML(unified ModelLanguage，统一建模语言)看来是不错的选择：多方面多层次多角度的过程描述，统一的图表符号，严格的名词定义。但最大的问题是，用户看得懂么?不要试图教会用户看自己的图表，这个阶段因为图表理解错误对项目的危害是致命的，直接使用用户明白的方式去交流。
于是，项目经理将UML的使用做了一些小小的限定。只给用户看用例图(Use Case)和活动图(Activity)。
用例图的角色(Actor)直接对应 到操作者部门，告诉他你会有那些工作任务，这些工作与哪些工作有关联。不要把用例划分得太细，图表做得太复杂，因为这份图表放在设计说明书的开始，用户一翻开说明书发现自己居然做这么多事情，一下子就产生了抗拒心理，后面的工作就要费劲多了。
活动图，或者叫流程图，全少和用户在一起时这样叫。这张图表体现了系统功能点以及联系，是用户了解设计意图的基本用图，所以一定要详细、明确。同用例图一样，活动图一定要分区，每个分区对应到一个业务部门。系统中每个操作功能都要明确对应到部门。因为报价有个循环的生命周期，所以在有可能的转向分支都要仔细的表示，哪怕这个分支不在系统中完成。
有了图表可以更方便的表述设计意图，但更艰巨的任务是——说服用户接受它!
和用户最容易产生分歧的在于操作功能的分配。因为系统的实现并不总会和实际的操作流程一致，有可能将某部门的操作转移到另一个部门来完成。只要工作量不是特别大，将实际情况以及可能的影响向用户解释清楚，一般都可以达成一致。
然而，在讨论定价模块新增的两个审核步骤时，却出现了一场激烈的争论。
定价(Pricing)是指应客户的要求，设计新产品，并将新产品的价格报给客户，以争取客户订单。新产品的定价过程很简单：工程部进行设计，将设计物料清单(E-BOM)中物料交给采购部定价，所有物料价格累加，乘以一定系数就是新产品报价。为保证设计质量，E-BOM设计完成后会交给高工或者主管审核；同样，采购部也有物料定价的审核。系统设计时将这两个审核作为了独立的功能，要求对E-BOM进行电子化批签。
但是用户却反对这么做，因为他们认为一是增加了系统的操作复杂性；二是需要进行系统批核，如果没有及时批核的話，会影响市场部的报价，影响客户响应速度。项目经理听懂了其中的潜台词一一“你这样会增加我的工作量。如果真因为批核影响报价速度，我可不愿意对付Sales的投诉!”
于是项目经理反复地和他们宣扬电子化流程的好处，如何带来流程的完整性与工作的可控性。告诉他们不一定自己亲自进行审核，可以授权给其他人做的。为了增加可操作性，可以集成公司的电子邮件系统，采用Email来进行下一步工作的通知。就算市场部投诉，也可以很方便地查找是在哪里出了问题……
正在讨论不可开交时，一起事故帮了项目经理一个忙：负责存档E-BOM价格信息的职员在离职时将所有E-BOM报价excel文件全部删除了。于是项目经理终于有了更加理直气壮的理由——“你看，如果有数据审核工作，就没有人可以修改这些数据了，更不要说删除了。嘿!相信我，这就是你要的东西。”
很快地，设计说明书被用户签名通过了。
接下来是紧张的编码，其间又有反反复复的和用户讨论细节，调整方案。终于完成了程序，并且通过了内部测试。该模拟运行测试了。于是项目经理给项目联系人打了个电话：“让我们来玩一下我们的新系统吧!”
首先需要的是一份可行的详细的测试计划。计划明确的规定了x月x日的上午应该使用什么功能，下午应该录入什么数据。不允许存在任何的含糊不清，头尾交迭的时间界定。对于每个功能应该输入何种类型的数据，产生怎样的输出结果也要清楚明白的列出。其中，特别需要强调的，一定是正在使用的真实的数据。当然，此时详细到每个栏位说明系统操作手册已经完成，一早就发到测试人员手上了。
得益于周密的准备，为期2周的模拟运行按照计划顺利展开，系统的大部分功能得到用户测试，流程运行的很顺畅，没有发现重大问题。于是项目经理很乐观地估计，只要再进行一次彻底的用户培训，就可以正常使用系统了。
系统上线以后……
上线的第一天，市场部的开始投诉了，“E-BOM定价太慢了，特别在采购部，都不知道该找谁才知道我这张E-BOM的价格!”
原来采购部的每个采购员只负责某几类物料，一个E-BOM的定价需要多个采购员分别询价才可以得到。之前每张E-BOM表格都交给采购部的专人，由他跟进各物料的询价情况。现在这张纸表格取消了，于是采购部“自然地”将这个专人地工作也取消了。于是导致了市场部客服小姐需要催促多个采购员及时询价及时录入系统才可以得到产品的定价。系统可以提醒采购员工作，但是没白办法让每个采购员都及时将价格输入系统的。
工程部的情况好些，但实际的使用却与设计相差甚远。因为ERP账号数量的限制，负责设计的工程师没有ERP账号，工程部相关的系统数据都是由专门的数据录入小组完成的。于是工程师还是将E—BOM做在纸上，并且通过相关主管的在纸制文件上签名审核通过后，才交给专门的数据输入员录入系统。录入完成后，系统还笨笨地发Email通知工程经理进行系统审核!这不仅仅带来重复的劳动，而且使系统不能正确采集项目的进度时间数据。
应该说，这都不是系统设计上的问题，系统的设计围绕着项目预期效益展开，并很好得实现了项目目的。问题出在系统执行时，没有很好的进行转变，在细节上“掉了链子”，引起了严重的后果。根本上，是实施的问题!
实施并不只是培训用户如何操作系统这么简单，而是要提供一整套业务流程的操作方案，包括系统内的和系统外的。在切换系统前后，需要将所有可能的变化都考虑到，并且做出应对的方案。培训最终用户要耐心仔细，要使他们清楚每个环节每个细节的做法，而不是仅仅告诉他什么时候应该使用什么系统功能。不要相信通过培训，用户就能按照培训的方法去做了。他们经常会忘记，甚至时不时来些“创造性”做法。对待他们，需要一根大棒加上一根胡萝卜。
定价模块的混乱影响到了响应客户的速度，必须马上解决，否则项目可能直接下线。
对于工程部，没有给工程师增加ERP账号，而是要求工程师还是按照原来的操作，只不过要求他们在完成工程审核后，第一时间将结果交给数据录入员输入系统。因为对工程师来说，他不仅仅是构造E-BOM，还要处理工程图纸，技术参数。如果他们不能够将所有工作都放在系统中完成，他们必然会将所有工作完成后再将E-BOM录入系统。这样还是导致了重复工作。更何况这些工程师从来没有接触ERP系统。对工程部的数据录入小组，项目经理建议系统中工程审核人不再是工程经理，而是另外的专人，负责核对系统数据是否和工程师递交的一致。虽然最后工程部并没有更改系统审核人，因为工程经理希望通过审核来大致掌握工程师的工作量，但这已经不是什么问题了，因为工程经理承诺会在4 小时内及时进行批核，并设置了后备的批核人。
对于采购部，项目经理建议将原来取消的E—BOM询价协调人设置回来，作为采购部面向市场部关于报价问题的窗口。又开发一个报表报告未完成报价的工作任务，以作为采购部定期检讨材料。最重要的，说服市场部牵头，逼着采购部做出在收到工程部E—BOM的5个工作日内必须完成定价的承诺。
为了加强市场部对saleQuote的监控力度，项目经理将项目控制报表提供给了他们。这份报表记录了每个Sale Quote在各阶段所耗用的时间，特别强调了超期项目的显示。
经过一周的调整，各部门逐步适应了新的操作流程，再也没有听到用户部门关于系统流程的抱怨。一个月后，新的流程已经成为了固定流程。各个部门都承担了对新同事进行系统培训的工作，IT部偶尔才需要做一些简单的技术支持。
本文作者：耿坚某外资制造型企业系统分析师
联系方式：paul_geng@163．com
细节与沟通
这是一次比较完整的企业内部IT项目实施，涉及了需求分析、系统设计、代码编制、系统推行等各主要过程。从结果上说，是成功的：按计划推进的进度，按预期获得的收益。对于不同企业不同项目来说，要获得内部实施的成功，需要着重注意两点：细节和沟通。
细节的运用，贯穿在本次实施的方方面面。一些典型的方法有：
一、使用明确的数字。比如在立项阶段，要求用户填写需求申请的那两个描述效益的两个百分比，还有收益分析的明确效果提高数字。
二、使用严格的过程定义。比如在需求说明书中明确的系统边界，UML图表。再比如不存在头尾交迭日期的测试计划。
三、关注用户，记录每次沟通。不要放过每次沟通时每个用户的细节。用户在会议上的欲言又止，不同部门用户需求描述的细微差别都有可能影响到需求搜集的准确性；在培训会议上的用户的哈欠、争论都有可能影响到系统的应用效果。千万不要忘记了每次会议都会有决议，都需要记录，都要让人知道。
每个内部实施项目，实施人员都要面对不同部门、职位、性格、利益取向的人进行沟通。在本次项目中，项目经理使用了各种方法来达到有效的沟通。需求分析时，为了得到更全面的信息，要求各部门互相补充，会议后的单独了解；说服各部门主管、经理采纳方案时，讲究从管理的高度，小心处理各方利益得失，并善于利用周围发生的一切事情；問题发生时，借助强势部门一一市场部的力量来推动自己的措施……
成功的IT项目可以总结的还有很多，细节和沟通则是这次项目的主要成功因素。希望不同的人看到这个故事可以得到自己想要的东西。