Mês julho 2011

O que é o iBOLT e qual é sua importância em um projeto CIGAM?

Adriana Mota

O iBOLT é o BPMS oficial da solução CIGAM, e pode ser facilmente implantado junto ao ERP. É um produto da Magic Software, que permite customizar e agilizar os processos empresariais, possibilitando a integração de processos entre o CIGAM e diversas aplicações, plataformas e bases de dados.

O iBOLT simplifica o processo de integração, separando a lógica de negócios da integração tecnológica. Você pode fazer alterações nos modelos de negócios, sem afetar o negócio real ou as camadas técnicas da empresa, ou seja, sem afetar a rotina normal do dia a dia da empresa.

 

Por que é tão importante ter uma suite de integração de negócios abrangente?

Os analistas do setor estimam que as empresas gastam entre 20 e 40% dos seus orçamentos  de TI em projetos de integração de negócios. A complexidade da tarefa de integração de sistemas é grande e aumenta cada vez mais devido à tendência de ampliação da cadeia de valor das empresas, onde surgem vários novos pontos de integração, tanto internos como externos à organização.

 

Quais são os objetivos de um projeto de integração em um projeto com o CIGAM?

Os projetos de integração iBOLT, garantem que:

* O CIGAM pode conversar com sistemas de front-end, como um site de e-commerce, por exemplo;

* O CIGAM pode conversar com sistemas legados;

* Aplicações e processos já existentes podem ser melhorados, através da automação de processos, protegendo o investimento já efetuado no CIGAM e nas outras aplicações envolvidas;

* O CIGAM pode conversar com o próprio CIGAM, criando cenários de automação de processos;

* A conectividade está disponível de forma a superar barreiras técnicas, tais como aplicações e bancos de dados diferentes;

* O ambiente integrado opera de forma totalmente transparente.

 

O que as ferramentas do iBOLT incluem?

O iBOLT inclui mais de 60 conectores, adaptadores e serviços que simplificam os projetos de integração.

 

Que tipos de usuários trabalham com iBOLT?

O iBOLT foi criado tanto para usuários técnicos quanto para não técnicos, proporcionando-lhes um ambiente de integração completo que apóia toda a abrangência de projetos Business Process Management (BPM) e Enterprise Application Integration (EAI). O conjunto de ferramentas de configuração e interfaces exclusivas do iBOLT potencializa toda a empresa, permitindo a total participação e colaboração em todas as fases do processo de integração, tanto das equipes de negócios quanto das equipes de TI.

 

Que capacidades de mapeamento de dados o  iBOLT inclui?

As capacidades de mapeamento de dados exclusivas do iBOLT  permitem  trabalhar com todas as fontes de dados e destinos, com  uma visão totalmente gráfica. Além disso, o iBOLT provê um gateway nativo para MS-SQL, My-SQL, Oracle DB2/400 e ODBC que permite que os dados sejam facilmente manipulados, através de um Gerador SQL baseado em wizards.

 

O iBOLT tem suporte a SOA?

Totalmente. O conceito de design fundamental do iBOLT é baseado no estabelecimento de funções de negócios e na exposição de processos de negócios como Serviços.

 

O que é exatamente o SOA e por que ele é importante para o processo de integração?

Diferente de arquiteturas firmemente acopladas onde as alterações em qualquer componente podem levar a mudanças de muitos outros componentes, SOA (Service-Oriented Architecture) é uma arquitetura que permite um desacoplamento entre componentes. Em um projeto SOA, você pode fazer alterações em componentes individuais sem ter que fazer alterações de outros componentes da arquitetura, permitindo assim que a sua seja muito mais ágil nas respostas às necessidades de mudanças.

 

Como o iBOLT permite SOA?

O Editor de Fluxos do iBOLT permite que você mapeie fluxos de negócios individuais que compõem cada processo de negócios, definindo as mensagens e dados trocados entre os componentes, e também suas interações e regras.

 

O que são Aplicações Compostas?

As aplicações compostas são montadas utilizando tanto componentes de várias aplicações quanto funcionalidades adicionais desenvolvidas especificamente como serviços. Os componentes individuais de uma Aplicação Composta são criados de forma independente dos outros, mas podem ser chamados e reutilizados várias vezes em diferentes aplicações. Como resultado, sua empresa pode obter soluções mais rapidamente com menos recursos – e garantir a coerência em toda a empresa.

 

O que o iBOLT Business Integration Suite inclui?

O iBOLT consiste de três módulos principais:

• iBOLT Studio: componente base, ambiente de implantação de integração e processos de negócios de alto nível que inclui o Business Process Editor para a modelagem real de processos, o Topology Editor que fornece uma representação gráfica das conexões entre as aplicações e os servidores, o Flow Editor que define os processos que existem entre as aplicações e os conectores e adaptadores pré-configurados do iBOLT.

• iBOLT Server: conduz o projeto de integração e gerencia todos os aspectos da implantação incluindo a execução dos fluxos, o  encaminhamento dos fluxos para diferentes servidores, e o acompanhamento de funcionalidades.

• iBOLT Monitor: oferece uma forma de visualizar a topologia de todos os servidores para monitorar atividades, ganhar visibilidade para o fluxo de negócios e processos, e obter em tempo real as informações de performance.

 

 

Como o iBOLT reduz custos e aumenta a eficiência?

Em um ambiente integrado, uma única alteração em uma aplicação, sistema, ou banco de dados pode gerar a necessidade de reformulação de muitos processos e conectores. O iBOLT Studio, com sua arquitetura portável e gateways e conectores embutidos, dá aos desenvolvedores uma forma de personalizar sistemas integrados rapidamente e, como resultado, os custos de manutenção são reduzidos.

Os diferenciais de cada negócio são mantidos com projetos de integração e automação personalizados para cada empresa, trazendo o conceito de “Empresa em Tempo Real”, agregando valor e eficiência aos negócios e processos.

iBOLT+CIGAM = Empresa em Tempo Real

Adriana Mota
Comercial / Magic Software Brasil

 




Um novo usuário chega ao mundo corporativo

Rodney Antonio Repullo

Rodney Antonio Repullo

Tradicionalmente, os sistemas computacionais de gestão empresarial contam com usuários sentados em suas mesas de escritório e, quando muito, nas bancadas das fábricas controlando sua linha de produção. Novos usuários impulsionados pela atual infra-estrutura de internet, poderosos smartphones, netbooks, tablets e uma onda de redes sociais que mais parece um tsunami, estão sedentos por aplicações corporativas que possam ser acessadas por seus novos brinquedos portáteis.

Usuários que estão a cada dia em um local diferente, visitando clientes ou em viagens de negócios, interagindo com os processos da empresa por fone (voz) ou através de formulários que necessitam ser digitados posteriormente em sistemas ou, na melhor das hipóteses, através de planilhas trocadas por email.

CIGAM no smartphone

Esses novos usuários demandam por aplicações móveis que possam acessar remotamente as informações necessárias para a execução de suas atividades, bem como, inserir informações em tempo real nos sistemas, evitando retrabalhos e agilizando os processos de negócios essenciais, aumentando dessa forma a competitividade de sua empresa.

Para suprir essa demanda, os provedores de soluções de gestão empresarial buscam migrar suas aplicações para viabilizar o acesso remoto, mas há um grande equívoco nesse processo. Esses novos usuários necessitam de interfaces adaptadas aos seus processos e que possibilitem uma execução simples e rápida. Esses novos usuários não se adaptarão a interfaces genéricas com dezenas de campos e formulários que não forem desenhadas para o seu processo.

Nesse sentido, a melhor solução que os provedores podem dar a seus clientes será a criação de um kit e/ou templates que permitam ao próprio cliente ou ao seu canal de implantação, o desenho de interfaces específicas para cada situação. Tanto o uniPaaS quanto o iBOLT atendem a essa demanda na modalidade de servidor de aplicações possibilitando a execução em dispositivos móveis e garantindo uma perfeita integração com o ERP CIGAM e outras soluções existentes.

O ERP CIGAM por ter uma integração nativa tanto com o iBOLT quanto com o uniPaaS sai na frente e se beneficia com grande facilidade dessas tecnologias.

 

CIGAM no tablet

Confira nossa demo de solução CIGAM com você (a partir do seu iPad, iPhone, Android, Blackberry, Nokia, etc) e comece a pensar quais processos de sua empresa ou de seu cliente possam ser atendidos com esse tipo de solução.

Leia mais sobre essa solução neste outro post.

Rodney Antonio Repullo – CEO Magic Software e Grupo Repullo

 

Padrões de desenvolvimento do ERP CIGAM para Bancos de Dados

Leandro de Matos Machado

Em tempos como o de hoje, onde as aplicações em geral cada vez mais precisam ter o máximo de performance para executar suas tarefas, um grande vilão torna-se o processamento de informações contidas no banco de dados. De certa forma não se pode fugir dessa realidade, ou desse caminho obrigatório a ser percorrido, mas podemos encurtar esse trajeto mudando o local desse processamento dos dados.

Para isso, podemos utilizar o processamento pesado, ou seja, aquelas enormes regras de negócios das rotinas do ERP CIGAM diretamente no banco de dados. Podemos fazer isso sem qualquer problema através de stored-procedures, functions, triggers dentre outros objetos de bancos disponíveis em banco de dados como Oracle e SqlServer.

Nesse ponto existe um consenso quase geral, inclusive alavancado por grandes nomes e tecnologias, citando, como por exemplo, a Microsoft e o .Net Framework respectivamente. Não basta apenas escrever código para objetos de banco ou consultas, também é preciso manter uma padronização de maneira que facilite a manutenção, bem como as evoluções.

Seria uma maravilha se pudéssemos desenvolver o ERP CIGAM para apenas um banco de dados, e no momento da venda o cliente se disponibilizasse a utilizar esse banco de dados “obrigatório”. Infelizmente, isso não é possível nos dias de hoje, considerando que o cliente já pode estar utilizando um banco de dados para outros aplicativos ou até mesmo outros módulos e rotinas em que se deseja que o ERP CIGAM integre.

Neste artigo veremos algumas características dos padrões adotados para o desenvolvimento de objetos de banco de dados, considerando principalmente a realidade que o CIGAM roda em diferentes bancos de dados com a mesma aplicação e que existirão objetos de bancos equivalentes em ambos os bancos.

O padrão

Em breve iremos disponibilizar para toda a Rede CIGAM o Padrão de desenvolvimento CIGAM (PDC). O PDC irá agrupar todos os nossos documentos que falam sobre padronização (interface, banco de dados, regras de programação, etc). Especificamente sobre o padrão de desenvolvimento para bancos de dados, este capítulo tem por objetivo detalhar a forma de escrever o código do objeto ou da consulta SQL que é utilizada diretamente no ‘SQL-Command’ do uniPaaS.  Nesse capítulo encontram-se, ainda, as regras, desde a capitalização dos caracteres, indentação, como até mesmo recursos que não devem ser utilizados, servindo como base e referência para todos os programadores e, inclusive, testadores. Sempre que os padrões forem alterados, quase sempre por inclusões, todos os afetados serão notificados para que possam fazer a leitura de revisão e adequação.

Existem muitos tópicos considerados importantes, ou seja, itens que se não cumpridos tornam o objeto ou consulta totalmente incompatível com as definições propostas. Hoje, porém, vou destacar somente alguns deles para conhecermos um pouco melhor:

 

Nomes

Os nomes dos objetos obedecem a um padrão que identifica pelo prefixo o tipo do objeto. Isso identifica claramente o tipo do objeto além de facilitar a localização em caso de depurações ou manutenção das rotinas. Exemplos:

  • Stored-procedures devem ter o nome iniciando com “CGPR_”, como CGPR_CALCULA_PLANO
  • Triggers terão o nome iniciando com “CGTR_”, como CGTR_EXCLUI_PARADAS
  • Views com “CGVW_”, como CGVW_ALOCACOES_DIARIAS

Arquivos de scripts

Cada objeto será contido em um arquivo, como o mesmo nome do objeto nele contido e com a extensão de acordo com o tipo do objeto.

Além de identificar de maneira clara a rotina da aplicação de manutenção consegue identificar e seqüenciar adequadamente os objetos no momento da criação em lote. A extensão do arquivo também está padronizada de acordo com o tipo do objeto. Exemplos:

  • O script de criação da stored-procedure “CGPR_CALCULA_PLANO” será contido no arquivo “CGPR_CALCULA_PLANO.prc”
  • O script de criação da view “CGVW_ALOCACOES_DIARIAS” será contido no arquivo “CGVW_ALOCACOES_DIARIAS.vew”

SQL Ansi

Sempre optar pelo SQl Ansi, ou seja, o padrão de código que é comum entre todos os bancos de dados. Quando um recurso/função existe apenas em um banco de dados, não deverá ser utilizado, pois no momento da conversão isso fará que existam diferenças na estrutura do objeto ou mais (ou menos) objetos que na versão para outro banco. Sempre que criado um objeto para um banco, o mesmo deverá existir no outro banco também. Caso o recurso/função não comprometa a estrutura de objetos citada anteriormente, deve ser criado o equivalente no banco em que não existe. Exemplo:

  • No Oracle existe a função ‘LPad’, inexistente no SqlServer. Para utilização, foi criada a função “CGFC_LPAD” para SqlServer

Conversão

O desenvolvimento é feito para um banco de dados e apenas convertido para o outro. Não confunda conversão com reprogramação. A conversão consiste em apenas mudar a sintaxe dos objetos para o outro banco, mantendo a regra de negócio idêntica.  Isso facilita muito as manutenções, pois quando alterado em um banco pode-se identificar as mesmas variáveis, cursores, condições, blocos de repetições, etc, no objeto do outro banco.

Nomes-lógicos

Nem todos os clientes utilizam as mesmas traduções para os nomes-lógicos. Neste caso, o script de criação do objeto deve conter uma seqüência especial de caracteres para que a rotina de manutenção possa identificá-los e traduzi-los no momento da criação do objeto. Exemplo:

select cd_material

from /*nl<ESMATERIAL>*/ESMATERI

No momento da criação do objeto, a rotina de criação substituirá o texto “/*nl<ESMATERIAL>*/ESMATERI” pela tradução do nome-lógico %ESMATERIAL%.  Notamos também que em tempo de desenvolvimento a instrução acima é perfeitamente válida, tornando possível a codificação com os nomes de objetos existentes naquele ambiente.

Acabamos de conhecer um pouco dos padrões de desenvolvimento para objetos e consulta de bancos de dados adotados para o desenvolvimento do CIGAM.  Para maiores informações, verifiquem o documento na íntegra.

Até a próxima.

Leandro de Matos Machado
Programador de Sistemas / CIGAM Software Corporativo

 

 

CMMI – Boas práticas no desenvolvimento e implementação do ERP CIGAM

Marcelo Petry

Atualmente a CIGAM Corporativa mantém um projeto interno, nominado “CIGAM Rumo ao CMMI Nível 3”, em que foi instituído um grupo de trabalho onde cada integrante ficou responsável por alguns requisitos, escolhidos de forma integrada com a função que o integrante ocupa na empresa, com o intuito preparar-se para a certificação do nível 3 de maturidade do CMMI.

Os principais objetivos desta fase do projeto são: elevar o nível de maturidade das metodologias MDC (Metodologia de Desenvolvimento CIGAM) e MTC (Metodologia de Testes CIGAM), com base nas práticas do CMMI nível 3, trabalhando aspectos como a gestão do conhecimento e a gestão integrada de projetos com métodos ágeis, como forma de aumentar a satisfação da Rede CIGAM, lembrando que na fase anterior implementamos o escritório de projetos (PMO) para implementação do ERP CIGAM. Mas, afinal, o que é este tal de CMMI?

Capatibility Maturity Model Integration ou, em português, Modelo de Capacidade e Maturidade Integrada é o que conhecemos por CMMI. O CMMI é um modelo de referência que contém práticas (genéricas e específicas) para desenvolvimento, manutenção e implementação de software e tem, portanto, relação direta com os conceitos de qualidade nos processos de software, a partir da capacidade e maturidade que a empresa possui para desempenhar de forma eficiente e eficaz os processos para o desenvolvimento, manutenção e implementação de software. Foi desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon com base nas melhores práticas de trabalho, identificadas, estudadas e medidas a partir de longas pesquisas.

 

O CMMI tem 5 níveis que determinam a maturidade da empresa, sendo cada estágio uma base para o próximo. É como uma escada que deve ser subida degrau a degrau, conforme a capacidade e a maturidade da empresa. Abaixo podemos destacar os 5 níveis de maturidade do CMMI e o que, de forma sucinta, cada degrau representa, conforme imagem abaixo:

 

Nesta representação, a maturidade é medida por um conjunto de processos, sendo necessário que todos os processos até o nível requerido atinjam o nível de maturidade necessário para que a empresa seja certificada naquele nível do CMMI. São acumulativos e representam estágios que devem ser alcançados até o nível máximo de maturidade, onde o foco passa a ser a manutenção e melhoria contínua. Na imagem abaixo podemos verificar todas os processos de cada nível:

 

Algumas etapas compõem as exigências para este modelo. São elas: auto-conhecimento e capacitação, que consistem na compreensão da real situação atual e as melhorias necessárias, o  planejamento, que abrange a equipe de trabalho, execução, validação, disseminação,  momentos em que os processos recebem a implantação das práticas CMMI e, por fim, vêm as etapas de homologação e encerramento, que abrangem a validação das lições aprendidas. Na seqüência, segue o propósito de cada processo, segundo o manual do CMMI:

 

Ø  Nível 2 – Gerenciado: No nível 2 do CMMI, os processos são caracterizados por Projeto e as ações são freqüentemente reativas.

Gestão de Requisitos: O propósito da Gestão de Requisitos (REQM) é gerenciar os requisitos dos produtos e componentes de produto do projeto e identificar inconsistências entre esses requisitos e os planos e produtos de trabalho do projeto.

Planejamento de Projeto: O propósito do Planejamento do Projeto (PP) é estabelecer e manter planos que definam as atividades de projeto.

Monitoramento e Controle de Projeto: O propósito do Monitoramento e Controle do Projeto (PMC) é proporcionar um entendimento do progresso do projeto, de forma que ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto desviar significativamente do plano.

Gestão de Acordo com Fornecedores: O propósito da Gestão de Acordo com Fornecedores (SAM) é gerenciar a aquisição de produtos de fornecedores.

Medição e Análise: O objetivo da medição e análise (MA) é desenvolver e sustentar a capacidade de medições utilizada para dar suporte às necessidades de gerenciamento de informações (indicadores).

Garantia da Qualidade de Processos e Produto: O propósito da Garantia da Qualidade de Processo e Produto (PPQA) é munir a equipe e a gerência com uma visão clara sobre os processos e seus produtos de trabalho associados.

Gestão da Configuração: O propósito da Gestão de Configuração (CM) é estabelecer e manter a integridade dos produtos de trabalho, utilizando identificação de configuração, controle de configuração, balanço de configuração e auditorias de configuração.

 

Ø  Nível 3 – Definido: No nível 3 do CMMI, os processos são caracterizados para Organização e são proativos.

Desenvolvimento de Requisitos: O propósito do Desenvolvimento de Requisitos (RD) é produzir e analisar os requisitos de cliente, de produto e de componente de produto.

Solução Técnica: O propósito da Solução Técnica (TS) é projetar, desenvolver e implementar soluções para requisitos. Soluções, designs e implementações englobam produtos, componentes de produto e processos de ciclo de vida relacionados ao produto isoladamente ou a combinações de produtos quando apropriado.

Integração de Produtos: O propósito da Integração de Produto (IP) é montar o produto a partir de componentes de produto, garantir que o produto integrado execute as funções de forma apropriada e entregar o produto.

Verificação: O propósito da Verificação (VER) é assegurar que os produtos de trabalho selecionados atendem aos seus requisitos especificados.

Validação: O propósito da Validação (VAL) é demonstrar que um produto ou componente de produto atende ao seu uso pretendido quando colocado em seu ambiente alvo.

Foco no Processo Organizacional: O propósito do Foco no Processo Organizacional (OPF) é planejar, implementar e implantar melhorias do processo organizacional com base na compreensão dos pontos fortes e pontos fracos atuais dos processos e dos ativos de processo da organização.

Definição do Processo Organizacional + IPPD: O propósito da Definição do Processo Organizacional (OPD) é estabelecer e manter um conjunto de ativos de processo da organização e padrões de ambiente de trabalho disponíveis para uso. Para IPPD, Definição do Processo Organizacional + IPPD cobre também o estabelecimento de regras e guias organizacionais que possibilitam a condução de trabalhos realizados por equipes integradas.

Treinamento Organizacional: O propósito do Treinamento Organizacional (OT) é desenvolver as habilidades e o conhecimento das pessoas para que elas possam desempenhar seus papéis de forma eficiente e eficaz.

Gestão Integrada de Projetos + IPPD: O propósito da Gestão Integrada de Projeto (OPD) é estabelecer e gerenciar o projeto e o ambiente dos stackeholders relevantes de acordo com um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização. Para IPPD, a Gestão Integrada de Projeto + IPPD cobre também o estabelecimento de uma visão compartilhada para o projeto e o estabelecimento de equipes integradas que irão cumprir os objetivos do projeto.

Gestão de Risco: O propósito da Gestão de Risco (RSKM) é identificar potenciais problemas antes que ocorram. Para isso, as atividades de tratamento de risco podem ser planejadas e colocadas em prática quando necessário, durante a vida do produto ou do projeto, para mitigar impactos indesejáveis na obtenção dos objetivos.

Análise de Decisão: O propósito da Análise de Decisão é analisar decisões possíveis usando um processo de avaliação formal que avalia alternativas identificadas com relação a critérios estabelecidos.

 

Espero que, a partir deste artigo, tenha ajudado no entendimento do que é o CMMI, enquanto modelo de referência com boas práticas no desenvolvimento e implementação de software. Fica a promessa de criação de novos artigos sobre o mesmo tema, onde então relacionarei cada processo do CMMI com as atividades práticas da CIGAM Corporativa no desenvolvimento e manutenção do ERP CIGAM.

 

Marcelo Eduardo Petry
Gerente de Produto e Tecnologia / Cigam Software Corporativo

 

Cigam com você – Mobilidade sob medida

Manoel Frederico

Neste post anterior, abordamos alguns aspectos do uso do UniPaaS como ferramenta de personalização e customização do CIGAM.

O UniPaaS é uma ferramenta profissional de desenvolvimento de soluções (sistemas) de negócios, que possui entre seus muitos recursos, a capacidade de atuar como um servidor de aplicações (tanto na intranet quanto na internet). Além dessas capacidades que são genéricas, o uniPaaS tem a habilidade de chamar componentes do CIGAM, pois é a tecnologia nativa desse produto. Isso traz um grande poder de desenvolvimento de soluções sob medida para necessidade de acesso através de dispositivos móveis.

Muitas empresas estão hoje em busca de soluções em dispositivos móveis, porque entendem a importância de participar deste novo mundo móvel e interativo, e dos benefícios que isso traz aos seus negócios.

O UniPaaS RIA Mobile é uma opção atraente neste vasto conjunto de tecnologias móveis que está sendo oferecida, porque é capaz de atender a múltiplos dispositivos. Aliás, um dos dramas ao se procurar soluções em sistemas móveis é justamente encontrar aquela que seja capaz de atender a esta grande variedade (smartphones, celulares, …) de dispositivos que possuem os usuários. Dentro desse conceito o uniPaaS já está disponível em Windows Mobile e Blackberry (final de julho) e estamos na expectativa da liberação para Android e iPhone nos próximos meses.

Agora independente do RIA Mobile, hoje já temos solução Mobile para o CIGAM disponível dentro da tecnologia Web Merge e é sobre ela que queremos dar o foco neste post.

Uma coisa que passa despercebida às vezes, é que um dos apelos da nova realidade dos dispositivos móveis é a conectividade on-line. Estar sempre ligado à internet. Por isso, quase todos os dispositivos possuem um navegador web.

Como o UniPaaS pode atuar como servidor de aplicações web (mencionado acima), uma coisa conduz à outra: o UniPaaS conecta o seu CIGAM aos dispositivos móveis.

Veja Como:

Desenvolvimento de aplicação “web” UniPaaS integrada ao CIGAM:

Execução desta aplicação “web” em dispositivos móveis:

Se você possui um dispositivo móvel (Blackberry, iPhone, iPad, Android, Nokia S60, …), acesse o endereço: http://websolution.magicsoftware.com.br/CIGAMcomVC e veja como é fácil ter o CIGAM na palma da sua mão e sempre com você.

Esta tecnologia já está disponível, através do uniPaaS, para desenvolver soluções customizadas e sob medida para o seu projeto do ERP CIGAM.

Manoel Frederico da Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil

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