Salut Je m'appelle Andrey Grachev et je suis chef de produit chez SIBUR.
Au SIBUR, des «arrêts de réparation» ont lieu régulièrement. Il s'agit de quelque chose comme la maintenance préventive, la maintenance planifiée et les réparations, pendant lesquelles l'installation entière ou une partie de celle-ci est complètement arrêtée. Ces réparations sont nécessaires pour assurer le bon fonctionnement de l'entreprise à l'avenir. Mais, il est clair qu'à l'heure actuelle, l'usine ne fait pas d'argent, il est donc important de tout faire le plus rapidement possible. Pour cela, vous devez planifier et exécuter le travail de manière optimale. L'idée est donc venue de créer votre propre application mobile pour arrêter les réparations, ce qui rendrait le processus de gestion du travail plus organisé, minimiserait la perte de temps. Nous vous dirons comment nous l'avons fait, ce qui s'est finalement produit et ce que nous recherchons pour le moment.
Pourquoi tout cela est-il nécessaire?
Pour commencer, je vais vous dire ce qu'est une réparation d'arrêt. Il s'agit d'un ensemble de mesures pour la réparation d'un grand nombre d'équipements d'usine, qui doivent être effectuées à une certaine période de temps - par exemple, une fois par an, par trimestre ou à d'autres intervalles. A ce moment, la production est arrêtée, l'entrepreneur appelle à l'usine, tout ce qui est nécessaire est réparé. Cela peut durer une semaine, plusieurs semaines, à Sibur-Khimprom, par exemple, l'usine s'est arrêtée pendant près d'un mois.
Une telle réparation à grande échelle de presque tous les équipements de l'usine peut être présentée comme un grand projet. Il a des opérations préparatoires lorsque l'usine réduit progressivement la puissance et s'arrête. Il y a une phase active, quand il y a remplacement et maintenance des unités, et la phase de reprise de production. 10-11 mois avant le début des travaux de réparation, toutes les personnes responsables commencent à planifier cette procédure, des ordres de commande pour les travaux à réaliser sont créés. Ainsi, au début des travaux, un important pool de tâches s'accumule et doit être achevé dans le temps imparti pour la réparation. Ces tâches sont souvent interconnectées: sans en terminer une, vous ne pouvez pas en démarrer une autre. Par exemple, nous ne pouvons pas réparer quelque chose dans la pompe, car nous devons d'abord l'éteindre, retirer l'équipement qui interfère avec le démontage de cet appareil, et ensuite seulement travailler avec la pompe. À partir de ces interconnexions, le terme de la réparation complète de l'arrêt est construit.
Les réparations d'arrêt ont un «chemin critique». En règle générale, d'année en année dans chaque entreprise, il y a des opérations constantes, sans lesquelles l'usine ne peut pas démarrer. Il s'avère que le chemin critique est le temps le plus long qui peut être consacré à l'arrêt des réparations. Tout le reste est prévu de manière à ce qu'il corresponde au moment de l'arrêt de la réparation, ou du moins ne l'allonge pas. Cela signifie que ces travaux doivent se dérouler en parallèle.
Comment tout s'est-il passé avant?
Jusqu'à présent, tout cela a été fait ainsi: les employés de SAP créent des commandes dans un délai d'un an qui sont marquées comme nécessitant un arrêt de la réparation. Le moment venu, toutes les commandes de SAP sont téléchargées dans la soi-disant «liste défectueuse», sur la base de laquelle les mécaniciens élaborent un calendrier pour l'arrêt des réparations. Ce sont des centaines de lignes dans Excel, à partir desquelles vous devez ensuite comprendre la liste des travaux nécessaires, combien de temps et de personnes en auront besoin, construire une logique dans le temps: ce qui sera réparé pour quoi. Dans toutes les entreprises SIBUR, cela se fait presque de la même manière - à la main dans Excel. Une seule entreprise, Sibur-Khimprom, a appris à le faire dans le service de planification Primavera. Pour nous, c'est extrêmement gênant en termes d'interface et de scripts utilisateur.
Bien sûr, nous nous sommes tournés vers d'autres services, tels que MS Project. Mais leur fonctionnalité était soit insuffisante pour nous, soit beaucoup de temps et, par conséquent, de l'argent devrait être dépensé pour la formation. Nous avons donc décidé de développer notre propre produit.
Lorsque nous avons commencé, l'image dans SIBUR était la suivante: tout le monde essaie de planifier un projet sérieux dans des tableaux Excel. Tout cela est imprimé, les signatures des personnes intéressées approuvant le calendrier sont mises. De plus, lors d'un arrêt de la réparation, les personnes se réunissent lors des réunions de planification et sont regroupées dans le siège social, où le fichier Excel est affiché à l'écran et les pourcentages de réalisation des tâches y sont définis.
De nombreuses réunions régulières de ce type sont nécessaires pour rassembler et mettre à jour les informations. Le représentant de l'entrepreneur indique ce qui a été fait, quels sont les problèmes et le représentant du client note tout dans un document papier. Ensuite, une autre personne recueille des informations auprès de chaque personne responsable, les consolide et prépare un rapport centralisé. Tout est compliqué et long, les gens restent au travail jusqu'à la nuit.
Premier prototype
Nous pensions que la gestion de tout projet est basée sur des éléments fondamentaux: les processus de planification et la transparence de ce qui se passe à un moment donné. Pour garantir la transparence, il est nécessaire pendant la réparation de fournir au système des données actuelles sur ce qui se passe. Nous avons étudié en détail les processus de production, compris le fonctionnement des arrêts de réparation et proposé une structure dans laquelle vous pouvez planifier. Au début, nous avons décidé de ne pas interrompre le processus existant et de ne pas entrer dans les scripts des gens. Qui avait l'habitude de planifier en exel - laissez-le planifier. Celui qui a appris à Primavera, laissez-le travailler là-bas.
Initialement, notre produit était un système de visualisation pour les graphiques qu'ils font. Nous avons développé une application pour iOS, Android et une version de navigateur Web. L'horaire est chargé dans le service avec les responsables, les exécuteurs et les contrôleurs - trois rôles principaux pendant l'arrêt de la réparation. C'est un point important, je vais donc m'y attarder plus en détail et montrer comment tout fonctionne avec un exemple.
Il y a une tâche pour réparer la pompe.
La tâche a un exécuteur testamentaire - c'est le contremaître de l'organisation contractante, qui répare un objet particulier.
Responsable - est responsable de s'assurer que tout est prêt pour la réparation, il doit remettre l'objet pour réparation, puis l'accepter, confirmant que l'entrepreneur a terminé le travail dans son intégralité et peut commencer à effectuer d'autres tâches. En règle générale, cela est fait par le mécanicien d'installation.
Les superviseurs sont la haute direction de l'entreprise, des gens qui veulent constamment voir la conformité du travail avec le calendrier.
Rôles personnalisés
Les personnes responsables et les artistes interprètes ou exécutants ont accès à la fois à l'application et à la version Web. L'entrepreneur voit les tâches qui lui sont assignées pour aujourd'hui, ainsi que pour la réparation complète de l'arrêt. L'interprète a une séquence de ces tâches. Au début du travail, il doit appuyer sur le bouton correspondant, ajouter au programme le nombre de personnes qui travaillent sur cette tâche. Il est important que la direction sache si le nombre de personnes travaillant sur cette tâche correspond au nombre qu'elles ont prévu. L'entrepreneur appuie sur le bouton et les travaux ont commencé. L'application surveille la durée du processus. Dans le cas où le délai est dépassé et que le contractant n'a pas appuyé sur le bouton d'arrêt, des notifications de retard sont envoyées à la personne responsable. Ainsi, le responsable s'en va et regarde ce qui s'est passé.
Si tout va bien et à l'heure fixée, l'entrepreneur termine le travail, il clique sur le bouton «Soumettre le rapport» et écrit qu'il a terminé le travail à 100%. Ensuite, la personne responsable reçoit également une notification que tout est fait, vous devez aller voir le résultat. Voici comment fonctionne le modèle de rôle.
Les gens peuvent ne pas garder à l'esprit tout ce qui se passe sur le site qui leur est confié, ils voient un horaire pour chaque jour et reçoivent des notifications sur le processus.
Nous avons également fourni l'opportunité de travailler sur des tâches qui durent plus d'une journée. Cela fonctionne de la même manière qu'avec les petites tâches, seulement à la fin de chaque journée, vous devez faire des rapports dans le programme: par exemple, aujourd'hui, le travail est terminé à 50%. La personne responsable reçoit une notification et doit vérifier si ces informations sont véridiques. Sinon, il rejette le rapport et oblige l'entrepreneur à mettre un autre numéro.
Quant à la version web, sa fonctionnalité est légèrement différente; elle est plutôt destinée aux contrôleurs - gestion d'entreprise. Nous avons réalisé que les gens sont habitués à percevoir des informations sur l'avancement de tous les travaux dans les diagrammes de Gantt. Ils voient les faits du plan, les relations, les statistiques sur la mobilisation des ressources humaines, combien de personnes nous voulions voir à l'usine pendant la réparation, et combien de travaux après coup. Et, en conséquence, pour toutes les installations de production, le contrôleur peut voir l'avancement des travaux, voir rapidement le décalage par rapport au calendrier.
Travail imprévu
Lors d'un arrêt de la réparation, un travail supplémentaire masqué apparaît toujours et ne peut être ignoré. Par exemple, lors du démontage de l'équipement, il y a une panne dans la pièce qui n'est pas visible à l'état assemblé de l'unité. Ces tâches sont également incluses dans le calendrier, une décision est prise que nous effectuions également des travaux cachés lors de l'arrêt de la réparation. Tout est entré dans le programme. Si ce travail supplémentaire affecte la durée de la réparation complète de l'arrêt, le programme reporte automatiquement toutes les autres tâches pour le temps nécessaire pour terminer ce travail masqué. Il en va de même dans le cas contraire - si certaines tâches sont effectuées plus rapidement que prévu, le planning est optimisé.
Pour de tels cas, l'équipe et moi avons conçu un système de messagerie sérieux et des notifications push pour avertir les personnes qui commencent à travailler qu'elles peuvent le faire tôt ou tard. Et ici, un moment intéressant a été révélé. Nous sommes allés trop loin avec ces notifications.
Où nous sommes-nous trompés?
Le fait est que nous y avons apporté un «calendrier de quatrième niveau» - un grand plan détaillé pour toutes les réparations d'arrêt. Pour nos besoins, il s'est avéré trop détaillé. Il s'est avéré que les utilisateurs ont reçu des notifications sur chaque petite chose, ce qui peut être insignifiant pour le processus dans son ensemble. Après tout, lorsqu'une personne travaille sans application, elle ne regarde pas l'horaire de travail tous les jours. Il sait juste: pour réparer une pompe conditionnelle, vous devez effectuer de nombreuses opérations (la démonter, la nettoyer, remplacer les unités, assembler, vérifier, etc.). Et la personne qui vérifie le fonctionnement de l'entrepreneur n'a pas besoin de contrôler le passage de chacune de ces étapes. Il suffit de regarder le résultat du travail dans son ensemble et le respect des délais fixés.
Autrement dit, si nous procédons à des notifications, le contrôleur doit connaître deux événements: le début de la réparation et l'achèvement de la réparation. Par conséquent, nous avons ajusté l'application en déplacement. Pour commencer, ils ont demandé de modifier les horaires et de les agrandir. Ensuite, ils ont abandonné certains événements mineurs et tout a commencé à fonctionner plus facilement, l'utilisateur a commencé à être moins distrait par les notifications.
Quel est le résultat?
Lorsque nous avons finalisé la demande, nous avons obtenu un service qui nous permet d'avoir constamment des informations à jour sur l'entreprise: ce qui est réparé, à quelle étape du processus et quand est la date limite. Cela vous permet de planifier le travail et de préparer un calendrier. Essentiellement, ce système de gestion de projet de réparation d'arrêt est un gestionnaire de tâches avancé.
Au départ, nous avons déclaré la métrique principale pour réduire le temps d'arrêt des réparations. Il est clair comment évaluer cela en termes d'argent: vous savez combien coûte une heure ou une journée de temps d'arrêt de production. Par conséquent, nous nous sommes fixé pour objectif d'accélérer la tenue des travaux de réparation. Nous voyons maintenant que l'analyse est également importante - une évaluation de ce qui se passe lors d'une réparation d'arrêt, dans les moindres détails. Si nous enregistrons les actions de l'utilisateur, comment et quand il a accepté le travail, quels commentaires il a écrits, ce qui s'est mal passé, comment la coordination se passe, nous voyons la formation de défauts cachés, comprenons qui fonctionne, alors vous pouvez analyser et comprendre beaucoup de choses sur les processus de production. Juste pour leur évaluation, nous avons une «fonction d'efficacité de production». Après chaque réparation, une certaine quantité de données est collectée: combien d'argent a été dépensé, combien a été planifié, à quelle vitesse nous sommes sortis de la réparation.
Bien entendu, nous envisageons de poursuivre le développement du projet. Jusqu'à présent, ce n'est que la première étape de la collecte de statistiques sur l'arrêt des réparations. Nous voulons collecter suffisamment de données pour pouvoir travailler avec et tirer plus de conclusions. Par exemple, nous devons réparer la pompe. Cela est fait par X personnes et cela prend du temps. Par conséquent, toute planification ultérieure de toute réparation peut déjà être basée sur ce modèle. Nous pourrons planifier les travaux en fonction du fait qu'il existe déjà un analyste confirmé par les données, ce qui signifie que nous ne surestimons pas ou ne sous-estimons pas les attentes en termes de temps.
Notre application peut être utilisée non seulement pour la production. Il peut s'agir de la gestion de la construction d'immobilisations, de tout autre domaine où une approche similaire de la planification des travaux est appliquée.
Qui a travaillé sur le projet?
Un groupe de personnes à l'intérieur de SIBUR et des entrepreneurs ont travaillé sur le projet. Le développement côté serveur et front-end a été entièrement confié à l'entrepreneur, au sein de l'équipe nous avons été engagés dans la conception de la logique applicative et de l'interface. Les consultants comprenaient le directeur de la réparation des pannes, le mécanicien qui travaillait directement sur les horaires, l'ingénieur en chef qui surveille le processus et le directeur de l'entreprise.
Tout sur tout (recherche, pilotage, interfaces et développement) a pris six mois.
Quel est l'avenir du produit?
Dans un avenir proche - plusieurs mises à jour clés. Bien qu'il y ait des problèmes avec le calcul des volumes physiques dans le cadre d'une tâche, par exemple, pour les raccords remplacés. Non seulement des indicateurs relatifs, mais aussi absolus sont importants pour nos collègues de l'entreprise: nous devons comprendre combien de pour cent des travaux ont été achevés, combien de barres d'armature du conditionnel 1000 ont déjà été remplacées. Maintenant, cela n'est pas pris en compte dans le calendrier de travail de l'application. Nous réfléchirons à la manière de mettre cela en œuvre. Jusqu'à présent, nous ne pouvons parler que de l'avancement des travaux effectués et du pourcentage de leur achèvement, pour corriger les situations de retard ou d'avance.
Il est possible (et nous avons déjà une telle compréhension), nous transférerons l'ensemble du processus de planification d'une réparation d'arrêt à notre projet. Peut-être, en même temps, l'ensemble du développement va déplacer la maison.
Nous serons heureux de voir de nouveaux collègues dans l'équipe: propriétaires de produits, concepteurs de produits, développeurs. La liste des postes vacants actuels sur le lien vers
hh.ru.