IT Editorial

Understanding and being able to effectively manage the business drivers which determine a company’s software portfolio is an invaluable best practice for software asset management teams. Having the ability to prioritize business drivers and manage them, permits companies to be able to manage and reduce their cost structures. Yet, understanding business drivers requires the implementation of a process in order to produce the greatest impact on software costs.

Those companies that have achieved “best in class” status for software usage and pricing follow this process and are seeing the greatest benefit. Since software costs per MIP are the easiest benchmark for management to understand, it will be wise to have an accurate cost per MIP value before initiating this process.

It is important to mention that going through this process is not going to be a “once and done” endeavor. Depending on your business drivers, the process may need to be initiated as frequently as once per year. That said, for companies whose business drivers may seem stable, using this process every two to three years will also have benefit – whether financial or operational.

Business Drivers Are the Key to Managing IT Software Costs
Gone are the days when IT organizations can spend money on technology for technology sake. More and more, CIOs are accountable for not only their bottom line, but indeed the results of the company. A good way to do this is by managing the IT budget by tying growth and spending to specific drivers.

For example, an insurance company may tie capacity upgrades to claims or policies. An airline may tie software contract costs to passenger miles flown. A bank may tie the IT budget to deposits. A retail organization may want to tie lower unit costs to rising revenue, instilling in management the idea that efficiency comes with growth. Whatever the chosen driver, it must make sense from an expense/revenue perspective. For instance, the number of employees in an organization should never be a driver in and of itself.

When a driver is chosen, management must be diligent in managing to that set of drivers. Drivers must stand the test of time since they will likely be tied into hardware and software contracts.

 

Understanding Capacity Planning
The SAM team should begin by thoroughly identifying what factors are driving or reducing capacity. Is capacity being driven by customers? Has the competition made changes? Are parts of capacity being driven by a mandate from management?

Certainly, if capacity is growing, the team will want to have a thorough understanding of the source of that growth. Growth for example, may be coming from a recent acquisition, new applications, clients or even latent demand – demand that is not fully known or anticipated until the service/application becomes available.

It will be important to document the various factors that are driving capacity and future plans for capacity.

Understand Software Inventory
It is important to fully understand the existing software inventory before examining software usage. Collect all software inventory in such a way that it can be easily catalogued by vendor, location and the line of business that it supports.

Once catalogued (in Excel, Access or some other database tool), the inventory should be easily sorted by vendor, location or business line it supports. As additional information is added to this catalog, the more valuable it will become.

Match Software Inventory to Business Drivers
From the SAM team’s analysis of capacity planning, they should now be able to match specific items in the software inventory to the factors driving capacity and this information should now be included in the software inventory database.

If there are business drivers that remain unclear or their future uncertain, the SAM team will want to make a decision to further research or move forward with this process. Again, this is a process that should be run through again in the future. So, agreeing to proceed is not necessarily a bad thing.

It is wise, at this point, to implement a monitoring tool to support capacity changes or growth. Begin by identifying which software items need support and which items do not. This monitoring tool should have an inter-relationship with the software inventory database that’s been created.

The result of matching a software inventory to business drivers will create a Gap Analysis of those drivers and needs that are not being met by the current inventory. This exercise builds a tool (document) that shows what needs have not been met and whether an overlap exists.

Understand Depth of Software Usage
At this stage of the process, the SAM team should arrange a brainstorming session to consider the following:

Without any constraints, knowing both existing capacity and needed capacity, what else is needed and how should the software configuration change?

Identify the needs that are currently not being met and document them. This stage of the process should provide the team with a great understanding of current software usage as well as an opportunity for new ideas to arise from the discussion.

Know Whether Needs are Being Met by Existing Inventory
Having documented the needs that are not currently being met, the team should now match those needs to existing or available inventory where possible.

The SAM team should perform a Gap Analysis to understand what needs can be filled by other software and whether acquisitions need to be made. Business needs tied to business drivers tied to software will provide the structure required to manage costs with business drivers.

Identify Inventory that can be Removed
Initially, the team will want to identify and remove software items that are functionally redundant or are no longer being used. Since there are often thousands of software line items to be reviewed, it may be helpful to have an outside service conduct this detailed analysis for the SAM team.

Once completed, the SAM team will need to identify what software items, from a product perspective, can be eliminated or minimized. This will be easier to do now that the team has an understanding of capacity, business drivers and software needs.

Next, the SAM team will want to identify what software items, from a capacity perspective, can be eliminated or minimized. Again, this is an easier step of the process given the research and documentation previously completed.

Identify Core Products
With a thorough understanding of the business drivers, it will be helpful at this stage to prioritize them by importance.

Then, within your software inventory catalog, identify those products that are vital to the business drivers. Label those items in your inventory so it is known that they are required. A technique can be used to identify inventory as “Must Have,” “Should Have” or “Nice to Have.” From this analysis, a list of steps can be created to tie software to the business drivers that require it.

Map Software Inventory to Business Drivers
Previously, you matched basic business drivers to your software inventory. Now that changes have been made to the software inventory and business drivers may have become clearer, it is important to review this information.
Specific business needs should be clearly associated with software inventory.

In this “mapping phase,” which should be more detailed, the SAM team will want to compare business requirements and the priorities which were previously given to each.

The last part of this stage is for the team to have a good understanding of the metric, “MIPS-based pricing.” Most software manufacturers base their pricing on total MIPS used. Since this metric is often unfair and illogical, the team will want to read every white paper they can get their hands on to fully understand the vendors’ logic – or lack thereof.

Evaluate Business-based Pricing as Option to MIPS-based Pricing
Those companies that are “best in class” for software usage and pricing have gone through the process of understanding their business drivers and prioritized their importance. Having an understanding of what you need and what you don’t need, gives SAM teams a great deal of leverage with the software vendors.

More importantly, the SAM team can develop logic around the value of their software based on their business drivers and use this logic to explain why MIPS-based pricing is unfair or illogical. For example, the addition of one new application, unrelated to the vendor’s proposed pricing, may increase MIPS. Should that new application affect your pricing from a different vendor?

There are numerous marketplace examples to help the team understand the importance of the metric the software vendor uses to determine pricing.

For example, one vendor wanted to charge a transportation company by revenue from passenger miles. So, rather than charging by real business needs, the vendor wanted payment for their software based on financial performance – a commission, so to speak.

Another vendor wanted to charge insurance companies by means of claims-based pricing for their software. If claims were up during a certain period, the insurance company would be charged more. The charge should have been based on a revenue producing activity, not an expense related activity.

Pricing should be based on real drivers (needs) instead of artificial drivers like MIPS.

Manage the Drivers that Determine Pricing
Depending on the circumstances of which business drivers are most important, the SAM team will need to find a way to manage all the business drivers.

For example, certain drivers may be seasonal. Other drivers may only exist during a transition period, like an acquisition or a merger.

When the team can manage business drivers, the team can manage the pricing they receive.

Re-negotiate with Vendors
The SAM team can now effectively demonstrate what is needed, when it is needed, where it is needed, what is not needed, when it isn’t needed and where it is not needed. This knowledge empowers the team to pull vendors away from the MIPS-based pricing logic that they typically rely upon.

If it has not already been added, the company’s software inventory catalog should have dates for software license expiration. The catalog, now a database, should also provide alerts to license expiration well in advance of their due dates. This allows the SAM team the time necessary to re-negotiate with the vendor. For some vendors, a full year is not unreasonable in order to have time to build a replacement or negotiation strategy.

Ongoing Driver Management
The SAM team will want to identify specific times to re-evaluate drivers and re-prioritize them. Certainly, some business drivers may disappear altogether or be replaced by completely new business drivers. These drivers, and the team’s understanding of them, play an important role in being able to control software expenses when its time to re-negotiate with vendors.

Benchmark Your Performance with Others
Just as data centers track the costs of new hardware by benchmarking it against the prices offered by resellers of used hardware, the SAM team must have an understanding of the pricing that others are receiving for the very same software.

Several members of the SAM team have probably developed a large sphere of influence and have peers that they can speak to at other companies for examples of their cost structures. When the team is able to compare the pricing it has received with other data centers of similar size, data centers with similar business drivers, or direct competitors, the team is able to tabulate a successful benchmark. This benchmark gives the SAM team an understanding of how well they have performed and whether the pricing they have received is as good as they believe it to be.

If the Benchmark is Unfavorable, Start Over
While the SAM team has probably generated savings for the company, the benchmark helps them to fully understand the additional savings that are available to them.

By going back to the beginning of the process may seem a burden, the root of identifying savings is by having a thorough understanding of current, future and perceived business drivers – and then being able to manage them.

At Minimum, Benchmark Every One-Two Years
When the frequency at which software items are added, and often those items are new software, the need to match those new items to a business driver becomes apparent. Additionally, regularly checking inventory for duplicate items or functionally redundant items becomes a quick and easy way to immediately reduce costs.

Yet, conducting a benchmark for software pricing regularly helps the SAM team know whether their pricing is consistent with what others are receiving in the marketplace for the very same software serving the same business drivers. Regular benchmarks will drive the SAM team to push for new agreements with software vendors.

A benchmark of the team’s software pricing with industry peers will allow the company to maintain its competitive edge and manage software cost structures with those companies that are “best in class” in software asset management.

Conclusion
Building a budget based on business drivers provides a built-in approval mechanism. As long as management agrees with the financial direction of the business, they also agree to the needs of the IT organization. Tying software costs to business drivers is a subset of this approach. If needs are identified, tied to the business and analyzed along with the software inventory for fit, then a structure for approval of the budget exists. If purchases and upgrades are not tied to the business, then the likely outcome is an uphill battle with management over the needs of IT versus the needs of the business.

SAM teams should insist on being involved in and understand business driver development so that the software budget can participate in the structure that is created when IT software costs are managed with business drivers.

About the Author: Michael Swanson is the President & CEO of ISAM