英语原文共 37 页，剩余内容已隐藏，支付完成后下载完整资料

平台治理作为生态系统协调的蓝图

如果传统组织的隐喻是军队，那么平台生态系统的比喻就是交响乐。 平台所有者就像指挥家一样，应用开发者就像音乐家一样。 每位音乐家贡献整体乐谱的独特部分。 指挥帮助不同的音乐家同步他们自己的贡献，以帮助确保他们集体表现的整体一致性。 指挥不直接，而是协调。 个别音乐家选择遵循指挥的领导，他们对所有为表演做出贡献的音乐家都具有有限的直接权限或专业音乐才能的深度。 每个音乐家都能够独立发挥自己的作用，但与其他人同步发挥出色的表现。

就像在交响乐中一样，协调而不是控制应该成为平台生态系统治理的焦点。 指挥和控制结构在传统组织中运作良好，因为管理人员对雇员的合法等级权力被双方接受为雇佣条件。 但是，平台生态系统中不存在这样的直接权限。 应用开发者不是平台所有者的雇员; 相反，他们通常是自由人，他们通常专注于平台所有者之外的利基领域。 需要基于绩效的奖励而不是惩罚性的惩罚。 因此，平台所有者进行善政的目标必须是塑造和影响其生态系统，而不是指导它（Williamson和De Meyer，2012）。

治理就是尊重应用程序开发人员的自主权，同时也能够将各种贡献融合到一个和谐的整体中。 这是平台编排的本质。 因此编配需要影响平台所有者无法控制的人。 因此，治理的关键功能是提供一种环境，由应用程序开发人员推动的分布式创新可以围绕平台出现。

平台管理是平台协调的第二步。 虽然架构可以降低结构复杂性，但治理可以降低行为复杂性。 平台治理很重要，因为它决定了模块化平台架构是否能够实现创新可分性（Boudreau，2010; Rochet和Tirole，2003; Tiwana等，2010）。 平台生态系统的治理广泛地指平台所有者对参与平台生态系统的应用开发者施加影响的机制（Schilling，2005，第159）。 治理因此从管理的平台所有者流向由平台所有者管理的应用开发者。本章为理解平台治理提供了基础，从其目的和重要性开始。 然后解释了平台治理的三个维度。 首先是平台和应用程序决策的权限和责任如何在应用程序开发人员和平台所有者（决策权）之间分配。 第二个包括平台所有者可以混合搭配的四种机制，以确保目标与应用开发者的融合和协调：关守，指标，流程控制和关系控制。 第三个维度是五个平台定价政策。 然后解释了为什么治理与平台架构不可分离，为什么要实现模块化平台架构的潜力需要调整它们。 它最终解释了治理决策权，控制权和定价三个维度如何与平台的架构，业务模型和生命周期阶段相一致。 镜像原则为调整生态系统中的决策权提供了强大的机制。 但是它也留下了一些必须被平台控制机制所堵塞的漏洞。 追求五个简单的规则可以帮助设计一个有效但简约的平台控制系统：简单，透明，现实，基于价值和公平。

平台与应用决策权

思考平台生态系统中的每个单独决策可能会迅速转变为压倒性的无意义的练习。 因此，有必要将广泛的决策权概念缩减为一个更易于理解和成立的子集或决策类别。 在平台生态系统中，有四套广泛的决策权。 第一个区别是决策权是否属于平台或平台的应用程序。 平台决策权是指平台所有者或应用程序开发人员是否有权直接作出有关平台的决策。 同样，应用程序决策权是指平台所有者或应用程序开发人员是否有权直接作出有关应用程序的决策。 乍看之下，您可能会得出结论：平台所有者和应用程序开发人员的应用程序决定自然会做出平台决策。 但这是一个误导性的过度简化，原因有四。

选择，而不是给定的。 这意味着平台和应用程序决策权并不一定与平台所有者和应用程序开发人员进行1：1映射，因为图6.4中的简单表示会导致人们得出结论。 相反，我们必须根据他们的分权程度来考虑他们。 例如，应用程序决策可以在一个平台上分散到更大程度，而在另一个平台上分散。 这意味着他们通常在应用程序开发人员和平台所有者之间不同程度上共享; 问题是关于他们分享的程度。 因此，我们将这种分享称为决策权的分割。 其次，它们的集权程度甚至略有不同。权力下放可以将两个类似的平台放在实质上不同的演化轨迹上。 平台和应用程序决策分散程度的这种微小差异可以放大或忽略平台所有者和应用程序开发人员所做的架构选择的好处。 换句话说，他们与平台级别和应用程序级别的体系结构具有强大的交互和依赖关系。 一种能够在一种架构下实现应用程序开发人员之间的高效专业化的决策权安排可能成为其另一个下的致命弱点。 因此，决策权的划分必须与平台的体系结构和应用程序的微体系结构保持一致。 第四，双方之间的决策权划分有分配者和受让人。 如果受让人不能（或不能）接受这些类型的决定的责任，那么给予受让人决策权的分配可能意义不大。

两类决策权：战略和实施

一个或多个平台的决策权可以大致分为两大类：战略和实施。 战略决策权与一方（应用开发者或平台所有者）应该完成什么以及实施决定是关于应该如何实现它有关。 因此，战略决策权是方向设定，以规范为导向的决策。 实施决策是技术执行决策，涉及软件子系统的功能，功能，设计，用户界面和实施细节的选择。 这两类决策权适用于平台和应用程序。 因此，平台战略决策权代表了指定平台必须完成什么的权限和责任，平台实施决策权代表平台如何实际实现这些目标。 同样，应用程序战略决策权代表指定应用程序必须完成什么的权限和责任，应用程序实施决策权代表应用程序如何实际实现这些目标。 应用程序决策权的划分可能因应用程序而异，同一平台可以针对不同的应用程序使用不同的应用程序决策权划分组合。 同样，同一平台上的多个应用程序的应用程序开发人员可能会在同一平台上看到用于各种应用程序的不同决策权限结构。 而在多个平台上使用相同应用的多宿主应用开发人员可能会在不同平台上遇到该应用的不同决策权限结构。

控制组合设计

平台治理的第二个方面是控制。 控制是指平台所有者确保应用程序开发人员的工作与平台最佳利益相一致的方式。 平台所有者通过使用各种控制机制的应用程序开发人员实施控制。 因此，控制机制是平台所有者用来实施和执行奖励理想行为，惩罚不良行为以及颁布应用程序开发人员行为标准的规则的工具（Evans and Schmalensee，2007）。 控制机制可以是正式的或非正式的。 可以一起使用几种这样的机制，并且这种控制机制的组合表示平台所有者通过应用开发者使用的控制组合。 同一平台上的不同应用程序可以 - 但不一定 - 具有不同结构的控制组合。

平台所有者可以使用三种正式的控制机制和一种非正式的控制机制。 所有正式的控制机制都集中在强加一个平台所有者希望应用程序开发者期望的会议规则和标准（Evans and Schmalensee，2007，p。22）。 正式的控制机制包括通过看门控制，过程控制和使用度量控制。 除了这些形式化机制之外，还可以使用一种非正式的控制机制，即关系控制。 表6.1总结了这些控制机制。 每个控制机制也有使用它的先决条件，也在表中进行了总结。

守门

第一个正式控制是通过看门。 网守代表平台所有者使用预定义的客观接受标准来判断应用和应用开发者被允许进入平台生态系统的程度。 平台所有者设定了这个标准，不仅限于允许的内容，还允许谁允许进入。这种正式控制也被称为输入控制（Cardinal，2001），就像组织选择哪个候选人从一个池中雇用员工一样的申请人。 在平台中，这需要应用程序开发人员将应用程序提交给平台所有者进行评估，以包含在平台的生态系统中。

例如，在其iOS平台中大量使用门卫作为控制机制。 但是，通过关守的控制必须满足三个重要要求才行。 首先，平台所有者必须有足够的能力来判断应用程序开发人员的提交。 其次，平台所有者必须能够公平和迅速地做到这一点。 第三，应用程序开发人员必须愿意接受这种关注。 如果平台所有者在判断对平台的投入时没有被认为是客观，公平和快速的，那么它会让应用程序开发人员面临相当大的风险和不确定性，因为他们已经投入完成平台特定的工作。 如果不小心部署，它可能会阻止应用程序开发人员致力于开发平台。

过程控制

第二种控制形式是过程控制，它指的是平台所有者根据其遵循规定的开发方法，规则和程序的程度来对应用程序开发人员进行奖励或惩罚的程度，它认为这将导致从平台所有者的视角。 平台中的这些令人满意的结果指的是可以与平台良好互操作的应用程序，而不是它们是否在市场上表现良好。 这些规则和程序由平台所有者规定，然后由平台所有者评估各个应用程序开发人员跟踪他们的程度。 对预先规定的流程的合规性将得到奖励，不合规则将受到惩罚。 这些过程必须事先定义，并且应用程序开发人员知道过程控制是可行的。 在许多软件平台中，平台所有者向应用程序开发人员提供的平台开发和测试工具，仿真环境和开发人员工具包是平台所有者试图实施过程控制的机制。 但是，过程控制有两个重要的要求是可行的。 首先，应用程序开发者的行为应该由平台所有者观察和监控。 这种行为可观察性不一定是直接的，可以通过电子审计跟踪和开发者日志。 其次，过程控制背后的主张是，如果应用程序开发人员遵循平台所有者规定的流程而不是留在他们的设备上，那么他们生产技术性能更好的应用程序的可能性就会更高。 平台所有者必须充分理解或更好地理解应用程序开发人员的工作，以便规定确实可以提高其工作成功可能性的流程（特别是应用程序与平台的集成）。

度量

第三种正式的控制机制是通过使用度量标准。 这种形式控制指的是平台所有者根据其工作成果达到预定目标性能指标的程度来奖励或惩罚应用开发者的程度。 研究人员称这种输出控制是因为它评估了应用程序开发人员的工作输出（Ouchi，1979）。 对度量驱动控制的要求是，这些度量必须是：（1）由平台所有者预先指定，（2）客观可测量。 应用程序开发人员完成的工作达到目标的程度决定了平台所有者对应用程序开发人员施加的奖励或惩罚。 基于指标的控制来自传统软件开发的传统世界，其中内部经理或客户可以向内部IT部门或外部供应商指定目标标准，如预算，项目进度和可接受的缺陷级别。 然而，如果平台所有者没有或不能预先确定目标度量标准，例如开发预算或期望应用开发人员满足的时间表，那么这些度量标准意义不大。

在平台上，残酷市场中的应用程序的性能和生存率作为一个强大的指标，消除了对基于度量标准的控制的需求（Armstrong，2006; Bester和Krauml;hmer，2008）。 在许多当代平台中，基于度量的控制因此很少使用

因为最终用户市场奖励高质量的产品，销售旺盛，并且由于销售不佳而导致低质量产量。 换句话说，市场竞争的使用可以取代使用度量的控制。 平台中一些较弱的应用程序级度量的示例可能包括性能，内存利用率和操作级别的速度。 它们还可以包含以市场为导向的指标，如单位销售量，下载量和最终用户评分。 使用诸如这些市场导向的指标也与治理的第三维息息相关：平台所有者使用定价结构来分配应用程序开发者的收益。 因此，面向市场的指标的唯一目的就是衡量实施收入分配协议的程度。

关系控制

第四种也是唯一非正式的控制形式是关系控制。 这种控制机制是指平台所有者依赖其与应用程序开发人员共同影响其行为的规范和价值的程度。 因此，这种控制机制依赖于平台所有者为平台生态系统提供总体集体目标; 这种共享标识定义了平台生态系统的特征，并通过将其自己的目标与平台的目标相协调来聚拢应用程序开发人员。 这样的系统级目标设定为发展平台生态系统创造了一个轨道，并且在不对应用程序开发人员进行微型管理的情况下创造出一致性（Meadows，2008，第165页）。 因此，共享文化，相似价值观和共享规范提供了一个共同点，可以使平台所有者的目标与应用程序开发人员的工作保持一致。 研究人员称这种氏族控制是因为它依赖于氏族行为（Kirsch，1997; Ouchi，1980）。 关系控制广泛用于各种Linux平台开发社区等开源平台。 关系控制的好处在于它通常是成本最低的控制形式之一，因为它只需要平台所有者很少的执行和努力。 但是，应用程序开发人员社区中先前存在的共享规范和价值是关系控制可行的重要先决条件。 如果应用程序开发人员与该平台没有长期的合作关系，则通常不会满足此要求。 在持续涌入加入该平台的新应用开发者的平台上，但与现有开发人员没有相同的共享历史，专业价值和规范的平台中，这也不太可能得到满足。 高应用程序开发人员流失因此降低了关系控制的可行性。 因此，关系控制本身很少足够，尽管它可以很好地补充其他正式的控制机制。 这四种控制机制在平台级别的组合描述了一个控制组合。

决定1：对称还是非对称定价？

回想一下，平台至少有两个方面：应用程序开发人员和最终用户。 平台所有者必须做出的第一个定价决定是你是否一边赚钱，另一边是不对称（非对称定价）还是双方都赚钱（对称定价）。 这些选择如图6.10所示。 如果平台所有者选择只在一方赚钱，那么通常需要零价格，甚至是另一方面的负价格。 例如，有些平台从终端用户那里赚钱，但为应用程序开发人员提供资助。 通常，平台所有者通过提供工具，硬件和其他昂贵的激励措施，导致他们一方面损失，甚至超过补贴。 平台的补贴方通常可以弥补另一方利润增加形式的损失。 例如，亚马逊Kindle和游戏控制台开发商（例如任天堂，索尼Playstation和微软Xbox）对终端用户提供补贴。 相比之下，苹果，谷歌和黑莓等移动计算平台所有者对应用开发者提供补贴。 在传统业务中，这被认为是不合理的，是商业模式崩溃的秘诀。 但是，在平台市场上，战略上补贴一方可以弥补另一方的损失。 为平台定价做出长期盈利决策很重要，这可能与短期盈利能力不一致。 这是一个棘手的战略决策，直接与平台生命周期的阶段，网络效应的关键性以及平台即时市场中的竞争动态直接相关，我们将在本章后面讨论。

决定2：补贴哪一方以及多长时间

第二个定价决策平台的所有者必须作出哪一方面的补贴（如果有的话）和多长时间。 例如，平台所有者可能为了吸引对方而支付一方的费用。 然而，无担保方应始终是赚钱方。 如果一方补贴另一方，平台所有者也必须决定该补贴应持续多久。 突然尝试结束补贴方面的补贴可能是具有挑战性的，必须提前

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[23871]，资料为PDF文档或Word文档，PDF文档可免费转换为Word