Schéma de l'architecture fonctionnelle PSMC

L'architecture fonctionnelle PSMC a été réalisée lors de la pré-étude 2004, dans une optique globale et à long terme.

Nous l'avons quelque peu adapté afin de donner une première vue sur la divergence entre les besoins fonctionnels couverts par le présent cahier des charges et l'optique globale de la pré-étude.

WORKFLOW

COUCHE D’INTERACTION MULTICANAUX CORRESP

ONDANCE E-MAIL TELEPHONE IVR/ACD KIOSQUE PORTAIL E-COLL ABORATION

FILE D’ATTENTE MULTI-CANAUX ROUTAGE MULTI-CANAUX

AUTORISATIONS GESTION UTILISATEURSIDENT/ AUTHEN

PLATE-FORME OPERATIONELLE AGENDA/

CALENDRIER

DESKTOP AGENTS

GESTION DES INTERACTIONS

SYSTEME DE

PAIEMENT CAMPAGNE CONTRÔLE

SATISFACTION

MAINTENANCE APPLICATION MONITORING QUANTITATIF

GESTION SLA GESTION

COMPETENCES

REPORTING PLATE-FORME DE SUPPORT

GESTION QUALITE GESTION

ORGANISATION

PLANNING

RECHERCHES SOURCES D’INFORMATION CMSDMSAUTRES

DOSSIER UNIQUE

CTI

Existant Inexistant

requis Inexistant optionel Hors scope Existant partiel

E.T. PSMC

Schéma n°5 – Architecture fonctionnelle – Source: pré-étude PSMC 2004

1.1.2 Couche d’interaction multi-canaux 1.1.2.1 Description

COUCHE D’INTERACTION MULTICANAUX CORRESP

ONDANCE E-MAIL TELEPHONE IVR/ACD KIOSQUE PORTAIL E-COLL ABORATION

FILE D’ATTENTE MULTI-CANAUX ROUTAGE MULTI-CANAUX

CTI

Schéma n°6 – Couche Multi-Canaux – (source : Pré- étude 2004)

Pré-étude

La couche des interactions multi-canaux est responsable de l’aboutissement des interactions. Le but de cette couche est de faire en sorte que toutes les interactions (qu’elles soient sous forme de correspondance, d’échange téléphonique ou par email, d’un accueil personnalisé ou enfin provenant d’Internet) soient captées et traitées.

Les deux fonctionnalités les plus importantes sont :

- la fonction de "Routage": Quel que soit son canal de provenance, l’interaction va être routée vers l’utilisateur qui est libre et dispose des capacités requises pour le traitement de l’interaction via ce canal;

- la fonction d’attente: Toutes les interactions ne pouvant être traitées immédiatement dès leur arrivée dans le système cette fonction devra faire patienter et transmettre le témoin à la fonction de routage dès qu’un agent se libère.

Remarque :

Etant donné que les fonctions de routage et d’attente sont optionnelles, le soumissionnaire veillera à proposer une solution permettant à la plate-forme PSMC d’interagir avec chaque canal dans un mode point à point au cas où ces options ne seraient pas levées.

1.1.2.2. Canaux d'interaction

Les canaux peuvent fonctionner dans les deux sens : "inbound" (interactions entrantes) et "outbound"

(interactions sortantes). Une interaction "outbound" peut être réactive (elle fait suite à une interaction entrante) ou, au contraire, proactive (dans le cadre d’une campagne d'information, p. ex.).

1.1.2.2.1. Correspondance papier

Les interactions peuvent arriver dans l’environnement PSMC via le canal correspondance.

Par correspondance, nous entendons, outre les lettres ou les autres supports papier, les fax.

Vu que ces documents devraient faire partie du Dossier Unique du demandeur, ils ne pourront être traités que de manière électronique dans l’environnement PSMC. Ceci signifie concrètement qu’une interaction qui arrive initialement en format papier ne pourra pas être traitée immédiatement dans l’environnement PSMC mais devra être préalablement digitalisée.

Situation actuelle

Un fax server est déjà utilisé au SPF Finances (Right Fax); celui-ci permet de router un Fax reçu vers une adresse e-mail spécifique en fonction au numéro de fax utilisé. Le fax reçu est

digitalisé sous format TIF ou PDF. Les documents reçus via ce fax server doivent être intégrés à la plate-forme PSMC.

La digitalisation de la correspondance papier ne doit pas être réalisée dans le cadre du présent cahier des charges, mais la correspondance préalablement digitalisée devra également être captée par la plate-forme PSMC et faire l'objet d'un routage.

1.1.2.2.2. E-mail

L’e-mail est une forme spéciale de correspondance. Un courrier électronique peut arriver dans l’environnement PSMC sous plusieurs formes:

- E-mail non structuré:

Il arrive via une adresse e-mail classique, le contenu n’est donc pas structuré. Le citoyen peut se servir d’une messagerie classique (programme ou webmail) pour initier son interaction avec le SPF Finances.

- E-mail structuré:

Ce type d’e-mail proviendra toujours du portail et présente deux caractéristiques qui sont la forme et la sécurité. La forme sera complètement définie par les formulaires que le citoyen utilisera pour rédiger son mail depuis le portail.

En d’autres termes, l’utilisateur de l’application PSMC recevra un e-mail dont il connaîtra la structure et le thème du contenu. De plus, pour l’envoi d’un e-mail structuré, une session sécurisée sera lancée sur le portail (HTTPS), permettant une transmission sécurisée du message via Internet vers le SPF Finances. Le web-Content management system transfèrera alors ce message au système e-mail qui, à son tour, le dirigera dans l’environnement PSMC.

L’e-mail jouera également un rôle de support pour les processus de workflow .

Situation actuelle:

Deux formulaires sont actuellement utilisés pour envoyer des e-mails structurés à partir de sites du SPF Finances, mais pas sous HTTPS.

Via le portail actuel (http://www.minfin.fgov.be), le citoyen qui ne trouve pas la réponse à sa question dans les FAQ's relatives à l'impôt des personnes physiques peut compléter un

formulaire qui va générer un mail structuré

(http://annuaire.fiscus.fgov.be/tow/index.php4?lang=fr&type_doc=fisc).

Un second formulaire, accessible via les pages d'aide du site taxonweb.be (http://annuaire.fiscus.fgov.be/tow/index.php4?lang=fr&type_doc=tow), permet au citoyen de poser soit une question fiscale (orientée vers le Contact Center du SPF Finances), soit une question relative à l'application taxonweb (accès, problème technique: orientée vers un autre CC compétent). Ces formulaires, ainsi que d'autres qui auraient été développés entre-temps, devront être intégrés dans la plate-forme PSMC.

Remarque: La création d'un nouveau portail pour le SPF Finances ne fait pas partie du présent cahier des charges.

1.1.2.2.3. Téléphone

Le volet téléphonie du présent cahier des charges est entièrement couvert par l'infrastructure du SPF Finances (TelLanNoga).

Situation actuelle:

La technologie actuelle est basée sur le Voice Over IP (voir détail dans l’annexe 9).

Le call center actuel (dédié aux particuliers) est accessible au public via un n° unique (0257 257 57 – tarif normal), auquel est lié l'IVR permettant au citoyen d'effectuer ses choix.

Outre ce numéro unique, des numéros spécifiques par langue, connus du public avant la création du call center, sont déviés via le call manager vers les files d'attente correspondant à la langue et au sujet concerné (versements anticipés ou taxe de circulation).

A noter que le projet TelLANoga prévoit l'extension de la téléphonie "voice over IP" à l'ensemble des implantations du SPF Finances, sur la base d'un seul système téléphonique.

1.1.2.2.4. IVR / ACD

IVR, acronyme de Interactive Voice Response, est une fonctionnalité permettant au citoyen d’effectuer, à l’entame de son interaction, des choix via les touches de son clavier. Suivant les choix effectués, le citoyen tombe sur des agents spécifiques capables de répondre à sa question ou de l’aider dans la résolution de son problème. Les choix proposés couvriront entre autres, le segment auquel le citoyen appartient, les thèmes dans lesquels sa question peut être rangée...

A terme, les fonctionnalités classiques de l’IVR pourront être élargies de manière à ce que ces choix ne doivent plus être manuellement introduits mais puissent être déduits par un système de reconnaissance des mots. La reconnaissance vocale et la transformation de mots reconnus ou codes en texte sont des fonctionnalités qui pourront être ajoutées.

Cette structure utilisée dans l’IVR pourra servir de base au développement des structures permettant de qualifier les interactions sur d’autres canaux.

Situation actuelle

Le volet IVR/ACD est entièrement couvert par l'infrastructure du SPF Finances (TelLanNoga).

Un IVR (Interactive Voice Response) et un ACD (Automatic Call Distribution) ont déjà été mis en place et configurés au SPF Finance dans le cadre du contact Center. Les logiciels utilisés sont décrits dans l’annexe 9.

1.1.2.2.5. CTI (optionnel)

L'intégration entre la téléphonie et la plate-forme PSMC permettra la récupération des données en provenance de la téléphonie et leur insertion dans l'interaction créée

automatiquement par la plate-forme PSMC (choix effectués dans l'IVR, clé d'identification éventuelle , n° d'appel,…).

1.1.2.2.6. Portail

Remarque:

La création d'un nouveau portail pour le SPF Finances ne fait pas partie du présent cahier des charges mais la plate-forme PSMC devra intégrer les e-mails structurés créés via les sites web du SPF Finances existants (voir C.1.1.2.2.2. E-mails).

1.1.2.3 File d'attente multi-canaux (optionnel)

Chaque interaction provient d’un canal physique (téléphone, e-mail, …) et est insérée dans une file physique (sur une centrale téléphonique, un serveur e-mail…) en attendant de pouvoir être traitée.

En marge de cette file d'attente physique propre à chaque canal, il existe également une file d'attente logique unique.

Pour chaque interaction entrante, (quel qu’en soit le canal de provenance), une interaction logique est créée, pointant vers l’interaction physique.

Les règles de routage (voir ci-dessous) décrivent la manière dont la file logique est gérée. Tant que le mécanisme de routage n’a pas réussi à attribuer une interaction à un agent (avec les compétences requises), l’interaction reste dans la file d'attente. Quand une interaction est attribuée à un agent, elle disparaît instantanément de la file d'attente logique et est transférée depuis la file d'attente physique vers l’agent (transfert de la communication téléphonique, envoi d’un e-mail…).

1.1.2.4 Routage multi-canaux (optionnel)

Le routage multi-canaux des interactions détermine, indépendamment du canal de provenance, quelle interaction de la file d'attente logique unique (voir file d'attente multi-canaux ci-dessus) va être traitée en priorité et par quel agent.

Ce routage s’effectue sur base de règles de routing : SLA (niveau de services) sur les différents canaux, priorités par canal/ segment / type d’interaction, exigences et compétences minimales / maximales / optimales pour pouvoir traiter un type donné d’interactions, …

Ces règles pour le traitement des interactions sont réévaluées en permanence et sont typiquement basées sur les informations suivantes:

• les informations concernant l’interaction: canal / segment / type de l’interaction, temps passé dans la file unique, numéro composé / adresse e-mail du destinataire, le numéro appelant et les choix dans l’IVR (dans le cas du téléphone), contenu des champs d’un e-mail structuré, informations sur le citoyen lorsqu’il est identifié ou sur son dossier (adresse légale, état d’avancement du traitement du dossier, profil de risque, …), …

• les informations sur les agents qui sont loggés dans le système: compétences des agents, groupes d’agents, la durée depuis laquelle un agent donné est libre,…

• autres informations comme par exemple l’heure, le jour, la date, les statistiques comme le nombre d’interactions dans la file d'attente, le temps d’attente moyen,…