=Paper=
{{Paper
|id=Vol-1408/paper3
|storemode=property
|title=Organization Implementation Fundamentals: A Case Study Validation in the Youthcare Sector
|pdfUrl=https://ceur-ws.org/Vol-1408/paper3-tee.pdf
|volume=Vol-1408
}}
==Organization Implementation Fundamentals: A Case Study Validation in the Youthcare Sector==
https://ceur-ws.org/Vol-1408/paper3-tee.pdf
Organization Implementation Fundamentals: a
Case Study Validation in the Youthcare Sector
Sandra van Bockhooven1 , Martin Op ‘t Land12
1
Capgemini Netherlands, P.O. Box 2575, 3500 GN Utrecht, The Netherlands,
{Sandra.van.Bockhooven,Martin.OptLand}@capgemini.com
2
Antwerp Management School, Sint-Jacobsmarkt 9-13, 2000 Antwerp, Belgium
Abstract. Changes in the business environment and healthcare sector
- such as changing laws and regulations, and the continuous shifting of
responsibilities in the cooperation - are forcing enterprises to be agile. To
effectively enable such changes of enterprises in the Healthcare sector,
Capgemini is constantly exploring better ways of a) continuously opti-
mizing business processes and b) building and maintaining inherently
flexible information systems. In 2014-H1 an existing Solution for youth-
care was evaluated by Capgemini and Leiden University to find out its
flexibility towards organizational and process change, using a) previously
proposed Organization Implementation Variables (OIVs) and b) DEMO
as way of thinking and modeling for the essence of any enterprise. Based
upon significantly improved definitions of these OIVs, we were able to
find 70% of the proposed variables in the youthcare practice. A part of
these OIVs were also supported in the Solution as ICT parameters, and
now it became clear to what extent this solution was indeed flexible with
respect to the foreseen changes, also given the Dutch decentralization
laws (3D).
Keywords: DEMO, Organization Implementation Variables, Agile En-
terprise Engineering, case study, Solutions, youthcare
1 Situation
In order to respond to changes in the business environment and healthcare sec-
tor, enterprises want to be more agile. Oosterhout (2010) summarizes several
definitions of agility as “the ability of an organization to swiftly change busi-
nesses and business processes beyond the normal level of flexibility to effectively
manage highly uncertain and unexpected but potentially consequential internal
and external events, based on the capabilities to sense, respond and learn.” En-
terprises are under pressure due to factors such as changing laws and regulations,
and the continuous shifting of responsibilities in cooperation. For instance, the
so-called “three decentralizations” (3D) are “taking place”, which means that
the responsibilities of Provincial and National Government of the Netherlands
with regards to healthcare and youthcare are moving to the municipalities, at
the same time cutting budgets.
Enterprises need to be agile in their products, services and its Quality of
Service, but especially agile in the way the enterprises are implemented in or-
ganization and ICT. Examples of choices in organization implementation are
e.g., splitting or joining responsibilities, order of working or segregation of du-
ties. Examples of choices in ICT implementation are e.g., platforms & devices,
programming frameworks or infrastructure.
For such agility, enterprises want capabilities for continuously optimizing
business processes, and information systems that support the ever-changing busi-
ness (processes) (called Solutions). For that they need a Body of Knowledge
(BoK) on organization and process design, which contains all factors important
for agility. Also enterprises need Solutions that can follow them over time, and
which they preferably can share with other enterprises in the same branch - to
strengthen continuity and enable cost sharing.
This makes it important for Capgemini to invest in such a Body of Knowl-
edge, and in concepts which create flexibility in such Solutions. This fits Capgem-
ini’s ambition to put its customers in the driving seat for steering business agility.
Also Capgemini continuously builds its portfolio of Solutions, usable by many
different customers. In order for Capgemini to scale up in creating such Solu-
tions, it is important to make this knowledge - on elements that have to be
flexible in its Solutions - explicit.
Op ’t Land and Krouwel (2013) state that such agility of organizations con-
cerns several levels:
– the context on which the organizations have to react (e.g. laws, regulations,
competitors); this is the occasion for the agility, which cannot directly be
influenced by the organization, but the organization can choose on which of
these trends to (re)act;
– the function of the organization: its products and services, and the quality
with which it is delivered; agility here means to enable fast starting / stop-
ping with a product or service, or delivering it with a different Quality of
Service (QoS), or delivering in other areas/regions;
– the construction of the organization on its essential (“ontological”) level,
which deals with actors entering into and complying with commitments,
modeled according to DEMO; agility here is about fast discerning of new or
obsolete roles and responsibilities, given a intended change in function;
– the construction of the organization on its organization implementation level,
which deals with the dimensions in which organizational implementation
choices are made; agility is here about fast changing the so-called Organiza-
tion Implementation Variables (OIVs), e.g., splitting or joining responsibili-
ties, order of working or segregation of duties;
– the construction of the organization on the level of its implementation with
(a/o ICT) means, which deals with the dimensions in which ICT and other
means implementation choices are made; agility is here about fast changing
the ICT implementation variables, e.g., channels, equipment, external data
sources.
Op ’t Land and Krouwel (2013) focus purely on the implementation variables,
proposing some 25 implementation variables, based upon literature study and
the verification with a fictitious case study. However, up to now these variables
have not been validated in a real life enterprise.
Our research aims at reviewing and validating the organization implementa-
tion variables (not the IT variables) in a real life enterprise, using a case study
at a dutch youthcare organization.
At the time of this case study, the municipalities and provinces in the Nether-
lands were jointly responsible for the Dutch youthcare. In 2015, the three de-
centralizations (3D) has moved the responsibility to the municipalities. These
responsibilities are defined in the law on youth care. Goal of this law is to guide
the provision of help to children, youth, and their caretakers. There are around
100 official organizations in the youth care that support in carrying out those
responsibilities. Currently, Capgemini is developing a Solution (hereafter: the
Youthcare Solution) in cooperation with an organization in the youth care, which
makes this, together with the ‘3D’, an interesting case to investigate.
2 Task
As we said, the goals of our research were to a) test the Organization Implemen-
tation Variables for completeness and occurrence in a real life enterprise, and
b) test an existing solution for youthcare developed by Capgemini on organiza-
tional implementation flexibility.
Current research (Dietz (2008)) shows that a meaningful distinction can be
made between the essence of an organization and the implementation choices
that have to be made. For instance, when an organization rents cars, the essence
of its processes contains the starting and stopping of a rental, the pick-up and
return of the car, and the payment of the rental. These processes can be imple-
mented in several ways. For instance, on splitting / joining of responsibilities:
contracting the car rental, issuing the car and receiving the payment for the
rental can be done by the same employee, or by different employees. Or on order
of working: payment can be made before picking up the car, or after. Or as an
example on segregation of duties: “receiving the payment for the rental has to be
done by a different employee than the employee who contracted the car rental”.
The methods for modeling the essence and the implementation of organiza-
tion differ in maturity. With his method the Design and Engineering Method-
ology for Organizations (DEMO), Dietz has provided a Way of Thinking and
a Way of Modeling for this essence of an organization. This has been studied
extensively for more than 25 years and applied in many cases (Dumay (2004),
Mulder et al. (2005)). Op ’t Land and Krouwel (2013) - also based on experience
in differences between organizations from the same branch which are differently
implemented (Krouwel and Op ’t Land (2012)) - have proposed 25 concrete Or-
ganization Implementation Variables (OIVs) in which choices have to be made
when implementing an enterprise. These variables are the elements within an
organization (e.g., in the business processes, organization structure, resources)
that can change over time or could be different for “similar” companies. When
these variables are known while (re-)designing the implementation of an organi-
zation, they can be taken into account (e.g., in the software). These OIVs have
been postulated based upon experience, literature research, and a thought exper-
iment on a fictitious car rental company. In this stage, the OIVs have to be tested
whether they appear in practice indeed, and if in practice new OIVs appear. In
order to be able to test the occurrence of the variables in a real life enterprise,
they need to be clear, complete and distinctive. The variables proposed by Op
’t Land and Krouwel (2013), were not defined and only illustrated by using one
example. Therefore, the OIVs need to be operationalized, i.e., made sufficiently
unambiguous that a traceable conclusion can be drawn, and that any observer
with the same operationalization of the OIVs will draw the same conclusions
from the validations.
The Youthcare Solution is a web-application that is currently being developed
by Capgemini for an organization in the dutch youthcare sector. It has the
potential to be used by different organizations working in youthcare. In order
to be able to reuse the solution for multiple enterprises in the same branch,
assessing the flexibility of the solution is important.
Our research has been done by a full-time researcher from Leiden University
during half a year. The researcher was supported by Subject Matter Experts
(SMEs), the lead architect, systems developers, DEMO experts and business an-
alysts. The SME provided information about context of and trends in the youth-
care sector, and about the case organization and its context. The lead architect
and the systems developers provided the researcher with all information on the
Youthcare Solution, such as the Request for Proposal and user stories. DEMO
experts helped the researcher with creating a DEMO model of the youthcare
sector. The variables were defined with the help of an expert group of business
analysts on organization implementation.
3 Approach
We designed our approach, starting from specifying the Ways of Thinking, Mod-
eling and Working, until the deliverables to be produced and the steps to be
taken. First we will elaborate the Generic Systems Development Process (GSDP)
to see how function, essence and implementation depend on one another for any
system, especially for enterprises. Then we will introduce DEMO as the Way of
Modeling of the essence of an enterprise. Finally, we define the deliverables and
describe the steps to be taken in our approach.
3.1 Enterprises and GSDP
Following the Enterprise Engineering paradigm (Dietz (editor), Dietz and Hooger-
vorst (2013)), we consider enterprises - goal oriented cooperatives - as essentially
social systems, of which the elements are human beings in their role of social
individuals, bestowed with appropriate authority and bearing the corresponding
responsibility. The operating principle of enterprises is that these human beings
enter into and comply with commitments regarding the products (services) that
they create (deliver). To operate an enterprise, it should be implemented by
people and (amongst other ICT-) means.
In order to perform optimally and to implement changes successfully, enter-
prises must operate as a unified and integrated whole. Unity and integration
can only be achieved through deliberate Enterprise Development (comprising
design, engineering, and implementation) and Governance, together called En-
terprise Engineering. (Dietz (editor), postulate 2)
The Generic System Development Process (GSDP) is a conceptual frame-
work for such design, engineering, and implementation of systems of any kind
(Dietz and Hoogervorst (2013), Dietz and Hoogervorst (2015)), which we will
now briefly introduce. Any development process concerns two systems, the Ob-
ject System (OS), the system to be developed, and the Using System (US), the
system that is going to use the services of the Object System. The GSDP consists
of three phases (see figure 1):
1. The design phase: consists of function design and construction design. Func-
tion design starts from the construction of the US and ends with the function
of the OS (a black-box model is created). The construction design starts from
the specified function of the OS and ends with the construction of the OS
(starting with the highest level white-box model of the OS).
The highest level white-box model, also called the ontological model, shows
the essence of an enterprise that is only dependent on the products and ser-
vices to be delivered. In the ontological model actor roles deliver services
by executing transactions. By Implementation is meant the assigning of peo-
ple and means—in GSDP called together “technology”—to actor roles and
transactions. The ontological model does not depend on any such implemen-
tation choices.
2. The engineering phase: here a series of constructional models are produced.
Engineering (in the narrow meaning of the word) starts from the ontological
model and ends with the implementation model.
3. The implementation phase: the assignment of technology to the construc-
tional elements in the implementation model. After this, the system can be
put into operation immediately.
By technology we understand the means by which a system is implemented.
A wide range of means is available, including human beings and organizational
entities, ICT artifacts (e.g., phone, email, computer programs) and mechanical
means. By implementation we mean assigning technological means to construc-
tional elements such as actor roles, transaction kinds and information links. The
organization implementation variables (OIVs) are the dimensions of freedom in
which implementation choices are made. One set of OIV key-value pairs in which
each OIV gets assigned one specific value, we call a Technological Alternative.
The IOTA-theory, Implementing Organizations with Technological Alternatives,
explains that an organization can be implemented using technological means,
Fig. 1. The Generic Systems Development Process
choosing between several Technological Alternatives. For example the actor role
“baker” is in Technological Alternative A assigned to 3 people of the functionary
type “cook” with white hats in the kitchen; and in Technological Alternative B
assigned to 5 people of the functionary type “transporter boy”, which all have
a transportable oven at the back of their scooter.
3.2 DEMO
DEMO is a methodology used to construct the ontology of an organization (Dietz
(2008)), focusing on the humans working in an organization and their communi-
cation. DEMO is based upon the PSI-theory (Performance in Social Interaction).
It explains that the humans in an organization enter into and comply with com-
mitments regarding the production of products through communication. Main
concepts of the DEMO methodology (Dietz (2006)) include:
– Transactions: these are the interaction patterns between parties involved,
shaped in transactions, each delivering a specific result. Each transaction
has one executor, and can have one or more initiators.
– Actor role: an elementary chunk of authority, responsibility, and competence.
Actor roles have to be implemented by organizations and people, and by
other means.
– Production and coordination acts and facts: an actor can perform two kinds
of acts: production acts (P-acts) and coordination acts (C-acts). By per-
forming P-acts, actors contribute to bringing about the goods or services
that are delivered by an organization. By performing C-acts actors enter
into and comply with commitments towards each other regarding the per-
formance of P-acts. The result of a P-act and a C-act is a P-fact and a C-fact
respectively.
According to DEMO, a complete, so-called essential model of an organiza-
tion consists of four aspect models: Construction Model (CM), Process Model
(PM), Action Model (AM), and Fact Model (FM). The CM specifies the com-
position, the environment and the structure of the organization. It contains the
identified transaction types, the associated actor roles as well as the informa-
tion links between actor roles and transaction banks (the conceptual containers
of the process history). The PM details each transaction type according to the
universal transaction pattern. In addition, it shows the structure of the identi-
fied business processes, which are trees of transactions. The AM specifies the
imperatively formulated business rules that serve as guidelines for the actors in
dealing with their agenda. The FM specifies the object classes, the fact types
and the declarative formulations of the business rules.
For the CM, we will briefly intro-
duce its concepts and representation
(figure 2). A CM shows the network
of identified transaction types and the
corresponding actor roles. E.g., trans-
action type T01 delivers a business
service to actor role A00; A00 is called
its initiator and A01 its executor. The
executor of a transaction is marked by
a small black diamond on the edge
of the actor role box. The solid line
between A00 and T01 is the initia-
Fig. 2. Typical DEMO Construction Model
tor link; the solid line between A01
and T01 is the executor link. By the
dashed line between A07 and T01, Figure 2 also shows that some other actor role
(A07) needs to have access to the history of transactions T01 (production facts
as well as coordination facts (e.g., status requested, promised, stated, accepted)).
3.3 Deliverables
Deliverables of this research are a) operationalized OIVs, including b) whether it
has been found in the youthcare sector, and c) whether it has been found in the
Youthcare Solution. The operationalized OIVs are shown in a list with for each
OIV its name, a definition, one or two examples and the relationship with other
variables; for some OIVs complemented with a counter example and guidelines
for observation. All OIVs are shown in a table, with per variable an indication
of whether it has been found in the youthcare sector, and whether this variable
was also parameterizable in the Youthcare Solution. Also new found variables
in the youthcare sector or in the Youthcare Solution are added to the list as
candidate OIV.
3.4 The steps
The different steps in our research are a) operationalizing the OIVs, b) a case
study validation of the variables in the youthcare section, c) a validation of
the variables in the Youthcare Solution, and d) a flexibility assessment of the
Youthcare Solution.
The case study preparation (a) is done by operationalizing the OIVs. Start-
ing point for this step is the variables as proposed by Op ’t Land and Krouwel
(2013). Each variable was defined, illustrated by examples and related to other
variables, and sometimes complemented with counterexamples and guidelines
for observation. As far as the definitions that were based upon the essence of
an enterprise, the DEMO terminology has been followed. The other parts of the
formulation of definitions built upon common business terminology. Examples
were formulated using different cases, the Rent-A-Car (RAC) case, the pizzeria
case, and own experience. Sometimes a counterexample was given when the defi-
nitions had multiple ways to be interpreted. When it became clear in a definition
of a variable that had a relationship to an other variable, this relationship was
given. First the researcher drafted a proposal for each OIV-disambiguation, then
it was reviewed in multiple work sessions with the help of experts on the subject.
The first part (b) of the case study is validating the variables in the youthcare
sector (e.g., in its processes). Inputs for this step are the list of operationalized
OIVs and publicly available literature of the youthcare sector (e.g., websites, an-
nual reports of different enterprises). The list of OIVs is used as a reference when
studying the available literature in order to assess the occurrence of the vari-
ables. The findings were proposed and verified with the help of Subject Matter
Experts (SMEs).
The second part (c) of the case study is assessing the occurrence of the vari-
ables in the Youthcare Solution. Inputs for this step are the list of operationalized
OIVs and documentation on the Youthcare Solution (e.g., Software Architecture
Document, user stories). The documentation is studied to find out if the OIVs
are parameterizable. The findings were validated with the help of SMEs and
system developers.
The last part (d) of the case study was a flexibility assessment, in which the
results of the previous steps are compared in order to see to what extent the
Youthcare Solution already takes variables that exist in the youthcare sector
into account (viz. they are parameterizable in the Solution). For example when
the variable Employee is found in the youthcare sector and is also a variable in
the Youthcare Solution, the Solution can be considered flexible in this aspect.
All steps of the research were done iteratively. The variables were initially
defined, but during the process of assessing the variables in the case organization
and the Solution, the definition of the variables were also revised.
Figure 3 shows that the research started with the literature study on the topic
and then the operationalization of the variables. During the operationalization
the literature study on the case was started and the case study was executed.
Lastly a report of the research was written.
Fig. 3. Global planning research
4 Results
The case study on the youthcare sector and an existing Solution for youthcare
was, according to plan, executed in 2014-H1. First, three Organization Imple-
mentation Variables are shown with the definition and examples. Second, the
construction model of the case organization is shown. Third, examples of the
OIVs found in the organization and in the Youthcare Solution are shown. Lastly,
all found variables are shown in table 2.
4.1 Organization Implementation Variables
For the OIVs Employee, Separation of duties, and Order of working, the defi-
nition, examples, sometimes a counterexample and observation notes are given
here.
Employee Definition: An employee is a natural person who fulfills one or more
functionary types.
Examples: Natural person “Jan van Vliet” is an employee of Ahold, who fulfills
the functionary type “cashier”. Natural person “Sarah” is an employee with the
functionary type “cleaner” who does undeclared work.
Counterexample: Illegal intruder in the organization who performs acts.
Observation notes: An employee does not need to have a legal contract with
the organization. He or she can also be hired from another company, or simply
perform acts with approval of the organization.
Separation of duties Definition: Governance policy according to which no
employee should be given responsibility for more than one related function.
Examples: A request for a money transfer in a bank is executed by two employees,
one employee approves the transfer, the other employee executes the transfer.
Observation notes: Validate if there are transactions within the organization that
are fraud or error sensitive or where consequences of mistakes can be severe.
Order of working Definition: The order in which different acts are performed,
within its dependency constraints.
Examples: In a mail order company, the packages are first sorted by postal code,
after that the packages are loaded into the delivery car.
4.2 DEMO Construction Model
In order to visualize the organization, and to understand the essence of the orga-
nization, a DEMO Construction Model is created. Its Organization Construction
Diagram (OCD - see figure 4) shows a simplified operation of a part of the youth-
care sector. Table 1 names and describes its transactions. This model will help
in making the distinction between what is the essence of the case organization
(represented in the DEMO Construction Model), and what belongs to the im-
plementation (represented by the Organization Implementation Variables).
Fig. 4. Construction Model of youthcare sector
4.3 Variables in youthcare sector
The occurrence of the OIVs is tested in some parts of the case organization by in-
vestigating the available data. Data sources that are used are two annual reports
of two different organizations in the youthcare sector and three different websites
of three organizations. In the next analysis we will first show the source text3
3
Note: these texts originate from Dutch websites and annual reports and have been
translated here to English
Transaction Transaction name Description
T01 Conversing The children’s helpline
T02 Registered incident Report an incident which then is registered to the
child abuse hotline
T03 Advice suitable youthcare Here parents and care takers can get non-binding
advice about suitable youthcare, or binding ad-
vice, where the register can report a suspected
incident
T04 Reported to police Following up from an incident registered with the
child abuse hotline, a case may be reported to the
police
T05 Executed procedure When voluntary help is not sufficient, a procedure
is started
T06 Initiated case Case is initiated and procedures are started
T07 Evaluated case An internal investigation is started regarding a
case
T08 Aid provided Youth rehabilitation when this is ordered by the
judge
T09 Performing rehabilitation Judge can assign a guardian
T10 Assign guardian Aid is provided to a child/family, ordered by the
court, following up from the procedure
Table 1. Transactions from youthcare construction Model
in which the variables have been found, and then mention the considerations for
this identification.
“Do you want to work as a volunteer at the children’s helpline? There is a
website with all information about volunteering [www.]” (Kindertelefoon (2014))
Here an instance of the variable V4: employee (see table 2) is found, namely a
volunteer. Also the variable V15: sourcing appears here.
“.. Besides talking by phone, we are also specialized in online help via chat”
This part explains that the volunteers can be contacted by phone and chat, which
are instances of V16: technical channels. The DEMO Construction Model (see
figure 4) shows no sign of the use of phone or chat, from which can be concluded
that technical channels do not belong to the essence of the organization, but to
the implementation.
“All volunteers are trained by our trainers which are all trained and certified
by our academy”
This states that the volunteers are trained by trainers who are certified by the
academy, which indicates the variable V17: Validation of competences.
“The children’s helpline is spread across 18 locations. All locations are affili-
ated with the National Bureau of the children’s helpline”
This text shows that there are 18 locations of the children’s helpline (V19: work
locations). All locations of the children’s helpline are affiliated with the National
Bureau of the children’s helpline which indicates V11: organizational structure.
There can also be deducted from this that one office of the children’s helpline is
a V12: organizational unit.
“Various work groups of managers and supervisors working for the children’s
helpline are active.” (van Zant and Waarts (2012))
Managers and work supervisors are instances of V7: functionary type.
“The volunteers have phone duty, have chat conversations, hold lectures at
schools and administer the site and the forum.”
Tasks of the volunteers, indicates V22: X-ref functionary type / act type. There
is not a direct link to a functionary type, but it is not clear if the volunteers
all have the same functionary type, or if there is a distinction between different
volunteers. It appears to be that all volunteers can perform the same tasks, and
only the paid employees have a different functionary type.
“A volunteer works on average 6 hours per week”
Here we detected V6: #FTE : apparently a volunteer counts for 0.15 FTE.
“The procedure ‘Referring actively’ is an opportunity for the volunteer to di-
rectly provide assistance to a child in a highly threatening situation (child abuse,
emotional neglect).”
There can be reasoned that a volunteer needs to have knowledge about when to
refer a child to a aid agency, so a certain V2: competence is needed.
“Some youthcare offices have a central registration or central access which
deals with the first contact with the child abuse hotline.” (Jeugdzorg Nederland
(2013))
This shows the variable V1: addressee specificity, where sometimes the addressee
is a youthcare office when there is a central entrance, and sometimes directly to
the child abuse hotline.
“The youthcare office in Friesland4 is a foundation under managerial re-
sponsibility of a general manager and a director.” (Bureau Jeugdzorg Friesland
(2014))
This shows that youthcare office Friesland is a foundation, and therefore a V9:
legal entity. It appears that all youthcare offices are legally a foundation.
Table 2 shows an overview of all variables found in the youthcare sector.
4.4 Variables in Youthcare Solution
The OIVs are also searched for in the Youthcare Solution to test if the variables
existent in the case organization, are already supported by their IT system. Data
that is used include: requirements document, software architecture document,
user stories, datamodel and product description. We will not show the analysis
of the documents (due to confidentiality), table 2 shows all variables actually
found in the Youthcare Solution. This table shows that not all variables found
in the youthcare sector are supported by the Youthcare Solution.
4
A province of the Netherlands
# Variable Youthcare sector Youthcare Solution
V1 Addressee specificity yes
V2 Competences yes
V3 Delegation yes
V4 Employee yes yes
V5 Event location restrictions
V6 #FTE yes
V7 Functionary type yes
V8 Language support yes
V9 Legal entity yes
V10 Order of working
V11 Organization structure yes yes
V12 Organizational unit yes yes
V13 Rules for assignment of tasks
V14 Separation of duties yes
V15 Sourcing yes yes
V16 Technical Channels yes yes
V17 Validation of competences yes
V18 Way of fulfilling actor role
V19 Work locations yes
V20 X-ref employee/functionary type
V21 X-ref employee/work location
V22 X-ref functionary type/act type yes
V23 X-ref work locations/act type
V24 X-reference employee/actor role new
V25 X-ref employee/organizational unit new
V26 X-ref actor role/organizational unit new
V27 Region new
Table 2. Organization Implementation Variables found in youthcare sector and Youth-
care Solution
5 Reflection
Our reflection on existing or new Organization Implementation Variables, is
structured as follows. First, the results of the case will be discussed starting with
the OIVs in general and after that the validation of the OIVs in the youthcare
sector and in the Youthcare Solution. Second, a general reflection is given on
this research. Lastly some recommendations for future research are shown.
Before this research, the Organization Implementation Variables were not
clear or defined. Now the OIVs have been defined and illustrated by one or
more examples. Some definitions are straightforward and clearly defined (for
example Functionary type, Organization structure, etc.), but for some variables
the definition is not stable enough, and could use some more discussion. For
example the variable Sourcing has a very general definition. Good examples are
needed in order to sharpen the definition. The variable Employee is still under
discussion. A question that arises is: can an employee be only under contract
of an organization? Also the examples of this variable can be more clear. The
variables are now also validated with a real life case study, however preferably
multiple case studies are needed in order to get a solid validation of the OIVs.
Validation can be used to see if a variable occurred in sector a, also occurs in
sector b and sector c. When this is the case, you could conclude that this variable
is generally applicable. Validation can also be used to see how often a certain
variable occurs (in one case or in multiple cases) to conclude something about
the importance of a variable.
The case study validated 16 out of 23 OIVs in either or both the case orga-
nization and in the Youthcare Solution. For the Youthcare Solution the OIVs
have been validated with the people directly involved. However for the valida-
tion in the youthcare sector, it was done using only publicly available documents.
Therefore variables regarding performing work (order of working, way of fulfilling
actor role, rules for assignment of tasks, event location restrictions, X-ref work
locations/act type, X-ref employee/work location) may be overlooked, as they are
not identifiable in public documentation or the requirements specifications for
the Youthcare Solution. Even though some of the variables have not been found
in the case organization, it does not mean that they do not exist in this or in
another organization. Therefore, other research is necessary for more validation
of the variables. Also not all variables found in the youthcare sector are found in
Youthcare Solution (and thus not supported by IT). However, this does not mean
by definition that the Youthcare Solution is not agile. Variables that were not
supported by the solution are variables that regard work routines (competences,
#FTE, validation of competences), and this is not important for the Youthcare
Solution. For the Youthcare Solution 8 out of 23 OIVs were variable indeed. For
the variable delegation this means that it is easy to change delegations. For the
variable employee it means that the solution supports having to add or delete
an employee from the system.
When using the list with OIVs a consultant or an organization needs to
realize that you should always think about what kind of flexibility is wanted
and needed in an IT system, and therefore taking into consideration what OIV
may be important and what may be not. We have made a first step in what we
think should lead to better organization consulting. It should help a consultant
in identifying the (in-)flexibilities of an organization and their supporting IT-
system.
This research only investigated the OIVs itself, but not the usage of these
OIVs. Future research may look into how the OIVs can be applied in an organi-
zation in order to really achieve agility. Also, as stated earlier, more case studies
at different organizations (and different sectors) are needed to make the results
more reliable. The research on the OIVs itself can also be extended: continue
research on the organization implementation variables, by making better defi-
nitions, come up with more examples, investigate the relationship between the
variables, and investigate the external influence on the variables (E.g., regula-
tions).
References
Bureau Jeugdzorg Friesland: Website BJZ Friesland (2014), http://www.
bjzfriesland.nl
Dietz, J.L.G.: Enterprise Ontology - Theory and Methodology. Springer Berlin
Heidelberg, Berlin, Heidelberg (2006)
Dietz, J.L.G.: Architecture: building strategy into design. Sdu Uitgevers bv, The
Hague, The Netherlands (2008)
Dietz, J.L., Hoogervorst, J.: The discipline of enterprise engineering. Int. J.
Organisational Design and Engineering 3(1) (2013)
Dietz, J.L., Hoogervorst, J.: The BETA Theory - understanding architecture
and design (forthcoming) (2015)
Dietz (editor), J.L.: Enterprise Engineering Manifesto (2011), www.
ciaonetwork.org/publications/EEManifesto.pdf
Dumay, M.: Demo of Praktijk: Een inventarisatie van het praktische toepassings-
gebied van Design & Engineering Methodology for Organizations (DEMO).
Master’s thesis, TU Delft (September 2004)
Jeugdzorg Nederland: Advies- en Meldpunt Kindermishandeling Jaarverslag
(2013)
Kindertelefoon: Website kindertelefoon (2014), http://www.kindertelefoon.
nl/
Krouwel, M., Op ’t Land, M.: Using Enterprise Ontology as a basis for Require-
ments for Cross-Organizationally Usable Applications (2012)
Mulder, J.B., Dumay, M., Dietz, J.L.: Demo or practice: Critical analysis of the
language/action perspective. Proceedings of the LAP Conference (2005)
Oosterhout, M.P.A.v.: Business agility and information technology in service
organizations (June 2010)
Op ’t Land, M., Krouwel, M.: Exploring Organizational Implementation Funda-
mentals (2013)
van Zant, M., Waarts, B.: Jaarverslag De Kindertelefoon (2012)