Urbanisation du Système d'Information : Ne vous perdez pas dans les typologies de référentiel !
Car vous n'obtiendez jamais un consensus sur ce genre de chose. Personne n'est d'accord et tout le monde a de bons arguments pour discuter telle ou telle classe de référentiel : "Pourquoi les contrats sont dans le référentiel de données élémentaires et pas dans le référentiel des données sensibles ?".
Faut-il créer un référentiel avec des données de type nomenclature (tables de référence), un référentiel basé sur le cycle de vie et la fréquence de mise à jour, un référentiel des données confidentielles et un référentiel des données élémentaires (clients, fournisseurs, produits, ...) ?
Mieux vaut se consacrer sur le coeur du sujet c'est à dire :
- la description de la structure des entités métiers. Pour cela on utilise une modélisation UML avec un diagramme de classe qui permet de préciser les objets, leurs attributs et les relations entre les objets.
- la solution retenue pour l'architecture technique d'implémentation du référentiel (base SQL, base objet, XML, les canaux d'accès, la sécurité, ...)
- les données métiers, avec l'analyse de la valeur des données, leur origine, le processus d'acquisition et de mise à jour, l'évaluation de la fiabilité, le propriétaire de la donnée et n'oublions pas le coût d'acquisition et de maintenance.
- les interfaces avec les applications futures ou existantes nécessitant la mise en place d'un langage pivot commun et les adapteurs entre ce langage et le format des applications.
"La science est avant tout une classification, une façon de rapprocher des faits que les apparences séparaient bien qu'ils fussent liés par quelque parenté naturelle et cachée. La science en d'autres termes, est un système de relations."
Henri Poincaré
La valeur de la science
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/
Expression des besoins : Concevez des modèles de spécifications avant que ce ne soit trop tard !
L'urbanisme du Système d'Information offre un cadre de développement lui permettant d'être agile, flexible, évolutif et facilement maintenable.
La mise en place de modèles de spécification permet d'avoir une uniformisation et une homogénéité de l'ensemble des projets à venir.
L'avantage se situe au niveau réutilisabilité et permet d'éviter les pièges.
Dans un projet d'envergure, par exemple, aucun modèle de spécification batch n'existait et ce malgré les recommandations des consultants. Alors chacun a réalisé ses SFD à sa sauce. Certain ont spécifié très en détails avec leur expérience d'ancien coboliste. Ansi dans les spécifications fonctionnelles, on retrouvait la création de fichiers temporaires qui devaient être fusionnés suivant des règles complexes.
Malheureusement l'architecture cible choisie pour les traitements de masse était Spring Batch. Avec ce choix, il est plus facile d'utiliser des tables temporaires plutôt que des fichiers. Résultat des semaines de spécifications à refaire et en plus cela à aggraver les relations entre le client ( MOA ) et son fournisseur ( MOE ).
Un projet comporte bien trop d'aléas pour qu'on n'en ajoute pas d'avantages. Bien au contraire, il faut consacrer toute son énergie pour tout ce qui va faire économiser des charges comme les outils et les méthodes même si cela paraît contraignant car après il sera trop tard.
"La liberté consiste moins à faire sa volonté qu'à ne pas être soumis à celle d'autrui."
Jean-Jacques Rousseau
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 SI : la méthode ultime pour modéliser les besoins d'un projet - Dernière partie - Traçabilité – UML – Relation de dépendance
La modélisation du Système d'information ( SI ) avec un AGL ( Atelier de Génie Logiciel ) permet de mettre en place la traçabilité des entités appartenant au système.
L'urbanisation du SI s'attache à partir de la vue stratégique à dire que la vue métier doit être une implémentation des objectifs stratégiques. Chaque processus métier doit réaliser un ou plusieurs objectifs stratégiques.
De même dans le POS ( Plan d'Occupation des Sols ou vue fonctionnelle ), chaque bloc fonctionnel doit implémenter un ou plusieurs processus ou activité métier.
Et ainsi de suite pour la vue applicative ou chaque bloc applicatif réalisent un ou plusieurs blocs fonctionnels et pour la vue infrastructure ou les blocs exécutent un ou plusieurs blocs applicatifs ( applications, ... ).
Toutes ces vues peuvent se modélisées en UML ( Unified Modeling Language ) qui est très générique et qui permet de modéliser tout ce qu'on désire.
Les relations de dépendances UML permettent de mettre des liens entre tous les éléments de modélisation quel qu’ils soient.
Et on peu continuer ainsi jusqu'au projet d'une nouvelle application prévu par le POS par un bloc applicatif. Les besoins ou exigences correspondent aux entrées/sorties modélisées dans les activités des processus métier à automatiser ( stéréotypés <<automatisé>> ).
Une relation de dépendance va du ou des use case vers l'activité métier du diagramme d'activité qu'il(s) implémente(nt).
Une relation de dépendance va d'une exigence ( classe UML stéréotypée <<requirement>> ) vers un ou plusieurs use case.
Les messages systèmes des diagrammes de séquence des scénarios dépendent des use case.
Et ainsi de suite, la discipline "Analyse et Conception" dépend de la discipline "Expression des besoins (exigences)" qui dépend de la discipline "Implémentation", ...
Un surcoût indéniable est à prévoir pour mettre en place les liens de dépendance entre tous les artefacts de modélisation en partant du niveau le plus haut ( urbanisme du SI ) jusqu'aux modèles de codes ( diagrammes de classe, d'état et de séquence d'implémentation ) pour la génération de codes.
Le ROI sera au rendez-vous dès que l'on aura des modifications ou des évolutions. L'AGL permet alos de mesurer tous les impacts et de les chiffrer.
La génération automatiques de ces métriques apportent une aide primordiale à la prise décision pour savoir si on intègre un changement ou si on le diffère voir carrément refuser de le faire parce que les impacts sont trop importants et que cela engendrerait trop de risques et un surcoût inconsidéré.
"Il vaut mieux subir l'injustice que la commettre."
Socrate
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 SI : la méthode ultime pour modéliser les besoins d'un projet - 16ème partie - Scénarios Cas d’Utilisation – UML – Diag. Séquence
Une fois les use case identifiés, le diagramme réalisé et les scénarios rédigés, il est facile de les modéliser avec un diagramme de séquence UML.
La méthode est de faire un diagramme par use case s'ils sont simples ou s'ils comportent peu de scénarios ou bien un diagramme par scénario.
Le mode de pensée de ce modèle est de voir le système comme une boite noire, chaque action de l'utilisateur décrite dans la fiche de use case devient un message envoyé au système avec éventuellement sa réponse.
Il ne faut surtout pas chercher pas à modéliser le fonctionnement interne du système.
La vue en boite blanche, c'est à dire la conception de la solution à la requête de l'utilisateur sera réalisée à la discipline suivante "Analyse et Conception". Pour chaque message reçu, on déterminera alors la séquence de messages à envoyer aux contrôleurs et aux entités.
Cette modélisation fera l'objet d'un prochain article.
Ces diagrammes systèmes permettent de mettre l'accent sur les messages systèmes. L'objectif est de formaliser les comportements attendus du système considéré comme une boite noire.
La traçabilité des messages reçus par le système et auxquels il devra répondre sera assurée par les diagrammes de séquence de conception avec comme point d'entrée chacun des messages, le système étant remplacé par un contrôleur.
Attention au piège d'utiliser trop de raffinements UML des diagrammes de séquence réservés à la conception, au développement et à la génération de code. Ces modèles doivent rester lisibles par la MOA/MOAD.
"Plus contagieuse que la peste, la peur se communique en un clin d'œil."
Nicolas Gogol
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 SI : la méthode ultime pour modéliser les besoins d'un projet - 15ème partie - Regroupement par Domaines – UML – Diag. Package
Les use case sont des cas fonctionnels, qui doivent être regroupés par appartenance au même domaine fonctionnel correspondant en urbanisation du Système d'Information ( SI ) à un quartier du Plan d'Occupation des Sols (cartographie fonctionnelle).
En UML, l'élément de modélisation permettant de regrouper des entités est le package ( symbole de dossier ). On peut avoir plusieurs niveaux d'imbrication mais les règles d'urbanisme du SI font qu'on se limite à 3 ou 4 niveaux maximum sinon cela devient ingérable et surtout incompréhensible pour le commun des mortels.
Les package de cas d'utilisation permettent de structurer le comportement fonctionnel d'un système pendant la modélisation des exigences. On les nomme de manière compréhensible par les experts métier.
Les packages offrent donc la possibilité de travailler à différentes échelles suivant le profil du lecteur et le niveau de détails souhaité.
De la même manière les acteurs peuvent être rassemblé dans des packages.
Les dépendances fonctionnelles sont matérialisées par les relations de dépendance UML.
UML propose d'autres raffinements comme les dépendances <<use>> ou <<merge>> réservées aux packages de classes de conception et de compilation donc à ne surtout pas utiliser ici.
Afin d'avoir une architecture fonctionnelle évolutive et réutilisable, on devrait éviter autant que faire se peut, les dépendances bidectionnelles et cycliques ( A dépend de B qui dépend de C qui dépend de A ) qui conduit à terme à un système en mauvaise santé pour ne pas dire à un véritable plat de nouilles.
"La vie serait impossible si l'on se souvenait, le tout est de choisir ce que l'on doit oublier."
Roger Martin du Gard
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 SI : la méthode ultime pour modéliser les besoins d'un projet - 14ème partie - Cas d’Utilisation – UML – Diag. Use Case
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".
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.
"La bonne musique ne se trompe pas, et va droit au fond de l'âme chercher le chagrin qui nous dévore."
Stendhal
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 SI : la méthode ultime pour modéliser les besoins d'un projet - 13ème partie - Contexte Dynamique/Diag. Flux
En urbanisation des Systèmes d'Information ( SI ), les flux entre les différentes applications sont modélisés en UML par un diagramme de communication ( le fameux diagramme de flux cher aux Merisiens n'existe pas en UML ! ). De la même manière, on représente les flux entrants et sortants d'une application par ce type de diagramme UML.
La future application est considérée comme une boite noire. Les acteurs externes au système sont des objets qui envoient ou reçoivent des messages.
L'objectif n'est pas d'ordonner les messages, ce serait rentrer dans un degré de granularité beaucoup trop fin pour cette étape de la modélisation des besoins, mais à partir des acteurs, il s'agit d'identifier quelles demandes ils peuvent faire et ce qu'ils attendent du système en retour.
Ce modèle permet aussi de recenser ou de compléter les exigences identifiées soit à la modélisation métier, soit par les techniques standards d'analyse de documents, interviews, groupe de travail, ..., et prépare l'étape suivante qui consiste à rechercher et à décrire les cas d'utilisation ( use Case ) UML.
"La vie est ton navire et non pas ta demeure."
Alphonse de Lamartine
Voir aussi :
http://www.urbanisation-si.com/
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 SI : la méthode ultime pour modéliser les besoins d'un projet - 12ème partie - Contexte Statique – UML – Diag. Classe
Lors de l'urbanisation du Système d'Information ( SI ), la modélisation des processus métiers avec les partitions du diagramme d'activité UML ou les lane en BPMN a permis d'identifier les acteurs de la future application automatisant ces processus.
Un acteur est un rôle que prend une entité externe ( humaine ou système externe ) dans l'utilisation de l'application cible. Par exemple Mme Michu chef d'une équipe de gestionnaires, peut avoir le rôle de "paramétreur expert" pour l'application de gestion des prestations dans le domaine de l'assurance prévoyance et "simple paramétreur" pour celle du domaine de la complémentaire santé.
A ce stade de la modélisation du système, il est intéressant de représenter le contexte statique, c'est à dire le système considéré comme une boite noire et les acteurs pouvant utiliser le système. Le diagramme de classe UML permet alors de représenter le système en relation ( association ) avec les acteurs et leur cardinalité éventuellement le nombre maximum pouvant accéder simultanément au système.
"L'ordre est le plaisir de la raison, mais le désordre est le délice de l'imagination."
Paul Claudel
Voir aussi :
http://www.urbanisation-si.com/
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 SI : la méthode ultime pour modéliser les besoins d'un projet - 11ème partie - Exigences – UML – Profil spécifique
Si dans une démarche d'urbanisation du Système d'Information ( SI ), on a cartographié la vue métier, les changements dans les processus métiers qu'ils s'agissent de modifications de nouveautés, vont conduire dans le schéma directeur à des nouveaux projets dont les exigences en seront directement issues.
Les AGL ( Atelier de Génie Logiciel ), utilisent des stéréotypes UML, c'est à dire une spécialisation de certains artefacts de modélisation. Pour les exigences, une classe UML est stéréotypée "Requirement" ( Exigence ) avec comme symbole de représentation un rectangle avec une double barre verticale dans le premier tiers gauche du rectangle.
Le modélisateur utilise alors les relations du diagramme de classe comme les associations, agrégations, compositions et héritages.
L'intérêt de l'AGL, c'est d'avoir un référentiel de tous les éléments de modélisation y compris les exigences. Un ensemble d'informations comme le titre, la description, le type ( fonctionnelle ou non fonctionnelle ), l'auteur, la date mais aussi des informations concernant la conduite de projet comme la priorité, le niveau de difficulté, la phase, les documentation liés, les règles, les contraintes, ... Toutes ces informations serviront par exemple à la planification, à la génération automatique de la documentation, ...
Outre de pouvoir gérer un référentiel d'exigences, l'AGL permet, comme les exigences sont d'un point de vue UML des classes, de créer des liens de dépendances vers d'autres éléments de modélisation comme les activités du diagramme d'activité UML, celles des processus métier modélisés en BPMN.
Les cas d'utilisation ( Use Case ) modélisent les comportements attendus des futurs utilisateurs et auront des liens de dépendance ( on peut utiliser la relation UML d'implémentation ) vers les exigences.
On vérifiera ainsi que toutes les exigences sont implémentées par au moins un cas d'utilisation. S'il reste des exigences non implémentées, c'est soit que tous les use case n'ont pas encore été identifiés, soit qu'elles appartiennent à des fonctionnalités hors du périmètre projet.
"Une vie qui n'est pas réfléchie ne vaut pas d'être vécue."
Socrate
Voir aussi :
http://www.urbanisation-si.com/
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 SI : la méthode ultime pour modéliser les besoins d'un projet - 10ème partie - Liste des exigences – UML – Diag. Package
Après avoir voyagé au pays de la modélisation métier, nous voici arrivé aux étapes qui vont conduire à l'informatisation des activités métiers identifiées (ou stéréotypées UML) à automatiser.
La discipline "Exigence" (au sens UP Unified Process) ou "Expression des besoins" du futur système informatique nécessite de pratiquer un ensemble de techniques comme l'analyse documentaire, les interviews, les groupes de travail, ... Le résultat constitue la base d'analyse pour recenser et structurer les exigences.
Du reste dans de nombreux projets, on commence directement par l'expression de besoins sachant que la discipline précédente de modélisation métier n'est pas réalisée.
Toutes les entreprises ne décident pas de mettre en place une démarche d'urbanisation du Système d'Information. Le chef de projet risque de se retrouver démuni sans méthode éprouvée, sans les cartographies métiers, fonctionnelles, applicatives et d'infrastructures. Ces études permettent , ne l'oublions pas, de simplifier les études préalables et fournissent le contexte au projet et bout du compte engendre des économies substantielles.
Utiliser un AGL pour modéliser les exigences offrent les avantages suivants :
- la gestion d'un référentiel centralisé d'exigences qui est sous contrôle (droits, mesures d'impacts en cas d'évolution, ...)
- l'utilisation de profils UML inclus dans l'AGL et spécifiques pour les exigences. On n'a pas à créer ses propres stéréotypes par exemple.
- la mise en place d'un AGL pour l'ensemble du projet, voir pour l'ensemble de l'urbanisation du Système d'Information de l'entreprise permet de centraliser l'ensemble des modèles et d'assurer la traçabilité entre les artefacts de modélisation, ce qui permet de mesurer immédiatement via l'outil les impacts d'un changement dans les exigences.
Mes retours d'expérience dans divers projets aussi bien dans le domaine public que privé, m'ont montré qu'il était important d'outiller et de mettre en place la bonne méthode adaptée à l'organisation et cela sans attendre les avancées des projets même si ça peu paraître coûteux au départ. Les processus métier peuvent vite évoluer et c'est le prix à payer si on veut être efficient dans l'agilité et la flexibilité.
"Ceux qui rêvent éveillés ont conscience de mille choses qui échappent à ceux qui ne rêvent qu'endormis."
Edgar Allan Poe
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/