Case Model for the RoboInnoCase Recommender System for Cases of
Digital Business Transformation: Structuring Information for a Case
of Digital Change
Hans-Friedrich Witschel, Marco Peter, Laura Seiler, Soyhan Parlar and Stella Gatziu Grivas
FHNW University of Applied Sciences and Arts Northwestern Switzerland, Switzerland
Keywords: Case Model, Recommender Systems, Decision Support Systems, Digital Transformation.
Abstract: In this work, we develop a case model to structure cases of past digital transformations which act as input
data for a recommender system. The purpose of that recommender is to act as an inspiration and support for
new cases of digital transformation. To define the case model, case analyses, where 40 cases of past digital
transformations are analysed and coded to determine relevant attributes and values, literature research and the
particularities of the case for digital change, are used as a basis. The case model is evaluated by means of an
experiment where two different scenarios are fed into a prototypical case-based recommender system and
then matched, based on an entropically derived weighting system, with the case base that contains cases
structured according to the case model. The results not only suggest that the case model’s functionality can
be guaranteed, but that a good quality of the given recommendations is achieved by applying a case-based
recommender system using the proposed case model.
Digitalisation is changing everything around us, and it
seems as though it is here to stay. With good reason:
companies that have decided to undertake a
transformation of their business model have found
themselves to be more competitive in today’s market
(PwC Schweiz, 2016). Investments in digitalisation
activities correlate to the perceived increase in
competitiveness. However, the trend affects all sizes of
organisations in all industries. This, unfortunately, is
where this development, with seemingly endless
possibilities, has a catch. As the survey “Digital
Switzerland” states, “a majority of 87% of Swiss small
and medium-sized enterprises (SMEs) can be
classified as so-called digital dinosaurs (HWZ and
localsearch, 2018). Missing resources tend to be the
number one challenge SMEs must deal with during a
digital transformation. Another finding reveals a lack
of know-how about the impact of digital technologies
on their business, which makes it difficult to exploit the
number of digital opportunities in daily business
(HWZ and localsearch, 2018). This is especially
important for SMEs which are under the pressure of
competitors. To support SMEs towards a successful
and sustainable digital transformation, the ABILI
Methodology (Peter et al., 2018) offers a systematic
and transparent transformation process, amongst
others focusing on the inspiration phase by identifying
so-called cases for digital change. In this inspiration
phase, SMEs understand their current internal situation
and their core capabilities as well as external
influencers (like new competitors, new customer
demands or new technologies) and get ideas about
possible transformation paths such as innovation,
process automation or organisational changes. The
analysis is supported by two web-based tools, the
Digital Backpack Assessment and the Panoramic Lens
(Gatziu et al., 2018). This is the starting point for the
further in-depth analysis, including the definition of
strategic goals for the digital transformation. For this
analysis, the ABILI Methodology offers the
Transformation Compass (Graf et al., 2018).
The lack of know-how mentioned above is
manifested especially in this inspiration phase. To
overcome this, we propose an intelligent recommender
system, the RoboInnoCase, which, depending on the
current internal situation of the companies and taking
into account the external influencers, makes
suggestions for cases of digital changes. Thus, the
company receives an array of recommendations that
are customised to its needs. Experiences of past
consulting cases are also collected and saved in a case
base to be accessed by the recommender system.
Witschel, H., Peter, M., Seiler, L., Parlar, S. and Grivas, S.
Case Model for the RoboInnoCase Recommender System for Cases of Digital Business Transformation: Structuring Information for a Case of Digital Change.
DOI: 10.5220/0008064900620073
In Proceedings of the 11th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2019), pages 62-73
ISBN: 978-989-758-382-7
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
In this paper, we discuss a case model to structure
the cases of past digital transformations which act as
input data for the RoboInnoCase recommender system.
The tailor-made set of recommendations, which are
then provided by the recommender system, is to be
understood as the output data, or the case for digital
The paper is organised as follows: related work is
discussed in Section 2 and our research methodology
in Section 3. Section 4 describes our proposed solution
for a case model for cases of digital business
transformation. The evaluation of the case model is
presented in Section 5 and discussed in a concluding
manner in Section 6.
2.1 The Core of Digital Business
Digital transformation is rather unique to every
business. However, there are a few concepts in
literature representing similar core parts of every
company’s digital transformation. Studies have shown
that managers generally transform four key areas of
business as part of a digital transformation within a
company (Westerman et al., 2011):
Customer Centricity
Operational Excellence
Business Model
Organizational Excellence
The Transformation Compass of the ABILI
Methodology is built around these four transformation
building blocks (Graf et al., 2018). These blocks also
give the structure of the Digital Backpack Assessment,
which is used for the analysis of the internal situation
of the company and is a starting point for the definition
of the case structure for the RoboInnoCase.
The first building block, customer centricity,
shows how a company empowers its customer, how it
is attracting the customer, how the company is
interacting with the customer and enhances the
customer’s respective experiences. Operational
excellence includes operational processes, strategy,
and corporate management as well as the dataflow
within an organisation. It mostly aims to increase
efficiency. Another key area for SMEs is to recognize
enablers which lead to market growth and innovation.
Those aspects are included in the third building block
called business model. The last building block,
organizational excellence, is linked to the cultural
aspects and the way people are managed and led in a
company such that the organisation learns and
improves its capabilities.
In Section 4, we will use the key areas to structure
recommendations and derive them from corresponding
aspects of a company’s initial situation such as its
current customer segments or core business processes.
2.2 Case for Change
At the beginning of every systematically created
innovation is a formulated “Case for Change” (Dobni
et al., 2015). The case for change is defined as follows:
“a case for something” = there is an existent necessity
and change = transformation (Dr. Kraus and Partner,
n.d.). In short, the case for change describes the reasons
for a change. However, the purpose of a case for
change is not only to explain the particular reasons for
a change, it should also (The Change Source, 2013):
Highlight desired outcomes and expected benefits
Demonstrate leadership support
Through this, it is meant to:
Minimise the resistance to change
Gain support from internal as well as external
stakeholders that are impacted by said change
To create a case for change, there are some guidelines
that have been proposed in business communities
(Jones et al., 2004). As a first step, the organisation’s
current internal and external situation should be
analysed and used to deduce the need for a change.
Secondly, it is important to point out if and how the
company, its management as well as its staff are able
to cope with the change (Jones et al., 2004).
Additionally, one should also articulate what exactly
will change and who will be impacted by these changes
(Jacoby, 2012). Thirdly, a roadmap should be
developed, showing how the proposed change will be
implemented, how the management should behave and
how it should make decisions concerning this
innovation. Further, one should highlight the expected
benefits resulting from these changes as well as the
consequences of delaying the changes. At last, it is
important to inform the various stakeholders “about
what is expected of them” to point out that everyone is
part of implementing the changes successfully (Jacoby,
2012). As this paper is concerned with finding a way
to provide suitable change recommendations for a
company, we focus on what will or could change and
what outcomes or benefits may be realised.
Case Model for the RoboInnoCase Recommender System for Cases of Digital Business Transformation: Structuring Information for a Case
of Digital Change
2.3 The Recommender System in a
Most current recommender systems (RS) are built to
provide recommendations that help individuals to
decide which products, goods or services to buy or use,
usually based on their personal preference. Generating
recommendations for personal preferences is not the
only purpose of a RS (Witschel and Martin, 2018a).
There are also recommenders which create suggestions
for business decisions, driven by business
requirements rather than individual preferences
(Tiihonen and Felfernig, 2010; Witschel and Martin,
2018b). The starting point for such business
recommenders is different from end-user
recommenders since business recommenders are often
invoked just once (or at least very rarely) by a company
and thus the system cannot collect information about
the user from repeated interaction (Felfernig and
Burke, 2008). This means that such systems usually
need to acquire their inputs (the business requirements)
via some kind of questionnaire in our case, much of
the input is acquired using the two online assessment
forms mentioned in Section 1. Such a process
resembles the process of business consultancy and,
as the consultancy industry itself undergoes a digital
transformation (Nissen and Seifert, 2017) may
partially replace the humans in that process.
In a nutshell, RS are useful tools that can support
not only individuals but also businesses in decision-
making. The RS merges methods from information
retrieval and filtering, user modeling, machine
learning, and human-computer interaction (Bridge et
al., 2005). For the development of case-based RS or
content-based RS, knowledge about case-based
reasoning, which is explained in Section 2.3, is
essential (Bridge et al., 2005).
2.3.1 Recommendation Techniques
According to Bridge et al. (2005), case-based
approaches to recommendation have their place as
special forms of both knowledge-based (Aggarwal,
2016) and content-based (Pazzani and Billsus, 2007)
recommendation. As states by Ricci et al. (2011), a
knowledge-based RS recommends items based on
specific knowledge about how an item feature meets a
user’s needs. A case-based RS assesses a user’s need
(problem description) for the recommendations
(problem solutions) through a similarity function. In
this case, a similarity assessment can be understood as
the benefit of the recommendation for the user.
As explained above, typical situations in business
consultancy may allow the system to acquire
information about a (current) user need, but usually
imply that no rich history of the current user is
available a common cold-start problem (Lika et al.,
2014) in collaborative filtering recommenders (Schafer
et al., 2007) that are commonly used for preference-
based recommendations, e.g. in e-commerce. This
makes content-based recommenders a better choice.
Since consultancy draws a lot on the re-use of
experience (Gable, 2003), case-based techniques are a
perfect match. The theory behind case-based RS is
explained in the following section (Ricci et al., 2011).
2.4 Case-based Reasoning
Case-based reasoning (CBR) is a theory for solving
problems with the help of remembering a similar
situation that has happened in the past and
subsequently reusing this knowledge and information
of that particular situation (Aamodt and Plaza, 1994).
Regarded as “a subfield of machine learning”, CBR
facilitates sustained learning by retaining the
experience of successfully solving a problem for
future, similar problem-solving. Thus, it continuously
updates the case base, the collection of cases, following
each problem that has been solved. The steps or
process necessary to conduct problem-solving is also
called the CBR working cycle (Aamodt and Plaza,
1994). Kolodner (1992) identifies the following
process steps when applying CBR: case retrieval, case
adaptation, solution evaluation, and case storage.
Applications of CBR range from medicine (Choudhury
and Begum, 2016) over law (Rissland et al., 2005) to
business process re-design (Mansar et al., 2003).
2.4.1 Case Representation
A case contains pieces of knowledge that represent a
particular experience. In general, cases comprise a
(Kolodner, 1991a):
Problem Description: a description of the
situation at the occurrence of the case
Problem Solution: the solution that has been
applied to the problem
As this definition shows, the notions of problem and
solution can be understood in a wide sense: a
“problem” might simply refer to an initial situation
such as the situation of a company where no
immediate pain is felt. However, in what Kolodner
(1991b) calls interpretive CBR, one “evaluates new
situations in the context of old solutions”. For our goal
of inspiring companies on how to transform digitally,
this means that we evaluate their situation by looking
at the contexts of other companies and what they did to
maintain their competitiveness in the digital age.
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
Case representation in CBR applies knowledge
representations to describe the experiences contained
in cases for the purpose of reasoning (Bergmann et al.,
2005). In terms of representation, there is a distinction
between three CBR types that should be made:
“structural, textual, and conversational” (Bergmann et
al., 2009). Here, the focus is put on structured cases as
we want to establish a common case structure with
controlled vocabulary to overcome problems of e.g.
synonyms that are inherent to e.g. textual
representations. In structural CBR, cases are
represented with attributes and corresponding values
(Bergmann and Schaaf, 2003). It is especially useful in
instances where further knowledge, besides cases, have
to be used to generate satisfying results (Bergmann and
Schaaf, 2003). Below, the representation formalisms
that were observed most in literature are described in
more detail:
A. Frame-based representation
In frame-based representations, frames are used to
combine the necessary knowledge concerning an
object or concept (El-Sappagh and Elmogy, 2015). A
frame organises the knowledge in forms of slots
defining the characteristics and attributes of the object.
This means, in terms of CBR, that a case can be
represented by a frame and every case feature is
characterised by a frame slot. Slots can contain
primitive values as well as pointers linking to another
frame. The frames, or cases, may have semantic
relationships as they can have features (slots or
attributes) whose value is a pointer to a different frame.
Additionally, the “cases connected by IS_A and
PART_OF relationships” can be hierarchically
structured as inheritance is one of the essential features
of the frame. This hierarchy improves the retrieval,
indexing as well as the adaptation of the cases (El-
Sappagh and Elmogy, 2015).
B. Object-oriented representation
In situations where the case data structure is more
complex or incoherent, object-oriented representation
may be more suitable (Bergmann et al., 2005; El-
Sappagh and Elmogy, 2015). The expressiveness is
similar to the frame representations, also making use of
IS_A and PART_OF relationships and the inheritance
principle. A collection of objects, that are each
described by various attribute-value pairs, represents a
case (Bergmann et al., 2005). The object class
describes the object’s structure (El-Sappagh and
Elmogy, 2015). One can distinguish between so-called
simple attributes, such as integers, and relational
attributes (Bergmann and Schaaf, 2003). Relational
attributes symbolise binary relations, such as part-of
relationships, between the objects defining the
relational attributes and the objects to which they refer.
Thus, it is possible to relate objects to other objects of
some arbitrary classes, enabling the appropriate
representation of cases with various structures. Most
modern CBR systems nowadays use object-oriented
representation (Bergmann and Schaaf, 2003).
C. Hierarchical case representation
The before-discussed methods focus on representing a
case at one level of abstraction (Bergmann et al., 2005;
El-Sappagh and Elmogy, 2015). It has, however, been
shown that cases can also be represented by using a
multitude of “representations at different levels of
2.5 Contribution
To the best of our knowledge, CBR and CBR-based
recommenders have not been applied to the problem of
inspiring companies regarding their potential digital
transformation. Since more and more companies are
undergoing such change and are thus collecting
experiences in this field, CBR seems a natural choice
to support other companies in learning from these
experiences. We make a first step toward such a CBR-
based RS by developing an appropriate case structure
for a “digitalisation case base”. Since there are many
success stories of digital transformations around
(formulated in natural language), building up a case
base will be a logical and feasible next step.
The objective of elaborating and creating an
appropriate case model for cases of digital business
transformation, that are fed into the RS, have led to the
decision to apply a design-oriented research approach
in this research paper.
We follow the Design Science Research (DSR)
process model proposed by Vaishnavi and Kuechler
(2004), with its 5 phases awareness of the problem,
suggestion, development, evaluation, and conclusion.
In the awareness phase, besides our literature
research on digital transformation and CBR, we
collected 40 cases of digital transformation, mostly
through online research, but also using stories from our
own and from acquaintances’ work environment. To
gather a relatively broad variety of cases, we selected
cases from different industries, sizes, and age. These
cases were then, in a further step, qualitatively
analysed by coding, where we indexed and categorized
the whole text in each case of a past digital
transformation to create a framework of thematic ideas,
to determine relevant attributes and values which were
then part of the later elaboration of the case model. The
Case Model for the RoboInnoCase Recommender System for Cases of Digital Business Transformation: Structuring Information for a Case
of Digital Change
results of these analyses were then used to build a first
suggestion of a possible solution (suggestion phase of
DSR). Therein, we used the knowledge about common
approaches to case modelling in CBR (see Section
2.3.1), as well as about the key areas of digital
transformation (Section 2.1) to structure the codes and
determine their relationships.
In the evaluation phase, the suggested structure
was evaluated by means of a qualitative test. For this,
we built the case base with our 40 cases from the
awareness phase, based on the defined case model, and
the RS was enriched with information such as an
industry taxonomy, to allow a better assessment of
similarity between industries. Then, two test scenarios
were defined which were fed into a simple case-based
recommender that we implemented. To evaluate the
recommender outcome in these scenarios, we first
formulated assumptions and expectations regarding the
results, which we then compared to the output of the
RS. The results of the test run are discussed as to the
case model’s functionality and the recommendations’
4.1 Categorisation of Parameters and
Scope of Case Model
In the next subsections, we will discuss our suggested
case structure from a conceptual perspective. It
comprises 4 main areas: a characterisation of the
company (in terms of industry, size, customer
segments, etc.), of the challenges the company faced
before the transformation, of the measures taken as part
of that transformation and finally a characterisation of
the outcome of applying these measures. In the
following, we give the rationale and some details for
each area.
4.1.1 The Transformed Company
To retrieve cases for inspiring a company’s potential
transformation, one needs to be able to describe the
company’s initial situation and its characteristics so
that retrieved cases are as relevant as possible to that
One of the parameters that plays a role in this is the
size of the company. Size plays an important role
regarding the feasibility of the transformation
measures, as micro-businesses often have a lack of
human as well as financial resources compared to
middle-sized companies. Additionally, smaller
companies tend to be less mature in terms of
digitalisation due to the before-mentioned reasons.
On the other hand, the age of a company may not
only be a further indicator of its overall digital
maturity, but it may also point out challenges in the
organisational culture to be overcome. As a change
culture is one of the key elements of transforming
successfully, and the age of a company can indicate
some degree of change-adversity, it represents an
important parameter in this case model.
Similarly, the industry of the company has a large
influence since it determines many other key factors,
such as core business processes or common customer
segments. Furthermore, it can point out industry-
specific trends and challenges that may impact digital
transformation measures as well as present a last
indicator of digital maturity as certain industries are
more advanced than others.
In addition to these rather general information
elements, it is essential to get a more in-depth view of
the case company. For this, relevant building blocks of
the business model canvas (Osterwalder et al., 2011)
serve as a basis. In particular the building blocks that
are concerned with the value (external view) of the
business model are featured in the case model, such as
the value proposition, the customer segments, the
customer relationships, the channels, the key activities
as well as the revenue streams. We place more
emphasis on these elements of the business model
canvas since they can more easily be researched by an
outside party than the elements concerned with the
efficiency (internal view) of the business.
4.1.2 The Challenge
To demonstrate the importance of the digital
transformation for the organisation, the challenges
faced are elaborated. While the variables identified in
Section 4.1.1 were mostly based on findings from the
literature, the aspects, relating to the drivers and the
strategic goals, we refer to here were mostly taken from
the analysis of our collected cases.
During our case analysis, we found that the reasons
for a digital transformation can be generalised rather
easily. Be it the increase in efficiency of processes, the
change in customer expectations, necessity for cost
savings or the need for a better differentiation to
increase competitiveness. The reasons for the digital
transformation are heavily interlinked with the
measures taken by the company. Furthermore, the
strategic goals of the company’s transformation more
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
clearly represent the overall objective of the taken
4.1.3 The Transformation Measures
To make suitable recommendations, the measures
taken in previous cases need to be understood. This
means that such measures are part of the solution of a
case. As mentioned in Section 4.1, the Transformation
Compass suggests that there are four key areas of a
business that are usually transformed, the so-called
building blocks of digital transformation. To identify
the characteristics of the taken measure it is important
to know which of these four areas, organisational
excellence, customer centricity, operational excellence
or business model, it covers. These areas are then
divided into further subcategories, corresponding to
codes that we derived during case analysis in the
awareness phase and allowing the identification of the
measure’s characteristics to get more specific. In the
end, the specific measure that was chosen is described
to give the company to be transformed a choice of
possible solutions. In addition to the solution itself, of
special interest to the company wanting to transform is
the course of action that should be taken to execute the
chosen measure. Thus, the case model considers
various aspects of the possible course of action, such
as the used development methodology and tools as
well as the trends the measure was inspired by.
4.1.4 The Result
Lastly, the result of the taken measure is of major
importance to the company wanting to transform.
Primarily, it is essential to know whether the solution
was a success or not. However, we strongly believe
that unsuccessful solutions should not be ignored
entirely, but that they should be analysed, to avoid
pitfalls and to be able to optimise their measures to fit
the needs or circumstances of the company wanting
to transform. Unsuccessful cases should represent
lessons learnt, not failures. The success of a solution is
most easily determined by the achievement of the
strategic goal set by the company. Further, certain
improvements or optimisations (or problems) that have
occurred as a result of the taken measure as well as the
benefits or advantages of those improvements are
highlighted. The drivers of the digital transformation
may serve as a basis for representing the improvements
as well as the advantages of the taken measure (e.g.
improvement = increase in process efficiency,
advantage = higher productivity or increased
4.2 The RoboInnoCase Case Model
4.2.1 Sets
In general, our proposed case representation is divided
into a problem as well as a solution set. However, when
considering the scope of the case model concerning
cases of digital transformation, a model including two
sets is insufficient. To give proper recommendations
for specific transformation measures, a case must
essentially contain not only the problem and solution
sets, but all the information required to describe a
case company in detail and the outcome of the chosen
measure (see Section 4.1).
Thus, the case model for cases of digital
transformation includes the following four sets:
general information (G, see Section 4.1.1), problem
description (P, see Section 4.1.2), solution (S, see
Section 4.1.3) and outcome (O, see Section 4.1.4):
      
Moreover, the union of all cases defines the case base:
 
Figure 1: Case model for cases of digital business transformation.
Case Model for the RoboInnoCase Recommender System for Cases of Digital Business Transformation: Structuring Information for a Case
of Digital Change
Table 1: Attribute-value table for case model (1/2).
4.2.2 Case Representation
To provide a more specialised representation than the
four sets defined above, the knowledge collected
throughout the research is appropriately categorised.
Since the case data structure is rather complex and
often inconsistent due to each case’s individuality, an
object-oriented representation was chosen. Addition-
ally, because of the case data structure’s complexity,
the authors have chosen to apply a hierarchical case
representation, allowing a case to be represented at
numerous levels of detail. Thus, for the case model for
cases of digital transformation, a hierarchical, object-
oriented case model is created (Figure 1).
A case is represented by the “Case” object, which
uses four objects on a lower level, corresponding to the
before-defined sets “General”, “Problem”, “Solution”
and “Outcome”. The “General” object contains two
lower level objects calledCompany Information” and
“Company Business Model (table 1), representing the
information needed from the case company. The
“Problem” object consists of another two lower level
objects, Drivers” and “Strategic Goals (table 1)
which capture the past problem situation of the case
company. The “Solution object uses a lower level
object called “Building Blocks/Focus”, which uses a
further lower level object, “Applied Solution” (table 2).
In addition, “Solution” consists of another lower level
object called “Course of action” (table 2), representing,
amongst others, the tools and methods, such as agile
software development or native development, used to
implement the chosen solution. Lastly, the “Outcome”
object makes use of three lower-level objects which are
“Result”, “Improvements” and Benefits” (table 2),
representing the outcome of the “Solution” object.
Table 2: Attribute-value table for case model (2/2).
4.2.3 Relationships
As the case model shows, various relationships exist
between the different objects. Firstly, there are certain
important multiplicities that need to be explained. The
case model can ever only represent one case. This case
can consist of one “General” object, meaning a case
can only involve one company. Further, a case contains
one “Problem”. If there is a company that deals with
different problems, a case for every problem is
generated since each new case is used as a query. Thus,
the RS should return a suitable recommendation for
every problem a company deals with. Every case
consists of one “Solution” and one “Course of action”.
Lastly, only one “Outcome” can exist for a case, as a
case may either be a success or not and has one set of
improvements and benefits. Furthermore, there are
various dependencies within the case model. For the
“Solution” object, the “Course of action” is dependent
on the “Applied solutionas it may impact attributes
such as the development methodology and tools.
Further, the “Outcome” is dependent on the “Solution”
object since the “Applied solution” or the “Course of
action may have been an unsuitable choice for the
problem at hand. Thus, the “Solution” object is
dependent on the “Problem” object as well. When
looking at the “Outcome” object in more detail, it is
apparent that the “Improvements/Optimisation” and
“Benefits/Advantagesobjects are both dependent on
the outcome. However, if the outcome was not a
success, both the “Improvements/optimisation” and
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
the “Benefits/advantagesobjects can still be used to
indicate which improvement or benefit could not be
realised. This helps characterise the “failure” in more
detail. Furthermore, to tell if an outcome was a success
or not, it is most practical to check if the strategic goal
that was set in the beginning has been (partly)
achieved. Thus, the “Result” object is dependent on the
“Strategic goals” object, which then, respectively, also
influences the Improvements/optimisation” and the
“Benefits/advantages” objects.
4.2.4 Information Representation
When applying the object-oriented case representation
method, a case consists of a collection of objects. As
represented above, the case model for cases of digital
transformation contains four higher-level objects that
each consist of various lower-level objects. These
objects are each described by various attribute-value
pairs. To define each value-attribute pair, the following
structure was applied:
Name: describes the information entity
Description: defines the meaning of the
information entity
Type: specifies the attribute type
Value representation: describes how the value,
corresponding to the attribute, is represented
Due to the fact that similar facts or situations can be
expressed differently in natural language (Furnas et al.,
1987), we have decided to define a set of controlled
vocabulary for most attributes. Thus, the type “choice”
is most frequently used, either with a choice of values
or yes/no. For attributes where no controlled
vocabulary could be defined, a string or “integer”
value can be inserted. An attribute-value pair (A) of an
information entity can be represented by a variable:
A= {name, type, value}
Where Name(A) = name, Type(A) = type, Value(A) =
Thus, a case 
 of digital transformation can be
represented by a set of attribute-value pairs:
 attribute-value pair in case & N =
number of attributes in a case.
All cases in the case base will have the same name
as well as the type of an attribute-value pair, however,
the value element may differ.
5.1 Experimental Set-up
To evaluate the defined case model, we conducted an
experiment with a prototypical case-based RS. The
goal of the experiment is to evaluate the functionality
of the case model and the quality of the output data of
the RS. Quality in this context means that the
recommendations accurately reflect the characteristics
and the need (general and problem object) of the query.
To build an experimental case base, the before-
analysed cases were structured according to the case
model defined in section 4.2. An exemplary row is
shown below:
{attributes:NAME=example-case; INDUSTRY
business services, SIZE >=250, AGE >=5,
The upper-case lettered strings represent the particular
attributes, whereas the lower-case lettered strings are
the respective values. Further, we configured the
system by defining which attributes should be used as
problem characterisations (   as defined in Section
4.2.1) and which should be part of the system’s output
(    ). The following attributes and their
corresponding values should be returned:
Building blocks
Applied solution
Course of action
Benefits and improvements
5.2 Prototypical Case-based
Recommender System
To receive meaningful results, we have developed a
prototypical implementation of a CBR-based RS,
including a similarity function for case retrieval. The
overall similarity of the problem parts of cases was
defined as a weighted sum of local attribute-based
similarities. Thus, a central problem was to define the
weight that each local similarity should have in the
sum. This was done by calculating the entropy,
describing the degree of uncertainty in a system, of
every attribute. The entropy was calculated by taking
the attribute’s values’ relative frequency as a
maximum likelihood estimation of a probability
. The entropy
then gives an indication of the information richness of
the attribute if nearly all cases in the case base have
Case Model for the RoboInnoCase Recommender System for Cases of Digital Business Transformation: Structuring Information for a Case
of Digital Change
the same value for an attribute, it is not very useful to
separate relevant from irrelevant cases.
The weighting
was then simply calculated by taking
the entropy value of each attribute and normalising it
by dividing by the sum of all attribute entropy values.
The attributes exhibiting the highest entropy weighting
1. Industry [ 0.149791516]
2. Value proposition [  0.127187279]
3. Drivers [ 
4. Strategic goals [ 
From a business perspective, weighting the before-
listed attributes the highest makes sense due to their
significance when considering digital transformation.
The industry most often indicates the development
stage, meaning trends, maturity levels, and resources,
of digitalisation activities, making it meaningful in the
context of giving recommendations for digital
transformation measures. On the other hand, the value
proposition describes the products and services which
create value for a specific customer segment. It is thus
significant in indicating how companies with similar
products and services have evolved and advanced in
the context of digital transformation. The drivers as
well as strategic goals not only indicate the direction of
impact, but they are both strongly interlinked with the
solution and the outcome of a digitalisation measure,
making the condition of similarity very reasonable.
Since the case base, at this point, only consisted of
40 cases, it was enriched with an industry taxonomy
(Bergmann, 2002). The industry taxonomy serves as
additional knowledge which is integrated within the
RS. The goal of the industry taxonomy is to be able to
make recommendations for industries that are not
represented in the case base yet, which are, however,
similar to industries that are already represented. This
will, eventually, lead to an improved result of the
recommendations. The industry taxonomy was defined
as shown in Table 3.
Various industries included in the NACE Rev. 1.1
classification list (Eurostat, 2015) were then allocated
to level 1-3 classifications. The goal when defining
these classifications was to be able to include not only
traditional business models but business models that
are emerging today. Thus, next to the rather traditional
division of products and services, we integrated
concepts such as technology creators as well as
platforms that are very much present nowadays. In
terms of services, we have added a level 3
classification, dividing the recipient of the service into
people (such as hotels, restaurants and catering
services) and things (like construction). Lastly, all of
those classifications are supplied with a number,
indicating the minimum similarity between two
Table 3: Industry taxonomy.
industries that are part of the same classification level.
This is used for the computation of a local taxonomic
similarity measure as proposed by Bergmann (2002).
For example: all industries classified as asset builders
have a minimum similarity of 0.6. The rationale behind
this taxonomic approach is that two companies that are
part of the asset builders’ classification probably have
a rather similar case for digital change since they share
various important characteristics such as important
business processes. In addition to defining an industry
taxonomy, keywords for the various string attributes
were extracted, which can be transferred between the
different cases, to achieve better recommendation
outcomes. For our rather small case base, this was done
manually by the authors. As soon as the case base is
growing, these keywords can, however, be extracted
with the use of text mining methods, using e.g. Tf-idf
or more sophisticated methods for keyword extraction
(Lott, 2012). Lastly, the similarity measure of the
attribute typechoice”, which was most frequently
used during this experiment, was based on the exact
similarity of the two values, meaning zero (different
values) or one (matching values).
5.3 Test Run
The case model itself, with its various sets,
relationships and attribute-value pairs was analysed
and improved continuously throughout the project.
Thus, this test run was performed merely to get a
qualitative understanding of the output data that was
generated by applying the defined case model and to
showcase the added value of that model.
To get recommendations from the system, any
company would need to provide information
concerning the “general” and “problem” object. Thus,
two experimental cases were defined to simulate a
company wanting to receive recommendations. The
case model is tested by running the prototypical case-
based RS. The two scenarios were defined as follows:
1. The company can fill in all the company information
and knows exactly what the drivers and strategic goals
for the digital transformation are (maximum
information provided). This case’s information exactly
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
Table 4: Results from scenario one.
represents an existing case from the case base. Thus,
the case was subsequently removed from the case base.
Its attribute values are as follows:
{INDUSTRY financial and insurance
sector, SIZE >=250, AGE >=5, VALUE
segmented, BUSINESS-RELATION b2c,
assistance, CHANNELS own direct,
ACTIVITIES problem solving, DRIVERS
added value for employees, STRATEGIC-
GOALS optimise efficiency of employees}
2. The company cannot fill in all the company
information and is not sure about the drivers and
strategic goals for the digital transformation (minimum
information provided). As we have omitted most
attributes within this query, the case base was adjusted
accordingly by removing those attributes.
{INDUSTRY financial and insurance
To conclude a meaningful result, it was necessary to
compare the data to our assumptions. Firstly, we
assume that our case model can be utilised by a case-
based RS. Secondly, we assume that recommendations
are ranked by similarity. The more information about a
case is provided, the more closely the top-ranked cases
should match this information. Based on these
assumptions, we expect the following results for
scenarios one and two:
1. For scenario one, we expect that the solution and
outcome values of the cases within the financial and
insurance sector are returned, with the ones which most
exactly fit the input values ranked highest.
2. For scenario two, we expect that the solution and
outcome values of all cases within the financial and
insurance sector are returned in an arbitrary order.
5.4 Results and Discussion
For the results, there was no similarity threshold value
set. The values most recommended by the RS, meaning
the largest similarity scores, were registered first. We
first explored the functionality of the case model in
harmonisation with the RS by comparing the output
data of the scenarios with the solution and outcome
object of a case in the case base. Based on the output
data we could recognise that the RS has given a
recommendation for every necessary attribute. For
every attribute, one to several values were provided.
Thus, the basic functionality of the case model is
guaranteed. We then examined the quality of the output
data by comparing it to our expected results concerning
the scenarios one and two. By quality, we mean that we
expected that only the attribute-value pairs of a case in
the case base would be returned in the top ranks which
achieve a high similarity score regarding the test case.
By weighting the attributes, the expectations for our
scenarios were met fully. For query one, three cases
were returned by the RS (table 4) while for query two,
all the cases in the case base that featured the financial
and insurance sector were returned. We can see here
for instance that the case at rank 1 shares the value
proposition with the query case while the others do not.
It also shares customer relation and revenue streams
values which are not shared by all other returned cases.
Thus, the business model of Case 1 is significantly
closer to the query case than that of Case 2 and Case 3.
Although Case 1 might not be a perfect match to
inspire the “input” company, it surely fits better than
the other two which qualitatively shows the value of
a more elaborate case model.
Regardless of the above-mentioned successful
results, we examined the task of structuring the cases
by applying the case model. While building the case
base, we have noticed that the task of structuring the
cases is affected by the person’s perception, meaning
that the application of the case model is rather
subjective. Further, we have looked at the
recommendations from a user viewpoint. In the
manner the recommendations are returned currently,
we have realised that their interpretation may need
Case Model for the RoboInnoCase Recommender System for Cases of Digital Business Transformation: Structuring Information for a Case
of Digital Change
prior knowledge of the case model, meaning that the
logic would have to be extracted by the user him- or
In this paper, we have developed a case model to
structure cases of digital transformation that act as
input data for the RS RoboInnocase. The case for
digital change, which represents the output data of the
RoboInnoCase, serves the inspiration phase of the
management’s initiatives concerning the company’s
own digital transformation. The output data of the
RoboInnoCase contains recommendations concerning
the possible area of the business transformation, how it
could be transformed and the possible improvements
of the change.
The case model of RoboInnoCase is defined along
the four building blocks of the Transformation
Compass, namely organisational excellence, customer
centricity, operational excellence, and business model.
Additionally, the results of the analysis of past cases of
digital transformation constituted a further
fundamental contribution to its definition. The final
case model contains four sets, “general” (G),
“problem” (P), “solution” (S), and “outcome” (O).
Thus, each case is defined by the union of these
nonoverlapping sets. The building blocks of the digital
transformation are a central part of the “solution” set.
The case model follows a hierarchical, object-oriented
case representation, meaning that a case consists of
various objects represented at numerous levels of detail
which are each described by various attribute-value
Our results concerning the functionality of the case
model as well as the quality of the given
recommendations indicate that the case model is
suitable to the needs of a case for change concerning
digital business transformation. In terms of similarity,
we weighted the most relevant attributes, calculated by
the entropy, in a query higher than the remaining
attributes. By doing so, the results that were returned
were quite accurate. By implementing a first prototype
of the RoboInnoCase, the assumptions made for both
scenarios held true in the test run. Furthermore, the
assumed exact similarity, achieved by weighting
certain attributes differently, makes the given
recommendations more accurate.
To improve the comprehensibility of the keywords
in the solution, we suggest applying text mining
methods as well as collecting a larger case base. Lastly,
we highly recommend implementing a genuine form of
RoboInnoCase which could then be customised to the
proposed case model.
In this work, one could highlight the advantages of
the RS for individual companies as well as serve as a
basis for the creation of a model to define best
Aamodt, A., and Plaza, E. (1994). Case-based reasoning:
Foundational issues, methodological variations, and
system approaches. AI Communications, 7(1), 3959.
Aggarwal, C. C. (2016). Knowledge-based recommender
systems. In Recommender systems (pp. 167197).
Bergmann, R. (2002). Experience Management:
Foundations, Development Methodology, and Internet-
Based Applications (Vol. 2432). Berlin, Heidelberg:
Bergmann, R., Althoff, K.-D., Minor, M., Reichle, M., and
Bach, K. (2009). Case-Based Reasoning - Introduction
and Recent Developments. Künstliche Intelligenz.
Bergmann, R., Kolodner, J., and Plaza, E. (2005).
Representation in case-based reasoning. The Knowledge
Engineering Review, 00:0(14), 14.
Bergmann, R., and Schaaf, M. (2003). Structural Case-Based
Reasoning and Ontology-Based Knowledge
Management: A Perfect Match? Journal of Universal
Computer Science, 9(7), 608626.
Bridge, D., Göker, M. H., McGinty, L., and Smyth, B.
(2005). Case-based recommender systems. The
Knowledge Engineering Review, 20(03), 315320.
Choudhury, N., and Begum, S. A. (2016). A survey on case-
based reasoning in medicine. International Journal of
Advanced Computer Science and Applications, 7(8),
Dobni, C. B., Klassen, M., and Nelson, W. T. (2015).
Innovation strategy in the US: top executives offer their
views. Journal of Business Strategy, 36(1), 313.
Retrieved from
Dr. Kraus and Partner. (n.d.). Case for Change - Definition.
Retrieved November 24, 2018, from https://www.kraus-
El-Sappagh, S. H., and Elmogy, M. (2015). Case Based
Reasoning: Case Representation Methodologies.
International Journal of Advanced Computer Science
and Applications, 6(11), 192208.
Eurostat. (2015). Archive:Business economy by sector -
NACE Rev. 1.1. Retrieved January 3, 2019, from
Felfernig, A., and Burke, R. (2008). Constraint-based
recommender systems: technologies and research issues.
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
In Proceedings of the 10th international conference on
Electronic commerce (p. 3).
Furnas, G. W., Landauer, T. K., Gomez, L. M., and Dumais,
S. T. (1987). The vocabulary problem in human-system
communication. Communications of the ACM, 30(11),
Gable, G. (2003). Consultants and knowledge management.
Journal of Global Information Management, 11(3), i--i.
Gatziu Grivas, S., Peter, M., Heeb, D., Lanaia, A.,
Zimmermann, P., and Graf, M. (2018). The Panoramic
Lens Model. In 2018 IEEE International Conference on
Engineering, Technology and Innovation (ICE/ITMC).
IEEE, pp. 17. doi: 10.1109/ICE.2018.8436286.
Graf, M., Peter, M., and Gatziu Grivas, S. (2018). Foster
strategic Orientation in the Digital Age - A methodic
approach for guiding SME to a Digital Transformation.
HWZ, and localsearch. (2018). Schweizer KMU fehlt es an
digitalem Fachwissen Digital Switzerland 2017.
Retrieved October 12, 2018, from https://fh-
Jacoby, J. (2012). How to develop a powerful case for
change. Retrieved November 24, 2018, from
Jones, J., Aguirre, D., and Calderone, M. (2004). 10
principles of change management. Retrieved from
Kolodner, J. L. (1991a). Improving Human Decision Making
through Case-Based Decision Aiding. AI Magazine,
12(2), 5268.
Kolodner, J. L. (1991b). Improving Human Decision Making
through Case-Based Decision Aiding. AI Magazine,
12(2), 5268.
Kolodner, J. L. (1992). An introduction to case-based
reasoning. Artificial Intelligence Review, 6(1), 334.
Lika, B., Kolomvatsos, K., and Hadjiefthymiades, S. (2014).
Facing the cold start problem in recommender systems.
Expert Systems with Applications, 41(4), 20652073.
Lott, B. (2012). Survey of keyword extraction techniques.
UNM Education, 50.
Mansar, S. L., Marir, F., and Reijers, H. A. (2003). Case-
based reasoning as a technique for knowledge
management in business process redesign. Electronic
Journal on Knowledge Management, 1(2), 113124.
Nissen, V., and Seifert, H. (2017). Die digitale
Transformation der Unternehmensberatung. In
Dienstleistungen 4.0 (pp. 411443). Springer.
Osterwalder, A., Pigneur, Y., Oliveira, M. A.-Y., and
Ferreira, J. J. P. (2011). Business Model Generation: A
handbook for visionaries, game changers and
challengers. African Journal of Business Management,
5(7), 2230.
Pazzani, M. J., and Billsus, D. (2007). Content-based
recommendation systems. In The adaptive web (pp. 325
341). Springer.
Peter, M., Graf, M., Gatziu Grivas, S., and Giovanoli, C.
(2018). Die ABILI-Methodik : Inspiration und
Navigation bei der Digitalen Transformation mit Fokus
auf KMU. Arbeitsberichte Der Hochschule Für
Wirtschaft FHNW, (36), 117. Retrieved from
PwC Schweiz. (2016). Digitalisierung-wo stehen Schweizer
KMU? Retrieved from
Ricci, F., Rokach, L., and Shapira, B. (2011). Introduction to
Recommender Systems. In Recommender Systems
Handbook (Vol. 532, pp. 135). Springer Science +
Business Media.
Rissland, E. L., Ashley, K. D., and Branting, L. K. (2005).
Case-based reasoning and law. The Knowledge
Engineering Review, 20(3), 293298.
Schafer, J. Ben, Frankowski, D., Herlocker, J., and Sen, S.
(2007). Collaborative filtering recommender systems. In
The adaptive web (pp. 291324). Springer.
The Change Source. (2013). How to build a case for change.
Retrieved November 24, 2018, from
Tiihonen, J., and Felfernig, A. (2010). Towards
recommending configurable offerings. International
Journal of Mass Customisation, 3(4), 389406.
Vaishnavi, V., and Kuechler, W. (2004). Design Research in
Information Systems - Overview of Design Science
Research. AIS, 45.
Westerman, G., Calméjane, C., Bonnet, D., Ferraris, P., and
McAfee, A. (2011). Digital Transformation: A Road-
Map for Billion-Dollar Organizations. Capgemini
Consulting & MIT Sloan Management. Retrieved from
Witschel, H. F., and Martin, A. (2018a). Random Walks on
Human Knowledge: Incorporating Human Knowledge
into Data-Driven Recommenders. Retrieved from
Witschel, H. F., and Martin, A. (2018b). Random Walks on
Human Knowledge: Incorporating Human Knowledge
into Data-Driven Recommenders.
Case Model for the RoboInnoCase Recommender System for Cases of Digital Business Transformation: Structuring Information for a Case
of Digital Change