Tesla nam in 2012 een vrij ongebruikelijke beslissing, zelfs voor een technologiebedrijf: in plaats van een groot enterprise resource planning (ERP) systeem aan te passen aan hun manier van auto’s produceren en verkopen, ontwikkelden ze een eigen platform. Dit project werd bekend als Warp of Warp Drive en stond onder leiding van Jay Vijayan, destijds verantwoordelijk voor bedrijfssoftware en later CIO van Tesla. Het echte verhaal is opmerkelijk, hoewel sommige verslagen op internet feiten en details die moeilijk te bewijzen zijn, door elkaar halen.
De kern van Tesla’s eigen ERP in 20 seconden
- Tesla ontwikkelde haar eigen ERP omdat conventionele bedrijfssoftware niet goed aansloot bij haar geïntegreerde model en directe verkoopstrategie.
- Jay Vijayan en zijn team maakten binnen ongeveer vier maanden een eerste werkbare versie.
- Het systeem verbond operaties, productie, voorraad, verkoop en andere kritieke afdelingen.
- Vijayan had eerder een aanbieding van Tesla afgewezen vanwege een substantieel salarisaanbod bij VMware.
- Deze case bewijst niet dat het ontwikkelen van een eigen ERP beter is dan SAP voor elke onderneming.
Het essentiële deel van het verhaal is goed gedocumenteerd. In augustus 2012, enkele maanden na de eerste leveringen van de Model S, vertelde Vijayan in een interview met Metis Strategy dat kritieke toepassingen voor Tesla’s kernfuncties voornamelijk eigen ontwikkeling waren.
Een jaar later was hij nog explicieter. Tijdens een event van Constellation Research verklaarde hij dat Tesla de traditionele ERP-systemen had bestudeerd en geconcludeerd dat deze niet de snelheid en flexibiliteit boden die nodig waren. Elon Musk ondersteunde toen de ontwikkeling van een eigen systeem.
Volgens een verslag van TechCrunch uit 2013 werkten meer dan 250 mensen aan de bouw van het ERP, waarvan de eerste versie binnen vier maanden klaar was.
Deze hoeveelheid staat haaks op sommige recente berichten op sociale media die verwijzen naar een team van slechts 25 ingenieurs. Meer gedocumenteerde bronnen uit die tijd wijzen op meer dan 250 betrokkenen, al betekent dit niet dat alle medewerkers exclusief aan de kern van het systeem werkten.
Tesla stopte niet met SAP omdat SAP te traag was
Hier ligt de eerste belangrijke nuance.
Zeggen dat Tesla ontdekte dat SAP “niet meer voldeed”, vereenvoudigt het verhaal te veel.
In 2012 legde Vijayan uit dat Tesla bij het bestuderen van standaard ERP-oplossingen vaste kwam te staan dat deze systemen bedoeld waren voor zeer diverse bedrijfsprocessen. Dit voegde functies toe die Tesla niet nodig had en maakte het systeem ingewikkelder.
Tesla had bovendien een heel andere bedrijfsstructuur dan traditionele autofabrikanten.
De autosector ontwikkelde zich rond uitgebreide netwerken van leveranciers, dealers en distributeurs. Tesla wilde veel meer functies direct integreren en een nauwere relatie met de klant onderhouden.
Het bedrijf verkocht zijn voertuigen rechtstreeks in plaats van uitsluitend via onafhankelijke dealers.
Daarom moest hun IT-infrastructuur daarop aansluiten.
TechCrunch meldde in 2013 dat Vijayan vond dat Tesla een eigen systeem nodig had vanwege de fundamentele verschillen in hun bedrijfsmodel en hoge mate van verticale integratie.
De beslissing was dus niet simpelweg “SAP is traag, dus bouwen we zelf”.
Het ging meer om:
Tesla wilde haar bedrijfsvoering organiseren op een manier die door bestaande ERP-systemen niet of te veel aangepast kon worden.
Het bedrijf koos ervoor de kosten en het risico van zelfontwikkelen te accepteren, afgestemd op hun unieke processen.
Er is geen sterke primaire bron die bevestigt dat SAP slechts elke halfuur of uur kon synchroniseren met de Tesla-webpagina, een detail dat vaker wordt genoemd.
Zo’n detail zou weggelaten moeten worden in een wetenschappelijk artikel, tenzij er aanvullende documentatie is die dat bewijst.
SAP beschikte destijds al over technologieën voor real-time integratie en systemen voor bedrijfsprocessen. Het implementeren van de specifieke architectuur die Tesla wilde, zou te complex, duur of traag geweest kunnen zijn voor een bedrijf dat zich voorbereidde op de Model S.
Jay Vijayan weigerde Tesla voordat hij de systemen leiding gaf
Het verhaal van de ingenieur die aanvankelijk nee zei tegen Elon Musk is stevig onderbouwd, maar verdient enkele correcties.
Zijn naam is Jay Vijayan, niet “Jay Bihan”, zoals soms automatisch wordt overgenomen.
Voor Tesla werkte hij jaren bij Oracle en later bij VMware, waar hij zich bezighield met bedrijfsapplicaties.
Vijayan vertelde later dat Tesla hem probeerde te recruteren terwijl hij nog bij VMware werkte.
Hij wees het eerste aanbod af, voornamelijk vanwege financiële redenen, niet omdat hij bij BMW zou werken zoals soms wordt beweerd. Vijayan werkte toen bij VMware.
In een latere interview legde hij uit dat het accepteren van de baan betekende dat hij teveel geld liet liggen. Forbes India vermeldde in 2020 dat hij ongeveer 2 miljoen dollar aan aandelen van VMware had en dat Tesla dat niet kon evenaren in compensatiepakket.
Tesla huurde vervolgens iemand anders in.
Ongeveer een jaar later nam Vijayan opnieuw contact op en koos toen wel voor de functie, ondanks een salarisreductie.
Zijn ervaring met bedrijfssoftware was zeer relevant voor de uitdagingen van Tesla op dat moment. Hij had gewerkt aan productontwikkeling bij Oracle en beheerste bedrijfsapplicaties bij VMware.
In 2012 kwam hij aan als vicevoorzitter van IT en bedrijfsapplicaties. Later werd hij CTO en bleef tot 2016 bij Tesla.
Vier maanden voor het bouwen van de eerste Warp
Het meest spectaculaire deel van het verhaal is ook gedocumenteerd, al vereist het precisie.
Tesla ontwikkelde niet in vier maanden alles vanaf nul, maar maakte binnen die periode een werkbare eerste versie van haar geïntegreerde systeem.
Vijayan en zijn team bouwden dus in ongeveer vier maanden een eerste functionele versie van het geïntegreerde systeem.
Vijayan’s professionele biografie beschrijft het project als een intern systeem voor e-commerce en ERP, waarvan de minimale werkbare versie in dat korte tijd werd gerealiseerd.
Dat past beter bij hoe complexe zakelijke platformen doorgaans worden ontwikkeld.
De eerste versie maakte operationeel gebruik mogelijk, terwijl het softwareplatform zich over de jaren zou uitbreiden met fabrieken, voertuigen, markten, servicecentra en nieuwe processen.
Warp moest een gemeenschappelijke basis vormen voor verschillende afdelingen zonder dat die afhankelijk waren van talloze koppelingen tussen gescheiden applicaties.
Volgens Vijayan was dat juist een van de voordelen van het systeem.
In plaats van systemen die via meerdere koppelingen informatie uitwisselden, kon Tesla haar componenten ontwerpen rond een gedeeld model.
De naam ‘Warp’ volgt bovendien Musk’s voorliefde voor sciencefictionreferenties: Warp of Warp Drive, verwijzend naar het fictieve voortstuwingssysteem uit Star Trek.
Het is belangrijk om te benadrukken dat dit software niet hetzelfde is als dat binnen de auto’s zelf werkt.
Warp betreft enterprise-infrastructuur. Het is niet Autopilot of het besturingssysteem van de Model S.
Het ERP ontstond terwijl Tesla haar toekomst speelde met de Model S
De tijdsdruk is logisch te verklaren.
De eerste leveringen van de Model S vonden plaats op 22 juni 2012 en betekenden een grote sprong ten opzichte van de Roadster.
Tesla moest een fabrikant worden die in staat was een auto op grote schaal te produceren.
Het bedrijf had die stappen gezet na een zeer moeilijke financiële periode.
In 2008 kwam Tesla heel dichtbij faillissement. Musk legde later uit dat de financieringsronde op kerstavond cruciaal was om de ondergang te voorkomen.
Het is echter belangrijk om het bewezen verhaal en enkele dramatiserende details gescheiden te houden.
Tesla doorstond echt een ernstige crisis en rondde in december 2008 een financieringsronde af, die Musk herhaaldelijk beschrijft als een van de moeilijkste momenten in zijn leven.
Later kwamen er twee goed gedocumenteerde financiële steunacties:
- Daimler verwierf in mei 2009 ongeveer 10% van Tesla voor circa 50 miljoen dollar.
- In januari 2010 sloot Tesla een lening af met het Amerikaanse Department of Energy voor maximaal 465 miljoen dollar onder het programma voor geavanceerde technologische voertuigen.
Van dat bedrag was 101,2 miljoen bestemd voor engineering en systemen voor aandrijving, en 363,9 miljoen voor de ontwikkeling van de Model S en de productie-infrastructuur.
Tesla gebruikte de volledige lening en betaalde deze eerder dan gepland terug in mei 2013.
Dus, Warp ontstond niet direct in de crisis van kerstavond 2008. De crisis legde de nadruk op de behoefte aan een bedrijf dat onder extreme tijdsdruk en met beperkt kapitaal opereerde, zoals tijdens de ontwikkeling van de Model S, maar het ERP-systeem werd enkele jaren later ontwikkeld.
Heeft Tesla echt ‘SAP uitgezet’?
Dit is waarschijnlijk de uitspraak die de meeste nuance vereist.
Er is solide bewijs dat Tesla gedurende haar vroege jaren SAP gebruikte en later een eigen ERP ontwikkelde dat haar kernfuncties overnam.
Ook is gedocumenteerd dat Vijayan en zijn team weigerden een conventioneel ERP als centrale platform te gebruiken.
Wat moeilijker te bewijzen is met publieke bronnen, is de exacte timing van de afschakeling van SAP en of beide systemen enige tijd naast elkaar hebben bestaan.
Daarom zou de uitspraak “Tesla schakelde SAP in vier maanden uit” te sterk zijn gebaseerd op de beschikbare bronnen.
De meest juiste formulering is dat Tesla binnen ongeveer vier maanden de eerste versie van haar eigen ERP-platform bouwde en haar kernfuncties overstapte op dat systeem.
In augustus 2012 bevestigde Vijayan al dat kritieke applicaties voor Tesla’s kernactiviteiten eigen ontwikkeling waren.
Wat Warp anders maakte
De grote voordelen van intern bouwen lagen niet noodzakelijkerwijs in meer functionaliteit.
Integendeel, het ging juist om het ontwikkelen van alleen wat nodig was en dat aanpassen wanneer processen veranderden.
Een traditioneel bedrijf past processen aan om te matchen met grote enterprise-platformen en voegt andere functies toe via modules of integraties.
Tesla kon tegelijk proces en software aanpassen, wat vooral nuttig was omdat het nog vorm moest geven aan hoe het auto’s zou maken, verkopen en onderhouden.
De directe relatie met klanten maakte ook dat de grenzen tussen systemen vervaagden.
Verkoop, bestellen, productie, voorraad, logistiek en service konden informatie delen via een door Tesla ontworpen infrastructuur.
Het grote voordeel is dat de software exact kan weergeven hoe het bedrijf functioneert.
Aan de andere kant betekent dit ook dat het bedrijf altijd verantwoordelijk is voor het onderhouden ervan.
Waarom doen Volkswagen, BMW of Mercedes niet hetzelfde?
Dit is de meest interessante vraag, maar het antwoord is niet dat Tesla een geheime truc ontdekte die andere autofabrikanten niet kennen.
Het ontwikkelen van een eigen ERP is extreem duur en risicovol.
SAP, Oracle en Microsoft delen de kosten voor hun platforms onder duizenden klanten en onderhouden systemen voor financiën, belasting, inkoop, HR, logistiek, productie, consolidatie en veel andere functies. Al deze functies zouden afzonderlijk ontwikkeld, geïntegreerd of gekocht moeten worden door een bedrijf.
Daarnaast heeft een lang bestaand bedrijf decennia aan fabrieken, overnames, filialen, leveranciers en systemen die op hun beurt verouderd zijn.
Tesla begon vanuit een heel ander punt.
Toen ze Warp bouwden, was Tesla nog een jong bedrijf dat haar bedrijfsprocessen en IT-infrastructuur gelijktijdig kon ontwerpen.
| Tesla in 2012 | Grote traditionele fabrikant |
|---|---|
| Processen nog in ontwikkeling | Decennia aan gevestigde processen |
| Directe verkoop | Uitgebreide dealernetwerken |
| Weinig productlijnen | Veel merken en platforms |
| Relatief jong bedrijf | Duizenden legacy-systemen |
| Cultuur van softwareontwikkeling | Grote enterprise IT |
| Bijna vanaf nul kunnen beginnen | Extreem complexe migraties |
Dit maakt het geval Tesla moeilijk te imiteren.
Een bedrijf kan kosten besparen door eigen software te ontwikkelen, maar kan daarmee ook veel meer uitgeven aan programmeurs, beveiliging, support, compliance, updates en onderhoud over decennia.
De beslissing is alleen logisch wanneer de software een voldoende onderscheidende rol speelt in het bedrijf om die verantwoordelijkheid te rechtvaardigen.
Warp bewijst niet dat SAP overbodig is, maar wanneer het zinvol is zelf te bouwen
Vijayan verliet Tesla in 2016 en richtte Tekion op, een bedrijf dat veel van die ervaring toepast op software voor auto-retail.
De paradox is interessant.
Na het bouwen van specifieke software omdat Tesla te anders was voor standaard bedrijfssoftware, richtte Vijayan een bedrijf op om dat inzicht om te zetten in een product dat andere bedrijven konden kopen.
Dit is precies de logica achter de meeste commerciële ERP-systemen.
Wanneer veel bedrijven vergelijkbare problemen hebben, is het vaak verstandiger een platform te kopen dan zelf te bouwen.
Wanneer een bedrijf vindt dat de manier waarop het opereert een concurrentievoordeel vormt dat door standaardsoftware beperkt wordt, kan intern ontwikkelen meer voor de hand liggen.
Tesla bevond zich in dat tweede scenario.
Het ging niet omdat SAP niet sneller was of ongeschikt voor autofabrikanten. Een groot deel van de industrie bewijst het tegendeel.
Het ging erom dat in 2012 Tesla tegelijkertijd een auto, een fabriek, een netwerk en een nieuwe manier om de klant te benaderen aan het opbouwen was, en besloot haar bedrijfssoftware daarop af te stemmen.
De relevante vraag is niet waarom alle bedrijven nog steeds SAP gebruiken, maar
welke delen van de software van een bedrijf echt core zijn en welke louter infrastructureel.