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.

#LeiaTambém

• “O Processo é soberano”
• Linguagem ubíqua e Contexto Delimitado

Blueprint? Que é isso? was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Olá para todos,

Um dos livros que li descreve a história da Pixar Animations desde os seus primórdios. Neste livro ficou marcado em minha mente o lema que trabalhou para manter a missão de cada um dos projetos no rumo da direção de sucesso.

“A História é soberana”

Este mantra foi usado na Pixar em todos seus projetos, servia para lembrar a todo momento o motivo e direção que deviam seguir. No processo de criação ou desenvolvimento é muito fácil deixarmos levar no envolvimento e dificuldades de determinados problemas tomarem nossa atenção e direcionar nossos esforços para direções adversas que acabam fugindo do objetivo principal.

Imagine a quantidade de problemas que tiveram na década de 90 para realizar cálculos de ponto flutuante com o objetivo de determinar adequadamente a quantidade de luz necessária para uma animação com um hardware com uma fração de processamento de nossos celulares.

O sucesso do primeiro grande projeto não haveria ocorrido sem que trama da história fosse envolvente e concisa.

Qual a relação entre Pixar e SAP sobre Processos?

Todas as histórias de sucesso têm muitas coisas em comum.

A SAP não alcançou esta predominância quase unânime do mercado de sistemas empresariais sem princípios fortes, sólidos e permanentes.

Obviamente isso não ficou marcado em uma simples frase, como no caso da Pixar. Está marcado na cultura empresarial na empresa, onde só poderemos entender trabalhando e convivendo no dia-a-dia passando nos vários departamentos e níveis organizacionais.

O “Processo é soberano” é o cerne da origem da SAP.

A SAP surge como um software de dentro da IBM para atender propósitos de processo ao qual a empresa “mãe” não esta disposta a investir para não desviar o foco na venda de hardware, de onde vinha seu principal montante de receita e lucro.

SAP é fundada na década de 70 e a adoção do seu sistema R/2 e R/3 ao longo da década de 80 e 90 está relacionado aos projetos de Re-Engenharia que correram o mundo. Onde grandes empresas, após um processo extremamente longo e caro, então: restava como tarefa final processos re-desenhados e extensos fluxogramas para que a empresa trabalhasse adequadamente ao invés de eternas brigas e conflitos entre departamentos. Restava a estas empresas desenvolverem sistemas em plataformas caras contratando analistas e desenvolvedores e mais um longo prazo para sua implementação. A SAP se tornava uma alternativa para encurtar os prazos, minimizar riscos atingindo os objetivos que foram descritos anteriormente.

Isso só foi possível desde que os sistemas implementassem as “melhores práticas” em cada um dos módulos em o sistema é organizado, salientando que são desenvolvidos de forma unívoca.

A formula do sucesso da SAP tem ingredientes importantes, além do processo implementado pelos seus sistemas:

1. Uniformidade de processos empresariais no mundo inteiro.
2. Plataforma de Desenvolvimento concisa, sólida escalável e multiplataforma.
3. Sistemas de parcerias, permitindo compartilhamento do risco e lucros.

Processos Universais

Processos empresarias das mais diversas empresas pelo mundo todo compartilham estruturas semelhantes:

• Níveis Organizacionais: Presidente, Diretores, Gerentes, Coordenadores, Trabalhadores; com algumas variantes de VP’s, Superintendentes, etc.
• Departamentos Comuns: Compras, Contabilidade, Contas a Pagar, Contas a Receber, Estoque ou Almoxarifado, Expedição e Logística (Entrada ou Saída), Marketing, Vendas, Financeiro, Recursos Humanos ou Departamento Pessoal e de Operações seja para Produção ou Serviços.

Estes departamentos, gerências ou diretorias cuidam dos mesmos processos, variando basicamente de valores, quantidades, volumes, distribuição geográfica ou importância dentro da organização.

Todos estes processos seguem princípios gerais em comum, em alguns casos regulados através de normas internacionais ou nacionais, como por exemplo princípios contábeis como US-GAAP, BR-GAAP que deram lugar para IFRS.

Empresas na bolsa de NY, todas devem ser SOX Compliance.

Processos fiscais e tributários são processos inter-empresariais controlados, auditados ou executados pelo governo.

Leis, acordos sindicais, praticas de mercado são comuns para contratação, demissão e pagamentos de funcionários.

Enfim, processo empresariais não foram criados pela SAP, eles vieram antes e foram entendidos, estudados e preservados acima de qualquer pretesto de desenvolvimento de software, restrições de hardware orientando a uma melhor prática atendendo os mesmos processos para todos seguimentos de indústria.

"Tenha o objetivo em Mente"

Definido implementação de processos através de uma ferramenta de software a fim de integrar áreas e departamentos empresariais facilitando o entendimento e comunicação.

O software que a SAP desenvolveu representa então uma proposta muito mais forte e entrega com valor agregado tangível e intangível dando foco no cliente final.

Nada é fácil, este objetivo gerou enormes desafios e requisitos muito fortes para arquitetura e desenvovimento multi-plataforma e multi-database, cenários que foram somente implementados com alcance mundial através do Java e sua JVM.

A genialidade e ousadia para o desenvolvimento da camada de aplicação fica em outro post…

#LeiaTambém

• Desenvolvedor por Hobby
• ABAP é mais forte do que você imagina

“O Processo é soberano” was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Instalar um (mini)SAP em uma VM é um passo importante. Todos devem ter seguido os tutoriais e videos do Flávio Furlan no ABAP101. Prova disso é que quando realizada a pesquisa por minisap no google de um ip vindo do Brasil, o tutorial do Flávio Furlan é o top 1 da lista.

Um ponto interessante é que esse é o primeiro passo para realmente ter o poder de SAP Basis, e então cortar qualquer dependência em que somos restritos em nossos projetos ou clientes.

Terminado o guia, pronto! Agora o que fazer?

Uma boa prática que é descoberta com pouco tempo de uso do minisap, é que devido ao consumo de memória, disco e processamento essa ferramenta não é ideal para as nossas maquinas. Caso você não possua uma maquina parruda, tudo começa ficar em câmera lenta e ter espasmos. — Eu odeio esta situação.

Todos, ou quase todos, temos banda larga em nossas residências e na maioria das vezes uma maquina encostada, então com uns 4Gb de RAM, vc pode instalar um Ubuntu Linux, instalar o MiniSAP e deixar ligado direto. Mas então teremos um novo desafio: Acessá-la de fora.

Então vamos seguir alguns passos para que tudo funcione de forma transparente e direta.

1 — DNS Dinamico

Nossos acessos domésticos de banda larga tem uma característica fundamental comparado a de um acesso empresarial, o IP é Dinâmico.

Assim para saber qual o IP no seu roteador, é necessário que alguém de dentro da sua rede entre no roteador e informe o endereço IP para quem está de fora acessar.

Para isto é possível utilizar um dos vários serviços que resolvem este problema, eu por exemplo utilizo: noip.

Outras alternativas estão listadas em:

http://alternativeto.net/software/no-ip/

Então assinando o serviço gratuito o próximo passo é registrar um hostname, no nosso caso por exemplo: bar8blog.ddns.net.

2 — Alterando a configuração de rede do MiniSAP

Este passo não precisa do passo anterior para ser executado.

Iremos configurar um IP fixo, e para isto vamos realizar alguns procedimentos que estão listados abaixo:

• No caso de estar utilizando alguma ferramenta de virtualização, é obrigatório que altere a configuração da rede para modo "Bridged", ou seja, a VM deve acessar diretamente a Rede.

• Verifique o IP da VM, no meu caso é uma VM Ubuntu Linux, caso o seu seja o mesmo execute o comando ifconfig, o resultado deve ser algo como 192.168.1.103, dependendo da configuração do seu roteador; altere para um IP tipo 192.168.1.50

3 — Alterando a configuração do seu Roteador (Port Forwarding)

O (Mini)SAP é instalado por default com System Number 00(zero zero), isto é o indicador das portas TCP que ele utiliza para ser acessado.

As portas são 32NN e 33NN onde NN é o System Number da instância do SAP. A porta 32NN é a porta de Dialog ou seja a porta que conecta o SAPGui, seja ele for Windows ou for Java.

A porta 33NN é a porta de Gateway, ou seja, a porta RFC. Alguns componentes do SAPGui utilizam esta porta como por exemplo o Screen Painter.

O procedimento aqui é adicionar um redirecionamento de portas 3200 e 3300 para o IP interno, ao qual o MiniSAP está configurado.

4 — Acessando o SAP

Agora é só configurar o SAPGUI e acessar via internet:

Desconecte sua internet doméstica, conecte o 3G no notebook e play!

Troubleshooting

Claro que nada vai funcionar de primeira, se você acha isto, é um tolo ou acredita em papai Noel. Então abaixo algumas dicas que poderão lhe ajudar com problemas corriqueiros:

• Primeiro verifique sua conexão do notebook está com internet e fora da rede doméstica.
• Verifique se o DNS está sendo "resolvido", para isto um simples comando de PING no CMD do windows já te dará a indicação, por exemplo: ping bar8blog.ddns.net, lembrando que deverá ser informado o dns que foi utilizado no momento do registro no no-ip ou em outro serviço. Caso não funcione, é possível que demore um pouco para "propagar" o dns até o servidor DNS da sua conexão de internet.
• Caso o DNS não esteja resolvendo, ainda existe a possibilidade de colocar o IP diretamente, ou seja, utilize 200.199.298.197 no lugar de bar8blog.ddns.net. Caso você tenha dúvidas em como descobrir o IP externo, verifique via roteador ou procure no google por my ip.
• Verifique se a conexão com o (mini)SAP está funcionando, e acessível na rede interna, para isto é necessário configurar a conexão local com IP 192.168.1.50.
• Verifique se a porta TCP está sendo bloqueada, para isto o melhor caminho é executar o comando telnet no CMD do Windows. Por exemplo: telnet 200.199.198.197 3200. Outra alternativa muito mais profissional é utilizar o nmap, que pode ser instalado pelo seguinte link. Assim, execute nmap 200.199.198.197 -p 3200 -Pn. Então esteja pronto para se sentir um hacker na Matrix.

NEXT

Simples… Fácil… Sim/Não…

Existem próximos passos, aguardem.

#LeiaTbm

• Tudo como Serviço — SaaS, IaaS e PaaS
• A SAP fez a sua lição de casa.
• Infinito, realmente é uma palavra muito longa.

#TODO — Acessando (Mini)SAP da Internet was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Diga-me para que serve, e farei com bom gosto.

Em meu trabalho sou movido por motivação e objetivos, sempre procuro olhar alguns passos adiante e entender o objetivo de meu trabalho e em cada uma das atividades diárias. Basta explicar e entender o objetivo que o restante acontece naturalmente.

Tenho pleno entendimento que nem tudo vai ser agradável, pelo contrário, sempre vai haver uma boa dose de amargo para um pouco de doce. Afinal não é assim para férias? Onze meses de trabalho para um de descanso.

No entanto a atividade que eu considero menos motivadora é o processo de documentação; seja para blueprint, processos, procedimentos, gaps e desenvolvimentos.

Sei que é uma atividade enfadonha, demorada, individual, burocrática e trabalhosa. Por si só, já começa pelo pé esquerdo, mas não é isto que me desagrada.

O que mais incomoda é que se trata de um trabalho que sempre é jogado no lixo (obviamente, depois de um tempo).

Vamos entender

Qual o objetivo da Documentação? Segue uma relação de explicações que tenho colhido ao longo de mais de uma década trabalhando com SAP, seja em projetos, melhorias pontuais ou suporte.

Interface entre Equipes

A documentação será utilizada por outra equipe a fim de entender o trabalho que está sendo realizado. Ou seja, serve de interface de comunicação entre equipes distintas.

• equipes de projeto x equipes de suporte;
• analista x desenvolvedor;
• consultoria x cliente;

Mitigar Riscos

A documentação servirá de subsidio para analisar impactos e dimensionar esforços de mudança, evitando-se erros e mitigando riscos.

• análise de impactos;
• entendimento de dependências;
• check list de revisões;

Gestão de Conhecimento

O que hoje é mais valorizado do que conhecimento? Nós consultores somos remunerados devido ao pleno conhecimento de sistemas SAP, nada mais; a única riqueza que temos é o nosso saber.

A documentação é o meio para que seja gerado o ativo de conhecimento a fim de que este seja perene entre todos os membros de um grupo, uma empresa ou uma corporação.

• Formalização dos motivos que geraram a atividade, tarefa ou projeto;
• Base de conhecimento para mudanças de pessoas na equipe;

Todos estes motivos fazem da documentação em atividades relacionadas a sistemas SAP um ótimo argumento para que a mesma seja realizada, concordo em gênero, número e grau.

A importância da geração e gestão de documentação não é restrita a processos relacionados a sistemas SAP. Pelo contrário, é atividade presente em qualquer outro sistema, sejam eles desenvolvidos, adquiridos, comprados ou licenciados.

O problema começa neste ponto. Os sistemas SAP têm peculiaridades e diferenças. Erra-se ao aplicar métodos envelhecidos e não adaptar métodos modernos além de desvirtuar o objetivo ao qual atende a documentação.

Segue uma relação de erros claros e praticamente repetidos sem questionamentos.

Documentação de Projeto x Documentação de Sistema

• A documentação que é produzida herda de processos e procedimentos criados em projeto, e portanto atendem especificamente ao ciclo de vida do projeto.
• O projeto tem começo, meio e fim. O sistema será utilizado e mantido após o fim do projeto, após isto o uso e utilidade da documentação terminam junto com o projeto.
• Projetos distintos, assim como melhorias não utilizam a mesma base de documentação, e portanto se tornam um risco não mitigado pela falta de governança centrada no sistema.
• Documentações de projetos e melhorias modificam as mesmas parametrizações e desenvolvimentos sem a união destas informações.
• Ao longo do tempo, várias melhorias mudam o sistema e até mesmo chegam a descaracterizar o que foi realizado no projeto de implementação, ficando a documentação desatualizada e sem utilidade.

Documentação de Planejamento x Documentação de Realização

Entre equipes de analistas e desenvolvedores, tem-se a “Documentação Funcional” e “Documentação Técnica”, geralmente são utilizadas para passar idéias e instruções do que é necessário e o como deverá ser implementado atendendo o objetivo inicial.

Geralmente durante a implementação encontram-se erros ou necessita-se de complementos, no entanto a documentação “aprovada” não é revista.

Caso a documentação seja revisada, geralmente não é feito um controle adequado das diferenças entre as revisões.

O foco da documentação é destinado para “instruir” de forma “planejada” a atividade que será realizada.

Quase nenhum esforço é destinado para documentar o resultado final da realização do sistema.

A documentação de processo e seus procedimentos é desassociada da documentação do sistema.

Documentação é para a Consultoria e não para o Cliente ou Sistema

Todos os tipos de documentos gerados em um projeto tem por objetivo proteger a consultoria a fim de sustentar todas as necessidades de mudança de escopo e esforços adicionais.

Quais documentos gerados não estão ligados a uma confirmação por um dos lados e estabelecem uma quantidade tangível de esforço e tempo?

O cliente contrata uma consultoria “A” ou “I” a fim de conseguir maturidade e conhecimento. No final das contas, cai em uma verdadeira “armadilha”, em que clientes são os fornecedores de munição de “fogo (falso) amigo”.

Caso seja realizada a documentação do sistema, consultorias e consultores entendem que estariam entregando o “ouro” do conhecimento e portanto não passam ao cliente.

Na prática, o sistema não é documentado

O resultado do trabalho em um projeto de implementação são configurações e desenvolvimentos para processos em execução em um sistema SAP.

Para isto configurações, tabelas e programas ficam em requests e abertos no sistema, os processo ficam a cargo dos usuários e key-users.

Necessitando informações do sistema verificam-se as configurações, programas e tabelas. Para os procedimentos de uso do sistema, é realizado entre usuários.

Confiança no sistema e conceitos implícitos

Para grande parte do mercado, Sistemas SAP são sinônimos de confiabilidade. Pois garantem processos sólidos e confiáveis, por exemplo, compreende-se que o SAP ERP calcula, registra e contabiliza adequadamente impostos. Os conceitos e detalhes de cálculo ficam implícitos no sistema, ninguém fica documentando este tipo de informação.

Conclusões e Considerações

• Existem casos e casos, nada neste mundo é 100% “X” ou “Y”. Existem casos que a documentação é realmente efetiva, bem feita, bem gerenciada.
• Para gerir adequadamente a documentação SAP é necessário um grande esforço, além de muita disciplina e maturidade. Consequentemente é um investimento muito alto, constante e muito fácil de perder a visibilidade de retorno. Pois o retorno é subjetivo a impactos intangíveis e imprevisíveis. Os Riscos podem ser medidos somente após erros em experiências anteriores.
• Casos conhecidos estão diretamente relacionados a obrigações e exigências externas, tais como FDA e SOX.
• O conhecimento para gerir adequadamente está além dos cursos e treinamentos. O conteúdo é focado em como utilizar o sistema.
• Obviamente, documentação não é lixo, basicamente coloco em “xeque” a verdadeira utilidade e beneficio. Quero focar em um retorno adequado de horas e horas de trabalho.

Caminhos e Soluções

1. Separar gestão de mudança do sistema com a gestão de projetos e gestão de problemas e incidentes.
2. Gerenciamento de “transport” requests ligados a um requisito, por exemplo o que é feito pelo Solman/Charm.
3. Automatizar e focar em documentação do Sistema com controle adequado de dependências entre objetos, versões e requests.
4. Gerenciar adequadamente a ligação “Processos” e “Modificações de Sistema”, permitindo rastrear mudanças, dependências e seus impactos, mitigando efetivamente riscos.

Para Refletir

Hoje a documentação é feita desta maneira pois sempre foi feita assim, projeto após projeto.

Complementando com um exemplo real

Na implementação foi utilizado para documentar uma ferramenta wiki, ao invés do diretório compartilhado de rede. Este repositório trata-se da uma das ferramentas de gestão de conhecimento.

Após 6 anos, passado por três consultorias, um funcionário formação no módulo de FI, conseguiu realizar sozinho, a implementação de uma nova empresa no SAP em 3 dias.

Somente através da documentação registrada e devidamente indexada.

Agora se curtiu o post não deixe de clicar no CORAÇÃO e participar comentando, pois assim você nos ajuda muito!

Documentação SAP: trabalho jogado no lixo (depois de um tempo) was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Este post complementa nosso primeiro post: "A quem possa interessar o Bar8", e vem celebrar o retorno que estamos tendo de todos que nos acompanham.

Toda vez que falamos que trabalhamos com informática, um leigo acaba nos associando a um problema no computador pessoal dele, tipo um problema de malware ou lentidão.

É a mesma coisa quando nós de informática, leigos em construção civil vemos um pedreiro concretando uma laje de um prédio. Para a maioria é simplesmente uma mistura de areia, pedra e cimento em algo parecido como uma forma de bolo, só que em tamanho maior. Agora pergunte ao pedreiro: O que ele faz?

Estou construindo um edifício com mais de 100 metros de altura e vai atender mais de 10.000 pessoas trabalhando.

O belo está em entender a magnitude e a missão. Não estamos expressando simples textos. Objetivamos passar uma mensagem que contribua, acrescente e ajude a todos evoluir; ambos: você que nos lê e nós que escrevemos. Também neste caminho, nem tudo são flores, vamos criticar e incomodar, pois críticas sempre são negativas, mas que ao menos sejam construtivas. Pois afinal de contas:

Para ajudar, é necessário compreender. Precisamos encontrar a origem das forças que regem nosso ecossistema nas mudanças que nos atingem diariamente.

O Efeito Blur

• Velocidade, conectividade e intangibilidade
• Abundância vs Escassez: entendendo a nova geração de valor.

O livro é bem antigo, foi publicado em 1999 e foi presenteado a mim pouco antes de ingressar como consultor SAP. Nem por isto deixa de ser atual e dominante.

BLUR?

Blur é o resultado da interação de velocidade, conectividade e intangibilidade. Blur ou "mancha", é assim chamado pois tudo que nos cerca perde limites ou rótulos. Vamos a alguns pontos de análise:

Vendedor vs Cliente.

Vamos tomar como exemplo de fornecedor um fabricante de sabão em pó e consequentemente seu cliente, uma rede de supermercados. Simples e Definido.

No entanto com o objetivo de incrementar as vendas do sabão em pó, o supermercado vende espaço de gondola para o fabricante, para que os produtos fiquem em áreas de maior movimento e visibilidade, neste caso o fornecedor é o supermercado e o cliente é o fabricante.

Os papéis se misturam, e a importância de rótulos ficam para um segundo plano. Agora ambos são ao mesmo tempo cliente e fornecedor.

No livro ou no resumo, verá outros exemplos e modelos de relação de troca.

Intangibilidade

O melhor exemplo que simboliza o avanço tecnológico são nossos telefones celulares. Desde os primeiros modelos analógicos até os mais modernos smartphones, muito mudou, alterando completamente a maneira de nos comunicarmos, entretermos e trabalharmos.

No início os celulares eram basicamente versões dos telefones comuns, só que em um novo formato, sem fios e com bateria, adicionando basicamente portabilidade. Porém, a cada degrau evolutivo claramente passa a ser exigido um incremento de velocidade e banda permitindo melhor conectividade.

Durante este tempo foi-se agregando funcionalidades. Através do simples display e teclado do aparelho, permitiu-se o envio de mensagens de texto. Em poucos anos, junto com a popularização e ampliação da rede, extinguiu-se todo o serviço de pager's.

Todos nós temos em nossas gavetas uma camera fotográfica digital. O que já foi uma ardente desejo de consumo, pois não precisava nem de filme ou revelação. Era uma revolução. Hoje praticamente são representante de um passado, aparentemente distante.

Os CD's representaram a transição para o modo digital, onde nossas musicas só estavam disponíveis de forma analógica em discos de vinil e fitas cassetes. Hoje, todos eles (CD's, Discos, Fitas, DVD's) não passam de ocupantes de espaço em armários. Substituidos de forma quase infinita por serviços online em praticamente qualquer lugar ou momento.

Game Watchs, Game Boys e PSP's são vendidos no eBay para saudosistas, substituídos por aplicativos com acesso e download imediatos em lojas virtuais sem necessidades de cartuchos e com recursos de interatividade social. Os atuais video games ainda estão vivos devido a capacidade de processamento e imersão que permite devido ao tamanho de nossas TV's. Logo darão espaços ao dispositivos de realidade virtual ou realidade aumentada.

Não existe dúvida, o incremento de valor é enorme e constante.

• Quanto valor foi adicionado?
• Resposta: O Valor adicionado é intangível.

Produtos e Serviços

Hoje não existe mais a segregação, pois um produto (um carro, por exemplo) vem sempre agregado a um serviço (assistência técnica e garantia). Serviços de telefonia são vendidos como produtos. E assim vão seguindo outros casos.

Conhecimento e Experiência

Cada situação em que passamos, seja ela positiva ou negativa agrega conhecimento e nos permite alcançar novas experiências.

Regra da Escassez e da Abundâcia

Houveram tempos que o acesso a informação e qualidade de conhecimento era difícil e caro. Neste cenário determinava-se o valor devido a sua maior escassez. Então o detentor do conhecimento, tinha interesse direto na preservação da escassez, a distribuição de informação era visto como uma ameaça.

A facilidade de acesso e capacidade de multiplicação da informação foram fundamentais para a transição, pode-se encontrar um valor maior pela abundância, vencendo o mito e a resistência para manter-se a escassez.

Estes fatos estão descritos no livro do Bill Gates, escrito em 1995 e também desde então ele mantem o título de "homem mais rico do mundo". Como referência, o livro foi lançado antes da chegada da internet comercial aqui no Brasil.

A revolução moderna da informação inicia-se com Johannes Gutenberg, através da invenção da impressão, minimizando o tempo e esforço de produção, multiplicando o alcance da informação.

A regra de escassez não deixa de existir, claro que de posse do primeiro release do windows garante uma posição privilegiada, no entanto, a ampla adoção do sistema operacional permite utilizar em outra lingua, sem ao menos conseguir ler, como um analfabeto (em japonês).

Microsoft, Google, Facebook, Alibaba, Uber, Airbnb, só conseguiram atingir os mais altos valores de mercado pela abundante base de clientes.

Competidores vs Colaboradores

As relações humanas e empresariais de longo prazo sempre serão baseadas em relações ganha-ganha. É necessário ampliar o entendimento para que meios de crescimento sejam encontradas entre competidores. Ouça a explicação da Bel Pesce:

Colaborar, Compartilhar são as leis que regem a nova economia: a economia da informação.

O que motiva o Bar8 was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

A partir de certo tamanho e tempo de existência, os maiores riscos para uma empresa não estão nos seus concorrentes, e sim residem dentro da própria casa. Ao longo dos anos a SAP foi bem sucedida reagindo ante as seguintes necessidades:

Ameaça On-Line:

A base de todos os princípios que fundamentaram o desenvolvimento do SAP até quase a virada do século vieram do Mainframe. O ABAP herda de Cobol e Adabas o controle de recursos de memória e processamento, que seguem a mão firme a distribuição de recursos a fim de que nada saia fora do controle. Integrações com sistemas externos são feitas através de troca de arquivos com estrutura de dados posicional. A saida de dados era feita através de Open Dataset e a entrada de dados mapeada e executada através de Batch-Input com Call Transaction.

Esta base de arquitetura de sistemas era o que se tinha de mais moderno para a sua época, serviu de fundação desde a versão R/2 até a versão R/3 4.6C.

O primeiro terremoto que fez a SAP se mexer foi o surgimento de sistemas Web, onde o processos de integração, que deixa de ser feito em "Batch", e passa a necessitar da execução do processamento e retorno em tempo real.

O ciclo de gravar arquivo, iniciar job, processar dados (muitas vezes em Batch Input) e retornar em arquivo para ser processado pelo sistema externo, passa a não atender a velocidade requerida no click de um browser.

A lição de casa foi dividida em duas partes:

1. Implementação de Gateway, onde a comunicação é feita através de RFC.
2. Refatoração de código, excluindo lógica de negócios na camada de apresentação.

Inicialmente o gateway que utiliza as portas TCP 33NN, onde NN é o system number da instância, era um binário separado em gwrd, onde a responsabilidade era receber a solicitação de RFC transportado pelo protocolo CPIC, servindo como "Adapter" para os módulos de função remotos a serem executados pelos mesmos processos de dialog no Servidor SAP.

A refatoração foi iniciada nas versões 3.X do R3 e se extendeu até a versão 4.6C. Isto pode ser verificado aproximadamente através da tabela TOJTB, onde são armazenados os dados dos "objetos" de negócios da transação SWO1.

Uma query na versão ECC6EHP8 nos dá o seguinte resultado:

• Total de Registros: 2709
• Registros com Criação com Release 3* e 4*: 1668

Portanto temos mais de 2/3 para esta "fase" de "refatoração", sendo que 1/3 estão incluidos novas funcionalidades diponibilizadas ao logo de 10 anos.

A SAP não conseguiu vencer no território Web, mas conseguiu ficar 8 a lado, tornando-se uma aplicação On-Line.

Mix de servidores de Aplicação

Na década de 70, a única alternativa de linguagem de programação que atendia a SAP com os requisitos de performance e portabilidade era a linguagem C.

A SAP desenvolveu um monstro de sistema: Total abstração de hardware, sistema operacional e banco de dados, permitindo uma "virtual machine" de ABAP, proporcionando assim, todo um ambiente de gerenciamento de memória, runtime e segurança com agilidade de desenvolvimento. Esta completa arquitetura de aplicação permite o foco em necessidades de negócio, ao qual o SAP R/3 se destina.

Em meados do ano 2000 a SAP começa abrir seu portfólio de produtos, pois até então era uma empresa de um produto apenas, tanto que seu principal produto o R/3 era (ou é até hoje) também chamado de SAP.

Surgem então as "New Dimensions", como eram chamadas: BW, APO, CRM, XI, EBP. A pressão interna para que a empresa não perdesse a onda ou o time-to-market, exigiu que a SAP utiliza-se boa parte da infraestrutura do SAP R/3. Estas aplicações não só exigiam nova programação ABAP, como também requeriam mudanças no Kernel original a fim de atender os requisitos de performance.

O BW necessita de algoritmos de geração e execução de SQL diferenciados para OLAP, pois o kernel foi desenvolvido com foco em OLTP. Além disto necessitava trabalhar com várias fontes de dados, inclusive outros bancos de dados, além do próprio banco da aplicação.

O APO no processamento de heurísticas de otimização necessita de transações em alta performance, o que deu origem ao "Live Cache". Podemos entender o Live Cache como sendo o pai do HanaDB.

O CRM por sua vez, na infraestrutura para o Internet Sales e o Mobile Sales, necessita transacionar dados de forma segregada do ERP sem deixar de manter integridade, por isto desenvolveu a infraestrutura de BDOC's, que seriam os IDOC's incluindo o próprio schema e no formato XML. Sendo distribuidos e organizados pelo CRM Middleware.

A base forte do Kernel do R/3 proporcionou o lançamento deste mix de aplicações em um curto espaço de tempo. No entanto, logo se tornaria também um problema grave e muito difícil de ser resolvido.

O kernel é desenvolvido em C/C++, e para atender ao mix de SO e DB, no final das contas temos mais ou menos 25 códigos fontes, pois atende a 5 SO's (Linux, Windows, AIX, Solaris, HPUX) e 5 DB's (MSSQL, SAPDB, Oracle, Sybase, DB2).

Quando surgiram as New Dimessions, o código base do kernel se multiplica por mais 5x, pois tem-se o kernel do R/3, BW, APO, CRM, XI, etc.

Temos agora 125 códigos bases para dar manutenção, atendendo alterações de bugs, melhorias e novas funcionalidades.

Nunca consegui descobrir qual sistema de versionamento de código que a SAP usa internamente, mas nenhuma solução de mercado resolvia adequadamente o processo de merges. Essencial para cenaríos com muitos "forks". Como referência, o problema de merge foi o principal motivo para que Linus Tovards desenvolvesse o Git durante o desenvolvimento do kernel do linux.

A Solução

Durante o boom do mix de soluções, a SAP lançou um produto que não foi adiante: o SAP Workplace, uma solução Web para atender com interface Web o acesso aos vários sistemas SAP sob o conceito de Portal. Pouca gente soube da existencia dele.

Para cobrir esta lacuna, a SAP adquiriu um empresa israelense chamada Toptier, e junto com ela veio um de seus fundadores:

Shai Agasi.

Shai Agassi | Wikiwand

Shai Agassi, foi quem arquitetou e colocou em prática o roadmap para a organização interna da SAP.

1. Unificação de todos os kernel's, unificando em uma só a plataforma de aplicação. Com esta unificação deu-se origem ao WAS: Web Application Server.
2. Reorganizar os sistemas a fim de formar uma nova plataforma de Solução. Dando origem ao SAP Netweaver.
3. Unificar o mix de soluções complementares de indústria em uma mesma solução.

Se tomarmos como base as soluções Financeiras, Logisticas e de Recursos Humanos do SAP R/3, R/3 Enterprise, ECC5 ou ECC6, qualquer um vai se dar conta que praticamente nada sofreu alteração. Em termos prático para usuários e funcionalidades.

O que mudou nestas versões foi a infraestrutura que está por baixo:

A) Do SAP R/3 para o SAP R/3 Enterprise, são unificados os "Basis", saindo da versão 4.6D para a versão 6.X, dando sequencia rumo ao Basis 7.X

B) Do SAP R/3 Enterprise para o ECC5, é implementada a funcionalidade de "Switch Framework". Para quem não teve a curiosidade, é a Primeira transação da arvore do Customizing de Referencia da SAP.

O Switch Framework surge junto com os "Implicit Enhancement Points", permitindo que uma solução de indústria "injete" código no código base do ECC (ERP Core Component).

C) Do ECC5 para o ECC6 é realizada a migração de todas as soluções de idústria da SAP para um mesmo sistema/produto.

Este é o motivo que ao longo de poucos anos temos tantas versões: a versão R/3 3.0 é de 1992 e a versão ECC6 é de 2005, tanto que inicialmente chamava-se SAP ERP 2005.

SAP R/3 | Wikiwand

Lição de casa feita: o SAP ECC6 segue seu roadmap estável, seguindo o processo de melhoria continua em uma base sólida:

• EHP's são lançados incluindo as melhorias, sem quebrar as funcionalidades antigas;
• Versões novas de SAP BASIS e SAP ABAP estão sob controle e são liberadas e atualizadas de forma rotineira.
• Os programas de upgrade de support packages e upgrade de versão estão unificados, realizando de forma sólida e controlada todos os passos para sua realização.
• Adição de Addon's ou Autilzação são controlados pela SAP através do MOPZ do Solution Manager.

Tudo isto reduzindo custos de suporte e manutenção simplificada tanto para o cliente como para a SAP.

Atualmente a última lição de casa, está sendo colocada à prova do mercado:

SAP HANA, SAP FIORI, SAP S/4.

Não deixe de conferir as referências abaixo, e se curtiu o post não deixe de participar comentando, compartilhando ou simplesmente segurando esse botão de aplausos para mostrar que é esse tipo de conteúdo que você deseja ter por aqui. Muito obrigado e até mais!

A SAP fez a sua lição de casa. was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nesta vida a única constante permanente é a mudança.

Apesar do ser humano ser a espécie neste planeta com a maior capacidade de adaptação, pois é capaz de viver em qualquer lugar deste planeta, a Mudança vem junto com riscos e consequentemente medo do inesperado, despreparo.

Linguagens de programação vem, vão, ficam, diminuem, quase desaparecem e regressam. Cada uma tem sua história e seu ciclo de vida.

Vamos dar sequência ao post:

Supondo que o ABAP morra. E daí?

Éclaro: Abap não vai morrer. No post, os comentários mais fortes estão relacionados ao "status quo", o volume de código existente não vai virar código "legado" na simples mudança de uma chave ou ordem gerencial.

É importante ressaltar que qualquer que seja a linguagem, ela é somente um meio para atingir um outro objetivo, normalmente um objetivo de negócios ou científico.

ABAP é mais do que uma linguagem. Trata-se de uma plataforma de aplicação.

Vamos comparar o Stack: "ABAP + Basis" com "Java", pois ambos são plataformas para aplicação de negócios empresariais, muitas vezes convivem lado a lado, com vários cenáros de interface.

Pontos em que ABAP é superior a Java:

• Java não tem Dicionário de Dados. Tudo é gerenciado com scripts de banco de dados: create table, alter table, etc. É necessário fazer o deployment manualmente, ou deve-se montar uma infraestrutura para isto, não existe nenhuma solução consolidada, cada projeto tem seu procedimento. Caso seja necessário alterar o tamanho de um campo, adicionar outro campo, … Está "F..".
• O banco de dados é tratado fora da aplicação, tudo deve ser configurado e controlado: connection string, conexão rede, pooling, autenticação, etc., no ABAP nada disso é necessário.
• Para acessar o banco de dados, no Java não existe um mesmo caminho, cada projeto utiliza uma arquitetura: JDBC, Hibernate, JNI, etc. No ABAP, o OPEN SQL é universal, seja qualquer que seja o banco de dados; na verdade, nem precisa saber qual banco estamos trabalhando.
• ABAP tem melhor performace, pois onde existem gargalos de processamento a SAP transfere o código para o kernel, obtendo performance de código feito em linguagem "C"; claro pois o kernel do sap é desenvolvido em "C". Por exemplo processamento de XML.
• No Java, a I18N (Internacionalizaçã0) deve ser feita "NA MÃO", não existe uma única solução, no ABAP está diretamente integrado na IDE, SE63, Dynpro, Basis, Kernel. Todo mundo sabe como fazer e como funciona (ou deveria). Uma única alteração no elemento de dados é necessária para replicar em todas telas.
• O Código ABAP também roda sobre uma "VM", assim como o Java. Assim temos: independência de plataforma, garbage collection (gerenciamento automático de memória), programas não derrubam o servidor (ou não deveriam).
• UI para Desktop em java tem várias alternativas: AWT, SWT, Swing, etc. Todos implementam somente componentes básico, tudo deve ser implementado. Vai tentar implementar um ALV em java… Também não existe uma arquitetura pronta para trabalhar em forma de Cliente-Servidor. Para fazer isto é necessário implementação de RMI, controle de sessão, etc.
• No java, para começar, precisa começar do… "LOGIN", começa pelo processo de autenticação: CAS, SAML, OAuth, AD, LDAP, etc. Depois tem que implementar o controle do controle de autorização, pois claro, nenhum sistema de autenticação faz controle de autorização.
• Vai tentar resolver um problema em PRD. Vai ficar fazendo scan de log em dezenas de arquivos, event viewer, log de banco de dados, trace de sistema operacional (ah, em várias máquinas), etc. No ABAP tudo está na mão: ST05, ST01, SE30.
• Depois de ficar MUITO, MUITO tempo vasculhando logs, e logs, e não conseguir achar nada, vai ser necessário realizar debug em produção.
• Nenhuma plataforma de desenvolvimento ou aplicação dá acesso ao debug, com código fonte de forma instantânea de dentro da própria interface de usuário.

Sempre teremos como ferramenta imbatível o:

ABAP é mais forte do que você imagina was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tenha o objetivo em mente.

Cada passo que damos nos leva a algum lugar, se não tivermos o objetivo em mente, damos oportunidade para não chegarmos a lugar algum e perdendo tempo.

Entre os profissionais que são contratados como "Programadores ABAP" temos de forma distinta dois tipos de profissionais: os "Codificadores" e os "Desenvolvedores".

Um modo simples para segregar em qual grupo você ou seu colega se encontra é analisando quais as perguntas que cada um faz.

Veja o seguinte digrama:

Observe: qualquer que seja sua pergunta, ela vai encaixar em uma direção; 100% de qualquer pergunta irá se encaixar no diagrama. Pode tentar.

Veja esta propaganda do canal futura, é bem antigo. No entanto não deixa de ser verdadeiro e atual.

Então use o simples princípio de escutar e observar mais, e procure expressar-se menos, conseguirá entender que:

Codificadores irão focar seu esforço em resolver perguntas como: o que deve ser feito (ou pior: o que seu chefe quer que você faça), em alguns casos vai ser proativo e procurar saber como deve testar.

Desenvolvedores vão questionar: para que serve este desenvolvimento? Qual problema iremos resolver?

Nós aqui do Bar8 temos interesse em incrementar a discussão e tratar questionamentos como:

A maneira que trabalhamos hoje, é a melhor maneira?

A única coisa permanente e constante é a mudança, insistir em fazermos sempre a mesma coisa e esperar resultados diferentes é a coisa mais idiota deste mundo.

O que te motiva?

Bem vindo.

Codificador vs Desenvolvedor was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Chefia e Liderança são formas de expressão do poder, no entanto existem momentos em que são confundidos com arrogância unida de ignorância.

Políticos tem que entender que a simples promulgação de leis não são garantia nenhuma que a sociedade irá absorver e obedientemente segui-las.

Veja um exemplo burro de quere mudar (talvez seja proposital):

Bernie Sanders: 'I do wish' Apple would bring manufacturing jobs back to the US

Com um poco mais de pesquisa, informação e compreenção da situação:

Trump says he'll force Apple to build in the U.S. if he's elected - here's why he's dead wrong

Outro caso em que ordens top-down não funcionaram, e com um pouco de análise, já se sabia que não ia dar certo.

IBM's Palmisano challenges his company to move to Linux desktop

Agora quando se encontra-se um consenso e uma maioria, não se pode segurar um movimento bottom-up.

Iceland: thousands demonstrate in Reykjavik calling for PM resignation - video

O nosso capítulo brasileiro, ainda vai tardar, mas o final já sabemos.

Você pode enganar poucas pessoas por muito tempo; enganar muitas pessoas por pouco tempo; nunca irá enganar muitas pessoas por muito tempo.

"Ninguém nasce sabendo"

Todos nós somos figuras errantes neste planeta, nascemos somente com uma carga inicial de habilidades embutida em nosso DNA, nada mais. Somente nossos instintos mais básicos.

Qualquer pessoa de grande proeminência, seja de riqueza, conhecimento, habilidade ou simplesmente respeitado por suas realizações, saiu do mesmo ponto de partida, nasceu como um bebê, assim como todo ser humano deste planeta, não sabia nem ao menos falar ou caminhar. Habilidades que demoram em média um ano de vida para chegar em um nível básico.

Neste processo de aprendizado, pode ter um suporte melhor ou maior de outras pessoas, mas trata-se de um processo exclusivamente individual.

Viver é um caminho de tentativas e erros constante agregando aprendizado a cada ciclo.

Cometer erros é o processo mais comum e natural que existe neste planeta. Tudo é tentativa e erro. A natureza está sempre fazendo novas tentativas e erros, somos cercado por erros por tentativas por todos os lados. É a base da teoria da evolução das espécies, ao qual se aplica a todo ser vivo neste planeta, desde virus, bactérias até elefantes e baleias, sem deixar de passar por nós, seres humanos.

No entanto os erros têm consequências, determinados tipos de erros nos levam à certos danos, em alguns casos, irreversíveis, como a própria morte. Portanto nosso instinto de sobrevivência está todo tempo alerta para que não cometamos erros, e portanto buscamos evitá-los.

A sequência de erros iguais e com mesma características são indicadores de burrice.

Aprender com os próprios erros e não errar novamente, trata-se de inteligência.

Agora aprender com erros dos outros, trata-se de Sabedoria.

Por toda história de sucesso sempre vai existir várias histórias e erros e fracassos. Falhar, errar faz parte da vida:

Para um jovem, as primeiras quedas e fracassos são a única referência, faz-se a extrapolação de tentativas e erros, temos 100%. Desiste.

O primeiro passo para o resultado final com sucesso é persistência e a visualização de resultado. Junta-se com ação. O final já é conhecido. No final das contas é uma questão de simples ciclos de seleção natural.

Somente com o tempo permite visualizar nosso erros e fracassos como sendo caminho ao sucesso.