A six-week pilot of an operations-layer overlay has a tight integration budget. You can wire about three or four systems cleanly in that window. Picking which three or four determines whether the pilot proves the thesis or stalls in plumbing.
What to wire up first
Read access to the ERP item master
Non-negotiable. The overlay cannot reason about anything downstream of the ERP without knowing what the items are. Read access is usually straightforward (SQL replica, REST API, or a scheduled extract). Write access can wait. Get the read working in week one.
Read access to PO and receipt history
The overlay's scoring, planning, and proposal logic all depend on knowing the recent PO and receipt activity. Same shape as the item master read. Two-year history is usually enough; deep history is a nice-to-have and not on the pilot critical path.
Email read access to the buyer's inbox
The pain the pilot is most likely trying to address is buyer-side: vendor quote parsing, PO drafting, override capture. Email read access is what makes the operations layer visible to the actual workflow. Skip this and the overlay is a dashboard. Include it and the overlay is a working assistant.
One narrow write path to the ERP
One. Not all of them. Pick the write path that closes the loop the pilot is trying to demonstrate (typically PO draft-and-emit). Get the write working with a feature flag and a kill switch. The rest of the write surface can be shadow-mode (the overlay produces the proposal, the operator copies it to the ERP manually) until week six is a confirmed success.
What to defer
Finance system integration
Finance integration is real work. Pilots that try to land finance in week one stall because the chart of accounts mapping, the cost-centre alignment, and the journal-entry conventions are all bespoke per customer. Defer to phase two. The pilot can demonstrate operational value without finance writes.
Custom in-house systems
Every customer has at least one. A homegrown CRM, a custom quality system, a bespoke MES, a SQL Server with a spreadsheet front-end. These integrations are achievable but unpredictable. Map them out, scope the work, and decide whether they are pilot-critical or phase-two. Often they are phase two.
The full vendor portal scrape
Vendor portals are seven different shapes and most of them are anti-scraping. A full portal scrape suite is a multi-quarter project, not a six-week pilot scope. Pick one or two key vendor portals if any, and accept that the rest of the portal surface stays manual through the pilot.
Reporting integrations
The dashboards downstream of the operations layer (BI tools, executive scorecards) can be deferred. The pilot needs to prove operational value. Reporting connectors prove executive visibility, which is a phase-two concern.
The two integration shapes that should never be on the pilot critical path
Custom DB change-data-capture against the ERP
CDC against an ERP is a deceptively appealing integration shape. It looks like "just subscribe to the changes and react." In practice, ERP databases are not designed for CDC. The schemas have invariants that are enforced at the application layer, not the database layer. The CDC stream produces events that look correct in isolation and are wrong in context (a row update without the joined rows that contextualise it). Building the translation layer that turns CDC events into meaningful operations-layer events is a quarter of focused engineering and does not belong in a pilot.
The right move in a pilot is to read through the ERP's official API (REST, SOAP, whatever the vendor provides), even if the API is slower and more rate-limited than a direct DB read. The API is the contract; CDC bypasses the contract.
Hand-rolled EDI 850 (or similar EDI documents)
EDI 850 is the standard purchase-order document in many industries. Implementing it from scratch is a serious project (X12 parser, EDI envelope handling, AS2/SFTP transport, trading-partner agreement, vendor onboarding). The full implementation is two to three quarters of engineering work.
In a six-week pilot, if EDI is needed, pick an EDI service (TrueCommerce, SPS Commerce, or one of the integration platforms that wrap EDI behind a REST API) and integrate to that. The operations layer talks REST to the EDI service; the EDI service handles the X12 and AS2. The cost is recurring. The time saved is the difference between a working pilot and a stalled one.
The week-by-week scope
Week 1
Read access to the ERP item master and PO/receipt history. Email read access to one buyer's inbox. The overlay starts producing proposals in shadow mode (visible to the operator, not writing anywhere).
Week 2-3
The buyer starts using the overlay's proposals as input to their existing workflow. The overlay learns from the overrides. The integration to the buyer's vendor portal (one key vendor) is wired if needed.
Week 4
The one narrow write path to the ERP is enabled with a feature flag. The buyer can use the overlay to draft and emit a PO end-to-end. Volume is intentionally low.
Week 5
The write path is enabled for the full PO volume the buyer is producing. The audit log is reviewed for any bad writes. The override patterns are characterised.
Week 6
The pilot is reviewed against the success criteria set in week zero. The decision is to phase-two or to wind down. Either outcome is acceptable; the pilot exists to give the information to decide.