流程挖掘應(yīng)用于內(nèi)部審計(jì)的研究

付 亮

長(zhǎng)江職業(yè)學(xué)院湖北武漢430074

流程挖掘應(yīng)用于內(nèi)部審計(jì)的研究

付 亮

長(zhǎng)江職業(yè)學(xué)院湖北武漢430074

隨著新的記錄有事務(wù)日志的各種工作流管理系統(tǒng)的不斷開發(fā)和普及，大量流程相關(guān)數(shù)據(jù)伴隨著系統(tǒng)運(yùn)行以日志的形式被記錄下來，可以避免人為主觀判斷偏差等，而流程挖掘正好可以對(duì)這樣的信息進(jìn)行分析挖掘，因此，將流程挖掘技術(shù)引入內(nèi)部審計(jì)這一領(lǐng)域無疑會(huì)是一次很好的嘗試。本文論述流程挖掘應(yīng)用到內(nèi)部審計(jì)的幾個(gè)切合點(diǎn)，如識(shí)關(guān)鍵控制點(diǎn)定位、流程中可能瓶頸、非法舞弊團(tuán)隊(duì)、不合規(guī)賬號(hào)等方面的應(yīng)用展開論述，并提出將傳統(tǒng)審計(jì)方法與模型審計(jì)相結(jié)合的新型審計(jì)，通過模型相關(guān)特性來分析業(yè)務(wù)流程中設(shè)計(jì)不太合理的地方?！娟P(guān)鍵詞】流程挖掘；內(nèi)部審計(jì)；研究

一、流程挖掘技術(shù)在內(nèi)部審計(jì)中的應(yīng)用

過程挖掘技術(shù)為內(nèi)部審計(jì)提供了一種更嚴(yán)格的檢查流程符合性和確定流程有效性的手段，審計(jì)人員可以避免因抽取樣例而出現(xiàn)漏審或者為避免漏審而大量抽樣導(dǎo)致審計(jì)的復(fù)雜度劇增的情況。引入流程挖掘技術(shù)，審計(jì)人員可以將業(yè)務(wù)執(zhí)行整個(gè)過程中的所有實(shí)例都考慮在列，在更短的時(shí)間內(nèi)做出更可靠的判斷，可以將現(xiàn)有審計(jì)方法與模型審計(jì)結(jié)合起來，大大縮小日志范圍，便于進(jìn)一步的分析，例如專案審計(jì)。事件日志和過程挖掘技術(shù)使得新形式的審計(jì)成為可能，有理由相信，基于事件日志的流程挖掘技術(shù)審計(jì)將極大地改變審計(jì)行業(yè)，主要體現(xiàn)在以下兩個(gè)方面：（1）關(guān)鍵控制點(diǎn)定位，流程中可能瓶頸發(fā)現(xiàn)。審計(jì)人員還可以基于事件日志數(shù)據(jù)對(duì)現(xiàn)有模型從新的方面進(jìn)行擴(kuò)展，比如通過綜合考慮到每個(gè)活動(dòng)（任務(wù)）執(zhí)行開始時(shí)間以及持續(xù)時(shí)間，來分析得到流程中各活動(dòng)執(zhí)行相關(guān)性能數(shù)據(jù)而找出所有可能存在的瓶頸，例如出現(xiàn)某些對(duì)響應(yīng)要求特別高的業(yè)務(wù)在某個(gè)任務(wù)執(zhí)行或者等待時(shí)間相對(duì)較長(zhǎng)的情況下，審計(jì)人員可以根據(jù)實(shí)際情況以及專業(yè)能力來判斷其中哪些應(yīng)該列為關(guān)鍵控制點(diǎn)予以重視。（2）多角度審計(jì)。多角度流程挖掘技術(shù)必然導(dǎo)致促進(jìn)多角度審計(jì)實(shí)現(xiàn)，比如權(quán)限或非法操作問題，基于組織視角，有利于發(fā)掘出組織中各員工（操作者）間的相互聯(lián)系，如親密度，來識(shí)別可能的非法舞弊團(tuán)隊(duì)，又或者有的組織管理比較混亂，往往出現(xiàn)多個(gè)員工使用同一管理員賬號(hào)登入系統(tǒng)操作，導(dǎo)致潛在的風(fēng)險(xiǎn)加劇，而審計(jì)人員往往很容易忽視這一現(xiàn)象或者很難發(fā)現(xiàn)相關(guān)證據(jù)，通過流程挖掘算法分析，可以很容易找出與其他員工執(zhí)行任務(wù)存在差異的特殊“員工”，結(jié)合組織結(jié)構(gòu)圖和實(shí)地調(diào)查即可很容易做出判斷，是否該“員工”賬戶存在共享的情況。此外，從審計(jì)人員還可以通過基于歷史數(shù)據(jù)構(gòu)建的流程模型進(jìn)行預(yù)測(cè)，比如，結(jié)合一些經(jīng)典的數(shù)據(jù)挖掘算法，來預(yù)測(cè)某個(gè)活動(dòng)還需多長(zhǎng)時(shí)間完成，或者會(huì)出現(xiàn)的結(jié)果，以此提出建議，最小化預(yù)期成本。

二、數(shù)據(jù)采集及預(yù)處理

我們以某保險(xiǎn)公司索賠業(yè)務(wù)處理流程為例，該項(xiàng)業(yè)務(wù)是用來處理國(guó)內(nèi)索賠問題，各種類型的保險(xiǎn)索賠均經(jīng)由電話進(jìn)行提交，由兩個(gè)獨(dú)立的呼叫中心call centre agent brisbane和all centre agent sydney（簡(jiǎn)記為B和S）各自運(yùn)營(yíng)的組織提供支持，兩中心在來電量和平均呼叫處理時(shí)間方面是相似的，但在代理的部署方式、底層IT系統(tǒng)上存在差異。通過抽取的日志中包含3512例索賠案例（也即前邊提到的過程實(shí)例）共涉及46138個(gè)事件（即記錄數(shù)），這里我們選取必要的幾個(gè)字段進(jìn)行挖掘，而選擇忽略其他屬性字段，當(dāng)然，如果我們獲取的數(shù)據(jù)足夠豐富，那么還可以基于其他字段做更多擴(kuò)展分析，如分析某個(gè)流程分支處分支的原因，也即影響流程選擇其中某一個(gè)子流程繼續(xù)的潛在因素，可以嘗試引入數(shù)據(jù)挖掘中經(jīng)典的決策樹分析算法來進(jìn)行操作，這里由于數(shù)據(jù)限制，我們選擇的字段包括：事件所屬實(shí)例標(biāo)識(shí)（case ID）、事件名（activity）、執(zhí)行人（resource）、事件開始事件（starttimestamp）以及事件完成時(shí)間（complete timestamp）。部分?jǐn)?shù)據(jù)源日志數(shù)據(jù)如圖1所示：

圖1 部分事務(wù)日志

為了使構(gòu)建的模型更加準(zhǔn)確，我們需要首先將日志文件進(jìn)行預(yù)處理，包括日志過濾以及對(duì)于多個(gè)日志文件進(jìn)行整合，整合時(shí)可以使用ProMimport工具將整合后的日志文件以MXML（mining xml format）的格式輸出，特別對(duì)于數(shù)據(jù)來源于某個(gè)數(shù)據(jù)庫中多個(gè)表的情況以及多個(gè)數(shù)據(jù)庫時(shí)，我們采用ProMimport工具可以進(jìn)行很方便的整合轉(zhuǎn)換處理，以MXML格式將整合后的日志用一個(gè)MXML格式文件輸出。一個(gè)MXML文件可以存儲(chǔ)大量的流程信息，其典型結(jié)構(gòu)如圖2，接下來的挖掘分析工作將利用ProM平臺(tái)下集成的各類算法插件以及Disco工具完成,轉(zhuǎn)化后的部分日志截圖如圖3：

圖2 MXML格式

每一個(gè)processInstance標(biāo)識(shí)的地方代表一個(gè)事件序列，其中的id號(hào)為標(biāo)識(shí)一個(gè)事件序列，該事件序列中事件成員即通過該標(biāo)識(shí)來識(shí)別，換句話說，具有相同該id號(hào)的事件屬于同一個(gè)事件標(biāo)識(shí)。每一個(gè)processInstance由多個(gè)auditTrail-Entry組成，一個(gè)auditTrailEntry代表記錄中的一條事件記錄，它由data、workflowmodel、ElementType、Timestamp、originator組成，data部分描述了諸如activity、resource、costs等事件屬性，workflowmodel描述了事件名，ElementType描述了該事件所處狀態(tài)，一般包含兩種狀態(tài)，一種為start（開始）狀態(tài)，另外一種為complete（結(jié)束）狀態(tài)。這樣記錄的好處在于，分析的時(shí)候可以很清晰的分清楚什么時(shí)候事件開始，什么時(shí)候事件結(jié)束，由此得出事件等待時(shí)間和處理時(shí)間，使分析更精準(zhǔn)細(xì)致。Timestamp描述了該事件該種狀態(tài)（開始或結(jié)束）時(shí)的具體時(shí)間，originator記錄了該事件的操作者是誰。比如我們看圖3的最前邊一個(gè)事件記錄，它代表的意思為該事件有三個(gè)屬性：activity、resource和costs。Activity（活動(dòng)名）是register request（注冊(cè)申請(qǐng)），resource（執(zhí)行者）是Pete，costs（開銷）為50，當(dāng)前事件名為registerrequest，事件所處狀態(tài)為complete（完成）狀態(tài)，所處時(shí)間timestamp為2010年12月30日14點(diǎn)32分，處理人是Pete。這樣就詳細(xì)描述了一條事件記錄，接下來以auditTrailEntry開頭再描述另外一個(gè)事件，直到id為3的所有事件被描述完，再接著描述另一個(gè)以processInstance開頭、id標(biāo)識(shí)的另一個(gè)事件序列。

將整合后的MXML格式日志導(dǎo)入Prom工具，可以看到有關(guān)日志詳細(xì)信息的界面，如圖4所示

圖4 ProM日志查看

從中可以看到，該日志總共包含一個(gè)processes（流程），3512個(gè)cases（案例）共46138個(gè)events（事件條數(shù)）也即記錄條數(shù)，共有21個(gè)不同event classes（事件類），event types（事件類型）為2種（這里代表start和complete兩狀態(tài)），orginators（執(zhí)行者）有四種。從右側(cè)的柱狀圖可以發(fā)現(xiàn)，每個(gè)案例均至少包含5個(gè)事件，最多情況下包含17個(gè)，平均包含13個(gè)事件。具體每個(gè)案例中事件個(gè)數(shù)及事件發(fā)生先后序列也即事件序列見圖5：

圖5由實(shí)例標(biāo)識(shí)索引展示的活動(dòng)序列

圖5 中標(biāo)有“0”的地方，代表的是編號(hào)為0的索賠案例，從圖形右側(cè)可以看到它包含9個(gè)事件，所有事件序列包含的事件情況有incoming claim（complete狀態(tài)）、B check if sufficientinformationisavailable（start和complete兩狀態(tài)）、B registerclaim（start和complete兩狀態(tài)）等，對(duì)于每個(gè)事件這里清晰的列出了與之相關(guān)的信息，以B registerclaim（start）為例，代表該事件當(dāng)前處于start狀態(tài)，該狀態(tài)下的時(shí)間為1970年1月1日8點(diǎn)，該事件的處理者為callcentre agentbrisbane。接下來的分析將借用Prom中集成的各種算法插件以及Disco完成。

三、流程模型構(gòu)建

使用算法進(jìn)行挖掘，挖掘出的模型用Petri表示，如圖6為了便于分析，局部放大后得到圖7：

圖6 petri網(wǎng)模型

圖7 放大后的petri模型

從中可以看到該業(yè)務(wù)流程為：當(dāng)一起索賠案例發(fā)生后，會(huì)由S或者B來執(zhí)行檢查（基于足夠的信息），如果是S做的檢查，接下來它會(huì)有三種選擇，如可以選擇直接結(jié)束案例，也可以是提出索賠（registerclaim），如果S執(zhí)行完提出索賠，則需要等到B也執(zhí)行完了提出索賠后，才能進(jìn)行下一步：確定索賠的可能性，之后可能會(huì)執(zhí)行索賠評(píng)估（assess claim），等等。

利用啟發(fā)式挖掘算法，并設(shè)定好相應(yīng)參數(shù)后，得到結(jié)果模型如圖8，可以看到這里計(jì)算出了模型的匹配度為大于0.9。

圖8 啟發(fā)式挖掘模型

將抽取出的10002條記錄共包含1423條case（事件）序列導(dǎo)入Disco，利用模糊挖掘算法得到的挖掘模型如圖9所示：

圖9 模糊挖掘模型

圖中可見每個(gè)節(jié)點(diǎn)的平均執(zhí)行次數(shù)，連接箭頭上的數(shù)字代表該路徑執(zhí)行次數(shù)，例如節(jié)點(diǎn)incoming claim（索賠傳入）共執(zhí)行了1423次，也即每一條case序列都執(zhí)行了該節(jié)點(diǎn)，1423次中B checkifsufficientinformationisavailable（B檢查資料是否齊全）和S check if sufficient information is available（S檢查資料是否齊全）分別執(zhí)行了713和710次，相差無幾。B check執(zhí)行完的713次接下來分為兩個(gè)子流程，其中79次是直接到end（結(jié)束），另外634次是走到了B register claim（B提起索賠），從incoming claim到B check這條路徑共被執(zhí)行了713次。從incoming claim到S check這條路徑共被執(zhí)行了710次，以此類推。這里展現(xiàn)出來的是包括所有的路徑和流程活動(dòng)情況，可以很清晰的觀察出哪些路徑執(zhí)行的次數(shù)相對(duì)少，而哪些路徑相對(duì)多，比如，除去開始事件incoming claim和結(jié)束事件end之后，執(zhí)行最多的事件要數(shù)determine likelihood of claim（判斷索賠可能性），共執(zhí)行了1198次；執(zhí)行最多的路徑為determinelikelihood ofclaim（判斷索賠可能性）到accessclaim（索賠評(píng)估），共執(zhí)行了988次；執(zhí)行最少的事件為S register claim（S提起索賠），共執(zhí)行了564次，相應(yīng)的執(zhí)行路徑最少的為Bcheckifsufficientinformationisavailable（S檢查資料是否齊全）到end，共執(zhí)行了79次。具體到審計(jì)工作而言，類似審核審批的活動(dòng)必然會(huì)相對(duì)較多一點(diǎn)，如果審計(jì)人員發(fā)現(xiàn)類似該種類的活動(dòng)執(zhí)行次數(shù)相對(duì)總的執(zhí)行路徑條數(shù)有一定差距時(shí)，就需要給予關(guān)注了，可能該流程的完整程度或者說控制程度有所欠缺，極有可能導(dǎo)致控制失敗，應(yīng)記錄為潛在風(fēng)險(xiǎn)點(diǎn)。此外，也應(yīng)考慮到另一極端，那就是對(duì)于一些執(zhí)行次數(shù)相對(duì)較少的點(diǎn)或者路徑也要給予關(guān)注，可能是某些人利用系統(tǒng)漏洞來進(jìn)行非法操作所在，應(yīng)具體就實(shí)際情況做記錄并分析。

四、基于模型的分析

（一）關(guān)鍵節(jié)點(diǎn)路徑分析

通過對(duì)圖9所示挖掘模型進(jìn)行簡(jiǎn)化，過濾掉執(zhí)行次數(shù)比較少而得到包含相對(duì)執(zhí)行路徑次數(shù)比較多的關(guān)鍵路徑如圖10：

圖10 路徑過濾

可以看到經(jīng)過濾后的關(guān)鍵路徑為，首先是incomingclaim (傳入索賠)，緊接著要選擇A和S中一個(gè)中心來審核數(shù)據(jù)是否充分（B check或Scheck），并各自registerclaim（登記索賠）后determine likelihood of claim(給出索賠可能性報(bào)告)，然后經(jīng)過assess claim(索賠評(píng)估)步驟后，下一步advise claiment on reimbursement(建議申請(qǐng)賠償)，再下一步就需要initiate payment(初始化賠償)，最后close claim(關(guān)閉索賠)end(結(jié)束)整個(gè)流程。那么，具體到實(shí)際內(nèi)部審計(jì)中，我們需要關(guān)注哪些環(huán)節(jié)必須要有而不存在關(guān)鍵路徑上的情況，也即缺失明顯的審核檢查流程，從而導(dǎo)致舞弊風(fēng)險(xiǎn)加劇，又或者哪些少量理應(yīng)不該直接跨越的路徑的存在，很有可能是某些違規(guī)操作的路徑所在，而應(yīng)給予重視。

（二）流程性能分析

1.基本性能分析

將日志采用Prom提供的性能分析算法進(jìn)行挖掘后，得到圖11（時(shí)間單位為小時(shí)）

圖11 性能分析

從中可以獲知每個(gè)任務(wù)的執(zhí)行時(shí)間和等待時(shí)間信息，如close claim（索賠關(guān)閉）這一事件，平均處理時(shí)間為0.008（小時(shí)），該事件出現(xiàn)頻數(shù)為1976次，最少處理時(shí)間為0（小時(shí)），處理時(shí)間中數(shù)為0.006（小時(shí)），最長(zhǎng)處理時(shí)間為0.057（小時(shí)），平均等待時(shí)間為0（小時(shí)），最短等待時(shí)間為0（小時(shí)），最長(zhǎng)等待時(shí)間為0（小時(shí)）。從圖中可見數(shù)據(jù)可以發(fā)現(xiàn)，平均處理時(shí)間最長(zhǎng)的事件為B register claim（B索賠注冊(cè)）為0.144（小時(shí)），平均等待時(shí)間最長(zhǎng)的事件為determine likelihoodofclaim（判斷索賠可能性）達(dá)2.861小時(shí)，進(jìn)一步觀察可以發(fā)現(xiàn)該事件最少等待時(shí)間為2.193小時(shí)，等待時(shí)間中數(shù)為2.39小時(shí)，最長(zhǎng)等待時(shí)間為10.309小時(shí)，說明之所以平均等待時(shí)間過長(zhǎng)是由于有少數(shù)幾次等待時(shí)間過長(zhǎng)的現(xiàn)象存在，具體到審計(jì)工作中，基于這一點(diǎn)應(yīng)進(jìn)一步展開分析，提取出處理時(shí)間相對(duì)大于等待時(shí)間中數(shù)小于最大等待時(shí)間的事件和事件序列，展開調(diào)查，分析可能原因。再來比較A、B兩個(gè)呼叫中心，可以很明顯的發(fā)現(xiàn)，在處理時(shí)間上，兩者沒有太大差別，而在等待時(shí)間上，B平均為0.632（小時(shí)）遠(yuǎn)遠(yuǎn)高于A的0.119（小時(shí)），建議保險(xiǎn)公司將此情況反映給B呼叫中心，促進(jìn)其分析可能的原因并做出改進(jìn)，出于盡最大努力滿足客戶的需要，如果B的等待時(shí)間遠(yuǎn)遠(yuǎn)長(zhǎng)于A的情況持續(xù)存在，沒有得到改善，那么可以有選擇性的將更多或者部分重要客戶的理賠案例通過A中心進(jìn)行。

將抽取的10003條記錄用Disco進(jìn)行性能分析后得到圖12

圖12 性能分析

從圖中可以看出，B check事件（信息充分提供后B中心完成檢查）平均用時(shí)29.2秒，S check事件（信息充分提供后S中心完成檢查）平均用時(shí)31秒；B register claim（B中心提出索賠）平均耗費(fèi)時(shí)間為8.5分，S register claim（S中心提出索賠）平均耗時(shí)8.3分。由此驗(yàn)證兩中心B中心和S中心確實(shí)在處理能力上相當(dāng)。這里有很多等待時(shí)間和處理時(shí)間為instant（及時(shí)）狀態(tài)的事件，如B register claim和S register claim的等待時(shí)間，assess claim的等待時(shí)間等。處理時(shí)間上基本上都有耗費(fèi)一定時(shí)間（出去首尾事件incoming claim和end事件），耗費(fèi)處理時(shí)間最短的是B check事件，用時(shí)29.2秒，耗費(fèi)處理時(shí)間最長(zhǎng)的是assess claim，耗時(shí)10.9分鐘，耗費(fèi)等待時(shí)間最長(zhǎng)的前兩位分別為B registerclaim（B注冊(cè)索賠）到determine likelihood of claim（判斷索賠可能性）和S registerclaim（S注冊(cè)索賠）到determinelikelihood ofclaim（判斷索賠可能性），分別高達(dá)3小時(shí)和3.2小時(shí)。說明在有關(guān)任務(wù)接洽上存在明顯的缺陷，部分流程受阻導(dǎo)致整體效能急劇下降，很有可能因此耽誤總體工作而導(dǎo)致重要客戶流失。通過對(duì)流程各節(jié)點(diǎn)執(zhí)行時(shí)間的分析，可以準(zhǔn)確定位出影響整個(gè)流程的主要延遲點(diǎn)所在，審計(jì)過程中將那些執(zhí)行時(shí)間相對(duì)長(zhǎng)的節(jié)點(diǎn)應(yīng)給予相對(duì)高的重視，記錄下來作為整個(gè)審計(jì)工作中的重要關(guān)注點(diǎn)，也即風(fēng)險(xiǎn)點(diǎn)。

2.瓶頸分析

為了找出影響整個(gè)流程完成時(shí)間的任務(wù)，也即分析該業(yè)務(wù)流程中可能存在的瓶頸環(huán)節(jié)，以檢測(cè)業(yè)務(wù)流程資源分配是否合理，將日志在按照Prom工具挖掘出的petri網(wǎng)模型上進(jìn)行重演，找出影響流程效益的關(guān)鍵任務(wù)點(diǎn)，得到的性能序列圖如圖13：

圖13 性能序列圖

圖中顯示小方塊的地方就是一個(gè)耗時(shí)較長(zhǎng)的block（瓶頸），不難發(fā)現(xiàn)，比如圖中標(biāo)記的地方顯示，assess claim（索賠評(píng)估）環(huán)節(jié)出現(xiàn)了block（瓶頸），該環(huán)節(jié)的平均處理＞236分鐘，阻塞時(shí)間超過了11分鐘，如果這是一個(gè)對(duì)響應(yīng)要求非常高的業(yè)務(wù)，那么針對(duì)這一信息，審計(jì)人員可以就此預(yù)測(cè)該業(yè)務(wù)流程運(yùn)行中可能存在的風(fēng)險(xiǎn)，并在制定審計(jì)方案中重點(diǎn)關(guān)注。

而對(duì)Disco而言，圖12已經(jīng)很清晰的反映出瓶頸點(diǎn)，圖中每個(gè)節(jié)點(diǎn)、路徑均標(biāo)出了平均執(zhí)行時(shí)間。如B registerclaim平均耗時(shí)達(dá)8.5分鐘，assessclaim（索賠評(píng)估）達(dá)到了平均10.9分鐘（與Prom分析的結(jié)果正好相互驗(yàn)證），而路徑上的瓶頸處在于B中心和S中心提出索賠后到determinelikelihood of claim（確定索賠可能性）耗費(fèi)時(shí)間相當(dāng)長(zhǎng)，分別達(dá)到了平均一次需要3小時(shí)和3.2小時(shí)，極大的拖后了整個(gè)流程的執(zhí)行時(shí)間，成為整個(gè)索賠流程的主要滯后點(diǎn)，也即瓶頸點(diǎn)所在，如果能夠針對(duì)這種情況再進(jìn)一步深入進(jìn)去調(diào)研出現(xiàn)該子流程滯留的原因分析，是什么因素導(dǎo)致該子流程執(zhí)行時(shí)間如此慢，是因?yàn)槿耸植粔蜻€是重視程度不夠，還是環(huán)節(jié)上設(shè)計(jì)本身不太合理，如工作量太多，資源配置結(jié)構(gòu)不相匹配等，從而積極改進(jìn)，如有沒有別的方法來加快該進(jìn)程，或者如何有效的將整個(gè)索賠可能性確認(rèn)工作分給多個(gè)部門協(xié)作，加快進(jìn)程等將可以很好的改善整個(gè)流程的總體質(zhì)量。

五、結(jié)論

應(yīng)用流程挖掘技術(shù)可從系統(tǒng)日志中提取被記錄的業(yè)務(wù)活動(dòng)，將這類信息按照固定格式進(jìn)行收集和整理后,形成可以被分析利用的事件日志，再結(jié)合一定的模型進(jìn)行表示與分析，避免了管理者對(duì)流程運(yùn)行過程的主觀理解乃至錯(cuò)誤認(rèn)識(shí)，將流程挖掘技術(shù)應(yīng)用于內(nèi)部審計(jì)中，不僅能夠?qū)崿F(xiàn)對(duì)現(xiàn)有內(nèi)部控制流程中存在的漏洞與缺陷進(jìn)行更全面地識(shí)別與定位，同時(shí)也可以減少因管理者對(duì)流程運(yùn)行過程的主觀理解而導(dǎo)致的審計(jì)失敗，通過將基于模型審計(jì)與當(dāng)前審計(jì)方法相結(jié)合，極大提高內(nèi)部審計(jì)質(zhì)量的同時(shí)，也能促進(jìn)審計(jì)風(fēng)險(xiǎn)防范能力，將內(nèi)部審計(jì)由事后查錯(cuò)向事前、事中轉(zhuǎn)變，使內(nèi)部審計(jì)能更好地發(fā)揮包括“免疫系統(tǒng)”在內(nèi)的更多功能。

[1]王紅霞,景波.多維數(shù)據(jù)聚類技術(shù)在電子政務(wù)審計(jì)分層抽樣中的應(yīng)用研究[J].商業(yè)會(huì)計(jì).2014(01)

[2]王輝,楊光燦,韓冬梅.基于貝葉斯網(wǎng)絡(luò)的內(nèi)部威脅預(yù)測(cè)研究[J].計(jì)算機(jī)應(yīng)用研究.2013(09)

[3]楊?yuàn)欐?朱建明.基于內(nèi)部威脅的信息安全風(fēng)險(xiǎn)管理模型及防范措施[J].管理現(xiàn)代化.2013(02)

[4]劉國(guó)城.BS7799標(biāo)準(zhǔn)及其在中觀信息系統(tǒng)審計(jì)中的運(yùn)用[J].審計(jì)與經(jīng)濟(jì)研究.2012(03)

[5]王會(huì)金.中觀信息系統(tǒng)審計(jì)風(fēng)險(xiǎn)控制體系研究——以COBIT框架與數(shù)據(jù)挖掘技術(shù)相結(jié)合為視角[J].審計(jì)與經(jīng)濟(jì)研究.2012(01)

付亮（1976-），女，湖北宜昌人，碩士，經(jīng)濟(jì)師。研究方向：經(jīng)濟(jì)管理。