工信部将我国数字化转型分为信息化（Information Digitization，1956-2003年）、业务数字化（Business Digitization，2003--2016年）和数字化转型（Digital Transformation，2016年至今）3个阶段。除去那个依靠企业内部服务器和个人电脑PC机的“远古时代”的企业信息化阶段之外，至今我国也经历了大约20个年头的数字化成长历程。
在这个历程中，最能够尝到甜头的是互联网企业，数字技术俨然已经成为了这些企业的核心竞争力之一。而对于传统实体企业来说，那些新生的小微企业大部分在补信息化阶段拉下来的课；而那些规模大的龙头企业则在数字化这条道路上不断试错，他们对数字化的看法是：不可或缺，但又食之无味。数聚股份作为一家14年来专注提供数字化解决方案的国内知名服务商，也在这个以数字化为主浪潮的时代中，见证了这一切：
案例一：某国内知名服装制造企业，虽然企业规模和销售体量有限，但在智能制造方面也深耕了数十年，且一直处于服装行业先进智能制造的领先地位，可以说该企业在将数字化技术应用于生产制造上，已经是先行者和成功者，那自然而然的，就希望能够在企业管理实践层面，也进行数字化改造。可是，这条道路却极其艰辛。不论是整体的商业智能平台项目，还是综合的数据大屏可视化项目，或是专题的数据分析挖掘项目，其输出的成果物上线后前半年还有一定的“热度”，半年以后能够被持续下来使用的不超过10%。
案例二：某国内知名消费电子品生产制造企业，始终以管理方法领先为保持企业持续竞争力的主要抓手，其早在12年前就已经具备国内一流水准的信息化水平。但在这个数字化时代里，中高层管理者却每周还在吃数据服务不满足管理要求的“苦”。这并不是因为数据服务部门消极怠工，他们的痛苦和难处则更甚，为了给周一例会提供及时的、准确的数据，以及有业务价值的数据分析，一年到头休不了一个完整的周末，领导越不满意，部门人员就越是动荡，上岁数的老人都被熬走了，新来的年轻人失误频频，服务质量越来越差。
案例三：某国内知名物流服务企业，具备全国的运输、配送网络，并且始终将数据应用作为提高客户满意度、以及降本增效的最重要武器，曾经招聘了大量的数字化人才，其中不乏大量的研究生和博士生，希望能够充分发挥总部职能，全面提升数据应用的水平。然而，现实中的结果却大相径庭，项目成果中的高层次的抽象概念、专业的统计学指标，大部分的业务和管理人员都无法看懂，逐渐的这个项目就变成了分析部门自己把玩的“铁核桃”，随着人员的更替，项目也就“寿终正寝”了。
在案例一中，那些很少被使用的90%的项目成果物，在项目进行时也是业务真真切切提出来的需求，但为什么交付之后又不会被使用？我们认为最主要的原因是：该企业在组织架构上使用“倒三角”，给员工和中层管理者更多的自由度，这也导致在业绩好的时候，没有数据分析的动力；在业绩不好的时候，没有数据分析的时间；面对业绩问题束手无策时，才想到需要数据分析，这时又发现之前设定的分析思路，已经不符合当前的需求；需要修改调整分析系统时，又由于业绩不好没有充足的资金，迟迟无法开展。
所以，我们建议，特别是对于规模小的企业就更应该在业绩好的时候，把数字化建设的重点放在数据模型设计的“全面性”上。一方面，规模小的企业可以只抓主营业务场景进行数据模型建设，这使得在一期的项目中将数据模型建设完善具备了可能性；另一方面，全面性也意味着不是直接的按照用户需求进行设计，而是依据企业的主营业务进行设计，这样设计出来的模型与特定人员的分析思路无关，更能够客观的、专注的体现企业本身。在这种“稳定”的数据模型基础上，再进行各种分析思路的实现。不论是通过固定报表、可视化交互仪表盘，还是敏捷BI提供的自助分析能力，都可以因人而异的快速实现。
在案例二中，大型集团企业肯定会面对产业多元化的问题。“那几个老产业的数据确实不大费工夫，但是这几个新兴的产业刚建立不到6个月，连组织分工、业务流程、管理规定都不完善，集团还整天向他们要数字，这可真难为了我们数据服务部门”，某个周日晚上正在加班等数的运维工程师孙晓光，在喃喃自语。在这个世界上，规模会决定很多事情，两天的时间如果是解决三四家分公司的数据问题还算轻松，但是要面临十几家公司的数据问题，在强逼之下他们都无法及时提供数据，对于等数的工程师们就到了濒临崩溃的边缘。
所以，我们建议，对于大型集团企业，需要设计出一套集团层面通用的分析模型，将其作为管理标准的一部分，任何一家分子公司的建立，能够执行这些标准都必须是基本条件之一。比如：能够按照标准的要求，及时的把数据提报上来。如果这些分公司规模太小或前景不明朗，暂时不要把他们纳入到每周例行的分析体系中，可以按季拎出来单独分析。
在案例三中，要实现具有深度的数据分析当然离不开设计精良的数据模型，但是企业中的数据应用不是搞科学研究，不是根据“刻板”的客观世界进行数据模型设计的，而是根据企业中“活生生”人的业务活动和管理活动来设计，所以数据模型需要有“前序”的明确定义好的业务模型和管理模型作为依据。在没有将业务模型和管理模型成功的植入到使用者的大脑之前，就强推数据模型和分析模型，肯定是无法被接受和使用的。
上面的文章中提到了数据模型、分析模型、业务模型和管理模型。那么首先要回答一下：什么是模型？我们是这样认为的：“模”所代表的是“模仿”，“型”所代表的是“样子”，而在这个世界中最需要模仿的就是现实，所以从建设模型的过程来讲就是“现实样子的模仿”，从建设模型的结果来讲就是“模仿现实的样子”。
模型一般具有两个用途：一是进行实验，将模仿的样子放到现实之中，与现实交互，以验证理论；二是体现套路，将错综复杂、略带隐晦的现实抽象概念放到一个有型的容器里，让使用者能够容易的、直观的理解，方便的、可信的使用。在企业数据应用领域中，我们接触较多的是后者。模型不同于“口传身教”的经验，模型需要在设计上需要具备一定的理论依据，不能凭空捏造。其实，每个理论基础中也都包含模型的要素，从这个角度看，一种模型总是另外一种模型或多种模型组合的延续。
模型在纵向上，要能够承上启下，在横向上，要能够包容万象。用技术的语言来讲，就像一个“万能接口”，当然“万能”的范围是有限的，通常是指这个模型要应用的场景。
在数据应用领域，经常可以接触到的四种模型，可以按照模型的解释来理解他们：
业务模型：业务样子的模仿，模仿出来的样子通常可以用业务流程图来表达其“型”；
管理模型：管理样子的模仿，模仿出来的样子通常可以用管理结构图来表达其“型”；
数据模型：数据样子的模仿，模仿出来的样子通常可以用数据关系图来表达其“型”；
分析模型：分析不是一个对象，是一个操作过程，所以分析模型是分析过程的模仿，模仿出来的样子应该是一系列模型如何配合起来，在一个平台中统一进行使用，可以用分析过程流程图或者分析过程的操作手册来表达其“型”。这四类模型的关系如下图：
数据模型的设计要来自于企业的业务模型和管理模型，而分析模型的使用是在使用者充分理解业务模型和管理模型的基础上，并能够依托软件技术来灵活的运用数据模型。
在后续的章节中，会详细介绍具体每种模型，以及他们之间的依赖关系。
让我们一同努力，让“数字化的未来不是梦”早日实现！
文章作者：王栋、孙启琳、陈琳琳