5月底的时候，跟一个从事信息化工作的朋友交流，他所在的公司人数超过了1.2万人，占去了所属行业国内30%以上的份额。2021年以来，公司明确数字化将会是公司下一阶段的重要战略之一。公司有着150人左右的信息化团队（这位朋友负责的团队人数约50人）面对这样的战略决定喜忧参半，动力和压力并进。
我们针对企业进行信息化落地工作中的种种难题展开讨论。讨论过程中发现很多问题恰恰是具备一定信息化规模的企业才会有切身的体会，而这些问题也普遍存在于大部分的“大公司”中。
难题一：核心系统运维难
该公司的系统是2015年开始设计，在2017年正式上线使用。5年的时间对于一个核心系统的生命周期来说并不算长，但是却疲态惊现，老迈地走不动路了。
由于各种原因，团队人员构成已经产生了很大的变化，最开始负责开发的同事已经不在了。项目初期的文档维护不规范导致老旧逻辑缺失，难以澄清。新的团队往往需要花费倍数的人力才能上手工作，团队的排错和修复工作都需要花费成倍的人力。
然而核心系统的稳定性往往牵扯到核心业务的正常运作，一个再小的错误都会直接导致不同程度的业务损失。所有的稳定性背后都是成本的投入，为了能够保障这种程度的稳定性，一个大型的信息化团队对于已有产品的维护和质量保障投入往往占去了超过50%的研发资源，这个数字随着核心系统的复杂度提升而不断攀升。
令人唏嘘的是，稳定性所带来的“业务损失”并没有减少，而是以“IT成本”的形式出现在了财报中。
难题二：信息化协作链路长，响应糟糕
大公司的“大”首先体现在复杂庞大的组织架构上。该公司超过1.2万人，共有5家分公司以及分散在全国各地40家左右的实验室的。为了服务这1.2万人进行协作和管理，公司组建了150多人的信息化团队；而为了维护这样规模的团队，每年公司需要支付总计数千万的各项成本，堪比一个小型企业全年的营收。这样级别的投入对于大部分公司来说都是难以想象的。
中心化的IT信息化团队在企业内扮演了乙方的角色，承接各个子公司、业务部门的信息化需求。在资源有限的情况下往往出现互相挤占以及排队现象，往往一个非常小的功能需求排期就动辄数月的等待周期。不仅是排不上队，即便排上队伍了，落地质量也差强人意。庞大的组织架构弱化了部门与部门之间的联系，中心化的IT团队离业务一线越来越远，使得甲乙双方有着巨大的信息差和理解差，这种差距直接导致了最终需求的落地效果差甚至无法落地。
这些问题在这家公司的集中暴露并不是偶然，在大企业中属于普遍现象。大企业的信息化陷入了一个怪圈：“投入越来越多，效果却越来越差”。信息化的“大公司病”就像房间里的大象显而易见却又难以改变，所有人都默默的承担着，然后继续负重前行。
“甲乙方”式的协同存在的弊端
生产资料的稀缺性以及生产工具的使用壁垒导致了甲乙方的协作模式。这个基本原理在“信息化”领域同样生效。我们发现正是这种“甲乙方”的信息化协作方式的弊端，造成上述的种种乱象。
弊端一：甲乙双方对于需求的理解有断层差距
软件开发是一项具备高度专业性的工作，其包含了两项重要“任务”：
任务一：将抽象的业务需求设计为可操作的系统功能；
任务二：通过代码将任务一的系统设计进行实现；
在过去我们非常关注“任务二”的专业度却忽略了“任务一”中软件的业务逻辑设计同样具备专业性。大部分的IT开发者并不缺乏coding能力的专业度，但是缺乏对于业务需求/痛点的深度理解。大型企业的组织架构和业务流程往往庞大且复杂，大部分的IT开发者都距离业务一线非常遥远，而业务问题同时具备广度和深度，非实际经历很难有切身体会。
IT开发者能够意识到“需求理解”的重要性，但在大量的开发排期面前往往却有心无力。这种差距导致甲乙方的服务落地质量得不到保障。服务满意度较低。这种牺牲“开发质量”而追求“开发数量”的做法并不可取，但身处其中的IT开发者其中并没有能力扭转局势。
弊端二：甲乙方的中心化协同缺乏响应业务变化的灵活度
VUCA时代，企业业务变化的周期被大大缩短。对于信息化工作的灵活度有了更高的要求，超过59%的中国IT开发者认同其企业的软件开发速度需要加快。
然而甲乙方的协作模式下，企业内所有的业务系统需求，都通过一个庞大的信息化中心来完成，一个标准的研发流程包含需求梳理、方案设计、落地研发、质量测试、版本发布等等环节，每个环节都是专人执行。项目参与人数越多，协作难度越大。过程中的信息损耗、效率低下问题也是反复出现。各个业务部门对于中心化的排期资源抢占也变成了一种企业内的负和博弈，增加了不必要的成本支出。
这一切都使得响应周期过长，系统还未开发就变成了“过期产品”。这些都大大提升了信息化投资的风险，企业每年投入大量的资金进行信息化投资，大部分都处于无法明确收益比的情况。这也难怪大部分的企业主想做信息化但又不敢做。
面对这个现状，我们需要做出改变。
做出改变：从“甲乙方”到“圆桌式”
圆桌十二骑士的故事深入人心。传说中不列颠君王亚瑟（Arthur）所领导了这样一群优秀的骑士，骑士们在战场上冲锋陷阵，在圆桌上议论国内事务。近代以来，圆桌形式的会议屡屡在关键的历史节点中发挥作用，大大的加速了相关历史事件的节点进程。
“圆桌式”代表着平等的对话、密集的信息交互、各司其职的配合，即模糊了“甲乙方”的边界，也模糊了“生产者”和“使用者”的边界。回顾历史，我们可以看到各个领域的技术普及都是一场场的去“甲乙方”的革命。
从专业媒体到自媒体（模糊了内容消费者和内容生产者的边界）；
从专业视频到短视频（模糊了视频消费者和视频生产者的边界）；
……
技术和工具的门槛降低，使得使用者有能力参与到生产过程中，从而指数级地提升整体的生产力。
我们欣喜地看到，源于“无代码系统搭建平台”的易用性和低门槛，“轻流”正在实现业务人员参与到信息化系统开发的历史性转变。越来越多的业务人员通过短暂快速的上手学习，完成了自身业务的数字化转型。通过应用软件技术的门槛降低，一种新的人才类型正在越来越多地出现在企业中，Gartner称之为“业务技术人员”。随着“业务技术人员”的出现，企业信息化的深度参与角色变得越来越多元，我们发现IT与非IT的之间的边界正在变得模糊。
不管是系统使用者还是专业开发者，都可以通过各自趁手的工具来发挥自身的优势在一个圆桌上密切协同高效敏捷地完成应用系统落地工作，这就是我们所倡导的——“圆桌式开发”协同方式，该方式让各种角色有能力在一个圆桌上通过高度协同、各司其职共同完成系统落地。
文源：轻流联合创始人&CPO严琦东，内容有删减。
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
