IT售前咨询白皮书_Digital.docVIP

IT售前咨询白皮书 2008年7月  目 录 1 前言 5 2 售前咨询及定位 7 3 售前咨询路线框架 10 3.1 计划与准备阶段 11 3.1.1 输入 11 3.1.2 工作内容 11 3.1.3 输出 12 3.1.4 注意事项 12 3.2 业务理解阶段 13 3.2.1 输入 13 3.2.2 工作内容 13 3.2.3 输出 14 3.3 解决方案阶段 14 3.3.1 输入 14 3.3.2 工作内容 14 3.3.3 输出 15 3.4 项目商务阶段 15 3.4.1 输入 15 3.4.2 工作内容 15 3.4.3 输出 17 3.5 项目实施阶段 17 3.5.1 输入 17 3.5.2 工作内容 17 3.5.3 输出 17 4 理解客户业务 18 4.1 业务战略 19 4.2 业务模式 20 4.3 组织架构 21 4.4 业务流程 21 4.5 作业程序 22 5 分析客户需求 24 5.1 软件需求层次 24 5.2 UML与相关模型 25 5.2.1 UML概述 25 5.2.2 用例模型 26 5.2.3 顺序模型 27 5.2.4 活动模型 28 5.2.5 类模型 29 5.3 用UML进行需求分析 30 5.3.1 确定系统边界 30 5.3.2 寻找参与者 30 5.3.3 寻找用例 31 5.3.4 寻找初始和终止事件 31 5.3.5 准备普通场景 31 5.3.6 增加变化和异常场景 31 5.3.7 寻找外部事件 32 5.3.8 编制复杂用例的活动图 32 5.3.9 组织参与者和用例 32 5.4 组织原型界面 32 6 编写技术方案 34 6.1 业务理解 34 6.1.1 项目背景分析 35 6.1.2 企业现状和业务架构分析 35 6.1.3 问题定义与变革分析 36 6.2 需求分析 36 6.2.1 系统目标分析 36 6.2.2 系统边界分析 37 6.2.3 系统功能需求分析 37 6.2.4 系统性能要求 39 6.2.5 系统技术要求 40 6.3 技术方案 40 6.4 实施方案 40 6.5 运维方案 41 6.6 公司简介 41 7 关于企业架构 43 前言 到现在为止，我一直在问自己，你够格吗？ 懵懂地闯入了售前咨询领域时，我几乎不明白售前是什么、应该做哪些工作，只记得最初的工作是从投标开始的。记得自己第一次独立承接标书任务时，整整用了三天时间才理出了一个提纲，然后用了十天时间完成了方案的编写，很幸运的是公司中了那个标，从此就开始了自己的售前之路。 在浑浑噩噩的头几年，我的主要工作是针对公司现有的产品编写解决方案和演示PPT，以及进行项目投标活动（主要还是标书的编写和PPT的制作）。在写方案的时候，针对客户关系管理、物流管理等系统，我比较注重理论体系的学习，并把相关的理论体系应用到方案中（说明理论的框架，并如明系统与理论的匹配度），这是我与公司之前的售前的最大区别——他们习惯直奔主题阐述系统有哪些功能。 这大概是我对售前工作理解的第一阶段吧。今天回过头去看看那段过程，最大的欠缺有两方面：一是IT售前的方法论，不能从全局的观点去定义售前的工作，采用方法论去指导自己的工作过程；二是理论与实践的脱结，与客户接触较少，不清楚也不了解客户的实际问题，不能用理论框架去实际地解决客户的问题。事实上，当时根本不明白这些，甚至颇有些自得地认为自己还挺不错的，当然有时心情也挺复杂的，毕竟售前咨询面临的领域太广了，明显觉得自己知识不够用。 2004年开始接触到了信息化规划，在不以为然其提交物的时候，也深深地被其方法论给震憾了。此后，比较多地关注了信息化规划的路线图和方法框架，在售前咨询过程中会以一些信息化规划模版为参照物，进行方案的编写。不可否认，起初生搬硬套的痕迹非常地明显，随着不断地学习和思考，慢慢地较深入地了解了信息化规划的内容以及实施路线，同时也领悟到售前咨询方案的编写也可采用规划的方法进行，二者的区别在于前者是基于全局业务的，而后者是基于局部业务的。采用信息化规划的方法论指导自己的售前工作，也算是对售前工作理解的第二阶段吧。 后来自己开始带团队，为了培训团队中的新人，我尽量把自己理解的售前咨询的方法论教给他们，这过程中也发现自己了解的内容也不是非常地体系。为了做好培训教材，上网查了很多资料，这才发现业界对售前的称谓莫衷一是，对售前的职能和工作也没有统一的定义。而实际上，自己团队的工作也有些疲于奔命的感觉，整天忙着应付来自销售的需求。混乱的现实促使我对售前职业进行了思考——售前应该是做什么的？售前应该怎么作？售前的出路是什么？售前应该具备哪些知识和能力了？ 在此谈点不成熟的看法。从客户价值视角看，售前咨询的主要工作应该是认识问题（理解业务）、分析需