对业务和IT关系的讨论，这个话题像猫和老鼠一样古老。

坊间讨论最多的有这么几个话题，1）业务和IT，孰轻孰重，潜台词也就是谁听谁的问题；2）业务和IT如何对接，专业说法叫对齐（Alignment）；3）技术如何应对技术变化，怎样才能不成为业务发展的羁绊。下面就这几个问题逐一谈一下。

1、业务和IT的协作

技术为业务服务，这个基本上没什么好讲的，技术的价值通过业务运营的产出体现。在IBM的资料中看到过专门描述业务与技术的关系，分为三个阶段，支撑关系、伙伴关系、引领关系，这个可能让很多人误解，无论技术多么重要，最终都要通过业务体现它的价值，因为技术只有在产品和服务化之后才能盈利。再来谈一下业务规划的问题，这个是讨论的焦点，我们关注的是脱离技术能不能做出合理的业务规划，显然是不行的（姑且认为这是个假设），为什么？因为业务规划要考虑其运作（实现）的方式，注意这里说的实现不是具体的技术实现，是较高层次的实现，所以叫运作好一点。我们知道，业务规划的核心是业务流程的设计，高层次的流程可以抽象到运营模式，信息化的一项重要工作就是实现业务流程的数字化，问题来了，哪些流程或者流程节点应该是通过数字化的方式实现，哪些是人工的方式实现，业务规划人员必须要清楚，否则设计出来的流程就是与现实脱节的，比如说1）指纹打卡、电子支付（比如AliPay、PayPal）等技术的出现，业务人员在做考勤管理、财务结算的时候就要知道这些可能的替代方式，否则会计电算化的时代你设计的流程还打算盘呢，就有问题了；再比如2）云计算应用起来后，企业就要考虑业务是否需要外包，比如小企业的人员招聘、工资管理、记账等业务，如果外包的话，企业就要转向人力资源需求，而不是设计招聘流程。再比如3）大数据技术出现后，传统的营销的方式会发生改变，以前做不到快速精准营销，现在可以做到了，企业营销流程要调整，提供针对精准营销对应的服务。企业也可能使用第三方的大数据分析服务，比如宝马汽车使用阿里的大数据分析服务，发现自己的潜在客户，这时候也需要有相应的业务流程支撑这些业务活动的展开。讲这几个例子的目的是为了说明业务规划需要清楚地了解实现方式的变化，有人说，了解技术趋势是IT部门的事情，实际上，这个只是中间过程，最终要体现在业务规划上，要负责规划的人清楚才行，否则上面已经讲过，无法做出合理的业务规划。

实际上，业务规划最佳的方式是业务和IT人员一起做，至少人频繁的互动，这样才能比较好地实现业务、技术融合，达到业务设计高效的目的。业内像华为、三一、宇龙的组织设置都是流程与IT在一起，这样至少对外是一致的，所以本质上如果业务和IT出问题，就是机制的问题，或者说是老板的问题^_^。

研究方法论的同学应该对参考模型这个概念应该很熟悉，选取参考模型的活动通常出现在未来设计的第一步，选参考模型干什么，当然是用来抄的，除了参照的作用之外，参考模型还有很多学问在里面。其实参考模型还解决了一个令人纠结的问题，就是业务和IT的关系，到底是先看一下有哪些技术可用来规划业务，还是先规划业务再来看有哪些可用技术，业务参考模型（参考模型根据领域划划分有多个类型）解决了这个问题，简单地说就是，你看看人家的业务流程是怎么设计的，标杆的业务流程已经融合了最佳的技术实现。实际上，IBM早就在自己的方法论中考虑到了这个问题，IBM有个PEBT方法论，全名叫做软件包驱动的业务转型，也就是基于选定的套装软件再来设计自己的业务流程，比如你买了SAP套装软件（根据自己的需求选型的结果），在很大程度上要接受SAP的管理思想、业务流程，当然可以通过实施定制化，但是用过SAP的都知道，代价很大。

2、业务与IT匹配问题

对于业务与IT的关系，老外搞了个词叫Alignment，中文翻译过来叫“对齐”，这个说法有时候会误导一些人，需要深究一下。很重要的一点是，业务和IT不是简单地对齐，而是转换，信息化是对业务的重构，不是简单地实现。有些说法是，业务规划好了，交给IT部门实现，这种甩手掌柜的做法很常见，基本上这是导致信息化出现问题的主因，业务规划IT部门参与不足，IT实现的时候，业务部门也参与不足，最终结果是验收的时候口水满天飞。为什么说信息化是对业务的重构，因为实现方式变了，原来住农民房的，现在住楼房了，上楼得坐电梯，做饭不用烧柴禾了，改用煤气灶了，生活方式变了，会不适应。这是为什么软件开发过程中要让业务人员持续参与，说穿了就是早点适应，有问题早说，别等到最后一看不认识了。根本原因是，业务在业务人员和IT人员眼中是有区别的，甚至区别很大，我们在研究业务流程建模的时候就会涉及到这个问题，业务人员设计出来的是业务流程，纸面上的，基于图的，系统里面跑的流程是系统流程，基于块的，一个个节点下面关联的是服务或者直接关联代码，业务人员画的基于图的肯定跑不了，得转换过来，BPMN2.0号称用一套规范来对付业务人员和IT人员，难度比较大，冗余太多，我们自己设计的流程建模工具有比较深的体会，很难即对业务人员友好又对IT人员友好。业务到IT两个视角的转换工作谁来完成呢，系统分析师（SA），系统分析要即对业务熟悉又对技术熟悉，这个角色非常重要，首先是个翻译的角色（Business Case to SystemCase，业务用例和系统用例，做系统分析的人清楚这两个东西的区别），业务人员最喜欢和系统分析师打交道了。一般在企业里面，IT部门作为业务承接方对业务是很了解的，原因很简单，整天和业务部门打交道，不懂业务是不正常的，除非是太懒了，企业中业务和IT部门之间的问题更多的是责权，而不是懂不懂业务。实际上容易出现问题的是软件厂商和咨询方（国内的甲方经过多年的成长，对IT知识、方法论和咨询公司的做法已经比较了解了，所以你会经常听到有些甲方也是滔滔不绝^_^），如果不是在一个领域耕耘多年的话，容易出现和甲方的情况脱节。最后，通过下面这个旅行前定机票酒店的例子看一下业务人员视角和IT人员视角的不同。

3、技术如何应对变化

哲学里面有句话叫“科学是时间的函数”，实际上，万物都是时间的函数，也就是说什么东西都是动态变化的，包括业务和技术，变化是正常的，不变就挂了。设计人员的职责就是应对不确定性，尽量找出规律，让不确定性变得可控，让设计能够应对变化（至少在一段时间内，比如三到五年），通常抽象程度越高，应对变化的能力却强。为了做到这一点，各行各业的大师们想出了很多办法，比如各种搞清楚需求的方法比如调研访谈、标杆客户考察、领域建模等各种分析模型，心理学都用上了，各种响应变化的方法比如模块化、流程编排、服务化、事件驱动，各种通过分工协作降低风险的方法比如人力资源外包、流程外包、产业链协同，还有各种小步快跑的方法比如持续改进、快速迭代等等，当然人的经验很重要，工具也很重要。方法有很多，多到数不过来，但是没有一劳永逸的设计，认识到变化是常态就可以了，信息技术还是个很年轻的行业，还在快速变化中，而且是跨学科的，设计师们只有内外兼修，做好长期修行的准备了。最后，很重要的一点是沟通，其实很多问题出在沟通上，尤其是跨部门协作。