IoT en puertos
Mantén a tus amigos cerca, y a tus máquinas monitoreadas
El problema
Las oportunidades están ahí
Las charlas del Manager de Flux IT Ports con distintos clientes y agentes de la industria portuaria, sobre casos extraños y dolores que ellos revelaban en su trabajo, develaron algunas situaciones que detectó como oportunidades: entre ellas la necesidad de tener la ubicación de una máquina dentro de una terminal en tiempo real, e información relacionada, para aumentar el control sobre esta maquinaria. Profundizando en entrevistas, descubrimos que le debíamos sumar a esta última, información sobre operadores.
Con este escenario en mente, un equipo interdisciplinario de Flux IT dedicado a IoT, y conformado por: arquitectos de soluciones, desarrolladores de software, analistas UX, diseñadores UI, UI devs, diseñadores industriales e ingenieros en computación, se reunió para dar respuesta a este problema.
Entonces, ¿por qué IoT?
En su artículo Why the Internet of Things is the real deal , Waweru Mwaura explica que, para considerar que estamos utilizando IoT en un sistema, éste debe tener una red de dispositivos que usan sistemas embebidos conectados entre sí, debe compartir datos a través de la red y hacer uso de hardware que corra software que permita al dispositivo ser “apto IoT”.
La idea de esta tecnología es la multiplicación de la inteligencia en dispositivos por fuera de las computadoras, laptops y smartphones, y aplicarla a otros“no-inteligentes”. IoT convierte estos dispositivos a smart, añadiendo la capacidad de conectarse a la red, comunicarse y compartir datos.
Hay muchos beneficios que a simple vista pueden resultar útiles e interesantes de aplicar IoT en una terminal portuaria, añadiendo sensores y dispositivos a los tres tipos de máquinas de las que se quiere tener control: RTGs, Reach Stakers y Fork Lifts. Hablamos de comandar dispositivos a distancia, que éstos se interconecten entre sí, y que esa interconección les permita tomar decisiones por sí mismos. Así podríamos, por ejemplo, monitorear la actividad de una flota o de un vehículo en particular en tiempo real, mejorar el control y la gestión de estos.
La conectividad en sí misma no es nada; la solución holística es todo.
Para entender el entusiasmo del Manager de Puertos cuando nos presentó el escenario-problema, primero hay que tener claro que IoT no crea valor a ningún negocio solamente a través de la conexión, sino que se necesita el procesamiento de esa información recopilada.
El artículo ”Internet de la cosas” de Deloitte resulta muy útil para comprender que el valor para el negocio es creado cuando la información es utilizada para modificar acciones futuras de maneras beneficiosas. Idealmente, esta acción modificada genera y da acceso a nueva información, permitiendo que el proceso de aprendizaje continúe. La información, entonces, no crea valor de forma lineal (como un paso a paso de procesos), sino que se convierte en un proceso que nunca termina. En este cuadro, ellos describen las etapas que generan este loop:
Tres desafíos y obstáculos
- Marco operativo
En una de las visitas del equipo de Flux IT a una terminal portuaria, tuvimos la oportunidad de escuchar a los managers de esa y otras terminales de Latinoamérica (Argentina, Honduras y Colombia). El objetivo era encontrarnos con sus relatos, contrastarlos con la información que teníamos, y obtener nueva data.
Conversando sobre la situación y la posibilidad de intervenir la maquinaria, nos topamos con comentarios como este en relación al porcentaje de máquinas que fallan, incluso si son del que consideran el mejor proveedor que existe:
“Si le sumo un dispositivo, y este es bloqueante para el encendido del vehículo, a 1 de 10 obreros le va a fallar; y no es un costo que esté dispuesto a pagar.”
A partir de esta apreciación, nos empezamos a hacer algunas preguntas clave: ¿Hasta qué punto el producto que hagamos debe ser inmodificable? Estas restricciones, ¿rigen para todas las terminales? De no ser bloqueante, ¿aún así debería levantar alertas? ¿Estas alertas deberían ser monitoreadas on time?
2. Marco ético y sindicatos
Las organizaciones sindicales son extremadamente fuertes en esta industria, y son bastante celosas de brindar información de los operadores. Por ejemplo, un manager nos comentó que a su terminal le tomó mucho tiempo (más de un año, ya estando en funcionamiento) poner molinetes para el acceso del plantel de trabajo.
Una de las patas fuertes de la propuesta era el acceso a la maquinaria mediante dispositivos biométricos. En el caso de la autorización de arranque, las Reach Stacker y las Fork Lift podrían llevar un lector de huella que permita o no el encendido. Planteando esta posibilidad nos encontramos con observaciones como:
- Van a aparecer con bolsas llenas de dedos.
- Jajajaja…
- No es un chiste.
3. Conexión
Otro gran obstáculo con el que debíamos lidiar era la conectividad dentro de las terminales. Por una cuestión de organización y accesibilidad, los contenedores se apilan (en columnas de hasta más de 5) formando pasillos, “blind spots” que no permiten el paso de señal. La conexión GPS o LTE (las alternativas propuestas en una primera instancia) no brindan la seguridad necesaria para poder detectarlos en todo momento, porque en estos blind spots la señal de las antenas o satélites no alcanzaría al dispositivo.
Se barajó entonces la posibilidad de alternativas como el GPS diferencial, u obtener la posición a través de gateways internos de la terminal, y realizar la triangulación desde estos lugares.
Entonces, el planteo podía verse desde dos perspectivas que debían analizarse de modo conjunto y evaluar su ROI:
- ¿Cuánto le cuesta al puerto no contar con la tecnología IoT que mejore tal situación?
- Y en caso de adoptar este ecosistema (dispositivo+software), ¿cuál es el costo de sumar un engranaje más a la cadena de sistemas actual del puerto?
En definitiva, las placas y los sensores son baratos, pero IoT no.
Con toda esta información, llegamos a una definición del problema:
Las terminales portuarias necesitan obtener datos de la acción de los operadores y el estado de las máquinas, porque esto les da mayor control y eficiencia en el trabajo realizado, para tomar decisiones sobre sus procesos. Pero no hay terminales iguales: cada una se rige por reglas establecidas de forma autónoma, que hacen imposible contar con una solución global.
¿Ninguno de los proveedores de maquinaria portuaria ofrece soluciones a este problema? Si, pero a medias. Y acá está la bisagra de TODO el asunto, donde se pueden generar soluciones eficientes y eficaces. En la actualidad, estos proveedores ofrecen un paquete de maquinaria, hardware y software herméticamente cerrado y extremadamente costoso de customizar, que cubre parcialmente las necesidades de cada terminal. Con un costo menor, podemos construir soluciones a medida, flexibles, que respondan al 100% de las dolencias particulares de una terminal.
La solución
Más vale café con experto, que 100 reuniones con stakeholders
A esta altura, contábamos con la visión del manager de Puertos, una idea general del equipo sobre cómo avanzar en el proyecto, benchmarking de productos y sistemas nacionales e internacionales (a rolete), y las observaciones de los stakeholders. Pero faltaba la visión que más importa: la palabra de los que están ahí, donde pasan las cosas.
Está bien, no fue un café; fueron charlas por Skype y audios de WhatsApp con Manuel Álvarez, que se encontraba trabajando en Malasia para una terminal Tipo 1 (Clasificación de APM Terminals, en este caso: solo de transbordos, las más grandes que hay en el mundo), con 6 km de muelle, y que poco después se fue para Holanda a realizar estructura global en otra. Hoy es material manager en una empresa de generación de energía norteamericana, pero en Argentina pasó por todos los puestos, en distintas terminales clave en este proyecto: operador de grúa portuaria, yard planner y shift manager. Sabe de lo que habla.
¿Por qué en estos casos veo como algo necesario contactarse con un experto que no sea parte del cliente actual? ¿Qué tipo de insights puede darte alguien externo al proyecto?
Primero, como ya dijimos, la realidad de las terminales es distinta en cada parte del mundo: necesitaba saber cuáles son las particularidades de las latinoamericanas, y siendo bien preciso, de las argentinas. Por otro lado, el pragmatismo de la visión del uso de los productos y sistemas que debemos rediseñar no lo iba a obtener de ningún otro actor que no fuera el mismo que los usa. Por último, si no es una persona involucrada en el proyecto, está exenta de cuidarse y va a sacar más de un trapito al sol (para nosotros, insights).
De estas conversaciones obtuve comentarios como este (cita textual):
“Mirá, todo se trata de costos. Si vos como terminal no estás pudiendo tener visibilidad de ese movimiento, estás teniendo una desviación del costo final en tu cierre anual. Cuando un cliente entra a buscar un contenedor, ese costo está bancado por el pago que se le hizo a la empresa. Pero si una Reach Stacker se mueve, y ese costo no está pagado por el cliente, tenemos una pérdida muy importante. Por eso es imprescindible tener la visibilidad total de todos de los movimientos dentro de la terminal, y así elevar las ganancias de la empresa, minimizar las desviaciones y, con el tiempo, llegar a déficit 0.”
Contar con toda esta información no sólo me sirvió a mí como diseñador, sino que empapó al equipo de la realidad para la que íbamos a trabajar. Hacer una bajada clara y una transferencia del contenido accionable no es “un plus interesante”; es parte esencial del trabajo como diseñador de experiencias.
Jugando se aprende, se empatiza y se diseña
Lo más importante al momento de elegir una técnica es tener claro qué es lo que realmente buscás o necesitás saber. Nuestro norte era comprender cómo iban a interactuar los operadores con los nuevos dispositivos, cuál sería un diseño propicio, cómo los entenderían, qué tipo de feedback necesitaban y cuánto interferirían éstos en las actividades diarias con maquinaria en el puerto.
Junto a la diseñadora industrial del equipo, nos pusimos a trabajar codo a codo para dar luz a nuestras dudas, utilizando como técnica el Role Playing.
El Role Playing es una técnica a través de la cual se simula una situación que se presenta en la vida real. Al practicarla, se adopta el papel de un personaje concreto sumergido en un contexto determinado, y se atraviesan situaciones cotidianas. El objetivo es empatizar con los usuarios, comprender los “porqués” de sus formas de actuar y las decisiones que tomaría cada uno de los personajes en situaciones diferentes, para descubrir presupuestos equivocados o soluciones no imaginadas.
Ponerse en los zapatos del usuario facilita descubrir una visión del mundo que suele ser bastante distinta de la que se tiene detrás del teclado. Por ejemplo: si vas a diseñar para pacientes de un hospital, acostate en la cama y observá qué diferente se ve todo cuando el único paisaje es el techo, y las caras se ven en contrapicado.
En el artículo “El role-playing, una técnica para facilitar la empatía y la perspectiva social” de Xus Martín García (profesora titular de la Facultad de Pedagogía de la Universitat de Barcelona), se puede ver y profundizar una división en cuatro fases de esta metodología: motivación, preparación de la dramatización, dramatización y debate.
La base del entendimiento: escenarios
Detectamos cuatro escenarios clave en los que apoyarnos para llevar adelante la actividad, comprender el alcance final, explotar las capacidades de IoT, y conocer lo que nuestro potencial cliente debería ver:
- El camino feliz, en el que el operador se identifica y luego enciende el vehículo.
- Uno en el que el operador enciende el vehículo sin identificarse, recibe la notificación luego y se identifica.
- Otro en el que el operador se identifica y enciende el vehículo, pero luego toma una decisión errada (para las reglas del negocio).
- Un último camino en el que el operador se identifica, enciende el vehículo, y recibe una notificación externa.
Luces, led y bocina
De la dramatización de estos escenarios logramos ponernos en el lugar de los operadores del puerto, obtener datos y llegar a conclusiones valiosísimas como:
- El tamaño que debía ocupar la interfaz del dispositivo, y la forma con la que tenía que contar para ser visible y accionable, como un elemento más dentro del tablero que no interfiera con los otros.
- Que debía tener una pequeña pantalla para comunicar el feedback sobre las decisiones mal tomadas por el operador.
- Que el feedback se dividía en: señales a través de luces, texto en una pantalla y sonido a través de unas pequeñas bocinas.
- Que el sonido de la bocina debía ser en un tono agudo. Por más que esté prohibido el uso de protectores auditivos, el sonido de la maquinaria (motores y componentes hidráulicos) puede interferir en la recepción del feedback.
- Las luces debían ser 3: una para comunicar aciertos, otra para los errores, y una tercera para notificaciones externas.
- Alguien debía monitorear todas estas alertas on-time y generar un registro.
Customización: work instructions, un nuevo rol y horas extra
Tuve la suerte de escuchar a Claudio Dobniewuski (Manager de IoT en Grupo Datco) en el evento IoT Day, en Capital Federal, e intercambiar unas palabras luego de su ponencia. Ambos coincidimos en que la clave está en la customización, en qué le vas a hacer ahorrar al cliente.
En nuestro caso, nos apoyamos en los escenarios y las reglas del negocio para definir usos correctos y usos incorrectos. Un ejemplo de este último sería la conducción de un operador sin haberse logueado previamente en la máquina.
Pero, ¿cuál era el valor de estas definiciones?
- Work Instructions
En el día a día de las terminales portuarias, hay una serie de acciones que se planifican (con hora, trayecto, vehículo, etc.) y son asignadas a operadores para su ejecución, denominadas work instructions. Para sintetizar, a través de éstas se ordenan los movimientos de los containers de exportación y los de importación en el puerto.
Introduciendo los conceptos de tipologías de uso a estas acciones, podíamos relevar información importante y eficientizar los procesos internos del puerto: acortando distancias de traslado (ahorro en combustible y desgaste en neumáticos y motores), previniendo problemas (si hay una zona por la que no se debe pasar, negarla y que el dispositivo dé feedback al operador si se equivocó de trayecto), monitorear horas de mayor uso en la terminal, etc.
En una de las tantas reuniones y entrevistas con actores portuarios, la opinión de éstos fue:
“Esto nos puede servir para la asignación de recursos. Al planificar qué recursos vas a tener en los turnos mañana día y noche, vos ya podés saber qué equipos vas a asignar, y asignarle a cada operador un camión de manera automatizada. Si le diste el 18, y se sube al 15, bloquearlo.”
- Monitoreo en vivo
Comprendimos que toda esta información tenía valor tanto en un informe como en el vivo. Alguien debería ver lo que está pasando en el puerto, durante la ejecución de las work instructions. Denominamos a este rol como “Usuario Controlador”, y parte de la propuesta fue diseñada para él.
- El beneficio y la llave a los sindicatos
Parte de la propuesta planteada, consistía en cruzar datos de la maquinaria con datos e información de operadores. Esto era un obstáculo a vencer, porque se corría el riesgo de que la planta de trabajadores se sienta auditada. Sin embargo, al contar con un perfil por operador, con cantidad de horas trabajadas, máquinas asignadas, previsión de turnos y skills, las observaciones por parte de los managers y otros actores de estas terminales fueron:
“A fin de mes, al controlador del personal le llega la estadística de las horas trabajadas, y surgen cosas como: ‘¿Por qué vos tenés 40 horas hechas y el 20?’ Con esta solución que presentan podemos levantar información útil, más todavía cuando estás pagando horas extras. Tienen que tener esa visión completa del equipo.”
Cada puerto podría adaptar las reglas del negocio a sus formas. La customización ya era parte intrínseca del proyecto. Teníamos el diferencial en la mano.
Fierros y pantallas
El trabajo realizado abarcó la creación (desde foja cero) de un ecosistema de soluciones, compuesto por los siguientes elementos:
- Un prototipo del dispositivo microcontrolador, que va a levantar toda la info y trabajar sobre las reglas del negocio (el que interviene en la fusilera de la maquinaria).
- Otro prototipo de acceso biométrico, que también ofrezca feedback de sus acciones al operador (instalado en el tablero de las máquinas). Para no chocar con las realidades de los puertos y de la fuerza sindical, ofrece una alternativa con lector de RFID y llaves.
- Un tercer prototipo de un dashboard que ofrezca toda la información de valor para el cliente, procesada.
Mostrar y contar
Como equipo necesitábamos mantenernos en la misma página paso a paso. Las técnicas que elegimos para lograr esto fueron desarrollar un Service Blueprint y apoyarnos en los escenarios de uso del operador con storytelling. Detenerse y profundizar en qué consisten estas técnicas sería muy denso y la nota se extendería ya demasiado, pero la agencia argentina WOW de Customer Experience da una definición muy certera:
En esencia, un Service Blueprint es un mapa de puntos de contacto, que describe cómo sus cualidades tangibles e intangibles afectan la forma en que las personas se sienten y cuánto valor reciben. Como herramienta operativa permite visualizar los componentes de un servicio con el detalle suficiente para analizarlo, implementarlo y mantenerlo.*
Tuvimos la suerte de que, en el transcurso del tercer sprint del proyecto, se unió a Flux IT Ports un consultor senior en operaciones de terminales portuarias (más vale café con experto…). Junto a él, y el PO del proyecto, pudimos sacarle todo el jugo a esta herramienta en cada demo y validación.
Articulamos los puntos de contacto entre:
- Movimientos en el puerto
- Operador (su día completo en la terminal)
- Usuario controlador (su día completo en la terminal)
- Dispositivo de feedback en el tablero del operador
- Dispositivo IoT
- Tablero de control para el usuario controlador
Validación: la última palabra
Con todo el proceso realizado y los prototipos cerrados, nos reunimos con el proveedor líder en soluciones de manipulación de cargas y servicios a puertos, terminales, centros de distribución y la industria pesada, a nivel mundial.
El planteo era la intervención de maquinaria a cargo del personal capacitado de la firma, y la articulación con nuestro ecosistema de productos, en las terminales donde éste proveedor estaba arraigado, con sus sistemas y maquinaria.
Realizamos la propuesta en sus oficinas y obtuvimos la respuesta que estábamos esperando:
“Esto, así como está, puede funcionar. Lo queremos probar.”
El orden sí altera el producto
Hay muchas maneras y técnicas distintas para conseguir información de valor y comprender a fondo la situación a la que nos enfrentamos a la hora de encarar un proyecto. No creo que haya una mejor: creo que hay técnicas que aplican mejor que otras en ciertos casos; y que, en la sumatoria de experiencias, cada diseñador va armando su propia mochila con herramientas.
Pero no me interesa cerrar este artículo hablando de técnicas, porque creo que lo más valioso de todo el proyecto fue la decisión temprana (y acertada) del equipo entero, de parar la solución entera desde el dolor para desarrollar un servicio.
Las oportunidades están ahí. Sólo hay que escuchar y observar.
__
*En su artículo ¿Qué es un Service Blueprint? extiende esta información.
(Si sos diseñador y te interesa el Service Design, esta info te va a ser valiosa, junto con “This is Service Design Thinking” de Marc Stickdorn).
