Le processus d'urbanisation du Système d'Information
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
L'urbanisme des SI et architecture d'entreprise : retour vers le futur
L'avenir de l'urbanisme de SI sera lié à 3 facteurs :
- La généralisation des relations en entreprise étendue, au delà des périmètres figés de la firme traditionnelle.
- 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.
- 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
Architecture d'entreprise : le framework de Zachman pour les nuls
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/
Urbanisation du Système d'Information vs Architecture d'Entreprise
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/
Urbanisation du Système d'Information : MOE, boulversez vos habitudes, le changement a du bon !
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/
Urbanisation du Système d'Information : la MOA fait partie d'un projet et un projet ne fait pas de politique !
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/
Urbanisation du Système d'Information : abolissez l'apartheid et vive la cohabitation entre MOA et MOE !
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/
Urbanisation du Système d'Information : les origines
Dans les 90s, un cadre de pensée s'est développé aux states ayant trait à l'architecture d'entreprise (EA), avec des buts similaires à l'urbanisation des Systèmes d'Information.
L'EA est comme l'urbanisation du SI une méthode à la fois top-down et bottom-up avec comme objectif la modélisation globale de l'ensemble des ressources de l'entreprise (stratégie, processus métier, briques fonctionnelles et applicatives, infrastructures techniques, ...), donc la volonté de définir un référentiel d'entreprise.
Citer souvent comme à l'origine de l'EA, l'Enterprise Architecture Model du NIST (National Institute of Standards and Technology = l'équivalent de l'AFNOR mais pour les Etats Unis) comprend une architecture en couches allant du métier à l'infrastructure technique.
Le but est d'avoir la description généralisée
- du fonctionnement de l'entreprise, de sa stratégie, de ses procesus métiers, ...
- de l'architecture du système informatique, les applications, les SGBD, les machines, réseaux, ...
- des relations entre les niveaux
Les prises de décision sont ainsi facilitées en montrant les impacts potentiels sur l'organisation, les processus, le SI, ...
Toutes les parties prenantes de l'entreprise ont une vision globale, organisée des ressources de l'entreprise grace au référentiel d'entreprise.
Depuis, les administrations américaines ont l'obligation d'intégrer ce type d'architecture sans quoi point de subventions.
Coté français, un gros effort a été fait avec le cadre commun d'urbanisme inter ministériel, encore faut il que tous les acteurs s'approprient la méthode et soient convaincus de son efficience.
"Aimer, c'est se surpasser."
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/
Urbanisation du Système d'Information : vous ne voyez pas, vous voulez que je vous donne un indice ?
L'urbanisation du Système d'Information est une démarche mettant en oeuvre les bonnes pratiques pour rendre le SI plus agile afin qu'il puisse réaliser la stratégie de l'entreprise.
Encore faut il qu'on sache où on en est dans la progression de la méthode ?
La technique classique pour connaître les progrés réaliser et de définir des indices constitués de mesures qualitatives et quantitatives concernant des critères les plus représentatifs de la démarche.
On trouve le plus souvent 6 critères :
- connaître le système existant,
- gérer les référentiels majeurs,
- disposer de cibles pour les évolutions du SI,
- maîtriser une construction du SI optimale pour l'ensemble de l'entreprise,
- maîtriser la complexité des flux d'échanges d'information,
- piloter l'urbanisation du SI et communiquer.
Des représentations formelles sous forme de diagrammes radar, permettent d'analyser les résultats et de planifier les progrès restants à fournir pour continuer à insufler la dynamique de développement de la méthode d'urbanisme du SI.
"Et que le vent hagard, soufflant dans son clairon,
Dénoue au-dessus d'eux sa longue et folle tresse
Et que peut-être ils sont à cette heure en détresse,
Et qu'on ne sait jamais au juste ce qu'ils font"
Victor Hugo
Les pauvres gens - La légende des siècles
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/
Urbanisation du Système d'Information : on n'est pas chez "Bic", donc pas de solutions jetables !
La partie opérationnelle de l'urbanisme du Système d'Information se concrétise dans les relations avec les équipes projets.
Cela commence dès la phase d'inception (ou première phase d'initialisation du Unifiel Process = méthode de gestion projet), lors des études d'opportunité et de faisabilité du projet et se poursuit pendant tout le cycle de vie du projet.
Les règles d'urbanisme doivent être prises en considération pendant les études préalables et l'expression des besoins.
La communication entre l'urbaniste et le chef de projet est primordiale.
La stratégie à moyen ou long terme doit l'emporter face à l'urgence et aux solutions jetables.
Il faut argumenter et convaincre pour ne pas se lancer dans des : "pour l'instant on va faire comme ça et on verra comment cela évolue".
Par la suite, il faut s'assurer lors des revues de conformité, de la bonne application du dossier d'architecture fonctionnel produit et continuer à exercer un rôle de conseil tout au long du projet.
"C'est à partir de toi que j'ai dit oui au monde."
Paul Eluard
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/