Inteligencia de negocios en INFA.

(1)

I IN N ST S TI IT TU UT TO O P PO OL LI IT TÉ É C C NI N IC CO O N N AC A C IO I ON N AL A L

MÉXICO, D.F. 2010 UNIDAD PROFESIONAL INTERDISCIPLINARIA DE

INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS

“ I N T E L I G E N C I A D E N E G O C I O S E N I N F A ”

I N F O R M E D E P R Á C T I C A P R O F E S I O N A L

Q U E P A R A O B T E N E R E L T Í T U L O D E:

LICENCIADO EN CIENCIAS DE LA INFORMÁTICA

P R E S E N T A :

L I L I A N A M E N E S E S B E N Í T E Z

S.

(2)

ÍNDICE

RESUMEN... i

INTRODUCCIÓN...ii

CAPÍTULO I. MARCO METODOLÓGICO. ... 1

1.1 Planteamiento del problema. ... 1

1.2 Objetivos... 1

1.2.1 Objetivo general. ... 1

1.2.2 Objetivos específicos. ... 1

1.3 Justificación. ... 2

1.4 Hipótesis. ... 2

1.5 Tipo de investigación. ... 2

1.6 Técnica de investigación a emplear. ... 2

CAPÍTULO II. MARCO TEÓRICO Y REFERENCIAL... 3

2.1 Conceptos clave y su aplicación... 3

2.1.1 Inteligencia... 3

2.1.2 Negocio. ... 3

2.1.3 Inteligencia de Negocios. ... 3

2.1.4 Data Warehouse. ... 3

2.1.5 Data Mart. ... 4

2.1.6 Arquitectura del Data Warehouse con Data Marts. ... 4

2.1.7 Minería de datos. ... 5

2.1.8 Procesos ETL. ... 6

2.1.9 Modelamiento Dimensional... 6

2.1.10 Fact Table / Tabla Fact... 7

2.1.11 Tabla de Dimensión. ... 7

2.1.12 Metodología Kimball. ... 7

(3)

2.1.14 Entorno de la Información... 8

2.2 La empresa: INFA. ... 9

2.1 Misión y Visión. ... 9

CAPÍTULO III. ANÁLISIS DE LA INVESTIGACION DE CAMPO. ... 11

3.1 Análisis de la Solución (Propuesta)... 11

3.1.2 Propuesta de Solución General. ... 11

3.2 Análisis de Costos. ... 12

3.3 Diagnóstico... 12

CAPITULO IV. PROPUESTA. ... 13

4.1 Análisis y Diseño... 13

4.1.1 Esquema Funcional y Operativo. ... 13

4.2 Inteligencia de Negocios en INFA. ... 14

4.2.1 Planteamiento del Problema... 14

4.2.2 Propuesta de Solución. ... 15

4.2.3 Análisis Costo–Beneficio. ... 16

4.3 Construcción. ... 18

4.3.1 Generación de ETL. ... 18

4.3.1.1 SATA (Visitas Médicas)... 18

4.3.1.1.1 Análisis SATA. ... 18

4.3.1.1.2 Diseño SATA... 23

4.3.1.1.3 Construcción SATA. ... 33

4.3.1.2 ATB... 59

4.3.1.2.1 Análisis ATB. ... 59

4.3.1.2.2 Diseño ATB. ... 61

4.3.1.2.2 Construcción ATB... 68

4.3.1.3 MPFM. ... 81

4.3.1.3.1 Análisis MFPM. ... 81

4.3.1.3.2 Diseño MFPM... 82

(4)

4.3.1.3.3 Construcción MFPM... 90

4.3.1.4 Reporte Ejecutivo. ... 112

4.3.1.4.1 Análisis Reporte Ejecutivo. ... 112

4.3.1.4.2 Diseño Reporte Ejecutivo... 116

4.3.1.4.3 Construcción Reporte Ejecutivo. ... 125

4.3.1.5 CLOSE-UP. ... 144

4.3.1.5.1 Análisis Close-Up... 144

4.3.1.5.2 Diseño Close-Up... 147

4.3.1.5.3 Construcción Close-Up. ... 151

4.4 Liberación ... 159

4.4.1 Manuales. ... 159

CONCLUSIONES. ... 175

BIBLIOGRAFÍA. ... 176

GLOSARIO. ... 177

ANEXOS. ... 178

(5)

RESUMEN.

La Tecnología de Información (TI) es, en la actualidad, un componente de gran importancia para cualquier organización, sin embargo, en los datos y su adecuado manejo como transformaciones, búsqueda de patrones, y consolidaciones, es lo que da un carácter estratégico a TI en la organización. En este contexto es donde aparecen conceptos como el de Inteligencia de Negocios, que apoyados en técnicas, estrategias, metodologías y herramientas buscan ofrecer información más adecuada para la toma de decisiones. Una decisión adecuada en una organización se traduce en mejoras significativas sea en dinero u otro beneficio. Una solución de Inteligencia de Negocios puede con gran posibilidad, cambiar el rumbo de una organización hacia escenarios más favorables y más beneficiosos.

En el mercado existen diversas herramientas que apoyan a la implementación de Inteligencia de Negocios, pero son muy pocas las organizaciones que los utilizan en nuestro país, principalmente por el alto costo que implican la plataforma informática de este tipo de soluciones o porque las soluciones existentes cubren una parte y no todo el espectro de posibilidades.

La implementación de soluciones de Inteligencia de Negocios se apoya necesariamente en un conjunto de herramientas informáticas que tienen que cubrir un ciclo de trabajo que comienza con la extracción de los datos de diversas fuentes de información como archivos de bases de datos de diferentes proveedores, hojas de cálculo, archivos planos, entre otros; continuando con un proceso de transformación de los mismos, que puede ser tan simple como la homogenización de los datos a conversiones complejas que se realizan en varias etapas; y, finalmente el análisis de la información a través de diversos reportes tabulares y gráficos que permitan a la alta dirección de una organización tomar decisiones. Una solución básica de Inteligencia de Negocios utiliza grandes almacenes de datos (data Warehouse) y herramientas que ayuden al diseño de las transformaciones y la explotación de la información; cada cual con sus diversas complejidades.

(6)

INTRODUCCIÓN.

En el mundo de los negocios, ha sido reiteradamente reivindicado el valor del “sexto sentido” de los altos ejecutivos de las empresas para fundamentar sus decisiones estratégicas. Sin embargo las nuevas, y algunas no tan nuevas características del entorno empresarial bajo los efectos de globalización de las empresas, de los mercados, de las tecnologías, de los flujos de capitales y de los productos, ejercen una enorme influencia sobre la competitividad y la productividad de las organizaciones, presionando con ello a fundamentar cada vez menos las decisiones en los sentidos, para hacerlo cada día más apoyados en los sistemas de información y las tecnologías.

En efecto, como respuesta a las nuevas condiciones del mercado, ahora con alcance mundial por la globalización de las economías, se han desatado un valor especial al uso de sistemas de información proveedores de los elementos para la toma de decisiones que corresponda al problema detectado, así como al logro de la meta planteada. Se puede reconocer, que el objetivo final de esta clase de aplicaciones es apoyar al personal responsable de la administración de una función, área o de toda la organización en el mejor desempeño de su tarea, especialmente en la toma de decisiones.

En el presente reporte de práctica profesional se enfoca a la problemática de la empresa INFA, empresa mexicana dedicada a la investigación y creación de productos de índole farmacéuticos;

con su información.

En el primer capítulo de este trabajo se describen las directrices generales para abordar el tema de la práctica profesional, en el que se realizó el planteamiento del problema detectado en la empresa INFA, definiendo desde los objetivos hasta la justificación del problema. En el capítulo II se presenta el marco referencial con el objeto de mostrar la información general de la empresa INFA, así como la definición de conceptos clave.

En el capítulo III se presenta la propuesta de solución, elaborada por BIS Soluciones, para la empresa INFA, así como los beneficios, ventajas y desventajas de la implementación de una solución de Inteligencia de Negocios.

Finalmente, con base a la información recopilada se presenta el capítulo IV, el cual es el resultado de este trabajo, que es el desarrollo de los procesos que extraerán, transformarán y cargaran la información en el Data Mart de la empresa INFA.

(7)

CAPÍTULO I. MARCO METODOLÓGICO.

En este capítulo se describen las directrices generales para abordar el tema de este informe de práctica profesional, en donde se realiza el planteamiento del problema, definición de los objetivos y la justificación de los mismos, así como el tipo de investigación y la técnica de investigación a emplear.

1.1 Planteamiento del problema.

En la actualidad las Tecnologías de la Información se han convertido en una herramienta clave en el proceso de desarrollo continuo dentro de las empresas. La competitividad del mercado y la globalización de la industria plantean un reto mayor dentro de toda organización pues se hace necesaria la innovación y el planeamiento estratégico que permita a la empresa trascender con un producto o servicio diferenciado. Para poder lograrlo se requiere que la información de la empresa se encuentre de forma adecuada para realizar un correcto análisis de la misma y se puedan tomar decisiones con mayor índice de certidumbre.

1.2 Objetivos.

1.2.1 Objetivo general.

Proporcionar a INFA la solución de Inteligencia de Negocios adecuada para el análisis correcto y eficiente de su información. Es importante notar que los datos de origen que serán cargados en el Data Mart y que pueden provenir de fuentes de datos heterogéneas.

1.2.2 Objetivos específicos.

• Generar cuatro Cubos Multidimensionales con la información del área Comercial, para las siguientes fuentes de datos:

SATA (Visitas Médicas, In-Bound/Out-Bound Clientes).

ATB (Participación de Mercado e Índice de Evolución por representante de Ventas INFA).

MFPM (Desplazamiento en unidades de los productos de INFA y de sus competidores).

CLOSE-UP (Close-Up Market y Close-Up Pharma).

• Generar el Reporte Ejecutivo, con las fuentes de datos que alimentan este mismo:

SATA (Visitas Médicas).

ATB.

ESAKT.

(8)

1.3 Justificación.

El problema planteado anteriormente, lleva a BIS Soluciones a plantear una solución que le permita obtener de forma eficiente la información estratégica para la toma de decisiones del área Comercial de INFA; mediante la utilización de herramientas tales como DataStage.

Respecto a la carrera de la cual provengo y al entorno en el cual me desenvuelvo, se aplicarán los conocimientos acerca de los procesos que intervienen de forma técnica, así como del análisis del negocio, dando el enfoque a las tecnologías de la información, procurando que cumplan con los objetivos establecidos.

Los resultados que obtendré como profesionista serán una proyección y una aplicación sobre el negocio al cual ofrecemos nuestros servicios, no solo de forma operativa sino estratégica para la toma de decisiones y así al tener ambos elementos seré aún más valiosa en mi entorno de trabajo, ya que tendré conocimiento y función sobre las reglas del negocio.

1.4 Hipótesis.

Se generará una solución de Inteligencia de Negocios para el área Comercial de INFA, mediante la herramienta de Inteligencia de Negocios DataStage, para integrar la información del área comercial y generar un mejor análisis de dicha información.

1.5 Tipo de investigación.

Descriptiva. Ya que se analizaran situaciones y eventos dentro del proyecto, buscando especificar cada uno de los componentes de este proyecto.

1.6 Técnica de investigación a emplear.

Para este proyecto las técnicas empleadas serán:

• Documentales. Fichas bibliográficas, información por parte del cliente y con esta llevar un registro de los pasos del proyecto.

• De campo. Que será por medio de entrevistas y cuestionarios a los encargados de la dirección del proyecto, así como a los empleados encargados del desarrollo del mismo.

(9)

CAPÍTULO II. MARCO TEÓRICO Y REFERENCIAL.

En este capítulo se abordará el tema del marco teórico y referencial sobre algunos aspectos de la Inteligencia de Negocios, con el objetivo de dar un panorama general de los conceptos utilizados dentro de este reporte de práctica profesional.

2.1 Conceptos clave y su aplicación.

2.1.1 Inteligencia.

Es la capacidad para aprender, en un contexto y tiempo reales la relación entre una situación problemática, la necesidad de su solución, la combinación específica de conocimientos conceptuales, instrumentales y operacionales y cómo utilizarlos para lograr, creativamente, una solución.

2.1.2 Negocio.

Actividad comercial o social que se ha pensado y se desea de que desarrollar. Es una herramienta que nos permite organizar y planificar las actividades que debemos realizar para lograr las metas de nuestra empresa cooperativa.

2.1.3 Inteligencia de Negocios.

Se puede definir como el uso de los datos recopilados con el fin de generar mejores decisiones de negocio, esto implica accesibilidad, análisis y revelar nuevas oportunidades.

Algunos conceptos de inteligencia de negocios no son nuevos, pero incluyen ahora la experiencia ganada desde los sistemas de información centrales hasta las aplicaciones de Data Warehouse.

La inteligencia de negocios busca proveer de un conjunto de tecnologías y productos para proporcionar a los usuarios la información que necesitan para resolver preguntas de negocios y tomar decisiones tácticas y estratégicas para el negocio.

2.1.4 Data Warehouse.

Kimball lo define como la conglomeración de un conjunto de datos, los cuales se requieren almacenar y presentar de forma organizada. Los datos de la operación que se almacenan están estructurados de tal forma que puedan ser consultados con el fin de analizarlos.

Según Kimball, podemos distinguir algunos elementos básicos del Data Warehouse:

(10)

Sistemas de Fuente Operacionales, la arquitectura en la cual se almacena los datos de la operación de la empresa.

Área de arreglo de los Datos, donde se ejecutan la depuración, estandarización y combinación de los datos de la fuente operacional. Además se almacena los datos y se ejecuta procesos de ordenamiento.

Área de Presentación de los Datos, donde se realiza la carga de los datos que conforman un Data Mart, haciendo uso del modelamiento dimensional.

Herramientas de Acceso a los Datos, que incluye aplicaciones para consulta específica, generadores de reportes, análisis de datos, modelamiento de proyecciones y estimación de resultados.¹

2.1.5 Data Mart.

Kimball lo define como subconjunto lógico y físico del área de presentación de datos en un Data Warehouse. Originalmente, los Data Mart fueron definidos como un subconjunto altamente agregado de datos, normalmente usados para resolver preguntas específicas del negocio. Esta definición resultó no ser la más apropiada pues provocaba que los Data Mart sean inflexibles de combinarse con otros.²

Esta primera concepción ha sido reemplazada, y el Data Mart es ahora definido como un conjunto flexible de datos, idealmente basado en los datos más atómicos posibles que se puedan extraer de una fuente operacional, y presentados en un modelo dimensional que es el que posee mayor capacidad de recuperación ante consultas inesperadas de los usuarios.

Los Data Mart pueden estar vinculados usando técnicas específicas al momento de conformar sus dimensiones. En este caso decimos que los Data Mart están conectados al bus del Data Warehouse.

En una forma simplificada, podemos decir que un Data Mart representa los datos de un proceso único de negocio.

2.1.6 Arquitectura del Data Warehouse con Data Marts.

El Data Warehouse suele contener un subconjunto de datos corporativos que son valiosos para una unidad de negocio específica, departamento o grupo de usuarios. Este subconjunto esta formado por datos históricos, sumariados, y posiblemente datos detalle del proceso de captura de

(11)

sistemas (llamados Data Marts independientes), o desde un Data Warehouse de la empresa (llamados Data Marts dependientes).³

Arquitectura del Data Warehouse con Data Marts.

2.1.7 Minería de Datos.

La minería de datos (DM, Data Mining) consiste en la extracción no trivial de información que reside de manera implícita en los datos. Dicha información era previamente desconocida y podrá resultar útil para algún proceso. En otras palabras, la minería de datos prepara, sondea y explora los datos para sacar la información oculta en ellos.

Bajo el nombre de minería de datos se engloba todo un conjunto de técnicas encaminadas a la extracción de conocimiento procesable, implícito en las bases de datos. Está fuertemente ligado con la supervisión de procesos industriales ya que resulta muy útil para aprovechar los datos almacenados en las bases de datos.

Las bases de la minería de datos se encuentran en la inteligencia artificial y en el análisis estadístico. Mediante los modelos extraídos utilizando técnicas de minería de datos se aborda la solución a problemas de predicción, clasificación y segmentación.

3 “Dimensional Modeling In a Business Intelligence”, página 40

(12)

2.1.8 Procesos ETL.

ETL - este término viene de ingles de las siglas Extract-Transform-Load y que significa Extraer, Transformar y Cargar. ETL es el proceso que organiza y consolida el flujo de los datos entre diferentes sistemas en una organización desde múltiples fuentes, formateándolos, limpiándolos y cargándolos en otra base de datos, Data Mart ó Data Warehouse. ETL forma parte de lo que se conoce como Business Intelligence, también llamado “Administración de los Datos” (Data Management).

Proceso ETL.

2.1.9 Modelamiento Dimensional.

Según Kimball, constituye una forma de modelamiento lógico de los datos orientado al rendimiento de las consultas y la facilidad de uso que se inicia de un conjunto de eventos de mediciones básicas. En el ámbito del modelo relacional de base de datos, una tabla Fact está acompañada de un conjunto de tablas de dimensión que le describen los atributos en el contexto de cada registro medidor. Por su estructura característica, al modelo dimensional se le conoce también como modelo de esquema estrella.

(13)

Dicho modelos dimensionales son la base de muchos componentes que agregan rendimiento en las bases de datos, incluyendo su considerable facilidad para poder vincular diferentes jerarquías de datos y aproximación por índices.

Los modelos dimensionales son la base para el desarrollo incremental y distribuido de los Data Warehouse a través del uso de dimensiones y Facts, además son la base lógica para los sistemas OLAP.⁴

Las características para llenar un modelo dimensional son:

• No deben existir en el modelo dimensional datos nulos.

• Cada dimensión tiene un código auto correlativo independiente que es su llave principal (IDENTITY).

• Los datos deben estar estandarizados. Ejemplo: si en alguna tabla se escribía 1 para masculino y 0 para femenino y en otra tabla se escribía M para masculino y F para Femenino. Al momento de llevar esta información al modelo dimensional todo debe esta estandarizado. Este tipo de conversión se hace en el proceso de ETL Extracción, transformación y carga.

2.1.10 Fact Table / Tabla Fact.

Kimball define que en un esquema tipo estrella (modelo dimensional), la tabla Fact representa la tabla central con medidores numéricos de rendimiento caracterizadas por una llave compuesta, cada una de ellas es una llave foránea en las tablas de dimensión.

2.1.11 Tabla de Dimensión.

Kimball define que en el modelo dimensional, una tabla de dimensión es una tabla con una única llave primaria y varias columnas de atributos descriptivos.

2.1.12 Metodología Kimball.

La metodología de Kimball se enfoca principalmente en el diseño de la base de datos que almacenará la información para la toma de decisiones. El diseño se basa en la creación de tablas de hechos (FACTS) que son tablas que contienen la información numérica de los indicadores a analizar, es decir la parte cuantitativa de la información.

“Ralph Kimball, es reconocido como uno de los padres del concepto de Data Warehouse, se ha dedicado desde hace más de 10 años al desarrollo de su metodología para que éste concepto sea bien aplicado en las organizaciones y se asegure la calidad en el desarrollo de estos proyectos.”⁵

4 http://www.gopac.com.mx/bi/index.htm

(14)

Ciclo de vida de los proyectos BI.

2.1.13 DataStage.

DataStage es una herramienta ETL que permite de una manera sencilla y versátil la creación y administración de procesos que integran información de diversas fuentes, ya sean homogéneas o heterogéneas, que se encuentren ubicadas en el mismo sitio o en servidores físicamente remotos.

Es una solución muy útil para proyectos de Data Warehouse, de integración de aplicaciones, integración de datos, etc. Posiblemente existan otros medios más económicos y conocidos que nos permitan realizar las mismas tareas, pero la ventaja de DataStage es la facilidad con que se desarrollan los procesos así como la administración de los mismos.

2.1.14 Entorno de la Información.

BI es sobre toda la información y la casa para dicha información es el Data Warehouse. El cual ya no es construido como una ventaja especial, sino que ahora es visto como un requisito empresarial. Este requisito es tener un entorno de información estructurada y organizada. Esta estructura contiene diferentes tipos y organizaciones de datos; y estos se pueden organizar en un ambiente estructurado. En la siguiente figura se muestra este ambiente como una pirámide de información.⁶

(15)

Pirámide de la información.

2.2 La empresa: INFA.

INFA (Investigación Nacional Farmacéutica) es una empresa mexicana fundada en los años 40’s, la cual esta dedicada a la fabricación de productos farmacéuticos, especializada en productos de salud femenina, así como también para el combate a la obesidad y el síndrome metabólico.

2.1 Misión y Visión.

Misión.

Nuestra Misión es la salud de los pacientes mejorando su calidad de vida. En Investigación Farmacéutica queremos ser reconocidos y respetados como una compañía que conduce negocios con la aplicación de elevados estándares éticos que cumplan con los requerimientos legales y regulatorios.

Visión.

Ser líderes en el mercado de obesidad y en el de salud femenina.

(16)

2.2.2 Política de Calidad.

Es el compromiso de INFA cumplir con las expectativas de nuestros Clientes ofreciendo productos farmacéuticos y suplementos alimenticios de Calidad a través de una Mejora Continua.

2.2.3 Objetivos de Calidad.

Los objetivos de calidad en la empresa INFA son:

• Estar dentro del ranking 40 a 45 en el año 2009, así como ser de las primeras 10 empresas farmacéuticas nacionales en el año 2012.

• Mantener un crecimiento de al menos el doble del mercado.

• Lanzar dos productos por año de al menos 10 millones de pesos cada uno en ventas con utilidad al tercer año como máximo.

• Lograr un alto nivel de servicio al cliente interno y externo (en tiempo y calidad) comparado con el histórico.

• Construir una nueva imagen para INFA (identidad corporativa, imagen, marca).

• Construir la vitalidad de la organización estableciendo un plan de sucesión y aprovechar el talento de la gente.

2.2.3 Organigrama.

Organigrama de la empresa INFA.

BIS Soluciones para el desarrollo del proyecto se encuentra ubicado a nivel STAFF en el área de

(17)

CAPÍTULO III. ANÁLISIS DE LA INVESTIGACION DE CAMPO.

En este capítulo se pretende mostrar el análisis de la solución, así como los beneficios, ventajas y desventajas de la implementación de una solución de Inteligencia de Negocios.

3.1 Análisis de la Solución (Propuesta).

3.1.2 Propuesta de Solución General.

Business Intelligence suele definirse como la transformación de los datos de la compañía en conocimiento para obtener una ventaja competitiva (Gartner Group). Desde un punto de vista más pragmático, y asociándolo directamente a las tecnologías de la información, podemos definir Business Intelligence como el conjunto de metodologías, aplicaciones y tecnologías que permiten reunir, depurar y transformar datos de los sistemas transaccionales e información desestructurada (interna y externa a la compañía) en información estructurada, para su explotación directa (reporting, análisis OLAP...) o para su análisis y conversión en conocimiento soporte a la toma de decisiones sobre el negocio.

Modelo integral de una solución BI.

(18)

3.2 Análisis de Costos.

La información en la actualidad se ha vuelto un componente de gran importancia para cualquier organización es la información, esto lo que lo convierte en un activo.

En INFA la información se encuentra distribuida en varios repositorios, que pertenecen a diferentes proveedores, esto a su vez, como ya se había mencionado, le genera costos y no sólo con los proveedores, sino también por el tiempo que le implica el poder generar un reporte con la información de sus diferentes fuentes. De tal manera que INFA puede estar perdiendo dinero por la toma de decisiones tardías.

Además el uso de recursos humanos es elevado, debido al gran tiempo que estos deben utilizar para la generación de sus reportes.

3.3 Diagnóstico.

La empresa INFA presenta problemas en conceptualización de información, su área de sistemas no se encuentra con la capacidad necesaria para poder implementar por sí misma un proceso de Inteligencia de Negocios, que permita a la Gerencia Comercial generar de forma fácil y eficiente el análisis de su información.

(19)

CAPITULO IV. PROPUESTA.

En este capítulo se presenta la propuesta de solución planteada por BIS Soluciones para la empresa INFA, en relación a sus problemas de análisis de información.

4.1 Análisis y Diseño.

La información en la empresa INFA presenta un grado de complejidad media, ya que no se requiere realizar cálculos complejos para su obtención en algunos casos, en otros simplemente los datos se toman desde la fuente hasta el destino.

Se plantea realizar un Data Mart, el cual contenga la información necesaria de las áreas de INFA, que son:

• Visitas Médicas.

• Ventas.

• Mercados.

• Close Up.

4.1.1 Esquema Funcional y Operativo.

Solución BI para la empresa INFA.

(20)

4.2 Inteligencia de Negocios en INFA.

En esta sección se explican los conceptos principales en el cual está fundamentado el procedimiento que se sigue para el desarrollo y determinación de la muestra que se aplicó en Impresora Chávez García y los cálculos realizados para su obtención.

4.2.1 Planteamiento del Problema.

INFA presenta un problema que muchas empresas en la actualidad lo sufren, el cual es tener información en diferentes repositorios, complicando el análisis de la información.

En INFA se encontraron las siguientes necesidades de información para la Gerencia Comercial:

1. Contar con un repositorio central, en el que converjan las distintas fuentes de información (VANTAGE, SATA, ATB, etc.) para contar con la capacidad de responder de forma veraz y oportuna a preguntas como las siguientes:

1) ¿Cómo se encuentra la alineación territorial de la fuerza de ventas?

2) ¿Cómo se están dando los Pagos de Incentivos?

Producto y por Distrito.

Por Producto y por Representante de Ventas.

En forma histórica por Distrito.

En forma histórica por Representante de Ventas.

3) ¿Cómo se encuentra la Cobertura en Unidades vs. la Cobertura en Visitas Médicas?

4) ¿Cómo se encuentra el Cobro de Incentivos vs. la Cobertura en Visitas Médicas?

5) ¿Cómo se encuentra la Rentabilidad?

6) Cuál es el Costo de Operación en función a:

Costo Distrito.

Volumen de Ventas en pesos vs. el Precio Promedio Esperado.

Costo de la Visita por Contacto (incluye Sueldos, Comisiones, Viáticos).

Costo de Material Promocional por ruta.

7) ¿Cuáles son los niveles de Productividad?

8) ¿Cuáles son las Variaciones vs. Rolling Forecast?

Tiempo histórico de procesamiento de lotes (desde que abre hasta que cierra)

(21)

2. Contar con los elementos necesarios para la elaboración de reportes más completos, que les permitan realizar análisis, de una forma gráfica y amigable, tales como:

1) Cobertura de la Fuerza de Ventas.

2) Ventas en unidades y dinero.

3) Ventas por Gerencia, por Regiones, por Divisiones, por Fuerza de Ventas, etc.

4) Variaciones de Logística, dando seguimiento en los cambios que se hayan podido realizar en la Fuerza de Ventas.

5) Rotación de Cuentas y Rankeo de Clientes.

6) Expectativas de Venta a través del Rolling Forecast y la Venta.

La información a nivel gerencial es un elemento en el cual se fundamentan las acciones y decisiones futuras, no sólo es un registro de lo que ocurrió en el pasado. Por lo que es fundamental para las empresas poder contar con un repositorio único de información.

4.2.2 Propuesta de Solución.

Derivado del punto anterior, la empresa INFA se le propone una solución de Inteligencia de Negocios, la cual consiste en la integración de las siguientes fuentes de datos en un solo repositorio, permitiendo así análisis integrados:

1) MFP.

2) SATA.

3) ATB.

4) CLOSE – UP (MARKET Y AUDIT PHARMA).

Modelo conceptual de solución para la empresa INFA.

(22)

Esta solución pretende terminar con los problemas actuales de análisis de información para la Gerencia Comercial de INFA.

4.2.3 Análisis Costo–Beneficio.

En la actualidad, la mayoría de las empresas manejan el concepto de retorno para sus inversiones.

El concepto de retorno viene por la cuantificación de los beneficios que va a suponer una determinada inversión y cuál es la calidad de esa inversión en función de los beneficios generados por ella.

Con los sistemas Business Intelligence obtenemos beneficios tanto en generación de nuevas oportunidades, mejora en la toma de decisiones y una notable disminución de costos.

En primer lugar hemos de ser conscientes de los costos en los que incurrimos cuando no tenemos una herramienta de Business Intelligence, que gráficamente se representan con esta balanza:

Balanza de ejemplificación del costo de no tener una solución BI.

Como se observa en esta balanza, se trata de costos contrapuestos.

• Costos Tangibles de la Información:

(23)

Horas de preparación de la información.

Costos de Interpretación de la Información.

Costo de los errores humanos en cálculo.

Costos No Humanos.

Horas de Equipo procesando búsqueda de información.

Horas de equipo preparando la información.

Horas de equipo transmitiendo.

• Costos Tangibles de la Desinformación:

Costo por no disponer de la información (no detectar los problemas).

No detectar objetivos no cumplidos.

No detectar desviaciones tácticas.

No controlar el cumplimiento de las estrategias.

No disponer de información para la toma de decisiones.

Tomar decisiones sin toda la información necesaria, coste de los errores.

Costo de oportunidad, (no detectar las oportunidades para generar negocio).

Comportamientos en campañas que aplicaríamos a mercados decrecientes.

Segmentos de alta rentabilidad, productos clientes, mix, etc.

Creación de información de alto valor para la toma de decisiones.

• Costos Intangibles de la información:

Costos de satisfacción del cliente interno.

Costos de aumento de productividad.

Costos de imagen corporativa.

Otros de menor importancia.

En toda empresa estos dos costos, los de información vs. desinformación deben estar equilibrados, ser iguales y deben sumar lo mínimo posible.

Por otra parte vendrá el aumento de beneficios, generados directamente de la posibilidad de disponer de sistemas Business Intelligence. Estos Beneficios vienen derivados de las nuevas oportunidades que se generan al disponer de esta tecnología y el uso correcto de la misma, como por ejemplo:

• Aumento de ventas por concentración de recursos.

• Aumento de ventas por focalización en segmentos de rentabilidad de clientes.

(24)

• Aumento de ventas por focalización en segmentos de productos.

• Aumento de márgenes por focalización en segmentos de mix de productos- clientes.

• Alineación de la empresa, (los empleados), según la estrategia.

• Toma de decisiones contando con todos los parámetros.

• Posibilidad de simulación de escenarios.

• Toma de decisiones basadas en cuadro de mando.

Hay efectos como el aumento de productividad de los empleados y directivos, la nueva imagen interna de la empresa de modernidad y avance, etc.

4.3 Construcción.

En esta sección se describe cada uno de los procesos de carga de los datos al modelo dimensional por cada modulo del proyecto “Inteligencia de Negocios en INFA”, pasando por el análisis, diseño y desarrollo. Cada proceso desarrollado con la herramienta DataStage.

4.3.1 Generación de ETL.

4.3.1.1 SATA (Visitas Médicas).

4.3.1.1.1 Análisis SATA.

SATA es un sistema que le permite a INFA conocer el número de visitas realizadas por cada uno de sus representantes, hacia los médicos y farmacias; permitiendo a INFA poder conocer la actividad de sus representantes y cuáles son los productos que estos están promocionando.

Este proveedor proporciona a INFA reportes y respaldos de la base de datos de forma mensual, los reportes dentro de un sistema Web y el respaldo dentro de un Backup en un Manejador de Base de Datos llamado postgres. Se definió que estas serán nuestras fuentes de análisis del sistema.

La fuente de datos final que se tomará, será la base de datos, ya que se considera como la fuente de datos más confiable para la extracción de la información. Para poder obtener la información es necesario conocer la Base de Datos y las tablas de la misma.

(25)

Se puede crear la conexión a la BD desde DataStage para las extracciones.

Puntos en contra:

• No se cuenta con el modelo de la BD.

• No se cuenta con el diccionario de datos.

A través de este sistema, INFA intentar cubrir los siguientes aspectos:

• Identificar a los clientes más rentables ó potenciales para cada producto, para brindar una atención personalizada y diferenciada.

• Reducir el tiempo en labores administrativas, permitiendo que su personal se enfoque en sus actividades de venta o servicio.

• Hacer de la información de sus clientes un activo de la empresa y no información del personal que los atiende.

• Establecer métricas de desempeño para dar un seguimiento de manera oportuna, cuando todavía hay posibilidad de tomar acciones correctivas en lugar de acciones reactivas.

• Optimizar el uso su material promocional haciendo que se entregue el material correcto al cliente objetivo y con la frecuencia que INFA defina.

• Trabajar desde cualquier lugar, ya que sólo se necesita de un acceso a Internet.

SATA maneja 2 tipos de entidades:

1. Instituciones.

2. Personas.

SATA maneja 2 Fuerzas de Ventas:

1. INFA.

2. CELN.

Nota: INFA y CELN solo cubren desde el Ciclo 200903 hasta el 200907, se definió que los ciclos anteriores al 200903 no se tomarán, debido a que las fuerzas de ventas son diferentes y están alineados a otros Bricks.

Las Fuerzas de Ventas están divididas en Territorios que se conocen como Rutas, las cuales a su vez están conformadas por Bricks, los cuales a su vez tienen Códigos Postales y Colonias. Esta estructura aplica a todos los estados de la república Mexicana.

Fuerza de Venta > Rutas > Bricks > CP y colonias.

(26)

La Fuerza de Ventas tiene una jerarquía como sigue:

Gerencia Nacional > Gerente de Distrito > Representante de Ventas.

La información a capturar de los médicos (Ficha del Médico) en el sistema es la siguiente:

Estatus del Médico (Nuevo o INFO100).

Nombre.

Apellido Paterno.

Apellido Materno.

Fecha de Nacimiento.

Sexo.

Bandera de Prescripción de Itravil (SI o NO).

Especialidad.

Actividad Académica.

Cédula Profesional.

Celular.

Email.

Maneja Igualas.

Bandera de Prescripción de Sibutraminas (SI o NO).

Número de pacientes a los que Prescribe Sibutraminas, expresado en Porcentaje.

Bandera de Prescripción de Medicamentos Controlados (SI o NO).

Número de pacientes a los que Prescribe Medicamentos Controlados, expresado en Porcentaje.

Número de pacientes que atiende en total por semana.

Número de pacientes que atiende de obesidad por semana.

Precio de la consulta.

Bandera de Prescripción de Alprazolam (SI o NO).

Teléfonos.

Estatus del médico que se está dando de alta debería de ser siempre INFO100, el cual se asigna una vez que se hayan proporcionado todos los datos requeridos por el sistema (los marcados en negritas, cursivas y subrayados). Para cambiar este estatus los representantes de ventas tienen hasta 90 días para llevarlo a cabo.

(27)

El manejo de Igualas significa que trabajo para algún banco o empresa como parte de su trabajo adicional al de tener su consultorio.

Los datos de la dirección a capturar serán los correspondientes a los de su Consultorio Principal, siendo estos los siguientes:

Tipo de Dirección.

Calle.

Número Exterior o Interior.

Código Postal.

Colonia.

Municipio.

Estado.

Teléfono de la Dirección.

Fax.

Referencia para ubicación.

Horarios.

El sistema está ligado al Sistema Postal Mexicano, por lo que los códigos postales se encuentran actualizados; el sistema a partir del código postal o de la colonia, busca y proporciona los datos del Municipio y del Estado correspondientes.

Los marcados en negritas, cursivas y subrayados son obligatorios para el sistema.

Los datos de las Instituciones que se capturan son los siguientes:

Nombre de la Institución.

Sucursal.

Email.

Página Web.

Matriz.

Estatus.

Los datos de las Farmacias que se capturan son los siguientes:

Nombre de la Farmacia.

Sucursal.

Email.

Matriz.

(28)

Página Web.

Estatus.

Clasificación 1 (RX, VDF Abierta al Público, VDF – Consultorio).

Clasificación 2 (No vende Controlados, Si Vende Controlados).

Clasificación 3 (Autoservicio, Farmacia Cadena, Farmacia Particular).

Estatus (Nuevo, Por Validar, Validado, Suspendido, Pendiente, Audit).

En cuanto a las Visitas Médicas se refiere, lo que pueden capturar los representantes de Ventas está lo siguiente:

Tipo de Visita (Llamada de Entrada, Llamada de Salida, Visita Farmacia, Visita Médica).

Bandera de Reasignación.

Fecha o Ciclos.

Hora.

Bandera indicativa de si tiene o no una cita.

Objetivo / Comentario.

Objetivo/ Siguiente.

Acompañado con: GNAC, GPRD, GDIS, DCOM, GMKT, OTROS.

Estatus (Planeada, Terminada, No Realizada, Reprogramada).

Clasificación (Normal o Ciclo).

Los representantes tienen indicado el grabar o agendar su primera cita del día, así como la primera después de la hora de la comida. También pueden “Reasignar” la cita a otro compañero de la misma ruta, aunque sea de otra Fuerza de Ventas. Estos casos en su mayoría son a sugerencia del Médico, ya que éste le pide al representante le notifique a su compañero de la necesidad que tiene de verlo.

SATA lleva un histórico de estas reprogramaciones, las cuales pueden ser consultadas por medio del módulo de “Análisis” con que cuenta.

Las calendarizaciones de las visitas se pueden visualizar a través del Calendario, ya sea por día, semana o mes.

Cuenta con un módulo de Análisis el cual a su vez tiene las siguientes opciones:

(29)

Indicadores.

La obtención de la información desde la fuente de información y la carga de la misma en el Data Mart se plantea con el siguiente diagrama:

Extracción de la información de SATA.

En donde toda la información de visitas se obtiene de la fuente SATA, agregándole la fuente INFAERP, de donde obtiene la alineación de la Fuerza de Ventas.

4.3.1.1.2 Diseño SATA.

Para la realización del diseño del modelo de visitas para INFA, se realizaron tareas previas, como lo fueron el análisis de la propia fuente de datos, pero no al punto de entender el 100% la aplicación, sino solo de las partes que se consideran importantes para el desarrollo del proyecto

“Inteligencia de Negocios en INFA”; así también se realizaron entrevistas con los usuarios finales para entender mejor sus necesidades y el negocio.

Como se describió en el análisis, la fuente de datos de donde se extrae la información es una base de datos denominada SATA, la cual se encuentra en POSTGRES SQL 8. Para el análisis de la información proveniente de esta fuente y funcionamiento de los cubos de información, se realizo un modelo de datos, el cual se muestra a continuación.

INFAERP

SATA

PROCESAMIENT

O PARA CARGA

Modelos Comerciales

(30)

Modelo de datos para el modulo SATA.

(31)

Este modelo de datos se obtuvo después de las entrevistas con los usuarios, las cuales fueron sensibles a las necesidades de los mismos. Para la realización se tomo como base la metodología de Kimball.

Dicho modelo está conformado por dos tablas FACTS (Visitas Resumen y Visitas) y 15 catálogos (Gerentes, Representantes, Clasificación actividad, Acompañamiento, Status visita, Tipo visita, Médicos, Precio Consulta, Fuerza de ventas, Bricks, Ciclos Promocionales, Especialidades, Clientes, Numero de pacientes a la semana, Numero de pacientes a la semana obesidad).

Para los catálogos de Gerentes, Representantes, Fuerza Ventas y Bricks su fuente es INFAERP.

A continuación se detalla cada uno de los catálogos y FACT contenidos en el modelo de Visitas.

GERENTES.

COLUMNA LLAVE TIPO LONGITUD

ID_DISTRITO_CONS NO VarChar 15

ID_DISTRITO SI VarChar 15

DESC_DISTRITO NO VarChar 45

ID_GTE_CONS SI VarChar 15

ID_NOMINA_GTE NO VarChar 15

DESC_GERENTE NO VarChar 50

ID_CNTO_COSTOS_GTE NO VarChar 10

FECHA_INICIO NO Char 16

FECHA_FIN NO Char 16

REPRESENTANTES.

ID_RUTA_CONS NO VarChar 20

DESC_RUTA NO VarChar 30

ID_RUTA SI VarChar 15

(32)

ID_REPRE_CONS SI VarChar 20

ID_NOMINA_REPRE NO VarChar 10

DESC_REPRE NO VarChar 50

ID_CNTO_COSTOS_RUTA NO VarChar 10

ID_FUERZA_VENTAS NO VarChar 10

HIBRIDO NO VarChar 20

CLIENTES.

ID_CATEGORIA NO Integer 10

DESC_CATEGORIA NO VarChar 50

ID_TIPO_CLIENTE NO Integer 10

DESC_TIPO_CLIENTE NO VarChar 50

ID_TIPO_CLIENTE_1 NO Integer 10

DESC_TIPO_CLIENTE_1 NO VarChar 50

ID_CLIENTE NO Integer 10

DESC_CLIENTE NO VarChar 50

ID_STATUS NO Integer 10

DESC_STATUS NO VarChar 50

ID_AUDIT NO Integer 10

DESC_AUDIT NO VarChar 50

PREESCRIBE_SIBUTRAMINA NO VarChar 50

PREESCRIBE_CONTROLADOS NO VarChar 50

(33)

ID_PRECIO_CONSULTA NO VarChar 50

RANGO_PRECIO_CONSULTA NO VarChar 50

ID_NUM_PAC_SEM NO VarChar 50

RANGO_NUM_PAC_SEM NO VarChar 50

ID_NUM_PAC_SEM_OBESIDAD NO VarChar 50 RANGO_NUM_PAC_SEM_OBESID NO VarChar 50

CLASIFICACION_ACTIVIDAD.

ID_CLASIFICACION NO Integer 10

DESC_CLASIFICACION NO VarChar 50

TIPO NO VarChar 50

ACOMPANAMIENTO.

ID_ACOMPANAMIENTO SI BigInt 19

DESC_ACOMPANAMIENTO NO VarChar 255

STATUS_VISITA.

ID_STATUS_VISITA SI BigInt 19

DESC_STATUS_VISITA NO VarChar 255

(34)

TIPO_VISITA.

ID_TIPO_VISITA SI BigInt 19

DESC_TIPO_VISITA NO VarChar 50

SUBTIPO NO VarChar 255

MEDICOS.

DESC_RUTA NO VarChar 50

ID_CLIENTE SI VarChar 50

DESC_CLIENTE NO VarChar 50

NUM_CEDULA_PROF NO VarChar 50

ACTIVIDAD_ACADEMICA NO VarChar 50

ID_ESPECIALIDAD NO VarChar 50

DESC_ESPECIALIDAD NO VarChar 50

ID_STATUS NO Integer 10

DESC_STATUS NO VarChar 50

PREESCRIBE_SIBUTRAMINA NO VarChar 50

PORCENTAJE_SIBUTRAMINA NO VarChar 50

PREESCRIBE_CONTROLADOS NO VarChar 50

PORCENTAJE_CONTROLADOS NO VarChar 50

MANEJA_IGUALAS NO VarChar 50

ID_PRECIO_CONSULTA NO Integer 10

(35)

RANGO_PRECIO_CONSULTA NO VarChar 34

PRECIO_CONSULTA NO VarChar 50

ID_NUM_PAC_SEM NO Integer 10

RANGO_NUM_PAC_SEM NO VarChar 25

PACIENTES_SEMANA_TOTAL NO VarChar 50

ID_NUM_PAC_SEM_OBESIDAD NO Integer 10

RANGO_NUM_PAC_SEM_OBESID NO VarChar 25

PACIENTES_SEMANA_OBESIDA NO VarChar 50

ID_AUDIT NO VarChar 50

DESC_AUDIT NO VarChar 50

PONDERACION NO VarChar 50

PRECIO_CONSULTA.

ID_PRECIO_CONSULTA SI Integer 10

RANGO_PRECIO_CONSULTA NO VarChar 34

NUM_PAC_SEM.

ID_NUM_PAC_SEM SI Integer 10

RANGO_NUM_PAC_SEM NO VarChar 25

NUM_PAC_OBESIDAD.

ID_NUM_PAC_SEM_OBESIDAD SI Integer 10

(36)

RANGO_NUM_PAC_SEM_OBESID NO VarChar 25

ESPECIALIDADES.

ID_ESPECIALIDAD SI VarChar 50

DESC_ESPECIALIDAD NO VarChar 50

CICLOS_PROMOCIONALES.

ID_CICLO SI BigInt 19

DESC_CICLO NO VarChar 250

DESC_CICLO_FV NO VarChar 50

ANIO NO VarChar 4

ID_FUERZA_VENTAS NO VarChar 50

BICKS.

ID_ESTADO SI Integer 10

DESC_ESTADO NO VarChar 50

ID_CIUDAD_ZONAPOSTAL SI VarChar 50

DESC_CIUDAD_ZONAPOSTAL NO VarChar 50

ID_BRICK SI VarChar 255

(37)

ID_FUERZA_VENTAS NO VarChar 50

FUERZA_VENTAS.

ID_PAIS SI Integer 10

DESC_PAIS NO VarChar 50

ID_REGION SI Integer 10

DESC_REGION NO VarChar 50

ID_GTE_NAL SI VarChar 50

DESC_GTE_NAL NO VarChar 50

ID_DISTRITO SI VarChar 50

VISITAS.

ID_CICLO SI VarChar 255

ID_CLIENTE SI BigInt 19

ID_DISTRITO_CONS SI VarChar 50

ID_RUTA_CONS SI VarChar 50

ID_BRICK SI VarChar 255

ID_TIPO_VISITA SI BigInt 19

(38)

ID_STATUS_VISITA SI VarChar 255

ID_CLASIFICACION SI BigInt 19

ID_ACOMPANAMIENTO SI BigInt 19

M_VISITAS NO BigInt 19

ID_PRECIO_CONSULTA SI Integer 10

ID_NUM_PAC_SEM SI Integer 10

ID_NUM_PAC_SEM_OBESIDAD SI Integer 10

ID_ESPECIALIDAD SI Integer 10

VISITAS_RESUMEN.

ID_CICLO SI BigInt 19

FECHA NO VarChar 50

ID_DISTRITO_CONS SI VarChar 50

ID_RUTA_CONS SI VarChar 50

ID_TIPO_VISITA SI Integer 10

M_VISITA_REALIZADA NO BigInt 19

M_VISITA_BASE NO Numeric 19

M_VISITA_REQUERIDA NO Numeric 19

M_INCIDENCIAS NO Numeric 19

M_PLAN_TRABAJO NO Numeric 19

M_COBERTURA NO Float 15

M_VISITA_ACOMPANADA NO BigInt 19

(39)

4.3.1.1.3 Construcción SATA.

La construcción de este proyecto está basada en los procesos ETL que cargan la información necesaria para llenar los modelos, en este caso particular es el de Modelos Vistas. Para dicho proceso se crearán los procesos necesarios en la herramienta ETL DataStage ®; se dividirán en cargas iníciales (historia) y periódicas (mensuales). Las cargas de la información se realizarán en una BD (Modelos Comerciales) en SQL Server 2005, esta tiene la misma estructura que el modelo de datos previamente mostrado.

Los procesos para tales cargas de información son como siguen:

• Especialidades.

En este proceso de carga solo se mapean los datos necesarios para el llenado del catálogo según el modelo de visitas, generando las siguientes reglas de negocio:

• Se obtienen los valores de entrada se obtienen desde la tabla CAT_DET con el siguiente QUERY:

SELECT ID_CAT_DET, CAT_DET_TYPE, VALUE, CAT_DET_SUBTYPE FROM CAT_DET.

• La derivación que se utiliza para filtrar la información es:

CAT_DET_TYPE = 'SPECIALTY'.

• La inserción hacia la tabla se realiza con el siguiente QUERY:

INSERT INTO "MODELOS_COMERCIALES"."DBO".LT_ESPECIALIDADES (ID_ESPECIALIDAD, DESC_ESPECIALIDAD) VALUES (?,?).

Siguiendo las reglas de negocio, el proceso queda de la siguiente forma:

Proceso de carga de información al catálogo de Especialidades Médicas.

(40)

• Ciclos Promocionales.

En este proceso solo se mapean los datos necesarios para el llenado del catálogo según el modelo de visitas, para lo cual se derivan las siguientes reglas de negocio:

• Los valores de entrada de obtienen de la tabla CYCLE, con el siguiente QUERY:

SELECT ID_CYCLE, NAME, FULL_NAME, START_DT, END_DT, CYCLE_SUBTYPE FROM CYCLE WHERE NAME LIKE '2%' ORDER BY NAME.

Debido a que años anteriores al 2000 no son necesarios.

• Para la derivación o transformación de datos solo se limpian los valores, ya que se deben eliminar espacios en blanco dobles.

• La inserción de los valores en la tabla destino, se realizan con el siguiente QUERY:

INSERT INTO

"MODELOS_COMERCIALES"."DBO".LT_CICLOS_PROMOCIONALES(ID_CICLO, DESC_CICLO, DESC_CICLO_FV, FECHA_INICIO, FECHA_FIN, ANIO, ID_FUERZA_VENTAS) VALUES (?,?,?,CONVERT(SMALLDATETIME,

?),CONVERT(SMALLDATETIME, ?),?,?).

Siguiendo las reglas de negocio, el proceso queda como sigue:

Proceso de carga del catálogo de Ciclos Promocionales.

(41)

• Número de Pacientes a la Semana.

Para este catálogo se definieron las reglas de correspondencia, ya que en la fuente de datos no este criterio no esta contemplado. Se obtiene la información desde un archivo plano (TXT) y las reglas de negocio a realizar son las siguientes:

• ID Pacientes Consulta.

Si el número de pacientes esta dentro de 0 y 24 entonces 1.

Si el número de pacientes es mayor a 200 entonces 7.

Si no es ninguna de las anteriores 8.

• Rango Pacientes Consulta.

Si el número de pacientes esta dentro de 0 y 24 entonces “Entre 0 y 25 Pacientes”.

Si el número de pacientes esta dentro de 75 y 99 entonces 'Entre 75 y 100 Pacientes”.

Si el número de pacientes es mayor a 200 entonces “Mayor a 200 Pacientes’.

Si no es ninguna de las anteriores 'N/A”.

• Para la inserción en la tabla del catálogo se define el QUERY:

INSERT INTO

"MODELOS_COMERCIALES"."DBO".LT_NUM_PAC_SEM(ID_NUM_PAC_SEM, RANGO_NUM_PAC_SEM) VALUES (?,?).

Con las reglas de negocio definidas, se obtiene el siguiente proceso de carga:

(42)

Proceso de carga del catálogo de Número de Pacientes por Semana.

• Número de pacientes a la semana obesidad.

Para este catálogo se definieron las reglas de correspondencia, ya que en la fuente de datos no está contemplada. Y se determino que este se llenaría mediante un archivo plano que se cargaría a la base de datos. Las reglas de negocio son las siguientes:

• ID Pacientes Consulta Obesidad.

Si el número de pacientes es mayor a 200 entonces 7.

Si no es ninguna de las anteriores 8.

• Rango Pacientes Consulta Obesidad.

Si el número de pacientes esta dentro de 75 y 99 entonces 'Entre 75 y 100 Pacientes”.

(43)

• Para cargar el archivo plano en la base de datos, se utilizará el siguiente QUERY:

INSERT INTO

"MODELOS_COMERCIALES"."DBO".LT_NUM_PAC_SEM(ID_NUM_PAC_SEM, RANGO_NUM_PAC_SEM) VALUES (?,?).

Siguiendo las reglas de negocio antes descritas, se genera el siguiente proceso de carga:

Proceso de carga del catálogo de Número de Pacientes por Semana Obesidad.

• Precio Consulta.

En este catálogo de igual forma se define una regla de negocio para su clasificación, la fuente de datos no proporciona estos, por lo que es necesario generar la siguiente regla de negocio:

• ID Precio Consulta.

Si el precio está entre 0 y 249 entonces 1.

Si el precio es mayo a 2000 entonces 7.

Si no es ninguna de las anteriores entonces 8.

• Rango Precio Consulta.

Si el precio está entre 0 y 249 entonces 'Entre $0.00 y $250.00 Consulta'.

(44)

Si el precio es mayor a 2000 entonces 'Mayor a $2000.00 Consulta'.

Si no es ninguna de las anteriores entonces 'N/A'.

• Para la inserción en la base el QUERY es:

INSERT INTO

"MODELOS_COMERCIALES"."DBO".LT_PRECIO_CONSULTA(ID_PRECIO_CONSULTA, RANGO_PRECIO_CONSULTA) VALUES (?,?).

Con las reglas de negocio anteriormente descritas, se tiene el siguiente proceso:

Proceso de carga del catálogo de Número de Precio Consulta.

• Clientes.

En este proceso solo se mapean los datos necesarios para el llenado del catálogo según el modelo de visitas, con las siguientes reglas de negocio:

• Para los valores de entrada se utiliza el siguiente QUERY:

SELECT A.ID_PARTY AS ID_CLIENTE, A.ACCNT_NAME AS DESC_CLIENTE, A.ID_TYPE AS ID_TIPO_CLIENTE,

CASE WHEN A.ID_TYPE = 2

(45)

CASE WHEN C.PERFIL IS NULL THEN 9999 OTRO C.PERFIL END AS ID_CATEGORIA,

CASE WHEN C.CLASE IS NULL THEN 'SIN CLASIFICAR' ELSE C.CLASE END AS DESC_CATEGORIA,

CASE WHEN C.ID_AUDIT IS NULL THEN 2 ELSE C.ID_AUDIT END AS ID_AUDIT, CASE WHEN C.DESC_AUDIT IS NULL THEN 'SATA' ELSE C.DESC_AUDIT END AS DESC_AUDIT,

CASE WHEN A.STATUS_FLAG IS NULL THEN 9999 ELSE A.STATUS_FLAG END AS ID_STATUS,

CASE WHEN A.STATUS_FLAG IS NULL THEN 'SIN CLASIFICAR' ELSE D.VALUE END AS DESC_STATUS

FROM (SELECT A.ID_PARTY, A.ACCNT_NAME, B.ID_TYPE, B.STATUS_FLAG FROM INSTITUTION A INNER JOIN PARTY_TYPE B ON A.ID_PARTY = B.ID_PARTY WHERE A.STATUS_FLAG <> 217 -- "ELIMINADO" AND B.ID_TYPE IN (SELECT ID_PRIVILEGE FROM PRIVILEGE WHERE GENERIC002 = 'INSTITUTION') -- INSTITUCIONES) A

INNER JOIN PRIVILEGE B ON A.ID_TYPE = B.ID_PRIVILEGE LEFT OUTER JOIN

(SELECT A.ID_PARTY, C.CLASE, C.CATEGORIA, C.PERFIL, CASE WHEN C.CATEGORIA = 1 THEN 1 OTRO 2 END AS ID_AUDIT,

CASE WHEN C.CATEGORIA = 1 THEN 'AUDIT' ELSE 'SATA' END AS DESC_AUDIT, C.PRIVILEGE_NAME AS DESC_CATEGORIA FROM INSTITUTION A

INNER JOIN PARTY_TYPE B ON A.ID_PARTY = B.ID_PARTY

LEFT OUTER JOIN (SELECT A.CODIGO_MEDICO, A.CATEGORIA, A.CLASE, A.PERFIL, B. PRIVILEGE_NAME FROM MEDICOS_AUDIT A LEFT OUTER JOIN PRIVILEGE B ON A.PERFIL = B.ID_PRIVILEGE) C ON A.ID_PARTY = C.CODIGO_MEDICO --14093 WHERE A.STATUS_FLAG <> 217 -- "ELIMINADO" AND B.ID_TYPE IN (SELECT ID_PRIVILEGE FROM PRIVILEGE WHERE GENERIC002 = 'INSTITUTION') AND C.CATEGORIA = 1) C ON A.ID_PARTY = C.ID_PARTY LEFT OUTER JOIN CAT_DET D ON A.STATUS_FLAG = D.ID_CAT_DET

UNION

SELECT A.ID_PARTY AS ID_CLIENTE, A.ACCNT_NAME AS DESC_CLIENTE, A.ID_TYPE AS ID_TIPO_CLIENTE,

CASE WHEN A.ID_TYPE = 2 THEN B.PRIVILEGE_NAME ELSE B.GENERIC002 END AS DESC_TIPO_CLIENTE, CASE WHEN C.PERFIL IS NULL THEN 9999 ELSE C.PERFIL END AS ID_CATEGORIA, CASE WHEN C.DESC_CATEGORIA IS NULL THEN 'SIN CLASIFICAR' ELSE C.DESC_CATEGORIA END AS DESC_CATEGORIA, CASE WHEN C.ID_AUDIT IS NULL THEN 2 ELSE C.ID_AUDIT END AS ID_AUDIT,

(46)

CASE WHEN C.DESC_AUDIT IS NULL THEN 'SATA' ELSE C.DESC_AUDIT END AS DESC_AUDIT, CASE WHEN A.STATUS_FLAG IS NULL THEN 9999 ELSE A.STATUS_FLAG END AS ID_STATUS, CASE WHEN A.STATUS_FLAG IS NULL THEN 'SIN CLASIFICAR' ELSE D.VALUE END AS DESC_STATUS FROM ( SELECT A.ID_PARTY, (A.NAME || ' ' || A.LAST_NAME || ' ' || A.MAIDEN_NAME) AS ACCNT_NAME, B.ID_TYPE, B.STATUS_FLAG FROM PERSON A INNER JOIN PARTY_TYPE B ON A.ID_PARTY = B.ID_PARTY WHERE A.STATUS_FLAG <> 217 - - "ELIMINADO" AND B.ID_TYPE IN (SELECT ID_PRIVILEGE FROM PRIVILEGE WHERE PRIVILEGE_NAME = 'MEDICO') -- MEDICOS ) A INNER JOIN PRIVILEGE B ON A.ID_TYPE = B.ID_PRIVILEGE LEFT OUTER JOIN (SELECT A.ID_PARTY, C.CLASE, C.CATEGORIA, C.PERFIL, CASE WHEN C.CATEGORIA = 1 THEN 1 ELSE 2 END AS ID_AUDIT, CASE WHEN C.CATEGORIA = 1 THEN 'AUDIT' ELSE 'SATA' END AS DESC_AUDIT, C.PRIVILEGE_NAME AS DESC_CATEGORIA FROM PERSON A INNER JOIN PARTY_TYPE B ON A.ID_PARTY = B.ID_PARTY LEFT OUTER JOIN (SELECT A.CODIGO_MEDICO, A.CATEGORIA, A.CLASE, A.PERFIL, B. PRIVILEGE_NAME FROM MEDICOS_AUDIT A LEFT OUTER JOIN PRIVILEGE B ON A.PERFIL = B.ID_PRIVILEGE) C ON A.ID_PARTY = C.CODIGO_MEDICO --14093 WHERE A.STATUS_FLAG <> 217 -- "ELIMINADO" AND B.ID_TYPE IN (SELECT ID_PRIVILEGE FROM PRIVILEGE WHERE PRIVILEGE_NAME = 'MEDICO') AND C.CATEGORIA = 1 ) C ON A.ID_PARTY = C.ID_PARTY LEFT OUTER JOIN CAT_DET D ON A.STATUS_FLAG = D.ID_CAT_DET.

(Se utilizo este QUERY a solicitud del cliente, INFA).

• Para la inserción de los valores se utiliza el siguiente QUERY:

INSERT INTO "MODELOS_COMERCIALES"."DBO".LT_CLIENTES (ID_CATEGORIA, DESC_CATEGORIA, ID_TIPO_CLIENTE, DESC_TIPO_CLIENTE, ID_CLIENTE, DESC_CLIENTE, ID_STATUS, DESC_STATUS, ID_AUDIT, DESC_AUDIT, PREESCRIBE_SIBUTRAMINA, PREESCRIBE_CONTROLADOS, MANEJA_IGUALAS, ID_PRECIO_CONSULTA, RANGO_PRECIO_CONSULTA, ID_NUM_PAC_SEM,

RANGO_NUM_PAC_SEM, ID_NUM_PAC_SEM_OBESIDAD,

RANGO_NUM_PAC_SEM_OBESIDAD) VALUES

(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?).

Con las reglas de negocio anteriormente descritas, se tiene el siguiente proceso:

(47)

Proceso de carga del catálogo de Clientes.

• Médicos.

Este proceso de carga busca la información en los catálogos de SATA, para complementarlo con los representantes, para poder ligar los médicos con los representantes que los visitan, además de agregar los campos necesarios del modelo de visitas para este catalogo.

Para obtener la información se detallan las reglas de negocio:

• La obtención de la información de la tabla PARTY_TYPE se obtiene con el siguiente QUERY definido por el cliente:

SELECT PT.ID_PARTY, PT.STATUS_FLAG , CD7.VALUE AS STATUS_MEDICO, PT.GENERIC001, CD1.VALUE AS ESPECIALIDAD, PT.GENERIC002 AS CEDULA,

CD3.VALUE AS ACTIVIDAD_ACADEMICA, CD4.VALUE AS

PREESCRIBE_SIBUTRAMINA, PT.GENERIC005 AS PORCENTAJE_SIBUTRAMINA, CD5.VALUE AS PREESCRIBE_CONTROLADOS, PT.GENERIC007 AS PORCENTAJE_CONTROLADOS, CD6.VALUE AS MANEJA_IGUALAS, PT.GENERIC009 AS PACIENTES_SEMANA_TOTAL, PT.GENERIC010 AS PACIENTES_SEMANA_OBESIDAD, PT.GENERIC011 AS PRECIO_CONSULTA, PT.GENERIC012, CD9.VALUE AS AUDIT_PHARMA

FROM PARTY_TYPE PT LEFT JOIN CAT_DET CD1 ON PT.GENERIC001::TEXT = CD1.ID_CAT_DET::CHARACTER VARYING::TEXT LEFT JOIN CAT_DET CD3 ON PT.GENERIC003::TEXT = CD3.ID_CAT_DET::CHARACTER VARYING::TEXT LEFT JOIN CAT_DET CD4 ON PT.GENERIC004::TEXT = CD4.ID_CAT_DET::CHARACTER VARYING::TEXT LEFT JOIN CAT_DET CD5 ON PT.GENERIC006::TEXT = CD5.ID_CAT_DET::CHARACTER VARYING::TEXT LEFT JOIN CAT_DET CD6 ON PT.GENERIC008::TEXT = CD6.ID_CAT_DET::CHARACTER VARYING::TEXT LEFT

(48)

JOIN CAT_DET CD9 ON PT.GENERIC012::TEXT = CD9.ID_CAT_DET::CHARACTER VARYING::TEXT LEFT JOIN CAT_DET CD7 ON PT.STATUS_FLAG::CHARACTER VARYING::TEXT = CD7.ID_CAT_DET::CHARACTER VARYING::TEXT WHERE PT.STATUS_FLAG <> 217 AND PT.ID_TYPE = 2.

• Los datos obtenidos de PERSON son mediante el siguiente QUERY:

SELECT PP.ID_PARTY, PP.ID_POSTN FROM PARTY_POSTN PP WHERE PP.ID_POSTN::TEXT !~~ '%ELIMINA%'::TEXT AND (PP.ID_POSTN::TEXT IN (

SELECT POSTN.ID_POSTN FROM POSTN JOIN

OBTIENE_JERARQUIA('000000'::CHARACTER VARYING)

OBTIENE_JERARQUIA(ID_ORG, NAME, ID_PARENT, ID_COMPANY, STATUS_FLAG, ID_HISTORY, GENERIC001, GENERIC002, GENERIC003, GENERIC004, GENERIC005, ID_USER_CREATED, ID_USER_MODIF, DATE_CREATED, DATE_MODIF, TIME_MODIF, TIME_CREATED) USING (ID_ORG))).

• Para el join entre PARTY_TYPE y PERSON, se utiliza un stage de transformación en donde la condición es que siempre sea verdadera la búsqueda en ambas tablas.

• La información correspondiente a médicos se obtiene con el siguiente QUERY:

SELECT ID_RUTA, DESC_RUTA, ID_REPRE_CONS, ID_NOMINA_REPRE, DESC_REPRE, ID_CNTO_COSTOS_RUTA, ID_FUERZA_VENTAS, FECHA_INICIO, FECHA_FIN FROM "MODELOS_COMERCIALES"."DBO".LT_REPRESENTANTES.

• La información de PARTY_POSTN se obtiene mediante el siguiente QUERY definido por el cliente:

SELECT PP.ID_PARTY, PP.ID_POSTN FROM PARTY_POSTN PP WHERE PP.ID_POSTN::TEXT !~~ '%ELIMINA%'::TEXT AND (PP.ID_POSTN::TEXT IN (

SELECT POSTN.ID_POSTN FROM POSTN JOIN

OBTIENE_JERARQUIA('000000'::CHARACTER VARYING)

OBTIENE_JERARQUIA(ID_ORG, NAME, ID_PARENT, ID_COMPANY, STATUS_FLAG, ID_HISTORY, GENERIC001, GENERIC002, GENERIC003, GENERIC004, GENERIC005, ID_USER_CREATED, ID_USER_MODIF, DATE_CREATED, DATE_MODIF, TIME_MODIF, TIME_CREATED) USING (ID_ORG))).