À l'époque où il n'y avait pas de traitement des données comme nous le considérons comme allant de soi aujourd'hui - à cette époque, l'homme traitait encore lui-même les données, à la main. Nous ne pouvons plus vraiment l'imaginer dans la perspective d'aujourd'hui. Qu'est-ce que cela aurait pu être ? Tenir la comptabilité d'une entreprise sur papier, la mettre à jour régulièrement et en déduire les indicateurs de performance clés pour la gestion... ? Mais en quelques décennies, le monde des affaires a radicalement changé à cet égard. De la comptabilité de gestion (d'où le mot) au traitement électronique des données par ordinateur. Et bien sûr, cela ne concerne pas seulement la gestion financière. Dans tous les domaines où des données sont traitées, les systèmes logiciels sont indispensables et prennent en charge une énorme quantité de travail qu'il aurait été impossible de faire à la main à une époque antérieure.

Automatique - qu'est-ce que cela signifie en réalité ?

La plupart d'entre nous (et probablement surtout le lecteur de cet article) ont déjà grandi avec des ordinateurs et des systèmes logiciels. Nous parlons naturellement de choses qui "fonctionnent automatiquement". Il est évident pour nous, natifs du numérique, que, par exemple, les textes dans les documents Word sont automatiquement emballés en fin de ligne (c'est presque banal) ou que le bénéfice annuel dans le compte de résultat est automatiquement calculé sur la base des revenus et des dépenses. Nous utilisons le terme "automatique " de façon si désinvolte que nous ne sommes pas toujours conscients qu'il existe parfois des logiques et des algorithmes complexes dans les systèmes logiciels ou derrière les processus, dont nous ne voyons que les résultats.

Selon le dictionnaire Duden, le mot " automatique " signifie "se produisant par lui-même". En outre, il existe également un certain nombre de définitions analogues. Le mot vient à l'origine du terme grec autómatos ce qui signifie quelque chose comme penser par soi-même. Et en ce qui concerne les logiciels, cela convient encore assez bien aujourd'hui - surtout quand on parle de plus en plus d'intelligence artificielle (IA), qui est presque un synonyme du terme automatique . Du moins quand on pense à toutes les choses qu'on attend d'elle.

Si nous considérons ce qu'est en fait l'avantage du logiciel, à savoir nous soulager, nous les humains, du traitement des données, alors l'IA n'est en fait que la forme ultime du logiciel : l'IA essaie simplement d'automatiser autant que possible le traitement des données. Avec l'IA, l'ordinateur commence à "penser" pour nous (dans le sens original du terme). Pour le dire de façon un peu abstraite : Nous donnons au système intelligent une entrée, et il produit une sortie utile avec beaucoup, beaucoup de traitement de données très intelligent. Un exemple concret ? Je suis assis dans ma voiture à la fin de la journée de travail (c'est mon entrée), et mon smartphone (mon système intelligent) me montre immédiatement le temps qu'il me faudra pour rentrer chez moi et si je ne devrais pas faire un détour pour éviter les embouteillages (c'est alors la sortie). Dans cet exemple, je n'ai même plus besoin de "taper" l'entrée ; le système la reçoit automatiquement en fonction des données du capteur. "Je suis maintenant connecté à la voiture et c'est le soir d'une journée de travail, par conséquent mon propriétaire veut probablement conduire chez lui, ce qu'il fait habituellement dans cette situation.

Planification automatique dans la gestion des ressources et des projets

Orientez la discussion vers le sujet de notre blog sur la gestion des ressources et des projets multiples. Qu'est-ce qu'un système peut automatiser ici ? Nous sommes convaincus qu'il peut automatiser beaucoup de choses, ce que nous mettons en pratique avec PQFORCE à chaque nouvelle version. La question dans le titre "Automatiquement ? La règle "ou préférez-vous le faire manuellement" s'applique toujours. Après tout, tout ce qui peut être automatisé ne devrait pas l'être. Dans certaines situations, il est évident pour tout le monde ce que doit être le résultat d'une entrée donnée, mais dans d'autres situations, c'est loin d'être le cas. Ce qui est un "résultat logique pour ces entrées" pour une personne n'est "pas du tout clair" pour une autre.

Examinons un exemple simple tiré de la pratique de la planification de projets. Un chef de projet a programmé une activité (tâche) dans son projet et lui a alloué des ressources. Il reporte maintenant cette tâche (pour une raison quelconque) d'un mois dans le futur. Qu'advient-il de l'utilisation des ressources allouées ? "Logiquement, bien sûr, ils changent aussi d'ici ce mois." Je pense que tout le monde est d'accord sur ce point. La charge de travail est par définition (quelque peu simplifiée) donnée par la période de temps de l'activité et le budget temps alloué de la ressource. Personne n'a rien contre le fait que le système actualise automatiquement la charge de travail, ou même qu'il doive le faire.

Rendons l'exemple un peu plus compliqué. L'opération 1 à déplacer est reliée à une autre opération 2 via une dépendance de bout en bout. Cela signifie que l'opération 2 ne peut pas commencer (c'est la signification de la dépendance) tant que l'opération 1 n'est pas terminée. Si la fin de l'opération 1 se prolonge au-delà de la date de début de l'opération 2 en raison du report de l'opération 1, que devrait-il se passer ? A première vue, c'est à nouveau clair : l'opération 2 devrait également être déplacée dans le futur, "après tout, c'est pour ça que j'ai dessiné la dépendance". A première vue, cependant, il y a des questions. S'il reste un délai d'une semaine entre les deux opérations, de combien l'opération 2 est-elle décalée dans le futur ? Un mois ? Ou seulement 3 semaines ? Ici, ce n'est plus aussi clair. Cela dépend des préférences du chef de projet et des contraintes qu'il doit suivre. L'un veut utiliser ces tampons exactement pour de tels déplacements, l'autre considère le tampon comme rigide et immuable (pour quelque raison que ce soit).

Et soudain, les automatismes ne sont plus souhaités

Prenons l'exemple un peu plus loin : que se passe-t-il si la tâche 2 n'appartient pas à mon projet 1 mais à un projet 2 d'un autre chef de projet ? Le passage automatique doit-il alors être également actif ? Est-ce que je sais quelles sont les conséquences pour le projet 2 ? Et mon collègue chef de projet est-il heureux que son projet ait changé automatiquement sans son intervention ? Je ne pense pas.

Vous pouvez voir à partir de cet exemple très simple (car la pratique de la gestion multi-projets est effectivement beaucoup plus complexe...) que les actions automatiques du système n'ont pas toujours de sens pour chaque utilisateur. La ligne de démarcation entre ce qui doit être automatisé et ce qui ne doit pas l'être pourrait être tracée ou définie approximativement comme suit : Si l'espace de solution des résultats possibles de l'automatisation est petit (tous les répondants trouvent "qu'il n'y a qu'un seul résultat significatif"), alors on peut automatiser en toute sécurité. Cependant, dès que l'espace de solution devient plus grand et surtout lorsque plusieurs utilisateurs du système sont concernés par les résultats possibles de l'automatisation (nos deux chefs de projet ci-dessus), alors l'automatisation doit être soigneusement envisagée. Il n'y a rien de pire que lorsqu'une action d'un utilisateur (par exemple, un chef de projet déplace une tâche vers le projet 1) modifie automatiquement en arrière-plan des données que je ne vois pas immédiatement et dont je ne remarque les conséquences que plus tard (par exemple, le plan du projet 2 a maintenant également changé, mais je ne l'ai découvert que beaucoup plus tard).

Utilisation prudente des automatismes, mais indications suffisantes en cas d'incohérences

Lors du développement de PQFORCE, nous sommes extrêmement prudents quant aux mécanismes que nous automatisons. Les réactions de notre base d'utilisateurs et de professionnels expérimentés dans le domaine de la planification nous montrent très clairement que les changements de données critiques ne doivent pas toujours entraîner des conséquences automatiques, c'est-à-dire des ajustements de données. Notre principe ici est le suivant : c'est toujours l'utilisateur formé et expérimenté (chef de projet, etc.) qui doit prendre les décisions critiques et apporter les ajustements appropriés aux données du système (plans de projet, etc.). Toutefois, le système doit toujours signaler à l'homme les cas de violation de l'intégrité résultant de la modification des données. L'être humain peut alors réagir avec l'intelligence humaine, c'est-à-dire prendre et appliquer des décisions réfléchies.

Nous verrons dans un article ultérieur comment l'intelligence artificielle (IA) peut encore être extrêmement utile dans la gestion de projets multiples et de ressources. Restez à l'écoute.