SciELO - Scientific Electronic Library Online

 
vol.2 número2EVALUACIÓN DE LA PRÁCTICA EDUCATIVA ESTUDIANTIL CON MIRAS A VALORAR EL FUTURO DESEMPEÑO PROFESIONALPOLITICAS Y SEGURIDAD DE LA INFORMACION índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados

Revista

Articulo

Indicadores

Links relacionados

  • No hay articulos similaresSimilares en SciELO

Compartir


Fides et Ratio - Revista de Difusión cultural y científica de la Universidad La Salle en Bolivia

versión On-line ISSN 2071-081X

Fides Et Ratio v.2 n.2 La Paz sep. 2008

 

ARTICULO ORIGINAL

 

IMPLEMENTACION DE UN SISTEMA DE INFORMACION DECISIONAL PARA EL ANALISIS DEL FLUJO DE TRÁMITES Y TRANSACCIONES EN EL AMBITO AUTOMOTOR.

 

 

Ricardo Medina Pacheco

Docente Ingeniería de Sistemas

 


 

 

INTRODUCCION

Entre las distintas instituciones gubernamentales en nuestro país que brindar servicios informáticos se encuentra el Registro Único para la Administración Tributaria Municipal (R.U.A.T), institución encargada de proporcionar sistemas de apoyo a las transacciones que actualmente realizan los Gobiernos Municipales.

La Institución nació el año 1997 con la responsabilidad inicial de diseñar, implementar y administrar un sistema informático que permita a todas las instituciones con atribuciones en el rubro automotor, cumplir con sus específicas funciones otorgadas por Ley.

Durante los primeros años de existencia, la Institución, anteriormente llamada RUA, se dedicó a estabilizar los sistemas otorgados a los Gobiernos Municipales, a la Policía Nacional y a la red Bancaria encargada de los cobros correspondientes.

Entre las principales actividades que se llevan a cabo en esta institución están la de administración de la información y el cobro de impuestos, además de proporcionar un sinnúmero de reportes diarios, mensuales y anuales tanto para las alcaldías, como para otras entidades que intercambian información con la institución.

En el transcurso del tiempo se fueron presentando una serie de oportunidades en el entorno cercano a la institución que abrieron otras opciones de desarrollo de sistemas y que permitieron el incremento en los niveles de recaudación de la entidad. El ingreso del RUA a los rubros de Bienes Inmuebles y Patentes Municipales es el ejemplo más claro de cómo la institución asumió mayores responsabilidades a partir de estas circunstancias externas.

 

PROBLEMATICA GENERAL

Actualmente, a pesar de contar con un sistema bastante completo en cuanto a la generación de reportes, estos continúan extrayendo información de estructuras que tienen un diseño obsoleto y no del todo normalizado, además de que no cuenta con una estructura especifica para la generación de los mismos, es decir que toda la información generada diaria y semanal y mensualmente es extraída de la base de datos de producción.

Para subsanar este problema se creó una base de datos alterna la cual sería utilizada específicamente para la generación de reportes, pero el hecho de ser una replica exacta de la base de datos de Producción no mejora el hecho de la obsolescencia del diseño ni tampoco el hecho de que para extraer cualquier tipo de información de utilidad estratégica se debe acceder a una gran cantidad de estructuras lo que disminuye el buen desenvolvimiento del mismo reporte.

Aún mejorando las consultas para la extracción de información, esta no refleja las necesidades mismas de algunos grupos importantes de usuarios como ser:

•      Las MAE, nivel destinado a la Máxima Autoridad Ejecutiva.

•      Oficialía Mayor, nivel destinado específicamente a los oficiales mayores de los Municipios

•     Dirección, destinado a los directores de ingresos, directores de recaudaciones y otros similares.

•     Jefaturas de división, destinado exclusivamente a los mandos medios (Jefatura de la División de Vehículos, Jefatura de la División de Inmuebles, etc.)

Ahora, refiriéndonos exclusivamente al flujo de trámites y transacciones en el ámbito de vehículos automotores efectuados en los distintos Gobiernos Municipales, podemos decir que actualmente estos no cuentan con herramientas estratégicas para el análisis de dicha información. Las decisiones tomadas, desde la máxima autoridad hasta los mandos medios, son inferidas a través de reportes diarios proporcionados por los operarios, lo cual no les brinda el suficiente conocimiento de la situación actual como para tomar decisiones inmediatas.

 

ANALISIS Y PROPUESTA DE SOLUCION

CICLO DE DESARROLLO

Siguiendo el los pasos para la construcción de un Data Warehouse, definimos nuestro ciclo de desarrollo:

 

SELECCIÓN DE ESTRATEGIA DE IMPLEMENTACION -ESTRATEGIA DE ABAJO HACIA ARRIBA (DE LO PARTICULAR A LO GENERAL)

Este enfoque es ideal para el presente proyecto ya que comienza con experimentos y prototipos basados en tecnología. Según lo especificado anteriormente seleccionaremos un subconjunto específico, bien entendido. Esta solución es considerada la mas rápida ya que comprende menos gente teniendo que tomar un menor numero de decisiones para resolver un problema especifico.

Beneficios del uso de esta estrategia:

•      Las consideración no tienen que ser de largo plazo y las soluciones propuestas son de implementación inmediata

•      Esta estrategia permite ser estudiada por parte de la dirección sin grandes compromisos ni costos

•      Como son diseños a menor escala, la toma de decisiones para los requerimientos es mas rápida por la menor cantidad de gente interviniente.

 

SELECCIÓN DE LA METODOLOGIA DE DESARROLLO

La metodología es la de desarrollo en Espiral. En este método, el énfasis esta en la velocidad y la culminación, con un reconocimiento de que los requerimientos no se pueden identificar con claridad o especificar al inicio. El enfoque se basa en la observación de que es más fácil redirigir un sistema desplegado con base en nuevos requerimientos que construir una solución completa basada en requerimientos inadecuados o no disponibles.

Por lo tanto, el método espiral es partidario de la rápida generación de sistemas cada vez mas funcionales con intervalos cortos entre versiones sucesivas. El intervalo entre versiones se emplea para identificar e implementar funcionalidad adicional.

 

REQUERIMIENTOS

REQUERIMIENTOS DE LA INSTITUCIÓN

Dentro de los requerimientos que tenemos para la empresa tenemos a los siguientes:

La necesidad de construir un Data Warehouse ocurre por la carencia de información rápida y útil que sirva a las Alcaldías para tomar la mejor decisión sobre la administración de los ingresos y oportunidades de los negocios.

Dentro de los objetivos empresariales están los siguientes:

o Brindar información útil a las Alcaldías.

o Trasmitir calidad de la información a los diferentes municipios de nuestro país.

o Realizar proyecciones de recaudación de las Alcaldías.

Otra parte de los requerimientos empresariales son las especificaciones de ámbito para el Data Warehouse, estos se basan en términos de lo mencionado a continuación:

Áreas o temas comunes de análisis

Estos son los temas de interés de diversas funciones empresariales, la selección cuidadosa de las áreas o temas comunes contiene el ámbito de implementación del Data Warehouse al tiempo que maximiza su utilidad.

Los distintos niveles de usuarios identificados como las MAE, Oficial Mayor, Dirección, Jefaturas de división nos sirven para la elaboración del Data Warehouse son:

•      Comportamiento del contribuyente

•      Decisiones sobre promoción o incentivos

•      Decisiones sobre canales de cobro de impuestos

•      Pronóstico de tendencias o proyecciones que el RUA podría tener.

•      Pruebas de calidad del sistema actual.

Dimensiones

Un Data Warehouse organiza un gran conjunto de datos operacionales e históricos mediante múltiples dimensiones de categorización. Una importante es el tiempo. A los datos operacionales se les asigna un registro de tiempo (fecha y hora) para luego establecer una referencia de tiempo con los datos. Las dimensiones de más uso en las consultas de los reportes establecidos son:

•      Tiempo

•      Características de los objetos (alcaldía)

 

REQUERIMIENTOS DEL ARQUITECTO

El arquitecto es la persona responsable de diseñar los diversos componentes del Data Warehouse para sustentar las necesidades actuales y futuras. La calidad del esfuerzo de arquitectura determinará lo siguiente:

• El rango de plataformas necesarias para la implementación, actualmente la plataforma no sufrirá ninguna modificación y esta implementada en Windows NT, un motor de base de datos Oracle 8i y como herramientas de apoyo al proyecto se proponer utilizar en caso de un implementación Warehouse Builder y Discoverer de los productos Oracle.

•      La flexibilidad para incorporar mejoras, por la variedad de características que se tiene en la información que puede variar con el tiempo.

Con respecto a la planeación de Arquitectura Empresarial (EAP) se utilizará la siguiente:

•      Una arquitectura de datos, la cual describe los elementos de datos y sus relaciones. La caracterización de datos se ve como una actividad fundamental. La razón es que las aplicaciones no pueden desarrollarse sin definir los datos que deben crear o modificar. Las arquitecturas de datos se describen en general como modelos entidad - relación.

 

REQUERIMIENTOS DE LOS USUARIOS FINALES

El usuario final ve al Data Warehouse como una caja negra cuyo acceso principal es a través de aplicaciones y herramientas de consulta y reportes, junto con cierto tipo de ubicación de la información contenida dentro del Data Warehouse.

Requerimientos de consulta

En la fase de planeación, ya se mencionó el empleo de escenarios de uso empresarial como una valiosa herramienta para hacer prototipos de las capacidades del Data Warehouse y también para establecer las expectativas del usuario final.

A continuación citaremos muestras de consultas empresariales que se necesitaran para la elaboración del Data Warehouse:

•      Índice de recaudación por zona geográfica

•      Índice de recaudación por distrito

•      Índice de recaudación por gestión

•      Índice de recaudación por concepto de pago

•      Índice de recaudación por tipo de vía (inmuebles)

•      Índice de recaudación por tipo de construcción

•      Índice de recaudación según servicios básicos con lo que se cuenta

•      Proyección de recaudación según los distintos planes de pagos

Las variables que intervienen en los índices de recaudación mencionados anteriormente son:

• Alcaldía

•      Bancos

•      Tipo de pago

•      Barrio

•      Tiempo

•      Tipo de vía

•      Servicios básicos

•      Calidad de construcción

•      Gestión de cobro

•      Tipo de propietario

ANALISIS Y DISEÑO

Especificaciones del Modelo

Base de datos operacional - Fuente OLTP

Debido a políticas de confidencialidad las tablas han sido parcialmente alteradas, pero estos cambios no afectaran la esencia misma de la estructura.

 

 

 

Caso de uso: Administrar Procesos.

Actores: Administrador del sistema

Propósitos: El DataMart deberá ser administrado por una persona especializada, danto el mantenimiento y la actualización al sistema

Caso de uso: Emitir proyecciones.

Actores: MAE, Jefe de división

Propósitos: La emisión de los reportes de proyecciones estará orientada a los dos niveles más altos de los gobiernos Municipales

Caso de uso: Emitir Reportes.

Actores: Oficial Mayor Jefe de división

Propósitos: La emisión de los reportes menos detallados estará orientada a los dos niveles más bajos de los gobiernos Municipales

 

CONCLUSIONES

Después de haber concluido el modelo propuesto hemos podido observar que seria de gran ayuda para los municipios contar con información especializada para:

o Proponer nuevos incentivos de cobro o Discriminar áreas de alta y baja recaudación para la toma de decisiones

o Proponer mejoras en el radio urbano dependiendo de las áreas de recaudación elevada

En cuanto a la Institución como tal los beneficios serian:

o Disminución en los accesos a la Base de Datos de Producción

o Mejora en la imagen de la institución a través de la mejora en el servicio