背景
最近几年，数字化转型口号喊得震天响，各种媒体上也捷报频传，不乏各种令人振奋的创新性应用。面对此情此景，不禁内心一片困惑，数字化转型真的那么容易吗?
过去三年里，我参与了若干家大型传统企业的数字化转型工作。大家几乎遇到同样一个问题，业务、生产一线部门抱怨手工报送报表数据工作量大、重复报送、数据质量难以保证。朋友不妨看看，是不是“熟悉的味道”的呢?
本篇简单回顾了华为在过去近20年在报表报告方面所做的努力，或许*可以供朋友参考一二。
在了解华为的数字化运营发展历程前，首先要了解华为在运营方面的两个基本特点：
特点一：“*集权式”的运营模式
众所周知，集团型企业的运营模式分为运营型管控、战略型管控、财务型管控三种模式。三种管控模式的难度依次降低。据了解，绝大部分企业采用的是财务管控，稍有条件的采用战略管控，采用运营型管控的企业少之又少。
所谓运营管控型，总结起来主要体现在几个方面：1、由总部确定每一年的经营目标并进行相应结果考核;2、战略项目(如区域性的市场突破)有明确目标，也有相应的战略补贴;3、合同商务(如单价、优惠、验收等商务条款)分层分级决策，超过一定等级就需要上升到总部来决策;4、总部对一线经营单元需要过程管控，包括经营达成情况、重大风险等等，并及时进行资源弹性配置，基于”东方不亮西方亮“的规律，确保公司总体目标达成。
尽管近十年来，华为也一直在努力改变这种运营模式，但这种改变是渐变式的，而非断崖式的。
特点二：全球化运营(用全球资源，做全球生意)
尽管早在2005年，华为海外收入首次超过了国内收入，但华为的运营还是以国内为主的公司。2012年，华为首次提出全球化战略，并明确了全球化的含义：做全球生意，即在全球范围选择客户，端到端的业务开展(研产供销服)，本地化运营;全球资源整合，即全球一致性的管理，比较优势下的最佳资源整合，保持一个相对比较低的组织上的”重心“，是决策始终贴近市场，从而能够灵活的响应本地市场变化和客户需求。
第一阶段：统计考核指标
2004年前后，公司各大业务部门开始提出建设BIS的需求，包括研发、供应链、工程交付、财经等。
2004年6月完成了BIS在供应链领域的试点。主要输出供应链一级、二级部门的考核数据(KPI)以及业务过程监控指标。
具体功能方面，1)以固定报表为主，当期(月、季、年)实际指标值，与当期目标对比，依据阈值进行告警。2)按维度输入查询条件，查询指定指标结果;3)趋势预测：下一月指标值预测及告警，改进机会分析，对指标改进贡献最大的TOP项;结构性分析：按分解结构的指标值进行分解展现;因果分析;4)数据下载。
以研发领域为例，最早成立了运营支撑部，其主要职责便是运营管理工作。
2000年，随着 IPD 流程的推行，使得不同团队在执行产品开发流程时获得成功的可复制性，通过持续、周期性的业务运营管理活动，达成业务目标，并总结和固化优秀业务实践。
IPD 项目管理是在有限的资源约束下，运用系统的理论和方法对项目涉及的全部工作进行有效地管理，即在整个项目生命周期内进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。
在 IPD 变革落地和推行的过程中，为管理和适应这些变化，成立了正式的运作支撑部，其主要责任有：决策支撑管理、组织绩效管理、多项目管理、预核算管理、经营管理、资产管理等等，其核心职责是保障管理体系的运作顺畅和效率提升。
2005年，研发领域的OAS(运营分析系统)立项建设，系统定位为产品体系建立一套成熟的决策支撑平台。通过对IPD指标体系的各指标运营状态分析支撑管理层进行日常经营管理，通过OAS实时了解公司的发展是否偏离了业务目标。
系统上运行了近一年之后，2006年底进行下一年度规划时，总结了系统的三大问题：
1、实际应用效果与中高层管理决策支持的系统定位不符。中高层管理者基本不使用该系统。系统真正使用人数只占当初设计目标用户数的1/3。
2、用户对系统现有的指标准确性存在很大质疑。例如，财务指标与财经发布的指标统计口径不一致。
3、系统实现的指标规范性有待改善。大量指标在上线、推行过程中被废弃。
最终提出建议：2007年着重解决系统定位及数据问题，进一步分析需求和整理业务规则，不进行IT优化。梳理过程中参考业界建设实践，加强与中高层用户沟通了解用户真实需求。
上述建议得到当初的研发管理高层F总认同。最终该系统的命运就是无声无息，自然消亡了。
第二阶段：手工报告多、重、细
尽管其他领域的BIS系统还在正常运行着，但更多的数据还是依赖于手工报告进行传递。尤其是一线经营单元向上各管理层级的报告，矛盾更加突出。
2011年，某一线员工在公司内部刊物上吐槽：
在年末关头，各地区部作为一线业务中心都在进行订货和收入等指标冲刺，而机关某些领导也发起了各种冲刺，组织了一大批员工和一线部门对口沟通，要数据、要报表、压指标，开各种大会小会。比如某部门领导就发起了“XX业务4季度收入冲刺”指令，要求给各地区部相关业务部门下发指标，列示TOP 20项目每周进行汇报跟踪，指定多个新员工对口各地区部和重点项目，催促完成指标并要求给出完成时间和具体措施，声称对“未完成指标”的项目和地区部，要求给机关领导紧急述职。机关为什么这么多部门重复要这些数据，机关有平台应该给我们数据呀?我们比机关的收入指标压力大的多，不用你们多费心!我们忙得很，没时间给你们填写各种报表，你们需要自己来一线调查吧!
2012年，一线给丁先生(时任研发总裁)发邮件投诉机关，数落了“三大罪状”，概括为“多、重、细”：
多：机关要求汇报/数据繁多，信息量大，一线疲于收集反馈数据，如项目管理部门要报告多达18份， 服务产品部的报告基本都要分产品线统计，数量也非常多。
重：以收入的各类报告/数据反馈为例：
1、机关工程服务部各二三级部门都需要获取一线的收入情况以完成各部门自己的报告，重复严重;质量运营部要求提供整体收入经营情况，如月度经营分析、经营滚动预测;项目管理部要提供地区部不同产品线收入预测报告/月，以及收入偏差分析。
2、管理混乱，随便哪个小部门都需要收入分析，甚至需要单个项目收入情况，同一个项目可能有2-3人通过邮件形式来获取信息。
3、产品研发也有多个部门直接和一线接口：各产品研发都有接口人不定期和一线开会，要求反馈收入和经营情况;某产品线每季度一次给产品线总裁的汇报，也要再反馈一次(主要包括设备与工程服务收入与经营情况)。
细：各 产品开发团队都有独立的订货、利润、收入的考核目标，一线需要投入较多精力反馈各团队的订货和成本归结。每个维度都有对应的管理考核，多方沟通导致内部工作量增加，但不增值;产品开发团队之间界面的模糊性，导致后续工作量增加。
尽管之后公司也采取了一系列的措施，但直到2018年，情况依然没有得到明显改观。后来据数字化运营项目经理后来介绍，
“报表满天飞。我记得2018年从一线回来前，每个月找我要报告的人没15个也有10个。不同的人给不同的模板过来，要的是同样的信息，因为他们每个人要去做汇报。公司当时在取消报告这件事情上坚定到什么程度?如果还有人再找你要报告，你可以去找内控投诉，你去找稽查投诉。即使如此，要报告、发报告、收数据，依然经历了好几年。其实写一份报告或者发一份报告本身没什么的，最大的是他在写这一份报告的时候，他得找一层一层的人去要数据，最可恨的就是每一条线要下来的收入的模板都不一样，让他要的东西其实差不太多，所以最后我们才说要实现一点录入多点应用。”
之所以出现如此难以理解的现象，而且是“屡禁不止”，与华为独特的管理组织结构存在直接的关系。下面引用一段华为首席管理科学家黄卫伟教授在《华为组织变革的认知和启示》的文字，便可知晓其中原因。
“华为的做法是，把市场体系按照区域这个主维度来划分销售组织，将区域销售组织定位成利润中心，按照利润中心来核算、来考核、来激励;把研发体系按照产品来划分产品开发组织，将产品线定位成利润中心，也是按照利润中心的方式来核算、来考核、来激励。通过连带责任，主要是销售毛利率、销售收入和经营活动净现金流，建立起着两大利润中心体系经营单位的利润责任。销售组织分产品的收入、利润和经营活动净现金流，同时也是产品体系分产品线的收入、利润和经营活动净现金流;产品线降低成本、快速向市场推出优质、满足客户需求的有竞争力的产品，由此带来的利润、收入和现金流增长，同时也是对积极销售其产品的区域销售组织的绩效的贡献。这种连带的利润中心责任体系，并没有出现西方管理控制理论断言的责任不清和推卸责任问题，反而促进了两大利润中心体系的合作和共同将收入、利润和现金流做大。”
黄教授对华为这种“拧毛巾”式的双利润中心组织模式给予了高度的肯定。从战略高度上来看，肯定是成功的。但从实际具体执行的层面来看，大家感受到更多的是痛苦。不同的视角，得出来的结论千差万别。
第三阶段：“数出一孔”
要实现数字化运营，最基本的是账能算清楚。不仅总账能算清楚，而且“细账”同样能算清楚。
作为一家研产服结合的企业，每一款产品是否赚钱，在哪个区域甚至哪个客户赚了多少钱，都必须清楚，才有进一步改进的可能性。研、产、供、销、服的每一个业务环节所消耗的成本、费用又是多少，又有多少降本的潜力可挖，等等。这就通常所说的管理会计。
华为的管理核算复杂到可以说令人抓狂的地步。记得十几年前每年的管理核算规则文档超过200页，朋友可以想象一下。这样的复杂度，Excel是肯定搞不定的。
为此，华为于2006年启动了集成财经变革(IFS)项目群。在一期基本打通了从订单到汇款的端到端信息流的基础上，2009年正式启动了报告与分析(R&A)项目。
经过三年的努力，以巨大的人力财力投入为代价，2012年iSee平台首个版本上线。后续若干版本迭代优化后，2014年iSee平台基本建成，一直沿用至今。
iSee具备的应用分析是提供经营管理所需的分析报告，以及为实现财经管理职能所需的作业工具及相关的流程运营。
iSee 应用分析架构包含经营管理、财务管理、账务职能、价值分析四大模块。
1)面向内部经营管理，以责任中心为视角的报告解决方案，如地区部、代表处、 产品线、业务板块等;
2)面向财经专业视角的报告解决方案与分析模型，如法人视角的子公司、税务、资金、财务内控等;
3)面向财报分析与监控平台，包括 AP 、 FA 、关联交易、 SA 监控分析、 INV 监控分析、集团合并与报表分析;
4)面向业务单元的价值分析报告解决方案，如项目、客户、产品等。
以区域责任中心为例，区域责任中报告包括绩效管理、全面预算管理、经营指标分析三大部分，从总体概览到明细报告层层打开。
1)绩效管理，用于衡量和展示组织的财务绩效，揭示主要预算单元的分层级绩效，覆盖关键指标一览( KPI Dashboard )、下层组织的绩效。
2)全面预算管理，包括核算数据发布、预算执行分析、预测分析、定长预测趋势四部分。基于年度预算管理要求(分版本依据当年的预算白皮书)，集成预算工具中的预算预测数据，并发布符合预算口径、反映业务实质的核算数据，从而支持预算执行闭环管理。
3)经营指标分析，提供分主题经营指标的多视角分析(概览、多维度、业务动因、效率与质量等)。业务动因中，各主题按照其业务特点深层次展开分析，如收入融合 LTC 数据，将财务核算与业务关键驱动因素相结合，统一调整分类，实现从交易收入、交易调整、管理核算到财务结果的报表结构化。
随着iSee平台上线，加上各级经营单元开始配备CFO，逐步满足了财务数据的可解释性、可用性、权威性等基本要求，真正实现了“数出一孔”。
即使如此，数是死的，人是活的。大家在使用数据的过程中，依然会动些手脚。
2015年，据说在某次高层会上，某业务部门在进行决策汇报时，对所采用的财务数据经过了二次加工，以有利于议案通过。好巧不巧，当时的轮值CEO恰好了解相应的原始财务数据，一下子看出了其中的猫腻，议案自然被否定了。会后轮值CEO找到数据管理部部长，要求对此提出相应的防范措施。后者组织相关部门讨论之后，结论是很难通过技术手段对此杜绝，只能提出相应的管理要求。
于是，在《公司数据管理总纲政策》中明确：“非财经应用系统集成和调用财经数据后，禁止更改财务口径和规则进行二次加工或重塑。”
并由集团CFO发布“关于重申 iSee 作为财务报告唯一出口的决议”，基本内容摘录如下：
1、 iSee 系统是财务数据发布的唯一平台，公司各级会议的财务报告数据必须取自 iSee 系统。
2、各责任中心向集团层面进行汇报时所使用的财务数据，必须与 iSee 系统的数据一致，不得在系统之外对 iSee 系统的数据进行手工修订。
3、各级 CFO 必须对汇报中使用财务数据的客观性、一致性负责。
4、在数据使用的过程中，发现的数据质量问题，应按流程在数据源头修正。
第四阶段：首次消除手工报告失败
光有准确的财务结果数据，而且最快也才一个月出一次财务报告，远远无法满足业务过程管理的需求。
当然，业务部门也没闲着，同时也在为实现线上报表而努力。接下来聊聊销售报告的故事。
2012年，机关销售部门在公司内部刊物上曝光“销售报表为何不能用?”：
销售报表是销售管理过程及销售例会上最重要的基本信息。销售例会上需要分不同维度(区域、产品、系统部)对比销售目标、销售预测及实际完成的销售订货，对销售目标是否可达成，销售预测与目标的缺口怎么弥补等进行相应的分析，并提出相应的对策。
在LTC项目以前，所有的这些报表均是通过EXCEL层层收集，最后人工处理。2011年，LTC项目逐渐实现了在iSales系统中支持销售目标注册，销售预测分解与自动卷积、调整功能，虽然界面不友好，但也实现了从无到有的第一步。
需求收集期，业务部门十分踊跃，以为终于实现了销售目标、销售预测到销售订货的有效打通，可以从人拉肩扛中解放出来，但销售报表一上线，大家发现，为何集成过来的实际订货与iSee系统总是不一致，要不就干脆没有数据。经过分析，发现最基本的问题没有得到解决，就是分析的维度不统一，完全没有可比性，暂且还不说数据准确性。例如：组织维度不一致。经过多次沟通，iSales的组织数据取自于HR系统，而iSee系统的组织数据取自财经COA，是财经体系组织信息，与公司标准HRMS组织信息不一样。HRMS组织信息和财经COA组织信息之间的映射关系尚未建立，目前也没有明确的责任人和组织对映射关系维护负责。
2013年，某项目组在国内某省公司调研实际情况也基本上验证上述说法：
目前整个销售管理的业务都是在体外通过Excel实现的，目标是由地区部手工下达给代表处的，实际数由销管查看iSee取出实际数填入到Excel，代表处每周开一次销售例会，代表处下的3大运营商系统部也是每周开一次销售例会。
一线销售例会不能在iSales上开的一个重要原因是iSales数据太不准确，根本不可用，也没有信心用，建议要建立相应的管控机制保证数据的准确性。当地销管提出订货报告的核心是数据要准确，抛离这个基础一切都是空谈，再多的功能都无意义。目前现状iSales的主要用户是客户经理、产品经理，基于多重原因录入的一些机会点等信息都是无效的，销管发现后有没有权限去清理，所以建议要梳理相应的评审及管控机制，保证进入数据是可信的。
除了维度不一致，iSales业务系统的数据不准确的问题外，订货指标的责任部门也存在争议。
简单来讲，订货是合同签订的统计数据，交付之后才能形成真正的收入。CFO认为订货不属于财务指标，尽管过去一直是由财务出的，现在应该还给销售部门。记得2014年，为了确定订货指标的责任部门，销售老大和CFO在某会议室的走廊上吵了起来。销售老大说了一句非常血淋淋的理由：”我们销售在前线打仗杀敌，你们财务在后面帮着数数人头都不愿意吗?"最后协商的结果，销售部门负责定指标规则，由财务在iSee系统继续提供。
2014年左右，由销售部门牵头，下了很大的决心来提升数据质量，并且在试点省公司强制要求经营分析会上，取消PPT，直接看系统数据。最终由于iSales系统数据质量的问题，导致不了了之。
直到2017年，销售部门面向全球发布了《2017年关于isales管道数据质量提升管理规定》。从机会点录入及时性、相应成单金额预测的准确性等等做了明确的要求规定和考核措施。同时也要求各级主管加强iSales系统的使用，总部行管部门还将不定期通报各级主管使用iSale的情况。
事实证明，数据质量是实现线上报告的基本前提。然而销售数据的准确性绝对不是简单的技术问题。
第五阶段：数据基础能力建设
2017年，为满足数字化转型对数据消费的紧迫诉求，数据资产管理项目正式立项。
在立项过程中，正式提出数据对业务具有“两轮收益”的概念，直观地让业务部门和管理层认识到数据工作在不同阶段的价值。
过去，华为主要是围绕数据标准统一、数据质量(准确、及时等)开展数据管理工作，提升业务运作效率，减少由于数据质量带来的纠错成本。数据质量达到了基本满意之后，一方面持续改进，另一方面，业务部门也开始意识到数据具有更大的价值，最基本的可以实现业务透明，支持业务决策、管控风险。除此以外，以数据为“原材料”，以算法为“加工工艺”，替代确定性的业务规则和部分人工经验判断，实现业务自动化。
为解决过去一直以来数据消费相关基础能力不足，导致各个业务部门重复“造*”问题，数据资产管理项目建设统一的数据底座以及统一的分析平台。
打个比喻，过去大家要做饭时，大家要去菜园摘菜，或者去菜市场买菜;现在把各种菜都准备好了，清洗干净了;不仅如此，还按照常见的菜谱切好、搭配好了;甚至做饭的厨具也一应俱全。大家只需要根据自己的喜好选择原材料，自己做菜即可。数据底座把散落在各个业务系统的数据汇聚进来，进行清洗，以及不同程度的预处理，就相当于菜的原材料，分析平台就相当于厨具。
当然，不仅仅只是“硬件”建设，还有配套的“软件”建设工作，确保数据底座的数据资产安全、高效共享。例如涉及到员工、外部客户个人隐私数据的管理，也涉及到成本等高密级数据的管理，在这些问题没有解决之前，企业共享数据的不乏宁愿慢一点。
除此以外，在分析平台方面，如今大家都在追求自助分析、低代码开发的“硬能力”。而实际上，我经常强调自助分析是“有限自助”。试想一下，一个从来没做过菜的朋友进到厨房，即使上面所提到的条件也都具备了，就能超出自己心目中的菜品来吗?至少还需要如今网络上分享的各种做菜经验作为指导。
华为当年为此单独成立了自助分析相应的支持团队，提出了赋能、归纳、复制、激励四部曲。赋能一线业务部门局部应用自助分析，在这过程中逐步归纳典型应用场景，作为模板通过线上工作空间发布供其他同类业务单元直接复制，并对原创部门给出各种形式的奖励。
但是即使如此，基础工作做得再好，真正用好数据，还得依靠最终的数据使用部门。
第六阶段：真正取消部分报告
2018年，任老板在某次讲话中提出相关要求，要点摘录如下：
机关和一线都要学会自行在IT系统上获取数据。我们所要构建的是面向公司内部管理所需要的集成数据平台，机关向一线提供标准报告，一线也可以基于数据底座生成自定义报告。机关所提供的标准报告，就是三类报告(财务报告、经营报告、考核报告)的正面清单。机关不是“老爷”，不能向一线随意索要报告。如果在现有的数据基础上，机关还需要正面清单以外的报告，就把机关工作组任命到前线去做“数据工程师”，与前线联合作战，补齐这些例外报告所需的数据基础。
我们将逐步发布三类报告的正面清单，约束机关的权力，改变机关驱动一线汇报的工作习惯。
响应老板讲话要求，总部机关、各地区部(号称小机关)相继发布报告正面清单。以中国区为例，各省级公司收集的报告从原有343份缩减到104份，频率有年度、季度、月度、周不等。尽管看起来依然还是很多，但绝大部分都属于没有系统支撑的业务报告。绝大部分可以从数据平台可以加工的报告都不再需要一线单元报送了。
2018年，运营商板块正式取消通过邮件向各层组织发送的全球订货月报。一项过去维持了三十多年的工作从此作古。
2019年，时任运营商板块总裁的丁先生提出要求，全球经营管理报告以IOC(智能运营中心)为准，即使错了就把IOC的数据搞准确，而不允许体外修正。
即使是“最后一公里工程”，运营商板块IOC项目经理讲述了一段背后惊心动魄的故事。
B国用IOC用得非常好，最早在里面跑起来的第一批就是B国。但是当他们相信了我们，或者说被我们忽悠了，真的就不再去维护过去这么多年线下表格了，就因为有了我们线上的数据。突然有一天就发现线上数据不可用了，他们立马就要开会，用户原话是“感觉你这个系统就是被你们忽悠，系统根本就不可用。”
后来查出来，其实这个问题因为一单合同，业务规则变更之后，导致这个合同卷上来所有的指标都错了。它带来的影响就在于他们部门要开一个会去决策某个事情的时候，他以前的表没了，系统也不可用了。人家就问你，这是什么意思，你这系统还能不能用，值不值得信任。
所以那时候我才意识到，我们做这个系统，就是大家有可能会感觉，你看，今天我做的都很漂亮的看板。其实当这个系统上线的时候才是IOC的开始。我们要做的事情是保证每天都能用。所以说，我把它做上来了，我当时感觉很牛很有成就感。事实上真正难的是我要做到365天，不管那个人在全球的哪里，他打开手机打开电脑他都得是对的。所以其实我们做的是一个365天的承诺，每天每天陪伴他的承诺。
该项目经理从2018年开始负责运营商板块的IOC建设。下面是4年项目结束时的一段总结：
“其实发现很多事情就现在我们习以为常，已经成为日常生活中一部分的事情，其实在5年前却是一个神话。我记得有一次在公司在汇报答辩的时候，当时就被问到为什么就是那时候的销售预测数据质量不行、不可用。我当年刚从一线回来非常大胆。我非常大胆的说了一句话，我说这公司30年我们在一线感受到的，它就是基于人治，基于人的治理和管理，不是基于数据的治理。”
总结：消除手工报告为什么那么难?
传统企业要实现从手工报告转变为线上报告，一方面确保数据准确、真实，另一方面减少大量的中间加工、处理、决策环节，存在一系列天然的障碍。只有逐步克服这些障碍，才能实现数字化转型的基本目标。
1、数据标准、指标统一是基础
首先确保单一指标的唯一性，这首先需要明确唯一的指标责任人。文中提到的订货指标的归属争议问题，并非说华为领导多没大局观，相反正反应大家的责任意识。
其次是分析的维度，这是指标之间整合、对齐、比较的重要条件。以组织维度为例，前端业务系统的订货预测数采用来自于人力资源系统的组织，完全符合要求;而财务系统的订货实际换了个财务专业说法，责任中心，跟组织似是而非。以前线下手工处理时，尽管费些力气，但“表哥表姐”们熟能生巧，基本很快能一一匹配上，并没有发现什么不妥。但如今打算从系统里直接把订货预测数和订货实际数按照组织维度拉起进行分析，问题马上就暴露出来了。
2、原始数据质量(准确、完备、稳定)是前提
数据质量是老生常谈的问题，有些跟技术有关，有些跟录入者的责任心有关，也还有其他原因，如跟业务真实性有关。文中选择的销售机会点(商机)便是其中典型的例子之一。
机会点掌握在客户经理手里，这关乎他的饭碗、前途，还有钱途，是不会轻易暴露出来的。即使在华为，每个客户经理的“地盘”相对明确，也要考虑机会点提前过早暴露所带来的风险，一方面万一丢单了同样会受到追责的，另一方面被上级掌握了“底牌”，不免在目标方面加码。
3、系统稳定性是保障
报告系统有一个大家所熟知的名字，决策支撑系统。往重要里说，是支撑各级管理层决策的;往轻里说，报告系统只是用于决策的数据来源之一，况且管理层决策也并非唯数据论，锦上添花。这便是大部分传统企业的报告系统的生存现状。
消除手工报告，完全依赖于线上数据。这意味将从“支撑系统”升级“指挥系统”。这种转变对于系统的稳定性和可用性的要求完全不一样了。还有一个因素，让大家改变过去线下看报告的习惯，一单事故便足以作为借口否定过去所有的努力。这一点跟ERP等系统的境遇并不一样，原因在于后者别无选择。
4、领导以身作则是原始驱动力
引用某个一线的销售经理说的，“领导你就喜欢看PPT，我为什么要给你录，你不是给我增加两倍工作量吗?”
因此，管理层带头改变过去被动接受报告的习惯，倡导自己主动进系统看数据。一方面，带头进系统看数据，加快决策效率。同时，这也是促进系统数据质量提升最有效的手段。
有一次跟某客户省级公司总经理交流时，对方非常开心地分享了他最近的一点经验。他安排信息部门开发了“天天看”、“月月看”两个应用，其中“天天看”是移动端APP。他强调，APP首页只展示7个最关心的经营指标，不用翻页，足够了。想看哪个指标，点进去不超过三步，可以找到需要管理的问题。他现场沿着一个汇款指标点进去，定位到某客户的问题，直接截屏通过WX发给相应的责任人。不久对方便回了信息，解释原因。
尽管这个应用看起来一点都不高级，但公司总经理“天天看”，下面的人员能不“时时看”?
5、用户部门长期参与是活力之源
本文每个阶段结合平台建设简单介绍了一些与之相关的运营管理背景。可以说，华为从来不是先建设好系统再考虑组织，至少是同步进行的。因此，明确的用户部门对此负责，并愿意长期参与建设，是系统平台长期发展的活力之源。
后记
数字化运营不仅仅只是消除手工报告，IOC的作用也不仅仅是替代原来的BI报告。
华为的IOC应用已经几乎覆盖了公司内各大业务。听说工信部某领导在参观了华为的某领域IOC之后，感到非常震撼，给了这样一句评价：“看了这么多IOC，只有你们华为的才是真的IOC。”