随着各行业赛道迭代的加速,行业客户日益重视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分析识别业务能力增量需求、应用架构设计支撑业务能力增量需求。