La aplicación es una posibilidad. El punto de partida es el proceso.
Un equipo recibe solicitudes por correo, anota información en Excel y consulta el estado de cada caso en varios mensajes. Cuando aparecen errores y retrasos, surge una propuesta: «Necesitamos una aplicación». La idea puede tener sentido, pero todavía falta explicar qué falla, cuánto afecta al trabajo y por qué ocurre.
La digitalización de procesos resulta más fácil de orientar cuando separas el problema de la solución propuesta. Este recorrido te ayuda a describir la situación actual, investigar las causas y decidir qué necesidades debe cubrir un cambio. Puedes aplicarlo con registros sencillos y conversaciones con las personas que realizan el trabajo.
- 01Entender lo que ocurreProceso y problemas observables
- 02Fundamentar lo que necesitasObjetivos, causas y evidencias
- 03Elegir y comprobarAlternativas, acciones y resultados
Paso 01
Comprender el proceso actual
Escoge un tipo de solicitud y sigue varios casos reales de principio a fin, incluyendo alguno que haya dado problemas. Identifica cómo entran, quién interviene, qué decisiones se toman, qué herramientas se utilizan y cuándo consideráis que una solicitud ha terminado.
Distingue el tiempo de trabajo del tiempo de espera. Una solicitud puede requerir diez minutos de revisión y permanecer dos días pendiente de información. Anota también las excepciones: quién devuelve un caso incompleto, cómo se comunica una prioridad y dónde queda registrado un cambio.
Una descripción compartida del recorrido, sus responsables, decisiones y puntos de traspaso. Comprueba con quienes lo ejecutan que refleja el trabajo habitual y sus variantes.
Paso 02
Identificar y cuantificar problemas
Busca errores, tiempos de espera, solicitudes incompletas, retrabajos y falta de seguimiento. «Excel es un caos» expresa una percepción; «hay solicitudes cuyo estado nadie puede determinar» describe un problema que puedes investigar.
Para dimensionarlo, fija el periodo, el número de solicitudes revisadas y el criterio de medida. Cuenta cuántos casos afecta y, cuando sea posible, su impacto en tiempo, coste o plazo. Si varios problemas afectan a la misma solicitud, evita sumar sus contribuciones como si fueran casos distintos.
- Observación
- Qué has visto: una persona devuelve una solicitud porque falta información.
- Dato disponible
- Qué puedes medir: casos devueltos, total de solicitudes y tiempo empleado en corregirlos.
- Hipótesis
- Una explicación por contrastar: quizá las áreas interpretan de manera diferente qué información es obligatoria.
Cuando falten datos, registra esa ausencia y acuerda cómo recogerlos. Una estimación puede orientar la conversación si indicas de dónde sale; no la presentes como una medición.
Paso 03
Definir el resultado esperado
Concreta qué debe mejorar, para quién y en qué plazo. «Tener una aplicación» describe una entrega. «Reducir las devoluciones por información incompleta» describe un resultado del proceso.
Elige un indicador, una situación inicial y un objetivo cuya viabilidad revisaréis. Acuerda cómo se medirá y qué condiciones deben mantenerse, como el volumen atendido o la calidad de la respuesta. Así podrás comprobar después si el cambio mejora el problema que lo motivó.
Si entregáramos la aplicación y este indicador no mejorara, ¿consideraríamos resuelto el problema?
Paso 04
Investigar las causas
El correo y Excel son herramientas del proceso; su presencia no demuestra que sean la causa de los problemas. Las devoluciones podrían relacionarse con criterios poco claros, información que el solicitante desconoce o cambios en las necesidades de quien recibe el trabajo.
El análisis de causa raíz consiste aquí en investigar las explicaciones que pueden estar originando el problema, en lugar de quedarte en sus síntomas. Para cada hipótesis, pregunta qué evidencia la apoyaría, qué la contradiría y cómo podrías contrastarla con registros y observaciones.
Compara solicitudes completas e incompletas, revisa las instrucciones que recibieron sus autores y observa cómo se valida la información. Que dos hechos coincidan no basta para demostrar causalidad. Mantén la explicación como hipótesis mientras no dispongas de evidencia suficiente; puede haber varias causas relevantes.
Paso 05
Identificar necesidades y evaluar soluciones
Una necesidad explica qué debe permitir el proceso para mejorar. Por ejemplo, disponer de la información mínima antes de empezar una revisión. Un formulario con validaciones es una posible forma de cubrirla; también podrías aclarar los criterios y mejorar la plantilla actual.
Los siguientes vínculos son ilustrativos. Cada capacidad requiere evidencias sobre el problema y sus causas, y una comparación con otras alternativas antes de considerarla justificada.
Desplaza la tabla horizontalmente para leer las alternativas y sus condiciones.
| Problema | Posible capacidad | Qué contrastar antes de elegir |
|---|---|---|
| Solicitudes incompletas | Formulario con validaciones | Qué datos faltan, por qué y si se pueden aportar al iniciar la solicitud. Comparar con una plantilla e instrucciones más claras. |
| Distribución manual ineficiente | Reglas de asignación | Si las esperas se deben a la distribución y si hay criterios estables. Comparar con una responsabilidad de recepción bien definida. |
| Falta de trazabilidad | Estados e historial | Qué cambios necesitan registrarse, quién los consulta y quién actualizará la información. Comparar con un registro compartido sencillo. |
| Ausencia de seguimiento | Indicadores de gestión | Qué decisiones ayudarán a tomar, con qué datos y frecuencia. Comparar con una revisión periódica del registro existente. |
Algunas mejoras pueden resolverse modificando el proceso sin desarrollar software nuevo. Evalúa también el mantenimiento, la calidad de los datos y la facilidad de uso. Automatizar una actividad innecesaria puede conservar el problema en otra herramienta.
Paso 06
Priorizar y planificar
Separa las necesidades imprescindibles para alcanzar el objetivo de las mejoras que podrían esperar. Compara impacto esperado, esfuerzo, dependencias y riesgos; explicita qué parte de esa valoración sigue siendo incierta.
Para cada acción, concreta responsable, plazo, personas afectadas y modo de comprobación. Si necesitas criterios comunes antes de definir validaciones, resuelve esa dependencia primero. Una prueba acotada puede ayudarte a valorar una alternativa antes de extenderla, con un criterio claro para continuar, corregir o detenerla.
Paso 07
Comprobar resultados
Compara los indicadores antes y después de implantar los cambios, usando el mismo criterio de medida y periodos comparables. Revisa si han cambiado el volumen, el tipo de solicitudes u otras condiciones que puedan explicar parte de la diferencia.
Comprueba también los efectos no deseados. Reducir las solicitudes incompletas sirve de poco si las personas dejan de enviarlas porque el formulario es difícil de utilizar. Si el resultado no alcanza el objetivo, revisa las evidencias y las hipótesis; terminar el desarrollo no equivale a haber resuelto el problema.
Caso ficticio e ilustrativo · No es una experiencia real
De «queremos una aplicación» a un encargo con fundamento
Imagina un equipo que, en una semana de este escenario ficticio, recibe 100 solicitudes y devuelve 30 por falta de información. Dedica 10 horas a revisar y corregir solicitudes. Quiere estudiar si puede reducir esa dedicación a 6 horas semanales en ocho semanas, con un volumen comparable y sin empeorar la calidad.
- Situación inicial
- 10 h / semana
- Objetivo propuesto
- 6 h / semana
- Brecha
- 4 h / semana
Estos datos describen una brecha, pero no prueban qué la causa. El equipo plantea que los criterios de entrada podrían ser ambiguos. Para contrastarlo, acuerda revisar los datos ausentes, las instrucciones recibidas y el tiempo de corrección de cada caso. También comprobará cuánto contribuyen las devoluciones a esas diez horas.
Así cambia la conversación
«Hemos definido el problema de las devoluciones, el objetivo de dedicación y las necesidades que debemos evaluar: información mínima comprensible, un responsable de validación y un registro del estado de cada solicitud. Antes de encargar una aplicación, contrastaremos las causas y compararemos mejorar la plantilla actual con crear un formulario».
El resultado de este ejemplo es un análisis inicial y un plan de investigación. Las necesidades siguen pendientes de validación; no hay ahorro conseguido, funcionalidades aprobadas ni una especificación completa.
Una guía para trabajar el razonamiento
Cómo puede acompañarte POLARIS
POLARIS es un asistente de IA para analizar problemas mediante siete fases conversacionales. Puedes aportar el contexto de tu proceso, revisar con él qué sabes y qué necesitas investigar, definir objetivos y valorar propuestas de mejora.
- Comprender la necesidad
- Analizar la situación actual
- Definir el objetivo
- Investigar las causas
- Diseñar y evaluar soluciones
- Preparar la implementación
- Comprobar los resultados
Tú aportas y contrastas las evidencias, validas las hipótesis y decides qué acciones emprender. POLARIS puede ayudarte a estructurar las necesidades que vas identificando; no genera automáticamente una especificación funcional completa ni desarrolla o despliega aplicaciones.