# Aprobaciones de cambios sin el tira y afloja por correo electrónico · Stilla > Un cambio está a la espera de aprobación, la aprobación se encuentra en la bandeja de entrada de alguien y la ventana de mantenimiento se acerca. URL: https://stilla.eywo.digital/es/blog/change-approvals-without-email/ Language: es Last updated: 2026-10-25 [← Volver al blog](https://stilla.eywo.digital/es/blog/) Cambios2 de julio de 2026Actualizado 25 de octubre de 20264 min readEquipo de Eywo # Aprobaciones de cambios sin el tira y afloja por correo electrónico Un cambio está a la espera de aprobación, la aprobación se encuentra en la bandeja de entrada de alguien y la ventana de mantenimiento se acerca. A continuación, se explica cómo trasladar las aprobaciones fuera del correo electrónico y a una cola única. El lunes por la mañana, la bandeja de entrada del gestor de cambios contiene decenas de mensajes. Algunos son solicitudes de aprobación de interrupciones, otros son respuestas a ellas, y otros más son preguntas reenviadas del tipo "¿podrías echarle un vistazo?". Algunos propietarios de servicios respondieron "de acuerdo", otros no respondieron en absoluto, y uno respondió solo a la mitad de los destinatarios. La ventana de mantenimiento es el jueves, y nadie sabe con certeza qué cambios están aprobados. Para los ingenieros, esto significa incertidumbre sobre si pueden proceder. Para los propietarios de servicios, significa un flujo de mensajes sin contexto: no saben exactamente qué va a pasar o qué significa para su servicio. Y si algo sale mal más tarde, averiguar quién aprobó qué, y en base a qué información, se convierte en trabajo de detective. ## Por qué el correo electrónico no es la herramienta adecuada para aprobaciones El correo electrónico es adecuado para la comunicación. Es una herramienta pobre para decisiones que necesitan ser rastreables. - **No hay una visión general.** Nadie puede ver en un solo lugar qué está esperando a quién, y durante cuánto tiempo. - **No hay contexto.** El aprobador recibe una descripción del trabajo, pero no sabe qué servicios estarán fuera de servicio. - **Destinatario poco claro.** ¿Quién debería aprobar la interrupción: el propietario de la aplicación, el líder del equipo o alguien de la empresa? - **"De acuerdo" no es una decisión.** Una aprobación por correo electrónico no tiene un enlace claro a una versión específica del cambio, y las rechazos a menudo simplemente faltan. La respuesta nunca llega. - **Procesos diferentes, caminos diferentes.** Los cambios se aprueban de una manera, las solicitudes de otra, y la aplicación de parches de una tercera. ## Una mejor forma de gestionar aprobaciones Un proceso de aprobación sólido responde a tres preguntas: quién decide, sobre qué base, y qué sucede si no lo hace. Recomendamos: 1. **Un lugar para cada solicitud de aprobación**, sea cual sea el proceso del que proviene. 2. **El consentimiento proviene de quien se ve afectado**: el propietario del servicio afectado, no quienquiera que fue incluido en el correo electrónico. 3. **El aprobador ve el impacto.** Sabe qué servicios estarán no disponibles o degradados, y cuándo. 4. **Una rechazo tiene una razón.** El solicitante sabe qué cambiar sin tener que perseguir a nadie. 5. **Rigor proporcionado.** Los cambios rutinarios no necesitan un CAB; los riesgosos sí. ## Cómo lo maneja Stilla Stilla trae cada solicitud de aprobación a una **única cola de "Aprobación pendiente"**. Contiene interrupciones de cambios, solicitudes de servicio, acuerdos de parche y propuestas de lista de precios. **Una regla determina quién es el propietario** para todos ellos; si un servicio no tiene propietario, el gestor de cambios decide. Antes de que se envíe un cambio, Stilla **calcula su impacto**: qué servicios y aplicaciones estarán no disponibles o degradados. La interrupción es aprobada por el **propietario del servicio afectado**, con pleno conocimiento de lo que implica el trabajo. Un cambio solo puede programarse dentro de una ventana de mantenimiento, fuera de congelaciones de cambios y sin chocar con otros cambios. El nivel de escrutinio se establece mediante **modelos de cambio**: - **cambios estándar preaprobados** para trabajos rutinarios recurrentes, - **cambios normales** aprobados por el propietario del servicio, el gestor de cambios y, donde sea necesario, el **CAB**, - **cambios de emergencia** para situaciones que no pueden esperar. **Cada rechazo viene con una razón**, para que el solicitante sepa qué arreglar. Cada decisión se escribe en el registro de auditoría, y las notificaciones se envían por correo electrónico o a Slack según las reglas. El correo electrónico se convierte en una forma de alertar a las personas, no en el lugar donde se toman las decisiones. ## Conclusión La aprobación de cambios no tiene que ser un intercambio interminable de mensajes. Cuando cada solicitud se encuentra en un solo lugar, el aprobador puede ver el impacto y cada rechazo tiene una razón, las decisiones se toman más rápido y con más confianza. Los ingenieros saben dónde están, y los propietarios de servicios pueden estar seguros de que nada sucede con su servicio sin su conocimiento. La cola de aprobación única, los modelos de cambio, el cálculo de impacto y la aprobación de interrupciones por parte de los propietarios de servicios son parte de la edición Estándar. **Stilla Standard** Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados. [Comparar ediciones →](https://stilla.eywo.digital/es/editions/) ## Más artículos [Cambios·9 de julio de 2026 ### Ventanas de mantenimiento y congelaciones: cuándo puede tocarse la producción Las ventanas de mantenimiento, congelaciones de cambios y colisiones a menudo viven en la cabeza de las personas y en hojas de cálculo dispersas. A continuación, se explica cómo convertirlos en reglas que el sistema hace cumplir para usted. Standard4 min read](https://stilla.eywo.digital/es/blog/maintenance-windows-and-freezes/)[CMDB·25 de octubre de 2026 ### La red virtual en la CMDB: del grupo de puertos al switch leaf Entre una máquina virtual y la red física se encuentra una capa que la mayoría de las CMDB no ven: conmutadores virtuales, grupos de puertos y enlaces ascendentes de host. Sin embargo, aquí es precisamente donde se decide qué servicios afectará un cambio en la red. Standard4 min read](https://stilla.eywo.digital/es/blog/virtual-network-in-the-cmdb/)[Gobernanza·25 de octubre de 2026 ### NIS2 y DORA: lo que las operaciones de TI deben poder demostrar Ambas regulaciones formulan la misma pregunta: ¿sabe qué servicios se ven afectados por una interrupción, quién es responsable de ellos y qué cambió cuándo? Sin un mapa de dependencias fiable, las respuestas se elaboran manualmente, a menudo bajo presión de tiempo. Standard3 min read](https://stilla.eywo.digital/es/blog/nis2-dora-evidence/)