urbanisation-si.com

02/05/2015

0 J'aime 0 Poster un commentaire

Partir du bon pied dans un projet informatique : la modélisation métier

Évaluer le fonctionnement métier de l'organisation

Capturer le vocabulaire métier utilisé par l'organisation.
Recenser et structurer les règles métier.
Évaluer les cibles de l'organisation
Identifier et ajuster les buts
Développer un guide de modélisation métier
Artefacts produits ou modifiés :
- Vision métier
- Evaluation des objectifs de l'organisation
- Glossaire métier
- Document contenant les règles métier

Décrire l'organisation actuelle

Trouver les acteurs métier et les Use Case métier (stéréotypes UML)
Identifier et ajuster les buts
Trouver les travailleurs métier et les entités métier (stéréotypes UML)
Modéliser le contexte statique (diagramme de classe)
Modéliser le contexte dynamique (diagramme de collaboration)
Artefacts produits ou modifiés :
- Evaluation des objectifs de l'organisation
- Modèle de Use Case métier
- Description des Use Case métier
- Suppléments de spécifications métiers
- Vision métier
- Modèle d'objets métiers
- Évaluer les cibles de l'organisation
- Réalisation des Use Case métier

Identifier les processus métier

Mettre à jour les règles métier (si nécessaire)
Identifier et ajuster les buts
Définir l'architecture métier
Capturer le vocabulaire métier utilisé par l'organisation
Trouver les acteurs métier et les Use Case métier (stéréotypes UML)
Artefacts produits ou modifiés :
- Document contenant les règles métier
- Vision métier
- Document d'architecture métier
- Glossaire métier
- Modèle de Use Case métier
- Description des Use Case métier
- Suppléments de spécification

Affiner les définitions des processus métier

Détailler les Use Case métier
Revoir le modèle de Use Case métier (si nécessaire)
Structurer le modèle de Use Case Métier (package, include, extend, héritage) (si nécessaire)
Modéliser (si nécessaire) les processus métier avec un langage (profil UML Eriksson Penker, BPML, ...)
Détailler les activités des processus précédents
Mettre à jour le glossaire (si nécessaire)
Mettre à jour les règles métier (si nécessaire)
Revue de validation
Artefacts produits ou modifiés :
- Fiche de Use Case Métier
- Diagramme de BPM (Business Process Model) avec le profile UML de Eriksson – Penker
- Diagramme d'activité à forte granularité représentant les activités de chaque processus métier
- Compte-rendu de la revue

Concevoir la réalisation des processus métier

Affiner les diagrammes d'activités en ajoutant les couloirs (d'abord les sous-systèmes métiers puis les travailleurs métiers)
Trouver les travailleurs métiers (stéréotype UML)
Trouver les entités (objets métiers stéréotype UML Entity)
Mettre à jour les règles métier (si nécessaire)
Définir l'architecture métier
Artefacts produits ou modifiés :
- Glossaire métier
- Modèle des objets métiers
- Réalisation des processus métier
- Réalisations des Use Case métier
- Document contenant les règles métier
- Document d'architecture métier

Affiner les rôles et les responsabilités

Détailler les entités métier
Détailler les travailleurs métiers (fiches)
Affiner le modèle des objets métiers
Artefacts produits ou modifiés :
- Fiche des travailleurs métiers
- Entités métiers
- Unité d'organisation (Sous-systèmes)
- Compte-rendu de la revue

Explorer l'automatisation des processus

Définir les processus automatisables (stéréotype UML)
Revue de validation
Artefacts produits ou modifiés :
- Vision métier
- Modèle de Use Case métier
- Modèle d'analyse
- Besoins supplémentaires

Développer un modèle du domaine

Maintenir les règles métier
Capturer le vocabulaire métier utilisé par l'organisation
Détailler les entités métier
Trouver les travailleurs métiers (stéréotype UML)
Trouver les entités (objets métiers stéréotype UML Entity)
Affiner le modèle d'objets métiersArtefacts produits ou modifiés :
- Règles métiers
- Glossaire métier
- Modèle d'objets métiers
- Entités métiers
- Compte-rendu de la revue de validation

"Je ne suis pas d'accord avec ce que vous dites, mais le me battrai jusqu'à la mort pour que vous ayez le droit de le dire."

Voltaire

Voir aussi :

02/05/2015

0 J'aime 0 Poster un commentaire

Quelques raisons de l'échec des projets informatiques

Le retard, le demi-succès/échec voir le flop total d'un projet peut être du au fait que les utilisateurs ne savent pas ce qu'ils veulent ou ne savent pas communiquer leurs besoins. C'est l'éternel problème de la communication entre la MOA et la MOE. Je veux un lave linge et on me livre un lave vaisselle.

Les exigences peuvent changer tout au long du projet. De nouvelles réglementations, lois, politiques peuvent surgir et obliger à modifier des systèmes ou à se plier à de nouvelles normes ou processus.

La concurrence de plus en plus agressive et féroce impose de s'adapter rapidement en cours de réalisation de projet ou sinon on s'expose à développer une application déjà obsolète. Il faut savoir anticiper sur la technologie et faire les bons choix.

Très souvent, la direction générale ne s'implique pas dans le projet qui va alors s'enliser sans que rien de concret ne se réalise. Combien de projets ont accouché de milliards de tonnes de "spec" sans qu'il n'y ait une véritable application exécutable. On ne le dira jamais assez "seul compte l'exécutable".

Le manque de connaissance (attention je n'ai pas dit incompétence) sur la conduite de projet informatique est aussi un facteur de risque important. De trop nombreuse fois j'ai vu des directions avoir "les yeux plus gros que le ventre" et démarrer un projet bien trop volumineux en terme de périmètre et être obligée par la suite de retirer des blocs fonctionnels ou de les différer.

Au départ les directions disent on ne veut pas de vitrine technologique, les méthodes, la modélisation, les outils c'est trop cher, ça ne produit rien et ça ne sert à rien. Résultat rien n'est documenté, modélisé, simulé, tracé, bref le projet devient une sombre forêt marécageuse ou tout s'enlise et rien n'en sort.

Un des secrets des projets réussis (si si ça existe !), c'est de ne pas hésiter à s'entourer d'experts reconnus en gestion de projets informatiques, en architecture technique, en management, ... qui mettront en oeuvre les bonnes pratiques reconnues sur le marché et qui éviterons ainsi toutes les erreurs à ne pas faire. Ce seront des leaders qui donneront confiance et motiveront les équipes. Les projets seront découpés en lots à taille humaine, ils seront développés dans un cadre d'urbanisation du SI. Les collaborateurs penseront projet avant de penser à leur propre carrière. Les relations et la communication avec la MOE seront maîtrisées. Les bonnes pratiques et les meilleures technologies seront mis en oeuvre dés le départ pour avoir un avantage concurrentiel.

"L'effort d'unir sagesse et pouvoir aboutit rarement et seulement très brièvement.

Albert Einstein"

Voir aussi :

01/05/2015

0 J'aime 0 Poster un commentaire

Urbanisation SI : Les indicateurs d’urbanisme SI sont avant tout une aide à la définition de plan d’actions.

Les indicateurs d’urbanisation SI sont avant tout une aide à la définition de plan d’actions sur les travaux d’urbanisme SI pour une entreprise, en fonction de sa stratégie.

En dehors de l’atteinte d’un premier niveau de maturité global, l’importance d’un indice ne réside pas dans sa valeur absolue, mais bien dans les travaux planifiés pour faire évoluer sa valeur en fonction de la stratégie engagée, et donc dans son évolution dans le temps. Ces indicateurs doivent inciter à plus de transparence dans le pilotage, la communication et la maîtrise des transformations du SI de l’entreprise.

En plus de la vision globale , il sera nécessaire à terme d’avoir une vision de ces indicateurs par zones ciblées du POS.

Les indicateurs d'urbanisation SI permettant d’évaluer le niveau de maturité de la démarche d’urbanisation, implicitement ils permettent également de mesurer le niveau d’urbanisation du SI.

Il est très clair que pour pouvoir piloter la transformation du SI de l'entreprise avec efficience, et donc pour pouvoir disposer d’indicateurs pertinents et utilisables, il est déjà nécessaire d’avoir démarré cette démarche d’urbanisation SI. Il est nécessaire d’atteindre « un premier niveau » d'urbanisme SI, de gouvernance et en particulier d’outillage, qui deviendra un élément déterminant pour la construction d’indicateurs et donc de tableau de bord efficace.

Les indicateurs sont organisés par activité de la démarche d’urbanisation.

Pour plus de précisions voir le site du Club Urba-EA.

"Même pour le simple envol d'un papillon tout le ciel est nécessaire."

Paul Claudel

Voir aussi :

30/04/2015

0 J'aime 0 Poster un commentaire

Ubanisation SI : circulation à accés réglementée

En Ubanisation SI, les constructions/destructions et l’entretien du POS sont réglementés :

Chaque zone doit être rattaché à un et un seul des 5 domaines : Opération (1), Support (2), Pilotage & Contrôle (3), Échange (4), Référentiel (5) ;
Chaque secteur fonctionnel (zone, quartier, ou bloc) doit avoir un libellé unique, et n’est rattaché qu’à un et un seul secteur fonctionnel de niveau supérieur (domaine, zone ou quartier) ;
Chaque secteur fonctionnel est identifié par code unique (un entier, non signifiant, qui s’incrémente en fonction des ajouts)
Chaque secteur fonctionnel doit être accompagné d’une définition (description succincte, non ambiguë, et auto porteuse).
Le POS est un découpage fonctionnel ; il constitue une partition. C'est-à-dire qu’un objet métier, ou une fonctionnalité n’appartient qu’à un et un seul secteur fonctionnel, idéalement un bloc voire un quartier le cas échéant) du POS.
Le POS n’est disponible que dans une seule version à un instant t. L’historique des modifications est conservé, mais il n’y a pas de version cible et de version existante. Il s’agit de décrire à un instant la meilleure vision fonctionnelle du moment. Par ailleurs, il peut être utile d’identifier (de marquer) les zones ou quartiers qui doivent faire l’objet d’une étude plus poussée (redécoupage, fusion, révision en profondeur, etc.).

Règles de gouvernance des secteurs fonctionnels du POS :

À chaque zone du POS doit être associée un responsable de zone fonctionnelle (RZF), c'est-à-dire un référent métier chargé de définir la transformation stratégique de la zone en fonction de la stratégie métier
À chaque zone du POS doit être associé un correspondant urbanisation.
Consolidation au fil de l’eau des évolutions et demandes d’évolutions, dans des versions mineures, validées par les correspondants urbanisation.
Production d’une version majeure annuelle du POS reprenant l’ensemble des modifications validées par les responsables de zones fonctionnelles.
Les principes d’urbanisation conduisent de fait à un certain nombre de règles dans l’utilisation de ce POS pour construire l’architecture applicative d’une solution, par exemple : une application ne devrait couvrir qu’au plus un seul bloc.

Faire aisément ce qui est difficile aux autres, voilà le talent ; faire ce qui est impossible au talent, voilà le génie.

Henri-Frédéric Amiel

Voir aussi :

29/04/2015

0 J'aime 0 Poster un commentaire

Urbanisation SI : la carte au trésor se dissimule t-elle dans le POS ?

En urbanisation SI, le POS est un outil graphique, un fond de carte. Il comprend un ensemble de zones fonctionnelles, décomposées en quartier, eux même décomposés en bloc, le tout organisé dans 5 grands domaines fonctionnels.

Chacun de ces secteurs fonctionnels (les zones, quartiers ou blocs) est un ensemble de fonctionnalité et d’objets métiers (de données).

Ce fond de carte est notamment utilisable pour « projeter » ou « positionner » des éléments de pilotage sur chaque zone ou quartier, par exemple :

Nombre d’applications globales, nombre d’application dont la mise en production date de plus de 15 ans (applications anciennes)
Coûts de fonctionnement récurrent annuel, budget d’investissement sur l’année.

Le domaine « Opération » regroupe l'ensemble des fonctions et des objets métiers qui ont une orientation, une finalité, au service des d'acteurs (internes ou externes à l'entreprise).

Le domaine « Pilotage & Contrôle » regroupe l'ensemble des fonctions et d'objets métiers de pilotage transverses des activités de l'entreprise, ainsi que des fonctions de contrôle (audit, inspection…).

Le domaine « Ressource & Support » regroupe l'ensemble des fonctions et des objets métiers d'appuis ou de support aux autres domaines. Il s'agit principalement des fonctions de gestion des ressources : RH, Finances, Immobilier, Moyen Généraux, IT…

Le domaine « Échange » regroupe l'ensemble des fonctionnalités et des objets métiers relatifs aux échanges entre les différents acteurs contributeurs, utilisateurs, partenaires, clients. Les échanges présentent un caractère particulier qu'il convient d'une part de tracer mais aussi de gérer de manière plus globale en les regroupant par thème (clients, partenaires, ...).

Le domaine « Données transverses » regroupe et isole l'ensemble des données, et des fonctions qui les manipulent, transverses ou communes à la plupart, voir la totalité des zones des autres domaines. Ces données transverses sont organisées par thèmes.

Le remède à l'ennui est curiosité. Il n'y a pas de traitement pour la curiosité.

Dorothy Parker

Voir aussi :

29/04/2015

1 J'aime 1 Poster un commentaire

L'urbanisation du SI c'est comme pour les villes, il faut savoir ce qu'on peut construire et détruire et comment on circule.

En urbanisation SI, le Plan d'Occupation des Sols (POS) est un plan de classement unique de la vue fonctionnelle du SI.

Cette nomenclature est un outil essentiel pour :

la stratégie d'évolution du SI : définition de responsabilité par zone,
la priorisation des investissements : projection des portefeuilles sur le POS,
le cadrage en amont des études et des projets (analyse d'impact), les responsabilités sur les projets, et le cadrage d’une manière général de l’évolution et de l’optimisation du patrimoine applicatif
l’analyse du patrimoine (comparaison, simplification, mutualisation), notamment sur les domaines transverses (échange, support, pilotage & contrôle et données transverses)
les responsabilités en matière d’administration des données
le suivi des coûts et donc les démarches de transparence des coûts
la stratégie de construction du SI (et donc d’achat). Par exemple, il pourrait être utile d’indiquer par zone et quartier, le niveau de maîtrise du patrimoine logiciel sous jacent : est-ce du « fait maison » (développement spécifique ») ? est-ce majoritairement des packages (logiciels libres ou éditeurs) ? voir une solution en mode SaaS ?
un élément de communication avec les métiers et les MOE pour faciliter les prises de décisions et faciliter l’analyse du patrimoine applicatif, en positionnant sur chaque secteur fonctionnel les applications correspondantes, ou bien en positionnant des indicateurs.

Lorsqu'une porte se ferme, il y en a une qui s'ouvre. Malheureusement, nous perdons tellement de temps à contempler la porte fermée, que nous ne voyons pas celle qui vient de s'ouvrir.

Alexander Graham Bell

Voir aussi :

29/04/2015

0 J'aime 0 Poster un commentaire

Le Big-Mac de l'urbanisation SI

Dans la démarche d'urbanisation SI, pour atteindre le but de faciliter la compréhension mutuelle à la fois du patrimoine mais aussi des initiatives et projets de transformation, il est nécessaire de se référer à des nomenclatures communes. Elles permettent de répertorier et de classer les sujets concernés : des données, des applications, des processus, mais aussi des composants logiciels ou équipements techniques, ainsi que les initiatives et les projets de transformation. L’objectif est de définir et d’entretenir pour chaque point de vue sur le SI (vue stratégie, vue métier, vue fonctionnelle, vue applicative, vue infrastructure) une nomenclature de référence qui permette :

de structurer le patrimoine et sa transformation,
de faciliter la communication et la compréhension du patrimoine et des projets

Ces nomenclatures de références sont régies par trois principes fondamentaux : administration étendue, évolution continue et transparence. Il est préférable d’identifier l’ensemble

des zones. Pour trouver un parallèle, il est préférable d’avoir une photo panoramique avec des zones floues, qu’une photo ne présentant qu’une portion limité du champ de vision mais parfaitement nette.
Une nomenclature de référence est un cadre structurant qui doit présenter une stabilité globale. Toutefois sa réalisation est un travail sur le long terme qui nécessite des adaptations régulières, des affinages progressifs tout en suivant les évolutions de la réglementation, du métier, et des technologies. Une nomenclature n’est donc pas figée dans le temps, elle rentre dans un processus d’amélioration continue. La question du périmètre couvert notamment est importante.
Une nomenclature de référence est un cadre qui donne une vision d’ensemble sur le SI, il doit être diffusé et partagé le plus largement possible. Il ne contient par nature aucune information à caractère confidentiel.

"Hier est derrière, demain est un mystère, aujourd'hui est un cadeau, c'est pour ça qu'on l'appelle présent."

Proverbe chinois

Voir aussi :

29/04/2015

1 J'aime 0 Poster un commentaire

Urbanisation SI : attaquez les risques avant qu'ils ne vous attaquent !

La vue Risque transverse aux 5 autres est ajoutée pour enrichir les points de vue lors de l’analyse et la transformation du SI de l'entreprise.

Elle consiste à identifier les risques auxquels sont soumis les actions de transformation du SI et le SI lui même.

L’identification des facteurs de risques et leur positionnement par rapport aux principaux concepts des 5 vues, notamment avec leurs criticités et vulnérabilité permet une véritable gestion des risques.

S'il est bon de ne rien dire avant de parler il est encore plus utile de réfléchir avant de penser.

Pierre Dac

Voir aussi :

28/04/2015

0 J'aime 2 Poster un commentaire

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

Les concepts de la vue Infrastructure (salle machine !)

La vue Infrastructure permet de décrire les équipements physiques qui composent le SI ou qui sont utilisés par le SI.

Les équipements de la vue Infrastructure sont organisés en 4 grandes familles :

les équipements liés à l’hébergement dans les salles informatiques (l’énergie, la climatisation, le câblage, etc.),
les équipements de télécommunication (LAN, WAN, réseaux voix, etc.),
les équipements de type serveurs d’exécution et de stockage,
les équipements et outils liés à la virtualisation.

Ne pas avoir le temps de méditer, c'est n'avoir pas le temps de regarder son chemin, tout occupé à sa marche.

Antonin Sertillanges

Voir aussi :