1. Pick the highest-volume, lowest-complexity workflow first
The first workflow to automate is the one with the highest volume and the lowest complexity. For a 100-person healthcare and medtech company in Switzerland, that is almost always order and shipment status updates. The operations team receives 40 to 60 inquiries per day from hospitals, clinics, and distributors asking where an order is. Each inquiry requires a human to log into SAP or Microsoft Dynamics, check the order status, and draft a response. The average first-response time is 4 to 6 hours. The error rate is 8 to 12 percent because humans copy data from the ERP into the response and make transcription mistakes. This workflow is the ideal first pilot because it is high-volume, low-complexity, and the data is structured. The AI reads the ERP directly, so there is no transcription step. The response is a template with the order number, the status, and the expected delivery date. The human approval gate is simple: if the status is ‘shipped’ or ‘delivered’, the AI sends the response automatically. If the status is ‘delayed’ or ‘exception’, a human reviews it. This single workflow, automated, cuts the first-response time from 4 hours to 60 seconds and the error rate to under 2 percent.
2. Integrate with the ERP through its native API, not a custom connector
The AI layer does not replace the ERP. It reads order and shipment records through the SAP or Dynamics API, classifies the status, and writes the response back to the helpdesk or messaging channel. The ERP remains the system of record for inventory, billing, and shipping. The AI orchestration layer sits between the ERP and the customer-facing channel, handling the translation and the human approval gate. No data is duplicated; the AI reads and writes through the existing API endpoints. The integration is built on the ERP’s standard API, not a custom connector. For SAP, that is the OData API or the BAPI layer. For Microsoft Dynamics, that is the Web API or the Business Central API. The integration is tested against the client’s staging environment before it goes live. The client’s IT team provisions the API credentials and the network access in the first two weeks. The Forfis team builds the orchestration layer in the next four weeks. The result is a system that plugs into the existing infrastructure without replacing it.
3. Run open-weight models on-premise to keep PHI inside the building
The model-agnostic architecture means Forfis can use OpenAI or Anthropic APIs for tasks where quality matters and the data is not regulated, and open-weight models on the client’s hardware for tasks where regulated data cannot leave the building. For a Swiss healthcare company, the order status workflow uses open-weight models on-premise because the ERP contains patient identifiers. The model never sees raw patient identifiers; the orchestration layer strips PHI before the prompt is constructed. The model’s output is a structured JSON object with a status code and a template ID, not free text. A human operator reviews any output that triggers an exception rule before it is sent. This architecture satisfies HIPAA’s minimum necessary standard and Swiss FADP Article 6(2) on data minimization. The client’s IT team provisions a single A100 or H100 GPU server in the first two weeks. The Forfis team fine-tunes the model on the client’s historical order data in the next four weeks. The model runs on the client’s hardware, so no data leaves the building.
4. Build the human-in-the-loop approval gate into the existing helpdesk
The AI drafts the response, but a human approves anything that touches money, health data, or a contract. For order status updates, the approval rule is simple: if the status is ‘shipped’ or ‘delivered’, the AI sends the response automatically. If the status is ‘delayed’, ‘returned’, or ‘exception’, a human reviews and approves before the response goes out. The approval queue is integrated into the existing helpdesk, so the operations team does not need a new tool. The human-in-the-loop design is not a compromise; it is the default. The model is a draft, not a decision. The human is the decision-maker. This design reduces the risk of a bad response going out, and it builds trust with the operations team. The approval rate for ‘shipped’ and ‘delivered’ statuses is 95 to 98 percent, so the human only reviews the 2 to 5 percent of responses that are exceptions. The average approval time is 30 to 60 seconds. The total first-response time, from inquiry to response, is under 2 minutes.
5. Measure the before/after baseline in the first two weeks
The pilot ships with a measured baseline: the average first-response time and error rate before automation, and the same metrics after. For a 100-person healthcare company, the typical baseline is 4 to 6 hours for a human to check the ERP and draft a response. After automation, the AI drafts the response in under 2 seconds, and a human approves it in 30 to 60 seconds. The error rate drops from 8 to 12 percent to under 2 percent because the AI reads the ERP directly rather than relying on a human to copy data correctly. The baseline is measured in the first two weeks of the pilot, before the AI is live. The after-metrics are measured in the last two weeks, after the AI has been running for at least four weeks. The client gets a one-page report with the before/after numbers, the error rate breakdown, and the approval rate. This report is the basis for the decision to scale to the next workflow. The 3-month timeline is realistic because the scope is fixed and the metrics are measured from day one.
6. Fix the scope and the price before the pilot starts
The pilot is fixed-scope and fixed-price. The scope is defined in the contract: the number of API endpoints, the number of response templates, and the approval rules. The cost covers the process audit, the integration with the ERP, the build of the orchestration layer, the model fine-tuning, and the 3-month managed operation. The client’s cost is the GPU hardware for the on-premise model, typically a single A100 or H100 server, and the time of the operations lead and IT contact. For a 100-person company, the total cost of the pilot is typically in the range of EUR 40,000 to EUR 60,000, depending on the complexity of the ERP integration. The fixed-scope model prevents scope creep. If the client wants to expand to shipment tracking or returns, that is a second pilot with its own scope and timeline. The 3-month timeline is realistic because the scope is fixed and the team is dedicated. The client does not need to hire new staff; the existing operations team handles the approval queue, and the IT team provisions the hardware and the API credentials.
7. Ship the pilot as a measured baseline, not a transformation
The pilot is one workflow, not a transformation. The operations team still handles the exceptions, the escalations, and the complex inquiries. The AI handles the 80 to 90 percent of inquiries that are routine status checks. The human-in-the-loop approval gate ensures that the AI does not make a mistake that a human would have caught. The model-agnostic architecture means the client is not locked into one vendor; if the open-weight model is not good enough, Forfis can switch to a commercial API for the non-PHI tasks. The integration with the ERP means the client does not need to replace its system of record. The 3-month timeline is realistic because the scope is fixed and the team is dedicated. The result is a measurable reduction in first-response time and error rate, with no new hires and no new tools. The operations team gets its time back for the work that actually requires a human.
Leave a Reply