Orchestrating the Ecosystem

Orchestrating the Ecosystem
On a beautiful sunny afternoon in July 2007, Zia Yusuf, the Executive Vice President, Global Ecosystem and Partner Group at SAP, took a sip of his cappuccino as he walked into his office. Yusuf found a new PowerPoint deck on his desk and his attention turned to Nakisa Inc., a small software company seeking Tier 1 status within SAP. But for the Montreal-based succession-planning software company to achieve the prized Tier 1 status, there would have to be a business case presented to the Board, one that justified, on an array of criteria, the rationale for this award. If it did happen, tiny Nakisa would take its place, in a very small and select circle, alongside such companies as Adobe, Cisco, and Microsoft. Five years ago, SAP would likely have built the application with its own engineering organization. Yusuf’s team had worked together with SAP’s product management organization to put together a deck of slides on the Nakisa partnership to be presented to the SAP Board. Yusuf flipped through the deck and wondered if the recommendation to elevate Nakisa to Tier 1 status really made sense.

Yusuf reflected for a moment on how far things had come in just a few years, to even be considering this. Prior to 2000, organizations in the enterprise resource planning software (ERP) industry—notably archrivals SAP and Oracle—played clear-cut roles in the complex process of developing and installing enterprise applications, even as the nature of the product demanded extensive collaboration between software supplier, enterprise customer, and the system integrators that drove implementation. SAP’s technology and its ability to create new areas of business process expertise for new applications were instrumental in making the firm the world’s leader in the Enterprise Resource Planning (ERP) field (see Exhibit 1).

In the new century, with the consolidation of the enterprise software market, SAP decided to strengthen its leadership position by adopting a platform strategy, which had proven very successful in the technology industry before (e.g., Windows, Intel). SAP wanted to create a platform that could be the basis for further application software innovation by third party ISVs that would benefit both its customers and enhance its market position. In 2003, SAP revealed its NetWeaver based platform, which foreshadowed its new role as the hub of a complex software ecosystem where SAP customers, traditional system integrator partners, and independent software vendors thrived and interacted with each other using SAP’s platform and technologies.Cases are not intended to serve as endorsements, sources of primary data, or illustrations of effective or ineffective management. Copyright © 2009 President and Fellows of Harvard College. To order copies or request permission to reproduce materials, call 1-800-545-7685, write Harvard Business School Publishing, Boston, MA 02163, or go to http://www.hbsp.harvard.edu. No part of this publication may be reproduced, stored in a retrieval system, used in a spreadsheet, or transmitted in any form or by any means—electronic, mechanical, photocopying, recording, or otherwise—without the permission of Harvard Business School.

achieve the holy grail of interoperability and reusability both inside and outside of its customers’ enterprises.
Yusuf began to dig into the information about Nakisa, aware of all the moving parts involved and how a build/buy/partner decision could have implications within SAP and among its partners. How critical is this application, he asked himself as he began his review? Is it “mission-critical”? If so, does it mean that we should make it in-house? Is it really all that hard to make? Should we buy the company? If Nakisa became a strategic partner, could it accommodate the demands that SAP, with its tens of thousands of customers and multitudes of sales representatives and System Integrator partners, would place on it? How would this be perceived by the Board?

Founded in Mannheim, Germany in 1972 by a small group of programmers originally from IBM, SAP staked out new ground in the automation of business processes, with a commitment to developing off-the-shelf applications that would be cheaper and more quickly installed than the customized solutions the big companies were then pursuing. Over the next three decades, SAP developed software that aimed to keep pace with fast-changing technological developments and client needs. Its first offering, R/1, was aimed at automating companies’ accounting functions. By 1980 SAP offered a mainframe database (R/2) package, which was replaced a little more than a decade later by a client/server version (R/3). R/3 could automate all of an enterprise’s business processes, from manufacturing to finance to human resources. It was the promise that companies could control resources and their allocations across complex enterprises that gave the software its name, enterprise resource planning, and made SAP an indispensable purchase all over the world. Over the years, SAP’s solution suite grew to include applications for supplier relationship management, customer relationship management, supply chain management, and product lifecycle management, in addition to ERP.

SAP also began to build and integrate industry-specific functionality to better enable its customers to use the applications for their specific needs in industries such as aerospace and defense, consumer products, chemicals and others. Given its software’s popularity and the demands increasing growth made on its own resources, SAP focused only on product development, leaving installation and customization to system integrator (SI) partners and its consultants, whom it would train and certify. The SIs typically charged more for their services than companies paid for their licensing fees: sometimes more than four or five times the licensing fees. However, the “solutions,” as attempts to make complex situations simple, became themselves fraught with technical incompatibility, as individual functions tended to pursue their own approaches; overall (i.e., enterprise-wide), integration often
became very challenging.

1995-2002
The Internet exploded in the 1990s and the model for enterprise software began to change once again. Internet startups challenged the business model of both SAP and SAP’s customers. A nexus of industry stalwarts like IBM, Microsoft, and venture capital-backed startups pushed open protocols and web services as the holy grail of software integration. IT customers could now, supposedly, eschew fully integrated solutions from a few providers and instead use “open” standards-based technologies to mix and match data and services and develop “best-of-breed” application solutions in a rapid manner. The focus, in this new world, was on flexibility via open protocols, standards, and languages that all aimed to enable a painless exchange of data, anywhere anytime in contrast to 2 systems where information might be able to flow relatively freely within the enterprise but have considerable difficulty getting beyond it.

Other trends also had their origin in this period. One was the increasing use of outsourcing, which blossomed into off-shoring, and the rise of enterprises like Wipro and Infosys (in India) that managed the work and workers. It was in fact the “rationalizing” of business processes, enabled by ERP applications that led organizations to assume that these activities could be coherently performed beyond the firm’s boundaries and at dramatically less cost. Meanwhile, in conjunction with that trend was an increased emphasis on what was “core” and “peripheral” to the firm, and where “competencies” lay. This set up, within organizations and as a part of their enterprise resource planning, the potential of making some of an enterprise’s functions and processes more important than others. This caused many organizations to embark on integrating internal IT systems with external suppliers, customers, and markets. Driven by the demand for Business-to-Business (B2B) market exchanges, IT systems now not only had to
become good at integrating internal information but also seamlessly connecting with external providers.

The rise of the Internet and the trend toward outsourcing created two interrelated results. First was the rise of specialized, best-of breed vendors who developed function-specific software that operated in tandem with a company’s ERP system. Second was the growing awareness that IT itself was a potential source of differentiation. As such, a firm would want to have something beyond the “best-of suite” that was, by virtue of licensing fees, basically available to anyone. That differentiation was becoming more possible not only via a host of new vendors using “flexible” technologies but also because organizations were often becoming more technologically fluent themselves—at various levels. The dreaded advent of year 2000 (“Y2K”), when potential dating problems (i.e., old systems were not set up for a year that began with “2”) would grind the planet to a halt, prompted massive reevaluations of IT policies, strategies, technologies, and purposes. At the same time, employees had themselves become far more sophisticated, as a generation raised on video games, personal computers, and, increasingly, the Web and Internet, joined the workforce.

As the Internet continued to evolve and play a greater role in SAP’s application development the company began to enhance their offerings to embrace tools and interfaces that would make the user experience more like their every day computer usage experience with joint offerings from Microsoft and others. As customer usage continued to mature, SAP recognized a demand and opportunity to enable customers to optimize the data and information within their SAP systems for analysis and strategic decision making. Working with partners and through development the company focused on bringing strategic insight capabilities to customers.

For SAP, these factors, and a growing consolidation of the ERP industry itself, triggered a hunt for increased sources of growth. One decision the company took was to pursue the small and medium-sized enterprises (SME) market; another, equally important tack was to meet the software flexibility issue head on.
Hasso Plattner, SAP’s co-founder and co-CEO through the Internet turmoil, responded to these challenges by convincing SAP’s Board in the spring of 2002 that the company’s future lay in embracing an open architecture strategy and by converting SAP from a software application provider to an open-standard based platform. In early 2003, SAP announced its NetWeaver composition and integration platform that encompassed SAP’s prior investments in traditional proprietary ERP technologies based on the ABAP programming language and the more recent open web-based technologies like IBM’s WebSphere, Microsoft’s .Net, and Sun’s Java programming language.

The move to the application platform was not just technological but also organizational. SAP had long pioneered working with SIs like Accenture, Deloitte, or IBM to help clients customize and install SAP systems—however, software functionality was still developed internally. The application platform strategy changed this dynamic as now “anyone” could now leverage SAP application functionality and create new applications on top of it. SAP’s challenge was now to attract and work with independent software vendors, SIs, and customers in ways that it had not done before.

Designing and Building the Ecosystem
As SAP embarked on the application platform strategy in 2003, SAP’s main challenge was to build out the ecosystem to attract both customers and partners to adopt the platform. Customers wanted to see broad adoption by partners before adopting the platform themselves. Partners, on the other hand, and particularly software companies, wanted to see customers on the platform before investing in the new platform. SAP started to work closely with key customers, where it had built trust over a long period of time, to pioneer new composite applications. Whirlpool Corporation, for example, used the SAP platform to build internal and external connections to their trade partners. Over two years, Whirlpool reported increased transactions on their application platform worth over one billion dollars while reducing IT costs by six percent. Customers like BG Group, Goodyear Dunlop, and Zeiss reported ROI’s between 281% and 362%. By January 2005, SAP had compiled a list of over 1,500 customers who had implemented at least one application solution on the Business Process platform. Yusuf reflected on the ecosystem design:

The SAP ecosystem was designed to enable our customers to view enterprise IT as a core asset that not only allowed cost reductions in the short term but fundamentally enabled adaptation and innovation for the long term. To deliver on this promise we had to engage customers, partners, and the SAP internal organizations with each other. The ecosystem was not about creating a hub and spoke network with SAP in the middle. Rather it was about a true peer-to-peer connection which was enabled by SAP technology and business process understanding. The fundamental insight we had was that the connection had to be between organizations and the individuals within those organizations—we needed both formal and informal ties in the ecosystem. The ecosystem was only going to be successful if we enabled collaboration across all these actors and organizations. We had to build communities, attract partners and change ourselves so we could best serve all these stakeholders in the ecosystem. (See Exhibit 3).

Communities of Innovation
The concept of community was core to the SAP ecosystem. Clearly, vast knowledge about how businesses ran SAP software resided outside of its own borders. Access to this knowledge could be critical to both customer and partner effectiveness. The best way to unlock this knowledge was to enable the various members of SAP’s ecosystem to interact with each other. Concurrent to the launch of the platform strategy was the establishment of SAP-sponsored communities of innovation. Embracing web-based technologies as core to SAP also meant that the spirit of community on the Internet as exemplified by open source software, Wikipedia, and blogs had to be embraced by SAP. Networking, and demands for collaboration, partnering, and community creation and management, would require a mindset shift within the SAP organization, as well as some changes in how functions operated. SAP communities spanned individuals and companies and the technical and business domains (see Exhibit 4).

The SAP Developer Network (SDN) exemplified the power of communities and the individuals in the ecosystem to self-organize and create value for each other in the ongoing usage of NetWeaver. By 2007, SDN became the community hub for technologies for over one million members (software developers, IT architects, and system administrators) associated with customers, partners, and internal SAP product and marketing organizations. Members contributed more than 5,000 posts per day in over 180 SAP hosted discussion forums which received more than 500,000 unique visitors per month. The median response time to a question on a technical forum was less than 20 minutes. Most of the responses came from other community members and not SAP employees; most questions received two to three responses and over 85% of the questions were deemed “answered” by the original poster.

Werner Miehle, an Architecture Strategy Manager from Airbus, articulated the customer point of view: “Increasing the productivity of our IT people year after year can be a challenge given our distributed, highly specialized workforce. The learning and collaboration that happens in SAP Developer Network really supports the productivity of our IT staff across Airbus locations in France, Germany, Spain, the UK, and China.” Of course, SAP also benefited by this user-to-user support mechanism as it now had to field fewer calls to its own staff. SDN also enabled co-innovation among its members. For example, in 2006, two developers from Colgate-Palmolive produced a tool, SAPlink, that allowed for easy distribution of custom code objects on the NetWeaver platform. These developers decided to showcase their tool at a face-to-face community meeting and made it freely available to other SDN members. The tool won an award from the community and also attracted 17 other developers to make code contributions.

Within a year, this tool had 19 additional plug-ins to handle other object types. SAP also established the Business Process Expert (BPX) community to connect ecosystem members responsible for creating models of new ways for enterprises to connect internally and externally. Community members, on their own, were often at the forefront of defining new interaction models & business processes that challenged existing technologies and implementation. However, there was a tremendous degree of expertise on business process modeling embedded in various specific industries. The BPX community allowed for the sharing of industry-specific solution maps along with interactions amongst business process experts and technology developers to assess feasibility of new process creation. BPX was also burgeoning with the activity of over 250,000 members in 2007, collaborating on change management, project leadership and industry best practices.

Core services development on the SAP platform was done in conjunction with selected ecosystem partners that SAP invited to join in the Enterprise Services (ES) community. These services were the “value added” that SAP provided on its platform and could be specific to either a business function (e.g., procurement, supply chain management) or industry (e.g., banking, energy, public sector). SAP convened community definition groups comprised of ES community members to address specific needs by inviting leading customers and partners to work collaboratively to define the exact specification that would be used by internal SAP developers to create the next round of enhancements to the platform.

SAP chose to keep membership on an invitation basis because the specifications created in the ES community resulted in SAP products and it was critical that it had clear rights to the intellectual property (IP) included in the products. Otherwise, someone could participate in a group, provide some great ideas, and then later that person’s company could reveal that it has patents on the ideas and require that SAP license the patents or else stop shipping the products. To prevent this scenario, participation in the ES community was based on a legal agreement that established a clear IP framework.

The ES community had over 300 customers and partners and was responsible for creating specifications for 24 of the 46 enterprise service bundles SAP delivered to its customers in 2007 (see Exhibit 5 for a sample list of organizations participating and examples of specifications that were jointly developed).

Beyond technology development, SAP also established Industry Value Networks (IVN) comprised of senior executives in specific industries and the specialized SAP partners that served those industries to assess key challenges and opportunities facing them. For example, the oil and gas Industry Value Networks was established to develop industry-wide innovations in commodity trading optimization, secondary distribution management, and the digital oilfield. The IVN enabled SAP to both look ahead and assess the shape of future industrial change and to potentially influence its direction and trajectory.

As part of the Ecosystem approach, SAP also created a Standards team that actively engaged in a variety of technology and industry standards communities, shaping standards to maintain an SAP advantage and/or create a level playing field for all vendors. SAP also established working relationships with independent SAP User groups/communities in various countries, such as Americas SAP User Group (ASUG) in North America, DSAG in Germany, to ensure customer feedback is incorporated into product development, and maintain an open, healthy dialogue with customers on wide variety of topics.

Mark Yolton, SVP of SAP Community Network, noted: “Our communities enable co-innovation that provides significant value to our customers, our partners and our firm. Communities drive new ideas, work practices and approaches that we aim to deliver through our software and with our partner solutions. We work hard to orchestrate our communities so that peer-to-peer connectivity takes place across all SAP stakeholders. “

Attracting Partners
SAP was no stranger to partnerships, having built its business by working hand in hand with SIs that actually delivered and installed its products to its customers. Given the platform strategy, SAP had to focus its efforts in reaching out to independent software vendors (ISVs) to encourage the creation of new functionality on top of the SAP platform. The company had to open up its technology & resources to support the new strategy, similar to earlier efforts from Oracle and Microsoft, which had signed up a large number of ISVs to form strategic developer networks around their traditional platform-like products.

Prior attempts at working with ISVs faced challenges because SAP was more focused on building the application internally instead of buying or partnering with another ISV. The platform strategy forced a wholesale rethinking on behalf of SAP towards its potential partners. Yusuf noted: “We had to rapidly expand and enhance our engagement with ISVs. In the ecosystem world, our partners were essential to our customers and our own success. We realized that in many cases our customers  encounter challenges that could be rapidly and effectively solved through our partner solutions and services. We simply could not do it all. Hence it was our imperative to now encourage the creation of diverse offerings from our partners, ensure and certify that they work on our systems and create ways for our customers to find and use them.”

SAP actively managed four major partner types; 1) System Integrators; 2) channel partners; 3) technology partners; and 4) software partners. Other partner categories included content partners, education partners, hosting partners etc. SAP had well established routines for developing and maintaining relationships with System Integrators and thus did not view them as a significant new challenge. SAP’s scale prevented it from being cost effective in selling to small- to medium-sized enterprises (SMEs) and thus channel partners were developed to specifically target solutions to enterprises that had less than $200M in annual revenue. Channel partners provided industry- and business-specific expertise to SMEs for cost effective and timely deployment of SAP solutions. SAP setup a structured partner program called SAP PartnerEdge to manage partners and provide enablement services, certifications and basic support services to partners.

The technology partners program was established to build strategic relationships between SAP and other large technology firms like Adobe, Intel, and Microsoft that could result in joint technology development that mutually benefited all parties. With Adobe, SAP jointly created interactive forms that enabled the creation of a seamless enterprise experience across customer, partners, and suppliers. SAP worked with Intel to speed processing of the multitudes of data stored in databases powering its applications. Intel developed special modifications to its motherboards to enable the preloading of a high-volume memory cache instead of using the onboard memory to load and run the data. Finally with Microsoft, SAP created a joint product called Duet that seamlessly integrated the flagship Microsoft Office Suite with SAP systems. Thus, reporting, budget alerts, sales, and account management could be directly linked to Microsoft Outlook and demand forecasting could be enabled natively within Microsoft Excel.

ISVs were recruited to the platform initiative by SAP’s creation of a new certification program which it branded “Powered by NetWeaver.” The program had two aspects. First, it ensured the high quality technical integration of third party software with SAP NetWeaver. Therefore, the partner solution had to be built on top of the NetWeaver web application server and had to withstand several quality and reliability tests. Second, the program included additional marketing support and a closer business relationship with the partner. “Powered by NetWeaver” partners could use the SAP brand logo to demonstrate to customers their proven interoperability with SAP solutions, and they were listed in the SAP partner catalog. The marketing support contained different levels of engagements depending on how well the partner solutions complemented SAP’s own offering. In some cases, SAP organized joint analyst events or offered partners a forum at SAP’s customer events. In selected cases, SAP even agreed to act as a reseller for the partner. In order to give direction to its ISVs about its development strategy, SAP began developing industry specific solution maps that outlined, over a three year horizon, those areas of IT functionality SAP wanted in its own products and those that could be covered by ISV partner solutions.

The solution map identified the level of IT functionality that was used in specific areas along an industry’s value chain (Exhibit 6 gives an example of a solution map for the telecommunication industry). SAP then evaluated how adequately it served each individual IT scenario with its own applications. The assessment ranged from “completely covered” to “elementary covered” to “not covered” by SAP’s applications.

In areas that were only elementary or not covered at all, SAP had to evaluate whether it was worth pursuing this opportunity on its own, or if it wanted to leave the whitespace open for partner solutions. IT functionality that is core to SAP offering or adjacent segments had high market attractiveness would be actively pursued by SAP. Other opportunities would be left for partners SAP made clear that it was open to working with partners in all
areas of IT functionality, whether they were complementors or competitors. In 2007, over 7,000 firms participated as partners.

Product Management in Light of the Ecosystem
Ecosystem notwithstanding, SAP still devoted significant attention and resources to the basics of product management and development. After all, a significant portion of revenue is driven by new software licenses sold to customers (see Exhibit 7).

Elvira Wallis, SVP of NetWeaver Product, described the basic activities of her organization: There is the product definition aspect, which means defining the product roadmap, driving the product strategy, including things like white space analysis. What do we want to own? What do we want to build? Where do we want to partner? And also, what are we going to ignore? The question we always ask ourselves is whether we would build something ourselves or would we partner or would we buy. That’s sort of the inbound side of the house. And then the other wing of product management is the outbound side of the house: taking a new product to market. We organize product information, everything that has to do with the supporting materials and information for taking a product to market.

Both inbound and outbound decisions were taken with SAP’s ecosystem/community thrust as an integral part of the process. SAP’s embrace of communities and partners also implied a major change for the internal SAP organization. Volker Hildebrand, VP of Product Management, referred to the BPX innovation community as an “interaction channel.” “It really drives collaboration not just SAP customer-to-SAP response, but customer-to-customer interaction, or customer-to-partner interaction.” The discussion forums, Hildebrand noted, were particularly active: “We have six different CRM forums on BPX, and there can be 85,000 contributions on them,” ranging from the highly technical to the very general. Hildebrand stressed the diversity of participants—customers, users, partners, analysts—anyone: “people with different backgrounds—what one member called ‘the geeks and the suits.’ They interact with each other but also with SAP product management, because we have moderators in all six CRM forums that come from our product management organization.”

Hildebrand saw this forum moderation work as “an integral part of what product management is supposed to be; it helps with writing specifications and eventually developing the right product-their traditional responsibilities.” “Product management has really become customer engagement,” Hildebrand continued. “We’re really looking at communication, reaching out, connecting with customers—really collaborating with the community. Rather than simply answering an email from one customer, the question and answer are publicly shown and that answer can create hundreds of happy customers who needed that information. These forums don’t replace the one-on-one events or meetings, [but] they’re a powerful new kind of platform that engages customers.”

The Nakisa Relationship
Montreal-based Nakisa was founded in 2000 as a consulting company in the field of organization management, creating custom applications for its clients. Over the next few years, the consultants noted problems common to their customers: while organizational structure was a fundamental building block for how human resources were to be specifically managed and how HR information could be organized more generally, the relevant data needed for that work often lodged in various parts of a company’s IT/ERP system, and could be cumbersome both to extract and to manipulate. “There is information about people and [their] organizational units that resides in all parts of the system,” Babak Varjavandi, the company’s founder and current president, said. “So we decided to provide the ability to actually visualize it. While our competitors attempted to offer full-blown solutions to the problem, we focused on creating a visualization layer that sits on top of an ERP system.” Nakisa’s first product with this technology was an organizational charting application (in 2003); the company, in conjunction with SAP, subsequently created a succession-planning product based on that application. The ERP systems Nakisa targeted with these products included those from SAP, Oracle, Microsoft, and PeopleSoft (now part of Oracle). In 2007, the company had about 50 employees.

Nakisa’s SAP customers soon began demanding SAP certification. “If you are pulling information from SAP,” Varjavandi recalled them saying, “are you doing it in the right way?” The company applied for certification at that point and embarked upon what Varjavandi referred to as a “journey” over the next four years as its relationship with SAP evolved. ”We wanted to become a Tier 1/Tier 2 partner right away, but they did not accept to make us one,” he said. Instead, Nakisa applied for “Certified for NetWeaver,” essentially SAP’s entry-level status. David Ludlow, Vice President of Product Management Human Capital Management Solutions, described what Nakisa offered to customers:

The whole concept of organizational charting is ‘who reports to whom.’ If you’re a manager of a unit, that’s critical information, and it’s information that continually changes as people move around, and can be scattered in various locations. It can also be valuable for an employee to know a reporting line when interacting with other employees across large organizations. SAP and others did not offer the ability for employees and managers to literally ‘see’ this from an organizational structure perspective. Nakisa’s visualization layer made that possible.” But it was what organization charting could lead to that caused the connection between SAP and Nakisa to deepen. Ludlow elaborated: “What Nakisa realized is that the org chart could be a good navigation paradigm for different end users of an HR system, because the organizational structure is a fundamental building block of how you organize your information and how you manage it.

Meanwhile, the area of “talent management” was becoming one of SAP’s fastest growing enterprise application areas, and part of the company’s Human Capital Management (HCM) business. And a core element of talent management was succession planning. “The whole purpose of succession management is to ensure the safety of the position itself,” Ludlow pointed out. “And Nakisa was in the business of visualizing those positions through an org chart.” Varjavandi outlined what was involved in succession planning:

First you need to look at the objectives of the company and you need to look at positions within the company that are key to supporting them. Then you have to determine the competencies for the positions. Then you look at the employees occupying the positions and the ‘bench strength’ of other employees that could occupy them if they became vacant.

These were issues that SAP was grappling with as talent management grew in importance for the company and for the more than 11,000 customers in its installed base. SAP decided that its investment in talent management would include the ability to model organizations, to provide decision criteria for who might qualify as a successor, and how to develop a pool of talent. For SAP, visualization of succession management would provide a “beachhead to show that we not only have great administration capabilities in HR and HCM, but also planning and C-level aspects of that solution, like talent management,” said Tobias Dosch, Senior Vice President of Business Suite Product Management “That is, by having a great capability to visualize succession planning, we might be able to sell the whole talent management suite—even the entire HR module.” HCM was a growing market (Exhibit 8) and competition in HR solutions tended to be “best-ofbreed.” Customers who were interested in succession management, for instance, purchased mainly from third party on-demand vendors specializing in the area; “they’re not looking at Oracle,” noted Dosch, making the distinction between best-in-breed and best-in suite (i.e., the entirety (back-end) of a solution like HCM). SAP had developed some talent management capabilities in its suite but these were not “very visible,” he said. “Fundamentally, we had the back end database objects for succession management for a long time,” added Ludlow. “But the user interface that sat on top of it was fairly outdated. What Nakisa offered was beautiful in its simplicity—basically they would take the org chart, write some interaction between it and these back end data objects, add some processes and actions: and boom, you’d have succession management!”

The Next Level?
As Nakisa and SAP worked through succession management development, Varjavandi was eager to deepen the connections between the two companies, even as he pursued partnerships with Microsoft, Oracle, and IBM, among others. “Whenever there was a new technology, or if SAP wanted someone to be a ramp-up for certain kinds of integration, we’d volunteer. And they’d take us up on it. For example, when SAP was doing pdk.net, the portable development kit that allowed a Microsoft-based solution to connect to SAP, SAP came to us and we said, fine, we’d build it.” Nakisa also began building solutions on the NetWeaver stack, signaling a greater technical exposure to SAP’s platform. SAP provided resources to help in such development efforts. “We saw the benefits every time we took on these projects,” Varjavandi noted. In 2006, SAP itself became a Nakisa customer when it installed its product for a global rollout to all of SAP’s HR units. Meanwhile, Nakisa was encouraged to become involved with SAP’s field (i.e., sales) activities so it could push the products being developed for SAP.

Part of the field feedback, however, related to the fact that what SAP was attempting to push was a “vision,” Ludlow said, not just products. “We found that customers, even our field executives, were saying, ‘look, to really be able to push this, we need not just what it is today but what the roadmap is. We can say this is a great product, but that speaks to the general software industry. You’re pushing a roadmap, not just a product.’ They wanted to know the next steps, that it’s not just a flash-in-the-pan relationship.” In early 2007, the Nakisa solution was certified for “Powered by NetWeaver”, which denoted that the software was now fully integrated with SAP’s platform ready to consume SAP enterprise services. Nakisa was interested in reaching the Tier 2 or Tier 1 Status. For a Tier 2 status, SAP after considerable technical due diligence would endorse the solution and engage in joint marketing
activities with partners. These solutions were referred to as “Endorsed Business Solution”. And, there were more than 25 partner solutions in that category.

SAP had around 15 Tier 1 partners, whose products were actually sold by SAP. Tier 1 and 2 levels are taken very seriously at SAP, designations that required Board approval. Sai Koppala, Senior 10

Director of Ecosystem Strategy, pointed out that unlike others in the industry that might “brag to their customers” about having huge numbers of partners, “we are more focused on customer value and industry-relevance. We have realized that in a given industry or vertical, there are a small set of solutions that we need to have tightly integrated with SAP. At the end of the day, our customers hold us to the highest standard: we provide mission-critical applications. Anything which ties into our application, and especially if we are selling it [as is the case in Tier 1 partnerships], they expect the same level of quality.”

Dosch noted that SAP and Nakisa had begun some “strategic” discussion as part of the succession planning application development. “We (SAP) thought, what are [other] strategic applications that we can do together with their capability? And that drove us into further joint planning of roadmaps.” At the same time, there was no inevitable progression in partnership development: Tier 2 did not automatically guarantee that Tier 1 status would follow. Moreover, there was no hard and fast expectations about the time involved in going through the extensive “technical due diligence” needed for qualification. Market demand, for one thing, was a big influence, as Koppala pointed out: How one becomes a Tier 1 partner is partly determined by what market demand is like—it can drive the process. In some situations, for instances, our sales force will say, hey, there’s a huge gap in a particular offering in, say, the oil and gas sector, in trading commodities. We have to have a solution to tackle that. So for the next six months to a year, we’ll look for the right partner that can provide that solution.

The Nakisa Decision
Yusuf looked out his window, realizing that afternoon had turned into evening, and that his cappuccino was now cold. Build/Buy/Partner decisions are a complex issue and Nakisa is no different. SAP chose its strategic partners on the basis of multiple, and evolving, criteria. Market demand and market size were important to determining specific needs and products, but there were also more intangible factors–how people would and could work together, for instance. A Tier 1 partnership demanded trust to ensure that joint strategy discussions, technology development, and coordination were optimal in execution, worked best for customers, and would mutually benefit the two firms.

Varjavandi had been pushing for increasing this kind of integration technologically and organizationally since the very beginning. Having access to SAP’s tens of thousands of customers was an amazing opportunity for his company. At the same time, Nakisa continued and would continue to work with Oracle, Microsoft, IBM, and others. “Oracle, for example, supports us in a lot of our sales engagements,” Varjavandi said, “but we still need to go and sell, and that’s a lengthy process.” To accommodate these other partnerships, therefore, the firm had to maintain its own sales function along with its development capability.

How “stretched” Nakisa would become was another concern. Rapid time-to-market development demanded the ability to scale. This ability was all the more critical because the kind of products Nakisa could provide were “horizontal”: they cut across industries. Any company potentially needed succession management tools, for instance. If SAP identified an opportunity for its huge installed base for a product that Nakisa would develop, could Nakisa develop it “in time”? Traditional Tier 1 partners were established players, like Adobe and Microsoft, and though not all were huge companies, they had all demonstrated their capacity to execute.

Yusuf could sense the questions the Board was going to ask: why is it strategic, what’s the upside, how does it affect the competitive landscape, and SAP’s competitive positioning? They would look at products, and of course, the potential partner’s financials. And the issue of whether the potential partner can implement would be important.

Another possibility was to invest in Nakisa via SAP’s NetWeaver Fund, whose purpose was to leverage equity investments in strategic partners. Making such an investment, of course, raised the question of actually buying a company rather than going through the apparent complexities of establishing and then maintaining a complex relationship.

Ultimately, the Nakisa matter raised issues that transcended the particular case. All Tier 1 decisions seemed to be poised on how “committed” SAP should become given the ecosystem that it was actively building as an extension of itself. No longer was a binary make/buy analysis sufficient to determine how relationships should be characterized. It now became make/buy/partner. But even that didn’t seem to do justice to what was involved. “Taking down borders” indeed, thought Yusuf, as he began to flip through the slide deck one more time and contemplate the case for Nakisa.