SAP的冰与火之歌
點擊?歐盟IT那些事?關注我們
公告：因企鵝審核規定，本公眾號從《德國IT那些事》更名為《歐盟IT那些事》。
身邊的諸多IT行業的朋友，對SAP的看法普遍分為兩派，一半是冰海，一半是火焰。
我今天不是來安利《冰與火之歌》的。
作為全球十大軟件公司之一的德國老牌軟件巨頭SAP，在德國可以說家喻戶曉，不亞于BAT之于中國，FANG之于美國。在德國工作的各行各業的所有藍領白領金領，我可以負責任地說，他們不是正在開發SAP，就是正在使用SAP的路上，剩下的都忙著給SAP做接口。
1蛋毛奶豬
為什么這么說，因為德國不管是政府公共部門還是私營企業，只要上了點規模，就一定會使用至少一套SAP系統。不管你是不是IT從業人員，你的工作生活中一定會直接或間接使用到SAP系統。去市政局登記，他們的民政管理系統可能是SAP；去銀行貸款，他們的CRM系統可能是SAP；去超市買菜，他們的ERP后臺可能是SAP；逛逛電商，他們的內部管理系統可能是SAP；工作上班，公司的員工考勤KPI系統可能是SAP。
你如果是IT從業人員，除了在SAP工作直接為它編程的程序員，以及在德國各地奔波不息的無數SAP咨詢師之外，還有很多程序員每天都在各種千奇百怪的軟件系統平臺中，處理和開發與SAP的數據交互接口。我現在的職位在面試時，面試官就非常直接問我會不會用肥皂(內心OS：你才用肥皂，你全家都撿肥皂)，因為系統需要與SAP對接。
當然肥皂只是SAP所支持的諸多數據接口中的一個，但無數運行良久的老SAP系統里，肥皂接口是唯一的對外數據交互接口。
在德國，可能只有繳稅和SAP，是你無法避免接觸的東西。
SAP為各行各業提供了各種可能的解決方案，以及海量的定制業務模塊，它的構架體系和功能非常龐大和復雜。德國人形容SAP系統是Eierlegende Wollmilchsau (eierlegendes Wollmilchschwein)，翻譯過來就是會生蛋的既產羊毛又產牛奶的豬，簡稱蛋毛奶豬。
2一半冰海
有意思的是，周邊的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實在是太難用，開發體驗又不友好。
3一半火焰
不過從事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)精益生產管理方式。
Heijunka，簡單的解釋, 如果按計劃要在5天內需要生產5個產品A，那可能會根據實際需求動態安排每天生產1-N個A，而不是在第一天一口氣生產5個，而在其他的4天休息或干別的。而這么做的意義，除了自身需要更少的資源以外（日生產能力為1個A就能滿足需要了，而不需要5或其他），對零部件和原材料的需求也更穩定了，意味著供應商儲備更少的庫存，或維持更小的生產能力就可以滿足最終市場的需求。另外對于客戶所要求的急單，或者生產線突發狀況也可以更快地動態做出調整。
看起來是不是特別熟悉，非常像我們軟件開發進程管理用的Kanban面板？是的，這貨就是Kanban，我們程序員常用的虛擬Kanban面板的爺爺。
生產大線上每天早上會開個例會（站會），討論分配一下當天和明天的計劃，總結下昨天已完成的計劃，和出現的問題。然后這個面板會被推到各個細分生產線那里，方便產線管理人員調配。這些操作目前還是靠人工手動操作，我的項目就是把生產上的一切流程數字化，并把數據和SAP系統對接，也就是俗稱的數字孿生。
產品負責人給我們講解從生產調度，到原料采購，備料，生產，檢驗，包裝，發送等一系列生產步驟。而這所有步驟中，不可缺少的一個環節就是：任何操作都會通過RFID或者掃碼被錄入數據，供中控調度。你們猜這些數據去哪了？
全去了SAP系統（部分去了MES系統）。
我注意到一個細節，一名工人在備料時，用車將零件送到備料區，上貨前需要用移動設備掃碼和記錄，這時他的設備可能因為后臺系統反應慢沒了響應，他就丟下送貨車和沒入庫的零件走了。換句話說，生產中任何一步的SAP系統出了岔子導致停工，那么整條生產線都要停下來等候系統恢復。工人們什么都不能干，集體喝咖啡休息。
恐怖不恐怖？SAP開發程序員你們責任大不大？
而這些原料采購，備料，生產，檢驗，包裝，發送等一系列生產步驟中所涉及到的SAP系統和模塊，已經在工廠中沿用了幾十年，所有生產數據都在其中。換句話說，不可能出現一個第三方軟件平臺，可以百分百接管SAP的任務。除非這個軟件供應商可以做到這點，邊開車邊修車：一邊平穩升級軟件平臺，一邊保持原有的生產暢通。
這完全是Misson Impossible，阿湯哥也做不到！
只有一種可能可以取代SAP，那就是新建整個工廠，并且重建整個生產管理系統，同時這套新系統還必須同步打通和原有老SAP系統的數據對接。以德國目前的IT開發專家缺乏的困境來看，這絕對是不可能完成的任務。
從純粹的業務角度來看，我又站在火焰這一邊，如果沒了SAP工廠將無法運轉。
4冰山一角
最終回到這個永恒的道理：業務高于一切，技術只是輔助。
不管你喜不喜歡SAP，待它甘之如飴，或是深惡痛疾，它都將在德國一直茁壯地生存下去，并為無數人提供飯碗。
德國工業界使用SAP系統已然成為歷史慣例，并且深入到生產的每個毛細血管里，短時間內不會出現另一個第三方平臺可以取而代之。對于第一線生產人員來說：你界面好不好看，交互好不要用，后臺用Java還是C++什么技術管我P事，我只要一點：
不要出錯，順利生產！
大部分人所接觸到的SAP，比如我們所詬病的界面難看難用，技術過時等方面只是浮于水面上冰山可見的一角，而潛于水下那龐大的數據結構和復雜的業務流程，卻很少有人會注意到。
水下的這塊冰山，才是真正的SAP，靜寂，難以窺視全局。
我們常說一套軟件系統不好用，并不是它們當初的設計和構架真的不好，它們只是老了。
本月新聞&文章回顧
可向下滑動
世界消滅你，與你無關
慕尼黑將用三年時間重迎企鵝
德國奔馳將自主研發車載系統MB.OS，對抗Tesla
德國大眾20億歐元押寶中國電動車市場
2020.05新聞&文章回顧
2020.04新聞&文章回顧
2020.03新聞&文章回顧
2020.02新聞&文章回顧
2020.01新聞&文章回顧
總結
- 上一篇： php redis 唯一id,PHP +
- 下一篇： 详解液晶面板制造全过程