Votre SIRH se souvient des salaires. Se souvient-il de l'horaire que vous avez facturé ?

Votre SIRH garde probablement l'historique

Laissez-moi régler une chose d'entrée de jeu, parce que c'est l'objection que tout administrateur de SIRH soulèvera, et il a raison de la soulever.

Les systèmes RH modernes gardent l'historique. PeopleSoft stocke des lignes à dates d'effet depuis les années 1990, précisément, selon les mots d'Oracle, pour maintenir un historique exact de l'information dans le temps. Workday, Oracle HCM Cloud et SAP SuccessFactors datent tous d'effet leurs objets de base. La plupart du milieu de gamme aussi : BambooHR, Rippling, ADP, UKG. Si vous pouvez produire un rapport « au 1er avril » et obtenir le poste et le salaire d'un agent tels qu'ils étaient ce jour-là, votre SIRH fait ce que les gens de données appellent la dimension à variation lente de type 2 : un historique versionné, à dates d'effet. C'est la base, et la majorité du marché la franchit.

Alors ce n'est pas un article du genre « les logiciels RH n'ont pas de mémoire ». Le problème est plus étroit et plus précis que ça, et il vit à deux endroits que le dossier d'emploi à dates d'effet n'atteint pas.

Une seule horloge ne suffit pas

Le premier, c'est que la datation d'effet suit une seule horloge : quand un fait était vrai. Elle ne suit pas une deuxième horloge qui compte tout autant pour l'argent : quand vous l'avez appris.

Martin Fowler a le plus clair des exemples pour illustrer pourquoi cet écart fait mal. L'augmentation de Sally est saisie le 15 mars, en vigueur le 15 février. Demandez « quel était le salaire de Sally le 25 février » et il y a deux bonnes réponses. Six mille, tel que vous le croyiez et le payiez à l'époque. Six mille cinq cents, tel que vous le savez maintenant, après la saisie rétroactive. Pour tout ce sur quoi vous avez déjà agi, un chèque de paie que vous avez émis, une facture que vous avez envoyée, le chiffre que vous devez pouvoir reproduire est celui que vous croyiez alors, pas celui que vous savez maintenant.

Tenir les deux réponses à la fois, c'est ce que les gens de données appellent le bitemporel : le temps valide, quand le fait était vrai, plus le temps de transaction, quand il a été enregistré. C'est réellement rare. Parmi les systèmes RH grand public, la production de rapports de Workday est l'exception nette, avec une Date d'effet et une Date de saisie distincte qui permet à un rapport d'ignorer les saisies rétroactives ultérieures. La plupart des autres, quand vous corrigez un enregistrement passé, modifient la ligne sur place. La valeur corrigée est bonne pour l'avenir, mais la valeur que vous croyiez le jour d'origine est écrasée, à moins d'aller fouiller dans un journal d'audit. Cette valeur écrasée est justement celle dont dépend un litige de paie ou de facturation.

Mais l'horaire n'a jamais été dans votre SIRH de toute façon

Le deuxième endroit, et le plus important, c'est que le registre à partir duquel vous facturez et payez n'est pas du tout le dossier d'emploi. C'est l'horaire : à quel client et à quelle ligne d'affaires chaque agent était affecté, à quel taux de facturation et à quel taux de paie, un jour donné.

Dans une entreprise à employeur unique, ces choses sont presque les mêmes. Dans un centre de contact multiclient, elles ne le sont pas. Le salaire de base d'un agent peut rester inchangé pendant un an tandis que son affectation client, et le taux que vous facturez pour elle, change trois fois. Le salaire n'est pas le fait facturable. C'est l'affectation-et-le-taux, par jour, qui l'est.

Et ce registre ne vit pas dans votre SIRH. Il vit dans votre outil de gestion des effectifs ou de planification. C'est ici que l'argument devient inconfortable, parce que ces outils n'ont pas été bâtis pour tenir un historique de paie et de facturation défendable. Ils ont été bâtis pour produire un indicateur d'adhérence. Ce qu'ils gardent, c'est un court journal de changements. Calabrio recalcule l'adhérence pour les changements d'horaire rétroactifs jusqu'à trente jours en arrière. NICE CXone tient compte des mises à jour d'horaire dans les trois mois précédents environ. La famille Zendesk et Talkdesk expose l'historique des changements d'horaire pour les quatre-vingt-dix derniers jours. Genesys Cloud garde un journal d'audit des actions sans aucun horaire versionné. C'est assez pour répondre à « cet agent était-il à l'heure ». Ce n'est pas bâti pour répondre à « reconstituez l'horaire payé et facturé pour la semaine du 8, tel qu'il était avant le changement rétroactif ». Et dans les outils que j'ai examinés, la partie commerciale, l'affectation client portant un taux, n'est pas modélisée du tout comme un objet versionné, à un moment précis.

Alors l'horaire tel qu'il était tombe droit dans la fissure entre les deux systèmes. Le SIRH garde le dossier d'emploi et présume que l'horaire est le problème de quelqu'un d'autre. L'outil de GME garde l'horaire et présume que le registre commercial est le problème de quelqu'un d'autre. Personne ne possède la seule chose sur laquelle vous vous faites réellement vérifier.

Ce que cette fissure coûte

Trois endroits où ça se manifeste, et aucun n'est hypothétique dès que vous gérez plus d'un client.

La paie. La paie rétroactive est courante, pas un cas limite : un changement de taux avec une date d'effet passée signifie de recalculer selon le bon taux pour chaque jour concerné. Si vous ne pouvez pas fixer le taux qu'un agent portait réellement chaque jour d'une période passée, la paie rétroactive est une supposition, et c'est une supposition qu'une commission des normes du travail peut vous demander de défendre.

La facturation. Une facture n'est défendable que dans la mesure où vous pouvez montrer qui était affecté à ce client, à quel taux, quels jours. Une réaffectation rétrodatée après la production de la facture change discrètement cette base. Vous ne faites rien de mal. Votre système ne peut simplement plus montrer la version à partir de laquelle vous avez facturé.

Les rapports et l'audit. Les chiffres d'effectif, de dotation et de niveau de service doivent se réconcilier avec l'horaire tel qu'il était, pas tel qu'il est maintenant. Quand un client ou un vérificateur le demande, « tel qu'il est maintenant » est la mauvaise réponse, et « tel que nous le savions alors » est celle qu'il vous faut avoir.

Rien de tout cela n'est exotique. C'est le résultat ordinaire de changements rétroactifs rencontrant un registre que personne n'a versionné correctement.

Ce qu'il faut pour tenir la jonction

Alors qu'est-ce que bien faire cela exige vraiment. Trois choses.

D'abord, l'horaire lui-même, l'affectation client et ligne d'affaires avec ses taux, doit être une donnée de première classe, à dates d'effet, versionnée comme votre SIRH versionne déjà un salaire. Pas un instantané nocturne de l'état actuel, ce qui est précisément la chose qui ne peut pas survivre à une modification rétroactive.

Ensuite, il devrait être bitemporel, pour que vous puissiez répondre à la fois à « qu'est-ce qui était vrai ce jour-là » et à « qu'est-ce que nous savions ce jour-là ». Au minimum, le système doit préserver la valeur que vous croyiez à l'époque au lieu de l'écraser à la correction.

Enfin, il doit vivre à cheval sur la jonction. Un changement d'affectation ou de taux rétrodaté doit mettre à jour la paie, la facturation et les rapports à partir d'un seul registre, sinon vous voilà de retour à trois équipes qui réconcilient à la main en espérant tomber sur le même chiffre.

C'est la partie que FrontLine a été bâti pour tenir, et je serai clair sur ce que cela veut dire et ne veut pas dire. FrontLine cadre chaque enregistrement au tenant, au client et à la ligne d'affaires, garde l'historique des affectations à dates d'effet, et écrit un événement d'audit immuable à chaque changement, de sorte que l'horaire à partir duquel vous avez facturé reste reproductible après coup. Ça, c'est tenir la jonction. Ce n'est pas une prétention que nous sommes le seul système doté d'une mémoire. Votre SIRH a une mémoire, et une bonne. C'est une affirmation sur quel registre, et à travers quelle frontière.

Si vous évaluez quoi que ce soit, les questions qui séparent une vraie réponse d'un instantané sont courtes :

Pouvez-vous reproduire l'horaire complet, affectation client et taux compris, exactement tel qu'il était un jour passé quelconque, y compris les changements rétrodatés après ce jour-là ?

L'affectation client avec son taux est-elle un objet versionné, ou un champ d'état actuel que la dernière modification a écrasé ?

Quand un changement est rétrodaté, circule-t-il vers la paie, la facturation et les rapports à partir d'un seul registre, ou trois équipes le réconcilient-elles à la main ?

Si la réponse à la première est un instantané et un haussement d'épaules, vous savez déjà où s'en va votre prochain litige de facturation.

À retenir

Que votre SIRH se souvienne des salaires, c'est la base, et la majorité du marché la franchit. Le registre qui vous protège réellement dans un centre multiclient est celui qui se trouve entre les systèmes : l'horaire, avec ses affectations client et ses taux, reproductible exactement tel qu'il était un jour passé quelconque, après des changements rétroactifs.

La datation d'effet vous donne l'employé. Un historique d'horaire bitemporel, à cheval sur la jonction, vous donne la facture et la paie. Dans ce métier, c'est la différence entre défendre un chiffre et espérer que personne ne le demande.