還記得早期的Dreamweaver嗎?為了提高網(wǎng)頁(yè)的開(kāi)發(fā)效率,Dreamweaver提供了可視化拖拽的能力來(lái)生成網(wǎng)頁(yè)代碼??梢?jiàn),低代碼、無(wú)代碼的探索和發(fā)展其實(shí)很早就開(kāi)始了。
近年來(lái),“低代碼”這個(gè)關(guān)鍵詞突然又熱了起來(lái),相關(guān)創(chuàng)業(yè)公司如春筍般涌現(xiàn)。突然爆火的背后其實(shí)仍然是企業(yè)數(shù)字化轉(zhuǎn)型的驅(qū)動(dòng),在海量軟件開(kāi)發(fā)需求下,現(xiàn)有軟件生產(chǎn)力已經(jīng)難以應(yīng)對(duì),低代碼技術(shù)則是一種破局之道。
關(guān)于低代碼
什么是低代碼?
通過(guò)和專(zhuān)業(yè)的代碼開(kāi)發(fā)做對(duì)比,低代碼、零代碼本質(zhì)是提供了一種更抽象的“開(kāi)發(fā)語(yǔ)言”。通過(guò)圖1能看到,低代碼、零代碼是建立在一種“建模語(yǔ)言”之上的,相對(duì)匯編、高級(jí)開(kāi)發(fā)語(yǔ)言,建模語(yǔ)言的抽象程度更高,所以對(duì)開(kāi)發(fā)者的門(mén)檻更低,只要熟悉圖形的含義,就可以通過(guò)可視化的方式拖拽出符合業(yè)務(wù)邏輯的程序。BPMN是一種比較成熟的流程建模語(yǔ)言,專(zhuān)門(mén)用于業(yè)務(wù)流程領(lǐng)域的業(yè)務(wù)場(chǎng)景構(gòu)建。這也是為什么很多低代碼產(chǎn)品能夠在“偏流程管理型”的應(yīng)用場(chǎng)景中獲得成功的原因,除了市場(chǎng)有需求之外,技術(shù)層面有成熟的理論支撐也很重要。
還有一種做法是基于大量基礎(chǔ)場(chǎng)景組件的積累,然后通過(guò)搭積木的方式來(lái)實(shí)現(xiàn)場(chǎng)景構(gòu)建的低代碼平臺(tái),筆者認(rèn)為這種方式成功的概率很低。組件再豐富也難以應(yīng)對(duì)千變?nèi)f化的業(yè)務(wù)場(chǎng)景,只有具備用“語(yǔ)言”來(lái)描述場(chǎng)景的能力,才能真正做到以不變應(yīng)萬(wàn)變。所以,以當(dāng)前建模語(yǔ)言的成熟度來(lái)看,流程管理域的業(yè)務(wù)場(chǎng)景才更適合發(fā)揮低代碼技術(shù)的應(yīng)用價(jià)值。
圖1
為什么要低代碼?
企業(yè)完成核心業(yè)務(wù)流程的數(shù)字化之后,下一步可能會(huì)聚焦到內(nèi)部運(yùn)營(yíng)效率的提升,內(nèi)部運(yùn)營(yíng)管理的效率同樣是組織的一種核心競(jìng)爭(zhēng)力。而內(nèi)部運(yùn)營(yíng)支撐系統(tǒng)又不及業(yè)務(wù)系統(tǒng)那么重要,不可能為此花費(fèi)過(guò)多的軟件開(kāi)發(fā)投入,也無(wú)法簡(jiǎn)單引入一套功能豐富的系統(tǒng)(如:ERP、OA)就可以解決問(wèn)題,很多邊緣的、零碎的個(gè)性化管理場(chǎng)景是難以覆蓋,導(dǎo)致開(kāi)發(fā)需求急劇上升,IT部門(mén)如果仍然以傳統(tǒng)的開(kāi)發(fā)方式,不管是自研還是引入外部開(kāi)發(fā)團(tuán)隊(duì),其生產(chǎn)力都遠(yuǎn)遠(yuǎn)無(wú)法滿(mǎn)足這些頻繁變化的、零散個(gè)性化的需求。因此低代碼的價(jià)值就凸顯出來(lái)了,其很重要的一點(diǎn)是實(shí)現(xiàn)全民開(kāi)發(fā),即人人都是開(kāi)發(fā)者。如果能真正運(yùn)營(yíng)起來(lái),其軟件的生產(chǎn)力可以是指數(shù)級(jí)上升的。
流程建模語(yǔ)言
既然低代碼的核心是建模語(yǔ)言,那么,我們以最常見(jiàn)的流程建模來(lái)看看什么是建模語(yǔ)言。此外,ITSM承載的是運(yùn)維、運(yùn)營(yíng)的流程管理體系,其核心也是流程類(lèi)的業(yè)務(wù)場(chǎng)景居多。因此,我們可以聚焦到流程領(lǐng)域再深入看看,進(jìn)一步理解低代碼的底層邏輯,也便于后續(xù)理解低代碼在ITSM中的應(yīng)用。
在流程管理領(lǐng)域中使用最廣泛的建模語(yǔ)言莫過(guò)于OMG發(fā)布的BPMN/DMN/CMMN等標(biāo)準(zhǔn),各種主流的開(kāi)源流程引擎、規(guī)則引擎,如:Activiti、JBPM等,都是基于這些標(biāo)準(zhǔn)進(jìn)行設(shè)計(jì)的。
圖2
當(dāng)然,這些引擎也不是百分百實(shí)現(xiàn)了前面三個(gè)標(biāo)準(zhǔn),和其發(fā)展的重心和年限有關(guān)。
1、BPMN
在管理機(jī)制的設(shè)計(jì)中,有一個(gè)很重要的點(diǎn)就是“工作流”的設(shè)計(jì)。通常來(lái)說(shuō),管理流程越成熟,工作流越固化,即某個(gè)工作不再需要太多的創(chuàng)造性了,只要按固定的工作流一步一步去完成,就能得到好的工作結(jié)果。BPMN的標(biāo)準(zhǔn)就非常適合此類(lèi)情況,即用于描述可預(yù)定義的、固定順序的工作流。
圖3 固化工作流
BPMN語(yǔ)言中關(guān)鍵要素包括活動(dòng)、網(wǎng)關(guān)和事件,通過(guò)這些對(duì)象符號(hào)來(lái)描述一個(gè)標(biāo)準(zhǔn)的工作流程。(如對(duì)更詳細(xì)圖形符號(hào)感興趣,可查閱官方資料,這里不做更詳細(xì)地展開(kāi)。)
2、CMMN
工作的流程完全固化是一種比較理想的情況,實(shí)際管理過(guò)程中,成熟度都是從混亂發(fā)展到可定義級(jí)別的,在還沒(méi)找到適合組織的最佳工作實(shí)踐的情況下,更多還是靠人的主觀能動(dòng)性來(lái)解決問(wèn)題。例如:當(dāng)某個(gè)運(yùn)維事件的發(fā)生,通常依賴(lài)于成熟的工程師臨時(shí)做出判斷,并拆解出幾個(gè)關(guān)鍵任務(wù)來(lái)進(jìn)行處理,分別由誰(shuí)來(lái)執(zhí)行,順序是如何的。這種不確定的、無(wú)法預(yù)定義的工作過(guò)程就難以用BPMN來(lái)建模描述了,而CMMN的標(biāo)準(zhǔn)則更加適合此類(lèi)場(chǎng)景。
圖4 CMMN場(chǎng)景案例
3、DMN
管理過(guò)程中還有一個(gè)很重要的活動(dòng)就是決策,不同的決策結(jié)果會(huì)影響后續(xù)的工作流程。例如:某個(gè)變更是否要執(zhí)行,就需要人為判斷變更的風(fēng)險(xiǎn)程度來(lái)決定后續(xù)的處理策略。針對(duì)此類(lèi)決策的活動(dòng)場(chǎng)景,最佳實(shí)踐則是通過(guò)DMN標(biāo)準(zhǔn)來(lái)進(jìn)行描述。通過(guò)下圖對(duì)比可以直觀看出在決策場(chǎng)景中用與不用DMN的區(qū)別。
圖5
4、最佳實(shí)踐
如前面章節(jié)所述,在流程建模過(guò)程中,不同的標(biāo)準(zhǔn)適用于不同的場(chǎng)景。那具體到一個(gè)完整流程的設(shè)計(jì),應(yīng)該如何判斷選擇怎樣的標(biāo)準(zhǔn)組合呢?同樣行業(yè)中也提供了最佳實(shí)踐的參考原則:
圖6 最佳實(shí)踐
- 業(yè)務(wù)流程中使用了一系列的網(wǎng)關(guān),這個(gè)時(shí)候可以考慮使用DMN決策引擎代替。
- 業(yè)務(wù)流程中使用了大量的事件,則可以?xún)?yōu)先考慮使用CMMN。
- 業(yè)務(wù)流程中有一系列的加簽、自由流程,則優(yōu)先考慮使用CMMN。
- CMMN中如果案例內(nèi)的元素都是有嚴(yán)格的執(zhí)行順序,則優(yōu)先考慮使用BPMN標(biāo)準(zhǔn)。
低代碼引擎設(shè)計(jì)
引擎模塊體系
要通過(guò)低代碼完整地實(shí)現(xiàn)一個(gè)管理類(lèi)應(yīng)用的閉環(huán)構(gòu)建,通常需要五大引擎能力進(jìn)行配合。
圖7
引擎功能設(shè)計(jì)
如下是各引擎模塊的定位、功能設(shè)計(jì)參考。
圖8
低代碼在ITSM中的應(yīng)用
運(yùn)維工單構(gòu)建
圖9
最能反映運(yùn)維管理的業(yè)務(wù)邏輯的是運(yùn)維工單的設(shè)計(jì),細(xì)節(jié)到一個(gè)事件優(yōu)先級(jí)的定義、問(wèn)題類(lèi)別的定義等,都能對(duì)運(yùn)維工作產(chǎn)生影響,甚至影響到是否滿(mǎn)足監(jiān)管合規(guī)。因此,即使過(guò)了建設(shè)期,在運(yùn)營(yíng)期間也可能對(duì)已定義好的表單進(jìn)行細(xì)微調(diào)整,此時(shí)ITSM表單的靈活性就非常重要。基于表單引擎可以對(duì)運(yùn)維工單進(jìn)行可視化建模,包括表單字段的定義、表單字段數(shù)據(jù)來(lái)源的定義、表單字段之間交互規(guī)則的定義、表單字段之間數(shù)據(jù)聯(lián)動(dòng)規(guī)則的定義等,以應(yīng)對(duì)表單頻繁變化的場(chǎng)景。常見(jiàn)的應(yīng)用場(chǎng)景如下:
- 承載事件/問(wèn)題/變更等流程表單的自定義;
- 承載場(chǎng)景化流程表單的自定義,如:資源申請(qǐng)、權(quán)限申請(qǐng)等。
運(yùn)維工作流構(gòu)建
圖10
運(yùn)維工作流反映的是運(yùn)維工作的協(xié)同過(guò)程。在運(yùn)維管理中,不僅僅是人與人的協(xié)同,還可能人與系統(tǒng)、系統(tǒng)與系統(tǒng)間的協(xié)同?;?span id="8yyyyyy" class="candidate-entity-word" data-gid="15430054">工作流引擎可以對(duì)運(yùn)維工作進(jìn)行端到端協(xié)同層面建模,包括工作流中活動(dòng)的定義、分支的定義、審批的定義、事件的定義等。在ITSM中的應(yīng)用場(chǎng)景如下:
- 審批場(chǎng)景:多級(jí)審批、多人審批、加簽審批等;
- 協(xié)作場(chǎng)景:事件處理的一線、二線之間的升級(jí)流轉(zhuǎn)、工單轉(zhuǎn)派、任務(wù)分配等;
- 集成場(chǎng)景:工作流與自動(dòng)化作業(yè)流的端到端打通。
運(yùn)維管理策略構(gòu)建
圖11
在實(shí)際的運(yùn)維工作中,還存在大量的管理策略規(guī)則,比如:事件處理的分派策略、優(yōu)先級(jí)矩陣、風(fēng)險(xiǎn)評(píng)估、審批策略等。這些看似簡(jiǎn)單的邏輯,對(duì)效率和成本影響可不容忽視,因?yàn)橥ǔ儆谝环N高頻的活動(dòng),例如:服務(wù)臺(tái)人員一天可能需要執(zhí)行上百次分派的動(dòng)作?;谝?guī)則引擎,通過(guò)決策表、決策樹(shù)等方式,可以靈活地將規(guī)則進(jìn)行固化,代替人工操作。
運(yùn)維度量報(bào)表構(gòu)建
圖12
度量是運(yùn)維管理持續(xù)改進(jìn)的前提,一是度量指標(biāo)的設(shè)計(jì),二是獲取準(zhǔn)確的度量數(shù)據(jù)。同樣,度量報(bào)表并不是一成不變的設(shè)計(jì),而是隨著管理的成熟度變化而變化,不同階段、不同管理者的要求也會(huì)帶來(lái)新的變化。例如:流程運(yùn)行的初期,我們更關(guān)注的是流程有沒(méi)有推廣起來(lái),因此更聚焦工單數(shù)量相關(guān)的度量指標(biāo)。隨著流程逐步運(yùn)行成熟,我們開(kāi)始關(guān)注工作的成效,如關(guān)單率、平均處理時(shí)效等。管理要求進(jìn)一步提升之后,還可能需要度量SLA的達(dá)成情況?;谳p量的報(bào)表引擎,可以靈活動(dòng)態(tài)響應(yīng)此類(lèi)度量要求,通過(guò)數(shù)據(jù)接入、度量維度定義、度量指標(biāo)定義、儀表盤(pán)編排等能力快速溝通運(yùn)維度量報(bào)表。
運(yùn)維工作臺(tái)構(gòu)建
圖13
ITSM面向的用戶(hù)廣泛,不僅有運(yùn)維工程師,還有終端普通用戶(hù)、運(yùn)維領(lǐng)導(dǎo)等。不同角色關(guān)注的重心不一樣,為了提供更好的體驗(yàn),面向用戶(hù)的視圖可能是千人千面的,基于視圖引擎,可以定義不同的視圖內(nèi)容、視圖排版、視圖樣式等,以滿(mǎn)足交互和視覺(jué)層面的個(gè)性化訴求。
總結(jié)
低代碼本質(zhì)上還是一種“開(kāi)發(fā)語(yǔ)言”,而不是組件的堆砌和拼裝。流程管理領(lǐng)域的低代碼技術(shù)相對(duì)成熟,有完善的建模語(yǔ)言作為支撐。因此,低代碼技術(shù)可以在ITSM領(lǐng)域較好的發(fā)揮其價(jià)值,以應(yīng)對(duì)流程數(shù)量的激增、管理要求的頻繁變化等,更好地助力IT服務(wù)管理的數(shù)字化建設(shè)。
版權(quán)聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶(hù)自發(fā)貢獻(xiàn),該文觀點(diǎn)僅代表作者本人。本站僅提供信息存儲(chǔ)空間服務(wù),不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容, 請(qǐng)發(fā)送郵件至 舉報(bào),一經(jīng)查實(shí),本站將立刻刪除。