基于业务的软件选型方法论

1、基于业务的软件选型方法论         前言    企业信息化的道路充满荆棘，这固然和中国企业本身信息技术人才缺乏，信息技术素质低，中国>' target='_blank' class='infotextkey'>管理软件市场处于成长的混乱期，厂商更多注重短期利益等原因有直接关系，但是未尝就不和企业本身对信息技术选择、实施的方法论有关。    回头34年，我们看看企业在推广“甩图板”工程时，虽

2、然也有很多路障，但是实施几年的CAD普及工作到2000年看，是比较成功的。而那时的科委、生产力促进中心和企业技术部门对软件选型的通力合作是关键的一个成功因素。有了正确的软件选型方法论，使得多数企业找到最适合自身技术开发特色和生产制造类型的CAD软件与IT合作伙伴。    我在972000年期间，有幸参加30多家大型企业集团的CAD项目建设，对于这段工作的经历，我总结成一套面向业务的软件系统选型方法论。期望这套方法论能帮助现在的企业在信息系统项目选型中少走弯路，最终提高项目的效益和运转的效率。    企业注重软件的选

3、型有很多原因。主要原因在于寻找并实施信息解决方案来帮助企业减少成本开支，最大化利润收入，并在迅速变化的市场抓住机会，使得企业运营有利可图，并成为可持续发展的实体。    不幸的是，许多公司在寻找他们想要的软件系统或解决方案的时候，由于方法论不正确而得不到理想的结局。多数情况下，公司只是简单的把软件选型工作交给业务人员作为他们的日常工作之一；其他时候，由公司的IS部门来实施软件选型计划。常常软件的选择是完全基于供应商自己的阐述，但是软件企业的论述是不独立客观的，如果软件供应商有好的范例、好的销售人员，一般会中标。   

4、0;总的来说，在任何一个企业都可以找出企业购买不适合的软件。而用基于业务的软件选型方法可以很大的改善企业软件选型，最终使得合适的软件配合适合的企业业务系统。    项目启动    软件选型项目的启动阶段包括：    ? 项目的范围和目标确定    ? 项目团队的组织    ? 选择和剔除        任何事物必须先定

5、义然后再有讨论的空间，软件选型项目的范围和目标对项目的成功是至关重要的。用户过高的期望注定企业常常有许多各式各样的软件需求，但是最终多数项目被取消。以公司必须在项目开始时候设立一个真实的范围，涉及的每个人对项目有一个共同的蓝图公司企图达到怎样的目的。把范围和目标文档化，公司产生一个文档包含以下内容：    ? 问题表述的定义（项目将要解决什么问题）    ? 项目出资人和项目的实际>' target='_blank' class='infotextkey'>管理委

6、员会职责定义和组成范围    ? 仔细讲解清楚项目的目标    ? 项目团队、参与者的名字和角色    ? 项目不包含部分的表述    ? 重要的或有费用和项目依赖的资源        定义项目的团队也是重要的步骤。项目如果有组织中各层面的人员参加，将会有更多机会获得成功。理想的项目组应该是如下结构：    项目的出资

7、方    一个或两个>' target='_blank' class='infotextkey'>管理委员会的成员，在项目开始时候，明确并展开目标    支持委员会    二个或更多的高层>' target='_blank' class='infotextkey'>管理人员，来自项目可能产生冲击、带来收益的部门    项目>&#

8、39; target='_blank' class='infotextkey'>管理    一个项目经理，>' target='_blank' class='infotextkey'>管理项目向项目>' target='_blank' class='infotextkey'>管理委员会负责    项目小组    项目目标涉及的不同部门员

9、工参与        参与者模型可以认为是凳子的三条腿，项目出资人、>' target='_blank' class='infotextkey'>管理委员会和项目小组三个层组织构架缺一项目难以获得成功。如果项目是对组织的重大变革，项目出资人没有项目>' target='_blank' class='infotextkey'>管理委员会支持将会遇到很多障碍。而>' target='_blank

10、' class='infotextkey'>管理委员会没有项目出资人将缺乏支持，也将导致项目失败。最后，项目小组的存在是承担具体的运作任务。        把那些不属于本项目的内容排除是项目启动的必要完成的工作，排除的目的是在项目早期告诉项目成员那些领域和内容是项目要完成的，使得他们对项目范围和目标更加清晰。如果项目出资人在项目早期明确阐述项目目的，项目小组在承当项目时将更可能获得支持。    业务流程分析   &#

11、160;业务流程分析包括：    ? 对当前业务流程的理解    ? 辨别出流程的关键环节来支持公司的业务目标实现    ? 业务流程的差距分析    ? 开发未来的或将有的业务流程        为了理解一个公司如何运作，首先最重要的是理解当前的运作流程。通过画出流程，项目小组能够理解企业内人、技术、流程之间的交互。业务流程分析涉及到对当前的业务流程的分析

12、，常常这些业务流程是非文档化的，通常的流程只是企业员工日复一日的进行。例如：销售如何定运期，订单如何处理，一个应聘者需要完成那些文件，在受雇期要完成那些档案？财务完成月度结算需要那几步？        面谈访问是项目小组获得这些问题答案的主要手段。当然面谈应该按照事前精心设计的顺序来执行访问，一般流程如下：    高层>' target='_blank' class='infotextkey'>管理人员  

13、;  访谈必须定位在战略和整体目标，也借此定下组织中还有那些人需要被访谈    中层>' target='_blank' class='infotextkey'>管理    访谈应用定位在和项目相关的问题，整个业务如何流过他们部门，那些人在处理过程中扮演怎样的角色    员工    对员工的访谈是最关键的，因为在绘制业务流程图时，他们可以提供最详细的细节。在访谈员工

14、的时候，必须搞清楚他的任务是从那级传下来并且下一工序传给谁，流程是水平还是垂直的。员工利用那些系统来完成他们的工作，判断那些工作必须手工完成。应该搜集执行流程的实例和表格。为了完成这些，项目组必须搜集足够的数据来为业务流程的描绘服务。        项目组应该化最多的时间在访谈员工上。因为控制和报告机制的分散，运作流程常常是复杂的。当业务流程被清晰的绘制出，就可以客观的分析并找出可以改善的机会。另外，项目组也可讨论那种流程适合企业，当前的流程如何改造以适应理想的业务状态。   

15、0;    项目组辨别关键环节，将明确这些环节如何使得流程生效。关键流程的确定可以是参考行业领袖企业、出版的研究报告、其他行业的公司研究报告等等资料。在研究关键环节后，项目组应该回头对被访谈者再进行“理想的流程”的开发。每个组织都有自身的生存的业务约束，这不允许他们照本执行理想的流程。因为这个原因，必须进行差距分析来定义针对本组织的最适合的可行方案。        差距分析将画出公司当前业务流程的薄弱地区，这些薄弱的环节可能是以下任何原因造成的  

16、0; ? 缺乏技术支持流程    ? 缺乏资源支持人工流程    ? 基于>' target='_blank' class='infotextkey'>历史和遗留的效率低下的流程        差距分析的产生的成果是建议书，这个文档定义了流程的改善，即包括人的、也包括技术的。基于差距分析，决策反映在建议书中，项目组可以开发未来的业务流程图。   

17、 需求定义    需求定义包括以下内容    ? >' target='_blank' class='infotextkey'>管理需求    n 预算、时间表    ? 报告需求    n 功能需求    n 表述业务需求    ? 技术需求 &

18、#160;  n IS标准    n 数据流图    n 系统界面        需求文档是评价最终解决方案的基石，项目组通过需求文档广泛和各方交流，辨认出重要的需求。需求的细节定义是关键的，许多公司没有开发特定的详细需求，结果可能是最后的项目使得很多人不满意。事情如何运作？组织想要他们如何工作？在访谈组必须回答很多这样的问题，>' target='_blank' class='

19、infotextkey'>管理层必须定义他们要达到怎样的目标，他们必须辨认关键的约束并分享他们对业务流程认识的观点。        >' target='_blank' class='infotextkey'>管理的需要    当通过访谈的过程定义需要，这些需求驱动最终的解决方案，项目组必须理解>' target='_blank' class='infotextkey

20、9;>管理层的需要和报告，预算、时间等。更多的是，当项目进展时候，必须维持和>' target='_blank' class='infotextkey'>管理层的常规的交流和项目进展与期望值的差距。        功能需要    是评估最终解决方案的基石，访问将帮助定义高层次需求用于广泛同系统目标交流。项目组应该基于未来的业务流程设计功能需求。一个常犯的错误是公司直接购买软件将当前的流程自动化，而没有事先考虑这个流程是

21、否应该被改善和更有效的执行。这样的自动化提高流程的速度，作一个错的，效益低的流程并不能导致理想的结局。        决策点：自建或者购买    一旦公司的项目组理解了全部的需求，他可以对是自建还是购买系统作出决策了。这里有几个因素在项目组作决策时必须考虑：    ? 市场解决方案提供者可选吗    ? 如果选择市场解决方案提供者那么成本和效益比如何    

22、? 公司有人员和技术能力在内部自建系统吗    ? 公司自己开发解决方案的成本和收益比如何        总的说，如果市场在特定的商业领域有许多供应商提供产品和服务，并且价格在公司项目预算之内的，购买是推荐的方案。然而如果这个领域没有足够的可选的方案，公司自己建设是更保险的方案，并且更加易于维护。自己解决方案总的来讲更加能迅速的满足快速变化的业务的特定需要。    软件选型    一旦公司决定购买

23、一套解决方案，项目的重心就由内部转向外部。挑战主要是找出正确解决方案一个满足项目业务、技术和预算目标。软件选型的工作包括以下：    ? 供应商选择    ? RFI项目招标书    ? 供应商列表    ? 评分卡    ? RFP投标书    ? 供应商论证计划        

24、;并不是每个项目都需要执行所有的步骤，例如一个相对小的项目，只有很少几个知名的供应商，可能就不需要RFI。项目组首先要做的是找出潜在的几个供应商，许多项目集中在软件本身的评价，而忽视对软件提供公司的评价。这是一个高风险的举动。项目组必须首先研究供应公司的财务稳定性和可靠性。如果公司购买一个比较大的软件系统，供应商必须能够提供系统的升级和维护，以保证软件系统的运作。项目组应该设计和分分发RFI给供应商，邀请他们根据他们的兴趣作出反馈。下列内容应该包括在RFI中：    ? 项目范围（预算、时间）    ? 主要的功能

25、需求    ? 技术需求        RFI将只被送到有兴趣做此业务的公司。精力集中在那些可能的供应商是很重要的，这将避免公司项目组花费不必要的时间去和其他可能性不大的供应商谈判。项目组应该基于RFI的要求列出一张短的项目供应商的清单，邀请他们来演示软件。这张表单应该包括46家供应商，邀请太多的供应商参加将提高项目的成本和拖延项目进展的时间。更重要的是项目组成员可能在看太多的演示之后失去注意力       

26、; 下一步，项目组应该开发一个评分表来评价各个供应商的建议。这些评价必须在每个供应商演示之后立刻完成。这些积分表应该包括功能和技术的细节需求。每个条目应该清晰可测。        RFP是一个详细文档，供应商必须在在规定时间内作出反应。项目组在RFP阶段的目的是搜集重要的信息，公司如何与被选中的供应商合作，包括：    ? 细节的财务信息    ? 软件定价    ? 技术平台信息

27、60;   ? 供应商支持和维护    ? 实施成本和可用的实施资源        常常有企业要求厂商作脚本方式的演示，对所有供应商的软件系统用一套公司的数据进行计算。在不同供应商用同一套数据进行演示，软件的一系列的功能可以得到较好的对比基础。    供应商>' target='_blank' class='infotextkey'>管理 

28、60;  供应商>' target='_blank' class='infotextkey'>管理包括以下内容    ? 供应商演示>' target='_blank' class='infotextkey'>管理    ? 评分卡和建议需求分析    ? 供应商解决方案排名    ? 谈判软件本身和软件的实施&#

29、160;   ? 合同谈判        对于项目组来说保持对供应商演示的控制是很重要的，项目组必须对供应商们分配相同的时间，不允许那家超时。对供应商必须注意评分表中每项项目是否被演示了，在演示结束后必须就评分表中的每项条目给出评分。在下一家供应商开始演示前，必须查看所有评审人员分数是否打全，不能等到下一家开始有比较的意味存在再主观打分。项目组必须用评分卡和RFP作为选择软件的基本标准，评分卡自然是质量的标准，而RFP则是资格和质量的综合。    项目组要对供应商作出排名，至少要排出一、二名。确保公司如果不能和第一候选供应商签约的，可以有其他选择。而且要注意每个供应商解决方案的差异，特别在两个供应商的方案的成本存在很大的差距的时候。        下一步在谈判的时候项目组要注意两点：