alotofpeople - stock.adobe.com
Composable ERP may break up monolithic systems
In this Q&A, Unit4's Claus Jepsen calls cloud-based composable ERPs, which enable companies to pick and choose the applications and vendors they want, the future.
The days of monolithic ERP systems may be drawing to a close.
Cloud computing, advanced technologies and better integrations are paving the way for composable ERP systems, a term coined by Gartner to refer to a central ERP database outfitted with select applications -- often from different vendors.
Composable ERP is not a new concept, but it is more achievable now with SaaS-based ERP applications and APIs that allow for integrations to outside systems. It also represents where the enterprise is headed, according to Claus Jepsen, CTO at Unit4.
Unit4, based outside of Rotterdam, Netherlands, makes financial and project-oriented ERP for professional services, higher education and public sector and nonprofit organizations. Here, Jepsen explains why he believes composable ERP will be an emerging trend going forward.
What is composable ERP?
Claus Jepsen: Back in the day, everybody had best-of-breed solutions, but they had to fight with all of the integrations. Then came the mega-suites -- the ERP applications intended to alleviate some of that integration pain. But now, as we are moving more and more into a cloud setting with all these cloud best-of-breed solutions coming, customers are getting more interested in how to pick the best solutions that they can [seamlessly] plug into their ecosystem. A key word here is seamlessly, so [it] needs to be easier to deal with. The difference is that in the cloud, it becomes the vendor's problem to get all these bits and pieces to run.
What does a composable ERP system look like?
Jepsen: ERP will become like the database. For example, if you go back some years, if you wanted to use the database, you needed to understand how to use the tooling around it -- you needed to go in at the admin level [to configure]. Today, nobody cares about the database; it just sits there and does its thing. ERP is going the same way. It's still going to be there, but you don't get the sense that you're actually interacting with the ERP. We talk about that as pervasiveness -- that it's basically nowhere but everywhere.
You still need an ERP system with a central transaction store, but what's changing is the way that people perceive ERP and what you have inside of ERP. Just a few years ago, users spent time doing data maintenance. If you look on the screens, and how everything is built in ERP today, it's really about making sure that the data is correct. But what's happening [at the same time] is that, due to vast amounts of data and [growing compute power], you can start [to use] smarter algorithms to handle that data scrutiny and cleansing automatically. You change the paradigm around and focus on issues that cannot be automated.
Where does the user interaction happen?
Jepsen: When we talk about composable ERP, you have the transactional engine, but the user interaction happens somewhere else, not inside the ERP application.
The idea that everybody's got to go into the ERP to do the job is in the past. Interaction is not based on [a user] creating a transaction, but [when automated analytics finds a failure] that requires the user to come in. But instead of dragging the user into the ERP [to resolve the failure], you give users the experience where they are -- for example, in [Microsoft Teams]. So you build these specific experiences for applications inside the tools they use.
How can companies make the systems work together?
Jepsen: The IT landscape of a company typically has a number of systems that need to communicate, but today there's really not a standard that [helps systems communicate with each other]. Different vendors have different approaches. These [integrated systems] need to hook into some sort of bus, so you need this middleware and a definition of the data model to make this work. What can make it easier is having an ERP that takes the first step in this to standardize and create the openness. Also, one of the key things in being successful with these architectures and systems is that the systems tell you when things happen. For example, if you have a CRM system, if something happens in that, you want to know it in the ERP. If composable ERP is to work, that's one of the key drivers.
Do you have to have cloud systems to make composable ERP work?
Jepsen: Yes, the first thing [companies need to do] is they have to move to the cloud, and they have to make sure they are on a real cloud system because there's a lot of lift-and-shift going on, which doesn't really solve the problem. So they need to go to the cloud, but they need to be on a real multi-instance cloud version, otherwise the composable idea won't work.
What should companies look for if they are considering a composable ERP model?
Jepsen: If customers are looking to buy an ERP system, they need to make sure that whoever they talk with understands that the future workforce won't mind working with the ERP indirectly through tooling. They will not want to interact with a big ERP system because it takes too long to learn and is too complicated to use. They also need to think about to what extent the system is open [via APIs]. Is it really open or is it just the vendor saying it's open? Does the vendor have the sufficient technologies that allows customers to extend the system to outside systems, to integrate it and to manage the system without having to deal with the ERP itself?
Jim O'Donnell is a TechTarget news writer who covers ERP and other enterprise applications for SearchSAP and SearchERP.