Benefícios da unicidade e exclusividade no desenvolvimento de soluções no ERP CIGAM

Alex Nascimento

Atualmente a CIGAM está passando por uma mudança de paradigma com relação à sua tradicional metodologia de desenvolvimento. Começamos aplicando o SCRUM nas equipes trazendo uma estabilidade considerável para o nosso ERP. Agora temos pela frente um desafio maior ainda. Atender as necessidades particulares dos nossos clientes de forma única e exclusiva como os mesmos desejarem. Para isso nasceu a equipe de customizações e, fazer parte desta equipe me proporcionou perceber como a satisfação do cliente pode ser alcançada de forma simples e ágil. Nesse artigo, quero compartilhar com vocês uma ótima experiência que tive nos últimos tempos atuando na equipe de customizações.

 

Conforme publicado no artigo A Evolução do ERP CIGAM: Da nova funcionalidade à customização, por Marcelo E. Petry, quando desenvolvemos uma customização temos padrões e procedimentos a serem seguidos. Isso para que possamos atender a necessidade do cliente modificando o núcleo (kernel) do sistema o mínimo possível. Para isso, usando todo o tipo de recurso tecnológico possível, criamos aplicações de software customizadas (CAS – Custom Application Software),  que são basicamente pequenos projetos ativados apenas para determinado cliente. Explicarei detalhadamente, a seguir, usando como exemplo uma das customizações realizadas para o cliente Summit.

 

 

Caso do cliente

A necessidade que o cliente estava enfrentando é que ele utiliza controle de reserva futura com lote (funcionalidade padrão do sistema habilitada pela configuração ‘ES GE 2120 – Controlar Reserva Futura em múltiplas Unidades de Negócio’ e demais) e estava mudando o endereço físico da empresa. Com isso, havia milhares de pedidos de venda em sua base de dados que estavam reservando o estoque, impedindo que fosse possível criar as notas fiscais de transferência para o seu novo endereço. Bom, obviamente, a única solução seria desenvolver uma rotina que removesse as reservas de todos os itens de pedidos e que depois da mudança física de endereço realizada, o estoque estivesse ajustado, conseguisse retornar as reservas para os itens. Nesse caso, nada mais eficaz que customizar a solução apenas para esse cliente através de uma rotina. É a partir dessa necessidade que estarei detalhando um exemplo de customização.

 

 

Mapeando e entendendo a necessidade do cliente

Primeiramente, temos que entender claramente a necessidade do cliente. Ouvir dele o que está precisando, escutar suas ideias, discutir possíveis soluções, pensar nas consequências, acompanhar como ele opera o sistema, entre outros. Como essa troca de informações já é feita diretamente entre usuário e desenvolvedor, já começamos a agilizar o processo e trazer muita satisfação para o cliente. O fato de estar sendo ouvido por quem entende o que acontecerá por trás do sistema, passa-lhe segurança e confiança no que está sendo solicitado, além de diminuir a possibilidade de divergências nas informações. Nessa etapa, criamos o levantamento de requisitos. No meu caso, para atender a necessidade da Summit, que era bastante complexa, ficamos uma manhã discutindo e documentando o que seria realizado até obtermos o aceite.


 

Desenvolvimento da rotina

Depois de ter o levantamento de requisitos concluído, já tinha autorização prévia para o desenvolvimento da rotina que removeria as reservas e posteriormente as recolocaria. Então, por que esperar? Comecei a desenvolver no próprio cliente ao lado do usuário. Ele já dava suas opiniões sobre as telas, entendendo como funcionaria a rotina e percebendo a tamanha dificuldade para realização do processo.  Outro fator muito importante é que os testes já foram feitos e conferidos juntamente com quem utiliza o sistema. A facilidade de tratar as possíveis falhas diretamente no ambiente do cliente agregou uma rapidez no desenvolvimento impressionante.

 

 

Testes com o usuário final

Feita a rotina, bastava homologar na base de testes com o usuário. Este, por sua vez, avaliou criteriosamente cada detalhe que a rotina alterou nos itens de pedido, usou seus relatórios no CIGAM Report para conferir se realmente seus dados estavam sendo trabalhados como solicitou. O teste é uma das etapas mais difíceis e demoradas, pois estamos fazendo o “acabamento” do desenvolvimento. Após a conclusão dos testes, o cliente já sabia que tudo funcionava e sentiu segurança e confiança para permitir a execução em sua base de dados oficial.

 

 

Entregando a rotina/funcionalidade exclusiva

Essa era uma rotina chamada diretamente pelo menu CIGAM. Então para disponibilizá-la para os usuários, apenas criamos uma nova opção no menu.  Criamos essa opção usando a tecla fácil CIGAM <F10> e informando o nome público e diretório para acessar a aplicação exclusiva do cliente (ECF – uniPaaS Cabine File). 
Essa é uma prática comum para customizações que são chamadas diretamente através do menu.

 

Existem muitos casos onde a customização será ativada através de nomes lógicos. Um nome lógico apontará para o nome público, outro para a aplicação exclusiva, outro conterá o nome do botão e, assim por diante. Esses nomes lógicos ativam conectores (chamadas feitas através de Call By Name em programas do núcleo do CIGAM). Vejamos um exemplo prático abaixo:

 

Nessa imagem, mostramos um conector criado no task prefix da rotina de devoluções de saídas do CIGAM (programa CG03792). Para ativá-la, precisamos ter o nome lógico EX_CG03792TPI = S. Além disso, existe um nome lógico principal, que é comum a qualquer customização e é o EX_DISABLE_ALL, que sempre deve ser “N” (Não desabilitar) para que as customizações sejam ativadas. Se ele estiver diferente, nesse caso geralmente com “S” (Sim desabilitar), todas as customizações do ambiente serão desativadas.

No detalhe, podemos perceber a chamada do conector (linha 5 em letras azuis). Vejamos na imagem abaixo como ela é preparada. Como dito anteriormente, um nome lógico determinará o nome público (EX_CG03792TPICabPrg) e outro o caminho para aplicação exclusiva (EX_CG03792TPICab).

Na prática, esse conector estará chamando a aplicação exclusiva do cliente. Então a aplicação exclusiva estará dando o tratamento necessário para atender a necessidade do cliente, seja através de programas uniPaaS, chamadas de objetos de banco, entre outros.

 

 

Documentação

Após a conclusão da rotina, preparamos a documentação, que segue um padrão definido pela equipe de customizações em conjunto com as lideranças do desenvolvimento da CIGAM.  Nessa documentação, damos embasamento para que qualquer atendente do suporte consiga prestar auxílio  sobre alguma rotina/funcionalidade exclusiva no cliente. Explicamos os nomes lógicos que foram empregados, o nome do projeto, desenvolvedor responsável, nome públicos de programas e objetos de banco relacionados, o objetivo da customização, onde pode afetar e detalhamos como deve funcionar.

 

Por fim, o todo esse procedimento realizado no cliente levou um dia para ser concluído. O cliente esteve presente em todas as fases do desenvolvimento e pôde determinar como queria que fosse realizado. Isso trouxe um contentamento muito grande, pois o cliente sentiu-se peça fundamental do sistema. Ele determinou como tudo deveria funcionar já sabendo suas dificuldades e assim conseguiu aplicar o lema da CIGAM na prática:  Sua Vida Mais Fácil.

 

Alex Eduardo Nascimento
Desenvolvimento CIGAM / Cigam Software Corporativo

Novo Comentário