PLIEGO DE CONDICIONES PARA LA ADQUISICION DE EQUIPOS, PRESTACION DE SERVICIOS E IMPLEMENTACION DEL SISTEMA CENTRAL DE PORTABILIDAD NUMERICA DEL SERVICIO MOVIL
PLIEGO DE CONDICIONES PARA LA ADQUISICION DE EQUIPOS, PRESTACION DE SERVICIOS E IMPLEMENTACION DEL SISTEMA CENTRAL DE PORTABILIDAD NUMERICA DEL SERVICIO MOVIL
ETCP 01/2017 V1
1.3 OBJETO DE LA LICITACIÓN. 4
1.6 PRESENTACIÓN DE PROPUESTAS 7
1.7 CONSULTAS Y ACLARACIONES 8
1.9 REVISIÓN Y MODIFICACIÓN XXX XXXXXX DE CONDICIONES 11
1.10 SOLICITUD DE AMPLIACIÓN DE ENTREGA DE OFERTAS 12
1.11 RESPONSABILIDAD DEL OFERENTE 12
1.12 ERRORES SUBSANABLES Y NO SUBSANABLES 12
2.1.1 DESCRIPCIÓN DE LA ARQUITECTURA 19
2.1.1.3 INFRAESTRUCTURA DE CONEXIÓN ENTRE EL SCP Y LOS OPERADORES Y PROVEEDORES 19
2.1.1.6 DISPONIBILIDAD Y RENDIMIENTO 20
2.1.1.7 CONFIABILIDAD Y SEGURIDAD 20
2.2.4 GESTOR DE PORTABILIDAD 23
2.2.5 BASE DE DATOS CENTRAL DE PORTABILIDAD NUMÉRICA - BDCP 23
2.2.5.2INFORMACIÓN CONTENIDA EN LA BASE DE DATOS 24
2.7.1 ADMINISTRACIÓN, MONITOREO, MANTENIMIENTO Y GESTIÓN DEL SCP 26
2.7.2 SOLUCIÓN DE PROBLEMAS DE USUARIOS 26
2.7.2.1 HERRAMIENTA PARA EL SEGUIMIENTO A PROBLEMAS DE USUARIOS 26
2.7.2.2 MONITOREO DE INCIDENCIAS 26
2.7.2.3 GESTIÓN, TRATAMIENTO Y SEGUIMIENTO XX XXXXXX 26
2.7.3 BACKUP Y RECUPERACIÓN DE INFORMACIÓN 27
2.7.4 IMPLEMENTACIÓN DEL SISTEMA 28
2.7.4.1IMPLEMENTACIÓN Y PUESTA EN OPERACIÓN 28
2.7.5 REQUERIMIENTOS DE CAMBIOS 28
2.7.9 ACEPTACIÓN DEL SISTEMA 30
2.7.10 DIRECCIÓN DE PROYECTOS (PMO) 31
TABLAS DE CUMPLIMIENTO DE REQUERIMIENTOS 35
3.1.1 LINEAMIENTOS DEL ESQUEMA DE PORTABILIDAD 35
3.1.2 XXXXXXXXXXXX XX XX XXXXXXXX 00
3.1.3 ARQUITECTURA DE HARDWARE Y SOFTWARE 40
3.1.4 SISTEMA CENTRAL DE PORTABILIDAD - SCP 41
3.1.5 PROCESOS Y GESTIÓN OPERATIVA DEL SCP 44
3.1.6.1ADMINISTRACIÓN DEL SCP 46
3.1.7 IMPLEMENTACIÓN DEL SISTEMA 49
3.1.8 REQUERIMIENTOS DE CAMBIOS 50
3.1.11 EXPERIENCIA DEL OFERENTE 53
3.1.13CUADRO DE CALIFICACIÓN CRITERIOS CALIFICABLES 54
ANEXO C 111
ARQUITECTURA GENERAL DE LA SOLUCION 111
ANEXO D 112
ACUERDO DE NIVEL DE SERVICIO 112
ANEXO E 123
MODELO DE CONTRATO 123
ANEXO F 139
PROCEDIMIENTO PARA MIGRACIÓN A UN NUEVO ASCP 139
ANEXO G 141
PROPUESTA ECONÓMICA 141
ANEXO H 144
CÓDIGO DE CONDUCTA DEL ASCP 144
ANEXO I 155
POLÍTICA DE ANTICORRUPCIÓN 155
ANEXO J 156
DECLARACIÓN DE INTEGRIDAD DEL PERSONAL DE LA EMPRESA
PROPONENTE 156
PLIEGO DE CONDICIONES PARA LA ADQUISICION DE EQUIPOS, PRESTACION DE SERVICIOS E IMPLEMENTACION DEL SISTEMA CENTRAL DE PORTABILIDAD NUMERICA DEL SERVICIO MOVIL
PARTE I INFORMACIÓN GENERAL
1.1 INTRODUCCIÓN
La Ley 164 General de telecomunicaciones, Tecnologías de la Información y Comunicación de 08 xx xxxxxx de 2011 y el decreto supremo N° 2498 del 26 xx xxxxxx de 2015 establecen los mecanismos para la implementación de la Portabilidad Numérica de los servicios de telecomunicaciones en Bolivia. Así mismo, la resolución administrativa regulatoria ATT-DJ-RA TL LP 1525/2015 y sus modificaciones establecen la normativa y el reglamento para la implementación del Sistema Central de Portabilidad como su administración y la integración con las bases de datos de portabilidad operativas de los operadores y proveedores de servicios de telefonía móvil.
1.2 CONVOCATORIA
Los operadores del servicio móvil en Bolivia convocan a Licitación Pública Internacional para seleccionar a la persona jurídica que se encargará de la provisión de equipos, prestación de servicios e implementación del Sistema Central de Portabilidad Numérica del Servicio Móvil.
La presente convocatoria será publicada en las páginas web de la Autoridad de Regulación y Fiscalización de Telecomunicaciones y Transportes (ATT) (xxx.xxx.xxx.xx); Empresa Nacional de Telecomunicaciones Sociedad Anónima - ENTEL S.A. (xxx.xxxxx.xx); Empresa de Telecomunicaciones Nuevatel PCS de Bolivia S.A. (xxx.xxxx.xxx.xx/xxxx) y Telefónica Celular de Bolivia S.A. (TELECELS.A.) (xxx.xxxx.xxx.xx) y por una sola vez en un diario de circulación nacional y/o a través de un medio de alcance internacional.
1.3 OBJETO DE LA LICITACIÓN.
El objeto de la Licitación es contratar una Persona Jurídica, responsable de la provisión, implementación, administración, operación, soporte, mantenimiento y seguridad del Sistema Central de Portabilidad Numérica del Servicio Móvil, solución técnica "All Call Query" (en adelante la Solución), conforme a los siguientes ítems:
1) Adquisición de equipos (Hardware) conforme a las especificaciones Técnicas requeridas en el presente documento.
2) Derecho de uso (licencia) de software (Gestor de Portabilidad, plataforma, Motor de Bases de Datos y toda licencia que permita el funcionamiento del SCP).
3) Implementación, pruebas de aceptación y puesta en marcha de la solución.
4) Administración del Hardware y Software de la Solución.
5) Mantenimiento, soporte y capacitación del hardware y software de la Solución.
El Sistema Central de Portabilidad Numérica del Servicio Móvil deberá estar localizado en el territorio del Estado Plurinacional de Bolivia, en la ciudad de La Paz, de acuerdo a las condiciones establecidas en el presente documento.
1.4 ANTECEDENTES
En el marco de lo dispuesto por el parágrafo V del Articulo 52 de la Ley N° 164 que determina que se establecerá mediante norma expresa que las usuarias o usuarios de los servicios de telecomunicaciones puedan conservar los números que les hayan sido asignados por el operador inicial, es que el Gobierno del Estado Plurinacional de Bolivia promulgó el Decreto Supremo 2498 de fecha 26 xx Xxxxxx de 2015 que establece los mecanismos para la implementación de la portabilidad numérica.
El citado Decreto Supremo dispone que la portabilidad numérica en los servicios de telecomunicaciones es de cumplimiento obligatorio de todos los operadores y proveedores, los cuales deberán acatar lo establecido en los reglamentos técnicos de portabilidad numérica que se aprueben para este fin.
En virtud a los preceptos antes mencionados, la ATT emitió la Resolución Administrativa Regulatoria ATT-DJ-RA TL LP 1525/2015 de fecha 26 de Noviembre de 2015 (en adelante RAR 1525/2015), resolviendo aprobar el Reglamento Técnico de Portabilidad Numérica del Servicio Móvil, modificado con posterioridad mediante la RAR ATT-DJ-RAR- TL LP 583/2017 de fecha 00 xx xxxxx xx 0000(xx adelante RAR 583/2017)
La normativa precedentemente citada, definió la solución técnica denominada "All Call Query' - Consulta de Todas las Llamadas–así como que el Sistema Central de Portabilidad Numérica – SCP está compuesto por infraestructura de hardware y software.
De conformidad con los artículos 7 y 8 del Reglamento Técnico de Portabilidad Numérica del servicio móvil se conformó el Equipo Técnico Consultivo de Portabilidad Numérica (ETCP) que elaboró y propuso a la ATT, el Pliego de Condiciones, el mecanismo del proceso de selección del ASCP y el modelo de contrato, los cuales fueron aprobados en todo su contenido por la ATT.
1.5 DEFINICIONES
Además de las definiciones establecidas en la Ley N°164, el D.S. 1391, el D.S. 2498, RAR 1525/2015 y la RAR 583/2017, que aprueban el Reglamento Técnico de Portabilidad Numérica del Servicio Móvil, los términos que se definen en el presente numeral y que se emplean en el transcurso del documento, tendrán los significados que a continuación se les atribuye:
ATT (Autoridad de Regulación y Fiscalización de Telecomunicaciones y Transportes): Ente regulador y fiscalizador delos sectores de Telecomunicaciones, Transportes y Postal en el Estado Plurinacional de Bolivia.
Adjudicatario: Es el oferente ganador de la presente Licitación
Administrador del Sistema Central de Portabilidad Numérica - ASCP: Es la persona jurídica contratada que es responsable de la implementación, administración, operación, gestión y seguridad del Sistema Central de Portabilidad Numérica.
Asociación Accidental: Es el contrato de cuentas en participación cuando dos o más personas toman interés en una o más operaciones determinadas y transitorias, a cumplirse mediante aportaciones comunes, llevándose a cabo las operaciones por uno o más o todos los asociados, según se convenga en el contrato, conforme a las formalidades establecidas. Para la presente Licitación uno de los asociados necesariamente deberá ser una persona jurídica constituida en el Estado Plurinacional de Bolivia.
Base de Datos Central de Portabilidad Numérica - BDCP.- Base de datos que contiene toda la información necesaria para viabilizar todo el proceso de Portabilidad Numérica, que entre otras, posee una base de datos de información de números portados, base de datos de información necesaria de orden administrativa, base de datos de información histórica, bases de datos de trazabilidad (registros de eventos, auditoría y otros relacionados), que es actualizada, gestionada y administrada por el ASCP de acuerdo al proceso de Portabilidad Numérica.
Base de Datos de Portabilidad Numérica Operativa (BDPO): Base de datos que contiene la información necesaria para el proceso de Portabilidad Numérica, misma que se encuentra en la red del operador del servicio móvil y es administrada por éste, la misma se actualiza periódicamente con información de la Base de Datos Central de Portabilidad Numérica del SCP.
Comisión de Calificación: Es aquel grupo de trabajo conformado por personal acreditado por cada uno de los Operadores y proveedores para la evaluación y calificación de propuestas.
Consulta de toda llamada (All Call Query): Solución técnica basada en el enrutamiento de llamadas previa consulta a una base de datos.
Contrato: Acuerdo entre partes que, empleando el Modelo de Contrato, suscribirá el Adjudicatario con los Operadores y proveedores, para la provisión de equipos y prestación de sus servicios, en el marco de la portabilidad numérica del servicio móvil.
Help Desk: Es un conjunto de recursos tecnológicos y humanos, para prestar servicios con la posibilidad de gestionar y solucionar todas las posibles incidencias de manera integral, junto con la atención de requerimientos relacionados a las Tecnologías de la Información y la Comunicación (TIC).
Licitación: Es el proceso de contratación convocado por los operadores del servicio móvil en Bolivia para elegir a la persona jurídica, que proveerá el equipamiento y prestará servicios de Portabilidad Numérica del servicio móvil.
Modelo de Contrato: Texto base a ser utilizado para la suscripción del Contrato, determinado en el Anexo X xxx Xxxxxx de Condiciones.
Oferente: Participante en el proceso de Licitación Pública Internacional de selección del Proveedor.
Pliego de Condiciones: Es el documento que incluye especificaciones técnicas, términos de referencia, Service Level Agreement (SLA), metodología de evaluación, procedimientos, condiciones, formatos, anexos y modificaciones, que fija los términos bajo los cuales se desarrollará la Licitación Pública Internacional del proceso de contratación.
PMO (Project Management Office/Oficina de Gestión de Proyectos): Unidad del Adjudicatario para centralizar y coordinar la dirección de proyectos a su cargo.
Reglamento Técnico de Portabilidad Numérica de Servicio Móvil: Reglamento aprobado mediante RAR 1525/2015 y modificado por la RAR 583/2017, que establecen el marco reglamentario de los aspectos técnicos, económicos y administrativos para la implementación de la Portabilidad Numérica del servicio móvil en aplicación de la Ley Nº 164 General de Telecomunicaciones, Tecnologías de Información y Comunicación del 8 xx xxxxxx de 2011 y del Decreto Supremo Nº 2498 de 26 xx xxxxxx de 2015.
Sistema Central de Portabilidad SCP: Compuesto por infraestructura de hardware y Software que permite a los Operadores o Proveedores del Servicio Móvil el intercambio de información para todo el proceso de Portabilidad Numérica, como ser: el Gestor de Portabilidad Numérica, Base de Datos Central de Portabilidad Numérica [BDCP] y otros relacionados, y es administrado por el ASCP.
SLA: (Service Level Agreement/Acuerdo de Nivel de Servicio): Documento técnico donde se indica los niveles de servicio requeridos.
Huso Horario Aplicado al Presente Documento: Corresponde al huso horario GMT -4 (hora en Bolivia).
Los términos no definidos en el presente numeral, se deberán entender conforme al significado que tienen según el Reglamento de Portabilidad Numérica y, en defecto de éste, de las normas aplicables.
1.6 PRESENTACIÓN DE PROPUESTAS
Las propuestas deberán presentarse en las oficinas de la ATT ubicadas en la Xxxxx 00 xx Xxxxxxxx Xxx. 0000 xx xx xxxxxx xx Xx Xxx, dirigido al Presidente de la Comisión de Calificación, hasta el día:
Fecha: | 1 de diciembre de 2017 |
Hora: | 10:00 am |
No serán aceptadas ni consideradas las propuestas recibidas en oficinas postales o cualquier otro lugar, aunque fueran dependencias de la ATT diferente al domicilio señalado en el párrafo precedente y tampoco serán consideradas las propuestas entregadas pasados el día y hora límite, señalados.
Las propuestas de los oferentes deberán estructurarse de acuerdo a las siguientes instrucciones:
SOBRE “A” – DOCUMENTOS ADMINISTRATIVOS (Un ejemplar).
SOBRE “B” – PROPUESTA TÉCNICA (1Original + 3 Copias Digitales escaneadas del original y una copia en formato “pdf” exportado desde un procesador de texto).
SOBRE “C” – PROPUESTA ECONÓMICA (1 Original + 3 Copias Digitales escaneadas del original y una copia en formato “pdf” exportado desde un procesador de texto)
Cada uno de los sobres serán presentados cerrados de manera separada; la Parte Técnica y la Parte Económica deberán contener las copias digitales de los documentos correspondientes; los originales deberán ser foliados, sellados y presentados con la siguiente inscripción:
COMISION DE CALIFICACION LICITACION PUBLICA INTERNACIONAL
“ADQUISICION DE EQUIPOS, PRESTACION DE SERVICIOS E IMPLEMENTACION DEL SISTEMA CENTRAL DE PORTABILIDAD NUMERICA DEL SERVICIO MOVIL”
RAZON SOCIAL DEL OFERENTE TELEFONO – EMAIL
PERSONA DE CONTACTO: SOBRE “…x…”:
La apertura de sobres se efectuará en un acto público, en las oficinas de la ATT ubicado en la calle 13 de Calacoto Nro. 8260 de la ciudad de La Paz, el día:
Fecha: | 1 de Diciembre de 2017 |
Hora: | 10:30 Sobre A |
Fecha: | 4 de diciembre de 2017 |
Hora: | 10:30 Sobre B |
1.7 CONSULTAS Y ACLARACIONES.
Los Oferentes podrán efectuar consultas respecto al Pliego de Condiciones de la Licitación únicamente por las siguientes vías:
a.) E-mail dirigido a xxxxxxxxxxxxxxxxxxx@xxx.xxx.xx en formato digital editable (Word).
b.) Consultas escritas dirigidas a LA COMISIÓN DE CALIFICACIÓN en la dirección: Xxxxx 00 Xx. 0000 Calacoto, entre Av. los Sauces y Av. Costanera. La Paz – BOLIVIA y formato digital editable (Word)
Estas consultas deberán ser formuladas en idioma castellano hasta horas 17:00 del 10 de noviembre del 2017.
En fecha 14 de noviembre de 2017se llevará a cabo la Reunión de Aclaración en las oficinas de la ATT, ubicadas en la xxxxx 00 xx Xxxxxxxx Xxx. 0000 xx xx xxxxxx xx Xx Xxx a horas 09:00 a.m., en la que se absolverán todas las consultas realizadas por los Oferentes.
Cualquier consulta adicional realizada y/o que se presenten en la Reunión de Aclaración será respondida por la Comisión de Calificación, hasta tres (3) días hábiles posteriores a la conclusión de la reunión, mediante publicación en las páginas web antes mencionadas.
1.8 PROPUESTAS.
1.8.1 FORMA DE PRESENTACIÓN.
Los Oferentes deberán presentar su propuesta por escrito en idioma castellano, sin tachaduras ni enmendaduras, debidamente foliada y suscrita por el representante legal del Oferente en cada folio hasta la fecha señalada en el presente Pliego de Condiciones.
Los documentos en idioma distinto al castellano deberán ser acompañados por su correspondiente traducción simple.
Los folletos técnicos y/o manuales de usuario podrán ser entregados en inglés, sin requerir de traducción.
1.8.2 CONTENIDO.
El contenido de los tres (3) sobres debe ser el siguiente:
1.8.2.1 Sobre A “Documentos Legales y Administrativos”:
Carta de Presentación firmada por el representante y/o apoderado legal.
En caso de Empresas nacionales deberá presentar los siguientes documentos en fotocopias simples:
Documentos de constitución de las empresas inscritos y resellados en el Registro de Comercio (FUNDEMPRESA) de acuerdo a la legislación nacional.
Matrícula de Comercio vigente.
Poder de Representación Legal del oferente con facultades para presentar propuestas y suscribir contratos, inscrito y resellado en el Registro de Comercio.
Certificado de Identificación Tributaria del NIT vigente.
Las empresas extranjeras deben presentar fotocopias simples de los documentos vigentes equivalentes a los solicitados emitidos por la entidad correspondiente en su país, con una nota aclaratoria y traducida al castellano para que sean evaluados por la Comisión de Calificación.
En caso de Asociación Accidental presentar en fotocopia simple:
Testimonio de la Asociación Accidental, que indique el porcentaje de participación de los asociados, la designación de la empresa líder, la empresa que emitirá la nota fiscal, la nominación del Representante Legal de la Asociación y el domicilio legal; así como fotocopias simples del Testimonio de Constitución y la última modificación al mismo de cada Asociado y un certificado de tradición comercial vigente o equivalente para el caso de empresas extranjeras.
Poderes de los Representantes Legales de cada uno de los asociados, resellados en FUNDEMPRESA (vigentes) mencionando las facultades otorgadas al apoderado para participar en procesos de contratación, presentación de propuestas y suscripción de contratos para la provisión/prestación de bienes o servicios. En el caso de empresas extranjeras, la documentación equivalente.
Matrículas de Comercio vigentes de todos los asociados. En el caso de empresas extranjeras, la documentación equivalente.
Certificado de Identificación Tributaria del NIT vigente de las empresas que conforman la Asociación Accidental. En el caso de empresas extranjeras, la documentación equivalente.
Adicionalmente y para ambos casos:
Tres Boletas de Garantía de Seriedad de Propuesta cada una por un valor de Bs 50.000,00.- (Cincuenta mil 00/100 Bolivianos) con las características de renovable, irrevocable, de ejecución inmediata y a primer requerimiento a favor de cada una de las siguientes empresas: Empresa Nacional de Telecomunicaciones Sociedad Anónima - ENTEL S.A.; Empresa de Telecomunicaciones Nuevatel PCS de Bolivia S.A. y Telefónica Celular de Bolivia S.A. (TELECEL S.A.) emitida por una institución bancaria legalmente constituida en el Estado Plurinacional de Bolivia con una validez de 120 días calendario, a partir de la fecha de presentación de propuesta.
Fotocopia simple de la póliza (general o específica) de responsabilidad civil general y operacional, responsabilidad contractual, extracontractual, daños a la propiedad y daños humanos.
Fotocopia simple de la póliza de seguro contra accidentes personales.
Fotocopias simple de la Cédula de Identidad o Pasaporte vigentes de cada Representante legal, según corresponda.
Fotocopia simple de los Estados Financieros auditados de la última gestión de cada asociado y en caso de empresas extranjeras documento equivalente.
Declaración del oferente sobre el período de validez de la propuesta equivalente a ciento veinte (120) días calendario, a partir de la fecha de presentación de la propuesta.
Declaración de Integridad firmada por el representante legal de cada proponente según Xxxxx X.
1.8.2.2 Sobre B “OFERTA TECNICA” conteniendo todos los requisitos y disposiciones solicitadas en las especificaciones técnicas (Parte II “Información Técnica de la Contratación”). No debe contener precios totales, parciales o referenciales de ningún tipo. La columna de respuestas debe ser llenada obligatoriamente con las referencias precisas y exactas (documento, página, referencia) y sin añadir comentario y/o condiciones adicionales.
La inclusión de precios totales, parciales o referenciales dará lugar a la descalificación de la oferta.
1.8.2.3 Sobre C “OFERTA ECONOMICA” conteniendo su propuesta de acuerdo a lo especificado en el Anexo G.
Toda la propuesta económica, el proceso de contratación, incluyendo los pagos a realizar, deben expresarse y efectuarse en moneda nacional (boliviano), incluyendo los impuestos xx xxx.
El proponente puede presentar toda consideración de índole económico-financiera que considere útil y apropiada para la evaluación de su propuesta.
En caso de discrepancia entre un precio unitario y el total o entre los montos en numeral y literal, se considerará al precio menor como el correcto.
En caso de ser necesario, la Comisión de Calificación podrá solicitar una mayor desagregación de los precios al proponente, quien está en la obligación de suministrar oportunamente toda la información requerida.
Empresas extranjeras y/o nacionales que consideren en su propuesta económica pagos al extranjero que generen impuestos por remesas al exterior ya sea por concepto de servicios, licencias de software (bienes intangibles) y otros, deben incluirlos en su propuesta económica de acuerdo a los porcentajes y/o montos que son establecidos en la normativa vigente en Bolivia.
1.9 REVISIÓN Y MODIFICACIÓN XXX XXXXXX DE CONDICIONES
Los convocantes se reservan el derecho de revisar y modificar los términos del presente documento y sus anexos durante cualquier etapa del proceso de contratación. De producirse esta situación las modificaciones serán comunicadas oportunamente mediante las páginas web de los operadores y de la ATT.
Las modificaciones requeridas no constituirán causal de indemnización de ningún tipo por parte de los proponentes y/o interesados.
1.10 SOLICITUD DE AMPLIACIÓN DE ENTREGA DE OFERTAS
Los oferentes podrán solicitar vía e-mail la ampliación del plazo de presentación de propuestas, hasta dos (2) días hábiles antes del plazo de entrega establecido para la presentación de las ofertas.
Si existiesen solicitudes de ampliación de plazo de entrega de ofertas, la Comisión de Calificación podrá aceptar previa evaluación del caso y su decisión será comunicada dentro de las veinticuatro
(24) horas de recibida la notificación a través de las páginas web indicadas en el presente documento.
El tiempo de ampliación del plazo de entrega de ofertas dependerá del análisis que realice la Comisión de Calificación en cada caso.
1.11 RESPONSABILIDAD DEL OFERENTE
El Oferente será el único responsable ante los convocantes de la oferta que presente, sin perjuicio de la responsabilidad solidaria que asuman sus asociados, conforme a las condiciones xxx Xxxxxx de Condiciones.
Las subcontrataciones en las que pueda incurrir el Adjudicatario para cumplir con las obligaciones que se deriven xxx Xxxxxx de Condiciones y el Contrato, no implicará en ningún caso que su responsabilidad frente a los convocantes sea transferida a los subcontratistas. La subcontratación no implicará en ningún caso que los subcontratistas tengan acceso a la información de datos personales de los usuarios. Todos los oferentes deberán basar su decisión de presentar su oferta en sus propias investigaciones, exámenes, análisis y conclusiones sobre la información disponible y la que de manera particular hayan procurado, a su propio costo y entero riesgo.
Será responsabilidad de los Oferentes correr con todos los gastos relacionados a la preparación y presentación de ofertas. Los operadores del servicio móvil no serán responsables en ningún caso por dichos costos, cualquiera sea su resultado.
El oferente adjudicado deberá realizar las acciones que aseguren el funcionamiento óptimo del Sistema Central de Portabilidad Numérica, de acuerdo a las reglas establecidas en el marco normativo vigente.
1.12 ERRORES SUBSANABLES Y NO SUBSANABLES
Se consideran las siguientes definiciones:
1.12.1 ERRORES SUBSANABLES: Son los que inciden sobre aspectos no sustanciales, sean accidentales, accesorios o de forma, sin afectar la legalidad ni la solvencia de las propuestas. Es susceptible de ser rectificado siempre y cuando no afecte los términos y condiciones de la propuesta, no conceda ventajas indebidas en detrimento de los otros proponentes y no se considere omisión de la presentación de documentos.
Todo error considerado subsanable deberá ser enmendado en un plazo perentorio de 2 días hábiles a partir de su notificación legal y será consignado en el Informe Final de la Comisión de Calificación.
1.12.2 ERRORES NO SUBSANABLES: Son considerados errores no subsanables, siendo objeto de descalificación, los siguientes:
La ausencia de la carta de presentación de la propuesta firmada por el Representante Legal del Oferente.
La ausencia de la Propuesta Técnica.
La ausencia de la Propuesta Económica.
La ausencia de Testimonio de la Asociación Accidental o de documentos de constitución de la empresa, cuando corresponda.
La ausencia del Poder del Representante Legal con las facultades respectivas.
La ausencia de Boleta Bancaria de Garantía de Seriedad de Propuesta y si presentada esté girada con una variación numérica superior al 0.05% o plazo de vigencia menores a los requeridos o su emisión sea errónea (salvo errores literales hasta en tres silabas, los que se considerarán subsanables) o no cumpla con alguna de las características requeridas.
Cuando se omita la presentación de cualquier documento requerido en el Pliego de Condiciones de forma obligatoria.
1.13 APERTURA DE SOBRES
La apertura de los sobres seguirá el siguiente procedimiento:
1.13.1 Se realizará la apertura del sobre “A” en el Acto Público de Apertura de Sobres en la fecha y hora establecidos en el Pliego de Condiciones, salvo el establecido en una comunicación oficial emitida por la Comisión de Calificación.
La Comisión de Calificación procederá a la revisión de los documentos administrativos (sobre “A”) de todos los oferentes y realizará la habilitación (considerando errores subsanables) o inhabilitación de los Oferentes que tengan errores no subsanables.
1.13.2 Se realizará la apertura del sobre “B” de los Oferentes habilitados en el sobre “A”, en acto público en la fecha y hora indicada en el Pliego de Condiciones. La Comisión de Calificación procederá a la revisión de la propuesta técnica (sobre “B”) de todos los oferentes y realizará la habilitación o inhabilitación de los Oferentes que no cumplan con los requisitos.
1.13.3 La apertura del sobre “C” de los Oferentes habilitados en el sobre “B”, se realizará en sesión reservada.
1.14 CRITERIOS DE EVALUACIÓN DE PROPUESTAS TÉCNICAS.
La forma de calificación está relacionada al cumplimiento estricto de lo solicitado en las Especificaciones Técnicas y que ponderado tendrá un valor 30%.
La calificación estará basada en la columna de respuestas (Parte III Tabla de Cumplimiento de Requerimientos), misma que deberá ser llenada con carácter obligatorio, incluyendo referencias precisas y exactas (documento, página, referencia) y sin añadir comentario y/o condiciones adicionales.
Para los incisos marcados como MANDATORIO, la calificación será CUMPLE o NO CUMPLE. Mientras que los incisos marcados como CALIFICABLE, se basarán en la tabla de calificación de Criterios Calificables y las fórmulas de calificación adjuntas a este documento.
A continuación se definen las palabras CUMPLE, NO CUMPLE:
CUMPLE: Xxxxxx que satisface completamente el requisito técnico requerido, de acuerdo a lo solicitado en el Pliego de Condiciones y se entiende que está incluida en la propuesta Técnica del Oferente.
NO CUMPLE. Define que no satisface los requisitos técnicos establecidos en el Pliego de Condiciones, lo que dará lugar a la inhabilitación de la propuesta.
1.14.1 CRITERIOS MANDATORIOS
Estos requisitos deben ser cumplidos por el Oferente para que su propuesta sea considerada, si alguno de estos puntos no fuera cumplido, la oferta será excluida.
1.14.2 CRITERIOS CALIFICABLES
Los criterios Calificables, serán evaluados de acuerdo a las siguientes formulas.
Fórmula para los puntos CALIFICABLES en los que se requiere menor tiempo/sensibilidad y otros es: (variables de TIEMPO)
Dónde:
C_Mínima = Cantidad mínima ofrecida de todas las propuestas. C_Ofrecida = Cantidad ofrecida en la propuesta.
Ponderación = De acuerdo a tabla de Calificación Técnica
La fórmula para la calificación de ítems en los que se requiere la mayor cantidad/capacidad y otros es: (variables de CANTIDAD)
Dónde:
C_Ofrecida = Cantidad ofrecida en la propuesta.
C_Máxima = Cantidad máxima ofrecida de todas las propuestas. Ponderación = De acuerdo a tabla de Calificación Técnica
La ponderación está descrita en la PARTE III del presente documento.
1.15 EVALUACIÓN DE LA PROPUESTA ECONÓMICA
La calificación de la oferta económica considerará todos los requerimientos económicos solicitados y que ponderado tendrá un valor de 70% en la calificación final.
Para obtener la calificación de precios (esto es traducir los precios resultantes de la aplicación del modelo en puntos), la puntuación de cada oferta (i) será obtenida mediante la siguiente fórmula:
Dónde:
Pmejor = Precio más bajo de todas las ofertas que hubiesen aprobado la calificación del sobre “B”
Pi = Es el precio de la oferta i.
Al resultado obtenido para cada oferta i se le aplicará la ponderación correspondiente al precio (70%), obteniéndose de esta manera el puntaje final obtenido por la oferta económica i.
1.16 CALIFICACIÓN FINAL
Es el resultado del promedio ponderado de las calificaciones obtenidas, en las evaluaciones Técnicas y Económicas, para tal efecto se considerará la siguiente distribución:
Aspecto | Ponderación |
Técnico | 30 % |
Económico | 70 % |
Total | 100% |
1.17 ADJUDICACIÓN
Una vez emitido el informe final, se procederá con el envío de la carta de adjudicación al Oferente adjudicado y al envío de la comunicación de no adjudicación a los demás oferentes.
El Oferente adjudicado contará con un plazo no mayor a cinco (5) días hábiles para dar respuesta de Aceptación/Rechazo a la nota de adjudicación.
En caso de aceptación, el adjudicatario tendrá un plazo de quince (15) días hábiles a partir de la notificación de adjudicación para adjuntar toda la documentación solicitada en la Carta de Adjudicación, plazo que podrá ser prorrogado a requerimiento del oferente y aceptación de al menos dos de los convocantes.
Asimismo, el adjudicatario acepta mediante nota escrita iniciar el cronograma de implementación a la aceptación de la Carta de Adjudicación, debiendo nombrar en la misma nota a su PMO.
El incumplimiento a estos plazos y la falta de presentación de la documentación será causal para dejar sin efecto la Carta de Adjudicación y se procederá con la ejecución de la Boleta de Garantía de Seriedad de Propuesta y se adjudicará a la segunda propuesta mejor calificada siempre y cuando convenga a los intereses de los operadores móviles.
Si el oferente adjudicado desistiera de suscribir el contrato, se procederá a la ejecución de la Boleta de Garantía de Seriedad de Propuesta y se procederá a la adjudicación de la segunda propuesta mejor calificada siempre y cuando convenga a los intereses de los convocantes.
1.18 SUSCRIPCIÓN DE LOS CONTRATOS
Para efectos de la suscripción del Contrato, el Adjudicatario deberá presentar la siguiente documentación en original o fotocopias debidamente legalizadas en tres (3) ejemplares:
En caso de Empresas nacionales, legalmente constituidas y reconocidas conforme a la legislación boliviana:
1. Constitución de Sociedad y última modificación a la misma (si corresponde) debidamente inscrita en el Registro de Comercio (FUNDEMPRESA).
2. Certificado de tradición comercial.
3. Matrícula de Comercio actualizada.
4. Poder de Representación Legal del oferente con facultades para presentar propuestas y suscribir contratos, inscrito y resellado en el Registro de Comercio (FUNDEMPRESA).
5. Certificado de Identificación Tributaria del NIT vigente.
En caso de Asociación Accidental:
1. Testimonio de la Asociación Accidental, que indique el porcentaje de participación de los asociados, la designación de la empresa líder, la empresa que emitirá la nota fiscal, la nominación del Representante Legal de la Asociación y el domicilio legal en Bolivia.
2. Poder del representante legal de la asociación accidental con facultades para presentar propuestas y suscribir contratos.
3. Fotocopias legalizadas y/u Originales del Testimonio de Constitución y última modificación a la misma, de cada uno de los asociados, debidamente inscrito ante FUNDEMPRESA.
4. Certificado de tradición comercial de cada uno de los asociados.
5. Poderes de los Representantes Legales de cada uno de los asociados, resellados en FUNDEMPRESA (vigentes) mencionando las facultades otorgadas al apoderado para participar en procesos de licitación, presentación de propuestas y suscripción de contratos para la provisión/prestación de bienes o servicios.
6. Fotocopias legalizadas de las Matriculas de Comercio ante FUNDEMPRESA (vigentes) de cada uno de los asociados.
7. Certificado de Identificación Tributaria del NIT vigente de las empresas que conforman la Asociación Accidental.
Adicionalmente y para ambos casos:
8. Tres Boletas Bancarias de Garantía de Cumplimiento de Contrato a favor de cada una de las siguientes empresas: - Empresa Nacional de Telecomunicaciones Sociedad Anónima - Entel S.A.; Empresa de Telecomunicaciones Nuevatel PCS de Bolivia S.A. y Telefónica Celular de Bolivia S.A. (TELECEL S.A.); cada una por un tercio (1/3) del valor total, que sumadas equivaldrán al 10% del monto adjudicado en caso de retribución fija, o a un monto estimado por los contratantes en caso de las otras modalidades.
Dichas Boletas deberán consignar las características de renovable, irrevocable, de ejecución inmediata y a primer requerimiento, emitidas por una entidad bancaria regulada y autorizada por la ASFI y a satisfacción de los contratantes.
Las Boletas de Garantía de Cumplimiento de Contrato, deberán estar vigentes durante el periodo total del contrato más (60) sesenta días calendario.
9. Fotocopia simple de la Cedula de Identidad o Pasaporte vigente de cada Representante legal según corresponda.
Las empresas extranjeras deberán presentar en original o copia legalizada ante autoridad competente, la documentación equivalente a la solicitada a las empresas constituidas en el Estado Plurinacional de Bolivia y traducidas al idioma castellano.
1.19 CANCELACIÓN, ANULACIÓN Y/O SUSPENSIÓN
Sin limitar este derecho, se podrá suspender, cancelar o declarar anulada y sin efecto la presente convocatoria, en cualquier etapa previa a la suscripción del contrato por las razones siguientes:
a) Cuando exista un hecho de fuerza mayor y/o caso fortuito irreversible que no permita la continuidad del proceso, o en su defecto porque la necesidad de contratación se haya extinguido.
b) Cuando se determine incumplimiento o inobservancia al procedimiento para la adquisición respectiva y/o desvirtúe la legalidad y validez del proceso.
c) Cuando a juicio de los operadores del servicio móvil, las ofertas no se adecuen a sus intereses y/o a las normas y procedimientos legales vigentes.
Los convocantes no asumirán responsabilidad alguna respecto a los proponentes afectados por esta decisión.
1.20 RECHAZO DE PROPUESTAS
Se podrá rechazar las propuestas, de acuerdo a las siguientes causales:
a) Ofertas presentadas fuera de fecha y hora establecidas en el Pliego de Condiciones.
b) Ofertas que tengan raspaduras, alteraciones o enmiendas.
c) Ofertas que no cumplan con cualquiera de las especificaciones descritas en el Pliego de Condiciones.
d) Cuando a juicio de los operadores del servicio móvil, los precios ofertados no guarden relación con el mercado.
e) Los operadores del servicio móvil se reservan el derecho de desestimar cualquier propuesta, si a su juicio ésta no satisface sus expectativas y necesidades en el marco del presente Pliego de Condiciones;
f) Si el Oferente tiene alguna controversia con alguno de los contratantes.
1.21 DECLARATORIA DESIERTA
En caso que la licitación se declare desierta, los operadores del servicio móvil podrán realizar la contratación directa del proveedor del SCP.
1.22 MULTAS
1.22.1 IMPLEMENTACIÓN
Si existiesen atrasos en los plazos acordados en el cronograma establecido para la implementación por el Adjudicatario imputables al mismo, este será sujeto a una multa equivalente al cero cinco por ciento (0,5%) del Monto Total del Contrato por cada día calendario de retraso, independientemente del pago de daños y perjuicios que generen los retrasos.
Las multas acumuladas por el retraso del Adjudicatario no podrán ser superiores al veinte por ciento (20%) del Monto total del Contrato.
1.22.2 OPERACIÓN
El régimen de multas se halla específicamente establecido en el Anexo “D” (Service Level Agreement).
Se aclara que el pago de multas (implementación y/o operación) no eximirá al Adjudicatario de su obligación de cumplir con las demás obligaciones y de responder por las emergencias de su incumplimiento según lo estipulado en el Contrato, más daños y perjuicios que emerjan de tales incumplimientos.
PARTE II
El Oferente debe presentar su oferta técnica para la implementación de un Sistema Central de Portabilidad y su Administración con fines de permitir los procesos de Portabilidad numérica entre los operadores y proveedores del servicio móvil en el Estado Plurinacional de Bolivia.
El Sistema Central de Portabilidad debe estar localizado en territorio del Estado Plurinacional de Bolivia.
Se establece que el intercambio de información entre los Operadores y Proveedores Donante y Receptor y el Administrador del Sistema Central de Portabilidad, debe ser automatizado mediante sistemas informáticos y medios electrónicos, de forma tal que se garantice rapidez, integridad, disponibilidad y seguridad en el desarrollo del Proceso de Portación y transacciones inherentes al servicio.
2.1 ARQUITECTURA DE LA SOLUCIÓN
Cumpliendo con las disposiciones mencionadas en el Reglamento Técnico de Portabilidad Numérica del Servicio Móvil, se requiere que el oferente presente una propuesta de arquitectura para la solución de portabilidad numérica, tanto a nivel de hardware como de software, que cumpla con las condiciones técnicas, operativas y administrativas expuestas a lo largo de la presente sección y que contenga mínimamente las características de la arquitectura descrita en el Anexo C.
2.1.1 DESCRIPCIÓN DE LA ARQUITECTURA
La solución técnica solicitada se describe como un Sistema Central de Portabilidad que en consideración a lo establecido en el Reglamento de Portabilidad Numérica, debe incluir, como mínimo, las siguientes características:
2.1.1.1 SOLUCIÓN DE ALTA DISPONIBILIDAD
Mecanismos y políticas para gestionar un sistema de respaldo y recuperación de información a nivel de hardware y software, instalado en el estado plurinacional de Bolivia, que garantice el mínimo tiempo de inactividad ofreciendo integridad de la información, continuidad de funcionamiento y seguridad de todo el sistema y la información contenida en el mismo.
2.1.1.2 INTERFACES
Corresponde a mecanismos y protocolos estandarizados de software y hardware con la función de proveer los medios que faciliten el adecuado intercambio de información entre las BDPO's de los operadores y proveedores de servicios de telecomunicaciones móviles con el Sistema Central de Portabilidad, considerando conectividad física y mediante internet hacia cada uno de los operadores.
2.1.1.3 INFRAESTRUCTURA DE CONEXIÓN ENTRE EL SCP Y LOS OPERADORES Y PROVEEDORES
El conjunto de Hardware y Software utilizados para la conexión entre los diferentes bloques funcionales que conforman la solución técnica del SCP y la integración con las BDPO's de los operadores y proveedores móviles con el ancho xx xxxxx suficiente y con redundancia por medios de transmisión separados bajo los siguientes modos de conectividad:
• Líneas dedicadas.
• Conexión segura por Internet (VPN, MPLS u otras)
Todos los equipos de red de datos necesarios del lado del SCP para la implementación de la interconexión con los operadores y proveedores de acuerdo a los medios físicos soportados harán parte integral de la solución del SCP y deberán ser provistos por el Adjudicatario considerando las mismas condiciones de operación, mantenimiento, disponibilidad, gestión, desempeño y garantías especificados en el presente documento.
2.1.1.4 AMBIENTES
El Oferente deberá proporcionar al menos los siguientes ambientes instalados en el estado plurinacional de Bolivia para una correcta gestión del SCP:
• Ambiente de Preproducción
• Ambiente de Producción
2.1.1.5 CAPACIDADES Y DESEMPEÑO
La solución técnica deberá considerar que la infraestructura de software y hardware empleada cuente con la suficiente capacidad para satisfacer las necesidades de los operadores y proveedores, sin disminuir el desempeño del sistema ni degradar la calidad de los servicios prestados. Para ello, como mínimo, deberá tener en cuenta los siguientes criterios de diseño:
Hasta Un millón de portaciones (Durante la vigencia del Contrato)
Hasta 100 transacciones por segundo
2.1.1.6 DISPONIBILIDAD Y RENDIMIENTO
La disponibilidad y rendimiento del Sistema de Intercambio de Información, interfaces y demás aplicaciones objeto del presente Pliego de Condiciones debe cumplir con los indicadores de servicio (SLA) mencionados en el Anexo D (Acuerdo de nivel de servicio).
2.1.1.7 CONFIABILIDAD Y SEGURIDAD
Es obligación del oferente asegurar que en el diseño y dimensionamiento de su propuesta, la información recibida, procesada y generada como producto de procesos sea veraz y que además, las funcionalidades propias de la solución técnica sean confiables. Para ello, el oferente tendrá en cuenta, como mínimo, las siguientes condiciones:
• Una transmisión y entrega confiable de mensajes, independientemente del tipo de interfaz a través de la cual se cursen.
• Mecanismos que aseguren la correcta recepción, orden, registro y procesamiento de los mensajes a fin de que se asegure su integridad y se eviten pérdidas.
• Un correcto y continuo procesamiento de las operaciones relacionadas con la portación de números en condiciones normales (de acuerdo a lo establecido en el SLA).
• Un correcto y continuo procesamiento de las operaciones relacionadas con la portación de números ante escenarios de interrupción de servicio programados y no programados.
• Procedimientos de notificación de emergencias y afectación de servicio por trabajos programados a los interesados.
• Procedimientos de notificación de restablecimiento del servicio y de reconexión al sistema de información principal.
• Procedimientos para asegurar una confiable recuperación total ante desastres.
• Procedimientos para asegurar la total restauración de la funcionalidad del Sistema Central de Portabilidad con posterioridad a un desastre.
• Procedimientos de auditoría para asegurar la integridad y confiabilidad de la información.
• Procedimiento de notificación de problemas o fallas del SCP y su escalonamiento correspondiente.
2.1.1.8 ESCALABILIDAD
El sistema propuesto deberá dimensionarse, asegurando su escalabilidad, a fin de que, en caso de incrementarse la demanda de servicios, la capacidad sea incrementada eficientemente y de forma flexible de tal manera que se garantice el cumplimiento de los parámetros de disponibilidad, desempeño, confiabilidad y calidad del servicio.
2.1.1.9 ADAPTABILIDAD
El oferente deberá ofrecer una solución técnica que sea adaptable al Plan de numeración vigente u otros procesos requeridos por los operadores del servicio móvil.
2.1.1.10 FLEXIBILIDAD
La solución propuesta por el oferente deberá ser flexible a fin de permitir la realización de las modificaciones o inclusión de situaciones no previstas que resulten de la experiencia de la implementación y operación de la Portabilidad, con sus respectivos controles de cambios, controles de configuración, casos de uso detallados, definición de procedimientos y licenciamientos.
El Oferente podrá presentar otras arquitecturas alternativas siempre y cuando cumplan con los requerimientos técnicos establecidos en el presente documento.
2.2 SISTEMA CENTRAL DE PORTABILIDAD
2.2.1 ARQUITECTURA DEL SCP
El Oferente deberá ofrecer una solución técnica con una arquitectura abierta y robusta de hardware y software que cumpla, como mínimo, con las siguientes características, las cuales serán extensivas a los sistemas operativos utilizados:
- Altamente disponible
- Escalable
- Confiable
- Segura
- Capaz de soportar procesos concurrentes con un desempeño óptimo
2.2.2 CARACTERÍSTICAS
El oferente ofrecerá una solución técnica que cuente, como mínimo, con las siguientes características:
• Arquitectura de software con estándares abiertos.
• Hardware basado en estándares de calidad.
• Sistema transaccional.
• Alta disponibilidad y desempeño.
• Confiabilidad
• Escalabilidad.
• Adaptabilidad.
• Flexibilidad.
• Altamente gestionable.
• Altamente seguro.
• Actualizable en el tiempo, sin afectar la disponibilidad, confiabilidad del sistema, ni los costos.
2.2.3 FUNCIONALIDADES
La solución técnica ofertada del Sistema Central de Portabilidad, deberá contar como mínimo con las siguientes funcionalidades a partir de un conjunto de reglas de negocio y procedimientos definidos en el Anexo B “Procesos de Portabilidad Numérica” adjunto al presente documento:
• Gestión de:
i. Proceso General de Portabilidad,
ii. Cambio titular,
iii. Devolución de números,
iv. Problemas o incidencias con el SCP,
v. Reversiones,
vi. Proceso xx xxxxx por deuda,
vii. Proceso de reconexión por deuda,
• Seguimiento integral de los procesos de portabilidad.
• Gestión de transacciones entre el SCP y los operadores y proveedores.
• Gestión de Reglas de negocio (funcionales y no funcionales).
• Gestión de notificación, actualización y distribución de información de portación.
• Generación de reportes
• Gestión de Tickets.
• Sistema de monitoreo, gestión, notificación y alarmas
• Sistema de gestión de resolución xx xxxxxx
• Sistema de backup
• Funciones de auditoría.
2.2.4 GESTOR DE PORTABILIDAD
Aplicaciones y sistemas informáticos que se encargan de la automatización y gestión de los procesos y reglas de negocio relacionados con la portación de números y la administración y operación centralizada de los mismos, bajo un esquema de intercambio de información transaccional síncrono y asíncrono entre los Operadores y proveedores del Servicio Móvil y el SCP.
2.2.5 BASE DE DATOS CENTRAL DE PORTABILIDAD NUMÉRICA - BDCP
Repositorio que contiene todos los datos resultado de los procesos y reglas de negocio referidos a la Portabilidad Numérica. Así mismo, al menos debe poseer bases de datos para números portados, procesos administrativos, datos históricos, trazabilidad de transacciones (registros de eventos, auditoría, etc.), una base de datos de parametrizaciones.
La solución técnica que ofrezca el oferente debe contar con una solución robusta de base de datos.
2.2.5.1 CARACTERÍSTICAS
• Alta capacidad y desempeño.
• Alta disponibilidad.
• Confiabilidad.
• Escalabilidad.
• Adaptabilidad.
• Flexibilidad.
• Mecanismos robustos de acceso.
• Múltiples operaciones simultáneas sobre la base de datos.
• Altamente gestionable.
• Altamente segura.
• Actualizable en el tiempo, sin afectar la disponibilidad, confiabilidad del sistema, ni los costos.
• Con interfaces abiertas y estandarizadas.
2.2.5.2 INFORMACIÓN CONTENIDA EN LA BASE DE DATOS
• Información de enrutamiento a números portados
• Información del proceso de portación
• Información del proceso de reversión
• Información del proceso de retorno.
• Información de las reglas de negocio (configuraciones) relacionadas con los procesos transaccionales del Sistema Central de portabilidad.
• Información Histórica de portaciones e incidencias o fallas.
• Información derivada de los procesos de portación (procesos rechazados, pendientes de validación, tickets generados, etc.).
• Información de supervisión y monitoreo del sistema.
• Información de incidencias o fallas ocurridas en el ecosistema de portabilidad.
• Información de registros de todos los eventos.
• Información adicional que provee la plataforma.
2.3 CONSIDERACIONES DE LOS PROCESOS DE PORTACIÓN Y GESTIÓN OPERATIVA DEL SCP
Se identifica un proceso de portación que incluye etapas y flujos descritos en el Anexo B Procesos de Portabilidad Numérica.
VENTANA DE CAMBIOS:
Define la fecha y hora de comienzo de la Ventana de Cambios en la cual se dará de baja el Número Portado en el Operador Donante y se activará el mismo en el Operador Receptor. Durante este período el usuario no tendrá servicio (Black out).
NÚMEROS PORTABLES:
Una solicitud de portación puede contener una entrada para portar un número, o contener múltiples números, hasta un número parametrizable por entrada a ser definido en la etapa de pruebas.
En la implementación del proceso se le permitirá al operador donante rechazar algún o todos los números de la entrada en una solicitud de portación, de acuerdo al Reglamento Técnico de Portabilidad.
En el caso que se produzca un evento que implique el rechazo parcial o total de la solicitud de portación, implicará el rechazo total de dicha solicitud y las líneas que la compongan.
El operador donante deberá analizar la solicitud de portación de todos los números incluidos en la misma, e informar al ASCP las causas del rechazo enmarcadas en el Reglamento de Portabilidad, de tal forma que el ASCP pueda informar al operador receptor el rechazo y sus causas, o caso contrario proseguir con el proceso de portación.
CONSULTAS DE ESTADO DE PORTACION
Mecanismos que permitan realizar consultas hacia el SCP de un proceso de portación llevada a cabo por un operador. El resultado de esta consulta deberá indicar la etapa en la que se encuentra el proceso.
2.4 DESCRIPCIÓN Y DEFINICIÓN DE TEMPORIZADORES
Para efectos de llevar el control de los tiempos en que se ejecutan los procesos y subprocesos de portación, así como para temporizar el envío y recepción de mensajes, el oferente, teniendo en cuenta los siguientes lineamientos, deberá implementar y configurar, como mínimo, los temporizadores establecidos en el SLA y tener en cuenta las siguientes consideraciones:
• Los temporizadores deben ser configurables por proceso y sus valores configurados a requerimiento del ETCP y aplicados por el proveedor del SCP.
• Si el mensaje no llega antes del tiempo de expiración, la acción por defecto que se deberá llevar a cabo, será la de registrar la correspondiente violación del temporizador y la de notificar a los involucrados.
• El SCP deberá soportar la definición de acciones que deban ser llevadas a cabo como respuesta a la detección de la violación de un temporizador.
2.5 SEGURIDAD Y AUDITORÍA
El Oferente propondrá políticas de seguridad e integridad con el objetivo de garantizar que sólo las empresas operadoras y proveedores de servicios de telecomunicaciones autorizadas, puedan acceder al sistema y realizar solamente las funciones que a cada uno de éstos les corresponda.
Las funciones de seguridad deben prevenir modificaciones accidentales o maliciosas en el flujo de datos, tanto del lado de las empresas operadoras de servicios de telecomunicaciones como de la Administración de la Base de Datos Centralizada Principal.
Cuando se requiera, el ETCP podrá realizar una auditoría de seguridad informática al ASCP para garantizar el cumplimiento de buenas prácticas y gestión de la seguridad de la información basadas en normas internacionales.
El ASCP debe aceptar las políticas de seguridad de la información de cada operador. A su vez, debe garantizar la confiabilidad, disponibilidad e integridad de toda la información gestionada por el SCP.
2.6 GESTIÓN DE REPORTES
Como parte de su propuesta de solución técnica, el oferente deberá proveer, como mínimo, las siguientes funcionalidades:
• Datos necesarios que los Operadores y proveedores del Servicio Móvil requieran para la elaboración de reportes personalizables, mínimamente los datos para elaborar los reportes citados en el Artículo 16 inciso III, del Reglamento Técnico de Portabilidad.
• El oferente debe brindar una herramienta de extracción de información para los reportes solicitados.
• Descripción de los datos disponibles para su adecuada interpretación y análisis
• Lista de reportes “out-of-the-box” implementada en la plataforma.
• Exportar los reportes a cualquier formato estándar (PDF, XLS, XLSX, CSV, TXT, entre otros)
2.7 SERVICIOS DEL ASCP
2.7.1 ADMINISTRACIÓN, MONITOREO, MANTENIMIENTO Y GESTIÓN DEL SCP
El oferente debe ofrecer una infraestructura de software y hardware que de forma continua lleve a cabo las funciones de administración y supervisión del SCP. En ese proceso, la infraestructura solicitada contará con las herramientas que le permitan la configuración, recolección, procesamiento y reporte de indicadores de gestión, así como las facilidades para la creación de nuevos indicadores.
El oferente deberá describir en su propuesta, los procedimientos y actividades a seguir en caso de que la solución técnica ofrecida o alguno de sus componentes que la integran, requieran de una actualización, optimización o mantenimiento.
El oferente tendrá en cuenta que las actualizaciones y mantenimiento del SCP programados, se deberán llevar a cabo en los días hábiles y no hábiles dentro del rango horario de 01:00 am a 06:00 am. Es obligación del ASCP solicitar el permiso correspondiente al ETCP con al menos diez (10) días hábiles de anterioridad, para la realización de las actualizaciones y mantenimientos.
Para la ejecución de tareas no programadas que realice el ASCP, deberá contar con la autorización del ETCP con la justificación correspondiente. Posterior a la ejecución del trabajo realizado el ASCP deberá enviar un informe de los cambios realizados.
2.7.2 SOLUCIÓN DE PROBLEMAS DE USUARIOS
2.7.2.1 HERRAMIENTA PARA EL SEGUIMIENTO A PROBLEMAS DE USUARIOS
El oferente deberá suministrar las herramientas e interfaces adecuadas, para que los organismos de control autorizados puedan hacer seguimiento, con el detalle suficiente, a las solicitudes de portación que tuvieron problemas para portar un número (excedieron el tiempo máximo, etc.), ya sea a través de mecanismos en línea y/o por medio de la generación de reportes mensuales o parciales, con las facilidades de configuración para ello.
2.7.2.2 MONITOREO DE INCIDENCIAS
El oferente ofrecerá como parte de su propuesta, una funcionalidad eficiente para la solución de incidencias que se puedan presentar durante la operación de todos los procesos involucrados en la Portabilidad.
2.7.2.3 GESTIÓN, TRATAMIENTO Y SEGUIMIENTO XX XXXXXX
El oferente ofrecerá como parte de la solución técnica los mecanismos de alarmas para monitorear los nodos interconectados, interfaces, procesos, etc.
Deberá tener la flexibilidad de configurar nuevas alarmas que puedan ser enviadas por
SMS/correo electrónico a los interesados definidos por los operadores y proveedores, además de generar logs de todas las acciones realizadas aplicando un formato específico.
El sistema debe permitir generar reportes de las fallas ocurridas en un periodo de tiempo.
El oferente deberá auto gestionar las fallas internas de la infraestructura de su solución (servidores, discos, memorias, etc.)
2.7.3 BACKUP Y RECUPERACIÓN DE INFORMACIÓN
Se distingue en este punto dos aspectos:
• Un mecanismo, donde el sistema implementado por el ASCP deberá contar al menos con los siguientes mecanismos de respaldo (backup):
o Automático: pudiendo configurar la ocurrencia del backup (diario/semanal/mensual), además del tipo de backup (incremental/full).
o Manual: esta puede ser realizada por el personal del ASCP que cuenta con el permiso correspondiente. Todas las actividades deberán ser registradas en los “logs” de auditoría.
Los objetos a ser respaldados, deben incluir toda la información registrada en base de datos y registro de logs del sistema.
La ASCP deberá contar con un mecanismo que asegure la recuperación total del servicio a partir de las copias de respaldo hechas. Está recuperación podrá ser exigida sobre una base semestral o anual, como una tarea preventiva de mantenimiento.
• Mecanismos que garanticen la continuidad del servicio y disponibilidad de acceso a la base de datos central de portabilidad
El oferente debe ofrecer la funcionalidad de hardware y software necesaria para la generación de copias de respaldo de información generada (backup) por el ASCP como parte de los procesos relacionados con la portabilidad numérica. El oferente debe ofrecer un plan complementario, estableciendo las estrategias adecuadas a seguir, haciendo énfasis particular en el archivo de información histórica y formas de acceso a la misma, considerando los siguientes aspectos:
Condiciones regulatorias y legales.
Definición de tiempos de archivo.
Medios de archivo.
Clasificación de información para acceso en línea versus acceso fuera de línea.
Facilidades para el acceso a información no disponible en línea.
Almacenamiento y acceso a información.
Definición de tiempos de recuperación conforme a su criticidad.
Sistema en caso de desastre, en el menor tiempo razonable.
2.7.4 IMPLEMENTACIÓN DEL SISTEMA
2.7.4.1 IMPLEMENTACIÓN Y PUESTA EN OPERACIÓN
El oferente deberá asegurar que el equipo de trabajo involucrado en la implementación de la solución técnica, objeto del presente documento, contará con la apropiada experiencia técnica, operativa y administrativa, así como con el entrenamiento necesario para su desarrollo, implementación, prueba y operación.
El oferente incluirá como parte de su oferta la organización, los perfiles y los roles de los miembros del equipo de trabajo que harán parte del proyecto durante su implementación y puesta en operación.
Con el fin de gestionar la ejecución del proyecto objeto del Contrato, el oferente que resulte elegido designará a un Gerente de Proyecto (PMO), quien será el único punto de contacto con el Equipo Técnico Consultivo de Portabilidad Numérica - ETCP y con los Operadores del servicio móvil que suscriban el respectivo contrato con el ASCP. El Gerente de Proyecto tendrá la misión de coordinar el desarrollo de todas las actividades relacionadas con la implementación de la solución y de la remisión de los correspondientes entregables que se deriven de las obligaciones contractuales adquiridas.
El oferente debe realizar los ajustes requeridos a los flujos de portabilidad que se definan durante la fase de diseño.
El oferente proporcionará un plan de implementación que considere como mínimo las siguientes actividades:
a) Entrega de un Cronograma detallado de actividades.
b) Entrega de especificaciones de la solución a implementar.
c) Procesos de instalación y configuración de hardware,.
d) Procesos de instalación y configuración de software.
e) Etapa de integración.
f) Finalización de pruebas de integración y ajustes.
g) Puesta en operación del servicio de Help Desk.
h) Entrenamiento a operadores y ATT incluyendo capacitación en procedimientos de interacción con el Help Desk.
i) Entrenamiento técnico sobre las conexiones con el SCP, el acceso y uso de la información de enrutamiento hacia números portados.
j) Finalización de pruebas extremo a extremo con el resto de los operadores y proveedores, y validación con el SCP.
k) Puesta en producción del servicio.
2.7.5 REQUERIMIENTOS DE CAMBIOS
El oferente deberá considerar las buenas prácticas relacionadas a la gestión de cambios. Una vez implementado el SCP, todo requerimiento de cambio debe seguir el siguiente flujo:
1. El ETCP en base a lo requerido por la Comisión Técnica Operativa debe entregar un documento de requerimientos “Stakeholder” al ASCP con el detalle del requerimiento de cambio solicitado. El documento debe ser descriptivo y debe contener el detalle necesario para describir las funcionalidades de cambio requeridas.
2. El ASCP deberá redactar un documento de la solución en base al documento “Stakeholder” y el mismo debe ser acordado con los gestores de cambios definidos en el punto 1.
3. El ASCP tendrá un tiempo no mayor a 10 días calendario para entregar la propuesta de solución al requerimiento descrito en el punto 1, describiendo tiempos y costos propuestos.
4. El ASCP y ETCP, deben firmar el documento de cambio que contendrá el detalle de la propuesta a ser elaborado por el ASCP, alcance, impactos, costos y tiempos.
5. El ASCP debe realizar entregas parciales o demostraciones en entornos de preproducción a los operadores y proveedores.
La puesta a producción debe ser acordada y coordinada con los operadores y proveedores, considerando como requisitos mínimos de puesta a producción, la entrega de documentación técnica y de usuario, así como las pruebas realizadas en entornos de preproducción.
Cualquier incidente relacionado al cambio debe entrar dentro del periodo de garantía de la solución y no debe implicar un costo adicional para los contratantes.
Después de 10 días calendario post puesta a producción y en caso de no existir observaciones pendientes, los contratantes deben proceder con la firma de aceptación del cambio siguiendo los procedimientos establecidos.
2.7.6 CAPACITACIÓN
El oferente debe establecer, dentro de su propuesta, el servicio de capacitación con una gama de cursos en sitio, dirigidos al personal técnico y operativo de los operadores del servicio móvil, y la ATT con el fin de capacitar en la administración, configuración y solución de problemas relacionados al SCP.. Esta capacitación deberá llevarse a cabo previamente a la puesta en operación de la solución.
Todos los cursos deben ser impartidos por instructores certificados por el oferente. Los mismos que deben ser expertos en la materia y posean sustancial experiencia de la solución de la plataforma propuesta y en la enseñanza.
Todos los cursos orientados a las áreas comerciales deberán ser impartidos en lenguaje local (castellano). Sin embargo, los cursos orientados a las áreas técnicas podrán ser impartidos en inglés previa aceptación del ETCP.
La capacitación deberá ser impartida mínimamente para 22 personas del área técnica y 18 personas del área comercial de los operadores del servicio móvil y la ATT.
Se requiere una capacitación para las áreas regulatorias y el ente regulador (ATT), con la participación mínimamente de 10 personas.
Las ciudades y las fechas para los cursos de la capacitación serán definidas por las partes. El oferente proveerá medios de evaluación para los participantes.
El oferente proveerá un Acta de Aceptación de la Capacitación una vez concluidos todos los cursos de la capacitación, que será firmada por los representantes de los capacitados.
2.7.7 HELP DESK (SOPORTE)
El ASCP deberá contar con el personal y la infraestructura necesarios para operar un servicio de Help Desk mediante el cual proporcionará, entre otros, las siguientes funcionalidades:
• Help Desk para los operadores y proveedores para solución xx xxxxxx y solución de preguntas técnicas. La atención debe ser accesible vía telefónica, email e interfaz Web GUI, y gestionada mediante una aplicación de creación de tickets de incidencias.
El Help Desk para operadores y proveedores deberá operar en un esquema de 24x7, 365 días al año, y contará con un registro de todas las llamadas recibidas vía telefónica, email e interfaz Web GUI que se reciban. Para cada solicitud de ayuda, se abrirá un ticket con su correspondiente número. El cierre de toda solicitud /petición deberá ser acordado en forma conjunta entre el ASCP y el personal que realizó el registro de la misma.
La atención debe ser en castellano y accesible vía telefónica, email e interfaz Web GUI, y gestionada mediante una aplicación de creación de tickets de incidencias
2.7.8 PRUEBAS
El oferente deberá presentar en su oferta el plan de pruebas para cada uno de los componentes de la solución técnica propuesta, al menos verificando aspectos de instalación, funcionalidad, seguridad e integración, éste podrá ser ajustado en la fase de diseño en común acuerdo con los operadores y proveedores. El plan debe especificar metodología, escenarios y calendario de ejecución de acuerdo a contrato.
Las pruebas de integración entre operadores y proveedores y el SCP se realizarán una vez que las pruebas individuales de integración hayan concluido exitosamente.
El ASCP deberá participar en las pruebas funcionales que defina el ETCP.
2.7.9 ACEPTACIÓN DEL SISTEMA
Como resultado de las pruebas a que se refiere el numeral anterior, y una vez que se cumpla con todas las condiciones y requisitos establecidos en el Contrato, el ASCP deberá realizar la entrega formal, del sistema estipulado en el Contrato a cada operador y al Equipo Técnico Consultivo de Portabilidad Numérica, a más tardar en la fecha establecida en el cronograma de implementación de la Portabilidad Numérica. Para tal efecto, cada operador deberá firmar y entregar la carta de aceptación correspondiente.
2.7.10 DIRECCIÓN DE PROYECTOS (PMO)
El oferente deberá conformar una Oficina de Gestión de Proyectos PMO y hacerse cargo de la Dirección del Proyecto de implementación de la solución durante toda la implementación del proyecto.
El oferente deberá presentar la metodología, cronograma, gestión de riesgos y gestión del plan de comunicaciones, etc. de la implementación del proyecto.
La PMO conformada deberá coordinar con las personas designadas por el ETCP.
2.8 ACUERDO DE NIVEL DE SERVICIO - SLA
El SLA tiene como objetivo definir los niveles de servicio que el oferente debe cumplir. Asimismo, los tiempos de respuestas según la criticidad, niveles de escalamientos y las multas que se aplicaran en caso de incumplimiento, el SLA se encuentra descrito en el Anexo D.
2.9 EXPERIENCIA DEL OFERENTE
El Oferente debe presentar documentación que respalde su experiencia en la implementación y administración de un Sistema Central de Portabilidad para el servicio móvil o un Sistema de Provisionamiento de alta transaccionabilidad para el servicio móvil.
Deberá presentar mínimamente una (1) referencia documentada donde su solución ha sido implementada y haya operado al menos un año durante los últimos 2 años. Especificar por referencia:
- País
- Empresas Operadoras o Proveedoras del Servicio Móvil
- Fecha de implementación
- Capacidad transacciones de portaciones por día
2.10 TIEMPOS DE ENTREGA
La entrega de todos los requerimientos y los servicios de instalación, implementación y pruebas funcionales deben realizarse en un tiempo máximo de 160 días calendario a partir de la adjudicación, incluyendo mínimamente un (1) mes para pruebas integrales.
El oferente debe presentar un cronograma de instalación e implementación que considere lo siguiente:
- La definición de las actividades del proyecto que consiste en identificar las acciones específicas a ser realizadas para la implementación del proyecto.
- Diagrama Xxxxx del proyecto donde se muestre la secuencia de las actividades del proyecto y sus relaciones.
- Los hitos que mínimamente debe incluir el diagrama Xxxxx son:
Adjudicación.
Fabricación/Desarrollo
Entrega de Equipos en Sitio
Instalación de Hardware
Implementación.
Integración.
Pruebas end to end (deben ser llevadas a cabo en un máximo de30 días calendario).
Puesta en producción.
2.11 ENTREGABLES
Los siguientes entregables deben ser presentados en su versión inicial para la evaluación de su oferta.
Ítem | Entregable | Descripción. | Formato Impreso | Formato Electrónico | Observaciones |
1 | Índice del documento | Índice del Documento. | X | ||
2 | Descripción del proyecto | ||||
2.1 | Descripción del proyecto | Descripción del proyecto, indicando el objetivo del mismo y los Participantes y/o responsables de cada área. | X | X | |
2.2 | Diagrama del sistema | Documento de arquitectura especifica física y lógica, que muestre los elementos que estarán involucrados en la solución, incluyendo módulos, interfaces, protocolos, administración. | X | X | |
2.3 | BCP (Business Continuity Plan) | Plan de contingencia que garantice la continuidad operativa de la portabilidad. | X | ||
2.4 | DRP (Disaster Recovery Plan) | Plan de contingencia que garantice la recuperación del sistema en caso de desastre, en el menor tiempo. | X | ||
2.5 | Dimensionamiento de la solución | Descripción de capacidades provistas y escalables de su solución (hardware y licenciamiento). | X |
3 | Integración SCP | En este punto se debe detallar todo el procedimiento realizado para poner en funcionamiento la solución, es decir detallar todas las configuraciones realizadas. | |||
3.1 | Integración SCP | Especificar el procedimiento para integrar el SCP con los operadores y proveedores. | X | X | |
4 | Parámetros de Calidad | ||||
4.1 | KPI's del SCP | Detalle de KPIs disponibles y su descripción | X | X | |
5 | Estructura de procesos | ||||
5.1 | Modelo de datos | Descripción del modelo de datos. | X | ||
5.2 | Diccionario de datos | Descripción especifica de todos los campos de las tablas. | X | ||
5.3 | Especificaciones de los flujos operativos | Detallar en el manual operativo todos los métodos expuestos de los web services. (Funcionalidades mandatorias y opcionales), indicando los valores y formatos. | X | ||
5.4 | Especificaciones de los flujos de usuarios | Detallar en el manual de usuario de todos los métodos expuestos de los web services. (Funcionalidades mandatorias y opcionales). | X | ||
5.5 | Tabla de códigos de respuesta. | Explicación de códigos de error y resolución sugerida. | X | ||
5.6 | Descripción archivos generados | Explicación de los archivos generados para los distintos flujos. | X |
6 | Capacitación | ||||
6.1 | Descripción de la capacitación técnica y comercial (Temario). | Se solicitan mínimamente los siguientes temas para el área técnica (nivel avanzado): - Administración de la Solución - Arquitectura de la solución. - Integración. - Interfaces. - Seguridad. - Herramientas GUI Se solicitan mínimamente los siguientes temas para el área comercial (nivel avanzado): - Help Desk - Gestión xx xxxxxx(Tickets) - Herramientas GUI | X | X | |
6.2 | Contenido y duración por tema. | Entrega de un plan de capacitación | X | X | |
6.3 | Material de capacitación. | El oferente proveerá todos los manuales de capacitación. | X | X | |
7 | Anexos.- | ||||
7.1 | Protocolos de aceptación de la solución (ATP) | Detallar las pruebas de aceptación sugeridas sujetas a consenso entre partes. | X | ||
7.2 | SW de Apoyo | Herramientas y aplicaciones de apoyo para la gestión. | X | ||
7.3 | Cronograma de implementación | (a ser elaborado por el oferente) | X | X |
PARTE III
TABLAS DE CUMPLIMIENTO DE REQUERIMIENTOS
El Oferente debe completar el "Estado de Cumplimiento" para cada párrafo del presente Pliego de Condiciones y sus anexos.
Las respuestas validas son:
- Cumple. Para esta respuesta ninguna aclaración adicional debe ser incluida, se considera que el Oferente se encuentra totalmente de acuerdo con el párrafo como se encuentra escrito. Si existe alguna aclaración adicional para esta respuesta la Comisión de Calificación considerará la respuesta como No Cumple
- No Cumple. Para esta respuesta ninguna aclaración adicional debe ser incluida; en una respuesta de No Cumple se considerará que el Oferente no cumple o no está de acuerdo con el requerimiento descrito en el párrafo respectivo (Esta respuesta será tomada como final)
La columna de respuestas debe ser llenada obligatoriamente con las referencias precisas y exactas (documento, página, referencia) y sin añadir comentario y/o condiciones adicionales.
En caso de no existir respuesta se considerará No Cumple.
El Oferente deberá presentar la documentación que respalde su respuesta tomando en cuenta todo lo requerido en el pliego de condiciones y sus Anexos.
Cualquier costo en que incurra un Oferente por su participación en este proceso debe ser asumido por el propio Oferente sin costo adicional para ninguno de los Operadores y proveedores involucrados en este proceso.
El Oferente deberá aceptar todos los puntos detallados en los siguientes anexos:
I. Anexo A: Reglamento Técnico.
II. Anexo B: Procesos de Portabilidad Numérica.
III. Anexo C: Arquitectura General de la Solución
IV. Anexo D: SLA (Service Level Agreement/Acuerdo de Nivel de Servicio).
V. Anexo F: Procedimiento para migración a un nuevo ASCP
VI. Anexo K: Características Técnicas del Hosting
3.1 REQUERIMIENTOS GENERALES
3.1.1 LINEAMIENTOS DEL ESQUEMA DE PORTABILIDAD
Esta sección contiene y describe los lineamientos de las funcionalidades y requerimientos que la plataforma debe tener para brindar el soporte adecuado al proceso de portabilidad numérica de cumplimiento obligatorio según su propuesta y de conformidad a los decretos, reglamentos regulatorios y aspectos operativos.
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
1.1 | El Oferente debe presentar su oferta técnica para la implementación, administración, operación, soporte, mantenimiento y seguridad de un Sistema Central de Portabilidad Numérica del Servicio Móvil con fines de permitir los procesos de Portabilidad numérica entre los operadores y proveedores del Servicio móvil del Estado Plurinacional de Bolivia. | Mandatorio | ||
1.2 | El oferente deberá describir los mecanismos, forma y procedimientos para la transferencia de información de enrutamiento, que deberá ser puesto a disposición de los operadores y proveedores de Servicios de Telecomunicaciones que utilicen el recurso de numeración. | Mandatorio | ||
1.3 | El Oferente deberá describir de forma amplia y detallada la propuesta técnica que permita la implementación de la Solución Técnica establecida para la portabilidad. En caso de existir información que pudiera ser relevante tales como, de manera enunciativa más no limitativa: versiones, funciones, servicios, sistemas operativos, protocolos, equipos, sistemas de seguridad, medios de comunicación, deberá ser incluida y referenciada con claridad. | Mandatorio |
1.4 | El oferente debe presentar la descripción de los elementos de su solución a nivel técnico. Incluir: • Descripción/diagramas mostrando los componentes de la solución y su integración. Si la solución incluye participación de terceros Especificar los proveedores y sus responsabilidades (cuando corresponda). Descripción y explicación de su arquitectura propuesta, incluyendo: Arquitectura de Hardware. Arquitectura lógica modular interna. Arquitectura de interconexiones. • Arquitectura de administración | Mandatorio |
1.5 | Describir las características de la arquitectura de la solución para cumplir con los niveles de desempeño, y alta disponibilidad, especificados en el SLA del Anexo “D”. | Mandatorio | ||
1.6 | El Oferente debe describir los mecanismos para garantizar la interconexión segura entre el SCP y los operadores y proveedores. | Mandatorio | ||
1.7 | El oferente deberá proporcionar la lista de funcionalidades básicas para garantizar la ejecución de flujos propios de la portabilidad numérica Anexo B. En caso de requerirse software y/o hardware adicional para el funcionamiento de las mismas, estos deberán ser provistos por el oferente sin que represente costo adicional. | Mandatorio |
1.8 | El oferente debe proveer un monitor de transacciones en línea que permita visualizar el desempeño de todas las transacciones definidas en los flujos comerciales de Portabilidad Numérica descritos en el Anexo B. | Mandatorio | ||
1.9 | El oferente debe describir el sistema de generación y gestión de Tickets para el registro de reclamos e incidencias que permita la interacción con los operadores y proveedores. | Mandatorio | ||
El oferente debe describir los mecanismos para generar, almacenar, gestionar y garantizar la integridad de toda la información producto de los procesos de portabilidad y su administración. Debiendo mantener dicha información, por al menos 3 años en línea. | Mandatorio |
3.1.2 ARQUITECTURA DE LA SOLUCIÓN
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
2.1 | La arquitectura deberá describir la solución integral que garantice el cumplimiento del SLA descrito en el Anexo D. | Mandatorio |
2.2 | La arquitectura debe incluir como mínimo los siguientes bloques funcionales o sus equivalentes que componen el Sistema Central de Portabilidad SCP: • Gestor de portabilidad • Base de Datos Central de Portabilidad Numérica BDCP. • Help Desk (Sistema de Ticket´s) • • Interfaces de software • Infraestructura segura de conexión entre el SCP y los operadores y proveedores. • Ambientes de pre-producción y producción. • Aplicaciones para gestión de la solución | Mandatorio | ||
2.3 | El oferente deberá tener en cuenta mínimamente los siguientes criterios de diseño: • Disponibilidad • Confiabilidad • Escalabilidad • Adaptabilidad • Flexibilidad • Trazabilidad • Integridad El oferente deberá describir la forma en la que su solución cumple los criterios de diseño expuestos. | Mandatorio | ||
2.4 | El oferente deberá permitir establecer una conexión (principal y redundante) entre el SCP y cada uno de los operadores y proveedores. Dicha conexión debe ser a través de un canal de conexión segura a través de líneas dedicadas y conexión segura por internet. | Mandatorio |
2.5 | El oferente debe describir la forma de integración síncrona y asíncrona de transacciones, mismas que deben considerar los mecanismos de reintentos manuales y automáticos. | Mandatorio | ||
Alta Disponibilidad en Sitio | ||||
2.6 | El oferente debe describir la arquitectura de la solución, con las características de redundancia y tolerancia a fallos necesaria para asegurar la alta disponibilidad de acuerdo al SLA. | Mandatorio |
3.1.3ARQUITECTURA DE HARDWARE Y SOFTWARE
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
3.1 | El Oferente deberá describir su solución técnica con una arquitectura de estándares abierta y robusta que cumpla, como mínimo, con las siguientes características, las cuales serán extensivas a todos los sistemas utilizados: - Altamente disponible en sitio - Escalable - Confiable - Segura - Capaz de soportar procesos concurrentes con un desempeño óptimo. - Hardware y Software con arquitectura estandarizada | Mandatorio | ||
3.2 | El oferente deberá describir una arquitectura, la misma que deberá estar orientada a servicios, publicando mínimamente servicios WEB para integrarse con los operadores y proveedores. | Mandatorio |
3.3 | El oferente deberá describir una arquitectura que deberá considerar mínimamente la implementación de los siguientes protocolos de integración e intercambio de información: • SOAP (Simple Object Access Protocol)/XML (Extended Markup Language), • HTTPS (Hyper Text Transfer Protocol) • SFTP (Secure File Transfer Protocol). | Mandatorio | ||
3.4 | El oferente debe describir los mecanismos de registro de los mensajes intercambiados entre el SCP y los operadores o proveedores, quedando estos eventos registrados y almacenados de forma apropiada. | Mandatorio | ||
3.5 | El oferente debe describir los mecanismos de respuestas, confirmación y reintentos en caso xx xxxxxx. | Mandatorio | ||
3.6 | El oferente debe describir las capacidades y especificaciones del hardware como mínimo (CPU, Memoria, RAID y Storage) para cada uno los servidores de su arquitectura. | Mandatorio |
3.1.4 SISTEMA CENTRAL DE PORTABILIDAD - SCP
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
4.1 | Reportes | |||
4.1.1 | El oferente debe describir la herramienta de extracción de información para la generación de reportes solicitados que se encuentra en su propuesta. | Mandatorio | ||
4.1.2 | El oferente debe describir todos los reportes propios de la solución. | Mandatorio |
4.1.3 | El oferente debe describir los métodos de exportación de la información de sus reportes que mínimamente debe contemplar los siguientes formatos., Excel, CSV, TXT, entre otros. | Mandatorio | ||
4.1.4 | El oferente debe proveer el tipo de datos y su correspondiente descripción. Además deberá indicar los mecanismos por los cuales se actualizarán y extraerán los datos del sistema (BD y logs) indicando explícitamente que la frecuencia de actualización es parametrizable. | Mandatorio | ||
4.2 | Procesos del SCP | |||
4.2.1 | El oferente debe describir los métodos que se utilizarán para implementar los siguientes flujos o requerimientos: - Proceso General de Portabilidad - Proceso de devolución de números - Proceso xx xxxxx por deuda - Proceso de reconexión por deuda | Mandatorio |
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
Proceso de Reversión Proceso de Cambio de titular Problemas o incidencias con ASCP Seguimiento integral de los procesos de portabilidad. Gestión de transacciones entre el SCP y los operadores (trazabilidad). - Gestión de Reglas de negocio (funcional y no funcional). Gestión de notificación, actualización y distribución de información de portación. |
Funciones de auditoría Integración con el sistema de tickets Consulta del estado de la Portación. | ||||
4.3 | Base de Datos Central de Portabilidad Numérica BDCP | |||
4.3.1 | El oferente debe describir la Base de Datos Central de Portabilidad que cuente como mínimo, con las siguientes características: • Alta capacidad y desempeño • Alta disponibilidad • Confiabilidad. • Escalabilidad. • Adaptabilidad. • Flexibilidad. • Mecanismos robustos de acceso • Múltiples operaciones simultáneas sobre la base de datos • Altamente gestionable • Altamente segura. • Actualizable en el tiempo, sin afectar la disponibilidad, confiabilidad del sistema ni los costos. • Con interfaces abiertas y estándares. | Mandatorio | ||
4.3.2 | El proveedor debe describir el tipo de información gestionada por la solución que mínimamente debe contener: Información de enrutamiento a números portados. Información del proceso de portación Información del proceso de reversión Información del proceso de retorno Información de las reglas de negocio (configuraciones) | Mandatorio |
relacionadas con los procesos transaccionales del Sistema Central de portabilidad. Información Histórica de portaciones e incidencias o fallas Información derivada de los procesos de portación (procesos rechazados, pendientes de validación, tickets generados, etc.) Información de supervisión y monitoreo del sistema Información de incidencias o fallas ocurridas en el ecosistema de portabilidad. Información de registros de todos los eventos. Información adicional que provee la plataforma |
3.1.5 PROCESOS Y GESTIÓN OPERATIVA DEL SCP
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
5.1. | Administración, monitoreo, mantenimiento y rendimiento del sistema | |||
5.1.1 | El oferente deberá describir en su propuesta, los procedimientos y actividades a seguir en caso de que la solución técnica ofrecida o alguno de sus componentes que la integran, requieran de una actualización, optimización o mantenimiento. | Mandatorio |
5.2 | Monitoreo y seguimiento xx xxxxxx de servicio | |||
5.2.1 | El oferente deberá describir los mecanismos de monitoreo de alarmas que mínimamente cubran los servicios e interfaces provistos por la solución asi como la disponibilidad de su infraestructura de hardware. | Mandatorio | ||
5.2.2 | Debe describir los métodos de notificación de alarmas hacia los operadores y proveedores. | Mandatorio | ||
5.2.3 | El oferente deberá entregar una muestra de logs y reportes de todas las transacciones incidencias, fallas ocurridas en los flujos del sistema, incluida las fallas de su infraestructura de hardware. | Mandatorio |
3.1.6 SERVICIOS DEL ASCP 3.1.6.1ADMINISTRACIÓN DEL SCP
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
6.1 | Herramientas para usuarios | |||
6.1.1 | El oferente deberá describir las herramientas e interfaces a implementarse en la solución, para que los organismos de control autorizados puedan hacer seguimiento, con detalle suficiente, a las solicitudes de portación que tuvieron problemas para portar un número (Excedieron el tiempo máximo, etc.), ya sea a través de mecanismos en línea y/o por medio de la generación de reportes mensuales o parciales, con las facilidades de configuración para ello. | Mandatorio | ||
6.2 | Backup y recuperación de información. | |||
6.2.1 | El oferente debe describir los mecanismos y procedimientos para realizar el respaldo (backup) y restauración de las configuraciones, estructuras del sistema y datos de manera periódica y automatizada, minimizando los tiempos de afectación del servicio de acuerdo a lo determinado en el SLA. | Mandatorio | ||
6.2.2 | El oferente debe describir los mecanismos por los que generará logs ante la ejecución de backup/restore de la información. | Mandatorio |
6.2.3 | El oferente debe describir los métodos de backup que mínimamente debe contemplar: • Automático: pudiendo configurar la ocurrencia del backup (diario/semanal/mensual), además del tipo de backup (incremental/full). • Manual: Esta puede ser realizada por el personal del ASCP que cuenta con el permiso correspondiente. Todas las actividades deberán ser registradas en los “logs” de auditoría. | Mandatorio | ||
6.2.4 | El oferente debe describir los procedimientos necesarios para garantizar el almacenamiento de información histórica que excede los 3 años, la misma que podrá ser almacenada en dispositivos de almacenamiento externo y deberá ser entregado de forma encriptada a los operadores | Mandatorio | ||
6.2.5 | El oferente deberá describir los mecanismos que aseguren la recuperación total de los servicios a partir de las copias de respaldo. Está recuperación podrá ser exigida a requerimiento del ETCP. | Mandatorio | ||
6.2.6 | El Oferente deberá describir los siguientes procedimientos: BCP (Business continuity plan): plan de contingencia que garantice la continuidad operativa de la portabilidad en Sitio. | Mandatorio |
6.2.7 | El Oferente deberá describir los siguientes procedimientos: DRP (Disaster Recovery Plan): plan de contingencia que garantice la recuperación del sistema en caso de desastre, en el menor tiempo razonable. | Mandatorio | ||
6.3 | Servicio de asistencia adicionales. | |||
6.3.1 | El oferente deberá describir los procedimientos de soporte en la planificación, implementación, realización de pruebas y lanzamiento comercial y de nuevos requerimientos de los operadores y proveedores y/o ente regulador. | Mandatorio | ||
6.3.2 | El oferente deberá describir los procedimientos e impactos referidos a cambios en la solución (Migraciones, Ampliaciones, cambios masivos, actualizaciones de SW, etc.). | Mandatorio | ||
6.3.3 | El oferente deberá describir los procedimientos de soporte en segunda línea escalados por las áreas respectivas de los operadores y proveedores | Mandatorio | ||
6.3.4 | El oferente deberá describir los procedimientos de gestión de usuarios relacionados a roles y funciones asociados a los elementos de la Plataforma de Portabilidad y sus respectivos sistemas de Gestión, previa autorización de los operadores y proveedores. | Mandatorio |
3.1.7 IMPLEMENTACIÓN DEL SISTEMA
Esta sección describe los requerimientos relativos a las actividades relacionadas con la implementación del sistema.
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
7.1 | Dirección del proyecto. | |||
7.1.1 | El oferente deberá describir los procedimientos y funciones de la Oficina de Gestión de Proyectos PMO, la misma que se hará cargo de la Dirección del Proyecto durante la implementación de acuerdo al cronograma, en coordinación con las personas designadas por el ETCP | Mandatorio | ||
7.2 | Implementación | |||
7.2.1 | El oferente deberá describir en su propuesta los servicios de: Instalación, integración, pruebas y puesta en producción de su solución con el Gateway de cada operador del servicio móvil. | Mandatorio |
3.1.8 REQUERIMIENTOS DE CAMBIOS
Esta sección describe los procedimientos ante cambios en los requerimientos del proyecto solicitados por el ETCP al ASCP.
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio/Calificable) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
8.1 | El oferente debe describir los procedimientos de todos los cambios, tomando en cuenta que estos deben ser notificados con una anticipación de 10 días hábiles (la cantidad de días puede estar sujeta a modificaciones). Tomar en cuenta que el oferente debe cubrir sin costo alguno las solicitudes de cambio que surjan durante el proceso de implementación y optimización del SCP con los operadores, acorde al pliego de especificaciones. | Mandatorio | ||
8.2 | El oferente debe enviar los procedimientos relacionados a gestión de cambios que consideren mínimamente los pasos descritos en la sección “Implementación del sistema – Requerimientos de cambios. | Mandatorio | ||
8.3 | El oferente debe describir el procedimiento que se aplicará ante cualquier cambio que se realice en la plataforma, informando el impacto en el servicio u otros aspectos técnicos, mediante un documento de reporte de impactos asociados a cambios. | Mandatorio | ||
8.4 | El Oferente deberá describir los siguientes ambientes para una correcta gestión de cambios: • Ambiente de Preproducción • Ambiente de Producción | Mandatorio |
8.5 | Se evaluará la cantidad de horas/hombre de desarrollo para Requerimientos de Cambios no incluidos en el pliego de especificaciones, las cuales deben ser incluidas en su oferta sin costo adicional. | Calificable |
3.1.9 CAPACITACIÓN
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
9.1 | El Oferente debe proporcionar una descripción de la capacitación referida a la solución, que cumpla con los requerimientos solicitados en el acápite 2.7.6 (Parte II) "CAPACITACIÓN" de la parte descriptiva de los servicios. | Mandatorio |
3.1.10 HELP DESK
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
10.1 | Disponibilidad del servicio y de personal. | |||
10.1.1 | El oferente deberá proporcionar una lista con el perfil profesional que este calificado y capacitado para brindar el servicio xx Xxxx de Ayuda de todos los componentes HW y SW de la plataforma de Portabilidad. | Mandatorio | ||
10.1.2 | El oferente debe proporcionar los procedimientos relacionados a su | Mandatorio |
mesa de ayuda, donde describa una disponibilidad del grupo funcional en un horario 24x7 y con un centro de llamadas que mantendrá un registro de los servicios de Help Desk. Los mismos que podrán ser visualizados en los sistemas de gestión y Help Desk provistos por el ASCP. |
10.1.3 | El oferente debe proporcionar los procedimientos relacionados al módulo xx xxxx de ayuda (Help Desk), los mismos que deberán incluir la atención de incidentes vía telefónica, email e interfaz Web GUI. Adicionalmente debe considerar la atención de estos canales en castellano | Mandatorio | ||
10.2 | Responsabilidades. | |||
10.2.1 | El oferente deberá presentar los procedimientos de monitoreo, registro, escalamiento, seguimiento, cierre de incidentes y problemas asociados a la Plataforma de Portabilidad Numérica. | Mandatorio | ||
10.2.2 | El oferente deberá presentar los procedimientos relacionados al cierre de incidentes, en los que se incluyan la elaboración de informes técnicos y ejecutivos de los incidentes presentados en la Plataforma de Portabilidad. | Mandatorio | ||
10.2.3 | El oferente debe presentar los procedimientos de atención de su mesa de ayuda que registrará reclamos, consultas y solicitudes realizados por los operadores y proveedores. | Mandatorio |
10.2.4 | El oferente debe presentar los procedimientos relacionados a la notificación (mediante Help Desk) de tareas de mantenimiento preventivo/correctivo. | Mandatorio | ||
10.2.5 | El oferente debe presentar el procedimiento de cierre de tickets en los cuales se describa que todo cierre de ticket debe ser acordado en forma conjunta entre el ASCP y el operador solicitante | Mandatorio |
3.1.11 EXPERIENCIA DEL OFERENTE
Con el fin de garantizar la experiencia del oferente, en esta sección se listan los requerimientos para este fin.
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Mandatorio) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
11.1 | El Oferente debe presentar documentación que respalde su experiencia en la implementación y administración de un Sistema Central de Portabilidad para el servicio móvil o un Sistema de Provisionamiento de alta transaccionabilidad para el servicio móvil. Deberá presentar mínimamente una (1) referencia documentada donde su solución ha sido implementada y haya operado al menos un año durante los últimos 2 años. Especificar por referencia: - País - Empresas Operadoras o Proveedoras del Servicio Móvil - Fecha de implementación - Capacidad transacciones de portaciones por día | Mandatorio |
3.1.12 TIEMPOS DE ENTREGA
REQUERIMIENTO | RESPUESTA | |||
N° | DESCRIPCIÓN | TIPO DE REQUERIMIENTO (Calificable) | CUMPLE / NO CUMPLE | DOCUMENTO, PÁGINA, REFERENCIA |
12.1 | El oferente debe entregar un cronograma en el que describa las tareas y los tiempos de entrega, propias del oferente, de todos los requerimientos del presente documento, referidos a la instalación, implementación, integración y pruebas de aceptación, los mismos que deberán realizarse en un tiempo máximo de 160 días calendario a partir de la adjudicación del proyecto. | Calificable |
3.1.13CUADRO DE CALIFICACIÓN CRITERIOS CALIFICABLES.
CRITERIOS CALIFICABLES (B) | PONDERACION SOBRE 100% | ||
Nro. | Requerimiento | Criterio de calificación | Ponderación por Ítem % |
13.1 | El oferente debe entregar un cronograma en el que describa las tareas y los tiempos de entrega, propias del oferente, de todos los requerimientos del presente documento, referidos a la implementación, integración y pruebas de aceptación, los mismos que deberán realizarse en un tiempo máximo de 160 días calendario a partir de la adjudicación del proyecto. | Se calificará en función al menor tiempo de implementación incluido en su oferta. | 70 |
13.2 | Se evaluará la cantidad de horas/hombre de desarrollo para Requerimientos de Cambios no incluidos en el pliego de especificaciones, los cuales deben ser incluidos en su oferta sin costo adicional. | Se calificará en función a la mayor cantidad de horas hombre adicional incluido en su oferta. | 30 |
CALIFICACIÓN TOTAL | 100% | ||
TOTAL CRITERIOS CALIFICABLES PARTE TÉCNICA | 30% |
ANEXO A REGLAMENTO TÉCNICO
ANEXO B PROCESOS PORTABILIDAD
1. Proceso Portabilidad
PROCESO GENERAL DE PORTABILIDAD
DRAFT v1.0
CLIENTE
INICIO
Realiza solicitud de portación
FIN FIN
OPERADOR RECEPTOR
Llena formulario
de solicitud
Recibe solicitud del Cliente para
portación de numero.
Requisitos:
- Cedula de identidad, Pasaporte o NIT (en caso de persona jurídica, adjuntar CI del representante legal)
- Numero(s) celular(es)
- Operador Donante
Podrá importar
listado de líneas
Notifica rechazo total o parcial con causal al cliente (con opción a impresión)
Recibe causal de
rechazo
Notifica al Usuario aceptación de portación y firma suscripción al servicio
Realiza activación (Alta) en ventana de cambio
Descarga lista de
números portados
Recibe Solicitud procedente y cantidad de portaciones
Envío de solicitud de Portabilidad al ASCP
FIN
Realiza las validaciones de
solicitud del numero y a que operador corresponde
Envía notificación de rechazo Total o parcial adjuntando causas
Validación de requisitos del numero:
Tiene solicitudes de portación pendientes?
Fue portado < 30 días?
Tiene solicitud xx xxxxx pendiente?
Validar cantidad de portaciones en los últimos 12 meses e incluirla en el formulario
ASCP
Cumple NO
requisitos?
Registra y Envía
notificación de Aceptación de
solicitud
Registra numero a lista de portaciones
Publica Para todos los operadores lista de portación
SI
Envía solicitud de Portación a Operador Donante
Registra y Envía notificación de rechazo con causal
Realiza las validaciones para aceptar solicitud
En caso de listado, validar todos los atributos de todas las lineas antes de pasar a la siguiente validación. Si una no pasa, rechazar toda la lista.
Línea activa?
SI
Envía notificación de rechazo total o parcial con causal
Notifica por SMS al número de referencia, que la solicitud es
rechazada
NO
NO
Envía notificación de solicitud procedente a ASCP
Descarga lista de
números portados
Realiza desactivación (Baja) en ventana de cambio
FIN
OPERADOR DONANTE
Solicitante es el titular?
SI
Validación de requisitos del
número:
Tiene antigüedad > 60 días? Tiene corte por fraude?
Tiene comodato vigente? Tiene factura vencida?
Notifica por SMS al número de referencia, que la solicitud es procedente
NO
Cumple requisitos?
SI
ID | Funcionalidad | Acción Inicial | Resultado | Quien lo inicia? | Comentarios |
1 | Realiza solicitud de Portación | Visita del cliente de manera presencial al operador receptor | Manifiesta el deseo de portar su número con el operador receptor | Cliente | Llena y firma el formulario impreso con términos y condiciones |
2 | Operador Receptor recibe solicitud de Usuario para portación de número. | Escucha solicitud del cliente, explica Solicitud del cliente | Valida documentos requisitos necesarios | Agente de Atención | Requisitos: - Cedula de identidad, Pasaporte o NIT (en caso de persona jurídica, adjuntar CI del representante legal) - Numero(s) celular(es) - Operador Donante) |
3 | Ingresar Solicitud en el Sistema | Verifica si sistema está disponible | Ingresar solicitud con todos los datos requeridos (mínimo: Tipo documento, Nro. documento, Nro. a Portar, Operador donante) | Agente de Atención | Cada operador define el “sistema” que utiliza para el ingreso de la solicitud (Gateway, CRM u otra aplicación) |
4 | Permitir importar datos de un archivo externo | Verificar si la solicitud es de más de un número a portar. | Ingresar solicitud de manera rápida por medio de la importación de datos de una tabla Excel o archivo .txt | Agente de Atención | El cliente debe portar en un medio digital la lista de números a portar |
5 | Envío de solicitud de Portabilidad al ASCP | Llenado el formulario en archivo electrónico | Enviar solicitud de portación al ASCP | Agente de atención. | Se envía la solicitud por medio del sistema. |
6 | ASCP realiza validaciones de solicitud | Recibe solicitud del operador donante | Entregar una respuesta positiva o negativa si la solicitud es procedente. | ASCP | Validación automática. Si recibe lista, valida uno por uno, pero responde por toda la lista. |
7 | Validación de requisitos de la solicitud: Tiene solicitudes de portación pendientes? Fue portado < 30 días? Tiene solicitud xx xxxxx pendiente? | ASCP recibe número que solicita portación | Entregar respuesta positiva o negativa si el número cumple con los requisitos. En caso de no cumplir unos o más requisitos, se envía el causal de rechazo. | ASCP | Automático |
8 | ASCP envía notificación de rechazo indicando causal | Si recibe resultado negativo de las validaciones anteriores | Enviar al operador solicitante la respuesta | ASCP | Automático Detallar el motivo de rechazo por número. Si hay lista y alguno es rechazado, se rechaza |
toda la lista indicando causal de manera individual. | |||||
9 | ASCP envía solicitud de Portación a Operador Donante | Si en todas las validaciones anteriores no existe causal de rechazo | Enviar al operador donante solicitud de portación | ASCP | Automático |
10 | Realiza las validaciones para aceptar o rechazar la portación | El ASCP envía la solicitud de Portación al operador Donante | El Operador donante recibe la solicitud de portación y dispara las validaciones necesarias | GW Operador Donante | El proceso es automático |
11 | Validación si la línea | Operador | El operador donante | Operador | Validación automática |
está activa | donante recibe | valida si el número | Donante | ||
número a portar | existe, está | ||||
y número de | habilitado o | ||||
documento | vinculado a una | ||||
identidad | cuenta o cliente | ||||
existente | |||||
(independientemente | |||||
si está en servicio, | |||||
en corte por xxxx o | |||||
cualquier otro | |||||
estado) | |||||
12 | Notifica por SMS al | Validación si la | Notificar por SMS al | Operador | Si el número está activo |
número de | línea está activa. | número de | Donante | pasa a la siguiente | |
referencia, que la | Resultado | referencia que la | validación | ||
solicitud es | Negativo. | solicitud es | |||
rechazada | rechazada | ||||
Notificar al ASCP de | |||||
solicitud | |||||
improcedente | |||||
indicando causal | |||||
13 | Validación de | El operador | El sistema del | Operador | En caso de que los datos |
titularidad de la | donante dispara | operador donante | Donante | proporcionados por el | |
cuenta individual | la validación de | valida si el número | ASCP coincidan con los | ||
titularidad de la | de documento y tipo | datos registrados en el | |||
cuenta | de documento | operador donante, se | |||
corresponden al | procede a la siguiente | ||||
registro del número | validación. | ||||
a portar. | En caso de que los datos | ||||
proporcionados por el | |||||
ASCP NO coincidan, se | |||||
debe generar el rechazo | |||||
de la portación. | |||||
14 | Notifica por SMS al | Validación de | Notificar por SMS al | Operador | Si la validación de |
número de | titularidad. | número de | Donante | titularidad es procedente | |
referencia, que la | Resultado | referencia que la | pasa a la siguiente | ||
solicitud es | Negativo. | solicitud es | validación | ||
rechazada | rechazada | En caso de lista de | |||
Notificar al ASCP de | clientes, se valida la | ||||
solicitud | titularidad de todas las | ||||
improcedente | líneas y si alguna no | ||||
indicando causal | corresponde, se rechaza | ||||
toda la lista, indicando |
cuales son las líneas que no corresponden al titular | |||||
15 | Validación de requisitos del número. | El operador donante validó la titularidad | El operador donante dispara la validación simultanea de los siguientes requisitos: Tiene antigüedad > | El operador Donante | Si el número no cumple con alguno de los requisitos, se rechaza la solicitud indicando el o los motivos del rechazo. En caso de lista, se valida toda la lista y de existir causal de rechazo se entrega el resultado detallando el o los números que no cumplen. Se entiende por Fraude aquellas acciones que hace un cliente que son declaradas como actividades fraudulentas que van en contra de los términos de uso del servicio, tales como: estafas a terceros desde el número en cuestión, bypass, etc. Se entiende por factura vencida aquella factura emitida que cumple su fecha límite de pago. |
60 días? | |||||
Tiene corte por | |||||
fraude? | |||||
Tiene comodato | |||||
vigente? | |||||
Tiene factura vencida? | |||||
16 | Envío de notificación de rechazo o aceptación (Individual y masiva) | Validación de requisitos no procedentes. | Se envía un SMS de notificación de rechazo o aceptación de portación a los números solicitados | El operador Donante | |
17 | ASCP registra y | Recibe | Registrar y notificar | Automático | |
envía notificación de | respuesta de las | rechazo y causal a | |||
rechazo con causal | validaciones que | operador receptor | |||
motivan rechazo | |||||
por parte del | |||||
operador | |||||
donante | |||||
18 | Recibe causal de | Operador | Tener la información | Automático | Debe tener opción de |
rechazo | solicitante recibe | de resultado de | imprimir reporte con el | ||
del ASCP | validación para | resultado de la solicitud y | |||
respuesta de | responder al cliente | sus validaciones (motivo | |||
rechazo con | porque se rechaza | de rechazo y causales) | |||
causal, depende | solicitud | por línea | |||
de validaciones | |||||
de ASCP u | |||||
Operador | |||||
Donante | |||||
19 | ASCP registra y | Operador | Registrar aceptación | ASCP | |
envía notificación de | donante notifica | y enviar notificación | |||
aceptación de | aceptación de | a operador receptor | |||
solicitud | solicitud después | ||||
de validaciones |
20 | ASCP Registra número a lista de portación | Recibe notificación de operador donante que solicitud es procedente | Registrar en lista de portación para enviar a operadores donante y receptor para su aplicación en ventana de cambio | ASCP | |
21 | Operador receptor recibe confirmación de solicitud procedente y cantidad de portaciones del cliente | Recibe del ASCP resultado de validaciones | Notificar al usuario la aceptación de portación | Automático | Debe tener la opción de imprimir aceptación y agente de atención procede a la firma de suscripción del servicio. |
22 | ASCP Publica para todos los operadores lista de portación | Registro de solicitud aceptada | Poner a disposición la lista para que en ventana de cambio los operadores bajen los archivos con los datos de números a portación. | Automático | |
23 | Operador donante Descarga lista de números portados | El ASCP publica para todos los operadores el listado de números portados | El operador donante realiza la descarga del archivo de números que están programados para el proceso de PORT- OUT | ASCP | El ASCP enviará las listas de PORT-IN, PORT-OUT y CROSS-PORTED. Las listas se deben enviar hasta las 23:00 |
24 | Operador donante Realiza desactivación o cambio de estado en ventana de cambio | El GW del operador donante descarga el archivo de números que están programados para el proceso de PORT-OUT | El operador donante dispara la orden de baja o cambio de estado al sistema indicado. | GW del operador Donante | El proceso de PORT-OUT se debe realizar desde las 00:00 hasta las 06:00. No es necesario enviar confirmación de tarea procesada al ASCP. |
25 | Operador receptor Descarga lista de números portados | El ASCP publica para todos los operadores el listado de números portados | El operador receptor realiza la descarga del archivo de números que están programados para el proceso de PORT- OUT | ASCP | El ASCP enviará las listas de PORT-IN, PORT-OUT y CROSS-PORTED. Las listas se deben enviar hasta las 23:00 |
26 | Operador receptor Realiza desactivación o cambio de estado en ventana de cambio | El GW del operador receptor descarga el archivo de números que están programados para el proceso de PORT-OUT | El operador receptor dispara la orden de alta al sistema indicado. | GW del operador receptor | El proceso de PORT-OUT se debe realizar desde las 00:00 hasta las 06:00. No es necesario enviar confirmación de tarea procesada al ASCP. |
2. Solicitud de cambio de titularidad
PROCESO CAMBIO DE TITULAR DE LA CUENTA
DRAFT v1.0
INICIO
FIN
FIN
FIN
USUARIO
Llenar formulario de solicitud y firma
Recibe solicitud de Usuario para Cambio de Titular.
Requisitos:
(según política de cada operación)
Notifica rechazo con
causal al cliente
Realiza el cambio de titularidad
OPERADOR RECEPTOR
NO
Numero es Portado?
Proceso normal de cambio de titular.
Recibe Solicitud procedente
SI
Envío de solicitud de Cambio de titular al ASCP
Recibe causal de rechazo
Realiza las
validaciones de
solicitud si
Envía notificación de rechazo con causal
Numero tiene
solicitud pendiente?
no
si
Numero fue portado
< 135 dias?
ASCP
no
si
Numero tiene solicitud xx xxxxx?
No
Si Operador Donante es el mismo que Inicial?
No
Envía solicitud de Cambio de titular a Operador Donante e Inicial
Registra y Envía notificación de rechazo con causal
Registra y Envía notificación de Aceptación de solicitud
OPERADOR DONANTE
Realiza las validaciones para aceptar solicitud
Envía notificación de rechazo con causal
Envía notificación de solicitud procedente a ASCP
Tiene deudas SI
pendientes?
NO
OPERADOR INICIAL
Realiza las validaciones para aceptar solicitud
Tiene deudas SI
pendientes?
Envía notificación de solicitud procedente a ASCP
NO
ID | Funcionalidad | Acción Inicial | Resultado | Quien lo inicia? | Comentarios |
1 | Solicitud de cambio de titularidad | El cliente solicita el cambio de titular | Formulario llenado y firmado | Cliente | Se necesita un formulario físico. Aplicar políticas internas de cambio de titularidad. ¿Numero portado? No: Fin Si: continuar con el paso 2. |
2 | Recibe la solicitud del cliente | Los datos del formulario son introducidos en los sistemas del Operador Receptor | Solicitud recibida | Operador receptor | Se verifica si el número le pertenece al Operador Receptor, en caso positivo, se continúa con el proceso normal de cambio de titular de cada operador. Caso contrario se va al paso 3. Se crea un ticket con estado ATENDIDO |
3 | Envío de solicitud a la ASCP | Se envía la solicitud al ASCP | Solicitud enviada | Operador receptor | Se envía la solicitud a la ASCP, con los datos llenados por el cliente. Se cambia el estado del ticket a ASIGNADO ASCP |
4 | Verificación de la solicitud | Recepción de la información | Solicitud validada | ASCP | La ASCP verificará los siguientes puntos, uno después de otro, en caso de que alguno no sea validado, se pasa al paso 6 1. Si ya existe una solicitud pendiente 2. Si el número fue portado hace menos de 135 días 3. Si el número tiene una solicitud xx xxxxx En caso de que la solicitud sea aprobada se pasa al paso 5. |
5 | Envío de la solicitud de Cambio de Titular al Operador | Recepción de solicitud validada | Envío de solicitud de cambio de titular a Operador Donante | ASCP | Se envía la solicitud al Operador Donante. Se cambia el estado del ticket a ASIGNADO DONANTE, se pasa al paso 7. |
6 | Envío de la notificación de rechazo con causal al Operador Receptor | Recepción de solicitud rechazada | Envío de notificación de solicitud rechazada | ASCP | Se registra y se envía la notificación del rechazo de la solicitud y sus causas al Operador Receptor, para que éste notifique al cliente. Se cambia el estado del ticket a Cerrado. |
7 | Validaciones para aceptar solicitud | Recepción de solicitud validada por la ASCP | Envío de notificación RECHAZADA o PROCEDENT E | Operador Donante | El Operador Donante realiza sus propias validaciones para verificar que el cambio es factible, estas validaciones pueden incluir verificación de deudas pendientes y otras. En caso de que las validaciones |
sean positivas, se va al paso 8, caso contrario, al paso 9 | |||||
8 | Notificación a la ASCP de solicitud procedente | Solicitud aprobada y ejecutada por el Operador Donante | Notificación y ejecución de solicitud procedente a la ASCP | Operador Donante | Se notifica a la ASCP que la solicitud es procedente y ejecuta el cambio de titularidad en su base, se va al paso 10 |
9 | Notificación al a ASCP de solicitud improcedente | Solicitud rechazada por el Operador Donante | Notificación de solicitud rechazada a la ASCP | Operador Donante | Se notifica a la ASCP que la solicitud es improcedente con causal y se va al paso 6 |
10 | Aceptación de solicitud | Notificación recibida por la ASCP de solicitud procedente | Cambio de titularidad | ASCP | Se registra y envía la notificación de aprobación de solicitud al Operador Receptor, se va al paso 11 |
11 | Recepción de notificación de solicitud procedente | Notificación recibida por el Operador Receptor de solicitud procedente | Cambio de titularidad | Operador Receptor | El Operador Receptor recibe la notificación de solicitud procedente por parte de la ASCP y procede al cambio de titularidad según políticas internas. El ticket es cambiado a CERRADO |
Inicio
Debe cumplir ciclo
xx xxxxx del operador
Fin
Fin
no
Valida si corte
es posible
Validación si el
numero no está
eliminado
si
Cambia el estado del
Ticket a Resuelto
Reporta el corte Total fecha y hora
Ejecuta el corte Total del servicio
Cierra el ticket, registra en las listas xx xxxxxx y notifica a los dos Operadores
Recibe justificación, cierra ticket y
notifica a
Solicitante
Notifica al operador Receptor Sobre solicitud
Recibe respuesta y justificación
Ingresa Ticket de Solicitud xx xxxxx total
Fase
Proceso xx Xxxxx Total por deuda
Recibe solicitud xx xxxxx
OPERADOR DONANTE/
INICIAL
OPERADOR RECEPTOR
ASCP
3. Proceso xx xxxxx total por deuda
ID | Funcionalidad | Acción Inicial | Resultado | Quien lo inicia? | Comentarios |
1 | Solicitud xx xxxxx total | Ingreso del ticket de solicitud xx xxxxx total | Notificación al Operador Receptor | Operador Donante | Según el ciclo xx xxxxx del Operador Inicial/Donante, se inicia el flujo. El ticket cambia a estado RECIBIDO |
2 | Notificación al Operador Receptor | Recepción del ticket de solicitud | Notificación al Operador Donante | ASCP | Se notifica al Operador Receptor sobre la solicitud xx xxxxx total. El ticket cambia a estado ASIGNADO |
3 | Verificación de la solicitud | Verificación xxx xxxxx disponible | Notificación sobre el corte disponible | Operador Receptor | El Operador Receptor valida el corte disponible, si el número es válido. Si la validación es positiva, se va al paso 4, caso contrario al paso 5. |
4 | Ejecución xxx xxxxx total | Corte total permitido | Notificación xx xxxxx total | Operador Receptor | En caso de que el corte sea procedente, el Operador Receptor ejecuta el corte, registra fecha y hora del mismo, y notifica al ASCP. Se cambia el estado del ticket a RESUELTO y se va al paso 7 |
5 | Notificación de no corte | Corte total rechazado | Notificación de justificación | Operador Receptor | En caso de que el ticket no pueda ser atendido, se envía una notificación a la ASCP con la justificación de la imposibilidad de realizar el corte, y se va al paso 6 |
6 | Notificación de no corte a solicitante | Notificación de justificación | Notificación de respuesta | ASCP | La ASCP envía la notificación con la información justificando la imposibilidad xxx xxxxx al Operador Receptor. El ticket pasa al estado CERRADO. |
7 | Recepción de notificación xx xxxxx total | Notificación de ejecución xx xxxxx total | Notificación de ejecución | ASCP | La ASCP cierra el ticket, registra la información en la lista xx xxxxxx y notifica a los dos Operadores. |