Jesuíno Lopes
Para atingir os objetivos foi preciso ações combinadas e reorganizações estruturais
A operação de um SAP ou outro sistema integrado de gestão empresarial (ERP) naturalmente envolve solicitações de diferentes áreas clientes para centros de serviços compartilhados (ou centros de competências). O processo de desenvolvimento das soluções é normalmente formado por etapas bem demarcadas, com diferentes interessados e participantes. Tem caráter multidisciplinar e costuma conviver com frases nada agradáveis como: “O problema é que o desenvolvimento é lento e há poucos desenvolvedores!” “O problema é na definição dos requisitos!” “Depois de pronto, o cliente demora muito a testar!”
Em algumas empresas, as áreas possuem multiplicadores, usuários-chave, ou até mesmo equipes dedicadas a configurar o negócio na plataforma. Se, por um lado, isto traz agilidade, pode trazer dificuldades também. O nível de autonomia de atuação de um demandante, justificado pela sua urgência e pela necessidade de atender regras específicas, pode gerar duplicação de soluções (devido a falta de sinergias e reusos) e um nível de customização que cobrará seu preço no custo de manutenção e de atualizações. O negócio cria, sem saber, uma grande dívida técnica.
Estabelecer um processo conhecido por todos os participantes e adotar práticas de governança não é nada fácil, mas muito necessário. Os obstáculos são os mais diversos, a começar pelo interesse de independência dos diferentes demandantes.
Além de métodos e ferramentas, será necessário habilidade, pragmatismo e coragem para que o CIO possa manter uma plataforma que não se torne um peso no custo do negócio e um elo fraco no value stream. Sim, um elo fraco, pois não conhecer e demonstrar bem essa cadeia de valor com sua importância e necessidades resultará em vários problemas como:
● dificuldades de coordenação estratégica para os times;
● dificuldade de capacitar os profissionais;
● alto turn-over;
● dependência técnica de alguns profissionais (real ou assim percebida pela companhia);
● dificuldade de identificar e gerir a capacidade do time;
● falta de lead-times conhecidos;
● falta de padrões;
● dificuldade para melhorar processos;
● feudos de poder.
Em paralelo, as empresas enfrentam o desafio da necessidade de diversificar o portfólio de produtos para atender um mercado cada vez mais segmentado - as plataformas e seus processos precisam ser ágeis e flexíveis. Afinal, foi para isso que criamos os centros de serviços compartilhados, não é mesmo?
Tudo isso somado e temos o maior dos pesadelos para a Tecnologia: gerar a percepção de ser um empecilho às necessidades do negócio.
Vamos descrever um caso pioneiro no Brasil, que foi tema de apresentação na ASUG (Americas’ SAP Users’ Group): como a utilização de práticas ágeis do Kanban e Scrum em um Centro de Serviços Compartilhados do SAP trouxe bons resultados em um cenário complexo de uma grande empresa, que exigiu ações combinadas e reorganizações estruturais.
Este caso ocorreu em um momento onde equipes multidisciplinares começariam a trabalhar juntas. Era preciso formar um time único e a jornada passaria de buscar entender o processo atual a ter indicadores definidos. Uma premissa era não fazer a gestão através de cronogramas e atividades. A meta era construir um time em torno de um objetivo único de criar um processo de gestão das solicitações.
Na etapa inicial, a própria equipe do Centro de Serviços Compartilhados fez um levantamento do processo de trabalho: o propósito do time, quem eram os envolvidos, o que cada um está fazendo, os limites de até onde ia o trabalho, etc. Com isto, geramos a primeira versão do quadro Kanban. Foi o início da gestão visual e tivemos resultados imediatos: visualização gráfica do sistema, classificação de demandas e definição dos estados iniciais de trabalho.
Para criar um espaço de discussão e aprendizado, havia as daily meetings — encontro rápido diário onde se trocava status das solicitações atuais e das metas diárias. A métrica inicial era o fluxo acumulado — quantidade de demanda por estado.
Com o alinhamento básico do time concluído, já era possível inserir novos conceitos. Antes, era preciso classificar bem as solicitações de acordo com o valor que agregavam ao negócio e aprender a quebrar o objetivo desejado em histórias menores — conceito fundamental para dar agilidade ao sistema. O time passou a identificar o que era “Evolução” e o que era “Produção”.
Após novas discussões, o quadro Kanban passou a representar a limitação da capacidade de cada etapa do processo e o conceito de que as atividades só podem ser “puxadas” se houver “vaga” para realizá-las. Resultado: alinhamento de expectativas de prazos e entregas.
Além de políticas de trabalho, ferramentas como User Story Cards, avatares e novos ritos (planning e reviews) foram introduzidos. A participação dos clientes foi fundamental e ocorreu principalmente nos plannings, onde se realiza a quebra das histórias e definição de critérios de aceite, e nos reviews, onde se apresenta as entregas.
A próxima etapa do time foi inserir a “Retrospectiva” nos seus ritos. Neste estágio, o próprio time definia o que começar, parar ou continuar a fazer para evoluir seu processo, além de conhecer o seu lead-time.
Como resultados da adoção dessas práticas, destacamos:
Identificação de Valor e Priorização
A participação ativa do cliente e a quebra de histórias fez com que as funcionalidades que mais adicionavam valor ao negócio fossem feitas primeiras, da forma mais simples e ágil possível. Tudo com transparência e consenso entre os vários demandantes.
Paradigmas Mudam
O ambiente mais participativo e as políticas de trabalho, além de promoverem uma melhor gestão do conhecimento, quebram feudos de poder e promovem uma verdadeira reorganização espontânea. Tempo ocioso não é para ser ocupado necessariamente com solicitações, mas pode ser usado para melhorar o seu processo interno - há que se afiar o machado!
Mitos Caem
A gestão visual e os ritos ajudaram a constatar que o “gargalo” não era o desenvolvimento (testemunhamos arrependimento de quem o culpava).
Redução de Estoque
Eliminamos em muito a quantidade de código que se gerava sem um teste sequer e que era, muitas vezes, abandonado.
Otimização do Processo
Novamente a gestão visual, os ritos e as políticas de trabalho promovem uma padronização do processo permitindo sua melhoria contínua.
Por fim, longe de definir fórmulas, o objetivo foi compartilhar o quanto buscar um modelo lean de trabalho com conceitos simples pode ser muito eficaz para tratar questões da nossa era do conhecimento, com resultados concretos para os negócios.
Nenhum comentário:
Postar um comentário
deixe aqui seu comentário