How to prepare for an ERP system implementation?

Continue reading

Every company management facing a system change wonders what steps should be taken to ensure that this change does not cause turbulence to its business. Identical dilemmas are faced by any IT company that provides services to implement a new system. I will focus on these dilemmas today.

Basic principles in the ERP system selection process

The selection and implementation of a system should be based on mutual trust and business satisfaction. Below, I will try to outline from my perspective the risks for both parties resulting from a system change.

I have more than 20 years of experience in consultancy and ERP implementation and maintenance. I ran an implementation company whose main motto was "We don't sell, we give the benefits of the new system". On many occasions I have also supported companies in the selection of a bidder by being on the other side.

Let's remember, and this should be the basis of every meeting, no matter which side we take, let's talk about the benefits of the new system and not just focus on the word 'system'.

The Titanic tragedy as a metaphor for business

Running a business is not easy and every business can be looked at from different perspectives. Most often we write and talk about indicators, i.e. the perspective of the CEO and management; on the other hand, we refer to the feelings of employees. In very few companies the concepts of objectivity and subjectivity go hand in hand. If they do, turmoil arises when investments are made, i.e. when new solutions are introduced into the company. One such solution is system replacement.

I often use the comparison to James Cameron's film Titanic in my articles. In the film, there is an allegory for business when we believe that our business is stable and promising, even indestructible like the most modern ship of the early 20th century - the Titanic. Often, in our view, the prospect of growth is only related to changing our old system for a new system that has been hailed as 'trendy' in the media. We say that it is very simple and there is nothing to be afraid of - after all, we take the best consultancy and implement the best system.

Confirmation of this traditional approach is what an employee of one company who was faced with the decision to replace a system told me: In the end, nothing will change. We will still be sitting in the same chair and at the same desk.

Does symbiosis exist in business?

Not many companies know how to prepare for the implementation of an ERP system and how to make conscious decisions regarding organisational changes in the company. Let us remember that during any implementation process, we have two business entities: on the one hand, the company ordering the service and, on the other hand, the company providing this service, i.e. the implementation company.

OK, so now I climb into the crow's nest and look at the sea horizon in front of my ship. What do I see? Unfortunately - icebergs. Here they are:

Personal composition

The first fundamental problem that occurs when selecting a system is the lack of delegation to key people in the implementation process.

For meetings with companies presenting solutions and implementation methodologies, we choose people who will not be involved in the implementation process, or the composition of people at such a meeting is incomplete. We are guided by the current wellbeing of the company rather than looking ahead.

  • Delegation of authority should take place at the system selection stage and at the selection of the implementation company. The composition should be such that key people cover all business areas of the company. If we are dealing with a manufacturing company, I cannot imagine that the key people responsible for production planning and scheduling are not present at the meetings. If we have a defined implementation team, then a person should be selected to manage all the processes involved in selecting the system. A good project leader needs to plan and agree all business functions and schedule meetings.
  • A budget must be prepared to fund the running of the project. The project leader must be assertive, motivated and have the authority to make decisions that take the project to the finish line.
  • We should already have all the business functions written down in a functional requirements document. I advocate that the document containing the current and future processes should be written by an external entity. The most important element, however, is for all of us in the meeting to know what benefits the system can provide us. Our meeting with the company presenting the system and the implementation process should be preceded by the handover of such a document and a meeting between the project leader and the leader on the implementing company's side.
  • The project leader should set a schedule of meetings to include all key people at each meeting with the supplier. The attendance of all stakeholders at the meeting means that with each presentation we gain knowledge of the system's capabilities, so we can make informed decisions about the provider in the future.

Fluctuation of people in teams

Another iceberg is the severe shortage of specialists in the ERP world.

Vendors start by putting up their best employees for sales presentations or project launches and then gradually replace them with less competent people. The hard-won knowledge transferred between teams during the sales cycle is mostly lost in communication with the customer.

It is worth insisting on a vendor-customer care model, in which the supplier appoints a single, unchanging team that deals with the customer from start to finish, and in the event of changes in the team, the new person is guaranteed to be implemented free of charge.

Company metrics

Don't overly worry about finding a supplier that has experience with the latest version of the system being implemented. Just make sure the supplier is capable of adapting the new version.

For example, the current Microsoft Dynamics 365 system receives version updates at intervals of several weeks. If the software provider demonstrates repeatable system version upgrades, based on the experience of their team as well as the tools they use, then you can be sure that your system will always have the latest developments and adaptable functionality as your business grows.

Service

If we are in the area of version upgrades, then I suggest always asking for a demonstration and reference from the service department. Let's find out if the supplier in question offers only support for system implementation or if they also provide warranty, service contracts and development work.

Most companies see their profit only in the sale of licences and the implementation process. The post-implementation stage is the least profitable, so they do not plan to invest in this area for economic reasons. This approach makes the business of the company where the system has been implemented vulnerable to delivery turbulence resulting from possible system problems. Choosing a new IT service provider as a future system maintainer involves the time and financial cost of getting to know the solutions implemented in the ERP.

Any professional implementation company provides an implementation and post-implementation guarantee. The implementation of the first stage is carried out by a dedicated project team, while the implementation of the second stage - stabilisation and design of future solutions - belongs to the service team. The service team acquires knowledge of the parameterisation and implemented solutions internally, without exposing the client to costs.

Innovation and technological development

When choosing a system provider, it is worth finding out whether it is just an implementation company selling a licence or an innovation company? Does the company have a research and development department that will provide cutting-edge technology that will make your business have, for example, a tool for predicting costs and meeting plans or budgets?    

References

When selecting a supplier, it is worth considering where you heard about the potential supplier:

  • Was it a sales meeting?
  • Was it press articles written by analysts, architects representing the supplier?
  • Was it international conferences and trade fairs in which the supplier actively participated?
  • Maybe we learned about the supplier through a direct recommendation?

Stages of the implementation process

Avoid the temptation to start the project with a lengthy sales process, trying to understand all the requirements to ensure the maximum accurate quotes and commitments from suppliers. Although on the surface this seems like a good idea, such a detailed approach to the request for proposal is more likely to end in project failure.

Time pressure

A very important element that new system owners fail to deal with is the pressure to start a project quickly.

Time pressure artificially created in the bidding process causes us to lose control of the project. Don't allow the system supplier to start work until the process owners on your side have approved and signed off the specification - no exceptions. Any change to the process exposes you to additional financial costs.

When it comes to warranties, many suppliers will do anything to avoid responsibility to your company. Never agree to sign a contract where the responsibility assignment matrix (RACI) does not include a partner. Don't accept vague promises to 'help' with delivery, 'support' your team or 'manage' targets. You are paying a supplier to design, build, configure, populate with data, correct, deliver, implement and guarantee the operation of your system. Don't accept a quote that doesn't include all these elements.

Licences

Another iceberg is the client's licensing requirements before analysis and full definition of design and organisational changes.

It is entirely feasible and realistic to start a version of the application with a 10-user system and only add new users when necessary. You will be paying the software manufacturer's support fees for each licence from day one of their purchase, giving you zero return on investment. Don't let the reseller put pressure on you to buy an inflated number of licences outright.

At the beginning of the article, I wrote that success is to eliminate all the risks present in the implementation process. Above, I identified the safeguards of the principal, i.e. the new system owner. Below I will present some icebergs, looking from the side of the implementing company.

Communication

Remember that the key element is to understand the client's processes.

During a system change, I adhere to the principle of 'show, don’t tell’. It is accepted that 65% of people are visual. It is visual content that will drive engagement and understanding with the software provider. If you have a manufacturing company, show the problems occurring on the shop floor. If you want to reap the benefits of advanced transport functionality - show your transport fleet and ask about the automation of the processes that take place there. My proposal has always consisted of four elements:

  • Gathering information.
  • Preparation of a 'beta' bid prototype.
  • Meeting with key people in the company.
  • Presenting the solution concept in front of the board.

The implementation of the first point was done by reading the functional requirements documentation and meeting with key people in the company. On the basis of the material on current and future processes, I designed a "beta" prototype for the offer. I wrote down the guidelines of the solution prototype in a document, which then formed the basis for minor visual development work. This mostly involved buttons, dictionary fields, workspaces, etc.

When the prototype was ready, we would agree a date for a meeting with the project manager, at which it was mandatory for all key people in the company to attend. One meeting was attended by as many as 25 people on the client side. The description and proceedings of the meeting could form a chapter in Stephen King's books.

I have always believed that risks should be eliminated at the initial stage of the process or a compensation factor should be determined during the implementation process. My methodology boiled down to bringing together at the solution concept stage everyone who would have an impact on the quality, timeliness and cost of implementation. Opposite the client, in this example – 25 people, sat my project team. In such cases, quantity does not always indicate, to use sports jargon, victory.

Prototype

I know from experience that the larger the organisation, the more prone it is to unfamiliarity with whole company processes and data redundancy. For me, the process is always the most important thing.

I started from the very beginning, presenting the solution, based on standard functionalities and discussed future solutions, showing the 'created in the prototype process' button. The next element was to enter into a conversation with the key user responsible for this part of the presented process. This part triggered a huge internal customer discussion.

As I have written, the big iceberg that the client itself cannot see is the unfamiliarity with the processes. In every organisation, on both the client and contractor side, there are specialists – key people in a particular area, but unfortunately only in a particular area. This is a very important element that can torpedo the whole implementation process by underestimating the offer from the supplier and the client not securing adequate resources in the budget.

For me, such a meeting is particularly energetic, but it provided me with information on the consistency of processes on the client's side of the organisation and gave me feedback on my understanding of the client's processes.

Can we be an authority for the client?

This meeting was supposed to last three hours, but it lasted seven. Most of the time was taken up by disputes within the client organisation. A day spent on a presentation or functional analysis, without input from the supplier, is a day lost. This meeting, despite its tumultuous course, produced four positive elements:

  • Improvement and consistency of internal processes.
  • I got to know the customer as they are and the processes as they are, with a definition of what they are supposed to be.
  • I and the team became an authority by moderating the meeting – invaluable at this stage of the client-supplier relationship.
  • The offer was relevant to the achievement of the objectives by each party.

Summary

Remember that there is no room for secrecy in the product bidding process. Clearly declare your budget upfront and insist that the supplier say whether the project objectives can be achieved with the assumptions given.

Always remember that a successful ERP implementation involves the principal and the contractor being on the same ship and sailing in the same direction. Let's be prepared for possible storms and tempests – with proper schedule control they will never surprise us.

Most importantly, project managers on both the supplier and client side should always be at the highest point of the ship, i.e. in the 'crow's nest', and make the right decisions by keeping an eye on the horizon.

More articles
Explore our blog

What can we do for you?

We'd love to hear about your project. Our team will get back to you within two working days.

Thank you for inquiry, we’ve passed it to our sales department, our representative will reach you back in his earliest convenience.
Oops! Something went wrong while submitting the form.