工單管理模塊建設思路

楊建榮的學習筆記2018-08-16 23:53:19

    工單是運維工作裏面的硬通貨,在多年之前我們口口相傳,no 工單,no work,但是似乎在很多公司裏面對於工單的管理都不夠給力或者給予的重視程度有一些落差。 

    運維工作其實也是一種服務,所以對於運維提供的服務來説,甭管你是使用了高大上的方式或者規範的流程還是手工處理,如果高效完成,那對於應用來説就是大大的贊。 

    實際上,很多公司裏面的工單基本會和兩類屬性掛鈎,一類屬性是部門預算,或者説是工時,比如處理一個問題,需要花費2個小時,那麼這個服務就可以通過工時的方式來評估服務的結算費用,第二類屬性是服務質量,比如工單的處理結果是否滿意,是否有一些規範的操作流程等,這些是需要做工單反饋的。

    對於工單處理的一個痛點來説,就是紙質工單,如果工單使用紙質方式,質量還能基本保證,效率那就不可控了。

    第二類痛點是偽電子工單,即工單是通過前端頁面輸入的,但是工單的信息都需要大量的附件,附件裏面才是真正的需求,比如excel,比如word甚至SQL語句。 

    第三類痛點是模糊需求工單,即工單是電子的方式提交的,但是工單的需求是一個模糊需求,為什麼是模糊,因為工單裏面全是大量的文字,需求和目標都不是很明確,你需要像做閲讀理解一樣去解析工單。

    第四類痛點是繁瑣的審批程序,如果一個工單的處理流程需要經手多個人,那麼工單就會成為強審批的單據,即工單有了過度的安全屬性,而對於運維屬性重視度不夠。 這種情況下你去統計工單的處理效率,那結果肯定會有很大的落差。 

    第五類是工單的邊界比較模糊,比如申請賬號權限,如果業務同學申請數據庫的賬號權限,那麼肯定需要開通系統層面的防火牆權限,這是一個連帶的工作,我們如果要求業務同學開通一個數據庫權限的工單,然後再開一個開通系統權限的工單,雙方就會比較疑惑。從解決問題的角度來説,這種體驗是很差的。

    對於來説,不同公司的定位不同,有的公司放在OA裏面,有的是獨立的OMS模塊,有的叫做MIS,有的和工作流是獨立的模塊,本質上還是和各個公司所處的行業屬性有一定的關係。 

    至於和運維模塊的建設,哪個在先?其實這是一個互相促進的過程。早期的工單肯定沒有自動化運維的輔助,所以肯定是有工單模塊,但是早期的工單模塊建設肯定不夠完善,基本操作和審批是脱節的,那就需要完成工單的自動化處理。互相促進之後,這就是一個完善的鏈條了。

    所以簡單來説,工單系統和運維繫統需要對接起來,對接之後就能夠互相關注自己特定的業務範圍,把每一個環節都做到了可控和可考核。 

    工單系統的對接就好比是水渠引水一樣,第一步不能邁得太大,比如雙方的平台技術體系不同,接口規範不同,認證機制不同等,剛開始做深度對接,其實在前期會有很多額外的工作和調試成本。如果步子太大,可能達不到預期,為後期的接入還會帶來一些隱患。 

    從我建設的思路來説,第一步是申請工單系統的接口權限,即工單的審批還是在已有的工單系統中完成,而工單的信息一定有一個流水編號,是一個唯一的ID值,我需要的就是根據這個唯一的編號能夠從工單系統中得到一個JSON數據串,得到這個數據串之後我來解析它把它拆分為符合業務屬性的工單。所以所做的工作會分為以下幾個步驟:

  1. 解析工單信息,根據流水號信息解析工單的格式

  2. 工單拆分,把原來的一個多個業務工單,這個過程對應用同學來説是透明的。比如數據庫權限開通的工單,會自動拆分為兩個工單,數據庫權限工單和系統權限工單。 

這個階段的意義在於,兩個系統開始對接起來了,雖然不是一種很自然的對接方式,但是彼此打開了一扇窗。 

    第二個階段就可以更近一步,這個時候我們可以對工單系統開放接口,讓他們把數據推送過來,就不用我們去拉取了。這將是一個自動的推送過程,可以省去很多的檢查和反覆確認環節。 

    這個階段的工作的一大亮點就在於我們可以在工單拆分為業務工單,處理完成之後,確認工單完成,讓工單系統開放一個寫入接口,我們把工單的狀態回傳過去。這樣業務操作就形成了一個閉環。形成閉環是這個階段最重要的一件事情,這樣審批的關注審批環節,業務操作的關注業務操作環節,各司其職。

    第三階段是更大的一個階段,比如我們的工單可以和外部的系統通過接口交互,那麼我們就可以和其他系統開始打通這個鏈路。 這是一個更大更全面的過程,會有更多的事情和接口需要對接。 

    這個階段的意義就在於,這是一個全鏈條的過程,我們可以在這個階段更多的挖掘運維數據的價值,比如工單的處理效率,工單的數據統計分析,工單的指派,業務工單拆分 邏輯等。 這些都可以逐步的細化和改進。 













閲讀原文

TAGS: