[领域]从业务到抽象，再到业务（2）

从业务问题中来

刚刚得到一件宝贝，是埃森哲给GDYC项目做的业务架构咨询的草稿。说起来，浪潮，浪潮软件，烟草事业部和技术研究中心，真是跟埃森哲有缘，DLYC的那个项目，我们和埃合作，提炼出来一个V3产品，占据了全国烟草的半壁江山。在国家烟草局提出"根据订单组织货源"的全国性策略时，能够提供整体性解决方案的，放眼望去，只有浪潮软件已经具备了成型的产品了，我们由此占得了先机。

我不是售前人员，不想对这个项目或者这个产品加以太多的赞美之词。我其实想说的是，这个产品的成功，应该首先归功于埃森哲对业务的理解和战略方向的把握上。跟他们的合作过程中，我受益颇多。

埃森哲公司不是一家专业的IT公司，在DLYC项目上，他们的很多IT解决方案是跟我们的工程师一起完成的（这是客气话，其实是我们的工作成果转由他们表述而已）。最让我痴迷的，是他们对问题的分析过错。埃公司的团队，分成两个组，BPR和IT组。他们的最强阵容，是BPR组。BPR的工作成果，分为两个重要的部分，as－is和to－be。as-is是对现状的描述，在中期报告中，会对as-is中隐含的问题做出圈定；to-be是对改造后的业务的描述，在终期报告中，这是最打动人心弦的部分。一句话，埃森哲的绝大多数的工作成果，都源于业务，可能会高于现在的业务。

读过《麦肯锡方法》的人都知道，在开篇不长时间，作者就提出麦公司咨询成功的主要因素，之一，就是：不要怕讲真话，虽然它会让某些人不舒服，但还是要讲出来。因为，它是真话。埃和麦都是这一类的公司。他们敢于对业务中存在的问题讲真话，而且，效果也是明显的。（当然，我和我的同事也晓得这其中是有些社会因素影响的，比方说，同样的话，从我们嘴里说出来，客户不买账，但转由埃说出来，客户听上去很受用的样子。对于这种情况，我们只能呵呵一笑）。

又联想到《探索需求》中，温伯格对问题的经典定义：问题＝期望－能感受到的。"问题"是需求产生的基本前提，如果你对"问题"是什么都不了解，何谈会做出一个良好的解决方案呢。

说实话，我也失败过，失败于那些没有需求单靠“拍脑门”来做事情的“产品”。项目上的情况相对会好一些，虽然需求也是变来变去，但终算还是有目标和验收标准的。失败的过程，给我更多的思考。我也成功过，就在前不久，我经历过的一个项目，在业务专家的全程参与下，利用迭代的方式，在国家的5个试点单位中脱颖而出。

还是回到V3吧，当时，我主持会议，征求V3的远景。得到了若干条答案，其中最主要的两条是：

1 v3将融入先进的科学的商业企业管理理念

2 V3将兼容各省市的业务模式

我来征求总架构师的意见，他说这两条都很重要。而在我看来，这两条是非常矛盾和对立的。（现在v3成功了，我才有机会和理由说出当年的困惑，呵呵）。先进，就意味着要废除掉若干的陈旧的业务模式，兼容，就意味着很多陈旧的模式会阻碍系统的先进性。

但现实状况就要求如此，那么我们能做的，就是要在模型层面，对领域进行梳理。可以说，基于对问题的应变要求提出的这样的模型，不会是如同引子中讲到的那种粗粒度的虚幻的景象。BSP(Business Service Platform 业务服务平台)3.0，就是基于业务提炼出来的一个细粒度领域模型，在后续的章节部分，我会针对一些应用场景，反映其中的组织模型和权限模型的某些部分的提炼过程。