Invite a team to a meeting about compliance and you’ll be met with a few no-shows, distracted body language and your fair-share of eye-rolling in the meeting. Invite a team to a meeting about quality and it’s a different story. Team members will be present, engaged and suggesting a wealth of opportunities to improve it.
Why is this? I suspect there are many reasons but a few spring to my mind. We all want to do a good job and sometimes our processes get in the way of doing just that. We feel good when we’ve removed a defect or made the customer experience better. On the other hand, the term compliance implies a chore, a “have to” rather than a “want to”.
What is also interesting is that the impetus for each type of meeting often comes from different functions within the organization. A request to improve the quality of the customer experience may be driven by the product or service owner. A push to reduce the cost of rework and defects may come from the finance function, while a focus on compliance is frequently initiated by the risk and compliance team.
Too many cooks in the kitchen
The trouble is that each function has its own goals and objectives, which they believe should be the priority. However, it’s the same underlying process that has to be changed, and communication between the relevant stakeholder groups is limited. This siloed approach is particularly common around planning time. Cascaded objectives may make sense functionally but generate conflict when trying to apply in practice.
The other issue relates to how change is funded in large organizations. Many organizations allocate capital to different portfolios, e.g., revenue generating/growth, productivity/cost, risk and compliance, with the latter split between mandatory and discretionary. This exacerbates the problem as business cases are prepared targeting a specific funding pool. There may be three different business cases – one in each of the categories – that all touch different parts of the end-to-end process with both upstream and downstream implications or, at worst target the same part of the process with different expectations. While work may be undertaken to analyze the dependencies, it is hard. Many services organizations do not have or apply a robust, detailed process architecture, with the result that process definitions are vague and business cases discuss the same processes at different levels of abstraction, with different start and end points, referring to different channels and different customer segments.
Quality is the answer
These are not simple issues to fix, but part of the answer is for each function to lead with a process quality mindset. Quality and compliance are two sides of the same coin. Whichever school of quality thought you subscribe to , and there are many, the underlying aim is to reduce the risk of process failure. Compliance is about ensuring that procedures correctly reflect the process’ obligations and that they are followed. Quality is about ensuring that the procedures reflect the customers’ and shareholders’ requirements and that they are followed. In both cases it’s a question of understanding the rules that apply to the process and then designing the process so that it meets these rules; whatever the source of the requirements and the implications of failure.
Making it happen
Easy to say, it’s not so easy to make happen. Trying to have an abstract conversation around a table with different stakeholders about the potential implications for the process’ performance, all too often leads to frustration. However, process intelligence tools can help to overcome these challenges. A good process intelligence platform combines process mining, scenario simulation and compliance monitoring functionality all on the same common platform, which makes answering these questions far easier.
Inviting all stakeholder groups to a quality planning meeting, where each group can:
- see the current process and its performance,
- describe the changes that they would like to implement, and
- assess the impact of these changes, not only on the performance of the process, but also on their colleagues’ objectives,
This makes for a far greater appreciation of the trade-offs that must be negotiated. Stakeholders start to use the same language, describe the process in consistent terms and have a common understanding of where it starts, where it stops, and its inherent design challenges. More importantly, conflict can be resolved directly by the respective stakeholder groups, without relying on the process owner to act as “piggy in the middle”. The benefit really comes to life during simulation where multiple scenarios can be run and challenged quickly, and each stakeholder gets a chance to “walk in the shoes of the others”. Besides leading to a more balanced change agenda, and business cases that are inherently more joined up, this approach dramatically improves process knowledge across the organization.
Ready to unlock new opportunities with Apromore? Request a Demo below and stay tuned for our upcoming series, where we’ll explore case studies and best practices for deploying customer service enhancements, or check out our compliance video below!
