Mês junho 2011

Road Map para Evolução do ERP CIGAM

Marcelo Petry

Conforme prometi no artigo onde falei sobre customização, este artigo tem por objetivo discorrer um pouco sobre o que é um Road Map e a sua relação com a evolução do ERP CIGAM. Conforme já registrado em outros artigos deste blog, já sabemos que o Road Map é o contraponto da customização e que é elaborado pelos Analistas de Negócios, porém, como é algo muito novo para todos da Rede CIGAM, vale a pena entender um pouco mais sobre o assunto.

Uma das definições para Road Map é que se trata de uma visão estendida do futuro de um campo escolhido de investigação composto de uma coletânea de conhecimento de pesquisadores nesse campo. Algumas palavras que também ajudam no entendimento são ‘guia’, ‘roteiro’ e ‘plano’. Enfim, Road Map é um plano com metas de médio e longo prazo com soluções específicas para ajudar a cumprir metas definidas na criação e/ou evolução de um produto e/ou processo, sendo que, o desenvolvimento deste plano tem pelo menos quatro finalidades:  ajudar no alinhamento dos stakeholders; ajudar na formatação da estratégia que será utilizada para que se atinja os objetivos estabelecidos;  ajudar no planejamento das atividades; e ajudar na coordenação da execução das atividades.

Enfim, a evolução do ERP CIGAM passa a acontecer com base em Road Maps, que definem quais funcionalidades o sistema deve passar a atender, por área de negócio e em dado período de tempo, que estamos definindo sempre como anual. Estes Road Maps são construídos pelos Analistas de Negócio em conjunto com a Área de Mercado, P,D&I e parceiros da Rede CIGAM. Neste momento, vale lembrar o que registrei no artigo sobre a função do Analista de Negócio, que é o profissional que “busca as melhores oportunidades de negócio, analisa tendências, cria novos produtos, recria produtos existentes, está sempre preocupado em encontrar novos caminhos para a empresa, complementando funções como as de analistas de processos e analistas de sistemas, buscando unir o melhor de cada uma destas funções a partir da visão sistêmica e orientada ao negócio da empresa”.

A tarefa de montar um Road Map tem a finalidade de mantermos um alinhamento entre os objetivos estratégicos da Rede CIGAM com a equipe de desenvolvimento do ERP CIGAM. Para isto, os Analistas de Negócios avaliam pelo menos três níveis dos negócios: mercado, produtos e serviços, e tecnologia, estando sempre atentos para a evolução do mercado, analisando as oportunidades, principais ameaças e concorrentes, bem como, avaliando as customizações de forma a incorporar as melhores práticas ao produto. Desta forma, garantimos que o que oferecemos realmente é o que os clientes e o nosso mercado necessitam, e garantimos que estamos gerando valor de negócio para este público, cumprindo com a nossa missão que é de “Promover crescimento e maiores resultados a nossos clientes com nossas soluções de software e serviços”.

O planejamento do Road Map da CIGAM será anual, com revisões semestrais e entregas trimestrais, conforme liberações das versões oficiais do ERP CIGAM. Todo o controle se dará a partir do módulo de Gestão de Serviços do próprio ERP CIGAM, permitindo assim, que as OSs de sugestões aprovadas, de clientes, parceiros e internas, que se referem a uma funcionalidade do Road Map,estejam vinculadas ao Road Map, permitindo assim a gestão da evolução do produto e de como cada uma das sugestões realizadas pelos clientes e toda a Rede CIGAM estão sendo implementadas. Em breve estaremos disponibilizando para toda a rede o que irá compor o primeiro Road Map da CIGAM, com o grupo de funcionalidades que ainda pretendemos atender no ano de 2011.

Espero que a partir deste artigo tenha conseguido esclarecer sobre o que é um Road Map e sobre como usaremos esta ferramenta com o objetivo de gerir todo o processo, mas, principalmente, de evoluir o ERP CIGAM com soluções robustas de mercado de forma a impulsionar as vendas do ERP CIGAM, conforme estratégia de vendas vigente.

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

iBOLT na Vida Real de um Projeto CIGAM – Episódio 02: “Conectando o CIGAM com a nuvem”

Manoel Frederico

Computação em nuvem é o tema do momento. Nuvem = internet, e de forma resumida, estar na nuvem significa ter informações e aplicações da empresa na internet. E isso é bom, a despeito de todos os detalhes que envolvem o processo. Estar na nuvem dá mobilidade e acessibilidade à empresa, o que resulta em melhor competitividade, quesito muito importante para o objetivo final: lucro.

O iBOLT é a ferramenta ideal para conectar o CIGAM à nuvem. Vamos abordar então, a primeira das duas vias desta conexão: levar.

Vamos considerar uma situação bastante comum, envolvendo “a nuvem” e as empresas: e-Commerce.

 

Sites e portais conectam a empresa aos seus fornecedores e consumidores (através da internet = nuvem), em busca dos resultados mencionados acima.

Considerando como exemplo de um portal de venda, surge a primeira necessidade: os dados do CIGAM precisam estar disponíveis à nuvem:

 

Usando-se os recursos visuais, assistentes (componentes) exclusivos e eficiente paradigma de desenvolvimento, o iBOLT pode disponibilizar qualquer informação do CIGAM para quem necessitar:

 

Com uma vasta biblioteca de componentes:

 

É possível, por exemplo, disponibilizar seu cadastro de clientes, relação de faturas em aberto, lista de preços, enfim, toda e qualquer informação do sistema CIGAM pode ser acessada na nuvem através do iBOLT, conforme as suas regras de formatação e segurança:

 

E com um diferencial: o iBOLT compartilha da mesma tecnologia utilizada no CIGAM e é o único ESB capaz de integrar-se 100% com as suas regras de negócio.

A nuvem está aí, e o CIGAM está preparado. Dê este passo, e leve a sua empresa a alçar novos vôos.

 

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

Os Analistas de Negócios na construção do ERP CIGAM e na potencialização de Projetos de Implementação

Marcelo Petry

Em tempos onde falamos de Road Maps criados pelos Analistas de Negócios CIGAM, é fundamental entender um pouco mais sobre esta função, suas habilidades e suas tarefas e o diferencial que temos ao explorar bem as suas potencialidades. É o que tentarei esclarecer neste artigo.

Na verdade, não existe uma definição única para a função de Analista de Negócios. Para os analistas da Forrester, poucas pessoas são capazes de oferecer uma definição padronizada (com conjuntos típicos de habilidades, métodos de treinamento apropriados e carreira profissional) para o cargo, pois suas funções podem variar de acordo com as necessidades e a realidade de cada empresa. No entanto, podemos destacar que, de forma mais ampla, estão entre as suas principais atribuições: o entendimento das necessidades dos stakeholders (partes interessadas), que muitas vezes têm dificuldades de externar suas necessidades; o entendimento dos requisitos de negócios; e a comunicação entre Negócio e TI. Para que consiga desempenhar estas funções, o Analista de Negócios deve entender: como a empresa trabalha; qual a razão de sua existência; seus objetivos e metas; e como a empresa busca os seus objetivos.

Segundo o IIBA (International Institute of Business Analysis), a análise de negócio possibilita entender a estrutura, as políticas e operações de uma organização e possibilita recomendar soluções para que esta organização atinja seus objetivos. O Analista de Negócios age como elo de ligação entre os integrantes de uma organização para obter, analisar, comunicar e validar necessidades de alterações em processos, políticas ou sistemas de informação. Ele entende os problemas e as oportunidades e recomenda soluções. O BABok  (Business Analysis Body of Knowledge) é um guia de referência da IIBA que resume o conhecimento dos profissionais que exercem a função de Analista de Negócios, bem como, também descreve as melhores práticas da função.

Enfim, o Analista de Negócios busca as melhores oportunidades de negócio, analisa tendências, cria novos produtos, recria produtos existentes, está sempre preocupado em encontrar novos caminhos para a empresa, complementando funções como as de analistas de processos e analistas de sistemas, buscando unir o melhor de cada uma destas funções a partir da visão sistêmica e orientada ao negócio da empresa.

Na CIGAM Corporativa, as responsabilidades não são muito diferentes, porém com algumas adaptações à nossa realidade e ao nosso contexto. Para que consigam desempenhar suas funções, nossos Analistas de Negócios devem entender como os atuais e os potenciais clientes da Rede CIGAM trabalham, a razão de suas existências, seus principais objetivos e metas e como buscam estes objetivos, e identificar questões comuns de nosso mercado. A partir deste entendimento, os Analistas de Negócios devem encontrar soluções no ERP CIGAM, para que ele se torne, cada vez mais, atraente para as empresas que buscamos ter como clientes, e o diferencial em nosso mercado, de forma que possamos oferecer soluções já disponíveis no produto, evitando o custo e o tempo de espera de uma customização, potencializando o projeto de implementação. Ou então, criando um canal de comunicação para que as expectativas do cliente sejam plenamente atendidas a partir do desenvolvimento de novas funções, uma vez que o analista de negócio alinhe as expectativas dos stakeholders com a  equipe de TI (analistas de sistemas, programadores e consultores), garantindo a efetividade na entrega da solução.

Podemos registrar então que a função do Analista de Negócios é definir o futuro das evoluções do ERP CIGAM com base nas necessidades do mercado e clientes da base, analisando e detalhando as necessidades dos clientes, buscando soluções já existentes no sistema ou, a partir do levantamento de requisitos, determinando a solução funcional que deverá ser implementada pela equipe de customização ou equipe de desenvolvimento do produto. São os Analistas de Negócios os encarregados de fazer essa ligação ao elaborar a solução funcional para o desenvolvimento de novas funções de software e/ou criar facilitadores na utilização das funções do software já existentes, suavizando assim, as relações entre consultores de aplicação e clientes, impulsionando os projetos de implementação.

Ser um Analista de Negócios exige mais do que conhecimento. Exige muita capacidade de negociação, mesclando o temperamento e a habilidade de comunicação de um diplomata, com o talento analítico de um oficial do serviço secreto. Um Analista de Negócios é um elo, uma ponte, um diplomata que equilibra a freqüente discrepância entre a oferta de recursos e as demandas do negócio. Para reforçar esta afirmação, novamente trago registros da Forrester que, após uma pesquisa, descobriu que os Analistas de Negócios mais bem-sucedidos foram aqueles que conseguiram “comunicar, facilitar e analisar”.

Espero, com este artigo, ter esclarecido sobre a função do Analista de Negócios e, principalmente, sobre a importância de toda a Rede CIGAM fazer uso destes profissionais. Mais do que viabilizar negócios e garantir uma evolução efetiva do produto para atender o mercado de toda a Rede, os analistas ainda podem potencializar os projetos de implementação, ao serem envolvidos no momento certo, direcionando a implementação para uma melhor utilização de todos os recursos já disponíveis no ERP CIGAM.

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

Como alterar a descrição de campos do ERP CIGAM

Na maioria das implantações do ERP CIGAM, nossos consultores se deparam com empresas que necessitam de descrições específicas de campos, seja por motivos exigidos pelo ramo de atividade ou até mesmo por cultura da própria empresa.

Com isso, vou mostrar nesse artigo como é simples atender a essas demandas usando os recursos do ambiente de execução do uniPaaS para o CIGAM. Ou seja, estamos nos referindo a um recurso que não necessita de programação ou o uniPaaS Studio para ele, somente do ambiente de execução.

Vamos tomar como exemplo uma empresa que faz distribuição de medicamentos e quer ter em seu banco de dados um Cadastro de Médicos, onde teremos campos como CRM do médico e alguns outros campos específicos para esse tipo de cadastro. Lembrando que esse é apenas um exemplo das centenas com que nos deparamos.

1. Crie um arquivo TXT

Na primeira linha, coloque a descrição do campo atual do CIGAM e, na segunda linha, a descrição do novo campo, repetindo esse procedimento para todos os campos que serão renomeados. Lembrando sempre de deixar uma linha em branco no final do arquivo:

 

2. Copie o arquivo MLS_BLD.EXE do diretório (C:\CIGAMe10\uniPaaS) para o diretório onde o arquivo TXT foi criado:

 

3. Abra o MS-DOS,  entre no diretório onde foi criado o arquivo TXT e execute o comando (MLS_BLD.EXE nomedoarquivo.TXT nomedoarquivo.NEW) e pressione ENTER. Será criado um arquivo com o mesmo nome do arquivo TXT com a extensão NEW:


4. Abra o CIGAM e pressione o botão (Fechar Aplicação) até que fique apenas a tela do Run-time do CIGAM:

 

5. Entre no menu (Opções > Configurações > Idioma), crie um novo idioma e, no campo Tradução, aponte para o diretório onde foi criado o arquivo .NEW:


6. Entre no menu (Opções > Configurações > Ambiente) e na guia Externo altere o campo 17 para o Idioma que acabou de ser criado. Lembre-se de se certificar que o arquivo INI do CIGAM não esteja protegido:

 

7. Feche e abra novamente o CIGAM para que sejam carregadas todas as alterações.

E é só isso. Simples e poderoso recurso de customização do ambiente sem a necessidade de programação.

Edson Rafaldini
Gerente de Produto e Negócios – CIGAM REPULLO


 

 

iBOLT na Vida Real de um Projeto CIGAM – Episódio 01: EDI

 

Manoel Frederico

Neste post anterior, foi abordado um tema bastante comum no dia-a-dia operacional das empresas: EDI.

Embora se fale muito hoje em novos padrões para troca eletrônica de informações (xml por exemplo), o grande volume ainda é baseado em arquivos texto (TXT). Vide o exemplo dos bancos (CNAB).

A troca eletrônica de informações pode ser necessária entre a empresa e seus clientes, fornecedores, parceiros, governo, mas também internamente entre diferentes sistemas que possam existir.

Vamos então focar neste último cenário. Imaginemos esta situação hipotética:

A empresa possui diferentes sistemas, entre eles um de Folha de Pagamento (FOPAG) e o CIGAM Contábil (CTB). A necessidade é fazer com que as informações geradas no FOPAG sejam transferidas para o CTB de uma forma mais ágil e eficiente do que a existente atualmente: digitação.

Entra em campo então o ESB. Em nosso caso, o iBOLT. A tarefa é ter um projeto (sistema) encarregado de buscar as informações geradas no FOPAG e colocá-las dentro do CTB.

Não é corriqueiro encontrar nesses sistemas, facilitadores (interfaces) para exportação e importação de dados. Vejamos então o que temos disponível (à mão):

  • FOPAG não exporta dados para outros sistemas (ou pelo menos para o que precisamos aqui), mas ele gera diversos relatórios, e tem a opção de gerá-los em arquivos eletrônicos (TXT neste exemplo).
  • CTB tem rotina para importação de dados externos via arquivo “TXT”. O layOut disponibilizado pelo CTB para importar movimentos contábeis é:  1;2;3;4;5;6;7;8;”9”

1 = Uma informação fixa (constante) de relevância apenas para o CTB (C = Lcto Contábil)

2 = Código da empresa empregadora/unidade de negócio

3 = Nro do documento (opcional)

4 = Data do lançamento

5 = Conta para DEBITO

6 = Conta para CREDITO

7 = Valor do lançamento

8 = Código do histórico do lançamento

9 = Complemento do histórico do lançamento

 

Estamos falando então de pegar um relatório assim:

 

E transformá-lo em um arquivo assim:

NOTA: Todos os nomes e informações contidos neste exemplo são meramente fictícios

 

Difícil? Não para o iBOLT. Veja um resumo do processo:

 

Esta tarefa pode ser completada por um projeto iBOLT de apenas três fluxos de integração.

Um que lê o relatório gerado pelo FOPAG e cria o arquivo (EDI) necessário ao CTB:

 

Outro que analisa o conteúdo do relatório, extrai as informações relevantes, e formata-as de acordo com as regras exigidas pelo CTB:

 

Outro que converte os códigos do sistema FOPAG para o sistema CTB:

 

Neste endereço, você pode baixar o projeto iBOLT (3.2sp2a) que realiza a tarefa acima.

Para executá-lo, basta seguir estes passos:

1)      Instale o iBolt 3.2 sp2a.

2)      Certifique-se de ter uma licença iBolt Studio (IBNPSTD) e iBolt Server Não Produção (IBNPSRV) válidas (não vencidas) no arquivo ‘License.dat’ na pasta do iBOLT

3)      Baixe o projeto e descompacte a pasta ‘EDIFolPagCIGAMCtb’ dentro da pasta ‘projects’ do iBOLT

4)      Abra o projeto (EDIFolPagCIGAMCtb.ibs) no iBolt Studio e faça um ‘build’ para criar os atalhos (start, stop e webMonitor) segundo as configurações de sua instalação

5)      Vá ao menu ‘Project -> Enviroment Variables’ e crie três variáveis de ambiente cfe. abaixo:

  • FOPAG_WATHCFOLDER %currentprojectdir%InFiles%sl%
  • FOPAG_PROCESSFOLDER %currentprojectdir%OutFiles%sl%
  • FOPAG_EDIFOLDER %currentprojectdir%EDIFiles%sl%

6)      Clique ‘OK’

7)      Abra o projeto no iBolt Monitor (pode fechá-lo no Studio se quiser), e use o atalho ‘start’ para colocar o projeto no ar.

8)      Na pasta ‘SampleFiles’ do projeto, há um arquivo de exemplo do FOPAG, chamado relatorio_folha_pagamento.txt

9)      Copie-o para a pasta ‘InFiles’. Em instantes, o arquivo será capturado pelo iBOLT e movido para a pasta ‘OutFiles’. É quando o processo tem início. Dentro de mais alguns instantes, o arquivo EDI (convertido) será gerado na pasta ‘EDIFiles’

Toda vez que for gerado o relatório de folha de pagamento (FOPAG) em arquivo, e salvo na pasta que está sendo monitorada pelo iBOLT, ele é capturado e convertido automaticamente.

 

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

 

A Evolução do ERP CIGAM: Da nova funcionalidade à customização

Marcelo Petry

Como tudo na história e na vida tem seus ciclos, a história de um produto de software não é diferente, e  este momento em que comemoramos os 25 anos da CIGAM nos leva a pensar no assunto e a fazer algumas reflexões. O momento coincide com uma das mudanças estratégicas mais significativas do ERP CIGAM, que é o fato de começarmos a trabalhar com customizações específicas e exclusivas para nossos clientes. Este é um marco também para mim, que completo 16 anos de história comum com a empresa desenvolvedora deste produto.

Quando a CIGAM iniciou suas atividades, os computadores ainda eram recursos exclusivos de poucas empresas e a quantidade de softwares disponíveis era pouca, principalmente para a realidade brasileira, onde a dificuldade tributária e o jeitinho brasileiro já eram característicos de nosso país. Portanto, desde cedo, eram necessários softwares específicos para as nossas empresas, com os cálculos de impostos, controles financeiros e de produção. E então nasceu o ERP CIGAM. Porém, em vez de criar um software específico para cada cliente, estabeleceu-se que o mesmo produto teria que atender a todos os novos clientes,  e a estratégia para viabilizar esta premissa era que a cada nova solicitação de um cliente, a funcionalidade seria incorporada ao produto, tornando o ERP CIGAM cada vez mais completo e robusto.

Para entender o ciclo de vida do software, faço uma analogia com o ciclo de vida de uma pessoa, reservadas as devidas proporções, é claro. Assim como uma criança que é planejada, se desenvolve no ventre de sua mãe, nasce e ganha alimentação, passa por experiências boas e ruins, e vai crescendo, passando pela adolescência e enfim chegando a fase adulta, também ocorre com os softwares, que são planejados, desenvolvidos, nascem pequenos, depois entram em produção, são experimentados (onde se resolvem problemas… e criam-se outros…) e vão recebendo novas funcionalidades, proteções, facilitadores, enfim, novos recursos conforme as demandas daqueles que o operam, que o utilizam, que o submetem a novas experiências, criando novas necessidades.

No entanto, chega um momento em que muita alimentação e robustez não é mais sinal de saúde, mas sim, um risco de obesidade, colesterol, triglicerídeos e tantas outras doenças causadas pelos excessos. Assim também podemos fazer uma analogia com os softwares, pois chega um momento em que incorporar novas funcionalidades e novas opções também deixa de ser sinônimo de saúde e robustez e passa a ser sinônimo de instabilidade e obesidade, trazendo consigo doenças como baixa performance, erros, dificuldades de uso, de implementação, de atualização e de manutenção.

O ERP CIGAM chegou à sua maturidade e, neste momento, antes que se torne um senhor obeso, entendemos que chegou o momento de parar de incluir cada nova necessidade de nossos clientes no produto, sem, no entanto, deixar de atendê-los naquilo que é o diferencial de cada negócio. Para isto, foi criado o Setor de Customizações do ERP CIGAM, que nasce na CIGAM Corp., mas deve se estender a todos os parceiros da Rede CIGAM, de forma que todos tenham condições de atender às necessidades urgentes dos projetos de forma ágil e precisa.

Para que possamos cumprir a nossa missão que é a de “Promover crescimento e maiores resultados a nossos clientes com nossas soluções de software e serviços.”, além do Setor de Customização, mantemos a equipe direcionada para a evolução do produto, e ela passa a atuar tendo como referências as funcionalidades dos Road Maps, criados pelos Analistas de Negócios da CIGAM Corp. em conjunto com a Área de Mercado e parceiros da Rede CIGAM… mas isto já é tema para um segundo artigo.

Enfim, o setor de Customizações é responsável por desenvolver alterações específicas e/ou exclusivas dos clientes que adquirem este tipo de solução. Participam deste setor Analistas de Sistemas e Programadores, que denominaremos “Customizadores”, sendo suas principais responsabilidades:

  1. Mapear, analisar e entender a necessidade do cliente;
  2. Desenvolver alterações e/ou rotinas e/ou relatórios que buscam atender uma necessidade específica do cliente;
  3. Testar as funcionalidades com o usuário final, usuário chave e/ou consultor de aplicação que acompanha a implementação do cliente;
  4. Documentar as customizações: como ligar e desligar a função, como utilizá-la, e informações sobre onde ela afeta o fluxo de operação normal do sistema;
  5. Entregar as novas funcionalidades para o cliente;
  6. Manter as customizações implementadas.

Podemos destacar como principal vantagem em relação às soluções que se agregam ao produto, o fato de não ser necessário generalizar a solução para atender a todas as funções de software de todo o ERP CIGAM, com a estrutura de dados e regras disponíveis até então. Em função disso, a solução tem um custo mais acessível, é mais simples, funcional, performática e, ainda, tem maior agilidade no encaminhamento e tratamento da alteração. Outro ponto de destaque é o fato de estas alterações não interferirem nas demais funcionalidades do sistema, evitando a geração de novos problemas de sistema (bugs).

As soluções de customização podem ser realizadas utilizando-se diversas ferramentas, desde que devidamente licenciadas, seja pela CIGAM Corp. (ou parceiro da rede CIGAM que está desenvolvendo a customização) ou, ainda, pelo cliente. As principais ferramentas em uso são: CIGAM Report, UniPaaS (Magic), iBOLT, Workflow, PHP, C# e soluções implementadas diretamente no Banco de Dados do cliente.

É importante registrar que existem alguns facilitadores para as integrações do ERP CIGAM para estas customizações, que chamamos de Kit Desenvolvimento CIGAM (SDK CIGAM). Estes facilitadores são os componentes já existentes no CIGAM, os conectores disponíveis em pontos estratégicos dos principais programas ou as views que compõem uma funcionalidade do sistema. É importante registrar que a base de dados do ERP CIGAM é aberta e, portanto, disponível para criação de triggers, procedures e functions de banco, telas de consultas e movimentação, relatórios e rotinas.

Enfim, o ERP CIGAM chega a um nível de maturidade plena… na fase adulta. E para se manter bem são necessárias ações firmes, consistentes e continuadas, de forma que possamos manter o processo de evolução do produto com soluções completas e robustas, sem perder a agilidade no atendimento das necessidades urgentes de nossos clientes, mantendo o produto saudável e estável por vários quartos de século a mais. E trabalhar com soluções customizadas é uma destas ações firmes, fortes e consistentes.

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

 

Padrões e Melhores Práticas para Integração com o ERP CIGAM

Rodney Antonio Repullo

Rodney Antonio Repullo

Integração ERP pode ser definida como o processo de projetar, testar e implementar processos de negócios automatizados, orquestrando as conexões entre os sub-processos de um sistema de gestão e os sub-processos de outros aplicativos de software corporativo como: e-commerce, aplicações web, ferramentas de conteúdo, sistemas de e-mail/comunicação, mídias sociais e workflow humano.

As melhores práticas para Integração com o ERP CIGAM são baseadas em princípios genéricos, mas aqui daremos ênfase a situações e ao cenário com ERP CIGAM e sua plataforma de integração iBOLT Suite da Magic Software.

Tomei como base para esse post o texto escrito por Glenn Johnson da Magic Software Americas que abordou o assunto de forma genérica

 

Melhores Práticas e Padrões de Integração durante a Implementação de Sistemas ERP

 

Plataforma agnóstica. O iBOLT, diferente de outras opções, é uma plataforma agnóstica, ou seja, não depende de um ambiente específico, tais como J2EE ou. NET e você também o executa em qualquer sistema operacional. É uma característica fundamental do que se propõe a ser um elemento de integração de ambientes. Estar vinculado a um ambiente específico limita muito o alcance dessa integração.

Sua integração de aplicações empresariais (EAI) e solução de gerenciamento de processos de negócios (BPM) deve ser capaz de trabalhar com todos os principais ambientes de computação e sistemas operacionais, incluindo Windows, Linux, UNIX e IBM i (AS/400). Com o iBOLT, o ERP CIGAM  é capaz de suportar todos esses padrões incluindo os padrões de integração IBM i (AS/400) e padrões de integração de mainframe para aquelas organizações que executam aplicações nestes ambientes.

 

Modelagem e execução integradas. Através do iBOLT Studio, a definição de alto nível do projeto de Integração e Automatização fica integrada ao Projeto. Muito frequentemente, os analistas de negócio são forçados a modelar processos de negócios de alto nível usando uma ferramenta e executá-los usando soluções completamente diferentes, incluindo programação manual, pacotes de componentes java, ou soluções de EAI e BPM mal concebidas. Não é o caso do IBOLT, que consolida tudo num único ambiente, facilitando o desenvolvimento e a manutenção do Projeto.

Decisores de negócios devem ser extremamente cuidadosos com as recomendações que amarram sua integração ERP com estas soluções de integração desarticuladas e fraturadas de grandes marcas. Elas exigem numerosas compras de licenças de software e um exército de desenvolvedores e implementadores para realizar a integração. Não caia na “armadilha do mel”, método de vendas que convence que você precisa de apenas uma das muitas ferramentas de software avulsas oferecidas por estas marcas e, em seguida, prossegue com uma estratégia para vender mais e mais  produtos diferentes e desconexos que são agrupados sob a mesma marca, a fim de tentar forjar uma solução de trabalho.

 

 

Monitoramento e Design paralelos. Quando o monitor de integração utiliza a mesma interface visual que o estúdio de design de integração, fica muito mais fácil para seus gestores de TI monitorarem a execução de seus processos de negócios. Esse é o caso do iBOLT integrando o ERP CIGAM a outros sistemas. Monitoramento e design paralelos significam que o fluxograma que você criou para seu projeto de integração é o mesmo que você utiliza para controlar sua execução. No iBOLT Studio você pode se aprofundar em qualquer componente para ver a sua configuração. No iBOLT Monitor (ambiente de monitoramento) você pode se aprofundar em qualquer componente no fluxograma para acompanhar a sua execução.

 

Nenhuma Programação Manual. Há uma série de soluções de integração de aplicativos que destacam o fato de serem livres de código, ou que nenhuma programação manual é necessária. Isto só será útil se a solução o levar longe o suficiente na direção de seu objetivo final. Uma viagem gratuita de táxi que te deixa a vinte quilômetros de seu destino não tem nenhum valor. Uma solução de EAI que é livre de código, mas não pode adaptar-se à variedade de tecnologias em uso hoje, é igualmente de efeito muito limitado. Alguns vendedores podem mostrar uma demo estratégica de integração entre o ERP CIGAM  e outra, por exemplo. Mas eles realmente possuem facilidades de baixo nível necessários para integrar o ERP CIGAM? Podem se integrar com aplicações legadas? Filas de mensagens? Fontes de texto não estruturadas? Será que eles possuem uma gama completa de operações lógicas incluídas em seus editores de expressão?

O iBOLT é construído em uniPaaS, que é a mesma tecnologia base do ERP CIGAM. A chamada de componentes do ERP CIGAM é feita de forma simples através do CIGAM, o que não existe em nenhuma outra plataforma tecnológica.

Qualquer outra solução de integração do ERP CIGAM, que não passe pelo iBOLT acabará duplicando lógicas e validações e sendo invasiva ao ponto de interfacear demasiadamente com a base de dados. Isso aumenta significativamente a complexidade da manutenção do projeto, podendo inclusive condenar e dificultar futuras atualizações do ERP.

 

Equilíbrio entre Adaptadores de Alta Granularidade e Baixa Granularidade. É impossível para qualquer solução de integração de ERP ter adaptadores pré-construídos para todos os outros aplicativos que você pode possivelmente querer integrar. É por isso que é muito importante que a solução de integração ERP escolhida tenha os adaptadores tecnológicos necessários para realizar o trabalho. No Caso do ERP CIGAM o componente uniPaaS funciona como um adaptador natural pois ele pode chamar qualquer serviço interno do ERP CIGAM. Isso significa muito mais do que ter suporte para bancos de dados e web services. Verifique atentamente para ver se a solução escolhida tem suporte para protocolos de comunicação, sistemas de arquivo, codificação / decodificação, redes e outras tecnologias de alta granularidade de baixo nível que te permitirão colocar em prática a integração necessária, sem recorrer à programação de interfaces para essas tecnologias. Qualquer analista de negócio que tenha experimentado a satisfação de realmente configurar uma solução de integração e não programá-la, entenderá este ponto muito claramente.

 

Aplicações compostas. Estas são as aplicações que são montadas utilizando tanto componentes de múltiplas aplicações existentes e adição de funcionalidades desenvolvidas especificamente ao projeto. Os componentes de uma aplicação composta são criados independentemente uns dos outros, sem o conhecimento ou análise dos diferentes modelos de informação que estão sendo usados. Na verdade, eles são independentes de plataforma, o que significa que o componente  que fornece algum serviço pode residir em qualquer plataforma capaz de fornecer tal serviço. Quando a integração ERP permite que o sistema ERP forneça serviços como parte de uma aplicação composta, você valoriza muito mais o seu investimento no ERP e começa a ver a recompensa de suas escolhas.

 

Arquitetura Fracamente Acoplada. Seu padrão de integração ERP deve incorporar arquitetura de baixo acoplamento com forte integração com o sistema ERP em si. Arquiteturas fortemente acopladas dependem umas das outras. Assim, alterações em qualquer componente podem (o que frequentemente acontece) exigir mudanças em muitos outros componentes. Arquiteturas fracamente acopladas, em contrapartida, mantêm independentes os componentes que podem operar de forma independente. Uma arquitetura de baixo acoplamento permite substituir ou modificar componentes sem ter que fazer mudanças que refletem para os outros componentes. Desenvolvedores podem exigir a tecnologia correta para o trabalho sem ter que se preocupar com dependências técnicas. Na integração com o ERP CIGAM, você vai querer ter a certeza de que manterá os fontes do ERP CIGAM e os destinos de terceiros separadamente (e vice-versa).

 

Componentes Stateless (sem estado). O ERP CIGAM é capaz de executar  múltiplas transações simultâneas. Isto é essencial para a escalabilidade da arquitetura. Quando um componente permite que mais de uma instância do componente esteja em uso simultaneamente e com estados separados, então ele é considerado um componente stateless. Isto tem a vantagem da escalabilidade e é vital para uma implementação robusta de arquitetura orientada a serviços e integração escalável de ERP.

 

Componentes Dinâmicos. Embora seja vantajoso ter componentes stateless em termos de dados de cada instância de execução, também é vantajoso ser capaz de configurar componentes de forma flexível para seu ambiente. Um sistema que utiliza componentes dinâmicos permitirá que você atualize a configuração do componente de forma a refletir quaisquer campos ou tabelas personalizados em uso nos ambientes de destino. O projeto de integração ERP é bastante simplificado quando os componentes utilizados podem ser passados em um pacote XML que configura a instância de execução. Um sistema de ERP que combina componentes sem estado e dinâmicos terá grandes vantagens, tanto no projeto concepção e execução.

 

Web Services. A Integração que utiliza Web Services pode vir a ter programação incrivelmente intensiva. Web Services programados manualmente também são difíceis de manter. Com Web Services nós estamos falando sobre o uso de protocolos padrão (como o WSDL, SOAP e UDDI) para “envolver”  serviços SOA, de forma que possam ser compartilhados com outras aplicações através da Internet. Este termo é frequentemente usado como sinônimo de “SOA”, apesar de Web Services ser na realidade um mecanismo que permite SOA. Mas apenas porque estas tecnologias estão sendo utilizadas, isso não significa que você deve recorrer à programação delas. Uma boa solução de integração evitará completamente a necessidade de programar conexões para o seu sistema de ERP, no caso o ERP CIGAM, e outras aplicações, sistemas de comunicação e Web Services em seu ambiente.

 

Enterprise Service Bus. Um enterprise service bus é um mecanismo de mensageria distribuído baseado em XML, orientado a eventos – é um tipo de implementação de arquitetura orientada a serviços. É mais adequado para ambientes com servidor Wintel do que para ambientes de computação de médio porte, embora um sistema de médio porte possa certamente funcionar como um nó em uma implantação de enterprise service bus. O iBOLT possui as características de um ESB embutidas.

Sem um planejamento cuidadoso e a seleção de uma solução ágil de integração de processos de negócios orientada a eventos, a Integração ERP será cara, demorada e instável. Embora muitas empresas procurem evitar riscos, comprometendo-se com soluções de grandes marcas para integração, em vez disso eles estão expondo-se a maiores riscos e apenas evitando a culpa. É o fracasso destas grandes soluções para integração que inspirou a Magic Software a trazer a solução de integração iBOLT. Os wizards amigáveis ao usuário do iBOLT, as opções de arrastar e soltar, e as tabelas permitem criar conexões diretas com as aplicações corporativas implantadas em qualquer tecnologia de hardware, sistema operacional ou banco de dados. O resultado é uma arquitetura flexível e escalável que te permitirá fazer novas conexões, implementar mudanças e se adaptar rapidamente à necessidade sempre presente de mudanças em seu negócio.

 

Rodney Antonio Repullo – CEO Magic Software e Grupo Repullo

 

 

 

Utilizando Componentes uniPaaS com o ERP CIGAM

Manoel Frederico

Componentização não é um conceito novo. Já existente desde os tempos do DOS (ex: PLL do Clipper), ficou popularizada através do MS-Windows e suas DLLs.

Você provavelmente já deve estar bem familiarizado com esta prática.

Diferentes aplicações/soluções tendem a ter procedimentos e recursos comuns (até iguais).

O objetivo da componentização é claro: reaproveitar o que já existe, ao invés de refazer.

Uma pequena imagem para ilustrar isso:

Os benefícios também são claros: menor tempo no desenvolvimento de novas soluções, menos “duplicações” e “repetições” desnecessárias, atualizações nos objetos compartilhados se refletem em todos os que os utilizam, facilidade para atualizações parciais das soluções, departamentalização do desenvolvimento, etc…

Com as soluções uniPaaS não é diferente.

Embora o uniPaaS não gere arquivos .exe ou .dll, é perfeitamente possível (e prático) dividir uma solução em módulos (.ecf) independentes.

Praticamente todos os objetos podem ser modularizados: programas, funções, definições de tabelas, modelos, ajudas…

O procedimento para realizar isso é também bastante simples:

Você cria um (ou vários) projetos uniPaaS representando a sua biblioteca de rotinas e recursos (objetos) que deseja compartilhar (tornar reutilizável em outros projetos).

Não é obrigatório compartilhar todos os objetos existentes. Você pode escolher quais deseja tornar “públicos”, e quais deseja manter “internos”.

Os objetos que deseja publicar devem possuir um “Nome Público”.

Em seguida, você acessa o “wizard” de publicação de componentes do uniPaaS Studio (menu: Options à Interface Builder à UniPaaS) para gerar um descritor dos objetos públicos. Este descritor contém a lista dos objetos que estão compartilhados e que podem ser utilizados em outros projetos. É um arquivo texto com a extensão .eci.

Vamos imaginar, por exemplo, que você criou um programa que calcula Juros em Atraso, e deseja utilizar o mesmo programa em dois sistemas diferentes: Contas a Pagar e Contas a Receber. Se a rotina é exatamente a mesma (cálculo dos juros), não há porque tê-la duas vezes, uma em cada sistema. Você cria um projeto só para ela e publica-a como um componente reutilizável. Você terá então:

CalculoJurosAtraso.ecf (projeto executável CIGAM)

CalculoJurosAtraso.eci (descritor dos objetos publicados)

Vejamos agora a outra parte do processo, que é a utilização de objetos existentes em outros projetos.

Seguindo o exemplo do projeto Contas a Pagar, abrindo-o no uniPaaS Studio nós vamos até o repositório de componentes (CRR à Shift+F7). Para cada componente que quiser acoplar a este projeto, acrescentamos uma linha e informamos (usando F5) a localização do seu descritor (.eci). Todos os objetos publicados nele (ex: programa de cálculo dos juros) tornar-se-ão disponíveis para uso, como se estivessem ali definidos/codificados (mas não estão; estão localizados (fisicamente) no outro projeto [.ecf]).

No momento da distribuição da solução (ambiente final de produção), é necessário disponibilizar todos os .ecf que compõem a solução (ex: ContasPagar.ecf e CalculoJurosAtraso.ecf). O descritor (.eci) só é necessário durante o desenvolvimento.

Quando o CIGAM RunTime carregar a solução (Contas a Pagar), ele carregará também todos os outros .ecf que estiverem vinculados a ela, como se fossem um único projeto.

Se na vinculação do componente (cálculo de juros) for definida a propriedade LoadImmediate=Y, a carga do seu .ecf é imediata. Senão, ele será carregado apenas quando algum de seus objetos precisarem ser utilizados, e ainda haverá a opção de descarregá-los com a função CabinetUnload().

Outro exemplo: você desenvolveu uma customização para o CIGAM, e deseja fazer uma pesquisa dos pedidos existentes, usando a mesma interface (UI) padrão que os usuários estão habituados. A solução CIGAM disponibiliza um (entre vários) componente chamado “CGGeral(CGGeral.ecf e CGGeral.eci). Vinculando-o ao seu projeto, você pode chamar o programa “Pesquisa Pedidos(CG00487), e a tela de zoom de pedidos (nativa do CIGAM) será executada a partir do seu módulo.

Além disso, o uniPaaS Studio possui um “wizard” chamado Composite Resource Generator (menu: Options à Composite Resource Generator, ou CTRL+SHIFT+G). Com este “wizard” nós podemos selecionar um recurso/rotina externo (não UniPaaS) que necessitamos utilizar:

  • WebService
  • Stored Procedure
  • Classe Java
  • Fila MSMQ
  • Rotinas iSeries (AS/400)

e ele gera automaticamente um projeto uniPaaS para acessar este recurso, na forma de componente reutilizável.

Veja mais detalhes sobre componentização com uniPaaS nesta página do DevNET da MAGIC Software.

Neste link você pode baixar um pequeno projeto uniPaaS (1.9g) de exemplo, com alguns programas (genéricos, utilitários) publicados, de forma que você poderá acoplá-lo como componente de seus projetos.

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

 

Viabilizando vendas com a ampliação da aderência do CIGAM

Jaime Sender

Jaime Sender / Gerente de Negócios / Cigam Grupo Repullo

Aprecio muito a capacidade do ferramental MAGIC de estender as excelentes funcionalidades do ERP CIGAM.

Isso tem sido muito útil para apresentar soluções criativas para novos e antigos clientes CIGAM e, é claro, alavancar minhas vendas.

Sem dúvida, o ERP CIGAM é a solução mais completa e flexível para o mercado brasileiro de ERPs para pequenas e médias empresas. Entretanto, podem surgir oportunidades que demandem mais criatividade na oferta de uma solução a um determinado cliente e façam gerar uma nova venda de licenças de uso e de serviços de consultoria.

Alguns exemplos mais comuns disto são:

  • Integração com loja virtual, de qualquer plataforma tecnológica, permitindo manter o ERP CIGAM como o centro de controle de qualquer transação, com baixo custo e alto desempenho;
  • Automação do módulo Workflow CIGAM, gerando confiabilidade, rapidez e economia de mão-de-obra;
  • Integração com sistemas especialistas, especialmente nas áreas de produção, ampliando o alcance do ERP CIGAM em novas verticais de mercado;
  • Integração com outros ERPs em outros países, permitindo comunicação de dupla mão com ERPs de grande porte, especialmente útil em filiais brasileiras de empresas multinacionais;
  • Automação de atividades humanas não-decisórias, gerando economia de mão-de-obra;
  • Harmonização de atividades de sistemas de terceiros, gerenciando conflitos;
  • Controle em tempo real de transações complexas, permitindo identificar rapidamente desvios e permitir correções.

Considero que, na medida em que as empresas avancem e amadureçam no uso do seu ERP CIGAM, possam enxergar outras possibilidades de melhoria e que estão acima e além do padrão de qualquer boa ferramenta de gestão empresarial de mercado.

O mesmo se aplica a empresas que buscam substituir o seu sistema de gestão atual por considerarem-no ultrapassado. O ERP CIGAM, agregado a uma solução via MAGIC, atende praticamente a qualquer desafio do gênero, arrisco-me a dizer.

São nestes momentos que o ferramental MAGIC apresenta-se como uma excelente arma para alavancar minhas vendas, face à sua claríssima relação custo x benefício e com resultados rapidamente visíveis para os clientes.

 

 




 

Robinson Klein – Diretor de Mercado da CIGAM – Depoimento sobre a Parceria com a Magic

 

Robinson Klein

Robinson Klein

Robinson Oscar Klein – Diretor de Mercado da CIGAM Corporativa

A parceria com a Magic nos últimos 18 anos, nos ajudou a chegar aos 25 anos vigorosos e atualizados tecnologicamente. A produtividade proporcionada pela ferramenta permitiu importantes ganhos deste competitivo mercado de software.

A Magic tem importante participação para o CIGAM ser hoje um dos principais players do mercado de ERP.

A construção do CIGAM é orientada por nosso lema, “Sua vida mais fácil”. Este lema só foi possível porque a ferramenta uniPaaS da Magic permite que os programadores tenham maior facilidade no desenvolvimento, gerando assim uma solução mais eficiente, mais fácil de usar, mais rápida para parametrizar, exigindo desta forma menos tempo e custo de implementação.

Este é o resultado de boas parcerias – uma sinergia que multiplica resultados para nossos clientes, que recebem um produto mais flexível, mais simples para usar e fácil para extração de informações. Uma vida mais fácil!