客製，就像是量身訂做的裁縫師，
以標準功能為基礎，打造完全合用的功能，
但是不要誤會客製無所不能，
因為寄人離下的功能，難免有先天的限制，
只要能夠明確提出問題，就有機會來解決問題，
因為，「答案就在問題中」。

-- 我的工作 --
本人專職從事 Oracle ERP 客製。

-- ERP 簡介 --
Oracle ERP 是一個功能強大、架構龐大的世界級應用系統，
裡面依功能別，區分為很多模組，
隨便一個模組，就有非常多的程式、與物件。

-- 客製是什麼 --
如果標準功能，與公司流程稍有出入，
想要對各別模組，增加、或是修改個什麼功能，
就要由客製人員，針對需求來花心思，
來思考怎麼對系統，東修西改、疊床架屋什麼的，
讓系統誤認為，經由客製程式，所產生的資料，
與標準功能，所產生的資料，內容完全一樣、無法區分，
這就是客製有趣的地方。

電腦，其實是個很有效率的工具，
或者，也可以說是很笨的工具，
因為電腦的一言一行，完全依照撰寫的程式來執行，
(不像人類的行為，可能依照心情來處理)，
如果執行的結果，不符合預期時，
不必擔心，
這裡有個基本程序，可以協助發現問題，進而解決問題。

-- 發現問題 --
當程式執行出現問題時，使用者多半只能提出，
「電腦有問題」、或「執行的結果錯誤」這類回應，
這時，就要設法來重建操作現場，
以便進一步找出，造成問題的原因。

為了找出問題，首先有二個步驟務必去做：
1 了解使用者的操作步驟。
2 確認相關資料的狀態。

其實，執行程式出現問題，十之八九都是資料的問題，
但是使用者並不明白，
所以就要花時間、與心思，與使用者不斷周旋、與確認，
資料操作的步驟、或是維護的資料，是否正確，
相關資料的關聯、或是基本設定，是否曾被異動什麼的。

千萬不要有「我應該已經設定好了」、或「我記得我有設定」這種心態出現，
在多人使用的系統中，只要有權限，
任何人、在任何時間，就可以進來改任何資料、或是設定，
只要針對出現的狀況，心中有懷疑的設定，
就「立刻」去「確認」目前的設定。

電腦畢竟不是人腦，
不會有立場不一、昨是今非的想法，
確認、再確認，
絕對是發現問題的不二法門。

-- 理解問題 --
我們可以先以 HOW、WHO、WHEN、WHERE、WHAT (WHY 是我們要去找的) 這幾個問句，
來檢視目前的問題，以便豐富掌握的資訊，
每人有自已喜歡的提問方式，
若不介意，可以參考這裡列出的幾個問題:
1 請問使用者如何操作？
2 請問是某人操作，還是大家都會出現這個問題？
3 請問是曾經，還是只要執行總是出現這個問題？
4 請問是特定電腦，還是任何電腦都會出現這個問題？
5 請問操作過程，是否曾出現提示 (錯誤) 訊息？若是，訊息為何？
6 請問狀況是不定時出現，還是會一直重複出現？

-- 分析問題 --
為什麼要這樣思考？
因為，只要是特定人、特定時間、特定電腦，出現的錯誤，
大多是操作不良，是屬於資料層面的問題，
錯誤有可能是使用者造成的，
通常只要重新教育訓練、或提醒使用者，
問題就可以解決。

如果是任何人、任何時間、任何電腦，都會出現的錯誤，
則多半是程式、或是資料庫物件層面的問題，
就要請寫程式的人來看看，
程式的邏輯，是不是有地方考慮不周全、破綻、還是根本就寫錯了，
導致使用者依照步驟來操作，會出現不可預期的錯誤。

-- 確認問題 --
程式的問題，多半有個特性，就是會「重複出現」，
換句話說，只要還原當時的操作，
程式就會出現當時的結果。
(當然偶爾會有例外，不過那是極少數的例外，這裡不論)

只要確定如何、如何操作，
就會產生如何、如何的資料，
造成如何、如何的錯誤，
這就算是確認問題。

確認問題說起來簡單，但是想要真正的確認原因，通常要花一些時間，
如果想找跨模組的問題，更是要花心力，
因為各模組的操作，步驟都很繁複，
想找出跨模組的問題，至少要對相關模組的資料流程，有點認識才做的到。

簡單的說，就是要靠經驗，
又說回來，有誰一出生就會 Oracle ERP 呢？
還不是多利用時間，不斷的測試、測試、再測試，才能累積所謂的經驗。

經驗較周全的，確認的問題，多半也較周全，不太會有後遺症，
經驗較粗淺的，確認的問題，多半也較單純，偶爾考慮不周全，多少有點後遺症，
不管怎麼說，只要能確認產生問題的原因，而且不讓錯誤重複出現，
就是有真本事。

-- 解決問題 --
解決問題其實是比較簡單的，
問題確認之後，只要針對問題來下手，通常可以解決問題。

比如說:
Q:程式沒有檢核某某資料，導致資料關聯不完整，造成串連錯誤。
A:程式增加某某檢核即可。

Q:新增時，沒有同步產生某某資料，導致後續運算出問題。
A:程式新增時，同步產生某某資料即可。

Q:查詢時，某某資料無法讀出來，導致資料少算。
A:讀取資料時，要多考量某些情況被漏列的資料。

發現了嗎，解決問題的方法很簡單吧，
答案就在問題中。

你有什麼問題，就以什麼答案來處理，一病自有一藥醫，
不用怕沒有藥，而要怕問題的方向搞錯了，
「醫生怕治咳、水電怕抓漏」，
只要確認了問題，幾乎就等同於解決問題，
方向對了，剩下的就是時間的問題了。

有時候解決問題的方法，很簡單，
有時候解決問題的方法，很複雜，

複雜的意思，
有可能是要用較多的程式，或是要用難度較高的程式，
這就要由系統分析人員去決定，
畢竟，與其寫個難度頗高的程式，我還是喜歡拆為多個難度較低的程式，
不但程式設計師水準不必太高，日後維護也比較簡單。

-- 備案 --
有些問題就算經過繁複的程式測試、單元測試、整合測試之後，
還是沒有百分百解決問題，
這時，當然要先將程式下下來。

如果使用者已經正式使用，也已經產生錯誤資料時，
為了避免後續作業，繼續出現錯誤，
就要將所有產生的錯誤資料，
完全回復到還沒使用的狀態 (這個動作很花時間)，
再回到找問題的「發現問題」階段，重新走一遭。

-- 觀念溝通 --
出現錯誤，其實並不可恥，只要立刻修改即可，
可恥的是發現了錯誤，不去改正，
以致於讓程式的錯誤，一直重複出現，
造成資料的正確性有問題。

程式只要不穩定，造成資料可能有問題，
對模組而言就是不安全，
模組不安全，就有可能導致整個系統出現狀況，
就是一個大災難。

對程式而言，只有 0 分、或是 100 分，
沒有 85 分、或是 60 及格。
試問，你能允許程式每維護 100 筆，就有 1 筆可能儲存失敗嗎？不會吧！
對使用者而言，只有要執行 (100分)、或不要執行 (0分) 這個程式，
問題的判定，絕對是黑、白分明，沒有灰色地帶。

記住，
客戶是以結果來論英雄，不是以你投入的時間來論英雄。

英雄可以分為幾種:
1 很快發現問題，很快解決問題。
2 很快發現問題，好不容易解決問題。
3 好不容易發現問題，很快解決問題。
4 好不容易發現問題，好不容易解決問題。

至於那種，找不出問題，或是無法解決問題的，
就不要再說自已很厲害，人還是謙虛點好。

更有那種，輕易、或隨便妄稱:
1 系統本來就沒有這個功能。
2 系統無法解決這個問題。
的人，更是要不得。

沒有人是完美的，不會可以直說，不要隨便就妄說系統做不到，
(雖然有的問題系統做不到，但是要評估後再回應)

知道、與做到，本來就是二回事，
發現問題、與解決問題，本來就是一碼歸一碼，
還是那句話，做人謙虛點好，
隨便就把話說死，妄稱做不到的，
日後如果有人能做到，豈不是丟自已的臉。

-- 沒事衍生 --
我們不是總統，
出錯就要明確告知，有時候還要寫報告，說不定還會有人被懲處，
不要認為時間久了，客戶會忘記，沒有這回事，
時間拖越久，問題越滾越大，要解決問題的成本也就越大。

不要以為你是綠黨的，
就可以說什麼，「新手上路、請多見諒」，沒有這回事，
總統可以讓「核四停建」損失2000億 (目前損失仍擴大中)，沒有人追就，
你如果敢讓客戶有任何損失，客戶可不會放過你，
輕則扣款、不付錢；重則對告、上法院。
人家不會管你是什麼黨的，也不會管你知不知恥，
只會管他付錢是請你來解決問題的，不是請你來製造問題的。
務必放在心上。

-- 結論 --
再怎麼複雜的問題、功能、或狀況，
都可以先將問題定義出來 (一個很複雜的大問題)，
然後再以切割問題的方式，來簡化成小問題 (分為20個簡單的小問題)，
只要再針對小問題，各別提出解決方案，
自然能夠解決複雜的問題。

客製，就像是量身訂做的裁縫師，
以標準功能為基礎，打造完全合用的功能，
但是不要誤會客製無所不能，
因為寄人離下的功能，難免有先天的限制，
只要能夠明確提出問題，就有機會來解決問題，
因為，「答案就在問題中」。