来源：市场资讯
（来源：王岩聊数智）
昨天在一个CIO群里有朋友问了个问题：
业务对数据的真实性、合法性及业务合理性负责，数据错了——仓库多出了、少入了，财务成本高了低了——IT需要对这些数据负责吗？碰到业务部门甩锅"系统有问题"的情况，怎么搞？
按标准定义，数据谁产生谁负责，业务部门作为数据Owner要对数据质量负责；IT本身不产生数据，不该背这口锅。
但现实往往是业务和IT互相拉锯，业务说"系统不好用"是个万能借口——操作不够人性化、录入东西太多、系统卡顿、模块之间数据不通，细究起来能说一大堆。
可就是没人反问一句：系统为什么一定要那么好用？
先界定一下：今天讨论的"系统"，是企业内部带业务逻辑和管控规则的管理系统（ERP、CRM、HR等），不是给一线用的扫码枪、小程序这类数字化工具。
接下来从我的亲身经历，谈一下企业级系统到底该不该以"好不好用"为标准。
01
IT 部门被投诉
第一段甲方经历，就经常被吐槽"系统不好用"。
那是2011～2016年，我所在集团和KD公司战略合作，在EAS产品+BOS平台上开发行业一体化系统——全集团除了蓝凌的OA就是EAS，HR+财务+资金+预算+CRM+POM彻底打通，誓要消灭数据孤岛。
那是个狂飙突进的时期，老板要求3年赶上龙头信息化水平。我们连着百来号外部人员，轰轰烈烈上各种系统模块。
但随着系统越上越多，质疑声也越来越大——最集中的就是"系统不好用"，特别是KD的EAS。
那时候EAS还是古早的C/S版本，用户要装客户端，启动时下载大量二开私包——最夸张时期打开客户端要更新好几个G，带宽一吃紧，体验自然崩。
为什么会下载这么多私包？因为集团和KD公司的合作本意是"做行业样板"，总部产品团队以我司业务为原型开发行业产品。但合作到一半，KD总裁下课了，产品化改造无疾而终——我司作为大客户业务需求依然重要，但不再作为产品需求源头，大量的二开需求靠本地外包团队做外挂私包实现，代码质量和规范离原厂开发差一截。
更深的问题是一体化系统的连锁反应：CRM动个字段不知怎么就让财务系统报错，权限规则改一下导致全系统登录失败，月初月末业绩冲刺和财务结账一出问题，业务部门抱怨就上来了。
公司提倡"职能服务好业务"，IT部门也要有服务意识，业务部门对系统的满意度被纳入信息化工作考核——这一下我们就被动了。
团队规模有限，软硬件加起来才7个人。核心系统三四个人管几十套模块的运营推广，老模块还没用好新系统又要上线，开发运维一把抓。我从上班IM就在闪，一直到下班就没停过，哪有时间琢磨用户体验？
02
Vanke来的副总裁
转机来自一位空降的执行副总裁。董事长有更大野心，从当时的行业龙头V公司挖来一位高管，分管我们部门。这位工程出身的领导（姑且称D总吧），一来就拉着我们和业务部门一起调研。
面对业务部门"系统不好用"的抱怨，D总没一味指责IT，反过来问业务部门几个问题：
哪里不好用？
是系统反应慢，还是程序出bug？
如果数不准，是系统出错还是一线没及时录入？
然后他直接要求采购部现场演示："你们不是说慢吗？打开系统，一步一步操作给我看，到底哪里慢。"
现场的效果比预期好，经过我们对系统的持续优化，登录和访问速度已有提升，虽然还没到业务部门说的"像微信一样好用"，但单模块非全量查询响应控制在5秒内，直观感受已经流畅。
采购部一步步操作时，D总突然发现一笔他印象中的订单系统里没体现。他掏出手机，免提打给认识的业务负责人，问系统用得怎么样、那笔订单为啥没往系统里录。
对方一听是D总裁，吓了一跳，连说马上查。几分钟后反馈电话来了——用户那几天刚好请假还是别的原因。
事后D总做了几条重要指示：
业务以后给IT提问题要说清楚，不能笼统说"系统不好用"，要具体到哪个环节；
总部要给一线减负——很多数据收上来也没什么好分析的，白白增加一线工作量；你让人家填的多了，人家当然有意见；
也不能因为要给一线减负，该填的一个不填——系统成了大号工作流，那还不如直接填Excel；
系统好用是有成本的，V公司财大气粗做定制开发才觉得好用，我们不能比；系统只要适度好用、稳定能用就行，重点是标准流程线上化，别让IT把精力浪费在琢磨"一线多点还是少点几下菜单"上。
领导表态就是好使。从那以后业务部门关于"系统不好用"的压力少多了，更多是就事论事的需求。
2014～15年移动应用普及起来，我们给领导配了移动审批APP，每人发个iPad，审批体验比电脑端好得多。慢慢地，压力小很多，满意度也逐步起来。
2016年中我离开原单位，加入一家信息化刚起步的公司。有了前一段经历，我在新项目里对用户体验尤其重视：
1、设计了一整套UI规范和操作流程‘’
2、系统以定制化+Web应用为主，必须考虑移动应用；
3、不管甲方还是乙方的产品经理我亲自面试，必须对用户体验有一定的理解。
经过相应的要求和规范，新公司新系统的上线期间，至少在用户体验层面很少再听到"系统不好用"的投诉了。
03
萨莉亚的理念
让我对"系统不好用"有更深认识的，是近期看的一本书《萨莉亚经营术》。作者堀埜一成（萨莉亚前总经理）讲了一个反共识观点：所有门店要"降低美味度"。
越是追求味道的极致，一旦味道偏离，客人的落差就会很大。连锁店应该追求的目标是"理所应当的品质"——无论哪家店都能提供同样味道的再现性和稳定性，而不是极致的美味。
对服务也是一样。萨莉亚只要求"把理所应当的事情理所当然地做好"，避免超出必要范围的服务。突出个性的服务不仅没有加分，反而会减分——会引起"那家店这么做了，这家店怎么不做"的不满。
把同样的理念映射到企业数字化：
什么是服务？服务就是"把理所应当的事情理所当然地做好"。
对甲方内部的数字化从业者而言，理所应当的事情是保障系统的安全和稳定——这是最基础的。在保障稳定的前提下，用最小化成本让业务系统上线、产生价值。
至于"系统好不好用"，和"菜好不好吃"一样，千人千面，没有明确标准。而数字化的前提恰恰是标准化，尽可能消除管理上的不确定性。
一味的追求"好用"，就要在人力物力上投入更多资源去满足某个个体飘忽的评判逻辑，又难以产生更大收益——这恰恰与上系统、数字化的逻辑背道而驰。
服务不是伺候。 IT的职责是服务业务部门，但并不是服务业务部门的某个人。涉及不同领导的差异化诉求（比如老板或某些高管），可以分级服务，改天单聊。
而且根据我的经验：阎王好见，小鬼难缠。 越大的领导由于不实际操作系统，反而对系统的意见不大，更容易满足。真正难缠的，是那些天天用、又有想法、又没大局观的中层执行岗。
把这些想透了，对"系统不好用"的投诉，自然能坦然处之。
我是王岩，20年数字化实战老兵。
热门跟贴