EE-華為智能化供應(yīng)鏈ISC加變革項(xiàng)目服務(wù)化工作指導(dǎo)書-2016

智能供應(yīng)鏈ISC+變革項(xiàng)目

服務(wù)化工作指導(dǎo)書

2016年12月1Agenda21為什么要做服務(wù)化ISC+服務(wù)化V模型服務(wù)化工作方法23服務(wù)識別與定義3.1服務(wù)設(shè)計(jì)與實(shí)現(xiàn)3.2服務(wù)管理與運(yùn)營3.3持續(xù)交付流程3.4單體應(yīng)?：功能集中、代碼中心化、一個(gè)發(fā)布包、部署后運(yùn)行在同?進(jìn)程的應(yīng)?程序。傳統(tǒng)的WEB工程是將服務(wù)端所有的功能模塊打包到一起并放在一個(gè)WEB容器中運(yùn)行。很多企業(yè)的Java應(yīng)用程序打包為WAR包。下圖所示為一個(gè)在線商店系統(tǒng)的功能：客戶下訂單、核對清單和信用卡額度，并將貨物運(yùn)輸給客戶。傳統(tǒng)單體應(yīng)用的技術(shù)架構(gòu)隨著應(yīng)用的功能越來越龐大，訪問量越來越大，需求變化越來越快，單體應(yīng)用架構(gòu)經(jīng)常會遇到以下幾方面的痛點(diǎn)太慢根據(jù)技能劃分團(tuán)隊(duì)——UI、應(yīng)用、中間件、數(shù)據(jù)庫等太脆弱一個(gè)bug可能很快導(dǎo)致整個(gè)系統(tǒng)癱瘓測試效率低每次變更需要全部完整的驗(yàn)證測試，難以支撐持續(xù)交付。責(zé)任不明確代碼是共同災(zāi)難的受害者，責(zé)任不明確時(shí)，忽視成為常態(tài)太復(fù)雜應(yīng)用變得越來越大和復(fù)雜，開發(fā)人員越來越難以理解。共享層（ORM，消息等）不得不處理100%的用例，而不是單個(gè)的解決方案責(zé)任不明確太慢針對性擴(kuò)展差太復(fù)雜測試效率低太脆弱針對性擴(kuò)展差應(yīng)用的不同部分有不同的性能需要——更多CPU、更多內(nèi)存、更快網(wǎng)絡(luò)等為了解決上述痛點(diǎn)，單體應(yīng)用技術(shù)架構(gòu)的擴(kuò)展方式為應(yīng)對業(yè)務(wù)量增長，應(yīng)用系統(tǒng)可以從三個(gè)維度擴(kuò)展：X軸擴(kuò)展，水平復(fù)制。即在負(fù)載均衡服務(wù)器后增加多個(gè)WEB服務(wù)器；Z軸擴(kuò)展，數(shù)據(jù)劃分。即分庫分表（分庫是將關(guān)系緊密的表放在一臺數(shù)據(jù)庫服務(wù)器上，分表是因?yàn)橐粡埍淼臄?shù)據(jù)太多，需要將一張表的數(shù)據(jù)存在不同的數(shù)據(jù)庫服務(wù)器）；Y軸擴(kuò)展，功能分解。將不同職能的模塊分成不同的服務(wù)。從Y軸這個(gè)方向擴(kuò)展，才能將單體應(yīng)用分解為不同的服務(wù)，例如訂單管理中心、客戶信息管理中心、商品管理中心等。單體應(yīng)用復(fù)制和負(fù)載平衡X軸擴(kuò)展—水平復(fù)制多服務(wù)類型Y軸擴(kuò)展—功能分解Z軸擴(kuò)展—數(shù)據(jù)劃分AKF可擴(kuò)展立方（ScalabilityCube）**AKF可擴(kuò)展立方（ScalabilityCube）來自《可擴(kuò)展的藝術(shù)》服務(wù)化的Y軸拆分單體應(yīng)用策略6單一職責(zé)原則（SRP）將改變原因相同的聚在一起，將改變原因不同的相分離；SRP將類職責(zé)定義為變更理由，并且是類變更的唯一理由。將SRP應(yīng)用于服務(wù)設(shè)計(jì)，一個(gè)服務(wù)只完成某一類功能，跨功能則需要拆分服務(wù)借鑒Unix工具的設(shè)計(jì)Unix提供大量的實(shí)用小工具，比如grep、cat、find、ps等。每個(gè)實(shí)用小程序僅將一件事情做到極致。它們可以通過shell腳本連接起來，從而執(zhí)行復(fù)雜的任務(wù)。在Unix工具中對服務(wù)建模并創(chuàng)建單一功能服務(wù)很有道理動詞或者用例（Usecase）劃分系統(tǒng)例如，經(jīng)過劃分的電子商務(wù)應(yīng)用具有負(fù)責(zé)訂單運(yùn)送的發(fā)貨服務(wù)。另一個(gè)通過動詞劃分例子是實(shí)現(xiàn)登錄服務(wù)的Login服務(wù)通過名詞或者資源劃分系統(tǒng)這種服務(wù)負(fù)責(zé)給定類型資源或者實(shí)體的所有操作。例如，在電子商務(wù)應(yīng)用中看到的，通過“庫存服務(wù)”跟蹤倉庫中的產(chǎn)品；在線商店擁有“目錄服務(wù)”領(lǐng)域模型驅(qū)動設(shè)計(jì)（DDD,DomainDrivenDesign）把復(fù)雜的領(lǐng)域拆分成不同上下文邊界以及它們之間的關(guān)系。這樣的過程對于整體架構(gòu)和微服務(wù)框架都很有用，服務(wù)間存在著明顯的關(guān)系，幫助我們對上下文邊界進(jìn)行區(qū)分領(lǐng)域驅(qū)動設(shè)計(jì)方法原則參考實(shí)踐操作根據(jù)功能和資源分解單體應(yīng)用后，形成微服務(wù)（服務(wù)化子系統(tǒng)）的應(yīng)用架構(gòu)示例復(fù)用服務(wù)，靈活插拔，可柔性編排通過對服務(wù)的復(fù)用和編排快速實(shí)現(xiàn)新的業(yè)務(wù)場景通過對服務(wù)的優(yōu)化和調(diào)整來快速實(shí)現(xiàn)業(yè)務(wù)活動的操作變化小應(yīng)用，快速靈活響應(yīng)業(yè)務(wù)變化基于服務(wù)設(shè)計(jì)實(shí)現(xiàn)的輕應(yīng)用，松耦合，獨(dú)立交付影響面小，交付效率提升，快速響應(yīng)業(yè)務(wù)變化快速擴(kuò)展，成效好橫向擴(kuò)展便利，只需要擴(kuò)展所需部分，擴(kuò)展性更強(qiáng)、成本更低快速開發(fā)、高頻部署各個(gè)服務(wù)獨(dú)立開發(fā)、獨(dú)立部署、獨(dú)立運(yùn)營，提高開發(fā)效率和部署頻率，降低測試時(shí)間和部署風(fēng)險(xiǎn)服務(wù)化帶來的收益4Agenda91為什么要做服務(wù)化ISC+服務(wù)化V模型服務(wù)化工作方法23服務(wù)識別與定義3.1服務(wù)設(shè)計(jì)與實(shí)現(xiàn)3.2服務(wù)管理與運(yùn)營3.3持續(xù)交付流程3.4概念高階設(shè)計(jì)階段詳細(xì)設(shè)計(jì)階段1應(yīng)用組是應(yīng)用域的細(xì)分，是一組強(qiáng)相關(guān)應(yīng)用的組合業(yè)務(wù)子領(lǐng)域業(yè)務(wù)領(lǐng)域下的具體子領(lǐng)域劃分業(yè)務(wù)能力對應(yīng)于業(yè)務(wù)子域下的具體能力定義，目前ISC+對應(yīng)于L3的能力定義業(yè)務(wù)領(lǐng)域針對業(yè)務(wù)所處的企業(yè)業(yè)務(wù)領(lǐng)域范疇?wèi)?yīng)用域應(yīng)用功能模型最高層分組，將應(yīng)用架構(gòu)的交付分為幾個(gè)大的領(lǐng)域服務(wù)化子系統(tǒng)由業(yè)務(wù)服務(wù)組合而成，支持一組相關(guān)業(yè)務(wù)活動的應(yīng)用，可獨(dú)立部署應(yīng)用組ApplicationGroup應(yīng)用域ApplicationDomain業(yè)務(wù)領(lǐng)域BusinessDomain業(yè)務(wù)子領(lǐng)域BusinessSub-Domain業(yè)務(wù)能力BusinessCapability服務(wù)化子系統(tǒng)ApplicationIT業(yè)務(wù)業(yè)務(wù)活動(Activity)業(yè)務(wù)服務(wù)(BusinessService)業(yè)務(wù)活動是對工作流中一個(gè)具體完整業(yè)務(wù)處理單元的詳細(xì)描述一般情況下一個(gè)業(yè)務(wù)能力對應(yīng)多個(gè)業(yè)務(wù)活動業(yè)務(wù)服務(wù)業(yè)務(wù)目的清晰，功能獨(dú)立完整單一的一組API或業(yè)務(wù)操作。在ISC+業(yè)務(wù)服務(wù)顆粒度定義原則如下：1、對相同或相似功能的業(yè)務(wù)活動的抽象與組裝；2、包含獨(dú)立的業(yè)務(wù)實(shí)體；識別、抽象業(yè)務(wù)活動通過活動識別業(yè)務(wù)服務(wù)進(jìn)行業(yè)務(wù)服務(wù)分組ISC+試點(diǎn)：服務(wù)化V模型6ISC+試點(diǎn)：包含主要的4個(gè)業(yè)務(wù)要素、5個(gè)應(yīng)用要素和7個(gè)數(shù)據(jù)要素，實(shí)現(xiàn)業(yè)務(wù)到IT服務(wù)拉通7應(yīng)用系統(tǒng)模型應(yīng)用功能模型1應(yīng)用組ApplicationGroup應(yīng)用域ApplicationDomain業(yè)務(wù)領(lǐng)域BusinessDomain業(yè)務(wù)子領(lǐng)域BusinessSub-Domain業(yè)務(wù)能力BusinessCapability服務(wù)化子系統(tǒng)Application業(yè)務(wù)活動(Activity)業(yè)務(wù)服務(wù)(BusinessService)業(yè)務(wù)能力業(yè)務(wù)場景工作流業(yè)務(wù)活動業(yè)務(wù)服務(wù)服務(wù)API服務(wù)分組ABB能力框架場景清單流程圖APPAGAD服務(wù)化子系統(tǒng)能力框架業(yè)務(wù)場景工作流業(yè)務(wù)活動業(yè)務(wù)服務(wù)(含服務(wù)API)服務(wù)化子系統(tǒng)應(yīng)用組應(yīng)用域服務(wù)API服務(wù)API服務(wù)API業(yè)務(wù)服務(wù)描述業(yè)務(wù)對象信息鏈概念模型邏輯模型數(shù)據(jù)流/數(shù)據(jù)源物理模型業(yè)務(wù)要素?cái)?shù)據(jù)要素圖例數(shù)據(jù)標(biāo)準(zhǔn)注：詳細(xì)的數(shù)據(jù)工作方法請參考《ISC+數(shù)據(jù)工作匯報(bào)》一個(gè)服務(wù)API實(shí)現(xiàn)了完整獨(dú)立單一的業(yè)務(wù)邏輯；服務(wù)API的顆粒度定義由服務(wù)消費(fèi)者驅(qū)動。TaskTaskTaskTask應(yīng)用要素業(yè)務(wù)側(cè)業(yè)務(wù)流程的級別12L6任務(wù)L5活動L4工作流L3

業(yè)務(wù)能力L2業(yè)務(wù)子領(lǐng)域L1業(yè)務(wù)領(lǐng)域價(jià)值鏈層級，從客戶價(jià)值出發(fā)，體現(xiàn)了公司的業(yè)務(wù)模式和價(jià)值鏈特點(diǎn)職能層級，表現(xiàn)公司內(nèi)部部門層級上，以達(dá)成內(nèi)部客戶需求為目的的各部門間或各崗位間的協(xié)作關(guān)系工作流分不同的級別，從描述企業(yè)增值的端到端工作流到描述一個(gè)角色具體活動的工作流活動的一部分，即子活動。將活動進(jìn)一步分解的目的在于便于理解和執(zhí)行用活動將流程分解成落實(shí)到角色的可執(zhí)行單元，實(shí)現(xiàn)人員的專業(yè)分工能力指為實(shí)現(xiàn)某一特定目標(biāo)的一組人力、流程和技術(shù)的集合ISC+服務(wù)化V模型定義的業(yè)務(wù)流程層級解釋業(yè)務(wù)能力定義13能力指為實(shí)現(xiàn)某一特定目標(biāo)的一組人力、流程和技術(shù)的集合。[1]能力管理指組織基于價(jià)值貢獻(xiàn)，結(jié)合公司客戶價(jià)值主張，來定義能力績效目標(biāo)，以剔除低效能力并聚焦能帶來財(cái)務(wù)收入的高效能力?！S基百科業(yè)務(wù)能力定義的是干什么，而非怎么做。業(yè)務(wù)能力能幫助企業(yè)實(shí)現(xiàn)期望達(dá)到的結(jié)果。在能力模型里，明確了不同層級的能力并給出了詳細(xì)定義，也就是我們經(jīng)常提到的L1,L2和L3能力（根據(jù)業(yè)務(wù)的復(fù)雜程度可能還會有更多層級），每下一層，能力會更加細(xì)化。問題關(guān)鍵詞能力說明

華為的定義What組織基于當(dāng)時(shí)的業(yè)務(wù)規(guī)則，記錄數(shù)據(jù)并使用數(shù)據(jù)引導(dǎo)系統(tǒng)行為對能力的文字描述Where地理基于當(dāng)時(shí)的業(yè)務(wù)規(guī)則，解決地理或空間分布問題，組織運(yùn)輸、物流和商務(wù)溝通執(zhí)行的地點(diǎn)How變革基于當(dāng)時(shí)的業(yè)務(wù)規(guī)則，負(fù)責(zé)流程執(zhí)行并創(chuàng)造附加值執(zhí)行方法，如流程，XXXWho互動基于當(dāng)時(shí)的業(yè)務(wù)規(guī)則，與用戶互動，支撐客戶達(dá)成某一期望行為。執(zhí)行的角色When時(shí)間基于當(dāng)時(shí)的業(yè)務(wù)規(guī)則，負(fù)責(zé)設(shè)定業(yè)務(wù)里程碑和編排流程的執(zhí)行能力執(zhí)行的時(shí)間點(diǎn)Why動機(jī)有能力展示業(yè)務(wù)目標(biāo)達(dá)成了，業(yè)務(wù)風(fēng)險(xiǎn)降低了以及當(dāng)時(shí)的的業(yè)務(wù)規(guī)則符合業(yè)務(wù)目標(biāo)預(yù)期。KPI的衡量關(guān)于能力的6個(gè)基本問題

14能力是一組人力、流程和技術(shù)的集合，如果詳細(xì)設(shè)計(jì)一個(gè)能力，我們將會從以下6個(gè)方面來綜合考慮：ISC+V模型從能力到活動15能力設(shè)計(jì)場景(工作流)->活動步驟:描述WHAT“做什么”–藍(lán)圖階段能力框架業(yè)務(wù)高階設(shè)計(jì)–單獨(dú)或共同能力融入面向未來的思考、愿景、領(lǐng)先實(shí)踐和前沿科技（例如大數(shù)據(jù)等）低階一些的能力需要在詳細(xì)設(shè)計(jì)中進(jìn)一步描述“做什么”步驟:考慮WHERE“在哪里”去定義場景能力可能會因?yàn)榈乩韰^(qū)域、業(yè)務(wù)或運(yùn)作模式等的不同而有差異，因此能力需要支撐多場景。舉例來說，不同的訂單類型可能會來自于不同的商業(yè)模式，這就需要在“訂單接收”和“訂單處理”能力下建立多重場景。用工作流來描述HOW“怎么做”，從而實(shí)現(xiàn)該能力。在工作流中，有邏輯關(guān)系的一系列業(yè)務(wù)活動支撐能力如何實(shí)現(xiàn)“誰”應(yīng)該作為“角色”被呈現(xiàn)。“什么時(shí)候”表述執(zhí)行時(shí)間點(diǎn)?！盀槭裁础弊鳛镵PI，用以度量客戶價(jià)值如何被影響。1）客戶：是流程服務(wù)的對象，對外來講是單位服務(wù)的個(gè)人或組織，對內(nèi)來講是流程的下一個(gè)環(huán)節(jié)；2）價(jià)值：是流程運(yùn)作為客戶帶來的好處，很多情況下不是用貨幣來衡量的，它可以表現(xiàn)為提高了效率、降低了成本等等；3）輸入：是運(yùn)作流程所必須的資源，不僅包括傳統(tǒng)的人、財(cái)、物，而且包括信息、關(guān)系、計(jì)劃等；4）活動：是流程運(yùn)作的環(huán)節(jié)；5）活動之間的相互作用：是環(huán)節(jié)之間的關(guān)系，把流程從頭尾串聯(lián)起來；6）輸出：流程運(yùn)作的結(jié)果，它應(yīng)該承載流程的價(jià)值。工作流的定義以及六要素16工作流是可以被重復(fù)執(zhí)行，邏輯上相互關(guān)聯(lián)的一組業(yè)務(wù)活動序列，將明確的輸入轉(zhuǎn)換成明確的輸出，從而實(shí)現(xiàn)為客戶和向客戶交付價(jià)值（產(chǎn)品和服務(wù)）的業(yè)務(wù)目的。工作流分不同的級別，從描述企業(yè)增值的端到端工作流到描述一個(gè)角色具體活動的工作流。□定義□工作流六要素活動（Activity）定義17□定義□解釋及說明

是流程的基本單元，是一組相互聯(lián)系的、有明確成果和輸出的任務(wù)或行動。如：匯總信息、確認(rèn)客戶資信度、評審方案一般以動賓結(jié)構(gòu)來命名（動詞+名詞）。每個(gè)活動都是由一個(gè)角色來負(fù)責(zé)，某些活動可以有協(xié)同參與的角色共同完成活動，但如果某項(xiàng)活動存在多個(gè)責(zé)任角色，需要拆分成不同活動，以便各負(fù)其責(zé)。每個(gè)活動都有明確的輸入、輸出，如果存在多個(gè)活動，其責(zé)任角色相同，輸入輸出相同，則建議對這些活動進(jìn)行合并。一般來說，流程活動描述要能直接指導(dǎo)業(yè)務(wù)操作，但對于較復(fù)雜的活動，可以下掛操作指導(dǎo)書做進(jìn)一步的細(xì)化說明。流程活動的顆粒度沒有嚴(yán)格的衡量標(biāo)準(zhǔn)，對于業(yè)務(wù)成熟度高（作業(yè)相對標(biāo)準(zhǔn)化、自動化率較高、員工技能嫻熟等）的流程活動描述可以概括、簡練，反之則要細(xì)化和詳細(xì)一些；流程活動的顆粒度還與IT相關(guān)，如果業(yè)務(wù)操作的IT化率較高，則流程活動描述相對概括、簡單，反之亦然。ActivityARoleARoleBActivityBInputInputoutput業(yè)務(wù)側(cè)術(shù)語范例18術(shù)語術(shù)語定義范例及說明業(yè)務(wù)領(lǐng)域針對業(yè)務(wù)所處的企業(yè)業(yè)務(wù)領(lǐng)域范疇針對業(yè)務(wù)所處的企業(yè)業(yè)務(wù)領(lǐng)域范疇，目前已有9大業(yè)務(wù)領(lǐng)域，包括：StrategyCustomerExperience/CustomerOrientedServiceInnovateandDev.MarketSellSupplyServeandSupportEcosystemManagementEnablement業(yè)務(wù)子領(lǐng)域業(yè)務(wù)領(lǐng)域下的具體子領(lǐng)域劃分業(yè)務(wù)領(lǐng)域下的具體子領(lǐng)域劃分，例如Supply業(yè)務(wù)領(lǐng)域包括：PlanSourceMakeDeliverReturnIntelligence&AnalyticsValueChainVisibility業(yè)務(wù)能力對應(yīng)于業(yè)務(wù)子域下的具體能力定義，目前ISC+對應(yīng)于L3的能力定義具體業(yè)務(wù)子領(lǐng)域下包含的L3能力，例如Deliver業(yè)務(wù)子領(lǐng)域包括：ManageOrderPlacementManageOrderHandlingOrderClosingWarehouseMgmt&OperationTrans.Mgmt&OperationCustomCompliance&OperationPlugandPlaySupplyNetworkIT側(cè)術(shù)語范例19術(shù)語術(shù)語定義范例及說明應(yīng)用域應(yīng)用功能模型中的最高層分組，將應(yīng)用架構(gòu)的交付分為幾個(gè)大的領(lǐng)域根據(jù)華為目前的定義，應(yīng)用域包括：Supply、Procurement、LTC、SD、Finance、IPD等應(yīng)用組是應(yīng)用域的細(xì)分，是一組強(qiáng)相關(guān)應(yīng)用的組合各應(yīng)用域下有不同的應(yīng)用組定義，例如Supply應(yīng)用域下包括：計(jì)劃管理訂單管理專業(yè)制造流通加工物流管理等應(yīng)用組服務(wù)化子系統(tǒng)由業(yè)務(wù)服務(wù)組合而成，支持一組相關(guān)業(yè)務(wù)活動的應(yīng)用，可獨(dú)立部署基于業(yè)務(wù)服務(wù)的聚合，識別出不同的服務(wù)化子系統(tǒng)，例如，計(jì)劃管理包括：需求感知與預(yù)測、全球集成計(jì)劃管理、全球供應(yīng)主計(jì)劃、國家集成計(jì)劃、供應(yīng)能力管理等流通加工包括：流通訂單管理，流通工單管理，理貨包裝、標(biāo)簽管理等Agenda201為什么要做服務(wù)化ISC+服務(wù)化V模型服務(wù)化工作方法23服務(wù)識別與定義3.1服務(wù)設(shè)計(jì)與實(shí)現(xiàn)3.2服務(wù)管理與運(yùn)營3.3持續(xù)交付流程3.421服務(wù)設(shè)計(jì)服務(wù)識別與定義服務(wù)設(shè)計(jì)與實(shí)現(xiàn)服務(wù)管理與運(yùn)營識別業(yè)務(wù)場景，設(shè)計(jì)工作流和定義業(yè)務(wù)活動識別及定義業(yè)務(wù)服務(wù)迭代計(jì)劃制定業(yè)務(wù)與IT攜手，解耦業(yè)務(wù)流程、聚焦創(chuàng)新、面向客戶與業(yè)務(wù)操作識別及定義服務(wù)通過業(yè)務(wù)與IT一體化運(yùn)作，迭代詳細(xì)設(shè)計(jì)、開發(fā)測試與部署以實(shí)現(xiàn)服務(wù)的快速交付通過建立“服務(wù)市場”與服務(wù)“運(yùn)營平臺”，建立服務(wù)運(yùn)營機(jī)制，促進(jìn)服務(wù)的靈活應(yīng)用與創(chuàng)新服務(wù)發(fā)現(xiàn)管理（API)服務(wù)訪問管理服務(wù)SLA管理服務(wù)開發(fā)、測試服務(wù)部署、運(yùn)維服務(wù)的全生命周期管理持續(xù)交付Agenda221為什么要做服務(wù)化ISC+服務(wù)化V模型服務(wù)化工作方法23服務(wù)識別與定義3.1服務(wù)設(shè)計(jì)與實(shí)現(xiàn)3.2服務(wù)管理與運(yùn)營3.3持續(xù)交付流程3.4LWA業(yè)務(wù)服務(wù)識別總覽13業(yè)務(wù)與IT攜手，解耦業(yè)務(wù)流程、聚焦創(chuàng)新、面向客戶與業(yè)務(wù)操作識別及定義服務(wù)業(yè)務(wù)代表場景/工作流/活動設(shè)計(jì)原則：愿景驅(qū)動領(lǐng)先實(shí)踐支撐關(guān)鍵設(shè)計(jì)明確的業(yè)務(wù)規(guī)則考慮因素業(yè)務(wù)服務(wù)識別原則：對相同或相似功能的業(yè)務(wù)活動的抽象與組裝包含獨(dú)立的業(yè)務(wù)實(shí)體一個(gè)服務(wù)API實(shí)現(xiàn)了完整獨(dú)立單一的業(yè)務(wù)邏輯服務(wù)API的顆粒度定義由服務(wù)消費(fèi)者驅(qū)動服務(wù)識別及定義1識別業(yè)務(wù)場景，設(shè)計(jì)工作流，定義業(yè)務(wù)活動2識別及定義業(yè)務(wù)服務(wù)3制定迭代計(jì)劃L3業(yè)務(wù)能力業(yè)務(wù)代表/應(yīng)用組產(chǎn)品經(jīng)理業(yè)務(wù)代表/子產(chǎn)品經(jīng)理迭代計(jì)劃制定原則：最小可接受的部署版本業(yè)務(wù)服務(wù)的依賴關(guān)系業(yè)務(wù)服務(wù)的工作量估計(jì)可投入交付的人力資源服務(wù)識別和定義主要工作和輸出24服務(wù)識別、服務(wù)定義場景、工作流、活動識別與定義業(yè)務(wù)服務(wù)制定迭代計(jì)劃負(fù)責(zé)人/參與人主要輸出模板、范例主要工作項(xiàng)業(yè)務(wù)代表業(yè)務(wù)代表/應(yīng)用組產(chǎn)品經(jīng)理業(yè)務(wù)代表/子產(chǎn)品經(jīng)理設(shè)計(jì)場景設(shè)計(jì)工作流定義活動根據(jù)業(yè)務(wù)活動識別業(yè)務(wù)服務(wù)，形成業(yè)務(wù)服務(wù)列表進(jìn)行業(yè)務(wù)服務(wù)詳細(xì)設(shè)計(jì)，完成里程碑業(yè)務(wù)詳細(xì)設(shè)計(jì)方案刷新業(yè)務(wù)服務(wù)列表1.場景定義2.工作流說明3.活動列表4.業(yè)務(wù)服務(wù)列表（不含API定義）5.里程碑詳細(xì)設(shè)計(jì)說明書制定里程碑迭代計(jì)劃設(shè)計(jì)子系統(tǒng)產(chǎn)品/數(shù)據(jù)標(biāo)準(zhǔn)定義補(bǔ)充服務(wù)列表中API定義6.里程碑迭代計(jì)劃7.產(chǎn)品服務(wù)化設(shè)計(jì)文檔/數(shù)據(jù)標(biāo)準(zhǔn)8.開發(fā)測試迭代計(jì)劃(XMEN)9.更新的業(yè)務(wù)服務(wù)列表（含API定義）概念、高階及詳細(xì)方案設(shè)計(jì)Sprint0123識別業(yè)務(wù)場景，設(shè)計(jì)工作流，定義業(yè)務(wù)活動25階段名稱識別業(yè)務(wù)場景，設(shè)計(jì)工作流和定義業(yè)務(wù)活動負(fù)責(zé)人業(yè)務(wù)代表階段輸入概念設(shè)計(jì)方案、能力框架圖、業(yè)務(wù)創(chuàng)新需求階段輸出業(yè)務(wù)場景定義，工作流，業(yè)務(wù)活動列表及業(yè)務(wù)活動上下文描述原則基于業(yè)務(wù)愿景，參考領(lǐng)先實(shí)踐進(jìn)行識別業(yè)務(wù)場景，設(shè)計(jì)工作流首先確定明確的場景識別要素，再進(jìn)行場景識別和收斂業(yè)務(wù)活動盡可能有明確的執(zhí)行主體、輸入輸出、操作對象、業(yè)務(wù)規(guī)則、可衡量的完成標(biāo)準(zhǔn)業(yè)務(wù)創(chuàng)新點(diǎn)需求和新的操作模式需要體現(xiàn)在具體的場景和活動中方法步驟識別業(yè)務(wù)場景參考業(yè)界的業(yè)務(wù)模式和場景識別要素，識別L3業(yè)務(wù)能力下端到端的業(yè)務(wù)場景；設(shè)計(jì)工作流明確不同場景下的業(yè)務(wù)規(guī)則，根據(jù)業(yè)務(wù)規(guī)則設(shè)計(jì)工作流，并分析工作流在不同業(yè)務(wù)環(huán)境下（地區(qū)、業(yè)務(wù)模式、組織形態(tài)…）的差異點(diǎn)以及對業(yè)務(wù)環(huán)境和操作環(huán)境（內(nèi)部人員操作、客戶操作、系統(tǒng)操作…）的影響；工作流設(shè)計(jì)需要包含清楚的角色定義，流程的活動規(guī)則描述和關(guān)鍵設(shè)計(jì)點(diǎn)說明定義業(yè)務(wù)活動根據(jù)不同的業(yè)務(wù)場景下的工作流，確定每個(gè)活動的參與業(yè)務(wù)角色，設(shè)計(jì)業(yè)務(wù)活動操作場景及核心業(yè)務(wù)處理邏輯；業(yè)務(wù)角色必須來自XX系統(tǒng)中已經(jīng)發(fā)布的角色，如果有新增角色，需要經(jīng)過審批并發(fā)布，或者合并到已有的角色中；對相同或相似功能的業(yè)務(wù)活動進(jìn)行抽象與組裝，歸并不同場景下的活動，形成活動列表（包含活動名稱、描述、輸入、輸出、業(yè)務(wù)規(guī)則、業(yè)務(wù)實(shí)體等）。1以O(shè)M為例，識別業(yè)務(wù)場景，設(shè)計(jì)工作流，

定義業(yè)務(wù)活動26識別活動定義活動識別業(yè)務(wù)場景設(shè)計(jì)工作流定義業(yè)務(wù)場景L3業(yè)務(wù)能力6.4.1Manageorderplacement驗(yàn)收確認(rèn)觸發(fā)開票觸發(fā)收入/成本確認(rèn)關(guān)閉訂單無安裝服務(wù)清晰PO132無安裝服務(wù)BulkPO+Call-off含安裝服務(wù)清晰PO4配置+MOS計(jì)劃+PO5框架合同+結(jié)算PO生成內(nèi)部銷售訂單分流訂單處理站點(diǎn)輔料配置生成站點(diǎn)要貨需求驗(yàn)證訂單承諾訂單生成SO分發(fā)訂單/需求獲取訂單生成要貨需求確定關(guān)聯(lián)交易路徑計(jì)算關(guān)聯(lián)交易價(jià)格生成內(nèi)部采購訂單變更訂單履行監(jiān)控/異常處理檢查備發(fā)貨條件編排訂單模擬供需排產(chǎn)訂單確定交單計(jì)劃檢查齊套性制定發(fā)貨計(jì)劃生成發(fā)貨單釋放訂單監(jiān)控硬件履行觸發(fā)軟件授權(quán)觸發(fā)服務(wù)履行執(zhí)行Claim訂單12345678910111213141516171819202122232425262830履行逆向訂單27293132336.4.2Manageorderhandling6.4.3OrderclosingISC+能力框架V1.3版本下的OM的L3業(yè)務(wù)能力276.1PLAN6.5RETURN6.4DELIVER6.3MAKE6.2SOURCE1.Strategy1.1StrategyplanandBusinessplan1.4IntegratedBusinessplanning1.2Supplynetworkstrategydesign1.3SupplyChainCenterofExcellence3.Innovateanddev.4.Market5.Sell3.1Designforsupplychain3.2Prod.Lifecyclemgmt.(NPI,EOL)3.4Engchangeordermanagement3.3Prod.structureoptimization4.1Marketinsightcollaboration4.2Promotion5.2Cust.insightcollaboration5.3ContractLifecycleMgmt5.1Demandshaping5.4IntegratedCPQ5.5ProductandSolutionSelling7.ServeAndSupport7.1Cust.networkmonitoring&analysis7.2Installedbasemanagement7.4Deliver&ManageImpl.7.3Cust.Support*6.1.2PlanningStrategy6.1.3Masterplanning6.1.4Procurementplanning6.1.5Productionplanning6.1.6Logisticsplanning6.1.9Distributionplanning6.1.10Inventorymanagement6.1.8Allocationplanningandmgmt6.1.7Replenishplanning6.1.1Demandsensing6Supply6.2.2Managecategory6.2.3Managebuyingoperation6.2.4Managesupplier6.3.2Productionscheduling6.3.3Managetrialproduction6.3.4Manageproductionflow6.3.5ContractMFGcollaboration6.3.7Managequality6.3.8Optimizeproductionfacility6.3.9Manageassetperformance6.4.2Manageorderhandling6.4.3Orderclosing6.4.5Trans.mgmt.&operation6.4.6Customcompliance&operation6.4.7Plugandplaysupplynetwork6.5.2Returnavoidanceplan6.5.3RMAmanagement6.5.4Triage/problemdiagnose&repair6.5.5Reuse,recycle,resell,scrap6.2.1Manageprocurestrategy6.3.1Capacityplanning6.3.6DigitallyEnabledManufacturing6.4.1Manageorderplacement6.4.4Warehousemgmt.&operation6.5.1Returnofferings&strategy6.6Intelligence&analytics6.6.4Root-causeanalysis6.6.1Scenariobasedwhat-ifsimulation6.6.2SupplyNetworkmodeling&opt.6.6.3SupplyChainanalytics6.6.5On-LineCust.BehaviorAnalytics6.7Valuechainvisibility6.7.7Visibilitybyviews6.7.1Performancemgmt.6.7.2Exceptionmgmt6.7.3Real-timedemandandsupply6.7.4Digitaltrackandtrace6.7.5N-tiersuppliervisibility6.7.6Channelpartnerinventoryvisibility8.EcosystemManagement9.Enablement9.1QualityAssurance9.2Sustainability9.3Talentmgmt9.4Knowledgemgmt9.5Licensing&entitlement9.6Masterdatamgmt9.7Process&ITdevandmanagement9.8Assettrackingandtraceability9.9Riskandcompliancemgmt2.CustomerExperience/CustomerOrientedService2.1DigitalCustomerCollaboration2.2Customercollaborativeplanning2.32.6Collaborativeprojectplanning10.Finance10.6Billing&Payment**10.5CreditControl10.4IntercompanyTransaction10.3RevenueandcostRecognition10.2CosttoServeManagement10.1Budgeting&Forecast***10.7Pricing10.8Digitaln-tiersuppliercollaboration8.1PartnerStrategy8.3PartnerDevelopment.&Enablement8.4PartnerBusinessOperations8.5PartnerPerformance&Incentives8.6PartnerInfrastructure8.7PartnerRelationshipManagement8.8AllianceManagement8.2PartnerProgramArchitecture細(xì)化OM的L3級業(yè)務(wù)能力，識別出相應(yīng)業(yè)務(wù)場景16基于客戶旅程，解耦端到端流程，細(xì)化到業(yè)務(wù)子流程，為細(xì)化工作流做準(zhǔn)備通過DesignThinking中的用戶畫像和客戶旅程，設(shè)計(jì)工作流對應(yīng)的業(yè)務(wù)活動，體現(xiàn)關(guān)鍵設(shè)計(jì)點(diǎn)與創(chuàng)新點(diǎn)設(shè)計(jì)工作流識別業(yè)務(wù)場景進(jìn)行客戶需求調(diào)研，同時(shí)在OM能力全景視圖內(nèi)選取影響業(yè)務(wù)流程的關(guān)鍵變化因子，設(shè)計(jì)OM業(yè)務(wù)子場景基于相同關(guān)鍵業(yè)務(wù)活動要素，把業(yè)務(wù)子場景收斂為5種典型業(yè)務(wù)場景，作為后續(xù)工作流設(shè)計(jì)的基礎(chǔ)完善業(yè)務(wù)活動的執(zhí)行主體、輸入輸出、操作對象、業(yè)務(wù)規(guī)則、可衡量的完成標(biāo)準(zhǔn)基于業(yè)務(wù)目的、輸入輸出和業(yè)務(wù)規(guī)則歸并功能相同或相近的活動，輸出業(yè)務(wù)活動列表定義業(yè)務(wù)活動場景名稱配置+MOS計(jì)劃+PO含安裝服務(wù)清晰PO框架合同+結(jié)算PO無安裝服務(wù)清晰PO1345無安裝服務(wù)BulkPO+Call-off2產(chǎn)品：硬、軟、安裝服務(wù)主要特征：下客戶PO時(shí)點(diǎn)履行信息不清晰，根據(jù)配置+MOS計(jì)劃驅(qū)動履行硬軟服統(tǒng)簽PO：根據(jù)配置+MOS計(jì)劃驅(qū)動履行，PO控制總量以及結(jié)算硬/軟單簽PO：根據(jù)配置+MOS計(jì)劃交付到站點(diǎn)安裝服務(wù)單簽PO：需要HW提供物流服務(wù)（如中心倉

站點(diǎn)、客戶倉

站點(diǎn)）產(chǎn)品：硬、軟、安裝服務(wù)主要特征：清晰PO，PO驅(qū)動履行硬軟服統(tǒng)簽PO：硬件/軟件由PO驅(qū)動，供應(yīng)至站點(diǎn)安裝服務(wù)單簽PO：不需要HW提供物流服務(wù)（如客戶倉

站點(diǎn)）產(chǎn)品：硬、軟、安裝服務(wù)主要特征：在沒有PO的情況下，根據(jù)配置+MOS計(jì)劃先交付，PO后下真對優(yōu)質(zhì)客戶，在沒有得到PO的情況下，通過配置+MOS計(jì)劃指導(dǎo)交付，再引導(dǎo)客戶下結(jié)算PO客戶下PO的時(shí)點(diǎn)，可以是交付過程中，也可以是交付后產(chǎn)品：硬、軟、非安裝服務(wù)主要特征：清晰PO，PO驅(qū)動履行硬件/軟件履行信息清晰，PO驅(qū)動供應(yīng)至客戶指定地點(diǎn)（非華為倉庫）非安裝服務(wù)的信息可支撐商務(wù)結(jié)算產(chǎn)品：硬、軟主要特征：下PO的時(shí)點(diǎn)履行信息不清晰，客戶會后續(xù)提供供應(yīng)指令（Call-off）Call-off驅(qū)動硬/軟供應(yīng)，PO控制總量以及結(jié)算同一PO里可含延長維保詳細(xì)說明PO例舉硬+軟+安裝服務(wù)履行信息不確定PO硬+軟PO（貨到中心倉）有硬件的履行（中心倉

站點(diǎn)or客戶倉

站點(diǎn)）的安裝服務(wù)PO硬+軟+安裝服務(wù)清晰PO；無硬件的履行（如客戶倉

站點(diǎn)）的安裝服務(wù)PO，根據(jù)配置+MOS計(jì)劃交付，交付過程中，客戶下PO根據(jù)配置+MOS計(jì)劃交付，交付后，引導(dǎo)客戶下PO硬+軟清晰PO；硬件供應(yīng)到客戶指定地點(diǎn)（含站點(diǎn)）軟件年費(fèi)PO單獨(dú)延長維保PO專業(yè)服務(wù)PO硬+軟，履行信息不確定PO；客戶后續(xù)提供Call-off信息設(shè)計(jì)業(yè)務(wù)子流程中的業(yè)務(wù)活動，體現(xiàn)出關(guān)鍵設(shè)計(jì)點(diǎn)與創(chuàng)新點(diǎn)18基于客戶旅程，解耦端到端流程，細(xì)化到業(yè)務(wù)子流程，為細(xì)化工作流做準(zhǔn)備通過DesignThinking中的用戶畫像和客戶旅程，設(shè)計(jì)工作流對應(yīng)的業(yè)務(wù)活動，體現(xiàn)關(guān)鍵設(shè)計(jì)點(diǎn)與創(chuàng)新點(diǎn)設(shè)計(jì)工作流識別業(yè)務(wù)場景基于客戶旅程，進(jìn)行客戶需求調(diào)研，同時(shí)在OM能力全景視圖內(nèi)選取影響業(yè)務(wù)流程的關(guān)鍵變化因子，設(shè)計(jì)OM業(yè)務(wù)子場景基于相同關(guān)鍵業(yè)務(wù)活動要素，把業(yè)務(wù)子場景收斂為5種典型業(yè)務(wù)場景，作為后續(xù)工作流設(shè)計(jì)的基礎(chǔ)完善業(yè)務(wù)活動的執(zhí)行主體、輸入輸出、操作對象、業(yè)務(wù)規(guī)則、可衡量的完成標(biāo)準(zhǔn)基于業(yè)務(wù)目的、輸入輸出和業(yè)務(wù)規(guī)則歸并功能相同或相近的活動，輸出業(yè)務(wù)活動列表定義業(yè)務(wù)活動客戶/CCO/PRM系統(tǒng)自動合同履行專員SO處理專員無安裝服務(wù)清晰PO-Part1下單訂單確認(rèn)合同注冊需求獲取訂單生成訂單承諾訂單驗(yàn)證不通過訂單分發(fā)關(guān)聯(lián)交易處理專員管理關(guān)聯(lián)交易路徑管理關(guān)聯(lián)交易價(jià)格內(nèi)部采購訂單生成內(nèi)部銷售訂單生成AP/AR財(cái)經(jīng)ERPCSO生成12ERPISO生成驗(yàn)證結(jié)果通過3對識別的業(yè)務(wù)活動進(jìn)行分析和歸并，確定活動定義20完善業(yè)務(wù)活動的執(zhí)行主體、輸入輸出、操作對象、業(yè)務(wù)規(guī)則、可衡量的完成標(biāo)準(zhǔn)基于業(yè)務(wù)目的、輸入輸出和業(yè)務(wù)規(guī)則歸并功能相同或相近的活動，輸出業(yè)務(wù)活動列表基于客戶旅程，解耦端到端流程，細(xì)化到業(yè)務(wù)子流程，為細(xì)化工作流做準(zhǔn)備通過DesignThinking中的用戶畫像和客戶旅程，設(shè)計(jì)工作流對應(yīng)的業(yè)務(wù)活動，體現(xiàn)關(guān)鍵設(shè)計(jì)點(diǎn)與創(chuàng)新點(diǎn)定義業(yè)務(wù)活動設(shè)計(jì)工作流識別業(yè)務(wù)場景基于客戶旅程，進(jìn)行客戶需求調(diào)研，同時(shí)在OM能力全景視圖內(nèi)選取影響業(yè)務(wù)流程的關(guān)鍵變化因子，設(shè)計(jì)OM業(yè)務(wù)子場景基于相同關(guān)鍵業(yè)務(wù)活動要素，把業(yè)務(wù)子場景收斂為5種典型業(yè)務(wù)場景，作為后續(xù)工作流設(shè)計(jì)的基礎(chǔ)驗(yàn)收確認(rèn)觸發(fā)開票觸發(fā)收入/成本確認(rèn)關(guān)閉訂單無安裝服務(wù)清晰PO132無安裝服務(wù)BulkPO+Call-off含安裝服務(wù)清晰PO4配置+MOS計(jì)劃+PO5框架合同+結(jié)算PO生成內(nèi)部銷售訂單分流訂單處理站點(diǎn)輔料配置生成站點(diǎn)要貨需求驗(yàn)證訂單承諾訂單生成SO分發(fā)訂單/需求獲取訂單生成要貨需求確定關(guān)聯(lián)交易路徑計(jì)算關(guān)聯(lián)交易價(jià)格生成內(nèi)部采購訂單變更訂單履行監(jiān)控/異常處理檢查備發(fā)貨條件編排訂單模擬供需排產(chǎn)訂單確定交單計(jì)劃檢查齊套性制定發(fā)貨計(jì)劃生成發(fā)貨單釋放訂單監(jiān)控硬件履行觸發(fā)軟件授權(quán)觸發(fā)服務(wù)履行執(zhí)行Claim訂單12345678910111213141516171819202122232425262830履行逆向訂單2729313233業(yè)務(wù)場景及其對應(yīng)工作流的上下文定義31序號屬性說明1業(yè)務(wù)場景名稱業(yè)務(wù)場景簡稱2場景識別要素說明識別該場景對應(yīng)的識別要素，比如履約方式是OM的場景識別要素，分為：PO履約和項(xiàng)目履約3場景描述描述對應(yīng)業(yè)務(wù)場景的業(yè)務(wù)規(guī)則和設(shè)計(jì)思路4工作流圖描述場景對應(yīng)的工作流圖，流程圖（泳道圖）中需要有清晰的角色定義和各角色對應(yīng)的業(yè)務(wù)活動；業(yè)務(wù)活動的命名采用業(yè)務(wù)語言，明確表達(dá)業(yè)務(wù)行為，格式建議采用動詞+名詞，從而角色與業(yè)務(wù)活動組成完整的主謂賓邏輯關(guān)系；如存在重要外部依賴或輸入，應(yīng)標(biāo)明在工作流圖中。5業(yè)務(wù)規(guī)則說明描述工作流中關(guān)鍵業(yè)務(wù)活動的業(yè)務(wù)規(guī)則、設(shè)計(jì)點(diǎn)、輸入輸出以及異常情況描述流程流轉(zhuǎn)的判定條件等業(yè)務(wù)活動識別需要包含的上下文定義32序號屬性說明1業(yè)務(wù)活動編號(BusinessActivityNo.)參考服務(wù)對象編碼規(guī)則2所屬L3業(yè)務(wù)能力(L3Capability)說明活動所屬的L3能力，具體L3能力參見ISC+能力框架圖3輸入(Input)描述活動的輸入信息，包括信息內(nèi)容(What)和來源(From);輸入內(nèi)容指本活動的開展所需要的前置依賴信息或依據(jù)，輸入信息載體一般是業(yè)務(wù)對象輸入的來源可能是前序活動的輸出、外部系統(tǒng)、線下表單等。如暫不清楚數(shù)據(jù)來源，則此列放空4輸出(Output)描述活動的輸出信息，包括信息的內(nèi)容(What)和可能的使用者(TO)輸出信息載體一般是業(yè)務(wù)對象5相關(guān)業(yè)務(wù)對象(RelatedBusinessObject)活動操作的主要業(yè)務(wù)對象。業(yè)務(wù)對象可參照BusinessObjectRefTab頁階段名稱識別及定義業(yè)務(wù)服務(wù)負(fù)責(zé)人業(yè)務(wù)代表/應(yīng)用組產(chǎn)品經(jīng)理階段輸入工作流、業(yè)務(wù)活動列表階段輸出業(yè)務(wù)服務(wù)列表，里程碑詳細(xì)設(shè)計(jì)說明書原則業(yè)務(wù)服務(wù)編號規(guī)則，業(yè)務(wù)服務(wù)命名規(guī)則請參考服務(wù)對象命名規(guī)則；業(yè)務(wù)服務(wù)包括業(yè)務(wù)實(shí)體+一組API，例如：圍繞業(yè)務(wù)實(shí)體SO，相應(yīng)的業(yè)務(wù)服務(wù)可以有CreateSO,DisplaySO等；業(yè)務(wù)服務(wù)顆粒度的原則：

對相同或相似功能的業(yè)務(wù)活動的抽象與組裝包含獨(dú)立的業(yè)務(wù)實(shí)體一個(gè)服務(wù)API實(shí)現(xiàn)了完整獨(dú)立單一的業(yè)務(wù)邏輯服務(wù)API的顆粒度定義由服務(wù)消費(fèi)者驅(qū)動方法步驟業(yè)務(wù)服務(wù)識別根據(jù)業(yè)務(wù)活動定義和業(yè)務(wù)服務(wù)識別原則，識別出業(yè)務(wù)服務(wù)，形成業(yè)務(wù)服務(wù)列表補(bǔ)充服務(wù)上下文根據(jù)業(yè)務(wù)服務(wù)模板，補(bǔ)充相應(yīng)的上下文信息，比如服務(wù)描述、輸入、輸出、依賴關(guān)系等基于DesignThinking中的Prototype

Visualize和Ideate

Brainstorm，進(jìn)行業(yè)務(wù)服務(wù)詳細(xì)設(shè)計(jì)，完成里程碑詳細(xì)設(shè)計(jì)說明書識別及定義業(yè)務(wù)服務(wù)212業(yè)務(wù)服務(wù)的業(yè)務(wù)特征34每個(gè)業(yè)務(wù)服務(wù)應(yīng)該提供具體業(yè)務(wù)功能，有明確的業(yè)務(wù)含義不能指望一個(gè)業(yè)務(wù)服務(wù)實(shí)現(xiàn)全功能，包打天下明確業(yè)務(wù)含義一個(gè)業(yè)務(wù)服務(wù)實(shí)現(xiàn)的功能應(yīng)該是單一的、確定的且完整的，既不能片段化也不能過于泛化業(yè)務(wù)職責(zé)完整單一服務(wù)調(diào)用是有成本的，應(yīng)盡可能減少各種跨服務(wù)調(diào)用的消耗顆粒度不宜太小業(yè)務(wù)服務(wù)應(yīng)該圍繞業(yè)務(wù)實(shí)體操作，比如RESTFUL服務(wù)基于WebResource操作圍繞業(yè)務(wù)實(shí)體操作業(yè)務(wù)服務(wù)不應(yīng)隨服務(wù)調(diào)用者改變而不得不變化隨著服務(wù)版本升級，業(yè)務(wù)功能應(yīng)向下兼容業(yè)務(wù)功能穩(wěn)定業(yè)務(wù)服務(wù)的技術(shù)特征35業(yè)務(wù)服務(wù)更多是為提供外部進(jìn)程調(diào)用服務(wù)，調(diào)用者不應(yīng)關(guān)心服務(wù)在遠(yuǎn)程還是本地。調(diào)用者通過網(wǎng)頁服務(wù)請求或者遠(yuǎn)程調(diào)用通信的方式進(jìn)行通信。為分布式而生調(diào)用者應(yīng)不必也無需關(guān)心業(yè)務(wù)服務(wù)采用的數(shù)據(jù)存儲方式和具體實(shí)現(xiàn)細(xì)節(jié)與數(shù)據(jù)存儲方式無關(guān)一類業(yè)務(wù)服務(wù)應(yīng)該對應(yīng)一組報(bào)文。一組報(bào)文內(nèi)通常包含服務(wù)申請報(bào)文、服務(wù)結(jié)果返還報(bào)文等接口標(biāo)準(zhǔn)化調(diào)用者應(yīng)不必也無需關(guān)心業(yè)務(wù)服務(wù)采用的技術(shù)棧和具體實(shí)現(xiàn)邏輯與開發(fā)語言無關(guān)服務(wù)調(diào)用者不應(yīng)隨著業(yè)務(wù)服務(wù)內(nèi)部實(shí)現(xiàn)邏輯的變化而變化，業(yè)務(wù)服務(wù)的接口應(yīng)具有一定的擴(kuò)展性，保證其穩(wěn)定性接口穩(wěn)定服務(wù)應(yīng)該有明確的邊界，封裝業(yè)務(wù)功能和業(yè)務(wù)數(shù)據(jù)，不暴露內(nèi)部實(shí)現(xiàn)細(xì)節(jié)聚合因同一理由變化的功能與數(shù)據(jù)，分離因不同理由而變化的功能與數(shù)據(jù)高內(nèi)聚業(yè)務(wù)服務(wù)之間應(yīng)該橫向解耦，一個(gè)服務(wù)的改變不應(yīng)導(dǎo)致其他服務(wù)必須改變業(yè)務(wù)服務(wù)內(nèi)部應(yīng)該縱向解耦，每層內(nèi)部的變化不應(yīng)導(dǎo)致其他層必須改變服務(wù)調(diào)用者與服務(wù)提供者解耦，不能因?yàn)橐环阶儎?，另一方必須改變低耦合業(yè)務(wù)服務(wù)的運(yùn)營特性36業(yè)務(wù)服務(wù)的績效可以度量，包括訂閱數(shù)量、調(diào)用次數(shù)、響應(yīng)時(shí)間等績效指標(biāo)可度量超過3個(gè)月沒有調(diào)用者或者沒有調(diào)用記錄的業(yè)務(wù)服務(wù)，應(yīng)該考慮下架，以保證業(yè)務(wù)服務(wù)都是有價(jià)值的有價(jià)值根據(jù)服務(wù)調(diào)用次數(shù)或者數(shù)據(jù)流量進(jìn)行定價(jià)核算可定價(jià)業(yè)務(wù)服務(wù)OpenAPI需要注冊到API管理平臺，形成服務(wù)目錄，供服務(wù)消費(fèi)者訪問調(diào)用可注冊可以監(jiān)控業(yè)務(wù)服務(wù)的運(yùn)行狀態(tài)可以啟停業(yè)務(wù)服務(wù)可監(jiān)控業(yè)務(wù)服務(wù)包含的上下文定義37序號屬性說明1業(yè)務(wù)服務(wù)編號(BusinessActivityNo.)業(yè)務(wù)服務(wù)的唯一標(biāo)識2業(yè)務(wù)服務(wù)名稱(BusinessSrvName)業(yè)務(wù)服務(wù)的英文名稱3業(yè)務(wù)服務(wù)描述(BusinessServiceDesc)業(yè)務(wù)服務(wù)的功能描述4對應(yīng)的業(yè)務(wù)活動(BusinessActivityNo.)對應(yīng)的業(yè)務(wù)活動的編號，如果一個(gè)業(yè)務(wù)服務(wù)對應(yīng)多個(gè)業(yè)務(wù)活動，則需要列出所有對應(yīng)的業(yè)務(wù)活動的編號5服務(wù)組(ServiceGroup)業(yè)務(wù)服務(wù)所屬的服務(wù)組，如果尚未對業(yè)務(wù)服務(wù)進(jìn)行分組，則該列可放空6服務(wù)子系統(tǒng)(Application)業(yè)務(wù)服務(wù)所屬的服務(wù)化子系統(tǒng)7服務(wù)接口名(SrvInterfacesName)業(yè)務(wù)服務(wù)對外提供的調(diào)用接口（API）的名稱(一個(gè)服務(wù)可以有多個(gè)API)。接口的命名遵從動詞開頭的格式，可以是動詞+賓語，比如getPO；可以是動詞+賓語+方式，比如getPOByName8服務(wù)接口描述(SrvInterfacesDesc)業(yè)務(wù)服務(wù)API實(shí)現(xiàn)的功能描述9輸入(Input)API的輸入?yún)?shù)10輸出(Output)API的輸出結(jié)果11相關(guān)的業(yè)務(wù)對象(RelatedBusinessObject)業(yè)務(wù)服務(wù)操作的主要業(yè)務(wù)對象12依賴的外部服務(wù)(DependenceDesc)本服務(wù)對其他服務(wù)的依賴說明，包括被依賴服務(wù)的編號、名稱和API13備注(Comments)其它需要說明的補(bǔ)充信息業(yè)務(wù)活動如何識別、歸結(jié)業(yè)務(wù)服務(wù)382、一個(gè)活動識別為多個(gè)業(yè)務(wù)服務(wù)說明：業(yè)務(wù)活動的粒度較粗，功能不單一，包含了多個(gè)操作步驟（建議細(xì)化活動后再識別服務(wù)）范例：OM的TriggerBilling/Revenue活動中可以識別為TriggerBilling、TriggerCost/Revenue、TriggerAP/ARgeneration等幾個(gè)服務(wù)1、一個(gè)活動識別為一個(gè)業(yè)務(wù)服務(wù)說明：業(yè)務(wù)活動包含了單一且完整的業(yè)務(wù)處理邏輯范例：OM的SOGeneration活動可識別為GenerateandverifySO服務(wù)；CCO的ViewProductList可識別為DisplayProductCatalogandProductList服務(wù)業(yè)務(wù)活動與業(yè)務(wù)服務(wù)的關(guān)系3、多個(gè)活動識別歸結(jié)為一個(gè)業(yè)務(wù)服務(wù)說明：多個(gè)活動是對一個(gè)業(yè)務(wù)實(shí)體操作且處理邏輯簡單清晰，如每個(gè)活動都對應(yīng)出一個(gè)業(yè)務(wù)服務(wù)，業(yè)務(wù)服務(wù)的顆粒度太小，不方便管理范例：CCO中不同工作流中對購物車的操作，可以歸結(jié)為統(tǒng)一的購物車管理服務(wù)經(jīng)過上述分析過程，業(yè)務(wù)能力已經(jīng)分解為各類業(yè)務(wù)活動并輸出業(yè)務(wù)活動列表，后續(xù)將根據(jù)業(yè)務(wù)活動識別相應(yīng)的業(yè)務(wù)服務(wù)。

通過業(yè)務(wù)活動識別業(yè)務(wù)服務(wù)有如下三種情況：以O(shè)M為例，識別業(yè)務(wù)場景，設(shè)計(jì)工作流，

定義業(yè)務(wù)活動，識別業(yè)務(wù)服務(wù)39驗(yàn)收確認(rèn)觸發(fā)開票觸發(fā)收入/成本確認(rèn)關(guān)閉訂單識別業(yè)務(wù)場景定義工作流識別業(yè)務(wù)服務(wù)定義并收斂業(yè)務(wù)活動無安裝服務(wù)清晰PO132無安裝服務(wù)BulkPO+Call-off含安裝服務(wù)清晰PO4配置+MOS計(jì)劃+PO5框架合同+結(jié)算PO生成內(nèi)部銷售訂單分流訂單處理站點(diǎn)輔料配置生成站點(diǎn)要貨需求驗(yàn)證訂單承諾訂單生成SO分發(fā)訂單/需求獲取訂單生成要貨需求確定關(guān)聯(lián)交易路徑計(jì)算關(guān)聯(lián)交易價(jià)格生成內(nèi)部采購訂單變更訂單履行監(jiān)控/異常處理檢查備發(fā)貨條件編排訂單模擬供需排產(chǎn)訂單確定交單計(jì)劃檢查齊套性制定發(fā)貨計(jì)劃生成發(fā)貨單釋放訂單監(jiān)控硬件履行觸發(fā)軟件授權(quán)觸發(fā)服務(wù)履行執(zhí)行Claim訂單12345678910111213141516171819202122232425262830履行逆向訂單2729313233分流訂單處理站點(diǎn)輔料配置生成訂單驗(yàn)證訂單承諾訂單分發(fā)訂單/需求確定關(guān)聯(lián)交易路徑生成國家要貨需求生成站點(diǎn)要貨需求生成內(nèi)部采購訂單生成內(nèi)部銷售訂單監(jiān)控訂單變更訂單處理異常生成采購計(jì)劃生成DO計(jì)算關(guān)聯(lián)交易價(jià)格計(jì)算清關(guān)金額檢查備發(fā)貨條件制定發(fā)貨計(jì)劃編排訂單觸發(fā)軟件授權(quán)觸發(fā)服務(wù)履行執(zhí)行Claim訂單釋放訂單履行逆向訂單確定交單計(jì)劃匹配資源監(jiān)控硬件履行驗(yàn)收確認(rèn)觸發(fā)開票觸發(fā)收入/成本確認(rèn)關(guān)閉訂單123456789101112131415161718192021222324252628302729313233OM部分服務(wù)清單（示例）

40*詳細(xì)定義參見OM服務(wù)列表，持續(xù)更新業(yè)務(wù)活動編號

BusinessActivityNo.業(yè)務(wù)活動名稱

BusinessActivityName對應(yīng)業(yè)務(wù)活動

BusinessActivityNo.對應(yīng)業(yè)務(wù)活動名稱

BusinessActivityName服務(wù)組

Application服務(wù)子系統(tǒng)

ApplicationOMActivity_001訂單分流（臨時(shí)）

OrderShunt(temporary)OMSRV_001訂單分流（臨時(shí)）

OrderShunt(temporary)訂單創(chuàng)建

OrderGenerationOMSOM_Activity_002配置處理

ConfigHandlingOM_SRV_002配置處理

ConfigHandling配置處理

Config.HandlingConfig.HandlingOM_Activity_003PO/需求獲取

Order/RequirementCaptureOM_SRV_003PO/需求獲取

Order/RequirementCapture獲取/管理需求

Capture&ManageRequirementRequirementManagementOM_Activity_004管理國家要貨需求

ManageCountrySupplyReq.OM_SRV_004管理國家要貨需求

ManageCountrySupplyReq.獲取/管理需求

Capture&ManageRequirementRequirementManagement制定迭代計(jì)劃階段詳細(xì)描述41階段名稱制定迭代計(jì)劃負(fù)責(zé)人業(yè)務(wù)代表/子產(chǎn)品經(jīng)理階段輸入場景、活動、業(yè)務(wù)服務(wù)列表可投入人力資源情況（產(chǎn)品經(jīng)理提供）階段輸出里程碑迭代計(jì)劃（PPT/EXCEL）產(chǎn)品服務(wù)化設(shè)計(jì)文檔/數(shù)據(jù)標(biāo)準(zhǔn)（UseCase，WORD）開發(fā)迭代計(jì)劃（UserStory，錄入XMEN系統(tǒng)）更新的業(yè)務(wù)服務(wù)列表（補(bǔ)充了API定義）原則明確迭代里程碑的目標(biāo)、時(shí)間段和工作范圍，用于安排任務(wù)，調(diào)配人力資源，排定工作時(shí)間建議采用固定短周期迭代，一個(gè)SPRINT一般為2~4周，最長不超過6周制定開發(fā)迭代計(jì)劃的同時(shí)，可以根據(jù)里程碑詳細(xì)設(shè)計(jì)說明書編制相應(yīng)的測試用例，準(zhǔn)備開發(fā)和測試環(huán)境在完成里程碑詳細(xì)設(shè)計(jì)說明書及開發(fā)迭代計(jì)劃后，可以把相應(yīng)的業(yè)務(wù)服務(wù)和實(shí)現(xiàn)需求規(guī)則說明以UserStory的形式錄入到XMEN平臺中進(jìn)行產(chǎn)品敏捷開發(fā)管理方法步驟產(chǎn)品團(tuán)隊(duì)根據(jù)里程碑詳細(xì)設(shè)計(jì)說明書，編制以USECASE分析為主要內(nèi)容的產(chǎn)品需求規(guī)格說明，形成產(chǎn)品服務(wù)化設(shè)計(jì)文檔；根據(jù)產(chǎn)品服務(wù)化設(shè)計(jì)文檔中的USECASE設(shè)計(jì)內(nèi)容，結(jié)合項(xiàng)目團(tuán)隊(duì)人力情況，評估相應(yīng)工作量，分解為USERSTORY，形成相應(yīng)的開發(fā)和測試迭代計(jì)劃；將開發(fā)和測試迭代計(jì)劃錄入到XMEN項(xiàng)目敏捷開發(fā)管理平臺；將UserStory中定義的服務(wù)API補(bǔ)充到業(yè)務(wù)服務(wù)列表。3迭代Sprint0的目標(biāo)42Sprint0是對于release做準(zhǔn)備或是暖身的Sprint，是應(yīng)用架構(gòu)以及技術(shù)架構(gòu)工作中的正常流程。Sprint0作為一個(gè)releasecycle的開始，其目標(biāo)為：識別Release的范圍以及目標(biāo)制定Release的時(shí)間排程計(jì)劃決定對于應(yīng)用架構(gòu)以及技術(shù)架構(gòu)的工作中，Sprint的數(shù)量以及Sprints的長度識別對于Release來說的UserStory/UseCase并將信息輸入產(chǎn)品backlog，同時(shí)識別并決定在哪一個(gè)sprint中開發(fā)這些stories識別當(dāng)前release的技術(shù)架構(gòu)的需求構(gòu)建持續(xù)集成(CI)與持續(xù)交付(CD)的pipeline定義對于開發(fā)測試的策略與環(huán)境需求確認(rèn)自動化測試框架的準(zhǔn)備程度對于當(dāng)前release做release計(jì)劃分析當(dāng)前release的需求對于套件開發(fā)，分析此release中產(chǎn)品backlog中的每個(gè)項(xiàng)目的匹配與差異度分析對需求做創(chuàng)建、更新、估算以及優(yōu)先級排序分解usecase成為userstories創(chuàng)建包含任務(wù)如創(chuàng)建物理數(shù)據(jù)庫設(shè)計(jì)（如果是自研開發(fā)）或是高階技術(shù)設(shè)計(jì)的設(shè)計(jì)框架ISC+對象命名規(guī)則43對象命名規(guī)則編碼規(guī)則業(yè)務(wù)活動符合業(yè)界標(biāo)準(zhǔn)命名，需以“<Domin>_”+<SubDomain>+”_”開頭，工作流圖（泳道圖）中的業(yè)務(wù)活動的命名應(yīng)該遵從動詞+賓語（比如，提交PO/審核PO等）或單獨(dú)動詞（比如提交/審核/會簽等）的結(jié)構(gòu)，這樣業(yè)務(wù)活動與泳道圖中最左列的角色組成了主+謂+賓或者主+謂的結(jié)構(gòu)例如：ISC_DELIVERY_創(chuàng)建SOISC_DELIVERY_刪除SO“ISC_”+<SubDomain>+”_”+”capability

code”+xxxxxx–從001到999例如：ISC_DELIVERY_001_001第一個(gè)001代表ManageorderplacementDomin:ISC,ISD,CRM,FIN