En el año 2000 fui contratado para llevar a cabo una consultoría en un Órgano Público del Estado de Brasil, con la misión de desarrollar productos para el Área de Fiscalización.

En aquella época una empresa de gran porte en el área de software estaba desarrollando hacía más de dos años, un Almacén de Datos para atender al Departamento de Fiscalización y no se vislumbraba resultado alguno dentro de los límites de tiempo del proyecto.

Al analizar la documentación generada, constatamos que esta era apenas una documentación de intenciones siguiendo los modelos de la metodología de la empresa y que reflejaba una especificación hecha por los usuarios, careciendo, así de mayores detalles técnicos necesarios para la consecución del proyecto.

Dada la urgencia de los resultados, tomamos entonces otro enfoque considerando las siguientes premisas en cuanto a los datos requeridos para el proyecto:

• El proyecto en ejecución había implantado nuevos sistemas de catastro y recaudación y estaba en vías de implantar otros con la utilización de modernas metodologías y herramientas y que garantizaban una buena calidad de datos;

• Las informaciones de recaudación proporcionada por los bancos también eran confiables y de buena calidad;

• Las demás informaciones previstas para participar en el sistema tales como la del Sistema COMEXT de SERPRO (Servicio Federal de Procesamiento de Datos) eran totalmente confiables;

• Otras informaciones presentadas por los contribuyentes eran procesadas mediante aplicaciones bajadas de sus sitios, desarrolladas recientemente por el proyecto en ejecución;

• El sistema de Auto de Infracción estaba totalmente digitalizado y recién implantado por el mismo proyecto.

En cuanto a los requerimientos necesarios para atender el área consideramos que:

• Una parte relevante de las necesidades del Área de Fiscalización están en la obtención de un conjunto de contribuyentes que respondan a algunos criterios que varían según el programa de fiscalización en ejecución;

• Este programa varía periódicamente y es difícil de sistematizar, ya que va a depender de eventos, prioridades o nuevas informaciones internas o externas agregadas a su Base de Datos;

• Los usuarios requieren tener la mayor flexibilidad posible para no depender del área de Tecnología de la Información en la preparación de los parámetros y casos seleccionables que respondan a los criterios definidos por los programas de fiscalización;

• Los usuarios requieren agilidad para permitir el análisis y ajuste del número de casos a su capacidad de gestión;

• El sistema sería usado por un número bastante restringido de usuarios.

Propusimos entonces la siguiente solución:

• El sistema debería ser repetitivo, sin necesidad de intervención del área de TI;

• El sistema debería minimizar los procedimientos operacionales para la generación de los datos necesarios, o sea, la información usada debería ser, en la medida de lo posible, ya existente en el banco de datos;

• El Sistema tendría una capa sobre el Modelo de Datos de forma que los nombres de los objetos del banco de datos fueran los nombres conocidos por el área de negocios y no los modelos implantados por el área de TI;

• El sistema debería usar las mismas estructuras de los datos existentes en las bases operacionales (replicadas o no);

• Definir el concepto de Tema como un conjunto de una tabla que sea de interés para el negocio. Así, una tabla podría ser separada en varios Temas.

• Definición de algunos atributos sobre las columnas de las tablas que confieren una función específica en la recuperación de los datos. Por ejemplo: Definir si la columna es un tipo de Elemento, si va a ser usado como Filtro, Dimensión, Métrica o un vínculo con otra tabla. Una columna podría tener varios atributos;

• Dado que el objeto resultante es siempre un conjunto de contribuyentes que satisfacen alguna condición propusimos definir que el resultado es siempre un conjunto de Elementos que pueden ser: CPF (Identificador de Contribuyente Persona Física), CNPJ (Identificador de Persona Jurídica), RENAVAM (Identificador de Vehículos Automotrices), IE – Inscripción Estadual, o cualesquiera otros;

• Uso de la teoría de conjuntos en las operaciones de Unión, Intersección y Sustracción de los elementos seleccionados (de un mismo tipo) produciendo otros conjuntos resultantes para la determinación del conjunto de interés;

El sistema actúa con refinamientos sucesivos: Una investigación está compuesta de Elementos, como resultado de selecciones de atributos de un Tema. La inclusión de nuevos atributos genera un nuevo conjunto que está contenido en el conjunto inicial, y así sucesivamente. En cualquier momento la investigación puede ser conservada por ya ser el resultado final, o para ser usada en otras investigaciones, ya sea para la recuperación o presentación de los datos.

A esta altura algunos lectores deben estar preocupados con la propuesta de acceso a los datos operacionales. La idea es usar las mismas estructuras, por ello en el caso analizado se usaron los mismos datos operacionales, debido al número limitado de usuarios que accesan el sistema y principalmente por una implementación del sistema conocida como Conjunto de Base. El Conjunto de Base es uno que se usa como referencia, de partida; o sea, que cualquier conjunto resultante siempre pertenece o está contenido en el Conjunto de Base.

Entrar en un Tema como Recaudación, Notas Fiscales Electrónicas, entre otros, sin un Conjunto de Base puede ser demorado para un sistema que sea repetitivo. Por eso, si el Conjunto de Base tiene algunos millares de Elementos y el banco de datos está bien configurado no hay mayores problemas.

Ejemplo:

Consideramos la existencia del Tema Catastro, el Tema Actividades Económicas de los Contribuyentes, el Tema de Recaudación y el Tema de Importaciones:

El objetivo es la obtención de Contribuyentes identificados por el CNPJ de una franja de capital social, de un conjunto de Actividades Económicas y que originaron más de un determinado valor y pagaron menos de un monto de impuesto en un período de referencia dado;

• En el Tema de Catastro, el usuario recupera el conjunto de contribuyentes (CNPJ) con capital social en la fase deseada. En el Tema de Actividades Económicas el usuario selecciona a los contribuyentes (CNPJ) que ejercen las actividades económicas de interés. Observe que el refinamiento es automático;

• El usuario puede conservar el resultado de la investigación para ser usado como Conjunto de Base de interés, y el CNPJ de los contribuyentes para el análisis posterior. Este Conjunto de Base es la forma más eficiente de investigar las demás informaciones que son archivos mucho mayores que los de los temas de Catastro y Actividades Económicas de un contribuyente, o usarlo en otras investigaciones;

• Como el sistema funciona con refinamientos sucesivos, aun no habiendo salvado la investigación, el sistema usará el conjunto obtenido en el punto (1) para la continuación de la investigación, pero con menor eficiencia.

• Partiendo del Conjunto de Base y el Tema de Recaudación, el usuario recupera el conjunto de contribuyentes (CNPJ) con pagos de uno o varios Códigos de Ingresos inferiores a un determinado valor en el período de referencia dado. En el Tema de Importaciones, el usuario recupera el conjunto de contribuyentes (CNPJ) que trajo como resultado valores por encima de un valor del período. En ese momento, el sistema utilizó el Conjunto de Base para ambos Temas además de haber hecho automáticamente el refinamiento.

En 4 tenemos el resultado deseado, una lista de CNPJ que corresponde al ejemplo. El usuario podría efectuar cualesquiera de las otras operaciones en los conjuntos obteniendo los conjuntos conforme a su necesidad, o igualmente seguir otra estrategia de navegación. Además, si la cantidad de elementos no responde a los requisitos, el usuario puede ajustar el capital social o usar otros códigos de actividad económica, u otros parámetros para incluir o eliminar contribuyentes del conjunto seleccionado.

Una vez obtenido el conjunto de elementos adecuado, salvo en un historial de investigaciones, este conjunto puede ser utilizado en cualquier momento para la extracción de datos de cualesquiera temas configurados en el sistema, o servir de control para la generación de casos y la emisión de órdenes de servicio para los equipos de fiscalización, o servir de conjuntos para participar en otras operaciones con nuevos conjuntos.

Este sistema estuvo disponible en su versión inicial en 6 meses y el resultado fue tan satisfactorio que pasó a ser utilizado por la Asesoría del Secretario de Ingresos para la extracción de información gerencial del área de recaudación, entre otras.

En la versión inicial implantada este sistema era conocido como “PLAFIS –Planeamiento de Fiscalización – Módulo Gerencial”. Posteriormente, fue conocido como “JONAS – Just Online Navigation Analysis and Selection System” (Sistema de Análisis de Navegación y Selección Justo En Línea).

La Historia se Repite

Posteriormente, en el 2014, fui contratado para un proyecto de consultoría en otro Órgano Público del Estado de Brasil. En aquella época la Administración tenía una gran expectativa en un proyecto, que llevaba como dos años en desarrollo, denominado “DW”, el cual consistía en el desarrollo de un banco de datos confiable residente en un servidor en la parte del ambiente operacional. Los datos eran transportados diariamente a este ambiente en un sistema basado en ACL (Audit Command Language) – Lenguaje de Comando de Auditoría que ejecutaba los procedimientos de recuperación en “Batch” (Lotes).

Aunque nuestro proyecto brindó algún apoyo a la consecución del proyecto DW, luego de más de tres años el proyecto DW fue declarado inviable. O sea, transcurridos 5 años, la expectativa de tener una base de datos para recuperar información esencial para la Administración se vio frustrada.

Pensando en una solución de transición hasta tanto se tuviese el nuevo sistema y un DW que sirviese a la Administración, recuperé el sistema JONAS descrito anteriormente que estaba en plataformas ya no apoyadas (Windows XP y Delphi 5), el cual fue instalado en una máquina virtual, la cual podría ser una alternativa en el camino hacia una solución para atender las necesidades de información de la Administración.

El JONAS fue configurado sobre la Base de Datos Operacional que servía a la Administración y no requirió ningún ajuste para la presentación del prototipo como propuesta de un camino alterno. Desafortunadamente, nuestro proyecto no tenía plazos ni recursos para desarrollar la solución en las plataformas actuales, lo que acabó ocurriendo posteriormente con la construcción del JONAS 2.0 utilizando otros recursos.

La solución descrita es muy adecuada para la recuperación de información con carácter sistemático o transitorio en espera o no de otras soluciones. Su capacidad de información es algo impresionante. Veamos a título de ejercicio el siguiente ejemplo:

Suponiendo que hay 20 Temas, cada uno con 5 atributos recuperables de información (una dimensión, por ejemplo, el Municipio es único independientemente de los valores posibles) podemos hacer el siguiente estimado:

Ante todo, 20 x 5 = 100 atributos. Del análisis combinatorio:

O sea: Existen 166,750 opciones de combinación de hasta 3 atributos, si fueran más atributos …

Obviamente muchas de las combinaciones podrían no tener sentido, pero están disponibles para los entendidos. Podemos decir que: En la profundidad de los datos no procesados existe una riqueza de informaciones que espera ser resaltada.

Vista de interfase con el Histórico de Investigaciones

Vista del Análisis de Información seleccionando la Dimensión Actividad Económica

3,034 total views, 4 views today