Running Microsoft Dynamics ERP at Alpine F1 Team

Most people watching a Formula One race see the drivers and the cars. They rarely see the manufacturing operation behind them, or the enterprise resource planning (ERP) system, the single platform that runs a company’s finance, parts and operations, that keeps it moving.

Jaco Schutte is ERP Manager at the Alpine Formula One Team, based at its Enstone factory. He trained as a computer engineer and spent about six years in the ERP partner space before joining Alpine five years ago. Today he leads the technical and functional design of the team’s ERP Software, Microsoft Dynamics 365 Finance and Operations.

In this episode of the Comparesoft ERP Podcast, Jaco explains what ERP selection, implementation and adoption look like inside Formula One, why he aligns process to the system before he customises it, and why the hardest part of the job is rarely the technology.

Why a Formula One Team Runs an ERP System

Start with the question most fans never ask: why does a race team need an ERP at all? Jaco’s answer reframes the sport.

“I don’t think a lot of people realise that F1 is just a different kind of manufacturing company,” he says. “Yes, it’s motorsport and it’s exciting, but there’s no profit margin, there’s no sales targets. Your focus is to get the car around the track as quickly as you can, and minimise your expenditure as much as you can.”

For a company of roughly 900 people, the ERP is the manufacturing tool that ties that work together. A manufacturing ERP here has to cope with constant change rather than a stable production line.
“It gives you the ability to plan manufacturing of components, source the materials, track the right build history and give visibility of cost,” Jaco explains. “All these caveats in an F1 environment give you the benefit, at the end of the day, to get the car to track quicker.”

He is careful not to overstate it. The ERP does not make the car faster. It makes the process faster.

“It’s more about us trying to facilitate the process to get things out quicker,” he says. “And that all translates to winning races at the end of it.”

How Alpine F1 Selected Its ERP System

Ask Jaco how you should choose an ERP and he describes a disciplined, evidence-led process.
“If you follow the correct approach, you’re looking at a structured, evidence-based evaluation: capability, process, integration, cost of ownership,” he says. “Ultimately, the downfall of any ERP implementation is when you have misalignment to process.”

Alpine’s own selection had a twist that few buyers will face. The choice was shaped by a commercial relationship.

“Because of commercial sponsorship, those normally trump certain areas,” he explains. “We would never take a product if it’s not a good fit, but Microsoft Dynamics was specifically chosen because we had a commercial sponsorship with Microsoft at the time.” Microsoft also acted as the implementation partner, which he credits for the successful delivery.

That sponsorship has since ended, yet Alpine has stayed with Dynamics, for a reason every buyer eventually meets: total cost of ownership.

“We spent a lot of energy and effort getting it to work well for the way we operate, and you don’t just walk away from that,” he says. “ERPs normally have a lifetime of about ten years, but it’ll be interesting to see what that looks like with the current rate of change.”

Why ERP Is Not a Silver Bullet

First-time buyers often expect an ERP to solve everything on its own. Jaco is blunt about that belief.

“The belief is just fundamentally wrong,” he says. “ERPs provide a consistent and structured platform, and if you use it correctly you can excel your operations. But you have to align your process to the system, ensure you are robust in your training, and get the right feedback from users.”

The point applies to any ERP implementation, not just an F1 one. The system rewards the work you put around it.

“If you adopt it and you maintain it, yes, definitely,” Jaco says. “But if you just deploy it and hope for the best, you’ll certainly pay for it.”

Running an In-House ERP Team in a Cost Cap Environment

Jaco joined five years after Dynamics went live, so he inherited a running system rather than building it. What he shapes is how Alpine supports it. In a cost cap environment, the team keeps ERP expertise in house rather than leaning on external consultants.

“The truth is it is more expensive for us to lean on external support,” he says. “Call it, in its simplest terms, having a partner on payroll. You have people with fundamental experience in running and modifying the platform, and that knowledge lives within your business.”

His ERP team is eight people, including himself. He is not arguing that every business should build one, but for Alpine it keeps both cost and knowledge under one roof.

An Agile Approach to ERP Implementation in F1

Jaco’s implementation style shifted when he moved from consulting into a race team.

“From a partner perspective we used to have a combination of Agile and Waterfall,” he says. “But from an F1 perspective we focus primarily on the Agile methodology, because we try to get that feedback earlier.” He pairs that with Microsoft’s FastTrack and Success by Design methodologies to stay close to best practice while still moving quickly.

The complication in F1 is rarely the build. It is the calendar.

“We don’t normally find the right time to have necessary downtime, or you have to plan your training accordingly,” Jaco says. “It comes down to how you align it to the business’s schedule. If you want this benefit, we need to make time for it.”

Where ERP Customisation Earns Its Keep at Alpine F1

Customisation is one of the biggest decisions in any ERP project, and Jaco starts from a clear default. Change the business to fit the system before you change the system to fit the business.
“To the detriment of the business sometimes, I would align the company to standard approaches first,” he says. “Then if the gaps are too big, or we can’t change a process to accommodate a certain flow, we look at customisation.”

He draws a hard line around the foundations of the platform, because that is where customisation quietly raises the cost of ownership for years.

“I would never customise something that changes the foundations of the ERP system, because it makes upgrades less seamless and you run into more problems,” he explains. “I actively avoid any customisation to general ledger financial postings, because no one wants to prove to the auditors why something has gone wrong.”

His alternative is to leave the standard behaviour intact and add a controlled step alongside it, a post-process that writes a separate journal entry, so every adjustment stays traceable and easy to audit. On how much customisation is safe overall, he will not give a number.

“It’s very contextual,” he says. “If you can work with an ERP in a vanilla state out of the box, excellent. But if you want to customise it, do it in a light-touch manner.”

Connecting PLM and ERP in Real Time

The most complex build Jaco’s team has taken on is an ERP integration with the design side of the business, so that engineering changes reach the factory floor without delay.

“The most complex bit we’ve done is getting real-time updates from our product lifecycle management solution,” he says. “Designers make design changes, but you need to kick off the manufacturing quite early, so you need to communicate those changes to the factory floor.”

Rather than build something proprietary, the team evaluated standard options first and proved them with data before committing.

“That process was only really successful because we took the time and built the relevant metrics around the analysis,” Jaco explains, “so we could say this is the throughput, this is the stability, this is the visibility.”

The payoff is the ability to change a component that is already being made.

“You may detect a small enhancement while designing the next iteration and think, I can retrospectively apply this to something currently being manufactured,” he says. “You look at the impact and decide how we want to apply it.”

Part Traceability When You Only Build a Component Once

Traceability matters everywhere in manufacturing, but in F1 the economics change how far you take it.

“Traceability is quite fundamental, not just to motorsport but to the manufacturing industry as a whole,” he says. “You need to be able to easily locate manufactured goods, anything that may compromise safety in the final product, or in our case assemblies within the car.”

Any capable ERP can track parts down to serial or batch level. The real decision is how granular to go, and Jaco says you must settle it early, with the right process engineers weighing the downstream impact. It comes down to a cost trade-off.

“If you have a very expensive component, you probably want to track it down to serial level, because if there’s something wrong you only want to record that individual assembly,” he explains. “But if it isn’t that expensive, you may record it at a batch level, because that has less overhead.”

F1 sits at the low-volume, high-value extreme, which pushes tracking towards the individual part.

“We prototype stuff, and you may only make it two or three times, so you probably don’t want to scrap all of them,” he says. “From a tracking perspective it’s always a bit more granular, and yes, that has more overhead, but you want that benefit at the end of the day.”

In practice, the serial-versus-batch call comes down to a few questions:

• How valuable is the component? High-value parts justify serial-level tracking; lower-value parts can sit at batch level.
• What is the recall unit? If something goes wrong, do you need to isolate one assembly, or is recalling a whole batch acceptable?
• Can you afford the admin overhead? More granular tracking captures more data, and someone has to record and maintain it.

Catching Integration Problems Early

When a new integration or process misbehaves, Jaco’s team relies on telemetry rather than luck. Early on, they decide to record metrics for every integration and process and publish them to a common platform.

“We have a bunch of dashboards with the relevant alerting,” he says. “You get to see average processing times, whether there’s a problem with performance going down, whether there are deviations at certain points in the day. The nice thing about having all this data is you can act on it.”

And nothing risky goes near live data first.

“We go through our proper testing platform and spin up the relevant environments,” he says. “Is the risk really that bad? Do it in the test environment. I do not want to deal with the fallout today.”

Where AI Fits Into ERP Today AT Alpine F1

Jaco is genuinely enthusiastic about AI in ERP, and specific about where the value is. He points first to natural language.

“I’ll specifically mention the Model Context Protocol that you can use with ERP systems,” he says. “The ability to use natural language with the relevant agents to automate processes, and get insight into them, is really going to change the way we work with ERP systems.”

The everyday win is asking a question instead of hunting through screens.

“Instead of interrogating a dashboard or going through a list of figures, just having a quick prompt will get the task done so much quicker,” he says. “Something simple like, can you summarise my main actions for today, or what’s the issue with this purchase order.”

What Alpine has already adopted is less glamorous and immediately useful: automated invoice capture, where AI reads incoming invoices and matches them, taking admin off the finance team. The slow part, he is clear, is not the technology.

“It is the adoption that takes time, the training, the upskilling, and getting the confidence that what it’s doing is what you want,” Jaco says.

How Jaco Drives ERP Adoption at Alpine F1

For all the talk of platforms and integrations, Jaco puts adoption down to people and process.
“Driving adoption is less about the technology and more about the people, the processes and how you handle change management,” he says. “The difference between success and failure comes down to how well you embed the system in your daily behaviours.”

He is wary of shipping a bare minimum and promising to improve it later. A colleague’s phrase has stuck with him: build something simple, lovable and complete rather than a minimum viable product (MVP).

“You need to deliver something people can love to work with,” he explains. “You can iterate over time, but if you’re not going to have the time to iterate, make sure it’s complete so it can be lovable.”

He is also clear about where responsibility for a process sits, and where it does not.

“Someone needs to take responsibility for these processes,” he says. “Your ERP team is amazing, but ultimately they are not responsible for your process.” After go-live he keeps system and business aligned with a feedback loop, pulling service desk data into dashboards and tagging recurring issues to decide whether a team needs more training or the process itself needs rethinking.