Cómo documentar un proceso que solo conoce el fundador.

Para documentar un proceso que solo conoce el fundador hay que observar una operación concreta, identificar sus decisiones, registrar excepciones, asignar responsables y comprobar que otra persona puede completarla. El objetivo no es guardar todo lo que sabe una persona: es convertir una parte verificable de ese conocimiento en una forma de trabajar compartida.

Una grabación, una reunión o una carpeta con capturas pueden ayudar a recoger información, pero no demuestran transferencia. Si quien recibe el material sigue sin saber cuándo aprobar, a quién consultar o dónde registrar una excepción, la dependencia continúa aunque exista documentación.

Esta guía se centra en el método operativo para capturar y validar un proceso. La continuidad de la empresa familiar, el relevo y la distribución general de responsabilidades son una conversación más amplia; aquí el entregable es un procedimiento concreto que otra persona pueda ejecutar.

Elige un proceso reconocible que tenga principio, final y consecuencias si se detiene: validar un pedido especial, resolver una incidencia de entrega, aprobar una compra no prevista o preparar una oferta con condiciones particulares. Son ejemplos de trabajo posibles, no clientes ni resultados atribuidos a AMBG.

Define el disparador y el cierre antes de entrevistar a nadie. Por ejemplo: el proceso empieza cuando entra una solicitud fuera de las condiciones habituales y termina cuando la decisión está comunicada, registrada en el sistema correspondiente y disponible para quien continúa la operación.

Anota qué entra, quién interviene, qué sistemas se consultan y qué resultado necesita la siguiente persona. Si el recorrido atraviesa comercial, administración y operaciones, esa frontera entre áreas forma parte del proceso: no puede desaparecer dentro de un procedimiento escrito desde un único puesto.

No hace falta empezar por el proceso más complejo. Conviene elegir uno que pueda observarse con operaciones reales, que tenga una persona de relevo identificada y cuyo riesgo permita revisar una primera versión sin interferir con el trabajo diario.

La primera conversación sirve para dibujar el recorrido, no para darlo por cerrado. Pide al fundador que reconstruya una operación reciente desde la entrada hasta el cierre y que enseñe qué comprueba realmente: el ERP, una hoja, un correo, un documento, una llamada o una condición que recuerda por experiencia.

Después compara un caso normal con otro que haya necesitado aclaración y, si existe, con una incidencia. La diferencia entre esos recorridos suele mostrar el conocimiento que no aparece en una descripción lineal: cuándo se acepta una condición, cuándo se detiene el trabajo y quién debe enterarse.

Las preguntas útiles son concretas: ¿qué miras primero?, ¿qué dato te haría cambiar de decisión?, ¿qué nunca aprobarías sin consultarlo?, ¿quién puede sustituirte?, ¿dónde queda constancia?, ¿qué ocurre si falta información? Si la respuesta es “depende”, la siguiente pregunta es de qué depende.

Si se utilizan capturas o grabaciones, hay que acordar antes su finalidad, acceso y conservación, y evitar registrar contraseñas, información innecesaria o datos que no deba ver el equipo. La evidencia de trabajo sirve para reconstruir el proceso; no justifica crear un archivo indiscriminado de conversaciones.

Un mapa inicial puede escribirse como una secuencia sencilla: solicitud recibida, información comprobada, decisión tomada, ejecución confirmada y cierre registrado. Debajo de cada paso se indica la persona responsable, el dato utilizado, el sistema consultado y la evidencia que debe quedar.

El detalle importante suele estar entre pasos. Si comercial confirma una condición por correo, operaciones necesita saber dónde consultarla; si administración registra el pedido en el ERP, el estado debe poder relacionarse con la decisión que lo autorizó. Un traspaso sin fuente de información definida obliga a volver a preguntar.

No conviertas el diagrama en un inventario de herramientas. Primero se describe qué trabajo ocurre y quién responde. Después se decide si el ERP, SharePoint, una lista de Microsoft 365 u otra herramienta existente es el lugar adecuado para sostener cada parte.

Cada paso debería poder responder cuatro preguntas: qué lo activa, quién lo realiza, qué necesita para avanzar y qué deja preparado para el siguiente. Si alguna respuesta sigue dependiendo de la memoria del fundador, el mapa todavía no representa la operación real.

La persona que introduce un pedido no siempre es quien autoriza una excepción, y quien aprueba no siempre mantiene actualizada la documentación. Mezclar esas funciones produce procedimientos que parecen claros hasta que aparece una incidencia o alguien falta.

Para cada tramo identifica un responsable titular, un suplente con acceso suficiente, la persona que puede aprobar y quien debe ser informado. No hace falta implantar una matriz compleja si el equipo es pequeño; sí hace falta que los nombres o los roles estén definidos y que el relevo conozca sus límites.

Una delegación útil especifica qué puede decidir cada rol, qué condiciones exigen escalar y qué evidencia debe quedar después. “Consultarlo con dirección” no es un criterio: debe aclararse qué motivo activa la consulta, quién sustituye a dirección y por qué canal se recoge la respuesta.

Los responsables se asignan por el proceso, no por la contraseña de una persona. Si el acceso al ERP, la aprobación de Microsoft 365 o el buzón compartido dependen de una única cuenta, documentar el trabajo no resuelve todavía la continuidad.

La matriz de decisiones recoge situaciones concretas y traduce experiencia en instrucciones comprobables: condición observada, dato que la confirma, decisión permitida, responsable de aprobar, motivo de escalado y lugar donde se registra. Cada fila representa una decisión; no un párrafo genérico sobre buenas prácticas.

Un ejemplo ilustrativo: si una solicitud encaja en las condiciones ya aprobadas, el responsable operativo puede continuar y dejar constancia en el ERP. Si cambia una condición comercial, falta documentación o existe una incidencia abierta, se detiene el avance y se solicita la aprobación del rol designado.

Los límites de importe, descuento, riesgo, plazo o crédito deben salir de las reglas reales de la empresa. No se copian umbrales inventados ni se presentan como universales. Si la organización todavía no puede explicarlos, el resultado de la entrevista es una decisión pendiente de dirección, no una regla ficticia.

La matriz debe distinguir qué es automático, qué requiere revisión humana y qué queda expresamente fuera. También indica cómo resolver contradicciones entre el criterio escrito y una situación no prevista: se registra la excepción, se decide quién la revisa y se actualiza el procedimiento si el patrón se repite.

Un proceso solo descrito para el caso ideal deja fuera precisamente el conocimiento que se quiere transferir. Conviene registrar qué ocurre cuando falta un documento, el ERP muestra un dato contradictorio, no responde la persona que aprueba o una entrega necesita cambiarse.

Cada excepción necesita un identificador o descripción reconocible, una condición de detección, un responsable, una acción provisional, un criterio de escalado y una forma de cierre. Si existe un plazo comprometido, ese plazo debe proceder de la política real de la empresa y quedar asociado al rol que vigila el caso.

Un registro de excepciones no pretende prever todas las situaciones. Permite diferenciar las variaciones habituales de las incidencias nuevas y conservar el motivo de cada decisión. Cuando una excepción empieza a repetirse, se revisa si debe convertirse en regla o si el proceso necesita simplificarse.

Automatizar un recorrido sin estas definiciones traslada el problema a otra herramienta: el flujo se detiene, nadie sabe a quién avisar o se ejecuta una decisión que debía revisar una persona. Primero se acuerda la respuesta; después se valora si merece automatización.

La ficha mínima debe identificar nombre y objetivo del proceso; disparador; entrada necesaria; resultado de cierre; responsable titular y suplente; roles que aprueban; sistemas y fuentes de datos; pasos; decisiones; excepciones; evidencias; permisos; fecha de revisión y propietario del documento.

Plantilla práctica: “Proceso: [nombre]. Empieza cuando: [disparador]. Termina cuando: [resultado verificable]. Titular: [rol]. Suplente: [rol]. Datos obligatorios: [campos]. Sistema de referencia: [ERP o repositorio]. Puede decidir: [rol y condiciones]. Debe escalar: [situación y destino]. Evidencia de cierre: [registro]. Próxima revisión: [fecha]”.

A esa ficha se añade una matriz breve: “Situación: [hecho]. Criterio: [regla confirmada]. Acción: [paso permitido]. Aprueba: [rol]. Si falta información: [bloqueo o escalado]. Registro: [ubicación]”. Los corchetes señalan datos que cada empresa debe completar; no sustituyen una política real.

El documento necesita un nivel de detalle proporcionado al riesgo. Una tarea sencilla puede quedar resuelta con una ficha y una comprobación; una operación con varias aprobaciones quizá requiera un mapa, una lista de excepciones y una prueba independiente. Más páginas no significan más transferencia.

El ERP suele ser el lugar adecuado para conservar datos operativos que forman parte de la transacción cuando el sistema admite esos campos y permisos: pedido, estado, condición aprobada, referencia de incidencia o responsable asignado. El dato se registra una vez en su fuente de referencia; no se replica en varios documentos sin motivo.

Microsoft 365 puede ayudar a organizar la documentación del proceso con las herramientas ya disponibles y los permisos correspondientes. SharePoint permite mantener una versión compartida de la ficha; una lista puede registrar excepciones o decisiones pendientes; Teams sirve para coordinar una conversación, pero no debería ser la única evidencia de una aprobación.

Un buzón compartido, una tarea o una aprobación pueden ser útiles cuando responden a un responsable y una finalidad concreta. Su disponibilidad, configuración, permisos, conectores y posibles licencias deben comprobarse en el entorno de cada empresa; no se da por hecho que cualquier suscripción incluya todas las capacidades.

Si el ERP y Microsoft 365 necesitan intercambiar información, antes hay que definir qué sistema manda en cada dato, qué evento inicia la integración, qué ocurre si falla y quién corrige una discrepancia. La documentación del proceso es lo que permite evaluar una API, un conector o una automatización sin inventar el alcance.

La transferencia no termina cuando el fundador aprueba el documento. Primero, la persona de relevo observa una operación y explica qué criterio se ha aplicado. Después ejecuta otra con el fundador presente, describiendo en voz alta qué comprueba y por qué toma cada decisión.

La prueba decisiva es invertir los papeles: la persona de relevo realiza el recorrido utilizando la ficha, la matriz y los accesos disponibles; el fundador observa sin intervenir salvo que exista un riesgo real. Cada duda, permiso ausente o decisión no prevista se anota como una corrección pendiente.

Si el proceso no puede probarse directamente en producción, se utiliza una simulación controlada, un entorno de prueba o un caso reconstruido sin datos innecesarios. La simulación tiene que cubrir al menos un recorrido normal y una excepción relevante, sin prometer que una muestra pequeña represente todas las situaciones.

El resultado queda documentado con fecha, participantes, caso revisado, incidencias, correcciones y responsable de validación. La transferencia se considera suficiente para ese alcance cuando la persona designada puede completar el proceso, justificar sus decisiones y saber a quién escalar lo que queda fuera.

Las primeras medidas pueden ser sencillas: cuántas decisiones del proceso siguen necesitando al fundador, cuántas operaciones quedan bloqueadas por falta de responsable, cuántas excepciones carecen de criterio y cuántas evidencias de cierre no aparecen donde deberían.

Antes de comparar, hay que definir cada indicador y observar la situación de partida durante un periodo acordado. También conviene distinguir una consulta necesaria por riesgo de una dependencia evitable por falta de documentación o permisos.

No existe un porcentaje de mejora aplicable a todas las empresas ni un plazo garantizado de transferencia. El alcance depende de la frecuencia del proceso, sus variaciones, la disponibilidad de las personas y el estado de los sistemas. El valor se demuestra con operaciones revisables, no con cifras comerciales inventadas.

Una señal práctica es comprobar si el responsable alternativo puede completar un caso ordinario y encauzar una excepción sin reconstruir decisiones desde mensajes personales. Otra es verificar que el fundador puede consultar el estado y revisar las decisiones sin convertirse en el único punto de paso.

Asigna un propietario del procedimiento y una fecha de revisión. El documento debe actualizarse cuando cambian una regla comercial, el ERP, los permisos, la persona suplente o una excepción que ya aparece con frecuencia. Una versión sin responsable vuelve a convertirse en papel que nadie consulta.

La automatización solo tiene sentido cuando la entrada, la salida, las reglas estables y la respuesta ante fallos están definidas. Puede consistir en avisar al responsable, solicitar una aprobación, actualizar un estado o conectar dos sistemas; no sustituye la revisión humana cuando el criterio todavía es ambiguo.

Si el problema principal es la continuidad general de una empresa familiar, conviene trabajar también el reparto de decisiones, la preparación de relevos y el acceso al conocimiento. Si el recorrido concreto ya está claro, la siguiente conversación es de consultoría de procesos y, solo cuando proceda, de automatización.

El primer paso útil es escoger una operación que hoy dependa del fundador, observarla con quienes participan y acordar qué debe quedar escrito, quién podrá decidir y dónde se conservará la evidencia. A partir de ahí se puede pedir un diagnóstico con un alcance reconocible, sin comprar software antes de entender el problema.