Skip to content

    10.12.2018 — 5 min read

    Can ERP systems and agility be brought up in the same sentence?

    Play the audio version - if available

    Can ERP systems and agility be brought up in the same sentence?

    Especially within IT, everything in today’s world should be agile, even the traditional ERP. A company’s IT department is easily squeezed between the business operations and the IT supplier, as business operations want quick changes and agile development, while ERP is more like a big wheel that turns slowly according to the update cycles.

    The main reason for the slowness is the fact that throughout the years, ERP has been built as a customer-specific monolith and making changes is difficult. The lifecycle of an ERP solution is at least ten years, so many companies will abide by the existing systems for many years to come. However, at some point, the systems will be updated, and this is a good time to do things differently.

    Current ERP systems are standard cloud products or, at the very least, well productised software. The deployment of off-the-shelf software is not actual software development, so the methods of agile development are not directly applicable.

    I have carried out some research on how agile software development methods can be utilised also in the world of ERP and off-the-shelf software. Below, I will discuss a few principles that can be utilised.

    1. Flexible definition

    Off-the-shelf software is COMPLETE and there are limitations in its methods of use that should be followed. Instead of a detailed description of the company’s current processes, it’s worth it to focus on sharing two-way understanding throughout the deployment. The customer’s understanding of the business operations and the supplier’s understanding of the system must be combined. The best method is to go through the customer’s operations against the system and to describe the user stories.

    2. Close collaboration and direct discussions instead of indirect communication

    A fixed project team and a direct dialogical connection between different parties will significantly decrease the risk of misunderstandings and improve the quality of projects. Collaboration and continuous interaction can be increased by, among other things, a joint project space and daily reviews.

    3. User- and role-based planning

    The constant problem of off-the-shelf software projects has been excessive customer-specific tailoring and the consequent heavy system maintenance in the future. Currently, tailoring is consistently seen in a negative light. However, it is necessary to understand the difference between good and bad tailoring. For example, the modern ERP user interfaces can be modified for use without changing the underlying processes.

    4. Iterative development and continuous testing

    Traditionally, delivery projects take too long, and the world has already changed by the time a system is created, making it too old or wrong. Deployment should consist of short iteration phases. At first, the integrated basic processes, the so-called skeleton models, can be implemented and then expanded with the iterations. Iteration outputs are tested in phases as they are completed.

    5. Early publications

    From time to time, someone says that deployment cannot be phased. However, it is often possible by creating temporary integrations between the old and the new system or by transferring data manually. Instead of seeing this as an extra cost, this should be considered as insurance and an enabler for an earlier deployment with fewer risks.

    Therefore, it is possible to utilise applied agile methods in ERP system deliveries. Changes in operational methods are not necessarily big, but their significance to the project might be. The biggest challenges for the change are the traditional operational methods of ERP projects and learning to leave them behind.

    B2B, ERP