Cómo comprar plataformas educativas sin improvisar

Una institución necesita una plataforma para gestionar aprendizaje, educación continua, prácticas, egresados, alertas estudiantiles o evidencias de calidad. Aparecen tres caminos: desarrollar un sistema propio, parametrizar un producto existente o integrar varias herramientas. La conversación suele comenzar con demostraciones y precios. Ahí está el primer error. La decisión no consiste en escoger la interfaz más atractiva ni la cotización más baja. Consiste en definir qué arquitectura permitirá sostener un proceso educativo o institucional durante varios años, con datos confiables, responsabilidades claras y una salida posible. Una plataforma barata de adquirir puede resultar costosa de adaptar, operar, conectar y abandonar. Una solución propia puede ofrecer control, pero también convertir a la institución en una empresa de software sin que haya decidido serlo. No existe una opción universalmente superior. La respuesta depende del problema, la diferenciación que la institución necesita, sus capacidades internas, el ecosistema tecnológico existente y el costo de equivocarse. Antes de elegir tecnología, describir el servicio “Necesitamos una plataforma” es una formulación demasiado temprana. Primero conviene describir el servicio: quién lo usa, qué tarea debe completar, qué decisión habilita, qué datos necesita, qué resultado se espera y qué falla sería inaceptable. Esta distinción evita automatizar un proceso mal diseñado. Si la gestión de prácticas carece de responsables, reglas de aprobación o criterios comunes, digitalizarla puede acelerar la confusión. Si una alerta de riesgo estudiantil no conduce a una acción de apoyo, el tablero solo mostrará problemas que nadie está preparado para resolver. El Informe GEM 2023 de UNESCO sobre tecnología en educación plantea una pregunta útil: ¿la tecnología se incorpora en los términos de la educación o la educación termina adaptándose a los términos de la tecnología? Para una compra institucional, eso significa comenzar por la necesidad educativa y organizacional, no por las funciones que el proveedor quiere exhibir. Antes de emitir bases, pedir propuestas o iniciar un desarrollo, el equipo debería acordar: el problema y los resultados esperados; los procesos que se mantendrán, cambiarán o eliminarán; los usuarios y sus condiciones reales de acceso; los datos indispensables y su fuente autorizada; las integraciones críticas; los riesgos de continuidad, privacidad, accesibilidad y seguridad; la evidencia que permitirá evaluar si la solución funcionó. Opción 1: desarrollar cuando la diferencia importa de verdad Desarrollar puede ser razonable cuando el proceso es estratégico, singular y estable; no existe una solución adecuada; la institución cuenta con arquitectura, producto, seguridad y mantenimiento; y conservar control sobre reglas y evolución genera valor real. El desarrollo propio permite adaptar flujos, priorizar integraciones y controlar el ciclo de cambios. También evita forzar un proceso distintivo dentro de un producto pensado para otra realidad. Pero “hacer a medida” no significa “hacer una vez”. El costo incluye descubrimiento, diseño, pruebas, accesibilidad, infraestructura, documentación, soporte, ciberseguridad, continuidad, actualizaciones y reemplazo de personas clave. El riesgo más común es financiar la construcción y subestimar la vida posterior. Un prototipo puede funcionar con un equipo entusiasta; una plataforma institucional debe sobrevivir cambios de autoridades, profesionales, normativas, navegadores, sistemas conectados y expectativas de usuarios. Desarrollar conviene menos cuando la necesidad es estándar, el mercado ya la resuelve con madurez o la institución depende de una o dos personas para comprender el código. La propiedad formal del software sirve poco si no existe capacidad para mantenerlo. Opción 2: parametrizar cuando el proceso puede adoptar una base común Parametrizar significa configurar un producto existente sin convertir cada requerimiento en código exclusivo. Es una opción fuerte cuando el proceso comparte patrones conocidos —matrícula, gestión del aprendizaje, CRM, tickets, educación continua— y la institución está dispuesta a revisar prácticas internas en vez de reproducir cada excepción histórica. Sus ventajas suelen ser una implementación más rápida, actualizaciones compartidas y una comunidad de clientes. Sin embargo, la parametrización puede esconder dependencia. Una configuración excesiva dificulta futuras versiones; un módulo aparentemente simple puede requerir consultoría del proveedor; y una necesidad fuera del estándar puede quedar atada a una hoja de ruta que la institución no controla. La pregunta clave no es cuánto se puede configurar, sino cuánto conviene configurar. Cada regla especial debe justificar su valor. Si una excepción no mejora el servicio, la calidad o el cumplimiento, quizá sea mejor simplificar el proceso. También es necesario distinguir configuración de personalización. La primera usa capacidades soportadas por el producto; la segunda introduce código o extensiones particulares. Esa frontera afecta costos, actualizaciones, seguridad y salida, por lo que debe quedar explícita en la propuesta y el contrato. Opción 3: integrar cuando el valor está distribuido Integrar puede ser preferible cuando ninguna plataforma debe concentrar todo el ciclo, varias herramientas especializadas ya funcionan bien y la institución posee una arquitectura capaz de coordinar identidades, datos, eventos y responsabilidades. La integración evita reemplazar sistemas útiles solo para conseguir una suite única. También permite cambiar componentes por etapas. Pero no equivale a conectar aplicaciones una vez. Requiere gobierno de APIs, identidad, diccionario de datos, sincronización, monitoreo, manejo de errores, seguridad y responsables cuando dos sistemas discrepan. Los estándares de 1EdTech muestran por qué la interoperabilidad educativa necesita acuerdos sobre intercambio de información, contenidos, herramientas, evaluaciones y credenciales. Declarar que un producto “tiene API” no prueba que pueda integrarse de forma sostenible. Conviene pedir documentación, límites de uso, mecanismos de autenticación, ambientes de prueba, versionado, registro de eventos y evidencia de implementaciones comparables. Una arquitectura integrada falla cuando nadie es responsable del conjunto. Cada proveedor puede demostrar que su componente funciona mientras el servicio completo entrega datos duplicados, tardíos o contradictorios. La institución necesita observar la experiencia de extremo a extremo. La matriz que importa: ocho criterios y no solo tres precios Una comparación ejecutiva debería puntuar cada alternativa con evidencia, no con adjetivos comerciales. 1. Ajuste al problema ¿Qué proporción de los requerimientos prioritarios resuelve sin desarrollos especiales? ¿Qué necesidades quedan fuera? Un listado de cientos de funciones puede ocultar que las tres decisiones críticas siguen dependiendo de trabajo manual. 2. Costo total de propiedad Debe incluir licencias, implementación, migración, integraciones, infraestructura, soporte, capacitación, seguridad, accesibilidad, actualizaciones, gestión contractual y salida. Conviene proyectarlo en escenarios de varios años y explicitar supuestos sobre usuarios, volumen y crecimiento. 3. Tiempo para producir valor No basta con estimar la fecha de puesta en marcha. Hay que preguntar cuándo los usuarios podrán completar el proceso con calidad y cuándo aparecerá el resultado esperado. Una salida rápida con baja adopción no es rapidez institucional. 4. Interoperabilidad y portabilidad ¿Qué datos entran y salen? ¿En qué formatos? ¿Existen APIs documentadas y estándares? ¿La institución puede recuperar información, configuraciones y evidencias sin pagar un rescate tecnológico? El Technology Code of Practice del Gobierno del Reino Unido recomienda diseñar para compartir, reutilizar, interoperar y evitar una dependencia innecesaria de proveedores. No es una norma chilena, pero ofrece preguntas transferibles. 5. Gobierno y calidad de datos Se debe definir quién es dueño institucional de cada dato, cuál es la fuente oficial, cómo se corrigen errores y qué ocurre cuando dos plataformas difieren. Integrar sistemas sin resolver estas decisiones multiplica inconsistencias. 6. Seguridad, privacidad y continuidad La evaluación debe cubrir accesos, registros, subcontratistas, ubicación y respaldo de datos, notificación de incidentes, pruebas, recuperación y niveles de servicio. La promesa general de “cumplimiento” no sustituye evidencia verificable ni responsabilidades contractuales. 7. Capacidad interna ¿Qué conocimientos exige cada opción durante la implementación y después? Desarrollar necesita producto y mantenimiento; parametrizar requiere dominio del proceso y del producto; integrar demanda arquitectura y gobierno técnico. La compra no elimina trabajo institucional: cambia su naturaleza. 8. Reversibilidad ¿Cuánto cuesta cambiar de rumbo? La institución debería conocer plazos de término, formatos de exportación, asistencia de transición, eliminación de datos, propiedad del código y continuidad durante una migración. Una decisión es más robusta cuando puede corregirse sin paralizar el servicio. Tres sesgos que deterioran la compra El primero es comparar el desarrollo propio con la licencia inicial de un producto. Son unidades distintas. Ambos caminos deben medirse por costo total y servicio entregado. El segundo es confundir una demostración con una prueba. La demo utiliza datos y recorridos preparados; una prueba institucional debe emplear casos representativos, errores, cargas, permisos e integraciones reales. El tercero es redactar bases como catálogo de funciones. Eso favorece respuestas de “cumple/no cumple”, pero no muestra cómo se resolverá el problema. Es mejor combinar requerimientos indispensables con escenarios: corregir un dato, integrar una calificación, atender una caída, exportar un historial o terminar el contrato. Una decisión híbrida suele ser más realista Muchas instituciones no escogerán una sola vía. Pueden parametrizar un núcleo, desarrollar una capa diferenciadora e integrar servicios especializados. Esa combinación puede ser sensata si existe una arquitectura deliberada. Sin ella, el modelo híbrido se convierte en una acumulación de contratos, conectores y excepciones. La decisión final debería quedar registrada: necesidad, alternativas consideradas, criterios, supuestos de costo, riesgos aceptados, responsables, métricas de éxito y condiciones de revisión. Así, la compra deja de depender de la memoria del equipo que participó en la licitación. Comprar una plataforma educativa es diseñar una capacidad institucional. La tecnología importa, pero no decide por sí sola qué procesos simplificar, qué datos confiar, qué dependencia aceptar ni qué experiencia ofrecer. Desarrollar, parametrizar o integrar son medios. La buena decisión es la que resuelve un problema relevante, puede sostenerse y conserva margen para aprender y cambiar. Si quieres seguir explorando herramientas para tomar mejores decisiones sobre tecnología, calidad y gestión educativa, regístrate gratis en InnovacionAcademica.org y participa en una comunidad interesada en innovar con evidencia y sentido institucional. Fuentes consultadas UNESCO. Informe de Seguimiento de la Educación en el Mundo 2023: Tecnología en la educación . 1EdTech Consortium. Estándares de interoperabilidad para tecnología educativa . Gobierno del Reino Unido. The Technology Code of Practice .