业务与管理实践-敏捷外包在客户解决方案中心的实施.pdf

上传人:哈尼dd 文档编号:5017621 上传时间:2020-01-28 格式:PDF 页数:31 大小:1.32MB
返回 下载 相关 举报
业务与管理实践-敏捷外包在客户解决方案中心的实施.pdf_第1页
第1页 / 共31页
业务与管理实践-敏捷外包在客户解决方案中心的实施.pdf_第2页
第2页 / 共31页
业务与管理实践-敏捷外包在客户解决方案中心的实施.pdf_第3页
第3页 / 共31页
业务与管理实践-敏捷外包在客户解决方案中心的实施.pdf_第4页
第4页 / 共31页
业务与管理实践-敏捷外包在客户解决方案中心的实施.pdf_第5页
第5页 / 共31页
点击查看更多>>
资源描述

《业务与管理实践-敏捷外包在客户解决方案中心的实施.pdf》由会员分享,可在线阅读,更多相关《业务与管理实践-敏捷外包在客户解决方案中心的实施.pdf(31页珍藏版)》请在三一文库上搜索。

1、敏捷外包在客户解决方案中心的实施敏捷外包在客户解决方案中心的实施 Apply Agile Outsourcing in Solution Center 李建昊李建昊 演演 讲讲 大大 纲纲 引论引论 Solution Center的诞生的诞生 敏捷与软件外包敏捷与软件外包 敏捷外包的实践敏捷外包的实践 问答环节(问答环节(Q&A) 引引 论论 聚焦 产品转向服务 客户的定制化服务 服务客户 高度的客户参与,快速的客户响应 高质量的产品解决方案 解决方案 客户解决方案中心(Solution Center)应运而生 采取离岸外包模式进行交付 敏捷外包 敏捷的方法运用到外包管理当中 有效地解决So

2、lution Center的管理和交付 从产品转向服务从产品转向服务 卖产品,还是卖服务? 制造业和服务业的 边界越来越模糊 产品和服务、 制造业和服务业不断融合 3 1 6 361服务体系 三位一体的 安装服务 安装作业的 6个一标准化 一个电话服务到家 转型的典范转型的典范 IBM华丽的转身- -成立全球服务部(IGS)突破业务瓶颈 1993年,当IBM遭遇瓶颈的时候,郭士纳(Louis Gerstner)带领 IBM 转型服务。IGS(IBM Global Services)的出现是其业务转型 的结果。 IGS IBM全球服务部 ITS(Integrated Technology Ser

3、vice) BCS(Business Consulting Service) AMS(Application Management Service) TSS(Technique Sales Support)- 提 供 IT 服 务 主 要 是 售 后 服 务, 包 括 IBM 和 非 IBM 的 产 品 的 维 护。 做项 目/ 行 业 咨 询, 各 个 方 面 的 S O (Strategy Outsourcing) 主 要 作 外 包。 技 术 部 门 产品的售前技术支持, 客户培训以及售后的 电话技术支持,包括 硬件以及软件。 Solution Center的机遇和挑战的机遇和挑战 高质

4、量的交付高质量的交付 整体解决方案整体解决方案 帮助客户实现 其商业价值 提高客户满意度提高客户满意度 加快响应速度加快响应速度 个性化个性化 定制化定制化 加大客户参与程度加大客户参与程度 高质量的交付高质量的交付 整体解决方案整体解决方案 帮助客户实现 其商业价值 提高客户满意度提高客户满意度 加快响应速度加快响应速度 个性化个性化 定制化定制化 加大客户参与程度加大客户参与程度 自制?还是外包?自制?还是外包? 自制自制 外包外包 每日使用成本:0.2万 生产成本:20万 每日使用成本:1万 设当设当X天的时候,两方案成本相等,即:天的时候,两方案成本相等,即:20+0.2X=1X 可计

5、算出:可计算出:X为为25天天 如果使用日期超过如果使用日期超过25天天,应该自制,否则应外包。,应该自制,否则应外包。 外包模式及其优势外包模式及其优势 外包(外包(Outsourcing) 外部、资源 、使用(Outside,Resource,Using)的结合体。 它的意思是,在一定的时间范围内,以及在协议的基础上,将企业的任务 交由其它企业完成。 离岸外包离岸外包 (offshore) 外包商与供应商来自不 同国家 外包工作跨国完成 在岸外包(在岸外包(Onshore) 外包商与供应商来自同一 个国家 外包工作在国内完成 “岸“岸 shore”,后来多指工作地”,后来多指工作地点点(S

6、ite)。 Cost Saving Easy on Ramp-up, Ramp-down Quality & Efficiency 外包的好处外包的好处 敏敏 捷捷 外外 包包 敏 捷敏捷外包敏捷外包外 包 敏捷方法和外包的交叉,将软件敏捷方法应用于软件开发,IT运作以 及商业过程外包中。 敏捷外包实践敏捷外包实践 爱迪德爱迪德+海辉的海辉的ODC(Offshore Delivery Center)模式)模式 敏捷外包实践敏捷外包实践 - 战略制定战略制定 服务部 Services 产品部 Product 运营中心 Operations 研发中心 R&D Product Strategy Ro

7、admaps Customer Requirements System Integration Solution Delivery Client Customization Customer Service Training Customer Loyalty Design Development Testing 提高灵活性提高灵活性 降低成降低成本本 客户真实环境测试客户真实环境测试 离客户最近离客户最近 敏捷敏捷+外包外包 Solution Center 定制开发定制开发 敏捷外包实践敏捷外包实践 -Solution Center甲乙双方甲乙双方 Facility (Office) Team

8、(Engineers) Manager Training for Ramp up Specific HW & SW Guideline & Policy Product Owner Performance Review 敏捷外包实践敏捷外包实践 -Solution Center实施过程实施过程 形成形成震荡震荡规范规范成熟成熟 2011/012011/032011/062012 敏捷合同 T&M 共识 Win-Win 目标明确 需求不是很清晰 未设定SOW 采用FTE模式 甲方:提升客户价值 乙方:技术积累 尝试敏捷外包模式 信任感 归属感 甲方的PO 乙方的Team 甲乙双方的 Team 客

9、户的方案 客户的客户 团队向心力 大团队敏捷 绩效考评 跨职能 多团队 多地点 KPI MBO 360度 激励机制 高效敏捷 敏捷外包模式 。 。 。 敏捷外包实践敏捷外包实践 案例分析案例分析 案例分析:项目背景介绍案例分析:项目背景介绍 目标目标进度进度 组织组织方法方法 该项目要提供一套全新的视频解决 方案框架。 项目的客户为媒体运行商。 项目分3个阶段(当前第1阶段) - 提供基本框架 - 实现通用的功能 - 定制化服务 项目使用敏捷的方法 外包团队与内部团队交叉,不在同 一地点,项目范围复杂,涉及人员 众多。 项目的核心小组成员 -Sponsor在荷兰。 -PM在美国,PO在法国。

10、-APAC/US/EMEA的三个大区各设一个 Product Owner/Architect。 案例分析:团队分布案例分析:团队分布 U.S.A. Ground Rule:1-2-1 原则 1个Core Team 2级Product Owner 1份Product Backlog Netherlands 开发:北京Solution Center /采用ODC外包模式 开发开发:荷兰阿姆斯特丹为基于项目的外包模式 集成测试:荷兰霍夫道夫实验室(内部团队) 开发:美国卡尔斯班的研发中心(内部团队) 开发: 美国圣地亚哥为onsite外包模式 AmericanEMEAAPAC 1 2 1 China

11、 Netherlands U.S.A. 案例分析:案例分析:1个核心小组个核心小组 OwnerResponsibility 1 Product VP项目的发起人、出资者。 对Business Case负责。 2 Product Manager (Product Owner) Product Owner 3 Regional PO -American -APAC -EMEA 承担本区各团队的Product Owner/Architect 工作。 4 Program Manager项目管理 (包括进度、成本、风险等各方面) 1 案例分析:案例分析:1个核心小组个核心小组 1 核心小组处理原则 Pr

12、oduct Sponsor 授权Product Owner Product Owner Review Board PO Regional PO Core Team 每周二开sync-up meeting Program Manager每周四召集weekly program meeting, 参与人员如下: Core team成员 各Scrum team 代表 (Scrum Master或Tech Lead) 问题汇报路径: Team -Scrum Master-Regional PO-Core Team 案例分析:案例分析:2级级PO制制 为什么要2级PO? Product Owner需要跟团

13、队在一起 Product Owner需要时刻对团队available 2级PO的工作方式 PO Review Board 2级PO(4人)成为一个虚拟团队Virtual team 每天电话会议同步PO之间的信息 Regional PO 全权授权,对本区内的全权授权,对本区内的team负责。负责。 2 案例分析:案例分析:2级级PO制制 2 两级PO的工作Focus Scrum Team: -Regional PO -Scrum Master -Team Product Backlog I. User Story II. User Story III. User Story New Requir

14、ements Customer Bugs Internal Change request 1.创建 U.S & 调整优先级 2. 精炼 & 分 解U.S 3. 接收US &迭代计划 4. Daily Standup 产品,市场,客户反馈 5. 迭代交付 & 版本发布 0. 收集需求 Sprint N Backlog Must Should Could Hot fix PORegional PO 主辅 P O Sprint N+1 Backlog Must Should Could Hot fix PORegional PO 主辅 案例分析:案例分析:1份份Product Backlog 1 P

15、roduct Backlog TeamStory PointsUser Story 8I. User Story . 8II. User Story . 5III. User Story. 3IV. User Story. 7V. User Story. . 团队 1 团队 2 团队 3 团队 4 团队 5 依据团队的速度, 接收User Story 执行迭代,修正团队速度团队速度校准 案例分析:案例分析:1-2-1原则原则 产品产品市场市场客户反馈客户反馈 Product Backlog 提交、记录提交、记录 优先级 分解 粗略的估算 精炼、细化、分解 团 队 1 团 队 2 团 队 5 U

16、S PO EMEA POAPAC PO PO (Product Manager) 团 队 3 团 队 4 Scrum of Scrums Scrum of Scrums SM (Program Manager) SMSMSMSMSM Sponsor & Executive 1 2 1 案例分析:案例分析:Solution Center KPI KPI-1 (on time delivery) KPI-2 (quality of coverage) KPI-3 (quality of testing) KPI-4 (attrition) KPI-5 (infrastructure) 案例分析:如

17、何计算案例分析:如何计算Solution Center KPI KPI计算公式:计算公式:Overall KPI Rating = Rating (KPI-i ) * weight Weight: KPI-1 (on time delivery)40% KPI-2 (quality of coverage)20% KPI-3 (quality of testing)20% KPI-4 (attrition)10% KPI-5 (infrastructure)10% Rating Form 12345 Not acceptable Development required Valuable Co

18、ntribution Exceeds expectations Outstanding 例:例:Overall KPI Rating=3*40%+4*20%+4*20%+5*10%+5*10%=3.8 12345 敏捷外包实践敏捷外包实践 每一项每一项KPI都代表什么?都代表什么? KPI-1 (on time delivery) KPI-1.1 每一次版本发布和每一个迭代中, 计划的工作在约定 时间箱(timebox)中完成(DONE)的百分比(%) 目标:= 80% KPI-1.2 每一次版本发布中, 团队速度( Velocity )提升的百 分比(%) 目标:= 20% 案例分析:案例分

19、析:Solution Center KPI (KPI-1) KPI-2 (quality of coverage) KPI-2.1 每一次版本发布和每一个迭代中, 从test case - code - user story回溯(traceability)的百分比(%) 目标:= 100% 案例分析:案例分析:Solution Center KPI (KPI-2) KPI-3 (quality of testing) KPI-3.1 每一次版本发布中, 在每一交付给客户的build中,由客户发现的 BUG数, 而这些BUG本应该由测试团队发现. 目标: = 10, 具体如下 0 critica

20、l/showstopper 5 major 5 minor KPI-3.2: 每一次版本发布中, 所报出的错误BUG的百分比(%),其中, 错误BUG是指:不是真正的问题,或者是由于测试误执行,配 置误操作等造成。 目标: = 10 % 案例分析:案例分析:Solution Center KPI (KPI-2) KPI-4 (attrition) KPI-4.1 每一个日历年内, 从团队中离职/被替代的成员百分比 (%) 目标:= 20 % 案例分析:案例分析:Solution Center KPI (KPI-4) KPI-5 (infrastructure) KPI-5.1 每一个日历月内,solution center 系统的down机时间 的百分比(%)(比如,邮件系统连接故障、网络连 接故障、突然断电等) 目标:= 1% 案例分析:案例分析:Solution Center KPI (KPI-5) Q & A 谢 谢!

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 研究报告 > 商业贸易


经营许可证编号:宁ICP备18001539号-1