Diagnóstico del bloqueo operativo en el departamento de IT, evidencia asociada e hipótesis de solución para la Fase 2.
Hallazgos e hipótesis de solución
01
Resumen ejecutivo
El cuello de botella en IT es un problema estructural, no de desempeño del equipo.
Lo observado confirma la existencia del bloqueo operativo, pero redirige su causa raíz. El equipo no está sub-performando: el modelo actual concentra conocimiento crítico en una sola persona y canaliza hacia IT tareas que no requieren un perfil de desarrollador.
Hallazgos principales
01Bus factor igual a 1. El 100% del contexto de negocio y del mapa de integración del stack reside en una sola persona del equipo.
02Tareas ruteadas al recurso equivocado. Envío de marketing outbound y gestión integral del CRM se ejecutan desde IT, sin requerir perfil técnico.
03Dos prácticas multiplican el costo de cada cambio: fragmentación de estilos CSS por formulario y duplicación de cursos por campaña.
04Equipo en riesgo de salida. Saturación sostenida y fricción crónica con los departamentos que solicitan tareas.
Hipótesis de solución — Fase 2
AReasignar la operación de marketing y CRM fuera de IT, vía capacitación dirigida y manuales.
BConsolidar el contenido duplicado para eliminar el multiplicador en Hyros, CRM y estilos.
CConstruir un sistema de documentación que habilite la transferencia autónoma de tareas y lleve el bus factor a ≥ 2.
DRedimensionar el alcance del rol de IT a su forma estructuralmente correcta, dado que la organización no produce desarrollo propio.
Implicación ejecutiva
Si el volumen operativo de IT se reduce ~80%, la capacidad técnica senior queda liberada para trabajo de mayor valor estratégico (consolidación de stack, mejoras de plataforma, nuevos proyectos internos), y la discusión sobre metodologías de planificación se vuelve innecesaria por reducción natural del volumen.
02
Alcance del encargo
Marco del trabajo y metodología.
01 — Mandato
Resolver el bloqueo operativo del departamento de IT.
02 — Formato
Consultoría externa, entregas incrementales.
03 — Horizonte
60 días, dos fases.
Fase 1: diagnóstico. Fase 2: ejecución.
04 — Outcome esperado
Mayor eficiencia en ejecución de tareas diarias.
Replanteo inicial
La propuesta original contemplaba la absorción full-time de las responsabilidades del líder técnico. La observación directa evidenció que el bloqueo no proviene del desempeño del equipo sino del diseño de responsabilidades y procesos. Se redefine el engagement a un rol de consultoría externa de 2 meses.
Metodología aplicada
Observación directa del flujo de tareas, entrevistas con el departamento de IT y managers de áreas solicitantes, revisión del stack técnico (6 sistemas integrados) y mapeo de dependencias de conocimiento.
03
Diagnóstico · Hallazgos
Cuatro hallazgos principales, con evidencia e implicación.
Nota editorialLas tareas, ejemplos y responsabilidades específicas citadas a lo largo de este diagnóstico son ilustrativas del análisis y fueron seleccionadas por su relevancia para los hallazgos. No pretenden inventariar ni describir exhaustivamente el trabajo que el departamento realiza hoy ni el que realizará a futuro.
HALLAZGO 01Riesgo estructural
Todo el conocimiento del stack reside en una sola persona.
El stack de la academia se compone de seis sistemas integrados entre sí. La lógica de integración, los puntos de falla y el contexto de negocio asociado a cada flujo están concentrados en una única persona del departamento.
Evidencia
6 sistemas integrados entre sí (Kajabi, GoHighLevel, Zapier, Monday, WordPress, Hyros)
La documentación disponible no describe los procesos con la profundidad necesaria para habilitar la transferencia autónoma de tareas
Ante cualquier cambio, integración o incidente del stack, la dependencia operativa recae sobre el perfil senior
Implicación
Ante una ausencia prolongada, no existe continuidad operativa. El riesgo no se ha materializado, pero tampoco está mitigado.
HALLAZGO 02Ruteo de tareas
IT ejecuta tareas operativas que no requieren perfil de desarrollador.
Dos bloques de responsabilidades asignados hoy al departamento de IT no tienen componente técnico real. Su ubicación actual absorbe capacidad de un recurso escaso sin generar valor marginal proporcional.
Evidencia
Envío de mensajes de marketing outbound
Gestión integral del CRM (GoHighLevel)
Configuración de tags de tracking (Hyros) por cada campaña
Implicación
El recurso técnico senior queda atado a operación no técnica, lo que desplaza en cola las tareas que sí requieren su perfil.
HALLAZGO 03Procesos no escalables
Dos prácticas actuales generan un costo marginal creciente por campaña.
La fragmentación de CSS y la duplicación de cursos por campaña introducen un multiplicador en cada cambio: lo que debería ser una modificación puntual requiere intervención en múltiples ubicaciones.
Evidencia
CSS fragmentado: cada formulario tiene estilos propios; un cambio global requiere intervención manual en N lugares
Duplicación de cursos: cada campaña genera un curso duplicado, que a su vez requiere un nuevo tag de Hyros, una configuración de CRM y una URL
Sin una convención de versionado o parametrización, no hay forma de diferenciar campañas sin duplicar el activo
Implicación
El costo marginal de lanzar la campaña N+1 crece linealmente con el número de campañas previas. El sistema se vuelve más lento con el tiempo, no más rápido.
HALLAZGO 04Capital humano
El equipo está saturado, con intención de salida y fricción inter-departamental.
El síntoma que originó la búsqueda externa es también un indicador de riesgo. Si la salida se materializa antes o durante la intervención, el bus factor descrito en el Hallazgo 01 se convierte en evento operativo.
Evidencia
Saturación sostenida reportada por el departamento de IT
La intención de contratación externa full-time se activó por la percepción de salida inminente
Los solicitantes no dimensionan el esfuerzo real de las tareas ("cambiar un color no debería tomar tanto")
Discusiones crónicas de plazo entre IT y otros departamentos
Implicación
La estabilidad del equipo durante la intervención está asegurada vía acuerdo directo con la dirección. La retención post-intervención depende del rediseño del rol propuesto en la Fase 2.
04
Evidencia visual
Arquitectura del cuello de botella.
Exhibit 01Múltiples áreas de la organización canalizan tareas hacia un único punto técnico.
NotaLas áreas y tipos de demanda citados son ilustrativos del patrón de convergencia; no representan la totalidad ni la complejidad de los pedidos que recibe el departamento.
Fuente: Observación directa del flujo de tareas · Fase 1 de consultoría
Exhibit 02El stack técnico se compone de seis sistemas integrados; el conocimiento de todos ellos reside en una sola persona.
Fuente: Mapeo de stack y revisión de documentación interna
05
Diagnóstico · Desagregación
Las cuatro fuentes del cuello de botella.
Desagregadas por tipo, origen y naturaleza: dos fuentes corresponden a ruteo incorrecto de tareas; las otras dos, a decisiones técnicas heredadas que generan un multiplicador.
01
Envío de marketing outbound
Tipo
Ruteo incorrecto
Ejecutor actual
Departamento de IT
Ejecutor objetivo
Marketing u operador con capacitación
Componente técnico
Ninguno sustancial
02
Gestión integral del CRM
Tipo
Ruteo incorrecto
Ejecutor actual
Departamento de IT
Ejecutor objetivo
Perfil asistente u operador interno
Componente técnico
Configuración puntual, no desarrollo
03
Fragmentación de estilos CSS
Tipo
Deuda técnica
Síntoma
Estilos por formulario, no sistema global
Efecto
Un cambio = N intervenciones
Mitigación
Sistema de estilos centralizado
04
Duplicación de cursos × tags de Hyros
Tipo
Decisión estructural
Síntoma
Un curso duplicado por campaña
Efecto compuesto
+1 tag Hyros, +1 CRM, +1 URL por duplicado
Mitigación
Unificación + parametrización (UTM / tags)
Nota
Las cuatro fuentes identificadas corresponden a los principales bloqueos observados durante la Fase 1, no a un inventario exhaustivo del trabajo del departamento. Los ejecutores objetivo y las mitigaciones propuestas son puntos de partida a validar en las próximas semanas, no decisiones finales.
Exhibit 03El efecto multiplicador de la duplicación: cada campaña añade activos adicionales en tres sistemas distintos.
NotaLos artefactos listados son ilustrativos del efecto multiplicador y fueron seleccionados para evidenciar el costo marginal; no representan la totalidad de las actividades derivadas de una campaña.
Lectura: cada nueva campaña genera cuatro artefactos en tres sistemas distintos, todos configurados manualmente
06
Fase 2 · En exploración
Cuatro frentes de trabajo para el rediseño operativo.
Las siguientes hipótesis están en evaluación durante las próximas 2–3 semanas. Se presentan con su premisa y la pregunta abierta asociada.
A
Reasignación de la operación de marketing y CRM
Las responsabilidades operativas que hoy ejecuta IT (envío de mensajes, gestión de CRM, configuración de tags) pueden migrar a un perfil no-técnico mediante manuales dirigidos y capacitación acotada.
Pregunta abierta
¿Existe un perfil dentro de la organización capaz de absorber estas tareas, o se requiere la incorporación de un rol asistente?
B
Consolidación del contenido duplicado
Es viable unificar cursos físicos y diferenciar campañas mediante tags y UTM parameters en lugar de duplicación. Esta unificación elimina el multiplicador documentado en Hyros, CRM y estilos.
Pregunta abierta
¿Qué limitaciones impone Kajabi al tracking granular por campaña sobre un único curso unificado?
C
Sistema de documentación habilitante
La documentación existe pero no está estructurada para habilitar la transferencia autónoma de tareas. Objetivo: construir un sistema de procesos documentados que lleve el bus factor de 1 a ≥ 2 al cierre del engagement.
Pregunta abierta
¿Qué procesos se priorizan primero para maximizar el impacto sobre el bus factor?
D
Redimensionamiento del alcance de IT
El alcance estructural del departamento es integración de herramientas, mantenimiento técnico y proyectos de mejora del stack. Reducido el volumen operativo no-dev, la capacidad técnica disponible se redirige hacia trabajo de mayor valor: consolidación de deuda técnica, optimización del stack y nuevos proyectos internos.
Implicación colateral
La adopción de metodologías de planificación pesadas deja de ser necesaria. El rediseño del alcance es el que resuelve el problema de planificación, no una nueva herramienta.
Exhibit 04Redimensionamiento del alcance de IT: estado actual versus estado objetivo tras la Fase 2.
NotaLas tareas listadas son ilustrativas del rediseño de alcance propuesto; no representan la totalidad ni la complejidad del trabajo que el departamento realiza hoy ni del que realizará a futuro.
Lectura: las tareas no-dev migran fuera de IT; las dev permanecen dentro de un alcance redimensionado
07
Marco de medición
Métricas de éxito para la intervención.
El volumen total de tickets resueltos se descarta como indicador: la intervención reduce ese volumen intencionalmente. El marco se concentra en velocidad, riesgo estructural y capital humano.
Métrica
Definición
Instrumento
Frecuencia
Lead time por ticketVelocidad end-to-end
Tiempo total desde la creación del ticket hasta su entrega. Incluye el wait time.
Monday / registro manual
Semanal · pre/post
Wait time por ticketDiagnóstico de cola
Tiempo entre la creación del ticket y el momento en que se trabaja activamente. Expone si el problema es capacidad o priorización.
Monday / registro manual
Semanal · pre/post
Cobertura de documentaciónBus factor
Porcentaje de procesos críticos con manual escrito y al menos una segunda persona entrenada para ejecutarlos.
Auditoría interna
T0 y T+60
eNPS del equipo de ITCapital humano
Score compuesto a partir de una encuesta de 5 preguntas. Delta pre/post es la lectura principal.
Encuesta (ver abajo)
T0 y T+60
Nota metodológica
Con un equipo de dos personas, el score numérico de eNPS es ruidoso. El valor principal proviene del delta entre mediciones y, especialmente, de la respuesta cualitativa de la pregunta 5.
Instrumento · eNPS del equipo de IT
Encuesta de cinco preguntas.
Aplicada en T0 (baseline) y en T+60 (cierre de engagement). Las preguntas 1 a 4 usan escala 0–10; la pregunta 5 es abierta.
01¿Qué tan probable es que recomiendes trabajar en el equipo de IT de Hundred Academy a un colega del rubro?Escala 0–10
02¿Qué tan claro sentís que es el alcance y las prioridades de tu rol en el día a día?Escala 0–10
03¿Qué tan sostenible sentís tu carga de trabajo actual en el mediano plazo (6+ meses)?Escala 0–10
04¿Qué tan reconocido sentís que es el esfuerzo técnico real de tus tareas por parte de quienes las solicitan?Escala 0–10
05Si pudieras cambiar una sola cosa del funcionamiento del equipo de IT, ¿cuál sería?Respuesta abierta
08
Agenda del engagement
Modo de trabajo, preguntas en exploración y fase de cierre.
Preguntas en exploración
Se resuelven a medida que los ciclos iterativos avanzan sobre cada frente. Condicionan decisiones estructurales, no el calendario del trabajo.
Q1¿Quién consume hoy los reportes de Hyros?
Determina si forma parte del bloque de tareas mal ruteadas o si ya está correctamente ubicada.
Q2¿Existe un perfil interno capaz de absorber la operación de marketing y CRM?
Alternativa: incorporación de un perfil asistente con ruta orgánica de crecimiento.
Q3¿Cuál es el sistema de priorización más adecuado al nuevo volumen redimensionado?
Hipótesis actual: un sistema ligero es suficiente una vez reducido el 80% del volumen.
Q4¿Qué limitaciones impone Kajabi al tracking granular sobre un único curso unificado?
Condición técnica previa a la consolidación de contenido duplicado.
Modo de trabajo
El engagement se ejecuta en ciclos iterativos sobre cada tarea del departamento de IT, no en fases secuenciales en cascada. Cada tarea atraviesa el mismo ciclo de forma independiente.
01Evaluación de la tareaObservación directa de cada tipo de tarea que entra al departamento: quién la solicita, quién la ejecuta, qué esfuerzo requiere, si está correctamente ubicada.
02Documentación del hallazgoRegistro del estado observado y del diagnóstico aplicable, en un formato que pueda ser consumido por otros equipos.
03Aplicación de la soluciónReasignación, consolidación, automatización, documentación o rediseño, según el tipo de hallazgo.
04Registro del progresoActualización continua del avance y comunicación informal de novedades a la dirección, sin estructura de reporte formal.
Fase de cierre · T+60
Handoff formal al finalizar el engagement.
Al término de los 60 días se entrega un handoff estructurado que consolida el trabajo realizado, documenta el cambio logrado y deja identificados los siguientes pasos posibles.
01
Documentación consolidada
Entrega organizada de todos los manuales, procesos y artefactos generados de forma incremental durante los ciclos iterativos. La dirección y los equipos reciben un único repositorio ordenado.
02
Estado pre / post
Reporte comparativo del departamento antes y después de la intervención: métricas baseline vs. T+60, tareas migradas, cobertura de documentación, eNPS del equipo.
03
Puntos de continuidad
Identificación de frentes que exceden el alcance de 60 días y pueden trabajarse más adelante, con prioridad estimada y esfuerzo asociado para futuras decisiones.
§
Cadencia del engagement
La entrega se estructura en incrementos, no en un único documento al cierre. El presente reporte formaliza el diagnóstico inicial; las comunicaciones subsiguientes adoptarán el formato apropiado a su contenido — notas de avance, documentación de procesos, reportes puntuales — culminando en el handoff formal de la fase de cierre.