是系统满足管理需求，还是管理适应信息系统？

    企业数字化转型建设之所以失败，技术与业务的融合是关键，但融合的基础是共识，在共识达成之前我们总会遇到这样的问题：是系统满足管理需求，还是管理要适应信息系统？

   信息部门在日常工作中经常遇到这样的场景：

   “这个软件的功能不适应我们业务部门当前的管理现状”，哪怕软件是企业斥巨资购买的一线大厂的产品。

   当业务部门提出这样的疑异的时候，可能就意味着软件的实施应用工作不会一帆风顺，有可能会烂尾，于是信息部门可能会做出两种选择：

    第一，与业务部门沟通，收集需求，对软件进行二次开发，以满足业务部门的当前需求；

    第二，说服业务部门做出改变与让步，因为在信息部门或软件公司心中认为大厂的产品集行业内最佳管理实践，如果业务部门用不起来，那一定是业务部门管理有问题，需提升与改善。

    有人会问老杨，这是购买标准软件的常见问题，如果订制开发的信息系统是不是适配性更强，不会出现以上问题呢？

    老杨要说的是：未必！即使订制开发的系统在应用方面依然会存在各种问题，说个真实的案例：

    某公司新的产业板块刚刚成立，部门不完整、各种管理制度不健全、管理人员也缺乏新产业板块的管理经验，但为了降低管理风险，在当时相关管理部门认为需求很明确的情况下让信息部门订制开发了一套ERP系统，但是系统在上线应用后业务部门认为系统管理的逻辑过于规范、严谨，不符合当前的业务场景，需将各种限制条件放开，例如，系统要求入库操作必须有前置审批，如无审批将无法办理商品入库，但业务部门提出的修改理由是大量历史的过程资料很乱，短时间难以清理补流程，现在必须将前置审批限制放开，先入库再说，另外各种审批流程还需再进一步调整.........如此一番要求提下来，几乎将原有管理框架全部推翻，系统有重构的风险。

    那么在这种情况下，信息部门改还是不改？

    如拒绝修改，不能满足当前业务场景需求，业务部门会以系统不好用为由拒绝使用；

    如果修改系统功能，就意味着改动系统业务框架，前期的开发成果、投入、付出将付诸东流，在业务场景如此多变、需求高度不确定的情况下信息部门大量人力、物力、极有可能陷入该项目中，致使信息部门对本项目鸡肋感满满。

    做数字化转型建设，最怕的就是遇到这种初建公司业务场景：

    一方面公司有信息化的需求，对信息化充满期待，希望借助信息系统提高工作效率、改善管理；

    而另一方面业务场景多变、需求不明、流程不清、人员职责混乱，难以形成体系化的管理、标准化的业务场景；所以这个时候是系统适应当前管理，还是管理适应信息系统的矛盾就出现了。

    怎么办？

    如何解决？

这个时候大部分的企业无一例外的出现以下场景：

    相互甩锅！

    相互指责！

    业务部门认为信息部门必须配合修改完善产品，以满足业务需求；

    信息部门认为系统是按需求开发的，软件没有问题，业务部门必须先将当前产品应用起来再修改；

信息部门与业务部门认为自己都没错！

    然后陷入无休止的争论...............

    对于以上场景问题，其实在项目立项之初就已注定如此的结果，只是信息部门与业务部门双方一开始未对项目的应用风险做充分的评估，在各自的立场上信心满满，信息部门认为需求已经过充分的调研与确认，不会有问题；而业务部门认为自己的管理模式没有问题，不会修改；结果这种理论模式的需求与管理遇到真实的业务场景时被啪啪打脸，业务在发展，部门在完善，流程在调整，职责在细分，当动态不稳定的场景遇到固化的信息系统功能时，一切都显得那么格格不入，怎么办？

    只能提出修改！再修改！再次修改！

    进入持久的系统修改拉锯战。

这个时候有人会问，以上问题又该如何杜绝？

    老杨认为造成以上问题的主要原因还是在于前期的项目规划：信息部门对于系统的建设规划、业务部门对于业务的运营规划，当二者之间未达成信息系统建设共识，有一方能力欠缺时，各种问题会纷至沓来。

    首先来谈一下信息部门的信息系统建设规划：

    在企业数字化转型建设过程中，业务部门总是想一步到位，想短时间内实现所有的业务功能，同时又缺乏成本意识，认为信息部门的技术人员是自己人，开发任何系统都不要费用，不会产生成本，所以在信息系统建设过程中随意性很强，而信息部门面对业务部门的需求，很容易进入技术的陷阱，认为只有做大而全的系统才能体现其技术价值，往往忽略了业务部门对于信息系统的承载能力，特别是忽略了对于新成立业务板块的各种不稳定因素，在大量的需求面前、在大系统平台 面前迷失对项目应用风险的判断，盲目进行大项目、大平台的建设，把想象中自认为正确的业务场景功能全部建设出来，不以现实场景进行的任何信息系统建设，结果是可想而知，规模有多大，失败的风险就有多大。

    所以在业务场景未完全成熟的情况下，信息部门不宜进行大规模全模块的系统建设，应与业务部门充分沟通，提出可预见的各种风险，同时向业务部门提交系统建设所需要的建设成本、二开成本、维护成本。在系统建设策略上可先期进行系统框架规划，模块分步建设的策略，将最紧急的模块建设出来，同时做好未来的数据接口，然后逐步迭代、模块打通。

    而对于业务部门而言，内部的经营管理体系完善建设工作十分重要，业务部门相关领导要清楚的是多变的业务场景、组织、管理模式遇到标准化的信息系统是难以融合的，所以应提前规划好公司的业务模式、同时要具有技术思维，用信息系统的思维模式逐步进行业务场景标准化建设，不要总想一步到位，步步严谨，业务在变动、管理在完善，因此信息系统的管理功能也是一个由粗放到精细的过程。

    所以在企业数字化转型建设过程中技术与业务要达成共识，要融合思维，不存在谁适应谁，否则就会进入无休止的争论、扯皮之中。双方都要具有规划能力、成本思维、风险意识，勿贪大、勿求全、勿求完美。