Enterprise Modeling

Within CDD, Enterprise Modeling is used to capture and document the existing organizational design in terms of business goals, problems, KPIs, business processes, concepts, etc. The overall vision of the CDD approach is to use (and update if necessary) the models that the organization already has for capability design. However, if the organization does not have existing models or their use is deemed impractical (e.g. they are severely out of date, the modelling language used is incompatible with the CDD approach or the quality of models is below acceptable), new models need to be created. In the latter case we recommend the 4EM method (published in a book by Sandkuhl et al., 2014) for carrying out Enterprise Modelling.

4EM uses six interrelated sub-models which complement each other and capture different views of the enterprise, i.e. each of the sub-models represents some aspect of the enterprise (see Figure above). These sub-models and issues they address are:

Goals Model (GM) focuses on describing the goals of the enterprise. Here we describe what the enterprise and its employees want to achieve, or to avoid, and when. Goals Models usually clarify questions, such as: where should the organisation be moving, that are the goals of the organisation what are the importance, criticality, and priorities of these goals, how are goals related to each other, which problems are hindering achievement of goals.

Business Rule Model (BRM) is used to define and maintain explicitly formulated business rules, consistent with the Goals Model. Business Rules may be seen as operationalization or limits of goals. BRM usually clarifies questions, such as: which rules affect the organisation’s goals, are there any policies stated, how is a business rule related a goal, how can goals be supported by rules

Concepts Model (CM) is used to strictly define the “things” and “phenomena” one is talking about in the other models. We represent enterprise concepts, attributes, and relationships. Concepts are used to define more strictly expressions in the Goals Model as well as the content of information sets in the Business Processes Model. CM usually clarifies questions, such as: what concepts are recognised in the enterprise (including their relationships to goals, activities and processes, and actors), how are they defined, what business rules and constraints monitor these objects and concepts.

Business Processes Model (BPM) is used to define enterprise processes, the way they interact and the way they handle information as well as material. A business process is assumed to consume input in terms of information and/or material and produce output of information and/or material. Business Process Model usually clarifies questions, such as: which business activities and processes are recognised in the organisation, or should be there, to manage the organisation in agreement with its goals? How should the business processes, tasks, etc. be performed (workflows, state transitions, or process models)? Which are their information needs.

Actors and Resources Model (ARM) is used to describe how different actors and resources are related to each other and how they are related to components of the Goals Model, and to components of the Business Processes Model. For instance, an actor may be the responsible for a particular process in the BPM or, the actor may pursue a particular goal in the GM. ARM usually clarifies questions, such as: who is/should be performing which processes and tasks, how is the reporting and responsibility structure between actors defined.

Technical Components and Requirements Model (TCRM) becomes relevant when the purpose of EKD is to aid in defining requirements for the development of an information system. Attention is focused on the technical system that is needed to support the goals, processes, and actors of the enterprise. Initially one needs to develop a set of high level requirements or goals, for the information system as a whole. Based on these, we attempt to structure the information system in a number of subsystems, or technical components. TCRM is an initial attempt to define the overall structure and properties of the information system to support the business activities, as defined in the BPM. TCRM usually clarifies questions, such as: what are the requirements for the information system to be developed, which requirements are generated by the business processes, which potential has emerging information and communication technology for process improvement.