Bon après-midi
Je veux offrir une petite excursion dans l'application pratique de la théorie des contraintes pour l'informatique. A savoir, en matière de calcul du «débit» du département de développement de logiciels internes d'entreprise.
À propos de la CBT (Theory of Constraints) et du méga-livre "Goal" d'Elia Goldratt, beaucoup a été écrit, y compris sur Habré, donc je vais aller droit au but.
Le département dont je suis en charge soutient et développe plusieurs soi-disant systèmes d'information "internes", dont les principaux sont le WMS et le TMS - systèmes de gestion d'entrepôt et de transport. De plus, je me concentrerai uniquement sur ces systèmes et sur une seule partie de l'entreprise - les services d'un opérateur logistique.
Chaque jour, une dizaine de nouvelles tâches sont déversées dans notre boîte aux lettres, nombre d'entre elles marquées "Urgent!", "Important!" etc.
À l'heure actuelle, l'arriéré est passé à environ sept cents tâches de différentes catégories de complexité.
Afin de gérer en quelque sorte ce volume, nous avons mis en place un système de priorités, en fonction du degré d'influence sur l'entreprise:
A - défaillances du système ou problèmes qui ne permettent pas de remplir pleinement les obligations contractuelles (pour l'activité principale).
B - tâches liées à la croissance des revenus de l'entreprise - c'est-à-dire l'arrivée de nouveaux clients.
C - tâches liées à l'amélioration de la rentabilité, c'est-à-dire des tâches pour optimiser la productivité (total - systèmes, processus de travail, personnes, croissance de la production, etc.).
D - améliorations à la demande de nos clients (rapports, intégration avec les entreprises de transport, etc.).
Au sein de ces catégories, il existe un autre niveau de division (A1, A2, ...), mais pour les besoins de l'article d'aujourd'hui, ce n'est pas essentiel.
Logiquement, l'exécution des tâches doit être organisée dans l'ordre: ABCD.
En pratique, un plan de développement est le résultat d'un grand nombre de compromis. À titre d'exemple, les tâches de catégorie D arrivent souvent tout en haut de l'arriéré (orientation client, oui).
Autrement dit, le système de priorité ne donne qu'une orientation générale pour la planification, mais ne permet pas à chacun de répondre objectivement à la question: "Pourquoi ma tâche ne prend-elle pas autant de temps?"
Nous avons également le problème des petits et grands clients, qui dépensent environ la même ressource informatique. Théoriquement, les gros clients devraient être une priorité, mais vous ne devriez pas non plus en laisser de petits, de plus, un petit nécessite très souvent une attention particulière, comme s'il expédiait non pas deux gazelles par semaine, mais au moins un train de conteneurs.
En comprenant cela et en comprenant que l'entreprise est une organisation commerciale, pas un organisme de bienfaisance, et en premier lieu doit être rentable, nous avons décidé de pomper le système de planification en utilisant la théorie des restrictions.
La limitation dans notre cas est la ressource de développement.
CBT introduit un nouveau concept de débit commercial, un «taux de génération de revenus» conditionnel, qui devrait être continuellement augmenté. Contrairement aux coûts, la croissance du passage n'est théoriquement limitée par rien et peut (peut) tendre à l'infini.
Dans le cas des développeurs, nous utiliserons le retour sur les heures-homme, en roubles, comme mesure de passage.
L'algorithme est quelque chose comme ceci:
- Pour chaque tâche, il est nécessaire d'évaluer l'effet économique de la mise en œuvre. Cela peut être une économie d'heures de travail des cols bleus, ou une autre ressource (par exemple, des mètres carrés rares dans la zone d'expédition, ou des emplacements de palette dans la zone de stockage, ou des heures de chargement). Souhaitable, en milliers de roubles / an. Le client doit effectuer une telle évaluation. S'il ne peut pas le faire lui-même, il contactera alors son superviseur.
- Une fois la tâche évaluée en termes d'effet, elle est renvoyée à l'étude Timlid ou à l'un des signataires. En conséquence, nous obtenons une certaine estimation préliminaire des coûts.
- En divisant le premier par le second, nous obtenons le passage même - la vitesse de réalisation de l'effet.
- Nous classons les tâches dans l'arriéré par ordre décroissant de passage.
- Coupez un morceau de carnet de commandes au-dessus du prochain plan / sprint.
Par exemple, il y a un problème dont l'effet est estimé à 100 000 roubles par le client. par mois, soit 1,2 million de roubles. par an.
Pour notre part, la mise en œuvre nécessitera 40 heures de développement.
Le laissez-passer sera donc de 1200/40 = 30 unités conventionnelles.
Pour une autre tâche, l'effet attendu de 50 mille roubles. par mois, mais sa mise en œuvre prendra 100 heures. Total, 600 mille roubles / 100 = 6 c.u.
Au final, nous ferons les deux tâches. Mais d'abord le premier, puis le second.
Revenant aux catégories prioritaires, nous formons un flux de correction séparé (catégorie A), puis lançons de nouveaux clients (les tâches sont planifiées en fonction des délais existants), et le reste du temps est bombardé par le développement d'un nouveau système d'évaluation des passes.
L'avantage de cette technologie est qu'elle est objective. Même avec toutes les hypothèses - comment le client a estimé l'effet, les inexactitudes dans l'évaluation de la complexité, le niveau du développeur qui le mettra en œuvre - cela donne une image réelle des tâches importantes et sans importance d'un point de vue commercial.
Et qu'en est-il de la catégorie D, demandez-vous? Comment le client souhaite-t-il, surtout les petits? Comment s'inscrivaient-ils dans le nouveau schéma?
Cette question est toujours ouverte.
Pour construire une image objective, il faut aussi en évaluer l'effet économique, mais, conditionnellement parlant, indirect. Autrement dit, la réputation de l'entreprise, l'orientation client, la croissance potentielle de l'activité de ces clients, attirant de bonnes références. Il y a des questions plus subtiles, nous discutons avec les ventes et le service client de la manière de numériser ces indicateurs.
Le but ultime est d'obtenir un système objectif transparent de tâches de construction qui vous permettra de maximiser l'utilisation des ressources de développement. Peut-être, en tant qu'harmonie, on ne peut que lutter pour cela, cependant, la théorie des restrictions déclare sans équivoque que le «but» est réalisable.
Quelque chose comme ça.
Par la préparation de la prochaine partie du rébus, je partagerai le résultat.
PS Pour l'instant, les problèmes de refactoring et diverses tâches d'infrastructure sont laissés de côté, nous y reviendrons plus tard.