FR2852123A1 - Procede pour l'automatisation de la mise en oeuvre et la mise a jour d'un systeme d'information - Google Patents

Abstract

Le procédé selon l'invention concerne un procédé pour l'automatisation de la mise en oeuvre et la mise à jour d'un système d'information, comprenant les phases suivantes : une phase de spécifications électroniques (Bloc 1) correspondant à un premier statut d'une version donnée du système d'information, une phase de génération automatique (Bloc 2) du système d'information correspondant à un deuxième statut d'une version donnée du système d'information, une phase de mise en production (Bloc 5) correspondant à un troisième statut d'une version donnée du système d'information déployée sur différents canaux d'exécution, si une modification du système d'information est apportée après la mise en production, une phase d'adaptation (Bloc 7) comportant le retour à la phase de spécifications électroniques ; ce procédé gérant automatiquement, les uns par rapport aux autres, les statuts des différentes versions du système d'information.Elle s'applique notamment à la gestion des flux d'informations des entreprises.

Description

La présente invention concerne un procédé pour l'automatisation de la mise

en oeuvre et la mise à jour d'un système d'information. Elle s'applique plus particulièrement, mais non exclusivement, à la gestion des flux d'informations des entreprises.

1 5 De façon générale, l'architecture d'un système d'information d'une entreprise peut comprendre: - un système de gestion des processus métier (" Business Process Management System ") appelé ci-après BPM, - un système d'information (SI) proprement dit, - un système d'intégration des applications d'entreprise (" entreprise application intégration ") appelé ci-après EAI, - un moteur des flux de travail (" workflow ").

Le système d'information est le système principal qui stocke les données de 25 l'entreprise et représente son fonctionnement. Dans l'idéal, le système d'information devrait intégrer les processus métier (les activités) de l'entreprise dans tous ses secteurs ou départements (vente, service client, comptabilité, ressources humaines...) étant entendu qu'un secteur ou département peut être caractérisé par un ensemble de processus métier. 30 Dans une entreprise, il peut y avoir plusieurs systèmes d'information pour couvrir l'ensemble des besoins et un ou plusieurs systèmes d'information pour un seul secteur.

Dans une entreprise, les employés (appelés -aussi " acteurs ") travaillent, collaborent dans différentes activités.

Tous ces acteurs, dans différents départements de l'entreprise, travaillent en utilisant certains éléments en commun qui sont aussi appelés objets métier.

Par conséquent, il est nécessaire de faire communiquer les systèmes d'information entre eux pour avoir une vision générale de ces objets métiers.

Avant l'apparition des EAI, les systèmes d'information étaient interconnectés entre eux un par un. Lorsqu'il y avait plus de deux systèmes d'information 10 alors le nombre d'interfaces augmentait de manière factorielle ce qui posait d'énormes problèmes de mise en place et de maintenance. Le but de l'EAI est de centraliser les échanges entre les systèmes d'information afin de diminuer la maintenance des interfaces. Parmi les exemples d'EAI connus, on peut citer WebMethods, Crossworlds, .. . 15 En revanche, l'EAI ne permet pas de stocker des données.

Ainsi, on peut dire que les différents processus métier des différents secteurs sont connectés entre eux. Comme l'EAI est le système qui permet de 20 connecter les systèmes d'information, il doit connaître les liens existant entre différents processus et la nature des données à transmettre.

Pour faciliter la modélisation des connections entre processus, il existe des outils, ce sont les BPM (par exemple W4, Rational Rose, System Architect, 25 Microsoft Visio). Ils servent à documenter les processus métier de l'entreprise. A défaut de ces outils, on utilise un logiciel de bureautique (Microsoft Word, PowerPoint...) pour les modéliser.

Il est à noter que les EAI et BPM ne permettent pas d'agir sur les processus 30 métier intégrés dans chaque système d'information. En effet, de même que les moteurs de workflow (moteur de flux de travail), ils ne sont que des composants de l'architecture d'un système d'information mais ne peuvent pas constituer un système d'information à eux-seuls.

Par conséquent, il faut intervenir directement au niveau du système d'information pour gérer les processus métier. En effet, c'est le système d'information qui supporte leur exécution.

Ces processus métier décrivent le fonctionnement de l'entreprise et ont notamment trait à la vente, le service client, le marketing, la comptabilité, la gestion des achats, la gestion des stocks, la logistique etc. Différents types de système d'information sont envisageables: 10 Des systèmes d'information comprenant des processus métier préintégrés ne permettant aucune adaptation. Or, ces derniers sont très rigides et correspondent rarement aux besoins et au fonctionnement propre de l'entreprise.

- Une solution totalement opposée correspond à l'élaboration complète d'un système sur-mesure. Mais, cette approche est très onéreuse et elle n'est valable qu'à un instant donné. En effet, dès qu'un processus métier est modifié c'est tout le ou les systèmes o il intervient qu'il 20 convient de modifier, ce qui sous-entend reprendre le cycle d'élaboration pour produire une mise à jour entraînant ainsi de nouveau coûts. La maintenance d'un système d'information est donc très complexe et devient un frein pour modifier le processus métier de l'entreprise. En général les modifications à effectuer dans le système 25 sont rassemblées dans l'attente d'une prochaine version.

- Une solution intermédiaire consiste à utiliser un système pré-défini, supportant quelques processus métier génériques et de l'adapter, c'est ce qu'on appelle la phase d'intégration du système d'information. 30 Cette phase nécessite de collecter des informations, les processus métier de l'entreprise, de les transposer en spécifications fonctionnelles puis techniques, de les intégrer à proprement parler dans le système d'information pour le modifier puis de le modifier et d'effectuer la mise en production du système ainsi modifié. Cette intégration se fait manuellement et prend en moyenne quatre-vingt dix jours avec neuf consultants (source: IDC, " Systems Integration Services for the Middle Market: Four Case Studies That Challenge the Myths ", Stéphanie M. Torto, 2002). Par " manuellement ", on 5 entend que chaque étape du procédé est réalisée et consignée indépendamment des autres et qu'il est nécessaire d'intervenir pour faire transiter les informations avec des risques d'erreurs notamment dus aux mises à jour qui sont d'ailleurs toujours lourdes à mettre en place.

Par ailleurs, la mise en oeuvre d'un système d'information est d'autant plus longue que différents canaux interviennent pour permettre l'exécution de processus métiers.

Le coût et le temps d'analyse, d'intégration des processus métiers, 15 d'interfaçage de ces différentes applications (faisant intervenir ou non un EAI) sont d'autant plus importants et complexes que les activités du processus métier sont imbriquées et que le nombre de canaux à mettre en oeuvre est important.

En effet, les différents acteurs intervenant dans un processus métier 20 exécutent les activités qui leur sont assignées dans différents " canaux " de communication: les clients peuvent par exemple utiliser le site ecommerce de l'entreprise, tandis que les commerciaux utilisent une application nomade depuis un ordinateur portable lors de leurs déplacements, les livreurs utilisent une application sur un terminal portable (type " Palm Pilot ") permettant le 25 suivi des livraisons à effectuer qu'ils synchronisent à leur retour, etc. Aujourd'hui on utilise une application informatique différente pour chaque canal d'exécution. Une des difficultés de l'intégration est la communication entre ces différentes applications.

L'invention a pour objet de supprimer ces inconvénients via un procédé permettant automatiquement à la fois la génération d'un système d'information et sa mise à jour en temps réel notamment en divisant le temps d'intégration des processus métiers dans le système par trois, ce procédé pouvant gérer des processus utilisant plusieurs canaux d'exécution.

A cet effet, elle propose un procédé pour l'automatisation de la mise en oeuvre et la mise à jour d'un système d'information comprenant les phases suivantes: - une phase de spécifications électroniques correspondant à un premier statut dit de " spécification " d'une version donnée du système d'information et comprenant notamment une modélisation des processus métier, ladite modélisation des processus métier comportant une définition des flux de travail, et une définition des 10 responsabilités, - une phase de génération automatique du système d'information à partir des spécifications électroniques correspondant à un deuxième statut dit de " test " d'une version donnée du système d'information, - une phase de mise en production correspondant à un troisième statut 15 dit d' " opération " d'une version donnée du système d'information et comportant un déploiement automatique de ladite version opérationnelle du système d'information sur différents canaux d'exécution, - si une modification du système d'information est apportée après la 20 mise en production, une phase d'adaptation comportant le retour à la phase de spécifications électroniques et ainsi la création en statut " spécification " d'une nouvelle version du système d'information, ce procédé gérant automatiquement, les uns par rapport aux autres, les statuts des différentes versions du système d'information. 25 En outre, les modifications apportées aux processus métier modélisés et par conséquent au système d'information pourront être mises en oeuvre en temps réel: Avantageusement, ladite gestion des statuts et des versions pourra notamment permettre qu'une version ait un statut opération pendant qu'une autre version a le statut spécification et ce, sans confusion possible.

La phase de spécifications électroniques pourra comprendre la définition des écrans de travail des différents utilisateurs.

Les spécifications électroniques comprennent une description détaillée avec 5 une granulométrie très fine afin que toutes les informations permettant de générer le système d'information soient inclues.

Lors de la modélisation des processus métiers, il est tenu compte du ou des canaux d'exécution de chaque activité afin de pouvoir générer 10 automatiquement les éléments du système d'information adéquats.

En effet, les processus métier sont des processus " de bout en bout ", c'està-dire que l'on peut représenter la chaîne complète des processus métier, quel que soit le canal utilisé pour l'exécution des activités.

Avantageusement, la gestion et la distribution des documents de spécifications pourront être effectuées automatiquement à partir des spécifications électroniques.

Il pourra y avoir des tests avant la phase de mise en production par exemple, 20 un test de conformité, un test de validation.

Il est à noter que, dans la mesure o le système d'information a été généré automatiquement à partir des données modélisées, il est conforme par défaut c'est-à-dire il correspond exactement auxdites données, ce qui rend 25 inutile un test de conformité.

Le test de validation a lieu sur une version du système d'information, correspondant à un statut test, isolée mais identique à celle qui sera mise en production.

Le test de validation pourra consister à faire vérifier par un responsable de l'entreprise qu'aucune erreur ou oubli concernant un processus métier n'a été faite. Il vérifiera également la cohérence du processus métier.

-T

Des scénarios de test pourront être définis pour le test de validation.

Si le résultat du test est positif, la phase de mise en production du système d'information peut commencer et la version du système d'information passe à un statut opération.

Si le test est négatif, il y a retour à la phase de spécifications électroniques et répétition des phases suivantes jusqu'à ce que le test soit positif, La modélisation des processus métier en tenant compte des canaux 10 d'exécution de chaque activité pourra permettre lors de la génération du système d'information, la génération d'éléments pour chaque canal tels que des écrans de travail, des fonctions de synchronisation.

Par exemple, le simple fait de définir une activité via un canal " Web " 15 permettra, lors de la génération du SI, de générer des écrans de travail et fonctions nécessaires au sein du site e-commerce. De même, si une activité est définie comme étant une activité via un canal " terminal manuel ", par exemple de type Palm E), alors l'application générera automatiquement les écrans de travail et fonctions de synchronisation nécessaires sur un terminal 20 manuel, et ainsi de suite.

La phase de mise en production comprend la réplication de la dernière version du système d'information testé, c'est-à-dire en statut " test " sur un serveur de l'entreprise puis son déploiement automatique sur les différents 25 terminaux ou postes clients.

Ledit déploiement sur les postes clients pourra être réalisé directement à partir d'un identifiant utilisateur donnant ainsi un accès restreint adapté à un certain nombre d'activités, c'est-à-dire donnant uniquement accès aux 30 activités sous la responsabilité de l'utilisateur.

Après le déploiement d'une nouvelle version du système d'information à la suite d'une modification par exemple d'un processus métier, les postes clients pourront détecter automatiquement une nouvelle version de système d'information et ainsi se mettre à jour.

Des modes d'exécution de l'invention seront décrits ci-après, à titre 5 d'exemples non limitatifs, avec référence aux dessins annexés dans lesquels: La figure 1 est un schéma de principe d'un procédé selon l'invention; La figure 2 est un schéma détaillant l'étape de " spécifications électroniques " de la figure 1; La figure 3 est un schéma détaillant l'étape de " modélisation des processus métier " de la figure 2 15 La figure 4 est un schéma détaillant l'étape de " définition d'un flux de travail " de la figure 3; La figure 5 est la représentation d'une interface graphique utilisée 20 pour la modélisation du flux de travail, La figure 6 est un schéma détaillant l'étape d'" ajout d'activité " de la figure 4; La figure 7 est un schéma détaillant l'étape de " définition du modèle de données " de la figure 6; La figure 8 est une représentation d'une interface graphique utilisée pour la définition du modèle de données; 30 La figure 9 est un schéma détaillant l'étape de " test " de la figure 1.

Dans cet exemple, le schéma de principe d'un procédé selon l'invention comprend les étapes suivantes (Figures 1, 2 et 3): - une détermination des spécifications électroniques (Bloc 1) comportant une modélisation des processus métier (Bloc 8) et une définition, si besoin, des écrans de travail (Bloc 9), des règles d'exécution d'activités automatiques (Bloc 10), ladite modélisation des 5 processus métier comprenant une définition des flux de travail (Bloc 1l), une définition des responsabilités (Bloc 12) et des canaux d'exécution (Bloc 13), cette détermination correspondant à une version n du système d'information dont le statut est " spécification ", - une génération du système d'information correspondant à la version n 10 dans un statut test (Bloc 2), c'est-à-dire que la version est utilisable car les écrans de travail et autres fonctions nécessaires à l'utilisation sont désormais disponibles, - une étape de test proprement dit de la version n du système d'information (Bloc 3) ou directement une étape de mise en production 15 (Bloc 5) correspondant à un statut opération de la version n.

- si la nécessité de modification survient après les tests (Bloc 4) ou la mise en production (bloc 5), il y a élaboration de nouvelles spécifications électroniques et ainsi d'une nouvelle version n+1 dans un statut " spécifications " à partir de l'introduction des modifications 20 (Bloc 7).

On appelle activité automatique une activité exécutée de manière automatique par le système d'information sans l'intervention d'un acteur de l'entreprise.

Un moteur de " workflow " ou d'activités automatiques exécute ces activités selon les règles d'exécution définies lors de la définition des informations d'une activité automatique dans la phase de spécifications électroniques.

C'est pourquoi on peut dire que les activités automatiques sont assignées à 30 la responsabilité " workflow " qui apparaît alors comme une responsabilité d'un utilisateur à part entière, sauf que l'utilisateur est le " workflow ", c'est à dire le système.

Lorsque l'on définit une nouvelle version du système d'information, on crée en fait une nouvelle version du système d'information ayant le statut "spécification". La même version suit les différentes étapes du procédé et passe successivement du statut "spécification" au statut "test" et enfin le cas échéant - au statut "opération".

Par exemple dans une entreprise, la version n est en opération.

Un administrateur du département marketing a besoin de modifier certaines activités de ses processus métiers. Il génère donc une version n+1 du système d'information, basée sur la version n, et ajoute les modifications aux 10 spécifications électroniques.

Pendant ce temps, l'administrateur du département commercial désire également faire des modifications de certains de ses processus métiers, il voit qu'une version n+1 est en cours de spécification et y apporte les modifications nécessaires.

Lorsque les spécifications sont terminées, les différents administrateurs se mettent d'accord pour mettre la version dans le statut "test" puis une fois les test finis, dans le statut "opération".

Ainsi tous les changements sont pris en compte dans cette même version n+ 1. Si les tests effectués sur n+1 ne sont pas satisfaisants, la version n+ 1 20 peut repasser au statut spécification".

Il ne peut y avoir qu'une seule version dans un même statut. Par contre, pendant qu'une version n a le statut "opération", la version n+1 peut être en ispécification".

Toutes les étapes du procédé décrites ci-dessus sont réalisées électroniquement et/ou automatisées dans l'application.

La définition des processus métier correspond au livre de processus ou 30 " Process Book " généralement rédigé par des intégrateurs et réalisé sous forme papier.

Le schéma de la figure 4 correspond à la définition du flux de travail soit la définition des différentes activités de l'entreprise et de l'ordre dans lequel ces activités sont exécutées. Cette étape est elle- même un processus composé de plusieurs étapes: - ajout d'activité (Bloc 14), positionnement d'activité dans le processus métier (Bloc 15), - ajout de liens entre les activités (Bloc 16), - ajout de points de décision (Bloc 17).

La modélisation du flux de travail est faite graphiquement (Figure 5) au moyen d'une interface appelée tableau blanc électronique permettant 10 notamment: - sur une première partie 18 de l'écran d'affichage d'un ordinateur: - une représentation graphique des activités d'un flux de travail par une forme géométrique telle qu'un rectangle 19, - une représentation des liens entre activités au moyen de lignes 20 15 joignant lesdites activités, - une représentation des points de décision par une forme géométrique par exemple hexagonale 21, - sur une deuxième partie 22 de l'écran d'affichage d'un ordinateur, une entrée d'informations complémentaires d'une activité, - sur une troisième partie 23 de l'écran d'affichage d'un ordinateur, une entrée des responsabilités pour chaque activité, - sur une quatrième partie 24 de l'écran d'affichage d'un ordinateur, une entrée du ou des canaux d'exécution 25 au moyen de listes de choix 26 (Web, UMTS, fax...).

L'étape " Ajout d'activité " illustrée sur la figure 6 consiste à ajouter une activité pour composer un flux de travail, cette activité pouvant être créée (Bloc 27) car nouvelle ou prédéfinie ou encore issue d'une activité prédéfinie puis ajustée (Bloc 28).

Quand une activité n'existe pas en tant qu'activité prédéfinie et qu'un ajustement d'une activité prédéfinie n'est pas suffisant, une nouvelle activité (Bloc 27) est créée en définissant un certain nombre d'informations.

Si l'activité correspond elle-même à un flux de travail, il faut suivre le processus " Définition de flux de travail " (Bloc 11) afin d'obtenir la granulométrie la plus fine possible.

Si l'activité est une activité élémentaire alors il faut suivre le processus " Définition d'activité " (Bloc 29).

La définition d'une activité qu'elle soit pré-définie (dans ce cas, ces étapes ont déjà été réalisées) ou non comprend donc les étapes suivantes: - La collecte d'information sur l'activité: nom, but, type. On spécifie notamment si l'activité est exécutée par l'utilisateur ou automatiquement par le système (" activité automatique ") (Bloc 30).

- La définition du modèle de données de chaque activité (Bloc 21), 15 chaque activité étant exécutée dans un contexte bien précis. En effet, lorsque l'on effectue une activité métier, on agit en fait sur les données ou attributs d'un ou plusieurs objets métier.

On appelle objet métier un ensemble d'attributs groupés logiquement, caractérisant une entité élémentaire d'un métier.

Dans l'exemple de mode d'exécution, chaque attribut peut être associé à un type de visualisation par défaut, c'est-à-dire que l'on précise dans la définition de chaque attribut à quel niveau de détail il correspond, et il doit être visible.

Le contexte d'une activité correspond donc à un environnement 25 d'objets métiers autrement appelé modèle de données. Les objets métiers compris dans ce modèle sont liés entre eux par des relations.

Par exemple, dans l'activité " gestion des adresses client ", deux objets métiers pourraient être inclus: " Client " et " Adresse ". Dans ce modèle, on voit toutes les adresses pour un client donné. L'objet 30 métier " Client " est donc représenté comme le père de " Adresse " et plusieurs adresses sont listées pour un client.

Définir le modèle de données (Figure 7) d'une activité consiste à: o Consulter un répertoire prédéfini d'objets métier (Bloc 32), - 13 O Si le ou les objets métier voulus se trouvent dans ce répertoire, ils sont introduits dans le modèle de données (Bloc 33), O Si le ou les objets métier voulus ne sont pas dans le répertoire, ils peuvent être créés (Bloc 34) puis introduits dans le modèle de données (Bloc 33), O Une fois que les objets métier nécessaires sont ajoutés, il faut définir les relations entre eux (Bloc 35), Ces relations peuvent signifier une relation 1 à 1 ou 1 à n. Le sens de relation entre les objets est normalisé. Par exemple, 10 lier un objet A vers un objet B veut dire que A est le fils de B. Ces relations sont utilisées lors de l'exécution de l'activité pour lier dynamiquement les objets métier. Dans un système d'information classique, les objets métier sont déjà liés entre eux par l'éditeur du système; par conséquent les liens sont 15 rigides. C'est la principale raison de l'inflexibilité des systèmes d'information existants.

A l'inverse, dans l'invention, les objets métiers sont dynamiquement liés dans chaque activité, les liens sont donc flexibles selon les besoins de chaque activité. 20 o Pour chaque objet métier, on précise de quelle manière l'utilisateur va voir les données des objets métiers (Bloc 36) d'une activité dans le système d'information en production. Un objet métier peut être inclus dans différentes activités et être montré de manière différente dans chaque activité. Par 25 exemple, dans l'activité " voir la hiérarchie d'un client ", l'objet métier " client " est montré sous la forme d'arbre. Les différents types de visualisation peuvent par exemple être classés comme suit: liste sommaire / moyennement détaillée / très détaillée I formulaire I arbre / arbre-liste / liste - formulaire, etc. 30 Cette étape se veut extrêmement simple et permet à n'importe quel utilisateur non informaticien de décrire dans un vocabulaire approprié la manière dont il veut voir les données dans les écrans de travail.

La définition du modèle de données est réalisée au moyen d'une interface graphique (Figure 8) o: - sur une première partie de l'écran d'affichage d'un ordinateur se situe le répertoire o sont listés les objets métier (Bloc 37), - sur une deuxième partie de l'écran d'affichage d'un ordinateur (Bloc 39) se trouve la représentation graphique du modèle de données de l'activité en cours de création, il convient alors de faire glisser l'objet métier de la fenêtre du répertoire à la fenêtre du modèle de données 10 pour l'ajouter, o il est représenté comme une forme géométrique.

Puis il convient d'ajouter les liens entre les objets métier en les matérialisant par des traits, - sur une troisième partie de l'écran d'affichage d'un ordinateur (Bloc 38), une liste de choix (Bloc 40) est affichée pour que l'utilisateur 15 précise comment il voudra voir les données (attributs) des objets métiers dans le système d'information en production.

Certaines activités classiques interviennent souvent dans les processus métier et, par conséquent, peuvent être prédéfinies et stockées dans un 20 répertoire puis, si besoin, une copie sera faite et ajoutée au flux de travail (Bloc 41).

Une activité prédéfinie permet de composer un flux de travail très rapidement. Elle contient des informations sur l'activité, le modèle de données et, de plus, l'écran de travail associé à cette activité - le cas 25 échéant - est prédéfini.

Les activités (Bloc 28) créées à partir d'activités prédéfinies peuvent correspondre à un ajustement (Bloc 42) visant à répondre exactement aux besoins de l'entreprise: ajustement du modèle de données, ajustement des 30 écrans de travail, etc. Cet ajustement est réalisé à partir d'une copie de l'activité prédéfinie faite dans le répertoire. Si l'activité prédéfinie répond déjà aux besoins de l'entreprise, alors il n'est pas nécessaire de procéder à cet ajustement.

Ensuite, dans la définition du flux de travail (Figure 4), il faut préciser le positionnement de chaque activité (Bloc 15): chaque activité nouvellement créée ou ajoutée à partir d'un répertoire d'activités a une place définie dans l'enchaînement du flux de travail.

Elles sont donc liées par des liens (Bloc 16) et des points de décision (Bloc 43).

Ces liens et ces points de décision permettent, lorsque le système est en statut test ou opération, de préciser quelles activités peuvent être effectuées à la suite d'une activité donnée. Des règles de décision sont définies pour 10 chaque point de décision.

Les activités suivantes peuvent ainsi être déterminées automatiquement suivant les règles de décision définies pour les points de décision (Blocs 16 et 43).

Par conséquent, en phase de production (statut " opération ") (Bloc 5), 15 l'utilisateur est complètement guidé entre les différents écrans de processus lorsqu'il travaille par exemple il passe d'une activité à une autre par des boutons de navigation du type " suivant " ou " précédent " qui lui indiquent quelles sont les activités possibles.

Cette forme de guidage est générée automatiquement à partir des liens (Bloc 20 16) et points de décisions (Bloc 43) dessinés lors de l'étape des spécifications électroniques (Bloc 1).

Une fois le flux de travail défini, l'étape d'assignation des responsabilités (Bloc 12) se déroule de la façon suivante Chaque activité de processus métier est exécutée par un ou plusieurs acteurs.

Chaque acteur dans l'entreprise a une ou plusieurs responsabilités appelées aussi " titre ". Par exemple: " Commercial " est le nom de la responsabilité assignée spécifiquement aux commerciaux de l'entreprise, " Agent Service 30 Client " est un titre d'un employé travaillant au service client.

Les titres sont définis pour chaque entreprise dans une étape de description de l'organisation de l'entreprise. Ils sont donc propres à chaque entreprise.

Dans cette étape, on précise pour chaque activité, le ou les titre(s) exécutant l'activité. On définit ensuite le ou les canaux d'exécution utilisés pour chaque flux

de travail (Bloc 13) c'est-à-dire une application interne, Internet, UMTS, fax...

Après cette dernière étape, la modélisation des processus métier est achevée, deux choix sont alors possibles: - si l'activité métier est destinée à un utilisateur, il y a définition et génération des écrans de travail (Bloc 9), - s'il s'agit d'une activité métier fonctionnant en arrière-plan telle qu'une 10 activité automatique ou assignée à un moteur d'activités automatiques pour laquelle il faut définir les règles d'exécution afférentes (Bloc 10).

Les écrans de travail (Bloc 9) sont générés: - soit automatiquement à partir des modes de représentation des objets 15 métier précisés lors de la définition des écrans et du niveau de visualisation par défaut des champs des objets métiers, - soit, si la représentation souhaitée ne correspond pas à un mode de représentation prédéfini, par la définition de la représentation souhaitée des objets métier et l'ajout des champs correspondant. 20 Une fois les spécifications électroniques réalisées, la génération du système d'information de la version n (statut test) (Bloc 2) est automatique et aboutit à un système prêt à exécuter les activités de l'utilisateur.

Le test de validation (Bloc 3) est lui-même un processus (Figure 9), permettant de faire valider les processus modélisés avant de passer en phase de production.

Ce processus de test peut comporter plusieurs étapes: 30. une définition des scénarios de test (Bloc 44) qui est une activité o les scénarios sont définis par rapport aux processus métier modélisés, * une validation de scénarios de test, cette activité étant optionnelle (Bloc 45), * une exécution des tests (Bloc 46), * un enregistrement des résultats (Bloc 47), * une analyses de résultats (Bloc 48), * si besoin l'exécution de nouveaux tests, * si les tests sont satisfaisants, le système d'information version test peut passer à l'étape de production (Bloc 5).

L'étape de mise en production (Bloc 5) est une activité permettant de mettre à la disposition des acteurs (utilisateurs) le système d'information fonctionnant suivant les processus métier'modélisés (statut opération).

Cette étape peut être elle-même un processus avec des étapes d'approbation sur un ou plusieurs niveaux avant d'autoriser la mise en production.

La génération de documentation peut être envisagée.

Pendant l'élaboration d'un système d'information classique, cette étape est séparée et en parallèle des spécifications alors que dans le procédé selon l'invention, elle découle des spécifications électroniques: elle est générée automatiquement.

La génération de la documentation à partir des processus modélisés selon le 20 procédé de l'invention est une garantie de qualité: on travaille toujours de la manière décrite et ce qui est écrit correspond toujours au flux de travail.

L'invention ne se limite pas à l'exemple précédemment décrit.

Par exemple, le système mettant en oeuvre le procédé selon l'invention pourra être connecté avec un EAI.

Il est à noter que le moteur de " workflow " (d'activités automatiques) décrit dans le procédé selon l'invention est plus complet qu'un moteur de 30 " workflow " classique. En effet, il est intégré avec le système d'information, généré selon le procédé, qui gère tous les processus aussi bien internes qu'externes.

Par exemple, dans le cas d'un processus extranet qui fait intervenir un moteur de " workflow " : Un client se connecte au site Web de l'entreprise, remplit un formulaire et en même temps veut communiquer avec les différents acteurs de l'entreprise. La communication Intemet sera immédiatement transmise au(x) acteur(s) concernés de l'entreprise. Ceci peut être fait en même temps que l'état du formulaire est modifié au cours 5 des différentes activités du processus. Un moteur de " workflow " classique ne sera pas capable de modéliser un tel processus. En effet, dans cet exemple, il y a deux processus métiers exécutés en parallèle: la communication avec des acteurs de l'entreprise et le suivi du formulaire. La communication n'est pas un processus faisant partie des processus du 10 " workflow ". Il ne peut pas être modélisé dans un moteur de " workflow " classique. Les moteurs de " workflow " classiques ne permettent que d'avoir une vision restreinte sur les parties des processus métier qui sont automatisées. Dans le système selon le procédé de l'invention, on est capable d'avoir une vision globale des processus de bout en bout, qu'ils 15 soient automatisés ou non.

Par ailleurs, un moteur de flux de " workflow " pourra parfaitement être connecté avec le procédé selon l'invention.

Claims (16)

Revendications

1. Procédé pour l'automatisation de la mise en oeuvre et la mise à jour d'un système d'information, caractérisé en ce qu'il comprend les phases suivantes: - une phase de spécifications électroniques (Bloc 1) correspondant à un premier statut d'une version donnée du système d'information et comprenant notamment une modélisation des processus métier (Bloc 8), ladite modélisation des processus métier comportant une définition 10 des flux de travail (Bloc 11) et une définition des responsabilités (Bloc 12), - une phase de génération automatique (Bloc 2) du système d'information à partir des spécifications électroniques correspondant à un deuxième statut d'une version donnée du système d'information, - une phase de mise en production (Bloc 5) correspondant à un troisième statut d'une version donnée du système d'information et comportant un déploiement automatique de ladite version opérationnelle du système d'information sur différents canaux d'exécution, - si une modification du système d'information est apportée après la mise en production, une phase d'adaptation (Bloc 7) comportant le retour à la phase de spécifications électroniques et ainsi la création d'une nouvelle version correspondant à un nouveau premier statut du système d'information, ce procédé gérant automatiquement, les uns par rapport aux autres, les statuts des différentes versions du système d'information.

2. Procédé selon la revendication 1, caractérisé en ce que ledit premier statut est un statut de spécification (Bloc 30 1), ledit deuxième statut est un statut de test (Bloc 2) et ledit troisième statut est un statut d'opération (Bloc 5).

3. Procédé selon la revendication 1, caractérisé en ce que les modifications apportées aux spécifications électroniques sont mises en oeuvre en temps réel.

4. Procédé selon la revendication 1, caractérisé en ce que la phase de spécifications électroniques comprend la définition des écrans de travail (Bloc 9) des différents utilisateurs et/ou des règles d'exécution d'activités automatiques (Bloc 10).

5. Procédé selon la revendication 1, caractérisé en ce que les spécifications électroniques comprennent une description détaillée avec une granulométrie très fine afin que toutes les informations permettant de générer le système d'information soient inclues.

6. Procédé selon la revendication 1, caractérisé en ce que, lors de la modélisation des processus métiers, un ou plusieurs canaux d'exécution de chaque activité sont définis (Bloc 13) afin de pouvoir générer automatiquement les éléments du système d'information adéquats.

7. Procédé selon la revendication 1, caractérisé en ce que la gestion et la distribution des documents de spécifications sont effectuées dynamiquement à partir des spécifications électroniques.

8. Procédé selon la revendication 1, caractérisé en ce que la phase de mise en production (Bloc 5) est précédée d'une phase de test de validation (Bloc 3).

9. Procédé selon la revendication 8, caractérisé en ce que ledit test de validation a lieu sur la version du système d'information en statut test.

10. Procédé selon la revendication 1, caractérisé en ce que des scénarios de test sont définis (Bloc 44) pour le test de validation.

11. Procédé selon la revendication 8, caractérisé en ce que, si le résultat du test est positif, la phase de mise en production (Bloc 5) du système d'information commence.

12. Procédé selon la revendication 8, caractérisé en ce que, si le test est négatif, il y a introduction de modifications (Bloc 7), retour à la phase de spécifications électroniques (Bloc 1) et répétition des phases suivantes jusqu'à ce que le test soit positif.

13. Procédé selon la revendication 1, caractérisé en ce que la modélisation des processus métier en tenant compte des canaux d'exécution de chaque activité entraîne, lors de la génération du système d'information, la génération d'éléments pour chaque canal tels que des écrans de travail, des fonctions de synchronisation.

14. Procédé selon la revendication 1, caractérisé en ce que la phase de mise en production (Bloc 5) comprend la réplication de la dernière version testée du système d'information sur un serveur de l'entreprise puis son déploiement automatique sur les différents terminaux ou postes clients.

15. Procédé selon la revendication 1, caractérisé en ce que ledit déploiement sur les postes clients est réalisé directement à partir d'un identifiant utilisateur donnant ainsi un accès restreint adapté à un certain nombre d'activités. 30

16. Procédé selon la revendication 1, caractérisé en ce que, lors de la génération d'un nouveau système d'information à la suite d'une modification par exemple d'un processus 22 métier, les postes clients détectent automatiquement une nouvelle version de système d'information et se mettent à jour.