Processus métier : vous êtes dans le privé ou dans le public ?
Les frontières classiques de l'entreprise s'estompent pour donner lieu à la collaboration en réseau de partenaires. Les processus de l'entreprise s'étendent au-delà de ses frontières traditionnelles, et doivent intégrer les processus des partenaires dans la chaîne de valeur.
Cette collaboration amène chaque partenaire de la chaîne à publier certains de ses processus ou certains de ses processus, pour permettre aux autres partenaires de les intégrer dans leurs propres processus.
Ces processus publics représentent une interface pour les partenaires, indépendante des processus privés qui les implémentent.
Les processus privés peuvent être modifiés sans pour autant changer leur interface publique, limitant ainsi l'impact de changements intenses sur les partenaires. A l'inverse, les processus publics peuvent être adaptés à de nouveaux réseaux de partenaires, sans toucher les processus privés, c'est à dire sans réorganiser la chaîne de valeur de l'entreprise.
On utilise le terme de chorégraphie pour désigner l'enchaînement des opérations à réaliser dans une collaboration inter-entreprise et l'orchestration pour désigner l'enchaînement des activités d'un processus privé interne propre à une entreprise.
"Rien n'est plus dangereux qu'une idée quand on n'en a qu'une."
Alain
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/
Urbanisme SI : les objectifs en moins de 20 lignes !
L’objectif majeur de l’urbanisme SI est de permettre au Système d’Information d’évoluer de manière fractale et itérative, sans effet de BIG BANG, en gérant l'intégration d'applications vieillissantes et hétérogènes.
Cela nécessite de définir des règles de conception des systèmes d’information qui soient pérennes pour de longues années et donc agnostiques sur le plan des technologies.
L’urbanisation SI présuppose que la cartographie applicative de l'existant ait été réalisée, mais il n’est cependant pas nécessaire d’avoir documenté l’architecture applicative en détail ; seule la nomenclature des applications et services est indispensable.
Un deuxième objectif de l’urbanisme SI est d’identifier les redondances fonctionnelles pour :
- Éviter d’en créer de nouvelles grâce à la réutilisation des ressources logicielles existantes lors du développement de nouvelles applications.
- Réduire les coûts de maintenance en effectuant une rénovation bloc par bloc, qui consiste à définir une nouvelle ressource qui se substitue aux anciennes et réponde aux divers cas d’utilisation.
- Consolider deux Systèmes d’Information comme dans le cas d’une fusion/acquisition.
- Préparer le déploiement d'une plate forme ESB (Enterprise Service Bus) à grande échelle.
"La pire erreur à faire est de constamment avoir peur de faire une erreur."
Elbert Hubbard
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 : en moins de 20 lignes !
L'urbanisation SI est une démarche qui asservit les évolutions du système d'information avec la stratégie de l'entreprise et les besoins métiers.
L'urbanisation SI est un processus efficient dans un contexte où le fonctionnement des entreprises s'est complexifié (nouvelles réglementations, agressivité accrue des concurrents, ...). C'est le moyen de faciliter les interactions avec les SI externes (clients, partenaires, ...).
L'urbanisme SI se fonde sur l'anticipation des évolutions de l'entreprise.
Le processus d'urbanisation SI correspond à l'ensemble des activités liées à l'urbanisme SI :
- poser le cadre et les règles d'évolution du SI
- porter la dynamique de transformation progressive du SI au fil des projets d'évolution
- développer un langage commun du SI entre les acteurs
- participer à la gouvernance du SI
- mesurer les résultats et les communiquer
L'urbanisation SI est donc un processus permanent qui s'adapte aux entreprises qui se l'approprient et évolue en fonction de la maturité gagnée.
"Le seul fait d'exister est un véritable bonheur."
Blaise Cendrars
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 : est ce qu'on a vraiment besoin de modéliser le SI ?
L'urbanisation SI permet d'avoir une réflexion plus globale et plus approfondie de l’organisation des composants logiciels nécessitée par des besoins toujours plus importants de communication entre applications.
Par une représentation schématique et structurée, détaillée ou synthétique, la modélisation aide à concevoir et décrire l’architecture des systèmes d’information, et facilite ainsi la maîtrise des évolutions ultérieures.
Il existe de multiples raisons de modéliser un Système d’Information : l’urbaniste peut s’intéresser à la description de l’existant, en focalisant son analyse sur l’architecture logicielle et son intégration dans l’organisation. L'architecte lui se focalisera sur l’infrastructure technique et matérielle du système d’information ; il peut également étudier les évolutions nécessaires d’un système d’information, qu’il s’agisse d’intégrer une nouvelle application, un nouveau site Internet, ou un progiciel tel que SAP, ou d’optimiser une architecture client/serveur, en recherchant la meilleure répartition des données et des traitements.
La cellule urbanisme peut également être amené à représenter de manière précise les interactions entre les applications de l’entreprise et celles de ses partenaires, ou entre des entités autonomes à l’intérieur d’une même entreprise comme lors de la mise en place d’un moteur de workflow.
Par rapport à de simples représentations graphiques ou documents de présentation, la modélisation permet la constitution progressive d’une base d’information complète et parfaitement cohérente, facile à maintenir.
"Il n'y a qu'une chose qui puisse rendre un rêve impossible : c'est la peur d'échouer."
Paulo Coelho
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/
Unified Process Analyse et Conception : voici ce que doit faire la MOE
Définir une architecture candidate
- Analyse de l'architecture
- Analyse des Use Cases
- Créer un prototype sur un ou plusieurs Use Cases les plus représentatifs permettant de valider l'architecture.
- Artefacts produits ou modifiés :
- Document d'architecture logiciel
- Modèle de conception
- Réalisation des Use Case
Mise en place d'une architecture pour prouver que ça marche
- Analyse de l'architecture
- Créer un prototype sur un ou plusieurs Use Cases les plus représentatifs permettant d'apporter la preuve que l'on a au moins une solution d'architecture qui fonctionne
- Artefacts produits ou modifiés :
- Modèle de conception
- Document d'architecture logiciel
- Réalisation des Use Case
- Liste des risques
- Vision
Analyser le comportement
- Analyse des Use Cases
- Identifier les éléments de conception
- Valider la conception (revue)
- Artefacts produits ou modifiés :
- Modèle de conception
- Réalisation des Use Case
Concevoir les composants
- Concevoir les Use Case
- Classes de conception
- Concevoir les packages et les classes de tests
- Concevoir les sous-système
- Concevoir l'encapsulation, étudier le couplage
- Valider la conception (revue)
- Implémenter les composants
- Artefacts produits ou modifiés :
- Conception des packages
- Classes de tests
- Tests des spécification d'interface
- Compte-rendu de revue
- Demandes de changements
- Encapsulation et étude du couplage
- Mise au point des protocoles
- Classes de conception
- IHM
- Conception des sous-systèmes
Affiner l'architecture
- Donner des priorités aux Use Cases
- Décrire l'architecture d'exécution (Run-Time)
- Décrire l'architecture distribuée
- Identifier des Design Pattern
- Intégrer des Design Pattern
- Incorporer des composants existants
- Valider l'architecture (revue)
- Structurer le modèle d'implémentation
-
Artefacts produits ou modifiés :
- Liste des risques
- Guidelines de conception
- Spécifications supplémentaires
- Document d'architecture logiciel
- Les demandes de changements
- Compte-rendu de revue
Concevoir la base de données (optionnel)
- Classes de conception
- Framework de Maping Objet Relationnel
- Conception de la base de données
- Valider la conception (revue)
- Implémenter les composants
- Artefacts produits ou modifiés :
- Classes de conception
- Modéle de données
- Composants
"L'écriture est la peinture de la voix."
Voltaire
Modélisation des besoins : qu'est ce je dois faire et ne pas faire ?
L'urbanisation SI est une démarche fractale. Les techniques utilisées s'applique au SI, puis aux projets,..., jusqu'au composants et objets des applications. La première méthode itérative de gestion de projet, UP (prononcer youpie) pour Unified Process propose 9 disciplines qui s'apparentent aux 5 vues de l'urbanisme SI. La discipline Business Modeling ou Modélisation Métier s'intéresse aux processus metiers et permet de modéliser les acteurs et les activités à automatiser. Soit on utilise les diagrammes d'activité UML brut de fonderie ou mieux des profils UML comme Eriksson Penker ou bien encore le langage spécialement conçu pour les experts métier BPMN. C'est le point d'entrée de la discipline suivante Requirement ou Exptession des besoins. Les activités à automatiser deviennent les uses case qui représentent les comportements attendus de la future application. Les données métier sont représentées avec un diagramme de classe ou chaque classe comporte juste des attributs et les relations. Les scénarios sont modéliser avec des diagrammes de séquence. Le système est considéré comme une boite noire. Les états et les transitions doivent être modélisés avec un diagramme d'état. Ca c'est-ce que doit modéliser la MOAD (Maîtrise d'Ouvrage Déléguée).
Maintenant voyons un peu ce qu'on ne doit pas faire. La MOAD ne doit pas faire des modèles complexes, détaillés, utilisant des techniques de modélisation trop sophistiquées, faire des modèles surchargés illisibles et anticiper sur les solutions techniques et l'optimisation. La MOE ne doit pas quand elle se contenter de réécrire le cahier des charges. UP prévoit une discipline Analyse et Conception pour que la MOE affine les modèles de l'expression des besoins avec les concepts objets, services, composants, intègre le projet dans le POS du cadre d'urbanisme SI. La aussi, on doit être agnostique sur le plan technologie.
Quand à la direction générale elle ne doit pas laisser faire sans s'impliquer et dire dans le cas ou le projet échouerait c'est la faute à la DSI ce qui relèverait de la part de la DG d'une totale incompétence.
"Il est des entreprises pour lesquelles la vraie méthode est un désordre intentionnel."
Herman Melville
Processus métier : UML vs BPMN, devinez qui va gagner ?
Les processus métier peuvent se modéliser en UML et/ou BPMN qui sont 2 normes de l'OMG.
UML (Unified Modeling Language) est le langage le plus ancien. Ce n'est pas une méthode, mais simplement une boite à outil, un espéranto permettant de modéliser un systéme et de faire communiquer tous les acteurs d'une entreprise. Les 13 diagrammes de la version 2.x permettent de modéliser un systèmes sous différentes vues (représentation privilégiant certains aspects au détriment d'autres).
La norme a été conçue de manière à être évolutive avec parcimonie. En effet, on ne peut pas changer la sémantique des artefacts de modélisation. Mais on peut créer des stéréotypes qui sont des vues ou des types plus spécifiques des éléments de modélisation UML. Par exemple, il n'y pas d'élément spécifique en UML pour représeter un processus métier. Mais on peut stéréotyper une activité composite (sub activity) d'un diagramme d'activité). Il suffit de créer un nouveau stéréotype en lui donnant un nom ("Processus"), une définition, sur quel élément de modélisation UML il s'applique et enfin un dessin le représentant. Des tagged value permettent aussi de créer des paramétres "clé/valeur". On peut aussi définir des règles de modélisation en utilisant le langage de contrainte formel OCL (UML 2.x est spécifié en OCL). L'ensemble des stéréotypes, clés/valeurs et règles OCL peuvent faire partie d'un même ensemble homogène appelé "profil".
Heureusement l'utilisateur n'a pas à créer tout cela, il pourra trouver son bonheur dans les nombreux profils existants dans tous les domaines et étendant UML de base. Certains sont normalisés comme SysML, JEE, ... d'autres sont fournis comme outils supplémentaires dans certains AGL (ils sont alors spécifiques à un éditeur) et d'autres sont des standards sans être des normes comme le profil Eriksson Penker spécialement conçu pour les processus métier.
Le profil UML Eriksson Penker se compose :
- d'un stéréotype (flèche) représentant une agrégation d'activités
- un stéréotype but du processus (<<goal>>), la raison pour laquelle l'organisation fait ce travail. Il doit doit être exprimé en termes de bénéfices apportés à l'organisation, c'est la justification pour exécuter le processus.
- un acteur métier (client, marché, ...)
- des entrées non modifiables (<<supply>>) et d'autres qui le sont pendant le processus (<<input>>)
- un stéréotype évènement, réception d'un objet, l'arrivée d'une date (événement temporel, expiration d'une durée, ...), une notification ou le déclenchement d'une action (trigger). On peut représenter l'envoi et la réception. L'évènement peut être utilisé et transformé ou juste être un simple catalyseur.
- un stéréotype sorties (<<output>>) qui sont les produits du processus métier
- des objet physiques
Processus métier : si vous avez manquer le début
Un processus métier est un ensemble d'activités ordonnées dans le temps, conçues pour produire un résultat (en sortie) pour un acteur métier (client, marché, ...) dans un but donné. Il possède un début, une fin, des entrées et des sorties.
La modélisation des processus métier fait partie du processus de la démarche d'urbanisation SI : "Accompagner les métiers sur la maîtrise de leurs transformations" (faire une recherche sur ce processus dans ce blog).
Les 2 normes (toutes 2 de l'OMG) pour modéliser les processus sont :
- les diagrammes d'activité UML avec le profil spécialement conçu pour les processus métier : Eriksson-Penker
- BPMN : nouveau langage de modélisation moins abstrait, moins technique qu'UML, a été tout particulièrement pensé pour les MOA
Nous verrons dans le prochain épisode, des éléments de comparaison entre ces langages de modélisation des processus métier.
"Il y a un but, mais pas de chemin ; ce que nous nommons chemin est hésitation."
Franz Kafka
La modélisation métier permet de faciliter la compréhension des processus métiers afin d'être capable de les faire évoluer et de spécifier les besoins.
Modélisation métier : quelques conseils pour réaliser un glossaire dont plus personne ne pourra se passer.
- Construire le dictionnaire dès l’analyse du cahier des charges (et des autres sources de documentation)
- Se limiter à l’étude et à la terminologie métier
- Les modèles et leur description utilisent en priorité les termes du dictionnaire
- Le dictionnaire doit « vivre » tout au long du projet
- Les descriptions textuelles associées aux modèles et particulièrement celles des cas d’utilisation (libellé et description) doivent faire référence aux termes décrits dans le dictionnaire
- Le dictionnaire est un document de référence, qui fait foi au cours du projet
- On peut mener conjointement la constitution du dictionnaire avec l’élaboration des modèles : processus, use-case, … qui contribueront à l’alimentation du dictionnaire
- Sans négliger cette activité, il n’est pas non plus nécessaire d’y consacrer une charge trop importante.