为什么数字化部门老背锅？,数字化转型是什么意思。

数字化部门紧张搞IT，常常自嘲为“挨踢”。

的确，在很多公司，数字化部门常常被业务部门告状、不满。

是数字化部门能力不到位，还是任务心不到位？实在，不但不是，而是太负任务了。

导存问识不到自己的事情方法有问题，越俎代庖，终极事情结果不符合预期，业务部门不认可；自己着力不谄媚，成了名副实在的“背锅侠”。

我结合事情履历，总结了三点关键缘故原由，分享给大家。

01 随便答应“一句话需求”

我们常常碰着以下三种场景。

有时候，公司某领导在会上提到某个事儿，须要数字化系统来支撑。

详细这个事儿的业务对接方是谁，业务策略是啥，还没明确，可能这事儿就直接让数字化部门牵头了。

有时候，数字化产品经理参加一次业务谈论会，会上个别人提到或一起谈论到某个业务事情须要以数字化系统实现，业务部门就会认为这便是提数字化需求了。

实在，业务上须要做什么，什么韶光弄完，需弄到什么程度，业务的紧迫度等，一概不明确。

有时候，某业务方很负责的发了封需求邮件，但是，需求就一句话。

需求背景是什么？要办理的业务问题描述准确吗？涉及哪些业务流程？涉及哪些业务角色？涉及什么流程管控点？一概含暗昧糊或不知道。

当面对如上三种场景时，难以让每个业务方都把需求提到位，乃至让业务方搞清什么是业务谈论，什么是业务需求，什么是数字化需求。

但是，什么是合格的数字化需求，做为数字化专业职员的你，你要清楚，你的尺度要坚持。

那么，面对上面三种场景该当如何做呢？

先说总结论，让业务方明白“数字化需求，需业务需求先行；一句话不是需求，连业务需求都不是”。

基于这个结论，我们就好办了。

面对领导会上一句话，要先找到紧张业务合营方或业务牵头方；面对业务谈论会上一句话，需提出一起先把业务需求谈论清楚；面对邮件一句话，要约韶光专门沟通细化需求。

然后，推动业务方去做，或者帮忙业务方把业务需求捋清楚，包括业务目的、业务流程、业务规则、涉及角色、业务优先级等，从中再识别出数字化需求。

让他们明白，前面这些事儿紧张是业务上的事儿。

可能业务捋完，短则三五天，长则一两个月过去了。

他们就不会拍着桌子说，数字化部门不干活；也不会到老板那里说，这需求我给数字化部门提了2个月了，迟迟看不到动静。

02 认识不到数字化项目都是业务项目

很多做数字化的同学有个误区，尤其是B端数字化项目，认为数字化项目的效果，就该数字化部门卖力，乃至兜底。

乃至在市场上，有些做B端软件的乙方，为了拿下项目，给甲方签兜底协议。

这在一定程度上，让人认为数字化项目便是交钥匙工程，就该数字化承建方兜底。

这是很严重的一个误区，任何数字化项目，都是一个业务项目，数字化仅是实现的方法和工具，是落地支撑而已。

数字化项目，一样平常上线前涉及业务需求梳理、流程梳理；上线后涉及宣贯、培训、管理规则颁布、试跑、推广，乃至还有回炉培训。

这些都离不开业务方的深度参与或主导。

以是，做数字化项目履行操持时，一定要把业务方的事变与操持一并制订出来。

开项目启动会时，一起明确，相互承诺。

我以前曾碰着一个营销体系勉励分配改革的项目，在需求提出时，业务部门非常焦急，导致项目研发操持排的特殊紧。

数字化研发同事，元旦期间加了三天班，平时两个月没有周末安歇日。

结果数字化运用功能上线都半年了，人力资源迟迟没有发布勉励分配管理规定。

你能说数字化项目做的不好吗？如果这事儿，公司领导不知道，在领导眼里便是一个失落败的数字化项目。
前期没有把业务方一起拉进来，制订明确的业务操持、躬身入局；从数字化角度项目是上线了，自己背锅的日子也开始了。

以是，数字化项目也都是业务项目。

03 光顾专一干活，不善向上沟通

尤其是在有一定职员规模的公司，比如5000人以上的公司，公司高层没有韶光每天盯着你做的那些事儿；业务部门怎么在领导那里说，故意无意的怎么说数字化的事儿，你是不清楚的。

说好的还行，说差的，可能很多事儿吭哧吭哧白干。

以是，要主动往聚光灯下，主动往高层雷达圈儿里走；不能光顾专一干活，还要长于向上沟通。

为了只管即便客不雅观，带来不必要的误会，同时考虑部门之间的协作关系，建议每有阶段成果时，数字化部门主动联合业务部门给公司高层进行项目申报请示，或事情申报请示。

数字化的事情，属于业务事情落地的工具支撑，属于下贱；很多上游的问题没有及时有效办理，堆积不才游，集中爆发；导致数字化部门挨踢、背锅。

作为数字化职员，要复苏的认识到问题的缘故原由，并找到科学的办理办法，才是问题办理之路。

这样，会从原来背锅的，成为堪当重任扛大旗的。

作者：产品人晓明；微信公众年夜众号：营销数字化实践；多年CRM、互联网产品履历。
做后端产品居多，从0到N做过CRM、用户订单、商家平台、商家结算......

本文由 @营销数字化实践 原创发布于大家都是产品经理，未经作者容许，禁止转载。

题图来自Unsplash，基于CC0协议。