Il y a un probleme devenu de plus en plus courant dans les entreprises ces dernieres annees : la fragmentation de la technologie.
La technologie est partout, mais les outils fonctionnent chacun de leur cote et ne communiquent pas entre eux.
Des logiciels sont introduits avec de bonnes intentions, mais sans jamais etre reellement integres aux processus de l'entreprise. Les donnees circulent mal, les activites exigent des passages manuels et les flux dependent trop des personnes et trop peu d'une infrastructure solide.
La limite du modele traditionnel de "software house"
Aujourd'hui, dans de nombreux cas, il ne suffit plus d'etre "une software house" au sens le plus traditionnel du terme.
Car, meme si developper du logiciel reste essentiel, cela ne resout pas a lui seul les problemes operationnels d'une entreprise.
Le vrai sujet est ailleurs : comprendre comment le logiciel s'insere dans les processus reels, comment il dialogue avec les autres systemes, comment il tient dans le temps et comment il accompagne la croissance au lieu de la freiner.
C'est exactement la que se joue la difference entre un fournisseur technique et un partenaire technologique.
Un fournisseur traditionnel livre un projet.
Un partenaire technologique fait en sorte que ce projet entre vraiment dans le travail quotidien, soutienne l'operationnel et continue a creer de la valeur apres la mise en ligne.
Les choix qui font la difference
Travailler comme partenaire technologique, c'est faire des choix moins visibles, mais beaucoup plus importants :
- Comprendre le processus avant de proposer une quelconque solution
- Distinguer clairement ce qu'il faut developper de ce qu'il faut integrer
- Reduire les points de friction entre systemes differents
- Eviter d'ajouter de la complexite la ou il faut simplifier
- Prendre des decisions techniques en pensant a la continuite, a la maintenance et a l'evolution dans le temps
Digitalisation reelle ou simple adoption d'outils
La digitalisation reelle ne coincide pas avec l'adoption d'un nouvel outil. Elle correspond a une amelioration concrete de la facon dont une organisation travaille.
Si un logiciel est introduit mais que l'equipe continue a utiliser des feuilles paralleles, des controles manuels ou d'autres passages hors processus, ce projet n'a pas encore produit la valeur promise.
Si, au contraire, la technologie rend le flux plus lisible, plus fiable et plus durable, alors le changement est reel.
Trois niveaux de travail, un seul objectif
L'approche de fabricators repose sur trois niveaux distincts mais etroitement lies.
Le premier est le developpement logiciel : analyse, conception, architecture, implementation.
Le deuxieme est l'integration : faire dialoguer des systemes differents, connecter les donnees et construire une continuite operationnelle entre des outils qui, autrement, resteraient des ilots separes.
Le troisieme niveau est le plus important : assumer un role actif dans la direction technologique des projets.
Nous ne nous contentons pas d'executer des demandes. Nous aidons a definir les priorites, a choisir la bonne voie, a eviter des erreurs couteuses et a construire des bases solides sur lesquelles grandir.
C'est a l'intersection entre developpement, integration et responsabilite operationnelle que se cree aujourd'hui la valeur la plus concrete.
Pourquoi les problemes naissent des couches, pas des outils pris isolément
Quiconque travaille dans des contextes complexes le sait bien : les problemes naissent rarement d'un seul logiciel mal concu.
Le plus souvent, ils viennent d'une structure numerique qui grandit par couches superposees, sans logique commune suffisamment forte pour les tenir ensemble.
C'est pourquoi notre travail ne peut pas etre raconte uniquement comme du "developpement logiciel".
C'est un travail qui part de la technologie et va jusqu'a l'operationnel. Il rassemble code, processus, systemes et vision.
C'est aussi pour cela que fabricators doit etre compris de facon plus large : oui, software house, mais aussi system integrator, partenaire technologique et facilitateur de digitalisation.
Non pas parce qu'il faudrait plus d'etiquettes, mais parce que les entreprises ont besoin d'une definition plus precise de ce dont elles ont reellement besoin.
Une technologie qui ne reste pas sur le papier, des systemes qui travaillent ensemble, des partenaires capables de resoudre de vrais problemes, pas seulement de developper une fonctionnalite.
L'avenir du travail technologique n'appartient pas seulement a ceux qui savent construire. Il appartient aussi a ceux qui savent integrer et assumer la responsabilite de faire vraiment fonctionner ce qu'ils realisent.
