Francis Dion sur le processus logiciel

Reporting 2.0

“Reporting 2.0” applique le concept général du « Web 2.0 » – où les contenus sont produits par les usagers eux-mêmes – au domaine des générateurs de rapports. Il s’agit d’un changement fondamental dans la dynamique établie entre le département TI d’une organisation et les usagers des lignes d’affaires pour la création et l’adaptation des rapports.

Dans le paradigme « Reporting 1.0 », un usager exprime des besoins qu’un analyste ou un programmeur tentera de traduire ou de réinterpréter dans le mode d’opération d’un générateur de rapport traditionnel. Ce processus est souvent compliqué par le clivage qui existe entre la façon dont les usagers conçoivent leurs besoins et les contraintes imposées par l’outil. Il faut aussi considérer les délais importants causés par les nombreux essais-erreurs et les allé-retours requis pour chaque changement, particulièrement lorsqu’ils touchent à l’organisation et à la présentation du rapport.

Le « Reporting 2.0 » transforme cette dynamique en permettant une meilleure séparation des responsabilités entre les professionnels de la technologie – principalement préoccupés par les méthodes d’accès sécurisés aux données, par l’application rigoureuse des règles d’affaires et par la définition des algorithmes – et celles des usagers qui sont les mieux à même d’appréhender, de mettre en évidence et d’exprimer le contenu informationnel sous jacent aux données brutes.

Xpertdoc Studio est un outil de type “Reporting 2.0” parce qu’il supporte optimalement cette nouvelle dynamique.

Informatique utilisateur

Dans les organisations d’une certaine envergure une tension se développe souvent entre le département des TI et certains usagers « technophiles » désirant développer eux-mêmes leurs propres solution sur mesure, généralement basées sur des langages de scripts et/ou une suite de productivité telle que Microsoft Office.

Devant cette situation, le département des TI doit choisir entre trois options distinctes :

• Ignorer le problème et courir le risque d’éventuellement devoir supporter une solution développée hors de son contrôle, plus souvent qu’autrement sans aucune considération pour les bonnes pratiques de développement.
• Prohiber strictement ce type d’activité, empêchant du même coup la réalisation d’initiatives valables et nécessaires pour les lignes d’affaires.
• Accepter que ces activités répondent à un besoin légitime pour lequel un développement d’application traditionnel n’est pas économiquement justifiable.

Dans cette troisième option, le rôle des TI est d’accompagner ces usagers en leur offrant le support et les outils leur permettant d’atteindre leurs buts sans pour autant contrevenir aux normes de gouvernances et aux règles d’affaires de l’entreprise.

xpertdoc est idéalement positionné pour supporter la réalisation de cette vision en intégrant :

• La versatilité d’un outil de mise en page (Microsoft Word)  connu et maîtrisé par la vaste majorité des usagers, et
• La puissance et la robustesse des langages de programmation modernes et des systèmes d’entreprise existants.

Avec ces caractéristiques, xpertdoc permet d’établir la balance exacte – et unique! – qui conviendra idéalement à chaque organisation.

Vous avez des expériences à partager sur ce sujet? Des bons coups dont vous êtes fiers? Des erreurs à ne pas faire… ou répéter !? Cliquez sur le lien suivant et xprimez-vous!

http://francisdion.blogs.com/processus_logiciel/2006/12/informatique_ut.html#post

Acheter ou développer?

Quand j’étais employé d’un département TI, je détestais les arguments comme celui-ci, confiant que j’étais (comme à peu près tout le monde dans cette industrie) que nous pouvions faire mieux que tout ce qui pouvait avoir été fait ailleurs.

Maintenant que j’ai un peu plus d’expériences (et les cicatrices pour le prouver), ma position sur ce sujet a passablement évoluée. Bien que de mauvaises pourraient laisser entendre que ce changement d’opinion est quelque peu opportun, considérant que je suis maintenant fournisseur d’une solution pour la production de documents, je dois dire que le constat qui suit est parfaitement en ligne avec ce que me dise de plus en plus les entreprises avec lesquels je fais affaires.

Selon Gartner inc., l’achat de logiciel (par opposition au développement interne de solution) est maintenant la tendance dominante suivie par les départements TI des grandes entreprises. De plus, « … les activités de développement à l’interne devraient être limités aux gains rapides et peu dispendieux ainsi qu’aux projets qui ne peuvent absolument pas être achetés à l’externe ».

Voici une petite liste de contrôle pour décider si l’on devrait acheter ou développer :

1. Existe-t-il une solution commerciale que l’on peut acheter?
2. Développer à l’interne serait-il la meilleure utilisation de nos ressources?
3. La solution ou la fonction ajoute-t-elle un avantage concurrentiel significatif?

La dernière question me semble particulièrement pertinente. Contrairement à ce qui était jadis considéré comme allant de soi, la plupart des initiatives TI ne sont pas source de différentiation dans le marché ni un avantage concurrentiel. Les organisations seraient donc bien avisées de concentrer leurs ressources sur ce qu’elles font de mieux, qui est de servir leurs clients, et de capitaliser sur les investissements en R&D réalisés pas les fournisseurs technologiques spécialisés.

En passant, est-ce que j’ai mentionné que nous étions des fournisseurs technologiques spécialisés dans la production automatisée des documents d’affaires? ;-)

Amélioration des processus : Job#1 des responsables TI

Selon une enquête de  CIO Insight, l'amélioration des processus d'affaires est en passe de devenir la priorité numéro un des décideurs en technologie de l'information, plusieurs d'entre eux considérant maintenant qu'il s'agit de leur principale responsabilité.

J'ai toujours cru que notre industrie devait focaliser moins sur la technologie en tant que tel et davantage sur l'application de la technologie à la création de valeur pour les organisations, sur la manière de les supporter et de les rendre meilleures et plus efficaces.

Des concepts comme le SOA, le Web 2.0 et le End User Computing ne sont pas seulement des "buzzwords" à la mode. Ils représentent une vision de la Technologie au service des organisations "apprenantes" et de leurs "knowledge workers". Cette vision est l'inspiration derrière la prochaine génération d'outils sur lesquels nous travaillons présentement à l' Académie des processus.

Gemba Kaizen

J’ai terminé la lecture de « Gemba Kaizen, l’art de manager avec bon sens » par Masaaki IMAI.

En Japonais, Gemba signifie « lieu du travail » et Kaizen signifie « amélioration continue ». Le livre décrit comment une culture d’amélioration continue du lieu de travail (principalement mais pas uniquement des manufactures) est au cœur du Miracle Japonais depuis les années ’70.

Pendant que je lisais ce livre, je ne pouvais m’empêcher de penser à cette scène du film « Le dernier Samouraï » où Tom Cruise, un occidental fait prisonnier par une communauté de guerriers Japonais, s’émerveille de voir comment tous les habitants, des enfants jusqu’aux vieillards, s’appliquent constamment à atteindre la perfection dans tous les aspects de leur vie.

Voici certains des concepts clés de ce livre :

• L’amélioration de la qualité et la réduction des coûts sont compatibles et devraient, en fait, aller de pair.
• Là où il n'existe pas de standard, il ne peut y avoir d'amélioration
• Les 5S (équivalents Français des termes Japonais : trier, ranger, nettoyer, systématiser et standardiser) sont les règles d’une discipline exigeant que tout ce qui n’est pas utiles soit éliminé.
• Le Muda est tout ce qui est un déchet et/ou qui n’ajoute pas de valeur.
• Établir des standards, appliquer les 5S et éliminer le Muda sont les trois piliers de Gemba Kaizen.
• Le temps Takt est le temps maximum alloué pour produire un produit de façon à satisfaire la demande.
• Le temps de cycle est le temps réel requis pour produire un produit. Dans une organisation fonctionnelle, il est toujours inférieur ou égal au temps Takt.
• Pour qu’un processus soit optimale, chaque sous processus doit être ralenti jusqu’à correspondre le plus possible au temps de Takt.
• Il ne doit jamais y avoir un jour sans amélioration.
• La continuité est l'une des clés du succès à long terme.

Ceci n’est qu’un aperçu des concepts puissants (et parfois dérangeants) offerts par l’auteur. J’ai l’intention d’en explorer quelques uns plus en détails dans les prochaines semaines.

En conclusion, la matière est un peu aride mais j’ai néanmoins vraiment apprécié cette lecture, en bonne partie à cause du lien que je vois entre ces idées et certains des concepts sur lesquels s’appuient les méthodologies Agiles de développement de logiciel. Je le recommande fortement à quiconque s’intéresse à la qualité, à la productivité et à l’amélioration des processus.

Combien coûtent vos données corrompues?

Dans le magasine BASELINE de juillet 2006, j’ai trouvé un petit tableau permettant de calculer le coût pour une compagnie de vivre avec et de maintenir des données corrompues, périmées ou autrement invalides. L’exemple fournit part d’un coût unitaire d’environ 10 cents par erreur et, dans le cas d’une banque, arrive à un coût annuel total dépassant 900 millions de dollars!

On peut évidemment faire dire ce qu’on veut à des chiffres. Il n’empêche que les compagnies auraient avantage, lorsqu’elles examinent leur portfolio d’applications et de bases de données, de tenir compte non seulement de ce qu’il en coûterait pour remédier aux problèmes de non qualité, mais aussi du coût exorbitant qu’ils assument en reportant à plus tard les interventions requises.

La technique de Christophe Colomb

Quand il est parti, il ne savait pas où il allait.

Quand il est arrivé, il ne savait pas où il était.

Quand il est revenu, il ne savait pas où il était allé.

Je suis tombé sur cette analogie dans un livre (Gemba Kaizen: L’art de manager avec bon sens, Masaaki IMAI) que je lis présentement. Je pense que c’est une puissante métaphore pour ce qui se passe dans la plupart des organisations développant du logiciel.

Quand le projet démarre, l’équipe ne sait pas ce qui doit être fait.

Quand le projet est livré, personne ne sait si ça va vraiment fonctionner.

Quand le projet est enfin terminé et que tout semble être en ordre, personne ne sait vraiment pourquoi CE projet a réussi.

Le résultat de cette « technique » est une incapacité de l’organisation à apprendre. Sans apprentissage, l’organisation ne peut tirer de conclusions utiles relativement à ses propres processus. Elle n’a aucune base à partir de laquelle elle pourrait les perfectionner au fil du temps. Elle n’a aucune garantie que les succès d’hier ne deviendront pas les cauchemars de demain.

Voici un aperçu d’une cure simple au « syndrome » de Christophe Colomb :

Planifiez et documentez non seulement le résultat final mais aussi l’itinéraire (les outils, les méthodes, les étapes) qui vous permettront de l’atteindre.

Gardez les plans et documents à jour, en vous assurant que les déviations sont détectées, communiquées et résolues. Favorisez l’éclosion d’une culture ouverte, où la discussion des problèmes est permise et encouragée.

Conduisez scrupuleusement des rencontres de post-mortem. Assurez-vous que tous les participants comprennent ce qui s’est passé et pourquoi. Ceci permettra à l’apprentissage de se produire, favorisant l’éclosion de nouvelles idées qui pourront être testées lors du prochain cycle.

Meilleures pratiques, Gestion de Projet et Amélioration des Processus

Un collègue m’a récemment demandé de lui expliquer la différence entre adopter les Meilleures Pratiques (Best Practices), la Gestion de Projet et l’Amélioration des Processus dans le contexte du développement de logiciel. Pour lui, ces trois disciplines traitent essentiellement de productivité et de gestion du risque, avec comme but ultime de livrer plus rapidement du logiciel de meilleure qualité.

Voici ma réponse :

• Meilleures Pratiques : Recettes pour le succès, leur crédibilité vient de réussites passées dans d’autres organisations.
• Gestion de Projet : Focalisation sur des communications précises et efficaces, le but étant de veiller à ce que toutes les parties impliquées aient accès à la même « version » de la vérité. Requiert l’utilisation disciplinée de procédures et d’outils adéquat pour la communication des statuts. Très difficile à implanter dans une organisation qui n’a pas encore développé une culture d’ouverture et de responsabilisation, sa mise en œuvre devient rapidement une seconde nature – presque mécanique – lorsque les premières résistances finissent par tomber.
• Amélioration des Processus : Approche basée sur les faits pour l’optimisation de la performance, visant à toujours mieux aligner les façons de faire et les résultats avec les besoins spécifiques et les conditions particulières de l’organisation.

L’adoption de Meilleures Pratiques peut aider une organisation à réaliser des succès rapides, permettant d’obtenir à court terme des résultats spectaculaires.

L’application disciplinée d’une solide approche de Gestion de Projet offre un filet de sécurité nécessaire pour éviter des catastrophes coûteuses, permettant d’assurer que les symptômes d’une Pratique inappropriée (oui, même les Meilleures Pratiques peuvent être inappropriées à l’occasion) sont détectés assez tôt pour réagir.

L’Amélioration continue des Processus, lorsque exécutée correctement et supportée par des mécanismes d’opération sociale appropriés, fournit les meilleurs résultats à long terme en suscitant l’émergence d’une culture d’ouverture et de remise en question perpétuelle du statut quo, évitant ainsi que les succès passés ne nous aveuglent aux conditions toujours changeantes de nos organisations.

Ces écarts sémantiques qui font obstacle au succès des projets

Je discutais l'autre jour avec un partenaire (Marc Lamoureux) et notre architecte fonctionnel à l'Académie des processus (France Cano) de l'importance de maintenir une communication directe et bidirectionnelle entre les personnes responsables de coder une application et celles responsables de sa base de données. Nous avons tous vu trop de projets dérailler à cause de délais indus, de contraintes artificielles et autres dysfonctionnements introduits par l'absence d'une bonne compréhension mutuelle des gens responsables de ces aspects cruciaux. Souvent, un camp va "l'emporter" sur l'autre, résultant en un déséquilibre où, éventuellement, tout le monde fini par y perdre. (j'invite ceux que cela intéresse à consulter cet article très pertinent)

Voilà une des multiples manifestations de ce que j'appelle les "écarts sémantiques" qui handicapent tant d'organisations développant du logiciel. En tant que consultant en amélioration des processus, je constate que pas moins de 50% de mon travail consiste à combler ces écarts de compréhensions qui existent entre codeurs et administrateurs de base de données, mais aussi entre codeurs et testeurs, entre le personnel technique et les analystes d'affaires, entre les membres des équipes de projets et les dirigeants, etc. L'autre 50%? C'est simplement de convaincre tout un chacun que leurs projets ne sont pas aussi uniques qu'ils le croient, et que des solutions éprouvées existent à leurs problèmes!

Gestion agile pour projets Agiles

Kevin Aguanno, un gestionnaire de projet certifié avec plus de 17 années d'expériences, sera à Montréal la semaine prochaine (jeudi 3 novembre) pour parler au SPIN de Montréal des défis structurels inhérents à la gestion de projets agiles.

Si vous êtes intéressés, vous trouverez les détails et un formulaire d'inscription en ligne sur le site Web du SPIN : www.Spin-Montreal.org.