EE-华为智能化供应链ISC加变革项目服务化工作指导书-2016

智能供应链ISC+变革项目

服务化工作指导书

2016年12月1Agenda21为什么要做服务化ISC+服务化V模型服务化工作方法23服务识别与定义3.1服务设计与实现3.2服务管理与运营3.3持续交付流程3.4单体应⽤：功能集中、代码中心化、一个发布包、部署后运行在同⼀进程的应⽤程序。传统的WEB工程是将服务端所有的功能模块打包到一起并放在一个WEB容器中运行。很多企业的Java应用程序打包为WAR包。下图所示为一个在线商店系统的功能：客户下订单、核对清单和信用卡额度，并将货物运输给客户。传统单体应用的技术架构随着应用的功能越来越庞大，访问量越来越大，需求变化越来越快，单体应用架构经常会遇到以下几方面的痛点太慢根据技能划分团队——UI、应用、中间件、数据库等太脆弱一个bug可能很快导致整个系统瘫痪测试效率低每次变更需要全部完整的验证测试，难以支撑持续交付。责任不明确代码是共同灾难的受害者，责任不明确时，忽视成为常态太复杂应用变得越来越大和复杂，开发人员越来越难以理解。共享层（ORM，消息等）不得不处理100%的用例，而不是单个的解决方案责任不明确太慢针对性扩展差太复杂测试效率低太脆弱针对性扩展差应用的不同部分有不同的性能需要——更多CPU、更多内存、更快网络等为了解决上述痛点，单体应用技术架构的扩展方式为应对业务量增长，应用系统可以从三个维度扩展：X轴扩展，水平复制。即在负载均衡服务器后增加多个WEB服务器；Z轴扩展，数据划分。即分库分表（分库是将关系紧密的表放在一台数据库服务器上，分表是因为一张表的数据太多，需要将一张表的数据存在不同的数据库服务器）；Y轴扩展，功能分解。将不同职能的模块分成不同的服务。从Y轴这个方向扩展，才能将单体应用分解为不同的服务，例如订单管理中心、客户信息管理中心、商品管理中心等。单体应用复制和负载平衡X轴扩展—水平复制多服务类型Y轴扩展—功能分解Z轴扩展—数据划分AKF可扩展立方（ScalabilityCube）**AKF可扩展立方（ScalabilityCube）来自《可扩展的艺术》服务化的Y轴拆分单体应用策略6单一职责原则（SRP）将改变原因相同的聚在一起，将改变原因不同的相分离；SRP将类职责定义为变更理由，并且是类变更的唯一理由。将SRP应用于服务设计，一个服务只完成某一类功能，跨功能则需要拆分服务借鉴Unix工具的设计Unix提供大量的实用小工具，比如grep、cat、find、ps等。每个实用小程序仅将一件事情做到极致。它们可以通过shell脚本连接起来，从而执行复杂的任务。在Unix工具中对服务建模并创建单一功能服务很有道理动词或者用例（Usecase）划分系统例如，经过划分的电子商务应用具有负责订单运送的发货服务。另一个通过动词划分例子是实现登录服务的Login服务通过名词或者资源划分系统这种服务负责给定类型资源或者实体的所有操作。例如，在电子商务应用中看到的，通过“库存服务”跟踪仓库中的产品；在线商店拥有“目录服务”领域模型驱动设计（DDD,DomainDrivenDesign）把复杂的领域拆分成不同上下文边界以及它们之间的关系。这样的过程对于整体架构和微服务框架都很有用，服务间存在着明显的关系，帮助我们对上下文边界进行区分领域驱动设计方法原则参考实践操作根据功能和资源分解单体应用后，形成微服务（服务化子系统）的应用架构示例复用服务，灵活插拔，可柔性编排通过对服务的复用和编排快速实现新的业务场景通过对服务的优化和调整来快速实现业务活动的操作变化小应用，快速灵活响应业务变化基于服务设计实现的轻应用，松耦合，独立交付影响面小，交付效率提升，快速响应业务变化快速扩展，成效好横向扩展便利，只需要扩展所需部分，扩展性更强、成本更低快速开发、高频部署各个服务独立开发、独立部署、独立运营，提高开发效率和部署频率，降低测试时间和部署风险服务化带来的收益4Agenda91为什么要做服务化ISC+服务化V模型服务化工作方法23服务识别与定义3.1服务设计与实现3.2服务管理与运营3.3持续交付流程3.4概念高阶设计阶段详细设计阶段1应用组是应用域的细分，是一组强相关应用的组合业务子领域业务领域下的具体子领域划分业务能力对应于业务子域下的具体能力定义，目前ISC+对应于L3的能力定义业务领域针对业务所处的企业业务领域范畴应用域应用功能模型最高层分组，将应用架构的交付分为几个大的领域服务化子系统由业务服务组合而成，支持一组相关业务活动的应用，可独立部署应用组ApplicationGroup应用域ApplicationDomain业务领域BusinessDomain业务子領域BusinessSub-Domain业务能力BusinessCapability服务化子系统ApplicationIT业务业务活动(Activity)业务服务(BusinessService)业务活动是对工作流中一个具体完整业务处理单元的详细描述一般情况下一个业务能力对应多个业务活动业务服务业务目的清晰，功能独立完整单一的一组API或业务操作。在ISC+业务服务颗粒度定义原则如下：1、对相同或相似功能的业务活动的抽象与组装；2、包含独立的业务实体；识别、抽象业务活动通过活动识别业务服务进行业务服务分组ISC+试点：服务化V模型6ISC+试点：包含主要的4个业务要素、5个应用要素和7个数据要素，实现业务到IT服务拉通7应用系统模型应用功能模型1应用组ApplicationGroup应用域ApplicationDomain业务领域BusinessDomain业务子領域BusinessSub-Domain业务能力BusinessCapability服务化子系统Application业务活动(Activity)业务服务(BusinessService)业务能力业务场景工作流业务活动业务服务服务API服务分组ABB能力框架场景清单流程图APPAGAD服务化子系统能力框架业务场景工作流业务活动业务服务(含服务API)服务化子系统应用组应用域服务API服务API服务API业务服务描述业务对象信息链概念模型逻辑模型数据流/数据源物理模型业务要素数据要素图例数据标准注：详细的数据工作方法请参考《ISC+数据工作汇报》一个服务API实现了完整独立单一的业务逻辑；服务API的颗粒度定义由服务消费者驱动。TaskTaskTaskTask应用要素业务侧业务流程的级别12L6任务L5活动L4工作流L3

业务能力L2业务子领域L1业务领域价值链层级，从客户价值出发，体现了公司的业务模式和价值链特点职能层级，表现公司内部部门层级上，以达成内部客户需求为目的的各部门间或各岗位间的协作关系工作流分不同的级别，从描述企业增值的端到端工作流到描述一个角色具体活动的工作流活动的一部分，即子活动。将活动进一步分解的目的在于便于理解和执行用活动将流程分解成落实到角色的可执行单元，实现人员的专业分工能力指为实现某一特定目标的一组人力、流程和技术的集合ISC+服务化V模型定义的业务流程层级解释业务能力定义13能力指为实现某一特定目标的一组人力、流程和技术的集合。[1]能力管理指组织基于价值贡献，结合公司客户价值主张，来定义能力绩效目标，以剔除低效能力并聚焦能带来财务收入的高效能力。——维基百科业务能力定义的是干什么，而非怎么做。业务能力能帮助企业实现期望达到的结果。在能力模型里，明确了不同层级的能力并给出了详细定义，也就是我们经常提到的L1,L2和L3能力（根据业务的复杂程度可能还会有更多层级），每下一层，能力会更加细化。问题关键词能力说明

华为的定义What组织基于当时的业务规则，记录数据并使用数据引导系统行为对能力的文字描述Where地理基于当时的业务规则，解决地理或空间分布问题，组织运输、物流和商务沟通执行的地点How变革基于当时的业务规则，负责流程执行并创造附加值执行方法，如流程，XXXWho互动基于当时的业务规则，与用户互动，支撑客户达成某一期望行为。执行的角色When时间基于当时的业务规则，负责设定业务里程碑和编排流程的执行能力执行的时间点Why动机有能力展示业务目标达成了，业务风险降低了以及当时的的业务规则符合业务目标预期。KPI的衡量关于能力的6个基本问题

14能力是一组人力、流程和技术的集合，如果详细设计一个能力，我们将会从以下6个方面来综合考虑：ISC+V模型从能力到活动15能力设计场景(工作流)->活动步骤:描述WHAT“做什么”–蓝图阶段能力框架业务高阶设计–单独或共同能力融入面向未来的思考、愿景、领先实践和前沿科技（例如大数据等）低阶一些的能力需要在详细设计中进一步描述“做什么”步骤:考虑WHERE“在哪里”去定义场景能力可能会因为地理区域、业务或运作模式等的不同而有差异，因此能力需要支撑多场景。举例来说，不同的订单类型可能会来自于不同的商业模式，这就需要在“订单接收”和“订单处理”能力下建立多重场景。用工作流来描述HOW“怎么做”，从而实现该能力。在工作流中，有逻辑关系的一系列业务活动支撑能力如何实现“谁”应该作为“角色”被呈现。“什么时候”表述执行时间点。“为什么”作为KPI，用以度量客户价值如何被影响。1）客户：是流程服务的对象，对外来讲是单位服务的个人或组织，对内来讲是流程的下一个环节；2）价值：是流程运作为客户带来的好处，很多情况下不是用货币来衡量的，它可以表现为提高了效率、降低了成本等等；3）输入：是运作流程所必须的资源，不仅包括传统的人、财、物，而且包括信息、关系、计划等；4）活动：是流程运作的环节；5）活动之间的相互作用：是环节之间的关系，把流程从头尾串联起来；6）输出：流程运作的结果，它应该承载流程的价值。工作流的定义以及六要素16工作流是可以被重复执行，逻辑上相互关联的一组业务活动序列，将明确的输入转换成明确的输出，从而实现为客户和向客户交付价值（产品和服务）的业务目的。工作流分不同的级别，从描述企业增值的端到端工作流到描述一个角色具体活动的工作流。□定义□工作流六要素活动（Activity）定义17□定义□解释及说明

是流程的基本单元，是一组相互联系的、有明确成果和输出的任务或行动。如：汇总信息、确认客户资信度、评审方案一般以动宾结构来命名（动词+名词）。每个活动都是由一个角色来负责，某些活动可以有协同参与的角色共同完成活动，但如果某项活动存在多个责任角色，需要拆分成不同活动，以便各负其责。每个活动都有明确的输入、输出，如果存在多个活动，其责任角色相同，输入输出相同，则建议对这些活动进行合并。一般来说，流程活动描述要能直接指导业务操作，但对于较复杂的活动，可以下挂操作指导书做进一步的细化说明。流程活动的颗粒度没有严格的衡量标准，对于业务成熟度高（作业相对标准化、自动化率较高、员工技能娴熟等）的流程活动描述可以概括、简练，反之则要细化和详细一些；流程活动的颗粒度还与IT相关，如果业务操作的IT化率较高，则流程活动描述相对概括、简单，反之亦然。ActivityARoleARoleBActivityBInputInputoutput业务侧术语范例18术语术语定义范例及说明业务领域针对业务所处的企业业务领域范畴针对业务所处的企业业务领域范畴，目前已有9大业务领域，包括：StrategyCustomerExperience/CustomerOrientedServiceInnovateandDev.MarketSellSupplyServeandSupportEcosystemManagementEnablement业务子领域业务领域下的具体子领域划分业务领域下的具体子领域划分，例如Supply业务领域包括：PlanSourceMakeDeliverReturnIntelligence&AnalyticsValueChainVisibility业务能力对应于业务子域下的具体能力定义，目前ISC+对应于L3的能力定义具体业务子领域下包含的L3能力，例如Deliver业务子领域包括：ManageOrderPlacementManageOrderHandlingOrderClosingWarehouseMgmt&OperationTrans.Mgmt&OperationCustomCompliance&OperationPlugandPlaySupplyNetworkIT侧术语范例19术语术语定义范例及说明应用域应用功能模型中的最高层分组，将应用架构的交付分为几个大的领域根据华为目前的定义，应用域包括：Supply、Procurement、LTC、SD、Finance、IPD等应用组是应用域的细分，是一组强相关应用的组合各应用域下有不同的应用组定义，例如Supply应用域下包括：计划管理订单管理专业制造流通加工物流管理等应用组服务化子系统由业务服务组合而成，支持一组相关业务活动的应用，可独立部署基于业务服务的聚合，识别出不同的服务化子系统，例如，计划管理包括：需求感知与预测、全球集成计划管理、全球供应主计划、国家集成计划、供应能力管理等流通加工包括：流通订单管理，流通工单管理，理货包装、标签管理等Agenda201为什么要做服务化ISC+服务化V模型服务化工作方法23服务识别与定义3.1服务设计与实现3.2服务管理与运营3.3持续交付流程3.421服务设计服务识别与定义服务设计与实现服务管理与运营识别业务场景，设计工作流和定义业务活动识别及定义业务服务迭代计划制定业务与IT携手，解耦业务流程、聚焦创新、面向客户与业务操作识别及定义服务通过业务与IT一体化运作，迭代详细设计、开发测试与部署以实现服务的快速交付通过建立“服务市场”与服务“运营平台”，建立服务运营机制，促进服务的灵活应用与创新服务发现管理（API)服务访问管理服务SLA管理服务开发、测试服务部署、运维服务的全生命周期管理持续交付Agenda221为什么要做服务化ISC+服务化V模型服务化工作方法23服务识别与定义3.1服务设计与实现3.2服务管理与运营3.3持续交付流程3.4LWA业务服务识别总览13业务与IT携手，解耦业务流程、聚焦创新、面向客户与业务操作识别及定义服务业务代表场景/工作流/活动设计原则：愿景驱动领先实践支撑关键设计明确的业务规则考虑因素业务服务识别原则：对相同或相似功能的业务活动的抽象与组装包含独立的业务实体一个服务API实现了完整独立单一的业务逻辑服务API的颗粒度定义由服务消费者驱动服务识别及定义1识别业务场景，设计工作流，定义业务活动2识别及定义业务服务3制定迭代计划L3业务能力业务代表/应用组产品经理业务代表/子产品经理迭代计划制定原则：最小可接受的部署版本业务服务的依赖关系业务服务的工作量估计可投入交付的人力资源服务识别和定义主要工作和输出24服务识别、服务定义场景、工作流、活动识别与定义业务服务制定迭代计划负责人/参与人主要输出模板、范例主要工作项业务代表业务代表/应用组产品经理业务代表/子产品经理设计场景设计工作流定义活动根据业务活动识别业务服务，形成业务服务列表进行业务服务详细设计，完成里程碑业务详细设计方案刷新业务服务列表1.场景定义2.工作流说明3.活动列表4.业务服务列表（不含API定义）5.里程碑详细设计说明书制定里程碑迭代计划设计子系统产品/数据标准定义补充服务列表中API定义6.里程碑迭代计划7.产品服务化设计文档/数据标准8.开发测试迭代计划(XMEN)9.更新的业务服务列表（含API定义）概念、高阶及详细方案设计Sprint0123识别业务场景，设计工作流，定义业务活动25阶段名称识别业务场景，设计工作流和定义业务活动负责人业务代表阶段输入概念设计方案、能力框架图、业务创新需求阶段输出业务场景定义，工作流，业务活动列表及业务活动上下文描述原则基于业务愿景，参考领先实践进行识别业务场景，设计工作流首先确定明确的场景识别要素，再进行场景识别和收敛业务活动尽可能有明确的执行主体、输入输出、操作对象、业务规则、可衡量的完成标准业务创新点需求和新的操作模式需要体现在具体的场景和活动中方法步骤识别业务场景参考业界的业务模式和场景识别要素，识别L3业务能力下端到端的业务场景；设计工作流明确不同场景下的业务规则，根据业务规则设计工作流，并分析工作流在不同业务环境下（地区、业务模式、组织形态…）的差异点以及对业务环境和操作环境（内部人员操作、客户操作、系统操作…）的影响；工作流设计需要包含清楚的角色定义，流程的活动规则描述和关键设计点说明定义业务活动根据不同的业务场景下的工作流，确定每个活动的参与业务角色，设计业务活动操作场景及核心业务处理逻辑；业务角色必须来自XX系统中已经发布的角色，如果有新增角色，需要经过审批并发布，或者合并到已有的角色中；对相同或相似功能的业务活动进行抽象与组装，归并不同场景下的活动，形成活动列表（包含活动名称、描述、输入、输出、业务规则、业务实体等）。1以OM为例，识别业务场景，设计工作流，

定义业务活动26识别活动定义活动识别业务场景设计工作流定义业务场景L3业务能力6.4.1Manageorderplacement验收确认触发开票触发收入/成本确认关闭订单无安装服务清晰PO132无安装服务BulkPO+Call-off含安装服务清晰PO4配置+MOS计划+PO5框架合同+结算PO生成内部销售订单分流订单处理站点辅料配置生成站点要货需求验证订单承诺订单生成SO分发订单/需求获取订单生成要货需求确定关联交易路径计算关联交易价格生成内部采购订单变更订单履行监控/异常处理检查备发货条件编排订单模拟供需排产订单确定交单计划检查齐套性制定发货计划生成发货单释放订单监控硬件履行触发软件授权触发服务履行执行Claim订单12345678910111213141516171819202122232425262830履行逆向订单27293132336.4.2Manageorderhandling6.4.3OrderclosingISC+能力框架V1.3版本下的OM的L3业务能力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细化OM的L3级业务能力，识别出相应业务场景16基于客户旅程，解耦端到端流程，细化到业务子流程，为细化工作流做准备通过DesignThinking中的用户画像和客户旅程，设计工作流对应的业务活动，体现关键设计点与创新点设计工作流识别业务场景进行客户需求调研，同时在OM能力全景视图内选取影响业务流程的关键变化因子，设计OM业务子场景基于相同关键业务活动要素，把业务子场景收敛为5种典型业务场景，作为后续工作流设计的基础完善业务活动的执行主体、输入输出、操作对象、业务规则、可衡量的完成标准基于业务目的、输入输出和业务规则归并功能相同或相近的活动，输出业务活动列表定义业务活动场景名称配置+MOS计划+PO含安装服务清晰PO框架合同+结算PO无安装服务清晰PO1345无安装服务BulkPO+Call-off2产品：硬、软、安装服务主要特征：下客户PO时点履行信息不清晰，根据配置+MOS计划驱动履行硬软服统签PO：根据配置+MOS计划驱动履行，PO控制总量以及结算硬/软单签PO：根据配置+MOS计划交付到站点安装服务单签PO：需要HW提供物流服务（如中心仓

站点、客户仓

站点）产品：硬、软、安装服务主要特征：清晰PO，PO驱动履行硬软服统签PO：硬件/软件由PO驱动，供应至站点安装服务单签PO：不需要HW提供物流服务（如客户仓

站点）产品：硬、软、安装服务主要特征：在没有PO的情况下，根据配置+MOS计划先交付，PO后下真对优质客户，在没有得到PO的情况下，通过配置+MOS计划指导交付，再引导客户下结算PO客户下PO的时点，可以是交付过程中，也可以是交付后产品：硬、软、非安装服务主要特征：清晰PO，PO驱动履行硬件/软件履行信息清晰，PO驱动供应至客户指定地点（非华为仓库）非安装服务的信息可支撑商务结算产品：硬、软主要特征：下PO的时点履行信息不清晰，客户会后续提供供应指令（Call-off）Call-off驱动硬/软供应，PO控制总量以及结算同一PO里可含延长维保详细说明PO例举硬+软+安装服务履行信息不确定PO硬+软PO（货到中心仓）有硬件的履行（中心仓

站点or客户仓

站点）的安装服务PO硬+软+安装服务清晰PO；无硬件的履行（如客户仓

站点）的安装服务PO，根据配置+MOS计划交付，交付过程中，客户下PO根据配置+MOS计划交付，交付后，引导客户下PO硬+软清晰PO；硬件供应到客户指定地点（含站点）软件年费PO单独延长维保PO专业服务PO硬+软，履行信息不确定PO；客户后续提供Call-off信息设计业务子流程中的业务活动，体现出关键设计点与创新点18基于客户旅程，解耦端到端流程，细化到业务子流程，为细化工作流做准备通过DesignThinking中的用户画像和客户旅程，设计工作流对应的业务活动，体现关键设计点与创新点设计工作流识别业务场景基于客户旅程，进行客户需求调研，同时在OM能力全景视图内选取影响业务流程的关键变化因子，设计OM业务子场景基于相同关键业务活动要素，把业务子场景收敛为5种典型业务场景，作为后续工作流设计的基础完善业务活动的执行主体、输入输出、操作对象、业务规则、可衡量的完成标准基于业务目的、输入输出和业务规则归并功能相同或相近的活动，输出业务活动列表定义业务活动客户/CCO/PRM系统自动合同履行专员SO处理专员无安装服务清晰PO-Part1下单订单确认合同注册需求获取订单生成订单承诺订单验证不通过订单分发关联交易处理专员管理关联交易路径管理关联交易价格内部采购订单生成内部销售订单生成AP/AR财经ERPCSO生成12ERPISO生成验证结果通过3对识别的业务活动进行分析和归并，确定活动定义20完善业务活动的执行主体、输入输出、操作对象、业务规则、可衡量的完成标准基于业务目的、输入输出和业务规则归并功能相同或相近的活动，输出业务活动列表基于客户旅程，解耦端到端流程，细化到业务子流程，为细化工作流做准备通过DesignThinking中的用户画像和客户旅程，设计工作流对应的业务活动，体现关键设计点与创新点定义业务活动设计工作流识别业务场景基于客户旅程，进行客户需求调研，同时在OM能力全景视图内选取影响业务流程的关键变化因子，设计OM业务子场景基于相同关键业务活动要素，把业务子场景收敛为5种典型业务场景，作为后续工作流设计的基础验收确认触发开票触发收入/成本确认关闭订单无安装服务清晰PO132无安装服务BulkPO+Call-off含安装服务清晰PO4配置+MOS计划+PO5框架合同+结算PO生成内部销售订单分流订单处理站点辅料配置生成站点要货需求验证订单承诺订单生成SO分发订单/需求获取订单生成要货需求确定关联交易路径计算关联交易价格生成内部采购订单变更订单履行监控/异常处理检查备发货条件编排订单模拟供需排产订单确定交单计划检查齐套性制定发货计划生成发货单释放订单监控硬件履行触发软件授权触发服务履行执行Claim订单12345678910111213141516171819202122232425262830履行逆向订单2729313233业务场景及其对应工作流的上下文定义31序号属性说明1业务场景名称业务场景简称2场景识别要素说明识别该场景对应的识别要素，比如履约方式是OM的场景识别要素，分为：PO履约和项目履约3场景描述描述对应业务场景的业务规则和设计思路4工作流图描述场景对应的工作流图，流程图（泳道图）中需要有清晰的角色定义和各角色对应的业务活动；业务活动的命名采用业务语言，明确表达业务行为，格式建议采用动词+名词，从而角色与业务活动组成完整的主谓宾逻辑关系；如存在重要外部依赖或输入，应标明在工作流图中。5业务规则说明描述工作流中关键业务活动的业务规则、设计点、输入输出以及异常情况描述流程流转的判定条件等业务活动识别需要包含的上下文定义32序号属性说明1业务活动编号(BusinessActivityNo.)参考服务对象编码规则2所属L3业务能力(L3Capability)说明活动所属的L3能力，具体L3能力参见ISC+能力框架图3输入(Input)描述活动的输入信息，包括信息内容(What)和来源(From);输入内容指本活动的开展所需要的前置依赖信息或依据，输入信息载体一般是业务对象输入的来源可能是前序活动的输出、外部系统、线下表单等。如暂不清楚数据来源，则此列放空4输出(Output)描述活动的输出信息，包括信息的内容(What)和可能的使用者(TO)输出信息载体一般是业务对象5相关业务对象(RelatedBusinessObject)活动操作的主要业务对象。业务对象可参照BusinessObjectRefTab页阶段名称识别及定义业务服务负责人业务代表/应用组产品经理阶段输入工作流、业务活动列表阶段输出业务服务列表，里程碑详细设计说明书原则业务服务编号规则，业务服务命名规则请参考服务对象命名规则；业务服务包括业务实体+一组API，例如：围绕业务实体SO，相应的业务服务可以有CreateSO,DisplaySO等；业务服务颗粒度的原则：

对相同或相似功能的业务活动的抽象与组装包含独立的业务实体一个服务API实现了完整独立单一的业务逻辑服务API的颗粒度定义由服务消费者驱动方法步骤业务服务识别根据业务活动定义和业务服务识别原则，识别出业务服务，形成业务服务列表补充服务上下文根据业务服务模板，补充相应的上下文信息，比如服务描述、输入、输出、依赖关系等基于DesignThinking中的Prototype

Visualize和Ideate

Brainstorm，进行业务服务详细设计，完成里程碑详细设计说明书识别及定义业务服务212业务服务的业务特征34每个业务服务应该提供具体业务功能，有明确的业务含义不能指望一个业务服务实现全功能，包打天下明确业务含义一个业务服务实现的功能应该是单一的、确定的且完整的，既不能片段化也不能过于泛化业务职责完整单一服务调用是有成本的，应尽可能减少各种跨服务调用的消耗颗粒度不宜太小业务服务应该围绕业务实体操作，比如RESTFUL服务基于WebResource操作围绕业务实体操作业务服务不应随服务调用者改变而不得不变化随着服务版本升级，业务功能应向下兼容业务功能稳定业务服务的技术特征35业务服务更多是为提供外部进程调用服务，调用者不应关心服务在远程还是本地。调用者通过网页服务请求或者远程调用通信的方式进行通信。为分布式而生调用者应不必也无需关心业务服务采用的数据存储方式和具体实现细节与数据存储方式无关一类业务服务应该对应一组报文。一组报文内通常包含服务申请报文、服务结果返还报文等接口标准化调用者应不必也无需关心业务服务采用的技术栈和具体实现逻辑与开发语言无关服务调用者不应随着业务服务内部实现逻辑的变化而变化，业务服务的接口应具有一定的扩展性，保证其稳定性接口稳定服务应该有明确的边界，封装业务功能和业务数据，不暴露内部实现细节聚合因同一理由变化的功能与数据，分离因不同理由而变化的功能与数据高内聚业务服务之间应该横向解耦，一个服务的改变不应导致其他服务必须改变业务服务内部应该纵向解耦，每层内部的变化不应导致其他层必须改变服务调用者与服务提供者解耦，不能因为一方变动，另一方必须改变低耦合业务服务的运营特性36业务服务的绩效可以度量，包括订阅数量、调用次数、响应时间等绩效指标可度量超过3个月没有调用者或者没有调用记录的业务服务，应该考虑下架，以保证业务服务都是有价值的有价值根据服务调用次数或者数据流量进行定价核算可定价业务服务OpenAPI需要注册到API管理平台，形成服务目录，供服务消费者访问调用可注册可以监控业务服务的运行状态可以启停业务服务可监控业务服务包含的上下文定义37序号属性说明1业务服务编号(BusinessActivityNo.)业务服务的唯一标识2业务服务名称(BusinessSrvName)业务服务的英文名称3业务服务描述(BusinessServiceDesc)业务服务的功能描述4对应的业务活动(BusinessActivityNo.)对应的业务活动的编号，如果一个业务服务对应多个业务活动，则需要列出所有对应的业务活动的编号5服务组(ServiceGroup)业务服务所属的服务组，如果尚未对业务服务进行分组，则该列可放空6服务子系统(Application)业务服务所属的服务化子系统7服务接口名(SrvInterfacesName)业务服务对外提供的调用接口（API）的名称(一个服务可以有多个API)。接口的命名遵从动词开头的格式，可以是动词+宾语，比如getPO；可以是动词+宾语+方式，比如getPOByName8服务接口描述(SrvInterfacesDesc)业务服务API实现的功能描述9输入(Input)API的输入参数10输出(Output)API的输出结果11相关的业务对象(RelatedBusinessObject)业务服务操作的主要业务对象12依赖的外部服务(DependenceDesc)本服务对其他服务的依赖说明，包括被依赖服务的编号、名称和API13备注(Comments)其它需要说明的补充信息业务活动如何识别、归结业务服务382、一个活动识别为多个业务服务说明：业务活动的粒度较粗，功能不单一，包含了多个操作步骤（建议细化活动后再识别服务）范例：OM的TriggerBilling/Revenue活动中可以识别为TriggerBilling、TriggerCost/Revenue、TriggerAP/ARgeneration等几个服务1、一个活动识别为一个业务服务说明：业务活动包含了单一且完整的业务处理逻辑范例：OM的SOGeneration活动可识别为GenerateandverifySO服务；CCO的ViewProductList可识别为DisplayProductCatalogandProductList服务业务活动与业务服务的关系3、多个活动识别归结为一个业务服务说明：多个活动是对一个业务实体操作且处理逻辑简单清晰，如每个活动都对应出一个业务服务，业务服务的颗粒度太小，不方便管理范例：CCO中不同工作流中对购物车的操作，可以归结为统一的购物车管理服务经过上述分析过程，业务能力已经分解为各类业务活动并输出业务活动列表，后续将根据业务活动识别相应的业务服务。

通过业务活动识别业务服务有如下三种情况：以OM为例，识别业务场景，设计工作流，

定义业务活动，识别业务服务39验收确认触发开票触发收入/成本确认关闭订单识别业务场景定义工作流识别业务服务定义并收敛业务活动无安装服务清晰PO132无安装服务BulkPO+Call-off含安装服务清晰PO4配置+MOS计划+PO5框架合同+结算PO生成内部销售订单分流订单处理站点辅料配置生成站点要货需求验证订单承诺订单生成SO分发订单/需求获取订单生成要货需求确定关联交易路径计算关联交易价格生成内部采购订单变更订单履行监控/异常处理检查备发货条件编排订单模拟供需排产订单确定交单计划检查齐套性制定发货计划生成发货单释放订单监控硬件履行触发软件授权触发服务履行执行Claim订单12345678910111213141516171819202122232425262830履行逆向订单2729313233分流订单处理站点辅料配置生成订单验证订单承诺订单分发订单/需求确定关联交易路径生成国家要货需求生成站点要货需求生成内部采购订单生成内部销售订单监控订单变更订单处理异常生成采购计划生成DO计算关联交易价格计算清关金额检查备发货条件制定发货计划编排订单触发软件授权触发服务履行执行Claim订单释放订单履行逆向订单确定交单计划匹配资源监控硬件履行验收确认触发开票触发收入/成本确认关闭订单123456789101112131415161718192021222324252628302729313233OM部分服务清单（示例）

40*详细定义参见OM服务列表，持续更新业务活动编号

BusinessActivityNo.业务活动名称

BusinessActivityName对应业务活动

BusinessActivityNo.对应业务活动名称

BusinessActivityName服务组

Application服务子系统

ApplicationOMActivity_001订单分流（临时）

OrderShunt(temporary)OMSRV_001订单分流（临时）

OrderShunt(temporary)订单创建

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制定迭代计划阶段详细描述41阶段名称制定迭代计划负责人业务代表/子产品经理阶段输入场景、活动、业务服务列表可投入人力资源情况（产品经理提供）阶段输出里程碑迭代计划（PPT/EXCEL）产品服务化设计文档/数据标准（UseCase，WORD）开发迭代计划（UserStory，录入XMEN系统）更新的业务服务列表（补充了API定义）原则明确迭代里程碑的目标、时间段和工作范围，用于安排任务，调配人力资源，排定工作时间建议采用固定短周期迭代，一个SPRINT一般为2~4周，最长不超过6周制定开发迭代计划的同时，可以根据里程碑详细设计说明书编制相应的测试用例，准备开发和测试环境在完成里程碑详细设计说明书及开发迭代计划后，可以把相应的业务服务和实现需求规则说明以UserStory的形式录入到XMEN平台中进行产品敏捷开发管理方法步骤产品团队根据里程碑详细设计说明书，编制以USECASE分析为主要内容的产品需求规格说明，形成产品服务化设计文档；根据产品服务化设计文档中的USECASE设计内容，结合项目团队人力情况，评估相应工作量，分解为USERSTORY，形成相应的开发和测试迭代计划；将开发和测试迭代计划录入到XMEN项目敏捷开发管理平台；将UserStory中定义的服务API补充到业务服务列表。3迭代Sprint0的目标42Sprint0是对于release做准备或是暖身的Sprint，是应用架构以及技术架构工作中的正常流程。Sprint0作为一个releasecycle的开始，其目标为：识别Release的范围以及目标制定Release的时间排程计划决定对于应用架构以及技术架构的工作中，Sprint的数量以及Sprints的长度识别对于Release来说的UserStory/UseCase并将信息输入产品backlog，同时识别并决定在哪一个sprint中开发这些stories识别当前release的技术架构的需求构建持续集成(CI)与持续交付(CD)的pipeline定义对于开发测试的策略与环境需求确认自动化测试框架的准备程度对于当前release做release计划分析当前release的需求对于套件开发，分析此release中产品backlog中的每个项目的匹配与差异度分析对需求做创建、更新、估算以及优先级排序分解usecase成为userstories创建包含任务如创建物理数据库设计（如果是自研开发）或是高阶技术设计的设计框架ISC+对象命名规则43对象命名规则编码规则业务活动符合业界标准命名，需以“<Domin>_”+<SubDomain>+”_”开头，工作流图（泳道图）中的业务活动的命名应该遵从动词+宾语（比如，提交PO/审核PO等）或单独动词（比如提交/审核/会签等）的结构，这样业务活动与泳道图中最左列的角色组成了主+谓+宾或者主+谓的结构例如：ISC_DELIVERY_创建SOISC_DELIVERY_删除SO“ISC_”+<SubDomain>+”_”+”capability

code”+xxxxxx–从001到999例如：ISC_DELIVERY_001_001第一个001代表ManageorderplacementDomin:ISC,ISD,CRM,FIN