08 | 中台落地第三步：中台的规划与设计（Design）

Sep 25, 2019

08 | 中台落地第三步：中台的规划与设计（Design）-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

08 | 中台落地第三步：中台的规划与设计（Design）

2019-09-25 王健来自北京

《说透中台》

课程介绍



讲述：王健

时长19:39大小17.99M



你好，我是王健。
前两讲我们通过 Discovery 结合 Define，完成了 D4 模型中的第一轮在企业级别的发散和收敛。我们站在企业的高度，基于企业愿景和内外部环境，通过自上而下的战略分解和自下而上的现状调研，再应用企业架构方法的分析，来确定最终的平台型企业架构，并回答到底要不要建中台、需要哪些种类的中台建设、谁先建、谁后建这些问题。
那从这一讲开始，我们就要进入 D4 模型的第二轮发散和收敛。站在一个中台产品的视角，来看看到底应该怎样对其设计并落地实施，也就是 D4 中的 Design 和 Delivery 的两个阶段。同样，本讲先从 Design 开始，我们以一个业务中台的设计和实施为样本，讲述一下这个阶段的思路和关键点。
好了，这时候还需要借用一下极客地产的例子。
我们假设，经过了第一轮企业级的的调研与架构设计，小王及其团队发现确实迫切需要构建一个极客地产自己的业务中台，来实现企业 2022 年的战略目标，也就是从重资产业务为主向轻资产的服务业务为主转型，更好地为极客地产的用户群体，即 IT 从业人员提供多场景服务。
那下一个问题就来了，这个业务中台该如何构建呢？业务中台的搭建又需要从何开始呢？
这节课我们就一起探讨下中台部分的具体设计和启动问题。在当前的这个例子，就是对于极客地产的业务中台（后续简称极客中台）的设计过程。
在设计阶段，我们需要回答的问题就是极客中台的愿景是什么？包含哪些内容？从哪儿开始落地？完成设计阶段，应该就能清晰地知道如何开始进行中台建设，可以让团队开始中台 MVP 的开发工作了。如果对于什么是 MVP 不太清楚，不用担心，后续会介绍到。
确定中台产品愿景讲到现在，你肯定知道了，第一步还是要先搞清楚这个业务中台的愿景和目标，因为这是我们整个中台建设过程的基础，也是中台建设的初心。
还记得我们之前提到过的么，中台的建设就是一条布满荆棘之路，充满曲折。在过程中我们会遇到各种各样的问题与选择。而一个好的中台愿景能让我们始终保持初心，不轻易迷失方向。
那如何来为中台制定一个好的愿景呢？我一般到一个企业去做中台相关的咨询时，我问对方中台建设负责人的第一个问题都是：你们说要做中台，那中台建设的愿景是什么？
我得到的大多数都是肯定的回答，毕竟没有谁会承认自己的项目连个目标和愿景都没有。但是一旦追问到愿景具体是什么的时候，一般就会开始一段漫长的讲述，从公司的历史到现状、从行业聊到企业管理层最近的讲话，总之我总结下来就是：领导说要做中台，我们做就是了。
我认为这样是比较危险的。毕竟我们前面提到过，中台的愿景作为所有问题的出发点，需要足够简单明确，才能做到像一个指南针一样，成为我们中台建设过程中指引方向的工具，也才能做到前面提到过的“遇事不决看愿景”。
这里推荐给你一个简单好用的工具，我们经常用这个工具来帮我们发散和收敛产品的愿景，当然对于中台也是同样适用的，就是电梯演讲（Elevator Pitch）。
顾名思义，电梯演讲假设的场景，就是我们在电梯上偶遇公司管理层，能否在有限的时间内给对方讲清楚我们在做的事情，比如中台。这就要求我们做到足够的收敛。因此电梯演讲的形式，主要是限定了几个产品最关键因素，比如用户是谁，解决什么问题，差异化特点是什么等等。其中每一个要素都非常重要，如果你回答不出来，或是团队的回答不一样，就在一定程度上体现出大家对于中台建设的愿景还没有达成一致，也就为后续各种问题的出现埋下了祸根。
你不要小看这么一个小小的电梯演讲，感觉只要回答几个问题就可以了。从我实际的经验来看，每次规划中台产品愿景的讨论都会超时，一开始觉得可能这么简单的事情，一个小时就能搞定了，后来因为讨论过于激烈，时间拓展到半天时间，到现在我们一般都会预留半天甚至是一整天的时间，来做中台产品愿景的充分发散和收敛。
但即使我们花了这么多的时间，我仍然认为这是十分有必要的。在愿景的讨论上花再多的时间也是值得的，因为这会影响我们中台设计与建设的后续走向，一旦形成，也就会成为我们中台建设的基础，这一步的重要性怎么渲染也不为过。
这里有一个问题，还是要提一下，愿景的价值和难点就在于充分收敛。但我见过很多企业的愿景虽然也用了电梯演讲的方式，但是结果满满地铺了一面墙，看着虽然震撼，但是其实效果是大打折扣的，毕竟我们也没法在一个电梯时间复述完一整面墙的内容。还是那句话，做加法易，做减法难。
确定业务梳理范围中台产品的愿景确定后，下一步就需要进行细粒度的业务架构梳理，抽取共性，识别中台产品的具体需求了。
但是，同样是企业级的原因，此时我们面对的问题往往就是不知道该从哪里下手。毕竟中台有企业级属性，就算是业务梳理也会涉及到企业的全业务线，而且是端到端全流程的梳理工作，工作量之大也往往让人望而却步。
是不是所有的业务线都要梳理？是不是端到端的所有阶段都要梳理？业务梳理要到什么样的粒度？这些都是经常面对的问题。
一般到这里，不同企业的情况就不一样了。如果公司整体规模不是特别大，其实做全业务端到端的业务梳理也是可以的，而这样的好处也是比较全面不容易出现遗漏，对于企业的业务现状能有一个整体的全貌，识别的中台共性需求也会比较准确。
但是很多企业，尤其是中台诉求最高的往往是一些多业务线的大型集团型企业。对于这种规模的企业，做全业务的端到端梳理基本上是不可能的，要不然仅仅是协调人员就是一个麻烦的问题。这时候我们就需要先确定一个范围，再在这个范围内进行业务的梳理和展开。
那这个范围该如何划定呢？还是那句，遇事不决看愿景，这时候我们前面讨论的中台愿景就有用武之地了。
还用极客地产为例，中台建设的愿景是希望通过将成熟业务的能力进行沉淀，并复用到其他新型的轻资产业务线例如长租公寓业务中，通过能力的复用快速实现业务的轻量化转型（具体的电梯演讲这里就不展开了）。
而目前的情况是，极客地产专注于服务 IT 群体，地产和物业业务发展成熟，有了非常健全的 IT 基础设施。现在针对这一人群挖掘出了很强的长租公寓需求，但是长租公寓作为新的业务线，无论是从投资拓展、设计、招标采购、工程建设、装修改造、客户管理到物业运营等等，这些方面都是从零开始。
回到业务梳理范围的问题上，有了清晰的愿景，就可以让我们的业务梳理更加聚焦。
首先从业务线上来看，就不一定所有的业务线都需要梳理。还是看极客地产这个例子，旗下涉猎广泛，还有业务线专注在投资、文化和教育等方面，因为这些业务线都是长期独立发展，与前面提到的极客地产中台产品的愿景目标也没有太大的直接关系，所以可以先直接跳过。
然后就是从端到端的业务价值链上。通过分析，由于企业的战略是轻资产服务化，所以对于像地产行业的工程建设，也就是盖楼盖房的部分，与企业基于轻资产战略投注的新业务都不适用，所以也不需要再进行梳理。
至此，基于中台的建设愿景，我们就可以在横向端到端价值链和纵向的业务线上收敛到一个聚焦的区域。
再在这个聚焦的区域中进行业务梳理和展开，就会更加有效率和聚焦。
细粒度业务梳理在确定了梳理范围之后，接下来就是具体的业务梳理工作了。
一般大家的做法都是基于现有的流程或系统，对现有业务的流程进行梳理，例如在电子商务领域大家经常提到的四流，具体指的是信息流、商流、资金流、物流的梳理工作，使用的工具也大多是流程图这种非常成熟的工具。
但是这种基于已有流程的梳理有时候会有一些限制，简单讲就是可能会基于过去遗留的业务债推导出伪中台需求。什么意思呢？就是对于一些长期且成熟的业务，现有的业务方式可能并不是一个最好的方式，而是由于长时间发展以及和过去的各种周边限制以及 IT 限制妥协的产物。
举个例子，往往时间比较长的业务线都会有非常复杂的审批审核流程。但是审核和审批流程其实只是一种解决方案，要解决的问题可能是过程造假或是其他的一些内部风险和问题。复杂的审批流程也往往是信息化时代甚至是更早的纸质时代的过程管控的产物，由于信息化更多只是将线下的流程线上化，所以一直延续至今，而且为了高度复刻还原纸质时代的流程，还非常中国特色地出现了各种的奇怪的审批逻辑，例如会签等等。
但是如果我们重新回到问题域，重新思考问题本身，我们就发现可能在当今这个数字化的时代，在大数据和 AI 已经广泛应用的今天，甚至可能不再需要流程审批这样一个过程。通过新的技术，我们可以用实时的审计分析或是风险识别来发现业务过程中的一些异常，甚至通过完全的自动化，消除中间人员参与的环节，从根本上解决这些问题，从而真正发挥数字化的威力。
这种回到问题域本身，回到问题的原点，基于用户需求在当前的业务及技术条件下，重新设计解决方案的思维方法，可以避开上面提到的业务债陷阱，也多用于创新型业务的设计过程，而这种思维方式也大量参考和借鉴了设计思维（Design Thinking）的方法。
所以和基于现状的传统业务流程梳理不同，我们在业务梳理过程中大量地采用了基于设计思维，结合用户体验地图（User Journey Map）和服务蓝图（Service Map）的方式。回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理，从效果上来看也是非常不错的。
当然不是说哪种方法更好，不同的工具和方法有不同的适用场景和优劣势，如果都能灵活掌握，甚至可以结合使用，充分发挥出各自的优势。
通过范围内的业务架构梳理，再结合最后的跨场景通用能力的分析，我们就可以对关注领域的业务全貌有了一定深入的了解，并且可以识别出不同业务线中一些可复用的业务数据、业务功能与业务流程。而这些通用的业务数据、业务功能、业务流程经过加工分析就形成了中台的具体需求。对于这些需求，我们是通过用户故事（User Story）的方式描述的。
确定 MVP通过业务梳理，我们识别和整理了大量的业务中台需求。值得注意的是，此时的所谓中台产品需求，更多的是来源于定性抽象，再考虑到中台的需求往往不像前台业务系统的需求那样明确，所以，从严格意义上来讲，此时的需求仍属于一系列高风险的假设。
从我实际参与的中台建设项目来看，往往这些一开始设想的中台需求，到真正开发完成之后，都与最初的设想有很大的偏差。这就意味着，中台建设的周期越长，需求假设的风险和需要为之付出的代价就越大。
所以，我们在中台的建设过程中，引入了精益创业中的 MVP 原则（Minimum Viable Product，最小可用品），也实现了我之前提到的整体原则中的 Start Small。
为了实现 MVP，保证做出来的 MVP 可用，我们在业务需求上采用端到端纵向切分的方式，结合需求优先级的多维度评分排序，最终确定 MVP 的需求范围，而最终落地的形式可能就是第一个迭代的用户故事列表。
那已经有了具体的用户故事列表，是不是我们就可以开始着手开发了呢。先别急，有两个事情，我们建议在开始中台建设之前就需要考虑，那就是运营计划和度量指标。
运营前置：制定迭代计划及接入计划首先我们来看看运营计划。对于中台可能就是中台产品推广、前台（用户）接入计划以及接入后的运营支持。
我过去看到的情况是，中台建设的中后期才开始考虑这些问题，往往就有些晚了。而且很多情况下，前台是不会停下来等中台建设完，等接入后再开始自己的业务演进，所以往往都是前中台并行。
这个过程就很像是我们开发中的分支开发一样，修改的又是同一块内容，所以当合并的时候就会非常痛苦。
所以提前考量运营计划尤其是接入计划，尽量使用合理的接入计划（我看到有很多企业把这个接入计划叫作上车计划，非常形象）来规避一些风险，对于中台产品的建设也非常关键。具体的运营策略，在下一篇中讲为你展开介绍。
度量前置：定义验证指标另一个需要在中台产品建设开始之前就要想清楚的就是度量指标。这一点，不知道你是否还记得，我们在之前讲中台建设前需要想清楚的四个问题时，已经讲到过了。具体为什么需要将度量指标设计前置到开发之前，之前已经阐述过了，在这里我就为你分享一些度量指标的设计思路。
首先，我们先来看看一般我们常用的有哪些指标。我把市面上最常见到的产品度量指标，分为了四个大类，也就是战略类、用户类、市场拓展类与降本提效类。基于每一个维度展开，都能找到很多的常用度量指标。
而对于中台来讲，难就难在与市场和用户之间还隔着一层前台，所以在度量上就不如直接接触用户的前台系统这么清晰。但是我们讲中台是为前台业务赋能的，又不能脱离开业务，单纯只在技术上做一些度量，例如接口稳定性和接口数量等，这样也不符合中台对于业务支撑赋能的定位和价值。
所以我们一般在考虑中台的度量指标的时候，还是把战略价值和业务价值作为出发点，开始拆解和推导，并且按照干系人关注点的不同，用多维度、多层次的指标设计来审视中台建设的效果。这里要强调一下，虽然维度和视角不同，我们要保证所有指标体现的中台建设目标必须是一个。
而具体到实施方法，因为每一个中台产品都是不一样的，所以很难给一个标准的答案。在实操过程中，建议你多换位思考，多问几个“怎么（How）”。相信你比较熟悉 5Why 分析法，这里我们可以稍微改一下，用 5How 来驱动验证指标的设计。
举个例子，如果我站公司管理层的视角：
那我怎么判断中台建设的成果？如果回答是看对于新业务的赋能，
那我怎么验证对于新业务的赋能效果？如果回答是看新业务的上线速度，
那我怎么验证新业务的上线速度？如果回答是看新业务从立项到上线的时间，
那我怎么验证……
你看，大家经常会说度量比较难，其实每个人心里都有一杆秤，只不过我们没有把这个秤清晰地表达出来。通过 5How，我们可以不断追问，将每个人心中的这杆秤发掘出来，来更好地指导我们中台产品的建设和推进。
总结思考本节课以一个业务中台的建设过程为例，以业务中台的愿景作为切入点，介绍了电梯演讲的工具，再基于中台建设愿景，明确业务梳理的范围和优先级。
明确了业务梳理的切入点和范围之后，我们就可以基于设计思维进行以用户为中心的业务流程梳理和服务设计了，再结合领域驱动设计进行业务模型梳理，最终再通过跨业务线的综合分析，识别共性业务数据、业务流程、业务模式的中台需求。
之后通过引入精益创业中的 MVP 原则，对于中台需求基于业务优先级采用端到端纵向切分的方式，最终确定中台建设的启动点，也就是第一阶段的具体建设内容。
最后有了中台产品运营机制和度量指标的分析与设计之后，我们就可以正式地立项并进入到交付阶段具体实施了。
那下一讲我我们就正式进入到 D4 的最后一个阶段，也就是 Delivery 的交付阶段，看看我们在交付阶段使用的思路和方法，以及要注意的问题。
最后给你留几个思考题：
你们的业务梳理过程是怎么样的？中台需求是怎么分析出来的？
你们采用了 MVP 原则了吗？是如何规避中台建设的需求假设风险的？
请在留言区写下你的思考，和我一起讨论，也欢迎你把今天的内容分享给身边的朋友，和他一起学习，我们下一讲见！

分享给需要的人，Ta购买本课程，你将得9元

生成海报并分享

赞 7

提建议

07 | 中台落地第二步：企业数字化全景规划（Define）

09 | 中台落地第四步：中台的建设与接入（Delivery）

 写留言

精选留言(22)

贝特
2019-10-07
对于中台的设计，绝大多数场景是基于现有的架构进行重构或者改造，基本上没有针对新项目直接设计中台模式，也就是说中台是软件架构发展过程中的一个迭代产品，所以满足迭代的要求也是在设计阶段必不可少的，例如要解决当前架构中的那些问题，如何兼容当前的接口，兼容当前的业务流，改造之后的中台要提供那些能力，具备那些模式，对成本、人力、技术的要求是什么，这些都需要回答清楚，并作为度量指标，确实挺难得，搞不好就是一地鸡毛。不知道理解是否深入，欢迎探讨。
展开
14
业余草
2019-10-11
发现很多公司跟风，为了微服务而微服务，为了中台而中台。中台的劣势是什么？
作者回复: 业余草，你好~ 好问题哈，中台的劣势比较难回答，我认为如果说中台就是平台型企业架构的话，那简单说我决定劣势有三点： 1. 原来的一层架构，变为两层架构（中台层和前台层），所以多了一层之后会带来中台与前台两层之间的摩擦，无论是从组织还是从业务上的。 2. 有了中台，其实会对于前台的业务会有更多的限制，毕竟不能自己爱怎么做怎么做了，需要遵循中台的一些规范或是业务模式限制，所以也会在前台业务的灵活性上受到一些局限（好处是可以借力中台赋能）。 3. 中台还有一个劣势就是太难推进，太难建设了，我觉得一件事情太难，本身就是最大的劣势，只有容易且收益大的事情，才更容易被实施。所以说中台的建设是有成本和副作用的，还是要先想清楚了，自己到底需要不需要，必要不必要，再开始，但一旦开始也要有些决心和耐心，阳光总在风雨后，没有事情能随随便便成功哈~
共 2 条评论
11
钱
2020-02-05
功力有限，我的感觉老师讲的主要是管理者视角，不是具体实施者视角，至少不是技术实施者视角。因为思考的问题是企业级的，思考的方式是愿景战略自上而下的，决定的事情主要是选择做什么不做什么，是大块的事情是在选择题而不是具体如何实现。有点像项目管理，不过又没有项目管理细致，学了之后想立杆见影的有升职加薪的想法是不现实的，不过如果有机会搞中台也许是有用。
5
Farewell丶
2019-10-01
我们前段时间的一个项目就是个反例，在前期，由于一个业务线已经开始开发，而我们刚进入设计评审阶段，被大领导建议讨论是否能够合并到一起，做公共的部分后。没有进行充分讨论，被新来的对公司还没有很熟悉的技术总监拍板，“都可以兼容~”。做到现在项目人心低迷，一期上线BUG众多，项目内部到处都是类似IF ELSE的租户兼容逻辑。拖的所有的研发，测试，运维在后边还债。进而引发了部门间，产品和研发以及运维之间的不信任。更进一步的加重了现在整个项目的病情。技术总监已经开始隐身，准备他下一步的计划了，搞中台[捂脸]，我好虚~~
展开
作者回复: Farewell，你好～又见面了哈，感谢你分享自己的实例，这样的例子见的太多了…… 中台不是简单的把“看起来差不多”的东西放到一起就可以了的，这其实特别危险，不然没法做到我们说的增加响应力，反而搞不好就会拖慢响应力，中台变成了另一个大泥球和瓶颈点。所以中台要做严谨的分析与设计，到底找到那些“看起来差不多”的业务功能背后到底有哪些是相同的那些是不用的，然后通过合理的抽象和设计进行分离，总结篇的滴滴和阿里交易平台都是好例子。而如果只是在中台里不停加IFELSE，那其实还不如把逻辑都放回前台的好，响应力可能还更强一些。所以我一开始就说了，我们经常把中台想简单了，轻敌了：）不过这也算是中台建设过程中大家都会经历的阶段，从现在开始重新做设计和治理改造，应该也还掰的回来。期待你的更多留言分享～
4
我叫阿杜
2019-12-17
遇事不绝看愿景？
作者回复: 张玉鹏，你好~ 是遇事不决看愿景哈，意思就是当遇到问题不知道该如何抉择的时候，就想想中台最初的愿景，也就是建设的初心，往往能够豁然开朗~
3
亚东
2019-10-09
突然明白为啥敏捷开发会啥会这么适用于互联网行业了，关键点就在于User Story。这就从一开始就以用户为中心。
1
Tony
2021-10-20
这章的中台的愿景和目标，和落地第一步的愿景和目标有什么联系吗？是不是同一个事情？
小炭
2020-11-07
是很好的思想，只是要找到适合它的企业然后有效的实施。这太难了……
陈
2020-11-01
回想中台的定义，企业级能力复用平台，感觉中台的最终呈现依然是平台，技术型平台，但真正的难点感觉是针对企业级能力复用而带来的业务、愿景、组织、实施的重新审视和重构，大型企业中业务愿景相对比较稳定，难度在于梳理和资源协调、利益平衡，支持决心等。对于中小型互联网公司，很多时候为了活下去业务和愿景可能都在不断变化，中台化思维去建设平台反而会是拖累。
阿豪
2020-05-02
Define阶段需要做“平台型企业架构规划”，有8个步骤，包括业务架构梳理和结合DDD做的应用架构梳理。Design又重新对细粒度的业务需求进行了梳理，并且结合DDD进行业务建模和服务设计，最终目标是识别出共性的业务数据、业务功能、业务流程和业务模式需求。请问具体的差异只是粒度吗？Define阶段只是到功能粒度，Design到模块粒度？
Fibee
2020-03-24
听了可能有四五遍，正好在开始一个业务中台的建设。在不知道如何下手时，跟着老师的这个课程设计一步一步做到design。我现在有些迷茫的是我是要基于多系统整合的，这些系统里面有很多线上数据，中台建设前也需要考虑异构系统的数据如何处理。以及研发跟产品团队已经组建，研发目前在做技术选型，但产品面对那么多的系统整合，业务线要梳理怎么快速开展，还是有些迷茫。是
hellojd_gk
2020-03-21
数据仓库，数据分析的相关工作，是中台的吗？感觉不想，但他却需要汇聚多业务部门
大漠孤烟
2020-03-19
我们在做电商平台的时候，第一版本上线的内容，一般都用MVP原则。
杜do度
2020-01-06
越看越觉得是好东西……看中台，我怎么老是莫名的想到产业互联网……
悟空
2020-01-06
王健老师，您好：在【细粒度业务梳理】这个章节中提到：“基于已有流程的梳理有时候会有一些限制，简单讲就是可能会基于过去遗留的业务债推导出伪中台需求。” 实际组织中，一般的新平台建设思路，都会尽量不触碰改动原有的系统，因为业主的要求（不希望触碰或者变动原有的运营模式或者利益分配）。这一点，特别是在政府、金融等保守机构和行业中非常明显，甚至是政治正确。面对这种情况，您有没有什么好的建议，或者实践的一些故事、经验？
展开
FF
2019-11-25
老师你好。几个问题请教下。确定业务范围那块内容，梳理业务线的时候，没看懂如何梳理聚焦出业务的。讲得有点简单。问题一：什么是端到端的业务价值链？如何理解？是横向的业务链？怎样的业务链才算横向的业务链？如何分析端到端的业务链得出结果不需要纳入中台业务范围？问题二：与横向相对的就是纵向业务链，聚焦是不是指横、纵向相交的这些业务链？相交的话横向才需要梳理？然后纵向是按愿景来？感谢，盼复。因为正好我们有在梳理中台业务需求，这块内容很有价值，望老师详细展开讲讲。
展开
作者回复: FF，你好~ 这块用文字比较难说清楚哈，我刚在DDD-China2019上分享了一个Topic，叫做《中台规划的7种武器》，在DDD-China官网或是其公众号上应该能搜到相关的keynote下载。（我的知识星球：白话企业数字化中台中也同步上传了PPT）。在PPT里对于中台的切入点选择，业务现状梳理，以及业务设计都有展开描述，感兴趣的话可以搜索下载看一下，应该对你有所帮助，也算是对于这个专栏的后续研究和展现~
OTM
2019-11-06
中台里面功能针对不同应用差异化的如何处理，定制化、配置化？如果定制，是否又脱离了复用定义；这一块老师能否举个例子
产品不是经理
2019-10-28
能不能结合具体的案例，在具体的一点，感觉整个听下来，多半是你的感受，听的云里雾里。
作者回复: 产品不是经理，你好~ 首先感谢关注和支持哈，没有让你听的特别清楚，确实是我的问题。由于大部分内容是基于我的学习、研究和项目实际经验而来，虽然我尽力说的通用且白话，但是确实难免比较抽象。案例的部分，我还在整理，因为目前实际的案例都是客户的资料，就算是脱敏也会有问题，所以我正在尝试虚构出一个完整的案例来，比极客地产更全面，或是直接在极客地产的背景下，做一些包装，把之前碰到的实际问题和解决方法都揉进来。这块还需要一些时间，如果我有一些案例的更新，一定及时补充到专栏里，并且通知大家。多谢反馈，再次感谢支持和理解，有问题可以继续留言交流~
吴志刚
2019-10-22
中台能否真正解决企业内部存在的烟囱问题。中台建设，根据企业愿景对业务进行梳理，分析，抽象，但都会有一个边界，不可能涵盖所有已有的业务线和未来可能出现的业务。那中台也只是作为企业信息化系统中的一员，无法形成大而全的平台，烟囱还是会存在，请老师指点
Geek_986f8b
2019-10-17
我们梳理业务重叠及可复用性，是不是最后我们中台的能力就是提供这部分可复用的业务接口，包括数据、功能或者流程？而没有重叠，不可复用的部分就不在中台考虑范围之内？
作者回复: Geek_986f8b，你好~ 这个问题可以归集到什么东西放中台，什么放前台。这个问题我应该已经回答了好几个了，看来大家都比较关注。我的观点简单来讲，就是还得先看中台建设的愿景，愿景就决定了中台作为一个产品，做什么，不做什么。再基于愿景决定是把“重要的”还是“重复的”还是其他“XX的”功能、数据、流程放到中台里。目前大多数想通过中台解决的都是笼统的“去烟囱”，所以大家一般都会像你说的去找共性的，重复的放到中台。但我认为不一定，现在不重复的也不代表以后不重复，而且重复多少算重复，这些都不太好界定。所以如果说中台复用的是企业的能力，那复用到底是不是因为简单的“重复”，还得看中台建设的最终目标到底是什么。当然你说的也没问题，目前大多数人理解也都是这样的，我只是想在深入一下，因为面上的道理大家都懂，但是一到具体实施就会很难拿捏尺度。希望回复对你有所启发~

