What we learned implementing ERPs: what worked and the mistakes we won't repeat

Before building MKA, our team developed software and implemented ERPs in manufacturing companies, trading companies, service firms and public institutions. Some projects went very well. Others cost more than planned. We learned from both, and this is the honest list.

Mistakes we saw (and avoid today)

1. Starting with the software instead of the process

The most expensive mistake: install the system and “adapt the company later”. If nobody has defined how a purchase gets approved or who releases a credit order, the system just automates the mess. Today: the project starts with a process review and a list of decisions the company has to make before anything is configured.

2. Customizing everything

Every “make this screen do that too” request adds code that then has to be maintained, tested and migrated. We’ve seen systems so customized they could no longer be upgraded. Today: we first try to solve it with configuration (price lists, approval workflows, templates, permissions). We only build custom code when the business rule truly requires it.

3. Migrating “the entire history” without cleaning it

Loading ten years of dirty data brings ten years of problems: duplicate customers, products with three codes, balances that don’t reconcile. Today: we define what gets migrated (clean master data, validated opening balances, history only when it adds value) and reconcile balances with accounting before go-live.

4. Going live with a badly counted inventory

The opening stock balance is the foundation of the kardex and of cost. If it starts wrong, everything that follows carries the error. Today: go-live includes a planned physical count, with lots and locations where relevant, and a valuation reviewed with the accounting team.

5. Training everyone and no one

A two-day general training for the whole company is forgotten within a week. Today: we train key users in each area, who know the system in depth and support their teams, and we train by role using real cases from their daily work.

6. Going live in every branch at once

A “big bang” multiplies incidents exactly when the team has the least time to deal with them. Today: we prefer a pilot in one branch or area, stabilize it and only then roll out further.

7. Treating regulations as a detail

In Bolivia, invoicing, statutory ledgers and payroll have strict rules, and they change (Ley 1733 is the most recent example). A system that doesn’t keep up with them leads to fines and rework. Today: tax and labor rules live inside the product, parameterized and with effective dates.

What we repeat on every project

• An executive sponsor. Process decisions are made by someone with authority, not by the vendor.
• Phases with clear deliverables. Initiation, planning, execution and control, and closing. Each phase has a progress report and an itemized investment breakdown.
• Short deliveries. We work in two- to four-week sprints: the company sees something real working regularly, not just at the end of the project.
• Testing before go-live. Every important rule has its automated test, and key users validate with their own cases.
• KPIs from day one. We define what will be measured (closing time, inventory variances, days sales outstanding) to know whether the system actually improved operations.
• Support after go-live. The first month-end close on the new system always raises questions; being there that month makes the difference.

In short

An ERP doesn’t fail because of the software: it fails because of decisions not made, dirty data and users who never take ownership of the system.

That’s why today, in every MKA implementation, we follow our own implementation methodology, based on PMBOK, and start from Bolivian regulations already built in.