资源|中台建设：不只是IT工具，更是组织布局( 二 )

例如，一家酒店集团的供应链部门作为业务中台提供的弹药，应该是供应链能力。供应链能力具体包括什么呢？看得见的是“资源”的构成，即整合供应商提供的设计、装修、供材、信息系统资源；看不见的则是“规则”的导向，包括供应商准入标准、甄选标准、服务标准等。“资源”只有进入“规则”的框架，才能成为可以被前台使用的弹药。
另一类情况里，“资源”和“规则”就是一回事。例如，金融机构的风控部门作为业务中台提供的弹药，应该是风控能力。他们看似常常都在说“这不行”“那不行”，但他们却是以自己的风控知识（模型）来对具体业务进行判断，他们的风控结论也会进入最终的产品里。他们提供了一种非实物形态的弹药，既是资源（知识），也是规则。
对于业务中台应该把资源池里的资源变成中间件，已经是不用争论的共识，在考核上，自然是关注资源经营的效能（Efficiency）；但对于其如何把平台规则变成中间件，尚且存在认知盲区，也没有明确的考核标准。
过去，很多人把规则设计相关的职能统一放到后台，认为后台设计的规则只要足够有弹性，自然就可以应对一线作战的复杂需求。实际上，这是不可能完成的任务，或者说，这种判断根本就是缺乏对于组织规律的认知。规则是死的，市场是活的，一定要有人基于基本规则去做不同应用场景的匹配。规则也应该有中间件，这也应该是业务中台的主要任务。其实，如果没有这一块职能，业务中台要想把后台传递过来的资源经营出好效能，是不可能实现的。
所以，我们既可以说业务中台应该对资源的效能负责，也可以说业务中台应该为平台的规则负责，这两者之间并不矛盾，而是高度统一的。在过去，大多企业所谓的“业务中台部门”似乎更强调自己在落地规则，而没有强调自己在经营资源。他们实际上是带着后台的脑子走到了业务中台，是“伪业务中台”。
我们甚至可以大胆地推断，大多所谓“业务中台”部门强调自己的主要职能是“落地规则“，本身也是因为这个职能难以考核。试想，如果业务中台要主张自己落地（坚守）了后台的规则，“一刀切”地当个规则的二传手，不是很容易吗？
我的建议是，把考核倒过来，从主要考核落地规则，到主要考核经营资源的效果。只有如此，他们才会以经营资源为前提，考虑如何弹性地适配规则，为前台找到经营空间。
进一步看，一个能够真正“落地好规则”和“经营好资源”的业务中台，应该拥有三项能力（如图2）：

连接能力——连接内外部合作者的能力，能够监管住合作者，让合作者交付有质量的服务，相当于盖木屋时取到合适木材。如供应链中台连接供应商的能力，再如生产部门连接设计部门的能力。
整合能力——基于自身对于某一领域的理解，将各种服务进行整合的能力，相当于把木材搭建成一个木屋的基本框架。如供应链中台设计各类流程和标准，让供应商能够各司其职，高效服务于生产。
交付能力——基于自身的基础能力，按照前台要求进行定制化交付的能力，相当于按照（前台）客户的要求对木屋进行一定的个性化。如供应链中台根据前台的特殊需求，给出弹性的服务。

文章插图
图2：业务中台的三项能力要求资料来源：穆胜咨询
03 数据中台建设的本质无论以“落地规则”还是“输送资源”的形式输送弹药，本质上都是业务中台沉淀知识的外化。知识，在这个时代是以数据为表现形式的，以数据来呈现知识，也是最高效的方式。数据中台是业务中台高效运转的根本支撑。
当然，数据只是一个大概念，现在的时代，任何人都可以毫不费劲地高呼“数据就是一切”。但数据从哪里来？如何在“落地规则”和“输送资源”上发挥作用？
让我们先回到知识的概念。我认为，在数字化的时代，知识有三层：

指标（Indicator）——将看到的事实变成数字，进入一个绝对标准化的对话频道。例如，将人才的某项素质变成分值。
模型（Model）——连接数字，说明数字之间的关系。在程序设计的语言里，有点像函数（Function）或子程序。例如，按照素质模型的5项维度来计算人才素质的综合得分，这就是一个简单的模型。
框架（Framework）——连接模型，说明模型之间的关系。在程序设计的语言里，有点像类库（Class Library）。一项“落地规则”或“输送资源”的赋能，一定是依靠综合知识的支撑，一定需要调用某个领域的若干模型。例如，要为前台经营单元输送人才，需要综合经营单元里角色的素质、经验、技能等级等模型，甚至要考虑人才的业绩产出节奏，再计算出候选人的适配程度，选出最合适的人。
- 上一页
- 1
- 2
- 3
- 4
- 5
- 6
- 下一页