Presentation is loading. Please wait.

Presentation is loading. Please wait.

Ch4 控制資訊系統: 企業流程控制.

Similar presentations


Presentation on theme: "Ch4 控制資訊系統: 企業流程控制."— Presentation transcript:

1 Ch4 控制資訊系統: 企業流程控制

2 學習目標 瞭解控制架構的步驟 瞭解如何編製控制矩陣 瞭解本章中所介紹的通用企業流程控制計畫 能夠描述企業流程控制如何達成控制目標
體認控制對於擁有企業整體系統的組織的重要性 體認控制對於從事電子商務的組織的重要性

3 AIS輪軸軸心的流程控制 本章聚焦控制的一層—流程控制—如AIS輪軸所示。
首先,你們將會學到如何將流程控制目標分解為作業程序目標及資訊程序目標,再據以評估流程控制目標的性質與範圍。 接著,作業程序目標將再細分為效能、效率、及安全性目標;而資訊程序目標將再劃分為輸入及更新目標。 針對各種控制目標,你們將瞭解其有效的控制計畫。 藉由結合控制目標與計畫,你們將瞭解如何建立控制矩陣;這些是後續章節評估流程控制的基石。

4 控制矩陣 控制矩陣(control matric)是一個用來協助分析系統流程圖與相關文字敘述的工具。 它建構了評估特定企業流程控制的準則。

5 控制矩陣範例

6 編製控制矩陣的步驟 設定控制目標為建構控制矩陣的第一步驟, 控制目標列在橫跨於矩陣上方的橫列 。 辨認作業程序目標 辨認資訊程序目標
設定控制目標為建構控制矩陣的第一步驟, 控制目標列在橫跨於矩陣上方的橫列 。 辨認作業程序目標 效能目標 效率目標 安全性目標 辨認資訊程序目標 輸入目標 更新目標

7 作業程序目標:效能目標 作業程序的效能控制目標,在於確保成功地達成企業流程的目的 。
在Causeway現金收入流程裡,我們目前只舉兩個目標為例: 目標A ─ 立即將收到現金存入銀行,以加速現金流動。 目標B ─ 確保遵循與存款銀行訂定的補償性餘額(compensating balance)協議。 其他可能的現金收入目標,將依序以目標C、D等表示,並描述於矩陣下方(位在矩陣裡說明(legend)的部分)。 若考慮其他企業流程,例如生產,我們可能會將效能目標訂為: 目標A ─ 藉由準時完成生產訂單,以維持顧客滿意度。 目標B ─ 藉由確保製成品的最高品質,以增加市場佔有率。

8 作業程序目標:效率目標 作業程序的效率控制目標,在於確保企業流程使用到的所有資源,都能以最具生產力的方式被利用。
請注意在圓括號裡,我們已列出可運用於現金收入流程的兩種資源─人員和電腦。 事實上,在評估會計資訊系統的效率時,人員和電腦是經常會被考慮到的項目。 其他企業流程,例如收貨,我們可能也需要考慮到設備使用的效率,例如卡車、叉架起貨機、及手提式掃描器。

9 作業程序目標:安全性目標 作業程序的安全性控制目標,在於保護企業資源,確保其不會遺失、被破壞、洩密、影印、不當銷售、或濫用。
在圓括號裡,我們已包含現金收入流程中需要確保其安全性的兩個資源─現金及資訊(應收帳款主檔資料)。 在任何企業流程中,我們均關心在執行流程時,被新增、修改或刪除的資料,以及被帶入或移出組織的資產,例如現金、存貨、及固定資產。 若考慮其他企業流程,例如出貨,我們可能加入客戶主檔資料及出貨資料。 請注意,光碟第16章將執行企業流程的硬體資產(例如電腦設備、卡車、拖車、月台碼頭設備等)的安全性,列為普遍性控制。

10 資訊程序目標:輸入目標 資訊程序的輸入目標,在於確保所有企業流程資料,在輸入系統時的
輸入真實性(input validity, IV) 輸入完整性(input completeness, IC) 及輸入正確性(input accuracy, IA) 在現金收入流程裡,我們關心現金收入的輸入真實性、正確性、及完整性。 在這裡,它們以匯款通知單的形式呈現。 請注意,我們明確地在圓括號裡記錄輸入的資料名稱。 若考慮其他的企業流程,例如雇用員工,我們將關心其他例如員工、薪資、福利計畫等輸入資料。

11 資訊程序目標:更新目標 更新目標必須考量所有將會被輸入資料影響到的相關資訊,例如主檔資料及分類帳資料。資訊程序的更新控制目標,在於確保企業流程輸入資料的 更新完整性(update completeness, UC) 更新正確性(update accuracy, UA) 在現金收入資訊程序裡,我們認為現金收入流程將會影響應收帳款資料。 現金收入為借方影響,顧客餘額為貸方影響。 請注意,我們在控制矩陣裡列出應收帳款主檔資料。 其他企業流程,例如支付現金,將牽涉到不同的更新項目,例如供應商、薪資、或應付帳款主檔資料。

12 編製控制矩陣的步驟 II. 建議控制計畫 註記「既存的」控制計畫 評估「既存的」控制計畫 辨認及評估「遺漏的」控制計畫

13 Causeway Company-經過註記的系統流程圖

14 註記既存的控制計畫 從系統流程圖的左上角欄位開始,在第一個人工輸入符號、人工程序符號、電腦程序符號(程序相關符號)。
接著,順著系統流程圖的邏輯,辨認所有程序相關符號。 每個程序相關符號反映著一個存在的內部控制計畫。 辨認可能存在的控制計畫是重要的,這些控制計畫可能沒有如預期般有效地運作,因此,你可能需要建議一些方法來加強或擴充既存的控制計畫。

15 註記系統流程圖 檢視流程圖,判斷某一控制『存在』 (P-)或『遺漏』 (M-) 。 註記流程圖 如果控制存在,則標示 P-。

16 註記既存的控制計畫 檢視Causeway的系統流程圖(圖4.2),你將發現第一個程序相關符號為「背書支票」
因為此程序顯示在流程圖上,表示此控制計畫已經存在。 因此,在這個程序旁我們記錄「P-」的記號,表示其為既存的控制計畫。同時在「P-」旁邊的「1」表示此為流程圖中第一個既存的控制計畫。 所以你應該已經在系統流程圖上註記P-1。

17 註記既存的控制計畫 繼續依照其邏輯檢視系統流程圖,依序在流程圖中註記P-2、P-3等,直到你已經將所有既存的控制計畫完成註記。
請注意圖4.2,Causeway已經存在八個控制計畫(P-1–P-8) 。

18 評估「既存的」控制計畫 在控制矩陣左手邊的欄位,寫下每個控制計畫的編號(P-1, P-2, P-3 ,…. P-n)與名稱 。
某一控制計畫也許能夠適用多個控制目標。 針對每個既存的控制計畫執行相同的程序。 同時,在矩陣的說明部分,描述控制計畫如何適用於註記的控制目標。

19 辨認及評估「遺漏的」控制計畫 在下一個步驟--建議控制計畫,為決定是否需要額外的控制,來補足目前缺少控制計畫的控制目標區域,或加強既存的控制計畫,或兩者並行。

20 辨認及評估「遺漏的」控制計畫 檢查控制矩陣:首先,檢視控制矩陣並觀察是否有任何控制目標(作業或資訊)尚未存有控制計畫。
若發現此情況,你需要進行下列事項: 在矩陣的左手邊欄位,將第一個遺漏的控制計畫編號為M-1,並寫下該計畫的名稱。 橫越矩陣的橫列,將M-1註記於該控制對應的相關控制目標的空格。 在矩陣的說明部分,解釋該遺漏的控制將如何適用於經註記的控制目標。 在系統流程圖裡,在該控制應被嵌入的位置,註記M-1。 若仍有控制目標尚未存在任何的控制計畫,則建立另一個計畫(M-2),並重複上述四個步驟。重複執行此程序,直到每個矩陣中的控制目標均有至少一個控制計畫。 在Causeway的例子中,我們僅在現金收入流程的範例控制矩陣中註記兩個遺漏的控制計畫(M-1及M-2) 。 當然,可能還有其他的控制計畫。

21 評估系統流程圖 儘管到目前為止,在矩陣中所有的控制目標都對應到一個或多個控制計畫,但仍然值得再一次仔細地詳細檢查系統流程圖。
注意尋找需要更進一步控制的地方。 雖然目前在矩陣中所有的控制目標都有一個或多個對應的控制計畫,但也許必須增加更多控制計畫或加強既存的計畫,來降低某特定區域的剩餘風險至可接受程度。 這需要訓練及經驗以辨認風險及缺點 。 在第5章至第11章,你們將學習更多有關於如何進行此種關鍵性的內部控制評估。

22 資料輸入的控制計畫釋例 未使用主檔資料的資料輸入控制計畫 使用主檔資料的資料輸入控制計畫 批次輸入的資料輸入控制計畫

23 未使用主檔資料的資料輸入控制計畫 未使用主檔資料時,許多資料必須仰賴人工鍵入。由於這種資料輸入方式容易出錯,必須使用特殊的控制措施以確保控制目標的達成。 輸入時未使用主檔資料,意謂沒有資料庫可以用來驗證資料。 如此一來,使得資料輸入的控制更形重要。

24 未使用主檔資料的資料輸入

25 可使用的資料輸入控制計畫 請注意,在第一欄(資料輸入員工1)的第一個程序相關符號為「輸入文件」。
P-1:文件設計(document design) —將原始文件設計成容易填製的的格式。 P-2:簽名核准(written approval) —透過在文件上簽名或蓋章的形式,以表示某人已授權該事件。 P-3:預設的螢幕畫面(preformatted screen) —定義每個資料欄位可接受的格式,來控制資料輸入。 P-4:線上提示(online prompting) —要求使用者輸入,或提示問題要求使用者必須回答。

26 可使用的資料輸入控制計畫(續) 下一個程序相關符號(編校輸入)位於第二欄(資料輸入裝置)
P-5:程式化編校檢查(programmed edit checks) 在登錄輸入資料後,資料輸入程式立即自動執行的功能。 合理性檢查(reasonableness check)或上下限檢查(Limit check)—測試輸入資料內容(例如:數值)是否落在預先設定的範圍內。 文件或記錄雜湊總計(document/ record hash totals) —比較電腦與人工加總的數額。 計算正確性檢查(mathematical accuracy checks) —比較人工計算和電腦計算的結果,以確認文件輸入的正確性。 檢查碼核對(check digit verification)–對於識別號碼的輸入,例如客戶及供應商代碼,包含一個額外的數碼—一個檢查碼。 如果資料輸入錯誤,電腦可以檢查出檢查碼不符,發現該錯誤。

27 可使用的資料輸入控制計畫(續) P-6:被拒絕輸入資料之處理程序 —被設計來確保先前不被接受進行處理的錯誤資料,已被更正並重新輸入進行處理。
M-1:鍵入驗證 —資料由兩個人輸入,然後由電腦加以比較。

28 未使用主檔資料的輸入控制矩陣

29 使用主檔資料的資料輸入控制計畫 當目前存在主檔資料時,輸入的資料可以利用現存資料加以驗證,因此提供更多的資料輸入控制
使用主檔資料的資料輸入意謂存在資料庫。 資料庫的資料可以用來自動填入輸入表單或是比對輸入的資料。 如果我們已經有一個顧客主檔,我們即可利用客戶代碼,帶出儲存的客戶主檔資料,並判斷客戶代碼是否被正確輸入、此客戶是否存在、客戶的正確地址等。 在下一節,我們將敘述利用主檔資料於資料輸入的情況下,可適用的額外控制。

30 系統流程圖:使用主檔資料的資料輸入

31 使用主檔資料的資料輸入控制矩陣

32 使用主檔資料的資料輸入控制計畫 P-1:於鄰近原始資料產生處輸入資料。 P-2:數位簽章。
直接並即時輸入資料可以減少輸入成本,避免資料遺失,降低資料錯誤的可能性,對錯誤資料較容易更改。 線上交易登錄(OLTE)、線上及時系統(OLRT)、及線上交易處理(OLTP),均為進行此策略的例子。 P-2:數位簽章。 驗證傳送訊息者的身份並且偵測訊息在傳遞過程中已被修改。 公共金鑰加密技術的應用牽涉到使用私密金鑰對傳輸的資料加以『簽名』。

33 使用主檔資料的資料輸入控制計畫(續) P-3:利用主檔資料自動帶入輸入資料。
使用者輸入一個個體(如顧客)的識別碼,系統依據該識別碼,將該個體的相關資料由主檔中帶出。 電腦可能提示使用者輸入顧客識別碼。 系統讀取顧客主檔,自動提供諸如客戶名稱、地址、銷售人員名稱、銷售品項等資料。 這種方式減少了敲擊鍵盤次數的需求,使資料輸入更快且更有效率。 因此,系統自動的利用現存資料填入輸入欄位。

34 使用主檔資料的資料輸入控制計畫(續) 例如在輸入銷售事件時,可進行測試以判斷某客戶是否屬於某銷售人員的服務區域。.
P-4:比較輸入資料及主檔資料—系統將輸入資料與之前已記錄的主檔資料進行比對,以確保輸入的正確性與真實性 輸入/主檔資料的相依性檢查。 此編校可測試事件描述中,兩個或多個資料項目或欄位的內容,是否具有正確的邏輯關係。 例如在輸入銷售事件時,可進行測試以判斷某客戶是否屬於某銷售人員的服務區域。. 若這兩個項目比對不合,則顯示客戶代碼或銷售員身分輸入可能有錯。 輸入/主檔資料的真實性及正確性檢查。 此編校測試主檔資料是否支持輸入資料的真實性及正確性。 例如此編校會防止無相對應客戶訂單的出貨資料輸入系統。 若輸入及主檔資料比對不符,則顯示我們可能錯誤地輸入一些資料,或該出貨可能是無效的。 我們也可以將 包含於 輸入及主檔資料的項目進行比對 。

35 使用主檔資料的資料輸入控制計畫(續) P-5:被拒絕輸入資料之處理程序。 P-6:鍵入校正。 P-7:記錄輸入。 P-8:互動式回饋檢查。
此程序被設計用來確保被拒絕輸入作進一步處理的錯誤資料,已被更正並重新輸入進行處理。 P-6:鍵入校正。 員工藉由鍵入正確資料,完成被拒絕輸入資料之處理程序,因而確保輸入資料的正確性。 P-7:記錄輸入。 一旦所有必要的更正完成,使用者接受該輸入。 此動作將觸發電腦同步記錄 輸入資料於交易檔,並 通知 使用者該輸入資料已被接受。 P-8:互動式回饋檢查。 此互動式程式的特徵為告知使用者輸入資料已被接受記錄或被拒絕處理。

36 批次資料輸入 批次資料輸入社即將輸入資料累積成『批次』的工作單位,然後將各批次資料分批輸入
意謂在經濟交易事件發生與系統資料正式呈現該事件之間有所延遲。 促成以批次為重點的控制,例如批次控制總數(雜湊或其他總數)。 批次輸入之後經常會產生異常與彙總報告。 書本192頁的圖4.7是批次資料輸入的系統流程圖

37 系統流程圖:批次資料輸入

38 批次輸入控制計畫 為求有效,批次控制計畫必須確保: 所有的文件均包還在批次之中 所有的批次均送交處理 所有的批次均為電腦所接受
所有的異常都及時的察覺、調查、與更正

39 批次控制計畫 批次控制程序首先必須將事件資料分組,然後計算每一組的控制總數。可以計算的批次控制總數有數種不同的型態:
文件或記錄筆數(document/record counts) 簡單計算輸入文件的數目 (例如:一批次有25張文件)。 此程序呈現了輸入完整性控制的最低要求。 由於一張文件可能被蓄意地以另一張文件取代,此控制無法有效地確保輸入的真實性 和正確性。 項目或項數總計(item or line counts) 計算資料輸入的項目或項數數量,例如計算所有客戶匯款支付的發票數目。 藉由減少項目或整張文件可能被加入批次或未被輸入的可能性,此控制提升了輸入的真實性、完整性、及正確性。 請記得,遺漏的事件紀錄是 完整性 錯誤,於一事件紀錄中遺漏資料項目是正確性錯誤。 金額總計(dollar totals) 加總批次中以金額表示的項目,例如批次中所有匯款通知單的金額總計。 藉由減少批次中整張文件可能被加入或遺漏,或金額數目被錯誤輸入的可能性,此控制提升了輸入的真實性、完整性、及正確性。 雜湊總數(hash totals) 加總批次中存在於所有文件的數值性資料,例如匯款通知單裡,客戶編號及發票號碼的總計數。 和金額總計不同的地方在於,計算雜湊總數通常只是為了控制的目的。 雜湊總數是強而有力的批次控制,因為它們能判斷輸入是否被變更、新增、或刪除。 這些批次雜湊總數對於批次的功用,正類似於 文件或記錄雜湊總數對於個別輸入的功用。

40 批次資料輸入之控制矩陣

41 P-1:收取回送單據 回送單據(turnaround document)被用來擷取和輸入後續的事件資料。
揀貨單、存貨盤點卡、附在客戶發票上的匯款通知存根聯、工時卡等,都是回送單據的例子。 例如我們看到由電腦印出的揀貨單,利用其進行揀貨,然後送到出貨部門,掃描揀貨單上的條碼以記錄該出貨。

42 P-2:計算批次總數 計算批次總數係用來確保資料輸入來自於符合規定的事件(輸入真實性),以及批次內的所有事件均被記錄(輸入完整性)。

43 P-3:記錄揀貨單 藉由使用條碼,揀貨單被自動地記錄(掃描)於電腦內。
此程序在及時地、並使用最少資源的情況下,於數位媒介內記錄正確、有效的輸入資料。 同時,藉由電腦自動計算批次總數,也能確保輸入資料後後續調節的效率及效果。

44 P-4:人工調節批次總數 批次總數之人工調節(manual reconciliation of batch totals)控制計畫有下列幾項作業: a.首先,以人工計算一個或多個批次總數 。 b.當各個事件描述被輸入(或掃描)時,資料輸入程式累加各個獨立的批次總數。 c.在完成輸入程序、或更新程序,或兩者時,電腦產生報告 (或顯示) 有哪些相關的控制總數。 d.進行調節批次總數的人員,必須判斷為何總數會不一致,並於需要時進行更正,以確保輸入資料的完確性。

45 P-5:記錄出貨 揀貨單資料及應收帳款主檔資料被用來記錄出貨,接著更新銷售交易資料。
自動化記錄在及時地、並使用最少資源的情況下,儲存正確、真實的輸入資料。

46 P-6:調節輸入及輸出的批次總數 (批次處理前後總數核對)
此為一種核對批次總數控制的變化。 批次處理前後總數核對(agreement of run-to-run totals)將電腦處理前計算的總數,以人工的方式或藉由電腦,與電腦處理完成後的總數比對。 此資料處理後的控制,通常也會出現於錯誤及彙總報告(error and summary report)。 當總數比對一致,則顯示輸入及所進行的更新是正確的。 當處理程序從開始到結束間存有許多中間步驟,且我們想要確保每個處理程序的完確性時,此控制將特別有用。

47 P-7:比對揀貨單(從待處理檔案) 及裝箱單(一對一檢查)
此有兩個目的: 確保所有揀貨單都連結至相關的裝箱單。 確保揀貨單上的所有項目,和相關裝箱單上的項目一致。 藉由定期檢視待處理檔案(tickler file)以採取行動清除該檔案內的未處理項目,協助達成上述兩個目的。 待處理檔案也可能是反映需要完成事件的電腦紀錄,例如未結案的銷售訂單、未結案的採購訂單等。 如果待處理檔案文件停留於檔案中過久,監控此檔案的人員或電腦將判斷此延遲的性質及程度。 在我們例子裡,一旦收到裝箱單,就會運用一種叫一對一檢查(one-for-one-checking)的程序,比對揀貨單及相關的裝箱單。 如有差異,則顯示在輸入或更新時可能有錯 此程序可以詳細告知我們批次中發生錯誤之處。 由於執行此作業之成本極高,因此一對一檢查通常只被用於低數量、高價值的事件。

48 M-1:自動化連號檢查 當文件被連續地編號─不論是在文件被編製時指定一號碼,或是使用預先編號的文件,連號檢查(sequence check)能夠自動地應用於這些文件。 當我們能控制輸入程序及輸入資料(例如薪資支票)的連續編號時,批次序號檢查能發揮最大功用。 進行批次序號檢查(batch sequence check)時,批次的事件資料會依下列方式進行核對: a.輸入此批次序號範圍。 b.輸入個別的預先編號的事件資料。 c.電腦程式將事件資料依據序號排序,依序號範圍檢查各事件 資料,並報告遺失、重複、及超出範圍的事件資料。 累積序號檢查(cumulative sequence check)於序列數值被組織內單位所指定(例如:銷售訂單號碼係由銷售訂單部門所編),但後續沒有依照原本編號順序輸入(例如:揀貨單可能包含不連續的編號)的情況下,提供輸入控制。 各個事件資料(揀貨單)會與包含 所有 文件號碼的檔案(所有銷售訂單號碼)比對。 定期產生遺漏號碼的報告以供人工進一步追蹤處理。 支票簿的調節是另一個號碼(支票號碼)被依序發出的例子。 然而,當我們接到銀行對帳單時,該批次的支票可能並未完全連號。 . 我們的支票記錄單可以協助我們進行累積序號檢查,以確認所有支票都已被兌現。

49 M-2:電腦核對批次總數 此控制計畫並未存在於圖4.7,被視為一個遺漏的計畫。
電腦核對批次總數(computer agreement of batch totals)計畫繪於圖4.9,並有下列幾項作業: a.首先,以人工計算一個或多個批次總數 (即:圖4.9中的使用者部門) 。 b.接下來,人工計算的總數被輸入電腦,並被寫入電腦批次控制總數檔案。 c.當各個事件描述被輸入時,電腦程式累加個別的批次總數,並將這些總數與先前人工計算並輸入的總數比對。 d.由電腦產出報告,通常會包括各批次的明細,並顯示該總數相符或不相符。 不相符的批次通常會被拒絕,並由人工針對不一致處進行調查。

50 電腦核對批次總數


Download ppt "Ch4 控制資訊系統: 企業流程控制."

Similar presentations


Ads by Google