Un autre morceau d'un manuel sur la programmation d'entreprise.
Les processus frontaliers sont mieux automatisés. Cela peut paraître ringard, mais une telle recommandation est loin d'être toujours mise en œuvre.
Les situations sont encore courantes lorsque le processus traverse la frontière sans utiliser de systèmes automatisés. Dans de nombreuses entreprises, des notes de service, applications, commandes, etc. sont utilisées. Bien sûr, cela ne s'applique pas seulement aux frontières entre les services - les employés du même service pèchent également avec des morceaux de papier.
Si un employé remet le processus à un autre sous forme papier, il est extrêmement difficile de suivre l'état de cette tâche. La méthode élémentaire et répandue de perdre une telle tâche s'exprime dans la phraséologie «nettoyer sous le tissu». C'est bien si l'employé empile de tels morceaux de papier sur son bureau - alors le volume des applications est au moins visible. Théoriquement, un morceau de papier spécifique dans cette pile peut même être trouvé et déterminer combien de temps il a été dans cette file d'attente.
Une méthode de transfert d'un processus par e-mail est également courante. Hélas, cette approche n'est pas bonne non plus. Dans un certain sens, c'est encore pire qu'une pile de papiers, car les clients de messagerie ne disposent pas de fonctionnalités suffisantes pour gérer les lettres en tant que tâches. Une personne aura juste une montagne de lettres, ce qui est à peine possible de déterminer l'état de la file d'attente.
A propos du transfert oral des tâches et ne vaut pas la peine d'en parler. Comme on dit, a volé dans une oreille, a volé dans l'autre.
Il y a un autre moment désagréable associé à la connaissance des frontières. Lorsqu'une personne a transféré la tâche à une autre - sur papier, verbalement ou par e-mail - alors le porteur de tâche appartient désormais à la seconde. D'un point de vue formel, moral et souvent technique, le premier ne peut plus se plonger dans les tâches du second. Avec une certaine structure de subordination, vous pouvez bien sûr creuser plus profondément dans une pile de documents, mais lire le courrier électronique de quelqu'un d'autre est déjà trop. Il est toujours possible de connaître l'état d'une ou plusieurs de vos applications, vos instances de processus, mais il est presque impossible d'évaluer l'état général de la file d'attente «à la frontière».
Nous avons donc besoin d'un système automatisé de contrôle des frontières. Il a plusieurs exigences importantes.
La première exigence est que le système doit identifier clairement la file d'attente et les tâches qu'elle contient. Même dans les systèmes automatisés développés, ce n'est pas toujours possible. Si vous demandez à une personne de montrer le tour de ses tâches dans le programme, elle pourra démontrer quelque chose - il montrera une liste de documents, appliquera des filtres et triera, et vous obtiendrez une liste de tâches. Si vous demandez au programmeur, il fera de même, non seulement dans la liste des documents, mais, très probablement, en interrogeant les données.
La phrase clé ici est «si vous le demandez». Et si vous ne demandez pas? Pour un programmeur d'entreprise, cette simple question («et si vous ne posez pas de question?») Peut être un critère clair pour l'identification correcte de la frontière. Si vous, en tant qu'observateur extérieur, pouvez, sans demander à un employé, voir une liste de ses tâches, alors la première exigence est remplie - la file d'attente est identifiée.
Avec l'apparente simplicité de ce critère, vous constaterez que la plupart des systèmes automatisés ne le satisfont pas. Comprendre la file d'attente car elle n'était que dans la tête d'un employé, même sous le tsar Gorokh et les notes de service, est resté dans le système automatisé. Cette situation est familière et semble normale, car «tout le monde l'a». Mais si vous, en tant que programmeur d'entreprise, souhaitez améliorer ce processus, vous devrez faire l'identification de la file d'attente.
La deuxième exigence est que la file d'attente doit être décomposée avant les tâches, c'est-à-dire à des entités simples qui nécessitent des actions compréhensibles. Il arrive que la file d'attente semble être identifiée, mais les tâches de différents processus y sont mélangées. Dans ce cas, la contrôlabilité et la contrôlabilité de la file d'attente est une question sérieuse.
Le critère est simple: si vous, sans demander à un employé, pouvez vous dire pour chaque tâche spécifique ce qui doit être fait, alors la file d'attente est correctement décomposée. Si la réponse est «il faut comprendre», ou «il faut y remédier d'une manière ou d'une autre», ou «n'a pas encore regardé», alors la décomposition est mauvaise. Le système et le processus continuent de dépendre de l'employé.
La troisième exigence est que les priorités pour l'accomplissement des tâches doivent être claires. Le principe est le même que dans les critères précédents. Si vous, en regardant la file d'attente de côté, voyez l'ordre des tâches, alors les priorités sont claires. Si vous, ou les consommateurs du processus, devez interroger l'employé sur les priorités ou réinitialiser ces priorités tous les jours, la file d'attente est mal gérée.
La quatrième exigence est que le temps passé par la tâche dans la file d'attente, c'est-à-dire Le principe "Iceberg" est appliqué. Le temps passé est généralement lié aux priorités d'exécution, mais il existe également des conflits.
Par exemple, le système de priorité est construit sur un double tri - d'abord l'importance, puis la date de la tâche. Dans ce cas, avec un volume important de tâches importantes, il n'atteindra jamais l'important. Si le processus est tel que la non-réalisation éternelle de certaines tâches est considérée comme la norme, alors ça va. Mais, en règle générale, dans les processus de streaming, il est important de terminer toutes les tâches.
Par conséquent, l'influence mutuelle de la priorité et du temps passé dans la file d'attente doit être surveillée. Par exemple, après avoir spécifié le système de priorité, ajoutez un coefficient de pondération au temps passé dans la file d'attente, de sorte qu'à une certaine valeur, la tâche flotte à la surface, quelle que soit son importance.
Ainsi, le critère est simple: si vous voyez que chaque tâche a du temps dans la file d'attente, alors l'exigence est remplie. Une erreur typique est l'opinion qu'il suffit de connaître et de voir la date de l'énoncé du problème, car dans ce cas, le temps passé dans la file d'attente peut être facilement calculé. L'automatisation est vraiment facile à faire. Mais le calcul dans l'esprit est beaucoup plus difficile, et aucun employé sain d'esprit ne le fera. Par conséquent, le temps passé dans la file d'attente ne sera pas pris en compte dans le travail.
La cinquième exigence n'est pas banale, mais l'exécuteur de la tâche doit être connu. Si le choix de l'entrepreneur est réglé par un algorithme automatisé, alors le moment où cet algorithme est exécuté doit être compris.
Tant que la tâche n'a pas d'exécuteur testamentaire, elle ne sera pas résolue. L'entrepreneur n'a pas à être affecté à chaque tâche spécifique - il suffit de comprendre que la solution à toutes les tâches de la file d'attente identifiée est attribuée à une personne spécifique.
Le choix d'un entrepreneur entraîne souvent une file d'attente inactive dans les cas où l'entrepreneur dans le processus désigne non pas une personne spécifique, mais un poste ou un service. Dans ce cas, il est recommandé que le choix de l'exécuteur testamentaire soit effectué comme une tâche distincte, que le gestionnaire ou un certain répartiteur devrait effectuer. Bien que le choix de l'entrepreneur ne soit pas une tâche, mais un privilège, la file d'attente sera constamment bloquée à ce stade.
Le critère est simple: en regardant du côté de la ligne, vous devez savoir exactement qui fera la tâche.
La sixième exigence , des domaines supérieurs de la programmation d'entreprise: le système doit être capable de visualiser et de comparer les files d'attente de différents processus. Dans le cas général, une telle exigence n'est jamais remplie, nous ne pouvons donc parler que du degré de conformité.
Le problème, généralement, est que différentes files d'attente, tâches et processus sont différentes entités système, avec des ensembles de propriétés disjoints. Il existe une instance de processus dans une file d'attente, mais pas dans une autre. Une tâche a une date de production, tandis que l'autre n'en a pas. Etc.
Compte tenu d'une telle diversité d'entités, personne ne résout généralement la tâche de contrôler toutes les files d'attente «dans une seule fenêtre» - ni dans les systèmes automatisés, ni dans le contrôle manuel. Par conséquent, l'état des files d'attente - à la fois instantanées et métriques par période - reste un mystère, ce qui réduit l'efficacité de la gestion et de l'analyse.
Les systèmes de contrôle de processus qui «enchaînent» une variété de documents primaires en entités uniques sont en partie utiles. C'est ainsi que les cartes de processus, les tâches communes et les entités d'adressage apparaissent.
Mais pour un programmeur d'entreprise, hélas, cette approche n'est pas très appropriée.
Premièrement, l'application de processus entraîne généralement une complication de l'automatisation - pas tant de la période de développement que des changements ultérieurs. Le processus, avec la carte, les exécuteurs, les actions et les conditions, est en soi un objet d'automatisation, avec toutes les conséquences qui en découlent - la nécessité de maintenance, de débogage, de coordination, etc.
Deuxièmement, la véritable image des processus, en règle générale, ne peut être tracée en raison du conflit «un-plusieurs». La plupart des systèmes de dessin de processus veulent qu'un seul objet soit exécuté à la fois, même si l'objet est multiple.
Par exemple, le processus d'exécution d'une demande d'achat. Si vous dessinez une carte de bout en bout de ce processus, il s'avère que la même application s'exécute du début à la fin. Le même fournisseur, à en juger par la mappe de processus, doit travailler avec chaque application séparément, dans le cadre de l'instance de processus.
En réalité, le fournisseur ne participe pas du tout au processus de bout en bout. Il a sa propre carte, à l'entrée de laquelle se trouve un éventail d'applications. De plus, chaque jour - d'un volume différent (y compris, parfois, vide). Après avoir exécuté une application spécifique à partir de cette première instance, la gestion revient à un seul processus.
Un tel processus ne peut être dessiné qu'en utilisant des processus imbriqués, qui réussissent généralement, mais la simplicité et la clarté de l'algorithme sont perdues - il devient technique, compréhensible pour les programmeurs, mais ne convient pas aux personnes vivantes et à la gestion.
Troisièmement, ces processus sont sujets à la bureaucratisation - ils s'efforcent de les rendre «béton armé», de les coordonner, de les imprimer et de les mettre sur l'étagère. Cette approche contredit les principes de l'automatisation rapide et, par conséquent, ne convient pas à la programmation d'entreprise. Les processus de bétonnage, en particulier pendant la période de débogage, sont identiques à l'impression du code de programme.
Et, quatrièmement, les développeurs de mécanismes de dessin de processus, guidés uniquement par la logique du programmeur, ne fournissent pas d'outils de gestion de file d'attente. En conséquence, analyser toutes les lignes aux frontières, les comparer les unes aux autres, en déplacement ne fonctionnera pas. Vous devez encore inventer vos propres outils.
La méthode de dessin des procédés "béton armé" peut être utilisée comme auxiliaire, il n'y aura pas beaucoup de mal. Ou, il peut être utilisé à la fin du projet, comme un moyen de préserver les processus configurés. Jusqu'au prochain projet.
Cependant, n'oubliez pas le troisième point - la tendance à la bureaucratisation. S'il vous semble que vous pouvez conserver le système pendant un certain temps, alors le reste des employés et des gestionnaires ont une opinion opposée: ne touchez pas à ce qui fonctionne. Le système créé, débogué et implémenté par vous commencera à vous résister.
Il est préférable d'utiliser le principe de "Tâche automatique" ou similaire lorsque votre système possède des entités qui peuvent "se rattacher" aux processus en cours et créer des tâches dans une file d'attente. Le principe lui-même sera examiné ultérieurement.
Une entité unique pour gérer les files d'attente aux frontières donne, tout d'abord, un système de coordonnées unique - les métriques de tous les processus dans les mêmes unités. Tout processus peut être évalué - à la fois instantanément et rétrospectivement - sur la même échelle.
L'évaluation instantanée peut être implémentée, par exemple, dans un panneau de contrôle de processus commun. Pas dans la carte de processus générale traditionnelle, qui ne peut pas être vue sur un écran sans défilement, mais sous la forme d'une liste simple, même sans chiffres, utilisant un écran couleur, comme un feu de circulation. Cela se traduira par une liste de deux colonnes: processus et statut.
L'option est un peu plus intéressante - pas une liste de processus, mais une liste de points problématiques. Le point, dans ce cas, est une tâche automatique, un certain nœud d'un processus spécifique, sans équivoque comparable à la vie. Par exemple, «accord de contrats par un avocat». Il suffit de lister tous les points, d'afficher leur statut et de les trier pour que les plus problématiques apparaissent en haut.
Une telle évaluation instantanée de tous les processus, malgré son apparente simplicité et son évidence, est extrêmement rare. Vous comprenez maintenant pourquoi.
L'analyse de file d'attente rétrospective est un phénomène encore moins courant car la plupart des systèmes ne contiennent pas du tout les données nécessaires. Ces données ne sont disponibles que si le principe Iceberg est pleinement utilisé, lorsque non seulement l'heure de l'état instantané est stockée, mais aussi son historique.
En général, comme vous le voyez, il n'y a rien de compliqué à automatiser le contrôle des frontières. Il est important de ne pas créer de difficultés artificiellement en utilisant des processus de «béton armé» et en ignorant les principes d'une automatisation rapide. Les approches et les critères que vous devez utiliser lors de l'automatisation des états limites des processus sont désormais connus de vous.