When signing up for an outsourcing or service integration and management (SIAM)-based deal, one thing that companies frequently fail to think about is the invoicing data they require as the service recipient organization. This information is very valuable, and needed to actively manage the supplier over time.
Hopefully this blog, written based around real-world situations, will help you to understand why and also what you should do.
Writing a SIAM invitation to tender with this in mind
As one of my clients started to write up an invitation to tender, a key requirement was for the responsible IT service management (ITSM) team to define how they would manage the future outsourcing partner (apart from managing the obvious service level agreements (SLAs)).
To help, I shared a personal observation with them. One that I have concluded during my time as an outsourcing and SIAM implementation consultant – that outsourcing customers tend to monitor service levels in detail, but pay little attention to the detail of the invoice received at the end of the month.
Based on this observation, a longer discussion was had with my customer’s service portfolio manager, and we pondered as to whether there was a way to change this approach to invoice handling and cost monitoring.
The result was that – based on the existing service catalog, an IT service-usage warehouse, and a well-established service owner and service manager organization – we proposed to the future SIAM team that they added a few more requirements into the invitation for tender.
So, what did we add?
Firstly, we asked for a data stream that had to be delivered by the outsourcing company before their invoice was sent to my client.
A second requirement was that the outsourcing partner could only submit an invoice after the SIAM team had okayed the data sent in the data stream.
So now you are probably wondering what we needed it for.
Why we wanted the data
Our initial idea was to have an extended SIAM supplier service catalog with a volume count per catalog entry. This would allow us to check the invoices simply by comparing the configuration management database (CMDB) counts with the counts charged. We thought that this would do the trick, but when we checked the service resource units intended to be ordered from the outsourcing supplier and found that we would need more information.
In the end, we decided to have the supplier deliver us not only the configuration item (CI) ID, CI nme, and the service it relates to but also some more costing and charging information such as virtual CPUs, memory size, the user ID whenever the resource unit relates to a single individual. With hindsight, we could have left it as just a set of identifiers, but we didn’t know what would work at the time.
Empowering SIAM service owners
During the transition project, and then well into the future mode of operation of this outsourcing deal, we started to empower the service owners and service managers. First, we delivered a reporting platform that allowed a service owner to see their service and all the related resource units delivered by the outsourcing organization. This had a tremendous effect on the data quality the supplier was required to deliver. And with the initial invoices we found that the data was inaccurate – resource units not linked up to the right service, wrong volume information, and missing units.
At the same time, we initiated a development to automate some consistency and calculation checks on the data received (from the outsourcing partner) every month. These checks made sure that the SIAM supplier didn’t have any calculation errors in their invoice. And this data has also been valuable for cost taking and forecasting reports on a per-service basis, with service owners given a projection of their costs for the full year. Such that they can check, every month, if their budget for a given service will last until the end of the financial year.
Mass validation of the outsourcer’s invoice
When it comes to checking if a given service is charged for correctly, the judgement and knowledge of a service owner or managers are usually good. But when it comes to checking and verifying mass data – such as email accounts in an international organization – service owners and managers will just give up. This is the point where technology needs to step in to help.
So, we decided to implement automated checks for this mass data. And checking email accounts against Identity and Access Management System (IAMS) data has been extremely successful. Now the customer is in the position to validate email and other personal account related charges in minutes – and they find discrepancies every month.
Another very valuable check has been to search for inconsistent resource unit usage, e.g. memory extensions without a related server, charges for disk space without a relationship to a database or a server, etc. Sure, SIAM service owners can manually detect such deficiencies but why have them search for these when we can automate the search and have their time used for managing the service and not the invoicing quality?
So, what did we achieve?
When looking at the data quality today we can see a massive improvement over time, given that the service owners and managers can today see every resource unit to be charged for before they sign off the invoice. This has already paid back, as adaptations to the infrastructure based on demand changes have been correctly reflected in the next invoice (rather than delayed or completely missed).
When combined with the trending and forecasting reports, budget issues have become visible much earlier and are therefore simpler to manage.
Finally, the customer has realized direct savings over the life of the SIAM service contract by immediately removing resource units from the invoice where they are no longer in use, i.e. no longer paying for phantom services and users that were caused by administrative inefficiencies.
So, what is the customer going to do next? The next ideas are more analytical – to manage the scope and granularity of the provider service catalog. I’ll cover this in my next blog.