Understanding Business Processes: How Companies Actually Run

Every company runs on processes — repeatable sequences of steps that turn inputs into outcomes. Before an FDE can improve, automate, or replace any of them, they need to read a business process the way a developer reads code: inputs, steps, decisions, outputs, and failure paths.

Table of Contents

• What Is a Business Process?
• The Anatomy of a Process
• Core, Support, and Management Processes
• Tracing a Process End to End
• Processes vs. Projects vs. Tasks
• Why FDEs Must Think in Processes

What Is a Business Process?

A business process is a repeatable sequence of steps, performed by people or systems, that turns inputs into a defined outcome. "Onboard a new employee," "fulfill an order," "close the monthly books" — each is a process with a trigger, a series of steps, and an end state.

The key word is repeatable. A process is something the organization does again and again, which is exactly why it matters to you: repeatable work is the work worth understanding, improving, and automating.

Why it matters: customers rarely ask for "a process fix." They ask for software. But the software only creates value if it changes how a process runs. If you can't describe the process, you can't tell whether your build actually helps.

The Anatomy of a Process

Every business process, from a two-step approval to a month-long audit, is built from the same parts:

Read a process like a function: it takes inputs, runs steps with branches, and returns outputs. The handoffs and decisions are where most real-world problems live — that's where work gets dropped, delayed, or done twice.

Core, Support, and Management Processes

Not all processes are equal. Companies sort them into three layers:

1. Core processes — create direct value for the customer and revenue for the company (sales, order fulfillment, customer support). These are the reason the company exists.
2. Support processes — keep the core running (hiring, IT helpdesk, payroll, procurement). They don't earn revenue, but the core stalls without them.
3. Management processes — oversee the rest (budgeting, performance reviews, compliance audits).

Note: when a customer says "we need to be faster," they almost always mean a core process. When they say "we're drowning in admin," they mean a support process. Knowing which layer you're in tells you what success looks like — revenue impact for core, hours saved for support.

Tracing a Process End to End

The practical skill is tracing one process from trigger to output without skipping steps. Here's a simple trace of "handle a refund request":

Trigger: customer emails "I want a refund"
   |
   v
[Support agent reads email, finds the order]      <- 5 min, 2 systems
   |
   v
[Check refund policy: within 30 days?]
   |-- No  -> polite decline email                 <- done
   |-- Yes
   v
[Agent asks manager for approval if > $100]       <- wait: up to 2 days
   |
   v
[Refund issued in payment system]                 <- manual re-entry of order ID
   |
   v
[Confirmation email sent manually]
Output: money returned, customer notified

To trace one yourself:

1. Name the trigger — what event starts it?
2. Follow one real instance forward, step by step, asking "and then what happens?"
3. Mark every decision point and both branches.
4. Mark every handoff and every wait.
5. Stop only when you reach the true end state — not where it's convenient.

Common Mistake: tracing the documented process instead of the real one. The official version skips the workaround spreadsheet and the "just ping Sarah on Slack" step. Trace what people actually do — the workarounds are the most valuable information you'll collect.

Processes vs. Projects vs. Tasks

These three get mixed up constantly in customer conversations. Keep them apart:

The distinction matters because the fix differs: a slow task needs a better tool, a broken process needs redesign or automation, and a struggling project needs scope and planning help. When a customer says "invoicing is a mess," figure out which of the three they're describing before proposing anything.

Why FDEs Must Think in Processes

Three reasons make process-thinking a core FDE skill:

1. Software changes processes, not feelings. A feature only helps if it removes a step, shortens a wait, or kills an error inside a real process.
2. Processes reveal the money. Each step has a cost in time and errors. Tracing a process is how you find where hours and dollars leak.
3. Processes are the shared language. Operations people, managers, and engineers can all discuss "step 4 of order intake" — it's neutral ground where requirements get agreed on.

Best Practice: in every new engagement, pick the customer's single most important core process and trace it end to end within the first week. That one trace will generate more good ideas than any brainstorming session.