Cómo mapear un proceso antes de convertirlo en una herramienta digital


Una solicitud llega por correo, alguien la copia en una hoja de cálculo y otra persona pregunta por WhatsApp quién debe resolverla. Antes de convertir ese recorrido en una herramienta digital, hace falta entender qué ocurre, quién decide y dónde se detiene el trabajo.
Cuando una empresa decide digitalizar su operación, suele comenzar por imaginar funciones: un formulario, un tablero, notificaciones y un reporte. Sin embargo, esas funciones todavía no explican cómo se resolverá el trabajo. Si nadie sabe quién autoriza una solicitud incompleta o cuándo puede considerarse terminada, la interfaz heredará esas dudas. Mapear un proceso permite hacer visibles sus pasos, responsables, reglas y excepciones para decidir qué debe cambiar antes de desarrollar.
El resultado debe ser una representación que las personas involucradas puedan revisar y contrastar con su experiencia. Para dueños y directivos, su valor está en conectar la inversión con la forma en que se recibe, atiende y termina el trabajo: qué problema se resolverá, qué responsabilidad asumirá cada área y cómo se comprobará que la herramienta ayuda. Un mapa puede comenzar en papel; su utilidad depende de la claridad que produce.
Puedes escuchar este artículo aquí:
Delimita el proceso desde la necesidad hasta el resultado
Un mapa pierde utilidad cuando pretende describir toda la empresa. Conviene elegir un recorrido con un inicio reconocible y un resultado verificable. Gestionar solicitudes de mantenimiento, por ejemplo, puede comenzar cuando una persona reporta una falla y terminar cuando se confirma la reparación y queda registrada la evidencia del trabajo realizado. Recibir el reporte es apenas una parte del proceso; resolverlo exige coordinación posterior.
También hace falta precisar qué significa terminar. ¿Basta con que el técnico marque la tarea como realizada? ¿Debe validarla quien solicitó el servicio? ¿Qué ocurre cuando la reparación necesita una segunda visita? Estas preguntas delimitan el trabajo y evitan confundir una actualización de estado con un problema resuelto.
La guía de GOV.UK sobre mapas de experiencia propone observar el recorrido desde que surge una necesidad hasta que la persona deja de utilizar el servicio. Esa perspectiva ayuda a reconocer actividades, canales y dependencias que podrían quedar fuera si el análisis comenzara directamente en una pantalla. Antes de diseñar un formulario, hay que entender qué necesita resolver quien lo llena y qué debe suceder después de enviarlo.
Observa cómo se trabaja y contrasta las versiones
El procedimiento escrito y la operación cotidiana pueden contar historias distintas. Un manual puede indicar que todas las solicitudes llegan mediante un formato, mientras el equipo también recibe llamadas, fotografías y mensajes de clientes habituales. Esos caminos alternativos forman parte del proceso actual: hay que entender por qué existen antes de decidir cuáles conservar, corregir o eliminar.
Para construir el mapa, reúne a quienes solicitan, reciben, ejecutan, autorizan y supervisan el trabajo. Pídeles que reconstruyan casos recientes con los documentos y registros disponibles, protegiendo la información personal. Después, observa cómo realizan las tareas. La investigación contextual descrita por GOV.UK permite identificar barreras, herramientas utilizadas y soluciones improvisadas en el entorno donde ocurre la actividad.
Imaginemos una empresa de mantenimiento. La dirección cree que el retraso está en asignar técnicos, pero al revisar varias solicitudes descubre que algunas llegan sin ubicación o sin una descripción suficiente de la falla. El equipo debe completar esos datos antes de asignar el servicio. En este escenario hipotético, un tablero de asignaciones atendería solo una parte del problema: también habría que mejorar la recepción y definir quién solicita la información faltante.
“Lo que el equipo resuelve de memoria también forma parte del proceso que necesitas entender.”
Haz visibles los pasos, las decisiones y las esperas
Una forma accesible de empezar consiste en escribir cada actividad en una tarjeta y ordenarlas según ocurren. Utiliza verbos concretos: recibir solicitud, verificar datos, asignar responsable, realizar servicio y confirmar cierre. Después, distribuye las actividades por persona o área. Así aparecen los traspasos: momentos en los que alguien termina una acción y otra persona necesita recibir información suficiente para continuar.
Cada paso debe explicar qué recibe, quién lo realiza, qué decisión requiere y qué entrega al siguiente responsable. En la empresa del ejemplo, verificar una solicitud podría describirse así: la persona de recepción revisa ubicación, descripción de la falla y datos de contacto. Si falta información, solicita que se complete e indica qué dato necesita. Si está completa, la entrega a quien asigna el servicio. La actividad deja de depender de una interpretación individual.
Registra también las esperas y sus causas. Una solicitud puede detenerse porque falta un dato, porque nadie tiene autoridad para decidir o porque el responsable aún no la ha visto. Aunque las tres situaciones aparezcan como pendientes en un tablero, requieren respuestas diferentes. Si existen registros confiables, distingue el tiempo dedicado a realizar las tareas del tiempo transcurrido entre ellas; si no existen, señala qué necesitas medir.
Conviene distinguir las herramientas que pueden acompañar este trabajo. El mapa de procesos muestra cómo se organiza y ejecuta una actividad; el mapa de experiencia ayuda a entender lo que vive la persona durante el recorrido. Un service blueprint, o mapa del servicio, conecta esa experiencia con las personas, recursos y procesos que la sostienen. Nielsen Norman Group explica que esta última representación permite observar tanto las actividades visibles para el usuario como las que ocurren detrás de ellas. Elige el nivel de detalle que ayude a resolver tu problema.

Incluye las excepciones y separa lo actual de lo propuesto
El recorrido ideal resulta insuficiente para definir una herramienta. Una solicitud puede duplicarse, cancelarse o cambiar de prioridad; un responsable puede ausentarse; una autorización puede vencerse. El mapa debe mostrar cómo se atienden las excepciones relevantes, dando prioridad a las que aparecen con frecuencia o tienen consecuencias importantes para el servicio y la operación.
En el ejemplo de mantenimiento, asignar una visita no garantiza que el técnico pueda entrar al inmueble. Si no encuentra a la persona responsable, necesita registrar lo ocurrido y solicitar una nueva fecha. El cliente, por su parte, debe saber qué pasó y qué necesita hacer. Esa excepción conecta operación, comunicación y experiencia de uso: requiere responsables y acciones definidos para que el trabajo continúe.
Con el proceso actual documentado, prepara una versión propuesta y conserva ambas. Esto permite distinguir lo observado de los cambios que todavía deben validarse. Revisa si hay capturas repetidas, autorizaciones cuyo propósito nadie puede explicar o pasos que podrían simplificarse mediante un acuerdo entre áreas. La digitalización debe partir de decisiones explícitas sobre qué conservar, qué cambiar y qué dejar de hacer.
“Una regla sin resolver puede convertirse en una pantalla que nadie sabe cómo usar.”
Puedes ver este artículo aquí:
Valida el mapa antes de convertirlo en funciones
Antes de encargar el diseño, recorre el mapa con quienes harán el trabajo. Utiliza un caso habitual y otro con una excepción importante. Comprueba si cada participante puede explicar qué recibe, qué debe hacer, qué decisión le corresponde y cómo entrega el caso al siguiente responsable. Cuando aparezcan respuestas incompatibles, registra el desacuerdo y resuélvelo con quien tenga autoridad sobre el proceso.
Como revisión práctica, comprueba estas cuatro condiciones:
El inicio y el resultado final se pueden reconocer.
Cada actividad y decisión tienen un responsable definido.
Los traspasos incluyen la información necesaria para continuar.
Las excepciones prioritarias tienen una respuesta que permite corregir, continuar o cerrar el caso.

Después podrás definir qué debe permitir hacer la herramienta en cada paso: capturar información, consultar un estado, autorizar una acción, corregir datos o avisar a otra persona. Cada función debería responder a una tarea o decisión identificada. El mapa también ayuda a delimitar una primera etapa y elegir qué observar durante una prueba, como solicitudes devueltas por información incompleta o casos que necesitan reabrirse. La mejora deberá comprobarse con evidencia de uso.
El proceso está suficientemente claro para avanzar cuando sus responsables han validado el recorrido y los vacíos pendientes tienen una persona encargada de resolverlos. No hace falta eliminar toda incertidumbre, pero sí reconocer qué falta por decidir y cómo afecta al diseño. Un mapa útil permite encargar una herramienta con responsabilidades y resultados definidos, y detectar los problemas que necesitan acuerdos operativos antes de convertirse en funciones.
¿En qué paso de tu operación se pierde más tiempo: al recibir una solicitud, al pasarla a otra área o al confirmar que quedó resuelta? Comparte tu experiencia.
¿Tu idea necesita más claridad antes de convertirse en código? En Señor Zorro Estudio de diseño de productos digitales, te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo. Conoce más en www.srzorro.com.
Escrito por: Editorial
#IdeasAntesDelCódigo #ProcesosYOperaciónDigital #MapeoDeProcesos #DiseñoDeServicios #ProductosDigitales #ClaridadAntesDelCódigo #SeñorZorro
Fuentes
GOV.UK, Service Manual. Creating an experience map.
GOV.UK, Service Manual. Contextual research and observation.
Sarah Gibbons, Nielsen Norman Group. Service Blueprints: Definition.




Comentarios