UBL e Inovação Disruptiva

XML de negócios pronto para uso para diversos segmentos de mercado

Normalmente, as empresas têm que configurar uma cadeia de fornecimento e gerenciá-la. Geralmente as empresas têm que comprar mercadorias e serviços de fornecedores para executar os seus negócios. Existem centenas, se não milhares, de aplicativos para ajudar nesse processo. Muitos desses aplicativos suportam faturas eletrônicas e outros documentos de negócios, e alguns inclusive oferecem suporte para XML, mas a maioria das trocas de documentos de negócios entre as empresas ainda são baseadas em papel. A Universal Business Language (UBL) da OASIS é uma tecnologia baseada em XML (e não um aplicativo) projetada para conexão nas práticas de gerenciamento existentes nas áreas de negócios, jurídica, auditoria e registros. Neste artigo, vamos examinar a UBL para ilustrar a sua utilidade e explorar como os serviços emergentes de UBL neste domínio de problema podem ser uma inovação disruptiva.

Hugh Chatfield, Information Systems Professional, CyberSpace Industries 2000 Inc.

W. Hugh Chatfield é um profissional de Sistemas de Informações e diretor da CyberSpace Industries 2000 Inc., que fornece treinamento e consultoria em XML e serviços de produção multimídia. Ele é graduado com louvor em Física e possui certificado de honra em Produção de Documentários. Com mais de 40 anos de experiência em Tecnologia da Informação, ele passou os últimos 17 anos na área de domínio geral da linguagem de marcações.



31/Ago/2012

Informações básicas da UBL

Desenvolver habilidades sobre este tema

Este conteúdo é parte de um guia progressivo de capacitação para o aprimoramento de suas habilidades. Consulte Introdução à Linguagem Universal de Negócios

Vamos explorar as origens e alguns recursos da UBL, incluindo como a UBL permite a customização local na cadeia de fornecimento. Em seguida vamos examinar como a UBL está sendo usada em situações reais.

Tim McGrath, um dos criadores da UBL, observou que "a UBL não é um avanço tecnológico revolucionário e sim um avanço revolucionário na aplicação de uma tecnologia" (consulte a seção Recursos).

Bower e Christensen criaram a expressão tecnologia disruptiva para descrever uma tecnologia que inesperadamente substitui uma tecnologia de sustentação estabelecida. As tecnologias de sustentação normalmente se apoiam em melhorias incrementais, enquanto a tecnologia disruptiva pode surgir de uma origem diferente da finalidade originalmente projetada para substituir outra tecnologia.

Então, se a UBL não é uma tecnologia disruptiva, certamente é o que Christensen posteriormente chamou de disruptive innovation , com potencial de "disponibilizar a toda uma nova população de consumidores o acesso a produtos e serviços que antes só estavam disponíveis para consumidores com muito dinheiro ou muita qualificação" (consulte a seção Recursos).

Plano de fundo

A UBL não é uma tecnologia nova, e sua base certamente não é nova. A UBL se tornou um padrão da OASIS em 2004, com releases subsequentes nos anos seguintes. Tabela 1 fornece a cronologia dos releases da UBL.

Tabela 1. Releases da UBL
VersionDatasObservações
0.7 (revisão pública)2003Usada na Dinamarca no projeto OIOXML
1,02004
2,02006Usada na Dinamarca no projeto OIOUBL
2 Errata 012008
2.1 (revisão pública)2010


A UBL é compatível com a recomendação da Extensible Markup Language (XML) (V1.0 - recomendação da World Wide Web Consortium, 1998), que é baseada na Standard Generalized Markup Language (SGML) que se tornou um padrão da organização internacional para normatização em 1986. A SGML descende da General Markup Language (GML) da IBM, desenvolvida na década de 60 por Charles Goldfarb, Edward Mosher e Raymond Lorie. Existe quase meio século de desenvolvimento técnico sólido no domínio das linguagens de marcação geral.

A SGML focou na resolução de problemas de documentação em larga escala que ocorriam nos segmentos de mercado militares, aeroespaciais e automotivos, e também nas editoras de grande porte. O Departamento de Defesa dos Estados Unidos (DoD), por exemplo, recebia informações técnicas de milhares de fornecedores em diversos formatos proprietários. Isso criou um grande problema quando eles tentaram integrar todas as informações em uma estrutura eletrônica comum. A solução foi solicitar a todos os fornecedores o uso da SGML. Os fornecedores tiveram que fornecer informações técnicas em SGML com base na definição de aquisição contínua e suporte durante o ciclo de vida (CALS), caso contrário o DoD não aceitaria a parceria de negócios Como resultado, o DoD passou a receber todas as informações em uma linguagem de marcações comum, eliminando diversos problemas. Estamos em uma situação similar com a troca de documentos de negócios.

O histórico da UBL

O site Cover Pages fornece uma excelente visão geral do histórico de desenvolvimento da UBL (consulte a seção Recursos).

A UBL é uma linguagem de marcações XML destinada à troca de documentos de negócios entre empresas na Internet. O esforço da UBL destina-se ao e-commerce global de combustíveis, simplificando a atual troca intensa de papéis de informações de negócios. A UBL 2.0 define uma biblioteca aberta, isenta de direitos autorais, com 31 documentos de negócios padrão em XML no formato eletrônico como ordens de compra, faturas e diversos outros documentos de negócios padrão que podem ser usados globalmente. A UBL 2.1 (em desenvolvimento) possui mais de 60 documentos. O objetivo do projeto da UBL é a conexão direta nas práticas de gerenciamento existentes nas áreas de negócios, jurídica, auditoria e registros, para eliminar a reinserção de dados nas cadeias de fornecimento existentes baseadas em fax e papel, além do fornecimento de um ponto de entrada no comércio eletrônico para empresas de pequeno e médio porte.

É importante entender que, ao implementar uma solução UBL, não é necessário alterar a forma de execução dos negócios e nem os aplicativos de software atualmente usados. A UBL substitui a troca de documentos de negócios em papel por documentos eletrônicos confiáveis que podem ser entendidos globalmente. Em muitos casos, o usuário final desconhece o uso da UBL, visto que continua executando suas tarefas normalmente usando seus aplicativos atuais. As práticas de negócios aperfeiçoadas por muitos anos são simplesmente aplicadas no mundo eletrônico.


Entidade de Informações de Negócios

A UBL foi desenvolvida com base nos padrões existentes. Por exemplo: a UBL usa os componentes principais do Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), conforme definido na Parte 8 da Especificação Técnica dos Componentes Principais (consulte a seção Recursos). Essa especificação define uma solução de componente principal como "uma metodologia para o desenvolvimento de um conjunto comum de blocos de construção semânticos que representam os tipos gerais de dados de negócios em uso hoje e fornece a criação de novos vocabulários de negócios e a reestruturação dos vocabulários de negócios existentes".

Um componente principal é um bloco de construção semântico que pode ser usado para todos os aspectos de modelagem e troca de dados e informações. Os componentes principais são o eixo de apoio para a criação de documentos de negócios e modelos de processos de negócios interoperáveis. Os componentes principais são de natureza conceitual e são usados para criar Entidades de Informações de Negócios (BIEs) em um contexto específico.

A UBL define um conjunto de definições de negócios que utiliza esses componentes principais como base. A Figura 1 ilustra como a UBL se associa a esses componentes principais.

A BIE é o conceito principal no processo de montagem da UBL. Uma BIE pode ser uma BIE Básica (BBIE), uma BIE Agregada (ABIE) ou uma BIE de Associação (ASBIE).

Uma BIE Básica é uma entidade atômica que não é composta por outras entidades. Uma BIE Agregada pode ser composta por BIEs básicas e outras BIEs Agregadas. O BIE de Associação define uma associação entre duas ABIEs. Um conjunto de documentos padrão de negócios, como ordens de compra e faturas, é então montado a partir da BIE. Consulte a Figura 1 para obter detalhes.

Figura 1. Relacionamento da BIE com os componentes principais
Relacionamento da BIE com os componentes principais

Conforme mencionado anteriormente, a BIE é o conceito principal do processo de montagem da UBL, assim como o componente principal é o conceito principal no processo de montagem do componente principal. A BIE pode ter 3 formatos: BIE básica (BBIE), BIE agregada (ABIE) ou BIE de associação (ASBIE). Uma BIE é uma parte de dados de negócios ou um grupo de partes de dados de negócios com uma definição semântica de negócios única. Existe uma ABIE especial chamada ABIE de Documento reservada para diferentes tipos de documentos como ordens de compra ou faturas. Cada tipo deste, por sua vez, será composto por um conjunto de ABIEs, ASBIEs e BBIEs.

A BBIE é uma entidade atômica que não é composta por outras entidades. Ela representa o bloco de construção semântico e associa-se diretamente ao componente principal básico. Um exemplo de BBIE pode ser o AddressTypeCode— um código que especifica o tipo de endereço como o endereço comercial ou o endereço residencial. Um Endereço é uma ABIE, um conjunto estruturado de informações sobre um endereço. Um DeliveryAddress ouAddressLine são exemplos de ASBIE. DeliveryAddress herda as propriedades do Endereço mais geral enquanto AddressLine herda as propriedades do elemento mais geral Line.

Entidade de Informações de Negócios de Exemplo

Para visualizar um fragmento do código do UBL-CommonAggregateComponents-2.0.xsd que ilustra como as diversas formas de BIEs são desenvolvidas e relacionadas, consulte a Listagem 1. Entidade de Informações de Negócios de Exemplo. As partes que lidam com a noção de um endereço foram extraídas, incluindo as definições de elemento para Endereço e AddressLine.

Os componentes principais básicos comuns, nos quais as BIEs são baseadas, pertencem ao namespace XML cbc. AddressLine (um ASBIE) também faz parte da definição de AddressType que possui o atributo type="AddressLineType".

AddressLine, com um atributo type="AddressLineType", é uma ABIE que consiste em um ou mais elementos Line (uma BBIE que também pertence ao namespace XML cbc). Line é definido como "uma linha de endereço expressa como um texto não estruturado".

Todos esses códigos definem um Endereço (uma ABIE) que consiste em diversos elementos opcionais (BBIEs), incluindo AddressLine (uma ASBIE). AddressLine (ABIE) consiste em um ou mais elementos Line (BBIE).


Customizações da UBL

Os designers da UBL não tentaram forçar aos usuários o uso de solução única universal gerenciada centralmente. Ao invés disso, eles projetaram a UBL para atender de 80% a 90% dos requisitos globais e reconheceram que existem requisitos locais que os usuários terão que gerenciar através da customização.

Por exemplo: é possível usar somente alguns documentos UBL em uma determinada comunidade. Talvez somente algumas partes desses documentos UBL sejam necessárias. É possível incluir extensões customizadas a eles para a sua comunidade. Também é possível restringir os valores das informações individuais.

Os designers da UBL tomaram a decisão exclusiva de separar a validação estrutural e léxica da validação de valor. Isso é um pouco diferente de outros vocabulários de negócios baseados em XML que reúnem as duas validações em um único esquema.

Na UBL, as restrições estruturais e léxicas são definidas (e validadas) através do esquema; uma segunda expressão abstrata das listas de códigos (usando Xpath, genericode e contexto para a associação de valores) e outras restrições de valores são usadas para a validação do valor. A Figura 2 ilustra essa separação. Essa segunda etapa de validação de valor permite que uma comunidade de interesse (como um fornecedor ou um conjunto de clientes) entre em acordo e especifique um conjunto de valores que será usado somente nessa comunidade. Por exemplo: um código do produto pode ser restrito ao conjunto de produtos oferecido pelo fornecedor.

Figura 2. Validação da UBL
Validação da UBL

Na Figura 2, é possível visualizar a validação léxica e estrutural no esquema W3C XSD padrão. Como acontece no XML, uma instância de entrada será declarada válida se pertencer à classe de documentos descritos formalmente pelo esquema W3C.

A validação de valor envolve listas de códigos. As listas de códigos, ou vocabulários controlados, são especificamente usadas para restringir os valores permitidos de um elemento de informações. As listas de códigos podem ser gerenciadas globalmente (como os códigos de país com dois caracteres) ou localmente (como uma lista de códigos de produtos no catálogo do fornecedor).

Não vamos descrever em detalhes as listas de códigos neste artigo, mas as perguntas mais frequentes da UBL 2.0 descrevem como as listas de códigos são processadas:

"A UBL 2.0 também apresenta uma resposta para o problema de gerenciamento de listas de códigos. Ao invés de vincular os valores da listas de códigos padrão diretamente nos esquemas de documentos, o que torna praticamente impossível o ajuste das listas de código para parceiros comerciais específicos, a UBL 2.0 expressa os valores da lista de código em arquivos separados usando o novo formato genericode. Os valores padrão são então usados para gerar um script XSLT que valida os valores do código de forma independente dos esquemas padrão. Essa abordagem com duas etapas não somente resolve a maioria dos problemas de gerenciamento das listas de código, como também permite a associação de diferentes subconjuntos de listas de códigos com contextos diferentes com a mesma instância de documento, fornece grande flexibilidade para a especificação de valores de códigos aceitos em cada relacionamento comercial e estabelece uma plataforma para a implementação de regras de negócios sofisticadas — tudo isso sem modificar os esquemas padrão da UBL 2.0".

Para obter um link para as FAQ da UBL 2.0, consulte a seção Recursos.

O UBL 2 Guidelines for Customization, First Edition da OASIS fornece uma descrição detalhada sobre como lidar com a customização (consulte o link na seção Recursos).


Problemas com a troca de documentos de negócios

Agora vamos examinar o problema com a troca de dados de negócios entre empresas em uma cadeia de fornecimento. Uma empresa pode atuar como uma cliente de um fornecedor que fornecerá ao cliente as mercadorias e serviços necessários para a execução dos seus negócios. Normalmente, cada cliente possui N fornecedores (consulte a Figura 3).

Figura 3. Cadeia de fornecimento
Cadeia de fornecimento

A Tabela 2 mostra as atividades típicas desse acordo de negócios.

Tabela 2. Atividades típicas
Activity
DiscoveryQuais fornecedores poderão ser usados?
FornecimentoO fornecedor possui os componentes necessários?
Solicitação de compraSolicitação de mercadorias ou serviços do fornecedor.
FulfillmentO fornecedor envia todos ou alguns itens da sua ordem.
Faturamento do fornecedorEnvio da fatura dos produtos enviados.
PagamentoO cliente paga o fornecedor.


Se gerarmos um gráfico das empresas no qual o eixo vertical é o número de fornecedores e o eixo horizontal é uma ordem de todos os clientes pelo número de fornecedores, veremos uma curva de Pareto padrão. Cerca de 20% dos clientes possuem um grande número de fornecedores e normalmente possuem aplicativos de larga escala instalados para lidar com esse grande número de fornecedores. Esses aplicativos possivelmente são sistemas de intercâmbio de dados eletrônicos (EDI) que fornecem transações, como faturas, para outros usuários de EDI eletronicamente (consulte a Figura 4).

Figura 4. Empresas ordenadas pelo número de fornecedores
Empresas ordenadas pelo número de fornecedores

Os outros 80% de clientes possuem menos fornecedores e usam aplicativos menos sofisticados (ou até mesmo ferramentas de escritório como planilhas e processadores de texto) para gerar transações de negócios como uma fatura. Muitos desses clientes usam o papel como meio de transmissão das transações de negócios para o fornecedor.

Figura 5. Troca de documentos em papel
Troca de documentos em papel

O problema dos clientes que possuem um número muito grande de fornecedores é que eles possuem um sistema que requer a inserção dos dados da fatura no sistema eletronicamente. Quando eles recebem as faturas dos fornecedores, como uma página impressa através do correio ou mesmo um arquivo PDF enviado por email, eles perdem tempo e recursos para redigitar as informações ou realizar uma varredura com OCR para obter as informações no formato eletrônico. Na Europa, o custo do processamento de uma fatura típica é estimado entre € 7 a € 15. A eliminação desse custo pode gerar economias significantes para uma empresa de grande porte.

Por exemplo: considere o Governo da Dinamarca que tem que processar 1,4 milhões de faturas por mês de 440.000 fornecedores. A economia gerada com a eliminação desse custo pode ser bastante significativa. A KPMG, na sua análise formal da situação da Dinamarca em 2003, percebeu que seria possível eliminar no mínimo 10 minutos do tempo de manipulação da fatura por fatura, resultando em uma economia de € 94 milhões. A eliminação dos 17 minutos gastos para corresponder a fatura à ordem de compra produziria uma economia adicional de € 160 milhões.

O problema dos clientes que possuem um número muito pequeno de fornecedores é que a maioria dos sistemas existentes é muito complexa e muito cara para atender às necessidades do cliente.


Aplicativos de UBL

Em geral, para dois negócios trocarem efetivamente documentos de negócios, eles devem possuir documentos com a mesma linguagem e devem possuir uma forma de trocar esses documentos eletronicamente — sem alterar os seus processos de negócios existentes. E o processo deve ser escalonável para o tamanho dos negócios envolvidos, de negócios muito pequenos até instituições do governo ou empresas de grande porte.

A UBL fornece a linguagem padrão para a troca de documentos de negócios com base em um conjunto comum de padrões semânticos. Todas as empresas podem trocar documentos de negócios com outras empresas e ter seus documentos entendidos.

A OASIS (2006), por exemplo, fornece diversos exemplos de documentos UBL. A Listagem 2 é um extrato de um LineItem de uma ordem de 100 kg de cera de abelha.

Listagem 2. Extrato de um LineItem de uma ordem de cera de abelha
<cac:LineItem> 
    <cbc:ID>1</cbc:ID> 
    <cbc:SalesOrderID>A</cbc:SalesOrderID> 
    <cbc:LineStatusCode>NoStatus</cbc:LineStatusCode> 
    <cbc:Quantity unitCode="KG">100</cbc:Quantity> 
    <cbc:LineExtensionAmount currencyID="GBP">
        100.00    
    </cbc:LineExtensionAmount> 
    <cbc:TotalTaxAmount currencyID="GBP">17.50</cbc:TotalTaxAmount> 
    <cac:Price> 
        <cbc:PriceAmount currencyID="GBP">100.00</cbc:PriceAmount> 
        <cbc:BaseQuantity unitCode="KG">1</cbc:BaseQuantity> 
    </cac:Price> 
    <cac:Item> 
        <cbc:Description>Acme beeswax</cbc:Description> 
        <cbc:Name>beeswax</cbc:Name> 
        <cac:BuyersItemIdentification> 
            <cbc:ID>6578489</cbc:ID> 
        </cac:BuyersItemIdentification> 
        <cac:SellersItemIdentification> 
            <cbc:ID>17589683</cbc:ID> 
        </cac:SellersItemIdentification> 
    </cac:Item> 
</cac:LineItem>

Observe que esse extrato é legível por humanos. É fácil visualizar que se trata de uma ordem de 100 kg de cera de abelha com um preço total de 100 libras esterlinas mais 17,50 libras esterlinas de imposto. Como se trata de um XML, pode ser processado por componentes prontos para uso.

Os dois namespaces, cbc e cac, referem-se aos componentes básicos e agregados, respectivamente. É possível ver que o elemento <cbc:Name> acima é um componente básico, enquanto o elemento <cac:BuyersItemIdentification> é um componente agregado que consiste em um componente básico <cbc:ID>. Também é possível ver que o <cbc:ID> também é usado no <cac:SellersItemIdentification> e é semanticamente o mesmo, só que usado em contextos diferentes.

A importância das listas de códigos controladas localmente externas ao esquema pode ser ilustrada aqui. Se você tentou incluir a lista de valores válidos do SellersItemIdentification na definição de esquema, será necessário um esquema separado para cada comunidade de usuários, além da manutenção contínua de cada uma das listas de valores válidos alterados.

Na Figura 6, é possível ver como é fácil mudar a forma como as empresas trocam dados de negócios eletronicamente simplesmente plugando um backend de conversão de dados corporativos de trocas impressas para eletrônicas, sem alterar os sistemas existentes.

Figura 6. Troca de documentos com a UBL
Troca de documentos com a UBL

A UBL na Europa

Agora vamos ver como diversos países adotaram a UBL para ter uma idéia do poder e da economia que podem ser obtidos com a implementação de diversas soluções de UBL.

A experiência da Dinamarca

A Dinamarca foi a adotante inicial da UBL como uma solução para o e-commerce. O governo da Dinamarca percebeu que teria grandes reduções nos custos de processamento de faturas se pudesse receber todas as faturas em um formato padrão, e a UBL forneceu o padrão para a implementação. Com o poder do governo, eles legislaram o uso da UBL.

Além de simplesmente legislar o uso da UBL, eles tiveram que fornecer a infraestrutura para as empresas de pequeno e grande porte cumprirem a lei. Eles desenvolveram um portal para compra pública, um mercado de trabalho público acessível a todos os compradores e fornecedores públicos da Dinamarca, e procuraram agências para fornecer a conversão dos papéis para a UBL.

Apesar da fatura ter sido o primeiro documento UBL manipulado pela Dinamarca, na verdade ela pertence à última parte da cadeia de compra. O processamento eletrônico dos outros documentos da cadeia de compra, da proposta até a fatura, pode gerar eficiência e economia de custo. O trabalho direcionado a esse objetivo e a adoção da UBL 2.0 conduziram à adoção de um subconjunto dinamarquês da UBL 2.0 chamado OIOUBL.

A experiência da União Europeia

Liderados pela Dinamarca, representantes da Dinamarca, Suécia, Noruega, Finlândia, Reino Unido e Islândia criaram um grupo de trabalho para desenvolver um Subconjunto do Norte Europeu (NES) dos documentos da UBL 2.0.

O objetivo do NES é facilitar a harmonização de diferentes tipos de documentos de e-procurement nos países que já usam a UBL ou estão considerando o uso dos documentos da UBL 2.0. Isso fornece uma oportunidade para basear os documentos e processos de e-procurement em um NES coordenado.

A UBL será a base do projeto Pan European Public Procurement On-Line (PEPPOL) (consulte a seção Recursos). A visão geral do PEPPOL é que todas as empresas da União Europeia, incluindo as empresas de pequeno e médio porte, possam se comunicar eletronicamente com qualquer instituição governamental da União Europeia, em todos os processos de compra.

UBL na América do Norte

Surpreendentemente, parece haver muito pouca adoção da UBL na América do Norte. Até o momento a solução não foi considerada para uso. Uma exceção notável é o trabalho que está sendo executado pelo Departamento de Transportes dos Estados Unidos. O projeto-piloto de gerenciamento eletrônico de frete do país usa os seguintes documentos da UBL:

  • Status do Transporte
  • Aviso de Despacho
  • Aviso de Recebimento

Esse projeto-piloto incluiu dois fabricantes de vestuário chineses, duas empresas de transporte de carga, um operador de terminal de carga, duas empresas aéreas de charter, um comprador de vestuário dos Estados Unidos, uma empresa de logística de terceiros dos Estados Unidos e um agente de importação em uma demonstração de comércio eletrônico de última geração em um cenário complexo do mundo real. A arquitetura criou efetivamente um banco de dados federado sem nenhum ponto único de falha e sem duplicação de dados, como ocorre com as soluções de banco de dados centralizadas tradicionais.


A UBL como uma inovação disruptiva

Ao examinarmos como a UBL pode ser inserida na América do Norte, podemos nos basear na experiência Europeia e concluir que isso pode ser feito de diversas formas:

  • Legislar o uso da UBL. Os governos podem criar leis para obrigar o uso da UBL em todas as transações de negócios com o governo.
  • Decretar o uso da UBL. As organizações de grande porte (como as forças armadas) podem se recusar a fazer negócios com organizações que não usem a UBL.
  • Expandir o uso da UBL. Os fornecedores atuais podem oferecer a saída em UBL como uma opção nas suas ofertas de software atuais.

Como a terceira via pode ocorrer?

Existem duas formas:

  1. Os fornecedores de aplicativos de e-commerce existentes podem incluir a exportação e a importação para UBL como um recurso.
  2. Os fornecedores podem fornecer novos serviços de UBL que façam interface com os aplicativos existentes.

A primeira opção é um exemplo do que Christensen chama de inovação de sustentação. No entanto, somente as pessoas que comprarem tais aplicativos terão acesso ao recurso.

Um exemplo da segunda opção é a abordagem diferenciada oferecida pela Tradeshift® (consulte Recursos). Eles fornecem um software como serviço (SaaS) baseado na computação em nuvem para a troca de documentos de negócios UBL eletrônicos, incluindo a fatura eletrônica grátis. Eles se concentram na troca de documentos UBL, e não em aplicativos. Na camada inferior, eles fornecem uma interface baseada em navegadores para a geração e troca de faturas. Na camada superior, eles fornecem uma API aberta para que os fornecedores de softwares existentes possam incluir o backend UBL com custo reduzido (consulte a A Figura 6). É interessante observar que eles incluíram o recurso de "rede social" para implementar uma "linha de discussão" em todos os documentos.


Um planeta mais verde

À medida que mudamos de sistemas baseados em papel para trocas eletrônicas, contribuímos para um planeta mais verde. Por exemplo: quase 10% das árvores cortadas no planeta são usadas para criar papéis para a impressão de faturas. A eliminação da necessidade desses papéis pode contribuir para a redução do desmatamento, e essa é apenas uma das iniciativas que o estudo Smart2020 identifica com uma forma de a Tecnologias da Informação e Comunicação contribuir para a redução das emissões de carbono na Era da Informação.


Conclusão

Demonstramos que a UBL é uma tecnologia baseada em XML que possui mais de 40 anos de desenvolvimento sólido no domínio das linguagens de marcações gerais. A UBL foi projetada para conexão nas práticas de gerenciamento existentes nas áreas de negócios, jurídica, auditoria e registros e, através da redução do uso de documentos em papéis, pode contribuir para um planeta mais verde.

Ao invés de tentar substituir os aplicativos existentes no segmento de mercado de serviços financeiros, a UBL pode ser usada para converter as atuais trocas de documentos de negócios entre as organizações do papel para o formato eletrônico, com base em um padrão internacional.

A UBL foi projetada para atender de 80% a 90% dos requisitos de negócios comuns, sendo que a porcentagem remanescente é atendida através das customizações da UBL. As customizações incluem o uso de subconjuntos de documentos definidos pela UBL. É possível usar somente partes opcionais de um único documento UBL necessário, estender um documento UBL ou até mesmo propor um novo documento UBL. Além disso, a validação do conteúdo dos elementos de informação pode ser gerenciada localmente com listas de códigos baseadas no cliente.

O uso da UBL pode ser considerado uma inovação disruptiva, pois permite a toda uma nova população de consumidores (até 80% das organizações atuais) o acesso a trocas eletrônicas ao invés da troca de documentos em papel para a condução dos negócios.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Segmentos de mercado
ArticleID=604399
ArticleTitle=UBL e Inovação Disruptiva
publish-date=08312012