SERVICE LEVEL AGREEMENT ENTRE ASTRID ET SES CLIENTS

Transcription

1 SERVICE LEVEL AGREEMENT ENTRE ASTRID ET SES CLIENTS VERSION : 1.9 DATE :

2 Table des matières 1 Introduction Catalogue des services ASTRID Service Centre Rôle et mission de l ASTRID Service Centre (ASC) Le Contact Center (ASC-CC) La 1ère ligne (ASC-1L) La 2ème ligne (2L) La supervision du réseau ASTRID Incident management Process Priorité Feedback pendant la résolution pour les Criticals Incident générant un Problem Niveaux de service pour le Resolution Time Incident de priorité Critical Incident de priorité Major Incident de priorité Medium Incident de priorité Minor Resolution Time Incident sur l infrastructure du client Incident sur l infrastructure de partenaire ASTRID Gestion des abonnés Gestion des demandes et des plaintes Problem Management Change Management Type de Change Maintenance préventive Coordonnées de contact Escalation Escalation pendant les heures de bureaux Escalation en dehors des heures de bureaux Maintenance planifiée : communication et information Service Windows Infrastructure du client Incident sur l infrastructure du client: Maintenance planifiée sur l infrastructure du client: Reporting Reporting Incidents Reporting Plaintes : Reporting Problems Reporting Changes Subscriber management Amélioration du SLA Résumé des tâches Tâches d ASTRID Tâches du client Dispositions concernant le paiement tardif ou le non paiement (et service minimum) ANNEXE GENERALE Introduction Escalation Escalation pendant les heures de bureaux Escalation en dehors des heures de bureaux Résiliation temporaire urgente d un terminal radio Le réseau électrique dans les CIC et la répartition des responsabilités Infrastructure du client ASTRID - Annexe 3 - SLA - version [1.9] [ ] 2/33

3 1 Introduction Ce document définit le Service Level Agreement (SLA) entre la société ASTRID et ses clients. Il définit les services, ainsi que les niveaux de qualité sur ces services, liant ASTRID à ses clients. Il définit aussi le cycle d amélioration continue d ASTRID : l évaluation avec les représentants du client de la qualité livrée, et la définition ensemble des actions à prendre, fera de ce document un document vivant, avec des versions à venir. Le Service Level Manager d ASTRID est responsable pour la gestion et les évolutions de ce document. Ce document est complété par l annexe Annexe générale du SLA entre ASTRID et ses clients. Note : Dans ce document, le terme client signifie un utilisateur (ou une organisation utilisatrice) d un service ASTRID. 2 Catalogue des services Le but du Catalogue des services est de définir exhaustivement les services fournis par ASTRID, ainsi que leurs criticités pour les clients ASTRID. Ce catalogue définit aussi le périmètre des responsabilités d ASTRID (scope of work) : tout service n étant pas inclus n est donc pas fourni par ASTRID. Pour chaque service, la criticité est appréciée en termes d impact qu a une indisponibilité du service sur la mission de secours et de sécurité menée par l utilisateur ASTRID. Impact critique : Impact non critique: l indisponibilité du service (ou d une fonctionnalité du service) empêche l utilisateur ASTRID (Policier, Pompier, Ambulancier, etc.) de mener à bien sa mission de secours et de sécurité. l indisponibilité du service (ou d une fonctionnalité du service) n empêche pas mais gêne l utilisateur ASTRID (Policier, Pompier, Ambulancier, etc.) de mener à bien sa mission de secours et de sécurité. Ce degré de gêne à la mission de secours et de sécurité a été subdivisé en différent niveau d impact (majeur, moyen, mineur) en fonction de l importance du service concerné. Cet impact déterminera (en partie) des délais d intervention dans le cadre de la maintenance corrective (définie dans les chapitres suivants). Les services et les fonctionnalités sont détaillés dans le document Catalogue des services. 3 ASTRID Service Centre L ASTRID Service Centre (ASC) est le Service Desk ASTRID. Il est le point de contact privilégié entre l utilisateur et ASTRID, pour des questions (Customer Request), demandes d informations (RFI), Incidents, demande de cotation (RFQ), plaintes : voir ci-après Rôle et mission de l ASC. L ASC est joignable par téléphone, , fax ou courrier. L ASC répond aux appels téléphoniques en maximum 30 s dans 95 % des cas. L ASC enregistre l appel du client comme «Service Call». ASTRID - Annexe 3 - SLA - version [1.9] [ ] 3/33

4 Chaque Service Call (catégorisé comme Incident, Customer Request, Rfi/RFQ, ou Plainte) reçoit un identifiant unique (Service Call Number). Une fois attribué, le Service Call Number est communiqué au client et est utilisé comme référence pour toute communication ultérieure. Le Service Call Number doit être employé par le client lors de toute communication avec ASTRID. Pour communiquer des Incidents, le client peut contacter l ASC tous les jours de l année, 24 heures sur 24. Pour communiquer les autres demandes (Customer Request, RFI, RFQ, Plainte) le client peut contacter l ASC les jours ouvrables de 8:00 à 17:00. Les coordonnées du ASTRID Service Centre sont : ASTRID SERVICE CENTRE Boulevard du Régent 54 Regentlaan B-1000 Brussel / Bruxelles Tél : Fax : Info@astrid.be Il est à noter qu en cas de overflow, l ASC est supporté par un Contact Centre externe. Au maximum 5% des appels sur 6 mois seront traités par ce Contact Centre externe. Ce Contact Centre externe sera en mesure de communiquer en néerlandais et en français. Lors de la communication avec le client, ce Contact Centre se présentera comme ne faisant pas partie d'astrid. 3.1 Rôle et mission de l ASTRID Service Centre (ASC) L ASC est le Service Desk mis en place par ASTRID. Il constitue la pierre angulaire des services délivrés par ASTRID à ses utilisateurs : l ASC assure la supervision des systèmes, prend les actions nécessaires au rétablissement du service en cas de panne et constitue le point de contact unique des clients pour les questions, plaintes et demandes diverses (Front Office). A cette fin, l ASC est constitué de généralistes capables d aborder un spectre de problèmes très large. L ASC n est donc pas constitué d experts pour chaque technologie ou application mise à disposition par ASTRID. Les questions et plaintes sont traitées dans les meilleurs délais par l ASC lui-même ou par des spécialistes internes voire des fournisseurs auxquels ASC fait appel. Pour ces raisons, l ASC n assure pas la mission de HelpDesk Applicatif en ce sens qu il ne délivre pas de support en temps réel (ou en ligne) concernant les applications et leurs fonctionnalités. L ASC est organisé autour de 3 services : Le Contact Centre (ASC-CC) Le Contact Centre assure les tâches principales suivantes, les jours ouvrables, durant les heures de bureau (08h-17h) : o La prise d appel des utilisateurs (Single Point Of Contact : SPOC) ; o La gestion des questions, des demandes d informations ; o La gestion des abonnements et des databases clients (subscriber management); o La gestion des plaintes (coordination des réponses) ; ASTRID - Annexe 3 - SLA - version [1.9] [ ] 4/33

5 o o L élaboration et la mise en œuvre de la communication vers les clients en cas d Incidents et de maintenances planifiées ; Le credit collection. L ASC-CC constitue dans tous les cas le point d entrée des utilisateurs. Les Incidents techniques sont directement transférés à l ASC-1L. Lorsque la capacité de l ASC-CC est dépassée, celui-ci est supporté (sur demande) par un Call Center téléphonique externe qui assure les prises d appels (enregistre l appel et le transmet ensuite à l ASC), et/ou la diffusion d information aux utilisateurs (contacts téléphoniques des clients sur base de listes pré-établies) La 1ère ligne (ASC-1L) La première ligne est composée d opérateurs qui assurent les tâches techniques suivantes 24/24h, tous les jours de l année : o o o o o la prise d appels pour les Incidents techniques, la classification et catégorisation de ces Incidents, la demande d intervention du ou des fournisseurs, le suivi de l intervention des fournisseurs (respects des SLA) jusqu à résolution de l Incident ; l information des clients lors de la résolution des Incidents techniques ainsi que o la supervision réactive des systèmes (monitoring) ; o o la gestion des Alertes (Incidents techniques détectés par les systèmes de supervision) ; le suivi et la coordination des activités de maintenance planifiées (maintenance préventive). La première ligne reprend, en dehors des heures de bureau, les tâches d information et de communication dévolues à l ASC-CC La 2ème ligne (2L) L ASC-2L est composée d ingénieurs qui assurent une présence 07h-18.30h ainsi qu une permanence «on call» en dehors des heures de bureau, tous les jours de l année. L ASC-2L assure les tâches suivantes : o monitoring proactif : analyse des alarmes mineures avant déclaration d Incidents ; o la gestion des Incidents : o diagnostique, corrélation avec les Incidents existants, corrélation avec les problèmes connus et les solutions standards, etc. gestion de l intervention des fournisseurs. la détection des «problèmes : l analyse proactive d Incidents menant à la déclaration de problème (Incidents récurrents, absence de «root cause») ; ASTRID - Annexe 3 - SLA - version [1.9] [ ] 5/33

6 o le suivi de l exécution de la maintenance évolutive (Changes) ; o l établissement de rapport d Incidents et statistiques ; o encadrement et formation de l ASC-1L ; o élaboration et maintenance des procédures opérationnelles (ASC) ; o identification de crise et gestion des Disaster Recovery Plan. L ASC-2L constitue le premier niveau d escalade pour les Incidents qui dépassent les capacités de l ASC-1L ou qui ne sont pas résolus dans les délais fixés La supervision du réseau ASTRID Les systèmes de supervision ASTRID permettent d être à l écoute des messages d alertes venant des réseaux ASTRID et ainsi d agir au plus vite sur les éventuels Incidents. Ce système couvre les composants critiques des réseaux, sans pour autant couvrir tous les composants : ainsi par exemple les stations de travail CAD, les stations de travail LCT, les terminaux Paging ne sont pas pour le moment supervisés. 4 Incident management Un Incident est tout événement qui cause une perte partielle ou totale d une fonctionnalité ou d un service ASTRID. Une dégradation de la qualité d un service ASTRID est aussi un Incident. Le but d Incident Management est de rétablir la fonctionnalité ou le service ASTRID aussi vite que possible, conformément au niveau de service convenu dans ce SLA. L ASC sera amené à, soit rétablir complètement le service endéans les délais prévu dans ce SLA, soit, si ce n est pas possible, mettre en place en accord avec l utilisateur un WorkAround. Le Workaround constitue une solution temporaire qui rétablit le service à un niveau acceptable pour le client. Lors de la communication d un Incident, le client sera amené à fournir à l ASC les informations nécessaires à l identification de l Incident, à son diagnostic et à la détermination de la priorité de l intervention. Au minimum les informations suivantes seront communiquées : ses coordonnées : Nom, Contact, Site la fonctionnalité ou le service impacté, la fonctionnalité ou le service est-il partiellement ou totalement indisponible, le client possède-t-il une alternative ou est-il bloqué. d autres questions pourront être posées par l ASC afin de mieux cerner l Incident. En particulier, pour les Incidents liés au CAD et à la couverture radio, les formulaires de «CAD problem report» et «Coverage Incident Report» pourront être utilisés et transmis à ASTRID par . Si le formulaire prévu n est pas employé ou si des informations essentielles y sont absentes, ASTRID contactera le client pour obtenir les informations nécessaires au traitement de l Incident. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 6/33

7 4.1 Process Un Incident est communiqué par téléphone, éventuellement suivie d un ou d un fax, par un client à l ASC. L ASC après analyse peut accepter ou refuser l Incident. Si refusé, l appel du client peut être catégorisé autrement qu un incident, comme par exemple Customer Request ou Plainte. Dès que accepté, l Incident est enregistré dans la base de données des Incidents (comme Service Call de type Incident), où il reçoit un identifiant unique (son Service Call Number). L ASC lui attribue aussi une priorité (Critical, Major, Medium ou Minor). Ces informations sont communiquées via un automatique d accusé de réception au client dès que ce Service Call de type Incident est enregistré. L ASC peut refuser l Incident pour différentes raisons : par exemple, s il s agit d un Incident pour un service qui n est pas offert par ASTRID, ou s il s agit d un doublon : le même utilisateur ou son service avait déjà signalé l Incident Un Incident peut aussi être créé par ASTRID, suite par exemple à une perturbation détectée via les outils de supervision des systèmes ASTRID. Dans ce cas, l ASC informe le client impacté dans maximum 30 minutes. L Incident est assigné à un Incident owner, qui sera responsable de la résolution de son Incident. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 7/33

8 Astrid Customer Astrid Service Center Start Customer reports an Incident Start Incident is received by Astrid Feedback no Incident accepted? yes Record incident Start Pro-actif incident monitoring yes Answer accepted? no Astrid internal Incident Mgmt proces End Incident closed by Customer End Incident closed by Astrid Diagramme Incident Management ASTRID - Annexe 3 - SLA - version [1.9] [ ] 8/33

9 Les différents statuts que peuvent prendre l'incident sont décrits ci-après : Assigned : L'Incident est enregistré et assigné à un owner, responsable de la résolution de l'incident. Work in Progress : L Incident owner poursuit alors le traitement de l Incident. L Incident owner pourra être amené à contacter le client pour obtenir des informations supplémentaires nécessaires à la résolution de l Incident. Waiting for Customer : L ASC attend des informations indispensables du client pour pouvoir continuer le traitement de l Incident : le compteur Resolution Time du SLA (défini ci-après) est suspendu tant que ces informations n'ont pas été communiquées. Resolved : L'Incident est résolu dès lors que le service est complètement rétabli. L ASC informe immédiatement le client quand l Incident est résolu : pour les Incidents Criticals, le feedback sera donné par téléphone et , pour les Incidents Majors et Minors, le feedback sera donné par . Suite à la résolution de l Incident, l ASC demande la confirmation du client pour clôturer l Incident. L incident n est pas clôturé à ce stade: le client dispose d un délai (voir ci-dessous) pour confirmer ou non le rétablissement du service. Closed : Un Incident résolu (Resolved) est mis en statut Closed dès lors que le client a confirmé que le service était rétabli. Sans réponse du client, l Incident est clôturé automatiquement dans un délai de : 3 heures pour les Incidents Criticals. 48 heures pour les Incidents Majors et Minors La récurrence avérée ou probable d un Incident ne constitue pas un obstacle à la clôture de celui-ci. Resolved with Workaround : Dans certains cas, il n'est pas possible de résoudre complètement un Incident soit parce que la cause profonde de l'incident n'est pas connue et une analyse en profondeur doit être réalisée, soit parce que l'élaboration d'une solution finale peut prendre plusieurs semaines, voire plusieurs mois (c'est en particulier le cas si de nouveaux développements software sont nécessaires). Dans la plupart de ces cas, il est possible au client de poursuivre sa mission soit parce que la gêne causée par l'incident est limitée soit parce qu il est possible de rétablir le service à un niveau acceptable (même si limité), et donc de résoudre partiellement l'incident au moyen d'une solution temporaire (Workaround). Dans ces deux cas, et avec l'accord du client, le statut de l'incident sera mis en «Resolved with workaround» même si l'incident n'est pas totalement résolu. S'agissant d'une situation temporaire, l'incident «Resolved with Workaround», ne sera pas clôturé (pas de statut «Closed»). L analyse de la cause structurelle de l incident et les corrections nécessaires sont réalisées selon le processus «Problem Management». Ce n est que quand une solution finale est implémentée que l Incident pourra être résolu (Resolved) et finalement clôturé (Closed).Un mail signifiant cette clôture sera envoyé au client. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 9/33

10 Assigned Work in progress Waiting for customer Resolved with work around Escalated to Problem Final solution implemented Incident management status flow Problem management Problem solution implemented Resolved Closed 4.2 Priorité Comme mentionné ci-avant, l ASC attribue une priorité à chaque Incident, en tenant compte de l impact défini au chapitre Catalogue des Services. Certains événements, comme par exemple la visite d un Chef d Etat dans une ville, peuvent aussi influer sur la priorité d un Incident. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 10/33

11 Il est par conséquent important pour le client de communiquer à ASTRID une semaine à l'avance les grands événements qui requièrent une attention particulière d'un point de vue de monitoring. Quatre niveaux de priorité seront gérés : Critical, Major, Medium et Minor. Un Incident de priorité Critical, Major, Medium ou Minor est généré quand l indisponibilité d un service résulte dans un impact Critique, Majeur, Moyen ou Mineur comme défini au chapitre Catalogue des Services. 4.3 Feedback pendant la résolution pour les Criticals Pendant la résolution d un Incident de priorité Critical, l ASC donne un feedback au client : une heure après la création de l Incident si le SLA est dépassé et l Incident n est pas encore résolu. Ce feedback sera assez succint et comprendra les points suivants : actions déjà entreprises, actions à entreprendre, estimation de la date de résolution. 4.4 Incident générant un Problem S il est suspecté que l Incident pourrait être récurrent, ou si sa cause ne peut être identifiée, même si l Incident est clôturé (status : Closed ), un Problem est généré pour plus d investigation. Si un Incident est résolu temporairement par l application d un Workaround (status : Resolved with workaround ), un Problem est généré afin d apporter une solution définitive. Dans ce cas, l Incident sera clôturé (status : Closed ) uniquement quand la solution du Problem sera implémenté. 4.5 Niveaux de service pour le Resolution Time ASTRID s engage sur le niveau de service décrit ci-dessous pour le «Resolution Time». o Le Resolution Time est défini comme : Resolution Time = Detection Time + Response Time + Repair Time + Recovery Time Detection Time Response Time Intervention Repair Time Recovery Time Resolution Time Start End o o Detection Time = délai nécessaire à la détection d un Incident par les systèmes de supervision. Il n y a pas de Detection Time si l Incident est communiqué directement par le client. Response Time = délai nécessaire ASTRID - Annexe 3 - SLA - version [1.9] [ ] 11/33

12 o o o à l enregistrement de l Incident, la classification (catégorie, priorité, etc.), la corrélation avec d autres Incidents existants, le diagnostic et la corrélation avec des problèmes et des solutions existantes (Known Errors), o au déplacement du technicien sur site ou à la connexion à distance. Repair Time = intervention sur site, le cas échéant, et dépannage des composants défectueux ou résolution des anomalies Software. Recovery Time = contrôle du fonctionnement et tests de rétablissement du service, enregistrement et communication au client par l ASC Incident de priorité Critical Tous les services et fonctionnalités «Critical» Resolution time < 6 heures pour 95% des Incidents Resolution time < 7 heures pour 100 % des Incidents LCT DSL connectivity Resolution time < 9 heures pour 95% des Incidents Resolution time < 10 heures pour 100 % des Incidents Paging Resolution time < 7 heures pour 95% des Incidents Resolution time < 8 heures pour 100 % des Incidents Incident de priorité Major Tous les services et fonctionnalités «Major» Resolution time < 24 heures pour 90% des Incidents Resolution time < 32 heures pour 100% des Incidents Incident de priorité Medium Tous les services et fonctionnalités «Medium» Resolution time < end of next business day pour 90% des Incidents Incident de priorité Minor Tous les services et fonctionnalités «Minor» Resolution time < 7 business days pour 100% des Incidents Resolution Time Les niveaux de services pour le Resolution Time sont garantis quand l intervention est de type Hardware Swap, sauf pour les interventions sur le projecteur et le mobilier dans le CIC. Les niveaux de services pour le Resolution Time sont des obligations de moyen quand l intervention nécessite un changement de configuration ou une modification du software, et pour les interventions sur le projecteur et le mobilier (table + moteur) dans le CIC. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 12/33

13 4.5.6 Incident sur l infrastructure du client Certains services offerts par ASTRID utilisent en partie l infrastructure du client. Par exemple, certains Dispatch/S utilisent le réseau HiLDE. Quand l incident sur le service ASTRID est la conséquence d un incident sur l infrastructure du client, le niveau de service pour le Resolution Time ne s applique pas. ASTRID est alors tributaire du temps mis par le client ou son sous-traitant pour remédier à la panne. Voir aussi le chapitre «13 Infrastructure du client» Incident sur l infrastructure de partenaire ASTRID Pour le service LBS/ANI-ALI, la mise à disposition des données par les opérateurs de Télécommunication est réglée via l arrêté royal du 27 avril 2007 portant sur les dispositions pour la fourniture de données de localisation pour des appels d urgence émanant de réseaux mobiles conformément à l article 107, 3, de la loi du 13 juin 2005 relative aux communications électroniques. Le niveau de service bout à bout pour le service LBS/ANI-ALI (performance, disponibilité et fiabilité des données) est limité par le niveau de service offert par les opérateurs Télécommunication pour la fourniture de ces informations. Les composants dont ASTRID a la charge sont, eux, soumis au SLA standard ASTRID. 5 Gestion des abonnés Les demandes non urgentes dans le cadre de la gestion des abonnés (subscriber management) sont traitées en 5 jours ouvrables: Exemples : activation d abonnement, changement de droits, changement de profil utilisateur, swap de terminal radio, résiliation définitive d abonnement. Les demandes d activation indiquées comme urgentes par le client sont traitées en 24 heures. A noter que ce service est facturé séparément. Les demandes urgentes de swap radio ou de résiliation temporaire, suite à la perte, le vol ou la panne d une radio, et quand le besoin opérationnel exceptionnel le justifie, sont traitées en 1 heure. Les éléments suivants doivent être fournis à ASTRID: pour le swap radio: o l ITSI, le TEI de la nouvelle radio o ASTRID doit être au préalable en possession des clés d authentification (paire REF-K), à fournir par le distributeur (exemple : AEG, Zenitel); pour la résiliation: o l ITSI et plusieurs autres éléments tels que décrits dans l annexe générale. A la demande des utilisateurs, la procédure de résiliation temporaire a été simplifiée quand l utilisateur demande de résilier temporairement et dans l urgence UN SEUL TERMINAL RADIO: cette procédure est détaillée dans l annexe générale de ce SLA. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 13/33

14 6 Gestion des demandes et des plaintes Une plainte ainsi qu une demande d information est aussi communiquée par le client à l ASC ou au Service Level Manager. ASTRID fait une distinction entre une plainte et un Incident : une plainte concerne les procédures, un collaborateur ou la société ASTRID ou un de ses fournisseurs, un Incident concerne une fonctionnalité ou un service ASTRID. Il est résolu rapidement dans le cadre de la maintenance corrective. ASTRID fournit une réponse formelle: en 15 jours ouvrables pour les demandes d information, en 20 jours ouvrables pour les plaintes. La réponse donnée par ASTRID contient : la description complète de la demande, le cas échéant, les actions déjà entreprises, le cas échéant, les actions à entreprendre, le cas échéant, l estimation de la date pour la réponse finale. La réponse finale pourrait être fournie dans un délai supérieur aux 15 ou 20 jours. 7 Problem Management Le but du Problem Management est de déterminer la cause structurelle ( root cause ) d un ou plusieurs Incidents, et de prévenir la récurrence des Incidents. Il ne s agit pas d une approche fire fighting comme c est le cas pour l Incident management. ASTRID analysera TOUS les Incidents, pour déterminer les cas donnant naissance à un Problem. Une composante importante dans le processus de Problem Management est la communication vers le client des Problems gérés, les Incidents liés, et les dates attendues de résolution. ASTRID communiquera avec les utilisateurs sur les Problems : voir chapitre Reporting pour plus d information. Ci-dessous, le processus Problem Management est représenté succinctement. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 14/33

15 Astrid Customer Astrid analyse Incidents and detect Problem feedback record Problem Problem management process Problem resolved Diagramme Problem Management Dans son Reporting, ASTRID informera le client des Problems gérés et de la relation entre les Problems et les Incidents. 8 Change Management Le but du Change Management est d utiliser une méthodologie et un processus afin de maîtriser l introduction des changements dans les systèmes ASTRID, et en particulier son impact sur la qualité du Service. Ci-dessous, le processus Change Management est représenté succinctement. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 15/33

16 Astrid Customer Astrid Service Center Start Autorised Customer sends RFQ/RFC Start Autorised RFQ/RFC is received Feedback no RFQ/RFC accepted? yes RFQ/RFC is recorded RFQ/RFC is prioritized yes Offer accepted? Offerings Mgmt Proces yes RFQ? no RFC Change initiated by ASTRID yes Implementaion accepted? Change Mgmt Proces no Implementation Acceptance signoff Billing Proces Invoice Diagramme Change Management ASTRID - Annexe 3 - SLA - version [1.9] [ ] 16/33

17 Une demande de cotation ou une demande de changement (RFQ : Request for Quotation, RFC : Request for Change) est communiquée par le client au Service Level Manager ASTRID. Dès que accepté, le RFQ/RFC est enregistré chez ASTRID, ou il reçoit un identifiant unique. ASTRID fournit ensuite au client en maximum 5 jours ouvrables un accusé de réception contenant l identifiant unique du RFQ/RFC, le délai et/ou la date d implémentation pour les Changes standards (voir ci-après Type de Change), le nom du Change Owner ASTRID qui sera l unique point de contact pour le client pour le RFQ/RFC, et résumant la demande du client. Une priorité pour le RFQ/RFC peut ensuite être définie ensemble entre le client et le Change Owner. S il s agit d une demande de cotation (RFQ), la demande est traitée par le Offer Management, qui propose une offre. Dès que l offre est acceptée par le client, le Change Management procède à l implémentation du Change. Le RFQ devient un Change, avec un identifiant unique, qui est communiqué au client. Si l implémentation du Change provoque une interruption du service, ASTRID informe le client avant l implémentation. Si l implémentation du Change ne provoque pas une interruption du service, ASTRID informe le client dans la mesure du possible. Lors de l implémentation du Change, ASTRID pourra demander la collaboration du client, par exemple pour : autoriser l accès aux techniciens aux locaux, effectuer des tests. Après l implémentation du Change, quand nécessaire, ASTRID effectue un Post Implementation Review avec le client : l objectif est de vérifier ensemble que le résultat prédéfini du Change est bien atteint, et si des actions d améliorations sont éventuellement nécessaires. ASTRID demande enfin la confirmation du client pour clôturer le Change : sans réponse du client, ASTRID clôture le Change après 10 jours ouvrables. Il est à noter que certains Change sont initiés par ASTRID. Dans les deux cas (Change initié par le client ou par ASTRID), le feedback que ASTRID s engage à donner est une composante importante de ce processus, notamment dans le cadre du Reporting (voir Reporting). 8.1 Type de Change ASTRID distinguera entre les Changes ponctuels (et donc non standards); standards : des points récurrents dont le contenu est connu de tous et pour lesquels ASTRID prendra un engagement en termes de durée d implémentation au cas par cas. Exemples de Change standard : changement de configuration o de l infrastructure de sécurité (Firewall), o des applications CAD. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 17/33

18 9 Maintenance préventive Afin d augmenter la disponibilité ses services et de réduire les activités de maintenance corrective, ASTRID contrôle la plupart des composants de ses réseaux dans le cadre de la maintenance préventive. Nous ferons référence à cette maintenance dans la suite de ce document dans les paragraphes sur la maintenance planifiée et le reporting. 10 Coordonnées de contact Comme il est apparu dans les chapitres précédents, le feedback donné par ASTRID au client est une composante importante de ce SLA. Pour permettre un feedback efficace, le client s engage à communiquer à ASTRID endéans un jour ouvrable toute modification de ces coordonnées de contact : personne de contact, téléphone fixe et téléphone mobile (GSM), , fax, adresse, et ce pour tous les types contacts, c'est-à-dire : contact jour, contact nuit, contact technique, contact facturation, contact Service Level Management. 11 Escalation Si les niveaux de service, dans le cadre d Incident Management, sur les quels ASTRID s engage dans ce SLA ne sont pas respectés**, le client peut utiliser le schéma d escalation ci-dessous pour contacter directement le Management ASTRID Ainsi, le responsable ASTRID peut prendre les actions nécessaires au plus vite. A noter que l Escalation se fait à un niveau hiérarchique raisonnablement semblable. Nous allons distinguer ci-après entre Escalation pendant les heures de bureaux et Escalation en dehors des heures de bureaux. ** : Le client utilise l Escalation si le Resolution Time est dépassé de 20% pour les Incidents Criticals et Majors. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 18/33

19 11.1 Escalation pendant les heures de bureaux ASTRID customer ASTRID Manager customer organisation Director Technique & Operations Manager customer organisation Customer Support Manager Customer ASC Les coordonnées des contacts ASTRID sont données dans l annexe générale du SLA Escalation en dehors des heures de bureaux ASTRID customer ASTRID Manager customer or customer Manager on duty Manager customer or customer ASC (2L) Customer ASC Les coordonnées des contacts ASTRID sont données dans l annexe générale du SLA. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 19/33

20 12 Maintenance planifiée : communication et information Dans le cadre de la maintenance planifiée (maintenance préventive et évolutive), lorsque l intervention provoque une interruption de service, l ASC informe par le client concerné : 3 semaines avant l intervention, et 24 heures avant l intervention. L ASC communique : le lieu, la date, le temps de l intervention le(s) service(s) interrompu(s) et la durée de l interruption les conséquences opérationnelles le signe de fin de maintenance pour le client la solution de back-up éventuelle. Le client confirme la réception du premier envoyé par l ASC endéans 1 jour ouvrable. Sans cette confirmation, l ASC recontacte le client par . Sans confirmation dans les 3 jours ouvrables après ce rappel, l ASC considère la réponse du client comme positive. Le client peut demander de reporter la date de l intervention à tout moment en cas d événement inopiné grave. Cette demande sera confirmée par par le client. L ASC sera le SPOC (single point of contact) pour le client ainsi que pour les techniciens en charge de la maintenance. A noter que pour les interruptions de services RCS (Radio), le CIC envoie un appel broadcast avant et après la coupure (cas de la GPI), en mentionnant : temps et durée de la coupure description des signes de début et de fin de la maintenance du point de vue de l utilisateur solution de back-up éventuelle mise en œuvre mesures prises par le CIC ou à prendre par l utilisateur en cas de prolongement imprévu de la durée de la coupure Service Windows Les Service Windows sont les fenêtres préférentielles de maintenance pendant lesquelles un Change planifié (maintenance évolutive) peut être implémenté. Comme mentionné plus haut, si l implémentation provoque une interruption du service, l ASC informe le client avant l implémentation. Implémentation Change avec interruption du service : RCS, CAD, LCT : entre 2:00 et 4:00, lundi à jeudi Paging : entre 9:00 et 12:00, samedi Implémentation Change sans interruption du service : entre 9:00 et 11:00, lundi à jeudi Service Window pour la région Bruxelles-Capitale : Implémentation de Change avec interruption de service : RCS, CAD, LCT: entre 04:00 et 06:00, mardi à jeudi. (Paging : entre 9:00 et 12:00, samedi) Implémentation de Change sans interruption de service : entre 11:00 et 16:00, lundi à vendredi ASTRID - Annexe 3 - SLA - version [1.9] [ ] 20/33

21 13 Infrastructure du client Certains services offerts par ASTRID utilisent en partie l infrastructure* du client. Par exemple, certains Dispatch/S utilisent le réseau HiLDE. En cas de maintenance sur cette infrastructure, le client informe l ASC. Cela permettra à l ASC de mieux répondre aux appels reçus des organisations utilisatrices, qui ne seront plus en mesure d utiliser certains service comme Disp/S, ANG/BNG, etc. * Cette infrastructure est détaillée dans l annexe générale du SLA Incident sur l infrastructure du client: Le client communique par téléphone à l ASC dès qu un tel incident est détecté, et lorsque cet incident est résolu techniquement Maintenance planifiée sur l infrastructure du client: Le client informe l ASC 3 semaines avant l intervention, et 24 heures avant l intervention. La date de l intervention, la durée, la conséquence sur le service seront communiqués. Le client informe l ASC quand l intervention est terminée. 14 Reporting Ce chapitre définit le Reporting qu ASTRID fournira au client Reporting Incidents ASTRID fournira les données suivantes concernant les Incidents : nombre total d Incidents non fermés, temps moyen de réparation, nombre et pourcentage endéans le niveau de service, temps moyen de retard par rapport au niveau de service. Ce reporting sera subdivisé par Système (RCS, CAD, LCT, PAGING), par Priorité Reporting Plaintes ASTRID fournira les données suivantes concernant les Plaintes : - nombre de nouvelles Plaintes, - nombre de Plaintes fermées, - les Plaintes encore ouvertes, - les Plaintes traitées avec retard, - temps moyen du retard Reporting Problems ASTRID fournira les données suivantes concernant les Problèmes : ASTRID - Annexe 3 - SLA - version [1.9] [ ] 21/33

22 - nombre de nouveaux Problems, - nombre de Problems fermés. - Problems encore ouverts, - temps moyen pour la disponibilité d un work-around, - temps moyen de résolution. Quand pertinente, l information sera subdivisée par Système (RCS, CAD, LCT, PAGING). Par Problem, les Incidents (impactant l utilisateur) qui y sont liés seront aussi listés Reporting Changes ASTRID rapportera sur l intégration des nouveaux sites TETRA. Cette information sera aussi fournie à la réunion de CCU : date estimée d intégration, date effective d intégration de nouveaux sites Subscriber management Dans ce paragraphe, nous rapportons sur les activités dans le cadre de la gestion des abonnés : terminaux radios, pagers et station LCT activés, et le total actif nouveau client activé, et le total actif changement des abonnements (désactivation, swap de terminal radio, etc.). Le cas échéant, le niveau de performance atteint sera intégré dans le rapport. 15 Amélioration du SLA Le SLA pourra être revu entre ASTRID et le CCU afin de l améliorer. 16 Résumé des tâches 16.1 Tâches d ASTRID Type Description Niveau de service Rapport ASC ASC/ Subscriber management/ Non urgent Temps de réponse (maximum) de l ASC aux appels téléphoniques Activation d abonnement, changement des droits, changement de profil utilisateur, swap de terminal radio, résiliation définitive. 30 s 5 jours ouvrables N Oui ASTRID - Annexe 3 - SLA - version [1.9] [ ] 22/33

23 Type Description Niveau de service Rapport ASC/ Subscriber management/ Urgent ASC Incident management/ Resolution Time Incident management/ Feedback Incident management/ Feedback Incident management/ Feedback Gestions des demandes (questions) Gestion des Plaintes Change management/ feedback Maintenance planifiée/ planning Change management/ Service Windows Reporting Activation urgente 24 heures Oui Résiliation temporaire urgente 1 heure Oui Swap urgent de terminal radio 1 heure Oui Overflow des appels vers Contact Centre externe Incident - Critical Incident - Major Incident - Minor L ASC tient le client informé pendant la résolution d un Incident Critical maximum 5% sur 6 mois les services Critical < 6 heures pour 95% des Incidents < 7 heures pour 100 % des Incidents LCT DSL connectivity < 9 heures pour 95% des Incidents < 10 heures pour 100 % des Incidents Paging < 7 heures pour 95% des Incidents < 8 heures pour 100 % des Incidents < 24 heures pour 90% des Incidents < 32 heures pour 100% des Incidents < 7 business days pour 100% des Incidents Feedback une heure après la création de l Incident si le SLA est dépassé et l Incident n est pas encore résolu Suite à une détection d Incident (via les outils du monitoring) l ASC informe l utilisateur impacté 30 minutes N Feedback après résolution de l Incident Immédiat Critical : tel + N Major et Minor : ASTRID fournit une réponse formelle en: 15 jours ouvrables Oui ASTRID fournit une réponse formelle en: ASTRID fournit un accusé de réception contenant : l identifiant unique du RFQ/RFC, le nom du Change Owner ASTRID, le délai ou la date d implémentation (Change standard), et résumant la demande du client. Intervention avec interruption de service : ASTRID informe le client avant l implémentation Voir paragraphe Service Windows dans ce document Reporting mensuel sur les Incidents, Plaintes, Problems et Changes N Oui Oui Oui 20 jours ouvrables Oui 5 jours ouvrables N 3 semaines et 24 heures N Voir paragraphe Service Windows dans ce document Voir paragraphe reporting dans ce document N N N ASTRID - Annexe 3 - SLA - version [1.9] [ ] 23/33

24 16.2 Tâches du client Un Incident est communiqué par téléphone à l ASC et éventuellement suivie d un ou fax. Pour un Incident au status Waiting for Customer, répondre au plus vite à l ASC. Le compteur Resolution Time est suspendu. Communiquer à l ASC une semaine à l'avance les grands événements qui requièrent une attention particulière d'un point de vue de monitoring. Maintenance planifiée : confirmer la réception de l reçu de l ASC en 1 jour ouvrable. Maintenance sur l infrastructure du client utilisé par ASTRID : o incident : informer l ASC dès qu un incident est détecté, et lorsque cet incident est résolu. o maintenance planifiée : informer l ASC 3 semaines et 24 heures avant l intervention. 17 Dispositions concernant le paiement tardif ou le non paiement (et service minimum) D après les termes des Conditions Générales, les clients disposent d'un délai de 30 jours après la date de facturation (indiqué ci-après comme "Échéance"). A. Si l utilisateur n a pas encore payé à l Echéance + 7 jours : o L utilisateur reçoit un coup de fil d ASTRID lui demandant la raison du retard et l invitant à régler la facture dans les plus brefs délais. o L engagement de paiement éventuel de l utilisateur est noté et lui est confirmé par écrit. B. Si l utilisateur n a pas encore payé à l'echéance + 20 jours : o ASTRID envoie une lettre à l utilisateur en indiquant le solde des comptes ainsi que les intérêts éventuels. C. Si l utilisateur n a pas encore payé à l'echéance + 30 jours : o ASTRID envoie une lettre recommandée en indiquant les intérêts à porter en compte et en signalant les suites éventuelles (réduction des connexions au service minimum) pour les utilisateurs. o Les cas concernés par cette situation seront exposés au CCU et ASTRID motivera sa position sur l application du service minimum (étape D et E ci-dessous) en demandant l avis du CCU. o ASTRID informera une personne de référence au ministère de tutelle. D. Si l utilisateur n a pas encore payé à l'echéance + 90 jours : o Les connexions sont réduites à un service minimum de niveau 1. E. Si l utilisateur n a pas encore payé à l'echéance jours : o Les connexions sont réduites à un service minimum de niveau 2. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 24/33

25 Schéma de mise en application du Service Minimum selon les étapes décrites ci-avant. Nonpaiement de N importe quelle facture B Quand Action Conséquences Pas de nouveaux abonnements, ni modifications d abonnements existants Radio Non Dispatching Non Frais de communicatio n C Suppression droits PSTN et appel individuel Plus d appel PSTN et individuel Non Abonnement radio Facture LCT D = 1er niveau de service minimum E = 2d niveau de service minimum Suppression droits PSTN - Oui Non making Suppression droits PSTN - Oui Non receiving Suppression droit appel individuel Oui Non - making Suppression droit appel individuel Oui Non - receiving Suppression SDS - making Oui Plus de statut, plus d AVL, plus de SDS Suppression SDS - receiving Oui Plus de transfert d event en bref vers radio Suppression Packet Data Plus de MDT Limitation du nombre de groupes (voir à un groupe unique!) Terminal disabling de 75 % des abonnements pris au hasard. Facturation de réactivation ultérieure. Soit 124 par radio. Encombrement! Toutes les communications sur un même canal! Nombre réduit de radio Complique la logistique pour le client. Emergency reste possible. Radio manquante, et frais ultérieurs de réactivation Conflit avec le standard radiocom D Browser : fermer l accès Firewall Non Wks inopérable D I/Mobile : suppression Packet Data radio Oui I/Mobile inopérable D DISP/S : déconnexion ADSLan ou Non Wks inopérable LL et fermer accès Firewall D DWS : idem radio subscriber Idem radio subscriber Possibilité d inhiber les fonctionnalités de management de com. Oui Abt paging D Suppression des RIC excepté 1 RIC commun pour tout le parc + frais administratifs de réactivation. Soit 124 par pager. Limite les possibilités de rappel (il faut rappeler tout le monde à chaque fois!) ASTRID - Annexe 3 - SLA - version [1.9] [ ] 25/33

26 ANNEXE GENERALE SERVICE LEVEL AGREEMENT ENTRE ASTRID ET SES CLIENTS VERSION: 1.2 DATE: ASTRID - Annexe 3 - SLA - version [1.9] [ ] 26/33

27 Table des matières 1 Introduction Escalation Escalation pendant les heures de bureaux Escalation en dehors des heures de bureaux Résiliation temporaire urgente d un terminal radio Le réseau électrique dans les CIC et la répartition des responsabilités Infrastructure du client ASTRID - Annexe 3 - SLA - version [1.9] [ ] 27/33

28 SLA entre ASTRID et ses clients v Introduction Ce document constitue l annexe générale du Service Level Agreement (SLA) entre la société ASTRID et ses clients (voir le document SLA entre ASTRID et ses Clients ). Il contient les chapitres qui peuvent être mis à jour indépendamment du document définissant le SLA lui-même. Le Service Level Manager d ASTRID est responsable pour la gestion et les évolutions de ce document. Note: Dans ce document, le terme client signifie un utilisateur d un service ASTRID. 2 Escalation Ce chapitre concerne le chapitre Escalation du document SLA, et contient les coordonnées des contacts ASTRID. 2.1 Escalation pendant les heures de bureaux ASTRID customer ASTRID Manager customer organisation Director Technique & Operations Manager customer organisation Customer Support Manager Customer ASC Fonction Nom Tél. GSM Director Technique & Christophe christophe.gregoire@astrid.be Operations Grégoire Customer Support Jacky Comblin jacky.comblin@astrid.be Manager ASC ASTRID - Annexe 3 - SLA - version [1.9] [ ] 28/33

29 SLA entre ASTRID et ses clients v Escalation en dehors des heures de bureaux ASTRID customer ASTRID Manager customer or customer Manager on duty Manager customer or customer ASC (2L) Customer ASC Fonction Tél. ASC Permanence ASC 2L Manager on-duty : en dehors des heures de bureaux Le client ou son responsable hiérarchique obtient les coordonnées de contact du Manager on-duty ASTRID auprès de l ASC 2 ème ligne. 3 Résiliation temporaire urgente d un terminal radio A la demande des utilisateurs, la procédure de résiliation temporaire a été simplifiée quand l utilisateur demande de résilier temporairement et dans l urgence UN SEUL TERMINAL RADIO. Cette procédure est décrite dans le diagramme suivant : 1. Le client appelle l ASC pour résilier de manière urgente mais temporaire 1 radio isolée. 2. L ASC enregistre la demande, ainsi que le nom, le numéro de matricule ou tout autre code d identification, l ITSI, ET le numéro de téléphone fixe pour confirmer la désactivation. 3. L organisation cliente est notifiée par automatique de cette demande. 4. L ASC appelle le numéro de téléphone fixe pour authentifier la demande. 5. Si confirmé, l ASC désactive le terminal radio, et l organisation cliente reçoit un de notification. 6. Si infirmé, l ASC ne désactive pas. L ASC informe le Service Level Manager de ce cas. 7. L organisation cliente est notifiée par de ce cas avorté. Conditions : 1. Cette procédure n est valable que pour la désactivation d UNE SEULE radio (par précaution). 2. Cette procédure est évaluée au terme d une période de 6 mois de test. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 29/33

30 SLA entre ASTRID et ses clients v 1.6 Urgent radio terminal deactivation process Astrid Customer Astrid Service Center Start: Radio terminal deactivation Urgent? No Send signed request by fax Subscriber management process Only 1 radio No Telephone ASC Record request + fixed phone number Confirmation by Telephone customer on fixed phone number Confirmed? yes Deactivate the radio terminal Confirmation by Do not deactivate Inform SLM Notification by End of process ASTRID - Annexe 3 - SLA - version [1.9] [ ] 30/33

31 SLA entre ASTRID et ses clients v Le réseau électrique dans les CIC et la répartition des responsabilités Ce chapitre explique la répartition des tâches et responsabilités concernant la fourniture d électricité dans le CIC. Chaque CIC est muni: d une cabine basse tension ; d un groupe électrogène ; d un switch automatique (ATS) ; de tableaux généraux basse tension (TGBT) situés à l extérieur du local technique ; d un (ou deux suivant le cas) UPS (onduleurs) ; d un tableau de distribution des circuits situé à l intérieur du local technique ; de deux racks Cherokee ; de deux UPS Blade Eaton ; d unités d air conditionné pour le local technique ; de CRAC (Computer Room Air Conditioning) pour racks spécifiques. Netstroom ALSB1 Generator EXTERNE GENERATOR EXTERNE GENERATOR ALSB5 ALSB2 UPS2 RDG UPS1 RDG ALSB2' ALSB4 EXTERNE GENERATOR FedPol ALSB 6 ALSB3' ALSB3 ASTRID Eaton UPS 1 Eaton UPS 2 Cherokee1 Cherokee2 230v Syst : PABX Telenet Routers Switches TCS, MDSC,.. WKS s 48V Syst : Paging DXT Backbone Fiber FIU/DN2 DCN CAD RC-216 Airco (230V) CAD RC-216 Servers (230V) ASTRID - Annexe 3 - SLA - version [1.9] [ ] 31/33

32 SLA entre ASTRID et ses clients v 1.6 Schéma électrique d un CIC: en vert : les éléments existants en rouge : éléments à venir suite aux recommandations de l audit phase 2 en gris : éléments à enlever suite aux recommandations de l audit phase 2 (quand les éléments en rouges seront ajoutés) : différentiels à enlever Generator : groupe électrogène de la Régie - maintenance assurée par la Police fédérale Externe Generator : prise de secours pour groupe électrogène mobile ALSB : tableau basse tension (Algemeen Laag Spannings Bord) UPS RDG : UPS de la Régie maintenance assurée par la Police fédérale UPS Eaton : UPS ASTRID pour services CAD Cherokee : UPS -48V ASTRID : répartition des responsabilités C est de la cabine basse tension que le courant est distribué aux équipements ASTRID. La cabine basse tension reçoit le courant du fournisseur d électricité de la Police fédérale. Cette cabine appartient à la Régie des bâtiments (ou au propriétaire des lieux comme la commune de Wavre pour le CIC Brabant Wallon par exemple). Le groupe électrogène, propriété de la Régie des bâtiments, intervient en cas de panne du réseau électrique, en d autres mots absence de courant dans la cabine basse tension. Le groupe est entretenu par la Police fédérale via Dalkia ou Cofely selon que l on se trouve en Flandre ou en Wallonie. C est donc la Police fédérale qui intervient sur le groupe en cas de panne (mineure ou majeure) par l intermédiaire de Dalkia ou Cofely pour assurer la continuité de service. Le switch automatique assure la transition entre courant réseau et groupe de secours. Ce switch est entretenu par la Police fédérale (via Dalkia, Cofely) et est propriété de la Régie des bâtiments. Dans les TGBT (hors local technique ASTRID) se trouvent divers départs électriques et notamment ceux destinés aux équipements ASTRID. Les TGBT appartiennent à la Régie et sont supervisés par la Police fédérale. Lors d un incident sur un départ d un TGBT, la Police fédérale est tenu d intervenir (via Dalkia ou Cofely) pour assurer la continuité du service. Les UPS «Régie» (UPS RDG) assurent la transition sans coupure électrique lors du basculement réseau vers groupe ou vice versa. Ces UPS appartiennent à la Régie des bâtiments et sont entretenus par la Police fédérale. C est donc la Police fédérale qui intervient sur les UPS en cas de panne (mineure ou majeure) par l intermédiaire de Dalkia ou Cofely pour assurer la continuité du service. Le tableau électrique situé dans le local technique ASTRID est repris sous UPS et alimente les différents racks du système réseau. Ce tableau, propriété de la Régie, est placé sous supervision de la Police fédérale. Tout incident dans ce tableau provoque un incident conséquent. Dans le schéma ci-dessus, ce tableau est représenté par le bloc ALSB3 / 3. L audit phase 2 décrit l emplacement d un deuxième tableau pour le local technique repris sous un deuxième UPS. Si l audit phase 2 est implémenté, la supervision du deuxième tableau (ALSB 6 dans le schéma ci-dessus) sera alors faite par ASTRID. ASTRID - Annexe 3 - SLA - version [1.9] [ ] 32/33