Blueprint? Que é isso?
Olá para todos!
O mundo evolui, gerações são renovadas, habitos são transformados, mas conceitos e princípios são praticamente eternos.
Resposta rápida (e antiga):
Blueprint é basicamente o processo de cópia heliográfica, onde os desenhos normalmente são de tamanhos grandes, necessitando de uma copiadora especializada, onde a cópia fica com a cor azul. Veja o vídeo para que possa entender.
- O processo de cópia era necessário para a distribuição correta da informação entre todos os interessados.
- Para entender o processo químico é apenas pesquisar na internet, o detalhe mais importante é que fica um cheiro quase insuportável de amoníaco.
- O processo de desenho, hoje em dia, totalmente em desuso era feito em papel vegetal (translúcido) com canetas especiais que utilizavam tinta nankim.
- O papel translúcido com desenhos opacos eram necessários para transmissão da imagem de uma folha (original) para a outra (cópia).
- Trata-se de um processo que era empregado desde o inicio do século passado, portanto o digital simplesmente não existia, porque tudo era analógico.
- A tradução técnica para "cópia heliográfica" para o inglês é "blueprint copy".
Agora a Resposta Longa:
O princípio fundamental de todo projeto é que o mesmo é progressivamente elaborado, ou seja, é composto de fases e a cada fase o projeto vai tomando mais corpo e se tornando realidade.
Com o intuito de formalizar o fim da fase de projeto (design) para a próxima fase de construção são entregues documentos onde são sintetizados de forma mais completa todo o plano de trabalho a ser seguido. Afinal de contas, planejamento é um dos fundamentos de execução bem sucedida de quase tudo que fazemos.
Tomando-se como exemplo o projeto de construção de um edifício, um dos blueprint é a entrega dos projetos de arquitetura, onde são apresentadas todas a plantas, cortes e fachadas do edifício a fim de que possa dar sequência aos projetos de elétrica, hidráulica, estrutura, esquadrias de janelas e portas, etc.
Os desenhos originais eram feitos em papel vegetal e desenhados com tinta nankim em pranchetas de desenho, todos feitos na mão e necessitando de um processo de formação específico.
Os desenhos quando finalizados, eram então distribuidos através do simples processo de cópia, como se tratavam de desenhos de tamanhos grandes, era necessário equipamentos e material específico para esta tarefa.
Com o tempo as máquinas de cópia heliográfica foram substituindo por foto copiadoras (xerox) de tamanhos grandes. Eu mesmo já passei horas tirando e dobrando as copias nos meus tempos de estagiário.
A data marco para a entrega do "blueprint" trata-se de uma das datas mais importantes, pois finaliza uma fase para dar início a outra. Esta data quase sempre estará no caminho crítico de qualquer cronograma.
Business Blueprint SAP, já velhinho.
A fase do projeto sap de implementação só dá inicio após a entrega do "Business Blueprint" onde estão documentados o levantamento e diretrizes para que sejam executadas as configurações iniciais de todos o sistema: estrutura organizacional, tipos de materiais, grupo de contas de clientes e fornecedores, plano de contas, determinação de contas de MM, FI, SD, etc.
A construção básica de uma ambiente SAP do zero trata-se:
- Basis (Ambientes do Landscape, Cópia de Clients, Rotas de Traporte)
- Customizing de Estrutura Organizacional
- Parametrização dos processos de cada módulo do SAP de acordo com a precedência e dependências entre eles.
- Dados mestres
- Carga de Saldos iniciais
- Dados transacionais e eventualmente dados históricos.
E Agora?
Vamos a uma reflexão controversa e paradoxal:
A apliação das metodologias de gerenciamento de projeto e técnicas industrialização para processo repetivos são úteis mas não devem ser cegamente copiados e aplicados para processos e projetos de desenvolvimento de software.
A principal motivação para o blueprint da construção de um edifício, claramente é para evitar riscos e reduzir impactos para a próxima fase de construção, pois refazer na fase de projeto (design) é muito mais barato do que na fase de construção.
O mesmo não vale para desenvolvimento de software, onde o maior custo e esforço é na fase de design (programação), comparada a fase de construção (compilação e deployment).
O impacto de adição de mais uma company code na configuração é infinitamente menor comparada com a construção equivocada de um pilar. Não estou afirmando que não existe impacto, claro que existem.
O importante é ficar claro que todo blueprint necessitará de revisão e o pânico ou aversão exagerada de erros é muitas vezes exagerada, claro existem projetos e projetos, para isto um bom tayloring é sensato.
Outra situação que confrontamos é justamente a oposta, que não é mais necessário nenhum blueprint, pois as metodologias ágeis entregam mais valor de forma mais rápida, justamente porque se faz uso do custo menor de "construção". Pode até ser … mas lembramos que não se deve perder o objeitvo em mente, sem esquecer de questionar os mesmos de tempos e tempos.
Do ASAP ao SAP Activated, a SAP se rendeu… finalmente.
Metologias ágeis são muito faladas atualmente, mas já são bem antigas.
O manifesto agil foi publicado em FEB/2001 representando o anseio de desenvolvedores, analistas e arquitetos em contraponto ao “modus operandi” de desenvolvimento que software que simplesmente copiou metodologias industriais e de gerenciamento de projeto.
O jeito metódico em bases perdurou por décadas em projetos SAP, pois por muito tempo que se trabalhavam eram projetos de implementação. Para isto utilizava-se o SAP ASAP (Acelerated SAP) um mix de ferramenta e metodologia focada na Implementação.
Com clientes entrando em produção a importância de manter o sistema rodando e implementar melhorias e mudanças gerou um novo framework de trabalho chamado ValueSAP, que girava em novos ciclos de implementação de outros ambientes SAP como APO, BW, CRM e ciclos de melhoria de novos funcionalidades.
No entento sempre olhando o processo de trabalho de forma externa para dentro do cliente SAP, sendo a consultoria a gestora do processo de mudança.
Sempre digo que o gap entre clientes/usuários de SAP e consultores entre processos e sistema é o maior risco de qualquer trabalho que realizei.
A fim de mitigar este gap, a solução sempre esteve no mercado: RUP — Rational Unified Process, que foi desenvolvido por uma empresa que incorporada pela IBM, o pilar da metodoligia era o desenvolvimento intertivo, em que as fases podiam ir e voltar de acordo com andamento do desenvolvimento, simplesmente porque sempre existe a possibilidade de erro e o maior erro está em não reconhecer o erro.
A interatividade é a base do SAP Activate, estreitando o tempo entre necessidades e entregas através de entrega de valor (menores) em ciclos curtos. Uma junção do sistema de deployment agil e validações e testes mais efetivos. Onde mais importante do que não errar é corrigir mais rápido.
Blueprint ou não Blueprint: Conclusão
A mesma de sempre: DEPENDE.
Até mais.
