Due diligence technologique pour le private equity : cibles NetSuite et ERP

L'analyse statique par IA de l'ERP cible, en 48-72 heures, chiffre la dette de scripts, le risque de permissions et les fuites de marge avant le virement des fonds : le constat entre ainsi dans le contrat d'acquisition au lieu d'apparaître après la clôture. Consultez le registre 100x pour les lignes qui sous-tendent ce levier.

Que doit contenir un rapport de due diligence technologique ?

La plupart des livrables de due diligence technologique sont des documents narratifs qui répètent ce qui figure déjà sur la facture de l'éditeur. Un rapport qui éclaire réellement un prix d'acquisition doit répondre à six questions mécaniques, chacune assortie d'un chiffre.

1. Inventaire des personnalisations. Chaque déploiement de script, enregistrement personnalisé, workflow et recherche enregistrée de l'instance cible, avec propriétaire, date de dernière modification et fréquence d'exécution.
2. Exposition à l'obsolescence. Quelles personnalisations dépendent de versions de plateforme en fin de vie, et ce que coûte la refonte en semaines d'ingénierie et en dollars.
3. Risque de permissions et de séparation des tâches. Chaque rôle noté sur un indice de 0 à 4 par rapport à l'organigramme, avec les identifiants partagés et les circuits d'approbation non séparés signalés nommément.
4. Topologie des intégrations. Chaque interface entrante et sortante, le middleware sur lequel elle repose, et l'abonnement récurrent qui est transféré à l'acquéreur à la clôture.
5. Préparation des données pour la consolidation. Structure du plan comptable, configuration des filiales, doublons du référentiel articles et clients, et ce qui doit être vrai avant que la cible puisse être intégrée à la clôture de la plateforme.
6. Un plan de remédiation chiffré pour le jour 1 et les 100 premiers jours. Pas des recommandations. Un plan séquencé avec un prix, pour que le chiffre puisse entrer dans le contrat d'acquisition.

Quels signaux d'alerte ERP devraient modifier votre prix d'offre ?

Ce sont les constats qui ont, à plusieurs reprises, justifié un ajustement de prix ou une indemnité spécifique dans les opérations que nous avons examinées.

• Un cycle commande-encaissement qui dépend de scripts hérités non maintenus, écrits par une personne qui a quitté l'entreprise.
• Des scripts d'événement utilisateur synchrones qui verrouillent des enregistrements sous charge concurrente et plafonnent le débit des transactions.
• Des identifiants administrateur partagés, ou des rôles financiers disposant de pleins pouvoirs de création et d'approbation sur le même type de transaction.
• Un tableur parallèle ou une base de données de poste de travail qui réalise une étape que l'ERP est censé réaliser, comme le calcul des coûts par affaire ou le rapprochement des stocks.
• Des abonnements middleware représentant un coût annuel significatif pour des interfaces qui pourraient fonctionner nativement.
• Deux plans comptables ou plus entre entités, que la direction présente comme consolidés.
• Une clôture de période de plus de dix jours ouvrés, ce qui signifie généralement que les chiffres soumis à la due diligence sont eux-mêmes des estimations.

L'indice de risque des rôles (0-4)

Nous notons chaque enregistrement de permissions sur une échelle fixe de cinq points, afin que le risque d'accès devienne un chiffre que l'équipe de l'opération peut comparer d'une cible à l'autre, plutôt qu'un paragraphe narratif.

Pourquoi 48-72 heures plutôt que quatre à six semaines ?

Les délais de due diligence conventionnels sont fixés par le calendrier des entretiens avec les parties prenantes, non par la difficulté de l'analyse. La configuration et la base de code contiennent déjà la réponse. Nous exécutons une analyse statique automatisée sur celles-ci et consacrons nos heures de travail humain à l'interprétation plutôt qu'à la planification.

Ce dont nous avons besoin de la part de la cible

• Accès en lecture seule à l'instance ERP, ou un export des métadonnées si l'accès est restreint avant la LOI.
• Le dépôt des personnalisations, s'il en existe un sous gestion de versions.
• Une liste à jour des rôles et des utilisateurs.
• Les calendriers de clôture des trois dernières périodes.
• Une liste des systèmes connectés et de leurs contrats.

Livrables

• Matrice des risques prête pour le conseil, notée et hiérarchisée.
• Inventaire des personnalisations et des intégrations avec exposition à l'obsolescence.
• Notation des risques des rôles de 0 à 4 par rapport à l'organigramme.
• Coût de remédiation chiffré, séquencé entre le Jour 1 et les 100 premiers jours.
• Une synthèse d'une page rédigée pour le comité d'investissement, non pour la DSI.

Questions fréquentes

Recherches associées