IT售前咨询白皮书

1、【最新资料,Word版，可自由编辑！】目录2售前咨询及定位 .3售前咨询路线框架 .3.1计划与准备阶段 .3.1.1输入 .3.1.2工作内容 .3.1.3输岀 .3.1.4注意事项 .3.2业务理解阶段 .3.2.1输入 .3.2.2工作内容 .3.2.3输岀 .3.3解决方案阶段 .3.3.1输入 .3.3.2工作内容 .3.3.3输岀 .3.4项目商务阶段 .3.4.1输入 .3.4.2工作内容 .3.4.3输岀 .3.5项目实施阶段 .3.5.1输入 .3.5.2工作内容 .3.5.3输岀 .4理解客户业务 .4.1业务战略 .4.2业务模式 .4.3组织架构 .4.4业务流程 .4

2、.5作业程序 .5分析客户需求 .5.1软件需求层次 .5.2UML与相关模型 .5.2.1 UML 概述 .5.2.2用例模型 .5.2.3顺序模型 .5.2.4活动模型 .5.2.5类模型 .5.3用UML进行需求分析 .5.3.1确定系统边界 .532寻找参与者 .5.3.3寻找用例 .5.3.4寻找初始和终止事件 .5.3.5准备普通场景 .5.3.6增加变化和异常场景 .5.3.7寻找外部事件 .5.3.8编制复杂用例的活动图 .5.3.9组织参与者和用例 .5.4组织原型界面 .6编写技术方案 .6.1业务理解 .6.1.1项目背景分析 .6.1.2企业现状和业务架构分析 .6.1

3、.3问题定义与变革分析 .6.2需求分析 .6.2.1系统目标分析 .6.2.2系统边界分析 .6.2.3系统功能需求分析 .6.2.4系统性能要求 .6.2.5系统技术要求 .6.3技术方案 .6.4实施方案 .6.5运维方案 .6.6公司简介 .7关于企业架构 .IT、/一前言 到现在为止，我一直在问自己，你够格吗？ 懵懂地闯入了售前咨询领域时，我几乎不明白售前是什么、应该做哪些工作，只记得最初的工作是从投 标开始的。记得自己第一次独立承接标书任务时，整整用了三天时间才理出了一个提纲，然后用了十天 时间完成了方案的编写，很幸运的是公司中了那个标，从此就开始了自己的售前之路。在浑浑噩噩的头几

4、年，我的主要工作是针对公司现有的产品编写解决方案和演示PPT,以及进行项目投标活动（主要还是标书的编写和 PPT的制作）。在写方案的时候，针对客户关系管理、物流管理等系统， 我比较注重理论体系的学习，并把相关的理论体系应用到方案中（说明理论的框架，并如明系统与理论 的匹配度），这是我与公司之前的售前的最大区别他们习惯直奔主题阐述系统有哪些功能。 这大概是我对售前工作理解的第一阶段吧。今天回过头去看看那段过程，最大的欠缺有两方面：一是 售前的方法论，不能从全局的观点去定义售前的工作，采用方法论去指导自己的工作过程；二是理论与 实践的脱结，与客户接触较少，不清楚也不了解客户的实际问题，不能用理论框

5、架去实际地解决客户的 问题。事实上，当时根本不明白这些，甚至颇有些自得地认为自己还挺不错的，当然有时心情也挺复杂 的，毕竟售前咨询面临的领域太广了，明显觉得自己知识不够用。2004 年开始接触到了信息化规划，在不以为然其提交物的时候，也深深地被其方法论给震憾了。此 后，比较多地关注了信息化规划的路线图和方法框架，在售前咨询过程中会以一些信息化规划模版为参 照物，进行方案的编写。不可否认，起初生搬硬套的痕迹非常地明显，随着不断地学习和思考，慢慢地 较深入地了解了信息化规划的内容以及实施路线，同时也领悟到售前咨询方案的编写也可采用规划的方 法进行，二者的区别在于前者是基于全局业务的，而后者是基于局

6、部业务的。采用信息化规划的方法论 指导自己的售前工作，也算是对售前工作理解的第二阶段吧。后来自己开始带团队，为了培训团队中的新人，我尽量把自己理解的售前咨询的方法论教给他们，这过 程中也发现自己了解的内容也不是非常地体系。为了做好培训教材，上网查了很多资料，这才发现业界 对售前的称谓莫衷一是，对售前的职能和工作也没有统一的定义。而实际上，自己团队的工作也有些疲 于奔命的感觉，整天忙着应付来自销售的需求。混乱的现实促使我对售前职业进行了思考售前应该 是做什么的？售前应该怎么作？售前的出路是什么？售前应该具备哪些知识和能力了？ 在此谈点不成熟的看法。从客户价值视角看，售前咨询的主要工作应该是认识问

7、题（理解业务）、分析 需求和提供解决方案。在整个售前咨询过程中，目前主要的欠缺有二：一是缺少工作路线图对售前工作 的指导，几乎没有售前对工作推进路线有清晰的计划；二是解决方案应该如何编写，要写哪些内容有些 模糊。其实只要明白售前的主要工作是认识问题、分析需求和提供解决方案，方案的编写内容就清楚 了。在一番思考后，我决定编写一本IT软件应用售前咨询白皮书，本书的主要对象是为行业或为客户提供应 MIS 系统的售前咨询人员。希望通过本书能给刚入门的售前提供指导，对职业有疑惑的售前提供帮 助，也为一些资深的售前提供参考。在与很多优秀同行的竞争中，我已经在这个职业中走过了七年，深深感觉售前咨询领域的博大

8、精深和售 前咨询工作的巨大挑战，到目前为止，自己一直感觉未能切实地站在较高的高度为客户提出可行的解决 方案，这也是我一直置疑自己的原因。希望能用此书作为我七年工作的总结，同时也是自己提升的基础 吧。在此对所有在过去工作中给予我帮助的客户、领导、同事和朋友表示感谢。售前咨询及定位 售前咨询，作为销售人员的技术支持，其职责是以专业的方法理解客户业务、分析客户需求，将管理理 论、客户需求、 IT 技术和公司产品相结合提供解决方案，并将良好的公司形象、产品形象和服务能力传 达给客户，从而达到有效战胜竞争对手、促成签章并合理降低项目风险的目标。 近代学者王国维认为，“古今之成大事业、大学问者，必经三种境

9、界。”“昨夜西风凋敝树，独上高 楼，望尽天涯路”，是为第一境界；“衣带渐宽终不悔，为伊消得人憔悴”，是为第二境界；“众里寻 他千百度，蓦然回首，那人却在灯火阑珊处”，是为最终境界。这不只是做诗的境界，做学问的境界， 从事艺术创造的境界，也是我们生活的境界，事业的境界，人生的境界。 售前咨询之道亦然。售前是作为公司的技术代表，其主要职责是 协同 销售人员让客户接受公司的解决 方案。但如何提供解决方案，亦存在几种不同的境界。 第一重境界：从产品到方案。将公司的产品说明书修改成针对用户的解决方案，这一类售前咨询不在少 数，特别是一些作产品的公司。此重境界的售前咨询，可能比较了解自己的产品，甚至有相当

10、的技术功 底，也有良好用户展示和交流能力（当然如果这些都没有那就真的是一无是处了），但不能站在客户价 值角度理解产品，通过了解客户业务、界定客户需求，并说明产品对客户的价值。这是售前咨询的初级 阶段，个人觉得也是比较幸福的售前阶段，怎么说了，简单就是幸福嘛。 第二重境界：从需求到方案。通过不断地学习和总结了，有了自己的知识体系和工作方法论（自觉或不 自觉的），能站在管理咨询的角度采用各种方法去了解客户业务、分析用户需求，并提供解决方案。达 到此境界绝非易事，方法论、知识、技能和态度一个都不能缺少，应该说此重境界的售前咨询已经是比 较成功的假如没有下一重境界的话。此境界的售前咨询能从较高的程度对

11、客户进行影响，可承担一 些客户的管理咨询工作，如进行产品体系规划和产品设计。 第三重境界：全程商务推进。毕竟售前咨询的本质还是促进销售，因而在商务领域也必须有自己的思路 和想法。此重境界的售前咨询对于整个商务推进路线有着清晰的认识，能根据此路线图制定计划，并按 照计划在不同阶段影响客户，直至商务合同的签订，甚至延伸至售中领域。 基于上述的境界描述，不难看出一个优秀的售前咨询应该具备的能力：一是体系化的方法论（包括商务 推进）；其二必须具备较宽的知识体系，包括管理、技术和业务方面的知识，特别是要熟悉自己的产 品；三是良好的综合技能，包括各类工具的应用，如计划、调研、交流、方案编写、方案展示等技能

12、； 此外还需要强调的是态度。 一个优秀的售前，除了为客户提供价值外，也应该在公司价值链中找到自己合适的定位。价值链是指企 业进行的一系列符合特定模式的活动，或者说，价值链是企业生产的产品或服务增值的环节或链条，价 值链中的每项活动都增加了产品或服务的价值。从企业价值链看，价值的创造和传递包括三阶段： 选择价值，通过市场细分，确定企业的市场目标和价值定位； 提供价值，根据企业的业务战略，开发产品和服务，并制订企业总体营销策略； 传播价值，通过销售、促销及其他推广工作，将企业价值推向市场。 在企业价值链中，售前咨询可以通过市场研究影响公司战略选择，也可参与产品开发以提供价值，更多 的时候售前从事是

13、的价值传播工作。因而一个优秀的售前咨询应该在价值链的各个环节都要有所映射。 基于上述分析，可将 IT 售前咨询定位如下：价值选择的辅助者，辅助公司战略价值选择。 通过行业研究和市场分析，进行公司的产品体 系规划、服务体系规划和市场发展规划，以辅助领导决策。解决方案的编制者，基于客户需求提供解决方案。 通过沟通和交流，了解客户战略与业务、 分析客户需求，并在此基础上提供解决方案。商务过程的推进者，辅助销售推进商务进程。 与销售共同制定商务推进计划，通过体系化的 方法、深厚的技术能力和丰富的展现能力影响客户选择，并在方案、价格和合同协助销售推 进商务进程。项目成功的保障者，保障项目的成功实施。通过

14、业务分析界定客户需求范围，从而实现客户需求与产品开发项目的衔接。售前咨询项目成功的秘诀在于运用客户能够理解、赞赏并反馈的方式来解决问题。在商务推进过程中， 售前咨询始终要采用顶级管理的眼光去看待问题，并根据项目情况对方法、商务推进线路进行裁剪，以 保证对客户影响的最佳。售前咨询路线框架 售前咨询阶段是实现销售和进行项目实施的前沿阶段，它包括了从销售线索获取、需求调研、调研分析 到准备项目建议书并向客户进行陈述等工作内容，为保证实现销售的铺垫阶段。在售前咨询阶段，由于 可能面临众多的竞争对手，同时在与客户之间还没有达成深入的沟通和了解，因此可能会遇到很多的困 难和局限，如何在这一阶段向客户成功地

15、展示自己的能力，说明客户相信自己就是最好的方案、产品以 及服务的提供商，就成为项目能否继续开展下去的关键所在。因而在此阶段全局的过程路线框架和专业 的知识、技能非常重要。在项目销售过程中，对于售前咨询来说，提供解决方案和推进商务进程是最重要的两项职能，要完成销 售活动中的技术服务和商务推进工作，可采用售前咨询路线如下：IT 项目售前咨询路线包括五个阶段：计划与准备阶段输入 销售线索分析与决策。获取销售线索以后，由销售部门与售前部门进行销售线索分析，并进行决策，如 果需要跟进，则由销售填写销售线索与项目立项书，进行项目立项。销售线索与项目立项书模板。工作内容计划与准备阶段的主要工作：商务推进计划

16、编制。 根据销售线索与项目立项书 编制商务推进路线图，大致的时间计划以及资 源需求。项目建议书编制。 根据销售线索与项目立项书 ，整合企业已有方案，编写初步的项目建议书。 此方案包括以下内容：定义项目背景、项目目标 对客户需求的粗略理解 公司的应用和技术解决方案 公司关于售前咨询的方法论、此项目的推进路线图和大致时间计划 项目的关键点及需要客户配合的工作现有产品演示需求调研计划与问卷编制。 制订需求调研计划 ，明确调研对象、访谈进度计划和以及需要客户 配合的工作内容。通过编写初步方案明确哪些问题需要调研，从而制订需求调研问卷。 需求调研计划包括以下内容：调研目的调研范围，涉及公司高层 / 主要

17、业务部门 /IT 部门等调研方式，问卷调查 /电话调研 / 面谈等 调研行程安排，为了提高整个调研的效率，行程安排务必紧凑、合理 调研人员组织需求调研问卷需要了解以下内容：行业背景和发展 组织的发展史和总体情况（企业文化、组织结构、资产状况、人员规模等） 组织今后的业务战略和发展规划 组织（关键业务部门）的职能、岗位设置、业务内容和业务流程 新系统的规划、目标、规模、需求等，包括用户对系统的安全性、可靠性、易用性、扩展性 的要求组织 IT 建设的发展过程；组织 IT 现状（基础设施、应用系统、组织人员等） 其他：客户对平台和数据库选型的想法、对软件开发机制的认识以及用户感兴趣的热点技术 需求调

18、研计划、需求调研问卷模板，下一步完善。输出 * 销售项目商务推进计划 * 项目建议书 * 销售项目需求调研计划 * 销售项目需求调研问卷提交注意事项 销售应根据销售项目商务推进计划及时与客户沟通，以明确双方第一次沟通的时间和沟通形式。同 时，需提交项目需求调研计划，并就调研时间进度与客户进行协商，让客户进行需求调研安排。 销售人员需要一定的协调和掌控能力，使客户能按照计划表安排时间和项目交流的对口人员，避免时间 和金钱的浪费。业务理解阶段输入销售项目商务推进计划、项目需求调研计划和项目需求调研问卷。工作内容 业务理解阶段的主要工作：首次客户沟通交流。 根据约定的时间与客户进行第一次交流，提交装

19、订精美的项目初步解决方 案，并进行方案讲解。主要工作如下：阐述客户问题产生的背景与复杂性总结客户当前需要解决的关键问题 定义项目目标和项目范围 解释公司的售前咨询方法和项目推进路线，解释工作重点、阶段性成果和需要客户提供的帮 助项目推进进度安排，为后续工作按计划进展做铺垫客户需求调研。 根据项目需求调研计划 ，进行相关部门和人员访谈，取得方案编写所需信息。 调研过程中仔细地聆听，尽可能翔实地记录。结束后对访谈记录进行整理，编写访谈纪要提交客户 确认。在需求调研中，应设计业务流程的调查样表，获取流程名、简单流程图、主要过程文档和支持系 统等信息。对于没有流程积累的客户，售前咨询需要花费时间和精力

20、进行流程调研，对已收集的流程进 行检查、分析，发现流程不全、尚需要补充细化的，要及时与业务部门联系，回溯补遗。客户调研总结。 调研完成后，自然就是对调研情况的整理和总结，编写 项目调研总结报告 客户确认，并约定下一次交流时间。客户需求访谈记录、客户需求访谈纪要、客户调研总结报告模板，下一步完善。输出客户需求访谈记录客户需求访谈纪要客户调研总结报告解决方案阶段输入客户需求访谈纪要、客户调研总结报告。工作内容解决方案阶段的主要工作：客户需求分析。 根据客户需求访谈纪要、客户调研总结报告进行需求分析，需求分析的重 点是通过对客户业务架构的梳理，编写用户需求用例。解决方案编写。 根据需求分析进行解决方

21、案的编写，包括方案文档和演示文档制作，有可能的话 可进行演示系统的准备。关于需求分析的方法、解决方案的内容和形式详见第4、5 部分。解决方案交流。 根据约定时间与客户进行解决方案的讲解，与客户进行方案探讨，并整理客户意 见，对方案进行修改。 * 项目解决方案模板，下一步完善。输出 * 项目解决方案项目商务阶段输入项目解决方案。工作内容项目商务阶段的主要工作：客户立项。 客户立项虽然是外部流程，但对于售前来说是非常重要的一环，销售与售前应尽可能 争取为客户提供项目立项申请报告。客户招标准备。 客户招标也是外部流程，此阶段客户的主要工作是供应商的考察、招标过程的组 织、招标的实施和确定最终的供应商

22、，并与确定的开发集成商进行商务谈判和签订合同。在此环节，销 售与售前应力争为客户提供项目招标书和项目招标评分标准，给竞争对手设置相应的商务、技 术障碍。项目投标。 项目投标是个复杂的过程，包括以下环节： 购买招标书由销售购买招标书后，如确定投标则回复投标函，如果需要则办理投标保证 金相关事宜。 编制投标计划由相关领导招集销售、售前和技术部门对招标书进行讨论，根据项目的规 模、技术难度和招标时间的要求，明确投标工作内容，制订投标计划，将计划分解到每个人 员上，确定每个人工作内容和计划，确定计划的执行的监督人员。此外，投标小组对招标书 进行讨论，找出招标书中描述不清楚的地方，根据情况向招标方提出要

23、求解释。 解决方案编制包括技术解决方案和商务解决方案的编制以及演示系统的准备。在编写标 书前，应仔细、反复阅读招标书，从而确定投标书的内容、投标方式。商务解决方案由销售 负责（公司简介、公司资质、公司荣誉、典型案例、售后服务承诺等内容） ，商务投标书应该 按照招标书的要求进行严格的应答，应答的顺序和格式最好严格遵循招标书的要求。存在资 质共享的情况下，应该请资质拥有的法人单位签署授权声明。演示 PPT 和演示系统准备在投标前，讲标的每一部分应该准备好相应的幻灯片，通过幻 灯片，规范讲解思路，并通过文字、图片、动画等多种方式，直观的向评委传达信息，便于 评委对讲解内容的理解。签字盖章在技术和商务

24、解决方案完成 （校对、审核） 后，打印解决方案，由相关人员进行 签字、盖章。商务投标书中的资质和要求公司盖章的部分一定要对照招标书的要求，严格检 查，这部分的错误和遗漏将有可能造成废标，因此，最好有两个以上的人员专门检查核对。 装订与封装将签字、盖章后的方案进行装订，并根据招标书要求进行封装。在规定的投 标文档密封条基础上，一定要多准备几张备用的、盖好章的密封条。 递交标书、述标和演示根据招标书要求递交标文，由相关人员进行述标和系统演示。讲 标应该有既要有重点，又要覆盖到各项内容，突出公司特点和优势、突出技术优势和特点。展示系统时，要注意扬长避短，屏蔽掉一些系统的弱点和缺陷，同时要注意演示的时

25、间控 制。商务谈判与合同准备。 在预中标后，将会进行商务和技术谈判，售前技术支持人员主要参加技术 协议的谈判和起草，并为合同准备技术方案附件。技术协议目的是界定好功能边界和深度，技术协议的 谈判就是要对敏感问题和技术难点要进行沟通，达成共识，使项目风险在项目实施前就得到充分的展示 和控制。技术投标方案和商务投标方案模板，下一步完善。输出 * 项目投标方案 项目实施阶段 输入项目投标方案。工作内容项目实施阶段的主要工作：协助制定项目实施计划。 在合同签订以后，与项目经理进行沟通，为项目经理理解客户需求和界 定项目范围提供帮助，并协助项目经理制定项目实施计划。输出 * 项目实施计划。理解客户业务

26、曾经一度，我和大家一样是极端鄙视那些的咨询专家的，除了“他们的方法论的确不错”。平心而论， 咨询专家能借助一套方法和工具，能在非常短的时间内进入一个他们完全不熟悉的业务领域进而成为业 务专家，是非常不容易的。设想你站在伸手不见五指的茫茫旷野之中，恐惧阵阵来袭，这时候你是多少 希望有一盏明灯啊，而企业业务架构就是指引我们了解客户业务的明灯。企业的战略往往取决于市场的环境、客户的需求和企业的资源和能力，而在战略制定之后，落实则主要 依赖于业务架构的承载。企业业务架构描述了企业的业务策略、管理模式、组织结构和关键业务流程。 业务架构用来定义企业的业务战略、企业业务模式/ 价值链、企业治理和管理架构、

27、业务流程和作业程序，并通过企业信息架构和技术架构来实现。在这一业务架构中，业务模式将直接承载企业的战略，而流程则是业务模式的承载体，作业程序则承载 着流程中某项作业的具体实现。一般来说，战略的改变需要对业务模式进行重新思考，进入影响到业务 流程的改变，而作业程序作为业务架构中最底层的操作，由最基本的任务单元的特征所决定，一般不会 受到战略改变的影响。企业业务架构是指导售前咨询理解客户业务和需求的方法论框架。值得注意的是，在售前咨询阶段，由 于客观原因限制，不可能对业务了解地非常详细，但要尽力而为。业务战略 任何企业都有自己的战略，彼得?德鲁克在 事业理论：企业的灵魂 一书中指出，每个企业都应依

28、据一套“事业理论”运作。企业战略包括的内容：企业使命定义公司为什么存在。企业使命描述一个持久的事实，是一个无限时期的解 答，为组织内所有决策提供前提，为内部和外部人员提供指导。企业愿景领导者希望公司发展成什么样。企业愿景描述一个鼓舞人心的事实，可以在一 个特定时期内实现，指导战略和组织的发展，主要是为内部人员提供指导 （有些口号也可提供 给外部人员）。企业竞争战略击败现有及潜在竞争者的计划。企业竞争战略描述公司战略选择的“价值 方案”，列出一系列举措以提供产品或服务，创造高于其成本的价值，竞争战略随市场分 析、消费者经验、试验而不断改善，且严格限制在内部使用。战略构架抽象描述了一个公司在市场上

29、正在或期望扮演的角色，以及这样的角色能够长期稳定地创造价 值的关键原因。战略构架包括：在哪儿竞争指从广泛的市场参与 （即众多的产品种类，及可能吸引的各类消费者） 中选择 一些目标市场、产品和顾客，以集中力量于一些细分的产品或顾客市场上。其核心是顾客、 产品、地理区域、渠道和垂直整合程度 如何竞争指列举所有该产业通常的可能竞争方式，并尝试采用不同的基本竞争手段（例 如，采用新技术，或不同的基本手段以满足顾客需求）。何时竞争指战略的时间动态考虑。业务模式 所谓业务模式，指的是企业创造价值的核心业务逻辑，包括核心业务的组合及相互的关系，简单地说， 就是企业是如何实现盈利的。企业的盈利模式有很多种，这

30、也就导致了业务模式的大量衍生。即使在同一行业，企业可以采用完全不 同的业务模式。有的企业可以从上游的原材料一直延伸到下游的分销，这是一种盈利模式，或者说是一 种业务模式；而有的企业只专注制造业务，有的企业集中于分销。通过这些业务的不同组合，市场上衍 生出若干不同的业务模式，每个企业凭借着自己的业务模式来实现价值。其实，即使只是同一种业务， 却依然可以有不同的业务模式，例如从事销售的企业，就有直销模式和分销模式之分。对于企业而言，采用什么样的业务模式，则主要取决于企业的战略，即企业想通过什么样的方式来盈 利，包括在哪些业务领域进行竞争，通过什么样的方式进行竞争等。企业的战略将直接决定企业的业务

31、模式，而业务模式也将直接决定企业的竞争能力，或者说战略实现的能力。正如管理学大师彼得德鲁 克（ PeterF.Drucker ）曾说过：“当今企业之间的竞争，不是产品之间的竞争，而是业务模式之间的竞 争。” 要了解企业的业务模式对企业的现有流程进行系统性的梳理，全面掌握企业价值链和高阶流程的现状。 组织架构 影响公司成功的三个关键因素是成功的战略、有效的运营和高效的组织。因而要了解企业，就必须了解 企业的组织事务和变革管理方面的内容。包括：企业治理组织结构企业的产权构成、治理模式以及治理的组织架构 企业管理组织结构企业的单元、部门和岗位设置情况 组织和岗位职能明确单位、部门和岗位的工作职责、标

32、准要求和履职条件业务流程 流程是指把一个或多个输入转化为对顾客有价值的输出的活动组合。在业务架构中，业务模式是战略的 直接承载体，而业务模式中的价值创造，则需要流程来实现。业务模式呈现了盈利的业务全景，包括企 业有哪些业务，以及这些业务主体之间的关系。而流程呈现的则是这些业务在每一步需要做什么。 不同的业务模式将需要不同的业务流程来支撑。例如，批量生产模式和定制生产模式的业务流程将完全 不同；直销模式和分销模式的业务流程也将完全不同；同样直营连锁模式和加盟连锁模式的业务流程也 将存在着差别。说到底，什么样的业务模式决定什么样的业务流程。可采用“职能域流程活动框架”进行业务流程及业务活动之间的关

33、系梳理、编目及查询，以建立业 务流程主题库。“职能域流程活动框架”中，最高层是职能域，是企业级的运营和支撑业务视图， 由若干个职能域（业务流程组）组成。第二层是流程，是对职能域的分解，一个职能域即一个业务流程 组，包含若干个业务流程，有些流程下可能包含子流程（第三层）。第四层是组成流程的活动。根据需 要，高层的流程模型可以进一步“分解”为较低的层次。在不同的层次上对流程进行规范时，应该使用 统一的指导方针和流程术语。作业程序 作业程序是作业活动的具体操作方法，是业务架构中最底层的元素，承载着业务流程中各种任务单元的 的具体实现。如果说流程回答的是业务模式中每一步需要做什么的问题，那么作业程序则

34、回答的是每一 步怎么做的问题。每一步做什么体现的是业务活动的逻辑关系，因此与业务模式息息相关，而每一步怎 么做则是实现某项任务单元的操作方法，一般来说只与任务单元的特征相关，而与业务活动的逻辑无 关，因此也就与业务模式无关了。作业程序就像最基本的零件单元，而流程则像组件，流程需要作业程 序配置在哪，作业程序就放在哪。因此，企业在制定战略之后，需要思考需要什么样的业务架构来支撑战略的实现，而在战略发生重大转 变时，企业就需要对业务模式进行调整，而对承载业务模式的业务流程进行再造。作业程序只是根据流 程的需要进行重新的配置，一般却并不对作业程序的本身进行调整。分析客户需求 软件开发是由系统构思、需

35、求分析、系统设计、编码实现、系统测试、系统培训、系统部署和系统维护 等一系列定义良好的阶段构成的，每个阶段都有不同的目标、输入和输出，整个过程应该是无缝的，在 整个开发过程中，要使用相同的概念和表示方法。UML （统一建模语言， UnifiedModelingLanguage ）是一种面向对象的建模语言，采用图形表示法来表示00的概念。通过 UML,可以构建一种应用模型，并在设计过程中增加细节。从分析到设计再到实现使 用的是相同的无缝表示法，这样一个开发阶段增加的信息就不会在下一阶段中丢失了。需求分析的过程是将企业业务模型到企业信息模型的映射的过程，实现从业务模式向信息模型的转变、 业务需求向

36、信息功能的映射、企业基础数据向企业信息的抽象，通过抽象和建模，将企业业务实体抽象 成为信息对象、业务运作模式抽象成为信息对象的属性和方法，建立面向对象的企业信息模型。UML 通过构造模型来更加深入地理解需求，分析的目标就是指明必须实现什么的规格说明，它描述了 系统的行为、特性或属性，是在开发过程中对系统的约束（而不是如何完成这些内容）。需求是开发者和用户交互的一个过程，任何一方的不投入都会导致项目的失败。由于售前咨询的定位， 必然存在着客户沟通和客户合作态度的问题（再者用户不是专业人士），因而开发者需要以积极的态度 告诉客户需求开发的方法，以获取客户的支持。软件需求层次 软件需求包括三个不同的

37、层次业务需求、用户需求和功能需求，也包括非功能需求。业务需求反映 了组织机构或客户对系统、产品高层次的目标要求，在项目视图与范围文档中予以说明。用户需求描述 用户使用产品必须要完成的任务，可使用用例文档或场景脚本予以说明。功能需求定义了开发人员必须 实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性是指逻辑上相关的功能 需求的集合，给用户提供处理能力并满足业务需求。无论哪个层次的需求，其目的都是为了说明系统要完成的内容，可采用不同的模型进行分析和展现： 业务需求，通过业务建模 （即采用业务架构理解客户业务） ，对企业目前的业务流程进行描述 和评估 用户需求，重心就是如何收集

38、用户的需求上，即确定角色和角色的用例，通过用例和场景说 明客户的工作内容和信息化需求 功能需求，依赖于用户需求，是用户需求在系统上的一个映射（Mapping ）。在这个层次上，为用户做一个软件原型是一个不错的方法UML 与相关模型UML 是一种图形化的面向对象建模语言，通过不同的图形表示来捕捉系统静态结构和动态行为的信 息，建立起对象模型。考虑到售前咨询过程更多的是理解和阐述客户需求，因而可以将注意力聚焦在用例和活动图上，即通过 层次化的用例（UseCase）模型和时序模型描述企业范围内各种应用的功能需求；通过逐级分解的活动模 型（业务过程、子过程、活动）来细化描述业务。当然也可适当考虑类模型

39、的分析，借此说明企业相关 的实体和关系。UML 概述UML的概念包括了 UML语义（Semantics）和UML表示符（Notation ）两个部分，UML语义定义了三种 模型（类模型、状态模型和交互模型） ， UML 表示符提供了完整的语义定义， UML 的表示符包括了下面 的几种主要的图：类图、用例图、顺序图、协作图、状态图、活动图和部署图。三种模型从不同的视角来描述系统： 类模型。描述了系统内部对象及其关系的静态结构它们的标识、与此同时其他对象的关 系、属性以及操作。类模型提供了放置状态模型和交互模型的基本框架。类模型中最重要的 概念是类、关联和泛化。状态模型。描述的是对象当中与时间相关

40、的内容，如表明变化的事件，以及那些界定了事件上下文的状态。状态模型是由多张状态图所构成的，一个类有一张状态图，每张状态图都包 含了一些重要的时序行为。交互模型。描述的是对象如何协作以达成某种结果。交互模型是跨越了许多对象的整体视 图。交互可以在不同的抽象层次上建模。在高层上，用例描述的是系统如何与外部参与者交 互（用例表示功能片段，有助于捕获非形式化的需求） ；顺序图提供更多的细节，显示交互的 对象，以及对象交互的时间顺序；活动图提供最详尽的细节，以显示某次活动中处理步骤之 间的控制流。用例模型 用例是从用户的角度看待系统，用例标识系统的功能，并根据用户的观点组织这些功能。用例模型包括 参与者

41、、用例和用例图三部分构成：参与者（ Actor ）。系统的直接外部用户直接与系统通信的一个对象或一级对象，但并不 是系统的一部分。用例。用例是系统通过与参与者的交互可以提供的一段连贯的功能，每个用例会涉及一个或 多个参与者以及系统本身。用例把与此一部分系统功能相关的所有行为组合在一起，包括普 通主线行为、普通行为的变体、异常条件、错误条件和请求取消。用例图。 UML 用一套图形表示法来总结用例，如下图。其中矩形包含了系统的用例，参与者 列在矩形外面。系统的名称可以写在矩形的某条边的附近。椭圆内部的名称表示用例。“火 柴人”图标表示参与者，参与者的名称列在图标下方或者临近图标的地方。实线连接用例

42、及 其参与者。顺序模型 顺序模型详细描述用例的主题。有两种顺序模型：场景和顺序图，顺序图具有更加结构化的形式。 场景。是指系统在某个特定的执行期内所发生的一系列事件，如用例。场景的范围可以变化它可以 包括系统中的所有事件，或者只包括与某些对象有密切联系或由这些对象产生的那些事件。场景可以是 执行一个实际系统的历史记录，或者是执行拟采用系统的预想实践。顺序图。文本格式便于编写，但无法清晰地显示每条消息的发送者和接收者，顺序图显示了交互的参与 者之间的消息顺序。每个用例需要一张或多张顺序图来描述其行为。每张顺序图显示用例的一个特定的行为序列，同时用例 内部的每种异常条件也需要绘制顺序图。在多数系统

43、中，会有无限多的场景，因此全部显示是不可能 的，但是应该试着详细描述所有的用例，并用顺序图来覆写基本的行为种类。活动模型活动图显示了组成复杂过程的步骤序列，例如算法和工作流。与顺序图类似，活动图可以显示控制流， 但专注于操作而不是对象。活动图很像传统的流程图，一步一步地显示流程控制。 在活动图中，拉长了的椭圆表示活动，箭头表示活动的顺序，菱形表示决策点，粗线条表示并发线程的 分流和合并，带输出箭头的实心圆表示活动图的起点，靶心（空心圆围绕着实心圆）表示终止点。 类模型 类描述了拥有相同特性（属性）、行为（操作）、关系种别以及语义的一组对象，类中的对象有着相同 的属性和行为模式。类图提供了地类及

44、其关系进行建模的一种图形化的表示法。类的 UML 表示法是一个方框，方框里面是类名（用黑体字表示，一般用单数名词表示）。UML值和属性。属性是类的一个命名特性，它描述了类的每个对象都拥有一个值，值就是一段数据。 表示法会在类方框的第二格里列举属性，而第二格里也可能会包含属性，其表示法是列出每个属性名， 之后跟着等号和取值。操作和方法。操作是一个函数或过程，可以应用于类的对象，或被对象使用。方法是类中操作的实现。 UML 表示法在类的第三格里列举操作。可以通过链接、关联、泛化和继承来建立对象与类之间的关系。由于类与类之间的关系内容比较得杂， 且不是售前咨询关注的重点，本文就不细述。用 UML 进

45、行需求分析采用 UML 进行需求分析，我们通过确定系统的整体边界来进行需求建模，然后识别用例，用场景和顺 序图来充实用例：确定系统边界首先，必须要了解系统的准确范围，也即系统边界，以便把功能确定下来。这意味着必须要确定系统包 括哪些功能（或者涵盖的业务范围），更重要的是，要确定系统应该忽略哪些内容。在确定系统边界阶段，可以把系统看作是一个可以和外界交互的黑盒（内部系统被隐藏了），我们要确 定的是系统的意图以及系统呈现给参与者的视图。通过不应该把人看成是系统的一部分人是必须与系统交互的参与者，但他们的活动不受系统控制。 寻找参与者一旦将系统边界确定下来之后，就要确定与系统直接交互的外部对象，这些

46、都是系统的参与者。参与者 可以是人、外部设备和其他软件系统。在寻找参与者的过程，要找的不是个体，而是行为原型。每个参与者都代表一个理想化的会执行一部分 系统功能的用户，外部对象可能会有多个参与者。寻找用例对于每个参与者，列举参与者使用系统的不同方式，每一种方式都是一个用例。用例将系统功能划分成 少数离散单元，所有的系统行为都必须处在某种用例之下。每个用例都应该表示系统所提供的一类服务，即给参与者提供价值的内容。在用例中，要努力使所有的 用例都保持相似的层次细节。此时可绘制初步的用例图，显示参与此同时者和用例，并将参与者连接到 用例上。寻找初始和终止事件用例将系统功能拆分成离散单元，并显示了每一

47、个单元所涉及到的参与者，但它们并没有清晰地显示行 为。要理解行为，就必须理解覆写每一个用例的执行顺序，我们可以从寻找发起每个用例的事件开始， 确定哪个参与者发起了用例，并且定义它发送给系统的事件。在许多情况下，初始事件是对用例所提供 服务的一种请求。同时，还应该确定一个或多个终止事件以及每个用例中究竟要包含多少个终止事件。 准备普通场景对于每一个用例，准备出一种或多种典型的对话，以获得对系统期望行为的感觉。这些场景描述了主要 的交互、外部显示格式以及信息互换等（场景是在一组交互对象之间发生的一系列事件）。对于大多数问题来说，逻辑上的正确性要取决于交互序列，而不是交互的确切时间。 增加变化和异常

48、场景整理“普通”情形的场景，也即没有任何异常输入或者错误的交互。因而在准备好典型场景之后，就要 考虑特例了，此外还要考虑错误情形（包括无效值和没有响应）。寻找外部事件 检查场景，寻找所有的外部事件，包括所有的输入、决策、中断以及用户或外部设备之间的往来交互， 外部事件可以触发目标对象动作。把信息传输给对象是一种事件，许多事件都有参数。应该把对控制流有着相同效果的事件都组织在同一个名称下面，即使它们的参数值不同的时候也要这么 作。事件之间的差异取决于应用。为每一种场景都准备一张顺序图，顺序图要清晰地显示每次事件的发送者和接收者。如果同一个类的多 个对象都参与了场景，那就要给每一个对象分配一列，通

49、过检视图中的某一列，就可以观察到会直接影 响某个对象的事件，这样从顺序图就可以总结岀每个类接收和发送的事件。编制复杂用例的活动图顺序图捕获参与者之间的会话与相互作用，但并没有清晰地给岀分支和决策，而活动图通过归档控制流 中的分叉和汇合，对业务逻辑进行分析。组织参与者和用例下一步是用关系（包括、扩展和泛化）来组织用例了。组织原型界面用户界面是以一致的方式给系统用户提供访问其领域对象、命令和应用选项的一个或一组对象。在售前 咨询阶段，原型界面的展现和功能描述是关键环节。在售前咨询阶段，界面要求通常是模糊的、不明确的，多数用户往往并不能提岀明确的、全局的界面需 求。因而组织原型界面，要先草拟岀一种示

50、例界面，将应用程序的操作可视化表示，并看看有什么重要 内容被遗漏。原型界面的组织步骤可为：确定所涉及的界面元素，分析用户特征并定义用户角色，依据用户角色的界 面需求设计界面原型并不断改进完善。通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能 分布、界面输入输岀模式。其中：对用户工作效率有显着影响的元素包括：输入输岀方式、交互方式、功能分布，在使用命令式交互方式 的系统中，命令名称、参数也是界面元素的内容，如何设计命令及参数也很重要。影响用户对系统友好性评价的元素则有：颜色、字体大小、界面布局等，这种划分不是绝对的，软件界 面作为一个整体，其中任何一个元

51、素不符合用户习惯、不满足用户要求都将降低用户对软件系统的认可 度，因而在做原型界面时要尽量地考虑友好性。编写技术方案 解决方案的路径是说明问题分析问题解决问题的过程。 编制解决方案的过程是从业务理解到技术方案编制的过程，即通过业务架构分析，了解组织的战略、相 关业务的组织结构和职能、关键流程，从而构建企业的应用系统架构，并根据应用系统需求提供技术解 决方案。根据此理解，解决方案的编写路线如下： 整个技术解决方案包括五部分： 业务理解 此部分内容旨在阐述公司对客户业务的理解，通过项目背景、业务架构、问题与变革三部分分析，说明 客户的业务现状、遇到问题和未来可能的变革，以实现在业务层面与客户的共鸣

52、。项目背景分析 项目背景分析包括竞争环境分析、业务标杆分析和信息化标杆分析三部分内容：竞争环境分析。 竞争环境包括宏观环境和任务环境，其中宏观环境包括政治、经济、社会和技术 环境等，任务环境是指与企业直接有关的产业环境，通常可采用波特的竞争力模型进行分析。波特认为 影响行业竞争结构及竞争强度的主要因素包括行业内现有企业、潜在的进入者、替代品制造商、供应商 和顾客（产品购买者）。业务标杆分析。 基准化分析法（ benchmarking ）就是将本企业各项活动与从事该项活动最佳者进行 比较，从而提出行动方法，以弥补自身的不足，是一种评价自身企业和研究其他组织的手段。信息化标杆分析。 针对相关信息化

53、领域，提供信息化标杆分析。 企业现状和业务架构分析 业务架构分析包括企业基本情况、业务战略、组织架构、业务模式及关键流程和信息化现状分析等五部 分内容：企业基本情况分析。 企业生产经营概况，包括公司简介、主要业务和效益情况、在同行业内所处 的地位等。企业业务战略分析。 企业的使命、目标、价值观和企业的竞争战略 （量化的竞争目标和竞争实施计 划）。企业组织架构分析。 企业的组织架构设置情况、组织各单元的主要职能、关键岗位设置和岗位职 责情况。业务模式及关键流程分析。 本部分内容是关键，采用价值链理论进行业务模式分析，并采用编目 的方法进行流程描述和说明。信息化现状分析。 描述企业相关的应用系统、

54、软 / 硬件设备投入情况，以及企业信息化管控模式。 问题定义与变革分析问题定义与变革分析包括三部分内容： 宏观问题。根据环境和标杆分析，指出企业业务模式各环节存在的问题及改进建议。 业务流程存在的问题。根据业务流程现状分析，分析企业业务流程存在的问题和改进建议。 企业未来可能的变革分析。根据问题分析、企业战略和标杆分析，指出企业未来业务可能存在的变革。 需求分析此部分内容旨在阐述公司对客户需求的理解，通过系统目标、系统边界分析、系统功能需求分析、系统 性能需求分析和技术要求等内容，说明公司对客户需求的理解，作为与客户进行需求交流的基准。 系统目标分析系统目标叙述该项软件开发的意图、应用目标、作

55、用范围以及其他应向读者说明的有关该软件开发的背 景材料。解释被开发软件与其他有关软件之间的关系：待开发的系统名称 系统是为谁而开发的，包括项目的任务提岀者、开发者、用户系统解决哪些问题，清晰地界定系统范围，以及系统功能所解决的客户问题 系统会用在什么地方，说明系统的部署要求项目的进度要求系统边界分析从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也 就是被开发岀来的系统将是如何被使用的。所谓边界，也就是将这个系统看成一个黑盒子，和外界的交 互。系统边界分析需要定义系统要与外部环境交互什么，确定系统边界非常重要，是使用用例技术的基础。 系统边界分析需要确定

56、系统的参与者，所谓的参与者是指所有存在于系统外部并与系统进行交互的人或 其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。系统边界分析要涵盖以下内容：系统使用者。定义有哪些系统使用角色，各角色对系统的信息需求是什么相关交互系统。定义有哪些交互系统以及系统之间的关联关系，如需要与这些系统协同什么 流程、交互什么信息相关硬件设备系统。定义系统需要控制哪些硬件 系统管理者。定义系统的管理角色，系统管理角色对系统的需求是什么 系统功能需求分析一般将系统需求分为功能、可用性、可靠性、性能、可支持性、设计约束等以下几类，除了第一项功能 性需求之外的其他需求都归之为非功能性需求。用例模型主要用于描述系

57、统的功能性需求，对于其他的 非功能性需要用其他文档来记录。可采用以下需求工件集合进行系统需求分析。用例模型：记录功能性需求用例图：描述参与者和用例之间的关系 用例规约：描述每一个用例的细节信息 补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等 词汇表：记录一些系统需求相关的术语应该避免这样一种误解一一认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致 描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描 述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描 述一一用例规约所组成的。每一个用例的

58、用例规约都应该包含以下内容：简要说明。简要介绍该用例的作用和目的事件流。包括基本流和备选流，事件流应该表示出所有的场景。用例场景。包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的 特殊需求。描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等） 和设计约束（所使用的操作系统、开发工具等）。前置条件。执行用例之前系统必须所处的状态。 后置条件。用例执行完毕后系统可能处于的一组状态。用例描述示例：用例名称：网站公告发布用例标识号：202 参与者：负责人简要说明：负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的首页上。前置条件：负责人已经登陆家教网站管理系

59、统基本事件流：1负责人鼠标点击“修改公告”按钮2系统岀现一个文本框，显示着原来的公告内容3 负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告4 负责人编辑完文本框，按提交”按钮，首页公告就被修改5用例终止其他事件流 A1:在按提交”按钮之前，负责人随时可以按返回”按钮，文本框的任何修改内容都不会影响网站首页的公告异常事件流：1. 提示错误信息，负责人确认2. 返回到管理系统主页面后置条件：网站首页的公告信息被修改注释：无 系统f 补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容：功能性。功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。有些功能 性

60、需求是全局性的，适用于所有的用例，如岀错处理等，则不需要在所有的用例中描述这些功能性需 求，只需要在补充规约中统一描述就可以了。可用性。记录所有可用性相关的需求，如系统的使用者所需要的培训时间、是否应附合一些常见 的可用性标准等。可靠性。定义系统可靠性相关的各种指标，包括：可用性：指岀可用时间百分比，系统处于使用、维护、降级模式等操作的小时数； 平均故障间隔时间：通常表示为小时数，但也可表示为天数、月数或年数 平均修复时间：系统在发生故障后可以暂停运行的时间精确度：指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准） 性能。记录系统性能相关的各种指标，包括：对事务的响应时间（平