Fin 2013, la journaliste Rachel King (The Wall Street Journal / CIO Journal, 1/11/2013), relayée début 2015 par Eric Peters (HubSpot, Mendix), révélait l’option prise par Elon Musk – l’un des créateurs de PayPal, fondateur de SpaceX (mars 2002) et de Tesla Motors (Octobre 2008) – quant au choix de l’ERP de sa marque automobile.
Pour bâtir un système d’information global, capable de gérer tous les métiers d’une entreprise en forte expansion et anticiper les montées en charge, il semblait logique de rationaliser et de standardiser les systèmes utilisés, à l’image de GM qui voulait passer entre 2000 et 2010 de 70 à 6 SI différents. Deux grandes options se dégagent habituellement : choisir la suite logicielle d’un vendeur unique, couvrant correctement la grande majorité des besoins ou sélectionner les meilleurs produits disponibles sur le marché, par type d’activité (finance, logistique, PLM…) puis les faire se parler ; avec dans les deux cas un possible recours à des développements spécifiques en nombre limité autant que faire se peut.
En effet, en 2013, les ERP « du commerce » savaient a priori remplir les besoins d’une ligne de production automobile : SAP, par exemple, propulsait déjà Porsche, une référence dans le secteur de l’automobile sportive. De plus, un projet SI peut être structuré agilement en phases successives, organisées par priorités, de manière à en diminuer le délai d’implémentation.
Mais, Jay Vijayan, CIO de Tesla de 2012 à 2016, estimait alors que “déployer SAP pouvait prendre plus d’un an et plusieurs millions de dollars à cause de toutes les intégrations nécessaires”. Elon Musk prit par conséquent la décision de développer l’ERP de Tesla « en interne », dans un délai record de 4 mois, au lieu de choisir le produit d’un des leaders du marché comme Oracle, SAP ou encore Microsoft Dynamics, que Tesla utilisait par ailleurs.
Pourquoi ce choix?
Tesla ne semblait pas manquer de ressources financières ou technologiques pour réussir l’implémentation d’un ERP Manufacturing. Pourquoi alors prendre le risque de construire un outil interne en si peu de temps, quitte à « réinventer la roue » et reproduire ce que parviennent à faire les ERP standards après plusieurs années de recherche et développement, sans pour autant être sûr de pouvoir aisément le maintenir et le faire monter en charge ?
Il est important de noter qu’il s’agit ici de la partie e-Commerce & Logistique de l’ERP de Tesla : en d’autres termes, de ce qui différencie la façon d’acheter une Tesla de la façon d’acheter une Chevrolet Bolt EV. Le Design Studio de Tesla permet de faire de sa Model S, X ou 3, un modèle quasiment unique, grâce au large éventail de configuration. Il est aussi possible, en théorie, de changer tardivement d’avis et de modifier une option même lorsque votre future voiture est sur les lignes de production (malheureusement, je n’ai pas pu vérifier cette théorie pour de sombres raisons matérielles).
La brique e-Commerce & Logistique « made in Tesla » prend alors tout son sens : elle autorise les clients à intervenir dans l’usine, au plus près de leur voiture, simplement. Une nouvelle expérience utilisateur et un avantage concurrentiel déterminant ont été rendus possibles par un choix stratégique ciblé sur une partie du processus.
Qu’en retenir?
Non, au moment où Cloud et SaaS se diffusent de plus en plus dans les organisations de toutes les tailles, l’ERP « 100% maison » n’est pas de retour, bien au contraire.
L’heure est bien à la rationalisation des SI, à une approche de type « Industrie automobile » : un produit standardisé, dans lequel des composants standards font 80% du travail, particularisé le plus tard possible au cours de sa construction. Les 20% restant peuvent (doivent ?) être développés sur-mesure pour différencier sa marque ou le service, la plus-value apportés au client.
Les offres Cloud actuelles des géants Oracle ou SAP vont aussi dans ce sens : leurs ERP proposent les principaux flux standardisés (« Best Practices ») adaptables – dans une certaine mesure – par paramétrage et intégrables à des applications tierces selon les API disponibles ou par Web Services. Dans les projets Cloud, le recours aux développements spécifiques est considérablement diminué : les clients passant d’une offre traditionnelle On Premise au Cloud se voient contraint d’abandonner nombres de spécifiques couteux, jugés obligatoires, stratégiques et vitaux il y a encore quelques mois.
Ce dernier point ne peut se faire sans un travail préalable de conduite du changement avec les équipes métier. Une des premières étapes obligatoires de ce que l’on appelle aujourd’hui la « transformation numérique » consiste en fait à identifier les processus internes où la technologie doit être un différenciant et ceux où les fonctions standards de l’ERP pourraient convenir moyennant une évolution des habitudes internes.
En effet, au moment de choisir un nouvel ERP, faut-il choisir entre un ERP qui fait des demandes d’achat et des commandes d’achat et un autre ERP qui fait des demandes d’approvisionnement et des commandes fournisseur ? Ou bien est-il préférable de baser son choix sur la souplesse de l’offre Cloud de son éditeur, sur le nombre d’APIs disponibles, sur les possibilités d’ajout de briques sur-mesure représentant l’ADN de l’entreprise, la spécificité de son savoir-faire, sa plus-value pour le client.
Le recours à l’Open Source peut ici être un choix stratégique avantageux : le code est modifiable à souhait (ou presque), sans contrainte éditeur (ou presque), avec le support de la communauté et de votre prestataire de services, pour un coût compétitif.
Oui, en 2012 Elon Musk était bien en avance de quelques années sur l’orientation du marché des solutions de gestion. Mais il était surtout pleinement conscient de l’importance de conduire la transformation numérique de sa société, pourtant âgée uniquement de 5 ans.
