Lesson: Existing Business Processes Analysis

Introduction: Why We Analyze Before We Build

In the world of system architecture and software development, there is a dangerous temptation to jump straight into designing the solution. We often feel the urge to draw diagrams, select cloud providers, or write database schemas the moment a problem is identified. However, the most successful architects recognize that you cannot effectively design a future state if you do not fully understand the current state. Existing Business Process Analysis (EBPA) is the systematic study of how an organization currently performs its tasks, manages its data, and makes decisions to achieve its objectives.

This process is not merely about documenting how things are done today; it is about uncovering the hidden dependencies, the undocumented workarounds, and the "tribal knowledge" that keeps an organization running. Without this analysis, you risk automating inefficiency. If you take a broken, manual process and digitize it, you end up with a faster, more expensive broken process. By taking the time to map out the current landscape, you identify the root causes of friction, reveal opportunities for simplification, and ensure that your new architecture actually solves the right problems.

The Foundation of Process Analysis: Identifying Stakeholders and Scope

Before you start drawing flowcharts or interviewing users, you must establish the boundaries of your analysis. If you try to analyze the entire enterprise at once, you will quickly become overwhelmed by the sheer volume of data. Instead, focus on the specific business domain or functional area that your proposed solution will impact. This involves identifying the key players who participate in these processes and understanding their unique perspectives.

Defining the Scope

Start by creating a context diagram that defines the boundaries of your analysis. Ask yourself: What are the inputs coming into this process, and what are the outputs leaving it? If you are analyzing an order fulfillment process, the scope might start when a customer hits "Checkout" and end when the package is marked as "Delivered." Anything outside of that—such as how the website was marketed or how the warehouse inventory was originally purchased—is likely out of scope.

Identifying Stakeholders

Stakeholders are the people who own, perform, or depend on the process. To get a complete picture, you need to engage with a diverse group:

• Process Owners: These individuals are responsible for the outcome and the budget of the process. They care about efficiency, cost, and compliance.
• End Users: These are the people who perform the day-to-day tasks. They are your most valuable source of information regarding "pain points" and workarounds.
• Subject Matter Experts (SMEs): These individuals understand the technical or regulatory nuances of the process that might not be obvious to the general staff.
• Downstream Consumers: These are the departments or systems that rely on the output of the process. If you change the process, you must ensure you don't break their workflows.

Callout: The "As-Is" vs. "To-Be" Mindset The "As-Is" analysis is a diagnostic exercise. It is not about judging the quality of the work, but rather documenting reality as it exists today. The "To-Be" design is the prescription. You cannot prescribe a cure if you have not accurately diagnosed the illness. Distinguishing between these two phases is critical; if you try to design the future while analyzing the present, you will inevitably bias your data collection toward the solution you already have in mind.

Techniques for Gathering Process Data

Once you have defined your scope and identified your stakeholders, you need to gather the actual data. There is no single "best" way to do this; instead, you should use a combination of techniques to cross-reference your findings and build a holistic view.

1. Document Review

Start by looking at what already exists. Most organizations have some form of documentation, even if it is outdated. Look for standard operating procedures (SOPs), training manuals, older system requirements documents, and even internal memos. These documents provide a baseline, but treat them with skepticism. If a manual says a task takes five minutes but the employee tells you it takes an hour, the document is likely reflecting how management thinks the process works, not how it actually works.

2. Observation and Shadowing

There is no substitute for watching someone do their job. Sit with the end users while they perform their tasks. Do not just watch them interact with the software; watch what they do away from the keyboard. Do they use sticky notes to remember passwords? Do they keep a spreadsheet on their desktop to track things that the main system doesn't support? These "shadow processes" are the most important things you can uncover because they represent the gaps in the current system.

3. Structured Interviews

When conducting interviews, avoid asking broad questions like "How does this process work?" Instead, ask specific, process-oriented questions:

• "What is the first thing you do when you receive a new request?"
• "What happens if the information provided is incomplete?"
• "Which systems do you have to open to finish this single task?"
• "What is the most frustrating part of your day?"

4. Data Mining and Log Analysis

If your current processes involve digital systems, look at the data. System logs, database tables, and workflow history can provide objective evidence of how processes move. For example, if you are analyzing an approval process, look at the timestamps between the submission and the final approval. If the average time is three days, but the actual work only takes ten minutes, you have identified a significant bottleneck that is likely caused by human latency, not technical limitations.

Mapping the Process: Visualizing the Flow

After gathering your data, you need to represent it visually. A process map is a communication tool that allows everyone—from the developer to the executive—to look at the same thing and understand the flow.

Choosing the Right Notation

You don't need to be a certified expert in Business Process Model and Notation (BPMN), but you should follow a consistent set of symbols.

• Start/End Events: Circles representing the beginning and conclusion of the process.
• Activities/Tasks: Rectangles representing a specific action taken by a person or system.
• Gateways: Diamonds representing a decision point where the process flow might split or merge based on a condition (e.g., "Is the order value over $500?").
• Swimlanes: Horizontal or vertical bands that group tasks by the person or department responsible for them. This is crucial for identifying "handoffs," which are the most common points of failure in any process.

Note: Pay close attention to handoffs between departments. When a process moves from the "Sales" swimlane to the "Finance" swimlane, information is often lost, delayed, or misinterpreted. These handoffs are the primary areas where you will find opportunities for process improvement.

Analyzing the Data: Identifying Inefficiencies

With your maps complete, the real analysis begins. You are looking for patterns that signal inefficiency. Here are common categories of waste to look for:

Handoffs and Latency

Every time a document or task is passed from one person to another, there is a risk of delay. If the "Finance" team waits for a daily batch of invoices from "Sales," that is a 24-hour latency period. Can this be made real-time? Can the process be automated so the Finance team doesn't need to be involved until a specific condition is met?

Redundant Data Entry

If a user enters a customer's address in the CRM and then has to enter it again in the shipping software, you have a redundancy issue. This is not just a waste of time; it is a major source of data entry errors. Every time data is keyed in twice, the probability of a discrepancy increases.

Exception Handling

How does the process handle the 5% of cases that don't fit the normal flow? Often, architects design for the "happy path" (the ideal scenario) and ignore the exceptions. If the current process requires a manager to manually override every "non-standard" order, you have a scalability problem. Your new architecture needs to define automated logic to handle these exceptions or route them to the appropriate person with all the necessary context.

Practical Example: The Order-to-Cash Workflow

Let’s look at a concrete example. Imagine you are analyzing an "Order-to-Cash" process for a manufacturing company.

Current State (As-Is):

1. Sales rep receives an order via email.
2. Sales rep manually enters the order into the ERP system.
3. Sales rep emails a copy to the warehouse manager.
4. Warehouse manager checks physical stock levels.
5. If stock is available, they pick the items and email the invoice back to the sales rep.
6. Sales rep sends the invoice to the customer.

Analysis of Inefficiencies:

• Manual Entry: Step 2 is prone to human error.
• Communication Gap: Steps 3 and 5 rely on email, which is not an integrated system. If the warehouse manager is out, the order sits in an inbox.
• Lack of Visibility: The sales rep doesn't know if the warehouse is actually working on the order unless they get a reply.

Proposed Improvements (To-Be):

• Integrate the website directly with the ERP so orders are created automatically.
• Configure the ERP to trigger an automated notification to the warehouse dashboard.
• Allow the warehouse manager to update the order status directly in the ERP, which automatically generates the invoice for the customer.

Technical Implementation: Capturing Process Data

Sometimes you need to write small scripts to extract data from legacy systems to understand the "As-Is" flow. Let’s say you need to audit how long it takes for a ticket to move from "New" to "In Progress" in an old support system.

# Simple Python snippet to analyze ticket transition times from a CSV export
import pandas as pd

# Load the export of the support ticketing system
df = pd.read_csv('support_tickets.csv')

# Convert timestamp columns to datetime objects
df['created_at'] = pd.to_datetime(df['created_at'])
df['in_progress_at'] = pd.to_datetime(df['in_progress_at'])

# Calculate the duration of the wait time
df['wait_time'] = df['in_progress_at'] - df['created_at']

# Get the average wait time for the team
average_wait = df['wait_time'].mean()

print(f"The average time a ticket sits in 'New' status is: {average_wait}")

# Identify tickets that took longer than 24 hours
bottlenecks = df[df['wait_time'] > pd.Timedelta(hours=24)]
print(f"Number of tickets exceeding 24 hours: {len(bottlenecks)}")

This code snippet takes a raw data export and turns it into actionable insight. By identifying that tickets are sitting for too long, you can inform the stakeholders that the "New" status needs an automated escalation trigger or a better notification system.

Best Practices for Process Analysis

1. Be Objective: Don't let your personal feelings about a department or a person color your analysis. Focus on the data and the process, not the personalities.
2. Validate with Users: Once you have created your process maps, take them back to the people you interviewed. Ask, "Is this how it really happens?" You will be surprised how often they say, "Oh, I forgot to tell you about that step."
3. Focus on Value: Not every process needs to be optimized. If a process happens once a year and takes ten minutes, don't waste your budget trying to automate it. Focus your efforts on high-frequency, high-impact tasks.
4. Keep it Simple: A complex process map is a useless process map. If you need 50 pages to explain a process, the process is too complex, and your first job should be simplifying the process itself, not building software for it.
5. Document the "Why": When you find a strange step in a process, don't just ask "how" it works. Ask "why" it exists. Sometimes a seemingly redundant step is there for a regulatory or legal reason that you must preserve.

Warning: Do not automate a process that should be eliminated. If you find a step that provides no business value, no data for reporting, and no customer benefit, your first recommendation should be to remove it entirely. Automating "trash" just makes the trash move faster.

Common Pitfalls and How to Avoid Them

Pitfall 1: The "Happy Path" Bias

Architects often focus on the standard flow where everything goes right. However, most system complexity is found in the "unhappy paths"—what happens when a credit card is declined, an item is out of stock, or a customer cancels mid-process?

• Prevention: Spend as much time mapping the error handling and edge cases as you do the main workflow.

Pitfall 2: Ignoring Informal Channels

Organizations rely on Slack messages, phone calls, and hallway conversations to get things done. If your system design doesn't account for how people actually communicate, they will continue to use these informal channels, and your system will be ignored.

• Prevention: During your interviews, specifically ask, "How do you communicate with other teams when you need something outside of the system?"

Pitfall 3: Failing to Verify Data Integrity

You might see a report that says a process is efficient, but if the underlying data is being manually "adjusted" by users to make the numbers look good, your analysis will be flawed.

• Prevention: Always perform a "sanity check" by comparing system reports against real-world observations. If the system says a task takes 5 minutes, but you see it taking 30, the system data is wrong.

Comparison: Manual vs. Automated Process Elements

FAQ: Common Questions about EBPA

Q: How long should the analysis phase take? A: It depends on the complexity of the domain. For a small internal utility, a few days might suffice. For a core financial system, it could take weeks or even months. The goal is to reach a point of "diminishing returns" where you have enough information to design a safe and effective system, and further analysis provides no new insights.

Q: What if the stakeholders disagree on how the process works? A: This is a common and valuable finding. It means the process is poorly defined and likely inconsistent. Use the analysis phase to facilitate a workshop where all stakeholders agree on a single "truth" for the process. This alignment is often the most valuable outcome of the entire exercise.

Q: Do I need to document every single step? A: No. Focus on the "critical path" and the "value-add" activities. If a step is purely administrative and doesn't impact the customer or the business outcome, you can summarize it or group it into a higher-level task.

Key Takeaways

1. Diagnosis Before Prescription: Never design a solution until you have a deep, evidence-based understanding of the current business process.
2. Look for the "Shadow" Processes: The most important information is often not in the official documentation, but in the workarounds and informal methods employees use to get their jobs done.
3. Handoffs are Bottlenecks: Focus your attention on the points where work moves between people or departments; these are the most common failure points.
4. Validate with Data: Use objective system logs and data to verify the subjective feedback you receive during interviews.
5. Simplify, Then Automate: Always look for ways to remove unnecessary steps before applying technology. Do not use software to speed up a broken, inefficient process.
6. Account for the "Unhappy Path": Design your architecture to handle errors and exceptions gracefully, rather than just focusing on the ideal scenario.
7. Build Consensus: Use the analysis phase as an opportunity to align stakeholders on how the business should actually function, rather than just recording how it currently functions.

By following these principles, you move from being a "coder" or "designer" to being a true "architect." You ensure that the systems you build are not just technically sound, but are also fundamentally aligned with the reality of how the business operates. This leads to higher adoption rates, fewer post-launch bugs, and significantly higher business value. Remember, the best architecture is the one that solves the right problem in the simplest way possible.