Le monde peut apprendre beaucoup des programmeurs. Il apprend déjà, mais pas de la mauvaise façon. Par exemple, j'ai pris des processus et des algorithmes, mais je n'ai pas remarqué une telle approche comme l'asynchronie.
Tout programmeur comprend ce que sont le synchronisme et l'asynchronie. C'est à quel point cela est compris par le programmeur, donc c'est incompréhensible pour les développeurs de processus ordinaires.
Les actions synchrones d'un processus sont celles qui sont exécutées dans le thread principal, au sein d'une instance de processus. La principale différence entre le mode synchrone: l'action suivante ne démarre que lorsque la précédente est terminée. En conséquence, jusqu'à ce qu'une action soit terminée, le processus est en jeu.
Les actions asynchrones sont celles qui s'exécutent en parallèle avec le thread principal, soit dans la même instance de processus, soit dans un autre processus. La principale différence entre le mode asynchrone: exécution parallèle de deux ou plusieurs branches du processus.
Les processus synchrones, comme les programmes, sont beaucoup plus faciles à écrire et à déboguer, donc cette approche de la conception de processus est très courante. Il y a beaucoup à voir avec l'asynchronie, en particulier avec la désignation des points de transition vers l'exécution parallèle et le retour au courant dominant. Il n'y a aucune promesse dans la vie.
Par exemple, le même processus d'approvisionnement sur demande. Il est tracé comme une séquence d'actions standard: une demande est apparue, le fournisseur sélectionne le fournisseur, demande les conditions et les coûts, convient avec le vendeur ou le service de contrôle interne, passe une commande avec le fournisseur, demande l'évaluation de la contrepartie au service juridique ou au service comptable, crée une demande de paiement, attend ce paiement, surveille la commande, puis organise ou suit l'envoi dans l'entrepôt, de sorte qu'à la fin, fermez l'application. Le processus est complètement synchronisé.
Imaginez maintenant - dans notre système d'information, le service d'évaluation des fournisseurs n'est pas connecté. Le service juridique doit donc collecter des informations auprès de sources ouvertes. Cela signifie que l'évaluation prend du temps. Compte tenu de la file d'attente des candidatures aux avocats, trois jours s'écouleront.
Qu'adviendra-t-il du processus à ce stade? Selon la logique synchrone, elle sera mise en jeu. Le fournisseur, étant un véritable élément du système, ne lèvera pas le petit doigt tant qu'il n'aura pas reçu l'évaluation du fournisseur - en particulier si des sanctions sont prévues pour avoir travaillé avec des contreparties non vérifiées.
Pouvons-nous ajouter l'asynchronie ici? Bien sûr. À ce moment, lorsque le fournisseur a choisi le fournisseur, il peut envoyer une demande d'évaluation de la contrepartie au service juridique et, pendant qu'il négociera, s'entendre sur les prix et les conditions. Au moment où il est prêt à passer une commande, et l'évaluation arrivera à temps. Le processus se terminera plus tôt trois jours.
Bien sûr, les avocats peuvent être scandalisés - pour quelle raison évaluerons-nous le fournisseur, si vous ne l'avez pas encore clairement décidé, allez-vous lui commander? Que devraient-ils répondre?
La solution se propose, nous l'avons déjà indiquée ci-dessus - pour connecter le service d'évaluation des fournisseurs. Maintenant, nous comprenons encore mieux pourquoi cela est nécessaire - pour assurer l'asynchronie et accélérer le processus. Cependant, le service sera probablement juste synchrone. Que pensez-vous?
Si le service n'est pas connecté, cette appréciation peut être justifiée par le travail d '"utilisation future". Si votre système d'information dispose d'un emplacement pour écrire les données d'évaluation, la prochaine fois que vous devrez travailler avec ce fournisseur, vous n'aurez plus à contacter le service juridique. Bien sûr, une évaluation a une date d'expiration, mais elle peut être utilisée dans certaines limites raisonnables.
En asynchronie, l'absence de garanties est généralement effrayante, c'est-à-dire le risque d'un résultat négatif dans l'une des branches parallèles du processus. Et si la réconciliation échoue?
Ici, vous avez besoin de statistiques. Si vous travaillez avec un processus existant, imaginez approximativement ou précisément à quelle fréquence certaines actions se terminent négativement - par exemple, la coordination. C'est à partir de cette probabilité que l'on doit procéder en commençant l'exécution parallèle.
L'asynchronie demande directement tous les processus de coordination. Si vous n'y travaillez qu'en mode synchrone et suivez même l'exemple des coordinateurs, de longues chaînes interdépendantes se construisent, générant bureaucratie et responsabilité mutuelle.
Un exemple typique: "Je n'accepterai qu'après qu'il aura accepté." Ou "Je ne regarderai ce contrat qu'après les financiers." Bien que, selon les statistiques et le bon sens, de telles déclarations ne soient pas justifiées et ne sont qu'un moyen de déplacer la responsabilité.
L'essentiel ici n'est pas de s'inquiéter et de ne pas tout aborder d'un coup. Essayez de sélectionner le mode asynchrone d'abord une branche de coordination. Il peut être nécessaire de réviser la tâche, les paramètres de coordination - afin d'éliminer l'interdépendance.
Par exemple, laissez le service financier, faisant partie de la chaîne d'approbation des contrats, examiner uniquement les conditions de paiement. Qu'il ait ses propres critères d'évaluation clairs. Il est préférable qu'ils soient formalisés sous la forme d'un contrat type - par exemple, 100% de post-paiement pour les fournisseurs, 100% de prépaiement pour les acheteurs. Dans ce cas, les contrats qui répondent aux critères glisseront à la fois. Et les financiers n'auront aucune raison d'attendre une évaluation des mêmes avocats.
Seule chose importante: les processus asynchrones sont très difficiles à mettre en œuvre sans automatisation. Si les processus, leur exécution et leur suivi ne sont mis en œuvre que sur papier, l'ajout de branches parallèles les transformera en chaos. Besoin d'automatisation.
Le principe de "Auto Task" est le mieux adapté à une telle automatisation. Bien que vous puissiez vous en tirer avec les moyens standard de dessin des processus qui sont dans les plates-formes modernes, vous n'avez qu'à bricoler.
Le "dessin" standard des processus vous obligera à identifier l'ensemble du processus, toutes les branches et relations. Si le processus est complexe et long, vous rencontrerez un problème - il cessera simplement de tenir sur l'écran, en largeur. Si vous avez étudié à l'institut en tant que programmeur, souvenez-vous de cette règle pour concevoir des algorithmes: pas plus de trois branches verticales parallèles. La règle n'a pas seulement été inventée - s'il y a plus de branches, il sera difficile de comprendre le schéma de l'algorithme.
Les tâches automatiques éliminent ce problème - il n'y a aucune image du processus, car il n'y a pas une telle entité - un processus. Il y a des tâches. Si vous le voulez vraiment, vous pouvez assembler un processus à partir d'eux. Mais pas l'inverse. Une sorte de méthode déductive de processus de dessin.
En plus de l'asynchronie, il existe une méthode d'optimisation encore plus puissante - la mise en mémoire tampon des processus. À propos de lui - une autre fois.