Descripción del Servicio SISTEMA INTEGRADO DE … · Descripción del Servicio SISTEMA INTEGRADO...

“Decenio de las Personas con Discapacidad en el Perú”

“Año de la Integración Nacional y Reconocimiento de Nuestra Capacidad”

1

Descripción del Servicio

SISTEMA INTEGRADO DE FOCALIZACIÓN PARA LA INCLUSIÓN SOCIAL I. ANTECEDENTES

1.1. Mediante Ley N° 29792 se crea el Ministerio de Desarrollo e Inclusión Social, asumiendo la rectoría del sector desarrollo e inclusión social que comprende a todas las entidades del Estado, en los tres niveles de gobierno, vinculadas a las políticas nacionales en materia de promoción y desarrollo social, la inclusión y la equidad.

1.2. El Sistema de Focalización de Hogares, en adelante SISFOH, fue creado mediante Resolución Ministerial N° 399-2004-PCM bajo la adscripción de la Presidencia del Consejo de Ministros, estableciéndose también que sus integrantes serían la Comisión Interministerial de Asuntos Sociales (CIAS) y su Comité Técnico Social Multisectorial; la Unidad Central de Focalización; las Municipalidades; los Programas Sociales y los Ministerios responsables de los Programas Sociales.

1.3. Mediante Resolución Ministerial N° 372-2005-PCM se determinó que la

responsabilidad de la operación del SISFOH estará a cargo de la Unidad Central de Focalización, bajo el ámbito de la Dirección General de Asuntos Económicos y Sociales del Ministerio de Economía y Finanzas.

1.4. Bajo el ámbito del Ministerio de Economía y Finanzas se aprobó la Directiva

N° 001-2011-EF/65.01 la cual contiene las disposiciones para la construcción, actualización y uso del padrón general de hogares del sistema de focalización de hogares.

1.5. Mediante el Convenio N° 015-2011-INEI del 21 de noviembre de 2011 se

autorizó el barrido censal de los departamentos de Pasco, Loreto, La Libertad, Ancash, Cajamarca, Junín, Piura, Amazonas y las provincias de la sierra de Lima, de tal forma que la Unidad Central de Focalización disponga de información actualizada sobre los hogares en el país para otorgar clasificación socioeconómica.

Además, mediante el Contrato F-001-0-2374 y Adenda del Contrato F-001-0-2374 del 9 de febrero de 2012 se autorizó el barrido censal a cargo del INEI de los departamentos de Cusco, Huánuco y Puno. De la misma forma, mediante oficio N°129-2012-MIDIS/VMPES/DGGU del 28 de noviembre de 2012 se autorizó el empadronamiento por parte del INEI de los departamentos de Ica, Madre de Dios, Tacna y Ucayali. Finalmente, a través del Convenio S/N-2013-MIDIS-INEI de marzo del 2013 se autorizó el barrido censal bajo responsabilidad del INEI de los departamentos de Apurímac, Ayacucho y Huancavelica.

1.6. Durante el año 2012, mediante la Primera Disposición Complementaria Final

delDecreto de Urgencia N° 001-2012del 22 de enero 2012 se transfirió al Ministerio de Desarrollo e Inclusión Social, en adelante MIDIS, el Sistema de



2

Focalización de Hogares de forma temporal hasta el 31 de diciembre de 2012. 1.7. En virtud del convenio N° 015-2011-INEI se recibió el 21 de mayo de 2012

mediante oficio 2362-2012-INEI/DNCE la información del barrido censal realizado en las provincias de la sierra de Lima y todo el departamento de Pasco. Esta información fue complementada con el oficio 2461-2011-INEI/DNCE del 25 mayo del 2012 conteniendo el sistema de consultas y búsquedas de imágenes de las Fichas Socioeconómica Única.

Así mismo, el 7 de junio de 2012 se recibe mediante oficio 2663-2012-INEI/DNCE la información completa sobre el barrido censal realizado en el departamento de Loreto. El 8 de junio mediante oficio 2733-2012-INEI/DNCE se recibe la información del barrido censal realizado en La Libertad. El 15 de junio de 2012 mediante oficio 2885-2012-INEI/DNCE se obtiene la información del empadronamiento realizado en Ancash.

La información de Cajamarca se recibe el 25 de junio de 2012 mediante oficio 3024-2012-INEI/DNCE. El 28 de junio de 2012 el INEI envía la información del barrido censal realizado en Junín a través del oficio 3230-2012-INEI/DNCE. El 2 de julio de 2012 se recibe la información del empadronamiento realizado por el INEI en la región de Piura mediante oficio 3229-2012-INEI/DNCE mientras que finalmente a través del oficio 3245-2012-INEI/DNCE del 3 de julio de 2012 se recibe la información del barrido censal realizado en Amazonas.

1.8. En virtud del Contrato F-001-0-2374 y Adenda del Contrato F-001-0-2374 se

reciben los oficios 3615-2012-INEI/DNCE, 3941-2012-INEI/DNCE y 4156-2012-INEI/DNCEde fechas 13 de julio, 30 de julio y 8 de agosto de 2012 respectivamente con la información parcial del barrido censal realizado en Puno, Cusco y Huánuco. Esta información es complementada con el oficio 4636-2012-INEI/DNCE del 28 de agosto de 2012 con la información completa del empadronamiento realizado en Puno, Cusco y Huánuco.

1.9. De acuerdo al oficio N°129-2012-MIDIS/VMPES/DGGU se recibió mediante

oficio 7736-2012-INEI/DNCE del 14 de diciembre de 2012 la información preliminar del barrido censal realizado en Ica. El 20 de diciembre de 2012 se obtuvo la información preliminar del empadronamiento realizado por INEI en Madre de Dios a través del oficio 7970-2012-INEI/DNCE. De la misma manera, el 27 de diciembre de 2012 se recibió la información preliminar del barrido censal realizado en Tacna mediante el oficio 8054-2012-INEI/DNCE. Finalmente, el 28 de diciembre de 2012 se recibió mediante el oficio 8110-2012-INEI/DNCE la información completa del empadronamiento realizado por INEI en las regiones de Ica, Madre de Dios, Tacna y Ucayali.

1.10. En base al Convenio S/N-2013-MIDIS-INEI se recibió mediante oficio 236-

2013-INEI/DNCE del 7 de junio de 2013 la información completa respecto al barrido censal realizado por INEI en los departamentos de Apurímac, Ayacucho y Huancavelica.

1.11. En virtud de lo establecido en el artículo 26° de la Ley N° 29951, Ley de

Presupuesto del Sector Público para el Año Fiscal 2013, se dispuso que la



3

Unidad Central de Focalización a cargo de la operación del SISFOH, se encuentra bajo el ámbito de la Dirección General de Gestión de Usuarios del Ministerio de Desarrollo e Inclusión Social de manera definitiva.

En este marco, mediante la Resolución Ministerial N° 018-2013-MIDIS se

declaró en proceso de adecuación la organización, funcionamiento, procedimientos y actividades de la Unidad Central de Focalización a cargo de la operación del SISFOH a lo dispuesto en el artículo 26 de la Ley N° 29951, con el objeto de garantizar que se sujete a los criterios de política sectorial de desarrollo e inclusión social, y a los valores y principios consagrados en la Ley N° 29792, Ley de Creación, Organización y Funciones del Ministerio de Desarrollo e Inclusión Social.

1.12. Asimismo, la Sétima Disposición Complementaria Final de Ley N° 29792 - Ley

de creación, organización y funciones del Ministerio de Desarrollo e Inclusión Social dispone la creación del Registro Nacional de Programas Sociales y el Registro Nacional de Beneficiarios de Programas Sociales, a nivel intergubernamental, debiéndose implementar además un mecanismo de cruce de información y alerta temprana, destinado a prevenir filtraciones y subcoberturas en el sistema.

II. DESCRIPCIÓN DE LA SITUACIÓN ACTUAL

DE LA FOCALIZACIÓN DE HOGARES La focalización de hogares se realiza a través de la utilización de la Ficha de Socioeconómica Única, este instrumento se emplea a nivel nacional y su llenado es realizado por las municipalidades. Esta Ficha cuanta con alrededor de 155 campos que deben ser llenados por un empadronador y luego deben ser transferidos a un medio digital (ver anexo 2). Como se refiere en el párrafo anterior, el primer mecanismo por el cual se carga información es a través de las Unidades Locales de Focalización (ULF), que se encuentran a cargo de las municipalidades, e inicia cuando se cuenta con las fichas debidamente llenadas que luego son registradas a través un aplicativo de escritorio denominado SISFOH (desarrollado en C++ Builder). Posteriormente, esta información es exportada a archivos de extensión PGH, que es un archivo comprimido que contiene 4 archivos DBF, que luego son remitidos a la sede central de la Unidad Central de Focalización (por correo o CD), donde serán validados a través de un conjunto de reglas de consistencia y se aplicará el cálculo de un algoritmo que permita determinar el nivel socioeconómico del hogar. El primero de estos cálculos hace referencia a la integridad de la ficha y su objetivo es que estas no contengan información inconsistente. Esta validación se realiza a nivel de base de datos, a través procedimientos almacenados. El segundo de estos cálculos está referido al cálculo del nivel socioeconómico de los hogares. Este es un cálculo matemático que se basa en la valorización de cada uno de los campos según determinados criterios; pudiendo incluso utilizarse información



4

completaría proporcionada por otras entidades del Estado. Este proceso también se realiza a nivel de base de datos a través del uso de scripts programados en PL-SQL. Posterior a ello, se realizan una última validación que está asociada a la identificación de las personas que componen un hogar; para ello se utiliza información proporcionada por el RENIEC. Al término del proceso de clasificación socioeconómica, se procede a aplicar las reglas de actualización de hogares previo a su incorporación en el Padrón General de Hogares. Este proceso debe ser automatizado y parametrizado. Un segundo mecanismo de carga de información es través de los empadronamientos bajo la modalidad de barrido censal. En este mecanismo la información es presentada directamente en dos archivos DBF. Estos archivos son validados del mismo modo que los archivo PGH del primer mecanismo. Adicionalmente, envían un archivo SPSS que para los fines de la validación, se utilizan para contrastar algunos campos que puedan venir en condición no legibilidad. Un tercer método, que aún se encuentra por implementar, contempla la posibilidad que las FSU sean registradas en línea a través de un aplicativo web. En este caso el aplicativo se encargaría de realizar la primera validación (referida a la consistencia de la información), lo que mejoraría la calidad de las FSU enviadas a la sede central. Cabe señalar que cada cambio realizado en las FSU es almacenado en una base de datos distinta. Si bien los cambios en la estructura de las FSU a lo largo del tiempo no han sido significativos, a la fecha no se cuenta con información integrada en una única base de datos, por tanto, se prevé como una necesidad la integración de estas versiones de la FSU que a la fecha asciende a aproximadamente 40 millones de registros. Desde el punto de vista técnico, se cuenta con 07 bases de datos de SQL SERVER 2008 y 05 bases de datos en ORACLE 11g que deben ser integradas en una única base de datos que permitan la navegación entre los registros que han sido almacenados a lo largo del tiempo. Igualmente, se hace necesaria la construcción de un sistema que permita la carga de esta información, su validación en línea, fuera de línea y a nivel de base de datos. Igualmente, debe permitir que se ingresen o retiren campos de las FSU y que los criterios de validación puedan ser modificados. También debe estar listo para recibir servicios web de entidades como RENIEC o SUNAT que coadyuven a la validación de las fichas.

DEL REGISTRO NACIONAL DE USUARIOS - RNU

El Registro Nacional de Usuarios es el repositorio que contiene la información sistematizada y actualizada de los usuarios afiliados a los programas sociales o de subsidios del estado – PPSS. La información que administrada comprende los tres niveles de gobierno.



5

De esta forma, el Ministerio de Desarrollo e Inclusión Social puede realizar un monitoreo adecuado de los beneficiario de estos PPSS, a fin que puedan generarse cruces de información y realizar alertas tempranas, destinos a prevenir filtraciones y subcoberturas en el sistema. Actualmente, la información es remitida por los programas sociales en formato de texto plano (.txt), texto separado por comas (.csv) u hojas de cálculo (.xls) a través de correo o medios magnéticos, no obstante, este mecanismo no ofrece los niveles de seguridad que permitan garantizar la integridad de la información. Igualmente, esta información, a pesar que es solicitada con una estructura determinada, no siempre cumple con las validaciones mínimas que garanticen su idoneidad, teniendo que realizarse, en el MIDIS, una validación de esta información, que en ocasiones termina haciendo que esta tenga que ser devuelta alosPPSS que la remitieron. Una vez la información es validada, en cuanto a su integridad, se procede a realizar una verificación de la identidad de los usuarios. Este proceso se realizar en conjunto con el Registro Nacional de Identidad y Estado Civil – RENIEC; no obstante, es proceso se realiza sin ayuda de herramientas que faciliten su automatización. Al término de la validación de la identidad realizado por el RENIEC, se ejecuta un conjunto adicional de reglas que permiten determinar, por aproximación, aquellos registros que no tuvieron coincidencia exacta respecto a lo que remitió inicial al RENIEC. Este proceso es similar al que se realiza en la validación de identidad para el Padrón General de Hogares. Adicionalmente, el MIDIS, cuenta con un Manual de Reglas de Consistencia cuyo objetivo es garantizar la calidad de la información recolectada para el Registro Nacional de Usuario, que deben ser aplicados por lo Programas Sociales durante la generación de su información; no obstante, estas reglas no pueden ser del todo aplicadas en razón que no todos los PPSS cuentan con sistemas de información o lo los que cuentan no permiten realizar este tipo de validaciones. Esta situación hace que sea complicado consolidar la información del 100% de los programas sociales a nivel nacional Es por ello que se hace necesario potenciar el Registro Nacional de Usuarios a través la implementación de un enfoque de inteligencia de negocios, que involucraría la construcción de una datawarehaouse, un aplicativo que permita validar la información, en el lugar y previo a su envió, de la información generada por los PPSS y la construcción de un sistema de distribución masiva que permita la gestión básica de los programas sociales que no cuenta son sistemas informáticos. Adicionalmente, para complementar la integración del Padrón General de Hogares y el Registro Nacional de Usuarios, será necesario desarrollar un módulo que se encargue de gestionar el Registro Nacional de Programa Sociales y Subsidios del Estado - RNPSSE.

III. OBJETIVO DE LA CONSULTORÍA

Dotar al MIDIS deun sistema integrado que permita la administración de la



6

información del Padrón General de Hogares, Usuarios de los Programas Sociales y Subsidios del Estado y el Registro Nacional de Programa Sociales y Subsidios del Estado – RNPSSE desde su carga, que se realiza por diversas fuentes, hasta la validación final, así como generar reportes, información estadística y explotación de datos (BI).

IV. ALCANCE DEL TRABAJO

El Sistema Integrado de Focalización para la Inclusión Social estará compuesto por dos grandes subsistemas cuyo alcance será el siguiente: Para la Focalización de Hogares (SISFOH)

Integrar las 12 basesde datos(aproximadamente) correspondientes a las distintas versiones dela FSU a lo largo del tiempo en una única base de datos.

Diseñar, desarrollar e implementar un sistema que permita la carga de información a través de tres fuentes:

o Municipalidades (archivos FSU). (Aplicativo escritorio) o Empadronamiento por barrido (archivos DBF). (Aplicativo web) o En línea. (Aplicativo web)

El aplicativo web debe contemplar la migración de la lógica desarrollada para la validación de consistencia para que sea empleada en los mecanismos de carga en línea, así como a un aplicativo de escritorio multiplataforma(desarrollado en Java) que permita la validación de los archivos FSU fuera de línea. Esta lógica debe ser parametrizable en el sistema web de manera que pueda ser modificada según las necesidades de la entidad. Asimismo, en la generación de la información debe figurar en la cabecera la versión de la regla de validación utilizada, de tal manera que se pueda llevar un control de versiones utilizadas por las ULF.

La construcción de un aplicativo de escritorio multiplataforma (desarrollado en Java y empleando SQL Lite) que permita a las ULF registrar las FSU siguiendo los parámetros mínimos a registrar definidos por el MIDIS. Asimismo, permitirá garantizar que la información que se registre sea consistente de acuerdo a los parámetros del MIDIS y exportar la información en un formato .FSU (archivoXML) para su posterior envío al MIDIS.

El aplicativo web debe contemplar la migración de la lógica desarrollada para el cálculo del algoritmo declasificación socioeconómica de manera que pueda ser parametrizable según cada caso.También debe contemplarse la utilización de información complementaria de bases de datos de otras entidades como una variable adicional en el algoritmo (estas variables pueden incrementar o decrementar según lo establezca la institución).

El aplicativo web debe contemplar la validación de la identidad de las personas inscritas; para ello deberá estar en capacidad de consumir un servicio web del RENIEC (Actualmente,la Unidad Central de Focalización tiene convenio con el RENIEC para acceder al referido webservice). Asimismo, deberá estar en la capacidad de exportar e importar información referente a la identidad de la población en formato de archivos



7

DBF, archivos XML y formato de texto(.TXT) para que sean validados por el RENIEC.

El aplicativo web debe contemplar la automatización de la lógica empleada para la actualización de hogares, que ya se encuentra previamente establecida por la institución. Esta automatización debe ser 100% parametrizable.

Ambos aplicativos deben contemplar mecanismos que garanticen la seguridad de la información que contiene. Para ello, deben establecerse usuarios con roles, perfiles y permisos, y cuyos accesos individuales puedan ser gestionados por un administrador.

Ambos aplicativos deben contar con un módulo de consulta que permita acceder a la información a través de filtros y búsquedas booleanas. Esta información debe poder ser exportada a XML, CSV, XLS y PDF.

Ambos aplicativos deben contar con un módulo de reportes que permita seleccionar los campos, imprimir y exportar la información, a través del ingreso de parámetros o como resultado de una búsqueda booleana en la base de datos.

El sistema debe estar preparado para consumir servicio web de RENIEC y brindar servicios web a los PPSS y ULF, además debe considerar conceptos de escalabilidad a nivel de software y una concurrencia máxima de 5000 usuarios simultáneos.

Se prevé un crecimiento de 5 millones de registros por año. El sistema debe considerar como insumo los procesos descritos en el anexo

03, así como otros que devengan de estos.

Para la RNU y RNPSSE

Migrar la información contenida en la Base de Datos del Registro Nacional

de Usuarios a un esquema que permita su tratamiento a través de herramientas de explotación de datos (Inteligencia de Negocios). Actualmente se cuenta con 81 millones de registros, que a su vez están conformado por 51campos.

Desarrollar un aplicativo en web que permita gestionar el Registro Nacional de Programas Sociales y Subsidios del Estado de acuerdo a la Ficha del Anexo N° 07.

La construcción de un aplicativo de escritorio multiplaforma (desarrollado en Java) que permita la validación fuera de línea de los archivos generado por los PPSS previo a su remisión al MIDIS. Esta lógica debe ser parametrizable de manera que pueda ser modificada según las necesidades de la entidad. Asimismo, en la generación de la información debe figurar en la cabecera la versión de la regla de validación utilizada, de tal manera que se pueda llevar un control de versiones utilizadas por los PPSS.

La construcción de un aplicativo de escritorio multiplataforma (desarrollado en Java y empleando SQL Lite) que permita a los PPSS registrar las atenciones u otra información para su gestión básica. Estos parámetros mínimos a registrar serán definidos por el MIDIS. Asimismo, permitirá garantizar que la información que se registre sea consistente de acuerdo a los parámetros del MIDIS y exportar la información en un formato .RNU



8

(archivos XML) para su posterior envío al MIDIS. El módulo del RNU debe contemplar la validación de la identidad de las

personas inscritas; para ello deberá estar en capacidad de consumir un servicio web del RENIEC (Actualmente, la DGGU tiene convenio con el RENIEC para acceder al referido webservice). Asimismo, deberá estar en la capacidad de exportar e importar información referente a la identidad de la población en formato de archivos DBF, archivos XML y formato de texto (.TXT) para que sean validados por el RENIEC.

Ambos aplicativos (web y de escritorio) deben contemplar mecanismos que garanticen la seguridad de la información que contiene. Para ello, deben establecerse usuarios con roles, perfiles y permisos, y cuyos accesos individuales puedan ser gestionados por un administrador.

Configuración de la herramienta de Inteligencia de Negocios y construcción de estructuras lógicas que permitan la explotación de la información del RNU.

V. PRODUCTOS O ACTIVIDADES

Al inicio de la consultoría, y una vez que el contrato haya sido suscrito, la Dirección General de Gestión de Usuarios (DGGU) y la Unidad Central de Focalización (UCF)entregarán a la consultora toda la documentación e información que se requiera para la elaboración de los productos: Producto 1 – Documentación inicial (SISFOH y RNU): El primer producto está orientado a los actos previos del inicio de las actividades. Este constará de la presentación de los siguientes documentos:

Metodología de gestión del proyecto. Metodología de desarrollo del software. De acuerdo a la Metodología del

MIDIS aprobada Metodología de aseguramiento de la calidad. Cronograma de trabajo, señalando rutas críticas. Especificaciones técnicas mínimas para la adquisición de servidores y otros

equipos que alberguen el sistema a desarrollar (servidores, equipos de conectividad, equipos de seguridad, entre otros).

Producto 2 – Análisis y definición del modelo de base de datos (SISFOH y RNU): El segundo producto se enfoca en el análisis y diseño del sistema, donde se debe definir el alcance del sistema, establecer los requisitos del sistema e identificar subsistemas. El sistemaesperado, en lo referido al Padrón General de Hogares, requiere contar con un modelo de datos que garantice una base de datos ágil respecto al manejo transaccional.Por ello es necesario que se considere la información que actualmente tiene la UCF almacenada en sus bases de datos.



9

Asimismo, en lo referido al RNU y RNPSSE, requiere contar con un modelo de datos de acuerdo las estructuras de cada producto. Asimismo, se requiere contar un modelo de datos que permita la explotación de la información a través del uso de herramientas de inteligencia de negocios, es decir, se debe contemplar que el diseño debe estar orientado a ser un datawarehouse de información. Para ambos casos será necesario elaborar el diagrama de base de datos, con su respectivo script de generación, así como el diccionario de datos que explica cada una de las tablas del modelo así como los campos que las componen y relaciones que existen entre ellas. Del mismo modo, es importante que se defina el diccionario de datos de tablas complementarias que coadyuven al sistema principal. Estas tablas son las que se emplearán en los sistemas de carga de información fuera de línea (empadronamiento por demanda), por empadronamiento de un barrido censal o por ingreso en línea. Adicionalmente, será necesario que en esta etapa se elabore la documentación que exige la metodología de desarrollo del Ministerio de Desarrollo e Inclusión Social (MIDIS) que corresponda a esta etapa, según se detalla en el anexo N°04 del presente documento. Cabe precisar que el modelo a implementarse deberá ser escalable, permitiendo incorporar nuevas estructuras de datos, sin afectar el modelo.También considerar la inclusión de técnicas que permitan la extensión de las definiciones de las tablas y que la desactivación de los atributos sea en base a criterios de seguridad; de esta manera se garantiza que la convivencia de varias versiones podría ser posible bajo un enfoque de extensión de atributos. Producto 3 – Migración de bases de datos del SISFOH al nuevo modelo de base de datos (SISFOH y RNU): Una vez definido el modelo de datos y la documentación del sistema se debe proceder a efectuar la migración de la información del SISFOH al nuevo modelo de datos (transaccional). Para ello se deben realizar pruebas que garanticen la eficacia de la migración final, por tanto para este producto se requiere garantizar que al menos el 25% de los registros de cada una de las bases de datos del SISFOH, tanto bases fuentes como complementarias; sean migrados sin errores y en un proceso desatendido. Dicha migración deberá estar de acorde a la Regla de Integración definida por la UCF. Finalmente el proceso de migración se debe realizar al 100% sin tolerancia de errores. Para el modelo de explotación de información del RNU será necesario que la migración se realice al 100%, sin tolerancia a errores. Para ello se extraerá información de las bases de datos de la Dirección General de Gestión de Usuarios que se encuentra en una instancia de Oracle 11g a otra instancia sobre el mismo motor de base de datos. Asimismo, la firma consultora deberá entregar elplan de migración con losscript, códigos fuentes,librerías y consideraciones acordadas que permita posteriores



10

migraciones por parte del MIDIS, deberá entregar adicionalmente los scripts de estadísticas requeridos para evaluar la información migrada. Producto 4 – Sistema base, módulo de seguridad, módulo de administración de tablas maestras y carga de información: Una vez se cuente con losmodelos de las bases de datos (transaccional y de explotación de información) se debe iniciar la construcción del software que permita la actualización de información en las bases de datos. Para ello, debe adicionar a cada avance la presentación de la documentación correspondiente, según lo establece la metodología de desarrollo de software del MIDIS. 4.1 Sistema Base y módulo de seguridad (SISFOH y RNU): El sistema base se le denomina al entorno sobre el cual trabajarán los módulos del sistema. Este debe incluir un módulo que se encargue de la gestión de usuarios, roles perfiles y permisos. Asimismo, debe contar con un módulo que permita la gestión de accesos según cada rol y perfil. Los datos mínimos a considerar son: Código de usuario, login (Usuario), Clave (Contraseña), email, observaciones, código de persona, teléfono, rango de horario de trabajo, rol (Administrador, gestión, gerencial, supervisor, operador), permiso (lectura/escritura), estado, acceso tablas maestras (crea/modificar tablas maestras/ acceso restringido), fecha de registro, fecha baja, descripción de baja, usuario baja, niveles de privilegio, grupo al que pertenece. Este módulo de seguridad debe permitir la creación de nuevos roles y a la asignación de 3 permisos básicos: lectura, escritura, eliminación. Cabe señalar que la eliminación para este sistema se debe considerar como una eliminación lógica y no física, es decir, que el (los) registro(s) deben ser deshabilitados pero nunca borrados. Sobre la información de los usuarios, debe presentarse la posibilidad que el administrador cree campos nuevos (atributos adicionales a las tablas maestras de seguridad) para registrar información que inicialmente no fue contemplada. Estos campos deberán ser creados en la tabla correspondiente desde el software y reflejarse automáticamente en el módulo de seguridad y en la tabla maestra.

4.2 Módulo de Administración de Tablas Maestras (SISFOH y RNU): El módulo de administración de tablas debe permitir la creación, eliminación y modificación de los registros en cada una de las tablas de sistemas. Asimismo, los campos deberán ser creados en la tabla correspondiente desde el aplicativo web y reflejarse automáticamente en la tabla maestra. Igualmente, debe permitir la exportación de la información en formatos XML, XLS y CSV sobre la base de filtros básicos. La información de los reportes de cada tabla debe presentar información legible y no los códigos de los campos llave, es decir, si se cuenta con un campo que proviene de otra tabla, el reporte deberá mostrar la



11

información del campo, según la descripción de la tabla originaria y no el código de la llave primaria.

4.3 Módulo de Carga de Informacióny Módulo de Gestión del FSU (SISFOH): El módulo de carga de información es el primer paso para la evaluación socioeconómica y se encarga de centralizar y consolidar la información proveniente de las ULF, instituciones que realizan empadronamiento a través de barrido censal y las bases de datos administrativas. Este módulo debe contener una versión para la carga en línea de la información. Este debe ser realizado en entorno web y con la capacidad de ser visualizada en dispositivos móviles (una versión en ANDROID y otra para IPHONE/IPAD). La información de carga, será un archivo de formato FSU (archivo XML), dicho archivo es proveído por el aplicativo de escritorio que se desarrollará como parte de esta consultoría para el registro de las fichas socioeconómicas únicas.Este archivo deberá ser validado aplicándosele reglas de consistencia posterior a la carga visualizándose alertas de estado de la información cargada. En referencia a la carga de las bases administrativas, debe considerar la definición de la estructura a cargar, luego la verificación de calidad de la información y por último la parametrización de las reglas de negocio, con la finalidad de interactuar con el sistema. Dicho proceso es diferente por cada base administrativa. Asimismo, durante la carga de la información el sistema debe aplicar la regla de consistencia que tiene el SISFOH previamente establecido y reportarle al usuario, las incidencias de inconsistencia presentadas, indicando la regla y los valores que lo hicieron inconsistente. Sólo deberá permitirse la carga de aquellos archivos FSU que no presenten inconsistencia. Cabe precisar que las Reglas de Consistencia comprende el conjunto de procedimientos teóricos y prácticos que sirven para completar y corregir omisiones u errores de la información recopilada en la FSU. Y generalmente tiene el objetivo de obtener una Base de Datos que permitirá conocer las características físicas de la vivienda, del hogar, así como de las personas que integran el hogar. Esta acción permitirá analizar la información evitando omisiones, duplicaciones e inconsistencias en las variables investigadas, lo que permitirá obtener resultados veraces, confiables y oportunos. Asimismo, el aplicativo de escritorio debe contemplar un módulo de consistencia que permita la revisión de la consistencia de la información, previo a su remisión a la UCF. Este módulo debe poder ser actualizado a través de la carga de un archivo de reglas de consistencia que será descargado automáticamente del servidor del MIDIS. Este debe garantizar la validación de acuerdo a la versión dela FSU y su regla de consistencia correspondiente. Este módulo debe validar previamente un archivo FSU, a fin de que el archivo antes de ser cargado, se encuentre sin inconsistencia, para que luego pueda ser fácilmente cargado en la base de datos transaccional, a través de un módulo construido especialmente para este fin. El aplicativo de escritorio, debe tener la funcionalidad de poder sincronizar la base de datos local SQLite a nuestra base de datos Oracle, se puedan realizar



12

validaciones según reglas de consistencia (Iguales a las reglas de consistencia que realizará el módulo web al cargar el archivo XML exportado por el aplicativo de escritorio). Una carga masiva de información, es la proveniente de un barrido censal, por eso, el aplicativo web debe permitir la carga de información que se genera a partir del empadronamiento a través del método de barrido censal. Este mecanismo también debe aplicar la regla de validación y poder cargar la información sobre la base de la estructura generada a través de este método. Asimismo, el aplicativo web deberá contar con un segundo proceso de consistencia a nivel central de acuerdo a las reglas de negocio definida para este proceso por la UCF. La regla de consistencia debe poder ser modificada a voluntad de la entidad y tener una validez de aplicación según el periodo que se establezca. De la misma manera, el sistema deberá tener un módulo que permita gestionar la Ficha Socioeconómica Única, que precisamente permitirá registrar la ficha en línea, permitiendo su edición, modificación, búsqueda y eliminación. Asimismo, el sistema deberá aplicar la regla de consistencia antes de grabar la ficha y aceptar sólo registros consistentes. El módulo de registro de la FSU, debe tener las siguientes consideraciones: El registro del formulario debe seguir el orden de la numeración de capítulos

(secciones) de la Ficha Socioeconómica Única sin poder continuar si su antecesor no está completa en sus campos obligatorios.

El registro del formulario debe permitir grabar la ficha incompleta para su posterior actualización, llevando un control del estado de registro de la ficha.

Al procesar (grabar la ficha socioeconómica) debe mostrar una pantalla de información estadística del proceso: Nro. de Personas Procesadas y descripción de las inconsistencias encontradas. En caso de encontrarse la ficha inconsistente no deberá permitir el grabado de la información.

El módulo debe contener una ayuda interactiva para la digitación de la ficha, teniendo como base la Guía y Manuales para el Empadronamiento de hogares.

Cabe precisar, que el sistema debe contar con un módulode gestión de plantillas de la FSU que permita modificar la plantilla según lo requiera la entidad diferenciándose por versiones. Esta modificación deberá implicar la creación de nuevos campos en las tablas y la desactivación de aquellos que no se utilicen a fin de poder garantizar la convivencia de varias versiones deFSU en la misma base de datos transaccional. Este requerimiento es aplicable para el aplicativo web y de escritorio, en relación a la reglas de negocio vigente.

4.4 Módulo de Carga de Información RNU y Módulo de Gestión del PPSS (RNU):



13

Para el RNU se debe considerar que los PPSS cuentan con un conjunto de lineamientos definidos por el MIDIS que establecen la estructura de la información que deben remitir a la DGGU. Para este caso se debe contemplar un módulo de consistencia offline (aplicativo de escritorio) que permita la revisión de la consistencia de la información, previo a su remisión ala DGGU. Este módulo debe poder ser actualizado a través de la carga de un archivo de reglas de consistencia que será descargado automáticamente del servidor del MIDIS. Este debe garantizar la validación de acuerdo a los parámetros y regla de consistencia correspondientes. Asimismo debe validar los archivos en formato .txt, .csv o .xls de los PPSS y exportarlos en formato .RNU, de tal manera que el archivo se encuentre sin inconsistencias antes de ser cargado. Asimismo, para los PPSS que no cuenten con sistemas de información, se debe considerar la construcción de un aplicativo de escritorio que permita a los PPSS registrar información básica respecto a las atenciones que brinda a fin que este luego pueda ser exportada a un formato RNU que es un archivo comprimido en cuyo interior se encuentra un archivo en formato XML, para que sean remitidos al MIDIS. El sistema debe garantizar que la información que se registre en él sea consistente de acuerdo a los parámetros que establezca el MIDIS. Revisar Anexo N°07. Finalmente, previo a la carga de información, el módulo deberá identificar la duplicidad de los registros (registros iguales en todos sus campos) entre el archivo RNU y la información existente en el datawarehouse. Para ello deberá marcar con un flag la información más antigua (borrado lógico automático) y considerar la más reciente. Para casos en donde exista duplicidad por aproximación (mismo DNI y fecha de atención pero otros campos distintos) el sistema deberá permitir que el operador tome la decisión sobre cual registro considerar (borrado lógico discrecional). Luego se generará un reporte automático de las ocurrencias (en ambos casos).

Producto 5 – Módulo de gestión de la identidad y módulo del cálculo socioeconómico: 5.1 Módulo de gestión de la identidad (SISFOH y RNU) El módulo de gestión de la identidad es aquel que se empleará para garantizar la identidad de las personas incluidas en los registros de empadronamiento y de los PPSS.Esta verificación se realiza con el apoyo del RENIEC y puede efectuarse de dos formas. La primera es a través de la generación de un archivo según una estructura definida por el MIDIS y en varios formatos de archivo como CSV, DBF, TXT y/o XML. Que luego es completado por el RENIEC e importado nuevamente para completar la información. La segunda es a través de la validación directa empleando un servicio web proporcionado por el RENIEC. En este módulo deben considerarse estados respecto a la información a fin que puedan identificarse como únicos los bloques de información que se remiten al RENIEC y aquellos bloques que retornan al MIDIS para su incorporación en las



14

bases de datos correspondientes. Este módulo será utilizado para el PGH y para el RNU. En relación, a la información observada por el RENIEC, se debenejecutar las reglas de recuperación de identidad, las cuales deben ser parametrizables y permitir el envío nuevamente a RENIEC para confirmar y completar los datos. Las reglas de recuperación de identidad serán entregadas a la Consultora al siguiente día útil de suscrito el contrato. 5.2 Módulo de cálculo socioeconómico (SISFOH) Este módulo se encarga de efectuar el cálculo del nivel socio económico del hogar. Para ello se realiza una primera etapa sobre la base de la información presentada en la FSU y complementada con información de las bases administrativas. Se deberá contar con un módulo donde se permita precisar los campos y valores para el cálculo del algoritmo. Dichos datos serán aplicados según el algoritmo vigente aprobado por el MIDIS. Asimismo, dicha configuración deberá ser modificada a voluntad de la UCF y tener una validez de aplicación según el periodo que se establezca. Producto 6 – Módulo de gestión de actualización del PGH (SISFOH)

Deberá permitir la actualización de la información del Padrón General de Hogares, tras la aplicación de reglas definidas por la Unidad Central de Focalización. El alcance funcional de dicho módulo es el siguiente:

Generación de información de los hogares identificados con Clasificación socioeconómica, esto será posible teniendo como insumos la base de datos de las FSU que hayan pasado el proceso de consistencia y el cálculo de la clasificación socioeconómica. Además de los datos de la población identificada por RENIEC.

Aplicación de reglas de actualización de hogares definidas por la UCF, teniendo como resultado en qué casos procede la actualización: 1. Cambio de estado en relación a la vigencia de información, 2. Actualización de los datos del hogar o la inserción de información de nuevos hogares en el PGH.

Generación de información con hogares observados: Contiene la información de hogares observados como resultado de la aplicación de reglas de actualización de hogares, definidas por la UCF.

Envío de mensaje por correo electrónico institucional sobre información de hogares observados para la atención del especialista en focalización. Los campos de datos de cuerpo del correo electrónico deben de ser configurables. Datos a considerar: Ubicación del archivo. Fecha y hora de envío. Usuario que generó el archivo Nombre del archivo



15

Resumen de contenido (número de registros, tamaño de archivo, otros)

Registro del resultado de análisis realizado por el especialista en focalización: Contiene un breve resumen de la opinión emitida, definición de estados y criterios de actualización.

Actualización del PGH: Genera una base de datos del PGH preliminar para la validación y aprobación para su pase a producción por el Área de Calidad de la UCF.

Pase a producción: Actualización del PGH en el servidor de producción y envío de mensajes automáticos vía correo electrónico institucional a las siguientes áreas: Coordinadora General de la UCF. Calidad de Información. Soporte a ULF. Atención al usuario. Tecnologías de Información.

Producto 7 – Explotación de la Información (RNU) Este producto constará de la configuración de la herramienta de Inteligencia de Negocios que emplea la DGGU para su óptima utilización así como las construcción de las estructuras lógicas y herramientas de extracción que permitan la carga desde el repositorio general (datawarehouse del RNU). La base de datos transaccional del PGH y otras bases de datos complementarias. Adicionalmente, deberán configurarse como mínimo los tableros de control para los indicadores establecidos por la DGGU: Filtración, Subcobertura, Caracterización de los usuarios, condición socioeconómica de los usuarios de la PPSS, cobertura de los programas sociales, ámbito de acción de los programas sociales,e intersección de los programas sociales en zonas geográficas. Asimismo, deben configurarse las herramientas de inteligencia de negocios para que se pueda generar reportes por cada uno de las dimensiones e indicadores del tablero de control, así como otros respecto a la información contenida en el datawarehouse. Producto 8 – Módulo de Reportes (SISFOH y RNU)

Reportes de Procesos: Carga de Datos: Estado de carga de la información. Consistencia de Fichas: Reportes de inconsistencias de las FSU y RNU

Inconsistencias más frecuentes. Cálculo de la clasificación socioeconómica: Resultado de clasificación

socioeconómica, relación de hogares que cuentan con información complementaria, impacto de clasificación socioeconómica por información complementaria.

Recuperación de Identidad: Reporte de Datos enviados a RENIEC, reporte de resultado del procesamiento de RENIEC y resultado del proceso.



16

Proceso de Integración de PGH: Reporte de actualización, Hogares Observados, resultados del análisis de hogares observados y resultado de las reglas de actualización de hogares.

Reportes de Gestión: Este sub-módulo permitirá autogenerar reportes del tipo booleano y genéricos en base a los principales variables de información del sistema, como: Ubigeo, Área, Fecha, Sexo, Nivel Educativo, Edad, Tipo de Vivienda, Grupo Etario, Acceso a servicios públicos, En dicho reporte el usuario podrá elegir cuantas variables considere en el reporte e indicar los criterios permitidos por la variable. Asimismo, contar con un reporte de caducidad de la FSU.|

Reportes de Explotación: El sistema debe considerar la capacidad de almacenar un repositorio con los informes que se generen a través de las herramientas de Inteligencia de Negocios. En esta sección se deberá registrar como mínimo la fecha en la que se creó el informe, el usuario y cantidad de descargas.

Adicionalmente, se deberán entregar todos los manuales, fuentes librerías, scripts y cualquier otro instrumento que haya sido elaborada para la presente consultoría, así como los planes de implementación, contingencia y otros para la puesta en marcha del sistema y que garanticen su adecuado funcionamiento en el tiempo.

VI. DETALLE DE LOS ENTREGABLES

Se deberá considerar que toda la aplicación sea parametrizable. Asimismo el desarrollo web deberá cumplir con lo precisado en el Top 10 del Proyecto OWASP para aplicaciones web y garantizar la seguridad de la aplicación.

Características generales de todos los módulos ‐ Un sistema amigable e interactivo (en virtud de las buenas prácticas de

diseño y desarrollo de aplicaciones WEB): Identificación del usuario en todas las pantallas (nombre, rol y

privilegio). Diseño de fase de navegación y usabilidad a través de cada pantalla. Configurable. Administrable. Parametrizable. Se dará preferencia a aquellas propuestas que

incluyan un motor de gestión de políticas para realizar esta función.

‐ Considerar como un factor relevante: Código fuente y objetos de base de datos optimizados. Código fuente indentado y comentado. Funcionamiento en todos los navegadores. Diseño web adaptativo.



17

La seguridad de la información (acceso no autorizado, ataque de hackers, pérdida de información, inyecciones SQL, Cross-site scripting, entre otros).

Mantener un log de operaciones realizadas en todos los casos (historial).

‐ Permitir reutilizar los objetos como: procedimientos almacenados, vistas, funciones, en caso de ser necesaria la modificación y/o creación de estos objetos, de alguna rutina o de un servicio web, los cuales deberán realizarse de acuerdo a los estándares de programacióny base de datosdel MIDIS.

‐ Este sistema debe permitir la validación de los datos personales con RENIEC.

‐ Todos los documentos de acuerdo a la metodología aprobada del MIDIS VII. REQUERIMIENTOS NO FUNCIONALES

Las aplicaciones en web deberán desarrollarse en JAVA utilizando base de datos ORACLE versión 11g, según metodología de desarrollodel MIDIS (ver anexo 04).El aplicativo de escritorio PGH y del RNU deberá ser desarrollado en JAVA con base de datos SQLite. El aplicativo web del SISFOHdeberá permitir una concurrencia mínima de 5000 usuarios y deberá ser escalablepermitiendo la generación de nuevos módulos. Asimismo, el modelo de la base de datos deberá ser escalable, permitiendo la incorporación de nuevos objetos, como tablas, vistas, procedimientos, y funciones que se integren al modelo de base de datos que se implemente. El sistema debe ser eficaz, lo que permite al usuario identificar fácilmente la finalidad y objetivo del sistema y deberá realizar tareas con un 0% de error. El sistema debe ser tolerante a errores de ingreso, ayudando al usuario con mensajes que ayuden en su correcta utilización, además, deberá presentar todos los mensajes de error en la terminología comprensible para el usuario (Exception handling).

VIII. INFORMES Cada producto deberá ser acompañado por un informe que detalle las actividades realizadas, actas de reunión y otra información que se considere pertinente. Igualmente, deberán incluir el avance a nivel de la ruta crítica y los problemas acontecidos que pudieron dificultan el cumplimiento de los plazos. Deberá realizarse un análisis de los riesgos en cada una de las etapas.

IX. PLAZO

El plazo de contratación es de 07meses y se iniciará a partir de la fecha de



18

suscripción del contrato. X. CRONOGRAMA DE PAGOS

Los productos deberán presentar bajo el siguiente cronograma:

Producto Plazo Abono Producto 1 A los 07 días de firmado el contrato. 0% Producto 2 A los 45 días de firmado el contrato. 10% Producto 3 A los 75 días de firmado el contrato. 20% Producto 4 A los 105 días de firmado el contrato. 10% Producto 5 A los 135 días de firmado el contrato. 10% Producto 6 A los 157 días de firmado el contrato. 15% Producto 7 A los 180 días de firmado el contrato. 15% Producto 8 A los 210 días de firmado el contrato. 20%

Para la entrega de cada producto, se debe haber cumplido con la entrega del producto anterior. La aprobación de los productos estará a cargo de la Dirección General de Gestión de Usuarios (DGGU), la Coordinación General de la Unidad Central de Focalización (UCF)y la Oficina General de Tecnologías de la Información (OGTI) del MIDIS en base al cumplimiento de los aspectos técnicos y a la ejecución de los servicios.

XI. COORDINACIÓN Y SUPERVISIÓN

La consultoría será supervisada, coordinada y monitoreada por la Dirección General de Gestión de Usuarios (DGGU)y la Coordinación General de la Unidad Central de Focalización (UCF) en colaboración con la Oficina General de Tecnologías de la Información (OGTI) del MIDIS.

XII. GARANTÍA

El software, tendrá una garantía por fallas en su programación por un plazo de un año contados a partir del otorgamiento de la conformidad al último entregable. Las fallas que se presenten como parte de la garantía deberán ser resueltas en un plazo no mayor a 24 horas, dependiendo de su complejidad. Posteriormente a la entrega del último producto, como parte de la garantía, la empresa acompañará a la a la DGGU y a la UCF en la puesta en producción (en la ciudad de Lima) por un periodo de 180 días adicionales, a fin de garantizar la funcionalidad de los productos entregados.

XIII. PERFILES

1. Experiencia de la Empresa

a. Experiencia específica en desarrollo de aplicaciones web mínima de 5

años comprobable (deseable mínimo 02 años en el Sector Público).



19

b. Experiencia específica en Desarrollo de Aplicaciones con Oracle y Java, al menos haber realizado 03 proyectos de con estas plataformas (deseable en el sector público). Preferiblemente, proyectos que hayan contenido al menos 10 millones de registros y estar preparados para soportar una concurrencia mínima de 1000 usuarios.

c. Debe contar con experiencia en el desarrollo de al menos 2 proyectos de inteligencia de negocios (desde la concepción hasta la implementación).

d. Debe contar con experiencia empleando metodologías estándar para la gestión de proyectos de software. Podrá presentar metodologías propias siempre y cuando se basen en estándares comúnmente reconocidos.

e. El proveedor debe contar con un staff profesional con estudios superiores y certificados en temas relacionados a tecnologías de información, arquitectura de software y gestión de proyectos.

2. Formación académica del Equipo de trabajo Personal Clave:

‐ Un (1) Gerente o Jefe de Proyecto: Titulado en Ingeniería de Sistemas o

Informática o afines con certificación PMP con mínimo 5 años de experiencia en Gestión de Proyectos relacionados a sistemas de información, los últimos 3 años como gerente de proyecto, jefe de proyecto o líder de proyecto.

‐ Un (1) Analista de Proyectos: Titulado o bachiller en Ingeniería de Sistemas. Experiencia mínima de 03 años en proyectos de software.

‐ Un (1) Analistas de Calidad de Software:Titulado de Ingeniería de Sistemas

o Informática o afines, con 5 años de experiencia profesional en proyectos de mejora de procesos de negocio, análisis, desarrollo y QA de sistemas con un mínimo de 3 años cumpliendo un rol activo en el aseguramiento y control de calidad.

‐ Ocho(8) Analistas Desarrollador: Técnico o profesional en informática o

afinescon experiencia mínima de 04 años de experiencia en el desarrollo de soluciones tecnológicas basada en JAVA, ORACLE y SQLite.

Personal de primer nivel:

‐ Un (1) Administrador de Bases de Datos: Bachiller o Titulado en ingeniería

sistemas o afines con certificación en base de datos “ORACLE CERTIFICATION PROFESIONAL” con un mínimo de 05 años de experiencia en Bases de Datos Oracle, preferentemente, gestionando bases de datos con más de 10 millones de registros.

‐ Un (1) Arquitecto Software Senior: Profesional titulado en la especialidad de Ingeniería de Sistemas o afines. Experiencia mínima de 5 años en el



20

área de gestión de tecnologías de información realizando actividades relacionadas a la función de arquitectura empresariales, los últimos 2 años como arquitecto líder. Certificaciones referentes a arquitectura de sistemas y gestión de tecnologías de información.

‐ Un (1) Analista de Inteligencia de Negocios: Titulado o bachiller en

Ingeniería de Sistemas. Experiencia mínima de 03 años en desarrollo de proyectos de inteligencia de negocios.

‐ Un (1) Capacitador: técnico en sistemas o informática o afines, con más de 02 años de experiencia ejecutando planes de gestión del cambio y/o transformación de negocios por el uso de herramientas tecnológicas.

‐ Dos (2) Documentador: técnico en sistemas o informática o afines, con más

de 01 año de experiencia profesional en la documentación de procesos y/o etapas dentro del ciclo de vida de desarrollo de software.

Para todos los casos, se requiere adjuntar constancias y certificados respectivos que sustenten lo requerido y las consideraciones del anexo 5.

XIV. LUGAR DE SERVICIOS

Los servicios serán prestados en la ciudad de Lima - Perú y en las instalaciones del MIDIS como desde las instalaciones de la consultora. La consultora deberá facilitar los equipos de cómputo y servidores de base de datos de desarrollopara su equipo de profesionales, asimismoel MIDIS brindará acceso a sus servidores de bases de datos. Es de responsabilidad de la consultora el uso de licencias de los programas informáticos para el desarrollo e implementación de los productos (incluye, de corresponder, la licencia del gestor de políticas) Las licencias de base de datos Oracle y herramientas de Inteligencia de Negocios serán proporcionadas por el MIDIS.

XV. LICENCIAMIENTO

Toda documentación, programas fuentes, librerías, código de sentencias, documentos electrónicos, informes y otros componentes de código que se generen como parte del servicio serán de propiedad del Ministerio de Desarrollo e Inclusión Social.La información antes referida, para el caso de manuales será entregada impresa y en digital. Para la demás información solo en medio digital. En ambos casos se presentarán en original y 2 copias.

XVI. SOPORTE Y MANTENIMIENTO EXTERNO

Los aplicativos desarrollados debe contemplar mecanismos y acuerdos de mantenimiento del desarrollo de software por un periodo mínimo de 6 meses posteriores a la entrega del último producto, vencido el plazo y de no requerir el MIDIS el mantenimiento, este aspecto se dará por cumplido de ambas partes. Tal mecanismo debe permitir brindar seguridad del aplicativo y de la base de datos. Asimismo, de ser necesaria la actualización ante posibles errores o defectos ocultos



21

encontrados en su integración, se regirá por el plazo mínimo de un (01) año contado a partir de la conformidad otorgada por la Entidad.

XVII. CAPACITACIÓN

Se deben establecer las acciones bajo un plan de capacitación y entrenamiento para transferir los conocimientos necesarios y suficientes para que el personal de la Dirección General de Gestión de Usuarios y de la Unidad Central de Focalización, pueda administrar de manera óptima la base de datos y el aplicativo. Los costos de capacitación deben estar incluidos dentro de los montos estimados por la consultoría. Al menos deberá considerar 14personas capacitadas, con un mínimo de 24 horas en el local del MIDIS aplicable al producto final y deberá adjuntar toda la información técnica necesaria para dicha capacitación y entrenamiento. Capacitación técnica al personal que se encargará del mantenimiento posterior del sistema, a la DGGU y OGTI tiempo de capacitación no menor a 14 horas. Adicionalmente, el proveedor, deberá asistir a 3 talleres que organice el MIDIS a nivel nacional para la capacitación de los usuarios finales en el sistema que se construya. Los gastos de pasajes y viáticos correrán por cuenta del proveedor.

Por otro lado, el proveedor debe considerar una capacitación sobre el módulo del BI desarrollado, el cual deberá tener una duración de 30 horas como mínimo para 10 personas. El espacio físico para la capacitación estará a cargo de la consultora.



22

ANEXO 01

Consideraciones Generales en la Implementación del Sistema a. Características Generales: • Adecuación, el aplicativo debe ser amigable, rápido, en entorno Web. El aplicativo debe proporcionar las herramientas adecuadas para administrar variables y otros tipos de elementos representativos de cada programa social. • Exactitud, el aplicativo debe garantizar la exactitud de la información de salida y procesada, los cuales deben tener una correlación con los variables establecidos. • Interoperabilidad, el aplicativo debe ser capaz de interoperar a través de lenguajes XML o Servicios Web para intercambiar información con los sistemas transaccionales que defina el MIDIS, (Estar preparado para la arquitectura SOA) • Seguridad, el aplicativo debe brindar mecanismos de seguridad a todo nivel, considerando la administración de usuarios y accesos a todo nivel. Se debe considerar la encriptación de claves así como el registro de sucesos y transacciones. La aplicación debe considerar un módulo de seguridad para la gestión de usuarios internos y externos. • Madurez, el aplicativo debe ser estable para el buen desarrollo del trabajo de los usuarios. El aplicativo deberá evitar caídas por un manejo inadecuado de las funciones por parte del usuario o una, mala Interacción con el sistema operativo. • Tolerancia a errores, la posible aparición de errores debe ser controlada y manejada con mecanismos y avisos amigables y entendibles. No debe cerrar ninguna aplicación del software o dañarlo en casos extremos. La aparición de esos errores no debe dañar el funcionamiento del sistema operativo. • Recuperabilidad, de ocurrir una caída inesperada, la información registrada en el aplicativo debe permanecer intacta. No se aceptará perdida de información en ninguna condición. • Aprendizaje, el aplicativo debe proporcionar información necesaria y sencilla para entender el funcionamiento por parte del usuario MIDIS. El postor ganador debe proporcionar como mínimo un manual de usuario y un manual técnico para la administración adecuada para la aplicación del software. • Operatividad, el aplicativo deberá ser de fácil manejo y fácil configuración. El usuario MIDIS no debe necesitar tener grandes conocimientos en dicho aplicativo para poder manejarlo. • Comportamiento en Tiempos, el aplicativo debe realizar sus procesos internos de manera ágil, ligera y rápida sin afectar notablemente al rendimiento de la computadora o el servidor donde se encuentre alojado. • Utilización de recursos, bajo condiciones normales el aplicativo debe utilizar los recursos de computación definidos en sus especificaciones.



23

• Capacidad de ser analizado, el aplicativo debe proporcionar información a través de registros “log” de todas las transacciones o errores que puedan ocurrir. Esta información debe ser visualizada en un módulo de "administración de logs" con los accesos necesarios. • Estabilidad, las actualizaciones o parches del aplicativo no afectarán la estabilidad del aplicativo o el rendimiento del equipo. • Coexistencia, el aplicativo no debe generar conflictos técnicos con otras aplicaciones que se encuentre en el sistema operativo.



24

ANEXO 02

FICHA SOCIOECONOMICA UNICA (FSU)

(Ver archivo digital: FSU2013.pdf)



25

ANEXO 03

PROCESOS

1. MACRO PROCESO DE INTEGRACIÓN DEL PGH

1.

“Añ

PROCESO

“Decenioño de la Integra

O DE CARG

o de las Personación Nacional

GA DE DATO

nas con Discapy Reconocimie

OS

pacidad en el Pento de Nuestra

Perú” a Capacidad”

26



27

2. PROCESO DE CONSISTENCIA DE FSU

3.

“Añ

CÁLCULO


O DE LA CLA


ASIFICACIÓ


ÓN SOCIOE


ECONÓMICA


A

28



29

4. VALIDACIÓN DE IDENTIDAD

5.

“Añ

ACTUALIZ


ZACIÓN DE


EL PGH




30



31

ANEXO 04

METODOLOGIA DE DESARROLLO Y ENTREGABLES

(Ver archivo digital: METODOLOGIA DE DESARROLLO EXTERNOS.pdf)



32

ANEXO 05

ROLES Y RESPONSABILIDADES

Gerente o Jefe de Proyecto: Fase: Planificación

Representa la máxima responsabilidad en la gestión operativa de un proyecto, así como la autoridad de la coordinación de las actividades técnicas dentro del ámbito del mismo.

Comunicar al Equipo de Procesos el inicio de un proyecto y coordinar con él la definición de los procesos que el proyecto seguirá.

Definir el alcance del proyecto, establecer el cronograma de actividades (tanto de desarrollo como de control), definir y solicitar los recursos necesarios, identificar los supuestos y restricciones, y establecer la estrategia de entregas al cliente, ya sean proyectos nuevos, evolutivos o de mantenimiento.

Identificar y gestionar necesidades y actividades de entrenamiento necesarias para que los integrantes del equipo de proyecto puedan realizar las tareas asignadas. Solicitar la aprobación de las actividades de entrenamiento a la Gerencia.

Identificar de manera temprana, proactiva y rigurosa los riesgos asociados al proyecto, con la participación de todos los stakeholders identificados, definición y aplicación de las actividades de mitigación, asignar a los responsables y comunicar los riesgos identificados.

Seleccionar los entregables más críticos que requieran revisiones de pares y coordinar la realización de las revisiones de pares designadas

Planificar las actividades relacionadas al análisis de los requerimientos.Solicitar al cliente la relación de personas autorizadas para proporcionar requerimientos. Identificar los datos más importantes de las personas que forman parte del canal autorizado, además de indicar cuáles requieren de aprobación adicional.

Obtener la aprobación del cronograma del proyecto por parte de la Consultora, y luego del cliente.

Preparar el Project Charter del proyecto, solicitar su aprobación por parte de la Consultora y luego por parte del cliente.

Otros que correspondan a la gestión de proyectos. Fase: Análisis Funcional

Obtener la aprobación del Product Backlog inicial.



33

Fase: Desarrollo

Asegurar que en el proyecto se identifiquen defectos de manera temprana, haciendo seguimiento a los resultados de las revisiones de pares, pruebas unitarias y pruebas integrales.

Registrar las lecciones aprendidas de la ejecución del proceso de Diseño y Desarrollo.

Fase: Control de Proyecto

Gestionar los riesgos, identificar y gestionar problemas e informar el status del avance del proyecto. Actualizar las actividades del cronograma.Controlar el avance del proyecto utilizando métricas. Hacer seguimiento a las actividades del cronograma, acciones correctivas, acciones de mitigación de riesgos y planes externos, y reformular la planificación según sea necesario.Hacer seguimiento al esfuerzo del proyecto y realizar revisiones en hitos representativos del proyecto.Gestionar reuniones de avance con todos los involucrados del proyecto y hacer seguimiento al envío y recepción de encuestas al cliente, estableciendo acciones correctivas cuando sea necesario. Informar con la periodicidad establecida el status del proyecto a la Gerencia y al cliente.

Convocar al equipo de proyecto (y otros stakeholders) a una reunión, al finalizar el proyecto, para identificar y registrar lecciones aprendidas. Gestionar la validación de la estimación e identificar mejoras al procedimiento utilizado para calcularlo. Almacenar los documentos e información producida del proyecto.

Analista de Proyectos:

Evaluación de la funcionalidad del sistema propuesto para la , gestión de identidad, evaluación socioeconómica, y gestión de la actualización del PGH, desde un punto de vista de gestión del sistema, análisis de información y toma de decisiones

Análisis de las fuentes de información, variables y algoritmos para el cálculo socioeconómico, como parte de las funciones del sistema

Acompañamiento en la identificación y análisis de los procesos y sub-procesos Análisis de los productos a obtenerse como reportes del sistema

Fase: Análisis Funcional

Trabajar en forma conjunta con los usuarios, clientes, equipo de arquitectura y equipo de diseño del proyecto para identificar los requerimientos reales, entender los objetivos del negocio. El analista debe gestionar los requerimientos utilizando métricas para la medición, el seguimiento y control.

Identificar y traducir las necesidades del cliente en requerimientos asegurando que cumplan con criterios estándar definidos.

Codificar, registrar y priorizar los requerimientos de cliente. Elaborar las especificaciones de migración. Analizar los riesgos asociados a los requerimientos y establecer balance entre las

necesidades del cliente y las restricciones del proyecto.



34

Realizar correcciones a las observaciones encontradas en las Revisiones de Pares y en la revisión realizada por QA.

Fase: Diseño

Realizar el diseño Técnica de los módulos o componentes del sistema. Definir y establecer el entorno completo para soportar el desarrollo, integración y pruebas del sistema indicando hardware, software, frameworks, clases base, etc. Definir el procedimiento generación de ejecutables e instaladores, así como de la inclusión de la documentación de usuario.

Definir las interfaces que serán ofrecidas por el subsistema, módulo o componente diseñado y registrarlas en la Matriz de Interfaces del proyecto.

Fase: Desarrollo

Planificar y ejecutar las pruebas integrales. Fase: Soporte

Analizar el impacto de las solicitudes de cambio del proyecto Analizar los resultados de las métricas y toma de decisiones.

Arquitecto Software Senior:

Evaluar alternativas de diseño de arquitectura. Elaborar el modelo de datos del proyecto Preparar la especificación de despliegue.

Diseñar y especificar la arquitectura de aplicaciones (cliente y servicios), datos e infraestructura del proyecto.

Mantener actualizada la definición de las interfaces y la Matriz de Interfaces del proyecto.

Analista Desarrollador: Fase: Desarrollo

Ejecutar las actividades de codificación o programación del aplicativo y, realizar las pruebas unitarias para garantizar calidad en la codificación aplicando los estándares establecidos.

Realizar correcciones a las observaciones encontradas en las Revisiones de Pares

Integrar el código desarrollado en una instancia consolidada Participar en las revisiones de pares definidas por el Jefe de Proyecto.

Fase: Pruebas

Corrección de errores y ejecución de pruebas unitarias.

Fase: Soporte



35

Analizar el impacto de las solicitudes de cambio del proyecto. Analista de Inteligencia de Negocios: Fase: Análisis y Diseño

Planificar de tiempos y procesos. Identificar y definir las necesidades de información de los usuarios clave. Diseñar modelos de almacenamiento de información. Diseñar modelo de extracción, transformación y carga (ETL). Diseñar tableros de desempeño y control Diseñar modelos de análisis de información. Determinar las necesidades de plataforma y herramienta de inteligencia de

negocio. Fase: Desarrollo

Implementar modelo de almacenamiento de información Implementar modelo de extracción, transformación y carga (ETL). Implementar tableros de desempeño y control (dashboard) Implementar modelos de análisis de información.

Analista de Calidad de Software: El analista de calidad de software deberá estar presente en todo el ciclo de vida de desarrollo de software. Fase: Análisis y Diseño

Definir el enfoque general de pruebas, establecer las fases de pruebas, criterios de entrada y salida a cada una de éstas.

Determinar el alcance de las pruebas a realizar y establecer los criterios de aceptación.

Determinar características del ambiente de pruebas. Elaborar el Plan Maestro de Pruebas. Establecer el proceso de gestión de defectos. Brindar lineamientos para la generar reportes de resultados e indicadores.

Fase: Desarrollo

Participar en la elaboración de casos de prueba.

Fase: Pruebas

Realizar las pruebas funcionales, ejecutando los casos de prueba definidos Realizar seguimiento a la corrección de los defectos identificados. Participar del análisis de resultados de las pruebas

Fase: Soporte



36

Analizar el impacto de las solicitudes de cambio del proyecto. Gestión y validación de incidencias reportadas. Gestión y validación de requerimientos de mejora.

Administrador de Bases de Datos:

Fase: Desarrollo y Pruebas

Configurar el ambiente de Desarrollo y QA Ejecutar y consolidar scripts Asesorar y apoyar al equipo de desarrollo en temas relacionados a Bases de Datos.

Fase: Soporte

Gestionar backups a realizar y comunicar a Soporte Técnica. Informar resultados de los backups realizados

Capacitador:

Elaborar el taller de capacitación para el personal de TI del SISFOH. Dicho Taller será aprobado por la coordinación general del SISFOH.

Capacitar sobre las actividades desarrolladas en el proyecto, explicación de las consultas (scripts) utilizadas en el proyecto, desarrollo y estructura de los módulos del aplicativo.

Asistir a los talleres nacionales que realice la UCF con la finalidad de capacitar a los usuarios finales.

Documentador:

Elaborar el manual de técnico (arquitectura, BD, procesos, módulos) y de usuario, antes de la capacitación al personal de TI del SISFOH.



37

ANEXO 06

ESTRUCTURA DE DATOS DEL REGISTRO NACIONAL DE USUARIOS

ID_RNU Identificador de registro

ID_PPSS Código del Programa Social de acuerdo a la Tabla N°01 ‐ Programas Sociales y/o Subsidios del Estado

PERIODO Periodo correspondiente registro de usuarios

COD_CA Código del Centro de Afiliación al Programa Social (Código propio de cada Programa Social)

NOMB_CA Nombre del Centro de Afiliación al programa social (lugar donde se inscribio el usuario o donde recibe

regularmente el servicio según corresponda)

UBIGEO_CA (*) Código de ubicación geográfica del Centro de afiliación al programa social

ID_CP_CA (*) Código del Centro Poblado donde se encuentra el Centro de Afiliación

NOMB_CP_CA Nombre del Centro Poblado donde se encuentra el Centro de Afiliación

TIPO_CENTRO_ATENCION Tipos de centros de atencion de acuerdo a los tipos definidos en la Tabla N°07. Solo aplica para PCA y PVL.

CENTRO_ATENCION Nombre del centro de atencion. Solo aplica para PCA y PVL.

BIEN_SERVICIO

Tipo de bien o servicio repartido de acuerdo a los tipos definidos en la Tabla N°08. Solo aplica para PCA y

PVL.

UBIGEO_CE_AT (*) Código de ubicación geográfica del Centro de atencion (afiliación al programa social). Solo aplica para PCA y

PVL.

ID_CP_CE_AT (*) Código del Centro Poblado donde se encuentra el Centro de atencion (Afiliación). Solo aplica para PCA y

PVL.

NOMB_CP_CE_AT Nombre del Centro Poblado donde se encuentra el Centro de atencion (Afiliación). Solo aplica para PCA y

PVL.

II. DATOS DEL USUARIO

TIPO_DOI Tipo de documento de identidad con el que se afilió al usuario, de acuerdo a los tipos definidos en Tabla

N°03

NUM_DOI Número de documento de identidad del usuario

ID_USUARIO Código con el que identifica al usuario en el Programa Social

AP_PAT Apellido Paterno del Usuario

AP_MAT Apellido Materno del Usuario

NOMB Nombres del Usuario

SEXO Sexo del usuario para lo cual debe considerar: (1) Hombre , (2) Mujer

FEC_NAC Fecha de Nacimiento (DD‐MM‐AAAA)

UBIGEO (*) Código de ubicación geográfica del domicilio del usuario (6 dígitos)

DIRE_USU Dirección completa del usuario

TELEFONO Telefono fijo o celular del usuario

ID_CP_US (*) Código del Centro Poblado donde vive el usuario

NOMB_CP_US (*) Nombre del Centro Poblado donde vive el usuario

EST_CIV_USU Estado civil del usuario

FECH_AFIL Fecha en que se afilió al Programa Social (DD‐MM‐AAAA)

ESTADO_AFIL Estado de afiliación al momento del reporte , de acuerdo a los tipos definidos en la Tabla N°06

FECHA_DESAFI Fecha de desafiliación.Llenar en caso el campo ESTADO_AFIL sea 3,4 o 5.

TIENE_APO Debe indicar si el usuario tiene apoderado, de acuerdo a los tipos definidos en la Tabla N°05

TIPO_DOI_APO Tipo de documento de identidad con el que se afilió al usuario, se debe considerar el Tabla N°03

NUM_DOI_APO Documento de Identidad del Apoderado o Titular

AP_PAT_APO Apellido Paterno del Apoderado o Titular

AP_MAT_APO Apellido Materno del Apoderado o Titular

NOMB_APO Nombre del Apoderado o Titular

SEXO_APO Sexo del apoderado para lo cual debe considerar: (1) Hombre , (2) Mujer

FEC_NAC_APO Fecha de Nacimiento (DD‐MM‐AAAA)

DIRE_APO Dirección completa del apoderado

UBIGEO_APO Código de ubicación geográfica del domicilio del apoderado (6 dígitos)

RELA_USU Relación con el usuario

EST_CIV_APO Estado civil del apoderado

I. DATOS GENERALES DEL PROGRAMA SOCIAL

III. DATOS DEL APODERADO (Aplica para aquellos usuarios que se encuentran registrados en el programa a través de un apoderado o

titular)



38

IV. DATOS DEL SERVICIO

COMP_PROG Según la clasificación de cada programa Social se debera indicar el componente del programa social al cual

pertenece, de acuerdo a los tipos definidos en el Tabla N°02

ALCANCE_SERV El servicio puede estar orientado a: (1) Individuo, (2) Hogar

COD_LUGAR_REC_SERV Código del lugar en donde recibe el servicio

DESC_LUGAR_REC_SERV Descripción del lugar en donde recibe el servicio

MODALIDAD_TRANSF Se refiere a la modalidad de Transferencia, que puede ser (1) Flat (2) EAT. Aplica para PS Juntos.

FECHA_REPORTE Fecha en la que esta reportado la información (DD‐MM‐AAAA)

FECHA_SERVICIO Fecha en el cual recibio el servicio

MONTO_SERV_PER Aplica a aquellos programas que realizan transferencias de dinero. Monto transferido al usuario desde el

último periodo reportado hasta la fecha.



39

ANEXO 07

Manual de Reglas de Consistencia para el Registro Nacional de Usuarios del MIDIS

Noviembre de 2013

I. OBJETIVO. Establecer las reglas de consistencia que garantice la calidad de la información recolectada para el Registro Nacional de Usuarios, las cuales deben ser aplicadas por los Programas Sociales y/o Subsidios del Estado - PPSS y por la Dirección General de Gestión de Usuarios - DGGU.

II. BASE LEGAL. Ley N°29792, Ley de Creación, organización y funciones del Ministerio de

Desarrollo e Inclusión Social. Decreto Supremo N°011-2012-MIDIS, aprueba el Reglamento de Organización

y Funciones del Ministerio de Desarrollo e Inclusión Social – MIDIS. Resolución de Contraloría General N° 320 – 2006 – CG, aprueba las normas

de control interno de las entidades del Estado. Ley 29951, Articulo 24 de la Ley de Presupuesto del Sector Público para el año

Fiscal 2013.

III. ALCANCE. El presente manual es de uso obligatorio para: Los PPSS que son los encargados de reportar la información de los usuarios

para el Registro Nacional de Usuarios del MIDIS. La DGGU, que es el área encargada de implementar el Registro Nacional de

Usuarios, y por tanto, de velar que la información contenida cumpla con estándares de calidad y consistencia.

IV. DEFINICIÓN DEL PROCESO.

La Directiva de Lineamientos para el envío y recepción de información del Registro Nacional de Usuarios de Programas Sociales y/o Subsidios del Estado contempla el siguiente proceso:

V.

VI.

“Añ

El procesoPPSS quecon el fin señalado Reglas esp Por su parde la DGGcon ciertoRNU. Paraconsistenc RESPONS a. Los PP

y remestabl

b. En casen el APPSSque im

c. Los Porgani

REGLAS D a. Regla

Sin imeste, dse usa i. Cam


o 1.0 consid debe ser ende garantiz

en la Seccpecíficas) co

rte, el proceGU y que bus requisitosa ello debe cia (b. reglas

SABILIDADE

PSS son resitidos a la Decidos en elso los PPSSAnexo N°01 , deberán co

mpide cumplPSS podránización de lo

DE CONSIS

s generalesmportar el tipo

deberá quedarán valores

mpos de tip


Diagrama

dera la Genenviada a la Dzar la calidaión VI. Regontenidas en

eso 3.0 consusca que la

s para que tener en c

s específicas

ES.

sponsables DGGU del l presente mS no pueda- Relación d

omunicarlo air con lo señn solicitar a os datos que

STENCIA.

s o de dato dedar el campopor omisión

po fecha


a N°01 - Proc

eración de DGGU para ad de la inglas de conn este docum

sidera el Coa informaciónsean considuenta lo ses) contenida

de que los pMIDIS de a

manual. n cumplir code Campos a la DGGU

ñalado. la DGGU la

e deben rem

e cada campo respectivon.


ceso del RN

Informaciónla conforma

nformación, nsistencia (amento.

tejo de inforn que proviederados com

eñalado en ls en este do

padrones a sacuerdo con

on remitir ladel Registromediante of

a asistencia itirse al RNU

po, cuando no con valor n


U

que está aación del RNdebe tener

a. Reglas g

rmación queene de los mo datos vála Sección Vocumento.

su cargo sean las reglas

informacióno Nacional dficio indicand

técnica necU.

no exista infonulo (sin inf

a cargo de lNU. Para ello

en cuenta generales y

e está a carPPSS cumpálidos para VI. Reglas

an elaboradde validaci

n especificade Usuarios do los motiv

cesaria para

ormación paformación). N

40

los o y

lo b.

rgo pla

el de

os ón

da de

vos

la

ara No



41

Para el caso de los campos que contengan fechas, se utilizará una cadena de tres (3) números separados por barra diagonal “/”. Asimismo, deberá ajustarse a la estructura “DD/MM/AAAA”, donde las 2 primeras posiciones “DD” corresponden al día del mes, con número arábigo y llenando con un cero a la izquierda los días anteriores al día 10 de cada mes, “MM” al mes de año con número arábigo y llenando con un cero a la izquierda los meses anteriores a octubre y las 4 últimas posiciones “AAAA” corresponden al año expresado con 4 dígitos.

ii. Campos de tipo carácter. Los campos que contienen cadenas de caracteres sólo deberán contener mayúsculas. El carácter “Ñ” no deberá ser sustituido por ningún otro carácter. Como separador de palabras, sólo deberá existir un espacio en blanco y ningún espacio al principio o final del campo. Se debe evitar el uso de pipes “|” (ASCCI 124) ya que será utilizado como carácter delimitador de cadenas en los archivos de texto. Para los casos de cadenas con contenido numérico de longitud fija, deberá justificarse a la derecha y llenar de ceros los espacios nulos o vacíos a la izquierda.

iii. Campos que contienen Nombres y Apellidos. Debe considerarse las siguientes reglas: El primer apellido, el segundo apellido y el o los nombres de la persona

deben tomarse, en la medida de lo posible, textualmente del Documento Nacional de Identidad – DNI.

Debe omitirse los títulos académicos. Los textos deben considerarse en mayúsculas, sin incluir dígitos ni

caracteres especiales ni diagonales (/) y pipes (|). No deben contener acentos, y en caso de diéresis, ésta debe omitirse,

colocando el carácter que corresponda sin la diéresis, por ejemplo escribir u en lugar de ü.

En nombres y apellidos si el texto contiene uno o varios apóstrofes (‘), éste deberá capturarse en la posición asentada en el acta de nacimiento o en el documento probatorio.

Si la conjunción “Y”, separa el segundo apellido del primero, éste deberá capturarse en el campo del segundo apellido.

b. Reglas específicas.

i. Datos del Programa Social y/o Subsidios del Estado. ID_PPSS – Código del PPSS.

Regla de consistencia: Campo de llenado obligatorio. Debe contener una cadena de longitud igual a 4 caracteres y el código debe estar asignado a un PPSS según lo indica la Tabla N° 01 Programas Sociales y/o Subsidios del Estado.



42

Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

PERIODO – Periodo correspondiente registro de usuarios. Regla de consistencia: Campo de llenado obligatorio. Puede contener caracteres alfanuméricos hasta por un tamaño de 10. Acción: En caso exceda la longitud, sólo se tomarán los primeros 10 caracteres.

COD_CA – Código del Centro de afiliación al PPSS. Regla de consistencia: Campo de llenado opcional. Puede contener caracteres alfanuméricos hasta por un tamaño de 50. Acción: En caso exceda la longitud, sólo se tomarán los primeros 50 caracteres.

NOMB_CA - Nombre del Centro de Afiliación al PPSS. Regla de consistencia: Debe llenarse si en el campo COD_CA se ha registrado información. Puede contener caracteres alfanuméricos hasta por un tamaño de 300. Acción: En caso exceda la longitud, sólo se tomarán los primeros 300 caracteres.

UBIGEO_CA - Código de ubicación geográfica del Centro de afiliación al

PPSS. Regla de consistencia: Campo de llenado obligatorio. Debe estar codificado según el UBIGEO del INEI de 2010. La longitud es igual a 6 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

ID_CP_CA – Código del Centro Poblado en donde se ubica el Centro de Afiliación del PPSS. Regla de consistencia: Campo de llenado opcional. Debe estar codificado según el UBIGEO de Centros poblados del INEI de 2010. La longitud es igual a 4 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

NOMB_CP_CA – Nombre del Centro Poblado donde se encuentra el Centro de Afiliación. Regla de consistencia: Debe llenarse si en el campo ID_CP_CA se ha registrado información. La longitud es hasta 300 caracteres. Acción: En caso exceda la longitud, sólo se tomarán los primeros 300 caracteres.



43

TIPO_CENTRO_ATENCION – Tipos de centros de atención, de acuerdo a

la Tabla N°07. Regla de consistencia: Debe llenarse solo si el PPSS es PVL o PCA.. La longitud es hasta 02 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

CENTRO_ATENCION – Nombre del centro de atención Regla de consistencia: Debe llenarse solo si el PPSS es PVL o PCA... La longitud es hasta 100 caracteres. Acción: En caso exceda la longitud, sólo se tomarán los primeros 100 caracteres.

BIEN_SERVICIO – Tipo de bien repartido, de acuerdo a los tipos definidos en la Tabla N°08. Regla de consistencia: Debe llenarse solo si el PPSS es PCA o PVL. La longitud es hasta 100 caracteres. Acción: En caso exceda la longitud, sólo se tomarán los primeros 100 caracteres.

UBIGEO_CE_AT - Código de ubicación geográfica del Centro de afiliación al PPSS. Regla de consistencia: Campo de llenado obligatorio. Debe estar codificado según el UBIGEO del INEI de 2010. La longitud es igual a 6 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

ID_CP_CE_AT – Código del Centro Poblado en donde se ubica el Centro de Afiliación del PPSS. Regla de consistencia: Campo de llenado opcional. Debe estar codificado según el UBIGEO de Centros poblados del INEI de 2010. La longitud es igual a 4 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

NOMB_CP_CE_AT – Nombre del Centro Poblado donde se encuentra el Centro de Afiliación. Regla de consistencia: Debe llenarse si en el campo ID_CP_CE_AT se ha registrado información. La longitud es hasta 300 caracteres. Acción: En caso exceda la longitud, sólo se tomarán los primeros 300 caracteres.



44

ii. Datos del Usuario. TIPO_DOI – Tipo de Documento de Identidad.

Regla de consistencia: Campo de llenado obligatorio. Debe contener una cadena de longitud igual a 1 y los valores posibles se encuentran entre 1 y 5 según los tipos de identidad definidos en la Tabla N°03 - Tipo de documentos de identidad. Acción: En caso no cumpla la regla, no se realizara la carga del registro de información.

NUM_DOI - Número de documento de identidad del usuario. Regla de consistencia: Campo de llenado opcional para el caso en que el tipo de documento sea igual a 5, en tal sentido deberá consignar información si en el campo TIPO_DOI se ha registrado los valores 1, 2, 3 o 4. En caso de (1) DNI la longitud de contenido del campo debe ser igual a 8 numéricos, mientras que para el caso de (2) Carné de Extranjería, (3) Partida de Nacimiento y (4) Otro la longitud del contenido del campo no debe exceder de 20 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

ID_USUARIO - Código con el que identifica al usuario en el PPSS. Regla de consistencia: Campo de llenado opcional. Puede contener valores alfanuméricos hasta por un tamaño de 50 caracteres. Acción: En caso exceda la longitud, sólo se tomarán los primeros 50 caracteres.

AP_PAT - Apellido Paterno del Usuario. Regla de consistencia: Campo de llenado obligatorio. Puede contener valores alfanuméricos hasta por un tamaño de 100 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

AP_MAT - Apellido Materno del Usuario. Regla de consistencia: Campo de llenado obligatorio. Puede contener valores alfanuméricos hasta por un tamaño de 100 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

NOMB - Nombres del Usuario. Regla de consistencia: Campo de llenado obligatorio. Puede contener valores alfanuméricos hasta por un tamaño de 100 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.



45

SEXO – Sexo del Usuario.

Regla de consistencia: Campo de llenado obligatorio. Debe contener una cadena de longitud igual a 1 y los valores posibles son 1 o 2. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

FEC_NAC- Fecha de Nacimiento. Regla de consistencia: Campo de llenado opcional. Debe tener el formato de fecha DD/MM/AAAA, por tanto la cadena de longitud es igual a 10 caracteres. Se considerará fecha válida a aquellas que sean superiores a 01/01/1900 y menor que la fecha actual. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

UBIGEO - Código de ubicación geográfica del domicilio de la persona. Regla de consistencia: Campo de llenado obligatorio. Debe estar codificado según el UBIGEO del INEI de 2010. La longitud es igual a 6. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

DIRE_USU – Dirección completa del usuario Regla de consistencia: Campo de llenado opcional. Puede contener caracteres alfanuméricos hasta por un tamaño de 300. Acción: En caso no cumpla la regla, no se realizará la carga del dato contenida en el campo.

TELEFONO – Teléfono fijo o celular del usuario Regla de consistencia: Campo de llenado opcional. Puede contener caracteres alfanuméricos hasta por un tamaño de 50. Acción: En caso no cumpla la regla, no se realizará la carga del dato contenida en el campo.

ID_CP_US - Código del Centro Poblado donde vive el usuario.

Regla de consistencia: Campo de llenado opcional. Debe estar codificado según el UBIGEO de Centros poblados del INEI de 2010. La longitud es igual a 10 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

NOMB_CP_US – Nombre del Centro Poblado donde vive el usuario.



46

Regla de consistencia: Debe llenarse si en el campo ID_CP_US se ha registrado información. La longitud es hasta 300 caracteres. Acción: En caso exceda la longitud, sólo se tomarán los primeros 300 caracteres.

EST_CIV_USU – Estado civil del usuario. Regla de consistencia: Campo de llenado opcional. Debe contener una cadena de longitud igual a 1 caracter de acuerdo a la Tabla N°04 Tipo de estado civil. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

FECH_AFIL - Fecha de Afiliación. Regla de consistencia: Campo de llenado obligatorio. Debe tener el formato de fecha DD/MM/AAAA, por tanto la cadena de longitud es igual a 10 caracteres. Se considerará fecha válida a aquellas que sean superiores a 01/01/1985 y menor que la fecha actual. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

ESTADO_AFIL – Estado de afiliación al momento del reporte, de acuerdo a los tipos definidos en el Anexo 08. Regla de consistencia: Campo de llenado. Debe contener una cadena de longitud igual a 1. Acción: En caso exceda la longitud, sólo se tomarán los primeros 1 caracteres.

FECHA_DESAFI - Fecha de desafiliación del usuario. Regla de consistencia: Campo de llenado obligatorio si en el campo ESTADO_AFIL es igual a 3, 4 o 5. Debe tener el formato de fecha DD/MM/AAAA, por tanto la cadena de longitud es igual a 10 caracteres. Se considerará fecha válida a aquellas que sean superiores a la información del campo FECH_AFIL y menores o iguales a la FECHA_REPORTE. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

iii. Datos del Apoderado. TIENE_APO – Tiene apoderado el Usuario.

Regla de consistencia: Debe contener una cadena de longitud igual a 1 y los valores posibles puede ser (0) si el usuario no tiene apoderado y (1) si el usuario tiene apoderado.



47

Acción: En caso no cumpla la regla, no se realizará la carga de toda la sección de Datos del Apoderado.

TIPO_DOI_APO – Tipo de Documento de Identidad del Apoderado. Regla de consistencia: Debe contener una cadena de longitud igual a 1 y los valores posibles se encuentran entre 1 y 5 según los tipos de identidad definidos en la Tabla N°03 - Tipo de documentos de identidad. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

NUM_DOI_APO - Número de documento de identidad del apoderado. Regla de consistencia: Campo de llenado opcional para el caso en que el tipo de documento sea igual a 5, en tal sentido deberá consignar información si en el campo TIPO_DOI_APO se ha registrado los valores 1, 2, 3 o 4. En caso de (1) DNI la longitud de contenido del campo debe ser igual a 8 numéricos, mientras que para el caso de (2) Carné de Extranjería, (3) Partida de Nacimiento y (4) Otro la longitud del contenido del campo no debe exceder de 20 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

AP_PAT_APO - Apellido Paterno del Apoderado. Regla de consistencia: Campo de llenado obligatorio. Puede contener valores alfanuméricos hasta por un tamaño de 100 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

AP_MAT_APO - Apellido Materno del Apoderado. Regla de consistencia: Campo de llenado obligatorio. Puede contener valores alfanuméricos hasta por un tamaño de 100 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

NOMB_APO - Nombres del Apoderado. Regla de consistencia: Campo de llenado obligatorio. Puede contener valores alfanuméricos hasta por un tamaño de 100 caracteres. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

SEXO_APO – Sexo del apoderado. Regla de consistencia: Campo de llenado obligatorio. Debe contener una cadena de longitud igual a 1 y los valores posibles son 1 o 2.



48

Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

FEC_NAC_APO - Fecha de Nacimiento.

Regla de consistencia: Campo de llenado opcional. Debe tener el formato de fecha DD/MM/AAAA, por tanto la cadena de longitud es igual a 10 caracteres. Se considerará fecha válida a aquellas que sean superiores a 01/01/1900 y menor que la fecha actual. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

DIRE_APO – Dirección completa del apoderado

Regla de consistencia: Campo de llenado opcional. Puede contener caracteres alfanuméricos hasta por un tamaño de 300. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

UBIGEO_APO - Código de ubicación geográfica del domicilio del

apoderado. Regla de consistencia: Campo de llenado obligatorio. Debe estar codificado según el UBIGEO del INEI de 2010. La longitud es igual a 6. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

RELA_USU – Relación con el usuario. Regla de consistencia: Campo de llenado obligatorio. Debe contener una cadena de longitud igual a 1 carácter de acuerdo a la Tabla N°05 – Relación con el usuario. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

EST_CIV_APO – Estado civil del apoderado.

Regla de consistencia: Campo de llenado opcional. Debe contener una cadena de longitud igual a 1 caracter de acuerdo a la Tabla N°04 Tipo de Estado Civil. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

iv. Datos del servicio. COMP_PROG – Componente del PPSS al cual está inscrito el usuario.

Regla de consistencia: Campo de llenado obligatorio. Debe contener una cadena de longitud igual a 7 caracteres y de acuerdo a los componentes de PPSS definidos en la Tabla N°02 – Componentes del PPSS.



49

Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

ALCANCE_SERV – Debe especificar si el servicio brindado por el PPSS está orientado al (1) Individuo o al (2) Hogar. Regla de consistencia: Campo de llenado obligatorio. Debe contener una cadena de longitud igual a 1 y los valores posibles es 1 o 2. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

COD_LUGAR_REC_SERV – Se refiere al código del lugar en donde el usuario recibe el servicio. Regla de consistencia: Campo de llenado obligatorio para aquellos PPSS que brindan sus servicios en diferentes lugares geográficos. Puede contener caracteres alfanuméricos hasta por un tamaño de 20. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

DESC_LUGAR_REC_SERV – Se refiere a la descripción del lugar en

donde el usuario recibe el servicio. Regla de consistencia: Campo de llenado obligatorio para aquellos PPSS que brindan sus servicios en diferentes lugares geográficos. Puede contener caracteres alfanuméricos hasta por un tamaño de 300. Acción: En caso no cumpla la regla, no se realizará la carga de la información contenida en el campo.

MODALIDAD_TRANSF – Sólo aplica para el Programa Nacional de Apoyo

Directo a los Más Pobres JUNTOS. Se refiere a la modalidad de Transferencia, que puede ser (1) Flat (2) EAT. Regla de consistencia: Campo de llenado obligatorio. Debe contener una cadena de longitud igual a 1 y los valores posibles es 1 o 2. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

FECHA_REPORTE- Fecha en la que el PPSS ha generado la información

para el RNU. Regla de consistencia: Campo de llenado obligatorio. Debe tener el formato de fecha MM/AAAA, por tanto la cadena de longitud es igual a 7 caracteres. Se considerará fecha no válida si es mayor que la fecha actual. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

FECHA_SERVICIO- Fecha en el cual recibió el servicio.



50

Regla de consistencia: Campo de llenado obligatorio. Debe tener el formato de fecha DD/MM/AAAA, por tanto la cadena de longitud es igual a 10 caracteres. Se considerará fecha no válida si es mayor que la fecha actual. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

MONTO_SERV- Monto transferido al usuario producto del servicio brindado

por el PPSS. Aplica para aquellos PPSS que realizan transferencias económicas. Regla de consistencia: Campo de llenado obligatorio para aquellos PPSS que realizan transferencias monetarias. Debe contener un valor numérico y el punto “.” como separador decimal. Asimismo, se debe considerar el monto con 2 decimales. Acción: En caso no cumpla la regla, no se realizará la carga del registro de información.

VII. INDICADORES DEL PROCESO.

Con el objetivo de evaluar y monitorear el proceso de consistencia de información, se plantean los siguientes indicadores: Nombre: Porcentaje de registros válidos por PPSS.

Definición: Se refiere al porcentaje de registros que han cumplido las reglas de consistencia y que, por lo tanto, han sido incorporados en la base de datos del RNU. Forma de cálculo Nro. de registros cargados

Nro. de registros recibidos100

Unidad de medida Registros válidos Fuente de información Base de datos del RNU enviada por

cada PS Nombre: Porcentaje de datos válidos por PPSS.

Definición: Se refiere al porcentaje de datos contenido en cada campo que ha cumplido las reglas de consistencia y que, por lo tanto, han sido incorporados en la base de datos del RNU. Forma de cálculo Nro. de datos cargados

Nro. de datos recibidos100

Unidad de medida Datos válidos Fuente de información Base de datos del RNU enviada por

cada PS



51

ANEXO 08 Ficha del Registro de Programas Sociales

MÓDULO 1: INFORMACIÓN GENERAL DEL PROGRAMA SOCIAL

1 NOMBRE DE PROGRAMA SOCIAL

2 NORMA DE CREACIÓN DEL PROGRAMA SOCIAL (anote la referencia exacta para ubicarla en medios electrónicos)

3 DEFINA CUÁL ES EL OBJETIVO DEL PROGRAMA SOCIAL

4 DATOS DE CONTACTO

Cargo:

Nombre:

Teléfono/ anexo: Celular:Dirección:

Correo Electrónico:Persona de contacto para coordinaciones (Nombre y Cargo / Dirección u Oficina en la que labora)Cargo:

Nombre:

Teléfono/anexo: Celular:

Correo electrónico:

5 RESPONSABLES DE LA EJECUCIÓN:

Gobierno Nacional

Gobierno Regional

Gobierno Local

6 SECTOR: Solo puede marcar una alternativa

Agricultura 7 ENTIDAD:

Trabajo Unidad Ejecutora: N° / NombreSaludAmbienteComercio Exterior/TurismoCulturaEducaciónDefensa 8 ES PROGRAMA PRESUPUESTAL (PpR)Energía y Minas SiInterior NoJusticiaMujer y Poblaciones Vulnerables 9 ÁMBITO DE ACCIÓN Producción UrbanoPCM RuralDesarrollo e Inclusión SocialTransportes y ComunicacionesVivienda, Construcción y SaneamientoRelaciones Exteriores

10 ESCRIBA LA DEFINICIÓN DE ÁMBITO RURAL QUE USA EL PROGRAMA SOCIAL

11 EL PROGRAMA TIENE COMPONENTE(S) SiNo PASAR A 14

FICHA DE REGISTRO DE PROGRAMA SOCIAL Y/O PRESUPUESTAL (FRPS)

Nombre:

Nombre:



52

12 ¿CUÁNTOS COMPONENTES TIENE EL PROGRAMA SOCIAL?

MÓDULO 2: CARACTERÍSTICAS DEL PROGRAMA /COMPONENTE

13 NOMBRE DEL COMPONENTE DEL PROGRAMA

14 El PROGRAMA/COMPONENTE OPERA A NIVEL:

Puede marcar más de una alternativa

RegionalProvincialDistrital

Centro Poblado

15 ADJUNTAR EN CD, LA LISTA DE REGIONES, PROVINCIAS, DISTRITOS Y/O CCPP CON UBIGEO (INEI) DONDE OPERA EL PS

Si No

16

17

18 ¿El PS/componente cuenta con linea de base?

19

20 ¿El PS/componente cuenta con marco lógico?

21 ¿El PS/componente cuenta con organigrama?

22Solicitud ConcursalFicha ConcursalInscripción en MunicipalidadesConvocatoriaInscripción en equipos zonalesIntervención DirectaFicha de EmpadronamientoA solicitud de la poblaciónOtro: especifique

23 24

CuestionariosEntrevistasEncuestasSupervisiones de CampoSupervición AdministrativaFichas y registros de datosMatrices de seguimientoMonitoreo a través de un sistema de informaciónReuniones de coordinaciónInformes de consolidaciónOtro (especifique)

25 El Programa Social es:

Focalizado

No Focalizado

26 UTILIZA EL SISTEMA DE FOCALIZACIÓN DE HOGARES (SISFOH): SiNo

27 TIPO DE FOCALIZACIÓN (Marque lo(s) que corresponda):IndividualHogarGeográficaAutofocalización

Otro: especificar

28 SU PROGRAMA CONTRIBUYE A LA ESTRATEGIA "INCLUIR PARA CRECER" Si

Decreto Supremo Nº 008-2013-MIDIS No

29

Evaluación de sostenibilidadEvaluación DiagnósticaEvaluación desde la perspectiva del usuario

En caso que el programa social tuviera más de un componente, se tendá que llenar a partir del módulo 2 una Ficha por cadaComponente del Programa Social.

TIPO DE ACCESO AL PROGRAMA (Marque la(s) que corresponda)

Análisis de consistencia interna del proyectoEvaluación EconómicaEvaluación de Viabilidad

¿El PS/componente cuenta con padron de usuarios?

¿El PS/componente cuenta con ficha de empadronamiento

Focalización: Es el conjunto de reglas e instrumentos que permiten identificar a personas o grupos poblacionales en situación de pobreza o exclusión, como potenciales usuarios (beneficiarios). A partir de dicha información, los programas sociales pueden programar sus intervenciones.

Ninguna de las anterioresEje 5: Protección de la tercera edad (65 años a más)Eje 4: Inclusión Económica (19 - 64 años)

MonitoreoEvaluación de los resultadosEvaluación de impactoOtros (especifíque)

Eje 3: Desarrollo Integral de la Niñez y la Adolescencia (6 - 17 años)Eje 2: Desarrollo infantil temprano (0-5 años)Eje 1: Nutrición infantil (0-3 años)

CONTRIBUCIÓN DEL PROGRAMA SOCIAL/COMPONENTE A LA ESTRATEGIA INCLUIR PARA CRECER DEL MIDIS:(puede marcar más de una)

MECANISMOS DE MONITOREO (Marque la(s) que corresponda, si no realiza monitoreo no marque)

MECANISMOS DE EVALUACIÓN (Marque laos) que correspondan, si no realiza evaluación no marque)

¿El PS/componente lleva un registro nominal de sus usuarios con dni?



53

MÓDULO 2: CARACTERISTICAS DEL PROGRAMA / COMPONENTE

(Marque las alternativas que considere)

30 LINEA DE ACCIÓN: 33 EL PS/COMPONENTE ESTA DIRIGIDO A: Transferencias monetarias Marque la(s) opciones que correspondanTransferencias de alimentos y/o otras especies HombresSubsidios de precios o tarifas reducidas MujeresSalud AmbosNutrición

Actividad física y/o recreativa

34

Ciencia y tecnología Educación inicialCultura Educación primariaEducación Educación secundariaCuidado Gestantes o embarazadasAcceso al crédito y microcrédito Jefes de hogarCapacitación / Asistencia técnica Grupos étnicosEmprendimiento y/o autoempleo AfrodescendientesEmpleo AymarasDesastres naturales QuechuasTerrorismo, violencia interna Otros gruposProducción y sectores productivos (fomento productivo) DiscapacitadosFormalización y regularización de tierras y/o predios urbanos Adultos mayores Manejo de Recursos naturales Problema de saludVivienda y/o saneamiento Enfermades especiales (especifique)Construcción de infraestructura TBC, Sida,Transportes y comunicaciones (caminos, etc) Otras (especificar)Electrificación rural Adicción a alcochol y/o drogasFortalecimiento de organizaciones comunitarias Personas en situación de calleParticipación y organización ciudadana Zona rural o aislamiento territorialSeguridad ciudadana Microempresario/trabajadorAlcohol/drogas Trabajador dependienteJurídico Desempleado o inactivoPensiones Vulneración de derechosMedio ambiente PobrezaOtro: especificar Pobreza extrema

Privados de libertad o en procesoPensionadosSin pensiónSin seguro de saludCarencia habitacionalSectores productivos deprimidosVíctimas de violencia internaSin condición específicaOtro: (especificar)

31 CICLO DE VIDA (edad): Anote el/los rango(s) de edad que atiende el programa o componenteAnote tantos grupos como el PS/componente atienda

De_____________años a _____________años

De_____________años a _____________años

De_____________años a _____________años

De ____________años a más

Otro: (especificar)

32 CRITERIOS DE EGRESO, SALIDA O DESAFILIACIÓN DEL USUARIOExplique los criterios de egreso, salida o desafiliación del usuario que utiliza en PPSS

CRITERIOS DE ELEGIBILIDAD ADICIONALES A EDAD Y SEXO



54

MÓDULO 2: CARACTERÍSTICAS DEL PROGRAMA/ COMPONENTE

(Marque las alternativas que considere)

35 EL TIPO DE PRESTACION DEL PS/COMPONENTE ES:

Característica general del programa social o componente.

Individual

Colectivo

36 TIPO DE PRESTACIONES (SERVICIO O BENEFICIO):

Características especifícas del programa social o componenteBienes: Financiamiento de proyectos y actividades

de consumo Financiamiento de proyectosde capital físicoinmuebles Fomento productivodocumentos y certificados Monetarioinsumos educativos Dinero para uso específicoinsumos médicos Dinero de libre disposicióninsumos productivos Saludotros insumos (especificar) Atención médica

Asistencia técnica/Capacitaciones, cursos, charlas MedicinasAprestamiento laboral Exámenes médicosCapacitación en oficios Rehabilitación

Capacitación técnico profesional Servicios básicosCursos, charlas, talleres Seguridad pública

Créditos y servicios financieros Servicio de alimentaciónCrédito educativo Servicio de telecomunicacionesCrédito productivo Servicio de transporteSeguros y otros Servicio residencial

Empleo e intermediación laboral Servicios básicos (agua, luz, gas)Intermediación laboralPuesto de trabajo

Apoyo psicosocialAsesorías técnicasEn fomento productivoEn proyectos de inversiónJudicial y legal

Financiamiento de educaciónBecasServicio educativoEducación inicial

Otro: (especificar)

Beneficios individuales: Son beneficios individuales los bienes o servicios que tienen por usuario directo a una persona u hogar.Beneficios colectivos Son beneficios colectivos los bienes o servicios que se entregan directamente a una comunidad o unidad geográfica, y de los cuales no es posible excluir a una persona u hogar si se encuentran en el ámbito intervenido

Descripción del Servicio SISTEMA INTEGRADO DE … · Descripción del Servicio SISTEMA INTEGRADO...

Documents

Transcript of Descripción del Servicio SISTEMA INTEGRADO DE … · Descripción del Servicio SISTEMA INTEGRADO...