Articles

Si le Business Process Management est avant tout une démarche, il nécessite des moyens technologiques pour modéliser les processus métiers et les mettre en oeuvre au sein de toute l’entreprise.

Quels sont les critères pour choisir sa solution BPM ?

Les impératifs

Atelier de design de workflow ergonomique

Modéliser simplement les processus, réaliser intuitivement des écrans et des formulaires (WYSIWYG)

Adhérence avec le Système d’Information

Consolider l’information au sein du SI, échanger facilement les données avec l’ensemble des applications et des référentiels

Supervision des flux et des traitements

Disposer de tableaux de bord, tracer toutes les actions, délais et incidents, archiver les processus terminés

Norme BPMN 2.0

Disposer d’un cadre commun de représentation des processus métier afin de partager une même vision au sein de l’organisation

Fonctions standards

Automatiser les alertes, le routage conditionnel des flux, la délégation, les délais d’exécution des activités, relancer les flux en anomalie, contrôler et vérifier les données saisies

Évolutivité

Bénéficier d’une souplesse de paramétrage pour s’adapter au fur et à mesure de ma transformation des processus métier, versionner les processus

Les plus

Nativement Responsive Design

Assurer la mobilité dans la réalisation des tâches aussi bien vis-à-vis de la visualisation que de la saisie

Fonctionnalités de confort et de collaboration

Pouvoir demander des informations complémentaires, enregistrer un brouillon, partager des commentaires…

Editique des informations

Exporter et importer des diagrammes, éditer les informations sous les formats souhaités (Excel, PDF, Word, …)

Processus augmentés

Disposer d’une aide à la saisie, d’enrichissements automatiques, de corrélations, d’une automatisation avancée avec le RPA…

Ouverture vers l’extérieur

Récupérer des informations Open Data, ofrir une ouverture sécurisée aux partenaires, fournisseurs, clients…

Outils de simulation

Simuler et tester l’exécution des processus les impacts des modifications

Portail collaboratif de suivi pour chaque intervenant

Offrir à chacun une visibilité sur les tâches qu’il doit réaliser ou qu’il a initiées ainsi que sur les KPI

Comment mettre cela en place dans mon SI ?

Modéliser le workflow ne suffit pas !

La solution BPM au croisement de 4 enjeux de gouvernance du SI :

1. Gouvernance des Processus (BPM)
pour modéliser et intégrer l’humain au sein des process

2. Gouvernance des données (MDM)
pour harmoniser et faire vivre les données en lien avec le BPM

3. Gouvernance des l’ouverture (API Management)
pour industrialiser et fiabiliser les échanges avec l’extérieur

4. Gouvernance des flux (ESB)
pour transporter les données et contrôler les flux

Vous avez un projet de BPM ou des questions à ce sujet ? Échangez avec l’un de nos experts!

Au plaisir d’échanger avec vous

API Management et portail API : atouts et limites

La transformation des entreprises repose de plus en plus sur le développement des chaînes de valeur avec l’écosystème. Dans ce contexte, on parle de plus en plus des API (Application Programming Interface) et de leur rôle pour permettre aux applications d’interagir ensemble sous des conditions déterminées et documentées.

La gouvernance des API : une évidence face à la multiplication des échanges avec les partenaires

La gouvernance des API au travers d’une solution d’API Management prend toute sa place dès que les partenaires et les API se multiplient et qu’il faut gérer les éléments de mise en œuvre associés :  le contrat d’interfaçage, l’explication, la documentation à fournir… c’est-à-dire lorsque l’organisation rencontre des freins à l’industrialisation des échanges avec son écosystème. Les risques sont alors de ralentir le déploiement des services et l’accompagnement de ses partenaires.

L’API Management a vocation à apporter une réponse à ces enjeux de scalabilité et de répétabilité. Ainsi, une solution d’API Management permettra de gouverner les API, au travers de la gestion de la publication, de la promotion et de la supervision des échanges de données entre le service fournisseur et le service client. Tout cela au sein d’un environnement sécurisé et évolutif.

Plus précisément, les enjeux d’une plateforme d’API Management sont de :

  • Normaliser la publication d’API
  • Administrer l’exposition et la consommation. C’est-à-dire maîtriser ce qui est diffusé !
  • Gérer le cycle de vie complet de vos API (initialisation, versioning, retrait…)
  • Centraliser la diffusion d’API internes comme externes
  • Piloter la consommation
  • Documenter automatiquement les APIs
  • Fournir un espace pour les développeurs avec un bac à sable
  • Monétiser la consommation de vos API

L’API Management ou la gouvernance des API doit donc répondre à certaines promesses :

Souplesse de l’API Management

Renforcer la souplesse dans la composition des offres

l’API Management pour de nouveaux services

Concevoir de nouveaux leviers de croissance au travers de nouveaux services

Intégrer des API tiers

Améliorer la valeur métier en enrichissant ses propres services avec des API tiers

Expérience client grâce à l’APIM

Contribuer à une meilleure expérience client et à l’omnicanalité des services proposés (mobile, web, IoT…)

La scalabilité de l’APIM

Assurer la scalabilité face à l’accroissement des services à proposer, des nouveaux partenaires, et de la consommation

Focus : qu’est-ce qu’un portail API ou API Gateway ?

L’API Gateway ou portail API sont des composants des solutions d’API Management.

Dans le cadre des solutions d’API Management, exposer une architecture de type Gateway vers l’extérieur assure de contrôler ce qui vient de l’extérieur et ce qui est interne. Il s’agit de concentrer les entrées et les sorties en un seul point afin de sécuriser et maîtriser l’utilisation et les accès associés. La brique Gateway va offrir toutes fonctions liées au transcodage, à l’exposition et à l’optimisation des communications. Elle doit aussi répondre aux enjeux de scalabilité.

Si on parle plus largement du concept de « portail », en prenant l’exemple de Blueway, il en existe plusieurs types au sein des solutions d’API Management :

  • Un portail dédié pour les abonnés : les organisations consommatrices peuvent voir via un portail dédié à quelles API vous les avez abonnées et accéder à leurs statistiques de consommation. Des tokens d’accès sécurisent l’ensemble des authentifications.
  • Un portail centralisé et dédié au monitoring de votre parc API : il vous permet de gérer toutes vos API grâce à une vue globale et exhaustive, de les faire évoluer et de configurer leurs expositions. Vous surveillez la consommation et la santé technique de vos API en retrouvant tous les logs et toutes les statistiques de consommation de vos API. Vous gérez les abonnements de vos clients, fournisseurs ou partenaires à vos API durant la période et selon les conditions de votre choix.
  • Un portail pour les développeurs : toute la documentation de vos API, leur structuration et les outils mis à disposition permettront aux développeurs de procéder à des tests en toute autonomie.
API Gateway et portail API

Créer les API et gérer les API : deux enjeux complémentaires à distinguer

Si les solutions d’API Management sont essentielles pour gouverner les échanges avec vos partenaires, il faut bien en identifier les limites. Une solution d’API Management n’est pas faite pour créer des API mais pour piloter leur exposition ! Les API doivent être créées en amont.

La solution d’API Management expose ainsi des services qui existent déjà au sein du système d’information. Elle n’a pas non plus pour objectif de structurer ou d’urbaniser votre SI interne.

Ainsi, mettre en place une solution d’API Management ne suffit pas pour répondre à l’enjeu d’APIser votre Système d’Information. Avant d’avancer sur le choix d’une solution d’API Management, vous devez prendre du recul sur de nombreuses questions : quels services avez-vous besoins d’exposer ? Pour quels besoins métiers ? Quel est le niveau de granularité attendu ? Quelle est la maturité de votre écosystème ? Quels KPIs souhaiterez-vous suivre ?

A l’inverse, il faut aussi garder en tête qu’exposer un service juste car il est disponible ne présente pas d’intérêt ! C’est votre besoin qui doit cadrer votre stratégie d’intégration et d’APIsation.

C’est donc une fois que les premières API seront définies et disponibles au sein de votre système d’information qu’une solution d’API Management prendra tout son sens. Pour autant il n’est pas nécessaire d’avoir mis en place dès le départ toutes les API : la démarche peut très bien être itérative ! Mieux vaut éviter l’effet Big Bang.

ESB et API Management :
deux réponses complémentaires pour soutenir votre transformation business

Comment alors créer des API à exposer ?

Il est possible de développer ses API avec du code et des frameworks de développement propres. Cependant, l’API Management gagne vraiment à s’appuyer sur des solutions d’urbanisation du SI et une architecture orientée services (SOA).

Dans l’un ou l’autre cas, isoler les API déjà présentes dans le SI interne et bien définir ce qui vient de l’extérieur et ce qui est interne est une étape importante avec d’exposer une architecture de type gateway.

Cette vision rejoint des convictions que nous partageons chez Blueway. La réponse ne doit pas être uniquement technique : la technologie reste un support, pas une réponse en soi.

Pour ne pas forcer la réponse à rentrer dans le périmètre technique d’un outil, il est nécessaire d’avoir une vision globale des échanges d’information : processus, référentiels de données, transport de l’information et ouverture vers l’extérieur.

Dans le cas présent, l’urbanisation du système d’information est le socle pour bâtir vos services exposables qui deviendront vos API. Une démarche ESB (Enterprise Service Bus) permettra de mettre en place une architecture SOA (Service Oriented Architecture) avec des composants d’échanges de données normalisés et réutilisables.

Avec l’ESB, les échanges de données sont normalisés et transitent au travers d’un bus applicatif dans le SI. Les applications du système d’information vont s’abonner aux services qui les concernent.

La solution d’API Management participera ensuite à étendre la stratégie SOA mise en place dans son SI interne aux échanges avec votre écosystème. Elle pourra aussi mettre à profit les API externes.

Il faut donc bien différencier l’orchestration des services internes, portée par l’ESB, et la gouvernance des échanges avec l’extérieur, portée par la solution d’API Management. C’est votre besoin de transformation qui définit la valeur à tirer de chaque outil, et non l’inverse !

Vous souhaitez en savoir plus sur la Gouvernance des APIs ? Échangez avec l’un de nos experts!

Au plaisir d’échanger avec vous

Architecture du Système d’Information

Avec leur rôle de plus en plus critique au sein des entreprises, les systèmes d’information se sont fortement complexifiés ces dernières années : ajouts successifs de briques applicatives, généralisation des applications SaaS, interfaces point à point…

Il devient alors ardu pour les entreprises de disposer d’une vision globale du Système d’Information, et d’assurer une vraie cohérence dans sa structuration et son évolution. Le risque derrière l’enchevêtrement des flux entre applications, la disparité des dictionnaires de données et des choix d’infrastructure est de rendre le tout illisible et de créer une inertie très forte dans les changements !

Pourtant, avec les impératifs de transformation (métier, business plan, technique, relation avec l’écosystème…) , l’agilité des entreprises est primordiale. Cette agilité se matérialise en exigences concrètes vis-à-vis du Système d’Information : concevoir un SI à un instant T ne suffit plus ! L’enjeu principal est de pouvoir le faire évoluer et le rationaliser suivant l’apparition de nouveaux besoins, contraintes, innovations…

Le défi de l’architecture du Système d’Information s’inscrit pleinement dans ce contexte et cet objectif stratégique. Un préambule à toute démarche, est de bien différencier Système d’Information et Système Informatique !  Le Système d’Information doit s’inscrire dans une vision fonctionnelle et plus pérenne que l’architecture informatique.

Rappel sur les grands principes de l’architecture du Système d’Information

Les objectifs de l’architecture du SI

L’objectif de l’architecture SI est d’analyser, définir et cadrer l’évolution des systèmes d’information en fonction de la stratégie d’entreprise, des processus métier et des innovations technologiques.

L’architecture du Système d’Information se décompose en 4 strates :

Architecture SI : strate métier
Architecture fonctionnelle du SI
Strate applicative de l’architecture SI
Strate technique de l’architecture du SI

Strate métier

Strate fonctionnelle

Strate applicative

Strate technique ou physique

L’architecture a vocation à apporter une vue consolidée du SI et à proposer un plan cohérent pour aligner infrastructure, applications, modélisation fonctionnelle, besoins métiers et stratégie d’entreprise, tout en prenant en compte l’existant !

La démarche rejoint un point de vue dont nous sommes convaincus chez Blueway : l’architecture doit être étudiée de manière descendante. C’est-à-dire que c’est la stratégie métier qui guide les orientations SI. Les choix métiers ne doivent ainsi pas être guidés par les contraintes techniques ! 

Comment le concept d’architecture SI se met en place dans la pratique ?

Sans rentrer dans les débats d’experts, en synthèse, l’architecte SI va étudier les quatre couches, les liens entre elles et cartographier la structure existante selon chacune des strates (diagrammes d’architectures). C’est l’occasion d’identifier et les dysfonctionnements et les axes d’amélioration.

En prenant en compte les orientations stratégiques, il s’agit ensuite de définir en conséquence la feuille de route et les différentes étapes pour passer du Système d’Information actuel au Système d’Information cible sur chacun des axes. La démarche est majoritairement « top – down », c’est-à-dire que ce sont les objectifs stratégiques et les enjeux métier qui pilotent les autres couches. Il existe de nombreuses méthodes de conception du Système d’Information comme Merise, Axial, IDEF, UML, SAD etc. qui peuvent être utilisées dans le cadre d’une prise de recul sur l’architecture du SI.

Les échanges entre les applications en interne mais aussi avec l’écosystème jouent bien sûr un rôle essentiel dans cette cartographie. La démarche d’urbanisation a aussi vocation à optimiser les processus et les flux d’informations au sein de l’entreprise et à garantir l’unicité et la fiabilité des données durant tout leur cycle de vie.

Ainsi, pour prendre quelques exemples pratiques, la démarche d’architecture du SI va permettre de répondre aux questions : comment sont modélisées mes informations et mes données ? Comment les informations circulent-elles dans mon entreprise ? Quels sont les traitements à réaliser sur ces données ? Quels sont les dysfonctionnements et les étapes à optimiser ? Comment améliorer mes processus métier et les échanges avec l’extérieur ?

Les outils et les logiciels au service de l’architecture du SI

Il existe deux grandes catégories d’outils qui viennent assister la démarche d’architecture du SI.

La première correspond aux outils de cartographie pour chacune des couches :

  • Cartographie des processus pour l’architecture métier
  • Cartographie fonctionnelle pour l’architecture fonctionnelle
  • Cartographie applicative pour l’architecture applicative
  • Cartographie technique pour l’architecture technique

Les logiciels de modélisation du SI ou les logiciels d’architecture d’entreprise apportent des réponses à l’enjeu de cartographie des processus : inventaire, recensement du portefeuille d’applications, ilots applicatifs, vues et liens entre les logiciels…

Outre la modélisation initiale, le maintien de la cartographie dans le temps est essentiel. Sans responsable et sans une vraie politique de mise à jour continue, Il est courant de retrouver les anciennes cartographies devenues obsolètes justement lorsqu’il est nécessaire de procéder à des évolutions en profondeur !

L’interopérabilité entre processus et données : le cœur d’une entreprise agile

Focus sur les outils d’urbanisation

La mise en œuvre fonctionnelle et IT de la méthode d’architecture est souvent un passage ardu. Il faut partir du SI existant afin de le faire évoluer vers le Système d’Information cible. La démarche d’architecture du SI doit permettre de ne plus contraindre les processus métier cartographiés et donc la couche métier par rapport aux couches inférieures de l’architecture du SI.

Un gage de succès de la démarche d’urbanisation du SI est donc de ne plus dépendre des applicatifs et des contraintes techniques pour la circulation de l’information. C’est-à-dire de rentrer dans une approche SOA (Services Oriented Architecture) assurant des composants d’échanges de données normalisés et réutilisables, en interne mais aussi avec votre écosystème. Et pour cause, dans de nombreux cas, la cartographie aura montré que les processus d’entreprise ne se restreignent pas aux applicatifs et sont transversaux !

Les outils d’urbanisation doivent ainsi vous garantir de vous affranchir des contraintes techniques afin de mettre votre SI au service des processus métier et de la stratégie d’entreprise, maintenant et dans le futur. Il s’agit ainsi de :

  • Désiloter les applicatifs afin de faire communiquer les applications entre elles
  • Se libérer des interfaces point à point afin d’en finir avec le syndrome spaghettis des échanges inter-applicatifs
  • Superviser les flux et les échanges afin de gagner en réactivité face aux erreurs et en capacité d’analyse
  • Faciliter le remplacement et le décommissionnement d’applications pour que votre Système d’information gagne en agilité
  • Contrôler les impacts lors de la modification des interfaces ou des applications et éviter le cercle vicieux qui consiste à ajouter des couches car on ne maîtrise pas l’existant
  • Ouvrir votre Système d’Information vers vos partenaires, clients, fournisseurs… car les processus métier dépassent maintenant très souvent le SI interne

Comment Blueway vous accompagne dans l’urbanisation de votre SI ?

Sans détailler les terminologies techniques (ESB, EAI, BPM, MDM, demi-interfaces, formats pivots, etc.), notre volonté au travers de notre plateforme Blueway est de vous redonner la maîtrise des flux d’informations et de vous apporter une vision holistique des échanges de données au sein de votre SI et avec l’extérieur :

  • Transporter, manipuler, contrôler, exposer les données dans une logique SOA
  • Modéliser les processus fonctionnels et intégrer l’humain au sein des processus au travers d’IHM ergonomiques
  • Centraliser, harmoniser, unifier les données au sein de référentiels
  • Industrialiser les échanges avec l’extérieur et publier vos services avec un portail d’API.

En complément, si Blueway n’est pas outil de cartographie globale du SI, nous cartographions les flux, données et processus qui transitent au sein de notre application.

Pour nous, les enjeux business et humains doivent rester au cœur du Système d’Information… et être les sources et les guides de son architecture !

Vous souhaitez en savoir plus ? Échangez avec nos experts : L’urbanisation nous passionne depuis toujours !

Au plaisir d’échanger avec vous !

Items portfolio