ToB谈谈生态合作伙伴的管理体系

　　当产业结构发生非连续的变化、跨界融合成为主旋律时，生态发展和互生共赢显得更为重要。做toB服务，有效管理合作伙伴，与合作伙伴齐头并进非常关键。
　　当前中国具有数字经济快速发展的巨大空间和优越条件，国内市场体量庞大、可观的年轻网民、政府的大力支持和参与等，已形成由若干数字化巨头引领下超越现有系统的数字化系统，整体呈现出一派欣欣向荣大有可为的市场趋势。而ToB服务市场的布局，早已不是一个新话题。
　　做什么产品，怎么做才能符合客户预期；做出来后又该如何交付到客户手中，引导客户从购买产品向购买服务过渡，然后在此基础上为更多的客户提供服务呢？
　　搭建生态合作伙伴框架，似乎已是箭在弦上。
　　最近几年，在新技术应用层出不穷、产业环境日趋动荡、客户对一体化解决方案的期望越来越高的背景下，产业边界逐渐模糊，跨界合作与价值共创成为潮流，使商业生态圈成为炙手可热的概念。
　　想要在新的商业环境下乘风破浪，还要善于连接外部资源，优化企业所在的商业生态圈。通用的底层基础设施，百花齐放的应用层，即便在当下零和博弈的竞争态势中，每家厂商依旧都在期待着分一杯羹。原来赢者通吃的超级马太效应，将转变为利益共享、合作共赢。
　　而生态视角下的企业优势和利润来源，背后的假定不再是零和博弈、你输我赢。它强调共赢把饼做大，形成共生、互生和再生的利益共同体。不追求为我所有，而是为我所用，有效地与外部资源发生连接。
　　注释：五力分析模型是迈克尔波特（MichaelPorter）于80年代初提出，用于竞争战略的分析。五力分别是：供应商的议价能力、购买者的议价能力、潜在竞争者进入的能力、替代品的替代能力、行业内竞争者现在的竞争能力。五种力量的不同组合变化，最终影响行业利润潜力变化。
　　我们已经迎来了数字经济全面发展的新契机。在线上线下深度融合、万物互联的情境下，生态战略也成为商业世界的主流，企业也逐步从平台战略向生态战略转型。都说把另外半条命交给合作伙伴，听起来我们和合作伙伴已经达成了一种血浓于水开放共生的境界。
　　那么现实情况是，怎么招募到合适的合作伙伴？如何培养合作伙伴的产品理解力和技术水平？合作伙伴的管理政策怎么定？如何保障合作伙伴资源池的动态运行？奖惩措施、保障机制又是什么？在销售全生命周期中，究竟我们该如何与合作伙伴打好组合拳确保项目的有序落地呢？
　　在谈合作伙伴管理之前，我想先分享一张图：
　　先来看图说话。当t0时，关系从0开始建立，此时维护关系的重要性高于任务的推进情况，若关系无进展，则任务的关注度较低。打个比方，当我们初次拜访客户，在基础的客户关系和合作模式尚未建立的时候，没有人会分心去关注你要解决什么问题。
　　当t0时，人们更倾向于将目光聚焦于任务的推进而非关系的维护。举个例子，对于你熟悉的朋友，当一方有事相求，你可能更多地会去关注这个事情本身如何解决，而不是拘泥于你俩之间的关系。
　　不难看出，t0就是这个分界点。我们的目标就是，尽量缩短t0，尽早到达P值，步入productivezone。
　　同样的，每个公司与合作伙伴的关系也是如此，只有当我们和合作伙伴建立起稳定的合作关系后，才能对双方的服务协同和任务推进施加一个有效的正向作用力。
　　那么，究竟如何构建与合作伙伴的良性、可持续发展的关系呢？
　　解决这个问题前让我们先来了解下合作伙伴吧。业内针对合作伙伴的类型众说纷纭，这里我想谈的是三种类型：服务商、经销商、独立软件开发商（ISV），对于每种类型的合作伙伴定义在此按下不表。
　　下面我从服务商的角度来阐述下如何搭建服务商生态合作体系。
　　合作伙伴引入后能力跟不上，项目实施过程中掉链子，派单的总是那几位老司机，合作伙伴的实施情况是个黑盒，客户对合作伙伴的表现不满意现实的情况就是，我们有可能高举旗帜招募了一帮同盟者，结果要么烂泥扶不上墙，要么留不住优秀的伙伴，最终遭殃的还是目标客户。
　　所以，究竟该如何对合作伙伴做统一的管理和支持呢？
　　首先，建立一个整体的视图，在这个视图下双方再不断地去磨合。
　　图片源自于microsoft，已授权
　　根据这个生态合作伙伴框架，我们来尝试着逐点分析下。
　　01合作伙伴管理政策
　　首先需要考虑的是合作伙伴是否合规、合法，公司政策、数据保护合法，再根据客户所处行业判断合作伙伴能给客户带来的价值。在商业领域，业界通用的合作伙伴有四种商业类型：
　　策略性：strategic
　　战略性：tactical
　　实操性：operational
　　通用性：common
　　根据合作伙伴能给客户带来的价值和交付客户时的影响力两方面来评估合作伙伴的类型，如下图所示：
　　根据客户所处的行业类别、合作伙伴在该行业的建树等，分别布局不同级别和类型的合作伙伴，确保资源池的健康流动。同时，为了确保合作伙伴清单的建立，可以提前根据不同类型的合作伙伴拟定对应的合作伙伴框架协议。
　　02合作伙伴分级分类与评选采纳
　　明确好预期的合作伙伴级别和类型，接下来正式进入合作伙伴引入流程。我们需要制定合作伙伴从引荐、到申请、审核、评估、培训、考核、认证等一系列的规则。只有通过这个引入流程的合作伙伴方可进入资源池。
　　那么常见的引入标准有哪些呢？
　　常见的有以下四个方面：
　　公司的企业资质：公司规模、年营业额、成立年限、优势行业等；
　　通用技术能力认证：项目经理认证、开发、运维相关的认证；
　　近几年本行业方向项目经验：项目商机、项目规模、项目数量等，并提供相关项目案例合同关键页的扫描件和案例介绍材料；
　　其他要求：客服中心、传统IT认证、软件研发资质等。
　　03合作伙伴能力培训与认证
　　合作伙伴引入后，开始对该公司的人员进行能力培训和考核认证。定义好角色模型、人员的资质要求和岗位职责，再正式发起培训邀请。培训形式可以是线下定期的大型授课，或是线上视频点对点分发等。
　　培训的内容以授课为主，实操为辅，加之统一的考核安排，确保学员可以深入地掌握服务实施的本领。
　　而当培训结束后，及时的考核结果反馈、认证证书定制、培训教材发放、合作伙伴问题解惑也是非常有必要的。
　　注意：培训不仅利于合作伙伴在本产品服务和解决方案上的能力提升，便于后续在实际参与客户项目时尽可能独挡一面，更是建立我们与合作伙伴友睦关系的基石，是双方尽早进入productivezone的推手。
　　04合同与服务协同管理
　　前文我们谈到了合作伙伴的引入和能力培养、人员认证，这些热身活动终究还是需要在项目实践中过过招。
　　在此分为三个阶段来看：
　　1。项目启动前
　　诚然，在动员别人和你一起做事前，双方必不可少的就是约法三章，而约定落在两家商业机构之间则需要合同来约束。而常见的商业合作模式无非两种：直销和经销。
　　不论是哪种销售模式，在乙方与客户签主合同前，都需要优先制定支持合同（UnderpinningContract（UC））。
　　《ITIL》对UC是这么定义的：
　　支持合同，即UnderpinningContract（UC），是IT服务提供方和第三方厂商签订的合同。第三方提供支持服务以便服务提供方更好地交付服务给客户。
　　UC需要遵从以下三点原则：
　　backtoback，即付款、交付、质量都需要背靠背；
　　合同必须经过法务审核确认；
　　统一按照UC模板来编写，包括与法律相关、与项目交付相关。
　　然而对于有些项目而言，先交付再谈钱几乎已是常态，几乎无法完全保障公司与合作伙伴之间的付款背靠背。即便如此，UC依旧需要先签署，付款与否可以根据实际情况灵活处理。
　　2。项目交付阶段
　　明确好合作模式，双方也签署好UC后，此时对项目交付过程中双方的服务协同管理成了重头戏。
　　从大的维度来看，项目交付主要涉及到工程实施、服务咨询、客户培训等。
　　工程实施：标准部署、客户端打包、测试验收、功能开发、应用定制、数据配置哪些模块由合作伙伴主导？哪些模块由合作伙伴配合？主导的模块里哪些环节需要我们提供什么服务支持？哪些内容需要我们提前配备对应的文档资料？
　　服务咨询：客户有问题找谁？一线二线三线的技术支持分别能支持到什么程度？客户需求谁来归纳汇总？
　　客户培训：谁来给客户做产品和技术培训？培训的周期谁来定？
　　项目交付阶段的人员组成复杂，踢皮球容易，追责难；一窝蜂扑上去容易，灭火难。因此，在项目交付前，甚至在合同签署前，我们都要尽快定义项目规划书，明确产品服务目录和WBS，细化与合作伙伴的权责边界、角色分工、响应级别、变更事件处理等，并做好服务级别管理（SLM，ServiceLevelManagement），确保服务得到持续的维护和改进。
　　SLM，即对服务的提供进行协商、定义、评价、管理以及以可接受的成本改进IT服务的质量流程，包括对下列三个协议的设计、协商和维护：
　　服务级别协议（SLA）：乙方与甲方签订的服务协议；
　　运营级别协议（OLA）：由服务团队和其他业务部门根据服务目录签订的协议，支持服务团队对外提供的各种服务；
　　支持合同（UC）：前文已提到，与合作伙伴就某项服务的提供所签订的合同。
　　合作伙伴在前方冲锋陷阵时，最重要的是要保证定期的战况同步和对大盘的掌控，持续供应必要的军粮和弹药，即便发生意外也要稳中求胜，有对应的作战变更策略，对问题进行升级并提前预判风险，最终方能占领高地。
　　对应到项目交付过程中，有三点主原则需要关注：
　　定期项目同步项目回顾；
　　布局变更管理流程（CAB）；
　　项目风险和突发事件的升级。
　　3。项目结案阶段
　　当项目进入尾声，正是激情褪去人心涣散的时刻。此时除了严防死守客户提合同以外的需求，合作伙伴这边的动静仍需多关注。也许他会将主要精力放到别的项目上，造成客户不满、投诉上报、合同尾款迟迟没打过来什么情况都有可能发生。
　　走完长征的最后一步才算是到达了目的地，因此我们要持续驱动合作伙伴同步项目进展和项目风险，做好项目总结和归档，再针对该项目对合作伙伴做整体的绩效回顾，并通过该项目的经验沉淀持续提升产品服务和商业方案，作为下一次项目的改善计划。
　　而这些目标均可通过日常接洽客户和合作伙伴的点滴中去梳理对应的流程来实现：
　　量化合作伙伴资源的投入，持续完善定价策略；
　　定义项目验收标准；
　　提供标准的项目实施总结模板；
　　合作伙伴考核评估标准；
　　定义持续服务改善机制（CSI），确保可追溯到某个关卡点去改善。
　　05合作伙伴考核评估与持续提升
　　前文提到，在引入合作伙伴进入资源池后，可以率先对合作伙伴进行培训和考核，以确保通过认证的人员向客户提供服务。而每次项目都是一块试金石，合作伙伴每参与一次项目，都需要对其进行考核。
　　考核的维度可以是：
　　资源投入度；
　　流程规范性；
　　客户满意度；
　　质量安全事件；
　　能力建设。
　　06合作伙伴资源池管理
　　从合作伙伴的评选、采纳、分类，到培训、考核、认证，再到经过项目历练、绩效考核、能力提升，合作伙伴从接入期到成长期再到最终成熟，这是一个穿针引线的过程。
　　在这个过程中公司也将沉淀一个流动的资源池，与合作伙伴构建了一个良性、可持续发展的合作关系，推动合作伙伴与公司步入productivezone。
　　总结
　　当产业结构发生非连续的变化、跨界融合成为主旋律时，生态发展和互生共赢显得更为重要。做toB服务，有效管理合作伙伴，与合作伙伴齐头并进非常关键。
　　从项目过程中的每个问题“点”，看到一个“体”，去把握生态合作伙伴的管理框架体系，结合销售生命全周期布局的服务流程和知识管理体系，用更集中优化的资源来支持更广泛的前线合作伙伴。让我们的产品服务和商业方案逐渐发挥杠杆特性，撬动更多业内优秀的同盟，博取更多金主的青睐。
　　共勉之。
　　参考文献：
　　刘小茵。基于ISOIEC20000的IT服务管理体系实践指南第二版〔M〕。中国标准出版社，2017年：86。
　　哈佛商业评论〔J〕，2016年
　　刘通，梁敏，梁娅，王前。ITIL2011服务管理与案例资产详解〔M〕。哈尔滨工业大学出版社，2014年