Caso de éxito · Industrial · Fabricación
Caso de éxito CheckList: cómo entregamos un ecosistema industrial de tres apps (un cliente Android para operarios en Kotlin, un panel de administración en Laravel + React y un panel de control para controladores), desplegado dentro de una red de planta aislada y concebido para sustituir los diarios en papel por un flujo de trabajo de nivel de auditoría para instalaciones de Estados Unidos y la Unión Europea.
El cliente de CheckList gestionaba una planta de fabricación en la que los procesos de los reactores se seguían con diarios en papel: los operarios anotaban a mano los tiempos de cada etapa, los supervisores hojeaban los cuadernos para reconstruir los turnos y no había visibilidad en tiempo real del tiempo de actividad ni del número de errores. La planta operaba sin internet dentro de su perímetro (una restricción estricta, no una preferencia), de modo que cualquier sustituto digital tenía que funcionar totalmente sin conexión y sincronizarse cuando hubiera conectividad de red local. Entregamos un ecosistema de tres apps desplegado dentro de la red aislada de la planta: los operarios usan una app Android en Kotlin para registrar las etapas con marcas de tiempo y evidencias fotográficas; los administradores configuran equipos, listas de verificación, usuarios y permisos en un panel de administración en Laravel y React; los controladores vigilan un panel en vivo con tiempo de actividad, número de errores y un botón de parada de emergencia. La autenticación local y la sincronización offline-first hacen que el sistema sea utilizable sin acceso a internet, y un constructor de reactores/procesos permite a la planta añadir equipos nuevos sin cambiar el código. El resultado es un flujo de trabajo de nivel de auditoría que resiste el escrutinio de las auditorías de planta en las jurisdicciones de EE. UU. y la UE y sustituye cada línea del cuaderno en papel.
Un resumen de lo que aportó el desarrollo de CheckList en la app de operario, el panel de administración y el panel de control durante su primer ciclo de producción en la planta.
La decisión sobre el stack pesa más que cualquier otra decisión de arquitectura en un desarrollo de MES industrial. Elegimos un cliente Android de operario a medida en Kotlin, junto con un backend en Laravel y una superficie web en React, porque las ventajas y desventajas encajan con claridad con una planta que opera sin internet. La app de Android funciona sin conexión por diseño, el backend de Laravel se despliega en un único equipo on-premise dentro de la red local de la planta, y los paneles de administración y de control en React comparten el estado de sesión mediante WebSockets, de modo que un supervisor ve subir el número de errores en el instante en que un operario registra una desviación.
Los proveedores de MES SaaS se descartaron pronto: dan por hecho que hay internet fiable, sacan los datos de la planta fuera del perímetro y facturan por nodo de maneras que se vuelven inmanejables a medida que la planta crece. El SCADA estándar es muy configurable, pero su superficie de flujos de trabajo (traspaso de turno, evidencia fotográfica, archivo de nivel de auditoría) queda fuera de su competencia principal. Un creador de formularios genérico más una herramienta de automatización unen una cadena frágil que se rompe la primera vez que la red local de la planta pierde un paquete.
| Criterio | CheckList (Kotlin + Laravel + React) | Proveedores de MES SaaS | SCADA / creador de formularios estándar |
|---|---|---|---|
| Comportamiento offline-first | Nativo: cola SQLite local que se vuelca al disponer de red local | Presupone internet fiable | SCADA: sí; creador de formularios: normalmente no |
| Topología de despliegue | On-premise en la red local de la planta; puede aislarse por completo | Nube multi-tenant; precio por puesto | SCADA: on-premise; formularios: solo en la nube |
| Titularidad de los datos | La planta es propietaria de la base de datos de extremo a extremo | El proveedor conserva los datos de producción | SCADA: la planta; formularios: proveedor + automatización |
| Ajuste de la superficie de flujos de trabajo | Flujo de turno, tiempos de etapa y evidencia fotográfica de forma nativa | Sólida, pero ligada al modelo | SCADA: centrado en el proceso; formularios: frágil |
| Profundidad de personalización | DSL constructor de reactores / procesos: la planta añade equipos | Ciclos del proveedor + límites de configuración | SCADA: profunda; formularios: superficial |
| Control de acceso basado en roles | Operario / administrador / controlador integrados | Sólido, pero hereda el modelo RBAC del proveedor | SCADA: sólido; formularios: normalmente débil |
| Archivo de nivel de auditoría | Archivo de ciclos completados con evidencia fotográfica | Depende del proveedor; la calidad de la exportación varía | SCADA: histórico de datos; formularios: hoja de cálculo |
Referencias del stack: documentación de Laravel, guía para desarrolladores de SQLite en Android, documentación de React.
El cliente Android está escrito en Kotlin y se ejecuta en tabletas de planta vinculadas a un identificador único de dispositivo en el primer arranque. La autenticación local es obligatoria (no se espera que el dispositivo pueda llegar a un proveedor de identidad en la nube) y cada acción del operario se escribe primero en un almacén SQLite local antes de cualquier intento de sincronización. El flujo de turno guía al operario por las etapas con un temporizador integrado, captura evidencia fotográfica en los puntos que exige la auditoría y envía el archivo de ciclos completados al servidor on-premise cuando hay conectividad de red local. La interfaz está ajustada para guantes gruesos, la iluminación de planta y toques rápidos, y no para el patrón de consumo de un teléfono en el bolsillo.
Un proceso de sincronización en segundo plano vuelca la cola local al servidor Laravel on-premise mediante WebSockets, con operaciones idempotentes identificadas por un ID generado en el cliente para que los reintentos nunca dupliquen trabajo. El traspaso automático de turno transfiere un ciclo de reactor en curso de la tableta de un operario a la del siguiente sin perder el estado, y los conflictos los resuelve en el servidor el motor de flujos de trabajo. La superficie del operario forma parte de nuestra práctica de desarrollo de aplicaciones móviles, y el contrato offline-first es la pieza central: si la red local de la planta se cae durante medio turno, no se pierde nunca ninguna acción del operario.
La superficie web tiene dos perfiles diferenciados, cada uno con una vista acotada respaldada por control de acceso basado en roles. El panel de administración, construido en React sobre un backend de Laravel, permite a los supervisores configurar equipos, editar listas de verificación, gestionar usuarios y permisos y vincular tabletas a operarios concretos. El DSL constructor de reactores / procesos es aquí la pieza central: la planta añade un reactor nuevo o amplía un flujo de proceso existente editando plantillas de listas de verificación en el panel de administración, sin esperar a un ciclo de ingeniería. Los equipos nuevos, las nuevas definiciones de etapas y los nuevos requisitos de evidencia fotográfica se incorporan mediante configuración.
El panel de control es una superficie de supervisión en tiempo real que transmite el estado de la planta por WebSockets (tiempo de actividad actual de los reactores, número de errores, turnos en curso, crecimiento del archivo de ciclos completados) y expone un botón de parada de emergencia protegido por RBAC, de modo que solo un usuario con el rol de controlador pueda pulsarlo. El panel funciona en cualquier navegador moderno dentro de la red local de la planta, lo que permite al controlador supervisar desde una estación fija, un portátil de mantenimiento o una pantalla de pared sobre la línea de producción. Toda la superficie web se entrega como parte de nuestra práctica de desarrollo de software a medida y está estructurada para que las plantas puedan añadir nuevos paneles (exportación de KPI, vista móvil para supervisores) sin reestructurar la capa de datos.
La arquitectura de CheckList se construyó en torno a la restricción de que la red local de la planta no tiene salida a internet. El backend de Laravel y la base de datos MariaDB se despliegan en un único servidor on-premise dentro del perímetro de la planta, los paneles de administración y de control en React se sirven desde la misma máquina y las tabletas Android llegan al backend por WebSockets en la red local de la planta. No hay ningún intermediario externo, ninguna telemetría solo en la nube ni ningún rastreador de analítica en la sombra. Los procesos en segundo plano gestionan la escritura del registro de auditoría y la ingesta de evidencias fotográficas, y el archivo de ciclos completados se conserva indefinidamente con políticas de retención configurables por instalación.
El control de acceso basado en roles protege cada endpoint de la API y cada ruta del panel: un operario solo ve su turno, un administrador ve la configuración y la gestión de usuarios y un controlador ve la superficie de métricas en vivo más el control de parada de emergencia. La vinculación de dispositivos asocia cada tableta a un identificador único, de modo que una tableta perdida no pueda reutilizarse fuera de la planta. El enfoque de tratamiento de datos está documentado tanto para las obligaciones del RGPD en las operaciones de la Unión Europea como para las de la CCPA / CPRA en las operaciones de California y del resto de Estados Unidos, con una retención del registro de auditoría configurable por instalación para ajustarse a los plazos regulatorios locales. El enfoque de refuerzo es coherente con nuestra higiene general de cloud y DevOps.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Un desarrollo en cinco fases que llevó a CheckList desde los diarios en papel hasta un ecosistema industrial de tres apps desplegado dentro de una red de planta aislada.
Entrevistas a operarios y controladores, taxonomía de los diarios en papel, modelado del flujo de turno, requisitos de evidencia fotográfica, restricciones del despliegue on-premise y mapeo del enfoque RGPD + CCPA.
Elección del stack Laravel + React + Kotlin, diseño del DSL constructor de reactores / procesos, superficie de control de acceso basado en roles, esquema del almacén del registro de auditoría y esquema de vinculación de dispositivos.
App Android de operario en Kotlin con sincronización offline-first, panel de administración en Laravel + React, panel de control con transmisión por WebSocket y control de parada de emergencia.
Refuerzo del canal de evidencias fotográficas, políticas de retención del registro de auditoría, barrido de pruebas de RBAC, reglas de resolución de conflictos en el motor de flujos de trabajo y ajuste de la experiencia de usuario en planta.
Despliegue del servidor on-premise, aprovisionamiento de tabletas y vinculación de dispositivos, formación de operarios, comprobaciones de ajuste del panel de control y verificación del archivo de ciclos completados.
CheckList se desplegó primero en una sola planta, pero la arquitectura está diseñada para ampliarse a varias instalaciones sin cambiar la app de operario ni el panel de administración. Cada instalación ejecuta su propio servidor Laravel on-premise y su propia base de datos MariaDB (la red local de la planta sigue siendo el perímetro de seguridad), y una futura capa de federación puede agregar los archivos de ciclos completados, las exportaciones de KPI y los flujos de BI en una visión corporativa sin romper el contrato offline-first en la planta. El DSL constructor de reactores / procesos permite que una instalación nueva configure su propia biblioteca de equipos, listas de verificación y flujos de turno sin una tarea de ingeniería; el esquema de vinculación de dispositivos permite aprovisionar y rotar las tabletas en local; y la superficie de control de acceso basado en roles hace que los roles de operario, administrador y controlador funcionen igual en todas las instalaciones aunque el equipamiento subyacente varíe. El mismo enfoque deja espacio para una futura vía de exportación a BI: los datos del archivo de ciclos completados salen del perímetro de la planta solo cuando el operador de la planta lo autoriza expresamente, con plazos de retención configurados por instalación para ajustarse al régimen regulatorio local. Las plantas de EE. UU. y la UE pueden funcionar con la misma receta de despliegue y ajustar en local la retención, los ámbitos de RBAC y las reglas de exportación a BI sin bifurcar la base de código.
CheckList se construyó para su despliegue en plantas de Estados Unidos y de la Unión Europea sin una base de código distinta por región. La interfaz en inglés atiende a operarios y controladores de California, Nueva York, Texas, Florida y Washington en EE. UU., y a operarios y controladores de Países Bajos, Alemania, Francia, Irlanda y Suecia en la UE. Las prácticas de tratamiento de datos están alineadas con el RGPD para las operaciones de la Unión Europea y con el mosaico de leyes estatales de privacidad de EE. UU.: CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) y la CPA de Oregón. Dado que el despliegue on-premise mantiene los datos de la planta dentro del perímetro de cada instalación y que la superficie de control de acceso basado en roles protege cada lectura y escritura, el cumplimiento regional se reduce a una divulgación honesta y a la configuración de la retención del registro de auditoría, y no a una segregación de datos por jurisdicción.
La receta de despliegue on-premise es idéntica en las instalaciones de EE. UU. y la UE: el mismo backend de Laravel, la misma base de datos MariaDB, la misma app Android de operario en Kotlin y los mismos paneles de administración y de control en React. Los plazos de retención del archivo de ciclos completados son configurables por instalación para ajustarse a las expectativas regulatorias locales, y el almacén del registro de auditoría está estructurado para satisfacer las obligaciones de tratamiento de datos del RGPD para los usuarios de la Unión Europea y las obligaciones de la CCPA de California para las instalaciones de EE. UU. El equipo de ingeniería responsable del desarrollo trabaja en CET y sigue una jornada CET con solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para las reuniones diarias, la coordinación del despliegue y la respuesta a incidencias: la franja horaria que permite a un equipo de operaciones de planta de EE. UU. y a uno de ingeniería de la UE compartir cuatro horas de solapamiento en directo cada día.
La hoja de ruta activa de desarrollo de software a medida de CheckList incluye una capa de federación multiplanta que agregue los archivos de ciclos completados de varias instalaciones, una vía de exportación a BI que envíe KPI depurados a data lakes corporativos, un canal de evidencias fotográficas offline-first que resista largas caídas de la red local en sitios remotos y una receta reforzada de actualización on-premise que no exija dejar una planta fuera de línea. Se prevén un manual de despliegue centrado en EE. UU. y otro en la UE, con la superficie de control de acceso basado en roles ya estructurada para admitir la configuración de retención local de cada instalación.
Si planea un MES de fabricación, una app de planta offline-first o cualquier desarrollo industrial de control de procesos en el que los datos deban permanecer dentro del perímetro de la planta para audiencias de EE. UU. y la UE, hemos entregado este stack de principio a fin y podemos acortar de forma notable el plazo de desarrollo. El equipo de ingeniería que lo desarrolló forma parte de YuSMP Group. Trabajamos a precio cerrado en MVP bien acotados y con equipos de desarrollo dedicados para la entrega continua, con jornada CET y una franja garantizada de solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para reuniones diarias, demos y respuesta a incidencias.
Un MVP de MES de tres apps con un cliente Android de operario en Kotlin, un panel de administración en Laravel + React, un panel de control, despliegue on-premise y sincronización offline-first suele costar $140k–$320k. Añadir un DSL constructor de reactores y procesos, federación multiplanta, canales de evidencias fotográficas, un almacén de registro de auditoría reforzado y exportación a BI lleva un producto industrial completo a $400k–$780k. Los principales factores de coste son la corrección de la sincronización offline-first, el trabajo de refuerzo on-premise y la superficie de control de acceso basado en roles, que tiene que resistir una auditoría real de planta.
Los proveedores de MES SaaS dan por hecho que la planta tiene internet fiable y que los datos del cliente salen del perímetro; ambas cosas son inaceptables para una instalación que opera sin conexión por diseño. El SCADA estándar es configurable, pero la superficie de flujos de trabajo en torno al traspaso de turno, la evidencia fotográfica y un archivo de nivel de auditoría queda fuera de su modelo central. Un creador de formularios genérico más automatización une una cadena frágil. Un desarrollo a medida con Android en Kotlin más Laravel y React controla de extremo a extremo los datos, la topología de despliegue y la superficie de flujos de trabajo.
Cada acción del operario (inicio de etapa, evento del temporizador, carga de fotografías, traspaso de turno) se escribe primero en un almacén SQLite local del dispositivo bajo una identidad de autenticación vinculada al dispositivo. Un proceso de sincronización en segundo plano vuelca la cola al servidor Laravel on-premise por WebSockets cuando hay red local en la planta, con operaciones idempotentes identificadas por un ID generado en el cliente para que los reintentos no dupliquen trabajo. Los conflictos los resuelve en el servidor el motor de flujos de trabajo, y la interfaz del operario muestra el último estado correcto conocido hasta que el servidor confirma la aceptación.
El sistema recoge solo los datos de operarios y procesos que la planta necesita realmente (rol del operario, turno, tiempos de etapa y evidencia fotográfica) y los almacena en el servidor on-premise dentro del perímetro de la planta. No hay ningún intermediario externo, ninguna telemetría solo en la nube ni ningún rastreador de analítica en la sombra. El control de acceso basado en roles determina quién puede ver qué fotografías y qué archivos de turno. El enfoque de tratamiento de datos está documentado tanto para el RGPD en las operaciones de la Unión Europea como para la CCPA en las operaciones de California, con retención del registro de auditoría configurable por instalación.
Un MVP centrado en una app Android de operario en Kotlin, un panel de administración en Laravel + React, un panel de control, despliegue on-premise y sincronización offline-first suele tardar 20–32 semanas de calendario. Añadir un DSL constructor de reactores y procesos, federación multiplanta, exportación a BI y un almacén de registro de auditoría reforzado suma otras 10–16 semanas. La pasada de refuerzo on-premise (vinculación de dispositivos, control de acceso basado en roles, retención del registro de auditoría y coordinación del despliegue en plantas de EE. UU. y la UE) debería presupuestarse con 4–6 semanas de trabajo dedicado.
Casos relacionados
Calculadora de ventanas en línea unificada y CRM: multi-tenant en tres sitios de marca, consulta por dirección.
Ver el caso →
Plataforma de taxis con tres apps (conductor, pasajero y despachador), con GPS en tiempo real y verificación de documentos.
Ver el caso →
Marketplace de autopiezas con CRM para vendedores: búsqueda por VIN, inventario multiubicación y entrega integrada.
Ver el caso →
Plataformas empresariales con la arquitectura como punto de partida, cumplimiento listo para auditoría e integración con SAP, Salesforce, Workday y Okta.
Más información →
Migración «strangler fig» de stacks heredados (.NET Framework, Java 8, monolito) sin el riesgo de reemplazarlo todo de golpe.
Más información →
Transformación pragmática que se entrega: migración a la nube, modernización de sistemas heredados, integración de IA y plataforma de datos.
Más información →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.