Six Notorious Pitfalls in the Pluripharm IT Debacle

Dutch newspaper de Volkskrant published an interview with Jan Dirk Jansen, director of pharmaceutical wholesaler Pluripharm. A failed ERP implementation caused thousands of orders to go undelivered. The article reveals six notorious IT pitfalls.

The remarkable article mentions glitches in software settings. Small errors have major consequences in a warehouse with tens of thousands of movements per day. I am not personally familiar with the Pluripharm case, but it is good that they communicate openly about it. It shows the enormous consequences of a flawed IT implementation. It not only impacts the company and its customers but affects the entire sector. This article highlights six notorious pitfalls.

Big bang

Director Jansen states there was no other choice than a completely new ERP software system for the entire flow of goods and money. Replacing all systems in one big bang, however, is a notorious IT pitfall that undeniably carries risks. Despite reportedly extensive testing, there were still bugs in the software. It is wiser to replace software step by step — for example, first the warehouse and then order processing. Especially with modern integration tools, connecting systems is perfectly feasible.

Traditional software

According to Jansen, Pluripharm chose the renowned JD Edwards from Oracle. Traditional software offers extensive features due to years of software development. Moreover, there are many big names using the software. However, we see a new generation of modern software emerging, often in the cloud. These packages are less comprehensive for now and cannot boast endless reference lists, but they are more flexible to adapt to company requirements. This makes it not only easier to implement the software but also to keep adapting it to new requirements in the future.

Long lead time

The implementation at Pluripharm took two years. That is far too long. It is impossible to work focused on a project for that long. The whole thing becomes impossible to oversee and the healthy tension disappears. Moreover, the assumptions that applied at the beginning of the project are already outdated by the end. Projects should not last longer than a year, preferably six months, with a clear beginning and end. This forces people to focus on the essentials and make decisions quickly. Anything that does not fit within the scope will be addressed in a follow-up project or perhaps was not as important as thought.

Customization

According to Jansen, the ERP was adapted to the company in collaboration with IT experts. When companies want a way of working that the software package does not support, it can be adapted through custom programming. This too is a notorious IT pitfall. Customization is risky, expensive, causes delays, and makes it difficult to adapt the package in the future. It is preferable to implement software without customization. Packages offer various standard ways of working. By cleverly combining these or by slightly adjusting current business processes, more is often possible than anticipated. However, this does require some creativity and, not to be forgotten, a healthy dose of change management. And if it really cannot be done without customization, you may have chosen the wrong package.

Integrated package

As mentioned earlier, Pluripharm chose one integrated package for all business processes. It appears that the package functioned well — except in the warehouse. Warehouses with relatively large numbers of transactions that must be processed in real-time typically have different characteristics than other business processes. Perhaps a specialized WMS would have functioned better here than the warehouse module in the ERP. It is wise to consider beforehand whether the integrated package should support all business processes, or whether you want to connect various best-of-breed packages. The goal should be the best possible business operations, not minimizing the number of packages. The latter is often strongly preferred by the IT department.

Unclear responsibilities

Who is responsible for this debacle? According to Jansen, everyone points at each other and it is legally difficult to hold the IT supplier accountable. Despite both parties pursuing a successful project, interests are opposed. The customer wants the best possible support at the lowest price, while the supplier wants to spend as little time as possible on components for which a fixed price has been quoted and as much time as possible on components (read: customization) that can be billed by the hour. The result is that the customer keeps coming up with additional requirements or revises earlier choices through progressive insight. This way, projects automatically end up in a customization spiral. It is high time for suppliers to take responsibility and deliver a well-functioning system within a fixed time and at fixed costs. The condition is that the customer adapts operations to the package and ensures fast decision-making. That may not sound appealing at first, but it is the best remedy against these kinds of disasters.


About the author
Jeroen van den Berg is the author of Highly Competitive Warehouse Management and holds a PhD in warehouse algorithms from the University of Twente. He has been advising companies on warehouse optimization and WMS since 1997, running his own consultancy since 2001. He develops Metrica, a Warehouse Optimization System.

Tags:
No Comments

Sorry, the comment form is closed at this time.