Perbaikan berkelanjutan adalah hal yang membedakan operator terbaik dari yang lainnya. Dengan Trupeer, Anda dapat menghemat waktu berjam-jam untuk perencanaan perbaikan dengan memulai dari template rencana perbaikan proses gratis, menyesuaikannya dengan panduan merek Anda, lalu mengubah rencana perbaikan menjadi pembaruan video yang mendorong adopsi di seluruh tim.

Apa itu template rencana perbaikan proses?

Rencana perbaikan proses menjelaskan apa yang salah dalam suatu proses, apa yang akan berubah, siapa yang akan melakukannya, kapan batas waktunya, dan bagaimana Anda akan mengetahui apakah itu berhasil.

Rencana ini bersifat mengantisipasi ke depan, yang membedakannya dari catatan yang Anda buat setelahnya. template dokumentasi perbaikan proses kami mencakup bagian tersebut, artinya laporan, register, dan dependensinya. Halaman ini membahas rencana yang Anda tulis sebelum apa pun berubah.

Template untuk itu memberi Anda bagian-bagian: masalah, kondisi saat ini, akar penyebab, perubahan yang diusulkan, manfaat, timeline, penanggung jawab, ukuran. Setiap versi yang Anda temukan menawarkan kira-kira bagian-bagian tersebut, dan itulah bagian yang tepat.

Yang tidak mereka sertakan adalah bahwa perbaikan proses bukan proyek dengan awal dan akhir. Ini adalah perubahan pada sesuatu yang harus terus berjalan sepanjang waktu, yaitu masalah yang jauh lebih sulit, dan sebagian besar rencana tidak membahasnya.

Mengapa rencana perbaikan proses tidak bisa menghentikan proses

Rencana proyek bisa mengasumsikan urutan yang rapi. Bangun produknya, uji, lalu rilis. Rencana perbaikan proses tidak bisa, karena pekerjaan tidak berhenti saat Anda memperbaikinya.

Pada hari Anda beralih, ada antrean. Ada item yang masih berjalan dengan metode lama, pelanggan yang belum mengadopsi metode baru, staf di berbagai titik pada kurva pembelajaran, serta dua set instruksi yang beredar.

Periode itulah tempat perbaikan hilang. Desainnya biasanya sudah tepat. Kasus manfaatnya biasanya masuk akal. Yang menghabiskan manfaat adalah minggu-minggu menjalankan dua metode sekaligus, tanpa rencana dan tanpa penugasan staf, dengan kualitas menurun tepat karena semua orang mengerjakan sesuatu yang belum familiar sambil menangani sisa dari cara lama.

Ukuran yang Anda coba perbaiki hampir selalu memburuk terlebih dahulu. Jika tidak ada yang merencanakan hal itu, perbaikan akan dinilai selama periode terburuknya dan akhirnya ditinggalkan atau dikembalikan secara diam-diam, yang merupakan hasil umum dan dapat dihindari.

Cara menyesuaikan template ini di Trupeer

Langkah 1: Buka Bagian Templates

Buka bagian Templates dari navigasi utama.

Langkah 2: Pilih dan Buka Template

Klik pada template apa pun yang ingin Anda gunakan untuk membukanya.

Langkah 3: Perluas Tampilan Template

Jika diperlukan, perluas tampilan template untuk melihat tata letak dan detailnya dengan jelas.

Langkah 4: Edit Template

Klik Edit untuk mulai memodifikasi template yang dipilih.

Di dalam editor, Anda dapat:

• Menambahkan bagian baru

• Menentukan atau memperbarui aturan pemformatan

• Menambahkan logo dan menyesuaikan posisinya serta pengaturan terkait

Langkah 5: Simpan Template yang Anda Sesuaikan

Setelah melakukan semua perubahan yang diperlukan, klik Save untuk menyimpan template yang diperbarui sebagai milik Anda.

Langkah 6: Pratinjau dan Penyempurnaan Template

Saat Anda ingin melihat seperti apa tampilan template yang Anda sesuaikan, buka Preview.

Dari layar pratinjau, Anda dapat terus melakukan penyesuaian secara langsung jika diperlukan, sehingga template tampil persis seperti yang Anda inginkan.

Dengan template rencana perbaikan proses, Anda dapat:

• Menghemat waktu untuk perencanaan: Lewati halaman kosong dengan struktur yang digunakan oleh praktisi Lean dan Six Sigma.

• Mendorong perbaikan yang terukur: Kolom metrik bawaan memastikan perbaikan terlacak.

• Tetap sesuai merek: Terapkan logo, font, dan warna Anda menggunakan brand kit Trupeer.

• Menggulirkan perubahan lebih cepat: Padukan rencana dengan panduan video manajemen perubahan.

• Standarisasi perbaikan: Gunakan template yang sama di seluruh tim dan fungsi.

• Menjangkau tim global: Terjemahkan rencana perbaikan ke 65+ bahasa hanya dengan satu klik.

Template rencana perbaikan proses bagian transisi menghilangkan

Empat pertanyaan, tidak ada satupun yang muncul dalam rencana perbaikan konvensional, dan semuanya harus dijawab di bawah tekanan jika tidak dijawab sejak awal.

Apa yang terjadi pada pekerjaan yang sudah berjalan? Item yang dimulai dengan metode lama pada hari Anda beralih. Ini yang terbesar dari keempatnya dan mendapat bagiannya sendiri di bawah.

Siapa yang bergerak kapan? Big bang atau bertahap. Jika bertahap, kohort mana, urutannya bagaimana, dan apa yang harus benar sebelum kohort berikutnya bergerak.

Berapa biaya menjalankan dua metode sekaligus, dan siapa yang menanggungnya? Dua metode yang berjalan berdampingan biayanya lebih mahal daripada salah satunya saja, baik dari sisi waktu, supervisi, maupun tingkat kesalahan. Tidak ada yang menganggarkannya, jadi transisi menjadi terkompresi dan kesalahan disalahkan pada metode baru.

Bagaimana Anda akan tahu, nanti, metode mana yang menghasilkan suatu pekerjaan tertentu? Penanda versi, format referensi, sebuah flag. Mudah ditambahkan sejak awal, hampir mustahil untuk direkonstruksi setelahnya, dan ini penting untuk pengukuran, audit, serta pertanyaan pelanggan.

Menjawabnya memakan waktu sekitar satu jam bersama orang-orang yang menjalankan proses. Ini adalah jam dengan imbal hasil tertinggi dalam seluruh rangkaian kegiatan.

Aturan saat masih berjalan (in-flight), dan biaya jika salah

Pada hari pergantian, ada populasi pekerjaan yang sudah dimulai dengan metode lama. Ada tiga opsi dan salah satunya harus dipilih secara eksplisit.

Kegagalannya bukan karena memilih dengan buruk. Bukan memilih, yang berarti staf melakukan improvisasi per item, dengan cara yang berbeda, dan kadang pekerjaan yang sama ditangani dengan dua cara.

Apa pun yang Anda pilih, tuliskan batasnya dengan tepat: pekerjaan in-flight jika sudah mencapai titik yang ditetapkan pada waktu yang ditetapkan. Lalu perkirakan volumenya, karena angka itu memberi tahu berapa lama dual running berlangsung dan karenanya berapa biayanya.

Kohort, dual running, dan cara membedakannya

Kohort. Kecuali prosesnya kecil, pindahkan orang atau pelanggan dalam kelompok, bukan sekaligus semuanya. Urutkan berdasarkan risiko, bukan berdasarkan kenyamanan: mulai dengan kelompok yang masalahnya dapat dipulihkan dan di mana orang-orang yang terlibat akan memberi tahu Anda dengan jujur apa yang salah. Tetapkan kriteria perpindahan, artinya apa yang harus benar sebelum kohort berikutnya bergerak, dan buat itu dapat diamati. Dua minggu berturut-turut pada atau di atas level kualitas sebelumnya adalah default yang masuk akal.

Dual running. Perkirakan periode dan siapkan stafnya. Saat dual running, perkirakan waktu penanganan per item akan meningkat secara signifikan, karena orang memeriksa kedua sistem, mengajukan pertanyaan, dan membuat kesalahan. Anggarkan sebagai biaya perbaikan, bukan menganggapnya sebagai kegagalan eksekusi. Rencana yang menunjukkan penurunan dan pemulihan itu kredibel. Rencana yang menunjukkan manfaat langsung tidak, dan itu merusak kepercayaan saat penurunan terjadi.

Identifikasi. Tambahkan sesuatu pada setiap item yang menunjukkan metode mana yang menghasilkannya. Prefiks pada referensi, sebuah kolom, nomor versi pada output. Tidak ada biaya apa pun pada tahap desain. Tanpa itu, pertanyaan apa pun tiga bulan kemudian, dari pelanggan, auditor, atau analisis internal Anda, memerlukan rekonstruksi manual.

Template rencana perbaikan proses gratis: struktur yang bisa dicontoh

Salin dari sini. Bagian transisi adalah tambahan.

Header. Referensi, judul, proses yang terdampak, penanggung jawab, sponsor, tanggal, status.

Masalah. Sebuah observasi dengan angka. Apa yang terjadi, seberapa sering, dan bagaimana Anda mengetahuinya.

Baseline. Ukuran, nilai saat ini, metode, periode, dan tanggal yang dicatat. Semua yang terjadi setelahnya bergantung pada hal ini yang dicatat sebelum Anda mulai.

Akar penyebab. Apa yang ditemukan dari analisis, dengan bukti, dibedakan dari apa yang diasumsikan sejak awal.

Perubahan yang diusulkan. Apa yang akan berbeda, dijelaskan dengan cukup presisi agar orang lain bisa mengimplementasikannya.

Ruang lingkup. Di mana proses dimulai dan berhenti untuk tujuan rencana ini, serta apa yang secara eksplisit dikecualikan.

Transisi. Aturan in-flight beserta batas dan volumenya. Urutan kohort dengan kriteria perpindahan. Periode dual running, perkiraan biayanya, dan siapa yang menanggungnya. Penanda identifikasi. Perkiraan penurunan pada ukuran dan perkiraan durasinya.

Dokumen yang perlu diubah. Prosedur, instruksi kerja, dan job aid mana yang perlu diperbarui, disebutkan, dengan penanggung jawab dan tanggal. Perbaikan tanpa perubahan dokumen tidak akan bertahan.

Manfaat. Dinyatakan sebagai ukuran yang bergerak, dengan tanggal saat seharusnya terlihat. Angka keuangan bersifat sekunder, karena diturunkan.

Risiko dan dependensi. Hanya yang akan mengubah rencana, masing-masing dengan pemicunya.

Ukuran dan poin peninjauan. Apa yang dicek, kapan, dan keputusan apa yang dibuat oleh setiap peninjauan.

Salin sampai di sini. Tiga atau empat halaman. Jika rencana berjalan lebih lama, analisis biasanya ditempelkan dan masuk ke lampiran.

Laboratorium yang kehilangan empat bulan manfaatnya

Ilkeston Testing Services adalah laboratorium pengujian material yang menangani sekitar empat ribu dua ratus permintaan pengujian per bulan.

Rencana perbaikannya bagus. Formulir pendaftaran sampel tulisan tangan menyebabkan kesalahan transkripsi, dan akibatnya 6,8% sampel harus diuji ulang. Rencana tersebut memetakan kondisi saat ini, menetapkan penyebab dengan benar, menentukan portal intake digital, dan membuat kasus manfaat sekitar seratus sembilan puluh ribu pound per tahun. Tujuh langkah, penanggung jawab, tanggal go-live.

Tidak ada apa pun tentang transisi di dalamnya.

Portal tersebut mulai beroperasi untuk semua pelanggan pada tanggal 1 Maret.

Seribu sembilan ratus sampel sudah ada di laboratorium, terdaftar secara kertas dan sedang dalam proses pengujian. Tidak ada aturan untuk itu. Staf memutuskan per kasus. Sebagian dimasukkan kembali ke portal, sebagian tetap di kertas, dan sejumlah berakhir di keduanya.

Kedua sistem berjalan selama lima minggu. Tidak ada yang merencanakan dual running, jadi tidak ada yang menyiapkan staf untuk itu. Waktu pendaftaran per sampel naik dari sekitar empat menit menjadi sebelas menit selama masa tumpang tindih, karena staf memeriksa kedua sistem sebelum melakukan apa pun.

Pelanggan bergerak sesuai kecepatan masing-masing. Pada minggu keempat, 61% menggunakan portal dan 39% masih mengirim email formulir. Rencana tersebut mengasumsikan adopsi penuh dalam dua minggu.

Ukuran yang mereka coba perbaiki justru bergerak ke arah yang salah. Median turnaround naik dari 6,1 hari menjadi 8,9 hari selama transisi dan tidak kembali di bawah 6 hingga bulan kelima.

Detail termahal adalah yang paling kecil. Portal dan log kertas menggunakan format referensi yang berbeda, sehingga untuk sampel mana pun tidak ada cara cepat untuk mengetahui jalur mana yang dilaluinya. Saat pelanggan menanyakan hasil pada bulan ketiga, rekonstruksi rantai penguasaan memakan waktu dua hari.

Biaya transisi kemudian diperkirakan sekitar tujuh puluh empat ribu pound untuk penanganan tambahan. Dibandingkan manfaat tahunan seratus sembilan puluh ribu pound, itu lebih dari empat bulan manfaat yang dikonsumsi sebelum apa pun mulai terakumulasi, dan tidak ada yang muncul di mana pun dalam rencana.

Template rencana ditulis ulang dengan bagian transisi yang mencakup empat pertanyaan di atas.

Perbaikan berikutnya, perubahan pada format pelaporan, menggunakannya. Aturan in-flight menyatakan bahwa apa pun yang sudah dipesan selesai dengan format lama. Tiga kohort pelanggan berpindah selama lebih dari enam minggu dengan kriteria perpindahan berupa dua minggu yang bersih untuk masing-masing. Dual running dianggarkan setengah dari setara penuh waktu selama delapan minggu. Setiap laporan membawa penanda versi.

Turnaround turun dari 6,0 hari menjadi 6,4 selama tiga minggu lalu kembali. Biaya transisi sekitar sembilan ribu pound dibandingkan rencana sebelas ribu.

Cara membuat rencana perbaikan proses dalam 7 langkah

Satu. Tetapkan baseline sebelum apa pun yang lain. Ukuran, metode, periode, tanggal. Baseline yang dipasang ulang selalu sedikit lebih menguntungkan.

Dua. Selidiki penyebabnya, bukan mengonfirmasi solusi. Sebagian besar rencana perbaikan ditulis untuk membenarkan sesuatu yang sebenarnya sudah ingin dilakukan seseorang. Tuliskan hipotesis awal Anda agar nanti Anda bisa menilai apakah itu benar.

Tiga. Tentukan ruang lingkup di kedua ujung. Di mana proses dimulai dan berhenti untuk rencana ini, serta apa yang sengaja dikecualikan.

Empat. Rancang perubahan dan transisi bersama-sama. Bukan perubahan dulu lalu transisi nanti, karena transisi sering kali mengubah desain. Metode yang sangat baik untuk kondisi stabil dan tidak mungkin dimigrasikan bukanlah metode yang tepat.

Lima. Sebutkan dokumen yang akan berubah, beserta penanggung jawab dan tanggal. Lakukan ini pada waktu perencanaan, karena setelahnya selalu diremehkan.

Enam. Sepakati penurunan yang diharapkan. Seberapa jauh ukuran akan turun, selama berapa lama, dan pada titik kapan Anda akan berhenti. Menyepakati ini di muka adalah yang mencegah perbaikan yang baik ditinggalkan pada minggu ketiga.

Tujuh. Tetapkan poin peninjauan, termasuk satu setelah transisi benar-benar stabil, yang biasanya lebih lambat daripada yang direncanakan siapa pun.

Metodologi perbaikan proses, dan kapan masing-masing cocok

Rencana adalah wadahnya. Metode adalah cara Anda menentukan apa yang perlu diubah, dan memilih salah satu sebelum Anda memahami masalah adalah kesalahan umum.

PDCA cocok untuk menguji perubahan spesifik terhadap baseline ketika Anda memiliki hipotesis tetapi belum yakin. template metode PDCA kami mencakup itu, termasuk mengapa tahap check biasanya gagal.

Kaizen cocok untuk perbaikan kecil berkelanjutan yang dibuat oleh orang-orang yang menjalankan pekerjaan, sebagian besar terlalu kecil dan terlalu mudah dibalik sehingga tidak perlu rencana sama sekali. template metode kaizen kami mencakup ambang batas di bawah mana sebuah rencana menjadi beban tambahan.

Lean dan value stream mapping cocok untuk masalah alur: menunggu, serah terima, persediaan, dan pengerjaan ulang di seluruh proses, bukan hanya pada satu langkah.

Six Sigma dan DMAIC cocok untuk variasi dalam proses yang stabil dan bervolume tinggi, ketika Anda memiliki data dan seseorang yang terlatih untuk menganalisisnya. Lebih berat daripada PDCA dan lebih kuat ketika masalahnya adalah inkonsistensi, bukan level.

5S cocok untuk pengorganisasian tempat kerja secara spesifik, dan template perbaikan proses 5S kami mencakup itu.

Business process reengineering cocok untuk kasus ketika proses sama sekali tidak seharusnya ada dalam bentuknya saat ini. Ini satu-satunya dari semuanya di mana masalah transisi mendominasi segalanya, itulah sebabnya beberapa badan sektor publik menerbitkan format rencana perbaikan BPR mereka sendiri.

Apa yang bukan dan apa itu rencana perbaikan proses

Ini bukan rencana proyek. Proyek memiliki akhir yang terdefinisi dan deliverable. Perbaikan mengubah sesuatu yang akan terus berjalan setelahnya, itulah sebabnya transisi dan standarisasi lebih penting daripada tanggal pengiriman. Jika perbaikannya cukup besar sehingga perlu penjadwalan yang tepat, template rencana proyek IT kami mencakup lapisan tersebut, dan rencana ini berada di dalamnya.

Ini bukan dokumentasi proses. Dokumentasi menjelaskan bagaimana proses berjalan. Rencana menjelaskan bagaimana proses akan berubah. template dokumentasi proses kami mencakup yang pertama, dan perbaikan yang berhasil menghasilkan pembaruan untuknya.

Ini bukan business case. Manfaat ada di dalam rencana, tetapi dokumen yang ditulis terutama untuk mengamankan pendanaan akan dibentuk untuk meyakinkan, bukan untuk dieksekusi, dan keduanya dibaca dengan cara yang sangat berbeda.

Dan ini bukan rencana perbaikan kinerja, yang dibahas berikutnya karena jumlah orang yang terkejut saat mencari istilah ini cukup banyak.

Rencana perbaikan proses atau rencana perbaikan kinerja?

Keduanya disingkat menjadi PIP dalam percakapan dan merupakan dokumen yang sepenuhnya berbeda, jadi ada baiknya untuk jelas.

Sebuah rencana perbaikan proses membahas bagaimana pekerjaan dilakukan. Ini tentang sebuah sistem, bukan tentang individu mana pun, dan output-nya adalah proses yang berubah.

Sebuah rencana perbaikan kinerja membahas seorang karyawan yang menjalankan pekerjaannya di bawah standar yang diperlukan. Ini adalah instrumen formal HR dan hukum ketenagakerjaan dengan kerangka waktu yang ditetapkan, persyaratan bukti, dan konsekuensi, serta biasanya menjadi bagian dari prosedur disipliner atau kapabilitas.

Mencampuradukkannya benar-benar berbahaya ke dua arah. Mengemas masalah proses sebagai isu kinerja individu adalah kesalahan manajemen klasik, dan itu tidak memperbaiki apa pun, karena orang berikutnya dalam peran tersebut akan menghadapi masalah yang sama. Mengemas kekhawatiran kinerja yang benar-benar ada sebagai perbaikan proses menghindari percakapan yang perlu dilakukan dan melemahkan posisi pemberi kerja jika nanti menjadi formal.

Jika Anda membutuhkan versi kinerja, itu harus berasal dari fungsi HR Anda dan ditinjau terhadap hukum ketenagakerjaan yurisdiksi Anda, bukan diadaptasi dari template. Tidak ada di sini yang merupakan nasihat ketenagakerjaan. template rencana pengembangan kepemimpinan kami membahas kasus pengembangan, yang merupakan hal ketiga lagi dan tidak boleh dicampur dengan salah satu.

Bisakah saya mendapatkan template rencana perbaikan proses dalam Word atau Excel?

Word atau Google Docs untuk rencana. Bagian masalah, penyebab, perubahan yang diusulkan, dan transisi adalah narasi yang diperdebatkan, dan dokumen diedarkan untuk persetujuan.

Excel untuk tiga hal yang menginginkan kolom. Pelacak transisi, artinya kohort, tanggal perpindahan, kriteria terpenuhi, dan status saat ini. Daftar perubahan dokumen, dengan penanggung jawab dan tanggal jatuh tempo. Dan log ukuran, yang menangkap baseline, penurunan, dan pemulihan pada sumbu yang sama, yaitu yang mencegah perbaikan dinilai selama minggu terburuknya.

PowerPoint untuk presentasi persetujuan, dibuat dari rencana, bukan sebagai pengganti. Jika yang tersisa hanya deck, bagian transisi adalah yang pertama hilang, karena bagian ini paling tidak mengesankan untuk dipresentasikan dan paling penting untuk dimiliki.

PDF untuk versi yang disetujui setelah ditandatangani, dengan salinan kerja tetap dapat diedit, karena tanggal kohort dan kriteria perpindahan berubah selama eksekusi.

Cara membuat metode baru tetap berjalan setelah go-live

Setiap rencana perbaikan proses memiliki baris tentang memperbarui dokumentasi, dan baris itulah yang paling sering terlewat, biasanya karena proyek berjalan lama dan tim sudah pindah.

Kelalaian itulah yang menyebabkan pengembalian (reversion). Perbaikan ada di kepala orang-orang yang terlibat, dan itu bertahan sampai mereka berganti peran, saat proses diam-diam kembali ke instruksi tertulis apa pun yang masih berlaku.

Trupeer AI membuat standarisasi cukup cepat untuk benar-benar terjadi di dalam proyek, bukan setelahnya. Siapa pun yang menjalankan metode baru mencatatnya sekali, dan output-nya adalah prosedur tertulis dengan langkah dan layar yang sudah ditangkap, siap untuk dicek daripada disusun. Dokumen yang disebutkan dalam rencana Anda diperbarui pada minggu saat metode tersebut terbukti.

Catat. Branding. Terjemahkan. Trupeer-kan.

Mencatat metode lama sebelum perubahan juga layak dilakukan, karena itu memberi Anda artefak sebelum untuk periode transisi dan membuat semua orang jelas metode mana yang sedang mereka lihat. SOP creator mencakup prosedurnya, template dokumentasi proses kami mencakup deskripsi yang harus berubah, dan output-nya tersimpan di knowledge base Anda dengan branding yang konsisten. Instruksi penyiapan ada di panduan penyiapan template dokumen.

Pertanyaan yang Sering Diajukan

Apakah ada template rencana perbaikan proses gratis di Word?

Struktur di atas langsung ditempel ke Word atau Google Docs, termasuk bagian transisi yang tidak disertakan oleh template standar. Tidak ada unduhan berpagar dan tidak ada formulir. Tulis bagian transisi sebelum bagian manfaat, karena biaya transisi biasanya mengubah angka manfaat.

Apakah ada template rencana perbaikan proses gratis di Excel?

Excel cocok untuk pelacak, bukan untuk rencana. Tiga lembar: kohort dengan kriteria perpindahan dan status, dokumen yang perlu diubah dengan penanggung jawab dan tanggal, serta log ukuran yang menunjukkan baseline, penurunan, dan pemulihan. Lembar ketiga itulah yang melindungi perbaikan yang baik agar tidak dinilai selama tiga minggu terburuknya.

Apakah ada template rencana perbaikan proses gratis di PowerPoint?

Gunakan slide untuk percakapan persetujuan dan simpan rencana itu sendiri sebagai dokumen. Enam slide sudah cukup: masalah beserta angkanya, penyebab, perubahan, transisi dan biayanya, penurunan dan pemulihan yang diharapkan, serta apa yang perlu disetujui. Slide transisi adalah yang paling diingat orang saat penurunan terjadi.

Apakah ada template rencana perbaikan proses gratis di PDF?

Ekspor versi yang disetujui saat penandatanganan dan simpan salinan kerja agar tetap dapat diedit. Tanggal kohort dan kriteria perpindahan berubah selama eksekusi, dan rencana yang dibekukan tidak lagi dirujuk saat realitas menyimpang untuk pertama kalinya.

Berapa lama rencana perbaikan proses seharusnya?

Tiga atau empat halaman plus pelacaknya. Rencana yang lebih panjang biasanya memuat analisis yang seharusnya ada di lampiran, atau business case yang seharusnya ada di dokumen terpisah. Ujiannya adalah apakah seseorang yang menggantikan penanggung jawab bisa menjalankan transisi dari rencana tersebut.

Siapa yang seharusnya memiliki rencana perbaikan proses?

Orang yang bertanggung jawab atas proses setelahnya, bukan orang yang menjalankan proyek. Perbaikan yang dimiliki oleh fungsi proyek cenderung diserahkan lalu menjadi tidak bertanggung jawab, dan periode transisi adalah tepat saat penanggung jawab yang masih ada dalam enam bulan membuat perbedaan.

Rencana perbaikan proses atau rencana proyek: apa bedanya?

Rencana proyek mencakup pekerjaan dengan akhir yang terdefinisi dan deliverable. Rencana perbaikan proses mencakup perubahan pada sesuatu yang terus berjalan, itulah sebabnya ia memerlukan bagian transisi dan langkah standarisasi yang tidak dimiliki rencana proyek. Perbaikan besar membutuhkan keduanya, dengan rencana perbaikan berada di dalam proyek.

Bagaimana cara mengukur apakah rencana perbaikan proses berhasil?

Gunakan ukuran yang sama seperti baseline, dengan metode yang sama, diambil setelah transisi benar-benar stabil, bukan pada saat go-live. Sepakati sebelumnya seberapa jauh ukuran boleh turun dan selama berapa lama, agar penurunan diharapkan, bukan dianggap sebagai kegagalan. Selain itu, pantau apakah dokumen yang disebutkan dalam rencana benar-benar diperbarui, karena itu memprediksi apakah hasilnya akan bertahan.