Many organizations face a problem that is as common as it is difficult to solve: processes are designed, documented… and then forgotten. They remain recorded in forms, diagrams, or manuals that never translate into action or meaningful change.
Meanwhile, internal dynamics continue to be marked by silent fragmentation. Each department operates according to its own logic, with its own tools and priorities, and has little awareness of what happens before or after its activities within the value chain.
This disconnect, although it does not appear on any organizational chart, is very real. And its consequences are noticeable: duplicated tasks, inconsistent decisions, unnecessary delays, loss of traceability, and, above all, a poor experience for those on the other end—whether an external or internal customer waiting for a timely and coordinated response.
In this article, I want to share how a business analyst who works from a process-oriented perspective, drawing on the knowledge areas of the BABOK® Guide from the International Institute of Business Analysis (IIBA), can act as an important catalyst, ensuring that formalization does not remain confined to a static document but instead becomes effective commitment, continuous improvement, and sustainable organizational transformation.
From the perspective of business analysis, this disconnect cannot go unnoticed. The challenge is not simply identifying needs or translating requirements, but also helping the organization recognize itself as an interdependent system. In this context, a process-based approach becomes a tool that is not only useful but also transformative.
Looking at an organization through its processes allows the analyst to identify the actual paths through which value flows, as well as the bottlenecks, deviations, and blind spots that slow down or distort that flow. A well-understood process reveals who is involved, what each party contributes, where key decisions are made, and which elements intersect across different areas: data, documents, approvals, validations, technical or human dependencies. It is, in fact, a map that does not follow hierarchical lines and, above all, encourages collaboration rather than competition.
In this work, the business analyst does not act as an isolated entity, but as a facilitator of conversations between departments—conversations that often have never even taken place. These dialogues go beyond organizational boundaries and allow different professionals to finally see a shared reality.
After all, when several departments believe they are solving the same problem but each follows a different logic, the result is usually a sum of misaligned efforts. The business analyst does not seek to bring departments together, but to align their purposes.
However, one point needs to be clarified. When people talk about process management, they often picture someone “drawing workflows” with arrows and colorful boxes. And I must admit that this bothers me deeply. Not because I fail to recognize the value of graphically representing how a process works—in fact, this tool has its merits—but because reducing this discipline to that alone means failing to understand it.
The true value of process modeling does not lie in the diagram itself, but in the dialogue that precedes it, the decisions it requires, the inconsistencies it brings to light, and the agreements it makes possible.
The diagram is a tool, not an end in itself. It helps the organization clearly see what usually happens implicitly or in a fragmented way. It provides transparency, facilitates analysis, and makes it possible to identify redundancies and design improvements.
However, a process is not transformed by a beautiful diagram; it is transformed when what is represented in that diagram becomes coordinated action, shared commitment, clear operational criteria, and monitoring mechanisms that ensure its continuous development.
A flowchart is only useful when it sparks dialogue, decisions, and action. If nothing changes, it is merely a set of boxes and arrows representing an unresolved problem.
And here another major obstacle emerges: after a process has been documented, validated, and “signed off,” it often ends up forgotten in a drawer. Reality moves on, and what was agreed upon is never put into practice. Urgent matters once again take precedence over important ones, and old habits quickly return. This is when it becomes clear that the greatest challenge is not representing how things should be done, but ensuring that they are actually done that way.
In this context, the business analyst plays a fundamental role, not as a process auditor or enforcer, but as a facilitator of change who is responsible for ensuring consistency between what is designed and what is executed.
However, no matter how well this work is structured, it has a clear limitation: without the explicit support of senior management and a culture that understands and values process management, the analyst lacks the resources needed to act.
After all, driving cross-functional change without legitimacy and support from senior leadership is like rowing against the current, especially in environments where any proposed change is perceived as a threat to the status quo, control, or spheres of power that some people are unwilling to relinquish.
This resistance is not necessarily conscious or ill-intentioned. Often, it is simply fear: fear of losing autonomy, being exposed, or seeing what has always been familiar stop working.
Therefore, in addition to technical knowledge, this work requires political sensitivity and influencing skills. The analyst must be able to build trust, demonstrate shared benefits, and present change not as a threat, but as an opportunity. To achieve this, they need clear, consistent, and ongoing support from the organization’s highest levels.
How Does an Analyst Use Processes as a Reference Point?
Imagine a fairly common situation: a customer service process that, in reality, has never been defined as a process. What exists instead are scattered tasks performed by different departments, without a shared perspective or traceability. Meanwhile, customers experience delays, receive contradictory responses, or, in some cases, receive no response at all.
In this scenario, the business analyst, drawing on knowledge areas such as those outlined in the BABOK® Guide from the International Institute of Business Analysis (IIBA) and applying its core activities with the intention of driving transformation, can foster meaningful change:
– Understand the context and align the need for change (Business Analysis Planning and Monitoring): The analyst identifies that what is perceived as a “lack of coordination” is actually the absence of a structured process. They assess current capabilities, listen to complaints from the areas involved, and clearly define the problem of functional disconnect. By carrying out activities such as “Analyze Current State” and “Define Future State,” the analyst helps build a shared vision: transforming isolated tasks into a structured customer service process.
– Identify and engage relevant stakeholders (Stakeholder Analysis): Before redesigning any activity, the analyst maps everyone currently involved, even if those individuals are not aware of their involvement: sales teams, operations, quality, IT, legal, and others. They identify resistance, allies, and points of friction. Through activities such as “Identify Stakeholders” and “Manage Stakeholder Collaboration,” the analyst begins to build a network of commitment that will make change possible.
– Understand operational reality through processes (Elicitation and Collaboration): The analyst does not rely on assumptions. They bring stakeholders together, observe, listen, and ask difficult questions. They discover how current tasks are connected—or not—while identifying exceptions, bottlenecks, and redundancies. Activities such as “Prepare for Elicitation,” “Conduct Elicitation,” and “Confirm Elicitation Results” help bring shape to the actual process experienced by the organization, even if no one has formally defined it.
– Represent processes in a way that encourages decision-making (Requirements Analysis and Design Definition): With all this information, the analyst models the process in a clear, validated, and understandable way for everyone involved. They do more than draw diagrams: they encourage operational decisions, highlight inconsistencies, and align expectations. Activities such as “Specify and Model Requirements” and “Verify and Validate Requirements” are essential to turning tacit knowledge into explicit knowledge and informal practices into something that can be managed.
– Turn the redesign into governance mechanisms (Requirements Life Cycle Management): At this stage, the designed process stops being an intention and becomes a living structure. The organization defines who will be responsible for it, which indicators will be used to measure its performance, how it will be reviewed, and what should be done when something does not work. Activities such as “Trace Requirements,” “Maintain Requirements,” and “Assess Requirements Changes” help ensure that the process does not disappear after implementation.
– Measure and sustain the proposed solution (Solution Evaluation): The process goes into operation. The analyst continues to monitor its execution, measure results, listen to the areas involved, identify deviations, and propose adjustments. The activity “Measure Solution Performance” helps close the cycle through learning and continuous improvement, keeping the process aligned with the organization’s strategy.
This is the true contribution of a business analyst who works with processes: building bridges between what the organization wants to become and what it is today. It means identifying opportunities, designing viable solutions, and ensuring they do not remain mere intentions.
Their role is deeply strategic because it lies precisely at the intersection of needs, capabilities, objectives, and decisions. And it is through processes, as natural instruments of organizational operations, that this alignment takes shape.
It is not about producing documentation, but about generating momentum, impact, and continuous transformation.
In short, the internal disconnect present in many organizations is not a secondary issue: it represents one of the main barriers to efficiency, innovation, and continuous improvement. But it is not irreversible.
Through a systemic perspective, rigorous business analysis practices, and well-structured process management, organizations can begin building the bridges they so urgently need. After all, no meaningful improvement happens in isolated compartments: either everything is connected, or every part remains stagnant.
And this is precisely where a business analyst who works with processes makes a difference: turning analysis into momentum, planning into commitment, and intentions into action.
After all, a process only comes to life when it stops being a document and becomes a shared practice. That is what true transformation looks like: transformation that goes beyond the page.
Author: Raúl Fernández Cuenca, Interact Latam Partner.
