Nota de clase consolidada

Puesta en producción, soporte postimplementación, tickets y acuerdos de nivel de servicio

1. La puesta en producción como hito del proyecto tecnológico

La puesta en producción de un sistema de información representa uno de los hitos más importantes dentro del ciclo de vida de un proyecto tecnológico. Hasta ese momento, el sistema se encontraba en una etapa de análisis, diseño, configuración, desarrollo, pruebas, capacitación, conversión y migración. Sin embargo, al llegar al Go Live o salida a producción, la tecnología deja de ser un proyecto en construcción y comienza a ser utilizada en la operación real de la organización.

Este punto marca una diferencia sustancial: el sistema ya no trabaja con datos de prueba, escenarios simulados o supuestos de laboratorio. A partir de la puesta en producción, se opera con datos reales, usuarios reales, procesos reales y consecuencias reales para la organización. Por ese motivo, todas las decisiones tomadas durante las etapas anteriores se consolidan en un producto que debe funcionar en la práctica diaria.

La puesta en producción no debe entenderse solamente como un hecho técnico. No se trata únicamente de instalar un sistema, habilitar usuarios o encender una plataforma. También implica un cambio organizacional, funcional, cultural, contractual, económico y operativo. Desde ese momento, el sistema comienza a afectar la continuidad de la operación, la experiencia de los usuarios, la relación con clientes y proveedores, el cumplimiento de controles internos y la eficiencia general de la organización.

En términos generales, puede considerarse que un proyecto tecnológico fracasa cuando el sistema desarrollado o adquirido no llega a ser utilizado en producción o cuando, aun habiendo sido implementado, no es adoptado efectivamente por la organización. Por eso, la salida a producción no debe analizarse como un simple cierre formal del proyecto, sino como el inicio de una etapa crítica: la operación del sistema en condiciones reales.

2. De la etapa de proyecto a la etapa de operación

Durante la etapa de proyecto, la organización trabaja con planificación, cronogramas, entregables, pruebas y criterios de aceptación. En cambio, una vez que el sistema se encuentra en producción, comienza la etapa de operación. La lógica ya no es la de construir el sistema, sino la de utilizarlo, sostenerlo, corregirlo, mantenerlo y mejorarlo.

Esta transición requiere comprender que el sistema comenzará a ser parte de la actividad cotidiana de la organización. Los usuarios deberán realizar sus tareas con la nueva tecnología, los procesos internos deberán ejecutarse en la nueva plataforma y los datos generados por la actividad diaria deberán registrarse correctamente.

En esta etapa cobran relevancia los siguientes aspectos:

La continuidad operativa.
La disponibilidad del sistema.
La correcta migración de datos.
La configuración de roles y perfiles.
La existencia de soporte técnico y funcional.
La capacitación de los usuarios.
La adaptación cultural de la organización.
La existencia de contratos de mantenimiento.
La definición de acuerdos de nivel de servicio.
La medición del desempeño real del sistema.

El hecho de que un sistema haya sido correctamente diseñado o probado no garantiza que funcionará sin inconvenientes en producción. Las pruebas reducen riesgos, pero no eliminan la posibilidad de fallas. Por eso, la puesta en producción debe estar acompañada de mecanismos de monitoreo, soporte y estabilización.

3. La importancia de los datos en producción

Uno de los elementos centrales tratados en la clase fue la relevancia de los datos. En un sistema de información, los datos son uno de los activos más sensibles de la organización. Otros recursos pueden reemplazarse con mayor facilidad: equipamiento, proveedores, conectividad, oficinas, hardware e incluso personal. En cambio, los datos propios de la organización no siempre pueden recuperarse desde el mercado.

Cuando se trabaja en producción, la pérdida, corrupción o inconsistencia de datos puede afectar la toma de decisiones, la facturación, la contabilidad, la gestión de clientes, la relación con organismos públicos, la trazabilidad de operaciones y el control interno. Por eso, la migración de datos desde un sistema anterior hacia uno nuevo requiere validaciones técnicas y funcionales.

La conversión y migración de datos no debe limitarse a trasladar información de una base a otra. También debe verificarse que los datos migrados mantengan sentido operativo. Por ejemplo, si un cliente tenía determinado código, saldo, condición fiscal o historial de operaciones en el sistema anterior, esos datos deben estar correctamente representados en el sistema nuevo. Lo mismo ocurre con legajos, usuarios, puntos de venta, saldos de cuenta corriente, permisos, roles y perfiles.

Un problema frecuente en las migraciones se produce cuando los datos se trasladan técnicamente, pero pierden sentido funcional. Un formato de fecha, una codificación distinta, un campo mal interpretado o una parametrización incorrecta pueden generar errores graves en producción. Por ese motivo, la validación debe contemplar tanto controles automáticos como revisiones por muestreo, pruebas funcionales y verificaciones de usuarios clave.

4. Preparación técnica, funcional y organizacional

La puesta en producción requiere una preparación integral. Esa preparación puede dividirse en tres dimensiones principales: técnica, funcional y organizacional.

4.1. Preparación técnica

La preparación técnica comprende todos los elementos necesarios para que el sistema pueda funcionar desde el punto de vista tecnológico. Incluye la instalación o habilitación de la plataforma, la conexión de equipos, la configuración de servidores, redes, impresoras, dispositivos, usuarios, accesos remotos, VPN, mecanismos de autenticación, respaldos, firewalls y demás componentes de infraestructura.

También deben considerarse los planes de contingencia. Desde el primer día de uso productivo, la organización debe saber qué hacer si el sistema falla, si se interrumpe la conectividad, si se bloquea un usuario, si se cae un servidor o si se produce un error crítico.

4.2. Preparación funcional

La preparación funcional se relaciona con el modo en que el sistema permite ejecutar los procesos de la organización. Implica revisar si los procesos del sistema anterior fueron correctamente trasladados al sistema nuevo, si los usuarios tienen los permisos adecuados, si la parametrización responde a las necesidades reales y si los controles internos se encuentran configurados.

Dentro de esta preparación se incluyen los roles, perfiles, circuitos de autorización, segregación de funciones, manuales operativos, instructivos, criterios de uso y procedimientos para operar ante errores o dudas.

4.3. Preparación organizacional

La preparación organizacional se vincula con la forma en que la estructura humana de la organización se adapta al nuevo sistema. No alcanza con que la tecnología esté disponible: los usuarios deben comprender cómo utilizarla, a quién acudir ante inconvenientes y qué cambios se esperan en la forma de trabajo.

La comunicación clara es fundamental. La organización no debe tratar a los usuarios como si no advirtieran los cambios. Cuando se reemplaza una tecnología, también pueden modificarse procesos, responsabilidades, tiempos de trabajo, controles y estructuras. Por lo tanto, la implementación tecnológica exige gestión del cambio.

5. Capacitación, usuarios y adopción de la tecnología

La capacitación previa al Go Live es necesaria, pero no suficiente. Los usuarios pueden haber recibido formación, manuales, videos o instructivos, pero eso no garantiza que puedan operar con seguridad en el contexto real de trabajo.

En producción aparecen situaciones que no siempre fueron previstas durante la capacitación. El usuario puede encontrarse con pantallas distintas, procesos reordenados, errores inesperados, validaciones nuevas o decisiones de parametrización realizadas con posterioridad a la capacitación. Por eso, durante los primeros días o semanas de uso, resulta necesario contar con asistencia cercana.

La adopción de la tecnología depende, en gran medida, de la experiencia inicial de los usuarios. Si el sistema genera errores, demora procesos, produce resultados inesperados o exige pasos que no estaban claros, puede desarrollarse una percepción negativa. Esa percepción puede afectar la confianza de la organización en la tecnología implementada.

La resistencia no siempre se origina en una actitud caprichosa del usuario. Muchas veces surge porque el nuevo sistema modifica rutinas conocidas, altera tiempos de trabajo, cambia responsabilidades o dificulta tareas que antes se resolvían con mayor rapidez. Por eso, la satisfacción del usuario debe considerarse como un indicador relevante de la implementación.

6. Soporte intensivo, estabilización y Hypercare

Luego de la puesta en producción se inicia una etapa conocida como soporte postproducción, soporte intensivo, estabilización o Hypercare. Este período tiene como objetivo acompañar a la organización durante los primeros momentos de uso real del sistema.

El Hypercare consiste en una ventana de soporte ampliado. Durante ese período, los equipos técnicos, funcionales, consultores, partners o responsables internos se encuentran disponibles para resolver incidentes, responder dudas, corregir configuraciones, ajustar procesos y acompañar a los usuarios.

La duración del período de estabilización depende de la complejidad del sistema, del tamaño de la organización, de la dispersión geográfica, del volumen de usuarios, del grado de criticidad de los procesos y de lo que se haya pactado contractualmente. En algunos casos puede durar una semana; en otros, treinta días o incluso varios meses.

La finalidad de esta etapa es proteger la estabilidad inicial del sistema y consolidar la confianza organizacional. A medida que los usuarios utilizan la tecnología, se detectan problemas no previstos, diferencias entre lo diseñado y lo utilizado, necesidades de ajuste y oportunidades de mejora.

El soporte intensivo también permite distinguir entre distintos tipos de problemas:

Errores reales del sistema.
Configuraciones incorrectas.
Problemas de permisos.
Dudas de uso.
Falta de capacitación.
Procesos mal diseñados.
Diferencias entre el manual y el sistema productivo.
Expectativas incorrectas del usuario.
Problemas de rendimiento o lentitud.
Fallas de infraestructura.

7. Desempeño del sistema y cultura organizacional

Un sistema puede funcionar técnicamente y, sin embargo, ser rechazado por los usuarios. Esto ocurre cuando la tecnología no responde a las expectativas operativas o culturales de la organización.

Un ejemplo claro es el tiempo de ejecución de un proceso. Si en el sistema anterior un cierre de ventas demoraba cuarenta o cincuenta minutos y en el sistema nuevo demora dos horas, el usuario puede considerar que el sistema nuevo es peor, aunque técnicamente procese más controles o genere información más completa. Desde la perspectiva del usuario, el cambio impacta en su rutina, en sus horarios y en su percepción de eficiencia.

Por eso, el rendimiento no debe evaluarse solamente desde la mirada técnica. También debe analizarse desde la experiencia real de uso. La tecnología debe ser medida en función de su impacto operativo, su velocidad, su confiabilidad, su facilidad de uso y su aporte a los objetivos de la organización.

Las pruebas realizadas antes de la puesta en producción son necesarias, pero no siempre reproducen la complejidad de la vida real. En producción existen usuarios reales, cargas reales, tiempos reales, presión operativa, vencimientos, clientes, proveedores y consecuencias concretas. Por eso, la etapa posterior al Go Live es clave para medir si el sistema realmente se adapta a la organización.

8. Tickets de soporte

Los tickets de soporte son documentos mediante los cuales se reportan incidentes, errores, dudas o solicitudes relacionadas con el sistema. Permiten registrar el problema, asignarlo a un equipo, hacer seguimiento, medir tiempos de respuesta, establecer trazabilidad y controlar la resolución.

El ticket no debe verse como una simple queja. Es una herramienta de gestión. Para que sea útil, debe estar correctamente redactado. Un ticket incompleto o ambiguo dificulta el trabajo de soporte y puede generar cierres prematuros, respuestas automáticas o solicitudes de información adicional.

No es suficiente indicar “no funciona el sistema” o “no sale el listado”. La persona que recibe el ticket necesita información concreta para reproducir el problema y comprender el contexto. Por ese motivo, un ticket debería incluir:

Usuario afectado.
Área o sector.
Módulo del sistema.
Acción que se intentaba realizar.
Datos utilizados.
Fecha y hora del incidente.
Mensaje exacto de error.
Capturas de pantalla.
Navegador, equipo o sistema operativo utilizado, si corresponde.
Frecuencia del problema.
Impacto operativo.
Nivel de criticidad.
Indicación de si afecta a un usuario, a un área o a toda la organización.

La posibilidad de reproducir el error es fundamental. Si el equipo de soporte no puede repetir el problema, será difícil determinar si se trata de una falla del sistema, un error de uso, un problema de permisos, una configuración incorrecta o una situación aislada.

También debe distinguirse entre tiempo de respuesta y tiempo de resolución. El tiempo de respuesta indica cuánto tarda el proveedor o el equipo de soporte en tomar contacto o reconocer el incidente. El tiempo de resolución indica cuánto tarda en solucionar efectivamente el problema. Ambos conceptos suelen estar regulados en los acuerdos de nivel de servicio.

9. Criticidad, escalamiento y soporte automatizado

No todos los incidentes tienen la misma gravedad. Un usuario bloqueado, una impresora sin tóner, un listado que no se genera, una base de datos sin espacio o una caída total del sistema requieren niveles de atención distintos.

La criticidad depende del impacto operativo. No es lo mismo que un listado no salga a mitad de mes que en el último día disponible para tomar decisiones comerciales. Tampoco es lo mismo un inconveniente que afecta a un solo usuario que uno que impide facturar a toda la organización.

Los sistemas modernos de soporte tienden a incorporar herramientas de autoservicio, chatbots, asistentes virtuales, inteligencia artificial, bases de conocimiento, preguntas frecuentes y formularios automatizados. Estos mecanismos pueden reducir costos y mejorar tiempos, pero también pueden generar frustración cuando el usuario necesita una respuesta inmediata o cuando la plataforma de soporte no está pensada para usuarios finales.

Por eso, en contextos críticos, la organización debe prever mecanismos de escalamiento. Si un incidente no puede ser resuelto por la primera línea de soporte, debe existir un procedimiento para elevarlo a un nivel superior, ya sea funcional, técnico, de infraestructura, de base de datos, de seguridad o de proveedor externo.

10. Acuerdos de nivel de servicio: SLA, OLA, Underpinning Contract y PLA

Los acuerdos de nivel de servicio son instrumentos fundamentales en la etapa de operación y soporte de los sistemas de información.

El SLA o Service Level Agreement es el acuerdo de nivel de servicio. Establece qué servicio se prestará, cuáles son los niveles esperados, qué indicadores se medirán, cuáles son las responsabilidades de cada parte, cuáles son las formas de pago, qué disponibilidad se garantiza, qué tiempos de respuesta se comprometen y qué mecanismos de seguimiento se utilizarán.

Dentro de esta lógica pueden distinguirse otros acuerdos complementarios:

10.1. OLA

El OLA u Operational Level Agreement es el acuerdo de nivel operativo. Se refiere a los compromisos internos entre áreas de la propia organización para cumplir con el SLA. Por ejemplo, puede establecer cómo deben coordinarse ventas, facturación, sistemas, soporte, administración y seguridad ante determinados incidentes.

10.2. Underpinning Contract

El Underpinning Contract o contrato de soporte subyacente es el contrato que el proveedor principal o partner mantiene con terceros necesarios para prestar el servicio. Esto es especialmente importante en sistemas alojados en la nube, conectividad, hosting, seguridad o infraestructura externa.

Una organización puede tener un SLA con un proveedor, pero ese proveedor puede depender de otros servicios externos para cumplirlo. Por eso, la calidad del servicio final también depende de contratos que no siempre son visibles para la empresa usuaria.

10.3. PLA

El PLA o Performance Level Agreement se vincula con el nivel de rendimiento esperado del sistema. Permite establecer criterios relacionados con velocidad, capacidad, volumen de transacciones, tiempos de procesamiento, disponibilidad y comportamiento operativo.

Estos acuerdos deben analizarse no solo desde el punto de vista técnico o legal, sino también desde la gestión organizacional. Quien administra procesos debe comprender qué significan los tiempos pactados, qué consecuencias tiene una demora, qué ocurre ante una caída del sistema y cómo impactan esas condiciones en la operación diaria.

11. Mantenimiento, amortización y continuidad

Con la puesta en producción también se activan consecuencias económicas y contractuales. En muchos proyectos tecnológicos, los pagos se estructuran por hitos. Puede existir un anticipo inicial, pagos durante el desarrollo y un saldo final asociado a la salida a producción o a la finalización del período de estabilización.

Desde el punto de vista contable, una vez que la tecnología comienza a utilizarse en producción, puede iniciarse la amortización de la inversión realizada. También pueden activarse contratos de mantenimiento, soporte, actualización o mejora continua.

El mantenimiento es un aspecto crítico. Una organización puede adquirir buena tecnología, pero si no prevé mantenimiento, actualizaciones y soporte, el sistema puede degradarse con el tiempo. Esto puede ocurrir tanto en empresas privadas como en organismos públicos. La compra de tecnología no garantiza su sostenimiento si no existen presupuestos, contratos y políticas de mantenimiento adecuadas.

12. Indicadores de éxito de la puesta en producción

La implementación de un sistema puede considerarse exitosa cuando la tecnología logra ser utilizada en producción de manera estable, confiable y alineada con los procesos de la organización.

Algunos indicadores relevantes son:

El sistema funciona con datos reales.
Los incidentes iniciales disminuyen progresivamente.
Los tiempos de resolución bajan.
Los usuarios adoptan la tecnología.
La información generada es confiable.
Los procesos críticos pueden ejecutarse.
Los datos migrados son consistentes.
Los contratos de soporte se cumplen.
Los niveles de servicio son medidos.
La organización puede operar sin depender del sistema anterior.
La cultura organizacional incorpora la nueva tecnología.
La experiencia del usuario resulta aceptable.
Los controles internos se mantienen o mejoran.

El éxito no debe medirse únicamente por haber instalado el sistema o haber cumplido una fecha de cronograma. Debe evaluarse por la capacidad real de la organización para utilizar la tecnología en su actividad diaria, con niveles aceptables de eficiencia, control, seguridad y satisfacción.

Conceptos Clave

Go Live: momento en que el sistema pasa a producción y comienza a ser utilizado con datos reales.
Producción: ambiente operativo donde el sistema se utiliza para la actividad real de la organización.
Datos reales: información efectiva de la organización, cuya pérdida o alteración puede generar consecuencias operativas, económicas o legales.
Conversión y migración: procesos mediante los cuales se trasladan datos y configuraciones desde un sistema anterior hacia uno nuevo.
Preparación técnica: configuración de infraestructura, accesos, equipos, redes, seguridad y respaldos.
Preparación funcional: configuración de procesos, roles, perfiles, controles, permisos y procedimientos.
Preparación organizacional: comunicación, capacitación, gestión del cambio y definición de responsables.
Hypercare: período de soporte intensivo posterior a la puesta en producción.
Estabilización: etapa en la que se corrigen errores, se ajusta la configuración y se consolida el uso del sistema.
Ticket de soporte: registro formal de un incidente, duda o solicitud relacionada con el sistema.
Trazabilidad: posibilidad de seguir el historial de un incidente desde su reporte hasta su resolución.
Criticidad: nivel de gravedad de un incidente según su impacto operativo.
Tiempo de respuesta: plazo en el que el soporte toma conocimiento o responde inicialmente al incidente.
Tiempo de resolución: plazo en el que el problema queda efectivamente solucionado.
SLA: acuerdo de nivel de servicio entre proveedor y organización.
OLA: acuerdo interno de nivel operativo entre áreas de la organización.
Underpinning Contract: contrato subyacente entre el proveedor principal y terceros necesarios para prestar el servicio.
PLA: acuerdo o plan vinculado al rendimiento esperado del sistema.
Mantenimiento: conjunto de actividades destinadas a sostener, corregir, actualizar y mejorar la tecnología en uso.
Adopción tecnológica: aceptación efectiva de la tecnología por parte de la organización y sus usuarios.

Preguntas de repaso

¿Por qué la puesta en producción constituye un hito crítico dentro de un proyecto tecnológico?
¿Qué diferencias existen entre trabajar con datos de prueba y trabajar con datos reales en producción?
¿Por qué la migración de datos debe validarse tanto desde el punto de vista técnico como funcional?
¿Qué aspectos deben contemplarse en la preparación técnica previa al Go Live?
¿Qué elementos forman parte de la preparación funcional de un sistema antes de su salida a producción?
¿Por qué la capacitación de usuarios no garantiza por sí sola una implementación exitosa?
¿Cuál es la finalidad del período de Hypercare o soporte intensivo postproducción?
¿Qué información debería incluir un ticket de soporte correctamente redactado?
¿Cuál es la diferencia entre tiempo de respuesta y tiempo de resolución dentro de un acuerdo de soporte?
¿Qué relación existe entre SLA, OLA, Underpinning Contract y PLA en la gestión de servicios tecnológicos?