FR 2871265 A1 20051209 FR 0504282 A 20050428 La présente invention concerne les services gérés et plus particulièrement la désagrégation de services dans des blocs de construction. Au fur et à mesure que l'importance et l'utilisa- tion des informations continuent à croître, les individus et le personnel commercial cherchent des moyens supplémentaires pour traiter et mémoriser les informations. L'une des options mises à la disposition des utilisateurs concerne les systèmes de traitement d'informations. Un système de traitement d'informations, d'une manière générale, traite, compile, mémorise, et/ou communique des in-formations ou données à des fins commerciales, personnel-les, ou autres, permettant ainsi aux utilisateurs de tirer avantage de la valeur des informations. Du fait que les besoins et exigences en technologie et traitement d'informations varient d'un utilisateur à un autre ou d'une application à une autre, les systèmes de traitement d'informations peuvent également varier en fonction des informations qui sont traitées, de la manière par la- quelle les informations sont traitées, de la quantité d'informations qui sont traitées, mémorisées ou communiquées, et du degré de rapidité et d'efficacité avec les-quelles les informations peuvent être traitées, mémorisées ou communiquées. Les variations des systèmes de traitement d'informations permettent aux systèmes de traitement d'informations d'être généraux ou configurés pour un utilisateur spécifique ou une utilisation spécifique telle qu'un traitement de transactions financières, les réservations de vols par avion, la mémorisation de données d'entreprise, ou les communications globales. De plus, les systèmes de traitement d'informations peuvent inclure une variété de composants matériels et logiciels qui peuvent être configurés pour traiter, mémoriser, et communiquer des informations et peuvent inclure un ou plusieurs systèmes informatiques, systèmes de mémorisation de données, et systèmes de gestion de réseau. Avec la prolifération des systèmes de traitement d'informations, spécialement dans les installations de systèmes de traitement d'informations de grande puissance, un important point concerne le service et la maintenance des installations de systèmes de traitement d'in-formations de grande puissance (c'est-à-dire les installations dans lesquelles de nombreux systèmes de traite- ment d'informations sont supportés par une entité unique. L'entité qui dessert et supporte une telle installation est souvent appelée fournisseur de services gérés. Les services gérés, ou les services de gestion de cycle de vie incluent d'une manière générale des services de dé- ploiement et des services de parc informatique. D'une manière plus spécifique, les services gérés incluent certains ou la totalité des services de déploiement et d'installation de parc informatique, des services de gestion de parc informatique (y compris, par exemple, à la fois les services de suivi et de déplacement de parc informatique), des services de maintenance de parc informa-tique et des services de retrait de parc informatique. Un fournisseur de services gérés fournit à un utilisateur une possibilité d'approvisionner, de dé- ployer, supporter et gérer des technologies de systèmes de traitement d'informations au cours du cycle de vie des systèmes de traitement d'informations. Les éléments concernant les services gérés incluent la logistique, la gestion d'informations et l'utilisation de parc informa- tique tout en fournissant la distribution de services de qualité et l'expérience favorable de la clientèle. Les fournisseurs de services gérés connus peuvent d'une manière générale être divisés en deux catégories: les fournisseurs de services gérés en interne et les fournisseurs de services gérés en sous-traitance. Les fournisseurs de services gérés en interne ont d'une manière générale de nombreux salariés présentent une définition des fonctions spécifiques pour fournir un service à un utilisateur particulier. Les fournisseurs de servi- ces gérés en sous-traitance utilisent d'une manière générale des fournisseurs de services tiers pour fournir un service à un utilisateur particulier du fournisseur de services. Certains fournisseurs de services gérés peuvent être un mélange des deux catégories générales; c'est-à-dire qu'un fournisseur de services gérés peut utiliser des salariés pour certains services et utiliser des fournisseurs de services tiers pour d'autres servi-ces. Selon la présente invention, on fournit un sys- tème de services gérés qui identifie et utilise des points de levier lors de la détermination indiquant si l'on fournit des fonctions de services en interne ou de services particuliers sous-traités. Le système des servi- ces gérés inclut des interfaces communes et normalisées vers des services de désagrégation. Le système de servi-ces gérés réduit les services à effectuer en tâches discrètes et répétitives qui peuvent être attribuées ou distribuées entre de multiples fournisseurs de services (ou une large variété de ceux-ci), en optimisant ainsi le nombre de candidats fournisseurs de services en identifiant le plus petit dénominateur commun des tâches. Le système de services gérés offre une structure qui supporte un ensemble diversifié de fournisseurs pour desservir un utilisateur particulier et dans la mesure où un meilleur fournisseur (par exemple, meilleur en termes de réglage ou coût fonctionnel) peut être activé sur une base par transaction. Par conséquent, la désagrégation de services dans un environnement de services gérés permet aux services et aux fournisseurs de services d'être personnalisés. Un tel système de services gérés réduit les coûts en créant des services et tâches répétitifs et en élargissant le groupe de fournisseurs potentiels et en réduisant la complexité des tâches et par conséquent les niveaux de qualification voulus des fournisseurs de services tiers. Dans un mode de réalisation, la présente invention concerne un procédé pour désagréger des services fournis par un fournisseur de services gérés qui inclut les étapes consistant à munir le fournisseur de services gérés d'un gestionnaire de collaboration de services, former une interface avec un utilisateur de services via le gestionnaire de collaboration de services, et former une interface avec un fournisseur de services tiers via le gestionnaire de collaboration de services. Dans un mode de réalisation, la présente invention concerne un dispositif pour désagréger des services fournis par un fournisseur de services gérés incluant des moyens pour munir le fournisseur de services gérés d'un gestionnaire de collaboration de services, des moyens d'interface avec un utilisateur de services via le gestionnaire de collaboration de services, et des moyens d'interface avec un fournisseur de service tiers via le gestionnaire de collaboration de services. La présente invention va maintenant être mieux comprise, et ses nombreux buts, caractéristiques et avantages vont mieux apparaître à l'homme du métier en se reportant aux dessins annexés. L'utilisation des mêmes références numériques de part et d'autre des dessins permet de désigner un élément analogue ou similaire, dessins sur lesquels: - la figure 1 représente un schéma fonctionnel d'un système de gestion de services, - la figure 2 représente un schéma fonctionnel du fonctionnement d'un système de gestion de services, - la figure 3 représente un schéma fonctionnel d'un système de traitement d'informations qui est utilisé dans un système de gestion de services et mis en service via celui-ci, - la figure 4 représente un schéma fonctionnel d'un schéma de document de services gérés, - les figures 5A, 5B et 5C, désignées d'une manière générale par figure 5, représentent un schéma fonctionnel d'un schéma d'incident de document de services gérés, - les figures 6A et 6B, désignées d'une manière générale par figure 6, représentent un schéma fonctionnel d'un schéma d'incident de service de services gérés, - la figure 7 représente un schéma fonctionnel d'un schéma de répartition de services gérés, - la figure 8 représente un schéma fonctionnel d'un schéma de réponse de répartition de services gérés, et - les figures 9A et 9B représentent des schémas fonctionnels d'un flux de document de services. En se reportant à la figure 1, on a représenté un schéma fonctionnel d'un système de gestion de services 100 dans un environnement de services gérés. Le système de gestion de services 100 permet la désagrégation de composants de service dans le système de gestion de services. En permettant la désagrégation en composants de service, le système permet le développement d'un groupe de fournisseurs de services potentiels, la transparence des fournisseurs de services, l'interchangeabilité des fournisseurs de services et la diversification des fournisseurs de services. Le système de gestion de services 100 inclut un module de gestionnaire de collaboration de services 110, un module de gestionnaire d'expérience de clientèle 112, une pluralité de modules de fabricants 114, une pluralité de modules de fournisseurs de services tiers 116 et un module administratif 118. Les utilisateurs 130a, 130b, 130c interagissent avec le système via le module de gestionnaire de collaboration de services 110. Le module de gestionnaire de collaboration de services 110 fournit une fonction de gestion conversationnelle, une fonction de routage de message et une fonction d'ouverture de session de transaction. Le module de gestionnaire de collaboration de services 110 inclut un fournisseur de services gérés vers un module d'utilisateurs (B2C) 140, un fournisseur de services gérés vers un module de fournisseurs (B2B) 142, un module de connectivité d'application 144 et un module de base de données 146. La pluralité de modules de fournisseurs de servi-ces gérés 114 incluent un module de services financiers 150, un module composants & logistique 152, un module de gestion de vendeurs 154, un module de support technique 156 et un module de fabrication 158. La pluralité des modules de fournisseurs de services tiers 116 incluent un module de tiers X 160 (qui représente tout type de service tiers), un module de composants & logistique tiers 162, un module de main d'oeuvre tierce 164 et un module d'assistance tierce 166. Le module administratif 118 exécute une pluralité de fonctions. D'une manière plus spécifique, le module administratif 118 permet l'accès entre les modules administratifs et le module de gestionnaire de collaboration de services 110. Le module administratif offre une fonc- tion de répartition de services, une fonction de demande détaillée d'étiquette SRV ainsi qu'une fonction d'état de répartition. Le module administratif 118 inclut un module de système de services 172. Chaque utilisateur 130 peut effectuer une ou plu- sieurs d'une pluralité de fonctions d'une manière interne dans l'utilisateur. Par exemple, un utilisateur peut exécuter une ou plusieurs fonctions parmi une fonction de ressources humaines 180, une fonction d'approvisionnement 182, une fonction de gestion de parc informatique 184 et une fonction d'assistance 186. Certains utilisateurs peu-vent n'exécuter aucune de ces fonctions d'une manière in-terne et par conséquent le fournisseur de services gérés effectue ces fonctions pour l'utilisateur. De plus, un partenaire de l'utilisateur peut exécuter une ou plu- sieurs de ces fonctions au nom de l'utilisateur. Un tel partenaire est considéré comme étant équivalent à l'utilisateur. En conséquence, le système de gestion de services 100 permet à un fournisseur de services gérés de minimi- ser la dépendance vis-à-vis d'un quelconque fournisseur donné. Toutes les interfaces d'utilisateur sont directes avec le fournisseur de services gérés, et pas avec les fournisseurs de services tiers. L'interface d'utilisateur inclut, par exemple, des informations du dossier de dé- faillances, des informations de demande de service, des informations d'approvisionnement de parc informatique, et des informations de facturation. Le fournisseur de servi-ces gérés contrôle toutes les informations concernant les utilisateurs; ces informations incluent des données pour permettre d'ajouter ou de remplacer des fournisseurs, des données pour autoriser les factures des utilisateurs et fournisseurs et des données pour résoudre les désaccords concernant les factures. Par exemple, ces informations peuvent inclure des informations concernant les parcs in- formatiques des utilisateurs, des informations concernant les contrats avec les utilisateurs, des informations d'historique de services des utilisateurs et des informations de facturation des utilisateurs. Le fournisseur de services gérés bénéficie directement des investissements en termes de développement technologique et capital in- tellectuel. De plus, le système de gestion de services 100 offre une solution évolutive pour permettre au fournisseur de services gérés de planifier les actions commerciales de sui,-i chez un utilisateur. De plus, le sys- tème de gestion de services 100 permet la gestion de flux de production en, p.r exemple, fournissant des pointeurs vers des instruct ris de travail discrètes et prédéfinies réduites à des 1u s de travail fondamentaux, qui peuvent être atteints par des fournisseurs de services indivi- duels. Le système de gestion de services 100 fournit une réalisation souple et adaptée des services par l'intermédiaire de l'intégration virtuelle de composants de servi-ces interchangeables obtenus via des services normalisés et des interfaces normalisées. Les exemples de composants interchangeables incluent le service d'exploration de parc informatique qui peut être réalisé par un quelconque fournisseur de services qualifié (par exemple, le fournisseur de services peut être désigné par l'utilisateur) ainsi qu'un outil de découverte de parc informatique qui est utilisé dans la réalisation du service et qui fournit toutes données voulues sur le parc informatique via une interface prédéfinie. Le système de gestion de services 100 prévoit une décomposition systématique des éléments d'une solution de service en éléments qui représentent des points de contrôle et de levier stratégiques et qui sont conservés dans le système de gestion de services. D'autres éléments, tels que des éléments de coût, peuvent être réduits à des composants appropriés qui peuvent être approvisionnés depuis l'extérieur à partir de multiples sources. Le système de gestion de services 100 réduit les services à réaliser en tâches discrètes et répétitives qui peuvent être attribuées ou distribuées entre de multiples (ou une large variété) fournisseurs de services, maximisant ainsi le nombre de candidats fournisseurs de services en fournissant le plus petit dénominateur commun des tâches. Le système de gestion de services 100 offre une structure (incluant une structure financière, une structure de définition de tâche, etc.) qui supporte un ensemble diversifié de fournisseurs pour desservir un utilisateur de services particulier. Dans la mesure où un meilleur fournisseur (par exemple, meilleur en termes d'adaptation et de coût fonctionnel) peut être activé sur une base par transaction, le système fournit la désagré- gation jusqu'au stade où des fournisseurs de services peuvent être sélectionnés via un échange commercial. Un tel système réduit les coûts en créant des services et tâches répétitifs et en réduisant la complexité des tâches, offrant ainsi un grand groupe de fournisseurs po- tentiels qui peuvent avoir un niveau de spécialité requis quelconque pour réaliser les tâches. En se reportant à la figure 2, on a représenté un schéma fonctionnel d'un exemple de l'opération de la désagrégation des fournisseurs de services dans un système de gestion de services. D'une manière plus spécifique, lorsqu'un utilisateur 130 désire accéder à une fonction d'assistance 166 dans le système de gestion de services 100 pour résoudre un problème d'utilisateur, l'utilisateur 130 prend contact avec le gestionnaire de collabora- tion de services 110 via une interface bien définie (étape 1). Le gestionnaire de collaboration de services 110 communique ensuite à son tour avec un fournisseur de services qui fournit la fonction d'assistance 166 via une autre interface commune bien définie. Le fournisseur de services d'assistance 166 analyse le problème soumis par l'utilisateur et peut déterminer, par exemple, que l'utilisateur a besoin d'un nouveau disque dur pour son système de traitement d'informations. Le fournisseur de services d'assistance 166 corn- munique avec un fournisseur de main d'oeuvre tiers 164 et un fournisseur de services de composants et logistique tiers 162 via le gestionnaire de collaboration de servi-ces 110 en utilisant l'interface commune bien définie (étape 2). Le fournisseur de main d'oeuvre tiers 164 et le fournisseur de services de composants et logistique tiers 162 exécutent ensuite l'élément de service indiqué par le fournisseur de services d'assistance 166, par exemple, le remplacement d'un disque dur d'utilisateur. Lorsque le fournisseur de main d'oeuvre tiers 164 et le fournisseur de services de composants et logistique tiers 162 activent l'installation du nouveau disque dur, alors le fournisseur de main d'oeuvre tiers 164 et le fournisseur de services de composants et logistique tiers 162 communiquent avec le fournisseur de services d'assistance 166 via le gestionnaire de collaboration de services 110 en utilisant l'interface commune bien définie (étape 3). Le fournisseur de services d'assistance 166 communique ensuite avec l'utilisateur via le gestionnaire de collaboration de services pour déterminer si le problème a été résolu (étape 4). Si tel est le cas, alors le fournisseur de services d'assistance 166 ferme l'élément correspondant au problème de l'utilisateur. Le fournisseur de main d'oeuvre tiers 164 et le fournisseur de composants et logistique 162 peuvent ou peuvent ne pas être le même four- nisseur tiers. En se reportant à la figure 3, on a représenté un schéma fonctionnel d'un système du traitement d'informations 300 qui est utilisé dans un système de gestion de services 100 et mis en service via celui-ci. Le système de traitement d'informations 300 inclut un processeur 302, des dispositifs d'entrée/sortie (E/S) 304, tels qu'un afficheur, un clavier, une souris, et des contrôleurs associés, une mémoire non-volatile 306 telle qu'une unité de disque dur, et d'autres dispositifs de mémorisa- tion 308, tels qu'une disquette et une unité de disque et d'autres dispositifs de mémoire, et divers autres sous-systèmes 310, tous connectés via un ou plusieurs bus 312. Dans le but de la présente description, un sys- tème de traitement d'informations peut inclure tout dis-positif ou ensemble de dispositifs opérationnels pour calculer, classer, traiter, transmettre, recevoir, récupérer, émettre, commuter, mémoriser, afficher, manifester, détecter, enregistrer, reproduire, traiter, ou uti- liser toute forme d'informations, intelligence ou de don-nées à des fins commerciales, scientifiques, de commande ou autres. Par exemple, un système de traitement d'informations peut être un ordinateur individuel, un dispositif de mémorisation de réseau, ou tout autre dispositif approprié et peut varier en taille, forme, performance, fonctionnalité et prix. Le système de traitement d'informations peut inclure une mémoire à accès direct (RAM), une ou plusieurs ressources de traitement telles qu'une unité centrale de traitement (CPU) ou une logique de corn- mande matérielle ou logicielle, une mémoire à lecture seule (ROM), et/ou d'autres types de mémoire non-volatile. Des composants supplémentaires du système de traitement d'informations peuvent inclure une ou plu-sieurs unités de disque, un ou plusieurs ports réseau pour communiquer avec des dispositifs externes ainsi que divers dispositifs d'entrée et de sortie (E/S), tels qu'un clavier, une souris, et un afficheur vidéo. Le système de traitement d'informations peut également inclure un ou plusieurs bus opérationnels pour transmettre des communications entre les divers composants matériels. L'interface d'utilisateur bien définie comporte une pluralité de schémas. Ces schémas fournissent la dé-finition du contenu d'un document. D'une manière plus spécifique, tous les documents qui sont envoyés et reçus par un utilisateur et le fournisseur de services gérés sont enveloppés dans une enveloppe de document. Dans un mode de réalisation, tous les messages envoyés par l'utilisateur et le fournisseur de services gérés ou reçus par ces derniers sont envoyés via le Protocole de Transfert de Documents Hyper Textuels via des stations de Protocole Sécurisé SSL. De plus, l'interface de fournisseurs de services tiers bien définie comporte une pluralité de schémas. Ces schémas fournissent la définition du contenu d'un docu- ment. D'une manière plus spécifique, tous les documents qui sont envoyés et reçus par un fournisseur de services tiers et le fournisseur de services gérés sont enveloppés dans une enveloppe de document. Dans un mode de réalisation, tous les messages envoyés par le fournisseur de services tiers et le fournisseur de services gérés ou reçus par ces derniers sont envoyés via le Protocole de Transfert de Documents Hyper Textuels via des stations de Protocole Sécurisé SSL. La figure 4 représente un schéma fonctionnel d'un schéma d'enveloppe de document de services gérés. D'une manière plus spécifique, le document de services gérés 400 inclut une étiquette IDEmetteur 410, une étiquette IDRécepteur 412, une étiquette facultative Erreur 414 et une étiquette ChargeUtile 416. L'étiquette ChargeUtile 416 inclut la charge utile réelle du document. La charge utile du document comporte une partie incident de service 420, une partie répartition 422, une partie réponse de répartition 424, et une partie état de répartition 426. L'étiquette IDEmetteur 410 et l'étiquette IDRé- cepteur 412 sont utilisées pour identifier l'émetteur et le récepteur du document 400. Lorsqu'un utilisateur en-voie des documents, l'étiquette IDEmetteur contient un identificateur qui identifie l'utilisateur et l'étiquette IDRécepteur contient un identificateur identifiant le fournisseur de services gérés. Si une erreur se produit lors de la réception ou du traitement d'un document, l'étiquette Erreur est ajoutée au document et le document est retourné à l'émetteur. En se reportant à la figure 5, on a représenté un schéma fonctionnel d'un schéma d'incident de services gérés 500. Le schéma d'incident de services gérés 500 est un exemple d'une implémentation de la partie incident de service 420. Le schéma d'incident de service des services gérés est conforme essentiellement à la Spécification d'Incident de service de Distributed Management Task Force (DMTF) telle que définie par la Société Distributed Management Task Force, Inc. de Portland, OR. Le schéma d'incident de service est utilisé pour instancier un Incident de Service. L'Incident de Service Instancié est un objet qui décrit un incident de service complet. Les étiquettes d'activité dans une partie de demande de service de l'objet Incident de Service décrivent divers évènements qui se produisent pour un incident de service. D'une manière plus spécifique, le schéma d'inci- dent de service de services gérés 500 décrit une étiquette MS_IncidentService correspondante 502 qui inclut une étiquette PRS Adresse 510, qui décrit l'entreprise où l'incident de service et éventuellement la répartition doit avoir lieu, une étiquette PRS_DemandeurService 512, qui décrit l'entreprise et la personne chez l'utilisateur qui fait l'objet de l'incident de service, une étiquette PRS FournisseurService 514, qui décrit les entreprises et la personne chez le fournisseur de services gérés qui traite l'incident et une étiquette MS DemandeService 516 qui décrit le problème concernant l'incident de service (conformément à la spécification DMTF, la référence PRS désigne la Norme de Résolution de Problème). L'étiquette MS IncidentService 502 inclut également une étiquette PRS Solution (non-représentée), qui agrège des informa- tions et la résolution concernant un problème. L'incident de service est ensuite divisé en une pluralité de types de demande: un type MS Interrogation 520, un type MS Commentaire 522, un type MS Informations 524, un type MS Problème 526, un type MS Projet 528 et un type MS IMACD 530. Le type MS IMACD 530 indique que la demande est une demande d'installation, de déplacement, d'ajout, changement ou de rejet. En plus des étiquettes décrites, l'étiquette MS IncidentService 502 inclut une pluralité d'éléments d'étiquette. D'une manière plus spécifique, l'étiquette MS IncidentService 502 inclut un élément d'étiquette TypeService (non- représenté), qui définit le type d'incident de service, un élément d'étiquette EtatCourant (non-représenté), qut désigne un état courant de l'inci- dent de service, un élément d'étiquette Gravité, qui dé-signe la gravité de l'incident de service, un élément d'étiquette Priorité, qui désigne la priorité de l'incident, un élément d'étiquette Transaction, qui définit la transaction de gestion de document. L'étiquette MS IncidentService 502 inclut également une étiquette IDCasDemandeur 540, qui fournit un identificateur unique pour l'incident assigné par le demandeur, une étiquette IDCasFournisseur 542, qui fournit un identificateur uni-que pour l'incident assigné par le fournisseur, une éti- quette IDDemandeur 544, qui fournit un identificateur unique de l'entreprise demandeuse, une étiquette IDFournisseur 546, qui fournit un identificateur unique de l'entreprise du fournisseur, une étiquette Commentaire 548, qui fournit des informations générales supplémentai- res concernant l'incident., une étiquette DateCréation 550, qui fournit une date à laquelle l'incident de service a été créé, et une étiquette DateFermeture 552, qui fournit une date à laquelle l'incident de service a été fermé. En se reportant à la figure 6, on a représenté un schéma fonctionnel d'un schéma de répartition de services gérés. Le schéma de répartition de services gérés 600 est un exemple d'une implémentation de la partie de réparti- tion de services 422. Le schéma de répartition de servi-ces gérés est essentiellement conforme à la spécification d'Incident de Service de la société Distributed Manage-ment Task Force (DMTF). Le schéma de répartition de services gérés 600 est utilisé par un fournisseur de services pour instancier et soumettre une demande de répartition au fournisseur de services gérés. La demande instanciée est un objet. Le schéma de répartition 600 inclut une étiquette MS Répartition 602 qui inclut une étiquette Données- Contrôle 610, une étiquette DonnéesDemande 612 et une étiquette DonnéesCommande 614. L'étiquette Données-Contrôle 610 inclut des informations permettant d'identifier la demande de répartition. L'étiquette DonnéesDemande 612 inclut des informations servant à identifier le demandeur de la répartition. Ces informations incluent un identificateur de système unique fourni par le fabriquant du système pour lequel le service doit être effectué tel qu'une étiquette Service qui est incluse dans l'étiquette EtiquetteService 620. L'étiquette DonnéesCommande 614 in- clut des informations concernant les composants associés à la répartition. Le schéma de répartition 600 peut aussi éventuellement inclure une étiquette Problème (non-représentée) qui inclut des informations concernant la raison de la demande de répartition. Le schéma de répartition 600 peut aussi éventuellement inclure une étiquetteParclnformatique (non-représentée) qui inclut des informations concernant le parc informatique pour lequel la répartition est demandée. Ces informations peuvent inclure l'étiquette de service du parc informatique ainsi que d'autres informa- tions d'identification de parc informatique telles qu'une ou plusieurs parmi le type de parc informatique, l'étiquette de parc informatique, le numéro de série de parc informatique, le parc informatique réalisé, le modèle de parc informatique, le secteur d'activité du parc informa-tique, la garantie du parc informatique et la période de garantie du parc informatique. En se reportant à la figure 7, on a représenté un schéma fonctionnel d'un schéma de réponse de répartition de services gérés 700. Le schéma de réponse de répartition 700 inclut une étiquette MS RéponseRépartition 702 qui inclut une étiquette TypeTransaction 710, une étiquette IDEmetteur 712, une étiquette NuméroContrôleMes- sage 714, et une étiquette MessageErreur 716. L'étiquette TypeTransaction 710 identifie si un envoi d'une demande de répartition ou une annulation de la demande de répartition a lieu. L'étiquette IDEmetteur 712 fournit un identificateur d'utilisateur. L'étiquette NuméroContrôle-Message 714 délivre à un utilisateur un identificateur unique pour la demande. L'étiquette MessageErreur 716 fournit le nom d'un champ d'erreur si une erreur se pro-duit. En se reportant à la figure 8, on a représenté un schéma fonctionnel d'un schéma d'état de répartition de services gérés 800. Le schéma d'état de répartition de services gérés 800 est utilisé par le fournisseur de services gérés pour délivrer à un utilisateur un état en cours d'une demande de répartition. Le schéma d'état de répartition de services gérés 800 inclut une étiquette MS EtatRépartition 802 qui inclut une étiquette TypeTransaction 810, une étiquette PSNuméro 812, une étiquette NuméroCommandeEchange 814, une étiquette DateFiled'Attente 816, une étiquette NuméroContrôleMessage 818, une étiquette IDEmetteur 820 et une étiquette Message 822. L'étiquette Message 822 contient de plus une étiquette PSMessage 830, une étiquette TRNMessage 832 et une étiquette REJMessage 834. L'étiquette TypeTransaction 810 désigne si la transaction est une demande de répartition ou une annula- tion de demande de répartition. L'étiquette PSNuméro 812 identifie le numéro de répartition du fournisseur de services gérés. L'étiquette NuméroCommandeEchange 814 indique un numéro d'échange d'un composant qui a été remplacé. L'étiquette DateFiled'Attente 816 identifie la date et l'heure de la demande d'origine de répartition. L'étiquette NuméroContrôleMessage 818 fournit un identificateur unique d'utilisateur pour la demande. L'étiquette IDEmetteur 820 fournit l'identificateur de l'utilisateur. L'étiquette Message 822 inclut l'un de trois sous-messages. L'étiquette PSMessage 830 fournit une zone de message d'état. L'étiquette TRNMessage 832 fournit une zone de message d'historique de transaction. L'étiquette REJMessage 834 fournit une zone de message de refus de répartition. En se reportant aux figures 9A et 9B, on a représenté des schémas fonctionnels d'un flux de document de service. D'une manière plus spécifique, le système de gestion de services 100 fournit un serveur mandataire entres utilisateurs 130 et fournisseurs de services tiers 116 pour tous les documents d'incidents de services. Tous les messages sont envoyés au fournisseur de services gérés et ensuite redirigés vers le récepteur prévu via des documents d'incidents de services individuels. Par exemple, en se reportant à la figure 9A, un utilisateur 130 envoie un document d'incident de service au fournisseur de services gérés 100. Le fournisseur de services gérés 100 détermine ensuite à quel fournisseur de services tiers 116 il doit envoyer le document sur la base du contenu de l'incident de service. Le fournisseur de services gérés 100 envoie ensuite le document au four- nisseur de services tiers approprié 116. De même, par exemple, en se reportant à la figure 9B, un fournisseur de services tiers 116 envoie des documents d'incident de service au fournisseur de services gérés. Le fournisseur de services gérés détermine à quel utilisateur il doit envoyer le document (par exemple, sur la base de l'étiquette PRS DemandeurService). Le fournisseur de services gérés envoie ensuite le document à l'utilisateur approprié 130. On va maintenant décrire d'autres modes de réalisation. La présente invention est bien adaptée pour atteindre les avantages mentionnés ainsi que d'autres avantages inhérents à celle-ci. Bien que la présente inven- tion ait été décrite, illustrée et définie en se reportant à des modes particuliers de réalisation de la pré-sente invention, ces références n'impliquent pas une limitation de la présente invention, et aucune limitation ne doit en être déduite. La présente invention peut subir des modifications, changements et équivalences considérables en termes de forme et de fonction, comme ceci va apparaître à l'homme du métier. Les modes illustrés et décrits de réalisation sont des exemples uniquement, et ne sont pas exhaustifs de la portée de la présente invention. Par exemple, les modes de réalisation décrits ci-dessus incluent des modules logiciels qui exécutent certaines tâches. Les modules logiciels décrits ici peu-vent inclure un script, un traitement par lot, ou d'autres fichiers exécutables. Les modules logiciels peuvent être mémorisés sur un support de mémorisation lisible par machine ou lisible par ordinateur tel qu'un disque dur. Les dispositifs de mémorisation utilisés pour mémoriser des modules logiciels selon un mode de réalisation de la présente invention peuvent être des disquettes magnéti- ques, des disques durs, ou des disques optiques tels que des CD-ROM ou des CD-R, par exemple. Un dispositif de mémorisation utilisé pour mémoriser des modules de micrologiciel ou des modules matériels selon un mode de réalisa- tion de la présente invention peuvent également inclure une mémoire à semi--conducteurs, qui peut être couplée d'une manière permanente, amovible ou à distance à un système de microprocesseur/mémoire. Par conséquent, les modules peuvent être mémorisés dans une mémoire de système informatique pour configurer le système informatique pour qu'il exécute les fonctions du module. D'autres nouveaux et divers types de supports de mémorisation lisibles par ordinateur peuvent être utilisés pour mémoriser les modules décrits ici. De plus, l'homme du métier va reconnaître que la séparation de la fonctionnalité en modules est effectuée à des fins illustratives. Des modes de réalisation en variante peuvent mélanger la fonctionnalité de multiples modules dans un module unique ou peu-vent imposer une autre décomposition de la fonctionnalité des modules. Par exemple, un module logiciel servant à appeler des sousmodules peut être décomposé de telle sorte que chaque sous-module exécute sa fonction et passe la commande directement à un autre sous-module. REVENDICATIONS 1. Procédé pour désagréger des services fournis par un fournisseur de services gérés (114), caractérisé en ce qu'il comporte les étapes consistant à : munir le fournisseur de services gérés (114) d'un gestionnaire de collaboration de services (110), effectuer un interfaçage avec un utilisateur de services (130) via le gestionnaire de collaboration de services (110), effectuer un interfaçage avec un fournisseur de services tiers (116) via le gestionnaire de collaboration de services (110). 2. Procédé selon la revendication 1, caractérisé 15 en ce que: l'interfaçage avec un utilisateur de services (130) a lieu via une interface bien définie. 3. Procédé selon la revendication 1, caractérisé 20 en ce que: l'interfaçage avec un utilisateur de services (130) inclut le routage de messages vers et depuis l'utilisateur de services (130). 4. Procédé selon la revendication 1, caractérisé en ce que. l'interfaçage avec un fournisseur de services tiers (116) a lieu via une interface bien définie. 5. Procédé selon la revendication 1, caractérisé en ce que: l'interfaçage avec un fournisseur de services tiers (116) inclut le routage de messages vers et depuis le fournisseur de services tiers (116). 10 30 6. Procédé selon la revendication 1, caractérisé en ce qu'il comporte de plus l'étape consistant à réduire des services à effectuer sous forme de tâches répétitives discrètes. 7. Procédé selon la revendication 6, caractérisé en ce qu'il comporte de plus l'étape consistant à attribuer les tâches discrètes répétitives entre de multiples fournisseurs de services (114, 116). 8. Procédé selon la revendication 6, caractérisé en ce qu'il comporte de plus l'étape consistant à supporter un ensemble diversifié de fournisseurs de services pour desservir un utilisateur (130) particu- lier en identifiant des services et tâches répétitifs dans le fournisseur de services gérés (114). 9. Procédé selon la revendication 6, caractérisé en ce que: la désagrégation permet de déterminer si une tâche particulière doit être effectuée dans le fournisseur de services gérés (114) ou la tâche particulière doit être effectuée via le fournisseur de services tiers (116). 10. Procédé selon la revendication 6, caractérisé en ce: les tâches discrètes répétitives correspondent à des objets de services respectifs. :30 11. Procédé selon la revendication 6, caractérisé en ce qu'il comporte de plus l'étape consistant à attribuer des fournisseurs de services tiers (116) sur une base par transaction, la base de transac-35 tion correspondant aux tâches répétitives discrètes. 12. Procédé selon la revendication 1, caractérisé en ce que: l'interfaçage avec l'utilisateur de services (130) inclut une pluralité de flux de travaux parallèles. 13. Procédé selon la revendication 1, caractérisé en ce que: l'interfaçage avec le fournisseur de services tiers (116) inclut une pluralité de flux de travaux parallèles. 14. Procédé selon la revendication 1, caractérisé en ce qu'il comporte de plus l'étape consistant à : coordonner une tâche entre de multiples fournisseurs de services tiers (116) via le gestionnaire de collaboration de services (110). 15. Procédé selon la revendication 14, caractéri- sé en ce que: la coordination d'une tâche entre de multiples fournisseurs de services (114, 116) inclut la communication avec la pluralité de fournisseurs de services tiers (116) via une pluralité de flux de travaux parallèles. 16. Procédé selon la revendication 14, caractérisé en ce que: la coordination d'une tâche entre de multiples fournisseurs de services tiers (116) est basée sur des moyens de détermination de fournisseur de services tiers. 17. Procédé selon la revendication 16, caractérisé en ce que: les moyens de détermination de fournisseur de services tiers incluent au moins l'un parmi le coût du fournisseur de services, l'emplacement géographique du fournisseur de services, la compétence du fournisseur de services, la dispcnibilité du personnel technique du fournisseur de services, le classement du fournisseur de services, la qualité du fournisseur de services et la préférence de l'utilisateur. 18. Dispositif pour désagréger des services fournis par un fournisseur de services gérés (114), caracté- risé en ce qu'il comporte: des moyens pour munir le fournisseur de services gérés (114) d'un gestionnaire de collaboration de servi-ces (110) , des moyens d'interfaçage avec un utilisateur de services (130) via le gestionnaire de collaboration de services (110), et des moyens d'interfaçage avec un fournisseur de services tiers (116) via le gestionnaire de collaboration de services (110). 19. Dispositif selon la revendication 18, caractérisé en ce que l'interfaçage avec un utilisateur de services (130) a lieu via une interface bien définie. 20. Dispositif selon la revendication 18, caractérisé en ce que les moyens d'interfaçage avec un utilisateur de services (130) incluent des moyens pour le routage de messages vers et depuis l'utilisateur de services (130). 21. Dispositif selon la revendication 18, caractérisé en ce que les moyens d'interfaçage avec un fournisseur de services tiers (116) ont lieu via une interface bien dé-finie. 22. Dispositif selon la revendication 18, caractérisé en ce que: les moyens d'interfaçage avec un fournisseur de services tiers (116) incluent des moyens pour le routage de messages vers et depuis le fournisseur de services tiers (116). 23. Dispositif selon la revendication 18, caractérisé en ce qu'il comporte de plus: des moyens pour réduire les services à effectuer sous forme de tâches répétitives discrètes. 24. Dispositif selon la revendication 23, caractérisé en ce qu'il comporte: des moyens pour attribuer les tâches répétitives discrètes entre de multiples fournisseurs de services (114, 116). 25. Dispositif selon la revendication 23, caractérisé en ce qu'il comporte: des moyens pour supporter un ensemble diversifié de fournisseurs de services (114, 116) pour desservir un utilisateur (130) particulier en identifiant des services et tâches répétitifs dans le fournisseur de services gérés (114). 26. Dispositif selon la revendication 23, caractérisé en ce que: les moyens de désagrégation permettent de déterminer si une tâche particulière doit être effectuée dans le fournisseur de services gérés (114) ou la tâche parti- culière doit être effectuée via le fournisseur de servi-ces tiers (116). 27. Dispositif selon la revendication 23, carac- térisé en ce que. les tâches répétitives discrètes correspondent à des objets de services respectifs. 28. Dispositif selon la revendication 23, carac- térisé en ce qu'il comporte: des moyens pour attribuer des fournisseurs de services tiers (116) sur une base de transaction, la base de transaction correspondant aux tâches répétitives discrètes. 29. Dispositif selon la revendication 18, caractérisé en ce que les moyens d'interfaçage avec l'utilisateur de services (130) incluent une pluralité de flux de travaux parallèles. 30. Dispositif selon la revendication 18, caractérisé en ce que les moyens d'interfaçage avec le fournisseur de services tiers (116) incluent une pluralité de flux de travaux parallèles. 31. Dispositif selon la revendication 18, caractérisé en ce qu'il comporte: des moyens de coordination d'une tâche entre de multiples fournisseurs de services tiers (116) via le gestionnaire de collaboration de services (110). 32. Dispositif selon la revendication 31, carac- térisé en ce que les moyens de coordination d'une tâche entre de multiples fournisseurs de services (114, 116) incluent des moyens pour communiquer avec la pluralité de fournisseurs de services tiers (116) via une pluralité de flux de travaux parallèles. 33. Dispositif selon la revendication 31, caractérisé en ce que: les moyens de coordination de tâche entre de mul- tiples fournisseurs de services tiers (116) sont basés sur des moyens de détermination de fournisseurs de servi-ces tiers. 34. Dispositif selon la revendication 33, carac- térisé en ce que: les moyens de détermination de fournisseurs de services tiers incluent au moins l'un parmi le coût du fournisseur de services, l'emplacement géographique du fournisseur de services, la compétence du fournisseur de services, la disponibilité du personnel technique du fournisseur de services, le classement du fournisseur de services, la qualité du fournisseur de services et la préférence de l'utilisateur.