Projects are set up in order to deliver the key requirements that the business will need to operate on the ERP system that has been chosen.
ERP projects are complex in nature as the ERP system is often core to the business and therefore implementing it cannot be done in isolation.
There are many facets to an ERP Project which include;
The ERP system itself
How the system integrates with other systems
Business processes it supports
External Business requirements
External influences such as legal, fiscal or regulatory requirements and social, political and environmental factors
Project Teams and resources
Throughout any project controls and measures have to be in place to ensure that the project is not getting out of control. You need to review the status of your project as it proceeds to make sure things are on track, evaluating any potential risks and putting the appropriate actions in place to mitigate them.
The key controls that need careful monitoring are scope, schedule, cost, quality, resources, performance, stakeholder management, risks and contract administration and change control.
Without proper monitoring and control, projects can easily spiral out of control, incurring additional costs, encountering significant scope creep or a poor quality implementation.
There are various approaches to monitoring projects, two most popular Project Management methodologies are Prince2 (which originated in the UK) and PMI (which originated in the USA).
An ERP methodology is a framework used to structure, plan and control the implementation of your ERP system.
It will likely include tools, templates and things that need to be completed or delivered by the project team during the implementation. It aims to provide you with a framework to accelerate your implementation while providing a structure within which to operate.
There are plenty of methodologies and approaches around for running a successful ERP project.
The terminology differs slightly between ERP products and suppliers, the tools and accelerators may be slightly different, but fundamentally the underlying principles and approaches are all very similar, built up on years of experience and expertise.
Systems Integrators can reel off hundreds of examples of successful implementations that they’ve been involved in.
Delivered on time and on budget, with a myriad of benefits delivered to the customer. They can also wax lyrical about why their methodology is better than their competitors.
There are tried and tested routes for implementing a new ERP system in a business and plenty of expertise in the marketplace. More than likely the methodology you use on your project will be dictated by the product you choose and the Systems Integrator you select.
For example:
SAP’s methodology is called SAP Activate, this is a framework that uses SAP best practices and agile methodology to deliver a quality solution quickly. It contains ready-to-use business process content, tools and accelerators, how to guides and templates.
There are four main project phases within SAP Activate:
Prepare - getting everything in place ready to deliver the project.
Explore - reviewing the solution in more detail and confirming the business requirements. Establish what you can achieve in the timeframe. Confirm the solution.
Realise - realise the solution and bring it to life through building and testing.
Deploy - once the system is built and tested the deploy phase is looking to get the system operational in the business.
Oracle uses a methodology called AIM (Application Implementation Methodology). Again the AIM methodology provides a framework of accelerators, templates, tools and methods to assist the implementation.
An AIM project is split in 6 phases:
Definition - review the project objectives and evaluate whether these can be achieved within the time, resource and budget constraints. Build an achievable plan.
Operational Analysis - develop the business requirements and assess gaps between the standard application and the business requirements. Provide solutions for gaps in standard functionality.
Solution Design - develop the detailed designs for the optimal solutions to meet the future business requirements.
Build - coding and testing of all customisations, enhancements, data conversions, and interfaces. Includes business testing to validate the solution.
Transition - deploy the finished solution into the organisation. End users are trained while the technical team configures the production environment and converts data.
Production - marks the last phase of the implementation, and the beginning of the system support cycle.
Microsoft Dynamics uses a methodology called Sure Step. As with the previous two examples, the premise is the same, providing a framework or templates, how tos and accelerators to get and keep your project on track.
The project is split into 5 phases:
Diagnostic - to understand the high level solution requirements in order to help the customer determine the right solution to meet their needs.
Analysis - the official start of the project. This phase defines the activities required to initiate and effectively plan the rest of the project.
Design - focuses on how the business requirements will be implemented, creating a solution for the team to build.
Development - the implementation team will build the system components defined and approved, including configurations, customisations, integrations and interfaces and data migration processes.
Deployment - the solution will ‘go live’, but there is much more to it than that. Users will be trained then perform their testing and acceptance activities to validate that all of the requirements for the project have been satisfied.
Operation - any final activities to officially close out the project are performed and where the solution is officially transitioned to the customer including providing any remaining knowledge transfer.
These three examples show how each ERP vendor will have their own methodology and best practice for implementing their product.
To complicate matters further there’s a good chance that the Systems Integrators will also have created their own methodologies based on their experiences and bundled their own templates and accelerators into a toolset as well.
Trying to differentiate themselves from the competition.
The SIs methodology could well be based on the ERP vendors methodology but with bells and whistles to make it better and to differentiate them from the competition.
Although the terminology between the methodologies and toolsets may vary slightly, and the phases may be slightly different, the underlying approach of all the ERP methodologies is the same and follows the same logic.
Before starting any ERP project you need to establish why you are even doing the project in the first place. What’s the main driver for implementing a new ERP system or for upgrading an existing one?
We’ve already established it can be a costly exercise but for what return? What will the business get for this significant IT investment?
Creating a robust and coherent business case to understand why you’re doing the project is the first step on your ERP project journey.
Unfortunately it's the one that often gets overlooked...
To all intents and purposes, the business case is a document that offers the reasons for implementing an idea or a project, in our case the reason for implementing the ERP project. It collates and considers the benefits and costs of the ERP project going ahead.
In contrast it should also consider the risk of doing nothing and the implications this may have to the business short-term and longer term.
Through the business case we are aiming to outline the future vision of the organisation from an ERP system perspective. It forces us to question whether it’s the right thing to do, to consider the options available and the costs and benefits of each, it helps us to validate the decision made.
The business case details the pros and cons of the ERP project, to enable executive management to decide whether or not the project should go ahead. By doing a business case you are ensuring that the right level of rigour is given to the investment decision.
You ensure that as an organisation your decision to invest in an ERP project is considered and that the implementation is not just the result of an individual whim or someone thinking it might be a good idea.
Despite the obvious benefits of a business case, some organisations just don’t see the need for one. It’s just additional paperwork, a waste of time and effort, this can certainly often be the case on ERP upgrades. The IT department makes the decisions and knows what’s best for the business. They dictate the direction of travel. The business does what they say.
Playing devil's advocate though if you haven’t considered the different options that are available, how do you really know that you’re making the best long term decision for the business, and to support your plans, actions and goals to compete in the marketplace. Will it support your business strategy?
If IT doesn't know what the business needs, how do we know their recommendations are right for us? They might be the technical experts but they aren’t the business experts.
The business case can also be used to define the approach necessary to achieve the project goals and manage the project risks.
If done right, it becomes the point of reference for managing both the scope and success of the project, by clearly outlining the implementation objectives. It should be a document to which you continually refer for the duration of the ERP project. Your point of reference to remind you what you are aiming to achieve.
It serves as a powerful tool for leading the business change and for getting the business to ‘buy in’.
If you don’t know what you’re trying to achieve, how do you know that you’ve been successful? It’s a yardstick for the executives to monitor and gauge the ERP project’s success.
Time and time again it’s been proven that having a good solid business case in place, that’s embedded at the heart of the project, significantly increases the likelihood of a successful ERP delivery.
It’s one of the key levers to ERP project success.
To sum up a business case should offer reasons to implement an idea or a project. It establishes and formalises the objectives of the project, detailing the what and the why. It becomes a guide to refer to throughout the project, to validate scope and to manage change. It allows you to monitor progress and evaluate the results of the project after its completion. Remember, every ERP project should have one.
A KPI is a Key Performance Indicator.
These are measurable values defined by the business that enable them to measure and monitor their performance. They are measurable and quantifiable and they enable the business to show the progress of the organisation against its defined goals and strategies.
KPIs can be financial in focus and tied to financial data, for example, looking at the profitability of the organisation, the revenue generated or the operational cash flow. They may also be non-finance related, more anecdotal, for example, customer satisfaction, customer footfall, repeat customer sales, employee retention, absenteeism. The list goes on.
As you’d expect KPIs vary between organisations and also between and within industries. For example, a bricks and mortar shop retailer may be interested in actual sales per employee, however, in contrast, an online retailer may be more interested in conversion rate of website hits to actual sales.
KPIs are dependent on the performance criteria the organisation has defined for itself. They should align to your strategy, goals and objectives and as such are unique to you. When it comes to KPIs, more is not necessarily better, a succinct targeted, well defined list can be more effective than a longer rambling list.
The list of possible KPIs that you might want to measure is vast but here’s some examples of the things different industries sometimes measure as a taster.
Within Aerospace you might want to look at flight departure punctuality, what percentage of your flights take off from their departing airport on time? The airline timetable is delicately balanced in terms of the aircraft availability and staff, getting planes and crew to the right places at the right time is imperative. Delayed flights can have a significant downstream impact for airlines, create chaos and cost them money. Understanding the volume of delays and correlation of delays enables you to build this into your plan schedule.
Measuring and monitoring the reasons for your aircraft delays. Understanding this lets you start looking into operational issues that you may have. Some delays may be out of your control such as the weather or acts of nature but others such as technical issues or ground handling might highlight an operational issue that needs to be addressed. For example, why does the 06:30 am flight to Brussels every Monday sit on the runway at Manchester for an hour and take off late?
How full are each of your flights? How many of your flights are taking to the air half full? How many bums on seats are there?
If the plane is only 50% full, is it covering its costs when it takes to the air? Regardless of how full it is you still need to pay for fuel, airline crew wages, airport costs. Understanding occupancy or seat load on each flight enables you to calculate which routes are popular but also which ones are profitable and make money.
Within food manufacture you might want to measure the operational throughput of a particular production line, machine or site. How many tins of beans can you manufacture on a particular machine, at a particular production facility in a 24 hour period?
Compare this to another production line or site, if line B can produce 20% more tins of beans in a 24 hour period than line A does it highlight operational inefficiencies?
When machines are down you can’t manufacture anything, as such you may want to monitor the unplanned downtime of your machines. If the machine is down unexpectedly then your planned production volumes will be down and your staff could be standing around twiddling their thumbs, costing time and money while producing nothing. Ensuring machines are kept operational is a key factor in the manufacturing process, downtime needs to be planned and controlled. Understanding when and why unplanned downtime occurs might let you take action that will keep the machines available and in turn will reduce costs and improve profitability.
Within the retail sector you might be interested in the Sales Conversion Rate, whether it’s footfall within a store or website hits, how many actually convert to and result in a sale? If you get a lot of traffic but no one makes a purchase then the chances are that you’re doing something wrong.
The flip side of this is also understanding the return rate, sales might be through the roof which is great, but if the majority of sales get returned then that’s a different story. Knowing how many sales result in a corresponding return is critical. How many of your sales actually stick?
Measuring and understanding your return rate might identify potential issues with a product or service. For example, does a particular dress look great and sell out within hours but 90% are returned as the quality isn’t good, the sizing is wrong or the item is flawed.
How long does a customer spend browsing in your store or on your website?
Measuring customer dwell time may be beneficial. Depending on your business and what you are trying to achieve may impact how you perceive dwell time and whether you want dwell time to be high or low.
For example in a fast food outlet, customers want to be in and out as quickly as possible, they know what they want and the longer they spend in store the more frustrated they get.
They don’t want to browse, they want to get in, get served and leave. The clue is in the name they want food and fast.
Same from the supplier’s perspective you want to serve as many people as you can in as short a time as possible.
At the other end of the scale the longer a customer stays in a car showroom to browse the more interested they are potentially and the more likely to buy a car, if not this time around they may well return. So in this scenario a long dwell time may be a positive. This is often why car showrooms offer seating areas, free coffees, biscuits and snacks, all part of the plan to keep you there longer and try to entice you to buy.
These are just a few examples of KPIs which may benefit the business. Whatever KPIs are defined, the key to being able to measure KPIs is data. KPIs require accurate data to be captured which is where your ERP system can help.
As a rule of thumb large system implementations often tend to be driven by the IT department.
They determine the direction of travel for the business in terms of systems as they understand the technical jargon and the technical requirements.
Very often the business doesn't want to be involved.
The IT department decides the technology needs to be updated, they decide on what the new solution should be, they get the budget approved and mobilise the team to get the job done.
The business doesn't need to worry or be involved, from their perspective it’s seamless. Perfect it never fails they’ve got the experience and the know how...
Wrong.
Let’s be clear, IT led projects certainly have their place but inevitably they tend to focus on the technical aspects of delivering a solution and focus less on how to support the business users and processes. This is fine for infrastructure changes and technical upgrades which don’t particularly impact business functionality or process, but when implementing an ERP system it’s a recipe for disaster and a sure fire road to failure.
By definition your ERP system is the backbone of your business, it supports your processes and as such the system requirements need to be defined by and driven by the business.
So what does the business want and need?
They are instrumental in the decision making, they are the ones who know what the ERP solution needs to be able to do for the business to function successfully. They also know what’s wrong with the current processes, the manual tasks that are being done outside of the systems and the workarounds that are in place because the current system processes are deficient and don’t meet the business needs.
The chances are implementing a new ERP system will fundamentally change the underlying business processes and ways of working.
The ERP project is an opportunity for change, to shape the business for the future and to improve things. It’s an opportunity to eliminate waste and streamline processes. Imagine it done right it might move you from a 7 day order to delivery process to a 24 hour order to delivery process.
Is there any point doing things the same? The same business processes on a shiny new platform? If your ERP project doesn’t improve things it’s an opportunity missed. There needs to be a vision, a strategy and a clear goal defined by the business leaders.
Strong business sponsorship and leadership is critical.
Business buy-in and engagement is the key to your ERP project's success.
Over and over we see ERP systems implemented, maintained and driven by IT departments with no strong business involvement. The business has no vested interest to make it better or for it to succeed. There is no sense of ownership from a business perspective, and the ERP system is viewed as an IT system rather than a business solution.
You want to ensure the ERP project is a success and is embedded within your business. IT and the business both need to work together, but the business needs to drive the solution from start to finish and ensure it is fit for purpose.
The ERP Ecosystem considers all the engaged parties in the implementation and running of an ERP solution.
At the heart of the operation is the ERP system.
There are many suppliers in the lifecycle of the ERP system including
ERP vendors
ERP Implementation Suppliers
ERP Support Suppliers
ERP Integrated Systems Suppliers
Infrastructure Suppliers
Support suppliers
Consultancies
Contractors
All of these different suppliers form part of the ecosystem of support where they work together with the one aim to ensure successful system implementation and support.
There are many ERP vendors globally. ERP vendors exist at all levels of the life cycle. Some vendors specialise in the implementation of the ERP system, others specialise in provision of outsourced services.
Organisations, depending on what their core business processes are, may outsource all of their ERP system and support to one or a few key vendors, other organisations only use vendors for the most complex solutions.
The top five key ERP vendors in the world are;
SAP (S/4HANA)
Oracle (Netsuite)
Microsoft (MS Dynamics)
Workday
Sage
There are many more ERP vendors, we’ve created a link to a list of vendors that will help you when you decide which path to take on your ERP career.
We will come back to this when we explore how to get a career in ERP.
When you decide to embark on implementing a new ERP system, chances are you’ll need some specialist skills to help and guide you. People who’ve been there, seen it, done it and have the battle scars to prove it, the experts who can guide you and help you push the implementation over the line.
More than likely this will take the form of an Implementation Partner or Systems Integrator.
This will generally be an external company who specialise in implementing ERP projects, they may even specialise in implementing specific ERP products.
They will provide a team of external resources with specialist software product and industry knowledge to support you through your implementation.
Be under no illusion, SIs don’t come cheap. They provide a premium service to customers who need their help and they charge accordingly.
They aren’t a charity and are in business to make a profit. The key to making the relationship work is knowing how to manage it.
That said there are real tangible benefits to using a third party on your ERP implementation.
The likelihood is that very few of your employees will have been involved in an ERP implementation before and the couple that may have previous experience may have only been involved in one or two implementations.
A Systems Integrator will have done it numerous times before, they should know the pitfalls, they’ve seen it all before and hopefully learnt the lessons.
With each implementation they should have refined their approach, so they’ll hopefully have a tried and tested way of doing things and more than likely bring their own toolsets and accelerators to help things along. They will bring specialist product knowledge with them to smooth the process and ensure it is a success.
Chances are your internal staff are already maxed out on their day jobs and are already struggling to do what’s required of them day to day to run the business. Very few businesses have a team of people sitting with nothing to do ready to embark on a new project.
How do you free up a small army of people to implement an ERP project without negatively impacting the day to day running of the business? That’s where your SI comes in, they provide the resources you need to augment your team and to work with the business to get the solution right.
Chances are they will also have a pool of resources on which you can pull if you have any specific skills gaps that need plugging. They won’t only bring ERP knowledge, if they are good, they’ll bring industry experience along with general IT experience and examples of what other customers have done.
They’re used to navigating the IT world and will be able to provide advice and input on innovations, other products and providers you may want to consider.
So the SIs can bring a lot to the party, the key is maximising the benefit they can bring. Get it wrong and it can be a disaster.
The trick is to build a successful partnership that delivers mutual benefit. If things are weighted too far in one party's favour, no one will benefit long term.
Understand that your supplier is entitled to make a reasonable profit just as you are entitled to expect value for money. Don’t see your job as beating down your supplier on cost or beating them up about delivery.
Your job is to deliver a successful outcome for your business and that is as much about you being a good customer as them being a good supplier.
Treat your suppliers as partners.
Be clear and transparent in what you are trying to achieve and work together.
A good customer should understand their contract and be clear on their own deliverables and obligations and be just as strict in holding their own organisation to account. Of course, you should also hold your supplier to account and be wise to sharp practices. An SI with revenue and profit targets may be tempted to behave in certain ways.
Be aware of this but recognise that a contract with the right amount of tension between parties — one that allows the supplier to make a reasonable profit — will be one where they are less tempted to try and exploit you.
When engaging with a Systems Integrator you will agree to a number of deliverables which are expected of them during the contract.
These deliverables outline what you expect them to achieve and also to produce e.g. specific documents, by the end of the piece of work in order to fulfill their contract. What will they be responsible for delivering?
These contractual deliverables will be outlined in a Statement of Work (SoW) to which both parties agree.
The SI is responsible for the management of their own resources and for ensuring that the deliverables outlined within the SoW are achieved. This means that they need to ensure that the right resources are assigned to the piece of work. They’ll do whatever is required to achieve their contractual obligations for example they may need to bring in additional expertise or resources in order to get the job done.
Systems Integrators come in various shapes and sizes, from the Big 4 consulting firms - PriceWaterhouseCoopers, KPMG, Deloitte, Ernst Young, to ERP vendors themselves - SAP, Oracle, Microsoft, to the small niche ERP consultancies. The list of options really is endless. Different SIs offer different project delivery models, again you need to consider which delivery model fits your business best.
Some SIs may be based onshore, some offshore or they may operate an offshore or hybrid offshore delivery model with resources based remotely in another timezone for example India or the Philippines.
Back in the 90’s all ERP projects were generally delivered using what was known as an onshore delivery model. Your SI consultants were on site working with the customer full time. Projects were often big, taking years to complete. Meetings were held face to face and consultants travelled relentlessly to meet customers and get the job done, often travelling at the weekend and being away from home 5 days a week.
There were benefits to this approach, due to the lengths of the projects, the consultants generally ‘went native’ and became embedded within the customer team promoting a one team approach. There was continual interaction between the customer team and the SI team with lots of face to face interaction.
The downside was it was really expensive, consultant’s expenses were through the roof, airfares, train costs, hotel costs, restaurant costs, per diems. ERP projects were basically paying for consultants to live away from home for the duration of the project.
As we entered a new millennium the concept of using what were termed offshore delivery models started to be considered as an alternative for certain aspects of project delivery.
This enabled projects to open up the pool of untapped resources, accessing less expensive offshore resources who would work remotely and never visit customer sites.
Resources could be anywhere in the world, India, the Philippines, Eastern Europe, South America. Location was irrelevant, the shifts in technology that enabled remote system access allowed work to be carried out away from the customer site.
Initially the shift was to use offshore programmers who would be sent a functional specification outlining the business requirements, this would be developed by the offshore resources then returned back to the onshore resources for them to validate and test the code.
Slowly as the expertise of the offshore resources grew and the ability of the onshore resources to interact with them improved, more and more of the delivery roles were shifted offshore.
The big consulting companies in particular quickly realised that using an offshore delivery model would make them more competitive in the ERP project space and significantly reduce their costs.
Customers demanded better value for money and more competitive delivery costs. The big players all opened numerous offshore delivery centres to support their increased offshore offering. Slowly there was a definite shift towards delivering ERP projects using an offshore delivery model.
The downside of this was no face to face contact, it was sometimes difficult to establish rapport and strong working relationships. The solution was landing offshore resources locally on long term contacts to work face to face with the client. To do what the onshore resources had been doing, to sit with the customer and be part of their team. This was still a cheaper option than using more expensive local resources.
Offshore models can bring many benefits from a cost perspective, as very often experienced resources can be accessed at much more competitive rates and as such offshore delivery models are often popular. They do however require a different way of working and can be challenging from a communication perspective, for example, in ensuring requirements have been clearly articulated and understood.
They certainly aren’t for everyone.
A hybrid offshore model which uses a mix of onshore and offshore can sometimes offer the best of both worlds. Certain activities such as analysis and gathering business requirements are retained onshore with local resources, then lower cost offshore resources are used to do development and testing for example, before user training and deployment is picked up back onshore. Again there are pros and cons to this and again it doesn’t work for everyone. As technology continues to evolve and improve the opportunities for remote working and remote project delivery increase.
Increased remote interaction via Zoom, Skype, phone calls, video calls and emails facilitate very different ways of working. This is evident from the 2020 pandemic which ground the world to a halt, ways of working were forced to change, businesses have had to embrace a remote working model to get things done. Approaches had to change. Projects have had to continue and have been delivered remotely.
When selecting your SI you need to consider the delivery model they are proposing and whether it will work for you.
Will their consultants be local, onsite either full time or on a part time basis working remotely for the remainder of the time? Or will they work remotely the vast majority of the time and just attend site for critical meetings or activities. Either way this onshore model offers the opportunity for continual interaction between the customer team and the SI team with some opportunity for onsite face to face interaction.
Or do they intend to use an offshore delivery model where the SIs consultants are in a different country and delivery of the project is all remote with no face to face contact other than via video calls.
Or will it be a combination of onshore and offshore resources?
Choosing the right implementation partner and the right delivery model is critical for the success of the project.
Your SI brings various benefits to the table but choosing the right one for your project is a task in itself that will take time and effort.
Get it wrong and it can be detrimental to the project’s success and also a costly lesson learnt.
There are loads of tips for choosing the right vendor and lots of factors that will influence your final decision. Some are obvious, making sure they’ve got the right ERP experience to get the job done, that they have experience within your industrial sector, they have demonstrated that they understand your requirements and pain points and have articulated how they can resolve them, that they have a proven approach, their rates and price are within your project budget.
Remember though, there also needs to be a good cultural fit with your organisation. You’re going to be working very closely with your SI so you need to make sure you trust them and feel that you can have honest and open communication with them.
They need to be your trusted advisor. Otherwise there could be sticky moments ahead.
Rather than using Systems Integrators to support their ERP project some organisations choose to go down the contractor route, particularly if they already feel that they have the skills in house to manage and execute the ERP project. They may just need some assistance in specific areas, individuals to augment their own skillset and plug specific skills gaps.
A contractor is a professional who provides skills to an organisation on a temporary basis for a set period of time. They’ll generally have their own limited company. They may be engaged to undertake a piece of work for a certain timeframe or for the duration of the project.
Contractors are generally independent, working for themselves and sourcing their own customers and projects, either directly or through an agency. They offer flexibility and can be a cost efficient way of plugging skills gaps in a team as they can set and agree their own contract terms, fees, deliverables and terms of engagement.
If engaged directly by you, it’s likely that the contractors will be managed by you as the client, and you will be responsible for ensuring that they achieve their deliverables and terms of contract.
Your SI may also use external contractors to boost their team or plug resource gaps they have. In this scenario the contractor will be engaged directly by your SI and will be managed by them to achieve their deliverables. There are benefits to using contractors, they offer you a great deal of flexibility often they are cheaper than getting resources directly from your SI.
This approach can be particularly good if you’re looking to secure niche skills within the marketplace.
Understand how to break down different phases of your ERP project.