Vous êtes à la recherche des meilleurs pratiques dans le domaine de la gouvernance SI, complétez donc votre boite à outils avec CobiT
Le pragmatisme de CobiT vient de la fourniture de tableaux de correspondance permettant d'identifier l'ensemble des objectifs informatiques dérivant de chaque objectif métier, puis les processus CobiT liés aux objectifs informatiques.
CobiT (Control Objectives for Information and related Technology) est un référentiel c'est à dire une boite à outils contenant les meilleures pratiques, orienté dans le domaine de la gouvernance.
Comme toujours on peut appliquer une approche top-down traduisant avec efficience les objectifs stratégiques d'entreprise en un ensemble d'objectifs informatiques cohérents, eux même alimentés par un ensemble de processus CobiT.
Le pragmatisme de CobiT vient de la fourniture de tableaux de correspondance permettant d'identifier l'ensemble des objectifs informatiques dérivant de chaque objectif métier, puis les processus CobiT liés aux objectifs informatiques.
CobiT fournit la démarche concernant les technologies, les applications, les compétences, l'architecture technique, l'efficience et la conformité des exigences métiers, la gouvernance et enfin l'analyse de la maturité des processus.
L'approche bottom-up quand à elle, permet un audit d'objectifs CobiT, d'identifier les forces et les faiblesses informatiques et les impacts éventuels sur les métiers. La DSI a donc à sa disposition, un excellent outil d'analyse de risques.
Lors d'une mission pour un service public, la DSI avait demandé une étude sur l'efficience de la gouvernance de son SI suite à une fusion. Les processus CobiT furent passés en revue pour déterminer ceux qui étaient prioritaires. Dans le domaine "Planifier et Organiser (PO)", les processus "Définir un plan stratégique informatique (PO1)", "Définir l'architecture de l'information (PO2)", "Gestion des risques (PO9)", et dans le domaine "Distribuer et soutenir (DS)", le processus "Gérer les services de Tiers (DS2)" fut identifié.
L'étape suivante a consisté à analyser leur degré de maturité grâce à la vérification de leur mise place, leur formalisation, leur diffusion, l'outillage, les métriques et s'il existait une démarche d'amélioration continue. Une notation (0 à 5) est attribuée en fonction du modèle CobiT. Pour chaque processus, la maturité mesurée du client est mise en perspective par rapport à l’état de l’art d’une part (la moyenne constatée dans un échantillon représentatif d’entreprises) et par rapport aux entreprises les plus en avance dans le domaine (best of breed) d’autre part.
Concernant le processus "Définir un plan stratégique informatique (PO1)", les points positifs étaient qu'un schéma directeur était réalisé selon une méthode formelle avec une organisation dédiée et que le processus était formalisé, planifié, partagé par les parties prenantes et notamment les métiers qui avaient validé le fait que leurs exigences étaient bien prises en compte. Le point négatif fut que le schéma directeur devait être révisé un an après sa réalisation, ce qui ne fut pas le cas.
Pour le processus "Gérer les services de Tiers (DS2)", aucun processus formalisé fut identifié, ce qui expliqua en partie les surcoûts exorbitants de certains développements qui dépassaient de plus de 3 fois les pratiques usuelles du marché !
A chaque phase, une remise en question des objectifs définis et du niveau de maturité de chacun des processus est donc effectuée afin que le SI soit le mieux aligné avec la stratégie de l'organisation. Attention, ce n'est pas magique, vous ne trouverez pas de remèdes miracles, c'est à dire que CobiT ne précise pas le "comment" (comme le font du reste les normes !), et il faudra alors se tourner vers d'autres référentiels comme CMMi, ITIL ou eSCM et c'est du reste une tendance des plus en vogue qui est d'utiliser le meilleur de chaque référentiel, nous y reviendrons dans un prochains épisode.
Rhona Maxwel
@rhona_maxwel
"Les amoureux campent rarement sur leurs positions : ils passent vite de l’inclination du cœur à l’inclinaison des corps..."
Daniel Confland
Articles conseillés :
Donnez moi des bonnes raisons d'urbaniser mon SI ?
Comment mettre en place un jeux de rôles pour modéliser un processus métier ?
Rien de mieux qu'un jeux de rôles pour simuler un processus métier.
Les futurs utilisateurs du processus métier sont rassemblés.
Les outils sont les outils de tous les ateliers classiques que l'ont fait avec les experts métiers : un paper board, des feutres de couleurs, des post-it, …
Le but est que les participants réalisent le processus de manière efficiente.
Les ateliers peuvent être planifiés sur 3 séances de 3 heures.
Vous commencez par identifier les activités externes, les flux d'échanges de documents, les moyens de communications, … et à amorcer un travail de réflexion qui sera repris lors de la deuxième séance.
L’objectif des 2 séances suivantes est de s’éloigner du processus et de mettre en évidence les objectifs/buts de chaque acteur afin d'explorer des pistes d’amélioration.
La première séance a pour but de simuler le processus métier.
L'atelier se déroule simplement avec l'aide de post-it autocollants qui représentent des activités et de feutres de couleurs qui différencient les rôles.
Les participants sont mis en situation. Les participants jouent chacun à leur tour en fonction du moment où ils ont à intervenir.
Le début de l'atelier, vous situez le contexte général, 15 mn de tour de table et affectation des rôles des participants.
Durant cette étape, vous vous apercevrez que parfois, certains rôles n’ont pas été identifiés.
Soit une personne présente peut jouer ce rôle, soit une nouvelle séance sera nécessaire.
Un animateur représente les acteurs externes (il reçoit et transmet des informations).
Les acteurs de mettent d'accord sur un scénario, et chacun discutera et évaluera le résultat.
Chaque participant joue son propre rôle. Il note toutes les actions qu'il doit effectuer sur un post-it jaune autocollant avec un feutre de couleur qui l'identifie. Il pose ensuite le post-it sur la feuille blanche du paper board et fait une ou plusieurs flèches en indiquant à qui il passe la suite.
Les actions sont constituées d’un verbe conjugué à la première personne du singulier (par exemple je demande), d’un moyen(par exemple par mail) et si besoin d’un document (par exemple un devis). Les verbes et les moyens sont mis à la disposition des acteurs sous la forme de fiches pré-remplies.
Durant le jeu, il est possible d’enrichir ce vocabulaire commun, tous les participants rajoutent alors le verbe sur leur fiche.
Les documents sont notés sur un paper board au fur et à mesure de leur apparition.
Certaines actions correspondent à des créations de documents. Dans ce cas, le participant remplit une petite fiche descriptive (nom du document, contraintes d'utilisation du document, type (électronique ou papier), ...), colle une pastille de couleur sur la fiche du document (une couleur unique par document) et la pose sous le post-it.
Si un participant a besoin d’un document préalablement créé, il colle sur son post-it une pastille dont la couleur est celle du document. S’il est nécessaire de faire appel à un acteur externe, l’animateur pose un post-it de couleur rose (donc différent des post-it jaunes des participants), aucune action n’est notée sur ces post-it, seuls les documents peuvent circuler ou apparaître sous un post-it rose.
Tout participant peut durant le déroulement du jeu « poser un joker » pour indiquer qu’il fait un choix et donc que des variantes seraient possible.
Pour chaque post-it, les variantes sont scrupuleusement notées par un des animateurs. Un participant qui n’a plus à jouer (il considère que son rôle est terminé) l’indique en posant un panneau STOP sur son dernier post-it.
Le résultat obtenu est très proche d’un processus BPMN « basique». La feuille du paper board correspond à l’espace de travail, les post-it jaunes aux activités, les traits de couleur entre post-it à des objets de flux, on retrouve facilement les couloirs grâce aux feutres de couleur différente et aux acteurs externes,...
Il reste évidemment, pour une modélisation complète, des éléments à rajouter (évènements déclencheurs, intermédiaires, de fin), des actions itératives, ...
Pour conclure la séance, vous posez les questions :
-
Où se situent les principales difficultés du processus?
-
Pourquoi?
-
Donner deux idées d’actions pour améliorer le processus.
Rhona Maxwel
@rhona_helena
"Alors pourquoi aspirons-nous constamment à l'amour ? Parce que l'amour est le point de rencontre entre la vérité et la magie. Vérité comme en photographie ; magie, comme en aéronautique."
Julian Barnes
Articles conseillés :
Comment identifier, simuler, améliorer et modéliser les processus métiers ?
BPMN : l'antisèche pour rester incollable en modélisation de processus
BPMN l’exemple type pour tout comprendre sans prendre d’aspirine
Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
Un use case UML ( cas d'utilisation ) est une activité métier comme par exemple un acte de gestion exécuté par un acteur externe à l'application.
Un acteur au sens UML du terme, est un rôle qui correspond à son activité métier au moment ou il utilise le système.
Par exemple, un directeur commercial peut avoir plusieurs rôles au sein de l'application. Si celle-ci propose une fonctionnalité d'aide à la rédaction de propositions commerciales, lorsqu'il veut en rédiger une ( activité identifiée normalement dans la modélisation des processus métier ), il endosse le rôle de "rédacteur de proposition commerciale".
Pour la gestion des prospects son rôle est alors "ingénieur commercial" et lorsqu'il souhaite gérer les tableaux de bord de ses commerciaux, "directeur commercial".
Le rôle « directeur commercial » hérite de tous les rôles précédents.
Ces rôles sont des profils fonctionnels par rapport à l'exercice d'une activité composée d'une suite d'actions.
Les acteurs sont identifiées à partir des fonctions existantes dans l'entreprise et à partir des processus métiers de la vue modélisation métier de l'urbanisation du Système d'Information.
Un use case comporte un ou plusieurs scénarios composés de une ou plusieurs étapes.
Les scénarios peuvent être des cas nominaux où tout se passe bien, des cas alternatifs ou des cas exceptionnels conduisant à une exception métier.
La bonne pratique est de toujours commencer par analyser les scénarios nominaux puis les décrire jusqu'à obtenir une version stable.
Il est alors plus aisé d'identifier les scénarios alternatifs et exceptionnels à partir de la séquence normale des étapes des scénarios principaux.
Un scénario nominal conduit au résultat attendu, un scénario alternatif va mener à une fin normale mais en empruntant un autre chemin c'est à dire une autre suite d'étapes pour des conditions particulières, quand au scénario exceptionnel, il conduit toujours à une fin anormale correspondant à la génération d'une exception métier comme par exemple une donnée de paramétrage inexistante.
D'après l'ouvrage culte d'Alistair Cockburn "Writing effective use case", on peut définir 3 niveaux de use case qui sont pour reprendre son allégorie : le niveau nuage, le niveau de la mer et le fond de la mer.
Le niveau nuage correspond à des use case à fortes granularités, stratégiques comme par exemple "Gérer un prêt bancaire". Ces use case sont trop "gros", ils doivent être décomposés en use case du niveau de la mer.
Le niveau de la mer correspond bien à un use case utilisateur pour l'application cible, l'exemple précédent se décomposerait en 3 use case : "Gérer une demande de prêt bancaire", "Analyser une demande de prêt bancaire" et "Valider une demande de prêt bancaire".
Et le niveau fond de la mer, correspond à une fonction élémentaire simple non décomposable comme par exemple "Imprimer la demande de prêt bancaire". Ces use case correspondent à une simple étape d'un scénario.
Pour synthétiser, tout se résume à déterminer la bonne granularité d'un use case.
Alors comment faire pour trouver les bons use case, ni trop gros, ni trop fin ?
Les retours d'expérience ont permis d'élaborer la méthode dite des "10 ; 10".
Un use case doit avoir en moyenne 10 scénarios composés chacun d'environ 10 étapes. De plus il doit être déclenché par un unique acteur ( rôle ), exécuté dans une limite de temps, être transactionnelle, avoir un début et une fin et pour terminer on doit avoir unicité de lieu.
Donc si ron eprend l'exemple du use case niveau nuage "Gérer un prêt bancaire", on voit qu'il faut d'abord faire une demande de prêt déclenchée par un chargé de clientèle, puis cette demande est analysée par un analyste financier et ensuite validée par le directeur d'agence.
Il y a donc 3 acteurs différents, intervenant à des moments différents dans des lieux éventuellement différents. Par conséquent, le use case doit être décomposé pour satisfaire la méthode des "10 ; 10".
Examinons cette décomposition.
La gestion de la demande exige environ une dizaine de scénarios ( utilisation, type de prêt, ... ) et pour chaque scénario on aurait approximativement une dizaine d'étapes ( situation de famille, recensement des revenus, existence d'autres prêts, même établissement, propositions de différentes solutions de remboursement, ... ).
Le use case "Gérer une demande de prêt bancaire" est déclenché par un seul acteur le chargé de clientèle, il débute quand celui décide de créer/modifier une nouvelle demande et se termine quand celle-ci est créée ou modifiée.
Le use case "Analyser un prêt bancaire" est déclenché par l'analyste, commence lorsqu'il décide d'analyser une demande en attente et se termine lorsqu'il a émis une recommandation. On peut identifier une dizaine de scénarios constitués d'une dizaine d'étapes.
Le même raisonnement s'applique pour "Valider un prêt bancaire" déclenché par le directeur d'agence.
Si un même use case doit être factorisé et exécuté systématiquement dans plusieurs autres, on utilise la relation de dépendance <<include>>, du use case inclus vers celui qui le contient. Typiquement c'est le cas de l'authentification qui doit être obligatoirement effectuée au début de chaque use case.
Un use case peut être le prolongement d'un autre, on dit qu'il étend un use case ( relation <<extend>> attention au sens de la flèche qui va de celui qui étend vers celui qui est prolongé ).
Par exemple, pour analyser une demande de prêt, il faut les rechercher et les consulter donc le use case "Analyser une demande de prêt" étend le use case "Rechercher et consulter une demande", sachant que l'on peut juste vouloir consulter sans faire d'analyse. L'appel au use case qui étend est donc facultatif.
On vérifie que toutes les exigences sont implémentées dans au moins un use case.
Si ce n'est pas le cas c'est qu'on n'a pas encore terminé le travail de recensement des use case ou bien que les exigences restantes sont en dehors du périmètre de l'application.
Cette traçabilité est assurée par des relations d'implémentation UML allant de l'exigence modélisée comme une classe vers le use case.
Chaque scénario doit être décrit de manière textuelle en adoptant un formalisme qui constitue le modèle de fiche de use case.
Les AGL offrent des modèles prêts à l'emploi.
L'avantage est que cette description textuelle est stockée directement dans le référentiel de l'AGL. La traçabilité est ainsi assurée, on peut générer automatiquement la documentation et faire des estimations avec les modules de points de use case.
La méthode empirique d'identification des use case dite des "10 ; 10" a toujours donné de bons résultats et surtout permet d'avoir un cadre pour se prémunir des pièges lorsqu'on débute dans la modélisation des exigences et obtient donc une note de 10/10.
Rhona Maxwel
@rhona_maxwel
"Dans le sommeil, ce voyage aventureux de tous les soirs, il y a quelque chose de positivement miraculeux c'est un miracle dont la ponctualité a émoussé le mystère."
Charles Baudelaire
Articles conseillés :
SysML : le diagramme de cas d'utilisation (use case diagram)
SysML : les use case "top level" et opérationnels (tutorial SysML partie 4)
Partir du bon pied dans un projet informatique : la modélisation métier
Les meilleurs outils de modélisation UML, SysML, BPMN, DMN de l'année 2016 et les gagnants sont ...
C'est la période vous n'y couperez pas, tout le monde y va de son classement du meilleur de l’année qu’il s'agisse de l'homme (ou de la femme) de l'année, du livre, du film, de la chanson, du personnage politique, …
Urbanisation-si n'échappera pas à la règle et nous vous proposons donc nos « best of the year » à notre manière bien sur.
En compétition pour le prix du meilleur outil de modélisation généraliste, UML, SysML, BPMN, MDA, ... de l’année 2016, les nommés sont :
- Modelio (gratuit) ( https://www.modelio.org/ )
- Papyrus (gratuit) ( https://eclipse.org/papyrus/ )
- Sirius (gratuit) ( permet de créer son propre formalisme de modélisation ) ( http://www.eclipse.org/sirius/ )
- Enterprise Architect ( http://www.sparxsystems.com/ )
- IBM Rational Rhapsody family (gratuit) ( http://www-03.ibm.com/software/products/en/ratirhapfami )
- IBM Rational Modeler (gratuit) ( http://www.ibm.com/developerworks/downloads/r/modeler/ )
- Open ModelSphere (gratuit) ( http://www.modelsphere.com/org/fr/open_modelsphere.html )
- MEGA ( http://www.mega.com/fr/produit/hopex-uml )
- Magic Draw ( https://www.nomagic.com/products/magicdraw.html )
Il s'agit de l'AGL commercial le plus complet, présentant le meilleur rapport qualité + fonctionnalités / prix. Différentes versions, correspondent à différents profils utilisateurs, cela va de l'expert métier au développeur en passant par l'architecte fonctionnel ou technique. Tous les langages sont présents : UML, SysML, BPMN, ... A mon avis c'est très certainement l'outil le plus convivial et le plus robuste et puissant du marché.
Voir l'article : AGL (Atelier de Génie Logiciel) : les ministères recommandent Enterprise Architect de Sparx System
En compétition pour le prix du meilleur outil de modélisation dans la catégorie processus métier BPMN (Business Process Modeling Notation) de l’année 2016, les nommés sont :
- Modelio gratuit) ( https://www.modelio.org/ )
- Sirius (gratuit) ( permet de créer son propre formalisme de modélisation ) ( http://www.eclipse.org/sirius/ )
- Enterprise Architect ( http://www.sparxsystems.com/ )
- TBM Blueworkslive ( https://www.blueworkslive.com/home )
- IBM Business Process Manager ( http://www-03.ibm.com/software/products/fr/business-process-manager-family )
- MEGA - HOPEX Business Process Analysis ( http://www.mega.com/fr/produit/hopex-business-process-analysis )
- Bizagi ( https://www.bizagi.com/ )
- Eclipse BPMN2 Modeler (gratuit) ( http://www.eclipse.org/bpmn2-modeler/ )
- Bonitasoft (gratuit) ( http://fr.bonitasoft.com/ )
- jBPM (gratuit) ( https://www.jbpm.org/ )
- Activiti (gratuit) ( http://activiti.org/ )
- Camunda (gratuit) ( https://camunda.org/ )
Grâce à ces trois composants majeurs : Bonita Studio permettant à l'utilisateur de modifier graphiquement les processus métier suivant la norme BPMN. L'utilisateur peut également connecter les processus à d'autres éléments du système d'information (telles que la messagerie, la planification des ressources d'entreprise, la gestion de contenu d'entreprise et bases de données) afin de générer une application commerciale autonome accessible comme un formulaire Web. Bonita Studio permet également à l'utilisateur de concevoir graphiquement les formulaires qui seront présentées à l'utilisateur final afin d'interagir avec le processus. Il s'agit d'un plugin Eclipse ; Bonita BPM Engine qui est une application Java qui exécute les processus métier créés avec Bonita Studio et enfin Bonita Portal permettant à chaque utilisateur final de gérer toutes les tâches dans lesquelles il est impliqué. Le portail permet également le propriétaire d'un processus d'administrer et d'obtenir des rapports sur les processus.
En compétition pour le prix du meilleur outil de modélisation dans la catégorie règles métiers DMN (Decision Modeling Notation) de l’année 2016, les nommés sont :
- FICO DMN Modeler ( http://www.ficoanalyticcloud.com/decision-management-suite/dmn-modeler/ )
- Decision First Modeler ( http://decisionsfirst.com/ )
- OpenRules (gratuit) ( http://openrules.com/ )
- Signavio Decision Manager ( http://www.signavio.com/fr/products/decision-manager/ )
- Camunda (gratuit) ( https://camunda.org/ )
Permet à tous les acteurs, des experts métiers aux développeurs de créer, tester, exécuter et maintenir des règles métiers (tables de décisions, …). Supporte le norme de l'OMG DMN (le langage FEEL, les tables de décisions, …) et un gros effort a été apporté à la documentation et aux exemples.
En compétition pour le prix du meilleur outil de transformation de modèles de l’année 2016, les nommés sont :
- Enterprise Architect ( http://www.sparxsystems.com/ )
- Eclipse QVTo (Query View Transform Operational) (gratuit) ( http://www.eclipse.org/mmt/?project=qvto )
- Eclipse QVTd (Query View Transform Declarative) (gratuit, en cours de finalisation)) ( https://projects.eclipse.org/projects/modeling.mmt.qvtd )
- Eclipse ATL (Atlas Transformation Language) (gratuit) ( https://www.eclipse.org/atl/ )
Le plus ancien et le plus stable des outils de transformation de modèles.
Voir l'article : Ingénierie Dirigée par les Modèles (IDM) : tutoriel ATL (ATLAS Transformation Language), le "Da Vinci code" de la transformation AT
Rhona Maxwel
@rhona_maxwel
« C'est là, dans le va-et-vient des jours et le fouillis des non-dits, que la vie perd le sens des choses profondes et se réfugie dans le superficiel et le faux-semblant. »
Boualem Sansal
Articles conseillés :
SysML pour les nuls : de la modélisation des exigences à la réalisation du système
Comment identifier, simuler, améliorer et modéliser les processus métiers ?
Vous vous demandez quel est le bon processus ou méthode pour gérer et modéliser vos processus métiers ?
Eh oui on le vit tout les jours, le monde évolue alors ne subissez pas les changements, soyez réactif dans vos processus métiers.
Vous devez être agile et capable de les identifier, les simuler, les améliorer et les modéliser, dans un délai s'approchant du temps réel, sur les besoins des usagers de la concurrence, du marché, des nouveaux aspects juridiques, politiques, des réorganisations internes, des évolutions technologiques et des contraintes environnementales.
Pour atteindre ces objectifs, vous devez réaliser 4 grandes étapes :
Etape 1 - Identifier le processus : rechercher les informations pour la modélisation du processus, les acteurs participants
Etape 2 – Simuler le processus : faire participer sous forme de jeux de rôle les futurs utilisateurs de manière à avoir la représentation quasi définitive et prête à être modéliser en BPMN du processus.
Etape 3 – Evaluer le processus : analyser le processus pour rechercher les problèmes rencontrés par les acteurs réalisant le processus et trouver des solutions.
Etape 4 – Améliorer le processus : rejouer le processus en intégrant les nouvelles activités ajoutées lors de l'étape 3 et estimer le gain d'efficience du processus.
Etape 5 – Modéliser le processus obtenu avec BPMN : les dessins réalisés manuellement lors des étapes précédentes doivent être très proches d'une modélisation BPMN, il ne reste plus qu'à transcrire avec le formalisme BPMN et le tour est joué.
Rhona Maxwel
@rhona_maxwel
« Il existe une pauvreté bien plus grande: ne pas se sentir aimé, désiré, être marginalisé. »
Mère Teresa
Articles conseillés :
BPMN : norme OMG - synthèse des éléments graphiques
BPMN : l'antisèche pour rester incollable en modélisation de processus
BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza.
Sur quels critères doivent reposer les indicateurs d'urbanisation d'un système d'information ?
La manière dont chaque composante du processus d'urbanisation est mise en œuvre est caractérisée par plusieurs axes et critères.
Rhona Maxwel
@rhona_maxwel
"Le bonheur n'accepte comme conjointe que la réalité."
Daniel Desbiens
Articles conseillés :
La démarche de l'urbanisation des systèmes d'informations : comment mesurer les progrès ?
Objectifs des indicateurs du processus d'urbanisation du Système d'Information
La méthode top-down dans l'urbanisme du Sytème d'Information
La méthode top-down dans l'urbanisme du Sytème d'Information
La méthode top-down part de la stratégie d'entreprise, pour en déduire les objectifs métiers, les processus métiers, le système d'information et enfin le système informatique.
En haut, juste en dessous de la stratégie d'entreprise qui ne fait pas partie de l'urbanisation du SI, on trouve la cartographie métier avec les processus métiers et leurs événements déclencheurs, puis en dessous, la cartographie fonctionnelle structurant le système d'information avec des blocs fonctionnels, un niveau encore en dessous, on trouve la cartographie applicative constituée de composants applicatifs du système informatique et enfin tout en bas la cartographie technique représentant l'infrastructure technique du système informatique.
La méthode top-down part de la stratégie d'entreprise, pour en déduire les objectifs métiers, les processus métiers, le système d'information et enfin le système informatique.
Le postulat étant que la couche supérieure à celle qui est modifiée, est invariante, sinon on s'expose à un risque de divergence.
Toute intervention dans l'urbanisation du SI est opérée sur la couche n immédiatement en dessous de celle n+1 qui doit rester invariante. La couche n-1 doit subir toutes les modifications pour remplir les besoins de la couche n et ainsi de suite. Il est possible qu'une couche remplisse déjà les besoins de la couche supérieure, auquel cas elle ne subira aucune modification.
Prenons l'exemple de la direction générale d'une mutuelle qui adopte une stratégie de lutte renforcée contre la fraude. Le schéma directeur défini sur 3 ans, bien qu'il puisse être révisé tous les ans, est considéré comme invariant. La première couche non invariante est la couche métier. En effet, le processus métier de remboursement d'actes de santé est modifié.
En fonction de certaines règles, comme plus de 3 consultations chez un généraliste dans la même journée, un rejet sera généré pour un traitement manuel. On voit que non seulement le processus métier est modifié mais aussi l'organisation avec un changement important pour le travail du gestionnaire. Il faudra modifié la couche fonctionnelle avec des classes et des services métiers spécifiques.
La couche applicatives devra implémenter ces classes et ces services et assurer la communication avec les autres blocs applicatifs comme le paiement, le juridique, ...
La couche technique ne sera peut être pas impactée, car elle possède déjà un ESB (Enterprise Serial Bus) permettant la communication entre les blocs.
La méthode bottom-up, consiste à intervenir sur une couche pour en améliorer le fonctionnement.
Cette opération peut faire émerger des opportunités de modification à la couche supérieure. Elle part du principe que dans tout système défini, il peut y avoir des évènements qui remettent en cause les principes établis.
Généralement ces évènements sont extérieurs à l’entreprise, d’ordre technologique mais aussi économique (fusions ou acquisitions) ou réglementaire (obligation de mise en place d’une norme européenne).
Et comme bien souvent ce n'est pas l'une ou l'autre qui est privilégiée mais bien un mixte des 2 méthodes.
Rhona Maxwel
@rhona_helena
"Le paradoxe du travail, c'est que l'on ne travaille, en fin de compte, que pour le supprimer."
Boris Vian
Objectifs des indicateurs du processus d'urbanisation du Système d'Information
Les 6 commandements de la démarche d'urbanisation du Système d'Information.
Connaître le SI existant. Cette connaissance, qui est indispensable pour faire évoluer le système d'information, porte à la fois sur les processus métiers et les applications du SI. Elle fait l'objet de référentiels cartographiques, dont la mise à jour doit accompagner les changements apportés au SI.
Gérer les référentiels majeurs pour l'entreprise. L'existence au sein d'un SI, de multiples bases de données ou fichiers contenant des données semblable, mais loin d'être identiques, est toujours un facteur de complexité ou de surcout.
Cet objectif permet d'évalue si les données métier de référence sont défini de façon unique et connue de tous, si la responsabilité de chaque référentiel est attribué à une maîtrise d'ouvrage identifiée. Enfin, il permet de vérifier si les dispositifs de gestion des données de référence permettent d'en assurer la qualité, la cohérence et la disponibilité.
Disposer de cibles pour l'évolution du SI. L'élaboration de ces cibles fonctionnelles, applicatives et techniques permet d'une par de s'assurer que la réalisation des nouveaux projets s'inscrit bien dans le cadre de ces cibles.
Permet de s'assurer en permanence que ces cibles sont en harmonie avec la stratégie de l'entreprise.
Maîtriser une construction du SI pour l'ensemble de l'entreprise. Pour atteindre ces cibles, il faut définir et mettre en œuvre un plan de migration ou road map, élaborer et diffuser des règles d'urbanisme applicables par les équipes de projets (maîtrises d'ouvrage et maîtrise d'œuvre).
Grâce à un accompagnement permanent des projets par les urbanistes, il faut en outre s'assurer que ces règles sont effectivement appliquées dès la première étude amont.
Maîtriser la complexité des flux d'échanges d'informations. L'indicateur portera sur la description des flux inter-applicatif, la standardisation de ces échanges, au moins pour les données majeures de l'entreprise.
Il faut vérifier la mise en place, l'administration et la maintenance de dispositifs d'échanges mutualisés.
Piloter et supporter l'urbanisation du SI. Pour mettre en œuvre le processus d'urbanisation, il faut des moyens adaptés.
L'indicateur analysera la modélisation de ressources pour l'urbanisme (définition de la fonction d'urbaniste, insertion des urbanistes dans les structures de gouvernance). Permet de vérifier la mise œuvre de dispositif de communication et de formation pour l'ensemble des acteurs projets.
Pour chaque objectif est associé un certain nombre de critère (3 à 5) et à chaque critère est associé une mesure, noté de de 0 à 4, selon une grille prédéfini associé à chaque critère.
L'indicateur de cette mesure est :
soit quantitatif : par exemple, pour les référentiels de cartographie, les notes sont attribuées selon le taux de couverture de la cartographie ;
soit qualitatif : l'indicateur caractérise des notions telles que le champ, la fréquence, la profondeur des actions associées au critère.
« Faiblesse et courage, étourderie et raison, caprice et dévouement ! la femme est un composé de tout cela. »
Goswin Joseph Augustin, baron de Stassart
Rhona Maxwel
@rhona_helena
Articles conseillés :
Quelle est l'étape la plus importante dans l'urbanisation des SI ?
Pas de nouvelles, mauvaises nouvelles
Quels sont les axes de recherche et développement de l'urbanisation ?
Vous cherchez désespérement un formalisme pour vos processus métiers mettant en accord MOA et MOE, la solution miracle existe, elle s'appelle BPMN
BPMN est un langage plus concret spécialement conçu pour les experts métiers afin qu'ils puissent représenter leurs processus métiers avec la terminologie qu'ils connaissent
Vous avez été nombreux à suivre la saga sur SysML, une nouvelle série commence consacrée à BPMN ( catégorie : BPMN )
BPMN 2 : les concepts de base des processus métiers
BPMN pour les nuls : les collaborations
BPMN pour les nuls : les chorégraphies (Choreographies)
BPMN pour les nuls : les conversations
BPMN : norme OMG - synthèse des éléments graphiques
BPMN : l'antisèche pour rester incollable en modélisation de processus
BPMN l’exemple type pour tout comprendre sans prendre d’aspirine
BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza
BPMN : processus exécutables, comment s'y prendre ? (1/3)
BPMN : processus exécutables, comment s'y prendre ? (2/3)
BPMN : processus exécutables, comment s'y prendre ? (3/3)
Le langage BPMN (Business Process Model & Notation) est une norme de l'OMG (Object Management Group) comme UML (Unified Modeling Language).
UML est un langage de modélisation générique avec lequel on peut tout modéliser à condition de bien maîtriser ses concepts et ses techniques d'extension alors que BPMN est un langage plus concret spécialement conçu pour les experts métiers afin qu'ils puissent représenter leurs processus métiers avec la terminologie qu'ils connaissent.
La modélisation des processus métiers avec UML (diagramme d'activité, ...) à toujours été rejetée par les experts métiers, trouvant UML trop technique et réservé à une élite d'informaticiens.
Un des objectifs de la norme BPMN est de faciliter la communication entre tous les acteurs impliqués dans un projet informatique tant au niveau cartographie des processus métier que sur le plan de la modélisation des besoins d'une application.
BPMN est censé être un véritable "espéranto" pour les processus métier depuis l'expert métier jusqu'au développeur.
Il permet d'avoir une représentation visuelle du fonctionnement d'un processus et ce, autant pour les expert métiers, les techniciens qui mettent en œuvre la solution technologique exécutant le processus et les utilisateurs, qui gèrent et contrôlent les processus.
Rhona Maxwel
@rhona_helena
"Quand tu sens que tu ne vas pas y arriver, tu sens aussi que ton probable échec te mettra sur la voie d'une réussite à venir."
Vincent Cespedes
La démarche de l'urbanisation des systèmes d'informations : comment mesurer les progrès ?
Un processus n'est bien défini que s'il est mesurable.
La démarche d'urbanisation est une tâche qui prend du temps, la communication doit être sans faille, les progrès doivent être visibles et l'on doit s'efforcer de renouveler la motivation et l'énergie nécessaire.
Fini le simple inventaire d'avantages qualitatifs, il faut objectiver grâce à des indicateurs servant de véritable outil de mesure.
L'indice est donc un outil de mesure et de management : il permet d'apprécier si l'urbanisation du SI est en "bonne voie", c'est à dire si les actions menées s'inscrivent dans une démarche de meilleures maîtrise de l'urbanisation du SI. En ce sens, il différencie l'urbanisme d'une démarche comme CMMI : cette dernière se concentre sur le pilotage du processus, alors que l'indice d'urbanisation mesure le résultat sur la base de faits démontrables correspondants aux résultats du processus mis en œuvre.
Il faut mettre en œuvre la cotation de l'indice d'urbanisation et l'utiliser comme outil de pilotage de l'urbanisation de leur système d'information.
Rhona Maxwel
@rhona_helena
"C'est toute la beauté des larmes ; elles peuvent avoir deux significations opposées.
On pleure de douleur, on pleure de bonheur.
Peu de manifestations physiques ont cette identité à deux têtes, comme pour matérialiser la confusion."
David Foenkinos
Articles conseillés :
Avec un peu de métier, métamodéliser la vue métier pour assurer la traçabilité avec la stratégie
Visiter la "salle machine" de l'urbanisation des SI