BPM(Business Process Management)方興未艾,然而市場上BPM產(chǎn)品你方唱罷我上場,各色產(chǎn)品?各種概念粉墨登場?雖然百花齊放,但真正有志于實施BPM的客戶卻被這亂花迷了眼,實在搞不清楚BPM該怎么去做,最終失去對BPM的信心?這于BPM的發(fā)展并無益處?
現(xiàn)在一種普遍的理解,即把BPM理解為一個IT術(shù)語或一類IT產(chǎn)品,這是不全面的?在BPM中,業(yè)務(wù)應(yīng)當占據(jù)主導(dǎo)地位,軟件或者說技術(shù)占輔助地位?從業(yè)務(wù)角度說,完整的BPM應(yīng)該覆蓋企業(yè)戰(zhàn)略管理?戰(zhàn)略流程定義?業(yè)務(wù)構(gòu)建?業(yè)務(wù)流程定義?業(yè)務(wù)服務(wù)定義和編排?業(yè)務(wù)執(zhí)行和監(jiān)控?業(yè)務(wù)流程優(yōu)化改進以及戰(zhàn)略調(diào)整等幾乎企業(yè)管理的方方面面?從IT角度說,BPM所集成的一系列軟件和專業(yè)技術(shù)要能夠支持上述的業(yè)務(wù)生命周期落地?最重要的是,這些軟件和專業(yè)技術(shù)必須是面向業(yè)務(wù)人員的,即要由業(yè)務(wù)來驅(qū)動BPM的建設(shè),由業(yè)務(wù)人員來主導(dǎo)整個業(yè)務(wù)流程管理體系的建立,而不是由IT來驅(qū)動?
BPM市場和產(chǎn)品的混亂
與其他革命性的IT變革一樣,我們需要從方法?架構(gòu)和實現(xiàn)技術(shù)三個方面去理解和掌握BPM產(chǎn)品?
方法對應(yīng)產(chǎn)品的設(shè)計目標企業(yè)的管理理論和相應(yīng)的實施方法論,架構(gòu)意味著對軟件產(chǎn)品的設(shè)計如何匹配設(shè)計目標,實現(xiàn)技術(shù)則意味著采用何種IT技術(shù)去實現(xiàn)相應(yīng)的設(shè)計目標?三者缺一不可,然而長久以來,人們習(xí)慣于用實現(xiàn)技術(shù)去分辨和解釋BPM,以至于到現(xiàn)在為止,人們?nèi)匀粺o法正確理解BPM?由此也造成了BPM市場和產(chǎn)品的混亂?
其實這個問題并不是BPM獨有的?舉例來說,筆者在培訓(xùn)面向?qū)ο蟮姆治龊驮O(shè)計方法時發(fā)現(xiàn),相當大比例的程序員,即使他已經(jīng)工作了很多年,即使他擁有豐富的項目經(jīng)驗,同時也精通一門或多門面向?qū)ο蟮恼Z言,但實際上他們卻沒有真正地掌握面向?qū)ο蟮姆椒?/span>?掌握面向?qū)ο蠓椒ǖ年P(guān)鍵不在于是否采用了面向?qū)ο蟮恼Z言和工具(如UML),也不在于是否掌握了面向?qū)ο蟮木幊碳记?/span>(如設(shè)計模式),而是從需求到分析設(shè)計,再到編碼實現(xiàn),你是否真的在用面向?qū)ο蟮乃季S去思考?
SOA也面臨同樣的問題?是否掌握了SOA,其關(guān)鍵不在于是否采用了支持SOA的應(yīng)用架構(gòu)(如WebSphere Application Server),也不在于是否把某些代碼邏輯封裝成了符合SOA規(guī)范的服務(wù)(如Webservice),而是,你是否真的采用面向服務(wù)的方法去分析需求?設(shè)計架構(gòu)?抽取服務(wù),把業(yè)務(wù)服務(wù)化?從項目開始到結(jié)束的整個過程都應(yīng)該是面向服務(wù)的,而不僅僅是針對產(chǎn)出物的?
回到BPM產(chǎn)品上來,如果僅從實現(xiàn)技術(shù)去理解,人們就會陷入這樣的混亂: BPM與工作流有什么差別?都有流程引擎,都可以自動化運行,都有流程編排器,也都能對流程進行監(jiān)控?憑什么工作流就不是BPM?如果辯解說BPM比工作流能做更多的事,比如服務(wù)編排和集成,那么也可以辯解說只要是開放的通信標準,不論是WebService還是JMS,工作流同樣可以集成第三方服務(wù),BPM可以做的,工作流同樣可以做到,無非只是技術(shù)實現(xiàn)的方式不一樣而已,并沒有本質(zhì)的差別?你還可以爭辯說BPM是面向業(yè)務(wù)的,而工作流不是,但你如何解釋什么是業(yè)務(wù)?難道BPM里一個審批申請的活動是業(yè)務(wù),工作流里一個審批申請活動就不是業(yè)務(wù)?什么道理?
看,一旦陷入這樣的技術(shù)細節(jié)比較,就是比上個三天三夜,吵個天翻地覆也不會有結(jié)果?
從方法和架構(gòu)入手
要辨別一個產(chǎn)品是否是BPM產(chǎn)品,我們還是得回到方法和架構(gòu)上來?我們得承認這樣一個事實:業(yè)務(wù)驅(qū)動架構(gòu),架構(gòu)驅(qū)動技術(shù),而不是相反?判斷一個產(chǎn)品是不是真正的BPM,應(yīng)該從源頭往下看,看它的設(shè)計目的是不是為了解決業(yè)務(wù)流程管理,看它的架構(gòu)是不是從業(yè)務(wù)流程管理方法論當中推導(dǎo)出來的,是不是符合業(yè)務(wù)流程管理方法規(guī)范,其針對的用戶是不是業(yè)務(wù)用戶?而不是看它是否包含了BPM的某些技術(shù)特征,也不是看它是不是能做到一些BPM聲稱應(yīng)該做到的事情?
一方面,技術(shù)的堆砌無法形成架構(gòu)(技術(shù)架構(gòu)必須指向特定的業(yè)務(wù)領(lǐng)域,解決特定的業(yè)務(wù)問題),拼湊出來的所謂架構(gòu)也無法完整的解決業(yè)務(wù)問題?能夠做到某些事情并不表示它就是解決這類問題的恰當?shù)墓ぞ?/span>,比如,扳手和錘子都可以用來砸釘子,但扳手本身不是錘子,二者被設(shè)計服務(wù)于不同的業(yè)務(wù)領(lǐng)域?另一方面,同樣的方法和架構(gòu)允許不同的實現(xiàn)技術(shù)?例如,如果你的架構(gòu)就是要解決砸釘子的業(yè)務(wù)問題,由于某種原因無法使用錘子,必要時,你可以把扳手集成進來,作為一種可能的實現(xiàn)技術(shù)?
這有兩層含義?其一,某種技術(shù)手段的加入不能決定或改變其所針對的業(yè)務(wù)領(lǐng)域,更不能改變其本質(zhì)?上述例子中,扳手是為砸釘子設(shè)計的,其設(shè)計目標并不會因為產(chǎn)品具備了扳手的某些特征就變成了修水管的工具?因為扳手在這里明確地指向砸釘子的業(yè)務(wù)問題,產(chǎn)品會忽略掉其他與砸釘子無關(guān)的扳手的其他特征?其二,不能因為某項技術(shù)最終解決了某個業(yè)務(wù)問題,就認為該項技術(shù)就是針對該業(yè)務(wù)問題的正確工具?上述例子中,在解決砸釘子業(yè)務(wù)問題的工具里,扳手是一種可能的實現(xiàn)辦法,但它仍然是扳手,不能夠說因為扳手也可以砸釘子了,所以它就是錘子?
我為何要如此糾結(jié)于一個產(chǎn)品到底是不是真正的BPM呢?只要能解決實際問題不就行了嗎?我要如此較真的原因在于,業(yè)務(wù)驅(qū)動架構(gòu),架構(gòu)驅(qū)動技術(shù),這是一套符合科學(xué)方法的體系:首先提出問題,然后分析問題,最后解決問題?從方法到架構(gòu)到實現(xiàn),它是一套自洽的?能自我發(fā)展完善的體系?隨著問題的深入和變化,整個體系也會隨之修改或者進化,但始終是一套完整的處于相應(yīng)理論指導(dǎo)下的體系,直到該問題不再有價值時被拋棄或者被另一套更好的體系或理論所替代?在整個產(chǎn)品生命周期中,其目標始終清晰?體系始終完整?進化始終有序?所以,如果它是真正的BPM,意味著該產(chǎn)品會隨著整個BPM理論和體系進化,獲得穩(wěn)定的?可靠的升級和改進;如果它只是披著BPM的馬甲,通過勉強的改造或挪用某些技術(shù)手段去解決BPM的問題,則意味著該產(chǎn)品無法針對業(yè)務(wù)流程解決方案提供有效和持久的改進?因為對一個軟件來說,如果一個軟件設(shè)計的最初目標與應(yīng)用目標不符,而硬逼迫它往應(yīng)用目標變更和定制,該軟件必然變成打滿補丁的袍子,總有一天它不但再也無法解決這些業(yè)務(wù)問題,恐怕連它的本職工作都無法再勝任了?
是,還是不是BPM,真的是問題的關(guān)鍵!
BPM產(chǎn)品甄別標準
BPM的設(shè)計目標決定,BPM是一個IT工具,必須要和企業(yè)運營緊密結(jié)合在一起,是企業(yè)管理運營的直接映射?企業(yè)需要的是可以直接將業(yè)務(wù)變成可執(zhí)行流程的技術(shù),需要由業(yè)務(wù)人員直接建立?管理?優(yōu)化流程,希望流程管理系統(tǒng)建設(shè)后可以直接在執(zhí)行過程中監(jiān)控企業(yè)績效,更希望企業(yè)的戰(zhàn)略意圖可以直接與具體的執(zhí)行層聯(lián)系起來?
要滿足這樣的需求,BPM工具必須徹頭徹尾地面向業(yè)務(wù)人員而不是IT人員,用業(yè)務(wù)語言去建模而不是IT語言,由業(yè)務(wù)人員驅(qū)動BPM的建設(shè)而不是IT驅(qū)動?換句話說,如果有一個所謂的BPM產(chǎn)品,它被設(shè)計為面向IT人員,靠IT人員定制開發(fā)而不是業(yè)務(wù)人員建模,它的設(shè)計無法對接企業(yè)戰(zhàn)略和執(zhí)行層面(是否對接戰(zhàn)略和執(zhí)行的簡單判斷標準是,是否能夠說明和測量流程中的某一個活動針對哪個戰(zhàn)略目標,某個實例貢獻值如何),它的設(shè)計是針對業(yè)務(wù)執(zhí)行問題(需求從基層來)而不是業(yè)務(wù)管理本身問題(需求必須自頂向下)的,即可懷疑為偽BPM或說是不完整的BPM?最容易混淆的便是工作流與BPM?OA與BPM?ERP與BPM?
非針對BPM的設(shè)計帶來兩個明顯的局限,其一,系統(tǒng)的建立盡管使得工作效率有所提高,但對于衡量企業(yè)的整體績效來說,這些系統(tǒng)內(nèi)容是一個黑盒子,無法在執(zhí)行過程中監(jiān)控并得到企業(yè)整體績效乃至戰(zhàn)略的反饋;其二,由于架構(gòu)和設(shè)計的方向不同,業(yè)務(wù)人員被排除在流程的建立?管理?監(jiān)控?調(diào)整之外,必須通過IT人員來進行?這使得業(yè)務(wù)敏捷成了一句空話?
總結(jié)下來,辨別一個產(chǎn)品是否是真正的BPM產(chǎn)品,可以從以下幾個關(guān)鍵特征出發(fā):
1.該產(chǎn)品是否具有極強的導(dǎo)向性,面向價值增值(戰(zhàn)略目標)而非僅僅實現(xiàn)當前業(yè)務(wù)?
此特征意味著每個業(yè)務(wù)流程和每個活動都可以明確地指出其針對的戰(zhàn)略目標,并可以用指標衡量其價值貢獻(相對于戰(zhàn)略目標)?BPM的建設(shè)成功與否可以用企業(yè)最為熟悉的商業(yè)價值評估體系來評判并優(yōu)化調(diào)整?
如果一個所謂BPM產(chǎn)品不能夠直接實時地提供業(yè)務(wù)執(zhí)行時對戰(zhàn)略目標的貢獻值,僅能夠提供IT級別的運行測量結(jié)果,或者只能通過滯后的報表統(tǒng)計,再通過諸如BI工具等來估算業(yè)務(wù)效益?它將無法支持BPM的價值?
2.該產(chǎn)品是否以端到端的業(yè)務(wù)流程為中心而非僅僅用于實現(xiàn)局部業(yè)務(wù)?
此特征意味著流程梳理是BPM建設(shè)的前提條件?BPM實施的同時必然帶有流程梳理?測量?優(yōu)化或改造等活動,基于片斷化的?局限于部門內(nèi)部的所謂BPM建設(shè)難以獲得BPM帶來的價值?
如果一個所謂的BPM產(chǎn)品從建模到實施到管理,僅需要或僅支持局部的業(yè)務(wù)需求,在必要時,只能通過其他技術(shù)手段(如WebService?JMS?Rest)來與其他部門或系統(tǒng)做散列的點狀集成,而不是像真正的BPM那樣需要端到端的流程梳理結(jié)果作為必要條件,在建模過程中沒有所謂的“與其他集成”的概念,所有活動都是端到端流程中一個自然的節(jié)點?那么,它將無法支持BPM中的戰(zhàn)略落地?
3.該產(chǎn)品是否由業(yè)務(wù)人員驅(qū)動而非IT驅(qū)動?
此特征意味著業(yè)務(wù)人員的角色將不只是單一被動的需求提供者和業(yè)務(wù)流程執(zhí)行者,還將是更積極主動的業(yè)務(wù)流程構(gòu)建者?業(yè)務(wù)流程監(jiān)控者?業(yè)務(wù)優(yōu)化者和業(yè)務(wù)流程管理者角色?
如果一個所謂的BPM產(chǎn)品僅面向IT人員,業(yè)務(wù)人員不能深度參與業(yè)務(wù)流程建設(shè),只能將業(yè)務(wù)需求翻譯為IT語言再實現(xiàn),那么很難做到IT資產(chǎn)與真實業(yè)務(wù)流程的高度同步?該產(chǎn)品將無法支持BPM的業(yè)務(wù)監(jiān)控?改進?優(yōu)化等管理需求?
4.該產(chǎn)品的流程實現(xiàn)是否支持粗粒度的服務(wù)編排而非從頭定制開發(fā)
此特征意味著BPM產(chǎn)品必須支持通過編排粗粒度的服務(wù)集成并整合利用企業(yè)資產(chǎn)(包括IT和非IT),以快速?敏捷的建設(shè)和變更業(yè)務(wù)流程,從而有效支持業(yè)務(wù)敏捷和業(yè)務(wù)改造?
如果一個所謂的BPM產(chǎn)品在項目中需要大量的定制開發(fā),其架構(gòu)不支持服務(wù)編排或者只能通過外掛的標準協(xié)議調(diào)用服務(wù)而不是架構(gòu)的一個有機整體,那么它將無法支持業(yè)務(wù)敏捷和快速的業(yè)務(wù)改進?就目前IT界的技術(shù)來看,產(chǎn)品是否全面支持SOA甚至直接架構(gòu)在SOA上,是判斷是否符合此特征的重要依據(jù)?
解決哪些核心問題
真正的BPM需要提供面向業(yè)務(wù)人員的業(yè)務(wù)流程的建模語言?建模工具?管理工具和監(jiān)控工具;需要屏蔽掉業(yè)務(wù)人員弄不懂的IT語言與實現(xiàn);需要強大的集成能力可以貫通分散于各個業(yè)務(wù)部門各個平臺上的異構(gòu)系統(tǒng)以實現(xiàn)企業(yè)整體業(yè)務(wù)流程管理和績效監(jiān)控;還需要業(yè)務(wù)流程當中的活動可以與企業(yè)戰(zhàn)略掛鉤,使得業(yè)務(wù)流程的運行直接反饋戰(zhàn)略執(zhí)行狀態(tài)?
因此,一個真正的BPM軟件要解決的是以下一些核心問題:
1.BPM必須橫跨業(yè)務(wù)和IT兩個部分?它必須很好地支持業(yè)務(wù)用戶采用業(yè)務(wù)語言來建設(shè)業(yè)務(wù)流程,同時又必須能夠支持IT人員使用IT語言來整合IT資產(chǎn)以實現(xiàn)業(yè)務(wù)流程?這要求一個BPM產(chǎn)品必須同時具備業(yè)務(wù)設(shè)計能力與IT設(shè)計能力,并且能夠?qū)煞N模型統(tǒng)一為一個完整的模型?
2.與以前純IT產(chǎn)品不同,企業(yè)的運營流程與BPM產(chǎn)品里的資產(chǎn)應(yīng)該是高度同步的,這些資產(chǎn)映射了真實的業(yè)務(wù)流程而不是需要翻譯的IT資產(chǎn)?當企業(yè)的業(yè)務(wù)變更發(fā)生時,這些變更不需要等待業(yè)務(wù)翻譯為IT資產(chǎn)的周期,而是由業(yè)務(wù)人員直接將其轉(zhuǎn)化成BPM資產(chǎn),這些BPM資產(chǎn)則應(yīng)快速響應(yīng)業(yè)務(wù)變更?這要求一個BPM產(chǎn)品要能夠管理一個業(yè)務(wù)流程(BPM資產(chǎn))從創(chuàng)建到測試?模擬?部署?運行?監(jiān)控?改進?變更?升級?歸檔的整個生命周期?
3.與單純的某一類專業(yè)IT產(chǎn)品(如生產(chǎn)?財務(wù)?客戶關(guān)系管理等)不同,BPM更注重于跨部門?跨IT系統(tǒng)?跨業(yè)務(wù)甚至跨組織的綜合業(yè)務(wù)需求?盡管它在解決企業(yè)應(yīng)用架構(gòu)中較低層次的執(zhí)行問題方面也是利器,但BPM更大的價值在于它能夠在整個企業(yè)應(yīng)用架構(gòu)中更高的層次上整合業(yè)務(wù),能夠與企業(yè)戰(zhàn)略相結(jié)合?這要求一個BPM產(chǎn)品要能夠使用粗粒度的服務(wù)來快速構(gòu)建應(yīng)用程序而不是從頭開發(fā)?
4.BPM必須具備更強的擴展能力,能夠容納?擴展?整合各種各樣的企業(yè)應(yīng)用,以BPM為核心形成應(yīng)用生態(tài)圈而不是僅僅是孤立的業(yè)務(wù)問題和流程問題?這要求一個BPM產(chǎn)品必須基于開放的標準和平臺,要能夠具備跨平臺?跨應(yīng)用的整合能力,可以擴展和被擴展,以滿足企業(yè)各種各樣的業(yè)務(wù)需求和應(yīng)用環(huán)境?
企業(yè)可以從以上四個方面來評估一個BPM產(chǎn)品是否符合自身的需要?
同時, BPM的實施是一個循序漸進的過程,它必須與企業(yè)當前的BPM成熟度?業(yè)務(wù)規(guī)模?人員素質(zhì)等相匹配,同時也與BPM產(chǎn)品的復(fù)雜度息息相關(guān)?顯然,一個剛剛接觸并開始采用BPM的企業(yè),不可能掌握從戰(zhàn)略到執(zhí)行的方法,不可能建立完善的從戰(zhàn)略目標到活動的指標體系,也無法在短時間內(nèi)在管理上疏通各個業(yè)務(wù)職能部門?直接實施一個龐大的BPM計劃,引入一個復(fù)雜的BPM產(chǎn)品,將會使企業(yè)充滿挫敗感:每走一步都極為艱難,周期長,難見成效?許多邀請咨詢公司做了業(yè)務(wù)流程梳理但卻難以落地的企業(yè)對此應(yīng)深有體會?
聯(lián)系客服
