Skip to Content
Case Studies — Kevisons
Case Studies

Real Problems.
Solved Properly.

These are not standard ERP implementations. Each required solving beyond the system — understanding the business first, then building around it.

Note: We work with businesses of all sizes. Not every project looks like this.

84% Less Time Per Batch. Zero Audit Findings.
The Same Team, a Better System.

A mid-sized FDA-registered contract manufacturer specialising in topical formulations and dietary supplements was serving over 40 private-label clients. At that volume, compliance is not a department — it is the entire business. One audit finding, one traceability gap, one batch record discrepancy can unravel a client relationship that took years to build.

The facility was running on a combination of paper-based batch records and fragmented spreadsheets. Inventory was managed with manual stock reservation — FEFO enforcement depended entirely on the team member handling the pick, not on any system logic. Quality control logs were paper-based with no automated deviation triggers. A tolerance breach could go unnoticed until someone manually reviewed the sheet. CAPA closures were tracked in siloed spreadsheets with informal sign-offs, meaning a regulatory audit was always a high-risk event rather than a routine exercise.

The administrative overhead was severe. Each batch required three to four hours of documentation work — a bottleneck that was directly limiting production throughput. The team was skilled and careful. The system was not helping them.

The initial scoping sessions revealed something the client had not fully articulated: different teams had quietly developed their own versions of the same forms because the original paper versions did not reflect how work actually happened on the floor. There were four slightly different batch record templates in use simultaneously. Standardisation had to come before digitisation.

How we approached it

We implemented an integrated manufacturing governance system built on Odoo, covering four interconnected layers: automated material planning, dynamic raw material QC, digital deviation and CAPA management, and structured change control.

The insight we kept returning to: compliance failures in manufacturing are almost never caused by careless people — they are caused by systems that rely on human memory to enforce the right behaviour. Our goal was to make the compliant path the only path available. Hard stops, automated triggers, locked historical records. The system enforces the workflow, not the individual.

Material planning was connected directly to the bill of materials and live stock levels, with FEFO logic auto-reserving materials and automatically generating procurement requests when stock fell short — every action timestamped in the audit log. QC was triggered automatically on material receipt. Out-of-spec results instantly blocked the lot and forced a documented Scrap or Return decision before any batch could proceed.

CAPA management was rebuilt with a strict lifecycle: Root Cause, Corrective Action, Preventive Action, QA Approval — in that order, with no shortcuts. CAPAs could not be closed without effectiveness verification. For change control, all BoM, SOP and packaging changes required a formal digital change request with full impact analysis. Approved changes auto-locked historical batch records, preventing retrospective data manipulation.

Before go-live, we ran a full parallel period where every paper process and its digital equivalent ran simultaneously. This was deliberate. In a regulated environment, the cost of a process error during transition is too high to absorb. We resolved three edge cases during this period that would have caused compliance gaps if we had gone live without it.

For the floor team, the experience was simpler, not more complex. Fewer forms, no ambiguity about which version to use, and the system would not let a step be skipped. The compliance rigour was built into the interface — they did not have to carry it in their heads.

84%
Reduction in batch documentation time — 3.5 hours per batch down to 35 minutes
Zero
Audit findings after go-live — down from 6 findings per year
99.2%
Inventory accuracy achieved — up from approximately 74%

They Had SAP. It Was Working.
The Problem Was Everything Around It.

A chemical distribution business had invested close to ₹8 lakhs in SAP Business One. Finance ran on it cleanly — GST filings, statutory reports, vendor payments, all handled without issues. The accounts team knew the system well and nobody wanted that to change.

The problem sat everywhere else. SAP at that licensing tier is rigid by design. Any change to how a report looked, how an approval flowed, or how a custom field was added required a certified SAP consultant or a change request to their implementation vendor — both expensive and slow. Over time, the sales team had quietly stopped using their SAP modules. The interface was built for accountants, not for people trying to close deals. They moved back to calls, emails and notes. The operations team followed.

The result was a business running two parallel realities. SAP had the numbers. The operations team had the actual picture. Every month-end involved manually cross-referencing the two, and errors surfaced only after dispatches had already gone out.

When we first mapped their process, we found three separate points where the same data was being entered manually by different people — each believing the others were not doing it. This was not a discipline problem. It was a systems problem.

How we approached it

The brief was clear from day one — SAP stays, and the finance team does not change how they work. We implemented Odoo to handle everything customer-facing: quotations, sales orders, delivery management and follow-ups. The interface was familiar enough that the sales team adopted it within days.

Most vendors would have proposed replacing SAP entirely. We rejected that approach because the finance team's workflows were deeply embedded and fully functional. Ripping out a working system to replace it with another is not a solution — it is a risk. We designed the integration so each system did only what it was genuinely better at.

We built a sync layer between Odoo and SAP so that confirmed invoices pushed accounting entries into SAP automatically, and stock movements updated SAP's inventory ledger in real time. The finance team saw everything they needed in SAP without any manual re-entry from the operations side.

The harder part was product master alignment. SAP and Odoo used different internal codes for the same items — a common problem when two systems grow independently. We built a translation layer that mapped between them silently. The first sync run flagged 23 mismatches we had not anticipated. We resolved each one and added validation logic so that any future mismatch triggered an immediate alert rather than a silent failure discovered days later.

From the team's side, nothing changed except things started working. The sales team used Odoo. The finance team used SAP. Neither needed to know what was happening in between.

Zero
Manual re-entry after go-live — work the system now does automatically
12 hrs
Per week returned to the operations team — time spent on work the system should have been doing
11 wks
From first conversation to fully live — finance workflow untouched throughout

One Business, Two Countries, Three Currencies —
No Unified View of Anything.

A manufacturing business had production operations in one country and a sales and distribution entity in another. Two legal entities, two tax regimes, two currencies, two sets of books — but one ownership group trying to run it as a single business.

Both entities had software in place. The problem was that neither talked to the other, and neither had been set up with cross-border operations in mind. Intercompany transfers were tracked on a shared spreadsheet updated once a week. Landed costs were calculated manually and added to the overseas entity's books by the accountant at month end. By the time those numbers landed, the data was two to three weeks old.

The owner had no real-time view of consolidated margins. When a large export order came in, the sales team confirmed it based on what they believed was available. The goods had already been committed to another shipment on the production side. The resulting delay was significant enough to cost them the customer relationship entirely.

Two vendors before us had proposed running two separate ERP instances connected via middleware. On paper it sounded reasonable. In practice, syncing two live databases across borders introduces lag, conflict resolution failures, and a single point of failure that tends to surface at the worst possible time. We told them this upfront. They appreciated the honesty.

How we approached it

At Kevisons, we do not add complexity to solve a complexity problem. The right answer here was one system, not two systems trying to behave like one. We set up a single Odoo instance with two companies inside it — each operating independently day-to-day but sitting on the same database.

Intercompany transactions were fully automated. When the production entity shipped goods to the sales entity, the system generated a corresponding intercompany purchase order on the receiving side automatically, with transfer pricing rules applied. The moment a shipment was confirmed, both entities' books reflected it — no spreadsheet, no weekly update, no lag.

We configured separate tax engines for each entity's local regime and set up live exchange rate synchronisation between both currencies. The owner could pull a consolidated P&L across both companies in either currency with a single click — something that had previously taken five days of manual reconciliation every month.

For inventory, we built a three-stage flow — production warehouse, goods in transit, destination warehouse — with landed cost allocation at point of receipt. The overselling problem was resolved through available-to-promise logic that automatically blocked stock already committed to a confirmed shipment.

Each entity's team used Odoo exactly as they would for a single-country business. The cross-border logic ran in the background. Neither team needed to manage it.

1
Unified system across both entities — one source of truth, no sync risk
Real-time
Cross-border inventory visibility — overselling became structurally impossible
5 days
Of monthly reconciliation eliminated — month-end now closes same day

Their Custom ERP Took 14 Months to Build
and Six Weeks to Abandon.

An engineering services firm had commissioned a custom ERP from a software development company roughly two years before they contacted us. The project took 14 months to deliver, well beyond the original timeline, and cost considerably more than the initial quote. By the time it went live, the team was already fatigued from months of shifting requirements and delayed testing cycles.

The system held together for about six weeks. Purchase requisitions went missing between approval stages. Job cost reports did not match what project managers tracked in their own sheets. The billing module could not handle milestone-based invoicing — which was how the company billed nearly 60% of its contracts. Every issue raised with the vendor came back with either a multi-week patch timeline or a fresh development quote.

Within three months, people had found workarounds. The accounts team was back on their old software. Project managers had rebuilt their tracking sheets. The custom system still ran in the background — technically live, practically ignored — because nobody had the energy to officially declare it a failure.

When we met the business owner, he was not interested in a pitch. He had heard every ERP pitch before and had the invoice to show for it. His only question was: how do we make sure this does not happen again? That question shaped everything about how we approached the engagement.

How we approached it

Before any configuration work started, we spent three weeks with the team — not on calls, but on the ground. Watching how purchase requisitions were actually raised. Sitting with project managers to understand how costs were tracked against contracts. Walking through how partial billing worked on long-term projects. We documented every workflow in plain language and got sign-off from each department head before opening Odoo.

This is how we work at Kevisons: the system gets configured to the business, not the other way around. The previous failure was not a technology problem. It was a process problem that technology had been asked to solve without anyone first understanding the process.

We recommended starting with a clean database rather than migrating from the old system. The data structure was inconsistent — vendors entered multiple times under different names, account heads with no standard chart, old job codes mixed with active ones. A clean start with properly structured master data would cost less time than cleaning what existed. We migrated only what was essential: open purchase orders, active project records, current customer balances.

The job costing configuration was the most critical piece. This business ran fixed-fee, milestone-based and time-and-material contracts simultaneously. We built three billing workflows within Odoo — each mapped to the contract type — so the system handled all three without the accounts team needing to remember which logic to apply manually.

We ran a four-week parallel period before full go-live. Both the old process and Odoo produced outputs simultaneously. The team cross-verified daily. It added time to the project. We recommended it anyway, because by the time we switched over completely, no one had any doubt about whether the system could be trusted.

Full team adoption within six weeks of go-live — the same timeline in which their previous system had been abandoned. The difference was not the software. It was the groundwork done before the software was touched.

100%
Team adoption within 6 weeks — same timeline the previous system was abandoned in
3
Billing models configured correctly from day one — no post-go-live rework
4 wks
Parallel run before full go-live — trust built before the switch, not after

Your situation is probably different from all of these.

That is exactly why we start by listening, not proposing.

Get a Free ERP Analysis →