The implementation of an ERP system is a large and complex task. Such software controls virtually all day-to-day business activity and has a direct impact on the productivity and profitability of an entire organisation.
Unfortunately, such large implementation projects often strike problems. These can range from minor cost or time overruns to major failures that result in significant delays and financial losses.
Often, the problems arise because of misunderstandings between the software vendor and the customer. Each needs to be very clear about their role and responsibilities, and be sure the same holds true for the other side. Misunderstandings can occur either when the vendor fails to explain the processes and requirements of the deployment, or the customer fails to fully understand them.
Customers may assume certain things are going to happen, or certain resources are needed for the project when in fact reality is very different. Untested assumptions can have a dangerous impact on the project’s success.
There are a number of key factors to consider before embarking on an ERP implementation, or any large software deployment project. They include:
It can be tempting to focus on the capabilities of a particular software application and not pay sufficient attention to the vendor behind it. Undertaking thorough vendor due diligence before any decisions are made is vital.
Ask your prospective vendor about the processes they have in place and the methods and documentation they use during a deployment project. Ensure you are comfortable with their knowledge of your business and the benefits the software will deliver. Only once you are satisfied that the vendor is the right fit for your organisation should attention then shift to the detail of the software.
Once a vendor has been selected, the next step is to undertake gap analysis. This maps out the business process requirements of your organisation and determines exactly whether the chosen software will be a good fit. Gap analysis can take place in the form of a series of workshops during which both sides run through their expectations and assumptions for the project and its outcome.
Management of assumptions at this stage is vital for project success. Some vendors fear they will miss out on a sale if they point out the true requirements from the customer, both in terms of staff and commitment, however this is particularly important.
Preparation testing is the next step. This involves talking to all key stakeholders about what to expect from the project, what will be changing, and what this means for them. Early buy-in from all affected employees can help greatly in a successful deployment.
During this step, the vendor should make recommendations on the number and types of customer staff that will need to be involved in each phase of the project.
Most ERP deployments will require software to be tailored to match the specific requirements of an organisation. It’s important to understand how these customisations will be handled by the vendor and what time delays and expense might be incurred during the process.
The organisation must also be clear on the impact of any changes to the initial deployment agreement. Adding additional components or features, known as ‘scope creep’, can significantly slow a project and cause cost overruns.
It’s also worth understanding the implications of working with a global rather than Australian-based vendor. Customer of global vendors may find themselves competing with other larger customers for support rather than having local access to required resources.
This is one of the most critical steps in the deployment project. You should identify key personnel who will take on the roles of users and super users. There should also be a project leader who needs to have a thorough understanding of business processes as well as the authority to make key decisions during the deployment process.
Care should be taken to ensure the selected staff actually have the time required to perform their new duties. Assigning new tasks to already busy people tied up with regular day-to-day operations can cause significant problems during the implementation process.
This is a critical part of the project and often under estimated in terms of the time that should be allowed. Sometimes, customers are unsure what to do in this phase and don’t ask the vendor for guidance. This is a mistake.
It’s important to continue to ask questions throughout the deployment as it removes assumptions and misunderstandings on both sides.
How is the project tracking? Are we meeting our list of requirements agreed at the start of the deployment? Are critical decisions being made in a timely manner?
By following these steps the risks associated with large-scale software deployments can be significantly reduced.
When choosing an ERP [enterprise resource planning system], companies typically look at the range of applications, the features and functionality of the software. They want to know that it will support all the different areas of the business, from the supply chain and logistics to transport. They look for functionality to support advanced planning and material demand control, forecasting, sales, cost control, quality assurance, traceability and more. Only occasionally does anyone stop to think about the underlying database. And this is a pity because in an ERP, the database lies at the very heart of the solution.
The job of the database is to support all the applications. It provides the common repository of data that is crucial when trying to share information between applications, people, departments and partners. The speed of the database, its flexibility and scalability has a profound affect on the performance of the ERP.
Unfortunately, discussions about databases can easily veer into technical territory. Talk about spatial, text, binary and other types of data, transaction loads, platforms, terabytes and petabytes can quickly leave non-technical participants out in the cold. The temptation then is to simply ignore the database and focus instead on the far easier topics of features and functionality. But it doesn’t have to be so.
Following are some very simple suggestions that will help you to understand and evaluate the suitability of a database the next time you go looking for an ERP.
There are many different kinds of databases but two of the most commonly found – among legacy and modern ERP offerings, from small-to-medium up to large solutions – are SQL Server and Oracle. These robust technologies are well-proven, capable of underpinning numerous applications and able to cope with the tens of thousands of daily transactions involved in large-scale manufacturing, distribution and logistics businesses.
Within the sector, there is also a large number of organisations relying on commercial or bespoke ERP systems based on legacy database infrastructure. In other words, the applications have been developed on older databases that may not be able to deliver the reliability, scalability, flexibility and availability expected in business today.
Two examples of legacy databases that periodically turn up in small-to-medium legacy solutions are FoxPro and Access. Never designed for the kinds of demands of an ERP and limited in their size and capabilities, it doesn’t take long for companies to find they are pushing the limits of these systems. More importantly in the case of FoxPro, the database is now at the end of its life, no longer supported by Microsoft. This raises the very real likelihood that one day soon, a new security patch for Microsoft Windows may inadvertently “break” the database permanently.
Even when the applications themselves are relatively modern, if the underlying database is from a past generation, there are many complications that can arise. The older the database, the harder it becomes to find the programming skills necessary to maintain and update the system. And, the rarer the skills, the more expensive they are to acquire.
Moreover, when dealing with databases developed a decade or more ago it can be difficult, if not impossible, to establish connections to the standard tools of today such as tablets, warehouse scanners or other third party peripherals.
The typical lifespan of an ERP system within the logistics sector is around ten years. So when you enter into a partnership with a software vendor, you’ll typically look for assurance that they are going to be there for the long haul. But what about the database – this incredibly important part of the software infrastructure?
Is your database current-generation or, like the FoxPro example above, is it at the end of its lifecycle? Will your choice be supported for the ten or so years you plan to use your ERP system?
The most logical place to start is with standards. Look for an ERP that adheres to industry standards, or even better, one that because of its popularity, has become an industry standard. This will give you the security of a path forwards in future years and will make it easier to integrate and add to your solution with new software or peripherals over time.
For security of mind and certainty of longevity, look for software powered by a proven, market-leading database. The more popular the database, the longer it is likely to be supported by the vendor.
Other essentials include scalability to cope with business growth and reliability of performance. You do want to know the system is likely to keep on operating. Also think about the availability of skills for your chosen database, not just across the overall employment market, but within the logistics sector and your geography.
For reasons of cost, performance and longevity, it’s obvious the database plays an important role when choosing an ERP system. For an enduring return on your ERP investment, look for a database that has the proven power and performance to support the complexity of an ERP. It should be affordable and scalable. Even better, choose a database that has already established itself as the leading industry standard, such as Microsoft SQL Server.
That said, it’s also important to keep in mind the database is just one of the factors that will influence your ERP purchase. A system that doesn’t have the functionality your business requires will be a poor investment, regardless of the quality of its database. Just as a great solution sitting on top of an outdated database will never provide the performance a modern business needs.
Perhaps it’s best to consider the database as a critical item in the check-list, right next to the list of functional areas you need to address and the must-have features that will help improve processes and performance. When you find an ERP solution that offers a fit across all three areas, you’ll know you’ve found the right solution for your needs.
Companies tend to replace their Enterprise Resource Planning (ERP) systems for one of two reasons. Either an existing system has reached the end of its operational life, or it is no longer providing the level of support required.
Many companies also come to the realisation that implementing a new ERP system can be a way to gain a competitive edge. By streamlining internal processes and improving customer service levels, they are in a better position to gain valuable market share.
These organisations have taken the step of placing technology at the forefront of their business planning. They recognise the strategic role it can play and understand the value of making required investments. This is not to say that they are allowing IT decisions to take precedence over business decisions, but rather they consider both concurrently.
Because ERP systems sit at the heart of an organisation’s IT infrastructure, any changes made can have unintended knock-on effects. Linkages with other applications and databases can be broken causing disruption to processes across the business.
Such potential problems, however, should not stop organisations embarking on integration projects. The challenge is to complete the project without causing any of these problems.
The goal might be to totally replace the ERP system or add fresh capabilities through the installation of additional add-on applications. Regardless of which goal is relevant, the key is to treat the project as a business-driven initiative that is critical to the long-term growth and profitability of the organisation.
By following a series of carefully orchestrated steps, the perils of an ERP system integration project can be significantly reduced. These key steps include:
The first step is the selection of a suitable technology partner to drive the project. This partner should have deep technical knowledge as well as a thorough understanding of the organisation and its activities. This understanding is vital to ensure the new infrastructure reflects real-world business requirements and will deliver the advantages sought.
Before any changes are made to the existing infrastructure or additional capabilities added, the entire implementation project must be carefully mapped out. This planning process should cover everything from timelines and expected go-live dates to areas of responsibility for both the organisation and its implementation partner. Specific staff members should be nominated as ‘super users’ who can be trained and then assist others as required.
A progress meeting schedule should be created and agreed with lines of responsibility and communication made clear for all involved.
Not all applications are designed to work cohesively or be readily linked to existing systems. Working with the implementation partner, the IT team should determine whether the proposed new ERP system can be integrated with other core IT systems.
There can be particular challenges when it comes to linking a new ERP system with legacy databases. Popular databases, such as SQL Server and Oracle, are robust and able to meet the performance demands of an ERP system, however many organisations have databases in place that were never designed for these kinds of workloads. Examples of these include FoxPro and Access.
If the underlying database cannot provide the required support for the new ERP system, complications can arise. As well as core applications becoming unstable, a lack of support can make it difficult to create links to standard tools such as tablets, scanners or other third-party peripherals.
Prior to switching operations to the new infrastructure, it should be thoroughly reviewed in a quarantined test environment. This will allow all new linkages to be tested for incompatibilities and flows between databases and other applications to be reviewed. Any required changes can then be made before the new system is put into production.
Keeping comprehensive documentation of all changes made to a complex IT infrastructure is vital. Staff who work on the project will inevitably move on, taking their in-depth knowledge of what has been undertaken with them. Proper documentation will ensure that any future alterations can be carried out with full knowledge of exactly what is in place and how it has been configured.
Once the new ERP system has been implemented, rigorous user acceptance testing should be conducted prior to it being put into production. This testing will identify any issues with functionality and user interfaces. Fixing these prior to going live will minimise disruption and help with rapid user acceptance of the new technology.
By taking a methodical and measured approach to the implementation of a new ERP system and its integration with existing applications, the chance of problems can be significantly reduced.
In this way, business and IT strategies can be closely aligned, thereby delivering the most benefits in the shortest period of time.