Hola Mi nombre es Andrey Grachev y soy gerente de producto en SIBUR.
En SIBUR, regularmente se realizan "paradas de reparación". Esto es algo como el mantenimiento preventivo, el mantenimiento programado y la reparación, durante el cual la planta completa o parte de ella se detiene por completo. Dichas reparaciones son necesarias para garantizar el buen funcionamiento de la empresa en el futuro. Pero, está claro que en este momento la planta no gana dinero, por lo que es importante hacer todo lo más rápido posible. Para ello, debe planificar y llevar a cabo el trabajo de manera óptima. Entonces surgió la idea de crear su propia aplicación móvil para detener las reparaciones, lo que haría que el proceso de administración del trabajo sea más organizado y minimice la pérdida de tiempo. Le diremos cómo lo hicimos, qué sucedió al final y por qué nos esforzamos por ahora.
¿Por qué es todo esto necesario?
Para comenzar, te diré qué es una reparación de parada. Este es un conjunto de medidas para la reparación de una gran cantidad de equipos de la planta, que deben llevarse a cabo en un determinado período de tiempo, por ejemplo, una vez al año, un trimestre o en otros intervalos. En este momento, la producción se detiene, el contratista llama a la planta, se repara todo lo que se necesita. Puede durar una semana, varias semanas, en Sibur-Khimprom, por ejemplo, la planta se detuvo durante casi un mes.
Tal reparación a gran escala de casi todos los equipos en la planta puede presentarse como un gran proyecto. Tiene operaciones preparatorias cuando la planta reduce gradualmente la energía y se detiene. Hay una fase activa, cuando hay un reemplazo y mantenimiento de unidades, y la fase de la reanudación de la producción. 10-11 meses antes del inicio del trabajo de reparación, todas las personas responsables comienzan a planificar este procedimiento, se crean pedidos de pedidos para el trabajo que debe realizarse. Por lo tanto, al comienzo del trabajo, se acumula un gran conjunto de tareas que deben completarse dentro del tiempo asignado para la reparación. Estas tareas a menudo están interconectadas: sin completar una, no puede iniciar otra. Por ejemplo, no podemos reparar algo en la bomba, porque primero debemos apagarlo, quitar el equipo que interfiere con el desmantelamiento de esta unidad y solo luego trabajar con la bomba. A partir de estas interconexiones se construye el término de la reparación de parada completa.
Detener las reparaciones tienen una "ruta crítica". Como regla general, año tras año en cada empresa hay operaciones constantes, sin las cuales la planta no puede iniciarse. Resulta que la ruta crítica es el tiempo más largo que se puede dedicar a las reparaciones de paradas. Todo lo demás está planeado de modo que corresponda al tiempo de la reparación de parada, o al menos no lo alargue. Esto significa que estos trabajos deben realizarse en paralelo.
¿Cómo sucedió todo antes?
Todo esto hasta ahora se ha hecho así: las personas en SAP crean pedidos dentro de un año que están marcados como que requieren detener la reparación. Cuando llega el momento, todos los pedidos de SAP se cargan en la llamada "lista defectuosa", en base a la cual los mecánicos desarrollan un cronograma para detener las reparaciones. Estos son cientos de líneas en Excel, a partir de las cuales debe comprender la lista del trabajo necesario, cuánto tiempo y las personas lo necesitarán, construir la lógica a tiempo: qué se reparará para qué. En todas las empresas SIBUR, esto se hace casi de la misma manera, a mano en Excel. Solo una empresa, Sibur-Khimprom, aprendió a hacer esto en el servicio de planificación Primavera. Para nosotros, es extremadamente inconveniente en términos de interfaz y scripts de usuario.
Por supuesto, buscamos otros servicios, como MS Project. Pero su funcionalidad era insuficiente para nosotros o requería mucho tiempo y, en consecuencia, habría que gastar dinero en capacitación. Por lo tanto, decidimos desarrollar nuestro propio producto.
Cuando comenzamos, la imagen en SIBUR era así: todos están tratando de planificar un proyecto serio en tablas de Excel. Todo esto se imprime, se ponen firmas de personas interesadas que aprueban el cronograma. Además, durante una reparación de parada, las personas se reúnen en reuniones de planificación y se agrupan en la sede, donde se muestra el archivo de Excel en la pantalla, y los porcentajes de completar las tareas se establecen en él.
Se necesitan numerosas y periódicas reuniones de este tipo para reunir y actualizar la información. El representante del contratista cuenta lo que se ha hecho, cuáles son los problemas, y el representante del cliente anota todo en un documento en papel. Luego, otra persona recopila información de cada persona responsable, la consolida y prepara un informe centralizado. Todo es complicado y largo, la gente permanece en el trabajo hasta la noche.
Primer prototipo
Pensamos que la gestión de cualquier proyecto se basa en cosas básicas: procesos de planificación y transparencia de lo que sucede en un momento dado. Para garantizar la transparencia, es necesario durante la reparación proporcionar al sistema datos actuales sobre lo que está sucediendo. Estudiamos los procesos de producción en detalle, entendimos cómo funciona la reparación de paradas y propusimos una estructura en la que puede programar. Al principio, decidimos no romper el proceso existente y no entrar en los guiones de las personas. Quien solía planear en exel, déjalo planear. Quien aprendió en Primavera, déjelo trabajar allí.
Inicialmente, nuestro producto era un sistema de visualización para los gráficos que hacen. Desarrollamos una aplicación para iOS, Android y una versión de navegador web. El cronograma se carga en el servicio junto con los responsables, ejecutores y controladores: tres roles principales durante la reparación de la parada. Este es un punto importante, por lo que me detendré en él con más detalle y mostraré cómo funciona todo con un ejemplo.
Hay una tarea para reparar la bomba.
La tarea tiene un ejecutor: este es el capataz de la organización contratante, que repara un objeto en particular.
Responsable: es responsable de garantizar que todo esté preparado para la reparación, debe entregar el objeto a reparar y luego aceptarlo, confirmando que el contratista ha completado el trabajo en su totalidad y puede comenzar a realizar otras tareas. Como regla, esto lo hace el mecánico de la instalación.
Los supervisores son la alta dirección de la empresa, personas que desean ver constantemente el cumplimiento del trabajo con el cronograma.
Roles personalizados
Las personas responsables y los artistas tienen acceso tanto a la aplicación como a la versión web. El contratista ve las tareas que se le asignan para hoy, así como para la reparación completa de la parada. El intérprete tiene una secuencia de estas tareas. Al comenzar a trabajar, debe presionar el botón correspondiente, agregar al programa la cantidad de personas que están trabajando en esta tarea. Es importante que la gerencia sepa si la cantidad de personas que trabajan en esta tarea corresponde a la cantidad que han planeado. El contratista presiona el botón y el trabajo ha comenzado. La aplicación monitorea la duración del proceso. En el caso de que se pase el plazo, y el contratista no presionó el botón de apagado, las notificaciones de demora se envían a la persona responsable. Entonces, la persona a cargo va y mira lo que sucedió.
Si todo está bien y en el momento establecido, el contratista completa el trabajo, hace clic en el botón "Enviar informe" y escribe que ha completado el trabajo al 100%. Luego, la persona responsable también recibe una notificación de que todo está hecho, debe ir y ver el resultado. Así es como funciona el modelo a seguir.
Es posible que las personas no tengan en cuenta todo lo que sucede en el sitio que se les ha encomendado, ven un horario para cada día y reciben notificaciones sobre el proceso.
También brindamos la oportunidad de trabajar con tareas que duran más de un día. Esto funciona de la misma manera que con las tareas pequeñas, solo que al final de cada día debe realizar informes en el programa: por ejemplo, hoy el trabajo se ha completado en un 50%. La persona responsable recibe una notificación y debe verificar si esta información es verdadera. Si no, rechaza el informe y obliga al contratista a poner otro número.
En cuanto a la versión web, su funcionalidad es ligeramente diferente; está destinada más a los controladores: gestión empresarial. Nos dimos cuenta de que las personas están acostumbradas a percibir información sobre el progreso en todos los trabajos en los diagramas de Gantt. Ven los hechos del plan, las relaciones, las estadísticas sobre la movilización de recursos humanos, cuántas personas queríamos ver en la planta durante la reparación y cuántas obras después del hecho. Y, en consecuencia, para todas las instalaciones de producción, el controlador puede ver el progreso del trabajo, ver rápidamente el retraso del cronograma.
Trabajo no programado
Durante una reparación de parada, siempre aparece trabajo adicional oculto que no se puede ignorar. Por ejemplo, cuando se desmonta el equipo, hay una falla en la parte que no es visible en el estado ensamblado de la unidad. Estas tareas también se incluyen en el cronograma, se toma la decisión de que también realicemos trabajos ocultos durante la reparación de parada. Todo se ingresa en el programa. Si este trabajo adicional afecta la duración de la reparación de parada completa, el programa pospondrá automáticamente todas las demás tareas por el tiempo que lleve completar este trabajo oculto. Lo mismo es cierto en el caso opuesto: si algunas tareas se completan más rápido de lo planeado, el cronograma se optimiza.
Para tales casos, el equipo y yo diseñamos un sistema de mensajería serio y notificaciones automáticas para advertir a las personas que están comenzando a trabajar que pueden hacerlo tarde o temprano. Y aquí se reveló un momento interesante. Más o menos fuimos demasiado lejos con estas notificaciones.
¿Dónde nos equivocamos?
El hecho es que trajimos allí un "cronograma de cuarto nivel": un plan amplio y detallado para todas las reparaciones de paradas. Para nuestros propósitos, resultó ser demasiado detallado. Resultó que los usuarios recibieron notificaciones sobre cada pequeña cosa, lo que puede ser insignificante para el proceso en su conjunto. Después de todo, cuando una persona trabaja sin una solicitud, no mira el horario de trabajo todos los días. Él solo sabe: para reparar una bomba condicional, debe realizar muchas operaciones (desarmarla, limpiarla, reemplazar las unidades, ensamblar, verificar, etc.). Y la persona que verifica cómo funciona el contratista no necesita controlar el paso de cada una de estas etapas. Es suficiente mirar el resultado del trabajo en su conjunto y el cumplimiento de los plazos establecidos.
Es decir, si procedemos a las notificaciones, el controlador debe conocer dos eventos: el comienzo de la reparación y la finalización de la reparación. Por lo tanto, ajustamos la aplicación sobre la marcha. Para empezar, pidieron cambiar los horarios y ampliarlos. Luego abandonaron algunos eventos menores y todo comenzó a funcionar sin problemas, el usuario comenzó a distraerse menos con las notificaciones.
Cual es el resultado?
Cuando finalizamos la aplicación, obtuvimos un servicio que nos permite tener constantemente información actualizada sobre la empresa: qué se está reparando, en qué etapa del proceso y cuándo es la fecha límite. Esto le permite planificar el trabajo y preparar un horario. Esencialmente, este sistema de gestión de proyectos de reparación de paradas es un administrador de tareas avanzado.
Inicialmente, declaramos la métrica principal para reducir el tiempo de reparación de parada. Está claro cómo evaluar esto en términos de dinero: usted sabe cuánto cuesta una hora o un día de inactividad de producción. Por lo tanto, nos propusimos el objetivo de acelerar la realización de trabajos de reparación. Ahora vemos que la analítica también es importante: una evaluación de lo que sucede durante una reparación de parada, hasta el más mínimo detalle. Si registramos las acciones del usuario, cómo y cuándo aceptó el trabajo, qué comentarios escribió, qué salió mal, cómo funciona la coordinación, vemos la formación de defectos ocultos, entendemos quién trabaja, luego puede analizar y comprender mucho sobre los procesos de producción. Solo para su evaluación, tenemos una "Función de eficiencia de producción". Después de cada reparación, se recopila una cierta cantidad de datos: cuánto dinero se gastó, cuánto se planificó, qué tan rápido salimos de la reparación.
Por supuesto, prevemos un mayor desarrollo del proyecto. Hasta ahora, este es solo el primer paso para recopilar estadísticas sobre las reparaciones de paradas. Queremos recopilar suficientes datos para poder trabajar con ellos y sacar más conclusiones. Por ejemplo, necesitamos reparar la bomba. Esto lo hacen X personas y lleva Y tiempo. En consecuencia, toda la planificación posterior de cualquier reparación ya puede basarse en este modelo. Podremos planificar el trabajo en función del hecho de que ya hay un analista confirmado por los datos, lo que significa que no sobreestimamos ni subestimamos las expectativas en términos de tiempo.
Nuestra aplicación puede ser utilizada no solo para la producción. Esta puede ser la gestión de la construcción de capital, cualquier otra área donde se aplique un enfoque similar a la planificación del trabajo.
¿Quién trabajó en el proyecto?
Un grupo de personas dentro de SIBUR y contratistas trabajaron en el proyecto. El desarrollo del lado del servidor y el front-end fue totalmente del contratista, nosotros dentro del equipo nos dedicamos al diseño de la lógica de la aplicación y la interfaz. Los consultores incluyeron al gerente de reparación de interrupciones, el mecánico que trabajó directamente en los horarios, el ingeniero jefe que monitorea el proceso y el director de la empresa.
Todo sobre todo (investigación, pilotaje, interfaces y desarrollo) tomó seis meses.
¿Cuál es el futuro del producto?
En el futuro cercano: varias actualizaciones clave. Si bien existen problemas con el cálculo de los volúmenes físicos en el marco de una tarea, por ejemplo, para accesorios reemplazados. No solo los indicadores relativos, sino también absolutos son importantes para nuestros colegas en la empresa: necesitamos comprender cuánto porcentaje del trabajo se ha completado, cuántas barras de refuerzo del 1000 condicional ya se han reemplazado. Ahora esto no se tiene en cuenta en el horario de trabajo de la aplicación. Pensaremos cómo implementar esto. Hasta ahora, solo podemos hablar sobre el progreso del trabajo realizado y el porcentaje de su finalización, para solucionar situaciones de retraso o antes de lo previsto.
Es posible (y ya tenemos tal comprensión), transferiremos todo el proceso de planificación de una reparación de parada a nuestro proyecto. Quizás, al mismo tiempo, todo el desarrollo moverá la casa.
Estaremos encantados de ver nuevos colegas en el equipo: propietarios de productos, diseñadores de productos, desarrolladores. La lista de vacantes actuales en el enlace a
hh.ru.