Nuestro almacén, del tamaño de dos cuadrados rojos y una altura de 5 pisos, está abierto todo el año y nunca duerme: 24/7 364 días al año (el único día libre es el 1 de enero). Hemos almacenado y atendido más de 8,000,000 de productos, cada día cambian más de 300 operadores. Trabajan con productos procedentes de todo el mundo y recogen pedidos para usuarios de cuatro países: Rusia, Ucrania, Bielorrusia y Kazajstán. En tal escala, el negocio requiere una automatización impecable.
Bajo el corte, yo, Pasha Finkelstein, líder del equipo de desarrollo y automatización del almacén, le diré lo que una solución de código abierto puede crecer si le asigna un buen equipo de desarrollo y una tarea comercial muy específica.
Lógica básica
Tres procesos principales de cualquier almacén: aceptación de mercancías, su almacenamiento y envío. El ciclo simplificado de nuestro almacén se ve así: identificación primaria, control de calidad, colocación, selección y reserva de un pedido, búsqueda, clasificación, embalaje, transferencia a un servicio de entrega. Cuando el cliente devuelve el producto, el ciclo se repite. Cada entidad física que participa en estos procesos tiene su propia representación informativa, por ejemplo: camión, producto, celda del gabinete, paquete, material de embalaje, contenedor, etc. Todos los movimientos y cambios significativos en el estado de los bienes se traducen en sistemas de contabilidad y se registra absolutamente cada acción con los bienes dentro del almacén.
WMS (Sistema de gestión de almacenes) controla el ciclo de vida de cada producto en el almacén, desde el momento en que el camión con los bienes del proveedor llega al almacén hasta que los bienes se envían al cliente.
Los detalles de la automatización de la moda.
Nuestra empresa trabaja en el campo de la moda y el estilo de vida, que plantea ciertas tareas en el almacén: el producto puede ser frágil (gafas, relojes), tamaño no estándar (botas de invierno o joyas), premium (en un embalaje especial), o poseer otras características específicas que El almacén debe tener en cuenta. Por lo tanto, es imposible abandonar por completo el uso de mano de obra en las áreas de almacenamiento.
Todos los demás procesos están automatizados: aceptación de mercancías, transferencia al área de envío, clasificación, embalaje y preparación para el envío. Cada uno de estos procesos requiere un equipo especial y un proceso operativo. La magia ocurre cuando todos estos procesos "se mantienen unidos" y comienzan a funcionar juntos, gracias a nuestros sistemas.
Cualquier supervisión en la automatización del almacén, ya sea una interfaz que contribuya a errores del operador, un proceso no óptimo, etc. - Esto es un retraso en el envío, el tiempo de inactividad de todo el complejo, enormes pérdidas. Además, con cada error creamos una experiencia negativa para el cliente. Por lo tanto, es importante para nosotros que el almacén funcione como un reloj.
Código abierto y el camino hacia el desarrollo propio
En la etapa de apertura, utilizamos un almacén externo. Con el crecimiento de los volúmenes, comenzamos a comprender que necesitamos un control total sobre los procesos operativos y una alta tasa de cambio de estos procesos, por lo que decidimos avanzar hacia nuestro propio almacén y desarrollo.
La pregunta principal que luego nos enfrentó fue la elaboración de los procesos operativos en todos los detalles. Hasta dónde y cómo van los empleados, cuántos escaneos hacen, etc. Y ya en estos procesos, era necesario implementar WMS, que gestiona las actividades operativas y automatiza las operaciones de rutina.
Para comenzar, tomaron una solución de código abierto en Java y luego decidieron reunir su propio equipo de desarrollo, especialmente porque ya existe una base adecuada. Aumentamos la funcionalidad, luego tomamos el núcleo del sistema: nos deshicimos del legado y un cliente gordo, realizamos la refactorización, desarrollamos nuevos servicios para apoyar los procesos operativos.
Etapas de automatización
Los principales cambios fueron llevados a cabo por las "olas", junto con la reestructuración de los propios procesos.
Hasta la fecha, ha pasado por nueve etapas de modernización, y no planeamos detenernos en esto.
- En la primera y segunda etapa, automatizamos los procesos de envío de pedidos: agregamos transportadores, lógica para clasificar productos, clasificación automatizada de pedidos por paletas.
- En la tercera y cuarta etapas, nos centramos en los procesos de aceptación: aprendimos a separar los flujos de mercancías entrantes por diferentes tipos y zonas de almacenamiento.
- La quinta fase agregó ascensores automáticos entre pisos: así es como comenzó el trabajo en el área de almacenamiento.
- La sexta fase fue la más crítica cuando cerramos las zonas de aceptación y envío, pasando por toda la automatización.
- En las fases séptima y octava, realizamos cambios en los procesos en la zona de aceptación y agregamos nuevas zonas, elevadores y transportadores: ampliamos la automatización existente.
- En la novena fase, agregaron un nuevo edificio al almacén y lo integraron con el sistema de automatización existente.
Implementación
Nuestras tecnologías principales: Java, Postgres, Wildfly, Redis, ActiveMQ.
WMS está escrito en Java 8. Pero no hace mucho tiempo, arreglamos el último módulo, que impedía la transición a Java 11, se actualizará en un futuro próximo.
Un bastidor de servidor instalado directamente en el almacén está reservado para WMS. Esto nos da mucha más confianza de que WMS funcionará incluso si la electricidad y / o Internet están apagados. Lo único que sufrirá es que los mensajes al sistema contable llegarán con retraso. WildFly se utiliza como servidor de aplicaciones, aunque todavía no es la última versión. La migración a este último también está en los planes. Ya se ha escrito todo para la mudanza, pero aún no se han logrado realizar pruebas funcionales y de carga, y antes del año nuevo, la carga es relativamente alta. También se utiliza un ActiveMQ probado.
Los datos que almacenamos en PostgreSQL. La esencia principal de nuestro sistema es obviamente un producto. A veces, los empleados del almacén proponen soluciones para simplificar su trabajo, por ejemplo, escanean el mismo código de barras 50 veces, y el producto en sí mismo simplemente se lanza manualmente sin escanear, sin entrar en detalles, se trata de jeans o camisetas, por lo que ingresamos etiquetas que identifican una unidad específica bienes, apoyándolo en la infraestructura. La información sobre estas unidades se almacena en una base de datos PostgreSQL de 2 terabytes.
La mayor parte del lugar está ocupado ni siquiera por bienes, sino por una auditoría de las acciones de los trabajadores del almacén. Al ser un sistema crítico para el negocio, el almacén debe saber por qué algo apareció en el sistema o desapareció; no podemos permitir cambios no rastreados. En este momento estamos pensando en llevar esta parte de la base de datos a una entidad separada en MongoDB.
Las estaciones de trabajo del personal de almacén son clientes web ligeros. En algún momento al comienzo de la automatización, todo esto funcionó de acuerdo con el principio de un cliente pesado, lo que creó ciertas dificultades, en particular, con lanzamientos grandes, que incluyeron cambios en la interfaz: alrededor de 150 estaciones de trabajo tuvieron que actualizarse manualmente. Esto y el hecho de que no podríamos liberar sin el tiempo de inactividad nos impuso límites: podríamos implementar no más de dos veces por semana, temprano en la mañana, cuando finaliza el turno de noche, lo que no se puede llamar un horario conveniente. Ahora hemos transferido WMS a la web y para finales de año abandonaremos por completo a los clientes gordos, lo que nos simplificará en gran medida los cambios en la interfaz de usuario. La web y la agrupación agregada en una de las etapas eliminan las restricciones sobre la frecuencia y el tiempo de los lanzamientos; ahora los usuarios aprenderán sobre los lanzamientos solo si algo sale mal.
También hay un interesante "exótico" en nuestro almacén. Por ejemplo, el Haskell mencionado en
Technoradar , en el que está escrito el back-end de la visualización del clasificador de artículos (esta es una máquina que puede componer productos de un paquete y entregárselos al operador del ensamblaje). Hay un problema puramente computacional que se resuelve convenientemente en un estilo funcional. Naturalmente, nadie va a usar Haskell para ningún proyecto a gran escala.
Otro elemento del almacén que mencionamos en el
artículo sobre Technoradar es una máquina de
estado autoescrita que "monitorea" la secuencia correcta de acciones con cada producto. Al igual que todo el sistema, se desarrolló de forma iterativa, comenzando con un conjunto simple de restricciones. Ahora es algo muy conveniente, profundamente integrado en nuestro sistema. Esperamos ponerlo en
código abierto en el futuro cercano, tal vez sea útil no solo para nosotros.
Equipos de automatización
¡Qué automatización sin equipo! Todo el almacén está enredado en una red completa de transportadores.
El clasificador de artículos mencionado anteriormente funciona en la etapa de envío, lo que le permite distribuir decenas de miles de unidades de mercancías recolectadas del stock para pedidos específicos. En un momento, el seleccionador salvó a nuestros operadores de la necesidad de viajar con un carrito alrededor del almacén para recoger los productos necesarios. Los pedidos se dividen, cada operador recolecta bienes solo de su piso (ahorrando tiempo en el movimiento), y el clasificador se asegura de que los bienes de diferentes pisos entren en los pedidos correctos automáticamente. Cambiar el proceso operativo en 4 veces aceleró el montaje del pedido y redujo significativamente el número de errores.
Todo el equipo automatizado es proporcionado por nuestro socio. Para la gestión de unidades específicas, tienen su propio sistema, que se encuentra en el bastidor del servidor junto a nuestro WMS. Entre los sistemas, la integración se configura en un protocolo de alto nivel: nos comunicamos a través de SOAP. Desde nuestros procesos operativos dentro de WMS, recurrimos a su sistema cuando, por ejemplo, necesitamos mover un contenedor con mercancías del punto A al punto B. Es decir, Desde el punto de vista de nuestro sistema, toda esta automatización parece bastante simple, a pesar de su verdadera complejidad interna.
Por supuesto, esta aparente simplicidad no funcionó de inmediato. En las primeras etapas de la automatización, tuvimos una "molienda mutua" de tecnologías. Una vez que el transportador literalmente quemó nuestros productos: la velocidad de la cinta transportadora era demasiado alta, "masticó" los productos y se quemó, lo que bloqueó el ensamblaje de otras órdenes. Quizás la historia más difícil sucedió al comienzo de la automatización, cuando lanzamos la primera fase. Ayer, el almacén era completamente manual, y hoy, después de cambiar el interruptor, debería volverse automático. Pero nada funcionó: debido a un error en la integración del sistema, los mensajes de cada uno se interpretaron incorrectamente, lo que resultó en varios días de inactividad del almacén y millones de pérdidas para nosotros.
Ahora el socio está presente en nuestro almacén, planea organizar el equipo con nosotros cuando se trata de una nueva ronda de automatización, ayuda a probar nuevos bloques.
Equipo y scrumban
El desarrollo de todo este sistema ahora está involucrado en un equipo de 12 personas. En una de las últimas etapas en el pico de la modernización, cuando los procesos automatizados por separado se combinaron en algo completo, solo 20 desarrolladores participaron (esa etapa requirió 132 meses-persona e incluyó más de 1,500 confirmaciones). Pero a medida que terminan las transformaciones a gran escala, algunas personas decidieron aprender Go o Python y cambiaron a otros equipos de desarrollo.
En el equipo, tenemos gerentes de proyecto "clásicos" que combinan las funciones de un producto y un proyecto de TI (en promedio, un PM para 5-6 personas). Sus tareas incluyen la comunicación con nuestro cliente principal: un almacén representado por su director y el departamento de desarrollo de procesos operativos. Por nuestra parte, nos preocupa más la modernización técnica: elegir la pila correcta, las actualizaciones, etc. - Y los chicos del almacén están pensando en optimizar los procesos.
A veces nosotros mismos dedicamos tiempo a la I + D en el campo. En el sentido literal, venimos al almacén, nos comunicamos con los turnos de alto nivel, con los operadores comunes, y aclaramos qué problemas tienen, qué es conveniente e inconveniente para trabajar. En otras palabras, realizamos una investigación de la experiencia del usuario.
Gracias a este enfoque, por ejemplo, hemos transformado la interfaz del lugar de trabajo de un empleado que lleva a cabo la aceptación de bienes. Inicialmente, era una interfaz compleja empresarial con muchos campos, botones y abreviaturas en lugar de explicaciones textuales. Pero tratamos de optimizar el proceso, así como el diseño, haciéndolo más similar a la página principal de búsqueda de Google, no tan hermoso, pero muy funcional. Cuanto más simple es la interfaz y menos opciones tiene el operador, dónde hacer clic y qué escanear, menos errores (y el tiempo requerido para solucionarlos).
Y el conocimiento acumulado sobre la optimización de detalles ahora nos supera en los momentos más inesperados: una vez que nuestro equipo estuvo en la institución y en un momento casi todos los participantes observaron la secuencia de las acciones del cajero. Después de unos 40 segundos, un colega expresó la idea general: "No de manera muy óptima, puede simplificarla".
Aunque la relación entre los roles en el equipo es bastante clásica, elegimos un scrumban para la metodología de desarrollo.
Experimentamos mucho con metodologías, mientras que los datos de "entrada" no eran estándar. Por ejemplo, tuvimos lanzamientos bastante raros. La restricción mencionada anteriormente de dos lanzamientos por semana actuó por parte de los procesos, pero de hecho la implementamos con mucha menos frecuencia, en promedio una vez cada dos semanas. Además, teníamos el hardware de automatización del almacén, que está siendo desarrollado por una compañía externa para la cascada limpia, donde todos los cambios están programados con dos años de anticipación con toda la documentación necesaria. Sin embargo, nosotros mismos no podíamos seguir su ejemplo: necesitábamos hacer algunos cambios en el sistema de manera regular y obligar al cliente a escribir una tarea detallada para cada uno de ellos no tenía sentido.
Entonces scrumban es un compromiso que hizo felices a todos. Usamos un proceso iterativo, pero sprint es el lanzamiento para nosotros. Una vez al mes nos reunimos con el cliente y planificamos los lanzamientos: discutimos qué y qué semana implementamos. Dentro del sprint, se implementa kanban, con una acumulación de tareas, progreso, etc. Es cierto que este proceso está cambiando gradualmente, por ejemplo, no tenemos un tablero kanban. Justo cuando un desarrollador termina su tarea, se le da el siguiente del grupo de acuerdo con los planes para el próximo lanzamiento y las competencias del desarrollador.
Nos gusta este enfoque. Proporciona la flexibilidad necesaria dentro de las iteraciones y le brinda al cliente comercial la previsibilidad de las fechas en que se implementarán ciertos compromisos. Y no es tan importante para nosotros cómo se llama esta metodología. Lo principal es que todo funciona.
No como todos los demás: utilizando el inventario y el monitoreo como ejemplo
Al desarrollar procesos operativos, partimos de las necesidades de nuestra industria, por lo tanto, tenemos bastantes características individuales.
Un buen ejemplo es un inventario. De acuerdo con la ley, debe realizarse en el almacén una vez al año, pero nuestros requisitos comerciales determinan un monitoreo más cercano del stock. En primer lugar, queremos reflejar información relevante sobre la disponibilidad de productos en el sitio web y, en segundo lugar, nuestros socios B2B, marcas de moda, requieren la misma información relevante. Por lo tanto, un inventario se realiza diariamente, 364 días al año, estante tras estante en todo el complejo de 5 pisos de varios edificios. Y este proceso es totalmente compatible con nuestro WMS: sería difícil implementar dicha solución.
Ahora el inventario está en proceso de la próxima actualización para aumentar la eficiencia de este proceso.
Otro ejemplo de nuestro propio desarrollo es el monitoreo. Se implementa a través de un cliente web y le permite mostrar y rastrear métricas muy interesantes. Además, una representación visual de estas métricas es importante para nosotros. De hecho, el monitoreo es un almacén representado en un horario simple, donde vemos claramente en qué lugares todo funciona bien y dónde se observan problemas (hasta un operador específico). Lo más importante, con esta visión, podemos entender por qué surgen estos problemas.
KPI Warehouse Workers y Redis
La introducción de nuevas tecnologías, actualizaciones, refactorización, todo es genial. Pero nuestro WMS funciona en negocios reales, así que aquí tenemos que resolver no solo estos problemas. Parte de nuestro trabajo es la protección de los "hackers" internos: empleados ingeniosos del almacén que inventan nuevas formas de realizar KPI sin pasar por la tarea.
Por ejemplo, no hace mucho tiempo, nos vimos obligados a agregar Redis a la pila para evitar que los usuarios inicien sesión en el sistema desde varias estaciones de trabajo al mismo tiempo e implementen un tiempo de espera de sesión. El hecho es que los trabajadores del almacén se dieron cuenta de que trabajar bajo un solo inicio de sesión y recibir una bonificación por exceder el KPI es mucho más rentable que aumentar su propia productividad.
Dado que resolver el problema comercial requería cambios en varios lugares del sistema, desde un punto de vista técnico fue un desafío muy interesante.
Las sorpresas del personal del almacén no terminaron allí. Casi inmediatamente después del lanzamiento de la sesión, PostgreSQL comenzó a fallar. Buscamos las razones de la degradación inesperada de la base durante varios días, hasta que descubrimos que el asunto, nuevamente, era el ingenio. Una niña solía fumar. Cuando dejó el lugar de trabajo, fue eliminada de la sesión y, para volver a iniciar sesión, fue necesario encontrar el turno de mayores y escanear su placa. Reduciendo sus deambulaciones por el almacén, simplemente arrancó el código de barras de uno de los carros y arregló el botón del escáner con cinta, configurándolo para escanear constantemente este código de barras. Y esto podría pasar desapercibido durante mucho tiempo si el código de barras no fuera del carrito, que contenía 800 unidades de productos. Con cada escaneo, se generó una gran consulta SQL para validar los productos, que "mataron" la base de datos con tales "DDoS internos". Tuve que ocuparme de las restricciones sobre el número de escaneos por unidad de tiempo y sobre el número de productos en el carrito.
Ya hay bastantes historias de este tipo, y constantemente nos enfrentamos con otras nuevas. Además, el sistema debe adaptarse a las nuevas condiciones cada vez. En tales situaciones, uno no puede limitarse solo a los métodos administrativos: lo que sucedió una vez puede muy bien repetirse.
¿A dónde vamos ahora?
La optimización del proceso y la automatización del almacén, al parecer, es imposible de completar. Dura 5 años en la empresa y, como dije anteriormente, incluso después de la etapa 9 no vamos a parar. La compañía continúa expandiéndose tanto en B2C como en B2B, por lo que en el futuro cercano estamos planeando otro gran proyecto: abrir otro almacén, esto requerirá una reescritura a gran escala del sistema existente o la creación de uno similar desde cero en un nuevo lugar. Y este es un nuevo desafío interesante en la unión de negocios, instalaciones físicas, procesos operativos y soluciones técnicas.