Cómo revisar documentos con un proveedor externo sin perder el control
En el último proyecto en que participé había seis fases y más de treinta
documentos. Informes, anexos, planillas de hallazgos, actas. Ninguno de esos
documentos vivía en un solo lugar. Vivían en correos, con nombres como
Informe_Caracterizacion_v1_1_rev_JA_final.docx, y el estado de cada uno
estaba en la cabeza de alguien.
No es un problema de desorden personal. Es un problema estructural, y aparece
siempre que la documentación cruza el límite entre dos empresas: el proveedor
produce, el cliente revisa, y nadie es dueño del proceso completo porque cada
lado solo ve su mitad.
Qué es lo que falla exactamente
Cuando se cae una revisión entre empresas, casi nunca es porque alguien no
leyó el documento. Es por una de estas cuatro cosas:
Nadie sabe cuál es la versión vigente. El proveedor mandó la v2 el martes,
alguien del cliente respondió sobre la v1 el miércoles, y el jueves hay dos
conversaciones en paralelo sobre textos distintos. El correo no tiene el
concepto de "versión actual": tiene el concepto de "último mensaje".
El documento no tiene un responsable, tiene un remitente. Son cosas
distintas. El remitente mandó el archivo; el responsable responde por su
contenido. Cuando solo hay remitentes, una observación que nadie recoge
simplemente se pierde, y aparece tres semanas después en una reunión.
La aprobación no queda registrada en ninguna parte. "Lo revisé y está
bien" dicho en una reunión no es una aprobación: es un recuerdo. Cuando hay
que demostrar que el entregable se aceptó —en una auditoría, en una
discusión de alcance, en un cierre de fase— no hay nada que mostrar.
Las observaciones no tienen dónde vivir. El arquitecto de seguridad arma
una planilla con sus hallazgos de los anexos. El equipo de operaciones arma su
propio reporte sobre el informe. Dos archivos nuevos, con contexto propio, que
existen a causa de un documento pero no están atados a él en ningún sistema.
Terminan como adjuntos en hilos distintos.
Cuatro reglas que sí funcionan
Ninguna de estas reglas requiere comprar software. Requieren decidir algo y
sostenerlo.
1. Un documento, un responsable con nombre
No "el equipo de seguridad": una persona. El responsable no es
necesariamente quien escribe; es quien responde por el estado del documento y
quien tiene que conseguir que avance. Si un documento no tiene un nombre al
lado, ese documento no tiene a nadie.
2. El estado se escribe, no se recuerda
Un documento está en borrador, en revisión, aprobado o rechazado. Cuatro
estados bastan, y el punto no es la cantidad: es que el estado sea un dato
consultable y no una conversación. La pregunta "¿en qué está el informe de
caracterización?" tiene que tener una respuesta que no dependa de encontrar a
la persona correcta.
3. La aprobación deja rastro: quién, cuándo, sobre qué versión
Las tres cosas juntas o no sirve. Aprobar "el informe" no significa nada
cuando hay cuatro versiones del informe; lo que se aprueba es la versión 3 del
informe, el 14 de octubre, y lo aprueba una persona concreta. Eso es lo que
después se puede mostrar sin tener que reconstruir una historia desde correos
viejos.
4. Lo que el documento genera se guarda junto al documento
La planilla de hallazgos, el reporte de respuesta, el acta de la reunión donde
se discutió: todo eso es parte del expediente de ese documento, no material
suelto. Si vive en una carpeta compartida aparte, dentro de seis meses nadie
va a saber que existía.
Por qué una carpeta compartida no alcanza
Es la objeción razonable: *esto ya lo resuelve una carpeta en la nube con
permisos*. No lo resuelve, y la razón es precisa. Una carpeta compartida
resuelve el almacenamiento: dónde está el archivo, quién puede abrirlo,
qué versión es la última. No resuelve la gobernanza: quién responde por
él, en qué estado está, quién lo aprobó y sobre qué versión.
Son dos problemas distintos y se confunden todo el tiempo. Por eso los
proyectos con la carpeta impecablemente ordenada siguen teniendo exactamente
las mismas discusiones en el cierre de fase.
Lo que construí con esto
Trabajé años en proyectos así y terminé construyendo Matrical para
resolver justamente esto: cada documento con un responsable, un estado y una
aprobación registrada contra una versión concreta; las revisiones como rondas
con su propio historial; y el ida y vuelta con el proveedor —mensajes y
archivos— guardado junto al documento que lo originó, no en un hilo de correo.
Se puede empezar gratis con un proyecto, sin tarjeta, y los
planes son por cuenta, no por usuario: sumar al proveedor como
revisor no cuesta más.
Pero si te quedas con una sola cosa de todo esto, que sea la más barata: la
próxima vez que recibas un entregable, antes de abrirlo, anota quién responde
por él y en qué estado está. Eso solo ya te ahorra la mitad de las
discusiones.