企业数智化软件的市场机会｜ OLAP究竟是业务应用还是技术平台

曾听到某万亿级企业的老板将企业数字化总结为两句话：“ 一切业务在线，数据驱动业务 ”，我觉得这个说法特别精准。企业的信息化和数字化的实质，不外乎是 生成数据、管理数据和利用数据 ，因而，我认为企业级信息系统可以分类为“两在线一平台”。

“两在线”，其一是“在线事务处理系统（OLTP）”——生成数据，包括了ERP、CRM、电商平台等等各种内部、外部处理业务和管理事务的系统，其二是“在线分析处理系统（OLAP）”——利用数据，包括所有生成业务洞察，支持业务交易的系统。而“一平台”则是指衔接所有系统、打通企业数据的数据平台，不管你把它叫啥：数据仓库、数据湖、数据中台、数据编织……其实都是数据平台的一部分以及一类技术架构或实现方式。

（一）

我们现在常说的“企业数智化”，实际上是OLAP系统在发挥作用，尤其是高级阶段的OLAP。既然称这些系统为“企业级”，代表着基于企业数据的，跨部门、跨职能、跨系统、跨数据源、长流程的复杂业务决策优化。从企业信息技术应用的发展历程来看，一般都遵循这样的系统建设阶段：

1、首先建立覆盖主要业务流程的“在线事务处理系统”（OLTP），以ERP、CRM等核心业务系统为代表，实现“一切业务在线”

2、其次，在已有的OLTP的基础上，建立初级的数据分析功能，即“ 初级OLAP系统 ”，实现报表、图表、查询以及数据挖掘功能

3、随着各个OLTP系统建设的覆盖面越来越广，例如ERP的周边扩展系统建设，以及外部数据源的接入，建立企业级大数据平台

4、基于企业级大数据平台，利用机器学习、深度学习等人工智能技术，提供支持业务的高级分析（Advanced analytics），建立“ 高级OLAP系统 ”。

在这个历程中，OLAP系统的能力可分为循序渐进的三个阶段（有些数据分析理论在描述性和预测性中间，还加了一个“诊断性”阶段，指对历史数据的挖掘、归因分析，本文为简单起见，将其拆到前后两个阶段中）：

高级阶段的OLAP采用了运筹学（Operations research）优化算法，其原理是面向优化目标，在条件约束之下，以数据输入为变量，给出决策方案的优化选择。：

在中国的大学课堂里，类似于“ 多级渠道分销和供应链网环境下，基于多目标的生产计划制定的模糊机会约束规划 ”这样的课题，是最近三十年来长盛不衰的学术论文题目。中国是个制造业大国，经济快速发展，这类学术研究有着广泛的现实应用意义，这就是OLAP在供应链领域里解决的业务问题，给企业带来的价值。

（二）

前面提到的企业建设信息系统的四个阶段，OLAP要略晚出现于OLTP——OLTP从80年代开始在企业推行，到90年代后期，OLAP概念开始出现，当时在欧美就已经开发出基于运筹学、系统动力学、事件仿真等理论的高级数据分析应用。今天，欧美大企业的数据科学应用已经相当普及了，然而，就我对中国企业信息化行业的观察来说，直到今天，导入了 高级OLAP 的企业仍然是凤毛麟角。

最近几年，随着全球范围内大数据、人工智能的基础技术的更新换代，中国打着数据中台、人工智能旗号的创业公司在资本推动下，风起云涌，似乎OLAP的春天来了。

我观察到国内OLAP公司普遍存在的问题是： 解决方案产品化程度低，他们自己甚至都讲不清楚自己究竟是一家IT服务公司，一家算法公司，还是一个应用软件产品商，还是一个技术平台提供商 ？而站在企业客户的角度，老听他们软件厂商说一些“中台”、“人工智能”、“数智化”、“数据驱动”一类似是而非的大词儿，却听不懂他们究竟核心能力是什么，每家厂商差异性在哪里，能给企业带来什么价值？

这确实是摆在国内OLAP公司面前的产品策略问题：你究竟提供的是一个包含了企业最佳业务实践、用户体验良好、功能完善的应用软件——我姑且称之为“ 应用派 ”？还是提供一个具备强大优化能力的数学工具以及应用开发平台，但是具体业务应用需要通过咨询公司和集成商、在项目中根据客户需求去构建——我姑且将提供算法内核的称之为“ 内核派 ”，提供开发平台的称为“ 平台派 ”？

OLAP实施过程和OLTP不一样，需要对数据进行探索、对模型进行迭代优化，最终达成分析目的，因而一方面OLAP软件的业务标准化程度较OLTP低，另一方面对实施人员的要求更高，需要理解用户场景， 将商业问题抽象为统计学和运筹学问题并且建模解决 ，相应的OLAP实施角色和OLTP类实施项目也不同：

（三）

“内核派”和“平台派”最具代表性的厂商是IBM。IBM从彭明盛接替郭士纳上台后，致力于向企业软件商转型，致力于发展数据分析的软件产品线，先后收购了BI软件Cognos和TM1，统计学软件SPSS，以及基于约束的规划的运筹学优化软件iLog，再加上其原有的中间件平台IBM WebSphere，数据中间件平台IBM InfoSphere等，在2012年前就构成了完整的高级分析软件产品线。

iLog是上世纪80年代末期在法国创立的用于资源优化求解、业务规则管理、优化方案可视化的软件公司，1997年，它收购了美国的一家名为CPLEX的线性规划求解器公司，到2008年7月被IBM以3.4亿美元收购前，iLog被认为是规划求解器最领先的商业软件公司。

iLog的优化决策管理器（简称ODM）是个通用软件，它以优化求解器为内核，提供了开发工具、应用界面、可视化展示、数据接口和应用接口等：

iLog ODM的优化器内核可以在单机的本地环境下运行，也可以作为服务器运行，包括如下内容：

优化决策管理器的系统原生界面如下，这是用于港口的集装箱堆场调度的例子：

数智化的应用场景（也称为“用例”）举例如下，也就是说以优化求解器为内核，以数据管理和算法开发为平台，外面包上用户界面的“壳子”，可以做成包含如下一项或多项功能的应用软件：

制造业

-供应链网络优化

-生产计划

-原材料、半成品、产成品和服务备件等多级库存水平优化

-车间详细排产

-运输计划

-设备维修计划

消费品和零售业

-门店选址

-仓库和物流网络决策

-库存水平优化

-门店品类组合

-定价和促销优化

-清仓折价决策

-门店布局和商品陈列

-顾客个性化营销

物流和交通行业

-存储点和仓库选址

-车辆、容器配载优化

-运输网络优化

-场站、人员、司机和维护的详细排程

-车队调度优化

-库存水平优化

电信和公用事业

-网络容量规划

-断网维修计划

-设备选址（例如中继站、铁塔）

-路由规划

-设备和服务配置

金融服务

-资产组合优化和再配置

-信贷池

-交叉交易

-产品和定价优化

其他

-人员排班和劳动力优化

-工作任务分配（可以设想一下美团快递的派单，或保险公司派人现场查勘）

-市场营销活动优化

-广告排期

-采购的拍卖竞价策略

-营收优化（例如航空公司的机票超售策略）

可以开发定制的用户界面，结合iLog提供的可视化工具，可以做成各种优化应用，例如：人员考勤排班系统长得这样的：

也可以做成甘特图样式的火车运行图：

（四）

iLog ODM是典型的“内核派”，提供问题求解的核心技术，但是本身并不是一个面向业务流程的应用软件。虽然iLog其实也提供供应链计划的应用软件，但是市场上并不普及；“应用派”在企业供应链计划优化领域里，最有代表性的就是SAP APO和JDA（以及i2）了。这两个软件都是90年代末期发明，经历了十多年发展，形成了基本一样的业务解决方案框架，以下讨论我们以SAP APO为例：

早在1998年，SAP就投资了同在欧洲的iLog，并且在其自己新推出、作为王牌产品ERP补充方案的供应链优化软件SAP APO中，使用iLog作为求解器。直到十年后iLog被IBM收购时，SAP都是iLog最大的客户。

SAP APO从推出的第一天，就包装出了供应链计划体系里各个 环节上的 业务应用，包括需求计划、供应网络计划、生产计划、车间详细排产、运输计划、全局交期承诺等。

SAP APO处于基于SAP数仓（也可以用Teradata等非SAP数仓）的BI环境，统一应用面向分析而设置的数据集市（SAP术语叫“数据立方体”）或内存计算数据库，几个应用场景根据其分析性质不同（分别是时间序列或者订单优化），采用不同的数据加载和优化计算方法：

近年来，随着SAP总体架构向HANA以及云平台迁移，SAP APO的架构也发生了变化，偏重时间序列分析的部分整合到云上的IBP平台，偏重需要实时订单优化的部分，则整合到基于内存数据库HANA的新一代ERP核心里。

（五）

在企业级系统“架构现代化”（architecture modernization）的进程中，数据分析应用会比核心业务系统更先上云。

今天，开发优化器的组织越来越多，免费或者开源的优化器。云环境下也有很多用户自己动手搭建OLAP系统，下图是我们参与的某企业自研APS系统，该系统采用了云原生架构：将多个核心系统的数据上载到云上的数据湖里，相关数据集送到目前流行的机器学习框架和分析引擎Databricks上，数据科学家和工程师在这上面采用Python脚本，调用一个名为Gurobi的求解器云服务，将计算结果传到一个数据库里，由前端工程师开发订单确认和排产调度的应用。

新的APS系统上线后，该企业订单确认及排产时间从两天缩减到一天，由于提高了订单排产的可视化程度，设备换产效率提升了20%。

Gurobi是最近开始流行的新一代求解器，对Python等流行的编程工具支持更好，据说其创始人跟CPLEX有一定的渊源关系，目前国内某优化器创业公司创始人跟Gurobi团队在学术上也有渊源关系，而一些其他优化器公司也都将iLog/CPLEX和Gurobi作为参考对象。这些创业公司都需要回答市场：自己究竟是一个业务应用软件（或者是供应链计划优化、或者是人员工作分配优化），还是一个数学软件（既可以单卖，也可以作为其他业务应用软件或者OLAP系统的优化器），还是一个OLAP系统开发平台？

（六）

类似于这些运筹学软件、原则学术界的数学软件，还有一类叫“系统动力学”软件，在果总八十年代末、九十年代初念大学的课堂上，是和统计学、运筹学三足鼎立的“管理科学软件”。

到90年代末，系统动力学软件（比较有名的是STELLA、PowerSim）曾经有商业化应用尝试，平台是大名鼎鼎的SAP！资深SAP顾问可能都不一定了解，SAP和APO类似的另一个OLAP系统——战略企业管理（SEM）里，曾经提供了用系统动力学软件工具PowerSim作为模拟引擎，来进行做业务计划时的场景模拟，是当时SAP计划和预算系统（即SEM-BPS）的一部分（见下图）。作为科班出身学系统动力学的，我当年看到这个SAP 方 案时瞠目结舌，大学里学的那么冷门的东西居然没白学。不过， 这个工具也许是 过于学术化、 过于高 端了 ，难以被 驾驭，没过几年， 更简单的SAP BPC逐步替代SEM-BPS作为预算工具，似乎就再没人提起过这个PowerSim了。

在2007年时，我偶然参与过某个咨询项目，利用系统动力学软件来帮助某汽车厂开展新车型上市后的市场环境仿真，从而制定该车型的维修保养服务备件的定价策略——在车型生命周期里，是先低后高，还是先高后低。 这个方法确实是太阳春白雪了，中国的企业领导不太相信基于数学模型的“电脑算命”，后来我很少遇见过同类项目。

今天，大数据和人工智能被资本炒得这么热，谁知道曾经也有过商业应用经验，八十年代源自MIT、非常冷门的系统动力学软件，会不会作为OLAP和人工智能的“创新”而重出江湖呢？——也许这是各位读者读果总这篇文章，到此最大的收获。

关键词： 应用软件 人工智能