Iceberg

Todo mundo sabe o que é um iceberg - um grande pedaço de gelo que flutua no oceano. Todo mundo se lembra do que há de errado com o iceberg - apenas uma pequena parte dele é visível, que está acima da superfície da água, o resto está escondido. E quanto há, esse resto - ninguém sabe.

Uma situação semelhante é com dados em sistemas automatizados.

Normalmente, vemos os dados em si. Documentos, como faturas de entrega ou recebimento, transferências, pagamentos etc. Diretórios - nomenclatura, contrapartes, unidades. Vemos as tarefas, comuns e de processo. Vemos os restos mortais - quantos bens há em estoque, quem nos deve dinheiro, quantos déficits temos etc.

Quaisquer dados, individualmente ou em combinação, formam um determinado estado. Por exemplo, nosso armazém, a todo momento, está em algum estado. Dizemos que sim - o estado do armazém. Ou o status de contas a receber, ou contas a pagar, ou o status de tarefas ou o status de processos.

Somos capazes de avaliar instantaneamente a condição - tanto em um sistema automatizado quanto na vida. Estimado, fugir e esquecer.

Depois de algum tempo, encontramos novamente os mesmos dados ou situação. Novamente fazemos uma avaliação instantânea do estado - dizemos "tudo é bom" ou "tudo é ruim". Isso é repetido uma segunda, terceira, cento e vigésima quinta vez.

Se avaliarmos a situação como crítica, provavelmente iremos corrigi-la. E se não? Sim, a situação não é muito boa, mas parece que você pode viver. Isso geralmente acontece em reuniões operacionais - alguém levanta uma pergunta, conta a situação, faz uma avaliação. Todo mundo geme, ou barulho de língua e ... o quê? Como regra, eles esquecem. Até a próxima vez, até que alguém preste atenção.

Toda vez que uma situação negativa recebe indulgência, porque a vemos como se fosse a primeira vez. Alguém, é claro, lembra - ah, isso já aconteceu, não me lembro, como um mês atrás, ou talvez seis meses. Eles cutucam o suporte de uma memória boa demais para ficar em silêncio - deixe a situação ser considerada melhor e limpa como um bebê.

Por que isso está acontecendo? O que está faltando nas informações da situação negativa? Há uma avaliação instantânea, de alta qualidade e detalhada. Como continuar a frase “tudo está ruim aqui”, para que ela brinque com novas cores e se torne mais informativa?

É muito simples continuar a frase: "tudo está ruim aqui e por muito tempo". O horário ou a duração do estado são as informações necessárias para uma decisão adequada.

Na vida, todo mundo entende isso. Deixe-me dar alguns exemplos.

"Não tenho dinheiro suficiente" - uma avaliação instantânea requer intervenção cirúrgica. “Não tenho dinheiro suficiente há um ano” - uau, temos um problema sistêmico aqui, no qual precisamos pensar muito e mudar alguma coisa na vida.

"Algo machuca minha perna" - bem, você nunca sabe, ele pode ter cumprido pena ou o tempo afeta a artrite. "Minha perna está dolorida há seis meses" - corra imediatamente para a clínica.

“Uma criança trouxe um empate” - bem feito, é mais do que tempo, empates são necessários para o equilíbrio. "Uma criança traz apenas dois para o quarto inteiro" - oh seu idiota é menor de idade, o que você está fazendo aí, amanhã eu vou para a escola, onde está o número de telefone do seu professor da turma.

Da mesma forma em sistemas de negócios.

"O cliente nos deve um milhão" - bem, pague o que você incomoda. “O cliente nos deve um milhão por seis meses agora” - sua mãe, onde você olhou?

“Existem cinco posições urgentes na declaração de déficit” - os compradores vão pedir, e é por isso que as pessoas não devem ser puxadas. “Cinco posições urgentes estão em déficit há dois meses” - é por isso que as vendas estão caindo! Arraste todos urgentemente para o tapete, compre imediatamente!

"Programadores venceram minha tarefa" - sim, todas elas são executadas, então não se preocupe. Vai fazer. “Os programadores já vencem minha tarefa há dois meses” - caramba, eu sempre quis dispersar esses idiotas, o que eles estão fazendo lá?

Como você pode ver, a duração de uma condição, especialmente uma negativa, fornece às informações uma nova dimensão. Era como se houvesse informações chatas e chatas com as quais não estava claro o que fazer, mas foi obtida uma imagem tridimensional. Analisar uma situação e tomar uma decisão se torna muito mais fácil.

Tudo é tão óbvio aqui que eu nem consigo acreditar - essas banalidades valem um capítulo separado no livro? Para responder a essa pergunta, dê uma olhada no seu sistema de informação.

Você encontra muitas condições com duração medida? Tradicionalmente, existem dois relatórios baseados no princípio Iceberg: ativos ilíquidos e atrasados. A propósito, você vê ativos ilíquidos? Nem todos, mesmo sistemas comuns, podem ser vistos ativos ilíquidos.

Infelizmente, nos sistemas de informação não existe sequer um conceito de “estado”. Existem dados e meios de visualizá-los, de diferentes ângulos. Uma expansão chique para um analista que gosta de vasculhar grandes quantidades de números, mas não possui informações suficientes para tomar decisões. Além disso, não importa quem toma a decisão - a pessoa ou o próprio sistema.

Existem várias maneiras de implementar o princípio Iceberg. Contabilidade em lote tradicional, quando um separador é adicionado à matriz de informações - um documento em lote. Por exemplo, as mercadorias chegaram ao armazém - lembramos não apenas a nomenclatura e quantidade, mas também o documento de recebimento - a fatura. A fatura tem uma data e, a partir dela, sempre podemos calcular a data de vencimento. Eles fazem o mesmo, por exemplo, com recebíveis - eles armazenam não apenas a contraparte e o valor, mas também o documento que criou essa dívida - por exemplo, uma fatura de entrega ou um adiantamento ao fornecedor.

Em termos técnicos, o documento da parte cria muitas dificuldades.

Em primeiro lugar, aumenta o número de registros nas tabelas. Uma entrada "Manga, 10 peças" pode se transformar em dez entradas - "Manga 1 peça a partir de 09/01/2017", "Manga 1 peça a partir de 12/09/2017" etc.

Em segundo lugar, são necessários algoritmos de cancelamento em lote. Por exemplo, ao enviar (ou seja, baixa de mercadorias), é necessário saber de qual lote menos o restante. Ou, ao pagar do comprador, é necessário indicar para qual documento de remessa o dinheiro veio. Duas abordagens são usadas: cálculo automático de lotes ou indicação manual. A seleção automática de lotes são as estratégias de cancelamento conhecidas do FIFO (primeiro, o primeiro lote) e LIFO (primeiro, o último lote). A identificação manual de lotes é normalmente usada no lançamento de pagamentos.

O terceiro problema, bastante metodológico, é que a vida real não obedece ao algoritmo de cancelamento de lote. O lojista tirará a parte da prateleira, mas não a que o programa selecionou. Ele não sabe o que é FIFO.

Acontece que um sistema tecnicamente complexo, cujos resultados raramente são usados. Não estou falando de contabilidade ou contabilidade gerencial, que usa muito para calcular o custo das baixas contábeis. Estou falando de medir a duração de um estado negativo - ativos ilíquidos. Quantos você teve que ver processos de trabalho real, regular e eficaz em ativos ilíquidos?

A segunda maneira não é armazenar a duração de todos os estados, mas calculá-la, se necessário. Esta é uma estimativa instantânea da duração. Por exemplo, é possível encontrar ativos ilíquidos em um armazém sem armazenar lotes. Existem várias maneiras - por exemplo, entender os saldos atuais, analisar retrospectivamente o movimento de mercadorias. Se não houve movimentos, então diante de nós há um ativo ilíquido.

Esse método não tem as desvantagens da contabilidade de lotes - não requer o armazenamento de grandes quantidades de dados e não complica o trabalho atual. Mas a principal vantagem da contabilidade de lotes - armazenamento de duração - não está nela. Você vê uma estimativa da duração apenas instantaneamente, em um momento específico. Entramos, parecemos, apreciamos, saímos - a avaliação da duração desapareceu.

Por um lado - tudo bem, tudo bem. Você pode usar um algoritmo para calcular a duração e incorporá-lo nos processos - deixe o sistema reagir quando o estado negativo se arrastar. Mas, infelizmente, uma estimativa instantânea da duração não é tão instantânea - os recursos do sistema são gastos em cálculos para que apenas o ruído custe, você não fica a cada minuto.

Uma estimativa instantânea da duração pode ser usada para processos não muito importantes que não precisam ser monitorados todos os dias. Por exemplo, os mesmos ativos ilíquidos quando você cria o processo de descarte deles - uma vez por mês, faz cálculos, determina a lista dos itens mais acumulados e forma a tarefa de descartá-los (por exemplo, vender com desconto ou sucateamento).

A terceira maneira é calcular, separar, armazenar e acompanhar o status de recorte.

Por exemplo, você tem uma declaração de déficit - uma lista de mercadorias que você precisa comprar. Para produção, vendas, reparos, etc. Não faz sentido monitorar toda a declaração de déficit - posições bastante expiradas. Vale ressaltar essas posições passadas, porque não haverá muitas?

Apenas salve em um local separado no sistema uma lista de itens expirados, com quantidades e, o mais importante, a data da ocorrência. Afinal, nem sempre há posições expiradas lá? Assim que aparecerem - lembre-se, e a data de aparecimento será o ponto de partida da duração.

Então o sistema faz tudo sozinho. Periodicamente verifica o déficit - verifica se há posições expiradas. Caso contrário, excelente, o estado negativo parou. A lista salva de posições vencidas pode ser esquecida e excluída do sistema (aqui, a seu critério, você pode deixá-la na memória, ou seja, para uma análise retrospectiva ou sistema de motivação). Se as posições expiradas ainda estiverem em falta, também é bom (para o sistema), porque você não precisa fazer nada, o tempo está passando e a duração está aumentando.

Uma pessoa que supervisiona um déficit em atraso simplesmente será feliz. Primeiro, ele não pode mais ficar de olho - basta configurar uma notificação sobre o atraso. Em segundo lugar, você não precisa mais descobrir se o atraso apareceu há muito tempo - a duração será mostrada automaticamente. Em terceiro lugar, não é necessário rastrear o momento do desaparecimento do atraso - o sistema informará quando as coisas correrem bem.

Será muito mais fácil para você, como programador de negócios, criar processos de resposta em um sistema de negócios. Embora não haja entendimento da duração, você é forçado a puxar a pessoa imediatamente, assim que um estado negativo surgir. E o seu "espasmo" ficará pendurado constantemente na frente do seu nariz, como um pano vermelho.

Quando há uma duração, a configuração se torna melhor - você mesmo escolhe o momento em que mostra a uma pessoa um problema. Você também pode escolher uma exibição colorida com base na duração do estado negativo. Por exemplo, amarelo - um dia, vermelho - dois ou mais dias etc.

Ao mesmo tempo, você pode criar um sistema de resposta upstream. Por exemplo, primeiro mostre o atraso no déficit para o fornecedor. Um dia depois, se não for eliminado, ao chefe de suprimentos. Três dias depois, para o diretor comercial. Em uma semana - para o diretor.

Além disso, você entende: sua essência depende do nível em que a tarefa subiu. Você pede ao fornecedor para eliminar o atraso - ele deve solicitar a posição. Você pede ao gerente de suprimentos que preste atenção e, possivelmente, transfira as posições para outro fornecedor. Você diz ao diretor que todo o serviço de suprimentos está de alguma forma funcionando estranhamente, são necessárias alterações no sistema.

Principais recursos deste método: armazenamento separado de dados de status e sua atualização automática. Tecnicamente implementado usando o princípio de "Tarefa automática", que será discutido mais adiante.

No processo, você certamente encontrará outras maneiras de determinar a duração do estado, ou seja, a magnitude do iceberg subaquático. Você pode estar programando em sistemas nos quais os métodos que listei não funcionam - então você precisa procurar por si próprio.

A principal coisa - não se esqueça do princípio de "Iceberg" ao programar um sistema de negócios.

Especialmente se você deseja usar a contabilidade de partições - ela precisa ser descontraída durante o design, retrospectivamente, é implantada com grande dificuldade.

Uma avaliação instantânea da duração, como as "AutoTasks", pode ser incluída a qualquer momento. Bem, desligue-o também. Nesta leveza é a sua vantagem.

Vou dar alguns exemplos de como usar o Iceberg da minha prática.

O primeiro exemplo são os sistemas de gerenciamento de tarefas. Há uma tarefa, uma tarefa ou um memorando. Há um iniciador, há um artista. Quando a tarefa é aceita no trabalho, tudo fica claro - há um prazo e você pode determinar rapidamente se tudo o que está com a tarefa é bom ou não.

Mas o problema também tem alguns estados intermediários. Por exemplo, o iniciador escreveu, enviou e o executor deve aceitá-lo para o trabalho. A aceitação no trabalho é um certo sinal em uma tarefa. Até que o contratado o anote, o estado da tarefa é a parte subaquática do iceberg. Nada é claro quando ele finalmente se digna a fazê-lo.

Eu agi simplesmente - adicionei a data de aceitação para trabalhar como um campo separado na tarefa. Aceito - a data foi lembrada. E a data de envio da tarefa ao executor já está lá. Conseqüentemente, temos duas durações de um estado negativo. Até que a tarefa seja aceita, a duração é a diferença entre a data atual e a data de envio. Quando, no entanto, o contratado a aceitou, aparece o intervalo exato entre aceitação e envio, que é lembrado para sempre no sistema e usado para análises posteriores.

Uma situação semelhante, com duração incompreensível, ocorre quando o contratado fez o trabalho e o enviou ao iniciador para verificação. Quando ele verifica lá, não se sabe. Qualquer programador decente que trabalhe diretamente com o usuário final confirmará que as tarefas geralmente congelam no teste. Além disso, fisicamente já pode ser verificado, o usuário gosta de tudo, mas não se preocupa em fazer login no sistema e fazer uma anotação.

A solução é semelhante. Adicionamos duas datas à tarefa - quando o contratado enviou para verificação e quando o iniciador reagiu, ele aceitou o resultado ou retornou para revisão. Assim, a duração do estado de verificação está sempre à mão e podemos normalizar o tempo de verificação da tarefa. Bem, então não foi.

Meu exemplo favorito é compras. Tudo é simples com as tarefas - sempre há um objeto no qual essa mesma tarefa é registrada, e você pode adicionar campos a esse objeto que armazenam dados sobre a duração do estado.

E compras é um fluxo. Ninguém lá, em sã consciência, apresentará tarefas separadas. Bem, imagine-se - uma garota está sentada, pedindo buchas. Todo dia As mesmas buchas. E também eixos, cavilhas, porcas, metais, peças forjadas, estampadas, etc.

Há apenas informações sobre o que precisa ser solicitado. Sim, isso acontece em diferentes níveis de detalhes - às vezes apenas uma lista de itens e quantidades, às vezes - por destinatários, contratados, pedidos, unidades etc. Mas essa informação é sempre instantânea, como um flash. Entrei - você vê, precisa encomendar 1020 peças. Depois de um minuto, entrei - oh, já em 1200, porque a situação mudou.

Os fornecedores entendem isso e se aproveitam disso. Nas reuniões, interrogatórios e agentes, os compradores costumam tentar chegar ao fundo, mas a partir deles, como a água de um pato. Eles dizem a eles - pessoal, e que buchas estão faltando? Então, ontem, apenas uma necessidade surgiu! - responda aqueles. Como está ontem? Bem ontem. Juro que entrei em escassez ontem de manhã, não havia arbustos!

Para provar que as mangas eram ontem, você pode apenas aumentando o backup. Obviamente, as pessoas vivas não pegam cópias de segurança todos os dias, então vendedores e fabricantes cansados ​​criam sua própria versão das impressões do Iceberg. Por exemplo, eles entram no sistema na segunda-feira, examinam o déficit e o imprimem. Quando surgir um problema, ou gratificações com fornecedores, mostre a eles este pedaço de papel.

Mas é fácil desviar de um pedaço de papel. Os vendedores dizem - em que você está me metendo aqui? Sim, não havia mangas suficientes na segunda-feira, e daí? Já na terça-feira havia tantos que todo mundo já teria bastante! E o que você vê no sistema hoje surgiu apenas ontem.

Depois, eles também são forçados a participar de assuntos de papel - eles não apenas imprimem uma escassez, mas também dão assinatura aos fornecedores. E as datas de entrega devem ser afixadas. Você entende que o processo em termos de eficiência é muito mais ou menos.

O princípio Iceberg trabalhou em tarefas, mas não no fornecimento. Os vendedores entenderam que algo precisava ser feito e começaram a definir tarefas para compras - eles criaram o objeto diretamente, colocaram uma lista de posições nele e aguardaram a execução. No começo, começou a dar certo, depois os fornecedores começaram a rejeitar estupidamente essas tarefas, com um comentário como "não precisamos colocar instruções separadas para o nosso trabalho de rotina". Em geral, o comentário correto é que, se você definir uma tarefa para todos, os produtos de limpeza precisarão ser conectados ao sistema.

O problema foi resolvido pelas tarefas automáticas e pelo Iceberg, que existe por padrão. O autotask simplesmente cheira a um déficit, quebra as posições ausentes pelos artistas e forma alguns objetos que contêm informações sobre o que precisa ser pedido aos fornecedores. A data de formação automática de tarefas é fixada automaticamente, bem como a data de execução, ou seja, colocação de posições com fornecedores.

Se fosse necessário, por exemplo, 100 buchas e o fornecedor encomendasse 70, a autotask não fecha, mas é simplesmente ajustada - agora você precisa colocar 30 posições. O importante é a data de início do estado negativo, ou seja, déficit permanece o mesmo. Uma pessoa encomendou 70 posições por um intervalo de tempo e 30 para outra.

Com a aplicação do Iceberg, o problema foi resolvido muito rapidamente, porque era impossível esconder qualquer coisa. Primeiro, a contabilização da duração do déficit é realizada no contexto de posições e quantidades e, segundo, com referência ao contratante.Imediatamente, é claro, um certo KPI nasceu para o fornecedor - qual a porcentagem de posições que ele ordena a tempo (parece que ele teve que cumprir o dia, a partir do momento em que a necessidade surgiu).

Iceberg cai bem em contabilidade. Para aqueles, afinal, sempre há algo errado em algum lugar. Saldos negativos estão presentes, em uma variedade de contas ou em registros que eles odeiam. Os avanços não são contados, apesar da aplicação da restauração da sequência de assentamentos. Sem mencionar os saldos totais sem quantidade e vice-versa.

No estado normal do sistema, sem um Iceberg, é difícil chegar ao departamento de contabilidade. A única maneira de provar que os contras estão suspensos há um mês é um backup. Mas eles também não são tolos - dirão que sim, houve contras há um mês, depois os removemos e agora saímos de novo, foram vocês os programadores que misturaram algo. Se os fornecedores simplesmente se desculpam sem mudar os problemas para os outros, os contadores pensam há muito tempo - não sei, conscientemente ou não - um método como a pressão artificial do tempo.

Há um programador decente na empresa que cuida do estado da contabilidade. Ele vê os contras nas costas e diz aos contadores - queridas tias, o que você está fazendo, vamos eliminá-lo! No início, eles dizem - sim, é claro, vamos eliminar, é do nosso interesse. Os contras nos atrapalharão muito ao fechar o trimestre, não se esqueça de eliminar. Neste momento - digamos, em maio - não há pressão de tempo, ou seja, ninguém tem um tempo limitado para resolver o problema. Portanto, a tarefa de restaurar a ordem, como esperado, é adiada para a caixa distante.

É quase impossível impedir a criação de resíduos negativos por métodos de monitoramento do trabalho diário atual. Mesmo se você proibir anulações negativas, há uma correção da paróquia. Portanto, nosso programador decente suspira e espera.

Antes do final de junho, o programador, por exemplo, lembra o contador várias vezes que seria bom remover os contras. Quanto mais próximo o prazo, mais agressiva a resposta se torna - foda-se, não é da sua conta, não nos ensina como trabalhar e, no final, completa desconsideração.

E então chegou julho, é necessário fechar o trimestre. Agora, o problema deve ser resolvido no modo de pressão de tempo - da maneira mais rápida e eficiente possível, porque ainda há muitas coisas a serem feitas, exceto os pontos negativos. Se você trabalhou como programador na fábrica, sabe o que está acontecendo neste momento - a tarefa muda rápida e lindamente da contabilidade para o programador.

É tarde demais para ficar indignado, embora os programadores estejam tentando. Mas os contadores dão argumentos de ferro - tudo, uma vez, é necessário entregar os relatórios, e há muuuitas multas que a empresa terá que ser fechada. Não resta mais nada para o líder que modera o abuso do programador e contador como tomar o lado dele - a ameaça parece real demais. O programador tem algo lamentando, como este é o trabalho de um contador, eles sabem o que fazer e, em geral, um programador custa à empresa três vezes mais que um contador, e tudo isso está errado, mas é tarde demais - um problema artificial no tempo foi criado.

Geralmente termina assim: o programador concorda em corrigir os desvantagens com as próprias mãos, e o gerente e o contador prometem resolver esse problema sistêmico após eliminar a pressão do tempo. E assim - sempre.

A solução para o problema é semelhante à oferta. Realizamos tarefas automáticas para cada variante do batente - por exemplo, calculamos e mostramos os pontos negativos na recuperação, definimos o responsável e, o mais importante, a data da tarefa para obter o Iceberg. Agora, assim que um sinal de menos é exibido, uma tarefa automática é exibida e pode ser usada como argumento em disputas.

É claro que a contabilidade ignorará essas tarefas. Mas então algo que falta ao programador nas reuniões com a gerência aparecerá - fatos. Aqui está o batente, aqui está a data de sua ocorrência, aqui está a duração do estado negativo - um mês, por exemplo. O principal é enviar as informações corretamente - olhe, querido líder, nossa contabilidade está em um estado incontrolável há um mês, não temos idéia de quanto custa nosso armazém, quanto incorremos em custos, porque temos desvantagens. Você entende, querido líder, o ponto não está nos pontos negativos, mas em relação à contabilidade. Menos é uma situação extrema, um erro óbvio e óbvio. E ainda existem implícitos que não são visíveis aos olhos, mas privam você da oportunidade de usar os dados. Bem e assim por diante.

Até o Iceberg solicita diretamente quaisquer processos em que haja acordo. Pedidos de gastar dinheiro, contratos, especificações, orçamentos, planos, emissão de roupas especiais e assim por diante, até o infinito.

Os burocratas amam a coordenação, mas não como um processo que precisa ser feito, mas como um processo que pode ser adiado infinitamente. O programador ingênuo, encarregado de adicionar a aprovação do contador ou diretor financeiro ao contrato, age de maneira simples e despretensiosa - ele adiciona um certo campo a esse contrato, como "Acordado". Ele não conhece Iceberg, portanto, condena o processo de negociação de acordos por uma morte lenta e dolorosa.

A coordenação será infinitamente dinâmica se o contrato não for muito significativo e não estiver no campo de visão do diretor. E os iniciantes dos tratados não terão escolha senão correr periodicamente para o contador principal para descobrir quando o grande sacramento acontecerá.

Iceberg resolve o problema imediatamente e rapidamente. Nesse caso, basta conhecer duas datas - quando foi enviado para aprovação e quando ocorreu. A duração do estado de inconsistência neste caso é calculada elementarmente, e você pode normalizar trivialmente esse tempo.

Fiz isso com a coordenação de contratos, onde a cadeia era composta por várias pessoas - o chefe da unidade, financiador, contador e advogado. Cada um recebeu um dia para aprovação e Iceberg elevou a porcentagem de acessos nesse período para 90%.

Porém, o problema começou por outro lado - quando o acordo foi acordado e assinado em papel, as duas cópias são enviadas à contraparte para colocar sua assinatura e selo. Consequentemente, o pedaço de papel deve voltar para entrar no arquivo do departamento jurídico.

Mas as pessoas que haviam reclamado anteriormente da longa aprovação não tinham pressa em entregar os originais dos contratos a advogados. Eles geralmente se esquecem disso - basta que o contrato seja assinado e você pode trabalhar com a contraparte. Aqui os advogados uivaram - é impossível sem os originais, qualquer verificação servirá para a empresa, como Auschwitz, que não parecerá suficiente.

Consequentemente, outro Iceberg pareceu entregar os originais dos contratos. Alocado por mês para acordos ordinários e 100 dias para acordos de comércio exterior. E tudo funcionou. Especialmente quando os advogados começaram a rejeitar novos contratos até a entrega dos antigos. Uma imagem do número e da época dos contratos com falha estava constantemente disponível no sistema e, tendo em vista a importância desse problema, ela estava sob controle constante da administração. Ninguém quer entrar na esfera de interesse do diretor com muita frequência, então eles entregam os originais quase sempre na hora certa.