Hai Nama saya Andrey Grachev, dan saya seorang manajer produk di SIBUR.
Di SIBUR, “hentikan perbaikan” secara rutin dilakukan. Ini adalah sesuatu seperti pemeliharaan preventif, pemeliharaan terjadwal dan perbaikan, di mana seluruh pabrik atau bagiannya benar-benar dihentikan. Perbaikan semacam itu diperlukan untuk memastikan kelancaran operasi perusahaan di masa depan. Tapi, jelas bahwa saat ini tanaman tidak menghasilkan uang, jadi penting untuk melakukan semuanya secepat mungkin. Untuk ini, Anda perlu merencanakan dan melaksanakan pekerjaan secara optimal. Maka muncul ide untuk membuat aplikasi seluler Anda sendiri untuk perbaikan berhenti, yang akan membuat proses mengelola pekerjaan lebih teratur, meminimalkan hilangnya waktu. Kami akan memberi tahu Anda bagaimana kami melakukannya, apa yang terjadi pada akhirnya dan apa yang kami perjuangkan saat ini.
Mengapa semua ini perlu?
Untuk memulai, saya akan memberi tahu Anda apa itu perbaikan berhenti. Ini adalah serangkaian tindakan untuk perbaikan sejumlah besar peralatan pabrik, yang harus dilakukan pada periode waktu tertentu - misalnya, setahun sekali, kuartal atau pada interval lainnya. Pada saat ini, produksi dihentikan, panggilan kontraktor di pabrik, semua yang diperlukan diperbaiki. Ini bisa berlangsung seminggu, beberapa minggu, di Sibur-Khimprom, misalnya, pabrik berhenti selama hampir sebulan.
Perbaikan skala besar hampir semua peralatan di pabrik dapat disajikan sebagai proyek besar. Dia memiliki operasi persiapan ketika pabrik secara bertahap mengurangi daya dan berhenti. Ada fase aktif, ketika ada penggantian dan pemeliharaan unit, dan fase dimulainya kembali produksi. 10-11 bulan sebelum dimulainya pekerjaan perbaikan, semua orang yang bertanggung jawab mulai merencanakan prosedur ini, pesanan pesanan untuk pekerjaan yang perlu dilakukan dibuat. Dengan demikian, pada awal pekerjaan, kumpulan tugas yang besar diakumulasikan yang harus diselesaikan dalam waktu yang ditentukan untuk perbaikan. Tugas-tugas ini sering saling berhubungan: tanpa menyelesaikan satu, Anda tidak dapat memulai yang lain. Misalnya, kita tidak dapat memperbaiki sesuatu di pompa, karena kita harus mematikannya terlebih dahulu, lepaskan peralatan yang mengganggu pembongkaran unit ini, dan baru kemudian bekerja dengan pompa. Dari interkoneksi ini, istilah perbaikan seluruh stop dibangun.
Stop perbaikan memiliki "jalur kritis". Sebagai aturan, dari tahun ke tahun di setiap perusahaan ada operasi konstan, tanpanya pabrik tidak dapat dimulai. Ternyata jalur kritis adalah waktu terlama yang dapat dihabiskan untuk menghentikan perbaikan. Semua yang lain direncanakan sehingga sesuai dengan waktu perbaikan berhenti, atau setidaknya tidak memperpanjangnya. Ini berarti bahwa pekerjaan ini harus dilakukan secara paralel.
Bagaimana semuanya terjadi sebelumnya?
Semua ini sampai sekarang telah dilakukan seperti ini: orang-orang di SAP membuat pesanan dalam waktu satu tahun yang ditandai sebagai membutuhkan perbaikan berhenti. Ketika saatnya tiba, semua pesanan dari SAP diunggah ke yang disebut "daftar cacat", atas dasar mana mekanik mengembangkan jadwal untuk perbaikan berhenti. Ini adalah ratusan baris di Excel, dari mana Anda kemudian perlu memahami daftar pekerjaan yang diperlukan, berapa banyak waktu dan orang akan membutuhkannya, membangun logika dalam waktu: apa yang akan diperbaiki untuk apa. Di semua perusahaan SIBUR, ini dilakukan dengan cara yang hampir sama - dengan tangan di Excel. Hanya satu perusahaan, Sibur-Khimprom, yang belajar bagaimana melakukan ini dalam layanan perencanaan Primavera. Bagi kami, itu sangat merepotkan dalam hal antarmuka dan skrip pengguna.
Tentu saja, kami melihat ke layanan lain, seperti Proyek MS. Tetapi fungsi mereka tidak cukup bagi kami, atau banyak waktu dan, oleh karena itu, uang harus dihabiskan untuk pelatihan. Karena itu, kami memutuskan untuk mengembangkan produk kami sendiri.
Ketika kami mulai, gambar di SIBUR seperti ini: semua orang mencoba merencanakan proyek serius dalam tabel Excel. Semua ini dicetak, tanda tangan orang yang berminat menyetujui jadwal dimasukkan. Selanjutnya, selama perbaikan berhenti, orang-orang berkumpul dalam rapat perencanaan dan dikelompokkan ke dalam kantor pusat, di mana file Excel ditampilkan di layar, dan persentase tugas penyelesaian diatur di dalamnya.
Diperlukan banyak pertemuan rutin seperti ini untuk menyatukan dan memperbarui informasi. Perwakilan kontraktor memberi tahu apa yang telah dilakukan, apa masalahnya, dan perwakilan pelanggan mencatat semuanya dalam dokumen kertas. Kemudian orang lain mengumpulkan informasi dari masing-masing orang yang bertanggung jawab, mengkonsolidasikannya dan menyiapkan laporan tersentralisasi. Semuanya rumit dan panjang, orang-orang tetap bekerja sampai malam.
Prototipe pertama
Kami berpikir bahwa manajemen setiap proyek didasarkan pada hal-hal dasar: proses perencanaan dan transparansi apa yang terjadi pada saat tertentu. Untuk memastikan transparansi, perlu selama perbaikan untuk menyediakan sistem dengan data terkini tentang apa yang terjadi. Kami mempelajari proses produksi secara terperinci, memahami cara menghentikan perbaikan, dan mengusulkan struktur tempat Anda dapat menjadwalkan. Pada awalnya, kami memutuskan untuk tidak menghentikan proses yang ada dan tidak masuk ke skrip orang. Yang dulu merencanakan di exel - biarkan dia merencanakan. Siapa pun yang belajar di Primavera, biarkan dia bekerja di sana.
Awalnya, produk kami adalah sistem visualisasi untuk grafik yang mereka buat. Kami mengembangkan aplikasi untuk iOS, Android dan versi browser web. Jadwal dimuat ke dalam layanan bersama dengan yang bertanggung jawab, pelaksana dan pengendali - tiga peran utama selama perbaikan berhenti. Ini adalah poin penting, jadi saya akan membahasnya lebih detail dan menunjukkan bagaimana semuanya bekerja dengan sebuah contoh.
Ada tugas untuk memperbaiki pompa.
Tugas tersebut memiliki pelaksana - ini adalah mandor organisasi kontraktor, yang memperbaiki objek tertentu.
Bertanggung jawab - bertanggung jawab untuk memastikan bahwa semuanya dipersiapkan untuk diperbaiki, ia harus menyerahkan objek untuk diperbaiki dan kemudian menerimanya, membenarkan bahwa kontraktor telah menyelesaikan pekerjaan secara penuh dan dapat mulai melakukan tugas-tugas lain. Biasanya, ini dilakukan oleh mekanik instalasi.
Pengawas adalah manajemen puncak perusahaan, orang-orang yang ingin terus-menerus melihat kepatuhan pekerjaan dengan jadwal.
Peran khusus
Orang dan penanggung jawab yang bertanggung jawab memiliki akses ke aplikasi dan ke versi web. Kontraktor melihat tugas-tugas yang ditugaskan kepadanya untuk hari ini, serta untuk seluruh perbaikan berhenti. Pelaku memiliki urutan tugas-tugas ini. Saat mulai bekerja, ia harus menekan tombol yang sesuai, menambah ke program jumlah orang yang mengerjakan tugas ini. Penting bagi manajemen untuk mengetahui apakah jumlah orang yang mengerjakan tugas ini sesuai dengan jumlah yang telah mereka rencanakan. Kontraktor menekan tombol dan pekerjaan telah dimulai. Aplikasi memonitor durasi proses. Jika tenggat waktu terlewati, dan kontraktor tidak menekan tombol mematikan, pemberitahuan keterlambatan dikirim ke penanggung jawab. Jadi, penanggung jawab pergi dan melihat apa yang terjadi.
Jika semuanya baik-baik saja dan pada waktu yang ditentukan, kontraktor menyelesaikan pekerjaan, ia mengklik tombol "Kirim Laporan" dan menulis bahwa ia telah menyelesaikan pekerjaan 100%. Kemudian orang yang bertanggung jawab juga menerima pemberitahuan bahwa semuanya sudah selesai, Anda harus pergi dan melihat hasilnya. Beginilah model peran bekerja.
Orang mungkin tidak mengingat semua yang terjadi di situs yang dipercayakan kepada mereka, mereka melihat jadwal setiap hari dan menerima pemberitahuan tentang prosesnya.
Kami juga memberikan kesempatan untuk bekerja dengan tugas-tugas yang berlangsung lebih dari satu hari. Ini bekerja dengan cara yang sama seperti dengan tugas-tugas kecil, hanya pada akhir setiap hari Anda perlu membuat laporan dalam program: misalnya, hari ini pekerjaan sudah selesai 50%. Orang yang bertanggung jawab menerima pemberitahuan dan harus memeriksa apakah informasi ini benar. Jika tidak, ia menolak laporan dan memaksa kontraktor untuk memasukkan nomor lain.
Sedangkan untuk versi web, fungsinya sedikit berbeda, lebih ditujukan untuk pengontrol - manajemen perusahaan. Kami menyadari bahwa orang-orang terbiasa mempersepsikan informasi tentang kemajuan pada semua karya dalam grafik Gantt. Mereka melihat fakta rencana, hubungan, statistik tentang mobilisasi sumber daya manusia, berapa banyak orang yang ingin kita lihat di pabrik selama perbaikan, dan berapa banyak yang bekerja setelah fakta. Dan, karenanya, untuk semua instalasi produksi, pengontrol dapat melihat kemajuan pekerjaan, dengan cepat melihat kelambatan dari jadwal.
Pekerjaan tidak terjadwal
Selama perbaikan berhenti, pekerjaan tambahan tersembunyi selalu muncul yang tidak dapat diabaikan. Misalnya, saat membongkar peralatan, ada kerusakan pada bagian yang tidak terlihat dalam kondisi unit yang dirakit. Tugas-tugas ini juga termasuk dalam jadwal, keputusan dibuat bahwa kami juga melakukan pekerjaan tersembunyi selama perbaikan berhenti. Semuanya dimasukkan ke dalam program. Jika pekerjaan tambahan ini memengaruhi durasi seluruh perbaikan stop, program akan secara otomatis menunda semua tugas lain selama waktu yang dibutuhkan untuk menyelesaikan pekerjaan tersembunyi ini. Hal yang sama berlaku dalam kasus yang berlawanan - jika beberapa tugas diselesaikan lebih cepat dari yang direncanakan, jadwal dioptimalkan.
Untuk kasus seperti itu, tim dan saya merancang sistem pengiriman pesan yang serius dan pemberitahuan push untuk memperingatkan orang-orang yang mulai bekerja bahwa mereka dapat melakukan ini cepat atau lambat. Dan di sini momen yang menarik terungkap. Kami sudah bertindak terlalu jauh dengan pemberitahuan ini.
Di mana kita salah?
Faktanya adalah bahwa kami membawa ke sana “jadwal tingkat keempat” - rencana besar dan terperinci untuk semua perbaikan berhenti. Untuk tujuan kami, ternyata terlalu rinci. Ternyata pengguna menerima pemberitahuan tentang setiap hal kecil, yang mungkin tidak signifikan untuk proses secara keseluruhan. Lagi pula, ketika seseorang bekerja tanpa aplikasi, ia tidak melihat jadwal kerja setiap hari. Dia hanya tahu: untuk memperbaiki pompa bersyarat, Anda perlu melakukan banyak operasi (membongkar, membersihkan, mengganti unit, merakit, memeriksa dan sebagainya). Dan orang yang memeriksa cara kerja kontraktor tidak perlu mengontrol jalannya masing-masing tahap ini. Cukup untuk melihat hasil pekerjaan secara keseluruhan dan pada kepatuhan dengan tenggat waktu yang dinyatakan.
Artinya, jika kita melanjutkan ke notifikasi, maka controller harus belajar tentang dua peristiwa: awal perbaikan dan penyelesaian perbaikan. Karena itu, kami menyesuaikan aplikasi saat bepergian. Untuk mulai dengan, mereka diminta untuk mengubah jadwal dan memperbesarnya. Kemudian mereka meninggalkan beberapa peristiwa kecil dan semuanya mulai bekerja lebih lancar, pengguna mulai tidak terlalu terganggu oleh notifikasi.
Apa hasilnya?
Ketika kami menyelesaikan aplikasi, kami mendapat layanan yang memungkinkan kami untuk selalu memiliki informasi terbaru tentang perusahaan: apa yang sedang diperbaiki, pada tahap proses apa dan kapan tenggat waktunya. Ini memungkinkan Anda merencanakan pekerjaan dan menyiapkan jadwal. Pada dasarnya, sistem manajemen proyek perbaikan berhenti ini adalah manajer tugas canggih.
Awalnya, kami mendeklarasikan metrik utama untuk mengurangi waktu perbaikan stop. Sudah jelas bagaimana cara mengevaluasi ini dalam hal uang: Anda tahu berapa jam satu jam atau satu hari biaya downtime produksi. Oleh karena itu, kami menetapkan tujuan untuk mempercepat penyelenggaraan pekerjaan perbaikan. Sekarang kita melihat bahwa analitik juga penting - penilaian tentang apa yang terjadi selama perbaikan berhenti, hingga detail terkecil. Jika kita mencatat tindakan pengguna, bagaimana dan kapan dia menerima pekerjaan, apa komentarnya, apa yang salah, bagaimana koordinasi berjalan, kita melihat pembentukan cacat tersembunyi, memahami siapa yang bekerja, maka Anda dapat menganalisis dan memahami banyak tentang proses produksi. Hanya untuk penilaian mereka, kami memiliki "Fungsi Efisiensi Produksi". Setelah setiap perbaikan, sejumlah data dikumpulkan: berapa banyak uang yang dihabiskan, berapa yang direncanakan, seberapa cepat kami keluar dari perbaikan.
Tentu saja, kami membayangkan pengembangan proyek lebih lanjut. Sejauh ini, ini hanya langkah pertama dalam mengumpulkan statistik tentang perbaikan berhenti. Kami ingin mengumpulkan data yang cukup sehingga kami dapat bekerja dengannya dan menarik lebih banyak kesimpulan. Sebagai contoh, kita perlu memperbaiki pompa. Ini dilakukan oleh orang-orang X dan butuh waktu Y. Dengan demikian, semua perencanaan perbaikan selanjutnya dapat didasarkan pada model ini. Kami akan dapat merencanakan pekerjaan berdasarkan fakta bahwa sudah ada analis yang dikonfirmasi oleh data, yang berarti bahwa kami tidak melebih-lebihkan atau meremehkan harapan dalam hal waktu.
Aplikasi kami dapat digunakan tidak hanya untuk produksi. Ini mungkin manajemen konstruksi modal, area lain di mana pendekatan yang serupa dengan perencanaan kerja diterapkan.
Siapa yang mengerjakan proyek ini?
Sekelompok orang baik di dalam SIBUR dan kontraktor bekerja di proyek. Pengembangan sisi server dan front-end sepenuhnya pada kontraktor, kami di dalam tim terlibat dalam desain logika aplikasi dan antarmuka. Para konsultan termasuk manajer perbaikan pemadaman, mekanik yang bekerja secara langsung pada jadwal, kepala insinyur yang memantau proses, dan direktur perusahaan.
Segala sesuatu tentang segalanya (penelitian, uji coba, antarmuka dan pengembangan) membutuhkan waktu enam bulan.
Apa masa depan produk?
Dalam waktu dekat - beberapa pembaruan utama. Meskipun ada masalah dengan perhitungan volume fisik dalam kerangka tugas, misalnya, untuk alat kelengkapan yang diganti. Tidak hanya relatif, tetapi juga indikator absolut penting bagi kolega kami di perusahaan: kita perlu memahami berapa banyak pekerjaan yang telah diselesaikan, berapa banyak tulangan penguat dari 1000 kondisional yang telah diganti. Sekarang ini tidak diperhitungkan dalam jadwal kerja aplikasi. Kami akan memikirkan bagaimana menerapkannya. Sejauh ini, kita hanya dapat berbicara tentang kemajuan pekerjaan yang dilakukan dan persentase penyelesaiannya, untuk memperbaiki situasi keterlambatan atau lebih cepat dari jadwal.
Itu mungkin (dan kami sudah memiliki pemahaman seperti itu), kami akan mentransfer seluruh proses perencanaan perbaikan berhenti untuk proyek kami. Mungkin, pada saat yang sama, seluruh pembangunan akan memindahkan rumah.
Kami akan senang melihat kolega baru di tim: pemilik produk, desainer produk, pengembang. Daftar lowongan saat ini di tautan ke
hh.ru.