Three components are crucial to defining requirements for a new software application: 1) documenting existing processes; 2) assessing the functionality of existing software; and 3) assessing current and future needs.
In any software selection undertaking, present conditions should serve as the point of departure for improvement. The first stage, process mapping, is the step in which an objective party reviews each major process function and gathers documents used to perform that work. Interviewing process owners (at least two per process, if possible) and observing the work allows the mapper to develop a written and visual representation of the task flow that a software application is meant to support. Developing application requirements follows a management review of the mapping.
The review also provides an excellent opportunity to determine whether the process itself can be improved. Implement any improvements with the understanding that these changes will be part of the process any new software system needs to support. Utilization rates are generally lower than one would expect, and sometimes far enough off the mark to warrant a challenge of the perceived need to replace an application. The causes of this problem range from employee turnover to postponed implementation to changes in the marketplace.
What’s the use?
Two levels of use exist, resource utilization being the first. It is important to understand how well the hardware and the software configuration match technically with the ways in which the organization uses (or could use) the system. Measurements such as response time and user traffic come to mind.
The second level constitutes user needs versus existing features and functions. For example, I recently worked with a purchasing group that was seeking a replacement application to support its buyers. In defining the scope of the project, it became clear that a number of functions — a system-generated EOQ (economic order quantity), for example — were not being used because the buyers found them too cumbersome. A modification to this one function might be much less costly than replacing the application.
Sometimes the issue is training. High turnover or growth may lead to a situation where most of the current users are recent arrivals who received training from their peers, who may be unaware of significant application capabilities.
In twenty-odd years of reviewing system capabilities and user views on software solutions, it has been rare to find a fully satisfied end user. To some extent, these views are a product of legacy environments in which, over time, systems were enhanced so that they became highly tailored to the context in which users lived. In the day and age of packaged, configurable vanilla software, meeting a broad range of needs also means meeting no one’s needs fully without expending additional effort, time, and cost.
Despite the fact that software life-cycles are shrinking, a needs assessment should include the future. Factors to consider might be major shifts in the company’s approach to its marketplace, product changes, and so forth.
Finally, there are a number of short cuts available to help document features and functions requirements, particularly if the application is in a core segment, such as a WMS. Several organizations publish free or “for a fee” checklists, functional comparison abstracts, and various opinions on how to compare vendors and applications. Not only will these assist in working with users, but they will support the vendor evaluation process later on.
Ron Hounsell is VP of software solutions at Tom Zosel Associates, a distribution and logistics consulting firm based in Long Grove, IL. He can be reached at [email protected] or at (847) 540-6543. Ray Becker, President of Assets Preservation Corporation, also contributed to this article.