Excessive complexity is something that most organizations over a certain size have to deal with. The more successful you are, the bigger the enterprise gets, and the farther removed it gradually becomes from the original core tenets that probably made it successful in the first place. So how does this hurt a company? Well, if we’re talking about the IT estate, erratic expansion and the resulting unmanaged complexity makes its presence felt in the form of higher IT management costs, increased risk, and a slow rate of innovation.
On the process side, which is what we’re interested in in this instance, the most common problems are the existence of bottlenecks, a weak level of systems integration, lack of actionable business intelligence, duplication and, of course, the emergence of silos. An organization that suffers from these symptoms can’t be successful in the long term, or at the very least it can’t reasonably expect to continue growing. When it comes to business processes, usability is what drives adoptability, and the single biggest variable in achieving usability is simplicity. So, as processes straggle farther and farther away from the principle of simplicity, they become increasingly more prone to being ignored or ‘customized’ by staff, which opens the door to all manner of risk (think breaking regulatory compliance terms etc.). That’s when you know you need to redesign your process landscape.
However, one of them main issues when trying to turn the ship around – process-wise – is that stakeholders tend to focus their attention on details, on the potentially very idiosyncratic realities that you find at the tail end of a process. Say you’re working with a process owner in an organization who suffers from overly complex processes. As you’re trying to understand a process and the context in which it exists, it’s very likely that you’ll learn all about the many paths it can follow depending on whether certain events come to pass or not, exceptions – so what you get in the end is a large diagram with a whole bunch of logical branches.
Now, it’s obviously necessary to find out about the situation on the ground, however, once you get the lay of the land it’s equally important you don’t let yourself dragged into the existing paradigm. The status quo may actually seem reasonable once you’re in the thick of it, but remember you’re here to streamline things, and that may sometimes mean giving up on re-compartmentalizing the house and instead just build it anew. This means you ought to try and fix the root of a problem, so that the time and resources you spend make a bigger impact. Why don’t you identify whether there are efficiencies to be gained further up the river, so to speak, before the situation arises where you need 7 types of behavior to deal with exceptions? Tackling things at the root makes more sense than trying to make the best of a bad situations with minimal success.
Now here’s a scenario for you. Imagine you’re a global markets company running a range of products aimed at facilitating e-trading for banking clients. Your Customer Support team are regularly contacted by customers who can’t execute trades. These same clients are getting increasingly aggravated with the long resolution times and lack of a more permanent solution. So, what’s the problem?
Upon investigating things, it turns out there is a distinct team who set the parameters for trading on your platform – the Trade Enablement team. Then there’s the Customer Support team, who are the first point of contact for customers experiencing an issue. They can access data about the clients’ trading activity but, importantly, can’t change clients’ trading parameters. Actually, there’s another
team in charge of that, the Market Surveillance team. To make matters worse, the company has CS team members in all the regions where it does business as part of its 24/7 support offering but the more advanced teams only work from Singapore.
So, how does an average case get solved? As you might expect, it all starts with the CS team being contacted by a displeased trader. After carefully analyzing their account setup and their trading log, the CS agent concludes it’s probably something to do with the way the platform has been set up for this particular customer, so the issue is escalated to Market Surveillance. MS then look at the detailed logs in order to discern what exactly is happening when trades are initiated by the client. They uncover the fact that this particular bank is trying to engage in currency exchange trades of a type for which they have no clearance – nothing wrong with the system, it’s a matter of how they were onboarded and how the tool was configured!
As such, the problem is the sent to the Trade Enablement team who confirm the client is simply lacking the privileges to trade a particular currency. They reach out to Account Management, ensure this is something that was negotiated and after approval they rectify the problem, get back to CS telling them everything’s been solved, and then CS in turn go back to the client with the story and recommended steps. The problem is it all took a long time and the bank missed out on the trades they wanted to do. This is a prime example of how convoluted process (and this is by no means a hellish scenario; rather average, at best!) affects customer experience and can lose an organization business.
Now, one might be tempted to try and improve communication between these teams, or replicate the more advanced Trade Enablement and Market Surveillance teams in other regions, as well… or one could simply develop an automated system checkup that reviews customers’ trading configuration against a ‘golden record’-type registry. This would be labor-free and human error-free in the long run (apart from the initial development work) and would eliminate oh-so-many needless customer support interactions.
So that’s one thing to keep in mind during process redesign, try and determine whether there’s any way of going one level up and perhaps eliminate the problem altogether, not just deal with it better. Root cause analysis will yield good results in situations where it seems there is no end in sight – perhaps you just need to set your eyes higher up on the horizon! At BiZZdesign we understand this ethos quite well – our very roots are in process improvement! In fact, and just as a side note, in the early days of the business process re-engineering wave in the 1990’s there was a famous article called Don’t automate, obliterate by Michael Hammer. The essence of that was that just putting a messy process in a system doesn’t actually make it any better, and we subscribe to this.
In conclusion, simplicity matters and one way of implementing simplicity into your processes is to take a bigger picture approach to your solution delivery. Give yourself more space to maneuver – no structure or framework is off-limits, as long as you have a genuinely better replacement. Remember, processes that aren’t simple are a burden – on the employees, who may feel alienated by the extra effort; as well as on the bottom line, which gets impacted by poor efficiency and wasted investments. So, when redesigning business processes, don’t get lost in the details. Set yourself a few solid principles to act as a ‘dependable 20%’ (as in the Pareto distribution) and then carry out work along those lines – the clarity and coherence that you’ll enjoy this way will prove priceless in your endeavor.
Thank you for reading and join us again next week for Part 2 of this series on overcoming process optimization challenges!