Muitas empresas estão se esforçando para obter mais agilidade nos negócios, ou mesmo um completa transformação, por razões das mais diversas possíveis:
- Tem empresa grande que está em recuperação judicial, ou mesmo em uma situação financeira delicada, que busca mais agilidade como uma das formas para enfrentar esta situação.
- Tem outras, menores, que precisam crescer dois dígitos de faturamento em um ano, e: como alcançar este objetivo sem se mover rapidamente com agilidade?
- Tem ainda aquelas relativamente novas, em franco crescimento, com poderosos investidores por trás, e que neste momento estão mais em busca de relevância do que de lucro.
- E ainda outras que lideraram o mercado nas últimas três ou mais décadas, mas que agora têm sua liderança ameaçada, acreditando que com mais agilidade conseguiriam se manter na dianteira.
Essa diversa lista poderia ser longa, mas acredito que esses exemplos já sejam suficientes para compartilhar meu ponto, que é:
Será que para empresas com histórico, características e objetivos tão diferentes, a agilidade nos negócios deveria ser definida e alcançada da mesma forma?
Uma estratégia
Entendo que cada empresa seja única, e que seu contexto e momento devam ser decisivos na definição de um novo modelo operacional que lhe dê mais agilidade nos negócios. De fato, uma prática que se mostra útil para a agilidade de uma empresa que busca mais relevância do que lucro, por exemplo, pode colocar em risco o negócio da empresa que está em uma situação financeira delicada ou daquela que busca se manter na liderança de mercado. Sem contar que empresas diferentes, na maioria das vezes, precisam de níveis e aspectos diferentes de agilidade.
Mas como identificar de quanta agilidade nosso negócio necessita? E, mais difícil ainda, como identificar quais os aspectos da agilidade são essenciais para nosso sucesso?
A estratégia BUILD (BUsiness agILity Design) é a forma com que venho trabalhado com meus clientes de forma a ajuda-los a construírem modelos emergentes para a agilidade dos seus negócios. O resultado é sempre algo que esteja alinhado aos objetivos, complexidade e jeito de ser da empresa.
Frameworks x Scaffolds
Atualmente, boa parte das estratégias utilizadas para desenvolver a agilidade organizacional das empresas são baseadas em frameworks. Isso implica que elas forneçam uma base comum de trabalho que será central para todo o restante do trabalho.
Na engenharia civil, por exemplo, um framework é a base que sustentará todo o restante da construção e que continuará fazendo parte da mesma. No mundo de desenvolvimento de software, um framework contém um bom número de código já desenvolvimento que, mesmo não tendo sido escrito por você, fará parte do seu produto final.
No BUILD, trabalhamos com scaffolds (andaimes) ao invés de frameworks, considerando que a base da estratégia para sua agilidade organizacional deva ser o seu negócio e não o meu framework preferido. Ou seja, partimos do seu contexto e não da nossa prática.
O fato de trabalhar desta forma não significa que iremos “reinventar a roda” a cada empresa, e muito menos que devamos ignorar tudo de bom que já foi construído até aqui.
No BUILD, práticas já existentes – publicadas em livros, utilizadas por outras empresas, e mesmo as presentes em outros frameworks, métodos e BOK’s – com frequência são sim utilizadas, e mesmo recombinadas. No entanto, elas nunca precedem o contexto, e isso faz uma enorme diferença nos resultados do seu negócio.
As etapas do BUILD
O BUILD é composto por uma sequência contínua de três etapas, que exemplificarei em mais detalhes na sequência deste artigo.
BRIEF
Seguindo com a estratégia de scaffoldings, o primeiro passo deste trabalho é identificar onde na sua empresa colocaremos “nossos andaimes”, quais os rumores existentes naquele território, e quais são as expectativas existentes sobre ele. Em suma, a gente trabalha em uma definição preliminar, cocriada com os profissionais locais, sobre o porque dessa empresa precisar de mais agilidade e o que mais lhe atrapalha a alcançar isso.
No entanto, o BRIEF não chega ao resultado que desejamos se simplesmente perguntarmos às pessoas “o que não está bem aqui?”, ou ainda se simplesmente observamos alguma tema organizacional isolado, como “olhar para fluxo” ou “trocar de estrutura”, por exemplo.
Por essa razão, procuramos trabalhar aqui com dinâmicas que tirem os participantes da sua zona conhecida, e que misturem diversos dos temas organizacionais.
Uma destas dinâmicas para BRIEF, que criei ao longo da prática do BUILD, e influenciado pelo trabalho de Michael Foucault, é o que chamamos de Georg Map (Geo-Organisational Map), nela identificaremos onde na organização devemos focar, e descobriremos as macro-narrativas, ou narrativas organizacionais, que representam a percepção atual e problemática do contexto, e que, além de guiar nosso trabalho no SENSE, será utilizada para definir o significado de sucesso para esta iniciativa.
SENSE
Uma vez com “nossos andaimes” posicionados, agora é hora de trabalhar para olhar os problemas em um nível micro, utilizando as lentes de cada pessoa afetada ou envolvida nessa situação. Esse trabalho vai além de analisar métricas e/ou megadados (big data) pois trabalha nas narrativas que fazem parte do cotidiano de cada indivíduo, ou seja, trabalhamos com dados de forma espessa e aprofundada, e não apenas larga.
Na primeira parte do SENSE, precisamos coletar as narrativas. Isto acontece a partir de variados tipos de dinâmicas: síncronas ou assíncronas, individual ou participativa, emergente ou prescritiva, com diversidade ou semelhança de pensamento, dentre outras. A estratégia utilizada aqui é fortemente influenciada pelo resultado do BRIEF.
Como resultado desta primeira parte, teremos uma coleção com centenas de micro-narrativas. O número aqui precisa ser bem alto, para nos permitir um trabalho rico e sem viés na busca por padrões.
Com isso em mãos, vamos para a segunda parte deste trabalho que é a qualificação das micro-narrativas e a busca por padrões alinhados aos temas organizacionais. Esses padrões serão decisivos para a etapa de DESIGN.
Aqui utilizo alguns métodos próprios, bem como técnicas derivadas dos trabalhos de Cynthia Kurtz, Bill Sharpe, Ann M. Pendleton-Julian e outros, além de métodos e ferramentas licenciadas com a Cognitive Edge, empresa de Dave Snowden — criador do Cynefin.
Ao fim, teremos um pequeno portfólio com os padrões identificados como sendo os principais bloqueadores para a agilidade na empresa. Esse catálogo é composto minimamente pelas narrativas que os sustentam, suas conexões e detalhes, energia e impacto de distribuição.
Agora sim, com o contexto compreendido, estamos prontos para tomar decisões sobre modelos, métodos e práticas, de forma emergente.
DESIGN
Essa etapa pode ser executada de duas maneiras distintas, dependendo se estou utilizando o BUILD para a direta resolução de problemas, ou para a construção de um desenho organizacional que habilite a agilidade nos negócios.
Resolução de Problemas. Partimos para a identificação do nível de complexidade existente nos padrões emergentes, para então construirmos práticas da forma mais apropriada. Nesse ponto, utilizamos fortemente o Cynefin e suas dinâmicas, e avançamos com a aplicação das restrições e práticas apropriadas de acordo com o domínio predominante (claro, complicado, complexo, caótico ou confuso) e com os temas organizacionais identificados. Além disso, o fluxo de aprendizagem do Learning 3.0 é muitas vezes utilizado para trabalhar de forma consciente com a experimentação de práticas no contexto.
Desenho Organizacional. No caso da utilização do BUILD para o (re)desenho organizacional, este é o momento de construir o Modelo “Sua Empresa”, que servirá como base para todas as implementações de agilidade ao redor da organização. Esse modelo será estruturado a partir dos temas organizacionais, e será composto por restrições, recomendações e propensões identificadas a partir dos padrões emergentes.
Este modelo será utilizado como base para qualquer iniciativa da empresa que queira trabalhar de uma forma mais ágil. Elas deverão instanciar o modelo e aplicar as práticas de sua preferência que se mostrem adequadas a cada contexto mas que estejam aderentes ao modelo.
Por exemplo, uma instância /Produto XPTO/ pode estar organizada em estrutura de “squads”, por ser mais adequada à sua necessidade local, e atender às restrições do tema “Estrutura” presentes no modelo. No entanto, uma outra instância, do /Produto YMCA/, consegue atender às mesmas restrições utilizando estrutura de “hierarquia”, que é mais adequada à sua realidade.
O modelo, no centro, garante os interesses e agilidade do todo a partir de suas propriedades emergentes (restrições, recomendações e propensões) enquanto as instâncias garantem os interesses e agilidade local a partir das práticas que melhor se adequem a sua realidade.
Trabalhando desta forma, não há discussão sobre práticas melhores ou piores, mas sim sobre a coerência das práticas com o modelo e com o contexto local. Quando soluções são construídas de forma contextualizada, não há espaço para guerra de métodos.
Uma vantagem adicional desta forma de encarar a agilidade nos negócios é que a escala acontece de forma orgânica, já que o modelo vai sendo “puxado” pelas pontas a partir das instâncias, e não empurrado a partir de frameworks ou métodos.
E depois disso
As etapas de Brief, Sense e Design, do BUILD, podem ser executadas de forma iterativa e contínua, ou seja, feito isso para um com contexto da empresa, seguimos para o próximo, e assim sequencialmente; ou em eventos períodos, por exemplo “BUILD anual”.
