No ano 2000 fui contratado para consultoria em Órgão Público de Estado no Brasil com a missão de desenvolver produtos para a Área de Fiscalização.

Àquela época uma empresa de grande porte da área de software estava desenvolvendo há mais de dois anos um Data Warehouse para atender ao Departamento de Fiscalização e não se vislumbrava quaisquer resultados dentro dos limites de tempo do projeto.

Ao analisar a documentação gerada, constatamos que esta era apenas uma documentação de intenções seguindo os padrões da metodologia da empresa e que refletia uma especificação feita pelos usuários, carecendo, pois de maiores detalhes técnicos necessários à consecução do projeto.

Dada a premência de resultados, partimos então para outra abordagem considerando as seguintes premissas quanto aos dados necessários ao projeto:

• O projeto em execução havia implantado sistemas novos de cadastro, arrecadação e estava em vias de implantar outros já com a utilização de metodologias e ferramentas modernas e que garantiam uma boa qualidade de dados;

• As informações de arrecadação providas pelos bancos também eram confiáveis e de boa qualidade;

• As demais informações previstas para participarem do sistema tais como as do Sistema COMEXT do SERPRO (Serviço Federal de Processamento de Dados) eram totalmente confiáveis;

• Outras informações apresentadas pelos contribuintes eram atendidas através de aplicativos baixados a partir de seus sites, desenvolvidos recentemente pelo projeto em execução;

• O sistema de Auto de Infração estava totalmente digitalizado e recém-implantado pelo mesmo projeto.

Quanto aos requerimentos necessários ao atendimento da área consideramos que:

• Parte relevante das necessidades da Área de Fiscalização está na obtenção de um conjunto de contribuintes obedecendo a alguns critérios que variam segundo o programa de fiscalização em execução;

• Este programa varia periodicamente e é difícil ser sistematizado, já que vai depender de eventos, prioridades ou novas informações internas ou externas agregadas ao seu Banco de Dados;

• Os usuários necessitam ter a maior flexibilidade possível para não depender da área de Tecnologia de Informação na preparação dos parâmetros e casos selecionáveis que atendam aos critérios definidos pelos programas de fiscalização;

• Os usuários necessitam de agilidade para permitir a analise e ajuste da quantidade de casos à sua capacidade de gestão;

• O sistema seria usado por um número bastante restrito de usuários.

Propusemos então a seguinte solução:

• O sistema deveria ser iterativo, sem a necessidade de intervenção da área de TI;

• O sistema deveria minimizar os procedimentos operacionais para a geração dos dados necessários, ou seja, a informação usada deveria ser na medida do possível a já residente no banco de dados;

• O Sistema teria uma camada sobre o Modelo de Dados de forma que os nomes dos objetos do banco de dados fossem os nomes conhecidos pela área de negócio e não os padrões implantados pela área de TI;

• O sistema deveria usar as mesmas estruturas de dados residentes nas bases operacionais (replicadas ou não);

• Definir o conceito de Tema como um conjunto de colunas de uma tabela de interesse para o negócio. Assim uma tabela poderia ser decomposta em vários Temas.

• Definição de alguns atributos sobre as colunas das tabelas que conferem uma função específica na recuperação dos dados. Por exemplo: Define se a coluna é um tipo de Elemento, se vai se usado como Filtro, Dimensão, Métrica ou um elo com outra tabela. Uma coluna poderia ter vários atributos;

• Visto que o objeto resultante é sempre um conjunto de contribuintes que satisfazem a alguma condição, propusemos definir que o resultado é sempre um conjunto de Elementos, que podem ser: CPF (Identificador de contribuinte Pessoa Física), CNPJ (Identificador de Pessoa Jurídica), RENAVAM (Identificador de Veículos Automotores), IE – Inscrição Estadual, ou quaisquer outros;

• Uso da teoria dos conjuntos nas operações de União, Interseção e Subtração dos elementos selecionados (de um mesmo tipo) produzindo outros conjuntos resultado para a determinação do conjunto de interesse;

O sistema atua com refinamentos sucessivos: Uma pesquisa é composta de Elementos, resultado de seleções de atributos de um Tema. A inclusão de novos atributos gera um novo conjunto contido no conjunto inicial, e assim sucessivamente. Em qualquer momento a pesquisa pode ser salva, por já ser o resultado final, ou para uso em outras pesquisas, seja para recuperação e apresentação dos dados.

A esta altura alguns leitores devem estar preocupados com a proposta de acesso aos dados operacionais. A ideia é usar as mesmas estruturas, porem no caso em analise, usou-se sim dos mesmos dados operacionais, devido ao número limitado de usuários que acessam o sistema e principalmente por uma implementação do sistema conhecida como Conjunto Base. O Conjunto Base é um conjunto usado como referencia, de partida, ou seja, qualquer conjunto resultado sempre pertence ou está contido no Conjunto Base.

Entrar em um Tema como Arrecadação, Notas Fiscais Eletrônicas, entre outros sem um Conjunto Base pode ser demorado para um sistema que se propõe iterativo. Porem, se o Conjunto Base tem alguns milhares de Elementos e o banco de dados estiver bem configurado não há maiores problemas.

Exemplificando:

Consideramos a existência do Tema Cadastro, o Tema Atividades Econômicas dos Contribuintes, o Tema Arrecadação e o Tema Importações:

O objetivo é a obtenção dos Contribuintes identificados por CNPJ de uma faixa de capital social, de um conjunto de Atividades Econômicas e que importaram mais de um determinado valor e pagaram menos do que um valor de imposto em um período de referencia dado;

• Do Tema Cadastro, o usuário recupera o conjunto de contribuintes (CNPJ) com capital social na faixa desejada. Do Tema Atividades econômicas o usuário seleciona os contribuintes (CNPJ) que exerçam as atividades econômicas de interesse. Observe que o refinamento é automático;

• O usuário pode salvar o resultado da pesquisa para ser usada como Conjunto Base de interesse, CNPJ dos contribuintes para a análise posterior. Este Conjunto Base é a forma mais eficiente de investigar as demais informações que são arquivos bem maiores que os Temas Cadastro e Atividades Econômicas de um contribuinte, ou usa-lo em outras pesquisas;

• Como o sistema funciona com refinamentos sucessivos, mesmo não havendo salvo a pesquisa, o sistema usará o conjunto obtido em (1) para a continuidade da pesquisa, porem com uma eficiência menor.

• Partindo do Conjunto Base e o Tema Arrecadação, o usuário recupera o conjunto de contribuintes (CNPJ) com pagamentos de um ou vários Códigos de Receita inferiores a um determinado valor no período de referencia dado. Do Tema Importações, o usuário recupera o conjunto de contribuintes (CNPJ) que importou valores acima de um valor no período. Neste momento o sistema usou o Conjunto Base para ambos Temas além de haver feito automaticamente o refinamento.

  refinamiento.

Em 4 temos o resultado desejado, uma lista de CNPJ que atende ao exemplo. O usuário poderia efetuar quaisquer das outras operações nos conjuntos obtendo os conjuntos conforme a sua necessidade, ou mesmo seguir outra estratégia de navegação. Ademais se a quantidade de elementos não atende aos requisitos, o usuário pode ajustar o capital social ou usar outros códigos de atividade econômica, ou utilizar outros parâmetros para incluir ou eliminar contribuintes do conjunto selecionado.

Uma vez obtido o conjunto de elementos adequado, salvo em um histórico de pesquisas, este conjunto pode ser utilizado a qualquer momento para a extração dos dados de quaisquer Temas configurados no sistema, ou servir de controle para a geração de casos e emissão das ordens de serviço para as equipes de fiscalização, ou servir de conjuntos a participar de outras operações com novos conjuntos.

Este sistema ficou disponível na sua versão inicial em 6 meses e o resultado foi tão satisfatório que passou a ser usado pela Assessoria do Secretário da Receita para extração de informação gerencial da área de arrecadação entre outras.

Na versão inicial implantada este sistema era conhecido como “PLAFIS –Planejamento da Fiscalização – Módulo Gerencial”. Posteriormente, ficou conhecido como “JONAS – Just Online Navigation Analisis and Selection System”.

A História se Repete

Posteriormente, em 2014, em fui contratado em projeto de consultoria a outro Órgão Público de Estado no Brasil. Àquela época a Administração tinha uma grande expectativa em um projeto, já com dois anos de desenvolvimento, denominado “DW” que era a construção de um banco de dados confiável residente em um servidor à parte do ambiente operacional. Os dados eram diariamente transportados a este ambiente e um sistema baseado em ACL (Audit Command Language) executava os procedimentos de recuperação em “Batch” (Lotes).

Embora o nosso projeto tenha dado algum apoio à consecução do projeto DW, ao final de mais três anos o projeto DW foi declarado inviável. Ou seja, passados 5 anos, a expectativa de ter uma base de dados para recuperar informação essencial à Administração foi frustrada.

Pensando em uma solução de transição enquanto não se tivesse o novo sistema e um DW que atendesse a Administração, recuperei o sistema JONAS descrito acima que estava em plataformas não mais suportadas (Windows XP e Delphi 5), que foi instalado em uma máquina virtual, mas que poderia ser uma alternativa no encaminhamento de uma solução para atender as necessidades de informação da Administração.

O JONAS foi configurado sobre Banco de Dados Operacional que atendia a Administração e não necessitou de nenhum ajuste para a apresentação do protótipo como proposta de um caminho alternativo. Infelizmente o nosso projeto não possuía prazos nem recursos para o desenvolvimento de solução nas plataformas atuais, o que acabou ocorrendo posteriormente com a construção do JONAS 2.0 utilizando outros recursos.

A solução descrita é uma solução muito adequada para a recuperação de informação em caráter sistemático ou transitório no aguardo ou não de outras soluções. Sua capacidade de informação é algo impressionante. Vejamos a título de exercício o seguinte exemplo:

Supondo haver 20 Temas, cada um com 5 atributos recuperáveis de informação (uma dimensão, por exemplo, Município é único independente dos valores possíveis) podemos fazer a seguinte estimativa:

Ao todo 20 x 5 = 100 atributos. Da análise combinatória:

Ou seja: Existem 166.750 opções de combinação até 3 atributos, se forem mais atributos.

Obviamente muitas das combinações podem não fazer sentido, mas estão disponíveis para os curiosos. Podemos dizer que: Nas profundezas dos dados brutos existe uma riqueza de informações no aguardo em ser alçada.

Vista da interface com Histórico de Pesquisas

Vista da Analise de Informação selecionando a Dimensão Atividade Econômica

2,637 total views, 2 views today