There are many ways to approach the procurement of software, hardware, or services, whenever you decide to replace or upgrade your CMMS and related systems. Regardless of which approach you use, there is always an element of gathering information, obtaining a price, and negotiating terms and conditions based on user requirements. This may involve multiple informal or formal methods as described in this column.
No matter which approach you use, the first and most important step is usually to determine your user requirements. This includes a detailed description of what the users need, as well as a means by which to evaluate and select alternative solutions. The language used to describe user expectations should be consistent and concise, in order for vendors to accurately interpret your needs. In turn, this will enable you to more easily compare vendor options.
Suppose for example, that your company has an older CMMS package that, among other things, does not adequately track warranty information. In fact, you determine that millions of dollars are lost each year because you are unable to keep proper warranty records for assets and parts. In discussions with all stakeholders such as Maintenance, Operations, Engineering, Procurement, Materials Management, and Finance, you develop user requirements for improved warranty management. Wording of the relevant software specification might be something like the following:
1. Ability for the system to handle warranties for BOTH
i. parts, and
including but not limited to:
a. Summary reporting of all work orders on warranty
b. Preparing a warranty claim
c. Recording and tracking multiple warranties per asset
d. Recording and tracking warranty for any activity on a single work order (e.g., one work order with two tasks, namely 1. fix brakes and 2. replace tail light, but only the first task “fix brakes” is under warranty)
e. Recording warranty types (e.g., manufacturer, vendor, extended)
f. Tracking using graphical calendar presentation
g. Tracking by meter including start/expiration/threshold readings
h. Handling warranty renewals
i. Favouring serialized parts closer to warranty expiration
j. Favouring non-serialized parts closer to expiration
k. Parent/child option (i.e., user can opt to pass warranty to all children such as a three-year, end-to-end vehicle warranty)
l. Parent/child option (i.e., user can opt to pass warranty to selected children)
m. Handling group/master warranty (e.g., 60 pumps bought on the same day from a vendor, that all share the same warranty info)
Writing a good user requirements document is no easy task. Specifications should be:
- Very detailed – when in doubt, err on the side of more detail, avoiding simplistic specifications such as "ability to manage warranties," which allows vendors to respond affirmatively even if they have the most archaic warranty capability
- Without company jargon – avoid acronyms that are not commonly known
- Supported with examples – provide lots of relevant examples, including use of footnotes, exhibits, or detailed appendices where helpful
- Bulleted on separate lines – force vendors to respond to each line item, as opposed to responding affirmatively if they can provide only some of the functionality
- Prioritized – although not shown above, each specification line item should be weighted so that vendors understand their relative importance. If the priority is “nice to have”, and not at least “important”, do not put it into the specification.
Not only should the software be evaluated based on user requirements, so too should the vendor be assessed. For example, is the vendor capable of meeting all of the specifications, or are they proposing partnering with other organizations? What are the vendor’s financial health, experience with similar projects, and breadth and depth of product/service offerings? What are the hardware, architecture, telecommunications, data, and other technical requirements recommended by the vendor in light of your specification? What support services are provided such as help desk, training, implementation, and consulting, and what are the expected service levels?
Vendors will also require some context around the specifications, including a description of the following:
- Your company (size, location, nature of business, organizational structure, technical environment, future technology plans)
- The nature of the project and why it was launched (project background, objectives, scope, deliverables, project team structure, key stakeholders, benefits contemplated)
- The evaluation process (timeline, evaluation criteria and percent weighting, your key contact, submission instructions)
As well, there are typically terms and conditions expected by the Purchasing Department, such as expectations around confidentiality, use of subcontractors, and payment terms. Of course one of the most important common elements is pricing. This includes pricing of various software options based on your requirements (e.g., different modules), hardware alternatives (e.g., hosted versus in-house options), and service offerings (e.g., process engineering and training).
One of the most basic procurement approaches is use of the Request for Information (RFI) to simply troll the market, fishing for information as to what solutions are available at roughly what cost. The RFI is most appropriate when you are exploring less known or more complex solutions, like say, whether there is pipeline integrity software that runs on a mobile device, is linked to both field services and route optimization software, and is all integrated with a full-function CMMS.