- A implementação começa com um protótipo, no qual já foram implantadas cadeias de processos de negócios, que podem ser aceitos pelo cliente como público-alvo. Ao mesmo tempo, pode haver diferenças que devem ser eliminadas durante o projeto.
- Para atuar no projeto, é criada uma única equipe composta por consultores, representantes dos clientes do negócio e serviços de TI. Os representantes dos clientes são treinados durante o projeto e, em conjunto com os consultores, testam os protótipos do sistema, formulam os requisitos do sistema e aceitam a sua implementação. O serviço de TI tem uma parte ativa, implementa alguns dos requisitos e ao final do projeto leva o sistema para suporte.
- Durante o projeto, vários outros protótipos são configurados, que a cada iteração se tornam mais próximos dos requisitos do cliente. Durante o curso do projeto, os requisitos são especificados e alterados várias vezes.
Na verdade, em um grande projeto de implementação de ERP, princípios ágeis são aplicados - pessoas e interação são mais importantes do que processos, um produto funcional é mais importante do que documentação, a cooperação com um cliente é mais importante do que um contrato e a prontidão para mudanças é mais importante do que seguir um plano inicial.
Porém, nas condições de um contrato firmado com preço fixo, trabalhando com um grande sistema unificado, esses princípios precisam pousar. Sem condições e restrições adicionais, o projeto provavelmente não será concluído e certamente ultrapassará o orçamento.
Em primeiro lugar, este não é um desenvolvimento de sistema que pode ser iniciado em partes, como costuma ser o caso em projetos ágeis, quando cada iteração deve terminar com o desenvolvimento de um bloco funcional completo pronto para uso. Um sistema ERP só pode ser executado em sua totalidade e não em partes.
Em segundo lugar, se você não limitar os requisitos, seus esclarecimentos e mudanças serão infinitos, o projeto se estenderá e exigirá financiamento adicional.
Então, o primeiro problema é que o sistema ERP consiste em partes intimamente interconectadas, permeadas por processos ponta a ponta. Portanto, precisamos de um sistema holístico em todo o seu escopo a cada iteração. A tarefa é facilitada pelo fato de que o sistema não foi criado do zero, é um produto acabado. Freqüentemente, há uma solução de mercado ou um sistema pré-configurado com processos padrão que você pode usar como seu primeiro protótipo funcional.
Leva tempo para preparar o próximo protótipo. O sistema é grande, complexo, há muitos participantes do projeto, então leva pelo menos dois meses para preparar um protótipo, testá-lo e fazer comentários sobre ele. Em nosso caso, as iterações não são de duas semanas, como em um agile típico, mas de 2 a 5 meses.
A cada iteração fazemos um sistema completo, mas existem diferenças entre eles. Na primeira iteração, este é um sistema típico com processos padrão ou específicos do setor. Os processos padrão podem estar muito longe do que o cliente espera ver no final. Os processos no nível superior são os mesmos, mas os detalhes serão muito diferentes. Quando digo "cliente", quero dizer as pessoas que irão utilizar o sistema - independentemente da relação que o liga ao contratante - contratual, ou seja, trata-se de um projeto interno da empresa, onde o contratante pode ser o departamento de TI.
Depois de coletar os requisitos com base nos resultados do teste do primeiro protótipo, configuramos o segundo protótipo, no qual todos os requisitos que podem ser implementados com as configurações são implementados, os dados de teste do cliente são carregados, todas as questões que surgiram durante o teste do primeiro protótipo são resolvidas. O cliente percorre os processos de negócio do sistema, verifica até que ponto a implementação atual se adequa, quão eficiente é o sistema e atende aos seus requisitos.
Na segunda iteração, os futuros usuários do sistema não o veem pela primeira vez, se sentem mais confortáveis, apresentam novos requisitos que já são mais significativos e detalhados. O ideal é que todos os principais problemas sejam resolvidos durante esse período, porque as alterações se tornam mais caras quanto menos tempo resta antes do lançamento.
Na terceira iteração, já podemos começar a desenvolver extensões ou, como chamamos no jargão, "customizações" do sistema. Podem ser relatórios, procedimentos, formulários que estão ausentes no sistema standard, mas são muito necessários, porque nem sempre é possível ajustar os processos empresariais ao standard do sistema. A decisão de desenvolver extensões é feita após considerar todas as outras possibilidades, uma vez que seu desenvolvimento e suporte são um prazer bastante caro e isso é dinheiro adicional.
Estamos preparando o terceiro protótipo por vários meses para que se torne um sistema completo, próximo do alvo. Normalmente, o sistema está totalmente configurado, uma quantidade significativa de dados é carregada lá, todas as extensões críticas são instaladas. Ele está sendo testado exaustivamente com um grande número de usuários. Esse teste geralmente dura cerca de um mês.
Depois de testar o terceiro protótipo, restam comentários e dúvidas, sobre os quais traçamos um plano para o seu desenvolvimento. E todas as observações críticas devem ser eliminadas até o lançamento.
O ritmo do projeto nessa hora fica muito intenso, o tempo é comprimido, como durante uma luta. É preciso preparar instruções, treinar usuários, converter dados, realizar mudanças organizacionais. Surgem questões anteriormente não resolvidas, alguém lembra que se esqueceu de anunciar alguma circunstância importante ... Antes do lançamento, mais um teste de aceitação é realizado - e adiante, o início de um novo sistema.
Esta, é claro, é uma descrição muito superficial da abordagem iterativa para a implementação de um sistema ERP. A metodologia descreve em detalhes todos os processos, incluindo documentação, treinamento da equipe do projeto e usuários, conversão de dados, realização de mudanças organizacionais, etc., que na verdade não diferem de nenhuma outra abordagem de gerenciamento de projetos.
A questão surge naturalmente, como organizar o processo de forma a não ir para a quarta e depois para a quinta ou sexta iteração? Como você pode evitar o risco de mudanças descontroladas e esclarecimento de requisitos, que se desenvolvem naturalmente conforme você se aprofunda nos detalhes e, às vezes, devido a mudanças nos negócios?
Claro, existe esse risco e é muito significativo. Na entrada do projeto, os requisitos são fixados em contrato, mas via de regra são formulados de forma geral, e o diabo está nos detalhes.
Com a "abordagem em cascata" no início do projeto, os requisitos são fixados, o trabalho técnico é assinado, que se torna uma base formal posteriormente para recusar a alteração dos requisitos ou pedir dinheiro adicional pela alteração. Em uma abordagem iterativa, esse truque não é aplicável.
Entendemos que os requisitos estão sujeitos a alterações e serão alterados sem falha. Estamos investindo em tempo e dinheiro. A questão é a extensão dessas mudanças. Podemos cometer um grande erro e obter uma onda de novos comentários no final, especialmente se o cliente a princípio referir-se à participação no projeto de forma "desleixada", selecionar as pessoas erradas para a participação, não formular requisitos com clareza, esperar que "tudo ficará bem" depende de consultores - então, no final, temos problemas sérios.
Portanto, o componente mais importante para reduzir o risco de requisitos em expansão no final do projeto é o envolvimento do cliente. A mesma implementação do princípio do desenvolvimento ágil, segundo o qual a equipe trabalha em conjunto - o cliente e o desenvolvedor, em contato direto desde o início do projeto. Isso tem várias consequências importantes. Em primeiro lugar, a identificação precoce das necessidades reais e o não cumprimento dessas necessidades do sistema. Em segundo lugar, estando envolvido no processo de preparação do sistema, o cliente torna-se seu proprietário não no momento da sua transferência na sua forma acabada, mas gradualmente, ao longo de todo o projeto. Torna-se o resultado do trabalho dele e, ao final do projeto, torna-se impossível fazer afirmações como “seu sistema não está funcionando”, porque este é o sistema dele.
É uma boa prática quando as pessoas mais qualificadas e capazes de tomar decisões estão alocadas no projeto 100% do tempo. Em nossa prática, esses eram os proprietários dos processos de negócios, seus substitutos ou funcionários que gozavam da total confiança dos gerentes de serviço. Sim, é difícil, sim - não há pessoas a mais, sim - é difícil dar o melhor. Mas essa é a única maneira de fazer um projeto rapidamente e obter um sistema de alta qualidade. Os participantes do projeto dão um grande salto na compreensão de como funciona uma empresa, adquirem novos conhecimentos, aprendem a trabalhar de uma nova forma e, via de regra, isso lhes cria novas oportunidades de carreira. Você pode considerar o projeto de implantação do ERP como um evento de desenvolvimento de pessoal extremamente poderoso, como a criação de uma nova reserva de pessoal para gerentes.
A segunda coisa a se observar são as restrições de tempo do projeto. O cronograma do projeto deve ser agressivo e a data de lançamento não deve mudar. Se o projeto for esticado, a probabilidade de alteração dos requisitos de negócios aumenta. Se a data do projeto mudar, novos requisitos aparecem e a situação se repete: novamente o sistema não está pronto, vamos adiar o lançamento. A perfeição dos sistemas não será alcançada mesmo com prazos de projeto muito longos e todos os requisitos nunca serão totalmente identificados antes do lançamento. Somente a operação real mostra todos os gargalos e o que é realmente importante. Portanto, após o lançamento, há um período de estabilização de pelo menos três meses, durante o qual a equipe do projeto auxilia e educa os usuários, corrige erros, recebe novos requisitos e faz as melhorias necessárias.
Para resistir à tentação de adiar os prazos e expandir as demandas, todos devem ter um forte incentivo para cumprir esses prazos. Para o contratante, é claro, essas são obrigações contratuais e um orçamento. A motivação do cliente geralmente é formada de cima, a partir da administração ou dos acionistas da empresa. Por exemplo, um CEO que toma uma decisão de prontidão para o lançamento pode estar preso por uma obrigação para com os acionistas. O gerente do projeto e a equipe do projeto podem ser motivados por um bônus no final do projeto, sujeito ao cumprimento dos prazos. Os chefes de departamentos se depararão com a necessidade de arranque por encomenda do empreendimento.
Muito raramente acontece quando há um desejo sincero de lançar o sistema o mais rápido possível devido às expectativas agradáveis das novas oportunidades que ele oferece. O novo sistema é, antes de tudo, o estresse e a necessidade de passar de uma interface familiar para uma incômoda na primeira vez, para mais controle, para a necessidade de inserir mais informações. Os usuários finais quase nunca dão as boas-vindas a um novo sistema. Leva tempo para eles chegarem a um acordo e encontrar vantagens nisso. E se a motivação interna para o lançamento no prazo não estiver inicialmente embutida no projeto, o lançamento será adiado, pois os sistemas nunca estarão 100% prontos para o lançamento.
Dadas as datas de lançamento apertadas, torna-se impossível expandir e refinar continuamente os requisitos. A equipe do projeto, que inclui representantes dos clientes, deixa de indicá-los e começa a pensar nas prioridades, nas possibilidades de adiar algo, diante de um prazo inevitavelmente iminente. A tarefa do gerente de projeto é desde o início do projeto formar essa sensação de um lançamento iminente, de falta de tempo. O clima muito calmo na primeira metade do projeto significa que a segunda metade será extremamente estressante devido à corrida que é inevitável. Para isso, metas intermediárias devem ser definidas, e o cronograma do projeto é formado de forma que as primeiras fases do projeto sejam comprimidas no tempo, e por isso, é formada uma reserva para as últimas fases antes do lançamento. Existem diferentes estratégias na corrida de longa distância,mas aqui a estratégia deve ser a mesma - você precisa correr rápido desde o início, pode não ter força suficiente para acelerar no final.
Resumo de todos os itens acima:
- A abordagem iterativa fornece resultados muito melhores em termos de proximidade do sistema aos requisitos declarados e implícitos do cliente.
- O envolvimento total do cliente no projeto é absolutamente essencial para implementar esta abordagem.
- Para evitar a proliferação e o refinamento infinito de requisitos, os cronogramas do projeto devem ser rigidamente limitados e os participantes do projeto devem ser motivados a cumpri-los.
Claro, esses são apenas os princípios básicos, ainda existem muitas sutilezas que dependem das condições específicas, das características da empresa e da personalidade dos participantes. Em cada caso, tudo é decidido individualmente.