urbanisation-si

urbanisation-si

Le processus d'urbanisation du Système d'Information


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.

 

processus-urbanisation-systeme-d-information-indice-urbanisation-01.png

 

 

urbanisation-systeme-d-information-tableau-processus-indice.png

 

Les indicateurs des processus d'urbanisation du SI

 

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


10/12/2016
0 Poster un commentaire

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.

 

urbanisme-systeme-d-information-methode-top-down.jpg

 

 Classiquement, le plan d'urbanisme est constitué de 4 couches qui doivent être cartographiées.

  

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


08/12/2016
0 Poster un commentaire

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.

 

processus-urbanisation-systeme-d-information-indice-urbanisation-01.png

  

Ce qu'il faut mesurer pour connaître la progression du processus d'urbanisation du Système d'Information.

 

Objectif 1 :

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.

 

Objectif 2 :

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é.

 

Objectif 3 :

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.

 

Objectif 4 :

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.

 

Objectif 5 :

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.

 

Objectif 6 :

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 :

 

2/11 Projet informatique, passer du moyen âge à l'ère industrielle. Urbanisez pour mieux régner, 1ère partie : les fondations.

 

2/11 Projet informatique, passer du moyen âge à l'ère industrielle. Urbanisez pour mieux régner, 2ème partie : les gains et les réticences.

 

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 ?


07/12/2016
0 Poster un commentaire

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.

 

processus-urbanisation-systeme-d-information-indice-urbanisation-01.png

 

Et pour cela, il y a l'indice d'urbanisation : évaluer l'état de la démarche d'urbanisation de tout de le système d'information de l'entreprise ou d'une partie.

 

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

 

En urbanisation SI, comment définit-on la vue fonctionnelle et quels sont les liens avec la vue métier et applicative ?

 

En urbanisation SI, comment met on en oeuvre la traçabilité entre la vue applicative et les vues fonctionnelle et infrastructure ?

 

Visiter la "salle machine" de l'urbanisation des SI

 

Le Big-Mac de l'urbanisation SI


06/12/2016
0 Poster un commentaire

L'urbanisme des SI et architecture d'entreprise : retour vers le futur

retour_vers_le_futur.jpg

 

L'avenir de l'urbanisme de SI sera lié à 3 facteurs :

  1. La généralisation des relations en entreprise étendue, au delà des périmètres figés de la firme traditionnelle.
  2. La montée inéluctable des organisations autour des processus, du management par les processus, qui remettra en cause les fonctionnements internes, et sera reliée aux SI urbanisés.
  3. L'extension progressive des solutions techniques et conceptuelles basées sur des architectures de services pour les fonctions métiers souvent développées par les informaticiens de l'entreprise, comme pour les fonctions de support traditionnellement confiées à des ERP.

Le 1ère évolution, les relations entre les acteurs économiques, de plus en plus basées sur la technologie, gommeront les espaces traditionnels.

Les entreprises interagiront plus fortement, dans des processus plus directs et plus tendus avec leurs clients et leurs partenaires.

Ce fonctionnement en entreprise étendue qui existe déjà chez de nombreux grands comptes, deviendra la règle.

Dés lors, le champ des préoccupations d'urbanisme débordant le monde clos de l'entreprise, il faudra raisonner sur l'entreprise et son écosystème.

Les flux, la gestion des grands référentiels, l'activation de services automatisés, de bases de connaissances, seront à situer dans un contexte élargi, où les mouvements stratégiques, partenariats, fusions, filialisations, acquisitions, externalisations, pourront redistribuer les cartes autour des composants urbanisés.

Les urbanistes devenant architecte de la chaîne de valeur, auront à étendre leurs investigations jusqu'aux limites de ces champs d'action.

 

La 2ème évolution, elle aussi déjà engagée, concerne la vision processus. en effet la recherche de l'efficience, de la flexibilité et la proposition pour le client de la plus grande efficacité, continueront à bousculer les organisations. 

La déformation des entreprises organisées en silos, en des modèles orientés processus deviendra une généralité.

Il faudra se préoccuper de diffuser la culture du management par les processus, de faire passer le BPM dans la réalité : instituer des propriétaires de processus, gouverner l'amélioration et piloter les performances pour que les processus répondent aux services qu'attendent les multiples parties prenantes, clients, usagers, partenaires, employés, actionnaires, sociétaires, ...

L'urbanisme des SI incite à décrire les processus métiers.

C'est un début, mais les processus sont considérés comme une entrée, et l'urbaniste n'a pas de légitimité pour les optimiser, voire les remettre en cause.

Pourtant dans le futur, il faudra fédérer les approches par les SI et celles par les processus, connecter les différentes visions transversales, réaliser la symbiose des méthodes, veiller à la cohérence des gouvernances SI et processus : les urbanistes seront les catalyseurs de cohérence, de transversalité, et de flexibilité.

 

La 3ème évolution majeure se réfère à la sphère technique.

Urbaniser le métier ou architecturer l'entreprise, tire les urbanistes vers le haut, que leur référence s'appelle urbanisme des SI, EA (Enterprise Architecture ou Architecture d'Entreprise) ou BPM (Business Process Management ou Gestion des Processus Métiers).

Ils ne doivent pas ignorer les évolutions techniques.

Un miracle technologique se produira-t-il (attention aux effets de buzz) ? Une révolution technique donnera-t-elle l'agilité instantanée tant espérée ? 

 

Comme le montre notre X-Men John Zachman dans son modèle, pour l'instant aucune bonne fée n'est apparue avec sa baguette magique, il sera toujours nécessaire d'architecturer l'entreprise.

 

Les grandes entreprises dotées de SI de plus en plus complexes, seront confrontées à un environnement réglementaire multiple, protéiforme, à des contraintes de marché archi-mondialisées.

Il leur faudra lutter férocement contre l'entropie et rechercher toujours plus d'agilité.

Dans le futur, tel un funambule, l'urbaniste devra maintenir l'équilibre sur une corde qui sera disposée malheureusement de plus en plus haut.

 

Rhona Maxwel

@rhona_helena

 

"Il n'y a rien de plus parfait que de trouver du bonheur à communiquer le sien."
Henri Lacordaire


02/05/2016
0 Poster un commentaire

Architecture d'entreprise : le framework de Zachman pour les nuls

urbanisation-si-arcitecture-d-entreprise-framework-zachman.jpeg

 

Le système d’information d’une organisation peut s’organiser suivant une matrice (Framework de Zachman) ou les colonnes sont les traditionnels : Quoi (inventaires des données), Comment (processus métier), Ou (localisation, distribution), Qui (Acteurs, responsabilités), Quand (temporalité, fréquence), Pourquoi (motivations, objectif stratégiques) et les lignes représentent les niveaux du plus au moins abstrait : Contexte (identification du périmètre métier, planification), Conceptuel (concepts et modèles métiers), Logique (architecture, modèles de conception), Ingénierie (réalisation des entités métiers, spécifications techniques), Perspective physique (implémentations des composants métiers, outils) , Perspective entreprise (la réalisation des différentes activités dans l’entreprise) et les cellules représentent les artefacts à réaliser.

 

La métaphore de la cité : le POS (Plan d’Occupation des Sols) d’un SI a pour but :
• De définir les services et les responsabilités attachées à chaque sous-ensemble
• D’organiser le SI
• L’objet et la mission des applicatifs le composant
• Les regroupements d’applicatifs en ensemble cohérents
• Les périmètres réservés pour de futurs applicatifs à construire, notamment pour les applicatifs transversaux
Le POS d’un SI doit être compatible et s’aligné sur la stratégie de l’entreprise. Le dossier doit comporter :
• Synthèse sur les orientations et options retenues
• Un ensemble de cartographies (graphiques et commentaires associés) montrant avec précision les différentes subdivisions du SI et permettant de savoir à quels sous-ensembles du SI s’applique ou non une règle d’urbanisme donnée
• Les règles d’urbanisme ainsi que la définition de la mission et des services de chaque zone, quartier et îlot
• Annexes, CR d’entretiens, liste des personnes concernées, …
Le découpage en zones suit la typologie suivante :
• zone échange est responsable de l’acquisition/restitution du SI vis à vis de son environnement extérieur
• zone gisement de données : ensemble de toutes les informations dynamiques et pérennes ainsi que les services d’accès à ces données et assure la conservation et la valorisation du patrimoine d’informations, garantit sa cohérence et permet son enrichissement dans le temps
• zone référentielle des données de l’entreprise : regroupe l’ensemble de toutes les informations communes aux différents éléments du SI dont le cycle de vie est relativement stable
• zones opérations : on en trouve par métier principal
• zone ressource : regroupe les systèmes dédiés à la gestion des ressources internes (RH, comptabilité, …)
• zone pilotage
Les quartiers dans le SI sont des composants homogènes quant à la nature de l’information traitée. Ils correspondent à un sous-système. On a un couplage faible et une forte cohérence entre les quartiers. Ils regroupent les îlots qui sont les plus petits niveaux de décomposition du SI.
Un îlot :
• représente des entités (développées ou achetées) remplaçables du SI
• correspond à un but fonctionnel et avoir des accès à des bases de données
• reçoit ou émet des données vers d’autres îlots
• équivalent à une application ou une grande fonction applicative
• progiciel ou module d’un progiciel.
Mais à quoi peuvent bien ressembler les règles d’urbanisme ? Exemple :
• Interdictions comme d’accéder à un bloc sans passer par son port (prise)
• Limitations, par ex. une donnée doit être sous la responsabilité d’un et d’un seul bloc
• Prescription, par ex. tout bloc doit avoir un port (prise)
Parmi retours d’expérience les plus fréquemment cités :
• Les cartographies des applications existantes sont exhaustives et constituent un référentiel partagé, complet et administré de façon centralisé
• Les cartographies d’états futurs du SI sont moins fréquentes et leur niveau de détail est d’autant moins fin que l’on se projette dans un futur lointain
• La mise à jour des cartographies est réalisée dans la plupart des cas par des cellules dédiées mais la tendance est d’inscrire la mise à jour de la cartographie dans la méthodologie de conduite de projet
• La restitution des cartographies se fait par l’intermédiaire d’un intranet en général largement ouvert aux utilisateurs concernés
Néanmoins malgré sa très large généralisation, la cartographie applicative rencontre des difficultés :
• La coexistence de la cartographie de l’existant, de cartographie futures à différents horizons et d’une cartographie cible est difficile à obtenir
• La maîtrise de la cohérence du référentiel de cartographie, notamment en ce qui concerne les flux inter-applicatifs, nécessite un processus formalisé de mise à jour, qui n’est pas toujours en place ce qui nécessite d’effectuer des contrôles à posteriori
• La production de sous-ensembles cartographiques spécifiques n’est pas automatisée
• Le maintien à jour de la cartographie est difficile et nécessite organisation, suivi et support du management
Mais, la question qui intéresse tout le monde, c’est en quoi un environnement urbanisé peut-il réduire les coûts projet. Les réponses sont multiples :
• Mise à disposition d’informations sur le contexte fonctionnel et les applications
• Anticipation des impacts des autres projets
• Réduction des études amont et des études préalables
• Réduction du risque de fausse route
• Maîtrise du périmètre des projets
• Réduction des risques liés à la taille des projets
• Réduction des études, des développements et de la recette
• Existence de briques directement utilisables (composants, référentiels, EAI, ESB, données…)
• Existence de règles de construction qui permettent aux projets de se centrer sur les problèmes métier.
Pour les spécifications, on a un surcoût de l’ordre de 20% au départ pour passer à une orientation processus et une économie par la suite de 30% du à la simplification des études d’impact d’où un gain net de 10%.
Sur le développement on a un gain net de 20% car les objets métiers sont mutualisés et externalisés des processus.
L’intégration gagne en net un facteur de 40%. Il faut en effet au départ un surcoût de 30% pour acquérir le technique des bus logiciel et des adaptateurs mais une économie par la suite de l’ordre de 70% grâce à la réutilisation et au fait qu’il faille un seul adaptateur à réaliser pour se connecter au bus. 
Ce que gagne l’exploitation, environ de l’ordre de 20% du aux découplages des systèmes et la flexibilité des hébergements, est perdu à cause des logiciels à mettre en œuvre (bus, logiciel d’administration, de surveillance, …).
Bien souvent, des applications obsolètes continuent de tourner par peur de couper le « mauvais fil » tellement les liens qui la relie au SI constitue un véritable plat de spaghetti. Si le SI est bien urbanisé, un seul lien à désactiver suffit d’où un gain net estimé à 80%. 
Bien sur ces contributions continuent leurs effets dans les phases d’évolution ou de maintenance.
La gouvernance du SI optimise l’ensemble « fonctionnalités, coûts, délais » en misant sur l’urbanisation du SI. Chaque projet, lui aussi, optimise le même ensemble, mais à son échelle.
Pourquoi les projets sont-ils réticents à appliquer les règles d’urbanisme, parce qu’ils y voient une source de coûts additionnels.
La raison est que chaque projet voit les efforts de maintien ou d’amélioration de l’urbanisation comme générateurs de coûts. La raison d’être même des projets explique ce point de vue. En effet, un projet est constitué pour fournir, partant d’une situation donnée, une situation cible dans des coûts et délais déterminés. Les facilités que lui offrent son environnement, fruit des projets précédents, et les surcoûts éventuels qu’il génère aux projets suivants ne sont pas prises en compte par le projet. Un projet ne tient pas compte des efforts passés : il ne valorise pas dans son budget ce qui lui apporte un contexte urbanisé. Le projet n’a aucune nécessité de simuler quel aurait été son coût si la cartographie n’était pas à jour, s’il n’y avait pas de référentiels, si aucun mécanisme d’échange inter-applications n’était disponible, ... ce contexte à haute valeur ajoutée est considéré comme gratuit, alors qu’en fait, il s’agit d’une réduction de coût financée par les projets antérieurs. Un projet ne tient pas compte de la situation qu’il laisse: le projet ne valorise pas non plus le surcroît de travail qui sera demandé aux projets suivants et à la maintenance du produit si le projet dégrade l’urbanisation. Par contre, chaque jour de travail à maintenir ou améliorer l’urbanisation apparaît dans ses charges: tout naturellement, le projet va privilégier les ressources vers des tâches qui participent à l’atteinte de ses objectifs. Les tâches « pour la suite » apparaissent inévitablement comme des surcoûts.
Il faut se lancer dans l’urbanisation dès le départ du projet, les méthodes, les retours d’expérience et les outils existent et font qu’aujourd’hui urbaniser son SI n’est plus une aventure mais de la vulgaire routine.   

 

"Rien ne vous emprisonne excepté vos pensées. Rien ne vous limite excepté vos peurs. Et rien ne vous contrôle excepté vos croyances."
Marianne Williamson

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


17/09/2015
0 Poster un commentaire

Urbanisation du Système d'Information vs Architecture d'Entreprise

Architecture-Entreprise-Framework-Zachman-vs-Urbanisation-SI-2.png

L'architecture d'Entreprise comme le célèbre framework Zachman, couvre toutes les strates de l'entreprise. Il est alors intéressant de voir quelles sont les lignes et colonnes couvertes par l'urbanisation du système d'information. 

Le procesus d'urbanisation répond aux couches "Scope (contexte)" , "Business Model (conceptuel)" et "System Model (logique)".

La stratégie de l'entreprise (Scope) et ses processus métier (Business Model) doivent être réalisés (en partie) par le SI (System Model). Une des préoccupations de l'urbanisme du SI est de mettre en oeuvre cette implémentation et la traçabilité nécessaire.

Ainsi la structure organisationnelle,  le modèle métier avec  ses processus, ses entités et leurs cycle de vie, sont liés aux systèmes applicatifs et leurs modèles de données.

La démarche d'urbanisme descend jusque sur l'axe  de préoccupation "System Model" correspondant à la vue logique du SI.

Cette comparaison avec le framework de Zachman montre bien que l'urbanisation des systèmes d'information joue le rôle de "glu" entre les processus métier et leurs dérivations logiques dans le SI.

 

"Tu dois devenir l'homme que tu es. Fais ce que toi seul peux faire. Deviens sans cesse celui que tu es, sois le maître et le sculpteur de toi-même."
Friedrich Nietzsche

  

 Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


13/07/2015
0 Poster un commentaire

Urbanisation du Système d'Information : MOE, boulversez vos habitudes, le changement a du bon !

urbanisation-du-systeme-d-information-accompagenement-changement-developpeur.jpg

Le changement est stimulant pour l'intellect. 

Un processus d'urbanisation s'accompagne forcément de changements dans les manières de travailler de la MOE et de la MOA.

La réticence aux changements est un comportement humain normal qui engendre une peur, un stress de ce que l'on ne connaît pas.

On a toujours le réflexe de dire "avant c'était mieux" en oubliant de préciser le contexte et quels étaient les buts à l'instant des choix.

Le plan d'urbanisme impose des modifications draconiennes dans les processus de réalisation des systèmes d'information.

Tous les acteurs de la MOE, architectes techniques, concepteurs, développeurs, ... doivent s'approprier de nouvelles technologies, se conformer à de nouvelles méthodes et assimiler de nouveaux paradigmes.

Il est donc légitime qu'ils perdent leurs repères, qu'ils critiquent sévèrement certains acteurs, qu'ils éprouvent une certaine confusion et le sentiment que tout leur échappe.

L'accompagnement au changement qui est absolument primordial dans la démarche d'urbanisation du SI, doit permettre : l'appropriation des concepts, la suppression des peurs, la mauvaise compréhension des valeurs de l'entreprise communiquées par la démarche, la reconnaissance du travail déjà accompli et enfin d'amoindrir la nostalgie du passé.

Cet accompagnement au changement doit tenir compte des fonctions occupées, des statuts, du contexte de travail et des bases des évaluations pour les évolutions de carrière. 

La capacité de la MOE à adapter son comportement et à acquérir des nouvelles compétences ne se fera que si un accompagnement du changement a été pleinement conçu et mis en oeuvre avec succès. 

 

"La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information."
Albert Einstein

 

 Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


07/07/2015
0 Poster un commentaire

Urbanisation du Système d'Information : la MOA fait partie d'un projet et un projet ne fait pas de politique !

urbanisation-systeme-d-information-responsabilite-MOA.png

Une des difficultés dans le processus d'urbanisation du système d'information réside dans la conception et la modélisation des processus métiers. La maîtrise d'ouvrage devrait être apolitique et créer ses processus en fonction de la seule stratégie de l'entreprise.

Or dans la réalité, la création ou l'évolution des processus métiers se font en fonction des intérêts de telle ou telle personne cherchant à prendre du galon ou à résoudre ses propres conflits.

Ceci entraîne des processus non optimisés, qui soutiennent de manière incomplète les objectifs opérationnels du SI.

De plus, la MOA ne fait pas d'efforts pour s'organiser et se rendre disponible pour le projet.

La direction Générale doit donc impliquer la MOA et la responsabiliser dans l'atteinte du bon déroulement du projet et donc dans la conception et la modélisation des processus métiers.

La modélisation des processus métiers est réalisée par la MOA opérationnelle (ou déléguée ou AMOA) en collaboration étroite avec la MOE pour la faisabilité technique et les estimations de charges, le tout sous la responsabilité de la MOA  stratégique.

La MOE  a un devoir d'alerte en cas de problèmes techniques, de performances, d'estimation de charges trop importante et est force de proposition pour tirer le meilleurs profit des avancées technologiques.

La versatilité de la MOA et sa difficulté à valider les évolutions d'un processus font partie des causes importantes d'échecs de projets d'évolution du SI.

L'assistance à MOA et avec la MOE doit fournir les techniques pour proposer un dossier de choix comportant plusieurs scénarios de solutions qui devront être partagées par l'ensemble des parties prenantes du projet.  

 

"L'égoïste n'est pas celui qui vit comme il lui plaît, c'est celui qui demande aux autres de vivre comme il lui plaît ; l'altruiste est celui qui laisse les autres vivre leur vie, sans intervenir."
Oscar Wilde

 

 Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


06/07/2015
0 Poster un commentaire

Urbanisation du Système d'Information : abolissez l'apartheid et vive la cohabitation entre MOA et MOE !

urbanisation-du-systeme-d-information-relation-MOA-MOE.gif

 

Le succès de la démarche d'urbanisation du Système d'Information passe par un re-engineering des relations entre maîtrise d'ouvrage et maîtrise d'oeuvre.

Terminé ce clivage entre 2 camps qui ne se comprennent pas ou plus exactement qui ne voulent pas se comprendre.

Sous l'impulsion de la direction générale, les projets doivent fédérer au sein d'une même entité la MOA et la MOE. Réinventons l'articulation des travaux entre MOA et MOE.

Travaillant ensemble pour atteindre les mêmes buts, elles se comprennent mieux et donc conçoivent ensemble  les meilleures solutions pour l'entreprise.

Pour que ça marche concrètement, la MOA est partagée en

  • MOA stratégique, c'est à dire l'ensemble des experts métiers ayant une longue ancienneté et qui possèdent la vision métier,
  • MOA opérationnelle ou déléguée qui a pour mission de traduire la vision métier en axes d'évolution du système d'information, de concevoir et de modéliser les processus métier, d'établir les cahiers des charges, de tester et de valider les nouvelles applications.

Si la MOA se divise en une partie experte dans le métier et une autre partie plus technique faisant l'interface avec la MOE, la MOE doit elle aussi avoir une partie plus fonctionnelle ayant une connaissance métier et bien entendu une partie constituée d'experts techniques.

La MOA opérationnelle ou déléguée et la MOE "interface fonctionnelle" parlent la même langue, comme les langages de modélisation  (UML, SysML, BPMN, mind map, KAOS, ...) qui sont les "espéranto" pour toutes les parties prenantes du système d'information.

Le respect du cadre d'urbanisme, l'exécution de la méthode d'urbanisation et la prise de décisions amenant à la construction de la trajectoire vers le système cible, relève du comité de direction du SI avec l'aide de la celllule d'urbanisme.

Tant que la fracture MOA / MOE subsistera, il y aura à coup sur des projets en échecs et des systèmes d'information figés, n'acceptant les évolutions du marché qu'aux prix de très gros efforts, parfois insurmontables !

 

"Nous devons apprendre à vivre ensemble comme des frères, sinon nous allons mourir tous ensemble comme des idiots"

Martin Luther King

 

 Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


05/07/2015
1 Poster un commentaire