SAP成都研究院許聚龍：Hello, Coresystems！

Jerry的前一篇文章《SAP成都研究院數字創新空間溝通S/4HANA和C/4HANA的智能服務演示視頻和Coresystems分享預告》已經提到，接下來會由SAP成都研究院數字創新空間的同事BD君給你們分享Coresystems。

那篇文章發出來以後，有同事問我，BD君是誰？SAP成都研究院好像沒這我的。

BD君 = 許聚龍(Xu Haytham)。記得聚龍第一次給咱們作自我介紹時，Jerry一聽名字，以爲好霸氣，"許巨龍"，內心就打上了Big Dragoon的標籤。

聚龍和Jerry是校友，目前是電子科技大學的本科生，讀大四上期。Jerry當初研究生畢業加入SAP成都研究院初期時一直是個愣頭青，什麼都不懂。而聚龍在校期間，有過休學創業的經歷，因此和普通的大四學生相比，多了幾分紅熟和穩重。

在Jerry的前一篇文章《SAP成都研究院數字創新空間溝通S/4HANA和C/4HANA的智能服務演示視頻和Coresystems分享預告》提到，說到雙截棍的技能，聚龍的水平算得上Jerry的師傅，這裏就不重複了。

說到聚龍的名字Dragon，想起一件讓Jerry很囧的事。一次Jerry和朋友吃飯聊天，聊到二戰的美國和日本。你們都是遊戲迷，談到日本雖然卑劣地進行了珍珠港偷襲，然而美國人仍是很給日本面子，在《星際爭霸》裏以日本的大和號戰列艦爲原型設計了人族空軍的終極單位：Battle Cruiser。

造價：400水晶，300氣。HP：500，佔用人口：6，建造時間：90，並且還有一個技能：Yamato Gun。

當時你們慨嘆《星際爭霸》裏沒有CHINA元素，而後Jerry就說，龍騎士好歹字面上也有個龍吧，雖然和CHINA傳統意義上的」龍「含義徹底不一樣。有位學霸朋友說，「你再仔細看看？龍騎士的單詞和龍的單詞是兩個不一樣的單詞。」 Jerry仔細看了下，發現還真是這樣，又長見識了：

• dragon: 西方神話中一種強大的生物，一般是邪惡的象徵，和CHINA的龍大相徑庭。

• **dragoon: **龍騎兵團，重騎兵，星際爭霸中的龍騎士。神族的狂熱者的肉體損壞後，將殘體取放入特殊成分的養分液中，存放於機甲裏造成的機械兵種。

看到dragoon，Jerry情不自禁就能回憶起昔日神族的領袖bisu，那華麗的dragoon操做和宿敵解凍大魔王那一場場經典的PVZ。

那是一個讓每一位星際爭霸迷一回憶起來就會熱血澎湃的激情年代。

扯遠了，下面是許聚龍的正文。

---

這篇文章主要向各位介紹SAP你們族的新成員之一：Coresystems，讓你們知道Coresystems是什麼，如何運行，以及它的一些特點功能。文章分爲上下兩部分，上半部分經過一個案例較爲直觀地介紹Coresystems，下半部分將深刻系統，介紹部分特點模塊的細節，你們可根據本身的須要選擇閱讀。

相信你們不管做爲我的仍是企業，都有過購買設備並聯系廠家安裝、維護(維修)的經歷。你們可能會遇到過一些問題，好比：在提供服務的工程師上門以前，沒法知道TA是誰，以及具體何時能到。我本身就有過一次糟糕的體驗，前段時間在某大型家電線下實體店購買了某國際大品牌洗衣機與冰箱。在配送當天，須要做爲客戶的我來協調配送與安裝技師的上門時間，可是兩者均沒有按照約定時間到來，通過反覆催促，最後在約定時間的3.5小時後才完成，嚴重打亂了我後續的安排。最後的簽收與檢查清單等，也都是紙質文件。對我而言，這一切是一場糟糕至極的體驗。而這個服務場景，正好是本文介紹的Coresystems能夠充分體現本身強大功能的舞臺。

Coresystems公司成立於2006年，以其重要產品Coresystems服務於世界各個國家，截至2015年全球已有8個分部。

2018年6月被SAP收購，歸入了SAP C/4HANA五朵雲的服務雲中。做爲「智慧企業客戶體驗」案例的一部分，Coresystems在2018年下半年舉辦的SAP NOW，雲棲大會，HUAWEI CONNECT等展會上也頻頻亮相。

發展到今天的Coresystems，功能已十分豐富。除了核心模塊「現場服務」，還加入了「衆包服務」、「Coresystems NOW(自助服務)」、「物聯網」、「整合」等強大的模塊，並嚴格遵照GDPR(通用數據保護條例)。

因爲篇幅有限、我將簡單介紹主要模塊的功能，而後聚焦到Coresystems的核心模塊「現場服務「。

「現場服務」模塊：Coresystems的核心與根基，具備極高的抽象性，除了標準的工單生成、委派、到場服務外，Coresystems在各流程都實現了高度的可配性，使它可以制定出幾乎大部分的實際場景。

這種系統的高度可配置性，卻是和SAP傳統的基於Netweaver的衆多產品相似，這真是「不是一家人，不入一家門」。

**「衆包服務」模塊：也就是官網上花了突出版面介紹的又一個核心模塊，Crowd Service。衆包服務容許系統內甲乙兩公司彼此之間締結合做關係，**即甲公司能夠將服務工單分發給乙公司的工程師來完成。該模塊能夠在短期拓展公司服務的地理覆蓋面積，並在用人高峯期經過分發工單減小客戶等待時長，極大的優化用戶體驗。

「Coresystems NOW」：NOW是新推出的客戶自助服務模塊，支持7x24客戶在線自助服務，只需掃描設備上二維碼便可獲取相應設備的資料，並找到常見問題的說明與解決方式，同時能夠經過NOW端自定義提交服務工單。

「物聯網」：Coresystems提供的一種物聯網解決方案，可以將客戶的設備鏈接到Coresystems，在系統內監控設備狀態。

「整合」：Coresystems支持經過Cloud Connector或REST API與SAP現有系統（ERP、CRM等）進行打通，實現整合。

好了，咱們如今聚焦到「現場服務」模塊。做爲Coresystems的根基，「現場服務」其實是不少功能的集合，其具體組成將在文章第二部分介紹。我將從系統角色，核心概念以及一個場景案例帶你們認識感性地去認識Coresystems。

系統角色

Coresystems裏有如下幾種角色：

• 客戶：現場服務提出者，能夠經過打電話給調度員或經過NOW模塊自助產生工單。

• 調度員：維護系統各類主數據，建立工單，分發工單給工程師。

• 工程師：接收工單併到客戶現場進行服務。

• 管理人員：能夠經過數據可視化模塊查看系統內數據分析與報告。

系統的部分核心名詞，概念和對象關係

這些名詞其實並非Coresystems首創的，任何成熟的帶有服務模塊的CRM系統，好比SAP CRM和SAP Cloud for Customer中都存在這些概念。

• Skills(技能)：Skills是Coresystems裏最根基的組成，幾乎全部其餘對象均可以綁定一個或多個Skills。Skills能夠在對應模塊自定義添加。這個詞的範圍很廣，能夠是真實的工程技能如：電工、機械工程；也能夠是相似語言、性格等軟技能。

• **Service Call(服務呼叫)：**調度員在WEB端建立的服務工單便是一個「服務呼叫」。服務呼叫建立完即會生成一個Activity與之對應，Activity的來源有不少，服務呼叫是其中之一。

• **Activity(活動)：**Activity是Coresystems最多見的的基本單位，Activity通常由調度員建立，是系統內任務的最小單位。

從圖中能夠看出Activity幾乎與系統內的全部數據都會有直接或間接的關聯。一個Activity會委派給一個工程師處理，而Activity在實際情境中能夠衍生出後續Activity。Activity的委派是基於Skill的，Coresystems會自動檢測被委派的工程師是否具備相應技能，若是沒有會給出警告(可是依然能夠強制委派)。

最後咱們開始咱們的案例，來認識一下咱們使用Coresystem提供服務場景案例的3位主人公。

• 客戶：綠野種子集團的生產主管曾海瑞

• 調度員：藍天機器人公司李莉

• 工程師：藍天機器人公司李曉剛

Jerry：個人同事李曉剛已經在咱們的服務場景裏以技師的身份屢次出現。關於他的事蹟和照片，在這篇文章裏能夠找到：《打通C/4HANA和S/4HANA的一個原型開發：智能服務創新案例》。李曉剛是SAP成都研究院C4C開發團隊的中堅力量，微信暱稱：心靈鴨子湯。這是他對本身的評價：

藍天技工李曉剛，

一手佛經一手槍。

雙臂關公學龍哥，

飛鏢指向麥口楊。

自稱編程彭于晏，

一身肥肉很囂張。

自我嘲諷需勇氣，

乾了這碗鴨子湯。

因爲舊機械臂的產能沒法知足快速增加的市場需求，曾海瑞向藍天機器人公司採購了一批性能更強的「機械臂系列9」，如今他須要專業的工程師來安裝機械臂，因而他撥打了服務熱線，提出了本身的服務需求。

調度員李莉接到了曾海瑞的電話，在Coresystems中建立了一個新的「服務呼叫」：

並完善基本數據(客戶信息、服務時間等)：

結束通話後李莉查看當前工程師工做計劃表，發現技師李曉剛的時間與技能狀況十分適合該工做：

因而便將該「服務呼叫」(工單)拖拽到李曉剛的行程表中，系統自動檢測技能匹配狀況，驗證成功後，李莉點擊「發佈」，將工單推送給李曉剛：

調度員李莉工做結束。

李曉剛這時手機會收到含有工做信息的短信提醒：

因而他打開手機app查看到這次工做內容：

覈對信息後，李曉剛點擊屏幕底部的「接受」按鈕，確認了此次任務安排：

到了曾海瑞預定安裝當天，曾海瑞將收到一個連接，打開後能夠實時顯示李曉剛的位置信息：

李曉剛到達現場後，在Coresystems終端的協助下開始了安裝工做：

工做完成後，李曉剛將終端交由曾海瑞打分評價，並簽字確認，該次現場服務結束。

以上就是一個簡單的「現場服務」的流程。看到此處，我想讀者應該已經可以在感性層面大體知道Coresystems是什麼，以及怎麼運行的了。

下面開始的內容，將深刻系統細節，從系統的模塊組成，特點功能(離線模式、AI智能委派、報表自定義、項目管理、流程定製)幾個方面深刻介紹Coresystems的強大之處。如下內容可能比較枯燥與硬核，讀者可根據本身的狀況選擇是否繼續看下去。

---

Coresystems的特點功能

Coresystems「現場服務」的組成部分很是多，在此我根據我的理解將系統模塊簡單分爲4大類:數據管理部分、現場服務部分、加強自定義部分和其餘。

1. 數據管理部分

主要包含Skills（技能）、Business Partners（合做夥伴）、People（員工）、Item（包含物料與倉庫）、Equipment（設備）、Contact List（通訊錄）。以上模塊的共同特色是其主要功能都是用於存儲數據。這些信息都具備各自獨立的屬性列表，同時又具備如圖所示的關聯關係，從而構建出詳細的系統主數據。

2. 現場服務部分

包含Planning(委派中心)、Service Calls(服務呼叫)、Activity(活動)。其中Activity是核心，它整合了幾乎數據管理模塊的全部數據。Service Calls建立後會自動生成一個Activity與之對應。Planning是委派Activity給工程師的模塊，也是調度員最常使用的模塊。這些模塊共同組成了推進」現場服務」流程的發動機。

3. 自定義配置部分

包含Analytics & Reporting(報表)、Knowledge Management（清單定製）、Project Management(項目管理)。該部分的這三個模塊是讓我最驚豔的，用於加強「現場服務」的功能，經過它們分別能夠實現自定義報表公式、自定義現場服務清單流程、大項目流程跟進。稍後都將詳細介紹。

4. 其餘

包含Setting、Time & MaterialJournal、Report等，包括員工上班時間設置、物料以及開銷彙總、現場生成報告查看等功能。

系統特點點

Coresystems的這些特點點，各位SAP老司機們也能夠同SAP其餘包含服務模塊的產品作一個對比。

離線模式

同SAP Cloud for Customer的移動端同樣，Coresystems的移動端也是自帶離線模式的。這個設計的目的是可以在網絡環境較差、甚至沒有網絡的狀況下(如碼頭、地下等)依然能夠在終端的協助下進行工做。

AI智能委派

Coresystems支持2種分配模式：手動委派(如以前案例中介紹的方式)和AI智能委派。在AI智能委派模式下，無需調度員耗費時間和人工去對比工程師技能與時間信息，只需將工單拖拽到智能分配區，系統即可以自動將工單委派給算法推薦的最合適的人選，大大提升委派員的工做效率。

這裏多說一句，SAP Cloud for Customer(C4C)的服務請求(系統裏稱爲Tickets)也具備機器學習的支持，只不過場景和Coresystems的AI委派有所不一樣。C4C的服務請求建立好以後，系統根據請求的主題和描述這兩個擡頭字段，調用機器學習服務器的API，計算出這個服務請求的類別建議(Service Category Proposal)。

報表自定義

Analytics & Reporting，一個數據可視化模塊，以上截圖是模塊主界面，從圖中能夠看出該模塊支持柱狀圖、餅狀圖、折線圖等形式來展現「自定義」數據。

每一個模塊的設置頁面局部截圖以下所示：

從設置圖能夠看出每個數據展現塊都支持任意切換3種轉換方式，而「sample chart「可選擇內置報表樣板，如：服務呼叫來源類型、服務呼叫頻率等。但這都不是最有意思的，咱們細看「Advanced Settings」能夠發現「Query」內是能夠寫SQL語句的，也就是說能夠根據須要隨時建立新的的報表樣板，並實時展現。

項目管理

Project Management，該模塊具備拓寬現場服務時間維度的功能。

正常的「現場服務」以Activity爲單位，快速建立，完成後關閉，工做內容固定且單一，沒法管理長期的、分步驟的項目。而Project Management能夠很好的解決這個問題，首先來看看主頁面：

「Project」是項目列表，在此處展現全部建立過的項目，右側是一個項目的具體步驟信息，能夠經過「+」按鈕自定義添加「階段」，而且在對應階段裏建立「Activity」，每一個階段均可以選擇性地編輯以下圖所示的信息，來豐富內容：

而在右側，則是階段對應的甘特圖，甘特圖內的時間跨度能夠經過鼠標拖拽變化、且能夠鎖定先後階段的關係(如圖中帶鎖部分)，鎖定後必須按順序執行不一樣階段。

在建立一個Project時，能夠選擇不一樣維度做爲發佈方式，具備「Project、Equipment、Activity「三種方式，方便根據實際狀況選擇不一樣方式。

流程定製

Coresystems爲了實現」現場服務」的規範化，針對不一樣的場景能夠製做很是細緻的流程指導，不一樣工程師在移動終端上按照流程執行，能夠極大地提升效率且減小缺漏。"流程定製"模塊就是用來自定義工做流程的。

先來看看主界面：

未打碼展現的流程模板都是我建立的測試數據。從主界面能夠看出，每個「Check List」都具備不少標籤與描述等常規屬性，特別須要指出的是該部分具備「版本」屬性，實現了一個簡單的版本管理功能。每一個「Check List」均可以建立副本，且獨立管理髮布狀態。

從圖中能夠看出我一共建立了5個不一樣的版本，其中3個處於發佈狀態。

下圖是一個「Check List」的明細頁面：

從圖中能夠看出，與「Project Management」相似，「Check List」也具備階段劃分，且具備數字表示，更加直觀。

右側則是系統組件列表，一共有17種組件可用，分別爲:主分支、子分支、文本輸入框、標籤、表格、下拉框、簽名、日期、數字輸入、附件、附件選擇器、公式計算器、主數據選擇器、系列、狀態、分頁符。

建立好階段後，能夠根據需求向每一個階段放入須要的組件，最後每個小階段內的全部組件，都將生成一個獨立的頁面，在移動終端顯示。

每個組件都具備經常使用的基本屬性，好比下圖顯示了」文本輸入框」這個組件的基本屬性：

以及高級設置：

在高級設置中，有兩個屬性比較有特點。你們請看上圖第一個勾選框「Internal」，其做用與「衆包服務」相關。一旦勾選後，只有公司內部員工才能夠在移動端查看或修改該組件的內容，而外部人員是沒法看到的(用於填寫內部價格等)。

而「Use Visibility Codition」 也比較有意思，這裏首先須要填寫當前Check List內一個組件的id，而後完善整個邏輯表達式。只有該邏輯表達式成立時，這個階段的內容纔會顯示。這就意味着能夠在不編寫代碼的狀況下定義出具備分支的業務流程。

此外模板支持導入功能，能夠直接編寫XML生成一個Check List。

最後來看看節選的部分組件在移動端的效果吧：

此次對Coresystems的介紹就到這裏，有機會我將會再寫續篇詳細介紹包括」衆包服務」在內的其餘特點模塊。感謝各位讀者耐心看完了整篇文章，再見。

更多閱讀

• 打通C/4HANA和S/4HANA的一個原型開發：智能服務創新案例

• SAP成都研究院數字創新空間溝通S/4HANA和C/4HANA的智能服務演示視頻和Coresystems分享預告