流程挖掘應用于內部審計的研究

付 亮

長江職業學院湖北武漢430074

流程挖掘應用于內部審計的研究

付 亮

長江職業學院湖北武漢430074

隨著新的記錄有事務日志的各種工作流管理系統的不斷開發和普及，大量流程相關數據伴隨著系統運行以日志的形式被記錄下來，可以避免人為主觀判斷偏差等，而流程挖掘正好可以對這樣的信息進行分析挖掘，因此，將流程挖掘技術引入內部審計這一領域無疑會是一次很好的嘗試。本文論述流程挖掘應用到內部審計的幾個切合點，如識關鍵控制點定位、流程中可能瓶頸、非法舞弊團隊、不合規賬號等方面的應用展開論述，并提出將傳統審計方法與模型審計相結合的新型審計，通過模型相關特性來分析業務流程中設計不太合理的地方。【關鍵詞】流程挖掘；內部審計；研究

一、流程挖掘技術在內部審計中的應用

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

二、數據采集及預處理

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

圖1 部分事務日志

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

圖2 MXML格式

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

將整合后的MXML格式日志導入Prom工具，可以看到有關日志詳細信息的界面，如圖4所示

圖4 ProM日志查看

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

圖5由實例標識索引展示的活動序列

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

三、流程模型構建

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

圖6 petri網模型

圖7 放大后的petri模型

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

利用啟發式挖掘算法，并設定好相應參數后，得到結果模型如圖8，可以看到這里計算出了模型的匹配度為大于0.9。

圖8 啟發式挖掘模型

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

圖9 模糊挖掘模型

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

四、基于模型的分析

（一）關鍵節點路徑分析

通過對圖9所示挖掘模型進行簡化，過濾掉執行次數比較少而得到包含相對執行路徑次數比較多的關鍵路徑如圖10：

圖10 路徑過濾

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

（二）流程性能分析

1.基本性能分析

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

圖11 性能分析

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

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

圖12 性能分析

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

2.瓶頸分析

為了找出影響整個流程完成時間的任務，也即分析該業務流程中可能存在的瓶頸環節，以檢測業務流程資源分配是否合理，將日志在按照Prom工具挖掘出的petri網模型上進行重演，找出影響流程效益的關鍵任務點，得到的性能序列圖如圖13：

圖13 性能序列圖

圖中顯示小方塊的地方就是一個耗時較長的block（瓶頸），不難發現，比如圖中標記的地方顯示，assess claim（索賠評估）環節出現了block（瓶頸），該環節的平均處理＞236分鐘，阻塞時間超過了11分鐘，如果這是一個對響應要求非常高的業務，那么針對這一信息，審計人員可以就此預測該業務流程運行中可能存在的風險，并在制定審計方案中重點關注。

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

五、結論

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

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

[2]王輝,楊光燦,韓冬梅.基于貝葉斯網絡的內部威脅預測研究[J].計算機應用研究.2013(09)

[3]楊姍媛,朱建明.基于內部威脅的信息安全風險管理模型及防范措施[J].管理現代化.2013(02)

[4]劉國城.BS7799標準及其在中觀信息系統審計中的運用[J].審計與經濟研究.2012(03)

[5]王會金.中觀信息系統審計風險控制體系研究——以COBIT框架與數據挖掘技術相結合為視角[J].審計與經濟研究.2012(01)

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