Di bagian pertama kami memetakan siklus pembelian sebagai tujuh tahap dari permintaan hingga pembayaran, dan menyarankan latihan sederhana: ambil sepuluh faktur pemasok terakhir yang sudah Anda bayar dan telusuri masing-masing kembali ke permintaan, persetujuan, pesanan pembelian, dan catatan penerimaannya. Dokumen pertama yang Anda cari dalam latihan itu adalah permintaan pembelian. Jika ada faktur yang tidak memilikinya, di sinilah kita mulai, karena setiap dokumen sesudahnya membutuhkan sesuatu untuk dirujuk.

Bagian ini membahas dua tahap pertama sekaligus: permintaan yang mencatat kebutuhan, dan persetujuan yang memutuskan bahwa perusahaan akan mengeluarkan uang untuknya. Bagian ini menjawab pertanyaan yang terdengar administratif tetapi sebenarnya operasional: siapa menyetujui apa, sampai batas berapa, siapa yang menyetujui menggantikan mereka ketika mereka tidak ada, dan apa yang terjadi ketika kebutuhan tidak bisa menunggu.

Permintaan pembelian: dokumen yang menjadi gantungan semua dokumen sesudahnya

Permintaan pembelian bukanlah urusan kertas yang ditambahkan di atas pekerjaan. Inilah saat sebuah kebutuhan berhenti menjadi satu kalimat dalam panggilan telepon dan menjadi catatan bernomor. Tanpanya, pesanan pembelian tidak punya apa pun untuk dirujuk, orang yang menerima barang di lokasi tidak tahu apa yang harus ditunggu, dan akuntan tidak tahu mengapa ia membayar. Permintaan yang baik menjawab lima pertanyaan inti:

  • Siapa yang membutuhkannya? Nama dan peran pemohon, bukan nama orang yang meneruskan pesannya: insinyur lapangan, pengawas lini produksi, kepala pemeliharaan hotel.
  • Apa tepatnya? Barangnya, spesifikasinya, jumlahnya, dan satuannya. Baris seperti material pipa bukanlah acuan, karena tidak ada yang bisa mencocokkan barang yang datang dengannya nanti.
  • Untuk proyek, lokasi, atau properti mana? Kolom inilah yang mengirim biaya ke tempat yang semestinya. Pembelian yang tidak masuk ke proyek mana pun menjadi biaya umum yang tidak bisa ditelusuri siapa pun.
  • Mengapa? Satu baris sudah cukup: satu pos dalam daftar kuantitas, suku cadang untuk mesin yang berhenti, bahan habis pakai untuk musim mendatang. Baris itu menghemat telepon dari pemberi persetujuan untuk bertanya.
  • Kapan dibutuhkan? Tanggal ketika Anda benar-benar membutuhkannya, bukan kata mendesak di setiap permintaan. Tanggal itulah yang dibandingkan bagian pembelian dengan waktu pengiriman pemasok.

Permintaan juga membutuhkan nilai perkiraan, meskipun kasar, karena persetujuan berdasarkan jumlah membutuhkan jumlah. Jika pemohon tidak mengetahuinya, bagian pembelian menambahkannya sebelum permintaan diajukan untuk persetujuan. Kemudian permintaan mendapat nomor yang menjadi acuan setiap dokumen berikutnya di dalam sistem: persetujuan, pesanan pembelian, catatan penerimaan, dan faktur pemasok. Ini logika yang sama dengan yang kami uraikan dalam perintah kerja dan nomor permintaan tempat biaya bergantung: ketika setiap dokumen terhubung ke nomor yang sama, Anda dapat mulai dari titik mana pun dalam rantai dan mencapai awalnya tanpa bertanya kepada siapa pun.

Matriks persetujuan: jumlah saja tidak cukup

Matriks persetujuan adalah tabel yang menjawab satu pertanyaan: siapa yang bisa berkata ya untuk permintaan ini? Matriks paling sederhana dibangun di atas satu sumbu, yaitu jumlah: sampai batas tertentu manajer departemen menyetujui, di atasnya manajer keuangan, dan di atas itu pemilik. Jumlah adalah sumbu yang sah, tetapi jenis pembelian mengubah pertanyaan yang dijawab oleh pemberi persetujuan:

  • Material stok. Besi dan semen untuk lokasi proyek, bahan baku untuk lini produksi, perlengkapan kebersihan untuk hotel. Pertanyaannya di sini adalah apakah Anda benar-benar membutuhkan jumlah ini, dan apakah barang itu sudah ada di gudang lain atau di lokasi lain sebelum Anda membelinya. Karena itu, akan membantu jika pemberi persetujuan dapat melihat stok barang tersebut pada saat persetujuan.
  • Jasa dan subkontraktor. Pemeliharaan lift, pekerjaan insulasi oleh subkontraktor, kontrak kebersihan. Di sini lingkup pekerjaan lebih penting daripada harga: apa tepatnya yang akan dikerjakan, dan bagaimana kita tahu bahwa pekerjaan itu sudah selesai. Jadi permintaan membutuhkan pemberi persetujuan untuk dua pertanyaan yang berbeda: orang yang memiliki pengetahuan teknis menyetujui lingkupnya, dan orang yang ditunjuk matriks untuk jumlah tersebut menyetujui pengeluarannya.
  • Aset modal. Peralatan, kendaraan, generator, mesin untuk lini produksi. Ini adalah komitmen yang berlangsung bertahun-tahun dan membawa biaya operasional serta pemeliharaan, sehingga wajar jika diajukan ke tingkat yang lebih tinggi daripada yang dituntut oleh jumlahnya saja.
  • Pembelian mendesak. Pembelian ini mendapat jalurnya sendiri, yang dibahas di bawah, karena orang akan mengakali matriks yang tidak memberi ruang bagi keadaan darurat begitu keadaan darurat pertama terjadi.

Angka-angkanya sendiri, yaitu batas tempat sebuah permintaan berpindah dari satu tingkat ke tingkat berikutnya, ditetapkan oleh pemilik, atau oleh dewan jika ada, karena angka itu mencerminkan ukuran perusahaan, marginnya, dan seberapa banyak yang ingin dilihat sendiri oleh pemilik. Tidak ada batas yang benar secara umum dan cocok untuk setiap perusahaan, dan batas yang dipinjam dari perusahaan lain mungkin terlalu ketat sehingga menghentikan pekerjaan, atau terlalu longgar sehingga tidak mengendalikan apa pun.

Dua aturan berlaku untuk setiap jenis. Pertama, tidak ada orang yang menyetujui permintaannya sendiri; permintaan milik pemberi persetujuan diajukan ke tingkat di atasnya. Kedua, wewenang persetujuan melekat pada peran, bukan pada orang, sehingga ketika seorang manajer lokasi pindah ke lokasi lain, wewenangnya berpindah mengikuti peran yang baru alih-alih menunggu seseorang ingat untuk mengubahnya. Kami menjelaskan prinsip itu secara rinci dalam hak akses: siapa melihat apa setelah data keluar dari file; matriks persetujuan adalah prinsip yang sama yang diterapkan pada uang.

Lalu siapa yang menyetujui ketika pemberi persetujuan sedang bepergian? Di sinilah matriks yang tidak pernah merencanakan ketidakhadiran menjadi rusak, dan celahnya diisi dengan pesan yang berbunyi tolong setujui untuk saya, atau kata sandi yang dipakai bersama oleh dua orang. Solusinya adalah delegasi yang diatur sebelumnya di dalam sistem: kepada siapa, untuk berapa lama, dan dalam batas apa. Persetujuan dari penerima delegasi tampil atas namanya sendiri, dengan tanda atas nama pemberi persetujuan asli, delegasi berakhir otomatis pada tanggalnya, dan pemberi persetujuan melihat apa saja yang disetujui selama ia tidak ada ketika kembali. Dan jika sebuah permintaan tertahan tanpa keputusan melewati tenggat yang ditetapkan pemilik, permintaan itu dieskalasi ke tingkat berikutnya alih-alih menunggu di kotak masuk orang yang sedang cuti.

Dua jalan pintas yang harus ditutup sistem

Di sekitar matriks mana pun, betapapun baik rancangannya, dua jalan pintas tetap terbuka. Menempuhnya tidak memerlukan niat buruk; cukup persetujuan yang lambat dan pekerjaan yang tidak bisa menunggu. Jadi sistem menutupnya dari dua sisi: dengan kontrol yang memblokir jalan pintas itu, dan dengan persetujuan yang cukup cepat sehingga tidak ada yang membutuhkannya.

  • Memecah permintaan. Permintaan yang melebihi batas manajer lokasi dipecah menjadi dua atau tiga permintaan di bawah batas tersebut, untuk barang yang sama dari pemasok yang sama dalam beberapa hari. Setiap permintaan tampak wajar secara terpisah; bersama-sama, permintaan itu melampaui batas tanpa pernah sampai ke orang yang memiliki wewenang atasnya. Sistem menutup celah ini dengan melihat totalnya, bukan permintaan tunggal: permintaan pada proyek yang sama yang memiliki barang atau pemasok yang sama dalam periode yang ditetapkan pemilik dijumlahkan, dan jika totalnya melewati batas, permintaan itu diajukan ke tingkat yang dapat menyetujuinya.
  • Persetujuan lewat WhatsApp. Manajer membalas OK pada foto sebuah penawaran di grup yang berisi puluhan pesan lain. Persetujuannya nyata, tetapi persetujuan atas apa? Versi penawaran yang mana, berapa jumlahnya, proyek yang mana? Dua bulan kemudian pesan itu terkubur di bawah ribuan pesan lain, atau tersimpan di ponsel yang sudah diganti. Sementara itu, bagi usaha yang dikenai PPN, faktur yang dibayar berdasarkan persetujuan itu wajib disimpan sekurang-kurangnya enam tahun sejak akhir masa pajak yang terkait menurut Pasal 66 Peraturan Pelaksanaan PPN, sementara tidak ada yang tahu di mana persetujuan di balik pembelian itu akan berada.

Solusinya tidak berarti kembali ke tanda tangan dengan kertas dan pena. Undang-Undang Transaksi Elektronik memberikan kekuatan mengikat pada transaksi, catatan, dan tanda tangan elektronik, dengan tunduk pada syarat-syarat yang ditetapkannya (Pasal 5), dan ketika menilai nilai pembuktian suatu transaksi elektronik, undang-undang itu mempertimbangkan seberapa andal metode yang digunakan untuk membuat, menyimpan, atau mengirimkan catatan tersebut, dan apakah catatan itu dapat diubah (Pasal 9(4)). Masalah persetujuan lewat WhatsApp bukanlah sifat elektroniknya; masalahnya adalah persetujuan itu terlepas dari permintaan yang disetujuinya. Jadi persetujuan dilakukan pada permintaan itu sendiri di dalam sistem, dengan memuat nama pemberi persetujuan, waktu, jumlah, dan versi yang disetujui, dan jika permintaan berubah sesudahnya dalam jumlah barang atau nilai, permintaan itu kembali diajukan untuk persetujuan. WhatsApp tetap menjadi saluran pemberitahuan: pemberi persetujuan menerima notifikasi berisi tautan ke permintaan dan menyetujuinya dari ponsel tanpa membuka laptop, sehingga persetujuan yang lambat tidak lagi menjadi alasan untuk mengakalinya.

Pembelian mendesak: jalur resmi alih-alih jalan pintas

Kebocoran air di kamar hotel sebelum tamu tiba, pompa yang berhenti di lini produksi, lokasi proyek yang menunggu material untuk menyelesaikan pengecoran beton yang sudah berjalan. Pada saat-saat seperti itu tidak ada yang menunggu siklus persetujuan penuh, dan memang tidak seharusnya. Matriks yang mengabaikan kenyataan ini tidak menghentikan pembelian mendesak; matriks itu mendorongnya ke luar sistem, sehingga barang dibeli dengan uang tunai atau dari kantong pribadi karyawan dan muncul di pembukuan dua minggu kemudian tanpa permintaan dan tanpa persetujuan.

Pendekatan yang jujur adalah sistem yang mengakui bahwa keadaan darurat itu ada dan memberinya jalur resmi dengan syarat yang jelas:

  • Siapa yang dapat memicunya. Peran tertentu, seperti manajer lokasi atau manajer pemeliharaan yang sedang bertugas, bukan setiap karyawan.
  • Apa yang dianggap mendesak. Definisi tertulis, bukan perasaan: risiko keselamatan, operasi yang terhenti, atau kerusakan yang meluas jika ditunda. Ini logika yang sama dengan yang kami sarankan untuk permintaan pemeliharaan dalam dari laporan hingga selesai: menjalankan permintaan pemeliharaan.
  • Data seminimal mungkin. Apa, mengapa mendesak, dan foto bila memungkinkan, diisi dari ponsel di lokasi alih-alih formulir lengkap.
  • Batas pengeluaran. Batas yang ditetapkan pemilik atas apa yang dapat dibeli melalui jalur mendesak; di atas batas itu, pemberi persetujuan menyetujui pada permintaan itu sendiri, dari ponselnya, sebelum pembelian.
  • Persetujuan setelahnya, dengan tenggat. Pembelian langsung dilakukan, dan persetujuannya dilengkapi dalam tenggat yang ditetapkan pemilik. Jika tenggat lewat tanpa persetujuan, permintaan itu muncul di daftar yang dilihat sendiri oleh pemilik.

Lalu pantau porsi permintaan mendesak dari total permintaan Anda. Keadaan darurat yang sebenarnya memang terjadi, tetapi ketika jalur mendesak menjadi jalur normal di departemen atau lokasi tertentu, itu bukan kelalaian orang; itu tanda bahwa perencanaan di sana perlu ditinjau, atau bahwa persetujuan normal lebih lambat daripada yang dapat ditanggung pekerjaan.

Pandangan Origami

Ketika kami membangun alur kerja pembelian untuk sebuah perusahaan, kami mulai dari matriksnya saat ini sebagaimana yang benar-benar berjalan, bukan sebagaimana yang tertulis dalam buku pedoman kebijakan: siapa yang menyetujui hari ini, di mana persetujuan tersendat, dan di mana orang mengakalinya serta mengapa. Jalan pintas yang ditempuh sebuah tim memberi tahu kami di mana rancangannya perlu diubah sebelum memberi tahu kami di mana kontrol perlu diperketat.

Lalu kami mengubah matriks itu menjadi tabel yang ditegakkan sistem: batas yang ditetapkan pemilik, jenis pembelian, delegasi dan eskalasi, serta jalur mendesak dengan tenggatnya, dengan persetujuan yang sampai ke ponsel pemberi persetujuan dan tercatat pada permintaan itu sendiri. Kami merancangnya agar pemilik dapat mengubah batas ketika struktur berubah, tanpa membutuhkan programmer. Ini bagian dari sistem khusus yang kami bangun, yang dijelaskan dalam layanan kami.

Latihan untuk minggu ini: gambar matriks Anda di satu halaman

Sebelum sistem apa pun, tuliskan matriks yang digunakan perusahaan Anda saat ini, meskipun belum pernah dituliskan. Pemilik dapat melakukannya bersama manajer operasional dan manajer keuangan dalam satu atau dua pertemuan:

  • Daftarkan jenis pembelian Anda sebagai kolom: material stok, jasa dan subkontraktor, aset modal, dan pembelian mendesak. Tambahkan jenis lain jika perusahaan Anda membeli sesuatu yang tidak masuk ke salah satu dari keempatnya.
  • Letakkan tingkat jumlah di baris pada batas yang Anda anggap tepat untuk perusahaan Anda, dan di setiap sel tuliskan peran yang menyetujui, bukan nama orang.
  • Tunjuk penerima delegasi untuk setiap pemberi persetujuan yang akan menyetujui ketika ia tidak ada, dan tetapkan tenggat yang setelahnya sebuah permintaan dieskalasi ke tingkat berikutnya.
  • Definisikan mendesak secara tertulis, dan putuskan siapa yang dapat memicunya, batas pengeluarannya, dan tenggat untuk melengkapi persetujuannya.
  • Kembali ke sepuluh faktur dari latihan bagian pertama, dan tanyakan tentang masing-masing: jika matriks ini berlaku, siapa yang akan menyetujuinya? Dan apakah orang itu benar-benar menyetujuinya?

Kesenjangan antara halaman itu dan kenyataan pada pertanyaan terakhir itulah yang harus ditutup oleh sistem. Jika Anda menemukan kesenjangan, periksa dulu apakah pemberi persetujuan memang tidak tersedia pada saat itu, karena jika demikian, solusinya adalah delegasi yang jelas, bukan kontrol yang lebih ketat.

Di bagian berikutnya

Kebutuhan kini memiliki permintaan bernomor, dan keputusan memiliki persetujuan yang pemiliknya diketahui. Bagian berikutnya beralih ke dua tahap selanjutnya: pemasok dan penawaran, lalu pesanan pembelian. Kita mulai dengan catatan pemasok yang dimasukkan sekali dan diperiksa ketika pemasok ditambahkan, lalu membandingkan penawaran dengan satu dasar yang sama, kemudian mengubah penawaran yang dipilih menjadi pesanan pembelian yang memuat harga, jumlah, dan ketentuan serta terhubung kembali ke permintaannya, sehingga menjadi komitmen yang dapat dilihat pemilik sebelum faktur apa pun tiba.

Sumber