Una cosa fundamental, para tener un buen sistema de gestión documental, es tener los expedientes de proyectos organizados.
Cuando hablo de un expediente me refiero a una unidad administrativa orientada a un objetivo (generalmente facturar) y cuyo contenido, en un estudio de arquitectura, normalmente es un proyecto. Pero podría darse el caso de que el expediente no fuera un proyecto (por ejemplo, un servicio de asesoramiento técnico a un cliente mediante minuta fija mensual).
Para esto hay que ordenar los proyectos en portafolios.
Un portafolio de proyectos, es un paquete de proyectos que tienen objetivos en común, generalmente de facturación de la empresa. Aunque podrían ser otros: como proyectos de desarrollo interno (formación) o mejora (implantación de sistemas), etc.
Como vimos en la entrada «Diseñar una estructura orientada a documentos«, las posibilidades de organización son muy variadas: por clientes, por localización, por fases, por estados, etc.
Tendrás que decidir qué opción te interesa más en función de tu sistema de trabajo.
Además de los documentos y los archivos de trabajo, los expedientes tiene datos asociados (como el nombre del cliente, o fechas, etc) y la estructura de carpetas no es el mejor sistema para buscarlos, por lo que no nos queda otra que apoyarnos en una aplicación complementaria.
¿Qué datos debes tener de un expediente?
De un expediente te puede interesar conocer:
- Fecha de creación y cierre.
- Localización (Municipio, provincia, etc).
- Datos del cliente.
- Datos de otros agentes intervinientes
- Datos sobre clasificación (residencial, …)
- Estado del expediente (abierto, en espera, en desarrollo, …)
- Presupuesto.
- Facturas recibidas y emitidas.
- Fases y tareas.
- Horas dedicadas.
- Y otros muchos datos asociados …
Como entenderás, toda esta gestión de datos no podemos realizarla a través de una estructura de carpetas.
Es decir, podemos organizar los expedientes por carpetas de cliente, de localización, por fechas, etc. Pero siempre nos faltarán carpetas para clasificarlos. Además, hay datos que son variables (como el estado del expediente) y no vamos a estar moviendo los expedientes de un sitio a otro.
Por lo tanto, lo más recomendable es tener estos datos en una aplicación aparte, que sea la que permita la estructura y análisis y dejando la localización en carpetas del expediente en una ubicación fija.
Entonces, ¿Cómo organizo los expedientes?
Si hay una cosa común a todos los sistemas es que vamos a necesitar un código y un nombre para referirnos al expediente. Y deberían ser únicos, al menos el código, de manera que no nos confundamos entre todos los expedientes.
Podemos tener la tentación de introducir datos dentro del código. Por ejemplo:
- Una o dos letras para referirnos a la provincia (SE para Sevilla, MA para Málaga, M para Madrid) del proyecto,
- o dos números para referirnos al año (19, 20, …),
- o un código de tres letras para referirnos al tipo de proyecto (APE para licencia de aperturas, RES para residencial, etc.),
- o tres letras para el cliente.
El objetivo de este código es que sea ÚNICO y que no haya otro expediente con el mismo código. Por lo que al final, de una u otra forma, habrá que añadirle un número. Este podrá ser consecutivo desde el origen o vinculado a algún dato de los anteriores. Como por ejemplo el año: 2019/01 (primer expediente de 2019).
A mí particularmente no me parece el mejor sistema y creo que, si partimos de la base de que tenemos una aplicación, base de datos o sistema dónde almacenar, clasificar y analizar los datos del cliente, localización, etc, no necesitamos complejizar el código.
Además, ¿para qué quieres saber el año del proyecto en el código? Si el proyecto comienza en noviembre del 2019 y después se paraliza hasta mayo del 2020 y se termina en febrero del 2022 ¿Para qué quieres arrastrar el «19» en el número del expediente? ¿Podrías decir que es un expediente de 2019 si no se dedicaron horas en ese año?
¿Para qué te va a servir el código de expediente?
Este código te va a servir para asociar datos al expediente y poder realizar análisis o filtros de datos.
Pero no tienes porqué usar el código para hacer los análisis. Por ejemplo, para saber cuantos proyectos arrancaron en 2019, o en qué provincia se hacen más proyectos, o qué cliente deja el mejor rendimiento no vas a usar el código como elemento de categorización. Es mejor realizar este análisis partiendo del campo apropiado.
A modo de ejemplo, yo uso el sistema que creo más sencillo y eficiente. Que es un código numérico de 4 cifras consecutivo desde el origen. De manera que el 0000 es el expediente «empresa» y el 0001 el primer expediente que hicimos en el estudio (desde que comenzamos con el sistema) y así consecutivamente.
Cada expediente, desde la fase de estudio, le asigno un código (y también un nombre, aunque este puede cambiar una vez tengamos más información) y ese código lo pongo al principio de todos los archivos del expediente y dentro en todos los documentos que tengan que ver con él: desde documentos del proyecto, facturas, etc.
No le añado nada más, ni fecha de apertura, ni localización, ni código de cliente, etc. No hace falta. Para saber de qué expediente estoy hablando simplemente sé que es el 0237.
¿Y entonces, cómo sé en que año comenzó el proyecto, o qué cliente tiene?
Pues lo miro en un programa de gestión de portfolios en el que, además de estos datos, tengo otros muchos datos necesarios para la buena marcha del expediente y la gestión del proyecto.
¿Qué aplicaciones tengo para organizar el portfolio?
Para esto tenemos muchas herramientas. Unas más sencillas que otras, otras más económicas que otras, algunas con más funcionalidades, pero en casi todas podemos hacer una buena gestión de los expedientes:
- Excel
- Trello
- Asana
- Gestproject
- …
En todas estas aplicaciones podemos llevar un listado organizado de datos y para que veáis cómo funcionan y cual se adapta mejor a vuestras necesidades vamos a repasar una por una en próximas entradas.
Lo que vamos a hacer es analizar que se puedan poner las siguientes características:
- Código (número de 4 cifras consecutivo)
- Nombre (nombre identificativo)
- Tipo (Informes, Proyectos, Licencia de aperturas, Adecuación de local, etc.).
- Uso (residencial, comercial, administrativo, educativo, etc.).
- Situación (Aceptado, rechazado, pendiente).
- Progreso (Sin comenzar, en desarrollo, parado, terminado)
- Descripción (Breve descripción del proyecto).
- Dirección (calle, municipio, provincia y CP del inmueble)
- Fechas (de inicio y final)
- Cliente (nombre, dni, dirección, teléfono y email)
- Presupuesto (realizado, aprobado)
- Ingresos (realizada, pendiente)
- Costes (realizados, pendientes)
- Beneficio (restando los anteriores)
- Horas dedicadas
- Ratio €/h
Se pueden tener muchos otros datos, pero con estos son por ahora suficientes para hacernos una idea del potencial de esta gestión.
Interesante introducción al tema. Espero ver el desarrollo. Viendo un ejemplo también ayudaría a entenderlo quizás algo más.
Yo estoy usando EVERNOTE para almacenar toda la documentación del proyecto y tengo una NOTA de EXPEDIENTE principal a la que añado todos los datos y voy referenciando las notas que voy creando de planos, correcciones, facturas, documentos..
Muchas gracias por tu comentario.
El problema que veo, de este sistema en EVERNOTE, es que no te permite analizar costes de expedientes tipo Licencias de apertura, o la relación costes beneficio de los proyectos de un cliente concreto.
Estoy preparando sesiones de video para explicar cómo lo organizo yo.