Architecture « 2015 – Processus ou Données ? »

DATE DE CREATION : 05/02/2005

Architecture SI « 2015 – Processus ou Données ? »

Les éditeurs de logiciels s’adaptent en permanence au marché du traitement de l’information en améliorant leur offre de base à partir de l’expérience issue de l’utilisation des outils par le client final.

Conséquence de ceci, une offre marketing toujours nouvelle qui prône de nouveaux concepts au sein de nouveaux produits qui son censés réglés tous les problèmes des clients et améliorer leur performance.

Beaucoup de clients décident la mise en place de ces produits sans avoir une vision réelle et globale de leur SI et sans anticiper les impacts négatifs que l’intégration de la nouvelle offre va avoir sur la cohérence globale du SI en terme de surcoût de fonctionnement.

Partir d’une feuille blanche et mettre en place les progiciels leader du marché sur les périmètres fonctionnels ERP/ PLM / SCM / CRM en veillant à une bonne intégration donnerait sans doute un bon résultat en terme de gestion de l’information. Encore faudrait-il avoir les ressources compétentes pour comprendre et intégrer l’ensemble des fonctions du SI, pour réussir la conduite du changement auprès des métiers qui exécutent les processus. Les budgets et le temps de mise en place de ces outils demanderaient un effort irréaliste en terme de management. En pratique, une entreprise ne part jamais d’une feuille blanche et elle a toujours à gérer un existant en terme d’infrastructure matérielle, de système d’exploitation, d’applications informatiques qui gèrent des données relatant la vie de l’entreprise (différentes codifications, spécificités, …) et surtout une organisation qui réalisent des tâches formalisées ou non en terme de processus.

L’introduction montre que le discours commercial des éditeurs est plus positionné sur une vision monopolistique de la couverture du SI au sein d’une entreprise plutôt que sur une réelle prise en compte des besoins clients. Bien sûr, certains vont mettre en avant l’évolutivité de leur produits qui s’adaptent à moindre coût au contexte de l’entreprise et l’intégration facile aux applications connexes mais qui en réalité vont devenir une source de bénéfice durable (licences, évolutions, …) pour eux.

Dans ce contexte mouvant dans lequel les éditeurs d’outils et de méthodes innovent et créent les concepts présents et futur (BPM, UML, WF, modélisation de processus, …) les éditeurs de solutions fonctionnelles répondant aux besoin métiers (hors informatique) vont essayer de tirer profit ce ces concepts pour les intégrer dans leurs discours commerciaux.

Un exemple concret : aujourd’hui, SAP prédit que le futur gagnant, c’est la réutilisation des processus au niveau applicatif en utilisant la plateforme « Netweaver ». D’autres éditeurs comme ORACLE restent fidèles à leur stratégie initiale et positionnent leur offre future sur la maîtrise des données dans leur SGBD.

Le débat est ouvert « Processus ou Données en 2015 ? ». Pour tenter de répondre à la question il est important de donner une vision conceptuelle et logique du SI au niveau « Processus / Fonctionnel / Applicatif / Technique » autour des fonctions et des informations à mettre en place.

Un peu d’histoire pour repositionner et décrire le SI de l’entreprise par rapport au Business et à l’organisation le supportant. « Le temps » est un paramètre essentiel qui a le plus influé les processus et l’organisation pour produire et vendre les produits et services.

Il y a 15 ans, les étapes de la conception (au sens large) d’un produit ou d’un service se déroulaient successivement. Etude de marché, définition du produit, style, études techniques, méthodes, … Conséquence directe, les processus et les organisations mis en place pour supporter l’activité étaient relativement simples d’un point de vue de l’interaction entre acteurs. Un service réalisait une tâche donnée, livrait sa production (physique ou informationnelle) au service connexe qui faisait de même.

Du point de vue SI, les tâches qui étaient réalisées étaient de granularité fine (processus opérationnels) et les applications mises en place pour automatiser ces tâches opérationnelles de groupe d’acteurs relativement dédiées à un métier avec peu d’interface, les hommes réalisant ces interfaces dans le cadre de réunions de travail. La diversité des métiers et la diversité technologique toujours croissante ont conduit à avoir un parc applicatif important en nombre et très hétérogène en terme de techniques, de méthodes de développement et d’exploitation (notamment avec l’arrivée du client/serveur puis de internet).

Quelques années plus tard, tout s’accélère, les marchés commencent à s’ouvrir sur l’extérieur, les entreprises commencent à sous-traiter des parties de leur ingénierie ou de leur production, le cycle de vie des produits et des services et leurs développements est fortement raccourci. L’adaptation à ces changements Business se traduit par des changements d’organisation. Parallélisation des activités Etude/Méthode, travail conjoint avec des fournisseurs, partenariat avec d’autres entreprises pour partager les coûts, …

Le parc applicatif composé d’applications autonomes et spécifiques aux métiers, va s’adapter en multipliant les flux d’informations entre applications et en augmentant le nombre de ces dernières du fait des nouveaux besoins issus des nouvelles structures matricielles mises en place (projet, filières métiers, groupes fonctionnels, …)

Conséquence de ces changements, un parc applicatif important, des flux entre applications très nombreux (d’application à application), des applications non connectées et intervenant dans les processus informationnels, des technologies supportant ce parc applicatif très hétérogènes. L’arrivée du eBusiness et des concepts qu’il va porter va encore accroître cette course folle à l’armement applicatif puisque chaque métier va demander une application « Web », clone de l’application métier pour que les partenaires et fournisseurs accèdent à l’information.

Sérialisation des activités, parallélisation des processus, partage des activités avec les fournisseurs sont des périodes qui vont être suivies par une ouverture des entreprises sur le monde, ce qui va engendrer une multiplication des sous projets à mener pour partager et déployer les activités partout dans le monde:

-         activités d’ingénierie (produit, processus de fabrication, logistique, après-vente),

-         activités d’exécution (logistique, fabrication, réparation),

-         activités de pilotage QCD (Management et reporting),

-         activités de support pour accompagner ces sujets (Rh, douanes, …)

Pour franchir ce nouveau pas et s’adapter à ces nouvelles contraintes Business, l’entreprise va créer de nouveaux concepts pour être capable de répondre aux contraintes plus nombreuses issues de zones géographiques multiples et avec des cycles de temps de réalisation raccourcis.

Le développement et l’intégration des multiples composants d’un produit devenant trop complexes à gérer avec ces contraintes, l’approche fonctionnelle puis systémique va être adoptée. La première consiste à décomposer l’objet à produire en sous parties ayant des liens fonctionnels entre elles (exemple pour un PC : alimentation, stockage, E/S, …). Cette décomposition nécessaire mais pas suffisante va être suivie rapidement de l’approche « système » qui en plus de traiter les sous ensembles fonctionnels (le Quoi), va faire en sorte que ces derniers soient autonomes en terme de comportement (fonctionnement propre et développement du sous ensemble). Cette approche va permettre aux entreprises d’être plus souples pour animer la co-ingénierie des produits, la multiplication des partenaires et des fournisseurs, les déploiements des systèmes. Par contre, la maîtrise des flux informationnels entre sous ensembles ou physiques au niveau de la logistique et de la fabrication, va accroître la complexité globale du SI.

D’un point de vue Business, un dernier point apparaît dans l’équation du problème à résoudre « 2015 – processus ou données ? », c’est l’aspect réglementaire qui existe déjà mais qui va croître en nombre et en vitesse d’apparition, se traduisant en terme de contraintes à respecter pour l’entreprise. Les règlements douaniers, environnementaux, liés à la sécurité, … de chaque pays co-fabricant ou consommateur devront être respectés sous peine de ne pas être prêt au bon moment et donc de perdre le marché suite à un non respect législatif.

Ayant abordé les aspects Business qui existaient dans la problématique posée, quelles sont les conséquences présentes et futures sur le SI de l’entreprise ?

Temps, nombre de produits, nombre de déploiement industriels et commerciaux, partenariats, fournisseurs multiples, réglementation sont des contraintes qui se traduisent au niveau SI par :

-         un fonctionnel toujours plus riche et complexe,

-         des flux informationnels toujours plus nombreux,

-         des niveaux de granularité entre objets obligatoires pour gérer la complexité et les différents besoins des métiers,

-         une vitesse de déploiement efficace dans la mise en œuvre des applications informatiques.

«Maîtriser les processus » ou « Maîtriser les données » ?

Quelles sont les actions à mettre en œuvre pour maîtriser toute la complexité abordée précédemment et pour avoir un SI qui permette de supporter cette complexité Business en s’adaptant à moindre coût ?

D’un point de vue processus, beaucoup d’entreprises commencent à formaliser leurs activités pour mieux les répéter et pour accroître la qualité de leurs productions intellectuelles, informationnelles, physiques. Un point important à prendre en compte pour bien exploiter ces travaux de capitalisation relativement coûteux en énergie, c’est la mise en place de différents niveaux de granularité de processus qui permettront leur intégration et exploitation finale. En effet, comme mentionné précédemment, les métiers qui commencent à modéliser leurs processus ont tendance à décrire les tâches opérationnelles qu’ils réalisent et le nombre de processus produits devient vite inexploitable si ces derniers ne sont pas découpés et organisés en différentes couches. Couche stratégique pour décision de management d’entreprise, couche fonctionnelle pour exploiter les grands flux d’informations inter métier, couche organisationnelle pour le pilotage des objectifs d’une direction et enfin couche opérationnelle pour maîtriser les livrables des acteurs qui contribuent au fonctionnement de l’organisation. Si ces découpages sont faits et reliés, l’ensemble des décisions prises aux différents niveaux pourront exploiter l’information issue de la description des processus réalisée et inversement toute décision aura un impact ciblé rapidement sur les activités concernées.

D’un point de vue fonctionnel, la complexité Business a engendré une complexité des fonctions et des flux inter fonctions supportés dans les applications informatiques. Ces fonctions souvent appelées fonctionnalités parce que leur mise en place répond à une demande opérationnelle de niveau tâche, sont très mal maîtrisées en terme de recouvrement et/ou des nombreux flux reliés aux fonctions connexes.

De façon similaire à la décomposition des processus en différents niveaux, il va falloir organiser les fonctions traitant l’information à la fois en terme de granularité de découpage et en terme de relations avec des fonctions connexes. Il faudra également organiser les données en fonction de leur granularité (entreprise, métier, spécifique) et en relation avec les données proches fonctionnellement. Cette vision macroscopique des fonctions et des données reliée aux fonctionnalités de bas niveaux est indispensable pour savoir définir et décrire une vision stratégique du SI alignée sur les décisions stratégiques Business.

D’un point de vue applicatif, le même problème est à régler : « réduire la complexité du parc applicatif » en le rendant plus modulaire pour minimiser les liens, pour faciliter les évolutions à moindre coût. Organiser les traitements et les données dans des ensembles fonctionnels cohérents, c’est le moyen de supporter des processus métiers dans des applications informatiques optimisées. Pour réussir ce découpage modulaire, il faudra savoir dissocier les données et les fonctions qui sont stables et peu évolutives dans le temps (données référentielles et transversales métier) des données et fonctions spécifiques utilisées dans les processus métiers opérationnels décrits précédemment.

Une fois ce découpage réalisé, l’implémentation des fonctions et des données sera organisée autour des référentiels d’entreprise sur lesquels viendront se brancher l’ensemble des logiques applicatives et de présentations correspondant aux processus métiers. Avantage immédiat, un nouveau besoin business n’entraîne plus le développement complet d’une application incluant données, traitements, logique applicative, IHM ainsi que des liens avec les applications connexes mais seulement le développement correspondant à l’automatisation du processus dans la partie Front office de l’architecture applicative tout juste décrite.

D’un point de vue technologique, il est important de faire des choix de solutions qui supportent les standards du marché en terme de système d’exploitation, de système de gestion de base de données, de bus applicatif et d’intégration. Si des progiciels sont intégrés au SI d’entreprise, ils devront bien sûr être compatibles au standard mais surtout précisément positionnés sur des périmètres fonctionnels cohérents avec des interfaces bien identifiées. Pour la mise en place de composants réutilisables, 2 règles essentielles seront à respecter, la première consistera à implémenter des services transactionnels encapsulant des fonctions de bas niveau de type gestion de données et de leurs caractéristiques en garantissant l’unicité d’accès, la seconde offrira des services fonctionnels de type applicatif utilisables par de nombreux métiers et développés sous forme de services réutilisables éventuellement externalisés de la logique applicative. Il faudra éviter de tomber dans le piège des solutions techniques de type GED, portail propriétaire, couplage de notions fonctionnelles encapsulées dans un applicatif fermé qui ne feraient qu’accroître la complexité du SI.

Conclusion

L’entreprise qui saura maîtriser les différentes composantes du Business en terme de processus, d’organisation fonctionnelle, de briques applicatives et de solutions technologiques sera capable de gérer l’information indispensable pour être compétitive sur son marché. Cependant les concepts mis en place ne suffiront pas si l’intégration entre les concepts n’est pas maîtrisée, c'est-à-dire les liens entre les couches processus, fonctionnelles, applicatives et technologiques. La cartographie est un outil indispensable pour gérer la complexité des objets manipulés sur ces différentes couches d’architecture car elle permet de capitaliser l’information complexe et nombreuse mais aussi de détecter les changements d’objets à effectuer suite à une modification ou à une décision prise sur l’un d’eux. Sa mise à jour par tous les métiers sera une garantie de succès pour l’exploitation future.

Alors : Le futur « 2015 – Processus ou Données ? »

-         Données pour structurer l’organisation fonctionnelle du SI (fonctions / informations transverses) accessibles par des services applicatifs de 2 types, des traitements transactionnels réutilisables, des services contenant un fonctionnel commun à plusieurs métiers,

-         Processus de haut niveau pour décrire les flux d’informations entre grandes fonctions (organisation du découpage fonctionnel) et pour faciliter l’alignement du SI sur le Business, processus détaillés pour décrire la logique applicative à encapsuler dans les applications ou à externaliser de celles-ci lors de l’existence de services mutualisables,

Et surtout une structure organisationnelle interne capable d’intégrer tous ces concepts dans le SI opérationnel en maîtrisant les couches fonctionnelles, techniques ainsi que les concepts stratégiques et opérationnels.

La conduite du changement, le pilotage et le développement opérationnel  de ces concepts au sein des entreprises est la chose la plus compliquée à mettre en place notamment d’un point de vue responsabilité et pilotage QCD des projets habituellement sectorisés côtés métiers et informatiques.

© Thierry BEL