为什么我们公司的OA这么难用？
为什么我们公司的OA这么难用？
做了5年泛微二次开发。
被问过最多的一句话是：
“为什么我们公司的OA这么难用？”
每次听到这句话，我都想反问一句：
你知道你那套OA，是怎么被做成这样的吗？
我接手过一个出差申请流程
功能描述很简单：
员工填出差申请，输入开始日期和结束日期，下面自动生成出差计划明细——每天一行，填写当天的工作内容。
听起来很普通，对吧。
但我打开这个流程的时候，愣了一下。
设计者的解法：建15张表
原来的设计者不会写JS。
他的解法是：
用关联台账表来生成明细行。
出差1天，关联第1张表。
出差2天，关联第2张表。
出差3天，关联第3张表。
……
出差15天，关联第15张表。
所以他建了15张表。
字段名整整齐齐：
uf_ccsqmrgz1uf_ccsqmrgz2uf_ccsqmrgz3
……uf_ccsqmrgz15
最大支持15天出差。
超过15天？不支持。
这不是解决问题，这是在绕开问题
我不是要嘲笑这个设计者。
能把功能跑通，说明他花了时间，也花了心思。
但这个方案有一个根本问题：
他在用数据堆砌来替代逻辑。
JS可以做的事，他用15张表来模拟。
结果就是：
系统里多了15张台账表，维护成本极高。
出差超过15天，功能直接失效。
后续如果要加字段，15张表要改15遍。
这套东西交付给客户，客户能说什么？
能用，就收下了。
我的优化：JS + SQL，一套逻辑搞定
我接手之后，把这15张表全部废掉。
用JS重写了生成逻辑：
根据开始日期和结束日期，动态计算天数，循环生成明细行，每行自动填入对应日期。
顺手用SQL算出了每天是星期几，直接显示在明细里。
现在的效果：
选好开始日期和结束日期，下面的出差计划自动生成——日期、星期、Day 1 / Day 2 / Day N，全部自动算好，员工只需要填每天的工作内容。
出差7天生成7行，出差20天生成20行，没有上限。
那15张表，说明了什么
我想说的不是我有多厉害。
我想说的是：
那15张表，是一个不会JS的人，在没有人帮他的情况下，用最笨的办法撑起来的一个功能。
他可能是外包顾问，工期卡得很死。
他可能是公司内部员工，没人教过他还能怎么做。
他可能知道这个方案不好，但当时没有更好的选择。
我不知道。
但我知道的是：
客户为这套OA付了钱，用了几年，出差超过15天的人，这个功能对他们来说从来都是坏的。
他们不知道是实施的问题。
他们只知道，OA不好用。
OA难用，锅不一定在平台
泛微E9的表单、工作流、JS扩展、SQL联动、ecode平台、无侵入开发等等，能力摆在那里。
根据日期动态生成明细行，不是什么高难度需求，JS写起来也就几十行。
但如果实施的人不会写，或者不想写，或者项目工期到了懒得研究——
他会给你建15张表。
然后告诉你，功能已经上线了，验收吧。
OA难用，很多时候不是平台的问题。
是当初做这件事的人，能力或者态度，没有到位。
最后说一句
接手别人留下的系统，是这行的常态。
我见过很多这样的东西——能跑，但跑得很勉强。
每次优化完，我都会想：
用这套系统的人，在这个问题上，安静地忍了多久。
