信息化的典型问题
如今，信息化在企业中作用无需多言。即使是规模不大的企业，至少也会有财务系统、进销存和小型MES系统等等。大企业更是如此，信息系统的发展也是纷繁复杂，不仅覆盖营销、生产、研发、供应链、服务等业务领域，还包括人力资源、资产管理、财务、质量、办公等管理支持的辅助功能。在这个信息化建设铺天盖地的大潮中，业务和信息化之间的矛盾是一个持久的话题。
这其中有一些典型的问题，比如这样的场景：
1.信息化上线不易，经过策划开发实施，费了好大劲结果还是不满意；
2.系统好不容易上线运行了，当时感觉还不多，可是过了两年就变得怨声载道；
3.业务部门常抱怨IT是瓶颈，我们要的功能到他们那里就打折扣，能力不足总找各种借口；
4.IT总是很委屈，业务部门要的功能总是不能一次性说清楚，今天提一个明天提一个，系统不是这样干出来的;
5.系统建设总是补丁摞补丁的方式，最后发现这些系统都成为孤岛而不能相互联通......
这些都是很具有代表性的现实。不过值得庆幸的是，现在越来越多的企业开始明白了一个基本的道理：信息系统的结果是开始于设计的，IT技术本身从来就不是障碍。尽管如此，那么如何能够做好这个设计的工作，依然是让很多企业一筹莫展的问题。下面我们就来讨论这个问题。
一个整体脉络
信息化的设计，一个基本脉络是经过“业务架构——功能架构——技术架构”这样一个逐步展开的过程。
我们可以通俗而简明地解释这个过程的三个动作：第一是业务架构，先把业务发生的整个过程讲清楚；第二是功能架构，在这个业务过程中，确定需要把哪些活动用信息系统去实现；第三是技术架构，设计信息系统如何去实现这些活动。
以下分别说说这三个部分工作的内容。
1.业务架构
业务架构我们在之前的《EA—企业架构》一文中曾经讨论过，简单说业务架构是描述业务结构和关系的模型。这些描述需要尽可能地把业务说清楚，包括：业务发生的场景、管理策略、组织和角色、权限、流程、规则和标准、传递的表单、报告和数据的要求。这部分完全是业务方面的内容，可以说与IT没有任何关系，是管理的需要。就是说如果你并不是需要上信息化系统而只是为了把业务管好，也需要做这样的工作。
那为什么把它作为信息化设计的第一步？这是基于两个方面的原因：第一，通常企业没有这样的基础，信息化很多时候是能够促进管理提升的，这种促进不是很多人说的上了信息化之后的结果，而恰恰相反是上信息化的前提给管理提出了更精确的要求。第二，信息化和完全人工的方式总会有些差异，这种差异是实际上一种业务模式的重构过程，可能变化很大也可能很小，这要看具体的情况。
比如上ERP（企业资源计划）这样企业规模比较大的核心业务系统，实际上就是一种业务模式的变革。这种变化非同一般，通常要企业用一年以上的时间去做准备，否则成功的可能性就非常渺茫了。记得有一个调查显示中国企业上ERP系统的成功率只有百分之四十多，这还不包括上线持续运行之后发生问题的情况。
在这里我们给出一个示例来说明：清晰地描述企业的现实业务其实有多么复杂。
这是一个企业采购业务流程的全景，因为实在太大而没有办法看到细节，我们可以大概了解一下。首先采购业务包括这样一些基本的环节（红字的部分）：采购计划、采购需求确认、采购立项、采购合同商务确认、签订采购合同、采购过程控制、采购验收、采购付款、采购问题处理。其中每一个环节又包括多种情况（下面的黑字表述的是每个红框里面有多少条流程），比如采购合同商务确认过程中有五种情况：招标、询比价、竞争性谈判、单一来源采购和直接采购。每种情况我们称为一个流程场景，流程场景就是在一个特定环境和条件下呈现的流程形态，就是说每一个场景是一条流程。那么整个采购流程会有多少种场景呢？不是这些数字的相加关系，而是有相加有乘积的组合。可想而知现实流程有多么复杂。
这是放大上面那张图中的其中一小段流程看到的样子。
实际想一想也容易理解这个现实：在一个大型企业里，需要采购的物资和服务类型是非常多的，包括原材料、成品、生产设备、信息系统、仪器仪表、办公用品、车辆、劳务、外协定制加工、土木工程等等，这些采购要求、实施角色、实现方式、过程控制、验收标准、付款方式等等差异都非常大。如果我们不把所有这些都搞清楚，那采购系统到底管哪些事情又怎么管谁说得清楚？
所以我们要做的事情是，描述这些业务的场景以及各种要素，通常需要经过流程梳理和业务建模来完成这样的工作，具体技术细节不在这里赘述。
2.功能架构
在业务架构完成之后，需要构建功能架构，也就是在业务架构中去勾画IT需求，形成面向未来的一个系统功能的蓝图。方法就是在上述那些业务模型和流程中去设想，哪些环节用IT去实现，哪些是人机交互的接口，哪些需要和其他信息系统接口——这有些指点江山的味道。
比如在上面那张放大的一小段流程图中，我们勾画出红色部分是准备用IT系统来实现的，而其他灰色部分的流程是人工的动作。然后再设计出这段流程配合流转信息的表单，就像下图这样。
想象一下这只是我们开头看到的那张采购流程全景图的冰山一角，而整个描述IT系统要覆盖的流程活动需要在那张大图上逐一勾画。这只是一个蓝图或者叫草图，当我们真正要用IT系统实现的时候，描述活动的流程图要更加精细才行，否则IT系统不知道如何处理（IT系统实际上比人”笨“得多）。比如，假设一个审核不能通过，那么是退回到前一个活动还是退回到更早的某个活动，诸如此类的问题都必须要有明确的答案。所以这是不小的工作量。
需要说明的一个问题是，有人认为流程就是研究能够被IT化的那些动作，其实不然，有很多工作是不能够或者不适宜被IT化的。比如这段流程中的技术交流、打印合同、核对文本、合同传递这样的工作需要人工来完成。
在这些用IT实现的流程环节中还需要考虑更多策略，比如我们在构建业务架构时提到的那些要素，流程活动之外还包括角色、权限、表单、数据和管理要求等等，我们要考虑用信息技术来实现的过程中它们可能会有什么变化，有什么技术可以应用，有什么障碍受到限制，可以有什么更好的管理和控制策略等等。这个功能架构的过程是需要业务和技术人员协同工作来完成的，这是在勾画一个业务未来的模样。
这个过程输出的结果是信息系统需求的基础，我们通常是用系统需求说明书（或者规格说明书）的方式展现出来。下图示意了一个需求说明书产生的过程。
3.技术架构
业务和功能的需求出来之后，还差最后一步技术架构，技术架构就是纯粹的IT工作了。从信息化实现的角度给信息系统描绘一个蓝图，包括数据架构、应用架构和技术架构。这部分内容在之前的文章《EA—企业架构》中我们已经讨论过就不再赘述。
给信息系统的输入
经过这样一个过程，我们才真正的为信息系统开发和实施提供了一个设计的输入，而现实我们是这样做的吗？我见过一些企业做的信息系统需求的文档，里面都是功能的罗列和说明，偶尔有流程图也简单得可怜，这样设计出来的系统就是孤岛，企业穿上这样的衣服如何能够“合身”呢？
这个”输入“还有一个非常重要的功能，用来对开发出来的信息系统进行测试和验收，确保这是我们想要的那个系统。这个过程同样是不可缺少而且需要有尽可能明确的标准。它实际成为业务和技术人员对话的一种语言，其实业务和技术人员之间的矛盾就在于此——他们缺少一个共同的语言。
我通常会告诉他们这样一句话：设计越详尽，实现越简单。
现实中企业实施信息化，更多的工作应该在前端，就是“业务架构——功能架构”的部分。这个过程不仅仅是产生信息化需求的过程，也是思考业务的过程，很多时候也伴随着流程优化。
很多信息系统开发和实施过程还会有前置任务，比如实施ERP系统之前可能需要重新定义物料编码，实施MPM系统之前可能需要重新梳理产品技术状态，这也使得信息化系统实施的工作变得更加漫长，但同时管理提升的作用也就更显著。
多几句闲言碎语
信息化的未来是不是会“消灭”人的工作？我们看看那些著名的高科技公司：亚马逊无人的物流中心仓库让我们叹为观止，而亚马逊实际上是一个拥有54万员工的巨无霸公司；Google是名副其实站在高科技前沿的公司，它有超过10万正式员工，还有超过12万承包商给它做外包服务。如此说来信息化不是在消灭人的工作，而是在改变着人们工作的方式和形态。
不管现在智能化的呼声有多么高涨，信息化都是眼前绕不开而且必须走好的路，在此之前说智能化就是痴人说梦。路总要一步一步的走，企业成熟靠一天一天长大。在我看来，后发优势和弯道超车都是教唆人们不走正路的胡扯，最直接的路总是最坎坷，只有经历了这样的路才能踏实。
