Processes are highly interconnected sets of activities, dependent on teams and technology coming together to deliver the intended outcomes. The way we record our processes helps us orchestrate all these different elements… but it might pay to check just how many times your organisation is re-writing the same process.
Take say a new faster process to ‘Raise Quote for New Customer’ that means we can beat the competition by two full days. What if…
- A process map was created by the service design team to define the new quoting process, used to seek approval to implement.
- The training team developed training materials describing the new process for Business Development Managers to raise a quote.
- The HR team updated the new quoting activities in the Business Development team role descriptions and KPIs
- The Enterprise Architects defined the new quoting process noting the IT platforms needed to support the raising of a new quote, and the data flows between different systems.
- Risk Managers updated their Risk Registers with the controls in the new process to ensure that all quoting risks were minimised
- Quality Managers updated their process documentation as part of compliance with quality standards
… and then someone decides to ‘improve’ the process.
The confusion and drag of different perspectives
What should be making everyone’s lives easier, could actually be contributing to making change harder, and creating more confusion for everyone. Different teams each make decisions based on their view of the process, assuming it’s still the way it should be performed. If the process has moved on… well this is exactly what leads to process break downs, process fire-fighting, and in general a whole lot of anguish.
How do we react when processes repeatedly break down? We usually respond by engaging someone to workshop the current state of the process to figure out where the problems are.
Two interesting points to note:
- We almost always need to workshop the process because for all those different versions that were created, none were used or updated, nor considered accurate enough to depend on even just months later
- We’ve just created yet another version of the process
How can you get out of this cycle?
There’s no one answer, but here are some factors that seem to make a real difference:
- Develop one process repository as the primary process knowledge base. Don’t leave the decision on the process knowledge base to different teams to duke it out. This part takes a bit of leadership.
- Promote it to teams: ‘this is it,’ the way the process is recorded here is assumed to be the way it’s done
- Keep it simple so it stays alive. Develop easy to follow processes, house them in a central, accessible place at the fingertips of those that need this information every day.
- Assign undisputed ‘process owners’. (Actually - one owner, one expert… but that’s another blog) There may be a lot of stakeholders, many listed above, but they need to understand that the process owner’s record is the primary description of how the process is performed.
- Instill a culture and processes to support updating of ‘the truth’. Any change or improvement must be reflected in the central knowledge base.
- Replace all those versions by shifting away from a documents approach to a single ‘object driven’ process structure. Each separate component that affects a different stakeholder can be filtered, traced, interrogated, logged, reported by stakeholders themselves.
- Don’t expect those stakeholders to somehow update their perspectives of process for every single change across the organisation. Keep everyone on the same page with automatic change notifications fed to all affected stakeholders. What feels like a slight change to one team, may force an entire rethink for another.
Having multiple different versions of a process is as bad as, and in some ways worse than, not having an agreed process at all.
I strongly believe that the team on the ground holds the key – those who are participating in the process and actually interacting with your customers. They are the real process owners, and their ability to consistently deliver right first time fundamentally depends on a clear, simple knowledge base helping them to do so.