00:00:07 Importance of ERP systems.
00:02:42 ERP: Misnomer explanation.
00:03:54 Initial ERP system implementation.
00:05:07 Early ERP systems’ core capabilities.
00:07:34 ERP systems: entities, interfaces, logic.
00:09:14 ERP’s role in business automation.
00:09:54 Evolution of ERPs and strategies.
00:11:32 Domain-specific languages in ERPs.
00:12:07 ERP systems’ module-based structure.
00:14:22 Role of integrators in ERPs.
00:16:00 Integrators promoting customized ERP solutions.
00:17:01 Relevance of traditional ERP constraints.
00:19:01 Challenging singular ERP system need.
00:20:01 Difficulties in ERP upgrades.
00:21:35 ERP operator’s role and complications.
00:22:53 Risks/benefits of specialized ERP providers.
00:25:00 ERP systems: complexity and challenges.
00:26:52 Small companies and SaaS apps.
00:28:42 Complex ERP products for mid-sized companies.
00:30:16 Large companies avoiding monolithic ERPs.
00:31:46 Strategies of top companies.
00:33:39 Closing thoughts.
Summary
In an interview with Kieran Chandler, Lokad founder Joannes Vermorel discusses the evolution of Enterprise Resource Planning (ERP) systems. Tracing their inception to the 1970s, Vermorel highlights two key innovations—the advent of relational databases and barcode readers—as crucial to ERP development. He suggests that “Enterprise Resource Management” is a more accurate term for these systems, which have grown from bespoke company solutions to prepackaged business model representations. ERP’s modern functionalities, such as CRUD interfaces and workflow logic, have automated routine tasks, improving productivity. Vermorel explores the strategies of successful ERP vendors, like SAP, to manage system complexity, and also discusses ERP selection and implementation for businesses of various sizes.
Extended Summary
In the interview, host Kieran Chandler speaks with Joannes Vermorel, the founder of Lokad, to discuss the evolution and functionality of Enterprise Resource Planning (ERP) systems.
Vermorel outlines the origins of ERP systems, pinpointing their emergence to the 1970s, despite the term “ERP” being coined only in the 90s. According to Vermorel, two key innovations led to the development of ERP systems. The first was the progression of computing hardware to the point where relational databases were possible. These databases, though rudimentary in their early stages, offered a versatile way to organize data. The relational format, comprised of tables and columns, was suitable for modeling various business activities, including transactions, payments, and client and supplier interactions.
The second critical innovation Vermorel mentions is the invention of barcode readers. While barcode readers came about in the 1950s, it wasn’t until the advancement in computing hardware in the 1970s that they could store and process sizable amounts of data. The combination of these two technologies gave rise to the ERP systems we know today.
Vermorel also addresses the misnomer of ERP, stating that it was a marketing gimmick initiated in the 90s. He explains that ERPs have little to do with planning but are instead focused on management—making “Enterprise Resource Management” a more apt name. He illustrates this by describing how, in the early stages, many companies began to develop their own software systems to manage resources using databases and data entry devices available at the time.
Observing commonalities in what businesses needed to represent—such as payments, stocks, and employees—some companies started offering prepackaged versions of these business model representations. Vermorel indicates that this was the origin of what we now refer to as ERP systems, although he suggests we should think of them as Enterprise Resource Management systems, given their actual functionality.
The user interfaces, typically categorized as CRUD (Create, Read, Update, Delete) interfaces, operate on these entities. They enable basic data entry tasks, like adding a new product (create), viewing an existing product’s attributes (read), modifying an existing product (update), and deleting a product (delete). This CRUD pattern applies to every entity within the ERP system.
Workflow logic, the third component, is where automation comes into play. Vermorel gives an example of a purchasing process, which starts with a purchase order, then receiving an invoice from the supplier, followed by the supplier shipping goods. The ERP system tracks these steps, and if the goods are not received, it alerts the user. If the received quantities do not match the ordered quantities, the ERP system suggests next steps, such as contacting the supplier to send the rest or returning the goods. This automation of routine tasks leads to significant productivity improvement.
Moving on to the evolution of ERPs, Vermorel emphasizes the role of vendors in shaping these systems. He notes that the prime challenge for vendors is managing complexity, as they have to implement an endless stream of entities, user interfaces, and logic. He refers to a “three-fold” strategy that successful ERP vendors use to manage this complexity and maintain competitiveness.
Firstly, vendors adopt specific technologies to streamline the production of entities, user interfaces, and logic. Vermorel cites the example of SAP, a successful ERP vendor, which invented its own domain-specific programming language, ABAP, to speed up the implementation process.
Secondly, vendors adjust the structure of their offerings and pricing to reflect the cost and effort of producing and supporting the diverse range of entities. This often leads to a module-based pricing structure, where entities are grouped into modules that make business sense, and customers are charged based on the modules they use.
ERP systems, which have become a dominant part of the enterprise software world, are constantly evolving and adapting to meet the needs of businesses and their complex operations.
Vermorel starts by discussing the incentives and business model of ERP vendors. He explains that these vendors are incentivized to continually develop new modules or features to sell to their clients. The vendors often view each successful implementation as an opportunity to create and sell an additional module to the client. This creates a perpetual cycle of sales and development.
The conversation then shifts to the choice between different ERP approaches. Vermorel suggests that businesses should ask whether the constraints built into ERPs from the late 70s are still relevant to their situation today. He questions the need for a singular, integrated system, arguing that this approach can lead to increased complexity and a multitude of edge cases. Instead, he suggests that businesses reconsider the assumption that one system should do everything, while also warning against having too many distinct systems.
In discussing the implementation of new ERP systems, Vermorel touches upon the significant risks and costs associated with transitioning to a new system or upgrading an existing one. He uses the example of a company that wasted half a billion euros on an SAP upgrade in 2009, emphasizing that the semantics of the entities within an ERP system—largely determined by the operators of the system—often change subtly but significantly between versions, leading to numerous edge cases and challenges.
Vermorel believes that smaller vendors carry some risk, but it is better to choose a product that has a narrow core, which reflects the current complexity and scale of the company. He advises against excessive features that can disrupt processes and recommends selecting a product that can be supplemented with integration if necessary.
The discussion also touches upon the appropriate ERP choice for different company sizes. Vermorel suggests that smaller companies with less than 100 employees should opt for narrow, simple, and cost-effective Software-as-a-Service (SaaS) applications. He recommends using two or three separate apps that cover specific needs rather than relying on a comprehensive ERP. For mid-sized companies with around 500 employees, Vermorel suggests considering a more complex mid-sized ERP product that can handle a broader range of typical business functions. However, for larger companies with thousands of employees, Vermorel advises against a monolithic ERP approach and instead proposes a divide-and-conquer strategy. He suggests breaking down the landscape into functional areas and building or buying solutions tailored to each area, rather than trying to implement a single ERP system.
Full Transcript
Kieran Chandler: Today, we’re going to discover how this class of enterprise software first came about and how companies can choose between the multitude of different options. So, Joannes, perhaps if we could start off by looking at the origins of ERP systems. How did they first come about?
Joannes Vermorel: ERP systems originated from two driving forces in the seventies. By the way, the term ERP was coined in the 90s, but what we typically refer to as ERP systems actually started in the seventies. There were two critical innovations. One was database systems. Computer hardware progressed to a point where a relational database became possible. That was the first innovation. The second innovation was barcode readers. When you combine these two innovations, you realize that relational databases were incredibly versatile and well-suited to model most business activities, such as payments, clients, suppliers, and transactions. It became clear that this format was well-suited to be the recipient of data. Barcodes were invented in the 50s, but until computing hardware had progressed enough to store and process sizable amounts of data in the 70s, it was not as impactful. However, it was already vast compared to manual processing.
Kieran Chandler: Okay, so you touched on it there. The name ERP didn’t come until a little bit later down the line in the 90s. ERP stands for enterprise resource planning. But where did the name actually come from? Why did they decide upon that?
Joannes Vermorel: Actually, ERP is a misnomer. Unfortunately, its name was more like a marketing gimmick that came in the 90s. ERP systems have basically nothing to do with planning. A better name would have been enterprise resource management. What happened is that as soon as you had both databases and barcode readers, a lot of companies started to realize that they wanted a computerized system to manage all those resources. They started to roll out their own software implementations on top of the database and the available data entry devices at the time. Some other companies realized that many businesses have similar needs when it comes to representation. For example, every business needs to represent payments, stocks for those dealing with physical materials, and employee payroll. So, some software companies thought, “Let’s have prepackaged versions of these business models,” and that’s where the concept of ERP was born. Nowadays, it’s best to think of it as ERP, not enterprise resource planning, but rather enterprise resource management.
Kieran Chandler: So, what were the core capabilities of early ERP systems?
Joannes Vermorel: An ERP basically consists of three things: entities, user interfaces, and workflow logic. Entities are the abstractions on top of tables. For example, if you want to represent products, you would have a table called “products,” but you may have multiple tables for different attributes or suppliers. Entities represent high-level concepts like products, clients, or transactions, as opposed to the lower-level implementation details of how they are stored in a database.
User interfaces are specifically designed for CRUD operations: create, read, update, and delete. Most of the time, when dealing with entities, you’re just working with CRUD interfaces. You enter new products, check existing product details, modify products, or delete them. This applies to every entity, such as transactions, customers, and more.
The third element is workflow logic. Let’s take the example of purchasing. First, you emit a purchase order, then the supplier confirms with an invoice. You receive the goods, and you need to track that in the system. Workflow logic ensures that you have alerts if something is missing and verifies that the quantities match the order. Based on this, you can decide to return the goods to the supplier or request the remaining items. ERP automates these mundane tasks and improves productivity by managing the consequences of basic business operations.
Kieran Chandler: In the software world, how much have they sort of changed since those earliest pieces of software? What is very interesting is that to understand that change, you have to understand the dynamics that are driving the ERP market. ERP, especially ERP vendors, play a significant role in implementing these systems, rather than companies implementing them on their own. Let’s delve into that. Most vendors have adopted a three-fold strategy, which I refer to as Allah. This strategy has been successful in winning the market. Nowadays, the majority of successful ERP vendors apply these three techniques.
Joannes Vermorel: The prime challenge faced by ERP vendors is complexity. To tackle this challenge, they need to implement endless streams of entities and provide user interfaces and workflows that make sense. The first way to be more competitive is to have specific technologies that streamline the production of entities, user interfaces, and logic. An example of such a technology is a domain-specific programming language. For instance, the successful ERP vendor, CP, invented their own domain-specific programming language called ab app, which helped them roll out entities, user interfaces, and logic faster than the competition.
Kieran Chandler: Interesting. So, the second path is to adjust the structure of the offering and pricing. Can you elaborate on that?
Joannes Vermorel: Certainly. As a vendor, the cost to produce an ERP is heavily influenced by how much effort is required to implement all the different elements. While the pieces individually might be straightforward, ERPs are about dealing with mundane tasks, such as handling receipts. Because vendors have to produce and support numerous entities, it makes sense to start charging not per entity but rather by modules. Modules group related entities together and align with business-wise considerations. This raises an interesting point regarding how ERP systems charge for their software.
Kieran Chandler: Absolutely. So, there’s an additional price for adding modules. We previously discussed vendor lock-in. Do the economic interests of ERP providers align with this module-based pricing?
Joannes Vermorel: Indeed, as soon as you introduce modules, it provides an efficient way to align pricing with the cost of implementing all the features. However, it also creates specific incentives. Vendors are motivated to continue developing new modules to sell on top of the existing ones. This can lead to a never-ending cycle of selling more modules to clients. But before we delve into the details of that, let’s move on to the third idea.
Kieran Chandler: Alright. What’s the third idea?
Joannes Vermorel: The third idea is that successful ERP vendors, due to the vast complexity of capturing all the fine-grained details of reality, find ways to grow even faster through integrators. Since one company can’t manage everything, ERP vendors collaborate with external companies known as integrators to handle the last mile, ensuring a complete and comprehensive solution.
Kieran Chandler: So, Joannes, you mentioned earlier that Lokad is introducing a new feature for its clients. Could you tell us more about that?
Joannes Vermorel: Yes, indeed. We are launching a new feature for our clients. It involves new entities, a new user interface, and new logic. We’re creating a network of partners called integrators to implement this feature. From a business model perspective, it’s interesting for ERP vendor companies because they can offload the cost and risk associated with this feature. There’s a long tail of features that can be outsourced to third-party companies.
Kieran Chandler: So, the software vendors transfer the risk to the integrators and ultimately to their clients. The integrators have their own incentive, which may not align completely with the software vendor’s incentive. Is that correct?
Joannes Vermorel: Exactly. The integrators have an incentive to provide the clients with a high level of customization because they get paid more for bespoke modules rather than built-in modules. They can convince clients by saying their business is unique and requires a solution that reflects their uniqueness. It’s an interesting dynamic.
Kieran Chandler: I see. So, there are different approaches that companies can take when it comes to ERP systems. How do you determine what is a good approach and what is a bad one?
Joannes Vermorel: Nowadays, when considering ERP choices, you need to question whether all the constraints that were built into ERPs in the late ’70s are still relevant to your situation. It depends on several factors. For example, the idea that you need to integrate everything into one system is often nonsensical because complexity doesn’t scale linearly. Adding more entities to the system leads to more edge cases and variations in what different industries consider as a “product.”
Kieran Chandler: So, you’re saying we need to revisit the assumption that we still need one system to handle everything?
Joannes Vermorel: Exactly. That assumption is no longer accurate. Having 100 distinct systems that need coordination is challenging, but having one master system as the be-all and end-all is also problematic. When you want to make changes to such a system, it becomes a massive project affecting every function in the company.
Kieran Chandler: I understand. It seems transitioning to a new system can be quite difficult. Some companies have experienced costly failures in trying to switch to new ERP systems. How practical is it to make that transition?
Joannes Vermorel: Indeed, transitioning to a new ERP system can be challenging. We’ve seen companies waste billions of dollars attempting such transitions. It’s not an easy task in practice.
Kieran Chandler: In 2009, they wasted half a billion euros on an ASAP upgrade. It wasn’t even a deployment, just an upgrade. So, the question is, is it more difficult to upgrade an ERP than to move to a new one?
Joannes Vermorel: It’s a very interesting question. Surprisingly, upgrading an ERP is typically more difficult than moving to a new one. It may seem counterintuitive, but that’s what I have observed. When you migrate to a new ERP, you have no illusion that it will be a massive undertaking. However, when you consider it as just an upgrade, it might sound simple, but it can actually be very, very difficult.
The problem is that when you move from one version to the next, there’s a semantic shift in the entities. You see, ERPs are all about representing entities that reflect various concerns in your business, such as products. You would think that the semantics of these entities in an ERP are defined by the vendor, but that’s not entirely true. The final semantics of any entity lies in the eye of the operator, the person who interacts with the system and performs data entry and workflow.
So, the true semantics of an entity are determined by the person operating the ERP. Unfortunately for ERP vendors, they don’t have much control over what people actually do with the product. They can provide recommendations and training programs, but ultimately, it’s challenging. Some companies may decide to have slightly different semantics to make the ERP work in their specific situation. It’s not because they’re rebels; it’s what it takes to get the ERP working.
However, the problem arises when you move to the next version. You can encounter numerous subtle edge cases where the entity suddenly doesn’t mean exactly the same thing due to new developments and a myriad of various edge cases.
Kieran Chandler: That’s interesting. So, on one end of the spectrum, you have these large monolithic approaches, and on the other end, you have smaller, more specialized ERP companies. How much confidence can you place in these smaller companies that might not survive in the next decade?
Joannes Vermorel: If you’re a small company, you want a system where the complexity makes sense in relation to your own scale. ERP products tend to become more complex over time. So, if you’re a young company, maybe just five years old, and you’ve been growing rapidly, it would be wrong to stick with an ERP that is three or four decades old. These older products can be incredibly complex, with hundreds or even thousands of tables and entities. Dealing with such complexity can be overwhelming.
So, my advice is to consider younger ERP companies, even if they come with some level of risk. Beware of burying yourself in piles of complexity. In my experience running Lokad for over a decade, I haven’t seen a company facing a dramatic situation solely because of their ERP choice. However, rolling out a product that is much more complex than your scale can actually be detrimental and even kill your business. I’ve seen it happen frequently, where companies struggle because they embraced software that was just too much for them in terms of complexity and features.
Kieran Chandler: It seems that when it comes to choosing software, having a strong core and interconnected apps is crucial for a growing company. Joannes, could you expand on this idea?
Joannes Vermorel: Absolutely. The counterintuitive essence of it is that it’s better to have something with a narrow core that reflects your current complexity and scale, even if it’s still missing some features. You can always supplement the missing bits through integration. On the other hand, having too many conflicting features can cause problems. Unused features tend to wreak havoc in your processes and prevent you from performing simple tasks. Fully integrated software products make it difficult to remove or modify certain features without disrupting the entire system.
Kieran Chandler: So, choosing a smaller product doesn’t eliminate these problems entirely?
Joannes Vermorel: No, the magnitude and importance of these problems depend on the complexity and entities within the software. However, the scale of the company also plays a role. For smaller companies with fewer than 100 people, it’s advisable to find a narrow, simple, and cost-effective solution like a SaaS app. You might need two or three of these apps to cover different areas, such as human resources, payroll, and inventory management. It’s not necessary to have a single ERP that encompasses everything. Just ensure that these apps have APIs to extract data so that you can integrate them later if needed.
Kieran Chandler: That makes sense. What about mid-sized companies?
Joannes Vermorel: For mid-sized companies, around 500 employees, a more comprehensive ERP product could be considered. It will be more complicated, with numerous tables and features. At this point, you have various typical aspects of the business to manage, and an ERP can provide coverage for those needs. It may require a longer implementation project and a good integrator, but it can offer the desired functionality.
Kieran Chandler: That is more productive compared to small apps that are starting to show their limits. Then if you’re bigger, then I would say the situation changes again. If you’re bigger, more… I mean, let’s say you’re like a 5,000-employee… You know, your large company. Then typically, I would say there are two things that really kick in. First, you want to break them on the leaf. You know, the monolith is just not going to work for you if you’re large. If you go for, like, a monolithic ERP, which most large companies are doing… I would say most… I mean, it’s going to be ugly. It’s going to take years. It’s going to be incredibly costly.
Joannes Vermorel: If you look at what the very best large companies are doing, they are typically rolling out, I would say, fairly bespoke stuff. And they have very good reasons. If you’re a large company, chances are that you have, like, some unique competitive edge that is not a simple thing. It’s embedded in your organization, which is large, which is complex, and maybe you had acquisitions. So you might have, like, an erratic genius landscape in the first place. So instead of saying, “I want one ERP to rule it all,” that was working when you had, like, 500 employees, it becomes very difficult when you have, like, 5,000 employees. So my suggestion is you need to basically divide and conquer. This sort of approach that I was suggesting when you were very small, you know, and you had a couple of apps, you can revisit that in a completely different way if you’re large.
So, to say, I’m going to split the landscape into, I don’t know, maybe up to a dozen functional areas. And then I’m going to build or buy on every area, depending on whether the vendors that I can find out are good or not. And the biggest challenge, what I would recommend to those larger companies, is to basically break the dogma that you need to have, like, one ERP to rule them all. I believe that is mostly… I mean, it’s mostly nonsense. And if you look at very, very super competitive players, let’s say Amazon, let’s look at Alibaba, let’s look at Rakuten, let’s look at Zalando, you know, those tech players who have to deal with the physical supply chain. So, I’m not… You know, I’m not speaking about Microsoft, who is, like, a pure… almost… It’s not completely a pure digital player. You know, they have Xbox. The Xbox is a very physical product. But if you look at companies who have been recognized as being at the top of their game to manage a physical supply chain like Amazon, they all went for a very… I would say, divide and conquer approach in their applicative landscape, where basically, they go very aggressively for a build or buy approach. And they… And basically, none of those companies have really an ERP. They have lists of products. Some of them would be closer to an ERP. And most of those companies actually wrote their own systems as well, for specific parts of what would be referred typically as an ERP module.
Kieran Chandler: Well, we’re gonna have to wrap up there, but thanks very much for your time this morning.
Joannes Vermorel: Thank you, Kieran.
Kieran Chandler: That’s everything for this week. Bye for now.
