A propos de


Digital Inside est un site dédié à la promotion, sensibilisation et accompagnement du digital interne au seins des petites, moyennes et grandes entreprises.

  • Facebook Social Icon
  • Twitter Social Icon
  • YouTube Social  Icon

Digitaliser des processus
avec le Digital interne 

Les opportunités "métier" du digital interne est encore très souvent ignorée par les entreprises, grandes et petites. Les outils d'Office 365, SharePoint en particulier, sont pourtant de forts leviers pour apporter des solutions métier rapides et économiques, très disruptives par rapport aux réponses des classiques projets informatiques. 

J'avais décrit dans cette interview d'Olivier BELMAun cas d'usage fameux qui restera la plus belle démonstration de la puissance de SharePoint pour répondre à une problématique métier en quelques heures. 

La digitalisation d'un métier

Vous avez des questions ou besoin de conseils ?

contactez-moi  |  qui suis-je ?   |   société Abalon

A l'origine un simple besoin d'échange...


Quel que soit le sujet, quel que soit le métier, quel que soit le domaine, toutes les équipes qui travaillent ensemble ont besoin d'échanger des informations entre  elles. C'est le cas par exemple entre une équipe qui identifie des actions à réaliser, et une autre équipe qui doit les réaliser.

Généralement, la solution de facilité (apparente), c'est de laisser les équipes échanger par mail. C'est apparemment facile, car il n'y a rien à faire, aucun dispositif à mettre en place, aucun outil à concevoir et à mettre en œuvre.

Mais cette façon de procéder est anarchique et présente de nombreux désavantages :

 

  • Les mails sont souvent (presque toujours dans certains cas) incomplets car non structurés : il manque des informations pour que la demande soit correctement traitée, ce qui génère d'autres mails pour demander des compléments d'information, avec de l'agacement en parallèle
     

  • Les demandeurs n'ont pas de vue sur le statut de la demande : est-ce qu'elle est bien reçue, est-ce qu'elle est en cours de traitement ? Pour être informé, les demandeurs envoient d'autres mails…
     

  • Les personnes qui traitent les demandes n'ont pas une vue très claire de ce qu'ils ont à traiter : les demandes sont empilées au mieux dans une boite mails génériques. Au pire, ces mails de demande s'empilent dans leur propre boîte mails déjà surchargée par d'autres messages
     

  • Il n'y a aucune statistiques ou indicateurs sur le nombre de demandes, leurs types, etc. J'ai connu un cas dans une équipe ou une personne consacrait une journée entière par semaine juste pour analyser le contenu d'une boîte mails afin de faire des comptes dans un fichier excel pour donner des indicateurs au manager
     

  • Enfin, ce fonctionnement par mails interposées a pour conséquence d'envenimer les relations entre les équipes. Le manque de visibilité sur le statut des demandes, les échanges (agacés) pour compléter les informations manquantes… tous ces mails plus ou moins cordiaux alimentent un climat de défiance entre les équipes

Il faut donc penser à autre chose pour canaliser les échanges, mais de manière simple, rapide et économique.
 

La solution SharePoint pour huiler les processus


Dans la plupart des cas, mettre en place un groupe Yammer (ou une équipe TEAMS), c’est-à-dire mettre en place un mur d'échange entre les deux parties, est une fausse bonne idée.

 

Communiquer par un groupe dans un Réseau Social d'Entreprise ne permet pas plus de structurer les échanges, ni d'apporter une vue claire sur les statuts des demandes en cours, et encore moins d'apporter des indicateurs sur la nature des demandes. 

L'idée pour solutionner ce cas métier, c'est de poser entre les deux équipes un espace digital (un site SharePoint) pour canaliser les demandes, en offrant aux deux parties une plus-value réelle :

 

  • aux "demandeurs", vous offrez un tableau de bord de leurs demandes,

  • et aux "opérateurs" qui réalisent la demande, vous leur donnez un tableau de bord des demandes à traiter.

Pour comprendre comment SharePoint peut solutionner ces cas de "besoin péri métier", il faut oublier l'usage "classique" que l'on connait habituellement de SharePoint (uniquement documentaire), et se pencher sur les autres fonctionnalités que l'outil propose, comme par exemple la possibilité de créer des "listes structurées de données".

Définir une liste structurée de donnée, c'est ni plus ni moins, finalement, que de décrire une table de base de données pour ceux qui connaissent les bases de données classiques.

 

Vous allez décrire dans SharePoint la liste des "propriétés" nécessaires pour décrire une demande d'action : un titre, une description, une date butoir, un degré de criticité, un statut, etc.

 

Pour ajouter un élément dans cette liste, SharePoint affiche un formulaire tout fait, qui en l'état, sans aucune modification, vous permet de répondre à pas mal de cas d'usage. Des solutions vous permettront de personnaliser le formulaire, d'intégrer des règles de saisie par exemple. Mais un conseil : restez simple.

 

SharePoint propose également des "affichages" : c’est-à-dire des requêtes sur les données que vous avez saisies, en spécifiant la forme (les champs à afficher), le tri, le filtrage des données.

Ensuite, vous pouvez construire vos pages SharePoint pour intégrer l'ensemble : les affichages vers les demandes formulées, un bouton pour accéder au formulaire de demande, et toutes les informations utiles que vous voulez associer à la demande.

Pour que cela fonctionne, il faut accepter la simplicité


Lorsque j'ai commencé à digitaliser des équipes par ce moyen, c'était en 2006. A cette époque, je m'étais dit qu'il y allait avoir une ruée des entreprises sur ces solutions, dès qu'elles seraient connues. Mais près de 12 ans plus tard, je constate que cette ruée n'a pas eu lieu.

 

Quand j'en parle aux équipes lors de mes interventions, elles sont tout autant surprises qu'à l'époque. C'est que, pour que ces usages émergent, il faut d'abord les connaître (c'est l'objet de ce billet), et il faut surtout que l'entreprise accepte la simplicité. Et là, rien n'est gagné. J'ai des anecdotes fameuses sur ces sujets.

Ca peut être la direction informatique qui bloque. Ces dispositifs sont souvent qualifiées de shadow IT (des applications informatiques développées sans le concours des informaticiens de la DSI) et ça, les DSI détestent. Les DSI veulent maîtriser les applications informatiques : elles veulent documenter chaque usage avec l'utopique volonté de pouvoir intervenir en maintenance à tout moment et à tout instant sur toute fonctionnalité informatique de l'entreprise, en sortant un épais dossier de conception qui bien souvent n'est jamais relu une fois qu'il a été écrit.

 

Chaque nouvelle "application métier" doit suivre un processus bien précis, entrer dans un circuit de validation, d'étude, de conception, de développement, de recette, de mise en production, de contrat de maintenance évolutive Ces solutions  métier pourtant pérennes mais réalisées en un ou deux jours, n'entrent dans aucune case. 

Ca peut être les utilisateurs qui complexifient : le cas classique, c'est l'équipe qui part de rien. Aucun outil, aucune procédure, aucun cadre informatique autour de leur activité, RIEN. Uniquement des échanges anarchiques par mail.

 

Lorsque vous proposez une solution qui solutionne 80 à 90% de leurs besoins, bien souvent, vos utilisateurs bloquent le projet pour les 10% restant. Je ne compte plus les équipes qui sont restées avec leur messagerie parce que le design général n'était pas à leur goût et qu'ils refusaient que tout ne soit pas parfait.

Ca peut être aussi des managers qui bloquent. Un jour un directeur a refusé une solution de ce type parce qu'elle lui semblait peu fiable, parce que réalisée en moins de deux jours. Mais mon dispositif (opérationnel immédiatement) l'avait inspiré et avait servi  de "cahier des charges".

 

Quelques semaines plus tard, il engageait un projet de développement spécifique pour plus de 70 keuros pour reproduire exactement le même fonctionnel, mais en moins riche (pas de notification, etc) et avec de gros problèmes à la clé (bugs, maintenance, …). N'oubliez pas le vieil adage : "ce qui est précieux est cher". Donc dans beaucoup d'esprit, ce qui ne coûte pas cher ne vaut rien.
 

En conclusion


Ce billet s'est contenté de donner un exemple reposant sur un usage de SharePoint seul, sans autre outil. La suite Office 365 propose aujourd'hui des solutions plus poussées encore pour outiller des processus métier, comme FLOW, POWERAPP ou POWERBI, que je n'ai pas abordé dans ce billet. 
 

Encore faut-il savoir aborder de tels projets sous le bon angle : 

 

  • savoir détecter les cas d'usage les plus pertinents (et réalistes),  

  • savoir définir la meilleure solution à mettre en œuvre, rapidement et à peu de frais, 

  • savoir accompagner les équipes pour modifier leur mode de collaboration en intégrant ces outils dans leur quotidien

  • au niveau de la DSI, accepter les solutions alternatives quick win, accepter de déroger aux règles immuables de la DSI (comités d'engagement, cycle de vie traditionnel des projets, …) et savoir être agiles (je ne parle pas de Scrum, qui est une méthode académique trop lourde encore pour ce genre de solutions rapides)

  • au niveau des métiers, accepter la simplicité, accepter de prendre un risque en faisant des essais
     

Tout ça c'est un vrai métier. Si ce billet vous a inspiré l'idée de lancer une campagne massive de digitalisation de processus en mode quick win ou tout simplement de lancer un pilote avec une équipe pour en tester les bénéfices, contactez-moi !

Besoin d'accompagnement ?

Cette rubrique vous a peut-être inspiré un cas d'usage concret pour votre entreprise ? Si vous souhaitez que nous en discutions, la société ABALON et moi même sont à votre disposition pour analyser votre contexte métier, vous conseiller, et vous accompagner de la conception à la réalisation.