Skip to content

{ Category Archives } BPM

流程為王,企業應用系統對比實現,活動的基本形式及可用資源(修訂)

由於太多新興的工具出現,使基於網絡的協作與交流形式發生了質的飛躍,故將之前的對比交流活動的基本組織形式做出修訂:         建議采用這樣的流程:即,我們先將要討論的業務流程主題、業務場景描述、BPMN2.0規範的業務流程圖、時間安排等相關要素以Moxtra活頁夾文件的形式公示,有興趣參與本主題流程在線交流的人員可加入相關Moxtra主題,實際的對比交流活動將通過Moxtra多媒體在線會議的形式進行,會議之前我們將會議安排等諸要素在Moxtra Notes形式列示,我們也會通過微信朋友圈將相關信息發布,對於不方便參與的興趣人士,我們將在Moxtra活頁夾或微信朋友圈中提供在線交流活動錄製回放的鏈接地址;         做為對比交流活動的成果記錄,各參與對比系統的主導人士有責任將交流活動的成果以WIKI或部落格的方式記錄於確定位置,這也是我們搞交流活動的初衷之一,即,將各商業系統成熟的產品化特質及業務流程本地實現經驗進行分享。 對比交流活動的可用資源: BPMN2.0: Business Process Model And Notation                                          http://www.omg.org/spec/BPMN/2.0/ Aris Express: Business Process modeling Tool (Free Software)                 […]

流程為王,企業應用系統對比實現,活動基本形式及可用資源

對比交流活動的基本組織形式:         建議采用這樣的流程:即,我們先將要討論的業務流程主題、業務場景描述、BPMN2.0規範的業務流程圖、時間安排等相關要素以論壇發貼和微博的形式公示,有興趣參與本主題流程在線交流的人員將報名郵件發送到確定郵箱,實際的對比交流活動將通過多媒體在線會議的形式進行,會議之前我們將會議安排等諸要素通過諸位報名所留郵箱發送到參與者處,我們也會通過微博將相關信息發布,對於不方便參與的興趣人士,我們將在微博或論壇中提供在線交流活動錄製回放的鏈接地址;         通過在線交流活動,我們可將流程所涉及到的關鍵環節及未決問題,以論壇或微博發貼的形式將總是歸納提出,對這些問題有見解的興趣人士可以跟貼或微博互動,這些資訊也將在微信朋友圈中公開討論,發揮社交網絡的集群及微信的及時便捷溝通效力,以期望在更大的範圍內討論問題,並求解;         做為對比交流活動的成果記錄,各參與對比系統的主導人士有責任將交流活動的成果以WIKI或博客的方式記錄於確定位置,這也是我們搞交流活動的初衷之一,即,將各商業系統成熟的產品化特質及業務流程本地實現經驗進行分享。 對比交流活動的可用資源: BPMN2.0: Business Process Model And Notation                                          http://www.omg.org/spec/BPMN/2.0/ Aris Express: Business Process modeling Tool (Free Software)         […]

流程為王,企業應用系統對比實現,對比活動的運作方式

對比活動的運作方式:         企業的戰略流程,屬於宏觀規劃與企業架構的範疇,比較不容易接觸到細節的流程運作,故我們將研討的時序倒置,即先從企業的一般運作如手,以一個製造企業集團為藍本,勾勒出企業運作的基本流程類目,從研發、製造、銷售、物料管理、服務、財務會計、成本會計(控制)、分析等大類入手,進而對大類按業務運作的最佳實踐進一步細分,如針對研發大 類,我們可以細分為:參考與模擬成本核算、內部產品開發等具體的業務流程,從這一層級的業務流程上展開討論;         根據對比活動採用的解決方案量級不同,相關業務流程的實現完整性亦各不相同,由於我們此次交流活動並不以解決方案PK為目的,故對於不同的系統應給出合理的適用於流程落地方案與建議為宜,原因是企業的情況千差萬別,根本不會有放之四海皆准的解決之道;另外一個最基本的認識是,流程之於企業,並不一定完全的自動化與計算機化,有人參與的流程節點,也應是業務流程討論的範疇;         根據之前相關交流活動的經驗,此次對比交流活動將圍繞最佳業實踐的方式展開,即,每一次線上交流活動之前,我們將需要討論的具體最佳實踐流程以BPMN2.0規範繪製成圖,並對本業務實踐場景做出概括性描述,如:用途、優勢、包括的關鍵處理流程、需要的參與流程的公司角色等信息,各解決方案在描述實現時,盡量提供本業務流程所涉及到的諸如:主數據與組織數據、流程前續業務條件、角色、流程步驟(如果條件允許,最好可以在系統中實現流程步驟的演示)、後續流程等相關主題的分享;         在對比交流過程中,參與方將學習或精化對業務流程最基本的描述方法,從國際合規角度考慮,我們採用BPM業界通用的BPMN2.0規範,做為我們的流程描述方式,當然,對其它流程表達方法諸如:EPC(Event-driven process chain)方法有了解的參與者,也可以貢獻以EPC描述業務的文檔;另外,之前我們提到,我們是以時序倒置的方式,即先從企業運營層面的流程入手展開討論,涉及到企業高階的諸如戰略流程討論、企業架構討論也應穿插於討論主題之中一並呈現,故,各參與人員應對企業管理的一般性理論有所了解,以製造業為例,我們應對諸如:六西格馬、精益製造等理論,以及如:價值流圖、因果圖等相關工具有一定了解,原因在於,企業的戰略管理,更多的是組織戰略方向界定、戰略組織結構建模、戰略流程的梳理與建模,基於各模型的分析及模擬運行等等,故應對戰略層面問題,除豐富的行業業務經驗與大局觀之外,掌握前述的理論、工具與分析方法必定會如虎添翼。 請持續關注交流活動的基本形式及日程安排主題。

流程為王,企業應用系統對比實現 ,在線交流活動即將啟程

比較活動的願景:         這是一個數據爆發的時代,每一個身處其中的人,都自覺不自覺地成為數據的提供者與消費者;而貫穿始終的,則是流程!         端到端的流程是一切機構運作的核心,無論企業、科學院所、政府、非營利組織乃至包羅萬象的互聯網絡;流程裹挾著紛繁的數據,衝擊著你我的生活、工作、娛樂、科研,無論你願意不願意,它已經或正在顛覆著一切;做為身處信息洪流中的我們應從哪裏入手,來理清這紛紛擾攘的一切?流程,是的,還是流程;我們並沒有誇大流程的意思,流程可以是簡單的從小麥到麵包的過程,也可以是複雜的如航天器從概念構思到一飛衝天遨游天際的歷程,你看,流程已經在我們身邊,你我生活的世界中處處可見流程;對於種種流程的梳理建模、自動化、運維監控及優化,則是我們推動經濟社會向前運作的永無休止的循環。         以計算機技術及互聯網絡發展為代表的第三次信息化浪潮,從上世紀的七八十年代開始席捲了我們的管理世界,而伴隨著企業管理信息化浪潮而來的,則是轟轟烈烈的流程再造運動,是的,流程早已存在於我們的企業經營管理活動之中,但以信息技術為主要手段的企業流程再造運動則是於上世紀80年代初露端倪,還記得業務流程再造之父,哈默先生的『再造理論』嗎?『為了取得經營業績的戲劇性提高,企業應該再造經營—運用現代信息技術的力量急劇地重新設計每項業務的核心流程。』作為管理信息化從業者的我們,已經耳熟能詳的概念諸如:ERP,CRM,SCM,PLM,SRM,BI,HCM,SEM等等,這些紛繁的系統及管理方法,其核心無外乎管理流程的固化與自動化,借由這些系統的導入,完成企業流程的梳理與再造;現實情況是,受限於系統設計者與實現者的眼界,關注領域及解決問題範疇的不同,經年以來,我們為信息化付出多麼慘痛的代價,我想也無需一一道來,所有的從業者們都會感同身受;那麼,問題到底出在哪裏?我們什麼地方搞錯了嗎?答案是肯定地,我們忘記了最本質的東西—流程!端到端地流程,我們所求的是流程驅動的企業運作,而非僅僅是自動化、信息化運作的企業,廣義上講,『流程既是業務,業務既是流程』,無論從企業戰略看,還是從具體業務運作看,端到端的流程是貫通企業與機構經營運作的主線,忘記這個主線,我們的努力焉能不事倍功半? 好吧,不要再糾結於誰的解決方案你長我短,我們來回到問題的本源,你有沒有從根本上是思考業務實踐的核心:業務流程?端到端的業務流程是穿越諸業務系統的主線!有了這種意識之後,你會發現,你思考及解決問題的方法會漸漸發生改變,從以信息化系統實現為主導的思想,慢慢地轉變為以流程實現為主導的思想,不管你是業務人員還是實施開發人員,你都會以流程的角度與方法思考問題,你都會以傳遞價值為主要的工作目標,你都會以流程是否增值作為衡量工作效績的標準,管它是什麼SAP、開源系統還是用友的產品,這重要嗎?         是的,這就是我們組織此類在線交流活動的願景,技術的多樣性及廠商們的利益驅使並不能阻礙企業應用系統的同質化趨勢,也就是說,優秀的企業應用系統,一定具有相似的業務邏輯與功能實現,這就為我們的在線交流與諸系統的對比活動,提供了前提,奠定了基礎;         需要指出的是,市場上各類企業應用系統產品化及商業運作程度參差不齊,加之無論企業方還是系統提供方從不同的角度與目的,以及對問題的理解,多少都會存在私心與瑕疵,我們的目標是以業務流程的最佳實踐為主線,通過對諸系統的業務流程實踐展開對比活動,從而培養從流程思考企業管理問題的方法,學習企業業務流程分析建模、自動化、運維監控及優化的手段;從另一個角度看,通過此對比活動,在了解各解決方案的長短板之後,我們可以參照成熟的業務流程處理模式及方法論,提升相關解決方案的短板;需要特別強調的是:發起此比較活動的根本目的不在於系統之間的PK,而在於培養與學習流程化的思考方式與實現。 交流活動所涉及系統與相關技術: BP: Best Practices BPM: Business Process Management BPMN2.0: Business Process Model And Notation Ultimus7.1: Business Process Management System, Provider: Ultimus Airs Express: Business Process modeling Tool, Provider: SoftwareAG BonitaSoft: […]

【轉載】商業流程管理系統﹙BPM﹚規劃的迷思

在瞬息萬變的商場上,企業經營者不但隨時注意著新商機的徵兆,更努力管理多年投資得來不易的現行競爭力資產,而商業流程的管理可見度及效率更是許多企業維持競爭力之所繫。於是商業流程管理系統﹙Business Process Management system,BPM﹚乃應運而生:以早期工作流程管理系統﹙Workflow Management System﹚技術為基礎,配合與其他系統如群組軟體﹙Groupware﹚、人力資源系統﹙HR﹚、企業資源規劃﹙ERP﹚、供應鏈管理﹙SCM﹚、客戶關係管理﹙CRM﹚與商業智慧﹙BI﹚系統…等整合功能,達到企業商業流程得以從組織業務協同作業面向的整體管理目標。 筆者以多年經營導入系統經驗,對現行BPM市場供需關係發生的迷思提出個人看法供讀者分享。   迷思一:BPM系統可以提供企業流程管理策略? 企業規劃者在許多案例中,無法歸納出企業流程管理策略,期望藉由導入BPM系統幫助其制定策略。理想狀況下,企業應先研究出現行流程管理策略再導入系統,當系統運行後可以提供更清晰的統計數據,依此進行流程最佳化,甚或制定新的流程管理策略。 例如某製造業為掌握訂單交貨品質及期限,在各生產單位間執行問題管理,但在協調過程中往往出現問題本身被誤解或擱置、各單位相互推責等情事,導入BPM系統不但無法解決上述問題,而且會面臨導入失敗的結果。廠方應指派高階主管密集地深入協調作業一段時間,分析與解決問題,對各生產單位主管實行貫徹命令的機會教育,問題協調作業在會議及文件上被公開談論及書寫。如果得到有效改善,開始制定問題協調作業流程,建立監督稽核機制,再行導入BPM系統,使本流程作業得以常態運作與監督,並定期審視統計報表及進行流程最佳化調整。   迷思二:BPM系統的導入是企業裁員的前兆? 大部份企業導入BPM系統是期望更務實精準地掌握企業流程管理,創造彈性有效率的運作組織,許多機關實際規劃後分析發現,反而需要增加若干職務才能達到最佳化的組織。所以,原有的組織運作流程運作不合理,是造成冗員或瓶頸環節現象的原因,與導入BPM系統無關。 例如某服務業之客戶服務單位人員大多為技術服務人員,經常人力不足,且客戶服務滿意度不見提高。在建立BPM系統規劃期間,發現原來該單位主管們均為原工程師職務調昇,對其轄下技術服務人員之服務工作單簽核內容,僅著重其技術描述,對於工作時數與費用報支內容並不關心,形成提報浮濫現象。公司因而決定加派行政管理及稽核部門各一人,建立客服部門行政助理組織與流程制度,並責成人資部門安排對客服部門單位主管們的管理專業課程。藉由標準作業流程雙重審核與勾稽規劃設計,導入BPM系統後,解決了人力不足與客戶服務滿意度的問題。   迷思三:該選擇何種廠牌的BPM系統? 當企業評估導入BPM系統且交付IT部門執行時,IT往往以選擇BPM系統平台廠牌為優先考量。其實BPM導入需要大量客製化工作,客戶於第一次導入系統時,大多專案成本遠大於BPM系統平台授權成本。所以除非專案排除委外作業,否則選擇熟悉產業相關業務領域或積極投入的BPM專案服務團隊,比選擇平台廠牌更為重要。 在BPM系統業界,因為客戶多以選擇BPM廠牌為切入點,所以原本以系統平台產品為發展核心之廠商,為擔心客戶選擇其他廠牌,常常不情願地接下許多客製化專案。又因為要維持其產品授權行情,只好降低專案報價於全案所佔的比例,形成客製化專案報價低於BPM系統平台授權報價金額的怪異現象。在以上市場現象下,BPM系統平台廠商往往被迫培養了龐大的專案部門,人數甚且多於其核心價值之產品團隊。這導致近年來在提高獲利能力的壓力下,平台廠商所屬專案部門均遭裁撤或縮編之命運,進而影響專案品質。 是以專案負責人應打破平台產品與專案服務捆綁﹙Bundle﹚的迷思,在導入BPM系統時宜分別遴選廠商,而且專案服務應優於平台產品。   迷思四:BPM系統專案內容僅包括系統平台及客製化流程開發? BPM系統上線維運期間,經常因頻繁的組織異動,造成原需求設計開發的流程難以正常運行,IT人員也因提出需求變更要求而疲於奔命;這是許多導入BPM專案之客戶,在上線一年內陷入維運窘境的主因。筆者非常重視維運管理之規劃,也呼籲企業導入BPM系統時,須將組織異動視為常態,在系統設計時納入維運管理流程規劃,可以避免商業流程須因應組織異動而變更程式碼。 如果企業有自行負責維運的技術人力,應在專案規劃時將技術移轉訂定為專案目標之一,採取獨立預算與個別驗收方式,以免與上線目標的達成產生資源上衝突。此外,企業亦可僅規劃負責維運的管理人力,在系統設計中納入維運管理子系統之需求考量,並向廠商另購因需求變更所需之客製化開發人力時數。   結語 BPM系統導入作業複雜,除了企業與服務廠商間緊密合作的專案團隊,系統長期運行的規劃設計眼光、流程的優化經驗技術、保障流程交易可靠度的設計模型及BPM資訊安全設計等,都是可以深入探討的議題。因篇幅限制,筆者本次先提出四點迷思,冀望能拋磚引玉,引起共鳴。

BPM導入,還不是時候?

這個問題一直是需要面對的問題,企業導入BPM的最佳時機是什麼? 『…我們還沒有做好充分的準備,…企業戰略,如何通過導入流程管控落地並風險可控?…企業管理還沒有達到流程管控的水平,…基礎信息化還沒有做好,談何業務流程管理?』 聽到來自不同角度的各種表述與訴求,做為BPMS的提供者,您們是否可以給出答案?

BPM与ERP、必要性及孰先孰后

        BPM项目、归根结底,是针对企业的战略管理及流程管理的优化与革新,企业战略需经过分解并形成各量化关键绩效指标,以引入业务流程管理的方式达到企业战略在业务层面的落地与体现,由于企业战略建模,运营流程的规范及优化,是企业管理革新的首要工作,从此一点上看,BPMS套件一定先于ERP系统进行导入实施,借由业务流程管理套件的业务流程梳理建模、落地(自动化)、运维监控及优化工具,形成企业管理的敏捷层,连通企业战略、业务与IT的桥梁。         再看ERP,本质上看,则是各企业业务流程的标准化、固化、自动化的软件系统,是ERP软件供应商根据长期的管理实践,对企业普遍适用的运营流程的预打包及预配置,如采购库存管理流程、账务处理流程、项目管理流程、销售管理流程等等,而ERP系统的适用性是其软肋所在,不同的ERP厂商在提高不同企业适用性及系统的复杂冗余之间保持必要的平衡,ERP系统的可配置性、完整性、可操作及可管理性,是考量ERP系统优劣的主要标准。         从联化目前的管理诉求及业务特性看,完全适用于联化管理需求的ERP系统并不存在,但从ERP涵盖企业运营的标准流程这一点看,在完成业务建模及流程梳理工作后,标准运营流程的落地与自动化可以借由ERP系统部分实现,这也是为什么我们要讨论BPM与ERP孰先孰后的主要动因。可以确定的是,ERP之于联化,是管理信息化的必要手段与工具,但导入ERP系统的前题,是企业战略建模及运营流程的梳理与优化,也就是我们通常所说的业务流程管理中流程分析(BPA)的工作范畴,故此,先后问题,不辩自明。

[Reshare] 35 Business Process Management Capabilities You Should Know

This article is based on the findings in Janne Ohtonen’s PhD thesis called BPMC – Business Process Management Capabilities, which was done for the University of Turku during the years 2010-2012. The results presented below are the capabilities that are related to successful BPM initiatives found in over 150 scientific studies conducted over the last […]

重构还是复用?

        如果你是在设计一条通过重用IT服务来实现自动化的业务流程,你需要事先建立服务库并且将他们分配给各个步骤。该步骤通常是由业务分析员来定义某个步骤需要的业务功能,并将这个业务功能匹配至一个或多个业务服务。然后,由流程工程师定义实现这个业务功能的特定IT服务。为提高重用水平,调整业务流程使其尽可能使用已有的IT服务,这样做显然比要求重新构建一套新的IT服务更为必要。

【转载】业务流程建模前需要考虑的问题

        设计流程和企业的其他工作一样,你需要清楚你为谁设计流程,他们为了什么目的使用这条流程,更重要的,你期望从所有建模工作中获取哪些收益。这些问题的答案决定了建模的内容、格式和细度。许多企业浪费了大量的时间创建了许多从未使用过的流程,因为这些建模者没有认真思考以下这些基本问题: