La manière de réaliser les schémas directeurs doit évoluer pour tenir compte des nouveaux enjeux et attentes des entreprises. Comment ? En conjuguant innovation et approche industrielle pour :
- Repenser les processus métier avec pour objectif l’innovation et l’efficacité opérationnelle.
- Déterminer les fonctionnalités assurant la meilleure péréquation entre support des processus métier, maîtrise de la diversité utile, scalabilité, flexibilité et évolutivité du SI.
- Construire l’architecture applicative comme un investissement industriel.
L’objectif du schéma directeur est de proposer un système d’information répondant aux besoins des Directions Métier de manière durable, avec la meilleure économie de moyens, dans les délais attendus et avec le risque minimum. Classiquement les difficultés d’un schéma directeur sont de bien se mettre d’accord sur les processus métier, de trouver le bon niveau de description des besoins fonctionnels pour être bien compris de l’utilisateur et pouvoir discriminer correctement les différentes solutions applicatives possibles, enfin de chiffrer le coût de mise en œuvre du futur système avec une bonne approximation. Avant les années 2000, de nombreux schémas directeurs ont privilégié des stratégies de refonte complète et abouti à des projets pharaoniques, et quelquefois catastrophiques.
Les attentes des Directions Générales ont profondément changé
Les Directions Générales, fortes de ces expériences passées, ont maintenant des attentes très claires concernant leur système d’information :
- la focalisation des investissements sur les enjeux stratégiques ou à fort ROI,
- la flexibilité et l’évolutivité du système d’information, qui doit vivre au rythme de l’entreprise,
- la rentabilité des investissements et la maîtrise du coût de possession du SI,
- avec comme première conséquence la valorisation systématique de l’existant applicatif,
- la livraison des projets dans des délais courts sans effets tunnel
- le « risque inutile » ZERO,
- le pragmatisme des solutions.
Les technologies informatiques se sont multipliées et diversifiées offrant maintenant une très large palette de solutions :
- en dépit de sa consolidation, le marché de l’ERP reste très riche, avec de nouveaux entrants, notamment dans l’open source ou les « verticaux métier ».
- beaucoup de solutions métier spécialisées sont disponibles en complément des ERPs
- les frontières fonctionnelles traditionnelles entre les offres logicielles se sont brouillées, avec des recouvrements entre ERP, solutions métier et solutions transverses
- de nouveaux types de solutions sont apparus dans les domaines de l’infrastructure de données, de l’intégration applicative, de l’orchestration des processus, et de la collaboration
- l’open source d’abord présent dans les logiciels d’infrastructure et les applications de service transverses, puis sur le e commerce, investit maintenant le monde du logiciel applicatif.
- le SAAS (Software As A Service) étend en permanence son périmètre fonctionnel.
Le principe de cette nouvelle démarche est de partir des processus métier de l’operating model de l’entreprise pour en déduire les besoins fonctionnels qui confrontés aux solutions logiciel possibles, internes ou externes, permettront de construire l’architecture applicative.
Innovation et efficacité opérationnelles pour définir les processus métier, et identification des spécificités métier discriminantes
La recherche de processus métier apportant des avantages compétitifs réels et durables est essentielle et se fait au travers de:
- l’innovation qui permet de trouver les meilleures solutions en termes de création de valeur pour les clients et l’entreprise,
- la productivité et l’efficacité qui visent à délivrer cette valeur avec la meilleure économie de moyens.
Partant de ces processus revisités et réinventés, il faut identifier les spécificités discriminantes par rapport aux pratiques usuelles du secteur : elles peuvent concerner un mode opératoire, le modèle de données, certaines règles métier, des données partagées, l’ergonomie ou des critères de performance.
Les erreurs à éviter
- passer trop de temps à décrire les processus sur des points usuels,
- ne pas assez se poser la question de l’alignement des processus sur la stratégie de l’entreprise.
- passer à coté de points discriminants par manque d’approfondissement des points métier sensibles.
- ne pas suffisamment impliquer les experts métier dans la réflexion sur les processus.
L’architecture fonctionnelle : identifier les besoins réellement nécessaires, au bon niveau de détail
Comment identifier les besoins réellement nécessaires ?
La méthode consiste à identifier les besoins fonctionnels par processus. Puis un travail transverse de factorisation des besoins analogues et de regroupement des besoins en blocs fonctionnels homogènes permet d’aboutir à l’architecture fonctionnelle du futur système d’information.
Quatre points sont particulièrement importants dans ce processus :
- La maîtrise de la diversité utile, diversité au niveau des processus, mais aussi au niveau des fonctionnalités
- La « scalabilité » des fonctionnalités pour tenir compte de la taille et du niveau de complexité des organisations.
- La flexibilité des applications, en premier lieu par rapport à l’organisation de l’entreprise, mais aussi au « make or buy », au caractère optionnel ou obligatoire des contrôles, aux évolutions de processus, …
- L’évolutivité du système d’information pour répondre aux évolutions des processus et des méthodes de gestion. L’évolutivité se construit dès le début dans l’architecture logicielle du système d’information en incluant des composants spécifiques (BRMS, EAI, MDM, ESB, BPM).
Quel est le bon niveau de détail pour décrire les besoins ?
C’est celui qui permet de : • décrire les applications existantes sans ambigüité fonctionnelle, • discriminer les besoins fonctionnels cible • construire la solution applicative cible en décrivant le LEGO applicatif, • décrire suffisamment précisément la roadmap de déploiement (faisabilité, coût) • d’estimer le budget de construction et de déploiement du système de manière analytique. Pour la Grande Distribution, une architecture fonctionnelle de référence comporte environ 25 processus et 150 fonctions.
Les erreurs à éviter
- en rester à une liste à la Prévert des besoins, sans priorité, sans factorisation, ni élimination de la diversité inutile.
- ne pas remettre en question les modèles fonctionnels des applications existantes, améliorer à la marge,
- ne pas traiter sérieusement la question de l’évolutivité du système,
- ne pas investiguer les questions de scalabilité et de maturité du besoin,
- travailler avec une architecture fonctionnelle trop globale
Construire l’architecture applicative comme un investissement industriel
L’architecture applicative doit conjuguer innovation et approche industrielle. L’architecture applicative doit être vue comme un investissement industriel mais en même temps permettre l’innovation qui apporte de la valeur aux clients et à l’entreprise. Pour cela il faut analyser plusieurs scénarios, même non conventionnels avec les critères simples que sont l’adéquation aux besoins, le coût de possession, le délai de mise en œuvre, le risque, et la durabilité de la solution.
Comment identifier ces scénarios ?
L’appréciation objective de la qualité et de la pérennité des applications existantes est essentielle. Dans de nombreuses entreprises une partie du patrimoine applicatif rend le service attendu et son redéveloppement n’aurait aucun business case. La comparaison de plusieurs types de solutions est souvent utile, mais toujours indispensable : ERP, logiciel métier, open source, SAAS, développement spécifique, amélioration d’une application existante.
Selon quels critères analyser l’existant ?
Evaluation Business par rapport aux processus métier cible
- Capacité à supporter les processus métier cible,
- Fonctionnalités manquantes ou insuffisantes, ou incohérences. Evaluation fonctionnelle par rapport aux besoins actuels
- Problèmes de fonctionnement (adéquation aux besoins, dysfonctionnements, efficacité pour l’utilisateur, problèmes de performance),
- Carences fonctionnelles (besoins insuffisamment ou non couverts, ergonomie pauvre ou inadaptée, données manquantes, contrôles et niveau d’automatisation insuffisants).
Évaluation technique
- Obsolescence technique,
- Limitations techniques structurelles,
- Capacité à respecter les SLAs cibles,
- Risque de non maintien en conditions opérationnelles.
Évaluation économique
- Coût d’exploitation annuel,
- Coût de maintenance corrective et petite maintenance évolutive annuelle,
- Coût des maintenances évolutives et petits projets programmés ou envisagés,
- Coût de mise à niveau technique nécessaire,
- Capacité à évoluer? À quel coût?,
- Coût de déploiement.
Évaluation de l’appropriation utilisateur
- Maîtrise de l’application,
- Niveau de satisfaction
Interfaces avec les autres applications
- Capacité d’intégration applicative,
- Interfaces manquantes, déficientes ou insuffisantes,
- Performances techniques de l’interface.
Compétences disponibles sur l’application
- Compétences & Effectifs internes et externes,
- Risques de départ,
- Documentation disponible.
Evaluation du risque
Le benchmark des solutions possibles
Les modèles d’architecture applicative se sont de plus en plus diversifiés et sophistiqués ces dernières années. Il est de plus en plus difficile de se tenir informé des nouveautés, mais plus encore de savoir ce qu’elles valent réellement. Le recours au benchmark est une nécessité.
Comment construire l’architecture applicative cible
Construire une architecture applicative c’est aboutir au bon LEGO entre les applications existantes que l’on a décidé de conserver et les nouvelles applications. C’est un exercice complexe au sens ou les choix possibles sont multiples et les critères de choix également. Examinons ceux deux aspects.
Les choix possibles sont multiples
Pour répondre à un même besoin fonctionnel, il existe aujourd’hui des solutions très différentes avec leurs avantages et leurs inconvénients respectifs.
- L’ERP
- Les logiciels métier
- Le développement spécifique
- Les solutions d’infrastructures de données, d’intégration applicative, de communication et de gestion de processus.
- L’open source
- Enfin le SAAS (Software as a Service).
Ces solutions se différencient d’abord sur les critères traditionnels, le fameux QCD (Qualité, Coût, Délais).
Comment choisir le meilleur lego applicatif ?
Quatre critères sont particulièrement importants pour retenir le meilleur scénario applicatif :
- Le partage des données consiste à se poser deux questions. Qui est maître sur quelles données ? Quelles solutions technologiques et d’intégration doivent être utilisées pour gérer les référentiels de données maîtres ?
- La configurabilité permet de mettre en œuvre les processus métier souhaités en orchestrant correctement l’appel aux applications et en s’affranchissant de l’architecture des traitements applicatifs actuels.Les solutions de portail, de BPM et de BAM permettent de la mettre en œuvre.
- L’intégration applicative permet d’éviter les ruptures de charge dans les traitements avec des intégrations en temps réel ou en temps différé. Les offres de logiciels d’EAI et d’ESB proposent des produits avec une large palette de fonctionnalité et de niveaux de prix. C’est une alternative à la duplication des données.
- La capacité d’évolution du SI sans développements informatiques. Les règles de gestion de l’entreprise évoluent de plus en plus, et de plus en plus vite ; la programmation classique ou le paramétrage atteignent leurs limites. Les moteurs de règles, la outils de programmation par contrainte, les logiciels d’orchestration de processus, une fois intégrés dans l’architecture logicielle du système d’information, permettent d’opérer des mises à jour plus rapidement et à moindre coût.
Les erreurs à éviter
- se soumettre au conformisme intellectuel, ne pas questionner les évidences,
- ne pas évaluer correctement les solutions possibles au regard de tous les critères pertinents,
- décider de remplacer les applications existantes sans réelle évaluation de leur potentiel,
- choisir une solution sans la valider par un benchmark ou des visites de référence.
Estimer les coûts et planifier
Pour construire la roadmap, il faut que les Directions Métier donnent leurs priorités. Ensuite les spécialistes du système d’information construiront les états techniques intermédiaires (interfaces temporaires, modèles de données hybrides ancien / nouveau système, reprise des données), et évalueront leur faisabilité technique et leur coût.
Le chiffrage, chacun le sait, est un sujet très sensible. Un directeur informatique me disait un jour « je prends le budget que me donnent mes équipes, et je le multiplie par 3 ». Pour éviter d’en arriver là, la bonne méthode consiste à faire un chiffrage analytique sous-tendu par des hypothèses précises.
Les bonnes pratiques
- faire un chiffrage analytique assez détaillé afin de ne pas passer à coté de points importants,
- demander à plusieurs personnes ou équipes de travailler en parallèle et confronter les résultats obtenus,
- demander des avis d’experts à des consultants, des éditeurs, des intégrateurs,
- obtenir des benchmarks ou des visites de référence auprès d’entreprises ayant réalisé des projets similaires.
Cet article a été écrit par Jean-Claude Bernardon, Fondateur et Business Consulting Managing Director d’Edifixio.