A second attempt after a failed ERP project

A second attempt only succeeds if it does not repeat the same mistake, namely starting right away. First comes the foundation: a cleaned data foundation, clarified processes and a governance that leaves control with you. On this foundation, Business Central can be implemented in a realistic frame, instead of getting lost again.

Why did the first attempt fail?

The first attempt almost never fails because of the system and almost always because of a missing foundation. The processes were not clarified before building started. The master data was not cleansed before migration. And it was not defined who may make which decision. Business Central then faithfully reflected what it was given, namely ambiguity.

That large technology programmes overrun budget or time is no isolated case and no failure of your team, but a structural finding. The eight most common patterns are in the article Why ERP projects fail. Whoever plans the second attempt should assume that the causes need to be named, not the culprits.

What is almost always missing in hindsight is a formal moment at which someone with full information asked: do we continue this project as currently defined? Without that moment, decisions still get made, only unconsciously and by people without the authority to make them.

What does the second attempt do differently?

The second attempt reverses the order. Cleanse the data foundation first, then migrate. Clarify the core processes first, then configure. Define decision rights first, then start. This sounds obvious, but in the first attempt it was in all likelihood exactly the other way round, because the pressure for visible progress was greater than the pressure for clarity.

You can carry more from the first attempt than you might think: process documentation keeps its value, so does cleansed data, and the requirements you have learned are more solid than any specification from the early days. What does not come along unchecked is the configuration and the customisations. Those are tested against the new target picture, not adopted.

The second attempt therefore does not start from zero but with an assessment. It typically takes two to four weeks and answers a single question: what holds, and what has to be decided again?

Why does the foundation decide, not the speed?

The foundation decides because speed in an ERP project is a false measure. A project that goes live in six months and then needs two years of rework was not fast. A project that takes eight months and then holds was not slow. What gets measured in the end is the time to reliable operation, not the time to go-live.

In practice this means three pieces of preparation that cannot be shortened: named owners per data object, documented core processes including the intended changes, and a decision cadence with fixed dates. These three cost a few weeks and, in our experience, save months.

Control stays on your side from start to finish, with Business Central as home. A second attempt that fully outsources responsibility again has not made the most important change from the first.