In the last post, I discussed why IT requirements should not be at the top of your needs definition. In this post, I’ll start the discussion of how to define needs. Let’s take a look at two typical requirements (needs) as an example. The specific needs aren’t that important, so if these don’t apply in your situation, keep reading; we’ll get to the point pretty quickly. Here are the two typical needs:
- Recurring payables capability. The system allows us to set up certain bills that we get every month like the mortgage or the pest control service bill and enters them to be paid so we don’t have to key them.
- Serial numbers for inventory. Some items we sell have serial numbers. It’s important that the system be able to track these serial numbers and who we sold them to.
The first item (payables) is an accounting need. If the system doesn’t have recurring payables, the mortgage and pest control will still get paid. It will just take more work to re-enter the transactions. The second item (serial numbers) is an operational need. If the system can’t track serial numbers, there will be work that needs to be done that can’t be done. In addition, operational needs usually have other operational needs that depend on them.
Operational Needs that Depend on Other Operational Needs
In this example, the reason many companies need to track serial numbers is for warranty work. Without this capability, many hours will be spent trying to trace down the invoice that a particular part came from to determine whether it is under warranty. More hours might be spent tracing the invoice from the vendor for that product. Recalls for ranges of serial numbers or lot numbers can be even more challenging.
In some industries, this need can be very important. For example, in the food industry recalls may be based on serial numbers (or lot numbers). Having this data is necessary to comply with government regulations.
The data may be needed to drive other business needs. For example, to track repairs on equipment or offer customers PM (preventive maintenance) contracts.
As you can see, the need for serial numbers may cascade into other needs. And these needs can be more significant that just a few hours a month of additional effort. There may be business opportunities that are either not possible or not practical without these software features.
Business and Software Expertise are Needed
What’s not as obvious from this is that both business and software expertise are needed to come up with a full needs definition. I’ve had many business people ask for serial number functionality. Only a fraction of that number also asked for warranty, service contract, or recall features. When asked, they quickly said that these were also issues.
Understanding how software uses serial numbers (or lot numbers, national accounts, warranty, etc.) allows an ERP provider to ask you the right questions to configure a system. Not all systems have the features we’ve mentioned in this post. For example, warranty tracking for is common in inventory systems that track serial numbers, but not all systems have it. Service and preventive maintenance is less common. For some systems, it is an add-on product; in others, it is part of the core system.
Make sure your ERP provider is asking good (and thorough) questions about your needs. And don’t leave anything out. The feature you leave out may be obvious to you but not to the ERP provider.