The three classes of enterprise software
The typical 21st century company, at least the kind that operates a modern supply chain, has bad spending habits when it comes to enterprise software and IT. After almost two decades of close observations, I estimate that 80% to 90% of the resources allocated in this area are entirely wasted, with zero payback, and occasionally, negative payback. That is to say, the investment has made the situation worse for the company. Besides enterprise software, I cannot think of any other business area where companies appear so utterly cavalier about wasting 80% of their spending. For example, considering physical goods, a 5% annual write-off is considered high, and 25% would just be simply unthinkable. The problem is so prevalent that I would comfortably bet (without knowing anything about your company) that your business currently faces this exact problem.
(Re)Classifying Enterprise Software
To understand the essence of the problem, we must first understand that there are three classes1 of enterprise software that absolutely dominate the field: systems of records, systems of reports, and systems of intelligence.
-
A system of records is software that “reifies” one or several workflows and their corresponding data entries. Fundamentally, a system of records digitizes and streamlines what otherwise would be done with pen and paper. Most entry-level white-collar workers interact with these systems daily; frequently spending several hours per day, in fact. Nearly all the transactional systems fall into this category: ERP, CRM, WMS, EDI, MRP, etc. This class of software emerged in the 1970s and became extremely popular in the 1980s. At their cores, they almost all share a transactional database (e.g., a SQL database).
-
A system of reports is software that offers analytical capabilities (primarily descriptive statistics) and data presentation capabilities, typically overlaid on top of the system of records. The system of reports mechanizes what corporate clerks historically did: compiling sales from last week, assessing aggregate inventory levels, etc. Most management-level white collars do routine checks, such as performance reviews, on a weekly – sometimes daily – schedule. This class of software gained notoriety and popularity in the 1990s with the rise of “Business Intelligence” tools.
-
A system of intelligence is software that mechanizes tasks that white collars would otherwise perform manually - typically with the aid of systems of reports, such as BI tools. A system of intelligence is also overlaid on top of the system of records, just like the system of reports. However, unlike the other two systems, it is not intended for human interaction. Rather, it replaces humans by design. This class of system emerged slowly in the 2000s, the antispam filter being a discreet but ubiquitous example. With the steady progress of machine learning, the capacity spectrum of this system-class started to explode in the late 2010s and early 2020s. Lokad, my company, is a prime example of a system of intelligence.
In short, my core proposition is the following:
For practically any company operating a supply chain, the annual IT budget with a TCO (Total Cost of Ownership) should be divided as follows:
-
20% for systems of records
-
5% for systems of reports
-
75% for systems of intelligence.
This divisions stands in stark contrast to how companies typically (and approximately) divide their spending:
-
75% for systems of records (wrong)
-
20% for systems of reports (wrong)
-
5% for systems of intelligence (completely wrong)
Understanding the Ratios
The root cause of this misallocation of resources is a short series of mistakes made by most businesses.
The first critical mistake that most businesses make is confusing the criticality of the system of records with the price they ought to pay for it. Without water, a man dies in 3 days. However, paying 1000 EUR per day for your drinking water is patently unreasonable given fresh water is abundant almost everywhere. Yet, numerous enterprise software vendors have become master illusionists, casting their system of records as some sort of unique jewels or life-saving devices, while they are really selling nothing more than cement bricks.
Systems of records are an “ancient” technology - i.e., dating back to the late 1970s - extensively commoditized across various business processes. Furthermore, even if there is no readily available on-the-shelf business app that supports your specific requirements, it turns out that there are many high-quality CRUD2 app development frameworks out there. Thus, those apps are cheap despite being critical. However, vendors, by relentlessly playing on the ambient corporate fears, almost invariably convince managers to “play it safe”, hence investing unreasonably large amounts in projects where “failure is not an option”3.
Furthermore, enterprise software vendors selling system of records invariably and intentionally present themselves as if they were also delivering systems of reports and systems of intelligence. This, understandably, fosters a great deal of confusion in the minds of their prospects.
Let’s immediately clarify that technology-wise, systems of records, reports, and intelligence are exclusive. The architectural requirements to excel as one class of software preclude your capacity, as a software venture, to be good at the other classes. The fine print of the technical discussion goes beyond what I intend to convey in this article, but to present an analogy, you cannot be both a champion weightlifter and a champion long-distance runner. The very athletic capacities of the former work against the success of the latter, and vice-versa. The “muscles” that the systems of records must develop come out all wrong when it comes to reports and intelligence, and the converse is true as well.
The second critical mistake that most businesses make is monitoring much while doing little. You can stare at yourself one hour every day in the mirror, but nothing is going to change until you actually hit the gym. Putting a bigger, fancier, brighter mirror is certainly not going to make that much of a difference (at least not in terms of muscle output, aka productivity). It’s certainly acceptable to have a quick look at yourself every day but anything more than that is most likely to be counterproductive. Yet, when it comes to BI (business intelligence) tools, as well as other systems of reports, this is exactly what most businesses are doing: staring at themselves ad infinitum rather than actually improving. Like mirrors, metrics are a net good but only in small doses.
Software vendors selling system of reports masterfully play on the vanity (or insecurity) of upper management. They are in the business of selling what it takes for management to feel in control of their own company. However, as justifying a high price-tag for a handful of metrics is near impossible, offerings are invariably steered towards excessive sophistication. This sophistication is appealing to management as it looks “scientific” - worthy of the intellectual capabilities of those men and women who practice the modern ways of corporate management. Yet, the sophistication of the reports themselves is a trap, consuming the mental energy of management to decipher the walls of metrics, instead of letting them address the most pressing problems that hardly need numbers to be spotted in the first place.
The third critical mistake is failing to acknowledge the company’s decision-making processes, as they presently exist, warts and all. Indeed, most decision-making processes are buried so deep in policies that the policies themselves become the true source of most decisions. Let’s consider first come, first served - a near ubiquitous policy found in businesses servicing both tangible and intangible goods. This is a clear case of decision-making, yet, why should servicing the first person to raise their hand be in the best interest of your company?
A vague sense of “fairness” does stand closer scrutiny: some client(s) may absolutely need to be served first while not being able to make the request early enough. While this policy is a reasonable starting point, there is no reason to believe that it is maximally aligned with the company’s long-term interests. It is only one option among endless variants. Thus, the odds for this option to be “the optimum” are virtually nil. Conversely, exploring and exploiting alternative options is almost guaranteed to be beneficial for the company - as long as the operating costs for those processes are kept reasonably low. Generating and constantly refining such optimized policies is exactly the responsibility of those systems of intelligence (e.g., what Lokad does on a daily basis for its clients).
However, as far as software vendors are concerned, selling systems of intelligence is both brutal and uncompromising. Unlike systems of records (which are as straightforward as software can be) and systems of reports (which are vanity sophistication), systems of intelligence are, by design, thrown in the deep end from day one. This is because bad decisions negatively, and very visibly, impact the company. When it comes to the mechanization of a decision-making process, the vendor is put under an immense spotlight leaving no place to hide. Moreover, the spotlight never ends, because the exercise is repeated daily, possibly many times a day. As a result, as of 2024, there are still very few vendors who are willing to engage the market on the premise of selling a system of intelligence. Lokad is one of them, specializing in supply chain optimization, but it still feels quite lonely to be there.
The Value of Better Decisions
Nevertheless, better decisions do improve the company in all the ways that truly matter. Unlike a system of records, which supports processes, there is no upper limit to how much “better” a decision can be made for the business. A decision that maximizes return on investment (ROI) for a client today can always be improved with greater access to data and better technology. Even if this improvement only translates to one dollar more, it is still a tangible improvement given the repetitive nature of supply chain decisions and low cost of producing the decisions thanks to automation.
On the other hand, with a system of records, once the process is smooth and reliable, there are no further returns to be made. If your company were to successfully hire the Mozart of accounting, past a certain point it would make no material difference compared to hiring an extremely competent one4. On the contrary, if your company were to hire the Mozart of marketing, chances are high that good things - seemingly impossible things - would start coming your way. This is a consequence of the fact that certain domains of expertise are less constrained than others, and when it comes to ingenious decisions, there is no upper bound to the ingenuity that can be applied to them.
Also, unlike system of reports, the upsides of a system of intelligence aren’t predicated on the willing collaboration of the rest of the company. Your anti-spam filter needs neither the support nor the approval of your boss, colleagues, or subordinates to perform the incredible feat of keeping your mailbox sane. Likewise, a system of intelligence does its own thing and improves your company on its own. The process is almost unconditional, except for the engineering of the system itself, which has to be adequate enough to effectively deliver the improvement sought by your company. Naturally, active collaboration from the rest of the company might vastly facilitate the engineering (and maintenance) of the system of intelligence. However, such collaboration is a completely different proposition compared to requiring constant interaction, tinkering, and babysitting to operate at all.
It should now be clearer why businesses typically end up with the bogus ratios listed above:
-
75% for systems of records (this reflects the ambient level of corporate fear).
-
20% for systems of reports (this reflects the vanity of upper management).
-
5% for systems of intelligence (this reflects the cowardice of software vendors).
Yet, unlike conventional wisdom, getting the ratios right doesn’t require extensive consulting missions5, nor mastery of the art of enterprise software. In fact, it mostly requires fortitude from top management.
Paths forward
In my opinion, top management must coldly assess what the system of records is expected to deliver, without getting caught in the illusions cast by vendors. They would be wise to remember that a system of records is essentially the digital equivalent of a particularly convoluted paper trail. As a result, there is nothing there that the management can’t understand with a little bit of patience. Yet, too frequently management is afraid to even take a close look at the software, as it might expose their own deficiency when it comes to software technologies.
This fear is unfounded. A vendor with integrity will take the time to explain exactly what the system of records does. As a system of records, by design, does nothing that couldn’t be explained to a patient child in junior high school, there is no reason to fear being exposed as “incompetent”. Any attempt - by anyone, particularly a vendor - to present a system of records as something exceedingly advanced should be viewed as an immediate red flag. It either means that the sales team is grossly incompetent or that they are in the process of blowing smoke in management’s eyes. In fact, a system of records that is not easily navigable by a non-specialist should be seriously reconsidered as a matter of principle.
Management must also be resolute in disentangling the system of records from all the other software considerations (i.e., reports and intelligence) that could be bundled into the offering. If the other aspects cannot be unbundled due to technical concerns, then this is another major red flag. If this is the case, the architecture of the enterprise software product is a bastard design that will yield nothing but endless and wholly unnecessary complications. This is because, as previously mentioned, the suitable architecture of a system of records is precisely what makes it unsuitable to also act as a system of reports and/or intelligence. If the concerns are mixed at the architectural level, the system should be considered “broken by design” (just like a Formula 1 car featuring a steam engine).
If the other aspects cannot be unbundled due to commercial terms, then, again, we have a major red flag. The vendor knows that elements of their offering are too defective to be sold on their own and, thus, the vendor has to resort to commercial bundling. Clients are attracted by what appears to be an end-to-end solution that they can get at a “discount” somehow. However, this perception is deceptive, and based on an invalid anchoring at an inflated price point for the system of records.
For example, if the vendor prices the system of records at $75 while it realistically could be as low as $25, it does not matter if the vendor is willing to bundle a system of reports for an extra cost of $10 instead of the regular $20. Simply put, $85 ($75 + $10) is still much greater than $45 ($25 + $20), Yet, many companies fall for this trap.
Upon cold assessment of what a system of records is effectively delivering, and how present-day software technology makes this a fairly straightforward affair, the management will always realize that allocating 20% of the software budget on this front is already quite generous.
Top management must carefully reflect on what actions they would effectively implement if, and only if, some extra numbers were to be provided. Systems of reports are not a substitute for having the willingness to act. All too frequently, management feels insecure about addressing a problem that they have already identified. While the quantification of the problem through various metrics may help to better calibrate the response, it does nothing concerning the willingness to act.
If the management is not already acting (albeit in a slightly uncalibrated manner), then throwing walls of metrics at the issue won’t make the feeling of insecurity go away. On the contrary, numbers are most likely to inflate the feeling of anxiety, as numbers invariably tell a complex, somewhat opaque, and ever-changing story. Thus, a management team (which was already acting too little) is likely to find itself acting even less when presented with dozens of metrics that can be interpreted in all sorts of contradictory ways.
Any attempt from the vendor to promote the versatility of its system of reports (i.e., “you can have as many metrics as you wish”) should be treated as a major red flag. Indeed, a vendor with integrity would relentlessly remind its prospect that every reported number that doesn’t come attached to a well-defined call to action is almost guaranteed to be a waste of time. A vendor with integrity would steer the prospects away from inflating the count of indicators. The reason is simple: it is trivially easy to generate thousands of numbers per day (thanks to modern computers), however it remains a brutal challenge to generate even five or six numbers that are worth being read every single day.
Moreover, a vendor with integrity should also make it very clear that no novel insights will be found by merely having access to descriptive statistics – such as those presented by the system of reports. Insights always precede statistics. Statistics can only be used to refine the quantification of the insight. The intellectual journey doesn’t progress in the other direction. Failing to mention this basic fact, or worse, suggesting that “hidden gems”6 will be found in the data should be treated as yet another major red flag.
A vendor with integrity does not delude their prospects about their chances of success, in the same way an honorable physician does not encourage their patient’s belief that a “magic ritual” will cure lymphoma. While the instinct of management might be to always crave more numbers, the litmus test “I would act if, and only if, some extra numbers were to be provided” is the yardstick that must be used to evaluate those instincts. Once more, allocating 5% for this is quite generous. Descriptive statistics are backward looking, like rearview mirrors. They are a nice addition to avoid a certain class of trouble, but better rearview mirrors are not how races are won.
Finally, we touch upon the critical role of decisions. Top management must focus on what the company ought to be, not what it currently is. For a company operating a large supply chain, the vast majority of decisions are implicitly and somewhat mindlessly taken through established policies. These policies reflect the status quo. By design, both systems of records and systems of reports are very much focused on the status quo. A better system of records will make the status quo a little bit more productive and a little bit more reliable. A better system of reports will facilitate the task of maintaining the status quo, making sure it doesn’t devolve into something worse than what it used to be.
Unfortunately, it is near impossible for top management to decouple its “mental bandwidth” expenditure with the spending of the company. If the company spends most of its software budget introducing a given piece of software, then, by design, top management will dedicate a lot (if not most) of its energy to this very piece of software. Thus, if systems of records and systems of reports consume the lion’s share of the budget, then, by design, the status quo will eat the lion’s share of top management’s attention.
The mantra of Jeff Bezos, founder of Amazon, has forever been: it’s always Day 1. Many observers, including myself, attribute a fair portion of the success of Amazon to this single perspective. Unlike so many internet pioneers (e.g., Yahoo, Digital, eBay, MySpace, etc.), Amazon relentlessly reinvented itself over the last three decades. Many (most?) companies don’t seem to appreciate how much their five-year ERP upgrade is going to cost them. The fees paid to the software vendor are only the tip of the iceberg. That said, the true concern ought to be that top management stops thinking about nothing more than getting the status quo to survive the software transition.
Most ERP vendors blame their clients for not properly conducting the change, and thus making the transition somewhat needlessly costly and slow. However, when it comes to ERPs, I casually observe that the bulk of the change that is brought to the company is accidental, not essential. Thus, the reluctance of the people to adopt the new system is nowhere near as irrational as it may seem. Unless the previous ERP was a complete trainwreck, there is genuinely little to be gained from adopting a new one. The supposedly “improved” processes will soon begin to present unexpected flaws, largely offsetting the expected benefits. While leading Lokad for the last decade and a half, I had the chance to interact with hundreds of C-level executives. Yet, I have never heard any of them ascribe their glory and success to a freshly deployed ERP, especially not ones that have taken several years to roll out.
In contrast, investing in a system of intelligence forces top management to think long and hard about all the tough questions:
-
What does quality of service genuinely mean for customers?
-
How can I nurture and grow suppliers while keeping them loyal?
-
How can I convert white-collar spending from OPEX to CAPEX?
In reality, decisions can only be optimized to the extent that top management knows what they are trying to optimize for. Even if a software initiative related to systems of intelligence doesn’t turn out to be as profitable as expected, important insights about the direction of the business are invariably gained. Interestingly enough, it’s occasionally the failed projects that generate the most important insights. Unless the vendor is technically incompetent - in which case, failure is entirely attributed to said incompetence - a failure typically reflects profound misunderstandings7 by top management about their own business. As long as gaining such insights doesn’t put the overall level of profitability at risk, the spending should be considered a sound investment - essentially future-proofing the company against delusions or outdated perceptions that top management might entertain.
Closing Thought
Most companies are stuck with IT spending habits they acquired in the 1990s (if not earlier), and these spending habits have gradually become dysfunctional. Companies have been ‘digitized’ for a long time, frequently decades, yet past a certain size (e.g., 200 employees), there are very few companies that can buy, produce, or sell anything without a digital trail. By and large, software vendors have become experts at reinforcing those bad habits among their customer base. It is quite ironic that they usually manage to do that under the guise of “innovation” while managing to innovate precisely nothing. This is particularly true when it comes to software that is so thoroughly commoditized that it has become quite unclear why companies ought to pay much for it at all – no matter how critical they are for the continuity of the business.
Fundamentally, top management doesn’t need to become software gurus themselves to address this problem. It mostly takes patience, attention to detail, and mental fortitude to get to the bottom of the case. Top management should stop budgeting for software based on what their peers are doing, and certainly not based on their own past bad habits. Lifelong bad habits are still bad habits, and “tradition” is the word we typically use for things we cannot remember the reason for doing.
It is encouraging to reflect on the fact that, despite being composed of people, companies are not themselves people. This is critical because, unlike the employees within a company, companies themselves can actually be rejuvenated and change to a supernatural degree (and often much faster than even the most ambitious and dedicated human could achieve). As far as properly budgeting enterprise software is concerned, the process is easier than one might assume, and the transformative effects are far-reaching, fast-acting, and long-lasting.
-
Depending on the vertical, other classes of software may apply, such as CAD (computer-aided design) for manufacturing, or microarray data analysis tools for pharmaceutical companies. However, in aggregate, those other classes tend to not only be somewhat niche, but marginal spending-wise compared to the top 3 listed above. ↩︎
-
Django for Python, EF Core for .NET, Spring for Java are excellent open-source frameworks to develop homegrown CRUD apps at blazing speed. ↩︎
-
Yet, enterprise software vendors have, by and large, insanely high failure rates; especially the dominant vendors. At Lokad, we remain mortified of having about a 10% failure rate on our supply chain initiatives, but our large peers are quite content with their low two-digit success rates. After all, there is money to be made in prolonging the problems. ↩︎
-
It is fair to say that a prodigious accountant might well unearth interesting loopholes to lower your corporate tax burden. However, the accountant cannot invent their own laws and procedures. As such, even the Mozart of accounting would be constrained by virtue of a codified tax system, thus placing a hard upper bound on their ingenuity. ↩︎
-
As far as the chart above is concerned, all it takes is to perform a cyclic permutation (1 3 2) of the budget split across the categories. ↩︎
-
Discovering hidden insights in business data has been the driving aspirational force behind the “data mining” buzzword since the early 2000s. Out of the dozens of initiatives that I had the privilege to examine up close, exactly zero yielded any insight that wasn’t an obvious known quantity for the relevant practitioners. The only genuinely positive outcome of those initiative was (typically) identifying a short series of software defects causing anomalous data patterns, as those software defects tended to interfere with the mundane business operations - beyond just messing up the reports. ↩︎
-
A decade ago, Lokad was commissioned to reduce the working capital on the women’s segment of a large luxury watchmaker. Out of the thousands of watches listed in the catalog, a store would typically not have more than a few dozen items to showcase. However, despite this limited assortment, it represented a sizeable amount of money. During the mission, we realized that the watchmaker was extensively under-stocked. Indeed, over 90% of the cost of those watches come from the precious metals and the stones, which can be nearly entirely recycled into another watch if the chosen model doesn’t sell. Moreover, patrons would almost never buy watches at any reasonable price point unless they could touch the object in the store. Finally, the brand was very profitable and had no cash flow challenge of any kind. Thus, we concluded that perceiving inventory as a liability was incorrect; this inventory was literally generating its own demand. Reducing the inventory would have damaged the brand for no reason. As a result of these discoveries, we lost the client as we technically failed to deliver on the inventory reduction roadmap they desired. ↩︎