Showing posts with label APPLICATION. Show all posts
Showing posts with label APPLICATION. Show all posts

CUSTOM APPLICATION DEVELOPMENT



Prototyping and Development Tools

Continually evaluate your set of development tools to ensure you have a complete up-to-date tool kit for application development that meets your needs. Having the right stack of tools significantly decreases the cost and time of development and support. This includes not only the development language but also other areas such as proper prototyping, source code management, debugging, testing, stress testing, and documentation tools. One company looked at their development tool stack in the areas of presentation layer, application server, web server, and rules engine. Evaluate and select your development tool set just as you would other software by identifying the requirements, establishing the selection criteria, and reviewing the options.

Agile Development

As compared to traditional waterfall systems development, agile software development methodologies gets you faster results with less cost and effort. There are many variations of agile development methodologies, such as Extreme Programming (XP), Scrum, Crystal Clear, Feature-Driven Development, and Lean Software Development. Concepts used in agile development vary, but usually include teamwork, regular communication, implementation in small increments, short time frames, and iterations. This type of development will reduce risks and costs as you are able to find errors earlier in the process and complete changes quicker.
Top Tip: Agile development methodology

"We changed from a traditional waterfall development methodology to an agile methodology using SCRUM. In doing so, we were able to take out a layer of management and significantly reduce costs, while also increasing value through better execution. This realizes the benefits of a small IT department in a large shop."
—Mike Degeneffe
Ceridian

Open Source

Open source software has had a significant impact on the software industry. Open source is not free like many think. Open source vendors charge for maintenance and support, but it is significantly less expensive than standard software. Many development projects mix open source with internal code to shorten development time and reduce costs. Open source software is typically modular so components are easily integrated, built for reuse in multiple applications, usually standards-based with efficient use of code, and transparent with its own source code. Open source avoids wasting time reinventing the wheel by using hundreds of thousands of components available for reuse on the Internet. However, open source introduces challenges to managing, such as license obligations, finding the best software for your needs, security vulnerabilities, scalability, maintenance, and version proliferation. Keep in mind that you do not realize cost savings with open source until you are able to replace or forgo other more expensive options as many companies are using open source in addition to other software. Also, do not forget to consider if you must increase resources to support open source software.

Service Oriented Architecture

Service Oriented Architecture (SOA) is an architectural paradigm that allows you to build applications with reusable components, which is similar to building blocks.
It is highly interoperable, loosely coupled, and encapsulated units of work that link or combine resources on demand. It provides a flexible application architecture that is easier, faster, and less expensive to change. Like any new approach, it is a major change, a challenge to get started, and is not a fix-all. However, evaluate using this architecture style if you have significant areas of custom development because the total cost of ownership can be less.

Mixed Development

Many companies are finding significant cost reduction by mixing development as necessary and using pieces of open source, third-party code, SOA components, outsource provided, and custom code. For example, when developing applications for online ordering, companies will frequently use a service for all the handling of credit card information. Payment Card Industry compliance requirements are very expensive if a company chooses to process and store credit card information internally rather than using an outsource provider. Another example is a company that liked salesforce.com but found it was too expensive for its budget and needs. They chose to buy the force.com development tool at a fraction of the cost of sales-force.com to develop the pieces of the system they needed.

Revenue Generation

Look at getting royalties from your custom software developments. If you have written custom add-ons to software packages, consider selling the software back to the vendor or other companies. Consider the possibility that IT can generate revenue. The one caution is that you do not want your IT department to become a software vendor that distracts from providing the business with a unique competitive advantage. This also diminishes your competitive advantage if your competitors are able to purchase the same functionality. One example is a company that wrote an extensive product configurator to handle a complex product structure. The vendor was interested in the enhancement as part of its standard product as other customers had requested the capability. The company was able to sell it back to the vendor in exchange for additional software licenses and modules. The enhancement became part of the vendor's standard offering that also helped the company maintain and enhance the modification without the high internal cost of custom software.

APPLICATION MAINTENANCE AND SUPPORT AGREEMENTS



Maintenance is comprised of regular upgrades and fixes to the software while support is the ability to get help for questions or problems. On-going maintenance and support contracts for applications cost an organization a considerable amount of money year after year. Depending on your needs and the vendor, you buy maintenance and support separately or bundled together. Typically, software maintenance costs range 11 to 15 percent of the purchase price, and support cost is approximately 7 percent of the purchase price on an annual basis for a total of 18 to 22 percent per year with potential annual increases. Therefore, you are essentially paying the entire cost of the software every four to five years. For obvious reasons, this on-going revenue stream is very important to software vendors. This section outlines specific tactics for reducing the costs of vendor maintenance and support.

Annual Cost

It is well worth your time and effort to try to negotiate the annual maintenance and support costs as much as you are able. In theory, these costs are even more important than the software license fees, and they often go by without even a discussion or negotiation. Maintenance fees are based on your negotiated purchase price, not the list price of the software. Often, you will be able to reduce a 22 or 25 percent total maintenance and support fee down to 18 percent per year. Some vendors are more likely to negotiate than others but the major ERP vendors (Oracle, SAP, and Microsoft) often do not budge at all on maintenance costs.
Top Tip: Consider extending term of contract

"To get good pricing in vendor negotiations, consider extending the term of the deal from a 1-year to 3-year contract for possible pricing reductions."
—Randy Witt
Restaurant Technologies

For some vendors, maintenance revenue accounts for 50 percent of total revenue so this is a very important revenue stream from the vendor's perspective. Work with user groups to resist maintenance fee increases. Get guarantees from the vendor for the percent reinvested in product support and enhancements in future releases.
Negotiate the first year maintenance as part of the purchase agreement. Include a ramp-up option if you believe full implementation will take a significant amount of time. Only pay the percent on licenses you purchased or right-sized, not future quantities or amounts. You are also able to negotiate quarterly payments that more closely relate to how you consume the value rather than prepaid annual fees. This also provides more options and flexibility on when to stop maintenance costs and when they hit your budget. If it is possible, time the maintenance and support costs to be due at or near the go-live date, not prior to the implementation date as you typically have partners or qualified consultants involved through the implementation. However, this is only possible with a privately held vendor as public companies are subject to revenue recognition rules so it may take the form of an additional software discount for the amount waived. Other licenses purchased after the initial implementation would be subject to immediate maintenance and support fees prorated to the next quarter.
Know how you are using the software products and negotiate maintenance changes accordingly. As mentioned, know the type of users that you have and separate employees into groups so that they have only the software they are using rather than paying the same fee for all employees. Reduce the number of seats for which you pay maintenance to the precise number needed to receive value.
Beware of the statement that software maintenance can increase up to a set percent for a maximum per year. Make sure you have terms that limit the rate of maintenance fee increases each year, as well as provisions to stop paying maintenance and support fees without any penalty or fees. Do not link license transactions to maintenance transactions. You are often able to negotiate lower rates for longer-term contracts. Specify that they must publish any changes in rates 120 days prior to the contract change date.
If you consider dropping maintenance, get an agreement on the price at which you can subscribe later if you are able. At times, particularly in the first 12 months of a warranty period, you are able to negotiate so that the vendor supplies fixes at no charge even if you are off maintenance. However, after a certain period, the vendor integrates fixes in new releases rather than old software so this will not be beneficial over the long term. Verify that your software license is perpetual and does not terminate if maintenance is not renewed.
Consider renegotiating maintenance fees. Particularly in difficult economic times, application vendors rely on the steady stream of maintenance revenue. When faced with the prospect of losing a maintenance and support customer, a vendor might consider renegotiating the agreement altogether. Even the larger, more inflexible application vendors sometimes circumvent their own policies by having a customer terminate and then again license the software at a much lower price to reduce the on-going annual maintenance fees.

Support Options

One option for the support contract is to look at how much you have used support in the past and the value it has provided the organization. It is frightening to drop support as the vendor is your lifeline in the event of application problems. However, if the application has been fairly stable in the past, your business needs are relatively stable, and you have had the software for a number of years, consider dropping the support agreement and switching to a pay per hour or pay per incident model. This could result in significant immediate savings. However, it might be useful to negotiate and have in the contract an established price should you decide to go back on support in the future, although many vendors are reluctant to do this. You should also investigate the possibility of receiving support from a third party provider.
Top Tip: Negotiate support and maintenance contracts

"The first place to save is in maintenance contracts. I tell the vendors that I need 20% or they will lose the business. Negotiate flat increases if you re-up. If you don't ask, you don't get it. There are alternatives, and in some cases you may be OK dropping maintenance and going with time and materials support. We saved 60% by going with a third-party alternative for mainframe support and have a higher service level."
—Dave Brady
Starkey Laboratories

Support Service Level

Be sure to negotiate financial performance penalties if the vendor does not meet agreed upon and reasonable service levels. Specify standards for response and resolution of different categories of issues in a service level agreement. The tactics for support contracts apply not only to the initial support agreement purchase, but if you track support activity, you are able to leverage the information as a way to obtain relief on costs if the quality of support provided has been an issue.
In the strategy on reducing service levels, match the service level to the business needs and do not overbuy. Vendors typically have different levels of service offering different responses, escalation, access to resources, hours of support, etc. Work with the business to identify the level that meets the business needs given the various costs. Consider downgrading the support level. Many vendors offer multiple levels of support from which to choose. Re-evaluate whether you need premium (i.e., 24/7/365) support based on how stable the application runs and the consequences of unplanned downtime. Dropping to a less expensive support plan can save a company up to 20 percent of the annual expense.

Cost-Justify Upgrades

Do not blindly upgrade just because the software vendor is your strategic partner. Any application software upgrade is a major expense and business disruption. Implementing a new release takes 10 to 50 percent of the original implementation effort, depending upon the degree of change as well as the number of interfaces and customizations that you need to redo and test. Evaluate and justify any upgrade based on the individual costs and benefits just like any other project.
Continue to stay abreast of vendor changes in direction, and re-evaluate your upgrade options every three to five years. When considering upgrades, plan the timing after considering your budget and project bandwidth, the vendor's product strategy plans, the vendors installed base, and your specific need for the business functionality provided in new release. Try to steer away from orphaned (through acquisition or vendor strategy direction) or old products, or releases that are likely to receive smaller investments in the future for new features and releases.
Although you should cost-justify upgrades and occasionally validate the direction to stay with a vendor, it does not mean that you should not implement upgrades. Rather, make sure you understand and communicate the business value of each upgrade. If you go beyond skipping every other upgrade, you are likely to fall victim to the pay-it-now or pay-it-and-a-lot-more-later syndrome because the bigger the gap between the production version and the upgrade version, the more difficult the upgrade project. In addition, staying on an old version puts a company at risk due to a lack of support and technical expertise from the vendor.

PURCHASING APPLICATION SOFTWARE LICENSES



Initial software license costs are a huge expense for a company. Many companies have paid more than they should for software license costs due to poor negotiating, lack of awareness, incorrect sizing, or poor contract management. When purchasing software, companies are in the driver's seat, yet they often sign a vendor's standard contract that leaves them with no leverage or control. This section outlines specific tactics that could save you a considerable amount of money on initial and future software costs.

Negotiation Strategy

There is much at stake with the negotiation of application licenses. Be sure you begin the negotiation process by developing a clear negotiation strategy. Identify your targets. For example, one company starts vendor discussions by saying they want three-thirds off. Although vendors laugh at this as a joke, it does set the tone for the negotiations. Prioritize your needs. Never concede on a term or condition without trading for something else. Also, document the negotiation process and the results of discussions as it is easy to forget who agreed to what



Start Negotiations Early

Do not wait until you have selected a finalist to start negotiating the price and terms. After eliminating competitors, the only valid option left is to do nothing. Keeping competing products in the evaluation strengthens your negotiation position.

Discounts

Do not be afraid to negotiate aggressively on software prices. As any seasoned CIO realizes, initially quoted prices are not the bottom price. Actual prices paid for software licenses for any given product vary greatly. In competitive software evaluations, vendors have lowered prices 40 to 75 percent, and companies have even received discounts up to 90 percent off list. Of course, each type of software has a different discount structure depending on its marketplace and competitive situation at the time. If you lower your license fee, your lifetime percentage maintenance fees are lower.
Top Tip: Hire experienced help for negotiating

"The best advice for renegotiating with vendors is to not do it yourself. Hire a company that does contract negotiation as a core competency. We engaged a company that gets a portion of the savings so there is no up-front investment."
—VP IT
Energy Company

Top Tip: Manage the contracts

"We manage the contracts rather than the contracts managing us. We try not to sign vendor's contracts and terms, but use our own. We try to have contracts that scale for good times and bad."
—Mark Brewer
Seagate

Use negotiating advantages such as the timing of the vendor's quarter or year-end, the desire for competitive positioning, publicity, and the desire for references in an industry or geography. For example, Oracle's fiscal year ends May 31 so buyers have the highest advantage and best prices as they approach the fourth quarter of Oracle's fiscal year. Some vendor's revenue cycle peaks in the fourth quarter due to increased year-end aggressiveness and the push to meet sales quotas.
Be sure to ask for the published list of prices rather than taking a vendor's word on the applied discounts. The vendor's desire for your business makes a huge difference. For example, you have minimal leverage with Microsoft when it comes to MS Office pricing and terms, but you have more leverage when it comes to your choice of all the other software categories in which it has to compete heavily.
In addition to negotiating price reductions, consider discounts for business continuity licenses, incentives for new licenses, free or discounted training, free or discounted consulting, and vendor-led financing. Consider negotiating add-on services when discussing the initial software contract as you have more leverage. For example, if you need the vendor to make critical custom software modifications or you want a support agreement, you will have much more bargaining power if you negotiate when the software licenses are negotiated.
It is also well worth the money to employ a consultant specializing in contract negotiations as they are aware of current vendor negotiating practices and prices that the vendor has agreed to with other customers. It can save the cost of services plus a tremendous amount of money through the life of the software.

License Timing

Purchase software that aligns with your actual needs relative to timing. Do not pay for software years before you will use the software in production. Consider your implementation phases and timing. Until you are using the software for production transactions, the software is not of value to your company.
Although it is not always possible, have the agreed-upon price written in the contract for the scheduled implementation time frame. For example, one company purchased complete ERP licenses and began the implementation project; however, it took two years to implement the software. They paid for two years for users who did not use the software when they could have saved a tremendous amount of money by purchasing only the necessary licenses when they needed them and the remainder of licenses coordinated at the time of implementation.
Top Tip: Tiered pricing for additional users

"When negotiating with a vendor, you will typically get better rates at the time of initial purchase. Look at tiered pricing for additional users, or enterprise licenses, so you can negotiate up-front rather than later."
—Haseen Alam
Johnson Brothers Liquor Company

Be aware that software is nonrefundable and vendors rarely give refunds for a change in your plans unless you add this provision to the contract. If you delay or cancel the project for any reason, you do not want the vendors holding your cash. As is common with any transaction, when a vendor has the cash, you lose some of your control to get attention and to get problems fixed. Time it to pay for initial software licenses about a month or so before the go-live date with acceptance language that gives you control over whether the software meets the specifications. If you are not able to proceed with the go-live, you do not want the vendor holding license fee money for software that you cannot implement. Be aware that many vendors require a good faith advance payment of 5 to 10 percent, which is normal, and reasonable.

Software Footprint

Only buy the software footprint, modules, business processes, and business functionality that you need at the time. The more precise and accurate you define the software footprint to your needs, the less your costs will be. If you will likely add other modules in the future, build that into the negotiated price and agreement, but do not pay for it until you need it. For example, if you plan to implement Customer Relationship Management (CRM) after you implement ERP, you should negotiate the price of CRM in the agreement to save a significant amount of money rather than negotiating it in the future. However, make sure in the terms that you cover an exchange clause. If down the road you decide you need a different module than CRM, such as Demand Planning, you will be able to exchange it. Not every vendor will consider an exchange clause, but it has saved many companies a significant amount of money. Be aware that vendors often make significant profit by fragmenting or starting small and up selling later, so be sure to have the negotiated future price in the contract.
Top Tip: Right-size cost of annual maintenance

"Validate and right-size the cost of annual maintenance against the needs of the company. We found we were paying for modules never implemented. Consider response time to make sure you are not paying for a greater SLA than you need."
—Trent Buness
3 Wire

Know the precise modules of functionality the vendor includes in its core software. If you do not need some functionality, try to negotiate some modules out, or if you need to pay for it anyway, consider using the functionality in the future. Be aware of middleware or structural components that you need to identify or purchase as well.
Enterprise applications morph over time. New functionality that you need is often bundled or repackaged with modules you already own, but access is limited unless you upgrade to the next version. The result is that you end up repurchasing functionality, unless you take the time to understand how the vendor is repackaging or rebranding its software. Consider breaking apart an offering or negotiating concessions for functionality that you already own. For example, a leading vendor offers over 160 modules to its enterprise software application that are bundled into suites of functionality. One company bought a Work In Process (WIP) module over ten years ago and later needed to increase its capability to manage capacity. Now the vendor packages the capacity module together with other applications in a new suite called Supply Chain. The vendor was happy to offer the new suite and bragged about its capability. However, after drilling down into the functionality within the new Supply Chain module, the company discovered that this new suite actually included WIP. After lengthy discussions with the vendor, the company was able to negotiate out the expenses for this duplicate offering. Understanding the vendors repackaging and rebranding of software functionality was important to saving considerable costs.

User Count

Ensure you have an accurate user count for software licenses. Right size your software purchase for your exact needs. Only purchase software licenses for the number of users you have today. Although most vendors have implemented a named user model in which you provide the number of distinct users, some software vendors or old agreements use the concurrent user license model in which you have a set number of people that are able to access the software at any time. Whether using the named or concurrent model, if you need additional licenses in the future due to projected growth or additional implementations, negotiate that in the contract as it could save a considerable amount of money rather than negotiating in the future. You may be able to negotiate a fixed per-user cost on licenses for some established period like two to three years from the initial implementation go-live date. At a minimum, lock licensing fees for the duration of the implementation project in case additions are necessary. As you would expect, the costs-per-user goes down as the number of users goes up.
The vendor often claims that you have to buy licenses in blocks of five users, but it is preferable to have more control, and the ability to purchase in units of one if necessary. After the fixed cost time frame, the vendor charges what they see fit and switching implemented software is difficult. The vendor has you as a captive audience.
One company purchased 300 licenses of ERP as the company was on an aggressive growth curve. The company did not grow as anticipated, and they paid for excess software license capacity for years rather than right sizing the contract for the right number of users. Be sure you have a trade-in clause and price in the event you buy too many licenses. Although the vendor is often reluctant to give money for trade-in purposes, perhaps they would be receptive to a trade-in for users in other software modules. You have significantly more leverage for adding creative options before the contract is signed.
Be aware that the software vendor is often not supportive of the concept to buy only the amount of licenses you need and when you need it. This is because incentives for the vendor are often based on large up-front payments at the signing of a purchase contract, or vendors may require a certain volume to give you the discounts they have stated. The vendor is often pressured by competitive positioning at critical quarter or year-ends, and they are not able to recognize the revenue on future negotiated licenses. Although the vendors initially resist this approach, it is possible to get agreement, and it saves you a significant amount of money.

Software Compliance

Although you want to minimize costs, always make sure you are compliant relative to any software licenses and user count. Particularly in an economic downturn, some vendors actually increase license audits. Although you might want to save a little in license costs, penalties for insufficient licensing are huge and quickly wipe out any savings you thought you were getting by cutting it short. Fines for software piracy and insufficient licensing can cost up to $250,000 and/or up to five years in jail in addition to bad publicity for the company. Track and manage usage closely to avoid these fines.
Many software distribution tools can provide software usage information. When considering various contract options, always include the cost of administrative overhead and software to comply with the terms of the contract. If there is a unit cost, consider what it is going to cost in labor to track the unit utilization.

User Type and Mix

Ensure the specific type and mix of users on licenses. Many software vendors calculate license fees based upon the type of estimated users. The way that you define users for your organization makes a tremendous difference in your total software license cost. For example, some vendors have different prices for:
  • A full user. A full user is someone who accesses main functions within the software footprint and has defined access tied to job duties.
  • Informational user. An informational user is a user participating in workflow tasks and obtains metrics, information, and reports from the systems.
  • Shop floor transactional user. This type of user does transactions often through bar coding of basic data entry information.
  • Conditional user. These are special users for a particular project.
  • Development user. This is someone in IT that configures the software and manages the database or programs.
  • Nonemployee user. This could be a partner, supplier, customer, or web user access. Do not forget to consider web users as that drives up costs and vendors classify them differently.
  • Interfacing user. An interfacing user accesses the software by using a system that you may interface to the software.
Vendors have the ability to monitor the usage pattern to determine when a user grows from an informational user to a full user. Monitoring and reporting the type of users also helps you recognize the value of the application as it grows over time. If your software agreement only specifies full user licenses, negotiate partial licenses as it substantially reduces costs. Again, if your needs or mix changes in the future relative to type of users, build that into the contract with an agreed-upon price.

Enterprise Licenses

Enterprise agreements are more common for databases and middleware, but they also relate to applications. One example is a large manufacturer that saved a significant amount of software license costs by purchasing a large software footprint. They were concerned that they would need additional modules in the future so they negotiated an enterprise license suite that entitled them to all the software vendors' modules for one price. Vendors typically estimate usage for about three to four years to determine the appropriate price. At the end of the term, many vendors do not recalculate a support number. Typically, customers choose to end the agreement, receive perpetual licenses, and true up.
Enterprise licenses are a good tactic to review as long as you do not overbuy significantly. Be aware of any metrics that the vendor may link to enterprise licenses costs, such as annual revenue. Consider enterprise licenses if you:
  • Do not want to track usage
  • Do not want to buy modules piecemeal
  • Do not want to constantly negotiate contracts with the vendor
  • Anticipate greater usage in the future
  • Want to lock in discounts for expected growth
  • Will likely want to expand the footprint to additional modules in the future
  • Are committed to the vendor for a large portion of your portfolio and are not afraid of locking in with a particular vendor
  • Have a high spend amount (e.g., $3 million)

Application and Process Design

Keep in mind that many vendors define a user as anyone using or accessing the software. Some vendors even require a user license for any interfaced application, in which case you need to document any known interfaces in the contract. However, if your vendor does not count interfacing users or interfacing systems but only direct users of the system, consider using portals or front-end applications to reduce direct users and your license costs. You need to know and understand your software license and terms and operate accordingly. For example, if you base your license on number and type of users, and you are able to decrease the number or type of full users by having infrequent queries going to a data warehouse or front-end system, you can reduce your vendor license costs. If the vendor charges you for interfacing users or applications, carefully consider business process design, roles, and responsibilities to minimize the number of individuals needing the information or application.
If you need to interface the information to subsidiaries or a parent company, ensure they have the right to use the software. Many times, vendors consider access by other organizations a totally new and expensive contract.

Processors, Cores, or Virtual Machines

Be sure to look at your hardware configuration relative to software licenses and consider changes to lower license costs. The price for some software is based on the number of CPU processors or number of core processors. If so, look at reconfiguring your hardware to have a lower processor count. In these cases, often you need to pay for licenses for a warm disaster recovery site as well as cold sites. Make sure you also understand the impact of virtualization on your application licenses. For example, one major vendor requires that if you use a software product in one VMware virtual machine, you must pay license fees as if you had deployed it to all of the cores in that server. The vendor will base your license fee on the number of CPUs in the box and not on the number of virtual machines that you have deployed.

Number of Instances

Be aware of how many copies or instances of the software you need as it costs you a considerable amount of money if you need to buy it in the future. Again, only buy the number you need currently, with clauses for future purchase, if needed. For example, typically you require an instance for testing, development, training, reporting, disaster recovery, and perhaps additional instances for other countries or divisions. Keep in mind that some vendors have flexibility in licenses for testing environments as the environment does not support any operational processes.

Beta Software

If the software product or release is new to market and has a small number of users, negotiate additional discounts to offset your risks. Implementing unproven software is very painful and costs you a tremendous amount of money working with the vendor to solve new software bugs and issues. If you are a beta site, be aware of it, be able to absorb the risk, and possibly be financially remunerated for it in some way. Be sure to include warranty and delivery specifications in the contract terms and conditions. Identify all of your projected costs to determine them for the entire effort.
Top Tip: New product

"At one company, we had a shortage of cash. We worked with a vendor and became a test case for one of their new products. We went to forums and told their story. We were able to secure a new solution at a very low cost. Both of us benefited."
—Randy Witt
Restaurant Technologies

Acquisitions and Divestitures

If you acquire a company or sell a part of your company, be aware that the vendor could charge you with significant software license costs. Typically, licensees cannot resell, reuse, or share the license. Several companies have had to purchase back the software which was an unplanned expense of the acquisition. Know your contract and be aware of the terms. At a minimum, negotiate terms for the transferability of the license to another entity at no cost.

Terms and Conditions

It is well worth your time and money to engage an experienced professional in the negotiation of software license terms and conditions, particularly as this is a significant expense in the event that you overlook critical items. As many CIOs have personally experienced, an oversight in simple terms and conditions can cost a company millions of dollars down the road. Examples of protections or simple terms and conditions that translate to saved money in the future include the following:
  • The software meets specific defined performance and acceptance criteria.
  • If the product is sunset (e.g., no longer supported by the vendor) while you are still using it, outline financial relief, such as five years of maintenance at no charge after the new product is implemented.
  • Include protection for vendor acquisition, merger, or bankruptcy. If this is a mission-critical application, subscribe to source code in escrow to mitigate the risk if the vendor goes out of business. This saves you replacing the software in the future.
  • Include protection for misrepresentation, lack of performance of functionality, or future capability not proven in the sales or demonstration process. Companies often include request for proposal (RFP) responses as part of the contract to warrant the promised functionality. This provides tremendous assurance and warranty and is a strong argument for detailed requirements in an RFP. Some companies also obtain conditions that new releases will not diminish functionality or they will get a refund of the initial buying decision. At a minimum, get proper notice if the vendor no longer supports software, underlying databases, or operating systems.
  • Include protection for damage limitations and warranties.
Top Tip: Two-year extension

"We were able to negotiate with our ERP vendor by adding a two-year extension at the back end. In exchange, we received cash back upfront and reduced rates. Even if it appears your influence is limited, sometimes just asking with the right offer results in significant savings."
—Scott Simerlein
North American
Membership Group, Inc.

Structured Selection Process | APPLICATION PORTFOLIO



When evaluating software packages, you can save a considerable amount of money by doing it correctly and selecting the right tools. It saves you from re-implementing a different tool a few years down the road, which can be a tremendous expense. It is often helpful to engage the assistance of a consultant who uses a structured selection methodology and is experienced in selections and in the particular application area. They are able to save you significantly more than their cost by helping you select the right tool, engaging support throughout the organization, and facilitating negotiation strategies throughout the selection process. However, be cautious about hiring service providers who have implementation resources in one of the reviewed packages as they may bias your selection. Remember, implementing and supporting new software is an expensive proposition, so it is well worth the time and money to make sure it is the right direction before beginning implementation.
The following are tips to include in your selection methodology to reduce overall costs:
  • Make sure you cast the net broad enough. Do not just evaluate the packages that you have heard about or read about in magazines. Seek the help of experts and open your evaluation to additional options such as software-as-a-service (SaaS) and other options covered at the end of this chapter. It is much easier and cheaper to cast the initial net broadly through a long list, and then narrow your search in order to consider all possible candidates and a reason for eliminating each one. The mistake many organizations make is that they start with a relatively short list and end up adding candidates late in the process because vendors pop up with no compelling reason for elimination. Be a thorough and educated buyer.
  • Your first contact with a vendor is not too early to start planting the seeds for the negotiation process. Have a plan and strategy for negotiating the best price. That said, licensing software is nothing like buying a used car. View your vendor as a partner, not a car dealer.
  • Carefully identify your requirements and prioritize the needs from the wants. Educate the users about the possibilities before participating in demos so that users do not discount the software because it does not do it the way they do it today.
  • Clearly identify the business goals and objectives you hope to achieve with the new software in order to align expectations.

APPLICATION PORTFOLIO



Use this same portfolio picture for an analysis of your business applications environment to look for cost savings. The process of identifying application cost savings cannot proceed without a solid understanding of what applications are already in use within the organization, who is using it, where it's being used, for what business purpose, and how much it is currently costing the organization. For significant cost reductions, consider the tactics in this section for changes to the business applications portfolio as shown in Figure 1.
  •  Eliminate unused software
  •  Consolidate redundant applications
  •  Replace applications with high support costs
  •  Consider second-best applications
  •  Standardize application vendors
  •  Consolidate application instances
  •  Standardize development tools
  •  Identify gaps in functionality
  •  Use more functionality
  •  Discontinue source code in escrow
  •  Do an assessment and strategic plan
  •  Consider legacy system renewal
  •  Consider life extension strategy
  •  Consider buy before build strategy
  •  Use a structured selection process
  •  Take an enterprise view
Figure 1: Tactics to get the most from your business applications portfolio

Eliminate Unused Software

It is challenging to reduce costs in the applications area because changes typically take a long time to implement. However, eliminating unused software modules is one of the quick hits that immediately take costs off the budget. Do this by reducing shelf ware. Make sure you are not paying for any unused or unimplemented software. Third-party software inventory and spending audits to validate software licenses frequently find overspending on licenses compared to the frequency of under-licensed software. Retiring unused application software usually results in a reduction in use of supporting infrastructure items, which you then can also eliminate. For example, one company found an application that had never been deployed. This application had 30 communication lines installed but these lines also were never used. Likewise, consider retiring unused modules or excess users of any in-use application to reduce the maintenance costs relative to those modules.

Consolidate Redundant Applications

Review modules that you have purchased as part of an enterprise system that duplicate functionality provided by silo applications. Consider replacing or removing redundant applications that have overlapping functionality in order to reduce costs. For example, recording and reporting employee time is often part of your payroll system. It might also be contained in your human resource system as well as your shop floor control system and project portfolio system. You might also have departmental silo systems to track and report time. In this example, restructuring your applications so you do all time reporting in a single enterprise application will reduce the cost of providing this functionality. Eliminate all use of duplicate functionality in other systems unless there is a compelling argument to do otherwise.
In the case of an organization with multiple geographic sites, look closely at applications that are deployed in different locations as you might find redundant applications that are ideal opportunities for consolidation.

Replace Applications with High Support Costs

Review your maintenance and support costs as well as your full time equivalent (FTE) personnel needed to support each application. Rank the applications by total cost of ownership. Make sure that the business value received from each application is in proper alignment relative to the costs. Review the support costs by application with each business executive to ensure they feel they are getting comparable value. Relative to the other applications, if an application seems costly compared to the business value, work with the business to consider replacing expensive applications with a more cost-effective solution. In some cases, this more cost-effective solution may be a lean or even manual method.
Assess the business applications to ensure they are providing the desired business value. One company did this by working with the IT steering committee to place each application on a grid indicating value and cost as shown in Figure 2 according to the following actions:
  • Applications identified in Grid 1 are high-value applications, funding is a priority, and they are generally maintained as status quo unless expenses must increase for some reason.
  • Applications identified in Grid 2 are also high-value strategic applications, but review them to see if you are able to decrease maintenance costs without negatively affecting value to the business.
  • Applications identified in Grid 3 are lower-value applications considered for consolidation into higher-value applications with a lower priority as they have a relatively low on-going cost.
  • Applications in Grid 4 are immediate candidates to review for consolidation, as the costs are significant relative to the value to the business.

 Figure 2: Application value matrix

Consider Second-Best Applications

When evaluating software options, many organizations implement the best software, best-of-breed, or high-end software. It is like the old saying, "no one ever got fired for going with IBM." In some cases, the second-best software may give you enough functionality to meet the business needs. You may not always need the most high-end software particularly when comparing the price differences. At times, you are able to get 90 percent of the functionality at 60 percent of the cost and that may be sufficient for your needs.

Standardize Application Vendors

If you consolidate the major portion of your application portfolio with one main vendor (e.g., IBM, Microsoft, Oracle, SAP, etc.,) as much as possible, you are able to gain additional discounts due to higher volume purchases, and it will cost less in interfaces and in achieving seamless streamlined processes. Training costs and personnel support costs are also less with a consistent technology stack. On the other hand, be aware that some of your post-purchase leverage is gone with a single vendor approach and a larger footprint has a much higher barrier, or costs, to exit. Therefore, in some instances a series of interfaced niche applications give a company more flexibility and interchangeability, particularly with the use of enterprise architecture and portal technologies.

Consolidate Application Instances

Many large global organizations spend millions of dollars implementing a common Enterprise Resource Planning (ERP) system, but some implement many different application instances to meet the needs of different divisions, locations, or business units. Each separate instance costs additional money for licenses as well as maintenance and support. Whenever possible, try to consolidate application instances into the fewest number for a lower total cost of ownership.

Standardize Development Tools

For both custom development and vendor-supplied packages, standardize on the fewest possible development tools, and classify the ones you retain as primary and special use.Each additional development tool costs the organization money as you need to have trained resources and backup resources that know each language and development tool. Of course, weigh this against the business functionality provided as you do not want to exclude applications that would provide value for the business because they are using a different language.

Identify Gaps in Functionality

As you look at your applications portfolio, contrast it against the business organization and functions. Identify any key missing areas to review for potential benefits from implementing technology. For example, one company did this analysis and found that the company's marketing area did not have automation. The company realized it was because the marketing executive did not have an appreciation of technology and did not drive the need for tools. When looking at the processes in marketing, they found a severe need for improved processes and technology, which, when implemented, resulted in tremendous business benefit.
Give people the tools to foster accountability, efficiency, innovation, and collaboration throughout the organization. Enterprise tools used across the company achieve a significant savings in business costs as opposed to siloed business unit solutions that meet the needs of only one department. One example is implementing a powerful data warehouse and Business Intelligence (BI) system that gets the right information to the right individual faster and cheaper, enabling improved business decisions. Businesses leverage and mine customer data to come up with solutions that allow a business to interact with customers in new ways that drive additional revenue.
Consider using new technology to provide functionality that was not possible in the past. This may help reduce business costs and eliminate other costly IT applications. For example, newer functionality provided with Web 2.0 collaboration products (e.g., blogging, Sharepoint, wikis, and mashups) can be extremely useful.

Use More Functionality

Most companies fail to take full advantage of their enterprise software packages, ignoring important features that drive significant business efficiencies. For example, one retailer created purchase orders to use in planning purchases and shipment timings with its vendors. This resulted in expensive downstream purchase order changes and reconciliations due to subsequent review and feedback from the merchants. When IT instructed the retailer's merchants in the use of purchase requisitions, which was previously an unused function, it significantly reduced time-consuming activities.
Considering both the full range of functionality and potential modules, industry estimates say that companies use 25 percent of the functionality that is available in packages. Work with the business managers and staff at all levels to review additional functionality that you currently own to see if they would benefit from using additional features. Of course, as a company uses additional functionality in existing software, the cost-per-functionality decreases. Payback from software implementations multiplies as the software penetrates more broadly and deeply into the organization.
Also, look at using more of what you own relative to hardware. For example, one company outsourced payroll as they initially did not have the capability to operate it independently. After implementing a secure data center for other needs, they looked at bringing payroll back in-house by using existing capacity, which saved considerable money.

Discontinuing Source Code in Escrow

Some companies regularly subscribe to source code in escrow whenever they license application software. Granted, this is a relatively nominal cost compared to the expense of having to replace an unsupported application. However, all of these nominal costs add up to a sizeable annual expense when a company subscribes to dozens of escrow agreements. Recognize that many source code escrow agreements are structured such that the only release event is where the vendor goes out of business, which is extremely uncommon. Rarely do vendors release source code without a very expensive and heated legal fight. When push comes to shove, most companies choose to continue operating their relatively stable unsupported applications rather than go to the expense of getting the source code and maintaining it internally. Subscribe to source code escrow only when the application is mission-critical and worth spending the additional tens of thousands of dollars required to get the source code released.

More?