Courrier des statistiques N4 - 2020

Poursuivant son exploration des métiers et méthodes de la statistique publique, ce numéro N4 s’intéresse d’abord à une pratique qu’on ne range pas habituellement dans ce domaine : la microsimulation, dynamique ou statique, pratiquée dans un INS ou dans des services ministériels. Deux modèles spécifiques sont détaillés : TRAJECTOiRE, sur le système de retraite et Ines, autour des politiques sociales et fiscales. Quatre papiers sont ensuite consacrés à des références pour le statisticien : en France d’abord, à travers la refonte de la nomenclature des PCS, le programme de refonte du répertoire d’entreprises Sirene et la mise au point du nouvel l’échantillon-maître. L’expérience suédoise ensuite, sur la modélisation des processus statistiques et son impact organisationnel, apporte l’éclairage externe que nous affectionnons. Enfin, un panorama sur le système d’information du logement en France, dans sa globalité, vient conclure ce numéro.

Courrier des statistiques
Paru le : Paru le 29/06/2020
Johan Erikson, propriétaire de processus, département du développement des processus et des méthodes, Statistiska centralbyrån (SCB)
Courrier des statistiques - Juin 2020
Consulter

Le modèle de processus statistique en SuèdeMise en œuvre, expériences et enseignements

Johan Erikson, propriétaire de processus, département du développement des processus et des méthodes, Statistiska centralbyrån (SCB)

L’institut national statistique suédois (SCB) a développé son modèle de processus statistique en 2007. Comme le GSBPM, modèle générique de description des processus de production statistique diffusé à grande échelle en 2009, il se fonde sur les travaux de Statistics New Zealand. Les deux modèles ont été développés en parallèle : malgré certaines différences, ils sont très proches l’un de l’autre. Des normes, des lignes directrices, des modèles et des listes de contrôle, ainsi que des outils informatiques ont été décrits et diffusés au sein de l’institut suédois, par le biais d’une infrastructure servant de support à la démarche. On a ainsi posé les bases d’une approche de la production statistique standardisée et « orientée processus ».

À l’œuvre depuis 2008, la démarche a radicalement changé l’organisation du SCB. En outre, depuis 2014, l’institut est certifié selon la norme internationale ISO 20252, dont tous les critères ont été incorporés à l’infrastructure associée au modèle. L’ensemble est maintenant largement implanté au sein du SCB, non sans avoir dû surmonter quelques difficultés : l’acceptation par les parties prenantes, l’identification des informations pertinentes et le maintien à jour des éléments constitutifs. Utilisé depuis plus de dix ans, le dispositif pourra se développer, par exemple en créant une version adaptée à chaque produit statistique, ou en étendant son usage à d’autres autorités responsables de la statistique publique en Suède.

Cet article décrit la mise en œuvre du modèle de processus suédois et de l’infrastructure qui supporte le modèle (Process Support System), dans une démarche d’ « orientation processus » de la production statistique (Process Oriented Production). Nous décrirons en premier lieu le modèle suédois, ses similitudes et ses légères différences avec le GSBPM, modèle générique international pour les processus statistiques. Nous présenterons ensuite brièvement le système de la statistique publique en Suède : en nous remettant dans le contexte de la création et de la mise en œuvre du modèle et de l’infrastructure associée, nous identifierons les facteurs de réussite qui ont abouti à la généralisation de leur utilisation au sein de l’institut national statistique suédois Statistiska centralbyrån (SCB). Nous étudierons ensuite les changements intervenus depuis que les dispositifs ont été créés, la conformité aux systèmes et certains des principaux défis auxquels nous avons été confrontés au fil du temps. Pour finir, nous présenterons les principales idées quant à l’évolution future.

Le GSBPM, ...

Le modèle générique de description des processus de production statistique (GSBPM pour Generic Statistical Business Process Model) décrit les différentes étapes à suivre pour produire des statistiques publiques. Développé en 2008 par le groupe de travail commun Unece/Eurostat/OCDE sur les métadonnées statistiques (METIS, cf. https://stats.oecd.org/glossary/detail.asp?ID=5494), il se fondait initialement sur le modèle conçu par Statistics New Zealand. La première version utilisée à grande échelle a été publiée en 2009 (version 4.0) et largement adoptée par la communauté mondiale de la statistique publique.

Le GSBPM structure le processus de production statistique en le divisant en plusieurs phases et sous-processus, avec à chaque fois une description des éléments inclus dans le processus ou le sous-processus et des travaux effectués en son sein (figure 1). Le GSBPM est un modèle de référence. Il peut donc, et est conçu pour, être utilisé de différentes façons par différents services, selon ce qui leur semble approprié.

Il est lié à d’autres modèles développés afin de décrire les travaux des services statistiques, à savoir :

  • le « modèle générique d’activité des organismes statistiques » (GAMSO pour Generic Activity Model for Statistical Organizations), qui décrit les activités de haut niveau des services statistiques ;
  • et le « modèle générique d’informations statistiques » (GSIM pour Generic Statistical Information Model), un cadre de référence pour les informations statistiques.

Le GAMSO et le GSIM ont tous les deux été développés après le GSBPM et s’inscrivent dans sa continuité.

Le modèle GSBPM complet est accessible sur le site de l’Unece (Unece, 2019). Une bonne description de sa première version, ainsi que de la façon dont il a été développé, est disponible dans (Vale, 2009).

 

Figure 1. Niveaux 1 et 2 du modèle générique de description des processus de production statistique (GSBPM)

 

Source : version 5.1 sur le site de l’Unece (https://statswiki.unece.org/display/GSBPM/GSBPM+v5.1).

 

... le modèle de processus suédois, ...

Le modèle de processus suédois a été développé en 2007, indépendamment du GSBPM mais en parallèle avec lui. Il se fondait également sur les travaux de Statistics New Zealand (Pearson et Savage, 2007). Il a été créé dans le cadre d’un projet de modernisation et de standardisation de grande envergure, appelé Lotta (voir infra), et mis en œuvre par le Statistiska centralbyrån (SCB) entre 2006 et le début 2008.

Le modèle de processus standardisé jouait un rôle important dans cette approche, car il définissait la liste des processus et sous-processus pour lesquels il fallait rassembler et développer des normes. La première version du modèle de processus suédois a été établie en octobre 2007 et n’a subi que des révisions mineures depuis lors. La figure 2 présente sa version actuelle.

 

Figure 2. Le modèle de processus suédois est structuré autour de neuf phases

 

 

... et la différence entre les deux

Si l’on examine les deux modèles, on peut identifier quelques différences, les principales étant les suivantes :

  • le GSBPM comporte huit phases, assorties de processus transverses, tandis que le modèle suédois comprend une neuvième phase (Support et infrastructure) qui remplace les processus transverses. En outre, la phase transversale d’Évaluation ne contient pas de sous-processus dans le modèle suédois alors qu'elle se subdivise en trois dans le GSBPM ;
  • la phase de Définition des besoins est abordée différemment dans les deux modèles ;
  • dans la phase de Conception, le modèle suédois comprend des sous-processus spécifiques pour la diffusion et la communication, et sépare la conception du traitement et de l’analyse en deux sous-processus distincts, tandis que le GSBPM établit un sous-processus séparé pour concevoir la description des variables. De plus, le modèle suédois ajoute un sous-processus pour planifier le cycle de production ;
  • le GSBPM fait la différence entre l’élaboration d’outils à des fins de traitement et d’analyse d’une part, et à des fins de diffusion d’autre part, établissant pour cela deux sous-processus, tandis que le modèle suédois rassemble ces deux activités dans le même sous-processus ;
  • dans la phase de Collecte, le modèle suédois distingue la création de la base de sondage et le tirage de l’échantillon, le GSBPM rassemblant ces deux activités dans le même sous-processus ;
  • les sous-processus de la phase de Traitement diffèrent légèrement dans les deux modèles ;
  • dans les phases de Construction, de Collecte et de Traitement, le GSBPM comprend des sous-processus pour la finalisation de la phase, mais ces sous-processus ne sont pas explicites dans le modèle suédois.

Si l’on regarde de plus près, en examinant la description détaillée de chaque phase et de ses subdivisions, on s’aperçoit que, au niveau du contenu, les différences sont minimes. Les deux modèles couvrent les mêmes étapes de travail, mais les attribuent dans certains cas à des sous-processus différents. C’est la raison pour laquelle on peut affirmer que, malgré quelques différences subtiles, les deux modèles sont très proches. Lorsque le GSBPM a été présenté au SCB, comme lorsque des révisions majeures ont été apportées au modèle suédois, des discussions ont eu lieu en interne afin de décider s’il fallait s’en remettre entièrement au GSBPM ; mais l’institut a jusqu’à présent préféré conserver son propre modèle. Celui-ci est bien connu au sein du SCB, le Process Support System est structuré en conséquence et somme toute, les différences sont minimes.

L’institut suédois a joué un rôle actif dans le développement du GSBPM au fil du temps, et a participé à chaque révision depuis 2009. Il a également pris part au projet MEMOBUST (méthodologie pour la modernisation des statistiques d’entreprises, voir https://ec.europa.eu/eurostat/cros/content/memobust_en) d’Eurostat, qui, de fait, traite beaucoup de ce que le Process Support System gère déjà : la collecte des méthodes et des guides relatifs à la production des statistiques d’entreprises, selon la grille des sous-processus du GSBPM. Le SCB a beaucoup œuvré dans ce projet pour fonder ses résultats sur le GSBPM.

Le système de la statistique publique en Suède

En Suède, la statistique publique est régie par une loi sur les statistiques officielles (« Lag (2001:99) om den officiella statistiken ») et par un décret (« Förordning (2001:100) om den officiella statistiken »). Depuis 1994, la Suède applique un système décentralisé pour la production des statistiques publiques. Aujourd’hui, 28 agences gouvernementales sont responsables de la statistique publique relative à leur domaine respectif.

Les statistiques sont elles-mêmes réparties entre plusieurs « sujets », « domaines » et produits. À l’heure actuelle, il existe 22 sujets, 112 domaines et 356 produits. Chaque agence étant responsable d’un ou de plusieurs domaines statistiques, il peut y avoir plus d’une agence responsable d’un sujet donné.

Le SCB joue deux rôles au sein du système : en premier lieu, il fait partie des 28 agences responsables de la statistique (pour 45 domaines inclus dans 13 sujets) ; en second lieu, en tant qu’institut national de statistique, il coordonne la globalité du système statistique public et évalue la qualité de la statistique publique.

Un conseil de la statistique publique (« Rådet för den officiella statistiken »), rassemblant les dirigeants des 28 agences, a été créé en 2002. Le Conseil compte douze délégués, dont six permanents et six tournants, avec une rotation tous les trois ans. Deux nouveaux délégués sont élus chaque année. Il est présidé par le directeur général du SCB.

Aujourd’hui, le Statistiska centralbyrån est organisé comme suit :

  • un département dédié à la collecte ;
  • quatre départements dédiés à différents « sujets » ;
  • un département dédié au développement des processus et des méthodes ;
  • un département dédié à la communication ;
  • un département informatique.

Il existe également un service des ressources humaines et un service administratif, ainsi qu’un cabinet exécutif central assurant la gestion de l’institut. Ce cabinet exécutif gère aussi ce qui relève des missions d’un employeur et d’une agence gouvernementale administrative (figure 3).

 

Figure 3. Organigramme du Statistiska centralbyrån (SCB)

 

Disponible à l’adresse suivante : https://www.scb.se/en/About-us/main-activity/organisation/.

 

Pourquoi le SCB a décidé de mettre en œuvre un modèle de processus

En 2005, l’environnement de production du SCB était largement décentralisé. Cela découlait pour partie du passage d’une unité centrale à des ordinateurs individuels vers la fin des années quatre-vingt-dix, et pour une autre partie, de la nature extrêmement décentralisée de notre institution : chaque département dédié à un thème (sujet) était responsable de ses propres processus de production, appliquait ses propres méthodes et avait ses propres experts informatiques. Dans ce contexte, chacun avait plus ou moins son propre système informatique pour la production de ses statistiques, selon ses propres développements. Les différences étaient grandes dans la manière d’exécuter chaque tâche des processus de production. En outre, les systèmes informatiques étaient déjà anciens et avaient besoin d’être reconstruits, sans parler du fait qu’ils ne faisaient l’objet d’aucune documentation et que leur maintenance était coûteuse. Enfin, il était devenu également coûteux et difficile d’introduire de nouvelles méthodes et solutions techniques pour ces systèmes dans un tel environnement informatique.

Deux exemples en témoignent : la collecte de données sur internet et la nouvelle méthode de contrôle sélectif. Dans les deux cas, il semblait inefficace de développer des solutions spécifiques à chaque enquête, et il était donc naturel de développer des solutions centrales communes. Mais pour les mettre en œuvre dans l’ensemble du SCB, il était nécessaire de procéder à de nombreuses intégrations dans le système spécifique à chaque enquête. Cela avait conduit à une « architecture spaghetti », exigeant de consacrer beaucoup de temps à la maintenance de toutes les intégrations.

En plus de tout cela, de nombreux experts du SCB allaient partir en retraite au cours des années suivantes, des experts qui connaissaient parfaitement les processus de production statistique « locaux ». Cela était également le cas pour de nombreux informaticiens. Il aurait alors fallu transmettre à d’autres personnes les connaissances relatives au fonctionnement de chaque enquête et de son système informatique spécifique.

Le SCB a donc pris la décision stratégique de lancer un projet de modernisation et de standardisation, le projet Lotta (Le projet et l’organisation des processus sont décrits dans (Jorner, 2008)). Son but était de réduire le nombre de systèmes de production et d’améliorer l’efficacité de la production statistique. Afin d’atteindre cet objectif, il a été décidé d’adopter une approche « orientée processus » de la production statistique (Process Oriented Approach) et de rassembler, développer et définir des méthodes, traitements automatisés et outils standardisés pour tous les sous-processus. On considérait que cela permettrait également « d’institutionnaliser » les connaissances sur les procédures ainsi standardisées.

Dans le cadre de ce projet, le SCB a développé et défini un modèle de processus permettant de décrire tous les processus de production. S’appuyant sur les travaux effectués par Statistics New Zealand, cela a abouti en octobre 2007 au modèle de processus suédois.

Impact sur l’organisation

La décision d’adopter une perspective axée sur les processus pour rationaliser la production statistique allait avoir un impact sur l’organisation du SCB, et placer le nouveau modèle standardisé de processus sur le devant de la scène.

Pour stimuler la progression vers la standardisation et vers des outils informatiques communs, il a été décidé de créer un département des processus, comprenant des propriétaires de processus (ou Process Owner) pour tous les sous-processus inclus dans la production statistique de l’institut. Les propriétaires de processus allaient être responsables du développement et de la maintenance des méthodes, traitements automatisés et outils standardisés. En outre, tous les agents traitant de la méthodologie ou de l’informatique ont été regroupés au sein de ce département des processus, qui a vu le jour le 1er janvier 2008.

Il a également été décidé de développer toute une infrastructure (Process Support System) rassemblant toutes les normes ainsi définies, et de fonder ce système sur le modèle de processus suédois.

Des propriétaires de processus ont été nommés pour cinq domaines définis à partir des sous-processus du modèle :

  • Définition des besoins, Diffusion et communication ;
  • Conception et planification, Construction et essai ;
  • Collecte ;
  • Traitement et analyse ;
  • Évaluation et retour d’information, Support et infrastructure.

Pour chaque domaine, un propriétaire de processus, et un adjoint, ont été nommés. Chaque domaine a également reçu un budget pour la maintenance des normes et outils existants et pour le développement de nouvelles normes. Il était prévu que les grands projets de développement informatiques soient initiés par les propriétaires de processus, mais financés par les ressources propres du SCB qui devaient également couvrir d’autres types de projets – tels que ceux consacrés au développement du contenu statistique – mais se concentrer en priorité sur le développement de processus.

Les personnes travaillant à la production statistique restaient dans les départements dédiés à leurs sujets d’étude, mais devaient également se consacrer à la collecte des données et à la communication. Cela a donné lieu in fine à l’établissement d’une structure « matricielle » contenant à la fois les processus/sous-processus et les produits statistiques.

Deux des dernières initiatives du projet Lotta ont consisté à préparer d’une part une première décision sur les normes, d’autre part une décision sur la façon dont l’infrastructure commune serait conçue :

  • sur le premier point, il a fallu examiner les outils, méthodes et traitements automatisés déjà utilisés par le SCB, puis faire la liste de ceux qui deviendraient des normes dans la nouvelle approche de travail orientée processus. Un grand nombre de sous-projets dans le projet Lotta avaient établi des normes et des outils. On estimait que cela serait très utile pour identifier les sujets dans lesquels les normes faisaient encore défaut. Le directeur général décidait des normes, et les propriétaires de processus allaient être chargés de leur maintenance et de leur développement ;
  • pour le deuxième aspect, il a été décidé de fonder le Process Support System sur MS SharePoint, où toutes les normes et tous les outils devaient être décrits et rendus accessibles aux utilisateurs. Hormis les outils informatiques, il était prévu qu’il contienne des traitements automatiques standardisés, ainsi que des outils de support tels que les listes de contrôles (checklists), les modèles et d’autres éléments nécessaires à l’application des normes. Les propriétaires de processus ont été chargés d’alimenter toute cette infrastructure logicielle et documentaire. Ce fut un travail considérable, mobilisant de nombreuses personnes dans l’institut, et une première version a été publiée dès septembre 2008. Le Process Support System avait – et a toujours – une architecture simple, construite à partir d’une version « cliquable » du modèle de processus suédois. Chaque phase et chaque sous-processus (qui peut être divisé en pages supplémentaires ou en sous-processus secondaires plus détaillés selon les besoins) comprend une description sur une page, divisée en quatre parties (figure 4) :
    • une courte description du processus ou du sous-processus et de son objectif ;
    • les intrants (input) : ce qui doit avoir été fait avant de démarrer le processus, et source des informations requises (avec des liens vers les sous-processus précédents, le cas échéant) ;
    • la réalisation : une description détaillée de la façon dont le processus doit être exécuté, y compris des liens vers les outils appropriés et une description des normes à appliquer (dont modèles, listes de contrôle, etc.) ;
    • les extrants (output) : les résultats en sortie du processus.

 

Figure 4. Exemple de structuration sur l’infrastructure logicielle et documentaire

 

 

L’infrastructure logicielle que constitue le Process Support System est toujours pleinement utilisée aujourd’hui. Elle joue un rôle légèrement différent de celui du modèle standardisé de processus : son principal objectif est de présenter les normes définies par le SCB qui doivent être appliquées par tous les utilisateurs des processus (il existe un processus spécifique à appliquer en cas d’exception, si, pour une raison ou pour une autre, on ne peut pas respecter une norme donnée). Si la description des phases et des sous-processus est générique dans le GSBPM, les descriptions incluses dans le Process Support System sont en revanche détaillées, précises et spécifiques au SCB.

L’utilisation d’un modèle général et standardisé de processus a permis d’une part de créer de nouveaux outils informatiques standardisés, et d’autre part, de faciliter la communication entre ces outils puisque ils sont reliés aux processus. Parallèlement, ces outils ont rendu la production plus efficace, notamment à l’étape de la collecte des données. Grâce à la standardisation, les coûts liés à l’apprentissage de nouveaux outils informatiques ont diminué et il est plus facile de travailler sur différentes productions statistiques. Bien que la standardisation puisse engendrer une certaine perte de flexibilité, globalement l’institut estime avoir atteint un grand nombre des objectifs fixés avant de débuter la démarche d’ « orientation processus » de la production statistique.

Certification ISO 20252 et mise en œuvre dans le Process Support System

Cette infrastructure commune, et en conséquence le modèle standardisé de processus suédois sur lequel elle s’appuie, ont pris de plus en plus d’importance entre 2008 et 2014. Dès mars 2008, le directeur général avait décidé que le SCB demanderait à être certifié suivant la norme internationale ISO 20252 (destinée aux services menant des études de marché, des sondages d’opinion et des recherches sociales).

Des recherches préliminaires ont souligné que le SCB devrait fournir de gros efforts pour parvenir à la conformité avec cette norme. Il était notamment nécessaire d’en interpréter certaines parties de façon plus approfondie, et surtout de développer de nouvelles normes. Ces travaux ont été réalisés dans le cadre d’un projet mené de décembre 2008 à décembre 2009, visant à aboutir pour le début de l’année 2010 au plus tard.

Lors d’un processus de certification ISO, le système d’assurance-qualité doit avoir été mis en place et utilisé pendant une période assez longue avant que la certification puisse être accordée. Pour chaque critère défini dans la norme, SCB s’est demandé s’il fallait établir une solution commune ou des instructions spécifiques à chaque production quant à la façon dont la norme pouvait être respectée. Il a été décidé d’inclure dans le Process Support System à la fois des solutions communes et des instructions, afin que, si une production est conforme aux normes définies dans le système du SCB, elle soit automatiquement jugée conforme aux exigences de la norme ISO 20252. Cette intégration des exigences de l’ISO 20252 a également permis à SCB d’en imposer de plus strictes lorsque cela semblait nécessaire, et de combiner les standards internes avec les critères externes de la norme ISO.

Le Process Support System était quasiment à jour à la fin 2010 ; mais la norme ISO exige une solution technique permettant de surveiller les enquêtes téléphoniques, que le SCB ne possédait pas encore, et la certification était donc impossible à obtenir avant d’avoir installé une telle solution. Cela a pris un certain temps. Le SCB a fini par obtenir la certification en mars 2014. Le parcours vers la certification est décrit dans (Hoff et alii, 2010) et (Bergdahl et alii, 2014).

Facteurs de réussite : intensité, sponsor et moteurs d’une approche globale

Le projet Lotta, la mise en œuvre d’un modèle de processus très proche du GSBPM, la mise au point d’une vaste infrastructure opérationnelle commune (Process Support System), la création du département des processus et la certification à la norme ISO 20252 – autant d’initiatives étroitement liées et mises en œuvre durant une période intense (2006-2010). Ces changements ont indéniablement été contraignants pendant ces quelques années, mais constituent cependant nos principaux facteurs de réussite.

Un profond sentiment de l’urgence prévalait, à tous les niveaux de l’institut. Les changements étaient conduits et appuyés par le top management, et traités de façon cohérente. Les collaborateurs qui n’étaient pas directement concernés n’étaient peut-être pas de cet avis, pris au beau milieu d’un ouragan de changements : mais si toutes les évolutions avaient été introduites une par une, le projet n’aurait sans doute pas réussi.

La standardisation et le Process Support System n’auraient probablement pas abouti sans qu’un certain groupe de personnes ne s’organise pour faire avancer le développement et la mise en œuvre (les propriétaires de processus). Si on n’avait pas fixé l’objectif de certification ISO 20252, le système ne serait peut-être pas devenu un outil central de support et de définition des orientations pour les différentes productions. Et, sans modèle réellement standardisé, il aurait été beaucoup plus difficile d’étendre les normes et les orientations à l’ensemble du SCB. Il a en effet permis d’établir une interprétation commune des différentes phases de la production statistique, et a fourni un cadre permettant à la fois de décrire et d’identifier les normes, les orientations, les outils et les supports. Le modèle standardisé de processus et l’infrastructure qui supporte ce modèle ont défini un cadre approprié pour vérifier la conformité aux normes existantes.

Changements au fil du temps

Entre 2010 et 2016, l’organisation interne et les systèmes sont restés relativement stables. L’institut était concentré sur le développement d’outils informatiques communs pour différents processus ; les fonctions informatiques ont quitté le département des processus pour intégrer leur propre unité en 2010. À noter toutefois que le développement informatique était toujours initié par les propriétaires de processus. Le département des processus et le département informatique travaillaient alors en étroite collaboration. Les procédures automatisées et les normes internes étaient toujours sous la responsabilité du département des processus et étaient mises à jour en continu. Le système constitué d’un département dédié aux processus en général et de propriétaires de processus a très peu évolué. Les responsabilités et les sous-processus attribués à chaque propriétaire ont légèrement changé, mais l’organisation principale est restée la même. Une description plus détaillée de l’environnement de production commun est fournie dans (Erikson et Odencrants, 2016).

Des changements organisationnels plus importants ont été apportés à partir de 2017. Des discussions avaient déjà eu lieu sur les frontières et responsabilités, entre département des processus et département R&D. Il devenait nécessaire de renforcer nos capacités de développement et d’améliorer l’efficacité des projets, ainsi que d’assurer une mise en œuvre plus rapide des résultats des projets. Dans cette optique, les deux départements ont fusionné en un nouveau « département du développement des processus et des méthodes ». L’institut a également décidé de mettre en œuvre un nouveau modèle de maintenance. Ces deux décisions ont engendré des changements dans les rôles et les responsabilités.

Les anciens propriétaires de processus ont été remplacés par des responsables de la maintenance, avec un seul propriétaire pour le processus de production statistique dans son ensemble. Puisque les responsables de la maintenance étaient dorénavant situés dans des départements différents au sein de l’institut, la maintenance du Process Support System s’est trouvée quelque peu décentralisée. Aujourd’hui, c’est à la fois aux responsables de la maintenance et au propriétaire de processus qu’il appartient d’assurer la cohérence et la mise à jour. Mais le rôle du Process Support System et du modèle standardisé de processus reste le même. Le système contient toujours les normes à appliquer, et le principe est toujours valide, selon lequel, si un produit suit le standard, il est automatiquement jugé conforme à la norme ISO 20252. C’est l’organisation autour de laquelle le système s’articule qui a changé, et non pas le système lui-même ou son objectif.

Conformité au cadre de référence

Dans la mesure où les exigences de la norme ISO 20252 sont intégrées au Process Support System, les utilisateurs des processus sont fortement incités à utiliser ce système et ses normes.

La conformité est vérifiée par un auditeur externe qui mène chaque année un audit de conformité à la norme ISO 20252 (grâce à un échantillon aléatoire de produits), ainsi que par des contrôleurs-qualité internes qui vérifient à la fois la conformité à l’infrastructure et la qualité de l’infrastructure elle-même et des orientations qu’elle contient. L’audit qualité interne est organisé de façon à examiner l’utilisation de tous les sous-processus sur une période glissante de trois ans.

Bien que les audits identifient parfois des écarts par rapport aux normes existantes, on peut dire que globalement la conformité est plutôt satisfaisante dans l’ensemble du SCB. Ce système est utilisé depuis dix ans et l’institut y est maintenant habitué. Les propriétaires de produits savent qu’ils peuvent faire – et feront assurément – l’objet d’un audit de conformité. Les auditeurs externes vérifiant la conformité à la norme ISO se sont dits très impressionnés par le Process Support System et l’ont jugé excellent en termes de conformité à la norme et de qualité du processus de production statistique.

Ce qui précède montre que la création et la mise en œuvre d’une approche de la production statistique orientée processus a globalement réussi en Suède. Toutefois cela n’a pas été sans difficulté. Les trois principaux défis rencontrés durant cette période ont été l’acceptation, la facilité pour les utilisateurs des processus d’identifier les informations pertinentes et la mise à jour de ces informations.

Trois nouveaux défis : accepter, ...

La standardisation pose toujours des problèmes en termes d’acceptation. Certaines personnes se demandent pourquoi elles doivent changer ce qui fonctionne bien. Une procédure standardisée peut être pertinente pour le SCB dans son ensemble, mais pas nécessairement pour chaque utilisateur. La nécessité d’une standardisation est remise en question par des personnes expérimentées qui connaissent les batchs actuels par cœur grâce à une longue expérience. La standardisation peut être considérée comme un frein à la créativité. Les normes elles-mêmes, ainsi que la pertinence de leur mise en œuvre (par exemple afin d’obtenir une certification), peuvent également être remises en question. Toutes ces situations ont été rencontrées lors de l’implémentation.

Le modèle de processus a été accusé de trop simplifier, de ne tenir compte ni des différences entre les types de produits, ni des complexités de la production statistique dans la pratique. Les normes, ainsi que la décision de demander la certification, ont été remises en question. Des collaborateurs expérimentés ont craint de devenir les « esclaves » des listes de contrôle, d’être contraints dans leur libre arbitre.

Ce type de discussion survient encore de temps à autre, si quelqu’un pense qu’il y a de meilleures manières de faire que les normes existantes, et qu’il est empêché de les utiliser comme bon lui semble. Pour répondre à ces arguments, il est important de débattre ouvertement des avantages de la standardisation, de créer un sentiment d’implication personnelle des utilisateurs des processus dans le développement des normes et d’obtenir le ferme support de la direction en vue des changements. Lors du développement, la direction a apporté un support inébranlable, ce qui a joué le rôle le plus important pour surmonter cette difficulté. On a également tenté de traiter ce problème en continu et, s’il persiste dans une certaine mesure aujourd’hui, il concerne des normes, modèles et outils informatiques particuliers et leur mode d’utilisation, plutôt que le concept global de l’orientation vers les processus et de la standardisation. C’est positif et beaucoup plus facile à gérer. Rappelons également que, aux alentours de 2010, il s’est avéré que certaines des statistiques du SCB contenaient des erreurs importantes, et il a fallu fournir de gros efforts pour améliorer la qualité de la production. Pour ce faire, les normes ont été très utiles, ce qui a renforcé l’acceptation de l’approche de travail axée sur les processus.

... identifier les informations pertinentes, ...

Le modèle de processus et l’infrastructure qui le supporte contiennent de gros volumes d’informations. Et toutes les normes ne s’appliquent pas à tous les types d’enquêtes. Par exemple, certaines normes ne concernent que les enquêtes par sondage avec collecte de données primaires, tandis que d’autres s’appliquent aux collectes fondées sur des données administratives. De très nombreux traitements automatiques standardisés sont liés à différents modes de collecte des données, et les enquêtes utilisent des modes différents. Les enquêtes obligatoires sont assorties de règles très strictes qui ne concernent pas les enquêtes facultatives. Il existe également des différences selon que l’on s’intéresse à des particuliers ou à des entreprises, etc.

Pour ces raisons, s’agissant de nombreux sous-processus, il est nécessaire d’identifier les normes applicables aux produits concernés, et uniquement ces normes. Cela peut parfois être difficile. En outre, on risque de passer à côté d’informations importantes. Certains de ces problèmes ont été abordés en divisant davantage les sous-processus et en créant des documents globaux, par exemple pour la production statistique fondée sur des répertoires et pour la vérification et la validation dans l’ensemble du processus de production. Mais cela n’a résolu qu’une partie de la difficulté. Beaucoup de collaborateurs estiment toujours qu’il est difficile d’identifier toutes les informations nécessaires, et cela affecte également l’acceptation des normes en général. Ceux qui ne trouvent pas ce qu’ils cherchent sont plus susceptibles de rejeter le système dans son ensemble. C’est là le défi le plus important à relever et gérer en continu.

... et maintenir les informations à jour

Comme on a vu plus haut, le Process Support System contient de gros volumes d’informations. Or, pour qu’il soit accepté au sein du SCB, il est impératif que tout soit à jour et pertinent. Cela a deux conséquences. Premièrement, lorsque les traitements automatisés ou les normes changent, il est important que les informations incluses dans l’infrastructure opérationnelle commune soient mises à jour en conséquence. Ce peut être une difficulté, surtout si les personnes qui mettent à jour ou développent une norme ne sont pas celles qui ont la responsabilité des informations incluses dans le système. C’est une chose de développer une norme ou un outil, mais c’en est une autre d’en faire la description dans des routines pouvant être intégrées à l’infrastructure. Pour cette raison, il arrive parfois que la nouvelle norme ne soit pas décrite immédiatement dans le système, ce qui pose problème. Il peut aussi arriver que les changements affectent plusieurs sous-processus dont la maintenance est assurée par différents responsables, ce qui peut engendrer des incohérences si toutes les parties concernées ne sont pas mises à jour au même moment. Dans d’autres cas encore, il peut être difficile de décider de la partie du modèle standardisé la plus appropriée pour y affecter les informations : doivent-elles être intégrées à un processus de conception, à un processus de réalisation ou bien à la phase Support et infrastructure ?

S’agissant de la mise à jour des informations, une autre complication découle du fait que toutes les normes ne changent pas au fil du temps, ou du moins pas très souvent. Ainsi, certaines normes développées il y a cinq ou dix ans sont encore utilisées de la même façon aujourd’hui. Lorsqu’il est confronté à un processus créé et mis à jour pour la dernière fois en 2013, l’utilisateur n’est pas assuré que ces informations soient toujours pertinentes. Dans ce cas, il a du mal à accepter le système dans son ensemble. Pour résoudre ce problème, l’idée a été d’attribuer à chaque sous-processus non seulement la date de la dernière mise à jour mais aussi la dernière date à laquelle les informations ont été vérifiées et confirmées comme étant pertinentes. Cela permet de dire, par exemple, que les informations ont été mises à jour en 2013 mais vérifiées en 2020 et sont par conséquent à jour. Cette approche a amélioré les choses et semble permettre de surmonter la difficulté.

Évolution future : quelques voies à explorer

La mise en œuvre d’une production statistique « orientée processus », fondée sur un modèle commun, a été pour l’essentiel une réussite, malgré les difficultés évoquées plus haut. Le modèle standardisé est désormais bien établi en tant que moyen de description du processus de production statistique, et l’infrastructure fondée sur ce modèle est utilisée dans l’ensemble du SCB. Mais cela ne veut pas dire qu’il ne reste plus rien à améliorer ou à développer. Trois évolutions potentielles prioritaires ont été identifiées :

  • une meilleure ergonomie : comme nous l’avons vu, le plus gros défi repose sur la capacité de nos collaborateurs à identifier facilement des informations pertinentes et à jour, afin d’assurer un bon niveau d’acceptation. Plusieurs idées ont été avancées pour optimiser l’ergonomie du Process Support System, notamment des approches sur mesure pour les différents types de statistiques, ainsi que des descriptions plus globales pour les sujets couvrant plusieurs parties du processus de production. Il a également été suggéré d’inclure une plus grande partie du cadre juridique relatif à la production statistique, et d’établir un lien avec les évolutions stratégiques du SCB. Pour inclure de plus gros volumes d’informations, il faudra réfléchir de façon plus approfondie à la façon dont elles peuvent être présentées, afin que l’ergonomie ne se dégrade pas en raison de volumes trop importants, mais s’améliore au contraire grâce à l’inclusion d’informations plus pertinentes ;
  • une utilisation plus adaptée aux produits : dès le début, des idées ont été suggérées pour créer une perspective radicalement différente sur le Process Support System et pour l’adapter de sorte que chaque produit reçoive les informations nécessaires, mais pas plus. Il devrait être possible d’identifier les informations nécessaires à un produit donné si l’on a accès à des informations sur ses choix de conception de base. On a tenté de mettre ces idées en pratique dans le cadre de la collecte des données avec un système « basique » d’assurance-qualité : chaque produit fournit des informations quant à sa conception, à partir desquelles une liste d’opérations d’assurance-qualité est établie pour le produit concerné. Cela consiste à filtrer les opérations pertinentes à partir d’une liste brute d’opérations potentielles, en fonction des choix de conception du produit. Cette version simple est déjà prometteuse (figure 5) mais, pour fonctionner pleinement, elle devra couvrir la totalité du processus de production statistique. Elle devra devenir plus « intelligente » qu’elle ne l’est aujourd’hui, pour présenter un outillage (tels que les modèles et les listes de contrôle) adaptés à des choix de conception spécifiques. Pour être vraiment utile aux personnes chargées de la production statistique, elle devra également permettre d’ajouter des informations spécifiques aux enquêtes, ainsi qu’une description de la façon dont un produit utilise une norme donnée. Par ailleurs, les choix de conception servent à créer un domaine pour chaque produit, où il est possible d’accéder aux outils pertinents et où les données du processus relatives à la production peuvent être présentées. À l’heure actuelle cela se limite à la collecte des données, mais il est prévu d’étendre cette utilisation à toutes les phases du processus de production statistique.

 

Figure 5. Cadre d’assurance-qualité pour une enquête spécifique

 

 

  • un même système pour l’ensemble de la statistique publique en Suède : comme on l’a décrit supra, la responsabilité de la statistique publique en Suède est répartie entre 28 agences différentes. Pour l’instant, le Process Support System n’est utilisé que par le SCB. Mais le débat est ouvert : les autres agences pourraient ou devraient-elles l’utiliser ? Dans l’affirmative, il devrait probablement y avoir deux versions du système, l’une spécifique au SCB et l’autre plus générique pour toutes les agences. À ces fins, il sera essentiel de définir un terrain d’entente, sous la forme du modèle de processus, sans quoi il serait extrêmement difficile d’établir une interprétation commune des éléments à relier aux normes et aux traitements automatisés. Si les autres agences ont leur propre modèle de processus, cela pourrait également nécessiter des ajustements, et il faudrait faire des compromis pour établir un modèle commun. Un test à portée limitée sera mené au printemps 2020 afin de déterminer si les informations sont utiles à d’autres agences.

Compte tenu de ces potentielles évolutions futures, le modèle standardisé de processus et tous les éléments qui y sont rattachés continueront indéniablement de jouer un rôle important dans l’infrastructure du SCB.

METIS (METadata Information System) a réuni l’Unece (United Nations Economic Commission for Europe ou Commission économique pour l’Europe des Nations unies), Eurostat et l’OCDE (Organisation de coopération et de développement économiques).

Voir https://ec.europa.eu/eurostat/cros/content/memobust_en.

Un grand nombre de ces systèmes avaient été rapidement développés ou modifiés à cette époque en raison de craintes quant à l’impact potentiel du « bug de l’an 2000 ».

Le projet Lotta est nommé ainsi car c’était le prénom fêté le jour du lancement, le 13 mai.

L’ISO 20252, norme internationale publiée en 2006, définit les termes et les exigences pour un système de management de la qualité, applicables aux entreprises et aux professionnels réalisant des études de marché, des études sociales et des études d’opinion.

Pour en savoir plus

UNECE, 2019. Generic Statistical Business Process Model GSBPM. [en ligne]. Janvier 2019. Version 5.1. [Consulté le 19 juin 2020].

BERGDAHL, Heather, COLLIN, Marie, ELLTING, Pernilla, LISAI, Dan, PETTERSSON, Åke et HOFF, Sara, 2014. The final steps of the journey towards an ISO certification. Implementing ISO 20252 for Market, Opinion and Social Research at Statistics Sweden. [en ligne]. 2-5 juin 2014. European Conference on Quality in Statistics Q2014, Vienne. [Consulté le 19 juin 2020]..

ERIKSON, Johan et ODENCRANTS, Martin, 2016. Building a common production environment – the Swedish experience. [en ligne]. 20-23 juin 2016. American Statistical Association (ASA), International Conference on Establishment Statistics ICES-V, Genève. [Consulté le 19 juin 2020].

HOFF, Sara, JAPEC, Lilli, LISAI, Dan et PETTERSSON, Åke, 2010. The journey towards an ISO certification – Implementing ISO 20252 for Market, Opinion and Social Research at Statistics Sweden. [en ligne]. 4-6 mai 2010. European Conference on Quality in Statistics Q2010, Helsinki. [Consulté le 19 juin 2020].

JORNER, Ulf, 2008. Summa summarum. SCBs första 150 år. [en ligne]. Septembre 2008. Statistics Sweden (SCB), Stockholm. [Consulté le 19 juin 2020].

PEARSON, John et SAVAGE, Tracey, 2007. Statistics New Zealand’s Business Model Transformation Strategy: Creating a new Business Model for the 21st Century National Statistical Office. [en ligne]. 18-21 juin 2007. American Statistical Association (ASA), International Conference on Establishment Statistics ICES-III, Montréal, Québec, Canada, pp. 1150-1157. [Consulté le 19 juin 2020].

VALE, Steven, 2009. Generic Statistical Business Process Model. [en ligne]. Avril 2009. Joint UNECE, Eurostat, OECD Work Session on Statistical Metadata (METIS) Version 4.0. [Consulté le 19 juin 2020].