Cas d'usages

• 1: Gouvernance
• 1.1: Evaluation de la qualité des flux
• 1.2: Evaluation de la qualité des échanges
• 2: Métier
• 2.1: Alerte rapide des dysfonctionnements
• 2.2: Prouver le transport d'une information
• 2.3: Recherches transverses de données transportées
• 2.4: Suivi de bout en bout
• 3: Support
• 3.1: Réduction des efforts de support
• 3.2: Centralisation de la supervision
• 4: Technologique
• 4.1: Migration de produits
• 4.2: Transformation technologique
• 4.3: Upgrade de version

1 - Gouvernance

1.1 - Evaluation de la qualité des flux

Besoins

Problématique

Réponse

1.2 - Evaluation de la qualité des échanges

Besoins

Problématique

Réponse

2 - Métier

Ces usages présentent les usages des acteurs technico focntionnels au sein des entreprises.

2.1 - Alerte rapide des dysfonctionnements

Problématique

• Comment alerter efficacement les référents fonctionnels lors de dysfonctionnement ?
• Comment identifier les référents ?
• Comment regrouper des dysfonctionnements entre eux afin de ne pas submerger en erreurs ?
• Quel est le niveau de l’alerte ?

Besoins

Une alerte est le fait de communiquer sur un dysfonctionnement. Elle doit être envoyée aux destinataires concernés par celui-ci. Dans le cas des échanges, il s’agit des responsables des applications sources et cibles.

Le niveau de l’alerte répond à 2 critères:

1. La criticité fonctionnelle de l’échange,
2. La gravité de l’erreur rencontrée.

Réponse

EFR organise sa vision du système d’information suivant des principes d'urbanisation. Ainsi il peut déterminer:

1. les applications mises en jeu lors d’un échange,
2. les contacts à solliciter.

EFR regroupe les dysfonctionnements suivant 2 perspectives:

1. métier pour offrir une vision par le métier (échanges et informations),
2. applicative pour permettre une compréhension des comportements des applications et de leurs interfaces.

Chaque contact est alors informé 1 seule fois lors de dysfonctionnements. Il n’y a pas d' effet TSUNAMI lors d’erreurs en masse sur un flux.

Enfin, la criticité de l’alerte est déduite par la définition de l’échange dans la vue métier de l' urbanisation.

2.2 - Prouver le transport d'une information

Problématique

• Comment démontrer le bon transport d’une donnée ?
• Comment suivre l’avancement du transport ?
• Comment valider le départ ou l’arrivée à destination ?

Besoins

Lors de la réception de données commercialement sensibles, il est primordial d’être en capacité de démontrer la réception dans le Système d’Information de l’entreprise. Un mécanisme de preuvre est alors nécessaire.

Exemples:

• Lors de la réception de flux EDI
• Lors d’échanges intégrés par MESSAGES avec un partenaire.

Réponse

EFR gère tout contenu de traces et leurs états correspondant. Il organise ces traces afin de les regrouper dans des ensembles simples et cohérents. Ces traces peuvent donc servir de preuves de transport entre des partenaires internes ou externes à l’entreprise.

Les partenaires émettent des traces aux étapes clés des traitements comme :

• émission,
• réception,

Les étapes internes (envoi, transformation, erreurs) viennent ensuite compléter le cheminement complet afin de permettre le suivi et la preuve de bout en bout.

2.3 - Recherches transverses de données transportées

Problématique

• Quelles sont les données transportées par les échanges ?
• Comment gérer les perspectives des données dans le SI ?

Besoins

Le métier a besoin de vérifier le transport d’informations au sein des briques du système d’information.

Il convient de rechercher par nature ou par identifiant métier les échanges réalisés.

Exemple:

• Tous les échanges ayant transportés la facture ABC,
• Quelle est le dernier système à avoir reçu la commande DEF ?

Réponse

Pour répondre à ce besoin, 3 fonctionnalités sont nécessaires:

1. la définition d’information purement fonctionnelle,
2. la capacité à lier des données (techniques ou applicatives) à ces informations,
3. l’identification des données dans les échanges.

Exemple:
Une commande est transportée sous les noms suivants:
- pour SAP: BLAORD et E1EDK03 suivant les contextes,
- pour Salesforce: order. 
- des raccourcis versionnés tels que ORDER01 et ORDER02

Enterprise Flows Repository y répond pleinement avec:

1. la prise en compte de:

• information: notion purement fonctionnelle, dans la vue BUSINESS,
• donnée: notion applicative, dans la vue APPLICATIONS.
• alias: synonymes des informations et des alias.

2. Le marquage des données transportées dans le format interne de la trace

2.4 - Suivi de bout en bout

Problématique

• Comment suivre un échange dans le systèmes d’information de bout en bout ?
• Comment obtenir une vision accessible par les non spécialistes ?
• Comment suivre un message entre plusieurs systèmes internes, externes ou même de partenaires ?

Besoins

Un échange entre le producteur et ses consommateurs passent par des systèmes différents à des fréquences différentes. Le message initial peut être découpés, regroupés et routé de nombreuses fois.

Pour suivre puis comprendre le transport d’une donnée, il convient d’avoir une console unique et agnostique de ces technologies.

Réponse

Enterprise Flows Repository regroupe l’information de transport. Il ne présupose pas un mode ou une technologie pour cela.

La cartographie applicative donne du lien et de la cohérence aux traces reçues par 1 ou plusieurs partenaires.

3 - Support

3.1 - Réduction des efforts de support

Besoins

Problématique

Réponse

3.2 - Centralisation de la supervision

Besoins

Problématique

Réponse

4 - Technologique

4.1 - Migration de produits

Besoins

Problématique

Réponse

4.2 - Transformation technologique

Besoins

Problématique

Réponse

4.3 - Upgrade de version

Besoins

Problématique

Réponse