1 IT售前——理解客户业务
曾经一度，我和大家一样是极端鄙视那些的咨询专家的，除了“他们的方法论的确不错”。平心而论，咨询专家能借助一套方法和工具，能在非常短的时间内进入一个他们完全不熟悉的业务领域进而成为业务专家，是非常不容易的。设想你站在伸手不见五指的茫茫旷野之中，恐惧阵阵来袭，这时候你是多少希望有一盏明灯啊，而企业业务架构就是指引我们了解客户业务的明灯。
企业的战略往往取决于市场的环境、客户的需求和企业的资源和能力，而在战略制定之后，落实则主要依赖于业务架构的承载。企业业务架构描述了企业的业务策略、管理模式、组织结构和关键业务流程。业务架构用来定义企业的业务战略、企业业务模式/价值链、企业治理和管理架构、业务流程和作业程序，并通过企业信息架构和技术架构来实现。
在这一业务架构中，业务模式将直接承载企业的战略，而流程则是业务模式的承载体，作业程序则承载着流程中某项作业的具体实现。一般来说，战略的改变需要对业务模式进行重新思考，进入影响到业务流程的改变，而作业程序作为业务架构中最底层的操作，由
最基本的任务单元的特征所决定，一般不会受到战略改变的影响。
企业业务架构是指导售前咨询理解客户业务和需求的方法论框架。值得注意的是，在售前咨询阶段，由于客观原因限制，不可能对业务了解地非常详细，但要尽力而为。
1.1 业务战略
任何企业都有自己的战略，彼得•德鲁克在《事业理论：企业的灵魂》一书中指出，每个企业都应依据一套“事业理论”运作。企业战略包括的内容：
• 企业使命——定义公司为什么存在。企业使命描述一个持久的事实，是一个无限时期的解答，为组织内所有决策提供前提，为内部和外部人员提供指导。
• 企业愿景——领导者希望公司发展成什么样。企业愿景描述一个鼓舞人心的事实，可以在一个特定时期内实现，指导战略和组织的发展，主要是为内部人员提供指导（有些口号也可提供给外部人员）。
• 企业竞争战略——击败现有及潜在竞争者的计划。企业竞争战略描述公司战略选择的“价值方案”，列出一系列举措以提供产品或服务，创造高于其成本的价值，竞争战略随市场分析、消费者经验、试验而不断改善，且严格限制在内部使用。
战略构架抽象描述了一个公司在市场上正在或期望扮演的角色，以及这样的角色能够长期稳定地创造价值的关键原因。战略构架包括：
• 在哪儿竞争——指从广泛的市场参与（即众多的产品种类，及可能吸引的各类消费者）中选择一些目标市场、产品和顾客，以集中力量于一些细分的产品或顾客市场上。其
核心是顾客、产品、地理区域、渠道和垂直整合程度
• 如何竞争——指列举所有该产业通常的可能竞争方式，并尝试采用不同的基本竞争手段（例如，采用新技术，或不同的基本手段以满足顾客需求）。
• 何时竞争——指战略的时间动态考虑，即随着时间推移，战略构架需不断改变成新模式。
1.2 业务模式
所谓业务模式，指的是企业创造价值的核心业务逻辑，包括核心业务的组合及相互的关系，简单地说，就是企业是如何实现盈利的。
企业的盈利模式有很多种，这也就导致了业务模式的大量衍生。即使在同一行业，企业可以采用完全不同的业务模式。有的企业可以从上游的原材料一直延伸到下游的分销，这是一种盈利模式，或者说是一种业务模式；而有的企业只专注制造业务，有的企业集中于分销。通过这些业务的不同组合，市场上衍生出若干不同的业务模式，每个企业凭借着自己的业务模式来实现价值。其实，即使只是同一种业务，却依然可以有不同的业务模式，例如从事销售的企业，就有直销模式和分销模式之分。
对于企业而言，采用什么样的业务模式，则主要取决于企业的战略，即企业想通过什么样的方式来盈利，包括在哪些业务领域进行竞争，通过什么样的方式进行竞争等。企业的战略将直接决定企业的业务模式，而业务模式也将直接决定企业的竞争能力，或者说战略实现的能力。正如管理学大师彼得•德鲁克（Peter F.Drucker）曾说过：“当今企业之间的竞争，不是产品之间的竞争，而是业务模式之间的竞争。
要了解企业的业务模式对企业的现有流程进行系统性的梳理，全面掌握企业价值链和高阶流程的现状。
1.3 组织架构
影响公司成功的三个关键因素是成功的战略、有效的运营和高效的组织。因而要了解企业，就必须了解企业的组织事务和变革管理方面的内容。包括：
• 企业治理组织结构——企业的产权构成、治理模式以及治理的组织架构
• 企业管理组织结构——企业的单元、部门和岗位设置情况
• 组织和岗位职能——明确单位、部门和岗位的工作职责、标准要求和履职条件
1.4 业务流程
流程是指把一个或多个输入转化为对顾客有价值的输出的活动组合。在业务架构中，业务模式是战略的直接承载体，而业务模式中的价值创造，则需要流程来实现。业务模式
呈现了盈利的业务全景，包括企业有哪些业务，以及这些业务主体之间的关系。而流程呈现的则是这些业务在每一步需要做什么。
不同的业务模式将需要不同的业务流程来支撑。例如，批量生产模式和定制生产模式的业务流程将完全不同；直销模式和分销模式的业务流程也将完全不同；同样直营连锁模式和加盟连锁模式的业务流程也将存在着差别。说到底，什么样的业务模式决定什么样的业务流程。
可采用“职能域—流程—活动框架”进行业务流程及业务活动之间的关系梳理、编目及查询，以建立业务流程主题库。 “职能域—流程—活动框架”中，最高层是职能域，是企业级的运营和支撑业务视图，由若干个职能域（业务流程组）组成。第二层是流程，是对职能域的分解，一个职能域即一个业务流程组，包含若干个业务流程，有些流程下可能包含子流程（第三层）。第四层是组成流程的活动。根据需要，高层的流程模型可以进一步“分解”为较低的层次。在不同的层次上对流程进行规范时，应该使用统一的指导方针和流程术语。
1.5 作业程序
作业程序是作业活动的具体操作方法，是业务架构中最底层的元素，承载着业务流程中各种任务单元的的具体实现。如果说流程回答的是业务模式中每一步需要做什么的问题，那么作业程序则回答的是每一步怎么做的问题。每一步做什么体现的是业务活动的逻辑关系，因此与业务模式息息相关，而每一步怎么做则是实现某项任务单元的操作方法，一般来说只与任务单元的特征相关，而与业务活动的逻辑无关，因此也就与业务模式无关了。作业程序就像最基本的零件单元，而流程则像组件，流程需要作业程序配置在哪，作业程序就放在哪。
因此，企业在制定战略之后，需要思考需要什么样的业务架构来支撑战略的实现，而在战略发生重大转变时，企业就需要对业务模式进行调整，而对承载业务模式的业务流程进行再造。作业程序只是根据流程的需要进行重新的配置，一般却并不对作业程序的本身进行调整。
2 IT售前——分析客户需求
需求是开发者和用户交互的一个过程，任何一方的不投入都会导致项目的失败。由于售前咨询的定位，必然存在着客户沟通和客户合作态度的问题（再者用户不是专业人士），因而开发者需要以积极的态度告诉客户需求开发的方法，以获取客户的支持。
2.1 软件需求层次
软件需求包括三个不同的层次——业务需求、用户需求和功能需求，也包括非功能需求。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，在项目视图与范围文档中予以说明。用户需求描述用户使用产品必须要完成的任务，可使用用例文档或场景脚本予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
无论哪个层次的需求，其目的都是为了说明系统要完成的内容，可采用不同的模型进行分析和展现：
• 业务需求，通过业务建模（即采用业务架构理解客户业务），对企业目前的业务流程进行描述和评估
• 用户需求，重心就是如何收集用户的需求上，即确定角色和角色的用例，通过用例和场景说明客户的工作内容和信息化需求
• 功能需求，依赖于用户需求，是用户需求在系统上的一个映射（Mapping）。在这个
层次上，为用户做一个软件原型是一个不错的方法
2.2 UML与相关模型
UML是一种图形化的面向对象建模语言，通过不同的图形表示来捕捉系统静态结构和动态行为的信息，建立起对象模型。
考虑到售前咨询过程更多的是理解和阐述客户需求，因而可以将注意力聚焦在用例和活动图上，即通过层次化的用例（Use Case）模型和时序模型描述企业范围内各种应用的功能需求；通过逐级分解的活动模型（业务过程、子过程、活动）来细化描述业务。当然也可适当考虑类模型的分析，借此说明企业相关的实体和关系。
2.2.1 UML概述
UML的概念包括了UML语义（Semantics）和UML表示符（Notation）两个部分，UML语义定义了三种模型（类模型、状态模型和交互模型），UML表示符提供了完整的语义定义，UML的表示符包括了下面的几种主要的图：类图、用例图、顺序图、协作图、状态图、活动图和部署图。
三种模型从不同的视角来描述系统：
• 类模型。描述了系统内部对象及其关系的静态结构——它们的标识、与此同时其他对象的关系、属性以及操作。类模型提供了放置状态模型和交互模型的基本框架。类模型中最重要的概念是类、关联和泛化。
• 状态模型。描述的是对象当中与时间相关的内容，如表明变化的事件，以及那些界
定了事件上下文的状态。状态模型是由多张状态图所构成的，一个类有一张状态图，每张状态图都包含了一些重要的时序行为。
• 交互模型。描述的是对象如何协作以达成某种结果。交互模型是跨越了许多对象的整体视图。交互可以在不同的抽象层次上建模。在高层上，用例描述的是系统如何与外部参与者交互（用例表示功能片段，有助于捕获非形式化的需求）；顺序图提供更多的细节，显示交互的对象，以及对象交互的时间顺序；活动图提供最详尽的细节，以显示某次活动中处理步骤之间的控制流。
2.2.2 用例模型
用例是从用户的角度看待系统，用例标识系统的功能，并根据用户的观点组织这些功能。用例模型包括参与者、用例和用例图三部分构成：
• 参与者（Actor）。系统的直接外部用户——直接与系统通信的一个对象或一级对象，但并不是系统的一部分。
• 用例。用例是系统通过与参与者的交互可以提供的一段连贯的功能，每个用例会涉及一个或多个参与者以及系统本身。用例把与此一部分系统功能相关的所有行为组合在一起，包括普通主线行为、普通行为的变体、异常条件、错误条件和请求取消。
• 用例图。UML用一套图形表示法来总结用例，如下图。其中矩形包含了系统的用例，参与者列在矩形外面。系统的名称可以写在矩形的某条边的附近。椭圆内部的名称表示用例。“火柴人”图标表示参与者，参与者的名称列在图标下方或者临近图标的地方。实线连接用例及其参与者。
2.2.3 顺序模型
顺序模型详细描述用例的主题。有两种顺序模型：场景和顺序图，顺序图具有更加结构化的形式。
场景。是指系统在某个特定的执行期内所发生的一系列事件，如用例。场景的范围可以变化——它可以包括系统中的所有事件，或者只包括与某些对象有密切联系或由这些对象产生的那些事件。场景可以是执行一个实际系统的历史记录，或者是执行拟采用系统的预想实践。
顺序图。文本格式便于编写，但无法清晰地显示每条消息的发送者和接收者，顺序图显示了交互的参与者之间的消息顺序。
每个用例需要一张或多张顺序图来描述其行为。每张顺序图显示用例的一个特定的行为序列，同时用例内部的每种异常条件也需要绘制顺序图。在多数系统中，会有无限多的场景，因此全部显示是不可能的，但是应该试着详细描述所有的用例，并用顺序图来覆写基本的行为种类。
2.2.4 活动模型
活动图显示了组成复杂过程的步骤序列，例如算法和工作流。与顺序图类似，活动图可以显示控制流，但专注于操作而不是对象。
活动图很像传统的流程图，一步一步地显示流程控制。
在活动图中，拉长了的椭圆表示活动，箭头表示活动的顺序，菱形表示决策点，粗线条表示并发线程的分流和合并，带输出箭头的实心圆表示活动图的起点，靶心（空心圆围
绕着实心圆）表示终止点。
2.2.5 类模型
类描述了拥有相同特性（属性）、行为（操作）、关系种别以及语义的一组对象，类中的对象有着相同的属性和行为模式。
类图提供了地类及其关系进行建模的一种图形化的表示法。
类的UML表示法是一个方框，方框里面是类名（用黑体字表示，一般用单数名词表示）。
值和属性。属性是类的一个命名特性，它描述了类的每个对象都拥有一个值，值就是一段数据。UML表示法会在类方框的第二格里列举属性，而第二格里也可能会包含属性，其表示法是列出每个属性名，之后跟着等号和取值。
操作和方法。操作是一个函数或过程，可以应用于类的对象，或被对象使用。方法是类中操作的实现。UML表示法在类的第三格里列举操作。
可以通过链接、关联、泛化和继承来建立对象与类之间的关系。由于类与类之间的关系内容比较得杂，且不是售前咨询关注的重点，本文就不细述。
2.3 用UML进行需求分析
采用UML进行需求分析，我们通过确定系统的整体边界来进行需求建模，然后识别用例，用场景和顺序图来充实用例：
2.3.1 确定系统边界
首先，必须要了解系统的准确范围，也即系统边界，以便把功能确定下来。这意味着必须要确定系统包括哪些功能（或者涵盖的业务范围），更重要的是，要确定系统应该忽略哪些内容。
在确定系统边界阶段，可以把系统看作是一个可以和外界交互的黑盒（内部系统被隐藏了），我们要确定的是系统的意图以及系统呈现给参与者的视图。
通过不应该把人看成是系统的一部分——人是必须与系统交互的参与者，但他们的活动不受系统控制。
2.3.2 寻找参与者
一旦将系统边界确定下来之后，就要确定与系统直接交互的外部对象，这些都是系统的参与者。参与者可以是人、外部设备和其他软件系统。
在寻找参与者的过程，要找的不是个体，而是行为原型。每个参与者都代表一个理想化的会执行一部分系统功能的用户，外部对象可能会有多个参与者。
2.3.3 寻找用例
对于每个参与者，列举参与者使用系统的不同方式，每一种方式都是一个用例。用例将系统功能划分成少数离散单元，所有的系统行为都必须处在某种用例之下。
每个用例都应该表示系统所提供的一类服务，即给参与者提供价值的内容。在用例中，要努力使所有的用例都保持相似的层次细节。此时可绘制初步的用例图，显示参与此同时者和用例，并将参与者连接到用例上。
2.3.4 寻找初始和终止事件
用例将系统功能拆分成离散单元，并显示了每一个单元所涉及到的参与者，但它们并没有清晰地显示行为。要理解行为，就必须理解覆写每一个用例的执行顺序，我们可以从寻找发起每个用例的事件开始，确定哪个参与者发起了用例，并且定义它发送给系统的事件。在许多情况下，初始事件是对用例所提供服务的一种请求。
同时，还应该确定一个或多个终止事件以及每个用例中究竟要包含多少个终止事件。
2.3.5 准备普通场景
对于每一个用例，准备出一种或多种典型的对话，以获得对系统期望行为的感觉。这些场景描述了主要的交互、外部显示格式以及信息互换等（场景是在一组交互对象之间发生的一系列事件）。
对于大多数问题来说，逻辑上的正确性要取决于交互序列，而不是交互的确切时间。
2.3.6 增加变化和异常场景
整理“普通”情形的场景，也即没有任何异常输入或者错误的交互。因而在准备好典型场景之后，就要考虑特例了，此外还要考虑错误情形（包括无效值和没有响应）。
2.3.7 寻找外部事件
检查场景，寻找所有的外部事件，包括所有的输入、决策、中断以及用户或外部设备之间的往来交互，外部事件可以触发目标对象动作。
把信息传输给对象是一种事件，许多事件都有参数。
应该把对控制流有着相同效果的事件都组织在同一个名称下面，即使它们的参数值不同的时候也要这么作。事件之间的差异取决于应用。
为每一种场景都准备一张顺序图，顺序图要清晰地显示每次事件的发送者和接收者。如果同一个类的多个对象都参与了场景，那就要给每一个对象分配一列，通过检视图中的某一列，就可以观察到会直接影响某个对象的事件，这样从顺序图就可以总结出每个类接
收和发送的事件。
2.3.8 编制复杂用例的活动图
顺序图捕获参与者之间的会话与相互作用，但并没有清晰地给出分支和决策，而活动图通过归档控制流中的分叉和汇合，对业务逻辑进行分析。
2.3.9 组织参与者和用例
下一步是用关系（包括、扩展和泛化）来组织用例了。
2.4 组织原型界面
用户界面是以一致的方式给系统用户提供访问其领域对象、命令和应用选项的一个或一组对象。在售前咨询阶段，原型界面的展现和功能描述是关键环节。
在售前咨询阶段，界面要求通常是模糊的、不明确的，多数用户往往并不能提出明确的、全局的界面需求。因而组织原型界面，要先草拟出一种示例界面，将应用程序的操作可视化表示，并看看有什么重要内容被遗漏。
原型界面的组织步骤可为：确定所涉及的界面元素，分析用户特征并定义用户角色，依据用户角色的界面需求设计界面原型并不断改进完善。
通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式。其中：
对用户工作效率有显著影响的元素包括：输入输出方式、交互方式、功能分布，在使用命令式交互方式的系统中，命令名称、参数也是界面元素的内容，如何设计命令及参数也很重要。
影响用户对系统友好性评价的元素则有：颜色、字体大小、界面布局等，这种划分不是绝对的，软件界面作为一个整体，其中任何一个元素不符合用户习惯、不满足用户要求都将降低用户对软件系统的认可度，因而在做原型界面时要尽量地考虑友好性。
因篇幅问题不能全部显示，请点此查看更多更全内容