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?
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.