从百丽IT建设看信息化、数字化和智能化的关系：信息化——局部与规模 | 数字思考者50人|智能化|百丽it建设|百丽国际|自动化|计算机

传统消费如何与新兴科技融合，激活庞大的客户群体、协同丰富的数据资源，提供精准高效的决策支撑？国内大型时尚鞋服集团百丽做出了样本，并在竞争激烈的市场中稳占先机。此前，百丽时尚集团科技中心总经理季燕利在钛媒体发布过多篇数字化深度思考：《百丽的核心竞争力与数字化》《从补货场景，看企业协同在线》《从无数到有数，如何深入数据应用与治理》《数智化在零售企业的应用探索》。这一次，他和团队、合作伙伴一起以超过5万字的文章，从百丽的业务视角出发，依据多年企业管理、业务运营和IT技术摸索与实践的经验，系统阐述了信息化、数字化和智能化在现代企业中的应用与发展。根据上述不同建设阶段，经钛媒体编辑分为三部分连载，本文为第一部分信息化阶段的探索和经验。延伸阅读：百丽IT建设实践与探索之数字化：“连接促整体”——循环往复，数字化作用于资源的调度百丽IT建设实践与探索之智能化：“运转到进化”——全速运转，催生数字化高级演进

前言

在过去几十年里，IT工具不仅深刻改变了我们的日常习惯，也彻底重塑了企业的工作方式。伴随技术的不断演进，企业的IT建设经历了显著的阶段性发展。业内通常将这一过程划分为三个主要阶段：信息化、数字化和智能化。而我们在实践中愈发深刻领悟到在实际的企业IT建设中，这三个阶段是可以相互交织、并行推进的。一家企业可能同时处于信息化、数字化和智能化的不同发展时期，根据自身业务需求和发展战略，采取相应的措施和技术手段来推动各个层面的进步。例如，一家零售公司可能会继续优化其ERP系统以支持新业务带来运营流程更新（信息化），同时开发数据平台以更好地了解零售多维度运营的表现（数字化），并且引入AI算法以寻找整体的销售和利润的空间（智能化）。

然而，尽管这些术语被广泛使用，许多企业和IT从业者对企业IT建设和三个阶段的内涵与边界仍存在不同理解。信息化、数字化与智能化分别代表了企业发展中不同阶段的核心任务。其本质是将技术进步如何融入公司的核心竞争力的建设之中，这也是一个不断实践、不断深化认识和不断提高水平的过程。信息化的重点在于数据的收集，它围绕业务流程，构建局部的功能模块。数字化则着眼于整体，通过对收集到的数据进行整理、标准化和治理，形成统一的、真实的企业数据视图。数字化的建设过程不仅仅是对信息化阶段流程断点的补齐和完善，它既依赖于持续的信息化建设，也通过自身的治理能力不断推进系统的整体优化。智能化着重于整体连接的自动化运行和自我优化，以数字化所提供的真实数据为基础，结合市场的动态变化，实现整体的自动化闭环运营，通过持续的反馈和优化，推动企业在运营层面实现飞轮效应。

IT建设是一个持续的、系统的、不断进化、不断完善的工程建设。在常规认知中，信息化阶段以部门需求为起点，侧重流程驱动和功能建设，目标是提升业务效率。随着业务规模发展，市场竞争日益激烈，企业希望通过技术手段提升业务运营效益，IT建设进入数字化阶段，数据成为核心资产，侧重于整体性的数据驱动和回路建设，而数据能否真正成为公司的核心资产完全有赖于公司对数据的定义、抓取、分析和利用。接着，智能化时代到来，企业通过智能技术优化资源利用，追求整体效能最大化。然而，智能化的实现不仅依赖信息化的采集能力，还需要数字化治理过的完整数据体系。没有信息化，数字化无从谈起；没有完整数据，智能化无法实现。因此，IT建设并不是简单的项目堆叠，而是一个遵循工程化逻辑渐进性、系统性的建设过程，必须从地基开始逐步构建。

企业IT建设应坚持长期主义，以迭代的思路不断探索与演进。智能化的建设并非能一蹴而就，它在不断深化的过程中，往往会揭示出信息化和数字化阶段中尚未完善的部分。这些不足之处，尤其是基础系统的局限性和数据标准化的缺失，通常会限制智能化能力的充分发挥。正因如此，企业通过智能化建设过程中所暴露的问题，识别并解决信息化和数字化阶段的薄弱环节，进一步完善基础系统，确保各阶段协同发展，实现技术与业务的深度融合。完善的过程实际上也是企业运营不断迭代与更新的过程。随着信息化、数字化和智能化的协同推进，企业能够在持续优化的循环中，逐步提升整体的运营能力，最终实现业务的长足发展。

从技术演进的视角来理解：信息化、数字化、智能化

本文是以业务视角出发，依据多年企业管理、业务运营和IT技术摸索与实践的经验，阐述信息化、数字化和智能化在现代企业中的应用与发展。本文第一部分信息化，首先表述了业务操作系统界面的复杂性及其原因；其次阐述了从业务需求到编码落地的过程，表明了系统建设的复杂性；最后系统与系统之间的断点，导致了IT支撑业务运营的复杂。第二部分数字化，首先如何用“协同在线”的方式连接了系统与系统之间的断点；其次通过回路的建设构建了真实的业务及管理；最后阐明数据平台的作用及网络形成，以及企业数字化的标志。第三部分智能化，首先表达了AI助理的应用；其次探索智能决策；最后探索智能整体运营。

信息化：“局部与规模”——负重前行，信息化困于规模化的挑战

九十年代初期，互联网正式进入了商业时代，网络把世界连接，激活了世界上的各类组织，带来了世界范围内信息化蓬勃发展的30年。中国最早的企业信息化从财务电算化开始，利用电子计算机技术处理会计业务的过程，使用财务软件代替传统的手工记账方式，这一变革极大地提高了财务管理的效率，减少了人为错误。从企业的角度来看，信息化开始的一个重要标志是计算机的普及应用，当企业开始大量使用计算机来进行数据处理、文件管理和日常办公时，可以认为该企业已经步入了信息化的门槛。

随着信息化建设的普及，业务规模的扩大，信息化带来了许多弊病，许多业务人员抱怨“系统不好使，需求响应慢，数字对不上”等，其背后的核心原因不是一个简单的系统升级就能解决的，它是以组织变化带来的流程变化及按流程变化迭代的系统化发展造成的。

我们企业三十多年的发展，规模不断的扩大，其业务特征是：多品牌、直营模式、从设计到生产到零售实现端到端运营，逐渐演变出组织庞大、根据市场变化业务调整频繁等特征。基于这样的业务运营特征，我们的核心业务系统是自研为主，从而能更加自主地适应业务的发展与组织的变化。

随着时间的发展，在系统的迭代过程中，更多的需求满足是在原有系统规则上堆叠新的规则、建设新的界面，长此以往，造成系统的选项越来越多，系统的操作越来越复杂。

本章从业务视角，通过三个方面来描述系统不好使的原因。

首先，描述单系统界面操作和业务配置这一“艰巨而复杂”的业务日常工作，为大家呈现信息化这个庞大工程的感观体验；
然后，从业务提出的一句需求开始，描述需求到编码的信息化工程建设的主体过程和方法，充分肯定了信息化为企业核心业务的底层逻辑打造一个又一个基建级的系统，“一句话即一项工程”，让企业各部门更加深刻理解每个业务需求背后的分量；
最后，随着企业规模的扩张，业务流程也会变得更加复杂，信息化在面对协同所需的连接和互动时表现乏力，用信息化的方式解决需要付出更大的精力与成本，而且还常常效果不佳。其根本原因在于它踢到了管理、组织和系统这道墙。这既是企业信息化一定要进化到数字化的必然，也是企业信息化进化到数字化的最大挑战。

一、界面与配置

信息化的特征之一是通过系统界面进行业务操作。业务用户通过登录系统，进入与其岗位相关的界面，进行各种功能操作。系统界面承载了业务流程，通过菜单、选项、按钮等工具帮助用户完成任务。这就是IT团队为业务团队提供的工具，用户通过界面与系统交互，完成一系列业务操作。

系统的复杂性在于其背后的配置。一个系统可能包含上百项复杂配置，业务人员需要根据不同需求在系统中调整选项，而这些配置的选择直接影响操作的成功与否。如果配置错误，系统会报错，造成业务中断。这种操作，实际上是业务逻辑通过系统语言执行的过程。

1、操作界面

系统是为了满足业务规则要求、支撑业务流程运作而设计出来的IT工具，系统开发的背后是一系列业务规则和流程需要的逻辑叠加，再用程序语言的逻辑来实现。操作系统的业务人员需要清晰地了解所有的业务规则、适应范围，并能掌握这些业务规则和适应范围在系统中的页面、配置、选项等细节要点，并结合当下的实际情况进行分析判断。这些完备的要素与条件对操作系统的业务人员的专业度要求很高，尤其是当一线业务人员有繁重的业务工作时，IT系统往往从提效工具变成了额外负担，完全背离了建设的目的与意义。而当业务人员变更时，为操作系统带来更多的挑战。

理想状态下，以下是一个大致的业务操作情形：

业务人员登陆系统，完成身份鉴别，然后打开「任务目录」菜单，进入用户交互的界面，进行相关内容的配置，执行操作，完成预定任务，达到预期目标。理想中的业务操作是流畅和高效的：业务人员只需按照既定的规则，在系统界面上选择相应的选项，配置条件，便能够顺利完成业务任务。

但实际上发生的操作情形要与理想状态产生较多的偏差：

用户打开菜单进入到交互界面时，为了完成所有的配置，往往需要更多的信息。因此，用户需要切换到另外一个系统去查找并确认所需的信息，然后再返回到交互界面去完成所有配置。然而，有时候系统会提示配置选项错误，用户需要撤回之前的操作，并思考问题所在，相应去查看更多的信息，再返回该系统的交互界面去进行配置，尝试是否能顺利完成操作。也有可能出现操作失败，还需要反复多次这样的思考和尝试过程，甚至与其他部门或者IT部门去沟通解决问题。不同的配置选项会产生不同的操作效果，错误的配置可能导致操作失败，甚至影响整个业务流程。在这个过程中，业务的熟悉程度和逻辑思考能力直接决定了业务人员通过系统完成业务任务的质量。

从上面的例子可以看出，业务人员要基于IT系统顺利完成一次操作，需要先梳理所有相关条件，全面了解系统界面呈现的各类选项，并结合业务逻辑进行正确配置。他们不仅要熟悉系统的内部规则，还要清楚了解业务操作的时效性、度量单位、组织范围、通知机制以及容错方案等多方面的要求。每个选项的选择都必须经过细致的分析，确保与其他条件相符。配置过程如同解锁密码本，稍有偏差便可能导致操作失败。如果输入的配置不符合要求或出错，系统会返回错误提示，业务人员需要细心排查并修正配置，直到系统接收并执行正确的指令。

单个流程本身是非常简单的，但是它面对多个业务组织时，同一个流程上就有多个选项，对于业务人员来讲，了解每个界面的选项，并按具体业务进行操作，再将操作结果给上一级审核，因此管理必须要分工明确、过程要认真负责，才能确保业务操作有效。

信息化时代：用户探索在界面上

2、组织与系统的关系

随着组织规模的扩展、业务流程的增加，系统的操作变得越来越繁复。企业的每一次扩张，都会增加新的业务规则、流程节点和决策条件，而这些变化最终都需要通过系统加以体现。每一项新规则的引入，都意味着系统需要增加新的配置项，现有的配置逻辑也可能因此需要调整，业务人员的操作也随之变得更加精细和多样。

为了更好地理解这种变化带来的影响，我们可以借助一个常见的零售企业案例来解释。收银系统是零售企业终端门店高频使用的系统，是支撑店铺的账实相符、账账相符的核心IT工具之一，而一线的销售人员操作这个系统就是终端的数据采集源头，准确与否尤其重要。公司的门店收银系统（POS系统）从最初的只有线下现金收银，增加到有十余种支付方式、同时支持各类礼品卡、优惠券和促销活动；从全渠道共享库存开始，店铺又增加了跨店、预售、定制等业务，系统随之不断迭代更新，目前总共有50多个菜单，其中销售相关10多个菜单，商品相关30多个菜单，店务相关10多个菜单，这些菜单以及里面的功能，都需要店员学习并掌握在什么场景下基于什么样的管理要求，做什么样的操作。

一个开单的过程，店员大致需要进入10多个界面进行操作处理，这并非技术方不懂得需要简化业务的操作，而是为了全面满足不同店铺的不同业务场景及相关的管理要求和规则，兼顾操作的便利性而给出的整体方案。POS系统背后，有各类别的控制参数400多个，对接了50多个其他系统，有350多个接口，200多个数据交互类型。正是由于这些操作条件和逻辑关系的增多，系统的操作变得更加繁琐。业务人员不仅要掌握系统的基本功能，还要灵活应对各种临时情况。尽管系统的设计初衷是为了简化业务流程，但随着功能的不断扩展，业务人员面对的操作界面变得愈加繁多，操作步骤愈加细致，稍有不慎便可能导致错误。通过这个例子，我们可以直观地感受到系统操作在企业发展过程中所经历的变化：从最初的简单操作，到逐渐充满多层次条件和约束的流程，每一次操作都需要严谨的逻辑推理和高度的熟练度。系统的复杂性，不仅体现在功能的叠加，更体现在操作人员所需应对的多重变化和细节调整上。

3、系统配置的复杂

界面操作的复杂性，背后也体现了系统配置的复杂性。随着业务模式的变化和流程增加，是增加系统还是在原有系统上进行改造？增加系统意味着增加整块的成本，所以大部分都是在原有系统上增加功能来满足。这些增加的功能对于系统应用来说，就是增加配置，而这个配置需要IT人员来实现和维护，系统的这种配置越多，维护起来的成本越高。例如：POS系统建设过程中累计了400+个参数进行业务控制，大区参数可以按大区控制业务规则和系统逻辑，店铺参数可以按店铺来控制业务规则和系统逻辑。新开店铺时，业务人员及IT人员会根据新开店铺的要求进行店铺初始化的配置（如店铺收款账户、店铺收银方式等），通常是复制同类店铺的参数进行快速配置，也可根据店铺个性需求进行调整。店铺日常运营中临时的业务规则调整，也可以通过参数调整来快速实现业务的变更，比如临时调整店铺设置来支持无原单退换货的场景。系统参数的建设，在支撑了店铺业务的多样性和灵活性的同时，也会带来运营维护的复杂性，同时对IT支持人员的要求也越来越高，进而增加了维护成本。

系统从好用到不好用的核心原因，也是因为不断增加配置所导致的。因为系统配置和规则都服务于业务流程，相互之间有关联性，其调整还需要考虑确保业务流程的可执行性，如果考虑不周全，规则配置冲突，会导致流程无法正常执行甚至报错，这也导致了业务人员经常抱怨系统有问题。再加上组织变更和员工更换往往需要大量的系统培训，让新的角色或员工熟悉不同流程、不同的配置选项，通常需要一定的时间去适应才能顺畅地操作系统，而这个上手的门槛随着系统配置的复杂而越垒越高。

界面的操作及系统的配置之所以复杂，一方面是业务规模增长造成了组织逐步庞大，另一方面是出于成本的考虑而选择在原有系统上进行迭代的模式。当系统的建设发展到一定规模时，这种在原有系统上迭代、增加配置的方式，对业务管理和IT人员的维护来讲，成本的增加越来越大，同时，业务人员也会感觉系统越来越不好使，IT人员在维护系统的过程中也会越来越难，这些都极大的增加了管理成本。

二、从需求到编码

当业务部门提出新需求时，IT部门的任务是将现实中的流程和规则转化为计算机中可执行的系统功能，也就是把现实世界的业务需求转化为计算机世界中的编码，从而帮助业务人员完成业务过程、达成业务目标。这是一个将复杂的业务逻辑映射到技术实现的过程，要求IT团队对业务逻辑有全面和深入的理解，然后将这些抽象的规则转化为可执行的指令。这一过程依赖于业务和技术部门的紧密合作，是一项逻辑严密、步骤繁复的工程。

从业务的角度来看，不仅仅需要业务人员表达一个想法，还需要明确业务目标，准确划定业务范围、流程及规则。这需要业务人员对自身的流程、产品和服务有深刻的理解，并能够精准地定义业务规则。例如，当业务部门希望引入维修服务时，需要明确维修的商品范围、流程步骤、收费标准以及相关规则，这种清晰的需求描述是IT部门可以有效开展工作的前提。

从技术的角度来看，首先需要对业务需求进行全面理解，并将其拆解为可执行的技术方案。这不仅是一次对业务规则的梳理过程，也是对业务与技术之间逻辑关系的精准把握。业务规则往往相互关联，并与现有流程紧密相连，因此，技术团队必须从全局角度出发，协同业务部门细化流程，确保每个环节都能被系统准确执行。其次，技术团队需要将这些业务规则转化为编程语言，这一过程中会面临一系列挑战，如何选择适合的编程模型来表达规则、如何避免冗余代码等问题。

需求到编码：从现实世界到计算机世界

我们用一个案例“电商部门提出要对接小红书平台卖货”来描述这一工程过程，即从需求到编程的主要环节。

1、需求到流程规则

某日，电商部门提出这样一个需求“要增加小红书这个新的渠道”。看似就相应增加一个线上渠道的简单需求，却并不简单。不同渠道业务模式各有不同，商品、库存、订单、售后等的处理流程也各有不同，完全新建系统会存在重复建设和资源浪费，融入已有系统需要考虑全面兼容和数据对接，更重要的是需要全面梳理业务流程和规则，实现这样一个需求完全是一项大工程，有时甚至不会比新建一个系统要简单。

IT部门要和电商部门一起全面梳理这项需求，而且为了能让此需求实现，流程通畅，不仅仅是考虑电商部门内部流程和规则，还往往需要跨出电商部门，从整体出发，把涉及到的各相关方（例如商品、仓库、物流、财务等）都纳入进来，全盘思考铺货管理、库存管理、订单履约、售后处理、财务结算，库存从哪里来？从哪些仓库发货？上架商品的规则、商品怎么分类、商品怎么上架到小红书去、上架后是否允许线上线下卖货？卖货的话是直销还是代销、怎么发货、怎么结算？等等。

IT部门需要和电商部门一起将整体需求一层一层的拆解下去，并配套一系列流程，在什么环节、由哪些岗位，分别完成哪些任务，先后顺序如何，流程规则如何，需求拆解和流程设计配套进行，最终IT部门要整理一整套流程和业务规则，然后形成流程图和需求文档，同业务部门及相关方多次沟通，业务部门根据沟通结果再去调整，IT部门再修改和完善相关文档，反复几次之后最终确认整套流程和业务规则。有了完整的流程与规则，IT部门再据此去推进研发落地。

渠道对接主要工作内容概览

2、规则的约束条件

业务规则：每个流程环节有什么要求和约束条件，各项都需要展开细化，比如低价商品限制不允许O2O发货；不同品类需要限制不同的安全库存；仓库发货有明确的面单格式及快递要求；财务结算需要有明确的计价分摊规则，等等。

沿着最新的流程图，需要全面检查到每一个岗位的每一条规则，充分思考到新的规则会对原来的规则产生的影响，尤其是规则之间的互斥，表现在对各类关键业务数据的操作上。IT部门要模拟业务开展的过程，通过编写测试用例等方式来仿真未来真实的业务流执行，及早发现问题。

3、流程规则到编码

IT部门从需求的最小单位“规则”出发，把一个个业务规则用一段段代码来编程实现，再通过连接一段段代码去实现一个个业务流程，进而继续整合去实现业务需求。

1）整体架构设计

经过和业务的多轮协同后，产品经理完成需求分析和功能设计，并形成规范的需求设计说明书文档，其中包含了业务对象的定义，需要建设或者更新的业务流程，未来的业务使用界面功能和业务场景。接下来，需要架构师基于对业务需求的理解设计整体工程建设蓝图。架构师是同时具备业务理解和系统架构思维的关键角色，是业务到技术的关键桥梁，架构师会把业务需求文档转变为IT领域的系列架构设计文档，去细化哪些系统需要对接、数据在哪些系统之间流转、各系统之间用什么方式对接、是否需要大数据计算、是否需要模型算法等；并考虑到未来业务数据量、使用频繁度等未来的增量，来设计选用什么样的技术组件、网络架构等等。

2）前端交互设计

产品经理通过草图、线框图、高保真原型图等同业务确认他们期望的风格、交互的方式。通过多轮静态的演示，或者动态Demo效果的互动演示，来表达系统未来可以呈现的效果，也就是未来用户进行操作的界面效果。然后交给设计师进行美工设计，美工设计完后提交给前端开发工程师，进行前端页面的开发。前端工程师同时还要与后端工程师沟通前端页面与后端的数据交互逻辑。

3）后端逻辑开发

对于电商部门提出的需求“要增加小红书这个新的渠道”，渠道的打通是为了扩大销售，这里我们以“新渠道需求”之下的“订单流程”之下的“订单金额”规则为例，选出百余项订单规则中的一项规则“订单总金额超过100元，享受10%的折扣”来举例说明，如何把“业务规则”转化为“计算机编码”。

规则到编码：业务规则与编程逻辑一一对应

第一步：从全局视角，找出“业务规则”背后的“隐藏规则”：

例如：制定订单金额规则“订单总金额超过100元，享受10%的折扣”时，需要兼容考虑订单合法性规则和特殊订单金额规则，所以我们把规则拆解到以下4条细则：

订单总金额超过100元，享受10%的折扣。（常规订单金额规则）
订单必须至少包含一项商品。（隐藏规则：订单合法性规则）
订单的总金额不能为负数。（隐藏规则：订单合法性规则）
如果订单中有特殊商品(如“特价商品”)，则享受额外5%的折扣。（隐藏规则：特殊订单金额规则）

业务规则的完整性、清晰度和内在一致性，对系统是否能满足业务需要起到关键作用。因此，某一个细分的业务规则一旦有变动，IT人员需要重新“编译”并验证其与所有相关的规则的联动关系，一一重新走过上述所有过程才能实现系统程序的对应调整。错综复杂的业务规则，一再调整的业务规则，这些都会使得系统的条件判断越来越多，相应界面上的配置也越来越多，通过跳转实现条件区分的组合也会越来越多，于是入口会越来越深，操作难度随之增加。

第二步：补全隐藏规则后的每一个“业务规则”逐个翻译为“编码实现”：

为了便于企业管理者和业务需求方理解IT工程化的过程，我们需要开启架构师视野，创新性地把业务规则和编程规则进行一一对应。我们首先需要思考并抽象出：如何定义一条业务规则，它的结构是什么？如何定义一条编程规则，它的结构又是什么？二者是否能够一一对应？

我们试着抽象出规则三要素：【业务实体】 + 【实体特征】+ 【条件+操作】。

【业务实体】指业务过程中的关键的人、事、物、地、表、证、单、书。例如在业务过程中，关键的“人（用户、员工、伙伴等）、事（订单处理、客户服务、物流配送等）、物（产品、设备、资源等）、地（商城、门店、仓库、机构等）、表（订单表、申请表、销售报表等）、证（证件、发票、合同等）、单（销售订单、采购订单、送货单、出库单等）、书（合同、用户手册、年度报告等）”是构成业务活动的重要元素。这些元素共同作用，确保业务流程的顺利进行和目标的实现。

【实体特征】在业务过程中，实体具有的特性。这些特征对于理解和管理业务流程至关重要，可以帮助企业更好地组织和优化业务活动。

【条件+操作】：即某一种/多种条件下的操作，包括增加，删除，修改，查看，排序，数学计算，循环，输入输出等。

同理我们设计出编程三要素去对应规则三要素：

例如在面向对象高级编程语言Java中，设计出“类（Class）”去描述一组具有相同特征和操作行为的业务实体，从而实现编码的抽象性和共享性。实际编码时，会使用类来生成一个具体的对象实例（专业术语：类实例化），此对象拥有这个类中定义的所有能力（对象的属性（数据）和方法（行为）），在这个能力之上去编写业务逻辑。比如我们把“汽车”定义为一个类，它具备品牌、颜色、速度等这些属性以及启动、加速、刹车等这些行为，当我们需要一个具体的汽车时，我们会描述这个车的具体信息，比如品牌是特斯拉，颜色是红色，最高时速是300公里/小时，这就是一个对象实例化的过程，我们通过“汽车”类来创建这个实例，还具有启动、加速、刹车这些“汽车”类中定义的行为。

所有编程三要素都要和规则三要素建立一一对应关系，编写程序并全部连接在一起，才能在计算机世界实现业务运营的过程。

此章节描述的是一个需求到编码的过程，目的是让业务人员理解这个过程的全貌，业务一句话的需求，对IT来说就是一次工程建设，如果业务改变规则提出需求时，IT可以直接修改源编码，但保证不了系统的稳定性，因为需要梳理新规则是否与原来规则互斥等合理性，避免系统无法运行。需求的梳理过程需要时间，因此业务感觉“需求响应慢”。同时，业务的每一次需求，首先需要投入业务人员进行梳理，然后技术人员一起进行梳理和建设，站在企业的经营角度，这些都是投资。从规则制定到规则改变，都会增加成本，业务人员就要评估改变后带来的效益与改变消耗的成本之间的差距，而往往业务人员只注重前端业务的改变结果，忽略了成本投入和系统改变的时间要求。

三、规模与断点

随着企业的持续壮大和业务多元化，内部的部门、员工、客户、流程、规则等要素的数量随之增加，而这些要素之间的交互和组合也呈指数级增长。各类业务元素之间的联系并非线性增加，而是以更高阶的形式成倍扩展。尤其当多个要素的规模同时增长时，企业所需管理的交互关系变得更加复杂，协调难度也随之提高。这种规模效应带来的影响不仅体现在业务流程的复杂化，还常常伴随着各业务元素之间关系的复杂化，都会进一步波及到规则的制定和执行。业务规则的增加使得系统的配置变得更加繁琐，而配置的繁琐性则直接影响到操作的难度和出错的可能性。同时，规模扩展导致业务协同需求增加，跨部门、跨系统的沟通协调变得更加频繁。信息传递的不对称、沟通过程中的延迟等问题，直接影响到企业的运营效率，甚至会导致资源浪费和管理混乱。业务规模越大，组织越复杂，对系统的要求就越来越高。

企业规模增长带来的复杂性与运营困境

伴随规模效应的另一现象是岗位专业化的进一步细化。为了应对日益复杂的业务需求，企业引入了更多的IT系统来支撑其运营，每个职能部门都会有相应的系统来承载其工作。信息化建设从早期的单一系统逐步演进为“单点+关系”的多系统架构，这在提升企业运作效率的同时，也带来了新的挑战。举例来说，一家初创企业在早期或许只需一套简单的ERP系统来管理业务，但随着规模扩大，它可能需要更多的系统，如CRM（客户关系管理）、SCM（供应链管理）、BI（商业智能）等来支持不同的业务需求。这些系统的建设往往是围绕各自部门的需求展开，从用户角色、岗位设置、业务流程到数据处理、安全机制等，都是以“单点”进行的功能开发和部署。“单点+关系”的多系统结构虽然能够满足单一部门的需求，但在跨组织协作时，由于单点的建设造成了“断点”的存在，常常带来操作复杂化、沟通不畅以及易出差错等问题。

随着企业规模的扩大，管理层逐渐远离一线操作，信息的传递与反馈链条变长，达成共识和进行跨组织协同的难度也随之增加。规模化带来的好处逐渐被其带来的管理挑战所消耗，导致信息化建设陷入规模化的瓶颈。如零售行业，在某个城市要新开一家店，总部和地区的相关部门要审批、工程队要装修、人事部要招聘、商品部和零售部要备货等等，涉及从总部到地区4大业务环节、10多个业务单位，30多个岗位，100多个业务事项，20多个产品/系统，存在多业务单位之间的沟通与协作，其中涉及3个及以上业务单位的事项超过20个。

新开店业务流程梳理

这具体表现为以下三大痛点：

第一，流程断点。新开店整个业务过程跨越了多个部门，大量的跨业务单元之间的沟通与协作都是靠人与人之间的连接，连接方式基本是单线的，如邮件、电话、微信、会议等。但事务多、过程变化多，一般是由业务人员将数据手工录入到系统，容易出现录入错误、录入延迟等情况，造成各系统之间的信息不一致，例如：开店日期、装修面积等。

第二，有结果无过程。流程断点处的衔接是靠组织，系统只是记录业务流的节点，过程缺乏数据记录，当出现系统之间的数据不一致时，经常是由组织协商完成的，最后发生问题时，很难回溯出问题的环节，形成盲点。这种“有结果无过程”的现象，还使得管理者无法通过过程数据来检验结果的一致性，影响了运营效率。例如，在开店装修过程中，装修设计图纸与现场装修不符，工程队会根据实际情况修改，修改过程和设计图纸之间的差异到底是何原因没有记录，只有当事人才清楚。

第三，协同难。如此多的系统断点和部门“墙”，即使随时开会沟通、做表统计跟进，还是容易出现信息不对称等带来的种种问题。上下游协作的任务链条长，依赖于组织内部的沟通效率；不同系统之间的数据标准和格式不统一，形成了一个个“信息孤岛”；而组织之间的立场冲突和信息不对称进一步加剧了协同的难度。例如：活动策划和备货没有对接好；系统内店铺的参数配置中地址的问题导致备货的收发货问题等。

新开店业务流程系统断点、有结果无过程、跨组织数据/信息未共享

信息化系统的建设，是以满足部门内的流程为主体，提高部门内部的运营效率为目标逐步建设出来的。随着企业与外部接轨越来越多，内部连通成一体化运营的要求相应越来越强，数据之间的流动也会越来越多，因此数据不一致性导致的割裂将影响企业整体对外的竞争力。

信息化是企业活动在计算机世界的建模，是一个基建的工程，就是从业务需求到编码，在计算机中形成“0与1”的过程。当业务提出新需求，经过管理、运营、IT相关方共同评估并确认立项后，要么新建工程，要么改造工程，新建是从零到一的设计和建设，改造是工程之上的工程，都是企业为了业务机会而向一次复杂的工程化建设买单。新的系统建成后，需要经历时间去完成业务运行论证，并不断迭代优化，才能最终实现业务最初提出的需求；同时，在系统的变化后，还要进行相关的数据处理，如果历史数据较多，数据处理的过程也同样复杂，用新的业务逻辑对齐所有的历史数据更是一项大的系统化工程；如果新的需求影响了更多部门的业务，就需要调整更多的部门级规则、建立更多的部门间的连接，因此更多的系统与数据都需要相应建设或调整，然而始终不能有效解决系统断点的影响。当承接业务的系统越来越多时，业务组织架构任何一次变化，系统与数据的工程性调整都需要完整历经一遍，其工程体量就如同一次系统大换血，波及影响到每一个部门、每一个人、每一份代码、每一张表、甚至每一行数据，企业综合成本倍增。因此，任何一个需求的确定，都需要与相关组织和部门之间达成统一业务语言和业务规则，每一个规则背后都是企业的一次投资决策和资源排布。