业务中台-服务中心设计资料
2020-04-13 11:02:48 151 举报AI智能生成
业务中台
作者其他创作
大纲/内容
问题
服务中心的边界是什么？有没有一些划分的原则和标准？
服务中心应该多大合适？对应的组织团队和流程应该怎么保障？
服务中心里面的服务数量应该有多少？粒度应该多大？
什么是服务中心
服务中心一定是不断发展的。业务架构是能反应业务变化的，服务中心作为共享架构的核心元素一定也会提现出这种变化。
服务中心中的服务形态多样性
依赖于接口的服务
依赖于工具的服务
依赖于数据的服务
服务中心可以进一步划分
服务中心价值
1、服务可重用
通过松耦合的服务带来业务的复用，不必为不同的前端业务开发各自对应的相同或者类似的服务。例如淘宝和天猫不必各自开都开发一个评价服务。
2、服务被滋养。
服务需要被滋养，不停的滋养，只有滋养才能最初仅提供单薄业务功能的服务逐渐成长为企业最为宝贵的IT资产，而服务所需的滋养正是来自新的业务不断的接入。
3、服务助创新。
创新不是一件容易的事情，因为有些本质上的创新按照传统的开发模式是需要从分析、设计、开发，每一个环节都从0开始的，这样一来就会导致投入成本大，开发周期长，可能等你开发完了，商机已经被别人抢占了。而共享服务平台中的诸多服务是经过清晰的沉淀，可以通过重新编排、组合，快速的响应市场，达成创新，如武侠小说常说天下武功，唯快不破。
4、服务敢试错。
试错和创新有着千丝万缕的关系，有时甚至可以划等号，部分试错是会变成创新的。共享服务平台由于具备快速编排、组合服务的能力，可以以较小的成本投入来构建出一个新的前端业务，即使失败了，公司损失也很小。这在传统模式构建的系统中是几乎不可能达成的。
服务中心的划分原则
1.高内聚、低耦合原则
2.数据完整性原则
3.业务可运营型原则
我们期望服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。
4.渐进性的建设原则
渐进性的建设原则是从降低风险和实施难度这个角度出发，服务化架构本来就是一种敏捷的实践，推荐小步快跑的方式逐步推进。
共享服务平台的建设思路
第一条，要找到一个合适的服务化对象。
服务本来就是个抽象概念，我们去做服务化，到底基于哪个承载对象来做服务化？这个对象既要能够涵盖各种各样的业务流程、数据服务能力，又要便于实现对对象的服务化组件封装。
第二条，建设对象服务化的基础设施。
有了服务化对象，就要解决应用服务治理的目标，就要制定并实现服务组件规范和服务治理工具与平台。有了这些规范和工具，就可以把在第一步选定的服务化对象封装成服务组件，完成治理。
第三条，服务化实施阶段。
用服务化基础设施把服务化对象变成服务组件，到了这一步，让业务方共同参与进来推动业务服务化，享受服务化带来的应用服务治理的红利。
第四条，增强服务和基础设施实现服务的精细治理。
通过产品和工具的支持，为用户提供更好理解、更易用、更优质的服务，最终达到按需服务的层次，这是我们的终极目标。
考核机制
1、服务定是重中之重（占比40%）
保障业务中台的服务能力稳定运行是各服务运营团队的关键职责，因此这项的绩效会比较关注所造成的事故等级以及次数，比如半年内出现两次P1故障，则此项考核项不达标，这部分的考核比重会占整个考核中的40%左右。
2、业务创新推动业务发展（占比25%）
为了避免服务运营团队为了单纯地追求服务的稳定运行，会有专门针对业务创新的考核，为了鼓励团队进行业务创新，适当的允许一定数量的故障率不纳入到业务稳定运行的考核中。
比如允许出现1次P1故障或者2次P2故障，不计入服务稳定考核的数量中。
比如允许出现1次P1故障或者2次P2故障，不计入服务稳定考核的数量中。
3、服务接入量（占比20%）
业务中台中的服务能支持集团中的应用越多，自然所体现出的业务价值就越大。除了对服务功能的不断完善和专业化，同时也需要做内部的营销，让更多的前端应用知道和了解到该服务能力。
所以，对于业务中台中服务的接入量一般也会占到整体绩效的20%左右。主要考量了服务能力的专业度以及对外的服务运营能力。
所以，对于业务中台中服务的接入量一般也会占到整体绩效的20%左右。主要考量了服务能力的专业度以及对外的服务运营能力。
4、客户满意度（占比15%）
业务中台掌控的业务和数据相比前端的应用方，在整个集团层面就显得更为重要和核心，为避免会让业务中台的人员滋生出高做自大的情绪，需应定期对中台服务团队进行360度的客户满意度调查。
这对中台服务团队也起到督促作用，同时调查的结果也为服务团队的服务能力提升提供了非常有价值的参考信息。
这对中台服务团队也起到督促作用，同时调查的结果也为服务团队的服务能力提升提供了非常有价值的参考信息。
0 条评论
下一页
