Iceberg

Tout le monde sait ce qu'est un iceberg - un gros morceau de glace qui flotte dans l'océan. Tout le monde se souvient de ce qui ne va pas avec l'iceberg - seule une petite partie est visible, au-dessus de la surface de l'eau, le reste est caché. Et combien est là, ce repos - personne ne sait.

Une situation similaire concerne les données dans les systèmes automatisés.

Nous voyons généralement les données elles-mêmes. Documents, tels que factures de livraison ou de réception, virements, paiements, etc. Répertoires - nomenclature, contreparties, unités. Nous voyons les tâches, à la fois ordinaires et de processus. Nous voyons les restes - combien de marchandises sont en stock, qui nous doit de l'argent, combien de déficits nous avons, etc.

Toutes les données, individuellement ou en combinaison, forment un certain état. Par exemple, notre entrepôt, à chaque instant, est dans un certain état. Nous le disons - l'état de l'entrepôt. Ou le statut des créances ou des dettes, ou le statut des tâches, ou le statut des processus.

Nous sommes tout à fait capables d'évaluer instantanément l'état - à la fois dans un système automatisé et dans la vie. Estimé, s'enfuit et oublié.

Puis, après un certain temps, nous rencontrons à nouveau les mêmes données, ou situation. Nous faisons à nouveau une évaluation instantanée de l'état - nous disons «tout est bon» ou «tout est mauvais». Cela se répète une deuxième, troisième, cent vingt-cinquième fois.

Si nous évaluons la situation comme critique, alors, probablement, nous la corrigerons d'une manière ou d'une autre. Et sinon? Oui, la situation n'est pas très bonne, mais il semble que vous puissiez vivre. Cela se produit souvent lors de réunions opérationnelles - quelqu'un pose une question, raconte la situation, donne une évaluation. Tout le monde gémit, ou claque sa langue et ... quoi? En règle générale, ils oublient. Jusqu'à la prochaine fois, jusqu'à ce que quelqu'un d'autre fasse attention.

Chaque fois qu'une situation négative devient indulgente, parce que nous la voyons comme si c'était la première fois. Quelqu'un, bien sûr, se souvient - oh, c'est déjà arrivé, je ne me souviens pas, comme il y a un mois, ou peut-être six mois. Ils piquent sur le titulaire d'une trop bonne mémoire pour garder le silence - que la situation soit considérée comme aussi propre qu'un bébé.

Pourquoi cela se produit-il? Que manque-t-il dans les informations de situation négatives? Il y a une évaluation instantanée, de très bonne qualité et détaillée. Comment continuer l'expression «tout est mauvais ici» pour qu'elle joue avec de nouvelles couleurs et devienne plus informative?

Il est très simple de continuer la phrase: "tout va mal ici, et pour longtemps". Le temps ou la durée de l'état sont les informations nécessaires à une décision adéquate.

Dans la vie, tout le monde comprend cela. Permettez-moi de vous donner quelques exemples.

«Je n'ai pas assez d'argent» - une évaluation instantanée, nécessite une intervention chirurgicale. «Je n'ai pas assez d'argent depuis un an maintenant» - wow, nous avons ici un problème systémique, sur lequel nous devons réfléchir sérieusement et changer quelque chose dans la vie.

«Quelque chose me fait mal à la jambe» - eh bien, on ne sait jamais, il a peut-être purgé sa peine ou le temps affecte l'arthrite. «Ma jambe est endolorie depuis six mois maintenant» - aussitôt couru à la clinique.

«Un enfant a apporté un diable» - bien joué, il est grand temps, des dieux sont nécessaires pour l'équilibre. "Un enfant n'apporte que deux pour tout le quartier" - oh, espèce de crétin mineur, qu'est-ce que tu fais là, demain je vais à l'école, où est le numéro de téléphone de ton professeur.

De même dans les systèmes d'entreprise.

«Le client nous doit un million» - eh bien, payez ce que vous harcelez. «Le client nous doit un million depuis six mois maintenant» - ta mère, où as-tu regardé?

«Il y a cinq positions urgentes dans l'état de déficit» - ordonnera les acheteurs, c'est pourquoi les gens ne devraient pas être tirés. «Cinq positions urgentes sont en déficit depuis deux mois maintenant» - c'est pourquoi les ventes sont en baisse! Glissez de toute urgence tout le monde sur le tapis, achetez immédiatement!

"Les programmeurs ont dépassé ma tâche" - oui, ils ont tous des tâches donc, ne vous inquiétez pas. Fera. «Les programmeurs ont déjà dépassé ma tâche depuis deux mois» - bon sang, je veux depuis longtemps disperser ces connards, que font-ils là du tout?

Comme vous pouvez le voir, la durée d'une condition, en particulier négative, donne à l'information une nouvelle dimension. C'était comme s'il y avait des informations plates et ennuyeuses avec lesquelles on ne savait pas quoi faire, mais une image en trois dimensions a été obtenue. Analyser une situation et prendre une décision devient beaucoup plus facile.

Tout est si évident ici que je ne peux même pas y croire - ces banalités valent-elles un chapitre séparé dans le manuel? Pour répondre à cette question, jetez un œil à votre système d'information.

Trouvez-vous de nombreuses conditions avec une durée mesurée? Traditionnellement, il existe deux rapports basés sur le principe Iceberg: les actifs non liquides et les arriérés. Au fait, voyez-vous des actifs non liquides? Pas dans tous les systèmes, même communs, des actifs illiquides peuvent être vus.

Malheureusement, dans les systèmes d'information, il n'y a même pas de concept d '«État». Il existe des données et des moyens de les visualiser sous différents angles. Une étendue chic pour un analyste qui aime fouiller dans de grands tableaux de chiffres, mais pas assez d'informations sensibles pour prendre des décisions. De plus, peu importe qui prend la décision - la personne ou le système lui-même.

Il existe plusieurs façons de mettre en œuvre le principe Iceberg. Traditionnel - comptabilité par lots, lorsqu'un séparateur est ajouté au tableau d'informations - un document par lots. Par exemple, les marchandises sont arrivées à l'entrepôt - nous nous souvenons non seulement de la nomenclature et de la quantité, mais aussi du document de réception - la facture. La facture a une date et nous pouvons toujours calculer la date d'échéance. Ils font de même, par exemple, avec les créances - ils stockent non seulement la contrepartie et le montant, mais également le document qui a créé cette dette - par exemple, une facture de livraison ou un paiement anticipé au fournisseur.

Sur le plan technique, le document du parti crée de nombreuses difficultés.

Premièrement, cela augmente le nombre d'enregistrements dans les tableaux. Une entrée «Sleeve, 10 pieces» peut se transformer en dix entrées - «Sleeve 1 pc from 09/01/2017», «Sleeve 1 pc from 12/09/2017», etc.

Deuxièmement, des algorithmes d'annulation de lots sont nécessaires. Par exemple, lors de l'expédition (c'est-à-dire la radiation de marchandises), vous devez savoir de quel lot moins le reste. Ou lorsque vous payez de l'acheteur, vous devez indiquer pour quel document d'expédition l'argent est venu. Deux approches sont utilisées: soit le calcul automatique des lots, soit leur indication manuelle. La sélection automatique des lots sont les stratégies de radiation bien connues de FIFO (premier, le premier lot) et LIFO (premier, le dernier lot). L'identification manuelle des lots est couramment utilisée pour enregistrer les paiements.

Le troisième problème, plutôt méthodologique, est que la vraie vie n'obéit pas à l'algorithme de radiation des lots. Le commerçant prendra la pièce de l'étagère, mais pas celle que le programme a sélectionnée. Il ne sait pas ce qu'est le FIFO.

Il en résulte un système techniquement complexe, dont les résultats sont rarement utilisés. Je ne parle pas de comptabilité ou de comptabilité de gestion, qui utilise beaucoup pour calculer le coût des radiations. Je parle de mesurer la durée d'un état négatif - les actifs non liquides. Combien avez-vous dû voir réellement, régulièrement et efficacement les processus de travail sur les actifs non liquides?

La deuxième façon n'est pas de stocker la durée de tous les états, mais de la calculer si nécessaire. Il s'agit d'une estimation instantanée de la durée. Par exemple, on peut trouver des actifs non liquides dans un entrepôt sans stocker de lots. Il existe de nombreuses façons - par exemple, comprendre les soldes actuels, examiner rétrospectivement le mouvement des marchandises. S'il n'y a pas eu de mouvements, alors devant nous est un atout non liquide.

Cette méthode n'a pas les inconvénients de la comptabilité par lots - elle ne nécessite pas le stockage de grandes quantités de données et ne complique pas le travail en cours. Mais le principal avantage de la comptabilité par lots - le stockage de la durée - n'y est pas. Vous ne voyez une estimation de la durée qu'instantanément, à un moment donné. Nous sommes entrés, regardés, appréciés, sortis - l'évaluation de la durée a disparu.

D'une part - d'accord, c'est d'accord. Vous pouvez prendre un algorithme pour calculer la durée et l'intégrer dans les processus - laissez le système réagir lorsque l'état négatif s'est prolongé. Mais, hélas, l'estimation instantanée de la durée n'est pas si instantanée - les ressources du système sont dépensées pour le calcul de sorte que seul le bruit coûte, chaque minute que vous n'exécutez pas.

Une estimation instantanée de la durée peut être utilisée pour des processus peu importants qui n'ont pas besoin d'être surveillés quotidiennement. Par exemple, les mêmes actifs non liquides lorsque vous créez le processus d'élimination - une fois par mois, vous effectuez des calculs, déterminez la liste des articles les plus accumulés et formez-vous la tâche de les éliminer (par exemple, vendre à rabais ou mettre au rebut).

La troisième méthode consiste à calculer, séparer, stocker et suivre le statut de recadrage.

Par exemple, vous avez un état de déficit - une liste de biens que vous devez acheter. Pour la production, les ventes, les réparations, etc. Cela n'a aucun sens de surveiller l'intégralité de l'état de déficit - des positions assez expirées. Ces positions passées méritent d'être soulignées, car il n'y en aura pas beaucoup?

Il vous suffit de sauvegarder dans un endroit séparé du système une liste d'articles périmés, avec les quantités et, surtout, la date d'occurrence. Après tout, il n'y a pas toujours de postes expirés? Dès qu'ils apparaissent - rappelez-vous, et la date d'apparition sera le point de départ de la durée.

Ensuite, le système fait tout par lui-même. Examine périodiquement le déficit - vérifie s'il y a des positions expirées. Sinon, excellent, alors l'état négatif s'est arrêté. La liste enregistrée des positions en retard peut être oubliée et supprimée du système (ici, à votre discrétion, vous pouvez la laisser en mémoire, c'est-à-dire pour une analyse rétrospective ou un système de motivation). Si les positions expirées sont toujours en nombre insuffisant, c'est également bon (pour le système), car vous n'avez rien à faire, l'horloge tourne et la durée s'allonge.

Une personne qui surveille un déficit en souffrance sera simplement heureuse. Premièrement, il ne peut plus garder un œil sur - il suffit de configurer une notification sur le retard. Deuxièmement, vous n'avez plus besoin de déterminer si le retard est apparu depuis longtemps - la durée sera affichée automatiquement. Troisièmement, il n'est pas nécessaire de suivre le moment de la disparition du retard - le système vous permettra de savoir quand tout va bien.

En tant que programmeur d'entreprise, il vous sera beaucoup plus facile de créer des processus de réponse dans un système d'entreprise. Bien qu'il n'y ait aucune compréhension de la durée, vous êtes obligé de tirer la personne immédiatement, dès qu'un état négatif est apparu. Et votre «contraction» pendre constamment devant votre nez, comme un chiffon rouge.

Quand il y a une durée, le réglage devient plus fin - vous choisissez vous-même le moment où montrer à une personne un problème. Vous pouvez également choisir un affichage couleur en fonction de la durée de l'état négatif. Par exemple, jaune - un jour, rouge - deux jours ou plus, etc.

Dans le même temps, vous pouvez créer un système de réponse en amont. Par exemple, montrez d'abord le retard du déficit au fournisseur. Un jour plus tard, sinon éliminé, au chef des approvisionnements. Trois jours plus tard, au directeur commercial. Dans une semaine - au directeur.

De plus, vous comprenez: son essence dépend du niveau auquel la tâche a augmenté. Vous demandez au fournisseur d'éliminer le retard - il doit commander le poste. Vous demandez au responsable de l'approvisionnement de faire attention et, éventuellement, de transférer les postes à un autre fournisseur. Vous dites au directeur que l'ensemble du service d'approvisionnement fonctionne étrangement, des changements de système sont nécessaires.

Principales caractéristiques de cette méthode: stockage séparé des données d'état et leur mise à jour automatique. Techniquement mis en œuvre en utilisant le principe de "Auto Task", qui sera discuté plus tard.

Dans le processus, vous trouverez sûrement d'autres façons de déterminer la durée de l'état, c'est-à-dire l'ampleur de l'iceberg sous-marin. Vous pouvez programmer dans des systèmes où les méthodes que j'ai énumérées ne fonctionnent pas - alors vous devez chercher les vôtres.

L'essentiel - n'oubliez pas le principe de "Iceberg" lors de la programmation d'un système d'entreprise.

Surtout si vous souhaitez utiliser la comptabilité des partitions - elle doit être décontractée lors de la conception, rétrospectivement, elle est déployée avec beaucoup de difficulté.

Une évaluation instantanée de la durée, comme les «tâches automatiques», peut être incluse à tout moment. Eh bien, éteignez-le aussi. Dans cette légèreté est leur avantage.

Je vais donner quelques exemples d'utilisation de l'iceberg de ma pratique.

Le premier exemple est les systèmes de gestion des tâches. Il y a une tâche, une affectation ou un mémo. Il y a un initiateur, il y a un interprète. Lorsque la tâche est acceptée dans le travail, tout est clair - il y a un délai, et vous pouvez rapidement déterminer si tout ce qui est avec la tâche est bon ou non.

Mais le problème a également des états intermédiaires. Par exemple, l'initiateur l'a écrit, l'a envoyé et l'exécuteur doit l'accepter pour le travail. L'acceptation au travail est un certain signe dans une tâche. Jusqu'à ce que l'entrepreneur le pose, l'état de la tâche est la partie sous-marine de l'iceberg. Pas une putain de chose n'est claire quand il daigne enfin le faire.

J'ai agi simplement - j'ai ajouté la date d'acceptation pour travailler comme un champ séparé dans la tâche. Accepté - la date a été mémorisée. Et la date d'envoi de la tâche à l'exécuteur est déjà là. En conséquence, nous obtenons deux durées d'un état négatif. Jusqu'à ce que la tâche soit acceptée, la durée est la différence entre la date actuelle et la date d'expédition. Lorsque, néanmoins, l'entrepreneur l'a acceptée, l'intervalle exact entre l'acceptation et l'envoi apparaît, qui est toujours mémorisé dans le système et utilisé pour une analyse plus approfondie.

Une situation similaire, d'une durée incompréhensible, se produit lorsque l'entrepreneur a effectué les travaux et les a envoyés à l'initiateur pour vérification. Quand il s'y rend, on ne sait pas. Tout programmeur décent travaillant directement avec l'utilisateur final confirmera que les tâches se bloquent très souvent lors du test. De plus, physiquement cela peut déjà être vérifié, l'utilisateur aime tout, mais il ne prend pas la peine de se connecter au système et de noter.

La solution est similaire. Nous ajoutons deux dates à la tâche - lorsque l'entrepreneur a envoyé pour vérification et que l'initiateur a réagi, il a accepté le résultat ou est retourné pour révision. Par conséquent, la durée de l'état de vérification est toujours à portée de main et nous pouvons normaliser le temps de vérification de la tâche. Eh bien, ce n'était pas le cas.

Mon exemple préféré est l'approvisionnement. Tout est simple avec des tâches - il y a toujours un certain objet dans lequel cette tâche même est enregistrée, et vous pouvez ajouter des champs stockant des données sur la durée de l'état à cet objet.

Et l'approvisionnement est un flux. Personne là-bas, dans son bon sens, ne posera de tâches distinctes. Eh bien, imaginez-vous - une fille est assise et commande des bagues. Tous les jours. Les mêmes bagues. Et aussi des arbres, boulons, écrous, métal, pièces forgées, estampages, etc.

Il n'y a que des informations sur ce qui doit être commandé. Oui, cela se produit à différents niveaux de détail - parfois simplement une liste d'articles et de quantités, parfois - par les destinataires, les entrepreneurs, les commandes, les unités, etc. Mais ces informations sont toujours instantanées, comme un flash. Je suis entré - vous voyez, vous devez commander 1020 pièces. Une minute plus tard, il est entré - wow, il est déjà 1200, car la situation a changé.

Les acheteurs comprennent cela et en profitent. Lors des réunions, des débriefings et des agents, les acheteurs sont souvent tentés d'aller au fond, mais d'eux, comme de l'eau sur un canard. Ils leur disent - euh les gars, et quelles bagues manquent? Alors hier, seul un besoin est apparu! - réponds à ceux-là. Comment va hier? Eh bien, hier. Je jure que je suis entré en pénurie le matin dernier, il n'y avait pas de buissons!

Pour prouver que les pochettes étaient hier, vous ne pouvez qu'en soulevant la sauvegarde. Bien sûr, les gens vivants ne récupèrent pas les sauvegardes tous les jours, donc les vendeurs et fabricants fatigués proposent leur propre version de l'Iceberg - les impressions. Par exemple, ils entrent dans le système lundi, examinent le déficit et l'impriment. Quand un problème survient, ou des râpes avec les fournisseurs, montrez-leur ce morceau de papier.

Mais il est facile d'esquiver un tel morceau de papier. Les vendeurs disent - que me glissez-vous ici? Oui, il n'y avait pas assez de manches lundi, alors quoi? Déjà mardi, il y en avait tellement que tout le monde en aurait eu beaucoup! Et ce que vous voyez dans le système aujourd'hui n'est survenu qu'hier.

Ensuite, ils sont également contraints de participer aux affaires papier - ils n'impriment pas seulement une pénurie, mais donnent également les fournisseurs pour signature. Et les dates de livraison sont demandées à apposer. Vous comprenez que le processus en termes d'efficacité est très moyen.

Le principe Iceberg travaillait dans les tâches, mais pas dans l'approvisionnement. Les vendeurs ont compris que quelque chose devait être fait et ont commencé à définir des tâches pour les achats - ils ont directement créé l'objet, y ont joint une liste de positions et ont attendu l'exécution. Au début, cela a commencé à fonctionner, puis les fournisseurs ont commencé à rejeter stupidement de telles tâches, avec un commentaire tel que "nous n'avons pas besoin de mettre des instructions séparées pour notre travail de routine". En général, le commentaire correct est que si vous définissez une tâche pour tout le monde, les nettoyeurs devront être connectés au système.

Le problème a été résolu par les tâches automatiques et Iceberg, qui est là par défaut. L'autotâche sent simplement un déficit, décompose les positions manquantes par les interprètes et forme des objets contenant des informations sur ce qui doit être commandé auprès des fournisseurs. La date de formation automatique de la tâche est fixée automatiquement, ainsi que la date d'exécution, c'est-à-dire placement de postes chez les fournisseurs.

S'il était nécessaire, par exemple, 100 douilles et que le fournisseur en a commandé 70, la tâche automatique ne se ferme pas, mais est simplement ajustée - vous devez maintenant placer 30 positions. Ce qui est important, c'est la date de début de l'état négatif, c'est-à-dire le déficit reste le même. Une personne a commandé 70 postes pour un intervalle de temps et 30 pour un autre.

Avec l'application de l'Iceberg, le problème a été résolu très rapidement, car il était impossible de cacher quoi que ce soit. D'une part, la comptabilisation de la durée du déficit est réalisée dans le cadre des positions et des quantités, et d'autre part, en référence au contractant. , , KPI – (, , ).

. – - - . , , . , . , .

, , . , , . – , , , , , , , - . , , – , – , .

, . , – , , ! – , , , . , . – , – , .. – . , , .

, , . – . , .

, , , . , – , , , , , .

, . – , , . , , – .

, . – , , , , . , , , – . - , , , , , , , – .

, , : - , . – .

– . – , , , , , . , , , .

, . , – . , , – , . – , , , , , , . , , , . – , . , , . Eh bien et ainsi de suite.

, . , , , , , . , .

, , , , . , , – , «». , .

, – - , . , , , - .

. – , . , .

, – , , . , 90 %.

, , – , , . , , .

, , . – , , . – , , .

, , . , 100 -. , . , , . , , , . , .