首頁 > 像云原生企業一樣，許多大型或老牌企業希望盡可能提高運營的自動化程度。因此，許多企業在流程自動化目標方面過于雄心勃勃，試圖推出面向整個組織的數字化轉型項目。雖然有野心是好事，但許多這類項目需要數年才能完成，常常需要將遺留系統推倒重來。
很少有企業考慮到端到端流程自動化需要在人員、流程和技術等方面改變觀念。不妨看看三個最常見的流程自動化錯誤，以及企業如何協同解決這些錯誤。
一、推出戰略性自動化項目過快
雖然力求戰略性沒有錯，但考慮過大的規模是過于雄心勃勃的自動化項目的常見陷阱。過早承擔太多的戰略性工作帶來很大的風險：企業在很長一段時間內看不到任何業務價值。因此，開發人員很可能陷入這種困境：在不了解用例的情況下設計一種復雜平臺。
相反，嘗試將龐大的戰略性項目分成幾部分，先從最緊急或最重要的項目入手。以下是這么做的一種方法：
-
從試點項目開始：試點項目的目標是定義并驗證架構和堆棧。這個試點項目通常充當概念驗證(PoC)。然而，上線試點項目很重要，以便真正了解工作流解決方案在整個軟件開發生命周期(SDLC)的所有方面。
-
加快到燈塔項目：運行成功的試點項目后不久，應處理燈塔項目。燈塔項目應該有更廣泛但仍然切合實際的范圍，以便向貴組織的其他人和團隊展示工作流自動化的架構、工具和價值。
-
進入到大規模轉型：利用從燈塔項目汲取的經驗教訓，使該項目團隊的人員能夠運行卓越中心(CoE)，從而打破團隊之間的孤島，并推動面向整個組織的變革。
我稱這種方法為“漸進式轉型的藝術”。理想情況下，在開展大規模自動化項目之前，嘗試勾勒整個流程生態系統——包括在后臺的相關人員、系統和設備。先更新改造對客戶影響最大的流程。然后設計一種轉型方法，適合業務或客戶的需求，而不是適合貴公司技術堆棧的需求。
二、孤立地處理自動化項目
盡管建議采用漸進式轉型方法，但并不意味著“孤立”或不成體系。如果每個團隊都選擇自己的工具，很難實現面向整個組織的變革或端到端流程自動化。技術決策需要承諾多年甚至數十年的投入。這些決策和隨之而來的維護影響的不僅僅是當前的一線團隊。
如上所述，CoE方法有助于打破組織孤島，分享關于以前的自動化項目中哪些管用、哪些不管用的優秀實踐。理想情況下，該小組并不硬性規定任意標準，而是維護可在整個公司重復使用的一系列已批準的工具和框架。
除了工具外，CoE 還可以維護入門指南、項目模板和可重用的開源組件/庫，供團隊利用。此外，它們還可以充當自動化代言人，通過運作社區針對公司內部的新自動化項目加強宣傳。在此框架內，更多團隊可以從自動化在本部門內的潛力中獲得啟發。
三、未擁抱微服務架構
要考慮的一個重要因素是公司內部構建軟件的方式。傳統公司擁抱微服務架構說起來容易做起來難。常常存在難以取代的遺留系統。據估計，仍有超過2000億行代碼是用COBOL(一種有數十年歷史的編程語言)編寫的。大規模更換這些系統可能至少需要4萬億美元到8萬億美元。
這時候漸進式轉型方法有了用武之地。比如說，許多公司已實施了初步自動化，RPA 實施在遺留系統(比如用COBOL編寫的系統)上。適合這種場景的好方法就是，分三個主要階段進行現代化改造：
-
沿端到端業務流程編排所有這些RPA機器人驅動的本地任務自動化。
-
按優先級順序逐一棄用這些機器人
-
致力于將底層業務邏輯重寫成微服務，而微服務可以沿端到端業務流程再次加以編排
基于微服務的自動化工作流具有的優勢在于，它允許分散式架構，其中每個團隊“負責”各自的隔離流程。萬一某個流程出現了問題，可以輕松控制和修復問題。此后，流程引擎可以在整個組織“驅動”這些基于微服務的流程，并且在必要時將這些流程統一起來。
總之，端到端流程編排不可能憑空發生。整個組織的利益相關者都應參與進來，項目應該從小處著手。如果沒有明確的試點項目，大規模的戰略性自動化工作很容易無法證明業務價值。只有齊心協力確定優先級、創建優秀實踐并推出所需的技術變革，組織才可以確保端到端流程自動化成功實現。
文章來源：51CTO
