Rencana manajemen proyek adalah buku pedoman utama untuk menyampaikan proyek dengan sukses. Dengan Trupeer, Anda dapat menghemat waktu berjam-jam untuk perencanaan dengan memulai dari template rencana manajemen proyek gratis, menyesuaikannya dengan identitas merek Anda, lalu mengubah rencana menjadi ringkasan video yang menyelaraskan pemangku kepentingan dengan cepat.

Apa itu template rencana manajemen proyek?

Rencana manajemen proyek adalah dokumen yang menjelaskan bagaimana proyek tertentu akan dikelola: ruang lingkup, jadwal, biaya, kualitas, penugasan sumber daya, komunikasi, risiko, pengadaan, serta pendekatan terhadap pemangku kepentingan.

Dalam metode formal, ini adalah rencana utama, yang berisi atau merujuk rencana turunan untuk masing-masing area tersebut. Itulah yang membedakannya dari rencana proyek, yang dalam penggunaan sehari-hari sering kali berarti jadwal saja.

Template untuk itu biasanya menyediakan seluruh rangkaian bagian turunan, itulah sebabnya versi yang sudah selesai bisa mencapai enam puluh halaman atau lebih. Kelengkapan itu bukan masalah, dan halaman ini bukan argumen untuk mengabaikan tata kelola.

Masalahnya adalah apa yang mengisi halamannya.

Uji sorot untuk setiap rencana manajemen proyek

Ambil rencana manajemen proyek yang sudah selesai dari organisasi Anda sendiri. Sorot setiap kalimat yang akan berbeda jika ini adalah proyek yang berbeda.

Bukan kalimat yang berisi nama proyek. Kalimat yang isinya akan berubah: batasan spesifik, ketergantungan yang disebutkan namanya, keputusan yang diambil untuk kondisi proyek ini, tanggal yang tidak bisa digeser.

Lalu lihat seberapa banyak dokumen yang disorot.

Di sebagian besar organisasi, jumlahnya antara lima belas hingga tiga puluh persen. Sisanya tujuh puluh hingga delapan puluh lima persen menjelaskan bagaimana organisasi mengelola proyek secara umum, dan akan tampak tidak berubah pada rencana berikutnya dan setelah itu.

Itulah alasan mengapa tidak ada yang membaca dokumen-dokumen ini. Seorang pembaca yang mencari hal spesifik tentang proyek ini harus menemukannya di dalam materi yang jumlahnya empat kali lebih banyak yang tidak.

Cara menyesuaikan template ini di Trupeer

Langkah 1: Buka Bagian Templates

Buka bagian Templates dari navigasi utama.

Langkah 2: Pilih dan Buka sebuah 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

• Menetapkan atau memperbarui aturan pemformatan

• Menambahkan logo dan menyesuaikan posisinya serta pengaturan terkait

Langkah 5: Simpan Template yang Anda Sesuaikan

Setelah membuat 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 manajemen proyek, Anda dapat:

• Menghemat waktu untuk perencanaan: Lewati halaman kosong dengan struktur PM yang komprehensif.

• Mencakup setiap area pengetahuan: Bagian bawaan untuk ruang lingkup, jadwal, biaya, kualitas, dan risiko.

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

• Menyelaraskan pemangku kepentingan: Ubah rencana yang padat menjadi ringkasan video agar semua orang dapat menyerapnya dengan cepat.

• Menstandarkan lintas proyek: Gunakan template yang sama untuk setiap inisiatif.

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

Mengapa sebagian besar dokumen akan cocok untuk proyek apa pun

Konten umum tidak ada karena kemalasan. Konten itu ada karena template memintanya dan karena tata kelola mengharapkan setiap area turunan ditangani.

Jadi, bagian manajemen ruang lingkup mengatakan bahwa perubahan ruang lingkup akan diajukan sebagai permintaan perubahan, dinilai dampaknya, lalu disetujui oleh change board. Itu benar, dan begitulah cara setiap proyek di organisasi tersebut berjalan, serta tidak memberi tahu pembaca apa pun tentang proyek ini.

Bagian manajemen kualitas menjelaskan pendekatan standar untuk peninjauan dan pengujian. Bagian manajemen komunikasi mengatakan pemangku kepentingan akan menerima laporan mingguan. Bagian kontrol perubahan mengulang kembali proses kontrol perubahan. Semua akurat, semuanya identik dengan rencana terakhir, semuanya menyita perhatian pembaca.

Sementara itu, konten yang benar-benar spesifik proyek—yaitu yang menjadi alasan rencana dibuat untuk mencatatnya—tersebar di dalamnya. Pembatasan akses situs. Satu pemasok sumber tunggal. Jendela yang tidak bisa digeser. Pemangku kepentingan yang harus menyetujui secara langsung. Masing-masing itu satu atau dua kalimat, dan semuanya tersembunyi.

Perbaikannya bukan menulis lebih sedikit. Melainkan memindahkan materi umum ke tempat yang bisa ditulis sekali saja.

Cara memisahkan metodologi dari rencana

Dua dokumen, bukan satu.

Dokumen metodologi yang berlaku tetap. Cara organisasi Anda mengelola proyek. Kontrol perubahan, quality gates, ritme pelaporan, jalur eskalasi, standar dokumen, peran, dan tanggung jawabnya. Ditulis sekali, dimiliki oleh kantor proyek, dirujuk oleh setiap rencana, diperbarui saat metode berubah, bukan saat proyek dimulai.

Rencana manajemen proyek. Hanya yang spesifik untuk proyek ini. Setiap bagian mengajukan satu pertanyaan: apa yang berbeda di sini?

Aturan yang menjaga pemisahan tetap jujur itu sederhana untuk diterapkan. Setiap kalimat yang bisa muncul tidak berubah dalam rencana proyek lain dihapus dan diganti dengan rujukan ke metodologi.

Menerapkan aturan itu pada rencana yang sudah ada dengan enam puluh halaman biasanya menyisakan delapan hingga dua belas halaman. Halaman-halaman itu adalah rencananya. Dan untuk pertama kalinya, halaman-halaman itu layak dibaca.

Ada dua keberatan yang muncul, dan keduanya punya jawaban. Auditor dan klien kadang-kadang memerlukan seluruh rangkaian konten turunan; dalam hal itu, dokumen metodologi memenuhinya dan rencana merujuknya, yang umumnya diterima auditor karena keterlacakannya lebih jelas. Dan orang khawatir rencana terlihat tipis, padahal memang begitu—sampai suatu saat seseorang harus menggunakannya.

Template rencana manajemen proyek gratis: bagian yang perlu dicontoh

Salin dari sini. Delapan bagian, delapan hingga dua belas halaman, masing-masing menjawab apa yang berbeda tentang proyek ini.

Header. Proyek, sponsor, manajer proyek, anggaran, tanggal, versi dokumen metodologi yang menjadi dasar rencana ini.

Tujuan dan kriteria keberhasilan. Apa yang harus dicapai proyek ini, sebagai ukuran bukan deliverable, diambil dari project brief alih-alih dibuat ulang.

Ruang lingkup dan batasan. Apa yang termasuk, apa yang tidak termasuk, dan secara spesifik apa yang tidak termasuk yang diminta orang. Rujuk proses perubahan, bukan mendeskripsikannya.

Batasan yang tidak bisa digeser. Tanggal, jendela, pembekuan, tenggat waktu regulasi, periode kepemilikan atau akses, tanggal pemberitahuan kontrak. Apa pun yang tidak bisa digeser oleh proyek, beserta pemiliknya. IT project plan template kami mencakup pembuatan ini dengan benar, dan ini adalah bagian yang paling layak diekstrak menjadi satu halaman.

Penugasan sumber daya dan kapasitas. Siapa yang berkomitmen, untuk berapa banyak waktu mereka, dan apa yang tidak mereka lakukan sebagai gantinya. Sebutkan individu yang ketersediaannya benar-benar bergantung pada rencana.

Pendekatan pengadaan. Apa yang dibeli, berdasarkan apa, dengan lead time. procurement management plan template kami mencakup ini sebagai rencana turunan jika proyek memang memerlukannya.

Risiko spesifik proyek. Hanya risiko yang khusus untuk proyek ini, masing-masing dengan pemicu dan pemilik. Risiko umum masuk ke daftar risiko tetap milik metodologi.

Penyimpangan dari metodologi. Di mana proyek ini akan melakukan sesuatu secara berbeda dari pendekatan standar, dan mengapa disetujui. Bagian ini singkat, dan ini adalah bagian yang pertama kali dibaca auditor.

Salin ke sini. Rencana turunan dilampirkan jika skala proyek membutuhkannya, dan dirujuk jika tidak.

Insinyur rel yang jendela kepemilikannya ada di halaman 41

Kelvedon Rail adalah perusahaan rekayasa infrastruktur dengan sekitar seribu enam ratus orang, yang menjalankan sekitar tiga puluh empat proyek per tahun di atas ambang batas dua ratus lima puluh ribu pound, dan setiap proyek memerlukan rencana manajemen proyek.

Template tersebut memuat sebelas rencana turunan dan versi yang sudah selesai rata-ratanya mencapai enam puluh delapan halaman.

Seseorang menjalankan uji sorot pada dua belas di antaranya. Konten yang disorot secara median: sembilan belas persen.

Bagian ruang lingkup, kualitas, komunikasi, dan kontrol perubahan hampir identik di semua dua belas, dan pada sembilan kasus kata demi kata, karena setiap penulis memulai dari rencana sebelumnya. Dua dari dua belas masih memuat nama proyek lain di teks utama.

Kantor proyek juga melacak pembukaan dokumen. Di antara dua belas rencana tersebut, jumlah median kali siapa pun membuka dokumen setelah persetujuan adalah tiga. Dua tidak pernah dibuka lagi oleh siapa pun.

Konsekuensi itu muncul pada satu proyek. Sebuah jendela kepemilikan jalur, tanggal yang benar-benar tidak bisa digeser yang disepakati berbulan-bulan sebelumnya dengan pemilik infrastruktur, dicatat di halaman empat puluh satu rencana dan tidak di mana pun lagi. Tim pelaksana merencanakan pekerjaan untuk satu minggu saat akses tidak tersedia. Tiga minggu hilang, dengan estimasi biaya seratus delapan puluh enam ribu pound.

Informasinya sudah didokumentasikan. Informasinya sudah disetujui. Informasi itu ada di dalam enam puluh delapan halaman, empat perlima di antaranya menjelaskan bagaimana Kelvedon mengelola proyek secara umum.

Hasil perombakan menghasilkan dua dokumen. Dokumen metodologi sekitar empat puluh halaman, ditulis sekali dan dimiliki oleh kantor proyek. Dan template rencana manajemen proyek delapan bagian, menargetkan delapan hingga dua belas halaman, di mana setiap bagian hanya menanyakan apa yang berbeda tentang proyek ini.

Di antara dua puluh satu proyek berikutnya, panjang rencana median adalah sebelas halaman dan median pembukaan setelah persetujuan adalah empat belas. Uji sorot pada delapan di antaranya menghasilkan median konten spesifik proyek sebesar delapan puluh satu persen.

Batasan yang tidak bisa digeser kini juga berada di lampiran satu halaman, diekstrak dari rencana dan diedarkan secara terpisah, karena pelajaran dari jendela kepemilikan adalah tanggal penting seharusnya tidak bisa ditemukan hanya dengan membaca.

Rencana turunan, dan mana yang benar-benar Anda butuhkan

Posisi yang jujur adalah bahwa sebagian besar proyek membutuhkan dua atau tiga dari hal-hal ini sebagai dokumen terpisah dan merujuk sisanya. Membuat semuanya sepuluh karena template mencantumkan sepuluh adalah yang menghasilkan rencana enam puluh halaman yang tidak dibuka siapa pun.

Cara membuat rencana manajemen proyek, langkah demi langkah

Mulailah dari brief, agar rencana melayani masalah yang telah disepakati, bukan mengulang pendekatan.

Tulis batasan yang tidak bisa digeser terlebih dahulu. Batasan ini menentukan apa yang memungkinkan, dan ini adalah bagian yang paling mungkin berubah dari sisanya.

Isi setiap bagian yang tersisa hanya dengan menjawab apa yang berbeda di sini. Jika jawaban yang jujur adalah tidak ada, tulis rujukannya dan lanjutkan.

Sebutkan individu di mana rencana bergantung pada ketersediaan seseorang, lalu konfirmasi dengan mereka.

Tentukan rencana turunan mana yang layak menjadi dokumen terpisah menggunakan tabel di atas, lalu rujuk yang lainnya.

Tulis bagian penyimpangan terakhir, setelah Anda tahu di mana proyek ini berbeda dari pendekatan standar.

Lalu terapkan uji sorot pada draf Anda sendiri sebelum diedarkan. Apa pun yang tidak disorot adalah kandidat untuk dihapus.

Tahap kunci yang harus dicakup oleh rencana manajemen proyek

Rencana harus menyampaikan sesuatu yang spesifik proyek untuk setiap tahap, dan untuk sebagian besar proyek, hal itu biasanya singkat.

Inisiasi. Apa yang memberi otorisasi ini dan berdasarkan kriteria keberhasilan apa.

Perencanaan. Batasan, penugasan sumber daya, dan keputusan pendekatan. Di sinilah sebagian besar konten rencana berada.

Eksekusi. Apa yang berbeda dalam cara proyek ini akan disampaikan, termasuk setiap penyimpangan dari metode standar.

Monitoring dan kontrol. Apa yang akan dipantau yang tidak biasa untuk proyek ini, bukan ritme pelaporan standar.

Penutupan dan serah terima. Siapa yang menerima output dan apa yang mereka butuhkan untuk menerimanya, yang dicakup oleh project handover checklist template kami, dan sebaiknya disepakati saat perencanaan, bukan saat penutupan.

Tahap di mana rencana paling lemah adalah tahap terakhir, karena jaraknya paling jauh saat rencana ditulis. Menamai tim penerima dan kriteria penerimaan mereka saat perencanaan adalah hal paling bernilai yang bisa dimuat oleh bagian penutupan.

Metodologi manajemen proyek yang umum, dan apa yang berubah

Bentuk rencana berubah mengikuti metode, dan uji sorot berlaku untuk semuanya.

Waterfall atau stage-gate. Rangkaian lengkap rencana turunan bersifat konvensional di sini, dan disiplin memisahkan metodologi dari rencana paling penting, karena template paling berat.

Agile. Banyak hal yang didokumentasikan dalam rencana tradisional justru ada dalam cara kerja. Rencana tetap perlu batasan yang tidak bisa digeser, komitmen penugasan sumber daya, pendekatan pengadaan, dan penyimpangan. Yang tidak dibutuhkan adalah rencana manajemen ruang lingkup untuk ruang lingkup yang memang sengaja bersifat emergent.

PRINCE2. Dokumentasi inisiasi proyek menjalankan peran ini dan strukturnya ditentukan. Pemisahan metodologi tetap berlaku, karena PRINCE2 secara eksplisit mengharapkan penyesuaian, dan penyesuaian itulah yang perlu dilihat pembaca.

Hibrida. Realitas yang paling umum, dan di mana bagian penyimpangan mendapatkan tempatnya, karena proyek hibrida secara definisi menyimpang dari metode standar dengan cara-cara spesifik yang perlu dicatat.

Metode apa pun yang berlaku, tugas rencana tetap sama: mencatat apa yang spesifik untuk proyek ini. Metode menentukan di mana materi umum berada, bukan apakah materi itu masuk ke dalam rencana.

Sederhana atau lengkap: seberapa panjang rencana seharusnya?

Kedua ekstrem muncul dalam hal yang dicari orang, yang menunjukkan bahwa pertanyaannya memang belum terselesaikan: sebagian menginginkan template satu halaman yang sederhana, sementara yang lain menginginkan dokumen rencana lengkap.

Solusinya adalah mereka menginginkan dua bagian berbeda dari hal yang sama. Template manajemen proyek yang sederhana biasanya adalah jadwal dan daftar tugas, yang merupakan artefak operasional. Rencana manajemen proyek yang lengkap adalah dokumen tata kelola. Keduanya sah dan tidak satu pun menggantikan yang lain.

Untuk rencana khususnya: delapan hingga dua belas halaman untuk proyek yang substansial, dua atau tiga untuk proyek kecil, ditambah rencana turunan mana pun yang memang layak menjadi dokumen terpisah. Jika tata kelola Anda mengharuskan lebih, buat dokumen metodologi dan rujukannya, yang memenuhi persyaratan tanpa membuat dokumen yang tidak dibaca siapa pun.

Jumlah yang layak dilacak bukan halaman. Melainkan pembukaan setelah persetujuan, yang biasanya akan diberitahukan oleh sebagian besar sistem dokumen, dan hampir tidak pernah dilihat oleh siapa pun.

Rencana manajemen proyek atau rencana proyek?

Istilah-istilah ini digunakan secara bergantian dan pembedaan itu layak dipertahankan.

Sebuah rencana manajemen proyek menjelaskan bagaimana proyek akan dikelola: pendekatan, batasan, tata kelola, rencana turunan. Ini adalah dokumen tata kelola, disetujui sekali dan direvisi saat ada perubahan.

Sebuah rencana proyek, dalam penggunaan sehari-hari, biasanya berarti jadwal: tugas, ketergantungan, durasi, dan pemilik. Ini adalah artefak operasional, diperbarui setiap minggu.

Mencampuradukkan keduanya menghasilkan dua kegagalan yang familiar. Dokumen tata kelola dengan bagan Gantt di dalamnya, yang sudah ketinggalan dalam waktu dua minggu. Atau jadwal yang disajikan sebagai rencana, yang tidak berisi batasan, tidak ada komitmen penugasan sumber daya, dan tidak ada kriteria penerimaan.

Pisahkan keduanya dan biarkan masing-masing diperbarui pada siklusnya sendiri. IT project plan template kami mencakup sisi perencanaan termasuk kalender batasan, dan project documentation template kami mencakup dokumen mana dari hasil tersebut yang layak dipertahankan setelah penutupan.

Bisakah saya mendapatkan template rencana manajemen proyek di Excel?

Excel untuk artefak yang berupa tabel dan diperbarui: jadwal, komitmen sumber daya per orang, daftar risiko, daftar batasan beserta pemilik dan tanggal, serta daftar paket pengadaan beserta lead time.

Word atau Google Docs untuk rencana itu sendiri, yang berupa narasi yang menjelaskan keputusan dan disetujui, bukan dilacak.

PDF untuk versi yang disetujui, diekspor dan diberi tanggal. Karena rencana adalah dokumen yang dirujuk orang saat ada sesuatu yang dipersengketakan, versi yang dibekukan dan disetujui itu penting.

Kebanyakan organisasi akhirnya memiliki rencana dalam satu dokumen dan empat atau lima spreadsheet yang saling terhubung, dan itu adalah susunan yang tepat. Yang tidak bekerja adalah salah satu ekstrem: rencana sepenuhnya di spreadsheet kehilangan keputusan, dan rencana sepenuhnya dalam dokumen berarti tabel menjadi usang.

Cara menjaga konten spesifik proyek tetap terlihat

Pelajaran dari contoh yang dikerjakan sebenarnya bukan soal panjang. Pelajarannya adalah konten spesifik proyek yang penting menjadi tidak terlihat ketika dikelilingi oleh materi umum, dan tidak ada jumlah penulisan yang baik yang bisa memperbaikinya.

Dua kebiasaan membantu. Ekstrak batasan yang tidak bisa digeser ke satu halaman dan edarkan secara terpisah, karena item-item itulah yang paling mahal jika terlewat. Dan pastikan dokumen metodologi benar-benar tetap mutakhir, karena sejak saat dokumen itu tidak lagi terbaru, orang mulai menuliskannya kembali dalam rencana.

Trupeer AI berguna untuk yang kedua. Dokumen metodologi menjelaskan proses, dan proses berubah: alat kontrol perubahan baru, jalur pelaporan yang berbeda, jalur persetujuan yang diperbarui. Mencatat proses sekali menghasilkan prosedur tertulis dengan langkah dan layar yang sudah ditangkap, sehingga metodologi bisa tetap akurat dengan biaya lebih murah daripada dibiarkan sampai tidak ada yang lagi mempercayainya.

Catat. Branding. Terjemahkan. Trupeer-kan.

Hal ini penting karena seluruh pemisahan bergantung pada metodologi yang dapat dipercaya. Rencana yang merujuk metodologi yang tidak dipercaya sebagai yang terbaru akan mulai mengulanginya dalam dua proyek. SOP creator mencakup prosedur-prosedur tersebut dan semuanya ada di knowledge base Anda dengan branding yang konsisten. Instruksi penyiapan ada di document template setup guide.

Pertanyaan yang Sering Diajukan

Apakah ada template rencana manajemen proyek gratis di Excel?

Excel cocok untuk tabel yang menjadi dasar rencana: jadwal, komitmen sumber daya, daftar risiko, batasan beserta pemilik, lead time pengadaan. Tidak ada unduhan berbatas dan tidak ada formulir. Simpan rencana itu sendiri sebagai dokumen dan tautkan lembarannya, karena keduanya diperbarui pada siklus yang berbeda.

Apakah ada template rencana manajemen proyek gratis di Word?

Struktur delapan bagian di atas langsung ditempel ke Word atau Google Docs. Terapkan uji sorot pada draf pertama Anda sebelum diedarkan, karena latihan ini biasanya menghapus lebih banyak daripada yang ditambahkan dan menghasilkan versi yang benar-benar akan dibuka orang.

Apakah ada template rencana manajemen proyek gratis di PDF?

Ekspor rencana yang disetujui dan simpan versi kerja agar tetap bisa diedit. Rencana adalah dokumen yang dirujuk saat ruang lingkup atau pendekatan dipersengketakan, jadi versi yang dibekukan dan diberi tanggal layak dimiliki bersama versi yang masih berjalan.

Di mana saya bisa menemukan rencana manajemen proyek lengkap dalam PDF?

Contoh yang dipublikasikan dengan rangkaian lengkap rencana turunan mudah ditemukan, termasuk dari badan publik dan universitas, dan berguna untuk melihat struktur konvensionalnya. Baca satu dan jalankan uji sorot di dalamnya: sebagian besar contoh yang dipublikasikan adalah pengulangan metodologi secara substansial, dan itulah tepatnya mengapa contoh tersebut aman untuk dipublikasikan.

Apakah ada template manajemen proyek sederhana di Excel?

Ya, dan biasanya itu adalah jadwal dan daftar tugas, bukan rencana. Keduanya layak dimiliki. Jadwal melacak pekerjaan; rencana mencatat batasan, penugasan sumber daya, dan keputusan pendekatan. Mengambil template yang sederhana saat Anda membutuhkan rencana adalah cara proyek berakhir tanpa catatan tentang apa yang telah disepakati.

Apakah saya perlu perangkat lunak rencana proyek?

Tidak untuk menulis rencana, yang merupakan dokumen. Perangkat lunak layak digunakan untuk jadwal setelah Anda melewati kira-kira tiga puluh tugas yang masih berjalan dengan ketergantungan yang berubah dan lebih dari segelintir orang yang memperbarui status. Di bawah itu, spreadsheet lebih cepat dan semua orang sudah memilikinya.

Siapa yang harus menulis rencana manajemen proyek?

Manajer proyek, dengan sponsor menyetujui dan kantor proyek mengonfirmasi rencana turunan mana yang diperlukan. Jika rencana turunan mencakup pekerjaan fungsi lain, seperti pengadaan, maka fungsi tersebut seharusnya menulisnya, bukan manajer proyek menebak lead time mereka.

Seberapa sering rencana manajemen proyek harus diperbarui?

Berdasarkan perubahan, bukan berdasarkan siklus. Saat sebuah batasan bergeser, saat penugasan sumber daya berubah, saat pendekatan menyimpang dari yang disetujui, atau saat ruang lingkup berubah. Jadwal diperbarui setiap minggu dan rencana tidak, yang menjadi alasan praktis untuk menjaga keduanya sebagai dokumen terpisah.