Por qué existe Doppels

En casi todas las empresas con las que hablamos pasa lo mismo. Support necesita reprocesar un cliente. Ops tiene que corregir un estado. Data necesita sacar unos datos para una reunión. Y la respuesta acaba siendo siempre la misma: «Eso tienes que pedírselo a Marta».

Marta sabe cómo se hace. Tiene el script, el terminal y los accesos. Así que le escriben por Slack, ella deja lo que estaba haciendo y el resto espera. Si Marta está de vacaciones, el trabajo se para.

El problema no es Slack

Slack solo es el sitio donde se nota. El problema de fondo es que hay conocimiento operativo que vive en la cabeza, el terminal o los accesos de unas pocas personas. Y no se puede repartir sin más: dar acceso a producción a más gente no es una opción, y documentar el procedimiento no sirve de mucho si nadie más puede ejecutarlo.

Lo que hacemos

Convertimos esa operación en algo que el resto puede pedir: con un nombre, los datos que necesita, una persona responsable y unas reglas.

El recorrido es siempre el mismo. Alguien pide la operación, quien es responsable la aprueba si hace falta, se ejecuta en el entorno autorizado y queda constancia de lo que ha pasado. Quien la pide recibe el resultado, no las credenciales.

Y los agentes

Si hoy una operación depende de escribirle a alguien, un agente tendrá el mismo problema. Darle acceso directo a producción tampoco lo arregla. Necesita lo mismo que una persona: una acción concreta que pueda pedir, dentro de los límites que ha puesto la empresa.

Por dónde empezamos

No intentamos automatizarlo todo. Empezamos por una operación real, la que hoy genera más espera, y la ponemos en producción. Las siguientes ya tienen el camino hecho.

En este blog iremos contando lo que aprendemos: qué operaciones encajan, cuáles no y qué cambia cuando una empresa deja de depender de que alguien conteste a tiempo.

Si tienes una operación que siempre acaba esperando a la misma persona, cuéntanosla.