Le chantier de construction à l’heure du Web et de la mobilité

Depuis quelques années, tous les secteurs sont bousculés par la révision forcée de leur modèle d’affaires avec l’avènement des technologies Web et mobiles.

Le secteur de la construction ne fait pas exception avec les nouvelles possibilités pour le gérant de projet et le gérant de chantier d’augmenter leur efficacité de gestion et la qualité de leurs livrables.

Qu’il s’agisse de la gestion rigoureuse de la sous-traitance et des bons de commande par le Web,

de la saisie et validation des heures de travail directement à partir du chantier,

ou de la gestion des avis de changement et des documents de chantier, tout devient plus fluide grâce au Web et aux technologies mobiles.

Comme pour tout virage technologique, soulignons toutefois que la présence de ces nouvelles possibilités ne doit pas sonner comme « la transition se fait toute seule ».

Le déploiement de votre gestion vers des utilisateurs sur le terrain comporte des défis de formation importants qui ne doivent pas être négligés au départ.

Si par le passé l’adhésion à de nouveaux outils technologiques était principalement la panacée des gestionnaires financiers, par la suite des chargés de projet et des estimateurs, dorénavant le déploiement technologique cible la ressource de terrain.

Sans négliger la capacité de cette ressource à apprivoiser et à exploiter les nouvelles technologies, il faut bien comprendre le contexte initial de votre virage organisationnel: votre gérant de chantier a quotidiennement bien d’autres défis que d’avoir des enjeux avec « l’informatique ».

Il est donc essentiel de définir, le plus tôt possible, un plan structuré de déploiement et de formation pour votre projet d’informatisation. Ce plan devrait prendre en considération quelques aspects clés:

• Une analyse initiale et le regroupement de vos utilisateurs éventuels par niveau de connaissance et de confort avec les technologies Web et mobiles. Vous aurez alors une vision globale de l’état des connaissances de vos futurs utilisateurs et vous pourrez concevoir un programme de formation plus efficace.

• Un projet pilote avec deux utilisateurs, un premier plus confortable vis-à-vis la nouvelle technologie et un deuxième moins à l’aise. Ce projet pilote vous indiquera rapidement les points forts et les points faibles à corriger dans votre plan de formation.

• Choisissez les utilisateurs impliqués dans le projet pilote avec la perspective d’en faire éventuellement des « superutilisateurs », c’est-à-dire que c’est eux qui pourraient devenir vos formateurs internes. Vous pourrez ainsi réduire vos coûts d’accompagnement externe au minimum.

• Par la suite, votre processus de déploiement devrait procéder par étape, dans une séquence qui ne nuit pas à la gestion courante de vos projets. Vous choisirez donc idéalement un projet sans enjeu criant, un projet qui se déroule bien. Ce contexte permet à l’employé d’investir un peu plus de temps dans son processus d’apprentissage, ce qui augmente l’absorption des connaissances tout en ne déstabilisant pas l’évolution du projet.

• Assurez-vous de mettre en place les mécanismes de communication internes nécessaires afin de supporter au maximum les nouveaux utilisateurs dans leur démarche d’apprentissage. Par exemple, en leur identifiant clairement un point de contact interne en cas de besoin et en leur remettant la liste des ressources d’information complémentaire à leur disposition.

Une approche de gestion structurée de votre démarche d’informatisation vous garantira des résultats optimaux en termes de retour sur votre investissement. Un investissement stratégique pour propulsez votre entreprise dans une nouvelle phase de croissance grâce aux technologies Web et mobiles.

Bonne gestion.

Publicités

La gestion documentaire mobile pour les chantiers de construction

Le volume de documents et de communications dans le secteur de la construction n’est pas un secret pour personne.

En fait, rare sont ceux qui réussissent à minimiser la lourdeur administrative qui impacte directement la rentabilité de leurs projets.

L’informatique du jour nous offre ces recettes rapides et instantanées qui sont, en apparence, assez simples à implanter.

Finalement, le principe se résume à gérer les documents d’un projet et les échanges d’information entre les intervenants du projet. Non ?

En apparence, il semble donc que l’explorateur de Windows^MD permet très bien de gérer les documents d’un projet et que les courriels avec Outlook^MD de Microsoft^MD permettent très bien de communiquer entre intervenants.

Comme toujours en informatique de gestion, « en apparence » ne veut pas dire « facilement ou optimal en réalité ».

Bien que ces technologies de base représentent un excellent point de départ en termes d’éducation, la question suivante vient rapidement par la suite : « Pourquoi ces technologies génériques ne sont pas nécessairement la solution optimale pour partager de l’information et communiquer dans un contexte de projet de construction ? ».

La réponse réside à deux niveaux :

• À cause de la structure documentaire complexe et spécifique qui encadre un projet de construction. Cette structure doit supporter les normes et les meilleures pratiques du secteur (complexité de nature);
• À cause du volume très important de personnes susceptibles d’intervenir simultanément et de partager une même information sur un projet (complexité de nombre).

Ces deux types de complexité appellent donc au respect de certains principes fondamentaux quant à l’architecture et au type d’interfaçage technologique si l’on souhaite optimiser la fluidité et l’efficacité opérationnelle :

• L’information et les communications relatives au projet doivent absolument être centralisées par projet, toute nature de document confondu (soumission, photo, devis, plan, contrat, permis, avis de chantier, etc.) et pour tout type de format technique (texte, vidéo, audio, image, PDF, etc.).

L’analogie est simple : créé l’équivalent de la pochette cartonnée du projet sous forme informatique. Ou autrement dit, mettre en place le dossier de projet « Sans papier ».

Le principe de centralisation de l’information est à la clé de voûte ici pour une information structurée qui peut être partagée rapidement.

• La gestion du partage et des accès à l’information doit pouvoir s’effectuer par projet et d’une façon discrétionnaire par intervenant au projet, sans dédoublement informatique desdits intervenants qui peuvent travailler sur différents projets.

Ou autrement dit : Il ne faut pas avoir à gérer à plusieurs endroits les coordonnées de base (nom, prénom, adresse, cellulaire, etc.) d’un intervenant donné parce qu’il travaille sur différents projets.

En apparence simple quand on pense à l’envoi d’un document par courriel avec Outlook^MD, cet outil vous impose pourtant beaucoup de manipulation manuelle pour gérer « qui a droit à quel document ». Et que dire des efforts pour des recherches complexes si vous avez éventuellement besoin de retrouver rapidement un document réponse, exemple, d’un sous-traitant donné.

• Les communications et le partage de documents doivent pouvoir s’effectuer dans un cadre d’accès sécurisé intégrant la notion de traçabilité et de confidentialité du partage documentaire. C’est-à-dire que vous pouvez en tout temps savoir « quand et qui a pris connaissance d’un document donné » ou, encore, « qui a dit quoi à quel moment à propos d’un document (ex : un plan) en rapport avec la gestion du projet ».
• La plateforme de communication et de partage de l’information doit être multidimensionnelle, soit simultanément permettre une gestion interne et locale, une gestion via le Web et une gestion via les équipements mobiles (tablette, téléphone intelligent, etc.) pour intégration complète avec le chantier.

La mobilité de votre gestion est une caractéristique clé et très spécifique au contexte du secteur de la construction.

Certaines solutions de gestion de projets de construction, telle que celle de CTRL, répondent à ces critères essentiels pour mettre en place une plateforme de partage documentaire extrêmement efficace pour votre entreprise.

Elles sont normalement dotées d’un CRM entièrement intégré qui permet de couvrir l’ensemble des aspects de gestion spécifiques au secteur de la construction tout en permettant à votre entreprise de se propulser dans l’ère du Web et de la mobilité.

Des portails Web standards permettent d’étendre et de déployer rapidement votre gestion vers vos chantiers : consultation de plans à distance, feuille de temps Web, bons de commande et de sous-traitance de chantier, gestion de tâches, etc.

L’ensemble de ces nouvelles possibilités technologiques sont intégrées de façon transparente avec les fondations comptables, de paie et de gestion de projets, des fondations robustes qui contribueront à la qualité de vos projets et qui stimuleront votre croissance.

Bonne gestion.

Gestion de la résistance aux changements

Tout le monde connaît la théorie, tout le monde sait quoi faire, mais le sujet est constamment ramené sur la table lors de déploiement de projets TI.

Avez-vous déjà eu l’impression que l’on vous disait n’importe quoi face à une prérogative simple dans le déroulement d’un projet? Qu’on vous servait des commentaires illogiques vis-à-vis votre démarche structurée? Des commentaires qui n’étaient pas axés fondamentalement sur une dynamique constructive et d’avancement du projet? Si oui, rassurez-vous, vous n’êtes pas seul gestionnaire à rencontrer cette situation.

Notre expérience de spécialistes ERP nous conduit invariablement au constat suivant: les enjeux du chargé de projet ERP se composent minimalement à 50% d’aspects psychologiques (gestion du changement), la proportion restante s’adressant aux enjeux opérationnels (processus) et technologiques.

Le phénomène est connu depuis longtemps: la résistance aux changements.

Pour bien cibler ce dont nous parlons ici, notez que toute personne a le droit à l’erreur. Constater qu’on s’est trompé et s’ajuster en conséquence ne constitue pas de la résistance aux changements. Il s’agit simplement de la gestion de projet courante.

De plus, il n’est pas de l’objectif de revenir sur les symptômes de la résistance au changement (référence à l’image ci-dessus) mais bien de mettre en évidence les causes fondamentales du phénomène.

Une bonne compréhension des dynamiques psychologique qui lui sont liées vous permettra de définir une approche de déploiement qui en réduit les impacts. Le déploiement de vos projets TI, et de votre entreprise, n’en deviendra que plus optimal sur le plan des coûts et des délais de livraison.

L’humain, l’humain…encore l’humain

Plusieurs sont convaincus de la supériorité absolue de l’homme sur les animaux. Pourtant nous partageons des points communs non négligeables avec nos amis. Pensons simplement à la peur qui est liée de près à l’instinct de survie.

La psychologie de l’homme est complexe. À ce sujet, je vous invite à prendre connaissance de la fameuse pyramide des besoins de Maslow à titre de référence de base.

Pour demeurer terrain, dans un premier temps tentons de définir le processus de création, de la naissance progressive de la résistance au changement. À cette fin, je vous propose la réflexion suivante:

• Tout être humain a besoin d’un sens, de se sentir utile, c’est une question de bien-être mental, donc de survie.
• Se sentir utile, voir un sens dans notre travail, vient en grande partie avec le sentiment de compétence.
• Or ne pas savoir quoi dire ou quoi faire déclenche un sentiment d’incompétence.
• Personne ne peut accepter de ne pas être bon, de se sentir incompétent et inutile sur une longue période.
• Les conséquences envisagées de son incompétence, telle que possiblement perdre son emploi ou son pouvoir, génèrent de l’incertitude.
• Or l’incertitude face à l’inconnue, la nouvelle technologie, la nouvelle façon de faire, génère la peur.
• Une peur intense déclenche des comportements défensifs ou agressifs.
• Une personne qui a peur cherche à supprimer les stimulus qui causent son malaise (question de survie).
• Le réflexe devient davantage instinctif et émotionnel que cartésien, les réactions, les gestes deviennent alors incohérents.
• On constate alors un phénomène de résistance aiguë.

Prenez ce schème de réflexion et appliquez-le à vos problématiques de résistance dans des projets en cours. Il est fort probable que vous arriviez en fin de course à l’identification d’une composante de « peur » chez la ou les ressources les plus problématiques.

Peur de décevoir, peur de ne pas être à la hauteur, peur d’être vu comme incompétent, peur de dire qu’on n’avait pas compris, peur de perdre du pouvoir et de la crédibilité, etc. Voilà un ensemble de raisons qui peuvent être exprimées.

Une personne qui se retrouve dans une situation de grande incertitude, ou de peur, peut vivre ce qui est appelé un phénomène de dissonance cognitive. Il s’agit du comportement d’une personne qui va à l’encontre de ce qu’elle exprime. Par exemple, le fait de poser des gestes en contradiction avec une pensée confirmée en rencontre de gestion de projet. Une réaction illogique…en apparence.

Ce ne sont pas toutes les personnes qui automatiquement entrent dans un phénomène de dissonance cognitive dans une situation de grande incertitude. La chose dépend de plusieurs facteurs, dont la confiance en soi présente au départ.

Mais quand le phénomène apparait, il s’agit de situations plus complexes à gérer et qui nécessitent plus de doigté. Il importe donc de comprendre ce qui se passe à la base chez les intervenants concernés.

Je vous propose de lier ce morceau du casse-tête à la théorie du cerveau triunique, un cerveau en trois couches héritées de l’évolution progressive de l’homme.

Contesté par certains scientifiques, ce modèle me permet d’introduire la suprématie de réaction par l’instinct, par l’émotion et non par le rationnel de l’être humain lorsqu’il  vie un sentiment de peur important.

La clé ici est de comprendre qu’il y a une hiérarchisation dans la couche qui contrôle le comportement d’un être humain selon la situation vécue. Exemple, vous êtes affamé, l’instinct prendra le dessus. Vous vivez une grande peine, inutile de vous dire de vous prendre en main et d’être logique, c’est le limbique et l’émotion qui dictent votre comportement.

En résumé, lorsqu’une personne est incertaine, insécure et qu’elle a peur, ce n’est plus le rationnel, la logique cartésienne qui dirige. Ce sont l’instinct et l’émotion qui dictent alors ses gestes et ses paroles, d’où les réactions illogiques perçues parfois en tant que gestionnaire de projets.

Comment tenir compte de cette dynamique en gestion de projets?

Les explications théoriques précédentes étaient nécessaires pour appuyer mes recommandations au gestionnaire de projets qui fait face à des situations critiques de résistance aux changements. Voici mes suggestions:

• Prenez rapidement conscience que votre enjeu principal dans le déroulement du projet s’est déplacé d’un volet technique/opérationnel vers un volet psychologique. Développez-vous des trucs pour détecter rapidement que le cheminement du projet vient de basculer dans un autre univers, celui de l’émotion.

Exemple: En cas de doutes, augmentez la fréquence et réduisez la durée des rencontres. En ciblant des petites avancées pour chaque rencontre, vous constaterez beaucoup plus en amont qu’il y a une démobilisation d’une personne ou d’une équipe si les petites avancées en question ne se font pas.

• Ne vous acharnez pas à traiter une situation émotionnelle par une méthodologie cartésienne. N’utilisez pas un diagramme de Gantt ou de Pert pour insister sur des ajustements visant à résoudre un blocage. Ne parlez pas d’ingénierie de projet pour résoudre un enjeu humain.

Au moment où la problématique principale d’un projet se déplace du côté humain, travailler plutôt à comprendre les origines de la dissonance que vous mesurez. Il y a fort probablement des gens qui ont peur de quelque chose. Identifiez ces gens, identifiez l’origine de leurs craintes. Discutez avec eux, sans lien direct avec l’avancement du projet, mais plutôt sur ce qui les inquiète personnellement et les empêche de participer activement à une belle aventure. Au besoin dans les cas plus aigus, faites-vous appuyer par le département RH ou par un psychologue.

• Votre patience peut être très limitée en période de gestion intense et critique de projets. Vous pouvez devenir très rapidement frustré par un comportement illogique à vos yeux. Toutefois, restez calme et posé dans le ton que vous prenez avec le ou les intervenants concernés. Il faut comprendre que plus vous emprunterez un comportement agressif, dictatorial ou très pragmatique, plus vous confirmerez à votre interlocuteur qu’il a raison de se sentir incertain, d’avoir peur de quelque chose, quelque chose dont il n’a peut-être aucune idée d’ailleurs. Votre objectif n’est pas d’amplifier une problématique, mais bien de la résoudre.

• Si cela s’avère possible selon la nature et le stade du projet, utilisez les intervenants les plus problématiques pour les transformer en pivot opérationnel, en référence, pour en faire des leaders informels dans votre projet.

Les personnes offrant habituellement la plus grande résistance aux changements sont habituellement celles qui s’expriment davantage, les plus émotionnelles et extraverties, celles qui occupent souvent ou qui pourrait occuper un leadership informel au sein de leur équipe. La raison est simple: c’est leur leadership ou leur pouvoir qui peuvent être menacés par une nouvelle technologie ou une nouvelle façon de faire. En leur donnant la chance d’influencer le cheminement du projet, en leur donnant un pouvoir pertinent, ces acteurs se transforment souvent en véritable moteur à réaction qui propulse le projet en avant.

Comme je le réitère à chaque fois que je le peux, la technologie est un moyen et non une solution. La meilleure technologie au monde ne pourra pas améliorer la productivité de votre entreprise si votre équipe n’en a pas fait une appropriation maximale. Dans cette perceptive, la clé est de s’assurer de la participation positive de tous et, par conséquent, de traiter rapidement et efficacement tout enjeu de résistance susceptible d’apparaitre en cours de projet.

Bonne gestion.

Déploiement de systèmes « objet », le SOA en mode gestion

Le Web et la mobilité multiplient les dimensions opérationnelles d’un projet d’informatisation ERP. Les méthodologies classiques de déploiement de systèmes qui produisaient déjà des succès mitigés, font face maintenant à une réalité augmentée, un cube rubique de 10 par 10 sur le plan des variables à gérer.

Cette multiplication de variables peut plus que jamais diriger une entreprise vers des problématiques majeures si la gestion du projet d’informatisation n’est pas adaptée aux nouveaux paradigmes opérationnels introduits par les technologiques Web et mobiles.

Rappelons également que cet ajustement méthodologique doit continuer de s’effectuer dans le cadre des objectifs fondamentaux qui eux ne changent pas: rencontrer les délais de livraison et le budget prévus.

À la lumière du taux de succès historique moyen des projets ERP, il peut être naturel de se sentir au départ plus près de l’utopie que du changement de paradigme.

Bref, les approches de déploiement classiques doivent se réinventer sinon les nouveaux projets adressés dans cette approche généreront davantage de systèmes isolés en silo, un résultat qui désintègre les opérations d’une entreprise sur le fond.

Dans le cadre classique, plus de silos isolés est synonyme de perte de levier opérationnel global. Ce qui rend la situation subtile est qu’en apparence, à l’ère du Web et de la mobilité, la magie des interfaces très esthétiques peuvent faire croire le contraire et, par conséquent, même justifier une stratégie de déploiement déficiente à la base.

Voilà un enjeu critique, soit celui de ne pas revenir à la case départ sur le plan des méthodologies de déploiement sous le couvert justifié, mais à nuancer, d’une clientèle, interne ou externe, conquise par des interfaces plus beaux et simplifiées.

Ma dernière affirmation vous créé un spasme rationnel? Comment pouvons-nous être contre une clientèle plus satisfaite? La nuance: Bien sûr toujours « Oui » à une clientèle plus satisfaite, mais…il faut aussi valider à quel coût.

Si votre clientèle est extrêmement satisfaite, mais que votre entreprise génère des pertes mensuelles, vous devrez fermer vos portes éventuellement. Comprendre qu’elle ne sera plus satisfaite par votre entreprise et qu’elle trouvera certainement un concurrent très heureux de l’accueillir. Il n’y a qu’un seul perdant dans cette situation: votre entreprise!

Je constate souvent avec étonnement cette espèce de distorsion de gestion qui créé pratiquement un lien direct entre « Clientèle satisfaite » et « Entreprise profitable » dans le cadre de réflexion stratégique.

Pour fermer cette boucle sur la satisfaction clientèle comme unique indicateur potentiel de succès d’un projet ERP, concluons qu’il peut s’agir d’un leurre donnant une fausse lecture car ce qu’il faut mesurer sur le fond, c’est levier opérationnel final, le gain de productivité global du projet, soit son impact mesurable, immédiat ou à terme, sur l’accroissement de la rentabilité de l’entreprise.

Cette mise en contexte de vecteurs d’influence subtile est nécessaire pour faire ressortir que les approches de déploiement de systèmes doivent s’attaquer dorénavant à un niveau de complexité beaucoup plus élevé de résistance au changement dans les projets. L’amplitude et la complexité du volet « humain » sont maintenant tellement élevées qu’ils peuvent désormais présenter à eux seuls le véritable défi d’un projet ERP.

Pour aborder cette nouvelle complexité dans une approche de déploiement de système renouvelée, je propose donc d’adopter les concepts technologiques de l’architecture « SOA »  (Service Oriented Architecture), ou « Architecture Orientée Service » dans la langue de Molière, comme principes globaux d’une méthodologie d’implantation renouvelée.

Il est d’abord connu qu’à problématique complexe, il est efficace de découper le problème en ses composantes clés et de les adresser individuellement dans un premier temps.

Dans la vision que je propose, bien comprendre ici qu’il ne s’agit pas de découper pour isoler, mais bien de découper en vertu de trois règles et objectifs précis:

• Comprendre la nature et les dimensions fonctionnelles d’une composante opérationnelle (rôle, fonction, tâche, criticité, complexité, résultat ciblé, etc.) dans le cadre d’un processus d’affaires.
• Évaluer le niveau de résistance potentiel des intervenants directement impliqués sur le plan fonctionnel (attentes, attitude, formation, etc.)
• Analyser et décrire les points de communication et d’échange de la composante opérationnelle avec ses prédécesseurs et successeurs dans le cadre des processus d’affaires dans lesquels elle intervient.

C’est dans cette approche découpage ajustée et, plus particulièrement, dans le troisième objectif que le parallèle avec l’approche SOA apparaît.

De façon simplifiée ma proposition est la suivante:

« Isolons les composantes opérationnelles pour mieux les comprendre et réduire la complexité fonctionnelle et humaine, mais attaquons rigoureusement dès le départ,  la question des liens et de l’intervention de la composante opérationnelle avec tout processus d’affaires de l’entreprise. »

Autrement dit, isolons pour faciliter et augmenter substantiellement les probabilités de succès du déploiement ERP mais en s’assurant constamment de la totale intégration opérationnelle de la composante tout au long du déploiement progressif du système.

Il y aurait plusieurs explications additionnelles à donner sur les mécanismes et les leviers naturels positifs de l’approche que je propose, mais j’y reviendrai suite à des questions ou dans un prochain article.

Ce qui importe ici c’est de constater l’adéquation et la similarité avec l’approche SOA qui s’appuie sur des principes tels que les suivants:

• Indépendance et autonomie maximale des services
• Interopérabilité maximale des services
• Unification des protocoles d’échange interservices

La notion de « Service » de l’approche SOA est finalement simplement transférée en notion de « Composante opérationnelle » de l’approche renouvelée de déploiement de systèmes.

L’application et le transfert de principes fondamentaux de l’approche SOA vers le domaine des méthodologies d’implantation de systèmes ERP change donc le paradigme classique en appliquant priorisant une approche de travail locale, mais toujours adressée dans une vision analytique globale de la composante opérationnelle.

L’approche classique cible la modélisation et le support complet d’un processus d’affaires global comme seul objectif logique pour le succès du projet quitte à forcer des changements opérationnels important dans les composantes impliquées dans le processus.

L’idée maîtresse de la nouvelle approche suggérée est de permettre de s’attaquer à des composantes opérationnelles de manière isolée, sans obligation d’en changer la nature et les mécanismes internes, en respectant une seule règle fondamentale: soit de s’assurer d’échanges et de communications standardisées avec les autres composantes impliqués dans un processus d’affaire global.

En termes de déploiement de systèmes, il s’agit donc d’intégrer dès le départ l’analyse des échanges d’information, exemple entre un département donné et un autre, dans le processus d’implantation d’un outil local dédié à un département.

Un des leviers stratégique de succès de cette nouvelle vision est donc qu’elle se base sur un phénomène naturel en entreprise: le directeur ou chef de département souhaite toujours contrôler le choix et le déploiement d’un nouvel outil de gestion informatisée dans  ses opérations. Ses responsabilités dictent d’ailleurs ce mode de pensée.

Ce responsable ne peut être en conflit constant contre l’idée de faire avancer globalement l’entreprise même s’il souhaite gérer tout changement au sein de son département.

Au moment où il est convaincu que le nouvel outil peut améliorer les performances de son département, il ne reste plus qu’à travailler sur les deux aspects centraux pour chaque composante opérationnelle (Service) impliquée de son département :

• Quelle information est requise à l’entrée de la composante (input)?
• Quelle information la composante doit fournir à l’externe (output)?

En travaillant les processus d’affaires globaux ciblés par un projet ERP dans cette nouvelle perspective méthodologique, l’efficience et l’efficacité globales sont constamment au centre des préoccupations de déploiement par le mécanisme naturel de validation constante de l’intégrité des échanges intercomposantes.

De plus, le focus et l’attention de l’équipe de déploiement s’attaque à des problématiques réduite sur le plan humain et opérationnel, ce qui réduit les risques de dérapage et augmente automatiquement les probabilités de succès du projet ERP.

Bonne gestion.

Interface utilisateur: la convergence du Web, de la mobilité et du modèle classique

L’interface « homme-machine« , le dispositif qui vous permet d’interagir avec votre équipement préféré tel que votre téléphone intelligent, est la composante clé qui détermine l’efficacité et la satisfaction que vous pouvez en tirer.

Lors d’une récente session sur mon portail bancaire, je remarquais que de nouvelles options avaient été ajoutées à la page principale, que certaines avaient déplacées, qu’on avait modifié le libellé de certaines autres options…j’ai alors esquissé un sourire résultat d’une espèce d’émotion hybride. L’utilisateur en moi: « merde où est rendu la fonction, je n’ai pas de temps à perdre ». Et le concepteur de logiciel en moi : « hum bien pensé, c’est beaucoup plus logique ».

Je suivais le sujet de près depuis quelques années, mais voilà qu’il m’apparaissait mûr: la conception d’interfaces des applicatifs Web et mobiles est arrivée à une étape charnière. Une étape vécue historiquement par les applicatifs classiques.

À mon avis, les enjeux des interfaces Web et mobiles devraient se réalignés dans le courant principal de réflexion d’ici 3 à 5 ans avec la convergence évidente, sur le plan de la gestion, des applicatifs multiplateformes et multipériphériques. Je vous propose ici ma vision des choses quant aux impacts potentiels à considérer pour le concepteur de produits.

Tout en continuant de devoir être assurément esthétiques, les interfaces utilisateurs Web et mobiles seront dorénavant confrontées plus que jamais au paradoxe de l’équilibre entre la « Simplicité » et « l’Efficacité »

Vous noterez peut-être que mon billet n’accorde pas toute l’importance nécessaire à la notion « d’esthétisme ». Cette omission est volontaire pour éviter de m’embourber dans des questions délicates telles que: Qu’est-ce qui est beau et qui ne l’est pas? Vous aimez le vert, mais qu’en est-il de votre voisin?

L’esthétisme est une notion relative et donc subjective. Les références collectives existent, mais le sujet nécessiterait un billet en soi. D’autre part, cette subjectivité appelle à la capacité de personnalisation des interfaces, notion que j’intégrerai au passage.

Ce qui est simple est efficace…euh vraiment?

Depuis le début des années 2000, les notions de simplicité et d’efficacité ont été fortement bousculées, mais, surtout, trop souvent mélangées avec des réflexions du type « Une interface simple est nécessairement efficace » ou le contraire « Une interface efficace est nécessairement simple ». La première des deux étant la plus courante.

D’abord, si la simplicité et l’efficacité sont des notions cartésiennes, mesurables, il n’en reste pas moins qu’elles sont extrêmement relatives selon l’utilisateur.

De plus, on ne peut mesurer que des résultats et dans le cas qui nous préoccupe, nous pouvons dire qu’il s’agit de l’atteinte de deux objectifs de base:

• Faire une tâche pour obtenir un résultat souhaité.

• Faire la tâche en question le plus rapidement possible.

De là, voyons immédiatement la distinction à faire:

• La capacité de faire une tâche par le biais d’une interface est liée à son degré d’interprétation intuitive pour poser les actions nécessaires. Si l’utilisateur ne peut comprendre ou déduire facilement ces actions, les probabilités d’absence de résultat et de blocages opérationnels augmentent.

• La rectitude et la rapidité avec laquelle la tâche peut être effectuée via l’interface déterminent l’efficacité de cette dernière. Pour être sûr que nous sommes au même endroit: si l’interface est simple, mais qu’il ne conduit pas à la bonne tâche…c’est foutu!

Que cachent ces constats? Que la nature des tâches et les connaissances de l’utilisateur le prédisposent automatiquement quant à la perception de ce qu’il considère simple et efficace.

Ajoutez les dimensions psychologiques (ce que je connais m’apparaît plus simple) et d’imprévisibilité du monde réel (je dois faire plusieurs choses en même temps) et nous obtenons la toile de fond qui explique en grande partie pourquoi les notions de « simplicité » et « d’efficacité » ont perdu autant leurs références chez les concepteurs de produits au cours des dernières années.

Adapter l’ergonomie de la machine aux compétences du conducteur

Compte tenu de la variabilité extrême des contextes opérationnels, il devient très important de profiler adéquatement, et le plus tôt possible, votre utilisateur final. Cette information est cruciale pendant le processus de conception de l’interface d’une fonction ou des principes généraux de navigation d’un produit.

Le recours à des groupes de discussion (« focus group ») s’avère un passage obligé pour vous permettre d’établir des lignes directrices fiables en lien direct avec votre futur utilisateur.

Outre les données démographiques pertinentes (âge moyen, sexe, formation académique, expérience pertinente, etc.), ce qui m’apparaît un élément de base à établir, c’est le profil opérationnel de l’utilisateur cible. Deux aspects devraient être quantifiés à ce niveau:

• Tâches répétitives ou variables. En terme de nombre d’interactions types avec l’applicatif, quelles proportions (%) visent une même tâche par jour.

• Taux d’imprévus opérationnel. Combien de fois par jour êtes-vous interrompu pendant une tâche pour faire une autre tâche différente.

Interface statique, interface dynamique et autres

Sans conclure à un lien direct, le mode d’interaction à privilégier avec un utilisateur est fortement influencé par son profil opérationnel.

Une interface statique se prête habituellement mieux à un environnement de travail plus répétitif. Une structure statique facilite l’optimisation « simplicité/efficacité ».

D’ailleurs, l’utilisation d’interface statique est à la base même du succès et de la pénétration des interfaces Web et mobiles à partir des années 2000. Lorsque l’objectif n’est de faire qu’une seule ou que quelques tâches, l’interface de ce type d’applicatif peut devenir extrêmement statique, simple et efficace.

Ajoutez les possibilités graphiques du jour et des possibilités fonctionnelles restreintes et vous obtenez également une plus grande flexibilité pour créer de l’esthétisme. Steve Jobs  en a fait la preuve éloquente: la simplicité n’aura jamais été aussi belle, raffinée et attirante!

De leur côté, les interfaces dynamiques présentent tout leur potentiel dans les contextes de gestion où l’imprévu est roi. Des contextes dans lesquels l’utilisateur doit constamment modifier son plan de travail. La clé dans ce cas est la notion d’adaptabilité à la situation imprévue, la flexibilité d’adaptation opérationnelle.

Sur le plan historique, l’interface dynamique est communément appelée « interface contextuelle  » ou « interface à menus contextuels » (Context-Sensitive User Interface). Il a émergé au cours des années ’70 avec le concept des interfaces graphiques (GUI – Graphical User Interface).

Sans oblitérer la notion de « Simplicité », l’enjeu principal de ce type d’interface devient l’efficacité, la rapidité avec laquelle l’utilisateur peut passer d’un contexte de travail à un autre et, à ne pas négliger, la rapidité avec laquelle il peut revenir à son contexte initial. Pour utiliser des termes de gestion manufacturière, nous dirions que ces interfaces sont des spécialistes de réduction des temps de mise en marche (« setup time »).

Il faut souligner aussi l’introduction récente du concept d’interface adaptatif , exploité plus particulièrement dans l’univers du Web sous le libellé mieux connu de « Responsive Web Design ». Toutefois, il ne faut pas confondre ce dernier avec le concept d’interface dynamique. La distinction n’est pas un automatisme évident pour le profane, j’en conviens.

Le concept d’interface adaptatif s’attaque à l’enjeu de la qualité constante de l’expérience utilisateur dans le cadre de la variabilité des plates-formes matérielles exploitées par l’applicatif Web ou mobile. Vous changez d’équipement, on s’assure que vous demeuriez dans un contexte de navigation logique et performant.

Ce joyeux mélange de possibilités technologiques nous conduit finalement à la tendance lourde de l’interface personnalisable. Cette approche qui permet à l’utilisateur de créer sa propre saveur de « simplicité/efficacité » et d’augmenter ainsi son confort d’utilisation et ses performances. Deux aspects liés à l’optimisation de sa productivité. La tendance ne fera que s’accentuer à ce niveau.

Et pour le futur, l’interface à morphologie adaptable est certainement un incontournable pour combiner de façon fluide différents modes d’interaction (statique, dynamique) pour un même utilisateur. Les tableaux de bord de gestion sont des cibles parfaites pour ce type d’approche.

Mais encore…

Cette panoplie de possibilités nous laisse croire que tout est en place pour poursuivre notre ascension sur la courbe de la productivité individuelle et corporative. Mais il y a un phénomène susceptible d’impacter le cheminement des applicatifs Web et mobiles et, donc, de toucher bien des utilisateurs de technologies sur la planète.

Pour saisir ce phénomène, il faut d’abord mettre en perspective que depuis leur pénétration active à partir des années 2000, les principes et concepts d’interfaces d’utilisation des applicatifs Web et mobiles ont très peu été remis en question par rapport, par exemple, à l’évolution historique des GUI. Le marché et le client ont imposé la route à suivre en absence d’exigences opérationnelles critiques.

L’univers du Web et de la mobilité s’est donc développé pratiquement en parallèle comme si une coupure spatio/temporelle était survenue dans le continuum de l’évolution technologique historique.

Les besoins étaient simples et/ou les possibilités technologiques étaient, somme toute, limitées en grande partie par la vitesse et le prix de la bande passante. Mais la réduction progressive des coûts de communications combinée aux innovations portées par la virtualisation matérielle ouvre dorénavant de nouveaux horizons aux applicatifs Web et mobile. Ces nouveaux horizons de gestion amènent avec eux leurs impératifs.

Il est de la tendance naturelle de l’homme à vouloir constamment en faire davantage avec ses outils. L’utilisateur de technologies informatiques n’est pas différent. Il cherche constamment à en faire plus, à en obtenir davantage. Et ce réflexe est encore plus présent dans le contexte spécifique de l’accroissement de la productivité organisationnelle.

L’applicatif qui offrait jusqu’à maintenant que quelques options (appeler, expédier un courriel, payer une facture) devrait donc, en principe, être de plus en plus bonifié sur le plan fonctionnel.

Comme l’accès à une fonction nécessite un élément visuel (hyperlien, bouton, icône, etc.) pour son activation, l’évolution naturelle peut nous conduire vers un bel arbre de Noël en terme d’interface.

Passé un certain degré limite de charge visuelle, une interface perd automatiquement en simplicité et en efficacité. Il est connu que l’être humain ne peut se concentrer que sur un maximum d’éléments visuels à la fois, 3 à 5 habituellement, pour prendre une décision et interagir rapidement. Comme la simplicité et l’efficacité sont deux conditions essentielles pour justifier l’utilité d’un applicatif, il faut donc revenir à la case départ si la surcharge d’une interface dégrade ces aspects.

Il faut déduire ici que l’accroissement de la capacité fonctionnelle d’un applicatif entraîne éventuellement un exercice de structuration fonctionnelle de l’interface qui peut, malheureusement, être associé parfois à de la perte de simplicité pour certains utilisateurs.

Pour le concepteur d’applicatifs

Le concepteur de produits Web et mobiles sera donc confronté comme jamais auparavant au dilemme d’équilibre « simplicité/efficacité » au cours des prochaines années. Il doit donc anticiper cette mouvance pour garantir l’évolution et la pérennité de ses applicatifs.

Pour certains concepteurs, il est possible aussi que le phénomène produise moins de vagues que prévu. Si vous ciblez un utilisateur à tâches très spécialisées, l’interface statique conservera alors son positionnement stratégique. Autrement dit, si votre produit n’a pas de vocation naturelle pour un déploiement opérationnel étendu, vous êtes probablement hors d’atteinte.

Pour les autres, voici quelques suggestions à mijoter dans le cadre d’une stratégie de réalignement au besoin:

• S’il s’avère possible de vous doter d’une feuille de route de produit claire et précise (« Product Road Map » ), cette dernière devrait vous permettre de garantir la fluidité d’évolution de votre interface et d’éviter le principal écueil commercial, soit celui de décevoir une clientèle existante suite à des changements trop radicaux.

• Si le réflexe des changements progressifs est alléchant pour des raisons de temps, conserver à l’esprit que la cohérence de votre interface utilisateur contribue fortement à la rapidité d’adoption de votre nouvelle vision par vos utilisateurs. L’incohérence dans les mécanismes d’interaction peut être perçue comme un produit non terminé ou incomplet.

• Réfléchissez beaucoup avant de faire une refonte globale et fondamentale de votre interface utilisateur. Assurez-vous de conserver la personnalité de votre produit, sa philosophie, bref tous les éléments qui ont contribué à son positionnement par rapport à votre concurrence. Devenir quelqu’un d’autre que vous n’avez jamais été n’est pas impossible, mais l’opération exige du doigté sur le plan des communications.

En conclusion

À l’heure où le téléphone intelligent est l’extension technologique par excellence de l’être humain, faisant de lui un pseudo-cyborg, cet utilisateur continuera d’en demander plus et de vouloir tirer davantage de ses outils technologiques.

Les applicatifs Web et mobiles seront donc inévitablement confrontés à de nouveaux enjeux d’ergonomie d’interface au fur et à mesure de la bonification de leurs capacités fonctionnelles.

Au moment où le téléphone intelligent se présente comme le périphérique unificateur de tous les besoins (film, TV, banque, journal, agenda, téléphone, achats, feuille de temps, etc.), les enjeux d’interface pour toutes les plateformes technologiques confondues sont désormais réunis sous un même courant de recherche et d’innovation.

CRM – XRM, retour vers le futur!

Je donnais récemment une conférence sur les concepts opérationnels derrière les CRM (Customer Relationship Management), conférence pendant laquelle je profitais de l’occasion pour introduire la notion moins familière de XRM (Extended Relationship Management).

C’est très intrigué que j’ai dû répondre à une vague de questions liées à l’opérationnalisation de base d’un CRM plutôt, par exemple, qu’à des questions axées sur une vision du type « Qu’est-ce que je pourrais faire de plus dans le futur avec mon CRM, quelle serait ma prochaine étape? ».

Je vous partage quelques conclusions de cette rencontre forte intéressante en souhaitant que mes propos puissent servir dans le cadre de vos projets actuels, ou futurs, de CRM / XRM.

Un peu d’histoire

La quête de gestion des relations d’affaires, ainsi que des outils pour la supporter, n’est pas nouvelle. C’est l’étendue et le degré de cette gestion relationnelle qui se sont accrus dans le temps. Sous forme très succincte, voici l’évolution des outils de ce domaine en quatre moments importants:

1980: Le domaine de recherche connu sous le libellé « CSCW – Computer Supported Cooperative Work » émerge à peu près en même temps que l’appellation « Groupware » (logiciel de groupe) associée davantage à la technologie supportant les concepts CSCW.

1990 : Des offres commerciales structurées s’installent concrètement dans le marché avec la promesse d’optimiser les communications dans une équipe de travail. Le logiciel « Lotus Note » est un ambassadeur issu de cette période.

2000: L’introduction d’une offre CRM claire dans le monde du logiciel avec l’arrivée, parmi d’autres, de la désormais très connue compagnie « Sales Forces« . L’objectif principal exprimé est de doter les entreprises d’un outil appuyant l’automatisation et l’optimisation de la force de vente. On voit apparaître les notions d’automatisation de la force de vente (SFA – Sales Force Automation) et de vision « 360 degrés » qui visent la maximisation du potentiel client.

2007: La notion de plate-forme XRM apparait. Fréquemment associé davantage à une façon de faire plutôt qu’à une technologie spécifique comme telle, l’objectif principal poursuivi devient l’automatisation et l’optimisation des processus d’affaires d’une entreprise dans leur globalité. De nouveaux horizons de performance corporative sont découverts et continus de l’être.

Un constat

Ce n’est pas un hasard si les concepts des CSCW se sont d’abord matérialisés sous des outils dédiés à la force de vente. Les ventes c’est le nerf de la guerre comme le dit l’expression consacrée. Il va également de soi de dire que les ventes, c’est avant tout la gestion du « relationnel ». Donc, pas surprenant qu’on ait dirigé rapidement les possibilités de gestion communicationnelles des outils CRM vers cette composante stratégique de toute entreprise.

Les ventes, c’est aussi une enclave de gestion passablement contrôlée, isolée, avec un objectif très clair. Une équipe de ressources s’appuyant sur des processus, une méthodologie et une théorie marketing bien établie. J’entends ici que l’ambiguïté opérationnelle est en principe moins présente.

Je fais une distinction ici entre le volet « Marketing » où il est davantage question d’analyse, de positionnement, de différenciation et de stratégie commerciale et le volet « Force de ventes » qui déploie le plan d’action sur le terrain. Bref, quand on fait partie des ventes, on doit se rappeler constamment le mantra « Just do it! ».

Donc des concepts et des outils dans un environnement contrôlé et pourtant, en revenant à ma conférence, des utilisateurs qui m’exprimaient leur volonté, mais aussi leurs difficultés et leur réticence à aller de l’avant avec un projet CRM même si ce dernier se limitait à l’équipe de vente.

La raison fondamentale est bien simple et les participants l’ont exprimée très clairement. Évidemment chacun à leur façon dans leur contexte et selon les objectifs qu’ils poursuivaient avec leur projet. La force de ventes, même avec un plan d’action marketing clair et précis, n’opère pas réellement en vase clos.

Certains reviendront ici à la notion de « vision 360 degrés ». Je dis « pas tout à fait » si on se limite à la force de vente uniquement. Je « d’accord » si nous parlons des enjeux « Client » vue dans l’ensemble des interactions de l’entreprise, tout département interpellé, avec sa clientèle existante et potentielle.

Dans cette dernière optique, on perçoit aisément la complexité de gestion issue de la dynamique interdépartementale. En effet, chaque département ayant ses responsabilités et son rôle précis, il est naturel que les visions respectives de chaque département s’entrechoquent.

Voilà un constat de fond résumé par les participants quant aux difficultés qu’ils rencontrent dans leur projet CRM actuel: la complexité de consensus interdépartemental autour d’une façon de faire pour atteindre des objectifs donnés.

Le choix de l’outil

Les logiciels CRM pullulent et vous avez donc un vaste choix à votre disposition. Il n’est pas de l’objectif de ce billet de faire une analyse comparative des principaux produits sur le marché. Pour ceux que cela intéresse, vous pouvez consulter une liste de CRM connus au lien suivant « 2013 Compare Best CRM Software« . Bien sûr, demeurez prudents sur l’interprétation du classement. Je n’ai pas évalué la méthodologie ni validé la source en détail.

Au-delà des caractéristiques fonctionnelles usuelles, je vous suggère deux validations à faire en profondeur si vous envisagez d’évoluer progressivement vers une plate-forme XRM étendue. Votre logiciel CRM devrait posséder:

1. Une grande capacité de personnalisation de l’information en fonction de vos enjeux stratégiques. Vous devez être en mesure de concilier, d’analyser et d’exploiter rapidement l’information stratégique pour chaque département.

2. Une grande capacité de configuration des accès à l’information. Je ne parle pas ici de l’aspect sécurité qui doit évidemment être présent, mais plutôt de la capacité de votre outil technologique à moduler l’accès à l’information en fonction des besoins opérationnels de chaque département.

Autrement dit, si vous souhaitez optimiser le levier de votre implantation, faites en sorte que chaque département puisse accéder à l’information dont il a besoin, mais seulement l’information dont il a besoin. Sinon vous pourriez réduire le centre d’attention opérationnel de chaque département sans vous en apercevoir immédiatement.

La centralisation de l’information

Une majorité d’échec ou de succès mitigés d’implantation CRM proviennent de la difficulté à définir une référence d’information centralisée. Bien sûr, si vous optez pour une solution du type « Cloud« , inutile d’aller plus loin comme de facto vous opérez en mode centralisé.

Pour ceux qui vivent présentement ou envisageraient une solution locale, rappelez-vous qu’il devient impératif de créer une référence informationnelle centralisée. Vous devez éliminer le réflexe d’accès à une information locale (sur un poste de travail donné) pour toute information liée à un client, sinon votre projet de CRM est en péril dès ses premiers jours d’existence.

Aussi minimale que cette information puisse être au départ, par exemple simplement les coordonnées de communication du client, générer rapidement le réflexe d’adhésion à l’information centralisée est primordial.

Cette étape vous permettra, entre autres, de soulever et de vivre également toute la question de la standardisation de la codification de l’information client. Cette normalisation est cruciale pour stimuler l’appropriation de l’outil par les utilisateurs et pour générer du levier d’analyse et du levier décisionnel par la suite. Par conséquent, ne négligez pas les efforts de mobilisation de votre équipe sur l’enjeu de la centralisation de l’information s’il y a lieu.

La face cachée du succès

Que vous souhaitiez limiter votre projet CRM à votre équipe de vente uniquement ou que vous souhaitiez étendre l’utilisation de votre logiciel pour constituer une plate-forme XRM, toute la question de l’analyse des processus de gestion impliqués demeure un enjeu critique.

Comme pour tout autre projet de gestion informatisée, l’implantation d’une solution CRM-XRM est un moment privilégié pour améliorer l’efficacité de vos processus en place sans les dénaturer et perdre de vue les façons de faire qui ont créé votre succès. Dans cette optique, vous ne devez jamais oublier qu’une gestion de projet rigoureuse est toujours votre meilleur allié.

Maintenant, il y a un aspect additionnel que je souhaite amener à votre attention au niveau de la phase de déploiement et d’opérationnalisation de votre outil CRM-XRM.

Il y a, à la base de la notion des CSCW, quelques principes opérationnels fondamentaux qui doivent être respectés et appliqués pour garantir la génération du levier que vous recherchez. Malheureusement, ils sont souvent oubliés ou négligés.

Je vous réfère d’abord à la matrice « Temps-Espace » de Johansen (1988) qui constitue une référence théorique historique pour tous les logiciels de groupe (Groupware). Cette matrice présente les communications et les interactions dans une équipe de travail en fonction des combinaisons possibles de deux paramètres que sont l’espace et le temps.

Je ne vais pas plus loin dans le détail de la théorie opérationnelle sous-jacente. Pour le théoricien en vous, je suggère une publication complémentaire de 2007 endossée par Elsevier (http://www.elsevier.com/) et titrée « A Classification Method for CSCW Systems« .

Le principe structurant à saisir ici, c’est qu’un outil CRM-XRM agit comme un différentiel de gestion. Un peu comme le rôle que joue le différentiel sur votre voiture lorsque vous prenez une courbe et qu’il faut gérer la différence de rotation entre la roue intérieure et la roue extérieure.

En fait, la clé des CRM-XRM, c’est qu’ils gèrent les différences de disponibilités, de vitesse d’exécution, de processus, etc. auxquels font quotidiennement face les ressources d’une entreprise à travers leurs interrelations internes et externes. Tous les écarts, ou désynchronisations opérationnelles, à gérer étant toujours liés aux notions de temps et d’espace.

Pour arriver à activer la magie des CRM-XRM, j’attire maintenant votre attention sur la structure simplifiée d’une interrelation entre deux ressources:

Nous sommes toujours en présence d’un déclencheur (Trigger) qui fait une demande à un faiseur (Doer), un transmetteur qui garantit que la demande est transmise à la bonne personne au bon moment (votre outil CRM-XRM) et, finalement, le faiseur lui-même. Notez la boucle de rétroaction qui souligne la possibilité d’un processus itératif si nécessaire pour compléter la tâche à faire.

Voilà pour la mécanique à la base de la magie opérationnelle des CRM-XRM. Maintenant, voici les principes de base qui sont fréquemment oubliés, non connus ou négligés dans le cadre de l’utilisation de ces outils en fonction de chaque intervenant dans le processus:

Responsabilités du déclencheur

1. Il doit s’assurer que la demande est claire et précise sinon il augmente automatiquement le temps de traitement et le délai d’exécution, car le faiseur lui redemandera automatiquement des précisions sur l’action à poser. Une lacune très fréquente liée au fait que le demandeur a toujours l’impression que ce qu’il écrit, ou dicte, est parfaitement clair. C’est effectivement clair pour lui, mais ne l’est pas nécessairement toujours pour le faiseur.

On perçoit ici toute l’importance de l’établissement d’une norme de codification des demandes.

2. Expédier la demande au bon faiseur sous-entendant à la bonne ressource possédant les qualifications, les compétences et les responsabilités pour répondre à la demande. Sinon, cela va de soi que des délais de traitements seront introduits dans le processus d’exécution.

3. Il doit indiquer avec précision la priorité de traitement à accorder à sa demande. Rappelez-vous ici, quand tout est urgent, la possibilité de priorisation n’existe plus, il n’y a plus de gestion efficace des urgences. Le sous-entendu ici est de porter une attention particulière à la définition de ce qu’est une urgence comme prérequis.

Responsabilités du transmetteur

Le support de transmission et le différentiel de gestion comme tel. La fiabilité et la performance de l’outil technologique sont des paramètres critiques, car sinon la crédibilité du système est automatiquement attaquée.

Responsabilités du faiseur

1. Valider immédiatement qu’il représente l’intervenant nécessaire pour répondre la demande en termes de rôle et fonctions ainsi qu’en termes de compétences et de connaissances. On voit ici rapidement l’efficacité d’un CRM à détecter éventuellement les besoins de formation continue d’une équipe.

2. Prendre immédiatement une décision sur la demande à savoir si elle doit être satisfaite maintenant ou plus tard. Si l’action peut ou doit être reportée, il faut planifier immédiatement son suivi ou son exécution au calendrier de travail.

La plus grande lacune rencontrée dans le cadre de l’implantation d’outils CRM-XRM est l’absence de décision sur une demande. Pour qu’il y ait gestion effective d’une situation, il faut prendre une décision éclairée et comme une décision éclairée n’est pas le fruit du hasard, un processus d’analyse minimale doit donc s’opérer dans le traitement de toute demande.

Notez qu’il faut distinguer « prendre une décision » et « satisfaire la demande ». Il s’agit de deux choses complètement différentes. Une décision peut être à l’effet de ne rien faire pour le moment, mais dans ce cas, je répète, il faut planifier immédiatement la date de suivi ou d’action au calendrier.

L’erreur classique est donc de laisser en suspens des demandes sans qu’elles aient fait l’objet d’une analyse de gestion minimale. En plus de ne pas être dans l’action, vous accumulez des problèmes potentiels dans le futur.

Prenez quelques instants pour réfléchir à ce principe. Il s’agit de la clé de voûte pour générer un levier de base avec un CRM. Tout est se trouve uniquement dans ce principe.

Si chaque demande reçue ne fait pas l’objet d’une analyse minimale immédiate…vous ne gérez pas même si vous croyez le faire et que vous êtes très occupé!

Prenons maintenant le principe dans le sens inverse pour faire apparaître l’autre situation problématique classique. On s’en doute, si l’idée est de ne rien laisser en suspens, il s’agit de satisfaire toute demande immédiatement!

Et voilà qu’un mode de gestion réactive se trouve maintenant amplifié par un outil qu’on dédiait initialement à une gestion plus précise, plus efficace.

Sous l’hypothèse de fonctionnement à capacité opérationnelle finie, en mode de gestion réactive, le processus de décision éclairée est fortement affecté sinon n’existant.
Par exemple, on ne réfléchit plus à savoir qu’elle serait la demande nécessitant le traitement prioritaire face à deux demandes de priorité équivalente.

Aussi bizarre que cela puisse paraître, à vouloir tout faire immédiatement, une équipe de travail peut arriver à réduire son efficacité simplement parce qu’elle ne fait pas les bonnes choses au bon moment.

3. Au moment de satisfaire la demande, d’y répondre adéquatement, le faiseur doit s’assurer de documenter avec clarté et précision ses actions puisqu’il représente le dernier maillon du processus et, plus encore, s’il doit retourner le résumé de son intervention au déclencheur.

Le faiseur est donc face à la même responsabilité de documentation claire et précise que le déclencheur.

Notons que la clarté et la précision de la documentation autant du côté du déclencheur que du faiseur sont des valeurs sûres pour préparer les leviers futurs de votre outil CRM-XRM. Si vous le souhaitez, cette documentation peut devenir la pierre angulaire d’une éventuelle banque de connaissances corporatives. Cette dernière peut constituer ensuite les fondations de règles d’affaires supportant l’automatisation de processus.

Conclusion

Il est fort intéressant de constater que le domaine logiciel de gestion collaborative fait ressortir à nouveau des règles tel qu’un outil technologique ne peut corriger un mauvais processus de gestion, une mauvaise façon de faire. À ce titre, un CRM est un outil et non une solution.

D’ailleurs, dû au nombre habituellement plus grand d’utilisateurs, les logiciels collaboratifs amplifient davantage les lacunes de gestion que tout autre type de logiciel. Plus l’outil que vous choisirez sera performant, plus vous aurez rapidement le « feedback » de vos déficiences opérationnelles.

Mes recommandations à ce billet sont évidemment de nature très terrain. C’est malheureusement au niveau de principes de base qu’on retrouve les erreurs les plus fréquentes et, par conséquent, que les projets de CRM-XRM sont mis en péril avant même d’avoir pris leur élan.

Une fois ces principes de base bien maitrisés, vous pourrez aisément passer aux étapes suivantes, tel que le BI (Intelligence d’affaires), pour extraire du levier additionnel de votre plate-forme CRM et évoluer vers une plate-forme XRM.

N’hésitez pas à communiquer avec moi pour des questions plus spécifiques. Bonne gestion.

Les véritables enjeux de l’informatisation publique du dossier patient

Des délais d’attente qui semblent parfois irraisonnables. Un manque de médecins de famille. Pourtant, des millions de dollars investis pour exploiter les dernières avancées technologiques. Pour plusieurs, où sont passés nos impôts en absence de résultats clairs et probants?

C’est la situation avec le projet du DSQ pour lequel le contrôle de gestion semble avoir été complètement perdu. Après 308 millions de dollars, et bien, on se demande toujours ce qui s’est passé.

Bref, la question devient louable: où est le problème avec l’informatisation dans le secteur de la santé?

Techno, techno, encore techno!

Avec l’ensemble des possibilités technologiques actuelles, protocole d’interconnectivité reconnu comme HL7, architecture de système SOA, informatique en nuage (Cloud), virtualisation et j’en passe, comment se fait-il que nous avons un sentiment de piétiner sur place?

Notre coffre d’outils techno est suffisamment complet présentement pour convaincre les spécialistes du domaine que le salut est dans l’établissement d’une plate-forme technologique commune respectant évidemment tous les critères nécessaires de confidentialité relativement à l’information personnelle.

Je dois avouer que je suis de ceux qui croient que nous avons effectivement en main les possibilités technologiques pour concrétiser ce fameux dossier patient informatisé. Ceci à des coûts et avec des délais beaucoup plus raisonnables que ceux rendus publiques jusqu’à maintenant.

Donc j’en conclus que si la problématique se trouvait principalement au niveau technologique, elle serait probablement déjà résolue.

L’étendue du réseau de la santé et les divergences de technologies actuelles en place expliquent probablement une partie des enjeux technologiques.

La réalité nous rattrape toujours

Pour ceux qui me connaissent, je vois rarement dans la technologie la source de la vie éternelle et donc la panacée opérationnelle à des enjeux complexes d’accroissement de productivité. Je vous amène donc ailleurs, là où se trouvent les réels enjeux de l’informatisation du système de santé selon moi.

Je vous propose une réflexion bien simple issue de mon expérience du secteur de la santé et de l’informatisation de cliniques de soins.

Quel est le degré de liberté opérationnelle dont profite un professionnel de la santé pour gérer couramment sa clinique?

Au risque de vous surprendre, pratiquement aucun, sinon très peu. Pourquoi?

Simplement parce que lorsqu’un médecin, un dentiste, podiatre, quel que soit la spécialité, lorsqu’un professionnel de la santé arrête de traiter des patients, il interrompe également l’entrée de revenus dans sa clinique.

Vous en connaissez plusieurs chefs d’entreprise qui y lanceraient allègrement un matin « Allez, on arrête de faire des revenus aujourd’hui, ne vendez plus rien! ».

Oups…j’ai utilisé le mot « vente » dans un billet sur la santé…je me suis mis les pieds dans les plats!

Sérieusement, au-delà du tabou qu’on ne vend rien dans la santé, mais qu’on offre plutôt des services à des patients dans le besoin, sur le fond, demandez à n’importe lequel professionnel s’il s’applique volontairement et fréquemment des réductions de revenus.

Premier constat d’affaires lié à un enjeu opérationnel critique dans le domaine de la santé:

Si un professionnel de la santé ne peut arrêter de traiter des patients pour gérer, comment peut-il gérer efficacement l’informatisation de ses opérations?

Car informatiser sa gestion…ça nécessite beaucoup d’énergie pour mobiliser les troupes.

Autre réflexion sur l’environnement d’affaire d’un professionnel de la santé:

Avez-vous déjà pensé qu’un professionnel de la santé a étudié pour pratiquer, j’insiste sur « pratiquer », une discipline médicale qu’il aime?

Pour une majorité d’entreprises composant le tissu de notre économie, il est usuel que ceux et celles qui gèrent les ressources humaines, la comptabilité et les finances, les technologies et l’administration générale sont des gens qui ont étudiés dans ces domaines respectifs et qui ont délibérément choisi ces domaines. Des gens qui aiment et souhaitent travailler dans ces domaines.

Le professionnel de la santé n’a pas étudié et ne s’est pas perfectionné pour administrer, gérer des ressources humaines, faire de la comptabilité et toute autre tâche administrative connexe à la gestion d’une clinique. Il a étudié pour faire ce qu’il aime, soit traiter des patients dans sa discipline médicale.

Deuxième constat d’affaires :

Le professionnel de la santé n’aime pas particulièrement les aspects de gestion d’une clinique de soins, dont l’informatisation de ses opérations. Il s’agit d’un sujet qu’il cherche à éviter le plus possible et le délègue la plupart du temps vers du personnel administratif qui, d’autre part, ne représente pas et ne possède pas le pouvoir décisionnel final. Le professionnel demeurant, malgré lui, le patron ultime.

Alors, le tableau est brossé, il me semble assez clairement:

1. Sous des considérations financières (ou si vous aimez mieux par intérêt pour la santé publique), on ne peut demander à un professionnel de la santé de s’investir par réflexe naturel dans un projet d’informatisation stratégique.

2. Sous des considérations de goûts personnels, on ne peut demander à un professionnel de la santé de s’investir par réflexe naturel dans un projet d’informatisation stratégique.

Comme on dit: « Chassez le naturel et il revient au galop! »

Il devient alors évidemment très complexe de réussir un projet d’informatisation d’aussi grande envergure que celui du DSQ.

C’est bien beau, mais qu’est-ce qu’on fait maintenant?

Voilà pour la toile de fond, mais que pouvons-nous faire concrètement?

Sur la base des constats énoncés précédemment, voici des recommandations:

1. Un découpage extrême des étapes au niveau de la planification du projet.

Si cela semble simpliste pour un titulaire d’une certification PMP et bien, dites-vous que vous ne comprenez peut-être pas tout à fait le sens profond de ma suggestion.

Je ne parle pas d’un découpage usuel logique d’un projet dans le cadre de l’étape d’ingénierie de la planification. J’ai mentionné le mot « extrême » pour une raison bien sentie.

Je parle d’un découpage du projet qui semblera ridicule pour tout PMP mais qui permettra de faire des avancées systématiques, si petites soient telles en incrément, pour garantir l’arrivée éventuelle à la destination.

Autrement dit, compte tenu de la faible disponibilité naturelle (opérationnelle et psychologique) du professionnel de la santé qui constitue l’intervenant clé du processus, il faut développer un modèle de gestion de projet complètement différent des modèles usuels appliqués dans d’autres secteurs.

C’est la nature intrinsèque du secteur de la santé qui impose cette démarche.

La meilleure façon de mobiliser un professionnel de la santé naturellement dans un processus d’informatisation de cette envergure, c’est de faire en sorte qu’il soit dérangé le moins possible par le processus d’où la nécessiter de petits pas et de petits changements à la fois.

Mon approche s’inscrit dans l’essence des méthodes de développement agile avec une nuance de modèle « stage-gate » pour s’assurer que tout le monde est toujours dans le véhicule à des étapes clés.

Chaque étape (activité, livrable, etc.) devrait idéalement se traduire par une avancée fonctionnelle utile pour le professionnel même si elle ne génère pas une complète satisfaction. Je fais ici le lien avec ma prochaine recommandation.

2. Respecter les orientations, mais pas les ultimatums du milieu

Évidemment, le système final doit répondre aux besoins des professionnels de la santé, mais vous devez résister aux nombreux ultimatums qui vous seront servis au cours du processus d’informatisation.

À maintes reprises vous aurez le commentaire « Si ça ne fait pas ça, ça et ça, c’est inutile de nous implanter cette technologie à notre clinique » ou encore « Votre système est complètement inutile s’il ne fait pas ça au minimum ». Soyez-en averti et avisé dès le départ.

Mon commentaire est d’autant plus pertinent que je viens de vous recommander de procéder par étape de très petite envergure. Donc en principe, peu de ces étapes livreront de fonctionnalités nécessairement complètes aux yeux du professionnel, du moins au début du projet.

Pour revenir à mes constats de base, un professionnel de la santé n’a, de manière générale, pas de temps pour gérer, pas de compétences en informatique, pas de compétences en gestion de projet et, qui plus est, tous ces sujets ne l’intéressent pas vraiment.

Comment voulez-vous qu’il puisse avoir une vision globale et aiguisée du contexte, des enjeux et de la meilleure stratégie pour atteindre l’objectif?

Comprenez-moi bien ici. Je ne dis pas qu’un professionnel de la santé n’est pas en mesure de comprendre ce qui se passe. Je souligne simplement qu’il a, par nature, d’autres champs d’intérêt issus de ses choix et de son cheminement professionnels.

Il a besoin de vous comme gestionnaire chevronné de projet technologique pour concrétiser sa vision idéale de la gestion informatisée d’un dossier patient numérique complet.

Il faut donc récolter son « input » mais toujours avec l’objectif de valider l’orientation du projet et non d’en structurer les étapes et/ou d’en définir les moyens technologiques pour sa réalisation.

J’insiste sur cette recommandation comme j’ai trop vu souvent les spécialistes technologiques et de gestion de projets se faire imposer radicalement les façons de faire et abdiquer devant le client.

Vous devez maintenir le cap contre vents et marée en vous assurant constamment que tous les professionnels impliqués dans le comité de projet demeurent motivés en voyant le cheminement effectué et prévu. Ici, il s’agit d’un art. Assurez-vous que votre chef de projet est un fin communicateur.

3. Gérer la fameuse résistance aux changements

L’encre a coulé et n’a pas fini de couler sur le sujet. Dans votre stratégie d’implantation, ne négligez en aucun temps le phénomène de la résistance aux changements opérationnels.

Le phénomène est souvent à connotation négative, comme si l’intervenant ciblé, l’usager du système, était borné et fermé complètement. Ce qui n’est pas le cas dans une majorité des cas.

Il faut simplement comprendre que tout changement technologique entrainant des changements de méthodes de travail nécessite une période d’adaptation et de transition suffisante pour dénouer les noeuds psychologiques et ne pas créer, justement, des blocages.

La résistance aux changements est un paramètre d’autant plus important dans le secteur de la santé que chaque professionnel est convaincu que toute clinique qui oeuvre dans le même champ de spécialité que la sienne, opère automatiquement de la même façon que la sienne.

Ce qui est malheureusement faux bien que des similarités sur des concepts fondamentaux sont évidemment présentes. Par exemple, une majorité de cliniques gèrent un dossier patient qui contient habituellement un formulaire d’historique médical.

Les professionnels de la santé peuvent être vus comme des travailleurs autonomes dans plusieurs cas. Dans cet esprit, ils développent chacun des méthodes de travail personnelles.

Par conséquent, comme gestionnaire de projet vous aurez à vivre une diversité importante d’épisodes de résistance aux changements comme chacun sera convaincu d’avoir LA bonne méthode de travail à suivre.

En résumé, tant que le projet d’informatisation du dossier patient publique s’articulera autour d’une approche globale à trop grande étendue opérationnelle, il sera à mon avis impossible d’en voir la naissance concrète.

Le projet ne peut se réaliser qu’en mode « underground » par des étapes de fond progressives, par l’établissement de cellules fonctionnelles non interconnectées nécessairement au départ pour éventuellement être assemblées à la finale dans un système global.

Mais là, le projet devient moins intéressant sur le plan politique. Ça, c’est un autre sujet!

Bonne gestion!