Organization domain: Trained software developers Hire and train software .... internet domain, a large group of third party application developers play an ...
Business model roadmapping: A practical approach to come from an existing to a desired business model Mark de Reuver, Harry Bouwman, Timber Haaker Preprint of an article published in International Journal of Innovation Management, 17, 2013, 18 pages. DOI: 10.1142/S1363919613400069 © [copyright World Scientific Publishing Company] http://www.worldscientific.com/worldscinet/ijim Abstract Literature on business models deals extensively with how to design new business models, but hardly with how to make the transition from an existing to a newly designed business model. The transition to a new business model raises several practical and strategic issues, such as how to replace an existing value proposition with a new one, when to acquire new resources and capabilities, and when to start new partnerships. In this paper, we coin the term business model roadmapping as an approach to define the transition path from a current to a desired business model. We develop our approach based on core concepts from business model literature as well as technology roadmapping. The approach is illustrated using a simplified case study. We find that visualizing business model roadmaps elicits how operational actions and business model impacts are interrelated. The merits of business model roadmapping not only lie in defining a roadmap of actions and business model changes, but also in identifying and discussing trade-offs between strategic business model issues and operational activities. Especially if an organization still has to choose between different alternative business models, business model roadmapping may help to identify overlapping paths and points of no return.
1. Introduction In a changing marketplace, organizations have to reinvent their business models regularly in order to remain competitive (Andries, Debackere, & Van Looy, 2006). Our previous work on business model dynamics has revealed that business models can change dramatically over time in response to external drivers like changing technologies and market conditions (NN, 2009). Such business model changes may be gradual, like adding new services to an existing portfolio, but may also be radical, like moving from a product to a service business model. While defining a viable business model can be challenging, especially the European school on business models has developed various practical approaches to design and test new business models (e.g., Ballon, 2007; Bouwman, Haaker, & De Vos, 2008; Gordijn & Akkermans, 2001; Osterwalder & Pigneur, 2010). However, even after a business model has been designed, the question is how to make the transition towards the new business model. Firms typically face challenges related to obstruction in case the new business model conflicts with the existing business model or existing resource configuration (Chesbrough, 2010), which raises questions like: When to start investing in new technologies? When to attract that new type of employees that are capable of dealing with new services? Moreover, firms face uncertainty on the environment and the effectiveness of a new business model (Chesbrough, 2010), which raises the question: Until when to postpone decisions to see how the market is developing, and what are points of no return? We argue that these issues can be dealt with by making a roadmap that describes the intermediate steps to realize a new business model. While roadmapping itself has been around for at least two decades (Phaal, Farrukh, & Probert, 2004; Willyard & McClees, 1987), most roadmapping approaches focus on technology development, omitting typical business model issues like service definition and dealing with other actors in the value network. Moreover, roadmapping is typically used as an ad-hoc
tool for project management and strategic planning rather than an integral part of strategy making and business model design (Hedman & Kalling, 2003). In this paper, we propose a practical approach to business model roadmapping. We define business model roadmapping as the process of developing a business model roadmap as a plan with intermediate steps achieve a desired business model B starting from a business model A. A business model roadmap is thus a description or a plan that describes what intermediate steps and critical decisions have to be taken to achieve a desired business model. Theoretically, business model roadmapping makes the link from the strategic level, on which most business model thinking focuses (Chesbrough & Rosenbloom, 2002; Osterwalder & Pigneur, 2010), to the more operational and tactical level, which is needed to translate a business model into a practical planning. Moreover, our approach contributes to the emerging stream of literature that provides scientifically grounded tooling and methods to deal with business model design, validation and testing (Bouwman, et al., 2008). Section 2 provides a theoretical background on business model design and roadmapping. Section 3 describes our business model roadmapping method including various extensions, illustrated with a simplified case study. Section 4 discusses core concerns and issues that warrant attention when applying our approach. Conclusions are drawn in Section 5. 2. Theoretical background 2.1. Business model design While most managers focused on strategic positioning in stable value chains until the 1990s, the breakthrough of Internet technologies necessitated companies to rethink and even reinvent their internal business logic (Magretta, 2002). Since then, business models have become a mainstream
concept to describe how companies create and capture value from technological innovation (Chesbrough & Rosenbloom, 2002). We define business models here as a description of how an organization or network of organizations intends to create and capture value from offering a service to its customers (Bouwman, et al., 2008). Our notion of business models goes beyond the revenue model and also includes the service being offered and the technological and organizational resource configuration that supports the offering of that service. There is a difference how American and European scholars approach the concept of a business model. The American school on business models mainly focuses on the classification of business models in specific sectors, such as the Internet (Afuah & Tucci, 2003; Rappa, 2000), but also on its use in a context of open (service) innovation (Chesbrough, 2003, 2010, 2011). Meanwhile, the European school on business models is more focused on causal modeling and design approaches. We discuss four European approaches to business model design, which may be used as a basis for business model roadmapping. Most prominent is the business model canvas, a popular tool that makes it simple for practitioners to design business models in a creative session (Osterwalder & Pigneur, 2002, 2010). Underlying this practical tool is a detailed conceptual model in which various design variables are considered. A strength but also a limitation of the business model canvas is that it focuses on one single company’s internal business model rather than a partner network. As such, when one is interested in a value network centered on a service concept rather than one specific organization, the approach is less usable. Moreover, despite the elaborate underlying conceptual model, the business model canvas as such provides little detail to the design variables and leaves much freedom to the user for interpretation. As Osterwalder explains himself, tooling for business model canvas is hardly developed (Osterwalder & Pigneur, 2010).
The approach from Ballon (2007) focuses mainly on classifying business models in taxonomical schemes. He argues that a classification of business models should be based on a set of key design parameters and a limited set of options per parameter. He proposes four levels of mobile services business models in which design parameters can be found. These are the value network level (i.e., combination of assets, the level of vertical integration, and customer ownership); functional model level (i.e., the modules and interfaces between models, distribution of intelligence within the system, and the interoperability with other systems); financial model level (i.e., the cost (sharing) model, revenue model, and revenue sharing model); and value proposition level (i.e., market positioning, user involvement and intended value). For each of these parameters, he identifies the two main options that require a trade-off and that can be used to classify business models. Although Ballon’s approach appears useful when it comes to analyzing business models on a high level of abstraction, it is not very well applicable as a design approach. The approach is high-level and does not provide practical guidelines on how to design and develop business models. E3-value methodology is especially useful to model the economic and financial aspects of business models (Gordijn & Akkermans, 2001). E3-value offers a means to model the exchange of value between the organizations in a value network. After specifying the value flows, the modeler can calculate the business case for each player in the network. Various alternative scenarios can be simulated to compare different outcomes of the business model. E3-value is thus most useful in situations in which tangible exchanges can be assessed rather accurately. Exchange of intangible values such as knowledge and information are difficult to quantify. Moreover, strategic business model issues like control over critical assets or the customer relationship are not included as E3-value focuses on the exchange relations in an operational situation.
The STOF method provides an elaborate approach to deal with business models (Bouwman et al, 2008). In contrast with Osterwalder’s business model canvas method, the STOF method takes the service as unit of analysis, and considers the network of organizations that are involved in providing that service. Moreover, the STOF method explicitly takes into account the technology design issues that often play a role in developing ICT-enabled services. Grounded in various branches of literature and building upon numerous case studies (see Bouwman et al, 2008), the STOF method provides a set of generic design issues and success factors regarding the service, technology, organization and finance domain of a business model. Critical design issues in the service domain are derived from concepts on service design (Grönroos, 1992; Vargo & Lusch, 2004), service marketing (Grönroos, 2007; Kotler, 2000), service innovation (Den Hertog, 2010) as well as user adoption (Rogers, 1962) and user experience theories (Edvardsson, Gustafsson, & Enquist, 2006; Pine & Gilmore, 1999). Besides the intended value proposition of a service, the service domain also explicates how service delivery and management may impact the expected, perceived and delivered value (Parasuraman, Zeithaml, & Berry, 1988). New service models become possible due to technology as driver (external factor) and as enabler (ecosystem internal). The technology domain specifies critical design issues on various levels of the technology architecture: (mobile and wireless) network architectures, platforms, applications and software. In addition, the technology domain requires insight into how applications are embedded in enterprise architectures of the actors in the value network. The organization domain deals with the resources and capabilities required to enable the service. These resources can be available within an organization (Barney, 1991) or at partners (Pfeffer & Salancik, 1978; Tapscott, Lowi, & Ticoll, 2000) or in the ecosystem around a firm’s platform (Perrons, 2009). When dealing with partners in a value network, critical design issues include the openness towards new partners as well as governance of relationships (Jones, Hesterly, & Borgatti, 1997). With regard to the finance domain, investment methods have to be taken into account, such as Net Present Value, Real Option theories and other
investment and risks assessment approaches (Renkema, 2000). However, for ICT-enabled services, typically network and Internet economics play a role as well (Shapiro & Varian, 1999). The financial domain focuses also on pricing schemes and revenue models. It will be clear that business model thinking as applied in the STOF model represents a multi-disciplinary background and is based in concepts and theories from several disciplines. A practical method to deal with these design issues and success factors has been developed and widely applied in dozens of real-life cases in telecom, ICT, media, independent living and energy domain (see for an overview, Bouwman et al, 2008). The STOF method gives more structure than the Business model canvas approach, as it lists a predefined set of design variables. Moreover, the STOF method has the advantage that it focuses on a specific service concept and the relevant value network that provides that service. However, the STOF method is less strict than Ballon’s approach as the answer to each design variable is not limited to a set of predefined values. The notion of critical design issues allows formulating (design) transitions for a business model roadmap. Therefore, in this paper, we choose to focus on the STOF method in order to develop our business model roadmapping approach. 2.2. Roadmapping Roadmapping has become increasingly popular during the last two decades, after its application by Motorola gained widespread attention (Willyard & McClees, 1987). Since then, several leading companies developed their own roadmapping approaches, including Lucent (Albright & Kappel, 2003), Philips (Groeneveld, 2007) and Rockwell automation (McMillan, 2003). Early publications on roadmapping mainly provide personal experience and lessons learned from people working at companies that implemented roadmapping. After that, several scholars have aimed to provide definitions and categorizations of roadmapping approaches and tools. More recently, scholars have
started to publish novel approaches to roadmapping that focus on specific areas, often illustrating these approaches with action research cases. 2.2.1 What is roadmapping? A wide variety of roadmapping approaches and tools exists (Phaal, et al., 2004). Still, one can distinguish some common elements to roadmapping. Phaal et al (2004, p. 5) define technology roadmapping as `a structured (and often graphical) means for exploring and communicating the relationships between evolving and developing markets, products and technologies over time’. Groeneveld (2007) similarly defines roadmapping as `a process that contributes to the integration of business and technology and to the definition of technology strategy by displaying the interaction between products and technologies over time, taking into account both short- and long-term product and technology aspects.’ In contrast to other management and planning approaches, roadmapping explicitly takes into account how products, technologies and markets change over time, which enables dealing with moving targets (Kappel, 2001). Generally, roadmaps help to establish the relative priority of technologies, markets and products, set targets and link them to justify investments and coordinate activities (Kappel, 2001). Albright and Kappel (2003) argue that roadmapping allows companies to link strategy, product plans and technology plans in order to define corporate-level technology plans. In addition, roadmapping would reduce time-tomarket and time-to-money and lead to better product requirement specifications (Groeneveld, 2007). Roadmaps may comprise several aspects, depending on the focus of the company or study. There is no commonly agreed set of aspects that is always considered in any roadmap. Still, typical aspects of market, product and technology are often included in a roadmap. Sometimes the process of roadmapping is considered more useful than the resulting roadmap itself (Phaal, et al., 2004). Indeed, Albright and Kappel (2003) assert that roadmapping would improve
communication and ownership of plans, and enable companies to focus on long-term planning and higher priorities. The value of roadmapping as a process to stimulate learning and cross-function communication is also underlined by Groeneveld (2007), who further argues that roadmapping can establish shared and interlinked product and technology planning. Groeneveld (2007) emphasizes that although roadmap concepts may be simple, applying this in an organization is more difficult. First of all, companies tend to underestimate the time and attention that roadmapping requires (Groeneveld, 2007). Secondly, one should safeguard that the process of roadmapping becomes common practice and is not suddenly stopped, for example in case of reorganization (Groeneveld, 2007). Thirdly, roadmapping should involve key players from all relevant business units that may play different roles through the phases of roadmapping (i.e., initiation, development and integration) (Gerdsri, Vatananan, & Dansamasatid, 2009). While dealing with multiple key players, issues of trust, cooperation and openness may become a major hurdle (Groeneveld, 2007). Kappel (2001) argues that the motivation of people to actually adopt roadmapping depends on the importance of the products, the magnitude or length of investments and whether the marketplace provides threat to existing business. In addition, roadmapping is more likely to be effective in cases in which the market or product is growing, the technology is considered the basis of competitiveness, coordination is otherwise difficult or customers voice needs to be strengthened (Kappel, 2001). Not only single companies apply roadmapping. On an alliance level, roadmapping could map technologies and licensing opportunities in open innovation context (e.g., Lichtenthaler, 2008). On industry level, industry associations may use roadmaps to align the technology agendas of their members (Kappel, 2001). Roadmapping is even applied on a society level, for example using sociotechnical roadmapping (e.g., Tuominen & Ahlqvist) or roadmapping of scientific progress (e.g., Galvin, 1998).
When applying these basic concepts to the phenomenon of business models, we can consider the business model and its underlying domains as specific aspects that are listed on a roadmap. When taking a STOF approach, the service, technology, organization and finance could be the four horizontal layers of the roadmap. 2.2.2 Existing roadmapping approaches Considering the wide variety of purposes, levels of analysis and time horizons, it is hardly surprising that companies use a wide variety of roadmapping tools and approaches in practice. According to Phaal et al (2004), organizations typically conduct roadmapping in an ad hoc self-invented approach that is discontinued after some time. Although roadmapping is often done in practice, hardly any formalized approaches exist that are commonly accepted. As a result, companies often have to reinvent roadmapping approach themselves. Phaal et al (2004) identify eight types of roadmaps: product planning, service/capability planning, strategic planning, long-range planning, knowledge asset planning, program planning, process planning and integration planning. In addition, they identify eight roadmap formats: multiple layers, bars, tables, graphs, pictorial representations, flow charts, single layers and text. Phaal et al (2006) develop a catalogue of as much as 850 management tools including roadmapping approaches, see http://www.ifm.eng.cam.ac.uk/ctm/t_cat/index.htm. In their later work, Phaal et al (2009) find a high variety and diversity of roadmap visualization approaches. Temporal roadmap forms are most commonly applied and can be clustered using two main dimensions: single theme versus multiple themes, and linear versus branched. In multiple-theme roadmaps, themes can either be separate or linked. Recently, several academics started to propose new roadmapping approaches and tools. Typically, these approaches comprise typical management tools like SWOT and strategic vision definition. The evidence
of the efficacy of the proposed approaches is typically limited to illustrative case study, often applying action research. Albright & Kappel (2003) propose several domains that corporate roadmaps should consist of: market (i.e., competitive assessment; market segmentation and trends), product (i.e., product drivers; experience curve price forecast; product roadmap; product evolution plan), technology (i.e., technology roadmap; forward costing) and summary (i.e., strategic summary; risk roadmap). Gindy et al (2008) propose a strategic technology alignment roadmapping approach including supporting software. The approach comprises several steps: strategic business drivers (i.e., defining business drivers that are aligned with company mission statement); market competitive strategy (i.e., deriving and scoring selected products to make clear the priorities); product strategy (i.e., deriving requirements for product developments); technology strategy (i.e., deriving the technologies the company should invest in); and R&D strategy (i.e. producing a project portfolio that meets the business, market and technology strategy requirements). Fenwick et al (2009) integrate marketing and decision methodologies into technology roadmapping. The steps in their approach include assessment, market analysis, services or products, technology needed for solution and roadmap links. Their approach utilizes tools and methods ranging from boardroom models to elaborate quantitative methods: SWOT, Porter’s five forces, value proposition definition, competitive features matrix, perceptual map, Delphi method, analytic hierarchy process, technology development envelope and technology roadmap. Abe et al (2009) integrate business model design and strategic roadmapping into a practical approach, comprising steps of defining the business model vision, planning business scenario and roadmapping the steps needed to be taken. Strauss and Radnor (2004) argue that roadmapping will not work in uncertain environments. As a solution, and propose `multi-scenario roadmapping’ to combine scenario planning and roadmapping as this would lead to `more robust and dynamic product technology architectures designed to fit a range of
different scenarios’ (Strauss & Radnor, 2004, p. 53). Their approach details fifteen steps that should be taken to do so, and adds four core time points to a typical roadmap:
Flex points: a point in time when conditions change that require adjustments but do not warrant a full-fledged change of strategy;
Window: a point in time when the company may continue along the roadmap most appropriate for the central scenario while watching changing conditions to see if a new scenario is actually emerging;
Fork: a point in time when a transition to a new strategy must be made;
Checkpoints: a point in time when subsequent checkpoints may be rescheduled and flex points and forks may be revised based on updated scenario.
2.2.3. Conclusions The methods used for roadmapping are highly diverse and borrow from many different disciplines. There is no commonly accepted methodological approach to construct roadmaps. The efficacy of proposed roadmapping approaches in literature is rarely supported by strong empirical evidence, and mainly based on experiences in action research. Apparently, roadmapping may use any method and approach, depending on the focus of the study. Existing approaches on roadmapping provide many opportunities, but also contain several gaps. In terms of the STOF-model, especially the Service and Organization domain of a business model are typically underdeveloped. Regarding the service domain, roadmapping literature hardly considers services and especially not ICT services (Fenwick, et al., 2009). Fenwick et al (2009) assert that Internet services require new ways of modelling finance and business, implying that technology roadmaps may fit less well. Regarding the Organization domain, most roadmapping approaches focus on single-
company level of analysis. In a value network, roadmapping may be more challenging because of multilevel issues. That is, each organization has its own roadmaps but there should also be a shared roadmap, and these have to be aligned. In addition, dealing with strategic differences and strategic behaviour may be a hurdle to overcome. However, roadmaps may in fact help collaboration by getting a shared vision and raising the commitment to start collective action (Phaal, et al., 2004). 3. A business model roadmapping approach In this section, we develop a business model roadmapping approach that combines business model design and roadmapping concepts. First, we define the core concepts underlying the approach. Next, we provide our basic step-wise approach to business model roadmapping, which is subsequently, illustrated using a simplified case study. After that, more advanced additions to the basic approach are given and illustrated. 3.1 Core concepts of business model roadmapping Business model roadmapping involves critical choices and intermediate steps in achieving a new business model. While examining these labels more closely, it appears that they in fact represent two different levels of analysis on which a business model roadmap should be considered. Business model changes The first layer consists of the changes that are made to realize the new business model. These changes can be found within each of the four domains of the STOF model (Bouwman, et al., 2008). Such business model changes may include launching a new service, implementing a new technology, involving a new partner or changing the tariff structure. Besides the desired business model changes, this layer also involves business model domains that are impacted by the desired changes. For example a choice for a new technology may impact the service
offering and/or the cost structure of a service. Therefore, the question should be asked as to what changes in other business model domains need to be made as well: what new technology, organization or finance arrangements are needed to enable effectuating the desired change in the business model? Required activities The second layer involves the activities that need to be executed in order to realize the changes in the business model domains. In most cases, an organization or value network may not have access to all resources and capabilities required to effectuate the changes in the business model. Moreover, existing resources and capabilities may become obsolete because a certain change will be made in the new business model. The translation to the activity level can be made by asking the question: what activity needs to be executed in order to enable the desired business model changes? Several activities can be taken into account in this level of analysis: technology development, partnership formation including selection, negotiation and setting up the governance structure, and making or attracting investments. Although a business model domain that needs to be changed can focus on any domain in the STOF model (e.g. on the service domain in case of a new or changed service offering, or on the finance domain in case of changing tariff structures), it can impact all domains of the STOF model, see Table 1.
Table 1: Two layers of a business model roadmap Layer in a business
Definition
Key question
Examples
model roadmap Business model change
Change in the service,
Which element(s) of
Adding more services
technological,
the business model in
to a core service
organizational or
any of the STOF
Internationalization of
financial domain of the
domains should be
service offering
organization or value
changed to enable the
New revenue model
network required to
new business model,
New technology
realize the desired
i.e. what new service,
systems
business model
technology,
Other partners
organization or finance
New competences
resources are needed
Need for new
to enable effectuating
investment funds
this change in the business model? Activities
Practical actions that
What activity needs to
Technology
need to be carried out
be executed in order
development
in order to realize the
to enable the change
Partnership formation
changes needed in the
in the business model
(i.e., selection,
business model
domain?
negotiation and setting
domains
up the governance structure) Attracting investments
3.2 A step-wise approach to business model roadmapping Business model roadmapping comprises four basic steps. (1) Identify desired changes in the business model. First, one should analyze the key differences in the business model elements between the current and the future business model. This results in a list of business model elements to be changed. For example, these changes may include the launch of new service / product, targeting a new market, putting the old service / product off the market, implementing a new technology, involving a new partner, installing a new governance structure, opening a previously closed platform technology, changing the tariff structure or revenue model. (2) Analyze the impact of the desired business model changes on other business model domains The previous step may already indicate high-level changes in service, organization, technology or finance domain of the business model. In this step, one analyzes what other business model components need to be changed to effectuate these changes, for example a new service concept relying on new technology can only be launched once the technology has been implemented. This is done by explicating which new technological, organizational or financial resources and capabilities are required to enable a specific changed element in the business model. However, one should also identify which technological, organizational or financial resources and capabilities are no longer required if for example existing services are no longer offered. (3) Translate business model changes into specific activities. In this step, the changes in resource configuration should be translated into specific activities. New resources and capabilities can be acquired in various ways: developing them within the firm, R&D projects, technology development, and recruiting new personnel. But also in partnering with firms that
have access to core resources and capabilities. It should be noted that the resource configuration alteration may also involve the ending of existing resources and capabilities, e.g. downsizing specific departments that support the old product or outsourcing R&D work. This step also involves assessing impact of these choices on the value network: What relationships have to be formed, which have to be ended, which need to be altered? Note that the above steps already define the interdependency between business model changes and practical activities. In this step, one should define how long the specific activities are expected to take. (4) Back-casting of ideal transition path Based on the list of actions, duration per action, interdependencies between actions and the ultimate deadline for the new business model to be developed, backcasting can be executed to map the actions into a roadmap that may be visualized in a graph. The figure should clearly define the relation between the actions. As attributes for the activities, one may indicate the criticality of that choice, for example indicating if it creates path dependencies or not. For each of the changes and activities, it should be analyzed how critical they are: Are they irreversible, i.e. can they be undone? Are they necessarily followed by activities that require large investments? Which choices still leave room for going back to the original business model or an alternative business model? For example, closing down a specific department is hard to undo. But also reducing the tariff structure in an oligopolistic market is difficult to undo. At the same time, specific choices may be critical because if they are not taken then it cannot be redone in the future, similar to real options reasoning. 3.3. Illustration with simplified case study
We now illustrate the approach with a simplified case study. Terribles is the name of an SME that provides a service platform in the dance industry. Dance club visitors can rate clubs and submit their
report to Terribles. Terribles award a number of stars to dance clubs, based on these reports. Terribles provides a website with information about the dance clubs, events, live streaming of shows, etcetera. Recently, they also launched a social media website on which club visitors can interact with each other, and they are launching all kinds of additional services like mobile payment and ticketing. Currently, they are on the verge of adding more services to their basic service portfolio, and expanding their service portfolio to foreign countries. Terribles has a lot of partnerships with dance clubs from which they receive content. (1) Identify desired change in the business model The desired change in this case is internationalization, that is: Terribles desires to launch the same core service bundle in foreign markets. Basically, the high-level desired change in the business model therefore lies in the service domain: extension of the target group. (2) Analyze the impact of the desired business model changes on other business model domains The next step is to analyze how the desired internationalization and extension of the target group impacts other business model domains. The following implications are identified, see Table 3. Table 3: Business model roadmapping: Illustration Terribles case Business model change
Explanation The brand of Terribles is currently unknown in foreign countries. Therefore, the brand of Terribles needs to gain international
Service domain: International branding
recognition.
Currently, the content on the website is only in Technology domain: Multi-lingual website
Dutch, and this should be translated Internationalization requires more efforts to maintain the website as more content will be provided. Therefore, more software developers
Organization domain: Trained software developers are needed at the company Content about the foreign dance clubs needs to Organization domain: Access to foreign content
be added to the website. To get access to foreign content, partnerships
Organization domain: Partnerships with foreign
are needed with local clubs in the foreign
players
countries.
(3) Translate business model changes into specific activities. Each of these business model changes can be translated into specific activities that need to take place, see Table 4. It should be noted that these activities are not necessarily unique. For example, capital investment can also be achieved by getting a bank loan. Table 4: Business model roadmapping: Illustration Terribles case Business model change
Activities required to enable the changes
Service domain: International branding
Marketing and promotion in foreign market
Technology domain: Multi-lingual website
Translate website material
Organization domain: Trained software developers Hire and train software developers
Attract capital from VCs Organization domain: Access to foreign content Organization domain: Partnerships with foreign players
Form partnership with local players
(4) Back-casting of ideal transition path Next, we assess the interdependency between the activities. The hiring and training of software developers needs to be done before automation of the software platform can be done. Before hiring these software developers, the capital is needed to do so. Marketing and promotion in foreign market can only be done once the material is translated, and probably it is smart to coordinate marketing with the foreign local players, so this activity also relies on formation of partnerships first. It should be noted that here, the sequencing of the activities may be debatable. By drawing the roadmap in Figure 2, the objective is rather to make the trade-offs on how to sequence the activities.
International branding
Service
Business model change
Multi-lingual website
Technology
Organization
Extension of target group: Internationalization
Partnerships with foreign players
Trained software developers
Access to foreign content Finance
Activities
Attract capital from VCs Form partnership with local players
Hire and train software developers Translate website material Marketing and promotion in foreign market
Figure 2: Business model roadmap for simplified Terribles case Internationalization
3.4 Extensions to the basic method 3.4.1 Dealing with multiple business model roadmaps
Of course, in many cases there are multiple alternative business models possible. Such alternative business models may be tested on their viability (e.g., how they score on critical success factors), robustness (e.g., how they score on different future scenarios). However, in case of severe uncertainty about the future, such tests may not lead to one business model that outperforms all others. In that case, multiple business model roadmaps can be generated to identify how these roadmaps overlap and conflict. First, for each alternative business model, the standard steps from business model roadmapping should be applied. Next, we propose the following. (1) Identify overlap and conflicts between the activities What actions from business model A are at odds with the actions from business model B? Which actions are the same for both business model roadmaps? What actions obsolete actions from an alternative business model? The actions from the two business models considered should be compared in a structured manner to identify which ones are at odds with each other. (2) Identify overlapping paths in the business model roadmaps. Based on the analysis of similarities in actions and obsoletes, one can identify bypass routes. Specifically, one should consider which paths of the business model roadmaps overlap. Especially at the start of a transition, similar actions may be relevant to be taken. As such, one can postpone the choice for a specific business model to a later point in time.
(3) Consolidate the ideal transition paths The proposed additional steps could even be broader: if there are multiple value propositions that each have their own business model and roadmap, one could try to find synergies between these roadmaps. In the example of the Terribles case, an alternative business model is possible that does not rely on partnerships with foreign players, see Figure 3. Content about foreign dance clubs may also be obtained through automated data mining in a way comparable to what Google does. Although the quality of automatically generated content may be lower, it makes the roadmap less reliant on partnerships with foreign players. In this alternative business model, the business model change and activity relating to partnerships with foreign players are replaced by a change and activity relating to automation of the software platform. The visualization of the roadmap below shows that this small change has large implications for the order in which activities can be executed, and consequently, the order in which business model changes can be achieved.
Business model change
Extension of target group: Internationalization
International branding
Service
Technology
Organization
Multi-lingual website Trained software developers
Automated content generation Access to foreign content
Finance
Hire and train software developers
Activities Attract capital from VCs
Developing content mining and generation tools
Translate website material Marketing and promotion in foreign market
Figure 3: Alternative business model roadmap for simplified Terribles case Internationalization
3.4.2 Other optional steps Specify when roadmap should be reconsidered or stress testing needs repeated Specific points in the resulting figure should be defined in which the roadmap towards the desired business model should be reconsidered. Typically, the most critical actions should be highlighted as possible points for reconsideration. One should also define if and when stress testing against uncertainties may be executed again. Of course, it may also be that the endpoint of the roadmap, that is, the desired business model, has to be reconsidered from time to time. Identify relation between uncertainties and the actions Typically, specific uncertainties may develop such as to drive certain changes in the business model. Similarly, a specific development in the environment may obsolete or necessitate a specific action to be taken. For instance, the development of a superior new technology may obsolete the R&D program. 4. Discussion: Core issues in business model roadmapping We are aware that there may be several points of concern when applying our business model roadmapping approach in practice, which may be considered as limitations to our approach. First, as strategy is partly emergent, creativity should be maintained in an innovation process. A roadmap should therefore not become a bureaucratic tool but should leave room for (open) innovation. Especially in the case of platforms around which ecosystems evolve, such as the app stores in the mobile internet domain, a large group of third party application developers play an important role in innovation. In this case, the business model roadmap should make explicit what part of the business model is left open for complementors to change along the way.
Secondly, the ambitions for business model roadmapping have to be set realistically. The objective of business model roadmapping may range from high-level plans to elicit key choices and trade-offs towards detailed plan that can be executed as a project management tool. The extent of uncertainties and the time horizon plays a role here: uncertainties may be so great and technological architecture may be so far from the desired state, that it seems impossible to arrive at a detailed planning of the activities that need to be done. Another issue that influences the ambition level for business model roadmapping is the control that organizations actually have on desired changes in the business model: full determinism and a false suggestion of full discretion should be avoided. Finally, when putting our method into practice, various questions emerge regarding the process of business model roadmapping. For example, when to involve which persons or departments within the organization is an important issue. How to deal with conflicting interests and perceptions regarding the actions and criticality of actions is also a likely issue. For example, marketers often have a shorter time horizon than R&D staff. Probably, appointing a designated person in the organization to implement and maintain the business model roadmapping process is important. 5. Conclusions and future research In this paper we have introduced the concept of Business Model Roadmapping and provided an illustrative example. We distinguish two layers: the business model layer which defines the required changes in the business model and the activities layer which defines the actual activities to be executed. The process of business model roadmapping involves four core steps: identify the desired change in the business model, analyzing how these desired changes impact other business model domains, the translation in executable actions, and back-casting transition paths. While business modeling is often on a very strategic level, business model roadmapping makes the link to the more tactical and operational levels. The implication of this is that activities in the business model
roadmap may become quite operational, like translating website material in the simplified example case. However, making the link to such more operational level of analysis is crucial to bridge the gap from a current to a future business model. Theoretically, we thus connect business model concepts to roadmapping concepts from long-range planning and forecasting field. The practical need for business model tooling is clear, as, in our experience, companies that have designed a new business model often ask us: now what? There is a clear need for tooling and practical approaches to deal with business models. While the advantage of the popular business model canvas approach is that it can be done in one afternoon, this is also its disadvantage: what to do after that? Our business model roadmapping approach thus extends the typical business modeling approaches. In this paper, we highlighted core issues and limitations with regard to business model roadmapping, for instance where to focus on when planning, how to leave space for creativity, what with the old business model, how to manage the implementation process, and how to define the time horizon, furthermore questions like the degree to which activities are under control of the core actor. In general we would suggest leaving room for innovation and creativity, both within the organization but also at partners or complementors. Moreover, the switch between the old and new business model should be included as a specific point in the business model roadmap. Like in normal business model analyses and design it makes sense to embed business model roadmapping in the organization by assigning a responsible person and by involving different disciplines and stakeholders in the process. The proper time horizon can be discussed with this interdisciplinary team. Finally we advise to list limitations and uncertainties of the business model roadmap, and to evaluate the robustness of a business model roadmap in different future scenarios. In general, we can conclude that a business model roadmap helps to operationalize what decisions to take in which order. Visualizing roadmaps elicits how operational actions and business model impacts
are related. Alternative approaches can be described, enabling also reflection on what the impact on strategic choices is. This paper paves the way for further work on how business models change over time, and how such change can be visualized in business model roadmaps. The complexity of the example case is low, and the discussion is high level. We are aware that in practice decisions are interrelated, that an organization has multiple business models, and that specific business models are supported by multiple actors. As such, we suggest that the merits of business model roadmapping not only lie in designing a roadmap of actions and business model changes, but also in identifying and discussing trade-offs on both the business model and activity level.
References Abe, H., Ashiki, T., Suzuki, A., Jinno, F., & Sakuma, H. (2009). Integrating business modeling and roadmapping methods-The Innovation Support Technology (IST) approach. Technological Forecasting and Social Change, 76(1), 80-90. Afuah, A., & Tucci, C. (2003). Internet Business Models and Strategies. Boston McGraw-Hill. Albright, R. E., & Kappel, T. (2003). Roadmapping in the corporation. IEEE Engineering Management Review, 31(3), 32-32. Andries, P., Debackere, K., & Van Looy, B. (2006, October 5). Effective business model adaptation strategies for new technology-based ventures. Paper presented at the 9th PREBEM Conference on Business Economics, Management and Organization Science, Amersfoort, The Netherlands. Ballon, P. (2007). Business modelling revisited: the configuration of control and value. info, 9(5), 6-19. Barney, J. (1991). Firm Resources and Sustained Competitive Advantage. Journal of Management, 17(1), 99-120. Bouwman, H., Haaker, T., & De Vos, H. (2008). Mobile service innovation and business models: Springer. Chesbrough, H. (2003). Open Innovation - The New Imperative for Creating and Profiting from Technology. Boston, Massachusetts: Harvard Business School Press. Chesbrough, H. (2010). Business Model Innovation: Opportunities and Barriers Long Range Planning, 43(2-3), 354-363. Chesbrough, H. (2011). Open Service Innovation. San Francisco Josset Bass: A Wiley Imprint. Chesbrough, H., & Rosenbloom, R. S. (2002). The role of the business model in capturing value from innovation: evidence from Xerox Corporation's technology spin-off companies. Industrial and Corporate Change, 11(3), 529-555. Den Hertog, P. (2010). Managing Service Innovation. Firm-level dynamic capabilities and policy options. PhD thesis, University of Amsterdam, Amsterdam.
Edvardsson, B., Gustafsson, A., & Enquist, B. (2006). Success Factors in New Service De-velopment and Value Creation through Services. In D. Spath & K.-P. Fähnrich (Eds.), Advances in Service Innovations (pp. 3-16). Berlin: Springer. Fenwick, D., Daim, T. U., & Gerdsri, N. (2009). Value Driven Technology Road Mapping (VTRM) process integrating decision making and marketing tools: Case of Internet security technologies. Technological Forecasting and Social Change, 76(8), 1055-1077. Galvin, R. (1998). Science roadmaps. Science, 280(5365), 803. Gerdsri, N., Vatananan, R. S., & Dansamasatid, S. (2009). Dealing with the dynamics of technology roadmapping implementation: A case study. Technological Forecasting and Social Change, 76(1), 50-60. Gindy, N., Morcos, M., Cerit, B., & Hodgson, A. (2008). Strategic technology alignment roadmapping STAR® aligning R&D investments with business needs. International Journal of Computer Integrated Manufacturing, 21(8), 957-970. Gordijn, J., & Akkermans, H. (2001). Designing and Evaluating E-Business Models. Intelligent Systems 4. Groeneveld, W. (2007). Roadmapping integrates business and technology. Research-Technology Management, 50(6), 49-58. Grönroos, C. (1992). Service Management and Marketing: Managing the Moment of Truth in Service Competition. Lexington: Lexington books. Grönroos, C. (2007). Service Management and Marketing: Customer Management in Service Competition. Chichester: John Wiley and Sons. Hedman, J., & Kalling, T. (2003). The business model concept: theoretical underpinnings and empirical illustrations. European Journal of Information Sciences, 12, 49-59. Jones, C., Hesterly, W. S., & Borgatti, S. P. (1997). A General Theory of Network Governance: Exchange Conditions and Social Mechanisms. The Academy of Mangement Review, 22(4), 911-945.
Kappel, T. A. (2001). Perspectives on roadmaps: how organizations talk about the future. The Journal of Product Innovation Management, 18, 39-50. Kotler, P. (2000). Marketing Management - International Edition - The Millennium Edition. Upper Saddle River, New Jersey: Prentice-Hall. Lichtenthaler, U. (2008). Integrated roadmaps for open innovation. Research-Technology Management, 51(3), 45-49. Magretta, J. (2002). Why Business Models Matter. Harvard Business Review, 80(5), 86-92. McMillan, A. (2003). Roadmapping-agent of change. IEEE Engineering Management Review, 31(3), 4242. NN. (2009). Anonimized for purposes of anonymous reviewing. International Journal of Electronic Business. Osterwalder, A., & Pigneur, Y. (2002, June 17-19). An e-Business Model Ontology for Modeling eBusiness. Paper presented at the 15th Bled Electronic Commerce Conference, Bled, Slovenia. Osterwalder, A., & Pigneur, Y. (2010). Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers: John Wiley and Sons. Parasuraman, A., Zeithaml, V., & Berry, L. (1988). SERVQUAL: a Multiple Item Scale for Measuring Consumer Perceptions of Service Quality. Journal of Retailing, 64(1), 168-174. Perrons, R. K. (2009). The open kimono: How Intel balances trust and power to maintain platform leadership. Research Policy, 38(8), 1300-1312. Pfeffer, J., & Salancik, G. R. (1978). The external control of organizations: A Resource Dependence Perspective. New York: Harper & Row. Phaal, R., Farrukh, C. J. P., & Probert, D. R. (2004). Technology roadmapping--A planning framework for evolution and revolution. Technological Forecasting and Social Change, 71(1-2), 5-26.
Phaal, R., Farrukh, C. J. P., & Probert, D. R. (2006). Technology management tools: concept, development and application. Technovation, 26(3), 336-344. Phaal, R., Farrukh, C. J. P., & Probert, D. R. (2009). Visualising strategy: a classification of graphical roadmap forms. International Journal of Technology Management, 47(4), 286-305. Pine, J., & Gilmore, J. (1999). The Experience Economy. Boston. Rappa, M. (2000, 13 February 2006). Business models on the web Retrieved 23 February, 2006, from http://digitalenterprise.org/models/models.html Renkema, T. (2000). The IT Value Quest: How to Capture the Business Value of IT-Based Infrastructure: John Whiley. Rogers, E. M. (1962). Diffusion of Innovations. New York: The Free Press. Shapiro, C., & Varian, H. (1999). Information rules: A strategic guide to the network economy. Boston, Massachusetts: Harvard Business School Press. Strauss, J. D., & Radnor, M. (2004). Roadmapping for dynamic and uncertain environments. Research Technology Management, 47(2), 51-58. Tapscott, D., Lowi, A., & Ticoll, D. (2000). Digital Capital - Harnessing the Power of Business Webs. Boston: Havard Business School Press. Tuominen, A., & Ahlqvist, T. Is the transport system becoming ubiquitous? Socio-technical roadmapping as a tool for integrating the development of transport policies and intelligent transport systems and services in Finland. Technological Forecasting and Social Change, 77(1), 120-134. Vargo, S., & Lusch, R. (2004). Evolving to a new dominant logic for marketing. Journal of Marketing, 68(1), 1-17. Willyard, C. H., & McClees, C. W. (1987). Motorola’s technology roadmap process. Research Management, 30(5), 13-19.
