那场顺利通过的评审会

新系统刚上线，业务人员就纷纷吐槽：这不是我们要的。

场面算不上激烈。说到底，他们原本就没系统，新的不好用，大不了先搁着、照样干活。这种事，哪家企业没碰上过几回。

真正让人啼笑皆非的，是后来有人翻出了当时提交的需求和评审记录——如今被吐槽的这些地方，需求里根本就没提过。

接下来的剧情，熟得能背下来：业务说软件公司做得不行，软件公司说业务当初没讲清楚，最后绕一圈，又怪数字化管理部门没统筹好。谁都有理，谁都不认。

可记录摆在那儿：这套被吐槽的系统，就是完完全全按评审会上定下的那一版需求做的。

评审会通过得越顺利，返工时翻起旧账来，就越难看。

问题不在谁错了

碰到这种事，人的第一反应往往是分清谁对谁错。

可真掰扯起来，往往不了了之——业务确实没把需求讲清楚，可软件公司也没把需求调研清楚，大家又都不是故意的。

企业里这种事，很少真去追责，因为追不出结果，也没有意义。

值得较真的不是“谁错了”，而是“哪儿错了”“以后如何避免”。

掰开来看，歪的往往不是执行，而是源头那份需求本身。

需求的几种错法

那份需求，是怎么写歪的？

我这些年看了不少企业的需求文档，歪法有套路，一层套一层。

第一种，需求是篇小作文。

通篇是“我们部门要什么功能”，写得粗，每个人读出来的意思还不一样。

可就是这么一篇东西，转头就拿去招标了——供应商看着它，其实只能猜着报，没准一不小心就中标了呢。

把功能当需求，就像去医院看病时不说症状，直接要求医生开药——药吃了，病没好。

第二种，调研只是纯写实。

供应商来调研，看业务现在怎么跑，就怎么记。

可被调研的每个人，对业务的理解本来就不一样，调研出来的结果，跟当初那篇小作文自然大相径庭。

而且，现在这套业务做法，本身未必就是最优解——原样搬到系统中，等于把不合理也一起固化了。

需求没说清，调研抄现状——抄得再工整，也只是旧账。

第三种，也是最要命的一种，目标本身就立错了。

上系统，图的是什么？

这里得说句公道话：有些系统，本来就是奔着留痕去的——合规要查、过程要追，那做成留痕，天经地义，没毛病。

可大部分业务系统不是。按数字化转型的路子，它该借这次上线，把业务顺手优化一遍，甚至重构一遍。

错位就出在这儿：本该奔着优化去的业务，最后只做到了把线下原样搬上线、留下痕迹。

结果线下原来能商量着办的事，线上全部卡死了，每一步都要按照标准流程去做，导致业务效率急剧下降。

于是大家对着已上线的这一版，开始动脑筋改，改出二期——二期往往是对一期的大量推翻重来，一轮一轮，改到自己满意为止。

时间搭进去了，钱也搭进去了。

问题不在留痕，在该优化的没优化——本来是搬家的活儿，结果干成了装修。

 

这类问题，我是怎么解决的

前一段时间，一家企业找到我们。他们上马的所有信息系统，几乎都卡在这个死循环里：上线→不好用→推翻→再上线。

核心的症结，就是需求想不明白，说不清楚。

企业的领导认识到，企业架构是个治本的方法，请我们进场，辅导他们把企业架构真正建起来。

我们带着企业的项目团队做出一整套基线文件——把家底盘清：

先出完整的业务能力地图。

往后每次上新系统，先对一对：这次要上的，是业务能力地图中的哪几个能力？不在地图里的，算不算公司该有的正常能力？先把“该不该做”问清楚，再谈“怎么做”。

再把业务流程全部铺开描述。

现状已经摆在那儿了，每一轮需求都要回答：这一步是原样的业务流程上线，还是哪些流程步骤上、哪些不上、哪些要借着这次上线的机会先优化一轮？

流程理清了，再往下落：流程和流程之间的接口是什么、流的是什么数据；这些映射到应用功能架构，对应哪些模块和功能；流程接口映射到应用集成架构，明确系统和系统之间怎么连接。

走下来，这家企业如今已经建立了一整套标准化的需求描述方式——从业务架构，到应用架构、数据架构，再到技术架构。

任何一个部门提的数字化需求，都得先把这四个架构做出来，并分别过审。

四个架构做完了，才进入采购招标流程。

这套打法，是通过企业架构让需求落地。

效果是这么慢慢显出来的：

业务部门再不能写一篇小作文就去立项了——得认真做业务架构，还得过运营管理部门的审。

需求从一篇小作文，变成了一整套标准化文档，质量自然高了一大截。

供应商拿到四个架构去投标、去开发，要做的、要连的，基本上都已经明明白白。

做架构的过程是繁琐的，前面要多花些功夫，可后面的返工，也少了太多太多——以前是上线了才发现不对，要推翻重来；现在是没上线之前，就把“做出来会是什么样”看清楚了。

这套打法，就是我们说的企业架构。它干的，是把需求翻译成软件公司能照着施工的东西——从业务能力，一路落到流程、接口、应用、数据。一环扣一环，需求才谈得上“落地”两个字。

这就是我们自己总结的企业架构双翼法里的增量翼：让需求落地。

写在最后

回到开头那场顺利通过的评审会。

这事，可能怪不到软件公司的代码质量上。最大的问题，可能就是需求从一开始就没有说清楚、没有讲明白。

可“没说清楚”这四个字背后，藏着一个真问题——有没有人能把业务心中想的、嘴上说的，翻译成软件公司能理解、能落实的语言？

这一步空着，需求写得再热闹，落地那一刻照样走样：你递过去一篇含糊的小作文，做出来的系统只会更含糊，然后就是二期、三期，一轮轮推翻重来。

需求这件事，从来不是“提一提”那么简单，它的背后，全是专业活儿。

这，就是企业架构该站的位置——也是我们一直在做的事儿。

星顺数字化讲堂
www.thinksum.cn