工作在金融机构，从事数据相关工作，写过SQL，做过COGNOS，用过SAS，偶尔在学Python，工作重心也从写代码逐渐的向产品经理转移，更多的参与到业务需求讨论，数据应用方式，数据中台理解，数据产品建设，企业数字化转型等方面，偶尔关注到一个公众号，里面的文章大部分很切合我的工作实际或是有共同点，在此做以转述，以加强自己的记忆和理解，此栏目下的文章均转载自“与数据同行”公众号。
现在讲数字化转型，大多是自顶向下的视角，但企业光提战略、目标是不够的，必须将任务分配到每个团队，落实到每个人每天的工作上，但这些工作会跟员工以前的工作不太一样，也就意味着团队和员工也需要跟着转型。
可以肯定的是，无论企业数字化转型口号喊得多么响亮，如果一线员工的工作内涵没有发生变化，那也就是企业的自嗨而已，那么面对数字化转型，作为员工的我们，应该如何迎接这些挑战呢？
企业的数据岗位人员，应是企业数字化转型中最先面临冲击的一拨人，我作为其中一员，现在也在经历着这一过程，虽然企业的数字化转型还在路上，但发生在自己身上的各种挑战已经暗流涌动，而正是发生在企业每个员工身上的这些挑战最终决定了企业数字化转型的成功与否。
今天就来讲讲自己正在经历的企业内部数字化转型一个案例，即原来企业的一些投资需求是由一线手工搜集上报的，存在数据不准确，上报不及时等问题，现在需要基于前端市场的诉求、设备实际运行的数据进行科学分析后给出投资需求，然后通过在线方式及时上报，快速响应前端市场的设备扩容需求。
围绕这项数字化转型工作，企业有几个核心参与角色，负责规划投资的业务部门，负责设备运维的管理部门，负责设备运维的一线生产部门，负责市场拓展的业务部门，负责IT的部门（负责管理信息系统，业务系统、数据系统的建设和运维）等等。
虽然这只是企业众多数字化转型案例中的一个，但的确够复杂，几乎涵盖了数字化转型的方方面面，带给我的挑战也是很大的，用四个字来概括，就是“不确定性”，具体来讲就是八个方面的挑战。
1、企业对转型来真的，我最担心的是不确定性
企业数字化转型不是简单的建个系统那么简单，大多需要动一些根本性的机制和流程，建系统那是很后面的事情了。这次企业数字化转型涉及到企业投资的流程，影响面还是很大的，毕竟投资一般还是有路径依赖的，原来多少，今年如果差不离，风险也不会很大，但如果把这种路径依赖打破了，对所有人都是挑战。
这个转会型涉及到很多的部门的工作，设备运维管理部门负责统一生产管理（包括设备运维系统统一建设，涉及源端相关数据），一线运维部门负责设备需求上报（市场前端部门也会提出需求），规划部门决定投资需求方案（也是投资管理系统、大数据平台等的需求方），IT部门负责系统建设和数据支持（负责投资管理流程系统，大数据平台等建设），这个时候组织机制的保障就非常关键了，比如转型工作哪个部门牵头，哪些部门配合，具体的职责是什么，具体的工作流程是什么等等。
各个部门都有自己的工作，要凝聚共识并不容易，需要强有力的管理层的推动，而且这种推动不是开几个会那么简单，因为数字化转型往往需要打破旧的框架，少有行业最佳实践，大多是摸着石头过河，领导开始的时候如果不亲力亲为，不抓些细节，可能大家走的路就会偏掉，其实很多时候大家并不知道这个工作做到什么程度才算真正的到位，领导和员工的视角也很难短期能够拉平，必须要靠慢慢的磨合。
我参加过很多次沟通会，汇报会，最大的体会就是领导的要求要跟员工对齐，这个对齐过程非常艰巨，一次次汇报工作都是为了纠正大家认知上的偏差，你以为做到这一点就可以了，其实离领导的目标还差很远，那下次继续汇报，直到逼近预期。在这个过程中，大家都要用实际流程说话、用实际数据说话，没有调查就没有发言权，你好我好大家好的数字化转型是不存在的。
数字化转型的牵头部门，这个时候承受着最大的压力，我们要对他们报以敬意。我每次去参加开会，最怕的就是这种不确定性哪天落到了自己身上，自己虽然懂点数据和IT，但跟他们的相比，那也是不值一提，我们搞数据和IT的，一定要知道这一点，这样你在后续的工作中，就没有不努力的理由。
2、业务需要数据支持，我担心业务想不清楚
可以肯定的说，如果数字化转型的组织、机制和流程扎实的建立了，那么也就成功了一半，大多数转型失败不是什么系统不好用，数据不靠谱，而是前面那个头就没做好，比如领导开了个头，后面就不持续抓了，那估计大家也就泄气了，领导一定是一以贯之的，比如每周要听汇报，每月要三方会审，把还不明确的东西要明确掉，子弹才能继续飞下去，因为到处都是壁垒。
牵头业务部门要出数字化转型的方案，挑战是巨大的，由于没有什么最佳实践，业务部门很难一下子出完整的方案，大多需要由点到面，比如先找一个点尝试做一下，汇报一下，根据汇报的结果再做调整，然后一点一点去摸索，因此这项工作开始前几个月，就没看到什么像样的方案，反正团队成员在不停的配合业务做些取数建模工作。
终于有一天我去参加了一次正式汇报，看到业务部门拿出了一个相对清晰的方案，我心里也算落了一块石头，的确这是一种相对务实的方法，如果业务部门一开始就拿着外来和尚的完美方案汇报一下，那的确是很难经得起实践的检验的。
举个例子，我们需要基于一些运维数据来判断是否需要扩容，但前期取数发现计算出来的结果跟一线上报的相差甚远，后来核查才发现是源端数据录入的问题，如果数字化转型不做录入数据这个流程的优化，那失败的可能性就会大增，但这种方案的完善根本不是靠临时找个合作伙伴写出个方案就能达到的。
业务千万不要想着直接扔个方案，然后就催着IT建系统，而是要因地制宜，否则建的系统大多无人使用，根本无法推广。
3、业务自己想清楚了，我担心缺乏业务指导
很多数字化创新只是在数据团队熟悉的领域内修修补补，这种局部的、改良式的数字化工作是很多数据团队的日常，比如把营销数据推送环节进行精简，取数从人工转向自动等等，而真正的企业数字化转型往往具有全局性的特点，对于数据团队很大的挑战就是要进行跨领域的数据支持。
数据团队面临的将是全新的业务领域，全新的数据环境和全新的机制流程，对于这些领域的业务和数据，数据团队以前可能也接触过，但也只是浅尝辄止，比如我们数据团队对市场营销领域比较熟悉，已经打造了一套较为成熟的在线精确营销体系，但对于投资规划、设备运维等领域就比较陌生，也就是曾经采集了个别的数据而已。
在一个全新的业务领域，数据团队再有本事，也要躬身去学习新的业务和数据，并能形成数据和业务的映射，才能对业务形成最基本的数据支持能力，而这种支持能力需要在非常短的时间内形成，因为数字化转型不会留给数据团队太多时间。
而站在业务方的角度看，虽然其可能熟悉业务，但也是分层次的，比如业务管理部门的业务理解往往有方向、有高度、有逻辑，但其可能并不熟悉一线的实操场景，而一线业务部门则是反过来的，数据团队并不是简单的抓住一个业务人员问就可以了，经常需要业务牵头部门帮忙协调到归口的业务人员来进行咨询，这带来了很大的不确定性。
一般业务部门也是没有数据专员的，所有的数据都在运维部门，数据团队还需要业务部门作为中间协调人与运维部门的IT进行沟通，否则理解业务和数据也无从谈起，这又带来了不确定性。
在数字化转型的初期，业务牵头部门的实际配合力度直接决定了数据团队的支持能力，业务部门能不能配合、相关干系人员能不能配合、业务部门自身的理解是否到位、相关干系人员是否传授到位，数据团队的人员能否理解到位，都成为了数据团队工作推进的不确定因素，对于所有人来说，这都是一个学习磨合的过程。
数字化转型让我感觉到了隔行如隔山，有时听团队人员汇报模型就像听天书，唯一能做的，就是确保资源到位，协调到位，能够未雨绸缪，我问得最多的都是这些问题，业务概念有没有理解？业务流程清不清楚？业务数据能不能验证？业务部门能不能配合？
4、业务持续提出诉求，我担心能力储备不足
在数字化工作的初期，数据团队的人员投入并不需要很多，但一定要是自己团队的核心骨干，不仅要有较好的业务理解能力，也要有数据的实操能力，这样能尽量减少前期的沟通成本，因为大家都知道，搞数据的，只要多了一个中间环节，那支撑的效率就会大幅降低，数据是业务的，业务是数据的，两者有时很难分的清楚。
但随着数字化工作的深入，业务部门的理解在不断加深，涉及的探索领域也在逐步扩大，相应的数据支持工作也在不断增加，这个时候开始需要大量的模型人员进行支持，比如验证业务人员某个想法，开发一个新的模型，进行汇报的数据支持等等，大量的探索性取数在这个阶段集中爆发。
如果一个数据团队没有足够的人员储备，就会冲击原有的数据工作，如果临时找人支持，那这些人员的数量、素质、协同水平是很个大的未知数。
由于数字化转型的数据支持工作探索性很强，需要团队成员之间有很好的信任关系，在出现问题时不扯皮，不计较，这种团队往往不是靠临时拼凑就能搞起来的，即使是现在，我还是有隐隐的担心。
数字化转型一旦进入了状态，最大的挑战一定是人吧，缺人的结果就是跟业务扯皮，然后双方都不满意，而你只能变相降低工作质量，更不要提能主动能为业务献计献策了，而这是非常重要的。因为在进入数字化转型的中期，业务会非常依赖IT和数据的能力，无论是平台建设、数据模型、可视化展现、人工智能等等，很多业务策略的制定，也需要建模人员给予建议，比如资源预警的阈值确定等等。
5、模型需要反复迭代，我担心业务缺乏耐心
有次跟公司领导汇报工作进展，提到要解决某路网匹配的问题，然后业务人员说需要建模人员给予支持，然后公司领导表示对于我们建模还是很有信心，一直在给我们打气，但自己还是有很大的担心。
我怕做不好是有原因的，一是业务的因素，企业80-90%的模型都是规则建模说明了业务理解的重要性，而这需要业务人员的充分参与，否则建模人员的压力太大；二是模型的因素，比如图模型以前没做过，短时间内不一定能出结果，这带来了不确定性；三是迭代因素，可能第一次效果不好，但如果多给些验证的机会，效果可能就会上来，我们需要业务给点耐心。
我得清楚的传递给领导和业务人员一个信息，就是建模不是简单的数据团队的事情，而是需要业务人员的全力配合，现在业务对于我们报有这么大的期望，我们当然要全力以赴，但你们也可千万别放手，最后一定是双方共同努力的结果。
6、流程需要进行变更，我担心业务无法协调
数字化转型一定要动一些根本性的东西，流程肯定首当其冲，因为流程在提升企业运营效率方面至关重要，我举一个例子。
以运维数据为例，企业需要基于运维数据发现设备运行的问题，但通过数据验证发现，很多运维数据在录入的时候就是错误的，这里既有系统方面的因素，也有管理上的因素，反正是历史原因造成的，而基于错误的数据得到的结论肯定也不靠谱，因此要做的一个工作就是改进数据录入流程，但这个问题解决起来难度可太大了，因为凡是涉及到一线的流程，就会牵一发而动全身，流程改一个环节，成千上万的一线人员可能就要摇一摇。
要解决这种问题，业务要做的事情就太多了，比如业务要充分理解一线业务流程，了解每个流程中每个角色的职责；发现这些角色操作中存在的问题，评估这些操作带来的影响，寻找解决这些问题的方法，跟公司领导汇报改进的方案；更改业务管理办法，下发业务操作手册，构建新的业务流程，打造相关的配套工具（比如自动录入工具和自动稽核工具）；对一线人员进行培训，然后新流程试点上线等等，更关键的是，可能还要花很多钱。
当然我这里只是举个例子，但你可以充分理解事情的复杂性，历史留下的欠债要当前的业务人员来还，的确有点不公平，但这就是数字化转型的关键点。
数据团队帮助业务人员发现了问题，但这只是个开始，你的数据分析结果还必须嵌入到生产流程中才算完成了使命，比如需要在一线人员数据录入的环节嵌入自动数据稽核模型进行预警，而这所有的一切，都需要业务人员来统筹操盘。
7、模型和流程终建立，我担心系统体验不好
我们好不容易建立了流程，嵌入了模型，这还不算完，因为如果新流程体验不好，就会极大提升一线使用门槛，况且老流程用惯了，新流程的替换成本就很高，自顶向下强推当然也是可以的，但浪费一线人员的时间就是一种罪过，即使初衷是好的。
我再举个例子：
为了确保施工信息的准确性，我们以前需要一线人员在施工的时候手工录入系统很多的信息，比如小区名称、地址信息、经纬度、设备信息、附属信息等等，但最后你会发现，这些人工录入的信息准确性很差，这次在新流程中，我们就需要考虑智能化的手段解决录入信息准确性问题，无论是小区信息、地址信息、经纬度信息、设备信息（比如端口数）等等，这些其实都是可以自动化的，只要你真的是为了解决一线的实际问题，比如经纬度信息可以APP自己采集，小区信息可以基于经纬度自动适配地图获得，地址信息和设备信息可以通过拍照图片AI自动识别获得，数字化转型成功其实就是靠这么一个个细节铸成的。
无论是数据团队还是IT团队，都要有种想干事，干成事的精神，充分利用数字化技术来为一线人员赋能，但在操作体验层面，业务人员是很难把握好的，这恰恰也是IT和数据发挥能力的舞台，也是我们需要向互联网公司学习的地方，即关注用户的体验，为一线提供炮弹不能嘴上说说，一定要落实到行动上。
8、应用体验终于达标，我担心业务推广不力
数字化转型工作会涉及到很多方面，每个方面的进度并不一致，有些流程和系统预警上线，有些已经进入到推广阶段，有些还处在设计阶段，但上线一个其实就要推广一个，让其尽快发挥生产力，由此螺旋式迭代提升才是精益运营的方法。
那么如何评估是否有真正的生产力呢？
唯一的办法就是用数据说话，比如我们这个转型案例其实最终要看得是投资是否节省了，决策是否更快了，业务投诉是否少了，但过程数据在前期更为关键，因为它可以促成尽早问题的发现和改进，业务和数据团队每天得盯着新流程和系统的使用情况来决定下一步，但在这最后一公里上，我们前期做的并不是太好。
我始终担心毕其功于一役的做法，因为我们当初想的，做的，并不一定符合一线的实际，这里一定有个渐进提升的过程。比如我们上线了一个可视化的管理工具，演示的时候很好，我还以为成功了，后来通过数据才发现使用者不多，一打听才知道业务还没有具体的推广计划，试点单位的操作体验问题也很多，比如数据的展示速度太慢，没有跟后续的流程打通等等。
以上就是我在一次企业数字化转型中的真实体会，它对数据团队提出了全新的挑战，但也带来了新的价值出口，更关键的是，我们每个人在这个过程中都能收获成长，这是件很快乐的事情。