ERP Requirements: a Paradox?

I had the difficult task recently to respond to several potential customers’ requests for proposals (RFP) that included numerous business requirements for an Enterprise Resources Planning (ERP) system. These RFPs contain from hundreds to thousands of requirements vendor organizations are expected to respond with a fit or gap. These companies are selecting an ERP application and implementation consultant based on these responses. It struck me that most organizations rarely write well-constructed requirements. This results in requirements that are difficult to follow, confusing, or may be too easily answered as a "fit".

The objectives for an RFP seems clear: obtain the best “fitting” and implemented information system at a low cost to benefit ratio. Well, that is what I typically assume is the objective. There are organizations that seek the lowest cost alternative, or at least they believe a lowest cost decision can be made based on these criteria. What may be challenging to evaluate is how fit/gap responses on requirements link together to achieve benefits across a specific business process and whether the responses from vendors will yield an application meeting those needs.

The first key is to articulate the requirement.  This seems to be a basic and easily achieved step, but this is frequently not the case. A requirement “Barcode data capture at Receiving”, communicates the idea that using bar codes is desired, but leaves a lot of room for interpretation. Is the purchase order number scanned? Or are the item numbers scanned?  Does this relate to printing a document with a bar code? Alternatively, this could be scanning all of the batch or serial numbers for the items after receipt. This bar code requirement does not articulate a complete actionable and measurable need. Each requirement should be one concept where a fit/gap response can be subsequently demonstrated and tested.

If the objective of the bar code requirement is to simplify and automate the receiving process, why not ask for ideas on how the application accomplishes that objective? For example, I might respond that vendors could send an advanced ship notification (ASN), which could be scanned to initiate the receipt of the purchase order lines and quantities, rather than the user taking five steps in the process: find the purchase order, enter the packing slip number to initiate the receipt transaction, review all lines on the purchase order, select the appropriate lines, and possibly edit the quantity received on each line. With an ASN, Receiving scans the vendor’s packing slip number and then confirms the physically received items and quantities for an exception based receiving process.

Articulating requirements takes a degree of precision and tenacity to be clear, concise and complete. It takes more effort to be concise: as Thomas Jefferson famously said (“I’d write a shorter letter but do not have the time”). Let’s address these three elements of a well written requirement:

•            Clear: addresses one concept and includes a noun and a verb.
•           Concise: uses few words with a separate glossary to clarify acronyms and company specific terms.
•          Complete: the requirement may be tested and validated at multiple points during the implementation to insure the solution is adequately designed and accepted.

Once the requirements are well written, consider grouping some of the most critical requirements along the lifecycle of a process.  Displaying the sequence of requirements needed to accomplish a process objective enlightens and clarifies the relationships between requirements. Use a process flow diagram with referenced decision and action points. Back to the receiving process, we can display the As-Is and To-Be processes, articulating that two time consuming and error prone steps are eliminated:  “Enter PS# and start receipt” (enter the packing slip number and start the receiving process in the ERP system) and “Edit lines & quantities” (remove lines not received and change the quantities of lines the supplier partially shipped):

Even with this simplified business process flow (it only shows the “happy path” of a correct receipt), the benefits of eliminated steps is clear and these requirements for the To-Be process are articulated:

•       The vendor ASN must include a unique packing slip number as the key
•       The ERP application creates a “pending” receiving transaction for each ASN
•       The user scans the vendor packing slip number (which must be in bar code format) to initiate the receiving process
•       The user should manually validate the correct items and quantities received and may code the transaction as not matched
•       Process steps outside of the ERP application may be shown (dashed boxes in the graphic above)
•       Printed documents from the ERP may be shown (e.g., receipt traveler)

An alternative to the ASN process could be to scan the entire vendor packing slip and use optical character recognition (OCR) to translate the packing slip into text and initiate the receiving process. Depending on the application’s functionality and customer’s needs either the ASN or OCR alternative may be the better approach, since there are positives and negatives for both:

Approach	Positives	Negatives
OCR vendor packing slip	Can be used without vendors changing their processes	Packing slips may not scan successfully or consistently
Vendor sends ASN	Provides advanced notice of shipment for inbound receipt planning Can identify issues prior to receipt (partial ship, etc.)	Vendor processes to send ASN & packing slip in prescribed format Requires a manual process for vendors without ASN

For this receiving example, the organization may 

now have an alternative it had not considered or even knew was possible, so the costs, benefits and risks of each may be assessed.

The additional time and effort to articulate requirements provides the clarity between the project team and the vendors responding. It may even make the job of responding more difficult by eliminating those pesky assumptions for requirements used to interpret requirement most favorably for their solution!

About Kirk:

During his 30 year consulting career he has led many ERP selections and implementations, primarily in the manufacturing, distribution and high technology industries. During a recent two year respite from consulting, he was an executive leading a global supply chain organization using Microsoft Dynamics. As the global supply chain director, he appreciated the opportunity to “eat his own dog food” by running the business processes and technology he helped the company select and implement.

Kirk’s published works include this monthly blog, magazine articles, conference presentations, and the book Lean Distribution, which focuses on the relationship between ERP and lean operations in the supply chain