架构三问3方案经理如何主导方案规划

　　以下文章来源于喔家ArchiSelf ，作者温昱
　　随着各行业赛道迭代的加速，行业客户日益重视IT系统和数字化方案的业务价值和整体效果。这意味着，各企业不再满意每次单独实施一个孤立产品这种形式，转而去拥抱那些能够规划全局和长期护航的供应商。这就是现在＂解决方案架构师非常抢手＂现象背后的原因。
　　不少供应商发现，没有《XXXX整体IT解决方案》作为＂敲门砖＂和＂门票＂，就根本得不到上门拜访企业客户的机会。
　　本文就来讨论，解决方案架构师或方案经理主导方案规划时的部分要点：
　　首先，总述方案规划的实际过程
　　然后，分享政策文件解读框架
　　第三，梳理从业务战略到业务蓝图的逻辑主线
　　第四，梳理从业务范围到应用架构的逻辑主线
　　方案规划的实际过程
　　理想情况下，方案规划过程的主线如下：
　　1）启动阶段：建团队、选方法、定计划
　　2）调研阶段：战略驱动因素（Strategic Driver）
　　3）规划起步：业务目标分析（Biz Goal）、影响范围分析（Scope of Org Impacted）
　　4）业务蓝图：从业务目标/业务价值、落到业务能力、再落到人员组织/业务功能/业务流程/业务渠道等组成的业务蓝图
　　5）技术方案：Gap分析识别业务能力增量、后者驱动应用架构/数据架构/技术架构设计
　　6）实施阶段：涉及IT项目和非IT项目的计划与实现
　　实际中，规划过程不会如上图那般一气呵成。例如，不精通领域、不清楚问题、不受客户领导层认同等等，都要求方案经理深入调研、细致诊断、细粒度推进规划，最终得到高针对性的方案设计。
　　一句话，就是要求方案经理反客为主、做好企业参谋。如下图所示，相比上图而言，调研环节、规划环节扩充了大量实践。
　　政策文件的解读框架
　　调研环节，进行外部分析和内部分析。其中，外部分析主要包含宏观环境分析和行业分析。
　　政策文件的深度理解是一个实践难点，对ToC、ToB和ToG业务都很关键。但很多解决方案架构师就算意识到了政策文件解读的重要性，实际做起来也并不容易。
　　下图，笔者分享政策解读框架。大家可以针对具体行业政策文件，解读解读试试。效果很好。
　　逻辑主线：从业务战略到业务蓝图
　　从业务战略到业务蓝图的内在逻辑，是由四个概念支撑起的骨架：
　　Driver——战略驱动因素
　　Goal——业务架构目标
　　Strategy——业务架构策略
　　Blueprint——业务蓝图
　　举个例子。一个大型企业，推进数字化采购转型。如图所示，我们注意以下几点：
　　图中从上到下正是Driver、Goal、Strategy、Blueprint四层体系
　　Driver层，1个战略驱动因素。公司即将数字化采购转型
　　Goal层，3个业务架构目标。理解成数字化采购转型的具体目标分解
　　Strategy层，10项业务架构策略。理解成3个Goal需要的能力提升
　　最关键一点，10项策略完全围绕蓝图五要素。如组织提升、业务能力提升等
　　Blueprint层，按业务蓝图五要素定义蓝图。这是业务架构师主要工作量所在
　　综上所述，从业务战略到业务蓝图的内在逻辑主线是：从Driver确定、到目标分解、到策略设计、到蓝图定义。逻辑明确，创新有据。
　　上图的建模，用的是Archimate Motivation分析图规范。它在下列四种情况下特别好用：
　　领导指令分解落实
　　系统性策略规划
　　头脑风暴
　　痛点分析
　　逻辑主线：从业务范围到应用架构
　　本节稍长，先理个脉络。主要工作步骤有：
　　价值链分析，得到的价值链模型相当于顶级业务域划分
　　细化分解，得到大家熟悉的业务域分块图
　　Gap分析，将每一个业务域标识为新增、增强、不变三者其一
　　整理业务能力增量需求
　　设计应用架构、数据架构、技术架构支撑业务能力增量需求
　　考虑业务能力增量需求需要的非IT能力建设
　　很多技术出身的业务架构师很烦恼，因为他们梳理的业务功能划分结构，根本得不到甲方企业领域专家的认同。究其原因，不外乎下列两点。
　　第一，他受到自己研发经历的影响，错误地按＂IT系统模块＂的方式划分＂业务功能模块＂。
　　第二，虽然没有犯情况一那么大的错误，但＂业务功能划分＂不符合该行业常规理解。
　　解决办法只有一个，那就是业务架构师必须对目标领域心存敬畏、尊重行业共识。具体而言，首要一条，必须掌握该行业的常见价值链分析模型。
　　价值链，不求巧妙但求通俗。笔者在此，斗胆分享几点心得。
　　首先，生产型企业的价值链模型。最经典的传统价值链模型，就是波特创造的生产型企业的价值链模型。现今应用时，都是进行了改造和优化的。笔者认为，比较公认的优化有：
　　1）倾向于分为支持层、业务层、战略层。
　　2）＂技术开发＂变身＂产品研发＂，移到业务层。因为现在的商业环境下，产品研发不是辅助，而是核心。
　　3）＂采购＂移到业务层。
　　4）如下图所示，＂老九样＂变成＂新九样＂。
　　其次，电信运营商、电网、仓储物流等基建投资占比高的企业的价值链模型。笔者认为，比较公认的优化有：
　　1）倾向于分为管理支持、运营支撑、核心业务三层。
　　2）如果存在业务支撑层，那么投资规划、工程建设、运营维护这三者就放入业务支撑层，否则列入核心业务主线。
　　3）例如，下图所示，为能源仓储分销企业的价值链模型。
　　第三，银证保、电信、电商、家电、运输等服务密集型企业的价值链模型。笔者认为，比较公认的优化有：
　　1）倾向于分为支持层、业务层。
　　2）支持层经常包含财务管理、人力资源管理、客户资源管理、数据资源管理等，比传统价值链模型更加强调客户资源、数据资源了。
　　3）企业对外提供的业务多种多样，那就分别梳理在业务层。
　　证券企业的价值链分析。如下图所示。
　　铁路运输行业的价值链分析。如下图所示。
　　价值链分析的价值，在于切合行业，也在于穷举。有一定经验的方案经理都能做到一个顶级业务域不漏。
　　接下来，本节还将：
　　细化分解，得到大家熟悉的业务域分块图
　　Gap分析，将每一个业务域标识为新增、增强、不变三者其一
　　整理业务能力增量需求
　　设计应用架构支撑业务能力增量需求
　　如下图所示。细化分解，得到了业务域分块图。图中，也体现了Gap分析的结果，新增功能标了红色，增强功能标了蓝色。这里，有两点值得说明：1）图中的＂上车前、乘车中、下车后＂运用了时间轴思维，2）时间轴思维是业务架构师必备技能，也是甲方企业领域专家们特别惯常的分析习惯。比如贷款领域的＂贷前、贷中、贷后＂。
　　方案经理或应用架构师，整理业务能力增量需求，包括六大业务需求板块：
　　1）销售，
　　2）检票，
　　3）客服，
　　4）清算，
　　5）现场设备管理，
　　6）IT运维管理。
　　继续推进应用架构设计，采用业界比较普遍的＂上渠道、中业务、下支持、右接口＂风格，刻画应用功能架构。
　　虽然业务架构设计、应用架构设计还包含很多其他工作，但本节已努力说明清楚了从业务范围到应用架构的逻辑主线：价值链分析要全、功能域分解要细、Gap分析识别业务能力增量需求、应用架构设计支撑业务能力增量需求。
　　《业务架构 应用架构 数据架构实战》新书上架
　　想要了解更多具体案例和实战方法，可阅读《业务架构应用架构数据架构实战》一书。
　　l 每一页都是实践经验的总结，参考性超强
　　l 每一页都简洁明了重点突出，可读性超强
　　l 大局＋架构＋文档，三大篇，操作性超强
　　本书思路清晰，每一个概念、每一项方法都给出了简要透彻的阐述。同时又结合实践，给读者看得见、摸得着的项目实践感受，帮助读者迅速上手。本书还有一个作用，就是能提升读者对IT及其业务的认知层次，为长远职业发展提供助力。
　　温昱老师简介
　　具有开发/管理/咨询职业经验
　　国内最早一批架构实践者之一
　　资深咨询顾问、培训讲师
　　辅导过多企业解决方案部
　　著《软件架构设计》
　　著《一线架构师实践指南》
　　著《业务架构•应用架构•数据架构实战》
　　参编《IT架构实录》
　　如果喜欢本文
　　欢迎 在看丨留言丨分享至朋友圈 三连