The first question in an e-procurement project does not have to be “Which software should we buy?” First describe the work that needs to improve. Are quotations scattered across files? Are requisition items entered repeatedly? Is it difficult to find the approved version of an order? Solving one of these problems visibly creates a stronger foundation for expansion.
1. Follow one purchase from beginning to end
Choose a recently completed purchase. Write down how the requirement arrived, how technical information was completed, who was invited, how bids were compared and how the order decision was recorded. Note the file and owner at each step. If the same information exists in several places, ask which version is authoritative.
The CIPS procurement cycle provides a framework connecting requirements with subsequent purchasing stages. Use it as a checklist when examining your own process. It does not mean that every activity must be performed in the same application.
2. Define what a successful pilot demonstrates
“Becoming more digital” is difficult to assess. “Transferring approved requisition items into sourcing without retyping them” is much clearer. Add a user group, a category and a review date. Decide in advance which records will provide evidence at the end of the pilot.
Do not judge success only through price. Usable quotation counts, clarification requests and the time needed to prepare the comparison report matter too. Compare them with a genuinely similar previous purchase. A different category or an unusually urgent event can make the comparison misleading.
3. Prepare data and ownership
Check item descriptions, units and supplier contacts. The quality of the supplier list matters more than its size. Decide who approves registration, sends invitations and corrects inaccurate information. These small decisions prevent long email chains once real work begins.
Integration does not always need to be the first-day requirement. A controlled file-based flow may be sufficient to validate the process. If an API connection is needed, treat its scope, development ownership and test data as a separate work package. Give users access according to their actual responsibilities.
4. Test both sides of the event
Testing is not complete when the buyer successfully publishes an auction. A supplier must also be able to receive the invitation, understand the conditions and submit a quotation. Include missing answers, incorrect units and bids close to the deadline in the test scenarios. Use these examples in training so users practise the situations they are likely to encounter.
5. Expand after reviewing the first purchase
Group pilot findings into training, data and process issues. Assign an owner and deadline to each action. Increasing the user count before resolving recurring problems can multiply the support workload. Update the pilot checklist before moving to the next category.
Tenflex can support a limited starting scope through Excel item imports, requisition approval by user unit and the transfer of approved items into an auction. RFQs and additional rounds can follow as needed. Bring your own representative item list to a demonstration. It will help you evaluate whether the workflow fits daily work rather than making a decision from the number of features shown on a slide.
