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 e ectively enable such changes of enterprises in the Healthcare sector, Capgemini is constantly exploring better ways of a) continuously optimizing business processes and b) building and maintaining inherently exible information systems. In 2014-H1 an existing Solution for youthcare was evaluated by Capgemini and Leiden University to nd out its exibility 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 signi cantly improved de nitions of these OIVs, we were able to nd 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 exible with respect to the foreseen changes, also given the Dutch decentralization laws (3D).
In order to respond to changes in the business environment and healthcare
sector, enterprises want to be more agile.
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 organization and ICT. Examples of choices in organization implementation are e.g., splitting or joining responsibilities, order of working or segregation of duties. 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 business (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 Knowledge, and in concepts which create exibility in such Solutions. This ts Capgemini'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 di erent customers. In order for Capgemini to scale up in creating such Solutions, it is important to make this knowledge - on elements that have to be exible in its Solutions - explicit.
Our research aims at reviewing and validating the organization implementation 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 Netherlands were jointly responsible for the Dutch youthcare. In 2015, the three decentralizations (3D) has moved the responsibility to the municipalities. These responsibilities are de ned 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 o cial 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
As we said, the goals of our research were to a) test the Organization Implementation Variables for completeness and occurrence in a real life enterprise, and b) test an existing solution for youthcare developed by Capgemini on organizational implementation exibility.
Current research (
The methods for modeling the essence and the implementation of
organization di er in maturity. With his method the Design and Engineering
Methodology 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 (
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 di erent organizations working in youthcare. In order to be able to reuse the solution for multiple enterprises in the same branch, assessing the exibility 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 analysts. The SME provided information about context of and trends in the youthcare 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 de ned with the help of an expert group of business analysts on organization implementation. 3
We designed our approach, starting from specifying the Ways of Thinking, Modeling 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 de ne the deliverables and describe the steps to be taken in our approach. 3.1
Following the Enterprise Engineering paradigm (Dietz (editor),
In order to perform optimally and to implement changes successfully, enterprises must operate as a uni ed and integrated whole. Unity and integration can only be achieved through deliberate Enterprise Development (comprising design, engineering, and implementation) and Governance, together called Enterprise Engineering. (Dietz (editor), postulate 2)
The Generic System Development Process (GSDP) is a conceptual
framework for such design, engineering, and implementation of systems of any kind
(
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 services to be delivered. In the ontological model actor roles deliver services by executing transactions. By Implementation is meant the assigning of people and means|in GSDP called together \technology"|to actor roles and transactions. The ontological model does not depend on any such implementation 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 constructional 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 constructional 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 speci c value, we call a Technological Alternative. The IOTA-theory, Implementing Organizations with Technological Alternatives, explains that an organization can be implemented using technological means, 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 is a methodology used to construct the ontology of an organization (
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 performing 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 performance 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 organization consists of four aspect models: Construction Model (CM), Process Model (PM), Action Model (AM), and Fact Model (FM). The CM speci es the composition, the environment and the structure of the organization. It contains the identi ed transaction types, the associated actor roles as well as the information 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 identied business processes, which are trees of transactions. The AM speci es the imperatively formulated business rules that serve as guidelines for the actors in dealing with their agenda. The FM speci es the object classes, the fact types and the declarative formulations of the business rules.
For the CM, we will brie y introduce its concepts and representation ( gure 2). A CM shows the network of identi ed transaction types and the corresponding actor roles. E.g., transaction 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 tboertwlienekn; Ath0e0 saonlidd Tlin01e bisettwheeeniniAti0a1- Fig. 2. Typical DEMO Construction Model 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 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 de nition, 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 di erent 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 exibility assessment of the Youthcare Solution.
The case study preparation (a) is done by operationalizing the OIVs.
Starting point for this step is the variables as proposed by
The rst 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, annual reports of di erent enterprises). The list of OIVs is used as a reference when studying the available literature in order to assess the occurrence of the variables. The ndings were proposed and veri ed with the help of Subject Matter Experts (SMEs).
The second part (c) of the case study is assessing the occurrence of the variables 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 nd out if the OIVs are parameterizable. The ndings were validated with the help of SMEs and system developers.
The last part (d) of the case study was a exibility 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 exible in this aspect.
All steps of the research were done iteratively. The variables were initially de ned, but during the process of assessing the variables in the case organization and the Solution, the de nition 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. The case study on the youthcare sector and an existing Solution for youthcare was, according to plan, executed in 2014-H1. First, three Organization Implementation Variables are shown with the de nition 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. For the OIVs Employee, Separation of duties, and Order of working, the de nition, examples, sometimes a counterexample and observation notes are given here.
Employee De nition: An employee is a natural person who ful lls one or more functionary types.
Examples: Natural person \Jan van Vliet" is an employee of Ahold, who ful lls 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 De nition: 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 De nition: The order in which di erent acts are performed, within its dependency constraints.
Examples: In a mail order company, the packages are rst sorted by postal code, after that the packages are loaded into the delivery car. 4.2
In order to visualize the organization, and to understand the essence of the organization, a DEMO Construction Model is created. Its Organization Construction Diagram (OCD - see gure 4) shows a simpli ed operation of a part of the youthcare 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 implementation (represented by the Organization Implementation Variables). The occurrence of the OIVs is tested in some parts of the case organization by investigating the available data. Data sources that are used are two annual reports of two di erent organizations in the youthcare sector and three di erent websites of three organizations. In the next analysis we will rst 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 T01 Conversing T02 Registered incident in which the variables have been found, and then mention the considerations for this identi cation.
\Do you want to work as a volunteer at the children's helpline? There is a
website with all information about volunteering [www.]" (
\.. 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 gure 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 certi ed by our academy" This states that the volunteers are trained by trainers who are certi ed by the academy, which indicates the variable V17: Validation of competences.
\The children's helpline is spread across 18 locations. All locations are a liated 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 a liated with the National Bureau of the children's helpline which indicates V11: organizational structure. There can also be deducted from this that one o ce 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." (
\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 di erent volunteers. It appears to be that all volunteers can perform the same tasks, and only the paid employees have a di erent 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 directly 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 o ces have a central registration or central access which
deals with the rst contact with the child abuse hotline." (
\The youthcare o ce in Friesland4 is a foundation under managerial
responsibility of a general manager and a director." (
Table 2 shows an overview of all variables found in the youthcare sector. 4.4
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 con dentiality), 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 Youthcare sector Youthcare Solution yes yes yes yes yes yes yes yes yes yes new Our re ection 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 re ection is given on this research. Lastly some recommendations for future research are shown.
Before this research, the Organization Implementation Variables were not clear or de ned. Now the OIVs have been de ned and illustrated by one or more examples. Some de nitions are straightforward and clearly de ned (for example Functionary type, Organization structure, etc.), but for some variables the de nition is not stable enough, and could use some more discussion. For example the variable Sourcing has a very general de nition. Good examples are needed in order to sharpen the de nition. 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 organization and in the Youthcare Solution. For the Youthcare Solution the OIVs have been validated with the people directly involved. However for the validation in the youthcare sector, it was done using only publicly available documents. Therefore variables regarding performing work (order of working, way of ful lling 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 identi able in public documentation or the requirements speci cations 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 de nition 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 exibility 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 rst step in what we think should lead to better organization consulting. It should help a consultant in identifying the (in-) exibilities of an organization and their supporting ITsystem.
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 organization in order to really achieve agility. Also, as stated earlier, more case studies at di erent organizations (and di erent 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 de nitions, come up with more examples, investigate the relationship between the variables, and investigate the external in uence on the variables (E.g., regulations).