Why we invested in (well, co-built) BONX

At OSS Ventures, we are lucky enough to be a bunch of builders, creating startups to change the world of operations. So far, we’ve launched 15 companies alongside inspiring founders and visionary industrials in three years, deploying software in 1080 factories all over Europe and the US in the process.

We took an habit to write down the history of how we stumbled upon a space, collaborated with a founder, got through the idea maze and started to scale the company when they exit and graduate out of the OSS co-building phase.

This one takes a special place in our hearts : it’s about resilience and surprising insights, deep technological shenanigans and unexpected business implications, blitz building in six months what competitors could not build in 5 years. It’s a good one.

You may find the read below interesting because :

• It is the genuine story of a bunch of builders ;
• It has deep insights in technology, applied to manufacturing ;
• It has some jokes and pretty pictures.

Sooooooo …… ERPs.

Those three letters, ERPs, can send your average factory director into overdrive. It is the one thing that every single factory worker uses at least 5 times a day. Entreprise Resource Planning is a software that truly is the backbone of any company. It usually blends finance, operations, supply chain and HR together in arcane “rules” and “key users”. It’s complicated, it’s very important, it’s long, it’s difficult. So, of course, it’s German. SAP reigns over the ERP category.

But it is a failed category. The average NPS of an ERP is 21 (which means that the average ERP implementation process is less pleasant than going to the dentist, which has an NPS of 23), more than half of ERP deployment projects fail, and shadow IT is rampant to make up for ERP’s weaknesses.

Why ?

Some history. ERPs were invented in woodworking factories in the 50s. The base issue was that with a lot (10k) of different products to be made, and a lot (10Ks) of different inputs, organizing the work of hundred of workers accross tens of machines is hard. Like, mighty freaking hard. And accouting is a nightmare, so knowing what goes where and how much it costs was … shaky, at best.

So, IBM and the likes came with a solution. Code a lot of “base processes” with “items”. Ask humans to give informations of the type of “this arrived”, “i paid that”, “I finished my work”, and get the robot to tell everyone what needs to be done based on the change of settings of it all.

It worked, sort of. It gave financial people visibility, and automated a reasonable amount of busywork organizing around the factories.

But then, when processes scaled and complexity grew, ERPs became monsters with millions of lines of code, dozens of and ERP implementations became those epic 24 months projects where one maps all the processes possible, try to imagine edge cases, perform “gap analysis” where a company has to change their processes to fit what’s already coded in the ERP and cannot be changed. Those projects fail more than half of the time.

Ripe for disruption, you said ?

At OSS Ventures, we love us some good ol challenge. We started with Charles and Remi, an amazing pair of technologists having worked at prestigious scale-ups, unicorns, having built technologies used by Pixar and Amazon. The journey began.

So we embarked on interviewing dozens of companies. With ERPs, without ERPs, with “failed” implementation projects, with “somewhat successful” projects under their belts, big, small, the works. In several weeks, we ended up with 120 data points (internal jargon for in-depth analysis).

Here are our findings :

• Big companies have reporting and auditing subjects. They need to be able to produce those and are legally responsible for it to be accurate. Implementing monstruous projects to be able to do this at scale is the turf of SAP and the Accenture of the world. They are bigcorporations, reluctant to change, they spent tens of millions to do those. Innovators dilemma. They won’t change ;
• Mid companies have productivity and organization subjects. They want to be able to operate at scale with repeatable processes. There are a lot of actors specializing on sub-categories ( “I’m the ERP of warehouses connected to e-commerce platforms, says Katana”, “I’m the ERP of mechanics where I have an algorithm that precisely master the use of raw material which accounts for 30% of your total costs, says Helios”, …) and thus winning their subsegments, while being average or subpar in all the rest : finance, supply chain, HR, … ;
• Small companies are stuck between two bad choices. Most of them have to get organized at some point. The local nerd did a 40 megabytes excel files that sort of does the job, and is highly customized, but it is not linked with the financial controlling software that they have. So the CEO either can try to grow with the excel and risk explosion, or implement a 24 months ERP with 50% failure rate and scratch every other software and defocus the org and have non-customized software.

So we chose to focus on small companies and ask a set of simple questions :

• Why are ERP implementations so painful and long and failure rate so high ?
• Why cannot ERP implementations satisfy the users and instead focus on weird “gap analysis”, forcing a certain type of processes to companies ?
• Why is the level of understanding of the workings from the ERP so low for the end users ?

To our great surprise, and after many scratch-your-head moments, we finally zeroed in the cause of those two. And it is not business. It’s tech.

The ERPs were invented in the 80s. At the time, the only data structure known was the “relational” data model. Think of separate excel sheets. And the only type of code known was “a human codes a process”. No code did not exist.

So all ERPs (including the latest ones) share a technical characteristic :

• The data structure is imposed, and relational (for example, SAP S/4HANA uses the proprietary SAP data model, even if they try to put some graph on top of it) ;
• Most if not all of the processes are tied to this data model and are standard.

This leads naturally to three things :

• First, ERP implementations are painful because all of the data of the company has to be mapped according to the data structure and processes imposed by the software ;
• Second, ERP implementations rely on “gap analysis” because at core, the company has to comply to the processes and data, at least the most basic ones, that are hard coded in the ERP, rather than being adapted to the company. So, impossible for the company to be truly free in their processes. And no possibility to change that core because in relational data management, it would break everything ;
• Third, and to our great surprise, a lot of processes and analysis are *simply impossible* to do with that set of technology. For example, asking questions such as “who are the customers who had a defect that was caused by a certain machine between those dates” is often impossible, because it asks five databases, and the complexity is n^5 (which is a lot). It is also highly non-resistant to any data or process change. So, no cake for you?

In our process at OSS, the “what is” phase is trying to understand, as deeply as possible, a given issue so we can try to solve it. That phase was done. So … “what if ?”

• What if an ERP could be implemented in three weeks ?
• What if any process, any data, any way of organizing oneself was possible ?
• What if company employees were empowered to write all of their processes and able to understand everything ?
• What if standards could become collaborative, open assets, instead of being locked-in, “secret sauce this is my biz” ERP shenanigans ?

Speaking with several dozens potential customers, we got more than 50% co-building agreement. The reaction was about equal share excitement and disbelief.

“People, if you do it, you’ll be magicians”
An early adopter presented with the vision

The technical and design secret sauce became clear :

• Graph database. By leveraging a graph database, one can manipulate any data structure with any level of complexity and answer very complex questions in milliseconds rather than hours. It was new (invented by Facebook), never used by an ERP, and was killing the “data structure has to be imposed” entirely. Of course, standards could be leveraged, but on one’s term. Collaborative standards, different by industries, co-created ;
• No-code. By empowering the nerd who was writing 40megs excel files to write, maintain, understand and be the steward of processes, we were enabling people to understand all processes, adapt them to the needs of the factories to no end ;
• Progressive. By implementing processes one by one and putting them live immediately, we were able to kill the 24-month risky implementation cycle, and start provide value in days, adding progressively to the complexity of the data structure and the processes, be able to roll back processes if needed, which was de-risking the whole process ;
• Multiplayer. By letting users create their own graphes and data structures and processes, but also empowering them to share them across the community for others to use, we could leverage the collective intelligence of builders instead of locking everyone in a complex, non-transparent, highly fragile data structure ;
• Focus. By keeping a “best of breed” approach, we could play nice with the buzzin pay/HR and finance modules ecosystem, and finally break free from complex ERPs : connected, not competing.

In eight weeks (a record), the first version was live with three co-builders. The inevitable tweaking of the solution began, and the value provided was immense.

Rémi deploying Bonx in a wooden furniture manufacturing plant

We started the go to market. Clients were pouring in and we hit the symbol of 500Ke ARR signed in less than 9 months. The offices were buzzing with developers, growth managers, implementation managers flying around to deploy Bonx at scale. In woodworking, consumer goods, luxury items, all over France.

The timing was clear : that is when OSS help comes to an end. We helped Remi and Charles onboard their core team and wired the check to go from hands-on co-builders to hands-off shareholders. Always a bittersweet moment, but also a very proud one as we know that team is on a special path to truly free operational companies from bad software, never ending implementations, and limitations in what they can do.

Here is to the builders.

Here is to changing the operational world, one software at a time.

Here is to BONX.