这篇文章上次修改于 190 天前，可能其部分内容已经发生变化，如有疑问可询问作者。 ###Chapter 15 Focus on Core Competencies: Build Versus Buy 第 15 章 聚焦核心能力：自建与购买 Thus far, we’ve made the case that if you are truly undergoing hyper growth and needto scale indefinitely, you need to take charge of your architecture; relying on third-party solutions alone is a recipe for disaster. This is not to say that third-party solu-tions are evil; in fact, we believe just the opposite. The point we make in this chapteris that you should absolutely purchase software and systems where you are not thebest qualified to build such software and systems, but you should not rely upon themas the means for your scalability. In the extreme case, you cannot possibly subjectyour shareholders to restricting the growth of your business until after the nextrelease of some partner’s software or hardware. In past chapters, we have offeredsuggestions on how to make the business case for scalability initiatives (Chapter 6,Making the Business Case) and to measure and increase your productivity to allowfor scalability initiatives (Chapter 5, Management 101). We also added, as one of oursuggested architectural principles, Buying When Non Core. Although we did not spe-cifically indicate Buying When Non Core as a scalability principle, your build andpurchase will absolutely have an indirect impact on your scalability. In this chapter,we are going to discuss when you should build and when you should buy systems andsoftware. Although the concepts apply to all of your decisions within technology, weare going to put a special emphasis on scalability. 到目前为止，我们已经证明，如果您确实正在经历高速增长并且需要无限期扩展，那么您需要负责您的架构；仅仅依赖第三方解决方案会导致灾难。这并不是说第三方解决方案是邪恶的；而是说第三方解决方案是邪恶的。事实上，我们的看法恰恰相反。我们在本章中提出的观点是，您绝对应该购买您不具备构建此类软件和系统的最佳资格的软件和系统，但您不应该依赖它们来实现可扩展性。在极端情况下，在某些合作伙伴的软件或硬件下一次发布之前，您不可能让股东限制您的业务增长。在过去的章节中，我们提供了有关如何为可扩展性计划制定业务案例（第 6 章，制定业务案例）以及如何衡量和提高生产力以实现可扩展性计划（第 5 章，管理 101）的建议。我们还添加了“非核心时购买”作为我们建议的架构原则之一。尽管我们没有具体指出“非核心时购买”作为可扩展性原则，但您的构建和购买绝对会对您的可扩展性产生间接影响。在本章中，我们将讨论何时应该构建以及何时应该购买系统和软件。尽管这些概念适用于您在技术方面的所有决策，但我们将特别强调可扩展性。 ####Building Versus Buying, and Scalability 构建与购买以及可扩展性 As a rule, when you decide to build something that is commercially available, it hastwo impacts to your organization and your company. The first is that the item youbuild typically ends up costing more after you factor in engineering time to supportand maintain the system that you’ve built. The second, and in many cases moreimportant, point is that you have finite development resources and anything youbuild uses some of that development capacity. Obviously, if you were to build every-thing from your computers to your operating systems and databases, you would findyourself with little to no capacity remaining to work on the application that makesyour company money. 通常，当您决定构建可商用的产品时，它会对您的组织和公司产生双重影响。首先，在考虑到支持和维护所构建的系统的工程时间后，您构建的项目通常最终会花费更多。第二点（在许多情况下更重要）是，您的开发资源是有限的，而您构建的任何东西都需要使用其中的一些开发能力。显然，如果您要构建从计算机到操作系统和数据库的所有内容，您会发现自己几乎没有能力开发为公司赚钱的应用程序。 How does this impact scalability? The more time that you spend architecting andimplementing supportive components of your site the less time you have in architectingand implementing an overall architecture that allows the entire platform, product, orsystem to scale. As we will discuss in Chapter 20, Designing for Any Technology, build-ing scalable architectures is about architecting solutions that grow horizontally as userdemand increases for any given system or service. When architectures are built to scalehorizontally and agnostically, the question of whether to build or buy something becomesone of competitive differentiation and cost rather than religion and capabilities. 这对可扩展性有何影响？您花在构建和实现站点的支持组件上的时间越多，用于构建和实现允许整个平台、产品或系统扩展的整体架构的时间就越少。正如我们将在第 20 章“为任何技术进行设计”中讨论的那样，构建可扩展架构就是构建随着任何给定系统或服务的用户需求增加而水平增长的解决方案。当构建水平且不可知的架构时，是否构建或购买某些东西的问题就变成了竞争差异化和成本的问题，而不是宗教和能力的问题。 When you have created an agnostic architecture, you further reduce the value andminimize the returns associated with dedicating internal and expensive resources toany piece of your architecture. Building a database now has very low shareholdervalue as compared to the alternative of using several commodity databases. Needmore database power? Design your application to make use of any number of data-bases rather than spending incredible amounts of time developing your own superfast database. Need encryption capabilities? Determine the additional value of yourencryption software versus the next best solution available to the public. 当您创建了一个不可知的架构时，您可以进一步降低价值，并最大限度地减少与将内部和昂贵的资源专用于架构的任何部分相关的回报。与使用多个商品数据库的替代方案相比，现在构建数据库的股东价值非常低。需要更多数据库功能？设计您的应用程序以利用任意数量的数据库，而不是花费大量时间开发您自己的超高速数据库。需要加密功能吗？确定您的加密软件与公众可用的下一个最佳解决方案的附加价值。 Any time you can buy something rather than build it, you free up engineeringresources that can be applied to business projects and projects focused on allowingyour platform to scale. You don’t have an infinite number of resources, so why wouldyou ever want to focus them on things that do not create shareholder value? 任何时候您可以购买而不是构建它，您就可以释放可应用于业务项目和专注于让您的平台扩展的项目的工程资源。你没有无限的资源，那么你为什么要把它们集中在那些不能创造股东价值的事情上呢？ You may recall from past education or even some of our discussions within thisbook that shareholder value is most closely associated with the profits of the com-pany. Rising profits often result in changes to dividends, increases in stock prices, orboth. Profits, in turn, are a direct result of revenues minus costs. As such, we aregoing to focus our build versus buy discussions along the paths of decreasing costand increasing revenue through focusing on strategy and competitive differentiation. ####Focusing on Cost 您可能还记得过去的教育，甚至我们在本书中的一些讨论，股东价值与公司利润密切相关。利润的增加通常会导致股息的变化、股价的上涨，或者两者兼而有之。反过来，利润是收入减去成本的直接结果。因此，我们将通过关注战略和竞争差异化，将构建与购买的讨论重点放在降低成本和增加收入的路径上。 ####关注成本 Cost focused approaches center on lowering the total cost to the company for anybuild versus buy analysis. These approaches range from a straight analysis of totalcapital employed over time to a discounted cash flow analysis that factors in the costof capital over time. Your finance department likely has a preferred method for helpingto decide how to determine the lowest cost approach of any number of approaches. 以成本为中心的方法的重点是降低公司进行任何构建与购买分析的总成本。这些方法的范围从对一段时间内所使用的总资本的直接分析到考虑一段时间内资本成本的贴现现金流分析。您的财务部门可能有一种首选方法来帮助决定如何确定多种方法中成本最低的方法。 Our experience in this area is that most technology organizations have a biastoward building components. This bias most often shows up in an incorrect orincomplete analysis showing that building a certain system is actually less expensiveto a company than purchasing the same component. The most common mistakes inthis analysis are an underestimation of the initial cost of building the component, andmissing or underestimating future costs of maintenance and support. It is not uncom-mon for a company to underestimate the cost of support by an order of magnitude asit does not have the history or DNA to know how to truly develop or support criticalinfrastructure on a 24u7 basis. 我们在这一领域的经验是，大多数技术组织都偏向于构建组件。这种偏见最常出现在不正确或不完整的分析中，表明对公司来说构建某个系统实际上比购买相同的组件更便宜。此分析中最常见的错误是低估了构建组件的初始成本，以及遗漏或低估了未来的维护和支持成本。一家公司低估支持成本一个数量级的情况并不少见，因为它没有历史或DNA来知道如何真正在24小时7天的基础上开发或支持关键基础设施。 If you adopt a cost focused strategy to determine build versus buy of any system, agood way to test whether your strategy is working is to evaluate how often the processresults in a build decision. Your decision process is probably spot on if nearly all deci-sions result in a buy decision. The exception to this rule is in the areas where your com-pany produces the product in question. Obviously, you are in business to make moneyand to make money you must produce something or provide a service to someone. 如果您采用以成本为中心的策略来确定构建还是购买任何系统，测试您的策略是否有效的一个好方法是评估该过程产生构建决策的频率。如果几乎所有决定都导致购买决定，那么您的决策过程可能是正确的。此规则的例外是在您的公司生产相关产品的地区。显然，你做生意是为了赚钱，而为了赚钱，你必须生产一些东西或为某人提供服务。 A major weakness of cost focused strategies is that they do not focus on strategicalignment or competitive differentiation. The focus is purely to reduce or limit thecost incurred by the company for anything that is needed from a technology perspec-tive. Very often, this strategy is employed by groups implementing back office infor-mation technology systems. Focusing on cost alone though can lead to decisions tobuild something when a commercial off the shelf (COTS) or vendor provided systemwill be more than adequate. 以成本为中心的战略的一个主要弱点是它们不注重战略调整或竞争差异化。重点纯粹是为了减少或限制公司因技术角度所需的任何事情而产生的成本。通常，实施后台信息技术系统的团队会采用这种策略。然而，当商业现成 (COTS) 或供应商提供的系统绰绰有余时，仅关注成本可能会导致决定构建某些东西。 ####Focusing on Strategy 聚焦战略 Strategy focused approaches look at build versus buy from a perspective of alignmentto the vision, mission, supporting strategy, and goals of the company. In most cases,there is a two-part question involved with the strategy focused approach: 以战略为中心的方法从与公司愿景、使命、支持战略和目标保持一致的角度来看待构建与购买。在大多数情况下，有一个由两部分组成的问题涉及以策略为中心的方法 * Are we the best or among the best (top two or three) providers or builders of thetechnology in question? * 我们是相关技术的最佳或最佳（前二名或前三名）提供商或建设者吗？ * Does building or providing the technology in question provide sustainable com-petitive differentiation? * 构建或提供相关技术是否可以提供可持续的竞争优势？ To be able to answer the first question, you need to be convinced that you have theright and best talent to be the best at what you are doing. Unfortunately, here again,we find that too many technology organizations believe that they are the best at pro-viding, well, you name it! Counter to the way some parents have decided to raisetheir children, not everyone can be the best, not everyone deserves a trophy, and noteveryone deserves to feel good about their accomplishments. In the real world, thereare only two or three providers of anything with the claim of being the best or at leastin the top two to three. Given the number of candidates out there for nearly any service,unless you are the first provider of some service, the chances are slim that your teamreally is the best. It can be good, but it probably is not the best. Your team is defi-nitely not the best if you haven’t been applying the management principles of “seed,feed, and weed” from Chapter 5. 为了能够回答第一个问题，您需要确信自己拥有合适且最优秀的才能，能够在您所做的事情上做到最好。不幸的是，我们再次发现太多的技术组织认为他们最擅长提供，嗯，你能想到的！与一些父母决定抚养孩子的方式相反，不是每个人都能成为最好的，不是每个人都应该获得奖杯，也不是每个人都应该对自己的成就感到满意。在现实世界中，只有两三个供应商声称自己是最好的，或者至少是前两到三名。考虑到几乎所有服务的候选人数量，除非您是某些服务的第一个提供者，否则您的团队真正是最好的的机会很小。它可能很好，但可能不是最好的。如果你没有应用第五章中的“种子、饲料和杂草”管理原则，你的团队绝对不是最好的。 #####Being the Best 成为最好的 The only people unbiased enough to really make a determination of whether you can be thebest provider of anything are those that start from the position of belief that you are not the bestprovider. No one gets to be the best at anything without proving it, and proving it requires atleast some work toward the achievement of a goal. Stating something emphatically is not proofenough of anything but your belief. Against whom or what are you comparing yourself or yourteam? Just because this is the best group of people you have ever worked with does not justifythe title. What are the metrics and measurements that you are using? 唯一能够足够公正地真正确定您是否可以成为最好的提供者的人是那些从相信您不是最好的提供者的立场出发的人。如果没有证明的话，没有人能在任何事情上做到最好，而证明这一点至少需要为实现目标而付出一些努力。强调某件事并不能证明任何事情，只能证明你的信念。您将自己或您的团队与谁或什么进行比较？仅仅因为这是您共事过的最好的一群人并不能证明这个头衔是合理的。您使用的指标和衡量标准是什么？ And being the best does not necessarily mean having the best technology. You have to winthe entire game, from technology to marketing to partnerships that will make you successful.Beta was arguably a better technology than VHS, yet it still lost. Apple’s Macintosh had a moreintuitive interface than the PC, yet the PC won based on the ecosystem of providers and toolsavailable for it. 成为最好的并不一定意味着拥有最好的技术。你必须赢得整个游戏，从技术到营销再到合作伙伴关系，这将使你成功。Beta 可以说是比 VHS 更好的技术，但它仍然失败了。苹果的 Macintosh 拥有比 PC 更直观的界面，但 PC 的胜利是基于其可用的提供商和工具的生态系统。 To be able to answer the second question, you really need to be able to explain how,by building the system in question, you are raising switching costs, lowering barriersto exit, increasing barriers to entry, and the like. How is it that you are making itharder for your competitors to compete against you? How does this help you to winnew clients, keep existing clients, and operate more cost effectively than any of yourcompetitors? What keeps them from copying what you are doing in very short order? 为了能够回答第二个问题，您确实需要能够解释通过构建相关系统，您如何提高转换成本、降低退出壁垒、增加进入壁垒等。你是如何让你的竞争对手更难与你竞争的？这如何帮助您赢得新客户、留住现有客户并比任何竞争对手更有效地运营？是什么阻止他们在很短的时间内复制你正在做的事情？ ####“Not Built Here” Phenomenon “不建在这里”现象 If we seem a little negative in this chapter, it is because we are. We see a lot of valuedestroyed in a lot of companies from executives and technology teams deciding thatthey should build something based on incorrect information or biased approaches.We very often find ourselves in discussions on why a company absolutely has to buildthis or that, when the thing being discussed has absolutely nothing to do with howthey make money. We’ve used the examples of databases and encryption methodolo-gies and we weren’t talking about the use of open source databases (we completelysupport the use of those). In our consulting practice at AKF Partners, we’ve had cli-ents running commerce sites who built their own databases from the ground up!We’ve also seen proprietary load balancers, entity and object caches, heavily modi-fied and sometimes nearly entirely proprietary operating systems, and so on. Mostoften, the argument is “we can build it better and we need something better, so webuilt it” followed closely by “it was cheaper for us to build it than to buy it.” 如果我们在本章中看起来有点消极，那是因为我们确实如此。我们看到许多公司的高管和技术团队决定他们应该基于不正确的信息或有偏见的方法来构建某些东西，从而破坏了很多价值。我们经常发现自己在讨论为什么公司绝对必须构建这个或那个，当事情发生时所讨论的与他们如何赚钱完全无关。我们已经使用了数据库和加密方法的示例，但我们没有讨论开源数据库的使用（我们完全支持使用这些数据库）。在 AKF Partners 的咨询实践中，我们的客户运行商业网站，他们从头开始构建自己的数据库！我们还看到了专有的负载均衡器、实体和对象缓存，它们经过大量修改，有时几乎完全修改专有操作系统等。大多数情况下，争论的焦点是“我们可以建造得更好，我们需要更好的东西，所以我们建造了它”，紧接着是“我们建造它比购买它更便宜。 We call this the “Not Built Here” phenomenon and not only is it dangerous fromthe perspective of scalability, it is crippling from a shareholder perspective. Whenapplied to very small things that take only a portion of your development capacity, itis just an annoyance. When applied to critical infrastructure, it very often becomesthe source of the company’s scalability crisis. Too much time is spent managing theproprietary system that provides “incredible shareholder value” and too little makingand creating business functionality and working to really scale the platform. 我们称之为“不在这里建造”的现象，它不仅从可扩展性的角度来看是危险的，从股东的角度来看也是有害的。当应用于只占用你一部分开发能力的非常小的事情时，它只是一种烦恼。当应用于关键基础设施时，它常常成为公司可扩展性危机的根源。太多的时间花在管理提供“令人难以置信的股东价值”的专有系统上，而花在制作和创建业务功能以及真正扩展平台上的时间太少。 To clarify this point, let’s take a well known real-world example like eBay. If eBayhad a culture that eschewed the use of third-party or COTS products, it might focuson building critical pieces of its software infrastructure such as application servers.Application servers are a commodity and can typically be acquired and implementedat very little cost. Assuming that eBay spends 6% to 8% of its revenue on buildingapplications critical to the buying and selling experience, a portion of that 6% to 8%will now be spent building and maintaining its proprietary application server. Thismeans that either less new product functionality will be created for that 6% to 8% orit will need to spend more than 6% to 8% in order to both maintain its current prod-uct roadmap and build its proprietary application server. Either way, shareholderssuffer. eBay, by the way, does not have such a culture and in fact has a very robustbuild versus buy analysis process to keep just such a problem from happening. 为了澄清这一点，让我们举一个众所周知的现实例子，比如 eBay。如果 eBay 有一种避免使用第三方或 COTS 产品的文化，它可能会专注于构建其软件基础设施的关键部分，例如应用程序服务器。应用程序服务器是一种商品，通常可以以很少的成本获得和实施。假设 eBay 将其收入的 6% 到 8% 用于构建对买卖体验至关重要的应用程序，那么这 6% 到 8% 的一部分现在将用于构建和维护其专有应用程序服务器。这意味着要么为这 6% 至 8% 创建较少的新产品功能，要么需要花费超过 6% 至 8% 的资金才能维持其当前的产品路线图并构建其专有的应用程序服务器。无论哪种方式，股东都会遭受损失。顺便说一句，eBay 没有这样的文化，事实上，它有一个非常强大的构建与购买分析流程来防止这样的问题发生。 Although the application server scenario might seem a bit ridiculous to you, thescenario happens all the time in our advisory practice. We see customers focused onbuilding proprietary databases, proprietary encryption programs, proprietary appli-cation servers, and even proprietary load balancing programs. In almost every case,it’s a result of the team feeling it can build something that’s better without a focus onwhether “better” truly adds any shareholder value. In most cases, in our experience,these approaches destroy shareholder value. 尽管应用程序服务器场景对您来说可能有点荒谬，但这种场景在我们的咨询实践中一直在发生。我们看到客户专注于构建专有数据库、专有加密程序、专有应用程序服务器，甚至专有负载平衡程序。几乎在所有情况下，这是团队感觉自己可以构建更好的东西的结果，而不关注“更好”是否真正增加了股东价值。根据我们的经验，在大多数情况下，这些方法会损害股东价值。 ####Merging Cost and Strategy 合并成本和策略 Now that we’ve presented the two most common approaches to analyzing build versusbuy decisions, we’d like to present what we believe to be the most appropriate solu-tion. Cost centric approaches miss the questions of how a potential build decisionsupports the company’s objectives and do not consider the lost opportunity of devel-opment associated with applying finite resources to noncompetitive differentiatingtechnologies. Strategy centric approaches fail to completely appreciate the cost ofsuch a decision and as such may end up being dilutive to shareholder value. 既然我们已经介绍了两种最常见的分析构建与购买决策的方法，我们想介绍我们认为最合适的解决方案。以成本为中心的方法忽略了潜在的构建决策如何支持公司目标的问题，并且没有考虑因将有限资源应用于非竞争性差异化技术而失去的开发机会。以战略为中心的方法无法完全理解此类决策的成本，因此最终可能会稀释股东价值。 The right approach is to merge the two approaches and develop a set of tests thatcan be applied to nearly any build versus buy decision. We also want to acknowledgea team and a company’s natural bias to build and we want to protect against that atall costs. We’ve developed a very simple, non-time-intensive, four-part test to helpdecide whether you should build or buy the “thing” you are considering. 正确的方法是合并这两种方法并开发一组可应用于几乎任何构建与购买决策的测试。我们还想承认团队和公司对建设的自然偏见，并且我们希望不惜一切代价防止这种情况的发生。我们开发了一个非常简单、非时间密集型、由四部分组成的测试，以帮助您决定是否应该构建或购买您正在考虑的“东西”。 Does This Component Create Strategic Competitive Differentiation? 该组件是否能创造战略竞争差异化？ This is one of the most important questions within the build versus buy analysis process.At the heart of this question is the notion of shareholder value. If you are not creatingcompetitive differentiation, thereby making it more difficult for your competition towin deals or steal customers, why would you possibly want to build the object inquestion? Building something that makes your system “faster” or reduces customerperceived response time by 200 milliseconds may sound like a great argument forbuilding the component in question, but how easy is it for your competitors to get to thesame place? Does 200 milliseconds really make a big difference in customer experience? 这是构建与购买分析过程中最重要的问题之一。这个问题的核心是股东价值的概念。如果您没有创造竞争差异化，从而使您的竞争对手更难以赢得交易或窃取客户，那么您为什么要构建相关对象？构建一些使您的系统“更快”或将客户感知的响应时间减少 200 毫秒的东西可能听起来像是构建相关组件的一个很好的论据，但是您的竞争对手达到同样的目标有多容易？ 200 毫秒真的会对客户体验产生很大影响吗？ Are you increasing switching costs for your customers or making it harder forthem to leave your product or platform? Are you increasing the switching costs foryour suppliers? Are you changing the likelihood that your customers or suppliers willuse substitutes rather than you or a competitor? Are you decreasing exit barriers forthe competition or making it harder for new competitors to compete against you?Does this create new economies of scale for you? These are but some of the questionsyou should be able to answer to be comfortable with a build over a buy decision. Inanswering these questions, or going through a more formal analysis, recognize yournatural bias toward believing that you can create competitive differentiation. Youshould answer “No” more often than “Yes” to this question and stop your analysisin its tracks. There is no reason to incur the lost opportunity associated with dedicat-ing engineers to something that is not going to make you significantly better thanyour competition. 您是否增加了客户的转换成本或让他们更难离开您的产品或平台？您是否增加了供应商的转换成本？您是否正在改变您的客户或供应商使用替代品而不是您或竞争对手的可能性？您是在减少竞争的退出壁垒，还是让新竞争对手更难与您竞争？这是否会为您创造新的规模经济？这些只是您应该能够回答的一些问题，以便对构建而不是购买决定感到满意。在回答这些问题或进行更正式的分析时，要认识到您天生倾向于相信自己可以创造竞争优势。对于这个问题，你应该更多地回答“否”而不是“是”，并停止你的分析。没有理由因为让工程师专注于不会让你比竞争对手明显更好的事情而失去机会。 #####Are We the Best Owners of This Component or Asset? 我们是该组件或资产的最佳所有者吗？ Simply stated, do you really have the right team to develop and maintain this? Doyou have the support staff to give yourself the support you need when the systembreaks? Can you ensure that you are always covered? Very often, a good question totruly test this is “If you are the best owners of this asset, should you consider sellingit?” Think long and hard about this follow-up question because many people get theanswer wrong or at best half right. It may be enough to be the best, or potentially inthe top two or three, but there is rarely a good justification for being “one of the top10” providers of anything, especially if it is not closely aligned with your core business.If you answer “No, because it creates differentiation for us and we want to winwith our primary product,” you are only half right. A fully correct answer wouldalso include “and it won’t make us more money than we make with our primaryproduct,” or “the value in selling it does not offset the cost of attempting to sell it,”or something along those lines. 简而言之，您真的有合适的团队来开发和维护它吗？当系统崩溃时，您是否有支持人员为自己提供所需的支持？您能确保您始终得到保障吗？通常，真正测试这一点的一个好问题是“如果您是该资产的最佳所有者，您是否应该考虑出售它？”认真思考这个后续问题，因为很多人的答案都是错误的，或者最多只答对了一半。成为最好的，或者可能进入前二名或前三名可能就足够了，但很少有充分的理由成为任何东西的“前十名”提供商之一，特别是如果它与您的核心业务不紧密结合。回答“不，因为它为我们创造了差异化，我们希望通过我们的主要产品获胜”，你只说对了一半。一个完全正确的答案还包括“它不会让我们赚到比我们用我们的初级产品赚到的钱更多的钱”，或者“销售它的价值不会抵消尝试销售它的成本”，或者类似的内容。 Here’s something else to consider: Given that there can only be one best at anygiven “thing,” how likely is it that your team can be the best at both what you do tomake money and the new component you are considering building? If you are a smallcompany, the answer is nearly none. If it was statistically unlikely you are the best atthe thing you started on, how can it be more probable that you are the best at boththat old thing and this new thing? 这里还有一些需要考虑的事情：鉴于在任何给定的“事情”上只能有一个最好的，那么您的团队在您赚钱的事情和您正在考虑构建的新组件方面都能够做到最好的可能性有多大？如果您是一家小公司，答案几乎是否定的。如果从统计角度来看，你不太可能在你开始做的事情上表现最好，那么你在旧事物和新事物上都表现最好的可能性怎么可能更大呢？ If you are an online commerce company, it’s entirely possible that you are the best atlogistics planning or the best at presenting users what they are most likely to buy. It isnot very likely at all that you can be the best at one of those things and be the bestdeveloper of databases for your internal needs or the best at developing your specialfirewall or your awesome load balancer. More than likely someone else is doing it better. 如果您是一家在线商务公司，那么您完全有可能是最好的物流规划或最擅长向用户展示他们最有可能购买的商品。您根本不可能成为其中一件事中的佼佼者，并成为满足您内部需求的最佳数据库开发人员，或者最擅长开发特殊防火墙或出色的负载平衡器。很可能其他人做得更好。 What Is the Competition to This Component? 该组件的竞争是什么？ If you have gotten this far in the questionnaire, you already believe that the compo-nent you are building creates competitive differentiation and that you are the bestowners and developers of the component. Now the question is how much differentia-tion can you truly create? To answer this, you really need to dig in and find out whois doing what in this space and ensure that you are so sufficiently different from themas to justify using your valuable engineering resources. Recognize that over time mosttechnologies that are sold become commodities, meaning that the feature set con-verges with very little differentiation from year to year and that buyers purchasemostly on price. How long do you have before a competing builder of this technol-ogy, who also specializes in this technology, can offer it to your primary competitorsat a lower cost than you need to maintain your proprietary system? 如果您已经完成了问卷调查，那么您已经相信您正在构建的组件可以创造竞争优势，并且您是该组件的最佳所有者和开发者。现在的问题是你能真正创造多少差异化？要回答这个问题，您确实需要深入挖掘并找出谁在这个领域做什么，并确保您与主题有足够的不同，以证明使用您宝贵的工程资源是合理的。认识到随着时间的推移，大多数出售的技术都会变成商品，这意味着功能集每年都会趋同，几乎没有差异，而买家主要根据价格进行购买。您需要多长时间才能让该技术的竞争对手（也专门从事该技术）以比您维护专有系统所需的成本更低的成本向您的主要竞争对手提供该技术？ Can We Build This Component Cost Effectively? 我们可以有效地构建这个组件吗？ And our last question is about cost. We hinted at the cost component within the anal-ysis of the existing competition for our new component, but here we are talkingabout the full fledged analysis of cost over time. Ensure that you properly identify allof the maintenance costs that you will incur. Remember that you need at least twoengineers to maintain anything, even if at least part time, as you need to ensure thatsomeone is around to fix problems when the other person is on vacation. Evaluateyour past project delivery schedules and make sure you adjust for the likelihood thatyou are overly aggressive in your commitments. Are you generally off by 10% or100%? Factor that into the cost analysis. 我们的最后一个问题是关于成本的。我们在对新组件现有竞争的分析中暗示了成本组件，但在这里我们讨论的是随着时间的推移对成本的全面分析。确保您正确识别将产生的所有维护成本。请记住，您至少需要两名工程师来维护任何东西，即使至少是兼职，因为您需要确保当其他人度假时有人在旁边解决问题。评估您过去的项目交付时间表，并确保针对您的承诺过于激进的可能性进行调整。你们一般会减少 10% 还是 100% 吗？将其纳入成本分析中。 Make sure you treat the analysis as you would a profit and loss statement. If youare dedicating engineers to this project, what projects are they not working and whatrevenue are you deferring as a result, or which scalability projects won’t get done andhow will that impact your business? 确保像对待损益表一样对待分析。如果您专门派工程师参与这个项目，哪些项目没有工作，您因此推迟了哪些收入，或者哪些可扩展性项目无法完成，这将如何影响您的业务？ #####Checklist—Four Simple Questions 清单——四个简单问题 Use this simple checklist of four questions to help you in your build versus buy decisions: 使用这个包含四个问题的简单清单来帮助您做出构建还是购买决策 * Does this component create strategic competitive differentiation? Are we going to have long-term sustainable differentiation as a result of this in switching costs, barriers to entry, etc.? * 该组件是否会创造战略竞争差异化？我们是否会因此在转换成本、进入壁垒等方面实现长期可持续的差异化？ * Are we the best owners of this component or asset? Are we the best equipped to build it and why? Should we sell it if we build it? * 我们是该组件或资产的最佳所有者吗？我们是最有能力建造它的人吗？为什么？如果我们建造它，我们应该卖掉它吗？ * What is the competition to this component? How soon until the competition catches up to us and offers similar functionality? * 该组件的竞争是什么？竞争对手要多久才能赶上我们并提供类似的功能？ * Can we build this component cost effectively? Are we reducing our cost and creating additional shareholder value and are we avoiding lost opportunity in revenue? * 我们可以有效地构建这个组件吗？我们是否降低了成本并创造了额外的股东价值？我们是否避免了收入机会的损失？ Remember that you are always likely to be biased toward building so do your best to protectagainst that bias. The odds are against you that you can build a better product than thosealready available and you should tune your bias toward continuing to do what you do welltoday—your primary business. 请记住，您总是可能对构建存在偏见，因此请尽力避免这种偏见。您很难构建出比现有产品更好的产品，因此您应该调整自己的倾向，继续做您今天擅长的事情——您的主要业务。 ####AllScale’s Build or Buy Dilemma AllScale 的构建或购买困境 AllScale decides to expand its services beyond the HRM platform and begins to builda customer relationship management (CRM) system focused initially at staffing andrecruiting companies. After the product has been defined at a business level, a teamof engineers, architects, and product managers begin to work on the high-level archi-tecture of the platform that will support the CRM functionality. One piece of func-tionality within the system will be the capability for companies to extend the systemby adding their own functionality. A debate soon begins over whether AllScaleshould build an interpreter for a proprietary AllScale scripting language that custom-ers would need to learn and use. AllScale 决定将其服务扩展到 HRM 平台之外，并开始构建最初专注于人员配置和招聘公司的客户关系管理 (CRM) 系统。在业务级别定义产品后，工程师、架构师和产品经理团队开始研究支持 CRM 功能的平台的高级架构。系统内的一项功能是公司能够通过添加自己的功能来扩展系统。关于 AllScale 是否应该为客户需要学习和使用的专有 AllScale 脚本语言构建解释器的争论很快就开始了。 The engineers think the project to build such an interpreter would be very excitingand quickly they set about defining why the interpreter should be proprietary ratherthan using one of the many existing interpreters ranging from Visual Basic to Pythonor PERL. The engineers all believe that they can make an interpreter specific to theneeds of AllScale’s needs and as a result the interpreter dubbed ScaleTalk will runfaster and more efficiently than any interpreted language they would otherwiseimplement. Johnny Fixer, CTO, on the other hand, is concerned about the time itwould take to develop such an interpreted language and is dubious regarding thepotential returns of such a system. Christine E. Oberman, CEO, is always talkingabout how they should think in terms of shareholder value creation, so Johnnydecides to discuss the opportunity with her. 工程师们认为构建这样一个解释器的项目将非常令人兴奋，他们很快就开始定义为什么解释器应该是专有的，而不是使用从 Visual Basic 到 Python 或 PERL 的许多现有解释器之一。工程师们都相信，他们可以根据 AllScale 的需求制作一个特定的解释器，因此被称为 ScaleTalk 的解释器将比他们原本实现的任何解释语言运行得更快、更高效。另一方面，首席技术官 Johnny Fixer 则担心开发这种解释性语言所需的时间，并对这种系统的潜在回报表示怀疑。首席执行官克里斯汀稥•伯曼 (Christine E. Oberman) 总是谈论他们应该如何思考股东价值创造，因此约翰尼决定与她讨论这个机会。 Together, Johnny and Christine walk through the four-part build versus buychecklist. They decide that using a proprietary language increases the switching costsfor customers because for a customer to leave AllScale for another provider of CRMtechnology, AllScale would need to rewrite its ScaleTalk scripts. The barriers to entryare also raised, as other companies adopting readily available interpreters for similarfunctionality would lack some of the functionality specific to the AllScale product.They agree that there is a strong business case for creating strategic competitive dif-ferentiation through an interpreter that customers can use to extend and modify thefunctionality of the AllScale CRM product. 约翰尼和克里斯汀一起完成了由四部分组成的构建与购买清单。他们认为使用专有语言会增加客户的转换成本，因为如果客户离开 AllScale 而转向另一家 CRM 技术提供商，AllScale 需要重写其 ScaleTalk 脚本。进入壁垒也增加了，因为其他公司采用现成的类似功能的解释器将缺乏 AllScale 产品特有的一些功能。他们同意，通过客户可以通过解释器创建战略竞争差异化是有强有力的商业案例的。用于扩展和修改 AllScale CRM 产品的功能。 Johnny and Christine disagree on whether they are the best builders and owners ofthe asset. Although they agree that it can create shareholder value, Christine doubtsthat the engineers they have today have the best skills to build such an interpreter.Christine pushes Johnny to experienced help in interpreters should they decide tomove forward and build ScaleTalk. Johnny reluctantly agrees to do so. 约翰尼和克里斯汀对于他们是否是该资产最好的建造者和所有者存在分歧。尽管他们同意这可以创造股东价值，但 Christine 怀疑他们现在拥有的工程师是否具备构建此类口译员的最佳技能。如果 Johnny 决定继续推进并构建 ScaleTalk，Christine 会敦促 Johnny 寻求经验丰富的口译员帮助。约翰尼勉强同意这样做。 Christine and Johnny agree that there is little direct competition to ScaleTalk as itis defined. There are lots of substitutes that would offer 60% of the intended func-tionality, but nothing that would allow them to give customers the flexibility andpower of ScaleTalk within the AllScale CRM system. Johnny believes that it couldtake years for someone else to build an interpreter for their own platforms, but Chris-tine pushes back indicating that it would probably take less time for a competitor tocopy AllScale’s solution than for AllScale to build it. Her reasoning is that the com-petitor needn’t innovate but rather copy nearly wholesale the features and functional-ity of AllScale’s intended interpreted language. Johnny decides that she has a goodpoint but indicates that AllScale would continue to innovate and give customers addi-tional language functionality over time. Christine 和 Johnny 一致认为，按照 ScaleTalk 的定义，几乎没有直接竞争。有很多替代品可以提供 60% 的预期功能，但它们无法为客户提供 AllScale CRM 系统中 ScaleTalk 的灵活性和强大功能。 Johnny 认为其他人可能需要数年时间才能为自己的平台构建解释器，但 Christine 反驳道，竞争对手复制 AllScale 的解决方案可能比 AllScale 构建它所需的时间更少。她的理由是，竞争对手不需要创新，而是几乎批量复制 AllScale 预期解释语言的特性和功能。 Johnny 认为她有一个优点，但表示 AllScale 将继续创新，并随着时间的推移为客户提供额外的语言功能。 Christine asks Johnny to estimate how long it would take to build the interpreterfor ScaleTalk and to determine how much they would save in license fees, support fees,and other costs of the system over the course of five years. Johnny does a back-of-the-envelope calculation indicating that five engineers over seven months should be ableto create the interpreter for a net headcount of expense of roughly $300,000.00. Hefurther indicates that the company will need to dedicate one engineer full time for thelife of the system to maintain it for an ongoing expense of $80,000.00 per year. Hebelieves the company will save about $60,000.00 per year in license and support feesfor a similar product and about $200,000.00 in initial purchase costs. That leaves a$100,000.00 gap in initial development costs and an ongoing deficit of $20,000.00per year. Johnny believes both of these will be made up in three years by needing fewersystems to support a similar number of transactions and in faster time to market. Christine 要求 Johnny 估计构建 ScaleTalk 的解释器需要多长时间，并确定在五年内他们将节省多少许可费、支持费和系统的其他成本。 Johnny 进行了粗略计算，表明五名工程师在七个月内应该能够创建翻译器，净人员费用约为 300,000.00 美元。他进一步指出，该公司需要在系统的整个生命周期内聘请一名工程师全职维护该系统，每年的持续费用为 80,000 美元。他相信公司每年将节省大约 60,000.00 美元的类似产品许可和支持费用以及大约 200,000.00 美元的初始购买成本。这使得初始开发成本存在 100,000 美元的缺口，并且每年持续存在 20,000 美元的赤字。约翰尼相信，这两个问题都将在三年内得到弥补，因为需要更少的系统来支持相似数量的交易，并且上市时间更快。 Although not a perfect scenario, Christine and Johnny jointly decide that ScaleTalkfor the AllScale CRM application is worth pursuing. Christine asks to be kept in the loopregarding development timeframe and issues as she is concerned about cost overruns.Johnny agrees and makes a note to clearly call out ScaleTalk progress in his weeklystatus meetings and monthly product updates. Christine makes a note to create a slideor two for the upcoming board of directors meetings to discuss the ScaleTalk decision. 虽然不是一个完美的方案，但 Christine 和 Johnny 共同认为 AllScale CRM 应用程序的 ScaleTalk 值得采用。 Christine 要求随时了解开发时间框架和问题，因为她担心成本超支。Johnny 同意并做了笔记，在每周状态会议和每月产品更新中明确指出 ScaleTalk 的进展情况。 Christine 做了笔记，为即将召开的董事会会议创建一个或两个滑块，以讨论 ScaleTalk 的决定。 ####Conclusion 结论 Build versus buy decisions have an incredible capability to destroy shareholder valueif not approached carefully. Incorrect decisions can steal resources to scale your plat-form, increase your cost of operations, steal resources away from critical customerfacing and revenue producing functionality, and destroy shareholder value. We notedthat there is a natural bias toward building over buying and we urged you to guardstrongly against that bias. 如果不谨慎处理，自建还是购买决策具有令人难以置信的破坏股东价值的能力。错误的决策可能会窃取资源来扩展平台，增加运营成本，从关键的面向客户和创收功能中窃取资源，并损害股东价值。我们注意到人们对建设过度购买存在天然偏见，我们敦促您强烈警惕这种偏见。 We presented the two most common approaches, cost centric and strategy centric.We offered a third approach that merges the benefits of both approaches and avoidsmost of the problems each approach has individually. Finally, we offered a four-partchecklist for your build versus buy decisions to help you make the right choice. 我们提出了两种最常见的方法，即以成本为中心和以策略为中心。我们提供了第三种方法，它融合了两种方法的优点，并避免了每种方法各自存在的大多数问题。最后，我们为您的构建与购买决策提供了一个由四部分组成的清单，以帮助您做出正确的选择。 #####Key Points 关键点 * Making poor build versus buy choices can destroy your capability to scale costeffectively and can destroy shareholder value. * 做出糟糕的构建与购买选择可能会破坏您以成本效益方式扩展规模的能力，并可能破坏股东价值。 * Cost centric approaches to build versus buy focus on reducing overall cost butsuffer from a lack of focus on lost opportunity and strategic alignment of thecomponent being built. * 以成本为中心的构建与购买方法侧重于降低总体成本，但缺乏对失去的机会和正在构建的组件的战略协调的关注。 * Strategy centric approaches to build versus buy focus on aligning the decisionwith the long-term needs of the corporation but do not account for total cost. * 以战略为中心的构建与购买方法侧重于使决策与公司的长期需求保持一致，但不考虑总成本。 * Merging the two approaches results in a four-part test that has the advantagesof both approaches but eliminates the disadvantages. * 合并这两种方法会产生一个由四部分组成的测试，它具有两种方法的优点，但消除了缺点。 * To reach a “buy” decision, you should be able to answer the following: * 要做出“购买”决定，您应该能够回答以下问题 + Does this component create strategic competitive differentiation? + 该组件是否能创造战略竞争差异化？ + Are we the best owners of this asset? + 我们是该资产的最佳所有者吗？ + What is the competition to the component? + 该组件的竞争是什么？ + Can we build the component cost effectively? + 我们可以有效地构建组件吗？
没有评论