Lesson: Collecting Current State Business Processes

Introduction: Why Understanding the "As-Is" Matters

In the world of solution architecture and business analysis, there is a common trap: jumping straight to the "To-Be" solution before fully grasping the "As-Is" reality. Collecting current state business processes is the foundational step in any project. It is the process of mapping out exactly how an organization operates today—the workflows, the manual workarounds, the data silos, and the hidden pain points that staff deal with daily. Without this baseline, you are essentially trying to build a bridge to a destination without knowing where the starting bank of the river is located.

Understanding the current state is not merely about documenting tasks; it is about uncovering the why behind existing behaviors. Often, what looks like an inefficient process on paper exists because of a specific compliance requirement, a legacy system limitation, or a cultural habit that cannot be easily changed. By systematically collecting this information, you gain the empathy and insight necessary to propose solutions that actually solve problems rather than creating new ones. This lesson will guide you through the methodologies, tools, and best practices for effectively capturing these processes.

Defining the Scope of Discovery

Before you start interviewing stakeholders or drawing diagrams, you must define the boundaries of your discovery effort. If you try to map every single process in an organization at once, you will quickly become overwhelmed and produce documentation that is too broad to be useful. Scope creep is the primary enemy of effective process collection.

Identifying Core Processes vs. Support Processes

To manage your discovery effort, categorize business activities into two main types. Core processes are those that directly generate value or touch the customer—such as order fulfillment, product manufacturing, or client onboarding. Support processes are those that keep the business running behind the scenes, such as payroll processing, IT helpdesk ticket management, or office facility maintenance.

• Core Processes: Focus on these first, as they have the highest impact on business goals and revenue.
• Support Processes: Address these only if they are identified as significant bottlenecks or cost drivers during your initial discovery phase.

Callout: The "As-Is" vs. "To-Be" Distinction The "As-Is" describes the current operational reality, including all the inefficiencies, manual data entry, and workarounds. The "To-Be" describes the future state you intend to design. You cannot successfully design the "To-Be" if you ignore the "As-Is," because you will inevitably miss critical edge cases or regulatory constraints that are currently buried in the messy, existing workflow.

Methods for Data Collection

Effective collection of current state processes requires a mix of qualitative and quantitative research. You cannot rely on a single source of truth because what management thinks happens is often different from what employees actually do.

1. Stakeholder Interviews

Interviews are your primary tool for gathering context. When conducting these, avoid asking general questions like "How does this process work?" Instead, ask specific, scenario-based questions such as "Walk me through the last time you handled a customer complaint; what was the first thing you did, and what system did you open?"

2. Job Shadowing and Observation

There is no substitute for watching someone work. When you observe a user, pay attention to the "hidden" tools—the Excel spreadsheets on their desktop, the sticky notes on their monitors, and the email threads they use to track status. These are the most important indicators of where your current technology is failing.

3. Artifact Analysis

Request access to existing documentation, including process manuals, training guides, and system logs. Additionally, look at the output of the process. If you are analyzing an invoice processing workflow, look at the final invoices. Are they consistently formatted? Do they contain errors? The quality of the output often reflects the health of the process.

Practical Example: Mapping an Order Fulfillment Process

Let’s look at a practical scenario. Imagine you are tasked with improving an order fulfillment workflow. You start by identifying the steps:

1. Order Receipt: Customer sends an email or fills out a web form.
2. Order Entry: A clerk manually types the order data into the legacy ERP system.
3. Inventory Check: The clerk checks a separate warehouse spreadsheet to see if items are in stock.
4. Confirmation: The clerk sends an email back to the customer.

By documenting this, you quickly notice that the bottleneck is the manual data entry and the disconnected inventory spreadsheet. If you hadn't observed the "As-Is," you might have proposed a new customer portal, not realizing that the real issue was the lack of integration between the ERP and the warehouse inventory database.

Capturing Metrics: Turning Observations into Data

Qualitative descriptions are useful, but metrics are what get the attention of stakeholders and budget owners. You need to quantify the current state to prove the return on investment for any future changes.

Key Metrics to Collect

• Cycle Time: The total time elapsed from the start of a process to the end.
• Touch Time: The actual time a human is actively working on a task.
• Error Rate: The percentage of instances where the process requires rework or corrections.
• Volume: The number of times the process occurs within a specific timeframe (e.g., daily, monthly).
• Cost per Execution: The labor cost associated with the time spent on the process.

Note: Always look for the "hidden" costs. If a process takes 10 minutes to complete but requires 5 minutes of verification because the system data is unreliable, that 5-minute verification is a hidden cost of low data quality.

Tools and Techniques for Documentation

Once you have collected the information, you need to represent it visually. Diagrams are the standard language for this because they allow teams to see the flow of information across departments.

Process Mapping Best Practices

• Use Standard Notation: Stick to BPMN (Business Process Model and Notation) or simple flowcharts. Do not invent your own symbols, as this makes your documentation inaccessible to others.
• Keep it Simple: If a process map takes up an entire wall, it is likely too complex. Break it down into sub-processes.
• Identify the "Swimlanes": Always use swimlanes to show which department or role is responsible for each step. This highlights hand-off points, which are usually where delays occur.

Example: Representing a Workflow in Code/Logic

While you will use visual tools for documentation, it is helpful to think in logical structures. You can express a process flow using pseudocode to ensure you haven't missed any branches.

# Logic representation of an Order Process
def process_order(order):
    if order.source == "email":
        # Manual entry required - High touch time
        data = manual_entry(order)
    else:
        # Automated entry - Low touch time
        data = parse_web_form(order)
    
    inventory_status = check_warehouse_db(data.items)
    
    if inventory_status == "in_stock":
        send_confirmation(data.customer)
    else:
        # Error handling - This is a "hidden" manual process
        trigger_manual_backorder_flow(data)

In this snippet, the if/else logic identifies where a human must intervene. When documenting the current state, highlight these branches as "manual intervention points" that are prime candidates for automation.

Common Pitfalls and How to Avoid Them

Even experienced analysts fall into traps during the discovery phase. Awareness is your best defense.

1. Mapping the "Should-Be" Instead of the "As-Is"

This is the most common error. When people describe their jobs, they often describe how they are supposed to do them according to the manual, not how they actually do them to get the work done.

• Fix: Always frame your questions around real, recent examples. Ask, "Tell me about the last order you processed," rather than "How do you process orders?"

2. Ignoring the "Grey" Work

"Grey" work refers to the tasks people do to fix broken processes that aren't officially documented. This includes sending emails to check on status, manually reconciling data, or calling a colleague to get information.

• Fix: Specifically ask, "What do you do when the system doesn't give you the information you need?"

3. Lack of Stakeholder Consensus

You might interview three people who do the same job and get three different descriptions of the process.

• Fix: Once you have a draft of the process map, hold a "walkthrough" session. Bring the stakeholders together and ask them to validate the map. This forces them to agree on what the current process actually is.

Comparison of Discovery Methods

Step-by-Step Guide to Executing Discovery

Follow this sequence to ensure you cover all bases without getting stuck in the weeds.

Step 1: Preparation

Identify the key stakeholders. Prepare a list of high-level questions. Get access to the necessary systems or physical areas. Send a brief email to the participants explaining that the goal is to improve their workflow, not to evaluate their personal performance.

Step 2: Initial Information Gathering

Conduct a kickoff meeting to understand the high-level scope. Ask for any existing documentation. Identify the "happy path"—the standard way the process is supposed to work.

Step 3: Deep Dive Sessions

Schedule individual interviews and observation sessions. Focus on the variations and exceptions. Ask, "What is the most frustrating part of this task?" and "What do you do if this step fails?"

Step 4: Drafting the Process Map

Create the initial diagrams. Use swimlanes to represent roles. Use distinct colors to highlight manual steps versus automated steps.

Step 5: Validation

Present the draft to the stakeholders. Ask them to point out inaccuracies. Use this session to build consensus on the current state.

Step 6: Finalizing the Metrics

Map the qualitative findings to the quantitative metrics you collected. For example, if the interview revealed that "checking the spreadsheet" takes 15 minutes, ensure this is reflected in your cycle time calculation.

Callout: The Importance of Empathy When documenting current state processes, you are essentially documenting the frustrations of the staff. Approach this with empathy. If you approach users as if you are "auditing" them, they will hide their workarounds. If you approach them as a partner trying to remove obstacles, they will open up about everything that is broken.

Best Practices for Long-Term Success

To ensure your discovery efforts remain useful throughout the project life cycle, adhere to these standards:

• Version Control: Processes change. Ensure your documentation is dated and versioned. If a process changes mid-project, update your documentation immediately.
• Centralized Repository: Store your process maps in a location accessible to the entire project team. Do not keep them on your local hard drive.
• Clear Definitions: Define your terminology. If you use the term "Order," ensure everyone knows if that means a "Draft Order," a "Confirmed Order," or a "Shipped Order."
• Focus on the "Hand-offs": The most dangerous parts of any process are the hand-offs between systems or departments. Pay extra attention to these.

FAQ: Common Questions

Q: How much detail is too much? A: If you find yourself documenting the exact mouse clicks a user makes, you are likely too deep. Aim for the "task" level (e.g., "Enter customer data into ERP") rather than the "keystroke" level.

Q: What if the stakeholders refuse to agree on the process? A: This is actually a valuable finding. It means there is no standard process. Document the variations and include them in your final report as a "lack of standardization" risk.

Q: Should I document the "happy path" or the "exceptions"? A: Both. The happy path is the skeleton, but the exceptions are where the most time and money are lost. A process that works 90% of the time but fails in a way that requires manual intervention 10% of the time is often the most expensive to run.

Key Takeaways

1. Start with the "As-Is": Never attempt to design a solution without first mapping the current reality, including all the messy, manual workarounds.
2. Combine Methods: Use a mix of interviews, observation, and artifact analysis to get a complete picture. Do not rely on what people say they do; observe what they actually do.
3. Quantify the Pain: Use metrics like cycle time, touch time, and error rates to turn qualitative frustrations into objective business cases.
4. Validate with Stakeholders: Always bring your process maps back to the people who do the work. They are the only ones who can confirm if your map is accurate.
5. Focus on Hand-offs and Exceptions: The biggest opportunities for improvement usually lie in the hand-offs between departments and the way exceptions are handled.
6. Maintain Neutrality: Your role is to understand the process, not to judge it. Approach the discovery phase with empathy to ensure you get honest feedback from the staff.
7. Keep it Scalable: Use standard notation like BPMN and keep your diagrams modular. This makes your work easier to maintain and explain to others as the project evolves.

By following these guidelines, you will move beyond simple note-taking and become a true partner in the business improvement process. The effort you put into understanding the current state will pay dividends when you reach the design phase, as your proposed solutions will be grounded in the reality of the organization's needs and limitations.