IT Budgeting: Getting Funding Right | Market Insights™
February 22, 2021
IT Budgeting
VIEW THE REPORT PAGE
IT Budgeting
VIEW THE REPORT PAGE
When considering your company’s IT spend decisions for 2020, it’s helpful to know what your peers and competitors expect for IT spend this year. What are their top investment priorities? Their biggest challenges? Is their focus different for 2020 than it was in 2019? How will their plans change if the economy strengthens or if it weakens?
The names that define the illicit hardware and software introduced into the organisation are uncannily accurate, but can be turned into a business benefit.
In a dark, gloomy and quiet corner of the office, behind cupped hands, the hushed words are spoken for fear that anyone else should hear: “Shhh, don’t say it out loud, but we’ve got a case of shadow IT.”
It’s not just limited to free apps either. Between both Gartner and Everest Group, their research found that anything from 30% to 50% of enterprise spend is linked to shadow IT. And both think this is likely not even close to the truth. The reality is that shadow tech is simple, accessible, cost-effective and quick. It doesn’t labour under the complex security and red tape restrictions that oft en hamper approved applications. And, let’s face it, many of the apps and solutions provided by organisations are difficult to use, bloated and chosen by management, not by the users.
Reimagining Enterprise IT Services Sourcing: The SLOTS framework for IT services sourcing
IT infrastructure services automation is evolving rapidly as the objective function shifts from efficiency gains to service resiliency and agility. IT infrastructure processes have become dynamic and complex, and traditional automation strategies, characterized by siloed initiatives and reactive script-based automation techniques, are becoming increasingly obsolete.
Autonomics holds the key to the “as-a-service” world…
Autonomics is poised to disrupt the automation space, and lay the foundation for business-aligned infrastructure services delivery. The self-learning and self-healing capabilities offered by the technology can help enterprises drive significant efficiencies and control within complex and judgement-intensive IT operations (think availability management or capacity management.) Efficient management of such processes, driven by autonomics, will be a critical enabler of the shift in IT service delivery towards the consumption-based/as-a-service paradigm.
We believe that the nirvana state of the IT infrastructure delivery-automation interplay, though a fair distance away, will involve the leverage of cognitive computing to create a “self-aware/alive” IT infrastructure model. Such a model will help deliver services contextualized to real-time user/business needs leveraging data from human-to-machine and machine-to-machine interfaces – i.e., making infrastructure “truly conscious.”
What is the best mode of automation adoption?
We observe three broad adoption modes for automation within enterprises:
While each of these models offers varied levels of benefits, we observe that the eventual mode of automation adoption chosen is highly dependent on enterprise imperatives/mindset and pre-existing service models, and rightly so.
Our recommendation to enterprises…
Traditional automation within IT infrastructure services has been around for ages, but is simply not designed to deal with today’s dynamic environments. It is time that enterprises took a coherent, business-context-aligned approach to IT infrastructure automation. Such a strategy should:
For drill-down and detailed insights into the latest trends in the IT infrastructure services automation space, please see Everest Group’s newly released report, “IT Infrastructure Services Automation – Codified Consciousness is the Future.”
CIOs and their IT teams are bombarded with major changes on nearly every front these days. Shifting to a software-defined environment is one of the top agenda items in many enterprises. But what does this shift in operations really mean? Are the benefits really worth the headaches of major operational change?
We are in the early days of this shift to a software-defined world, and it takes me back 20–25 years to the talk about taking our offices paperless. The early motivations of saving paper and preserving the rain forests have given way to a focus on office productivity, collaboration and ease of use.
The pace of new technology is advancing exponentially. But organizations change so slowly. This is particularly frustrating if you’re a senior executive who sees the opportunity to drive efficiencies or value and by making big changes in your organization, yet you find it’s painful and difficult to drive change and you can only make incremental progress. It’s also frustrating if you’re a service provider trying to sell a new vision to a slow-changing organization. What causes the slowdown?
People do what they are incented to do and what is in their best interest. Just because technology makes something possible doesn’t mean that people are prepared to change. And driving change is dependent on relationships with other people; highly dependent technologies also impact change. It’s not that individuals want to thwart change; it’s just that change will be thwarted because people always do what is in their best interests, as they perceive it.
Making a change in technology forces change in policies, processes and relationships; and that requires realignment. Alignment is complicated. It’s a combination of organizational incentives, personal incentives, metrics and what we measure, proximity to people, how we relate to one another and technology.
The tragic mistake that clients and providers so often make is believing that changing one aspect – the technology or perhaps a few people – will drive others to change. But it won’t. Driving change requires realigning the organization and ecosystem.
Borrowing from the old adage, human behavior is like water – it flows to the lowest point or takes the easiest path. This is a defining principle about why Apple has been so successful: it makes it easy to operate an iPhone or iPad. When we fail to make those same accommodations and think through technology change thoroughly, we can’t drive the organizational and behavioral change we’re looking for.
Change and adopting new technologies is so simple for the architects and designers. But they fail to view it from the perspective of the people who will be affected by the technology. New technology requires creating new steps or more complexity; therefore, new technology is more difficult to utilize than the old technology people are accustomed to and trained on.
Often the new visions based on a breakthrough or change in technology rarely live up to their potential because the service provider only changes the technology or provide new technology to the aspects of the service for which the provider is responsible. So the remaining organization can’t or won’t change; it’s left with the original interests and metrics, and it won’t readily change to accommodate the new structure.
Unfortunately, service providers’ salespersons attempt to beat competitors’ offers by oversimplifying the nature of the change the client will need to undergo.
To ensure client satisfaction and to ensure the technology lives up to its potential, providers selling a new vision and making promises must be far more realistic around the cost and time it takes to accomplish the change from implementing new technology.
Demand management has been the unicorn of enterprise IT – something frequently talked about but rarely seen and never captured. Every centralized IT organization would love the ability to accurately manage user demand. It would provide tremendous return if it were possible; but to date it has been largely or completely thwarted in large enterprise IT organizations. But there’s good news, thanks to the as-a-service model.
The reason demand management has been thwarted is that IT is organized on a functional basis; the data center, servers, network, purchasing, and security app development and maintenance are all defined functionally. IT leaders are held responsible for driving out cost and building capability that is shared by multiple departments. The problem is there is no relationship between demand and supply capability because business users don’t understand how to measure their usage/demand.
When IT asks business users how many servers they you use, their response is often “How many did we use last time?” Or when IT asks how many programmers will you use and why, business user typically respond with “We need 10 percent more than we had last time.” There is no relationship between actual demand and the actual demand drivers and the estimates they must provide to IT. This is a hopeless and fruitless exercise. It’s like a broken clock that is right only twice a day. This demand estimate is doomed to be wrong every day.
So what’s the answer? We need a service construct where IT is organized into service models. This construct gives business users a way to understand their usage or demand. For example, a healthcare payer understands how many people it expects to enroll. This is a metric the business can use to predict usage and the time frame in which they will need the service. IT can then manage the demand for the service it provides to the payer based on the number of enrollments.
When companies organize IT along service lines, they can translate business activities into technical consumption. The as-a-service construct attempts to make as much of its service chain or supply chain as elastic as possible. It adjusts each part of the supply chain to the usage demand. So unlike the traditional functional IT structure, business users only pay for what they use.
There are three mechanisms to make a technology or service elastic:
Typically, as-a-service providers use all three of these techniques to allow them to use their full service stack with the business metrics that the technique serves.
The as-a-service model achieves one of the Holy Grails of centralized IT – it provides a realistic demand management vehicle where the business can make accurate estimates. It also provides paying for the services only when they are used; this is the consumption-based model that the services industry is moving to.
Demand management to date has been completely illusive to centralized IT because of the take-or-pay nature of IT. This method for building capability – and business users sharing the cost to be able to use it – has no connection to business metrics that the business can control and understand how to estimate their technology capacity/demand. But the good news is the as-a-service model puts a rope around the unicorn. It creates the ultimate answer to demand management.
Although Software as a Service (SaaS) has become widely adopted, some organizations’ application management practices have not changed to reflect this.
All too often enterprise SaaS upgrades are handled in the same way as on-site software. Risk averse enterprises tend to rely on their IT service providers and their methodologies to support a mix of on-site and SaaS applications. The methodology is often the same for both types of software: The ITS provider lines up staff, according to its traditional application management strategies; one to oversee the upgrade, another to do impact assessments, another to fix issues on the day and so on. Before you know it, you have a team of half a dozen people lined up to help with the SaaS upgrade. In the meantime, the upgrade gets done remotely overnight by the SaaS software provider who has automated a large part of the process. It is not unusual for the on-site ITS team members to sit there looking embarrassed while twiddling their thumbs.
This is not to say that SaaS clients should throw caution to the wind and rely 100% on the SaaS providers’ best efforts. Instead they need to revisit best practices and follow upgrade strategies that fit the SaaS model. This should result in a reduction in the effort to oversee an enterprise SaaS upgrade by more than 50%.
Cloud and SaaS have had a huge impact on the ITS market already. This is evident by the reducing size of contracts. With increasing automation in the cloud, this trend is set to continue. The more adaptive of organizations will be reaping cost reduction benefits well ahead of those who stick to older approaches for managing their applications. The question to ask yourself: Is your organization stuck in tradition or adapting for its benefit?
As the services industry begins moving into the as-a-service era customers look for providers that change their traditional services to make them elastic or consumption based. We at Everest Group have spent some time studying this, and we believe there are three key ways to change take-or-pay (fixed costs oriented) services and make them elastic (pay as used). One or even a combination of all three ways are present in the services model that customers now demand.
Customers benefit from a provider sharing its capacity among multiple clients. AWS and Salesforce are classic examples of this elastic type of service. They redeploy servers or capacity when not in use to other customers and therefore achieve an extremely high utilization rate. In fact, arguably, AWS has over 100 percent utilization rate because it can charge customers for capacity when they’re not using it, yet can use that capacity for other clients. The model is much like an airline selling more seats than its actual capacity.
Repeatable process automation (RPA) or robotics spins up a virtual robot to do the work and then shut it down again. This fundamentally aligns a customer’s costs with usage and thus makes the service elastic.
The third way customers can have elastic services is to change their purchasing so that they only buy services as they use them. An example of this would be changing the way a customer acquires software, switching from enterprise licenses to consumption-based licenses where the customer pays for the software only as they use it. A note of caution here for customers: Although this makes the service elastic to you, there may be a stranded cost to your provider, and that cost may be embedded at a higher cost to you in your cost structure. So be careful about overly using the purchasing mechanism to make a component of your IT service stack be elastic.
Although customers can use these three methods separately, it is also beneficial to look for service providers that use a combination of all three methods to make a material difference to an entire service line to make the service far more flexible and consumption based to meet your needs.
We have not uncovered other mechanisms to make a provider’s service line elastic, but we are very interested to know if you have discovered another way to achieve elastic services. Please post your comment and share your experience.
Photo credit: Flickr
© 2011-2023 Everest Global, Inc. Privacy Notice Terms of Use Do Not Sell My Information
"*" indicates required fields