技术主管的增加带来了混乱和权力斗争

简介:

D1net观察:据市场调研公司IDC估计,企业数字化转型的经济价值为20万亿美元,占全球GDP的20%以上。因此,向数字化转型成为企业重要的战略目标,在这方面投入大量的资金和人力,企业中随之出现了一些新的职位如首席信息官、首席数字官、首席创新官、首席营销官等,这些人的工作时有交叉,边界模糊,这种状况容易导致企业高管层中发生混乱和权力斗争,从而使企业陷入困境。国外知名公司在这方面已经有先进的经验,让我们来看看他们是如何解决这一难题的。

在您的企业高管层中是否有太多的技术主管呢?如果是这样的话,最好让他们与企业保持步调一致,并确保他们向首席执行官(CEO)汇报工作,否则的话,企业将面临商业状况恶化的风险。

企业正在凭借数字技术使自己更贴近客户。但数字麦肯锡(Digital McKinsey)咨询公司表示,随着首席信息官(CIO)、首席数字官、首席创新官、首席营销官等角色的岗位职责日益扩大,可能导致企业高管层中发生混乱和权力斗争,这不利于企业业绩。

该咨询公司所调查的700位信息技术(IT)和企业高管中有三分之一表示,他们不清楚自己公司哪个领导主要负责数字技术。数字麦肯锡(Digital McKinsey)公司合伙人克里斯多夫·施莱(Christoph Schrey)告诉CIO.com,导致这种不清楚谁来负责企业数字资产(如基础设施运营、应用开发、电子商务、数据分析和数字营销)的情况,源于公司把技术任务分配给了过多的主管。

你可以把这一问题归咎于全球数字化转型过热。大多数公司传统上都有一名首席信息官(CIO)或首席技术官(CTO)负责技术策划。麦肯锡公司说道,但是随着开发总监(CDO)的兴起,目前14%的公司已雇佣这一角色,而且越来越多的首席营销官(CMO)也负责技术工作,这就意味着目前公司在高管层平均有两位技术主管。一些公司甚至有六位或更多的各种技术主管。“随着更多的技术主管同时推进企业数字化和技术工作,在角色和职责上的清晰界定变得更加困难,”施莱说道。

清晰界定岗位职责或另谋高就

一些企业通过明确界定其首席信息官和开发总监的职责已经取得了成功。他们已经指派一名开发总监来负责面向客户的解决方案(如移动应用程序或网站),并与首席信息官紧密合作,确保将应用程序或网站正确地集成到后端系统中。成功合作产生的合作关系确保了首席信息官和开发总监彼此工作上的成功。

在一些公司,当开发总监因工作上的进步且高效而迅速获得比思维缜密的首席信息官更多青睐时,这就导致发生权力斗争。“这是一个企业的问题,因为所有这些岗位都需要密切合作为客户提供解决方案,如果他们无法合作,则他们就会瓦解,”施莱说。

由于技术主管们通常会向企业中的不同领导汇报,因此可能会产生彼此抵触的技术派别,因此企业内部进一步脱节。例如,有57%的受访者表示自己的首席信息官负责技术工作,47%的受访者表示他们的首席信息官会向首席执行官汇报工作,其中19%的受访者认为其首席信息官会向首席运营官汇报工作,16%的受访者认为其首席信息官会向首席财务官汇报工作。而在14%拥有开发总监职位的公司中,39%的开发总监会向首席执行官汇报工作,有10%的开发总监会向首席运营官汇报工作,有11%的开发总监会向首席信息官汇报工作。如果首席信息官和开发总监必须经常合作来提交工作报告,那么向高管层的不同领导汇报工作则是另一个潜在的危险策略。

就运作模式达成共识

施莱说,我们可能需要帮助这些技术主管,使他们凝聚在一起,将其部门整合到一个单一的运作模式中。目前还没有一个明确的途径。当然,每个部门都必须了解各方统一的端对端流程,就其职责达成共识。

另一种界定主管职责的途径包括让技术主管直接升级向首席执行官汇报工作。“在首席信息官、首席技术官或其他技术主管直接向首席执行官汇报工作的企业中,人们认为信息技术人员的工作效率比没有使用这一途径的企业更高,”施莱说。“这不仅对企业的感知绩效有影响,而且还改善了技术主管参与制定公司经营策略的程度,这是业务部门和信息技术部门都期望的目标。”

一些公司似乎逐渐理解这一方式,并且做出了转变,比如饮料制造商可口可乐上周宣布,首席信息官巴里·辛普森(Barry Simpson)将直接向总裁兼首席运营官(COO)詹姆斯·昆西(James Quincey)直接汇报工作,昆西已被提拔为首席执行官,将于5月1日入职。可口可乐公司表示,此举将“提升工作可见度并着力于在可口可乐业务的各个方面推行数字化。”

如果技术部门要与业务部门合作推行企业数字化转型,那么主管岗位职责界定是至关重要的。麦肯锡公司表示,各行业的平均数字化率不到40%,其中49%的龙头企业在数字化转型上的投资比其他公司更多。

尽管投资风险很高,但潜在的企业回报也很大。据市场调研公司IDC估计,数字化转型的经济价值为20万亿美元,占全球GDP的20%以上。

本文转自d1net(转载)

目录
相关文章
|
程序员
思考:如何写出让同事难以维护的代码?(1)
思考:如何写出让同事难以维护的代码?(1)
73 0
思考:如何写出让同事难以维护的代码?(1)
思考:如何写出让同事难以维护的代码?(2)
思考:如何写出让同事难以维护的代码?
57 0
思考:如何写出让同事难以维护的代码?(2)
思考:如何写出让同事难以维护的代码?(3)
思考:如何写出让同事难以维护的代码?
51 0
思考:如何写出让同事难以维护的代码?(3)
|
API 计算机视觉
思考:如何写出让同事难以维护的代码?(4)
思考:如何写出让同事难以维护的代码?
71 0
思考:如何写出让同事难以维护的代码?(4)
|
设计模式 测试技术
重构·改善既有代码的设计.02之代码的“坏味道”
之前在《重构·改善既有代码的设计.01》中初步了解了重构的基本前提,基础原则等入门知识。今天我们继续第二更......
206 1
重构·改善既有代码的设计.02之代码的“坏味道”
|
Unix Java Linux
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
![](https://ata2-img.oss-cn-zhangjiakou.aliyuncs.com/neweditor/846d5052-1e21-4f9c-8f52-aaa37cacc407.png) # 前言 一群高智商青年在餐厅吃饭,餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉,而标识为胡椒粉的瓶子里装得却是盐,他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个
48652 10
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
|
Unix Java Linux
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
软件工程最大的成本在于维护,为了未来可扩展、为了未来更灵活,我们往往会增加很多很多奇奇怪怪可有可无的代码,增加这些代码可能只需要几分钟,但移除这些代码花费的精力与承担的风险,却数倍于此。我们不断 YY 着所谓的未来,却让现在越来越糟。系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』。
1175 1
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
|
程序员 API 计算机视觉
思考:如何写出让同事难以维护的代码?doge
本文从【程序命名&注释】【数据类型&类&对象】【控制执行流程】和【程序/结构设计】四个方面梳理了一些真实案例,相信通过这些案例你能迅速get技能:如何写出让同事难以维护的代码doge。
|
消息中间件 运维 JavaScript
在公司混的差,不一定是能力不行,可能和组织架构有关!
在公司混的差,不一定是能力不行,可能和组织架构有关!
|
存储 应用服务中间件
老代码多=过度耦合=if else?阿里巴巴工程师这样捋直老代码
作者:闲鱼技术-紫思 简介 在业务开发的过程中,往往存在平台代码和业务代码耦合严重难以分离、业务和业务之间代码交织缺少拆解的现象。平台和业务代码交织导致不易修改,不同业务的代码交织增加了不同负责团队之间的协同成本。
8860 1

相关实验场景

更多