1. 团队背景
马小跳是该组织零售信贷团队的老员工了。零售信贷业务发展历史长，算是零售条线的核心业务，包含了小微企业经营贷、按揭贷、消费贷等多种复杂业务。马小跳从最开始的审查审批和贷后管理流程线上化、到消费贷业务平台、再到风控数字化等，参与了多个项目的建设。
在业务侧，马小跳对接的主要角色包含了总行这些不同贷款产品的业务设计、营销策略、贷后及风控管理和分行客户经理等角色，日常沟通对象超过20人。在融合机制启动后，新补充了对应于营销及渠道、审查审批和贷后管理、风险合规相关的业务需求角色，和小跳一起来统筹数字平台的规划和建设。
在IT侧，负责所有渠道、业务系统和风控平台的研发有100+人。在融合机制设计的过程中，依据团队拓扑，把原来面向系统的开发小组划分成面向数字产品的敏捷团队，以最小化团队在开发交付过程中的相互依赖，促进在研发落地时的流畅进行：
面客的各种渠道（手机银行、信贷APP、微信、小程序、网点客户经理PAD等）、提供客户经营与服务线线上化能力的客户经理工作平台、创新消费贷业务，各自形成融合的业务流团队，通常直接面向客户，变化多并响应快；
提供全渠道服务、支持各类贷款业务线上化处理中台，则属于平台团队，与业务流团队之间的协同原则为“一切皆服务”, 所有能力形成中台服务提供给各个业务流团队；相对于业务流团队，在灵活响应业务变化的同时，也需要尽量在各个不同的贷款业务中抽象出统一规则；
数字风控、资信数据、客户标签等团队属于复杂子系统团队，与平台团队为协作关系，与业务流团队之间则相对独立；
平台运营运维小组是新组建的，在整个领域的角度来落地数字化运营和运维工作，包括运营监控、运营数据分析、自动化运维服务等，属于团队拓扑中的赋能团队，为其他团队赋能。
马小跳负责整个领域数字平台的规划管理，因为PO还是人手不足，同时也兼任了客户经营与服务团队、运营增长&运维服务小组的PO。队伍成型了，怎么开干呢？
2. 当前从规划到落地中的三大断点
在当前，从业务目标制定再到平台研发，之间的流程大致像这样：通常业务部门，会在年初围绕业务目标和KPI进行务虚会，提出很多业务举措，然后提请业务部门立项，再进行方案细化，拍一个“IT工作量”，然后提前IT立项决策，决策完之后IT进行需求分析并交付上线。
马小跳发现，在当前这个过程中，运作不流畅导致业务和IT相互抱怨、响应慢质量不高、用户体验不好等，主要是因为三个断点：
1）断点一：在提请IT立项之前，平台建设需求并未被真正识别
业务部门务虚会产出的业务举措，其中一些是业务运作的策略设计、一些是新的业务类型、一些则是概念和想法。在进行项目方案细化提前IT立项之前，因为业务部门缺少对平台架构、各个IT系统的了解，往往导致数字化平台建设需求并未被真正识别。要识别出数字化平台建设需求，通常要能大致上回答诸如下面的问题：
背后实际上需要IT平台提供什么能力？
这些能力在当前的IT平台上：是完全没有、部分有还是可能已经有？
这些能力建设有先后依赖关系吗？
实现新的业务流程/策略/规则，涉及哪些IT系统？
是要新建一个应用，还是在某个已有应用上做扩展？
需要依赖哪些内部外部服务/数据？获取方式可行吗？
与合规条款仔细对过了吗，新的线上化逻辑和规则是否有漏洞？
为A业务做的改动、会影响到B和C业务吗？是否要统一、规范化处理、避免将来的数据孤岛？
…
但在实际过程中，往往是把这些业务需求直接给到了IT部门。这是第一个断点。
2）断点二：业务和IT的优先级信息不对称，IT的响应与业务的期待错配
业务部门给提请IT立项的时候，是从业务维度拆分的，并且各个子业务会根据自己的需求来提出优先级；而IT在接到业务项目时，会大致地映射出是哪些IT系统。IT在考虑优先级的时候，会先考虑对应的系统/模块是否有研发资源、从研发实现的角度是否有依赖关系、且是否有IT架构需要调整、一些基础性的IT战略举措（如上云、国产化改造、统一主数据）是否需要先满足等。但因为业务需求和IT需求这复杂的像蜘蛛网样的对应关系，导致各自的优先级信息完全不对称，相互抱怨：
业务视角：“A需求都提了多半年了，IT还没开始做！B需求倒是做了，可是是个半截袖根本用不了啊！”
IT视角：“天天996，业务的需求永远做不完，还总是变！”
3）断点三：IT急赶交付时间线，必要的需求澄清和体验设计不到位
等业务和IT终于相互妥协、勉强就优先级达成一致的时候，离业务预期的上线时间也没剩多长了——在IT立项后，研发团队“囫囵吞枣”地理解了一些业务需求、基于业务在三四个月前提供的页面原型开始了实现、顾不得深挖用户问题、顾不得提炼一致的业务模型、顾不得改造原有代码统一重复逻辑、顾不得是否存在重复建设，匆匆忙忙地赶在预期的时间上线。业务在开始使用时，会遇到各种断点、卡点，以及一些莫名其妙的bug，于是提更多的运维问题并吐槽。IT团队此时又手忙脚乱应付各种运维问题，导致其他业务需求更无暇顾及，形成恶性循环。
3. 四个关键动作，让规划到落地流畅起来
在业务侧工作的2年多，马小跳对三个断点深有体会。要去消除这些断点，第一，必须让IT伙伴往前站，尽早在业务规划时就参与进来；第二，这个新的流程必须尽可能轻，不能让业务和IT伙伴觉得是额外又增加了很多的工作环节和负荷；第三，要有明确、清晰的动作及责任人定义，以保证落实。
基于EDGE从业务规划到落地的轻量管理框架，马小跳制定了如下从规划到落地的端到端工作流程：
第一步：业务规划
第二步：优先级决策
第三步：专题方案分析细化
第四步：专题迭代交付
第五步：持续运营
第六步：定期成效回检
最关键的，当属前三步和成效回检。马小跳明确了如下四个关键动作，并在团队开始落地实施。
1）关键动作1：季度业务规划
动作目标：
动作产出：
动作输入：
顶层业务战略和目标
业务市场洞察输入
上周期成效回顾结论
负责人：
参与人：
业务负责人/业务专家（必须）
各融合产品团队BA（必须）
用户代表、设计师、数据分析等（可选）
完成时间：
产出质量：
通过这一关键动作，确保平台建设需求被提前识别出来、且避免立项后发现技术不可行导致的磕绊。
2）关键动作2：季度专题优先级决策
动作目标：
动作产出：
业务领域的精益价值树
高优先级的专题待办清单
业务领域的演进路线
动作输入：
负责人：
参与人：
完成时间：
产出需在每个季度开始后，第二周内完成
建议时长~2天
产出质量：
业务和IT的优先级不对称，还来自于业务只关注业务指标、而IT关注效能和质量指标。在进行优先级评估时，基于价值三角，聚焦用户价值并用延迟成本方式来评估优先级。
另外结合领域特点，预先对价值成效实现和IT技术战略分类来确定投资比例分配，对相应的业务和技术类专题分别来排优先级，也能促进业务和IT结合短期和远期目标来明确优先级。
这些方式结合，可以有效地消除业务和IT的优先级错配。
3）关键动作3：专题分析工作坊
动作目标：
动作产出：
动作输入：
负责人：
参与人：
完成时间：
产出质量：
动作提示：
4）关键动作4：每周专题实时进展和成效更新
动作目标：
动作产出：
动作输入：
负责人：
参与人：
完成时间：
以这四个关键动作为抓手，以前的三单断点得到了有效缝合；从业务规划到IT落地、也显得井然有序，从领导到业务和IT的伙伴，都得到了不错的反馈。
4. 小结
业务和IT的融合，其实不仅仅是因为要协作，而是数字化技术改变了我们运营业务的方式。当IT建设不再是持续把流程从线下搬到线上时，用数字化思维进行好业务治理不是简单的事情。作为这样一个业务的核心推动者，在这繁乱的事务中，需要能把握核心原则、掌握管理抓手，才能拨云见日。
注：文中案例和角色均为虚构。