Le rôle de l'informatique

Joannes Vermorel

Dans de nombreuses, voire la plupart, des grandes entreprises opérant une supply chain, le service informatique a des années de retard accumulé. Ce retard est constitué d’une myriade de problèmes, d’incohérences ou de fragilités qui pourraient être résolus mais ne le sont pas. En plus de créer d’énormes surcharges bureaucratiques, cette interminable série de tracas inutiles démotive tout le monde. La supply chain, qui se situe en plein milieu du paysage applicatif, est particulièrement impactée. De manière anecdotique, la partie supply chain¹ représente fréquemment la moitié du retard informatique total de l’entreprise.

Pire encore, le retard est souvent obscurci par une Grande Transition, généralement une mise à niveau d’un ERP. C’est la conséquence directe de l’attente que la Grande Transition résolve tous les problèmes qui ont été laissés sans réponse au cours de la dernière décennie. Pourtant, cette attente est erronée. En effet, la Grande Transition, même si elle est menée à bien², introduira de nombreux nouveaux problèmes, même si elle parvient à éliminer certains des anciens.

La Grande Transition a deux effets secondaires : d’une part, elle réduit au silence toutes les divisions - à l’exception du service informatique - en ce qui concerne les questions logicielles ; d’autre part, elle agit comme un trou noir absorbant tous les budgets et toute l’énergie. Le second est une conséquence du premier.

En raison de sa nature même, la Grande Transition est très technique. Personne - à l’exception des spécialistes de l’informatique - ne comprend vraiment les détails de la migration d’un système de base de données à un autre, et les incompatibilités subtiles qui existent entre les deux. Une fois que les autres départements sont réduits au silence, il n’y a aucune résistance à tout canaliser vers la Grande Transition. Les autres départements jouent généralement le jeu dans l’espoir erroné que cela accélérera la Grande Transition. Ce ne sera pas le cas. Au contraire, plus le budget est important, plus l’initiative est lente.

Parmi les grandes entreprises, cette approche prévaut depuis les deux dernières décennies. Les résultats sont désastreux. Les entreprises continuent de payer des frais exorbitants pour des applications CRUD³ qui auraient dû être banalisées - via l’open source - il y a plus d’une décennie. Les délais de mise en œuvre n’ont jamais été aussi longs. Cerise sur le gâteau : les performances et la réactivité des logiciels d’entreprise sont toujours aussi médiocres, alors que le matériel sous-jacent est 1000 fois plus performant qu’il y a deux décennies.

Cette situation nécessite une réparation en profondeur : le service informatique doit cesser de se comporter comme le Grand Architecte au nom de tous les autres départements. Au lieu de cela, le service informatique doit devenir un coach pour les autres départements, en se concentrant exclusivement sur l’infrastructure⁴, laissant tout le reste aux départements eux-mêmes avec une mentalité de facilitateur.

La position de Grand Architecte est intenable : même collectivement, le service informatique ne peut pas tout savoir sur la finance, le marketing, les ventes, la paie, la production, la comptabilité, le transport, la planification, la conformité, le juridique, etc. Le couteau suisse gâche la plupart des initiatives qu’il entreprend. Chaque livraison bâclée entraîne davantage de problèmes qui nécessitent une correction ultérieure. La génération de backlog est à la fois inévitable et sans fin. À mesure que les logiciels deviennent de plus en plus omniprésents chaque année, le backlog devient de plus en plus ingérable chaque année.

La solution est simple⁵ : abandonner le rôle de Grand Architecte et repositionner le service informatique en tant que facilitateur et mentor pour toutes les initiatives liées aux logiciels exécutées par les autres départements. Mettre les départements, comme la supply chain, aux commandes de leurs propres initiatives logicielles les oblige à revoir leurs propres ambitions : plus de boucs émissaires pour le backlog qui devient incontrôlable. Le département est responsable à la fois de ses succès et de ses échecs.

Cependant, cette solution est presque jamais mise en œuvre.

Repositionner le service informatique en tant que facilitateur signifierait réduire ses budgets de moitié, voire plus, conséquence directe d’une empreinte opérationnelle beaucoup plus réduite au sein de l’entreprise. Cela est inacceptable pour le responsable du service informatique dont la position rivalise souvent, en termes de pouvoir, avec celle du PDG pendant la Grande Transition.

Cela signifierait également que les responsables de département devraient assumer la responsabilité de leurs propres initiatives logicielles - ou de leur absence. Il est confortable de pouvoir rejeter la faute sur le service informatique chaque fois qu’un projet dérape - un événement courant dans le domaine des logiciels. Cela permet également aux départements d’éviter la question épineuse du recrutement de talents en informatique, qui est un défi depuis des décennies.

Néanmoins, à mesure que les logiciels d’entreprise évoluent vers le SaaS (Software as a Service), la perspective du Grand Architecte s’estompe progressivement, car les fournisseurs se chargent de l’hébergement, des sauvegardes, des mises à jour, etc. Ainsi, bien que de manière incidente, les responsables de département sont progressivement contraints de rendre des comptes pour leurs décisions en matière de logiciels, et le service informatique est progressivement contraint de renoncer à ses anciennes responsabilités.

Les logiciels d’entreprise sont arrivés dix ans en retard à la fête du SaaS. Je prédis qu’il faudra une autre décennie pour que la plupart des grandes entreprises abandonnent la mentalité du Grand Architecte.