项目的开始不是在团队成立时开始的，而是在经过售前咨询签订合同那一刻就开始了，对解决方案、管理类软件来说，售前咨询对项目的重要性{jd1}可以决定一个项目的起点。最近在思考企业架构以及项目经历中的一些问题，考虑了一些与售前咨询相关的内容，本篇将对售前咨询和企业架构进行一些描述，由于我本人不是售前咨询人员，所以以下说的有问题的地方还希望专家指正。

售前咨询就是分析as-is和to-be

    售前咨询可以通过市场研究影响公司战略选择，也可参与产品开发，更多的时候从事是价值传递的工作，IT售前咨询定位如下：

    我认为咨询简单的说就是给出as-is和to-be，也就是分析现状，认清问题，提供解决方案。而售前咨询是促进销售拿单的有力保障，他是作为用户、产品和技术的桥梁，他必须有较强的综合能力。    

售前咨询三境界

    售前的一个主要职责是协同销售人员让客户接受公司的解决方案，对于解决方案的提供，有人总结了有以下几种境界：

售前咨询应具备的能力

    从上面的售前咨询三境界中的描述，我们也不难看出一个优秀的售前咨询应该具备的能力至少包括以下几个部分：

企业架构方法对售前的支持

    在上面所说的售前做的工作是以管理咨询的身份对用户现状进行分析，提出解决方案，这个as-is和to-be也是企业架构方法中都存在的重要工作内容，所以企业架构的方法对售前必定可以提供一些方法论上的支持，那我们又有那些可以借鉴的呢，主要又能解决哪些问题呢？

    在我经历的一些项目中，我感觉{zd0}的主要有以下两个问题：

    在《》中的"如何实施TOGAF"章节中的基于基线开发(Baseline first)的迭代步骤中介绍了TOGAF的{dy}个迭代：架构上下文（Architecture Context），其中包括ADM方法中的预备阶段和愿景阶段。

预备阶段

    预备阶段为组织实现成功的企业架构项目做好准备，包括定义一个组织特定的架构框架以及架构原则的定义，这一阶段明确了需要确定企业范围，获得高级管理层的承诺。

架构愿景

    架构愿景阶段明确企业架构愿景，确定项目的范围、约束和期望，定义涉众，并生成架构工作描述（Statement of Architectural Work），获得大家的一致认可。通过现状对as-is进行0.1版本的分析，提出0.1版本的to-be方案，可以确定业务范围，并与用户达成一致，避免后期范围的不确定。

    在愿景阶段，售前咨询人员需要从以下几个方面去考虑：

基于上面的考虑，以及现状分析，能够做出以下工件：

在做业务架构0.1版本时，我们也可以使用IBM的业务架构方法，具体可以参考我写的一篇介绍：

欢迎转载，转载请注明：转载自 [ ]