Hay una diferencia de lenguaje entre la TI y el negocio. La TI habla de servidores, enlaces y clústeres; el negocio habla de correo electrónico que no llega, ERP que no abre, informe que no se emite. El Service Mapping del Portal Nyverra ITSM sirve como traductor: conecta los activos con los servicios de negocio que sustentan.
Esta guía explica el módulo de Servicios de Negocio: qué resuelve, cómo funciona el mapeo y por qué la criticidad del servicio debe guiar la priorización de la atención.
Interfaz del módulo en el Portal Nyverra ITSM.
¿Qué es un servicio de negocio?
Un servicio de negocio es la entrega que el cliente percibe — algo con nombre de negocio, no de infraestructura:
| Servicio de negocio | Activos de los que depende |
|---|---|
| Correo corporativo | Servidor de correo, DNS, enlace, firewall |
| ERP | Aplicación, base de datos, almacenamiento, red |
| PACS (imagen médica) | Servidor de imágenes, almacenamiento, red, estaciones |
El objetivo del mapeo es responder, en segundos: “Si este activo falla, ¿qué servicio pierde el cliente y con qué criticidad?”
Por qué esto cambia la priorización
Sin servicios de negocio, la cola tiende a reflejar quién se queja más alto. Con el mapeo, la prioridad pasa a reflejar impacto real. Una alerta en un servidor de homologación puede tratarse en horario comercial; la misma alerta en un activo del PACS de un hospital es potencialmente crítica, aunque el síntoma técnico parezca pequeño.
Quién lo usa
| Perfil | Uso típico |
|---|---|
| Gestor de servicios | Definir servicios y criticidad |
| Infra / CMDB | Mapear los activos que componen cada servicio |
| Operación / NOC | Consultar el impacto al tratar incidentes |
Cómo usar: paso a paso
- Liste los servicios de negocio relevantes (comience por los críticos).
- Clasifique la criticidad de cada uno (alta, media, baja).
- Vincule los activos del CMDB que componen cada servicio.
- Relacione con clientes/contratos cuando el servicio sea específico de una organización.
- Use el mapa en la atención para priorizar y comunicar incidentes.
Reglas de negocio
| Regla | Explicación |
|---|---|
| Servicio ≠ activo | El servicio es la entrega; el activo es lo que la sustenta. Un servicio depende de varios activos. |
| Criticidad | Debe definirse con el negocio, no solo por la TI. |
| Actualización | El mapa debe acompañar al CMDB; desactualizado, engaña. |
Buenas prácticas
- Comience por los servicios más críticos y expanda — no intente mapear todo de una vez.
- Alinee la criticidad con el negocio: ¿qué considera esencial el cliente?
- Vincule servicios a cambios y problemas para llevar el contexto a la decisión.
- Use el mapa para comunicar: “incidente en el servicio X” dice más que “alerta en el host Y”.
- Revise el mapa periódicamente, junto con los cambios de infraestructura.
Errores comunes
| Situación | Qué hacer |
|---|---|
| Mapa “de papel”, nunca actualizado | Cree un responsable para el mapa y revíselo con cada cambio relevante. |
| Todo marcado como crítico | Si todo es crítico, nada lo es. Diferencie por impacto real al negocio. |
| Servicio sin activos vinculados | Sin vínculo, no hay análisis de impacto — mapee las dependencias. |
Preguntas frecuentes
¿Cuál es la diferencia entre servicio de negocio y activo?
El activo es la pieza técnica; el servicio de negocio es la entrega percibida por el cliente, sustentada por varios activos.
¿Esto sustituye al CMDB?
No — lo complementa. El CMDB guarda los CIs; el Service Mapping los organiza en servicios.
¿Sirve para priorización automática?
La criticidad del servicio orienta la prioridad; configúrelo con el negocio.
Automatice vía API
El módulo se expone por API (/api/servicos-negocio y recursos de mapeo), favoreciendo la integración con el CMDB y con herramientas de monitoreo. Referencia en developer.nyverra.com.
Escenarios de uso: el mapa que cambia la priorización
1. Hospital y PACS. Una alerta en un almacenamiento puede parecer rutina — hasta que el mapa muestra que sustenta el sistema de imágenes médicas. El incidente, entonces crítico, se trata como tal.
2. Correo corporativo. La caída de un servidor de correo afecta a cientos de personas. Con el servicio mapeado, la comunicación al negocio cambia: “el servicio de correo está afectado”, y no “el host X presentó error”.
3. ERP y cierre de mes. Una degradación del ERP en período de cierre tiene un impacto desproporcional. La criticidad del servicio, combinada con el contexto, orienta el refuerzo de prioridad y la comunicación proactiva.
Cómo construir el mapa (sin convertirse en proyecto eterno)
- Liste los servicios de negocio de los más a los menos críticos.
- Para cada uno, identifique los activos que lo sustentan (usando el CMDB).
- Defina la criticidad con el negocio — no solo en la TI.
- Vincule a clientes/contratos, cuando el servicio sea específico.
- Revise el mapa con cada cambio relevante de infraestructura.
KPIs y impacto
| Indicador | Qué revela |
|---|---|
| Servicios mapeados vs total | Cobertura del mapeo |
| Servicios sin activos vinculados | Mapas incompletos |
| Incidentes por servicio crítico | Dónde priorizar esfuerzo |
| MTTR por criticidad | Si la priorización funciona |
Con el mapa en mano, la TI pasa a hablar el lenguaje del negocio — y la priorización deja de ser opinativa para volverse estratégica.
Checklist del Service Mapping
- Liste los servicios de negocio por criticidad.
- Para cada uno, identifique los activos que lo sustentan.
- Valide la criticidad con el negocio.
- Vincule servicios a clientes/contratos cuando sean específicos.
- Defina un responsable del mapa y revíselo con cada cambio relevante.
- Use el mapa en la priorización y en la comunicación de incidentes.
Preguntas frecuentes adicionales
¿Necesito mapear todos los servicios de una vez?
No. Comience por los más críticos; el mapa crece según la madurez.
¿Cómo se vincula esto con el CMDB?
El CMDB guarda los activos; el Service Mapping los organiza en servicios de negocio.
¿Sirve para informes?
Sí — permite informes por servicio y por criticidad, además de MTTR por impacto.
Conclusión
Servicios de Negocio dan contexto a la atención. Cuando la TI ve el impacto en el lenguaje del negocio, la priorización deja de ser opinativa y pasa a ser estratégica — y cada incidente se trata por lo que realmente importa.
Seguir leyendo
Lea también
ArmazenamentoManual LSI / Broadcom MegaRAID — MegaCli y StorCLI
Con esta guía, su equipo gana autonomía para diagnosticar rebuilds, resolver foreign configurations, gestionar BBU y CacheCade — con escenarios reales de producción documentados.
20 min de leitura
Nginx Cheatsheet
Guía de bolsillo con ejemplos listos para configurar Nginx en producción: desde instalación y virtual hosts hasta ajuste de rendimiento y resolución de problemas.
12 min de leitura
KubernetesCurso Kubernetes 27 — SLO/SLI, on-call y postmortem sin culpa
Qué prometer, cómo medir y qué hacer cuando el error se dispara: SLI, SLO, presupuesto de error, alertas que despiertan a alguien y postmortem sin caza de brujas.
5 min de leitura
Comentarios
Aún sin comentarios
Sea el primero en compartir su opinión sobre este artículo.

Deje un comentario