SOLICITUD DE INFORMACION (RFI-REQUEST FOR · PDF file- El proponente debe acreditar...

POSITIVA COMPAÑIA DE SEGUROS S.A./ARP

-Gestión Documental-

Código: VFA-RE-SI (RFI)-03

FORMATO SOLICITUD DE INFORMACION (RFI)

Fecha: 14/11/2014

Proceso Gestión de Aprovisionamiento

Pàgina 1 de 52

1

SOLICITUD DE INFORMACION (RFI-REQUEST FOR INFORMATION) PARA INSCRIBIR

PROVEEDORES DE SERVICIOS Y/O PRODUCTOS

RFI No. 007 de 2016 CATEGORIA A CONTRATAR: SERVICIOS TECNOLÓGICOS

Descripción: La pluralidad y deficiencia en la interoperabilidad de los aplicativos para la gestión del back office de la compañía, en el ramo de Riesgos Laborales, ha ocasionado inconvenientes en el gobierno y la administración de la información, afectando así los procesos misionales que interactúan en el ramo. Es por esto que Positiva Compañía de Seguros está interesada en realizar un estudio de mercado con el fin de buscar una solución eficaz a esta problemática, que sea capaz de integrar la operación de los procesos misionales relacionados con el ramo de Riesgos Laborales, cubriendo las necesidades actuales del negocio, a través de una (1) aplicación, que permita fortalecer el esquema de gobierno de los datos y sistemas de información.

CONFIDENCIAL Información a los participantes Positiva Compañía de Seguros S.A., es una Sociedad Anónima con régimen de Empresa Industrial y Comercial del Estado, integrante del sector financiero cuyo objeto social es el Aseguramiento de personas. Actualmente La Compañía, adelanta su proyecto de Abastecimiento Estratégico con el objeto de evaluar diversas oportunidades de optimización de costos relacionados con el Servicio que presta a nivel nacional, a través de mejoras en la relación con los proveedores. El proceso tiene como objetivo realizar una consulta de mercado para seleccionar y certificar a los proveedores que posean las mejores prácticas referentes a: condiciones técnicas y comerciales, para prestar el servicio requerido por Positiva Compañía de Seguros, proveedores que por su calidad y oportuna respuesta ofrezcan las mejores oportunidades de ahorro y de optimización del servicio para conformar la base de datos de Positiva.

El presente documento tiene como objetivo principal evaluar bajo los mismos parámetros y condiciones a todas las empresas participantes del proceso. A través de este documento de Solicitud de Información se establecen los parámetros y elementos de evaluación de servicios y productos de aquellos proveedores que en un futuro podrán ser llamados a un proceso de contratación con Positiva Compañía de Seguros.





Fecha: 14/11/2014


Pàgina 2 de 52

2

Proceso de inscripción Para participar en este proceso de inscripción, el proveedor debe leer detenidamente el presente documento con su anexo. Una vez comprendida la naturaleza del mismo, deberá ingresar a la página WWW.POSITIVA.GOV.CO en el aparte de contratación / registro de proveedores y registrarse en GESCONT aportando la información allí solicitada, posteriormente y antes de 02 de marzo de 2016 enviar un correo electrónico a [email protected] manifestando haber hecho el registro, el asunto debe ser: RFI CATEGORIA SERVICIOS TECNOLÓGICOS 007 de 2016 – PROYECTO DE INTEGRACIÓN OPERACIONAL ARL.

La omisión de este requisito será interpretada como la declinación del proveedor a esta solicitud de información. Las comunicaciones recibidas después de la fecha señalada no serán tenidas en cuenta, se aclara que en esta etapa NO se reciben documentos por otros medios diferentes a GESCONT.

Documentos requeridos

Durante el proceso de inscripción, se le solicitará información general y de carácter jurídico, tributario, financiero, técnico y comercial. Estos documentos serán validados por la Compañía como parte del proceso de creación de la base de datos de posibles proveedores de Positiva y en caso de ser seleccionados para un proceso contractual, constituirán soporte informativo y documental

De igual manera, en caso de llegar a una contratación, podrá validarse la información en visita que haga el supervisor a las instalaciones del Proveedor durante su ejecución.

La información obtenida servirá como elemento de evaluación para invitar a los proveedores certificados a los procesos de contratación que adelante Positiva Compañía de Seguros S.A.

Los parámetros a considerar dentro de la evaluación para certificar un proveedor son los siguientes:

Capacidad técnica y de servicio.

Información comercial

Aspectos jurídicos y Financieros

Cumplimiento de requisitos ambientales, de seguridad industrial y salud ocupacional

mailto:[email protected]





Fecha: 14/11/2014


Pàgina 3 de 52

3

Documentos jurídicos:

Deben allegar los siguientes documentos, al siguiente correo: [email protected] o [email protected]

1. CERTIFICADO DE EXISTENCIA Y REPRESENTACIÓN LEGAL (CAMARA DE COMERCIO) Vigencia no superior a 30 días calendario, contados a partir de la fecha de radicación de la propuesta.

2. ESTADOS FINANCIEROS, CERTIFICADOS de los dos (2) últimos años,

Términos de Confidencialidad

Este documento de Solicitud de Información y cualquier otro documento adicional que sea diligenciado e ingresado por ustedes durante este proceso, son considerados y se les dará tratamiento de información confidencial, por parte de Positiva Compañía de Seguros.

De igual manera, usted acepta no reproducir copias de ninguna sección de este documento, o revelar o distribuir información del mismo a terceros o utilizar la información confidencial para otro propósito más que para elaborar su respuesta.

El proveedor acepta adherirse a los lineamientos y requerimientos establecidos en el presente documento así como a las fechas de entrega establecidas.

Positiva Compañía de Seguros S.A. se reserva el derecho de seleccionar aquellos proveedores que considere calificados para participar en sus procesos contractuales. Igualmente puede descalificar cualquier proveedor cuando así lo considere sin incurrir en ningún tipo de obligación.

Requerimientos mínimos exigidos

Es importante resaltar que el proponente debe tener experiencia específica igual o superior a (3) tres años en compañía de seguros que tengan habilitado el ramo de riesgos laborales en Colombia.

El proponente puede optar por (2) dos alternativas para seleccionar y dar respuesta a las que estén en condiciones de ofertar. La cual debe dar respuesta a cada una de las necesidades formuladas. El proponente tiene libre elección de escoger cualquiera de las alternativas, dependiendo de la naturaleza de su negocio, optando por presentarse a una (1) alternativa o a las dos (2).

Para los oferentes que opten por la opción (B), adicional a lo ya expuesto deben relacionar las organizaciones donde tienen en operación su aplicación, precisando:

Razón social Módulos en operación Tiempo que tiene la aplicación en servicio Volúmenes de las transacciones promedio mes

Así mismo detallar metodología, costos, tiempos y volúmenes de datos migrados exitosamente en proyectos similares objeto de este RFI.







Fecha: 14/11/2014


Pàgina 4 de 52

4

Alternativa (A): Software a la Medida

- El proponente debe especificar la metodología de Ingeniera de software que aplicará en la ejecución del proyecto.

- El proponente debe especificar la metodología de gestión de proyectos que aplicará para le gestión del proyecto.

- El proponente debe presentar los roles y sus respectivos perfiles del equipo de trabajo que desarrollará el proyecto

- El proponente debe especificar la metodología propuesta para la estimación de esfuerzos.

- El proponente debe acreditar certificación CMMI nivel 3 como mínimo. - El proponente debe indicar los costos unitarios de ingeniería de software. - El proponente debe acreditar experiencia en integración de aplicaciones. - El proponente debe estimar los tiempos de desarrollo de cada uno de los módulos

solicitados.

Alternativa (B): Licencia de Uso

- El proponente debe especificar la metodología de gestión de proyectos que aplicará. - El proponente debe especificar los roles y sus respectivos perfiles del equipo de trabajo

que desarrollará el proyecto. - El proveedor debe presentar su modelo de soporte y mantenimiento de la solución. - El proponente debe especificar el modelo de mesa de ayuda soportado en herramientas

de software especializadas para este servicio. Se debe presentar documento que describa este servicio, indicando los niveles de escalamiento y ANS.

- El proponente debe especificar la metodología propuesta para la estimación de esfuerzos.

- El proponente debe acreditar certificación CMMI nivel 3 como mínimo. - El proponente debe especificar el modelo de licenciamiento del software. - El proponente debe especificar el costo del soporte y mantenimiento. - El proponente debe especificar el modelo de servicio y costo de personalizaciones. - El proponente debe especificar los requerimientos de licenciamiento adicionales y

necesarios para operar la aplicación. - El proponente debe especificar la metodología propuesta para realizar la migración de la

información histórica de la compañía a la aplicación. - El proponente debe detallar los costos de la migración de datos propuesta, del sistema

actual a la aplicación ofertada.

Independiente de la alternativa escogida para presentar oferta de parte del proponente, este deberá presentar los costos desglosados asociados a la solución tecnológica presentada.





Fecha: 14/11/2014


Pàgina 5 de 52

5

Para aclarar cualquier duda relacionada con el proceso y las condiciones presentadas en este documento, favor remitir sus interrogantes al correo [email protected], el asunto debe ser: SOLICITUD DE ACLARACION RFI CATEGORIA SERVICIOS TECNOLOGICOS 007 de 2016 – PROYECTO DE INTEGRACIÓN OPERACIONAL ARL.

Si está interesado en participar en este proceso debe dirigir la documentación hasta del día 16 de Marzo de 2016, hasta las 3:00 p.m. en la (Avenida Carrera 45 No. 94-72 piso 1, dirigida a la (Gerencia del Producto A.R.L).

Agradecemos su participación.

(Original Firmado) (Original Firmado) MARTHA LUCIA CEPEDA M. FABIO FLOREZ G. Vicepresidente TIC Vicepresidente Operaciones (Original Firmado) (Original Firmado) MAURICIO GAVIRIA S. CHARLES BAYONA M. Vicepresidente Negocios Vicepresidente Técnico

(Original Firmado)

SANDRA REY TOVAR Gerente de Compras y Contratación

Anexo: DOCUMENTO FUNCIONAL Y TECNOLÓGICO PROYECTO INTEGRACIÓN OPERACIONAL ARL – 45 folios






Fecha: 14/11/2014


Pàgina 6 de 52

6

Control de Cambios

N° Descripción del Cambio Fecha del Cambio

Quien Aprueba el Cambio (Cargo)

Versión Anterior

1 Se adicionan documentos a solicitar 13/11/2014 Sandra Cecilia Rey T. 3





Fecha: 14/11/2014


Pàgina 7 de 52

7

ANEXO

INTEGRACIÓN OPERACIONAL ARL

1.1 DEFINICIONES FUNCIONALES GENERALES PROYECTO INTEGRACIÓN OPERACIONAL ARL 8

1.1.1 Objetivo del Proyecto .................................................................................... 8 1.1.2 Alcance del Proyecto .................................................................................... 8

PRIMERA FASE .............................................................................................................. 10 1.2 MÓDULO AFILIACIONES ........................................................................................ 10 1.3 MÓDULO NOVEDADES .......................................................................................... 11 1.4 MÓDULO RECAUDO ............................................................................................. 12 1.5 MÓDULO CARTERA .............................................................................................. 13 1.6 PORTAL TRANSACCIONAL POSITIVA – MÓDULO OPERACIONES ............................... 14 SEGUNDA FASE: ............................................................................................................ 16 1.7 MÓDULO PROMOCIÓN Y PREVENCIÓN ................................................................... 16 1.8 MÓDULO SINIESTROS .......................................................................................... 16 1.9 MÓDULO AUTORIZACIONES .................................................................................. 17 1.10 MÓDULO RESERVAS ............................................................................................ 19 1.11 MÓDULO PRESTACIONES ASISTENCIALES ............................................................. 21 1.12 MÓDULO PRESTACIONES ECONÓMICAS ................................................................ 21 1.13 MÓDULO ESTABLECIMIENTO DE BENEFICIARIOS .................................................... 23 1.14 MÓDULO DE PAGO DE PENSIONES ........................................................................ 24 TERCERA FASE ............................................................................................................. 25 1.15 MÓDULO DE MERCADEO ...................................................................................... 25 1.16 MÓDULO CANALES .............................................................................................. 29 1.17 MÓDULO PRODUCTO ARL .................................................................................... 37 2. SITUACIÓN TECNOLÓGICA ACTUAL ................................................................. 42 2.1 ARQUITECTURA DE SOFTWARE .................................................................... 44 2.2 ARQUITECTURA INICIAL DE SOFTWARE ................................................................. 46 2.3 ARQUITECTURA EVOLUTIVA DE SOFTWARE ........................................................... 46 3. ALTERNATIVAS DE SOLUCIÓN TECNOLÓGICA CONTEMPLADOS ................. 47 3.1 ALTERNATIVA DE SOFTWARE A LA MEDIDA ................................................. 47 3.2 ALTERNATIVA DE LICENCIAS DE USO ........................................................... 50





Fecha: 14/11/2014


Pàgina 8 de 52

8

DOCUMENTO FUNCIONAL Y TECNOLÓGICO PROYECTO INTEGRACIÓN OPERACIONAL

ARL

Este documento recopila los requerimientos funcionales y tecnológicos de cara al Proyecto de Integracion Operacional ARL – (PIOARL)

1.1 Definiciones Funcionales Generales Proyecto Integración Operacional ARL

1.1.1 Objetivo del Proyecto

Integrar la operación de los procesos misionales relacionados con el ramo de riesgos laborales, cubriendo las necesidades actuales del negocio, a través de una (1) aplicación web, que permitan fortalecer el esquema de gobierno de los datos que afectan al ramo de ARL y sus sistemas de información.

1.1.2 Alcance del Proyecto

Evaluar, diseñar e implementar una (1) solución integral, compuesta por las etapas del producto ARL; Prospectación de Clientes, Sustentación de Propuestas Comerciales, Producción, Administración del Riesgo y Reconocimiento; que le permita a POSITIVA realizar la gestión de los procesos asociados al ramo de riesgos laborales dando cubrimiento a la operación de manera transversal. Para una mejor ilustración en la gráfica se observa cada una de las etapas del producto ARL con los procesos misionales.

Gráfica 1 – Etapas del Producto ARL

Como parte de la integración operacional de estos procesos misionales, igualmente se busca que las empresas clientes accedan e interactúen con cada uno de estos procesos a través de un portal web transaccional de la compañía, en primera instancia se realizará en los frentes de Operaciones que incluye la generación de afiliaciones, expedición de certificados y carnets, el





Fecha: 14/11/2014


Pàgina 9 de 52

9

ingreso de novedades y consultas de recaudos. El frente de Promoción y Prevención, permitiéndole al cliente realizar seguimientos a sus planes de trabajo, el registro y control del ausentismo laboral, solicitud y consulta de la reclasificación de empresas y trabajadores y, la consulta e investigación de los accidentes de trabajo. Y el frente de Gestión de Siniestros, que le permitirá a la empresa cliente realizar el seguimiento a los eventos reportados así como a sus incapacidades temporales.

Gráfica 2 – Portal Transaccional Positiva

El proyecto se tiene contemplado realizarlo por fases, teniendo en cuenta el volúmen de operaciones que el ramo de riesgos laborales maneja y las distintas integraciones transversales que debe tener cada uno de los módulos.

Gráfica 3 – Integración del producto ARL

A continuación describimos funcionalmente las necesidades de cada uno de los módulos que tendría la herramienta, así mismo la integración de los procesos misionales dentro del producto ARL por las fases de ejecución del proyecto.





Fecha: 14/11/2014


Pàgina 10 de 52

10

PRIMERA FASE: Esta primera fase del proyecto contempla el desarrollo de la etapa del producto ARL de PRODUCCIÓN, donde se cubre el proceso de Gestión de Producción, así como el portal web transaccional en su frente de Operaciones.

1.2 Módulo de Emisión (Afiliaciones)

En este proceso se tiene cuatro grupos poblacionales que son: - Empleadores

- Contratantes

- Trabajadores Dependientes

- Trabajadores Independientes

Los estados de afiliación son para: - Empleador

o Afiliado

o Desafiliado

- Trabajador

o Activo

o Inactivo

Este módulo deberá administrar (419.667) empleadores y (3.368.012) de relaciones laborales en las 32 Sucursales de la Compañía a nivel país (a corte Agosto de 2015). Así mismo debe soportar imágenes digitales de los documentos que se recepcióna en los 49 puntos de radicación de afiliaciones de la Compañía a nivel nacional. Es importante aclarar que la Compañía maneja la recepción de documentos físicos de afiliación de empleadores, trabajadores dependientes y trabajadores independiente a través de un tercero. Por lo cual los módulos deben permitir la transferencia de datos de la información estructurada y no estructurada (imágenes documentos) recibida en estos puntos a los módulos. Durante el primer semestre del año 2015, se recepciónaron en los 49 puntos a nivel país 4.781 registros de afiliaciones de empleadores. Las afiliaciones de trabajadores dependientes e independientes es de 280.039, las cuales se capturan de forma simultánea por ventanilla y página web. Durante el periodo de Enero a Agosto de 2015, los registros mensuales promedios de afiliaciones de trabajadores dependientes e independientes fueron de 280.039 y retiro fue de 247.275 mes. Así mismo el módulo debe crear la póliza de cada empleador y trabajador independiente no vinculado, conforme a los criterios definidos la cual es única por cada empresa cliente y debe alimentar la información de la liquidación de aportes para su posterior recaudo. Tomando como base las relaciones laborales asociadas a cada póliza, salario base de cotización y la respectiva tasa según la actividad económica. En las relaciones laborales el módulo debe tener la traza por siniestro (Accidente de Trabajo o Enfermedad Laboral) reportado y por cada uno de los empleadores y contratantes existentes en





Fecha: 14/11/2014


Pàgina 11 de 52

11

la base de datos. Así mismo los trabajadores deben existir una sola vez dentro del sistema e interactuar con los distintos módulos donde se requiera la información del trabajador. Por último el módulo debe liquidar los aportes de cada una de las pólizas activas con sus relaciones laborales existentes, con el fin de conocer el valor de la liquidación de aportes a recaudar en cada periodo.

1.3 Módulo de Emisíón (Novedades)

Las novedades que manejaría este módulo son las de empleadores, contratantes, trabajadores dependientes y trabajadores independientes. Novedad de Empleadores y Contratantes: hace referencia a las de retiro, ya sea por depuración de bases de datos o por procesos de traslado a otras ARL dentro del sistema general de riesgos laborales, los promedios al mes de estas novedades entre el periodo enero a agosto de 2015 fueron de (3.890). Novedades Trabajadores Dependientes e Independientes: se presentan de dos tipos, permanentes y temporales. Son informadas a la Compañía por los empleadores en puntos de atención 68.893, página web 280.877 y por planilla PILA 404.137 trámites que incluyen cambio de salario y retiros. Así mismo se debe poder programar ingresos y retiros de trabajadores. Es importante enfatizar que la aplicación de las novedades permanentes afectan el estado de la afiliación de la población en la base de datos de Compañía, por lo cual debe estar actualizado en tiempo real, para consulta interna de Positiva y de los empleadores a través de la página web.





Fecha: 14/11/2014


Pàgina 12 de 52

12

Gráfica 4 – Módulos Afiliación y Novedades

1.4 Módulo Recaudo

En este proceso el módulo debe gestiónar el recaudo de las primas esperadas, liquidadas por el módulo de afiliaciones, con el fin de conocer la produccción mes a mes de la compañía por el ramo de riesgos laborales. Los volúmenes promedios que se debe gestiónar son:

o Setecientos mil (700.000) Archivos PILA promedio mes.

o Ochenta y cuatro (84) archivo de Log Bancario - (4 diarios x 21 días hábiles promedio)

o Tres cientos cincuenta (350) formularios de autoliquidación por el Sistema General de

Participación promedio mes.

El módulo debe gestiónar las certificaciones de recaudo, con las relaciones de pago por aportantes y cotizantes. La consulta de las certificaciones deben estar disponibles adicionalemente en la página web de la Compañía.





Fecha: 14/11/2014


Pàgina 13 de 52

13

Así mismo se debe controlar en el módulo temas como: - Liquidación aporte Fondo de Riesgos Laborales

- Devolución de aportes

- Correcciones de recaudo

- Aporte sin póliza vinculada

- Conciliaciones bancarias de la información con la gerencia financiera de la compañía

1.5 Módulo Cartera

Frente al tema de cartera, el módulo debe realizar el seguimiento y traza de las deudas en sus distintas etapas; preventiva, constitución mora, pre juridica y coactiva, con el fin de llevar el control detallado de las primas esperadas, conforme a la liquidación de los aportes en ARL. Adicionalmente se debe manejar el ajuste de la cartera de los empleadores teniendo en cuenta las novedades PILA reportadas y retiros que se presenten, ya sea por depuración de bases de datos o traslados a otras ARL´s. Igualmente controlar los distintos procesos concursales que se presenten por liquidación, restructuración o daciones de pago de empleadores. Así mismo contemplar el control y visualización de las acciones de cobro normativos, como Constitución en Mora, Avisos de Incumplimiento y demás acciones de cobro que los entes de control requieren frente a las normas vigentes. Por último el módulo debe controlar las cuentas corrientes de los distintos intermediarios que tenga la Compañía vinculados, con el fin de registrar la liquidación de comisiones de las claves de cada uno de ellos, conforme a las pólizas recaudadas intermediadas a nivel país de acuerdo a la red comercial de la compañía. Es importante que el módulo tenga en cuenta las notas de autodescuentos generadas por reconocimiento de incapacidades temporales en el módulo de prestaciones económicas, para alimentar la cuenta corriente de los intermediarios.





Fecha: 14/11/2014


Pàgina 14 de 52

14

Gráfica 5 – Módulos Recaudo y Cartera

1.6 Portal Transaccional Positiva – Módulo Operaciones

El portal web transaccional de la compañía debe ser flexible y escalable con el fin de facilitar a nuestras empresas clientes el acceso al producto ARL. Los módulos que inicialmente deben contemplar el portal son:

- Operaciones

- Promoción y Prevención

- Gestión de Siniestros





Fecha: 14/11/2014


Pàgina 15 de 52

15

Gráfica 6 – Módulos Oficina Virtual – Portal Web Positiva

Los procesos misionales que interactuarían con los módulos de la pagina transaccional son: - Promoción y Prevencion

- Revision, Verificación y Calificación del Siniestro

- Autorizaciones

- Prestaciones Económicas

- Prestaciones Asistenciales

El volúmenes que se han manejado (año 2015) en el página web del tercero son: - 260.000 tramites mes

- 250.000 usuarios

La solución tecnológica propuesta ya sea en la alternativa A o B deberá tener un componente de interacción entre los asegurados y Positiva Compañía de Seguros; esto se traduce en la construcción e implementación de un portal transaccional en ambiente web donde las empresas cliente tendrán la capacidad de realizar distintas operaciones propias de cada proceso misional del ramo de riesgos laborales de la compañía. Así mismo el portal debe tener la facilidad de cargas imágenes de documentos que los usuarios alimenten y diligenciamiento de formularios.





Fecha: 14/11/2014


Pàgina 16 de 52

16

SEGUNDA FASE: Esta segunda fase del proyecto, contempla el desarrollo de las etapas del producto ARL de ADMINISTRACIÓN DEL RIESGO y RECONOCIMIENTO, donde se abordan los procesos de Gestión de Promoción y Prevención, Gestión Actuarial y Gestión de Siniestros.

1.7 Módulo Promoción y Prevención

Es importante precisar que el módulo de promoción y prevención se encuentra desarrollado actualmente por la compañía en las aplicaciones web Gestpos y Seguir, por lo cual la necesidad funcional es lograr integrar la gestión que se desarrolla en las distintas modalidades de atención en los aplicativos existentes. La integraciones que se requieren es:

- Polizas ARL

- Relaciones laborales

- Liquidación de aportes

- Recaudo ARL

- Cuenta corriente intermediarios

- Siniestros

Las empresas atendidas a corte 31 de agosto 2015 en las distintas modalidaddes es de (258.206)

- Modalidad de atención Regulares: 6.517

- Modalidad de atención Sectoriales: 14.256

- Modalidad de atecnión Educa: 5.171

- Modalidad de atención Comunica: 232.262

1.8 Módulo Siniestros

Este módulo inicia la gestión con los los distintos reportes de siniestros (accidente de trabajo y enfermedades laborales) que realizan cada uno de los empleadores (419.667) a nivel país de sus relaciones laborales (3.368.012). Una vez se recepcióne los reportes de siniestros por los distintos canales como son portal web, call center, línea movil, ventanilla, gerencia jurídica, retroactivos y dictamenes de EPS en primera oportunidad, se procede a realizar la calificación de origen del siniestro y su posterior valoración de la perdida de capacidad laboral (P.C.L). Los volúmenes que actualmente se manejaron en el periodo de Enero a Agosto 2015 fue de:

Reportes de accidentes de trabajo (FURAT): 16.089 mes

Reporte de enfermedades laborales (FUREL): 184 mes

Calificación de origen de los reportes FURAT: 15.925 mes

Califiación de origen de los reportes FUREL: 300 mes

Valoraciones de PCL: 11.802 mes

Notificaciones de dictamenes médico laborales: 691 mes

Controversias en las calificación es en primera instancia: 390 mes

Controversias en las calificación es en segunda instancia: 129 mes

Los usuarios que actualmente manejan la aplicación que realiza esta gestión en la compañía es de 200 usuarios interno de la Compañía y 400 usuarios externos (médicos calificadores).





Fecha: 14/11/2014


Pàgina 17 de 52

17

Es importante evitar errores de digitación de los datos de los reportes de accidente de trabajo y enfermedad laboral, por lo cual el módulo debe lograr integrar la información existente en la base de datos como:

Datos empleador o contratante

Datos trabajador (dependiente o independiente)

Así mismo la comprobación de derechos de los siniestros reportados, debe realizarse integrando la informacion (módulos de afiliacion y recaudo) de fechas de inicio y terminación de cobertura y relaciones laborales activas en la fecha de ocurrencia del evento (AT-EL). Es de anotar que el módulo debe permitir transferir la información de los AT-EL, recepciónado en los puntos de atención del front office administrador por un tercero.

1.9 Módulo Autorizaciones

Este módulo debe asegurar la correcta comunicación, asesoría, coordinación y gestión de las solictudes de asistencia médica requeridos por los asegurados (trabajadores dependientes e independientes) de la Compañia de acuerdo a pertinencia médica y dentro de los tiempos establecidos de acuerdo a su ubicación. Las solicitudes de autorizaciones las realiza:

- Empleador o Contratante

- Trabajador dependiente o independiente

- IPS red Positiva

Las autorizaciones médico asistenciales deben partir de la ocurrencia y reporte de un accidente de trabajo o enfermedad laboral (AT-EL) a la compañía y las distintas etapas son:

Asesorías

Orientación y direccionamiento de atención de urgencias, se realiza en el call center durante el reporte del siniestro. El módulo debe dejar trazabilidad de la asesoría dada al asegurado.

Recepción de la Solicitud

Mediante los canales dispuestos para la recepción como lo son; call center, portal web y puntos de atención. El módulo debe gestiónar las solicitudes de autorización médico asistencial (orden médica o fórmula con sus documentos soporte y reseña médica del día en que dictaminaron la orden), ingresadas mediante el diligenciamiento del formato (anexo tres(3)) en el aplicativo por proveedores, auditores técnicos de rehabilitación, profesionales de Casa Matriz o Médicos Laborales y empresas aseguradas. El sistema en la recepción de las autorizaciones debe identificar e integrar la información de:

Polizas ARL (empleador o contratante) Relaciones laborales Siniestros Calificación de siniestros





Fecha: 14/11/2014


Pàgina 18 de 52

18

Gestión de la solicitud

Las solicitudes de autorizaciones deben ser gestiónadas por el operador logístico (tercero) en los tiempos establecidos para cada ubicación:

- Ubicación urgencias 10 minutos

- Ubicación Hospitalización 1 Hora

- Ubicación Consulta y Servicios Selectivos 24 Horas

- Rehabilitación (ingreso al programa) 24 horas

Por lo cual el módulo debe realizar la trazabilidad de los tiempos y movimientos en la gestión de las solicitudes.

Coordinación y Seguimiento a las solicitudes

El tercero quien tiene a cargo los casos, realiza la coordinación y seguimiento a: - Tutelas - Juntas de Calificación - Casos Crónicos - Casos de empresas Oro, Platino y otras - Riesgo Biológico - Servicios de referencia y contra referencia - Análisis de puesto de trabajo para definir origen - Servicios de traslados urgentes, traslados de referencia y traslados no urgentes - Hospedaje - Coordinación zonas protegidas - Coordinación de polígonos empresariales - Solicitudes de asegurados revisión pensional

Entrega y/o notificación de la autorización

La respuesta a la solicitud, se realiza en el formato de anexo 4, entregando este formato diligenciado en los puntos de atención o notificándola a través de línea telefónica o página web al empleador.

Los volúmenes promedio mes de las autorizaciones asistenciales son:

Cuadro 1 Volúmenes mensuales – Autorizaciones asistenciales





Fecha: 14/11/2014


Pàgina 19 de 52

19

Por último los usuarios que actualmente manejan la aplicación que realiza esta gestión en la compañía es de 8 usuarios interno de la Compañía y 4709 usuarios externos. De las cuales 4276 corresponde a IPS de la red de Positiva.

1.10 Módulo Reservas

Este módulo debe admnistrar las reservas que por ley, se deben constituir la compañía para atender las erogaciones presentes y futuras de las obligaciones contraídas en virtud de su actividad como entidad aseguradora para el ramo de riesgos laborales. Las reservas para el producto ARL son:

Reserva matemática, cuyo volumen para septiembre de 2015 es de 3.472 causantes

Reserva siniestros ocurridos y avisados (SOA)

Cada mes se presentan siniestros nuevos a los cuales se les debe constituir una reserva inicial: para el año 2015 se tiene la siguiente experiencia de reporte de siniestros nuevos

Enero 14.416

Febrero 17.371

Marzo 17.897

Abril 16.263

Mayo 16.383

Junio 16.479

Julio 18.340

Agosto 16.654

Septiembre 19.083

Cuadro 2 Volúmenes mensuales – Reservas





Fecha: 14/11/2014


Pàgina 20 de 52

20

Con corte a agosto de 2015 el libro radicador de siniestros cuenta con 19.350.244 registros. Cada mes, la reserva de siniestros ocurridos y avisados presenta movimientos de ajuste, reconocimiento o liberación, con los siguientes volúmenes para lo corrido del año 2015:

Enero 230.667

Febrero 293.476

Marzo 257.574

Abril 214.086

Mayo 203.411

Junio 317.310

Julio 324.156

Agosto 310.558

Septiembre 358.868

Cuadro 3 Volúmenes mensuales – Reservas SOA

Es importante que el módulo de reservas administre:

Cálculo de la reserva matemática

Cálculo de la reserva de siniestros ocurridos y avisados (SOA)

Cálculo de la reserva especial

Cálculo de la reserva de desviación de siniestralidad

Cálculo de la reserva de siniestros ocurridos no avisados (IBNR) y cálculo de la reserva

de siniestros ocurridos y no suficientemente avisados (IBNER)

De igual manera se debe poder generar la información estadística Alimente los formatos 250, 251, 253 y 394 conforme a la Circular Externa 052 de 2002

de la Superintendencia Financiera de Colombia.

Circular 35 del 22 de septiembre de 2015 del Ministerio del Trabajo

Generación de estadísticas mensual de la reserva matemática correspondiente al

número y valor de reserva discriminada por invalidez y sobrevivencia, género y mesada

pensional; así como por año de causación de la reserva.

Un reporte mensual de la reserva de avisados, con el saldo de reserva en cada siniestro

por cada cobertura.

Un reporte de los movimientos presentados en el mes por cada cobertura afectada.





Fecha: 14/11/2014


Pàgina 21 de 52

21

1.11 Módulo Prestaciones Asistenciales

Este módulo debe gestionar las prestaciones asistenciales suministrada por las IPS como consecuencia de un accidente de trabajo o enfermedad laboral que presente un trabajador dependiente o independiente que esté asegurado en el ramo de riesgos laborales. Los diferentes funcionalidades que debe tener la aplicación son:

- Radicación de facturas asistenciales: Se realiza la recepción de la facturación de las

IPS a nivel nacional en las sucursales, lo cuales una vez registrado el dato y

capturada la imagen digital de los documentos para luego ser transferido para su

respectiva gestión en la compañía. Los volúmenes mensuales promedio es de

51.230 registros.

- Auditoría médica: Se realiza la auditoría médica y administrativa de las facturas

donde se determina su pertinencia para seguir el proceso de pago. Es importante

aclarar que esta actividad se realiza sobre la información radicada y transferida.

- Los volúmenes mensuales promedio es de 50.000 registros.

- Respuesta a glosas y Conciliación Medica: Se analiza los soportes para realizar el

levantamiento de glosas o llegar al acercamiento para la conciliación de las mismas

con los Proveedores o IPS. Los volúmenes mensuales promedio es de 800 registros.

- Certificación de Facturas: Se realiza la causación de las facturas y validación de

datos de los Proveedores. Los volúmenes mensuales promedio es de 50.000

registros.

- Soporte de Pagos: se realiza envio soporte de pago a los Proveedores para

descargar de las carteras. Los volúmenes mensuales promedio es de 4.000

registros.

- Conciliación de Cartera Proveedores: se realiza conciliación de cartera entre las

Partes. Los volúmenes mensuales promedio es de 100 registros

1.12 Módulo Prestaciones Económicas

Este módulo debe administrar las siguientes prestaciones económicas del producto de ARL: - Incapacidad temporal

- Indemnización por incapacidad permenente parcial (IPP)

- Auxilio funerario

Las prestaciones se originan de los siniestros ocurridos y avisados (AT-EL), por lo cual debe estar totalmente integrado este módulo con los procesos de:

- Afiliaciones

- Novedades

- Recaudo y Cartera

- R, V y Calificación de Siniestros

- Autorizaciones





Fecha: 14/11/2014


Pàgina 22 de 52

22

- Cálculo de Reservas

Las certificados de incapacidades temportales (IT) son radicadas a la compañía con el fin de reconocer la prestación económica como resultado de un accidente de trabajo o enfermedad laboral. Para lo cual se tiene dispuesto los siguientes canales de recepción:

- Portal web – oficina virtual

- Punto de atención – oficina física

Una vez ingresa las solicitudes de reconocimiento de la prestación por IT con sus respectivos soportes, se analiza la pertinencia médica y administrativa de las solicitudes de reconocimiento de Incapacidades Temporales que se radican en la Compañía con el fin de determinar el pago o negación de la incapacidad. Es importante mencionar que las radicaciones de las solicitudes que se realizan en los puntos de atención a nivel país, son gestionadas por el front office que es administrado por un tercero, por lo cual la aplicación debe permitir realizar la transferencia de datos de la información estructurada y no estructurada (imágenes documentos), recibida para su respectiva gestión en el proceso. La informacion que se recibe a través del portal web son datos e imágenes que el empleador o contratante carga, previa validación de los documentos soportes exigidos. Es importante que el módulo de prestaciones económicas en el ítem de incapacidades temporales, administre:

Recepcionar solicitudes de I.T con sus soportes digitales por el portal web

Permitir la transferencia de los datos e imágenes capturadas de las solicitudes de I.T en

los puntos de atención a nivel a la aplicación para su gestión.

Integrar las calificación es de origen realizadas por el módulo de siniestros y las

solicitudes de reconociemiento de IT.

Realizar Auditoría Médica a la IT para determinar la pertinencia del reconocimiento de la

misma

Aprobar o negar las solicitudes de reconocimiento de IT e informar automáticamente al

solicitante.

Liquidar las IT aprobadas para pago

Reexpedición de IT liquidadas para pago no efectivo

Elaborar y cerrar nóminas de pago de IT liquidadas. Modalidad cobro directo

Transferir información de la nómina a la aplicación fianciera para su pago por parte del

área contable.

Elaborar y cerrar nómina de autodescuentos por concepto de IT aprobadas y

reconocidas.

Crear y asignar notas de autodescuento. Así mismo tener la trazabilidad del total de las

notas generadas para ser el insumo en el módulo de recaudo y cartera.

Integrarse con el módulo de cartera, con el fin de cruzar las notas de autodescuento y

la liquidación de aportes de las Polizas de ARL.

Generar las comunicaciones automáticas con las notas de autodescuentos a los

empleadores y/o contrantes.





Fecha: 14/11/2014


Pàgina 23 de 52

23

Los volúmenes mensuales promedio actual es de 12551 registros de solicitudes de IT para reconocimeinto por AT-EL.

Las solicitudes de indemnizaciones de incapacidad permanente parcial (IPP) son radicadas en la compañía, a partir de la calificación de la pérdida de capacidad laboral (PCL) de un siniestro (AT-EL) que se encuentre en el rango de ≥5% y <50% de la calificación obtenida de PCL. Una vez se han entregado la documentación exigida para el reconocieminto de la IPP, en los puntos de atención de la compañía a nivel país; esta debe ser transferida (datos e imágenes de documentos) al módulo para su análisis de los casos de solicitudes, con el fin de realizar el pago o la negación (según sea el caso) de la Indemnización. Es importante que el módulo de prestaciones económicas en el item de incapacidades temporales, administre:

Permitir la transferencia de los datos e imágenes capturadas de las solicitudes de IPP

en los puntos de atención a nivel país a la aplicación para su gestión.

Integrar las calificaciones de origen y PCL realizadas por el módulo de siniestros y las

solicitudes de reconociemiento de IPP.

Realizar la decisión de las solicitudes de IPP.

Elaborar y cerrar nóminas de pago de IPP aprobadas.

Realizar reexpedición de IPP

Realizar negación de IPP e informar al solicitante.

Realizar la aprobación de IPP e informar al solicitante

Transferir información de la nómina a la aplicación fianciera para su pago por parte del

área contable.

Los volúmenes mensuales promedio actual es de 361 registros de solicitudes de IPP para reconocimeinto por AT-EL.

Las solicitudes de los auxilios funerarios derivados de la muerte del asegurado, como consecuencia de un accidente de trabajo o enfermedad laboral, son radicadas en los puntos de atención donde se capturan los datos e imágenes de los documentos físicos entregados como soportes a la solicitud, para su transferencia al módulo y decisión del pago o negación de la prestación económica. Los volúmenes mensuales promedio actual es de 27 registros de solicitudes de auxilios funerios.

1.13 Módulo Establecimiento de Beneficiarios

Este módulo debe administrar los beneficiarios de las siguientes pensiones como consecuencia de la ocurrencia de un accidente de trabajo o enfermedad laboral.

Pensión de invalidez

Pensión de sobrevivientes

Sustitución pensional

La radicación de los soportes para cada una de las pensiones anteriomente enunciada, se realiza en los puntos de atención a nivel país, que son gestionados por el front office que es administrado por un tercero, por lo cual la aplicación debe permitir realizar la transferecia de





Fecha: 14/11/2014


Pàgina 24 de 52

24

datos de la información estructurada y no estructurada (imágenes documentos), recibida para su respectiva gestión en el proceso. Es importante que el módulo de establecimiento de beneficiarios de pensión administre:

Con el lleno de los documentos exigidos y una vez validado los soportes entregado en

los puntos de atención, debe tener la funcionalidad para decidir sobre las distintas

solicitudes radicadas. Es importante integrar las calificaciones de origen y pérdida de

capacidad laboral de los distintos accidentes de trabajo o enfermedades laborales que

genera el derecho a la pensión.

Liquidar las distintas pensiones a causa de un AT-EL.

Los volúmenes de solicitudes de pensión promedio mensual es: - Pensión de invalidez: 21

- Pensión de sobrevivientes: 9

- Sustitución pensional: 11

1.14 Módulo de Pago de Pensiones

Actualmente Positiva se encuentra adelantando los trámites para que el Ministerio de Trabajo nos ceda los derechos para usar el SISTEMA DE NÓMINA DE PENSIONADOS –SNP- desarrollado por el proveedor CROMASOFT y de propiedad del Ministerio de Trabajo, el cual soporta actualmente el proceso de pago de pensiones del FOPEP y otras entidades del estado. Por lo anterior, se requiere que la aplicación que se adopte cuente con interfaces para recepción y envío de información desde y hacia la aplicación de pago de pensiones así:

Interfaz con proceso de establecimiento de beneficiarios y reconocimiento de pensiones,

el cual debe proveerle a la aplicación de nómina de pensionados, toda la información

base para el ingreso de pensiones a la nómina. Es importante tener en cuenta que el

establecimiento de beneficiarios debe estar lógicamente artículado con el proceso de

siniestros, el cual provee la información de los casos en los cuales debe iniciarse el

trámite de reconocimiento de una pensión con toda la información detallada tanto del

trabajador como del empleador

Interfaz con Reservas: La solución tecnológica debe estar en capacidad de recibir a

través de interfaz con la aplicación de nómina de pensionados, la información detallada

de novedades de retiro, activación, suspensión de beneficiariosla para actualizar la

información base para el cálculo de la reserva matemática





Fecha: 14/11/2014


Pàgina 25 de 52

25

Los volúmenes actuales del proceso de nómina de pensionados ARL son:

Cuadro 4 Volúmenes mensuales – Pago de Pensiones

TERCERA FASE: Esta tercera fase del proyecto, contempla el desarrollo de las etapas del producto ARL de PROSPECTACIÓN CLIENTES y SUSTENTACIÓN PROPUESTAS COMERCIALES, donde se abordan los procesos de Estrategia de Mercadeo, Gestión de Canales y Gestión de Vinculación y Mantenimiento de Clientes.

1.15 Módulo de Mercadeo

Este módulo debe permitir a la Compañía, identificar las necesidades y tendencias del mercado, para establecer estrategias de identificación, atracción, vinculación, relacionamiento y fidelización de empresas clientes objetivos. Por lo anterior debe poder segmentar las pólizas ARL (empleadores y/o contratantes) de la compañía en las siguientes categorías: Descripción corta de las características de los segmentos:

Platino: Empresas que aportan la mayor producción y el mejor resultado técnico.

Oro: Empresas con el mejor margen de utilidad y las segundas con el más alto

resultado técnico.

Plata: Empresas con bajo índice de siniestralidad y baja participación en la

producción.

Bronce: Empresas con baja siniestralidad y resultado técnico.

Cobre: Empresas de resultado técnico negativo y con alto índice de siniestralidad

Periodo NOMINA No. Pensiones No. De Pagos Valor Mesadas Netas

(Giro a Bancos)

Deducciones

(Giro a Terceros)

(1)

Valor Total Nómina

ARL 3.386 5.291 2.215.332.961 521.098.541 2.736.431.502 Septiembre

No. Beneficiarios con pago de mesada 5.291

No. De Terceros para pago de libranzas 106

No. Novedades Individuales 428

No. Novedades Masivas 419

No. Peticiones, Quejas, Reclamos 75

No. Tutelas 10

sep-15PROCESO





Fecha: 14/11/2014


Pàgina 26 de 52

26

Crear y socializar la segmentación de empresas afiliadas a riesgos laborales. Los datos de la segmentación son:

Entradas del Modelo Cálculos del Modelos Socialización del Modelo

Identificación de la

Empresa:

Número de Documento

Tipo de Documento

Razón Social

emp_Id

Primas emitidas por empresa:

emp_Id

loc.IdEmpresa

csp-valorprima

Periodo de análisis

tim_id

Cuenta corriente – comisión de

intermediario

ID del intermediario

Intermediario

Ramo

% Comisión

Comisión

Inversión en Promoción y Prevención

ID de la empresa

Razón Social

Total de Inversión en Promoción y

Prevención

Siniestralidad

Incurrida del Periodo: Reserva SOA +

reserva matemática

Índice de siniestralidad: Siniestralidad

Incurrida del periodo / Primas Emitidas

Resultado Técnico = +Primas emitidas

- Siniestralidad Incurrida del periodo

- Inversión en Promoción y

prevención -Comisión de

intermediarios - Costos

administrativos y legales

Margen de Utilidad. Resultado técnico /

primas emitidas

Genera los 5 segmentos de

empresas a través de conglomerados

estadísticos :

Platino Oro

Plata

La información de la

empresa con las entradas y cálculos del

modelo:

Entradas:

Identificación de la empresa

Primas Emitidas

Comisión

Inversión de Promoción y

Prevención

Reserva Matemática

Salidas:

Siniestralidad incurrida del

periodo

Índice de siniestralidad

Resultado Técnico

Margen de Utilidad

Segmento por empresa





Fecha: 14/11/2014


Pàgina 27 de 52

27

Entradas del Modelo Cálculos del Modelos Socialización del Modelo

Reserva SOA

ID de la empresa

Tipo de Documento

Id: tipo de movimiento

Reserva matemática:

ID de la empresa

Tipo de Documento

nro_siniestros

total_reserva

Bronce cobre

Cuadro 5. Resumen de las Variables del Modelo de Segmentación de ARL El modelo de segmentación consiste en el análisis de conglomerados (cluster), es una técnica multivariante y descriptiva que busca agrupar elementos (o variables) tratando de lograr la máxima homogeneidad al interior de cada grupo y la mayor diferencias o heterogeneidad entre los grupos. Las (3) tres variables que permiten generar los cinco (5) segmentos, que fueron construidas y se constituyen como salidas son:

- Resultado técnico

- Índice de siniestralidad incurrida en el periodo

- Margen de utilidad

Resultado Técnico: El resultado técnico de la empresa afiliada, para el modelo de segmentación de clientes ARL se define como la relación entre las primas emitidas menos los costos operacionales de cada póliza ARL para el periodo de análisis. El periodo de análisis es de un año corrido, desde la fecha de corte doce meses hacia atrás.

𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜 𝑡é𝑐𝑛𝑖𝑐𝑜 = 𝑃𝑟𝑖𝑚𝑎𝑠 𝐸𝑚𝑖𝑡𝑖𝑑𝑎𝑠 − 𝐶𝑜𝑠𝑡𝑜 𝐶𝑜𝑠𝑡𝑜𝑠: 𝑆𝑖𝑛𝑖𝑒𝑠𝑡𝑟𝑎𝑙𝑖𝑑𝑎𝑑 𝐼𝑛𝑐𝑢𝑟𝑟𝑖𝑑𝑎 𝑑𝑒𝑙 𝑝𝑒𝑟𝑖𝑜𝑑𝑜 + 𝐼𝑛𝑣𝑒𝑟𝑠𝑖ó𝑛 𝑃&𝑃 + 𝐼𝑛𝑡𝑒𝑟𝑚𝑒𝑑𝑖𝑎𝑐𝑖ó𝑛

+ 𝐶𝑜𝑠𝑡𝑜𝑠 𝑎𝑑𝑚𝑖𝑛𝑖𝑠𝑡𝑟𝑎𝑡𝑖𝑣𝑜𝑠 𝑦 𝑙𝑒𝑔𝑎𝑙𝑒𝑠





Fecha: 14/11/2014


Pàgina 28 de 52

28

La Siniestralidad Incurrida del periodo es calculada como la suma de la reserva SOA + reserva matemática, del periodo de análisis.

a. Reserva SOA reserva de los siniestros ocurridos y avisados corresponde:

𝑹𝒆𝒔𝒆𝒓𝒗𝒂 𝑺𝑶𝑨 = 𝑆𝑎𝑙𝑑𝑜 𝑎𝑙 𝑝𝑒𝑟𝑖𝑜𝑑𝑜 (𝑆𝑖 − 1) + 𝑉𝑎𝑙𝑜𝑟 𝑑𝑒 𝑙𝑎 𝑟𝑒𝑠𝑒𝑟𝑣𝑎 𝑎𝑙 𝑝𝑒𝑟𝑖𝑜𝑑𝑜 (𝑅𝑒𝑖) Donde

Si-1 = (Reserva Total – Pago)i-1

Entendida la Reserva S.O.A Total como la reserva del periodo y está dada por todo movimiento que implique la variación en el monto de la misma, es decir, los movimientos a nivel de siniestro de: Constituciones (C), hacen referencia a la creación (aviso del siniestro) de la reserva. Ajustes (A), adiciones a la reserva Liberaciones (P), disminuyen la reserva, se puede disponer de dichos rubros. Por su

naturaleza son negativos. Liberación por paso a Matemática (M), aceptación de la pensión del siniestrado, genera

la creación de la reserva matemática.

𝑹𝒆𝒔𝒆𝒓𝒗𝒂 𝑺𝑶𝑨 𝑻𝒐𝒕𝒂𝒍 = 𝐶 + 𝐴 + (−𝑃) + (−𝑀)

Pagos, correspondientes a los movimientos que implican la aceptación de una obligación y disminuyen la reserva SOA, los cuales a nivel de siniestro pueden ser: Reconocimientos (R), aceptación del pago de uno o varios conceptos de reserva.

Reaseguros (S), aceptación de un pago correspondiente al reasegurador

𝑃𝑎𝑔𝑜𝑠 = 𝑅 + 𝑆

En conclusión 𝑆𝑎𝑙𝑑𝑜𝑖 − 1 = (𝐶 + 𝐴 + (−𝑃) − (𝑅 + 𝑀 + 𝑆))𝑖 − 1

Reserva del Periodo, se toma como la reserva total del periodo, es equivalente a: Reserva del Periodo (𝑅𝑒𝑖) = 𝐶𝑖 + 𝐴𝑖 + (−𝑃𝑖) + (−𝑀𝑖) b. Reserva Matemática

Se toma el valor de la reserva total de las personas, recibidas dentro de los archivos de reserva matemática como nuevos, para el periodo de análisis por mes, es decir, el mes que son reportados como nuevos se toma el valor de la reserva total.

Índice de Siniestralidad Incurrida del Periodo:

ÍNDICE DE SINIESTRALIDAD INCURRIDA DEL PERIODO / PRIMAS EMITIDAS

Margen de Utilidad:

RESULTADO TÉCNICO / PRODUCCIÓN Como conclusión, las tres variables del modelo tienen la misma importancia y no poseen sesgo alguno que modifique estadísticamente los resultados.

Para evaluar los resultados del modelo de segmentación, se analizaron tres variables que permiten clasificar a las empresas de acuerdo a una calificación dada de RFM, de la siguiente manera:

Recencia: Es medida como la antigüedad de la compañía.





Fecha: 14/11/2014


Pàgina 29 de 52

29

Frecuencia: De la siniestralidad incurrida del periodo

Monto: Es medida como el resultado técnico construido anteriormente.

1.16 Módulo Canales

El módulo de canales, debe administrar los distintos canales de comercialización del producto de ARL, por lo cual debe:

Crear y administrar la red de Intermediarios de Seguros Los datos de los intermediarios son:

Datos Personales Datos Gestión de Pago

Datos Comerciales

Nombre / Razón Social Documento Identidad Dirección Teléfono / Celular Ciudad Correo electrónico

Entidad Financiera Tipo de Cuenta Número Cuenta Bancaria Régimen Fiscal Datos SARLAFT

Idoneidad Estado Intermediario Fecha de inicio de vigencia Canal de venta Corte de cuentas

Cuadro 6. Variables Intermediarios – Producto ARL Los Intermediarios de Seguros que se tendrían son:

- Corredores de Seguros - Agencias de Seguros - Agentes de Seguros

Cada uno de estos tipos de intermediarios tiene características especiales en el manejo del régimen de impuestos que los cobija (Régimen Fiscal). Actualmente la compañía cuenta con 1.125 Intermediarios con clave activa en el sistema existente, de los cuales aproximadamente 494 tienen producción de primas en el ramo de riesgos laborales y generan procesos de liquidación y pago de comisiones mensuales. Mensualmente se tiene un volumen de aproximadamente 1.650 pólizas ARL que se encuentran intermediadas y generan procesos de facturación, liquidación y pago de comisiones. Se estima que anualmente ingresen por lo menos 150 intermediarios nuevos y se inactiven 80 claves por baja productividad. Esto implica que el sistema debe poder administrar los tipos de estado del intermediario dentro de la red comercial:

- Activo - Inactivo





Fecha: 14/11/2014


Pàgina 30 de 52

30

- Inactivo Temporalmente - Cancelado.

Los intermediarios se deben parametrizan en el sistema mediante una codificación única que les permite asociar los negocios que ingresan a la compañía, la estructura que se tiene actualmente para administrar la red de intermediarios cuenta con las siguientes características: La clave o código del intermediario está compuesto por un conjunto de campos numéricos que permiten asociar el intermediario a su respectiva Sucursal, esta combinación numérica sigue la siguiente estructura:

XX XXX XXXX Código Regional Código Sucursal Código único del Intermediario De acuerdo con lo anterior el código o clave del intermediario se compone de nueve (9) dígitos y se construye dependiendo de la Sucursal en la que principalmente va a desarrollar su gestión comercial. Nota: Actualmente el sistema de información que administra los seguros de vida (IAXIS) centraliza la creación y administración de intermediarios de seguros; el aplicativo propuesto para administrar ARL podría “alimentarse” de esta información por medio de interfaz lo cual evitaría un desarrollo para este módulo. Es de anotar que los intermediarios comercializan todos los ramos de la compañía (Vida y ARL)

Control de “asignación de intermediarios” al líder comercial de la Sucursal La estructura comercial de la compañía está compuesta por 32 Gerencias Sucursales que tienen líderes o coordinadores comerciales que administran un grupo de intermediarios. El sistema debe contar con una funcionalidad en el cual se pueda asignar a cada líder comercial un número de intermediarios para su correspondiente gestión, es decir que debe poder administrar “Grupos de vendedores”.

Control asignación de negocios del intermediario La función del intermediario de seguros es vincular a Positiva Compañía de Seguros nuevas empresas en el ramo de Riesgos Laborales, para lo cual desde la etapa de afiliación (diligenciamiento del formulario de vinculación) debe venir registrado el intermediario que está realizando la gestión comercial. La Funcionalidad de asignación de negocios del intermediario debe funcionar mediante flujos de trabajo (workflow) en el cual se visualice cada una de las etapas asociadas a la afiliación de la empresa y la correspondiente cobertura de sus empleados. Las etapas mínimas requeridas son:

a) Afiliación: Diligenciamiento del formulario de afiliación Radicación de los documentos soporte Radicación de la carta de nombramiento como intermediario Radicación del pre-diagnóstico comercial





Fecha: 14/11/2014


Pàgina 31 de 52

31

b) Análisis de Riesgo

Revisión y análisis de los datos contenidos en el pre-diagnóstico comercial Análisis del margen técnico del negocio Aplicación de las políticas comerciales Definición del porcentaje de comisión del intermediario (por defecto es cero) Autorización del porcentaje de comisión Escalamiento de autorización de comisión si no cumple con políticas

c) Asignación de porcentaje (%) comisión Marcación del % de comisión en la póliza Autorización en cascada si no cumple políticas Emisión de carta de ratificación de porcentaje % de comisión para el intermediario

Para el ramo de riesgos laborales las comisiones se establecen de la siguiente manera: Para establecer el porcentaje de comisión se realiza un análisis de riesgo y de acuerdo con el resultado técnico se autorizara hasta el 10%. De acuerdo con los siguientes rangos:

Margen Técnico Porcentaje de Comisión

40 % o más 10%

30 % hasta el 39.99 %

9%

20 % hasta el 29.99 %

8%

10 % hasta el 19.99 %

7%

Menos del 10 % No Aplica

Cuadro 7. Comisiones intermediarios – Producto ARL

Estos rangos y comisiones deberán ser parametrizables por el usuario administrador del sistema. Sólo se podrá autorizar una comisión superior o diferente a las detalladas en la tabla presentada con autorización expresa de un rol superior. Por lo tanto el sistema debe contemplar un esquema de Roles y Perfiles que permitan autorizar los porcentaje de comisión, incluyendo aquellos que se salgan de política. La funcionalidad de asignación de negocios debe contar con el desarrollo de una actividad de pre-diagnóstico comercial o análisis de margen técnico del negocio nuevo de tal manera que los usuarios puedan registrar los campos necesarios para definir si el negocio es rentable o no, antes de proceder a asignar un porcentaje de comisión. Todos los documentos asociados al proceso de asignación de comisión en la póliza ARL, deben quedar digitalizados y las fases deben contar con fecha de inicio, fecha de finalización, número





Fecha: 14/11/2014


Pàgina 32 de 52

32

de días que dura el proceso, campo para observaciones y registro de huella de usuario que autorizó en el sistema el porcentaje de comisión. Así mismo se requiere poder aplicar novedades como son:

- Nombramiento de intermediario: Se entiende cuando en un negocio que se encuentra gestionado actualmente por Positiva (es decir sin intermediario), el tomador (empresa afiliada) solicita que su póliza se gestionada o administrada por un intermediario de seguros.

- Cambio de intermediario: Se entiende cuando un negocio se encuentra actualmente gestionado o administrado por un intermediario de seguros y el tomador de la póliza (empresa afiliada) solicita que ahora sea gestionado por un intermediario de seguros distinto.

- Co-corretaje: Se entiende cuando en una misma póliza intervienen dos o más intermediarios de seguros para su administración. Cuando ocurre esta situación el tomador (empresa afiliada) definirá previamente los porcentajes de participación de cada uno de los intermediarios en el negocio.

- Cambio de porcentaje de comisión: Se entiende cuando por motivos de rentabilidad del negocio o comerciales, se evalúa el cambio de porcentaje de comisión que actualmente se tiene definido para un negocio en particular.

El sistema debe permitir administrar las novedades de intermediarios, de tal manera que se lleve una traza de los cambios realizados en la póliza ARL especificando las vigencias y porcentajes de comisión y participación definidos para cada cambio, así como las observaciones de los usuarios involucrados en el proceso de asignación de comisión y la digitalización de los respectivos documentos soporte. El sistema debe contemplar la posibilidad de realizar ajustes o marcaciones retroactivas en las pólizas ARL, esto implica que el sistema debe ajustar la intermediación desde el momento en que el tomador (empresa afiliada) lo solicite, así esto implique realizar movimientos en meses anteriores.

Liquidación y pago de comisiones del intermediario El sistema debe permitir la administración de los procesos relacionados con la liquidación de las comisiones del intermediario. El intermediario de seguros tiene derecho a recibir la comisión pactada en el negocio, una vez se haya realizado el recaudo (módulo recaudo) y este se encuentre debidamente aplicado en el sistema de información de la compañía. Para la liquidación de la comisión se debe tener en cuenta:

- Prima recaudada - Autodescuentos por parte del tomador de la póliza ARL - Porcentaje de Comisión - Comisión bruta





Fecha: 14/11/2014


Pàgina 33 de 52

33

- Descuentos, o devoluciones a cargo del intermediario - Impuestos: Retención en la fuente, Retención de ICA, y demás impuestos que se

definan - Comisión neta

El sistema debe tener en cuenta el régimen fiscal de cada uno de los intermediarios (simplificado, común, auto-retenedor, etc.) para liquidar los impuestos a que haya lugar, así mismo debe contemplar tablas de parametrización de impuestos nacionales y distritales por municipio. Una vez genere la liquidación de comisiones de acuerdo con las políticas y procedimientos definidos por Positiva, el sistema debe permitir la conexión con el sistema de administración contable de la Compañía (en este momento es SAP) para que este genere automáticamente los pagos a las cuentas bancarias de los intermediarios de seguros en las fechas de corte establecidas.

Administración del modelo de compensación variable de la Estructura Comercial Se entiende por estructura comercial aquellos cargos relacionados directamente con la función de ventas: Vicepresidencia de Negocios, Gerencia de Producto ARL, Gerencias Regionales, Gerencias Sucursales, Coordinadores Comerciales, Líderes Comerciales, Asesores Comerciales directos de la compañía. El sistema debe tener una funcionalidad que permita parametrizar y administrar los modelos de compensación variable para la estructura comercial. La aplicación debe permitir asociar en cascada los presupuestos de venta, la ejecución (liquidación de aporte – módulo afiliación) y el recaudo derivado de las pólizas de negocios de ARL para definir qué personas de la estructura comercial pueden acceder a los beneficios descritos en el modelo de compensación variable (comisiones por cumplimiento de metas y resultados). Las variables de esta funcionalidad deben ser parametrizables por el usuario, pero deberá contener como mínimo los siguientes aspectos:

- Administración de grupos de ventas (Intermediarios de Seguros) - Liquidación de aportes asociados al grupo de ventas - Recaudos asociados a las pólizas ARL administradas por el grupo de ventas - Siniestralidad asociada a las pólizas administradas por el grupo de ventas - Número de negocios nuevos del grupo de ventas - Primas emitidas en negocios nuevos del grupo de ventas - Calificación de los negocios administrados por el grupo de ventas (Sectores

estratégicos) - Margen técnico de los negocios administrados por el grupo de ventas - Asignación de comisiones (compensación variable) en cascada para la Estructura

Comercial - Módulo de autorización de pago de comisiones (compensación variable) para la

Estructura Comercial El sistema debe permitir asociar pólizas ARL que se gestionen directamente (es decir sin intermediario) por cada uno de los integrantes de la Estructura Comercial, esto con el fin de





Fecha: 14/11/2014


Pàgina 34 de 52

34

tenerlas en cuenta al momento de calcular las comisiones definidas en el modelo de compensación variable.

Asociados al intermediario y a la estructura comercial El sistema debe contar con una funcionalidad de reportes que permita extraer toda la información relacionada con la gestión de los intermediarios de seguros. Dentro de los reportes requeridos se debe tener en cuenta por lo menos las siguientes variables:

Reporte de Intermediarios: Este reporte se requiere para poder extraer la información detallada de la red comercial creada en el sistema. Debe contener como mínimo los siguientes campos:

- Código del Intermediario - Nombre del Intermediario - No. documento de identidad - Tipo de agente (agente, agencia, corredor) - Sucursal - Dirección - Teléfono / Celular - Correo electrónico - Personas Relacionadas (para agencias información del Representante Legal) - Estado del intermediario (activo, inactivo, etc.) - Fecha de alta - Fecha de baja - Canal - Corte de Cuentas - Régimen Fiscal - Entidad Financiera - Tipo de cuenta - Número de cuenta bancaria

Reporte de producción del intermediario

Este reporte se requiere para poder obtener la información de la gestión comercial realizada por el intermediario en un periodo de tiempo determinado. El módulo debe contar con un filtro que permita seleccionar las fechas y deberá contener como mínimo los siguientes campos:

- Número de póliza - Sucursal - Ramo - Número de movimiento - Tipo de movimiento (expedición, facturación, ajuste, cancelación) - Fecha de movimiento - Vigencia a la que corresponde el movimiento - Estado de la póliza - Código intermediario - Nombre intermediario





Fecha: 14/11/2014


Pàgina 35 de 52

35

- Fecha de inicio de vigencia de la póliza - Prima - Documento identidad del tomador - Nombre del tomador - Porcentaje de participación del intermediario (para pólizas con co-corretaje) - Comisión

Reporte de Recaudos del intermediario

Este reporte se requiere para obtener la información de los recaudos aplicados a cada una de las pólizas que gestiona el intermediario, pues de estos depende el pago de su comisión. El módulo debe contar con un filtro que pueda seleccionar las fechas. Este reporte debe contener como mínimo con los siguientes campos:

- Número de póliza - Sucursal - Ramo - Número de movimiento - Tipo de movimiento (expedición, facturación, ajuste, cancelación) - Fecha de movimiento - Vigencia a la que corresponde el movimiento - Estado de la póliza - Fecha de inicio de vigencia de la póliza - Código intermediario - Nombre intermediario - Fecha del recaudo - Valor del recaudo - Documento identidad del tomador - Nombre del tomador - Porcentaje de participación del intermediario (para pólizas con co-corretaje) - Comisión - Impuestos - No. Recibo (aplicación en el sistema)

Reporte de comisiones pagadas al intermediario

Este reporte se requiere para conocer las comisiones que efectivamente se han pagado al intermediario en un periodo de tiempo determinado. El módulo debe contar con un filtro que pueda seleccionar las fechas. Debe contener como mínimo los siguientes campos:

- Número de póliza - Sucursal - Ramo - Tomador - Documento de identidad tomador - Código intermediario - Nombre intermediario - Porcentaje de participación del intermediario - Número de movimiento - Tipo de movimiento (expedición, facturación, ajuste, cancelación)





Fecha: 14/11/2014


Pàgina 36 de 52

36

- Fecha de movimiento - Vigencia a la que corresponde el movimiento - Valor de Recaudo - Fecha de recaudo - No. Recibo (aplicación en el sistema) - Porcentaje (%) Comisión asignado en la póliza o movimiento - Comisión - Impuestos - Neto a pagar - Número de la orden de pago - Fecha de la orden de pago - Valor del pago

Reporte de P&G del intermediario

Este reporte se requiere para conocer la rentabilidad del intermediario en un periodo de tiempo. El módulo debe contar con un filtro que pueda seleccionar fechas y deberá contener como mínimo los siguientes campos:

- Número de póliza - Sucursal - Ramo - Tomador - Documento de identidad tomador - Código intermediario - Nombre intermediario - Porcentaje de participación del intermediario - Prima - Valor de Recaudo - Valor de la Comisión - Gastos asociados a la póliza en P&P (promoción y prevención) - Siniestros en Reserva asociados a la póliza - Siniestros Pagados asociados a la póliza - Margen técnico de la póliza

Reportes asociados a la Estructura Comercial

El sistema debe contar con una funcionalidad reportes que permita extraer toda la información relacionada con las pólizas gestionadas directamente por los integrantes de la estructura comercial y las pólizas asociadas al grupo de intermediarios que gestiona el integrante de la estructura comercial. Dentro de los reportes requeridos se debe tener en cuenta por lo menos las siguientes variables:

- Nombre del integrante de la Estructura Comercial - Documento de Identidad - Cargo - Sucursal - Negocios asociados por gestión comercial directa - Intermediarios asociados a su grupo de ventas - Número de póliza





Fecha: 14/11/2014


Pàgina 37 de 52

37

- Sucursal - Ramo - Número de movimiento - Tipo de movimiento (expedición, facturación, ajuste, cancelación) - Fecha de movimiento - Vigencia a la que corresponde el movimiento - Estado de la póliza - Código intermediario - Nombre intermediario - Fecha de inicio de vigencia de la póliza - Prima - Valor de Recaudo - Documento identidad del tomador - Nombre del tomador - Porcentaje de participación del intermediario (para pólizas con co-corretaje) - Porcentaje % de Comisión - Valor de Comisión - Gastos asociados a la póliza en P&P (promoción y prevención) - Siniestros en Reserva asociados a la póliza - Siniestros Pagados asociados a la póliza - Margen técnico de la póliza

1.17 Módulo Producto ARL

En este proceso el módulo debe registrar la gestión comercial realizada por los Gerentes Regionales, Gerentes Sucrusales, Cordinadores y Líderes comerciales del ramo de riesgos laborales, empezando por el registro de los prospectos, creación de cuenta, elaboración del prediagnóstico para calificación del prospecto, agendamiento de visitas, generación de oportunidades, elaboración y presentación de propuestas, registro de cierre de negocio (Ganados o Perdidos), si el negocio es ganado se debe digitalizar y adjuntar la carta de traslado como constancia de cierre del negocio. Una vez el negocio es cerrado y ganado, se debe continuar el proceso con el módulo de afiliaciones, creando la poliza de ARL y realizando la afiliación del empleador o contrante y sus relaciones laborares correspondientes, el negocio nuevo de acuerdo con el modelo de segmentación vigente debe tener atención en los programas de promoción y prevención, por lo cual la información debe intercontectarse con las aplicaciones Gestpos o Seguir según sea el caso. Los volúmenes promedios que se debe gestiónar son:

- Prospectos a gestiónar (520 Mensuales)

- Creación de cuentas (200 cuentas)

- Elaboración Prediagnóstico Comercial para calificación del prospecto y autorización

inicio de gestión comercial (200 cuentas)

- Agendamiento Visitas comerciales (210 registros diarios)

- Cargue del formato de acercamiento comercial o registro de las acciones realizadas en

esa visita (200 registros diarios)

- Elaboración de la propuesta comercial (100 mes)





Fecha: 14/11/2014


Pàgina 38 de 52

38

- Bodega de almacenamiento propuestas comerciales presentadas (100 mes)

- Registro del cierre de la oportunidad (ganada o perdida) (100 mes)

- Generación de alertas de los prospectos que no han sido gestionados

- Genaración de alertas de las oportunidades que están abiertas y llevan más de 3 meses

sin gestionar.

- Generación de reporte de los negocios nuevos vinculados por gestión comercial que

inician vigencia en el periodo anlizado.

- Generación de reporte de las oportunidades que se están generando con intermediarios.

- Generación de reporte de oportunidades cerradas ganadas que tienen intermediario.

- Generación de reporte de oportunidades cerradas ganadas identificandolas por sectores

económicos.

- Generación de reportes de oportunidades cerradas ganadas por sucursal, cordinador y

líder comercial Arl.

El módulo debe gestionar el seguimiento, control y generación de informes sobre la situación de cada oportunidad, información debe estar disponible diariamente y ser consultada desde cualquier lugar en línea. Así mismo debe existir un módulo de reportes: Frente a este módulo es necesario generar informes que permitan a la gerencia responsable, hacer seguimiento, control y análisis a los resultados de la gestión realizada por cada una de las sucursales en lo referente a riesgos Laborales: INFORMES:

- Facturación de empresas que tengan más de un año de vinculacion a la ARL.

- Facturación de Negocios nuevos que tengan menos de una año en la ARL

- Facturación de trabajadores independientes discriminando por clase de Riesgo

(1,2,3,4,5)

- Informe de empresas que se trasladan a otras ARL

- Informe de empresas que se retiran del Sistema de Riesgos Laborales

- Informe de empresas retiras por proceso de depuración

- Informe de empresas que realizan pagos y no se encuentran afiliadas

- Informe de Autodescuentos autorizados y que afectan la producción

- Informe de Producción detallado por Regional o Sucursal incluyendo las siguientes

variables:

o Ajustes hospitales Sistema General de Participacion

o Ajustes de cartera – desafiliacion - inactivacion conciliación

o Aplicación independientes (sena, municipio de cali, etc)

o Legalización recaudo aportantes no vinculados

o Nota crédito cambio intermediario

o Nota crédito devolución aportes devoluciones por trabajadores

o Nota débito cambio intermediarios

o Notas crédito por recaudo (normal)

o Notas crédito por recaudo(ajustes)

o Notas débito por recaudo





Fecha: 14/11/2014


Pàgina 39 de 52

39

o Legalización notas autodescuento

o Notas débito por recaudo

o Legalización autodescuentos

o Renovación (valor producción de empresas que tienen más de 12 meses con

Positiva).

o Negocios Nuevos por Demanda espontánea.

o Negocios Nuevos por gestión comercial.

- Estado y costo del plan de trabajo de promoción y prevención ejecutado en las

empresas.

- Sinestralidad incurrida y pagada por póliza de empresa.

- Informe de producción por Intermediario (Pagos y Cartera).

- Informe de comisiones liquidadas y pagadas por intermediario por sucursal regional y

total país .

- Generación de alerta de radicación de carta de traslado por parte de las empresas que

están afiliadas y han sido identificadas como rentables por la organización.

- Informe comporatamiento facturación,ajustes, producción, recaudo, cartera , afiliación y

retiro de trabajadores por empresa, por sector económico por ciudad por región por

tamaño de empresa, por segmento y otras variables que se consideren como soporte de

conocimiento de los clientes para generar presupuestos y metas de ventas.





Fecha: 14/11/2014


Pàgina 40 de 52

40

Gráfica 7 – Módulos Producto ARL

MODULOGERENCIA

PRODUCTOARL

DESARROLLOPROCESOGESTIONCOMERCIAL

- Registrodelosprospectos

- CreacióndeCuenta

- Elaboracióndeprediagnóstico

- AgendamientodeVisitas

- Generacióndeoportunidades

- Elaboraciónypresentacióndepropuestas

- Registrodecierredenegocio

- Digitalizaryadjuntarlacartadetraslado

VINCULACIONYPOSVENTA

- CreacióndePólizaNueva

- Digitalizaciónycarguederatificaciónonombramientodelintermediario

- Carguedelformularioydocumentosnecesariosparalaafiliacióndelaempresa

- Asignacióndeusuarioyclaveparaaccesoalosdiferentesaplicativosvirtuales

- Carguedelformulariooarchivoquecontengalainformacióndelostrabajadores

- EntregadeCarnets

- AsignacióndeGestor

- AsignaciónPosventa





Fecha: 14/11/2014


Pàgina 41 de 52

41

Gráfica 8 – Reportes Módulos Producto ARL

MODULOGERENCIAPRODUCTOARL

INFORMESYREPORTES

- Valor facturación de empresas que tengan más de un año de vinculación a la ARL.

- ValorfacturacióndeNegociosnuevosquetenganmenosdeunañoenlaARL

- ValorfacturacióndetrabajadoresindependientesdiscriminandoporclasedeRiesgo

(1,2,3,4,5)

- InformedeempresasquesetrasladanaotrasARL

- InformedeempresasqueseretirandelSistemadeRiesgosLaborales

- Informedeempresasretiradasporprocesodedepuración

- Informedeempresasquerealizanpagosynoseencuentranafiliadas(Positiva)

- InformedeAutodescuentosautorizadosyqueafectanlaproducción

- Estadoycostodelplandetrabajodepromociónyprevenciónejecutadoenlasempresas.

- Informe de Producción detallado por Regional o Sucursal incluyendo las variables:

§ Ajustes hospitales Sistema General de Participación

§ Ajustes de cartera – desafiliación - inactivación conciliación § Aplicación independientes (sena, municipio de cali, etc) § Legalización recaudo aportantes no vinculados

§ Nota crédito cambio intermediario § Nota crédito devolución aportes devoluciones por trabajadores

§ Nota debito cambio intermediarios § Notas crédito por recaudo (normal) § Notas crédito por recaudo(ajustes)

§ Notas debito por recaudo § Legalización notas auto descuento § Legalización auto descuentos

§ Renovación (valor producción de empresas que tienen más de 12 meses con Positiva)

§ Negocios Nuevos por Demanda espontanea

§ Negocios Nuevos por gestión comercial

- Siniestralidadincurridaypagadaporpólizadeempresa

- InformedeproducciónporIntermediario(PagosyCartera)

- Informedecomisionesliquidadasypagadasporintermediarioporsucursalregionaly

totalpaís

- Generacióndealertaderadicacióndecartadetrasladoporpartedelasempresasque

estánafiliadasyhansidoidentificadascomorentablesporlaorganización





Fecha: 14/11/2014


Pàgina 42 de 52

42

2. SITUACIÓN TECNOLÓGICA ACTUAL

En este aparte se presenta el estado de la arquitectura de software original del Sistema de Información de Riesgos Laborales – SIARP y la Nueva arquitectura, con base en la cual se han desarrollado nuevos módulos y migrando de la anterior. Actualmente Positiva Compañía de Seguros cuenta con el sistema de información para la administración de Riesgos Laborales - SIARP para gestionar sus procesos, este sistema se comenzó a construir desde 2007. Actualmente el sistema está compuesto por varios módulos los cuales se mencionan a continuación:

Afiliación

Reservas

Prestaciones Asistenciales

Prestaciones Económicas

Medicina Laboral

Siniestros

Tutelas

Procesos Jurídicos

Auditoría

Gestión de recobros

Investigaciones/Conciliaciones

MUCI

Reportes Fasecolda

Salud Ocupacional

Adicionalmente el sistema SIARP tiene implementadas integraciones punto a punto con otros sistemas de información tanto internos como de proveedores de la compañía. Dichas integraciones se mencionan a nivel general en la siguiente tabla:

NOMBRE SISTEMA ORIGEN

SISTEMA DESTINO

UBICACIÓN SERVICIO

DESCRIPCIÓN Y/O OBSERVACIONES

PAGOS SISE I SIARP SISE I SISE GESTIÓN DE PAGOS SISE I

PAGOS SISE II SIARP SISE II SISE GESTIÓN DE PAGOS SISE II

MEDICINA LABORAL SIARP CONEXIA SIARP VISTA DIAGNÓSTICOS

MEDICINA LABORAL SIARP CONEXIA SIARP VISTA FURAT

MEDICINA LABORAL SIARP CONEXIA SIARP VISTA TRABAJADOR

MEDICINA LABORAL SIARP CONEXIA SIARP VISTA RELACIÓN LABORAL





Fecha: 14/11/2014


Pàgina 43 de 52

43

NOMBRE SISTEMA ORIGEN

SISTEMA DESTINO

UBICACIÓN SERVICIO


MEDICINA LABORAL SIARP CONEXIA SIARP VISTA SOLICITUD

PRESTACIONES ECONÓMICAS

SIARP SAP SIARP INCAPACIDADES TEMPORALES

PRESTACIONES ASISTENCIALES

SIARP SAP SIARP CUENTAS MÉDICAS

CONSULTA SIARP UMB SIARP CONSULTA

Cuadro 7 Integraciones SIARP con otras aplicaciones

NOMBRE SISTEMA ORIGEN SISTEMA DESTINO

UBICACIÓN SERVICIO


TUTELAS SICO SIARP SICO RADICACIÓN DE TUTELAS

AFILIACIONES ENLACE OPERATIVO

SIARP SIARP CONSULTA Y NOVEDADES DE AFILIACIONES

COMPROBACIÓN DE DERECHOS

CONEXIA SIARP SIARP PROCESO DE COMPROBACIÓN DE DERECHOS

ADMINISTRACIÓN DE TERCEROS

SISE SIARP SISE CREACIÓN DE TERCEROS

AUTORIZACIONES SYC - AUTORIZACIONES

SIARP SIARP COMPROBACIÓN DE DERECHOS

AUTORIZACIONES SYC - AUTORIZACIONES

SIARP SIARP COMPROBACIÓN DE DERECHOS

SINIESTROS SYC - SINIESTROS VENTANILLA

SIARP SIARP GESTIÓN DE SINIESTROS

SINIESTROS SYC - SINIESTROS WEB

SIARP SIARP GESTIÓN DE SINIESTROS

RESERVAS SYC - RESERVAS SIARP SIARP GESTIÓN DE RESERVAS

AFILIACIÓN SYC VENTANILLA - AFILIACIÓN Y NOVEDADES

SIARP SIARP AFILIACIÓN Y NOVEDADES

AFILIACIÓN SYC PORTAL ARL - AFILIACIÓN Y NOVEDADES


AFILIACIÓN SYC NOVEDADES - AFILIACIÓN Y NOVEDADES






Fecha: 14/11/2014


Pàgina 44 de 52

44

NOMBRE SISTEMA ORIGEN SISTEMA DESTINO

UBICACIÓN SERVICIO


AFILIACIÓN SYC NOVEDADES PILA - AFILIACIÓN Y NOVEDADES



SYC VENTANILLA- PRESTACIONES

SIARP SIARP INCAPACIDADES TEMPORALES


SYC PORTAL ARL - PRESTACIONES

SIARP SIARP INCAPACIDADES TEMPORALES

PRESTACIONES ASISTENCIALES

SYC - PRESTACIONES

SIARP SIARP CUENTAS MÉDICAS

PMU AFILIACIÓN SYC - AFILIACIONES SIARP SIARP CONSULTAS

SCG SYC - AFILIACIONES SIARP SIARP CONSULTAS

GESTPOS SYC - PYP SIARP SIARP CONSULTAS

SEGUIR SYC - PYP SIARP SIARP CONSULTAS

EXPEDIENTE DIGITAL 1 (PÓLIZAS DE VIDA)

SYC - PÓLIZAS DE VIDA

SIARP SIARP CONSULTAS

EXPEDIENTE DIGITAL 2

SYC - AFILIACIONES, PRESTACIONES, RECAUDO


PROCP SYC - AFILIACIONES SIARP SIARP CONSULTAS

RADICACIÓN

SYC - AFILIACIONES, PRESTACIONES, RECAUDO


Cuadro 8 Integraciones SIARP con otras aplicaciones II

2.1 ARQUITECTURA DE SOFTWARE

La arquitectura de software base está compuesta por: en su capa de persistencia con Sybase ASE como motor de bases de datos, en su capa de aplicaciones con el servidor de aplicaciones Sybase EAServer con componentes de negocio desarrollados en PowerBuilder y Struts en presentación, tal como lo muestra la gráfica.





Fecha: 14/11/2014


Pàgina 45 de 52

45

Gráfica 9 – Arquitectura de Software

En el 2014 SAP adquirió los productos del fabricante SYBASE, tales como Motores de Base de datos, Servidor de Aplicaciones EAServer, Bodega de datos y productos para desarrollo. SAP tomó la decisión de no evolucionar el producto EAServer Servidor de aplicaciones, generándonos un riesgo de obsolescencia tecnológica para los aplicativos cuya capa de negocio está atendida por el EAServer, como es el caso de la arquitectura definida al inicio del proyecto. Para mitigar el riesgo de obsolescencia anotado en el párrafo anterior Positiva definió la arquitectura más apropiada para un ambiente empresarial, de modo que fuera ágil, moderno, que siguiera los lineamientos que la industria del software y la academia recomiendan, y que permitiera mejorar la productividad en la construcción y/o mantenimiento del sistema de información. Se adoptó la nueva arquitectura soportada en software de código abierto, ampliamente probadas y soportadas por una activa comunidad de desarrolladores. Con esta nueva arquitectura se ha construido y puesto en operación en producción el módulo Manual único de Calificación de Invalidez – MUCI, cumpliendo con el Decreto 1507 de 2014, mejorando su funcionalidad y desempeño y logrando satisfacción de los usuarios finales. Igualmente está en proceso de implementación el liquidador de pensiones, el módulo de Incapacidad Permanente Parcial - IPP ajustado a la Resolución 1562, la administración de siniestros y el módulo de cuentas médicas. El sistema actual cuenta con un módulo de seguridad para la gestión de usuarios, roles y perfiles, así como la auditoría de transacciones del sistema.





Fecha: 14/11/2014


Pàgina 46 de 52

46

2.2 Arquitectura Inicial De Software

El Servidor de Aplicaciones es el EAServer, el cual permite realizar el desarrollo de la

capa de negocio en Power Builder, y a su vez estos componentes ser integrados a la

capa de presentación en JAVA mediante el uso de STRUTS.

El servidor EAServer enfrenta obsolescencia tecnológica por ser una aplicación de 32

bits que limita el uso de recursos de máquina, la ausencia de soporte por parte del

fabricante para versiones actuales de java y frameworks de presentación enriquecidos;

aspectos que repercuten sensiblemente en la escalabilidad del sistema, su desempeño y

sobre todo su disponibilidad. Esto sumado a que EAServer dejó de tener soporte por

parte del productor, exige tomar medidas tendientes a mejorar las condiciones en que

Positiva S.A y sus usuarios desarrollan las actividades misionales.

2.3 Arquitectura Evolutiva de Software

Se adoptó Spring + JPA/MyBatis + Vaadin por las siguientes características:

Fácil configuración inicial (Maven).

Independencia de IDE.

Máxima flexibilidad para implementación de funcionalidad.

Soporte para dependency injection, transaccionalidad y messaging, proporcionados por

Spring Framework.

Combinación usada más frecuentemente por otros desarrolladores.





Fecha: 14/11/2014


Pàgina 47 de 52

47

Gráfica 10 – Nueva Arquitectura SIARP

3. ALTERNATIVAS DE SOLUCIÓN TECNOLÓGICA CONTEMPLADOS

Con el fin de dar solución a la situación planteada y las necesidades de la compañía, se plantean dos escenarios a través de los cuales se podrá abordar la solución de software.

3.1 ALTERNATIVA (A): SOFTWARE A LA MEDIDA

Para esta alternativa, se solicitan los siguientes requerimientos tecnológicos que deben ser tenidos en cuenta en la solución planteada.

No. DESCRIPCIÓN DEL REQUERIMIENTO

REQUERIMIENTOS DEL SISTEMA

Requerimientos Tecnológicos

3.1.1. CAPÍTULO GENERALIDADES

3.1.1.1. Se requiere construir módulos adicionales que complementen la funcionalidad del sistema de información que actualmente opera en la compañía. Los módulos adicionales se deben construir utilizando las herramientas de desarrollo actuales y utilizando el software base instalado en la compañía.

3.1.1.2. Los módulos de software deberán ser construidos reutilizando diferentes componentes de software a nivel de capa de persistencia, capa de reglas de negocio o capa de presentación. Dichas soluciones deben ser parte integral del sistema de información que actualmente está en operación en la compañía.

Máquina Cliente

•Navegador

Servidor de Aplicaciones

• Framework Presentación

• Contenedor

• Persistencia

Servidor de Bases de Datos

• Sybase ASE





Fecha: 14/11/2014


Pàgina 48 de 52

48




3.1.1.3. Los módulos de software debe garantizar el correcto funcionamiento sobre los siguientes Web Browser como mínimo: Internet Explorer 8.x o superior Chrome 41.x o superior.

3.1.2. CAPÍTULO ADMINISTRACIÓN & GESTIÓN

3.1.2.1. El proponente debe presentar la metodología de Ingeniera de software que aplicará en la ejecución del contrato

3.1.2.2. El proponente debe presentar la metodología de gestión de proyectos que aplicará para le gestión del contrato

3.1.2.3. El proponente debe presentar el organigrama del equipo de trabajo que desarrollará el proyecto.

3.1.2.4. El proponente debe presentar los roles y sus respectivos perfiles del equipo de trabajo que desarrollará el proyecto

3.1.2.5. Los módulos que se desarrollen deben utilizar e integrarse con el módulo de gestión de usuarios del sistema de información actual.

3.1.2.6. El proveedor debe proveer los ambientes de desarrollo y pruebas unitarias. El ambiente de preproducción para las pruebas de aceptación será provisto y administrado por positiva S.A

3.1.3 CAPÍTULO ARQUITECTURA DE SOFTWARE

3.1.3.1. Los nuevos módulos de software deberán integrarse a la arquitectura, decir se deben generar archivos .jar integrables al proyecto de la aplicación existente.

3.1.3.2. Los nuevos módulos de software deben permitir la implementación de las diferentes capas (Presentación, Negocio, Persistencia) en diferentes servidores, debe permitir escalabilidad vertical y horizontal.

3.1.3.3. Los nuevos módulos de software deben ser construidos utilizando el Servidor de aplicaciones: JBOSS 6.X o superior

3.1.3.5. Los nuevos módulos de software deben ser construidos utilizando una base de datos Sybase ASE 15.X o Superior sobre Plataforma SUN SOLARIS 10 o Superior. Lo anterior para la capa persistencia.

3.1.3.6. Los nuevos módulos de software deben ser construidos con Lenguajes de Programación Orientados a Objetos (JAVA 8 o superior) utilizando el framework spring. Para el acceso a datos se debe utilizar el JPA (java persistence api/MyBatis Lo anterior para la capa de reglas de negocio.

3.1.3.7. Los nuevos módulos de software deben ser construidos sobre framework Vaadin. Lo anterior para la capa de presentación.

3.1.3.8. Los nuevos módulos de software deben ser construidos y permitir la asociación de imágenes digitales o documentos electrónicos permitiendo la integración con una solución de gestor documental de POSITIVA para las funcionalidades que lo requieran.

3.1.3.9. Los nuevos módulos de software deben ser construidos aplicando las mejores prácticas de Ingeniería de Software y se debe garantizar bajo acoplamiento entre los diferentes componentes del software. El proveedor debe presentar en la etapa





Fecha: 14/11/2014


Pàgina 49 de 52

49




correspondiente del ciclo de software la propuesta de diseño la cual será aprobada por Positiva S.A.

3.1.3.10. Los nuevos módulos de software deben integrarse con otros sistemas de información tanto internos como de terceros utilizando el modelo y plataforma de integración SOA de la compañía.

3.1.3.11. La solución de software debe tener definidos componentes de servicio para cada capa, facilitando la reutilización de los mismos y optimizando los tiempos de implementación de cambios al sistema

3.1.4. FIABILIDAD

3.1.4.1. Los nuevos módulos de software deben ser construidos garantizando la integridad en los datos y las operaciones sobre los mismos

3.1.4.2. Los nuevos módulos de software deben ser construidos con mecanismos de captura y manejo de errores de componentes, manejo de excepciones

3.1.5. USABILIDAD

3.1.5.1.

El software debe tener e integrar Ayudas en línea para cada uno de los módulos del sistema en español.

3.1.5.2. Todos los procesos o tareas que se ejecuten en el sistema de manera exitosa o defectuosa deben notificar al usuario en el momento que se interrumpa o culmine la operación de manera clara y en español

3.1.6. DOCUMENTACIÓN

3.1.6.1. El proponente debe elaborar y entregar toda la documentación definida tanto en la metodología de Ingeniería de Software.

3.1.6.2. El proponente debe elaborar y entregar toda la documentación definida tanto en la metodología de Gestión de Proyectos

3.1.7. DESEMPEÑO DE LOS NUEVOS MÓDULOS

3.1.7.1. Los módulos, funcionalidades a nivel de procesos batch deben tener tiempos de respuesta aceptables al proceso funcional y a la plataforma tecnológica de positiva. Para lo anterior el proveedor debe realizar el estudio de desempeño de los mismos y asegurar el afinamiento del software desarrollado.

3.1.7.2. Los módulos, funcionalidades a nivel transaccional deben asegurar tiempos de respuesta aceptables de máximo dos (2) segundos por transacción. En caso que la transacción específica no cumpla con este estándar el proveedor debe realizar el análisis necesario y suficiente para soportar la situación y proponer alternativas de solución.

3.1.7.3. El proveedor debe proveer los ambientes de desarrollo y pruebas unitarias. El ambiente de preproducción para las pruebas de aceptación será provisto y administrado por positiva S.A





Fecha: 14/11/2014


Pàgina 50 de 52

50

3.2 ALTERNATIVA (B): LICENCIAS DE USO

Para este escenario se solita los siguientes requerimientos tecnológicos que deben ser tenidos en cuenta en la solución planteada.




3.2.1. CAPÍTULO GENERALIDADES

3.2.1.1. La solución de software ofrecida deberá ser una sola aplicación que contenga todas las funcionalidades requeridas, no se acepta integración de dos o más aplicaciones.

El proveedor debe ser el propietario de la aplicación o ser distribuidor o representante autorizado por el fabricante para su comercialización y soporte.

3.2.1.2. Las herramientas de software base (base de datos, servidores de aplicación, etc.) sobre las cuales está construida la solución deben tener certificación de fabricante que garantice su evolución y soporte por al menos diez años. Las certificaciones deben ser expedidas por el fabricante propietario de las herramientas de software correspondiente.

3.2.1.3. La solución de software ofrecida deberá estar instalada y en operación en al menos dos (2) compañías de seguros en Colombia. La operación en tales compañía deben ser de al menos de dos (2) años. Se debe anexar las certificaciones expedidas por dichas compañías.

3.2.1.4. El proveedor debe presentar su modelo de soporte y mantenimiento de la solución.

3.2.1.5. El proveedor deberá presentar el organigrama, roles y perfiles con los que cuenta para prestar servicio de soporte a los clientes actuales.

3.2.1.6. El fabricante de la solución de software debe acreditar certificación CMMI nivel 3 como mínimo

3.2.2. CAPÍTULO ADMINISTRACIÓN & GESTIÓN

3.2.2.1. El proponente debe presentar la metodología de gestión de proyectos que aplicará para le gestión del contrato

El proponente debe presentar los roles y sus respectivos perfiles del equipo de trabajo que desarrollará el proyecto

3.2.2.2.

El proponente debe especificar la metodología propuesta para realizar la migración de la información histórica de la compañía a la aplicación.

3.2.2.3. El proponente debe detallar los costos de la migración de datos propuesta del sistema actual a la aplicación ofertada.

3.2.2.4.

El proponente debe contar un modelo de mesa de ayuda soportado en herramientas de software especializadas para este servicio. Se debe presentar documento que describa este servicio, indicando los niveles de escalamiento y ANS.

3.2.3. CAPÍTULO ARQUITECTURA DE SOFTWARE

3.2.3.1. La aplicación de software debe estar construida en ambiente web.

3.2.3.2. La aplicación de software debe estar construida en ambiente web y debe cumplir con el estándar W3C en nivel AAA.





Fecha: 14/11/2014


Pàgina 51 de 52

51




3.2.3.3. La aplicación de software debe estar construida en capas: Presentación, Negocio, Persistencia, las cuales permitan escalabilidad vertical y horizontal. Se debe presentar el documento que describa la arquitectura de la aplicación y su modelo de despliegue.

3.2.3.4. S debe presentar el modelo de arquitectura física requerida por la aplicación de software.

3.2.3.5. Se debe indicar si la aplicación de software utiliza una solución de gestor documental propio o de un tercer fabricante.

3.2.3.6. La aplicación de software debe tener mecanismos de integración otros sistemas de información tanto internos como de terceros utilizando el modelo y plataforma de integración SOA de la compañía.

3.2.3.7. La aplicación de software debe garantizar el correcto funcionamiento sobre los navegadores web. Se debe indicar sobre que navegadores y sus versiones está certificada la aplicación de Software.

3.2.4. FIABILIDAD

3.2.4.1. El software debe estar construido garantizando la integridad en los datos y las operaciones sobre los mismos

3.2.4.2. El software debe estar construido con mecanismos de captura y manejo de errores de componentes, manejo de excepciones

3.2.5. USABILIDAD

3.2.5.1. El software debe tener e integrar Ayudas en línea para cada uno de los módulos del sistema en español. 3.2.5.2.

3.2.5.3. Todos los procesos o tareas que se ejecuten en el sistema de manera exitosa o defectuosa deben notificar al usuario en el momento que se interrumpa o culmine la operación de manera clara y en español

3.2.5.4.

3.2.6. DOCUMENTACIÓN

3.2.6.1. El software debe contar con la documentación funcional y técnica. Se debe especificar qué tipo de documentación se ofrece y e que medio se entregará.

3.2.7. DESEMPEÑO DEL SISTEMA

3.2.7.1. El software debe asegurar tiempos de respuesta aceptables de máximo dos (5) segundos por transacción. En caso que la transacción específica no cumpla con este estándar el proveedor debe realizar el análisis necesario y suficiente para soportar la situación y proponer alternativas de solución.

3.2.7.2. Los módulos, funcionalidades a nivel de procesos batch deben tener tiempos de respuesta aceptables al proceso funcional y a la plataforma tecnológica de positiva. Para lo anterior el proveedor debe realizar el estudio de desempeño de los mismos y asegurar el afinamiento del software desarrollado.

3.2.8. CAPÍTULO SEGURIDAD & AUDITORÍA





Fecha: 14/11/2014


Pàgina 52 de 52

52




3.2.8.1. La aplicación de software debe contar con funcionalidades para la gestión de la seguridad y de auditoría. Se debe presentar documento describiendo el alcance de estas funcionalidades.

SOLICITUD DE INFORMACION (RFI-REQUEST FOR · PDF file- El proponente debe acreditar...

Documents

Transcript of SOLICITUD DE INFORMACION (RFI-REQUEST FOR · PDF file- El proponente debe acreditar...