Is it time to rewrite the ELP? The recent court case concerning Diageo and their errant use of SAP software brings into sharp focus the matter of perspective that is needed when taking intangible purchases and turning them into electronic services.
A £54M penalty is going to offer an eye-watering jab in the pockets of the IT Director, and I’ve no doubt the SAM Manager in Diageo will be reaching for every last possible email where he highlighted the risk of not being consulted on projects, or even being kept at arms’ length in contract negotiations – but the problem potentially goes wider than that.
Let’s suppose that the Project Team did consult with the SAM Manager, and that the procurement division did confer with the SAM Manager; those point-in-time engagements might have been based upon a fiscal-only assessment, or a comparison of what licences are already available in any license pool compared to what is needed, or even a muted deployment compared to the actual roll-out.
These are valid questions to be asking, but clearly the aspect of IT architecture and its relationship to the purchase was not given due weight of attention.
Let’s fast-forward a couple of months to after the point where customers in Diageo were granted the ability to place their own drinks orders on line….
If a standard ELP was produced whereby purchases were compared to installs, then that ELP would have left Diageo believing that they had paid for the SAP software and all was right with the world. Their perspective was based on the financial transaction and not the architectural implementation.
So what’s to be done about this? Perhaps it’s time to go old school – Operations Management calls this Value Chain Analysis; Service Management calls it Service Design:
Start at one end of the technology stack and work your way back. If you were an end user, and you were re-ordering drinks then what technology do you come into contact with to successfully complete your order?
If a pre-existing license doesn’t exist to cover each and every element of that technology stack, then you need to buy one. Even if there is a pre-existing license, double-check that the terms and conditions of that license permits use by an end user. And while you’re at it, don’t be afraid to check the other use cases of people who interact with the technology stack – the converse could be true, you might be paying for licenses that those other users already have.
As I am often fond of saying, perspective is subjective – and we’ve seen a similar experience in the move to virtualization.
Scenario B: Someone in the IT hardware side of life comes up with a good idea of taking servers when their hardware support goes end of life and virtualizing those instances. Savings could be made through consolidated and improved new hardware, reduced energy bills and clearly through not renewing hardware support and maintenance…
But hang on, in our rush to virtualize did we check to see that the existing on-premise software could be virtualized from a licensing point of view? Have we in fact created a larger liability for our company than the alleged savings made in reducing our physical tin?
So is it time to rewrite the ELP? I don’t think we can ring the death-knell on ELPs just yet, but I think the demand for improved and qualified reporting around IT architectures and Services is going to be the next benchmark by which we review SAM suites.
Should SAM be wrestling control of the CMDB away from Service Management? For some parallel thinking, perhaps think about software-tagging your APIs. More of which can be read about in our whitepaper: “Using SAM to create and maintain your CMDB.”
