DEMO Construction Model Generation Process from Business Model
Canvas
Novandra Rhezza Pratama and Junichi Iijima
Department of Industrial Engineering and Economics, Tokyo Institute of Technology, Tokyo, Japan
Keywords: System Development Process, DEMO Construction Model, Business Model Canvas.
Abstract: Enterprise engineering is a discipline aspect of enterprise, including designing and modelling a system. In
system development process, a construction of Using System is developed into function of Object System,
and then continued with development of construction of Object System. Construction can be represented by
DEMO Construction Model and function can be represented by Business Model Canvas. To manipulate a
function system, we need to define a specification or construction of that system. Therefore we need to be
able to generate a construction from a function. This study attempts to create a linkage between Business
Model Canvas and DEMO Construction Model as a construction design process. A methodology of
generating DEMO Construction Model from Business Model Canvas is proposed. Case study of City
Logistics is used to illustrate the proposed methodology. We found the correspondence between Business
Model Canvas and DEMO Construction Model, and the proposed methodology proved to be able to create
DEMO Construction Model from Business Model Canvas through step-by-step process.
1 INTRODUCTION
Enterprise engineering is a discipline aspect of
enterprise, including design and modelling a system.
A real-life system or a Using System (US) can be
represented as an Object System (OS) consists of
functional model and system ontology (Dietz, 2005).
The representation process of OS from US is further
developed into system development process (Dietz,
2006), as seen in Figure 1.
Figure 1: System Development Process (Dietz, 2006).
Construction of an enterprise can be represented
by DEMO (Design & Engineering Methodology for
Organizations) (Dietz, 2006), in particular DEMO
Construction Model, one of the aspect models of
DEMO. DEMO is a methodology of enterprise
ontology (Albani and Dietz, 2011) presenting aspect
models of an enterprise and method for the
development (Dietz, 2006), and the only approach
that produce a truly ontological models (Perinforma,
2015).
One of popular representatives of function of an
enterprise is a Business Model. In recent years,
Business Model is getting more relevance in
information system fields (Salgado et al., 2014).
Business Model, as a tool for management (Magretta,
2002), represents activities of a company (Wirtz et
al., 2016). One of the established business model
template is Business Model Canvas (Osterwalder
and Pigneur, 2010) that expresses the building block
of a given business serving as a value or function of
the business, and one of the most used frameworks
of business models.
A function system, or a black box model, is a
dominant yet vague sort of model, and does not
explicitly shows any information about construction
(Dietz, 2006). Meanwhile, a construction system can
be decomposed into several subsystems, and those
subsystems can be merged into another construction
system (Suga and Iijima, 2015).
Therefore, to manipulate a function system, we
need to define a specification or construction of that
system. This leads to motivation of this paper, to
connect function with construction of a system by
generating a construction from a function as a
construction design process.
384
Pratama, N. and Iijima, J.
DEMO Construction Model Generation Process from Business Model Canvas.
DOI: 10.5220/0006805503840392
In Proceedings of the 20th International Conference on Enterprise Information Systems (ICEIS 2018), pages 384-392
ISBN: 978-989-758-298-1
Copyright
c
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
There are several researches that links DEMO as
a construction with function in the system
development process, such as e3Value (Pombinho,
Tribolet, and Aveiro, 2014), and Organizational
Implementation (Op’t Land and Krouwel, 2013).
However, there is no clear representation of business
model as a function, especially Business Model
Canvas. Therefore we need to find the connections
between Business Model Canvas and DEMO
Construction Model. These statements lead to the
following research questions:
1. What is the correspondence between Business
Model Canvas and DEMO Construction Model?
2. How can we generate DEMO Construction
Model from Business Model Canvas?
2 BACKGROUND
2.1 Business Model Canvas
Business Model Canvas (BMC) (Osterwalder and
Pigneur, 2010), is a strategic management tool for
developing a new business model, or simply capture
the existing one (Salgado et al., 2014). BMC was
firstly introduced as a new design science approach
of business model ontology (Osterwalder, 2004).
BMC is popular in its way to pinpoint the essential
elements on a business as leverage for innovation
(Martikainen, Niemi, and Pekkanen, 2014).
BMC has 9 building blocks as a representation
of business activity (Osterwalder and Pigneur, 2010).
Figure 2 illustrates BMC and the building blocks.
In the BMC, the building blocks are positioned
according to their classification. The left side of the
canvas represents the internal business of the
company on how to create business values, whereas
the right side represents the customer side of the
business and how to deliver those values. The
bottom side can also be classified as a financial
aspect of the business.
2.2 DEMO Construction Model
DEMO Construction Model (CM) indicates
transaction kinds and actor roles associated with
them and also information links between them, or in
simplified term, the construction of the organization
(Perinforma, 2015). A Transaction Kind represents
coordination act/fact in a business conversation, and
an Actor Role represents the initiator/executor of
such coordination. CM is a part of four aspect
models expressing the ontological knowledge of the
target enterprise. The other aspect models are
Process Model (PM), Action Model (AM), and Fact
Model (FM).
In this study we only focus on the coordination
part, or interaction model of CM of an organization,
which contains Actor Transaction Diagram (ATD)
and Transaction Product Table (TPT). These two
composed the interaction structure of an
Figure 2: Business Model Canvas (Osterwalder & Pigneur, 2010).
DEMO Construction Model Generation Process from Business Model Canvas
385
organization (Dietz, 2006). Figure 3 expresses an
example of ATD and TPT of an organization, we
use an example of simple retail shop that sells a
product. The ATD can be created using online
modeling tool for process design and animation from
www.demoworld.nl,.
Transaction Kinds
Product Kinds
T1 Product Selling
Product selling has been completed
T2 Product Payment
Product fee has been paid
Figure 3: Example ATD and TPT of an organization.
3 GENERATING DEMO
CONSTRUCTION MODEL
FROM BUSINESS MODEL
CANVAS
In this section, we will explain our proposed
methodology. The methodology is divided into two
parts, the first part is DEMO-Oriented BMC
generation from BMC, and the second part is DEMO
Construction Model generation from DEMO-
Oriented BMC.
3.1 DEMO-Oriented Business Model
Canvas
To make conversion from BMC into construction
model easier, the authors propose a new concept:
DEMO-Oriented Business Model Canvas (BMC).
DEMO-Oriented BMC is a specified BMC that
includes components of organizational building
blocks of DEMO Construction Model, which are
actor role and transaction kind. Each building block
in BMC may contain either of actor roles or
transaction kinds, both of them, or none of them. All
items in each building block are given notation to
identify which building blocks they belong to, in
order to ease the identification and conversion
process. The notation pattern is NNm where NN
indicates building block notation and m indicates
element number. The building block notations are
given based on original BMC’s notations
(Osterwalder and Pigneur, 2010).
These steps also involve decision making about
contents of building blocks in DEMO-Oriented
BMC, and eventually DEMO CM. Given that a
functional model can have many different
construction models depends on scope of interest,
the resulting DEMO-Oriented BMC may differ.
Therefore, this phase cannot be done automatically.
Below is the proposed description of each
building block in DEMO-Oriented BMC:
1) Customer Segments
This building block consists of target customer
that the company intends to deliver its value, and is
an Actor Role denoted as CSm.
2) Value Propositions
This building block consists of value delivered
by the company, and has no appropriate
correspondence in construction model, and is
denoted as VPm.
3) Channels
This building block represents the way of
communication, not the communication itself, so
that there is no appropriate correspondence in
construction model, and is denoted as CHm.
4) Customer Relationships
This building block consists of activities by the
company to support the customer, and is a
Transaction Kind denoted as CRm.
5) Revenue Streams
This building block consists of payment
activities that is done by the customer, and is a
Transaction Kind denoted as R$m.
6) Key Resources
This building block consists of resources within
the company, which are:
Human Resources is an Actor Role denoted as
KR-Hm, and/or
Other resources like facilities and knowledge are
included, but not a part of construction model,
and denoted as KR-Fm.
7) Key Activities
This building block consists of activities that are
conducted by the company to provide value to their
customer, and contains a Transaction Kind denoted
as KAm.
8) Key Partners
This building block consists of two parts, which
are:
ICEIS 2018 - 20th International Conference on Enterprise Information Systems
386
Supplier or partner that is an Actor Role denoted
as KP-Am, and/or
Activities provided by them to the company that
is a Transaction Kind denoted as KP-Tm.
9) Cost Structure
This building block consists of activities in a
company that incurred costs to the company, and is a
Transaction Kind that can be divided as:
External Transaction Kinds (related to external
actor roles) are denoted as C$-Em, and/or
Internal Transaction Kinds (not related to
external actor roles) are denoted as C$-Im.
To summarize, Table 1 shows the proposed
correspondence table between Business Model
Canvas and DEMO Construction Model. This table
acts as a guideline to determine the entities in each
building block of DEMO-Oriented BMC.
Table 1: Correspondence between BMC and CM concepts.
Business Model Canvas
Construction Model
Customer Segments
Actor Roles
Value Propositions
-
Channels
-
Customer Relationships
Transaction Kinds
Revenue Streams
Transaction Kinds
Key Resources
Actor Roles
Key Activities
Transaction Kinds
Key Partners
Actor Roles, Transaction
Kinds
Cost Structure
Transaction Kinds
We can generate DEMO-Oriented BMC directly
from description on business, or convert it from a
standard BMC. The step-by-step process of DEMO-
Oriented BMC Generation is explained as follows:
STEP 1 : Identify all parties
The first step is to identify all parties involved in the
business that is stated in existing BMC. Involved
party can be divided as internal (e.g. human
resources) and external (e.g., supplier or customer).
Then write it as a noun in their respective building
blocks. These will represent Actor Roles in the
DEMO CM.
STEP 2 : Identify all activities
The next step is to identify all activities of business
coordination stated in existing BMC, also other
activities initiated or executed by parties that are
identified from the previous step. If there is a
payment activity, indicate it clearly. Then write it as
a noun in their respective building blocks. These will
represent Transaction Kind in the DEMO CM.
STEP 3 : Identify any other information
The next step is to identify any other necessary
information to be written in DEMO-Oriented BMC.
These usually include values obtained from the
business, channels to deliver value, or company
resources. These will not represent any components
in DEMO CM, and act as a complementary of
DEMO-Oriented BMC.
STEP 4 : Make sure that all activities has all initiator
and executor written
The final step is to check that all activities has all
initiator and executor written in DEMO-Oriented
BMC. Sometimes there is missing information of
who is the initiator or executor of an activity in the
standard BMC. As DEMO CM needs all information
of the Actor Roles that become initiator and
executor of all Transaction Kinds, this missing
information of initiator/executor of an activity has to
be filled. The filled information, and the resulting
DEMO-Oriented BMC, should be verified by the
stakeholders of the business.
3.2 Generating DEMO Construction
Model
After DEMO-Oriented BMC is completed, we can
generate DEMO Construction Model. DEMO CM
Generation process from DEMO-Oriented BMC is
explained as follows:
STEP 1 : Identify Transaction Kinds
The first step is to identify any transaction kind in
the BMC. Identify any activity that is initiated or
executed by the company in the BMC that can be
considered as a transaction kind, then make the table
of its notation and the transaction kind.
STEP 2 : Identify Actor Roles
The next step is to identify any actor role in the
BMC. Identify any party that is involved in this
business and stated in BMC that can be considered
as an actor role. Also identify the type of the actor
role, whether it is internal or environmental actor
role, then make table of its notation, actor role, and
type.
STEP 3 : Generate Transaction Product Table
The next step is to generate one part of DEMO CM,
which is Transaction Product Table (TPT). Identify
the Product Kind for each identified transaction.
Draw Transaction Product Table consists of
Transaction Kind and Product Kind.
STEP 4 : Generate Actor Transaction Table
The next step is to generate Actor Transaction Table
as a baseline to create Actor Transaction Diagram
DEMO Construction Model Generation Process from Business Model Canvas
387
later. Identify the initiator and executor for each
transaction kinds from the identified actor roles.
Draw Actor Transaction Table consists of
Transaction Kind, Initiator and Executor. To aid
this process, we propose actor-transaction relation
table (Table 2).
Table 2: Actor-Transaction Relation.
Transaction
Building Block
Initiator Building
Block
Executor Building
Block
Key Activities
(KA)
Customer Segment
(CS)
Key Resources
(KR)
Revenue
Streams (R$)
Key Resources
(KR)
Customer Segment
(CS)
Customer
Relationships
(CR)
Customer Segment
(CS)
Key Resources
(KR)
Key Partners
(KP-T)
Key Resources
(KR)
Key Partners (KP-
A)
Cost Structure
(C$-E)
Key Partners (KP-
A)
Key Resources
(KR)
Cost Structure
(C$-I)
Key Resources
(KR)
Key Resources
(KR)
We determined the initiator and executor building
block for each respective transaction building block.
STEP 5 : Produce Actor Transaction Diagram
The last step is to produce other part of DEMO CM,
which is Actor Transaction Diagram, thus
completing DEMO CM. Draw Actor Transaction
Diagram based on Actor Transaction Table. The
resulting Actor Transaction Diagram then verified
whether it is suitable and valid as a construction
model of the business.
4 CASE STUDY: CITY
LOGISTICS
In this section, we attempt to test our proposed
methodology to a City Logistics Case, as a case
study. City Logistics (Quak, Balm, and Posthumus,
2014) is a study of developing a Bentobox as a
business model of a city logistics and delivery
service. The Bentobox is a delivery station with
removable trolleys to deliver goods within the city.
Operators can deliver the parcels to the recipients, or
the recipients can take the parcels themselves from
the delivery station after receiving username and
password from operators. A Business Model Canvas
of this case is already provided, and can be seen in
Figure 4.
4.1 DEMO-Oriented Business Model
Canvas of City Logistics
The first phase is to create the DEMO-Oriented
BMC from the existing BMC. For the length of this
paper, we only present brief explanation. We applied
ICEIS 2018 - 20th International Conference on Enterprise Information Systems
388
the four steps proposed in Section 3.1 here.
STEP 1 : Identify all parties
The parties or actors involved in this business and
stated in the BMC are all identified. They are
included in their respective building blocks:
Key Partners: KP-A1 Bentobox Supplier and
KP-A2 Vehicle Supplier
Key Resources: KR-H1 Driver
Customer Segments: CS1 Small Shop Owner
STEP 2 : Identify all activities
The business activities or transaction that stated in
the BMC can be identified. Bentobox should be
renamed as Bentobox Payment to indicate payment
transaction, and Delivery Collection should be
renamed as Delivery Payment for the same reason.
Loading & Unloading and Sent an E-mail is part of
business activity of Delivery Completion. Self-
Service and Personal Delivery is part of business
activity of Customer Support. Insurance and
Software is part of Operation & Maintenance in the
internal of the company. Training is the business
activity of HR Training, also in the internal of the
company.
The business activities that initiated or executed
by parties identified in Step 1 can also be identified.
Bentobox Supplier executed Bentobox Supply and
initiated Bentobox Payment, and Vehicle Supplier
executed Vehicle Supply and Vehicle Payment.
Driver executed Goods Delivery, that is part of a
Cost Structure building block, because the delivery
itself incurred cost to the company. Small Shop
Owner initiated Delivery Completion and Customer
Support, and executed Delivery Payment.
These activities then included in their respective
building blocks:
Key Partners: KP-T1 Bentobox Supply and
KP-T2 Vehicle Supply
Key Activities: KA1 Delivery Completion
Customer Relationships: CR1 Customer
Support
Cost Structure: C$-E1 Bentobox Supply
Payment, C$-E2 Vehicle Supply Payment, C$-
I1 HR Training, C$-I2 Operation &
Maintenance, and C$-I3 Goods Delivery
Revenue Streams: R$1 Delivery Payment
STEP 3 : Identify any other information
The other necessary information to be written in
DEMO-Oriented BMC can be identified from other
components that are neither an actor nor a
transaction, or part of them. For the sake of
simplicity, we only write them as-is form the
existing BMC, and included in their respective
building blocks:
Key Resources: KR-F1 Vehicle, KR-F2
Software, KR-F3 Bentobox, and KR-F4
Bentobox Location
Value Proposition: VP1 Reliable, VP2 Flexible,
and VP3 Less Disruption & Emission
Channels: CH1 Bentobox Touch Screen and
CH2 Email
STEP 4: Make sure that all activities has all initiator
and executor written
In this step, each transaction is checked whether they
have their respective initiator and executor written in
DEMO-Oriented BMC. If such initiator and
executor are not yet stated in the BMC, a new parties
or actors needs to be defined, and include them in
their appropriate building blocks. This step involves
decision making and verification, whether the newly
defined actors are actually involved in the business.
After the process, we found out that the following
information should be added in the DEMO-Oriented
BMC:
Key Resources: KR-H2 Delivery Manager,
KR-H3 Customer Service Manager, KR-H4
HR Manager, KR-H5 Operation Manager, KR-
H6 Bentobox Purchasing Manager, and KR-H7
Vehicle Manager
The resulting DEMO-Oriented BMC can be seen
in Figure 5. Note that there is no difference in
building blocks compared to other BMC, only the
content of each building block is specified to
organizational building blocks of DEMO CM.
4.2 Generating DEMO Construction
Model of City Logistics
After DEMO-Oriented BMC is created, we proceed
to the next phase proposed in Section 3.2.
STEP 1 : Identify Transaction Kinds
Using Table 1, we can identify Transaction Kinds
from DEMO-Oriented BMC. Those are Delivery
Completion, Delivery Payment, Customer Support,
Bentobox Supply, Vehicle Supply, Bentobox Supply
Payment, Vehicle Supply Payment, HR Training,
Operation Management, and Goods Delivery.
DEMO Construction Model Generation Process from Business Model Canvas
389
STEP 2 : Identify Actor Roles
Again, using Table 1, we can identify Actor Roles
from DEMO-Oriented BMC. Those are Bentobox
Supplier, Vehicle Supplier, Driver, Delivery
Manager, Customer Service Manager, HR Manager,
Operation Manager, Bentobox Purchasing Manager,
Vehicle Manager, and Small Shop Owner.
STEP 3 : Generate Transaction Product Table
Based on results in STEP 2, we can generate
Transaction Product Table after the Product Kinds of
each Transaction Kinds are identified. The resulting
TPT can be seen in Table 3.
STEP 4 : Generate Actor Transaction Table
Based on the rule in Table 2, we can identify and
draw the Actor Transaction Table of City Logistics.
The result can be seen in Table 4.
STEP 5 : Produce Actor Transaction Diagram
Finally we can produce Actor Transaction Diagram
to complete generation process based on Table 6.
The resulting ATD (Figure 6) is suitable to represent
a construction model of City Logistics.
Table 3: Transaction Product Table of City Logistics.
T No.
Transaction
Kinds
P No.
Product Kinds
T01
Delivery
Completion
PP01
Delivery has been
completed
T02
Goods Delivery
PP02
Goods has been
delivered
T03
Delivery Payment
PP03
Delivery fee has
been paid
T04
Customer Support
PP04
Customer support
has been done
T05
Bentobox Supply
PP05
Bentobox supply
has been done
T06
Bentobox Supply
Payment
PP06
Bentobox fee has
been paid
T07
Vehicle Supply
PP07
Vehicle supply has
been done
T08
Vehicle Supply
Payment
PP08
Vehicle fee has
been paid
T09
HR Training
PP09
HR Training has
been done
T10
Operation &
Maintenance
PP10
Operation &
Maintenance has
been done
Figure 5: DEMO-Oriented BMC of City Logistics.
ICEIS 2018 - 20th International Conference on Enterprise Information Systems
390
Table 4: Actor Transaction Table of City Logistic.
Transaction
Kinds
Initiator
Executor
Delivery
Completion
Small Shop
Owner
Delivery Manager
Goods Delivery
Delivery
Manager
Driver
Delivery Payment
Delivery
Manager
Small Shop Owner
Customer Support
Consumer
Customer Service
Manager
Bentobox Supply
Bentobox
Purchasing
Manager
Bentobox Supplier
Bentobox Supply
Payment
Bentobox
Supplier
Bentobox
Purchasing
Manager
Vehicle Supply
Vehicle Manager
Vehicle Supplier
Vehicle Supply
Payment
Vehicle Supplier
Vehicle Manager
HR Training
HR Manager
HR Manager
Operation &
Maintenance
Operation
Manager
Operation Manager
5 DISCUSSION
This paper proposed the correspondence between
business model and construction model, in particular
Business Model Canvas and DEMO Construction
Model. The important finding of this research is that
we found the correspondence links between BMC as
a function design, and DEMO CM as a construction
design. The case study of City Logistics also
explains the methodology of process of conversion
from BMC to CM, with a step-by-step process. We
found the correspondence between Business Model
Canvas and DEMO Construction Model, and the
proposed methodology proved to be able to create
DEMO Construction Model from Business Model
Canvas through step-by-step process, thus answered
our research question.
The introduction of correspondence table and
actor-transaction relation table are very useful to
help the generation process, in particular the
conversion from DEMO-Oriented BMC to DEMO
CM. The resulting TPT and ATD are able to show
the construction of the business in the form of
DEMO CM, generated from BMC.
This research has some limitations, however, that
the formulation of DEMO-Oriented BMC should be
refined further. In particular the identification of
missing actor roles or transaction kinds, and the
validation; to further enhance this, the conversion
method should be tested to another type of business.
A comparative study across several business models
can also be conducted. Also this process should be
reversible; one can create a BMC from a given CM.
Figure 6: Actor Transaction Diagram of City Logistics.
DEMO Construction Model Generation Process from Business Model Canvas
391
A methodology of BMC Generation from DEMO
CM can be developed as a reverse process of this
paper. The void in the correspondence table, that is
no correspondence of Value Proposition and
Channels, gives the opportunity for DEMO
researchers to identify these building blocks
corresponds to which components in DEMO.
6 CONCLUSION
In this paper we proposed a methodology to generate
DEMO Construction Model from Business Model
Canvas. We found the correspondence between
building blocks in Business Model Canvas and
DEMO Construction Model. We suggest DEMO-
Oriented BMC as a specified BMC containing the
organizational building blocks of DEMO CM, and
step-by-step process to create it. We propose DEMO
CM generation step-by-step process from DEMO-
Oriented BMC.
In this paper, we only focused on generating
Object System construction from Object System
function; Object System function generation from
Using System is outside the scope of this research.
This paper only proposed a methodology to generate
DEMO Construction Model from Business Model
Canvas, not the other way around. A comparative
study across several business models is not yet
conducted.
This paper visualized the connection between
BMC as an Object System function and DEMO CM
as an Object System construction. This paper can
contribute to adding an alignment between Object
System function and Object System construction, as
a part of system development process.
This paper can give some insights about future
research related to this work. Formulation of
DEMO-Oriented BMC can be refined further. A
methodology of BMC Generation from DEMO
Construction model can be developed as a reverse
process of this paper. A comparative study across
several business models can also be conducted. By
using proposed methodology in this paper and future
studies, we hope that we can gather several business
models, generate construction models from them and
create a pool of submodels, modify them to create a
new construction model, and generate a new
business model to create a new business.
ACKNOWLEDGEMENTS
This work has been supported by Indonesia
Endowment Fund for Education (LPDP).
REFERENCES
Albani, A., and Dietz, J. L. (2011). Enterprise ontology based
development of information systems. International
Journal of Internet and Enterprise Management, 7(1), 41-
63.
Dietz, J.L. (2005) •System ontology and its role in system
development, in Castro, J. and Teniente, E. (Eds.):
Advanced Information Systems Engineering Workshops
(CAiSE 2005), Vol. 2 of FEUP Edicoes, Porto, Portugal,
pp.273284.
Dietz, J. L. (2006). Enterprise ontology: theory and
methodology. Springer Science and Business Media.
Magretta, J., 2002. Why Business Models Matter. Harvard
Business Review 80 (5), 86-92.
Martikainen, A., Niemi, P., and Pekkanen, P. (2014).
Developing a service offering for a logistical service
providerCase of local food supply chain. International
Journal of Production Economics, 157, 318-326.
Op’t Land, M., and Krouwel, M. (2013). Exploring
organizational implementation fundamentals.
In Enterprise Engineering Working Conference(pp. 28-
42). Springer, Berlin, Heidelberg.
Osterwalder, A. (2004). The business model ontology: A
proposition in a design science approach.
Osterwalder, A., and Pigneur, Y. (2010). Business model
generation: a handbook for visionaries, game changers,
and challengers. John Wiley & Sons.
Perinforma, A. P. C. (2015). The Essence of Organisation: An
Introduction to Enterprise Engineering. Sapio Enterprise
Engineering.
Pombinho, J., Tribolet, J., and Aveiro, D. (2014). Linking
Value Chains-Combining e3Value and DEMO for
Specifying Value Networks. In EEWC (pp. 105-119).
Quak, H., Balm, S., and Posthumus, B. (2014). Evaluation of
city logistics solutions with business model analysis.
Procedia-Social and Behavioral Sciences, 125, 111-124.
Salgado, C. E., Teixeira, J., Machado, R. J., and Maciel, R. S.
(2014). Generating a Business Model Canvas through
Elicitation of Business Goals and Rules from Process-
level Use Cases. In International Conference on Business
Informatics Research (pp. 276-289). Springer, Cham.
Suga, T., and Iijima, J. (2015) Does ‘Merging DEMO Models’
satisfy the associative law? - Validation of partial models
and merge operation. In Proceedings of the 7
th
International Joint Conference on Knowledge Discovery,
Knowledge Engineering and Knowledge Management,
vol. 2, pp. 467478.
Wirtz, B. W., Pistoia, A., Ullrich, S., and Göttel, V. (2016).
Business models: Origin, development and future
research perspectives. Long Range Planning, 49(1), 36-54.
ICEIS 2018 - 20th International Conference on Enterprise Information Systems
392