Once a company has determined the important value propositions for moving forward with the selection and implementation of new or upgraded software, it is time to form the detailed requirements for the new system to support. These requirements are essential to determining best fit and ultimate value of the new solution.<\/p>\n
Requirements should be classified as both \u201ccurrent state\u201d and \u201cfuture state.\u201d Current state requirements are presented to explain to potential vendors how the company does business today. The current state business process is impacted by not only current business conditions but by the limitations of the current software on how transactions are processed and your company interacts with its customers and suppliers.<\/p>\n
Future state requirements present how the company plans to operate in the future and use software to support its functioning. The future should be defined in terms of 5 to 7 years. While no company can foretell exactly how they will be operating seven years from now, a company can envision how it plans to be doing business and what types of software and hardware technology it will need to achieve its long term strategy.<\/p>\n
Companies also need to consider how they want to gather information about their current and future operations. Obviously the collection of information is based on the interaction among current users and those in the organization who will be responsible for presenting the collected information to vendors.<\/p>\n
Some companies are capable of preparing business process maps that present the full structure of each aspect of their current state and future state business processes. These maps utilize input from those in the business who work with transactions in a particular business activity. A list of potential maps of both current state and future state business processes may include the following work flows:<\/p>\n
Business process maps should include all inputs and outputs related to the current and future state business processes. These activities should be \u201coverlayed\u201d with indicators of what software is used to support the current action. Examples can be activities that use the current ERP system, activities that use MS Excel or Access Databases, or activities that are performed manually.<\/p>\n
By color coding the activity, readers of the maps can gain visualization of how much of each technology is used to support the current and planned business processes. One of the visible benefits of the future state map should be the uniform color of the new software planned for selection and the elimination of other colors, especially those for Excel spreadsheets and Access databases.<\/p>\n
Checklists have been used to select software for decades. Checklists are typically based on the knowledge of a third party who lists out literally hundreds or thousands of functional requirements grouped similar to the list above. Many of these checklists are associated with databases of yes\/no capability of a number of software vendors. By completing the checklist the user will be in possession of a list of ERP vendors who are most capable of meeting the needs of the user.<\/p>\n
The challenge of checklists is how the underlying database was developed. Vendors are not always completely forthcoming about whether they provide specific functionality but how the software actually provides the information.<\/p>\n
Whether the particular solution is for a company whose sales is $5 million to $25 million or for a company whose sales are $250 million to $500 million requires clarification. An extreme example is that SAP and Oracle provides functionality to support the business process areas above and so does JobBOSS and E2 (popular job shop solutions). There needs to be a match between scope of solution, requirements, and budget (value proposition), as well as industry and basic manufacturing structure between discrete manufacturing and process manufacturing.<\/p>\n
If an organization is going to use a checklist (service) make sure the checklist is completed initially buy the staff responsible for each area and then reviewed by a company-wide team who can relate individual answers to company-wide operations and needs.<\/p>\n
The author\u2019s preference is a narrative document that explains the current state processes and discusses future state needs. By interviewing the people in the business process, narratives can be created that tell the story of how the business runs today and how it wants to operate in the future. There can be a solid level of detail presented that will allow the vendor to understand the business fully. Narratives can also be supplemented with what the business does, why the business is looking for new software (the value proposition), and what technology is currently in place.<\/p>\n
From feedback that the author has received in the past, most vendors struggle to fully follow business process maps and are bored with checklists that are 2,000 features long. Narratives are easier to review. Vendors still spend a great deal of time asking questions that are already disclosed in all three documents so companies need to be prepared to review all processes in some detail even when significant effort is placed into developing the user and software requirements.<\/p>\n
Significant effort and care must be placed into developing user requirements as what has been documented is the foundation of how alternative software solutions will be evaluated for fit, function, and value. Well-developed user requirements will allow a vendor to make the most complete presentation of how their capability will support your vision of future operating success.<\/p>\n
It is really your fault if the vendor is not positioned to demonstrate their capability to the best advantage of your company. A vendor\u2019s solution that is easily observable as not meeting your basic needs should never show up in your conference room for a presentation.<\/p>\n
<\/p>\n
Harry Landsburg<\/em><\/a>, DVIRC\u2019s Director of Business Process Technology Consulting, has worked with over 300 companies to document how their business processes can best be supported by upgraded or new software. His approach to relating the way his clients operate to the technology marketplace results in a better selection and implementation outcome. For more information,\u00a0<\/em>learn more<\/em><\/a>\u00a0or\u00a0<\/em>contact<\/em> us<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"Once a company has determined the important value propositions for moving forward with the selection and implementation of new or upgraded software, it is time to form the detailed requirements for the new system to support. These requirements are essential to determining best fit and ultimate value of the new solution. Two Categories of Requirements […]","protected":false},"author":2,"featured_media":30940,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"acf":[],"yoast_head":"\n