Boa tarde
Quero oferecer uma pequena excursão à aplicação prática da teoria das restrições para TI. Ou seja, na questão de calcular a "taxa de transferência" do departamento para o desenvolvimento de software corporativo interno.
Sobre o CBT (Teoria das Restrições) e o mega-livro "Goal", de Elia Goldratt, muito foi escrito, inclusive sobre Habré, então vou direto ao ponto.
O departamento que eu sou responsável por apoiar e desenvolver vários chamados sistemas de informação "internos", os principais dos quais são WMS e TMS - sistemas de gerenciamento de armazém e transporte. Além disso, focarei apenas nesses sistemas e em apenas uma parte do negócio - os serviços de um operador logístico.
Todos os dias, uma dúzia de novas tarefas são despejadas em nossa caixa de correio, muitas delas marcadas como "Urgente!", "Importante!" etc.
No momento, a lista de pendências aumentou para cerca de setecentas tarefas de diferentes categorias de complexidade.
Para gerenciar de alguma forma esse volume, introduzimos um sistema de prioridades, de acordo com o grau de influência nos negócios:
A - falhas no sistema ou problemas que não permitem cumprir totalmente as obrigações contratuais (para o negócio principal).
B - tarefas relacionadas ao crescimento da receita da empresa - ou seja, a chegada de novos clientes.
C - tarefas relacionadas à melhoria da lucratividade, ou seja, tarefas para otimizar a produtividade (sistemas totais, processos de trabalho, pessoas, crescimento da produção, etc.).
D - melhorias a pedido de nossos clientes (relatórios, integração com empresas de transporte, etc.).
Dentro dessas categorias, há outro nível de divisão (A1, A2, ...), mas, para os propósitos do artigo de hoje, isso não é essencial.
Logicamente, a execução das tarefas deve ser organizada em ordem: ABCD.
Na prática, um plano de desenvolvimento é o resultado de um grande número de compromissos. Como exemplo, as tarefas da categoria D costumam chegar ao topo da lista de pendências (foco no cliente, sim).
De fato, o sistema prioritário fornece apenas uma orientação geral para o planejamento, mas não permite que todos dêem uma resposta objetiva à pergunta: "Por que minha tarefa não leva tanto tempo?"
Também temos o problema de clientes pequenos e grandes, que gastam aproximadamente o mesmo recurso de TI. Teoricamente, os clientes mais gordos devem ser uma prioridade, mas você também não deve deixar que os pequenos também requeiram atenção especial, como se não enviasse duas gazelas por semana, mas pelo menos um trem de contêineres.
Entendendo isso e entendendo que a empresa é uma organização comercial, não uma instituição de caridade, e em primeiro lugar deve ser rentável, decidimos bombear o sistema de planejamento usando a teoria das restrições.
A limitação no nosso caso é o recurso de desenvolvimento.
A CBT introduz um novo conceito de taxa de transferência de negócios, uma "taxa de geração de receita" condicional, que deve ser aumentada continuamente. Ao contrário dos custos, o crescimento da passagem não é teoricamente limitado por nada e pode (pode) tender ao infinito.
No caso dos desenvolvedores, usaremos o retorno em horas-homem, em rublos, como medida de passagem.
O algoritmo é algo como isto:
- Para cada tarefa, é necessário avaliar o efeito econômico da implementação. Isso pode economizar horas de trabalho, ou economizar outro recurso (por exemplo, escassos metros quadrados na área de expedição ou locais de paleta na área de armazenamento ou horas do carregador). Desejável, em milhares de rublos / ano. O cliente deve realizar essa avaliação. Se ele não puder fazer isso sozinho, entrará em contato com o supervisor.
- Depois que a tarefa é avaliada em termos de efeito, ela é direcionada ao estudo Timlid ou a um dos signatários. Como resultado, obtemos uma certa estimativa preliminar dos custos.
- Dividindo o primeiro no segundo, obtemos a própria passagem - a velocidade de alcançar o efeito.
- Classificamos as tarefas na lista de pendências em ordem decrescente de passagem.
- Corte um pedaço de atraso em cima do próximo plano / sprint.
Por exemplo, há um problema, cujo efeito o cliente estimou em 100 mil rublos. por mês, ou 1,2 milhão de rublos. por ano.
De nossa parte, a implementação exigirá 40 horas de desenvolvimento.
O passe, como resultado, será 1200/40 = 30 unidades convencionais.
Para outra tarefa, o efeito esperado de 50 mil rublos. por mês, mas sua implementação levará 100 horas. Total, 600 mil rublos / 100 = 6 u.u.
No final, faremos as duas tarefas. Mas primeiro o primeiro e depois o segundo.
Voltando às categorias prioritárias, formamos um fluxo de correção separado (categoria A), em seguida lançamos novos clientes (as tarefas são planejadas de acordo com os prazos existentes) e o restante do tempo será bombardeado com o desenvolvimento de um novo sistema de avaliação de aprovação.
A vantagem desta tecnologia é que é objetiva. Mesmo com todas as premissas - como o cliente estimou o efeito, imprecisões na avaliação da complexidade, o nível do desenvolvedor que a implementará - ele fornece uma imagem real de tarefas importantes e sem importância do ponto de vista comercial.
E a categoria D, você pergunta? Como está o desejo do cliente, especialmente os pequenos? Como eles se encaixaram no novo esquema?
Esta questão ainda está em aberto.
Para construir uma imagem objetiva, também é necessário avaliar o efeito econômico deles, mas, condicionalmente, indireto. Ou seja, a reputação da empresa, foco no cliente, potencial crescimento dos negócios desses clientes, atraindo boas referências. Existem assuntos mais sutis, nós, juntamente com vendas e atendimento ao cliente, discutimos como digitalizar esses indicadores.
O objetivo final é obter um sistema objetivo e transparente de criação de tarefas que permita maximizar o uso do recurso de desenvolvimento. Talvez, como harmonia, alguém possa apenas lutar por isso, no entanto, a teoria das restrições afirma inequivocamente que o "Objetivo" é atingível.
Algo assim.
Pela prontidão da próxima parte do rebus, vou compartilhar o resultado.
PS Por enquanto, os problemas de refatoração e várias tarefas de infraestrutura são deixados de fora, retornaremos a eles mais tarde.