De un Word de 40 pasos a un panel ejecutable: cómo convertimos un runbook de Salesforce en un proceso auditable

Sábado por la mañana. Alguien del equipo abre un documento de Word con cuarenta pasos numerados y empieza por el primero. Copiar un dato de aquí, lanzar un comando allá, esperar, comprobar, seguir.

A mitad de la lista suena el teléfono. Media hora después vuelve al documento y aparece la pregunta que todos hemos hecho alguna vez: «el paso 17, ¿lo llegué a lanzar o no?».

El Word no lo sabe. El Word nunca lo sabe. Y algunos de esos pasos tardan media hora en ejecutarse, otros sobrescriben datos y ninguno tiene botón de deshacer. Así que la decisión real no es «lo repito o sigo»: es «me juego media mañana repitiéndolo o me juego el entorno saltándomelo».

El problema de fondo no es el tamaño, es el método

Esta escena la vivimos con uno de nuestros clientes en Barcelona, sobre cuatro entornos de Salesforce: producción, preproducción, integración y desarrollo. Pero el problema no aparece porque haya cuatro entornos. Aparece porque el proceso está escrito, no ejecutado.

Un documento describe lo que hay que hacer. No sabe qué se ha hecho ya, ni cuándo, ni contra qué entorno, ni con qué resultado. Toda esa información vive en la memoria de quien está ejecutando, y se evapora en cuanto esa persona se va de vacaciones, cambia de proyecto o simplemente atiende una llamada.

Si tienes un solo entorno y un solo administrador, tienes exactamente el mismo agujero. Solo que con menos ruido alrededor. La escala no cambia el problema: cambia lo visible que es cuando falla.

Y el fallo más caro de este tipo de procesos es silencioso: ejecutar el paso correcto contra el entorno equivocado. Nada peta. Nadie se entera. El daño aparece días después.

La solución: un panel que ejecuta el runbook

Construimos un Command Center: un panel de control que se abre en local y orquesta 30 scripts sobre una matriz de tarea × entorno. Cada casilla de esa matriz guarda su estado, su registro de ejecución y los parámetros con los que se lanzó.

Cubre dos campañas de operaciones sobre el mismo motor: refrescar los entornos de prueba a partir de producción, y alinear las ramas de código con lo que realmente hay desplegado en cada entorno.

El progreso sobrevive a cerrar el navegador y a interrumpir la campaña a mitad. Pero lo interesante no son las funcionalidades, son las decisiones.

Decidimos que el estado tuviera dos ejes, no uno

Qué decidimos: el semáforo del panel no mide solo cuánta desviación hay entre entornos, sino también cómo de vieja es la medición. Una medida tomada hace más de tres días se pinta en gris, no en verde.

Por qué: porque pintar de verde un dato caducado es mentirle a quien lo mira. Un «todo correcto» de la semana pasada no es un «todo correcto».

Qué evitó: que alguien tomara una decisión irreversible apoyándose en una foto vieja del sistema.

Decidimos que todo lo peligroso empezara en simulación

Qué decidimos: el modo de simulación —ejecutar el paso entero sin escribir nada, mostrando solo lo que haría— viene activado por defecto. Aunque dejes el campo vacío, no escribe.

Por qué: los valores por defecto son la única política de seguridad que se aplica sola. Todo lo que dependa de que alguien se acuerde de marcar una casilla, tarde o temprano falla.

Qué evitó: que un despiste de configuración se convirtiera en una escritura real sobre un entorno.

Decidimos poner guardas que abortan solas

Qué decidimos: dos frenos automáticos. Si el entorno destino no coincide con el esperado, el script se detiene antes de tocar nada. Y si una operación fuera a borrar más del 40 % de los componentes, se para y pide confirmación explícita.

Por qué: un borrado masivo casi nunca es lo que querías hacer. Casi siempre es el síntoma de que el proceso está apuntando donde no debe.

Qué evitó: exactamente el fallo silencioso del que hablábamos: el paso correcto contra el entorno equivocado.

Decidimos tender la red antes de saltar

Qué decidimos: una copia de seguridad completa de cada entorno, guardada de forma permanente, antes de la primera operación de la campaña.

Por qué: porque la copia que necesitas es siempre la que no hiciste.

Qué evitó: que la vuelta atrás dependiera de la retención estándar de la plataforma, que tiene fecha de caducidad.

Decidimos medir el punto ciego en vez de ignorarlo

Qué decidimos: el proceso destapó 4.381 componentes —informes, plantillas de correo, cuadros de mando— que las herramientas estándar no pueden extraer de un entorno Salesforce. No podíamos resolverlo, así que lo contamos y lo pusimos en pantalla.

Por qué: un punto ciego medido deja de ser un riesgo desconocido y pasa a ser una decisión consciente. Puedes convivir con 4.381 elementos fuera del proceso automático; lo que no puedes es no saber que existen.

Qué evitó: dar por completo un inventario que no lo estaba.

Decidimos contar dos veces y comparar

Qué decidimos: para responder a «¿tenemos de verdad todo el inventario?» no nos bastó con que una herramienta dijera que sí. Contamos por dos vías independientes y comparamos los resultados.

Por qué: una sola fuente no se puede contradecir a sí misma. En una medición real salieron 33.060 componentes en 29 tipos, con 12 coincidencias exactas entre ambas vías y los descuadres señalados uno a uno.

Qué evitó: confiar en un número que nadie había verificado.

Lo que aprendimos

Un proceso escrito no es un proceso ejecutable. El Word describe la intención; el panel guarda los hechos. Mientras el estado viva en la cabeza de alguien, el proceso no es del equipo: es de esa persona.

El dato caducado no es un dato, es un riesgo con buen aspecto. Cualquier indicador que enseñes debería llevar pegada su fecha de medición. Si no puedes decir cuándo se midió, no lo pintes de verde.

Lo que no puedes arreglar, mídelo. Hay límites técnicos que no vas a resolver. Cuantificarlos los convierte en una línea del plan en lugar de en una sorpresa a mitad de camino.

El número que nadie quiere ver es el que desbloquea el proyecto. Las cuatro ramas de código habían acumulado 10.094 commits divergentes entre sí, y la cifra crecía sola cada mes. Ese número no existía antes de la herramienta. Ponerlo en una pantalla es lo que convirtió un «algún día habría que mirar eso» en una prioridad de dirección.

Qué se lleva una PYME de todo esto

No necesitas cuatro entornos ni treinta scripts. Necesitas cuatro hábitos.

1. Convierte tu runbook en una lista con estado. Aunque sea una hoja de cálculo compartida con tres columnas: paso, quién lo hizo, cuándo. Que cualquiera pueda mirar y saber por dónde va el proceso sin preguntar a nadie.

2. Simula antes de ejecutar. Antes de una carga masiva, una regla de borrado o un cambio de permisos, pruébalo primero en un entorno de pruebas o con una muestra pequeña. Y que ese sea el camino por defecto, no la excepción.

3. Pon una guarda donde puedas. Un campo de confirmación, un aviso cuando el volumen es anormal, una comprobación de «¿estoy donde creo que estoy?». Un solo freno automático vale más que tres párrafos de advertencia en un documento.

4. Deja evidencia, no confianza. Después de cada operación crítica, guarda algo que puedas enseñar: una captura, un informe exportado, un registro. Cuando alguien pregunte «¿esto se hizo?», la respuesta debería ser un fichero, no un recuerdo.

En nuestro caso, el resultado fue pasar de un documento que solo una persona sabía ejecutar a un panel donde cualquiera del equipo ve el estado de los cuatro entornos de un vistazo, y donde cada operación deja evidencia descargable para la reunión de seguimiento.

¿Tienes un proceso que vive en la cabeza de una persona?

Casi todas las empresas con las que hablamos tienen uno. La migración anual, el cierre de trimestre, el alta de un cliente grande, el despliegue de un cambio importante. Funciona hasta que esa persona no está.

En Newe Cloud ayudamos a PYMEs a convertir esos procesos en algo que el equipo entero pueda ejecutar con seguridad. Sin proyectos eternos ni consultores rotativos.

Cuéntanos cuál es el tuyo y le damos una vuelta juntos, sin compromiso.