Archives du mot-clé agile

Le Case Management pour adresser la complexité de l’entreprise digitale

L’entreprise digitale et le risque de complexification du Système d’Information

La transformation digitale de l’entreprise se traduit par l’irruption de technologies numériques dans l’environnement de travail, ouvrant de nouvelles possibilités de collaboration entre les participants internes et externes à un même processus. Aujourd’hui, chacun interagit avec un fournisseur, un prestataire de service, un collègue, une administration via différents moyens de contacts – courrier électronique, formulaire web, discussion instantanée, application mobile – selon ses préférences, ses habitudes, son équipement, et selon le moment choisi pour l’interaction (il peut même les combiner pour une expérience utilisateur optimisée).

Mais l’adoption de médias modernes de communication, web ou mobile, ne suffit pas à répondre aux défis de la révolution numérique. Il faut aussi que les processus prennent en compte la diversité des modes d’interaction, et que les organisations et modes de fonctionnement s’adaptent aux besoins de plus en plus personnels et changeants des clients.

Ce phénomène n’est pas le monopole de secteurs comme le commerce, la banque ou les services, déjà préparés depuis longtemps au web, à la dématérialisation des actes de gestion, et aux objets connectés (vente en ligne, billet de train électronique, badge de télépéage d’autoroute, carte ticket-restaurant…). Le secteur industriel est aussi largement touché : dématérialisation des remises d’ouvrages sur les chantiers, automatisation des entrées et sorties de stock en entrepôt, etc.

La transformation digitale n’est donc pas uniquement une question d’adoption de nouvelles technologies. Elle apporte son lot de changements faisant apparaître de nouvelles opportunités ou exigences dans la façon de s’échanger et traiter l’information, de collaborer ou partager le travail.
Ces changements entraînent une complexification de l’activité de l’entreprise et de son pilotage. Là où hier les choses étaient claires et bien rodées, sur qui fait quoi à quel moment et avec quel résultat, la transformation digitale apporte, au travers de la contraction du temps et de l’espace, au travers de la dématérialisation toujours plus poussée et de l’adaptation permanente des modes opératoires, un sentiment de complexité qui s’accompagne d’un risque de confusion voire de perte de contrôle.

La nécessaire collaboration entre applications et entre acteurs

Face à cette complexité, le SI doit réussir à combiner des applications variées et à impliquer des acteurs différents. On a besoin d’intégrer des flux de travail (courrier, formulaire web, message électronique), d’accéder à des ressources documentaires, d’affecter l’activité à des collaborateurs en fonction de l’organisation, des compétences et des disponibilités, de tenir compte des règles métiers portées par les applications de gestion, le tout, en suivant des modes opératoires qui deviennent nativement instables.

Ce n’est pas un outil pour automatiser leur processus que les métiers réclament. Ils savent très bien gérer leur affaire sans devoir entrer dans un outil structurant, voire contraignant ; et la variabilité des manières de dérouler leur processus est trop importante ; sans compter l’indispensable réactivité qu’ils veulent conserver pour répondre aux exigences de leur marché.

Lorsqu’une situation exceptionnelle ou non prévue se présente, les acteurs veulent prendre la main et ajuster le déroulement de leur processus, par exemple en missionnant un acteur d’une nouvelle tâche, ou en court-circuitant certaines étapes. Dès qu’on se trouve avec un nombre élevé de scénarios alternatifs, l’approche strictement BPM est impuissante, la complexité d’implantation devient trop importante, et, pire, la réactivité pour adapter la solution devient insupportable.

En fait, c’est de collaboration dont on a besoin, entre les participants au processus, bien sûr, mais aussi entre les applications : les « legacy systems » qui assurent l’ossature du socle de gestion des entreprise, les applications métier, plus récentes, plus spécialisées, et parfois plus exotiques sur le plan fonctionnel ou technique (espaces clients, outils spécialisés pour les échanges B2B, open services, etc.).

On parle bien de collaboration : il ne s’agit pas seulement de s’échanger des données entre applications, mais de « travailler ensemble » avec intelligence. Ce besoin de collaboration est difficile à satisfaire car il va parfois au-delà du simple besoin d’orchestration : les règles de gestion sont mouvantes, les situations métiers sont multiples et parfois non déterministes. D’ailleurs la plupart des applications métier historiques (legacy), un peu rigides, ne sont pas, par nature, ouvertes aux exigences d’agilité d’un paradigme digital. Ceux qui ont travaillé avec un ERP savent de quoi nous parlons.

Le Case Management, agent de simplification

Le Case Management, comme nous l’avons vu dans un précédent article se positionne comme un nouveau type de solution pour les domaines métier où l’activité s’avère difficilement prévisible et nécessite d’adapter le processus nominal à pratiquement chaque situation qui se présente.

Tous les déçus ou sceptiques des solutions classiques / traditionnelles de GED ou de BPM trouvent dans le Case Management une alternative crédible pour outiller leur gestion d’affaire ou de dossier, ni totalement documentaire, ni purement déterministe, dédiée au partage d’information et à la collaboration, en permettant le suivi et le pilotage. Un outil nouveau, pas si révolutionnaire que ça, qui ressemble à un réseau social et qui permet de travailler à un résultat / une œuvre collective avec un minimum de cadre procédural et organisationnel.

Plutôt que d’apporter une réponse sophistiquée à un besoin qui se présente comme complexe, on essaie de simplifier le besoin. En fait, pour un domaine d’activité qui s’avère complexe du point de vue des processus, peut-être l’approche processus n’est-elle pas la bonne manière de l’appréhender. Si la gestion d’un dossier ou d’une affaire apparaît difficile à traiter par l’approche processus, alors essayons l’approche objet, centrée sur le « case » (l’affaire, le dossier…).

Là où le Case Management devient un agent de simplification, c’est dans ses capacités à faire fonctionner un réseau d’acteurs. En effet, lors du déroulement d’un processus impliquant plusieurs acteurs utilisant chacun un outil dédié à sa fonction (le client sur son espace web, le commercial dans son CRM, l’intervenant dans son outil de gestion de chantier, etc.) le Case Management va savoir qui fait quoi et pourquoi, positionnant ainsi chaque contribution dans le contexte global de l’entreprise digitalisée.

Pour ce faire, le Case Management dispose de plusieurs atouts. A titre d’illustration nous proposons de voir comment un outil de Case management peut gérer des acteurs et des rôles pour pouvoir donner un sens aux contributions des uns et des autres.

Dans cet exemple, le Case Management identifie les applications comme des rôles. Il va pouvoir gérer des « corbeilles d’application » qui représentent chacune un outil utilisé par des acteurs. Ainsi, l’espace client ou le portail prestataires deviennent, pour le Case Management, des corbeilles où il pourra déposer une tâche à faire ou recevoir un résultat. Un acteur pourra, lui aussi, être représenté par une corbeille, si le Case Management a besoin de savoir précisément quel acteur fait l’action. Dans ce cas, le Case Management va gérer une relation entre acteur et rôle(s).

On voit ici que le Case Management est en situation d’orchestrer les contributions des uns et des autres, le tout étant supervisé par un agent orchestrateur, par exemple une personne chargée de suivre l’activité de bout en bout. A noter que les acteurs du processus n’ont pas, dans ce schéma, besoin d’avoir la vision complète du processus. Mais rien n’empêche de leur fournir cette visibilité.

Case management

Une forme de « Lean management »

La réponse au risque de complexification du SI de l’entreprise digitale n’est donc pas la mise en place et l’outillage de processus sophistiqués (cela ne ferait que rajouter de la complexité, au prétexte de la maîtriser). L’alternative Case Management propose au contraire de se concentrer sur l’information (le « case ») et l’humain (les participants au traitement du « case ») pour offrir un espace de liberté au déroulement des processus et permettre, dans un monde en perpétuel mouvement, de réagir et d’adapter les modes opératoires (et donc le fonctionnement de l’entreprise).

Il s’agit d’une approche « allégée » (lean) pour gérer des situations complexes, en ce contentant d’une structure de processus juste nécessaire au pilotage de l’activité (une forme de frugalité). Le Case Management ne doit pas être perçu comme une hyper-sophistication informatique, qui ne fait qu’ajouter à l’enchevêtrement dans la gestion des flux d’information. Il doit rendre l’existant plus utile et plus pratique. Le leitmotiv c’est que l’introduction d’une brique de Case Management ne doit pas donner l’impression d’augmenter la complexité du Système d’Information.

Auteurs : Joseph PAUMIER et Christophe ROUXEL

Data Agilité : Comment le big data devient agile !

En 2001, les initiatives historiques autour de l’agilité se fédèrent avec le Manifeste Agile, qui couvre désormais toutes les activités d’une organisation. L’agilité est devenue un mot clé plus seulement limité au périmètre des projets. C’est la solution idéale vers laquelle toute organisation s’oriente pour répondre aux enjeux et contextes à venir.

Parallèlement, l’apparition ces dernières années des big data et surtout la prise de conscience de leur potentiel a poussé les géants de l’informatique à mettre en œuvre des architectures de stockage assez complexes, massivement distribuées, capables d’engloutir des données toujours plus nombreuses et variées. Les entreprises traditionnelles de leur côté, se retrouvent devant une jungle d’outils estampillés big data, avec des problématiques qui leurs sont propres, mais sans aucune promesse de connaître un jour le succès des GAFAS et autres NATU (Netflix, Airbnb, Tesla, et Uber).

Dans un tel contexte, il devient crucial de savoir concilier deux besoins : d’une part, celui de disposer d’une architecture de données (moyens – technologies – logiciels – infrastructure, contenus, politique) robuste et, d’autre part, celui de répondre rapidement (le « juste à temps ») et de façon agile à des besoins métier (use case). Cet article propose une définition de la Data Agilité.

La Data Agilité, c’est répondre aux enjeux du Big Data, proposer une architecture robuste, c’est-à-dire vérifiant un ensemble de qualités telles que performance, sécurité, lisibilité, traçabilité et résilience. Pourtant, dans la réalité, la construction d’une telle infrastructure échappe souvent à la vigilance des entreprises. Certaines s’engouffrent dans une phase architecturale longue, quasi bureaucratique, au délai non adapté et aux lacunes variées. D’autres, au travers de projets dits novateurs, se retrouvent avec des architectures non pérennes se transformant en goulot d’étranglement, et au final le ROI n’est plus assuré.

Pire, une fois l’architecture aboutie, celle-ci devient non conciliante, car à la recherche de la norme absolue de représentation des données, niant ainsi la richesse des différents points de vue et des différentes maturités à considérer sur les données. Son contenu accuse alors un retard continu dans la prise en compte des évolutions, intrinsèques au contexte de toute entreprise. Finalement, la construction d’une telle architecture accumule les reproches que l’on retrouve dans des projets plus classiques de type datawarehouse d’entreprise.

Le projet est fragilisé : il s’appuie sur des données non maîtrisées, qui dégradent les fonctions visées. A terme, l’architecture finit par reconstituer des silos de données et aboutit à un stockage « dépotoir » avec le retour des problématiques de cohérence / écarts du fait de l’utilisation de données « non fiables  » ou non contrôlées.

Un récent sondage réalisé par le CRIP autour du Big Data annonce que 50% des CTO français estiment que l’un des principaux freins aux projets Big Data est l’insuffisance de compétences au sein des DSI. Pourtant, les compétences ne sont pas les seules à entrer en jeu : l’un des freins majeurs, selon nous, est le manque d’alignement entre la démarche agile et l’architecture de données sous-jacente aux projets Big data.

Premier point, la Data Agilité pose les briques essentielles d’un projet à succès car elle répond à une logique de capacités et non à un besoin précis : alimentation de données, représentations des données, fonctions d’exploitation de ces données, contrôle et gouvernance des données… Plus précisément, on cherche à mettre à disposition une architecture ayant la capacité à répondre à N besoins que l’on ne connait pas à l’avance. L’architecture est un cadre structuré facteur d’accélération, de préservation et de capitalisation des travaux antérieurs sur les données.

Deuxième point, cette capacité couverte par l’architecture de données relève d’une construction incrémentale alignée avec les projets. Cette démarche itérative sur le plan de l’architecture doit rejoindre celle que l’on retrouve dans un projet data science :

Data Agilité : Démarche de Data Science

  • Mise en place du socle – construction de l’architecture de données : cette première étape vise à initier la structure data agile en esquissant une vision macroscopique de la partie modélisation des données (à l’aide d’un modèle d’objet métier par exemple) et en chargeant les premiers jeux de données bruts sur une infrastructure de base. On privilégiera lors de cette étape des outils de stockage « ouvert » ou des solutions de data virtualisation, les scénarios variant bien sûr selon l’existant IT.
  • Itération X – «  réponses » agiles au use case data : la seconde phase vise quant à elle à développer l’architecture initiale selon les uses case data que l’on souhaitera aborder. La modélisation du macro-modèle pourra être détaillée, de nouvelles briques d’architecture ajoutées ou étendues…

Troisième point, l’architecture doit également accorder une autonomie vitale aux nouveaux acteurs et organisations data (CDO, data scientist, datalab, data manager…) en apportant d’une part le « juste à temps » grâce à sa rapidité de mise en œuvre et d’exploitation immédiate et, d’autre part une structuration / représentation des données à l’usage et non a priori. Le data shadow IT (excel, mail d’échanges de données…) coté métier est de son côté réintégré dans l’architecture et encadré par l’autonomie apportée. Enfin, l’intégration de nouveaux composants dès le premier incrément, renforce cet esprit d’agilité, de « juste à temps » et d’autonomie. On distinguera notamment une chaîne de composants support aux démarches agiles :

  • Les « ETL visuels » : venant compléter les ETL classiques (Extract-Transform-Load) dont la fonction initiale est l’extraction (avec des connecteurs par sources de données), la transformation de données (filtre, enrichissement, fusion, jointure de données) et la création / alimentation d’une nouvelle source (un dataset). La nouveauté de ces outils est la « programmation » visuelle et dynamique qu’ils apportent à ces différentes étapes ainsi que leur facilité à combiner différentes sources (de la simple jointure à la mise en œuvre d’algorithme avancé de matching), en plus d’intégrer des fonctions avancées de calcul ou de pré-traitement/préparation des données.
  • Les bacs à sable : qui constituent une solution de stockage « libre », dans un espace dédié, sans perturbation des stockages dits industriels. Plus généralement, un bac à sable est conçu comme un environnement non opérationnel où les analystes et les scientifiques de la donnée peuvent tester des idées, manipuler les données et le modèle sans imposer une charge de calcul excessive sur les processus opérationnels de base. Il a une espérance de vie limitée et les découvertes associées sont soit incorporées dans l’entrepôt de l’entreprise soit abandonnées.
  • Les stockages de type NoSQL, Hadoop… libérant des contraintes de structuration a priori, par leur implémentation de modèles à la volée. Leur vocation est de répondre à la problématique de stockage des données en étant non-relationnelle, distribuée (réplication élévée), open-source et horizontalement évolutives.
  • Le « self BI », les fonctions de data discovery : c’est-à-dire la capacité de construire une couche d’abstraction sur des données sources de façon dynamique, à l’aide notamment de fonctions de navigation dans les données. Cette approche libre-service permet aux utilisateurs finaux de créer des rapports personnalisés et des requêtes analytiques dans un cadre structuré permettant de concilier industrialisation et expérimentation.

Quatrième et dernier point, n’oublions par enfin que la Data agilité c’est également la reprise de méthodes de travail agiles, dont la pertinence n’est plus à démontrer. On retiendra notamment la possibilité qu’elles offrent en terme de maturation métier au fur et à mesure de la progression du projet, mais aussi la prise en compte des évolutions, naturelles au contexte des projets data.

Alliée au phénomène data, la Data Agilité propose un cadre de travail robuste qui convaincra tous les acteurs de la donnée.

Auteurs : Joël BIZINGRE et Elkhader FATNI

Observatoire CONIX de la Donnée