Production-Aware Analysis of

Multi-disciplinary Systems Engineering Processes

Lukas Kathrein

, Arndt Lüder

, Kristof Meixner

, Dietmar Winkler

and Stefan Biffl

Christian-Doppler-Laboratory for Security and Quality Improvement in the Produciton System Lifecycle,

Technische Universität Wien, Favoritenstraße 9-11, Vienna, Austria

Institute of Factory Automation, Otto-von-Guericke University of Magdeburg, Magdeburg, Germany

Institute for Information Systems Engineering, Technische Universität Wien, Vienna, Austria

Keywords: Production Systems Engineering, Product-Process-Resource (PPR) Relationships, Engineering Process

Analysis, Engineering Knowledge Representation.

Abstract: The Industry 4.0 vision of flexible manufacturing systems depends on the collaboration of domain experts

coming from a variety of engineering disciplines and on the explicit representation of knowledge on relation-

ships between products and production systems (PPR knowledge). However, in multi-disciplinary systems

engineering organizations, process analysis and improvement has traditionally focused on one specific disci-

pline rather than on the collaboration of several workgroups and their exchange of knowledge on product/ion,

i.e., product and production processes. In this paper, we investigate requirements for the product/ion-aware

analysis of engineering processes to improve the engineering process across workgroups. We introduce a

product/ion-aware engineering processes analysis (PPR EPA) method, to identify gaps in PPR knowledge

needed and provided. For representing PPR knowledge, we introduce a product/ion-aware data processing

map (PPR DPM) by extending the BPMN 2.0 standard, adding PPR knowledge classification. We evaluate

the contribution in a case study at a large production systems engineering company. The domain experts found

the PPR EPA method using the PPR DPM usable and useful to trace design decisions in the engineering

process as foundation for advanced quality assurance analyses.

1 INTRODUCTION

The goal of production systems engineering (PSE) or-

ganizations is to create automated manufacturing sys-

tems (Biffl et al., 2017). These companies support

achieving this goal by creating their own special in-

formation systems and tools (usually integrating best

purpose tools) and by using them throughout the en-

gineering process, similar to software developers us-

ing a tool chain for code development (Lüder, 2017).

However, in the PSE process insufficient representa-

tion of important relationships between the product,

the production process, and production resources

(PPR) may lead to considerable risk of low quality

and unanticipated costs during production system op-

eration. Although PSE organizations build on pro-

found PPR experience, surprisingly, PPR relation-

ships are not routinely modeled explicitly in the PSE

process. The equivalent in information systems engi-

neering (ISE) would be not to communicate non-

functional operational requirements, e.g., on perfor-

mance or security, to the software developers, making

it costly and risky to fulfill these requirements during

systems operation. To address these challenges, the

ISE and software engineering communities have in-

troduced operation-aware processes and methods

such as SCRUM (Schwaber, 2002), DevOps (Zhu,

2016), or rapid prototyping.

However, the involvement of several disciplines

in PSE and the complexity of productions systems,

which involve risky hardware, make it much harder

to engineer and explore the target system in short

feedback cycles. On the contrary, PSE domain ex-

perts tend to focus on the specific contribution of their

discipline to the overall PSE process without specifi-

cally considering product or production process as-

pects (Biffl, 2018).

In this paper, we focus on the capability for the

analysis and improvement of multi-disciplinary engi-

neering processes that exchange knowledge between

workgroups. We investigate the product/ion (i.e.,

Kathrein, L., Lüder, A., Meixner, K., Winkler, D. and Bifﬂ, S.

Production-Aware Analysis of Multi-disciplinary Systems Engineering Processes.

DOI: 10.5220/0007618000480060

In Proceedings of the 21st International Conference on Enterprise Information Systems (ICEIS 2019), pages 48-60

ISBN: 978-989-758-372-8

product and production process) aware analysis of

engineering processes as there is significant potential

for improvement in the collaboration and coordina-

tion of PSE workgroups by considering and explicitly

representing PPR knowledge, like process parameters

or product resilience. Product/ion-awareness in the

context of software engineering, is knowledge on

how to develop and configure a system, the product,

to run ideally in a target environment like a web

server (the process executing the product). In this pa-

per, we use the term PPR knowledge for success-crit-

ical attributes, such as configurations and parameters,

and dependency relationships between products, pro-

duction processes, and production resources.

We illustrate the PSE process with the use case

fragile product. A customer requires a production

system for producing fragile products. In the PSE

company, a basic planner specifies the production

process and system according to the product require-

ments. A team of detail planners derives discipline-

specific detailed plans for constructing and operating

the production system from the specifications, includ-

ing a high-throughput transport system. Unfortu-

nately, during operation of the system, the high accel-

eration of the transport process potentially damages

fragile product parts due to the missing explicit PPR

knowledge of detail planners on product fragility, a

critical product-to-production-process relationship,

in the specifications of the basic planner. From this

use case we derive the following key challenges.

C1. The engineering process between discipline-

specific workgroups is hard to trace and analyze. Tra-

ditionally, the focus of organization in PSE is on one

workgroup. Workgroups collaborate according to

project needs in changing configurations by exchang-

ing engineering artifacts, often inefficiently. How-

ever, there is no formal process or knowledge repre-

sentation to guide or analyze the cooperation of

workgroups in the engineering process.

C2. Unclear benefit of representing PPR

knowledge. For domain engineers, e.g., basic plan-

ners, who have knowledge on the product and design

the production process, it is not clear which roles

would benefit to what extent from sharing their PPR

knowledge. Therefore, they do not take the extra ef-

fort to explicitly represent PPR knowledge that could

be beneficial for detail planners and other roles.

C3. Unclear impact of PPR knowledge. For prod-

uct engineers, it is often not clear which effects their

design decisions have on later phases in production

systems engineering. The domain experts have only

limited overview on the positive or negative impact

their design decisions may have on the achievable

product quality and similar systems planned in the fu-

ture.

To address these challenges, we derive the follow-

ing research questions for improving the product/ion

(i.e., product and production process) aware analysis

of engineering processes of workgroups following

the design science cycle (Wieringa, 2014).

RQ1. PPR EPA Method. What adaptions or combi-

nations of business/engineering process analysis

methods allow overcoming their limitations regard-

ing product/ion-aware engineering process analysis?

Based on existing approaches from business process

analysis (BPA) and PSE, we identify capabilities and

limitations of process and data analysis approaches

for a product/ion-aware engineering process analysis

(PPR EPA) method. Both domains have similarities

that can be used for adapting an EPA method (Biffl et

al., 2017). Based on requirements elicited in work-

shops with domain experts, we introduce a PPR EPA

method. We evaluate the PPR EPA method in a ho-

listic case study (Runeson and Höst, 2009) by con-

ducting process analysis tasks with stakeholders from

workgroups on their exchanged artifacts in order to

classify PPR knowledge in engineering artifacts.

RQ2. PPR DPM Notation. What adaptions or com-

binations of business/engineering process notations

allow overcoming their limitations for representing

stakeholders, processes and documents that may rep-

resent PPR knowledge? Based on requirements com-

ing from the PPR EPA method and on the analysis of

existing notations, we propose an extension of BPMN

2.0 to design and evaluate a product/ion-aware data

processing map (PPR DPM) as foundation for the

analysis of gaps in the PPR knowledge representation

in the engineering process. Following the design sci-

ence approach, we validate the treatments, PPR EPA

method and PPR DPM artifact, in the context of the

case study. The result of RQ2 allows the stakeholders

to express the PPR knowledge needs in the engineer-

ing process as foundation for overcoming identified

shortcomings.

The remainder of the paper is structured as fol-

lows: Section 2 summarizes related work on strengths

and limitations of process analysis approaches. Sec-

tion 3 introduces requirements for the PPR EPA

method and PPR DPM artifact, and the treatment de-

signs. Section 4 presents the case study conducted

with domain experts in a large PSE company. Section

5 evaluates and discusses the case study results. Sec-

tion 6 concludes and proposes future research work.

Production-Aware Analysis of Multi-disciplinary Systems Engineering Processes

2 RELATED WORK

This section summarizes related work on production

awareness (PPR), on approaches for engineering pro-

cess analysis, and on notations for representing the

analysis results.

2.1 Production Awareness (PPR) in

Multi-disciplinary Engineering

Technical systems are often distinguished into prod-

ucts and production systems (Biffl et al., 2017). The

product is typically characterized as the reason a com-

pany exists for, i.e., products are created in a value

adding process to make profit by selling them (Stark,

2015). In contrast, a production system provides the

means to create products by the appropriate combina-

tion of production factors (El Maraghy, 2009).

There are strong dependencies between product

and production system. Schleipen (2015) coined the

PPR concept for the relationships between products

and production systems based on the production pro-

cess, illustrated in Figure 1, as foundation for design-

ing and analysing engineering processes. Each prod-

uct requires for its manufacturing processes, which

are executed by production resources. Each produc-

tion resource processes sets of products and is able to

execute processes. Finally, each process is used for

the production of products.

Figure 1: Product, production Process, and production Re-

source (PPR) relationships.

2.2 Engineering Process Analysis

Method

Business process analysis (BPA) methods, like (Ros-

enberger, 2018), determine and define activities

which need a business context and then execute a con-

text elicitation. Santos and Alves (2017), follow the

design science cycle from Wieringa (2014), and pre-

sent a three phase in depth analysis of the business

process, based on interviews. The BPA contributions,

present detailed execution steps on how to represent

the big picture of business processes for analyzing

characteristics of multiple stakeholders and their ac-

tivities, including exchanged documents. Vergidis et

al. (2009), classified BPA methods and concluded

that only few BPA methods allow for more detailed

analyses going beyond the identification of stake-

holders, tasks and input/output artifacts. As a limita-

tion for engineering process analysis, BPA methods,

do not consider individual disciplines, interfaces be-

tween workgroups for cooperation and collaboration

or dependencies regarding knowledge transfers

across an organization. However, the analysis of en-

gineering processes across workgroups requires both

the analysis of the overview on relationships of

workgroups and a more detailed analysis of the ex-

changed engineering artifacts according to the de-

pendencies between workgroups.

In the PSE community, Jäger et al. (2011) identi-

fied the need to “systematically model the engineer-

ing workflow, which would allow a deeper knowledge

of different engineering aspects and to improve the

views of each discipline on the engineering objects.”

To fulfill this need, the authors analyzed engineering

artifacts and their mappings to domain experts as

foundation for creating cause and effect diagrams.

Through these analyses, Jäger et al. (2011) gained in-

sights into the needs of specific workgroups, and on

dependencies between engineering artifacts.

Lüder et al. (2012) investigated a detailed engi-

neering process analysis method focusing on single

workgroups, but did not consider how the overall en-

gineering process of multiple workgroups is con-

structed or could be improved. In a second publica-

tion Lüder et al. (2018) investigate challenges that

arise in multi-disciplinary engineering processes re-

garding data exchanges and highlight the importance

of an engineering process analysis method.

The VDI 3695 standard (VDI, 2009), presents a

more general approach and coined the concepts of en-

gineering organizations, which execute their work in

a project-based manner. The standard, points out pos-

sible improvement areas, but does not consider con-

crete implementation guidelines, this stands out, be-

cause for example the need of a shared data model is

identified, but how an engineering organization can

achieve a unified view of their data is not presented.

Engineering process analysis (EPA) methods

tend to focus more on discipline internal representa-

tions and improvements, whereas BPA methods al-

low representing an overall big picture of business

processes.

Overall, the analyzed literature reveals a gap of

analysis methods regarding workgroups. There are no

considerations on how workgroups collaborate or co-

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

ordinate common process tasks with each other. Fur-

thermore, the analysis methods do not consider the

PPR engineering knowledge exchanged as founda-

tion for identifying risks from missing PPR

knowledge in multi-disciplinary engineering tasks.

2.3 PPR Knowledge Representation in

Process Analysis Outcomes

For modeling both process and data flows in business

processes, there are several established methods with

varying strengths and limitations. In the engineering

domain, the IDEF0 system analysis standard (Presley,

1995) is widely used (Zhang, 2010) for providing an

overview on processes, inputs and outputs, stakehold-

ers and mechanisms. However, IDEF0 diagrams do

not allow to easily represent the sequence of a pro-

cess, represent the flow of PPR knowledge and in-

volved stakeholders need to be annotated per process

task, which makes the models cumbersome to work

with.

Lüder et al. (2012) classify identified knowledge

through tables, which allow a representation of the in-

dividual engineering tasks, but the approach does not

scale well, due to the number of different tables and

high level of detailed represented.

In business process modeling there are several op-

tions like: Event-driven process chains (EPCs)

(Scheer, 1998), BPMN 2.0 (Allweyer, 2016), or the

UML standard (Fowler, 2004). Merunka (2017)

pointed out that the UML standard allows modeling

system structure and behavior, but does not consider

the combination of product and process knowledge in

neither one diagram, nor in combinations of related

diagrams.

Both EPCs and BPMN 2.0 are widely used for

modeling business processes, and have similar

strengths and limitations. When modelling multiple

tasks for one stakeholder, the extended EPC is less

efficient by requiring the annotation of each task with

an organizational unit, whereas BPMN 2.0 provides a

compact swim plane concept for parallel processes.

To overcome the limitations of popular BPA lan-

guages, Khabbazi (2013), Huang (2017), and

Merunka (2017) proposed the combination of multi-

ple concepts. Even though these combinations allow

for working with “best-of-breed” approaches, they

also increase the complexity for further analyses. As

the mentioned authors did not coin a term for the com-

bination of process and document flow, we use in this

paper the term data processing map, whenever it is of

importance that the data aspect of a business process

is considered alongside the process aspect.

While the investigated notations do not consider

expressing PPR knowledge and its flow through an

engineering process, the notations provide a good

foundation for closing this gap with an extension,

e.g., in our case by extending BPMN 2.0 diagrams.

3 PRODUCTION AWARE

ANALYSIS OF ENGINEERING

PROCESSES

To address the limitations of general business process

analysis and domain-focused EPA methods, we pro-

pose an approach for multi-disciplinary engineering

environments, driven by uses cases that represent typ-

ical processes and requirements and are well known

to the domain experts.

The goal of the product/ion-aware engineering

process analysis (PPR EPA) method is to represent a

repeatable process, which results in a PPR data pro-

cessing map (PPR DPM) (see Figure 4). The PPR

DPM is a visual representation of the engineering

tasks in a selected scope that allows reasoning about

workgroup interfaces and responsibility hand overs.

In Section 3.1, we present requirements for the

proposed PPR EPA method, as well as for the PPR

DPM notation. Section 3.2 presents the design of the

treatment PPR EPA method. Section 3.3 introduces

the design of the treatment PPR DPM artifact by ex-

tending BPMN2.0 with PPR knowledge elements.

3.1 Requirements

This section presents requirements for the PPR EPA

method and for the PPR DPM notation. We elicited

EPA requirements and illustrating use cases with ar-

tifact and data samples in workshops with stakehold-

ers at a large PSE company.

RQ1 PPR EPA. To address the goal of systematically

collecting data on the use of PPR knowledge for en-

gineering process analysis and improvement, we de-

rived a set of requirements for capabilities of the ini-

tial product/ion-aware engineering process analysis.

We focus on these requirements because they repre-

sent the PPR knowledge aspect missing in approaches

from BPA and PSE literature.

Identification of PPR Knowledge. The PPR EPA

method should be able not only to identify the se-

quence of engineering tasks but should also allow

identifying PPR engineering knowledge, e.g., that

product knowledge is represented in initial product

drawings from the customer.

Production-Aware Analysis of Multi-disciplinary Systems Engineering Processes

Identification of PPR Knowledge Flows. The PPR

EPA method should follow the creation of PPR

knowledge and tasks requiring PPR knowledge

throughout the engineering process. An example pro-

cess path is: 1. Create production process sequence

with process knowledge; 2. create production system

layout with resource knowledge, process knowledge

is not carried on; and 3. submit production system of-

fer to the customer with resource knowledge.

Identification of PPR Knowledge in Interdiscipli-

nary Interactions. The PPR EPA method should al-

low identifying where engineering disciplines, typi-

cally workgroups, interact with each other, e.g., hand-

over phases of project responsibility or artifacts, e.g.,

the change from basic to detailed planning where all

artifacts are handed over to a new team.

RQ2 PPR DPM. To support the reasoning of domain

experts on improving the use of PPR knowledge in an

engineering process, we derived the following set of

requirements for concepts capabilities of the PPR

DPM and its visualization. These requirements focus

on representing PPR knowledge and the combination

with process and data flow representations.

PPR-specific Visual Elements. The PPR DPM nota-

tion should provide specific elements for the concepts

used in the PPR EPA, including different visual ele-

ments for: PPR knowledge, tasks with a priority indi-

cation for PPR knowledge, and representing which

PPR knowledge an engineering process currently re-

ceives and what is additionally needed.

Iterative Refinement. The PPR DPM should allow

for starting with a small initial model and for itera-

tively expanding the model to the desired level of de-

tail. This allows representing only the most vital en-

gineering process tasks per discipline in the beginning

as context for collecting workflows that are more de-

tailed.

Process Overview. The PPR DPM should provide an

overview on the involved disciplines with their re-

spective process executions, e.g., which role executes

which sequence of tasks, as foundation for reasoning

on improvements, e.g., where engineering disciplines

would benefit from closer collaborations.

3.2 Design of a Production-Aware

Engineering Process Analysis

Method

To address RQ1, we build on a BPA method pre-

sented from Santos and Alves (2017) and extend it

with perspective investigations from an EPA method

(Lüder et al., 2012). This allows for a combination of

the best approaches of both BPA and EPA.

The proposed PPR EPA method is designed to

work in multi-disciplinary environments where the

process execution involves several domain experts

making it crucial to investigate beyond the boundaries

of a single discipline.

Figure 2 provides an overview on the steps and

tasks of the PPR EPA method. The stakeholders are

engineering domain experts (orange), engineering

management (blue), quality assurance (green), and

the new role EPA facilitator (red). The EPA facilita-

tor

conducts the interviews, draws an initial PPR

Figure 2: Steps of the product/ion-aware EPA method based on (Biffl, 2018).

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

DPM, and holds workshops. This role was also iden-

tified in (Fay, 2018) with its importance to the execu-

tion/integration of digital models in an engineering

process. The remaining stakeholders provide infor-

mation and are interested in improving the engineer-

ing process by avoiding rework, such as redrawing ar-

tifacts due to proprietary engineering tool data for-

mats. In addition, the stakeholders are interested in

capturing PPR knowledge in a reusable way for more

efficient exchange of PPR knowledge in the engineer-

ing team.

Phase 1 Initial PPR Engineering Process Analy-

sis elicits the context of the engineering process in the

current state. The investigation already considers PPR

knowledge, but the resulting documentation, includ-

ing an initial DPM, focuses on outlining the context

and not on representing PPR knowledge.

Phase 2 PPR Data Processing Map Design is con-

cerned with the transformation of detailed PPR

knowledge from qualitative interviews into a visual

representation. This step classifies and visually repre-

sents the PPR knowledge in engineering artifacts.

Phase 1. Initial PPR Engineering Process

Analysis starts with initial knowledge about the pro-

ject under investigation. Outcome of this phase are in-

terview documentation, representative engineering

documents and an initial data processing map, which

represents the engineering process and high-level ar-

tifact flows with no PPR knowledge consideration.

Task 1.1. Engineering Process Analysis Kick-

Off outlines the context of the engineering process

with a small team of stakeholders. Outcome of this

task is a document collecting context, goals, and re-

quirements as well as a first sketch of the data process

map providing an overview on stakeholders and their

major tasks building on standard modeling elements

like events, tasks and data flow.

Task 1.2. Interviews with domain experts allow

collecting detailed and diverse data for gaining deeper

insights to the engineering process of the respective

domain expert. The interviewer elicits PPR

knowledge from domain experts, e.g., which PPR

concepts are relevant for a selected process task, as

foundation for an initial PPR classification of engi-

neering artifacts. Outcome of this task is a set of de-

tailed interview notes.

Task 1.3. Initial Data Process Map concerns the

reassessment of the information gathered in the inter-

views with a basic process model of the data flow in

the engineering project. Outcome of this task is a data

processing map consisting of rough process se-

quences and input and output artifacts.

Task 1.4. Wrap Up finishes the first phase of the

PPR EPA by revisiting domain experts to resolve

open issues as it cannot be taken for granted that the

same stakeholders will be available for follow-up in-

terviews in the next phase. Outcome of this task is a

report with an initial draft of the DPM.

Phase 2. PPR Data Processing Map Design

starts off with an initial version of the data processing

map and sets out to detail the current model with PPR

knowledge. Outcome of this phase is the final and re-

fined version of the PPR DPM (see Figure 4).

Task 2.1. Refinement integrates the detail infor-

mation from the interview partners and stakeholders

from Phase 1. Here too, detailed or coarse tasks can

either be split up or be aggregated together. Outcome

of this task is the final basic version of the DPM.

Task 2.2. PPR Classification classifies the input

and output artifacts regarding product, production

process and production resource (PPR) based on the

insights from the interviews regarding the data flow

and concepts represented in the artifacts. Outcome is

a PPR DPM with PPR knowledge classifications for

each artifact and tasks with high or critical need of

PPR knowledge are identified

Task 2.3. Finalization. The EPA facilitator cre-

ates the final version of the PPR DPM, with input

from the remaining stakeholders. Outcome of this

step is the PPR DPM, representing all disciplines and

their process tasks, engineering artifacts and their

flow as well as the classification of these artifacts.

3.3 Design of a Production-Aware Data

Processing Map Notation

To address RQ2 and to be able to represent the out-

comes of the PPR EPA, we explored business and en-

gineering process notations and modeling techniques

like UML, BPMN 2.0 or EPC. We extend these ap-

proaches by indicating PPR knowledge, where it is

possible to label document content regarding product

(P), process (P’), or resource (R) information.

In the first phase of the EPA, the kick-off, we ex-

plored several modeling notations, which revealed the

following limitations: IDEF0 did not scale very well

and was hard to analyze for multiple stakeholders and

PPR knowledge. UML did not provide a single con-

cept and would have required combining several.

EPC and BPMN 2.0 provided similar features, but

EPC was more cumbersome for the requirements

needed for the PPR DPM. BPMN 2.0 fulfills many

criteria presented in section 3.1 but has no means to

classify PPR artifacts or knowledge in general. There-

fore, we use from the BPMN 2.0 standard: events,

tasks, documents and gateways and introduce our

own extensions to express PPR knowledge.

Production-Aware Analysis of Multi-disciplinary Systems Engineering Processes

Figure 3: Custom BPMN 2.0 extensions for product/ion-aware (PPR) Data Processing Map based on (Biffl, 2018).

Figure 3 illustrates the extensions that we intro-

duced to the BPMN 2.0 standard. On the left-hand

side, we take the BPMN 2.0 task concept and add

PPR Knowledge Requirements. These require-

ments are expressed by (a) annotations of P, P’ and R

and (b) white/black broken documents, if at least one

PPR aspect is needed but missing. The annotations of

P, P’ and R indicate what information the task cur-

rently receives (coloured in green) and what infor-

mation is missing (coloured in red). The white broken

document expresses that it is important for a task to

receive PPR knowledge, but that the process execu-

tion is not hindered if PPR knowledge is missing, but

could be conducted more efficiently or with better

quality. A black broken document indicates high risk:

it is absolutely crucial for the task to receive the re-

quired PPR knowledge, otherwise the task cannot be

executed properly, reducing the efficiency or quality

of the overall engineering project outcome.

On the right-hand side of Figure 3, we present

PPR Knowledge Classification of Engineering

Documents. We extend the BPMN 2.0 representation

of documents by adding on top an indication whether

the artefact contains product (P), process (P’), or re-

source (R) information. The documents themselves

are also distinguishable through the annotations in the

middle: a package for a product, conveyor belt for a

process, and a robot arm for a resource. In Figure 4,

tag D1 highlights an engineering task receiving prod-

uct- (P) and process-specific (P’) knowledge.

The annotation of engineering documents with

PPR knowledge is the foundation for describing the

flow of PPR knowledge in the engineering process

and for analyzing which tasks create, lose, or trans-

form PPR knowledge in order to identify key gaps in

the engineering process and propose improvements.

To evaluate the proposed PPR EPA method and

PPR DPM notation, Section 4 reports on a case study,

conducted at a large engineering company.

4 CASE STUDY

To evaluate the proposed approaches for RQ1, the

PPR EPA and RQ2, the PPR DPM, we conducted a

case study following (Runeson and Höst, 2009). We

took the role of the PPR EPA facilitator described in

section 3.2 to go through the tasks with the domain

experts. In the case study, we collected data on the

existing engineering process as well as the role and

current representation of PPR knowledge. The inter-

viewed domain experts communicated their needs re-

garding PPR EPA and PPR DPM.

Study Subject. The case study on the proposed prod-

uct/ion-aware engineering process analysis (PPR

EPA) method was conducted with seven domain ex-

perts, one quality assurance stakeholder and one en-

gineering management stakeholder, and three re-

searchers acting as EPA facilitators. The case study

spanned over nearly two months from the initial kick-

off to the final version of the data processing map and

the final feedback from the involved stakeholders.

Study Execution. According to the PPR EPA Phase

1, Initial PPR Engineering Process Analysis, we held

a kickoff, for a project on ultrasonic welding, at the

company. The kickoff presented the context the com-

pany operates in and gave some insights into the cur-

rent engineering workflow and tool landscape.

The nine interview sessions, for each stakeholder

one, took place over the span of two days, where each

interview lasted one hour. Each interview started with

collecting data concerning the interviewee’s field of

work, usual project-specific tasks and responsibili-

ties. More specific questions regarding engineering

process tasks, the sequence of tasks, engineering arti-

facts and their content, as well as questions regarding

the current representation of PPR knowledge fol-

lowed. After each interview, there was a break, which

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

Figure 4: Production-aware (PPR) Data Processing Map based on (Biffl, 2018).

allowed a short modeling cycle to transform the qual-

itative knowledge into a first visual representation.

After the interviews were finished, the researchers

reviewed the information gathered in the interviews,

categorized artifacts and their content for sharing.

Starting from an initial data processing map (DPM),

we designed a more detailed DPM with information

from the interviews. We discussed the more detailed

DPM with the stakeholders involved, getting their ap-

proval and feedback for improvement as input to the

wrap up step of PPR EPA method.

According to PPR EPA Phase 2, PPR Data Pro-

cessing Map Design, we reexamined the gathered in-

put carefully regarding PPR knowledge aspects and

hidden implications that allowed for some refine-

ments of the engineering tasks. The PPR DPM allows

for a good overview analysis of an engineering pro-

cess, but also linking represented artifacts to concrete

associated files and examples in a separate document

store. In cooperation with domain experts, we exam-

ined and classified the exchanged representations of

engineering data artifacts for information regarding

the product, production process or production re-

source. The classification builds on a mapping by

Hundt (2012) between engineering phases and engi-

neering artifacts, such as electrical or mechanical

plans. In addition, we reexamined the identified engi-

neering tasks and expressed their requirements for

PPR knowledge as no need, important need or crucial

need. Figure 4 illustrates a representative part of the

final version of the PPR DPM.

In Figure 4, the production process planner, in the

BPMN swim lane number one (light orange), starts

each project and receives product and production pro-

cess information, indicated by tag D1: product draw-

ings, product variations, and the customer specifica-

tion. With these input artifacts the production process

planner creates new resource knowledge in the tasks

sketching, plant layout creation, and cost calculation.

A production system planner, see BPMN swim

lane number two (purple), starts working after the

production process planner finishes with the hand-

over of relevant documents, and when all team mem-

bers from different disciplines find the time for a pro-

ject kickoff, indicated by the timer event (clock sym-

bol). The production system planner receives as input

all the output artifacts from the previous role, the pro-

duction process planner, and develops a rough plant

concept, indicated by tag D2, where only resource

knowledge is present, but it would also be important

to receive product and process information.

The work of the automation engineer, see BPMN

swim lane number three (yellow), runs in parallel to

the production system planner and the production

process optimizer, see BPMN swim lane number four

Production-Aware Analysis of Multi-disciplinary Systems Engineering Processes

(dark orange). The automation engineer is responsi-

ble for detailing the electrical point of view of the sys-

tem under construction, whereas the production pro-

cess optimizer aims at minimizing production system

cycle times to maximize the overall production

throughput. Both roles receive resource knowledge

from the production system planner. However, as can

be seen in Figure 4, tag D3, product and process in-

formation is crucial for their engineering tasks. In the

current situation, the domain experts try to get a hold

of the person responsible for a design decision to start

personal, unplanned communication, which takes ad-

ditional time, is very inefficient, and bears the risk of

taking wrong decisions due to insufficient PPR

knowledge.

We evaluate the findings of the case study for the

PPR EPA method and PPR DPM in the next section.

5 EVALUATION AND

DISCUSSION

This section reports on (a) a comparison between the

outcomes of different data processing map notations

in an initial feasibility case study (Runeson and Höst,

2009) with domain experts at a large multi-discipli-

nary systems engineering company and (b) a discus-

sion of the overall process execution, observations,

and lessons learned.

5.1 Evaluation

The conducted evaluation for the PPR DPM uses dif-

ferent requirements than in section 3.1. This is be-

cause the evaluation focuses on the non-functional

parts of the designed artifact. We compare (a) the vis-

ualization of engineering processes with EPC cur-

rently used at the company, (b) a standard BPMN 2.0

model, and (c) an adapted BPMN 2.0 model, accord-

ing to the notation adaptations introduced in Section

3.3.

The evaluation was conducted in an engineering

company that creates custom, project-based, automa-

tion systems.

To evaluate the proposed PPR DPM artifact, we

interviewed the engineering manager, the quality as-

surance stakeholder at the company and received

feedback from domain experts regarding the parts that

were most relevant for them. The stakeholders evalu-

ated the PPR DPM regarding the following ISO

25010 (Bevan, 2009) metrics: functional appropriate-

ness, learnability, performance efficiency, and ana-

lyzability.

Functional appropriateness measures to what ex-

tent the designed artifact allows expressing the engi-

neering environment appropriately. Learnability

measures how easy domain experts and stakeholders

are likely to be able to understand and use the con-

cepts represented in the data processing map. Perfor-

mance efficiency measures the level of time and re-

sources required to use the PPR DPM notation as part

of the PPR EPA method. Analyzability measures to

what extent future analyses can be conducted based

on the PPR DPM.

Table 1 summarizes the results of the evaluation.

The scores are based on a 5-point Likert scale (++, +,

o, -, --), where “++” indicates high fulfilment of the

criterion, “+” indicates good fulfilment of the crite-

rion, “o” represents neutral fulfilment of the criterion,

“-“ indicates disagreement that the approach fulfills

the criterion and “--” indicates strong disagreement

that the approach fulfills the criterion .

The PPR DPM was effective for providing an

overview on the engineering process, including stake-

holder, their tasks and communication, as well as

tasks that require PPR knowledge and engineering ar-

tifacts

that may bear PPR knowledge aspects with

Table 1: Evaluation results for Data Processing Map visualizations based on (Biffl, 2018).

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

new PPR-specific visual elements that extended the

traditional BPMN 2.0 notation.

The case study results reveal that the current state

of domain-specific isolated engineering “silos” bears

significant risk for each new project and that the cur-

rent representation form is not sufficient for any kind

of analysis involving multiple disciplines and their in-

teractions.

5.2 Discussion

This section discusses results regarding the research

questions introduced in Section 1.

RQ1. PPR EPA Method. What adaptions or combi-

nations of business/engineering process analysis

methods allow overcoming their limitations regard-

ing product/ion-aware engineering process analysis?

Section 3.2 introduced the PPR EPA method adapted

from (Santos and Alves, 2017;) and from production

systems engineering (Lüder, 2012). Our adaptations

follow the design science cycle from Wieringa

(2014), as presented in (Santos and Alves, 2017), and

introduce production systems engineering aspects as

presented in (Lüder, 2012) to overcome, the limita-

tions of individual fields regarding product/ion-aware

engineering process analysis. The resulting PPR EPA

method, allows individual disciplines to focus on

their work tasks of and on engineering artifacts that

they receive, create, and exchange with related

workgroups and was evaluated in a case study with

real-world use cases. The new role of the EPA facili-

tator mediates the interests of the EPA in the EPA

process. In the feasibility study, a member of the re-

search team took this role.

The PPR EPA method facilitates identifying and

collecting data on the engineering process to analyze

where relevant PPR knowledge is required, created,

or lost. The domain experts found the PPR EPA

method usable and useful for better understanding is-

sues in the engineering process that were hard to trace

with the traditional focus on production systems,

leaving out considerations of product and production

process factors. The PPR EPA approach facilitates

both, the independent investigation in workgroups for

improving their local capabilities, and the analysis

and improvement of cooperating workgroups by

identifying interfaces and interactions between disci-

plines that may benefit from the explicit representa-

tion of PPR knowledge. Further, allows the PPR EPA

method allows to introduce well-established concepts

from software engineering in a new production sys-

tems engineering context.

RQ2. PPR DPM Notation. What adaptions or com-

binations of business/engineering process analysis

notations allow overcoming their limitations for rep-

resenting processes and documents that may repre-

sent PPR knowledge? Section 3.3 introduced the PPR

DPM notation based on adaptations to the BPMN 2.0

standard as a foundation for representing PPR

knowledge in a data processing map, resulting in a

PPR DPM. The PPR DPM notation elements repre-

sent the necessary PPR knowledge on engineering

tasks and documents for the use cases explored in the

feasibility case study. The introduction of new ele-

ments, such as PPR knowledge requirements and PPR

knowledge aspects in engineering documents, to a

well-established standard allowed minimizing the

number of newly introduced concepts , in comparison

to alternative approaches (Khabbazi, 2013; Huang,

2017; Merunka, 2017). The interviewed domain ex-

perts required some instructions and training to move

from their well-known EPC models to the BPMN 2.0

notation but found the PPR DPM notation easy to un-

derstand, usable, and useful. The PPR DPM concepts

can be easily added to tools that support the BPMN

2.0 standard.

Limitations. The presented research in this paper en-

tails some limitations that need further research.

Feasibility Study. We evaluated the PPR EPA pro-

cess and the PPR DPM in cooperation with domain

experts in a typical large company in PSE of discrete

manufacturing systems. The company can be seen as

representative for systems engineering enterprises,

where business is conducted on a project basis focus-

ing on the engineering of production systems, but

without integrated consideration of PPR knowledge

management. The evaluation results are based on ob-

servations from a limited sample of projects. To over-

come these limitations, we plan a more detailed in-

vestigation in a broader selection of domains and ap-

plication contexts. A lesson we learned was that it is

very important to define a particular scope of the

problem because it is easy to get lost in details of a

complex engineering process, as the domain experts

are very versatile in their field and can express deep

insights into their work. In addition, it became evident

that the quality of the researched process model

strongly depends on the qualification of the EPA fa-

cilitator related to the aims of the EPA organization

(production system to be engineered) and the engi-

neering disciplines involved.

Expressiveness of the PPR DPM Notation. The

DPM PPR notation enabled the beneficial representa-

tion of PPR knowledge aspects for engineering docu-

ments in the use cases of the feasibility study. How-

ever, the stakeholders foresee advanced applications

based on a more detailed modeling of PPR aspects

and relationships, e.g., for constraint modeling, which

Production-Aware Analysis of Multi-disciplinary Systems Engineering Processes

would require extending the expressiveness of the

PPR DPM notation potentially exploiting basic con-

cepts of ISA 95 (International Electrotechnical Com-

mission, 2003) or formal process specification given

in VDI Guideline 3682 (VDI, 2005). However, these

aspects go beyond the scope of this paper. Working

with PPR DPM revealed that it is common in engi-

neering to exchange artifacts that are difficult to pro-

cess for machines rather than data or knowledge.

6 CONCLUSION AND FUTURE

WORK

In a multi-disciplinary system engineering environ-

ment with workgroups collaborating in varying pro-

ject-specific teams, challenges and risks may go un-

detected, if the workgroups mainly focus on improv-

ing their internal processes, tools, and outcomes. This

risk is amplified with the absence of a role that opti-

mizes the collaboration and coordination between

workgroups. Further, in systems engineering there is

a tendency to focus on the properties of the system

design, often with (too) little awareness of the product

that the system should be able to produce in the pro-

duction process.

In this paper, we introduced and investigated sys-

tems engineering use cases for product/ion-aware en-

gineering process analysis (PPR EPA) and a notation

for a product/ion-aware data processing map (PPR

DPM). These contributions provide domain experts

and the new role of an EPA facilitator with a system-

atic approach to represent PPR knowledge in EPA. It

also facilitates pinpointing tasks that require PPR

knowledge and engineering artifacts that contain PPR

knowledge aspects as a foundation for analyzing and

closing PPR knowledge gaps in the engineering pro-

cess.

C1. The engineering process between discipline-

specific workgroups is hard to trace and analyze. The

PPR EPA method results in a graph of engineering

tasks, which potentially require PPR knowledge,

linked by the exchanged engineering artifacts, which

possibly contain PPR knowledge aspects. The net-

work allows effectively and efficiently tracing the en-

gineering process tasks and documents across

workgroups. Therefore, the PPR EPA method re-

duces the risk of low product and production process

quality.

C2. Unclear benefit of representing PPR

knowledge. The product/ion-aware data processing

map (PPR DPM) can be analyzed for assessing the

risk at engineering tasks from insufficient availability

of PPR knowledge and for estimating the extra effort

and cost to represent PPR knowledge in engineering

artifacts explicitly. Consequently, the PPR DPM ena-

bles prioritizing and planning improvement candi-

dates according to their expected cost and benefits.

C3. Unclear impact of PPR knowledge. The PPR

DPM can provide the foundation for assessing the im-

pact of specified PPR knowledge aspects in order to

consider which PPR knowledge to model first. The

PPR DPM further allows maximizing the benefits of

an explicitly represented PPR knowledge element, by

identifying all engineering tasks that potentially ben-

efit from the awareness of this knowledge element.

An example would be using PPR knowledge as a pre-

requisite for introducing Industry 4.0 applications,

such as reasoning on the impact of production process

changes on production systems engineering and oper-

ation.

The PPR DPM is the basis for research on ad-

vanced engineering process analysis and improve-

ment methods. Future methods could, e.g., allow re-

ducing the impact of risks in the engineering process

from important PPR knowledge, such as low product

and process quality. An advanced analysis would also

provide machine-understandable PPR knowledge as a

foundation for reasoning on capabilities, e.g., self-

adaptive processes, during engineering and operation.

Future Work. Advanced PPR knowledge represen-

tation. Following the annotation of PPR knowledge

aspects in engineering artifacts, there is a need to rep-

resent PPR knowledge explicitly in sufficient detail

and to find ways on how to store this knowledge for

efficient processing. This would allow the shift from

engineering artifacts to data and knowledge that can

be accessed for reasoning under the Industry 4.0 vi-

sion.

Traceable design decisions. The explicit repre-

sentation of PPR knowledge is the foundation for rea-

soning about relationships between design decisions

taken on product, production process, or production

system levels. These relationships allow systems en-

gineers to better understand the reason, e.g., for value

ranges of system parameters that depend on charac-

teristics of the product or of the production process.

Generation of system design aspects. In addition,

explicitly modeled dependencies between design de-

cisions may enable the efficient derivation of system

design parameters from product/ion design decisions.

While the efficient derivation of system design pa-

rameters is already beneficial for one system, the re-

use in a production system family is a considerable

business advantage for a PSE company.

IT Security considerations.

The PPR EPA method

enables the collection of PPR knowledge and the

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

analysis of data flows across workgroups. This

knowledge could be interesting to a potential IT secu-

rity attacker and will require research on threats to the

integrity of the collected PPR knowledge and indus-

trial espionage.

Finally, future work will include the application

and evaluation of the PPR EPA method and the PPR

DPM notation in various engineering domains and

application areas.

ACKNOWLEDGEMENT

The financial support by the Christian Doppler Re-

search Association, the Austrian Federal Ministry for

Digital & Economic Affairs and the National Foun-

dation for Research, Technology and Development is

gratefully acknowledged.

REFERENCES

Allweyer, T. (2016). BPMN 2.0: introduction to the stand-

ard for business process modeling. BoD–Books on De-

mand.

Bevan, N. (2009). International standards for usability

should be more widely used. Journal of Usability Stud-

ies, 4(3), 106-113.

Biffl, S., Gerhard, D., & Lüder, A. (2017). Introduction to

the Multi-Disciplinary Engineering for Cyber-Physical

Production Systems. In Multi-Disciplinary Engineering

for Cyber-Physical Production Systems (pp. 1-24).

Springer, Cham.

Biffl, S., Kathrein, L., Lüder, A., Meixner, K. & Winkler,

D. (2018) Secure Refactoring and Reuse of Engineering

Data and Knowledge - Case Study for Ultrasonic Weld-

ing. Technical report, CDL-SQI, TU Wien

ElMaraghy, H. A. (2009). Changing and evolving products

and systems–models and enablers. In Changeable and

reconfigurable manufacturing systems (pp. 25-45).

Springer, London.

Fay, A., Löwen, U., Schertl, A., Runde, S., Schleipen, M.,

& El Sakka, F. (2018). Zusätzliche Wertschöpfung mit

digitalem Modell. Atp Magazin, 60(06-07), 58-69.

Fowler, M., Kobryn, C., & Scott, K. (2004). UML distilled:

a brief guide to the standard object modeling language.

Addison-Wesley Professional.

Huang, Yuze, Huang, Jiwei, Wu, Budan, & Chen, Junliang.

(2017). Modeling and analysis of data dependencies in

business process for data-intensive services. Communi-

cations, China, 14(10), 151-163.

International Electrotechnical Commission. (2003). IEC

62264-1 Enterprise-control system integration–Part 1:

Models and terminology. IEC, Genf.

Jager, T., Fay, A., Wagner, T., & Lowen, U. (2011). Mining

technical dependencies throughout engineering process

knowledge. Emerging Technologies & Factory Auto-

mation (ETFA), 2011 IEEE 16th Conference on, 1-7.

Khabbazi, M. R., Hasan, M. K., Sulaiman, R., & Shapi'i, A.

(2013). Business Process Modeling in Production Lo-

gistics: Complementary Use of BPMN and UML. Mid-

dle East Journal of Scientific Research, 15(4), 516-529.

Lüder, A., Foehr, M., Köhlein, A., & Böhm, B. (2012). Ap-

plication of engineering processes analysis to evaluate

benefits of mechatronic engineering. In Emerging

Technologies & Factory Automation (ETFA), 2012

IEEE 17th Conference on (pp. 1-4). IEEE.

Lüder, A., Schmidt, N., Hell, K., Röpke, H., & Zawisza, J.

(2017). Fundamentals of Artifact Reuse in CPPS. In

Multi-Disciplinary Engineering for Cyber-Physical

Production Systems (pp. 113-138). Springer, Cham.

Arndt Lüder, Johanna-Lisa Pauly, Konstantin Kirchheim,

Felix Rinker, Stefan Biffl. (2018). Migration to Auto-

mationML based Tool Chains –incrementally overcom-

ingEngineering NetworkChallenges. [ONLINE] Avail-

able at: https://www.automationml.org/o.red/up-

loads/dateien/1548668540-17_Lueder_Migration-

ToolChains_Paper.pdf. [Accessed 2 January 2019].

Merunka, V. (2017). Symmetries of Modelling Concepts

and Relationships in UML -Advances and Opportuni-

ties. Lecture Notes in Business Information Processing,

298, 100-110.

Presley, A., & Liles, D. H. (1995). The use of IDEF0 for the

design and specification of methodologies. In Proceed-

ings of the 4th industrial engineering research confer-

ence.

Rosenberger, P., Gerhard, D., & Rosenberger, P. (2018).

Context-Aware System Analysis: Introduction of a Pro-

cess Model for Industrial Applications. In ICEIS (2)

(pp. 368-375).

Runeson, P., & Höst, M. (2009). Guidelines for conducting

and reporting case study research in software engineer-

ing. Empirical Software Engineering, 14(2), 131-164.

Santos, H., & Alves, C. (2017). Exploring the Ambidex-

trous Analysis of Business Processes: A Design Science

Research. In International Conference on Enterprise

Information Systems (pp. 543-566). Springer, Cham

Scheer, August-Wilhelm. (1998). ARIS: Vom Geschäfts-

prozeß zum Anwendungssystem / August-Wilhelm

Scheer (3., völlig neubearb. u. erw. Aufl. ed.). Berlin

[u.a.]: Springer.

Schleipen, M., Lüder, A., Sauer, O., Flatt, H., &

Jasperneite, J. (2015). Requirements and concept for

plug-and-work. at-Automatisierungstechnik, 63(10),

801-820.

Stark, J. (2015). Product lifecycle management. In Product

Lifecycle Management (Volume 1) (pp. 1-29).

Springer, Cham.

VDI 3682 (2005). Formalised process descriptions, Beuth

Verlag, Berlin

VDI 3695 (2010). Engineering of industrial Plants, Evalua-

tion and Optimization, Part 1. Beuth Verlag, Berlin

Vergidis, K., Tiwari, A., & Majeed, B. (2008). Business

Process Analysis and Optimization: Beyond Reengi-

Production-Aware Analysis of Multi-disciplinary Systems Engineering Processes

neering. Systems, Man, and Cybernetics, Part C: Appli-

cations and Reviews, IEEE Transactions on, 38(1), 69-

82.

Wieringa, Roel. (2014). Design science methodology for

information systems and software engineering. Berlin

[u.a.]: Springer.

Zhang, C., Chen, X., Feng, Y., & Luo, R. (2010, June).

Modeling and functional design of logistic park using

IDEF0 method. In Service Systems and Service Man-

agement (ICSSSM), 2010 7th International Conference

on (pp. 1-5). IEEE.

Schwaber, K., & Beedle, M. (2002). Agile software devel-

opment with Scrum (Vol. 1). Upper Saddle River: Pren-

tice Hall.

Zhu, L., Bass, L., & Champlin-Scharff, G. (2016). Devops

and its practices. IEEE Software, 33(3), 32-34.

ICEIS 2019 - 21st International Conference on Enterprise Information Systems