dimanche 15 avril 2012

La pertinence d'un outil, entre insuffisance et démesure - partie 2/2.

--- Ce billet-ci est la suite de la réflexion initiée dans le billet précédent, billet qui mérite d’être lu avant celui-ci. Dans ce billet précédent, on a mis en parallèle deux notions : d’une part la complexité d’une tâche, d’autre part la pertinence d’un outil traitant cette tâche. On a également introduit un mode de représentation graphique pour illustrer ce parallèle. ---


Revenons au monde de l'entreprise et focalisons-nous sur l'univers du traitement de données chiffrées.

Il va falloir sortir de la boulangerie – désolé – et choisir une autre problématique. Cette fois-ci, l'idée ne va pas être d'imaginer une série de situations distinctes pour se demander quels outils pourraient y répondre. On va faire l’inverse : choisir une problématique générique et raisonner à partir des des outils susceptibles d'y répondre.

Choisissons une problématique simple à énoncer. En voici une qui est à peu près universelle, quels que soient le secteur d'activité de l'entreprise et sa taille : compter les collaborateurs de l’entreprise.

La mémoire

Il y a d'abord pas mal de choses qu'on peut faire de tête. S'il s'agit de répondre par un unique nombre à une question ponctuelle (“combien y a-t-il de collaborateurs dans la société ?” – "76 au 1er décembre"), ou bien si on veut dénombrer de manière informelle les collaborateurs d'une TPE ("une douzaine il y a un an et bientôt une vingtaine"), il n'y a pas besoin d'outil à proprement parler. Les questions posées dans ces situations sont d'une faible complexité. Dans le cas d'une PME, répondre à la question est à peine plus difficile. Et de même si, dans une entreprise plus grande, on peut se contenter d’une approximation ("environ 2000") : travailler de tête sur cette question est presque aussi pertinent. En revanche, cela l’est sensiblement moins dès que le sujet gagne en complexité. Par exemple pour compter l’effectif d’une grande entreprise constituée de nombreux services ou répartie sur plusieurs sites. Ou bien pour suivre l’évolution dans le temps de cet effectif.

La calculatrice

Autre outil évident pour compter, la calculatrice. Elle est inutile pour additionner deux ou trois petits nombres mais devient pertinente lorsqu’il s’agit de sommer une plus grande quantité de nombres plus élevés. Autrement dit, elle permet de gagner un peu de temps dès qu’on monte en complexité arithmétique. Enfin, elle est très utile si l'on veut davantage de précision au sujet d'une entreprise dont la structure est plus complexe : s'il y a par exemple plusieurs sites dispersés à des endroits différents, chacun étant composé de plusieurs entités. Cela dit, si on parle de plusieurs dizaines de sites ou plus, ou bien si la problématique est plus large (historiser l’effectif par exemple), la calculatrice perd en pertinence.

On peut représenter ces deux outils de la même manière que ceux utilisés précédemment :


Le tableur

J’écrivais récemment un billet ironique autour d’un besoin métier lambda auquel on décide de répondre par un tableau, et sur les errements techniques qui peuvent en découler. “Suivre l’effectif précis de l’entreprise et leur évolution dans le temps” est un bon exemple de ce type de besoin. Là aussi, recourir à un tableur pour effectuer quelques opérations simples de façon ponctuelle est inutile. Ca reviendrait à l’utiliser comme une sorte de calculatrice king-size (qui garde les résultats en mémoire même quand elle est éteinte). Soit.

En revanche, le tableur va devenir pertinent si on envisage d’illustrer graphiquement ces informations. Par exemple, si on a une entreprise d’une demi-douzaine de sites, c’est la voie de l'illustration par un graphique en secteurs (le très classique"camembert").

Autre exemple de gain en complexité : on s'intéresse uniquement au nombre total de collaborateurs (pas à sa répartition par site) mais on veut suivre son évolution dans le temps, mois par mois. Ici plus encore, on a besoin de mémoriser un historique, pour en faire par exemple une représentation en courbes.

Nouveau cas de figure : rassembler les deux besoins précédents, c’est à dire suivre l'évolution dans le temps de la répartition par site. Ici, la réponse au besoin de représentation peut être le modèle de graphe en aires empilées.

Au fil de ces cas à la complexité croissante, le tableur est une réponse de plus en plus pertinente.

Cela dit, il y a un cap de complexité au-delà duquel la pertinence de cette solution décroît. C’est ce qui se passe si le volume d’informations à traiter devient trop grand : très grande entreprise, nombreux sites, organisation sur un grand nombre de niveaux hiérachiques. Ou bien si la fréquence de traitement est trop élevée : suivre l’effectif précis au jour le jour par exemple. Ou encore s’il y a un turnover élevé et donc de fréquents changements d’effectif.

Illustration extrême : suivre en temps réel l’effectif d’une entreprise, organisée sur cinq ou six niveaux hiérarchiques, comptant plusieurs milliers d’employés répartis sur plusieurs dizaines de sites. Dans ce cas, on peut s’entêter sur la solution tableur et développer un outil monstrueux à base de tableaux échangés, annulés, mis à jour, traités par les uns, retraités par les autres, tout cela selon des règles de gestion devenant obscures à force de vouloir couvrir le plus de situations possibles. Bref : développer un machin proche de l’esprit de ce sur quoi j’ironisais dans ce billet-là. Ou bien convenir que le tableur n’est plus suffisant et réfléchir à un autre type de solution !

La base de données

Je reprends ici l’abus de langage courant : on dit “base données” mais on veut parler de système de gestion de base de données (SGBD). Les deux notions sont bien sûr étroitement liées. L’abus de langage est ici caractérisé dans la mesure où ce dont je veux parler, c’est plus de la vision utilisateur que de la mécanique interne de l’outil.

On peut bien sûr réfléchir base de données avant d’atteindre le niveau de complexité de l’exemple ci-dessus. Si ce n’est certes pas nécessaire pour les problématiques simples évoquées plus haut, ça commence à devenir intéressant dès les cas de figure où la solution tableur est optimale : structure d’entreprise moyennement complexe, besoin d’un suivi dans le temps, souhait d’illustrations.

Mais surtout, au-delà de la problématique qui nous occupe, le recours à un outil base de données prend tout son sens dans une articulation avec d’autres sujets et donc dans le partage d’un outil commun avec ces autres sujets. Ici, on pourrait lier notre suivi d’effectif à des problématiques RH (le registre des entrées-sorties de personnel, le suivi de l’ancienneté des employés, etc) ou bien à l’annuaire électronique interne par exemple.

L’usage d’un outil de gestion de base de données pour suivre l’effectif de l’entreprise ouvre la voie à des améliorations intéressantes : données centralisées de fait (pas de foisonnement de fichiers), pérennité de l’outil (pas de fichier qui disparaît), possibilité de gestion de la confidentialité, automatisation de la réalisation de synthèses, etc.

C’est sur cette même voie qu’on peut chercher des limites fonctionnelles à un outil base de données. Ces limites relèvent de la portée du sujet (nombre de sites voire nombre de pays pour une multinationale, fréquence et finesse attendues dans le suivi, etc) et de la complexité des tâches dont on souhaite intégrer la gestion (suivi de quelques problématiques ciblées ou gestion exhaustive des sujets RH ? outil exclusivement RH ou bien intranet RH ouvert aux collaborateurs ?)

Mais il y aura également des limites d’ordre technique, qui tiennent notamment au type de base de données utilisé. On pourrait poursuivre la schématisation proposée ici en différenciant les logiciels utilisés : Microsoft Access, qui peut être une bonne solution pour ce sujet-là dans une PME, sera insuffisant pour une plus grande entreprise. On pourrait dessiner une courbe “Access” à la place de la courbe “base de données” sur le schéma ci-dessus. Puis terminer cette courbe et en esquisser une autre pour les solutions utilisant des bases MySQL. Puis une autre sur les bases DB2, solution qui concernerait des multinationales, etc.

Je laisse l’idée ouverte sur des pointillés...

Aucun commentaire:

Enregistrer un commentaire