IT售前咨询白皮书.doc

IT售前咨询白皮书【最新资料,Word版，可自由编辑！】目 录1 前言52 售前咨询及定位73 售前咨询路线框架103.1 计划与准备阶段113.1.1 输入113.1.2 工作内容113.1.3 输出123.1.4 注意事项123.2 业务理解阶段133.2.1 输入133.2.2 工作内容133.2.3 输出143.3 解决方案阶段143.3.1 输入143.3.2 工作内容143.3.3 输出153.4 项目商务阶段153.4.1 输入153.4.2 工作内容153.4.3 输出173.5 项目实施阶段173.5.1 输入173.5.2 工作内容173.5.3 输出174 理解客户业务184.1 业务战略194.2 业务模式204.3 组织架构214.4 业务流程214.5 作业程序225 分析客户需求245.1 软件需求层次245.2 UML与相关模型255.2.1 UML概述255.2.2 用例模型265.2.3 顺序模型275.2.4 活动模型285.2.5 类模型295.3 用UML进行需求分析305.3.1 确定系统边界305.3.2 寻找参与者305.3.3 寻找用例315.3.4 寻找初始和终止事件315.3.5 准备普通场景315.3.6 增加变化和异常场景315.3.7 寻找外部事件325.3.8 编制复杂用例的活动图325.3.9 组织参与者和用例325.4 组织原型界面326 编写技术方案346.1 业务理解346.1.1 项目背景分析356.1.2 企业现状和业务架构分析356.1.3 问题定义与变革分析366.2 需求分析366.2.1 系统目标分析366.2.2 系统边界分析376.2.3 系统功能需求分析376.2.4 系统性能要求396.2.5 系统技术要求406.3 技术方案406.4 实施方案406.5 运维方案416.6 公司简介417 关于企业架构43第 5 页 共 55 页前言到现在为止，我一直在问自己，你够格吗？懵懂地闯入了售前咨询领域时，我几乎不明白售前是什么、应该做哪些工作，只记得最初的工作是从投标开始的。记得自己第一次独立承接标书任务时，整整用了三天时间才理出了一个提纲，然后用了十天时间完成了方案的编写，很幸运的是公司中了那个标，从此就开始了自己的售前之路。在浑浑噩噩的头几年，我的主要工作是针对公司现有的产品编写解决方案和演示PPT，以及进行项目投标活动（主要还是标书的编写和PPT的制作）。在写方案的时候，针对客户关系管理、物流管理等系统，我比较注重理论体系的学习，并把相关的理论体系应用到方案中（说明理论的框架，并如明系统与理论的匹配度），这是我与公司之前的售前的最大区别他们习惯直奔主题阐述系统有哪些功能。这大概是我对售前工作理解的第一阶段吧。今天回过头去看看那段过程，最大的欠缺有两方面：一是IT售前的方法论，不能从全局的观点去定义售前的工作，采用方法论去指导自己的工作过程；二是理论与实践的脱结，与客户接触较少，不清楚也不了解客户的实际问题，不能用理论框架去实际地解决客户的问题。事实上，当时根本不明白这些，甚至颇有些自得地认为自己还挺不错的，当然有时心情也挺复杂的，毕竟售前咨询面临的领域太广了，明显觉得自己知识不够用。2004年开始接触到了信息化规划，在不以为然其提交物的时候，也深深地被其方法论给震憾了。此后，比较多地关注了信息化规划的路线图和方法框架，在售前咨询过程中会以一些信息化规划模版为参照物，进行方案的编写。不可否认，起初生搬硬套的痕迹非常地明显，随着不断地学习和思考，慢慢地较深入地了解了信息化规划的内容以及实施路线，同时也领悟到售前咨询方案的编写也可采用规划的方法进行，二者的区别在于前者是基于全局业务的，而后者是基于局部业务的。采用信息化规划的方法论指导自己的售前工作，也算是对售前工作理解的第二阶段吧。后来自己开始带团队，为了培训团队中的新人，我尽量把自己理解的售前咨询的方法论教给他们，这过程中也发现自己了解的内容也不是非常地体系。为了做好培训教材，上网查了很多资料，这才发现业界对售前的称谓莫衷一是，对售前的职能和工作也没有统一的定义。而实际上，自己团队的工作也有些疲于奔命的感觉，整天忙着应付来自销售的需求。混乱的现实促使我对售前职业进行了思考售前应该是做什么的？售前应该怎么作？售前的出路是什么？售前应该具备哪些知识和能力了？在此谈点不成熟的看法。从客户价值视角看，售前咨询的主要工作应该是认识问题（理解业务）、分析需求和提供解决方案。在整个售前咨询过程中，目前主要的欠缺有二：一是缺少工作路线图对售前工作的指导，几乎没有售前对工作推进路线有清晰的计划；二是解决方案应该如何编写，要写哪些内容有些模糊。其实只要明白售前的主要工作是认识问题、分析需求和提供解决方案，方案的编写内容就清楚了。在一番思考后，我决定编写一本IT软件应用售前咨询白皮书，本书的主要对象是为行业或为客户提供应MIS系统的售前咨询人员。希望通过本书能给刚入门的售前提供指导，对职业有疑惑的售前提供帮助，也为一些资深的售前提供参考。在与很多优秀同行的竞争中，我已经在这个职业中走过了七年，深深感觉售前咨询领域的博大精深和售前咨询工作的巨大挑战，到目前为止，自己一直感觉未能切实地站在较高的高度为客户提出可行的解决方案，这也是我一直置疑自己的原因。希望能用此书作为我七年工作的总结，同时也是自己提升的基础吧。在此对所有在过去工作中给予我帮助的客户、领导、同事和朋友表示感谢。第51页售前咨询及定位售前咨询，作为销售人员的技术支持，其职责是以专业的方法理解客户业务、分析客户需求，将管理理论、客户需求、IT技术和公司产品相结合提供解决方案，并将良好的公司形象、产品形象和服务能力传达给客户，从而达到有效战胜竞争对手、促成签章并合理降低项目风险的目标。近代学者王国维认为，“古今之成大事业、大学问者，必经三种境界。”“昨夜西风凋敝树，独上高楼，望尽天涯路”，是为第一境界；“衣带渐宽终不悔，为伊消得人憔悴”，是为第二境界；“众里寻他千百度，蓦然回首，那人却在灯火阑珊处”，是为最终境界。这不只是做诗的境界，做学问的境界，从事艺术创造的境界，也是我们生活的境界，事业的境界，人生的境界。售前咨询之道亦然。售前是作为公司的技术代表，其主要职责是协同销售人员让客户接受公司的解决方案。但如何提供解决方案，亦存在几种不同的境界。第一重境界：从产品到方案。将公司的产品说明书修改成针对用户的解决方案，这一类售前咨询不在少数，特别是一些作产品的公司。此重境界的售前咨询，可能比较了解自己的产品，甚至有相当的技术功底，也有良好用户展示和交流能力（当然如果这些都没有那就真的是一无是处了），但不能站在客户价值角度理解产品，通过了解客户业务、界定客户需求，并说明产品对客户的价值。这是售前咨询的初级阶段，个人觉得也是比较幸福的售前阶段，怎么说了，简单就是幸福嘛。第二重境界：从需求到方案。通过不断地学习和总结了，有了自己的知识体系和工作方法论（自觉或不自觉的），能站在管理咨询的角度采用各种方法去了解客户业务、分析用户需求，并提供解决方案。达到此境界绝非易事，方法论、知识、技能和态度一个都不能缺少，应该说此重境界的售前咨询已经是比较成功的假如没有下一重境界的话。此境界的售前咨询能从较高的程度对客户进行影响，可承担一些客户的管理咨询工作，如进行产品体系规划和产品设计。第三重境界：全程商务推进。毕竟售前咨询的本质还是促进销售，因而在商务领域也必须有自己的思路和想法。此重境界的售前咨询对于整个商务推进路线有着清晰的认识，能根据此路线图制定计划，并按照计划在不同阶段影响客户，直至商务合同的签订，甚至延伸至售中领域。基于上述的境界描述，不难看出一个优秀的售前咨询应该具备的能力：一是体系化的方法论（包括商务推进）；其二必须具备较宽的知识体系，包括管理、技术和业务方面的知识，特别是要熟悉自己的产品；三是良好的综合技能，包括各类工具的应用，如计划、调研、交流、方案编写、方案展示等技能；此外还需要强调的是态度。一个优秀的售前，除了为客户提供价值外，也应该在公司价值链中找到自己合适的定位。价值链是指企业进行的一系列符合特定模式的活动，或者说，价值链是企业生产的产品或服务增值的环节或链条，价值链中的每项活动都增加了产品或服务的价值。从企业价值链看，价值的创造和传递包括三阶段：选择价值，通过市场细分，确定企业的市场目标和价值定位；提供价值，根据企业的业务战略，开发产品和服务，并制订企业总体营销策略；传播价值，通过销售、促销及其他推广工作，将企业价值推向市场。在企业价值链中，售前咨询可以通过市场研究影响公司战略选择，也可参与产品开发以提供价值，更多的时候售前从事是的价值传播工作。因而一个优秀的售前咨询应该在价值链的各个环节都要有所映射。基于上述分析，可将IT售前咨询定位如下： 价值选择的辅助者，辅助公司战略价值选择。通过行业研究和市场分析，进行公司的产品体系规划、服务体系规划和市场发展规划，以辅助领导决策。 解决方案的编制者，基于客户需求提供解决方案。通过沟通和交流，了解客户战略与业务、分析客户需求，并在此基础上提供解决方案。 商务过程的推进者，辅助销售推进商务进程。与销售共同制定商务推进计划，通过体系化的方法、深厚的技术能力和丰富的展现能力影响客户选择，并在方案、价格和合同协助销售推进商务进程。 项目成功的保障者，保障项目的成功实施。通过业务分析界定客户需求范围，从而实现客户需求与产品开发项目的衔接。售前咨询项目成功的秘诀在于运用客户能够理解、赞赏并反馈的方式来解决问题。在商务推进过程中，售前咨询始终要采用顶级管理的眼光去看待问题，并根据项目情况对方法、商务推进线路进行裁剪，以保证对客户影响的最佳。售前咨询路线框架售前咨询阶段是实现销售和进行项目实施的前沿阶段，它包括了从销售线索获取、需求调研、调研分析到准备项目建议书并向客户进行陈述等工作内容，为保证实现销售的铺垫阶段。在售前咨询阶段，由于可能面临众多的竞争对手，同时在与客户之间还没有达成深入的沟通和了解，因此可能会遇到很多的困难和局限，如何在这一阶段向客户成功地展示自己的能力，说明客户相信自己就是最好的方案、产品以及服务的提供商，就成为项目能否继续开展下去的关键所在。因而在此阶段全局的过程路线框架和专业的知识、技能非常重要。在项目销售过程中，对于售前咨询来说，提供解决方案和推进商务进程是最重要的两项职能，要完成销售活动中的技术服务和商务推进工作，可采用售前咨询路线如下：IT项目售前咨询路线包括五个阶段：计划与准备阶段输入销售线索分析与决策。获取销售线索以后，由销售部门与售前部门进行销售线索分析，并进行决策，如果需要跟进，则由销售填写销售线索与项目立项书，进行项目立项。销售线索与项目立项书模板。工作内容计划与准备阶段的主要工作：商务推进计划编制。根据销售线索与项目立项书编制商务推进路线图，大致的时间计划以及资源需求。项目建议书编制。根据销售线索与项目立项书，整合企业已有方案，编写初步的项目建议书。此方案包括以下内容： 定义项目背景、项目目标 对客户需求的粗略理解 公司的应用和技术解决方案 公司关于售前咨询的方法论、此项目的推进路线图和大致时间计划 项目的关键点及需要客户配合的工作 现有产品演示需求调研计划与问卷编制。制订需求调研计划，明确调研对象、访谈进度计划和以及需要客户配合的工作内容。通过编写初步方案明确哪些问题需要调研，从而制订需求调研问卷。需求调研计划包括以下内容： 调研目的 调研范围，涉及公司高层/主要业务部门/IT部门等 调研方式，问卷调查/电话调研/面谈等 调研行程安排，为了提高整个调研的效率，行程安排务必紧凑、合理 调研人员组织需求调研问卷需要了解以下内容： 行业背景和发展 组织的发展史和总体情况（企业文化、组织结构、资产状况、人员规模等） 组织今后的业务战略和发展规划 组织（关键业务部门）的职能、岗位设置、业务内容和业务流程 新系统的规划、目标、规模、需求等，包括用户对系统的安全性、可靠性、易用性、扩展性的要求 组织IT建设的发展过程； 组织IT现状（基础设施、应用系统、组织人员等） 其他：客户对平台和数据库选型的想法、对软件开发机制的认识以及用户感兴趣的热点技术需求调研计划、需求调研问卷模板，下一步完善。输出*销售项目商务推进计划*项目建议书*销售项目需求调研计划*销售项目需求调研问卷注意事项销售应根据销售项目商务推进计划及时与客户沟通，以明确双方第一次沟通的时间和沟通形式。同时，需提交项目需求调研计划，并就调研时间进度与客户进行协商，让客户进行需求调研安排。销售人员需要一定的协调和掌控能力，使客户能按照计划表安排时间和项目交流的对口人员，避免时间和金钱的浪费。业务理解阶段输入销售项目商务推进计划、项目需求调研计划和项目需求调研问卷。工作内容业务理解阶段的主要工作：首次客户沟通交流。根据约定的时间与客户进行第一次交流，提交装订精美的项目初步解决方案，并进行方案讲解。主要工作如下： 阐述客户问题产生的背景与复杂性 总结客户当前需要解决的关键问题 定义项目目标和项目范围 解释公司的售前咨询方法和项目推进路线，解释工作重点、阶段性成果和需要客户提供的帮助 项目推进进度安排，为后续工作按计划进展做铺垫客户需求调研。根据项目需求调研计划，进行相关部门和人员访谈，取得方案编写所需信息。调研过程中仔细地聆听，尽可能翔实地记录。结束后对访谈记录进行整理，编写访谈纪要提交客户确认。在需求调研中，应设计业务流程的调查样表，获取流程名、简单流程图、主要过程文档和支持系统等信息。对于没有流程积累的客户，售前咨询需要花费时间和精力进行流程调研，对已收集的流程进行检查、分析，发现流程不全、尚需要补充细化的，要及时与业务部门联系，回溯补遗。客户调研总结。调研完成后，自然就是对调研情况的整理和总结，编写项目调研总结报告提交客户确认，并约定下一次交流时间。客户需求访谈记录、客户需求访谈纪要、客户调研总结报告模板，下一步完善。输出客户需求访谈记录客户需求访谈纪要客户调研总结报告解决方案阶段输入客户需求访谈纪要、客户调研总结报告。工作内容解决方案阶段的主要工作：客户需求分析。根据客户需求访谈纪要、客户调研总结报告进行需求分析，需求分析的重点是通过对客户业务架构的梳理，编写用户需求用例。解决方案编写。根据需求分析进行解决方案的编写，包括方案文档和演示文档制作，有可能的话可进行演示系统的准备。关于需求分析的方法、解决方案的内容和形式详见第4、5部分。解决方案交流。根据约定时间与客户进行解决方案的讲解，与客户进行方案探讨，并整理客户意见，对方案进行修改。*项目解决方案模板，下一步完善。输出*项目解决方案项目商务阶段输入项目解决方案。工作内容项目商务阶段的主要工作：客户立项。客户立项虽然是外部流程，但对于售前来说是非常重要的一环，销售与售前应尽可能争取为客户提供项目立项申请报告。客户招标准备。客户招标也是外部流程，此阶段客户的主要工作是供应商的考察、招标过程的组织、招标的实施和确定最终的供应商，并与确定的开发集成商进行商务谈判和签订合同。在此环节，销售与售前应力争为客户提供项目招标书和项目招标评分标准，给竞争对手设置相应的商务、技术障碍。项目投标。项目投标是个复杂的过程，包括以下环节： 购买招标书由销售购买招标书后，如确定投标则回复投标函，如果需要则办理投标保证金相关事宜。 编制投标计划由相关领导招集销售、售前和技术部门对招标书进行讨论，根据项目的规模、技术难度和招标时间的要求，明确投标工作内容，制订投标计划，将计划分解到每个人员上，确定每个人工作内容和计划，确定计划的执行的监督人员。此外，投标小组对招标书进行讨论，找出招标书中描述不清楚的地方，根据情况向招标方提出要求解释。 解决方案编制包括技术解决方案和商务解决方案的编制以及演示系统的准备。在编写标书前，应仔细、反复阅读招标书，从而确定投标书的内容、投标方式。商务解决方案由销售负责（公司简介、公司资质、公司荣誉、典型案例、售后服务承诺等内容），商务投标书应该按照招标书的要求进行严格的应答，应答的顺序和格式最好严格遵循招标书的要求。存在资质共享的情况下，应该请资质拥有的法人单位签署授权声明。 演示PPT和演示系统准备在投标前，讲标的每一部分应该准备好相应的幻灯片，通过幻灯片，规范讲解思路，并通过文字、图片、动画等多种方式，直观的向评委传达信息，便于评委对讲解内容的理解。 签字盖章在技术和商务解决方案完成（校对、审核）后，打印解决方案，由相关人员进行签字、盖章。商务投标书中的资质和要求公司盖章的部分一定要对照招标书的要求，严格检查，这部分的错误和遗漏将有可能造成废标，因此，最好有两个以上的人员专门检查核对。 装订与封装将签字、盖章后的方案进行装订，并根据招标书要求进行封装。在规定的投标文档密封条基础上，一定要多准备几张备用的、盖好章的密封条。 递交标书、述标和演示根据招标书要求递交标文，由相关人员进行述标和系统演示。讲标应该有既要有重点，又要覆盖到各项内容，突出公司特点和优势、突出技术优势和特点。展示系统时，要注意扬长避短，屏蔽掉一些系统的弱点和缺陷，同时要注意演示的时间控制。商务谈判与合同准备。在预中标后，将会进行商务和技术谈判，售前技术支持人员主要参加技术协议的谈判和起草，并为合同准备技术方案附件。技术协议目的是界定好功能边界和深度，技术协议的谈判就是要对敏感问题和技术难点要进行沟通，达成共识，使项目风险在项目实施前就得到充分的展示和控制。技术投标方案和商务投标方案模板，下一步完善。输出*项目投标方案项目实施阶段输入项目投标方案。工作内容项目实施阶段的主要工作：协助制定项目实施计划。在合同签订以后，与项目经理进行沟通，为项目经理理解客户需求和界定项目范围提供帮助，并协助项目经理制定项目实施计划。输出*项目实施计划。理解客户业务曾经一度，我和大家一样是极端鄙视那些的咨询专家的，除了“他们的方法论的确不错”。平心而论，咨询专家能借助一套方法和工具，能在非常短的时间内进入一个他们完全不熟悉的业务领域进而成为业务专家，是非常不容易的。设想你站在伸手不见五指的茫茫旷野之中，恐惧阵阵来袭，这时候你是多少希望有一盏明灯啊，而企业业务架构就是指引我们了解客户业务的明灯。企业的战略往往取决于市场的环境、客户的需求和企业的资源和能力，而在战略制定之后，落实则主要依赖于业务架构的承载。企业业务架构描述了企业的业务策略、管理模式、组织结构和关键业务流程。业务架构用来定义企业的业务战略、企业业务模式/价值链、企业治理和管理架构、业务流程和作业程序，并通过企业信息架构和技术架构来实现。在这一业务架构中，业务模式将直接承载企业的战略，而流程则是业务模式的承载体，作业程序则承载着流程中某项作业的具体实现。一般来说，战略的改变需要对业务模式进行重新思考，进入影响到业务流程的改变，而作业程序作为业务架构中最底层的操作，由最基本的任务单元的特征所决定，一般不会受到战略改变的影响。企业业务架构是指导售前咨询理解客户业务和需求的方法论框架。值得注意的是，在售前咨询阶段，由于客观原因限制，不可能对业务了解地非常详细，但要尽力而为。业务战略任何企业都有自己的战略，彼得德鲁克在事业理论：企业的灵魂一书中指出，每个企业都应依据一套“事业理论”运作。企业战略包括的内容： 企业使命定义公司为什么存在。企业使命描述一个持久的事实，是一个无限时期的解答，为组织内所有决策提供前提，为内部和外部人员提供指导。 企业愿景领导者希望公司发展成什么样。企业愿景描述一个鼓舞人心的事实，可以在一个特定时期内实现，指导战略和组织的发展，主要是为内部人员提供指导（有些口号也可提供给外部人员）。 企业竞争战略击败现有及潜在竞争者的计划。企业竞争战略描述公司战略选择的“价值方案”，列出一系列举措以提供产品或服务，创造高于其成本的价值，竞争战略随市场分析、消费者经验、试验而不断改善，且严格限制在内部使用。战略构架抽象描述了一个公司在市场上正在或期望扮演的角色，以及这样的角色能够长期稳定地创造价值的关键原因。战略构架包括： 在哪儿竞争指从广泛的市场参与（即众多的产品种类，及可能吸引的各类消费者）中选择一些目标市场、产品和顾客，以集中力量于一些细分的产品或顾客市场上。其核心是顾客、产品、地理区域、渠道和垂直整合程度 如何竞争指列举所有该产业通常的可能竞争方式，并尝试采用不同的基本竞争手段（例如，采用新技术，或不同的基本手段以满足顾客需求）。 何时竞争指战略的时间动态考虑。业务模式所谓业务模式，指的是企业创造价值的核心业务逻辑，包括核心业务的组合及相互的关系，简单地说，就是企业是如何实现盈利的。企业的盈利模式有很多种，这也就导致了业务模式的大量衍生。即使在同一行业，企业可以采用完全不同的业务模式。有的企业可以从上游的原材料一直延伸到下游的分销，这是一种盈利模式，或者说是一种业务模式；而有的企业只专注制造业务，有的企业集中于分销。通过这些业务的不同组合，市场上衍生出若干不同的业务模式，每个企业凭借着自己的业务模式来实现价值。其实，即使只是同一种业务，却依然可以有不同的业务模式，例如从事销售的企业，就有直销模式和分销模式之分。对于企业而言，采用什么样的业务模式，则主要取决于企业的战略，即企业想通过什么样的方式来盈利，包括在哪些业务领域进行竞争，通过什么样的方式进行竞争等。企业的战略将直接决定企业的业务模式，而业务模式也将直接决定企业的竞争能力，或者说战略实现的能力。正如管理学大师彼得德鲁克（Peter F.Drucker）曾说过：“当今企业之间的竞争，不是产品之间的竞争，而是业务模式之间的竞争。”要了解企业的业务模式对企业的现有流程进行系统性的梳理，全面掌握企业价值链和高阶流程的现状。组织架构影响公司成功的三个关键因素是成功的战略、有效的运营和高效的组织。因而要了解企业，就必须了解企业的组织事务和变革管理方面的内容。包括： 企业治理组织结构企业的产权构成、治理模式以及治理的组织架构 企业管理组织结构企业的单元、部门和岗位设置情况 组织和岗位职能明确单位、部门和岗位的工作职责、标准要求和履职条件业务流程流程是指把一个或多个输入转化为对顾客有价值的输出的活动组合。在业务架构中，业务模式是战略的直接承载体，而业务模式中的价值创造，则需要流程来实现。业务模式呈现了盈利的业务全景，包括企业有哪些业务，以及这些业务主体之间的关系。而流程呈现的则是这些业务在每一步需要做什么。不同的业务模式将需要不同的业务流程来支撑。例如，批量生产模式和定制生产模式的业务流程将完全不同；直销模式和分销模式的业务流程也将完全不同；同样直营连锁模式和加盟连锁模式的业务流程也将存在着差别。说到底，什么样的业务模式决定什么样的业务流程。可采用“职能域流程活动框架”进行业务流程及业务活动之间的关系梳理、编目及查询，以建立业务流程主题库。 “职能域流程活动框架”中，最高层是职能域，是企业级的运营和支撑业务视图，由若干个职能域（业务流程组）组成。第二层是流程，是对职能域的分解，一个职能域即一个业务流程组，包含若干个业务流程，有些流程下可能包含子流程（第三层）。第四层是组成流程的活动。根据需要，高层的流程模型可以进一步“分解”为较低的层次。在不同的层次上对流程进行规范时，应该使用统一的指导方针和流程术语。作业程序作业程序是作业活动的具体操作方法，是业务架构中最底层的元素，承载着业务流程中各种任务单元的的具体实现。如果说流程回答的是业务模式中每一步需要做什么的问题，那么作业程序则回答的是每一步怎么做的问题。每一步做什么体现的是业务活动的逻辑关系，因此与业务模式息息相关，而每一步怎么做则是实现某项任务单元的操作方法，一般来说只与任务单元的特征相关，而与业务活动的逻辑无关，因此也就与业务模式无关了。作业程序就像最基本的零件单元，而流程则像组件，流程需要作业程序配置在哪，作业程序就放在哪。因此，企业在制定战略之后，需要思考需要什么样的业务架构来支撑战略的实现，而在战略发生重大转变时，企业就需要对业务模式进行调整，而对承载业务模式的业务流程进行再造。作业程序只是根据流程的需要进行重新的配置，一般却并不对作业程序的本身进行调整。分析客户需求软件开发是由系统构思、需求分析、系统设计、编码实现、系统测试、系统培训、系统部署和系统维护等一系列定义良好的阶段构成的，每个阶段都有不同的目标、输入和输出，整个过程应该是无缝的，在整个开发过程中，要使用相同的概念和表示方法。UML（统一建模语言，Unified Modeling Language）是一种面向对象的建模语言，采用图形表示法来表示OO的概念。通过UML，可以构建一种应用模型，并在设计过程中增加细节。从分析到设计再到实现使用的是相同的无缝表示法，这样一个开发阶段增加的信息就不会在下一阶段中丢失了。需求分析的过程是将企业业务模型到企业信息模型的映射的过程，实现从业务模式向信息模型的转变、业务需求向信息功能的映射、企业基础数据向企业信息的抽象，通过抽象和建模，将企业业务实体抽象成为信息对象、业务运作模式抽象成为信息对象的属性和方法，建立面向对象的企业信息模型。UML通过构造模型来更加深入地理解需求，分析的目标就是指明必须实现什么的规格说明，它描述了系统的行为、特性或属性，是在开发过程中对系统的约束（而不是如何完成这些内容）。需求是开发者和用户交互的一个过程，任何一方的不投入都会导致项目的失败。由于售前咨询的定位，必然存在着客户沟通和客户合作态度的问题（再者用户不是专业人士），因而开发者需要以积极的态度告诉客户需求开发的方法，以获取客户的支持。软件需求层次软件需求包括三个不同的层次业务需求、用户需求和功能需求，也包括非功能需求。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，在项目视图与范围文档中予以说明。用户需求描述用户使用产品必须要完成的任务，可使用用例文档或场景脚本予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。无论哪个层次的需求，其目的都是为了说明系统要完成的内容，可采用不同的模型进行分析和展现： 业务需求，通过业务建模（即采用业务架构理解客户业务），对企业目前的业务流程进行描述和评估 用户需求，重心就是如何收集用户的需求上，即确定角色和角色的用例，通过用例和场景说明客户的工作内容和信息化需求 功能需求，依赖于用户需求，是用户需求在系统上的一个映射（Mapping）。在这个层次上，为用户做一个软件原型是一个不错的方法UML与相关模型UML是一种图形化的面向对象建模语言，通过不同的图形表示来捕捉系统静态结构和动态行为的信息，建立起对象模型。考虑到售前咨询过程更多的是理解和阐述客户需求，因而可以将注意力聚焦在用例和活动图上，即通过层次化的用例（Use Case）模型和时序模型描述企业范围内各种应用的功能需求；通过逐级分解的活动模型（业务过程、子过程、活动）来细化描述业务。当然也可适当考虑类模型的分析，借此说明企业相关的实体和关系。UML概述UML的概念包括了UML语义（Semantics）和UML表示符（Notation）两个部分，UML语义定义了三种模型（类模型、状态模型和交互模型），UML表示符提供了完整的语义定义，UML的表示符包括了下面的几种主要的图：类图、用例图、顺序图、协作图、状态图、活动图和部署图。三种模型从不同的视角来描述系统： 类模型。描述了系统内部对象及其关系的静态结构它们的标识、与此同时其他对象的关系、属性以及操作。类模型提供了放置状态模型和交互模型的基本框架。类模型中最重要的概念是类、关联和泛化。 状态模型。描述的是对象当中与时间相关的内容，如表明变化的事件，以及那些界定了事件上下文的状态。状态模型是由多张状态图所构成的，一个类有一张状态图，每张状态图都包含了一些重要的时序行为。 交互模型。描述的是对象如何协作以达成某种结果。交互模型是跨越了许多对象的整体视图。交互可以在不同的抽象层次上建模。在高层上，用例描述的是系统如何与外部参与者交互（用例表示功能片段，有助于捕获非形式化的需求）；顺序图提供更多的细节，显示交互的对象，以及对象交互的时间顺序；活动图提供最详尽的细节，以显示某次活动中处理步骤之间的控制流。用例模型用例是从用户的角度看待系统，用例标识系统的功能，并根据用户的观点组织这些功能。用例模型包括参与者、用例和用例图三部分构成： 参与者（Actor）。系统的直接外部用户直接与系统通信的一个对象或一级对象，但并不是系统的一部分。 用例。用例是系统通过与参与者的交互可以提供的一段连贯的功能，每个用例会涉及一个或多个参与者以及系统本身。用例把与此一部分系统功能相关的所有行为组合在一起，包括普通主线行为、普通行为的变体、异常条件、错误条件和请求取消。 用例图。UML用一套图形表示法来总结用例，如下图。其中矩形包含了系统的用例，参与者列在矩形外面。系统的名称可以写在矩形的某条边的附近。椭圆内部的名称表示用例。“火柴人”图标表示参与者，参与者的名称列在图标下方或者临近图标的地方。实线连接用例及其参与者。顺序模型顺序模型详细描述用例的主题。有两种顺序模型：场景和顺序图，顺序图具有更加结构化的形式。场景。是指系统在某个特定的执行期内所发生的一系列事件，如用例。场景的范围可以变化它可以包括系统中的所有事件，或者只包括与某些对象有密切联系或由这些对象产生的那些事件。场景可以是执行一个实际系统的历史记录，或者是执行拟采用系统的预想实践。顺序图。文本格式便于编写，但无法清晰地显示每条消息的发送者和接收者，顺序图显示了交互的参与者之间的消息顺序。每个用例需要一张或多张顺序图来描述其行为。每张顺序图显示用例的一个特定的行为序列，同时用例内部的每种异常条件也需要绘制顺序图。在多数系统中，会有无限多的场景，因此全部显示是不可能的，但是应该试着详细描述所有的用例，并用顺序图来覆写基本的行为种类。活动模型活动图显示了组成复杂过程的步骤序列，例如算法和工作流。与顺序图类似，活动图可以显示控制流，但专注于操作而不是对象。活动图很像传统的流程图，一步一步地显示流程控制。在活动图中，拉长了的椭圆表示活动，箭头表示活动的顺序，菱形表示决策点，粗线条表示并发线程的分流和合并，带输出箭头的实心圆表示活动图的起点，靶心（空心圆围绕着实心圆）表示终止点。类模型类描述了拥有相同特性（属性）、行为（操作）、关系种别以及语义的一组对象，类中的对象有着相同的属性和行为模式。类图提供了地类及其关系进行建模的一种图形化的表示法。类的UML表示法是一个方框，方框里面是类名（用黑体字表示，一般用单数名词表示）。值和属性。属性是类的一个命名特性，它描述了类的每个对象都拥有一个值，值就是一段数据。UML表示法会在类方框的第二格里列举属性，而第二格里也可能会包含属性，其表示法是列出每个属性名，之后跟着等号和取值。操作和方法。操作是一个函数或过程，可以应用于类的对象，或被对象使用。方法是类中操作的实现。UML表示法在类的第三格里列举操作。可以通过链接、关联、泛化和继承来建立对象与类之间的关系。由于类与类之间的关系内容比较得杂，且不是售前咨询关注的重点，本文就不细述。用UML进行需求分析采用UML进行需求分析，我们通过确定系统的整体边界来进行需求建模，然后识别用例，用场景和顺序图来充实用例：确定系统边界首先，必须要了解系统的准确范围，也即系统边界，以便把功能确定下来。这意味着必须要确定系统包括哪些功能（或者涵盖的业务范围），更重要的是，要确定系统应该忽略哪些内容。在确定系统边界阶段，可以把系统看作是一个可以和外界交互的黑盒（内部系统被隐藏了），我们要确定的是系统的意图以及系统呈现给参与者的视图。通过不应该把人看成是系统的一部分人是必须与系统交互的参与者，但他们的活动不受系统控制。寻找参与者一旦将系统边界确定下来之后，就要确定与系统直接交互的外部对象，这些都是系统的参与者。参与者可以是人、外部设备和其他软件系统。在寻找参与者的过程，要找的不是个体，而是行为原型。每个参与者都代表一个理想化的会执行一部分系统功能的用户，外部对象可能会有多个参与者。寻找用例对于每个参与者，列举参与者使用系统的不同方式，每一种方式都是一个用例。用例将系统功能划分成少数离散单元，所有的系统行为都必须处在某种用例之下。每个用例都应该表示系统所提供的一类服务，即给参与者提供价值的内容。在用例中，要努力使所有的用例都保持相似的层次细节。此时可绘制初步的用例图，显示参与此同时者和用例，并将参与者连接到用例上。寻找初始和终止事件用例将系统功能拆分成离散单元，并显示了每一个单元所涉及到的参与者，但它们并没有清晰地显示行为。要理解行为，就必须理解覆写每一个用例的执行顺序，我们可以从寻找发起每个用例的事件开始，确定哪个参与者发起了用例，并且定义它发送给系统的事件。在许多情况下，初始事件是对用例所提供服务的一种请求。同时，还应该确定一个或多个终止事件以及每个用例中究竟要包含多少个终止事件。准备普通场景对于每一个用例，准备出一种或多种典型的对话，以获得对系统期望行为的感觉。这些场景描述了主要的交互、外部显示格式以及信息互换等（场景是在一组交互对象之间发生的一系列事件）。对于大多数问题来说，逻辑上的正确性要取决于交互序列，而不是交互的确切时间。增加变化和异常场景整理“普通”情形的场景，也即没有任何异常输入或者错误的交互。因而在准备好典型场景之后，就要考虑特例了，此外还要考虑错误情形（包括无效值和没有响应）。寻找外部事件检查场景，寻找所有的外部事件，包括所有的输入、决策、中断以及用户或外部设备之间的往来交互，外部事件可以触发目标对象动作。把信息