Automate a broken process and you just get broken faster.
Software is very good at doing the wrong thing thousands of times per second. So before we build anything, we measure what the process actually costs you today, remove the steps that shouldn't exist, and then automate what's left. Usually that means a smaller, cheaper build than the one you came in asking for.
Why a software firm does process work at all
Because we kept getting hired to automate things that shouldn't have existed. A client asks for a tool to speed up a four-step approval, and three of those steps turn out to exist because of a problem that was solved in 2019. Writing code around that is expensive and permanent. Deleting it is free.
DMAIC, without the ceremony
Five phases, in order, because skipping straight to "Improve" is how improvement projects turn into opinions with a budget.
-
1
Define
What is actually broken, for whom, and what would 'fixed' look like in numbers? Most projects die here, from a problem statement too vague to ever be finished.
-
2
Measure
Establish a real baseline. If nobody can say how long the process takes today, no one will be able to prove it improved — so measurement comes before opinions.
-
3
Analyze
Find the cause, not the symptom. Where does the time and rework actually go, and which few causes drive most of the pain?
-
4
Improve
Change the process, pilot it small, and confirm against the baseline. Automation comes here — after the process makes sense, not instead of it.
-
5
Control
Make the gain permanent: standard work, error-proofing, and the dashboard or alert that catches drift before it becomes a habit again.
Where the day actually goes
Lean's classic list, in office and warehouse terms rather than factory ones. Read it once and you will recognize at least three of them before you finish your coffee.
| Waste | What it looks like in a real business | |
|---|---|---|
| D | Defects | Rework, corrections, credit memos, and the order that ships twice. |
| O | Overproduction | Reports nobody reads; picking or building ahead of real demand. |
| W | Waiting | Approvals, batch jobs, a dock waiting on paperwork, an order held for one field. |
| N | Non-utilized talent | Skilled people re-keying data a system could have moved. |
| T | Transportation | Handing files, freight, or tickets between systems and teams more than once. |
| I | Inventory | Work-in-progress queues, unworked backlogs, stock held to hide a process problem. |
| M | Motion | Extra clicks, extra screens, extra steps across the warehouse floor. |
| E | Extra-processing | Approvals and fields that exist because of a problem solved years ago. |
Mnemonic: DOWNTIME — which is also what these cost you.
What you actually get
Not a slide deck nobody opens again. The deliverables are the kind of thing you can hand to a new hire, defend to an auditor, or point at when someone claims the process is fine.
- A current-state process map, built from watching the work — not from a meeting
- A measured baseline: cycle time, touch time, error and rework rates
- Root-cause analysis tying the pain to specific, addressable causes
- A prioritized improvement list with effort and expected payback per item
- Standard work documentation for the process as it should now run
- Error-proofing built into the tools, so the wrong thing gets harder to do
- A control plan and dashboard that shows drift before it becomes normal
- A before-and-after comparison against the original baseline
Measure first, always
If nobody can say what the process costs today, nobody will be able to prove it improved — and the gain will quietly erode.
Ask the people doing it
The operators already know where it breaks. Most of our first week is spent watching and listening, not presenting.
Delete before you build
Every step removed is a step nobody has to maintain, train, or pay for. Code is the last resort, not the first.
Make it stick
The Control phase is where most projects quietly fail and where software genuinely helps: defaults, validation, and alerts on drift.
Tools we use when they earn their keep
Chosen to fit the problem. Nobody needs a designed experiment to discover that one approval step has been unnecessary for three years.
Processes worth measuring first
Warehouse & fulfillment
Dock-to-stock time, pick accuracy, and the rework buried in short-ships and returns. Pairs directly with our 3PL and warehouse work.
Order to cash
Quote, order entry, fulfillment, invoicing, collection. Every hand-off is a place orders stall and margin leaks.
Customer onboarding
The gap between "signed" and "actually running." Usually the least documented and most improvised process in the company.
Month-end close
The recurring multi-day scramble that exists mostly because data arrives late and in the wrong shape.
Quoting & estimating
Slow quotes lose deals and inconsistent quotes lose margin. Both are measurable variation problems.
Support & dispatch
Triage, routing, and first-time-fix rate — where waiting and re-work hide behind "we're just busy."
Straight answers
Isn't Lean Six Sigma a manufacturing thing?
It started there, but the method is about any repeatable process with variation and rework — order entry, invoicing, customer onboarding, quoting, dispatch, month-end close. If it happens more than once a week and people complain about it, it is a process.
How is this different from just hiring you to build software?
Sequence. Automating a broken process makes it break faster and more expensively. We measure first, remove the steps that should not exist, and only then automate what remains. Often the software we end up building is smaller and cheaper than what you originally asked for.
What if we do not have any data to measure?
That is the normal starting point, and the first deliverable. We instrument the process — sometimes with a stopwatch and a spreadsheet, sometimes with logging we add to your systems — and we confirm the measurement is trustworthy before drawing conclusions from it.
Do we have to shut the operation down?
No. We work around your schedule, pilot changes on one lane, shift, or customer first, and keep a rollback. A kaizen event can be a focused few days, but it should never mean stopping the business.
How long before we see anything?
Define and Measure typically take one to three weeks depending on how accessible the data is, and that alone usually surfaces one or two obvious fixes worth doing immediately. Full DMAIC on a meaningful process is more often a couple of months.
Who needs to be involved from our side?
The people who actually do the work — they already know where it breaks. Plus one sponsor who can approve a process change. We do the mapping, measurement, and analysis; the operators supply reality; the sponsor removes obstacles.
Pick the process that annoys everyone.
That's almost always the right place to start. We'll measure it for free and tell you what it's really costing.