universidad nacional de ingenieríacybertesis.uni.edu.pe/bitstream/uni/7859/1/muñoz_my.pdf ·...

Universidad Nacional de Ingeniería FACULTAD DE lNGENIERíA INDUSTRIAL Y DE SISTEMAS

Metodología y Desarrollo de un Prototipo de un

Sistema Financiero para una Compañía de

Seguros (basado en un software existente)

INFORME DE INGENIERIA

Para optar el Título Profesional de

INGENIERO DE SISTEMAS

YURI BERNARDO MUNOZ MARTINEZ

Lima - Perú

1999

Dedicatoria

A mis papas y a la vida, que me han dado más de lo que merezco.

Indice

Introducción ................................................................................................................................................. 03

Capítulo 1: Objetivo .................................................................................................................................... 05

Capítulo 11: Ambito de Desarrollo - Restricciones .................................................... ................................ 06

Primera Restricción Segunda Restricción Tercera Restricción Cuarta Restricción Quinta Restricción

: Elaborar el prototipo en un "Tiempo Fijo" y a un "Costo Fijo" : Elaborar el prototipo basándose en un "Sistema Existente" : El Usuario no tiene tiempo, pero, reclama participar en el prototipo : El Usuario del Area Finanzas esta descontento : No habían experiencias previas en desarrollo de prototipos

Capítulo 111: La Metodología paso a paso .............................................................................................. 10

Entregables del Prototipo (Productos Finales)

Capítulo IV: Detalles de los Pasos a seguir . . . . ... . . .. .. . . . . . . . . . . . . . . . . . .. ... . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . .. ... . . . . . . . . . . . .. . . .. . . .. 15

1. Preparar el "Contrato Marco" para la implementación del Prototipo2. Solicitar "Informe de Expectativas" al Area Usuaria3. Presentación de los Módulos de Finanzas de PPS a los Consultores4. Preparar Documentos para controlar la ejecución del Proyecto5. Preparar formatos para recoger las apreciaciones de los usuarios respecto del módulo a implementarse6. Presentación del "Software de la Consultora" a los Usuarios7. Completar "Documentos de Apreciación" por parte de los Usuarios8. Preparar Inventario de Módulos y Funciones de los módulos de PPS9. Preparar Inventario de Módulos y Funciones de los módulos del "Software de la Consultora"10. Identificar módulos a prototipear11. Formalizar los equipos de Trabajo12. Discusión de los "Documentos de Apreciación"13. Reunión final del Prototipo

Capítulo IV: Productos Finales del Prototipo . . . . . .. .. . . ... . . .. . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . .. . . . . . . . . ... .. . . . . . . . . .. . . . . . . . . . . . . . . . 34

1. Diagrama del "Nuevo Sistema Financiero" de PPS2. Diagrama Entidad - Relación3. Definición de Procesos Complicados4. Documentos de Especificación5. Pantallas Modificadas del Nuevo Sistema6. Definir Etapas para la implementación del Nuevo Sistema7. Presentación de los Costos de Implementación del "Nuevo Software"

Capitulo V: Conclusiones . . .. . ... . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . . . . . . . . . . . .. . .. .. . . . . . . .. . . . .. . . . .. . . 43

Descriptores Temáticos

Contrato a "Costo Fijo"

Contrato a "Tiempo Fijo"

Control de Avance Semanal

Cronograma en Bloques

Cronograma General

Definición de Etapas

Documentos de Especificaciones

Documentos de Expectativas

Grupos de Trabajo

Informe de Expectativas

Integrantes de Equipo

Interfases

Interfases AS/400 y Redes NT

Inventario de Módulos y Funciones

Liquidación de Pagos

Liquidador/Cajero

Módulo de Acreencias Manuales

Módulo de Agentes

Módulo de Anulaciones de Primas

Módulo de Cobradores

Módulo de Egresos

Módulo de Estados de Cuenta

Módulo de Ingresos

Módulo de Obligaciones Manuales

Módulo de Refinanciaciones de Primas

Módulo de Registro de Compras

Módulo de Registro de Ventas

Módulo de Tesorería

Notas de Abono Bancarias

Programación Orientada a Objetos

Prototipo

Repositorio de Datos

Sistema Existente

Sistema Financiero de Seguros

Software de Consultora

Metodología y Desarrollo de un

Prototipo de un Sistema Financiero

para una Compañía de Seguros

(basado en un sistema existente)

Introducción

En los últimos años las líneas de negocio de seguros se han ido diversificando como

consecuencia de un aumento en la demanda de seguros, especialmente en el rubro de

personas; este crecimiento en la demanda ha originado una competencia entre las

aseguradoras, que ha consistido básicamente en ofrecer productos cada vez más

particulares dirigidos a segmentos de mercados específicos, un ejemplo de esto es la

variedad de seguros de salud para personas naturales que se ofrecen hoy en día.

En vista que el mercado de seguros es compartido por más de una decena de

compañías a nivel nacional, cada una ha tratado de lanzar sus productos antes que la

otra, procedimiento que por lo general ha incidido positivamente en un buen

posicionamiento en el mercado, lo que ha permitido asegurar, en muchos casos, la

rentabilidad del producto en el mediano plazo.

Esta necesidad de ofrecer productos nuevos y modificar los existentes ha generado la

necesidad de adaptaciones y cambios rápidos que han debido ser soportados por las

áreas que ofrecen los productos y por las que apoyan a estas. Este es el caso de

Informática que como proveedora de servicios computacionales de la compañía se

responsabiliza por las modificaciones e implementaciones, que se puedan requerir.

La velocidad con la que el Negocio requería los cambios, hizo que Informática trabajara

rápidamente los cambios e implementaciones de los softwares, descuidando de manera

lógica la "Arquitectura Integral" de sus sistemas, este descuido se fue haciendo evidente

paulatinamente, al hacerse cada vez más costoso el mantenimiento de los sistemas y al

aumentar de manera visible la cantidad de fallas en los sistemas.

2

Durante varios años la Compañía de Seguros y Reaseguros "Pacífico Peruano Suiza" -

PPS, basó su soporte computacional en ambientes AS/400 y Redes, en donde residían

1.os principales módulos informáticos de la compañía como son: el de Emisión de

Primas, el de Siniestros, los Estados de Cuenta de Agentes y los Sistemas

Administrativos, como Cobranzas, Tesorería, Contabilidad, entre otros.

La separación de plataformas hacía necesario el mantenimiento de interfases

manejados por procesos batch. Las interfases más importantes eran las que permitían

trasmitir la información entre el AS/400 y la Red y viceversa y estas eran conocidas

como la "Interfase de Bajada" y la "Interfase de Subida".

La "Interfase de Bajada", que cargaba los archivos textos de formato predefinido con

información de la Emisión del día, recopilada en el AS/400. Esta información se

tramsmitia hacia la red una vez acabada las operaciones diarias.

La "Interfase de Subida", que cargaba los archivos textos de formato predefinido con

información de la Cobranza, recopilada en la red. Esta información tramsmitia hacia el

AS/400, también una vez acabada las operaciones diarias.

Esto significaba que cualquier cliente que suscribiera una póliza el día de hoy recién

podía pagarla el día de mañana, situación que originaba malestar entre los clientes que

deseaban terminar la gestión en un solo día. Al mismo tiempo las Cobranzas realizadas

durante el día solo podían reflejarse en los Estados de Cuenta y en los Sistemas de

Siniestros del AS/400, al día siguiente; situación que generaba tiempos muertos para

las operaciones que se deseaban completar durante el mismo día.

En este ambiente de cosas, era difícil y costoso aplicar mejoras integrales que apunten

a mejorar la capacidad de respuesta y la confiablidad en los procesos, problemas que

ya estaban sindicados como una debilidad evidente de Informática.

3

Introducción

En los últimos años las líneas de negocio de seguros se han ido diversificando como

consecuencia de un aumento en la demanda de seguros, especialmente en el rubro de

personas; este crecimiento en la demanda ha originado una competencia entre las

aseguradoras, que ha consistido básicamente en ofrecer productos cada vez más

particulares dirigidos a segmentos de mercados específicos, un ejemplo de esto es la

variedad de seguros de salud para personas naturales que se ofrecen hoy en día.

En vista que el mercado de seguros es compartido por más de una decena de

compañías a nivel nacional, cada una ha tratado de lanzar sus productos antes que la

otra, procedimiento que por lo general ha incidido positivamente en un buen

posicionamiento en el mercado, lo que ha permitido asegurar, en muchos casos, la

rentabilidad del producto en el mediano plazo.

Esta necesidad de ofrecer productos nuevos y modificar los existentes ha generado la

necesidad de adaptaciones y cambios rápidos que han debido ser soportados por las

áreas que ofrecen los productos y por las que apoyan a estas. Este es el caso de

Informática que como proveedora de servicios computacionales de la compañía se

responsabiliza por las modificaciones e implementaciones, que se puedan requerir.

La velocidad con la que el Negocio requería los cambios, hizo que Informática trabajara

rápidamente los cambios e implementaciones de los softwares, descuidando de manera

lógica la "Arquitectura Integral" de sus sistemas, este descuido se fue haciendo evidente

paulatinamente, al hacerse cada vez más costoso el mantenimiento de los sistemas y al

aumentar de manera visible la cantidad de fallas en los sistemas.

2

Durante varios años la Compañía de Seguros y Reaseguros "Pacífico Peruano Suiza" -

PPS, basó su soporte computacional en ambientes AS/400 y Redes, en donde residían

1.os principales módulos informáticos de la compañía como son: el de Emisión de

Primas, el de Siniestros, los Estados de Cuenta de Agentes y los Sistemas

Administrativos, como Cobranzas, Tesorería, Contabilidad, entre otros.

La separación de plataformas hacía necesario el mantenimiento de interfases

manejados por procesos batch. Las interfases más importantes eran las que permitían

trasmitir la información entre el AS/400 y la Red y viceversa y estas eran conocidas

como la "Interfase de Bajada" y la "Interfase de Subida".

La "Interfase de Bajada", que cargaba los archivos textos de formato predefinido con

información de la Emisión del día, recopilada en el AS/400. Esta información se

tramsmitia hacia la red una vez acabada las operaciones diarias.

La "Interfase de Subida", que cargaba los archivos textos de formato predefinido con

información de la Cobranza, recopilada en la red. Esta información tramsmitia hacia el

AS/400, también una vez acabada las operaciones diarias.

Esto significaba que cualquier cliente que suscribiera una póliza el día de hoy recién

podía pagarla el día de mañana, situación que originaba malestar entre los clientes que

deseaban terminar la gestión en un solo día. Al mismo tiempo las Cobranzas realizadas

durante el día solo podían reflejarse en los Estados de Cuenta y en los Sistemas de

Siniestros del AS/400, al día siguiente; situación que generaba tiempos muertos para

las operaciones que se deseaban completar durante el mismo día.

En este ambiente de cosas, era difícil y costoso aplicar mejoras integrales que apunten

a mejorar la capacidad de respuesta y la confiablidad en los procesos, problemas que

ya estaban sindicados como una debilidad evidente de Informática.

3

Es por este motivo que la Gerencia de Informática, decide buscar y evaluar un "Software

Integral para Seguros" desarrollado por terceros, que entre sus principales

características se cuenten: la flexibilidad, que haya sido implementado utilizando

lenguajes de 4ta generación y que la información sea gestionada por una Base de

Datos potente y sólida.

Al mismo tiempo se buscó que el software a implementarse en PPS este respaldado por

implementaciones exitosas previas, en otras compañías de seguros.

Luego de investigar y evaluar softwares de diferentes proveedores, se decidió comprar

un "Software Configurable de Seguros", llamado Acsel/X que es comercializado por sus

creadores, CONSIS Internacional, empresa de software Venezolana, con 1 O años de

experiencia en el mercado de seguros.

Una vez tomada la decisión de implementar el Acsel/X en PPS, se decidió iniciar los

trabajos, implementando primero, los módulos de emisión, para luego implementar los

módulos de siniestros, y finalizar con la implementación de los módulos administrativos

entre ellos el "Módulo Financiero", que es motivo del presente trabajo.

Debido a la diversidad de procesos que PPS tiene en operación, el software tuvo que

ser modificado de manera que pueda incorporar los procesos y funciones ya

mecanizados y operativos, esto hizo que no se pudiera implementar los módulos del

Acsel/X de manera rápida cosa que sí, había ocurrido en anteriores implementaciones.

Es por este último motivo, que cuando se decidió implementar el "Módulo Financiero del

Acsel/X", la Gerencia de Informática vió conveniente implementar previamente, un

prototipo que permitiera conocer con exactitud la magnitud del cambio al "Sistema

Financiero" original del Acsel/x".

4

Capítulo 1: Objetivo

Presentar paso a paso una metodología práctica para llevar a cabo la implementación

de un prototipo de un "Sistema Administrativo", cuando este debe estar basado en un

software existente.

5

Capítulo 11: Ambito de Desarrollo - Restricciones

Cuando se tomo la decisión de elaborar un prototipo, se plantearon una serie de

restricciones formales y prácticas, restricciones que dieron forma a la metodología que

presento en este trabajo.

Primera Restricción: Elaborar el prototipo en un "Tiempo Fijo" y a un "Costo

Fijo"

Debido a la cantidad de trabajo que gestiona e implementa Informática, no es posible

disponer de mucho tiempo para las labores de "Análisis y Diseño", sin embargo, de las

experiencias en implementaciones anteriores, se hizo evidente la importancia de contar

con anterioridad al inicio del proyecto, con un documento que muestre la magnitud del

trabajo a realizar y de esta manera poder obtener una planificación más precisa.

Por lo tanto se decidió desarrollar el prototipo en un periodo de tiempo fijo, 6 semanas

inicialmente. De la misma manera se pactó un "Precio Fijo" por todo concepto, precio

que ascendía a US 16,000 Dólares Americanos.

Las Gerencias de Finanzas e Informática consideraban que era muy importante conocer

con anticipación al inicio del proyecto, cuanto tiempo demoraría el desarrollo del

prototipo, cuanto iba a costar, cual era el personal que debía participar y finalmente,

cual sería el beneficio de desarrollar un prototipo.

6

Segunda Restricción: Elaborar el prototipo basándose en un "Sistema Existente"

. En vista que ya se había tomado la decisión de .implementar el "Software de la

Consultora", el prototipo debía estar basado en el "Módulo Financiero" del Acsel/X.

Es así que el prototipo no podía partir de cero, y por lo contrario debía basarse en los

módulos existentes en el "Sistema Financiero del Acsel/X".

Tercera Restricción: El Usuario no tiene tiempo, pero, reclama participar en el

prototipo

El Usuario del Area de Finanzas no tiene tiempo disponible para labores extras, que no

sean las ya asignadas, al mismo tiempo la escasez de personal y el alto volumen de

trabajo cotidiano, hace difícil convocar al usuario y lograr la concentración necesaria

para que participe en el desarrollo de un trabajo como el prototipo.

Por lo que se buscó configurar equipos de trabajo pequeños, con gente idónea que

permitiera obtener resultados de una manera rápida. De igual manera era necesario

diseñar un horario ad-hoc, que no perjudique la atención de las obligaciones de las

personas que participarían en el proyecto.

Cuarta Restricción: El Usuario del Area Finanzas esta descontento con el

servicio que le ha brindado Informática últimamente.

Hace 4 años se realizó un esfuerzo especial y sui-generis promovido por el Area de

Finanzas, que consistió básicamente en hacer una lista detallada y sustentada de las

necesidades del Area, como cambios en los procedimientos, en las operaciones y en los

servicios hacia los clientes, buscando hacer más eficiente el flujo de trabajo, para esto

se asumia que podían apoyarse en procedimientos mecanizados.

7

Al liderar el Area de Finanzas este esfuerzo, Informática se vió en la necesidad de

buscar una herramienta para implementar los cambios solicitados, ya que

implementarlos en las plataformas con las que se trabajaba, sería demasiado costoso y

lento.

Con los requerimientos de Finanzas bastante bien detallados, Informática realizó un

"Benchmark" con diferentes softwares que pudieran usarse para satisfacer el

requerimiento de Finanzas.

Luego de un proceso de selección, donde participó un grupo de analistas especialmente

escogidos para este fin, se eligió el "Visual Age con Smalltalk" de IBM. Esta herramienta

según los expertos era el único lenguaje disponible comercialmente que permitía una

"Programación Orientada a Objetos" - (POO), lo que significaba, que, usando

correctamente el software se podía sacar provecho de las características únicas de la

"Programación Orientada a Objetos" como son el polimorfismo, el encapsulamiento y la

herencia, características que sin embargo han sido y son complicadas y difíciles de

asimilar por los analistas, acostumbrados generalmente a usar herramientas mas

comerciales y menos complejas.

Así fue que durante el desarrollo del proyecto, los analistas inicialmente asignados

asumieron otras responsabilidades en la compañía, obligando a Informática a buscar

desarrolladores externos, momento en el cual se hizo evidente la falta de difusión del

software en nuestro medio y la falta de soporte de su casa comercializadora - IBM - al

no poder conseguir analistas preparados para trabajar en VisualAge. Todo esto trajo

como consecuencia un avance cada vez más lento del proyecto y no se tardó en

comenzar a incumplir los cronogramas propuestos inicialmente lo que culminó con el

incumplimiento de los acuerdos con Finanzas.

Este malestar se acrecentó cuando se presentaron problemas con la información que

viajaba a través de las interfaces entre la Cobranza y la Emisión, de las que ya hemos

hablado anteriormente.

8

Esto hizo que finalmente el Usuario de Finanzas tenga una actitud de incredulidad y

desconfianza hacia la Gerencia de Informática, actitud que debía ser superada

mediante la consecución de un prototipo en donde ellos puedan ver plasmados los

requerimientos que venían siendo solicitados de tiempo atrás.

Quinta Restricción: No habían experiencias previas en desarrollo de prototipos

En vista de las restricciones mencionadas no era práctico usar un metodología de

prototipeo existente en el mercado, por que eran complicadas y estaban basadas en

softwares que no se comercializaban localmente, por lo tanto no contaban con soporte y

era imposible obtener capacitación en el uso de las mismas.

Como ejemplo, puedo mencionar las reuniones con Oracle-Perú que confirmaban que

no usaban la metodología de prototipeo en sus desarrollos y por lo tanto no disponían

de un software especializado para hacer prototipos.

Al mismo tiempo la premura por iniciar el proyecto hacia muy difícil escoger una

herramienta de prototipeo, estudiarla y aplicarla con éxito.

Es así que, la única solución posible, era bosquejar una metodología propia, que debía

irse probando con la práctica.

9

Capítulo 111 : La Metodología paso a paso

Luego de que se había definido la realización del prototipo, se diseñó un conjunto de

pasos que debían realizarse secuencialmente y con un objetivo definido, para lograr

desarrollar el prototipo.

A continuación se presenta la lista de 13 pasos que se debe seguir para desarrollar un

prototipo de un "Sistema Administrativo" basándose en un módulo existente.

Paso 1

Objetivo:

Preparar el "Contrato Marco" para la implementación del Prototipo

Definir los costos, los tiempos y los responsables del proyecto

fromalmente.

Entregable: Contrato suscrito entre PPS y la Consultora

Paso2 Solicitar un "Informe de Expectativas" al Usuario

Objetivo: Conocer con precisión las expectativas del Usuario de Finanzas.

Entregable: "Documento de Expectativas" elaborado por el Area de Finanzas

Paso 3 Presentación de los Módulos de Finanzas de PPS a los Consultores

Objetivo: Que los consultores externos conozcan los diferentes módulos de

Finanzas implementados y operativos en PPS.

Entregable:

Paso4

Objetivo:

Entrega ble:

Documentación de los módulos de PPS en operación.

Preparar Documentos para controlar la ejecución del proyecto

Establecer canales formales de comunicación con las Gerencias.

Informe de "Control de Avance Semanal".

10

Paso 5 Preparar formatos para recoger las apreciaciones de los usuarios

respecto del módulo a implementarse

Objetivo: Contar con un formato estándar para la recopilación ordenada de

información proveniente del usuario luego de las presentaciones del

"Software de la Consultora".

Entregable: Formato del "Documento de Apreciación".

Paso 6 Presentación del "Sottware de la Consultora" a los Usuarios

Objetivo: Que los usuarios de Finanzas conozcan de manera general como

funciona el "Software de la Consultora" .

Paso 7 Completar "Documentos de Apreciación" por parte de los usuarios

Objetivo: Conocer la apreciación inicial de los Usuarios respecto al "Software de la

Consultora".

Entregable: "Documentos de Apreciación" debidamente llenados por los usuarios.

Paso 8 Preparar Inventario de Módulos y Funciones de los módulos de PPS

Objetivo: Conocer con exactitud todas las módulos y funciones que PPS tiene

mecanizados y en operación.

Entregable: Inventario de "Módulos y Funciones" implementados y operativos en

PPS.

Paso 9 Preparar Inventario de Módulos y Funciones de los módulos del

"Sottware de la Consultora"

Objetivo: Conocer con exactitud todas los "Módulos y Funciones" que la Consultora

tiene mecanizados y en operación en otras instalaciones.

Entregable: Inventario de Módulos y Funciones del "Software de la Consultora"

11

Paso 1 O Identificar módulos a prototipear

Objetivo: Determinar el alcance del proyecto.

Entregable: Lista de módulos a prototipear.

Paso 11 Formalizar los "Equipos de Trabajo"

Objetivos:

• Formalizar la participación de los usuarios con el VoBo de su

Gerencia.

• Buscar comprometer al usuario con el éxito del proyecto al hacerlo

partícipe del mismo.

Entregable: Lista con los "Integrantes de Equipo" por cada módulo a prototipear.

Paso 12 Discusión de los "Documentos de Apreciación" y elaboración de

"Documentos de Espcificaciones"

Objetivo: Revisar en detalle las características del "Software de la Consultora",

para saber con precisión que partes deben ser modificadas, anuladas o

adicionadas.

Entregables:

• "Documento de Especificación" debidamente completado y pantallas

modificadas

• "Acta de Conformidad" firmada por el "Líder Usuario" y "Líder de

Equipo", ratificando que han sido discutidos todos los temas que se

apuntaron en los "Documentos de Apreciación".

Paso 13 Presentación del Prototipo - Reunión Final

Objetivo: Presentar el trabajo realizado a todos los participantes del proyecto

Entregable: Presentación e Informe Final de la Ejecución del proyecto.

12

Entregables del Prototipo (Productos Finales)

Una vez finalizada la la ejecución de los 13 pasos, arriba mencionados se deben de

obtener los 7 entregables que se mencionan a continuación como prueba de una

consecución exitosa y completa del prototipo.

Producto 1

Entregable

Producto 2

Entrega ble

Producto 3

Entregable

Producto 4

Entrega ble

Diagrama del "Nuevo Sistema Financiero" de PPS

Diagrama de Procesos y Módulos del "Nuevo Sistema Financiero

de PPS".

Diagrama Entidad -Relación

Diagrama Entidad-Relación del "Módulo Financiero modificado del

Acsel/X", que soporte los cambios y adiciones solicitados

recogidos en los "Documentos de Especificaciones".

Definición de Procesos Complicados

Diagrama de Procesos y Ejemplos de los módulos o de los

procesos complicados.

Documentos de Especificación

"Documentos de Especificación" elaborados por Informática,

indicando las soluciones que se han tomado por cada problema

en particular, con la respectiva revisión y VoBo (firma del Líder

Usuario y Líder de Equipo).

13

Producto 5

Entregable

Producto 6

Entrega bles

Pantallas modificadas

"Módulo Financiero del Acsel/x - Modificado", que muestre las

pantallas cambiadas y las adicionadas. ( no es necesario que se

muestra data).

Definición de las etapas para la implementación del "Nuevo

Sistema"

• Documento "Propuesta de Inicio de Trabajos".

• Cronograma en bloques de la implementación de los Módulos

(expresado en Días útiles).

• Propuesta del Funcionamiento de la "I Etapa del Nuevo Sistema

Financiero de PPS" en PowerPoint.

Producto 7 Presentación de los Costos de Implementación del "Nuevo

Software"

Entrega ble Hoja de Costos detallados en Excel mes por mes.

14

Capítulo IV: Detalles de los Pasos a seguir

En este capítulo se dasarrolla los pasos que se siguieron para desarrolllar esta

metodología.

15

1. Preparar el "Contrato Marco" para la

implementación del Prototipo

Objetivo Conocer desde un inicio la duración y costo de la implementación del prototipo.

Entregable [ENT11 Contrato suscrito entre PPS y la Consultora

Con la suscripción de un "Contrato a Tiempo Fijo". se buscó limitar el periodo de tiempo

para la implementación del prototipo y limitar el costo del mismo. Manejar las variables

de tiempo y costo resultó en datos útiles para la Gerencia de Finanzas e Informática por

les permitía saber que, en 8 semanas y a un costo de US 16,000 Dólares, debían contar

con un prototipo terminado.

Realizar el trabajo, bajo un "Contrato a Tiempo Fijo", obligó a las partes (Consultores.

Usuarios e Informática) a concentrarse en el cumplimiento de las labores asignadas en

el tiempo programado, sin soslayar la calidad de los entregables que debían obtenerse

por cada paso o tarea cumplida.

Los datos básicos que se incoporan en el contrato son: Costo del Proyecto, Duración

del Proyecto, Responsables de Ejecución, Penalidades por incumplimiento, Asegurar la

confidencialidad del producto final. En los anexos se muestra el centrara suscrito.

16

2. Solicitar "Informe de Expectativas" al Area

Usuaria

Objetivo: Saber exactamente cuales son las expectativas que el Usuario

espera solucionar con la implementación de un nuevo sistema.

Entregable [ENT2] Hoja Excel con la información requerida.

Como se mencionó en la introducción, existía un descontento del Area de Finanzas

hacia Informática, que se resumía de la siguiente manera: "Informática no había logrado

cubrir las expectativas del Area de Finanzas"

Este concepto "Cubrir las expectativas", siempre se manejo como una idea abstracta

difícil de ponerla en blanco y negro, es por eso que se pensó en un formato Excel en

donde el usuario pudiera describir cuales eran los problemas y/o dificultades a las que

se enfrentaba día a día, al mismo tiempo se le pidió hacer un esfuerzo por identificar lo

que en su opicinión eran "Actividades Innecesarias" y que con el apoyo de Informática

podían ser obviadas.

Ejemplo:

Con referencia a los "Procesos de Cobranzas" el Usuario identificó los siguientes

"Problemas Actuales y/o Dificultades":

1. Lentitud del sistema (mas de tres segundos de demora luego de presionar Enter).

Oportunidad de Mejora: Bajar el tiempo de liquidación a 1 segundo, por lo

menos.

17

2. La "Anulación de Financiamientos" en Cupones y Letras deben esperar al día

siguiente.

Oportunidad de Mejora: Implementar la "Anulación de Financiamientos"

"On-Line".

3. Los "Financiamientos de Cupones y Letras" no pueden ser pagados el mismo día.

Oportunidad de Mejora: Modificar los sistemas de manera que sea posible

financiar y pagar en el mismo día.

4. Falta visualizar más datos en la pantalla del Liquidador/Cajero lo que induce a

errores en el registro de documentos.

Oportunidad de Mejora: Implementar pantallas Ad-Hoc, que permitan al

Liquidador/Cajero trabajar eficientemente y con

seguridad.

5. Los pagos en distintas monedas contra documentos también en distintas monedas,

generan movimientos de cuentas manuales.

Oportunidad de Mejora: Implementar el pago en dos monedas en la misma

"Liquidación de Pagos" sin necesidad de registrar

movimientos de cuentas manualmente.

6. El sistema no permite facturar moras por los pagos provenientes de Bancos ni de

Ventanillas.

Oportunidad de Mejora: Implementar el cálculo de moras en el momento

del pago.

7. No es posible rehacer facturas sin la intervención del Area Técnica respectiva.

Oportunidad de Mejora: Implementar un módulo bajo la gestión de

Cobranzas de manera que el cambio de facturas

se hagan directamente en esta Area.

18

8. No se cuenta con el control de los números de cheques con los que los clientes

pagan a PPS.

Oportunidad de Mejora: Implementar .una lectora magnética de cheques en

Ventanilla.

9. No se cuenta con el control de los números de "Notas de Abono Bancaria" con los

que nos pagan, con lo cual se corre el riesgo de utilizar la misma "Nota de Abono

Bancaria" más de una vez.

Oportunidad de Mejora: Llevar el control de las "Notas de Abono Bancarias"

que se ingresan en ventanilla de manera que se

pueda detectar el uso de una Nota por segunda

vez.

1 O. Faltan cuentas para registrar los cobros de conceptos que están fuera del sistema

central de facturación de la Compañía.

Oportunidad de Mejora: Preparar una estructura de tablas nuevas, que

permitan ingresar desde el Area de Cobranzas

todo movimiento nuevo para efectos de cobranza.

En el anexo [ENT2] se adjunta el "Informe de Expectativas" que el Area de Finanzas,

hizo llegar al responsable de la implementación del prototipo.

19

3. Presentación de los Módulos de Finanzas de

PPS a los Consultores

Objetivo:

Entregable (ENT3]:

Entregable (ENT4]:

Lograr que los consultores conozcan los módulos con las

que trabaja PPS en el Area de Finanzas.

Se entregó a los consultores la documentación de los

siguientes módulos de PPS en operación:

• Módulo de Cobranzas

• Módulo de Tesorería

• Módulo de Anulaciones de Primas

• Módulo de Refinanciación de Primas

Cronograma de las reuniones para la 1 era semana,

indicando:

• Temas

• Duración

• Expositor

• Participantes

Durante 2 días y a tiempo completo se programaron 15 reuniones en donde

personal de Informática fue explicando los diferentes módulos que PPS a los

consultores externos.

En este lapso de tiempo se prepararon exposiciones de los siguientes módulos:

• Módulo de Cobranzas


• Módulo de Anulaciones de Primas

• Módulo de Refinanciación de Primas

20

• Módulo de Cuenta Corriente de Agentes

• Módulo de Estados de Cuenta

• Módulo de Asientos Contables

Para lograr que los consultores conozcan las implementaciones con las que cuenta

el Area de Finanzas se preparó documentación de los siguientes sistemas:

• Sistemas de Cobranzas

• Sistemas de Caja y Tesorería

• Diagrama de Funcionamiento del sistema completo.

Finalmente se realizó una explicación de como interactuan los módulos del Sistema

Financiero entre sí y con otros módulos externos como los módulos de emisión y los

otros módulos administrativos.

21

4. Preparar Documentos para controlar la

. ejecución del Proyecto

Objetivo: Establecer canales de comunicación con las Gerencias de

manera formal y periódica.

Entregable [ENTS]: Actas de "Reuniones No Programadas"

Entregable [ENT6]: "Cronograma General de la Implementación del Prototipo"

Entregable [ENTn: Informe de "Control de Avance Semanal".

En vista que la Gerencia de Finanzas así como la Gerencia de Informática necesitaban

estar informadas de los avances del Proyecto, así como de las dificultades y retrasos

que pudieran presentarse, se vio conveniente establecer documentos de control, que

sirvan como vehículos para canalizar información referente a la ejecución del proyecto

de manera rápida, concisa y oportuna.

Los documentos que se diseñaron fueron los siguientes:

1.1 Acta de "Reuniones No Programadas"

Estas Actas eran completadas cada vez que se sostenían reuniones de trabajo que no

estaban programadas en el "Cronograma General", en estas actas se registraban los

acuerdos y desacuerdos con los que se finalizaban las reuniones.

Los formatos de estas Actas estaban guardadas en un "Repositario de Datos" diseñado

especialmente para "Gestionar la Ejecución de Proyectos" en Informática.

En estas actas de reuniones se consigban la básicamente la siguiente información:

fecha, tema de la reunión, participantes, acuerdos y observaciones

22

1.2 Cronograma General del Proyecto

Se usó una Hoja Excel en donde se visualiza las etapas del proyecto de implementación

del prototipo (Organización, Ejecución e Implantación). Los datos que se consignan son

básicamente:

• Nombre de la Actividad

• Responsible de la actividad

• Fecha de Inicio y Término de la actividad

• % de Avance

• Estatus (OK, Atrasado)

1.3 Informe de Control de Avance

Con la finalidad de mantener informado a la Gerencia de Finanzas e Informática, se

diseño un formato para ser presentado en las "Reuniones de Control Semanales" (todos

los Viernes a las 4:00 p.m.), en donde se presentaba la siguiente información:

• Riesgos que puede enfrentar la ejecución del proyecto

• Problemas que enfrenta el proyecto.

• Temas o Ta reas Pendientes

• Temas o Tareas Avanzadas

• Acuerdos arribados en la "Reunión de Control Semanal"

Cada acción que se realizaba contaba con un responsible de la consecución de los

resultados así también se establecía un plazo para terminar la tarea.

23

5. Preparar formatos para recoger las

apreciaciones de los usuarios respecto del

· módulo a implementarse

Objetivo: Contar con un formato estándar para la recopilación ordenada de

información proveniente del usuario luego de las presentaciones

del "Software de la Consultora".

Entregable [ENT81: Formato del "Documento de Apreciación".

Por cada módulo a prototipear se preparó un formato Word con la finalidad de recoger

ordenadamente la información obtenida en las "Reuniones de Trabajo".

Este formato debía facilitar la recopilación y posterior consolidación de la información

que se obtendría en las "Reuniones de Trabajo" formales con el Area Usuaria.

Los ítems que conforman el "Documento de Apreciación" son:

• Puntos a Favor y en Contra

• Que le falta?

• Cuánto Falta?

• Implementaría tal como esta?

Ejemplo: Módulo de "Facturación y Cobranzas" (Usuario: RORbegozo)

Opción Puntos a Ptos. en

Que le Falta ? Favor Contra

Concepto de Acreencias Inclusión/ Manteni-miento de Acreencias Facturación Automática

Facturación Manual Cobradores

Cuanto lmplem Falta? ent

24

6. Presentación del "Software de la Consultora"

a los Usuarios

Obietivos:

• Que los Usuarios de Finanzas conozcan de manera general como

funciona el "Software de la Consultora".

• Que Informática visualize como trabaja el "Software de la Consultora"

integralmente.

Durante 2 días y a tiempo completo se programaron 12 reuniones, en donde los

consultores fueron explicando el funcionamiento de los diferentes módulos que

componen su "Módulo Financiero".

Durante estas reuniones los consultores explicaron el funcionamiento de los siguientes

módulos:

• Módulo de Facturación y Cobranzas

• Módulo de Ingresos y Caja

• Módulo de Financiación de Primas


• Módulo de Estado de Cuentas de Intermediarios

• Módulo de Cuentas por Pagar y Egresos

25

7. Completar "Documentos de Apreciación" por

parte de los Usuarios

Objetivos:

• Conocer la apreciación inicial de los Usuarios respecto al

"Software de la Consultora", luego de las charlas explicativas

• Conocer a criterio del usuario, "Cuanto Falta?" para poner el

"Software de la Consultora" en operación.

Entregable [ENT8.5): "Documentos de Apreciación" debidamente llenados por los

usuarios.

Luego de finalizada los 2 días de presentaciones del "Software de la Consultora", se les

dio a los usuarios 48 horas para que devuelvan a Informática los "Documentos de

Apreciación" debidamente llenados.

Ejemplo: "Documentos de Apreciación" completado por el usuario ROrbegozo

Opción Puntos a Ptos. en

Que le Falta ? Cuanto lmplem

Favor Contra Falta? ent Permite hacer

Concepto de vínculos con las Visualizar las cuentas de 5% Si

Acreencias cuentas de ma-nera manera completa natural Permite visualizar Falta de Seguridad,

Inclusión/ Manteni- todas las Acreencias cualquier usuario Implementar seguridad 10% Sí

miento de Acreencias en diferentes estados puede visualizar la en una sola pantalla información

Facturación Permite controlar al Aumenta la labor Automática Area de Cobranzas, administrativa al

los documentos que generar un paso Nada 0% No

pueden ser pagados más en el proceso por Clientes de facturación

Facturación Manual Permite descentralizar Falta seguridad y la creación de segmentar cuentas Implementar seguridad y

15% No documentos de cobro según el tipo de restricción de cuentas en PPS. usuario

Cobradores Es un módulo simple Falta "Zonificación" y Implementar "Control de de trabajar "Control de Entregas Entregas y Devoluciones" 35% No

v Devoluciones"

26

8. Preparar Inventario de Módulos y Funciones

de los módulos de PPS

Objetivo: Conocer con exactitud todas las funciones que PPS tiene

mecanizadas y en operación.

Entregable (ENT9 Inventario de "Módulos y Funciones" implementados y operativos

en PPS.

Se realizó un inventario de los módulos implementados y operativos de PPS,

identificando las opciones por cada uno de los módulos.

Ejemplo: Detalle de las Funciones y Opciones del "Módulo de Estados de Cuenta"

con el que opera PPS.

Estados de Cuenta (Clientes) Estado de Cuenta por Cliente (pendientes) Visualización global de documentos Impresión agrupada de documentos

Estados de Cuenta por Agente Documentos vencidos a determinada fecha Documentos emitidos a determinada fecha Documentos vencidos y emitidos a determinada fecha Estado de cuenta sin ninguna restricción

Estado de Cuenta Cronológico Visualización por póliza Impresión por póliza Visualización por línea y código de cliente Impresión por línea y código de cliente Visualización por código de cliente Impresión por código de cliente Visualización por póliza y linea Impresión por póliza y línea

Estado de Cuenta Seguro Individual de Asistencia Médica Visualización e impresión por código de cliente Visualización e impresión por póliza y certificado

Estado de cuenta de cliente por un determinado Estado de cuenta total del cliente

Estado de cuenta según Ejecutivo de Cuenta (*) Documentos vencidos a determinada fecha Documentos emitidos a determinada fecha Documentos vencidos y emitidos a determinada fecha

27

9. Preparar Inventario de Módulos y Funciones

de los módulos del "Software de la Consultora"

Objetivo: Conocer con exactitud todas las funciones que la Consultora tiene

mecanizadas y en operación en otras instalaciones.

Entrega ble [ENT1 O]: Inventario de Módulos y Funciones del "Software de la

Consultora"

Se preparó por cada módulo una lista, de las opciones que se encuentran disponibles

en el "Software de la Consultora".

Ejemplo: Detalle de las Funciones y Opciones del "Módulo de Estados de Cuenta"

del Acsel/X.

Estados de Cuenta Estados de Cuenta de Clientes

Primas Pendientes de Pago Visualización/ Impresión

Primas Históricas Visualización/ Impresión

Estados de Cuenta de Agentes Primas Pendientes de Pago

Visualización/ Impresión Primas Históricas

Visualización/ Impresión Estados de Cuenta de Entidades Endosatarias

Primas Pendientes de Pago Primas Históricas

28

1 O. Identificar módulos a prototipear

Objetivo: Determinar el alcance del proyecto.

Entregable: Lista de Módulos a prototipear

Con el inventario de los módulos obtenidos en los puntos 8 y 9, se procedió a

confeccionar una lista definitiva de los módulos a ser prototipeados, los módulos que se

incorporarían en el prototipo podían clasificarse de la siguiente manera:

• Módulos existentes en el "Software de la Consultora".

• Módulos en operación en PPS y que no existen en el "Software de la Consultora".

• Módulos nuevos, que no existen ni en el "Software de la Consultora" ni en los

módulos en operación en PPS.

Módulos existentes en el "Software de la Consultora":

• Módulo de Acreencias Manuales y de Ingresos

• Módulo de Egresos y Caja


• Módulo de Cuenta Corriente de Agentes

• Módulo de Refinanciaciones

Módulos en operación en PPS y que no existen en el "Software de la Consultora",

• Módulo de Anulaciones

• Módulo de Estados de Cuenta

Módulos nuevos

• Módulo de Retenciones

• Módulo de Control de Pagos de Reaseguros y Coaseguros

29

11. Formalizar los equipos de Trabajo

Objetivos:

Entregable [ENT11):

• Formalizar la participación de los Usuarios (VoBo de su

Gerencia)

• Buscar comprometer al usuario con el éxito del proyecto al

hacerlo partícipe del mismo.

Lista con los "Integrantes de Equipo" po cada módulo a

prototipear.

Para la elaboración de los "Equipos de Trabajo" se buscó formar grupos homogéneos

con ejecutivos con alta capacidad de análisis y que puedan brindar aportes al prototipo

y que al mismo tiempo conozcan el día a día de su trabajo.

Ejemplo: lntragante del Equipo de Trabajo del Módulo de Cuenta Corriente de Agentes

• Adalberto Delgado

• Jose Luis Arribas

• Osear Chavez

• Miguel Piscoya

Apoderado de Tesorería

Pro-Gerente de Finanzas

Ejecutivo de Agentes

Ejecutivo de Cuentas

Líder de Equipo

Integrante

Integrante

Integrante

30

12. Discusión de los "Documentos de

Apreciación"

Objetivo: Profundizar en los requerimientos de modificaciones y adiciones

para luego aprobar su incorporación por consenso en el prototipo.

Entrega ble [ENT12): "Documento de Especificación" y "Acta de Conformidad"

• Descripción y Tipo del "Problema"

• Usuario que reporta el "Problema"

• Confirmación de revisión al 100% en las reuniones

• Solución obtenida por consenso (Usuarios-Consultores-Informática).

• "Acta de Conformidad" firmada por el "Líder Usuario" y "Líder de Equipo"

Se elaboró un "Cronograma de Reuniones", para explicar en detalle las características

de los módulos del "Software de la Consultora" a los "Integrantes de Equipos" de los

"Grupos de Trabajo" conformados previamente. Por cada módulo se hicieron un

promedio de 5 reuniones de 2 horas de duración. Este trabajo demoró 1.5 meses

aproximadamente.

Basándose en el contenido de los "Documentos de Apreciación", se desarrollaron las

siguientes actividades:

• Explicación por parte de los consultores del "Software de la Consultora" de manera

detallada.

31

• Se absolvieron dudas e inquietudes de los usuarios respecto a las diferentes

funciones del software.

• Se tomó nota . de los puntos faltantes y de las debilidades de algunas de las

opciones del software.

• Se modificaron interfaces gráficas para usuario final (pantallas) de manera que

muestre la información que el usuario necesita para trabajar eficientemente.

• Se discutieron futuros cambios en los procedimientos de trabajo actuales como

consecuencia de la implementación de este software.

• Se estudiaron los requerimientos del área usuaria a la luz de las restricciones de

control, contables, tecnológicas, etc. obteniendo requerimientos refinados y

simplificados que podían ser implementados ofreciendo un mejoramiento para el

negocio. Se apoyo al usuario a esquematizar mejor sus requerimientos y reducir los

pedidos innecesarios.

Una vez terminadas las reuniones, Informática se tomó 24 horas para consolidar toda la

información recogida durante las reuniones en un formato diferente llamado

"Documento de Especificaciones", en donde, entre otras cosas se encontraban las

soluciones que se planteaban a los requerimientos planteados en los "Documentos de

Apreciación".

32

13. Reunión final del Prototipo

Objetivo: Dejar constancia al usuario del trabajo realizado.

Entregable [ENT131: Informe Final de la Ejecución del proyecto.

Una vez culminada todas las reuniones programadas y luego de que Informática emitió

los "Documentos de Especificaciones" de cada uno de los módulos a prototipear, se

llevo a cabo una reunión final con el Area de l=inanzas para detallar, todo el trabajo

realizado, compilándolo en un documento.

33

Capítulo IV: Productos Finales del Prototipo

34

1. Diagrama del "Nuevo Sistema Financiero" de

PPS

Con los "Documentos de Especificación" y el "Software de la Consultora" modificado

(interfaces gráficos prototipeados). Se elaboró un Diagrama Completo de Procesos y

Módulos del "Nuevo Sistema Financiero para PPS".

Entregable (ENT14): Diagrama de Procesos y Módulos del "Nuevo Sistema

Financiero de PPS" elaborado en PowerPoint.

35

2. Diagrama Entidad - Relación

Una vez finalizado el "Levantamiento de las Especificaciones", de los diferentes

módulos que componen el prototipo, es posible saber en que puntos hay que modificar

el Diagrama Entidad - Relación original.

Es así que una vez completadas las rondas de reuniones de los consultores con los

usuarios, se procedió a modificar el diagrama original de manera que pueda soportar las

implementaciones solicitadas.

Por otro lado contar con el Diagrama Entidad - Relación antes de la fase de

implementación permite repartir el desarrollo de los módulos entre diferentes analistas,

lo que hace factible avanzar en el "Desarrollo del Sistema" más rápido.

Entrega ble: Diagrama de Entidad - Relación modificado

36

3. Definición de Procesos Complicados

Cuando se inició el prototipo era dificil predecir en que módulos se encontraban las

"Opciones más Complejas", pero durante el desarrollo se hizo evidente que el "Módulo

Refinanciador" y el "Módulo Anulador", eran complejos.

Con la finalidad de evitar sorpresas en la etapa de implementación del nuevo software,

se decidió que era preferible tomarse un poco más de tiempo en tratar de analizar estas

opciones con la finalidad de bosquejar esquemas de solución, (pseudo-algoritmos,

detalle de procesos, ejemplos), y poder cuantificar el esfuerzo que requerían para su

implementación.

Entregable [ENT15]: Diagrama de Procesos y Ejemplos del Módulo

Refinanciador y de Anulaciones

37

4. Documentos de Especificación

Los "Documentos de Especificación" junto con el Diagrama de Entidad - Relación son

los entregables más importantes, por que ambos permiten conocer con detalle el

conjunto de modificaciones que se deben realizar para que el "Software de la

Consultora" se convierta en el "Nuevo Sistema Financiero de PPS".

Para completar los "Documentos de Especificación" se invirtieron la mayor cantidad de

horas - hombre por que era necesario revisar cada opción y cada módulo del "Software

de la Consultora", para especificar los cambios que debían realizarse.

Entregable "Documentos de Especificación" elaborados por Informática, indicando

las soluciones que se han tomado por cada problema en particular, con la

respectiva revisión y VoBo (firma del Líder Usuario y Líder de Equipo).

38

5. Pantallas Modificadas del Nuevo Sistema

Lo que un inicio se pensó que sería el entregable más importante se convirtió en el

transcurso del proyecto en un entregable de relativa importancia, sin embargo elaborar

los cambios en las pantallas permitió a los consultores mostrar a los usuarios, la forma

en la que sus pedidos se materializarían en el nuevo módulo.

Entrega ble "Módulo Financiero del Acsel/x - Modificado", que muestre las pantallas

cambiadas y las adicionadas. ( no es necesario que se muestra data).

39

6. Definir Etapas para la implementación del

Nuevo Sistema

Luego de completar las tareas del prototipo es mucho más simple visualizar la

organización del proyecto para la "Implementación del Nuevo Módulo Financiero".

Entregable (ENT161:

Entregable (ENT171:

Entregable (ENT181:

Documento "Propuesta de Inicio de Trabajos"

"Cronograma de la implementación de los Módulos del

Nuevo Sistema Financiero" (expresado en Días útiles)

Propuesta de funcionamiento de la I Etapa del "Nuevo

Sistema Financiero de PPS" en PowerPoint.

Luego de prototipear los módulos y tener el esquema general de funcionamiento del

"Nuevo Sistema" se propuso el inicio de trabajos, poniendo en operación los siguientes

módulos en un Primera Etapa:

• Módulo de Generación de Acreencias Manuales al 100%

• Módulo de Registro de Ventas al 100%

• Módulo de Ingresos al 50%

• Módulo de Generación de Obligaciones Manuales al 100%

• Módulo de Registro de Compras al 100%

• Módulo de Egresos al 50%

• Módulo de Tesorería al 100%

• Módulo de Pagos Masivos al 50%

• Módulo de Estados de Cuenta al 50%

Para una segunda etapa se consideró poner operativos los siguientes módulos:

• Módulo de Ingresos el 50% restante

• Módulo de Agentes al 100%

• Módulo Financiero al 100%

40

• Módulo de Estados de Cuenta el 50% restante

• Módulo de Pago Masivo el 50% restante

• Módulos Periféricos:

• Cargo Automático

• EDI con bancos

• Access-Cobranzas

• Flujo de Caja

41

7. Presentación de los Costos de

Implementación del "Nuevo Software"

Conociendo el volumen de trabajo que suponían las modificaciones solicitadas por el

usuario y conociendo la disponibilidad de personal de Informática, se procedió a

preparar una "Hoja de Costos Detallados" (mensual), donde se visualize el costo de la

implementación del "Nuevo Sistema Financiero de PPS"

Entrega ble: Hoja de Costos detallados en Excel mes por mes.

42

Capítulo V: Conclusiones

La metodología de prototipeo como alternativa a las "Metodologías de Análisis y Diseño

Orientadas a los Procesos", es una opción aplicable a nuestra realidad por los

siguientes motivos:

1. El prototipeo permite la participación activa del Usuario, acción que aumenta el

compromiso de los mismos con el éxito del proyecto.

2. El prototipeo permite materializar un producto entregable en forma de pantallas.

reportes y documentación de procesos, lo que hace que sea una producto que

puede ser fácilmente entendido por el usuario y el analista. Normalmente con otras

metodologías los entregables son diagramas, difíciles de interpretar para ambas

partes.

3. El prototipeo permite visualizar de manera más rápida las contradicciones a las que

nos lleva las "mejoras mecanizadas deseadas".

4. El prototipeo permite independizar a los responsables de las Etapas de Ejecución de

un proyecto. Un prototipo correctamente elaborado y con la documentación

correspondiente, puede ser entendido fácilmente por un analista que no ha

participado en el proyecto, pudiendo liberarse recursos que han participado en la

elaboración del prototipo, esto nos puede llevar a una especialización en las tareas

lo que permitiría especializar a un analista en la elaboración de prototipos.

43

Recomendaciones

1. La metodología propuesta, como toda metodología, debe ser usada como una

herramienta y no como un fin, la aplicación de una metodología debe siempre

combinarse con la realidad de cada empresa, y según eso debe aplicarse porciones

de la misma o en su defecto, el conjunto completo, si es que eso permite obtener un

"Levantamiento de Información" eficiente.

2. Las "Etapas de Implementación" de un sistema, que es uno de los "Productos Finales"

de esta metodología, debe buscar minimizar el riesgo técnico de una sola gran

implementación ( pruebas integrales demasiado pesadas, por ejemplo), pero al mismo

tiempo debe buscarse que las mencionadas "Etapas" aporten soluciones valiosas para

el negocio.

3. Sea con prototipo o no, hay que buscar que el usuario valide y se comprometa con las

especificaciones levantadas, de tal manera que durante la implementación del

proyecto, se pueda trabajar con las las mencionadas especificafiones, esto hará que la

interacción con el área usuaria se minimice y por consiguiente se obtenga mayor

tiempo para el desarrollo.

4. Un tema básico para realizar un buen prototipo, es el de buscar el tiempo necesario,

tanto del Informático como del usuario, antes de iniciar el proyecto. Por que es muy

fácil encontrarse con problema de tiempos en el transcurso del proyecto, que inciden

de manera directa en la calidad y en el alcance del prototipo.

Indice de Anexos

Entregable 01: [ENT1] Contrato para la Implementación del Prototipo del Nuevo Sistema Financiero de PPS"

Entregable 02: [ENT2] "Informe de Expectativas" para un "Nuevo Sistema Financiero de PPS", elaborado por el Area de Finanzas.

Entregable 03: [ENT3] Documentación de Módulos Implementados y Operativos de PPS

Entregable 04: [ENT4] Cronograma de Reuniones de la 1era Semana de Trabajo

Entregable 05: [ENT5] Actas de "Reuniones No Programadas" - Ejemplos

Entregable 06: [ENT6] Cronograma General del Proyecto de "Desarrollo del Prototipo"

Entregable 07: [ENT7] "Informe de Control de Avance Semanal"

Entregable 08: [ENT8] Formato del "Documento de Apreciación" para los Usuarios - Ejemplo

Entregable 09: (ENT9] Inventario de los "Módulos Implementados y Operativos" en PPS en el Area de Finanzas.

Entregable 10: [ENT10] Inventario de los "Módulos Implementados y Operativos" en el "Software de la Consultora".

Entregable 11: [ENT11] Cuadro con los "Integrantes de Equipos" por cada módulo.

Entregable 12: [ENT12] "Documento de Especifiación" - Ejemplo y "Acta de Confromidad" - Ejemplo.

Entregable 13: [ENT13] "Informe Final de la Ejecución del Proyecto".

Entregable 14: [ENT14] Diagrama de Procesos y Módulos del "Nuevo Sistema Financiero de PPS".

Entregable 15: [ENT15] Diagrama de Procesos y Ejemplos del Módulo Refinanciador y de Anulación.

Entregable 16: [ENT16] Documento "Propuesta de Inicio de Trabajos".

Entregable 17 [ENT17] Cronograma en bloques de la implementación de los Módulos (expresado en Oías útiles).

Entregable 18 [ENT18] Propuesta del Funcionamiento de la I Etapa del Nuevo Sistema Financiero de PPS.

Entregable 19 (ENT19] Hoja de Costos para la "Implementación del Nuevo Sistema Financiero de PPS".

Entregable 1: [ENT1]

Contrato para la "Implementación del Prototipo

del Nuevo Sistema Financiero de PPS"

PROYECTO PARA LA ELABORACION DEL "PROTOTIPO" DEL NUEVO SISTEMA FINANCIERO DEL ACSEL/X

Conste por el presente documento, el CONTRATO DE LICENCIA DE USO Y DE SERVICIOS PROFESIONALES que celebran de una parte CONSULTORIA GERENCIAL Y SISTEMAS CONSIS INTERNACIONAL C.A. empresa no domiciliada en el País y constituida bajo las leyes de laRepública de Venezuela , quien actúa debidamente representada porDirector señor Osear Manuel Carrera Flores, a quien en adelante se ledenominará "El Distribuidor" y de la otra parte, "PACIFICO-PERUANOSUIZA" COMPAÑÍA DE SEGUROS Y REASEGUROS, con RUC 10003539,con domicilio en la Avenida Arequipa 660-Lima, debidamenterepresentada por su Gerente General señor Arturo Rodrigo Santistevan,identificado con Libreta Electoral Nº 07801675, según poder inscrito en laFicha 94380 del Registro de Personas Jurídicas, a quien en adelante se ledenominará "El Cliente", con la intervención de OPENSOFT S.R.L. , conRUC 10856230, con domicilio en la calle Gozzoli Sur 253-San Borja,representada por su Gerente General señor Jesús Gamarra Figueroa,identificado con Libreta Electoral Nº 10608783, según poder inscrito en laFicha 88528 del Registro de Mandatos de Lima, a quien en adelante se ledenominará "El Representante Local", en los términos y condicionessiguientes:

PRIMERO: Objeto del Contrato

El objeto del presente contrato es el de regular el desarrollo del "Prototipo" del Nuevo Sistema Financiero del Acsel/X que en adelante se le denominará "El Prototipo", este desarrollo comprende la prestación de servicios profesionales para realizar los cambios y modificaciones que "El Cliente" considere necesarios y deseables, para construir "El Prototipo".

Estos servicios serán suministrados directamente por "El Distribuidor".

"El Representante Local", se hace responsable para todos los fines del cumplimiento por parte de "El Distribuidor", de este contrato.

El siguiente contrato estará enmarcado por cláusulas adicionales cuyos contenidos principales se mencionan a continuación.

La primera de estas cláusulas será la "Cláusula de inicio de Etapa", en ella se especificarán el Cronograma de trabajo tentativo así como la definición de los equipos de trabajo de los diferentes módulos a prototipear.

La segunda cláusula de etapa, denominada "Cláusula de Informe de Definición", se elaborará como parte de la implementación de "El Prototipo", este documento deberá ser presentado al finalizar la primera semana de trabajo. Este documento contendrá básicamente Fecha de inicio y fin, plazos, cronograma definitivo, equipos de trabajo, listado detallados de los módulos y funciones a prototipear.

La tercera cláusula de etapa se denominará "Cláusula de Término de Proyecto" y será suscrita como constancia de conformidad de "El Prototipo".

SEGUNDO: De la Instalación del Software de "El Prototipo"

Queda convenido entre las partes que "El Distribuidor" se obliga a la entrega, e instalación de "El Prototipo" materia del presente contrato, asimismo la prestación de este servicio dada la particularidad de los trabajos a realizarse, se ejecutará parte en el País y parte en Venezuela, conforme a lo siguiente:

2.1. Efectuar las modificaciones o ampliaciones a "El Prototipo", previa definición en conjunto con "El Cliente".

2.2. Se realizará revisiones periódicas de Avances del Proyecto y de Control de Calidad cada tres semanas en la sede de "El Distribuidor" (Venezuela) o de "El Cliente" (Lima).

2.3. Instalar "El Prototipo" en las 3 computadoras que se indiquen.

2.4. Entregar los programas fuentes de "El Prototipo".

2.5. Entregar las especificaciones escritas de los cálculos, de los procesos internos que por su naturaleza no sean susceptibles de ser prototipeados y además que no puedan deducirse a partir del diseño de las pantallas y de los reportes.

2.6. Brindar la capacitación técnica necesaria a 4 usuarios que se indiquen, para operar correctamente "El Prototipo".

2. 7. "El Cliente" deja en libertad a "El Distribuidor", de elegir el softwarede prototipeo que considere idóneo para implementar este trabajo en los tiempos programados y con la calidad que este precise.

TERCERO: Condiciones de Uso

"El Cliente" se encuentra prohibido de reproducir o facilitar a terceros "El Prototipo", asimismo no puede ofrecer, utilizar o participar en licitaciones en las que se ofrezca dicho producto.

CUARTO: Finalización del Contrato

"El Cliente" podrá finalizar el presente contrato en el momento que lo considere necesario, comunicando por escrito su decisión a "El Distribuidor".

La finalización del Contrato no le otorga ningún derecho a solicitar o a exigir a "El Distribuidor" los reembolsos por las sumas pagadas por concepto de elaboración de "El Prototipo", quedando por el contrario "El Cliente" obligado a cancelar de inmediato los saldos que pueda adeudar a "El Distribuidor" a consecuencia del presente Contrato.

QUINTO: Precio

Como contraprestación por los servicios profesionales para la implantación de "El Prototipo" por parte de "El Distribuidor" (lo cual se realizará con Consultores no residentes en el Perú), las partes acuerdan que:

"El Cliente" pagará el servicio a "El Distribuidor" la cantidad de veintiún mil doscientos catorce dólares americanos (US$ 21,214.00), que se componen de la siguiente manera:

Honorarios Viáticos Pasajes Total

US$ 16,364.00 4,200.00

650.00 US$ 21,214.00

Los mismos que serán pagados de la siguiente manera:

50% a los 30 días de iniciado el proyecto y el 50% restante con la aprobación de la Cláusula final (aceptación de "El Prototipo" por parte del Area de Finanzas). Se presentarán 2 facturas; la lera. incluirá sólo honorarios, la 2da. viáticos y pasajes.

La duración de la elaboración de "El Prototipo" se pacta en 2 meses (60 días calendarios), la fecha de inicio se especificará en la Cláusula de Inicio.

"El Cliente" conviene en cubrir los.costos relativos a:

Se asume como compromiso de "El Cliente" el pago de alojamiento, limpieza, teléfono hasta un máximo de US$ 100.00 dólares americanos (tanto para llamadas locales como internacionales), lavandería, electricidad y otros gastos del departamento.

Los precios de esta propuesta no incluyen ningún tipo de impuestos, los cuales serán calculados al momento de cada facturación y pagados por "El Cliente".

SEXTO: Otros ámbitos de Responsabilidad

"El Distribuidor" no será responsable por el retraso en la adquisición de los equipos ni en las fallas o daños que éstos presenten ocasionados por terceras personas o por accidentes, desastres naturales y en general, a cualquier razón o circunstancia que no estén bajo su control o custodia.

"El Cliente" será responsable por el estricto cumplimiento del cronograma de trabajo (reuniones con los miembros de los equipos de trabajo del Area de Finanzas) para de esta manera conseguir los objetivos previstos en los tiempos planificados.

El prototipeo de los reportes u otros formatos impresos serán realizados por "El Cliente".

SETIMO: Autorizaciones

Las partes acuerdan que "El Cliente" no autorizará ni dará acceso a ningún tercero que no sea empleado autorizado para el uso de "El Pro to tipo".

OCTAVO: Resolución del Contrato y Penalidades

El presente Contrato, así como las cláusulas de implantación podrán resolverse por acuerdo de ambas partes, así como por decisión de "El Cliente", cuando los atrasos superen el 100% del tiempo establecido en el Cronograma.

El cronograma presentado en el Informe de Definición se tomará como base para el cálculo de los atrasos, los cuales se contarán a partir del período de gracia establecido en dicho Informe.

Transcurrido este período de gracia ( una semana para "El Distribuidor" y una semana para "El Cliente"), "El Distribuidor" pagará a "El Cliente" a prorrata cada día de atraso cuando éste se deba a incumplimiento por su parte. De igual manera "El Cliente" pagará a prorrata, cada día de atraso luego de transcurrido el periodo de gracia, siempre y cuando éste ocurriera por responsabilidad de este último. El monto del pago diario se ha calculado en trescientos diez dólares americanos (US$ 310.00), que es el producto de dividir US$ 18,600.00 entre 60 días calendarios.

La determinación de los días de atraso así como la responsabilidad de los mismos estará contenida como un punto de la agenda para la reunión del Comité de Gestión del Proyecto. Este Comité la presidirá el Líder del Proyecto.

Esta reunión será cada 5 días útiles, (cada 7 días calendario) dicha reunión será citada y conducida por el Líder del Proyecto quien distribuirá la agenda en la mañana del día anterior.

NOVENO: Confidencialidad

Las partes acuerdan que toda información y/ o documento que sea de propiedad intelectual de "El Cliente", que por objeto de este Contrato, esté a disposición de "El Distribuidor" deberá ser tratada con el más estricto sentido de discreción, sin que "El Distribuidor" pueda divulgar a persona o institución las informaciones que pudieran en el desarrollo de su laborconocer, todo ello en virtud del secreto profesional y que de no cumplircon lo expuesto, se responsabilizará por los daños y perjuicios en quepudiese haber sufrido "El Cliente".

DÉCIMO : Compromiso de "El Cliente"

Las partes acuerdan que "El Cliente" en el plazo de cinco años, a partir de la firma del presente documento, no utilizará ni empleará los servicios de forma ajena a este Contrato, de ninguna persona que se encuentre laborando bajo relación de dependencia de "El Distribuidor".

DÉCIMO PRIMERA: Domicilio de las Partes

"El Cliente" y "El Distribuidor" fijan como sus domicilios, los señalados en la parte introductoria del presente Contrato.

Firmado en Lima, a los seis días del mes de Mayo de mil novecientos noventinueve.

OPENSOFT S.R.L.

Jesús Gamarra Figueroa Gerente General

"PACIFICO PERUANO SUIZA"

Arturo Rodrigo Santistevan Gerente General

CONSULTORIA GERENCIAL Y SISTEMAS CONSIS INTERNACIONAL C.A.

Osear Manuel Carrera Flores Director


"Informe de Expectativas" para un "Nuevo

Sistema Financiero de PPS", elaborado por el

Area de Finanzas.

Módulos /Procesos Acsell/X en Finanzas 11. Tesorería

MOOUIO

1.Cobranzas

10. Caja

2.Refinanc

1. Cobranzas2. Refinanciaciones3. Estados de Cuenta de clientes

4. Cargo AutomáticoProblemas actuales - Dificultades

l. Lentitud del sistema {mas de tres segunaos ae demora luego de presionarEnter)2. Anulacion de financiaciones de Cupones y Letras deben esperar al diasiguiente3. Las financiaciones de Cuponeras y Letras no pueden ser pagadas el mismo

S. EDI 12. Cuentas por Pagar6. Anulaciones 13. Comisiones7. Siniestros Retenidos 14. Pago Masivo a Proveedores8. Control de Cobradores 15. Ctas Ctes. Coaseguros::::;:::;;::::::;;=;:============

10. Caja 16. Ctas Ctes. ReasegurosAct1v1aaaes innecesarias oportumaaaes ae me1ora

Mayor tiempo en proceso de liquidaciÓ_!!:_ Colas Menos de 1 segundo _

Perder 24 horas�-- On line

día. Perder 24 horas On line 4. Falta visualizar más datos en la pantalla del Liquidadors/Cajero y se induce Mayor tiempo en proceso de liquidación.a errores en el registro de documentos. Errores

Colas. Pantallas Ad Hoc

S. Los pagos con distintas monedas contra documentos tambien en distintasmonedas, generan movimientos de cuentas manuales Mayor tiempo en proceso de liquidación. Colas automatización

-----

6. No permite facturar moras para los pagos provenientes de Bancos ni deVentanillas

8. No es posible re-hacer facturas sin la intervención del Area Técnicarespectiva.

9. No tenemos control de los números de Cheques con los que nos pagan.10. No tenemos control de los números de Notas áe Abono con los que nospagan, teniendo el riesgo de duplicar un ingreso con la misma nota de abono.

perdemos ingresos financieros Demora en atención de solidtudes de cambios en facturación. Doble trabajo Area Técnica + Finanzas Pérdida de Control y mayor trabajo administrativo.

Pérdida de Control y mayor trabajo administrativo.

Mayor tiempo en proceso de liquidación. 13. Manipulación de cuentas contables para registrar los cobros de conceptos y Pérdida de Control y mayor trabajo

Colas

que estan fuera del sistema central de facturación de la Compañía. administrativo.l. Lentitud del sistema {mas de tres segundos de demora luego de presionarEnter) _

2. Demasiado trabajo manual en el registro de los documentos

3. Demasiado trabajo manual en el registro de la forma de pago.4. No permite sub totalizar al ir ingresando formas de pago.

S. No tenemos un sistema de consulta de los cheques con los que nos pagan.S. Reportes de control "pobres". Ejm. Cuadres por liquidador instantáneos,etc.

Mayor tiempo en proceso de liquidación. Colas

facturación on line de Moras

Módulo estrictamente financiero. ---

Lectora magnética del código del cheque.

Control por Nº de operación 13. Dejar estructura preparara para recibirpaulatinamente TODA cuenta por Cobrar / Pagar que se genere por todo concepto en la Compañía.

Menos de 1 segundo _ Código de Barras en nuestros Cupones, Letras y avisos de Cobranza. Código de Barras para reconocer cheques y guardar la información de ellso.

Control posterior al pago

l. Sistema de Financiación RIGIDO que permite solamente re-financiarPrimas en Letr� Letras con Letras y cupones con cupones.

!�1scema r-LLJutsLt que nnanc1e toao tipo ae Mayor tiempo en proceso de liquidación, Control cuenta x cobrar con Cuotas, Letras, Cupones ó

2. Cuando se hace una financiación, se debe esperar al dia siguiente parapoder J!:!.gresar 1� cuota inicial

y mayor trabajo administrativo. un mix de los dos primeros.

Perder 24 horas On line

29/08/99 Página 1 de 4

Módulos /Procesos Acsell/X en Finanzas


4. Cargo AutomáticoMoau10 Problemas actuales - Dificultades

--

3. No pod�mos financiar con cuotas g_ue incluyan facturación parcial.

4. No podemos agrupar varias cuponeras en una sola.S. No podemos calcular el Valor Actual de los documentos antes de sufinanciación.

-

6. Pago de Comisiones ligado a la cancelación de factura.13, E/C l. No es posible emitir estados de cuenta cortados a una determinada tecnaClientes de emisión, vigencia, etc.

2. En los estados de cuenta históricos no se reflejan las notas de credito ydebito ni tampoco los chques devueltos.3. La Información no puede ser agrupada de acuerdo a la necesidad delcliente (por antigüedad, tipo de documento, tipo de riesgo, a favor o encontra)

4. No se pueden ver vencimientos de los cupones Número 1 ni tampoco delas Cuotas Iniciales si es que dicho primer cupón o la misma Cuota inicialestan _pagados.S. No se ven siniestros Retenidos en los Estados de Cuenta.6. No podemos visualizar las entidades Endosatarias ni las primas pendientes

- ó pagadas agrupadas por Entidad Endosataria.7. No tenemos sistemas de búsqueda de codigos de Cliente rápidos, flexiblesy completos.8. No podemos visualizar si las primas son facultativas ni en que proporciónni con que vencimientos de Q¡ª9º al Rease�urador9. Dificultad de lectura e int rpretacion-de anctuales Estados de Cuenta dePrimas pendientes e históricas. Esta dificultad se traslada a las Areas liquidadoras de Siniestros, al Call Center y a toda Area que tiene que acceder a ellos. l. Las renovaciones no necesariamente conservan la forma de pago de la

4.Cargo Auto. vigencia anterior ni tampoco la matrícula de cargo automático.2. Las matrículas se desactivan cuando se dan cambios entre contratantes

(interfase) y/o asegurados, durante la vigencia del seguro.

11. TesoreríaS. EDI 12. Cuentas por Pagar6. Anulaciones 13. Comisiones7. Siniestros Retenidos 14. Pago Masivo a Proveedores8. Control de Cobradores 15. etas Ctes. Coaseguros::::::::::;;:::=::;;::::;===============

10. Caja 16. Ctas Ctes. ReasegurosAa1v1aaaes innecesarias

Perdida de Control y mayor trabajo administrativo. Pérdida de Control y mayor trabajo administrativo.

Pérdida financiera.

Cualquier tartamiento distinto debe ser manejado manualmente por el Area de Comisiones. Perdida de control y mayor trabajo administrativo. - --


-


Pérdida de Control y mayor trabajo administrativo. --

Pérdida de Control y mayor traba� administrativo. --

Mayor tiempo en proceso de liquidación. Colas Pérdida de Control y mayor trabajo administrativo.

Pérdida de Control y posibilidad de atenderv un siniestro a un Cliente Moroso.

oportun1aaaes ae me1ora

> Control-

> Control, facilidad para Cliente

> Control- -

Poder programar en pago de las comisiones en un número de Letra o Cuota determinado, independientemente de la facturación total o parcial de las primas que se financian.

Por medio de una carátula de selección con cierto número de variables que pueden llenarse o no, se escoge el tipo de información

Dicha información se imprime en papel simple, se imprime en una determinada carta tipo, se envía por E-Mail ó por el servidor de Fax, de manera inmediata.

Estados de Cuenta por Entidad Endosataria

Búsquedas de texto "parcial"

Estados de Cuenta flexibles y ampliables.

Estados fáciles de leer que puedan ser adaptados y trasladados a las Areas liquidadoras de Siniestros Modulares + Empresas.

29/08/99 Página 2 de 4



4. Cargo AutomáticoMOOUIO Problemas actuales - Dificultades

3. La informacion a los bancos debería ser enviada por EDI y recibida de lamisma forma.4. El reporte de errores generado por nuestro sistema liquidador/receptor de los pagos de cargo automático debe mostrar el motivo por el cual no se encontró tal o cual curón.S. En algunos casos e proceso deja sin "dar por pagado" los interesesgenerados en una refinanciación de cupones, siendo necesario manipular manualmente la !_iguidación. 6. No existe clave doble en Asistencia Medica para la matricula ( codigo decontratante+ código de aseaurado)7. Los endosos de-inclusión eben matricularse automáticamente,sumándose a la matrícula de la póliza original. 1. t:1 reporte ae errores generaao por nuestro sistema 11qu1aaaor¡receptor aelos pagos de cargo automático debe mostrar el motivo por el cual no se

S. EDI encontró tal o cual cupón.2. En algunos casos e proceso-deja sin "dar por pagaao" los interesesgenerados en una refinanciación de cupones, siendo necesario manipular

(interfase) manualmente la liquidación.

6.AnulSBS l. Endoso de anulación amarrar documentos a anular.--

2. Selección de documentos x fecha fija.-

3. No emite endoso al 100% en cupones4. No permite identificar pólizas endosadas antes de anularlas

7. 5m1estros

Retenidos l. No se ven los siniestros Retenidos en Estados de Cuenta.2. No se puede descargar automáticamente los siniestros Retenidos almomento que Créditos y Cobranzas los aplica a Primas o los libera para su pago total ó parcia. 3. _lll_o hay plataforma interconectada con Tesorería.4. No se ven todos los riesgos (NO A.M.)

H. control

Cobradores l. No permite incluir todo tiRO de documento x cobrar2. No permite imQrimir "hoja de Ruta" ___3. No permite visualizar "otros documentos"4.

1. NO existe un control ae 10s cneque giraaos que son entregaaos a 10sAgentes / Clientes/ Proveedores y por lo tanto no diferenciamos entre el

11.Tesorería saldo líquido vs. El contable de nuestra caja.2. No existe un sistema distribuidor de cheques a Bancos

11. Tesorerías. EDI 12. Cuentas por Pagar6. Anulaciones 13. Comisiones7. Siniestros Retenidos 14. Pago Masivo a Proveedores8. Control de Cobradores 15. Ctas Ctes. Coaseguros======::;:=;==============

10. Caja 16. etas Ctes. ReasegurosAct1v1aaaes innecesarias oportumaaaes ae me1ora

-

Errores con Clientes, malestar Plataforma FLEXIBLE

Pérdida de tiempo para encontrar errores y mayor trabajo administrativo. Plataforma FLEXIBLE

Evitar dejar sin aplicar endosos de anulac,on SBS -- -- -Evitar calcular "días" entre fechas Evitar " saldos" al aplicar endosos. Ebitar anulaciones de Bancos

Descarga automática cuando se libera Pérdidas de tiempo y de control en los siniestros totalmente, se paga parcialmente ó se aplica retenidos en Cobranzas. todo contra primas.

Debe permitir incluir todo tipo de documento x cobrar y distribuirlos por Distrito, cobrador

29/08/99 Página 3 de 4



4. Cargo AutomáticoMOOUIO Problemas actuales - Dificultades

2. No existe un sistema automat1co de 11qu1dacion de compra/ venta de moneda extranjera.

12.ctas xPagar l. Ingreso manual de cuentas x pagar de Gastos Generales.

2. Ingreso manual de saldos de Siniestros x pagar.3. Ingreso maniual de cuentas x pagar de Gastos Generales4

13.

Comisiones l. Rehacerlo de nuevo--

2. Manejo manual de abonos en efectivo3. Reportes de Comisiones generadas vía FAX automático x la noche.(implementado en Lotus Notes)

-

4. Reportes pobres:L't. ra!:jjU

Masivo Proveedores l. Reportes de pagos via FAX automáticos x la noche 15. \.tas. 1. �LLUa1meme en e, programa ae coaseguros no se v1sua11za s1tuac1on aeCtes. primas (pendientes, pagadas ó anuladas)Coaseguros

2. Requerimos consultar consultar Pagos efectuaaos a CoaseguraOores por elsistema de caja. Dicho sistema es incompleto pues no se refleja concepto del

�ª

iº

· . os Pagos por Siniestros que se encuentran coasegurados deben serverificados por el Area. No existe la relacion Nº de Siniestro & Documentos de cobro a Coaseguradores

16 etas. Ctes. l. contabilizacion manual del pago de reaseguro. Se carga en el sistema de Reasegurador eta cte (programa de contabilidad) los reaseguros ya sean por pagos de es primas o cobros de siniestros.

2. Contabilizacion manual de impuestos y gastos bancarios por vouchercontable (para ser ingresados al sistema de Tesorería)

3. No existe interrelación entra los pagos recibidos por Siniestros deReaseguros Vs. Los archivos de Siniestros gropios del Area de Reaseguros.4. Los Pagos por Siniestros que se encuen ran reasegurados deben ser verificados por el Area. No existe la relacion Nº de Siniestro & Documentos de cobro a Reaseguradores.

11. Tesorería

5. EDI 12. Cuentas por Pagar6. Anulaciones 13. Comisiones7. Siniestros Retenidos 14. Pago Masivo a Proveedores

=ª

=·

=C

=o

=n

=t

=ro

=l=d=e

=C

=o

=b

=r

=a

=d

=o

=re

=s

====== 15. etas Ctes. Coaseguros

10. Caja 16. etas Ctes. ReasegurosAct1v1aaaes innecesarias uportumaaaes ae meJora

Contabilización y Operación totalmente manual

---

Ctas x pagar generadas por las Areas respectivas.

Pérdida de control y mayor trabajo . administrativo al encargado de Comisiones Sistema nuevo de Accsell / X

Congestión en Caja solicitando Reportes de pagos del dia anterior. No proveedores en caja ::,e tiene que ingresar a1 menu ae cooranzas y realizar la consulta. Pérdida de tiempo.

Integrar la información en un solo cuadro_. __

Ir al archivo físico de Contabilidad y verificar el Integrar la información en una sola pantalla compronante de�-ª-· __

--

ampliabla.

Integrar la información en una sola pantalla Ir al Area técnica por la informacion ampliabla.

Debe ser ejecutada por las Areas técnicas trabajo manual respectivas.

Debe ser ejecutada por las Areas tecnicas trabajo manual Pérdida de control y mayor trabaJo

respectivas. ---

administrativo al encargado de Finanzas / Reaseguros. Sistema integrado

Integrar la-información en una sola pantalla Ir al Area técnica por la informacion ampliabla.

29/08/99 Página 4 de 4


Documentación de Módulos Implementados y

Operativos de PPS

Sistema de Cobranzas

1. Tipos de Documentos por CobrarA Continuación enumeramos los diferentes tipos de documento que maneja el sistema:

F -> Liquidación de Prima, Cuenta por cobrar originada por algún movimiento de inclusión o creación de alguna Póliza.

E -> Endoso de Devolución, Cuenta por pagar originada por alguna movimiento de devolución efectuado sobre alguna póliza ..

K -> Cupón, Cuenta por cobrar originada por la aceptación de una financiación de prima(s) (con cupones).

L -> Letra, Cuenta por cobrar originada por la aceptación de una re-financacion de primas(s) (con letras).

N -> Nota de Crédito, Cuenta por Pagar originada por la recepción de un pago a cuenta. Este documento debe ser aplicado contra el documento relacionado con la operación que el cliente debió realizar.

H -> Nota de Débito, Cuenta por Cobrar originada por el cobro de algún concepto que generalmente no esta relacionado con el Negocio.

O -> Ajustes, Documentos creados para sustentar movimientos contables. No son susceptibles de ser aplicados. Estos documentos pueden tener cualquier signo.

2. Terminología del Sistema

Liquidación de Cobranza. Es la unidad básica de cualquier transacción de cobranzas, una liquidación de cobranzas contiene una relación de documentos que se dan por pagados y los documentos valor que sustentan el mismo.

Distribución de Pagos. Datos correspondientes a los documentos valor con los que se dará por pagados un grupo de documentos en una Liquidación de Cobranzas.

Operaciones. Se denominan así a los diferentes conceptos con los que se puede dar por pagado algo en una Liquidación de Cobranza. El uso de estas operaciones esta restringido y el administrador del sistema es el encargado de asignar el uso o no de estas por cada usuario.

Tipos de Operación. Son una extensión para los diferentes tipos de operación que existen, cada unos de estos tiene una representación contable que es usada en el momento de elaborar el asiento de la Liquidación de Cobranza. El uso de estos Tipos de Operaciones esta restringido y el administrador del sistema es el encargado de asignar el uso o no de estos por cada usuario.

Liquidador / Cajero. Persona encargada de la atención al publico en el área de caja, es la encargada de elaborar la Liquidación de Cobranza y recibir el dinero o documento que sustentan el pago efectuado.

Ejecutivo de Cuentas. Persona encargada de gestionar los tramites que los clientes quieran realizar con respecto a sus cuentas por cobrar tales como, Anulaciones, Financiaciones, etc. Además también elaboran Liquidaciones de Cobranzas de la cartera de clientes y agentes que tienen asignada. Asimismo desempeñan labores de gestión de cobranza.

Confirmar Liquidación. Es el proceso por el cual el Liquidador/Cajero da por aceptado el dinero o documentos valor correspondientes a una Liquidación de Cobranzas. En este momento se entregan al cliente los Comprobantes de Pago y Constancia correspondientes a la transacción. Los Documentos dados por pagados en una Liquidación de Cobranza solo son reconocidos como pagados una vez ejecutado y terminado este proceso.

Comprobante de Pago. Documento que tributariamente sustenta la operación realizada, aquí se consigna el bien adquirido el valor de este, los impuestos correspodientes y los datos del Cliente. Estos pueden ser Facturas o Boletas de Venta.

Constancia de Pago. Documento que se entrega como constancia del dinero recibido.

Oesconfirmar Liquidación. Proceso para revertir la confirmación de una Liquidación de Cobranza

Liquidación Retenida. Estado por el que puede atravesar una Liquidación de Cobranzas el cual impide que esta sea Confirmada. La retención es causada por el cumplimiento de alguna de las siguientes condiciones: - Aplicación de una Nota de Crédito de otro Cliente.

- Utilización de un Tipo de Cambio fuera de los Rangos establecidos.- Ajuste Contable mayor al Permitido- Pago de un Documento que ha sido AnuladoEstas Liquidaciones solo podrán ser confirmadas previa aprobación del responsable del área.

Refinanciacion. Grupo de Documentos que serán cancelados al pago de una inicial y la aceptación de un grupo de letras.

Aceptación de Cupones. Proceso por el cual se da por pagada una prima cuyos cupones correspondientes se convierten en cuentas por cobrar para reeemplazar a la prima correspondiente.

Aceptación de Letras. Proceso por el cual se da por pagada un grupo de primas cuyas Letras correspondientes se convierten en cuentas por cobrar y reemplazan a estos documentos.

Pre-Emision. Primas cuyo convenio de pago no ha sido aceptado, esto se da cuando se paga la inicial o cuando el cliente firma el documento convenio de pago, en ese momento cambia la fecha de emisión de la prima.

Contabilizacion de Liquidación. Proceso por el cual se contabiliza el pago de los documentos en una liquidación y se registra contablemente el dinero ingresado por esta operación.

Tipo de Cambio Interno. Tipo cambio fijado por la entidad reguladora de las operaciones de seguros (SBS).

Tipo de Cambio de Ventanilla. Tipo de cambio del mercado, es utilizado para calcular las equivalencias en el momento de aceptar pagos

3. Descripción del Sistema.

3.1 Funciones Principales.

Trabajar con Liquidaciones de Cobranza.

-; • ... \h:.ilir..t .. �s--ons r:.u� llf.llJ Esta opción permite al Liquidador crear una Nueva Liquidación de Cobranza o trabajar con una existente.

Se podrá ubicar los documentos por pagar de la siguiente forma: Por Numero de Documento, Por Póliza y Línea, Por Código de Cliente y Moneda,

, Por Numero de Refinanciacion y Por Código de Asegurado.

Se puede visualizar la información del documento mediante este panel de ayuda, las operaciones que se pueden realizar sobre un documento son:

Dar por Pagado Amortizar el Documento Anular la Operación Castigar el Documento (Solo para

Cupones y Letras)

.:,S.l.,.1.o,:,6,,;,,,,..l,;lt0-J$. L-.:Jtl'J!A 1'!11::ll:l

r..:,·.:•.Ja:�,.:,; í·:,L.:.:: m.tmil F:,e! �11::11< ;,1,.: ,.:,n ri.51:=:.1•..1¡�,:t-. r,.,::c 1::.,r:-:::

[C". ;.'1:c..r;�·.¿.

1

LIQUIO: 414954 414955

e,.. faét/L.1!\. �!.i:1:1 o�.:c:Ecr.to Hn, it.:.JUl!I r.., ..

.... ,J(.J 1_:; 1� \·t:tl· •: :1 ':C:J-:,C ::::m ·CtJ.-;1:·: ::rn.:n

F-0615312 INC-0009110 END-026242 H3.93 F-0617949 DES-0001420 END-D05638 139. 61 F-0651187 ACC-00047?3 END-008565 215. 16 F-06S2601 INC-0009796 END-029156 ?12.ll

F-Oó5302� II/C-0009110 END-029281 156. 43 F-Oó5316j VEH-0037651 l, 461. 69 F-0654261 VEH-0036015 l. 407 .39 F-0651000 VEH-0030866 ENl'-060930 1 b00.99 F-0663411 INC-00C9110 END-030240 1 20,.11 F-Oó67090 INC-0009110 END-026920 1 673 .21 N-1032604 'ND-0000000 l, 000 .00 p

� ... .,·.,:i-1 f,¡_,·,r� -- 1� ?.!!;:-,..:. ·�.·�J: -.. �I

Confirmación de Liquidaciones de Cobranza.

Una vez terminado de incluir todos los documentos en la Liquidación de Cobranza se procederá a elaborar la Distribución de Pagos.

Se seleccionaran las Operaciones y Tipos de Operación correspondientes a la transacción que se vaya a realizar. Así mismo el sistema va indicando cual es el saldo actual de la Liquidación.

Una vez que la distribución de cobranza ha sido terminada y la Liquidación de Cobranza ha cuadrado se procederá a Confirmar esta. Proceso que dar por pagados los documentos y emite los Comprobantes de Pago y Constancia de Pago correspondientes a la transacción realizada

Pagos a Cuenta y Regularizaciones.

Listados de Cuadre por Cajero.

Esta Opcion permite crear nuevas Cuentas por Cobrar (Notas de Debito) y Cuentas por Pagar (Notas de Credito). Así mismo se podran hacer regularizaciones contables.

Estos movimientos están asociados necesariamente a un Tipo de Operación, la misma que indica a que cuenta contable va ha afectar el movimiento.

Se consignan además datos tales como: Cliente, Agente, Moneda, Concepto. Para llevar un control adecuado de estas nuevas obligaciones y derechos generados.

En cualquier momento del día se pueden emiten reportes que permiten a los cuadrar su Caja.

Definición y Actualización de Tipos de Operación.

Control de Uso de Tipos de Operación

Desde este Panel se Matriculan y se , da mantenimiento a los diferentes

Tipos de Operación.

Asimismo se asignan los Parámetros de funcionamiento del Tipo de Operación.

El Administrador del Sistema Asigna los Tipos de Operación que puede utilizar cada usuario.

Control de Acceso al Sistema.

. �,,.,......, "°" l,n OOS LlJL•Jh\ _ _ _ Este panel permite seleccionar al

usuario y modulo del aplicativo n el que se desea trabajar.

Luego aparece el Menú con el acceso correspondiente al usuario seleccionado y desde aquí se podrá otorgar o quitar acceso a las diferentes opciones del menú.

3.2 Funciones de Soporte al Usuario.

Distribución de Comprobantes de Pago.

Desconfirmacion de Liquidaciones de Cobranza.

Esta opción permite agrupar / desagrupar los Comprobantes d� Pago que se emitirán.

Esta opción revierte una operación de desconfirmacion de una Liquidación de Cobranza.

Autorizaciones para Liquidaciones Retenidas.

Anulación de Letras.

Modificación Tipo de Cambio Interno.

Esta opción permite autorizar una Liquidación que ha sido retenida, las causas por las cuales una liquidación queda retenida son:

- Aplicación de una Nota deCrédito de otro Cliente.- Utilización de un Tipo deCambio fuera de los Rangosestablecidos.- Ajuste Contable mayor alPermitido- Pago de un Documento que hasido Anulado

Esta opción permite anular las letras asociadas a una Refinanciacion, es utilizada cuando el cliente desea hacer el pago al contado no obstante haber sido refinanciado. Este procedimiento se complementa con la anulación de la Refinanciacion en el AS400

Esta opción permite actualizar el tipo de cambio SBS, el uso de esta opción es restringido al primer día del mes únicamente.

Modificación Tipo de Cambio de Ventanilla.

Cobranza por EDI.

Esta opción permite registrar el tipo de cambio comercial que se utilizara cada dla para las operaciones de Cobranzas.

Este modulo permite procesar la cobranza realizada en ventanilla de Bancos para los diferentes bancos afiliados, se genera automáticamente un liquidación de Cobranza.

Cobranza por Cargo Automático.

Este modulo permite procesar la cobranza realizada por débito automático en cuentas para los diferentes bancos afiliados, se genera automáticamente un liquidación de Cobranza.

Canje de Comprobantes de Pago.

Este panel permite canjear Comprobantes de Pago, esta operación es generalmente usada para entregar facturas a personas que previamente les fue entregada una Boleta.

Modificación de Comprobantes de Pago.

Esta opción permite modificar información del Comprobante de Pago (solo de la cabecera).


Cronograma de Reuniones de la 1 era Semana de

Trabajo

� ..

8:3� 11 9:00 1 9:00 11 9:30 1

9:30 IB ElB BB BB ¡ 11:

30 IEl 1 '. 12:00 IBBEl

BG GI 1

5:00 1 BEJ EJE] EJB BB BB 1 17:30 11 18:00 1

EJE]

I Dia1. - ·- 11 ., __ 11 " __ , 11 Dia2 11 Dia3. Dia4 11 Dia5

Explicación General de los Sistemas Financieros de PPS [RZambrano) (Daal]

Explicación del Módulo de Cobranzas [FI01J x [PBest]

(RZambrano, Daal]

Ver operar Módulo de Cobranzas en el ter Piso

[AYong] [Daal, RZambrano, PBest]

Explicación del Módulo de Tesoreria (FI02J x (ANoriegaJ

(Daal, RZambranoJ

Ver operar Módulo de Tesoreria en el 1er Piso

[MAbad] (Daal. RZambrano, ANoriega)

Explicación del Módulo de Anulaciones (Fl05] x

[MPiscoya] (Oaal, RZambrano)

Ver operar Módulo de Anulaciones (ejemplos) en el 3er Piso (MPiscoyaJ

(Daal. RZj

Explicación del � Refinanclador [FI06) x

[MPlscoya] (Oaal. RZambrano]

Ver operar Módulo de Refinanclado r en el 3er Piso

[MPiscoya] [Daal, RZambranoJ

Explicación del Módulo Cta. Cte. Agentes [FI05] x

[MPlscoya y OChavez] (Oaal, RZambrano]

Ver operar Módulo de Comisión de Agentes en el

1er Piso [ADelgado y MPiscoya] (Oaal, RZambrano]

Visualizar los Estados 5!e Cuenta [FID8) x [MPlscoyaJ (Oaal.

AZambranoJ

Explicación de los� Contables [CN04] x

[ANoriega] (Daal. RZambrano]

Explicaci6n del Cierre de Mes (CNOJ) 1 x (ANoriegaJ (Oaal, RZambranoJ

Preearar eresentaclón del Acsel/X Finanzas a Usuarios Finales x [OaalJ y Reeaso de

Funciones no Revisadas

Explicación General del �csel!)! - Flaanzas x [Daal) [MMacará, JLArrlbas, EHeji,

ROrbegozo, MAbad, ADelgado, GMenendez.

CSuarez, CMorote. RZambrano, ANorlega, PBest)

Explicación del Módulo de Facturación l( Cobranzas [AC-FI01] x [Oaal] [EHaji,

JLArrlbas, ROrbegozo, RZambrano, PBestJ. 0

Reunión 1

Explícacl6n del Módulo de Ingresos l( Ca[a [AC-FI03] X

[Daal] [MAbad, EHaji, ROrbegozo, RZambrano,

PBest] - Reunión 1

, -

,. .. -

- ,.-•L.

Explicación del Módulo de Financiación de Primas [AC-

F102] x [Daal] [JLArrlbas, MPiscoya. GMenendez;

RZambrano) - Reunión 1

Explicación del Módulo de Tesoreria [AC-FI04] x [Daal]

!ADelgado, EHají, MAbad, RZambrano, ANoriega] -

Reunión 1

Explicación del Módulo Estado de Cuea¡a de lnle!IIJedlarios

[AC-FI06) x (Oaal) [JLArribas, MP,scoya, ADelgado, OChavez,

RZambrano) - Reunión 1

Expllcaclón del Módulo de Cuentas eor Pagar l(

Egresos del AcseVX [AC-FI05] x [Daal] [MAbad, ADelgado,

EHajl, RZambrano, ANoriega] Reunión 1

Explicación del Módulo d e Facturación l( Cobranzas del AcseVX [AC-FI01J x [Daal] -1 EHajl, JLArribas. ROtbegozo,

RZambrano, PBestJ Reunión 2

Expficadón del M�s!ul2 Eista�2 5!e Cuent.l de Intermediarios [AC-FID6],

(Oaal] (JLAmbas, MP,.coya, AOergado, OChavez. RZambnlno) •

Reunión 2

Explicac16n del Módulo de Financiación de Primas [AC-

FI02] x [Daal] (JLArríbas, MPiscoya, GMenendez) -

Reunión 2

Explicación del Módulo da Ingresos l! CaJa [AC-FI03] x

[Oaal] (MAbad, EHají, ROrbegozo, RZambrano,

PBest) - Reunión 2

Expllcecl6n del Módulo de Cuentas eor Pagar l!

Egresos del AcseVX (AC-FI05] x [Daal] (MAbad, ADelgado,

EHaji, ANoriega) - Reunión 2

'�---S-is_t_ e_m_a _s _F_i_ n_a_n_c_i_er_o_s_d_ e_P_P_s __ ___., .._l ____ s_;s_t_e_m_a_s_A_cs_e _llX_F._,_·n_a_n_z_a_ s _____.

-

Verificación de la Lista de Funciones ii Servicios de

PPS, de AcseVX, y Faltantes -( CONSIS - Informática ]

-

PreDarar Cronoarama Dara la 1era semana del Prototieo ,

confirmar los Equipos de Trabajo, Confirmar las "Reserva de Horas por

Participante" para la 1 era semana, "Definir los

Entregables" -[CONSIS - Informática)

Entregable 5: [ENTS]

Actas de "Reuniones No Programadas" - Ejemplos

Acta de Reunión Acsel/x - Finanzas Etapa

1: Prototipo

1. Información General.Título: #14 - 06 Jul 99 -> Manejo de "Mix" Cuotas con Letras Participantes: . Jase Luis Arribas, Juan Temoche, Pablo Quiroz, Ruben Zambrano, Elias

Daal, Yuri Munoz Fecha: 07/07/99

2. Acuerdos Tomados.

Para los planes de financiamientos denominados "Mix de Cuotas con Letras", Cobranzas solicita el siguiente manejo:

Ejemplo : Monto Financiado: 1,000 US Dólares 4 Cuotas y 6 Letras:

Cuota# 01: 100 Cuota# 02: 100 Cuota # 03: 100

Cuota# 04: 100 Cuota# *05: 100 Cuota # *06: 100 Cuota# *07: 100 Cuota # *08: 100 Cuota # *09: 100 Cuota# *10: 100

Cuota Inicial Letra# 01 Letra# 02 Letra# 03 Letra# 04 Letra# 05 Letra# 06

1. Hasta que no se pague la 4ta Cuota los Estados de Cuenta mostrarán 1 O Cuotas las 6últimascon un asterisco que indica que en realidad son "Letras Futuras" que se muestran como"cuotas".

2. Con el Pago de la 4ta Cuota, se aceptan las 6 letras y el Sistema reemplazará las "Cuotascon asterisco" por Letras, con lo cual las letras mencionadas se harán visibles para el Sistema yporlo tanto para los Estados de Cuentas

3. Las letras serán impresas y firmadas por el cliente cuando se haga la Refinanciación,es decir en el mes 1.

4. En ningun lugar se menciona la 4ta cuota con su valor real (US 700).

Solicitud final de Cobranzas: Jose Luis Arribas pidió a Informática analizar este pedido y verificar su viabilidad.

Respuesta de Informática:

1. La Operatividad solicitada es viable de ser implementada. Pero será necesario realizarprogramación muy particular ("Código Duro"), para mostrar en los Estados de Cuenta y en losReportes, una Cuota con un importe que no es el real así como mostrar documentos que

realmente son letras emitidas como Cuotas con "*".

2. Informática sugiere seguir un procedimiento alternativo en dondela 4ta Cuota se visualize como 700, y que contenga información adicional internaque informe que esta cuota podrá generar 6 letras por 100 US dólares cuando se paguela Cuota Inicial de 100 US Dólares.

3. Se plantea Aceptar e Imprimir las 6 Letras cuando se pague la Cuota Inicial en el 4to pago.Inicialmente Auditoría observo un procedimiento no regular al imprimir y firmar las letras con elpago de la primera cuota.

Nota: El "Código Duro", dificulta el mantenimiento de los programas, haciendo que demoren más tiempo las modificaciones, y sea más dificil de hacer seguimiento a los cambios, lo que redunda en errores de ejecución en el momento que el Usuario usa el programa modificado.

3. Observaciones.

4. Distribución.Enviar a:

Autor:

Fecha de creación:

Michel Macara-chvili, Jose Laguna, Juan Temoche, Pablo Quiroz, Ruben Zambrano, Elias Daal, Yuri Munoz, Luis Fernandez Yuri Munoz 07/07/99

Acta de Reunión Diseño del prototipo del

nuevo sistema de

finanzas de PPS

1. Información General.Título: Participantes: Fecha:

#1 O - 11 Jun 99 -> Manejo de Notas en Acreencias y Obligaciones Manuales Juan Temoche, Ruben Zambrano, Elias Daal, Yuri Munoz 14/06/99


El tema de la reunión fué el siguienteContemplar el manejo de las Notas de Crédito y Débito que deben generarse desde los Módulode Generación de Acreencias y Obligaciones Manuales

Se tomaron los siguiente acuerdos

1. En el "Módulo de Generación de Acreencias Manuales" se adicionará un campo a nivelde datos generales llamado "Documento SUNAT", en el cual se podrá escoger 3 tipos de documentos

• Factura SUNAT• Boleta SUNAT• Nota de CréditoEn los 3 casos se tendra cuidado de guardar la numeración correspondiente.

2. Las Notas de Crédito generadas por el "Módulo de Generación de AcreenciasManuales", se crearán cuando se entregue una Factura-SUNAT, por un monto menor al correspondiente.

Ejemplo: 1. Se entrega Factura-SUNAT por un alquiles por US 1,000.002. El precio real del alquiler es de US 1,100.003. Se entrega una Nota de Crédito por la diferencia US 100.004. Se hace referencia a la Factura-SUNAT

3. Las Notas de Débito generadas por el "Módulo de Generación de ObligacionesManuales", se crearán cuando se entregue una Factura-SUNAT, por un monto mayor al correspondiente.

Ejemplo: 1. Se entrega Factura-SUNAT por un alquiles por US 1,100.002. El precio real del alquiler es de US 1,000.003. Se entrega una Nota de Débito por la diferencia US 100.004. Se hace referencia a la Factura-SUNAT

3. Observaciones.

Hay que contemplar la posibilidad de que todas las usuarios del "Módulo de Generación deAcreencias Manuales" (Fincas, Recuperos, etc), también tengan acceso al "Módulo deGeneración de Obligaciones Manuales", para hacer Notas de Débito.


Autor:

Fecha de

creación:

Juan Temoche, Ruben Zambrano, Elias Daal, Enrique Haji, Mario Abad, Adalberto Delgado, Rosaluz Orbegoso, Yuri Munoz, Michel Macara-chvili, Jose Luis Arribas

Yuri Munoz

14/06/99

Acta de Reunión Acsel/x - Finanzas Etapa

1: Prototipo

1. Información General.Título: Reunión FINAL del PNSF-Acsel/X Participantes: Michel Macara-chvili, Jose Luis Arribas, Enrique Haji, Luis Fernandez, Ruben

Zambrano, Elias Daal, Yuri Munoz Fecha: 26/07/99


1. Se presentó el "Informe Final de la Ejecución del Proyecto del PNSF-Acsel/X" en donde seinformó el cumplimiento del objetivo del Contrato suscrito entre CONSIS y PPS. Asitambién como el cumplimiento de sus cláusulas.

2. Se entregó a Michel Macará la documentación completa del prototipo, que cuenta con elVoBo de los Líderes de Equipo de los diferentes módulos prototipeados y del Líder Usuario(Jose Luis Arribas).

3. Se informó que Elías Daal se ausentará por 3 semanas (hasta el 23 de Agosto), parahacer:• Diagrama Entidad Relación del Módulo de Finanzas.• Cronograma detallado de la implementación de los 9 módulos prototipeados. Este

cornograma estará expresado en Horas-Hombre.

4. En el lapso de 3 semanas hasta el 23 de Agosto, Informática realizará las siguientes tareas:• Preparar una presentación del Módulo Financiero Acsel/x, para el Viernes 6 de Agosto• Preparar un documento inicial referente a la implicancia de la "Carga de Datos".• Preparar un documento inicial referente a los "Módulos Periféricos" que serán parte del

Módulo Financiero.• Preparar un documento de las implicancias de la salida del Módulo Financiero antes de la

salida de Asistencia Médica.

5. Se bosquejó la duración de la implementación del Módulo Financiero entre 8 y 11 meses. (este periodo no incluye la etapa de Implantación, que dura aproximadamente 2 meses).Estos datos son referenciales y se necesita conocer el Cronograma Detallado que prepararáCONSIS.

6. Finanzas se mostró satisfecho con la ejecución del proyecto del PNSF-Acsel/X, yrecomendó la aplicación de la metodología de prototipeo para el levantamiento de informaciónen otras Areas de la Compañía, entre otras cosas por que logra un grado óptimo deinvolucramiento del usuario.

7. Con este documento se da por finalizado para todos sus efectos la ejecución delproyecto del PNSF-Acsel/X.

Se anexa el Informe Final presentado así como el Cronograma cumplido al 100%.

� � Acta de Conformidad del ACSEL-X Finanzas (Ver

3. Observaciones.


Autor:

Fecha de

creación:

Michel Macara-chvili, Jose Luis Arribas, Enrique Haji, Luis Fernandez, Ruben Zambrano, Elias Daal Yuri Munoz

26/07/99


Cronograma General del Proyecto de "Desarrollo

del Prototipo"

PROTOTIPO NUEVO SISTEMA FINANCIERO

Fecha de revisión : 26/07/1999

Actividades Resp Inicio Término Fin Avance A

Actual

ORGANIZACION 17-Mav 2s�Mav Exposición módulos PPS a CONSIS 17-Mav 18-Mav 100% A

Explicación General RZ 17-Mav 17-Mav 100% A Módulo de Cobranzas PB 17-Mav 17-Mav 100% A Módulo de Tesorería RZ 17-Mav 17-Mav 100% A Módulo de Anulaciones MP 17-Mav 17-Ma, 100% A Módulo Refinanciador MP 18-Mav 18-Mav 100% A Módulo Cta. Cte Aaentes OCH 18-Mav 18-Mav 100% A

Exposición módulos CONSIS a Usuario-Finanzas 18-Mav 24-Ma\lPreparar Módulo Base de CONSIS 18-Mav 20-Ma, 100% A

lmport de las Tablas traídas x CONSIS ED 18-Mav 18-Ma, 100% A Creación de los TableSapces ED 19-Mav 19-Ma, 100% A Instalación v Pruebas de "Forms" ED 20-Mav 20-Ma, 100% A

Preparar "Documentos de Apreciación" YM 19-Mav 19-Ma, 100% A Exposición Módulo de Facturación v Cobranzas ED 20-Mav 20-Ma\ 100% A Exposición Módulo de lnaresos v Caia ED 20-Mav 20-Ma, 100% A Exposición Módulo de Cuentas x Paqar Earesos ED 20-Mav 21-Ma\ 100% A Exposición Módulo de Est. Cta Intermediarios ED 21-Mav 21-Ma, 100% A Exposición Módulo de Tesorería ED 24-Mav 24-Ma\ 100% A Exposición Módulo de Financiación de Primas ED 24-Mav 24-Ma\ 100% A

Consolidación Aoortes Usuarios v Seteo de BD definitivas 25-Mav 28-Ma\lConsolidar "Documentos de Apreciación General" YM 25-Mav 28-Ma\ 100% A Consolidar Aportes Usuarios durante las reuniones YM 25-Mav 28-Ma, 100% A Puesta a Punto del Módulo GvT ED 25-Mav 26-Mav 100% A Preparación de Data para el prototipo ED 26-Mav 27-Ma\ 100% A Exposición Mod. Financiador deseado (Finanzas) JLA 27-Mav 27-Mav 100% A Revisión de Procesos de Emisión de Conv.Paao RZ 27-Mav 27-Mav 100% A

Preparar "Claúsula de Inicio" RZ 25-May 25-May 100% A EJECUCIONI 28-May 14-Jul

Módulo de Generación de Acreencias YM 28-Mav 3-Jun 100% A Orqanización YM 28-Mav 28-Mav 100% A Reunión de Levantamiento# 1 EDT 31-Mav 31-Mav 100% A Reunión de Levantamiento # 2 EDT 1-Jun 1-Jun 100% A Preparación de Dcto. Del Prototipo YM 28-Mav 1-Jun 100% A Reunión de Validación del Prot. De "Generación de Acre e'M 1-Jun 1-Jun 100% A Entrega de Doc. Del Prototipo Validado por FINANZAS EH 3-Jun 3-Jun 100% A

Módulo de lnqresos v Caia 2-Jun 9-JunOraanización YM 2-Jun 2-Jun 100% A Reunión de Levantamiento# 1 EDT 3-Jun 3-Jun 100% A Reunión de Levantamiento # 2 EDT 4-Jun 4-Jun 100% A Reunión de Levantamiento # 3 EDT 5-Jun 5-Jun 100% A Reunión de Levantamiento# 4 EDT 7-Jun 7-Jun 100% A Preparación de Dcto. Del Prototipo YM 2-Jun 7-Jun 100% A Reunión de Validación del Prot. De "lnaresos v Caia" YM 7-Jun 7-Jun 100% A Entreqa de Doc. Del Prototipo Validado por FINANZAS MA 9-Jun 9-Jun 100% A

Módulo de Eoresos v Caia 8-Jun 15-JunOrqanización YM 8-Jun 8-Jun 100% A Reunión de Levantamiento # 1 EDT 9-Jun 9-Jun 100% A Reunión de Levantamiento# 2 EDT 10-Jun 10-Jun 100% A Reunión de Levantamiento # 3 EDT 11-Jun 11-Jun 100% A Reunión de Levantamiento# 4 EDT 11-Jun 11-Jun 100% A Reunión de Levantamiento# 5 EDT 12-Jun 12-Jun 100% A Preparación de Dcto. Del Prototipo YM 8-Jun 12-Jun 100% A Reunión de Validación del Prot. De "Earesos v Caia" YM 15-Jun 15-Jun 100% A Entreqa de Doc. Del Prototipo Validado por FINANZAS MA 17-Jun 17-Jun 100% A

Módulo de Tesorería 14-Jun 18-JunOrqanización ED, YM 14-Jun 14-Jun 100% A Reunión de Levantamiento # 1 ED, JLA, EH, 15-Jun 15-Jun 100% A Reunión de Levantamiento # 2 ED, JLA, EH, 16-Jun 16-Jun 100% A Preparación de Delo. Del Prototipo YM 14-Jun 16-Jun 100% A Validación del Prot. De "Tesorería" ED, JLA, EH, 16-Jun 16-Jun 100% A Entreqa de Doc. Del Prototipo Validado por FINANZAS AD 18-Jun 18-Jun 100% A

Módulo de Retención de Paqos 21-Jun 25-JunOrqanización ED, YM 21-Jun 21-Jun 100% A Reunión de Levantamiento# 1 ED, JLA, YM, 21-Jun 21-Jun 100% A Reunión de Levantamiento# 2 ED, JLA, YM, 22-Jun 22-Jun 100% A

Preparación de Dcto. Del Prototipo Validación del Prot. De los "Retención de Paqos" Entreqa de Doc. Del Prototipo Validado Por FINANZAS

Estados de Cuenta de Intermediarios Orqanización Reunión de Levantamiento # 1 Reunión de Levantamiento # 2 Preparación de Dcto. Del Prototipo Validación del Prot. De "Ctas. De Intermediarios" Entreqa de Doc. Del Prototipo Validado POr FINANZAS

Módulo Financiero Orqanización Reunión de Levantamiento # 1 Reunión de Levantamiento# 2 Reunión de Levantamiento # 3 Reunión de Levantamiento # 4 Reunión de Levantamiento # 5 Reunión de Levantamiento # 6 Reunión de Levantamiento# 7 Reunión de Levantamiento # 8 Reunión de Levantamiento# 9 Preparación de Dcto. Del Prototipo Validación del Prot. De "Módulo Financiero" EntreQa de Doc. Del Prototipo Validado por FINANZAS

Módulo de Anulaciones Organización Reunión de Levantamiento # 1 Reunión de Levantamiento# 2 Preparación de Dcto. Del Prototipo Validación del Prot. De los "Anulaciones" Entreqa de Doc. Del Prototipo Validado Por FINANZAS

Módulo de Estado de Cuenta Orqanización Reunión de Levantamiento# 1 Reunión de Levantamiento # 2 Reunión de Levantamiento# 3 Reunión de Levantamiento # 4 Preparación de Dcto. Del Prototipo Validación del Prot. De los "Estados de Cuenta" Entreqa de Doc. Del Prototipo Validado Por FINANZAS

Módulo de Cobradores Reunión de Levantamiento # 1 Preparación de Dcto. Del Prototioo Validación del Prot. De los "Cobradores" Entreqa de Doc. Del Prototipo Validado por FINANZAS

IMPLANTACION

Comentarios Siglas de Responsables

RZ = Rubén Zambrano

PB = Pablo Best

MP = Miguel Piscoya

OCH = Osear Chávez

YM = Yuri Muñoz

JLA = Jose Luis Arribas

RO = Rosa Luz Orbegozo

MM = Michell Macará

Notas

YM

ED, JLA, YM,

ED, YM ED, JLA, AD, ED, JLA, AD, YM

ED, JLA, AD, AD

ED, YM ED, MP, GM, ED, MP, GM, ED, MP, GM, ED, MP, GM, ED, MP, GM, ED, MP, GM, ED, MP, GM, ED, MP, GM, ED, MP, GM, YM

ED, MP, GM,

ED,YM ED, JLA, MP, ED, JLA, MP, YM ED, JLA, MP,

ED, YM ED, JLA, MP, ED, JLA, MP, ED, JLA, MP, ED, JLA, MP, YM

ED, JLA, MP,

CM

ED, JLA, YM, YM ED, JLA, YM, JLA

EH = Enrique Haji

MA = Mario Abad

21-Jun22-Jun25-Jun 23-Jun 23-Jun24-Jun25-Jun23-Jun25-Jun30-Jun26-Jun26-Jun28-Jun30-Jun

1-Jul2-Jul5-Jul6-Jul7-Jul8-Jul9-Jul

26-Jun9-Jul

13-Jul12-Jul12-Jul12-Jul13-Jul13-Jul14-Jul16-Jul15.Jul15-Jul16-Jul19-Jul20-Jul21-Jul15-Jul21-Jul23-Jul22.Jul22-Jul23-Jul23-Jul23-Jul26.Jul

AD = Alberto Delgado

ED = Elias Daal

GM =

CM = Claudia Morote

es =

RV = Ricardo Vasquez

Un solo responsable por actividad. El puede delegar o apoyarse en otros. Es el Es opcional usar las columnas de meses y semanas para graficar a modo de Gantt,

¾A V Porcentaje de avance de una actividad ABC Indica Actualizaciones : A alta, B baia, C cambio

22-Jun 100% A 22-Jun 100% A 25-Jun 100% A 30-Jun23-Jun 100% A 24-Jun 100% A 25-Jun 100% A 25-Jun 100% A 25-Jun 100% A 30-Jun 100% A 13.Jul

26-Jun 100% A 28-Jun 100% A 30-Jun 100% A

1-Jul 100% A 2-Jul 100% A 5-Jul 100% A 6-Jul 100% A 7-Jul 100% A 8-Jul 100% A 9-Jul 100% A

9-Jul 100% A 9-Jul 100% A

13-Jul 100% A 16.Jul12-Jul 100% A 12-Jul 100% A 13-Jul 100% A 13-Jul 100% A 14-Jul 100% A 16-Jul 100% A 23.Jul15-Jul 100% A 16-Jul 100% A 19-Jul 100% A 20-Jul 100% A 21-Jul 100% A 21-Jul 100% A 21-Jul 100% A 23-Jul 100% A 23.Jul22-Jul 100% A

23-Jul 100% A 23-Jul 100% A 23-Jul 100% A

27-Jul 100% A


"Informe de Control de Avance Semanal"

Informe de Control de Avance

Proyecto : PNSF-Acsel/X

Tema/Sub-tema

R" 1esgos Tiempo disponible de los Integrantes de EQuipo, para el Levantamiento del Prototipo.

Tiempo adicional dedicado a conocer los Sistemas de Emisión del Acsel/X.

Incluir los días Sabados en el Cronograma

Problemas Prototipear el Módulo de "Egresos· tomó más de los 4 días programados.

EDaal. RZambrano y YMuñoz han sostenido 2 reuniones no programadas con Miguel Cerra (CONSIS-Venezuela)

Su11erados: Tomar Decisiones sin análisis

Su11erados: Puntualidad y Asistencia

Pendientes

sufciente

Reconfigurar equipos de Trabajo

RZambrano esta participando más en esta labor, EDaal e YMuñoz, en la medida de lo posible participan menos. No incluir en el Cronograma los días Sabados (por que no se trabaja horario normal, promedio 10 horas) Ojo : Se puede avanzar el trabajo, pero sin formalizarlo en el CronoQrama.

Se ha juntado el prototipeo del "Módulo de Egresos· y "Retención de Pagos"

Reunión 1: "Evaluación del significado en Volumen de trabajo de la Carga de Datos desde el AS/400". Reunión 2: Como contabiliza el Acsel/X

Se esta tomando más tiempo en las reuniones y se están haciendo reuniones adicionales.

Se están realizando las reuniones puntualmente.

Cumplimiento de tareas programadas.

EDaal, YMuñoz no "distraen" tiempo del Prototipo

Cronograma no se cumple

El lunes 21 y Martes 22 se prototipeará YM 9/06 SI el "Módulo de Retenciones· y lo que falta

del "Módulo de EQresos· 1. Se ha tomado tiempo del prototipo 2. Se tiene una idea del volumen de

RZ 17/06 SI trabajo que significa la ·carga de Datos·

3. Se conoce mejor como contabiliza elAcsel/X.

1. La calidad de las decisiones es

YM 14106 SI mejor.

2. El prototipo de los módulos toma más tiemoo del programado.

YM 14/06 SI Se esta cumpliendo con las reuniones dentro de los horarios.

1. Firmar el "Documento de Conformidad del Módulo de Generación de Acreencias Manuales· (Responsable YMuñoz). Se entregará el día Lunes 28.

2. El "Usuario-Finanzas· aún no devuelve el documento borrador del "Módulo de Ingresos" (debia devolverse el Jueves 17).

Hechos

Acuerdos

(1) Responsable (2) Fecha de Término

Semana del: 14/06/99 al 18/06/99

Líder : Jose Luis Arribas

Semana Próxima Acciones R(1) F(2)

GUIA DE USO 1. Los acápites de RIESGOS. PROBLEMAS. PENDIENTES y HECHOS corresponden a las principales ocurrencias producidas durante la semana en revisión.

2. El acápite de PENDIENTES. ad1c1onalmente consigna todos los acuerdos que surgen en las reuniones de Control de Avance. no incluidos en el cronograma y que están asignados a una persona. la cual debe tomar acción 3 El acá pite de ACUERDOS debe registrar al menos los 1 O últimos puntos más importantes, acordados durante las reuniones de Control de Avance. 4 El procedimiento general para la utilización de este informe por el Lider de Proyecto es el siguiente:

• Previo a la reunión de Control de Avance. registrará las acciones propuestas para los RIESGOS/PROBLEMAS y los hechos más relevantes de la semana.

• Durante la reunión de Control de Avance, se registrarán las modificaciones al informe, así como los nuevos acuerdos. • Después de la reunión de Control de Avance. enviará por mail a los participantes el informe actualizado.


Formato del "Documento de Apreciación" para los

Usuarios - Ejemplo

Concepto de

Acreenclas ( Cuentas

x Cobrar)

Inclusión/

Acreenclas

Facturación

Automática

Facturación Manual

(Clientes,

Intermediarios,

Pólizas/Recibo)

_()pclóf!: .• .•.

Cobradores

Configuración de

Planes de

Financiamiento

Emisión y Cálaculo

de Financiamientos

Control de

Financiamientos

Ingreso General:

Terceros, Clientes.

lntennediarios

Descuentos de

Obligaciones:

Sobrantes

Múltiples

Documentos

Consulta de Relación

de Ingreso:

Facturas

Relacionadas


de Ingreso:

Obligaciones

Relacionadas


de Ingreso:

Documentos

Relacionados


de Ingreso:

Anulación de

Ingresos

Cuadre de Caja Diario

--------- -- ---

Consulta de Caja ---------

Entidades

Financieras:

Consulta de

Disponibilidad

Entidades

Financieras:

Inclusión de Nuevas

Entidades

Financieras

Entidades

Financieras:


Cuentas

Entidades

Financieras:


Chequeras

.. ""'"""' ............... : ...... &'"' ·- • ·-·--:ia

--- ---- -------

Entidades

Financieras:

Entrega de

Chequeras

Consulta de Cuentas

Consulta de Che ues

/ Chequeras

Depósitos y

Consignaciones

Bancarias

Registro de Tasa de

CAmbio de Monedas

Conceptos de

Egresos:

Creación de nuevos

conceptos con su

código contable

asociado

Conceptos de

Egresos:

Mantenimiento de

Conceptos

Obligaciones (Ctas x

Pagar)

Relaciones de

Egresos ( con

Múltiples

Documentos)

Generación

Automática de

Cheques

Control de Cheques:

Consulta y

Conformación de

Cheques

Transferencia de

Cheques a Caja

Control de Cheques:

Sustitución de

Cheques

Control de Cheques:

Anulación de

Cheques

eraciones

de Intermediarios:

Creación de Nuevos

Conceptos

Nuevos Conceptos

Estados de Cuenta:

Consulta de

Conceptos

Pendientes x Liquidar

Mantenimiento de

Estados de Cuenta:

Consulta de

Conceptos

Liquidados

------------------------ ------------------------

Mantenimiento de

Estados de Cuenta:

de Operaclon&S

Mantenimiento de

Estados de Cuenta:

Operaciones

Manuales de

Intermediarios

Control de Otros

Conceptos

·.;.;.;.;.;.;-:-::;:··-·.· .. -. . · ... · ..... .

¡=

::::::¡:¡¡¡�ij�i!1!iftti1li�::::tf/;

Liquidación de

Intermediarios

Generación

AutomAtica de las

Obligaciones para

Finanzas (Ctas. x

Pagar)


Inventario de los "Módulos Implementados y

Operativos" en PPS en el Area de Finanzas

1 . . . . . , · . .

:-'' ,' .· ·•

1, Cobranzas

2. .Tesorería

3. Caja

4. Refinanciación

5. Anulaciones

Módulos Financieros de PPS

6. Estados de Cuenta

7. Pago Masivo

8- EDI con Bancos

9. Telestat

1 O. Access-Cobranzas

11. Control Centralizado de Caja

12. Flujo de Caja

13. Fincas

14. Caja Chica

15. Caja Provincias

16. Cobradores

17. Registro de Ventas

18. Registro de Compras

19. Agentes

Entregable 1 O: [ENT1 O]

Inventario de los "Módulos Implementados y

Operativos" en el "Software de la Consultora"

Módulos Financieros del Acsel/X·

1. Acreencias Manuales

2. Obligaciones Manuales

3. Ingresos

4. Egresos y Caja

5. Tesorería

6. Estado de Cuenta de Agentes

7. Cobradores


Cuadro con los "Integrantes de Equipos" por cada

módulo

L----------,,------------,,,------------,,-----------:,----------;,---------,,-----------:;-----------•• ---------- ,

Relación de Integrantes de Equipos

AOefgado RVasquez

Entregable 12: [ENT121

"Documento de Especifiación" - Ejemplo y "Acta

de Conformidad" - Ejemplo

/t.

1

• _P_A_IF_IC_O_Peruano Suiza

Documento de Especificaciones del Prototipo del Módulo de Estados de Cuentas

Temas

Pantalla de Selección

Requerimientos

Tip.Prob User Rev

Adicional JLA Si®

Acción Tomada

Se ha diseí'\ado una pantalla de "Selección de Documentos" en donde se pueden escoger diferentes parámetros para seleccionar la instancia de información que el Ejecutivo de Cuenta necesite visualizar.

La pantalla de "Selección de Documentos" consta de 2 secciones: la "Sección Principal" que es la que se usará en el 90% de los casos y la "Sección Secundaria" en donde se podrán realizar filtros más detallados (ambas secciones se encuentran en la misma pantalla).

Para evitar generar "Lentitud en el Sistema" es necesario enviar parámetros coherentes desde la "Sección Secundaria".

Los parár.ietros de la Sección Principal son: 1. Código de Cliente ó Identificación.2. Póliza (Producto-Ramo).3. Certificado.4. Moneda.

Los parámetros de la Sección Secundaria son: 1. Código de Intermediario.2. Código de Asegurado.3. Código del Ejecutivo de Producción. 4. Código de Endosatario. 5. Código de Ejecutivo de Cobranza. 6. Fecha de Emisión ... Rango.7. Fecha de Inicio de Vigencia ... Rango.8. Fecha de Fin de Vigencia ... Rango.9. Fecha de Convenio ... Rango.10. Estátus de la Póliza.11. Oficina Emisora o Suscriotora.

1

/t. Temas

2 Pantalla de Visualización de Acreencias

PACIFICO Peruano Suiza

Requerimientos • • ., __ - ..L..--

Tlp.Prob User

Adicional JLA

Rev Acción Tomada

Se ha disenado una pantalla de "Visualización de Acreencias" en donde se displayan todas las acreencias que cumplan con el condicionado indicado en los parámetros enviados mediante la pantalla de "Selección Inicial", en caso de que no se haya usado la "Pantalla de Selección" se displayarán todas las acreencias de la Compafüa (por defecto se mostrarán todas las acreencias "Activas" en el orden original que figuran en las tablas del sistema).

La pantalla de "Visualización de Acreencias" a su vez contiene 3 pantallas en donde se visualiza la siguiente información.

1. "Contrato de Financiamiento" Los datos que se visualizan son los siguientes: • Datos del Contrato de Financiamiento al que pertenece la acreencia

seleccionada como: • Información de las pólizas financiadas en el Contrato. • Información de los Giros de Financiamiento (Cuotas o Letras).

2. "Relación de Ingresos" esta información estará disponible cuando laSi® acreP.ncia seleccionada haya sido cobrada. Los datos que se visualizarán

en esta pantalla son los siguientes:• Otras acreencias que pertenecen a la misma Relación de Ingresos de

la acreencia seleccionada.• Obligaciones que pertenecen a la misma Relación de Ingresos (en el

caso que se hayan realizado neteos). • Documentos con los que se Cobro la "Relación de Ingresos".

3. "Detalle de la Acreencia", Los datos que se visualizarán en esta pantalla son los referentes a los detalles de los conceptQs que componen la acreencia.

Adicionalmente, la pantalla de "Visualización de Acreencias" permite, mediante una ventana de consulta hacer lo siguiente: • Seleccionar una acreencia en particular. • Seleccionar un grupo de acreencias según el rango de la Fecha de

Vencimiento.• Según tipo de acreencia. • Estatus de la acreencia. • Por Unidad de Neqocio o Centro de Costo.

2

/t. Temas

3 Pantalla de Visualización de Obligaciones

• PACI ICOPeruano Suiza

Requerimientos

Tip.Prob User

Adicional JLA

Rev Acción Tomada

Se ha diseñado una pantalla de "Visualización de Obligaciones" en donde se displayan todas las obligaciones que hayan cumplido con el condicionado indicado en los parámetros enviados mediante la pantalla de "Selección Inicial", en caso de que no se haya usado la "Pantalla de Selección" se displayarán todas las obligaciones de la Compañía (por defecto se mostrarán todas las obligaciones "Activas" en el orden original que figuran en las tablas del sistema).

La pantalla de "Visualización de Obligaciones" a su vez contiene 3 pantallas en donde se visualiza la siguiente información.

1. "Relación de Egresos (Pagos)" esta información estará disponiblecuando la obligación seleccionada haya sido pagada. Los datos que se visualizarán en esta pantalla son los siguientes:• Obligaciones que pertenecen a la misma Relación de Egresos que

Si® pertenece la obligación seleccionada.• Documentos con los que se Pago la "Relación de Egresos":

2. Detalle de la Obligación en donde se muestran el detalle de losconceptos que han sido pagados.

3. Observaciones que tendrán aquellas Obligaciones que hayan sido retenidas.

Adicionalmente, la pantalla de "Visualización de Obligaciones" permite, mediante una ventana de consultas hacer las siguientes selecciones: • Seleccionar una obligación en particular.• Seleccionar un grupo de obligaciones según el rango de la Fecha de

Garantía (Fecha de Pago).• Según tipo de obligación.• Estatus de la obligación• Tipo de obligación• Por Unidad de Negocio o Centro de Costo

3

/t. Temas

3 Pantalla de Visualización de Resumen

4 Pantalla de Movimiento de Primas

PACIFICO Peruano Suiza

Requerimientos . . . - . ·-

Tlp.Prob User

Adicional JLA

Rev Acción Tomada

Se ha diseñado una pantalla de "Resumen" en donde se displayarán el Monto

SI® total de las Acreencias y Obligaciones en Soles y en Dólares de los registrospreviamente seleccionados mediante la "Pantalla de Selección".

Se ha diseñado una pantalla de en donde podrán visualizarse todas las pólizas que cumplan con los parámetros previamente indicados en la "Pantalla de Selección".

Los datos que se mostrarán serán los siguientes: • Póliza (Producto - Ramo).• Certificado.• Fecha de Emisión .• Fecha de Inicio de Vigencia .• Fecha de Fin de Vigencia .• Código de Intermediario .• Número de Contrato de Financiamiento .• Código de Moneda .• Monto .

Adicionalmente hay una opción de ver los "Datos Generales" de la póliza seleccionada. En donde se mostrarán básicamente datos de la emisión de la póliza, adicionalmente se podrá visualizar (rápidamente) si la póliza tiene "Reasequro Facultativo".

4

Acta de Conformidad del Levantamiento del Prototipo del "Módulo

de Estados de Cuenta"

Los abajo firmantes validan el "Documento de Especificaciones" presentado por Informática así como al "Prototipo del Módulo de Estados de Cuenta" presentado por CONSIS, que reside en el servidor de Desarrollo de Aplicaciones PPS, cuya operatividad fue explicada en la "Reunión de Validación" llevada a cabo el día Jueves 22 de Julio.

Considerandos

1. El módulo prototipeado pretende cubrir un 100% del total de los requerimientos quepudieran aparecer en el transcurso de la "Etapa de Implementación del NuevoSistema Financiero del Acsel/X".

2. La existencia de este Prototipo no inhibe futuras modificaciones y adecuaciones a losplanteamientos aquí recogidos, sin embargo cualquier modificación posterior a lafinalización del Prototipo modificará indefectiblemente los plazos que presentaráCONSIS.

3. Los estimados para la implementación del "Módulo de Estados de Cuenta" estaránbasados en el prototipo levantado por CONSIS y el Usuario-Finanzas así como en el"Documento de Especificaciones" preparado por Informática. Estos estimados loselaborará personal de CONSIS en su local de Caracas-Venezuela.

4. El Diagrama Entidad-Relación será generado por personal de CONSIS en su local deCaracas-Venezuela, basándose en el Prototipo levantado, así como en el "Documentode Especificaciones".

5. Los integrantes de equipo que participaron por el Usuario-Finanzas:• Claudia Morote (Líder de Equipo)• Jose Luis Arribas

Líder de Equipo Claudia Morote

Líder Usuario Jose Luis Arribas

Lima, 26 de Julio de 1999

/t.

1

• ___ P_A_ C_I_F_I_C_O_ Peruano Sutza

Documento de Especificaciones del Prototipo del Módulo de Ingresos

.

Requerimientos de Procesos ( Facturas·y Notas) -_.. - • _ _._ � .a.

Temas Tip.Prob User Rev

Implementar la Factura y Boleta SUNAT Que le

EHaj SI® Falta?

•

•

•

•

•

•

•

•

•

Acción Tomada

CONSIS adicionará la Entidad Factura-SUNAT y Boleta-SUNAT (posiblemente cree una tabla especial para almacenar esta información, esto se definirá en la "Etapa de Implementación"). La entidad Factura-SUNAT no existe como tal en el Acsel/X, lo que implica una implementación adicional. La Factura o Boleta SUNAT se creará en el momento que finalize la elaboración de la "Relación de Ingresos". La Factura o Boleta SUNAT se imprimirá inmedia1amente después de concluir la "Relación de Ingresos". El sistema guardará un FLAG o MARCA que indique si la Factura o Boleta SUNAT ha sido impresa. Por defecto el "Módulo de Ingresos" emitirá Facturas o Boletas SUNAT quebrando por "Moneda-Contratante-Asegurado" (como en la actualidad), siempre y cuando el Area Emisora haya generado un A/C por cada asegurado. El formato de la Factura y Boleta SUNAT tomará un correlativo y prefijo único como en la actualidad. Los formatos de la Factura y Boleta SUNAT, no sufrirán modificación alguna, sin embargo INFORMATICA suguiere aprovechar el cambio de sistema para mejorar la presentación de las mismas. La anulación y cambio de "Boleta por Factura" y "Factura por Facturas" sera una opción del "Módulo de Registro de Ventas", que debe ser orototioeado posteriormente.

1

• PACIFICO--

Peruano Suiza

Requerimientos de Procesos ( Facturas y Notas)

/t. Temas Tip.Prob User Rev Acción Tomada ..

• El cambio de "Facturas por Facturas" y "Boletas por Facturas" será atendido en un módulo llamado "Módulo de Registro de Ventas".

• Para cambiar una "Factura" por un "Grupo de Facturas" se procederá de la siguiente manera

2 Implementar "Cambio de Boleta r;ior Factura" Que le

EHaj SI® • Se emitirá una Nota de Crédito por la Factura-SUNAT que se anula .

Falta? • En base al detalle que aparece en la factura que se anula, se emitiránuevas facturas.

• El cambio de Factura por Facturas esta relacionado estrechamente a la forma en que el Area Emisora generó los Avisos de Cobranzas ( Ej. Por Póliza-Línea o por Contratante-Asegurado), en el caso que el Clientesolicite una agrupamiento diferente al que se puede obtener del detalle de

Selección de Factura SUNAT con un Aviso de Cobranza Que le su Factura, el Area Emisora tendrá que emitir nuevamente.

o Varios. Cambio de una por otra. Falta? EHaj SI® • CONSIS esta evaluando la forma de implementar la Opción de "Cambio

de Facturas" de manera de cumplir sus estándares y evitar la redundanciade los datos.

• Las Notas se originarán en la pantalla de "Documentos de Cobro" . • Se creará un Tipo de Acreencia Nota de Crédito • Se creará un Tipo de Obligación Nota de Débito . • Las Notas de Crédito y Débito se crearán cuando superen un "Tope

Mínimo", este "Tope" será establecido posteriormente por el Area deCobranzas.

Que le • Se guardará prefijo y numeración separada por cada tipo de nota (Nota de

4 Gestión de Notas de Crédito y Notas de Débito. Falta?

EHaj SI® Crédito y Nota de Débito), diferenciándolas siempre. de las Notas que se Numeración Separada. pudieran crear por conceptos de Otros Ingresos.

• Las Notas de Crédito y de Débito generadas al procesar una transacción en Ventanilla se imprimirán una vez culminada la "Relación de Ingresos".

• En el caso que se elabore una "Relación de Ingresos" para varios clientes,el Liquidador/Cajero seleccionará el cliente a quien corresponde la Nota.

• El Liquidador/Cajero no podrá asignar una Nota de Crédito o de Débito a un cliente diferente al que esta trabajando en su "Relación de Ingresos".

La diferencia por cuadre en la "Relación de Ingresos" Que le

5 debe poder ser de varios tipos y seleccionada por el Falta?

EHaj SI® Este requerimiento es atendido con la atención del Punto Anterior (4) Usuario: "Diferencia de Cambio", "Nueva Acreencia", etc.

2

• PACIFICO--

Peruano Suiza

Requerimientos de Procesos ( Documentos de Cobro) .. 1 --- - ·--- -�

/t. Temas Tip.Prob User Rev Acción Tomada r º,

[Descuentos de Obligaciones Sobrantes] Es necesario que se pueda elegir las cuentas que se

Puntos en 1 pueden afectar ( "Servicio de Bancos" o "Ajuste por ROrb SI® El "Módulo de Ingresos" permite hacer esta diferenciación.

Ganancia o Pérdida de Cambio") y generar los Contra -

documentos adicionales que sean necesarios. • Montos mínimos se van a Cuentas de Resultados (Cuenta única) .

(Descuento de Obligaciones Sobrantes] Que le

• Los topes se fijarán en la "Etapa de Implementación", inicialmente se Que los "Sobrantes" puedan difererirse a una cuenta

Falta? RZam SI® habló de 1.00 US Dólares.

contable y no genere documento alguno • Todo diferencia que supere el "Tope Establecido", generará "Acreencia" u"Obligación" seaún sea el caso.

Se acordó lo siguiente • Finanzas revisará cual es la forma en que los bancos controlan la

numeración de sus Notas.• Una vez revisado los estándares de numeración de cada banco, se

procedera a establecer controles que no permitan digitar ni mas ni menos 3 Control de Notas de Abono Bancarias Adicional SI® cifras de las que corresponde al número de Nota de un banco

determinado, lo cual Qermitirá controlar gue gue no se ingrese unamisma Nota dos veces.

• Este control se implementará vía programa (Hard-Code) .• Esta facilidad estará disponible en la opción de "Ingreso General\

Documentos de Cobro".En el "Módulo de Ingresos" del Acsel/X un cheque que entra por Caja debe entrar a distribuirse el mismo día o máximo al día siguiente y no puede quedar en espera, por falta de fondos. Ejemplo: Si un cliente paga con un cheque que no puede ser cobrado el mismo día de la transacción (x falta de fondos) y ya se le hizo la "Relación de Ingreso".

4 Cheques sin Fondos en espera Adicional MAbad SI® 1. Si se conoce del problema antes del Pre-Cierre (durante el día), se procederá a anular la "Relación de Ingresos" y la Factura-SUNAT.

2. Si se conoce del problema después del Pre-Cierre, se seguirá elprocedimiento de Cheque Devuelto.

En el 1er caso al anular la "Relación de Ingresos", ya �O se acreditarán las Comisiones que se puedan haber generado producto de ese pago (se reversarán).

Debe permitirse cuadrar la "Relación de Ingresos" en una Que le

El Acsel/X permite cuadrar la "Relación de Ingresos" en moneda nacional o en 5 sola moneda

Falta? EHaj SI® dos monedas según los documentos con los que se estén pagando sea una

moneda o dos.

3

1

2

3

4

Controlar que las aplicaciones se realicen con documentos de un mismo Cliente o contar con una aprobación especial para pasar este tipo de transacciones.

Control automático de "Obligaciones de Clientes" que tienen "Acreencias Pendientes"

No controla que la "Aplicación de una Obligación" o Pago se realice sobre un mismo cliente.

Control automático de "Obligaciones de Clientes" que tienen "Acreencias Pendientes"

Que le Falta?

Que le Falta?

Puntos en Contra

Que le Falta?

RZam

EHaj

SI®

RZam

EHaj SI®

• ___ P_A_C_I_F_I_C_O_Peruano Suiza

•

•

•

•

•

•

•

•

•

Al elaborar una "Relación de Ingresos", cada vez que se escoga uno o varios clientes, se jalará automaticamente todas las Acreencias y Obligaciones de ese o esos clientes. La selección de Clientes se realizará desde una pantalla especialmente diseñada en el prototipo. Los Liquidadores/Cajeros solo visualizarán aquellas Obligaciones que provengan por conceptos de : • Siniestrro Retenido.• Obligación generada por un Sobrante.• Endosos Negativos (Devoluciones de Primas).• Pago de Primas adelantado. Los Ejecutivos podrán "jalar" Obligaciones de un Cliente diferente que no haya sido seleccionado previamente, este acceso será restringidomediante "Permisología".El Monto Neto a pagar por cliente siempre debe ser positivo En caso que un Monto Neto por cliente sea negativo, el supervisor de Caja deberá ingresar un password de autorización para continuar con la elaboración de la "Relación de Ingreso".El sistema guardará registro de el password digitado. para implementarcontroles posteriores.El sistema no permitirá Montos Netos negativos a nivel de "Relación de Ingresos".Solo los Ejecutivos de Cuenta podrán realizar transacciones cuyo MontoNeto a nivel de "Relación de Ingresos" sea menor que cero. en esos casosel sistema guardará registro de ese tipo de operaciones, que seránauditadas ( mediante listados) a pedido del usuario.

El "Módulo de Ingresos" permite jalar las obligaciones (*) de los clientes que tienen Acreencias. (*) El Usuario-Finanzas debe definir cuales son las Obligaciones que deben visualizarse or la antalla de los Li uidadores/Ca·eros.

4

/t.

• PACIFICO--

Peruano Suíza

Requerimientos de Procesos ( Cierre de Caja)

Temas np.Prob User Rev

Pre-Cierre y Cierre General Adicional MAbad SI®

Que le Cierre del día considera el "Depósito de Cheques" al día

Falta? EHaj SI®

siguiente.

Acción Tomada

Se implementará un procedimiento de Pre-Cierre, que se hará de la siguiente manera: • Cada cajero realizará un Pre-Cierre, que le generará un listado con el cual

realziará el cierre de su caja.• INFORMATICA suguiere se norme una hora límite para que cada cajero

realice su Pre-Cierre, ejemplo • Lima 5:00 pm • Sta. Cruz 7:00 pm • Arequipa y Chiclayo 7:00 pm .

• MAbad a las 7:05 pm podrá correr una Consulta de Caja x Oficina (Reporte) donde visualize el movimiento de Efectivo, Cheques, Notas, etc . . El podrá saber mediante el sistema si alguna de las Cajas aún no ha realizado su Pre-Cierre.

• Con la consulta de Caja por Oficina (impresa) se hará la "Distribución" . • Al día siguiente MAbad luego de terminar su "Distribución" y haber

afectado su "Posición de Bancos" por el módulo de Tesorería, ejecutará el"Cierre Definitivo".

Se controlará por el "Módulo de Ingresos" en la opción de "Cuadre Diario de Caja". Se puede hacer un "Pre-Cierre" en el mismo día y un "Cierre Definitivo·· al dia siguiente".

5

• ___ P_A_C_I_F_I_C _O_Peruano Suiza

Requerimientos de Control ( Varios)

lt. Temas Tip.Prob User Rev Acción Tomada

Se tendrá en cuenta en la programación del módulo : Cuando se pague un

1 Control de Pre-Emisión, cambio de fecha del Aviso de Que le

EHaj SI® documento que este como "Pre-Emitida", este pasará a estado de "Convenio

Cobranza y su respectiva contabilización, al momento del Falta? de Pago" automáticamente y la fecha del "Convenio de Pago" será la fecha en cobro. la que se realiza el pago.

Se ha adicionado en la "Pantalla de Consulta" que esta disponible en la opción de "Consulta/Anulación de Ingresos" , los siguientes campos de

2 Ubicar en que "Relación de Ingreso" se ha dado por

Adicional MAbad SI® busqueda:

pagado un documento • Aviso de Cobranza • Nro de Giro o Cuota . • Nro de Financiación . Se ha prototipeado un campo adicional de "Oficina" en la Pantalla de

3 Es necesario una Consulta de Caja a nivel de Oficina

Adicional MAbad SI® "Consulta de Caja", de manera que Tesorería pueda conocer el movimiento

(Lima, Sta. Cruz, Arequipa, Chiclayo) por "Tipo de Documento" por cada oficina (lima, Sta. Cruz, Arequipa, Chiclayo).

4 Cuentas de Efectivo por moneda para cada Oficina Adicional MAbad SI® Esto se ha contemplado en el "Módulo de Tesorería".

5 Manejo de Centros de Costo Que le

EHaj SI® Esto se ha contemplado el "Mód. de Generación de Acreencias Manuales".

Falta?

6 Que le

EHaj SI® Esto se ha contemplado en el "Módulo de Tesorería/ Chegue Devuelto".

Incorporar como "Acreencia" los "Cheaues Devueltos". Falta?

7 No todos los documentos pueden ser tratados de igual Puntos en

ROrb SI® Esto esta contemplado con la estructura de "Ti¡;io-Gru120-Conce12to" que

forma v no aeneran los mismos movimientos contables Contra maneja el Acsel/x.

8 Debe existir una señal al usuario que le indique los Puntos en ROrb SI® limites o autoridades de trabajo Contra Esto se contemplará mediante el "Módulo de Permisoloaía" del Acsel/X.

9 Debe permitirse la identificación y las razones por las Puntos en

ROrb SI® Cuando en el "Módulo de Ingresos", el Monto Neto a cobrar por Cliente sea

cuales se invalida un "Ingreso" o una "Forma de Cobro" y Contra negativo, la elaboración de la "Relación de Ingresos" no podrá continuar hasta la persona que generó las modificaciones. que el supervisor digite un Password, que autorize la transacción.

6

• ___ P_A __ I_F_l_'-_O_Peruano Suiza

Requerimientos Ergonómicos

/t. Temas Tip.Prob User Rev Acción Tomada ,.

Consulta del detalle de la Cuenta por Cobrar: Póliza, Puntos en Finanzas dio conformidad para que esta facilidad sea contemplada en el

Cliente, Agente, Financiamiento, si es Patrimonial que Contra

EHaj SI® Prototi12eo del "Módulo de Estados de Cuenta". Primas incluye, si tiene Cupones, Letras, etc.

Que le Se ha adicionado 3 campos adicionales a la pantalla de "Búsqueda de

Búsqueda de Documentos por Cobrar por: Número, Falta?

EHaj SI® Documentos" : Tipo de Documento (Factura, Cupón, Letra, Notas (Cr/Db), Póliza-Certificado, Cliente, Financiación, etc. Póliza, Certificado, Nro. de Financiación.

Se han colocado botones de "Ordenamientos" por cada campo en la Pantalla de Selección de Avisos de Cobranzas/Obligaciones que está en la Opción "Ingreso General/ Selección de Avisos de Cobranzas": • Númerpo de A/C,

3 Puntos en

ROrb SI® • Nombre de Tercero

Debe permitirse el ordenamiento de las "Pantallas de Contra • Apellido de Tercero

Selección de Documentos". • Moneda• Producto• Póliza -

• Certificado

4 Mayor Cantidad de Lineas para visualizar "Documentos Que le

EHaj SI® Se ha prototipeado en la Opción "Ingreso General" la opción "Avisos de

Cobrados" y "Forma de Cobro". Falta? Cobranza" y "Obliaaciones", en donde las pantallas tienen mas líneas.

5 Poder seleccionar "Facturas" y "Obligaciones" de más de

Adicional SI® Se ha prototipeado la pantalla "Tercero" en donde se puede seleccionar 1 o

un cliente varios clientes.

7

Acta de Conformidad del Levantamiento del Prototipo del "Módulo

de Ingresos"

Los abajo firmantes validan el "Documento de Conformidad" presentado por Informática así como al "Prototipo del Módulo de Ingresos" presentado por CONSIS, que reside en el servidor de Desarrollo de Aplicaciones PPS, cuya operatividad fue explicada en la "Reunión de Validación" llevada a cabo el día Martes 8 de Junio.

Considerandos

1. El módulo prototipeado pretende cubrir un 100% del total de los requerimientos quepudieran aparecer en el transcurso de la "Etapa de Implementación del NuevoSistema Financiero del Acsel/X".

2. La existencia de este Prototipo no inhibe futuras modificaciones y adecuaciones a losplanteamientos aquí recogidos, sin embargo cualquier modificación posterior a lafinalización del Prototipo modificará indefectiblemente los plazos que presentaráCONSIS.

3. Los estimados para la implementación del "Módulo de Ingresos" estarán basados en elprototipo levantado por CONSIS y el Usuario-Finanzas así como en el "Documento deConformidad" preparado por Informática. Estos estimados los elaborará personal deCONSIS en su local de Caracas-Venezuela.

4. El Diagrama Entidad-Relación será generado por personal de CONSIS en su local deCaracas-Venezuela, basándose en el Prototipo levantado, así como en el "Documentode Conformidad".

5. Los integrantes de equipo que participaron por el Usuario-Finanzas:

• Mario Abad (Líder de Equipo)

• Enrique Hají

• Rosaluz Orbegoso

Líder de Equipo Mario Abad

Líder Usuario Jose Luis Arribas

Lima, 25 de Junio de 1999


"Informe Final de la Ejecución del Proyecto"

Informe Final de la Ejecución del Proyecto para desarrollar el

Prototipo del Nuevo Sistema Financiero del Acsel/X - [PNSF]

Mediante el presente documento se resume el trabajo realizado durante la ejecución del PNSF del Acsel/X.

1. Del Cumplimiento de los Objetivos:

El proyecto del PNSF-Acsel/X tenia como objetivo principal

"Identificar los módulos, funciones y servicios que se deben modificar y adicionar en la parte financiera del Acsel/X con la finalidad de cuantificar con precisión la inversión necesaria para su implementación"

2. Módulos prototipeados:

Módulo de Acreencias Manuales Módulo de Ingresos Módulo de Egresos y Retención de Pagos Módulo de Tesorería Módulo de Agentes Módulo de Financiamiento Módulo de Anulaciones Módulo de Estados de Cuenta Módulo de Cobradores

El PNSF- Acsel/X se conforma de: • Prototipo desarrollado en Developer/2000.

(LE: EHají, JLArribas, ROrbegozo) (LE: MAbad, EHají, ROrbegozo) (LE: MAbad, EHají, ADelgado) (LE: ADelgado, Abad, EHají) (LE: OChavez, JLArribas) (LE: JLArribas, MPiscoya, GMenendez) (LE: MPiscoya, JLArribas, CSuarez) (LE: CMorote, JLArribas) (LE: JLArribas)

• Especificaciones documentarías de las opciones y procesos de los diferentes módulosasí como bosquejos de información que serán mostrados a través de reportes.

3. Ubicación del Prototipo:

El ejecutable del prototipo reside en el directorio "Epps inf \ Acself\Fmb\", y se esta backpeando diarimente, el ícono del PNSF-Acsel/X está instalado en las PCs de Jose Luis Arribas, Enrique Hají y Yuri Muñoz.

4. Duración del Prototipo:

La ejecución del PNSF-Acsel/X con la participación de CONSIS ha durado del 17 Mayo al 27 de Julio (72 días calendarios). El contrato preveia una duración de 2 meses (60 días calendarios) y 1 semana de gracia.

5. Acciones futuras de CONSIS:

1. Con el PNSF-Acsel/X desarrollado, CONSIS definirá el Diagrama de Entidad-Relaciónque soportará la estructura de datos que permita la implementación del MóduloFinanciero de Acsel/x para PPS.

2. Estimar de manera detallada los tiempos necesarios para implementar los cambios yadiciones recogidas en el PNSF-Acsel/X.

Lima, 26 de Julio de 1999


Diagrama de Procesos y Módulos del "Nuevo

Sistema Financiero de PPS"

o

o

-LL

-�

-:::,

o

(/)

o

<C

D.

-

e PACIFICO

Peruano Suiza

•• t 1--Y 51-

Acreencias del Negocio (Ref)

""® . 00 ...

...

... Acreencias del Negocio /

- ti - / �Acreen�

ias Ma�

u.ales

/ ¡ Acreencias Cobradas

en Bancos

Refinanciación de Acreencios (*)

Crear Relación de Ingresos (Manual y

Automática) *

Anulaciones de Acreencias Impagas (*)

Gestión de Cuentas Bancarias {Tesorería)*

'1111!@., U? Ql, ....

...

Registro de Ventas

_...

•Relación de Ingresos•Facturas/ Boletas•Notas

Obligaciones x Comisiones

...

...

...

•Relación de Egreso&•Facturas/ Bo4etas y Notas

-

_cambio de Boletas x Factura

Pago de Comisiones (*)

Pago Masivo 1

e PACIFICO

Peruano Suiza

Ricardo Vasquez

ti •

f abiola Alfajeme

ti Miguel Zevallos

-

1 • � • •

5 Et E

., . � . ... . .. . ' . .

-,.,,,_s . ... se ,.. ;e .• t ,..

Acreencias Manuales x

Reaseguros y Coaseguros

Acreencias Manuales xFincas

Acreencias Manuales xRecuperos

�· g í\cr�;�-��s Manuales de PPS *

8 PACIFICO

Peruano Suiza

(+) Comisiones

-� -

(+) bonificaciones

/

H Prestamos

Operaciones de Agentes

-

Adicionar nuevas Operaciones

Visualizar Operaciones

Retener Comisiones

Pre-Liquidar Comisiones

Liquidar Comisiones

Generar Obligaciones para Netear

Control de Préstamos

OblJgac:iones

Pago Masivo -

Proceso Nocturno 1 de Cheques

- PACIFICOPeruano Suiza

Entidades Financieras

Chequeras

Gestión de Cuentas Bancarias (Tesorería) �.

Posición de Bancos (Real)

Archivo de Movimiento de

Cuentas

Depósitos

/ Depósitos

Documentos de Ingreso

Pagos

Operaciones entre cuentas

Movimiento de Cuentas

• PACIFICO Módulo de Ingresos Peruano Suiza

Seleccionar Documentos a Pagar Crear "Relación de Ingresos�' _ = _:_ ._

I�sar los bocumentos de. Pggo . (Efectivo •. Cheque,.

4' PACIFICO

Peruano Suiza

- - -

- Opciones del Módulo Re-Financiador * :·

Días entre Cuotas

Tasas de Interes

Número de Cuota,s vs.

Vigencia de los Pólizas. -

Refinanciomiento de Letras sale con Letras�

Man.to mfnímo de Cuotas y Letras.

4"·twe�� L i��2-��C?,. �e��'?.�i.�io�,.. J

� .. ¿��é�,,d�.,x�y.t ":·.;d�:\-·'': 1 �ar. �ot� a refinanc. - j

Jajd�Jití,�ilpili< ':'NT't,,·:-� í

1 >At1ular lemas o refinanc !

4j PACIFICO

Peruano Suiza

zf Juan Morán

zf �arina Tejada

�

ITJlc Jose Layseca

Obligaciones Manuales . . _ . __

Obligaciones de Economato

Obligaciones de Marketing

Obligaciones x Servicions Generales

ObUggciones por p�s de Reaseguros y Cooseguros

% Obligaciones Manuales de PPS *


Diagrama de Procesos y Ejemplos del Módulo

Refinanciador y de Anulación

8 PACIFICO

Peruano Suiza

Cliente# 1 3M

�óliza: # 1,;' x/tooo ,, "..:z�··. �� ... ,;:_;:__":.,.ó..,"' -»!·�"· . ' .,.>,;.�--�"

Cliente # 3 3Com

CuÓta # 1 , x 2,000 , . � . . .

EMISION

G PACIFICO

'"" .• :r

. . &'

N•«I

·.:o.a.

"'• _g

;� .·:O

"'•-�

11) •�

Peruano Suiza

1 1 1 1

1 1

1

•

··-- ..

. -- . ---- -

. .. . . .. . -·- ·-·-· ·-··- -- -

···--·

Pagos Anteriores

Pago Cubierto con Cuota# 7


Pagos Anteriores



Pagos Anteriores



Pagos Anteriores



Pagos Anteriores


� x Pagar

1,000

500

1,000

500

11 Pagada 11 x Pagar 11 Pagada rl x Pagar 11 Pagada r1 x Pagar 1 Pagada

11 11 30 11 I] 180 11 l'I 100

11 500 IJ 15 11 15 1 1 90 11 90 1 1 100

· Refinánciado eil Contrato de Refhniciainientr> i# 5

11 11 30 11 1 1 180 11 " 100

11 500_] j 15 11 15 1 1 90 11 90 11. 100

Refinanci-ado en Cónttato de Refianci,amiento # 5

fl PACIFICO

Peruano Suiza

Póliza# 1 x US 900 Vig 1 Ene al 31 Die

Comisión 10%

Endoso # 1 x US 800 Vig 1 Mayal 31 Die

Comisión 10%

Pagos al 1 de Julio

•

•

Total Pagos Cuota # 1 US 300 Cliente US 700

Comisión pag. US 45 Cuota # 4 US 400

Comisión pag. US 40

Comisión paq. US 85

Costo de Cobertura diaria jPóliza # 1 x día (US 900/365) :-> 2.465

.-' Endoso# 1 x día (US 800/245) -> 3.265

Anulaciones - Ejemplo _.

Vigencia Original

Cuota # 1 x 300 � Cuota # 2 x 300 Cuota # 3 x 300

Nueva Vigencia SBS

• Vigencia Original

Cuota # 4 x 400 � �uota # 5 x 406·

--------• N. Vig. SB� �

• Fecha de anulación -> lero de Julio

-> 120 días x 2.465 = US 296


Documento "Propuesta de Inicio de Trabajos"

Propuesta de Inicio de Trabajos

1. Poner operativo la generación de Acreencias Manuales

Que trabajos implica:

Centro de Costo y Unidad de Negocio:

1.1 Definir la estructura definitiva de los campos que guardarán los datos referentes a los Centros de Costos y las Unidades de Negocio, en las tablas de Acsel/X.

1.2 Crear una opción de Mantenimiento de la Tabla de Centros de Costos y Unidades de Negocio (Consultas y Reportes).

1.3 Aplicar restricciones en la aplicación de los Centros de Costos y Unidades de Negocio en el "Módulo de Acreencias Manuales".

1.4

Precisar Manejo Operativo de:

• Pagos Adelantados• Ventas de Administración• Coaseguros y Reaseguros• Recuperes• Cobranzas

Para los 5 conceptos mencionados arribas hay que precisar lo siguiente:

1. En que opción de Acsel/X se emitirán los documentos (se supone que en todos loscasos debería ser la opción de "Inclusión/ Mantenimiento de Acreencias".), En el casode "Adelantos" es posible que sea necesario usar el "Módulo de Obligaciones".

2. Definir documentos "Impresos de Salida" (Formato de Acreencia, Factura o BoletaSUNAT).

3. Definir "Tipos-Grupos-Conceptos", para cada uno de las Areas (es necesario que cadaarea tenga un grupo de cuentas restrngida por seguridad y para evitar errores decontabilización), al definir esto se estará definiendo también la contabilización de losmovimientos.Eiemplo: En el caso de "Adelantos", existen adelantos por Viáticos, Capacitación,Adelanto de sueldos, etc.

4. Definir usuarios por cada Area.5. Definir si alguno de estos módulos debe estar en más de un Area

Eiemplo: Recuperes debe estar en Automóviles, Cascos, Transportes, etc.6. Definir si las areas cuentan con algún sistema mecanizado y definir si existiría

duplicación de esfuerzos al implementar el "Módulo de Acreencias Manuales".Establecer desde un principio que el "Módulo de Acreencias Manuales" es un sistemapara mejorar el Control de Finanzas en la empresa y que no podría convertirse en un"Sistema de Control o Gestión" para el Area en si.

1. Definir las Tablas en donde se guardarán las Facturas, Boletas y Notas que segeneren por la Cancelación de las Facturas.

2. Definir las.Opciones que tendrá el "Módulo de Registro de Ventas":• Crear Facturas/Boletas/Notas.• Anular Facturas/Boletas/Notas.• RE-impresión de Facturas/Boletas/Notas.• Consultas de Facturas Emitidas, Anuladas.• Consultas de Facturas Emitidas por cliente, por Area, etc.• Reportes de Control.• Reportes para el "Registro de Ventas".• Opciones de exportación de Formatos texto en disco.• Opción de Cambiar Facturas por Boletas con Generación de Notas.

Definir formatos de Facturas/Boletas y Notas. En esta etapa es factible diseñar un nuevo formato para las Facturas/Boletas/Notas (Código de Barras).

Poner operativo el "Módulo de Ingresos", para poder hacer lo siguiente: • Escoger un cliente para jalar las Acreencias que le pertenecen.• Selección de Acreencias y Filtros de Consulta.• Generar la "Relación de Ingresos"• Consulta de las Relaciones de Ingresos, con las Acreencias y Dctos, de Pago de una

"Relación de Ingresos".• Poner Operativo la Consulta de Caja junto con los Documentos del Periodo,

Documentos de Caja y la Consulta Gráfica.• Pre-Cierre y Cierre de Caja.• Consulta de Documentos de Ingreso.• Ergonomía ,de Pantallas.

Que cosas aún no se implementarian.• Neteos de Obligaciones (Aprobaciones, permitir múltiples clientes).• Gestión de Notas de Crédito• Control de de Notas de Abono Bancarias• Generación de Ajustes (Acreencias u Obligacion_es).• Control de la Pre-Emisión y Convenio de Pago.

Que trabajos implica:

Centro de Costo y Unidad de Negocio:

4.1 Definir la estructura definitiva de los campos que guardarán los datos, referentes a los Centros de Costos y las Unidades de Negocio, en las tablas de Acsel/X.

4.2 Aplicar restricciones en la aplicación de los Centros de Costos y Unidades de Negocio en el "Módulo de Obligaciones Manuales".

4.3

Precisar Maneio Operativo de: • Economato (Juan Morán)• Marketing (Marina Tejada)• Servicios Generales (Jose Layseca)• Pagos por Reaseguros (Ricardo Vasquez)• Otros Pagos (Mario Abad).Para los 5 conceptos mencionados arribas hay que precisar lo siguiente:

1. Definir documentos "Impresos de Salida" (Formato de Obligaciones u Ordenes dePago).

2. Definir "Tipos-Grupos-Conceptos", para cada uno de las Areas (es necesario que cadaarea tenga un grupo de cuentas restringidas por seguridad y para evitar errores decontabilización), al definir esto se estará definiendo también la contabilización de losmovimientos.

3. Definir usuarios por cada Area.4. Definir si alguno de estos módulos debe estar en más de un Area.5. Definir si las areas cuentan con algún sistema mecanizado y definir si existiría

duplicación de esfuerzos al implementar el "Módulo de Obligaciones Manuales".Establecer desde un principio que el "Módulo de Obligaciones Manuales" es unsistema para mejorar el Control de Finanzas en la empresa y que no podríaconvertirse en un "Sistema de Control o Gestión" para el Area en si.

6. Quien genera la Orden de Pago

Poner operativo las siguientes funciones del "Módulo de Egresos": • Conceptos de Ingreso• Mantenimiento de Obligaciones (Crear, Actualizar, Anular, Visualizar, Generar Orden

de Pago).• Mantenimiento de Ordenes de Pago (Visualizar, Anular, Actualizar).

• Generar Relación de Egresos escogiendo las Ordenes de Pago, listas.• Emisión de Cheques.• Consulta/Anulación de Relaciones de Egreso.• Entrega de Cheques.

No poner aún operativas las siguientes funciones: • Generación de Ordenes de Pago de' Obligaciones Retenidas.• Retener Ordenes de Pago.• Pagos Masivo (Garantía de Pagos, Selec. de Pagos, Pago Masivo, Pre-Pago Masivo).

¿?• Emisión de Cheques en Lote.

Implementar el 100% del Módulo de Tesorería, esto significaría por un tiempo hacer los siguiente:

• Emisión de Cheques para las Obligaciones Manuales por el Acsel/X. (Economato,Servicios Generales, Marketing, Reaseguros, Otros Pagos).

• Hacer 2 cierres uno de AS/400 y otro de Acsel/X.• Hacer un Depósito con cierre de AS/400 y otro de Acsel/X.• Tener una posición de bancos en AS/400 y otra en Acsel/X• Tener juegos de cheques en AS/400 y juego de cheques en Acsel/X

Una forma de facilitar esto sería teniendo una sola cuenta para todos estos pagos. Pero aún así se necesita una persona de apoyo en Tesorería, definitivamente. durante esta etapa.

Poner operativo el módulo de Pagos Masivos para poder pagar a los proveedores de (Economato, Servicios Generales, Marketing, etc). Antes de esto hay que verificar si se puede realizar estos pagos vía Transferencia Electrónica.

Solo debe poner operativas las pantallas pedida$ por JLArribas, pero solo se podrán visualizar las Acreencias y Obligaciones manuales, por lo tanto no se podrá visualizar información referente a la pólizas ni a las Financiaciones.

Entregable 17 [ENT17]

Cronograma en bloques de la implementación de

los Módulos (expresado en Días útiles)

... ,

....

....

....

....

....

... ,....

....

... , .... ,,

... 12

.....

.....

.....

.....

... ,,

.....

.....

D1a2I

Di1Z1

D1al2

.....

.....

Dla2'

Dla21

... .,

Dla21

.....

DlaSI

.....

.....

.....

.....

.....

.....

... .,

.....

.....

.....

.....

.....

D1aa

.....

Dla4'

....

... .,

.....

Dla4'

.....

.....

.....

DlalS

DlaM

.....

.....

Dlal7

.....

.....

.....

.....

.....

.....

.....

.....

.....

Dlal7

....

....

... ,.

Dla71

D1an

... ,.

... ,.

... ,.

... ,.

... ,,

... ,.

... ,.

....

.... ,

Dlal2

.....

.....

....

Olall

... .,

....

....

.....

Dlaff

Dlal2

.....

.....

....

....

... .,

....

º'""

... , ..

..... ,

... 112

......

... , ..

a .. ,u

......

..... ,

... , ..

EDT 11 xRB 11 Prepración de Ambiente de JI Conocer-�! Acsel/X Finanzas y �11

Desarrollo y de Pruebas (4d) Diagrama E/R (4d) J

Registro de Ventas (� l Implementar Módulo de _j

Acreencias Manuales al 100%

- - · - :J--(l8d) Reportes de Acreencias Manuales (6d)

Evaluación de Interfase o ¡ Migración de Fincas (4d)

(8d) ._. .... , -·de ,,,:....1

Implementar Módulo de Ingresos �==========�

al 50% (18d)

Implementar Módulo de Obligaciones Manuales al 100o/o

(18d)

Módulo de Egresos al 50% (18d)

Implementar Módulo de Tesorería al 100% (15d)

Migrar o Interfasear Fincas (10d)

Reportes de las Obligacones Manuales (8d)

Implementar Registro de J Compras (5d) __J

Implementar Módulo de Estados de Cuenta al 50% (Sd)

..,,, ... del-·�.,,..,., J(Sd)

Migraci6n,-Interfase o orporación del Pago Masivo

Andlisis (�---�

EdeT=�·<�J

�============-----------------

Pruebas Integrales para la Etapa I (12d)

--=

Implementar Etapa 1 (5d)

20 Agosto 1999 (YM)

xPB 11 xAG

Dlllff

D1a110

Oll111

Dl11t2

011111

Diltt•

º" ttl

o•u•

0•111

D11111

0111tt

011120

011 tt1

Dll 122 DII 123

01112'

DIIUI

DIIUI

Ola 121

011 ttt

011121

011, ..

0111,1

o .. ,u

011, ..

0111 ..

D11131

DlltM

D11117

Dll1 ..

Ola ...

Ola ...

D11M1

Dll 142

DIIM3

Ola ...

Ola ...

Ola ...

D11147

011, ..

DII ...

011100

Ola,,,

0111'2

Dll 1',I

º""'

0111U

011111

Dll 117

Oll 1'1

Ola ... Di11&1

061111

º""'

Dll1G

Ola ...

Ola ...

Dll1M

D11111

Dll 1'1 Ola ..

D1117t

0.171

Dll 112

DII 173

Dta174

Dll 111

Dll 111

Dll 177

D111Jt

Oia17t

DiatlO

D11111

º""'

011 m

Dll 111

Ola ...

Dll1N

Dll 111

º"*

0111N

OIIIN

DII tlt

D11112

Dll1tJ

Dll1N

D11111

DIIIN

Dll 117

D11111

°"'"

º"'""

Dll 201

DIII02

D11203

D11204

D112H

0112H

Ola ffl

Implementar Módulo de Ingresos

50% foltonte (16d)

Implementar Módulo de Agentes

ol 100% (20d)

Implementar 50% foltante del

Módulo de Egresos (18d)

Implementar Módulo Financiero ol

100o/o (25d)

Implementar Módulo de

Anulociones al 100% (25d)

Reportes de Ingresos Faltontes

(9d)

�.

EDI-Boncos (20d)

Reportes de Agentes (9d)

Implementar Pogo Mosivo (20d)

___J

�--�� Faltonte de los Estados de Cuenta

(10d)

�

--

Corga de Dotos

---� --·----

1 Migroeión de Flujo de Caja (20d)

- --

Cargo Automático (20d)

¡ 1

Access-Cobronzos

_j

Otat•

0112"

011110

1*111

0112'2

0112'2

01121'

DIIHI

,..n,

... Uf

... l ..

Dla21t

... no

Olol21

011222

01122>

01122<

011221

01am

Ola227

,..m

... m

Oto ...

01"2SI

... ,...

OtolS>

01o ...

otam

......

111on1

......

Ollnt

OIIMI

011:141

0111<2

0111<2

Olol<f

011:141

,----------------------------- ----- · ·----. ·------------· ----- ··--·¡

Pruebas Integrales de la Etapa II (22d)

Implantación de la Etapa II (15 d)


Propuesta del Funcionamiento de la I Etapa del

Nuevo Sistema Financiero de PPS

O

0

-u.

- �-

::::,

o�

<(

ffi

ll.

� a.

¡j PACIFICO

Peruano Suiza

.

' RVasquez Reaseguros

·-'-�

MAbad Adelantos

�, Otros

JMorcín

Economato

A:VQ� Cea seguros

FAlfajeme Fincas

OYacila Salvamentos-Autos

FQuezada Recuperos-Autos

�- ; JLayseca· · Sel'."ficiós Groles

Sgte

- .; .·, ...

A creencias

Manuales

...__,., >.Pi�

Registro de Ventas

•Relación de Ingresos

•Facturas/ Boletas

•Notas

•Relación d1! Egresos

•Facturás 1 Boletas

•Notas

...

o

o

-ro

LL

.!:::!

�

-(f)

o

o

e

<t

m

�

,_

a..

(l.)

a..

e


Hoja de Costos para la "Implementación del

Nuevo Sistema Financiero de PPS"

Propuesta Y Muñoz

CONSIS ... Programación de mod,f,coc,one:s e.n Módulos CONSIS RBarredo ... Reoortes. f>OQo Masivo, EOt, Est Cuento. i::l:e.Q de Comoros v Ventas

ISEGRIMSA ... �o de Datos IDEASA ... de o. Telestot. Access-Cobranzos. C

1 Desembolso Men sual

o Automót,co

Propuesta Inicial

FluJO

11 Sep t. 99

11 Oct. 99

11 Nov . 99 11

9.300 .00 9,300 00 9,300.00

1.800 00 1,800.00 1,800.00

1 i 11.100.00 11 11,100.00 1111.100.00 11

Dic. 99 11

9,300.00 1

1,800.00 1

l 1

11,100 .00 11

Total 99 11 E ne. 2000 11 Feb. 2 00011 Mar.20 0011 Abr. 20001 1

May.2000 11 J!Jn. 2000 11

37 .200 .00 1 9,300 00 9,300 00 9,300.00 9,300.00 9,300 00 9,300.00

7, 200.00

1 1.800.00 1,800.00 1.800.00 1,800.00

-,

44,400 .00

1 2,000.00 2.000.00 2,000.00

2,000.00 2,000.00 2.000.00

11 11 .100 .00 1115,100 .00 1115,100 .00 1115,100 .0011

1,800.00

2,000.00

2,000.00

1 5,100 .00 11

1,800.00

2,000.00

2,000.00

1 5,100 .00 11

11

Sep t. 9 9 :e==================�

11 Oct. 99 1 �I _No_v. _99�1 I Dic. 99 l l

�=To=ta=I 9=9

�11 Ene. 2 000 11 Feb. 200011 Mar. 200011 Abr. 200011

May. 2000 11

Jun. 2000 11 CONSIS ... Pr ramoc1ón de mod1f1coc10nes e.n Módulos CONSIS

IOpensoft ... Reportes. Cargo de. Datos IDEASA ...

9.300 00 9,300.00

4,000.00

Pago

9,300.00 9,300 00 37 ,2 00.00

4,000.00 4,000 00 12 ,000 .00

M05,vo, Corgo Automátóco. EDI Bancos . Flujo de CoJa. Telestat, 2.500 00 2,500.00 2,500.00 7, 500.00

Access-Cobron1os. j

9,3 00.00 9,300.00 9,300.00 9,300 00

4,000.00 4,000.00 4,000.00 4,000.00

2,500.00 3.500.00 3,000 00 3.500.00

Jul. 2000 11 Total 200011 Total Gener al

1 9,300.00 r 6!5.100.00

1 102 ,300 .00 J

1,80 0.0 0 112 ,600 .00 1 1 9,800 .00

1 ! 12 ,000 .00 1

1 2,000.00 12 ,000 .0 0

l_______j

2,000.00 12 ,000 .00 12,000 .00 1

15,100 .00 J ! 101.100 .0011 146 ,100.00

Total GeneralJul. 2000 11 Total 200 0 11 :e======�

1 37,200 .00 11 74,400 .00

1 1�' ====!

16 ,000.00 1 28 ,000 .00

112 ,500 .00

. 20 ,000 .00

ISEGRIMSA ...1.soo.00 1.soo.00 1.soo.00 1 �.500.00 2,000.00 2.000 00 2.000.00 2.000.00 8 ,000 .00 ' 1 12 ,500 .00

�·- . �-=======

�1::e�:!:'�=T="�=�=e=�=:=;;=�·===============�I ____ ---

-1.000.00 1,000.00 1 2 ,000 .00

---

� ---- ----. 0 .00 ,.1 ____ 2=·º=º

=º .. ·º ..

º---

I.__D _e_se_ m_ b _o,_so_ M_ e_n _su_ a_l __________ __,11 9,300 .00 [ ¡ 17 , 300 .00 1118,300.00 1118,300 .00 11 63 .200 .00 1117 ,800 .00 11 18,800.00 1118.300 .00 1 � �� --,.,..�

1 73 ,700 .00 11 .. _1 _3 _6_.9 _00_. _ºº _ __.

�D-if_er_e_n c_ia_e_nt_ re_"P_ro_p_ue_st_ a _Y_M_"_Y_"P_ro_ p _ue_ st_a_I_ni_ci_al_" � 1: í,800.�: 1 f-�.�_c:o:6?·1 l'.�7,Í!Oó:�:¡ ¡;;=1 ;2�.�:j ¡:: -'.��:,��oo-�J ¡::�:,�:� :j 1)}7oo:bóJ r :J-,iQO��'l l�:�:7oq;�, 1 · }�)ób.�.J k��.1�:�-'.j ! b)_�:�'._j ¡,;�:8:(!00.�b:l fü::�_'. ;�_�2�.q:;:;�

Propuesta para Finanzas

CONSIS ... Proqromoc1ón de mod1f1coc,ones en Módulos CONSIS RBar reda + Opens of t ... Rcoorte.s, Poao Mos,vo. EDt, Est Cuento, A.ea de Compres v Vcntos IDEASA ... Mos,vo. Cargo Automót,co. EDI Boncos, FluJO de Cojo. Telestot . Access-Cobr"onzos

¡sEGRIMSA ... Cargo de Datos

¡soUTHNET ... R,q,s,ro de V<nt05

Pago

11 Sep t. 99 11

9.300 00

Oct. 9 9 11 Nov. 99 11

Dic. 99

9.300 00 9.300.00 9,300.00

4,000 00 4,000.00 4,000 00

2,500.00 2,500.00 2,500.00

1,500 00 1,500 00 1,500 00

1,000 00

11 Total 99

1 37,200.00

11 E ne.2000 11 Feb. 200011

Mar.200011 Abr. 20001 1 May.2000 11 Jun. 2 000 11

1 9.300 00 9,300 00 9,300 00 9.300.00 9,30000 9.300 00

112.000 .00 1 4,000 00 4,000 00 4,000.00 4,000.00 4,000.00 4,000.00

1 7,500.00 J 2,500.00 3,500.00 3,000 00 3,500.00

----, ! 4,500.00 2.000.00 2.000 00 2,000 00 2.000 00

Jul. 2000 11 Total 200011

9.300.00 65 ,100.00 11

4,000.00 1 1 28 ,000 .00 1 1

¡ 12.500 .00 ¡ 8 ,0 00.00

,-

0 .0 0

Total General

102,300.00

40 ,000 .00

20 ,000.00

12 ,500.0 0

2,000 .00

1 Desembolso Mensual 9,300 .00 J

l 11 ,300.0 0 1 18,300.00 1

1.000 00 ! 2 ,000.00

18 ,300 .00 1 63 ,200.00 11 17 ,800 .00 1 18.800 .00 I J 18.300� 18 .800 .00 11 3,300 .00 l l 13 .3� 113 ,300 .00 1113,600 .001 ... 1 __ 1,_6_.s _ oo_.o_o _ _,

D iferencia entre "Pro p . Inicial" y "Prop, xa Fin anzas" jl '.o.bó'.;:.¡ [f,}j>.��--A L:!,ó:c¡q);;·11·:: ·;. '�,o63J f{,7%.$,;:�;·� F"ó:oo'':] r' � '.o:c>of ::1 t-<o.@; :.11> d.�o :. -'11 :13,300:0011-13,30Ó.ooj ¡ :13)00001 !.-39,900.00 ·¡' �--------------------' .·/!.: •jt/_ ��,/• .,! .. ,..-.] l/ .:• -J•,,. _ _ .':',_<-: _•1,,.j [,,,:",.:;:., ,.:.:í,'•�,J .·,�.:·�·: • ', t�(� ',,;�-�_>,..-:':A�,•: • ,; ,,.,,,., ' ' �--� :�,·---�

universidad nacional de ingenieríacybertesis.uni.edu.pe/bitstream/uni/7859/1/muñoz_my.pdf ·...

Documents