Active Knowledge Modeling

Business processes are commonly defined as a set of related activities directed at producing an outcome. In bureaucratic case processing, the outcome is typically a decision, which is documented in a case file and communicated using e.g. formal letters. For the management, improvement and automation of some of these processes, BPM and workflow systems are adequate. Knowledge intensive processes like engineering, design, and construction, however, produce outcomes that are far more complex. To manage, improve, and automate such processes, we must design product models and process models in parallel, with evolving product structures as the core and foundation. This post presents a case from oil&gas field development, outlines why a product-driven business process management approach is needed, and how it is applied.

The Case: Piping Design

In order to understand the profound influence that product structures have on work processes, we will look at the example process of designing the piping in a chemical processing plant, such as an offshore oil&gas platform. The types of product elements being designed are depicted below. (Arrowheads signify that the target only is connected to one origin).

Product element types and relationships in piping design

The core element being designed in 3D, is the area line, which is the section of a process line that is found within one area. Process lines can be regarded as the logical design of the line, while the area lines define its physical layout. Systems engineering defines the process line, its class, material, and dimension, based on what will flow through the pipe, its rates, pressures, and temperatures.

Lines connect equipment like oil pumps, compressors and separators, and instruments may be mounted on lines or equipment to monitor the process. Equipment and instruments are typically purchased from suppliers, and they are organized into procurement packages based on e.g. lead times. Lines are kept in place by pipe supports, which are attached to structure elements (floors, walls, beams).

The key activities (rounded rectangles) and organizational roles (triangles) involved in the design of these product structures, is added to the model below. The primary aim is to complete the 3D layout modeling of the pipe area lines, so that manufacturing may start. However, in order to mark a pipe as design-completed, related activities must also be finished:

• Process line design for the given line, by systems engineering,
• Equipment and instruments connected to the line must be fully specified by suppliers (as data sheets and general arrangement (GA) drawing),
• Equipment and instruments must be modelled in 3D,
• All pipe supports for the line must be laid out in 3D, and the attachment to structure elements reviewed,
• For critical lines, isometric stress analysis must be performed. Whether a line is critical is determined based on its size, and which system it is part of.
• The planning group is responsible for coordinating all the activities.

Products, processes and organizational roles in piping design

These activities have been modeled as part of the quality control system of the engineering company. Like any conventional process model, these activities must be structured into a single work breakdown hierarchy. In this case, the process was broken down according to these rules:

1. At the top level, the engineering process is broken up into 5 phases, each with 1-4 stages. Here the process is structured according to the temporal dimension.
2. One level down, we identify a set of key activities for the most important discipline groups. Most disciplines are involved throughout all the stages and phases, so the time and discipline dimensions create a matrix structure.
3. For each cell in the time/discipline matrix, a best practice process model is defined, each containing 5-15 activities. The process models have defined interfaces to preceding, concurrent, and later processes and activities.
4. For each activity in the best practice quality control processes, the project plans will include one instance for each higher level product module. The modularization principles differ across disciplines, so 3D modeling activities are organized by geometric area, systems engineering by system, procurement by procurement package, etc. The activities at this level are the units of planning, monitoring, and management.

This structure is a good fit for a business process model of this kind of engineering work. However, if you build an automated process support system based on these models, you will fail. One reason is that the model is dominated by the concerns of management, not the engineers who perform the work. The process hierarchy is constructed to facilitate reporting and monitoring, and dependencies are represented at a relatively high level (levels 3 and 4 above). The theory that you can report status up to the right management level, and then the managers will coordinate all dependencies, does not hold water anymore. Top-down process management must be combined with bottom-up process execution in middle-out coordination.

Process execution, management, and coordination

We need a fine-grained coordination based on the dependencies between product elements. As discussed above, it is the concrete connections between individual pipes, equipment, instruments, supports etc. that creates a need for coordination. The activities that need to be coordinated are scattered across the whole process management hierarchy, placed in different level 4, 3, 2 and even top level activities (phases). Conventional BPM clearly does not address the core concerns of product-driven processes.

Products and Processes – A Knowledge Architecture Approach

The key is to conceptualize the problem, and to model it, in more than one dimension. This is illustrated below, where a task is connected to surrounding process, product, organization, and infrastructure models. Rather than seeing tasks and activities as just the leaf nodes of the process hierarchy, our knowledge architecture methodologies recognize that many tasks are better understood from another perspective. Product-driven tasks were discussed above, but there are also task patterns in e.g. reporting and decision making, which are best understood and managed from an organization perspective. Several tasks also arise from infrastructure requirements, e.g. data replication across application systems, or transport between manufacturing machinery in a plant.

Tasks in process, product, organization and infrastructure models

In engineering, it is critical to design the process models and the product models together. In a given project, the selection of a product concept will often determine which overall engineering process that we should apply. On a more detailed level, the selection of which product components and modules to include, will determine which activities we need to perform.  One important benefit of a combined product and process modeling approach is that it directs focus on the value-adding steps in the process, the ones that directly contribute to the end product. It is also aligned with current project and process management practices in many industries.

One reason why BPM has been applied for engineering, is that the processes by themselves are quite simple, compared to the product models. The complexity of the business process arises from the number of concurrent process instances for each product element (up to several thousand), and the dependencies between these instances, captured by the product model. Some BPM languages, e.g. event-driven process chains (EPC), allow a combination of a product- and a process-oriented approach, through constructs like event or state that are connected to the sequence flows between activities. In general, we find that

Relationships in the product model often appear as tasks in the process model.
Relationships (sequence flows) in the process model often appear as states or types in a product model.

Ideally then, a model-based project design environment should facilitate seamless transfer between process and product views. They should be managed as mutually reflective views on the same phenomena, so that changes to one view are immediately reflected in the other. At the same time, we cannot automatically generate entire process models from the product model. The interdependencies are not that simple, neither is process design. Both the product model and the process model will evolve, be extended and elaborated throughout the project.

Product-Driven Process Execution Using Events and Task Patterns

An execution framework for product-driven processes must be capable of handling evolving and incomplete process models. Interactive execution, where responsibility for deciding what to do next is shared between a rule-based engine and its users, was briefly described in a previous post. In order to automatically react to dependencies and changes in product structures, the execution engine should have these capabilities:

• Event driven, so that tasks may be triggered e.g. by updates of a product property or addition of a product component.
• Rule based, so that different tasks can be applied for different types of product elements.
• Data driven, recursive, so that tasks may be applied dynamically to every element of a large product structure.
• State controlled, so that the state of a product element affects how it is handled and which tasks may be performed on it.
• Dynamic and partial process instantiation, so that the process always reflects an up to date product model.
• Parameter resolving through multi-dimensional inheritance, so that tasks can be applied to product components dynamically, with as little manual data mapping as possible. Some parameters will get their value from the process context, others from the product context.

All in all, Event-Condition-Action rules are a suitable approach for managing an evolving network of loosely coupled product and process components, however, many actions (tasks) will also be triggered or even created manually by engineers doing their job.