“后数字化”系列 - 后数字化时代已经来临，敏捷转型救不救得了？

这也是最近几年愈发明显的一个现象。

传统企业的数字化部门，经过几年的发展，规模迅速扩大，组织关系复杂，业务产品不断积累，大规模的数字化部门面临【后数字化时代】的困境。

什么意思呢？

在数字化转型的后期，成立的数字化部门经过几年的沉淀，所面对的组织和业务挑战，相较成立初期，都已经有了天翻地覆的变化，几乎所有的数字化部门都不得不面临新一阶段的挑战和困难，而原有的方法和模式都在变得越来越重，越来越吃力，跟不上数字化部门的发展。

首先，我们分析一下，传统企业的数字化部门常常只是服务于主营业务的工具，用来降本增效，而不是独立生产能够用来变现的产品。不像微信、淘宝、或者滴滴，他们的主要产品就是软件平台。

而数字化部门的产品常常是为其他核心部门提供服务，或者为一些已经建立业务关系的客户提供增值服务。面对这些内部或者外部客户，数字化部门能够让产品或者服务更便捷，更高效，提升品牌形象，服务质量，提升收益，或者挖掘出一些新的数字业务模式，甚至产生一定新的收益模式。

这些都是我们耳熟能详的数字化转型的目的，也是数字化部门所期望的。

正因为这个本质特点，传统企业的数字化部门，天生需要面临几个问题。

第一，传统企业中，数字化部门的工作，必须优先满足企业固有服务，也就是核心业务部门和核心客户的需要。

例如，顺丰就是需要围绕着快递业务服务，东风汽车就要围绕着汽车行业服务。这既带来了行业优势，但也带来了一系列问题。

最基本的一条，无论内部客户还是外部客户，都是大爷，谁都得罪不起。

每个实体的需求还会不一样，内部客户希望能做一些管理和流程性质的工具，例如供应链管理，人员和培训的管理等等。外部客户则希望满足他们自己不同业务的需求。

久而久之，诞生了许多平台，许多产品，许多工具，也诞生了许多数据，这些都需要维护的成本。有的平台可能只有一两个人偶尔用一下，但是他们作为数字化部门的衣食父母，不可能不提供符合质量要求的服务，需要有人能够维护这个平台，文档和知识都需要维护。

但面对滚雪球一样的新老系统，维护这么多产品和业务线，数字化部门需要多少人手？数字化团队的知识积累和持续服务该如何保障？

第一句话把问题说破，数字化部门无法独立管理产品组合，因此老旧系统像滚雪球一样不停累积，越滚越大。

第二，数字化部门的业务知识严重依赖于其他部门，往往这些数字化转型的传统企业，他们赖以生存的业务知识都有一定壁垒和难度。数字化部门的客户关系也常常要依赖销售部门，如果涉及到制造、供应链等环节，数字化部门毫无疑问必须通过现有部门与实际业务发生关系。

在企业进入数字化转型后期，数字化部门与原有各个部门都发生了关联，销售、市场、产品、工程等等，加上不同地区、不同客户和不同产品线又将数字化部门关联的复杂程度成几何倍数往上拉。

而数字化部门内部呢？软件开发的基本环节也要有，设计、开发、测试、运维、运营等各个环节也要根据不同的业务范畴进行匹配。组织关系在企业原有的基础上又增加了好几层。

客户和用户的信息、业务场景、需要经过复杂的组织关系层层转述，才得以到达开发团队，在复杂的组织关系和复杂业务知识的背景之下，开发团队是很难做到敏捷团队要求的自管理的，常常只能是被当做工具团队使用，而且这些工具团队往往只能听命于外部给的输入。

更残酷的现实是，给输入的很可能只是某个客户或者某个大领导拍脑袋的需求。

第二句话把问题说破，数字化部门的团队无法实现自管理，因此组织依赖关系错综复杂，距离业务场景还很远。

第三，每个组织都有自己的愿景和目标，组织目标明确了目前阶段组织的首要考虑内容和发展方向，起到指南针的作用。当不同的项目需求来临的时候，愿景和目标能够帮助组织决策，该如何选择，如何投入。

然而数字化部门仿佛很难有自己的目标。

讲一个案例，年底的时候，某公司数字化部门制定来年的目标是，搭建公司的新的数字化服务平台。

然而没过多久，各种问题便会来挑战这个目标。

一个大客户急需数字化部门配合开发某个应用接口；

某个政府项目急需在很短时间完成开发工作应付上级检查；

必须配合市场部门开发一系列线上工具，来协助新产品的推广；

与此同时，数字化部门内部也开始有声音质疑，这么多时间精力投入到这个所谓“新的数字化服务平台”到底能带来多少利润……

毕竟，我们对于市场和业务也没有那么清晰的认识，如果孤注一掷“all-in”这个新产品，怠慢了传统大客户和内部客户这些衣食父母，可能数字化部门存在的意义都会没有了。

忙了大半年下来，发现年前制定的目标已经没有人再提起了……

是不是很熟悉？这不是个别案例，而是我亲身经历过，发生在许多传统企业数字化部门里的常见情况。

第三句话说破，数字化部门很难自由地定义团队愿景和目标，因此基于传统的理论，基于愿景的商业战略和产品战略是无法在数字化部门轻松落地的。

这三个问题只是众多问题中的一部分：

数字化转型发展到了一定阶段，以业务为中心形成不同的“大部门”或者“中心”，这些像“堡垒”一样的不同中心之间该如何协作？

需求归口和方案设计如何审查管理？

如何避免重复造工具造平台？

如何降低子系统间的耦合性？

降低团队之间的依赖关系？

数据仓湖如何综合治理？

数据所有权、操作权和审查责权如何分配？

在团队层面，如何积累业务知识？技能如何提升？

我们还不用着谈什么学习型组织，创新精神，自主发明创造，或者什么企业文化，先谈谈如何避免团队人员大规模流失……

团队似乎不高效，但无法明确地量化效能……

这些都是我作为敏捷教练过程中反反复复遇到的问题。

在数字化转型的初期，一个小团队足以频繁地创造价值，加速扭转以往流程中阻塞或者造成浪费的节点。无论敏捷不敏捷，或者采用什么敏捷方法，只要开发团队靠谱，一切都会显得很美好，顺理成章。

而数字化转型后期，我们迎来了后数字化时代，无论产品规模还是团队规模，都不是原有的管理方法和流程能够支持的。

敏捷转型是不是出路呢？我只能说现成的敏捷框架并不是针对传统企业的数字化部门设计的，也不是针对后数字化时代的问题和痛点设计的。

这也是为什么许多企业数字化部门敏捷转型举步维艰的原因，

“哪里能够自管理呀？需求谁给的，就得听谁的啊。”

“制定目标有什么用，明天客户一个电话过来，都得放下，优先考虑客户的事情。”

“一个PO哪里能够对接得了那么多用户，管理得了那么多需求。”

“口号喊的是创造价值，用户为中心，用户在哪里都没见过呢，价值就是做一个按钮，做一个表单么？” 

当然，我们知道，按钮和表单并不是价值。

后数字化时代，管理方式也要升级，现有的敏捷方式不是解药，相应的，敏捷也得升级。

这个题目很大，但是非常有意义，后面我希望做一系列主题来分别讨论这些问题，分享一些可能的解决方法和实践，感兴趣的朋友请在评论区留言讨论。谢谢！

B站《老袁讲敏捷》