Understand process management and BPM, how to organize end-to-end processes, define responsibilities, measure performance, and improve workflows in engineering companies.

Check it out!

Process management is the discipline used to identify, understand, organize, control, and improve how interdependent activities transform inputs into results. Its purpose is not to produce flowcharts for compliance’s sake, but to ensure that work creates value, meets requirements, maintains clear responsibilities, and can be measured and improved.

In engineering companies, this approach connects technical, administrative, contractual, and document-related activities that typically cross different areas. Design requests, document reviews, scope changes, RFIs, inspections, measurements, approvals, and acceptance criteria are examples of processes that depend on well-defined interfaces to work effectively.

What is process management?

Process management is the systematic management of processes and their interactions. It establishes which results must be achieved, which activities are required, who participates, which rules must be followed, which resources are used, and how performance will be monitored.

The process approach adopted by ABNT NBR ISO 9001 views the organization as a system of interrelated processes. Each process receives inputs, performs activities, produces outputs, and connects to upstream and downstream processes. Controls and measurement points vary according to context, requirements, and the risks involved.

A well-managed process needs to make clear which result is intended, what starts and ends the flow, and which inputs are required to produce the expected outputs. It must also explicitly define who performs, verifies, approves, and is accountable for the result.

In addition, the design must record decision rules and criteria, the systems and documents used, the risks that may compromise execution, and how schedule, quality, capacity, and efficiency will be measured. Exceptions, changes, and improvement opportunities also need defined treatment.

From process management to workflow implementation. A3A structures technical processes, responsibilities, approval rules, SLAs, evidence, and audit trails, with implementation on existing platforms or in ENGiOS.

Learn about the Process and Workflow Management solution

Why do processes need to be managed?

Many organizations have processes but do not manage them. Work happens through individual experience, messages, meetings, parallel spreadsheets, and informal agreements. While volume is low, this model may seem sufficient. As the number of projects, suppliers, documents, and decisions increases, delays, rework, and loss of traceability emerge.

Process management seeks to reduce this dependence on tacit knowledge. It makes work understandable and repeatable without eliminating technical analysis or professional autonomy.

In practice, process management seeks to ensure consistent compliance with requirements and reduce variations that generate rework. By making responsibilities and approval authorities explicit, it improves coordination among areas, suppliers, and projects that depend on the same flow.

Another objective is to produce reliable information for decision-making, preserve records and evidence, and handle risks and exceptions in a structured manner. This gives the organization greater predictability in schedule and capacity and enables it to identify more clearly where to simplify, standardize, or automate.

The expected result is not a static process, but a work system that can be monitored and continuously improved.

Process, project, procedure, and workflow: what is the difference?

These concepts are related, but they are not equivalent.

Process

It is a recurring or repeatable set of related activities that transforms inputs into outputs. A process can be performed many times, even though each occurrence may have particular characteristics.

Examples: technical document approval, RFI handling, change management, contract measurement, and nonconformity control.

Project

It is a temporary endeavor undertaken to achieve defined objectives. It has a beginning and an end, its own organization, deliverables, and constraints. ABNT NBR ISO 21502 characterizes a project by its temporary nature.

A project uses organizational processes, but it is not the same as those processes. Multiple projects may use the same document approval or change management process.

Procedure

It is the specified way to perform an activity or process. It may define instructions, criteria, sequence, documents, and responsibilities. Not every process needs an extremely detailed procedure, but critical processes generally require documented guidance proportional to risk.

Workflow

It is the executable or operational representation of the work flow. It defines steps, transitions, responsible parties, deadlines, conditions, notifications, and records. It may exist on paper or in a spreadsheet, but it is usually associated with digital implementation on a platform.

Functional management and process-based management

In functional management, work is organized primarily by departments: Engineering, Procurement, Contracts, Finance, Operations, and Quality. This structure is necessary to concentrate competencies, but it can create silos.

Process-based management looks at the end-to-end flow. Instead of analyzing only the performance of each department, it follows how a demand crosses different functions until it produces the expected result.

An engineering change process, for example, may involve:

  1. identification of the need by Operations or Engineering;
  2. registration and classification of the request;
  3. technical analysis and risk assessment;
  4. estimate of schedule, cost, and contract impacts;
  5. approval according to authority level;
  6. update of documents and baselines;
  7. implementation;
  8. verification and closure.

No single area controls this entire result. For this reason, process-based management requires integration between functional responsibilities and a cross-functional view.

Types of organizational processes

A simple classification helps organize the process portfolio.

Core or primary processes

They directly deliver products, services, or results to the client or user. In an engineering company, they may include design development, supervision, commissioning, inspections, studies, and issuance of technical opinions.

Support processes

They provide resources and capabilities to the primary processes. Examples include document management, information technology, procurement, human resources, infrastructure, and knowledge management.

Management and governance processes

They direct, control, and evaluate the organization. They include strategic planning, portfolio management, risks, performance, audits, management review, prioritization, and decision-making.

The classification should support management. There is no need for excessive debate about conceptual boundaries when the objective, owner, and interfaces are already clear.

Which elements define a process?

A process is not sufficiently defined simply because a flowchart exists. Its description should combine a graphical view, rules, and operational information.

Every process should have an objective, a start event, and a known set of inputs. From these, activities transform information, requirements, or resources into verifiable outputs.

The design also needs to represent the decisions that change the path of the flow and the roles responsible for performing, verifying, approving, supporting, and being accountable. Outputs should indicate what was produced and who the affected customers or stakeholders are.

Technical, legal, contractual, and organizational requirements determine the conditions that must be met. Controls reduce risks and ensure compliance, while resources include people, competencies, tools, and infrastructure.

Finally, indicators show performance and results; records preserve evidence of execution, decisions, and approvals; and interfaces explain how the process connects to other flows, systems, and organizations.

Stages of process management

Process management is cyclical. The initial design needs to be validated, implemented, monitored, and reviewed. A practical sequence can be organized into nine stages.

1. Understand the context and objectives

Before mapping activities, it is necessary to understand the problem. The work should start from strategy, stakeholder needs, applicable requirements, and intended results.

The diagnosis needs to identify which problem will be solved, which result must improve, and which requirements cannot be compromised. It must also define the affected areas, projects, and suppliers, as well as the risks and constraints that condition the change.

It is equally important to assess the organization’s capacity to absorb change. A technically correct process may fail when it requires too many simultaneous changes, unavailable resources, or a level of maturity that has not yet been developed.

2. Identify and prioritize processes

It is not efficient to map the entire organization at the same time. Processes should be inventoried and prioritized according to impact and need.

Possible criteria:

  • criticality to customers and operations;
  • exposure to technical or contractual risks;
  • volume of occurrences;
  • number of areas involved;
  • frequency of delays and rework;
  • financial impact;
  • traceability requirements;
  • potential for standardization or automation.

3. Map the current state — AS-IS

AS-IS mapping records how work actually happens. It should not merely reproduce the formal procedure. Interviews, document analysis, observation, system data, and case samples help identify the flow that is actually practiced.

The current-state map should reveal:

  • activities and decisions;
  • actual responsible parties;
  • documents and systems used;
  • processing and waiting times;
  • parallel controls;
  • returns and rework;
  • recurring exceptions;
  • points without clear responsibility;
  • differences between areas or units.

4. Analyze problems, risks, and causes

After understanding the current state, symptoms can be separated from causes. A delay may result from insufficient capacity, incomplete information, inappropriate authority levels, excessive approvals, or lack of criteria.

The analysis should examine where bottlenecks and queues form, which activities do not add value, and where there are duplications or excessive transfers between areas. Communication failures, responsibility conflicts, and disconnected systems often explain a significant share of delays.

It is also necessary to examine existing risks and controls, the availability of data and evidence, and the causes of nonconformities and rework. The objective is to understand why the process fails before proposing a solution.

ABNT NBR ISO 31000 reinforces that risks need to be integrated into activities and decision-making. Therefore, redesign should not seek speed alone; it must maintain controls proportional to the consequences of failure.

5. Design the future state — TO-BE

The TO-BE describes how the process should operate. The future design should resolve priority causes and preserve technical, legal, contractual, and safety requirements.

The redesign may eliminate redundant steps, combine compatible verifications, and adjust authority levels that concentrate decisions unnecessarily. Objective entry and exit criteria help prevent incomplete requests from moving forward and repeatedly returning.

It may also be necessary to standardize forms and data, bring validations forward, reduce transfers between areas, and create dedicated paths for exceptions. Automation comes later, supporting notifications, repetitive tasks, integrations, indicators, and alerts.

6. Define roles, rules, and documentation

The future process needs to be operationally executable. This requires defining who performs, who decides, which information is mandatory, and how evidence will be preserved.

The main outputs of this stage may include:

  • process diagram;
  • responsibility matrix;
  • business rules;
  • approval levels;
  • procedures and instructions;
  • forms and templates;
  • acceptance criteria;
  • data and document catalog;
  • indicators and targets;
  • exception and escalation rules.

7. Plan and perform implementation

Approval of the design does not mean that the process has been implemented. Systems, documents, people, data, and support structures need to be prepared.

Implementation may begin with a pilot project used to validate the flow, roles, forms, and indicators under real conditions. In parallel, tools are configured and the data that need to be migrated or cleansed are prepared.

After training and communication, it is advisable to maintain a period of assisted operation. During this phase, the team monitors adherence, corrects problems identified in daily use, and only then expands the process to other areas, contracts, or units.

8. Monitor performance and compliance

Indicators should demonstrate whether the process delivers its result and whether controls work. Measuring only the number of activities may encourage volume without value.

Monitoring should combine results, efficiency, quality, risk, and capacity.

9. Continuously improve

Process management does not end after implementation. Changes in requirements, technology, contracts, structure, and volume can make the model inadequate.

The PDCA cycle provides a simple structure:

  • plan: establish objectives, methods, resources, and controls;
  • do: operate the process as planned;
  • check: measure results, analyze deviations, and assess risks;
  • act: correct causes, adapt controls, and improve performance.

How to represent a process?

The representation should be appropriate to the audience and objective. An executive map may show only major stages and interfaces. An operational flow needs to detail activities, decisions, and responsibilities.

Common formats include:

  • SIPOC, to visualize suppliers, inputs, process, outputs, and customers;
  • functional flowchart or swimlane, to show activities by area or role;
  • BPMN, to model events, activities, decisions, messages, and participants;
  • value chain map, to represent macroprocesses;
  • textual procedure, for rules and instructions that do not fit in the diagram;
  • RACI matrix, to clarify responsibilities and accountability.

The notation does not replace understanding. Sophisticated diagrams that are incompatible with actual practice do not improve the process.

Roles and responsibilities in process management

Process governance should avoid the idea that everyone is responsible for everything.

Sponsor

Authorizes the initiative, removes obstacles, and supports changes that cross organizational areas.

Process owner

Is accountable for end-to-end performance, interfaces, and process evolution. The process owner does not necessarily perform all activities.

Functional managers

Ensure resources, competencies, and adherence in the areas under their responsibility.

Performers, verifiers, and approvers

Perform activities and make decisions according to defined criteria. Segregation between preparation, verification, and approval may be necessary in critical processes.

Process analyst or process team

Facilitates diagnosis, mapping, analysis, redesign, documentation, and implementation.

Information technology and system administrators

Configure platforms, integrations, permissions, automations, data, and audit trails.

Responsibilities need to be explicit. The RACI Matrix complements the process design by distinguishing who performs, is accountable, is consulted, and must be informed for each activity or decision.

Learn how to apply the RACI Matrix

Process management indicators

A balanced set of indicators may include:

  • cycle time: period between start and completion;
  • waiting time: portion of time in which the demand remains idle;
  • deadline or SLA compliance: occurrences completed on time;
  • first-pass approval rate: items accepted without being returned;
  • rework rate: occurrences returned or redone;
  • backlog: pending volume;
  • age of pending items: accumulated time of open items;
  • capacity and productivity: volume handled per period and resource;
  • exception rate: cases that leave the standard flow;
  • nonconformities: failures against requirements or controls;
  • internal or external customer satisfaction: perception of results and service;
  • risk exposure: open risks and effectiveness of controls.

The target should consider criticality, resources, and variability. Reducing approval time without assessing quality can increase errors and subsequent costs.

Process automation and digitalization

Automation is a possible stage of process management, not its mandatory starting point. Digitalizing a poorly defined flow merely accelerates problems and makes exceptions harder to manage.

Before technology implementation, it is advisable to define:

  • start event and entry criteria;
  • mandatory data;
  • roles and permissions;
  • steps and transitions;
  • conditional rules;
  • deadlines and escalations;
  • documents and evidence;
  • integrations;
  • audit trail;
  • indicators;
  • exception handling.

Automation can generate tasks, validate fields, control deadlines, issue alerts, route approvals, and consolidate indicators. Complex technical decisions, however, continue to require professional judgment and appropriate accountability.

When the formal process exists but delays, rework, and information loss continue to recur, the problem needs to be diagnosed before automation. The analysis should locate causes, interfaces, bottlenecks, authority levels, indicators, and redesign opportunities before any technology decision.

Learn about Engineering Process Diagnosis and Optimization

Process management in engineering companies

Engineering companies combine intellectual work, standards requirements, contracts, controlled documentation, and multidisciplinary interfaces. Processes need to reflect this reality.

On the commercial and mobilization front, process management may cover opportunity qualification, requirements analysis, proposal preparation, and initial project planning. The objective is to prevent critical information from being lost in the transition between Commercial, Engineering, and Contracts.

During execution, the processes of issuing, verifying, and approving documents, revision control, requirements and interface management, handling RFIs, risks, changes, inspections, tests, and nonconformities become particularly important.

At the delivery stage, the flows of measurement, technical acceptance, closure, supplier management, commissioning, handover to operations, and lessons learned come into play. These processes are interconnected and therefore should not be structured as isolated routines.

The design needs to consider that different contracts may require specific flows, authority levels, and documents. Standardization should create a common foundation with adaptation rules rather than impose a single rigid flow on every project.

Practical example: approval of a technical document

Consider the process of issuing and approving a descriptive technical specification.

Inputs

  • contractual scope;
  • client requirements;
  • applicable standards;
  • survey data;
  • interfaces with other disciplines;
  • template and document coding.

Basic flow

  1. the responsible professional prepares the first revision;
  2. a designated professional performs the technical verification;
  3. inconsistencies are returned for correction;
  4. the internally approved document is submitted to the client or supervision team;
  5. comments are recorded and classified;
  6. the document is revised without losing its history;
  7. final approval is recorded;
  8. the current revision is released for use.

Controls

  • segregation between preparation and verification;
  • unambiguous revision identification;
  • requirements checklist;
  • record of comments and responses;
  • approval according to authority level;
  • blocking of obsolete versions;
  • audit trail.

Indicators

  • average preparation and approval time;
  • percentage approved on first submission;
  • number of review cycles;
  • documents overdue against SLA;
  • most frequent causes of comments;
  • improper use of obsolete revisions.

This example shows that the process is not merely the sequence of tasks. It also includes requirements, responsibilities, documents, controls, risks, and indicators.

Risks and controls in processes

Improvement should not remove controls without assessing their purpose. Some controls appear bureaucratic because they were poorly implemented, but they may exist to prevent significant consequences.

An independent review, for example, reduces the risk of technical error; defining financial authority levels prevents unauthorized commitments. Version control prevents the use of obsolete information, while recording acceptance reduces contractual disputes.

Similarly, segregation of duties helps control conflicts of interest, and requirements validation reduces the probability that an incomplete deliverable will advance to subsequent stages.

The redesign should ask whether the control is necessary, whether it is positioned at the right point, and whether there is a more efficient way to achieve the same objective.

Common mistakes in process management

Mapping the ideal process and ignoring actual practice

The AS-IS needs to portray the real work, including shortcuts, spreadsheets, and exceptions.

Starting with the tool

Choosing software before understanding the process, data, and responsibilities often generates excessive customization and low adoption.

Confusing documentation with management

Procedures are important, but they do not replace owners, indicators, management review, and improvement.

Creating excessive approvals

Each approval should have a purpose, criterion, and authority. Approvals without real analysis increase cycle time without reducing risks.

Ignoring exceptions

Real processes include urgent cases, rejections, cancellations, and incomplete cases. The design should define how to handle them.

Measuring volume only

The number of completed items does not demonstrate quality, schedule, value, or risk.

Failing to designate a process owner

Without end-to-end accountability, each area optimizes its own stage and problems remain at the interfaces.

Treating implementation as isolated training

Change requires leadership support, configured systems, resources, monitoring, and correction of problems after operations begin.

Process management maturity

Maturity can evolve gradually:

  1. informal: execution depends on individuals and local agreements;
  2. documented: basic flows and procedures are defined;
  3. standardized: common responsibilities, criteria, and data;
  4. controlled: indicators, risks, and compliance are monitored;
  5. integrated: processes connected to strategy, projects, contracts, and systems;
  6. optimized: continuous improvement, automation, and data-driven decisions.

The organization does not need to bring every process to the same level. Critical, regulated, or high-impact processes require greater control than simple, low-risk routines.

Relationship between process management, PMO, and governance

Process management organizes how recurring work is performed. The PMO structures or supports capabilities for managing projects, programs, and portfolios. Governance defines direction, authority, oversight, and accountability.

These layers complement one another. Governance establishes policies, authority levels, and decision criteria; the PMO converts part of these guidelines into methods, services, and controls applied to projects; and process management organizes the flows used by teams in daily work.

Systems act as the infrastructure for recording and execution, connecting tasks, documents, decisions, and indicators. When one of these layers is treated in isolation, gaps emerge between direction, method, and operation.

A PMO depends on clear processes for planning, risks, changes, reporting, and closure. Likewise, technical processes need governance to resolve conflicts of priority, authority, and responsibility.

Conclusion

Process management is an organizational capability for transforming scattered activities into understandable, controlled, and improvable flows. Its value lies in connecting people, requirements, decisions, documents, risks, and systems to produce consistent results.

In engineering companies, the greatest benefit arises when technical, administrative, and contractual processes are managed end to end. The work begins by understanding the context and the current state, advances to future-state design, and only then reaches standardization, implementation, and automation.

Technology can accelerate the process and provide traceability, but it does not replace clear objectives, responsibilities, technical criteria, and continuous management.

Technical references

[1] ABNT. ABNT NBR ISO 9001:2015 — Quality management systems — Requirements. Corresponding to ISO 9001:2015. Available at: ISO 9001:2015.

[2] ABNT. ABNT NBR ISO 31000:2018 — Risk management — Guidelines. Corresponding to ISO 31000:2018. Available at: ISO 31000:2018.

[3] ABNT. ABNT NBR ISO 21502:2021 — Project, programme and portfolio management — Guidance on project management. Corresponding to ISO 21502:2020. Available at: ISO 21502:2020.

Frequently asked questions
What is process management?

It is the systematic management of processes and their interactions to ensure results, responsibilities, controls, indicators, and continuous improvement.

What is the difference between process management and project management?

Process management addresses recurring or repeatable organizational flows. Project management addresses temporary endeavors created to achieve defined objectives. Projects use organizational processes, but they are not the same as those processes.

What does process-based management mean?

It is an approach that follows work end to end across departments and suppliers instead of analyzing only the isolated performance of each functional area.

What are AS-IS and TO-BE?

AS-IS represents how the process currently works. TO-BE represents how it should work after redesign, including improvements, responsibilities, rules, controls, and indicators.

Does every process need to be automated?

No. Automation should be applied when it adds value, reduces repetitive effort, or improves control and traceability. Poorly defined processes should be understood and redesigned before they are digitalized.

Which indicators can be used in process management?

Cycle time, waiting time, SLA compliance, first-pass approval, rework, backlog, age of pending items, capacity, exceptions, nonconformities, satisfaction, and risk exposure.

Who should be responsible for a process?

A process owner should be designated as accountable for end-to-end performance. Functional managers, performers, verifiers, approvers, process specialists, and IT have complementary responsibilities.

Are BPM and BPMN the same thing?

No. BPM is the discipline of business process management. BPMN is a notation used to represent processes graphically. The notation can support BPM, but it does not replace analysis, governance, implementation, and improvement.

Complementary technical materials

Related solutions

Related services

Core content on the topic

Related technical content