No início desta semana, fizemos uma pergunta:
Seu processo funciona — ou as pessoas aprenderam a contorná-lo?
A pergunta parece simples.
Mas existe uma diferença importante entre perceber que as pessoas estão criando atalhos e compreender por que isso está acontecendo.
Um procedimento pode existir. O fluxo pode estar documentado. As responsabilidades podem ter sido definidas. As pessoas podem ter sido treinadas.
E, ainda assim, na operação real, o trabalho seguir por caminhos diferentes daqueles previstos.
Diante disso, uma conclusão aparece com facilidade:
“As pessoas não seguem o processo.”
Talvez.
Mas isso ainda descreve o que estamos vendo. Não necessariamente explica o que está acontecendo.
Nem todo desvio começa na execução
Há situações em que o processo é adequado, mas as pessoas não receberam conhecimento, recursos ou preparação suficientes para executá-lo.
Há outras em que uma ferramenta foi disponibilizada, mas a capacidade necessária para utilizá-la não foi construída.
Há situações em que hábitos anteriores continuam prevalecendo.
E existem também aquelas em que o problema começou antes de tudo isso:
o próprio processo foi desenhado sem compreender suficientemente a realidade em que precisaria funcionar.
Essa possibilidade muda a investigação.
Em vez de perguntar apenas:
“Por que as pessoas não estão seguindo o processo?”
talvez seja necessário perguntar:
“O processo que estamos pedindo que elas sigam faz sentido nas condições reais em que o trabalho acontece?”
Essa não é uma defesa do improviso. Também não significa que toda resistência seja legítima ou que a maneira atual de trabalhar deva ser preservada.
Significa apenas reconhecer algo elementar:
um processo pode fazer sentido no fluxograma e não fazer sentido no território onde precisa acontecer.
Quando uma boa ideia encontra uma operação que ela não conhece
Imagine uma operação de campo distribuída geograficamente.
Determinado equipamento precisa receber uma intervenção depois da ocorrência de uma condição específica.
Alguém analisa a necessidade e define quem será responsável pela atividade.
Tecnicamente, a decisão parece coerente. Existe uma necessidade de manutenção. Existe um profissional associado àquele tipo de instalação. Atribui-se a atividade a ele.
No papel, problema resolvido.
Mas existe uma informação que o desenho não incorporou suficientemente:
onde essas pessoas estão em relação ao local onde a intervenção precisa acontecer?
Em determinadas situações, o profissional definido pelo procedimento poderia precisar percorrer uma distância considerável apenas para realizar aquela atividade.
Enquanto isso, equipes de atendimento emergencial já circulavam pelo território e poderiam incorporá-la à própria rotina operacional.
A necessidade continuava correta. A atividade continuava necessária. O problema estava na arquitetura escolhida para executá-la.
Quando a orientação chegou à operação, quem conhecia a realidade de campo questionou o desenho.
Não porque não quisesse executar. Mas porque conhecia uma condição que não havia participado suficientemente da decisão.
Esse tipo de situação revela uma armadilha gerencial:
podemos tentar treinar pessoas para executar perfeitamente um processo que deveria ter sido questionado antes do treinamento.
Mais treinamento não corrigiria o deslocamento desnecessário. Mais cobrança por aderência também não.
Um indicador de cumprimento poderia até demonstrar que a atividade estava sendo realizada.
E ainda assim continuaríamos consumindo recursos de maneira inadequada.
O trabalho real contém informações que o procedimento não contém
É por isso que compreender o AS-IS não deveria significar simplesmente localizar o procedimento vigente e transformá-lo em um fluxograma.
O processo formal informa como o trabalho deveria acontecer. O trabalho real mostra como ele efetivamente acontece.
Entre os dois podem existir atalhos, exceções, controles paralelos, planilhas auxiliares, decisões informais, conhecimento tácito, restrições tecnológicas, limitações geográficas, dependências entre áreas e adaptações incorporadas ao longo do tempo.
Algumas dessas práticas são desperdícios.
Outras são respostas inteligentes a problemas que o desenho formal nunca resolveu.
E algumas podem ser as duas coisas ao mesmo tempo.
Por isso, observar o trabalho real não significa aceitá-lo sem questionamento.
Significa transformá-lo em evidência para compreender o sistema antes de redesenhá-lo.
Stakeholder não é quem recebe o fluxograma para aprovar
Uma organização pode acreditar que envolveu os stakeholders porque apresentou o processo pronto para diferentes áreas e pediu validação.
Mas validar um desenho depois que suas principais decisões já foram tomadas é diferente de participar da compreensão do problema.
Stakeholder, nesse contexto, não é apenas quem executa uma atividade.
É quem fornece entradas. Quem executa. Quem recebe as saídas. Quem toma decisões. Quem responde pelos sistemas. Quem conhece restrições de segurança, qualidade, regulação ou tecnologia. Quem é afetado pelas consequências. E quem possui conhecimento relevante para compreender como aquele processo funciona.
Isso não significa colocar dezenas de pessoas em uma sala para decidir cada seta de um fluxograma.
Significa garantir que as perspectivas necessárias estejam representadas no momento em que ainda podem alterar o desenho.
Porque conhecimento organizacional é frequentemente distribuído.
Quem executa conhece detalhes que a gestão não vê. Quem recebe a saída percebe problemas que quem executa pode não perceber. Tecnologia conhece limitações sistêmicas. A liderança conhece objetivos e restrições do negócio. O cliente experimenta consequências que nenhuma dessas áreas observa integralmente.
Nenhuma perspectiva, isoladamente, necessariamente representa o processo inteiro.
Um processo pode existir durante anos e continuar inadequado
Existe também o problema oposto ao processo recém-desenhado: o processo antigo.
Aquele que existe há tanto tempo que sua própria longevidade começa a funcionar como argumento de legitimidade.
“Foi sempre assim.”
Em uma operação de cobrança com muitos anos de funcionamento, havia procedimento, responsabilidades e uma forma estabelecida de executar as atividades.
O processo existia. Mas não funcionava satisfatoriamente.
Uma das mudanças realizadas foi aparentemente simples:
colocar os stakeholders relevantes diante do mesmo processo.
Primeiro, compreender como o trabalho realmente acontecia: o AS-IS.
Depois, confrontar perspectivas, interfaces, problemas e lacunas.
O que uma área fazia? O que a seguinte esperava receber? Onde estavam as ambiguidades? Quais responsabilidades não estavam claras? Que partes do procedimento não correspondiam à execução? Que conhecimento estava distribuído entre diferentes pessoas e áreas?
Somente depois dessa compreensão foi construído o TO-BE.
O novo desenho foi discutido, validado, formalizado e então colocado em prática.
A diferença não estava simplesmente em possuir um fluxograma melhor.
O processo passou a incorporar conhecimento que antes estava espalhado entre os seus stakeholders.
Ouvir a operação não significa desenhar o processo exatamente como ela trabalha hoje
Se desenhar um processo apenas a partir da visão de quem está distante da execução é arriscado, fazer o movimento contrário também pode ser.
Quem executa o trabalho pode ter incorporado práticas desnecessárias, reproduzir controles cuja razão original deixou de existir, manter etapas porque “sempre foram feitas assim”, criar atalhos que resolvem um problema local e geram consequências em outra parte do processo ou não enxergar restrições e objetivos fora de sua atividade.
Por isso:
ouvir quem executa não significa transformar o AS-IS em TO-BE.
Significa não construir o TO-BE ignorando aquilo que só o trabalho real consegue revelar.
O objetivo não é escolher entre “a teoria” e “a operação”.
É colocar conhecimento técnico, objetivos organizacionais e realidade operacional em diálogo.
E então chegamos ao treinamento
Depois que o processo é desenhado, ainda existe outra distância a percorrer.
Uma organização pode construir um processo adequado e fracassar na implantação.
Pode comunicar mal. Treinar insuficientemente. Não disponibilizar recursos. Não preparar as lideranças. Não desenvolver autonomia para tratar exceções.
Ou simplesmente apresentar o procedimento e considerar que a capacidade foi instalada.
Foi justamente essa a provocação que fizemos na publicação anterior:
ferramenta disponível não é capacidade instalada.
O mesmo raciocínio vale para processos.
Processo desenhado não é processo executável.
Processo publicado não é processo incorporado.
Treinamento realizado não é capacidade instalada.
Por isso, quando encontramos distância entre procedimento e execução, existem pelo menos três hipóteses que precisam permanecer abertas:
o processo pode estar inadequado;
a capacidade necessária para executá-lo pode não ter sido construída;
ou as duas coisas podem estar acontecendo simultaneamente.
Diagnosticar uma delas antes de investigar é justamente o tipo de simplificação que produz novas intervenções sobre causas erradas.
E a automação torna esse cuidado ainda mais importante
Na terça-feira discutimos outra consequência dessa mesma questão:
automatizar o processo — ou automatizar o problema?
Automação e inteligência artificial ampliam enormemente aquilo que podemos transferir para a tecnologia.
Mas velocidade não substitui compreensão.
Se automatizamos um fluxo distante do trabalho real, podemos retirar justamente a flexibilidade informal que permitia às pessoas compensar suas fragilidades.
O processo continua inadequado. Só que agora pode executá-las com maior velocidade, consistência e escala.
É por isso que a pergunta anterior à automação continua sendo tão importante:
compreendemos suficientemente bem aquilo que estamos prestes a acelerar?
Talvez a aderência comece antes do treinamento
Existe uma tendência de tratar aderência como uma questão posterior ao desenho.
Primeiro construímos o processo. Depois treinamos. Então cobramos cumprimento.
Mas parte da aderência pode começar muito antes.
Começa quando enxergamos o trabalho como ele realmente acontece. Quando entendemos as perspectivas que interferem naquele sistema. Quando confrontamos procedimento e realidade. Quando distinguimos adaptação necessária de desperdício incorporado. Quando as pessoas que possuem conhecimento relevante conseguem influenciar o desenho antes que ele esteja decidido.
Isso não elimina resistência. Não elimina conflito. Não elimina a necessidade de decisão gerencial. E certamente não transforma todo processo em consenso.
Participação não significa que todos decidem tudo.
Significa que decisões melhores podem ser tomadas quando o conhecimento necessário chega à decisão antes dela.
Do trabalho real à capacidade organizacional
Talvez seja justamente aqui que Pessoas e Processos deixem de ser assuntos separados.
Processos organizam a execução.
Pessoas carregam parte relevante do conhecimento necessário para executá-los e melhorá-los.
Tecnologia pode ampliar capacidade.
Produtos e serviços recebem os efeitos dessa combinação.
E a Rentabilidade acaba absorvendo aquilo que funciona — e aquilo que não funciona.
Na Power 4P, os 6Es ajudam a organizar essa investigação sem presumir antecipadamente onde está o problema.
ENXERGAR o trabalho real.
ENTENDER stakeholders, restrições, conhecimento, interfaces e exceções.
ESCOLHER um desenho coerente com o resultado que precisamos produzir.
EXECUTAR e construir capacidade para que ele aconteça.
EVIDENCIAR se o novo processo efetivamente melhorou o sistema.
EVOLUIR incorporando aquilo que a própria execução continua ensinando.
O ponto não é defender que todo processo precisa ser redesenhado.
Nem concluir que todo desvio demonstra um erro de projeto.
É evitar a conclusão confortável de que o problema está nas pessoas simplesmente porque foi nelas que conseguimos enxergá-lo.
Antes de exigir aderência, talvez exista uma pergunta anterior:
Quem desenhou o processo conhecia o trabalho real?
Porque, quando a resposta é não, aquilo que chamamos de resistência pode ser apenas o lugar onde a realidade finalmente encontrou uma maneira de responder ao fluxograma.