有陣子.協助PP模組.

這間公司導入初期.將生產規範客製建置在sap上.

系統盡量避免過多的客製.這是顛仆不破的真理.

這間公司在導入初期.便犯了一個極大錯誤.諸多評估放在今日.顯得不合宜.

只能說當時評估團隊並不專業.(起頭架構僵硬.後續承接維運人員因循怠惰.也有責任)

將一套系統搞得暮氣沉沉.好幾代思考懶惰者,眾志成城.相互合作堆砌出混亂局面.

當時顧問公司不知是哪一間.肯定海賺一筆.許多界面連接程式,灌水嚴重.以粗糙模式建置.談不上精巧.也無法靈活.遑論有足夠彈性符合未來拓展.

當企業有新產品.新規範需求時.當時維運者.想了一個不犯錯的策略.依樣畫葫蘆複製一套出來調整.

周邊相關程式,因為彙整過於傷腦筋.全部閉眼複製.放棄彙整.

這使得系統PP模塊.看起來混亂.粗糙.只是多個產品類型.便毫無彈性的複製相關table出來.這看在專業的工程軟體公司.妥妥的貽笑大方.

這當中還有一個致命傷.

這套客製毫無說明文件.起至開發需求說明書.到使用者操作手冊.通通沒有.

在這號稱知識爆炸時代.僅靠口耳相傳.後人努力從程式代碼中翻譯出個邏輯出來.

無人說明.全憑自己解讀.歷經數代工程師迭替.這套客製,早已混亂不堪.無人說得明白.也無人理解全貌.

後續維運人員.也未針對變化進行記錄.所有起承轉折.皆在這群亂七八糟的程式裡.靜待翻譯.靜待不同的人,解讀出不同的意思.

每屆維運人員,前不著村.全憑自己想像(理解)去調整程式.這就改得四不像.脫離中心訴求.

系統維運.有幾個重點需遵守:

1.勤紀錄.系統代碼是給電腦使用.該留存一份人眼看得懂的說明.該程式屬於何種功能.有甚麼考量.當中有甚麼變化.

2.定期審視.每半年或一年.應彙整這些紀錄文件.重新梳理系統邏輯.企業流程.乃至建置手法.是否有優化的空間?是否有更精簡扼要的作法?

進行知識管理能縮短開發時間.提升效率.

每一年的掌握,至關重要.你得了解這套運行中的系統.正以何種邏輯在運轉.

你理解了底層邏輯.方能與來自四面八方的使用者談論需求.

使用者的需求千奇百怪.但不能偏離系統主架構.背離企業運轉邏輯.

系統理應愈使用愈順遂.而非處處受限.枷鎖不斷.