A colleague recently told me of his “tech support” calls with his 80-year-old mother. He had set her up with video chat, carefully designing everything to be as simple as possible and giving her extensive instruction. Yet she still calls him often, frustrated that, “the thing doesn’t do the thing when I press the thing.” Luckily, my friend says he can always solve the problem over the phone in a matter of minutes and get her back in business.
This resonated with me because it’s exactly in line with much of my work here at KPMG. No, I’m not usually helping 80-year-olds make the thing do the thing. But I am trying to help our clients understand the importance of having a complete support model for their application infrastructures such as Oracle Cloud. And my friend provides a perfect example.
“It’s better to be looked over than overlooked” – Mae West
The support model is one of the most overlooked parts of a digital transformation project. Even after a cloud migration, it’s often left unchanged, typically with three parts I’ll collectively call “IT support”:
- The IT “administrators” or “developers” The traditional “Super users” who hold all the keys to the kingdom.
- Security managers responsible for developing and maintaining application roles, permissions, password configurations, etc.
- The identity management (IDM) team responsible for provisioning application access based on the roles and permissions defined by security managers
If it ain’t broke…
With the exception of the all powerful “Super User” IT administrators, there is nothing inherently wrong with this model, per se – it’s worked for years with the on-prem systems. But consider the value my friend brings to the engagement with his mom.
He can understand her and help translate and fix “the thing” far more efficiently and effectively than any “official” tech support person could. He knows exactly what she’s trying to do and what needs to be done to resolve the problem – almost without her having to explain anything. He doesn’t need to take control of her tablet or login to her account – he can easily talk her through the solution. In other words, he doesn’t need “Super User” access.
Bringing it back to the now, when one of your employees hits a roadblock and needs support, wouldn’t it be great if they had a resource like that? From a compliance perspective, wouldn’t It be great if we could reduce the ‘super user” access of our IT teams, without causing operational issues?
While it sounds like we’re talking only about support models, we’re really talking about risk. These IT support teams need access to the production system and its sensitive data to reproduce and solve the problem. Indeed, they often need remarkably broad access to support a wide range of business groups or units – finance, sales, purchasing, etc.
Speed, of course, is essential. As a result, the issue and the steps to address it are often not well documented or even documented at all. The IT support person might “solve” the problem by making a “quick” change to the production environment or by granting the employee a new and broader set of access privileges. If a business user is trying to approve an invoice, for example, and the system isn’t letting them, the IT support person might make a change that allows them to approve it – without, perhaps, questioning why they weren’t being allowed to in the first place.
IT support is empowered to make these changes – the question is: should they? This is the stuff that keeps auditors awake at night (or perhaps more accurately what keeps them in business).
Is it really a technical issue?
IT support teams surely have their place – when the problem is technical, such as when a VPN connection drops. But ask yourself this: are most of the issues your business users encounter technical or are they really issues with business processes?
This is where a business support team comes in. Such teams are so often the missing ingredient in many support models. They consist of people with a detailed understanding of the business processes who also have a level of technical competence or familiarity with the applications. Just like my friend and his mom, they’re not brokering a conversation between the IT support team and the end user – they are a first line of support. They don’t have access to initiate transactions or to make the same technical changes the IT support team can, but they shouldn’t ever need to.
For example, with our user who wasn’t able to approve an invoice, rather than change the system to allow it, a business support person might explain to her that the reason she can’t approve it is because of a business rule designed to prevent some potentially fraudulent activity and not some bug in the system – something an IT support person wouldn’t likely know.
Already got ‘em?
As testimony to their importance, you might already have business support teams and just don’t know it. “Unofficial” such teams often appears all by themselves. When someone has a problem, they know to call Roland or Debra in their group because he or she understands exactly what they’re trying to do and usually has the solution. Of course, Roland and Debra have other full-time jobs, and their access to recognize and address systemic issues will be limited.
The challenge of empowering a business support team falls to you. Recently, KPMG hosted a webcast on this exact topic, you can check out the replay below. Additionally, please reach out to have a further discussion on this topic, everyday my colleagues work with clients on streamlining their support model to improve support and mitigate risks.
