A lean automation framework for elevating business processes
TL;DR
We describe our framework for lean business process automation (BPA). It involves three steps, the second of which a human drives. This approach helps control the complex interdependence between process and automation in BPA.
Paul Graham’s oft-cited essay “Do Things that Don’t Scale” encourages startup founders to embrace activities infeasible at a larger org, i.e. writing personal notes to customers or manually on-boarding users.
Graham devotes a few sentences to automation, pointing out that it can be faster to start by hand and then to “gradually automate the bottlenecks” as they appear. No sense in automation that “doesn’t yet solve anyone’s problems”.
It turns out that this idea prevails more broadly in the context of business process automation (BPA) and bespoke software. We write custom code professionally and have adopted a system for lean automation much in the spirit of Graham’s essay. It involves “automating” business processes with humans as the second step in a three part cycle. The approach recognizes the interdependent bond between a process and an automation, improving both while cutting waste.
Successful expert clients
Here’s an anecdote: clients thrive who have lots of experience in a manual process. Have you written thousands of car insurance claims? Then I have a lot of faith in you to advise on a claim automation system. Do you file tax returns year after year? Then you’d be a great consultant on this tax-filing platform.
Tell us if we can digitize that clipboard
A few obvious reasons come to mind:
- You’ve likely put out a fire or two in this job and will step around landmines.
- You’ll have a great sense of priorities as to what we should build.
- You will validate good ideas and dismiss bad ideas quickly.
- You won’t try to rip out Chesterton’s Fence.
Business process automation
When it comes to BPA, the “process” and “automation” components are interdependent and tightly linked. Like the chicken and the egg, they each follow from the other. You automate a process, but usually can’t stop there: idiosyncrasies arise out of the manual remnants, sometimes unnerving users and personnel. So you update the process and maybe repeat the cycle.
Thus BPA is hairy and iterative— it demands context switching. When an expert knows a process like the back of their hand, they can save iterative cycles by sensing how things will play out. So automation involving a domain expert and arduous process tends to flow smoothly downhill. By focusing all conscious attention on the implementation, they cut much of the work and risk.
But we don’t always sit on a gold mine of unrealized potential. You might not have 1,000 hours of experience specifically printing UPS labels, or 100 hours writing invoices. Or else, you might be new to a role and just know that the system needs improvement. Fortunately, there’s another way to take on the complex feedback loop of process and automation.
The virtual assistant method
The question of automation involves two risks:
- Not automating and missing a big opportunity
- Pouring resources into an automation that fails
To reduce risk we only need to be sure an automation won’t fail before kicking off. That in turn means being liberal with what we’re willing to consider and somehow testing preemptively.
The process goes like this:
- Propose an automation
- Emulate the automation with a human
- Write bespoke software after validating that the automation proves worthwhile.
1. Propose an automation
Someone will propose an automation by identifying a coherent process and suggesting a way to automate it. The proposal should be geared towards software, though at the end it will entail how to emulate software processes manually.
You should be liberal with your proposals; most won’t garner any investment so there’s not a big cost.
2. Human replication
We typically use a virtual assistant for the “human” component, hence the name. VAs are easy to find online, but you can also employ anyone from your org for this part.
Send the person detailed instructions— which, by the way, has the dual benefit of helping you elucidate the fine details.
Have the person be in charge of this process for a reasonable amount of time and determine whether it seems worthwhile. You will likely tweak the process a little bit while observing results. Don’t put much weight into the human costs which should drop in the third step.
How do you determine if it’s worthwhile? I’m sorry to say that usually you can just tell. As a rule of thumb, if you find yourself dreading going back to the pre-assistant setup, then you’ve found something worth investing.
3. Bespoke software development
Finally, at this point you will know whether the automation will pay dividends or not. Well, assuming you know the general costs to implement, so find a competent team to tell you that info.
For our part, we take the original proposals along with feedback from the human component and write a technical specification for our engineers to dig into.
Examples of the VA-method
We’ve employed this method for clients but also internally to much success.
Meeting notes
K-Optional Software has a documentation-oriented culture. We basically assume Slack to be a black hole for information and compile notes for any nontrivial meeting.
While this system has paid dividends in the form of a great knowledge-base, it doesn’t come for free. Someone has to take notes each meeting that conform to our structure and also provide some meta information such as the time, type, and attendees.
Pretty early on we decided we wanted to automate this system. Instead of waiting for resources to be available, we went through the VA method. We wanted calendar invites to drive meet documents, pre-filling relevant meta data and attaching relevant recordings.
Before writing code we wrote instructions. Attaching a VA to a meet invite cued them to set up the notes manually. By the time we started our suite for automating meeting notes, we had the confidence and blueprint to write the code.
Research pipeline
We spend a lot of time prospecting technology and ideas that can help our clients. A process slowly formed where we mark lots of articles and papers for consumption. Then when someone in R&D has a block of time, they read everything and write primers, reviews and proposals.
Organizing the stack of research became unwieldy and we envisioned a system for tracking research.
To emulate with a human, we would simply email a VA whenever we saw a title worth exploring. The VA would convert the page to a PDF using a plugin, transmit it to the researcher’s e-reader and prime our database for commentary.
Our eventual solution combines VAs and machines and has saved hours while sharpening our knowledge-base.
The VA method and systems engineering
In hindsight the human emulation step happens to set the stage nicely for a robust system design. That’s because a human implementation involves:
- Asynchronicity - we can’t expect a human to do something immediately
- Unreliability - humans make mistakes and miss cues
Controlling for these attributes during the human phase has naturally resulted in resilient software systems.
The VA method and GPT
I also think it’s worth noting that this system primes us well to the next generation of bespoke software and automation: large language models (LLMs) like GPT.
Already LLMs have made thorny problems palatable for a computer. And since they’re flexibly driven by natural language, we can turn human instructions into the bespoke software very easily. Writing good instructions bodes well for writing good prompts.