There are two main challenges to documenting, streamlining, and automating complex business processes.
- It’s All In Your Head: As the business owner or operator, you have full knowledge of the entire process. It’s “obvious” to you because you’ve been doing it long enough that you don’t have to think about it anymore. By analogy, walking uses every muscle in the body, but we seldom have to think about the complexity required to make it work.
- Nobody Knows: You are part of a much larger system where many departments understand their area in greater detail. Unfortunately, very few people understand how the system works as a whole. This is the challenge of the trees trying to understand the forest.
In both cases, there are invariably inefficiencies, redundancies, and hidden opportunities for growth. This is the 7-step process to uncover where and how to improve your system and achieve your primary goals.
1. Identify the Stakeholders.
The goal here is to identify at least one person from each major perspective in the system. While that may be department heads, it should also include line workers who interact with your system firsthand.
2. Build the List of Entities.
Some entities are familiar to most organizations. These include Prospects, Customers, Products, Services, Tasks, and Notes. Other entities are particular to your organization, such as named processes, suppliers, materials, processes, and outputs. The point of this step is to identify what they all are.
3. Identify Everything That Changes State.
Several entities listed above will have various state changes. Some, like below, are common. Others will be particular to your environment.
- Tasks: To Do, Doing, Testing, Accepted, or Done
- Contacts: Prospecting, Onboarding, Serving, Closing, etc.
- Projects: Scoping, Performing, Delivered, Archived, etc.
4. Identify Entity Attributes.
This is a more subjective step. How far you drill down will be based on what is needed for making decisions, sorting and filtering, or what creates value. However, different attributes are valuable to different stakeholders. For example, Engineering seldom cares about the address or birthday of a contact, but that information is helpful to sales teams.
By identifying all the attributes, we can reduce the need for multiple systems because your primary system fails to account for something relevant to one of your teams. However, there are other occasions where an external tool is so much better at a particular function that it’s not worth trying to replicate its functionality in a centralized system. For example, finances are part of every system, but it’s unlikely that the same tools will serve engineering and finance.
5. Map Entity Relationships.
One attribute of most entities is how they relate to one another. For example, tasks are being performed for a customer, are part of a project, and are owned by a person or role. The map of all entities and relationships is called an Entity Relationship Diagram (ERD) and can be represented visually from simplistic to detailed form.
6. Define the Rules.
Information and products or services “flow” through the system in all businesses. The steps in the process are most often invisible until such time as there is a breakdown. In this step of automation and documentation, we seek to make explicit the rules that the stakeholders implicitly know. Here are some of the questions we’ll answer together:
- For everything that changes state, what must happen before the change occurs?
- When an entity changes state, what happens to other entities afterward?
- Does an entity automatically change state when other things happen?
- Is an entity prohibited from changing state until other things happen?
- Is changing state dependent on attributes within an entity or on other entities?
7. Documentation and Recommendations.
The process above gives us almost everything we need to chart our path forward. It lets us know the capabilities that your system needs to track and facilitate. It creates a roadmap for implementation for whatever tools you are using, else gives you the requirements to consider when you are evaluating what other tools would better serve your needs. This is especially important so that your tools can work for you, rather than you having to shoehorn your process into the limitations of your tools.