In business process management (BPM) it is customary to differentiate between the current (as-is) situation, and the future (to-be) situation and develop models of these situations. In practice you never are able to implement the ideal to-be model, although it is still useful to represent this and update it as the situation changes. A finer distinction between the modelling of this ideal ought-to-be, as-is, and to-be is necessary, and we have in this paper provided an approach for combining top-down and bottom-up modelling to support the dynamic interplay between these models. The approach is exemplified through a case in the health sector where it has been tried out, reporting the learnings from supporting this in a contemporary enterprise architecture environment.
The first process modelling language was described as early as 1921 [
Models of work processes have long been utilized to learn about, guide and support
practice also in other areas. In software process improvement [
A lot of research has been done in the field of enterprise process modelling [
A more detailed overview of types of process models are found in section 2. How the interplay in particular between as-is, ought-to-be and to-be models can be supported is illustrated in more detail in a case study reported in section 3. Discussion of results, concluding remarks and ideas on further work are found in section 4. 2
Modeling of Business Processes in Enterprise Development
According to general model theory [
Process modeling is usually done in some organizational setting. An organization can be looked upon as being in a state (the current state, often represented as a descriptive 'as-is' model) that are to be evolved to some future wanted state (traditionally represented as a prescriptive 'to be' model). In practice only looking at as-is and to-be models is insufficient, one also need to have the possibility to experiment with could-Be's (different scenarios), and Ought-to-Be (the best scenario).
In table 1, we list relevant situations, along temporal and a contextual axes
We will below look in particular on the interplay between the actual as-is model, the ought-to-be (ideal) model, and to-be model. Process modeling starts with the company vision and business value, and shall contribute to long-term success. It is important to develop both corporate future goals and a target architecture. To achieve this, we need both a top-down and a bottom-up approach. Future state models are best done with a top-down approach while past and present state models are mostly done bottom-up. Future state models can also be referred to as future operating model (other terms are ought-to-be model and target architecture)
The future operating model is a top-down model describing best practice of how the most critical work ought to be done, and of how we want to operate in the future. There will always be a gap between the ambitions of an organization and the current or short term technical, methodical and organizational possibilities.
In order to get an overview, control and management of a business, it is important to get a common understanding what the business is doing or is supposed to do. One need an overall model of the main processes, information, systems, and skills necessary to produce products and services, that all stakeholders (owners, managers, employees, suppliers and customers) can agree upon. The model should also have a long perspective, 5-10 years or more, to be a “lighthouse” to guide the direction of the organization, thus the name “Future Operating Model”
This model is used for understanding and the planning of programs and projects. The Future Operating Model describes best practices which are derived from previous experience, expected technological development and regulatory requirements etc., and show the ambitions and plans. This model is a generic/conceptual/logical model, and is used for basic analyses and help answer questions like: • • • • "What is the enterprise doing?" "Is the enterprise doing the right things?" “How are the main processes and value chain performed?” "Could one redesign the basic processes?" This is analysis that should be done before going into the details like: • "Who / what does what?" (Human / machine).
• "Which IT systems used for what?"
Once these basic analyzes and decisions have been made, we can proceed with detailed workflow diagrams.
A unifying overall process model like this makes it possible for people with various backgrounds, coming from different organizational units and disciplines, and who has worked in different ways in the past - to agree on common work processes and value chains. This contributes to common terminology for processes, concepts and information objects. A generic overall model, also contributes to the standardization of the process-mapping so that the work processes are described the same way in the different departments and disciplines, which is important for communication and reuse.
In this model it is also important to focus on the customer/client and the customer interaction with the company is explicitly modeled.
Using a top-down generic model in IDEF0 [
This means we get a complete future operating model which is maintained independent of current technology and organizational implementations. It can live through technological innovations and organizational changes such as mergers or divisions.
The workflow-model describes detailed activities for each role and how the ITsystems are used for each activity. This gives detailed about which roles, information objects and applications functions that are used (as-is and to-be).
The workflow-model is a bottom-up implementation model, which shows the detailed workflow for defined parts of the value-chain.
Figure 2 illustrates how to combine top-down best practice with bottom-up implementation 1. On the left side a top-down process breakdown structure, from an "overall view" detailed in several levels down to "processes / activities". 2. The right side show a bottom-up workflow model which is built up from applications & roles, IT Services and procedures, used for implementation. As illustrated in Figure 3 process modelling with focus on a best practice top-down model, as well as detailed workflow diagrams, makes the process of going from current as-is to the next to-be that is easier, more structured and efficient.
By linking best practice with as-is and to-be models, it will be possible to analyze how close (or far) the current and next practice is from best practice.
Often certain process steps are repeated several places in the value chain, and we want to standardize on ways of performing these processes. To make this more explicit in the model, we make stereotype-processes as indicated in Figure 4, which can be used as reference processes. These can be referenced from several places in the value-chain or in several value-chains and should be the basis for services and aligned with the service catalog and used as specification for the services. These stereotype processes will then represent the “layer” of common terms where the business meets IT.
The model(s) were created and maintained in a graphical tool (Troux Architect) with an underlying repository structure.
Based on this process modelling experience, and a reference model for clinical pathways used in the same organization a top-down process model was developed.
The process modelling project for a new hospital that was under construction, was adjusted to this reference model and below is some examples from this model
The top level Hospital Clinical Pathway process modelled in IDEF0 illustrated in Figure 5 shows the sick patient as input and a cured patient as output. As controls on top the laws and regulations are shown and as mechanisms at the bottom the main roles/skills and logical application systems are shown.
On the next level we see the sub-processes in the pathway with more detailed inputs, controls, outputs and mechanisms (IDEF0 ICOM’s). The processes and ICOM’s are numbered according to the process breakdown structure.
This top down generic model can be broken down in several levels to an appropriate detailed level. It is also important to include the patient’s own processes in the model in order to include a patient focus.
From this main process structure it is possible to make many different model views for various purposes and audiences. The processes can i.e. be presented in swimlanes representing main hospital units.
On the most detailed level it is also possible to present the processes with generic roles including the patient processes with focus on the interactions between the healthcare and the patient, highlighting the Line of Visibility (LoV) between the enterprise (hospital) and the customer (patient). This is illustrated in Figure 6.
These views can be made on several process levels, helping people from different professions with varying skills to get a common understanding of the enterprise processes.
When we get to a detailed level we often find standard processes that are used in several value-chains (pathways). To avoid making duplicates, we model these standard processes separate as Stereotypes and make a link (relationship) from the value-chain process to the Stereotype processes. The stereotypes should be aligned with the Service Catalog and might be seen as a specification for the services. The use of stereotypes/standard processes as specifications for services is indicated in Figure 7, where they in the model are linked to application functions, the information model and to logical application objects. All the above are views from the best practice ought-to-be top-down generic model.
When we come to the implementation models (as-is or to-be) we have to go bottom up from implemented systems (applications, application functions, information model) up to activities in a workflow diagram (in the case using BPMN), often also called Orchestration as illustrated in Figure 8.
This is a specific architecture model referring to specific activities, applications and information. One model might show the as-is situation with as-is activities and installed operative applications. Another model might show to-be with proposed activities and applications.
Going from as-is to to-be where guided by the best practice ought-to-be model in order to over time close the gap between the long-term ambitions and current technical and organizational capabilities.
This generic, conceptual process can also be applied and be valid outside a hospital unit. There will be several similar clinical pathways outside the hospital like municipal health service (local doctor), emergency units (Prehospital), and ambulance. It is important to see these similarities to be able to synchronize medical records information in the computer systems. 4
Conclusion and Further Work We have in this paper looked upon how to enhance the traditional practice with as-is and to-be models with a ought-to-be model representing the best practice and future operating model – expressing also the long-term ambitions within the enterprise.
Working with this approach hopefully also will make it easier for the enterprise management and enterprise architects to express in more detail their ambitions, before the CIO and IT-architects brings in their systems and limitations from current technology. A main learning from the case is that the top-down ought-to-be models due to that they are not to be immediately implemented makes it possible to describe ideas and ambitions on a generic level, avoiding both organizational and technical limitations, but also terminological and conceptual constraints making it easier to be innovative and learn from others without being experienced as threatening to the current state of affairs.
As a case study this is limited to a certain phase of the specification and building of a new hospital in HSØ.
In the approach so far, we have used traditional process modelling such as IDEF0
and BPMN for the top-down and bottom-up modelling. In future work we will
experiment with the use of approaches such as AKM [