Lima Backbone reads planning data from SAP and Oracle through the interfaces SAP keeps open, transforms it at the volume an MRP run needs, loads it on your planning calendar, and returns approved plans to the ERP with every write acknowledged. Your first planning dataset is live in four weeks at a fixed price.
Delivered as software with a fixed scope. Your systems integrator can deliver on it; so can ours.
Nine in ten planning programs underestimate the integration work; data preparation is about 70% of what an APS implementation costs; only 59% of planning-system users can plan without manual work-arounds.
Every one of those numbers traces back to the same job: getting items, bills of material, routings, inventory, open orders and forecasts out of the ERP, into the shape the planning engine expects, on the day the planners need them. Lima Backbone does that job with a fixed scope and a reconciliation report at the end, so the program schedule stops depending on a one-off integration build.
A planning engine such as Kinaxis or o9 cannot query your SAP system directly. It needs a complete, consistent copy of the planning data, delivered in its own format, inside a fixed time window before the planning run. Lima Backbone builds and runs that delivery, checks it, and carries the approved plan back.
Each step is a stage in the same pipeline, visible on one canvas, with an owner for anything that fails a check.
Planning engines depend on data that lives in spreadsheets in most companies: product families, regional roll-ups, safety-stock policies, minimum order quantities, lot sizes, lead-time overrides, sourcing priorities. Lima keeps these as governed records.
A planner changes a safety-stock policy in Lima; the change is versioned, reviewed where your policy requires it, and reaches the planning engine on the next load.
Orphan nodes, duplicate codes and broken roll-ups are caught as exceptions with an owner, which is why the planning graph stays consistent cycle after cycle.
One set of planning master data feeds Kinaxis, IBP and the S&OP model alike, so the numbers in each system reconcile.
Counts and control totals per dataset, compared with the source, with any variance routed to an owner. The sample below shows the structure of the report; the figures are illustrative.
| Dataset | Source rows | Loaded | Variance | Control total | Status |
|---|---|---|---|---|---|
| Item master MARA · MARC | 2,914,220 | 2,914,220 | 0 | — | Reconciled |
| BOM components STPO · STKO | 18,406,113 | 18,406,113 | 0 | qty 1.20 × 10⁹ | Reconciled |
| Open purchase orders EKKO · EKPO | 1,204,881 | 1,204,878 | 3 → owners | value matched | 3 exceptions |
| Sales orders VBAK · VBAP | 6,102,447 | 6,102,447 | 0 | qty matched | Reconciled |
| Forecast external file | 412,006 | 412,006 | 0 | — | Reconciled |
| Planned orders returned BAPI_PLANNEDORDER_CREATE | 41,207 | 41,207 acknowledged | 0 | — | Acknowledged |
Illustrative sample. Record counts and control totals are compared per dataset on every run; the three held-back purchase-order lines were routed to their buyers and replayed on the next run.
A planning load has a deadline that belongs to the business: the MRP run at 06:00, the weekly S&OP cut-off, the month-end close. Lima treats that deadline as the promise the pipeline exists to keep. The figure shows one night from the showcase estate.
Each pipeline carries its run window and deadline. A dashboard shows how much margin is left, and alerts go to Slack, Teams or PagerDuty before the deadline is at risk.
When a check fails, the pipeline holds its place and the deadline clock pauses with it. Once the fix lands, the run resumes from its checkpoint and replays events in order. Nobody restarts anything by hand.
Lima’s DAGs are standard Airflow DAGs. Your enterprise scheduler can trigger them, and your engineers can read them.
Orchestration on the platform →02:14 — an anomaly fires on an inbound feed; three dependent pipelines are held automatically. 02:51 — root cause found. 02:58 — the pipelines resume from their checkpoints and replay 841,000 events in order. 06:30 — the deadline is met with 3 hours 32 minutes to spare. Time to resolution: 44 minutes, with no manual restart. Showcase estate figures.
Items, BOMs, sources, inventory, open orders and forecasts in; planned orders and allocations back through acknowledged BAPI calls. The closed loop Lima has run since 2021.
Lima for Kinaxis →Product, location and customer hierarchies checked for gaps and duplicates before they reach o9, so the planning graph stays consistent cycle after cycle.
Lima for o9 →Planning objects loaded on the calendar; warehouse and transport data read live for the control tower.
Lima for Blue Yonder →The multi-ERP and non-SAP sources SAP’s own integration leaves out, delivered in IBP’s format on the planning cycle.
Lima for SAP IBP →Recipes, resources, calendars and demand streams shaped for OMP’s model, with counts proved on every run.
Lima for OMP →The trial planning teams ask for, with a number at the end of it.
Once the planning loads run on their calendar, the same governed data serves the AI control tower: KPI library, exception management, agents that act across the estate with earned autonomy.
The AI Control Tower on your SAP estate runs on the fabric and the backbone you already have in place after the first load.
One engine underneath every page in this family. It reads from any source and writes to any target, runs batch loads or change-data streams, handles a nightly delta or a multi-terabyte migration, and is licensed by capacity, so the bill stays the same however many rows move. Lima’s fabric answers questions on data in place; Lima Backbone moves, transforms and returns data on a deadline. When to federate and when to pipeline · The Backbone hub.
Neither. Lima reads SAP through table reads, BAPIs, CDS views and change-data capture, which SAP keeps open to partners, and it writes back through BAPIs and IDocs. There is no add-on to install and no additional SAP licence line.
Lima is the software they can deliver with. The first-load offer gives you the reconciliation report and the run-window measurement either way, and the pipelines are readable Airflow DAGs your team can maintain.
Records that fail a check become exceptions with a named owner and a deadline. The load continues with the valid records, the report shows what was held back, and the exceptions are replayed once fixed.
Approved planning results are posted to the ERP through BAPI or IDoc transactions. Each write carries a unique reference so a retry never posts twice, is acknowledged by the ERP, and is reconciled against what was sent. A failed write re-queues with its reason.
Kinaxis Maestro, o9, Blue Yonder, SAP IBP and OMP have dedicated pages. Other engines are loaded through their API or file interfaces with the same reconciliation.
The first load is a fixed-price engagement. The platform is a subscription sized by capacity tier, with everything included and no charge per row, per connector or per question. Pricing principles.
One planning dataset from your ERP into your planning system, with a reconciliation report and run-window measurement at the end. Fixed price.
