BPMS.info : Comment avez-vous traversé 2009 et quelles sont vos perspectives de croissance en 2010 ?
A.W. : Grâce à une excellente gestion interne et une planification minutieuse de nos actions, le chiffre d’affaires et les bénéfices de Casewise ont continué de grimper en 2009.
Casewise est une société pérenne et profitable. En effet, en 2009 l’entreprise a réalisé une croissance organique de plus de 15%. Nous annonçons également une croissance de 27% sur les zones EMEA et APAC au premier trimestre 2010 (par rapport au Q1 2009).
|
En France, nous enregistrons une croissance record de plus de 76% sur le premier trimestre, cela nous permet d’entrevoir une année 2010 prometteuse !
En ce qui concerne la zone EMEA & APAC, compte tenu de la forte demande, nous étudions des plans d’expansion en Europe Centrale et Europe de l’Est afin de répondre aux besoins des organisations sur ces marchés. Avec une présence sur le marché Belge et un marché à fort potentiel en Allemagne, ces deux pays sont des régions géographiques où Casewise s’est implanté en début d’année. En France, notre objectif est d’acquérir plus de 100 nouveaux clients par an ainsi que de développer notre base de clients existants. Nous sommes convaincus que cette stratégie peut être appliquée à la fois en Belgique et en Allemagne. Nous voulons être géographiquement proches de nos clients afin de répondre à leurs attentes et besoins.
De plus, l’Europe de l’Est offre de nombreuses opportunités. Nous avons constaté au cours des 18 derniers mois une augmentation des demandes de renseignements émanant d’organisations en Europe pour des solutions de modélisation, en particulier l’Ukraine, la Pologne, la République Tchèque et la Slovaquie. La Russie offre entre autre de grandes opportunités et nous avons d’ores et déjà développé une relation de partenariat avec une société de développement de logiciels.
Casewise s’engage également à développer la croissance de son vaste réseau mondial de partenaires revendeurs. Grâce à ce programme, nous avons étendu notre présence dans plus de 20 pays à travers le monde en 2009. Associées à une connaissance approfondie des produits et des solutions Casewise, ces organisations nous accompagneront en 2010 sur les marchés locaux.
Nous avons de grands projets pour Casewise dans les 12-24 prochains mois. Grâce à une expansion en Europe et à l’ouverture de nouveaux bureaux, Casewise associe avec ses partenaires européens son expérience et ses solutions innovantes avec leur passion et leur connaissance du marché afin d’offrir la meilleure solution aux organisations.
La vision globale de Casewise met l’accent sur une approche holistique composée de cinq éléments : – Renforcer notre relation client – Développer des solutions innovantes – Développer de nouveaux marchés – Elargir notre couverture géographique – Former de nouveaux partenariats et alliances stratégiques
BPMS.info : Comment définiriez-vous la stratégie de votre société ?
A.W. : Nous souhaitons nous pencher sur le Top 10 des priorités des organisations en 2010 : 1. Assister les entreprises dans leurs initiatives d’amélioration de processus métiers 2. Réduire les coûts dans les entreprises 3. Augmenter l’utilisation des informations et des analyses 4. Améliorer l’efficacité opérationnelle des entreprises 5. Attirer et fidéliser des clients 6. Gérer les initiatives de changement 7. Créer de nouveaux produits et services (innovation) 8. Cibler des marchés et clients plus efficacement 9. Consolider les actions commerciales 10. Améliorer les relations avec la clientèle actuelle
BPMS.info : Casewise vient de sortir la nouvelle version de son outil de modélisation Corporate Modeler. Quelles améliorations ont été apportées ? Sur quoi avez-vous porté un accent particulier ?
A.W. : Ayant pris en compte les besoins et les exigences des utilisateurs de notre logiciel de modélisation Corporate Modeler et évaluer les tendances sur les marchés du BPA, EA et BPM, la sortie de Corporate Modeler 2009.2 représente une avancée majeure dans le développement de notre technologie.
Pour répondre aux attentes de notre clientèle internationale, cette dernière version est disponible en huit langues : Anglais, Français, Allemand, Espagnol, Italien, Polonais, Japonais et Russe. De nouvelles fonctions et améliorations étendent les capacités du logiciel ; un accent particulier a été porté sur une navigation plus intuitive grâce à une explosion contextualisée des diagrammes, une meilleure ergonomie réduisant l’effort de modélisation et un arbre d’exploration facilitant la navigation.
BPMS.info : Quelles vont être les nouveautés du point de vue offre cette année ?
A.W. : Casewise travaille sur une application mobile permettant d’accéder au référentiel à distance sur son smartphone (iPhone, iPad par exemple). Nous travaillons aussi sur une offre de private cloud computing. Les outils de Casewise seront accessibles à distance sur un serveur dédié et sécurisé. Cette solution est plus sécurisée que les solutions habituelles de cloud computing puisque le serveur n’est pas partagé avec d’autres entreprises. Nous prévoyons en outre une nouvelle montée de version majeure de Corporate Modeler en 2011.
BPMS.info : Quel regard portez-vous sur le niveau de maturité des entreprises par rapport au Business Process Management en Europe ? Quelles particularités présente le marché français ?
A.W. : Ces dernières années, nous avons constaté de nombreuses fusions entre des acteurs du BPA, de l’EA et du BPM. Tous ces nouveaux groupes prétendent offrir une solution étendue, de la modélisation à l’exécution, mais en réalité il y a beaucoup de brick and mortar. Tous ces fournisseurs offrent principalement des technologies.
Casewise fournit bien plus qu’un produit, nous proposons des solutions complètes composées d’un outil, de contenus (ITIL, eTOM, Togaf,…) et d’un accompagnement projet. L’objectif de Casewise est d’offrir des solutions verticales aux entreprises afin de répondre au plus près à leurs attentes et spécificités. « Vous souhaitez mettre en place un nouveau call center, Casewise vous accompagne de la définition de votre besoin à la mise en œuvre de votre projet tout en vous accompagnant avec un conseil de qualité, des solutions complètes et des Meilleures Pratiques ».
Aujourd’hui, Casewise est l’unique éditeur de logiciel à fournir une solution « intégrée » allant de la conception EVP (Excel, Visio, Power Point) à l’exécution des processus d’entreprise.
La solution Casewise permet de : • Réduire la complexité de vos projets o Approche adaptée au contexte de l’organisation o Utiliser des frameworks spécifiques à l’entreprise o Développer des outils adaptés aux différents acteurs d’un projet • Travailler en collaboration o Disposer d’un Référentiel Central afin de créer un langage commun o Des outils logiciels conçus pour le travail en équipe o Une méthodologie de travail • Créer un avantage concurentiel o Nous accompagnons nos clients tout au long de leur projet (transfert de compétences) afin de rendre mature la capitalisation de leur savoir (Cf. Courbe de maturité du Gartner).
En ce qui concerne le marché français, nos clients exigent des résultats visibles et un succès rapide. De plus en plus, ils souhaitent que leur Référentiel de BPA/BPM devienne leur Référentiel d’Entreprise, ce qui signifie qu’ils désirent une intégration avec les outils tiers. C’est pourquoi Casewise lancera en 2010 une nouvelle solution appelée "Casewise Integration Pack".
Grâce à cette technologie, Casewise donne une nouvelle dimension au Référentiel CMDB, à la gestion du patrimoine IT, à la gestion des risques, etc. en fournissant une capacité de reporting et de dimension graphique.
Une autre exigence de nos clients est la notion de « collaboration ». Casewise met un accent particulier sur cette dimension fondamentale dans les projets de BPA, d’EA et de BPM. Aujourd’hui Casewise fournit des solutions sans cesse plus innovantes : solutions full web, PDA compatible, interface conviviale, etc. permettant aux entreprises de travailler sur des projets en collaboration.
BPMS.info : En septembre dernier vous avez été nommé à la tête de la direction monde (except US) de Casewise. La crise économique a-t-elle eu un impact sur les activités opérationnelles de ces zones commerciales ? Quelle est la stratégie du développement de Casewise sur de nouveaux marchés ?
A.W. : La crise économique a eu un impact sur ces zones commerciales, il serait insensé de dire le contraire.
Notre objectif 2010 est de réaliser plus de 70% du chiffre d’affaires de Casewise sur l’EMEA et l’APAC.
En France, notre but est de développer le secteur public, de la finance, des services, des média et de la communication, et enfin de la santé, de la distribution et des télécommunications afin d’acquérir de nombreuses nouvelles références sur ces secteurs. Nous sommes convaincus que cette stratégie « verticale » fera également le succès de notre présence en Belgique et en Allemagne.
BPMS.info : Depuis quelques années sont nombreuses les annonces de rachat ou de rapprochement entre les acteurs de l’analyse de processus (BPA) et acteurs de l’automatisation (BPM). Comment expliquez-vous cette tendance ?
A.W. : Ce n’est que le début des rapprochements entre les acteurs du BPA et du BPM. Lors d’une récente conférence, un analyste a annoncé que dans les trois prochaines années, nous verrons des fusions entre les acteurs du BPA, de l’EA et du BPM.
De nombreuses organisations ont des besoins et exigences non pas seulement de cartographie des processus mais aussi d’exécution de ces processus en workflow, d’où cette tendance de fusions/ acquisitions entre les acteurs de ces marchés.
Interview réalisée par BPMS.info |
Entretien avec Yannick Jouannin, Président Directeur Général du cabinet Nomia
Cette année Nomia fête ses 18 ans d’existence. L’âge de majorité pour une entreprise. Par quels résultats se sont traduites ces 18 années ? Que représente la société aujourd’hui ?
– Nomia est aujourd’hui un acteur reconnu dans le conseil en management du changement avec une offre qui s’articule autour de 3 grands axes :
– Le conseil en management des changements dans les organisations avec une expertise en modélisation des processus (BPM/ BPA) et en optimisation de leur performance (Lean Six Sigma pour les Services)
– Le conseil en cartographie et urbanisation du SI
– Le conseil en accompagnement du changement avec un produit dédié dont nous sommes l’éditeur : « OnMap l’entreprise visuelle »
Ce savoir-faire et notre longue expérience nous valent aujourd’hui la confiance d’un investisseur, Avenir Entreprises, une filiale de la Caisse des Dépôts et Consignations. Il nous accompagne depuis fin 2008.
Depuis quelques années l’industrie du logiciel et des services connaît la crise. En 2009 de nombreux éditeurs et cabinets de conseils ont montré des chiffres d’affaires inférieurs à ceux de 2008. Comment Nomia gère-t-elle la crise ?
– En dépit de cette crise sans précédent, nous avons maintenu notre chiffre d’affaires entre les deux années. Bien que notre marge ait diminué, elle demeure positive.
Nomia édite la solution OnMap. Quel est son positionnement ? Quels sont les gains apportés par ce type de solution ?
– Par notre activité de conseil, nous avons constaté le manque de solutions packagées disponibles sur le marché pour aider les opérationnels à s’approprier efficacement les changements lors de projets de transformation. Il fallait soit développer des contenus de communication et de formation sur mesure, coûteux et difficilement maintenables, soit se contenter de supports power point avec leurs inconvénients. Nous avons donc développé OnMap, fruit de plus de 10 ans de savoir-faire et d’expérience acquise.
OnMap est une solution industrielle qui permet aux entreprises d’être autonomes dans la création de leurs dispositifs pédagogiques. Surtout, elle repose sur le concept innovant d’entreprise visuelle. Il part du constat souvent partagé que les collaborateurs connaissent mal leur propre entreprise. Ils n’en n’ont pas une vision claire. Cette méconnaissance augmente la résistance au changement. OnMap permet de déployer en ligne des représentations visuelles et animées de l’entreprise ou de l’un de ses services. Plusieurs dispositifs multimédias exploitant cette entreprise visuelle peuvent être mis à disposition des collaborateurs, selon les besoins : des visites interactives pour s’approprier l’organisation et son fonctionnement ; des parcours de formation (présentiel et elearning), par profil métier ; des bureaux métiers virtuels pour consulter les documents à jour nécessaires à la réalisation de leurs activités.
Les solutions OnMap contribuent à améliorer la performance des organisations en valorisant le capital humain : elles facilitent et accélèrent la mise en œuvre des projets ; elles favorisent l’acquisition de compétences et l’appropriation du poste de travail.
Vous dites qu’OnMap est capable de récupérer les processus décrits dans les outils BPA/BPM ? Que se passe-t-il quand le référentiel BPA connaît des modifications ? Nomia sait-il se synchroniser au référentiel ?
– Absolument. OnMap se synchronise avec les référentiels d’Aris (IDS Scheer), de MEGA et de Corporate Modeler (Casewise). Les mises à jour sont automatiquement répercutées dans la base OnMap.
Au début de cette année vous avez lancé une nouvelle offre OnMap, l’hôpital visuel. Quelles sont ses grandes caractéristiques ?
– Il s’agit de la solution OnMap, complétée de cartographies et d’animations permettant de disposer en standard d’un « hôpital visuel » avec 15 services et 11 processus parmi les plus importants (circuit de la biologie, circuit du médicament, gestion de l’imagerie, admission, urgences, chirurgie, chirurgie ambulatoire, ….). La solution permet bien entendu de personnaliser et d’enrichir cet hôpital visuel au contexte de chaque établissement.
Souvent dans les projets de transformation de système d’information, la conduite du changement se réduit au seul axe « outils ». La formation aux nouveaux outils suffit-elle pour faire adhérer aux changements ?
– A notre sens, non. Le collaborateur doit pouvoir établir des liens logiques entre la finalité du projet et les actions qui vont lui être demandées. En amont d’une formation aux outils, il faut qu’il sache pourquoi certaines tâches et procédures vont lui être demandées. Il doit pouvoir mesurer sa contribution dans l’effort collectif. C’est ce que nous appelons la phase « d’implication ».
Il y a une autre phase souvent négligée dans les projets : celle de l’accompagnement post-déploiement qui doit donner aux collaborateurs les moyens d’être complètement et durablement opérationnels à leur poste de travail. A l’issue des sessions de formation, tous ne se sentiront pas immédiatement à l’aise avec les nouvelles procédures ou les nouveaux outils mis à disposition. Il faut proposer les dispositifs adéquats. Pour y répondre avec OnMap, nous proposons le concept de bureau métier.
Quelles nouveautés du point de vue offre préparez-vous ?
– Nous nous apprêtons à sortir une offre en SaaS d’ici le 1er trimestre 2011.
Plusieurs études constatent que l’intérêt pour le management pour les processus s’est véritablement accéléré ces dernières années. Quels sont les principaux moteurs de cette industrie ?
– Les grands éditeurs tels que SAP ou Oracle, en s’y ralliant, ont largement contribué à son essor, de même que les éditeurs de solution SOA et Workflow. A cela s’ajoute le constat fait par les entreprises que le processus est la brique essentielle entre l’organisation et le S.I. C’est lui qui matérialise le fonctionnement de l’entreprise, et c’est là que se joue sa performance. Enfin, j’ajouterai la poursuite de la montée en puissance de l’informatisation qui rend obsolète – en particulier avec les logiciels intégrés – l’organisation en silo de l’entreprise.
Quel est le niveau de maturité des entreprises en France en matière de management par les processus ?
– Il reste sans doute encore bien faible. Le BPM se réduit souvent à une finalité qui est de modéliser les processus et d’en informatiser un certain nombre, au travers notamment de projets workflow. On reste bien loin de l’enjeu essentiel qui est de manager l’entreprise avec les processus, avec le décloisonnement des métiers à la clé. In fine, ce qui doit être visé, c’est l’amélioration de la qualité des services ou des produits délivrés aux clients ou usagers et bien entendu une amélioration de la valeur générée pour l’entreprise ou l’organisme.
Comment voyez-vous le marché du BPM en France dans 5 ans ?
– En fort développement, car la crise – et la recherche de nouveaux gains qu’elle engendre – va renforcer l’absolue nécessité de « repenser » l’organisation des entreprises autour de processus fluides et dénués de tout gaspillage.
Par ailleurs, la notation BPMN va très certainement s’imposer progressivement dans la modélisation des processus métier (BPA). Elle ne restera donc pas cantonnée à la modélisation « logique » des processus workflow. La version 2.0 de la notation apporte des évolutions par rapport à la 1.2 qui vont dans ce sens.
C’est une excellente nouvelle qui apportera plusieurs avantages :
– les processus seront mieux décrits grâce à une notation formelle qui oblige à une certaine rigueur, ce qui est loin d’être le cas avec les processus métier modélisés avec les outils actuels
– les modèles de processus seront indépendants des éditeurs d’outils de modélisation, ce qui aura pour conséquence de favoriser l’arrivée sur le marché de nouveaux produits innovants
– la notation devrait s’enrichir d’éléments permettant la simulation des processus
Vaste sujet que celui du workflow, sans même parler de BPM encore. D’autant plus lorsqu’on commence à faire la différenciation entre workflow documentaire, workflow de formulaire et workflow métier (pour ne parler que de ceux là).
Je m’y étais essayé dans une précédente note (lire la note en question) et je vais donc reprendre en partie ce que je disais alors pour définir ma conception du workflow documentaire (chaque éditeur ayant bien sûr la sienne lorsqu’on rentre dans les détails fonctionnels) afin d’alimenter cette série “concepts”.
On entend donc par workflow documentaire tout processus consistant à faire circuler 1/ des documents et 2/ d’un utilisateur à un autre. Je mets volontairement l’accent sur ces deux points car il n’est pas question ici de traitement métier impliquant une quelconque intégration aux applications de l’entreprise (cf. ma définition des besoins rencontrés par les entreprises).
C’est bien un “simple” circuit de routage des documents permettant à ces derniers de suivre un trajet prédéfini, pouvant être modifié par un des participants selon les cas (au run-time, si l’applicatif le permet ce que proposent la plupart des outils).
Ce circuit peut être purement séquentiel (le document passe d’une corbeille à l’autre sans possibilité d’aiguillage conditionnel) ou bien au contraire complexe et conditionné par les métadonnées portées par le document (par exemple envoi à un collaborateur A si une condition est satisfaite et à un collaborateur B dans le cas contraire).
Il sera également possible d’envisager des retours à l’envoyeur, des étapes de rendez-vous (plusieurs collaborateurs doivent valider le même document avant que le circuit n’avance), des sauts d’étapes (un responsable ne valide que certains documents pour lesquels une métadonnée présente une valeur particulière), etc.
Un workflow documentaire ne fait pas appel à des instructions systèmes élaborées (appel de sous-procédures, composants applicatifs, Web Services, transactions SQL, etc.) ou si peu, selon les produits.
On retrouve par contre chez certains éditeurs la capacité de ce type de workflow à faire appel à des composants de manipulation des documents, par exemple de conversion au format PDF (”PDF Rendition”), de modification/enrichissement par une application bureautique (par exemple application d’un modèle MS Word), ce type de fonctionnalité vient enrichir la capacité du workflow à prendre en charge une partie des traitements (purement documentaires donc) afin de minimiser les tâches à faible valeur ajoutée précédemment attribuées aux utilisateurs.
L’exemple (volontairement simpliste) ci-dessous montre ce que peut être un workflow documentaire consistant à :
• créer un document à partir d’une demande (par exemple nouvelle procédure Qualité) ;
• le rédiger à partir d’un modèle MS Word, stockage local pendant la rédaction (l’idéal étant d’utiliser la gestion des versions offerte par la GED sous-jacente) ;
• le faire relire ;
• le faire corriger si les critères de relecture ne sont pas satisfaits ;
• le faire valider ;
• le corriger si les critères de publication ne sont pas satisfaits ;
• le faire publier, classer en GED.
Ce circuit incluant quelques retours et branchements conditionnels peut être complexifié afin de prendre en compte de multiples acteurs, un enchaînement plus complexe d’actions, des validations plus nombreuses, une publication multi-canaux, etc.
Comme on vient de le voir, un workflow documentaire vient compléter un système de Gestion des Documents afin d’en faciliter la circulation, l’enrichissement, la classification, la publication. Il est en ce sens orienté “utilisateurs” (‘human centric’ selon la terminologie usuelle) et s’intègre assez naturellement aux applications bureautiques.
Jean-Christophe DICHANT
Site : www.bpmbulletin.com
Le BAM (Business Activity Monitoring) consiste à mesurer en continu des indicateurs (KPIs : Key Performance Indicators) et des métriques permettant de juger du bon fonctionnement général des processus de l’entreprise et de l’efficacité de la gestion des activités métier.
Objectifs complémentaires
Quatre objectifs complémentaires articulent cette démarche et posent des exigences vis-à-vis des solutions informatiques permettant de la supporter :
A qui est destiné le BAM dans une direction métier ?
Au sein d’une direction métier, 2 populations peuvent tirer bénéfice des projets de BAM :
A qui est destiné le BAM au sein d’une DSI ?
2 types d’acteurs de la DSI sont particulièrement concernés :
• les groupes de support informatiques (support applicatif, support à l’exécution de processus transverses informatisés) ayant à leur charge d’identifier la cause de problèmes métier constatés, de les résoudre rapidement en fonction des priorités métier définies et pouvant souhaiter anticiper leur résolution avant qu’ils n’impactent les acteurs métier.
Afin d’optimiser les processus informatisés, ces équipes peuvent par ailleurs être en attente de fonctionnalités leur permettant de donner un retour factuel aux équipes études en ce qui concerne les zones de dysfonctionnements récurrents, afin que les actions correctives soient engagées ;
• les équipes d’exploitation et de production informatique (supervision technique des systèmes, des échanges …) ayant sous responsabilité d’évaluer l’impact de problèmes techniques liés aux applications et flux d’échanges (rupture de flux, goulets d’étranglements) sur le bon déroulement des opérations métier et le niveau de service délivré.
Etre en mesure pour eux de prioriser la résolution de ce type de problème par rapport aux activités métier impactées constitue une valeur ajoutée réelle. Sur ce thème, certaines solutions de BAM offrent d’ailleurs des fonctionnalités équivalentes à celles offertes par des solutions de BSM.
Exigences vis-à-vis des solutions
Afin de répondre aux objectifs et aux axes de progrès attendus de la part d’une démarche de BAM outillée, une solution de BAM doit proposer un certain nombre de fonctionnalités :
• des fonctions de supervision temps-réel de processus et d’activités métier, permettant de suivre leur bonne exécution de manière massive ou bien unitairement pour chaque objet mis sous surveillance (objet métier, message, fichier, …).
La solution de BAM doit être en mesure de prendre en charge de multiples degrés de complexité dans ces processus et activités métier (processus linéaire, complexes, à branches optionnelles, activités conditionnées par un contrôle métier, activités humaines détectables par un événement informatique, …) ;
• des fonctions de pilotage temps-réel d’indicateurs de performance. Ces indicateurs peuvent prendre de multiples formes : durée d’exécution d’une ou de multiples étapes d’un processus, volumes d’objets (objet métier dans un statut métier donné, message parvenu à une étape du processus, fichier reçu ou émis), volumes et taux d’erreur, montants financiers liés à un volume d’objets métier traités…
Leur calcul doit résulter d’une agrégation de données relativement simple et intelligible afin de faciliter la compréhension de la valeur de l’indicateur pour l’utilisateur de la solution de BAM. La mise en place d’alertes paramétrables doit être permise au travers de l’IHM de la solution ;
• des fonctions d’aide à l’identification, la qualification, la résolution et l’anticipation des dysfonctionnements. Il s’agit par exemple :
– de fonctions d’analyse de cause,identification des instances de processus impactées par un même dysfonctionnement ;
– d’analyse d’impact (détermination automatique du niveau de sévérité d’un problème, indicateurs de suivi du respect du niveau de service …) ;
– d’analyse de risque (non-réception d’une donnée de la part d’un système dans un délai suffisant pour effectuer un traitement métier programmé et respecter un cut off …) ;
• des fonctions d’analyse de données et de restitution graphique avancée, incluant potentiellement des services de présentation.
L’ergonomie de la solution de BAM doit être flexible afin de s’adapter au besoin des différentes populations d’utilisateurs, sans pour autant générer un surcoût trop élevé en développement spécifique (l’aspect modulaire est à privilégier). La gestion sécurisée de l’accès aux écrans et l’interopérabilité avec des systèmes tiers (comme les portails par exemple) sont des compléments clés dans certains contextes.
Développer spécifiquement une solution de BAM est une alternative envisageable pour une DSI. Au vu des couches logiques composant une solution de BAM industrielle, il est tout de même souhaitable d’évaluer les solutions marché existantes afin d’identifier le degré de fonctionnalité couvert par ces solutions et de se faire une idée de la complexité d’un développement maison.
Architecture logique des solutions
Une solution de BAM se compose de plusieurs couches logiques :
• une couche de collecte ou d’absorption de données, prenant en charge la complexité de connectivité avec les systèmes sources et d’interprétation des données ;
• une couche de filtrage et de corrélation des données, où les règles de corrélation des données aux processus et activités métier supervisées sont paramétrées voire codées ;
• une couche de calcul des indicateurs par agrégation de données, d’analyse de ces indicateurs, de détection des tendances et des déviations. Cette couche peut embarquer des modules intelligents, pouvant par exemple « apprendre » le comportement nominal d’une activité métier sur des périodes calendaires définies ;
• une couche de restitution graphique des données collectées et indicateurs calculés, embarquant la logique d’accès sécurisé et pouvant proposer des services interopérables de présentation des données ;
• des espaces de gestion des données référentielles de la solution (définition des événements de collecte de données, des modèles d’observation des processus ou activités métier, des indicateurs calculés, des seuils d’alerte, des calendriers d’activation de la surveillance …) et des données d’exécution (valeurs des données brutes collectées, des indicateurs calculés, historique des alertes déclenchées …).
Déploiement d’une solution de BAM et impact du projet pour l’entreprise
Comme tout projet informatique, une fois l’étape du choix de la solution franchie, sa mise en œuvre et son déploiement requiert une démarche méthodologique adaptée.
Les phases suivantes d’un projet de BAM ont en particulier de véritables spécificités :
• l’analyse des besoins utilisateurs et l’élaboration des spécifications fonctionnelles du projet sont sans doute la phase la plus conditionnante.
En fonction de la typologie d’utilisateurs concernés et de la vocation du projet, il faut identifier les KPIs et fonctionnalités les plus pertinents vis-à-vis de la démarche de contrôle qu’adopteront les utilisateurs.
En découlent la constitution d’un modèle d’observation du processus ou des activités métier, le choix des modules d’analyse (risque, cause, impact), des typologies d’alerte (critères de déclenchement, plage calendaires de contrôle, destinataires, fonction d’acquittement …) et le maquettage des tableaux de bord de restitution ;
• la conception de l’architecture de la solution et des traitements de collecte de données doit garantir le niveau de service attendu (performance des traitements d’agrégation des indicateurs, fréquence de rafraîchissement des résultats, …) ainsi que la cohérence des évènements observés (mise à profit des horodatages métier, persistance des données source et cohérence des traitements de ré-émission, …) ;
• la phase de recette est structurante et doit investir les utilisateurs finaux, car elle permet de valider la fiabilité des indicateurs calculés et d’anticiper les sujets qui devront être traités au moment de la mise en production : initialisation du paramétrage fonctionnel de la solution (valeurs de seuil d’alerte, de paramètres métier spécifiques au processus à mettre sous contrôle …), prise en main des fonctions d’administration fonctionnelle, évaluation de la réaction à la montée en charge … ;
• l’activation de la solution sur les systèmes de production doit enfin s’accompagner d’une potentielle période de tuning (KPIs, alertes) ainsi que de mesures organisationnelles pour mettre en place les procédures de suivi et les circuits adéquats de résolution des dysfonctionnements.
Compte tenu de ses objectifs d’apporter une meilleure visibilité et réactivité sur des fonctions clés de l’entreprise, un projet de BAM ne constitue pas une approche remettant en cause l’existant informatique de celle-ci.
L’emploi de nouvelles connectivités techniques permettant de supporter des approches orientées événement (event-driven) peuvent parfois s’avérer souhaitable, notamment pour simplifier l’interprétation et la cohérence d’enchaînement des événements collectés. Une faible intrusivité technique vis-à-vis des systèmes source est dans tous les cas privilégiée.
L’impact le plus fort du projet est la nécessité de réorganiser autour de l’outil les procédures de contrôle et de support aux activités métier, ce qui peut conduire à modifier le rôle et les prérogatives de certains acteurs métier ou techniques. Négliger l’impact organisationnel d’un projet de BAM peut donc générer des espoirs infondés envers la solution mise en œuvre, et restreindre les bénéfices à attendre d’un tel projet.
Source : Guide Informatique – article : BAM : Business Activity Monitoring
Six sigma, méthode d’amélioration continue de la qualité, issue du monde industriel, tend à se développer de plus en plus dans le secteur tertiaire. Mais que signifie réellement le sigma du Six Sigma ? Quels sont les gains de la méthode ? Les limites ?
On a constaté qu’un produit (ou service) défectueux (ou défaillant) tend à réduire le niveau de satisfaction des clients. C’est pourquoi la méthode Six Sigma utilise le principe des « sigmas » pour que n’importe quel processus puisse être évalué sans tenir compte de son environnement. Le « sigma » est donc une échelle de mesure qui compare la production d’un processus aux attentes du client.
Lorsque l’on étudie un processus métier, on s’aperçoit qu’il est incapable de fournir un résultat constant dans la durée. Cette notion de variabilité est incontournable et on ne peut pas la faire disparaître complètement. Il s’agit donc de déterminer pour le processus étudié :
– la norme souhaitée (valeur moyenne)
– les limites de variation autour de cette norme (intervalle de variation)
Dès qu’un produit (dans le secteur de la production) est hors des limites fixées par l’intervalle de variation, il est considéré en défaut. On s’attend alors à avoir le plus grand nombre possible de produits sans défaut, c’est-à-dire dans l’intervalle de variation de la norme.
La lettre grecque σ (« sigma »), symbolise la variabilité statistique, encore appelé écart-type, permettant de mesurer la dispersion (répartition) des produits autour de la moyenne à l’aide d’une échelle de mesure (de 0 à 6). Plus le sigma est grand, plus la production est homogène, avec des valeurs proches de la moyenne.
Le tableau ci-dessous fait référence à l’échelle des sigmas ainsi qu’aux taux de qualité et défaut associés :
Le Sigma 6 représente donc l’objectif « idéalisé » d’un taux de défauts de 3,4 DPMO (Défauts Par Millions d’Opportunités), soit 3,4 produits défectueux sur un échantillon d’1 million, ce qui correspond à un taux de qualité de 99,9997%. Il faut cependant garder à l’esprit que l’objectif final de la méthode Six Sigma n’est pas d’atteindre la perfection, mais un niveau de qualité acceptable par les clients.
Pourquoi utiliser une nouvelle échelle et ne pas se contenter de mesurer simplement le taux de non qualité en pourcentage ? Pour des raisons pratiques : un taux de qualité de 99,4% qui apparaît excellent peut en réalité être désastreux ; 0,6% de rebut sur une production à grande échelle pouvant générer des surcoûts très importants. On conçoit qu’il soit peu porteur de motiver une équipe projet sur l’amélioration d’un indicateur 3 chiffres après la virgule. Mieux vaut alors changer d’échelle pour mieux s’approprier les objectifs d’amélioration.
Concrètement, voici des exemples de signification du « sigma » dans la vie courante :
Les points clés de cette méthode sont :
– des objectifs clairs, concrets, précis
– une gestion en mode projet (5 phases pour la méthode DMAIC : Définir, Mesurer, Analyser, Innover, Contrôler)
– une organisation dédiée « Six Sigma » (participant Green Belt, chef de projet Black Belt, responsable Master Black Belt)
– une démarche rigoureuse basée sur des analyses statistiques (fréquemment réalisées avec l’outil Minitab)
– une boîte à outils performante
– l’implication du « top management » (direction) par le biais d’un « sponsor »
– la formation et l’accompagnement au changement pour les acteurs du processus
– un suivi dans le temps du processus amélioré (c’est pourquoi on parle d’amélioration continue)
Trois éléments jouent un rôle essentiel dans le succès rencontré auprès des Directions Générales par cette approche :
– le fait que la démarche d’amélioration soit quantitative,
– la certification des compétences (les « Belt ») sur la démarche,
– l’existence de métriques indiquant précisément le niveau d’investissement nécessaire pour obtenir des résultats. Ce niveau, généralement élevé, évite de se lancer « a minima » dans la démarche et implique de facto un soutien de la Direction, compte tenu des moyens mobilisés.
Six Sigma s’appuie sur de nombreux outils pour avancer dans la démarche, dont voici les principaux :
– Le planning projet qui définit le calendrier, les acteurs, les livrables, les objectifs…
– La cartographie du processus qui définit les variables d’entrée et de sortie pour chaque étape du processus, les acteurs, les règles de gestion, les risques… (en deux exemplaires : une première version « as is » qui représente l’état actuel du processus, une deuxième version « to be » qui représente le processus cible).
– Le diagramme de Pareto qui permet d’identifier les 20% de causes qui engendrent 80% des problèmes (loi des 80/20).
– Le diagramme d’Ishikawa (ou diagramme en arêtes de poisson) qui liste et classe l’ensemble des causes pouvant affecter le processus.
– L’analyse du système de mesure qui étudie le caractère répétitif et reproductible du processus à l’aide d’un outil de statistique.
– Le plan AMDEC (Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité) qui détermine les variables à haut risque et les causes de défaillances des variables d’entrée du processus.
– L’analyse coût/bénéfices qui permet d’identifier la solution d’amélioration optimale.
– Le plan de contrôle qui documente toutes les actions nécessaires pour mettre le processus sous contrôle.
– Les indicateurs de performance et tableaux de bord qui permettent de contrôler l’amélioration du processus.
Le diagramme de Pareto permet de vérifier la loi des 80/20 : 80% des défauts sont issus des causes a et b, ce qui représente 2 causes sur 9, soit 22% des causes.
Le diagramme de Pareto permet de vérifier la loi des 80/20 : 80% des défauts sont issus des causes a et b, ce qui représente 2 causes sur 9, soit 22% des causes.
Le diagramme d’Ishikawa liste l’ensemble des causes aboutissant à un défaut (effet) du processus, selon cinq critères : matières, matériel, méthodes, milieu, main d’œuvre.
Le diagramme d’Ishikawa liste l’ensemble des causes aboutissant à un défaut (effet) du processus, selon cinq critères : matières, matériel, méthodes, milieu, main d’œuvre.
Un des impacts majeurs de Six Sigma est la réduction des coûts de non-qualité (retours clients, pertes de temps, problèmes de communication…). Cependant, selon la nature des projets, il arrive parfois qu’aucune opportunité financière ne puisse être dégagée. Ces projets se focalisent alors sur la satisfaction du client et la qualité de service fournie.
Les freins à l’avancée de projets Six Sigma sont la plupart du temps :
– Un système de mesure (des données du processus) peu pertinent. En effet, il n’est parfois pas possible de collecter des données fiables (système de mesure peu sûr ou absent), ce qui par la suite peut poser des problèmes pour savoir vers quoi tend le nouveau processus, si l’on ne connaît pas l’état actuel du processus.
– Un manque d’implication du « top management » qui aura pour effet de ralentir le bon déroulement du projet et d’en compliquer la communication au personnel de l’entreprise.
– Une coopération insuffisante de l’ensemble du personnel. La formation systématique de tous les employés concernés par le projet en cours est en effet un préalable.
On reproche également à la démarche de trop se focaliser sur l’amélioration de la qualité sans traiter de la réduction des délais. C’est pourquoi la méthode est de plus en plus couplée avec l’approche Lean popularisée par Toyota : on parle alors de « Lean Six Sigma ».
Mais le principal obstacle de la mise en place de l’amélioration continue ne se déroule pas au moment du projet. Lorsque ce dernier est correctement présenté, l’enthousiasme et la volonté d’action sont présents chez les acteurs du projet. La menace apparaît après, lorsque les habitudes passées finissent par reprendre le dessus. La régression est en effet la menace la plus courante. Ce retour en arrière annulera les gains promis, mais laissera surtout flotter un sentiment d’inutilité susceptible de démoraliser et de casser l’enthousiasme de l’ensemble du personnel pour les projets suivants.
Le levier de la réussite consiste donc à généraliser la culture du Six Sigma et de l’orientation client au sein même de l’organisation.
Six Sigma est donc une méthode structurée de management par les processus qui semble très séduisante à mettre en œuvre : il faut cependant être rigoureux et précis dans la démarche si l’on souhaite améliorer durablement la performance du processus.
Auteur : Jean-Baptiste GILLIOT, consultant chez BPMS
Le service support, un des piliers de la méthode ITIL
Ce domaine se compose de 6 processus types :
Configuration management
La gestion de configuration est utilisée pour assurer le contrôle de tous les composants de l’infrastructure informatique, y compris la documentation, et ainsi faciliter la maîtrise des changements et le traitement des incidents et des problèmes.
Change management
Processus décrivant les activités permettant de conduire rapidement et efficacement tous les changements afin de minimiser le risque d’impact négatif de ces changements sur la qualité de service.
La demande de changement se fait à travers des RFC (Request For Change). Ces RFC sont passés en revue par le CAB (Change Advisory Board).
Le CAB est un comité consultatif chargé d’évaluer le risque et l’impact de ces changements et de conseiller le gestionnaire des changements.
Release management
Processus visant à coordonner l’ensemble des activités liées au stockage, à la gestion, à la distribution et à la mise en place de tous les composants logiciels du système d’information.
Il garantit que les versions autorisées et testées des logiciels sont effectivement mise en production, constitue un référentiel des logiciels autorisés et prend en compte les aspects techniques et non-techniques.
Ces versions sont stockées dans une DLS (Definitive Software Library) – bibliothèque de versions de références –.
Service desk
Le service desk est le point de contact, au quotidien, entre les utilisateurs du SI et le département informatique.
Il est responsable du traitement de toutes les attentes des utilisateurs, que celles-ci soient de simples demandes ou occasionnées par des dysfonctionnements du SI (qu’ils soient directement signalés par des appels utilisateurs et/ou par des remontées d’alarmes automatiques).
Pour tout dysfonctionnements, il doit également s’assurer de la remise en conformité du SI du point de vue de l’utilisateur. Le Service Desk est responsable de l’application des processus de résolution des incidents.
Incident management
Processus permettant de décrire les activités afin de restaurer, aussi rapidement que possible, le service normal, et de réduire, au minimum, l’effet négatif du dysfonctionnement.
Problem management
Processus qui permet d’optimiser le niveau de service en analysant les causes réelles des dysfonctionnements et en y apportant des solutions correctives, afin d’éviter que ces mêmes dysfonctionnements ne se produisent à nouveau.
On constate que plusieurs processus sont imbriqués les uns aux autres. C’est le cas de Configuration Management, Service Desk, Incident Management et Problem Management.
Mais de quoi sont composés les processus de Configuration Management et Service Desk qui sont les processus principaux de ce module ?
Description détaillée du processus de « configuration management » et « service desk »
Le processus de configuration management à pour objectifs de :
– contrôler l’infrastructure informatique en recensant l’ensemble des informations sur toutes les ressources nécessaires à la fourniture des services informatiques ainsi que sur l’état, l’appartenance et l’historique des différents composants de l’infrastructure et enfin sur les relations entre les différents composants,
– mettre à jour et faire le suivi de toute modification,
– vérifier que l’infrastructure ne contient que les composants « autorisés ».
Il permet non seulement de piloter la configuration logiciel mais aussi la gestion de l’organisation autour du logiciel.
Ce processus contient deux éléments :
– des CI pour Configuration Item – c’est un élément de configuration au sens large utilisé pour fournir un service–. Il est identifiable et peut être géré. Il se caractérise par une catégorie, des attributs, des relations et un statut.
– une base de donnée qui regroupe ces CI.
La classification des éléments de configuration se fait par catégorie (groupe d’éléments ayant une ouades caractéristique(s) commune(s)) et par statut (caractéristiques propres aux éléments d’une même catégorie).
Le statut décrit l’état d’un élément (réparation, production, préparation…).
L’ensemble de ces états constitue le cycle de vie de cet élément.
Le Service Desk a pour objectifs :
– d’être la principale interface entre la DSI et les utilisateurs pour : les incidents, les questions, les améliorations, les remarques,
– de gérer la satisfaction du client par rapport aux services fournis,
– de piloter la fourniture des différents services,
– de gérer initialement les incidents et superviser le processus de gestion des incidents jusqu’à leur résolution,
– de contribuer à l’utilisations optimale du SI en fonction des objectifs et des contraintes du business,
– de fournir une source centrale d’information pour le management des services.
Le Service Desk doit :
– recevoir et enregistrer tous les appels utilisateurs,
– réaliser une première évaluation pour tous les incidents,
– suivre dans le temps et affecter tous les incidents en respectant les engagements de niveaux de service,
– contrôler le cycle de vie de tous les appels (validation et fermeture incluses),
– coordonner l’ensemble des activités d’escalade,
– informer régulièrement l’utilisateur sur l’état et la progression de son appel,
– fournir une source centrale d’information pour la gestion des services,
– participer à l’identification des problèmes.
Comme on le constate le Service Desk ne se situe pas au même niveau que les autres processus. En effet, il « pilote » les processus d’Incident et Problem Management. Il intervient aussi bien à un niveau informationnel (gestion de la documentation) que logiciel.
L’autre pilier de la méthode : service delivery
5 processus types le composent :
Service Level Management
Ce Processus permet de définir, négocier, documenter et contrôler les services et les niveaux de service, en collaboration avec le représentant des utilisateurs (clients) chargé de cette activité et les prestataires de services internes ou externes (ou leurs responsables) chargés de fournir le service.
Il permet d’établir un catalogue des services, d’évaluer l’expression de besoins utilisateur et de valider les niveaux de service requis (Service Level Requirement – SLR), de négocier et formaliser les contrats de service (Service Level Agreements – SLA), les engagements de prestations en interne (Operational Level Agreements – OLA) ou en externe avec les contrats de sous-traitance (Underpinning Contract – UC) et enfin de rédiger et mettre en œuvre le Plan Qualité (Service Quality Plan – SQP).
Availability Management
La gestion de la disponibilité (Availability Management) est le processus permettant de mettre en œuvre une méthode et des outils qui permettent de mesurer et de piloter la disponibilité des composants du SI pour s’assurer que la disponibilité des services est conforme aux engagements pris dans les SLA’s (Service Level Agreements).
Capacity Management
La gestion des capacités est le processus permettant de prendre en compte :
– la stratégie de l’entreprise : les services que l’on souhaite pouvoir délivrer dans le futur ( Business Capacity Management).
– l’organisation de la production : La façon dont les services sont actuellement fournis (Service Capacity management).
– l’infrastructure : les moyens à mettre en œuvre pour pouvoir fournir les services (Resource Capacity Management).
Il permet aussi de s’assurer que tous les aspects actuels et futurs en terme de ressources et de performance sont pris en compte.
IT Service Continuity Management
Le service Continuity Management est le processus permettant de définir, tester et mettre à jour régulièrement, les plans et/ou procédures, afin de prévenir toute interruption des services critiques pendant une longue période.
Financial Management for IT Services
C’est un processus qui permet de :
– déterminer la rentabilité des actifs et des ressources utilisées pour la fourniture des services,
– expliquer entièrement les dépenses sur des services et attribuer ces coûts aux services fournis aux clients de l’organisation,
– aider à la prise de décision sur les investissements
Pour en savoir plus :
http://www.itil.co.uk
http://www.itsmf.com
Guillaume DECALF – Consultant
Famille : Organisation
Termes équivalents : Zachman Framework
Définition BPMS
Très répandu dans le monde anglo-saxon pour développer des SI, le modèle Zachman est une matrice de 36 cellules qui couvre toutes les dimensions d’une entreprise en répondant aux questions : « quoi, comment, où, qui, quand, pourquoi». Cette représentation fournit ainsi 6 perspectives différentes, commençant du plus haut niveau d’abstraction de l’entreprise jusqu’au niveau le plus détaillé de mise en œuvre.
Famille : Automatisation/intégration
Définition BPMS
Langage de description de données défini par le W3C.
Evolution du langage SGML, XML permet aux concepteurs de documents HTML de définir leurs propres marqueurs, dans le but de personnaliser la structure des données qu’ils comptent présenter. Alors qu’HTML précise comment les éléments d’une page seront présentés, XML définit ce que contiendront ces éléments. Il permet de créer des pages Internet
sophistiquées (comprises par les navigateurs modernes). Mais aussi, il est utilisé pour les échanges entre machines et/ou programmes, même étrangers entre eux (EDI, Services Web…).
Famille : Automatisation/intégration
Définition BPMS
Intégration de processus informatisés afin d’en améliorer la performance globale.
Edité par : Cecima Version : 12.0.1
|
![]() |
||||||
Descriptif
WinDesign est une Suite de modélisation d’entreprise, offrant 3 modules, autonomes et complémentaires, articulés autour d’un référentiel. |
|
||||||
Prestataire compétent sur cet outil : | |||||||
Cecima | |||||||
BPMS | |||||||
![]()
![]()
![]() Les stéréotypes et caractéristiques étendues associées au paramétrage graphique des objets permettent : Pour faciliter la représentation graphique des modèles, une bibliothèque de patterns et templates est proposée en standard pour chaque type de diagramme. Celle-ci peut être amendée et complétée par l’utilisateur. Référentiel ![]() Système de requêtes et analyses d’impacts
![]()
![]() Support BPMN2.0
![]() |
|||||||
Points forts | |||||||
– Facilité d’installation
|
|||||||
|
|||||||
Cet outil a fait l’objet d’un banc d’essai :
Il est inclu dans notre étude outils BPA. L’achat de l’étude permet également d’accéder en ligne aux résultats du banc d’essai via le comparatif outils.
|
|||||||
Famille : Organisme
Acronyme : Workflow Management Coalition
Définition BPMS
La coalition WfMC est une association internationale regroupant éditeurs, utilisateurs et analystes, dont la mission est de promouvoir et de développer l’utilisation de la gestion électronique de processus (workflow), grâce à la définition de standards de logiciels, en termes de syntaxe, d’interopérabilité et de connectivité.
Famille : Organisation
Termes équivalents : Modèle VCOR, Chaine de valeur
Définition BPMS
Crée par le Value chain group (VCG), VCOR est un référentiel des processus de la chaîne de valeur couvrant le périmètre de l’écoute des besoins du marché au support après-vente en passant par la définition de l’offre, son lancement, l’avant-vente,
la contractualisation, et le suivi de la relation commerciale.
Le value stream mapping vise à la simplification d’une organisation, ce qu’on appelle communément le « lean ». Le value stream mapping ne tend pas ici à amorcer une nouvelle révolution, le concept de lean jouissant déjà d’une réputation établie. La transposition du lean dans la pratique, à savoir l’élimination efficace de tout ce qui, dans l’organisation, est superflu, se limite par contre encore à quelques exemples types. La raison principale est que l’on ne possède pas encore d’idée précise de ce qui constitue ce superflu – le « waste ». De même qu’il n’existait pas encore de modèle clair pour implémenter le lean. Le value stream mapping tente de remédier à ces deux manquements.
Dans ce premier article, nous exposons brièvement la méthode de value stream mapping. Un prochain article testera ces concepts théoriques par rapport à un exemple pratique.
Pourquoi le value stream mapping ?
Malgré tout ce qu’on peut prétendre, l’essence des affaires n’est aujourd’hui rien de plus que ce qu’elle était il y a environ cent ans : faire des bénéfices. Il ne fait aucun doute, cependant, que l’environnement a subi une transformation drastique, et qu’il était (et est encore) dès lors nécessaire de s’adapter pour acquérir un avantage compétitif permanent ou une meilleure position concurrentielle. Dans cette quête perpétuelle des stratégies les plus efficaces et les plus rentables, le concept de lean est apparu depuis quelque temps comme un guide fort utilisé et efficace. Le lean vise à la rationalisation d’une organisation en éliminant tout ce qui utilise des ressources sans créer de valeur directe. Toutefois, le lean n’est pas une fin en soi : l’application de la réduction des stocks, par exemple, peut avoir un effet inverse à celui escompté s’il n’y a pas d’encadrement correct. C’est pour cela que des projets d’amélioration indispensables échouent encore trop souvent, ou se limitent à l’optimalisation d’un petit sous-processus.
Le value stream mapping peut créer le cadre nécessaire qui permettra finalement une organisation lean : il structure et indique la direction à suivre pour introduire des projets de lean, afin d’atteindre un optimum global.
Qu’est-ce que le value stream mapping ?
Le value stream mapping manie son propre vocabulaire, très clair. Le value stream – flux de valeurs – liste toutes les activités nécessaires pour guider un produit à travers les principaux processus indispensables pour donner à ce produit sa valeur finale. Toutes les activités y sont reprises, aussi bien celles qui apportent une valeur ajoutée que les autres. Le value stream mapping est, au sens étroit du concept, la méthode à appliquer pour suivre le flux de marchandises et d’informations à travers ce flux de valeurs, et pour le traduire visuellement de façon claire. Dans un sens plus large, le value stream mapping reprend également le processus d’amélioration continue qui sera expliqué plus loin.
Le but du value stream mapping est d’atteindre une organisation lean, à savoir une organisation dans laquelle les activités n’apportant aucune valeur ajoutée, appelées waste, ont été éliminées. La nouveauté dans cette approche est le fractionnement rigoureux du concept de waste, grâce auquel le sens de ce terme vague devient clair.
Approche du value stream mapping
Etablissement du current state (état actuel)
Avant de pouvoir appliquer des changements, il y a lieu de détecter les points problématiques actuels au moyen d’une représentation précise et réaliste du fonctionnement actuel. Un certain nombre de règles empiriques existent pour établir ce current state.
Commençons avec une famille de produits, c’est-à-dire un ensemble de produits présentant approximativement la même conception, le même processus de production et des éléments semblables.
Dans une première phase, en parcourant la salle de production, on suit cette famille de produits à contre-courant, à savoir en partant du produit fini destiné au client, jusqu’aux principales matières premières. À chaque étape du processus, les caractéristiques pertinentes sont notées, comme le stock, le temps d’attente de ce dernier, etc. La valeur ajoutée est ici d’une importance capitale : quelle modification le produit subit-il pour acquérir une plus grande valeur et pour que le client soit finalement d’accord de payer ? Et combien de temps ces opérations prendront-elles ?
Dans une seconde phase, on fait un tour d’horizon du flux d’informations, qui règle le flux physique de marchandises. Dans les grandes lignes, on retrouve ici principalement la réception des commandes des clients et l’envoi de programmes de production.
Enfin, toutes ces données sont rassemblées dans une représentation visuelle reprenant plusieurs icônes standard : la current state map.
Un exemple type de current state map est représenté très sommairement dans la figure 3. Il résume de façon claire l’interaction entre flux d’informations et flux de marchandises. Dans une figure entièrement élaborée, on verrait en outre clairement la relation entre le temps apportant une valeur ajoutée et le temps total de lead.
L’attention se porte donc simplement sur le produit, et non sur les divisions de l’organisation, ni sur les inducteurs de coûts ou la technologie. Quant à l’état des matériaux, il est tout aussi peu pris en considération.
Elaboration du future state (état futur)
L’élaboration de la future state map ne se réduit pas à une re-conception tendance et un enjolivement de la current state map. Il y a plus. L’approche est structurée en 6 directives.
Directive 1 : Produire en accord avec le « takt time » (rythme de la demande) du marché
Le takt time est le rythme auquel le marché demande des marchandises issues de la production. Un exemple simple pour clarifier : si chaque jour, une moyenne de 10 pièces sont vendues sur le marché et que le temps de production disponible s’élève à 10 heures, le takt time sera d’1 heure par pièce. Cette règle simple se complique cependant en cas de saisonnalité importante ou de modèles de demandes très sporadiques. Mais la plupart du temps, il est possible de définir la famille de produits dans le current state de telle sorte que l’on peut remédier à ces problèmes. Le takt time indique le rythme de production : c’est le marché qui entraîne la production.
Directive 2 : Introduire le flux continu là où cela s’avère possible
Examiner la possibilité d’instaurer des systèmes de production continue, en partant du point final de la chaîne de production. Plusieurs méthodes ont déjà été élaborées pour ce faire, puis testées par rapport à la réalité. Les lignes d’assemblage fixes sont l’exemple le plus connu dans lequel il n’y a plus de stock intermédiaire, mais seulement des WIP en développement. On trouve des alternatives à ce thème avec les « bucket brigades » (chaînes) ou l’installation de lignes de production flexibles, en U ou CONWIP, mais les conséquences de ces concepts seront ici laissées de côté. À partir du point où la production continue n’est plus possible, des supermarchés sont installés. Ce point spécifique est appelé « pacemaker ».
Directive 3 : Utiliser des supermarchés dès que le flux continu n’est plus possible
À première vue, les supermarchés ressemblent simplement à d’énormes stocks, nommés autrement pour enjoliver. Mais cette apparence est trompeuse. Un supermarché est un système de stock qui abrite un ensemble de produits semi-finis et renouvèle seulement ceux qui entraînent la partie continue de la production dans le sens du courant. Une fois qu’un produit disparaît du supermarché, la production de ce produit est demandée à – comprenez : tirée de – un processus allant à contre-courant. Un autre produit intermédiaire est alors pris dans un autre supermarché.
Directive 4 : Envoyer le programme client vers le pacemake du flux de valeurs
Les demandes des clients peuvent difficilement être libérées dans les ateliers de production dans l’ordre dans lequel elles entrent ou encore, non traitées. Le value stream mapping ne fait pas d’exception à cela : il est toujours nécessaire d’établir un programme. La seule chose un peu exceptionnelle est que le value stream mapping ne programmera qu’un seul processus : le pacemaker susmentionné. Cela est rendu possible par le fait que tout le traitement ultérieur du produit se trouve dans un flux continu et que la production est entraînée à contre-courant. Dans la pratique, il apparaîtra que ce pacemaker est devenu le point de dissociation de la clientèle.
Directive 5 : Etaler la production
Le programme mérite encore davantage d’attention. Il est fortement conseillé, dans la logique présupposée, de répartir la fabrication des différents produits de la façon la plus égale possible à travers le pacemaker. Cela aura surtout comme résultat qu’on ne rencontrera plus, en amont, de perturbation inutile de la demande. On s’opposera ainsi le mieux possible à l’effet Forrester redouté.
Ces cinq directives doivent résulter en l’élaboration d’un future state plan. La figure 4 représente un développement possible de l’exemple type original.
Clôture du cycle
Si on se contente d’établir un current et un future state map, rien ne changera encore dans la pratique. Un plan d’implantation développé et suivi par une équipe compétente doit garantir la réalisation concrète.
Une fois les processus superflus écartés, on n’agira plus, dans la mesure du possible, que dans le sens d’un ajout de valeur. Même si on rêve de ce scénario, il ne peut constituer une fin en soi. Il faut veiller à ce que les modifications ultérieures sur le marché et dans le vaste environnement de production soient perçues assez tôt pour pouvoir y réagir de façon appropriée. Après l’élimination du superflu, le future state est devenu réalité et retombe alors à l’état de nouveau current state. Vous l’avez deviné : le cycle recommence.
Remarques concernant le value stream mapping
Le value stream mapping est une méthode intuitive, simple et relativement bon marché pour mener à bien un projet de lean. Il ne faut toutefois pas s’attendre à un miracle : aussi bon qu’il puisse être, il n’est pas parfait. Ou plutôt, pas complet.
Le value stream mapping perfectionne la collaboration de différents processus, mais il influe à peine sur les processus mêmes. En outre, il part du principe que les processus sont disponibles à tout moment, ce qui n’est malheureusement pas le cas. Ces deux défauts peuvent toutefois être compensés par deux autres concepts qui sont juste un peu inférieurs aux points forts du value stream mapping. Il y a d’abord le 6 Sigma, qui vise à optimaliser les processus individuels. Selon le 6 Sigma, la variabilité doit être en fin de compte si faible que la possibilité d’une qualité imparfaite devient insignifiante. L’autre concept est celui de Total Preventive Maintenance ou TPM, qui gère la disponibilité des outils de production de façon optimale, et ce, grâce à un entretien ciblé et préventif. Voilà ce qu’il en est de la critique facilement réfutable du value stream mapping.
Un autre défaut du value stream mapping est qu’il s’adresse principalement au flux physique de marchandises. Dans les représentations graphiques du flux de valeurs, on ne trouve pas, en ce qui concerne le flux d’informations, de données relatives aux délais de traitement, ou d’informations sur l’ajout de valeur. Les premières étapes, pour remédier aussi à ce défaut, sont déjà reprises lors de l’adaptation du value stream mapping aux environnements de bureau.
Conclusion : résultats du value stream mapping
Le value stream mapping est, exprimé autrement, une extension du concept de lean. Il complète donc le vocabulaire et fournit un cadre dans lequel les projets d’implémentation peuvent être accrochés. La plus grande valeur ajoutée du concept de lean est indubitablement le lien entre le flux d’informations et le flux de marchandises, ainsi que la création d’un fil conducteur aidant à représenter le tout de façon uniforme.
Mais un simple concept n’est aucunement séduisant. Par contre, les réductions de coûts qui résultent d’un value stream mapping réussi le sont. En effet, les stocks, étapes de processus et temps d’attente superflus et onéreux, sont éliminés. Ces réductions de coûts constituent dès lors l’objectif réel. Suivant la logique du lean, le coût de la production est en effet directement lié aux bénéfices réalisés. Aujourd’hui, c’est le client qui détermine le prix, à tel point que la plupart des entreprises n’ont d’autre choix que d’accepter ce prix, au lieu de le fixer elles-mêmes. De cette façon, le bénéfice suit en partant du prix accepté moins les coûts engendrés. Le schéma traditionnel « frais + bénéfices = prix de vente » n’est malheureusement plus suffisant dans beaucoup de cas. En d’autres termes : le client est roi et le value stream mapping tente d’y répondre le mieux possible. Mais outre la question du prix demandé, il y a aussi l’adéquation aussi précise que possible de la production au rythme de demande du marché et au raccourcissement des délais grâce à une efficacité supérieure.
Définitions
Kaizen : petites améliorations quotidiennes réalisées par chacun. L’objectif de l’approche kaizen est d’atteindre une élimination totale du gaspillage (waste). S’il s’agit, dans le plan d’implémentation, de passer du current au future state, le kaizen ne suffit pas : des changements en profondeur sont alors nécessaires, comme un réajustement des postes de travail sur une ligne de production. On parle alors de kaizen burst.
Heijunka : l’équilibrage de la charge de travail dans un laps de temps et de la capacité disponible pour exécuter ce travail. En fabriquant différentes sortes de produits, on répartit le planning de la façon la plus étendue possible. Dans un système kanban, différentes sortes de kanbans sont réparties le plus également possible dans l’ordre de production.
Alex Waterinckx
La vocation de l’urbaniste
Elaborer et maintenir un plan d’évolution de l’informatique en concertation avec les directions métiers. Une fonction qui nécessite un profil de compétences particulier, et qui donne parfois lieu à la création d’un poste dédié.
Une fonction ou un métier?
La fonction d’urbaniste tendrait-elle à devenir un métier ? Au sein des grands groupes, en tous cas, on constate l’apparition des poste dédiés à ce domaine. C’est notamment le cas au sein des groupes présentant des systèmes d’information complexes, dotés de nombreux processus transversaux nécessitant ce type de formalisation. En France, l’ensemble des sociétés du CAC 40 sont désormais pourvues de tels responsables.
Mais sur cette question, le débat fait rage entre les experts du monde de l’urbanisation. Pour certains, cette fonction ne doit surtout pas être portée par un responsable particulier, à 100% de son temps. Elle doit plutôt être partagée entre plusieurs opérationnels et membres de la DSI, dans l’optique de favoriser l’appropriation de la démarche par tous. D’autres, en revanche, défendent la vision d’un urbaniste bien identifié au sein de la DSI, seule façon de garantir pour eux la mise à jour des cartographies et la pérennité du chantier d’urbanisation dans le temps.
Les rôles de l’urbaniste
La cartographie du système d’information
Le premier rôle d’une fonction ‘urbanisme’ est l’élaboration d’une cartographie du système d’information. « L’idée est de bénéficier en permanence de deux cartes permettant un dialogue entre la DSI et les directions opérationnelles (MOA) : l’une présentant l’état du SI à un instant T, l’autre une ou plusieurs cibles à atteindre », commente Bernard Leroux, directeur associé chez Cosmosbay-vectis.
La carte cible vise à modéliser les processus métier transverses à optimiser ou à ajouter à l’existant. Elle permet aussi de projeter les impacts de ces projets d’implémentation sur les applications et l’infrastructure informatique (en termes de déploiement, d’intégration, etc.).
Bref, d’évaluer la faisabilité d’une décision, en vue de définir sur cette base un schéma directeur d’évolution. Pour y parvenir, les experts recommandent une méthode de modélisation par couches (stratégique, processus métier, fonctionnelle, applicative et infrastructure) affichant les liens entre chacune d’elles.
Un langage commun pour tous les protagonistes
En vue d’assurer le dialogue entre les différents acteurs (entre directions générale et opérationnelles et DSI), ces cartes doivent s’adosser à des référentiels de vocabulaires permettant de bénéficer d’un langage commun, à la fois au niveau des couches métiers et fonctionnelles (qu’est-ce qu’un processus de commande, d’achat, etc.), et au niveau des couches techniques – avec à la clé la définition de standard d’intégration assurant un découplage technique entre ces différentes couches pour faciliter le déploiement de processus transverses.
« Pour les informaticiens, cette approche permet aussi de se situer dans la chaîne de valeur de l’entreprise », note également Grégory Weinbach, directeur d’agence chez Objet Direct (Homsys Group).
La définition de règles de gouvernance
Seconde grand rôle de la fonction d’urbanisation : la définition de règles de gouvernance. Car, une fois la cartographie du système réalisée, il est nécessaire d’appliquer des règles pour garantir sa maintenance. Un travail qui permet de bénéficier d’une carte à jour, en vue d’assurer un contrôle permanent de la cohérence du SI avec la stratégie de l’entreprise tout en étant en mesure de piloter son évolution.
« Il s’agit ici de mettre en place une gouvernance de l’évolution du SI », résume Bernard Leroux. « Cette démarche passe par la définition de méthodes d’évolution des référentiels d’urbanisme et de la cartographie, outillées, avec des applications de modélisation, et basées sur des procédures de demande et de validation des changements… »
Antoine CROCHET-DAMAIS, JDN Solutions
Les spécialistes des systèmes d’information (SI) ont choisi de nommer urbanisation la démarche qui consiste à rendre un SI plus apte à servir la stratégie de l’entreprise et à anticiper les changements dans son environnement (CIGREF).
L’urbanisme, dans ce contexte, vise à prendre en compte la nécessaire réappropriation du SI par les maîtres d’ouvrage (stratégique, opérationnel, délégué) ; pour cela, une compétence plus grande en matière de SI leur est nécessaire.
Les techniques d’urbanisme ont également pour objectif d’accroître la communication avec les maîtres d’œuvre. La performance d’une organisation (entreprise, administration, service public,…) est aujourd’hui très dépendante de la qualité de son SI, dont la complexité est sans cesse croissante.
Il faut maîtriser le SI pour pouvoir le moderniser : le projet d’urbanisation du SI n’est pas un projet en plus ! C’est souvent celui qui permet de réussir tous les autres.
Auteurs : Bernard Le Roux, Luc Desbertrand, Pascal Guerif et Xavier Tang
Référence ISBN : 2746208857
Le point de vue d’un DSI
Dans ce livre, destiné aux informaticiens opérationnels, aux managers, mais aussi aux étudiants, le DSI de Bouygues Telecom tire des leçons de son expérience. Il explique, notamment, pourquoi se lancer dans un projet d’urbanisation des systèmes d’information et de gestion des processus métier (BPM). Il indique aussi comment le mener à bien et les pièges à éviter afin de faire évoluer la notion de système d’information urbanisé.
Auteurs: Yves Caseau
Référence ISBN : 2100487248
Famille : Organisation
Définition BPMS
Représentation fonctionnelle du SI indépendante des applications qui le composent.
Famille : Organisation
Définition BPMS
On parle d’unicité dans un référentiel lorsque chaque objet est unique. Ainsi, si on applique une modification sur un objet utilisé dans plusieurs modèles, elle sera effective dans tous les modèles.
On parlera d’occurences de cet objet pour décrire l’utilisation du même objet dans plusieurs modèles ou au sein d’un même
modèle.
La gestion de l’unicité des objets est un préalable pour pouvoir mener des analyses d’impacts.
La modélisation est un support de réflexion collective qui permet de dénouer la complexité des situations étudiées, en focalisant le débat sur les objectifs du projet. De quoi faire converger Maîtrise d’Ouvrage et Maîtrise d’Oeuvre.
Modéliser les processus métier peut sembler simple. Or, la diversité des interlocuteurs, la complexité du métier, les cultures parfois différentes de la Maîtrise d’Ouvrage et de la Maîtrise d’Œuvre et les contraintes de productivité auxquelles sont soumis les acteurs, compliquent la donne.
Multiplicité des représentations individuelles, vocabulaire imprécis ou changeant, orientations divergentes… font souvent de la définition même d’un projet d’organisation et de ses objectifs un objet de conflit qu’on évite d’approfondir.
La modélisation n’est pas un cadre rigide qu’il s’agirait d’apposer sur l’entreprise sans souplesse ni prise en compte des spécificités du projet et du métier. Méthode plutôt que recette, elle sait s’adapter aux contraintes.
En premier lieu, déterminer le domaine d’application du projet
Pour ce faire, les processus sont situés et évalués à l’aulne des processus déjà identifiés au sein d’un catalogue regroupant les activités métier et les processus s’y rattachant. Cette grille d’analyse permet de déterminer la nature, d’analyser et de communiquer sur l’existant tout en précisant déjà les orientations possibles du projet.
Il n’est pas rare que, dès cette étape, les interlocuteurs Maîtrise d’Ouvrage et Maîtrise d’Œuvre ressentent une avancée : les bases sont connues et communes, les zones d’ombre sont éclaircies, les problèmes sont identifiés et deviennent souvent des éléments dynamiques de réflexion pour l’élaboration du projet en tant que tel.
Cette première phase peut sembler futile dans le cadre de petits projets dont l’impact paraît mineur. Il n’en est rien, elle est capitale : en définissant les frontières du projet, elle lui donne d’abord un espace de réalisation, mais surtout elle lui donne sens dans la structure globale d’un service, d’une entreprise. C’est de cette phase que dépend l’identité du projet, partagée par tous les acteurs et donc, sa pertinence !
La modélisation des processus commence. Il faut lister les évènements déclencheurs et résultants de processus.
L’approche de la notion d’événement est révélatrice des difficultés inhérentes au projet et au métier mais elle permet paradoxalement de surmonter le « syndrome de la page blanche ».
Souvent auprès de nos interlocuteurs, la notion d’événement métier reste vague. En effet pour le dictionnaire, un événement est un fait qui arrive ou un fait important. Mais pour le modélisateur de processus, un événement est le résultat ou le motif déclencheur d’une activité du métier. Cette différence sémantique trouble nombre de nos interlocuteurs au cours des séances de modélisation et amplifie le syndrome de la page blanche.
La notion d’événement, telle qu’elle est définie par le modélisateur, doit permettre de surmonter ces différences de point de vue en objectivant les opérations et les données du métier. La phase est délicate. Le modélisateur doit écouter, comprendre et respecter les témoignages qu’il recueille tout en prenant, dans le même temps, suffisamment de recul. Cette distance réfléchie rendra possible l’élaboration des projets transversaux et facilitera les relations d’équipe en permettant l’expression et la prise en compte des compétences individuelles à chaque niveau d’élaboration du projet.
Le modélisateur doit jouer le rôle de révélateur
Précisons d’abord que le stade de la feuille blanche est un stade normal et nécessaire. Le modélisateur doit jouer le rôle d’un « révélateur ». Les éléments sont posés sur la table de réunion, pêle-mêle certes, mais avec leurs nuances respectives. Ce panorama exhaustif est la condition sine qua non d’une démarche consensuelle. Il permet aux acteurs d’échanger, de faire part de leur problématiques propres et de prendre conscience de leurs différences. Les informations sont nombreuses, parfois divergentes et contradictoires. Il s’agit là d’une étape importante et féconde, si elle est dépassée…
Pour ce faire, le modélisateur doit, à ce stade, visualiser le projet comme une boîte noire et identifier tous les éléments – les événements au sens méthodologique du terme – entrants et sortants (appels téléphoniques, fichiers envoyés, éditions produites…). Dans le cadre de projets conséquents, afin de faciliter l’identification, il est conseillé de visualiser des « boîtes » de périmètre plus restreint reprenant le découpage fourni par le cadrage du projet. Le modélisateur peut ainsi facilement réaliser une première liste d’événement déclencheurs et résultants. A partir de ces évènements déclencheurs, il n’aura plus qu’à identifier l’activité produite et les événements résultants et ainsi de suite jusqu’aux éléments résultant des processus.
L’approche événementielle dénoue la complexité
Cette approche de la complexité devient, à chaque étape de l’élaboration des modèles, un outil de travail opérationnel pour les membres du projet qui l’utilisent comme une donnée objective et descriptive de l’identité et des finalités du projet.
De plus, cet outil intellectuel permet une convergence selon deux axes complémentaires : une visualisation globale et la focalisation sur des points particuliers et annexes.
Il offre donc, outre sa capacité fédératrice, une grande lisibilité du projet en tant que tel. Lisibilité qui s’avère des plus profitable puisqu’elle permet d’évaluer la pertinence de chacune des étapes et leur éventuelle modification dans le respect de la structure et de la finalité globale du projet. Elle permet également une réévaluation des objectifs en cas de variation du budget consacré au projet, comme un étalement progressif dans le temps des différentes phases d’implémentation.
L’approche événementielle de la méthode de construction des processus est d’un apport qui déborde ce cadre de la modélisation. C’est un véritable support de la réflexion collective qui permet de dénouer la complexité des situations étudiées en focalisant le débat sur les objectifs de chaque activité constitutive du processus et donc sur les objectifs « réels » et partagés du projet.
Auteur : Olivier Baude (photo)
KBC, groupe de bancassurance multicanal européen, utilise, dans le cadre de la documentation et de la modélisation de ses processus, la Suite de modélisation MEGA afin de promouvoir l’alignement de ses activités.
Les solutions d’architecture d’entreprise de MEGA International apportent à KBC les connaissances nécessaires à la création d’une architecture orientée service (SOA) destinée à optimiser l’efficacité de la société.
Le groupe KBC qui fournit ses services aux particuliers et aux entreprises dans une trentaine de pays européens et emploie plus de 50 000 personnes, est confronté, en tant qu’organisation multinationale, à un certain nombre de défis opérationnels.
En raison de l’internationalisation croissante de la société, le groupe ICT, prestataire des services informatiques de la société, a du faire face à divers problèmes : particularismes linguistiques et culturels, divergences en termes d’alignement des activités et des objectifs et différences des niveaux de compétence technique et fonctionnelle au sein du département informatique.
KBC a lancé un programme stratégique dans toute l’Europe fondé sur le développement d’un haut niveau de maturité et de cohérence dans l’ensemble des groupes informatiques et métiers de la société.
« Les responsables d’ICT ont été d’avis que la mise en place d’une méthodologie unique applicable au développement et à la gestion de programme et de projet informatiques faciliterait l’échange entre les groupes d’exploitation des différents pays et permettrait par conséquent d’optimiser la flexibilité et la capacité de l’organisation à s’adapter à l’évolution des tendances du marché » a expliqué Franky Paul, analyste d’entreprise ICT du Groupe KBC. KBC a privilégié deux initiatives permettant de traiter de manière uniforme la documentation des systèmes informatiques et, par conséquent, d’améliorer productivité et professionnalisme.
KBC a tout d’abord mis en œuvre une solution d’architecture d’entreprise contribuant à l’alignement du système informatique et des processus métiers de la société. La société a, par la suite, mis en place un programme de modélisation de ces processus en préambule à l’implémentation des principes de gestion des processus (Business Process Management, ou BPM) destinés à améliorer l’excellence opérationnelle de la société.
Le département ICT souhaite mettre les meilleurs services informatiques à la disposition de l’ensemble de l’organisation, afin de permettre à chaque secteur de gérer ses activités sans problème et de manière efficace. Il est également prévu, dans le cadre de l’optimisation de la productivité, de mettre en œuvre une architecture SOA compatible avec les activités d’intégration et de consolidation.
Une fois ces objectifs précisément définis, KBC a choisi l’architecture d’entreprise et la solution de modélisation de processus de MEGA International. Ce choix a été dicté par la convivialité des produits, par la disponibilité d’outils d’aide à la conception et à la modélisation en général et par l’évolutivité de cette solution.
Aujourd’hui, la solution de MEGA International est appliquée dans l’ensemble de la société, de ses départements et divisions, au fur et à mesure de la mise en œuvre de procédures de gestion des processus plus rigoureuses. Environ 1 200 personnes utilisent actuellement les outils MEGA Architecture, MEGA Process et MEGA Designer au sein de la filiale ICT du groupe KBC.
Suivant la croissance des activités de KBC en Europe centrale, ce chiffre devrait dépasser les 1 500. En outre, le nombre de gestionnaires de processus métiers utilisateurs des produits MEGA au sein du groupe KBC devrait atteindre les 400 au cours des deux prochaines années.
KBC a constaté une amélioration de l’alignement entre départements opérationnels et informatiques, la diminution des discussions et des délais de conception des nouveaux projets et une meilleure compréhension des besoins. Cette évolution a également contribué à optimiser l’utilisation des ressources de la société et l’efficacité des collaborateurs et des équipes.
L’un des principaux avantages de la solution MEGA notés par KBC réside dans la possibilité de modéliser les évolutions potentielles avant leur mise en œuvre, ce qui permet à la société d’éviter les problèmes et d’économiser temps et argent. KBC est désormais en mesure d’envisager différentes alternatives et de choisir en toute connaissance de cause l’option la mieux adaptée et ce, plus particulièrement en matière d’architecture.
« La suite de modélisation MEGA nous a apporté une méthode de modélisation universelle. Il s’agit là de son avantage le plus important – nous travaillons tous de la même manière et nous sommes tous en mesure de comprendre les résultats obtenus par les autres, » remarque en outre Frankly Paul. « La documentation obtenue grâce à la modélisation nous permet de réduire les coûts liés aux changements ou à l’implémentation de nouveaux processus et de résoudre tout problème opérationnel de manière bien plus efficace. »
Ford et Taylor
Le succès de Ford Motor Company s’est nourri des deux premiers échecs de son fondateur : la première tentative en 1899, la Detroit Automobile Company, qui vise la production d’un véhicule bon marché, ne dépasse pas la vingtaine d’exemplaires produits, faute d’une organisation adéquate. Le second essai en 1901, la Henry Ford Company vise le créneau des voitures de course et se révèle être un véritable désastre au plan financier. Paradoxalement, cet échec renforce l’idée première du fondateur, celle de construire des véhicules minimalistes.
La troisième tentative sera la bonne : la Ford Motor Company est fondée en 1903 et dégage dès le départ des bénéfices confortables. Mais ce n’est qu’en 1909 qu’est décidée la construction d’une usine révolutionnaire destinée à fabriquer la Ford T en grande série. Les résultats dépassent toutes les espérances : le temps de fabrication d’une voiture passe de 15 heures à 1 heure 33.
Les bases du système sont désormais célèbres : la division du processus en opérations simples ne nécessitant pas de qualification poussée et l’apport des pièces à l’ouvrier par des systèmes de manutention.
Dans la foulée des premiers résultats obtenus par Ford, le premier à conceptualiser l’approche Qualité fut sans doute Frederick Taylor qui publia en 1911 son best seller « Principles of Scientific Management ». L’idée maîtresse de Taylor fut de décomposer un processus en étapes mesurables de manière à pouvoir tester l’impact de chaque changement sur la durée du cycle complet.
L’après guerre
La fin de la seconde guerre mondiale fut l’occasion de porter une attention particulière sur l’efficacité de la production et notamment la réduction de la non qualité via le contrôle statistique. Cette époque voit la création de l’American Society for Quality (ASQ) qui regroupe à l’heure actuelle plus de 1100 sociétés et 110 000 membres dans le monde.
L’exemple japonais
Dans la foulée du premier choc pétrolier, les consommateurs américains commencèrent à acheter des véhicules japonais, réputés plus sobres. Ils ne mirent pas longtemps à constater que ces voitures importées étaient également plus fiables, de meilleure qualité et moins chères à entretenir. A l’étude, l’écart de performance s’avérait même spectaculaire : comparé à l’usine General Motors de Framingham, il fallait à l’usine Toyota de Takoaka 2,5 fois moins de temps et 40% de place en moins pour 3 fois moins de défauts à la sortie (source : IMMP World Assembly Plant Survey, 1986), le tout en fonctionnant avec un stock moyen de pièces détachées de 2 heures de production contre 2 semaines pour l’entreprise américaine.
Le paradoxe est que ce résultat fut en partie le fruit du travail d’un Américain, Edwards Deming, envoyé par son gouvernement à la fin de la guerre et qui travailla à l’optimisation des méthodes de production des constructeurs nippons. Dépassant les standards américains en la matière, Deming convainquit les Japonais de mesurer la performance à tous les stades du processus et à étendre les efforts de contrôle Qualité aux sous-traitants.
L’ensemble de ces techniques aboutit à une nouvelle conception de la production de masse appelée lean management .
A la fin des années 80, les Américains firent de gros efforts pour rattraper leur retard et l’on vit apparaître et mettre en pratique de nouvelles méthodes d’amélioration de la performance : contrôle statistique (SPC), Qualité Totale (TQM) et Production en juste à temps (JIT manufacturing).
ISO, Six Sigma et Balanced Scorecard
Pour encourager ces efforts fut créé en 1987 un prix national de la Qualité, le Malcolm Balridge National Quality Award, en référence au Deming Award japonais.
Au plan international, l’International Standards Organisation (ISO) publia une première série de normes de contrôle Qualité en 1994 alors que se développait dans le sillage de Motorola, la méthode Six Sigma centrée sur le contrôle statistique de l’amélioration de la performance. Cette méthode prit réellement son envol à partir de 1995 quand elle fut mise en œuvre à grande échelle chez General Electric.
En 2000, l’ISO publia une nouvelle version de ses normes, désormais centrée sur l’approche processus, la satisfaction client et le contrôle permanent de la qualité.
L’avénement des technologies informatiques et l’essor de l’Internet accentuèrent le besoin de pilotage et de réactivité et les outils de Business Process Management se développèrent en même temps que l’approche de Balanced Scorecard,rendue populaire par par deux professeurs du MIT, Norton et Kaplan, et qui fait le lien entre processus et stratégie de l’entreprise.
UML facilite l’écriture des spécifications, déterminantes pour la réussite d’un projet logiciel. L’expression des exigences doit ainsi être lisible, faciliter les tests et l’évaluation qualitative, et rendre possible le suivi des décisions de conception. Cet ouvrage expose clairement les techniques de spécification par les cas d’utilisation et de modélisation métier en UML 2. On apprendra à choisir une méthode (XP, UP…) et des outils adaptés permettant de fédérer le travail des équipes. Enfin, l’ouvrage présente un processus itératif d’adoption d’UML, respectant les bonnes pratiques de conduite du changement.
Auteurs : Franck Vallée, Pascal Roques
Référence ISBN : 2212116217
Le cours magistral de Pascal Roques plébiscité par les étudiants et les professionnels pour comprendre et utiliser UML.
Réédition au format semi-poche de la 6e édition du livre culte de Pascal Roques consacré à UML 2, ce support de cours exemplaire enseigne à travers de nombreux exercices corrigés et études de cas une démarche méthodique de modélisation UML, tant sur les axes fonctionnel que statique et dynamique.
Chaque choix de modélisation est minutieusement commenté et accompagné de conseils issus de l’expérience de l’auteur. Un glossaire reprend en fin d’ouvrage les définitions des principaux concepts et une étude de cas complète illustre le processus itératif de modélisation depuis la modélisation métier jusqu’à la conception en Java et C#.
Sommaire
– Introduction
– Point de vue fonctionnel
– Point de vue statique
– Point de vue dynamique
– Conception
– Annexes
Publics : dirigeants, cadres dirigeants, responsables de projets, managers ou étudiants
Auteurs : Pascal Roques
Référence : EAN13 : 9782212133448
Site: Consulter la fiche-produit du livre
Editeur : Eyrolles
Famille : Automatisation/intégration
Acronyme : Unified Modelling Langage
Définition BPMS
Le langage UML (Unified Modelling Language) est un langage de modélisation basé sur un méta-modèle et un formalisme rigoureux proposant une démarche de modélisation basée sur l’élaboration itérative de modèles, surtout utilisé dans le domaine de l’ingéniérie.
Avec plus de 6 400 collaborateurs dans le monde dont 300 dans l’IT répartis sur cinq sites (Shanghai, Bucarest, Paris, Montréal, San Francisco), Ubisoft est la 2ème force de production de jeux vidéo dans le monde (24 studios dans 17 pays).
Face à l’évolution constante du secteur des jeux vidéo, Ubisoft doit s’adapter rapidement pour répondre aux besoins du marché. Les technologies de plus en plus complexes doivent être maitrisées car elles sont stratégiques pour l’entreprise. Un Système d’information performant devient alors un élément clé et différenciateur face à la concurrence.
Quels ont été les besoins exprimés à l’origine du projet ?
La culture Ubisoft est orientée sur la créativité, l’originalité et l’innovation. De ce fait, l’agilité et la performance du Système d’Information s’impose de plus en plus comme un facteur clé de succès. L’enjeu de la société est de disposer d’un Système d’Information plus structuré et plus homogène afin de le maîtriser et de s’adapter aux besoins métiers.
L’origine du projet était de réaliser une cartographie applicative et identifier les flux applicatifs de manière à répondre à la complexification du métier et à la réactivité imposée par le secteur.
David Trillaud, responsable de la cellule Architecture d’Ubisoft commente : « Les filiales ont une grande indépendance opérationnelle et ont donc pu au fil des ans déployer des applications non connues et non maîtrisées par l’IT siège. L’interconnexion de tous les systèmes grandissant, les équipes centrales se devaient de connaître précisément les systèmes pour déterminer au mieux l’ensemble des enjeux et des impacts des projets en cours et à venir« .
Quel sont les objectifs du projet Cassini ?
Afin de répondre aux besoins du marché et aux exigences internes, Ubisoft a entrepris le projet Cassini (famille de cartographes français). Les objectifs de ce projet sont multiples :
Meilleure visibilité et maîtrise du Système d’Information
– Avoir des inventaires à jour
– Rendre l’information disponible
Partage de connaissance entre l’IT et les métiers
– Centraliser l’information
– Baser la documentation sur des sources uniques
– Eviter les redondances et incohérences
Outil d’aide à la décision (Réaliser des analyses d’impacts au niveau stratégique et opérationnel)
– Le premier besoin exprimé : mieux maîtriser les impacts d’un projet
– Etre capable d’établir des liens/croisements d’informations, qui étaient jusque là difficile voire impossible à faire de manière fiable et pérenne.
L’objectif final est de réaliser un projet d’Architecture d’Entreprise. Le projet Cassini est une « simple » brique de base qui propose une cartographie des différents aspects de l’entreprise en relation avec l’IT : processus métiers, applications et infrastructures techniques.
« Le projet Cassini vise des objectifs très opérationnels dans un premier temps et s’étendra vers une vue plus stratégique dans un second. Le tout servira à l’établissement d’un projet d’Architecture d’Entreprise« , explique David Trillaud.
Comment s’est déroulée la phase de choix de la solution ?
Suite à une sélection et une analyse de quatre outils sur le marché de la modélisation, Ubisoft s’est orienté vers la suite Corporate Modeler de Casewise.
« Nous avons également participé aux Clubs Utilisateurs Casewise afin de rencontrer des clients et échanger autour de la solution Corporate Modeler et de leurs projets d’Architecture d’Entreprise« , commente David Trillaud.
Un ensemble de critères a été fixé permettant ainsi de noter les différents éditeurs et leurs outils. Les critères déterminants identifiés étaient :
Sur l’éditeur
– Environnement international
– Support multilingue
– Références internationales
– Consulting multi-sites
Sur l’outil de modélisation
– Génération automatique de diagrammes : import des données dans la base et diagramme automatique
– Graphique design paramétrable : charte graphique adaptable
– Souplesse du méta modèle : langage adaptable
– Capacité d’importer / exporter des données (Access, Excel, Visio,…)
David Trillaud ajoute : « Quand bien même l’intérêt premier d’un Référentiel de cartographie est son contenu, l’aspect visuel donné à ce contenu est primordial pour Ubisoft. En effet, au sein d’une entreprise qui crée des univers très riches, les équipes IT sont également challengées sur l’aspect visuel et ergonomique de ses projets (charte graphique, fonctions « web 2.0 », …)« .
Comment s’est déroulée l’implémentation ? Quelles ont été les étapes clés du projet ?
« Le projet Cassini a démarré chez Ubisoft plus comme une expérimentation qu’un vrai projet structuré. Une personne à mi-temps pendant quelques mois a bâti l’ossature du futur projet, collectant une multitude de besoins, identifiant sources d’information mais aussi manques d’information. Le projet avait pour but initial d’être un projet purement IT mais a rapidement pris de l’ampleur en termes de périmètre (de cartographie applicative à cartographie des infrastructures et des processus). Une fois la pré-étude validée, le projet a réellement commencé avec 2 personnes formant l’équivalent d’un temps plein et demie pour mettre en oeuvre l’outil et initialiser le Référentiel » explique David Trillaud.
Lors de la mise en oeuvre du projet, Ubisoft a choisi de construire son Référentiel d’Entreprise par démarche itérative et par opportunité projet. La démarche itérative est pilotée par l’équipe centrale de l’Architecture d’Entreprise.
Chaque projet représente une opportunité pour compléter le Référentiel (la cartographie) en l’occurrence les trois premiers projets identifiés ont été :
– Projet pilote CRM Marketing
—– Contexte : redistribution de responsabilité IT sur un grand nombre d’applications locales ou centrales
—- Identifier toutes les applications et les flux interapplicatifs
—- Identifier les macro-fonctions servies par ses applications
– Salle Réseau Montréal
– Contexte : Construction d’une nouvelle salle réseau
—- Identifier tous les matériels
—- Automatiser leur ajout/mise à jour dans le Référentiel Cassini
—- Produire des cartes automatiques de représentation des racks
– Architecture technique des applications clés de l’entreprise
—- Contexte : uniformiser la documentation
—- Se baser sur des inventaires techniques automatiques
—- Produire des diagrammes riches en information technique
David Trillaud commente : « la plus grande difficulté est d’établir un socle général qui permet de démarrer ensuite chaque projet. Il faut à la fois servir le besoin du projet tout en prenant garde à ne jamais perdre de vue la perspective globale. Cela nécessite un permanent jeu d’équilibre, d’autant plus difficile lorsque le nombre d’interlocuteurs augmentent et que les structures plus ou moins autonomes doivent alimenter et valider les différents concepts à modéliser ».
Deux règles d’or font foi dans le projet, sous forme de 2 questions simples :
– A quoi servirait une donnée qui est demandée dans le Référentiel ? (quelle analyse effectuée dessus et/ou quelle représentation graphique ?)
– Comment maintenir la donnée à jour dans le Référentiel ?« .
Quels sont les bénéfices et livrables clés du projet Cassini ?
Méthodologie : Identification et structure du Référentiel
– Evolution progressive du modèle en fonction des projets / données traités
– Mise à disposition de bonnes pratiques pour les diagrammes produits manuellement
Un langage commun : Faciliter la communication
– Le projet Cassini définit un langage dans un contexte donné.
– Chaque objet / attribut / association a une définition unique.
– Le modèle actuel contient environ 30 objets types et 40 associations.
Cartographie des différentes couches
– Une quinzaine de templates (représentations graphiques) sont définis couvrant divers aspects : processus, organisation, inventaire applicatif, architecture technique, architecture de réseau, …
– Environ 300 diagrammes ont été produits (environ 50% manuellement et 50% automatiquement)
Intranets
– 2 intranets produits (l’un à un accès limité contenant des informations techniques sur les réseaux d’Ubisoft)
Quelle est la prochaine étape de votre projet ?
David Trillaud répond : « L’objectif est maintenant d’intégrer de plus en plus d’acteurs IT d’Ubisoft dans le Référentiel pour alimenter le socle commun mis en place. La phase de démarrage arrive à sa fin et le mode production démarre. Il faut créer un cercle vertueux d’intérêt autour du Référentiel. »
Les objectifs à 6 mois sont :
– Un inventaire d’infrastructure très riche (structure réseau, gestion des stockages, …) – Un inventaire applicatif / flux inter-applicatif en constante progression
– La mise en place d’une méthode de modélisation de processus qui se généralise«
Famille : Performance
Acronyme : Total Quality Management
Définition BPMS
Ensemble des méthodes et outils visant à augmenter la satisfaction du client et à réduire les coûts en supprimant tous les points faibles des processus métier. Il porte, entre autres, sur la satisfaction du client, les résultats de l’entreprise, sa part de marché, la productivité, les coûts et la durée de cycle des produits. Cette démarche est plus poussée que la SMQ.
La sortie de Togaf v9, la nouvelle version du cadre d’architecture de l’Open Group, a été couronnée de succès. Lors de l’événement de lancement, les débats ont notamment porté sur les apports du modèle d’architecte pour les entreprises touchées par la crise.
Le lancement de Togaf v9, la nouvelle version du cadre d’architecture d’entreprise de l’Open Group, a été couronné de succès malgré la récession qui planait sur cette semaine de travail à San Diego début février 2009. En guise de synthèse témoignant de la maturité des débats et de l’apport de Togaf, voici un résumé des derniers échanges qui se sont poursuivis dans les salons de l’aéroport.
Le contexte est connu de tous : bien que les entreprises et leurs SI doivent se transformer et offrir toujours plus de services pour affronter la crise, les budgets des DSI, jugés à tort ou à raison trop élevés sont réduits. Face à cette situation, nous étions d’accord pour rappeler les pistes déjà ouvertes par les architectes et par les DSI.
Le mot rationalisation a souvent été porté par les architectes de tout bois : les urbanistes rêvent depuis des années de poser des modèles métiers qui seraient partagés par l’ensemble des lignes métiers ; intention louable pour éviter que le « client » porte autant de définitions que de lignes métiers… ce qui inévitablement implique autant d’applications que de lignes métiers pour en analyser le comportement et les tendances (data mining).
Les architectes techniques ne sont pas en reste, ils portent volontiers le même discours, arguant que le nombre de serveurs et la complexité des infrastructures vont de pair avec la non standardisation des données et des fonctions métiers qui induit la non mutualisation des infrastructures. Ces intentions louables ont peiné à rationaliser l’information et les systèmes d’information car elles s’appuyaient sur des modèles prescriptifs assez rigides et souvent déconnectés voir en retard sur les projets ou les attentes des métiers.
Lors d’un récent forum, les DSI se demandaient si le monde du Web 2.0 avec ses nouveaux modes de travail collaboratif, ses nouvelles stars et les services associés (cloud computing …) allaient leur permettre de répondre plus vite et pour un coût réduit aux besoins de leur entreprise. La réponse est bien évidemment oui … mais la mise en œuvre est une autre affaire car elle remet en cause bon nombre d’habitudes, de méthodes de travail … et de prescriptions.
C’est en analysant ces deux tendances que l‘on en est venu à expliquer simplement ce qu’apportent l’architecture d’entreprise et le Togaf aujourd’hui. Le cadre de méthode proposé aujourd’hui par l’Open Group fait entrer l’architecture d’entreprise dans le monde 2.0. Pourquoi ?
En passant d’un mode prescriptif à un mode descriptif (le « content framework » – cadre de description de l’architecture) et collaboratif (le processus d’architecture d’entreprise ou ADM – Architecture Development Method), le Togaf se pose en méthode de travail et de management moderne.
Ainsi posée, l’architecture d’entreprise 2.0 règle 2 problèmes majeurs : la contribution directe aux métiers et la possibilité de rationaliser.
– La contribution directe aux métiers car la collaboration s’effectue dans le cadre d’une réponse à un besoin de l’entreprise : un nouveau service ou une nouvelle offre, l’alignement à un nouveau principe métier tel que la mutualisation de services ou de ressources. Cette architecture collaborative est doublement efficace car elle traite le besoin d’évolution qui donnera lieu à des projets et elle décrit ses résultats et ses livrables dans un cadre collaboratif et réutilisable (notamment les architectures building blocks). Notre débat quasi philosophique a même débordé un instant sur la solidarité apportée par ce mode de travail dans lequel un projet ou un programme contribue au développement durable sous forme de modèles d’architecture ou de services réutilisables … ce qui est plus agréable qu’une dette symbolisée par une complexification du SI ou l’opacité d’une boite noire.
– La rationalisation est enfin un résultat atteignable puisque chaque programme de transformation a contribué à remplir le « cadre de description » du système d’information de l’entreprise. Il ne s’agit plus de dépenser un effort aussi important que vain pour maintenir un référentiel à jour. Tout nouveau programme sera donc enclin à réutiliser ce qui a été décrit ou pour le moins étudiera cette possibilité notamment parce qu’il appliquera ainsi les principes d’architecture de l’entreprise éco-responsable (mutualisation, c’est-à-dire réduction du nombre de serveurs, de firewall ou mutualisation de services d’infrastructure).
Il n’a échappé à personne qu’en travaillant ainsi, les budgets sont réduits au rythme de la rationalisation, de la simplification des infrastructures et de la mutualisation des services. Par ailleurs, l’expérience a montré qu’ainsi la qualité de service augmentait au rythme de l’industrialisation des infrastructures.
Nous étions prêts à nous quitter, convaincus d’apporter une brique essentielle à la professionnalisation des DSI… Une chose restait à faire : doper l’architecte d’entreprise aux « soft skills », ces qualités de communication et de leadership nécessaires pour accompagner l’entreprise dans sa transformation d’un mode de travail en silos à une mode de travail collaboratif en réseau associant direction générale, métiers et DSIO.
Auteur : Eric Boulay représentant de l’Architecture Forum France – PDG, Arismore
Source :JDNet
Le cadre d’architecture de l’Open Group prône l’instauration d’une collaboration entre les chefs de projet métier et technique. Une configuration qui, selon les experts, permet une accélération du déploiement de nouveaux processus.
Elaboré au milieu des années 1990, le Togaf (pour The Open Group Architecture Framework) est reconnu aujourd’hui comme un standard industriel. Ce cadre d’architecture porté par le consortium Open Group fait l’objet de mises à jour régulières (sa version 9 est attendue pour 2009). Une certification à destination des consultants est proposée par l’organisme.
Indépendant du secteur d’activité, Togaf n’impose pas de modèle de formalisation d’architecture, mais en recommande en revanche l’utilisation. Sa mise en œuvre n’est donc pas antinomique avec l’utilisation de méthodes de conception d’architecture, comme Zachman ou tout autre infrastructure métier formalisée.
Togaf propose une démarche de conception et de gouvernance des architectures d’entreprise. « Elle est comparable à l’ingénierie simultanée dans le domaine industriel.
Cette méthode consiste à faire travailler en parallèle les équipes de conception et de fabrication en vue d’accélérer les processus de mise sur le marché des produits », explique Eric Boulay, PDG d’Arismore et représentant de l’Architecture Forum France
Togaf désencalve le travail des urbanistes en le remettant au centre de la gouvernance du SI
L’objectif de Togaf est bien de désenclaver le travail des urbanistes en le remettant au centre de la gouvernance du système d’information.
« Pour être pertinente, la cartographie de l’organisation de l’entreprise, de ses processus, et de ses systèmes, doit être élaborée de manière à ce que les équipes technique et métier puissent partager des vues différentes d’un élément unique en fonction de leurs compétences et leur place dans le projet », détaille Eric Boulay.
A chaque étape d’un projet d’architecture, Togaf recommande ainsi un travail conjoint entre l’informatique et les métiers : de l’analyse de l’organisation d’entreprise, à l’urbanisation de l’architecture du système d’information (technique, fonctionnelle…) et la définition des référentiels d’exigences.
Et une fois la mise en œuvre du chantier lancée, Togaf conseille de vérifier que le projet reste bien aligné sur les objectifs de l’entreprise.
« A chaque étape de la roue du Togaf, il est important que les deux profils, technique et métier, soient présents. Il est vrai qu’il n’est pas possible d’être totalement séquentiel. En fonction des phases, les uns peuvent être naturellement plus présents que les autres », commente Eric Boulay.
En cohérence avec cette logique, Air France a adopté un modèle de gouvernance inspiré de Togaf dans le cadre d’un projet d’architecture de services (SOA) lancé en 2006. Objectif affiché : privilégier la collaboration, domaine métier par domaine métier, entre architecte métier et architecte SI, dans l’optique de mieux maîtriser les processus transverses.
« Ainsi, ces ‘binômes’ d’architectes peuvent faire émerger et maîtriser les collaborations entre domaines métiers et vers l’extérieur, des collaborations outillées et exposées grâce à l’approche SOA sous forme de services métiers normalisés et réutilisables », nous indiquait Jean-Baptiste Ceccaldi, directeur général de Vistali, société de services ayant épaulé Air France dans le projet « SOA : Air France-KLM donne des ailes à son SI ».
Source : Antoine CROCHET-DAMAIS
The Open Group
9.1
Architecture d’entreprise
www.opengroup.org
Méthode et cadre d’architecture, TOGAF fût publié dans une première version dérivée du Technical Architecture Framework for Information Management (TAFIM) en 1995. Cette première version, orientée architecture technique a, au fil des années, évolué vers un canevas plus propice à la gestion de l’évolution de l’architecture d’entreprise au sens large.
La définition et/ou l’adaptation des livrables sont les premières étapes de la mise en œuvre de cette méthode :
– Utilisation de différentes notations, différents diagrammes
√ Propriétaires, c’est-à-dire propres aux différents outils de référentiel d’architecture d’entreprise comme Aris, Corporate Modeler ou MEGA
√ Standardisés, tels qu’UML, avec un profil TOGAF dédié
– Adaptation de la structure des livrables aux besoins de l’entreprise
Ce sont ces différents points transversaux à l’ensemble des projets instanciant un cycle de la méthode couplés à une volonté de valorisation du contenu produit par ces derniers qui constitue la gouvernance de l’architecture dont le cadre est également proposé par TOGAF.
Cadre générique adaptable à des entreprises de secteurs variés.
Difficulté d’appropriation, la première itération (adaptation et projet pilote) représentant une barrière d’entrée assez élevée.
Famille : Organisation
Acronyme : The Open Group Architectural Framework
Définition BPMS
TOGAF est un référentiel d’architecture de l’Open Group qui permet de concevoir, évaluer et développer des architectures informatiques.
Famille : Organisme
Termes équivalents : X/Open Company
Définition BPMS
L’Open Group (à l’origine la X/Open Company) est un consortium industriel de plus de 400 sociétés fondé par IBM, Sun Microsystems, Hitachi, Hewlett-Packard et Fujitsu qui définit certaines normes dans le domaine de l’ingénierie informatique pour développer l’utilisation de standard technologiques ouverts.
Il est notamment à l’origine du référentiel TOGAF.
Comment obtenir une synergie entre les différents acteurs de l’entreprise, pour avoir une vision commune des objectifs, du métier, des procédures, de l’organisation, du système existant et des évolutions en cours sur le SI ?
Le problème n’est pas mince : il se heurte à la diversité des domaines et des expertises, et plus encore aux problèmes de communication entre acteurs de cultures et de préoccupations différentes.
Il n’est pas simple en effet de faire une synthèse entre la vision des dirigeants, des utilisateurs, des spécialistes métier (MOA) et des équipes informatiques (MOE).
Certains ont des réticences à formaliser le fonctionnement de l’entreprise : après tout, l’organisme humain fonctionne sans que l’on ait une claire perception de ses mécanismes. Il est par ailleurs vain, voire contre-productif de présenter un diagramme de classes UML à un dirigeant ou à un utilisateur.
La pré-modélisation consiste à fournir les moyens informels, notamment à destination des acteurs non techniques, pour permettre une première formalisation, sur laquelle des décisions et orientations peuvent être prises, à partir de laquelle des modèles plus détaillés peuvent être bâtis, eux-mêmes pour des objectifs spécifiques (MOA, MOE, etc.). Ces « pré-modèles » ne se traduisent pas de manière mécanique en modèles plus détaillés et formels (sur lesquels on peut par exemple faire des simulations, des générations de code, etc.). Ils constituent plutôt une référence justifiant et guidant la construction de modèles détaillés. Ils fournissent une base terminologique, un guide sur la structuration, sur lesquels s’appuieront les éléments de modèle plus précis. Nous allons présenter quelques exemples de ces pré-modèles, qui sont des éléments compréhensibles sans nécessiter d’explications complexes sur le formalisme.
Le succès ou l’échec d’un développement se jouent essentiellement lors des phases amont de la construction d’un système, étape où la pré-modélisation joue un rôle essentiel. C’est là où les acteurs principaux qui déterminent les choix fondamentaux – les décisionnaires, les utilisateurs, les maîtres d’ouvrage – bâtissent l’objectif stratégique ; c’est là où le contour du domaine à traiter, et où les engagements fonctionnels, budgétaires, de planning, et architecturaux apparaissent. À ce stade, l’enjeu est de définir des objectifs compris par tous, réalistes, recouvrant exhaustivement la vision initiatrice du projet.
Face à une analyse préliminaire réussie, à une liste d’exigences bien formalisée et à une définition du domaine suffisamment complète sur laquelle les acteurs se sont accordés, la réalisation du développement permet d’isoler et de réduire les risques qui pourront être maîtrisés.
Les phases préliminaires, cibles de la pré-modélisation
Il est nécessaire de définir les domaines d’application sur lesquels un système doit être mis en place et les processus que le système doit instrumenter. La portée du système doit être illustrée, en termes de domaine couvert, de décomposition initiale en sous systèmes, d’interface avec l’extérieur, etc. La terminologie, les définitions et le contour du domaine sont clarifiés, afin de poser le problème dans un contexte clair. Dans ce domaine, les modes de fonctionnement doivent être explicités, sous forme de procédures métier, mais aussi sous forme de règles et contraintes métiers. L’existant doit être analysé, en étant représenté comme un système dont on montre la structure, les rôles, les responsabilités et échanges d’informations internes ou externes. On cherche à collecter toute l’information préliminaire, que celle-ci soit sous forme de documents, de modèles, de formulaires ou de toute autre représentation. On explicite la nature des produits élaborés par les processus.
Face à cette analyse, il faut ensuite identifier les points faibles, les points à améliorer ou les nouveaux points à introduire constituant la base de la définition du futur système. Le terme « système » est à prendre ici dans son sens le plus large : c’est l’ensemble de l’organisation permettant de fournir un service, d’effectuer des traitements et opérations.
Il s’agit d’une organisation humaine, matérielle, dont seule une partie est assumée par le logiciel. La définition des fonctions à assumer par le logiciel, qui peut être développé spécifiquement ou repris sur étagère, ainsi que l’articulation des responsabilités entre le logiciel et les autres acteurs appartient à la phase préliminaire.
À ce stade, les représentations de l’existant sont reprises, pour présenter le système conformément à la vision et aux objectifs d’évolution.
Dans la phase préliminaire, un enjeu majeur consiste à utiliser des représentations permettant un dialogue entre les parties impliquées comme les utilisateurs, les analystes, les responsables hiérarchiques et les experts du domaine.
L’emploi exagéré de techniques de modélisation comme UML constitue un obstacle à la compréhension pour certains intervenants, et ira à l’encontre de leur implication dans la modélisation ou les revues.
A contrario, l’absence d’une méthode rigoureuse de représentation empêchera la collecte d’une information précise, cohérente et pertinente, que l’on peut abstraire ou détailler selon les niveaux de dialogue. On en viendra donc à combiner plusieurs techniques, pour adresser spécifiquement chaque type de problème, mais aussi pour fournir des représentations compréhensibles par les diverses catégories de personnes impliquées dans les phases amont.
La phase préliminaire fournira des représentations qui constitueront la base d’un contrat pour les acteurs de l’évolution d’un SI : MOA et MOE.
Cette dimension contractuelle renforce encore la nécessité que tous puissent comprendre et partager ce que le contrat exprime. Elle introduit un mode de gestion très particulier des livrables issus de cette phase :
Le rappel « littéraire » de l’expression de besoin initiale est une partie importante de ce contrat : il sera souvent nécessaire de s’y référer pour faire des choix (et reposer les pieds sur le sol) lorsque l’on sera accaparé par les difficultés techniques et pratiques de la réalisation.
Techniques de pré-modélisation
Vue générale
Il est dangereux de produire prématurément des modèles. La modélisation impose une vision « formelle » du problème, détermine des choix qui peuvent s’avérer prématurés, et produit facilement un assemblage de boîtes et de liens non représentatifs de la réalité du problème et des objectifs. Il est avant tout fondamental de répertorier une information pertinente sur la nature du problème à traiter et sur les objectifs.
En revanche, il est très intéressant de réaliser des modèles, car ils formalisent le problème, structurent le cadre du développement, et permettent d’identifier des manques de l’analyse préalable en contraignant l’analyste à décrire l’implicite, et à considérer les aspects significatifs du processus. Ils permettent de rendre cohérente une base initiale trop informelle. Outre la formalisation nécessaire à la réalisation du logiciel, le modèle apporte aussi au métier la maîtrise de ses propres concepts et l’explicitation de ses procédures.
La Figure 1 montre qu’il est ainsi nécessaire d’associer plusieurs techniques informelles ou formelles de modélisation, pour pouvoir saisir toutes les facettes d’un problème sans le dénaturer, et ensuite les détailler dans un modèle central, qui peut être raffiné et retravaillé jusqu’à l’implémentation.
À titre d’exemple, la construction d’un modèle peut débuter par le recueil des objectifs, des exigences et du dictionnaire d’un système, pour se poursuivre par un modèle initial des procédures métier et un modèle des notions du domaine, qui seront tracées par rapport au dictionnaire et exigences initiales. Ensuite, un modèle de cas d’utilisation permettra par exemple d’isoler l’exploitation du système d’information au sein du système global, tracé et déduit des procédures métiers et des exigences. Enfin, le modèle applicatif sera lui-même tracé sur ces modèles initiaux.
La Figure 2 illustre un cycle de développement pouvant être pratiqué pour itérer des modèles les plus informels au modèle complet et formel. Des intervenants non informaticiens peuvent intervenir sur les représentations informelles.
Sans prétendre à l’exhaustivité, les techniques les plus fréquemment utilisées sont présentées ci-dessous. En pratique, elles sont employées selon un grand nombre de variantes, y compris dans leur dénomination. On assiste cependant, et pour chacune d’entre elles, à des mouvements d’uniformisation et de consolidation, se traduisant soit par des outillages ayant des fonctionnalités similaires, soit par des livres dédiés à ces pratiques, ou même des efforts de standardisation comme ceux de l’OMG1 sur l’approche « system engineering », « business rules », ou encore « Business Motivation Metamodel ».
L’ensemble des informations recueillies par le biais de ces techniques permet d’initier le référentiel du système. Le référentiel permet d’identifier les éléments présents dans le système d’information, ainsi que de fournir des nomenclatures et les identifiants qui seront constamment exploitées et référées sur l’ensemble du cycle de vie des développements et évolutions du système.
Un effort particulier doit être entrepris pour obtenir, de la part de l’ensemble des parties prenantes relatives au système et à ses évolutions, la validation et l’appropriation des modèles et informations recueillis. Des outils spécifiques sont nécessaires pour présenter le modèle aux divers niveaux des responsables hiérarchiques des métiers de l’entreprise, ainsi que pour le présenter aux utilisateurs finals et leur permettre de comprendre l’organisation du système ainsi que le rôle que chacun des utilisateurs doit remplir.
La gestion de la traçabilité est un élément important dans l’ensemble de l’approche. La mise en oeuvre simultanée de techniques différentes impose en effet de gérer la cohérence globale, de garantir la complétude de chacune des facettes, et de permettre des vérifications croisées.
Les standards de modélisation UML et BPMN apportent une assistance importante pour la prémodélisation. Cependant, ces modèles ne couvrent pas tous les besoins pour ces phases, où des extensions et des techniques complémentaires sont nécessaires. Le Tableau ci-dessous montre de manière synthétique le degré de support que UML et BPMN fournissent pour les techniques de modélisation des phases amont. Il existe des ateliers supportant l’ensemble, UML, BPMN et les parties non couvertes par ces standards. La technique des profils UML permet par ailleurs d’avoir des extensions et des supports dédiés à la prémodélisation.
Dictionnaire
La technique du dictionnaire est la plus simple et la plus immédiate à appliquer. Bâtir un dictionnaire, c’est tout simplement répertorier les termes propres à un domaine d’application, et en produire la définition. C’est un travail fondamental, toujours utile, pouvant être entrepris dès le début. La terminologie d’un domaine est une connaissance essentielle, préliminaire à toute décision fonctionnelle et tout choix d’implémentation, qui bénéficie d’une très grande stabilité une fois finalisée. Il n’appartient pas aux développeurs mais bien plus aux spécialistes du domaine de définir la terminologie d’un domaine. Une fois établi, le dictionnaire est un guide précieux pour les développeurs, qui pourront en extraire un nommage cohérent du modèle. Il constitue un outil de mesure de complétude et de pertinence des modèles, en exploitant la traçabilité entre un dictionnaire et un modèle. Le dictionnaire peut être tolérant dans son recueil de terminologie : il accueille la diversité des vocabulaires qui coexistent dans l’organisation ou le domaine. Le modèle devra opérer une réduction terminologique en choisissant de ne nommer qu’une seule fois une même chose ou un même concept.
Analyse des objectifs et des besoins
La notion d’objectif est à distinguer de celle de besoin. Un objectif est défini en général qualitativement sur du long terme, en ayant une portée large et pouvant être obtenu de nombreuses manières différentes. Un objectif fournit des moyens de mesurer sa satisfaction, mais n’exprime pas par qui ou quoi il doit être appliqué. Un besoin doit être satisfait par quelque chose d’identifié, il intervient a un niveau plus bas que les objectifs. La décomposition des objectifs est un moyen d’identifier des besoins. Formalisé sous forme d’un identifiant (nom, numéro…) et de quelques phrases courtes exprimant le besoin, il possède un ensemble de propriétés (priorité, origine, etc.) qui permettent de le gérer. Les besoins ont très souvent une nature contractuelle : leur identification, gestion, traçabilité est fondamentale pour gérer leur évolution, et pour mesurer la couverture et le respect d’un modèle relativement aux besoins. La traçabilité exprimée entre des besoins et un modèle permet par ailleurs d’établir des mesures d’impact pour, par exemple, connaître les modifications induites par l’évolution d’un besoin.
L’expression des besoins peut par exemple aider à identifier ou à justifier la présence des processus. On identifiera des besoins externes, comme par exemple les besoins des clients relatifs aux services d’une organisation, des besoins internes comme par exemple respecter des contraintes de qualité, légales, de traçabilité, et des besoins dit « non fonctionnels » relatifs aux performances du système, à leur disponibilité, aux taux d’erreur toléré, etc. L’analyse des besoins peut être conduite suivant des méthodologies spécifiques, qui procureront des classifications en types de besoins (exemple : fonctionnels, non fonctionnels, ergonomiques, etc.), et attacheront de nouvelles propriétés à un besoin. S’appuyant sur une définition du domaine et du métier apportée par le dictionnaire, sur les règles métier, et sur la modélisation des processus métiers, l’analyse des besoins exprime les motivations conduisant au développement ou à l’évolution d’un système.
Approche systémique
Pour les systèmes de grande ampleur, où bien souvent un existant est à prendre en compte, il est nécessaire de construire des schémas généraux qui transcrivent une vision globale des constituants d’un système, et de leur mode de coopération. Sur ces schémas, il est important de construire un dialogue et d’avoir l’approbation de tous. Le modèle d’organisation représente les structures de l’entreprise impliquées dans les processus métier avec les échanges d’information. Il met en valeur les responsabilités des sous-systèmes représentés.
UML2 introduit la notion de « flot d’information », apportant de nouvelles capacités pour présenter la coopération des sous-systèmes. La Figure 3 est une extension spécifique d’UML2, qui représente l’organisation d’une agence de voyage, avec ses différentes unités d’organisation, et les flux principaux d’information échangés entre ces unités d’organisation et des acteurs essentiels.
La Figure 4 représente les rôles dans l’entreprise et leurs types de liens. Outre le lien hiérarchique, il est utile d’indiquer les relations de travail nécessaire (communication), et d’annoter des responsabilités. Ce type de représentation peut être complété par une vision générale des processus, et une indication des éléments manipulés et communiqués entre processus.
Dans la Figure 5, les processus ont été structurés par les unités d’organisation, ce qui permet de leur assigner une entité responsable.
Modélisation des processus métier
Cette technique est très fréquemment utilisée dans le cadre de développement de systèmes d’information.
Un processus métier est constitué par un ensemble d’activités réalisées par des acteurs afin d’atteindre un but précis. Par exemple, « Souscrire un nouveau compte » pour un système bancaire ou « Traiter un sinistre » pour un système d’assurance sont des processus métier.
Un processus métier décrit le métier, et non le système informatique. Les tâches d’un processus métier peuvent cependant être liées au système d’information, mais c’est une décision qui intervient ultérieurement. On cherche à formaliser les flux et la synchronisation des différentes tâches impliquées dans la réalisation d’un service.
Il est préalablement nécessaire d’obtenir un accord sur la liste des processus relevant du domaine à modéliser. Il faut s’appuyer sur les points fondamentaux, comme typiquement les processus externes, dans lesquels le client ou les partenaires sont impliqués, avant de présenter les processus « internes » parfois plus sujets à débats.
Plusieurs niveaux de représentation peuvent exister, permettant de progresser depuis une première identification comme indiqué en Figure 5, pour ensuite définir une procédure générale non liée à une organisation particulière et enfin aboutir à un processus détaillé, identifiant les responsabilités des tâches dans un processus, les informations échangées, et les conditions de choix précises.
Ici, la pré-modélisation permet d’affiner l’identification des processus et leur positionnement, avant de débuter les activités de modélisation détaillées qui induiront de nombreux choix et décisions.
Règles métier
Les règles métier sont constituées d’un ensemble de règles déterminant le fonctionnement du métier. Ce peut être des règles qui empêchent, provoquent ou permettent le déclenchement de processus, comme par exemple une assertion qui définit ou contraint certains aspects du métier, un terme ou un fait (assertion structurelle) qui fournit des informations sur le métier ou une contrainte régissant les actions et processus au sein du système.
Une règle doit être « atomique », c’est-à-dire qu’elle ne peut pas être re-découpée en « sous règles ».
On peut par exemple considérer le code civil comme un ensemble de règles métier régissant la société. Les règles métier apportent un modèle abstrait, relativement stable1 et indépendant des choix techniques sous-jacents. Elles constituent une vision complémentaire des autres techniques employées en phase préliminaire.
UML fournit la notion de « contrainte », permettant d’associer des contraintes à toutes parties d’un modèle. En adaptant cette notion aux différents types de règles métier (profil UML dédié), UML peut ainsi supporter la représentation des règles, avec l’avantage de les situer dans le contexte des éléments sur lesquels elles s’appliquent.
En préalable à la modélisation UML, les règles métier peuvent être répertoriées, classifiées et structurées, pour être ensuite tracée sur les modèles concernés.
Cas d’utilisation
La technique des Cas d’utilisation (Use Case) est très populaire chez les praticiens UML. Son cadre d’utilisation s’applique au système à développer une fois celui-ci identifié. Son utilisation intervient donc après celle de la modélisation des processus métier, de la définition du dictionnaire, et de la description des règles métier. Par exemple, pour toute activité d’un processus métier qui utilise le système, on doit trouver un ou plusieurs cas d’utilisation permettant de la réaliser.
De nombreux ouvrages ont été publiés sur la mise en oeuvre du modèle des cas d’utilisation, assurant un support méthodologique bien documenté. L’avantage de la modélisation des cas d’utilisation est de permettre une définition externe du système, en identifiant les acteurs pouvant intervenir, et les grands cas de figure de mise en oeuvre du système futur. Un modèle de cas d’utilisation est structurant pour l’activité d’analyse, et pour la modélisation future en UML.
Le modèle des cas d’utilisation s’applique dans un contexte bien défini : le périmètre fonctionnel du système est identifié, et les exigences globales, les objectifs généraux du système sont connus. Son emploi doit se limiter à la découverte « gros grain » des cas d’utilisation, chaque fois associés à au moins un acteur externe, et réalisant à chaque fois une fonction complète (« transaction fonctionnelle »). Parfois, des modèles de cas d’utilisation dérapent en de véritables décompositions fonctionnelles des services du système, ce qui in fine nuira à une bonne modélisation et conception du système. Un modèle général de cas d’utilisation est compréhensible par tous, et peut permettre un cadrage et une validation générale, avant de poursuivre dans une description détaillée de chaque cas d’utilisation.
Ordonnancement de ces techniques de modélisation
L’ordonnancement précis de ces techniques de modélisation s’appuiera sur une méthodologie relevant du contexte de mise en oeuvre. Cela dépend du domaine d’application, de la taille et de l’importance du problème à traiter, et de nombreux autres facteurs. Fréquemment, seule une partie des techniques mentionnées est mise en oeuvre. Plusieurs types de représentation peuvent être construits en parallèle, par une démarche itérative.
La règle est de partir des aspects les mieux connus, les plus généraux, les plus immédiats et les plus stables, pour ensuite détailler progressivement, en recherchant constamment le consensus et l’appropriation des représentations par les autres intervenants. Il importe d’une part de procéder selon l’ordre « top down », en couvrant couche par couche l’intégralité du processus considéré, chaque couche correspondant à une modélisation plus fine que la précédente, et d’autre part de s’interdire de réaliser de façon prématurée une modélisation partielle et détaillée d’un aspect du processus.
Le dictionnaire peut toujours être défini en premier. Il permet de recueillir les définitions existantes sans apporter d’interprétation. L’analyse des besoins intervient également très en amont. Menée conjointement avec l’élaboration du dictionnaire, elle permet de cadrer la terminologie requise.
L’approche systémique offre le moyen de fournir rapidement une vision globale du système.
La définition des modèles conceptuels peut ensuite précéder ou être menée conjointement avec la modélisation des processus métiers. En effet, les processus exploitent les données. Ils se justifient par les produits réalisés, et permettent d’identifier la nécessité de certaines données intermédiaires. Les règles métier viennent enrichir les modèles conceptuels, et les modèles des processus. Les cas d’utilisation interviennent en dernier lieu, en détaillant ce que le système d’information doit effectuer au sein d’un système global.
Conclusion
Une pré-modélisation correctement construite fournit aux acteurs du SI une référence initiale sobre, stable et pertinente.
Le cadrage offert par ces techniques apporte à l’entreprise la maîtrise de ses propres concepts, de son propre langage, ainsi que la clarté sur les priorités : la documentation du dictionnaire, du référentiel, des règles métier, leur appropriation par les utilisateurs, leur validation par les dirigeants, précisent et stabilisent l’informatisation de l’entreprise, améliorent la qualité des réflexions sur son rôle et son évolution.
La pré-modélisation est ainsi à la fois une étape utile à la réalisation technique du logiciel, et une phase nécessaire à la maturité de l’entreprise en matière de système d’information. Intégrée à une démarche d’entreprise, elle assure une vision d’ensemble sur le système non technique et facile d’appréhension, pour permettre à tous d’être partie prenante.
Auteur: Philippe DESFRAY, Directeur Général Délégué,
On ne mesure pas pour contrôler mais pour piloter
Dans la logique de nos entreprises encore porteuses du poids taylorien, nous associons trop facilement les termes « mesure » et « indicateurs » avec « contrôle ».
A l’origine de l’entreprise taylorienne, le mot d’ordre était «on ne peut pas être bon dans tous les domaines, il faut donc être spécialiste». On trouvait (et on trouve encore) ainsi les spécialistes de l’encadrement, les spécialistes de l’exécution et les spécialistes de la mesure pour garantir le fonctionnement global selon un mode prédéterminé. Les trois rôles principaux étant définis par les formules suivantes : « je commande, tu travailles, il mesure et tu seras sanctionné/gratifié selon les résultats ».
Dans un contexte stable, le raisonnement n’est pas réellement critiquable. Lorsque nous travaillions à flux poussé avec très peu de perturbations, nous pouvions axer la gestion sur la planification et les procédures. Dans ce cas, la performance pouvait être estimée en termes exclusivement productiviste et financier. L’objectif demeurant : l’augmentation de la production et la diminution des coûts. Aujourd’hui, bien que le contexte ne soit plus le même, de nombreuses entreprises ne modifient pas leurs habitudes pour autant et persistent toujours (si ce n’est dans le propos, cela reste vrai dans les faits) dans l’application du schéma classique : planification => contrôle => sanction.
Il est aujourd »hui parfaitement avéré que ce système est totalement inadapté à la nouvelle configuration économique caractérisée par le changement rapide et l’imprévisibilité! Il faut passer d’une logique de planification a priori et de constat a posteriori à une logique dynamique et réactive : mesure/action/réaction. Bref, il faut PILOTER ! Avec l’entreprise « réactive », le tableau de bord n’est plus un outil de contrôle mais un instrument d’aide au pilotage pour les acteurs/responsables.
Le tableau de bord n’est pas un instrument de motivation mais un instrument de progrès
Utiliser le tableau de bord et les indicateurs comme objets de motivation est un travers assez courant dans les entreprises. Trop souvent, on présente aux utilisateurs, des indicateurs de performance beaucoup trop généraux et fort éloignés de leurs préoccupations et de leurs moyens d’action. Les tableaux de bord ainsi construits sont purement et simplement inutiles. Si l’utilisateur ne dispose pas du levier de commande pour agir, l’indicateur ne sert à rien. A noter : les incontournables indicateurs mesurant la « satisfaction client » entrent généralement dans cette catégorie.
Il est aussi de tradition de définir les objectifs à atteindre comme autant d’obstacles à franchir, chacun récompensé par une carotte. L’indicateur servant alors de mesure officielle de la performance personnelle. Cette dérive particulièrement courante mérite toute notre attention. Elle se place tout à fait dans la continuité de l’utilisation archaïque du tableau de bord dont nous parlions ci-dessus. Il ne faut pas considérer un objectif comme la barre de saut d’un perchiste placée toujours plus haut par la direction. Il ne faut pas non plus considérer l’indicateur comme un compteur de points acquis. Ce n’est pas ainsi que seront résolus les problèmes de motivation. Un indicateur doit rester un outil d’aide à la décision. Il permet de s’assurer que les actions engagées s’incrivent bien dans la voie de progrès choisie. C’est ainsi que se définit la performance.
Que doit-on mesurer ?
Pour piloter efficacement l’entreprise réactive actuelle, il faut conserver en ligne de mire les 7 axes de mesure suivants :
1- Client
La réussite de l’entreprise passe nécessairement par la satisfaction du client…
2- Actionnaires
…Mais l’entreprise a besoin de capitaux…
3- Partenaires
…Et elle ne travaille plus toute seule, mais en coopération avec d’autres acteurs du monde économique…
4- Personnel
…Si la réactivité et la qualité de services rendus sont les deux clés de l’entreprise moderne, ce sont les hommes qui les détiennent…
5- Public
…Dans tous les cas, il faut prendre garde à conserver une éthique responsable en toutes situations….
6- Processus internes et système qualité
…Ne perdons pas de vue ce que nous sommes, ce que nous faisons et comment nous le faisons…
7- Système d’information
…C’est la clé de voûte de l’entreprise intégrée. La pertinence et la qualité des informations échangées depuis le client jusqu’au dernier fournisseur conditionnent la viabilité de la supply-chain.
Est-ce une nouvelle version de la question de la résolution de la quadrature du cercle ?
Non, car dans l’entreprise, le culte du décideur unique tend à disparaître. On ne placera pas les 7 axes sur un seul tableau de bord. La décision doit être envisagée comme un processus coopératif, où chacun agit dans son domaine de compétences et de prérogatives. Chaque responsable, sur son tableau de bord, suivra le ou les axes le concernant. C’est globalement au niveau de l’entreprise que la performance pour l’ensemble des axes sera appréciée.
Alain Fernandez
Loin d’être un simple outil de mesure, le tableau de bord est devenu un véritable outil d’aide à la décision favorisant un pilotage implicatif et proactif. A ce titre, la notion de reporting est significativement revisitée car désormais, les tableaux de bord sont porteurs de leur propre reporting.
|
Ce phénomène est notamment soutenu par le besoin croissant des entreprises de disposer d’un Système de Management transverse et participatif menant au décloisonnement des acteurs. Au cours de cet article, l’accent sera mis sur l’importance de la mise en œuvre d’une approche processus dans la construction et le déploiement d’un tableau de bord facilitant la prise de décision et véhiculant une dynamique d’amélioration continue.
Il est tout d’abord important de bien différencier tableau de bord et reporting. En effet, le tableau de bord est essentiel à la mise en œuvre de la stratégie. Il permet de mesurer, aux différentes étapes du déploiement de la Vision de l’entreprise qui se traduit dans les objectifs, la performance des activités afin de donner un cap au pilotage. Le reporting, quand à lui, permet de référer au niveau hiérarchique supérieur l’analyse du tableau de bord et de pouvoir vérifier l’atteinte des objectifs annuels tant en termes de moyens que de résultats. En d’autres termes, ce reporting permet d’expliciter et d’analyser les résultats présentés dans le tableau de bord. Un tableau de bord possède quelques qualités fondamentales qui le rendent efficace : – Il ne présente que les informations essentielles pour l’organisation. – Il ne se contente pas de signaler les dysfonctionnements : il délivre des éléments d’explication sur les causes de ces derniers ainsi que leur récurrence. – Il est un véritable outil d’aide à la décision : il contribue à la définition d’une nouvelle tactique d’action. Un tableau de bord est composé d’indicateurs de performance nommés « Key Performance Indicators ». Ces indicateurs doivent respecter un certain nombre de règles essentielles : – Etre alignés sur les objectifs de l’entreprise ou du processus : les indicateurs doivent être porteurs des orientations stratégiques de l’élément analysé. – Etre identifiés en groupe de travail : les acteurs stratégiques et opérationnels doivent s’entendre sur des indicateurs ayant de la pertinence pour les décideurs à tous les niveaux de l’entreprise. – Etre suffisamment explicites pour provoquer une prise de conscience de la part du pilote concerné et ainsi entraîner une ou plusieurs décisions. – Etre en nombre limité : nous sommes sur des indicateurs clé ! – Etre régulièrement réinterrogés et actualisés. Un tableau de bord doit pouvoir permettre de répondre aux questions essentielles d’un dirigeant d’entreprise ou d’un pilote de processus et lui permettre de prendre les bonnes orientations stratégiques pour assurer la croissance de l’entreprise. Afin de mettre en place un tableau de bord efficace et ciblé sur les enjeux, deux facteurs essentiels doivent être réunis et placés au cœur de la démarche : il s’agit de l’implication de la direction et de la responsabilisation des acteurs à tous les niveaux managériaux de l’entreprise.
• L’implication de la direction
Ce premier facteur traduit toute l’importance du déploiement de la Vision managériale : c’est-à-dire les orientations stratégiques prises par la direction se déclinant en objectifs de performance sur différents volets. Le but est d’insuffler à l’organisation une dynamique de progrès afin d’éviter une certaine inertie interne. Ceci implique pour la direction d’être un soutien à l’effort collectif et notamment : – De créer les facteurs de motivation du personnel. – De porter les orientations prises. – D’instaurer une communication claire quant aux objectifs et aux conséquences probables de la stratégie mise en œuvre. – D’élaborer et mettre en place les outils de suivi de la performance de l’entreprise. Un autre constat nous montre que l’implication de la Direction est fortement conditionnée par les « relais charismatiques » de l’entreprise car, de part le leadership qu’ils incarnent, ils sont force de mobilisation autour des objectifs à atteindre. Plusieurs questions se posent alors : comment impliquer ces personnes dans le projet de l’entreprise ? Comment les suppléer en cas « de forte résistance » ou de turn-over ?
• L’approche processus
Cette démarche est une réponse aux questions précédentes. Redéfinissant une organisation au travers de ses processus, l’approche processus permet : – De conférer à une entreprise une vision transverse de son activité. – De décloisonner le rôle des acteurs. – De développer une dynamique de progrès continu en mettant l’accent sur le retour d’expérience et le partage des bonnes pratiques. – De définir des objectifs spécifiques à chaque processus, ces objectifs étant la déclinaison opérationnelle de la Politique de l’entreprise. L’approche processus facilite ainsi le déploiement et l’appropriation de la Politique de l’entreprise tant en termes de Vision que d’objectifs. A ce titre, elle instaure un cadre propice à la mise en œuvre d’une démarche participative et favorise la déclinaison des tableaux de bord au sein de tous les niveaux hiérarchiques. Afin de pérenniser un tableau de bord, celui-ci doit être revu de façon périodique en fonction de l’adaptation de la stratégie de l’entreprise aux évolutions auxquelles elle est assujettie (structure, réglementation, etc.). De plus, de façon à inscrire son fonctionnement dans un cycle vertueux, l’entreprise doit veiller au maintien d’une boucle d’amélioration continue, ceci afin de s’assurer de la pérennité de la démarche de progrès. Tenant compte des pré-requis, développés jusqu’ici, pour bâtir un tableau de bord efficace nous nous proposons de présenter une démarche d’élaboration et de mise en œuvre d’un tableau de bord.
1. Identification du périmètre du tableau de bord
Le périmètre du tableau de bord est défini selon une analyse en deux volets successifs : – L’environnement de l’entreprise permettant de déterminer le contexte macro-économique (localisation, concurrence, règlementation, etc.). – La structure intrinsèque de l’entreprise (processus, activités, acteurs et parties-prenantes, etc.). Cette analyse est nécessaire à la bonne compréhension de la Stratégie de l’entreprise, de sa conception jusqu’à son déploiement. Elle permet ainsi de formuler des objectifs cohérents sur plusieurs axes de mesure (humain, matériel, financier, etc.). En termes de déploiement, ces objectifs globaux doivent être instaurés unilatéralement au sein de l’organisation (approche top-down) car ils traduisent l’engagement de la direction. Leur déclinaison doit, a contrario, être soumise à la responsabilité de chaque niveau hiérarchique (approche bottom-up) afin : – De segmenter les objectifs globaux en parties plus petites et donc plus maniables. – D’instaurer des objectifs compréhensibles par la maille opérationnelle de l’organisation. – De responsabiliser chaque acteur managérial dans l’atteinte des objectifs. – De faciliter l’appropriation de la Vision de l’entreprise et le reporting.
2. Définition des indicateurs et des dispositifs de mesure
Les indicateurs doivent être élaborés en groupe de travail afin d’être porteurs de sens pour les personnes qui le suivent. Chaque groupe inclut les décideurs « stratégique » et « opérationnel » afin que les indicateurs soient cohérents d’un niveau à l’autre. Le nombre d’indicateurs doit rester limité, les objectifs étant déclinés de manière globale et locale (répondant aux questions « pourquoi ? » et « comment ? »). Les indicateurs sont classés en trois catégories : suivi, progrès et résultat. Ils doivent être positionnés sur des axes différents (matériel, humain, financier…). Afin d’établir et de pérenniser le référentiel du tableau de bord, chaque indicateur doit être détaillé dans une fiche de documentation retraçant sa nature, sa signification, son mode de calcul, ses sources, etc. Les dispositifs de mesure doivent permettre de donner les informations nécessaires au calcul de l’indicateur. Ils peuvent varier du simple tableur à l’ERP selon la taille de l’entreprise et/ou de l’activité.
3. Construire et automatiser le tableau de bord
Le tableau de bord doit être construit de telle façon qu’il présente les indicateurs en partant de la mesure et remontent vers la direction du processus ou de l’entreprise. Au niveau macro, il confère une vision synthétique et pertinente de l’activité. Bien entendu, dans la construction du tableau de bord, il faut aussi prendre en compte l’automatisation des indicateurs, rendue possible par les « sondes » mises en place au sein du système d’information. La mesure se fait ainsi en temps réel, ce qui permet : – De fiabiliser les remontées d’informations en effectuant un traçage précis de ces dernières. – D’améliorer la vitesse des alertes et, de ce fait, la réactivité de la prise de décision. – D’industrialiser le traitement préventif et correctif des risques opérationnels.
4. Le pilotage du processus ou de l’entreprise à partir du tableau de bord
Le pilotage de l’entreprise se fait par le biais de l’analyse des résultats présentés dans le tableau de bord. Cette analyse se fait au cours d’une revue de performance qui doit se tenir périodiquement avec les pilotes des processus concernés. La revue de performance est l’occasion de : – Valider les plans d’action et de suivre leur avancement. – D’évaluer leur efficacité opérationnelle.
Conclusion
Il est nécessaire de souligner toute l’importance d’une communication claire et incitative, du lancement du projet jusqu’à son « ancrage terrain ». En outre, la mise en œuvre d’un tableau de bord ne peut être dissociée de la conduite du changement. Ces deux facteurs clés donneront ainsi toute la dimension humaine et participative requise dans le cadre d’un suivi de performance synthétique, proactif et au plus proche de la réalité opérationnelle. Présentation de THEIA Partners THEIA Partners est un cabinet de conseil en organisation et optimisation de la chaîne d’information financière, réglementaire et de gestion, qui accompagne les entreprises vers la performance opérationnelle. Présents auprès des directions fonctionnelles et équipes transverses de grands groupes bancaires et industriels, nos consultants apportent la pratique du mangement de projet, l’expertise du processus de reporting et l’expérience de la gestion des risques.
Auteurs :
Anthony BORDES, Consultant
Frantz TOUSSAINT, Manager
|
L’ouvrage propose une démarche méthodologique de construction d’un système de tableaux de bord par rapport aux objectifs du dirigeant d’entreprise et de ses responsables.
Il détaille l’application de cette analyse aux secteurs de l’industrie, de la banque, de l’assurance, du commerce, du conseil et des services. La disquette synthétise la méthodologie et en déroule l’application à une entreprise.
Deux méthodologies sont présentées pour bâtir progressivement des tableaux de bord :
– l’approche française de construction de tableaux de bord,
– l’approche américaine de mise au point d’un balanced scorecard.
Auteurs : Carla Mendoza, Marie-Hélène Delmond, Françoise Giraud, Hélène Löning, Alexis de Font Réaulx
Référence ISBN : 2865214532
La mise en place de systèmes d’information décisionnels (SID) dédiés au pilotage de la performance facilite la prise de décision et l’alignement stratégique des organisations en recherche d’efficacité et d’efficience.
Ces systèmes assurent la restitution d’informations fiables, précises et pertinentes au moyen d’indicateurs structurés en tableaux de bord. Ils s’appuient sur les méthodes de contrôle de gestion et de pilotage de la performance (benchmarking, balanced scorecard, etc.).
Cet ouvrage analyse les principes de construction d’un SID pour le pilotage de la performance en proposant un modèle d’architecture datawarehouse et datamarts modélisés en étoile, Operational Data Store, cubes et tableaux de bord diffusés via le Web.
Il détaille la conception des systèmes d’alimentation, de stockage et de restitution en intégrant la gestion de la qualité des données, la validation du SID et la gestion de ses évolutions.
Il s’adresse aux responsables de projets et architectes de systèmes décisionnels et propose une application de ces principes à la gouvernance des systèmes d’information (GSI).
Auteurs : Dominique Mollard
Référence ISBN : 2746212196
Site : www.hermes-science.com/fr/
Aucune opération, aucune analyse, aucune décision, aucune stratégie ne peut se construire sans un système qui recoupe les processus d’organisation, d’exploitation et d’échange des données pertinentes. C’est le rôle du système d’information, longtemps réduit à sa simple dimension informatique.
L’objectif de cet ouvrage est de dépasser cette représentation technique et d’amener les managers et les futurs managers à maîtriser les SIO (systèmes d’information organisationnels).
Le livre comprend :
• les thèmes clés liés au management des SI : management du changement, management de projet, audit des systèmes d’information ;
• une synthèse des outils et des technologies disponibles ;
• des développements sur la place des systèmes d’information dans le management des organisations ;
• des enjeux majeurs, généralement passés sous silence : les problématiques juridiques et fiscales, le contrôle interne, la sécurité, l’éthique et l’impact social des systèmes d’information.
Cette nouvelle édition rend compte des derniers changements techniques ainsi que des évolutions d’ordre juridique et réglementaire. Par ailleurs, elle comprend un chapitre complet sur le thème central des ERP. Enfin, les données chiffrées et les nombreuses applications (mini-cas et études de cas) ont été systématiquement mises à jour.
Les droits d’auteurs de cet ouvrage seront entièrement reversés à l’association Aide et action
Aide et Action www.aide-et-action.org, créée en 1981, est une organisation de développement dont l’objet est de faire progresser la cause de «l’Éducation Pour Tous», prioritairement l’éducation de base, pour toutes les populations, partout où elle l’estime nécessaire et réalisable.
Elle agit, dans différentes parties du monde, sur tous les facteurs ayant des incidences dans le domaine éducatif. L’association est libre de toute attache politique et de toute attache religieuse.
Sommaire :
I – Les principaux fondements de la discipline
01. Les systèmes d’information organisationnels
02. L’évolution des rôles des systèmes d’information
03. La technologie et les systèmes d’information
II – La place des systèmes d’information dans le management des organisations
04. Les systèmes d’information au service de la stratégie
05. L’ERP et ses outils, moyens et principales composantes du système d’information
06. Les systèmes d’information et d’aide à la décision
III – Le management des systèmes d’information
07. La conduite de changement dans un projet de SI
08. Les projets de système d’information
09. L’audit des systèmes d’information
IV – Les enjeux majeurs
10. Sécurité des systèmes d’information
11. Les systèmes d’information, soutien indéfectible du contrôle interne
12. Dimension juridique et fiscale des systèmes d’information
13. Éthique et impact social des systèmes d’information
Public :
Etudiants en écoles de commerce et universités (1er et 2e cycles), gestionnaires non spécialistes des systèmes d’information.
Auteurs : Pascal Vidal, Vincent Petit, François Lacroux, Marc Augier, Valéry Merminod, Marc de Gibon, Christophe Mangholz
Référence ISBN : 978-2-7440-7296-3
Site : www.pearson.fr/livre/?GCOI=27440100440440
Editeur : Pearson Education
Systèmes d’information et processus Agiles a pour objectif de former les ressources (maîtrise d’ouvrage comme maîtrise d’œuvre), engagées dans un projet d’organisation et/ou de système d’information.
Systèmes d’information et processus Agiles décrit d’abord les aspects stratégiques de l’Agilité puis en détaille les concepts opérationnels. Il s’adresse aux dirigeants et à tous les cadres de l’organisation, dont évidemment, les DSI et chefs de projets « informatiques » ou « utilisateurs ».
Outil de compréhension de l’agilité organisationnelle et support de sa mise en œuvre technique, Systèmes d’information et processus Agiles propose, dans la finesse d’une approche alliant normes d’industrialisation et concepts Agiles, des références opérationnelles couvrant :
Afin d’offrir une réponse appropriée aux intérêts de chaque acteur du projet, l’ouvrage est organisé en 3 sections :
Auteurs : Jean-Pierre VICKOFF
Référence ISBN : 2746207028
Site : www.rad.fr
Ce manuel de management est conçu pour préparer des responsables à la gestion des systèmes d’information. Il présente l’essentiel des connaissances nécessaires pour aborder les principaux problèmes posés aux organisations par l’usage des technologies de l’information (progiciels de gestion, Internet, commerce électronique…).
Auteurs : Robert Reix
Référence ISBN : 2711775682
Dans un monde où les mots « vigilance » et « agilité » prennent tout leur sens, le « changement » se traduit par la mondialisation des marchés et la globalisation de l’économie. Ce nouveau mode de changement, radical et rapide, incite les entreprises, tout secteur confondu, à être proactives. En effet, plusieurs crises vécues ainsi que la montée en puissance des groupes de pression ont conduit à l’homogénéisation des pratiques et des systèmes de reconnaissance. Cette régularisation a permis aux entreprises de regagner une certaine confiance et d’afficher une grande transparence auprès des acteurs intéressés.
Par conséquent, la normalisation des différents secteurs a favorisé l’émergence de plusieurs référentiels de système de management de la qualité, de l’environnement et de la sécurité, conçus à l’origine pour le secteur industriel uniquement (Mathieu et al., 2003).
Par ailleurs, les entreprises qui adoptent ces systèmes intègrent une démarche de progrès qui leur permet de déceler les opportunités, d’écarter les menaces et surtout de mesurer leurs niveaux de performances. L’adoption de l’un ou de l’autre de ces systèmes de management dépend de plusieurs paramètres, en particulier, le mode de gestion, la culture de l’entreprise et ses enjeux.
Face à l’importance de ces paramètres, l’entreprise est confrontée à de nombreux facteurs encourageant l’approche globale au travers d’un système de management intégré qualité, sécurité et environnement. Ces différents facteurs sont : la productivité, l’optimisation des ressources, la réduction des risques et enfin, le principe de cohérence. Ce dernier facteur, et non le moindre, est le concept fédérateur de l’intégration. Effectivement, lorsqu’une entreprise manage ses performances en arborant une vision d’ensemble et en se basant sur des systèmes séparés et indépendants, l’incohérence s’installe (Mathieu et al., 2003).
Cependant, une approche de système intégré s’avère indispensable. Cette étude présente ainsi quatre référentiels pouvant faire l’objet d’intégration dans un système de management commun, à savoir : le système de management de la qualité selon ISO 9001, le système de management de l’environnement selon ISO 14001, le système de management de la santé et de la sécurité au travail selon l’OHSAS 18001 et le système de management de la sécurité des denrées alimentaires selon ISO 22000.
Tout d’abord, une rétrospective succincte comprenant l’historique, la finalité, les concepts et les exigences, sera présentée dans les sections suivantes, pour chacun des référentiels choisis. Ensuite, ces derniers feront l’objet de comparaison avec quelques modèles de managements intégrés existants et seront également confrontés à des pratiques de classe mondiale, pour enfin présenter un modèle intégrateur qui rejoint l’excellence et adhère aux principes d’un référentiel simple et élargi.
1. Présentation du Système de management de la qualité (SMQ)
Publiée par l’organisation internationale de standardisation (ISO – International Standard Organisation) en 1987, la nouvelle série du système de management de la qualité ISO 9000 comprenait trois normes permettant d’accéder à une certification : ISO 9001, ISO 9002 et ISO 9003. La norme ISO 9004 donnait les lignes directrices pour la mise en place de l’assurance qualité (www.iso.org).
En 1994, une première révision a permis d’intégrer de nouvelles exigences et d’instaurer la notion d’actions préventives (Monin, 2001). La deuxième révision, en 2000, a mis l’accent sur plusieurs aspects non exigés dans la version précédente. Tout d’abord, la recherche continue de la satisfaction du client et l’exigence des indicateurs. Ensuite, dans un objectif de simplicité et d’accessibilité pour les entreprises, les trois normes certifiables ont été rassemblées en une seule ISO 9001.
Enfin, l’adoption des principes de base du management de la qualité et des pratiques d’excellence, soit : l’orientation client, le leadership, l’implication du personnel, l’approche processus, le management par approche système, l’amélioration continue de type PDCA (Plan, Do, Check, Act – Planifier, Faire, Vérifier, Agir), l’approche factuelle pour la prise de décision, les relations mutuellement et bénéfiques avec les fournisseurs (ISO 9000: 2000).
Une entreprise peut ainsi poursuivre son effort vers l’excellence en direction des référentiels de management de la qualité totale (EFQM, Deming, Malcom Baldrige…) en suivant les recommandations de ISO 9004 pour l’amélioration des performances. ISO 9000 présentant les principes essentiels et le vocabulaire (Monin, 2001).
Le système de management de la qualité (SMQ) selon la norme ISO 9000 obéit à trois types d’évaluation : l’audit interne (assure l’efficacité de gestion des processus et la rigueur dans la maîtrise des activités), l’audit second (inviter ses clients à auditer son système) et l’audit tierce partie (réalisé par des organismes de certification indépendants) (www.iso.org).
Ces différents audits viennent évaluer la conformité des exigences du système de management de la qualité par rapport à leur maîtrise, lors de leur implantation et de leur certification. Ces exigences sont présentés en huit chapitres, à savoir : le domaine d’application, les références normatives, les termes et définitions, le système de management de la qualité, la responsabilité de la direction, le management des ressources, la réalisation du produit et la mesure analyse et amélioration.
Ces différentes exigences sont détaillées à leur tour pour éviter les ambiguïtés et permettre facilement de détecter les écarts lors des audits internes et externes (ISO 9001 : 2000).
2. Présentation du Système de management de l’environnement (SME)
La problématique environnementale a pris de l’importance dans les dernières décennies. Elle a été à l’origine d’une mobilisation généralisée face à la dégradation accélérée des écosystèmes planétaires. Les principaux phénomènes biophysiques et écologiques sont (Gendron, 2004) : le réchauffement de la planète, la diminution de la couche d’ozone, la biodiversité, la déforestation, la désertification, l’urbanisation, la croissance démographique et la surpopulation.
La problématique environnementale n’est donc plus une question technique et scientifique, c’est un véritable enjeu sociopolitique. Les écologistes, les gouvernements et les entreprises font ensemble appel à l’idée du développement durable en relevant le double défi du développement économique et de la protection de l’environnement.
Dans le cadre de ce soutient environnemental, le secteur privé a pris des mesures volontaires afin d’améliorer l’image corporative, d’accroître l’avantage concurrentiel et de réduire les coûts de conformité législative. La norme du système de management de l’environnement ISO 14001 ne se substitue pas à la réglementation et n’impose pas d’obligations environnementales au sens strict.
Son objectif premier est de fournir un outil de gestion environnemental universel pour éviter que la protection de l’environnement ne devienne une barrière non tarifaire qui entrave la circulation des biens (Gendron, 2004).
La série ISO 14000 en version 2004 comprend l’ISO 14001 qui spécifie les exigences pour un SME et l’ISO 14004 qui donne les lignes directrices relatives à leur mise en oeuvre (www.iso.org).
La norme ISO 14001 ne fixe pas de performances à atteindre, mais stipule une organisation du management environnemental inspirée de la boucle d’amélioration continue PDCA, qui repose sur la réalisation d’un ensemble d’exigences réparties en six étapes successives (Mzoughi et al., 2005) : la détermination des intentions de l’établissement, la rédaction d’une politique environnementale, l’établissement d’un plan environnemental, la mise en oeuvre du plan environnemental, le contrôle des performances environnementales et d’actions correctives et la revue de direction exhaustive.
3. Présentation du système de management de la santé et de la sécurité au travail (SMS)
La branche certification du BSI (British Standard Institute) a conçu, pour des fins d’harmonisation de pratiques et de certification, le référentiel du système de management de la Santé et la Sécurité au Travail (SMS) OHSAS 18001. Entré en vigueur depuis 15 avril 1999, ce référentiel a le statut de « spécification » et non pas de « norme ».
La structure de la série OHSAS est conçue de façon à faciliter l’intégration des trois domaines, Qualité, Sécurité et Environnement dans le management global de l’entreprise. Elle comprend l’OHSAS 18001 : 1999 (SMS – Spécification) et l’OHSAS 18002 : 2000 (SMS – Lignes directrices de mise en application de l’OHSAS 18001).
La démarche du SMS selon la série OHSAS vise à identifier un risque/danger inhérent au milieu du travail pouvant causer un accident ou une maladie professionnelle (risque électrique, incendie, chute…). Ce système prône également l’amélioration continuellement des conditions de travail et des performances en terme de sécurité et santé (ergonomie des postes, vibration, température…) (Mathieu et al., 2003). Il emprunte ainsi les mêmes principes, outils et concepts qui s’appliquent au système de management de la qualité.
Les grandes étapes successives essentielles de mise en place d’un système de management de santé et sécurité selon le référentiel de l’OHSAS 18001 sont : la définition et planification d’un plan d’actions, la réalisation d’un diagnostic initial, la rédaction de la politique sécurité, la mise en place de l’organisation sécurité, la mise en place de la formation, la mise en place du programme sécurité, la mise en place de la gestion documentaire sécurité, le fonctionnement du système de sécurité, l’audit du système de sécurité et la revue de direction (Gey et al., 2005).
4. Présentation du système de management de la sécurité des denrées alimentaires (SMSA)
La maîtrise de la sécurité alimentaire est un enjeu essentiel dans le secteur alimentaire. La crise de confiance actuelle a suscité de nombreux débats et a envahi l’opinion publique. L’hygiène et la sécurité des denrées alimentaires deviennent ainsi une exigence impérative par excellence. Par conséquent, en octobre 2005, le comité « produits alimentaires », dans l’enceinte de l’ISO, a publié la norme ISO 22000 qui définit les exigences d’un système de management de la sécurité des denrées alimentaires (SMSA) (www.iso.org).
Cette norme s’applique à tout type d’entreprises et concerne divers intéressés quelques soient leurs métiers et leurs positions dans la chaîne alimentaire. Elle est destinée également à tous les organismes, indépendamment de leur taille, qui sont impliqués dans cette chaîne et qui veulent mettre en oeuvre un système permettant de fournir en permanence des produits sains (ANIA, 2006).
La norme ISO 22000 prend en considération les principes et les dispositions structurelles contenues dans la norme ISO 9001 afin de permettre une parfaite compatibilité et complémentarité avec les différents référentiels de management couramment utilisés par les entreprises. Elle repose sur quatre chapitres principaux étroitement liés : la responsabilité de la direction, le management des ressources, la planification et la réalisation de produits sûrs, la validation, la vérification, et l’amélioration du système.
L’implantation de la norme ISO 22000 s’articule autour des programmes préalables (PRP) et de la démarche HACCP de façon dynamique. Tout d’abord, les programmes préalables (PRP) qui sont constitués d’une ou plusieurs procédures ou instructions spécifiées, qui sont spécifiques à la nature et à l’ampleur de l’opération, qui améliorent ou maintiennent les conditions opérationnelles afin de permettre une maîtrise plus efficace des dangers liés à la sécurité des aliments et/ou qui maîtrise la probabilité d’introduction de tels dangers et leur contamination ou prolifération dans le ou les produits et dans l’environnement de transformation des produits (Faergemand et al., 2004).
Ensuite, le système de maîtrise HACCP (Hazard Analysis Critical Control Point – Analyse des points critiques pour leur maîtrise) basé sur la prévention varie selon la dispersion (homogène ou hétérogène) des dangers dans les lots de production, et de leur fréquence d’apparition (Mortimore et al., 1996).
Il respect sept principes, à savoir : la description du procédé du produit, l’identification des dangers à chaque étape, l’évaluation de la probabilité de leur apparition et l’exposition des mesures préventives ; l’identification des points critiques pour la maîtrise (CCP) ; l’établissement des limites critiques pour les mesures préventives; l’élaboration et la mise en place des procédures de surveillance des CCP ; la détermination des actions correctives à appliquer lorsque les résultats de surveillance indiquent que ce CCP n’est pas en état de maîtrise ; l’établissement des procédures qui assurent l’enregistrement et le suivi des actions et qui s’inscrivent dans un système documentaire efficace ; l’élaboration des procédures de vérification et de validation du système HACCP (ASEPT, 1995 ; Mortimore et al., 1996 ; Buscemi, 2004).
5. Comparaison des systèmes de management présentés
Les référentiels présentés dans les sections précédentes sont les systèmes de management de la qualité selon ISO 9001, de l’environnement selon ISO 14001, de la santé et de la sécurité au travail selon l’OHSAS 18001 et de la sécurité des denrées alimentaires selon ISO 22000. Pour chacun des systèmes on a rapporté une brève description comprenant l’historique, la finalité, les concepts et les exigences. Ce qui permettra d’exposer, dans la présente section, les similitudes conceptuelles, structurelles et méthodologiques des systèmes choisis.
Tout d’abord, ces différentes démarches managériales arborent simultanément deux concepts fondamentaux, le cycle PDCA et l’évaluation du risque. Ensuite, ces normes véhiculent plusieurs principes, les plus communs d’entre eux sont ceux du management de la qualité plus particulièrement l’approche par processus.
Enfin, les quatre systèmes suivent la structure du guide des systèmes de managements ISO 72 (Mathieu et al., 2003). La logique méthodologique commune aux quatre systèmes de management étudiés est illustrée dans le tableau suivant :
Tableau 1. Logique structurelle et méthodologique détaillée des systèmes de management étudiés
Le schéma suivant a pour objectif de visualiser les convergences et les divergences des quatre systèmes de management étudiés. Le choix d’inclure une norme sectorielle parmi ces systèmes, concède à la présente étude une ouverture vers l’incorporation de d’autres secteurs d’activité dans un objectif de globalisation.
Figure 1. Convergences et divergences des systèmes de management étudiés
La figure suivante permet de synthétiser la cible et la finalité des différents référentiels de systèmes de management étudiés (Mathieu et al., 2003) :
Figure 2. Composantes, cibles et finalités des systèmes de management étudiés
Les diverses illustrations précédentes présentent les similitudes conceptuelles, structurelles et méthodologiques des quatre systèmes étudiés. Ces derniers possèdent des domaines de fonctionnement communs, qui peuvent être fusionnés dans un Système de Management collectif Intégré (SMI).
Ces référentiels de management ne précisent pas la manière de concevoir les systèmes de management, et ne fixe pas d’objectifs de performance. Les principaux points communs à ces quatre systèmes se résument en (www.management-environnement.com) :
– L’amélioration continue (roue de Deming ou approche PDCA) ;
– La nécessité d’un engagement de la Direction, d’une politique et des objectifs ;
– La planification et l’élaboration d’un programme ;
– L’identification des risques et la prévention des dysfonctionnements ;
– L’identification des exigences légales et autres ;
– La définition d’une organisation, des autorités et des responsabilités ;
– La nécessité de former et de sensibiliser le personnel (management des compétences) ;
– La communication interne et externe ;
– Les exigences en matière de gestion des documents et des enregistrements ;
– La gestion des non-conformités, la définition et la mise en oeuvre d’actions correctives et préventives ;
– La mise en oeuvre d’un processus d’audit ;
– La diminution du coût des relations clients-fournisseurs ;
– La facilitation des échanges internationaux (certification internationale).
Malgré une architecture organisationnelle similaire des référentiels traités, les objectifs diffèrent sur des dimensions importantes. Les principaux points de divergences entre les quatre systèmes sont : les interlocuteurs ou les intéressés, les coûts d’adoption, les bénéfices liés aux systèmes ainsi que leur tangibilité, les programmes planifiés et le niveau d’évaluation du risque.
Ces quatre approches sont, tantôt différentes, tantôt similaires ou encore complémentaires. La nature de l’entreprise et de son interaction avec son environnement sont, en grande partie, les causes de la corrélation entre ces différents systèmes de management.
Leur mise en place peut être effectuée lorsqu’une entreprise possède déjà un ou plusieurs systèmes et veut s’étendre aux autres domaines; ou qu’elle n’en a pas et souhaite une mise en oeuvre intégrale des quatre systèmes à la fois. Ils sont donc complémentaires et s’insèrent dans une démarche volontaire engagée par la direction de l’entreprise dont le but est l’amélioration continue de sa performance globale.
La complémentarité des systèmes choisis réside dans leur finalité. En effet, la norme du système de santé et sécurité au travail traite le bien être du « coeur du système », soit : le personnel (clients internes), tandis que la norme du système environnementale s’occupe des autres intéressés (clients externes). La norme du système de sécurité alimentaire réunie à la fois le client interne et externe dans l’acception singulière de consommateur dans le secteur particulier de l’alimentaire.
Enfin, la norme du système de management de la qualité qui rassemble le client interne et externe avec une porté plus globale. La figure suivante permet de bien situer et visualiser les différences et les complémentarités des quatre systèmes de management.
Figure 3. Frontière d’application des systèmes de management étudiés
Les quatre systèmes étudiés regroupent donc trois types de management : Qualité, Environnement et Sécurité. Le management de la sécurité étant orienté à la fois vers la santé, la sécurité au travail et la sécurité des produits alimentaires, sachant que les produits alimentaires comprennent des composantes tangibles (produits physiques) et/ou intangibles (services et/ou informations).
Ces approches ont déjà fait l’objet de tentatives d’intégrations réussies. La prochaine section tentera d’expliciter la notion d’intégration et d’exposer par la même occasion quelques modèles ayant fait leurs preuves dans le domaine du management stratégique et organisationnel.
6. Présentation des systèmes de management intégrés (SMI) existants
Le concept de système de management intégré (SMI) existe déjà depuis plusieurs années et notamment suite à l’apparition du système de management environnemental en 1996. Dans un premier temps, le SMI dans son acception la plus courante portait sur l’intégration des systèmes : Qualité, Sécurité et Environnement, soit, QSE (www.afnor.fr). Cette intégration n’est pas d’ordre structurelle uniquement, elle obéit à un ensemble d’enjeux principalement économiques.
L’enjeu majeur de cette démarche d’intégration est la formalisation d’un outil de pilotage qui répond avec pertinence aux attentes des dirigeants conscients, avertis et responsables. Les trois modèles d’intégration suivants présentent les synergies qui existent entre les systèmes de management étudiés et qui permettent leur fusion :
– En premier lieu, la logique PDCA qui est le système normalisé de management représenté par le tableau suivant (Mathieu et al., 2003) :
– En second lieu, le modèle des processus proposé dans la famille ISO 9000 qui vient enrichir le palmarès des structures d’intégration des systèmes de management. Cette conceptualisation s’articule autour de quatre critères qui constituent les macros processus. Ils sont présentés dans le tableau suivant :
– En fin, le dernier modèle présenté est celui des « Bonnes pratiques de classe mondiale », tels que : le Prix européen de la qualité (EFQM) en France, le Malcom Baldridge National Quality Award (MBNQA) aux Etats Unis et le Prix Deming au Japon qui sont tous basés sur un concept d’évaluation et d’amélioration en continue.
Les organisations utilisent différentes démarches et des outils très diversifiés afin d’améliorer leur performance et leur compétitivité. Les outils de première importance sont ceux qui aident à définir un diagnostic.
En effet, les référentiels d’excellence sont des outils de diagnostic et d’évaluation du niveau de performance de l’organisation. Ils proposent une structure d’analyse systématique orientée vers les résultats. Les pratiques qui mènent à ces derniers et leur déploiement dans l’ensemble de l’organisation sont passées au peigne fin également. La structure de ces référentiels les rend pertinents pour tous types d’entreprises, quel que soit leur domaine ou leur taille.
Le schéma suivant présente le modèle intégré du QUALImètre adapté du référentiel du Malcolm Baldrige National Quality Award (Mouvement Québécois de la Qualité, 2002) :
Les trois modèles présentés représentent quelques exemples d’intégration qui ont fait et continuent aujourd’hui à faire leur preuve dans le management des organisations publiques ou privées tous secteurs confondus. Ces approches managériales ont permis aux entreprises de développer leurs pratiques de gestion, d’améliorer leur productivité, d’atteindre leurs objectifs de performances et de couronner leurs efforts par des reconnaissances internationales.
Auteurs : Houda EL Yacoubi El Idrissi, Abdelghani Cherkaoui, Driss Bouami.
Ecole Mohammadia d’Ingénieurs
BP 765 Agdal – RABAT – MAROC
L’Entreprise orientée «service» a pour guide le tracking des exigences «client» et pour finalité la performance et la qualité optimale. La notion d’agilité s’attache quant à elle à un ensemble de valeurs optimisant la mise en œuvre des moyens de cette ambition. Le premier outil de l’Architecture d’Entreprise est une modélisation stratégique des exigences «client» incluant l’état, au présent et au futur immédiat, des solutions technologiques susceptibles d’apporter une réponse opérationnelle.
En second outil, une modélisation métier permet à l’organisation de formaliser les processus devant supporter ses missions. Et c’est seulement ensuite que la notion d’architecture technique, s’appliquant à un système d’information ou à un système de production industriel apparaitra.
Dans le «buzzword du framework architectural», la plus grande imprécision règne. L’absence de vision globale des informaticiens en est certainement la cause. Leurs propositions se limitent actuellement aux aspects techniques ou applicatifs du système d’information (figure 1). De plus, cette vision d’urbanisation qu’ils qualifient d’ «Entreprise» fait abstraction d’une modélisation des ressources humaines et n’implique pas de modèle anticipatif de l’environnement en évolution (1).
(1) Puma délègue l’architecture technique et la gouvernance à des modèles spécialisés ou standards.
La réponse n’est pas dans la structure du SI mais dans la dynamique du processus. Plus précisément dans une double dynamique : la première, en réaction maitrisée de l’adaptation opérationnelle du processus à supporter ; la seconde, en anticipation mesurée des impacts technologiques et fonctionnels de l’environnement.
Pour être Agile, l’entreprise doit maitriser en continu les dynamiques d’évolution du processus métier, des ressources humaines et du système d’information. L’agilité à ce niveau nécessite une projection dans le futur qui doit être instrumentée par des techniques formelles comme l’anticipation rationnelle. Cette pratique permet d’appréhender la dimension des évolutions technologiques ou fonctionnelles en émergence et leurs impacts prévisibles sur les composants de l’organisation.
Actuellement, en ce qui concerne la vision métier et l’architecture applicative devant la supporter, deux approches prédominantes collaborent complémentairement à la recherche de la solution optimale, l’une, le management des processus métiers (BPM), est liée à l’Agilité du processus opérationnel, l’autre, l’Architecture Orientée Services (SOA), apporte une solution élégante au développement des composants du système d’information :
– le BPM s’appuie sur la modélisation métier pour optimiser et adapter l’ensemble des activités. En remodelant l’organisation autour des processus composant le cœur de l’organisation, le BPM s’impose comme le levier principal de la performance opérationnelle ;
– la SOA, par son approche de conception et de construction de services sous la forme de briques applicatives indépendantes, facilite l’instrumentation des processus.
L’avantage de la SOA est de produire des composants simples, modulaires et faiblement couplés, donc permettant de recomposer rapidement l’agencement applicatif des fonctionnalités qu’ils assurent.
SOA comme BPM collaborent à la même stratégie : assurer l’atteinte des objectifs de l’Entreprise dans un contexte d’évolution rapide et le plus souvent lié à une obligation de différenciation concurrentielle.
La performance du processus métier
Tous les processus opérationnels d’une organisation ne sont pas automatisés ou rationnellement automatisables. De plus, ils coexistent généralement avec un ensemble de pratiques individuelles souvent difficilement formalisables. La notion de productivité doit donc composer avec plusieurs variables dont certaines, comme les processus, peuvent faire l’objet d’un monitoring automatisé et d’autres, moins aisément mesurables, sont liées aux notions de compétence, de motivation ou d’appartenance.
Pour être pertinente, une approche globale de la performance doit intégrer l’ensemble de ces préoccupations. Ainsi a émergé le concept d’Agilité optimale.
L’approche ouverte PUMA pour Processus Urbanisant les Méthodes Agiles (voir Entreprise-Agile.com), propose le premier modèle Agile de ce genre (figure 2) couvrant la totalité de ces aspects et les déclinant pragmatiquement du niveau stratégique de l’anticipation rationnelle jusqu’aux pratiques de qualité du code des développeurs en passant par l’amélioration opérationnelle des processus métiers.
Dans cette approche, la dynamique d’évolution de l’entreprise se structure en 6 domaines d’actions modélisées. Ces domaines sont en liaison structurelle avec les 3 niveaux d’abstraction désormais représentatifs de la nouvelle Expression des Exigences (2).
Le fondement essentiel du paradigme Agile est la puissance de la simplicité, aussi PUMA propose-t-il une vision pragmatique de la mise en œuvre de cette architecture. Dans chaque domaine, après diagnostic d’une pratique réelle de l’organisation, la technique Agile recherchée donne lieu à une formation et s’implémente par coaching. L’efficacité obtenue est ensuite mesurée par monitoring.
Ainsi pour gagner rapidement un degré dans la performance ou la qualité, il suffit d’utiliser la technique adéquate nommée Agile QuickWin ou un groupe de techniques complémentaires (Agile Pack).
En ce qui concerne les aspects plus complexes de l’Agilité liés à la modélisation, au développement ou au pilotage de projets de système d’information, PUMA a intégré les aspects standards les plus puissants de l’Agilité (Agile Modeling, Agile Programming, eXtreme Programming, Agile Unified Process, Agile MDA, EssUP, etc.). Le processus guidant le pilotage du projet fédère l’ensemble des concepts de manière opérationnelle, Agile, formalisée, mais surtout cohérente.
(2) Les Exigences de contraintes non techniques et non fonctionnelles ne sont pas traitées à ce niveau.
L’implication des ressources humaines
La première valeur fondatrice de l’Agilité se situe dans l’implication des ressources humaines. Elle se décline dans le sentiment d’appartenance et les conditions de motivation, puis la vision commune et la connaissance partagée. Cet ensemble, qui s’apparente à une philosophie comportementale, portera ensuite le pragmatisme de l’action.
A la base de l’entreprise Agile, se situent les ressources humaines opérationnelles. Leur implication est déterminante dans la recherche d’optimisation permanente des processus en termes de performance et de qualité. Pour les maîtriser et les simplifier, il faut utiliser le pouvoir de l’intelligence collective.
Les techniques PUMA basées sur le principe d’amélioration continue de la qualité, sont en ce sens de puissants moyens d’obtention d’avantages concurrentiels au meilleur coût. Le principe tire sa force de la connaissance pratique des personnels opérants, dont la participation à une recherche systématique d’améliorations est suscitée. Bien déployée, cette technique peut optimiser tous les secteurs de l’entreprise.
Dans cette quête de productivité et de qualité, lorsque les règles Agiles sont réellement et complètement implémentées, l’organisation dispose d’un fantastique outil de résolution de la «complexité de détails». La détection et la résolution des problèmes peuvent alors s’appliquer à une multitude de dysfonctionnements mineurs qui échappent généralement aux échelons supérieurs compte tenu de leur faible visibilité.
Ainsi, l’entreprise Agile maîtrise en continu la complexité d’un environnement mouvant, en traitant, dès leur détection, les évolutions émergentes.
La performance du système d’information
Au niveau du SI, l’adoption du paradigme «orientation service» repose essentiellement sur un style d’architecture technique qui sera pris en compte lors de la recherche d’une solution applicative. Plus généralement, l’obtention Agile d’une application s’appuie sur un modèle (3) de recherche de composants «clé en main». Parfois les solutions génériques sont inexistantes (nouveaux besoins, nouvelles technologies) ou inadaptées au contexte (différenciation concurrentielle).
Dans ces cas, un développement spécifique est justifié, et trois aspects vont concourir à la performance du projet et à l’efficience de la solution en résultant :
– la souplesse de l’architecture applicative, et particulièrement la facilité de redéploiement qui conduit à privilégier les techniques de la SOA ;
– la pertinence, la qualité et la fiabilité de la solution, qui résultent généralement de pratiques de développement industrialisées (Frameworks, Design patterns) et orientées Agile programming ;
– la maîtrise des délais, coûts et autres contraintes de projets auxquelles les techniques PUMA de pilotage Agile offrent des solutions élégantes et performantes.
En l’état de l’art, et en ce qui concerne l’architecture technique, la solution faisant consensus est actuellement l’orientation services des applications (SOA). Cette approche consiste à décomposer les fonctionnalités, telles que les appréhende un utilisateur, en un ensemble d’éléments basiques nommés «services».
L’étape suivante consiste à décrire finement leur schéma d’interactions dans le cadre d’un processus métier. Les services seront ensuite développés et déployés sous forme de composants logiciels indépendants.
L’objectif de ce type d’architecture logique est de supprimer la construction d’applications lourdes tentant de figer une logique métier en évolution, pour organiser les éléments Agiles d’une réponse adaptée à cette évolution. Lorsque ces techniques s’implémentent par des Web services, l’acronyme utilisé est WSOA, pour (Web Services Oriented Architecture).
Idéalement chaque service est construit indépendant afin de garantir sa réutilisabilité et son interopérabilité, ainsi que finalement, la facilité d’évolution de l’ensemble dans lequel il s’inscrit. Il n’existe pas actuellement de spécifications officielles d’une architecture SOA mais un ensemble de notions fédératrices et de standards trop techniques pour être abordés ici.
La réponse Agile optimale
En résumé, pour l’Entreprise confrontée à la nécessité d’adaptation, l’agilité opérationnelle se situe à la convergence de deux dynamiques :
– l’une, en projection dans le futur immédiat, intègre l’anticipation rationnelle des évolutions de la technologie et de l’exigence client ;
– l’autre, en collaboration avec les ressources humaines, se nourrit au présent de l’impact des divergences fonctionnelles entre le processus et la réalité des opérations.
Dans ce contexte, l’agilité s’affirme comme un outil d’alignement et de cohérence entre les forces internes et les défis externes qui dynamisent l’organisation. Le framework méthodologique PUMA instrumente ce principe en s’appuyant sur les fondements du mouvement Agile et ses standards techniques qu’il intègre et fédère.
Conçue par Jean-Pierre Vickoff, désormais en collaboration avec le Groupe TeamLog, l’approche PUMA se compose d’une palette de solutions Agiles couvrant le scope complet de la problématique évoquée. De plus, PUMA représente une couverture native de diagnostic et de correction, aussi bien des principaux macro-risques liés à l’évolution de l’environnement (obsolescence technologique, débordement concurrentiel, etc.), que des émergences de failles mineures susceptibles de fragiliser le processus opérationnel ou le système d’Information.
PUMA, outil d’adaptation et d’accélération permettant de rendre dynamiquement l’entreprise plus performante, représente la première formalisation d’un modèle global d’Architecture d’Entreprise Agile.
(3) Modèle en 7 couches correspondant à des niveaux du cycle de production. Décrit dans le livre Systèmes d’Information et Processus Agiles.
Jean-Pierre Vickoff,
Bibliographie et références : Systèmes d’Information et processus Agiles, Vickoff (J-P), Editions Hermes, 2003.
Famille : Qualité
Acronyme : Software Process Improvement Capability Determination
Définition BPMS
C’est un modèle d’évaluation de l’aptitude des processus logiciels à répondre aux objectifs fixés. Plus précisément, il s’agit du nom de code du projet international autour de ce modèle, qui a conduit à la norme ISO 15504, plus générale, car applicable à tout processus.
Depuis le mois de mai, la version 9 d’ARIS est disponible.
Software AG présente son nouvel outil comme la combinaison de 20 ans d’expérience en amélioration des processus et des dernières tendances technologiques dans les domaines du Cloud, du mobile, de la collaboration sociale et l’exploitation de gros volumes de données / d’informations :
À travers les fonctionnalités de collaboration sociale, ARIS 9 donne la possibilité, aux membres d’un même réseau social d’entreprise, d’être sensibilisés à la démarche processus et de participer à son amélioration.
La nouvelle version offre de nouvelles capacités d’analyses, plus intelligentes et plus faciles, et permet de mieux profiter du contenu des processus existants.
ARIS 9 promet une prise en main plus aisée, à travers une expérience utilisateur intuitive, et une visualisation des processus plus attrayante.
L’administration de la plateforme sera quant à elle plus pratique grâce à une configuration centralisée permettant une meilleure gestion des licences et des documents.
Pour finir, la nouvelle architecture Cloud, privée et évolutive, alliera performance et sécurité de vos données.
ARIS 9 n’est, pour l’instant, disponible qu’en anglais : nous vous tiendrons informés de sa sortie en français.
En attendant pour en savoir plus, vous pouvez visiter le site Web ARIS 9 .
Crédit visuel : Software AG Tous droits réservés.
|
![]() |
|||||||||||
Présentation : | ||||||||||||
Editeur allemand de progiciels dans les domaines du développement d’applications, SGBD, intégration d’applications internes et B2B, gestion des processus métier et gouvernance SOA. Il est connu pour la suite logicielle ARIS Platform. Domaines d’activités : Principales références :
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
Le guide de l’architecte
Principaux thèmes abordés :
Positionnement des outils Workflow / BPM / EAI ;
Les concepts et la structure des plateformes SOA ;
Méthode pour modéliser les services, les processus et les applications composites ;
L’organisation d’un projet SOA ;
La boîte à outils des Web Services ;
Etude d’une mise en ouvre concrète ;
L’offre du marché.
Cible : Métier / Technique
Niveau : Vulgarisation / Expertise
Auteurs : Xavier Fournier Morel, Pascal Grojean, Guillaume Plouin, Cyril Rognon
Référence ISBN : 2100499726
Famille : Automatisation/intégration
Acronyme : Service Oriented Architecture
Définition BPMS
Architecture applicative pour l’éxecution de processus métier. Chaque fonction, ou service, est conçue de manière à être interconnectée mais indépendante des autres fonctions.
Famille : Qualité
Termes équivalents : Systeme de management de la qualité
Définition BPMS
Le SMQ décrit l’organisation de la société en terme de politique et objectifs qualité et leur planification, de maîtrise et assurance de la qualité, et d’amélioration de son efficacité et efficience. Mettre en place un SMQ repose sur la compréhension du fonctionnement des organisations et ce qui fonde leur réussite. Les processus sont au cœur des systèmes de management, la politique et les objectifs donnent le sens et la direction, le pilotage des activités se fait par indicateurs et le progrès est obtenu par les plans d’amélioration continue. La gestion documentaire est enfin l’art et la manière de transcrire ce système et de le pérenniser.
Famille : Qualité
Acronyme : Service Level Management
Définition BPMS
Gestion de niveaux de services. Il s’agit des procédures et des outils qui permettent à l’exploitant de gérer l’escalade applicable pour résoudre un problème lié à une application client. En cas de problèmes client simultanés, le prestataire doit choisir parmi des priorités selon la criticité de l’application et les termes de la convention de service.
Famille : Qualité
Acronyme : Service Level Agreement
Définition BPMS
Accord sur la qualité de service, également appelé convention de service. Ce document contractuel définit les engagements de l’exploitant relatifs à la qualité de sa prestation, ainsi que les pénalités encourues au titre d’éventuels manquements. Le niveau de qualité dont il fait état sera mesuré selon des indicateurs objectifs fixés par les parties, comme le temps de rétablissement du service.
L’origine de Six Sigma
6 sigma est à l’origine une démarche qualité née au coeur même de Motorola. Limitée dans un premier temps aux techniques de SPC (Statistical Process Control MSP Maitrise Statistique des Procédés), elle est rapidement devenue une véritable méthode de management englobant l’ensemble des fonctions de l’entreprise. 6 sigma a ensuite été perfectionnée par d’autres groupes, comme General Electric, l’ayant mise en oeuvre avec succès.
Motorola a d’ailleurs été une des toutes premières entreprises mondiales à recevoir le « Malcolm Baldrige » prix très convoité récompensant les entreprises US accédant à la qualité totale.
Six sigma est une méthode de management du progrès particulièrement efficace. Issue d’une démarche fortement connotée qualité à l’origine, Six sigma est relativement simple sur le plan du principe.
6 sigma est fondée sur une règle éternelle qui se vérifie depuis la nuit des temps en tout cas depuis que l’homme commerce :
Pour satisfaire les clients, il faut délivrer des produits de qualité.
Peu de monde pourra contredire cette vérité fondamentale.
Pourtant, elle n’est pas si simple à mettre en pratique. Avec la complexité croissante des produits, la régularité de la qualité délivrée est un véritable casse-tête.
En effet, les processus de fabrication ont une forte tendance à devenir terriblement complexes. De plus, il faut noter que les composants de base utilisés pour chaque produit ne sont pas toujours de qualité ou de performance égale. Et si de surcroît, les procédures de fabrication sont difficiles à établir, la dérive sera inévitablement au rendez-vous.
Que ce soit pour l’une ou l’autre raison, au final bon nombre de produits seront en dehors de la « normale » et s’écarteront ainsi de la fourchette correspondant à la qualité acceptable pour le client. Cette dérive est fort coûteuse pour l’entreprise.
La gestion des rebuts, des retouches ou des retours clients pour non-conformité génère des coûts conséquents amputant sérieusement les bénéfices espérés. N’oublions pas d’ailleurs qu’il faut aussi prendre en compte l’insatisfaction du client. Même si elle est moins palpable dans l’immédiat elle est la principale explication de la croissance molle, caractéristique d’une majorité d’entreprises.
A noter : La lettre grecque « Sigma » symbolise la variabilité statistique.
Si on peut mesurer on peut corriger
La méthode 6 Sigma offre techniques et outils pour améliorer drastiquement la capacité de production des processus tout en réduisant les défauts. Orientée processus de production à l’origine, la méthode recherche la régularité absolue. La variabilité est en effet source d’insatisfaction du client.
Le client attend un produit avec une certaine qualité, selon un standard précis. Ne pas être capable de garantir la totalité de la production en respectant ce standard est particulièrement coûteux pour l’entreprise.
En fait la variabilité de la qualité finale est essentiellement la conséquence de l’instabilité des composants entrant dans la fabrication du produit, de l’imprécision des procédures de travail et plus globalement de la complexité des processus. 6 sigma impose de rester dans les limites en appliquant le principe :
« if you can measure how many defects you have in a process, you can systematically figure out how to eliminate them and get as close to zero defects as possible. »
Autrement dit, en résumé : « Si on peut mesurer on peut corriger »
L’objectif est de recentrer la courbe sur la cible. A terme, 6 Sigma n’autorise pas plus de 3.4 défauts par million pour chaque produit ou service.
Economie de coûts :
Réduction de la non-qualité comme les rebuts, les reprises, les retouches, les retours clients ainsi que tous les problèmes inhérents à la non-qualité (perte de temps, problèmes de communication, blocage aux interfaces des processus et activités…).
Meilleure exploitation des ressources (optimisation des processus, utilisation optimale des machines et des autres équipements, amélioration des temps de cycle : diminution du coût de fonctionnement combiné à une meilleure exploitation . voir TRS (Taux de Rendement Synthétique) dans le glossaire ).
Amélioration des revenus :
Meilleure satisfaction des clients donc fidélisation renforcée, amélioration du CA par client, accroissement de la part de marché.
Dynamique de progrès continu :
Meilleure disposition pour lancer des projets de grande ampleur : nouveaux produits ou nouveaux processus.
Instauration d’une culture du pilotage par la mesure.
Réussir le projet : SIX SIGMA, la culture de la mesure
6 Sigma n’est pas une amélioration ponctuelle. C’est une réforme de fond de l’ensemble de l’organisation et des mentalités. Il faut ainsi soigner la formation, l’accompagnement du changement et la mesure continue de la performance. L’effort doit être continuellement soutenu.
La réussite du projet repose sur des paramètres bien précis :
– une approche par projet, chacun bien délimité en termes de périmètre d’action, de délais et de budget,
– des objectifs clairs, concrets, précis et connus,
– une formation extensive de l’ensemble des acteurs directs et indirects du projet,
– une coopération et une participation de tous les instants,
– un système de mesure performant.
La généralisation de la mesure est à la base de la méthode 6 SIGMA.
Cependant, cet esprit de mesure ne se limite pas à la phase de mise en oeuvre du projet. C’est en fait une véritable culture de la mesure qu’il s’agit d’instaurer au sein même de l’organisation.
Comme le note lui-même Joseph JURAN, les principaux obstacles de la mise en place de l’amélioration continue ne se situent pas au moment du projet. Lorsque ce dernier est correctement présenté, l’enthousiasme et la volonté d’action sont au rendez-vous.
La principale menace apparaît bien après, lorsque les habitudes passées finissent par reprendre le dessus. La régression est en effet la menace la plus tangible et la plus courante. Cette régression non seulement annihilera les gains promis, mais laissera aussi flotter un vague sentiment d’inutilité susceptible de démoraliser et de casser l’enthousiasme de l’ensemble du personnel pour les projets suivants.
Instaurer la culture de la mesure : le levier de la réussite
D’autre part, le système de mesure ne se limite pas à la mesure pour la mesure mais doit être un véritable outil de pilotage à la portée de tous les acteurs du projet. La performance n’est pas une notion abstraite. Chacun doit savoir « où il en est » afin d’agir dans la bonne direction tout en appréciant les risques avec précision.
Alain Fernandez, consultant international et auteur d’ouvrages sur le management le chef de projet efficace et l’essentiel du tableau de bord a développé une méthodologie nommée Gimsi d’accompagnement à la mise en oeuvre de Six Sigma.
Alain Fernandez
Comment l’appliquer
Ce premier ouvrage français sur le sujet vous présente une méthode de six étapes pour mettre en œuvre un chantier Six Sigma dans votre entreprise.
Il met à votre disposition des outils (tests de comparaison, plans d’expériences, enquêtes de Kano…) pour améliorer votre rentabilité en augmentant la satisfaction totale de vos clients.
Auteurs : Maurice Pillet
Famille : Performance
Termes équivalents : 6 sigma, Appproche 6 sigma, Méthode 6 sigma
Définition BPMS
Méthode d’amélioration de processus fondée sur un principe de réduction de la dispersion statistique. Son succès repose principalement sur la qualification, l’engagement et l’implication. L’objectif étant de se rapprocher du zéro défaut.
Famille : Organisation
Acronyme : Supply Chain Operations Reference-model
Termes équivalents : Référentiel SCOR, Modèle de référence SCOR
Définition BPMS
Le référentiel SCOR a été élaboré par la SCC.
Il présume que toute chaîne logistique peut être subdivisée en 6 types de processus : planification (Plan), approvisionnement (Source), fabrication (Make), livraison (Deliver), gestion des retours (Return) et management (Enable).
Ce modèle SCOR ayant pour finalité l’optimisation des processus Supply Chain de l’entreprise qui au-delà du périmètre de la logistique couvre celui de la gestion commerciale s’accompagne d’une méthode de mise en œuvre qui distingue 4 étapes :
Profil de la société Schlumberger
Depuis mi-2000, l’équipe IT de l’entreprise SLB réalise des plateformes applicatives de référence plus simples et moins coûteuses à intégrer. Elles sont communes à toutes les activités de SLB et fournissent les fonctionnalités et l’aide nécessaire face à l’environnement économique actuel.
L’équipe d’optimisation des processus (BPI : Business Process Improvement) a pour mission de revoir les processus métiers, de documenter les meilleures pratiques, de proposer des tableaux de bord de pilotage de la performance et d’émettre des recommandations visant à l’amélioration ou l’optimisation des processus.
Schlumberger Limited (NYSE: SLB) est une entreprise leader dans la fourniture de services dédiés au secteur pétrolier. Elle fournit et met en oeuvre les technologies et les systèmes d’information visant à optimiser les performances des clients travaillant dans l’industrie internationale du pétrole et du gaz.
Fondée en 1927, l’entreprise emploie aujourd’ hui plus de 80.000 personnes de plus de 140 nationalités travaillant dans 100 pays. La société se compose de deux secteurs d’activité :
– Schlumberger Oilfield Services qui fournit une large gamme de produits et de services allant de l’évaluation des gisements aux activités de forage, construction, stimulation et fermeture de puits, en passant par les services de conseil en matière de gestion, logiciels, et infrastructures informatiques, en support des processus opérationnels clés de cette industrie
– Western Geco, numéro un mondial des études sismiques, qui fournit des prestations à forte valeur ajoutée en matière de collecte et de traitement de données
Défi
Aujourd’hui, plus que jamais, l’organisation de SLB s’appuie sur les processus métiers pour pallier les difficultés afin d’accroître les performances et améliorer la relation client.
Les challenges clés de l’équipe de BPI résident, dans un premier temps, dans la capture de la situation du « as-is » (vision actuelle), dans l’analyse des problèmes et dans l’établissement du process « to-be » (vision cible) pour deux processus métiers clés : Marketing-Ventes et Achats-Approvisionnements.
Dans un second temps, dans la documentation du processus de manière intuitive, user friendly et facile à communiquer, publier à travers l’organisation, ainsi que dans l’analyse de l’impact causé par des possibles changements du processus.
Solution
L’équipe BPI a considéré et évalué les différentes solutions sur le marché afin de trouver une solution qui propose un modèle de processus intelligent et multidimensionnel, qui permet une cartographie intuitive et rapide, une analyse et une simulation rapide d’un processus métier complet, afin d’une part de trouver et éliminer les inefficacités etet d’autre part d’adapter les opérations pour mettre en oeuvre de nouveaux objectifs.
Par la suite, SLB a fait l’acquisition de licences Casewise notamment :
– Corporate Exchange, pour l’aspect référentiel
– Corporate Modeler, pour la partie modélisation
– Casewise CAM Portal, pour la partie communication
Aujourd’hui, d’autres services de SLB, ont rejoint l’équipe BPI pour documenter les meilleures pratiques et le « To Be » process de SLB.
Résultats
Schlumberger est à un stade avancé dans l’initiative entreprise pour la modélisation des processus. Une partie significative des processus ont été documentée. Le focus actuel porte sur la vue matricielle et globale des processus de l’entreprise et la mise en place de sa gouvernance.
Pourquoi Casewise?
Précédemment pour la modélisation des processus, SLB a utilisé un outil très peu convivial avec une publication assez limitée ; l’outil ne pouvait pas être utilisé pour le grand public de l’entreprise.
Une recherche sur le marché des solutions BPA a conduit à la présélection de 2 produits : Casewise a été sélectionné pour sa simplicité, sa flexibilité, son adaptabilité et son innovation.
Famille : Organisme
Acronyme : Supply-Chain Council
Définition BPMS
Le SCC a été fondé en 1996 et est à l\’origine du référentiel SCOR.
Cet organisme est composé de près de 1000 membres à travers le monde et s\’occupe de maintenir et développer le référentiel.
Famille : Qualité
Termes équivalents : SARBOX, SOX, LSO, loi Sarbanes-Oxley
Définition BPMS
Adoptée en juillet 2002 par le Congrès américain, la Loi Sarbanes-Oxley oblige les entreprises cotées relevant de la SEC,
américaines ou non, à répondre de certaines prérogatives administratives dont l\’analyse de leurs procédures financières et la publication de leurs résultats dans les plus brefs délais.
L\’objectif est de restaurer la confiance des investisseurs et de renforcer la gouvernance d\’entreprise, largement entamée par les nombreux scandales financiers de 2001 et 2002.
L’article 404 traite des obligations liées au contrôle interne dans l’optique de la fiabilité de l’information financière délivrée, il introduit l’exigence d’un rapport d’évaluation de la qualité du contrôle interne dans l’entreprise, l’obligation (lourde) de documenter les tests de contrôle interne réalisés, et met un fort accent sur les dispositifs anti-fraudes. Cet article rend obligatoire l’utilisation d’un cadre d’analyse reconnu en matière de contrôle interne et cite en substance le référentiel COSO.
Entretien avec Philippe GRANGE, Directeur des Conférences des Salons Solutions, qui se dérouleront les 2,3 et 4 octobre prochains au CNIT de la Défense.
L’année dernière, on a pu constater aux Salons Solutions une explosion des exposants ERP. La tendance se confirme-t-elle sur l’édition 2012, ou une consolidation s’est-elle déjà amorcée ?
– Oui, absolument ! La partie ERP, historiquement la plus forte, réunit cette année encore une offre large et diverse en la matière. Signature caractéristique de ce salon : les très grands sont présents mais aussi les éditeurs de tailles moyenne, petite, voire très petite. Nous ne ressentons pas d’effet de « consolidation« , car l’offre reste foisonnante, riche et créative.
Le BPM parait régresser en visibilité, pour se retrouver au sein de suites logicielles, ou comme module d’ERP. Cela témoigne-t-il de nouvelles problématiques de la part des professionnels ?
– Je suis d’accord avec votre analyse. J’étais de ceux qui, parmi les premiers, ont contribué à promouvoir – à travers des séminaires, des congrès et un salon – le BPM. Ce domaine ne régresse pas : technologiquement il est en train de « s’enfouir » (« embedded » conviendrait mieux) dans les offres ERP (modélisation et workflow), dans la BI, dans le CRM et bien sûr dans la dématérialisation. Une illustration à cela : cette année, j’ai modifié le thème de notre conférence récurrente sur « Procure-to-Pay, Order-to-Cash » en mettant l’emphase sur la composante BPM de la gestion de ces processus. Au vu du nombre de pré-enregistrés (nous sommes avant l’ouverture), je constate que le thème intéresse sous cet angle… et intéressera de plus en plus.
L’aspect Dématérialisation/GED du salon avait surpris l’année dernière, de par sa densité et sa diversité, sur les conférences données. Quelle est la thématique (ou le domaine) la plus explorée dans le programme 2012 ?
– Vous allez être encore plus étonné cette année : l’engouement pour les conférences dématérialisation est encore plus impressionnant que l’an passé. J’ai d’ailleurs du mal à vous donner une thématique dominante. Toutefois je puis vous dire que les débats portant sur la « cohabitation » documents numériques/documents papier, sur la gouvernance documentaire, sur la mise en œuvre d’une stratégie de dématérialisation et sur les bonnes pratiques de conduite de projets font recette.
Avez-vous le sentiment que certaines conférences ne sont pas seulement des exposés, mais l’occasion pour les professionnels de réfléchir à voix haute ? A quel moment commence l’Atelier et finit la conférence, quand la question fait débat ?
– Tout à fait. Cela fait partie de notre mission, telle que je l’entends et telle que je la conduis. Il doit y avoir – aux côtés des grandes thématiques du moment et de celles récurrentes qui connaissent le succès depuis… 15 ans – des thèmes plus « difficiles » et surtout d’ouverture. C’est ainsi que les choses avancent, par incréments successifs et à un rythme synchrone avec la maturation des technologies émergentes. Je suis têtu sur ce point, lorsque je pense qu’un sujet en vaut la peine… et le P-dg d’Infopromotions (l’organisateur) me fait confiance là-dessus.
D’un point de vue organisateur, estimez-vous que la différenciation entre salons soit encore nécessaire, alors que vous avez donné à l’ensemble une cohérence forte, en rassemblant sujets et exposants sur un même programme ?
– La stratégie de développement des Salons Solutions a toujours été claire : regrouper dans un seul événement et en un seul lieu toutes les solutions progicielles permettant la gestion, la performance et l’innovation indispensables aux entreprises, qu’elles soient grandes, ETI et PME. J’emploie souvent une métaphore pour parler du positionnement des Salons Solutions: il s’agit d’une fleur dont le cœur serait l’échange dématérialisé des données et leurs traitements sur les systèmes d’Information de l’entreprise ; les pétales étant constitués des applications (ERP, DEMAT’, eACHATS, CRM, BI, GPAO…). Dans la durée (nous avons créé le salon ERP il y a 15 ans), certains pétales peuvent être rajoutés au gré des besoins et des innovations ; d’autres peuvent en être détachés.
Quel avenir envisagez-vous pour les Salons Solutions, face à d’autres évènements, comme Documation, eux aussi très tourné vers la GED et la dématérialisation ?
– Les entreprises clientes, comme les exposants, ont pris l’habitude de ce grand rendez-vous de rentrée. En termes de « business« , il est calé en S2 afin de permettre la maturation de projets et les prises de commande pour le premier semestre de l’année qui suit. A l’avenir, les Salons Solutions vont encore se développer grâce à la cohérence et par la complétude de ce qu’ils proposent. Les visiteurs professionnels peuvent, et pourront de plus en plus, optimiser leur visite, prendre de nombreuses informations sur des thématiques connexes et/ou complémentaires, et cela sur 2 jours et demi.
Maintenant que le programme est arrêté, quelles conférences ou ateliers conseilleriez-vous tout particulièrement aux visiteurs qui voudraient découvrir l’essentiel des Salons ?
– Le programme 2012 comprend plus de 40 tables rondes : certaines portent sur les choix de progiciels, d’autres sur leurs mises en œuvre, d’autres encore sur le Big Data, sur le Social CRM, sur la traçabilité, sur le Cloud ou la mobilité. Cet exercice de choix est donc cruel pour leur responsable… Pour jouer le jeu, je dirai : le mardi (15h45) une table ronde eAchats sur la pression que ressentent les Directions Achats avec « l’acheter français » ; le mercredi (14h00) la table ronde Demat’, orientée BPM : « Order-to-Cash, Procure-to-Pay : dématérialiser les processus et après ? » ; et le jeudi (14h00) : « Ce qu’un ERP en mode SaaS change à la DSI, en termes d’organisation, de compétences et d’engagement de services vis-à-vis des métiers utilisateurs«
Interview « Avant-goût » de Francis Mantes, Commissaire Général du Groupe Solutions, réalisée en amont de l’évènement Salons Solutions 2011 qui se tiendra les 4,5 et 6 octobre 2011 au CNIT de la Défense.
Depuis 2 ans Solutions BPM est intégré aux Salons Solutions, un recadrage né d’un constat critique ?
Effectivement nous avons intégré Solutions BPM au cœur des Salons Solutions comme nous l’avons également fait d’ailleurs, pour Solutions IT On Demand et SaaS et Solutions Gestion de Projet. Depuis plusieurs années, les Salons Solutions sont constitués de pôles tels que ERP, la partie la plus importante mais aussi CRM, Dématérialisation, GED, Business Intelligence etc. Il était donc naturel d’y ajouter cette discipline.
Nous le constatons, en dehors de quelques éditeurs qui disposent d’une offre ciblée, voire unique (ERP, CRM, BPM etc), l’offre des exposants se diversifie. Telle société leader dans son secteur enrichit son offre de modules complémentaires ou de savoir-faire en vue de satisfaire ou d’élargir sa clientèle professionnelle. Nous le constatons à la lecture des parcours thématiques du salon. Plusieurs sociétés ont mentionné le BPM dans leur savoir-faire technologique.
Cela signifie-t-il que le coeur de métier s’est déplacé, que le BPM « Pur » serait devenu une idée révolue ?
Pas du tout, en tout cas du côté des offreurs. Un spécialiste du BPM ou d’une autre discipline, cloud computing, CRM par exemple a sa place dans l’univers de l’informatique d’entreprise dès lors qu’il maîtrise la problématique d’intégration et d’adéquation au système d’information. Les éditeurs ne peuvent pas être spécialisés dans toutes les disciplines et les utilisateurs le savent !
Entretien avec Caroline Moulin, Directrice de salon pour Documation
Pouvez vous nous présenter le salon Documation en quelques mots ?
– le salon Documation est le rendez-vous de la gestion de contenu et du document et aborde l’ensemble des problématiques liées à ces thématiques : de la gestion de l’information et de contenu à la dématérialisation de document en passant par le travail collaboratif.
L’exposition regroupe 130 exposants et un cycle complet d’ateliers en accès libre ainsi que quatre événements exceptionnels présentés par BEA, Le Groupe La Poste, Microsoft et W4.
Le congrès, en accès payant, regroupe 11 sessions de conférences, dont 2 tutoriels et a comme objectif de former et d’aider les personnes en phase de projet. Chaque session, d’une demi-journée chacune, comporte des sessions spécifiques pour les maîtrises d’œuvre et d’autres pour les maîtrises d’ouvrage.
Quels sont les objectifs de ce salon ?
– L’originalité de Documation est de s’adresser aux directions informatiques mais également aux directions fonctionnelles ayant des projets à mener dans des secteurs aussi variés que les ressources humaines, le secteur administratif et financier, juridique, marketing, communication, R&D, qualité, formation, commercial, ….
Documation est devenu une « plate-forme collaborative » pour ce binôme devenu maintenant incontournable dans les entreprises lorsque l’on parle système d’information !
C’est la 13ème édition du salon Documation, quels ont été les principales évolutions du salon ces dernières années ?
– Documation a beaucoup évolué et évolue chaque année en fonction des projets de gestion de contenu qui se développent dans les entreprises, si le XML a été l’une des thématiques phares de Documation à ses débuts , l’effervescence de la GED, puis l’archivage légal, le portail et la collaboration, la dématérialisation étaient au cœur des principaux projets ces dernières années.
La dernière édition a fait la part belle au workflow et cette 13ème édition consacre le rapprochement des plates-formes documentaires et des outils de gestion de processus.
Quel est le nombre et la segmentation des visiteurs en 2006 ? Quels sont les objectifs pour cette année ?
– Nous accueillons environ 4200 visiteurs sur deux jours avec une répartition identique entre maîtrise d’œuvre et maîtrise d’ouvrage.
Comment positionnez vous ce salon en fonction d’autres événements comme le Sysqual, le forum de la GEIDE… ?
– Vous auriez pu effectivement m’en citer d’autres !, nous sommes dans la complémentarité de beaucoup d’événements puisque nous abordons ces différents sujets sous l’angle de la gestion de contenu d’entreprise.
Quels sont les thèmes sur lesquels les annonceurs du Salon veulent communiquer ?
– Cette 13ème édition est résolument tournée vers les processus d’entreprise et la relation client : de nombreux ateliers sont consacrés à cette thématique, preuve s’il en est que le management par les processus est une réalité dans les entreprises françaises !
Famille : Qualité
Définition BPMS
La mise en pratique prônée par le nombre croissant de réflexions consacrées à ce sujet consiste à considérer comme réalisation d’un risque opérationnel
• tout événement qui perturbe le déroulement normal des processus métier
• et qui génère des pertes financières ou une dégradation de l’image de l’entreprise
La troisième édition du congrès Gestion des Processus Métiers, organisée dans le cadre du salon Solutions BPM par Infopromotions a permis aux participants de bénéficier d’une dizaine de retours d’expérience de qualité illustrant les grandes étapes des projets de BPM : identification des enjeux, déploiement d’un projet processus et pilotage des processus optimisés.
AXA Investment Managers (IM) traite d’une problématique centrale : faire adhérer le top management à une démarche BPM pour l’ancrer dans la culture d’entreprise.
Compte tenu de la variété et de la complexité des activités financières du groupe et de sa très large couverture géographique, la capitalisation de processus métiers clés est apparue comme le principal atout pour éviter la frustration des clients.
L’engagement du top management a été obtenu autour des concepts de pilotage par les processus orientés clients et de la méthode Six Sigma, adaptée « AXAway » avant d’être promue dans les entités opérationnelles. Les processus centrés sur la relation client ont été sélectionnés, des Key process owners sont désignés et formés, ils ont disposé de personnes ressources dédiées et ils sont tenus pour responsables de la performance de leur processus.
La mobilisation du management des multiples entités opérationnelles a été plus délicate. En synthèse, l’approche retenue a été de :
– créer un sentiment d’urgence (autour du nombre de clients perdus),
– faire plus émerger la notion de qualité perçue par le client, principalement dans toutes les composantes qui ne sont strictement de l’ordre de la performance financière,
– faire valider chaque processus de référence ainsi que ses performances cibles. La modélisation des processus a été effectuée et publiée sur l’intranet d’AXA avec l’outil MEGA , avec beaucoup de road-show en complément,
– associer les entités opérationnelles à la gestion des processus clés,
– mesurer et publier les performances sous forme de tableau de bord,
– aligner les entités opérationnelles sur le processus de référence,
– et célébrer les succès de la démarche.
Le groupe Pierre Fabre (médicaments, cosmétiques) a quant à lui présenté des premiers exemples de la démarche BPM ; effectuée avec l’outil Aris , son déploiement est passé par une coopération originale public – privé avec l’école des Mines d’Albi-Carmaux.
Les travaux de modélisation ont été effectués en fonction de la demande interne au groupe donc plutôt « bottom-up », mais avec le souci de maintenir une cohérence d’ensemble en articulant les travaux autour de la carte générale des métiers de l’entreprise et de modèle cibles de fonctionnement des différents macro-processus impliqués.
Ce projet a permis l’émergence d’un langage commun sur les processus et leur modélisation, et la définition de 4 familles de processus de référence autour desquelles viendront s’attacher toutes les entités opérationnelles du groupe.
Mais d’autres livrables méritent d’être remarqués :
– la structuration des données de références Ressources Humaines (rôles, parcours professionnels),
– la représentation structurée du système d’information et de ses besoins,
– la représentation de tous les projets sur la carte des métiers du groupe.
Ces deux derniers points sont régulièrement la source d’économies substantielles, car ils permettent de détecter très en amont les affinités de certains projets pour les fédérer.
Tibco a présenté la mise en place d’un outil de BAM (Business Activity Monitoring) au Crédit Lyonnais réalisé sur la période 2001-2008.
Ayant analysé que l’ensemble des instructions de dossiers étaient effectuées sur une base de proximité géographique avec des rendements considérés comme modestes :
– les processus de traitement de dossiers ont été modélisés,
– les dossiers ont été entièrement dématérialisés,
– les équipes salariées ont été spécialisées,
– les informations sur les entrées et l’état d’avancement des différents types de dossiers sont désormais capturées,
– ces données sont exploitées pour gérer le plan de charge des équipes salariées en temps réel, et réallouer des travaux ou des ressources lorsque cela est nécessaire,
– le périmètre du projet a été étendu à la gestion des habilitations pour permettre une réallocations efficace,
– enfin les reportings auprès des managers de processus, et l’ensemble des données statistiques collectées, permettent de détecter les processus peu performants pour les faire à nouveau évoluer.
Les participants ont profité de nombreux autres témoignages de qualité.
Le retour d’expérience du Ministère de l’écologie, du développement durable et de l’aménagement du territoire concernait la mise en place d’un système de gestion des amendements réalisé avec l’outil BPM d’Axway et destiné à soulager les utilisateurs de tâches sans valeur ajoutée et à gérer des pics de volumes très élevés.
TOTAL Trading and Shipping a présenté une démarche de reprise de référentiel sous Corporate Modeler.
Le groupe SIDEL (emballage et process alimentaire) a exposé un projet impliquant très fortement le management du groupe : avec le « process office» qui rend compte au comité directeur, les priorités sont gérées en fonction de la stratégie du groupe, et les indicateurs processus font partie de la balanced score card du groupe.
RENAULT Consulting a eu une approche de dématérialisation documentaire en « libre service » pour les différentes entités du groupe, tout en formalisant un outil pour évaluer avec précision « le degré de maturité » d’un processus cible, sa capacité à répondre au niveau idéal de l’attente.
ALSTOM Transport a présenté la démarche de prise en compte maximale des processus cibles au sein d’un SI, avec une volonté de quantifier en pourcentage le niveau de conformité du SI ainsi développé par rapport à la cible. L’approche du partage des responsabilités dans la phase de « Go live » a également été développée.
Enfin, la POSTE groupe courrier a insisté sur l’utilité d’un « indicateur de destruction de valeur par le SI » qui peut être utilisé pour définir les processus sur lesquels une DSI doit travailler en priorité : (valeur pour l’entreprise de chaque processus) * (nombre de processus perdus du fait de l’indisponibilité ou de la non-conformité du SI).
En conclusion, le président du congrès, Jean-François PIRUS, président de BPMS a résumé les retours sur investissements des projets BPMS et listé les facteurs clés de succès pour y parvenir.
Auteur : Laurent Hassid, Consultant Sénior chez BPMS
La seconde édition du congrès BPM, organisée par Infopromotions et présidée par Jean-François Pirus (PDG de BPMS), a permis aux participants de bénéficier de nombreux retours d’expérience de qualité et de faire ainsi un tour d’horizon du BPM en France.
Les différents intervenants ont cherché à répondre à la question centrale : comment utiliser la Gestion des Processus Métier pour viser l’excellence opérationnelle et améliorer la satisfaction client ?
SFR : ou comment convaincre et impliquer la direction dans une démarche processus ?
L’engagement du top management est une condition essentielle de réussite et l’expérience de l’opérateur SFR l’atteste en notant que les arguments ayant fait la différence sont :
– la réduction des dysfonctionnements perceptibles par le client,
– les contraintes réglementaires extérieures grandissantes, notamment en matière de transparence financière (Sarbanes Oxley),
– la possibilité de réduire les coûts liés à certaines prestations de tiers, tels que ceux liés aux SI, en leur fournissant des informations complètes et pertinentes,
– le fait d’aborder la question sous l’angle : quels risques a-t-on à ne pas le faire ?
Le projet processus s’est fait par itération successive suivant une approche top-down. Après une phase pilote avec un périmètre restreint, le déploiement s’est poursuivi et accéléré avec la mise en place et la formation de personnes dédiées. Un référentiel créé sous l’outil MEGA et partagé sur l’intranet est donc utilisé par toutes les personnes de l’entreprise.
Leurs enjeux étaient de servir au mieux le client et d’uniformiser la réponse aux questions les plus communes en partageant l’information.
Si ce projet a illustré la difficulté initiale à convaincre le top management, un intérêt largement partagé a été perçu dès les premières descriptions de processus. Un des facteurs de réussite a été d’intéresser financièrement les personnes qui collaborent de façon transversale à l’amélioration des processus.
BNP PARIBAS : s’appuyer sur une démarche processus pour produire un Plan de Continuité d’Activité
Pour BNP PARIBAS, l’approche processus était vue comme une opportunité de :
– décomposer la complexité du métier,
– avoir une vision d’ensemble et être en capacité d’optimiser le fonctionnement,
– disposer d’un outil de communication.
Cette démarche initiée il y a 7 ans sous l’outil ARIS a donné lieu à la création d’une équipe dédiée et spécialisée.
Le retour d’expérience a été illustré par la modélisation du Plan de Continuité d’Activités.
Ce dispositif doit être soigneusement préparé afin d’éviter la perturbation du fonctionnement de l’entreprise en cas de crise importante. En modélisant les métiers et l’organisation en découlant, l’on dispose d’un outil unique et partagé proposant, par exemple, les probabilités liées à la gestion des risques, ou encore la criticité des services et les temps d’inaccessibilité admissibles.
Il permet également :
– d’identifier et de prioriser les activités vitales ou critiques,
– d’analyser les impacts,
– de définir les niveaux de service minimum,
– de connaître le fonctionnement prévu en mode dégradé.
Caisse des Dépôts et Consignations : modélisation des processus et bonnes pratiques
Initiée en 2004 et poussée par une réorganisation interne, la démarche sous ARIS de la Caisse des Dépôts et Consignations a concerné un processus pilote puis a été étendue à un plus large périmètre.
Les axes d’analyse sont le processus (quoi), les acteurs (qui) et les méthodes et outils (comment). En commençant par un processus simple, concret et compréhensible de tous, l’adhésion au projet a été facilitée.
Les objectifs de cette modélisation étaient de capitaliser la connaissance et de formaliser la relation client.
Les enseignements tirés de ce projet peuvent se résumer ainsi :
– la méthode est un élément capital,
– il convient de doser avec soin les proportions équipes internes/externes,
– la sélection des modélisateurs est primordiale, il s’agit d’un métier à part entière,
– la nécessité d’assister les opérationnels dans la description de leurs métiers,
– la diversité des motivations des collaborateurs.
RENAULT F1 TEAM : les apports d’un outil de BPM
Pour l’équipe Renault F1 Team, il s’agissait de gérer l’ensemble des problèmes liés à la fiabilité des voitures, et en particulier :
– d’unifier les systèmes de gestion des fautes (7 systèmes départementaux existaient auparavant),
– de remplacer les nombreuses feuilles Excel permettant le suivi des incidents sur la piste,
– de réduire les temps nécessaires aux opérations,
– et de développer une interface réutilisable sur différents projets.
Au plan technique, la solution mise en œuvre via l’outil TeamWorks de Lombardi s’est appuyée sur une architecture multi-site, avec une base de données centralisée. Elle permet l’intégration avec le relevé de données de terrain existant et un accès temps réel partout dans le monde.
L’enjeu de ce projet était d’optimiser le temps des ingénieurs sur les circuits, principalement en réduisant le temps qu’ils doivent passer à traiter des emails. En libérant du temps et en assurant un suivi fiable des échanges, l’efficacité du travail de l’équipe est améliorée.
Le projet s’est déroulé en deux grandes phases, après une première itération d’environ 6 mois sur le processus de gestion de la fiabilité, une seconde phase de 3 mois a ensuite permis d’étendre le périmètre du projet.
Au final, la collaboration entre techniciens IT et techniciens métiers s’est améliorée et le projet a été rentabilisé dès la première année.
Les participants ont profité de nombreux autres témoignages de qualité.
Ainsi le retour d’expérience d’Air France a rappelé l’importance de la planification et d’une organisation dans un projet processus.
SAFRAN a détaillé l’approche méthodologique de la modélisation des processus.
EDF de son côté, a insisté sur le défi technique que représentait l’ouverture du marché de l’énergie et comment celle-ci risquait de démultiplier les demandes de la part des clients et des fournisseurs.
GENERAL ELECTRIC a détaillé la mise en œuvre de l’approche Lean Six Sigma.
La BRED BANQUE POPULAIRE a exposé les motivations de la démarche processus adoptée : en prévision des départs en retraite d’une partie de ses effectifs, une capitalisation était souhaitable et fut également l’occasion d’optimiser le temps de travail de leurs collaborateurs.
Enfin, les supermarchés CORA ont appliqué la démarche processus pour améliorer le fonctionnement et donc le service rendu par la Direction des Systèmes d’Information.
En conclusion, le président du congrès, Jean-François PIRUS, a fait le point sur la réalité et la répartition des projets BPM en France en s’appuyant sur les résultats d’une étude menée en 2006 par BPMS.info.
Auteur : Thomas Couderette
Améliorer à la fois la compétitivité de l’entreprise et le bien-être du personnel
Comment, pour nos entreprises européennes, lutter contre la crise tout en étant plus efficaces, bien sûr, plus compétitives, c’est évident, mais aussi plus agréables à vivre.
C’est possible, indispensable même en ces temps de crise. Christian Doucet propose une approche « fonctionnelle » de l’entreprise, avec des démarches d’amélioration pragmatiques et concrètes, sans perte de temps, d’énergie ni d’efficacité. Une vision de l’entreprise qui place le personnel, ses compétences, ses envies et son dynamisme, au cœur des résolutions de problèmes.Fort de son expérience de plus de 40 ans dans le conseil et le suivi des entreprises, l’auteur regroupe dans ce livre les pratiques les plus efficaces mises en place par des entreprises généralement leaders dans leur domaine. On y retrouvera, entre autres thèmes, la recherche de l’excellence, la construction de l’entreprise dans la durée, le renforcement de la motivation du personnel, une priorité donnée aux valeurs et à l’éthique, à la compétence technique et à l’innovation.
Un ouvrage essentiel pour tous les managers, cadres et responsables qui trouveront ici une vision pragmatique, humaniste et stimulante de l’entreprise. Au service de l’efficacité, de la compétitivité et du bien-être de ceux qui y travaillent.
Auteur: DOUCET Christian
Editeur France :Lexitis Editions
Référence ISBN : 978-2-36233-023-0
Famille : Organisation
Définition BPMS
Dans le cadre de la modélisation des processus métiers, une règle de gestion sert de support à des tâches telles qu’apprécier, valider, ou à des répartitions de tâches entre 2 acteurs. Elle se matérialise fréquemment par un périmètre (liste de critères) ou un seuil.
Famille : Organisation
Définition BPMS
Cartographie des processus métier, de l’organisation du SI.
Famille : Organisation
Termes équivalents : Enterprise architecture
Définition BPMS
La notion de référentiel sous-entend un ensemble partagé et généralement structuré d’informations. On parlera de référentiel d’entreprise dans le cas d’une base de données unique intégrant le plus souvent des référentiels métier (vues processus et organisation) et des référentiels techniques (systèmes d’information et outils informatiques le plus souvent). Ce référentiel pourra également, selon les besoins intégrer des vues spécifiques : lexique, risques, compétences (requises par les tâches / acquises par le personnel), environnement légal, pilotage stratégique (indicateurs rattachés à des projets adressant un objectif stratégique), pilotage opérationnel (indicateurs rattachés à des objectifs opérationnels)…
En résumé, le référentiel d’entreprise constitue l’épine dorsale autour de laquelle s’organisent toutes les démarches de formalisation, de communication et de pilotage de l’entreprise.
Guide pratique
Un sujet que tout le monde croit maîtriser. Au travers des 170 pages de ce guide, vous trouverez matière à revisiter ou améliorer votre approche des procédures.
Auteurs : Alain HENRY Ignace Monkam-Daverat
Référence ISBN : 2708121219
L’ambition d’un projet de référentiel processus peut aller jusqu’à décrire le fonctionnement d’ensemble d’un organisme, quel que soit l’environnement (industrie, services marchands, secteur public ou associatif…) dans lequel il évolue. Bien entendu tous les macro-processus de l’organisme ne seront pas décrits avec le même degré de détail, mais tous ont vocation à figurer sur les niveaux les plus synthétiques de la cartographie métier.
La création de cette vue globale métier est une sorte d’acte fondateur, un travail de démiurge qui définit le périmètre, la tranche de réalité complexe, à transformer en un monde intelligible et précis : les activités exercées sont ordonnées, les productions intermédiaires ou finales (destinées aux clients, usagers ou bénéficiaires) sont définies comme bornes de sortie de ces activités.
Partant de ce monde intelligible et précis, un projet d’analyse des coûts ABC (Activity Based Costing), va en traduire la logique et la cohérence sous forme d’enchaînements de flux financiers, avec la même ambition d’ordonner, de rendre compréhensible la mécanique de construction des coûts. Il nous paraît crucial de partir de l’ensemble des processus et des coûts de l’organisme pour, le cas échéant, réduire le périmètre d’analyse en toute conscience en fonction des objectifs que l’on se donne.
LES PREMIERES ETAPES D’UNE ANALYSE ABC
La première étape est de définir les éléments à analyser : sous quel prisme et avec quelle précision veut-on voir les produits ou types de produits et services commercialisés, les clients ou familles de clients ou d’usagers, les zones géographiques desservies… Cette première étape est déjà très liée à la conception stratégique de l’organisme et elle peut présenter une richesse qui n’aurait pas été perçue dans la construction du référentiel processus. Dans une entreprise industrielle cette segmentation est souvent bien connue, pour un acteur du secteur non marchand, cette démarche peut s’avérer très instructive.
La seconde étape consiste à construire, en partant du référentiel processus exhaustif, une cartographie spécifique ABC, ciblée sur les éléments à analyser : pour concevoir, produire, commercialiser tous ces produits ou services, auprès de toutes ces cibles de clients, sur toutes les zones géographiques, etc. quelle est la liste d’activités pertinentes ? Il faut garder présente à l’esprit la difficulté de collecter et de restituer des informations très nombreuses, et donc essayer de simplifier la carte des processus sans perdre de vue chacune des productions intermédiaires significatives qui concourent à la production finale. Néanmoins ce travail devrait faire apparaître à l’inverse quelques zones à détailler plus finement que dans la cartographie des processus.
A titre d’exemple, si plusieurs activités, distinctes et structurantes en termes de coûts sont externalisées, il peut être judicieux de compléter une carte de processus qui n’aurait représenté que la supervision de l’ensemble.
LA NOTION CLE D’INDUCTEUR DE COUT
A chaque élément de cette liste d’activités doit être associé un inducteur de coût, qui va permettre de consommer cette ressource une fois valorisée.
Dans les approches traditionnelles de comptabilité analytique, plus les prismes d’analyse sont précis, plus la part des coûts indirects tend vers 100% : la précision de l’étude dépend donc entièrement des mécanismes de ventilation de ceux-ci. C’est à ce stade que la démarche ABC apporte une plus-value considérable car elle met en évidence le peu de précision des clés de répartition habituellement utilisées.
Prenons une activité banale de « qualification de dossier client » : qu’il s’agisse d’une commande reçue, une demande de crédit dans une banque, … ou de l’orientation du dossier du patient vers le circuit thérapeutique adéquat, la problématique est similaire, identifier les facteurs déterminant le coût de cette activité.
Dans une approche analytique classique, on trouvera fréquemment comme clé de répartition le nombre de dossiers traités, et ce choix, indiqué en légende d’un tableau d’analyse des coûts ne soulèvera généralement pas d’interrogations particulières de la part du management.
Or répartir l’activité au prorata du nombre de dossiers traités (par les acteurs pour les coûts humains, mais aussi par les applications informatiques,…) revient à dire que le temps de traitement est homogène quel que soit le dossier. C’est évidemment rarement le cas. Dès lors l’analyse ABC va rechercher plus finement les facteurs de complexité permettant de déterminer le niveau réel de ressources consommées. Même en simplifiant l’exercice, la clé unique sera souvent remplacée par 3 à 4 critères (inducteurs) dont chacun sera associé à un profil de consommation type de ressources.
Avec le recul, la clé de répartition initiale apparaîtra bien obsolète, quand elle n’aura pas abouti à des analyses complètement fausses ! Une fois les inducteurs définis et mesurés, la phase de production des livrables peut démarrer.
LA PRODUCTION DES ANALYSES
La balance analytique des coûts de l’organisme doit être analysée et parfois retraitée en profondeur. Partant des comptes annuels, et non pas d’une sélection de coûts divers, il convient de procéder méthodiquement à l’élimination des éléments exceptionnels, pour se rapprocher autant que possible d’un fonctionnement normatif futur. A cette occasion on peut choisir de valoriser l’usage d’un bâtiment utilisé par son propriétaire (le bâtiment pourrait aussi être vendu ou rapporter des revenus locatifs), ou à l’inverse éliminer les coûts ponctuels, si l’on a l’assurance qu’ils ne traduisent pas des risques récurrents. Il ne faut pas oublier que l’objectif n’est pas tant de justifier le résultat annuel (ce que l’on fera de toute façon parfaitement avec le relevé de ces retraitements) que de se donner les moyens de se projeter dans la structure de coûts future pour nourrir la réflexion stratégique. A la fin de cette phase, nous aurons définir le périmètre de coûts de l’étude, dont les données vont être manipulées dans tous les sens, mais toujours à total constant.
La liste des activités pertinentes reste à confronter à la balance analytique et à l’organigramme de l’organisme. Certains coûts analytiques pourront être affectés directement aux activités ABC retenues. Pour les autres centres de coût analytiques il faut collecter (en pourcentage) les temps de travail des services par activités ABC et les utiliser comme clés de répartition des coûts analytiques sur les activités ABC.
L’étape suivante est un peu délicate, il faut définir un modèle de consommation de ressource univoque, notamment entre les services support. Toujours dans l’optique de la structure de coût orientée client que l’on recherche, il est possible de faire un travail certes un peu simplificateur, mais qui ne nuit pas à la cohérence recherchée. Une activité de gestion des ressources humaines classique peut ainsi et sans trop de détail se déverser dans les autres activités…s’il ne s’agit pas d’une société d’intérim!
Restent à effectuer les déversements successifs des différentes activités l’une dans l’autre à l’aide des inducteurs de coûts, jusqu’à alimenter le prix de revient des éléments à analyser. Il faudra encore les comparer, relever les incohérences et faire quelques itérations de la démarche pour plus de finesse et pour étayer les découvertes qui vont à l’encontre des idées reçues, mais nous voilà avec une base de coûts qui peut permettre d’orienter une politique tarifaire ou l’ensemble de la stratégie de l’organisme.
En complément il est souhaitable de faire des petits zooms, de reprendre la démarche activité par activité pour identifier d’éventuels effets de suractivité (non qualité, équipe salariée épuisée) ou sous activité sur les résultats obtenus. C’est aussi l’occasion de s’interroger sur la valeur ajoutée intrinsèque de chaque étape, et comme on maîtrise bien les activités en amont et en aval à l’issue de cette démarche d’ensemble, c’est l’occasion pour le Business Analyst de justifier pleinement sa propre valeur ajoutée!
EN PRATIQUE SUR UN TABLEUR
Si le modèle de consommation univoque des ressources n’introduit pas de biais manifeste, un tableur est tout à fait suffisant pour mener la démarche sur une société de taille moyenne. Les matrices suivantes sont nécessaires :
A partir de la seconde étape, une bonne vieille balance carrée permet de vérifier que la masse des coûts analysée est toujours la même.
CIBLAGE DE L’ANALYSE ABC ET OUTILS DISPONIBLES
Selon nous, une analyse ABC est un outil d’analyse stratégique plus que de contrôle de gestion. Sauf à évoluer dans un environnement totalement instable, la construction de la démarche, et l’analyse pas à pas des résultats permettent de comprendre la formation des prix de revient, d’en tirer des orientations stratégiques (commerciales ou organisationnelles) pour une assez longue période. Une analyse annuelle sur la base de comptes arrêtés nous paraît donc suffisante. Rien n’empêche au quotidien d’actualiser les prix de revient obtenus avec des indexations pertinentes, sans devoir reprendre une analyse des coûts de l’organisation du sol au plafond.
Partant de cette conviction que l’analyse ABC doit surtout permettre de prendre des décisions stratégiques, nous en déconseillons la pratique au quotidien, par exemple dans un progiciel de gestion intégré, car les déversements multiples dans les centres de coûts vont plutôt nuire au suivi des opérations. Les coûts traités ne pourront pas non plus faire l’objet d’une analyse préalable, enfin il y aura probablement peu d’enseignements fiables à en tirer d’un mois sur l’autre pour prendre de nouvelles décisions de gestion.
Pour autant, lorsqu’il est nécessaire de construire des analyses très multi dimensionnelles, quelques outils du marché permettent de dépasser l’usage du tableur par une sécurisation de la structure de données et par un chargement rapide et fiable des données de la période à analyser. Si le nombre d’outils disponibles sur ce marché de niche est limité, l’éventail des prix est large, mettant l’approche à la portée de tous les budgets.
Auteur : Laurent Hassid (photo), Directeur Général adjoint de BPMS
Résumé : Jean-Philippe ARESU, Délégué à l’organisation et aux processus de Radio France, attaché à la Direction de la modernisation, revient sur sa collaboration avec l’éditeur Casewise.
Le Web a donné naissance à de nouvelles architectures qui nécessitent une fine modélisation des processus et donc de nouveaux outils. L’heure de la modélisation avec « PaperBoard et Post-it » semble en effet révolue. Dans une chronique précédente, je montrais, en m’appuyant sur l’exemple d’Akazi et de son outil Flowmind, quel type de démarche on pouvait adopter pour modéliser les processus d’une entreprise et en contrôler l’exécution. Pour généraliser le propos, examinons en détail les fonctions que doit comporter un système complet de BPMS (Business Process Management System) :
Un outil de modélisation. C’est évidemment le cœur du système. C’est lui qui servira à formaliser la description des fonctions exercées dans l’entreprise en processus, en applications informatiques. Il permettra de définir également les données échangées, les interfaces avec les autres modules.
Des outils de développement. Ils permettront de formaliser la logique qui régit les processus de l’entreprise, à énoncer les règles de fonctionnement.
Un moteur d’exécution. Il supervisera le déroulement des processus ainsi que les échanges de paramètres.
Un moteur de règles. Il évaluera l’état de tous les objets impliqués dans le déroulement des processus et déterminera si les conditions sont remplies pour en lancer, poursuivre ou arrêter l’exécution.
Un référentiel. Il mémorisera tous les objets manipulés, en particulier les définitions des processus, les règles qui doivent déclencher leur exécution, les contraintes d’intégrité, de sécurité ainsi que les mesures de référence relatives au métier de l’entreprise.
Des outils d’administration. Ils permettront de régler les paramètres de l’ensemble du système et d’obtenir des indicateurs de performance et des statistiques à partir des données collectées lors de l’exécution des processus.
Au sein de l’architecture du système d’information, le BPMS va constituer une nouvelle couche qui va s’insérer en les fonctions de présentation et la logique applicative métier. En général, cette mise en œuvre sera lourde : elle nécessitera en effet d’extraire les règles de fonctionnement de l’entreprise des applications existantes pour les remonter d’un niveau et les intégrer au BPMS. Une fois que l’on aura réalisé cet effort, on aura bien plus de souplesse pour adapter rapidement le fonctionnement de l’entreprise à de nouveaux contextes économiques. Pour mettre en place de nouveaux partenariats par exemple. Toutefois, la profondeur de la réforme à mener pour mettre en place un BMPS nécessite de choisir des fournisseurs de logiciels en qui on peut avoir toute confiance pour plusieurs années. Ces fournisseurs quels sont-ils ?
Trois catégories de fournisseurs
Ceux qui possèdent une large gamme de produits tout d’abord. Ainsi IBM propose WebSphere Business Integrator que l’on peut associer à la gamme WebSphere et MQSeries. Hewlett-Packard propose Process Manager tandis que Microsoft a intégré des fonctions de BPMS à BizTalk Server 2000. Chez Sun/Netscape, le BPMS fait désormais partie de iPlanet Integration Server. Autre catégorie de fournisseurs : les spécialistes des serveurs d’applications ou des connecteurs EAI (Entreprise Application Integration), comme BEA ou Iona. Ces derniers ont fait l’acquisition des sociétés qui avaient développé des BPMS pour intégrer ces technologies à leur offre. Ainsi BEA a acheté The Workflow Automation Corp. pour en intégrer les développements à WebLogic Process Integrator. Iona a porté son choix sur Netfish Technologies. Tibco, WebMethods, Vitria, SeeBeyond, Peregrine, etc. ont également ajouté à leur offre des fonctions de BPMS.
Enfin, dernière catégorie de fournisseurs : les éditeurs indépendants spécialisés dans la formalisation et l’optimisation de processus. Intalio, à l’origine de l’initiative BPMI (Business Process Management Initiative) fait partie de ceux-là. IDS Scheer également. Sa gamme de produits, élaborés autour de la solution ARIS, englobe des méthodes, des logiciels et interfaces pour modéliser, analyser, documenter et évaluer les performances des processus de toute l’entreprise. IDS Scheer travaille en étroite collaboration avec SAP, l’éditeur de progiciels intégrés. Il n’y a rien d’étonnant à cela : on peut en effet considérer le BPMS comme une étape supplémentaire dans l’intégration de logiciels d’entreprise.
La raison de l’apparition des concepts d’urbanisation et d’architecture d’entreprise
Avec la révolution de l’informatique, les systèmes d’information sont devenus de plus en plus complexes : Les entreprises cumulent des projets informatiques hétérogènes pour des besoins bien particuliers. C’est comme un phénomène de mode, tous les services de l’entreprise veulent leur dernière application « tendance » qu’il considère la plus efficace mais ne pense pas à la globalité de l’entreprise : la fameuse vue holistique.
Dans ce cas de figure, la DSI met en place de nombreuses applications s’appuyant sur des technologies différentes. Ceci implique l’intervention de plusieurs experts (coûts supplémentaires) et la multiplication des flux entre ces applications (informations redondantes, origine de la donnée floue, etc). Ainsi de l’autre côté de la frontière, la DSI, considérée comme un autre monde pour les opérationnels, est reconnue comme un centre de coût inefficace:– La maintenance est difficile à piloter: il y a trop de systèmes en place,
– Elle n’est pas réactive face à un nouveau projet par manque de temps et de ressources,
– La stratégie d’entreprise n’est pas alignée au SI mis en place.
– Elle est de plus en plus chère et produit de moins en moins de valeur, par conséquent, il n’y a pas de collaboration stratégique réelle entre le business et la DSI
La naissance d’une nouvelle ère structurante dans l’architecture d’entreprise En 1987, un « IBMer« , John Zachman se fait connaitre en proposant un méta-modèle architectural permettant de structurer la vue holistique de l’entreprise dans le but de gérer sa complexité. A l’origine, il se base sur le système informatique (information system architecture Framework) et étend son travail sur la description globale de l’entreprise (Entreprise Architecture Framework). Il a influencé le gouvernement Américain, et plus particulièrement le Département de la Défense, à mettre en place ce type de Framework au sein de leur agence fédérale afin d’aligner les projets techniques avec les besoins stratégiques.
Avec ces succès et ces ratés au sein du gouvernement, ce travail a été remis à l’Open Group qui l’a standardisé dans la méthode TOGAF. D’autres méthodes sont nées de ces concepts et je m’attarderai sur celles citées ci-dessus qui restent les plus utilisées ou les plus connues. En parallèle en France, plusieurs DSI de grandes entreprises et d’institutions gouvernementales se réunissent dans un groupe de réflexion – le Club Urbanisme des SI – Enterprise Architecture – afin de définir les « best practices » de la mise en place de l’architecture d’entreprise. Afin d’alimenter leur réflexion, ils se basent sur l’Urbanisation des villes pour établir une image schématisée claire de leur entreprise et du SI. Comme pour Zachman, historiquement, L’Urbanisation se concentrait sur l’épuration du SI par rapport aux fonctionnalités attendues sans s’attarder sur les processus métiers.Catégorisation des genres Maintenant de nombreuses personnes s’accordent à catégoriser toutes les méthodologies anglo-saxonnes dans l’Architecture d’Entreprise (EA) et notre méthode bien française dans l’Urbanisation. Est-ce juste un souci de la prolongation de la guerre de cent ans ou y-a-t-il vraiment une différence ?
Sens des termes utilisés
Pourtant, l’analogie à l’urbanisme des villes a également été employée de l’autre côté de l’Atlantique. Roy Schulte (1997) du Gartner group a identifié que les projets d’architecture en IT ne fonctionnaient pas car il n’y avait pas de distinction entre les vues macroscopique et blueprint (détaillée). En effet, le cerveau humain peut très difficilement assimiler un certain nombre d’éléments en même temps comme l’explique cet article concernant les niveaux d’abstraction : Quelle forme pour mon modèle ?
La vue macroscopique, de type city planning, permet de se concentrer sur la relation entre les différents blocs. De plus, pour faciliter la compréhension lors de la lecture, la notion « cohérence forte / couplage faible » est apparue : il doit y avoir un nombre restreint de relation entre les blocs afin de conserver la cohérence de l’architecture et améliorer la visibilité.
Cette vue se rapproche de celle du cours d’Urbanisation & Architecture des Systèmes d’Information du CNAM : « Un Urbaniste conçoit et fait évoluer le SI d’un point de vue global, élabore le plan et l’architecture d’ensemble : Vision globale et générale. L’Architecte élabore les plans d’un édifice et travaille dans le cadre fixé par le POS (Plan d’Occupation des Sols) sur une partie (quartier, îlot,…) : Vision détaillée. L’architecture respecte les règles de l’urbanisme qui aura défini la finalité du bâtiment et les contraintes de construction, mais dispose dans ce cadre d’une grande liberté.« .
Ces différences sont en fait liés aux niveaux d’abstraction, mais ces métaphores ont permis d’introduire plus facilement ces nouvelles notions dans l’entreprise. En effet, il est toujours plus facile d’expliquer un sujet à un interlocuteur lorsqu’il peut remplacer les mots par des images. D’un autre côté, ces mots manquent de précision ou peuvent créer la confusion dans le domaine de l’entreprise : Ne faut-il pas s’orienter vers un vocabulaire plus business ? A mon avis, introduire le sujet avec cette comparaison peut aider, mais la réalisation devrait s’appuyer sur un vocabulaire précis et, dans l’idéal, standardisé.
Points forts des méthodes d’architectures d’entreprises analysées
Zachman fournit un meta-modèle complet permettant de décrire l’entreprise sur plusieurs niveaux à différents points de vue. Pour plus de détails voir le site Zachman ou la définition Wikipedia de Zachman :
Figure 1. Zachman Framework 3.0, 2011
Les principaux atouts de TOGAF sont la méthodologie ADM (Architecture Development Model) qui guide la mise en place d’un projet d’architecture d’entreprise :
Figure 2. The Architecture Development Model
Et la gestion de référentiels avec l’entreprise continuum (pour plus de détails voir TOGAF 9.0). TOGAF est un cadre de travail générique, dirigé par les processus, flexible et fournissant un ensemble de livrables génériques.
L’Urbanisation se concentre principalement sur la cartographie des processus sur les 3 niveaux ci-dessous.
Pour plus de détails, voir le site du Club Urba-EA ou le livre « Le projet d’urbanisation du SI : Cas concret d’architecture d’entreprise de Christophe Longépé, René Colletti et Gérard Balantzian » – 2009.
Figure3. Les couches du système d’information
Comparaison de Zachman, TOGAF et de l’urbanisation sur le terrain
Des différences sont facilement identifiables entre les notions d’architecture d’entreprise, je ne peux pas comparer l’Urbanisation et l’Architecture d’Entreprise, mais Zachman, TOGAF et l’Urbanisation. Sans trop rentrer dans les détails et en me basant sur mes recherches, voici un aperçu de ces trois méthodes selon les principaux critères clés:
Zachman | TOGAF | Urbanisation | |
Stratégie de l’entreprise | ++ Le but est d’aligner les exigences de la stratégie dans l’ensemble des processus de l’entreprise | ++ La démarche exige de commencer l’analyse par la stratégie de l’entreprise. | +– Bien que décrite comme une méthodologie top-down, l’utilisation de l’urbanisation est appliquée pour établir la cohérence des processus du SI et établir des cartographie applicatives. |
Meta-modèle | ++ Meta-Modèle très exhaustif (abordant tous les sujets et niveaux de l’entreprise), mais n’est pas formellement décrit | +– Méta-modèle simple et formalisé | – Proposition d’un modèle générique, définition peu formalisée |
Process step-by-step | – Aucun document n’est disponible | ++ Description exhaustive comment créer l’architecture step-by-step à travers l’ADM | +– Description simplifiée des actions à réaliser |
Référentiel | – Aucun | ++ L’entreprise continuum défini la sémantique de référence à utiliser | – Se base sur des études de cas et la sémantique est peu précise et très métaphorique |
Architecture cible/Change management | – Il est possible de modéliser l’architecture cible mais il n’y a pas de guide pour la transition | ++ Guidelines pour la planification de la migration vers la cible et le change management | – Bien que l’objectif soit d’amener plus de cohérence dans leSI, il n’y a pas de démarche formalisée pour atteindre la cible |
Périmètre | ++ Une description très exhaustive de l’entreprise est prise en compte | ++Elle prend en compte les 4 niveaux d’abstraction : métier, fonctionnel, applicatif et technique | +– Bien que par principe, elle prend en compte les mêmes 4 niveaux, les urbanistes se concentrent sur les 3 premiers et son souvent peu impliquée dans la stratégie et l’organisation globale de l’entreprise |
Source | +– Le Framework graphique est facilement accessible, mais le détail explicatif est réservé aux membres. | ++Une documentation exhaustive est disponible sur le web : TOGAF 9.0 | +– Les informations sont accessibles à travers des livres. L’accès aux détails des informations est limité aux membres du club urba-ea. Mais ce club publie des livres explicitant des cas concrets. |
Complexité d’utilisation | – Il est nécessaire d’être certifié afin de comprendre correctement l’utilisation du Framework. | – Vue l’exhaustivité de la documentation, la certification est également nécessaire. | ++ La non-standardisation de l’urbanisation donne un champ assez libre sur son utilisation. Elle est ainsi plus facile à mettre en place. |
Ce que j’en pense
On peut voir qu’il y a un décalage entre la définition des termes et la réalité : l’Urbanisation ne se focalise pas seulement sur la macro cartographie, mais entre aussi dans le détail et inversement pour l’Architecture d’Entreprise, bref les niveaux d’abstraction sont nombreux. De plus, il n’y a pas de différence entre l’Architecture d’Entreprise et l’Urbanisation, mais entre toutes les méthodes visant la gestion de la complexité de l’entreprise. Au final, quelque soit la méthode et le modèle employé, les techniques fondamentales de modélisation seront nécessaire afin de gérer la complexité de l’objet organisationnel, technologique et fortement social qu’est l’entreprise moderne. D’ailleurs, en France, les cabinets de conseil se basent sur le concept de l’urbanisme en ajoutant plusieurs couches inspirées des autres méthodes pour en révéler une architecture d’entreprise optimisée. Et vous, quelle est votre approche ?
Auteur : Jérémie Cohen – Consultant,
——————————————————————–
Références
– Namba & Iijima, City Planning Approach for Enterprise Information System – 2004
– CNAM U&ARSI « Urbanisation & Architecture des Systèmes d’Information »
– Roy Schulte, Architecture and Planning for Modern Application Styles, 1997
– Camille Salinesi — Laure-Hélène Thevenet Enterprise Architecture, Des problèmes pratiques à l’innovation, 2008
– C. Longépé, Le projet d’urbanisation du SI, Démarche pratique avec cas concret, 2006.
– A Comparison of the Top Four Enterprise-Architecture Methodologies – 2007
– TOGAF 9.0 Referential
– Club Urba SI – EA
– The Open Group
La norme ISO 9000:2000 définit lâ??efficacité comme étant « le niveau de réalisation des activités planifiées et [le niveau] dâ??obtention des résultats escomptés ».
Lâ??efficience est quant à elle définie par la norme comme étant « le rapport entre le résultat obtenu et les ressources utilisées ».
Véritable sésame de l’entreprise moderne, les projets SOA (Services Open Architectures) sont un formidable levier de croissance et un moteur de productivité sans équivalent sur le marché.
Incontestablement adoptées et reconnues, les technologies SOA sont aujourd’hui omniprésentes et largement utilisées par les grands comptes qui, grâce à leur apport, ont pu moderniser leurs systèmes d’information et proposer plus rapidement des services innovants à valeur ajoutée. Comment expliquer un tel succès ? Tout d’abord, il convient de démystifier la complexité plaquée sur SOA.
Comme toute nouvelle démarche, cette approche a bouleversé les standards existants et fait naître quelques craintes quant à son adoption et à sa pérennité. Mais les éditeurs, les intégrateurs et les grands donneurs d’ordres (notamment les compagnies d’assurances et les banques) ne s’y sont pas trompés et ont largement porté ces projets générateurs de plus-value à court, moyen et long terme.
Forte de ce succès et de la démocratisation du concept, l’approche SOA est devenue totalement légitime et prend une nouvelle dimension en se tournant vers les entreprises du middle market en attente à juste titre de solutions performantes leur permettant d’appuyer leurs systèmes d’information sur les meilleures pratiques du marché.
A bien y regarder, les besoins et la complexité des SI des entreprises du middle market (applications hétérogènes, besoins d’ouverture du SI vers l’extérieur, recherche d’interopérabilité…) se prêtent parfaitement à la mise en œuvre de l’approche plus fluide et industrielle générée par les architectures SOA.
Le middle market représente également une part importante du tissu économique. En quête constante de compétitivité, ces PME investissent largement dans la mise en œuvre de SI toujours plus performants. Depuis un an, SOA se démocratise pour répondre à ces attentes. De nombreux déploiements largement présentés et mis en avant en sont la parfaite illustration.
Un point intéressant tient également à la maturité des entreprises du «middle market » : en raison de l’évolution des offres du marché, elles n’hésitent plus à adopter une démarche cohérente et normalisée dans la mise en place de leur système d’information. Conscientes de la nécessité de s’appuyer sur une architecture flexible capable de prendre en compte leur rythme de croissance (évolution organisationnelle, ouverture vers de nouveaux partenaires…), ces PME mettent les besoins d’orchestration, d’unification et de communication au centre de leur démarche.
Grâce à cette approche essentiellement fondée sur la démocratisation des technologies d’intégration (EAI) et de gestion des processus métiers (BPM), elles bénéficient dès lors des fondamentaux liés à la mise en œuvre de la démarche SOA. Notons que les technologies d’EAI et de BPM ont largement su s’adapter aux besoins des entreprises du middle market et sont pour une grande partie à l’origine de la diffusion des technologies SOA sur le marché.
Au travers d’une approche stratégique (grands comptes) et tactique (entreprises du middle market) guidée par la recherche de productivité, les architectures SOA ne sont donc plus un mythe mais une réalité désormais unanimement reconnue comme un pré requis nécessaire pour permettre aux entreprises de créer de la valeur en s’appuyant sur une infrastructure IT performante.
Ainsi, les entreprises pourront aisément dégager de nouvelles opportunités en déployant des services innovants (services web, Mashups réalisés avec les sites de leurs partenaires…) et donc améliorer leur avantage concurrentiel sur un marché dont le cœur se nourrit des notions de compétitivité et de « time to market ».
Auteur : Luc SIMON
Famille : Qualité
Définition BPMS
Définition ISO 9000 : Aptitude d’un ensemble de caractéristiques intrinsèques à satisfaire des exigences pré établies.
Les outils de gestion de référentiel processus font souvent référence à leur approche systémique des organisations : cette notion fait référence à la notion de système défini par la norme ISO 9000 :2000 comme étant un ensemble dâ??éléments corrélés ou interactifs ».
Les référentiels processus gèrent sous forme de base de données lâ??ensemble des éléments descriptifs (tâche, organisation, application informatique,â?¦) et leurs relations (« est utilisé par », « doit être informé de »,â?¦) de sorte quâ??aucun élément du référentiel ne doit être isolé.
La démarche ABC vise à fournir des analyses de coût, et le plus souvent de rentabilité, selon des axes d’analyse divers (produit, client, fournisseur,…) reposant sur la consommation réelle de ressources de chaque activité (ou sous-processus).
Partant du principe que la conception, la production et la commercialisation d’un produit ou d’un service consomment des activités, que chacune de ces activités, prise isolément, consomme des ressources que l’on peut quantifier, il est alors possible de calculer les ressources réellement consommées par tout produit ou service vendu. L’impact le plus manifeste de la méthode ABC est de remplacer les coefficients de frais généraux, ou de coûts indirects, par des consommations aussi précises que nécessaire de ressources de services support.
Cette approche est tout à fait compatible avec une démarche processus dans la mesure où elle s’appuie sur la décomposition de processus en activités et en tâches dans l’optique de qualifier et de quantifier les ressources consommées à chaque niveau. En quelque sorte, la démarche ABC (pour Activity Based Costing) constitue la vue « mesure des coûts » d’un référentiel processus.
Les termes de base
Dans « Activity Based Costing », la notion d’activité peut être définie comme une succession de tâches exécutées de manière répétitive : préparer la commande, expédier la livraison,…
A la décomposition traditionnelle processus- activité – fonction (ou tâche), s’ajoutent les notions :
– de ressources (humaines et techniques) consommées par chaque fonction ;
– d’inducteur de ressources (indicateur mesurable permettant de quantifier la consommation de ressource par activité : effectif, m2,…) encore appelé « ressource driver » ou parfois « cost driver » suivant les méthodes ;
– d’inducteur d’activité (événement déclenchant l’activité : validation d’une commande, …) ;
– d’objet de coût (« cost object ») traduisant les éléments dont il faut déterminer les coûts (produit, client,…).
Les étapes de la démarche
La première étape d’une démarche ABC, consiste à identifier les activités, les ressources et les inducteurs (activity driver et ressource driver).
Ensuite, il s’agit de quantifier ces éléments.
L’analyse de l’organisation permettra de quantifier les ressources utilisées par chaque tâche, et par conséquence par chaque activité.
Reste à déterminer le coût de chaque ressource.
Dans la plupart des cas, la comptabilité (générale et analytique) fournira des informations globales sur les coûts des ressources. Ces coûts devront être éclatés en coûts directs (directement affectable à un produit, un canal de distribution, un service), coûts indirects affectables à une activité et coûts indirects non affectables. Les coûts de direction générale ou de publicité institutionnelle rentreront par exemple dans ce dernier groupe.
Avantages et inconvénients de la méthode ABC
Une approche classique de comptabilité analytique consistera à allouer les coûts indirects selon des clés de répartition. Cette méthode est peu précise car :
– les clés de répartition sont souvent définies de manière empirique (pourcentage) traduisant davantage la vision estimée que la consommation réelle des ressources ;
– cette répartition est souvent mono dimensionnelle : il faut privilégier un axe d’analyse (le produit par exemple), le même flux ne pouvant être réalloué suivant différents axes.
En se focalisant sur les ressources consommées à un niveau fin, l’approche ABC permet ensuite de réaliser des consolidation par produit, clients ou canal de vente et d’obtenir des analyses multidimensionnelles. Elle fournira sans conteste un coût plus proche de la réalité économique. En contrepartie, elle nécessitera un travail d’analyse préalable important afin de pouvoir alimenter le modèle en données pertinentes.
Face aux limites des méthodes japonaises, cet ouvrage vous propose une nouvelle façon de penser les systèmes de production. Il vous fournit les éléments d’une transition en douceur entre une organisation classique par ateliers spécialisés et des conceptions cellulaires plus efficaces. Toutes les questions de méthodologie, de qualité, d’identification et de résolution des problèmes, de main d’œuvre et de réduction des délais sont abordées. Salim Bouzekouk travaille à la promotion des techniques de production au plus juste et à l’amélioration continue.
Auteurs : Salim Bouzekouk
Autant de concepts, porteurs d’un sens commun : Celui de « l’action dans l’organisation ».
Comment s’y retrouver ?
Comme un bon schéma vaut mieux qu’un long discours, je propose un modèle simplifié permettant de mettre en relations, ces concepts, dans le cadre de référence de l’EA.
Processus
Le mot processus est d’origine latine. Il signifie « progrès, progression ». Dans le cadre économique de l’entreprise, il désigne le déroulement, d’un ensemble d’opérations successives, organisées, en vue de produire une valeur tangible pour son utilisateur (ou son organisation). Il transforme des données d’entrée en données de sortie, un peu à l’image d’une fonction, mais dont les contributions sont planifiées, cadencées, et ordonnées, dans des conditions maîtrisées selon un mode d’emploi, et contrôlables à tout moment. Les processus métiers doivent être efficaces, à un moment donné, et devenir de plus en plus efficients. S’ils ne le sont plus, c’est que le contexte économique de l’entreprise a probablement changé.
Un processus peut être transverse à l’entreprise. L’analyse systémique de l’entreprise par l’approche des processus permet d’identifier les interfaces entre les différents « métiers ». Les éléments d’entrée d’un processus sont généralement les éléments de sortie d’autres processus. C’est ainsi qu’ils s’enchaînent. Ce peut être des données, des objets ou des évènements, contenus dans des flux. Le découpage d’un processus en tâches, en sous processus, ou en deux processus distincts, va dépendre de sa complexité, et par voie de conséquence, des responsabilités associées.
Le processus répond essentiellement aux questions : QUOI ? POURQUOI ?
Exemples : Quand il transporte ses passagers d’un aéroport à l’autre, le pilote fait un acte économique pour sa compagnie. Il est au centre d’un processus « Gérer un Vol » dont les objectifs sont : (C’est le POURQUOI)
Le QUOI : Vol, Appareil, Passager, Pilote, Aéroport …
Il est intéressant de préciser, que dans la vraie vie, un processus, comme « Gérer un Vol » n’est pas automatisable de bout en bout, même avec le pilotage automatique. La moindre boisson, ou jeu distribué aux passagers, fait l’objet d’une description dans une procédure.
Procédure
Le mot procédure désigne une série de formalités ou de démarches à accomplir, et/ou un ensemble de règles auxquelles il faut se soumettre, dans une situation déterminée, en vue de réaliser le processus cible. La procédure est donc un descriptif organisationnel détaillé à l’image d’un mode d’emploi, ou d’une recette possible à suivre scrupuleusement pour espérer remplir les objectifs du processus. Si la procédure n’est pas respectée, les données de sorties du processus ne seront pas conformes aux exigences attendues.
Une procédure d’entreprise, appelée également procédure métier ou procédure opérationnelle :
A un et unique processus, peuvent correspondre plusieurs procédures :
• Il peut s’agir d’une procédure principale, accompagnée de procédures challengers et/ou complémentaires
Par exemple, pour le sous-processus de débarquement, on peut avoir : la procédure de débarquement « PLAN A» mettant en œuvre un satellite de débarquement, une autre procédure de débarquement, par bus, ou enfin la procédure de débarquement d’urgence, par activation des toboggans. C’est le « PLAN B »…
• ou il peut s’agir d’une procédure par type d’objet
Par exemple la procédure « Check list » du même sous-processus « Décoller » sur Boeing n’est probablement pas la même que sur Airbus… (l’art du consultant, est de pouvoir parler de quelque chose qu’il ne connaît pas … lol).
Remarque: Le processus définit le métier de l’entreprise en faisant abstraction de son organisation sous-jacente, tandis que la procédure aligne le métier de l’entreprise sur son organisation.
Un des sous processus parmi les plus périlleux est « Faire décoller l’avion ». Pour faire décoller l’avion, le pilote doit suivre la procédure adéquate (sur Airbus A380) qu’il a apprise à l’école de pilotage, et qui fait l’objet d’un guide précis : La « check-list ».
La procédure répond, en plus, à la question : QUI ?
Procédé / Tache
Le procédé désigne une « méthode à façon » (ré)utilisée en vue d’obtenir un résultat déterminé. Les procédés qualifient les taches élémentaires d’une procédure.
Exemples :
QUOI ? POURQUOI ?
Le procédé répond de plus aux questions : QUAND? OU ? COMMENT ?
Le mode pilotage répond de plus à la question : COMBIEN ?
Conclusion
Un processus au sens large, est caractérisé par les paramètres suivants:
Auteur : Emmanuel PESENTI
Processus, la voie de la ÉDITEUR ADMINperformance propose un nouveau mode d’organisation et de management fondé sur un « modèle de maturité » construit pour garantir la compétitivité des entreprises et la satisfaction client. Ce nouveau modèle, qui implique un pilotage par les processus client, situe l’entreprise et toutes ses structures sur cinq niveaux d’excellence de Réactif à Leader, remettant en cause certains paradigmes du taylorisme. Il répond à neuf critères permettant l’amélioration de l’entreprise : alignement stratégique, vision processus, alignement du SI, satisfaction client, performance économique, maîtrise des risques, optimisation, reconstruction et innovation, animation et gestion du changement. Fort de l’expérience de plus de trente experts praticiens, ce livre présente des méthodes et des concepts novateurs et expose les meilleures pratiques mises en œuvre en entreprise.
Sommaire
Dossier introductif. Piloter la performance par les processus : modèle de maturité. Nécessité d’un modèle de maturité du pilotage de la performance par les processus. Quel message doit délivrer un modèle de maturité ? Les domaines à évaluer : des moyens pour conduire le changement. Applications du modèle de maturité. Déployer le modèle de maturité sur votre entreprise.
1. Implication de la direction générale et alignement stratégique. Pourquoi les dirigeants doivent s’impliquer ? L’alignement stratégique : un projet qui irrigue l’entreprise.
2. Vision processus. Comment réussir sa vision ? Quelques outils de déploiement des stratégies processus. Référentiel d’entreprise et carnet de santé
3. Alignement du système d’information. Comment aligner le système d’information? Alignement du SI et modélisation des processus métier
4. L’orientation et la satisfaction client. Les clés de l’orientation client. Client interne et SI
5. Performance économique de l’entreprise et des opérations. Piloter la création de valeur
6. Maîtrise des risques et gestion de la conformité. Maîtrise des risques opérationnels et financiers
7. Amélioration et optimisation des processus. Deux angles d’analyse pour l’amélioration des processus. Optimisation des processus dans une multinationale de négoce et de service
8. Reconstruction et innovations. Démarche Lean Six Sigma pour piloter par les processus. Retour d’expérience de la refonte des processus de maintenance applicative du SIMAT
9. Animation et gestion du changement. L’animation du dispositif du pilotage par les processus. Le changement et l’homme au travail. Cultures et Processus
Auteurs : CLUB DES PILOTES DE PROCESSUS (Collectif)
Site : Lavoisier
Editeur : Lavoisier – Coll. Management et informatique
En informatique la modélisation des données était jusqu’à présent au centre de toutes les méthodes de conception. Aujourd’hui la modélisation s’étend aux “processus “ ce qui revient à davantage intégrer les » processus-métier » dans la conception des logiciels. Le but de cet ouvrage est d’apporter des éléments concrets à ceux qui adoptent une approche par processus en offrant une vue la plus large possible de la notion de processus dans l’entreprise : quelles définitions ? quels langages de modélisation et quels modèles ? quels outils ? L’ouvrage comporte différents exemples, ainsi que plusieurs bibliothèques de modèles génériques de processus métier (banque, assurance, CRM…).
Auteurs : Chantal Morley,Jean Hugues,Bernard Leblanc,Olivier Hugues
Référence ISBN: 210-007099
Évaluation, modélisation, mise en œuvre
En informatique la modélisation des données était jusqu’à présent au centre de toutes les méthodes de conception.
Aujourd’hui la modélisation s’étend aux « processus » ce qui revient à davantage intégrer les « processus-métier » dans la conception des logiciels.
Cet ouvrage apporte des éléments à ceux qui veulent adopter une approche par processus en outre il offre une vue sur la notion de processus dans l’entreprise :
• Quelles définitions ?
• Quels langages de modélisation?
• Quels modèles ?
• Quels outils ?
Auteurs : C.Morley, J.Hugues, B.Leblanc, O.Hugues
Référence ISBN : 2100070992
Deux démarches fortement imbriquées
On note de nombreux points communs entre COSO2 et la mise en œuvre d’un référentiel processus et les premières étapes d’une démarche projet seraient dans les deux cas identiques :
– comprendre et cartographier le ou les métiers de base de l’entreprise,
– les décomposer macro-processus métier ou support,
– puis en processus métier et processus support,
– obtenir la validation des organes de direction sur la pertinence de la représentation du tableau ainsi obtenu par rapport à leur connaissance de leur entreprise et de sa stratégie.
Sur cette base, un projet référentiel processus va poursuivre la décomposition « top down » jusqu’à parvenir à un niveau de détail par entité organisationnelle permettant d’éditer les procédures en vigueur, mais aussi de lister les applications informatiques touchées, les postes de travail concernés, tâche par tâche, éventuellement les compétences ou les systèmes de pilotage mis en oeuvre.
Comment intégrer les risques au référentiel
Un projet risques va devoir introduire une dimension ou une vue risques dans ce tableau et structurer les différentes caractéristiques des risques pour pouvoir les gérer (nature, probabilité, évaluation..). La collecte des incidents selon Bâle 2 ou toute autre forme de recensement permettra de positionner chaque risque à un niveau adéquat, qui n’est généralement pas le niveau de granularité le plus fin d’une analyse référentiel processus.
Comparé à un projet de référentiel d’entreprise au périmètre maximal intégrant l’ensemble des prismes d’analyse des processus et du S.I., le travail d’analyse, pour un projet strictement orienté « risques », apparaît considérablement allégé.
Tout d’abord, avec une démarche et des étapes intermédiaires très largement communes, et en dehors d’une course aux échéances de première mise en œuvre SOA ou Bâle 2, il serait vraiment dommageable pour une entreprise – notamment s’ils coexistent déjà- de ne pas lier ces deux projets dans la même base de donnée – référentiel.
On notera qu’insérer un projet risque au sein d’un projet référentiel processus offre une garantie de revue exhaustive de l’organisation et des processus sur le périmètre choisi.
Mais au-delà, les textes réglementaires n’ont pas vocation à produire de belles cartographies de risques mais bien à les maîtriser ou mieux, à les supprimer.
Les apports de l’intégration de la vue Risques
Positionner un risque en haut de la pyramide des processus qui le génère (dans le cadre d’un projet processus), permet d’avoir immédiatement à disposition l’ensemble des procédures, acteurs, et systèmes concernés -autrement dit l’environnement de contrôle-. C’est tout de même la matière première, dans toute sa diversité, des changements nécessaires à la gestion du risque, qu’il s’agisse d’automatisation de tâches ou de contrôles, de formation ou de modifications de procédures.
La base de données référentiel apparaît aussi comme un outil indispensable pour « l’entité indépendante » responsable de la gestion des risques opérationnels, des procédures et des contrôles de « l’approche avancée » de Bâle 2.
On ajoutera que positionner un contrôle dans un contexte qui permet d’identifier les ressources qu’il consomme permet d’en réévaluer rapidement le coût, et le cas échéant la pertinence, s’il n’est plus en rapport avec les bénéfices qui en sont attendus.
Cependant, insérer un projet risques dans un projet référentiel processus, si cela ne retire rien aux bénéfices précédemment décrits, ne suffit pas. L’obligation de documenter les contrôles nécessite plusieurs étapes supplémentaires :
– sélectionner des contrôles à effectuer au sein des systèmes opérationnels,
– les adresser à chacun des contrôleurs,
– suivre les contrôles et en conserver l’historique,
– générer documentation des rapports.
Toutes choses qui nécessitent de s’appuyer sur des outils complémentaires à la base de données référentiel (parfois proposés par les mêmes éditeurs), et des interfaces avec systèmes opérationnels en amont.
Tirer profit des contraintes réglementaires
En conclusion, plus les législateurs se sont adressés à des structures puissantes (cotées SEC) et homogènes (établissements financiers) plus ils ont pu être exigeants sur la définition d’un cadre d’analyse des risques poussant les entreprises à s’auto évaluer, pour aligner stratégie et profil de risques acceptés.
Nous aurions tendance à être encore plus ambitieux et à proposer d’utiliser les outils de modélisation de processus désormais matures pour appliquer la stratégie de façon cohérente non seulement avec la politique de risques, mais simultanément avec l’organisation des processus et avec toute autre dimension de ressource suivie dans la base de données.
Pour les dirigeants des entités qui ne sont pas concernées par SOA et Bâle 2, et donc avec moins de contraintes formelles sur les contrôles, mener un projet référentiel processus en intégrant la dimension risques peut s’avérer une façon extrêmement stimulante de rechercher une meilleure maîtrise de l’avenir de son entreprise, tout en recherchant pas à pas une utilisation plus rationnelle des ressources de l’organisation.
Lire la première partie de l’article
Auteur : Laurent Hassid
Suite à la débâcle d’ENRON, annoncée en 2001, et à celle de nombreuses autres sociétés américaines ou européennes, des textes de loi sont venus dans la plupart des pays occidentaux apporter des contraintes d’informations nouvelles aux sociétés cotées et éventuellement à d’autres sociétés commerciales. Deux grands objectifs communs caractérisent ces textes :
– détecter plus précocement les risques encourus par les actionnaires
– et prévenir les comportements frauduleux des dirigeants, par des obligations de communication plus explicites et des peines encourues nouvelles ou aggravées.
C’est l’approche des risques d’une entreprise qui va retenir notre attention dans le présent article, tel qu’il ressort de textes aux abréviations désormais courantes : LSF, SOA et Bâle2.
La loi de Sécurité Financière (LSF)
La loi du 1er août 2003 sur la sécurité financière (LSF) couvre trois volets principaux : la modernisation des autorités de contrôle des marchés financiers, la sécurité des épargnants et des assurés et enfin le contrôle légal des comptes ainsi que la transparence et le gouvernement d’entreprise. Ce dernier volet s’adresse non seulement aux sociétés faisant appel public à l’épargne, mais à toutes les sociétés anonymes.
La LSF confie au Président d’une société la responsabilité de la rédaction et du contenu d’un rapport annuel sur les procédures de contrôle interne mises en place dans l’entreprise.
Ce volet de la LSF vise à imposer un usage étendu et très pragmatique du contrôle interne, dans une acception plus anglo-saxonne proche du contrôle des opérations (par opposition à une simple obligation formelle). Cette fonction renforcée du contrôle interne et des reportings associés doit permettre d’instiller une réelle culture de gouvernement d’entreprise entre les organes de contrôles (conseil d’administration ou de surveillance) et les organes de direction pour au final déboucher sur plus de transparence vis-à-vis des actionnaires.
La loi Sarbanes-Oxley
Le Sarbanes-Oxley Act (SOA) de 2002 concerne les seules sociétés cotées sur les marchés financiers nord américains auprès de la SEC et visait à sa création à apporter une réponse rapide à la crise de confiance en la fiabilité des informations communiquées par les entreprises. Le SOA est donc centré sur le contrôle de ces informations et il exige de surcroît que les directeurs généraux et directeurs financiers (CEO et CFO) engagent leur responsabilité sur la fiabilité de celles-ci.
L’article 404 traite des obligations liées au contrôle interne dans l’optique de la fiabilité de l’information financière délivrée, il introduit l’exigence d’un rapport d’évaluation de la qualité du contrôle interne dans l’entreprise, l’obligation (lourde) de documenter les tests de contrôle interne réalisés, et met un fort accent sur les dispositifs anti-fraudes. Cet article rend obligatoire l’utilisation d’un cadre d’analyse reconnu en matière de contrôle interne et cite en substance le référentiel COSO.
Ceci nous amène à nous arrêter quelques instants sur le cadre conceptuel du référentiel méthodologique COSO 2. Il se présente comme un cube dont les 3 dimensions sont :
1 Concourir à la réalisation des 3 objectifs suivants :
– la réalisation et l’optimisation des opérations
– la fiabilité des opérations financières
– la conformité aux lois et règlements
2 Analyser pour chacun de ces trois objectifs les cinq composantes du contrôle interne suivantes :
– l’environnement de contrôle,
– l’évaluation des risques,
– les activités de contrôle,
– l’information et la communication,
– le pilotage du contrôle interne
3 Appliquer cette double approche à chaque activité et fonction de l’entreprise
COSO 2 promeut, sur la base de cette analyse en « cube », l’émergence de la notion de gestion des risques de l’entreprise, « l’Enterprise Risk Management ou ERM ».
Cette gestion des risques doit être considérée dans une optique de pilotage : quels risques veut-on absolument éviter, quels risques sont inutiles, quels risques est-on prêt à prendre pour profiter de quelles opportunités ou conserver quel avantage ?
Il faut souligner à cette occasion qu’une organisation qui souhaiterait ne jamais prendre de risques se verrait par son immobilisme condamnée à disparaître.
Nous retiendrons à ce stade que, pour la LSF comme pour COSO 2, l’un des enjeux, (extrêmement positif) est d’amener l’entreprise à aligner sa stratégie et sa gestion des risques.
La réglementation dite « Bâle2 »
Le dispositif réglementaire Bâle 2 concerne les établissements financiers européens, a été publié en 2004 et vise à une homologation des établissements par le régulateur en 2006. Il nous apporte des contraintes méthodologiques fort intéressantes en précisant des étapes de perfectionnement à suivre et en décomposant les risques par grande nature pour les établissements financiers : risques de Crédit, risques de Marché, et risques Opérationnels.
Cette dernière catégorie retiendra plus particulièrement notre attention car c’est la moins spécifique au secteur bancaire, mise à part la nature de la récompense offerte aux plus méritants (la possibilité de diminuer la mobilisation de 15% de fonds propres sur les risques opérationnels de « l’approche de base » si la méthode suivie le justifie).
Le premier niveau de perfectionnement est « l’approche standard » pour laquelle il faudra :
– mettre en place un dispositif de collecte des incidents, avec une historisation longue et une consolidation le cas échéant (risques réalisés),
– découper les activités de la banque par ligne de métier,
– identifier les risques opérationnels de la banque, et dégager leurs composantes,
– évaluer les pertes potentielles liées à la réalisation de ces risques,
– définir des indicateurs de suivi des risques, construire et diffuser largement des reportings internes sur les risques, et mettre en place des plans d’actions pour faire suite à ces reportings.
A ces premières obligations s’ajoutent pour « l’approche avancée » :
– mettre en place une entité indépendante, responsable de la gestion des risques opérationnels, des procédures et des contrôles,
– utiliser des données externes pour la prise en compte de risques extrêmes,
– calculer les fonds propres à mobiliser sur la base des incidents et des données externes collectés.
Laurent Hassid
Des processus schizophréniques
Un nombre sans cesse croissant d’entreprises recensent leurs processus métier pour des raisons très diverses. Les processus constituent en effet le point de départ des projets axés sur l’amélioration de la qualité et de l’efficacité, les projets d’homologation (par exemple, ISO), la gestion de la performance, la satisfaction client, l’informatisation, les restructurations, les fusions, etc.
La connaissance des processus ainsi acquise oblige les entreprises à déterminer s’ils répondent ou non aux besoins des différents intéressés. Dans la littérature classique sur le management, cet aspect est souvent associé à ce qu’il est convenu d’appeler les disciplines de valeur, telles que l’orientation stratégique de l’entreprise (Treacy & Wiersema). Pour commencer, les entreprises doivent se concentrer sur l’excellence opérationnelle, le leadership dans le domaine des produits, ou encore la connaissance du client. L’entreprise doit être très performante dans chacun de ces domaines, mais le succès ne viendra qu’avec le temps, lorsqu’elle se sera distinguée de ses concurrents dans l’un de ces domaines. Les « performances olympiques minimales » requises dans les deux autres représentent aujourd’hui un enjeu important pour les entreprises. Le plus urgent et le plus évident réside dans la pression en vue d’améliorer constamment le rendement. En raison de la mondialisation, les entreprises ont désormais la possibilité de mettre en place leur production et leurs services là où ils sont le plus rentable. Surtout, la conjoncture boursière défavorable actuelle accentue encore la pression sur les budgets et les moyens disponibles. Ensuite, les progrès technologiques entraînent une complexité croissante des produits et des services. Enfin, les clients hésitent de moins en moins à exprimer leur point de vue, et ils exigent une réponse personnalisée à leurs besoins. Grâce à Internet, ils sont mieux informés et les échanges de points de vue en ligne ont plus d’effets que toutes les campagnes marketing. Toutes ces évolutions contraignent nombre d’entreprises à rechercher le juste équilibre entre les différentes disciplines de valeur. Cette évolution a donné naissance à des processus schizophréniques qui rendent la réalisation des objectifs de l’entreprise plus difficile.
La réponse appropriée consiste en une approche intégrée combinant les points forts de la gestion des processus métier (BPM, business process management), en flux tendu et Six Sigma.
Méthode intégrée
La prolifération des méthodes mises en oeuvre pour aider les entreprises à devenir plus performantes, plus axées sur le client et plus innovantes fait que, pour bon nombre d’entre elles, l’arbre finit par Auteurs : Kim Oostvogels et Jan Bellaert – MÖBIUS Source : Business Proces Magazine – Octobre 2008 cacher la forêt. Bien que la plupart des méthodologies et des structures aient de nombreux points communs, les atouts de chaque méthode viennent simplement de son origine.
La gestion des processus métier (BPM) trouve sa source dans le mouvement de refonte des processus métier (BPR, business process re-engineering) né dans les années 80. Elle a apporté des améliorations radicales par l’introduction de modifications profondes dans les processus et les entreprises. Visant à remédier aux inconvénients de la BPR, la BPM est axée sur l’expansion permanente des améliorations. Cela implique l’instauration d’une culture qui met l’accent sur l’optimisation de la création de valeur par une gestion rationnelle et par une informatisation poussée.
La figure 2 présente une « pratique recommandée » pour l’application pratique de la BPM en 7 étapes :
1. Analyse : toute initiative de BPM commence par l’analyse du contexte de l’entreprise. Il est impossible de porter un jugement de valeur sur le fonctionnement d’une entreprise et le déroulement de ses processus sans une connaissance approfondie de ses objectifs stratégiques et opérationnels. Il est alors possible de cataloguer les anomalies dans les processus, les systèmes et l’entreprise – éventuellement comme autant d’opportunités. Cette étape permet de s’assurer que les moyens de l’entreprise sont utilisés conformément à sa stratégie ; elle offre en outre une vue d’ensemble de l’exploitation. Cela permet également de déterminer l’étendue de l’initiative de BPM et de définir les priorités.
2. Diagnostic : la phase de diagnostic identifie les améliorations permanentes requises à partir de la situation actuelle. De même qu’un médecin doit consacrer du temps à l’examen de son patient, l’entreprise doit étudier ses processus de manière approfondie. La crédibilité du médecin et du traitement proposé dépend de son professionnalisme dans l’établissement du diagnostic ; ce principe s’applique également à une initiative de BPM. Une analyse structurée et chiffrée des dysfonctionnements et des opportunités actuels constitue le premier pas pour convaincre et mobiliser tous les intéressés dans l’entreprise.
3. Ciblage : les résultats de la phase de diagnostic indiquent les améliorations envisageables. À partir de là, il est essentiel de définir les objectifs de l’initiative de BPM en termes quantitatifs.
4. Refonte : le pivot de toute initiative de BPM est la refonte des processus. L’exécution de toutes les étapes précédentes permet de cibler le processus de conception. Cette phase consiste à décrire les activités typiques de chaque processus, ainsi que les acteurs assurant leur exécution et des systèmes prenant en charge l’exécution des processus futurs.
5. Validation : une fois la conception des processus futurs terminée, il est possible de mettre en place le plan détaillé d’exécution des nouveaux processus. Dans certains cas, cela peut nécessiter des investissements informatiques. L’étape de validation permet de définir les différentes phases de conception des processus futurs, selon les moyens disponibles, et de s’assurer que l’entreprise ainsi réorganisée peut atteindre les objectifs fixés.
6. Implémentation : l’étape six consiste à mettre les nouveaux processus à exécution. La communication, le transfert de connaissances et le coaching individuel sont essentiels au cours de cette phase.
7. Suivi : la dernière étape d’une initiative de BPM consiste à mesurer les performances des processus et à examiner dans quelle mesure les objectifs fixés ont été atteints. Une fois la dernière étape du cycle BPM achevée, il est possible d’en lancer un nouveau.
Le succès de la méthode de BPM dépend de l’intégration de la stratégie de l’entreprise ainsi que de ses efforts permanents en vue d’apporter des améliorations solidement justifiées et visibles.
La gestion en flux tendu est une philosophie d’origine japonaise dont certains principes pratiques ont été mis en application avec succès par le constructeur automobile Toyota. À la fin des années 80, un certain nombre de best-sellers ont fait connaître cette méthode à un public plus vaste. Les cinq caractéristiques de la gestion en flux tendu sont les suivantes :
1. Création de valeur : la création de valeur désigne toute activité pour laquelle le client se montre disposé à payer dès lors qu’elle semble nécessaire pour résoudre ses problèmes.
2. Gaspillage : les processus regroupent trois types d’activité, à savoir, les activités qui créent de la valeur ; les activités qui ne créent pas de valeur mais sont nécessaires dans le contexte et l’infrastructure actuels de l’entreprise ; enfin, les activités qui, en un mot, ne créent pas de valeur.
3. Flux : un flux désigne un processus permanent sans réserves de travail.
4. Pull : un processus en flux tiré (pull) comprend uniquement les activités répondant à un besoin spécifique.
5. Perfection : à l’inverse des bancs d’essai classiques, ce principe considère la perfection comme l’objectif ultime.
Depuis quelques années, la philosophie du flux tendu a connu d’autres développements. Elle n’est plus réservée aux processus internes de l’entreprise et trouve désormais son application dans toute la chaîne de valeur d’entreprises et de secteurs d’activité très divers. Surtout, ces principes se sont frayé un chemin hors de l’industrie et ils sont aujourd’hui appliqués à l’optimisation des processus administratifs.
Le flux tendu repose sur le principe fondamental selon lequel l’amélioration des microprocessus influe directement sur l’application de la stratégie d’une entreprise (voir figure 3).
L’un des facteurs de succès critiques du flux tendu dans un contexte administratif réside dans l’idée que les exécutants des processus sont les mieux placés pour en éliminer tout gaspillage.
Son succès, cette méthode le doit à l’accent mis sur la réduction du gaspillage par toutes les parties concernées, mais également au moyen d’outils permettant une application concrète d’un processus en flux tendu.
Enfin, Six Sigma désigne une pratique de management conçue à l’origine par Motorola en vue de réduire le nombre de défauts résultant de processus incomplets. Tout événement provoquant l’insatisfaction du client est considéré comme un défaut. L’appellation « six sigma » fait référence à la mesure statistique de la variance dans un échantillon donné et définit l’objectif fixé en termes quantitatifs. L’application générale de cette méthode fait également largement appel à des analyses statistiques.
Son succès, Six Sigma le doit à la logistique statistique concrète de cette méthode dans l’exécution des initiatives d’amélioration.
Les différentes méthodes ayant un certain nombre de points communs, le risque est grand d’en appliquer une seule pour résoudre tous les problèmes. La métaphore suivante résume bien cette situation dans les applications de bureau : « Bien qu’il soit possible d’utiliser un tableur pour rédiger une lettre et un logiciel de traitement de texte pour créer des feuilles de calcul, il est plus efficace et pertinent de créer les feuilles de calcul avec un tableur et de rédiger la lettre avec le traitement de texte. Une solution intégrée, qui extrait une feuille de calcul d’un tableur et une lettre d’un traitement de texte, représente la combinaison optimale. »
Il en va de même avec les méthodes d’amélioration. La méthode de travail idéale est la suivante :
Double approche
Pour aboutir, les initiatives d’amélioration reposant sur la méthode intégrée nécessitent une double approche : une approche logique :
Un premier aspect logique de la méthode de travail réside dans l’idée que l’approche du projet visant à introduire les principes du flux tendu doit elle-même être réduite à l’essentiel. Autrement dit, deux aspects concrets doivent être pris en considération. D’une part, le déroulement du projet doit exclure toute activité ou analyse dépourvue de valeur ajoutée pour le résultat recherché : une exécution plus performante de processus plus performants. D’autre part, tous les exécutants doivent avoir au moins la possibilité de participer activement et d’assumer des responsabilités dans le cadre du projet. La tentation est souvent grande pour la direction de sélectionner certains employés comme particulièrement compétents pour participer à un projet. Ainsi, ce sont toujours les mêmes qui sont impliqués dans les changements, l’innovation étant sacrifiée au profit du consensus.
Un deuxième aspect logique réside dans le fait de reconnaître au client la place qui lui est due. La méthode BPM repose sur une stratégie d’entreprise qui privilégie une certaine proposition de valeur au client. Dans la gestion en flux tendu, la création de valeur telle qu’elle est définie pour le client est l’aune à laquelle sont mesurées les activités d’un processus. Dans la méthode Six sigma, les défauts et tout ce qui risque de provoquer l’insatisfaction du client sont réduits au strict minimum. Toute initiative d’amélioration des processus qui ne commence pas par recenser les différents aspects de la valeur ajoutée et de la satisfaction client est vouée à l’échec. En outre, les enquêtes de satisfaction et les études de marché offrent dans bien des cas une multitude d’informations précieuses.
Un troisième aspect logique réside dans le regroupement des différents cas de gaspillage dans la résolution des défauts. De nombreuses initiatives d’amélioration, avec ou sans effets sur le système informatique, ne sont jamais mises en oeuvre en raison d’une portée trop limitée. Elles ne peuvent pas bénéficier de l’attention requise et, en conséquence, les moyens nécessaires ne sont pas mis à disposition. La méthode intégrée permet, par un effet boule de neige, de tirer parti de la multitude d’opportunités éparpillées dans les tiroirs d’une multitude d’employés et d’améliorer ainsi les performances de l’entreprise. Une portée minimum assure la notoriété requise et facilite éventuellement la gestion des procédures à suivre et des canaux.
Le dernier aspect logique est l’ouverture de l’approche du projet. Il est courant que les projets d’amélioration aient une portée fixe, rigide, et ce pendant toute leur durée. Cette situation est avant tout le résultat des accords avec les parties extérieures et des budgets externes. Dans le meilleur des cas, des procédures sont en place pour influer sur la portée du projet au moyen de demandes de modification. Du point de vue de l’entreprise, il est toutefois plus judicieux d’aborder la portée du projet de manière dynamique. Cette dynamique peut se manifester dans deux directions : le « spin out » ou le « spin in ».
Le « spin out » consiste à scinder une partie du reste d’un projet pour l’exécuter immédiatement. Malgré les avantages potentiels de certaines options d’amélioration identifiables pendant le projet de flux tendu, il serait difficile de les justifier auprès de l’entreprise pour exécuter tout le cycle BPM avant même d’avoir rentabilisé ces avantages. Ce mécanisme offre habituellement des « gains rapides » pour les groupes de travail ou les employés chargés des processus auxquels les droits associés ont été attribués.
Un « spin in » désigne un mouvement inverse. Pendant le déroulement d’un cycle BPM, l’entreprise et le contexte dans lequel elle évolue ne restent pas statiques. C’est ce qui fait des initiatives « bottom up », parfois inconsciemment, la méthode actuelle de travail. Une entreprise a besoin de la flexibilité et du sens de l’initiative de ses employés ; il serait donc néfaste d’étouffer ces initiatives dans l’oeuf. Pourtant, il ne faut pas perdre de vue le fait que les modifications ne rendent pas les objectifs du projet de flux tendu plus difficiles à réaliser, mais qu’elles peuvent même les renforcer. Un « spin in » a pour but d’assurer le suivi de l’étendue des initiatives spontanées et l’application de normes éventuelles, afin de garantir un résultat cohérent à la fin du cycle de BPM.
La grande difficulté, dans les initiatives d’amélioration, réside dans l’aspect psychologique. Bien que considéré comme essentiel par bon nombre d’entreprises et de sociétés de conseil, peu parviennent à briser les dogmes existants et à s’en affranchir.
Avant tout, l’entreprise en général et les employés en particulier, doivent être conscients de l’évolution du contexte de l’entreprise ainsi que des possibilités infinies qu’elle offre au quotidien. Pour ce faire, il peut être judicieux d’organiser un brainstorming où un grand nombre d’employés s’attachera à identifier les formes de gaspillage les plus diverses rencontrées dans l’entreprise.
Ensuite, tous les employés doivent disposer d’une tribune pour exprimer leurs idées et leurs critiques concernant les initiatives. Le principe fondamental est que lorsque deux personnes ont les mêmes idées et les mêmes pensées, l’une des deux est superflue. N’hésitez donc pas à encourager la contradiction ! De plus, une telle tribune tend généralement à favoriser l’apparition de nouvelles pratiques recommandées et de nouvelles initiatives d’amélioration.
Ensuite, il ne faut pas oublier l’intérêt des chiffres. Même si le coeur n’obéit pas toujours à la raison, il a plus de chances de le faire si les arguments donnés sont étayés par des chiffres.
Enfin, une communication permanente a des effets considérables. Si, dans l’idéal, les performances des processus en flux tendu doivent être visibles pour tous, il est tout aussi important de communiquer en interne sur le succès des cycles BPM et des opérations de spin in et de spin out. Il est important de savoir que les employés peuvent ainsi découvrir les avantages de ces initiatives et prendre conscience qu’elles apportent un ballon d’oxygène, qu’elles allègent les tâches, enfin, qu’elles peuvent donner à leur tour naissance à de nouvelles initiatives.
Grâce à cette double approche, vous évitez que votre projet en flux tendu soit un motif de frustration et que des intentions louables ne deviennent des opportunités manquées.
Auteurs : Kim Oostvogels et Jan Bellaert, consultants,
Famille : Organisation
Définition BPMS
Ensemble organisé d’activités utilisant des ressources (personnel, équipements, méthodes, finances…) pour transformer des éléments entrants en éléments sortants.
Définition ISO 9000 : Ensemble d’activités corrélées ou interactives qui transforment des éléments d’entrée en éléments de sortie.
Famille : Organisation
Définition BPMS
Ensemble formalisé d’étapes à appliquer pour réaliser une activité ou un processus. Les procédures sont multi-acteurs et se situent à un niveau de détail plus fin que les processus.
Définition ISO 9000 : Manière spécifiée d’effectuer une activité ou un processus.
Ces cinq dernières années, les problématiques et usages liés à la gestion des contenus et documents se sont stabilisés. Les différentes solutions de GED, CMS, de travail collaboratif ou moteur de recherche permettent aujourd’hui de déployer les outils et moyens nécessaires à l’entreprise afin de mieux gérer ses documents numériques et la masse d’information associée.
Cette maturité toute relative du monde de l’ECM s’inscrit elle aussi dans un contexte plus général d’urbanisation des services informatiques. Ainsi, se pose une nouvelle question : comment positionner les services GED par rapport aux autres services informatiques ?
Quelles solutions, quels protocoles et quelles attitudes adopter sur l’urbanisation afin de maîtriser le déploiement et l’évolutivité de ces solutions tout en optimisant leur amortissement ?
La GED comme service unifié au sein du SI
Les entreprises et organisations ont unifié leurs sites intranets, mis en place des solutions de gestion de contenus Web (CMS) ou ont déployé des outils de GED ou autres bases documentaires.
De leur coté, les éditeurs logiciels ont étendu l’adressage fonctionnel de leurs solutions afin d’être en capacité de répondre à la problématique générale de « référentiel de ressources numériques ». Ainsi la « fonction GED » se retrouve intégrée dans les solutions du marché sous différentes formes : module GED ou « Resources Library » complémentaire au CMS, Intranet ou encore ERP.
Les logiciels de GED ont également étendu leur spectre fonctionnel afin de permettre la mise en place de fonctions de publication Web (intranet et Internet), de collaboration ou autres fonctions métiers (configuration produit, gestion de documentation structurée, médiathèque…).
Dès que le Système d’Information d’une organisation est constitué de plusieurs services « de gestion de contenus« , il devient vite critique d’unifier « la fonction GED » afin de répondre au besoin de « référencement et d’unicité des ressources numériques » et rationaliser ainsi l’investissement « GED« .
Deux grandes orientations sont alors envisageables :
– Migrer les solutions existantes vers une unique solution couvrant les fonctionnalités attendues
– Mettre en place une architecture permettant d’urbaniser et d’intégrer ces différents services
Nous développons ici la seconde alternative. Nous considérons en effet le cas où le nombre et les caractéristiques des applications existantes rendent difficile une refonte totale du SI en ce qui concerne les applications de gestion de contenus. Une architecture modulaire « par service » restera plus évolutive (grands principes des orientations EAI).
Maîtriser le périmètre fonctionnel de la GED
Il faut préalablement définir les fonctionnalités de la GED à « unifier« . En effet, les éditeurs étendent en permanence la couverture fonctionnelle de leurs produits, il faut donc savoir arbitrer sur les fonctions à conserver pour chaque solution.
Ainsi faut-il plutôt conserver la fonction portail d’un outil de GED ou est-il préférable de coupler la GED au moteur de portails déjà déployé ? De même, faut-il utiliser le moteur d’indexation intégré à la solution intranet, utiliser celui de la GED ou déployer une solution tierce complémentaire remplaçant les deux premières ? Ou encore, faut-il préférer les fonctionnalités collaboratives de la GED par rapport au CMS ? Penser l’urbanisation des services de gestion de contenus et documents nécessite d’effectuer ces arbitrages.
Si de grands principes d’urbanisation peuvent être exprimés, ces choix restent néanmoins dépendants de l’historique du Système d’Information, de la génération des solutions utilisées pour chaque service, de leurs capacités à évoluer, des roadmaps éditeurs, des usages, du niveau de déploiement de l’annuaire d’entreprise et bien évidemment du budget.
Quelques principes pour une démarche d’urbanisation GED
Avant toute chose, il est nécessaire :
– De faire l’inventaire des services attendus par les utilisateurs, d’apprécier leurs spécificités mais surtout leurs criticités par rapport aux activités de l’organisation. L’arbitrage final sera toujours guidé par les objectifs fonctionnels à atteindre et le retour sur investissement associé. Il faut donc pondérer chaque service identifié par rapport à sa criticité et au ROI estimé
– De définir un périmètre fonctionnel concentrique pour chaque grand service. Dans ce cadre, il faut revenir aux fondamentaux :
o Quelles sont les principales fonctions attendues d’une GED et leurs interdépendances ?
o Il est a minima nécessaire d’assurer le référencement des ressources documentaires, leur classement, leur sécurisation
o Dans un second temps (de façon concentrique) viennent les fonctionnalités liées à la description (métadonnées), l’indexation, les états et statuts documentaires, la gestion des versions
o Puis les principes de gestion documentaire : réserver/libérer un document, valider
o Les fonctionnalités périphériques, les plus distantes du cœur fonctionnel pourraient éventuellement être reportées sur des services externes : workflows, publication web, collaboration…
– Une fois les périmètres fonctionnels établis, il s’agit de définir les flux de données/documents nécessaires :
o Quels sont les services exposés : créer un nouveau document, récupérer un document, mettre à jour, liste de documents pour lequel un utilisateur donné possède des droits de lecture, liste des documents à valider
o Quels sont les services requis pour l’interopérabilité : annuaire d’identités et de groupes communs entre les services, connecteur pour un moteur de recherche externe
Le niveau de couverture du service GED unifié dépend des fonctionnalités attendues par les autres services et des capacités de la (ou des) solution(s) identifiée(s).
Dans ce cadre, les fonctions GED retenues peuvent éventuellement être simplifiées (exemple : stockage, classement, sécurisation, métadonnées), les fonctions étendues seront portées par des services spécifiques a priori plus performants sur leur domaine. Par opposition, le niveau d’utilisation de la GED peut rester très avancé. Dans ce cadre, le niveau de compatibilité du produit identifié avec les besoins de l’entreprise en termes d’urbanisation devra être très important. L’outil de GED devient dans ce cas central dans l’architecture du SI.
Considérations techniques
Si l’urbanisation des services GED suit les grands principes d’intégration des applications d’entreprise, il y a néanmoins quelques spécificités techniques liées à la nature des informations échangées, nous en citons deux :
– Unifier les référentiels d’identités et de groupes
o Point essentiel de toute intégration d’applications mais nécessaire lorsque l’on aborde le domaine des contenus d’entreprise
o En effet, il s’agit de permettre une continuité entre les applications (accéder aux documents depuis l’intranet ou depuis le portail de recherche) afin de respecter les différents périmètres de confidentialité propres aux documents et informations produites par les collaborateurs
o Ainsi la diffusion d’un document sera restreinte à une certaine population tant qu’il appartiendra à une application métier spécifique et il pourra être diffusé plus largement lorsque publié sur l’intranet
o Les différents services doivent pouvoir accéder à un annuaire d’identités unique ainsi qu’aux définitions de groupes d’utilisateurs applicables
– Utiliser des standards EAI spécifiques à la GED: CMIS
o Les éditeurs de solutions de gestion de contenus s’accordent actuellement sur la définition d’un nouveau standard : CMIS (Content Management Interoperability Services)
o Ce standard doit permettre de faciliter l’interopérabilité entre les applications ayant à échanger des contenus ou documents ou effectuer des traitements sur ces informations
o Au moment de la rédaction de cet article, CMIS vient d’être approuvé par OASIS (Organization for the Advancement of Structured Information Standards) mais reste à un stade très générique de sa définition
o Les premières mises en œuvre au sein des plateformes ECM restent relativement basiques, certains services ne sont pas encore implémentés (ex : unification des mécanismes de propagation des droits)
o A ce stade, il s’agit donc d’en rester aux principes et protocoles génériques d’intégration d’applications. L’intégration future de CMIS dans le contexte d’une architecture modulaire sera facilitée
Conclusion
Le positionnement des fonctions GED comme service unifié au sein du Système d’Information de l’entreprise est une orientation forte, justifiée par la maturité des solutions ECM et le contexte général « d’intégration d’applications« . Comme nous l’avons abordé, il n’y a pas de solution unique et standardisée pour l’urbanisation des fonctions GED, il y a néanmoins des principes forts qui peuvent guider la démarche d’intégration pour assurer l’interopérabilité des systèmes.
Une étude préalable des existants techniques et de l’expression des besoins est nécessaire afin d’établir l’urbanisation d’un SI pour ses fonctions d’ECM. Enfin, l’aboutissement de standards comme CMIS devrait faciliter la démarche d’urbanisation.
Auteur : Thomas Dechilly – Directeur Technique et Exécutif chez Sollan, cabinet spécialiste de la GED
Les principes de management par la qualité introduits dans la norme ISO 9004:2000 définissent un cadre de référence (en anglais framework) permettant aux organisations d’améliorer leurs performances. Ces principes sont issus des meilleures pratiques et de l’expérience d’un grand nombre d’entreprises et d’institutions au niveau international.
La norme ISO 9004:2000 définit 8 principes fondateurs constituant des règles et conseils destinés aux organisations afin de les aider à améliorer de façon continue leur performance en se focalisant sur la satisfaction de leurs clients (bénéficiaires au sens large), tout en tenant compte des besoins des différentes parties prenantes.
Les 8 principes de management par la qualité sont les suivants :
1 – Organisme à l’écoute du client (Customer focus) :
Les organismes dépendent de leurs clients, il convient donc qu’ils comprennent leurs besoins présents et futurs, qu’ils répondent aux exigences des clients et qu’ils s’efforcent de dépasser leurs attentes.
L’objectif est de considérer le client non seulement comme un consommateur mais surtout comme un utilisateur des produits ou services réalisés par l’organisation et de s’assurer de l’adéquation avec les objectifs de l’entreprise. Il s’agit donc de mettre en oeuvre un mécanisme d’écoute client pour avoir une meilleure vision des besoins et des attentes du bénéficiaire, afin d’être toujours en mesure d’y répondre au mieux.
Par ailleurs, il est également conseillé de faire en sorte d’évaluer régulièrement le niveau de satisfaction du client afin d’être en mesure de détecter au plus tôt les opportunités ou les risques.
2 – Leadership :
Les dirigeants de l’organisation définissent de manière cohérente une finalité et les orientations de l’organisme. Il serait souhaitable qu’ils créent et maintiennent l’environnement interne nécessaire pour que le personnel se sente pleinement impliqué dans la réalisation des objectifs de l’organisme.
L’objectif de ce principe est de faire en sorte de prendre en compte les besoins de toutes les parties prenantes pour définir et formaliser une vision prospective claire de l’organisation en définissant des objectifs motivants. Il s’agit de créer des valeurs partagées par tous afin de remplacer les craintes éventuelles par une relation de confiance.
3 – Implication du personnel (Involvement of people) :
Le personnel à tous les niveaux constitue l’essence même d’une organisation et leur implication permet de mettre leurs compétences au service de l’organisation.
Il s’agit de faire comprendre à tout le personnel de l’organissation son rôle et son importance dans celle-ci et de fixer avec lui des objectifs motivants tout en le responsabilisant. Il est notamment important de faire régulièrement un bilan de compétence et de proposer un plan de formation afin de faire évoluer chacun dans son métier.
A l’inverse, il peut être utile de proposer aux employés de faire un retour à leur supérieur sur leur manière de manager et sur leur relation de travail. Dans un tel contexte, chaque personnel sera ainsi plus enclin à améliorer ses compétences sur la base de buts personnels à atteindre et donc à échanger avec les autres son expérience et ses connaissances.
4 – Approche processus (Process approach) :
Un résultat escompté est atteint plus efficacement lorsque les actions et les ressources correspondantes sont gérées comme des processus.
Il s’agit donc d’identifier clairement, en tant que processus, les activités nécessaires permettant d’aboutir à un résultat et de nommer un responsable pour chacune d’entres-elles. L’identification des activités peut être avantageusement réalisée avec les acteurs concernés.
Sur cette base, il sera possible de mesurer la performance de chaque processus et d’analyser de quelle manière il peut être amélioré afin de mieux répondre aux objectifs stratégiques de l’entreprise.
5 – Management par approche système (System approach to Management) :
Identifier, comprendre et gérer un système de processus interdépendants pour un objectif donné permet d’améliorer l’efficacité et l’efficience de l’organisation.
L’idée de ce principe est de considérer que le fait de structurer et de documenter clairement les actions concourant aux objectifs de l’organisation permet d’améliorer l’efficacité et l’efficience. Pour ce faire, il est nécessaire d’identifier dans un premier temps les dépendances existantes afin de réduire les conflits inter-processus et la duplication des activités.
Ceci devant conduire à la formalisation d’un système de management par la qualité clairement documenté. Une formation ou une information des acteurs pourra être nécessaire afin de s’assurer que chacun s’approprie la démarche.
6 – Amélioration continue (Continual improvement) :
L’amélioration continue devrait être un objectif permanent de l’organisation.
Il s’agit donc de mettre sous contrôle les différents processus, puis, de façon cyclique, d’analyser leurs performances, de faire des propositions d’amélioration et de les mettre en œuvre. Cela peut notamment se faire par le biais d’une revue régulière avec les responsables et avec des audits interne ou externes.
Il est particulièrement important de savoir repérer les améliorations et de les faire connaître à tous.
7 – Approche factuelle pour la prise de décision (Factual approach to decision making) :
Les décisions efficaces sont basées sur l’analyse de données et d’informations tangibles.
Ce principe consiste ainsi à prendre des décisions sur la base d’une analyse factuelle de l’information, corroborée par l’expérience et l’intuition. Selon cette approche, il sera plus facile a posteriori d’argumenter sur le bien fondé d’une décision en faisant référence à des documents rendus accessibles.
Cela permet notamment de donner les moyens à l’ensemble des parties impliquées de comprendre la manière dont les décisions sont prises.
8 – Relations mutuellement bénéfiques avec les fournisseurs (Mutually beneficial suppliers relationships) :
Les organisations et leurs fournisseurs sont interdépendants aussi une relation mutuellement bénéfique améliore leur capacité à créer de la valeur.
Les relations avec les fournisseurs doivent ainsi être pensées de manière à concilier des victoires faciles à court terme avec des considérations plus prospectives. Pour cela, il est nécessaire de comprendre les intérêts des partenaires, de définir clairement dans un contrat leurs obligations et d’évaluer régulièrement leurs performances.
Un tel principe permet lorsqu’il est correctement appliqué d’améliorer les relations avec les fournisseurs, notamment le temps de réponse et donc le coût global.
Auteur : Jean-François PILLOU
Ce document intitulé « Qualité – Management par la qualité » issu de Comment Ça Marche (www.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.
De bon matin, motivé et déterminé, doté d’une licence MEGA Process, je m’en vais ouvrir la suite MEGA, afin de modéliser l’un des processus dont j’ai la charge. Mon profil ? Ce matin, je suis cartographe, utilisateur MEGA Process. Le reste du temps, je suis Responsable du Back-Office Gestion de contrats. En effet, la solution MEGA Process est dédiée aux opérationnels sur le terrain, mais également aux architectes d’Entreprise. Plus généralement, à tout collaborateur responsable ou impliqué dans la gestion des processus de l’entreprise. Et ils sont nombreux !
Une fois connecté à la base (au sens MEGA) adéquate, j’accède à mon espace de travail, me proposant, dans une page d’accueil, différents points d’entrée dans la modélisation existante. A l’avenir, lorsque j’aurai réussi à intégrer mon processus dans la hiérarchie des processus existants, je pourrai utiliser ces points d’entrée. Pour le moment, je vais plutôt créer mon processus dans un dossier temporaire de processus. Ou créer un Projet (au sens objet MEGA) qui m’est propre, auquel je pourrai rattacher mon nouveau processus. Au choix.
Mon processus créé, il s’agit maintenant de le modéliser (créer les objets dans la base), puis de le cartographier (placer les objets sur les diagrammes). Encore une fois, j’ai le choix : créer d’abord les objets dans l’arborescence, l’Explorateur d’objets ou les pages de propriétés des objets puis les poser sur un diagramme, ou créer directement les objets dans le diagramme. Je me dirige vers la première option : ainsi, je maîtriserai mieux les liens existants entre les objets et je peux compléter facilement l’ensemble des propriétés des objets créés (pas uniquement leur nom). Puis, habitué à manipuler l’outil, je créerai directement mes objets et liens entre objets sur les diagrammes (sans oublier de compléter les propriétés des objets qui ne s’affichent pas sur les diagrammes).
Que cartographier sur mes diagrammes ? Je ne serai pas exhaustif, mais je vais vous en donner une idée. Niveau macro : uniquement mon nouveau processus « Effectuer un rachat partiel », les clients de mon processus et ses bornes (événement(s) déclencheur(s) et résultat(s), représentés à l’aide des objets Message dans MEGA). Niveau détaillé : mon enchaînement d’activités et mes flux entre activités, mes règles de gestion, mes acteurs, les applications informatiques utilisées. Pas de connecteurs (un peu comme ceux que j’aurais eu avec la licence MEGA Process BPMN), mais des objets qui me permettent de contourner le problème (condition, synchronisation…). Si je souhaite ajouter ou modifier les types d’objets MEGA (ou Métamodèle) que j’utilise lors de ma modélisation, je dois m’adresser à mon administrateur MEGA, qui possède la licence adéquate.
Remarque importante : mes acteurs sont issus de l’organigramme qui a déjà été modélisé par mon collègue, ce grâce à la licence MEGA Process. En effet, je ne crée pas de nouveaux acteurs, je réutilise les acteurs existants ! Pour cela, je les recherche via mon arborescence d’acteurs ou via le moteur de recherche, puis je fais un glisser-déposer pour les placer sur mon diagramme. Et je peux faire de même pour tous les objets disponibles dans les fenêtres jouxtant l’écran où s’affiche mon diagramme.
D’autre part, les formes standards d’objets proposées par MEGA me plaisent bien, elles sont à la fois simples, lisibles et sympathiques. Critère important pour motiver mes collègues qui consulteront ces processus par la suite. Je peux choisir ces formes parmi un panel de formes disponibles, mais je peux également en créer de nouvelles, à l’aide d’un éditeur de formes. Cependant, il m’a été déconseillé de l’utiliser massivement, ces formes spécifiques étant des impacts à traiter lors des montées de versions MEGA.
Une fois ma modélisation terminée, je peux générer deux types de livrables facilement : un document texte (WORD généralement) ou un site web (intranet). Il existe des « squelettes » de restitution en standard dans MEGA, mais ils sont calqués sur la méthodologie propriétaire MEGA embarquée dans l’outil. Mon collègue administrateur en a développé de nouveaux à l’aide d’une licence spécifique, ce sont ceux-ci que je dois utiliser. Une fois mon document texte généré, je peux le détacher de MEGA et le transférer à mes collègues, de la même manière que n’importe quel document WORD.
Enfin, je quitte l’application, en n’oubliant pas de sauvegarder mon travail. Spécificité MEGA : malgré tout le