IT Cost Effectivity Model
The cost-effectiveness model was developed for working, in a structured way, towards a situation where you only pay for the IT resources you actually need. Usually there are four steps to reach this stage. The first step is the analysis of what you pay for. In step 2, the comparison is made with what was originally planned. In step 3, concerns the measured actual use. Finally, step 4, analysis what the customer actually needs.
IT cost effectiveness model
Step 1. What do you pay for
The first step is creating transparency in the current billing by suppliers.
Infrastructure
Especially companies that have outsourced the management and maintenance of the IT infrastructure often have difficulties to determine what they are charged for. Main reason is that often the maintenance of the Configuration Management Database (CMDB) is transferred to the outsourcing partner. If this transfer is not periodically audited and / or contract management is not strong enough, this is the source of high costs and low quality. Examples are:
• There is no clear relationship between service levels and environments because the information provided by the supplier is not sufficiently specific. Unintended result is that for 7×24 support is paid on a test or development environment.
• There are too many items in the CMDB. The contract owner must explicitly communicate the removal of items from the CMDB. Often each individual item in the CMDB can be invoiced by the supplier. If you do not indicate that certain servers or databases must be removed, these items will remain in the charging until the end of times (this problem also occurs frequently in the management of workstations).
• There are too few items in the CMDB. It is also possible that a provider forgets to include items in the CMDB. This has the advantage of lower than expected charging, but has the disadvantage that if an incident happens it becomes much more difficult to find the root cause. This again can cause very large costs.
Application maintenance
Again, in many outsourcing contracts a mega-deal is achieved by procurement for a fixed price contract covering both application maintenance and application development. A fixed price deal at one stage can be very beneficial, but has major disadvantages in times of contraction. A fixed price contract has insufficient information on the activities of the supplier for the different activities. It is important to ensure that contracts consists specific information regarding reporting of hours and activities and writing and ownership of handbooks. This is necessary information contract renewals and/or supplier switches. In a shrinking and rapidly evolving environment it can be much more beneficial in the long term to have more variable elements in the outsourcing contracts. Initially this would lead to higher costs, but in the longer term great benefits can be realized as these contracts are much more scalable (and thus faster and cheaper).
Step 2. What was originally planned
The second step is to see what was originally planned for the application.
Infrastructure
Prior to initiating the development and / or installing an application often a design is made by IT architects. This design contains data regarding the use of environments, required computing power, databases, platforms and connections with other applications. This is the basis for the hardware being made available for the application. When a new application is being developed the project often needs additional hardware and / or databases to speed up programming and testing. After completion of the project this additional infrastructure is often not cleaned up.
Application maintenance
Many companies have IT business cases for new applications. These business cases consist of a number of expectations regarding the recurring costs. Linking recurring costs to the original business case often provides much insight. Also the availability of more technical information can lead to additional savings. For example, if customization of an application is far more than expected, recurring costs will increase. Rewarding the application maintenance party for the reduction of customization in the maintenance contract may in the longer term, have a large positive financial impact on recurring costs.
Step 3. What is actually used
The third step is to analyse usage data. The planned use and actual use are often two completely different worlds.
Infrastructure
The architecture of an application assumes certain basic principles for use. This refers to numbers of users, number of transactions, the amount of data to be stored, etc. In the design of the infrastructure estimation are made with large safety margins. This means that measurements may show that over half of the available computing power is not used or that the volume of allocated terabytes storage vs the actual used storage are far apart. Measurements are the basis vor rescaling the infrastructure and thus reduce costs.
Application maintenance
For application it is basically the same story as above. Yet the variance is much greater here. Depending on the culture of the organization one can see that in one organization, the number of users (and thus the required number of licenses) is overestimated, while in the other organization conservative estimates are used. In one case, this means that a too high annual license fee is paid, whereas in the other company too little too little is paid and incompliancy is sword of Damocles.
In addition, application maintenance contracts often do not distinguish between the actual maintenance tasks and changes. Also, in maintenance contracts there is mostly no attention for the relationships between problems, incidents and maintenance costs. Analysis shows that when the number of incidents decreases the amount of maintenance needed decreases. The two main causes of incidents are changes/projects and poorly trained key users. By paying attention to the right variables the cost of maintenance can be reduced considerably. In the most extreme case of a well functioning agile team, you could say that the application maintenance is an obsolete activity.
Step 4. What is needed
The fourth step involves the analysis of the functionality in the application landscape. An application is often purchased for a reason, but often provides more functionality than what it was purchased for.
Infrastructure
Within the infrastructure there is often no active policy for cleaning and archiving data. In accordance with the public laws some data must be stored for long periods. However, users do not need this information for their daily work. Archiving these data can create significant cost savings, as it reduces the system load (search queries are shorter because the database is smaller) and will lead to reduction of SAN consumption.
Application maintenance
Experience has learned that especially in companies engaged in mergers and acquisitions it often happens that there are several applications in the landscape which have more or less the same functionality. Mapping of required functionality on the functionality available in this case can lead to remarkable results. A smart look on functionality can easily be the driver to turn off a large number of applications. An additional advantage is that when developing BI systems fewer applications need to be made accessible n the BI system. This both saves money and shortens the “time-to-market”.
Linking the information from the “cost effectiveness model” to that of the “IT added value model” has additional advantages. The combination of the information creates transparency in the cost of the functionality used (this may lead to reconsidering investment decisions or disinvestment decisions) It also offers the user more options to balance between higher performance at higher cost and lower performance at lower cost. More information on service levels will follow in future.