Pourquoi utiliser la modélisation des processus d’entreprise ?
Les organisations utilisent la modélisation des processus opérationnels (modélisation BP) afin de documenter visuellement, comprendre et améliorer leurs processus. Faisant partie de la gestion des processus d’entreprise (BPM), la modélisation BP a été utilisée comme outil organisationnel pour cartographier ce qui est (ou « en l’état ») comme référence et pour déterminer l’avenir (ou « à venir ») avec toutes les améliorations assimilées. La modélisation BP représente visuellement toutes les activités, événements et ressources qui relient le processus d’un produit ou d’un service afin de le rendre plus efficace. La modélisation BP combine souvent les disciplines de la cartographie des processus, de la découverte de processus, de la simulation de processus, de l’analyse des processus et de l’amélioration des processus. Dans le cadre d’un événement de réingénierie des processus d’affaires (RPA), la modélisation BP est utilisée pour éclairer les processus déjà utilisés, et pour représenter les nouveaux processus. Certaines des autres raisons d’utiliser la modélisation BP sont les suivantes :
- Créer des modèles visuels de processus - La documentation axée sur Word n’est souvent pas suffisante pour que les employés comprennent la façon dont un processus est effectué. Le sauvegarder à l’aide de représentations visuelles permet d’obtenir une image complète.
- Alignez les opérations - Avec toute nouvelle stratégie commerciale, le maintien de la cohérence des processus après un changement exige de trouver comment rester dans la stratégie globale de l’organisation. Des analyses sont également effectuées pour identifier les goulets d’étranglement et les inefficacités, et permettre l’agilité des processus.
- Améliorer la communication sur les processus - La communication est la clé de toutes les tâches suivantes : formaliser les processus existants (qui étaient autrefois des connaissances informelles), créer des processus cohérents, éliminer les suppositions avec les règles commerciales, gérer les exceptions, assurer la conformité réglementaire, s’assurer que les personnes sont responsables et soutenir de nouvelles initiatives (comme le Lean Six Sigma).
- Améliorer l’efficacité opérationnelle - Les processus de modélisation favorisent l’optimisation en permettant la simulation et en illustrant les améliorations nécessaires. Cela réduit le temps de cycle et favorise une meilleure utilisation des ressources.
- Obtenez un avantage concurrentiel - Un processus est meilleur dans l’ensemble lorsqu’il est constamment affiné et aligné sur les stratégies de son entreprise. Cette efficacité place l’entreprise dans une position orientée vers l’avenir pour être meilleure que la concurrence.
Modélisation des processus d’entreprise dans le développement de logiciels
Le développement de logiciels est un domaine risqué. Il y a vingt ans, le rapport CHAOS de 1995 du Standish Group rapportait que 90 % des projets logiciels échouent. Aujourd’hui, ces chiffres sont inférieurs, mais démontrent toujours qu’il y a du travail à faire. Dans le rapport de 2015 du même groupe, le taux de réussite des projets de développement de logiciels n’était encore que de 29 %. Les recommandations du groupe visant à améliorer ces chiffres au fil des ans ont été améliorées et ont suivi de nouvelles tendances, mais voici l’une des recommandations principales : communiquer avec toutes les parties prenantes, en particulier les utilisateurs finaux, car les utilisateurs finaux sont ceux qui finissent par définir les exigences en premier lieu. Les experts recommandent de développer des modèles clairs avec une notation compréhensible dès le début des projets afin de valider les exigences du logiciel. La modélisation BP permet aux ingénieurs logiciels de négocier avec les parties prenantes afin de déterminer le système à construire, en fonction de ce qui est optimal pour les deux groupes.
La plupart des modèles de BP ont été développés dans le cadre d’architectures d’entreprise existantes, ce qui montre que l’intention pendant le développement est que l’utilisateur final est représenté. Cependant, ces modèles ont été réalisés à partir d’un certain nombre de perspectives différentes, y compris fonctionnelles, comportementales, organisationnelles et informationnelles. Les experts s’accordent à dire que la combinaison de ces perspectives dans la conception des processus est la meilleure méthode.
- La perspective fonctionnelle indique quels éléments de processus sont effectués et quelles informations sont pertinentes pour eux.
- La perspective comportementale (ou dynamique) montre la séquence d’interaction et la façon dont les éléments du processus sont effectués.
- La perspective organisationnelle indique par qui et où les éléments d’un processus sont effectués.
- La perspective informationnelle représente l’origine des informations produites ou analysées.
Langage de modélisation des processus d’entreprise dans la modélisation des processus d’entreprise en logiciel.
Tous les langages existants du modèle de traitement des affaires proviennent de différentes facettes de la tradition scientifique, et ont été conçus pour s’adapter à une perspective ou à une autre. Il y a un chevauchement important dans les langages, mais il existe quatre grandes catégories de langages de modélisation des processus d’entreprise.
- Langages traditionnels de modélisation des processus : issus de la tradition de l’ingénierie de l’information des systèmes d’information (MIS), ces langages sont destinés à être compris et ne sont généralement pas formels. Il s’agit notamment de l’IDEF, des réseaux de Petri, de l’EPC, des diagrammes d’activité, du REA et du BPML.
- Langages de modélisation de flux de travail : ces langages de script sont destinés à décrire les flux de travail d’un système de gestion des flux de travail (WfMS). Ces langages très formels comprennent le langage de description des processus de flux de travail (WPDL) et les formats d’échange proposés (PIF, PSL).
- Langages d’intégration des processus : ces langages ont pour but d’intégrer les entreprises et de saisir différents niveaux de sémantique dans les processus. Il s’agit notamment de RosettaNet, ebXML et BPEL4WS.
- Langages orientés objet : destinés à être compris par les experts en informatique et dans le domaine, ces langages représentent le domaine des logiciels. La plupart de la modélisation orientée objet prend en compte les perspectives fonctionnelles, comportementales et informationnelles.
Hafedh Mili et al recommandent aux équipes d’utiliser un langage de base pour la modélisation, puis d’utiliser différentes parties qui conviennent au processus à partir d’autres langages. Dans ce domaine, il semble que les experts s’accordent à dire que même les langages doivent être guidés par les tâches.
Comment aborder un projet de modélisation des processus d’entreprise
Choisir une approche de la modélisation BP est tout aussi essentiel que de l’effectuer. L’approche, qui s’appuie sur la tâche elle-même, n’est pas une affaire universelle. Certaines classifications doivent être effectuées avant qu’un projet ne soit entrepris. Selon Bider, les professionnels doivent prendre en compte trois facteurs : les processus opérationnels réels, les caractéristiques de l’environnement de modélisation et l’utilisation prévue du modèle. Ces trois facteurs peuvent être divisés en considérations commerciales spécifiques.
- Les processus opérationnels - Les entreprises doivent tenir compte de leurs participants actifs et passifs, de la manière dont ils atteignent leurs objectifs opérationnels, de la proximité du processus avec son environnement, ainsi que de la nature et de l’ordre du flux de processus.
- Les caractéristiques de l’environnement de modélisation - Pour l’environnement de modélisation, les entreprises doivent tenir compte de la maturité de leurs processus existants et de savoir s’il y a ou non du personnel disponible qui comprend la notation très formelle.
- L’utilisation prévue du modèle - Les entreprises doivent tenir compte de leurs objectifs de conception de modèles et de la base qu’elles utilisent pour créer des modèles. Par exemple, elles peuvent essayer d’améliorer les processus actuels, fournir une analyse ou une réingénierie, ou créer un nouveau système informatique.
Étant donné qu’il n’existe pas d’approche universelle de la modélisation BP, les experts recommandent de prendre en compte tous les facteurs commerciaux uniques. Certains professionnels recommandent une approche formelle spécifique qui recueille toutes les informations avant de choisir des outils, tandis que d’autres recommandent des outils spécifiques qui ont fonctionné pour eux dans le passé. Deux de nos experts font leurs recommandations ci-dessous.
Selon Dani Peleva, directeur général de Local Fame Ltd :
“When approaching a business process modeling task, I’d always break it through the prism of project management as it helps me get an idea of the objective of the system that needs engineering, the time the process needs to be completed for, as well as the resources available. Once you know what the requirements are, i.e. the purpose of the process is, what the deliverables are, the budget/resource constraints and so forth, it is a lot easier to approach the design/engineering stage.
When it comes to process engineering at Local Fame, we always have efficiency and effectiveness in mind - the most cost-effective, timely and optimized manner that a process can flow. For this purpose, I always approach the task from a few different angles - from the start of the process, as well as from the end of the process backwards. When you do not limit yourself with the direction of the process flow you can identify gaps and possible flaws in the strategy and implementation, as well as possible bottlenecks. Once I come up with a few different models I test those applying different scenarios in order to understand how sustainable those are in turbulent environment. This is when usually you sift through the best models and shortlist one or two successful ones.
Additionally, an intrinsic part of business process modelling for me is risk management, more specifically, identifying the potential flaws of the model and where and under what circumstances the model can fail. Identifying those weaknesses of the process helps you create contingency plans and backups, and as you often may find yourself, you get to optimize the process even further and scrap some of the chunks you initially considered essential, but later on realized you could go without. When thinking about risk management, however, one should know a risk could be both a positive and a negative, risk can create opportunities for the process to fail or get delayed, but also speed up and become more efficient, which again leads to the process optimisation and potential changes in the model. Tools I often use when doing business process modelling are Gliffy, Activiti Modeller, and Gantt charts.
To conclude, when modelling a process or re-engineering an existing one, I usually approach the task from a project management perspective analysing the requirements fully before moving to the design stage. After design stage, I test the model numerous times in different scenarios and if needed I return to different stages to optimise and tweak it further. Lastly, I always think about risk management and contingency to make sure that the process is resilient and sustainable.”
Ray McKenzie, Founder and Principal, Red Beach Advisors, recommends, “As a management and business consultant for small- to medium-sized companies, a primary duty of mine is to develop efficient and optimized process for every organization to be productive. I always start with examining the problem and finding out the history of the problem, the different parts of the problem, and the effect the problem has on the business. Understanding the problem and components are core pieces to developing an effective process model to improve. Start with the problem. Examine the parties involved. Understand the current performance and measurements. Define the performance improvement goals. Outline an efficient process which drives results and displays success.”
Flux de travail et approche orientée services (BSOA)
Certains experts considèrent la modélisation de BP pour le développement de logiciels comme une perspective avant et après qui tourne autour de l’introduction des services Web. Avant le développement du web, l’approche principale pour le développement des processus était les flux de travail. Dans l’approche des flux de travail, les processus opérationnels sont prédéterminés. Les langages les plus appropriés sont le langage d’exécution des processus d’entreprise (BPEL) et le langage de définition de flux (FDL). L’approche du flux de travail a été critiquée comme n’étant pas très flexible dans un environnement moderne.
Après le développement de services Web, l’approche de la modélisation BP pour le développement de logiciels est devenue plus ciblée et identifiée comme l’approche orientée services aux entreprises (BSOA). La modélisation des processus repose sur la composition flexible des services aux entreprises. L’approche peut être adaptée pour répondre aux objectifs et exigences du designer dans le développement de l’architecture en utilisant des éléments de construction. Les services effectuent de petites tâches, telles que le développement de données, ou des procédures de service simples. Pris dans l’ensemble, le BSOA constitue un système extrêmement réutilisable qui peut être corrigé et régulièrement mis à niveau. Cette approche est créditée comme étant Agile, et applicable à de nombreux types d’organisations différents.
Différentes façons de modéliser les processus opérationnels
Entre toutes les normes et les langages standardisés, certains professionnels pensent que la créativité dans la conception des processus est lessivée. D’autres approches peuvent restaurer une partie de cette créativité. Certaines des techniques les plus populaires qui peuvent être autonomes ou même compléter des approches plus formelles sont les suivantes :
- Technique des diagrammes de flux
- Diagrammes de flux de données : la technique de Yourdon
- Diagrammes de rôle-activité (RAD)
- Diagrammes d’interaction des rôles (RID)
- Diagramme de Gantt
- Définition intégrée de la modélisation des fonctions (IDEF)
- Filets de Pétri colorés (CPN)
- Méthodes orientées objet (OO)
- Technique de flux de travail
- Simulation
- Notation de modélisation des processus d’entreprise (BPMN)
- Diagramme d’activité UML
- Modèles de processus transformationnels
- Témoignage
- Modèles de processus hiérarchiques
- Visualisation
According to Bernard Lee, President of Charlotte Search Engine Consultants, there are other ways to model your projects visually. He points out that, “As a lifelong entrepreneur who started my first business at 20, I am now 53 and am considered a ‘college dropout.’ It has always been about systems, automation, and measuring risks to achieve our stated goals. This has been true in my career as a wealth manager, a Healthcare IT executive, and now as the founder of a digital marketing agency that specializes in SEO. Yes, SEO is about metrics, analytics, and CTR (click-through rate). Nevertheless, I've found the creative aspects is what separates the pretenders from the achievers. We are Google partners so we believe in the usual success measurements, but get there differently. YouTube, Geo-Tagging, and unorthodox combinations of our client's digital properties consistently land multiple properties on page one for the most important keywords. The visual of multiple positions on page one always has an immediate impact on our client’s brand, traffic, and conversions while moving competitors to page two.”
Cartographie des processus par rapport à la modélisation des processus
La cartographie des processus est un examen de haut niveau d’une organisation en tant qu’entité unique avec des parties interconnectées. Le flux des processus opérationnels au sein de l’organisation est examiné afin de clarifier qui fait quoi, comment les processus sont exécutés et selon quelle norme ils sont jugés. Dans la modélisation des processus, les professionnels sont plus concentrés sur l’efficacité des processus, en utilisant les meilleures pratiques commerciales et économiques. Bien que les deux représentent graphiquement les processus, la modélisation des processus est une plongée plus profonde dans les relations qui produisent les services et les résultats.
Cadre de modélisation et d’évaluation des processus logiciels (FMESP)
L’un des problèmes complexes qui est venu du développement de processus opérationnels standardisés est la notion que leur efficacité doit être déterminée. En d’autres termes, dans quelle mesure les processus opérationnels sont-ils réussis ? Le FMESP est un ensemble de métriques pour évaluer les modèles conceptuels des processus opérationnels : ce qu’ils font et ce qu’ils ne font pas. Le FMESP mesure la complexité structurelle des modèles de processus logiciels, puis les activités, les rôles et les produits de travail. Ce cadre est destiné à fournir aux entreprises des informations objectives sur la maintenabilité de leurs modèles.
Développez de bons modèles de processus opérationnels
Comment un professionnel commence-t-il un modèle BP ? L’une des approches courantes préconise de choisir un problème, de sélectionner la méthode, puis de résoudre le problème. Le fait de rester simple garantit que tout ce qui est pertinent est dans le modèle et que tout dans le modèle est pertinent.
Voici d’autres astuces professionnelles :
- Assurez-vous de savoir qui sera vos ressources. Développez des listes de tâches, de personnes et du temps requis pour terminer le modèle.
- Effectuez vos entretiens dans l’ordre où les rôles apparaissent sur le modèle de processus.
- Document. Document. Document.
- Vérifiez à nouveau tous vos symboles, assurez-vous qu’il y a une clé et suivez chaque étape pour vous assurer que le chemin vous emmène en arrière ou en avant.
- Connaissez le résultat souhaité à l’avance.
- Déterminez vos points de début et de fin.
- Obtenez à l’avance les documents et formulaires qui font partie du processus.
- Utilisez des modèles chaque fois que vous le pouvez.
Selon Steve Wallis, co-fondateur/analyste/consultant chez ASK MATT, Foundation for the Advancement of Social Theory (FAST) - Theory for a better world :
“BPM is incredibly useful for showing ‘what goes on’’ within a business organization. However, it can also create a false sense of comfort. When the map says, ‘You are here’ we feel a sense of security. However, unless the map shows how to get from ‘here’ to ‘there’ it is not going to be very useful. More importantly for the ever-shifting world of business, a map needs to show multiple paths so that leaders can take advantage of new options when unanticipated problems arise (and you know they will). Research in this area suggests that models (maps) which are more complex and have more interconnections are more useful for understanding how organizational processes work, and how they might be changed when the need arises. What does NOT work is a simple, linear model such as:
Source de l’image : Steve Wallis
Oh, si seulement la vie était si facile, et si prévisible, cependant, ce n’est pas le cas. Par conséquent, nous avons recherché une approche légèrement différente de la modélisation des processus d’entreprise. Appelée cartographie stratégique des connaissances (SKM), nous nous concentrons sur les aspects transformationnels de la modélisation. Plutôt que de modéliser ce qui se passe à la « surface » (par exemple, la recherche donne des informations à la fabrication), nous encourageons nos clients à voir quels changements se produisent à toutes les étapes interconnectées du processus. Grâce à nos recherches et à notre expérience, nous avons développé deux techniques faciles pour développer de bons modèles.
Tout d’abord, pour comprendre une transformation d’un modèle, il doit y avoir plusieurs flèches pointant vers chaque case. Par exemple, si nous parlons de la fabrication de pâtisseries, le processus de création nécessite des matières premières (farine, œufs, sucre, chocolat, etc.) et des équipements (four, grilles, mélangeurs, etc.) et des cuisiniers (avec un certain niveau d’expertise). Par conséquent, afin de mieux comprendre la transformation, nous créons un modèle montrant comment chacune de ces « entrées » se combine pour créer la « production » transformée. Pour certains, cela peut sembler évident. Cependant, voici l’information cachée (ex : garniture au chocolat) : si vous avez un modèle où il n’y a qu’une seule flèche pointant vers quelque chose, ce manque de flèches supplémentaires indique un écart dans le modèle. Pour gérer le processus, il vous manque un autre chemin.
La deuxième astuce pour créer des modèles efficaces est de comprendre chaque flèche comme étant « causale ». C’est l’un des grands morceaux de « connaissances oubliées » dans le monde des affaires. La causalité est l’essence de la compréhension scientifique. Pour comprendre le processus de transformation, et les processus opérationnels en général, il ne suffit pas de dire simplement : « Le cuisinier mélange les ingrédients et fait les gâteaux ». Un bon responsable comprend que le fait d’avoir plus de matières premières, plus d’équipement et plus d’expertise entraînera la transformation en un produit (ou service commercialisable). Et, pour gérer ce processus, il peut y avoir quelques compromis entre eux (un très bon expert peut être en mesure d’étirer un peu la matière première), mais chaque flux est nécessaire pour créer le produit final. Sans matières premières, je n’aurai pas de pâtisserie avec mon café ! »
Notation de modélisation des processus d’entreprise (BPMN)
Le BPMN a été développé par la Business Process Management Initiative (BPMI) et est maintenu par l’Object Management Group (OMG). Aucun logiciel ou entreprise de conseil n’en est propriétaire. Il s’agit d’une notation graphique pour créer des modèles de processus, similaires à des organigrammes, qui est utilisée et comprise à l’échelle de l’industrie. De nombreux outils logiciels prennent en charge le BPMN. Cependant, la signification des formes et des symboles est indépendante de ces outils, et ces significations sont précises. Le BPMN est un élément essentiel de la gestion des processus d’entreprise (BPM), une initiative de l’architecture d’entreprise. La version de BPMN actuellement utilisée est la v2.0, dernière mise à jour en 2011. Les professionnels peuvent être certifiés en BPMN v2.0 lors du processus d’examen OMG. L’OMG propose également des guides qui montrent comment la notation est divisée en groupes d’événements, d’activités, de flux, de données, d’artefacts, etc. Les éléments sont classés en quatre groupes principaux appelés objets de flux, objets reliant, couloirs et artefacts.
Source : OMG
L’objectif du BPMN est que les utilisateurs techniques et les utilisateurs professionnels puissent être en mesure de comprendre un langage schématique commun. Le BPMN est fondé sur une technique d’organigramme similaire à celle développée à partir du langage de modélisation unifié (UML), et peut être cartographié directement au langage d’exécution des processus d’entreprise (BPEL), un langage qui s’appuie sur XML qui est utilisé pour définir les services commerciaux d’entreprise au sein des services Web.
Critique du BPMN
L’opinion du secteur varie quant à l’utilisation du BPMN pour la modélisation BP. Les critiques soutiennent que le BPMN est beaucoup plus complexe et avancé qu’il n’en a besoin pour les parties prenantes qui ne sont peut-être pas très proches du processus réel. De plus, avec autant de symboles, il est facile de faire des erreurs, ce qui contredit le but de son utilisation.
Les partisans du BPMN disent que la plupart des professionnels n’utilisent qu’une poignée de symboles, ce qui rend inutile la connaissance des symboles obscurs. Certaines entreprises internationales ont besoin de la cohérence du BPMN, en particulier lorsque les langages peuvent être variées. Comprendre les processus à l’aide d’une notation standardisée est moins difficile.
Autres types de notations et de diagrammes
En 2012, Cristina Venera a effectué une étude de deux langages de notation populaires, le BPMN et le diagramme d’activité UML (UML AD). Parmi les professionnels et la littérature, elle a constaté que les deux langages sont également faciles à comprendre par les parties prenantes intéressées par la modélisation BP, et qu’elles fournissaient en fait toutes les deux des solutions similaires. Cependant, la différence était que le BPMN peut être cartographié avec (WS)BPEL, tandis que UML AD n’est pas en mesure d’être automatiquement cartographié avec aucun BPEL.
D’autres types de notations comprennent la chaîne de processus pilotée par les événements (EPC), les diagrammes de flux de travail et les cartes mentales. L’EPC est le plus souvent utilisé pour des processus opérationnels de niveau supérieur, se compose de cinq éléments et règles, et commence toujours par un événement et se termine par un événement. Il existe des règles entre les deux : « OR », « AND » ou « XOR » représentés sous forme de connecteurs graphiques.
Les diagrammes de flux de travail illustrent les étapes et les relations entre toutes les parties d’une entreprise. Dans les diagrammes de flux de travail, il n’y a pas d’ensemble de symboles (standard) convenus. Il est plus difficile de comparer les modèles réalisés au sein d’une organisation, mais laisse plus de liberté à la créativité.
Les cartes mentales sont les moins restrictives de toutes les techniques énumérées ici. Bien qu’elles soient généralement hiérarchiques, elles peuvent être faites à la main sur une serviette dans un pub, si nécessaire. Les cartes mentales sont un moyen de montrer les relations autour d’un seul concept ainsi que d’éventuelles associations. Elles sont libres et permettent un maximum de créativité.
Source : Jennifer Frith
Ce qu’il faut rechercher dans les logiciels de modélisation des processus d’entreprise
D’après toutes les opinions d’experts et les recherches, il ne semble pas y avoir un seul outil qui répondra à tous les besoins éternels d’une organisation. Les principales exigences recommandées pour un outil ou une suite d’outils sont qu’ils sont rapides (à apprendre) et peu coûteux. La page d’accueil du BPMN répertorie 74 outils conformes au BPMN. Si la conformité BPMN est une exigence, la recherche est déjà restreinte. Sinon, les utilisateurs doivent indiquer leurs objectifs et exigences, quels outils répondent à leurs exigences, quels sont les critères les plus importants et quels outils potentiels pourraient être utilisés. Ensuite, il faut TESTER. Trouver le bon outil peut être un processus, mais il ne sera pas regrettable.
Selon Norbert Nogrady, directeur général et copropriétaire de JCM Ltd : norbert.nogrady.bpralumni@gmail.com, Twitter : @kgordos
“I started to reorganize organizational units more than 15 years ago. At the time, the number of available process modeling tools was very limited, much less their functionality. However, as time went by, I witnessed the evolution of such tools. In the beginning, I used large sheets, then Microsoft Word and Visio. However, I had a number of serious issues with these tools. The biggest problem is that BPR projects tend to be lengthy and thus overwhelming. The usual routine at the large corporations I worked for was (one of the following):
- La direction a nommé le service informatique pour trouver un outil de gestion des processus d’entreprise (flux de travail) qui correspond aux exigences informatiques.
- Des responsables de la direction et les ingénieurs RPA ont créé leurs processus respectifs
- Des diagrammes de processus avaient été créés à l’aide de divers outils.
- Les processus ont ensuite été transférés au service informatique, afin qu’il puisse évaluer si les processus correspondent au système de flux de travail de leur choix.
- Après un certain nombre d’itérations, qui se sont généralement traduites par des compromis concernant les processus, le service informatique a commencé à programmer les processus dans le système de flux de travail.
- Les processus ont été mis en œuvre au sein de l’organisation, avec la nécessité immédiate de réorganiser beaucoup d’entre eux.
- Les points deux à six ont été répétés pendant longtemps jusqu’à ce qu’un ensemble de processus opérationnels quelque peu acceptable soit créé.
Comme il ressort clairement de ce qui précède, la RPA de cette façon n’a pas été facile, mais au lieu de cela, elle exige beaucoup de temps et de ressources. De plus, je me suis rendu compte très vite que les services devaient créer leurs propres processus, au lieu d’itérer avec l’informatique ; par conséquent, un certain nombre de compromis de processus pourraient être évités. De plus, il a fallu beaucoup de temps pour mettre en œuvre les processus créés dans le système de flux de travail en programmant. Ces deux problèmes m’ont dérangé au point que j’ai commencé à chercher une solution qui correspond aux exigences informatiques habituelles et soutient pleinement mes activités de RPA.
Après beaucoup d’essais et d’erreurs, Nogrady a finalement trouvé une solution qui fonctionnait pour lui. Après sa recherche réussie, il propose de chercher un système de flux de travail doté d’un outil intégré d’éditeur de processus et de flux de travail avec une interface graphique, ce qui rend la programmation de processus obsolète. L’avantage est qu’une fois qu’un processus a été créé dans l’éditeur de flux de travail graphique, il suffit d’un clic sur un bouton pour qu’il soit exécuté immédiatement dans le système de flux de travail. Par conséquent, tous les services peuvent créer leurs propres processus opérationnels, sans avoir besoin de programmation. Suivre cette voie signifie qu’il n’y a pas ou peu de compromis dans les flux de travail et plus important encore, beaucoup de temps et de ressources pourraient être épargnés de cette façon. Enfin, une bonne solution fera que les tests des processus prendront beaucoup moins de temps et d’efforts. De cette manière, si un processus peut utiliser une certaine amélioration, n’importe qui dans le service peut avoir ses suggestions, et si le chef de service l’a approuvé, le processus modifié devrait être en mesure de s’exécuter dans le système de flux de travail en quelques heures.
L’avenir de la modélisation des processus d’entreprise
L’un des domaines critiques de préoccupation pour l’avenir de la modélisation BP comprend la manière dont les approches de modélisation pourraient être standardisées. De nombreuses entreprises passent à une plateforme plus Agile, et la modélisation BP ne va pas nécessairement de pair avec les processus Agile. Une approche de modélisation ne peut être considérée Agile que pour certains types de processus, selon une étude récente de Nancy Alexopoulou.
Comme le note également Ian Gotts, fondateur et PDG de Elements.cloud et chroniqueur chez Digital Business, « Il y a de grands problèmes dans le secteur de la modélisation BP. Les fournisseurs de BPM, d’automatisation et de logiciels de flux de travail ont détourné le BPM, de sorte que le B dans le BPM a disparu. La modélisation a fini par signifier la définition des flux de travail par l’informatique pour l’informatique. Toutefois, la visualisation des processus (modélisation des processus d’entreprise) est précieuse pour les utilisateurs finaux. Elles utilisent les diagrammes de processus opérationnels pour s’entendre sur la façon dont le travail est effectué. Cela donne ensuite une perspective informatique en coulisses. Néanmoins, il est difficile d’essayer d’utiliser la notation BPMN comme modèle pour tout le monde ; avec autant de symboles, elle semble alambiquée, et les professionnels sont rapidement désengagés et se demandent pourquoi ils font cela.
“There is a notation - Universal Process Notation (UPN) - that works for business people, that has been very successful. It is outlined in Chapter two of the e-book, Analysis, Automation & Adoption for #AwesomeAdmins. The first principle that is relevant here is that we are not building a huge flowchart, but a hierarchical process map, where every diagram is easier to follow. For example, at a bank, there may be 10,000 diagrams for all of the processes, but they are organized in a hierarchy so no diagram is overwhelming. Second, the notation is a simple model using an activity box or step with inputs and output, resources identified (or swimlanes), and hyperlinks to supporting information. This process map is useful for end users, but it is also valuable for compliance, IT, and management where metrics can be viewed in the context of a process. Using this approach is valuable for app vendors to improve adoption. An end-to-end process can make sense of the detailed flow of apps.”
En savoir plus sur la modélisation des processus d’entreprise
Vous souhaitez en savoir plus sur la modélisation BP et comment la mettre en œuvre dans votre entreprise ? Vous trouverez ci-dessous des listes de ressources à lire qui peuvent vous aider.
Livres et eBooks
- Analysis, Automation & Adoption for #AwesomeAdmins - Manuel du logiciel UPN gratuit
- A Pragmatic Guide to Business Process Modelling, de John Holt
- Essential Business Process Modeling, de Michael Havey
- Business Process Modeling, Simulation and Design, Second Edition, de Manuel Laguna et John Marklund
Livres blancs
- Strategic Knowledge Mapping For Improved Policy and Strategic Planning, de Steven E. Wallis et Bernadette Wright.
- Strategic Knowledge Mapping: The Co-Creation of Useful Knowledge, de Steven E. Wallis et Bernadette Wright..
Logiciel
- Une liste de logiciels gratuits de modélisation des processus d’entreprise
- Comparaison des outils de notation de modélisation des processus d’entreprise
- Guide du marché de l’analyse des processus d’entreprise - tiré de Gartner
Autres types de diagrammes
Contribution de Smartsheet à l’amélioration des processus d’entreprise
Donnez à vos employés les moyens de se dépasser grâce à une plateforme flexible conçue pour répondre aux besoins de votre équipe, et capable de s'adapter quand ces besoins changent. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.