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 (in a March 2009 article on “The Truths About IT Costs”) 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.

Buying enterprise software isn’t easy. In fact, it’s just as complicated as global sourcing, if not more so (and that’s why IT professionals make great global sourcing professionals, as noted in this recent article from Global Services). You’re buying something that’s immaterial and, these days, ephemeral, but just as costly once all the “hidden” costs are taken into account.

What’s worse, a mistake can cost you many times the initial purchase price. Accidentally spot buy 10,000 parts incompatible with your current assembly? You sell them at a 10% loss, take a one time hit, learn your lesson, and move on. Move too quickly on that new, on-premise, e-Sourcing platform to take advantage of that limited time “special discount” and lock in a five year term on a platform that is thoroughly incompatible with your ERP? There’s an additional seven to eight figures, up front, of custom integration work plus significant third party maintenance each year to keep the middleware running each time you patch your ERP or your new e-Sourcing platform and “break” the custom middleware.

Thus, when it comes to enterprise software, you need to be prepared. In this 8-part series, I’ll attempt to walk you through each step of the enterprise software buying process, point out what you need to watch out for, and pass on some of the secrets of successful software purchasing.

First of all, let’s outline the basic process.

1. Form a Cross-Functional Team.
2. Document Your Needs.
3. Identify Potential Solutions.
4. Build Your Cost Models.
5. Define Your Objective.
6. Negotiate Professionally.
7. Comb the Contract.
8. Manage Performance.

Sounds simple enough, doesn’t it? Too bad each step is a virtual minefield laden with explosives that can blow up your costs, your project, and your organization’s trust in you. That’s why we’re going to examine each phase in detail.

When you get right down to it, enterprise software is a serious commitment. Even if you are able to divorce yourself from a system (or a vendor) after signing a contract, you can bet that it won’t be before you incur a significant penalty. (Even if the vendor is a “quit anytime you want” SaaS vendor. There’s always a cost, even if it isn’t always paid direct to the vendor.) Plus, you’ll have to move all of your data to a new system, which will likely require custom development work to integrate it with other systems and cause your losses to mount in this double whammy scenario. Of course, you’ll take a productivity loss while your employees are left without a system (and if it’s a supply management system, the disappearance of a key piece of analytics technology could result in uninformed buyers making less-than-optimal, and costly, sourcing decisions). That’s why you have to do everything you can to make sure you select the right system up front.

In our next post, we’ll discuss cross functional team formation.