Ranti
The autopilot for post-go-live ERP.
Every ERP implementation produces two things: a configured system and a body of institutional knowledge about why it was configured that way. The system persists. The knowledge does not.
Within months of go-live, the SI team has rolled off, the documentation is archived, and the client's team has turned over. Every support ticket triggers an investigation — and in the majority of cases, the answer already exists somewhere in the project record. Nobody can find it. So the SI bills for the discovery work again, and again, and again.
Ranti ends that cycle. It sits between your ITSM platform and your ERP system, reading both the implementation record and the live system configuration. When a ticket comes in, Ranti classifies it in seconds by surfacing the gap between what was decided during the project and what actually exists in production.
Everyone else reads the blueprint. We read the building.
How Ranti Thinks
Every ticket, every classification, and every surfaced gap is derived from comparing data across three layers.
Knowledge
The implementation record. Design decisions, scope trade-offs, configuration rationale, training commitments, change requests. Queryable against every incoming ticket. When a user reports an issue, Ranti checks whether the answer already exists in the project record.
Configuration
The live system state. Transaction configurations, workflow rules, transport history, authorization objects, master data mappings. Read continuously via read-only API. Compared against Knowledge in real time. Divergences surfaced proactively.
Delta
The gap between Knowledge and Configuration, computed by comparing both sides simultaneously. Every surfaced gap is a Delta. Every classification is derived from a Delta, or the absence of one. Deltas also capture business needs that evolved after go-live.
From Ticket to Answer in Seconds
When a support ticket is filed, Ranti runs a three-way comparison: it queries the Knowledge layer for any decision, scope trade-off, or training commitment related to the ticket's subject area; reads the live Configuration to determine what the system actually does; and computes the Delta between the two. Based on that comparison, the ticket is classified into one of six categories, each with a different resolution path.
Training Gap
The feature is active and working as designed. Training was committed during the project but the user does not know how to use it correctly. Resolution: auto-close with evidence. No SI call required.
Scope Deviation
The requested feature was explicitly excluded or deferred during the implementation. The system is working per the approved scope. Resolution: log as a new request. This is not a defect.
Standard System Behavior
The system is working exactly as designed and documented. The user expects different behavior, but the configuration rationale supports the current state. Resolution: auto-close with evidence.
Master Data Issue
The migration specification says one thing. The live data says another. The gap is in the data, not the configuration. Resolution: route to the data team with the migration assumption and the live data side by side.
Config Change Impact
The approved configuration no longer matches the live system. A post-go-live transport or change has overwritten the original setting. Ranti identifies what changed, when, and which transport caused the divergence. Resolution: escalate to the SI with full context.
Unrecorded Need
No Knowledge record matches the ticket. The Configuration is working as designed. No Delta detected. This is a business need that was not initially captured, or one that has evolved since go-live. Resolution: flag for review and add to the Knowledge layer. This is how Ranti gets smarter over time.
A Living Layer, Not a Static Archive
At deployment, Ranti ingests your project documentation once: design documents, configuration workbooks, decision logs, test results, change request records, migration specs, and training materials.
But Knowledge is not a one-time snapshot. Every time Ranti encounters a ticket that matches no existing record and the system is working as designed, it flags the ticket as an unrecorded need. Your team reviews and confirms: is this a business need that was missed during the implementation, or one that evolved after go-live? Either way, it becomes a new Knowledge entry.
Over time, Knowledge evolves from "what was decided during the project" to "what the organization actually needs from the system, documented continuously." The longer Ranti runs, the more complete the picture becomes — and the fewer tickets require human investigation.
Copilot First. Autopilot When You Are Ready.
Phase 1: Copilot
Every ticket is classified across all three pillars. Ranti surfaces the gap and the evidence. Your team still decides what to do. This phase builds accuracy proof and trust. You see every classification, review every match, and override anything that does not look right. Overrides improve accuracy.Transition criteria: classification accuracy exceeds 90% over a rolling 30-day window, validated by your reviewers.
Phase 2: Autopilot
Training gaps and standard system behavior auto-close without reaching the SI. Scope deviations, master data issues, and config change impacts escalate with full context pre-attached. The SI starts at the answer instead of spending hours on investigation.Auto-close decisions always include a full evidence trail accessible to the original ticket submitter. Nothing is hidden.
What Ranti Delivers
Ticket classification with evidence. Every ticket paired with the specific project decision and live system state that explains it. Blueprint on the left, building on the right, gap in the middle.
Cost avoidance. A running total of SI investigation costs avoided, based on tickets that Ranti resolved without escalation. Measured against your historical SI billing, not our projections.
Recurrence patterns. When the same root cause produces multiple tickets, Ranti surfaces the pattern and the shared upstream cause. Fix the root cause once instead of investigating each symptom individually.
Configuration drift detection. When the live system diverges from what was approved, even before a ticket is filed, Ranti flags the divergence proactively. Especially valuable after transport deployments, support pack upgrades, and system copies.
AMS validation. An independent view of your SI’s investigation billing. Ranti identifies tickets where the answer was already in the Knowledge layer, and the SI billed for discovering it anyway. This is the report that pays for the pilot.
What We Need From You
Ranti is designed for minimal client involvement and rapid deployment. Target timeline: two weeks from contract to first ticket classified.
A read-only RFC user on your SAP system. Provisioned by your basis team. Ranti never writes to the ERP system. Typical effort: 2 to 4 hours of basis team time.
API access to your ITSM platform. ServiceNow or Jira Service Management. A webhook or scheduled poll for new ticket events. Typical effort: 1 to 2 hours of ITSM admin time.
Access to your project documentation. A one-time upload of design documents, configuration workbooks, decision logs, test results, migration specs, and training materials. Ranti does not need ongoing access to your file shares after ingestion.
HTTPS connectivity. Outbound from Ranti’s cloud environment to your ERP system (direct or via VPN / private link). Inbound for the ITSM webhook.
All client data is tenant-isolated. Ranti does not store transactional business data — no invoice amounts, no customer names, no employee records. Configuration metadata, decision records, and classification results only. Hosted in your preferred cloud region.
Who Ranti Is Built For
Mid-market enterprises, typically $200M to $2B in revenue, within 24 months of an ERP go-live. The buyer is usually an IT Director, VP Technology Operations, or CIO who suspects a meaningful portion of their SI investigation spend is avoidable — and wants the data to prove it.
If your AMS provider is billing for discovery work that feels repetitive, if your team is answering the same questions the project already answered, or if you have lost confidence that the system is still configured the way it was approved — Ranti was built for exactly that situation.