Como os processos de loop aberto interrompem o fluxo de informações nos negócios

Fiz uma boa quantidade de reengenharia de processos de negócios ao longo da minha carreira, e o maior problema que encontro é sempre o mesmo: processos de negócios de ciclo aberto. Os processos de ciclo aberto ocorrem principalmente porque a responsabilidade é dividida entre várias pessoas e, muitas vezes, entre vários departamentos. Um fluxo de informações que começa em P&D com uma solicitação de um novo equipamento pode passar pelas Finanças e Compras antes de sair da fronteira organizacional para o Fornecedor (onde passará por vários departamentos sucessivamente) e, eventualmente, voltar para Recebimento e , com sorte, o grupo de P&D que iniciou o fluxo.

Em cada etapa, existe a possibilidade de que a comunicação seja interrompida e os gerentes de projeto precisem mitigar esses riscos. Se os fluxos de informações incorporados em um processo de negócios não forem explicitamente estruturados para detectar e manipular quaisquer exceções, a falha não será detectada até muito mais tarde ou talvez nem seja detectada. Enquanto algumas falhas no fluxo de informações resultam apenas em itens relativamente sem importância não serem pedidos ou entregues corretamente, outras falhas podem custar às organizações grandes somas de dinheiro ou impor atrasos em atividades de missão crítica.

Open-loops podem custar milhões de dólares

Para ilustrar o ponto, primeiro vou falar sobre uma grande organização farmacêutica que estava pagando impostos sobre centenas de milhões de dólares em equipamentos que não conseguia mais rastrear e queria eliminar essa despesa desnecessária. Nosso projeto descobriu muitas falhas fundamentais do processo, todas as quais somavam dezenas de milhões de dólares em impostos desnecessários por ano e muito mais sendo gastos em pedidos das mesmas coisas várias vezes por engano.

Comunicação unidirecional entre áreas de responsabilidade

Como todas as grandes organizações, as responsabilidades estavam em silos. Alguém na Manufatura precisa do equipamento X, então informa o Financeiro e é gerado um pedido de compra (PO). O pedido envia o pedido ao fornecedor. Até um ano no futuro, X é entregue e aceito pelo Recebimento. Receber notifica Manufatura e Finanças. As finanças emitem uma etiqueta de ativo, que o Recebimento coloca em X. X é colocado na linha de produção e está tudo bem.

Exceto, nem tudo está bem. Para começar, os funcionários vêm e vão, e é fácil pedir X sem perceber que outra pessoa na mesma função pediu X nove meses atrás. As finanças não têm ideia de que este pedido é uma duplicata: eles assumem que você simplesmente precisa de outro X e, portanto, outro pedido é gerado e outro pedido é feito. Além disso, mesmo que você não encomende acidentalmente, você rapidamente perde o controle do que tem.

Vamos supor que X seja um equipamento complexo, talvez uma linha de preenchimento-acabamento. Consiste em 20 componentes principais, todos os quais serão substituídos várias vezes durante sua vida útil. Uma etiqueta de ativo colocada ao acaso em uma parte de X desaparecerá devido ao desgaste. Pior ainda, a etiqueta do ativo pode nem ser aplicada porque não chega ao recebimento a tempo. Depois disso, ninguém tem ideia de como rastrear X e, portanto, não tem ideia de como desativá-lo no final da vida útil. Do ponto de vista tributário, X ainda é um item tributável funcional.

Ao longo de mais de 20 anos, isso começaria a prejudicar os resultados de uma maneira não insignificante. Além disso, as Finanças estão usando uma parte de seu sistema ERP com um conjunto de designadores de ativos, enquanto a Manufatura está usando um módulo ERP totalmente separado com um conjunto diferente de designadores de ativos. No final do ano, ninguém consegue conciliar os dois conjuntos de números, e os auditores estão questionando por que você tem dezenas ou centenas de milhões de dólares em discrepância em relação ao seu equipamento de capital.

Esses são problemas clássicos que surgem de um conjunto de processos de negócios em malha aberta. Loop aberto é quando você não cria pontos de confirmação explícitos ao longo da linha de fluxo do processo. No exemplo acima, havia tantos processos de loop aberto que a falha era garantida.

Criando fluxos de informação bidirecionais

Veja como lidamos com o problema. Modelamos cada fluxo de processo significativo do início ao fim. Identificamos todos os loops abertos. Em seguida, projetamos maneiras simples de fechar esses loops, um de cada vez, começando desde o início.

Passo um

A manufatura precisa de X, então eles pedem às Finanças para abrir uma ordem de compra. O departamento financeiro agora verifica com a Manufatura para confirmar, fornecendo detalhes de pedidos anteriores para X que remontam a 24 meses. A duplicação acidental de pedidos é evitada.

Passo dois

A fabricação fornece ao departamento financeiro um detalhamento dos componentes de X que serão substituídos durante a vida útil. O Finance cria etiquetas de ativos para cada componente e confirma com o Manufacturing. Ambos os módulos ERP são preenchidos com tags de ativos correspondentes por componente, permitindo o rastreamento ao longo do ciclo de vida do ativo.

Passo três

O recebimento notifica as Finanças, que notificam a Fabricação. A colocação de etiquetas de ativos é feita por uma parte responsável da Fabricação para garantir que cada etiqueta seja colocada em seu componente correto. Todos os tags/componentes são então reconfirmados para os dois módulos ERP.

Passo Quatro

Toda vez que um componente é trocado, a Manufatura informa as Finanças e uma nova etiqueta de ativo para esse componente é gerada e colocada no novo componente pela Manufatura e, em seguida, confirmada em ambos os módulos ERP. As finanças então iniciam o processo de remoção do componente antigo dos livros enquanto a Manufatura passa pelo processo de desativação do Guia de Boas Práticas (GMP). Ao final do descomissionamento, a Manufatura informa o Financeiro para que o ativo possa ser retirado dos livros.

Os detalhes são um pouco mais complexos do que este exemplo simplificado, mas o ponto é claro: em cada etapa da estrada, há verificações e confirmações explícitas.

Garantindo Ações de Contingência

Em outro projeto, me pediram para ajudar uma empresa de serviços a melhorar os índices de satisfação de seus clientes. O negócio deles era o processamento de reclamações, e eles estavam preocupados com o fato de não conseguirem ganhar licitações. Além disso, em seus lances vencedores, a insatisfação subsequente dos clientes significava que o índice de perda de contas era muito alto.

Levou apenas alguns dias para identificar o cerne do problema, que mais uma vez eram os processos de malha aberta. Quando um cliente em potencial solicitava uma oferta, o gerente de contas usava seu sistema interno para enviar um esboço de requisitos do cliente para a pessoa responsável pela montagem da oferta. O criador do lance então criaria o lance e o encaminharia ao cliente. Esperançosamente, o cliente acabaria respondendo, geralmente com as modificações desejadas, que o criador do lance incorporaria na próxima versão. Em algum momento, o cliente aceitaria a oferta e uma nova conta de cliente seria criada pela Contabilidade, uma fatura levantada e a equipe de integração informada.

O primeiro problema era que não havia confirmação explícita do criador do lance para o gerente da conta, então, às vezes, os lances não eram criados e enviados a tempo e ninguém sabia disso. Isso foi possível porque o sistema interno não tinha campo para mostrar uma data de vencimento para um lance e, como o criador do lance estava sempre sobrecarregado, isso fazia com que os lances fossem enviados muito tarde. Devido ao fraco fluxo de informações no negócio, essas situações nunca vieram à tona.

Depois disso, as modificações no lance não foram transmitidas ao gerente da conta. Isso era importante porque era o gerente de contas quem informava a equipe de integração quando um cliente finalmente assinava na linha pontilhada. Muitas vezes, o briefing baseava-se no entendimento inicial do gerente de contas, e não na oferta que o cliente realmente havia aceitado.

Uma vez que o trabalho começasse, os documentos do cliente chegariam e seriam encaminhados para qualquer membro da equipe no pool de processamento que tivesse sido designado naquela semana para lidar com eles. Como não havia confirmação explícita de recebimento, era possível que os documentos desaparecessem sem que ninguém soubesse do fato, até que o cliente começou a perguntar por que não estava recebendo os resultados do trabalho de processamento.

Quando os documentos processados ​​eram enviados de volta ao cliente, não havia confirmação no recebimento, de modo que quaisquer documentos ausentes eram perdidos até que alguém em algum lugar começasse a reclamar sobre sua ausência.

Confirmar eventos-chave

Em cada etapa do processo de licitação, incluímos confirmações explícitas. Criamos soluções alternativas para falhas do sistema para que todas as informações críticas fossem capturadas, incluindo a data exigida e as modificações subsequentes da oferta. Implementamos verificações e confirmações explícitas para todo o fluxo de informações nos negócios dentro da empresa e entre a empresa e o cliente.

Por exemplo, quando um cliente enviava um pacote de documentos, agora ele enviava um e-mail para o gerente de contas do cliente informando-o. O gerente de contas do cliente encaminharia isso para a parte responsável no processamento de reivindicações. Se os documentos não fossem recebidos em três dias, um alerta seria gerado. Quando os documentos foram recebidos, um e-mail foi para o cliente confirmando o recebimento. O inverso também acontecia quando a empresa enviava documentos processados ​​de volta ao cliente.

Como a maioria dos clientes usava o correio dos EUA para embaralhar documentos impressos de um lado para o outro, os processos de ciclo fechado usando verificações explícitas em cada etapa significavam que qualquer documento perdido poderia ser identificado rapidamente e as medidas tomadas para corrigir a situação.

Procedimentos de tratamento de exceção de design

Para ver como os procedimentos de tratamento de exceção podem ser construídos de maneira razoavelmente leve e eficaz, vamos examinar outro exemplo do mundo real que encontrei em minha carreira quando eu era o CIO de uma organização de pesquisa científica focada em investigar as causas de envelhecimento e os desencadeadores de doenças relacionadas com a idade.

Todos os institutos de pesquisa financiados pelo NIH contêm muitos laboratórios individuais, cada um administrado por um investigador principal (PI) e composto por vários cientistas subordinados e pós-doutorandos. Em algum momento, o PI precisa de uma nova bandeja de reagentes multicâmara, então eles pedem a um dos pós-docs para criar a solicitação necessária. O pós-doc cria a solicitação e a envia por e-mail ao Finance para solicitar que uma PO seja levantada, enviando uma cópia do PI para garantir que o PI esteja ciente de que a solicitação foi enviada. Enquanto isso, o PI tem uma notificação de calendário automática definida para lembrá-los de verificar o status da solicitação se não tiverem recebido a confirmação até uma determinada data. Isso garante um mecanismo à prova de falhas caso o pós-doc se esqueça de criar ou enviar a solicitação necessária.

Agora, o pós-doc também tem uma notificação de calendário automática para fazer check-in com as Finanças se não receber a confirmação da ordem de compra sendo levantada dentro de um período de tempo definido. Quando o Finance levanta o PO, o pós-doc recebe a confirmação por e-mail de que foi enviado ao fornecedor e o pós-doc encaminha essa confirmação para o PI.

Nesta fase, o PI ou o pós-doc define outra notificação automática de calendário para garantir que, se nada for recebido do fornecedor dentro de um período de tempo definido, alguém verifique com o fornecedor para garantir o recebimento do PO e o envio do equipamento que foi encomendado.

Supondo que o fornecedor confirme o recebimento do PO e despache o item junto com uma notificação de despacho, isso é roteado para o PI ou pós-doc. Em seguida, eles definem uma notificação de calendário final para três dias após a data programada de recebimento para garantir que, se o item não aparecer, eles saibam entrar em contato com o fornecedor para rastrear o que aconteceu e receber o item corretamente. Se o item chegar conforme o planejado, o pós-doc notifica as Finanças e se a organização emprega etiquetas de ativos, esse conjunto de processos pode ser iniciado.

Em cada etapa do caminho, há uma confirmação explícita necessária e um subprocesso disponível para garantir que a ação corretiva ocorra se o fluxo do processo principal for interrompido. Nada é deixado pendente, não confirmado ou sem suporte. Nenhuma ação ad-hoc é necessária porque todos sabem o que é necessário e o que fazer se as coisas derem errado.

Aprendendo a criar processos de loop fechado a partir do SQL

A essência de um bom processo é muito semelhante à maneira como os bancos de dados relacionais baseados em SQL foram projetados para garantir a consistência transacional. Qualquer ação deve ser confirmada para que seja assumida como concluída. Todas as comunicações bidirecionais precisam de confirmação explícita incorporada como parte do processo e processos subordinados desenvolvidos para garantir que, se a confirmação não for recebida, a ação correta seja tomada. Gerentes de projeto bem-sucedidos devem criar processos de ciclo fechado para melhorar o fluxo de informações em um negócio e economizar muito tempo e dinheiro para as organizações.