Notre perspective sur la compétence dans le cadre d’une démarche GPEC est qu’elle n’est pas seulement une donnée RH ou qui appartient à l’individu lui-même, mais une donnée largement diffusée et partagée au sein de l’entreprise, avec de nombreux (co-)propriétaires.
La diversité et le nombre de ces propriétaires de la donnée met le responsable de la démarche GPEC et d’un projet compétence face à 3 challenges que nous adressons ici :
Bien que ces challenges autour de la gestion des compétences soient d’importance variables selon la nature du projet GPEC, il reste néanmoins important de les parcourir – peut-être sous la forme d’une check list – pour chaque projet compétence. Notez également que l’ordre dans lequel ces challenges sont présentés n’est pas nécessairement l’ordre chronologique dans lequel ils doivent être adressés lors de votre démarche GPEC, qui est elle continue.
Pour chacun de ces challenges liés aux compétences, nous proposons une réponse à deux points cruciaux qu’ils comportent, de telle sorte qu’un chef de projet GPEC au fait de cela augmente de façon très significative la probabilité de succès de son projet ainsi que sa valeur économique.
Pour identifier les sources d’informations, commencez par recenser l’information structurée disponible. Il s’agit des éléments de référentiels métiers et compétences existants, des bases de données contenant déjà de la donnée sur les compétences identifiées de manière nette et immédiatement exploitable. Puis, étendez le recensement aux sources d’informations non structurées, autrement dit les sources d’informations qui nécessitent un retraitement ou une analyse pour en extraire la donnée sur les compétences.
Qualifier l’information doit s’effectuer selon deux axes : en dehors du contexte du projet et dans le contexte du projet. En dehors du contexte du projet GPEC, évaluez par exemple pour les données non structurées l’effort nécessaire à leur retraitement (besoin d’une analyse manuelle, d’investir dans une solution d’analyse textuelle …). Dans le contexte du projet GPEC, évaluez la criticité de l’information : où se trouve l’information la plus pertinente ? Des projets ayant trait à la mobilité, au workforce management ou à la transformation de l’entreprise ne vont pas utiliser le même type d’information, et n’ont pas besoin du même niveau de qualité d’information sur les différents types d’information utilisés.
Quelle que soit la nature du projet, il va être nécessaire de construire ou utiliser une seule base de données grâce à laquelle les objectifs métiers de la démarche GPEC vont pouvoir être atteints. Ce sont les sources d’informations identifiées à l’étape précédente qui vont permettre de créer ou d’alimenter cette base de données. Il faut donc comprendre quelles données vont être extraites de ces sources d’information, la façon ces données sont structurées (quelle information disponible, selon quelles dimensions organisationnelles, de temps …), et la manière dont on va pouvoir arrimer ces données à la base de données sur laquelle le projet va s’appuyer.
Une fois la structure des sources de données disponibles comprise, il faut alors déterminer la façon dont ces données vont être traitées afin de la proposer dans le format cible de la base de données centrale du projet. En informatique, ce type d’opération est désignée par l’acronyme ETL : Extract, Transform, Load. Ce sont bien les parties Extract et Transform de cet acronyme qui sont en périmètre de ce challenge, nous avons adressé la partie Extract ci-dessus et nous nous intéressons maintenant à la partie Transform. Pour la transformation des données, le sujet est l’identification des règles de transformation et la manière dont celles-ci vont être implémentées. Certains éditeurs proposent par exemple des fonctionnalités natives pour le retraitement et l’import de données, y compris venant de sources non structurées (voir ci-dessus). Dans tous les cas, il existe également des solutions dédiées aux opérations ETL, indépendamment du type de données considéré, éditées par des entreprises ou communautés expertes du sujet telles que Talend ou MuleSoft.
Il s’agit ici d’établir une véritable spécification des besoins métiers, et de documenter la manière dont ceux-ci se traduisent du point de vue des processus, pratiques de travail, indicateurs de suivi de la performance, etc. Cette spécification vise à établir clairement la valeur ajoutée attendue du projet de démarche GPEC, et peut s’établir en fonction du périmètre du projet à au moins deux niveaux de détail : celui des individus (temps de travail, qualité du travail …) et celui de l’entreprise dans son ensemble (performance économique, accélération de la transformation de l’entreprise …).
C’est la deuxième partie de la spécification du projet : une fois les besoins métiers et les processus concernés documentés ou spécifiés, il s’agit de spécifier la réponse fonctionnelle à ces besoins métiers d’une part et la réponse technique à cette spécification fonctionnelle d’autre part. La spécification fonctionnelle répond à la question suivante : quelle solution va supporter les besoins métiers ou les différentes étapes d’un processus, via quelle(s) fonctionnalité(s) de cette ou ces solutions ? La spécification technique quant à elle répond à la question : comment cet ensemble de fonctionnalités va-t-il être implémenté et maintenu, et comment s’insère-t-il dans l’architecture technique de l’entreprise ?
Selon le degré de complexité de l’organisation dans laquelle la démarche GPEC va vivre, il peut être nécessaire d’entretenir plusieurs versions parallèles d’un même processus qui utilise la donnée compétence pour fonctionner. Le projet compétence peut lui-même amener à reconcevoir ces processus dans une approche plus souple et plus agile, où un même « patron » d’un processus peut être décliné de différentes manières en fonction du contexte dans lequel il est exécuté (par exemple, un même patron peut être utilisé pour gérer la mobilité et le staffing, mais va s’exécuter dans des modalités différentes selon le contexte).
Dans la même logique que celle décrite ci-dessus pour les processus, le projet compétence va être amené à servir une typologie d’utilisateurs aux besoins parfois radicalement différents les uns des autres. Bien que la donnée exploitée soit la même pour tous (cf. la première catégorie de challenges « Construire une seule source d’information »), il va être nécessaire de penser en termes d’interface utilisateur ou de reporting la façon dont cette donnée va être poussée aux parties prenantes du projet : de quoi on t-il réellement besoin, dans quel contexte ? Quelle flexibilité est nécessaire quant aux formats de restitution (quels besoins d’évolution dans le futur) ?
Nous revenons ici sur les contextes d’exploitation de l’information liée à la démarche GPEC et au projet compétence, pour souligner qu’au-delà du contexte opérationnel (processus) ou organisationnel (qui, dans quelle capacité) dans lesquels l’information est sollicitée, les aspects plus pratiques de l’accès à la donnée doivent être considérés. Par exemple, y a-t-il des situations dans lesquelles l’accès à la donnée est essentiel mais rendu difficile par le contexte (accès mobile seul disponible, accès hors ligne …) ? Dans de telles situations, où des contraintes techniques particulières peuvent s’exercer, l’accès doit il être restreint ou limité à une partie ou un format de restitution particulier de la donnée ?
Ce point est directement lié à la spécification des besoins métiers liés à la démarche GPEC, et peut même être totalement englobé dans cet exercice de projet compétence. En voyant l’utilisation de la donnée du point de vue de la prise de décision, que celle-ci soit au niveau d’un collaborateur, d’un manager, de la direction de l’entreprise ou de tout autre acteur, on s’assure que la donnée est traitée comme un outil au service des métiers. De plus, dans le prolongement de cette réflexion il sera d’autant plus facile d’identifier la bonne réponse fonctionnelle à apporter au besoin métier et les formats de restitution attendus (en particulier pour ce qui relève du reporting).
Dans ce dernier challenge que nous abordons, il s’agit de veiller à ce que la démarche GPEC n’aboutisse pas à un paysage opérationnel ou technologique inutilement complexe. Bien souvent, des solutions déjà en place peuvent couvrir tout ou partie du projet compétence, parfois sans même aucune adaptation fonctionnelle mais simplement en variant leur usage. Ainsi la solution apportée aux problématiques posées par la gestion des compétences se construit aussi à partir du paysage technologique existant. Pour une question de facilité d’usage et de simplification de l’expérience utilisateur, les parcours utilisateurs liés à la démarche GPEC doivent être envisagés à l’échelle de l’intégralité du paysage applicatif et / ou de processus impactés par le projet, et non du seul périmètre du projet en lui-même.
Enfin, il nous paraît utile de zoomer sur une portion souvent négligée des spécifications fonctionnelles des projets de GPEC et gestion des compétences, celle des droits et permissions d’accès à la donnée. La plupart du temps les contraintes liées au RGPD sont adressées avec rigueur et selon une méthode bien construite. Toutefois, au-delà de cela et dans le contexte de la gouvernance de la solution implémentée, force est de constater que même s’il est reconnu que de nouveaux usages & pratiques seront mis en œuvre après le projet compétences, il reste assez rare de voir des responsabilités clairement définies pour gérer ces nouveaux usages & pratiques.
Ainsi, nous invitons le responsable en charge des compétences et de la démarche GPEC à se poser très tôt la question de la gouvernance de la solution finale et de l’adresser avec un soin tout particulier : qui sera en charge de la gestion de la donnée elle-même, qui sera en charge de la gestion des objets construits à partir de cette donnée (profils collaborateurs, référentiels X ou Y …), qui sera chargé de compiler les demandes d’évolution de la solution ou des besoins métiers qu’elle adresse, et qui enfin, si un tel impact est à prévoir, devra définir la gouvernance des nouveaux processus construits ou redéfinis autour de la solution.
En conclusion, pour ceux d’entre vous habitués à cadrer et livrer des projets d’intégration ces challenges devraient être déjà très familiers. La particularité d’une démarche GPEC cependant est le caractère très transverse du projet compétence et la diversité des sujets en périmètre – tantôt technique, tantôt opérationnels, tantôt stratégiques … – , ainsi que l’importance disproportionnée, et donc capitale, de la première étape « Construire une seule source d’information ».
Plus qu’un simple travail technique, il s’agit souvent dès ce stade-là de comprendre en détail le métier de l’entreprise, et la manière dont celui-ci crée et consomme de l’information. Ce travail peut s’avérer particulièrement complexe dans un contexte où l’information sur les compétences est dans l’ensemble peu documentée et passe souvent sous les radars managériaux ou opérationnels. Plus qu’un choix d’outillage ou de méthodologie, il s’agit donc aussi de solliciter des ressources, internes ou externes, capables d’analyser et comprendre le métier de l’entreprise afin d’approcher, dès le début du projet, ces problématiques essentielles de manière efficace.