Business Process Modeling of a Quality System in a Petroleum Industry Company

Abstract

• (a) Situation faced: The petroleum industry is characterized by increased focus on safety and compliance with regulations, in addition to efficient operations. Earlier quality systems were represented in large binders of textual documents, which made important governing documentation difficult to access and unusable for operational personnel who wished to gain an overview.

• (b) Action taken: Based on the existing quality system, a new way of structuring and accessing the material was developed as a collection of 2000 process models with navigational support through an intranet solution whose use was mandatory in the workplace.

• (c) Results achieved: Improved compliance with regulations and reduction in the number of accidents were observed. This improvement is not attributable only to the restructuring and presentation of the quality system through process models, but the process models are a visible sign of the organization’s focus on safety and compliance, and it has made it easier for workers to find relevant regulations and requirements when dangerous work is to be undertaken.

• (d) Lessons learned: Although good results have been achieved, there is room for improvement in this large-scale example of the use of process models to structure a company’s quality system. Ensuring that all employees can find all the models they need and that the models are kept up to date based on practice are important challenges. In addition, handling the trade-offs among goals for safety, efficiency, and compliance is a challenge. Modeling practices that were regarded favorably at an earlier stage might come to be seen as insufficient for the future needs. Therefore, professional long-term use of models must be conscientiously pursued over time.

1 Introduction

The case organization, which operates in the oil and gas sector, has more than 24,000 employees and approximately the same number of external contractors. It operates in 37 countries, although main operations are in the company’s home country. Permanent employees are divided among organizational units of varying size, with Development and Production (DPN) and Technology, Products, and Drilling (TPD) the largest. The company operates worldwide and, particularly over the last decade, it has used process modeling to structure its massive amount of organizational knowledge.

As an advanced technology company, the organization has a long tradition of adopting new approaches to IT and organizational development. In the 1980s, the organization experimented with the use of process and data modeling in connection with the application of what was then called CASE tools (Solum and Østerud 1989). In the 1990s, modeling was used for a broader set of tasks. As summarized in Christensen et al. (1995), the use of process and enterprise models in the company was divided into three purpose-based categories:

• 1. Construction of reality: modeling as a technique for creating a common understanding among people whose cognitive models do not necessarily coincide.

• 2. Analysis and simulation: making changes to simulated enterprise models and monitoring the consequences to determine whether a change should be implemented.

• 3. Model deployment and activation: the use of an enterprise model for controlling and performing work.

These areas for the use of models are still central for enterprise process modeling (Krogstie 2016). Although the notations used in the various early projects differed and covered a larger part of the enterprise than business processes, the company developed a standardized process-modeling notation. In 2001 (when BPMN was not yet available) this notation was evaluated and compared with other notations (Krogstie and Arnesen 2005) and the “home-brew” notation was kept, albeit with some changes. Some years later, when BPMN arose as a standard, the company adopted it, and in 2004 the company began using enterprise process models as part of its corporate management system. According to Wesenberg (2011) the company “achieved a fair [amount of] success with enterprise modeling in its corporate management system where workflow models are used extensively to communicate requirements and best practices throughout the enterprise.”

Classifying the case according to the BPM Context Framework (vom Brocke et al. 2015), we find the following:

• Goal

  • Focus: The focus is on exploitation of the framework to support compliance and improvement.

• Process:

  • Value contribution: The main value is the standardization of core processes, although the overall framework also supports management and support processes on a less detailed level, since there are fewer compliance rules and virtually no dangerous work situations in these areas.

  • Repetitiveness: The focus on the core processes is on repetitive processes, but the framework also represents non-repetitive processes on a high level.

  • Knowledge intensity: Similarly, the framework covers processes of both low, medium, and high knowledge intensity.

  • Creativity: Similarly, the framework covers processes of low, medium and high creativity.

  • Interdependence: Processes with low, medium, and high interdependence are covered in the framework.

  • Variability: Processes with low, medium, and high variability are covered, although the level of detail differs based on knowledge intensity, variability, and creativity.

• Organization

  • Scope: intra-organizational processes.

  • Industry: product (resources) industry.

  • Size: large organization.

  • Culture: highly supportive of BPM (at least in large parts of the organization, although some parts are only moderately supportive).

  • Resources: high levels of organizational resources used.

• Environment

  • Medium competitive environment.

  • Medium level of environmental uncertainty, although a high level of uncertainty is soon likely given the significant changes in the energy area.

2 Situation Faced

Although the case organization works across a number of fields, the main activity is off-shore oil and gas production. This area focuses on safety and on compliance with the regulations in the country of operations (which are often there to ensure safe production). Offshore work, such as that in the North Sea, is also characterized by workers’ working in shifts (e.g., 2 weeks on and 3 weeks off). When returning to the platform after 3 week off, workers must be able to work according to the procedures from the first minute to ensure safety and compliance.

The organization has a detailed management system, described as “the set of principles, policies, processes and requirements which support the organization in fulfilling the tasks required achieving our goals” (Statoil 2016). The management system defines how work is done in the company, and all employees are required to act according to its relevant governing documentation (GD).

The three main objectives of the management system are:

• 1. Contributing to safe, reliable and efficient operations and enabling compliance with external and internal requirements.

• 2. Helping the company to incorporate its values, its people, and its leadership principles into everything it does.

• 3. Supporting business performance through high-quality decision-making, fast and precise execution, and continuous learning.

GD describes what is to be achieved and how to execute tasks, and it ensures standardization.

The management system’s organizational function, Corporate Security and Safety—Corporate Management System (the CSS-CMS unit) is responsible for creating and improving the management system based on business needs, ensuring that the GD is understood and used, and monitoring compliance with work requirements. Around 50 persons work in this function, and an additional 15 or so persons from other parts of the organization, most notably from Corporate Audit (COA) work daily to ensure the quality and compliance of the quality system. The CSS-CMS function’s work follows a five-step cycle:

• 1. Assess and plan changes to the GD: When a change or update to the GD is needed, a lead nominated by the owner of the GD which often is the same as the owner of the process performs a stakeholder analysis to identify all roles involved. A work group is established to perform the planning and scoping of the work to be done. The plan is then evaluated, and when agreed upon, the design step begins. This step relates to Process Discovery and Process Analysis in the BPM Lifecycle (Dumas et al. 2013).

• 2. Design the GD: A workflow model (or a detailed textual GD or both) is created as described in a predefined workflow. This work includes describing the process’s purpose and triggers, identifying activities, checking its business value, assigning roles, and identifying risks. External consultants usually facilitate the modeling activities, while the process owner and representatives from the stakeholder groups identified contribute in participative modeling sessions (Gjersvik et al. 2005). This step relates to Process Redesign in the BPM Lifecycle (Dumas et al. 2013).

• 3. Implement the GD: When the GD is ready, the implementation is planned and executed. The local process manager acts as a facilitator, the scope of the implementation is assessed, and a plan for the implementation is established. The local process manager then performs the activities needed in order to prepare for the implementation of the new GD in his or her area. If needed, employee training is prepared and conducted. When ready, the local process manager sends a confirmation to the lead of the implementation planning, who passes the confirmation on to the GD’s owner. The GD is then ready for publication. This step relates to Process Implementation in the BPM Lifecycle (Dumas et al. 2013).

• 4. Use the GD: GD is intended for use by its target group, according to its purpose and validity (i.e., to whom it applies). Before dangerous work begins, the actor responsible for the process must go through the documentation/process model, and before getting a work order accepted, the employees acting in each role defined in the process must consult the model. Employees can apply for a permission to deviate from a requirement in the GD, and upon registration of such an application, an initial consideration is performed, where the line manager and local process manager give comments and advice, and relevant contributors propose additional actions. When the application is submitted, the process owner decides whether to submit the application for implementation approval or to terminate it. The line manager then rejects or approves the implementation. Information on the result is then sent to the applicant, and if approved, the deviation permit is ready for use. As part of this process, any employee might also suggest improvements to the general process.

• 5. Monitor and control use of the GD: The purpose of monitoring use of the GD is to reduce risk, drive performance, and ensure compliance. Monitoring can be carried out by internal or external parties. Activities performed in internal monitoring include:

  • Follow-up: ensuring that strategies and tasks are executed according to plan.

  • Verification: confirming through objective evidence that work has been done in compliance with requirements.

  • Internal audit: evaluating and improving the effectiveness of performing a process with a formal mandate from the board of directors to, for example, ensure that projects are properly organized and managed.

The last step relates to Process Monitoring and Control in the BPM Lifecycle (Dumas et al. 2013).

Until 2004, the company’s quality system was text-based and was found in binders around in the organization. After an accident in which the procedures were not followed, it was determined that employees had not been able to identify all relevant procedures. At the same time, the organization merged with another organization that used process modeling more actively for structuring its quality system, and the merged organization was able to build on this example.

3 Action Taken

Over the last decade, the company’s quality system has been restructured and maintained in the form of an integrated collection of process models. The general requirements for the quality system were described above, but five more concrete areas of use are also important :

• 1. Compliance management: Monitor and control how and whether the work performed complies with the standards set for how to work to ensure the production of predictable output from work.

• 2. Competence management: Document the competency profiles needed to perform tasks, compare required competency profiles with the competence represented in the organization, and manage the competency gap.

• 3. Portfolio management: Gain an overview of the current portfolio of, for example processes, information systems, and technologies in order to provide opportunities to determine whether the existing portfolio will meet future needs and to plan the roadmap to move from the current to the future portfolio.

• 4. Analysis and decision-making: The model and its sub-models enable an analysis of the relationships among the objects in the models and how changes to one object (e.g., a process) will impact other objects (e.g., the information systems used by that process or relationships among work processes).

• 5. Performance analysis: Monitor results to obtain experience and data related to quality in order to determine whether the method of working produces the best possible result.

Even if several possible purposes are listed, a model always has one primary purpose, although it may have a number of secondary purposes. The current primary purpose of the enterprise process model is compliance management, so priority is given to achieving an acceptable level of quality for the GD models, along with their corresponding governing elements, roles, and responsibilities. The process owners decide what is the right level of quality based on the use of and feedback related to the models. Guidelines for the quality of the models, including a balance among the syntactic, semantic, and pragmatic quality of the models (Krogstie 2016), are described in the GD, TR0002 (Statoil 2013). Two of the five concrete goals, competency management and performance management, were not included in version 1 of the requirements (Statoil 2009). This change is not an example of “goal creep” [i.e., the use of models for purposes that were not originally envisioned (Krogstie et al. 2008)], but it results from the requirement that the models be current as-is models because of the focus on compliance. Recently, the underlying infrastructure to support the areas of competency management and performance analysis was put into production in the organization.

The model-based management system consists of three main parts:

• The end users assess the process models using a restricted subset of BPMN (Silver 2012) that is represented in the ARIS tool , the modeling solution that all of the GD in the models and in accompanying detailed documents uses. The models are as-is models that are manually activated; that is, they represent how people are expected to work at the company and also support checking adherence to the models at times such as when employees are doing dangerous work or submitting new work orders.

• Docmap is used for handling and publishing textual GD. These more detailed documents are directly accessible from the process models in ARIS, where they are relevant.

• Disp is a tool that supports the process of handling applications for deviation permits when compliance with a requirement is difficult or impossible to achieve. Disp is also accessed directly from the ARIS process models. It is also possible to add suggestions for process improvements directly in the ARIS tool.

There are three levels of abstraction in the enterprise process model—the contextual level, the conceptual level, and the logical level—which include the interrelated diagrams illustrated in Fig. 1. Examples of each diagram-type are found in Figs. 1, 2, 3, 4, 5 and 6. The example diagrams provide a “flavor” of the types of models on the various levels and are not meant to be read.

• The top-level diagram (Fig. 2) is a mandatory navigational diagram that visualizes core value-chain processes, management processes, and support processes, capturing what the company terms “the contextual level.” This diagram is similar to a process map (Malinova et al. 2014), as it depicts core, support, and management processes at the highest level.

• The navigation diagram(s) (Fig. 3) are optional diagrams that support more tailored access to the processes for users in various parts of the organizations than is provided by the top-level diagram. All models show validity (i.e., relevance) for all business and organizational units, so a person has access only to the part of the model that is relevant to him or her based on the organizational unit to which he or she belongs.

• The model diagram (Fig. 4) is a mandatory diagram that visualizes the model of one process area in the organization.

• The process navigation diagram (Fig. 5) is an optional model for navigational support on the conceptual level.

• The workflow model (Fig. 6) contains BPMN models on the logical level. This model is similar to what others term “the descriptive level” (Silver 2012). The quality system contains approximately 2000 BPMN models at this level, qualifying the case as BPM-in-the-large (Houy et al. 2010).

Fig. 1

Structure of models in the management system

Fig. 2

Top-level diagram, a.k.a. company process map

Fig. 3

Navigation diagram

Fig. 4

Example of a model diagram

Fig. 5

Optional process-navigation diagram

Fig. 6

Example of workflow diagram

The contextual level consists of a top-level diagram and navigation diagrams and provides a high-level overview of the enterprise. The top-level diagram, which is mandatory, contains a model of the enterprise in terms of both process areas and function areas. The management system’s start page, shown in Fig. 2, is a top-level diagram.

The purpose of the navigation diagrams, which are optional, is to help the user navigate to the correct model by structuring and detailing the content in a process area. The navigation diagram can contain symbols that represent closed content groups, document model groups, and document models. A stippled rectangle can be used to group a set of closed content groups. An example of a navigation diagram is given in Fig. 3.

The primary purpose of the conceptual level, which provides a conceptual view of the enterprise as model diagrams and process navigation diagrams, is to show relationships between or within models.

The model diagram in Fig. 4 is a mandatory diagram that shows the content of a closed content group or a process area. It may contain collapsed workflow models, process models, and document models. A rectangle can be used to group a set of collapsed process models, and for quicker navigation, collapsed workflow diagrams can be placed inside a collapsed process model symbol.

The optional process-navigation diagram (Fig. 5), which is used to show how workflow models are related to each other, uses collapsed workflow models, start events, end events, and intermediate events. A sequence flow in the form of an arrow visualizes the order in which the workflow models are to be executed.

The logical level shows the breakdown of the enterprise model into generic elements. The only diagram that visualizes the logical level of the enterprise model is the workflow diagram, a mandatory diagram that is modeled using an adapted subset of BPMN 2.01. This diagram has several activities and may have decision gateways arranged in a sequence within lanes that represent the process role that is responsible for those activities. The activities, which are carried out by someone who represents the process role, are represented by a task symbol. Activities can be either mandatory or optional. A set of task symbol with a stippled line around them is used to represent a collaboration activity that includes more than one role. (This is a modeling mechanism not found in core BPMN.) The diagram can also contain either collapsed sub-processes that lead to another workflow diagram that details the sub-process or call task symbols that refer to a workflow model in another process model. The workflow diagram also contains start and end events and various types of standard gateways (“and” and “xor”), but not intermediate events or complex gateways.

An example of a small workflow diagram is given in Fig. 6, which shows the interactions among three roles (as swimlanes) relative to a coordination activity that involves risk assessment and activity approval. The approver and senior approver are mandatory participants in the task, whereas the advisor is an optional participant. When the coordination activity is complete, the task ends successfully if pre-approval has been made. This example follows the version of BPMN the company uses (Statoil 2013; Heggset et al. 2014), which differs somewhat from the official BPMN definition (e.g., including special semantics in the grouping mechanism) and links to extra requirements and guiding documentation from the models (stored in the Docmap tool). The use of restricted and tailored subsets of BPMN is common in practice (Aagesen and Krogstie 2015).

There are several ways for users to access GD:

• Navigating through process areas: When a user accesses the ARIS start page, he or she gets an overview of all process areas and can click one for an overview of the content in it. From there, the user can access work processes, documents, workflow models, and other information.

• Using the navigation history: The user can use the dropdown menu to access his or her navigation history from anywhere in ARIS. This menu displays the pages in the management system that the user previously visited.

• Using “breadcrumbs”: From any but the top level in the hierarchy users can navigate to higher levels using “breadcrumbs” located at the top of the page. (See, e.g., Figs. 3, 4 and 5) The “breadcrumbs” also help users keep track of where they are in the process hierarchy.

• Searching: ARIS search is a simple search interface into which the user can put search words and then use a drop-down menu to choose the type of GD that they seek. The results appear as a list of full or partial hits that is updated as the user types.

• Using “MyPage”: Each user has a personal space, called “MyPage,” which is accessible on each page. Beginning from a workflow model page, the user can click the “Subscribe” tab and confirm that he or she wants to subscribe to that particular model. Within a short time, a direct link to the model will be available in the Subscriptions section of the user’s MyPage.

4 Results Achieved

The company’s quality system had been text-based and stored in large binders before it was restructured as a network of process models. Our contact in the company claimed that the process modeling approach provided the employees the ability to structuring the quality system in manageable pieces that, together with good tool support for accessing the models and detailed requirements for the process, made it much easier to find relevant parts of the process, thus doing a better job of supporting the work to be done. One KPI in particular that improved after the introduction of this new way of structuring the quality manual is the Serious Injury Frequency (the SIF-index). Figure 7, which is based on the company’s yearly sustainability report (Statoil 2015), provides an overview of the positive development in the company’s injury frequency over the last decade.

Fig. 7

Development of the SIF-index over the last decade. The red line in the bottom indicate the trends for injuries, whereas the yellow middle line indicate the trend for reported incidents, i.e. dangerous situations (without physical injuries)

To investigate how the improvments in the SIF-index might be related to the models, we looked at actual model use. Using the models as a checklist before starting dangerous work (safe job analysis) and before getting work orders accepted (work permits), including daily work-permit meetings, is mandatory. In recent years, the company has been using the Splunk Enterprise tool, a platform for collecting and indexing machine-generated data such as click-streams, to monitor the use of the management system. The data collected by Splunk are indexed as events and can be searched using the Search Processing Language (SPL), a query language developed by Splunk. The search results in Fig. 8, which are based on around a half year of usage data, provide information on how employees use the enterprise model, such as how often a certain page or model is accessed and how users navigate through the enterprise process model. According to the results collected from Splunk and a user survey fielded in the company, Operation and Maintenance (O&M) is the process area that uses the management system most frequently. The number of navigational elements and levels in ARIS vary widely by process area, so the search included only clicks on workflow models at the bottom level and excludes events that lack the “process area” field. Therefore, the calculated percentage for each process area is the percentage of the total number of events that do contain the field for process area.

Fig. 8

Process areas’ system use

Table 1 lists the ten most frequently used workflow models. Twelve of the 20 most frequently used models deal with safety-critical processes; that is, either they are classified as Safe work (a sub-category of O&M) or they belong to the Safety process area. The high number of distinct users over the half-year period indicates the models’ high level of use, which occurs at least in part because their use is mandatory in many operational areas.

Table 1 The ten most frequently used process models

Table 2 lists the total number of clicks for each organizational unit for the 6-month period, along with the average number of clicks per user. (This value was calculated only for organizational units with more than a thousand total clicks.) As the table shows, DPN is the organizational unit responsible for the largest number of workflow hits, although both COA and CSS have much higher average hits per employee, with 186.8 and 138, respectively. This result is not surprising because one of COA’s primary responsibilities is to evaluate and improve the management systems’ effectiveness. CSS’s sub-unit, CSS-CMS, is responsible for the corporate function described in Sect. 2, related to the management system. Therefore, although employees in these units work directly with the management system, they are not its primary end users.

Table 2 Workflow model hits per organizational unit

Although used in various ways and at various levels, the models were visited and searched for extensively and by more than 24,000 individual people over the 6-month period (i.e., almost all employees). One can use various methods to access the workflow model of interest, and a clickstream analysis enables a more detailed study of this phenomenon.

A path analysis for the most frequently used workflow model, “Prepare isolation plan,” shows that the most common path corresponds to navigating from the start page directly down through all of the layers above the model page, which indicates that 38.8% of those who used this model knew exactly what they were looking for and where to find it. That so many users went directly to the model via the navigational pages is unsurprising considering that this model is the most-used workflow model, so most of its users probably use it frequently and have learned where it is located. Even so, although they use it often, these users do not use “My Page:” or bookmarks to access it directly. However, 15.1% of those who use this model either do that or access it through the search function, because the second most-popular path contains only one click—to the model itself. The fifth most-common path is the only one in the top five that suggests that the user looks for the model in several places before locating it.

Another example process is “Chemical management”. Whereas 11,753 sessions ended with a view of “Prepare isolation plan,” only 2096 ended with “Chemical management.” However, as many as 42.4% of users went directly to “Chemical management,” whereas only 15.1% accessed “Prepare isolation plan” directly. The number of sessions in which the workflow model is accessed directly varies widely by sub-model, perhaps in part because awareness of the “MyPage” functionality is higher in some parts of the organization than it is in others. The intuitiveness of the model’s placement in the hierarchy is another possible explanation. Users might use the search function when they feel that it is difficult to locate the model using their intuition and knowledge about the process area.

Diagrams that are designed in the enterprise process model must meet specific company requirements. Heggset et al. (2014) provides an overview of the company’s modeling requirements structured according to SEQUAL’s model quality levels (Krogstie 2012).

5 Lessons Learned

Although the models in the quality system are widely used and likely contribute to the improved safety and compliance of company operations, there is also room for improvements in the approach.

A large-scale user survey was conducted in the company to clarify users’ experiences and opinions related to the management system and GD. The survey was completed by 4828 employee participants, approximately half of those invited to respond (Heggset et al. (2015a)). The results of the survey revealed many challenges related to the management system itself, as well as educational processes and work practice, all of which contribute in some way to the management system’s goals of safety, reliability, and efficiency. Some important points from the survey revealed that:

• Many of the employees have trouble finding what they need when they look for GD, although the clickstream analysis indicates that the level of difficulty varies in different parts of the organization. Moreover, when users do find the relevant documentation, many are unsure that they have found all of it.

• Many are not satisfied with how changes to the GD that affect their work are communicated, which makes it difficult to know whether their information is current. Fourteen percent of the respondents report using paper copies to access GD in part because of limited access to IT systems on the oil-platforms; therefore, unless employees are notified of changes, they might continue to use old versions. This situation has improved, though, so the quality system is used as a work tool for preparing the tasks to do out on the platform deck.

• The models use too many abbreviations. Although the guidelines for modeling explicitly discourage the use of abbreviation (Heggset et al. 2014), these guidelines are not always followed.

• There are many guidelines for the correct use of the modeling language and many examples of those guidelines’ being only partly obeyed. Although this issue was not explicitly mentioned in the survey, when a large number of syntactic errors are found in the models, comprehension can be affected (Heggset et al. 2015b).

• The process of handling improvement proposals is experienced as being too slow for some users.

• Sixty-eight percent of those who responded to the survey feel that the GD has the right amount of detail, although they are seen as too rigid or general to account for local needs and variations in some cases, leading to many requests for deviations because the models are not seen as properly fitting the domain of the specific sub-process.

• Approximately half of the respondents feel that the GD is easy to understand, but others perceived it as vague and ambiguous, especially with respect to authorities and responsibilities. Approximately half of the respondents have participated in organized training related to the use of GD. These respondents have a higher score for confidence in, use of, and compliance with the GD than the respondents who have not participated in a training program.

• The survey showed that good leadership support has a strong positive effect on use.

• Considering how GD contributes to the management system’s goals, the results from the survey indicate that it makes a substantial contribution to a high level of safety (as confirmed by 75% of the respondents) and to a moderate to high effect on reliability, but not to high efficiency (37%). One in five of the respondents feel that safety and efficiency is not properly balanced. Reasons for this imbalance include that the GD is experienced as too focused on safety, which sometimes results in longer task-execution times, and that local best practices are not always reflected in the GD. Even so, safety was a main driver for restructuring the quality system in the first place.

The quality system was developed especially to support compliance with requirements in order to reduce risk, an area in which large improvements have been observed over the last decade. Still, there are challenges related to, among other things, finding all relevant information, the comprehensibility of some of the models [although the pragmatic quality of models has been emphasized (Wesenberg 2011)], the update of models based on local needs, and the combined focus on compliance, safety, and effectiveness. The need for training is also emphasized.

Through the Splunk analysis, the user survey, interviews, and conversations with company employees we have gained valuable insights into how users experience the management system. Some measures can be taken to achieve higher model quality, as some users in the user survey report that the GD is difficult to understand, and improved understanding is a necessity if 100% compliance is the goal. Measures that can contribute to increased understanding include strictly applying the language guidelines and naming conventions and tailoring model complexity to the needs of the target audience. Processes for including employees’ knowledge more directly in the loop, such as the AKM approach (Lillehagen and Krogstie 2003) and the use of interactive models (Krogstie and Jørgensen 2004), and for clearer model governance are also important. Changing the organization’s emphasis to focus more on efficiency, rather than only on safety and compliance may influence the perception of quality.

The company’s use of modeling has evolved over the years, and models and modeling practices that were once regarded favorably might come to be seen as insufficient later. As in many companies (Krogstie 2008) one see a need to integrate also other type of modeling perspective than process models. Therefore, the serious long-term use of models must be conscientiously followed up over time as the organization’s context and need for modeling changes.