J’aime le travail en architecture de système et en management de projet. Cela me procure le plaisir de manipuler des choses complexes et la fierté d’être au cœur de l’action. Mais les projets ne réussissent pas toujours aussi bien qu’on le voudrait et dans ces circonstances, je retrouve le sentiment que j’aurais pu faire mieux si j’étais mieux qualifié.

Depuis 1985, je conçois des systèmes qui se rapprochent le plus possible des règles de l’art. Je travaille avec des gestionnaires de tous les niveaux qui ont de la difficulté à comprendre la complexité de mon travail. Je les vois acculés à prendre une décision avec beaucoup trop d’incertitude. Avec les budgets, les risques s’accroissent avec la taille de la clientèle affectée par mon travail.

Un projet prend la forme mathématique d’un treillis de décisions; alors, comment prendre de meilleures décisions? La question se conjugue en deux aspects : (1) comment concevoir des systèmes qui répondent aux règles de l’art et aux besoins et (2) comment rendre le projet gérable pour les gestionnaires? En effet, il m’apparait clair que j’ai une responsabilité à rendre la complexité du projet assez simple pour que mes gestionnaires prennent les meilleures décisions en fonction de leurs objectifs. Cela peut signifier de découper le projet ou le système en pièces qui répondent spécifiquement aux impératifs d’affaires. Au final, il s’avère qu’en faisant cet exercice, l’architecture elle-même se simplifie. Les équipes de développement la comprennent mieux. J’ai plus confiance au résultat. Le client se sent rassuré qu’on aille dans la bonne direction. En fait, ces deux aspects s’imbriquent dans une synergie parce qu’ils exploitent les mêmes outils et reposent sur une même base factuelle.

Depuis l’histoire du Titanic, nous savons mieux que donner un coup de barre sans anticiper le résultat peut conduire à la catastrophe. L‘impératif que je me donne se résume à offrir des choix simples aux gestionnaires (un ensemble d’options réfléchies) qui mènent à des résultats probables. À eux de choisir les conséquences qu’ils privilégient et les compromis avec lesquels ils devront vivre, mais je dispose d’outils très puissants pour les aider à faire ces choix.

Ma réserve à cette promesse provient de mes limites à disposer d’un modèle de cause à effet assez fiable, assez expressif et assez accessible pour refléter toute la culture, la structure et la dynamique de l’organisation.

J’y travaille sérieusement depuis quelques années et j’obtiens de plus en plus de résultats. Je n’invente rien, tout se trouve dans la littérature spécialisée. Je conçois des instruments simples et accessibles à tous pour répondre à plusieurs besoins courants. Pour mon propre travail de conception, j’utilise des instruments de modélisation formels couplés avec des mathématiques relativement simples, surtout pour manipuler l’incertitude et le risque. En somme, tout ce qui se conçoit peut être modélisé et quantifié avec un degré d’incertitude. Tout se comprend et peut être expliqué aux professionnels. Je découvre que la modélisation quantitative s’applique à peu près à tout, autant dans la gestion de ma petite entreprise que dans les grands projets de développement.

J’ai intégré à un certain niveau les processus du PMBOK comme exercice de modélisation quantitative et aussi pour bâtir une librairie de modèles réutilisables. J’ai manipulé les méthodologies OOSEM et SYSMOD, avec des incursions dans BPMN, BDM, CWM, UPDM, DODAF,  MODAF, SPEM et autres. J’ai fait un exercice plus exhaustif dans la classification multiindustries des processus (PCF) du modèle APQC. J’ai fait une incursion dans COBIT, TOGAF, ITIL et une bonne dizaine d’autres BOK et ISO. Modéliser ces magnifiques cadres de référence m’a fourni des accélérateurs pour récolter de ressources, des ontologies, des processus et des métriques, mais me permet aussi de comprendre leur portée relative et leurs limites respectives.

Pour m’assurer que mon travail était conforme à l’esprit de ces cadres, je me suis astreint à une certification CAPM du Project Management Institute et à 3 niveaux de certification SysML (OCSMP) de l’Object Management Group. Évidemment, quand on tombe dans le concret des modèles formels, les faiblesses des connaissances de base remontent : statistiques, logique, UML et OCL, rationalité, éthique, etc.; il faut constamment les remettre à jour.

Je suis convaincu que concevoir un modèle quantitatif sur un problème d’envergure rapporte beaucoup à une organisation. Mais, la force de ma conviction ne serait qu’un artéfact ou une illusion si je ne m’astreignais pas à une contrainte formelle. En effet, si je peux instrumenter toute forme de décision, je devrais être capable de démontrer la valeur économique de chacune de mes interventions.

Est-ce là un engagement insoutenable par abus de principes? Cela comporte plus de facteurs que je ne le croyais au départ, mais il existe plusieurs modèles d’estimation de la valeur de l’information que je peux utiliser. Cela dépend parfois de l’information que je peux obtenir de mon client. En fait, c’est un entrainement continuel et mon taux de succès progresse avec l’amélioration de mes instruments. Cela impose aussi de retirer ou de modifier ma proposition quand la preuve de rentabilité ne la soutient pas.

Je perçois que, progressivement, la modélisation quantitative deviendra le meilleur moyen pour prendre de meilleures décisions plus rapidement, parce qu’elle met en valeur toutes les connaissances de l’organisation, parce que le modèle s’enrichit par cycle en mettant les résultats à l’épreuve, parce qu’elle laisse la place à l’expérimentation et parce que le modèle peut se systématiser. Après quelques cycles, les modèles quantitatifs dépassent en précision les prévisions de tous les experts, peu importe le domaine. Je crois aussi que plus il y aura de personnes qui comprennent et maitrisent la modélisation quantitative, plus la gestion fera preuve de rationalité, d’humanisme et de démocratie. Voilà le véritable sens de prendre de meilleures décisions, plus rapidement.

La progression de la modélisation quantitative rappelle la métaphore du grimpeur. Au début, tout le monde croit que la falaise est infranchissable, jusqu’à ce qu’un grimpeur la franchisse. Dès lors, d’autres grimpeurs veulent apprendre à la gravir et à en gravir de plus grandes. Dans cette démarche, je me perçois comme un grimpeur qui a réussi à gravir quelques montagnes, mais je suis certain que de meilleurs grimpeurs arriveront avec de meilleures techniques que moi. Ce qui m’importe, c’est de faire partie de la race des grimpeurs fiers de leurs os brisés.

Évidemment, je ne fais pas que grimper et je ne grimpe pas à toutes falaises que je vois, j’ai aussi les pieds sur terre. Je gère, je conçois et je communique. Et parfois, je m’attaque à des problèmes d’analyse un peu plus complexes. Tout cela, surtout en informatique décisionnelle, mais aussi en informatique générale, en développement de système ou dans l’ensemble de la gestion informatique.