Évaluation technique
du Système de gestion des cas intégré
de la Commission de l'immigration et du statut de réfugié du Canada

Table des matières

• Restrictions et limites
• Sommaire
• Introduction
• Résumé des principales observations et conclusions
• Observations
• Annexe A - Personnes-ressources interviewées
• Annexe B - Documents examinés
• Annexe C - Pratiques exemplaires en matière de génie logiciel et d'architecture
• Annexe D - Analyse du marché des SGPF, figures et diagrammes
• Annexe E - Réponse de la Direction

Acronymes

Acronym	Description
AE	Architecture d'entreprise
CIC	Citoyenneté et Immigration Canada
CISR	Commission de l'immigration et du statut de réfugié du Canada
FRP	formulaire de renseignements personnels
GPF	gestion des processus fonctionnels
ICMS	Integrated Case Management System (SGCI - Système de gestion des cas intégrés)
KPMG	Klynveld Peat Marwick Goerdeler
PRU	Processus rationnel unifié
SAI	Section d'appel de l'immigration
SGCI	Système de gestion des cas intégrés
SGPF	systèmes de gestion des processus fonctionnels
SI	Section de l'immigration
SPR	Section de la protection des réfugiés
SQL	Selected Query Language (langage d'interrogation structuré)
STAR	System for Tracking Appeals and Refugees Claims (Système de suivi des appels et es revendications du statut de réfugié)
TI	technologie de l'information

Restrictions et limites

Restrictions

• Le présent rapport de même que les observations et les conclusions qu'il contient ne sont valides que dans le contexte global de l'évaluation. De même, les observations et les conclusions ne peuvent être interprétées indépendamment du rapport dans son intégralité.
• Les sources d'information consultées aux fins du rapport sont citées; sauf avis contraire, elles n'ont pas fait l'objet d'une vérification indépendante.

Limites

• Ayant reçu le mandat d'effectuer une évaluation technique rapide et de portée générale à l'intérieur d'un court échéancier, nous avons fait de notre mieux pour couvrir tous les aspects techniques de l'application du Système de gestion des cas intégré (SGCI) et du projet ayant mené à sa création. Il est possible, cependant, que des documents pertinents ou des commentaires d'une ressource importante aient échappé à notre démarche, lesquels auraient pu avoir une grande incidence sur nos observations et nos conclusions. L'évaluation doit être interprétée à la lumière des commentaires que nous avons obtenus des intervenants de la Commission de l'immigration et du statut de réfugié du Canada (CISR), des documents que nous avons examinés ainsi que des limites de temps et de budget imposées.
• Étant donné que des questions fondamentales sont demeurées sans réponse dans cette évaluation, il pourrait être avisé d'effectuer un examen complémentaire avant de donner suite aux mesures proposées.
• Notre évaluation n'avait pas pour objectif d'analyser la gestion globale du projet du SGCI ou les exigences et les modèles fonctionnels relatifs au SGCI. Dans le cadre de nos travaux visant à déterminer si les spécifications fonctionnelles du SGCI étaient suffisamment détaillées pour guider l'architecture du système et si une vérification de la conformité aux spécifications avait été effectuée, nous avons observé un certain nombre de problèmes liés à la gestion du projet et aux processus fonctionnels. Quelques-uns ont été documentés et devront être approfondis préalablement à l'exécution des mesures recommandées.

Sommaire

Le présent rapport expose les observations et les conclusions issues d'une évaluation technique rapide et de portée générale réalisée sur le SGCI, partiellement mis en œuvre, de la CISR. C'est à la société KPMG LLP qu'a été confié le mandat d'évaluer la viabilité technique du système eu égard aux modifications continues pour rendre le SGCI plus performant et adapté aux besoins opérationnels.

• L'évaluation visait les objectifs généraux suivants :
  • Effectuer une évaluation technique de portée générale de la conception globale (architecture) du SGCI afin de déterminer la viabilité technique du système eu égard aux modifications continues nécessaires pour rendre le SGCI plus performant et adapté aux besoins opérationnels;
  • Fournir une orientation quant aux questions prioritaires à traiter et aux mesures qui aideraient la CISR à obtenir la capacité technique dont elle a besoin pour exécuter ses processus de gestion des cas avec efficience et efficacité.
• Il a été déterminé que les paramètres suivants échappaient à la portée de l'étude :
  • Examen du budget du projet, des coûts et d'autres aspects financiers;
  • Examen des plans de projet, des calendriers de mise en application et d'itération, et de leur contenu;
  • Examen des rapports de problème, des demandes de changement et d'autres problèmes fonctionnels;
  • Examen du code de projet du SGCI ou des révisions effectuées.
• Le projet a été réalisé en trois phases :
  • Phase 1 - Confirmation des objectifs du projet et examen préliminaire de la documentation du système;
  • Phase 2 - Évaluation du SGCI, comprenant l'essai du système, la conduite d'entrevues avec les intervenants clés des Opérations et des technologies de l'information (TI), et un examen complémentaire de la documentation fournie;
  • Phase 3 - Analyse de la documentation et de l'information recueillie lors des entrevues, analyse générale du marché des systèmes de gestion des processus fonctionnels (SGPF) et préparation du rapport final.

Les entrevues avec les intervenants clés, l'essai du système et l'examen de la documentation clé fournie nous ont permis de formuler les principales observations et conclusions suivantes :

• Le SGCI semble employer les technologies les plus récentes et s'appuyer sur une architecture souple axée sur des processus. D'après notre analyse générale du marché, l'architecture du SGCI est conforme à celles recommandées pour les systèmes de gestion des cas.
• Bien qu'elle semble assez robuste, l'architecture axée sur des processus du SGCI ne répondrait pas aux principaux besoins opérationnels de la CISR pour la gestion du tribunal.
• Les utilisateurs ne sont pas satisfaits des fonctionnalités du SGCI (module 4) et ont signalé de nombreux problèmes, qui sont généralement de deux types :
  • Rapports de problème / amélioration des caractéristiques - L'application actuelle du SGCI semble assez souple pour qu'on puisse corriger les problèmes cernés, pourvu qu'il y soit consacré suffisamment de temps, d'efforts et de ressources.
  • Modifications aux processus fonctionnels - Comme le SGCI possède une architecture axée sur des processus, il devrait être possible d'apporter des modifications aux processus fonctionnels. Cependant, tels qu'ils ont été conçus et mis en application, les processus du SGCI ne semblent pas assez souples pour recevoir le grand nombre de modifications requises dans le délai nécessaire pour que le SGCI soit opérationnel.

Quelques mesures sont recommandées ci-dessous à la lumière des principales observations et conclusions précitées.

• Faire participer les responsables de la gestion du tribunal et les utilisateurs aux activités suivantes :
  • Définition et gestion des spécifications fonctionnelles du SGCI;
  • Harmonisation des spécifications fonctionnelles avec les efforts de restructuration des activités associées au processus du tribunal intégré.
• Envisager de ramener le SGCI au stade de « développement logiciel », dans le cadre d'un projet distinct et financé, au lieu de maintenir le mode actuel de « maintenance ».
• Examiner plus en détail l'architecture existante du SGCI et ses composantes afin de déterminer quels sous-systèmes offriraient une valeur opérationnelle à court terme.
• Envisager de modifier l'actuelle méthode fondée sur le cycle de développement de système en vue d'augmenter la souplesse et de réduire les retards d'itération.

Par suite de notre évaluation rapide de portée générale, nous recommandons qu'un examen complémentaire soit effectué préalablement à l'exécution des mesures proposées puisque des questions fondamentales sont demeurées sans réponse.

Le présent rapport comprend les sections suivantes :

• Introduction - les objectifs et la portée de l'étude y sont énoncés, de même que notre méthodologie et le contexte général du projet du SGCI.
• Résumé des principales observations et conclusions - il s'agit d'un résumé des résultats de l'évaluation.
• Observations - cette section décrit plus en détail les observations sur lesquelles s'appuient nos principales observations et conclusions.
• Annexes - on y trouve des renseignements généraux, dont la liste des intervenants interviewés et les documents examinés.

Introduction

Objectifs et portée de l'étude

• La société KPMG LLP avait comme mandat d'effectuer une évaluation technique rapide et de portée générale du SGCI, partiellement mis en œuvre, de la CISR. Le projet consistait à évaluer la viabilité technique du système eu égard aux modifications continues nécessaires pour rendre le SGCI plus performant et adapté aux besoins opérationnels.
• L'évaluation visait les objectifs généraux suivants :
  • Effectuer une évaluation technique de portée générale de la conception globale (architecture) du SGCI afin de déterminer la viabilité technique du système eu égard aux modifications continues nécessaires pour rendre le SGCI plus performant et adapté aux besoins opérationnels;
  • Fournir une orientation quant aux questions prioritaires à traiter et aux mesures qui aideraient la CISR à obtenir la capacité technique dont elle a besoin pour exécuter ses processus de gestion des cas avec efficience et efficacité.
• Il a été déterminé que les paramètres suivants échappaient à la portée de l'étude :
  • Examen du budget du projet, des coûts et autres aspects financiers;
  • Examen des plans de projet, des calendriers de mise en application et d'itération, et de leur contenu;
  • Examen des rapports de problème, des demandes de changement et d'autres problèmes fonctionnels;
  • Examen du code de projet du SGCI ou des révisions effectuées.

Démarche et méthodologie

Phase I - Lancement et examen préliminaire de la documentation

Nous avons d'abord rencontré le chargé de projet pour :

• Confirmer les objectifs et la portée de l'évaluation.
• Confirmer et mettre au point la démarche proposée et le calendrier associé.
• Discuter du plan de communication avec les intervenants devant participer au processus d'évaluation.
• Désigner des personnes-ressources pour l'organisation des entrevues et des séances de travail.
  • Obtenir une copie des documents de référence exposant :
  • la portée et les objectifs du projet global;
  • les besoins opérationnels, tant fonctionnels que non fonctionnels, y compris les cas d'utilisation, les scénarios et les modèles fonctionnels;
  • la documentation technique, y compris le modèle d'analyse, le modèle de conception, le modèle d'installation, le modèle de données, le modèle de relation entre les entités et l'architecture du système, de l'entreprise et de l'application;
  • le plan de l'application, les lignes directrices et les normes, y compris les normes de codage, les modèles de codage, etc.;
  • les documents relatifs à la gestion du projet, y compris les plans de projet, les plans d'itération, les plans de risque, le processus de gestion des modifications, les listes de problèmes et l'organisation du projet;
  • la stratégie d'essai, le plan, les cas, le code, les données et les résultats des essais unitaires, d'intégration, d'acceptation et de performance;
  • les guides d'exploitation, comme le guide de l'utilisateur, le suivi, la reprise après sinistre, etc.
• Les documents n'étaient pas tous accessibles, mais l'examen préliminaire de la documentation principale a permis de donner un contexte et une orientation à l'exercice d'évaluation sur place.

La phase I s'est déroulée du 12 au 14 mai 2008.

Phase II - Évaluation du SGCI

Dans un deuxième temps, nous avons effectué les activités suivantes :

• Un examen de la documentation existante portant sur la conception et l'architecture du SGCI, ainsi que d'autres documents techniques pertinents et accessibles.
• Un essai du système et des entrevues avec 13 employés clés du projet du SGCI, dont des dirigeants, des membres de l'équipe de projet et d'autres intervenants clés, afin d'examiner :
  • les fonctions existantes du SGCI associées aux activités et aux tâches de gestion des cas;
  • l'architecture globale du SGCI et la façon dont les diverses composantes ont été conçues pour interagir entre elles;
  • la conception des menus, des caractéristiques, des processus et des options du SGCI, afin d'en vérifier la conformité aux pratiques et aux règles administratives;
  • les modules du système et les principales fonctions incluses dans chaque module;
  • les modifications approuvées en attente;
  • les principaux problèmes techniques survenus et la façon dont ils ont été réglés.

La phase II s'est déroulée du 15 au 21 mai 2008.

Phase III - Présentation des observations et des recommandations

Nous avons enfin préparé un rapport contenant les résultats de notre évaluation technique et nos recommandations. Le rapport d'évaluation final couvre  les volets suivants :

• Une évaluation de la robustesse de l'architecture du SGCI et de la mesure dans laquelle l'interaction entre ses composantes est conforme aux normes établies en matière de conception de logiciel Web.
• Une évaluation visant à déterminer si l'architecture est assez souple pour recevoir les principales modifications prévues, afin que la CISR ait un système de gestion des cas opérationnel qui répond aux exigences minimales.
• Une orientation quant aux questions prioritaires à traiter et aux mesures à étudier, qui aideraient la CISR à obtenir la capacité technique dont elle a besoin pour exécuter ses processus de gestion des cas avec efficience et efficacité.
• Les principaux risques techniques auxquels la CISR peut être exposée si elle fait une utilisation continue du SGCI dans sa forme actuelle.
• D'autres éléments qu'il nous paraissait opportun, dans le contexte de l'évaluation, de porter à l'attention de la CISR.

La phase III s'est déroulée du 23 mai au 13 juin 2008.

Contexte du projet du SGCI

• Le SGCI est un projet pluriannuel qui vise à remplacer graduellement le Système de suivi des appels et des revendications du statut de réfugié (STAR) existant par un SGCI qui appuierait les activités des sections de la CISR : la Section de la protection des réfugiés (SPR), la Section de l'immigration (SI), la Section d'appel de l'immigration (SAI) et la Section d'appel des réfugiés (SAR) (n'existe pas encore).
• Le STAR est une application Clipper fonctionnant sous DOS utilisée depuis 1990 pour le suivi des dossiers. Les utilisateurs trouvent l'application non ergonomique, sa technologie est désuète et elle ne peut être mise à niveau pour satisfaire aux nouvelles exigences.
• Les utilisateurs du SGCI sont situés dans trois bureaux régionaux : à Montréal, à Toronto et à Vancouver. Le SGCI a été installé à l'échelle nationale, mais seulement 6 000 cas ont été entrés dans le système en 2007. Aucun nouveau cas n'a été ajouté depuis.
• D'après les entrevues et notre examen de la documentation, la CISR traite environ 90 000 cas par année, dont la part la plus importante et la plus complexe est traitée par la SPR. Cette section traite quelque 30 000 nouveaux cas chaque année. L'arriéré de la CISR atteint les 50 000 cas et continue de croître.

Historique

• La CISR travaille à la mise en place d'une application de gestion des cas depuis 1996. Voici les principaux jalons qui ont été atteints ces douze dernières années :
  • 1989 : création du STAR
  • 1996-2002 : élaboration d'un Système de gestion des cas avec le logiciel Sustain pour remplacer STAR (projet annulé en 2002)
  • 2002-2003 : définition de la vision du SGCI, définition du projet et attribution de fonds par le Conseil du Trésor pour la mise en œuvre du système en trois étapes dans les sections suivantes de la CISR :
    • Étape 1 = SPR
    • Étape 2 = SAI
    • Étape 3 = SI
  • 2004-2007 : élaboration de l'application du SGCI pour la SPR (étape 1) - modules préliminaires 1, 2 et 3.
  • Avril 2007 : mise en œuvre officielle du SGCI (module 4) à la SPR; les nouveaux cas déférés ne sont plus entrés dans le STAR; dissolution de l'équipe de projet du SGCI.
  • Août 2007 : arrêt du traitement des nouveaux cas dans le SGCI; entrée de tous les nouveaux cas déférés dans le STAR pour traitement.
  • 2007-2008 : maintenance du SGCI, élaboration et mise en application des modules 4.1, 4.2, 4.3 et 4.4 pour les utilisateurs.
  • En date de mai 2008, l'application du SGCI est installée mais ne sert pas au traitement des nouveaux cas. À mesure que les cas existants dans le SGCI sont traités, les données sont extraites et entrées dans le STAR et d'autres systèmes pour y être traités.
• Il semble y avoir eu un roulement élevé des ressources tout au long du projet, tant à la direction de la CISR qu'au sein des équipes responsables du développement et de l'exploitation.
  • Par exemple, depuis le début du projet du SGCI, la CISR a vu se succéder trois présidents, deux secrétaires généraux, deux vice-présidents à la SPR, cinq directeurs généraux aux Opérations et quatre directeurs à la Gestion des renseignements opérationnels.
• L'équipe responsable du développement, qui était principalement composée d'entrepreneurs externes selon les intervenants interviewés, a été presque entièrement dissoute à la fin du projet en avril 2007.
• Il reste peu de ressources possédant une expérience du projet du SGCI au sein des TI et des Opérations pour assurer la continuité du projet dont la CISR a grandement besoin (code, documentation, processus, etc.).

Résumé des principales observations et conclusions

Les conclusions présentées ici s'appuient sur l'évaluation exposée dans la section Observations du rapport.

Robustesse de l'architecture du SGCI

À la lumière de l'information recueillie lors des entrevues avec les intervenants clés et de notre examen des documents techniques pertinents, nous avons constaté que l'architecture et la technologie du SGCI :

• emploie une technologie comparable aux technologies courantes et aux progiciels commerciaux offrant une capacité limitée de personnalisation pour permettre l'évolution des activités et les améliorations requises.
• possède une architecture souple axée sur des processus qui, selon notre analyse générale du marché, semble conforme aux architectures recommandées pour les systèmes de gestion des cas. Notre analyse générale du marché des SGPF révèle que l'application de la gestion des processus fonctionnels principale (GPF) du SGCI, soit BizFlow v10 d'Handysoft, se classe parmi les meilleurs SGPF axés sur le facteur humain (voir l'annexe D pour plus de détails).
• répond à quelques besoins opérationnels, surtout dans les secteurs clés suivants :
  • gestion électronique des documents - l'application Hummingbird et ses systèmes associés semblent offrir la fonctionnalité nécessaire;
  • production de rapports - l'application Cognos offre, semble-t-il, des rapports et des modèles qui répondent aux besoins d'analyse des utilisateurs.

Quel est le degré de robustesse de l'architecture axée sur des processus?

• Le SGCI est une application axée sur des processus; c'est-à-dire qu'un processus défini de gestion des cas détermine les activités qui doivent être accomplies et les tâches que les ressources de la CISR doivent exécuter. Cette approche est acceptable pour autant que le SGCI puisse produire et gérer toutes les activités principales qui doivent être exécutées par la fonction de gestion du tribunal.
• À l'autre extrémité du spectre, une application axée sur des données permettrait de faire le stockage et le suivi des nombreux types de données liées à la gestion des cas. Il s'agit d'une application à événement neutre comportant peu de capacités axées sur des processus. On trouve ce type d'application dans le STAR ou le Système de suivi des cas d'arbitrage, et également dans les sous-systèmes du SGCI (gestion des documents, mise au rôle, etc.).
• Selon nos observations, l'application axée sur des processus du SGCI semble assez robuste pour qu'on y intègre des processus fonctionnels semblables à ceux associés à la gestion du tribunal. Dans sa forme actuelle, cependant, le SGCI ne semble pas répondre aux principaux besoins opérationnels de la CISR en matière de gestion du tribunal.

Dans la section Observations, de plus amples renseignements sont fournis sur ces deux types d'application et leur incidence respective sur l'architecture du système.

Souplesse de l'architecture du SGCI

L'information recueillie lors des entrevues avec les intervenants clés et notre examen des documents techniques pertinents nous ont permis de faire les constats suivants :

• Les utilisateurs ne sont pas satisfaits de la fonctionnalité du SGCI (module 4) et ont signalé de nombreux problèmes avec l'application, notamment :
  • Performance : le temps de réponse est trop lent dans certains écrans, l'enchaînement des écrans est trop long, etc.
  • Ergonomie : l'interface-utilisateur n'est pas intuitive. Les pages Web sont habituellement plus longues que la taille des écrans de sorte qu'il faut défiler assez longtemps pour atteindre les champs appropriés ou obtenir les renseignements voulus. De plus, il n'y a pas d'ancrage des barres de défilement. Les fonctions de recherche et les filtres qui permettent de préciser l'information sont inexistants ou limités.
  • Rôles des utilisateurs : ils semblent manquer de souplesse et ne reflètent pas les réalités organisationnelles. Certains utilisateurs doivent avoir plusieurs identifications d'utilisateurs pour pouvoir effectuer leur travail.
  • Intégrité des données : les utilisateurs disent qu'ils n'arrivent pas à trouver les cas et les tâches lorsqu'ils se déplacent entre les étapes du processus. Les tâches (façon d'accéder à un dossier) apparaissent après plusieurs jours ou semaines de retard.
  • Fonction de correction d'erreur inexistante : à l'heure actuelle, le système ne reconnaît pas les erreurs dans les étapes de traitement. Si un dossier est envoyé à l'étape suivante du processus, il n'y a aucune façon de le récupérer s'il a été envoyé par erreur.
  • Autre : de nouveaux champs et une fonction d'impression en bloc sont nécessaires, il faut réduire ou simplifier les tâches, une nouvelle interface de mise au rôle a été demandée, il faut inclure la documentation des Cartables nationaux de documentation, des capacités accrues de production de rapports sont nécessaires, etc.
• À ce jour, les problèmes qui ont été signalés sont principalement de deux types :
  • Rapports de problème et amélioration des caractéristiques : il s'agit de modifications très précises qui nécessitent des solutions très précises (p. ex. ancrage des barres de défilement sur les écrans).
  • Modifications aux processus fonctionnels : celles-ci sont plus complexes et coûteuses du fait qu'elles supposent un remaniement des processus existants du SGCI. Ces problèmes sont définis en des termes plus généraux que les rapports de problème et les améliorations (p. ex. besoin d'une fonction de détection et de correction d'erreur, le système crée trop de tâches, la répartition des tâches n'est pas efficiente et entraîne des problèmes d'affectation des ressources, besoin de rôles plus souples, etc.).

Souplesse de l'architecture du SGCI (suite)

Analyse de la souplesse

• L'application actuelle du SGCI semble assez souple pour recevoir les modifications correspondant à la majorité des rapports de problème signalés et aux améliorations demandées jusqu'à maintenant par la CISR, pourvu qu'il y soit consacré suffisamment de temps, d'efforts et de ressources.
• Comme le SGCI possède une architecture axée sur des processus, il devrait être possible d'apporter des modifications aux processus fonctionnels. Cependant, tels qu'ils ont été conçus et mis en application, les processus du SGCI ne semblent pas assez souples pour recevoir le grand nombre de modifications requises dans le délai nécessaire pour que le SGCI soit opérationnel.
  • Nombre des informations recueillies semblent indiquer que les procédures et les règles associées aux processus fonctionnels ne sont pas bien intégrées dans l'application du SGCI et ne reflètent pas une conception axée sur des processus.
  • Les processus fonctionnels ne semblent pas bien définis, stables ni définitifs.

Principaux défis et risques

Sont énoncés ci-dessous quelques-uns des principaux défis et risques qui pourraient compromettre la réussite de la mise en œuvre des recommandations présentées ici et la capacité de la CISR d'obtenir une version du SGCI qui répond aux besoins opérationnels :

• L'approche actuelle de conception axée sur des processus, si elle est maintenue sans qu'on obtienne la participation, la compréhension et l'acceptation des utilisateurs, fera en sorte que la CISR se retrouvera avec un système qui ne répond pas aux besoins opérationnels.
• La capacité de la CISR d'adopter un cycle de développement plus souple et itératif qui réduit au minimum l'intervalle de temps entre les itérations et fait participer les utilisateurs.
• Le leadership discontinu et le roulement des ressources, qui pourraient miner les efforts déployés pour remettre le SGCI sur la bonne voie.
• Les problèmes de communication non résolus entre les utilisateurs, les Opérations et les équipes de développement et de maintenance.
• Les pressions constantes des régions afin que soient élaborées des solutions personnalisées qui répondent aux besoins opérationnels urgents (p. ex. la mise au rôle des cas), mais qui ne sont pas nécessairement conformes aux exigences et aux normes de l'organisation.

Principales mesures recommandées

Sont présentées ci-dessous les mesures qui ont été soumises à la CISR pour examen et mise en œuvre. Elles s'appuient sur l'information recueillie tout au long de cette évaluation rapide de portée générale. L'évaluation ayant été soumise à des contraintes de temps, de portée et de budget, un examen complémentaire pourrait être nécessaire préalablement à la mise en œuvre de certaines mesures proposées.

• Faire participer les responsables de la gestion du tribunal et les utilisateurs à la définition et à la gestion des spécifications fonctionnelles du SGCI ainsi qu'à l'harmonisation de ces spécifications avec les efforts de restructuration des activités associées au processus du tribunal intégré. Par exemple, les mesures suivantes devraient être envisagées :
  • définir l'architecture opérationnelle globale qui reflète le processus de gestion des cas de la CISR;
  • évaluer comment tirer le maximum de l'application existante du SGCI (module 4) en utilisant une nouvelle architecture fonctionnelle, comme moyen de combler les lacunes existantes;
  • évaluer la maturité des processus fonctionnels de la CISR afin d'en établir les limites et de déterminer la vitesse à laquelle des modifications peuvent être apportées aux processus;
  • préparer une analyse de rentabilisation et une charte de projet afin de remettre l'initiative du SGCI sur la bonne voie.
• Au lieu de maintenir le mode actuel de « maintenance », envisager de ramener le SGCI au stade de « développement logiciel » dans le cadre d'un projet distinct et financé où :
  • les utilisateurs, les analystes du fonctionnement, les analystes de système, les développeurs, les responsables des essais et les autres ressources affectées au SGCI sont réunis en une seule équipe où tous les membres partagent les risques et visent les mêmes objectifs à court, à moyen et à long terme;
  • des utilisateurs spécialisés affectés au projet à temps plein reçoivent une formation sur l'analyse des processus fonctionnels et l'établissement de modèles, et ont le pouvoir d'apporter des modifications aux processus du SGCI;
  • une expertise externe peut être obtenue, au besoin.

D'un point de vue technique, à tout le moins, les mesures suivantes devraient être définies et mises de l'avant en priorité :

• Examiner plus en détail l'architecture existante du SGCI et ses composantes afin de déterminer :
  • à partir de l'architecture fonctionnelle de la CISR, si l'architecture actuelle du SGCI doit être maintenue ou s'il serait préférable d'opter pour une application hybride, en partie axée sur des processus et en partie axée sur des données;
  • lesquels des sous-systèmes existants du SGCI peuvent être installés rapidement pour procurer une valeur commerciale en tant qu'applications axées sur des données, en dehors de l'architecture actuelle axée sur des processus.
• Envisager de modifier l'actuelle méthode fondée sur le cycle de développement de système en vue d'augmenter la souplesse et de réduire les retards d'itération :
  • adopter une approche itérative comportant des cycles de développement plus courts et permettant une plus grande participation des utilisateurs; si possible, envisager une approche plus souple misant sur une collaboration entre les utilisateurs et les développeurs du système;
  • tenir compte des caractéristiques uniques du processus de GPF, lequel délègue certaines activités aux utilisateurs (p. ex. établir un modèle fonctionnel et entrer les modifications directement dans l'application de GPF).

Observations nécessitant un examen complémentaire

Nos observations concernant les applications axées sur des processus et sur des données ont soulevé maintes questions qui sont demeurées sans réponse dans le cadre de notre évaluation. Il est recommandé que la CISR examine les questions suivantes avant d'apporter des modifications supplémentaires au SGCI.

• Peut-on tirer un maximum du SGCI en limitant la mise en œuvre aux sous-systèmes axés sur des données?
• Au fil du temps, sera-t-il possible d'intégrer dans le SGCI quelques sous-systèmes axés sur des processus qui procureraient des avantages supplémentaires par rapport aux sous-systèmes axés sur des données?
• La restructuration des activités et l'harmonisation des processus ont-elles été documentées par les utilisateurs et les bureaux régionaux? Ont-elles été approuvées et acceptées par eux?
• Est-ce qu'un plan de transition a été élaboré pour harmoniser les processus et la gestion des cas de la CISR avec la vision qu'elle s'est donnée en 2003 et qui se trouve à la base du projet du SGCI?
• Les ressources fonctionnelles et technologiques de la CISR sont-elles suffisamment développées pour recevoir toutes les modifications de nature humaine, opérationnelle et technologique qui sont inévitables dans les projets de transformation aussi importants que celui envisagé avec le SGCI dans sa forme actuelle? Le SGCI peut-il être modifié de manière à répartir l'intégration des modifications sur une période plus longue?

Observations

Aperçu

Les observations présentées dans les pages suivantes ont été recueillies au moyen d'entrevues avec les intervenants clé (voir l'annexe A), d'un essai du système et d'un examen de la documentation pertinente (voir l'annexe B). De plus, nous avons appliqué des méthodes reconnues de génie logiciel (voir l'annexe C) et avons procédé à une analyse générale du marché des SGPF. Bien que nous ayons fait de notre mieux pour couvrir tous les aspects de l'application du SGCI et du projet ayant mené à sa création, il est possible que des documents pertinents ou les commentaires d'une ressource importante nous aient échappé, ce qui pourrait avoir une grande incidence sur nos observations.

Nos observations sont présentées sous les thèmes suivants :

• Exigences et modèles fonctionnels
• Architecture, analyse et conception
  • Cette section comprend également des renseignements sur les systèmes axés sur des processus et ceux axés sur des données
• Mise en œuvre, essais, installation et environnements
• Projet, configuration et gestion des modifications

Pour chacun de ces points principaux, nous avons structuré nos observations autour des thèmes suivants :

• Secteurs de réussite - dans le contexte du projet du SGCI.
• Contraintes/Difficultés/Problèmes - qui ont été constatés et auraient une incidence sur les mesures prises dans l'avenir.
• Questions à approfondir - il s'agit des questions qu'il nous a été impossible d'explorer dans le cadre de notre évaluation, mais qui devraient être approfondies dans le cadre de l'établissement d'un plan d'action pour l'avenir.

I.  Exigences et modèles fonctionnels

Notre évaluation ne visait pas à analyser les exigences et les modèles fonctionnels relativement au SGCI. Suivant les pratiques exemplaires en matière de génie logiciel, cependant, nous avons dû valider si les spécifications fonctionnelles du SGCI étaient suffisamment détaillées pour guider l'élaboration de l'architecture du système et si une vérification de la conformité aux spécifications avait été effectuée. L'information recueillie nous a permis d'effectuer les observations suivantes.

Secteurs de réussite

Des cas d'utilisation détaillés ont été documentés.

Contraintes/Difficultés/Problèmes

• Bien que les exigences fonctionnelles semblent avoir été recueillies et consignées (Use Cases - ICMS - Release 3), nos entrevues avec les utilisateurs, les formateurs et les analystes du fonctionnement ont révélé l'existence de problèmes fondamentaux. Le système proposé ne semble pas répondre aux besoins ni aux attentes des utilisateurs.
  • Voici quelques-uns des problèmes mentionnés : pas de fonction d'impression en bloc, pas de fonction de recherche avec filtres, fonction de mise au rôle inutilisable (la région de Montréal a mis au point une application  personnalisée).
  • Seuls les cas d'utilisation « heureux » ont été consignés, ce qui expliquerait l'absence de fonction de « correction d'erreur », comme l'ont mentionné les utilisateurs en entrevue.
• On ne sait pas avec certitude si l'architecture et les exigences fonctionnelles ont été approuvées par les utilisateurs et ont été mises en œuvre selon les spécifications (problème possible de gouvernance).
• Le SGCI, tel qu'il a été livré, ne semble pas correspondre aux activités réelles de la CISR.
• Les modèles d'interface-utilisateur et les scénarios du SGCI ne semblent pas avoir été présentés aux utilisateurs avant la mise en œuvre du module 4.
• Les raisons pour lesquelles le système ne répond pas aux besoins ni aux attentes des utilisateurs devront être approfondies et confirmées avant de passer aux prochaines étapes du projet.
• En ce qui concerne les modifications recommandées au système, il semble n'exister aucun plan global des modifications nécessaires et on ne sait pas si elles répondraient effectivement à tous les besoins liés aux processus fonctionnels.

Questions à approfondir

• L'architecture fonctionnelle n'a pas été examinée - il ne semble pas y avoir d'architecture fonctionnelle approuvée.
• La documentation sur l'analyse des processus fonctionnels, les modèles et la liste des caractéristiques du SGCI ne nous a pas été fournie pour que nous puissions comparer avec la liste des caractéristiques du module 4.
• Bien qu'il existe un aperçu général du processus fonctionnel de traitement au sein de la CISR (aperçu du processus de la SPR, guide de formation sur le Système des cas intégrés), il nous a été impossible de vérifier si les « responsables » fonctionnels avaient participé à l'élaboration ou à l'approbation des processus.

II. Architecture, analyse et conception

Secteurs de réussite

• Dans l'ensemble, l'application du SGCI semble utiliser une architecture de pointe, et même d'avant-garde pour certains éléments.
• Selon notre analyse générale du marché, l'architecture de GPF semble conforme aux architectures recommandées pour les systèmes de gestion des cas.
• L'application de GPF du SGCI (BizFlow v10 d'Handysoft) se classe parmi les meilleurs SGPF axés sur le facteur humain (voir l'annexe D).
• Les services Web sont exploités de manière à dissocier les composantes pour qu'elles soient réutilisables individuellement.
• L'architecture du système a été élaborée en tenant compte de facteurs de sécurité. Il semble que les contraintes et les exigences à cet égard jouent un rôle important dans les décisions relatives à l'architecture, qui, à leur tour, ont une incidence sur la performance, les environnements et la durée du cycle de développement et d'itération du logiciel.
• Les principes fondamentaux liés à l'architecture ont favorisé l'achat plutôt que l'élaboration.
  • Les logiciels commerciaux ont été exploités suivant le « principe d'achat ». La solution finale intègre plusieurs composantes qui demeurent légèrement associées, permettant ainsi une souplesse accrue pour les mises à niveau futures du produit et l'évolution globale de l'application du SGCI : Hummingbird pour la gestion électronique des documents, Cognos pour la production de rapports et la veille économique, BizFlow d'HandySoft pour la gestion des processus fonctionnels (GPF) et les interactions avec les utilisateurs.
  • L'architecture examinée révèle que les logiciels commerciaux ont été personnalisés au minimum afin que le produit puisse être mis à niveau ultérieurement.

Contraintes/Difficultés/Problèmes

• Le SGCI possède une architecture axée sur des processus, laquelle repose sur des sous-systèmes axés sur des données. Les pages suivantes présentent notre analyse de la question ainsi que nos observations.
• Selon notre brève analyse du marché des SGPF, la gestion des cas possède des « caractéristiques particulières » pour ce qui a trait à l'automatisation des processus. L'utilisation « de règles et de files d'attente de traitement », notamment, est remise en question et semble également représenter un problème pour le SGCI.
• Les applications de GPF acceptent plus facilement les modifications de processus que l'architecture logicielle traditionnelle. Cependant, les utilisateurs doivent pouvoir apporter eux-mêmes les modifications aux processus lors d'itérations rapides sans devoir recourir à des spécialistes techniques. Il nous a été impossible de vérifier si ce mécanisme est en place à la CISR ou si cette option peut même être envisagée.

Questions à approfondir

• Les interfaces avec d'autres systèmes (internes ou externes) n'ont pas été examinées. Cet élément semble être une composante clé du SGCI puisque la CISR doit communiquer avec les systèmes de Citoyenneté et Immigration Canada (CIC) et d'autres organisations externes.
• Les causes de la défaillance du formulaire de renseignements personnels (FRP) électronique ne sont pas claires et doivent être examinées plus avant.
• Les contraintes liées à la sécurité semblent avoir joué un rôle important dans la définition de l'architecture du SGCI. Une analyse plus approfondie est nécessaire pour déterminer si une diminution de ces contraintes aiderait à simplifier l'architecture du SGCI et faciliterait le développement du logiciel.

Le SGCI est composé de deux sous-systèmes principaux

Nous avons constaté que le SGCI est composé de deux systèmes : un axé sur des données et l'autre axé sur des processus.

1. Sous-système axé sur des données - On trouve à la base du SGCI un ensemble de sous-systèmes de gestion et de stockage de données :
   • De multiples applications stockent et gèrent les données qui sont essentielles à la gestion des dossiers de cas pendant leur durée de conservation.
   • Les applications suivantes du SGCI sont axées sur des données :
     • Hummingbird, système de gestion des documents;
     • Cognos, système de production de rapports;
     • SQL Server, système de gestion des bases de données;
     • FRP électronique, système de gestion des FRP.
2. Sous-système axé sur des processus – Le système de gestion et d'automatisation des processus :
   • utilise une interface uniforme pour les données et les applications;
   • gère les processus fonctionnels et les règles administratives;
   • appuie les activités humaines et peut automatiser certaines activités;
   • fait le suivi des activités et donne l'état en temps réel des cas prioritaires et des retards;
   • BizFlow d'Handysoft est l'application axée sur des processus du SGCI.

Système axé sur des données du SGCI

Observations

• Le SGCI semble présenter des problèmes d'intégrité des données qui ne sont pas acceptables pour les utilisateurs compte tenu du rôle attendu du SGCI comme source de données fiables pour la gestion des cas.
• Il existe de multiples systèmes, mais d'après nos entrevues et notre essai du système, ils n'offrent pas tous les fonctions et interfaces complexes nécessaires (comme des systèmes de production de rapports et de mise au rôle).
• Il semblerait que le SGCI n'offre pas les outils adéquats pour que les utilisateurs puissent exécuter leur travail de manière efficiente ou efficace (la mise au rôle notamment).

Système axé sur des processus du SGCI

Observations

• En général, un système de GPF requiert des processus fonctionnels stables et bien connus, harmonisés entre tous les utilisateurs de l'organisation.
• Les combinaisons, les permutations et les exceptions dans le processus de gestion du tribunal de la CISR n'ont pas été pleinement exécutées ni ne semblent avoir été définies par les utilisateurs des bureaux régionaux.
• En ce qui concerne les modifications aux processus fonctionnels, les utilisateurs ont besoin d'outils, de connaissances et de souplesse pour pouvoir les effectuer eux-mêmes rapidement.
  • Les utilisateurs semblent avoir été peu engagés dans l'élaboration des processus du système actuel.

Quelle architecture permettrait d'atteindre les objectifs de la CISR?

Par suite de nos observations, nous nous sommes demandés s'il était nécessaire d'avoir des systèmes axés sur des processus et axés sur des données pour atteindre les objectifs de la CISR relativement au SGCI. Nous avons utilisé le plan de projet du SGCI module 4 (voir l'extrait dans l'encadré) pour déterminer si une architecture de GPF axée sur des processus est nécessaire pour atteindre les buts et les objectifs opérationnels de la CISR.

• Les objectifs d'amélioration des activités, suivant l'orientation donnée par le président et le but du projet du SGCI, portent sur la saisie et l'échange électroniques de renseignements sur les dossiers de cas.
• Seuls les objectifs « restructuration des activités » et « harmonisation des activités des bureaux régionaux » justifient les composantes axées sur des processus du SGCI.
• Il semble que l'installation et la mise en œuvre rapides des composantes axées sur des données du SGCI pouvaient offrir la majeure partie des avantages opérationnels, et que la mise en œuvre du système axé sur des processus pourrait être reportée.
• Les sous-systèmes suivants, axés sur des données, pourraient générer des avantages à court terme pour les utilisateurs :
  • Gestion électronique des documents
  • FRP électronique
  • Mise au rôle électronique
  • Production de rapports

III. Mise en œuvre, essais, installation et environnement

Secteurs de réussite

• On trouve une quantité importante de documentation sur le site intranet SharePoint consacré au projet.
• D'après notre examen des échantillons, la documentation semble de bonne qualité, détaillée et pertinente. Ce commentaire s'applique particulièrement à la documentation théorique préparée aux premières étapes du projet. Il ressort toutefois de nos entrevues que certains documents n'ont pas été complétés dans les dernières étapes (2006-2007), et que la documentation logique et physique a été négligée en raison de contraintes de temps.
• Le nombre d'environnements semble suffisant pour appuyer un développement approprié en parallèle et la mise en application du SGCI.

Contraintes/Difficultés/Problèmes

• Il y a actuellement beaucoup d'environnements pour appuyer le SGCI, ce qui augmenterait la durée de la mise en application et rendrait le processus vulnérable aux erreurs.
• Il semble qu'il n'existe aucune bonne liste de documents.
• Les documents de base comme les présentations techniques sont toujours en cours d'élaboration et semblent n'avoir été créés que récemment.
• L'utilisation de la documentation semble limitée parce que les personnes ne savent pas quels documents existent, à quel endroit ils sont situés ni ce qu'ils contiennent. Cela pourrait être attribuable en partie au roulement élevé des ressources affectées au projet.

Questions à approfondir

• Comme nous n'avons pas effectué un examen du code, le code du logiciel du SGCI ne peut être évalué pour l'instant.
• Évaluer si l'adoption de la dernière version de BizFlow (version 11) ajouterait des caractéristiques dans les BizCoves qui répondraient rapidement aux demandes de changement et aux rapports de problèmes les plus urgents (p. ex. recherche et filtres, performance améliorée).
• Évaluer la possibilité de réduire le nombre d'environnements et leur complexité.
• Estimer l'effort nécessaire pour mettre la documentation à jour, uniformiser l'utilisation et effectuer une épuration générale.

IV. Projet, configuration et gestion des modifications

Secteurs de réussite

• Il semble qu'on se soit efforcé de planifier et d'exécuter le projet en suivant les pratiques exemplaires en matière de génie logiciel (Microsoft Solutions Framework) et une démarche structurée de développement de logiciel.
• Des plans de projet assortis d'équipes de développement et de processus structurés semblent avoir été en place tout au long du projet (de 2004 à 2007).

Contraintes/Difficultés/Problèmes

• Depuis le commencement du projet, le leadership et la prise en charge semblent avoir été discontinus.
• Le système semble avoir été développé sans qu'on profite du point de vue des utilisateurs et sans que les exigences, les spécifications, les scénarios, les processus, etc., ne fassent l'objet d'une approbation continue. Selon la méthode d'élaboration itérative (voir le Processus rationnel unifié (PRU) à l'annexe C), la rétroaction des utilisateurs doit être obtenue tout au long du cycle de développement, et la discipline de gestion des modifications doit être appliquée dès le commencement du projet. Cette ligne de conduite ne semble pas avoir été suivie pour l'élaboration du SGCI :
  • La situation semble n'indiquer qu'une participation indirecte des utilisateurs (par l'entremise des représentants des analystes du fonctionnement). Nos entrevues confirment que les utilisateurs n'ont participé aux essais d'acceptation par l'utilisateur qu'à un stade avancé du projet (octobre 2006). Un nombre important de problèmes ont été signalés à ce moment-là, mais beaucoup n'ont pu être réglés puisque le projet devait se terminer en avril 2007.
• La communication entre les Opérations et les TI doit être améliorée. De façon générale, il semble que l'équipe de projet n'ait pas bien compris le processus fonctionnel de la CISR, ce qui expliquerait les différents problèmes signalés, comme l'absence d'une fonction de détection et de correction d'erreur dans le système et la mise au point d'un module de mise au rôle sans calendrier en ligne. Les utilisateurs communiquent leurs besoins, mais il est possible qu'ils ne comprennent pas tous les éléments techniques précis à inclure dans le système. Les programmeurs techniques semblent avoir élaboré le SGCI d'après les exigences fournies sans penser à faire tester les solutions techniques par les utilisateurs pour s'assurer qu'elles répondaient effectivement aux besoins opérationnels établis.
• Les plans de projet du SGCI semblent suivre la démarche traditionnelle en cascade où toutes les fonctions sont installées en une seule fois plutôt qu'une démarche itérative où de plus petits groupes de fonctions sont installés sur une période donnée, de façon à pouvoir améliorer la fonctionnalité tout au long du projet.
  • Pendant la phase d'élaboration du projet (de 2004 à 2007), il ne semble pas y avoir eu d'itérations entre les principaux modules (V1 à V4).
  • Pendant la phase de maintenance (de 2007 à ce jour), des itérations ont été effectuées, mais les délais sont considérables (p. ex. de 6 à 9 mois).
• En avril 2007, l'équipe affectée au développement du SGCI a été dissoute, et les ressources possédant une connaissance approfondie du SGCI ont été dispersées. Comme la responsabilité à l'égard du système est maintenant fragmentée entre différents groupes, il est plus difficile de trouver des ressources et cela entraîne des problèmes de communication. Par exemple :
  • Le groupe des TI est responsable de l'équipe de développement du SGCI, des questions touchant à l'infrastructure et à l'installation, et des questions de sécurité;
  • Les Opérations sont responsables de l'analyse des activités et de la formation des utilisateurs;
  • Les bureaux régionaux ont des utilisateurs (multiples);
  • Un comité directeur fournit une orientation.

Questions à approfondir

• Les plans de projet existants et la liste détaillée des demandes de changement et des rapports de problème.
• Vérifier à ce que le plan de projet, l'orientation et les lignes directrices ont été suivis.
• Le rôle des utilisateurs dans les spécifications du SGCI et leur participation pendant le projet.

---

Annexe A - Personnes-ressources interviewées

Les intervenants clés et les membres de l'équipe de projet du SGCI ont été interviewés les 15 et 16 mai 2008 :

1. Brigitte Desmeules - Directrice, Gestion des renseignements opérationnels
2. Bill Couch - Gestionnaire par intérim, Soutien aux systèmes opérationnels
3. Jennifer Waymark - Formation sur le SGCI
4. Penelope Routier - Analyste du fonctionnement
5. François Thinel - Coordonnateur régional / Représentant des utilisateurs
6. Lucie Loignon - Directrice, Systèmes informatisés
7. Bernie Vaz - Architecte d'applications
8. Andrée Forget - Analyste de systèmes
9. Petar Vrzic - Responsable du développement
10. Dan Thanh Nguyen - Développement de l'architecture des données et des applications
11. Troy MacFarlane - Cognos
12. Susan Siu - Directrice générale, Opérations
13. Onnig Beylerian - Dirigeant de la vérification par intérim et chef de l'évaluation

---

Annexe B - Documents examinés (en anglais)

Documents relatifs au SGCI

1. ICMS Overview - PowerPoint
2. ICMS Implementation Overview - PowerPoint
3. ICMS Technical Overview - PowerPoint
4. ICMS R4 Technical Overview, v0.4, 12 mai 2008
5. ICMS Presentation - BizFlow Overview
6. ICMS R4 Logical Environment Diagram
7. Conceptual Design - ICMS - Release 2, v0.8, 26 août 2004, état final
8. Conceptual Design - ICMS - Release 3, v0.4, 16 août 2004, état final
9. ICMS R4 Technical Roadmap
10. ICMS R2-R3 Logical Environment Diagram
11. ICMS R4 EasyButton
12. BizFlow 10 Overview
13. Systems Development Standards
14. ICMS R4 Solution
15. ICMS R4 Big Picture, sans n^o de version (créé le 8 sept. 2005)
16. Release 4 Project Plan, v0.3, 26 sept. 2005
17. Notes - RPD Overview Process, sans n^o de version (créé en mai 2004)
18. Use Cases - ICMS - Release 3, v1.0, 17 août 2004, état final

Documentation et recherche non liées au SGCI

1. IRB - Case Flow Process Overview - 12 mai
2. BPTrends BPMS Report 2007 on BizFlow v10
3. The Forrester Wave^TM: Human-Centric Business Process Management Suites, T1 2006
4. Gartner Magic Quadrant for BPMSs, 2006
5. Q2'08 BPMS Watch Ratings, BPM Institute
6. « The Process Audit », Michael Hammer, Harvard Business Review, avril 2007
7. Getting Past the First BPM Project: Developing a Repeatable BPM Delivery Capability, BPTrends, 2006

---

Annexe C - Pratiques exemplaires en matière de génie logiciel et d'architecture

Notre évaluation technique s'appuie sur trois pratiques exemplaires bien connues dans le domaine du génie logiciel et de l'architecture de système :

• Processus rationnel unifié (PRU) : généralement connu et utilisé, le PRU sous-tend notre analyse du projet du SGCI et de ses résultats attendus. Plus précisément, nous avons utilisé les neuf disciplines principales du PRU.

  Le PRU est utilisé dans le cadre de nombreux et importants projets pluriannuels de développement de logiciel, et il englobe les aspects technique, fonctionnel et humain des grands projets.

  Nous avons utilisé le PRU comme référence pour nous assurer que tous les aspects du projet du SGCI avaient été couverts.

• Développement d'applications de GPF : Derek Miers, de BPTrends, propose une démarche itérative pour les projets de GPF dans son article « Getting Past the First BPM Project: Developing a Repeatable BPM Delivery Capability », paru en 2006.
• Architecture d'entreprise (AE) : Selon les cadres et les méthodes associés à l'AE, six aspects principaux doivent être analysés dans le cadre de l'étude de systèmes et de leur intégration à l'entreprise : activités, données, systèmes d'information (applications), infrastructure technologique, sécurité et gouvernance.

---

Annexe D - Analyse du marché des SGPF, figures et diagrammes

Dans le cadre de l'évaluation technique, nous avons effectué une brève analyse des principales entreprises de recherche sur les technologies afin d'évaluer le système principal du SGCI, son SGPF et l'application BizFlow v10 d'Handysoft.

• Les autres applications du SGCI (Hummingbird, Cognos, etc.) ont été exclues de notre analyse, faute de temps.

Forrester Research (dans son récent examen des SGPF axés sur le facteur humain pour le premier trimestre de 2006) est la seule entreprise qui évalue les produits d'Handysoft.

• BizFlow se classe parmi les applications performantes.
• L'application affiche une présence faible sur le marché.
• Un score faible est alloué pour les fonctions d'analyse et d'optimisation.
• Un score élevé est alloué pour la capacité d'intégration et l'architecture du produit.

BPM Institute (dans son évaluation des SGPF pour le deuxième trimestre de 2008), bien qu'il n'évalue pas le produit BizFlow, fait mention des « fonctions spéciales » et des « propriétés uniques » des produits de gestion des cas. Nous soulignons notamment les points suivants :

• Il insiste sur le fait que la gestion des cas représente un style très différent de GPF axée sur le facteur humain, où les tâches ne sont pas acheminées à des files d'attentes d'exécuteurs de tâches en fonction de règles prédéterminées; les utilisateurs collaborent plutôt à l'exécution de façon ponctuelle.
• Il alloue 50 % du score total des produits de gestion des cas à la collaboration.

BPTrends a examiné BizFlow v10. Elle énumère et analyse les caractéristiques du produit, mais n'offre aucune recherche comparative ni aucun commentaire qualitatif. Quelques observations sont toutefois dignes de mention :

• « La caractéristique la plus impressionnante de BizFlow est peut-être l'interface-utilisateur très souple et configurable. » (BizCoves)
• Gartner n'examine pas BizFlow d'Handysoft dans son dernier Magic Quadrant pour les SGPF, 2006.

---

Annexe E - Réponse de la Direction

En août 2007, la CISR a répondu aux préoccupations des utilisateurs du SGCI en redirigeant vers le STAR les nouveaux cas déférés à la SPR, de manière à permettre l'analyse et la résolution des problèmes liés au système. Les dossiers de la SPR en étaient alors à l'étape de la vérification du FRP.

L'équipe du SGCI, composée de coordonnateurs régionaux, d'analystes du fonctionnement et d'analystes des systèmes, a effectué des vérifications et des simulations destinées à tester toutes les fonctionnalités du traitement des dossiers, allant du renvoi d'un cas au prononcé de la décision, en vue de cerner les problèmes particuliers.

En février 2008, l'équipe du SGCI a rencontré des utilisateurs afin de confirmer les changements nécessaires à l'amélioration du système. L'équipe avait alors dressé une liste de fonctionnalités problématiques. La liste supposait que le SGCI nécessitait des correctifs supplémentaires avant de pouvoir fonctionner pleinement dans le contexte opérationnel. Au fil du temps, les correctifs appropriés seront apportés.

En conséquence, le président a confié au Comité de vérification et d'évaluation le mandat de commander une évaluation technique du SGCI et a demandé à l'équipe du SGCI d'examiner diverses options pour simplifier le système. C'est dans ce contexte que la société KPMG LLP a effectué l'évaluation technique du SGCI.

Le Comité de vérification et d'évaluation de la CISR tient à exprimer son appréciation pour l'analyse d'expertise effectué par les analystes experts de KPMG LLP pour l'examen approfondi et les recommandations pertinentes.

La CISR a nommé Mme Lucie Loignon, une directrice de projet, qui donnera suite à cette évaluation. Dans le cadre de son mandat, Mme Loignon évaluera les ressources requises et déterminera la structure organisationnelle la plus appropriée aux fins de la stratégie de renouvellement. Son équipe travaillera en étroite collaboration avec les utilisateurs et les coordonnateurs pour garantir que les priorités sont définies et que les changements sont apportés aussi rapidement que possible. Mme Loignon mettra bientôt à l'essai une nouvelle méthode pour accroître la souplesse et la rapidité des cycles de développement et d'application, tout en maintenant le mode de production existant du SGCI.

À mesure que la stratégie prendra forme, des réponses plus précises aux recommandations formulées dans l'évaluation technique du SGCI s'ajouteront à la présente réponse de la direction.