{"id":72850,"date":"2026-08-28T14:53:10","date_gmt":"2026-08-28T17:53:10","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=72850"},"modified":"2026-08-28T14:53:10","modified_gmt":"2026-08-28T17:53:10","slug":"process-management-bpm-stages-application-engineering","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/en-us\/content\/technical-articles\/process-management-bpm-stages-application-engineering\/","title":{"rendered":"Process Management and BPM: What It Is, Stages, and Application in Engineering"},"content":{"rendered":"\n

Process management<\/strong> 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.<\/p>\n\n\n

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.<\/p>\n\n\n\n\n

What is process management?<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

\n

From process management to workflow implementation.<\/strong> A3A structures technical processes, responsibilities, approval rules, SLAs, evidence, and audit trails, with implementation on existing platforms or in ENGiOS.<\/p>\n\n\n\n

Learn about the Process and Workflow Management solution<\/a><\/p>\n<\/div>\n\n\n\n\n

Why do processes need to be managed?<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

The expected result is not a static process, but a work system that can be monitored and continuously improved.<\/p>\n\n\n\n\n

Process, project, procedure, and workflow: what is the difference?<\/h2>\n\n\n\n

These concepts are related, but they are not equivalent.<\/p>\n\n\n\n

Process<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

Examples: technical document approval, RFI handling, change management, contract measurement, and nonconformity control.<\/p>\n\n\n\n

Project<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Procedure<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

Workflow<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n\n

Functional management and process-based management<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Process-based management<\/strong> 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.<\/p>\n\n\n\n

An engineering change process, for example, may involve:<\/p>\n\n\n\n

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

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

    Types of organizational processes<\/h2>\n\n\n\n

    A simple classification helps organize the process portfolio.<\/p>\n\n\n\n

    Core or primary processes<\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    Support processes<\/h3>\n\n\n\n

    They provide resources and capabilities to the primary processes. Examples include document management, information technology, procurement, human resources, infrastructure, and knowledge management.<\/p>\n\n\n\n

    Management and governance processes<\/h3>\n\n\n\n

    They direct, control, and evaluate the organization. They include strategic planning, portfolio management, risks, performance, audits, management review, prioritization, and decision-making.<\/p>\n\n\n\n

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

    Which elements define a process?<\/h2>\n\n\n\n

    A process is not sufficiently defined simply because a flowchart exists. Its description should combine a graphical view, rules, and operational information.<\/p>\n\n\n\n

    Every process should have an objective<\/strong>, a start event<\/strong>, and a known set of inputs<\/strong>. From these, activities transform information, requirements, or resources into verifiable outputs.<\/p>\n\n\n\n

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

    Technical, legal, contractual, and organizational requirements<\/strong> determine the conditions that must be met. Controls<\/strong> reduce risks and ensure compliance, while resources include people, competencies, tools, and infrastructure.<\/p>\n\n\n\n

    Finally, indicators<\/strong> show performance and results; records<\/strong> preserve evidence of execution, decisions, and approvals; and interfaces<\/strong> explain how the process connects to other flows, systems, and organizations.<\/p>\n\n\n\n\n

    Stages of process management<\/h2>\n\n\n\n

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

    1. Understand the context and objectives<\/h3>\n\n\n\n

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

    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.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    2. Identify and prioritize processes<\/h3>\n\n\n\n

    It is not efficient to map the entire organization at the same time. Processes should be inventoried and prioritized according to impact and need.<\/p>\n\n\n\n

    Possible criteria:<\/p>\n\n\n\n