Cómo levantar un proceso AS-IS paso a paso

Qué es un proceso AS-IS y para qué sirve

AS-IS significa “como es”. Describe el funcionamiento actual de un proceso dentro de un alcance acordado. Su propósito es crear una línea base común para comprender resultados, responsabilidades, interdependencias y variaciones antes de proponer cambios.

La representación puede ser una tabla, un mapa simple, un diagrama BPMN o una combinación. El formato depende de la pregunta. Lo indispensable es que el contenido refleje el trabajo real y pueda rastrearse a entrevistas, documentos, registros u observación.

Diferencia entre proceso declarado y proceso real

El procedimiento puede indicar cómo debería ejecutarse una actividad, mientras la práctica incorpora atajos, esperas, controles informales y excepciones. Ninguna fuente aislada describe todo. El levantamiento contrasta lo normado, lo narrado y lo observado.

Una diferencia no implica automáticamente incumplimiento. Puede revelar una regla obsoleta, una necesidad no prevista o una adaptación legítima. El análisis debe registrar la brecha antes de juzgarla.

Cuándo no conviene empezar dibujando BPMN

BPMN 2.0.2 es una notación formal útil para representar eventos, actividades, decisiones y participantes. Sin embargo, dibujar símbolos demasiado pronto puede centrar la conversación en la notación y no en el proceso. Primero construya una secuencia sencilla y confirme alcance, actores y evidencias.

Preparación del levantamiento

Definir propósito, alcance, inicio y fin

Explique para qué se levanta el proceso: reducir tiempos, entender controles, preparar requisitos o evaluar una automatización. Defina el evento inicial y el resultado final. “Gestión de compras” es demasiado amplio; “desde la recepción del requerimiento completo hasta la emisión de la orden” es verificable.

Registre exclusiones. Un alcance explícito evita que cada participante describa un proceso diferente y permite identificar dependencias que quedarán para otro análisis.

Identificar propietario, participantes y usuarios

El propietario responde por el resultado o por mantener la definición del proceso. Los participantes ejecutan actividades; los usuarios reciben o experimentan el servicio. Incluya áreas externas cuando aporten evidencia, autoricen o reciban resultados.

No limite el levantamiento a jefaturas. Quienes ejecutan casos diarios conocen excepciones y transferencias que no aparecen en informes.

Reunir normas, formatos, registros y sistemas

Solicite procedimientos, formatos, reglas, matrices, correos tipo, reportes, indicadores, tickets y muestras anonimizadas. Para cada fuente registre versión, vigencia, propietario y restricción de acceso.

Prepare una matriz de evidencias para distinguir afirmaciones confirmadas, pendientes y contradictorias. Esto evita convertir recuerdos en hechos.

Técnicas para obtener evidencia

Entrevistas y talleres

Use entrevistas para comprender responsabilidades, decisiones y casos concretos. Pregunte “muéstreme el último caso” en lugar de “¿normalmente qué hacen?”. Los ejemplos reducen respuestas idealizadas.

Los talleres sirven para contrastar versiones y ordenar la secuencia. No deben sustituir conversaciones individuales cuando existe jerarquía, conflicto o conocimiento especializado.

Observación del trabajo

Observe cómo una persona recibe, interpreta, registra y transfiere un caso. Anote herramientas, interrupciones, búsquedas, duplicaciones y decisiones. Pida permiso y proteja información sensible; el objetivo es comprender el sistema, no evaluar desempeño personal.

Revisión documental y análisis de datos

Los registros permiten contrastar frecuencia, volumen y tiempos. Verifique qué representa cada marca temporal: creación, envío, recepción o cierre. Un dato disponible no siempre mide lo que su nombre sugiere.

La guía de servicios de GOV.UK recomienda combinar la perspectiva interna con el recorrido del usuario. Para procesos que cruzan áreas, mapear contactos y evidencias del usuario ayuda a detectar puntos muertos que un flujo interno puede ocultar.

Documentar el proceso actual

Actividades, decisiones y excepciones

Escriba actividades con verbo y objeto: “revisar integridad del expediente”. En decisiones, documente condición y posibles salidas. No oculte excepciones en una nota general; pueden explicar gran parte del tiempo y riesgo.

Roles, transferencias y responsabilidades

Marque cada transferencia entre personas, áreas o sistemas. Es frecuente que el problema no esté dentro de una tarea sino en la espera, pérdida de contexto o duplicación que ocurre entre responsables.

Documentos, datos y sistemas

Relacione cada actividad con sus entradas y salidas. Identifique cuál fuente es oficial, dónde se conserva la versión y qué datos se copian manualmente. Evite asumir que dos campos con el mismo nombre significan lo mismo.

Tiempos, controles y puntos de espera

Separe tiempo de trabajo, espera y retrabajo. Registre rangos y casos extremos, no solo promedios. En controles, explique objetivo, responsable, evidencia y reacción ante un hallazgo.

Validar el AS-IS con quienes ejecutan el trabajo

Contrastar variaciones y desacuerdos

Presente el mapa como hipótesis. Recorra al menos un caso normal y uno excepcional. Cuando existan versiones distintas, identifique si corresponden a sedes, tipos de caso, periodos o interpretaciones diferentes.

No fuerce un consenso artificial. Documente la variante y quién puede resolverla. La incertidumbre visible es más útil que un diagrama limpio pero falso.

Cerrar hallazgos y dejar trazabilidad de cambios

Registre fecha, participantes, versión, comentarios y decisiones. Un AS-IS se vuelve obsoleto; debe indicar su corte temporal y responsable de actualización.

Analizar problemas sin saltar a la solución

Cuellos de botella, reprocesos y causas

Describa el problema como diferencia entre resultado esperado y observado. “Falta un chatbot” no es problema; “las consultas esperan dos días porque la información está distribuida y no existe responsable de respuesta” sí permite investigar causas.

Diferencie síntoma, causa y consecuencia. Una aprobación lenta puede originarse en expedientes incompletos, asignación tardía o autoridad poco clara. Cada causa exige una intervención diferente.

Riesgos y oportunidades de mejora

Valore frecuencia, impacto y capacidad de detección. Identifique primero mejoras de proceso, información y responsabilidad. La automatización o IA solo debe evaluarse después de comprender qué parte es estable y qué error debe controlar.

Ejemplo aplicado: solicitud administrativa

Ejemplo completamente simulado. Una oficina recibe solicitudes por correo y mesa de partes. Un analista registra datos en una hoja, revisa anexos y solicita subsanación cuando falta información. Los casos completos se envían por correo al especialista; el seguimiento depende de carpetas personales.

El levantamiento identifica dos variantes de ingreso, tres copias del mismo dato, ausencia de estado único y esperas sin alerta. La primera mejora no es incorporar IA: es definir entrada válida, registro central, estados, responsable y evidencia de transferencia. Después puede evaluarse automatización para validaciones y alertas. La IA solo sería candidata para una tarea delimitada de extracción documental con revisión.

Entregables mínimos de un levantamiento AS-IS

• Ficha de propósito, alcance, inicio, fin y propietario.
• Mapa de actores, usuarios y dependencias.
• Inventario de documentos, datos, sistemas y normas.
• Flujo validado con actividades, decisiones y excepciones.
• Matriz de roles y transferencias.
• Línea base de volumen, trabajo, espera y reproceso.
• Inventario de controles y riesgos.
• Lista de problemas con evidencia y causas por confirmar.
• Registro de versiones, validadores y desacuerdos.
• Preguntas abiertas para el diseño TO-BE.

Checklist de validación

• ¿El alcance tiene inicio, fin y exclusiones?
• ¿El resultado y usuario están identificados?
• ¿Participaron quienes ejecutan el proceso?
• ¿Se contrastaron procedimiento, práctica y registros?
• ¿Cada decisión muestra condición y responsable?
• ¿Las excepciones relevantes están visibles?
• ¿Se distinguen trabajo, espera y retrabajo?
• ¿Documentos y datos tienen fuente y versión?
• ¿Los controles indican evidencia y reacción?
• ¿El mapa fue recorrido con casos reales o anonimizados?
• ¿Los desacuerdos y límites quedaron registrados?
• ¿La solución futura se mantuvo fuera del levantamiento?

Preguntas frecuentes

¿Cuántas entrevistas son necesarias?

No existe un número universal. Incluya los roles que ejecutan, deciden, reciben y controlan, y continúe hasta comprender las variantes relevantes. Un proceso pequeño puede requerir pocas conversaciones; uno transversal necesita varias perspectivas.

¿Siempre se necesita BPMN 2.0?

No. Una tabla o mapa sencillo puede bastar para alcance y diagnóstico. BPMN aporta precisión cuando debe comunicarse lógica, participantes y eventos de forma estándar, pero exige conocimiento de la notación y propósito claro.

¿Qué hacer cuando cada área describe un proceso distinto?

No elija una versión por mayoría. Separe variantes, contraste evidencia y determine qué autoridad puede resolver la definición. Las diferencias pueden revelar procesos realmente distintos o una falta de gobierno.

Fuentes y fecha de revisión

Revisión editorial: 21 de julio de 2026. Esta guía presenta un método general; cada organización debe adaptarlo a sus normas, riesgos y gobierno de información.

• Object Management Group — BPMN 2.0.2.
• ISO — enfoque por procesos y mejora continua.
• GOV.UK Service Manual — mapear el problema completo del usuario.
• GOV.UK Service Manual — creación de mapas de experiencia.