ERP, The Next Generation: The Final Frontier? Part 3

This is the third post of a series on Next Generation ERP. If you missed the first two in the series, take a moment and catch up with Part 1 and Part 2. You can find them on “Recent Posts” to the right.

As you recall from the previous posts, one of the hallmarks of “next generation” ERP is the ability to customize without customizations. Sound like a contradiction? Not really.

Customization versus Configuration and Tailoring

Different roles in the organization require different views. And different individuals may require unique views. And what organization today doesn’t think it isn’t unique in some way? With traditional ERP based on older technology this used to mean customization.

Customization also used to mean mucking around in source code, which builds barriers to moving forward with updates and upgrades. That was because in the past all the logic was “programmed” into that source code. This made business applications like ERP rigid and inflexible. Sure, there were always some configuration options, but those options were constrained by the logic embedded in the source code.

But next generation ERP is built in layers that are removed from the source code. First and foremost there will be a user interface layer. By removing this from the source code, you can easily tailor what the users see, and how they see it, without ever touching the underlying code. This is also how translations are much more easily delivered these days, allowing different users to interface with ERP in different languages.

This means tailoring the look and feel is easy. It also means that configuration (versus customization) does not require deep technical skills and is carried forward as the software is enhanced.

In addition, there might also be a set of business rules that are created and maintained. These rules might be used to determine behavior of a function or to configure next steps in a workflow. Business rules might define different thresholds for approval (e.g. all purchase orders require approval but those over a certain value require an extra step in the approval process).

These business rules might also be used to trigger alerts, notifying managers when events occur (e.g. a big order comes in) or when they fail to occur (a scheduled delivery date is missed).

To better distinguish between configuration and customization, Mint Jutras posed the question to ERP survey participants, “What level of customization do you believe you need?” Respondents were allowed to select any or all of the options presented. Their responses are shown in Figure 2.

Figure 2: What level of customization do you believe you need?

Figure 3Source: Mint Jutras 2013 ERP Solution Study

With a next generation ERP, it is highly unlikely that any of these requirements, with the possible exception of “custom logic is required” would require customization rather than configuration. And if an external rules engine is available, custom logic might also be “configured” as well.

 Integration and Innovation

We include integration capabilities and new ways of delivering innovation as a single topic here because the technology used to deliver both are likely to be similar, if not identical. In this context, you will hear two terms bandied about: services and objects, both of which can be shared. We should also throw a third term in there: components.

Before getting into how next generation ERP delivers integration and innovation, let’s first recap how traditional ERP originally worked. Mint Jutras defines ERP as an integrated suite of modules that forms the transactional system of record of a business. This is a rudimentary definition because today ERP is likely to do much more than this, but it will serve us well in drawing a contrast between traditional and next generation ERP.

Traditional ERP was developed as a tightly integrated set of modules, with only one of everything, including master files and maintenance functions. Even though the order management and the accounts receivable modules both needed a customer master, there was only one and it was shared by both. Purchasing and accounts payable shared a supplier master file. Purchasing, shop floor control, engineering and inventory management all shared a common part master file.

Not only do all modules of an ERP solution share a common database, but all are developed using the same tools and technology and they all move forward in lock step. This eliminates data redundancy and any need for separate integration efforts. But it also means purchasing can’t move forward until order management, shop floor control and inventory management modules are ready to move. It takes massive efforts of coordination by the vendor to make sure all the pieces of the puzzle more forward together. And it takes similarly massive efforts of coordination for all departments within their customers’ organizations to take those next steps altogether.

But what if a supplier (or, even worse, a customer) demands that your enterprise change the way you conduct business with them? What if your current solution can’t support that new way of doing business? Maybe you need to upgrade, enhance or even swap out the purchasing (or order management) module for a new solution that does. If purchasing (or order management) was a separate application you could, although that would most likely require additional effort (and cost) to integrate that separate application with ERP. And when you make a change, the integration would likely require change as well.

What if, instead, you could take that tightly integrated purchasing module of ERP and loosely couple it? That way, if you wanted to replace it you would just have to uncouple it and swap in a new one – sort of like uncoupling one of the cars on a train? It just takes a standard coupling, right? Of course it is a little more complicated than that, but that’s the general idea.

Instead of referencing supplier and item master files directly, a next generation ERP will access a standard model of a supplier or an item (a business “object”). It might have its own standard or it might use an industry standard (like OAGIS). Of course a different supplier record (being swapped in) might not be identical to the master but think of the object as sort of a Rosetta stone for supplier information. If you can map to all the elements of the object, you can map to what ERP needs. This provides a leg up when it comes to integration with other internal applications as well as interoperating with those of customers and suppliers. Point to point integration methods are replaced with a hub and spoke approach. By connecting to the hub, you can “speak” with all the different spokes.

And instead of inserting lines of code directly into the purchasing module of its ERP to maintain the supplier master file, next generation ERP might call upon a standard “service” for file maintenance or for adding a new purchase order or any number of different functions. Need to upgrade or add new functionality, simply swap out the old “service” for the new. You might also view these services as external components. Again, this is an oversimplification, but conceptually describes how next generation ERP can effectively deliver new, targeted innovation without forcing all departments served by ERP to march forward together.

It is also how acquisitive ERP vendors can deliver more innovation to broader installed customer bases. The ERP market has been steadily consolidating for the past two decades. Many ERP vendors have grown through acquisition using one of two approaches, or combining the two:

  • Some have acquired market share by buying other ERP vendors resulting in larger development staffs, but also requiring them to support (and develop?) multiple product lines.
  • Others have expanded the breadth of their offering by acquiring complementary solutions. While this approach allows them to potentially grab more share of their customers’ wallet, the acquired products may or may not be fully and seamlessly integrated with their ERP offering(s).

Some vendors will have combined both approaches for growth. Using next generation “services” and “object orientation” provides more seamless integration and also allows them to develop code once and deliver across different ERP product lines.

Even if the vendor in question has not grown by acquisition, this approach also allows delivery of more innovation with less disruption to the customer. The connection will be the strongest when ERP and these components share a common platform of technology.

This entry was posted in ERP and tagged , , , , , , . Bookmark the permalink.

One Response to ERP, The Next Generation: The Final Frontier? Part 3

  1. Doug Hadden says:

    You’ve covered a number on interesting ERP trends. Some of these trends seem to passed many vendors and customers by.

    I tend to think that pre-2000 ERP architectures are linked to integration and user interface problems one hand and agility issues on the other. (The not-so-subtle observation here is that there are a minority of organizations are running pre-2000 ERP systems but a majority are running ERP systems built on pre-2000 client/server code.)

    This manifests itself in the following ways:
    1) Integration is based on very large (monolithic) rather than granular objects. Of course, the larger ERP vendors have persisted in the notion that integration is enabled by buying everything from them! The lack of separation between presentation, business logic and data layers adds to this problem.
    2) Agility in pre-2000 architectures was primarily based on code customization. Configuration tended to the be with the low hanging fruit. Workflow tools have been thought to be the magic bullet in easy adaptation at various times in the past 15 years or so. Although there seems to have been an increase in usage according to your study, I think that the lack of a huge uptick relates to the difficulty of using the workflow hammer to think that all problems are nails.
    3) User interfaces are difficult to decouple from architectures that did not separate the presentation layer. That’s only the first problem. The increase in complexity with ERP systems has made these systems harder to use. This means that standard UI metaphors – typically “form” – have become increasingly irrelevant to those of us familiar with consumer tools. And, the old architectures assumed a functional view of interaction where users are expected to know where in the menu system the function is located. That differs from goal-based design that we see in consumer-based technology.

Leave a Reply

Your email address will not be published. Required fields are marked *