For centralized IT, the problem of shadow IT may seem insurmountable, with new cloud-based apps making their way into the hands of business users on a steady basis. But there are steps IT can and should take to compete with and minimize the disruption caused by shadow IT. In this webcast presentation, Derek Lonsdale, IT transformation leader and Lean expert for PA Consulting, discusses one of those key steps: understanding business processes. Hear why Lonsdale says it's so important to think in terms of business outcomes rather than technology.
Editor's note: The following is a transcript of the third of five parts of Lonsdale's webcast presentation on coping with shadow IT.
Derek Lonsdale: I was talking to some of my colleagues in Europe last week and I came across a couple of interviews. One was with Patty Hatter, who is the CIO and … SVP of operations in McAfee, and they had an issue with renegade IT when Patty took on the CIO role, and her strategy was, 'We have to fix IT. The business will continue to go outside of IT if we don't fix it. If we fix it, then the business will come back to us.' And her strategy worked. I think, less than a year later the business was coming back and saying, 'Well, you're doing a really good job, IT. Can we take these services back from our providers and give them to you?'
I also worked for a Boston biotech chief technology officer. [His company] had an issue with renegade IT as well, and he stated that so long as the business approached IT first and asked for the service, if IT didn't have competitive services he was OK that they went elsewhere. He just wanted … the opportunity to compete and 'if we can't compete, let's advise where appropriate and we can help out.'
Ray Noonan, who's the CEO of Cogent [Ltd., of New Zealand], basically just shut down his IT and embedded it in his business. So, he totally went the other way around and said, 'Right, we're IT people; IT is our business; let's just merge it and have one IT in the business.' So, these interviews are on Transform IT and if you haven't come across it, they're well worth a visit.
I want to go back a little bit to this maturing of the end-user-facing processes because I think this is important. You can't just use the ITIL framework, which is the best practice brainwork for processes. The framework is great, but you have to use it to suit your organization. And you need to understand things like the fully lapsed time of your processes, and identify where there's waiting time, whether there's any rework or bottlenecks. There's a whole bunch of things that you can do to look at these processes, incident management and request fulfillment, from a slightly different angle. How do you reduce the waste? If there's a service desk ticket sitting in somebody's cube, that waiting time is waste. We want to get rid of it. If we have serial activities on a service request when there's the opportunity to do parallel activities, then that's waste. And onboarding is a great example of that, where, if an onboarding process is taking too long, it's probably because things are being done in sequence. And there's HR involved, there's IT involved, there's real estate involved. Let's parallel some of those activities so we can speed things up.
Having access to a well-structured knowledge base and retrieving things you want quickly is a way of getting rid of waste.
The reports that we deliver to the business [are] quite complex most of the time, they're not in business language most of the time, so let's focus on what the business wants. So, maturing end-user-facing processes, not just focusing on firefighting, are key things to do to allow us the right to deliver services.
So, if we've earned the right to deliver the services, how do we get to understand the business better? This is something that I think is really, really important. I did an end-user services strategy for a financial firm in New York recently and one of the things that we were talking to them about is, How much do we really understand the business? You've got three distinct business units and they're quite different in what they want from IT. One was much more of a waterfall-type approach, quite happy to have things slow and steady in terms of releases. The other one was much more agile and wanted releases, weekly if not daily. So, being able to understand what the business wants and having a good understanding of the broader business and the products that it's using so that you can understand what you can do from an IT perspective. Really knowing how those business processes works is important.
And IT has to get better at doing this. When I worked in the service desk, I used to get my services agents to go spend some time with the client. Spend some time in the business so that you understand how it works. [It was] very, very valid and valuable training for the services agents.
So, we talked on the previous slide about some of the operational processes and here we're talking about some of the more strategic business-facing processes. We know historically that most of the process maturity increases have been in operational processes -- incident, problem, transition processes like change and release -- but we need to look at the strategic service processes, basically: the service portfolio management, business relationship management and service-level management, too.
One of the things that Patty also explained in her interview was that IT has to become more transparent. We can't go silent and close ranks if something's gone wrong. Let's be honest. Let's be proactive when projects are going south and let's develop honest and simple reporting that is value-focused, not systems-focused. Now, the business doesn't care whether we've had a network of availability of 99.99%. They want to know whether they can produce invoices on time, or provide sales. So, how can we produce reports that actually provide business value?
A great example I came across the other day is having reports that explain revenue-impacting incidents and compliance-impacting incidents -- things that the business really want to see. They don't want to see how many P1s or P2s or P3s. What impacted the business? And if we can look at those revenue-impacting incidents and reduce them through good problem management, we're providing better value to the business and understanding the business better.
Improving accessibility to the business is about being joined up. We don't want the business to think about, 'How do we engage with IT? Who do I need to go to for X, Y and Z?' And they certainly don't want to be told, 'That's not my job. I'm a network guy. You need to speak to the server guy or the applications guy.' We want to have fewer silos and more end-to-end thinking.
We know that there's an increasing number of business products and services. There's a lot of complexity in data interdependency to get value out of these things. The days of two-year IT projects have disappeared. DevOps and Scaled Agile are all terms that IT should now be familiar with. And their introduction correlates with speed-to-market requirements from the business. IT projects cannot keep on being behind schedule and over budget. And I think IT has to focus on business op outcomes and objectives, and not technology.
Questions about this webcast presentation on understanding business processes? Email firstname.lastname@example.org.