Le contexte :
Une question essentielle se pose lorsqu’un besoin informatique est identifié dans une entreprise. Doit-on construire la solution ou faut-il adopter une solution toute faite ? Dans la plupart des cas les entreprises orientent leur choix sur des solutions du marché, et les développements internes n’interviennent que si aucun logiciel n’existe ou seulement si aucun d’entre eux ne répond correctement au besoin.
Articles déjà publiés :
Le développement est une solution trop risquée dans notre cas
Dans l'article précédent nous avons essayer de comprendre pourquoi le développement spécifique était parfois vu comme un risque dans une DSI. Nous allons essayer d'analyser une autre idée reçue sur le développement en interne
Le développement
n’est pas notre métier
L’informatisation a complètement révolutionné l’organisation de l’industrie ces quarante dernières années. Un rapprochement est souvent fait entre l’informatisation et l’industrialisation. Au début de l’ère industrielle, certaines entreprises possédaient leurs propres productions d’électricité. Aujourd’hui ce n’est plus le cas et ces entreprises s’appuient sur des fournisseurs externes d’énergie. Pour un grand nombre de sceptiques les développements spécifiques sont rangés au même niveau et il est préférable pour eux de s’appuyer sur des progiciels pour couvrir leur besoin. Dans la même logique, une entreprise n’a plus besoin d’héberger ces propres machines puisque le cloud est présenté comme la solution miracle….
Pour certaines sociétés les solutions logicielles ne sont plus seulement des outils qui permettent d’exécuter des processus mais ils sont également un moyen d’optimiser leur organisation, de permettre d’aller vers de nouvelles façons de faire des affaires. Mais certains décideurs oublient que nous sommes aujourd’hui dans une société de marchés où chaque industrie doit se démarquer de ses concurrents directs. Si tous utilisent les mêmes solutions, s’organisent de la même manière, il sera de plus en plus difficile pour une entreprise de se différencier des autres et d’obtenir un avantage sur ses concurrents.
Développer des logiciels n’est peut être le métier de la plupart des sociétés mais essayer de se démarquer des autres doit rester leur but premier. Une entreprise ne devrait pas abandonner les méthodes qui l’ont fait avancer, arriver là où elle en est, pour passer à des organisations dictées par des progiciels. Le coût de ces solutions clé en main est la plupart du temps énorme, que ce soit d’un point de vue financier mais aussi sur le côté humain. Bien trop souvent ces nouvelles solutions font à peine mieux que les anciennes.
Mettre en place de nouvelles idées dans un progiciel est toujours possible mais chaque personnalisation est très lourde, longue et coûteuse à mettre en place. Comparé à une solution développée en interne de manière agile il n’y a pas comparaison. Certaines entreprises peuvent choisir un compromis et demander à des sociétés de service de leur développer pour eux une solution spécifique en mode forfait ou en régie. Mais sous traiter son besoin pose d’autres questions qui dépassent le cadre de cet article. Qui est maître de la solution, que ce soit d’un point de vue organisationnel, fonctionnel et technique ?
Une autre remarque sur l’agilité, les méthodes agiles ne doivent pas être cantonnées au développement mais doivent être adoptées à tous les niveaux dès la prise de besoin jusqu’à la mise en production.
Les chefs de projets ont très souvent commencé comme développeur. Les chefs de projet sont généralement les personnes choisies pour travailler sur le choix entre un développement spécifique et un progiciel. Ayant fuit la technique par incompréhension du développement ou par méconnaissance, le choix d’un progiciel est un choix plus facile. Il comporte moins d’inconnue, moins de risque et un sentiment de maîtriser la solution. C'est pourquoi les choix stratégiques d'une entreprise doivent être pris en mêlant à la fois des profils fonctionnels et des profils techniques.
Dans le prochain article j'aborde une autre idée reçue "Les développeurs ne sont pas efficaces"
Merci à Agnes Crepet, Anne Laure Rigaudon, Alfred Almendra, et les autres anonymes pour leur relecture et leurs différentes critiques.

Aucun commentaire:
Enregistrer un commentaire
Remarque : Seul un membre de ce blog est autorisé à enregistrer un commentaire.