Content uploaded by Ilia Bider
Author content
All content in this area was uploaded by Ilia Bider on Sep 17, 2018
Content may be subject to copyright.
The final version has been printed and copyright by Springer in: BIR 2018, LNBIP V. 330, 2018
Defining Transformational Patterns for Business Model
Innovation
Ilia Bider & Erik Perjons
DSV, Stockholm University, Stockholm
{ilia|perjons}@dsv.su.se
Abstract. The pace of changes in the business environment in which a modern
enterprise operates requires the enterprise to constantly review its business mod-
els in order to survive and prosper in the dynamic world. This exploratory study
investigates how to help the enterprise to innovate their business models based
on the concepts of fractal enterprise model and transformational patterns. The
paper suggests an approach to Business Model Innovation (BMI) where the focus
is on transformational patterns. It discusses the structure of such patterns, and
based on examples, it presents an approach on how such patterns can be derived
from cases of completed business transformations.
Keywords: business model, innovation, strategy, business transformation, pat-
tern, enterprise modelling, fractals.
1 Motivation
In the dynamic world of today, enterprises need to be innovative not only in the line of
products and services they offer, but also in who they are and what they do, i.e. under
which Business Models they operate. This is needed in order to survive in the turbulent,
technology driven business environment and/or exploit the opportunities for growth,
emerging due to the changes in the environment. For example, in the future, a tradi-
tional manufacturing company may not be able to continue its business as usual, i.e.
designing and manufacturing their own products, due to the emergence of mature 3-D
printing. Instead, the company may need to change its business model, for example,
becoming a designer while letting the customer 'print' the design in the place convenient
for the customer, or becoming a manufacturer, providing the customer with a service
to 'print' somebody else's design (having both alternative could do as well). This change
could be more radical than adding a new product or service to the company's offerings.
In light of the increasing pace of changes in the business environment, it is not a
surprise that the topic of Business Model Innovation (BMI) got attention from both
practitioners and researchers. This interest is visible in numerous research publications,
including books [1] and special issues of journals. [2]. According to the classification
suggested in [3], there are three ways of innovating a Business Model (BM):
1. Industry model innovation - which amounts to change the position in value change,
entering new markets, and/or other type of radical changes.
2. Revenue model innovation - which results in changes in how a company generates
revenues, e.g. reconfiguring offerings and/or introducing new pricing models.
3. Enterprise model innovation – which involves innovating the structure of an enter-
prise, such as enterprise goals, business processes, products and/or services
In this paper, we focus exclusively on the first type of BMI, i.e. industry model inno-
vation. Note, however, the three types are not independent, but can interweave. This
especially concerns the industry model innovation, as, for example, entering a new mar-
ket may require changes in the existing revenue model as well as the enterprise model.
From the strategic perspective, the industry model innovation corresponds to changing
the doctrine [4], i.e. who we are, which is the highest level of strategic decision making.
From the field of engineering invention [5], it is well known that over 90% of in-
ventions do not propose anything new, but suggest new combinations of known ideas,
or exploiting known ideas in new domains. Based on this fact, Altshuller created a
method called TRIZ [5] that "industrializes" invention in the field of engineering by
making use of recurrent problems and solutions across industries. In the same way, an
enterprise that needs or wants to change its BM does not need to invent a new model
but can follow a proven example invented by somebody else.
A number of research papers is devoted to designing tools that could help the
decision makers to successfully innovate their BMs. Some of these works suggest
standardized procedures for innovation, for example, [6] suggest a procedure to use
analogies when innovating a business model. Other works [7,8] suggest using patterns
as help in designing a new business model. Patterns can be on the highest level as in
[7], or on the level of elements of the business model, as in [8].
When designing a new business model for an already existing enterprise, it makes
sense to take into account and to utilize already existing enterprise structures and
elements. Designing a new BM completely unconnected to the existing enterprise does
not make sense, as it might be easier to create a new company in this case instead of
transforming the old one.
An enterprise has several strategic layers [4]; any of them or a combination can be
used as a starting point for innovating a business model. According to [4], the highest
strategic layer is the doctrine, i.e. who we are (mentioned above), followed by the layer
of capability/infrastructure. The other two strategic layers are grand strategy, e.g.
choice of a sector or strategic alliances, and strategy as such, which is defined as a
structural coupling to the elements of environment, e.g. competitors, partners,
customers, markets, etc. In this paper, we will mostly consider the layer of
capability/infrastructure as a starting point for innovating a business model of an
existing enterprise. In this case, the innovation consists of reconfiguring capabilities,
including the infrastructure, for a new strategic direction. This corresponds to the idea
of destruction (of an old model) and creation (of a new one) by reconfiguring the
existing elements, as suggested in [9].
The research reported in this paper aims at creating a procedure that facilitates busi-
ness model innovation based on transformational patterns. The usage of concept of pat-
tern in our approach is different from other works that exploit patterns in BMI, e.g.
[7,8]. In the latter works, patterns are used to design a new business model. Our patterns
are used to find a way to transform an existing business model. As it has been mentioned
above, we mostly consider transformations that are based on existing capabilities and
infrastructure. This type of transformation requires depicting existing capabilities/ in-
frastructure in some form.
Currently, a business model is depicted using some kind of a canvas, e.g. as
suggested in [7]. Such a model may not reveal all capabilities existing in the enterprise,
and thus it is not very useful for the sake of transformation. Therefore, we are not using
a canvas type of enterprise model, but a more powerful enterprise model that can reveal,
if not all, but the essential capabilities of the enterprise in question.
The enterprise model we use for transformational purpose is called a Fractal
Enterprise Model (FEM). It was first introduced at PoEM 2012 [10], and then extended
and improved in [11]. FEM has a form of a directed graph with two types of nodes
Processes and Assets, where the arrows (edges) from assets to processes show which
assets are utilized by which processes and arrows from processes to assets show which
processes help to have specific assets in healthy and working order. The arrows are
labeled with meta-tags that show in what way a given asset is utilized, e.g. as workforce,
reputation, infrastructure, etc., or in what way a given process helps to have the given
assets “in order”, i.e. acquire, maintain or retire the assets.
A FEM model is built recursively by using a so called unfolding procedure and two
types of archetypes: process-assets archetypes that show which kind of assets might be
needed for running a process, and an asset-processes archetype that shows which pro-
cesses are needed to maintain an asset in order. Unfolding starts with a primary process,
a process that delivers value to a customer/beneficiary, by applying process-assets ar-
chetypes and alternating them with the asset-processes archetype.
Both assets and processes represent capabilities that exists in the enterprise and can
be used as a basis for a transformation. A major organizational change would result in
changing FEM. A change that corresponds to an industry model innovation would re-
sult in appearing nodes for new primary processes that substitute or complement the
old ones. A part of a FEM graph that corresponds to a new primary process would use
assets and processes that already exist in the old FEM, though some modification can
be made in them. This reuse of nodes from the old FEM in a new one represents em-
ployment of the existing capabilities during industrial business model innovation.
The idea of using FEM for business model transformation was first presented in [12],
but without any technical details on the transformational procedure and transforma-
tional patterns. A more recent publication [13] sets a research agenda for converting the
idea from [12] into a practically useful procedure. The agenda consists of several items,
including defining transformational patterns (archetypes), and providing computerized
tools support. The current paper aims at making a step in fulfilling the research agenda
by defining a possible structure of a transformation pattern, and presenting examples of
such patterns.
The rest of the paper follows the following structure. In Section 2, we give an over-
view of the related literature. In Section 3, we present a short description of FEM. In
Section 4, we discuss our research approach. In Section 5, we demonstrate a way for
analysis of examples of BMI. In Section 6, we discuss the structure of transformational
patterns. In Section 7, we present another transformational pattern, also built based on
a BMI example. Section 8 contains concluding remarks and plans for the future.
2 An additional literature overview
There is a sizable body of literature devoted to BMI in addition to what has already
been reviewed in Section 1. The book by [1] provides a systematic review of this lit-
erature. The works that are related to the current research belong to the area Tools and
Processes for BPI. According to [1], "overall, research on the BMI process is still in its
infancy and more work is needed in all respects". Still, there are a number of researchers
working in this area. Below, we review some works related to our research that repre-
sent the main directions in the area of tool and processes for BMI.
The idea of experimentation starting from the existing BM and trying to reconfigure
it is expressed in [14]. This work proposes using the business model canvas [7] as an
enterprise model to start experimentation. Moreover, it does not suggest any systematic
way for experimentation, therefore, the experimentation remains on the ad-hoc level.
We are also promoting the idea of experimentation. However, we suggest the use of a
richer enterprise model as well as a more systematic way for experimentation by apply-
ing transformational patters to the existing model.
The ideas of using the experience of others, so-called best practices, is promoted by
a number of researchers. For example, [6] suggest a procedure (process) called BMI by
analogy that consists of finding cases of BMI and reinterpreting them so that the ideas
can be applied in a certain business. In our work, we exploit the idea of analogy implic-
itly; namely, we suggest (1) having a library of cases instead of scanning the environ-
ment for them each time, (2) pre-interpreting the cases by increasing the level of ab-
straction in the case description, thus converting them into transformational patterns.
Another way of using best practices is by using a library of patterns to be used in the
BMI process. Two directions of using patterns can be found in the literature. The first
direction is having a pattern of overall composition of a business model, as in [7] where
five general BM patterns are defined. The second direction is introducing patterns for
individual components of a BM, as suggested in [8]. In both directions, patterns are
used for designing a new BM. Our aim of using patterns is different, we suggest using
transformational patterns to get an idea for changing/complementing an existing BM.
After the new idea has been chosen, the non-transformational patterns can be applied.
Summarizing the short literature overview above, we can conclude:
The research area of tools and processes for BMI is a relatively new field which
requires attention from the researchers.
Our approach uses some of the already known ideas, like experimentation, analogy
and patterns. However, it implements and combines these ideas in a different way,
i.e. use a richer business model as well as transformational patterns.
3 Fractal Enterprise Model
The Fractal Enterprise Model (FEM) includes three types of elements: business pro-
cesses (more exactly, business process types), assets, and relationships between them,
see Fig. 1 in which a fragment of a model is presented. The fragment is related to a
hypothetic company that sells books over the Internet. Graphically, a process is repre-
sented by an oval, an asset is represented by a rectangle (box), while a relationship
between a process and an asset is represented by an arrow. We differentiate two types
of relationships in the fractal model. One type represents a relationship of a process
“using” an asset; in this case, the arrow points from the asset to the process and has a
solid line. The other type represents a relationship of a process changing the asset; in
this case, the arrow points from the process to the asset and has a dashed line. These
two types of relationships allow tying up processes and assets in a directed graph.
In FEM, a label inside an oval names the given process, and a label inside a rectangle
names the given asset. Arrows are also labeled to show the type of relationships be-
tween the processes and assets. A label on an arrow pointing from an asset to a process
identifies the role the given asset plays in the process, for example, workforce, infra-
structure, etc. A label on an arrow pointing from a process to an asset identifies the way
in which the process affects (i.e. changes) the asset. In FEM, an asset is considered as
a pool of entities capable of playing a given roles in a given processes. Labels leading
into assets from supporting processes reflect the way the pool is affected, for example,
a label acquire identifies that the process can/should increase the pool size.
Fig. 1. A fragment of a FEM from [13]
Note that the same asset can be used in two different processes playing the same or
different roles in them, which is reflected by labels on the corresponding arrows. It is
also possible that the same asset can be used for more than one role in the same process;
in this case, there can be more than one arrow between the asset and the process, but
with different labels. Similarly, the same process could affect different assets, each in
the same or in different ways, which is represented by the corresponding labels on the
arrows. Moreover, it is possible that the same process affects the same asset in different
ways, which is represented by having two or more arrows from the process to the asset,
each with its own label.
In FEM, different styles can be used for shapes to group together different kinds of
processes, assets, and/or relationships between them. Such styles can include using
dashed or double lines, or lines of different thickness, or colored lines and/or shapes.
For example, a dashed border of an asset (see the asset “Excellent technical platform
based on customer experience” in Fig. 1) points to the asset being intangible opinion of
stakeholders. A diamond start of an arrow from an asset to a process means that the
asset is a stakeholder of the process (see the arrows “Workforce” in Fig. 1).
Labels inside ovals, which represent processes, and rectangles, which represent as-
sets, are not standardized. They can be set according to the terminology accepted in the
given domain, or be specific for a given organization. Labels on arrows, which repre-
sent the relationships between processes and assets, however, can be standardized. This
is done by using a relatively abstract set of relationships, like, workforce, acquire, etc.,
which are clarified by the domain- and context-specific labels inside ovals and rectan-
gles. Standardization improves the understandability of the models.
To make the work of building a fractal model more systematic, we introduced ar-
chetypes (or patterns) for fragments from which a particular model can be built. An
archetype is a template defined as a fragment of a model where labels inside ovals
(processes) and rectangles (assets) are omitted, but arrows are marked. Instantiating an
archetype, means putting the fragment inside the model and labeling ovals and rectan-
gles; it is also possible to add elements absent in the archetype, or omit some elements
that are present in the archetype.
We introduce two types of archetypes, process-assets archetypes and asset-processes
archetypes. A process-assets archetype represents which kind of assets that can be used
in a given category of processes. An asset-processes archetype shows which kinds of
processes are aimed at changing the given category of assets.
Note that the fractal model does not represent direct relationships between business
processes, such as generalization or composition. On the level of abstraction accepted
for FEM, a process with all its possible sub-processes is considered as one process.
4 The research approach
The research presented in this paper belongs to the Design Science (DS) paradigm,
[15,16,17], while we use an approach suggested in [18]. Using DS is natural for this
research, as the objective is to develop a way of depicting and using transformational
patterns for BMI, as well as creating a library of such patterns. The problem the research
addresses is that, currently, BMI (at least, industry model innovation) is done in an ad-
hoc manner based on experience and intuition, which may result in a new BM that is
too costly, difficult, or impossible to implement. The proposed solution, or artifact in
terminology of [15], is transformational patterns that could be applied to a FEM-based
enterprise model.
The development of a solution for the problem defined above requires both (a) de-
fining a structure of a transformational pattern, and (b) creating a sizable library of such
patterns. An appropriate approach for both tasks is analyzing examples/cases of trans-
formations of the industry model innovation type, successful and unsuccessful, from
the international enterprise practice. Information of such transformations can be found
in different sources, like books, Internet, and our own practice. The analysis and build-
ing of a pattern are envisioned as consisting of the following steps:
1. Build a relevant fragment of FEM before the transformation
2. Build a relevant fragment of FEM after the transformation
3. Relate elements of these two models showing which elements of the original model
have been used in the transformed model and how they have been change during the
transformation
4. Abstract from the details of the given case creating a transformational pattern
5. Finding other examples of transformation that fit the constructed pattern
The analysis of a specific transformational example/case can be done in different ways,
dependent on the amount of information available about the example. In the best case,
information can be available on the rationale behind the transformation, and details on
how it has been decided upon and completed. This will help to better understand the
logic of transformation to be presented in a transformational pattern. In a less favorable
case, only the business activities before and after transformation are known, but not
how the decision has been made. In such a case, we can just make logical analysis when
comparing FEM before and after transformation, deriving the rationale behind the
transformation based on the analysis and imagination. Whether this rationale corre-
sponds to the decision making in the case or not is less important, as long as our analysis
can result in defining a transformation pattern and finding other examples of its appli-
cation. In the following sections, we will analyze both types of transformation cases.
5 Reverse engineering of a transformational case
In this section we will use an example from [13] to demonstrate our approach for ana-
lyzing examples/cases. The example corresponds to the transformation completed by
Amazon when it created a new business – Amazon Web Services (AWS) - in 2006. The
new business was created [19] to complement the main business of selling books over
Internet. As we do not know the exact rationale behind this transformation, we just
create the relevant fragments of FEM before and after transformation and analyze the
relationships between the elements of these two FEMs.
The two FEMs and the relationships are presented in Fig. 2. The FEM fragment that
corresponds to book sells over the Internet is represented on the left-hand side of Fig.
2; actually, it repeats the fragment depicted in Fig. 1. The right-hand site of Fig. 2 de-
picts a FEM fragment related to the new business – AWS. The (green) dashed arrows
between the elements of these two FEM's show the relationship between these ele-
ments, the labels on the arrows indicating the difference between these elements.
The main idea of the transformation is to lease the internal IT platform to external
customers. Thus, the cornerstone of the transformation is the asset IT platform for work-
shop deployment. This asset represents also a capability of maintaining such a platform,
including updates, scaling up the power, etc.; this capability is represented by the whole
graph that "hangs" on this asset, see Fig. 2. This asset plays a role of Technical & in-
formational infrastructure in the Books sales process, which is indicated by the label
on the arrow going from this asset to the process. In the new FEM it also plays the role
of infrastructure, but the nature of the main process is completely different – platform
as a service. Though we do not know the actual rationale of the transformation, we can
imagine one as follows:
We are maintaining a powerful IT platform for our own needs, and the market for
IT platform as a service is growing. We could use our platform capability to enter
this market.
The FEM on the right hand side of Fig. 2 is built based on this rationale. To ensure that
the transformation is feasible, we need to compare the new FEM with the old one to
see what assets and capabilities from the old business could be employed in the new
one. The analysis follows below:
Beneficiary (customers). Customers for the new business are different from the old
one. However, the decision makers of the new kind of customers, can be assumed to
be book readers (at least some of them), which increases the chance that they have
used the original main process for buying books. In this case, they have the firsthand
experience of using Webshop software and the IT platform behind it. Therefore, a
reputation of having software that is reliable and efficient can be used for acquiring
new customers. This thinking is depicted in Fig. 2 by using the reputation asset from
the left-hand side of Fig. 2 to underpin the sales process in the new business.
Technical & informational infrastructure - the platform itself. For the book sales
business, the infrastructure needs to contain only the components, e.g. database en-
gines, webservers, etc., that are used by the Workshop software. For the AWS busi-
ness the platform should be more general, e.g. include different database engines.
This is depicted as a label that connects the infrastructure assets from two FEMs in
Fig. 2.
Managing processes for IT platform. The processes for maintaining the IT platform
asset - Acquire, Maintain and Retire - also have different characteristics. For the
internal use, acquiring a new platform and dismantling the old one can be planned
in advanced and performed at regular speed. For the new business, this should be
done quickly, i.e. as soon as the customer defines what platform is needed, it should
be immediately created. When the customer no longer needs the platform, it should
be dismantled to free the resources. This is depicted in labels that connect the man-
aging processes in two FEMs.
Fig. 2. Analysis of AWS transformation
Assets needed for managing platform – workforce. The discussion on the differences
between two FEMs could continue further by unfolding the FEMs downwards. For
example, at the next level the capacities of hiring platform specialists could be eval-
uated with the result that this capacity might need to be increased for the new FEM,
which is depicted in Fig. 2.
6 The structure of transformational patterns
In this section we will use the example from the previous section to show how a trans-
formational pattern can be derived from a business case of BMI, and discuss the struc-
ture of transformational patterns. The basic idea behind BMI in Fig. 2 is based on the
following reasoning:
We have an infrastructure that supports our main process that could be of use for
other processes if made more general
Part of our current customers might be interesting to use our infrastructure if the
latter is generalized
These customers have positive experience of our infrastructure, though indirect
A transformation pattern that corresponds to this thinking could be presented as Fig 3.
It consists of two FEM fragments, (green) labeled arrows between the elements of these
fragments, and green hexagons with label inside that are connected to the elements of
the left-hand FEM fragment. We can differentiate two parts in a pattern - formal and
informal:
Fig. 3. An example of transformational pattern
The formal part is a part that can be applied by an algorithm to an existing FEM
without any human participation. It includes (1) shapes for processes and assets in
both FEM fragments, but not the labels in them, (2) links between these shapes,
including labels, inside each fragment, and (3) green links between the elements of
the two FEMs, but not their labels.
The informal part is a part that needs human beings for interpretation. It includes:
(1) hexagons connected to the elements of the left-hand FEM that express some con-
ditions on these elements (2) labels inside elements of FEMs that express the seman-
tics of the assets, and (3) labels on the (green) arrows that connects the elements of
two FEMs that express the difference between the corresponding elements.
Application of a transformation pattern to an existing FEM is as follows:
1. A place in a FEM graph is found which matches the formal part of the left-hand
FEM fragment of the pattern (labels inside shapes excluding)
2. The informal conditions expressed by (green) hexagons and semantic labels inside
the pattern's shapes are checked by experts
3. If the conditions are considered as being satisfied, a new FEM is generated and at-
tached to the old one with (green) arrows
4. Conditions included in the labels on the (green) arrows between the new and old
FEMs are checked by experts
5. If conditions considered as being satisfied, the process of adding details to the new
FEM continues
Fig. 2 can be used as an example of application of this procedure to the FEM in Fig. 1.
Note that the pattern from Fig. 3 can be applied not only to the place where IT-platform
matches Specific infrastructure, but also to the place where Webshop software matches
Specific infrastructure. In this case, the new FEM would represent licensing the Web-
shop to other book sellers. In fact this transformation has also been completed by Am-
azon.
7 Another example of a transformation pattern
The example of transformational pattern presented in Section 6 is more or less straight-
forward, as the idea behind it is simple – having excellent infrastructure that supports a
main processes, the company can decide on leasing this infrastructure to others. This is
why the pattern could be constructed based only on facts, without knowledge on the
details of decision making. In this section, we present another example, which is not
that straightforward and which has been built based on the information on the decision
making process of the company that has completed this type of transformation.
The company in question is an American consulting company called Prolifics, for
which the first author worked for a short period of time in the middle of 1990th. At this
time, the company was a vendor of a high-level software development tool, also called
Prolifics, which could be counted as a kind of 4GL tools. The main business was selling
licenses of the tool and providing product support. Beside this, there was a consulting
business providing experts in Prolifics for various software development projects that
used this tool. By the end of 1990th the market for 4GL went down due to the switch to
the web and low-level programming (e.g. Java), and in the beginning of 2000th, the
company needed to radically change its business in order to survive.
Such a change was successfully completed, and the company reemerged as a con-
sulting business providing expertise in IBM's Websphere. Understanding the rationale
behind such a transformation requires some insights in the internal decision making.
These were provided by Prolifics’ CEO, who explained that the internal changes were
minimal. The sales and marketing of the new consulting service was done according to
the same routines that were established for consulting arranged around the company’s
tool (Prolifics). The consulting service itself also used the already established routines.
The main difference was that instead of expertise related to the tool Prolifics, the com-
pany started to provide expertise related to Websphere. At the same time, activities
related to the tool Prolifics where drastically cut off. The support for the tool, and some
consulting related to it, remained, but without any marketing and sales activities. The
product development went down to bug fixing and releases connected to changing op-
erational environment. The developers where redirected to be Websphere consultants.
The main factor that allowed to successfully complete the transformation above was
that Prolifics had interface (API) to a number of third parties products, including Web-
sphere. Therefore, some of their consultants and product developers already had exper-
tise in Websphere. Moreover, a number of their customers had both Prolifics and IBM
products working together, as well as some of the consultants providing expertise in
both. In addition, the company had a partnership agreement with IBM.
Based on the analysis of the information provided by CEO, we created a transfor-
mational pattern in Fig. 4 by abstracting from details specific for Prolifics. In several
places in Fig. 4, a connection between an asset and a process labelled ExT is used. ExT
stays for Executable Template, and it is used for linking to the process any asset that
affects the behavior of process instances that belong to this process. In the first place,
ExTs have a form of description of working routines, process maps, policy documents,
etc. However, an EXT can be any other asset that affects how the process is executed.
In particular, the asset Own software product is used as ExT in both main processes in
the left-hand FEM in Fig. 4. In Product Licensing an installation package is used for
copying and sending to the customer, or downloading. In Consulting, the product af-
fects the area of the customer project that engages the consultants.
Note also that the two main process in the left-hand FEM are not independent, the
consulting process serves for retention of customers that license the product; also the
set of customers for consulting is a subset of the customers who have bought a license.
On the whole, the pattern in Fig. 4 represents the main idea of Prolifics's transfor-
mation – amending the consulting business by substituting its own product to a third
party product. The pattern expresses also the conditions when such transformation is
feasible. For example, to have a solid customer base for this kind of transformations, a
substantial part of the existing customer base should not only have the company's own
product installed, but also the third party product. Moreover, a substantial part of their
consultants needs to be experts in both products, and their expertise in the third party
products should be revealed to the customers that have both products.
Note that Prolifics, as a company, still exists, but at the end of 2000th , it was sold to
an Indian concern, and might have changed the line of its business. The example of the
transformation refers to the events of the early 2000th. The authors are grateful to Robert
Ismach, its President at the time, for providing the internal insights.
Fig. 4. From a tool vendor to providing expertise in a third party product
8 Concluding remarks
According to the literature reviewed in Section 1 and 2, the needs for the enterprises to
innovate their business models is expected to grow, particularly in connection to ad-
vances in technology, and especially in regards to digital transformation. In particular,
in this environment, the needs for industrial model innovation is expected to grow, as
the companies might be forced to rethink their line of business. As the same literature
shows, there is no systematic way for an existing business to conduct this kind of BMI.
Currently, it is being done on the intuitive, tacit level with running a risk of failure or
great costs, or missing a better opportunity. Management consultants, with whom we
discussed our ideas, also confirmed the lack of tools for systematic industrial model
innovation.
This exploratory study represents a major step on the way of filling the above gap in
theory and practice by providing an innovative approach for BMI that takes into con-
sideration existing capabilities of the enterprise (in form of both processes and assets).
Though this approach is based on the known principles - experimentation, analogy (best
practices) and patterns - it combines these principles in a new way. The contributions
of this paper include:
Clearly identifying the gap in practice and research that needs filling
Suggesting an approach to fill the gap by a library of FEM-based transformational
patterns
Suggesting a structure for transformational patterns
Suggesting and demonstrating an approach for creating new patterns
Our immediate plans regarding transformational patterns are related to creating and
disseminating a library of patterns. Creating a transformational pattern includes finding
a good example, abstracting from details and creating a transformational pattern based
on this example, and finding other examples that correspond to the constructed pattern.
Dissemination can be arrange by creating a website where such patterns are published,
giving access to it to any researcher or practitioner who wants to add a new pattern,
thus making the library a collaborative work.
More long-term plans include creating a computerized tool that facilitate experimen-
tation by automatically finding places in a FEM model which can serve as a basis for a
pattern-based BMI. We also plan to extend our framework so that it can help not only
in finding a promising transformation using the pattern library, but also in planning the
completion of such a transformation. This requires the development of a set of qualita-
tive and quantitative properties that could be assigned to the nodes of FEM [13]. Plan-
ning then can be done based on comparing characteristics of elements of the FEM be-
fore transformation with the corresponding elements of the FEM after transformation.
We are also planning to investigate attaching other frameworks and method for devel-
oping a more detailed plan. Here in the first place, we are looking at pattern of strategy
suggested in [4] trying to find a synergy between two types of patterns. The connection
between them seems to exist when considering specific examples, e.g. Prolifics´ pattern
of strategy was changed from coupling to a market to coupling to a bigger partner.
References
1.
Andreini, A., Bettinelli, C.: Business Model Innovation. From Systematic Literature
Review to Future Research Directions. Springer (2017)
2.
Mangematin, V., Ravarini, A., Sharkey Scott, P.: Special Issue: Business
Model Innovation.
Journal of Business Strategy 38(2) (2017)
3.
Giesen, E., Berman, S. J., Bell, R., Blitz, A.: Three ways to successfully innovate your
business model. Strategy & Leadership, Vol. 35 Issue: 6, pp. 35(6), 27
-
33 (2007)
4.
Hoverstadt, P., L
oh, L.: Patterns of Strategy. Taylor & Francis (2017)
5.
Altshuller, G.: The innovation algorithm: TRIZ, systematic innovation and technical
creativity. Technical Innovation Center (1999)
6.
Rumble, R., Niall Anthony Minto, A.: How to use analogies for c
reative business modelling.
Journal of Business Strategy, 38(2), 76
-
82 (2017)
7.
Osterwalder, A., Pigneur, Y.: Business Model Generation: A Handbook for Visionaries,
Game Changers, and Challengers. Wiley, Hoboken, NJ,US (2014)
8.
Echterfeld, J. .,
Gausemeier, J.: How to use business model patterns for exploiting disruptive
technologies. In : 24th International Conference on Management of Technology, pp.2294-
2313 (2015)
9.
Boyd, J. R.: Destruction and creation. Lecture presented to the U.S. Army Com
mand and
General Staff College (1976)
10.
Bider, I., Perjons, E., Elias, M.: Untangling the Dynamic Structure of an Enterprise by
Applying a Fractal Approach to Business Processes. In : Proceedings of PoEM 2012,
Springer, LNBIP 134, pp.61
-
76 (2012)
11.
B
ider, I., Perjons, E., Elias, M., Johannesson, P.: A fractal enterprise model and its
application for business development. Software & Systems Modeling (2016)
12.
Henkel, M., Bider, I., Perjons, E.: Capability
-
based Business Model Transformation. In :
Advanced Information Systems Engineering Workshops, Sprnger, LNBIP 178, pp.88-
99
(2014)
13.
Bider, I., Perjons, E.: Using a Fractal Enterprise Model for Business Model Innovation. In
: BPMDS 2017 RADAR, CEUR Vol 1859, pp.20
-
29 (2017)
14.
Chesbrough, H.:
Business model innovation: opportunities and barriers. Long range
planning 43(2), 354
-
363 (2010)
15.
Hevner, A., March, S. T., and, P.: Design Science in Information Systems Research. MIS
Quarterly 28(1), 75
-
105 (2004)
16.
Peffers, K., Tuunanen, T., Roth
enberger, M. A., Chatterjee, S.: A Design Science Research
Methodology for Information Systems Research. Journal of Management Information
Systems 24(3), 45
-
78 (2007)
17.
Baskerville, R. L., Pries
-
Heje, J., Venable, J.: Soft Design Science Methodology. In
:
DERIST 2009, pp.1
-
11 (2009)
18.
Bider, I., Johannesson, P., Perjons, E.: Design science research as movement between
individual and generic situation-problem-
solution spaces. In : Organizational Systems. An
Interdisciplinary Discourse. Springer (2013)
35
-
61
19.
Amazon: Amazon Web Swevices (AWS). Available at:
https://aws.amazon.com/
