La automatización no corrige una operación que nadie entiende
Una solicitud entra por correo, cambia de responsable en un chat y termina en una hoja de cálculo. La empresa quiere automatizarla, pero nadie puede explicar quién autoriza cada paso ni qué ocurre cuando falta información. Encargar una herramienta en ese momento no resuelve la duda: obliga a alguien a convertirla en una regla del sistema.
La herramienta termina tomando decisiones que la empresa no tomó
En muchas organizaciones, el trabajo sale adelante gracias a acuerdos que nunca quedaron escritos. Una persona revisa los datos antes de enviarlos; otra sabe a quién consultar cuando falta una autorización; alguien más corrige errores que no aparecen en los reportes. Estas intervenciones pueden ser eficaces, pero también revelan cuánto depende el resultado del conocimiento individual y de decisiones tomadas sobre la marcha.
Al diseñar una automatización, esos acuerdos dejan de ser invisibles. Hay que definir qué información permite avanzar, quién tiene autoridad para aprobar, cuándo se detiene un caso y quién responde por una excepción. Si la empresa no resuelve estas preguntas, el equipo que configura o desarrolla la herramienta tendrá que interpretarlas. Así, una decisión de negocio puede quedar incorporada al producto sin que sus responsables la hayan discutido.
“La automatización no decide por una empresa: ejecuta las reglas que alguien definió, incluso cuando nadie advirtió sus consecuencias.”
Puedes escuchar este artículo aquí:
El recorrido real importa más que el procedimiento ideal
Imaginemos una empresa que recibe solicitudes de compra. El procedimiento indica que cada responsable aprueba los pedidos de su área. En la práctica, algunos casos requieren confirmar presupuesto, otros dependen de la disponibilidad de un proveedor y los urgentes se resuelven mediante llamadas. Si la instrucción para crear una plataforma se limita a «agilizar las aprobaciones», la pantalla podrá quedar clara mientras el criterio para aprobar sigue siendo ambiguo.
Por eso hace falta mirar el trabajo desde la solicitud hasta su resolución, incluidas las personas, los datos y los cambios de canal que intervienen. La guía de diseño de servicios del Gobierno del Reino Unido recomienda comprender tanto el recorrido de quien utiliza un servicio como los procesos internos y sus responsables. Lo que ocurre entre áreas puede explicar una dificultad que no se aprecia al observar una sola tarea.
Comprender el recorrido tampoco significa asumir que todos los pasos actuales deben conservarse. Algunas verificaciones protegen una decisión necesaria; otras existen porque nadie recibe información confiable a tiempo. Antes de llevarlas a una app, la dirección debe distinguir cuáles aportan valor, cuáles pueden simplificarse y cuáles requieren una persona con autoridad para actuar.
Automatizar exige hacerse cargo de las excepciones
Es fácil diseñar el caso habitual: llega una solicitud completa, la persona indicada la aprueba y el sistema envía una confirmación. La calidad de la operación se pone a prueba cuando falta un documento, hay dos responsables posibles o la aprobación se retrasa. En esas situaciones, una alerta automática sirve de poco si nadie sabe quién debe intervenir ni con qué criterio.
La explicación de IBM sobre automatización de procesos señala que estas soluciones pueden coordinar tareas entre áreas y sistemas, pero que la documentación insuficiente y la coordinación entre personas y herramientas plantean dificultades. La implicación editorial es clara: definir responsables y criterios de resolución forma parte del proyecto, aunque no se vea en la interfaz final.
“Una excepción sin responsable no desaparece al digitalizarse; encuentra una nueva forma de quedarse pendiente.”
Puedes ver este artículo aquí:
Primero comprender; después elegir la tecnología
Examinar la operación permite tomar una decisión más precisa. Una tarea repetitiva, con información disponible y reglas estables, puede ser buena candidata para automatizarse. Otra quizá necesite corregir un traspaso entre equipos, aclarar quién tiene autoridad o probar una herramienta existente antes de justificar un desarrollo propio. La respuesta no tiene por qué ser la misma para todo el proceso.
Los registros de actividad pueden ayudar a contrastar el procedimiento declarado con el recorrido real. La documentación de Microsoft sobre minería de procesos describe su uso para visualizar cómo se ejecuta un proceso e identificar oportunidades de mejora. Esa evidencia resulta útil cuando existen datos adecuados, pero debe completarse con la explicación de quienes realizan el trabajo: un registro muestra qué pasó; no siempre revela por qué se tomó una decisión.
Pedir claridad antes de invertir no es frenar la innovación. Es asumir la responsabilidad de definir qué debe mejorar y quién responderá cuando el caso no siga el camino previsto. Una herramienta puede dar rapidez y visibilidad a una operación comprendida; si las decisiones siguen pendientes, habrá que resolverlas después dentro de un sistema ya construido.
Antes de encargar una automatización, ¿tu equipo puede explicar quién decide, con qué información y cómo se resuelve una excepción? ¿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
#Automatización #OperaciónDigital #ProcesosDigitales #DiseñoDeProductosDigitales #IdeasAntesDelCódigo #CriterioZorr
Comentarios