Proyek transisi OSS setelah PP 28/2025 perlu dipilah sebelum petugas atau pelaku usaha menekan tombol pengajuan ulang. Portal OSS menyediakan jalur “Perizinan Berusaha Data Lama” untuk proyek tertentu yang sudah mempunyai persyaratan dasar tata ruang sebelum implementasi PP 28 pada 5 Oktober 2025, tetapi proses perizinan berusahanya belum selesai. Jalur ini bukan alasan untuk memindahkan semua proyek lama secara seragam.
Artikel ini menyusun pemeriksaan praktis bagi DPMPTSP, unit teknis, pendamping, dan pelaku usaha. Untuk penguatan proses layanan, kewenangan, dan penggunaan OSS secara lebih luas, lihat Bimtek Pelayanan Perizinan Berusaha Elektronik melalui OSS Berbasis Risiko.
Mengapa proyek lama harus diperiksa ulang?
PP 28/2025 berlaku sejak 5 Juni 2025 dan mencabut PP 5/2021. Ruang lingkupnya mencakup persyaratan dasar, Perizinan Berusaha, PB UMKU, norma dan standar, layanan sistem OSS, pengawasan, evaluasi, penyelesaian hambatan, serta sanksi. Perubahan kerangka ini membuat proyek yang belum selesai tidak cukup dinilai hanya dari tanggal pembuatan akun atau tanggal terbit NIB.
Portal OSS menyebut jalur data lama untuk proyek transisi sebelum 5 Oktober 2025 yang persyaratan dasar tata ruangnya telah terbit tetapi perizinan berusaha belum rampung. Karena itu, “proyek lama” dan “proyek transisi yang memenuhi kondisi panduan” bukan istilah yang sama.
Empat pertanyaan penyaring sebelum membuka alur
- Proyek mana yang diperiksa? Catat NIB, KBLI, lokasi, skala usaha, penanggung jawab, dan nomor proyek.
- Apa bukti persyaratan dasarnya? Identifikasi nomor, tanggal terbit, lokasi, luas, kegiatan, dan status dokumen tata ruang.
- Di titik mana proses berhenti? Bedakan belum mengajukan persyaratan, perlu perbaikan, menunggu pembayaran, menunggu verifikasi, atau status lain.
- Apa tindakan terakhir yang sudah dilakukan? Simpan tanggal, akun pelaksana, tangkapan layar, pesan sistem, dan respons instansi.
Matriks klasifikasi proyek transisi
| Kondisi yang ditemukan | Pemeriksaan awal | Tindak lanjut terkendali |
|---|---|---|
| Persyaratan tata ruang terbit, pemenuhan PB belum dilakukan | Pastikan proyek, KBLI, lokasi, dan dokumen benar | Gunakan panduan data lama bila kondisi proyek sesuai |
| Persyaratan tata ruang terbit, data perlu perbaikan | Petakan kolom salah dan bukti pembanding | Koreksi hanya data yang terverifikasi; simpan jejak perubahan |
| Menunggu pembayaran PNBP atau status menggantung | Cek kode billing, tanggal, kanal, dan pesan status | Eskalasi dengan paket bukti lengkap; jangan membuat proyek duplikat |
| Ada fasilitas atau proses lain yang masih berjalan | Identifikasi ketergantungan dan pemilik proses | Tahan tindakan yang berisiko memutus proses aktif |
| Tidak ada bukti persyaratan dasar terbit | Validasi pada akun dan dokumen sumber | Jangan mengasumsikan jalur data lama; ikuti alur yang berlaku |
Matriks ini adalah alat triase, bukan pengganti keputusan pada sistem. Tampilan dan status aktual di OSS tetap menjadi dasar operasional. Bila data proyek tidak sama dengan dokumen sumber, hentikan perubahan sampai selisihnya dijelaskan.
Bukti minimum yang perlu dikumpulkan
- identitas pelaku usaha, NIB, nomor proyek, KBLI, dan skala usaha;
- alamat serta koordinat lokasi, luas lahan, dan bentuk penguasaan lahan;
- nomor dan tanggal dokumen persyaratan dasar tata ruang;
- status PB atau PB UMKU yang belum selesai;
- riwayat perbaikan, pembayaran, verifikasi, dan notifikasi sistem;
- tangkapan layar yang memuat tanggal serta konteks menu, tanpa menyebarkan kata sandi;
- nama PIC pelaku usaha, DPMPTSP, atau unit teknis yang menangani tindak lanjut.
Panduan OSS meminta pengguna memastikan hak akses sebelum melanjutkan proses. Hak akses dipakai untuk bekerja di sistem, tetapi kata sandi tidak boleh dicatat dalam register bersama atau dikirim melalui lampiran tiket.
Periksa konsistensi lokasi dan kegiatan usaha
Sebelum melakukan perbaikan, bandingkan lokasi proyek, luas, KBLI, uraian kegiatan, serta dokumen penguasaan lahan. Kesalahan satu elemen dapat mengarahkan pemeriksaan ke persyaratan yang berbeda. Jangan mengubah KBLI hanya untuk melewati kendala tanpa dasar kegiatan usaha yang nyata.
Untuk kondisi lokasi tertentu, panduan OSS meminta dokumen pendukung mengenai penguasaan lahan dan kesesuaian kegiatan. Petugas perlu mencatat apakah dokumen milik sendiri, sewa, atau pinjam pakai; siapa pemiliknya; berapa luasnya; siapa penerbit dokumen; serta masa berlakunya.
Bedakan izin utama, PB UMKU, dan persyaratan dasar
PP 28/2025 membedakan persyaratan dasar, Perizinan Berusaha, dan Perizinan Berusaha untuk Menunjang Kegiatan Usaha. Status salah satu komponen tidak otomatis berarti seluruh rangkaian telah selesai. NIB yang sudah terbit juga tidak selalu membuktikan izin atau standar untuk risiko tertentu telah dipenuhi.
Gunakan satu daftar per komponen: apa yang wajib, status sekarang, instansi yang memverifikasi, bukti penerbitan, tenggat, dan hambatan. Cara ini mengurangi kesalahan ketika satu proyek memiliki beberapa KBLI atau lebih dari satu PB UMKU.
Register kendala dan keputusan
| Kolom register | Isi yang diharapkan | Bukti penutup |
|---|---|---|
| Identitas kasus | NIB, proyek, KBLI, lokasi | rekaman sistem yang cocok |
| Status awal | menu, status, tanggal, pesan | tangkapan layar bertanggal |
| Akar kendala | data, dokumen, pembayaran, verifikasi, sistem | hasil pemeriksaan atau respons resmi |
| Keputusan | lanjut, koreksi, eskalasi, atau tahan | dasar dan pemberi keputusan |
| Hasil akhir | status sesudah tindakan | nomor/tanggal keluaran dan tautan arsip |
Contoh ilustratif triase satu proyek
Contoh ilustratif: sebuah proyek memiliki NIB dan persyaratan dasar tata ruang yang terbit sebelum 5 Oktober 2025. Permohonan PB belum selesai karena data kegiatan perlu diperbaiki. Tim mencocokkan nomor proyek, KBLI, lokasi, luas, dan dokumen penguasaan lahan; mencatat kolom yang tidak konsisten; lalu mengikuti panduan data lama pada akun resmi.
Setelah perubahan, tim menyimpan status baru, waktu tindakan, nama PIC, dan keluaran sistem. Jika status tetap menggantung, paket eskalasi berisi kronologi, bukti sebelum-sesudah, dan pertanyaan spesifik. Tim tidak membuat proyek kedua karena tindakan itu dapat memperbesar risiko data ganda.
Kapan kasus harus dieskalasi?
Eskalasi layak dilakukan ketika dokumen sumber sudah konsisten tetapi sistem menampilkan data berbeda; status pembayaran tidak berubah; permohonan menunggu melebihi waktu yang diinformasikan; menu yang dirujuk panduan tidak tersedia; atau ada proses aktif yang dapat terdampak bila data diubah. Tuliskan satu pertanyaan utama per kasus agar petugas dukungan dapat mengidentifikasi masalah.
Sertakan identitas proyek dan kronologi, tetapi jangan mengirim kata sandi, OTP, atau data pribadi yang tidak diperlukan. Gunakan kanal bantuan resmi yang tersedia pada portal OSS.
Bangun paket eskalasi yang bisa langsung diperiksa
Paket eskalasi yang baik tidak hanya berisi kalimat “status belum berubah”. Susun ringkasan satu halaman berisi identitas proyek, hasil yang diharapkan, status aktual, waktu mulai kendala, langkah yang sudah dicoba, dan satu pertanyaan yang perlu dijawab. Lampirkan bukti secara berurutan serta beri nama berkas yang mudah ditelusuri. Jika kasus pernah diteruskan, catat nomor tiket dan jawaban sebelumnya.
Sebelum mengirim, lakukan pemeriksaan oleh orang kedua untuk memastikan identitas proyek konsisten dan data sensitif telah disamarkan. Setelah jawaban diterima, tautkan jawaban ke register, tentukan PIC tindakan berikutnya, dan tetapkan tenggat baru. Dengan cara ini, eskalasi menjadi bagian dari kendali kasus, bukan percakapan terpisah yang mudah hilang.
Peran DPMPTSP dan unit teknis
DPMPTSP dapat membantu triase, konsistensi bukti, koordinasi, dan pemantauan tindak lanjut sesuai kewenangannya. Unit teknis memeriksa substansi standar atau persyaratan sektoral. Pelaku usaha bertanggung jawab memastikan data usaha dan dokumen yang diajukan benar. Pembagian ini perlu dicatat agar kasus tidak berpindah-pindah tanpa pemilik.
Untuk menilai kesiapan proyek investasi secara lebih luas—bukan hanya penyelesaian transaksi OSS—gunakan pula kerangka data, kewenangan, dan tindak lanjut investor.
Checklist sebelum menutup kasus
- Identitas proyek dan KBLI sudah cocok dengan dokumen sumber.
- Status persyaratan dasar, PB, dan PB UMKU dipisahkan.
- Dasar penggunaan jalur data lama tercatat.
- Perubahan memiliki bukti sebelum dan sesudah.
- Tidak ada proyek ganda yang dibuat untuk masalah yang sama.
- PIC, tenggat, dan jalur eskalasi jelas.
- Status akhir serta dokumen keluaran tersimpan.
Kesalahan yang perlu dihindari
Hindari menyamakan semua akun lama dengan proyek transisi, mengubah KBLI tanpa dasar, menimpa bukti lama, membagikan kredensial, atau membuat permohonan baru sebelum memastikan nasib permohonan aktif. Jangan pula menyimpulkan izin selesai hanya karena NIB telah terbit.
Jika panduan dan tampilan akun tidak selaras, dokumentasikan perbedaannya dan minta konfirmasi melalui kanal resmi. Prosedur internal perlu mengikuti pembaruan sistem dan regulasi, bukan tangkapan layar lama yang sudah tidak relevan.
Rujukan resmi
- PP 28/2025 tentang Penyelenggaraan Perizinan Berusaha Berbasis Risiko — Database Peraturan BPK
- Kumpulan panduan resmi OSS Berbasis Risiko
- Pengumuman resmi proyek transisi sebelum implementasi PP 28
- Panduan Perizinan Berusaha Data Lama — OSS
Siapkan simulasi kasus OSS yang dapat ditelusuri
Bawa contoh register proyek, status persyaratan dasar, dan paket bukti kendala agar pembahasan pelatihan dapat difokuskan pada alur kerja serta koordinasi yang benar.