Un cliente llama para cambiar la dirección de entrega de un pedido. Una persona del equipo encuentra el pedido, comprueba la solicitud, cambia la dirección y comunica al cliente lo ocurrido. Parece una sola tarea. ¿Cuántas herramientas hacen falta para terminarla?
Al definir un sistema interno de administración, empiece por una tarea como esta. Decida qué necesita ver esa persona, qué puede cambiar y cómo sabrá que el cambio se ha realizado. Así tendrá un encargo mucho más claro que una lista de paneles.
Elija una tarea que pueda seguir de principio a fin
Imagine un taller de reparaciones ficticio que devuelve a sus clientes los equipos reparados. Un cliente pide que le envíen su artículo a otra dirección. El taller guarda las órdenes de reparación en un sistema y organiza los envíos en otro.
En este ejemplo, el sistema de reparaciones guarda la dirección de devolución aceptada para ese pedido concreto. El servicio de expedición guarda la reserva del envío y confirma si todavía se puede cambiar. Actualizar los datos generales de contacto del cliente sería una decisión aparte.
Anote a qué sistema corresponde cada dato. Si dos pantallas muestran direcciones distintas, ¿en qué registro debe confiar el equipo y quién debe resolver la discrepancia? Mostrar ambas en una página no resuelve la cuestión.
La guía de Microsoft para crear aplicaciones basadas en modelos trata los datos, los procesos, las pantallas y los roles de seguridad como partes distintas del trabajo. Habla de Power Apps, pero deja una idea útil para planificar: elegir las pantallas es solo una parte de definir la tarea.
Dé a cada persona lo que necesita
Antes de diseñar el espacio de trabajo, defina los roles, las tareas y las acciones permitidas. Esta podría ser una distribución para nuestro taller ficticio:
Atención al cliente
Ve las solicitudes de cambio de dirección y el pedido correspondiente. Puede solicitar una corrección tras las comprobaciones necesarias del cliente. No puede marcar un paquete como redirigido.
Equipo de expedición
Ve los pedidos pendientes de envío y los cambios de dirección aceptados. Puede preparar un envío o atender un cambio fallido, según las reglas acordadas.
Responsable de operaciones
Ve las solicitudes sin resolver y cuánto llevan esperando. Puede asignar a alguien para gestionar una excepción. Este rol no tiene por qué permitir editar todos los pedidos.
Son responsabilidades propuestas, no una política de permisos ya definida. Sus normas pueden exigir autorización para ciertos cambios o limitar el acceso a determinados registros de clientes. Tanto los controles visibles como el sistema que acepta el cambio deben respetar esas normas.
El resumen de un responsable y la cola de trabajo de un empleado pueden estar en la misma aplicación y servir para fines distintos. Deje que la tarea determine la vista.
Siga la corrección de la dirección
Encuentre la solicitud. Coloque la solicitud de cambio en una cola con una persona responsable. Muestre a qué orden de reparación corresponde, cuándo llegó y si alguien ya la está atendiendo. Una nota escondida en el historial del cliente puede quedar sin resolver.
Compruebe qué se puede cambiar todavía. Muestre la dirección de devolución actual del pedido y el último estado conocido del envío. Indique de dónde proceden esos datos y cuándo se comprobaron. Si la información del envío no está disponible o es demasiado antigua, el equipo debe saberlo antes de prometer el cambio.
Haga el cambio permitido. Tras las comprobaciones del cliente y cualquier aprobación necesaria, una persona autorizada puede enviar la nueva dirección. El diseño debe explicar si esto actualiza la orden de reparación, solicita un cambio en un envío existente o hace ambas cosas en pasos distintos.
Un espacio de administración útil muestra qué hay que hacer, ofrece la información y los permisos necesarios, y confirma si la tarea se ha completado.
Espere la confirmación adecuada. Guardar una dirección en la orden de reparación no confirma que el servicio de expedición la haya aceptado. Muestre ambos resultados por separado. Una solicitud sin respuesta debe seguir pendiente, con información suficiente para explicar la situación al cliente.
Deje un historial útil. Defina qué hechos deben registrarse, por ejemplo, quién solicitó y aprobó la corrección, los valores anteriores y nuevos, y la respuesta del servicio de expedición. Decida quién puede consultar ese historial y cómo se revisará. Una pestaña de historial no indica por sí sola qué hechos contiene.
Asigne las excepciones a alguien. Si el paquete ya salió, el servicio de expedición rechaza el cambio o falla la conexión, asigne la solicitud sin resolver a una persona o equipo concreto. Explique qué debe comprobar antes de volver a intentarlo, para evitar acciones repetidas por una respuesta incierta.
Decida qué deben traducir las conexiones
Distintos sistemas pueden dar significados diferentes a un estado de pedido o una dirección. La guía de arquitectura de Microsoft sobre la traducción entre sistemas explica este problema y el trabajo necesario para mantener esa traducción. Describe un patrón técnico, no un componente que necesite todo sistema de administración.
Para el taller, la pregunta práctica es sencilla: ¿qué significa exactamente «cambiado» en cada sistema? Acorde los campos, los estados, las confirmaciones y la gestión de errores antes de dar por terminada la conexión. Un solo espacio de trabajo puede depender de varios sistemas que cumplen funciones distintas.
Convierta el recorrido en un encargo
Para cada tarea que quiera incluir, anote el rol, la cola de entrada, la fuente de los datos, la acción permitida, la confirmación, el historial y la persona responsable de las excepciones. Incluya el caso habitual y uno complicado, como un envío cuya dirección ya no se puede cambiar.
Creamos software empresarial a medida. Traiga un recorrido de la tarea que quiere que complete el equipo, incluida la parte que hoy se atasca. Así podremos hablar del alcance y las condiciones de un posible proyecto a partir de ese trabajo.
Preguntas sobre un espacio de administración compartido
¿Un solo espacio de trabajo implica sustituir todos los sistemas?
No. Puede reunir información y acciones de los sistemas existentes. Decida cuál conserva el registro aceptado para cada dato y cuál debe confirmar cada acción. Una vista compartida no resuelve esas decisiones por sí sola.
¿Todo el mundo debe ver los mismos controles?
Dé a cada rol la información y las acciones necesarias para su trabajo. Un responsable puede necesitar un resumen de tareas pendientes, mientras que atención al cliente necesita ver una solicitud concreta. Compartir el espacio no exige compartir todos los permisos.
¿Qué debe pasar si no se puede completar un cambio?
Mantenga visible la solicitud, con un estado claro y una persona o equipo responsable del siguiente paso. Explique qué se sabe, qué falta por confirmar y si es seguro volver a actuar. No muestre un cambio solicitado como completado antes de que el sistema responsable lo confirme.
