系统架构设计笔记（29）—— 项目的选择与提出
组织在信息化的过程中，可能基于各种动机提出系统项目的建设，有关人员要根据这些动机，提出和确定信息系统的工作范围，确定项目立项，提出系统选择方案，给出选择结果。
1 项目的立项目标和动机
企事业单位在其自身的经营管理过程中，对于项目的立项建设可能具有多种动机，通常可归结为下列几种。
（1）进行基础研究并获取技术
此类项目通常由大学院校或企业集团的战略研究性部门提出和实施。小规模的研究组织可能仅仅是企业中的一个研发部门或从事研发工作的团队；中大规模的研究组织包括研究所或研究院这种独立建制的单位；大规模的研究性项目可类似于国家 863 计划等跨行业 、 跨地域协作的国家级重大项目立项。
（2）进行应用研发并获得产品
此类项目通常由企业进行立项和开发，企业立项的基本动机通常是为了得到应用软件产品并向目标客户群进行销售从而获取利润等。产品一般会基于某类特定客户群体的需求进行设计，有明确和具体的研发目标需求，有严格的时间限制 、 资源预算等，因此可归入 “ 应用研发 ” 型软件。
应用研发型软件通常具有一定的通用性，客户广泛，既可能是面向个人消费者的工具软件（例如Office 、 杀毒软件 、 游戏软件等），也可能是面向特定领域或行业的工具软件（例如 SQLServer 数据库 、 AutoCAD工程绘图软件 、 RationalRose这样的建模工具软件等）。
（3）提供技术服务
对此类项目进行立项的企业通常能向目标客户群提供比较全面的技术服务而不是单一的软件产品。因此企业的服务范围可能包含提供技术和解决方案的咨询 、 利用现有产品进行系统集成和服务 、 面向特定客户的软件项目定制开发 、 对现有的软件系统进行升级和改造 、 提供软件应用相关的技术支持 、 服务和培训等服务中的一个或多个内容。
总的来说，此类组织通常会面向一个特定行业 、 具有相对稳定性的客户群体，通过提供一种综合性服务来获取市场价值，因此可以把此类公司看做 “ 服务 ” 导向的组织。
（4）信息技术产品的使用者
信息技术的使用者是最终客户。对他们来说，软件项目的立项动机既不是为了得到软件产品而进行销售，也不是为了提供技术服务，而是通过购买产品或服务来得到使用价值。例如：一个消费者购买了绘图软件是为了存储和处理个人数码相机中的照片；而一个企业通过实施 ERP （ EnterpriseResourcePlanning ，企业资源计划）可能是为了达到生产能力的控制 、 生产计划科学性 、 提高管理水平 、 获取新的决策能力 、 降低库存成本 、 提高资金周转率 、 建立面向市场订单生产方式等目标，并期望通过这些目标的实现来增强企业竞争力 、 获取更大的市场份额。对信息技术的使用者来说，信息技术是一种手段，同时也是一种成本。如何用最小的成本和风险获得满意的效果是客户最关心的问题。
2 项目的选择和确定
系统项目的选择至少包含两种实用性目的，一个是软件开发公司在诸多的产品方向中选择适当的方向进行研究和开发，另一种是客户从诸多的产品中购买适合自己需要的产品或选择适合自己需要的技术方案进行实施。与系统项目提出的问题一样，并不存在一个统一模式进行系统项目的选择和取舍，但可以提出进行项目取舍和评估的若干原则。通过使用项目取舍和评估的原则，可以逐步排除那些不符合需求的项目定义，从而找到比较适合的项目或产品开发方向。
2.1 选择有核心价值的产品/项目或开发方向
这个策略关键在于确定什么样的系统项目是有价值的。由于立项单位所处的行业 、 在行业中的位置 、 立项目标等因素不同，对软件项目的价值判断也不同。但 “ 有核心价值的软件项目 ” 通常总是和企业或客户的核心业务相关的。
美国哈佛商学院的著名教授 MichaelPorter 曾经在他的 《 竞争优势 》 （ CompetitiveAdvantage ）一书中提出了 “ 价值链 ” 的概念，价值链把企业运作的各种活动划分为产品设计 、 产品生产 、 产品营销和产品应用等独立领域，企业的价值链也可以进一步和上游供货商与下游买主的价值链相连，从而构成一个产业的价值链。如果以 “ 价值链 ” 的观点来看待软件产品或项目，软件是作为一种技术服务手段被运用到企业业务的价值链上的，通过实现价值链中的关键业务的信息化从而最终改善客户单位的企业质量，同时也使软件开发公司获得现实的经济利益。
因此，在企业或客户经营活动中对价值链增值最大的部分，就是企业或客户的 “ 核心业务 ” 。 针对核心业务的信息化产品或项目，通常都是具有高价值的，也可以说，所谓的 “ 行业信息化 ” 的关键就是该行业中这些核心业务的信息化改造。例如：
（1）对生产制造业的企业来说，生产计划 、 库存控制 、 实现面向订单的生产就是核心业务，无论实施 ERP 还是小规模的 MIS 系统，针对这些部分的软件功能总是被客户认为是最有价值的。
（2）对于金融保险行业来说，由于保险公司的基本职责是分摊风险和补偿损失，所以一般要求保险公司有足够的分散风险的能力。因此，管理保单数据的业务系统 、 评估风险的定损系统等就是非常有价值的软件系统。
（3）对于教育行业来说，因为学校的核心职能是教书育人，因此与教研 、 教学 、 考试 、 评价等业务相关的软件系统，以及支持上述业务开展的教育资源库软件 、 电子图书馆软件等就是高价值的软件系统。总之，选择软件项目，必须首先考察软件应用的行业 、 业务和目标，以便判明要建设的软件项目价值。
2.2 评估项目风险、收益和代价
在判断出一个潜在的软件项目后，还应评估项目实施的风险 、 收益和维护付出的代价。对于开发产品进行销售的情况，主要评估的是产品的预期收益和为完成开发投入的各种资源（包括时间 、 人力 、 资金等），项目的风险主要是技术难度 、 技术能力 、 经济能力和各种资源是否能承担 、 是否是企业需要优先实施的项目 、 是否符合行业标准和国家政策规定（例如：在电子签章没有经过国家法律许可之前，使用电子签章替代手工操作可能是有风险的）等。
对于购买产品或技术服务的客户来说，还应该评估项目实施后对自身业务变更，组织机构和人员职责的影响，现有的业务流程和人员的 IT 技能是否能满足要求，是否需制定相关的系统维护 、 运行规约和规章制度等。而项目实施的实际开销，除购买产品或服务的开支外，通常还包括各种系统维护 、 改进 、 培训，招聘新职员，变更业务流程等各种应用方面的开销。以总持有成本（ Total Owner Cost ， TOC ）来评估信息化的代价才能比较准确地得到项目的实际代价。
评估项目风险 、 预期收益和代价后，可筛选掉多数不符合企业要求的建议项目。
2.3 评估项目的多种实施方式
对于已经确认有价值 、 并且有能力开发的软件项目，则可以进一步参照企业现状考察项目的实施方式。这种实施方式通常既包括了前面对项目风险 、 预期收益和资源开销的评估，也包含了企业对现阶段经营目标和现有资源如何合理运用的考虑。这个过程通常由项目的负责人和企业中高层经理进行决策，决策结果决定了项目的实施优先级及具体的实施方式。
需要说明的是，企业完成软件项目的方式并不单纯限制于自己组建开发团队进行软件项目或软件产品开发的策略。根据具体情况不同，还可能使用诸如转包开发业务给外部公司 、 直接 OEM （ Original Equipment Manufacture ，原始设备制造商）软件产品并进行系统集成 、 购买关键技术并进行 “ 软件集成 ” 方式的开发 、 完成技术方案和设计，然后寻求外部公司进行编码等各种方式。对这些项目实施方式的取舍，主要依据依然是对项目风险 、 收益和资源开销综合平衡的考虑。
2.4 平衡地选择适合的方案
人们在选择可行的方案时，总是希望得到高质量 、 低成本的产品和方案。软件开发人员通常也很愿意在产品开发中，向产品加入创造性的内容。另一方面，客户单位在面对诸多的投标方案时，会听到各种各样关于技术先进性 、 快速开发 、 产品质量稳定可靠 、 价格如何低廉 、 推荐的方案有多少成功应用等宣传。然而：
（1）新技术可能意味着未来更多的变化从而导致风险，也意味着未来产品的使用者需要更多的学习和导入期，而采用成熟的技术则可能享受不到新技术带来的好处。
（2）不基于某种快速开发技术或平台构造的产品可能会延长项目开发时间从而导致更多的开销，但基于某种平台的产品又可能使得用户未来 “ 绑定 ” 在某种平台之上，减少未来的自由选择性。（
3）不考虑系统的扩展性则很可能在业务变更时，会受阻于已经实施的 IT 设施，但过多考虑系统的扩展性，软件接口通常就需要花费较大的力气进行设计，那么用户是否在当前的购买中为一些自己并不需要的特性多支付成本？尤其在软件技术高速发展的今天，当用户期望进行系统升级的时候，常常会发现原来的计算体系已经早就被开发单位淘汰和抛弃。
（4）价格低廉的产品可能具有好的质量，也可能有些功能并不那么让人满意，而最重要的是，当关注这些具有先进性 、 低成本及拥有众多成功应用的产品或方案的时候，项目的选择者容易失去对自己目标的关注，即这些先进技术或宣传的产品特性是否确实是自己需要的？
事实上，对性能的要求常常是充满矛盾的，任何时候都不存在一个完美无缺的方案，只存在一个对当前的项目目标相对比较适合的方案。项目的决策者必须从最终的项目目标出发，判明各种功能或性能的重要性和优先级。在抛弃明显存在问题的 “ 差 ” 项目后，选择项目的基本立场应该是 “ 适合 ” ，而不是尽可能的 “ 好 ” 。（实际上任何超出预期设定目标的 “ 好 ” 性能，通常都意味着更多的成本。）
更进一步地看， “ 适合 ” 的方案就是平衡考虑开发单位利益和客户满意度的方案。图 1 是 Noriaki Kano 提出的顾客质量模型图，要求质量是客户认为产品应该具备的功能或性能，实现越多客户会越满意；假想质量是客户想当然认为产品应具备的功能或性能，客户并不能正确描述自己想当然要得到的这些功能或性能需求；兴奋质量则是客户要求范围外的功能或性能（但通常是软件开发者很乐意赋予产品的技术特性），实现这些性能客户会更高兴，但不实现也不影响其购买的决策。
显然，项目开发方更多考虑的是项目风险和回报。而客户更多关心的是成本和购买后的满意度。好的方案必须平衡考虑这些因素。系统分析师应尽可能用技术手段来平衡这些彼此对立的要求，保证在项目预期投入资源可接受的范围内，尽量实现客户要求质量对应的功能和性能 、 发掘客户假想质量对应的功能要求并进行沟通确认，但按自身所服务企业的经营目标平衡考虑客户兴奋质量的实现策略（是努力提供兴奋质量的功能 、 争取忠诚的客户获得远期潜在的收益，还是削减这些功能 、 以便使项目的成本最小化）。
系统设计师常犯的一个错误，就是用自己对技术的兴趣产生的兴奋质量，来替换客户最基本的要求质量和假想质量。而企业经营者常犯的错误，则可能是对客户提出的合理要求质量视而不见；或者走向另一个极端，不加区分地把一切未经评估的假想要求质量不断指派给软件开发团队。这些都是错误的做法。
3 项目提出和选择的结果
系统项目提出和选择的结果，最终会以 “ 产品 / 项目建议书 ” 的方式来体现。
典型的应用场景是：
（1）在投标项目中，产品 / 项目建议书通常是乙方提交给甲方竞标方案的一部分；
（2）企业单位在确立了要开发某类型产品后，对该产品进行多角度的评估，最终项目立项人向上级提交供决策的建议报告的主要内容就是 “ 产品 / 项目建议书 ” 。
产品 / 项目建议书是一个包含多种综合内容的报告，涉及的范围通常要比 GB8567-1988 标准中规定的标准—— “ 项目可行性分析报告 ” 的内容更全面。在项目建议书中，可能包含如下几个部分：
- 用户单位、项目或产品的立项背景、需求来源和目标性的介绍；
- 用户的内外部环境、组织机构、现有的 IT 设施情况等；
- 用户的业务模型和业务规划；
- 预期要建设的技术系统在用户业务中的位置和作用；
- 信息化后的用户业务模型、软件应用方式、相关的部署环境、运行规则、管理规范等；
- 为实现信息化业务模型，技术系统的产品需求定义（功能、性能、约束）和部署方式等；
- 产品或项目的技术框架；
- 项目的要点、技术难点、主要实施障碍等；
- 项目或产品的可行性研究结果；
- 项目可选择的实施方式、组织方式、沟通和协调机制等；
- 项目的资源范围和预算（人、财、物、时间等）；
- 项目的成本/收益分析；
其他项目建议书可能包含的内容，或以单独文档列举的内容可能包括：
- 项目风险及影响评估；
- 项目进度计划；
- 项目质量计划；
- 项目过渡期资金的获得方式、财务计划；
- 产品或项目的商务模式、盈利模式论述；
- 同类产品或公司的市场调查结果，以及竞争性比较；
- 企业成功案例、资质等；
- 商务条款或供应商/客户合同；
项目建议书标志着项目立项和选择阶段性工作的完成，一旦项目建议书被批准通过，项目即可进入正式的开发准备和实施阶段。