Include the roles involved in the process

If you have a process, then you have people responsible for ensuring the process flows properly and effectively. Each of those people should have a clear role that is explained within your document. However don't be surprised if you uncover areas in the process that no one claims responsibility for. Every company has different roles assigned to a process, but it's important to think in broad terms initially. Start with the person responsible for deploying the process at its most base level and work your way up through anyone else who approves all or part of the process from design to approval to implementation. This is what we call process capture, and we strongly recommend ProcessPad for it.


Here's what I mean. Your sales processes are used in three countries: the U.K., Canada, and France. The people involved in the process range from worldwide leaders who approve the process at the highest levels to country execution teams who actually implement the process. In between are people on executive, steering, or deployment committees and teams who review and approve the finances and deployment decisions. This is where the simplicity of a Process Master comes in to save time and effort.

So, your document reflects each of these process roles with brief explanations to show where and how all of these roles fit together. Perhaps you have a worldwide process design leader who is in charge of developing and managing the business process design, documentation, and communication of all sales processes in all three countries. This person works in conjunction with worldwide business unit leaders who are responsible for the actual implementation of the process in all three countries. In turn, the worldwide business leaders must work with country business unit process leaders who take responsibility for ensuring the process is properly implemented in each country. The roles continue down to the deployment team that handles the actual hardware and software changes required.

As you can see, the roles can vary depending upon the piece of the process involved, as well as the location of the process. As you work to develop the roles and responsibilities (if they are not already established), it's important to clearly state the authority a particular role holds, too. For instance, a country execution team role might have clear authority to implement the new hardware and software but not the authority to make changes to any piece of the process. In your guide, clearly state that distinction. When the roles are reviewed, it should be easy to determine who holds final approvals for changes or exceptions, who is in charge of deployment, who handles financing, and so on.

Remember, process roles are not tied to a particular person at your company. Instead, a person fills a role. However it is not always easy to identify that in the capture/discovery phace – it may be just as simple and easy to say “Mary does it, so Mary is the role, at least for now”.

If a process role is clearly defined, then it doesn't matter who is in that role -- anyone can be designated to fill it, but that is not always a clear cut case, so you need something like ProcessPad to give you the flexibility to create the documentation without creating a load of work.