用流程拯救你的IT-技术圈

信息化的典型问题

IT在企业中作用无需多言，即使是规模不大的企业，至少也会有财务系统、进销存和小型MES系统等等。大企业更是如此，IT系统的发展也是纷繁复杂，不仅覆盖营销、生产、研发、供应链、服务等核心业务领域，还包括人力资源、资产管理、财务、办公等管理支持的功能。在这个信息化建设铺天盖地的大潮中，业务和IT之间的矛盾是一个持久的话题。

这其中有一些典型的问题，比如这样的场景：

1.系统上线不易，经过策划开发实施，费了好大劲结果总还是不满意；

2.系统上线运行感觉还不错，可是过了两年就变得怨声载道；

3.业务部门常抱怨IT是瓶颈，我们要的功能到他们那里就打折扣，能力不足总找各种借口；

4.IT总是很委屈，业务部门要的功能总是不能一次性说清楚，今天提一个明天提一个，系统不是这样干出来的;

5.系统建设总是补丁摞补丁的方式，最后发现这些系统都成为孤岛而不能相互联通……

这些都是很具有代表性的现实。不过值得庆幸的是，现在越来越多的企业开始明白了一个基本的道理：IT系统的结果是开始于设计的，IT技术本身从来就不是障碍。尽管如此，如何能够做好这个设计工作，依然是让很多企业一筹莫展的问题。下面我们就从IT规划说起。

IT规划始于业务架构

企业做IT规划的时候，总是首先要从业务架构出发——近些年企业越来越多的经验和教训充分说明了这一点。调查数据表明，国内企业成功上线ERP的大概比例是46%，这还不包括上线之后存在很多问题的情况。

企业IT规划的路径：从业务架构，到功能架构，最后到技术架构。

业务架构

业务架构描述的是一个企业的业务结构和关系。包括企业有哪些业务功能模块、业务域、业务单元构成？企业的价值链结构和业务模式是怎样的？有哪些业务场景，以及描述这些业务场景的结构和逻辑关系。这个过程不需要到细节的操作流程，操作流程是IT系统设计和实施层面的事情。

业务架构是管理和业务人员来完成的工作，不是技术工作。或者说是业务架构的技术，而不是IT技术。业务架构通常并不如想象中的容易，不只需要基于对业务本身系统性的理解，更需要结构化概念思维和模型化表达，这其中还涉及到业务之间的关系、管理之间的关系，以及业务和管理之间的关系。

业务架构是需要团队来完成的，需要能够把握顶层整体架构的架构师，还有业务团队，是多层面、多维度、多业务系统共同工作的结果。

功能架构

功能架构就是在业务架构基础上，考虑如何用IT系统来实现其中的哪些功能。包括企业IT建设的整体蓝图、架构的原则和标准，还有这些IT系统之间的关系，以及IT系统与人工之间如何协作。

功能架构是业务架构和技术架构之间的桥梁，既要考虑业务的需要，也要考虑IT系统的功能特征。其中，IT系统功能规划的边界是一个典型问题。

有时候企业会面临这样的选择：要实现某一个业务模块的IT化，是开发一个新的系统，还是在现有IT系统中进行功能的扩展？这样的问题就是功能架构要回答的。如果在现有IT系统基础上进行功能的扩展，这样做的结果是不是能够满足未来我们对于这个业务模块的信息化需求？如果只是实现了其中的一部分功能，而更多的功能是通过这种扩展的方式无法实现的，还是需要再开发一个系统。那么也就意味着未来我们可能要面临一个窘境：扩展功能受限，而重新开发会担负更高的成本。

从经济意义上来说，规划的价值就在于用尽可能小的成本确保预期目标的实现。

如此，功能架构不是一项单纯的业务工作，也不是单纯的IT工作。业务人员更理解需求，IT人员考虑技术路线，这个过程是需要对话的，是业务和IT共同完成的工作。

技术架构

技术架构就是在功能架构之后，实现这些功能的技术策略。包括基础设施和系统设计，选择什么语言、什么框架、什么数据库，如何部署、如何通信等等。

技术架构是纯技术性质的规划工作，是由IT架构师来完成的，接续才是IT系统开发和实施的具体的工作。

功能架构和技术架构可以是企业IT规划的整体蓝图，也可以应用于对单个IT系统的规划和设计。

现在我们把视角从整体的IT规划拉近到单个系统的开发。业务和IT之间总有解不开的矛盾，主要原因在于业务人员和IT人员之间没有一个很好的彼此沟通的语言，都是在自己的语境和逻辑中自说自话。

哪里找这样的语言？答案是流程。

从软件需求规格说明书说起

这里我们要提到“软件需求规格说明书”，这是软件在开发之前需要确认的需求说明文档，类似于业务和IT人员为软件开发约定的一个“合同”。这个“合同”需要描述IT系统功能、性能、数据的需求，也要描述开发的目标、过程和标准。

软件需求规格说明书一方面是业务人员和IT人员对话的语言，另一方面也是IT人员系统开发、测试以及最后验收的依据，它对于软件开发的重要性是不言而喻的。

软件需求规格说明书有不同的格式，包括ISO也给出了参考目录，但要说明的内容是大体相同的。

软件需求规格说明书主要内容：

引言:主要包括目的、对象、背景、术语定义和参考资料。
任务概述:主要包括目标、运行环境、条件和限制。
功能需求:主要包括功能描述、流程图、岗位角色、数据字典、系统接口。
性能需求:主要包括数据精确度、时间特性和适应性。
运行需求:主要包括用户界面、硬件接口和故障处理。
其他需求:如可实用性、安全保密、可维护性和可移植性等。

在以上列举的内容中，业务和IT之间主要讨论的就是功能需求，而通常的问题也就出在这里。

很多时候，业务向IT提出的功能需求是不够完整、不够详细的，他们也并不一定清楚这样的需求应该包括哪些要素，以及用什么方式来表达。可能只是粗略的流程图，甚至只有功能的列表。

企业IT系统的应用有不同的量级，如果需求不够详尽，开发一个简单的系统可能问题还不大，要是系统相对比较复杂那就是灾难了。需求越粗糙，IT发挥的空间就越大，结果的偏差也就越大。

需求规格说明书中的功能需求应该表述哪些内容？我们可以用下面这张图来表述。

它的内容应该包括：

流程图：系统要运行哪些流程？这些流程不是简单的逻辑图，应该是非常详细的，比我们通常用来描述业务的流程图还要精细。比如我们描述业务的时候可能并不需要精确的表达一些审批环节的退回路径，而面对系统我们就必须精确的告诉它要怎么走。从这一点上来说，IT完全没有人类的聪明。

权限表：系统中有哪些用户，这些用户拥有怎样的权限？这个比较容易理解，必须赋予使用者某些活动的权限，他们才能操作这些系统的流程。

控制矩阵：系统中应该有组织赋予的岗位和角色关系的，就是谁对谁负责，谁是谁的上级，这样的矩阵可以建立相应的控制关系。举个例子来说，一个员工请假，系统需要识别他是哪个级别，属于哪个部门，他的请假要提交给谁。

表单：表单是系统中流转的信息，就像我们在现实中流程也总是要用到表单一样，信息通过它们实现传递、转化和累积，它们是流程路径的缩影。

数据仓库：输入的和流转的信息都可以在系统中储存起来，我们需要告诉系统记录和存储哪些信息，这样信息存储是需要有格式和结构的。结构化的数据能够被很好的应用，就像我们建一个仓库总是要清楚的分区、建目录一样。

报表：业务都是需要管理的，IT系统必须为管理提供支持和服务，这就需要进行数据的统计和报告。必须告诉系统我们需要什么样的报表，给它输入相应的算法和公式，它们才会给我们提供需要的结果。报表的设计常常被忽视，因为它们看起来似乎没有业务本身那么重要，实际这个部分可以为管理提供直接的支持，很能体现管理的智慧。

以上这些内容是需求的核心要素，如果我们能清楚的表述它们，后面的技术本身通常没有什么障碍。这些要素的获取是沿着“业务——功能——技术——数据”这条线来思考的，核心的就是流程，因为流程总是要承载这些要素。如果我们能够把流程梳理清楚，并且匹配这些要素，一切也就豁然开朗。

企业并不总是要自己开发信息系统，很多时候是对成型信息系统的实施和应用。实施这样的系统就是要比对现有的业务逻辑和成型系统之间匹配的关系，哪些部分是要配置的，哪些是要应用的。

信息化的实质是业务变革

开发或者应用IT系统，不管这个系统是大的还是小的，都可以视作是一种业务模式的变革，差别只是变革的规模不同而已。

像ERP这样的大型IT系统对于一个企业来说，是一次非常大的变革。通常有一定规模的企业至少要准备一年以上的时间，否则仓促上线就很难能够成功。首先总是要从业务模式设计和流程梳理开始，最终实现与系统的匹配和平稳运行。

人们说，信息化能够让企业管理和业务运营水平上一个台阶，其实我们应该这样理解，是你的管理和业务运营水平通过设计和变革上了一个台阶，IT只是最后帮助我们将结果固化下来而已。

还有一些比较小的IT系统，涉及到的业务相对简单，比如OA系统。它们的应用与人工操作也总会形成差异，对于这样的系统应用我们也是要经过设计的。有时候就是因为信息系统的简单而我们忽视了设计，最后不是给我们带来了效率的提升，而却是相反的结果。

比如有些企业中涉及到会签的活动，原本应该是一个小组通过沟通的方式来完成的工作，类似于讨论和评审，这样的活动放在IT系统中就失去了信息充分交流的作用，通过会签完全达不到我们预想的结果。于是现实操作中人们就选择首先线下交流，然后在信息系统中再各自去会签，这样的设计实在是鸡肋，不如从前直接线下完成来得实在而且有效率，这样的变革还是不做的好。

一个从流程思考的需求示例

这是一个企业的案例，他们准备开发采购IT系统。首先要做的就是构建完整的采购业务框架。

在这样的业务框架中，我们要考虑哪些功能需要在IT系统中实现，同时与其他系统有什么接口，以及其他管理功能之间的输入输出关系。系统需要实现的业务功能包括：采购计划、采购立项、签订合同、采购验收、发起付款、合同变更。需要考虑和PMC系统、仓储系统、财务系统的接口，需要预算管理、供应商名录管理功能提供输入。这是一个在业务架构基础上的初步思考。

接下来我们描述每一个业务功能的流程图，这样的流程图是全要素的，包括活动、逻辑关系、输出输出的信息、活动的角色、应用的表单等等。