Mostly Harmless, Part II
A requisition is a request for a product or service in a written form. With respect to e-Procurement, it is generally an electronic request for a product or service in a standard form, which may or may not use standard product or service codes from either the organization’s ERP/MRP systems or the supplier’s (e-)catalog.
While the concept is simple, the reality can be quite complex, especially if the requisition is for a large BOM (Bill of Materials) that requires multiple products and services from multiple suppliers, as different types of identifying information and specifications can be required for each line item.
The requisition needs to be able to capture a significant amount of information. In addition to the following core information:
- requisitioner
- department, division, and/or organization
- request date
- requested delivery date
- delivery location
- line items, each of which requires:
- organizational product/service code
- supplier product/service code
- quantity
- price (from the contract, schedule, or catalog)
- etc.
The requisition may also need to capture:
- supervisor
- budget manager(s)
- AP contact
- delivery contact
- product description(s)
- itemized Statements of Work (for services)
- etc.
As a result, the requisition needs to be very flexible and capable of being augmented by the buying organization as needed. Furthermore, it needs to be able to extract information from the organization’s ERP/MRP system, vendor master, contract system, and catalog(s), punch-out(s), and/or marketplace(s). As a result, it must either support easy integration with these systems, or (one or more) standard XML input and output streams (and cache commonly used codes if the updates aren’t near real-time).
In addition, it has to be integrated into the workflow management system that handles approvals, m-way matching (against goods receipts, invoices, etc.) during reconciliation, and the data store(s) used by the analysis and BI tools.
When evaluating the requisition capability of an e-Procurement system, one should keep in mind the associated challenges of the requisitioning process, keep an eye out for best practice support, and insure that the solution will deliver the intended benefits, which is the subject of the next post.
Next Post: Requisitions, Part II