QUALITY PARTNER FOR YOUR EXPANSION

1. T-SAS: T24 – Scramble, Archiving and Subset QUALITY PARTNER FOR YOUR EXPANSION

2. Réduire les coûts de stockage en déplaçant d’anciennes données hors ligne. Accroître l’efficacité en réduisant l’empreinte de données actives. Améliorer les scénarios de backup – Les petits paquets de données sont plus faciles à sauvegarder. Rapidité de temps de restauration – Des petits paquets de données sont plus rapides à restaurer. Améliorer les performances – Un petit ensemble de données rend d’indexation plus rapide et réduit les coûts d’extraction .

3. Répondre aux besoins de conformité – Les données sont préservé pour un accès ultérieur et sauvegardé. Pour conserver la performance (requête et COB) sous control après Go Live au-delà d’une période les données augmentent progressivement. Pour être en mesure de faire une copie d’un environnement (copie de production) plus rapidement et en réduisant sa taille Réduire de mise à jour et du temps de conversion des données.

4. Pourquoi l’archivage? 40% de TCCA peut être une estimation prudente! “Avec des taux de croissance supérieurs à 125% , les organisations sont confrontés à deux options: continuer à croître l’infrastructure ou développer des procédés pour séparer les données dormantes des données actives.” Source: Meta Group 2008

5. Pourquoi l’archivage?

8. …cela continue à ajouter Personnes Processus Technologie …et cela continue de diminuer Performance Disponibilité Temps pour d’autres projets Base de données De Production

10. Jusqu’à 80% des données dans la base de données OLTP de plus de 2 ans ne sont plus nécessaires pour l’activité quotidienne de la société. Les frais administratifs pour le stockage de 1To sont cinq à sept fois plus élevés que les coûts de stockage (Dataquest/Gartner). Suppression des anciennes transactions de la base de données active permettra de réduire les coûts et augmenter les performances des applications critiques. La majorité des banques ne contrôlent pas la croissance de la base de données sur une base quotidienne. Difficile de mettre en place l’archivage après 2 ans de croissance de la BDD, tant le temps d’arrêt est nécessaire pour le processus d’archivage avec la taille de la base de données.

11. 1200GB Test Production Total Développement Backup 200GB DisasterRecovery 200GB 200GB 200 GB 200GB 200GB Control de qualité Besoin actuel de données = Taille de la base de données de production + tous les clones dupliqués 200GB Formation

12. Archive Données Actuelle 1+ ans Historique Actif 2-3 ans Base de données De production Base de données des archives de rapports Archive Archivé / purge de la base de données Base de données de test

13. Base de données d’archive Fichiers archivés Base de données de production Fichiers archivés Accès aux données (localisation, navigation, recherche) purge • Réduit la quantité de données dans la base de données d’application • Supprimer les données obsolètes ou peu utilisées • Maintenir un “contexte business” de données archivées • Purger les fichiers archivés régulièrement pour en garder le contrôle • Permet aux utilisateurs un accès facile aux informations archivées • Voir, rechercher et restaurer selon les besoins • Soutien données et les stratégies de gestion de stockage de la banque

14. L’archivage est une solution orientée T24, cela réduit le nombre de fichiers Live ou de fichiers HIS en déplaçant les enregistrements en fichiers $ARC. Le processus actuel d’archivage standard et les paramètres couvrent uniquement une partie des fichiers T24 Core. Pour archiver les fichiers locaux et les fichiers Core, non inclus dans l’archivage standard (tables liées aux frais, tables liées aux AM, tables AA, etc) dont un développement local supplémentaire est nécessaire. Les tables sont classées en 3 catégories Tables Core (couvertes par le processus archivage Core) Nouvelles tables Core ( non couvertes par le processus d’archivage Core, nouveau dev local) Tables locales (non couvertes par le processus d’archivage nouveau dev local)

15. DE.O.HISTORY ../bnk.arc/de/DE.O.HISTORY$ARC Données On-line Archive Données On-line Espace vide

16. Le processus actuel d’archivage ne couvre pas tous les fichiers Core qui croient. Cette fonctionnalité est limitée dans les anciennes version T24. Le processus d’archivage existant est une application autonome qui déplace les données LIVE/HIS vers les tables $ARC mais rien d’autre. Ce n’est pas une solution pour une application autonome. Les banques ne peuvent pas l’utiliser tel quel. Lorsque l’archivage est fait, par défaut, il ne réduit pas la taille de la DB mais elle augmente, car l’espace vide n’est pas rendu par défaut. L’accès aux données archivées est transparent pour l’utilisateur, car ils ont besoin d’écrire des requêtes spécifiques pour accéder aux données des tables $ARC. Le paramétrage est limité (uniquement basé sur la Date), qui est une limitation énorme vu que de nombreuses tables n’ont pas le champ DATE.TIME (comme les concat files, fichiers live, etc.). Aucunes techniques de base de données ne sont utilisées dans l’ensemble du processus d’archivage. L’ensemble du processus d’archivage est manuel (configuration, l’exécution, le déplacement des tables, l’exécution du redimensionnement/réorganisation pour récupérer de l’espace, l’accès aux données ARC, etc.) Les fichiers $ARC ont coutume de ne pas être lors de la mise à jour de T24. Ainsi ces fichiers seront obsolètes après la mise à jour T24.

20. Utilisation optimale de stockage Conserver uniquement les données nécessaires dans un stockage à grande vitesse (ex: SDD), ce qui est coûteux. Retrait des données les moins accédées pour diminuer le coût de stockage de disque. Contrôle la croissance de la DB et dépenser moins sur l’infrastructure de stockage. Mise à jour du logiciel - Supporté La conversion automatique de temps d’exécution se produira, ce qui permet de convertir le format d’anciens enregistrements pour la release T24 actuelle. Aucune conversion nécessaire, ce qui est consommateur de temps. Pour lire les données archivées, une API standard est fourni qui peut être utilisé dans le développement local. Pas d’énorme problèmes de performance et c’est un simple champ de mapping de l’ancienne version T24 vers la nouvelle version T24.

21. Temporary TABLESPACE DATAFILE 1 DATAFILE 1 DATAFILE 1 Temporary DATAFILE TABLE A Free TABLE A Part 1 of 2 Copy of TABLE A Free TABLE A Part 1 of 2 TABLE B TABLE B TABLE B Copy of TABLE B TABLE C Copy of TABLE C TABLE C Part 1 of 2 TABLE C Part 1 of 2 TABLE D Copy of TABLE D Free DATAFILE 2 DATAFILE 2 TABLE A Part 2 of 2 TABLE A Part 2 of 2 TABLE C Part 2 of 2 TABLE C Part 2 of 2 TABLE D TABLE D Free Free • Utiliser Reorg pour optimiser les tables, les index et l’espace des tables après archivage: • La plupart des bases de données relationnelles supportent la Reorg ONLINE. • Le support Online de rétrécissement sous Oracle pour les tables XML et ses objets associés (index, segment LOB, etc.) • DB2 supporte une REORG Online pour une DB XML à partir de DB2 9.7 • Il n’est pas nécessaire d’arrêter la DB durant la REORG, les grandes tables peuvent être traitées en parallèle pour accélérer le processus. • Il est possible de redimensionner une DB jBase pour réduire la taille des tables. • Après la performance de la Reorgsera améliorée pour ces tables TABLESPACE TABLESPACE

22. Accès aux données archivées - Routines standards fournis pour accéder aux données archivées à partir de requêtes existantes. Elles liront les données archivées ou Live sur la base de la date indiquée. - Requêtes standards qui sont fournies ont été spécifiquement écrites pour les données archivées - Un ensemble d’API sont fournies pour prendre en compte les développements locaux avec une documentation claire. Fichiers/applications d’Interface de nettoyage - Il n’y a pas par défaut un nettoyage automatique pour les fichiers interfaces T24/fichiers de log/fichiers OFS. - Actuellement l’accumulation de données dans des dossiers partagés par les serveurs d’application T24 (NFS/GPFS) n’est pas traité. En conséquence, la taille totale et le nombre d’INODE se développent considérablement. Un mécanisme d’archivage empêche la croissance incontrôlée de ces fichiers. - Le service d’archivage va scanner les dossiers spécifiques fondés sur un ensemble de règles définies dans un fichier de paramètres. Le service a la possibilité de supprimer les anciens fichiers ou de créer des archives compressées. Exécutés quotidiennement, la quantité de données dans les dossiers sélectionnés se stabilisera. - Cela permet de garde les fichiers d’application propre et contrôlé, ce qui permet de réduire les temps de backup et de restauration ainsi que les besoins de stockage.

23. STOCKAGE DE DONNÉES ARCHIVÉES - Plusieurs options sont disponibles dans notre solution pour stocker les données archivées. - Les données archivées peuvent être conservées sous forme de fichiers de hachage jBase dans un système de fichiers distinct. Ce répertoire peut être ignoré durant les backups et les restaures. - Les données archivées peuvent être conservées dans un autre TABLESPACE si T24 tourne sous des serveurs ORACLE/DB2/SQL. Ce TABLESPACE peut être conservé dans des disques moins coûteux et peut être ignoré dans les backups et les restaures. - Les fichiers de données archivés peuvent être conservés dans un autre schéma au cas où T24 tourne sur un server ORACLE / DB2 / SQL. Ce schéma peut être conservé sur des disques moins coûteux et peut être ignoré lors de backup et de restaure. - Les fichiers de données archivés peuvent être conservés dans une base de données différentes et accessible via un environnement T24 différent.

24. PRODUCTION UTILISATEUR PRODUCTION UTILISATEUR WAS WAS MQ/TCPIP MQ/TCP T24 T24 PROD TS Scénario normal PROD DB

25. UTILISATEUR ARC PRODUCTION UTILISATEUR WAS WAS Menu Restreint – Données Live Menu restreint – Données d’Archive MQ/TCP MQ/TCP T24 T24 Libre PROD TS ARC TS Après le scénario d’Archive PROD DB

26. Création d’une autre TABLESPACE ne compromet en aucune façon la sécurité de la base de données, dès sa mise en place qui s’appuie entièrement sur les fonctionnalités de base de données et suivre la conception T24. Un TABLESPACE est un ensemble de volumes sur des disques qui possèdent les ensembles de données dans lesquels les tables sont effectivement stockées. Tous les tableaux sont conservés dans les TABLESPACE. Un TABLESPACE peut contenir une ou plusieurs tables. Avantages: //Toutes les données T24 se trouvent sur la base de données. //Résistance à la corruption de données. //Capacité à utiliser les fonctions des bases de données comme la compression TABLESPACE/le cryptage pour de plus petites tailles de bases de données. //Le TABLESPACE peut résider sur des disques séparés moins coûteux (SATA); d’où, cela n’affectera pas les performances de la base de données principale. //Les backups quotidiens n’incluent pas ces TABLESPACE. Inconvénients: //La taille du TABLESPACE va continuer à croître. En conséquence, une autre procédure de purge avec une période de rétention des données archivées doit être élaborée afin de garder la taille du TABLESPACE stable sur le long terme. //Le script actuel de backup doit être modifié pour exclure les TABLESPACE ARC du processus de backup quotidien.

27. PRODUCTION UTILISATEUR ARC UTILISATEUR Menu Restreint– Données Archivées WAS WAS Menu Restreint– Données Live MQ/TCP MQ/TCP T24 T24 Libre PROD TS ARC TS Après le scénario d’Archive DBLINK / FEDERATED SERVER PROD DB ARCHIVE DB

28. Les fichiers ARC peuvent être conservés sur un serveur à distance et accessible depuis le serveur de production via des options de connexions comme dbLink ou DB2 Federated ou JRFS (jBaseremote file system). Avantages: //Pas de changement dans les scripts courants pour le backup et le restaure de la DB de production. //Fonctionne comme une base de données indépendante, l’administration de DBA sera plus facile. //La sécurité des données n’est pas compromise à la fois sur la DB de production que la DB d’archivage sur la même instance DB de production. //Fonctionne de manière transparente sur DB2/ORACLE/JBASE. Pas de patchs majeurs, de configuration, changements nécessaires à la configuration serveur fédéré/DBLINK/JRFS. //La DB d’Archive sera sur un système de fichiers séparé sur des volumes de disques moins coûteux (disques SATA), de sorte qu’il sera un système à faible coût. //Une même DB d’Archive peut être partagée entre de nombreux environnements T24 ce qui permet d’éviter l’utilisation de stockage pour chaque environnement. Inconvénients: //La structure des données T24 sera fragmentée, une partie sera stockée sur la DB de production et une autre partie sur une autre DB. //La création de nouvelles tables est possible sur une DB distante T24, les tables peuvent être déplacées manuellement vers une DB distante puis la liaison doit être établi entre la DB de production et la DB distante. //La performance sera affectée (5 fois plus lent par rapport à la conservation des données sur la même DB). //La création d’Index ne fonctionne pas depuis un serveur fédéré vers une DB distante.

29. PRODUCTION UTILISATEUR ARC UTILISATEUR WAS WAS Menu restreint – Données Live Menu restreint – Données Archivées MQ/TCP MQ/TCP GPFS / NFS / JRFS T24 T24 ARC Files as J4/JR Libre PROD TS Après le scénario d’archive PROD DB

30. Avantages: //Fichiers structurés pour chaque table ARC. En conséquence, il serait plus facile et rapide de restaurer et de travailler avec uniquement les données nécessaires pour le Business. //Possibilité de faire des fichiers jBase distribués. Par exemple, il est possible de faire un fichier distribué par date (par exemple, par années pour les fichiers STMT et de Delivery), ainsi chaque fichier contient les enregistrements regroupés par année. Les plus anciennes parties de ces fichiers peuvent être mis sur bande puis supprimées. Sur demande, la partie du fichier peut être facilement récupérer et utilisée par T24 par requêtes. Il peut y avoir jusqu’à 254 parties définies par fichier. Donc la purge de fichiers sera plus facile . //La taille de fichiers sera 50% plus petite en comparaison des tables DB, car il n’y aura pas un quelconque format XML. //Simple mécanisme de hashage de fichiers, pas de licence supplémentaire nécessaire. Facile à administrer. //Pas de changements dans les scripts de backup et de restore de DB, peut être facilement géré par des options tar / gz. Inconvénients: //La structure de données T24 sera fragmenté, une partie sera stockée sur DB, et une partie sur les tables de fichiers. //Pour la distribution de fichiers et la gestion des parties des fichiers, une procédure doit être développée en incluant: La préparation de routines DISTRIB pour les fichiers ARC. La préparation d’un script sur base annuelle pour compresser et mettre sur bandes les plus anciens fichiers pour tous les fichiers ARC concernés sur la base de période de rétention des archives, et de les remplacer sur les disques par des parties de fichiers vides. Définir une procédure pour restaurer les parties de fichiers et les déposer temporairement sur disque, ainsi l’utilisateur sera en mesure d’interroger les anciennes données T24. //Risque de corruptions de données..

31. UTILISATEUR ARC PRODUCTION UTILISATEUR WAS Menu Restreint – Données Live EXCEL / CRYSTAL REPORTS / BUSINESS OBJECTS / TODD Menu Restreint – Données Archivées MQ/TCP DRIVER / ETL T24 T24 Connexion jRFS Après scénario d’archive Free PROD TS ARCHIVE DB PROD DB

32. SCRAMBLING

33. Introduction Le but principal de cet outil est de scramblé une base de données T24 tout en maintenant l’intégrité des données de la plate-forme. L’anonymisation des données sensibles comme (l’adresse des clients, nom, les champs KYC, et des portefeuilles reconnaissables) dans diverses tables sera réalisée par cet utilitaire. L’objectif d’un tel exercice est de fournir une base de données « scramblé »en dehors du pays hôte ou accueillir l’environnement scramblé mais permettre un accès transfrontalier à cet environnement. L’outil a été développé en langage de programmation T24 (j-basic) et est conçu pour fonctionner en mode multi-thread, en maximisant l’utilisation des ressources du serveur. Le Data masking est un mécanisme préconstruit qui peut être exécuté pendant le processus SUBSETTING ou STANDALONE. Masquer les données sensibles dans les bases de données de non-production. Entièrement piloté par des paramètres. Scrambler ou crypter toutes les données dans une table T24 (standard ou non-standard).

34. Méthodes de masquage Encryptions intégrées Simple algorithme de Scrambling (masquage du nom des clients par XXX) Réglage automatique de la longueur des champs. Mise à jour facilement configurable des fichiers concat pour les champs sensibles Facile extension pour inclure vos propres méthodes. Désidentifier les données sensibles Information sur les employés Information sur les clients Information des fournisseurs Parfait pour la formation, le testing, les bases de données de développement. Bon pour le développement offshore. Paquets précompilés Basé sur les meilleures pratiques suivies par la plupart des banques, la majorité des champs applicatifs sensibles sont mappés par défaut. Champs supplémentaires doit être mappé comme champs LOCAL.REF, tous les champs sensibles core sont déjà mappés. Couvre tous les principaux modules T24 dans le paquet pré-construit.

35. Identifie automatiquement tous les fichiers associés tels que $NAU, $HIS, $ARC ou $SIM sont également scramblés. Prise en charge de valeurs aléatoire tels que la DATE, MOIS, ANNEE ou autres listes de valeurs depuis le répertoire SAVEDLISTS Prend en charge l’encryption, l’encryption par défaut est XOR. Une encryption complexe peut être faite en utilisant l’option SUBROUTINE Règle la longueur automatiquement par dictionnaire ou par longueur de la valeur originale. Si PC file est disponible pour une application donnée, alors le contenu de PC file sera également scramblé. Concat Files configuration, which will be updated automatically

37. Scrambling dynamique / Le scrambling dynamique permet de MASQUER/SCRAMBLER les informations sensibles à la volée dans la base de données de production. / Au niveau de la vue utilisateur, les informations scramblées en mode SEE sur les champs sensibles. / Utilise la même fonctionnalité SAS.SCRAMBLE.PROFILE, avec une API simple qui appelle un scrambling dynamique disponible sur tous les écrans VERSION. Parfait pour les utilisateurs externes, entrepreneur, employés et gestionnaires de comptes pour accéder au contrôle aux données sensibles sur la base de données de production.

38. Monitorer les privilèges d’accès Il y a beaucoup d’utilisateurs privilégiés inconnus dans une banque. Les administrateurs système, les utilisateurs ayant accès à du contenu sensible notamment sur ces comptes où l’activité devrait être suivi de près, comme l’environnement de production. Pour savoir ce qu’ils font vraiment de leurs accès, il est obligatoire de suivre leurs activités. Suivre les partenaires externes Certaines banques ont plus d’utilisateurs externes que d’utilisateurs internes. Ils ne peuvent pas les contrôler avec leurs politiques courantes: le suivi et le contrôle de leurs activités est une obligation. Respecter les normes industrielles et internationales L’audit de conformité est une des tâches des plus pénibles de nombreuses banques. Les régulateurs externes du gouvernement ou d’organisations internationales peuvent vérifier qui est conforme aux normes obligatoires. Les données sensibles doivent être protégées et tout accès en arrière plan des sources de données doit être étroitement surveillé et contrôlé.

39. Accès T24 L’accès aux applications T24 est complètement contrôlé par le système de configuration défini au niveau applicatif du contrôle d’accès, appelé (SMS). La mise en place du USER.SMS.GROUP qui contrôle la méthode d’accès pour chaque utilisateur défini dans le système et qui permet l’enregistrement au niveau USER pour s’assurer que toutes les activités des utilisateurs sont enregistrés dans la table F.PROTOCOL, qui peut être utilisé plus tard à des fins d’Audit. Accès TAFC / JBASE Actuellement il n’y a pas de système de contrôle d’accès/de système de logging par défaut pour TAFC/JBASE. JBASE agit actuellement comme une base de données ainsi que l’environnement d’exécution pour T24. Permettre l’accès au jshell signifie que les utilisateurs peuvent être en mesure d’agir en arrière plan sur les données T24, en particulier cela devient difficile lorsque des bases de données externes comme DB2, MSSQL sont utilisées, aucune commande Unix peut protéger les données. Il s’agit d’un des risques majeurs pour la banque et l’Audit élèvera aussi une objection. Pour contre cela, ITSS a développé un wrapper pour jshell qui permettra de contrôler les restrictions d’accès pour les utilisateurs et aussi enregistrera toutes les activités réalisées au niveau Jshell.

40. Le record SYSTEM aide à enregistrer toutes les commandes définies par défaut. L’utilisateur a la possibilité d’avoir des accès complets, mais toutes les opérations seront enregistrées par défaut. Field 1– Liste de commandes séparées par des virgules seront enregistrées dans la table F.TAFC.AUDIT.LOG. Ex: JED,BASIC,CATALOG Si le record SYSTEM n’existe pas – Une liste par défaut est utilisée: ED,JED,EED,EJED,EEDIT,EDIT,BASIC,CATALOG,DECATALOG,COPY,LOGOFF,JKILL, CREATE,SELECT,LIST,CLEAR,DELETE Il est conseillé d’ajouter uniquement les commandes sensibles dans cette liste pour éviter l’engorgement inutile.

41. Configuration du contrôle d’accès F.TAFC.ACCESS.PARAM – SYSTEM ID est le nom de connexion de l’utilisateur Unix. Si l’enregistrement est introuvable – la commande n’est pas vérifiée pour restriction, l’accès complet est disponible pour l’utilisateur mais toutes les opérations seront enregistrées par défaut. Field 1– fichiers restreints, séparés par des virgules (il est aussi possible de restreindre un champ) ex: FBNK.ACCOUNT,FBNK.CUSTOMERex: FBNK.CUSTOMER>SHORT.NAME,FBNK.ACCOUNT>CURRENCY Peut être spécifié comme ALL, ainsi l’utilisateur n’aura pas le droit de faire quoi que ce soit sur l’une des tables défines dans le VOC.. Field 2– commandes restreintes, séparées par une virgule ex: JED,LIST,SELECT.Peut être spécifié comme ALL, ainsi aucune commande n’est autorisé pour cet utilisateur. Field 3– fichiers d’exception, séparé par une virgule ex: FBNK.STMT.ENTRY,FBNK.CATEG.ENTRYUtilisé lors qu’il est précisé ALL dans le champ 1. Field 4– commandes d’exception, séparé par une virgule ex: LIST,SELECT,SORTUtilisé lors qu’il est précisé ALL dans le champ 2

42. Exemple de TAFC.ACCESS.PARAM t24oper ----- Identifiant Unix 001 FBNK.CUSTOMER>SHORT.NAME,FBNK.ACCOUNT>CURRENCY 002 LIST,JED 003 004 t24admin 001 FBNK.ACCOUNT 002 All 003 004 SELECT,JED t24support 001 All 002 003 FBNK.STMT.ENTRY,FBNK.CATEG.ENTRY 004

43. Journal d'audit - F.TAFC.AUDIT.LOG • Il s’agit d’un fichier de log avec les détails suivants. • ID – format est Date_Time_PortNumber_LoginName • Field 1 – nom de la routine • Field 2 – clé d’enregistrement • Field 3 – date & heure • Field 4 – commande actuelle exécuté • Field 5 – identifiant utilisateur • Field 6 – adresse IP • Field 7 – host name • Field 8 – terminal • Field 9- environnement

44. Exemple TAFC.AUDIT.LOG 20120309_11-35-10_4080_t24support 001 jsh.b -> jsh.b -> jsh.b 002 jutil_jsh__dev_pts_106 003 09 MAR 2012 11:35:10 004 LIST-ITEM F.TAFC.ACCESS.PARAM ‘t24oper' 005 t24support 006 (P06412) 007 t24prodserver 008 /dev/pts/106 009 t24prod 20120309_12-08-36_4081_t24oper 001 jsh.b -> jsh.b -> jsh.b 002 jutil_jsh__dev_pts_99 003 09 MAR 2012 12:08:36 004 LIST FBNK.ACCOUNT 005 t24oper 006 192.168.56.101 007 t24prodserver 008 /dev/pts/99 009 t24test - Both F.TAFC.ACCESS.PARAM and F.TAFC.AUDIT.LOG will be kept in jbase hash file and restricted permission (write) willbe given only for ADMIN or ROOT. This will avoid tampering this configuration tables by other unix users

45. SUBSETTING

46. Archivage – Notre approche Scoping - 5 jours - Analyser la base de données pour la croissance de la DB et des grandes tables. - Analyser au niveau des répertoires applicatifs et des fichiers Interface - Décider où placer les données archivées - Estimer l’économie de stockage, le temps d’archivage, la période de rétention, TCO et Pilotage de la salle de Conférence - 10 jours - Configurer la table de paramètre et son trailrun - Corriger le relancement de l’archivage/de la récupération/du scrambling - Créer accès aux données pour l’archivage - Formations des administrateurs sur l’archivage Affiner/UAT - 10 jours - Test UAT avec validation business - Approuver la configuration des paramètres - Valider COB / online - Fin de mois / fin d’année et testing Déploiement - 5 jours - Déploiement en Production - Exécution en Production - Support

47. Méthodologie Scoping Support post Live Configurer la table de paramètres et trailrun Happy Client Déploiement en production et Formation Corriger relance de archivage / récupération / scrambling COB validé/ online Stratégie d'archivage et stockage des données Tests UAT avec validation de l'utilisateur business

48. Nous contacterITSS109, rue du Pont du CentenaireCH – 1228 Plan-les-OuatesSuisseTel: + 41 22 706 20 80www.itssglobal.com Merci pour votre attention! QUALITY PARTNER FOR YOUR EXPANSION