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.

INTRODUCTION

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

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

change.

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.

RELATED WORK

2.1 The Core of Digital Business

Transformation

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

Nutshell

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

abstraction”.

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.

RESEARCH METHODOLOGY

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’

quality.

DEFINING THE CASE MODEL

FOR THE RECOMMENDER

SYSTEM ROBOINNOCASE

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

situation.

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

measures.

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

competitiveness).

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):

        

(1)

Moreover, the union of all cases defines the case base:





 







 







(2)

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 called “Company 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 solution” as 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/Advantages” objects 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/advantages” objects 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}

(3)

Where Name(A) = name, Type(A) = type, Value(A) =

value.

Thus, a case 



 of digital transformation can be

represented by a set of attribute-value pairs:











 





 





   







(4)

Where 





  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.

EVALUATION

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

distribution 



. The entropy

  



















(5)

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

are:

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 type “choice”, 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

performance, CUSTOMER-SEGMENTS

segmented, BUSINESS-RELATION b2c,

CUSTOMER-RELATIONSHIPS personal

assistance, CHANNELS own direct,

REVENUE- STREAMS usage fee, KEY-

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

sector}

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

herself.

CONCLUSION

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

pairs.

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

practices.

REFERENCES

Aamodt, A., and Plaza, E. (1994). Case-based reasoning:

Foundational issues, methodological variations, and

system approaches. AI Communications, 7(1), 39–59.

Aggarwal, C. C. (2016). Knowledge-based recommender

systems. In Recommender systems (pp. 167–197).

Springer.

Bergmann, R. (2002). Experience Management:

Foundations, Development Methodology, and Internet-

Based Applications (Vol. 2432). Berlin, Heidelberg:

Springer.

Bergmann, R., Althoff, K.-D., Minor, M., Reichle, M., and

Bach, K. (2009). Case-Based Reasoning - Introduction

and Recent Developments. Künstliche Intelligenz.

https://doi.org/10.1007/978-3-642-39056-2_1

Bergmann, R., Kolodner, J., and Plaza, E. (2005).

Representation in case-based reasoning. The Knowledge

Engineering Review, 00:0(1–4), 1–4.

https://doi.org/10.1017/S000000000000000

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), 608–626.

Bridge, D., Göker, M. H., McGinty, L., and Smyth, B.

(2005). Case-based recommender systems. The

Knowledge Engineering Review, 20(03), 315–320.

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),

136–144.

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), 3–13.

Retrieved from https://www.emeraldinsight.com/doi/

pdfplus/10.1108/JBS-12-2013-0115

Dr. Kraus and Partner. (n.d.). Case for Change - Definition.

Retrieved November 24, 2018, from https://www.kraus-

und-partner.de/wissen-und-co/wiki/case-for-change

El-Sappagh, S. H., and Elmogy, M. (2015). Case Based

Reasoning: Case Representation Methodologies.

International Journal of Advanced Computer Science

and Applications, 6(11), 192–208.

https://doi.org/10.14569/IJACSA.2015.061126

Eurostat. (2015). Archive:Business economy by sector -

NACE Rev. 1.1. Retrieved January 3, 2019, from

https://ec.europa.eu/eurostat/statistics-explained/index.

php?title=Archive:Business_economy_by_sector_-

_NACE_Rev._1.1

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),

964–971.

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. 1–7. 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.

IDEA.

HWZ, and localsearch. (2018). Schweizer KMU fehlt es an

digitalem Fachwissen – Digital Switzerland 2017.

Retrieved October 12, 2018, from https://fh-

hwz.ch/news/digital-switzerland-2017/

Jacoby, J. (2012). How to develop a powerful case for

change. Retrieved November 24, 2018, from

http://blog.emergentconsultants.com/2012/01/29/how-

to-develop-a-powerful-case-for-change/

Jones, J., Aguirre, D., and Calderone, M. (2004). 10

principles of change management. Retrieved from

https://www.strategy-business.com/article/rr00006?gko

=643d0

Kolodner, J. L. (1991a). Improving Human Decision Making

through Case-Based Decision Aiding. AI Magazine,

12(2), 52–68. https://doi.org/10.1609/AIMAG.

V12I2.895

Kolodner, J. L. (1991b). Improving Human Decision Making

through Case-Based Decision Aiding. AI Magazine,

12(2), 52–68.

https://doi.org/10.1609/AIMAG.V12I2.895

Kolodner, J. L. (1992). An introduction to case-based

reasoning. Artificial Intelligence Review, 6(1), 3–34.

Lika, B., Kolomvatsos, K., and Hadjiefthymiades, S. (2014).

Facing the cold start problem in recommender systems.

Expert Systems with Applications, 41(4), 2065–2073.

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), 113–124.

Nissen, V., and Seifert, H. (2017). Die digitale

Transformation der Unternehmensberatung. In

Dienstleistungen 4.0 (pp. 411–443). 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), 22–30.

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), 1–17. Retrieved from

https://kmu-transformation.ch/die-abili-methodik-

inspiration-und-navigation-bei-der-digitalen-

transformation-mit-fokus-auf-kmu/

PwC Schweiz. (2016). Digitalisierung-wo stehen Schweizer

KMU? Retrieved from https://www.pwc.ch/de/

publications/2016/pwc_digitalisierung_wo_stehen_sch

weizer_kmu.pdf

Ricci, F., Rokach, L., and Shapira, B. (2011). Introduction to

Recommender Systems. In Recommender Systems

Handbook (Vol. 532, pp. 1–35). Springer Science +

Business Media. https://doi.org/10.1007/978-0-387-

85820-3

Rissland, E. L., Ashley, K. D., and Branting, L. K. (2005).

Case-based reasoning and law. The Knowledge

Engineering Review, 20(3), 293–298.

Schafer, J. Ben, Frankowski, D., Herlocker, J., and Sen, S.

(2007). Collaborative filtering recommender systems. In

The adaptive web (pp. 291–324). Springer.

The Change Source. (2013). How to build a case for change.

Retrieved November 24, 2018, from

https://de.slideshare.net/thechangesource/how-to-build-

a-case-for-change

Tiihonen, J., and Felfernig, A. (2010). Towards

recommending configurable offerings. International

Journal of Mass Customisation, 3(4), 389–406.

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

https://www.capgemini.com/wp-content/uploads/

2017/07/Digital_Transformation__A_Road-

Map_for_Billion-Dollar_Organizations.pdf

Witschel, H. F., and Martin, A. (2018a). Random Walks on

Human Knowledge: Incorporating Human Knowledge

into Data-Driven Recommenders. Retrieved from

http://insticc.org/node/TechnicalProgram/ic3k/presentati

onDetails/68939

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