Digitalizar no es acumular software, es ordenar decisiones
Una empresa puede sumar plataformas y seguir sin saber quién autoriza una solicitud, qué información es válida o cuándo termina un trabajo. Antes de invertir en otra herramienta, necesita aclarar las decisiones que sostienen su operación y que el software deberá facilitar.
Ventas tiene su sistema, administración trabaja en otra plataforma y el equipo coordina pendientes por mensajes. Hay tecnología disponible, pero para confirmar una entrega todavía es necesario llamar a tres personas. La información existe, aunque está repartida entre herramientas y conversaciones que cada área interpreta a su manera. Mientras tanto, el cliente espera una respuesta que nadie puede darle con certeza.
Digitalizar exige acordar qué se decide en cada paso, quién tiene autoridad para hacerlo, qué información necesita y qué sucede ante una excepción. Esa claridad permite evaluar si conviene aprovechar una herramienta existente, conectar sistemas o desarrollar un producto propio. Sin ella, una nueva compra puede añadir otro lugar donde capturar datos y conservar la incertidumbre que detiene el trabajo.
Puedes escuchar este artículo aquí:
Identifica la decisión que está deteniendo el trabajo
Imaginemos una empresa de mantenimiento que recibe solicitudes por WhatsApp, agenda visitas en una hoja de cálculo y factura desde un sistema administrativo. Su director propone crear una app porque algunos servicios se retrasan. Al revisar el recorrido, descubre que nadie ha acordado cuándo una solicitud está completa, quién confirma la disponibilidad del técnico ni quién puede aprobar un trabajo fuera del presupuesto.
Antes de definir funciones, conviene reconstruir qué pasó con las solicitudes recientes. ¿Faltaba información del cliente? ¿El técnico esperaba una autorización? ¿Ventas había prometido una fecha sin consultar disponibilidad? Cada respuesta conduce a una intervención distinta. Reunir todo bajo la etiqueta de falta de sistema impediría reconocer qué debe cambiar y quién necesita participar.
“Cada decisión que la empresa deja sin resolver termina convertida en una duda para quien usa el sistema.”
La app podría organizar solicitudes y enviar avisos, pero primero necesita una definición de lo que permite avanzar. Si una visita requiere autorización, hay que establecer quién la concede, con qué criterios y qué ocurre mientras llega. De lo contrario, el pendiente reaparecerá en pantalla, acompañado por una notificación que tampoco explica cómo resolverlo.
Acuerda las reglas antes de convertirlas en funciones
En esta empresa hipotética, recibir un mensaje no equivale a aceptar un servicio. Para asumir ese compromiso hacen falta datos suficientes, disponibilidad y una persona responsable de confirmarlo. También debe existir una respuesta cuando el cliente cambia el domicilio, falta una pieza o el técnico encuentra un problema distinto al reportado. Son situaciones que el producto deberá contemplar desde su definición.
El estándar de servicios de GOV.UK propone diseñar alrededor de las necesidades de las personas y evitar que una tecnología elegida de antemano determine la solución. Aunque está dirigido a servicios públicos británicos, ofrece un criterio útil para esta discusión: comprender el problema completo antes de seleccionar la herramienta que atenderá una parte de él.
Para la empresa de mantenimiento, eso significa acordar qué representa cada paso. Una solicitud recibida puede estar pendiente de revisión; una visita confirmada debe expresar un compromiso concreto. Si ventas, operaciones y el cliente entienden algo distinto por confirmado, el diseño necesita resolver esa diferencia antes de mostrar una etiqueta o activar un aviso.
El punto de partida es la tarea que una persona necesita completar. Desde ahí se puede definir qué información verá, qué acción podrá realizar y cómo sabrá que su intervención terminó. Las pantallas adquieren sentido cuando hacen comprensibles esos acuerdos.
Puedes ver este artículo aquí:
Relaciona la claridad con un resultado de negocio
Una interfaz ordenada puede facilitar el trabajo, pero el director necesita saber qué mejora justificaría la inversión. En nuestro ejemplo, sería útil observar cuánto tarda una solicitud en confirmarse, cuántas se devuelven por información incompleta y cuántas visitas deben reprogramarse. Estos indicadores propuestos permitirían dimensionar el problema y evaluar después la intervención.
Para elegirlos conviene escuchar tanto a quienes solicitan el servicio como a quienes lo prestan. La guía de investigación de GOV.UK recomienda estudiar el recorrido completo, incluidos los pasos fuera de línea y las personas que participan en la atención. Revisar solicitudes y conversar con clientes, administración y técnicos ayudaría a contrastar versiones del mismo proceso.
Así, el objetivo podría pasar de tener una app a conseguir que cada solicitud pueda confirmarse con información suficiente y una responsabilidad clara. Ese cambio de enfoque permite discutir funciones con un propósito: pedir un dato porque evita una devolución, mostrar disponibilidad porque permite comprometer una fecha o registrar una autorización porque condiciona el trabajo.
“Una decisión bien definida permite saber qué debe resolver la herramienta y cómo evaluar si funciona.”
Elige qué resolver antes de contratar otra herramienta
Ordenar decisiones tampoco exige resolver toda la empresa antes de avanzar. Conviene elegir un recorrido delimitado, como recibir y confirmar una solicitud, y aclarar sus vacíos principales. La intención es reunir información suficiente para evaluar una solución y reconocer qué supuestos todavía necesitan ponerse a prueba.
Antes de solicitar una propuesta, revisa cuatro puntos:
Problema observable: dónde se detiene el trabajo y qué evidencia lo muestra.
Responsabilidad: quién toma la decisión que permite continuar.
Información necesaria: qué datos deben estar disponibles y quién los valida.
Resultado esperado: qué mejora permitiría juzgar si la intervención funciona.
Con esas respuestas será más fácil valorar lo que ya existe. Quizá baste con configurar mejor una herramienta; quizá haga falta conectar sistemas o desarrollar algo específico. La fase de descubrimiento descrita por GOV.UK plantea precisamente comprender el problema, explorar alternativas y definir cómo se evaluará el resultado antes de comprometerse con la construcción.
En la empresa de mantenimiento, el avance tendría que verse en algo concreto: poder confirmar un servicio sin perseguir autorizaciones por mensajes y sin prometer una fecha que operaciones desconoce. Esa es la claridad que debe orientar el diseño, la cotización y el desarrollo. ¿Qué decisión sigue deteniendo el trabajo en tu empresa y debería quedar resuelta antes de sumar otra herramienta?
¿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 #DigitalizaciónConPropósito #ProductosDigitales #DiseñoDeExperiencia #ProcesosDigitales #ClaridadAntesDelCódigo #SeñorZorro
Fuentes
Comentarios