SAP的冰与火之歌
公告：因企鹅审核规定，本公众号从《德国IT那些事》更名为《欧盟IT那些事》。
我今天不是来安利《冰与火之歌》的。
作为全球十大软件公司之一的德国老牌软件巨头SAP，在德国可以说家喻户晓，不亚于BAT之于中国，FANG之于美国。在德国工作的各行各业的所有蓝领白领金领，我可以负责任地说，他们不是正在开发SAP，就是正在使用SAP的路上，剩下的都忙着给SAP做接口。
为什么这么说，因为德国不管是政府公共部门还是私营企业，只要上了点规模，就一定会使用至少一套SAP系统。不管你是不是IT从业人员，你的工作生活中一定会直接或间接使用到SAP系统。去市政局登记，他们的民政管理系统可能是SAP；去银行贷款，他们的CRM系统可能是SAP；去超市买菜，他们的ERP后台可能是SAP；逛逛电商，他们的内部管理系统可能是SAP；工作上班，公司的员工考勤KPI系统可能是SAP。
你如果是IT从业人员，除了在SAP工作直接为它编程的程序员，以及在德国各地奔波不息的无数SAP咨询师之外，还有很多程序员每天都在各种千奇百怪的软件系统平台中，处理和开发与SAP的数据交互接口。我现在的职位在面试时，面试官就非常直接问我会不会用肥皂(内心OS：你才用肥皂，你全家都捡肥皂)，因为系统需要与SAP对接。
有意思的是，周边的IT行业的朋友，对蛋毛奶猪的看法通常分成两派，一派如初恋般对待SAP，非常看好其技术和市场前景；另一派就如对待前女(男)友，一边骂渣，一边希望永不再见。
我不是做SAP开发的，但长期在公司使用各种SAP的系统。作为一个多年互联网产品一线开发，大部分时间的使用体验是：想摔键盘。
慢：装载页面的等待半天，一个操作要等待半天，无论干什么都比其它互联网同类产品慢。
难看：界面UI设计古老，基本停留在21世纪初期设计水平，丑到爆。
难用：UX设计烂，页面很多还不是Rich Client，还沿用表单submit形式，操作必须刷新当前页面，万一填错数据，刷新之后又要重新填写。
总之，使用起来非常反人类。
以前项目中也做过SAP的相关，懂点ABAP二次开发，也做过sapui5 fiori前端项目。ABAP是SAP的专有编程语言，用于系统内二次开发，基本结构类似于COBOL，感觉像是在开发Visual Basic。而Fiori的API是仿JQuery设计而成，虽然不算太老旧的前端框架，但和现在主流的Angular，React和Vue的设计模式已经有较大的代差，实际开发起来不算太高效。
很多程序员都和我一样的体验，觉得SAP技术单调老旧，为什么这么难用的系统怎么还没有被其它更先进的系统取代？而且ABAP虽然入门容易，但模块二次开发繁琐无比，发一个饼图的数据报告可能需要写上千行的xlst transformation。
有的SAP程序员可能做了十几年ABAP还不知道OOP，不知道模块式开发，处于开发语言鄙视链的最底端。有喜欢尝试新技术的同行认为，SAP开发不少人一辈子只做一个模块和技术，很难理解和忍受这种孤独和寂寞。还有同行认为，SAP只是市场营销做得不错，产品更新快，但很多只是搞卖点，曾参与Oracle到SAP的数据Migration项目，做的焦头烂额。
不过从事SAP开发和咨询的同行都持另外的看法。
首先，SAP并不是以漂亮的UI和高效的操作而见长。
一，SAP靠的是灵活性和可扩展性，因为要面对全世界各行各业的公司，或者同一个行业但却有天壤之别的业务流程，对这些去开发一套全部适用的系统，难度可想而知。任何复杂的流程都可以基于SAP开发出来。
二，可以条理清楚地存储企业级复杂的海量数据，SAP系统写代码虽然比较容易，但是理解SAP各个模块里的表格数据和他们之间的关系比较费时间。数据和业务才是企业的立足所在。
三，SAP的技术构架并不落后，SAP可以搞IoT, Machine Learning, AI，开发上可以和Node.js, R等其他语言混合编程，可以用微服务分布式架构，可以部署于公有云也可以私有云。
SAP在ERP阶段还只负责企业流程，但从HANA开始，SAP已经相当于企业的操作系统，全面接管企业的方方面面。今年所在部门开会时还透露，未来将斥巨资把公司现在所有的SAP系统升级到SAP HANA，但在这之前将实施一个两年期的先导试点项目。
我现在做的是工业4.0的生产管理系统这领域的项目，上周被下放到工厂第一线深入体验生活。生产线目前采用的是源自日本的(Heijunka)精益生产管理方式。
从纯粹的业务角度来看，我又站在火焰这一边，如果没了SAP工厂将无法运转。
最终回到这个永恒的道理：业务高于一切，技术只是辅助。
不管你喜不喜欢SAP，待它甘之如饴，或是深恶痛疾，它都将在德国一直茁壮地生存下去，并为无数人提供饭碗。
我们常说一套软件系统不好用，并不是它们当初的设计和构架真的不好，它们只是老了。