Business process design covers many areas. It involves understanding requirements, both the business and functional, the ability to interview different subject matters experts, then write the narrative explaining how the process currently works (as is) and could work (to be).
Furthermore, it requires visual design skills to map the process, typically in MS Visio or some other diagramming tool so reviewers can evaluate the process, find errors in the current design, and then make suggestions to improve the actual ‘to be’ design.
There’s a lot of iteration and document reviews. But I find it very enjoyable. Getting the process right ensures that what the software developers build starts on a firm foundation, that the system will be delivered to a higher standard, and that fewer updates will be required to retrospectively fix poorly designed processes.
So where do we start?
What do sudoko and business process writing have in common? If you’ve spent an idle afternoon playing sudoko, you know the pleasure in solving these riddles. In some ways, capturing business processes is a little similar.
If you’ve never writing a business process before, then this tutorial may help. Let’s look at how to get started, mistakes to avoid, and the best way to develop your processes.
Business Process Writing: How to Get Started
I have to confess that of all the different types of writing, I enjoy writing business processes the most.
I thought this would be a doddle as it was a blue chip firm, Nasdaq listed, and a household name. When we started to scope the business processes, I realized why we’d been hired.
In many cases, the problem with writing business processes is that your client may not have their processes ‘mapped out’ in a way that show them how the business functions.
What this means is that while they ‘know’ how their company operates, they haven’t actually put it down on paper… or if they have, it’s not correct.
That’s where you, the process designer, come in.
How to Define Business Processes
To define a business processes, follow these steos:
- Priority – Confirm what processes are most important to your client, i.e. what do they want captured most urgently. Which processes cause the greatest bottlenecks in their operations? What do customers complain about the most?
- Experts – Identify the people who can help you understand these areas, usually these are people who’ve been with the firm the longest and/or subject matter experts.
- Scope – Define the scope of your work; this avoids assumptions from other parties on your specific deliverable.
- Project Plan – Create a work breakdown structure (WBS) and enter the start/end dates for each process.
In other words, create a project plan, enter the deliverables and get started with each task. Don’t start any writing until the project plan/wbs is in place.
Business Process Writing: Guidelines
Once you’ve agreed with the project stockholders which business processes need to be developed, start documenting the processes.
Here’s a plan of attack:
- Template – Create a template for your business processes. This helps standardize the documents and lets others get writing faster.
- Guidelines – Create writing guidelines (cheat-sheet) so less experienced writers can develop their business processes with more confidence.
- Reference – Share examples of SOPs and other business processes with the team. This gives a frame of reference and creates expectations.
- Tasks – Allocate writers to different business processes. This makes people own their respective process and encourages accountability.
- Interviews – Contact SMEs and those you wish to interview. Describe what you hope to achieve and why you feel they can help with process definition.
- Peer Reviews – Write the business processes and share them with the team for review. Again, share best practices on how to review the documents and show other (novice) writers how to critique the business processes.
- Validate – Test the business processes. If you’re developing a software system, then validate them against how the system operates. If you’re documenting a finance department, arrange a workshop and walkthrough the business processes, examining each step, and making corrections as needed.
Business Process Writing: Mistakes to Avoid
If you’re new to business process writing, or hired as a freelance writer, it’s easy to get pumped up and want to start writing NOW.
Pause for a moment and look at you’ll approach the overall business process design.
- Style Guide – Choose a style guide so writers have a frame of reference for grammar queries and… so you can focus on your work and not answer another ‘quick question’.
- Writing Guidelines – Give your team examples of how to write business processes, for example, how to use the active voice, how to break down specific tasks, how to use If-then tables to capture multiple options in a process, and how to diagram them in MS Visio.
- Flowcharts – Most clients appreciate flowcharts and process maps. Instead of having to read another business process, they can examine it if presented visually and make corrections much faster. I recommend that you create a process map for each business process. It gives a nice balance and, from my experience, improves the quality of the deliverables.
- Reviews – Many writers will focus on grammar and other technical details when reviewing the business process. That’s important but… checking that the actual steps are correct is much more important. Highlight to other writers what needs to be prioritized, i.e. the integrity of the process rather than a split infinitive!
Developing business processes requires different skills than writing, for example, a user guide. You need to engage with others more actively and develop interviewing skills that help you capture how the process works correctly.
It’s also very rewarding as, if done properly, you help others see how their business actually work – not how they feel it works. Subjective feelings become objective facts.
What else would you add?
What’s the most common mistake others make when writing business processes?
Editor’s Note: This post was originally published in Sept 2011 and has been updated for freshness, quality, and comprehensiveness.