Operating Kit

Identificación y gobierno

Contexto que debe mantenerse actualizado

Antes del día 1 · preparar el inicio

Owner: AI Lead. No iniciar tareas sobre sistemas o datos del cliente sin autorización y accesos aprobados.

Días 1–5 · alinear y establecer contexto

• Realizar kickoff: objetivos de negocio, expectativas, alcance, roles, decisiones y forma de trabajo.
• Completar la ficha de cuenta y validar contactos, aprobadores, canales y cadencias.
• Recorrer procesos prioritarios con sus owners; separar hechos, hipótesis y percepciones.
• Solicitar y registrar documentación, arquitectura, inventario de herramientas, datos y restricciones.
• Crear el backlog inicial; registrar solicitudes existentes sin asumir que están aprobadas.
• Identificar riesgos, dependencias, sistemas críticos y proveedores externos.

Salida esperada: ficha de cuenta inicial, mapa de stakeholders, registro de información recibida/faltante, backlog inicial y lista de riesgos/bloqueos.

Días 6–10 · diagnosticar y acordar prioridades

• Completar entrevistas y relevamiento dentro del alcance contratado.
• Evaluar oportunidades con criterios de valor, factibilidad, esfuerzo, riesgo y dependencia.
• Definir baseline y fuentes de medición cuando existan; marcar explícitamente lo que no puede medirse todavía.
• Validar restricciones de seguridad, privacidad, datos, arquitectura y supervisión humana.
• Presentar opciones y trade-offs al sponsor; no convertir recomendaciones en compromisos sin aprobación.
• Seleccionar una primera iniciativa o conjunto acotado de trabajo, con owner y criterio de aceptación.

Salida esperada: diagnóstico o síntesis de contexto, oportunidades priorizadas, decisiones registradas y primera iniciativa aprobada o motivo explícito de espera.

Días 11–20 · definir y preparar la ejecución

• Convertir la prioridad seleccionada en brief: problema, usuarios, resultado, alcance, exclusiones y dependencias.
• Definir solución y arquitectura proporcional al riesgo; identificar componentes propios y de terceros.
• Estimar esfuerzo por rol, capacidad, costos variables, incertidumbre y plan de validación.
• Definir criterios de aceptación, pruebas, fallback, monitoreo y responsable operativo.
• Obtener aprobaciones del cliente para datos, accesos, gasto, riesgos y cambios en producción que correspondan.
• Preparar entorno y plan de trabajo; revisar Definition of Ready antes de comenzar.

Salida esperada: iniciativa lista para ejecutar, estimación revisada, plan de pruebas y aprobaciones trazables. Si no está lista, permanece en clarificación o bloqueada.

Días 21–30 · ejecutar un primer ciclo controlado

• Ejecutar el alcance aprobado con seguimiento de WIP, horas, costos, riesgos y dependencias.
• Realizar pruebas técnicas y funcionales en entorno adecuado; documentar resultados y limitaciones.
• Presentar demostración o evidencia al owner de negocio y recoger feedback estructurado.
• Corregir defectos dentro del alcance; registrar cambios como nueva demanda.
• No liberar a producción sin aprobación explícita del cliente y controles acordados.
• Cerrar el ciclo: aceptación o pendientes, documentación, handoff, métricas iniciales y prioridades siguientes.

Salida esperada: primer incremento validado, decisión de avanzar/ajustar/pausar, registro de capacidad consumida y plan del siguiente ciclo.

Checklist de readiness para operación recurrente

Reunión de cierre del primer ciclo

La reunión no equivale a aceptación contractual automática. Registrar aceptación, observaciones y pendientes conforme al mecanismo acordado con el cliente.

Información a solicitar

• Objetivos de negocio y métricas disponibles; organigrama y responsables.
• Procesos relevantes: volumen, tiempos, costos, fricciones y excepciones.
• Stack, arquitectura, datos, integraciones, infraestructura y proveedores.
• Usos actuales de IA, automatizaciones, pilotos y proyectos previos.
• Políticas de seguridad, privacidad, acceso y uso aceptable de herramientas.
• Iniciativas activas, contratos relevantes, presupuestos y bloqueos.

Registro de hallazgos y límites

Brief de iniciativa

Entrada única de solicitudes

Toda demanda del cliente se registra en un backlog compartido o en el sistema operativo acordado. El AI Lead confirma recepción y se asegura de que exista información suficiente para evaluarla; recibir una solicitud no equivale a aceptarla.

Estados del backlog

Priorización: separar valor, urgencia y riesgo

Usar el scoring del Assessment o del brief como insumo para comparar oportunidades. En la operación recurrente, revisar además compromisos vigentes, capacidad por rol, costo de demora y dependencias. No sumar puntos de forma mecánica para ocultar riesgos.

El AI Lead prepara la recomendación. La prioridad de negocio y los trade-offs de presupuesto corresponden al sponsor/cliente. LIUM decide si puede comprometer capacidad y bajo qué alcance.

Regla de aceptación: cuatro condiciones

1. Problema y resultado claros: existe owner de negocio, alcance y criterio de aceptación verificable.
2. Riesgo tratable: permisos, datos, seguridad y controles están revisados; los riesgos no resueltos tienen decisión explícita.
3. Capacidad disponible: los roles necesarios tienen disponibilidad confirmada y el trabajo cabe sin romper compromisos vigentes.
4. Autorización: sponsor/cliente aprueba prioridad, presupuesto o consumo incluido y cualquier cambio de alcance que corresponda.

Planificación y límites de trabajo en curso

• Planificar por rol y etapa, no solo por total de horas: arquitectura, ingeniería, análisis, AI Lead, QA y adopción pueden ser cuellos de botella distintos.
• Hacer visible el WIP por persona/rol y por cuenta. No iniciar más trabajo del que el equipo puede terminar y revisar.
• Terminar, desbloquear o cerrar trabajo en curso antes de abrir nuevas iniciativas cuando la capacidad esté tensionada.
• Reservar tiempo para coordinación, QA, soporte acordado, incidentes y tareas no previstas; la reserva debe basarse en datos reales de operación.
• Revisar semanalmente estimado vs. real y actualizar pronóstico; registrar la causa del desvío.
• Si no hay capacidad, ofrecer opciones transparentes: reordenar prioridades, reducir alcance, mover fecha o cotizar capacidad adicional.

Política de cambios y urgencias

• Una nueva urgencia no desplaza trabajo planificado sin que el sponsor conozca qué compromiso se mueve y sus consecuencias.
• Antes de aceptar un cambio, registrar impacto en alcance, fecha, costo, capacidad, calidad y riesgo.
• Trabajo fuera del plan o fuera de lo incluido requiere aprobación escrita y, cuando corresponda, una propuesta/SOW adicional.
• Incidentes reales siguen el proceso de incidentes y la severidad/cobertura acordadas; no convertir cualquier pedido urgente en incidente.
• El AI Lead puede recomendar la secuencia, pero no aprobar gasto adicional ni aceptar cambios contractuales en nombre del cliente.

Cierre de una solicitud o iniciativa

• Resultado y criterios de aceptación revisados con el owner del cliente.
• Decisión de aceptación, rechazo o aceptación condicionada documentada.
• Documentación, configuraciones, responsables y soporte posterior definidos.
• Métricas y baseline actualizados; limitaciones de medición explícitas.
• Riesgos, deuda técnica, pendientes y dependencias transferidos con owner y fecha.
• Horas reales, costos variables, retrabajo y desvíos registrados.
• Backlog actualizado y aprendizaje reutilizable incorporado al modelo.

Estructura del reporte

1. Resumen ejecutivo: estado general, valor observado y principal conclusión.
2. Objetivos: avance frente a baseline y metas; aclarar datos no disponibles.
3. Iniciativas: estado, hitos, entregables, owner y siguiente paso.
4. Capacidad: consumida por dirección, análisis, coordinación, QA y ejecución; saldo y proyección.
5. Riesgos y bloqueos: impacto, responsable y decisión necesaria.
6. Decisiones del cliente: qué se necesita, de quién y para cuándo.
7. Próximo ciclo: prioridades propuestas y cambios de alcance/capacidad.

Control de capacidad

Umbrales sugeridos, no política contractual aprobada. Ajustar al plan y formalizar antes de comprometerlos.

Cadencia de gobierno

No fijar frecuencia, tiempos de respuesta ni cobertura antes de confirmar el contrato, la criticidad y la capacidad disponible.

Ficha de control por iniciativa

Una ficha por iniciativa activa. Mantener una única fuente de estado, evitando que el seguimiento viva solo en chats o reuniones.

Gates del ciclo de una iniciativa

1. Discovery: problema, usuario, sponsor y evidencia suficientes para evaluar.
2. Definition: alcance, baseline, criterios de éxito, riesgos, owner y dependencias acordados.
3. Validation: hipótesis técnica y operativa probadas con datos y permisos adecuados; riesgos críticos tratados.
4. Build / configure: plan, responsables, presupuesto/capacidad y criterios de aceptación aprobados.
5. Pilot: grupo y contexto acotados, monitoreo, soporte, fallback y umbrales de salida definidos.
6. Production readiness: seguridad, observabilidad, documentación, ownership, soporte y aprobación del cliente.
7. Operate / improve: medir resultados, incidentes, adopción, costos y cambios; continuar, corregir o retirar.

No todas las iniciativas requieren el mismo recorrido. Una automatización de bajo riesgo puede tener gates simplificados; una solución con datos sensibles o impacto crítico requiere controles reforzados. La aprobación de producción corresponde al cliente y a sus responsables autorizados.

Decisiones de gobierno y escalamiento

• El AI Lead puede ordenar y coordinar el trabajo dentro del alcance aprobado, pero no ampliar presupuesto, autorizar uso de datos ni aprobar producción por el cliente.
• Si aparece un cambio de alcance, registrar impacto en valor, esfuerzo, calendario, riesgo y capacidad; obtener aprobación antes de ejecutar.
• Si una iniciativa no tiene owner, baseline o criterio de éxito, mantenerla en definición; no declararla lista para construir.
• Si se supera la capacidad acordada, priorizar con el sponsor o formalizar capacidad adicional. No absorber trabajo ilimitado.
• Ante riesgo crítico de seguridad, privacidad o daño operativo, pausar la actividad afectada y activar el proceso de incidentes acordado.
• Registrar toda decisión relevante con fecha, decisor, contexto, opciones consideradas y consecuencia.

Revisión de salud

Completar en la revisión mensual y actualizar ante cambios relevantes. Cada dimensión debe tener evidencia, owner y acción si hay desvíos.

Estado de salud y respuesta

El estado es un juicio operativo documentado, no un score automático. No ocultar una dimensión crítica detrás de un promedio favorable.

Plan de recuperación

No convertir el plan en una promesa unilateral. Las acciones del cliente, los cambios de alcance y las dependencias deben quedar explícitos.

Preparación de renovación

Iniciar la conversación con anticipación suficiente según contrato, ciclo de compra y complejidad del cliente. No asumir un plazo universal ni renovación automática.

Expansión responsable

• Partir de un problema validado por el cliente, no de una tecnología que LIUM quiera vender.
• Confirmar owner, sponsor, impacto esperado, baseline y criterio de éxito antes de proponer.
• Revisar datos, seguridad, integraciones, dependencias y capacidad real disponible.
• Separar claramente lo incluido en el servicio vigente de una nueva iniciativa o ampliación contractual.
• Estimar costo, esfuerzo, riesgo y oportunidad; obtener aprobación antes de comprometer fecha o resultado.
• No ofrecer expansión para compensar una cuenta deteriorada: primero resolver causas de insatisfacción y recuperar confianza.

Registro de decisión de continuidad

Ficha de métrica

Capas de medición

Elegir pocas métricas que cambien decisiones. No usar todos los ejemplos por defecto ni asumir que una métrica está disponible en todos los clientes.

Antes de atribuir impacto

• Comparar períodos equivalentes y documentar estacionalidad o cambios de volumen.
• Separar resultados observados de estimaciones y proyecciones.
• Identificar cambios simultáneos en personal, proceso, pricing, campañas o sistemas.
• Cuando sea viable, usar grupo de comparación, rollout gradual o medición previa/posterior con limitaciones explícitas.
• No atribuir a IA todo el cambio observado si no puede aislarse su contribución.
• Informar rangos y nivel de confianza cuando la medición sea incompleta.

Revisión mensual de valor

1. Revisar baseline, valor actual, período y fuente.
2. Explicar variaciones y separar impacto confirmado de hipótesis.
3. Revisar adopción, calidad, excepciones y guardrails.
4. Comparar valor observado con costo total y capacidad consumida.
5. Decidir: continuar, corregir, ampliar, pausar o retirar.
6. Registrar decisión, responsable, fecha y evidencia que la motivó.

Registro de costo cargado por rol

Costo cargado = remuneración/contratación + cargas y costos asociados + tiempo no facturable atribuible. Definir una misma moneda y período para todos los importes.

Timesheet de piloto y onboarding

Registrar tiempo real, no estimaciones retrospectivas. Separar incorporación, Assessment, operación recurrente y proyectos adicionales.

Costo de mano de obra por actividad = horas × costo horario cargado del rol. No cargar una misma hora a más de una fase o entregable.

Costos variables y asignables por cuenta

Hoja de rentabilidad por plan o cliente

Escenarios para decidir precio y capacidad

Duplicar la tabla para cada plan. Simular varios niveles de utilización y carga de retrabajo usando los datos del piloto.

1. Estimación de esfuerzo por etapa

Antes de cotizar, estimar horas por rol. Agregar o quitar filas según alcance. Las horas incluyen preparación, reuniones, análisis, coordinación, QA y documentación.

No asumir que todas las etapas requieren todos los roles. Registrar cero cuando no aplique; justificar especialistas externos o revisiones adicionales.

2. Costo directo estimado

La contingencia no debe ocultar una estimación débil. Identificar qué incertidumbre cubre (por ejemplo, disponibilidad de datos, cantidad de entrevistas o complejidad de integraciones).

3. Precio mínimo y margen

4. Registro de resultados del piloto

Completar al cierre de cada Assessment. Comparar estimación inicial con ejecución real y explicar los desvíos.

Registrar también alcance original vs. alcance ejecutado, entrevistas previstas vs. realizadas, entregables adicionales, demoras externas, retrabajo y cambios solicitados.

5. Decisión de cotización

Registro y respuesta inicial de incidente

Ante sospecha de exposición de datos o credenciales: preservar evidencia, limitar accesos afectados y escalar al contacto de seguridad del cliente según el procedimiento acordado. No borrar logs ni prometer plazos no contratados.

Checklist de offboarding

• Confirmar fecha de cierre, obligaciones pendientes y responsables.
• Entregar inventario de soluciones, documentación, estado de iniciativas y riesgos abiertos.
• Transferir repositorios, cuentas, configuraciones y activos que correspondan al contrato.
• Devolver o eliminar datos según instrucciones y obligaciones aplicables; registrar evidencia.
• Revocar usuarios, tokens, llaves, sesiones y accesos de LIUM.
• Confirmar proveedores, costos recurrentes y renovaciones que quedan a cargo del cliente.
• Realizar reunión de handover y dejar constancia de aceptación o pendientes.