引言：

为了应对激烈的市场竞争，企业需要在管理成本可控的情况下对业务的管理做到尽可能的精细化、个性化。而这些精细化的管理理念如何传递到业务人员，尤其是前端销售人员，从而让管理细节能够有效的执行？这一直是企业管理的难点，一旦管理诉求传递不当，会给企业带来比较大的影响。

例如某企业与供应商合同约定在其上海地区的门店是不允许进行某品牌产品销售的，然而这个管理诉求却没有及时下达到配送中心及相应门店，导致该品牌产品最终通过门店要货、配送中心配送渠道一路畅通地出现在了该地区门店的陈列架上。由此而引发的与供应商纠纷、以及商品退回的逆向物流成本等都给企业带来了比较大的损失。

如果对企业的管理仅靠各个部门之间的沟通，那么带来的沟通成本会过高，而且很可能因人为因素而导致指令无法执行，因此企业一般会借助信息化系统来实现部分规则明确的业务管理需求。但系统管理的越是细化，维护也越复杂，维护的难度、后续问题排查的难度也就越会增加。

为此，海鼎结合企业的业务管理诉求，开发了业务状态功能，将各个业务管理的细节控制集中在业务状态功能中，同时又从商品、门店商品、门店等多个维度进行全生命周期控制。从而，既能够满足企业精细化的管理需求，又能够降低业务人员的维护难度。

一 业务状态理念的应用

随着企业信息化的发展，通过信息系统来管理的业务越来越丰富，对应的系统业务单据类型也越多，目前已达数十甚至上百种。如果管理精细化到每一种业务都需要进行控制，那么就意味着每一个商品或每一个门店就需要面对数十种开关，如果再需要管理到门店商品级别，那么这个数量就更是庞大到难以估量。因此，我们需要探索一种合理的应用方法，既利于理解和执行，又能够精确有效地管控业务操作。

（一） 商品生命周期与业务控制关系

我们在实际的业务中会发现，当商品或门店处于不同的生命周期时，其对应的业务控制往往是有关联的，如当某商品需要淘汰时，我们会停止该商品的采购、配货业务，准备将商品都退回供应商。以常见的商品生命周期业务控制关系为例，如表1所示。

表1 商品生命周期与业务开关对应关系

（二） 业务状态定义

从表中可以看到，生命周期与业务控制有关联关系，但是同一个生命周期可能因多种业务场景的原因，对应多种控制关系，为此我们引入业务状态的概念。

业务状态指对有关联的业务开关进行总结归纳后形成多种业务开关配置的集合。定义了业务状态后，当企业管理较为简单时，可将生命周期的管理与系统中业务状态的控制严格对应，而当业务场景比较多时，生命周期与系统的业务状态可以形成多对多的关系，从生命周期维度进行管理分析，从业务状态维度进行业务控制，如表2所示。

表2 商品生命周期与业务状态对应关系

（三） 业务状态与业务控制关系

业务状态定义完成后，再从不同的维度去引用对应的状态，可实现多维度的业务控制，其对应关系如图1所示。

此时，业务人员需要面对的就不再是数量级庞大的业务开关，而是若干已经归纳好的业务状态。当排查问题时，也不再需要检核数十个业务开关，而只需要检查各个维度对应的业务状态一项即可。

图1 业务状态对应关系

二 各维度业务状态的控制关系

前文中提到，我们会在不同的维度去引用业务状态，而业务状态对应的业务开关其实可能是相重叠的，那么不同维度之间的业务开关之间应当是怎么一个控制关系呢？

我们先来看一下现实中的一些业务场景：

当一个门店需要进行装修，配送中心在装修期间内不应该再给这个门店配货，我们应如何限制？是限制门店维度不能配货还是限制该门店商品维度所有商品都不能配货呢？

当一个正常的商品需要逐渐退出某个区域，因此要控制这个区域所有门店都不能对该商品要货，这又要如何进行限制？

对于第一个业务场景，我们应当满足以下业务管理要求：

1）    当门店在进行装修之前，门店的商品其实可能有多个状态，例如某些商品可能禁止了销售，有些商品禁止了要货；

2）    当门店进行装修时，这些门店的商品所有业务包括销售、配货等都会禁止；

3）    当门店装修完成以后，我们要恢复原来的状态，也就意味着原来禁止销售的，那么现在仍禁止销售，禁止要货的，仍禁止要货。

这就表明，门店状态与门店商品状态之间，应当都能够独立进行维护，且进行实际业务控制时，应当体现交集关系。也就是说，如果要想进行某业务，那么需要保证所有维度该业务都是开启的才能够进行。以是否允许要货的控制为例，具体关系如图2所示。

这样的控制关系能够保证各个维度之间的状态是独立的，当需要调整某个维度的状态时，不会对其他产生影响。但是值得注意的是，当某业务需要从禁止调整为允许时，应该保证所有的维度的状态都为允许状态。

此时我们再来看第二个场景，当我们需要控制某些门店某些商品不允许要货，只需要从门店商品维度进行控制即可。

图2 要货范围控制关系

三 业务状态的系统实现

海鼎在对业务状态的设计过程中，考虑了不同企业间的灵活性以及客户操作的便利性，在系统中的具体实现包括以下步骤。

图3 业务状态实现步骤

1 单据管理范围配置——满足不同企业管理需求

不同的企业其管理精度不同，能够管理的业务范围也有限，而系统可管理的业务单据有数十上百项，如果企业未达到这种管理精度而系统却要求必须都维护的话，反而对企业的管理造成负担。因此我们系统后台允许配置不同的业务范围，使得该功能能够贴合不同企业的需求。

2 业务状态设置——系统推荐状态与客户自定义相结合

如果企业在初期没有业务状态的管理概念，需要自己去定义不同维度的业务状态会比较困难。

因此海鼎根据企业的常见业务场景进行总结分析，从商品及门店两个维度给出了推荐的业务状态（如表3、表4所示），这些状态能够涵盖企业基本的管理需求。例如：商品状态中的“禁采”通常用在该商品与供应商暂停合作时；“禁采禁配”通常用在商品需要进行淘汰时。

表3 推荐商品状态

表4 推荐门店状态

企业在应用初期，采用系统推荐的业务状态即可，随着企业管理的发展，可再采用自定义的方式去定义一些满足企业个性化需求的商品状态或门店状态。

3 各维度业务状态维护——批量操作提升维护效率

业务状态定义后，需要在各个维度进行引用，为保证操作的效率，系统支持手动维护与批量操作等多种维护方式，如图4所示。

图4 批量设置门店商品状态操作示意

4 状态查看——最终结果展示清晰

在多个维度维护完状态以后，实际的控制结果到底如何，系统提供了可查看的界面，如图5所示。通过该界面业务人员可快速确认业务控制的结果。

图5 业务状态结果查看示意

小结

业务状态的管理思路，与生命周期管理相结合，解决了以前业务开关过多且界面分散的困扰，明察秋毫而又不冗杂繁琐，为企业的管理精细化铺平了道路，在多家海鼎客户企业中应用获得良好效果。另外业务状态可以和企业的陈列软件等相结合，使得控制的层次更丰富更精准。海鼎将在后续对相关功能持续优化，助力企业管理的飞跃发展。