前面幾天我們都是針對比較屬於策略面及管理面的事務進行說明，接下來的篇幅，會必較屬於執行面的做法，先從系統功能增修單元談起。
稽核重點：程式的開發與變更是否依據系統功能增修管理流程進行？是否需求單位主管認可？是否經資訊主管認可？程式上線程序，是否權責區分。
提供資料：程式開發及變更申請清單、抽查樣本之實體單據與簽核記錄、程式上線異動時間與程式所有權人畫面
由於 ERP 系統關係著公司的營運命脈，如果在安全把關上沒有做得很仔細， 一旦發生弊端，則其影響層面會相當深遠，甚至可能影響公司營運的誠信與形象。
我們公司在程式開發與變更申請的部份，有設計一套系統來協助管理（雖可運作，但在管理與績效分析上仍嫌不足，目前在 Survey Helpdesk 的軟體，Open Source 為主），流程如下：
1.使用者針對系統方面的需求，於系統填寫申請單
2.經部門主管核准後，通知資訊主管審核
3.資訊主管依功能需求指派負責的人員處理（估計開發時程）
4.接單人員依實際進度維護實際開發時程（必要的需求訪談、系統分析/設計、測試驗收通知）
5.通知需求人員測試
6.測試完由部門主管認可結案
7.通知資訊主管
8.核可後進行程式上線
9.資訊主管結案
通常審計的重點在於ERP程式修改的需求申請，是否有 ERP 專員的角色，以及 ERP 系統的負責人員是否依權限區分：程式開發人員與系統上線人員。
為何會有這樣的要求？（這也是當初會計師資訊審計要求我需區分時，我的疑問）我公司人員的編制就沒有這麼多，如何可以達成這樣的任務要求？
當然，就這部份的要求我與審計人員有些意見相左，但基於安全性的考量，我還是勉為其難，配合實施（不然我們就等著看會不會過啊）。其實在經過溝通與解說之後，自己在衡量現實狀況，綜其目的主要也是為了防止人員可能發生的弊端，而這些事情如果不能夠事先預防，以及擬定稽核措施，那麼當事件發生時，可能會造成無法彌補的問題產生。
我們試著想想：如果程式開發人員可以很容易的將程式上到系統上面，那麼，你如何知道這是為了什麼需求而放上去的？這裡面藏了什麼東西？當然我相信在這個圈子大部分的從業人員基本上都相當守份際與具備高度的職業道德（這種事情以前在對岸就很常發生），但站在保護公司資訊系統安全、穩定的立場，這一個步驟其實是必須要執行的。
當然，程式修改與更新如何勾稽，我們會在後續的篇幅中一一說明。
這讓我想起以前聽過一位銀行IT襄理講的話
他告訴我
你以為銀行搞這麼多安控機制是在防駭客嗎？
外面的駭客容易防(明槍易躲)
其實最主要的是在防內部員工做怪
基本的原則就是
不讓任何一個人擁有全流程的權限
不讓任何一個人了解全流程的技術細節
寫程式的人碰不到資料
管資料的人搞不懂程式邏輯
最大權限的管理者不懂程式邏輯也管不到資料
結果弄了這麼多
銀行還是發生了許多財務損失事件
都不是IT的漏洞
而是出在人身上
沒錯！
所以jamesjan在銀行上班??...
我們如何訓練上市上櫃客戶實例 ::
jamesjan提到：
1.使用者針對系統方面的需求，於系統填寫申請單
2.經部門主管核准後，通知資訊主管審核
3.資訊主管依功能需求指派負責的人員處理（估計開發時程）
4.接單人員依實際進度維護實際開發時程（必要的需求訪談、系統分析/設計、測試驗收通知）
5.通知需求人員測試
6.測試完由部...(恕刪)
1.使用者針對系統方面的需求，於系統填寫申請單
[需求部門 : 需求職務 : 提議人員]
提議人員 : 必須接受輔導完成基本需求框架(可正確銜接管理流程)
[畫面需求 : 欄位位置 : 型態長度 : 顯示邏輯 : 運算邏輯 : 驗證邏輯]
[報表需求 : 欄位位置 : 型態長度 : 顯示邏輯 : 運算邏輯 : 篩選邏輯]
[拋轉需求 : 欄位位置 : 型態長度 : 顯示邏輯 : 運算邏輯 : 拋轉邏輯]
2.經部門主管核准後，通知資訊主管審核
[需求部門 : 部門主管]
[資訊部門 : 資訊主管]
3.資訊主管依功能需求指派負責的人員處理（估計開發時程）
提議人員 : 必須接受輔導完成基本需求框架(可正確銜接管理流程)
資訊人員 : 必須接受輔導完成進階需求框架(可正確銜接資料庫)
[畫面需求 : 欄位位置 : 型態長度 : 顯示邏輯 : 運算邏輯 : 驗證邏輯]
[報表需求 : 欄位位置 : 型態長度 : 顯示邏輯 : 運算邏輯 : 篩選邏輯]
[拋轉需求 : 欄位位置 : 型態長度 : 顯示邏輯 : 運算邏輯 : 拋轉邏輯]
4.接單人員依實際進度維護實際開發時程（必要的需求訪談、系統分析/設計、測試驗收通知）
5.通知需求人員測試
6.測試完由部門主管認可結案
7.通知資訊主管
8.核可後進行程式上線
9.資訊主管結案
真正企業的系統
不會讓資訊中心去寫編程
自己分析管理流程
自己分析架構流程
自己來編程
自己測流程
!! 確記
編程發包 不可用技術發包
編程發包 是採用實作發包
!! 確記
實作發包 是 Coding House 要承包
必需遵守 技術轉移顧問 的標準範例不可以更改程式流程
例如 :
單據 ComplteIt WorkFlow
單據 VoidIt WorkFlow
單據 ReverseIt WorkFlow
...
技術顧問做一次 實作編程做一百次
20年經驗顧問 一模組講解 3 萬元 實作編程做一百次 30萬
技術顧問公司有技術 日薪 8000 做 3 天 = 公司賺 6千
實作編程公司有人脈 日薪 3000 做 30天 = 公司賺 21萬
人脈比較值錢
iThome鐵人賽
看影片追技術