Tag BPMS

Um Projeto iBOLT Completo num passe de mágica (Vídeos)

Rodney Repullo - CEO Magic Software Brasil

Rodney Repullo – CEO Magic Software Brasil

Com o objetivo de apresentar a facilidade de uso da nossa tecnologia de integração, gravamos um projeto completo utilizando o iBOLT Integration Suite.

O projeto que se segue representa um  exemplo de situação de integração de sistemas e automatização de processos onde integramos um eCommerce que está na WEB e envia pedido via e-mail para uma determinada conta. O iBOLT monitora a conta de e-mail e realiza uma integração do pedido e cadastro do cliente em um ERP e depois passa a automatizar o processo de geração de ordem de compra e envio ao fornecedor.

Ao todo são 39 minutos de vídeo que ilustra o desenvolvimento de um projeto real desde a sua criação até a sua execução. Isso comprova a alta produtividade da ferramenta que é uma das marcas da tecnologia da Magic Software.

Se trata de um exemplo de projeto simples e pontual, mas que agrega um grande valor a uma empresa que normalmente cuida desse tipo de situação com atuações manuais.

Ressaltamos que a solução facilita não só o trabalho de áreas de TI de empresas, como oferecemos através da suite iBOLT uma grande oportunidade de negócios a desenvolvedores de software que podem oferecer nossa tecnologia como infra-estrutura de soluções de ERP, CRM, Workflow entre outros.

O projeto está dividido em 4 partes e foi gravado pelo nosso especialista em iBOLT, Jerônimo Alberto da Costa.

 

Rodney Repullo – CEO Magic Software Brasil

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

Glenn Johnson – Senior Vice President – Magic Software Americas

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 planejamento de recursos empresariais e os sub-processos de outros aplicativos de software corporativo, aplicações web, ferramentas de conteúdo, sistemas de e-mail/comunicação, mídias sociais e workflow humano.

Quando alguém aplica os princípios de integração ERP para um sistema ERP específico, isso pode se tornar conhecido como Integração SAP, Integração JD Edwards, Integração Peoplesoft, Integração Oracle eBusiness Suite (EBS), Integração Lawson, Integração Dynamics, Integração Sage, etc.

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

Plataforma agnóstica. Os sistemas ERP estão ligados a uma plataforma de aplicações ou ambiente específicos, tais como J2EE ou. NET e você também os executa em um sistema operacional específico. 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. Uma boa solução de integração ERP vai mesmo ser capaz de suportar os padrões de integração IBM i e padrões de integração de mainframe para aquelas organizações que executam aplicações nestes ambientes.

Modelagem e execução integradas. Muito freqüentemente, 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. Os gerentes de TI precisam ser muito cuidadosos aqui. Só porque a mesma marca, tais como IBM WebSphere ou Oracle Fusion Middleware, é aplicada a uma variedade de produtos diferentes utilizados para modelagem e integração pelos fornecedores, não significa que eles sejam integrados e projetados para trabalhar juntos. Ambas as marcas são conhecidas por ter usado uma estratégia de aquisições ao invés de uma estratégia de desenvolvimento unificado para ganhar mercado. Como resultado, suas ofertas para integração de aplicação e gerenciamento de processos de negócios são desconexas, confusas, sobrepostas e frustrantes para serem entendidas – e mais ainda para serem utilizadas.

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. 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 estúdio de design você pode se aprofundar em qualquer componente para ver a sua configuração. No 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 milhas 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 JD Edwards EnterpriseOne e Salesforce.com, por exemplo. Mas eles realmente possuem os adaptadores de baixo nível necessários para integrar o JD Edwards World? Podem se integrar com aplicações legadas? Filas de mensagens? Fontes de texto não estruturadas? Eles podem funcionar com arrays multi-dimensionais? Será que eles possuem uma gama completa de operações lógicas incluídas em seus editores de expressão?

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. 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, quanto serviços, tais como leitura de pedido do cliente, validação do status do cliente, cálculo do desconto ao cliente, ou aplicação de desconto ao pedido. 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 prometida por fornecedores de ERP no início.

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 freqüentemente 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 ERP, você vai querer ter a certeza de que manterá os fontes do ERP e os destinos de terceiros separadamente (e vice-versa).

Componentes Stateless (sem estado). Os sistemas de ERP normalmente são capazes de 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. Suponha que você está configurando a integração do Microsoft Dynamics CRM com o Oracle JD Edwards EnterpriseOne. 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 de ERP 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 é freqüentemente 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 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.

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.

Criando Inteligência de Negócios através do Business Integration Suite

Hilton Menezes- Arquiteto de soluções Java/JEE na Add Technologies

Post originalmente publicado no Blog Add Tech

Introdução
O ambiente de negócios no qual as empresas operam atualmente está se tornando cada vez mais complexo. As empresas, privadas ou públicas, sentem crescentes pressões forçando-as a responder rapidamente a condições em constante mutação, além de terem que inovar na maneira como operam. Estas atividades exigem agilidade e tomada de decisão rápida e freqüente, sejam elas, estratégicas, táticas e operacionais. Tomar decisões pode exigir quantidade consideráveis de dados oportunos e relevantes, bem como informações e conhecimento. O processamento dessas informações, na estrutura das decisões necessárias, deve ser feito de forma rápida, com freqüência em tempo real e comumente exige um apoio computadorizado.

Diante deste cenário, cada vez mais empresas buscam na Tecnologia da Informação, soluções focadas em inteligência de negócios para tomada de decisões gerenciais. Neste artigo – dividido em 2 partes – apresentaremos uma solução de inteligência de negócios, através da criação de sistemas de informações corporativas e sistemas de informações geográficas.

O problema

Visando dinamizar a tomada de decisão sobre as obras de engenharia, a Prefeitura da Cidade do Rio de Janeiro (PCRJ), considerou a necessidade de georreferenciamento das informações existentes em seus sistemas legado no mapa digital do Município, sem que seja necessário realizar manutenção nas bases de dados existentes.

Como ponto de partida, foram eleitos dois sistemas que apóiam os processos de negócio da Secretaria Municipal de Obras (SMO) e da Secretaria Municipal de Habitação (SMH) respectivamente, realizando o controle e acompanhamento, inclusive orçamentário, das obras de engenharia da cidade.

A PCRJ definiu como escopo inicial, a análise das informações do Sistema de Acompanhamento, Controle de Obras e Serviços de Engenharia (SISCOB), do Sistema de Orçamento e Controle de Obras (ORC) e Sistema de Monitoramento e Acompanhamento (SIMA), sendo os dois últimos relativos a projetos habitacionais. O objetivo final é o georreferenciamento das informações de cada sistema no mapa digital do Município.

A solução

Para solução proposta, foram analisados alguns pontos importantes apresentados no problema, a saber:

1.A solução não poderia solicitar manutenção nos sistemas legado;
2.Deveriam ser lidas diversas fontes de dados, tanto em sistemas gerenciadores de banco de dados como em serviços web;
3.A nova massa de dados deveria ser utilizada por Sistemas de Informações Geográficas – SIG.

O maior problema encontrava-se em como ler os dados de diversas fontes, sem criar uma solução de alto custo, com agilidade e flexibilidade suficiente para adapta-se a mudanças nas estratégias de negócios.

Precisava-se utilizar uma ferramenta corporativa de integração (ESB) para criar uma base única, a ser utilizada por softwares de Sistemas de Informações Geográficas (SIG) e de Inteligência de Negócios (BI).


A resposta veio através da utilização do iBolt Business Integration Suíte da Magic Software Brasil, empresa parceira da ADD Technologies. O iBolt é um suite de integração flexível, com um ótimo custo-efetivo e de fácil uso, alavancando o investimento no legado, enquanto cria rápida e dinamicamente novos processos de negócios, serviços e aplicações. Seu design poderoso e simplificado – que não requer virtualmente nenhuma habilidade de programação – assegura as empresas, integração de negócios rápida e bem sucedida, enquanto gera um rápido retorno sobre o investimento (ROI), aumentando o rendimento e a satisfação do cliente.

Neste momento iremos conhecer o resultado do projeto e o que foi gerado de valor para o cliente.

iBolt contêm diversos conectores para SGBDs, sistemas SAP, Web Services, Salesforce, ERP, Serviços de E-mail, Enterprise Java Beans, Microsoft Office, SNMP, Google Docs, JDEdwards, HTTP, classes Java, Lótus Domino, XML, Websphere MQ, Microsoft MQ, Java Message Sevice, FTP, dentre outros, prontos pra uso. É só “plugare-usar”. Dessa forma diminui-se o custo do projeto e proporciona-se flexibilidade necessária em caso de mudança nas regras de negócios.

O Resultado

A organização administrativa do município do Rio de Janeiro divide-se em Bairros, Regiões Administrativas (RA) e Áreas de Planejamento (AP). No entanto, alguns registros de obras deveriam ser georreferenciados pelo seu logradouro mais número predial ou número do logradouro, por exemplo, obra de manutenção na “rua voluntários da pátria, 5678”

Segue abaixo alguns problemas encontrados no projeto e sua resolução no iBolt:

Problema Solução
Os nomes dos logradouros não tinham um padrão comum de tipos Foi importado um arquivo CSV com os tipos padrões e feito a conversão durante a leitura dos sistemas legado
Os códigos dos logradouros são fornecidos via serviços web por outro órgão Foi criado um fluxo específico para consulta de códigos de logradouros a partir de composição do nome do logradouro nos serviços web. A lógica do fluxo permite filtrar o bairro retornado pelo serviço web.
Os números de logradouros (numeração predial) estavam em campos alfanuméricos sem um padrão determinado Foram criadas regras de negócios e extratores, que filtravam o número a partir de um conjunto de caracteres alfanuméricos. O resultado foi gravado em outra coluna, permitindo que a PCRJ pudesse observar quais registros foram limpos.

A PCRJ repassou 4320 registros como amostra de dados. A solução e mostrou eficiente, uma vez que como resultado, obteve-se 100% dos dados de obras dos sistemas legados, tratados e com possibilidade de georreferenciamento pelo Sistema de Informação Geográfica da PCRJ.

Segue números do resultado final:

• 1115 registro com referência de logradouros, sendo 592 tratados pelo iBolt, tornando-os georreferenciáveis pela dupla  logradouro e número predial. Os 523 não tratados, foram georreferenciáveis pelo bairro.
• 1441 georreferenciados por Bairros, pois não continham informações de logradouros
• 233 georreferenciados por RA, pois não continham informações de logradouros nem bairros
• 1531 georreferenciados por AP, pois não continham informações de logradouros, nem bairros, nem RAs.

Segue abaixo o conjunto de ilustrações retiradas do Sistema de Informações Geográficas da PCRJ a partir da leitura da base da dados SIG gerada pela solução proposta pela Add Technologies.

Ilustração 7 – Obras por bairros

Ilustração 8 – Obras por RA

Ilustração 9 – Obras por AP


Conclusão

A solução proposta pela Add Technologies, resolve o problema de georreferenciamento das informações existentes nos sistemas legado da PCRJ em um mapa digital do município do Rio de Janeiro, sem que seja necessário realizar manutenção nas bases de dados existentes.

Não obstante, o uso do iBolt – Business Integration Suíte como ferramenta corporativa de integração e de gerenciamento de processos de negócios, permitiu estender a solução para atender outras áreas de negócios, bem como, a leitura de dados por Sistemas de Informações Corporativas, alavancando a solução em não somente um ferramenta de integração, mas também em uma solução que permite Inteligência de Negócios, uma vez que fornece informações cruciais a sistemas de apoio a decisão.

O Impacto da indisponibilidade de software na eficiência das empresas

Glenn Johnson – Senior Vice President – Magic Software Americas

Hoje, o software já faz parte do cotidiano das empresas. Se a informação é o seu negócio ou se você simplesmente precisa de informações sobre ele, o software fornece o que você precisa. Então por que tantas empresas reduzem sua eficácia operacional, tentando sobreviver com menos licenças de software do que realmente precisam?

A falta de software disponível para os trabalhadores em sua organização, traz graves, e muitas vezes ocultas consequências ao negócio. Enquanto os gerentes podem pensar que estão ajudando os seus negócios, limitando o número de licenças de software para “apenas aqueles que realmente precisam”, em vez disso, eles podem estar reduzindo a eficácia operacional em detrimento de seus negócios. O acesso insuficiente ao software aumenta o custo da má qualidade (COPQ) em um negócio.

Considere estas consequências da insuficiência de software:

Formação inadequada e aculturação. Em muitas organizações, o processo na contratação do funcionário não incluiu a providência prévia de acesso aos softwares necessários. Como resultado, os programas de formação inicial erram o alvo ou ensinam comportamentos menos eficientes do que os possíveis quando as aplicações de software corretas estão disponíveis. Funcionários mal treinados podem oferecer um serviço pobre ao cliente, cometer um maior número de erros e afetar negativamente a moral dos funcionários.

Período inicial de ineficiência. Quando as licenças não estão disponíveis para os novos funcionários, mesmo após o seu período de treinamento inicial, a perda econômica ocorre durante o período de espera para entrar no “sistema”. Até então, salários são gastos em trabalhadores menos eficientes e os maus hábitos de trabalho são mais incentivados.

Outsourcing e In-Sourcing indevidos. Quando trabalhadores especializados que poderiam fazer um trabalho, e não o fazem porque não têm acesso ao software, eles são obrigados a submeter a tarefa a outra pessoa. Isso pode resultar em um outsourcing externo com custo. Quando uma outra empresa é necessária para fazer um trabalho que poderia ser feito se o software estivesse disponível para aquela pessoa, ocorrem custos extras e atrasos. Frequentemente, transferir uma tarefa para outro trabalhador significa transferi-la para outra empresa. Estas transferências criam atrasos, introduzem maior oportunidade para a falta de comunicação e são inerentemente ineficientes por causa das comunicações circundantes desnecessárias, solicitações e revisões do processo.

Trabalho duplicado. Algumas empresas mantêm duas aplicações de software distintas para executar a mesma tarefa, essencialmente, porque eles não possuem licenças de software suficientes para todos os trabalhadores para que utilizem um único sistema. Alguns trabalhadores estão no antigo sistema, enquanto outros estão no novo. Muitas vezes, nessas organizações, há um funcionário que passa horas por semana reinserindo dados ou executando tarefas em lote para sincronizar sistemas – que poderiam ser evitadas através de um trabalho em um único sistema.

Estrangulamentos. Quando somente alguns dos que precisam de acesso efetivamente o possuem, ocorrem gargalos. Atividades importantes são desnecessariamente atrasadas porque o processo está dependente de um número limitado de pessoas que têm acesso ao aplicativo adequado. Alguns trabalhadores podem estar compartilhando uma licença, o que significa que apenas um trabalhador tem acesso ao software a qualquer momento. O tempo de espera para a licença ficar disponível cria necessidade de comunicação, acrescenta atrasos e cria gargalos.

Excesso de pessoal. Quando um aplicativo de software é incorretamente rotulado como uma especialidade e trabalhadores de conhecimentos específicos são contratados para operá-lo, o resultado é o excesso de pessoas. O aumento das necessidades de mão-de-obra especializada muitas vezes pode ser evitado com o simples aumento da disponibilidade do software e treinamento de mais trabalhadores sobre o uso do mesmo. Às vezes, estas ineficiências em excesso também podem ser necessárias devido a uma gestão excessivamente restritiva de direitos de usuário dentro de um aplicativo. O usuário pode ter uma licença, mas não tem os direitos de usuário necessários para executar a tarefa. O impacto econômico é o mesmo.

Moral reduzido dos funcionários. No mundo de hoje das mídias sociais, aplicações ricas, integração e mesclagem de software em tempo real, a falta de acesso às aplicações pode ser extremamente frustrante para os trabalhadores e provocar a redução da moral dos funcionários e um maior turnover.

Falta de Enriquecimento Interdepartamental. Existe um custo negativo, quando os vendedores não estão cientes dos problemas de atendimento ao cliente, porque eles “não estão no sistema” que acompanha os problemas e soluções do atendimento ao cliente. Estender software e o acesso à informação para além das tradicionais fronteiras departamentais pode melhorar os processos de negócio. Quando a equipe de engenharia pode acessar diretamente o sistema de apoio ao cliente, eles podem ser capazes de propor soluções imediatas ou mesmo detectar defeitos do produto mais cedo do que quando eles não têm acesso e devem confiar nos relatórios mensais ou outros meios de compartilhamento de informações entre os departamentos.

Processos de Negócio Ineficientes. Talvez o resultado da falha no uso de software ou utilização de software inadequado seja o custo de um processo de negócio ineficiente. A maioria das organizações passa por um treinamento inicial sobre “como” utilizar um aplicativo de software. As instruções iniciais normalmente abrangem o desempenho de tarefas básicas. Sem um treinamento mais avançado sobre “quando fazer” e “por que” usar o software, os processos são executados ad-hoc ou sem o benefício integral da eficiência incorporada ao sistema de software. A subutilização de software tem graves consequências econômicas em todas as funções departamentais de uma organização: administração, finanças, engenharia, produção, marketing, vendas, distribuição, serviços e operações.

Desvantagens competitivas. Organizações que subutilizam softwares e restringem o número de licenças ficam à mercê de concorrentes que operam na máxima produtividade e eficiência reforçada por softwares. Organizações que operam sem um número suficiente de licenças de software ficarão para trás na inovação, tempo de resposta ao mercado, participação de mercado, capacidade de produção, satisfação do cliente e performance dos resultados financeiros.

A insistência nos caros estudos formais de ROI e relatórios de uso pode incorrer em uma lista longa e geralmente esconde custos nas empresas, que podem ser facilmente evitados, bastando ter uma visão mais agressiva em relação à disponibilidade e utilização de software. O software que funciona vale cada centavo do seu custo de licenciamento. Cloud computing não elimina o problema, na verdade, agrava-o. Quando o software é visto como uma despesa operacional ao invés de uma despesa de capital, crescem as pressões para limitar o seu uso. Empresários inteligentes terão certeza de que têm licenças de software suficientes disponíveis para todos os seus usuários, incluindo as licenças suficientes para o crescimento futuro. De quantas licenças você precisa?