1.Introducción
ChildFund International es una organización humanitaria global cuya misión es promover el bienestar y el desarrollo de los niños en situaciones vulnerables. Desde su fundación en 1938, nuestro trabajo se ha adaptado a los constantes cambios del mundo, manteniéndonos fieles a nuestro compromiso de crear impactos positivos y duraderos en la vida de los niños, sus familias y comunidades.
Nuestro trabajo comenzó con acciones de apoyo a los niños de China afectados por la Segunda Guerra Sino-japonesa, a través de programas de patrocinio. A lo largo de los años, hemos mejorado nuestro modelo de acción, pasando de un enfoque centrado en los orfanatos a una estrategia integrada que combate las causas estructurales de la pobreza, situando siempre a las niñas y los niños en el centro de nuestras acciones.
A lo largo de las décadas, hemos reforzado el desarrollo dirigido a nivel local, reconociendo que las soluciones más eficaces y sostenibles nacen en las propias comunidades. También hemos mejorado nuestra respuesta de emergencia, creando espacios seguros donde las niñas y niños pueden recuperarse, jugar y aprender tras vivir situaciones de crisis o catástrofes.
En 2002 formamos la Alianza ChildFund, una red de organizaciones comprometidas a ampliar nuestro impacto global y acelerar la consecución de nuestros objetivos. Desde entonces, hemos ampliado nuestro enfoque a la protección integral de la infancia, especialmente en la lucha contra la violencia, ya sea en el entorno físico, familiar, escolar o digital.
Hoy, frente a retos crecientes como el cambio climático, la desigualdad, la explotación en línea y los conflictos, mantenemos nuestro compromiso de reforzar nuestras conexiones, alianzas e innovaciones. Nuestro objetivo es claro: influir positivamente en la vida de 100 millones de niñas, niños y sus familias para 2030, garantizando que crezcan sanos, seguros, educados y con acceso a las oportunidades que necesitan para desarrollar todo su potencial.
ChildFund, en su trabajo en las Américas, busca continuamente mejorar sus procesos operativos y fortalecer la comunicación y colaboración con sus sociales locales. Actualmente, la gestión del flujo de información relacionada con los niños patrocinados y las solicitudes de cartas se realiza de forma descentralizada, con procesos que varían entre países, lo que genera desafíos operativos, falta de
estandarización, aumento del tiempo de ejecución y riesgo de inconsistencias de datos.
Ante este escenario, identificamos la necesidad de desarrollar una aplicación que facilitará y optimizará la transferencia de información entre nuestro CRM (Salesforce), nuestros Socios Locales y el sistema interno de traducción denominado LTE. Este nuevo sistema actuará como un intermediario digital que automatiza, organiza y controla este flujo de datos de forma segura, eficiente y estandarizada.
El funcionamiento previsto de la aplicación incluye el siguiente flujo operativo:
•Salesforce CRM proporcionará los datos relativos a los participantes (niños, adolescentes y jóvenes) afiliados y las solicitudes de cartas realizadas.
•Esta información se enviará automáticamente al nuevo sistema, que se encargará de generar notificaciones a los socios locales informándoles de las solicitudes pendientes.
•A continuación, los socios locales cargarán los archivos correspondientes (cartas en formato PDF) directamente en la aplicación.
•El sistema realizará comprobaciones automáticas de estos archivos/documentos, asegurándose de que cumplen los parámetros y requisitos establecidos (como el formato, la integridad de los datos y otros criterios por definir).
•Una vez validados, los ficheros estarán disponibles para ser cargados en el sistema de traducción LTE, finalizando así el ciclo estándar de tramitación.
•Si alguna carta es rechazada o devuelta por el sistema de traducción LTE (debido a problemas de calidad, errores de contenido o cualquier otra razón), el nuevo sistema debe generar una notificación automática al socio local, solicitando que se prepare y envíe una nueva carta, reiniciando así el flujo para ese elemento específico.
Este proyecto pretende no sólo mejorar los procesos internos, sino también normalizar las operaciones entre las distintas oficinas e interlocutores sociales de los países de América, promoviendo un mayor control, trazabilidad y una comunicación más rápida.
2.Objetivos del provecto
•Automatizar el flujo de información entre Salesforce, los socios locales y el sistema de traducción LTE.
•Reducir significativamente el tiempo de tramitación de las solicitudes de cartas.
•Eliminar los procesos manuales y reducir los errores operativos.
•Estandarizar la ejecución de este proceso en los países de las Américas en los que operamos.
•Garantizar la seguridad, trazabilidad y conformidad en la gestión de datos y archivos.
3.Justificación de la necesidad de la solicitud
Actualmente, la falta de un sistema unificado para este proceso conduce a operaciones heterogéneas, con variaciones en los procedimientos entre países, aumento de los tiempos de respuesta, riesgos de retrabajo e inconsistencias en las entregas. La implantación de esta aplicación supone un avance significativo en la transformación digital de la organización, alineando los procesos locales con las mejores prácticas operativas, además de reforzar la calidad del servicio prestado a los niños y comunidades atendidas.
4.Ámbito geográfico y multilingüe
La aplicación debe servir a las oficinas y a los interlocutores sociales ubicados en los distintos países de las Américas (Honduras, Guatemala, Ecuador, Brasil y Bolivia), garantizando un soporte multilingüe, con interfaces y comunicaciones disponibles en inglés, español y portugués. Además, debe cumplir con la legislación local aplicable, incluyendo, entre otras, las leyes de protección de datos, privacidad y seguridad de la información en cada país de operación.
5.Objetivo del requerimiento
El objetivo de estos Términos de Referencia es establecer los requerimientos técnicos, funcionales y operativos para el desarrollo de una aplicación que optimice y estandarice el flujo de información entre ChildFund, sus aliados sociales locales, su Prestador de Servicios Multipaís y los sistemas internos Salesforce y el sistema de traducción LTE. Esta aplicación deberá proporcionar mayor eficiencia operativa, seguridad de la información, estandarización de procesos en las diferentes áreas de operación de los países mencionados y, al mismo tiempo, estar preparada para recibir continuas mejoras, adaptaciones y evolución tecnológica de manera ágil y sostenible.
Además de definir los requisitos de la aplicación, este documento pretende:
•Especificar los criterios de contratación de los proveedores, incluidos los aspectos técnicos, operativos, éticos y jurídicos.
•Orientar a los licitadores sobre los parámetros de preparación y presentación de las propuestas técnicas y económicas, garantizando claridad, transparencia y equidad en el proceso de selección.
El desarrollo de la aplicación debe guiarse por una arquitectura escalable que permita futuros mantenimientos, actualizaciones e incrementos, tanto en términos de funcionalidad como de adaptación a los nuevos requisitos operativos y tecnológicos que puedan surgir.
6.Compromisos éticos e institucionales
De acuerdo con los principios y políticas de ChildFund, los proveedores interesados deben cumplir los siguientes compromisos:
•Conflicto de intereses: Todos los solicitantes deben declarar formalmente si tienen algún vínculo directo o indirecto con colaboradores, empresas asociadas, organizaciones sociales asociadas o beneficiarios de los programas y proyectos de ChildFund. En caso de duda sobre la existencia o configuración de un conflicto de intereses, el solicitante deberá solicitar aclaraciones directamente a ChildFund antes de presentar la propuesta. La omisión de esta información puede dar lugar a la descalificación de la propuesta.
•Política de protección de la infancia: ChildFund cuenta con una sólida política corporativa de protección de la infancia, que debe ser cumplida íntegramente por cualquier persona física o jurídica que establezca una relación comercial, contractual o de servicios con la organización. El incumplimiento de esta política es motivo de rescisión inmediata del contrato, además de las implicaciones legales aplicables. Todos los profesionales implicados en el proyecto deben leer, comprender, firmar y comprometerse formalmente con la política de protección de la infancia.
•Diversidad, equidad e inclusión: ChildFund es una organización comprometida con la promoción de la diversidad, la equidad y la inclusión en todos sus procesos y relaciones. Buscamos proveedores que compartan estos principios y estén alineados con nuestro compromiso de garantizar que en nuestras actividades estén representadas diferentes perspectivas, con especial atención a la promoción de oportunidades para grupos históricamente marginados.
•Política antifraude y de integridad: ChildFund mantiene una política de tolerancia cero frente al fraude, la corrupción y las prácticas poco
éticas. Cualquier sospecha o constatación de actos ilícitos, deshonestos o que pongan en riesgo la integridad de la organización será investigada con prontitud y podrá dar lugar a sanciones legales, administrativas y contractuales, incluida la rescisión inmediata del contrato.
•Código de conducta, ética empresarial y política de denuncia de irregularidades: Los proveedores deben adherirse a los principios del Código de Conducta y Ética de ChildFund, así como conocer y respetar nuestra política de denuncia de irregularidades. Existen canales seguros y confidenciales para denunciar cualquier conducta que infrinja las políticas institucionales, la ética o la legislación vigente.
7.Presentación de propuestas
Las propuestas, que incluirán los aspectos técnicos y económicos, deberán enviarse antes del 30 de junio de 2025 a las siguientes direcciones de correo electrónico:
•[email protected]
•[email protected]
Las propuestas deberán contener todos los documentos e información necesarios, respetando estrictamente las condiciones, criterios y compromisos descritos en el presente pliego de condiciones.
8.Resumen del proyecto
Nombre del proyecto: Aún sin definir.
El nombre se desarrollará a lo largo del proyecto, en consonancia con la identidad institucional de ChildFund y con la participación de las principales partes interesadas.
Visión general de la aplicación:
El desarrollo de esta aplicación tiene como objetivo resolver un problema recurrente y crítico en el proceso operativo de ChildFund: la falta de estandarización y eficiencia en la transferencia y gestión de la información relacionada con el intercambio de cartas entre los niños patrocinados y los socios locales en los diferentes países donde operamos en las Américas.
En la actualidad, cada país lleva a cabo este proceso de forma diferente, algunas veces de forma manual, lo que provoca ineficacias, repeticiones, retrasos y dificultades para consolidar y rastrear la información.
La aplicación se encargará de conectar de forma segura y estructurada los sistemas internos de ChildFund, concretamente el CRM Salesforce (donde se encuentran los datos de los niños y las solicitudes de cartas ) y el sistema de traducción LTE (donde se almacenan los archivos de las cartas), así como de proporcionar una interfaz intuitiva para que los socios locales puedan recibir las solicitudes, enviar los archivos necesarios y seguir todo el flujo con transparencia y agilidad.
De esta forma, la aplicación:
•Normalizará el flujo operativo de la comunicación por carta en todos los países implicados;
•Reducirá el tiempo de funcionamiento y el riesgo de averías;
•Aumentará la trazabilidad, el control de calidad y la fiabilidad del proceso;
•Garantizará una experiencia más eficaz tanto para los empleados internos, los socios locales y el prestador de servicios multipaís.
¿Quiénes son los usuarios?
La aplicación será utilizada por tres perfiles de usuario principales, con distintos niveles de permiso y acceso:
1.Administrador:
•Perfil con acceso completo al sistema, incluida la gestión de usuarios, la parametrización de reglas, la supervisión de todo el flujo operativo, la generación de informes y las intervenciones técnicas cuando sea necesario.
2.Usuario interno - ChildFund:
•Perfil para empleados de ChildFund. Tendrá acceso a las funcionalidades necesarias para el seguimiento de los procesos, la supervisión de los flujos, la comprobación de la información y la gestión de las demandas internas relacionadas con las cartas.
3.Usuario - Socios locales:
•Perfil destinado a las organizaciones sociales locales asociadas. Tendrán acceso a solicitar cartas, cargar documentos (en formato PDF), supervisar
el estado de las presentaciones, recibir notificaciones, incluso en los casos en que las cartas sean devueltas por el sistema de traducción LTE, requiriendo la creación de una nueva carta.
9.Contexto operativo:
La aplicación debe desarrollarse teniendo en cuenta un entorno operativo complejo, que abarque múltiples países y características específicas, entre ellas:
•Ámbito geográfico: El sistema servirá inicialmente a los siguientes países: Brasil, Bolivia, Honduras, Ecuador, Guatemala y México, y podrá ampliarse a otros lugares en el futuro.
•Multiplataforma: Debe ser accesible a través de un navegador web responsive, compatible con los principales navegadores y dispositivos modernos (ordenadores, tabletas y smartphones). Opcionalmente, podría valorarse la viabilidad de desarrollar versiones móviles (iOS y Android), en función de la evolución del proyecto.
•Zonas horarias: Debe contemplar el funcionamiento en múltiples zonas horarias, con un adecuado registro de logs, notificaciones y flujos, asegurando la correcta trazabilidad de los eventos, independientemente de donde se haya originado el acceso.
•Idiomas: El sistema debe estar preparado, desde su concepción, para un funcionamiento multilingüe, con soporte mínimo para los siguientes idiomas:
•Portugués
•Español
•Inglés
Debería existir la posibilidad de ampliarlo a otras lenguas en el futuro, si fuera necesario.
10.Alcance de los servicios
Principales funciones previstas
La aplicación debe incluir al menos las siguientes funcionalidades:
•Gestionar la transferencia de información entre CRM Salesforce, los socios locales y el sistema LTE, garantizando la integridad de los datos y la trazabilidad.
•Control total del flujo de cartas, desde la solicitud hasta la entrega de expedientes validados en el sistema LTE.
•Mecanismo de notificación automática para los socios locales, informándoles de nuevas demandas, asuntos pendientes o devoluciones de expedientes, incluso cuando una carta rechazada debe ser sustituida o corregida en el sistema de traducción LTE.
•Carga y almacenamiento de archivos (PDF) vinculados a las solicitudes, con control de versiones y trazabilidad.
•Validación y comprobación de archivos, según criterios predefinidos, antes de la integración final con el sistema de traducción LTE.
•Gestión de usuarios y permisos, permitiendo diferentes perfiles (administrador, colaborador interno y socio local), con acceso controlado a funcionalidades según su rol.
•Cuadro de mandos para supervisar el estado de las solicitudes, los asuntos pendientes, el estatus de cada pieza, el historial y los informes de gestión.
•Historial completo y trazabilidad de las interacciones, garantizando la transparencia de todo el proceso.
11.Plataformas
El desarrollo se centrará inicialmente en la versión web, accesible mediante navegadores modernos, garantizando la compatibilidad con los principales sistemas operativos (Windows, MacOS, Linux) y dispositivos (ordenadores de sobremesa y tabletas).
La posibilidad de un futuro desarrollo para aplicaciones móviles (iOS y Android) podría considerarse una mejora o ampliación, pero no forma parte del alcance inicial.
12.Integraciones necesarias
El sistema debe poder integrarse de forma segura y eficaz con los siguientes sistemas:
•CRM Salesforce:
Consumo de datos sobre niños y solicitudes de cartas.
La integración se realizará a través de la API REST u otros medios compatibles con Salesforce.
•Sistema LTE:
Envío de los ficheros de cartas validadas y aceptadas al LTE.
Integración preferida mediante API. Alternativamente, se puede utilizar la integración mediante la exportación e importación de archivos en formato Excel u otro estándar aceptado.
El proveedor debe estar preparado para sugerir y proponer la mejor solución técnica de integración, teniendo en cuenta el rendimiento, la seguridad y la simplificación del mantenimiento.
13.Soporte multilingüe
El sistema debe tener una arquitectura preparada para el soporte multilingüe, que permita el uso de al menos las siguientes lenguas:
•Portugués
•Español
•Inglés
La solución debe permitir una fácil ampliación a otras lenguas en el futuro, con una separación adecuada de los archivos de traducción y una interfaz adaptable.
14.Accesibilidad
Al principio no será necesario cumplir estrictamente las normas internacionales de accesibilidad (como WCAG, ADA o equivalentes). Sin embargo, el sistema debe ser al menos compatible con las funciones de accesibilidad nativas de sistemas operativos y navegadores, garantizando que los usuarios puedan utilizar funciones como lectores de pantalla, zoom, alto contraste, entre otras.
15.Cumplimiento legal
El sistema debe cumplir la principal legislación sobre protección de datos aplicable en los países en los que vaya a funcionar, incluida, entre otras, la siguiente:
•Ley General de Protección de Datos (LGPD) - Brasil
•Reglamento General de Protección de Datos (RGPD) - Unión Europea (aplicable en casos de relaciones con socios europeos o de tratamiento de datos personales sensibles)
•Leyes locales de protección de datos en los demás países implicados (Bolivia, México, Honduras, Ecuador y Guatemala).
El proveedor debe garantizar que los datos personales se tratan de acuerdo con los principios de privacidad, seguridad, minimización, transparencia y control de acceso, de conformidad con cada jurisdicción.
16.Requisitos de ciberseguridad
El sistema debe desarrollarse teniendo en cuenta la seguridad de la información, incluyendo al menos los siguientes requisitos:
•Autenticación segura: uso de autenticación mediante contraseña segura, con posibilidad de integración futura con mecanismos de autenticación multifactor (MFA).
•Control de acceso: gestión estricta de perfiles, permisos y niveles de acceso.
•Cifrado: los datos sensibles viajan a través de HTTPS (TLS) y, en su caso, se almacenan de forma cifrada.
•Protección contra ataques comunes: prevención contra SQL Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) y otras vulnerabilidades conocidas.
•Registros de auditoría: un registro completo de la actividad de los usuarios en el sistema, que garantiza la trazabilidad y la posibilidad de realizar auditorías.
•Copia de seguridad y recuperación: estrategia definida para la copia de seguridad periódica de los datos, así como un plan de contingencia y recuperación en caso de fallos.
•Adhesión a buenas prácticas de desarrollo seguro, como las definidas por OWASP.
17.Requisitos funcionales
Características principales
El sistema debe incluir al menos los siguientes módulos y funcionalidades:
Gestión de usuarios
•Registro, edición, desactivación y gestión de usuarios.
•Control de los perfiles de acceso:
Administrador: acceso completo al sistema, incluida la parametrización, la gestión de usuarios, la supervisión y la generación de informes.
Colaborador interno (ChildFund): acceso restringido a las funcionalidades operativas necesarias para supervisar el flujo de cartas.
Socio local: acceso restringido a sus propias demandas y actividades, con la posibilidad de cargar archivos y ver notificaciones y asuntos pendientes.
18.Autenticación y seguridad
•Sistema de inicio de sesión seguro con contraseña.
•Posibilidad futura de implantar la autenticación multifactor (AMF).
•Recuperación de contraseñas por correo electrónico.
•Control de los intentos de acceso (bloqueo temporal tras X intentos incorrectos).
•Gestión de sesiones y cierre automático de sesión tras inactividad.
19.Panel de administración
•Visión general del estado de las solicitudes de cartas (abiertas, en curso, completadas, devueltas, pendientes).
•Gestión de los flujos operativos.
•Seguimiento de interacciones e historial de actividades.
•Gestión de integraciones (Salesforce y LTE).
•Control de notificaciones y alertas.
•Gestión lingüística de la plataforma.
20.Gestión de la demanda de cartas
•Recepción automática de demandas originadas en Salesforce.
•Distribución de las demandas a los socios locales mediante notificaciones.
•Zona para que los socios carguen cartas en PDF.
•Validación de los archivos cargados:
Comprobación del tamaño, el formato, la nomenclatura y los campos obligatorios.
Alertas sobre errores o no conformidades.
•Flujo de trabajo de aceptación:
Si se aprueba → Enviar a LTE.
Si falla (incluida la devolución a través de LTE) → Notificación automática al socio local para su corrección y reenvío.
•Historia completa de cada carta, desde su creación hasta la finalización del proceso.
21.Notificaciones
•Notificaciones automáticas para:
Nuevas demandas disponibles.
Pendiente de entrega.
Errores en los archivos cargados.
Vuelve por LTE.
Finalización del proceso.
•Canales previstos:
Correo electrónico (obligatorio).
Push Web (deseable para usuarios activos en la plataforma).
22.Informes y cuadros de mando
•Informes operativos, por ejemplo:
Número de demandas por país, socio, estatus y periodo.
Tasa de devolución.
Tiempo medio de tramitación.
•Informes administrativos y de resultados.
•Exporte informes en Excel o PDF.
•Visualización mediante cuadros de mando en la propia plataforma.
23.Historia y auditoría
•Registro completo de las actividades de cada usuario.
•Registros de:
Subidas.
Cambios de estado.
Interacciones en el sistema.
Notificaciones activadas.
•Acceso a los historiales por parte de los administradores.
24.Multilingüe
•Interfaz disponible en todos los idiomas:
Portugués.
Español.
Inglés.
•Posibilidad de ampliar a otras lenguas.
25.Integraciones
•Integración con:
Salesforce CRM: Recepción de datos de solicitudes.
Sistema LTE: Envío de archivos tras la validación y recepción de comentarios (aprobación o devolución).
•Las integraciones deberían realizarse preferiblemente a través de la API, pero debería ser posible realizar la integración a través de la carga/descarga de archivos (Excel, CSV) si la API no está disponible.
26.Normas empresariales
•Una carta sólo puede considerarse completa cuando
El socio local lo carga correctamente;
Pasar todas las validaciones definidas en el sistema;
Y es aceptado por el sistema de traducción LTE.
•Si el sistema LTE devuelve una carta, el sistema:
Genera automáticamente una notificación al interlocutor local;
La carta vuelve al estado "pendiente de corrección";
Sólo después de una nueva presentación válida se devolverá la carta al sistema de traducción LTE.
•El socio local sólo tendrá acceso a las demandas asignadas a su organización.
•El sistema debe garantizar que no se procese dos veces la misma carta.
•Todos los registros y cargas deben estar asociados a un número identificador único, tanto para el niño como para la solicitud, manteniendo una trazabilidad completa.
•El proceso de actualización y envío de datos debe tener en cuenta los husos horarios locales de cada país, garantizando la exactitud de plazos y estados.
•Las notificaciones automáticas deben producirse a horas configurables para cada país, respetando el horario comercial local.
27.Requisitos no funcionales
Rendimiento
•El sistema debe permitir la carga simultánea de varias cartas (archivos PDF) sin que el rendimiento se vea afectado.
•Tiempo medio de respuesta previsto para operaciones sencillas (como navegar entre páginas o ver datos) inferior a 3 segundos en condiciones normales de uso.
•La carga de lotes de archivos (cartas y perfiles) debe procesarse con eficacia, con mecanismos que eviten fallos y permitan la reanudación en caso de interrupciones.
Escalabilidad
•El sistema debe desarrollarse teniendo en cuenta la escalabilidad horizontal, es decir, la posibilidad de aumentar su capacidad de
procesamiento y almacenamiento a medida que crece el volumen de datos y el número de usuarios.
•Apoyo para futuras ampliaciones, ya sea aumentando los socios, incrementando la base de datos o añadiendo nuevos países.
Seguridad
•Aplicación de buenas prácticas de seguridad, entre ellas
Cifrado de datos en reposo y en tránsito (mínimo TLS 1.2).
Almacenamiento seguro de información sensible (como credenciales de acceso e identificadores personales).
Copias de seguridad periódicas de los datos, con almacenamiento en entornos seguros y posibilidad de recuperación en caso de fallo o pérdida.
Protecciones contra ataques comunes (SQL Injection, Cross-Site Scripting, Cross-Site Request Forgery, entre otros).
Autenticación mediante contraseña segura, con la posibilidad de activar la autenticación multifactor (MFA) en el futuro.
Control de acceso por perfiles y permisos.
28.Fiabilidad y disponibilidad (SLA)
•Disponibilidad mínima del sistema del 99%, teniendo en cuenta los periodos comerciales de los países atendidos.
•Aplicación de la supervisión de errores, fallos e incidentes.
•Plan de contingencia y recuperación en caso de catástrofe acorde con las buenas prácticas informáticas.
•Notificaciones a los administradores en caso de fallos críticos.
29.Compatibilidad
•El sistema debe ser una aplicación web responsive, compatible con los principales navegadores (Google Chrome, Microsoft Edge, Mozilla Firefox y Safari).
•Soporte garantizado para su uso en sistemas operativos:
Windows 10 y Windows 11.
•También es compatible con dispositivos móviles a través del navegador, lo que garantiza un acceso básico, aunque de momento no se trate de una aplicación móvil nativa.
30.Mantenibilidad
•La aplicación debe desarrollarse utilizando buenas prácticas de desarrollo de software que favorezcan:
Fácil de mantener, actualizar y corregir errores.
Arquitectura modular y escalable.
Documentación técnica completa (arquitectura, API, base de datos y manuales operativos).
•El código debe estar estructurado para permitir mejoras continuas y el desarrollo incremental de nuevas funcionalidades.
31.Usabilidad y diseño adaptable
•El sistema debe tener un diseño adaptable, que garantice una navegación fluida en diferentes tamaños de pantalla (ordenador de sobremesa, portátil y dispositivos móviles a través del navegador).
•Interfaz con un diseño limpio e intuitivo acorde con las mejores prácticas de experiencia de usuario (UX).
•Navegación sencilla y eficaz, incluso para usuarios poco familiarizados con la tecnología.
•Las pantallas y mensajes del sistema deben estar alineados con el idioma configurado por el usuario (portugués, español o inglés).
32.Entrega y calendario
El desarrollo del sistema se estructurará en fases, con entregas parciales que permitirán un seguimiento continuo, la validación de las etapas y los ajustes necesarios a lo largo del proyecto. Los hitos y plazos se muestran a continuación:
| Escenario | Descripción | Periodo | Plazo |
| 1. recopilación de requisitos y alineación técnica | Comprensión detallada de las necesidades, reglas de negocio, definición de la arquitectura y diseño del flujo operativo. | 07/07/2025 a 15/07/2025 | 15/07/2025 |
| 2. Diseño y creación de prototipos | Creación de wireframes, prototipos navegables y definición de la identidad visual de la aplicación. | 16/07/2025 a 25/07/2025 | 25/07/2025 |
| 3. Desarrollo de soluciones (Fase 1) | Desarrollo de los módulos principales, integraciones con Salesforce y LTE, funcionalidades básicas, registro, notificaciones y gestión de datos. | 26/07/2025 a 25/08/2025 | 25/08/2025 |
| 4. Pruebas funcionales y de integración | Validar flujos, probar integraciones, simular el uso, ajustar errores y realizar mejoras. | 26/08/2025 a 05/09/2025 | 05/09/2025 |
| 5. Homologación con el cliente | Validación del sistema por representantes de ChildFund y socios locales, con posibles ajustes finales. | 06/09/2025 a 12/09/2025 | 12/09/2025 |
| 6. Formación de usuarios | Formación de administradores, usuarios internos y socios locales en el uso del sistema | 13/09/2025 a 17/09/2025 | 17/09/2025 |
| 7. Despliegue y puesta en marcha | Publicación de la solución en un entorno productivo, entrega oficial y puesta en funcionamiento. | 18/09/2025 a 22/09/2025 | 22/09/2025 |
| 8. Periodo de estabilización y apoyo inicial | Corrección de cualquier error posterior a la implantación y apoyo continuo durante la estabilización. | 23/09/2025 a 30/09/2025 | 30/09/2025 |
Fecha límite para la entrega completa: 30 de septiembre de 2025
33.Criterios de evaluación de las propuestas
Las propuestas recibidas se evaluarán sobre la base de criterios técnicos, financieros, operativos y, en su caso, de sostenibilidad. La evaluación se llevará a cabo para garantizar la selección del proveedor que mejor satisfaga las necesidades de ChildFund, asegurando la calidad, el cumplimiento y la relación calidad-precio.
Criterios técnicos
•Experiencia previa en proyectos similares: Valoración de la experiencia demostrada del proveedor en el desarrollo de sistemas integrados con funcionalidades similares, especialmente en proyectos multilingües e internacionales.
•Calidad de la propuesta técnica: Análisis detallado del plan de trabajo, metodología propuesta, arquitectura del sistema, soluciones de seguridad y escalabilidad, así como cumplimiento de los requisitos funcionales y no funcionales.
•Capacidad de atención multilingüe e internacional: Verificación de la capacidad técnica para desarrollar y apoyar el sistema en múltiples idiomas (portugués, español, inglés) y considerar aspectos de legislación y uso en diferentes países de las Américas.
Criterios financieros
•Valor total de la propuesta: Análisis del coste global del proyecto, teniendo en cuenta el presupuesto disponible.
•Desglose de costes por fase y/o servicio: Evaluación de la transparencia y el detalle financiero, con una separación clara de los importes referidos a las fases de encuesta, desarrollo, pruebas, despliegue y asistencia.
Criterios operativos
•Propuesta de SLA (Acuerdo de Nivel de Servicio): Evaluación del nivel de servicio ofrecido, incluyendo garantías de disponibilidad, tiempo de respuesta para soporte y mantenimiento, y capacidad para dar servicio a múltiples zonas horarias.
•Apoyo posterior a la implantación: Análisis de la estructura de asistencia técnica ofrecida tras la implantación, incluidos horarios de apertura, idiomas disponibles y canales de comunicación (teléfono, correo electrónico, chat, etc.).
Criterios de sostenibilidad (si procede)
•Uso de prácticas sostenibles y responsabilidad social: Consideración de aspectos relacionados con el compromiso del proveedor con las prácticas medioambientales, la responsabilidad social corporativa y las acciones que promueven el desarrollo sostenible.
Nota: La suma de las puntuaciones en cada categoría determinará el proveedor ganador, que deberá presentar el mejor equilibrio entre calidad técnica, coste, funcionamiento eficiente y alineación con los valores institucionales de ChildFund.
34.Obligaciones del contratista
El contratista deberá cumplir plenamente las siguientes obligaciones a lo largo de todo el ciclo del proyecto, garantizando la entrega de una solución funcional, segura y acorde con los objetivos de ChildFund:
•Entrega según alcance y plazos: El contratista deberá desarrollar y entregar la aplicación de acuerdo a los requerimientos técnicos y funcionales definidos en estos Términos de Referencia, respetando el cronograma establecido, incluyendo los hitos y la fecha límite para la entrega total del proyecto.
•Documentación completa: Se debe proporcionar documentación técnica detallada, que incluya una descripción de la arquitectura, códigos, manuales de instalación, configuración e integración, así como manuales de usuario para todas las funcionalidades del sistema. La documentación debe estar disponible en portugués, español e inglés.
•Formación para usuarios y administradores: El contratista deberá llevar a cabo una formación presencial o a distancia para formar a los usuarios internos de ChildFund, a los administradores del sistema y a los socios locales, garantizando la plena comprensión y el uso adecuado de la aplicación.
•Soporte y mantenimiento: Tras la implantación, el contratista deberá proporcionar soporte técnico
para la resolución de problemas, actualización de funcionalidades y mantenimiento correctivo, según los niveles de SLA acordados, garantizando la continuidad operativa del sistema.
•Garantía técnica: Se deberá ofrecer una garantía técnica por el periodo mínimo definido en el contrato, que cubra la corrección de fallos, defectos y cualquier problema derivado del desarrollo del sistema, sin coste adicional para ChildFund.
35.Obligaciones del contratante
ChildFund, en su calidad de contratante, se compromete a cumplir las siguientes obligaciones para permitir el buen desarrollo del proyecto y garantizar el éxito de la aplicación:
•Suministro de información y acceso: Proporciona toda la información necesaria para desarrollar el proyecto, incluyendo acceso a los sistemas internos relevantes (Salesforce, LTE y otros), especificaciones técnicas, flujos operativos, así como aclaración de dudas que puedan surgir durante el proceso de desarrollo.
•Participación activa en validaciones y homologaciones: Participar activamente en las fases de recopilación de requisitos, seguimiento del desarrollo, validación de funcionalidades, realización de pruebas y homologaciones, garantizando que el sistema satisface las necesidades operativas y los requisitos funcionales.
•Aprobación de los entregables: Evaluar y aprobar formalmente los entregables de cada etapa del proyecto (prototipado, desarrollo, pruebas, despliegue y documentación), asegurándose de que se ajustan a los criterios definidos en estos Términos de Referencia y en las especificaciones técnicas acordadas.
36.Confidencialidad y protección de datos
El contratista deberá cumplir estrictamente la normativa sobre confidencialidad y protección de datos, comprometiéndose a proteger toda la información y los datos personales y sensibles a los que tenga acceso en el ámbito de este proyecto, incluidos, entre otros, los datos sobre niños, familias, colaboradores, socios y otras partes interesadas de ChildFund.
•Protección de datos personales: El contratista garantizará el pleno cumplimiento de la legislación aplicable en materia de protección de datos en todos los países involucrados en el proyecto, incluyendo, entre otros:
Ley General de Protección de Datos (LGPD - Brasil)
Reglamento General de Protección de Datos (GDPR - Unión Europea)
Leyes locales de protección de datos en los países participantes en el proyecto (Bolivia, México, Honduras, Ecuador y Guatemala).
•Uso restringido de la información: Los datos a los que se acceda, traten o almacenen durante la ejecución del contrato deberán ser utilizados exclusivamente para los fines de este proyecto, quedando prohibida cualquier forma de compartición, reproducción, divulgación o utilización para otros fines sin la autorización expresa de ChildFund.
•Confidencialidad: El contratista mantendrá la más estricta confidencialidad respecto de toda la información, procesos, datos operativos, estratégicos, comerciales o de cualquier naturaleza a los que tenga acceso como consecuencia de la realización del proyecto, tanto durante la vigencia del contrato como una vez finalizado el mismo.
•Medidas de seguridad: El contratista se compromete a adoptar las mejores prácticas de seguridad de la información, incluyendo, entre otras, controles de acceso, encriptación , copias de seguridad seguras, gestión de vulnerabilidades y protección contra la fuga de datos.
•Responsabilidad en caso de incidentes: En caso de cualquier incidente de seguridad, fuga, pérdida o acceso no autorizado a los datos, el contratista deberá notificarlo inmediatamente a ChildFund, adoptar todas las medidas necesarias para mitigar los impactos y colaborar plenamente en el esclarecimiento y resolución del incidente, así como cumplir con los requisitos legales resultantes.
•Acuerdo de confidencialidad: El contratista y sus empleados directamente implicados en el proyecto deberán firmar un Acuerdo de No Divulgación (NDA) y, en su caso, un término de compromiso relacionado con la política de protección de la infancia de ChildFund.
37.Modelo de propuesta previsto
Las propuestas deberán presentarse en formato PDF, de forma clara, objetiva y estructurada, y contener los siguientes elementos:
•Resumen ejecutivo: Visión general de la propuesta, incluyendo una breve descripción de la empresa, su experiencia, comprensión del proyecto y de los objetivos de ChildFund.
•Propuesta técnica detallada: Debe contener:
Metodología de desarrollo propuesta.
Arquitectura de la solución, considerando aspectos de seguridad, integración, escalabilidad y usabilidad.
Descripción detallada de las funcionalidades y módulos del sistema.
Equipo técnico implicado, con sus respectivos perfiles y experiencia.
Calendario detallado, alineado con los hitos y plazos establecidos en el pliego de condiciones.
Estrategia de asistencia multilingüe y servicio internacional.
•Propuesta financiera:
Valores detallados por etapa, actividad y/o servicio.
Descripción de los impuestos, tasas y costes de licencia aplicables, en su caso.
Información sobre el tipo de cambio, si hay importes en moneda extranjera.
Condiciones de pago.
•Condiciones comerciales y contractuales:
SLA propuesto.
Condiciones de apoyo y mantenimiento tras la implantación.
Garantías ofrecidas.
Condiciones para ajustes, modificaciones del contrato y mejoras continuas.
38.Disposiciones generales
•Cómo enviar las propuestas: Las propuestas deberán enviarse exclusivamente por correo electrónico, en formato PDF, a las siguientes direcciones:
[email protected]
[email protected]
•Fecha límite de presentación: Las propuestas deberán recibirse a más tardar el 30 de junio de 2025.
•Forma de comunicación: Cualquier pregunta o aclaración deberá enviarse exclusivamente por correo electrónico a las direcciones arriba indicadas, a más tardar cinco días laborables antes de que finalice el plazo de presentación de propuestas.
•Validez de la oferta: La oferta debe ser válida durante al menos 60 (sesenta) días a partir de la fecha de presentación.
•Observaciones finales: ChildFund se reserva el derecho a cancelar, modificar o suspender este proceso, total o parcialmente, en cualquier momento, sin que ello genere derecho a indemnización o compensación alguna a los solicitantes.
La presentación de la oferta implica la plena aceptación de las condiciones establecidas en el presente pliego de condiciones.