In our last post, we talked about how you defined lifetime total cost of ownership models and what the key cost components of each major software delivery model were, reviewed below. In today’s post, we discuss how you will usually calculate each of the cost components.

Based on these model requirements, you can build a spreadsheet that allows you to calculate and capture each cost component using all of the information available to you. These spreadsheets can then be modified during negotiations to capture the true total cost of ownership over the projected lifetime to understand the true cost of each proposal put before you, or your expert negotiator. Each of the costs above can be calculated as follows:

• License Cost
  The license cost will either be a fixed price or an annual fee. In the first case, it’s a simple input, and in the second case, it’s the annual license fee times the number of years you intend to use the solution. (It’s a good practice to also calculate the costs for a range of years in multiple columns. If you think you’ll use the application for 10 years, calculate values for at least an 8 year and a 12 year ownership term as well to understand how costs change over time.)
• Maintenance and Support Cost
  This is usually a percentage of the license cost each year. As such, it’s easily modeled as a percentage of the license cost multiplied by the number of years you intend to use the solution.
• Dedicated Server Costs
  You’ll likely have to add servers to support your new acquisition. The cost will be the number of new servers required times the expected server cost. (Note that tough times will get you great deals on hardware using a reverse auction.)
• Supporting Software Costs
  Many enterprise applications require database licenses and application server licenses (and some will require middleware licenses as well). These applications generally have license fees, maintenance fees, and per CPU and/or per seat fees. If you are lucky enough to already be licensing the supporting software, the cost will just be the costs to support the new application, calculated either as the number of new CPUs times the per CPU cost or the number of new seats times annual seat cost. If not, you’ll have to add in the license costs and the annual maintenance costs of the supporting applications as well.
• Implementation & Customization Costs
  In the world of enterprise software, there really is no such thing as “it works out of the box”. At the very least you have to load your data. Usually, you’ll have to bring in a hired gun to install it, customize it, and get it working efficiently on your systems. If you’re lucky, this will be a reasonable fixed fee. If not, it will be a by-the-hour fee (and you’ll need to ask current/past customers to get an idea of the number of person-hours that will be required.)
• Integration Costs
  If you need your new system to talk to, or work seamlessly with, other systems, you’ll likely have to do some integration. You’ll probably have to consult with a third party integrator to get an idea of project size, which will determine what will likely be a day rate based quote.
• Training Costs
  Although it’s getting better, most enterprise software is still a long way from “Web 2.0” and your staff will generally need to be (extensively) trained to take full advantage of the system. This will usually be a fixed rate per course or student.
• Internal Support Costs
  Even if the vendor installs and configures the software and includes “support” as part of maintenance, the support will generally be limited to bug fixes. You’ll still need internal IT resources to manage the instances, manage the servers, and support your users (and the required operating environments). The annual cost will be the estimated number of annual resources required times their average annual salary.
• Software Upgrade Costs
  Depending on the vendor, every 2 to 4 years they’ll release a major new version of their (on-premise/ASP) solution and discontinue support for an older version around the same time. This means that, every 2 to 4 years, you’ll have to upgrade, for a hefty fee, or risk losing support. This cost can be estimated by looking at the vendors historical major release cycle and average upgrade cost as a percentage of previous system price.
• Hardware Upgrade Costs
  Every 3 years, your hardware will need to be replaced. Even though the cost per performance unit continually decreases, you’ll need a more powerful machine at upgrade time as your users will be using the system more heavily, the software upgrades will demand more computing power, and you’ll need to support your (hopefully) growing business. A safe bet is to expect the upgrade costs will be roughly equal to the initial hardware costs.

In our next post, we will tackle negotations and how you should go about defining your ultimate objective.

In our last post on the buying of enterprise software, we discussed the process by which you could identify potential solutions capable of meeting your needs. In today’s post, we talk about how you identify the components required in your cost models, define the appropriate lifetime calculations, and why these cost models are critical to good solution identification.

4. Build Your Cost Models

Those of you who know software know that there’s the up-front price and then the true back-end cost that materializes after you sign on the dotted line, and that the back-end costs can often outweigh the up-front pricing by an order of magnitude, especially if you are going to be tied to the system for a number of years. Thus, before you enter into negotiations for any piece of software, it’s important to understand the range that your total lifetime ownership costs are likely to fall in, how this range compares to other solutions, and whether the ROI is likely to be there. If the annualized total cost of ownership is in the millions and you only have a quarter million per year in the budget, if the median cost is three times as much as the median cost of other solutions being considered, or if the ROI is negative, then you immediately know that a solution isn’t appropriate and can narrow your search, evaluation, and negotiations to other potential solutions.

While the total cost of lifetime ownership will depend on the delivery model of the software being delivered, the pricing structure used by the vendor, the skills of your internal IT support department, the price concessions you get in negotiations, and a host of other factors, it is possible to build a reasonably accurate model based on the delivery model of the software, the supporting platform requirements, and benchmark costs (which can then be refined during negotiations with the shortlisted vendors).

Furthermore, there’s no fast and simple rule as to when a certain type of application will be cheaper. Some people will argue that SaaS is always more expensive in the long run, on the faulty premise that rental models are always more expensive than up-front buys, and some will argue that SaaS is always cheaper on the faulty premise that SaaS does not require back-end hardware costs or internal support personnel, which can cost hundreds of thousands of dollars a year. The fact of the matter is that each buying scenario is different. It strongly depends on the solutions being considered, current market pricing, whether or not the space has recently seen any disruptive entrants, and how long you are likely to keep the application. If the trend is to replace the application you are buying every 5 years, and the rental model only becomes more expensive in year 15, the on-premise advocates don’t have a leg to stand on. If the solution you are buying does not require much in the way of compute power (as all it does is suck data in, aggregate it, and spit out some basic reports), your racks are only running at 50% capacity, and it’s a product your new network admins are already familiar with, it might not require that much in the way of support, knocking the legs out from under the SaaS evangelists. You’ll never know which solution is truly cheaper until you build the model, get the facts, do the math, and then negotiate for the best deal you can get.

On-Premise applications will generally entail at least the following costs:

• License Cost (Up Front)
• Maintenance & Support (Annual)
• Dedicated Server Costs
• Supporting Software Costs, usually Database and Application Server at a minimum
• Implementation & Customization Costs
• Integration Costs
• Training Costs (Up-Front)
• Internal Support Costs
• Major Software Upgrade Costs, usually every 2-3 years
• Hardware Upgrade Costs, approximately every 3 years
• (Re)Training Costs (on Upgrade)

Hosted ASP applications will generally entail at least the following costs:

• Annualized License and Maintenance Cost
• Annualize Hosting Cost that consolidates hardware, bandwidth, and support costs
• Major Software Upgrade Costs, usually every 2-3 years
• Implementation & Customization Costs
• Integration Costs
• Training Costs (Up-Front)
• (Re)Training Costs (on Upgrade)

True multi-tenant SaaS Applications, that don’t require a dedicated instance and the costs that go along with the classic ASP model, will generally entail at least the following costs:

• Annualized License, Hosting, and Maintenance Cost
• Implementation & Customization Costs
• Integration Costs
• Training Costs (Up-Front)

In our next post, we will discuss the calculation of each of these primary cost elements.

In our last post on enterprise software buying, we discussed the process that should be followed in documenting your true software needs. In today’s post, we discuss how you use these requirements documents to identify the right potential solutions for you.

3. Identify Potential Solutions

Once you’ve documented your basic requirements, you can start identifying solutions that could meet your needs. Don’t limit yourself to vendor materials and demos. Be sure to read analyst reports and blogger reviews, check with your local associations for independent reviews, and ask colleagues about the solutions: what they do, positive experiences, and negative experiences. Get a well rounded view … don’t just check the box.

Furthermore, be sure to ask the right questions. Have a starting list before you talk to the vendor the first time. If you’re buying
RFX & e-Auction,
Spend Analysis,
Optimization,
Contract Management,
e-Procurement,
Supplier Networks & Catalogue Management,
GPOs & Marketplaces,
Market Intelligence,
Strategic Sourcing Services,
Trade Data Management,
Supply Chain Optimization, or
e-Payment, a good starting list (that you can customize to your needs based on the outputs of Step 2) can be found in the X-emplification series.

And remember to chuck the checklist when looking for potential solutions. After all:

• it’s impossible to sum up a “feature” in one sentence, or even a short paragraph,
• no piece of software can do everything,
• trade rags and analysts, despite their best of intentions, give you bad lists, and
• RFP templates are Poison Pills.

In addition, in these troubled times, be sure to spend some time investigating the stability and financial solvency of the vendor before you buy. Five years of guaranteed support for the version of the system you buy is meaningless if the vendor closes up shop in six months … which is a lot more likely than you might think in this current environment. Right now, as many as a few dozen providers in the space are having financial difficulties to some degree. Be sure to ask questions along the following lines, and carefully evaluate the responses, to get a feel for their financial status. (Tip: it wouldn’t hurt to have a behavioral psychologist on the evaluation team when you ask these questions.)

• How is your profit statement looking these days?
  Is it positive, break-even, or negative? What’s the trend over the past year, the past three years, and, if the vendor has been around that long, the past five years? And how many months of operating capital does the vendor have in the bank?
• What’s your ownership structure? (And who ultimately makes the financial calls when times get tough.)
  If it’s public, the board runs the show. If it’s private, do the founders/owners run the show, or do the VCs? If VC’s own over 50% of the company, they ultimately run the show and they will decide who to keep, what to cut, and whether the company will even stay in business if times get tough.
• What would happen if you didn’t sign any new customers for an entire year?
  Does the company have enough cash and booked revenue to maintain current staffing and service levels? Would they have to make serious cuts to support and NPD? Might straits get so dire that they’ll have to liquidate or shut down?

In our next post, we talk about the creation of total lifecycle cost models for each potential solution, which are key to helping you understand the order of magnitude of the full lifetime total ownership cost of each solution you are considering and key to helping your negotiator get you the absolute best deal.

In our last post on enterprise software buying, we discussed the formation of a cross-functional team … critical to the identification of your true needs. In today’s post, we discuss the proper process for identifying and documenting your true software needs which helps you identify the solutions that are capable of meeting your fundamental needs and helps your negotiator avoid the “unnecessary modules trap” that we’ll discuss later in the series.

2. Document Your Needs

Once you have your selection team in place, the first task to accomplish is the documentation of what your organization needs the solution to do. This does not mean you document your current systems; this does not mean you document your current processes; and this definitely does not mean you use a “checklist” from a trade rag or a free RFP template. It means you sit down and spell out what your current problems are, what your preferred solutions are, and how you intend to functionally meet them with a new software solution.

It’s key to focus on process-oriented functional descriptions at this stage as “features” are irrelevant. It’s not how many features a product has, as you won’t use most of them anyway (consider Microsoft Word as an example), but how many functions it can perform relative to your business (and process) needs.

Some important points to consider at this stage of the selection process are:

• What are my current issues?
  Software should solve problems, not create new ones. If you need to get your procurement process under control, but the new software doesn’t have any workflow management capabilities, you’ll end up having one more thing to manage.
• What do I need the new system to do?
  What are your big problems? Data collection? Analysis? Reporting? Order Tracking? Logistics and Network Management? That is what you need the new system to do, not what your vendor, trade rag, analyst, or even your favorite blogger tells you.
• Who will be using the new system, who will be using the new system the most, and what are the most common tasks that will be performed in the new system?
  Sounds obvious … but in reality, this important question is often overlooked. I see people buy systems time and time again simply because they have a “feature” that a competing product doesn’t have. What’s wrong with that you ask? Well, when the feature is only used once a month, or once a quarter, and could easily be accomplished in an external tool through a simple data export, and the “cost” of the feature is a significantly larger price tag or a lack of usability with respect to common functionality that is needed every day, an undue focus on a single “feature” becomes counter-productive. If a vendor is playing the “feature” game, chances are their “functionality” is lacking.
  The only way to truly maximize value from any system you buy is to make sure it supports all of the common functions needed by all of your regular users. The “3-click” rule should apply just as it does in good web design. If a regular user can’t access a common function in 3 clicks, it doesn’t matter how easy it is for the manager who only logs on once a month to access what is likely, in effect, a stale and meaningless report. Remember, even the Harvard Business Review was quick to point out that “feature”-based “enhancements” don’t necessarily deliver results commensurate with costs.
• What data do we need to collect, what information do we need to compute, and what knowledge do we need to get out?
  If it’s a data intensive application, make sure it’s very simple to get large amounts of data into the system, using the native formats in which you are able to acquire the data. If it’s a decision support tool, make sure the analytics you need are present, easy to use, and templateable (as this is the best way to support junior users).
• Where, and how, will our users be using the system?
  If your only users are buyers and finance who will always be at their desks on their big-screen workstations with their high-speed connections, you can buy just about anything and it will work well. But if you need to support road warrior buyers who are always on the road visiting factories with intermittent internet access that’s sometimes restricted to slow dial up or cell-phone connections, you better make sure it has a stable off-line fat-client mode that only pulls down/pushes up new data, in a compressed format, on an as-needed basis. If it locks up for 30 minutes every time your user signs on to the network, it’s more useless than a brick (which can at least be used to prop the door open as you show the vendor out in a Jazz Style Exit).
• What existing systems does the new system need to interface with?
  If your organization just spent eight figures on an ERP, then even if it’s not a mandate, your new system will need to interface with the ERP. Buying a contract management system? It should interface with your e-Sourcing and e-Procurement systems. And so on. Equally important, don’t be fooled by vendors who create artificial dependencies between products that really don’t have any dependencies on each other. This legedermain is common in e-sourcing software, and forces you to buy more than you need. If the vendor has introduced an artificial dependency that requires purchase of an unrelated module, demand the unrelated module for free.
• What are our operating environment constraints?
  If your IT department can only support Windows, that’s a major limiting factor. You need to understand all of your limiting hardware and software factors (operating systems, databases, application servers, hardware environments, etc.) before you identify potential solutions, or you might get all the way to the contract signing only to find out IT can’t support the system, forcing you to go back to square one.

In our next post, we’ll talk about how you use these requirements to identify potential solutions appropriate for your organization.

In our last post, we overviewed the basic eight-step process that should be followed whenever you embark on acquiring a new piece of enterprise software. In today’s post, we start our deep dive into the process steps, starting with the issue of cross-functional team formation.

1. Form a Cross Functional Team

The starting point is to form a selection team that consists of representative stakeholders from each group that will be using the system, each group that will be paying for the system, and each group that will be supporting the system. This will help fully define your needs and requirements and ultimately insure that no solution is shortlisted that doesn’t meet a basic need of one or more parties (and minimize the chance that you buy a(nother) multi-million dollar “shelfware” product). It’s also necessary to insure you don’t buy a product that one or more intended users will boycott (which could result in your selection being a failure and a money-pit from day one).

In supply management, the following stakeholders will need to be represented in every purchase:

• Buyers
  Buyers, or a subset thereof, will be the primary users of the system.
• Procurement Managers
  Supervisors, Directors, and the CPO will need to track the activity of their buyers, track spending, and, most importantly, track productivity increases and cost avoidance.
• Accounts Payable and/or Accounts Receivable
  Supply management is all about buying and realizing savings, especially those that take the form of discounts, rebates, warranty claims, and returned overpayments. Even if AP and/or AR doesn’t need to use the system directly, they will still need the data from the system.
• IT
  Even if it’s SaaS, IT is still going to have to support the system one way or another. If it’s on-premise, IT will likely be responsible for the installation, maintenance and upgrades. If it’s hosted ASP, IT will need to manage the remote integration with the other systems that need to push data into and pull data from the new system — and, no doubt, run security checks and audits to ensure that the hosted software passes basic security checks. And even if it’s SaaS, IT will still have to support the requisite environment as most software is only certified for specific browser-based environments (such as IE 7 and/or Safari 3 on Win XP SP2+, Vista SP1+, or Mac OS X 10.4+) if it’s thin client, or specific operating system configurations if it’s fat client (such as Win XP SP2+ with Cisco VPN software).

Furthermore, the following departments will be affected by certain types of supply management software acquisition:

• Risk Management
  If your organization has a dedicated risk management function, since every aspect of supply chain involves risk, you’ll need to involve risk management.
• Strategic Planning
  If you have a long-term strategic planning division, and you’re buying software that supports scenario planning, what-if modeling, or (network and/or market) simulations (like strategic sourcing or supply chain network optimization), you’ll likely have to consult with strategic planning.
• Legal
  If you’re buying a contract management system with contract authoring support, for example, legal may end up being a primary user.
• Human Resources
  If you’re buying software to support the procurement of temporary labor, you’ll need a sign-off from HR.
• Regulatory Compliance
  If you’re buying a global trade management system, a carbon emissions tracking system, or a SOX compliance system, you’ll likely need to make your selection under the guidance of regulatory compliance.
• Production
  If you’re buying software that impacts forecasts and production plans, you’ll need to work closely with production.
• R&D / Engineering
  If you’re buying software that impacts or supports PLM (Product Lifecycle Management), you’ll also need to involve R&D and/or Engineering as it will critically impact their operations.

In our next post, we will discuss need identification and documentation.