Project-CAPEX in IT
Halûk Sagol, Associate Director of INVERTO, on why the seperate consideration of CAPEX and OPEX in IT purchasing is counterproductive
Why do you argue that OPEX and CAPEX should not be considered separately?
Whether a requirement is OPEX or CAPEX is initially completely irrelevant from the buyer’s point of view and only has consequences for the subsequent financial posting. The practice of separating OPEX and CAPEX requirements is counterproductive, as this lacks the necessary transparency in mixed product groups. I would therefore argue that purchasing should first only be differentiated according to functional IT product groups, which then contain all the requirements of this category, whether OPEX or CAPEX.
What does this mean in concrete terms in IT procurement?
The procurement of a server, for example, is CAPEX or OPEX, depending on whether it is purchased, leased or procured as-a-service. For the demand planners, however, it is not relevant how the server is procured, because the demand is always the same. Only the procurement channels are different. Consequently, the anticipated separation of OPEX and CAPEX is premature from a purchasing point of view. The merger, on the other hand, ensures transparency and enables more efficient viewing and support together with the procurement department.
In your opinion, where else are the IT requirements affected?
In IT, there is sometimes an excessive need for security and a latent aversion to risk. This often leads to a considerable over-specification of actual requirements. Take the example of a new data line. This is where IT decides in favour of the feature with the highest availability. However, this decision is neither future-oriented nor appropriate. This would be the case if the capacity of the data line could be flexibly adapted to the respective future requirements and already available models of the market could be used.
How can such situations be solved?
Through trustful cooperation between the specialist department and procurement – throughout the entire purchasing process. Always on the basis of IT requirements, Purchasing can already support the vendor-independent specification, methodically accompany the joint market development, help evaluate alternatives from a business point of view and point out potentials.