ERP专案失败的“真正主要原因”是“ERP系统的‘品质’不佳”
走笔至此，也许少数人仍有觉得“ERP系统的‘品质’不佳”这句话太陇统、含糊、没有搔到痒处、不一定是ERP专案失败的真正主要原因。所以，有具体化这句话的必要。
借用我在台湾和中国两个工厂任职的粗浅经验，去揣测【魔鬼终结者】阿诺史瓦辛格的人事薪资、考勤（这里就讲“Human Resource, HR”）专案是怎么死的。
http://ppt.cc/~kim
台湾和中国这两家传统企业的HR制度，记忆中有这些：
- 劳工：三班制：07:00 ~ 15:00、15:00 ~ 23:00、23:00 ~ 07:00。夜班提供夜点费。
- 迟到半小时内，扣薪N元。迟到M小时以上，视同请假半日。早退，（忘了详情！）。未请假，旷职，扣薪X元。
- 有全勤奖。
- 小过：扣N元；大过，扣M元。小功：奖N元；大功，奖M元。
- 职员：高级主管不打卡，其余须打卡。可填单报出差。
- 薪资：按层级表。也许有年终奖金。
- 年假/年资对照表。
- 外国劳工提供住宿。
- 中国厂有用餐制度、住房、保险。
- 台湾厂有劳保、健保、综合所得扣缴凭单。
- 当然，打卡钟24小时侍候。
这些HR制度，就是user对软件“品质”的正面挑战：
- 数据错，是灾难：多发薪，公司会倒；少发薪，下班可能有人在大门堵你这个MIS主管。
- 功能尚未开发，不能接受：发不出薪水，投资人以为公司要倒了，股价跌停。
（从HR系统的重要性可知：如果MIS主管不亲自维护HR系统，那么，他要100%善待负责HR的程式部属，以免...）
HR的要求是“黑/白”、“是/非”、“有/无”、“Yes/No”，绝对没有模糊的空间。
专案辅导顾问也好，软件程式设计师也好、数据库管理师也好，都不可逃避、曲解、转移焦点。
“有”且“正确”，给100分；“无”或“错”，退回、拒绝付款。
“最佳化”这句哲学用语面对HR的要求时，必须立即丢弃。
软件专案组人员接到这种case，只有一个解决方案（solution）可以令user、MIS、软件商、顾问4方皆大欢喜，成功结案。那就是：设计数据库、程式、报表，一一满足HR的需求。
至于SAP拿什么神奇妙药去推这个专案，外人无从得知，只能透过只字词组揣测。
“SAP co-CEO Leo Apotheker angrily denied there were problems with SAP's software, and blamed consulting firms like IBM (IBM) and Accenture (ACN) for sending people who knew nothing about the software to clients as experts on SAP. Leo also has said SAP's new cloud-like package, SAP Business Suite 7, should be easier to implement.”
SAP副总裁辩称：“IBM和Accenture这些顾问不懂SAP的软件。SAP的新‘类似云端’软件应该比较容易推”。
根据此言，如果SAP拿出去的，是R/3那套架构的话，
- 它是制造业的架构，和HR相去十万八千里。
- 数据库里现有的35000个table，有没有先砍掉大部分？谁敢砍、有能力砍？
- 14000个function module，有没有先砍掉大部分？谁敢砍、有能力砍？
- 如前述，想满足HR的需求，要写程式。
R/3的ABAP是加上一堆自己特有规定的COBOL级“祖”字辈低生产力语言。
(1)用ABAP去写数百、上千个程式，何年何月何日可完成？
(2)加州现在用的系统，不就是COBOL吗？舍稳定的COBOL，求尚未撰写、更复杂的COBOL，是MIS主管做得出来的决策品质吗？
至于SAP副总裁所指的“SAP的新‘类似云端’软件”或“‘类似SOA’软件”是何种高科技？因为我没时间去了解，所以不予置评。
按我对20年前的老旧技术“Common Object Request Broker Architecture，CORBA”的皮毛认知，怀疑许多学术界在ERP产业每隔几年就推出的“软件科技最新明星”只是一些旧瓶新装的重复名词炒作而已。
面对HR需求，软件品质不良、拿不出来时，
- COBOL换COBOL的兄弟姊妹ABAP没有用
- 开会没有用
- 换顾问没有用
- 换计画主持人没有用
- 加码预算没有用
- 沟通没有用，只会火上加油、使关系更紧张
- 换SOA、云端没有用，除非采人海战术：（按美国高阶程式人员薪资水准估）月薪30万/每人，投入30人。
“ERP系统的‘品质’不佳”，在加州这个case，也许可以这样指认：
- 该有的，没有：一些画面、报表、程式没有设计给user。
- 不该有的，一大堆：制造业专用的table、ABAP程式残留在HR系统中，混淆资讯人员的视听、拖慢系统的运转速度。
- 开发困难度太高：R/3本身就是半透明的黑盒子。数据库结构犹如蜘蛛网、技术手册不一定提供且不保证正确、有隐藏机制或陷阱、“Note（官方发布的‘注意事项’）”满坑满谷且很多已失效。
- 低生产力：ABAP。
- 难用：一项功能，必须在多个画面完成（最多2层的“一对多”单据）；“Note”满坑满谷且很多已失效、互相牴触。
统称“品质不佳、不合用”。用“品质”不佳的软件推大型专案而失败，不足为奇。
加州这个case，要做的是：
- 设定停损时间点。就是N年前。
- 改用【资讯系统开发架构（framework）】，瘦客户ERP、PostERP。
- 1位数据库设计师、3位程式师上场。
- 屈下去（台语），老老实实地设计数据库、写PostgreSQL的PL/PGSQL程式。
做这项决策，
- 政府花的成本最低
- 最快结案
- 公务员user最满意
- MIS主管悠闲、拿高薪、稳坐宝座
- 数据库设计师、程式人员、软件商收到的报酬最合理
以皆大欢喜收场。
竟出此言！岂非狂妄？有何根据？
略述“瘦客户ERP”的开发应用资讯系统的流程，网友或多或少可以揣摩一下开发HR系统的“生产力”：
（1）设计数据库的（150个？）table。2个人月。
（2）开发新画面，不需要写程式：
(a)指定用到哪些数据库的table，就完工90%。3分钟。
(b)剩下的10%是：选单、选项、画面线上说明、字段线上说明...。30分钟。
（3）设计报表，不需要写程式：
(a)设计SELECT ... SQL。10分钟 ~ 1日。
(b)用鼠标拉（drag and drop）报表外观。30分钟。
(c)挂在指定的画面下、授权。各1分钟。
（4）算考勤、绩效、薪水：
(a)写（20个？）PL/PGSQL function。2人日每支。
(b)挂在指定的画面下、授权。各1分钟。