Mapear los procesos de una empresa antes de desarrollar software consiste en dibujar cómo se trabaja hoy (as-is), medir dónde se pierde el tiempo y acordar cómo se trabajará con el sistema nuevo (to-be). Se hace con entrevistas a quien ejecuta cada paso, un diagrama BPMN sencillo y datos reales de tiempos. Es el primer entregable de cualquier proyecto de desarrollo de software a medida para procesos en Madrid.
Sin ese mapa, el equipo de desarrollo programa lo que le cuentan en una reunión, que rara vez coincide con el día a día. Las excepciones aparecen a mitad del proyecto y la aplicación reproduce en pantalla los atascos que había en papel. Por eso conviene preguntar cómo se hace este trabajo al elegir una consultoría de procesos y software a medida en Madrid.
Al terminar sabrás cómo preparar las entrevistas, dibujar un mapa que entiendan tanto tu equipo como el de desarrollo, encontrar el cuello de botella con datos y qué documentos entregar para que el presupuesto del software que vas a encargar sea fiable.
Qué es mapear los procesos de una empresa
Mapear un proceso es describir, de principio a fin, la secuencia de pasos que convierte una entrada en un resultado: un pedido en una entrega, o una factura recibida en un pago. El mapa recoge quién hace cada paso, con qué información, en qué sistema y cuánto tarda, incluidas las esperas entre un paso y el siguiente.
La notación más extendida es BPMN, cuya versión 2.0.2 publicó el Object Management Group en enero de 2014. La especificación BPMN del OMG la presenta como un estándar para quienes diseñan y gestionan procesos, lo bastante preciso para traducirse a software. Para un proyecto de digitalización de procesos de empresa en Madrid basta con una parte pequeña de la notación.
Lo mínimo de BPMN que necesitas
- Eventos de inicio y fin: círculos que marcan qué dispara el proceso y cuándo se da por terminado.
- Tarea: un rectángulo con un verbo y un objeto, por ejemplo «Validar crédito».
- Compuerta: un rombo donde el flujo se divide según una condición, como un importe superior a un límite.
- Carriles: franjas horizontales, una por rol o departamento, que dejan ver cada traspaso de trabajo.
- Objeto de datos: el documento o registro que entra o sale de una tarea.
Con esas piezas se dibuja casi cualquier proceso administrativo, en una pizarra o una herramienta gratuita. Lo importante es revisarlo con quien hace el trabajo, igual que se revisa un prototipo en Figma antes de programar.
Paso 1: elegir el proceso y sus límites
Empieza por un proceso, no por toda la empresa. Elige el que más duele, el que genera más horas extra o más errores, y fija dónde empieza y dónde acaba. «Del pedido recibido al pedido entregado y facturado» es un buen límite; «la gestión comercial» es demasiado amplio. Si ese proceso vive hoy en hojas de cálculo, revisa también cuándo compensa llevar un Excel a una aplicación web.
Paso 2: entrevistas con quien ejecuta cada paso
La dirección sabe cómo debería funcionar el proceso; quien lo ejecuta sabe cómo funciona. Entrevista por separado a una persona de cada rol, en su puesto y con su pantalla delante, y pídele que te enseñe un caso real de la última semana. Es la misma observación que hacemos antes de diseñar aplicaciones móviles para procesos internos. Pide que te cuente:
- Disparador: qué le avisa de que tiene trabajo y por qué canal llega.
- Información: qué datos necesita, de dónde los copia y qué hace si faltan.
- Decisiones: qué comprueba antes de pasar el trabajo y quién decide en caso de duda.
- Excepciones: qué casos se salen de la norma y con qué frecuencia aparecen.
- Esperas: a quién o a qué espera y cuánto suele durar esa espera.
- Herramientas paralelas: hojas de cálculo, notas o correos que usa para no perder el hilo.
Las excepciones y las herramientas paralelas son las respuestas más valiosas. Un Excel personal con el que alguien controla los pedidos urgentes es una función que el software nuevo tendrá que cubrir, y si nadie lo menciona aparecerá a mitad de proyecto, con impacto en los plazos reales del desarrollo.
Apunta también qué datos personales pasan por cada paso. El mapa debe coincidir con el registro de actividades de tratamiento que exige el artículo 30 del RGPD; la exención para organizaciones de menos de 250 empleados no se aplica, entre otros casos, cuando el tratamiento no es ocasional.
Paso 3: dibujar el as-is
El as-is es el mapa del proceso tal como funciona hoy, con sus rodeos. Dibuja los carriles por rol, coloca las tareas en el orden real y marca en otro color cada traspaso entre personas o sistemas, porque ahí se concentran las esperas y los errores de copia. Si un paso se resuelve con un correo reenviado o un dato que se teclea dos veces, va al mapa tal cual: son los puntos donde un buen backend con su lógica de datos ahorra más trabajo.
Valida el mapa con las mismas personas hasta que nadie añada casos nuevos, y guarda cada versión con fecha, igual que el código revisado en un pull request, porque vas a compararla con el to-be.
Paso 4: medir y encontrar el cuello de botella
Un mapa sin tiempos no dice dónde se pierde el dinero. El dato que más se olvida es la espera: el tiempo que un caso pasa parado entre que termina un paso y empieza el siguiente. Es habitual que cada tarea dure minutos y el caso tarde días porque espera una aprobación, un dato de otro departamento o a que alguien revise su bandeja, algo que un panel de administración con colas de trabajo hace visible.
Si tus sistemas guardan la fecha y la hora de cada paso, puedes calcularlo sin encuestas. Es la idea de la minería de procesos, que el manifiesto del IEEE Task Force on Process Mining presenta como una herramienta para mejorar el rediseño, el control y el soporte de los procesos operativos. Para un primer diagnóstico no hace falta una plataforma: basta con exportar los pasos a un CSV.
CodeZone Pro Tip: calcula la espera entre pasos con el registro de eventos y el cuello de botella aparece solo
# Detecta el cuello de botella de un proceso a partir de su registro de eventos
# CSV con columnas: caso,paso,inicio,fin (fechas ISO, una fila por paso ejecutado)
import csv, sys
from collections import defaultdict
from datetime import datetime
from statistics import median
def horas(a, b): # diferencia en horas entre dos marcas de tiempo ISO
return (datetime.fromisoformat(b) - datetime.fromisoformat(a)).total_seconds() / 3600
casos = defaultdict(list)
with open(sys.argv[1], newline="", encoding="utf-8") as f:
for fila in csv.DictReader(f):
casos[fila["caso"]].append(fila)
espera, trabajo = defaultdict(list), defaultdict(list)
for pasos in casos.values():
pasos.sort(key=lambda p: p["inicio"]) # orden real de ejecución del caso
for anterior, paso in zip([None] + pasos, pasos):
trabajo[paso["paso"]].append(horas(paso["inicio"], paso["fin"]))
if anterior: # espera = hueco desde que acabó el paso previo
espera[paso["paso"]].append(horas(anterior["fin"], paso["inicio"]))
print(f"{'paso':<22}{'casos':>6}{'espera med. h':>15}{'trabajo med. h':>16}")
for nombre in trabajo:
e = median(espera.get(nombre, [0.0])) # el primer paso no tiene espera previa
print(f"{nombre:<22}{len(trabajo[nombre]):>6}{e:>15.1f}{median(trabajo[nombre]):>16.1f}")
cuello = max(espera, key=lambda n: median(espera[n])) # la cola más larga, no el paso más lento
print(f"\nCuello de botella: '{cuello}' (espera mediana {median(espera[cuello]):.1f} h)")El script ordena los pasos de cada caso, separa el tiempo de trabajo del tiempo de espera y señala el paso con la espera mediana más alta. En un ejemplo hipotético de pedidos, aprobar un descuento ocupa cinco minutos, pero los pedidos esperan una mediana de 33,5 horas a que alguien lo haga, así que acelerar la preparación del envío no acortaría nada. La mediana evita que un caso extraordinario distorsione el diagnóstico, y el resultado te dice dónde invertir antes de calcular el coste de automatizar procesos con IA en Madrid.
Paso 5: diseñar el to-be
El to-be es el proceso como funcionará con el software nuevo. Se diseña sobre el as-is medido y empieza por el cuello de botella: una aprobación que puede resolverse con una regla, o un dato que se puede pedir una sola vez. Antes de automatizar un paso, comprueba si puedes eliminarlo, porque automatizar un paso inútil solo lo hace más rápido. Esta revisión es la base de cualquier proyecto para automatizar procesos con IA en Madrid.
En el to-be decide también qué hace cada sistema. Si el proceso cruza la gestión comercial y la financiera, tendrás que elegir entre adaptar un CRM comercial o construir el tuyo y qué parte vive en el ERP, que puede ser un ERP a medida con presupuesto por fases. Si el to-be se apoya en herramientas que ya pagas, revisa la comparación entre software propio y suscripciones SaaS con los números del mapa.
Qué entregar al equipo de desarrollo
El resultado del mapeo es un paquete de documentos que permite presupuestar y diseñar sin adivinar. Con él, cualquier estudio de software para procesos en Madrid puede estimar por funcionalidad y detectar riesgos antes de firmar:
- Mapas as-is y to-be: en BPMN básico, con carriles por rol y versión fechada.
- Catálogo de excepciones: cada caso fuera de la norma, con su frecuencia aproximada y quién lo resuelve hoy.
- Reglas de negocio escritas: límites de importe, condiciones de aprobación y cálculos de precios o plazos.
- Inventario de datos y sistemas: qué información usa cada paso, dónde está hoy y quién la mantiene.
- Métricas de partida: tiempo total por caso, esperas por paso y tasa de errores, para medir la mejora después.
- Prioridades: qué parte del to-be es imprescindible en la primera versión y qué puede esperar.
El inventario de datos será también la base de la migración de los datos al sistema nuevo, y las métricas de partida te permitirán demostrar el retorno cuando el software esté en marcha. Si el proceso llega a tus clientes, añade sus puntos de contacto, que condicionan el portal privado donde consultan su información.
Errores habituales al mapear procesos
Son los fallos que más vemos cuando una empresa nos trae un mapa ya hecho, y casi todos se pagan después en forma de cambios durante el desarrollo de aplicaciones de gestión a medida:
- Mapear el proceso ideal: el del manual de calidad, en lugar del que se ejecuta.
- Entrevistar solo a responsables: quien aprueba no ve las esperas; quien ejecuta, sí.
- Dibujar con demasiado detalle: si el mapa no cabe en una pared, divídelo en subprocesos.
- Olvidar el final: el proceso acaba cuando el resultado llega al cliente y está facturado.
El Coste de Programar un Proceso que Nadie Ha Dibujado
Cada hora de mapeo ahorra cambios de alcance durante el desarrollo, y en nuestra experiencia esos cambios son la principal fuente de desvíos en un proyecto a medida. Un mapa medido también protege la inversión después: con las métricas de partida sabes si el software ha reducido las esperas y puedes planificar el mantenimiento del software de procesos en Madrid sobre datos.
En Codezone empezamos cada proyecto con este mapeo y lo convertimos en el software que tu equipo necesita. Cuéntanos qué proceso quieres digitalizar y te ayudamos a dibujarlo y medirlo antes de escribir una línea de código; puedes ver el resultado en los proyectos de gestión de nuestro portfolio.
