Digital transformation: Making sense of the CapEx/OpEx conundrum

The journey as a CIO has offered me new challenge, to draw an efficient IT roadmap, to bring digital transformation to the organization. While the organization is thriving and are expanding businesses at a fast pace. Since the capital expenditure towards the expansion, is substantial, as the CIO it is my responsibility to plan and execute IT infrastructure, deploy multiple ERP solutions, to assure,  hassle free business continuity, while achieving operational excellence; enhancing industrial automation, empowering the management to make better decision through BI enablement, and further ensure recovery and data security are the must calls to address, to support the business on this journey to digital transformation.

It is obviously a tough call to accommodate all in the same platter when there are concerns about financial flexibility and proper assumptions of future risk and changes of trends. Most companies focus solely on the short term and gravitate towards capital expenditure to boost perceived profitability, given that popular measures such as EBITDA conveniently ignore depreciation. We can be lulled into believing that CapEx is an almost-free financing option. I have been there, spending CapEx while someone else had to worry about the depreciation. Taken too far, this myopia can rob organizations of deeper financial control, growth opportunities, and even their future. With that context, I started giving thought to how can we counter some of these financial barriers and other calculative risks when it comes to cloud solutions? Before setting my vision and calibrating the IT road-map with that, I ensued that it satisfies my concerns.

While we might exercise control of capital through purchase orders (POs), what happens after the PO is approved? How do we track the efficacy of a new software license or data center post approval, and what’s to be done if the purchase was a mistake? Do the approvers of the PO really understand that they will be asked to sign more POs in the future for upgrades, maintenance, and hardware replacements? Consider too the psychology of CapEx, namely the much-studied sunk-cost problem. If I buy a data center or database license, or I spend a bunch of capital on a project, what happens if my business needs or environment change, or the initiative starts to go sideways? History shows that we tend to put aside the cold logic and double down on investing more in the hope of rescuing and justifying our original purchase. We find reasons to use the database license whether it’s the right software or not. We innovate based on what we have previously acquired rather than what makes the most sense.

The visibility of cloud expenditure and level of control is far superior to that achievable through capital-intensive equivalents. Agile, cloud-based organizations pace their investments with value realization. Their iterative investments are managed in near real time, with failures quickly addressed, pre-empting further unwise investments.

Many a time, we conveniently fall into the trap of believing that our core systems such as the ERP should cost the same every year due to their criticality and need for stability. We further attempt to create predictability by sizing the hosting environment to accommodate peak demand. A system in demand at the end of the month idly floats in a sea of excess compute capacity for the remainder of the month as there is often no incentive to improve financial performance.

Usually we spend two-thirds of our technology budget on just keeping the lights on, and it’s easy to believe that we only have to worry about the other third. Migrating many of these systems to the cloud and using the tools available to free up this year-on-year financial bleeding can save both CapEx and OpEx. An equally annoying belief is that we can create a hybrid solution, building fixed infrastructure rebranded as a “private cloud,” and using virtualization to match cloud scalability. Yes, this approach can help utilize more of the compute capacity, but it nowhere near reflects the level of scalability, security, or reliability investments made public cloud. In that strategy again we will have to consider the cost of resources, utilities and so on only to keep the game on.

It is a huge pride to the IT professionals when they can build their own branded data-center with highly configured resources. But, is that really wise to invest in an expensive robot only to satisfy the prediction of doing lots of hard work by that robot one day, or in emergency it may come on use or to avail some good discount from the partner only to wave the collar in front of the management! It really does not make any sense if you do respect only the growth of your organization and want to enable your IT as an innovative partner for the business.

I am not concluding the debate with which one is the best option, CAPEX or OPEX? At the heart of the CapEx/OpEx conundrum is the same philosophy that we see with digital transformations. Companies which have the confidence on predicting the right answer of their majority of investments can safely move to the Capex, while Agile enterprise firmly go with Opex as they invest based on the assumptions that they can often be wrong or the technology trend might be changed anytime or business focus might shift from one to another; yet they are able to learn and pivot cost effectively and quickly.

Disclaimer: The views expressed in this article are those of the author and do not necessarily reflect the views of ET Edge Insights, its management, or its members

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top