1.1       招标书中的思考

“全新的招标书范本”中提供的招标文件的写作规则是比较完善的，但还是忽视了项目完成前的验收过程的要求。它不是一项普通的要求，而是作为一项企业信息化的标准体系中的“验收标准”。这是一项强制性标准，所有参与招标的公司都必须明确地表示对这一标准的认同。

当然，验收标准并不是强人所难，它是根据信息系统的特点而设计验收工作流程与规则，它具有一定的科学性。它强调，验收是一项组织性非常强的工作，它要有验收团队，要有验收流程，要有验收的基础数据，要有验收的测试用例，要有验收的测试大纲，要有各个功能和流程的验收报告，要有验收测试结束后的验收总结报告，所有的验收过程结束后，双方的负责人必须签字认可。至此，验收工作才算完全结束。

我曾见过几个信息化战略咨询的项目，在战略咨询的报告中，已经明确了信息化项目的验收标准。其中，一份验收标准已经制定的非常细致，不但有标准而且有范例，在标准中写道：

系统验收测试流程标准

1.          术语约定

Ÿ              测试用例

测试数据及与之相关的测试规程的一个特定的集合。它是为了特定的目的（如考察特定程序路径或验证是否符合特定的需求）而产生出来的。

Ÿ              测试集

Ÿ              测试用例的集合

Ÿ              测试规程

对给定的测试，就其建立、运行和结果估计所作的详细说明。常常把一组有关的过程组合起来形成测试过程文件。

2.          测试流程

当项目合同生效时，系统实施方应与用户方共同制定本项目的验收标准。标准中应包含功能、性能、易用性、可扩展性、稳定性、可维护性等多方面的指标。

当实施方提交“项目验收申请报告”后，双方应根据“需求分析报告”制定“验收测试计划”。该测试计划必须经过双方审查和批准。如果，企业信息化项目聘请了项目管理公司或咨询公司，那么上述测试计划的审批，将由三方共同负责。

3.          测试计划

                参与单位

测试任务

实施方

用户方

项目管理方

测试准备阶段

制定测试框架

收集、验证、完善系统设计、用户需求说明

测试方案制定阶段

确定测试类型

计划测试资源

建立组织机构和控制过程

制定测试内容（编制测试用例）

计划测试时间

评审测试方案

测试执行阶段

执行测试方案

跟踪测试状态

解决问题

测试总结阶段

总结测试结果

结论

A-裁决，测试活动的最高决策层，批准测试活动或解决疑难问题。

L-领导，测试活动的负责方。

E-执行，测试活动的执行方。

S-支持，不直接参与测试活动的执行，但提供支持。

4.          测试过程

Ÿ              执行验收测试

Ÿ              运行测试用例

Ÿ              判定结果，针对每一个测试用例，利用测试用例中描述的测试期望结果，来判定验收测试活动是通过还是失效。将测试结果记录在测试用例管理工具的数据库中（如果存在的话）。失效的情况可分为下面几种：

Ÿ              测试数据或者测试用例详细说明书的错误

Ÿ              改正错误，将改正错误信息记录在测试日志中，并在测试总结报告的“活动总结”中记录，然后重新运行该测试。

Ÿ              测试环境的错误

Ÿ              修正测试环境，并且记录在测试日志中。在测试总结报告的“活动总结”中记录，然后重新运行。如果测试环境无法修复，必须记录无法修复的原因。

Ÿ              编码（实现）错误

Ÿ              需要在测试日志和“测试总结报告”中记录。

Ÿ              设计错误

Ÿ              需要在测试日志和“测试总结报告”中记录。

5.          评估验收测试。测试计划和测试规格说明书的变化情况必须记录在测试总结报告中，并且要说明每次变化的原因。必须提交验收测试成果和相关测试文档。

6.          当验收测试符合测试完备性以及满足用户方的质量标准时，各方项目负责人签署“验收测试报告”。

这只是一份验收过程的测试大纲，它并未包含具体的测试细节，而在招标书中必须提供非常详尽的各种测试文档。只有这样，这一测试要求才变得具有约束力，否则还将处于不确定状态。

1.1.1          招标书中企业需求的变相思考

到目前为止，信息化项目招标书的写作并无一定之规，每一位信息化主管都可以根据自身的情况设计不同的招标书写作规范，但无论怎样改变，都必须把握一点：强化招标中的需求内容的基础上，提出完善的约束机制。这样才能够避免在未来的工作中出现无法规避的风险，下面是另外一种招标书核心内容的写作方法，在这里可以作为一种参考模式。读者在阅读后，可以发现这两种方式从实质上讲没有太多的区别，只是一种写作方法的变形。

1   信息化项目的有效表达

1.1      语言与规范

1.2      目标与范畴

1.3      时间与地域

2   信息化需求的有效表达

2.1      管理流程

2.2      管理规则、算法、制度

2.3      管理难题与提升的需求

2.4      管理和控制要求

2.5      企业的现有单据与表格

3   系统网络体系需求的有效表达

3.1      服务器(主机)系统需求

3.2      操作系统需求

3.3      数据库需求

4   网络系统需求

4.1      安全需求

4.2      效率需求

5   实施要求

5.1      组织与人员

5.2      经验与技能

5.3      态度与沟通（表现出文化色彩）

5.4      计划与管理

5.5      客户化过程与实施衔接

5.6      实施优秀案例提供

6   验收要求

应用系统验收标准

6.1      系统目标达成率

6.2      流程与规则

6.3      效率与准确性

6.4      安全与防护

网络体系验收标准

1.1.2          范畴、时间、地域对投标的影响

范畴

我们众多企业的信息化过程是突发和非理性的，大多都是没有确定信息化内容的前提下，仓促地向企业的经理人提出了一些全新的项目名词，诸如ERP、CRM、物流、供应链（SCM），在简单陈述了这些名词的大致涵义后，企业经理人大多都会体现出绝对权威，要么否定、要么同意。要知这些涵义是否真实，是否信息化主管详尽地作了介绍，是否能够将企业所需要上的项目范畴一一陈述清楚，这只能够看主管对企业信息化理解的程度了。

显然，大多数情况下经理人并不太清楚这些名词的实质，只能是囫囵吞枣地在心中存留一些大概的记忆。由此产生的信息化项目存在盲目性几乎是一种必然。今天在总结许多项目失败的经验和教训时，总是免不了加上这一条。

本书中，笔者总是试图通过不懈的企业需求的调查与研究来避免这种盲目，调查的直接结果，并不是试图说明ERP或其他一些软件的名字，而是企业真实的需求与管理的需要。通过信息化主管对企业真是需求的了解，希望他们放弃原有的、固有的对所谓的ERP等各种类型标准软件的需求。站在企业需求的立场上去做事情，去选择软件。至于软件叫那种类型的名字并不重要。

一旦ERP这类标准的名字没有了，主管们就必须要搞清楚自身企业的实际需求，在此基础上才能建立完整的信息化范畴，这个范畴就是在招标和投标中必须关注的重点。其他的一切都是为实现这个范畴和系统目标的达成所作的努力。

这就是信息化范畴的真正含义，也是项目目标的基础。它远比让主管们去解释那些无法搞清楚的软件名词要实在得多，没有了软件名词的束缚，主管们更能够集中精力关注企业的现实，也更能够让经理人明白，你是在实现一个抓住了企业管理灵魂的软件应用。

时间——项目周期

现在的企业经理人对于时间的感觉，已经超越了我们的想象。产生这种感觉的第一个来源，是企业间竞争的压力和客户压力，经理人总是希望通过一个快速的信息化运作，来缓释这种压力。为此，他们总是自觉与不自觉地给项目下了一个时间的指标。这个指标在确定之前，经理人也会非常聪明地征求主管们的意见，但这种征求并不是在轻松地环境和状态下完成的。经理人大多会在办公室征询项目完成时间，主管们此时一般都很难做出一个非常明智的分析，自然会更多地顺从企业经理人对项目时间的看法。

这产生了什么呢？即便需求定义、需求范围定义的完满，软件商的软件产品选择的恰到好处，实施商的经验、能力和责任心足以支撑这个项目的实施，可还是造成了项目周期的拖延。这是国内信息化运作过程中的，项目实施周期定义过程中，产生了本不应该的忽视科学的时间周期、项目计划、项目人员和相关的投入这些因素。

这种现象在我们的信息化工作中，几乎每个项目都会有这种现象的存在。2003年7月25日，曾经有一篇《首钢ERP考验软件弹性》的文章，在文章中明确提出项目分三个阶段完成，大致每阶段需要花费一年左右。笔者无法清楚这个计划是否是经过严格的企业能力、实施公司能力、软件适应性调查后，所推导出的结论，还是一相情愿的主观预想。

在研究了首钢的ERP所涉及的范畴后，不难发现，项目每个阶段所涉及的内容是复杂的，无论是第一阶段的业务流程的改造，还是第二阶段的周边众多内容的信息化，直至第三阶段的业务管理信息化。这里面的任何一项工作，对首钢而言都是一次从未遇到的挑战，而这些挑战最大的，不是媒体所预想的第三阶段，而是彻头彻尾的第一阶段的管理变革的企图。

信息化推进过程，如果我们的经理人或信息化主管们，考虑的只是积极的方面，而忽略了事务推动中所存在的消极因素。那么，这样所设定的时间就显得缺乏依据，当然也会缺乏在这样的周期下，完满完成的可能。

一些人可能对此不以为然，它可以让我们固执地认为：大多项目都是这样确定时间周期的，可还是依然完成了，即便是作者曾经参与过的许多项目，也是在这种状态下完成的。

这是不是说这是对的呢？学习过项目管理的人员都会知道，如果一个项目是处在一个许多内容都是未知的情况下，那么这个项目充满风险。是的，我们过去许多的项目是完成了，但是在哪种情况下的完成，是100%的完成、还是60%的完成？如果，所有的人都好好回顾一下过去的所谓“完成”的水份，就已经明白了我们以前所操作的许多项目，是在无序中、甚至可以说是凌乱之中，实现了并“不真实”的完成。

而这种完成的背后，一定存在两个因素，第一是项目组成员的努力和拼搏，第二是具有一位卓越的项目经理。没有这两个因素，不要说完成，就是初见成效都已是很难！

我们所走过的路并不平坦，过去的许多信息化经验，也并不完全真实。那么这些不真实的内容，一定需要被更加科学化的方法所替代，“摸着石头过河”的方式必须被快速地抛弃，否则，大多企业根本无力品尝失败，信息化项目根本输不起。

地域----另类范畴

许多企业并不太关注信息系统的地域特征，宁愿把注意力集中于软件的功能上，也不愿意关注企业信息化软件系统所涉及的地域。他们不但不关注，甚至可以说是忽略了软件适应地域需求的一个基本特征。

国内一家著名家电企业，在1999年底，投资5000万元，选择了国外著名大型ERP软件。两年过去了，这家企业已经全部启用了所购买的财务管理（FI/CO）、销售与分销（SD）、物料管理（MM）和售后服务管理（SM）4大业务系统。但是令人遗憾地发现，这一系统在使用后，并不是面向全国的销售机构（名字叫销售与分销），尽管投资如此巨大，但是销售与分销业务系统竟然还需要全国各地的销售公司，通过传真或电子邮件的方式，把每天几千张提货单传回来，再由总部相关人员将数据输到主机系统中去。

为何会产生这种奇怪的现象呢？一种现代的软件系统，却竟然“笨”到了需要“传真”的帮助。这不正是说明两大问题嘛，一个是在选择软件时，缺乏对软件系统的详细了解，并不知道这种ERP软件是否有能力支持分销，即便它的名字有分销的概念。另外一个方面是缺乏理会西方人的分销软件购买方式，并不知道外地的销售公司如果需要软件，就必须向软件厂商单独支付客户终端软件的使用费。

这家著名家电企业的人员采用了典型的东方式的思维，而忽略了软件公司的西方背景，一旦使用后才发现，这个“标榜的分销”是一个完全的“假货”，它根本无法支持免费的分销业务，由此就产生了这个案例的怪象。但这种怪象在今天的国内信息化过程中，还是依然存在，非但没有减少，而且还在迅速的增加，这导致了国内信息化项目的“虚火”上升。所有的人都认为“OK”，可实际上是不少项目所涉及的软件都无法完全满足企业的地域特征的需求，它根本无法支持企业面向不同地域管理的需求，而只是在一个独立的封闭环境下应用的体系。

当然可以看到一些软件公司，为了适应企业规模扩大后的管理需求，利用起了互联网技术实现了在原有体系上的突破，经历了这种突破后的软件，已经可以适应企业对分子公司管理的需要，这种经过C/S与B/S两类软件捆绑后的系统，在网络时代似乎还有着一定的生命力。

结论

范畴、时间与地域从表面上看来，它对项目并没有直接影响，而事实上，现实的失败，已经告诉人们必须关注这些细小的内容，不要因为它“小”而忽视它。我们的习惯性的“宏观”思维，往往让经理人和项目负责人关注于“大”方面，但独独地忘记了没有许多“小”而哪里会得到“大”的道理。

遗憾的是，范畴、时间与地域的所谓的小，并不是真正的小，而是信息系统建设过程中的“大”，而一旦把“大”当作了小，那么，这种所犯的错误将会变得日益严重起来。

1.1.3          “成功”实施的思考

任何一个信息化项目都必须经历“立项、论证、招标、投标、评标、谈判、购买、实施、交付、维护”等阶段，对这些阶段的划分本无定式，但大致细化一些是可以按照这种方式来分的。

在企业启动项目的过程中，实施阶段是历时最长、最复杂、矛盾最多、难度最大的一个核心环节，难怪现在市面上流行一句话：“三分软件，七分实施”，尽管笔者对这种提法并不完全赞同，但是对于它强调实施的重要性这一点还是认同的。

重要归重要，而如何去将重要的内容变成实际的行动是值得所有的信息化人员思量的，要了解一家实施机构的能力，必须要掌握一些方法。可以看到在此之前许多的信息化的标书的要求也罢，项目的建议书也罢，对于它的要求也仅仅限于一种常规性的内容，由此可以看到，无论实施机构大小，都会提出自己所设定的实施组织结构、实施的计划和所谓的方法论。

而这些都是静态的，它是不能够反映出实施机构的能力的。为此，在本文中所提出的方法，彻底地改变了原有的对于实施机构静态方面的要求，而将重点转向了实施机构的动态能力。它在建议书的写作要求中写道：

1.1.1          咨询与实施满足度

1.1.1.1             组织与人员

1.1.1.1.1  个人能力考察方法建议

1.1.1.1.2  组织能力考察方法建议

1.1.1.1.3  方法论的掌握能力

1.1.1.1.4  投标方项目管理组织建设思维

1.1.1.2             咨询与实施方法论

1.1.1.2.1  咨询方法流程与结构

1.1.1.2.2  咨询调查与分析方法

1.1.1.2.3  咨询评估方法

1.1.1.2.4  咨询与改进方法

1.1.1.2.5  方法论工具

1.1.1.2.6  方法论文档考察方法建议

它强调考察项目核心实施人员的个人能力，考察实施人员的组织能力，考察实施项目小组的方法论的掌握能力，重要的是方法论的灵活应用能力，最后是项目核心人员的思维能力。没有这些能力的考察，一个公司即便有再好的实施方法论，也只能够是一堆废纸。

同样，它也强调对咨询与实施方法论的研究，每个公司都会号称有方法论，而这些方法论表达的实质是什么？这个实质是必须要掌握清楚。现在有许多著名的咨询公司，一旦你翻开他们给企业所作的咨询报告，你会豁然发现，许多报告中的内容是缺乏科学与现实的结合，可以看到粗糙和非职业化，那么这样的咨询公司的方法论只是一个说辞，而并不能够称之为方法论，甚至可以说它不具备方法论的一些基本特征。

所以，通过对组织和个人能力的考察和对某一企业现实方法论应用的考察，你就会清楚地明白咨询与实施机构的实际能力，这也就会成为你评判的基础。

1.1.4          招标书对合同的影响

许多主管们可能会对招标与投标书提纲的内容提出质疑，为何与过去曾经使用过的招标与投标书的写作方法多有不同？为何需要如此地设计招标书和投标书的写作要求呢？对这个问题的回答，可以很好地解释设计的初衷和设计的目标。

现有标书的写作方式已经不适用于现在的信息化需要了，所有的主管们不难发现招标书、投标书与合同之间缺乏必要的逻辑关系。在经过了2、3个月的招投标过程后，所得到的各个公司提交的投标书和建议书的内容，往往无法成为签署合同细节的依据，那么这样的招投标过程就显得失去了原有的意义，变成了为招标而招标，而不是为需求而招标，为实现信息化成功而招标。这样的立意下，招标、投标已经成为了信息化过程的一项点缀。

现实已经让主管们开始思考，需要建立一种有效的招投标书的写作方法，让招标过程所形成的文字成为合同中的一个部分，只有这样才能够将投标者的承诺、投标者的工作方法、投标者的思考作为合同中的一个部分。同样，由于招标书中的企业需求和系统范畴的相对完整，也会成为合同中必须考虑的一个部分。这样的方式，极大地促进了招投标过程和合同谈判过程之间的逻辑关系，即：招投标过程是合同谈判的前趋。再也不会产生相互之间的脱节。

主管们一旦这样去思考问题，不难发现招标书设计上的原委。它强调一个信息化招标过程必须提供相对详实的企业需求，它要求包括：企业管理现状中的管理、流程、规则所产生的问题，要求包括现有的核心性流程和与流程相伴随的制度、规则和算法，要求包括各种不同类型管理人员的管理需求、控制需求、查询和分析需求。在企业的基本原始需求确定之后，必须提交一份较为完整的功能需求，这份功能需求和企业管理需求将会成为合同中的“企业需求附件”，它将成为一份原始的法律依据文件。

同样，在标书中要求投标单位全面考虑自身的实施能力和方法，它不但要有原有标书中所提供的组织与人员，还要求提供方法论和具体的实施案例。这种要求即可以起到阻止能力不足的投标单位的同时，也可以了解投标者的实际状况，而它的核心也是要求这些对咨询与实施能力和组织的内容作为合同附件中的另外一个部分。当然此类内容还会涉及售后服务的承诺，有关技术路线和开发规范等方面的承诺，它们一同构成了合同中的附件内容。

在建议书中的前6项中，已经对原有建议书的体系做了一个很大的调整，它不再是一个以投标商的建议书写作思维为核心的建议书，而是要求投标商回答6项必须回答的问题，这些问题的回答，将通过一条逻辑线路完整地导出投标单位的完整报价的同时，也会清晰地得到了软件投标单位的信息化体系的状况，而最终的目标就是要将建议书中的对于项目的承诺作为合同依据、和谈判的砝码。这样将迫使投标单位努力地担负起责任和承诺的法律义务。

因此，无论是招标、还是投标的文件，它的中心点除了选择一家可以合作的单位之外，还必须得到相应的法律和承诺的保证。只有这样，主管们才能够易于控制招投标的同时，更好地把握合同中的需求与法律内容。