模型化的企業制度與流程管理系統是相對文件化的管理系統而言的。在模型化的系統中,企業所有制度和流程都在同一個管理模型中進行制定和維護,所有制度和流程的描述都采用統一的建模語言和方法,并通過此統一的建模語言和方法實現對制度和流程元素的數據化、結構化、標準化、規范化及可視化管理。
模型化的企業制度與流程管理系統的另一個特點是,管理文檔由此模型系統自動產生。比如,制度文件、流程手冊、標準作業手冊、程序文件、作業指導、崗位職責書等這些在文件化管理系統中的支撐文件,在模型化的管理系統中將只是一種輸出形式。
當然,要實現所謂的模型化管理,需要借助于最新的IT技術,簡單來說就是需要基于這種理念開發一套軟件,也就是所謂的模型化的企業制度與流程管理系統。目前絕大部分情況下,文件化的管理系統是基于微軟公司的office 系列軟件來實現的。
當企業的管理者要制定一套管理制度和流程時,如果是基于office 進行工作,那么一般會先創建一個文件夾,文件夾的名字即制度和流程的名稱。在此文件夾中,一般會先用 Visio 的格式畫一張流程圖,但流程圖并不能完全講清楚一個流程的所有詳細信息,因此我們還會寫一份制度及流程說明手冊,一般為 Word 形式。同時,我們還會建立一個子文件夾,這個子文件夾中有此制度和流程所用到的流轉表單的模板。做完上述三件事,我們就認為制定了一套制度和流程。也就是說,流程圖、制度及流程手冊、表單模板三者構成了一套制度和流程。這是典型的文件化的、離散型的制度和流程管理體系。那么,這樣的體統有什么問題呢?
如果我們需要修改某一個制度和流程,比如我們改了流程圖中某一流程結點的名稱和相應的崗位以及所用表單,流程手冊和表單模板并不會自動更正,而是需要人工一一加以修改。當制度和流程很多時,這種一致性往往就會出現問題。這種修改其實也是一種信息的重復錄入工作,是一種不增值卻又增加錯誤機率的簡單勞動。
另外,不同的人在描述相同的制度和流程時,或者同一批人在不同的時間點描述同一個制度和流程時,由于沒有一套強制性的業務描述規范,就會出現描述的差異。比如,同樣對于“供應商詢價”這個結點,有的時候可以描述成“向供應商詢問材料價格”,有的時候可以描述成“向供應商詢價”,而完成此事的崗位又可以描述成“采購助理”或“采購業務助理”。之后,當不同的人來讀這兩個結點時就會產生不同的理解。有的人可能會認為“采購助理”和“采購業務助理”是同一個崗位,有的人可能會認為是兩個不同的崗位。如果IT人員基于此開發系統,就會出現是設定兩個不同的角色并配以兩套不同的權限,還是同一個角色匹配一套權限的差異。另外,由于沒有強制的規范性的描述,各部門間或業務人員與IT人員在討論同一個管理節點時,往往會發生“各說各話”的現象,都認為對方懂了,但其實大家說的是兩回事。
還有,文件化的管理體系,沒有體現管理要素間的關聯,而實際上這些要素是緊密聯系在一起的。比如,描述完一套采購部門的管理制度和流程后,如果我們想要知道在這套管理體系中,究竟涉及多少崗位,每個崗位涉及多少流程,如果我們想出具一套采購部門各崗位的職責及操作說明,通常需要根據這套文檔重新進行整理,不能直接獲得這些原本已存在的信息。
那么,模型化的管理系統又是如何工作的呢?基于模型化的工具描述制度和流程時,除了強調所有的人都連到同一個服務器和同一個數據庫,用同一套軟件進行工作外,更為主要的是,還強調大家都必須采用統一的建模語言進行描述。比如,我們需要對采購部門的制度和流程進行梳理,那么我們不是直接繪制采購部門的流程圖或直接寫制度。我們要做的第一步是將業務流程分解為組織、功能、數據和產品及服務四大一級要素。我們首先對此四大一級要素進行描述。具體做法是,先建立采購部的組織結構模型,可以詳細到具體崗位甚至個人。這一步一般都比較容易完成。第二步,是基于崗位描述清楚每個崗位的工作。具體操作是發一套調研表,要求各崗位的人員填寫自已每天都做一些什么事,有什么職責,同時完成這些工作需要什么樣的輸入信息并且會輸出什么信息。一般來說,所謂的信息是精細到表單這一層,即輸入什么表單,輸入什么表單,包括這些表單是書面文檔形式還是電子格式的表單,如果是電子格式的表單還需要注明是在什么信息化系統中的表單。將這些信息收集上來后,將這些信息分別梳理成功能視圖,即采購部的業務工作分為幾大類,每一類又具體做一些什么事;數據視圖,即采購部究竟用到哪些表單,這些表單的分類及存在形式。第三步,我們還要梳理出所謂的產品和服務視圖,即采購部具體對其它部門或者對外提供什么樣的輸出。這些輸出是整個采購部門所有工作的價值和目的。
完成上述步驟后,我們相當于梳理出了組織、功能、數據和產品及服務四套搭建制度和流程的“標準積木”,也就是先制定了一套“普通話”規范。接下來,我們才開始搭建采購部的制度和流程。具體做法是讓采購各相關業務人員連到同一臺服務器和同一個數據中,從已經事先輸入系統的組織、功能、數據、產品和服務四套“積木”中選用自已需要的“積木塊”來搭建管理體系。這個過程,不允許采購業務人員直接“畫流程”或“寫制度”,而是只允許“搭建”。此時,必然會發生在某一套“積木”中找不到自已所需要的“積木塊”的情況,比如某一崗位的業務人員認為需要由“采購業務助理”來完成,但找遍“采購部組織”這套“積木”也找不到“采購業務助理”這個“積木塊”。此時,這位業務人員必須向主管部門提出“更改需求”,即要求在組織視圖中加入“采購業務助理”這個崗位,才能繼續他的流程搭建工作。通過這個環節的控制,不但規范了建模語言,確保大家用同一套規范,同時又梳理了一遍流程。這就是“建模”和“畫”或 "寫" 之間的區別。另外,通過這種流程建模的方式才能確保所謂的制度和流程梳理能夠精細到流程的每一個節點和要素。
核心關注:拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理,全面涵蓋了企業關注ERP管理系統的核心領域,是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處:拓步ERP資訊網http://www.hanmeixuan.com/
本文標題:模型化企業制度及流程管理系統
本文網址:http://www.hanmeixuan.com/html/consultation/1081963059.html