企业数字化转型已不是一个新话题，作为传统企业基本都在此实践路径上，是否能够有一套合适的理念+工具能够使企业在转型初期乃至中后期仍然保持通过统一的平台进行支持，以下文章将给出一种实践思路。

业务流程域

项目敏捷 OR 企业敏捷？

项目敏捷也好、企业敏捷也罢，两者的有机结合是从业务管控域减少工作交接成本的极好方式，首先敏捷思想在需要产品快速迭代的场景下往往会被优先选用，无论是 SCRUM 还是看板都已经是相对成熟的理念，在十人左右的项目团队中直接以此开始实践并无太大问题，大型互联网企业也可以直接采用规模化敏捷的模式实现复数级的团队敏捷。

但是回顾传统企业的现状，由于旧有的技术栈等存在，瀑布流等传统模式在转型期或长期都会是一个持续存在的状态，很难直接延续规模化敏捷的理念来做，因此结合传统企业现状来重新定义敏捷流程就显得尤为重要。

CMMI 是否限制产能？

CMMI 作为能力成熟度模型被各大企业熟知，即便是现在也依然在被许多传统企业或大型企业所使用，采用此模型的优势有许多，例如可以有效控制质量、定义过程、控制变更、管控范围，但缺点也很明显，繁杂的过程使得在处理过程之中耗费较多时间，这在如今面向业务需要快速响应的情况下显得有些格格不入。

我接触的许多企业在发现这一点之后，优先考虑的均是将新旧业务剥离，旧的继续沿用老一套，新项目组采用敏捷模式来满足日益变化的需求，这样如果说新业务组是新成立的，那么在企业内部也无需做太多的组织结构改造，算是平滑过渡，但是毕竟不是持续实践出的方式，很可能在追求敏捷的同时为生产系统带来更多不受控的缺陷和隐患。

为什么不融合一下呢？

是的，为什么不融合一下呢？这个仅从想法上来说绝非什么创新，可能很多传统企业管理者在最初实践敏捷，梳理业务流程域的时候都会想到，例如哪些 CMMI 过程组可以先保留下来，可以在对效率影响较小的情况下保持企业对产品的把控力度。

那么，往期为什么更多停留在想法呢，首先单纯的将 CMMI 与敏捷进行嫁接，并不能解决问题反而可能带来更多的工作，这样的改造没有实际意义，第二组织实践的想法需要有一个灵活支撑中间态的平台来作为基础，第三需重新梳理完整的业务管控流程并结合精益度量思想，使之处于或长期处于逐步消除生产力瓶颈的过程中。

工具及流程体系建设

持续交付体系

企业级用户无论是通过开源工具搭建或是诸如采用蓝鲸这样的成熟研运一体化平台模式，最终目标都将会是建设面向于交付业务价值以及具备持续运营能力的企业级平台，此平台并非往期意义上的业务中台、数据中台，而是为企业 IT 进行整体的支撑和赋能，因此不仅要求自身能力丰富，也需要企业具备自主性的扩展能力，使交付更加高效、高质量。

▲ 软件全生命周期及所需能力

▲ 嘉为蓝鲸 DevOps

业务流程的梳理及落地

结合前一板块的内容，需求作为整个平台的输入显得尤为重要，业务流程梳理将主要包括但不限于业务领域、产品线、产品、项目、版本、迭代、任务、变更、缺陷等流程，所有流程中哪些是平台流转，哪些是线下沟通均需妥善梳理，最终形成企业完整的一套需求管理模型。

产品线-产品-项目的多级管理体系

以产品线-产品-项目的管理模式作为一个典型样例来说，在传统企业中产品线-产品往往可以采用更加细致化的流程管理模式，保证需求的一致性以及产品整体的可控，项目层级则可聚焦于更快交付业务价值，通过敏捷模式进行实践，三者的有机结合应当充分考虑之间的包含关系，建立评审体系、变更体系，进而通过统一的需求跟踪矩阵的方式从业务整体查看当前的分散结构，此模式不仅可以有效查看需求变更带来的整体影响，也可以在一定程度上保持敏捷思想带来的灵活性。

使用模板

为使企业定义好的业务管理模型能够更加便捷的被不同产品线或项目组复用，产品应具备组织级的模板管理功能，可配置如产品线-产品-项目亦或业务需求-软件需求等不同的需求层级组织模板，模板嵌套之间需处理好关联关系。

另外为使在场景支撑能力足够丰富的同时也可以去做轻量化使用，平台需设置一定的功能开关，满足最小化使用的诉求。

▲ 功能开关示例

总结

传统企业的数字化转型将是一个持续性过程，在此进程中无需过于焦虑管理模式或组织的转变，一切当以结合实际情况为主，转型过程可采用逐步的过程转换方式进行，重点应当是在过程中找出影响业务价值交付效率的瓶颈所在，逐渐消除，这才是实践组织效能提升的最好方式。