ID-INFO blog
How long does it take to leave IBM i?
Last week I was talking to an IBM expert who explained that 5 years ago, new management complained that their IBM i system was really old.
Why? Because it was based on characters instead of a graphical interface. As a result, they chose to replace it with a SaaS CRM based on a graphical interface. This IBM i expert has lost his job.
As an experienced IBM i user, it came as no surprise that 5 years later, SaaS CRM with its graphical user interface had not replaced the IBM i system. Although the company spent a lot of money, the replacement project was a failure. The innocent were punished and the guilty were promoted.
Sound familiar? How is this possible? In fact, a quick Google search on “what percentage of ERP implementations fail?” will tell you 75%.
Translation of the original article by Robert Losey: http: //ow.ly/pw4b50GiuFJ
I’ve seen and heard of many decisions to migrate IBM i applications to new GUI-based applications. Most of them cost much more than originally planned. For the few who make it to the end, they reach a delay of around 5 to 7 years more than the original 1-2 years (with many even further behind).
Perhaps you know of similar experiences.
Quite simply, the new management who made the choice to throw out the antiquated IBM i applications, are unaware of critical factors that have little to do with GUI screens. There are many root causes. Here are just a few examples.
Functionality and business logic. The evaluation to select the new system did not include an in-depth analysis of functionality and business logic in relation to the current IBM i application.
Nuance and specific refinements. The selection team was unaware of the nuances and specific software enhancements that had been added over decades of use.
Databases and file design – sometimes, the length of the fields is insufficient. In cases where field lengths can be resized, I’ve seen implementation teams ignore the fact that the associated field lengths don’t reconcile. I’ve also seen cases where file layouts didn’t include critical fields for the business specific.
Migration team lacking key team members with critical expertise and business knowledge – I have witnessed other cases where the application manager or key experienced users with deep process expertise were NOT included in the implementation team. As a result, key information and processes are omitted.
Implementation teams – I’ve observed implementations where one team knows software and nothing about infrastructure, another team only knows server hardware, another team’s knowledge is limited to Windows software, another team only knows networking – but ALL the teams don’t talk together or understand each other’s technology.
Non-standard data – Too-common non-standard fields updated by users for “notes” because the current software did not include fields for a specific new software.
Those who decide to replace IBM i applications are unaware that the current system has probably evolved over 2-3 decades, and includes nuances and tailor-made functionalities specific to the business. Worse still, they may not understand the business.
What’s the solution?
There’s no easy way to migrate software. Nor was there a simple solution 10 to 30 years ago when ERP software was first implemented. Software implementations are difficult. The most successful have team members who understand the business, dig deep to understand what they have and what they’re getting back, and set realistic goals to make the software work with the help of knowledgeable teammates.
What leads to failure?
The mindset that “this IBM i is obsolete because it has no graphical interface”. If it’s the impulse to change, beware.
Do you have questions or projects concerning your IBM i platform? Our teams are at your service. Contact us on 01 88 32 12 34, or via contact form.