What are the best practices for documenting a business process redesign?

The most important question to answer before commencing on any business process redesign is: "We perceive that the current process is not working because.....". The answer to the question will set the scope and limits of the redesign, and give both expected outcomes and KPIs for the redesign. All stakeholders associated with the process should be asked to contribute and where possible, answers should be backed up with quantifiable data.

When documenting a business process redesign, I follow standard steps but also consider alternative perspectives. 1. Identify the Scope and Objectives: Define clear goals to keep everyone aligned. 2. Use a Standard Notation and Format: Stick to one style, like BPMN, for clarity. 3. Involve the Stakeholders: Gather input from everyone affected.. 4. Validate and Verify the Documentation: Ensure accuracy and get feedback for corrections. 5. Maintain and Update the Documentation: Keep documents current as processes change. 6. Additional Tips: Consider user experience, embrace flexibility, use visuals, tell a story, document failures and fixes, and focus on simplicity. This ensures thorough, practical, and user-friendly documentation.

Using standardized notation, such as BPMN, which offers consistency and clarity, is one of the best practices for documenting business process redesign. In particular, using BPMN symbols to map out the revised process guarantees a visually pleasing representation that is simple for teams to comprehend. To create thorough documentation, make sure to include specific roles, responsibilities, and descriptions. To ensure that all parties involved are informed and on board with the revised process, update and distribute this documentation regularly.

I would perhaps examine the culture of process you are working in and who will be using it (management, workers, other project workers) I’ve seen a huge amount of energy go into the curation of high quality documentation for it to subsequently be ignored. Or perhaps in other words, write to your audience needs.

I recommend using Universal Process Notation (UPN) to document processes. It is the standard recommended for Salesforce projects, and I have found it helpful to use. Whatever notation & format you use, assume you will have to explain it to non-techncial stakeholders.

Involving stakeholders doesn't always just mean conducting interviews or questionnaires. In my experience, colleagues do a good job in workshops with around seven members if the process model can be seen by everyone and if everyone can give their input and suggestions for optimisation.

I agree that this does not always include interviews— but could even be creating mocks / prototypes and obtaining feedback from the actual users of the new flow. Users can often detail problems they face that can easily be incorporated into the flow. Feedback loop during and after implementing a process change is invaluable and can help open the dialogue towards continuous improvement as well.

Invite your stakeholders into the process by looking for problems. For example, find out which steps are particularly frustrating to do. For example, when I was at a bank, I had to use a complicated Excel file regularly. That process needed a process redesign!

Engaging stakeholders from the outset of the change process is a strategic move that pays dividends in the long run. By involving key stakeholders early on, organizations can tap into their knowledge, insights, and concerns, creating a more informed and inclusive change strategy. Stakeholders, being directly affected by the changes, possess valuable contextual knowledge that can help refine the change plan and identify potential pitfalls. Moreover, involving stakeholders fosters a sense of ownership and commitment, reducing the likelihood of resistance.

Walk throughs and training are two of the best ways to test your documentation. The gold standard for documentation is whether a person who has NEVER done a process is able to complete the work without any external support.

Most importantly, scope the process whether it’s a cross-functional or standalone within one function. Other elements can be defined accordingly

1. Use of BPMN 2 versions compliant tools such as MS Visio 2. Clearly outline the changes vs what has remained unchanged on the TO-BE process maps

The most important "stakeholder" is the customer or end user of the process undergoing a redesign. So many processes are designed with too much input from internal users, the external or customer is often overlooked.

I’d like to recommend adding a few more points. Define the first and last step in the process to establish the boundaries. Identify the controls in the process. Identify who are the people that will review the process and who will approve it. The latter is usually the person accountable or owns for the process.