AcumatiCares
Introducción
En nuestra época moderna de tecnología avanzada y logros científicos, muchos de nosotros damos por sentado que todas las herramientas y equipos que nos rodean simplemente funcionan. La mayor parte de la tecnología que damos por sentada se considera desechable. Sustituimos los caros teléfonos móviles cada dos años. Los hornos microondas y los televisores se desechan la primera vez que se estropean o cuando sale el siguiente gran modelo. Y así sucesivamente. En el mundo del mantenimiento, esto se llama "funcionar hasta fallar". Usamos y abusamos de estos aparatos hasta que se estropean o simplemente se desgastan y entonces compramos otro.
Como consumidores, esta mentalidad de correr para no fallar está tan extendida que no reconocemos muchas actividades de mantenimiento que realizamos a diario. Algo tan sencillo como aspirar el suelo es mantenimiento de la alfombra. Cambiar las bombillas y cortar el césped son otras dos formas de "mantener" nuestros hogares. Estas actividades básicas se trasladan a las industrias de la construcción, la fabricación y otras más en un campo muy sofisticado que simplemente llamamos mantenimiento.
Mientras que el consumidor medio puede cambiar de vez en cuando el aceite del coche o camión que le lleva al trabajo, el mundo del mantenimiento gestiona una lista de activos, o equipos, y la inversión en el mantenimiento de esos equipos para maximizar su vida útil y reducir el coste total de propiedad. Un equipo, como un coche o un camión, es algo más que un medio de transporte. Es una herramienta cara que repercute en la rentabilidad de la empresa y, por tanto, debe mantenerse para reducir el coste total de propiedad a lo largo de la vida del vehículo.
El 27 de enero de 2020, Acumatica anunció la adquisición de JAAS Systems (enlace: /corporate-newsroom/press-releases/acumatica-summit-opens-to-record-attendance-announcements-drive-leadership-position-in-midmarket-manufacturing/). Esta adquisición añadió el popular módulo de fabricación a la cartera de Acumatica. Con esa adquisición se creó la necesidad de una solución sencilla que diera soporte a la organización de mantenimiento que mantiene en funcionamiento los equipos de producción. Mientras que las organizaciones más grandes utilizan Enterprise Asset Management (EAM) para una gestión sofisticada de los equipos, la organización de mantenimiento confía en Computerized Maintenance Management Software (CMMS) para realizar un seguimiento de los equipos y programar el trabajo de mantenimiento preventivo (PM) necesario para mantener la planta funcionando de forma eficiente.
En la Cumbre de 2021, se preguntó a la dirección de Acumatica si había una solución de GMAO disponible o en desarrollo. La respuesta fue que en ese momento no y que la acogerían con agrado si alguien de la comunidad estaba dispuesto a trabajar en un proyecto de este tipo. La fase 1 ya está disponible de forma gratuita en GitHub como proyecto de la comunidad de Acumatica. Siga leyendo para obtener más información sobre el proyecto y dónde encontrarlo si desea probarlo o incluso contribuir al desarrollo en curso.
El proyecto comunitario de Acumatica
Buscando ir más allá de las ideas y habilidades de una persona, un grupo de MVP desarrolladores de Acumatica y otros expertos de la comunidad y dentro de Acumatica se reunieron para formar el proyecto. Geográficamente, este grupo se extiende de costa a costa en los EE.UU. y tan lejos como Sudáfrica. El líder del equipo presentó la idea del proyecto y dio continuidad al debate sobre el diseño, pero la forma del proyecto y los resultados, al final, serían un esfuerzo de equipo. A continuación se indican las empresas representadas por desarrolladores y líderes empresariales que participaron en el debate y/o codificaron la Fase 1 del proyecto:
El proyecto comunitario comenzó con la presentación de la idea a un ejecutivo de Acumatica que dirigió el proyecto a un responsable de producto de Acumatica. El debate resultante examinó la necesidad y el valor de un proyecto de este tipo. La pregunta más obvia era, sencillamente, ¿satisface Field Services esta necesidad? Tras un largo debate e indagación entre la comunidad, el proyecto demostró sus méritos, ya que se centraba específicamente en los equipos internos y el mantenimiento relacionado. Por el contrario, el módulo de servicios de campo se diseñó para dar soporte (y facturar) a clientes con requisitos de datos que hacen que la introducción de datos para un simple mantenimiento interno sea, como mínimo, un reto. Esto llevó al concepto básico de diseño de que el proyecto debe ser fácil de usar y permitir a un técnico de mantenimiento que puede no tener conocimientos informáticos mejorar su trabajo en lugar de crear cargas adicionales.
Decididos a apostar por la sencillez y la flexibilidad, que admiten una amplia variedad de casos de uso al hacer que casi todo sea opcional, el equipo se dispuso a diseñar y construir el proyecto. Tras semanas de reuniones para debatir casos de uso y crear documentos de diseño técnico, los elementos clave de la herramienta se crearon en un modelo de trabajo con muy poco detrás de las pantallas en términos de lógica empresarial. El modelo de trabajo basado en el concepto de diseño entonces vigente despejó el camino para debates de diseño más productivos, y se asignaron tareas a cada uno de los desarrolladores. Además de las pantallas propiamente dichas, se necesitaba lógica empresarial, revisión y mejora del CAD, la adición de funciones estándar como aprobaciones y atributos, así como puntos finales de servicios web y definiciones de pantallas para la aplicación móvil.
Para completar el proyecto, se creó un repositorio de GitHub para apoyar el desarrollo distribuido entre los distintos miembros del equipo. Se seleccionó a un miembro del equipo para gestionar el repositorio, y todo el trabajo, las incidencias y las revisiones se completarían en GitHub. Mediante la instalación de una instancia de desarrollo local para cada miembro del equipo de desarrollo y la sincronización con GitHub, se podía realizar un seguimiento de los cambios y resolver los conflictos. En al menos un caso, un elemento funcional del proyecto se rompió tras una fusión, y el uso de GitHub en Visual Studio permitió comparar claramente el código funcional con el nuevo código roto para localizar y resolver el problema.
Presentación de GMAO-Lite - Fase 1
La fase 1 del proyecto comunitario aporta las funciones básicas necesarias para apoyar las operaciones de mantenimiento. Los datos maestros (perfiles) permiten configurar los equipos, las clases de órdenes de trabajo, las mediciones y los modos de fallo. Las transacciones proporcionan la entrada de órdenes de trabajo tanto para plantillas de tipo PM como para órdenes de trabajo estándar para el trabajo real realizado. Una pantalla de procesamiento escanea el equipo en busca de trabajos PM programados a realizar y crea órdenes de trabajo estándar que se programan para su finalización. Existe un conjunto básico de informes para ver los detalles del equipo, los detalles de la orden de trabajo y una lista de las órdenes de trabajo. Una pantalla de preferencias permite añadir varios parámetros de configuración y aprobaciones estándar para el módulo.
El corazón de GMAO-Lite es el maestro de equipos, que representa máquinas completas, componentes individuales, herramientas compartidas e incluso "Otros" cuando no cabe ninguna otra categoría. La pantalla de equipos permite gestionar información algo estática sobre los equipos, pero también proporciona un lugar para centrarse en el mantenimiento y la fiabilidad de esos equipos.
Cuando se adquieren equipos para su fabricación, el fabricante de los mismos suele facilitar una Lista de Piezas de Recambio Recomendadas. La pestaña Lista de materiales permite añadir estos artículos al equipo siempre que estén configurados en la pantalla Artículos almacenados. La pestaña Programas permite adjuntar trabajos PM al equipo para definir el programa de mantenimiento repetitivo necesario para el equipo. El Historial de Órdenes de Trabajo simplemente muestra todas las órdenes de trabajo que han sido creadas haciendo referencia al equipo. Los modos de fallo proporcionan un lugar para registrar las formas en que el equipo puede fallar y proporcionar un comentario sobre cómo se mitiga ese medio de fallo.
La orden de trabajo consta de dos tipos. La orden de trabajo Plantilla es la definición de un trabajo PM que se programaría para el equipo. La orden de trabajo estándar es el trabajo real, ya sea creado para satisfacer una actividad PM definida o introducido manualmente por un usuario que solicita un servicio de mantenimiento. Las órdenes de trabajo estándar se pueden enrutar a través del proceso de aprobación estándar de Acumatica, completo con indicaciones de motivos opcionales o requeridos para la aprobación o el rechazo, y contienen cualquier atributo asociado con la clase de orden de trabajo seleccionada.
Las órdenes de trabajo se componen de una lista de instrucciones, u operaciones, que deben realizarse. Opcionalmente, cada operación puede tener requisitos de mano de obra especificados por el tipo de habilidad y las horas (en decimales) requeridas. Pueden especificarse los materiales y herramientas (equipos de tipo Herramienta) necesarios para la operación, así como las mediciones realizadas y los modos de fallo observados por el técnico de mantenimiento.
La pantalla de procesamiento puede configurarse en una programación estándar de Acumatica para convertir cualquier trabajo PM programado en órdenes de trabajo estándar.
Una vez creada la orden de trabajo estándar, puede requerir aprobación o avanzar al estado Pendiente de programación para que un planificador de mantenimiento asigne una fecha de finalización del trabajo. Una vez completada, la orden de trabajo actualizará la programación del equipo con la última fecha de finalización y establecerá automáticamente la siguiente fecha programada para volver a empezar el ciclo.
¿Dónde lo "pillo"?
Excelente pregunta. CMMS-Lite ya está disponible en el GitHub de Acumatica. (enlace: https://github.com/Acumatica/CMMS-Lite) Para vivir la vida al límite, la versión más reciente en desarrollo se encuentra bajo la rama Development. La versión actual considerada estable para pruebas debe estar bajo la rama Testing.
Descárgatelo. Pruébelo. Aporta tus comentarios. "Involúcrese y hágalo suyo. La fase 1 ya está disponible y optimizada para Acumatica 2022 R1.
