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 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. Ouvrir dans un nouvel onglethttps://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 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 (Ouvrir dans un nouvel ongletUnece, 2019). Une bonne description de sa première version, ainsi que de la façon dont il a été développé, est disponible dans (Ouvrir dans un nouvel ongletVale, 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 (Ouvrir dans un nouvel onglethttps://statswiki.unece.org/display/GSBPM/GSBPM+v5.1).

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 (Ouvrir dans un nouvel ongletPearson 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

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

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 Ouvrir dans un nouvel onglethttps://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.

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 :

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 : Ouvrir dans un nouvel onglethttps://www.scb.se/en/About-us/main-activity/organisation/.

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 (Ouvrir dans un nouvel ongletJorner, 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.

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 1^er 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 :

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 :

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.

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 (Ouvrir dans un nouvel ongletHoff et alii, 2010) et (Ouvrir dans un nouvel ongletBergdahl et alii, 2014).

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.

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 (Ouvrir dans un nouvel ongletErikson 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.

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.

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.

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.

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é.

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 :

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

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.