NOC/SOC OPERATIVO · MONITOREO CONTINUO
IT Experts de México
Contáctanos
Inicio/ Blog/ El tamaño impresiona en PowerPoint: por qué más recursos no...
Consultoría

El tamaño impresiona en PowerPoint: por qué más recursos no significan mejor operación

RERubén Espinoza calendar_today07/08/2026 schedule7 min de lectura

Hace unos días entré al portal de una empresa enorme —de esas con miles de empleados, presupuesto de tecnología que no cabe en un renglón y una marca que todo el mundo reconoce— a hacer algo trivial: descargar un estado de cuenta. No pude. Y en el camino me encontré una pantalla que se quedó conmigo, no por lo mal que estaba, sino por cómo estaba mal.

No era una intranet olvidada desde 2011. Era una interfaz de cara al cliente, viva, en agosto del 2026.

Aclaro de entrada: esto no es un artículo contra las empresas grandes. La escala da cosas reales que un operador chico no puede igualar —redundancia, poder de compra, profundidad de turnos, capacidad de aguantar la pérdida de una persona clave—. Lo que me interesa es un mecanismo específico que se activa con el tamaño y que explica por qué a veces la organización con más recursos entrega peor operación que una con muchos menos.

La anatomía de una pantalla sin dueño

Reconstrucción genérica de una interfaz con seis fallas señaladas: tarjeta cuidada a medias, un selector que dice elige una opción mientras abajo ya muestra un resultado, un botón deshabilitado que no explica por qué, jerarquía visual inconsistente, texto sin estilo con contraste casi nulo, y espacio desperdiciado en una tarea trivial. La tesis: ningún ingeniero hizo nada mal, nadie era responsable del conjunto; cada síntoma vive en la costura entre dos áreas.Reconstrucción genérica. Cada síntoma vive exactamente en la costura entre dos áreas.

Vale la pena mirarla por partes, porque los síntomas son específicos y ninguno es exótico:

  1. La tarjeta estaba cuidada a medias. Alguien diseñó el marco con esmero —tipografía correcta, esquinas redondeadas, jerarquía clara— y ahí se detuvo el cuidado.
  2. El selector se contradecía solo: decía "elige una opción" mientras, abajo, ya mostraba el resultado de una opción.
  3. El botón principal estaba deshabilitado sin explicar por qué. El usuario tiene que adivinar qué le falta hacer.
  4. El dato que yo iba a buscar pesaba menos que el marco que lo contenía. Jerarquía invertida.
  5. El mensaje de error era texto sin estilo —fuente de sistema, casi negro sobre fondo oscuro—, con un contraste tan bajo que había que forzar la vista. Parecía pegado ahí por accidente.
  6. Y sobraba espacio por todos lados para una tarea que debería ser de un clic.

Ahora, la observación que importa: ningún ingeniero hizo nada mal. El que diseñó la tarjeta hizo su trabajo. El que programó el selector hizo el suyo. El que devolvió el mensaje de error devolvió un mensaje correcto. Cada pieza, tomada por separado, es defendible.

El mecanismo: las costuras no tienen dueño

Fíjate dónde vive cada falla. Ninguna está en el centro de una responsabilidad; todas están en la costura entre dos áreas: entre diseño y front-end, entre front-end y backend, entre producto y el proveedor externo que entregó ese módulo. El selector que se contradice con su resultado es la costura entre quien maneja el estado de la interfaz y quien maneja el dato. El texto sin estilo es la costura entre quien escribe mensajes de error y quien define los estilos.

Y las costuras no aparecen en ningún organigrama. No hay un puesto que diga "responsable de que esto se sienta bien de punta a punta". Hay responsables de módulos, de sprints, de proveedores, de indicadores. El conjunto es de todos, y lo que es de todos no es de nadie.

Eso es la paradoja: el tamaño no degrada la calidad de las piezas, degrada la propiedad del resultado. Cada capa que agregas —un área más, un proveedor más, un nivel de aprobación más— crea costuras nuevas. Y las costuras se llenan de esa clase de fallas que nadie considera suyas. Es deuda técnica, pero de un tipo particular: no la contrajo nadie en específico, y por eso nadie la paga.

Por qué las credenciales no lo arreglan

Aquí está lo incómodo. Esa organización tiene, con seguridad, más certificaciones que toda mi empresa junta. Más especialistas. Metodología documentada. Auditorías. Y aun así el usuario final termina viendo eso.

Porque las credenciales miden capacidad, no propiedad. Un certificado acredita que alguien sabe hacer algo; no acredita que alguien vaya a hacerse cargo cuando la falla está en un lugar que no es de nadie. Cientos de especialistas certificados no configuran un firewall a las tres de la mañana: lo hace una persona, la que le tocó, y lo hace bien o mal según si el resultado es suyo o solo pasa por sus manos.

Es el mismo error de categoría que ya escribí sobre la sobreingeniería: confundir el tamaño del diseño con la calidad del resultado. El tamaño impresiona en PowerPoint. La calidad real aparece en una pantalla como esa.

La objeción obvia (y es justa)

Alguien puede decirme: "claro que dices eso, tú eres el proveedor chico". Es una objeción legítima, así que la contesto de frente.

Sí: el operador pequeño tiene su propia forma de fallar, y es peligrosa. Se llama dependencia de personas. Si la persona que sabe se va de vacaciones, se enferma o se va de la empresa, el conocimiento se va con ella. No hay profundidad de turnos. No hay quien cubra al que cubre. Un cliente que contrata chico y no verifica eso está comprando un riesgo distinto, no menor.

La diferencia es que ese riesgo se puede auditar: se pregunta cuántas personas conocen tu operación, se exige documentación y runbooks, se prueba qué pasa cuando el titular no está. El riesgo de las costuras sin dueño, en cambio, es casi invisible desde afuera — no aparece en ninguna presentación de credenciales, y solo se manifiesta el día que necesitas que alguien se haga cargo de algo que no es de nadie.

La pregunta que sí distingue proveedores

Cuando estás evaluando a quién le confías tu operación, la conversación suele girar alrededor de tamaño, certificaciones y logotipos de clientes. Todo eso es información, pero ninguna de las tres responde lo que de verdad importa.

La pregunta que distingue es más simple y más incómoda: ¿de quién va a ser esto?

  1. Cuando falle algo que está entre dos áreas de tu proveedor, ¿quién se hace cargo — o me van a explicar que ese pedazo es de otro equipo?
  2. ¿Quién firma el resultado completo, no el módulo?
  3. ¿Con cuántas personas tengo que hablar antes de llegar a alguien que pueda decidir?
  4. Y la versión de verificación: enséñame lo que operas. No la presentación: la operación.

Esa última es la que a nosotros nos gusta, porque es la única que no se puede simular. Nosotros construimos y operamos nuestras propias plataformas —el portal del centro de operaciones, los tableros de monitoreo, este mismo sitio— y las enseñamos. No porque sean perfectas, sino porque cuando algo se rompe ahí, no hay a quién echarle la culpa: es nuestro. Ese incentivo hace más por la calidad que cualquier certificado colgado en la pared.

Así que la próxima vez que te toque una pantalla como esa —y te va a tocar—, no pienses "qué mal equipo". Piensa: este pedazo no era de nadie. Y luego voltea a ver tu propia operación y hazte la pregunta que de verdad cuesta: ¿cuántas costuras tengo yo, y quién es el dueño de cada una?

#operación #criterio #proveedores #calidad #gestión de TI

Preguntas frecuentes

help ¿Por qué una empresa con más recursos puede operar peor que una pequeña?

Porque el tamaño no degrada la calidad de las piezas: degrada la propiedad del resultado. Cada área, proveedor o nivel de aprobación que se agrega crea "costuras" —los límites entre responsabilidades—, y esas costuras no aparecen en el organigrama. Las fallas se acumulan justo ahí, en lugares que nadie considera suyos. Ningún especialista hace nada mal; simplemente nadie es responsable del conjunto.

help ¿Las certificaciones garantizan buena operación?

No. Las certificaciones miden capacidad, no propiedad del resultado. Acreditan que alguien sabe hacer algo, no que alguien se hará cargo cuando la falla esté en un punto que no pertenece a nadie. Cientos de especialistas certificados no configuran un firewall a las tres de la mañana: lo hace una persona, y lo hace bien o mal según si el resultado es suyo o solo pasa por sus manos.

help ¿Cuál es el riesgo de contratar a un proveedor pequeño?

La dependencia de personas: si quien sabe se va de vacaciones, se enferma o deja la empresa, el conocimiento se va con ella, y no hay profundidad de turnos para cubrirlo. Es un riesgo real, pero tiene una ventaja: se puede auditar. Se pregunta cuántas personas conocen la operación, se exige documentación y runbooks, y se prueba qué pasa cuando el titular no está. El riesgo de las costuras sin dueño en organizaciones grandes es más difícil de detectar desde fuera.

RE
Sobre el autor

Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.

Ver perfil y todos sus artículos →
Compartir
// Más artículos
// Contacto

Inicia hoy tu transformación digital

Trabajemos juntos. Cuéntanos qué necesita tu operación y te respondemos a la brevedad.

call+52 (614) 400-0013 phone_in_talk+52 (614) 426-2339 mailcontacto@itxperts.com.mx

Al enviar aceptas nuestro Aviso de Privacidad.