企业转型的关键,是组织重构

数字化转型
企业的需求不同,可能选择的组织转型路径也不同,有的选择激进疗法,有的选择保守疗法。

互联网和数字化时代是万物互联的时代,整个商业社会形成了一个更加庞大的系统,酝酿了大量的不确定性。在不确定性中,更加灵活的平台型组织则可以抓住机会,对抗风险。

如今组织转型已经不是一道选择题,而是一道必答题。只有通过打造平台型组织,才能让企业拥有更轻、更快、更强的组织能力。

企业的需求不同,可能选择的组织转型路径也不同,有的选择激进疗法,有的选择保守疗法。

没有什么绝对的对与错,关键在于自己的需求。

本文,我们将基于两种路径,给出更加具象化的“实施路线图”。

1.激进疗法

采用激进疗法的企业应该意识到,尽管路径激进,但转型依然需要在一个长周期内才能完成。正因如此,企业应该有一个3~5年的组织转型规划,基于组织终局的设想,确定每个阶段的里程碑,稳步实施,逐步落地。

一般来说,这种规划以打造三台架构为主线索,分为三个阶段。

第一阶段的主要任务是打造市场化的前台和组织中台。

要改变企业内的组织模式,只是讲道理、出文件是没用的,首先要打造出属于企业的“深圳特区”。讲一百句道理,不如给一个案例。

在组织转型的初始阶段,企业就应该有意识地培养组织中台,打造“腰部力量”。

当前台组建了小公司,它们必然需要市场化激励。所以,应该针对这个小公司做三段式薪酬改革、漏斗式分配、合伙式奖金和三预一致的变革,将它们的收益最大限度与经营业绩联动起来。

与此同时,在聚光灯之外的培训部门或企业大学也需要开展支线任务。它们应该尝试初步建立赋能机制,明确企业知识管理的核心主体,形成企业知识的框架模板(尤其是最内圈的经营知识),推出知识管理的基础运营标准。

第二阶段的主要任务是打造市场化的业务中台。

前台“深圳特区”的成功,让企业有信心将经营单元的模式推广到更大范围。

当前台接受了直接的市场压力,它们一定会将压力传递到中台,尤其是业务中台。这个阶段,由于前台的“小公司”更多了,这种压力是并发式的,业务中台的改造变得势在必行。

这种改造主要分为两个方面:

一方面,进入前台的业务中台BP需要改造。此时,进入前台的可能不仅是来自业务中台的BP,而应该是小职能团队。

另一方面,业务中台的母体部分也应该进行改造。它们必须以前台的需求为出发点,思考如何提供柔性的中间件。它们会总结自己的底层方法论,并基于前台的业务场景,提供乐高积木一样的模块化交付,柔性匹配需求。

面对前台的汹涌压力,大多业务中台会采用强势对抗的姿态,坚持自己的专业主义。面对这样的局势,企业不要惊讶,这就是人性。要打破它们的执念,不要光讲道理,要上激励。此时,一定要让业务中台的业绩和前台紧密关联。

换句话说,业务中台的赋能效果决定了它们获得的收益。

第三阶段的主要任务是打造市场化的后台。

当前台又有一批小公司获得了成功,企业会有坚定的决心把经营单元模式覆盖到全公司。

此时,业务中台和组织中台必然会迎来更大的挑战,它们的压力无处释放,必然涌向后台,而铁板一块的后台又成了它们绕不过去的阻碍。

这个阶段,必须整合中台的需求,让后台有所行动。

而真正让后台能动起来的,只有高于后台的权力机构—合伙人团队。

合伙人团队应该是在前一个阶段就已经成立了,但那个时候的他们只是在“找感觉”,这一阶段的他们才需要“打硬仗”。这个阶段,他们必须频繁输出价值理念和战略内核两方面的成果,并对资源洼地和共享机制的建设给出具体要求。

当中台基于短期目标提出了需求,当合伙人团队基于长期目标提出了需求,后台就会被逼入转型的轨道。为了保持它们的势能,也为了推进平台型组织建设,后台这种转型动作必须用结果来衡量。

2.保守疗法

采用保守疗法的企业一般都处于业绩的快速提升期,它们害怕组织转型打乱这种增长节奏,更希望进行“小迭代”,一次次“做加法”。这样的思路完全没有问题,但尽管是做“小迭代”,也应该有“大格局”,同样需要进行3~5年的规划。

一般来说,这种规划以打造知识流赋能为主要线索,也可以分为三个阶段。

第一阶段的主要任务是建立文本协作规则,形成知识流赋能。

如何让一个业绩飞速提升的企业好上加好?

事实上,从外部引入的组织创新、管理模式等很难说服牛气冲天、傲视天下的员工,因此我们只能选择用“魔法打败魔法”“以彼之道还施彼身”。于是,我们希望总结这类企业的最佳实践和常见教训,让它们以“知识流”的形式渗透到组织的每个角落,这让老板和员工都很难拒绝。

让知识的萃取、整合、推送、变现,在打仗的流程里实现闭环,这就是所谓的文本协作。

具体来说,在企业内选择若干项目进行试点,每个项目都以一个核心文本作为底层逻辑,来开放式地吸纳成员,组成项目团队。不管员工来自哪个部门,只要能够为完善核心文本提供知识或信息,都可以进入项目团队。

项目参与者很可能是在本职工作之外做非常规的事,他们最初可能是基于热情,但随后热情肯定会逐渐降温。

企业也不能压榨参与者的这种热情,而应该在最初就导入激励,认可这种贡献。此时,发放项目奖金可能是一个不错的选择,但一定要界定项目参与者的范围,同时也应该有明确的价值量化的方法。

第二阶段的主要任务是导入知识交易,形成市场化激励。

现实中,不少企业在激励上都做得比较粗放,仍然是在跨边界组建项目团队的基础上,用360度绩效考核法等传统方法来衡量业绩,然后再发点增量奖金,显然这种方法是不靠谱的。这类企业的悲哀在于,它们只是身在起点,就天真地以为自己已经到达了终点。

知识本身是有价值的,但很难衡量价格。

要实现知识的定价无非有两种途径:一是让知识的贡献者作为合伙人参与项目;二是让知识的贡献者作为外包商提供封装式的交付。

这种市场化激励联通了企业内每个掌握知识的节点(员工),让知识碎片能够迅速萃取、整合、推动、变现,让知识创造的成果喷涌而出。越多的知识创造,越能产生好的经营业绩,好的经营业绩又能形成更强的激励,促进更多的知识创造。

第三阶段的主要任务是进行组织结构整合,形成三台架构。

当企业导入了市场化激励时,必然最大限度地促进员工的跨部门协同,一种更加灵活的组织结构就呼之欲出了。那么,应该往哪个方向进行组织结构调整呢?

传统的金字塔组织结构中,为了确保部门能够封闭运转,必然存在大量职能的重复设置。当两个部门都有同一项职能时,其业务逻辑是很难对接的,结果就是各玩各的。

对于企业来说,不仅是产生了当下的职能设置成本,更有未来的协同成本。

当企业初步打破部门和层级的边界时,员工就能带着自己的知识进行流动,他们自我经营的效果就一目了然了。此时,企业完全可以按照市场化激励的效果,合并一些重复的职能,甚至剔除一些水平不高的员工。

需要强调的是,这里并不是让企业没有组织架构,基本的组织架构形成了员工在自由协作之外的归属地,他们的知识需要沉淀在这些地方,这些地方也是企业真正的竞争力。

因此,前台的重复职能应该被整合到中台上,中台的重复职能应该被整合到后台上,企业应该走向极度精简和共享的三台架构。

3.放弃也是一种选择

在推广平台型组织的过程中,我和我的团队得到了若干企业的热情反馈。也难怪如此,对于组织模式的发展方向,稍有认知水平的老板都不会拒绝。但我在与部分企业的老板接触后,劝他们中的一部分放弃这个念头。

我必须诚实地表达自己的观点—不是所有的企业都适合转型为平台型组织。

其一,没有澄清价值理念的企业不适合做平台型组织。

有的老板导入平台型组织,实际上只是想用这种组织模式来“让员工更听话”,而不是“发挥他们的创造力”。他们既然不敢授权,也不愿激励,更无法赋能。于是,企业进也不是,退也不是,变革到最后不伦不类。

其二,没有澄清战略内核的企业不适合做平台型组织。

如果企业本身没有合理的战略内核,连方向都是错误的。这类企业多半处于创业期,老板对自己所处的赛道通常会无比乐观,他们认为,以企业的发展势能为基础,加载强大的平台型组织模式,一定可以一飞冲天。

这个逻辑里,关键要素是他们的战略内核,而不是平台型组织。他们需要做的是“活下去”,而为了实现这个目的,应该花最小的成本,建立简洁而规范的金字塔组织。

其三,没有管理基础的企业不适合做平台型组织。

有的老板因为企业管理基础差,希望导入平台型组织来补课甚至实现突破,但这步“跳棋”下不得。若干次的项目经验告诉我们,尽管平台型组织是在颠覆金字塔组织的逻辑,但它又必须建立在金字塔组织的管理基础之上。

对于以上几类老板,我的建议是:放弃也是一种选择。踏踏实实做好传统的组织管理,打造健康的金字塔组织,这并不是什么丢脸的事情。

重剑无锋,大巧不工。

当企业校准了战略内核,夯实了组织管理时,老板自然会在这两个方面有深度认知,成为前面提及的会主动选择组织转型的凤毛麟角。

到了那个时候,他们自然有资格向平台型组织进军!


责任编辑:华轩 来源: 今日头条
相关推荐

2013-12-22 15:51:00

IT基础架构关键业务英特尔

2016-04-20 23:34:40

SAP数字化 S

2021-09-03 09:34:35

物联网IOT数字化转型

2016-01-25 14:22:46

大型企业移动化

2012-07-18 15:33:42

用友两化融合转型升级

2022-04-29 17:18:55

数据治理数据管控体系数据管道

2021-05-20 15:54:03

物联网数字化转型科技

2021-08-19 15:47:46

数字化转型IT技术

2019-03-15 09:40:45

云徙科技数字中台数字营销

2023-08-01 07:19:15

变革管理项目

2020-10-26 09:57:06

CIO首席信息官IT

2020-08-26 10:24:22

IT领导者数字化转型首席信息官

2012-05-15 01:16:19

开发重构Java

2011-06-08 11:55:01

IMPACT2011SOA业务敏捷

2022-07-17 15:56:33

数字化转型工具IT

2011-09-27 09:12:14

关键业务IT号外

2019-01-02 11:34:33

数字化企业转型互联网

2021-04-06 10:56:21

数字化转型CIOIT

2013-04-07 10:41:13

2023-01-30 10:46:10

点赞
收藏

51CTO技术栈公众号