Document réalisé par EDIFRANCE dans le cadre du programme Boost Industries et Services (coordination des projets TIC et PME 2010)

Transcription

1 ebxml pour la maîtrise d ouvrage Pourquoi et comment conduire un projet d Echanges Electroniques Professionnels (EEP) selon la méthodologie UN/CEFACT? Document réalisé par EDIFRANCE dans le cadre du programme Boost Industries et Services (coordination des projets TIC et PME 2010) Document d initiation à la conduite des Projets d Echanges Electroniques Professionnels et au développement de formats d'échange standardisés A l usage de la maîtrise d'ouvrage et des chefs de projet Page : 1

2 PREFACE EDIFRANCE tient un rôle privilégié auprès des organes internationaux de standardisation notamment par une participation active à de nombreux groupes de travail de l UN/CEFACT et du CEN sur des sujets très importants pour les échanges électroniques en France. L intégration des processus d une filière et entre les filières impose de coordonner les démarches sur le plan des standards, et de travailler à l interopérabilité des solutions numériques proposées. ebxml, constitue une réelle avancée en termes de dynamique d échanges et d ouverture fonctionnelle et un véritable défi technique en ce qui concerne la définition des objets, leur modélisation mais aussi leur mise à disposition. EDIFRANCE, en tant qu acteur de ce défi souhaite par cette publication sur «ebxml» communiquer son savoir-faire au service des «maîtrises d ouvrages» de filières et d entreprises afin de leur apporter des réponses aux questions : Pourquoi et comment conduire un projet d Echanges Electroniques Professionnels (EEP) selon la méthodologie UN/CEFACT. Ce document a été réalisé dans le cadre du programme TIC&PME 2010, sous l'autorité de l'instance de coordination qui est chargée d'assurer le suivi et la cohérence des travaux. Le programme TIC&PME 2010 est une opération financée par le ministère de l'économie, des finances et de l'emploi et dont le pilotage est confié à la direction générale des entreprises, le conseil général des technologies de l'information et le conseil général des mines. L'instance de coordination est soutenue techniquement par des experts de l'afnet, d'edi France et de GS1 France. Le site du soutien technique est le suivant : Jean-Marc DUFOUR Président EDIFRANCE Directeur de projet EDIFRANCE Boost Industrie et Services Je remercie les personnes qui ont contribué à l élaboration de ce document et son évolution : Gilles BRANDEL Michel ENTAT Bernard LONGHI Bruno PREPIN Dominique RICHARD SRCI AXEMIO EDIFRANCE EDIFRANCE NYC Le présent document est la propriété d EDIFRANCE avec le statut de document de préparation à la standardisation ouvert et respectant les caractéristiques suivantes : chaque nouvelle version est publiée dès la validation ; les coûts d'accès, de réutilisation, de copie, de distribution seront nuls ou faibles; les mises à jour sont ouvertes à toutes contributions validées dans le cadre d'un processus de décision ouvert à l'ensemble des acteurs ; ce document ne donne pas lieu à rémunération par une quelconque personne ou organisme. Suivi des modifications : Date Objet Version N 19/06/2007 Méthodologie_Développement_EEP_R1.1.3.doc R /06/2007 Méthodologie_Développement_EEP_R1.1.2.doc R /06/2007 Méthodologie_Développement_EEP_R1.1.0.doc R1.1.1 Page : 2

3 Table des Matières : 1. PREAMBULE SYNTHESE POUR DECIDEURS POURQUOI UNE METHODE BASEE SUR DES STANDARDS INTERNATIONAUX?6 4. PRINCIPES DES EEP, MODELISATION ET DEFINITIONS PRINCIPE MODELISATION DEFINITIONS ETAPES D'UN PROJET EEP COORDINATION ET HARMONISATION PROCESSUS METIERS LIVRABLES DE LA SPECIFICATION DES PROCESSUS METIER DESCRIPTION DU CONTEXTE METIER SPECIFICATION DES PROCESSUS METIER SPECIFICATION DES COLLABORATIONS METIER DOCUMENTS, INFORMATIONS METIERS ET COMPOSANTS LIVRABLES DE LA SPECIFICATION DES INFORMATIONS ET DES COMPOSANTS METIER SPECIFICATION DES INFORMATIONS METIER LES REGLES DE LA CCTS DE L UN/CEFACT LES DIFFERENTS TYPES DE COMPOSANT LE TYPAGE DES COMPOSANTS SPECIFICATION DES COMPOSANTS METIER (ABIES, BBIES, ASBIES) SOUMISSION DES COMPOSANTS METIER SCHEMAS IMPLEMENTATION PRE-REQUIS A L'IMPLEMENTATION TESTS ET RECETTE MAINTENANCE OUTILS PUBLICATION GLOSSAIRE...38 Page : 3

4 1. Préambule L Etat, dans le cadre de l Appel à Projets TIC PME 2010, met en œuvre un dispositif de soutien et d accompagnement à l intention des acteurs publics et privés de l économie numérique, en vue de : soutenir la création d une «chaîne numérique» dans les entreprises d une même filière, favoriser la normalisation et la standardisation des formats d échanges, soutenir des actions d assistance à maîtrise d ouvrage destinées à intégrer les TIC dans les processus internes des entreprises et dans les relations avec leurs clients et fournisseurs. Le projet BOOST Industries et Services vise à accompagner la mise en œuvre de services d Echanges Electroniques Professionnels basés sur standards de l UN/CEFACT dans des filières sélectionnées. Secteurs faisant partie d un même écosystème, i.e. ayant les mêmes fournisseurs Secteurs d activité (clients, donneurs d ordre, équipementiers, PME) M é t i e r s Mécanique Electronique Plasturgie Textile industriel Aéronautique Défense Ferroviaire/naval Automobile IT et Telco Bâtiment Pétrole chimie Nucléaire Services Logistique/transport Filières de TIC PME 2010 L association EDIFRANCE, depuis 1990, est l un des principaux acteurs nationaux des standards d échanges électroniques de l UN/CEFACT. Plusieurs dizaines de milliers d entreprises utilisent en France des solutions basées sur le standard EDIFACT. En relation avec les progrès des techniques des TIC, l UN/CEFACT, dans le cadre de l initiative ebxml, a produit une méthodologie et un jeu de standards permettant la création d un environnement d échanges ouvert au niveau mondial. Les acteurs de l économie numérique qui décident d utiliser cet environnement dans le développement de leurs projets EEP en retireront un gain significatif au niveau de leur productivité et de leur réactivité. Ce document présente aux chefs des projets EEP, en particulier les projets des filières BOOST Industries et Services, une démarche de conduite des projets EEP standardisés basée sur les méthodes et standards de l UN/CEFACT. Afin d'en faciliter la compréhension, les considérations théoriques sont étayées par des exemples. Ces exemples s'appuient sur la dématérialisation de la facture, la commande et les appels d'offres. Sa lecture prépare les chefs de projets à l utilisation des standards EEP. Il est intégré à un ensemble de services proposés dans le cadre de Boost Industries et Services (AFNET, EDIFRANCE, GS1) pour les accompagner dans le développement de leurs projets filières: formations, missions de conseil, site web, mise à disposition de modèles et documents de référence, accompagnement à la standardisation de leurs processus par l UN/CEFACT. Plus d information Page : 4

5 2. Synthèse pour décideurs Les résultats des entreprises - les grandes entreprises comme les PME - sont très dépendants de leur stratégie de développement et de leurs Systèmes d Information. Celle-ci contribue pour une grande part à l'augmentation de leur productivité et à l amélioration de leurs positions commerciales sur un marché de plus en plus global et concurrentiel. En matière d échanges électroniques professionnels entre l entreprise et ses partenaires, les enjeux sont de la même ampleur que pour les processus internes mais les projets nécessitent des conventions avec ces partenaires quant aux modalités de la communication. Il est essentiel pour l entreprise que les investissements faits soient pérennes, d une charge supportable et maîtrisée et que leurs effets soient positifs sur l ensemble de ses processus. Cela implique que les standards initialisés, par exemple, avec certains clients soient acceptables par les autres clients et constituent une bonne base pour l extension des relations électroniques avec les fournisseurs, les partenaires financiers, etc afin de mettre en place une bonne exploitation des informations échangées dans les systèmes internes de l entreprise. Cette problématique est aujourd hui gérable avec efficacité, notamment depuis la mise en œuvre des standards EDIFACT. Au sein de l Organisation des Nations Unies, l UN/CEFACT est l instance de standardisation la plus reconnue pour les échanges électroniques professionnels. Après avoir créé et maintenu les normes et standards EDIFACT, les experts de l UN/CEFACT ont constitué un ensemble moderne de procédures, de méthodes et d outils permettant de conduire un projet de standard d échanges électronique efficace, pérenne et ouvert sur le plan intersectoriel. Le présent document décrit succinctement comment obtenir ces résultats. Les informations complémentaires nécessaires au fil de l application de la méthode sont accessibles d une part dans les documents plus techniques et d autre part au travers du support technique fourni par Boost Industries et Services aux projets TIC & PME Le succès nécessite que, sous l impulsion du chef de projet et avec le support des spécialistes, les partenaires s approprient les principes essentiels que sont : les étapes à respecter dans un projet d échanges électroniques professionnels, l expression des objectifs au travers d une analyse d opportunité et de faisabilité, la constitution de groupe(s) de travail associant compétences métier et support méthodologique, l expression des besoins et la recherche des standards ou éléments de standards existants, la conception des standards nouveaux nécessaires selon la méthodologie présentée, leur validation et leur publication en relation avec les instances correspondantes. L expression des besoins et la conception des standards s appuient sur la méthodologie UMM (Unified Modeling Methodology) de l UN/CEFACT. Elle conduit le projet vers un résultat harmonisé avec les éléments de standards des autres secteurs et autres pays. Le travail passe par : la spécification des processus d échanges, la spécification des informations échangées, l harmonisation et l utilisation des composants communs intersectoriels, la production des schémas XML pour l implémentation technique dans les systèmes informatiques, la production de documents nécessaires pour briguer une qualification de standard officiel, et enfin la production des éléments nécessaires pour accompagner l implémentation des standards dans les systèmes des entreprises et pour la maintenance de ces standards dans le temps. Dans le but de rendre les bénéfices de la démarche accessibles à tous les projets, EDIFRANCE propose, audelà du présent document, un ensemble de structures et d outils permettant de marcher sur la voie d un standard international reconnu sans investir prématurément dans une compétence méthodologique complète et la présence dans les instances internationales. Pour optimiser la pérennité, la rentabilité, la pertinence, la sécurité et l ouverture de votre projet d échanges, nous recommandons donc dans un premier temps la lecture de ce guide et ensuite la prise de contact avec le groupe HICC d EDIFRANCE, en charge de l accompagnement de la démarche. Page : 5

6 3. Pourquoi une méthode basée sur des standards internationaux? De nombreux arguments plaident pour qu un secteur d activité adopte une méthode de conduite de projets d Echanges Electroniques basée sur les standards de l UN/CEFACT. Les avantages les plus importants sont de sécuriser le projet et d optimiser la rentabilité de l investissement qu il mobilise. Optimiser le retour sur investissement Elaborer un standard d échanges nécessite un effort collectif important. Ne pas s appuyer sur les travaux internationaux serait courir le risque de devoir refaire le travail plus tard sous la pression d un standard international concurrent. Cela serait d autant plus grave que le projet n aurait pas bénéficié des travaux génériques faits au niveau international et intersectoriel. Les réfactions feraient apparaître que le projet aurait redécouvert des problèmes et construit des solutions dans des domaines déjà connus et en ignorant les voies déjà ouvertes et expérimentées. De plus la conception de standards en appliquant la méthodologie proposée apporte une ouverture intersectorielle. Or il n est pas d entreprise qui n ait à communiquer avec plusieurs secteurs et l utilisation de concepts communs décrits sous une forme homogène permet d ouvrir son système d information dans différentes directions sans réinventer ou réapprendre un nouveau langage à chaque fois. Dans la circulation d un document papier, la présentation de l information contribue à son interprétation. Sous forme électronique, seule la conformité à des standards internationaux donnera la force de conviction attendue. Sécuriser le projet Un projet de standard d échanges électronique requiert un niveau de consensus qui le rend très différent d un projet de système d information d entreprise. Adopter la méthode proposée permet de prendre en compte les dimensions Communication et Consensus, et d avoir une vision globale des étapes du projet. Bénéficiant de l expérience de tels projets au travers de la méthode, le chef de projet pourra minimiser les risques de dérive ou d échec et aura de bons arguments pour légitimer sa méthodologie. L UN/CEFACT : l instance de référence, reconnue, expérimentée et dynamique Installée au sein de l Organisation des Nations Unies, l UN/CEFACT est l instance de standardisation la plus reconnue au niveau international pour les échanges électroniques. Elle travaille depuis plus de 40 ans à développer, promouvoir et maintenir un environnement mondial de standardisation pour la facilitation des échanges administratifs et commerciaux. Plusieurs centaines d experts représentant les utilisateurs des différents secteurs de l économie, des administrations et les grands acteurs de l offre informatique sont les membres actifs des groupes de standardisation. Leurs travaux ont déjà produit les messages standards EDIFACT (UNSM), largement utilisés. Depuis 2001, dans le cadre de l initiative ebxml, la méthodologie appliquée par l UN/CEFACT intègre les progrès les plus récents des techniques et des méthodes orientées objet, formats XML, etc. Ces standards couvrent tous les aspects de la mise en œuvre des projets d échanges électroniques et de leur mise en œuvre dans les entreprises. Une démarche relayée au niveau européen (CEN) et au niveau national : EDIFRANCE Pour assurer le lien entre l UN/CEFACT et les contextes locaux, des instances relais assurent la prise en compte des besoins des utilisateurs français. Elles offrent aux entreprises un support pour faciliter leur appropriation des méthodes de la standardisation et le développement de leurs projets d échanges électroniques. EDIFRANCE a pour mission d accompagner les projets français dans leurs démarches de standardisation. EDIFRANCE existe depuis 1990 et regroupe aujourd hui plus de cent adhérents utilisateurs et offreurs de solutions d échanges électroniques issus de tous les secteurs d activité. Les groupes de travail d EDIFRANCE ont constitué des délégations qui, au sein du CEN (Comité Européen de Normalisation), œuvrent pour garantir l adéquation des standards internationaux aux besoins de l Europe. Une forte dynamique internationale d adoption des nouveaux standards La France ne peut ignorer que, parmi d autres, Etats-Unis, Canada, Hollande, Suède, Corée du Sud, Japon, Australie, ont adopté les standards ebxml pour asseoir le développement de leurs infrastructures de commerce électronique. Ne nous laissons pas distancer! Page : 6

7 4. Principes des EEP, modélisation et définitions 4.1. Principe Les Echanges Electroniques Professionnels (EEP) permettent à des professionnels appartenant à une même communauté et à leurs systèmes d information d échanger des documents administratifs et commerciaux et de traiter les informations qu ils contiennent. Informations Transmission électronique Documents métiers Transmission électronique Scénario d'échange Processus métiers Acteur / Rôle Principe des EEP Acteur / Rôle Les Echanges Electroniques Professionnels mettent en œuvre des acteurs qui, selon leur rôle, s'échangent des informations en suivant un scenario précis et au moyen de systèmes de messagerie. Dans le cadre de l exécution d une relation d affaires, par exemple la fourniture d un produit ou d un service par une entreprise fournisseur à une entreprise client, plusieurs échanges sont nécessaires. Le scénario de ces échanges s'organise en processus d échanges et les informations échangées en documents. Ces processus d échanges sont appelés " processus métier ". Ils répondent aux exigences et aux pratiques professionnelles des partenaires engagés dans l exécution de la relation d affaires et véhicules des " documents métiers ". Afin d'être partagés et compris par les différents acteurs, ces processus et ces documents doivent être formalisés. Dans le monde des EEP la formalisation s'exprime par des modèles qui peuvent être graphiques, textuels ou mixtes Modélisation Que signifie " modéliser "? Dans la vie courante, nous modélisons tous et tout le temps : à chacun des objets qui nous entourent, qu il s agisse d objets matériels, de personnes ou d institutions, nous associons une image mentale qui nous permet d anticiper son comportement. Modéliser un objet c est donc définir : les concepts qui permettent de le décrire ; les relations fonctionnelles qu entretiennent ces concepts. Page : 7

8 Le modèle de l'entreprise Dans le cas particulier d une entreprise, modéliser l entreprise revient à définir : les processus de production, en identifiant les événements déclencheurs et finaux de chaque processus ; le parcours de chaque processus, avec l enchaînement des activités humaines et des opérations informatiques qu il comporte ainsi que les objets qu il manipule ; le référentiel de l entreprise, à savoir les attributs qui sont associés à chaque objet, notamment leurs identifiants et les nomenclatures qui permettent de coder leurs attributs ; les " règles de gestion " dont la mise en œuvre propulse ces objets dans leur cycle de vie. La modélisation implique donc que l on se représente, définisse et documente les tâches effectuées dans l entreprise, tant par l être humain que par les systèmes d'information. A chaque tâche est associée la liste des dossiers que l'acteur doit utiliser (ex : " fiche client", "commande", "fiche produit", etc.). Pourquoi modéliser? Les entreprises qui doivent modéliser ce sont celles : qui sont placées dans un contexte évolutif (concurrence, innovation technique, réglementation) et doivent donc être souples et réactives ; qui partagent avec d autres entreprises la production d un produit (partenariats) et doivent assurer l interopérabilité de leurs processus. Il est en effet indispensable d avoir modélisé ses processus pour pouvoir les faire évoluer comme pour pouvoir les partager. Aujourd hui la plupart des entreprises se trouvent ou se trouveront bientôt dans l un ou l autre de ces deux cas, ou dans les deux, car l évolutivité et les partenariats sont une contrainte de l économie actuelle. Finalités de la modélisation Tout modèle a deux finalités, l une technique, l autre intellectuelle : finalité technique : fournir des spécifications claires pour produire, puis exploiter l application informatique qui opère chaque processus ; finalité intellectuelle : fournir au métier une vision claire de ses objets, de ses concepts, de son référentiel, de ses processus. Comment modéliser? Il existe un langage de modélisation qui permet de formaliser des concepts, c'est le langage UML ("Unified Modeling Language"). Qui modélise? La modélisation est souvent faite par la maîtrise d œuvre informatique (MOE). C est malencontreux, car les priorités de la MOE résident dans le fonctionnement de la plate-forme informatique et non dans les processus de l entreprise. Il est préférable que la modélisation soit réalisée par la maîtrise d ouvrage (MOA) de sorte que le métier soit maître de ses propres concepts. La MOE ne doit intervenir dans le modèle que lorsqu'après avoir défini les concepts du métier, on doit introduire les contraintes propres à la plate-forme informatique. Langage de modélisation Le langage UML permet de définir des vues utiles (diagramme d activité, cas d utilisation, diagramme de classes etc.) ainsi que les commentaires qui doivent leur être associés. Les logiciels de modélisation sont conçus de telle sorte que la cohérence soit garantie. Il importe que la MOA se forme à UML, et l utilise pour communiquer avec la MOE. Page : 8

9 4.3. Définitions Acteurs Un acteur est quelqu un ou quelque chose, externe au système, qui interagit avec lui. En règle générale, dans les projets EEP les acteurs sont des êtres humains qui exercent des rôles. Ce sont donc des personnes qui assurent l'exécution d'une activité. Rôle Un rôle se définit par des actes et des opérations qui sont exercées par un acteur. Ce dernier peut exercer à son tour plusieurs rôles (ex: un client peut exercer le rôle d'acheteur, de logisticien, de payeur, ). Activité Les activités sont modélisées et représentées par des diagrammes d'activité. L'activité porte principalement sur les aspects fonctionnels, à savoir la gestion des événements donc le comportement du système d'échange en fonction de ces différents états. Le diagramme d'activité n'est autre que la transcription dans UML de la représentation du processus telle qu'elle a été élaborée lors du travail qui a préparé la modélisation : il montre l'enchaînement des activités qui concourent au processus. Activité métier Une activité métier (Business Activity) représente un ou plusieurs processus métiers réalisé par des acteurs. Ce peut être par exemple, la préparation ou le contrôle d une commande, l'envoi de cette commande à un fournisseur et l'envoi de l'accusé de réception de cette commande par le fournisseur. Plus tard, ce même fournisseur fait parvenir une proposition de date de livraison à son client qui lui répond pour donner son accord. Dans ce scénario ou activité métier, on a mis en scène deux processus (commande et avis d'expédition) avec deux acteurs (client et fournisseur) qui ont exercé trois rôles (acheteur, vendeur, logisticien) Processus métier Un processus métier " Business Process " désigne un ensemble de plusieurs activités reliées les unes aux autres pour atteindre un objectif, généralement dans un contexte organisationnel (ex : l'entreprise) qui définit des rôles et des relations. Dans une activité métier le processus métier (Business Process) spécifie les modalités d exécution d un interchange qui peut être composé de un ou plusieurs échanges point à point. Lorsque l'on modélise un processus métier dans le cadre d'un système d'eep, il est toujours représenté par un diagramme de cas d utilisation, un diagramme d'activité et un diagramme de collaboration. Cas d utilisation Les cas d utilisation sont modélisés et représentés par des diagrammes de cas d utilisation. Les cas d'utilisation permettent de décrire l'interaction entre les acteurs et le système d'échanges. Le but est de démontrer que les acteurs d'un système d'échange ont un objectif lorsqu'ils l'utilisent. Le cas d'utilisation est une description des interactions qui vont permettre aux acteurs d'atteindre cet objectif en utilisant le système. Le diagramme de cas d'utilisation décrit la succession des opérations réalisées par des acteurs. C'est le diagramme principal du modèle UML, celui où s'assure la relation entre les utilisateurs et les objets que le système met en œuvre. Collaborations métier Les collaborations sont modélisées et représentées par des diagrammes de collaboration. Une collaboration métier (Business Collaboration) spécifie les modalités détaillées de la mise en œuvre des échanges d un processus métier : acteurs, rôles, activités, enchaînements, conditions et contraintes qui interviennent dans l exécution du processus. Des diagrammes de collaboration ou des diagrammes de séquence peuvent éventuellement compléter la description de la collaboration donnée par les diagrammes d activité. Dans les collaborations de type " protocole de collaboration métier ", les rôles des acteurs sont des rôles métier, par exemple " acheteur " et " vendeur "). Page : 9

10 Séquence Les séquences sont modélisées et représentées par des diagrammes de séquences. Une séquence représente la succession chronologique des opérations réalisées par un acteur : saisir une donnée, consulter une donnée, lancer un traitement ; elle indique les objets que l'acteur va manipuler, et les opérations qui font passer d'un objet à l'autre. Dans le cadre des EEP, les objets sont des documents. Transactions métier Les transactions sont modélisées et représentées par des diagrammes d activité qui peuvent être complétés par des diagrammes de séquence et/ou de collaboration. La transaction constitue l élément " atomique " (tout ou rien) de la décomposition d un processus métier. Le concept de transaction s'appuie sur la notion de point de synchronisation qui représente un état stable du système d'échange considéré. La cohérence des données doit être assurée dans tous les cas, même dans les cas d'erreur où le système doit revenir au précédent état cohérent. Lorsque la transaction est achevée, le système est dans un état stable durable, soit à l'issu d'une modification transactionnelle réussie, soit à l'issue d'un échec qui se solde par le retour à l'état stable antérieur. Cet échange doit être effectué dans un format, un ordre et un délai convenus. Une transaction est constituée d'un flux allé et d'un flux retour entre deux partenaires. Documents Métier Les documents métiers sont modélisés et représentés par des diagrammes de classe. Un document métier regroupe un ensemble d informations métier structurées et indépendantes des syntaxes. Implémenté dans une syntaxe, le Document Métier peut devenir un document XML, un message EDIFACT,... Dans le cadre des EEP, les documents métiers sont échangés par les acteurs à travers les processus métier. Le diagramme de classe représente l'architecture conceptuelle du système : il décrit les classes que le système utilise, ainsi que leurs liens, que ceux-ci représentent un emboîtage conceptuel (héritage, marqué par une flèche terminée par un triangle) ou une relation organique (agrégation, marquée par une flèche terminée par un diamant). Informations métier Les informations métiers sont modélisées et représentées par des diagrammes de classe. Une information est un stimulus qui a une signification dans un contexte donné pour celui qui le reçoit. Quand une information est enregistrée dans un ordinateur, elle est appelée donnée. Ce sont les informations qui agrégées constituent les documents. Les informations, une fois modélisées, font l'objet d'une description sémantique très précise, unique et non ambigüe. Ces mêmes informations sont nommées selon des règles de nommage très précises afin de pouvoir être entreposées dans des dictionnaires d'information. Les informations sont techniquement neutres et indépendantes des syntaxes. A l exception des types de données qui ont une signification spécifique, les rédacteurs de ce document, conformément à la terminologie des standards, ont utilisé " information " et non " donnée ". Données " Fait, concept ou instruction représenté sous une forme conventionnelle et adaptée à une communication, une interprétation, ou un traitement par l homme ou par des moyens automatiques (définition ISO ). ". Les données présentent des informations exprimées dans un format particulier. Dans le domaine des technologies de l information, les données sont des informations présentées dans un format qui permet leur traitement par les ordinateurs. En EDIFACT, une " donnée " désigne des informations exprimées dans la syntaxe EDIFACT. Composant Les composants sont modélisés et représentés par des diagrammes de classe. Un composant est un élément de base d'un ensemble plus complexe (structuré ou composite), lequel est un assemblage de composants souvent différents. Un composant permet de représenter une information métier. Un composant peut être simple ou agrégé c'est-à-dire formé de plusieurs composants. Page : 10

11 Un composant simple se caractérise par : Une identification telle que nom d'élément (Data element name) Une définition claire Un ou plusieurs termes de représentation Des valeurs optionnelles énumérées par des listes de codes Une liste de synonymes des éléments dans d'autres registres de métadonnées Message Un message spécifie un transfert d information entre deux ou plusieurs acteurs ou systèmes d'informations. Dans les EEP, les messages sont échangés par des systèmes de messagerie. Un message ebxml est constitué d'une enveloppe (contenant) qui contient trois parties, un entête (header) qui contient les informations de routage telles que coordonnées de l'expéditeur et du ou des destinataires, une description de conteneur (manifest) et un conteneur (payload). C'est dans le conteneur que l'on trouve les documents à échanger. Messagerie Un système de messagerie permet de véhiculer des messages. Il doit donc décrire : les protocoles d'échange de message (ex : SOAP); les systèmes et niveaux de sécurité à mettre en œuvre ; les protocoles réseaux (ex : HTTP(s), FTP(s), SMTP(s)) ; les erreurs et les actions qui les corrigent ; les accès aux annuaires. XML XML (Extensible Markup Language " langage de balisage extensible ") est un langage informatique de balisage générique. Le World Wide Web Consortium (W3C), organisme qui promeut la compatibilité des technologies du World Wide Web en éditant des recommandations à valeur de standards industriels, recommande XML pour exprimer des langages de balisages spécifiques (exemples : XHTML, SVG, XSLT). Son objectif initial est de faciliter l'échange automatisé de contenus entre systèmes d'informations hétérogènes (interopérabilité), notamment sur Internet. XML est un sous-ensemble de SGML dont il retient plusieurs principes comme : la structure d'un document XML est définissable et validable par un schéma, un document XML est entièrement transformable dans un autre document XML. Page : 11

12 5. Etapes d'un projet EEP La conduite d un projet d échanges électroniques standardisés mobilise de multiples partenaires et fait appel à une méthodologie de conduite de projet spécifique. Un projet de standardisation commence par l évaluation de sa faisabilité, se poursuit par son développement et se termine par sa mise en exploitation et sa maintenance. L organigramme général des étapes est le suivant : DEBUT Etude d opportunité et de faisabilité oui non FIN Constitution d'un groupe de Travail Spécification des processus métiers (ch 7) Recherche de standards existants Modélisation des processus metiers (ch 7) non Modélisation des documents metiers (ch 8) oui Publication UN/CEFACT pour standardisation (ch 13) Harmonisation et dépôt pour soumission (ch 6) Guide d'implémentation et convention interchange ch10 Développement syntaxique (ch 9) Choix des sites pilotes Implémentation (ch 10) Développement ou acquisition solution EEP Configuration et installation solution Tests et recette des sites pilotes Maintenance et Support (ch 11) Mise en exploitation des sites pilotes FIN Etapes d'un projet d'eep Déploiement accompagné Les organisations qui envisagent de mettre en œuvre un projet d'échanges électroniques commencent par en évaluer la faisabilité technique et économique. L étude passe par l identification des partenaires potentiels, leur mobilisation et leurs capacités, les flux à dématérialiser et, pour chaque flux, une prévision de volumes et le résultat attendu. Chaque flux est régi par un processus d'échange ou processus métier qui peut intéresser plusieurs types de documents. Constitution du groupe de travail Le groupe de travail doit à la fois être représentatif des acteurs des futurs processus dématérialisés et rester néanmoins d une taille propice à la productivité. Sa composition doit refléter les résultats de l étude d opportunité par l adhésion des membres aux objectifs du projet. Page : 12

13 Il faut avoir dans le groupe un chef de projet, mais aussi des experts des processus métier visés et de la méthodologie de projet. Un bon support méthodologique sera le garant de la productivité du groupe et de la pérennité de ses résultats. Pour élaborer la première version du modèle, on constitue des groupes de travail responsables du modèle. Ces groupes doivent être constitués au minimum de deux personnes, un modélisateur, expert dans la manipulation de l outil graphique et le langage UML, et un expert métier venu du terrain. Le modélisateur demande à l expert métier les informations nécessaires pour préciser le modèle. L expérience montre qu au bout de quelques semaines de travail en commun, l expert métier utilise spontanément le langage UML (" classe ", " lien ", " attribut ", etc.), ce qui prouve que ce langage n est pas difficile à assimiler. Analyse fonctionnelle, spécification et modélisation des processus, documents et informations (chapitres 7 et 8). La méthodologie ebxml fournit une démarche détaillée d élaboration des spécifications des processus et des informations échangées. Cette démarche est indépendante des syntaxes et des choix techniques d implémentation, ce qui simplifie significativement les évolutions ultérieures du service. Elle préconise de s'appuyer sur des catalogues de processus et de documents existants. Les processus et les documents qui sont développés dans le cadre du projet doivent être eux-mêmes réutilisables par la communauté et donc harmonisés avec les processus et les documents soumis par d'autre groupes de travail, puis enregistrés et confiés à des instances agrées à des fins de standardisation. Recherche des standards existants Dès que les besoins sont identifiés et les différents éléments modélisés, on procède à une recherche systématique de données similaires dans des entrepôts de standards existants. Le développement de nouveaux éléments ne se fait donc qu'en absence de standards sur " étagère ". Harmonisation et dépôt (cf. chapitre 6) Une fois les modèles réalisés, ils peuvent être déposés pour enregistrement auprès d une instance agrée. Celle-ci procédera, en relation avec les intervenants du projet, à leur harmonisation. L harmonisation passe en revue les éléments réutilisables des différents projets et les modifie si nécessaire pour parvenir à une présentation identique, voir universelle. L harmonisation des processus, des documents et des informations est une condition indispensable à l interopérabilité des échanges. Guide d Implémentation Avant d implémenter les standards et les solutions, le groupe de travail rédige un guide d implémentation. Le guide d implémentation contient l ensemble des informations nécessaires au déploiement des solutions EEP. Le groupe HICC d EDIFRANCE a défini un modèle de guide d implémentation pour les projets EEP en France. Le plan de ce modèle est précisé dans le présent document. Convention d Interchange Avant de mettre les échanges électroniques en exploitation, les partenaires établissent et signent une convention d interchange. Cette convention précise les modalités contractuelles des échanges. En EDIFACT, la convention d interchange n est pas standardisée. Des modèles de convention sont proposés par les différentes instances nationales et internationales impliquées dans la standardisation. En ebxml, les informations de la convention d interchange peuvent être formalisées en XML par les partenaires dans un CPA (Collaboration Protocol Agreement) à partir d'un modèle CPP (Collaboration Protocol Profile). Les CPP et CPA sont échangés afin d automatiser l'interconnexion. Page : 13

14 Développement syntaxique Avant d'implémenter les modèles, il est nécessaire de rendre ces derniers compréhensibles par les systèmes d'information des différents partenaires. Pour ce faire, on les convertit dans une syntaxe spécifique qui peut être de type EDIFACT ou XML. Si c'est la syntaxe XML qui est retenue, on produit alors des schémas XML qui représentent les documents métiers. C'est à partir de ces schémas que les systèmes d'information communiquent et peuvent se comprendre. Dans le cadre des projets TIC-PME 2010 et de la méthode ebxml de l'un/cefact, la syntaxe XML est fortement recommandée. Développement ou choix et acquisition de la solution EEP Les partenaires qui ne disposent pas de système EEP adéquat établissent un cahier des charges de développement ou de consultation, sélectionnent les offreurs appelés à répondre, reçoivent et analysent les offres, établissent le dossier de marché et signent le marché. Configuration et installation de la solution EEP La solution EEP retenue est configurée pour répondre aux exigences du cahier des charges. Chez chaque partenaire est mis en place un prototype qui s'interface avec leur système d'information et prend en compte les spécifications du système d échanges. Tests, recette Les modalités de test sont définies dans le cahier des charges. Les tests valident l ensemble des spécifications et s assurent que les anomalies sont prises en compte et remédiées. Des modifications du standard peuvent être définies et prises en compte en revenant aux étapes précédentes du projet. Lorsque les résultats des tests sont positifs, la solution est réceptionnée. Sites Pilotes Les partenaires expérimentent leurs systèmes d échanges. Les procédures d exploitation du service sont validées. Les résultats, performances et qualités sont enregistrés et confrontés aux spécifications. Les corrections et les éventuelles améliorations doivent être intégrées avant le début du déploiement. Déploiement accompagné Le déploiement généralisé ne peut se faire que lorsque les structures d administration ou de support ont été mises en place. Il requiert un accompagnement au démarrage. Maintenance et Support (cf. chapitre 11) Lorsque les échanges sont en exploitation, il est nécessaire d'assurer la maintenance du standard et des systèmes. Le suivi et la coordination requièrent un organe nommément désigné. Portage au niveau international (cf. chapitre 13) Les projets EEP qui recherchent une interopérabilité au niveau national ou international portent leurs modèles à l UN/CEFACT pour enregistrement, harmonisation et publication à titre de standards. La procédure de standardisation implique un certain formalisme, un suivi et une étroite collaboration entre le projet et les experts des groupes de travail de validation et d harmonisation. Le présent document n aborde de façon explicite que les phases du projet spécifiques à l élaboration et l implémentation d un standard d échanges. Les activités génériques de conception, développement, acquisition, et test d un système ne font pas l objet de développements ici. Un projet EEP sectoriel, comme le sont les projets TIC-PME 2010, peut être constitué de plusieurs sous projets. L un d entre eux aboutit à la spécification des standards d échanges nécessaires, voire à leur publication en tant que standard national ou international officiel. D autres peuvent être centrés sur la mise en œuvre de ces standards dans des systèmes d échanges, l accompagnement des sites pilotes, et enfin, la promotion et le déploiement généralisé. C est la vision globale de l ensemble de ces sous projets qui permettra d aboutir au vrai succès que constitue une large utilisation réelle par les entreprises des systèmes d échanges ainsi conçus. Page : 14

15 6. Coordination et harmonisation Un fournisseur de matériaux de construction doit pouvoir communiquer simultanément avec la grande distribution et avec les entreprises de travaux. Il souhaitera donc, à des fins pratiques et surtout économiques, utiliser les mêmes systèmes échanges avec ces différents réseaux de distribution. Pour atteindre cet objectif, il faut harmoniser les processus et les informations issus des multiples contextes sectoriels, et nationaux. Cette harmonisation conditionne l interopérabilité entre systèmes d'information au travers des EEP. Principes de l harmonisation Chaque projet EEP spécifie ses processus métier, ses documents et ses informations métier en répondant à ses propres exigences de besoins. Il est particulièrement judicieux de soumettre ces spécifications aux instances de standardisation, afin de les harmoniser et de le voir figurer dans les entrepôts de standards. Deux projets EEP peuvent par exemple créer un composant «ligne de facture», le nom, la structure et les propriétés de ces composants étant différents. Un travail d harmonisation doit être effectué pour unifier les structures et les propriétés des composants candidats à la standardisation et en extraire un composant «ligne de facture» standard et unique. Le travail de validation et d harmonisation est accompli par les experts des groupes de standardisation de l UN/CEFACT en relation avec les représentants des projets. Lorsqu un accord est trouvé, les composants sont standardisés et publiés dans une version actualisée de la librairie de composants réutilisables. L activité d harmonisation des processus des secteurs nationaux participant au projet TIC PME 2010 est suivie dans le cadre des réunions de coordination entre les représentants des projets EEP impliqués. Acteurs de l harmonisation des Processus Les instances impliquées dans l harmonisation des processus sont, d une part l UN/CEFACT, d autre part les instances nationales et sectorielles de standardisation. Ces instances mettent des structures d accueil et d accompagnement à la disposition des intervenants des projets EEP. EDIFRANCE et le groupe HICC EDIFRANCE a constitué un groupe de travail Harmonisation Intersectorielle (HICC). Ce groupe est ouvert aux adhérents d EDIFRANCE et aux acteurs des projets EEP participant à TIC PME Il propose aux utilisateurs des secteurs les services et supports suivants : Faire connaître les techniques des groupes de standardisation de l'un/cefact, du W3C et d'oasis, Accompagner les utilisateurs français dans la rédaction de spécifications de leurs processus métier. Permettre aux acteurs des secteurs d'activité de soumettre leurs composants selon une procédure commune dans le but d'aboutir à des Composants Communs uniques et harmonisés. Fournir un support aux projets TIC PME 2010 dans leurs procédures de standardisation à l UN/CEFACT, Mettre à disposition sur le site web d EDIFRANCE les spécifications des processus et des composants d informations disponibles. L UN/CEFACT et le TBG 17 Pour obtenir une prise en compte de leurs besoins dans les standards, les projets EEP soumettent leurs spécifications de processus et leurs composants d information à l UN/CEFACT en respectant un certain formalisme. Le projet est affecté à un groupe de travail sectoriel (Trade Business Group, voir liste au chapitre 13) qui en a la charge jusqu à sa standardisation. Les spécifications sont analysées par un groupe de travail ad hoc, le TBG 17. Composé de représentants des groupes sectoriels, le TBG 17 constitue une structure opérationnelle pour l harmonisation, la création des composants, et la publication du catalogue des composants communs de l UN/CEFACT. Page : 15

16 7. Processus métiers Dans les entreprises, on entend par processus métier l'enchaînement des tâches réalisées pour parvenir à un but final, donc pour produire une valeur ajoutée. Ces tâches sont soit intellectuelles (étude, recherche et développement, planification, décision, ) soit physiques (fabrication, livraison, maintenance, ). En règle générale, les tâches intellectuelles préparent et accompagnent les tâches physiques. Une description pertinente des processus métier garantit l adéquation entre le standard d échanges et les attentes des partenaires, donc la réussite du projet. L analyste fonctionnel réalisée par les groupes de travail permet de définir les caractéristiques des processus métier. Identification et description des processus métier Identification et description des collaborations métier Identification et description des transactions métier Identification du contexte métier Modélisation des processus métier Modélisation des collaborations métier Modélisation des transactions métier Spécification des processus métier Spécification des collaborations métier Spécification des transactions métier optionnelle Les activités de la spécification des processus métiers 7.1. Livrables de la spécification des processus métier Les processus métier sont décrits dans un document appelé BRS (Business Requirements Specification) et qui contient : des parties descriptives présentées en mode texte : présentation du processus, règles à l échange. des modèles conformes à la méthode UMM et présentés sous forme de diagrammes UML. des tableaux renseignés, appelés aussi feuilles de travail, qui complètent et précisent la représentation graphique donnée par le modèle UML. Lorsque le domaine d interopérabilité recherché est restreint à la France, le groupe de travail travaillant en langue française, les BRS peuvent être rédigés en langue française. Lorsque l'on désire porter un projet d'eep sur la scène Européenne au niveau du CEN ou sur la scène internationale au niveau de l'un/cefact, il est alors obligatoire de traduire ce dernier en langue anglaise (Référence : Oxford English Dictionnary). Le tableau ci-après détaille le contenu du BRS. Contenu du BRS Activité Tableau / Feuille de travail Diagrammes UML Périmètre du projet Description du projet et du contexte métier Spécification des Processus Contexte métier Néant. Description des processus métier Processus métier Diagramme de cas d'utilisation Diagramme de séquence (optionnel) Page : 16

17 Spécification des Collaborations Description des collaborations métier Spécification des Transactions (optionnelle) Description des transactions métier Collaboration métier Transaction métier Diagramme d'activité Diagramme de séquence (optionnel) Diagramme de collaboration (optionnel) Diagramme d'activité Diagramme de séquence (optionnel) 7.2. Description du contexte métier Le tableau suivant sert à préciser les catégories de contexte qui correspondent au processus à décrire. Catégorie de contexte Processus métier Classification produit Classification activité Géopolitique Contrainte légale Rôle dans le Processus Rôle auxiliaire Capacités System Description du contexte Processus de facturation. Tous. Tous. International, global. Directive Européenne et MINEFI. Tous rôles pour facturations publiques et privées. Néant. Archivage Spécification des processus métier Chaque processus métier correspond à un cas d utilisation. Le cas d utilisation décrit la manière spécifique d utiliser le système EEP pour réaliser les objectifs du processus métier. Le diagramme de cas d'utilisation décrit la succession des opérations réalisées par un acteur. C'est le diagramme principal du modèle UML, celui où s'assure la relation entre l'utilisateur et les objets que le système met en œuvre. Use Case Fournisseur Facture Client Diagramme de cas d'utilisation d'un processus de facturation simple Processus métier Nom du processus Facturation Page : 17

18 Identifiant du processus Description Acteurs Pré-conditions Post-conditions Scénario Commentaires Facture intersectorielle Le fournisseur présente au client une facture qui correspond aux biens et/ou services qu'il lui a livré, conformément à la commande que le client lui avait préalablement passée. Le client s'assure que la facture est conforme aux biens et services livrés et commandés, vérifie les prix au droit de la commande et procède au règlement. Client, Fournisseur (Acteurs auxiliaires : Tiers payant, Agent comptable) Les biens ou les services facturés ont été préalablement livrés par le fournisseur et correspondent à ce qui avait été initialement commandé par le client. Si le client ne relève aucune anomalie, il déclenche le paiement. Dans le cas contraire, il conteste la facture. Le fournisseur a livré au client ou à un tiers dûment mandaté par ce dernier les biens et/ou services correspondants à la commande qu'il lui avait fait parvenir. Cette livraison ayant fait l'objet d'un bon de livraison signé par le client, le fournisseur émet alors une facture qui reprend les termes de la commande et du bon de livraison. Néant 7.4. Spécification des collaborations métier Formaliser un processus conduit à définir de façon explicite les activités et leur enchaînement ainsi que les relations entre les acteurs et les documents qu'ils manipulent tout en spécifiant les conditions, les contraintes et les règles propres à l échange. Collaboration métier Nom de la collaboration Identifiant de la collaboration Description But Rôle initialisant Rôle demandeur Evènements Initiaux Evènements Finaux Limites Contraintes Commentaires Emission de facture Emission de facture Le fournisseur adresse au client une facture qui correspond aux biens et/ou services qu'il lui a livré. Le client contrôle si les quantités et les prix correspondent à ceux qui avaient été négociés lors de la commande et/ou du contrat d'approvisionnement. Si tout est en règle, le client déclenche alors le paiement. Dans le cas contraire, il conteste la facture et demande au fournisseur de la corriger. Demander le paiement des biens et /ou services fournis Fournisseur : vendeur, agent commercial, affactureur Client : acheteur, agent acheteur Le fournisseur envoie la facture Le client règle la facture ou déclenche le processus de contestation Néant Règlementation Européenne et MINEFI Néant Les modèles de collaboration métier présentés dans les BRS sont des diagrammes d activité. Les diagrammes d activité peuvent être complétés par des diagrammes de séquence et/ou par des diagrammes de collaboration. On appelle "activité" l'ensemble des tâches réalisées par un même acteur lors d'une étape du déroulement du processus. On appelle séquence la succession chronologique des opérations réalisées par les acteurs. Le diagramme de séquence indique les échanges de documents sans préciser les activités internes qui se déroulent entre les envois. On peut représenter les mêmes opérations par un diagramme de collaboration et/ou un diagramme de séquence. Diagramme de séquence et diagramme de collaboration sont deux vues différentes. Page : 18

19 Activité Client Fournisseur Commande et Livraison Début Reçoit facture Prépare et émet facture Contrôle facture Facture Ok? [Non] Conteste facture [Oui] Fin Diagramme d activité modèle de la collaboration facture simple La spécification des transactions métier, optionnelle, suit les mêmes principes généraux que celle des collaborations. Elle permet de réutiliser sans la redéfinir à chaque fois une même transaction simple qui serait exécutée dans plusieurs collaborations. Page : 19

20 8. Documents, informations métiers et composants Les informations métier appelées aussi composants définissent le contenu des échanges des processus métier et sont assemblées dans les documents métier. Chaque flux d un processus transfère un " Payload " entre un émetteur et un ou plusieurs destinataires. Le " Payload ", analogue à l interchange EDIFACT, contient un ou plusieurs documents métier et éventuellement des fichiers annexes multiformats qui leurs sont attachés. Les informations métiers communes appelées composants communs font l'objet d'une harmonisation visant à les mutualiser. Cette harmonisation permet de mettre à la disposition des projets, des entrepôts de composants communs et réutilisables, afin de réduire les coûts de développement. Pour décrire les composants, un certain nombre de règles sont à respecter, qui, pour l'essentiel sont décrites dans une recommandation de l'un/cefact appelée la CCTS (Core Component Technical Specification). Nous développerons ci-dessous : la méthode de description des documents et des informations métier qui les composent. le formalisme à respecter en vue d'une soumission aux instances de standardisation. les principes et concepts de représentation des composants tels que décrit dans la CCTS. les outils, les modèles et les feuilles de travail, mis à disposition des utilisateurs pour les modéliser et les décrire. Identification des informations métier Génération des composants Modélisation des informations métier Description de leurs attributs BRS Spécification des informations Modélisation des composants Spécification des composants RSM Les activités de la spécification des informations et de la génération des composants Livrables de la spécification des informations et des composants métier Les informations métier sont décrites dans deux documents appelés le BRS (voir chapitre précédent) et le RSM (Requirements Specification Mapping) qui contiennent : des parties descriptives présentées en mode texte : présentation des informations métier, des composants, des attributs et des documents. des modèles conformes à la méthode UMM et présentés sous forme de diagrammes de classe UML. des tableaux renseignés, appelés aussi feuilles de travail, qui complètent et précisent la représentation graphique donnée par le modèle UML. Le tableau ci-après détaille le contenu du BRS et du RSM. Le BRS contient donc les informations métiers succinctes de niveau supérieur et sans application des règles de la CCTS. Page : 20