Sistem permintaan pembelian internal: hindari hambatan

Mengapa permintaan pembelian tersendat

Sebagian besar keterlambatan pembelian dimulai sebelum seseorang menyetujui atau menolak permintaan. Karyawan meminta laptop melalui email, mengirim harga lewat chat, lalu menambahkan baris spreadsheet untuk bagian keuangan. Setiap tempat hanya menyimpan sebagian informasi. Pembeli kemudian harus menggabungkan pemasok, biaya, alasan bisnis, pemilik anggaran, dan tenggat waktu.

Akibatnya, pekerjaan menjadi berulang. Manajer meminta detail yang sudah dikirim karyawan kepada keuangan. Keuangan memeriksa anggaran, tetapi tidak tahu apakah kepala departemen sudah menyetujui kebutuhannya. Karyawan juga tidak tahu posisi permintaan atau siapa yang harus bertindak berikutnya.

Detail yang hilang menyebabkan keterlambatan

Alur persetujuan pembelian melambat ketika permintaan tidak memuat informasi yang dibutuhkan setiap pihak. Kekurangan yang umum antara lain:

• Tidak ada deskripsi barang, jumlah, atau penawaran pemasok
• Tidak ada departemen, pusat biaya, atau nilai anggaran
• Tidak ada alasan bisnis atau tanggal kebutuhan
• Tidak ada pemilik persetujuan atau pembelian yang jelas
• Tidak ada catatan komentar, perubahan, atau keputusan sebelumnya

Satu informasi yang hilang saja dapat mengembalikan permintaan ke awal. Seorang pimpinan tim mungkin menyetujui perpanjangan perangkat lunak senilai $1.200, lalu bagian keuangan mengetahui bahwa tidak ada yang mencantumkan anggarannya. Alih-alih menempatkan pesanan, tim menghabiskan beberapa hari untuk mencari pemilik pengeluaran tersebut.

Satu catatan dan kepemilikan yang jelas

Sistem permintaan pembelian internal menyimpan seluruh permintaan dalam satu tempat, sejak pengajuan hingga serah terima pesanan pembelian. Pemohon memasukkan kebutuhan satu kali. Manajer, staf keuangan, dan pembeli melihat detail yang sama, menambahkan komentar pada catatan yang sama, serta meninggalkan riwayat keputusan yang dapat dilihat.

Label status yang jelas mengurangi pertanyaan lanjutan. Permintaan dapat menunjukkan apakah masih membutuhkan pemeriksaan anggaran, persetujuan manajer, tindakan pembeli, atau detail pemasok. Setiap tahap memerlukan orang atau peran yang ditunjuk, serta aturan pengganti ketika seseorang tidak hadir.

Aplikasi pengadaan tanpa kode membuat proses ini dapat diterapkan tanpa memaksa tim operasional mengelola banyak formulir dan spreadsheet. AppMaster dapat mendukung formulir permintaan, kolom anggaran, logika persetujuan, dan antrean pembeli dalam satu aplikasi. Setiap permintaan harus memiliki satu tempat penyimpanan, penanggung jawab saat ini, dan detail yang cukup untuk bergerak menuju pemesanan.

Tentukan isi setiap permintaan

Formulir permintaan harus memberi manajer dan pembeli informasi yang cukup untuk mengambil keputusan dengan cepat. Jika karyawan harus menjelaskan fakta dasar melalui pesan lanjutan, formulirnya terlalu sederhana. Jika formulir meminta detail keuangan yang tidak mungkin diketahui karyawan, mereka akan menebak atau menyerah.

Setiap permintaan membutuhkan nama barang, jumlah, pemasok, perkiraan harga satuan, total biaya, dan alasan bisnis. Tambahkan departemen, pusat biaya, pemohon, dan tanggal kebutuhan jika informasi tersebut memengaruhi anggaran atau pengiriman. Setelah karyawan masuk, sistem dapat mengisi nama dan departemen mereka secara otomatis.

Alasan singkat lebih berguna daripada kotak teks kosong yang besar. Contohnya: «Lima akun tambahan untuk staf dukungan pelanggan pada shift malam yang baru.» Contoh ini memberi penyetuju alasan praktis, jumlah, dan kaitan dengan pekerjaan saat ini.

Gunakan dua jenis permintaan

Pembelian katalog dan pembelian satu kali memerlukan formulir yang berbeda. Barang katalog sudah memiliki deskripsi, pemasok, harga, dan terkadang referensi kontrak yang disetujui. Karyawan dapat memilih barang, memasukkan jumlah, dan menjelaskan kebutuhannya. Dengan begitu, permintaan umum tetap konsisten.

Pembelian satu kali memerlukan konteks yang lebih lengkap karena tim pembelian harus menilainya sebelum memesan. Minta deskripsi barang atau layanan, pemasok pilihan dan kontak jika diketahui, penawaran atau perkiraan biaya, jumlah dan frekuensi penagihan, alasan bisnis, serta tanggal kebutuhan.

Jangan memaksa karyawan mencari pemasok sebelum dapat mengajukan permintaan. Mereka mungkin tahu bahwa mereka membutuhkan meja berdiri, tetapi belum tahu vendor mana yang memenuhi aturan perusahaan. Tim pembelian dapat melengkapi bagian itu nanti.

Pastikan setiap kolom wajib memang diperlukan

Wajibkan sebuah kolom hanya jika seseorang memerlukannya untuk menyetujui, menganggarkan, atau membeli permintaan. Barang, jumlah, perkiraan biaya, pusat biaya, dan alasan biasanya termasuk di dalamnya. Lampiran sebaiknya hanya wajib di atas batas pengeluaran tertentu atau untuk kategori seperti langganan perangkat lunak.

Kolom bersyarat membuat formulir lebih mudah digunakan. Permintaan perangkat lunak dapat menanyakan jumlah pengguna, tanggal perpanjangan, dan apakah layanan akan menangani data pelanggan. Barang fisik dapat menanyakan alamat pengiriman. Setiap alur persetujuan pembelian memperoleh fakta yang dibutuhkan tanpa memaksa semua karyawan mengisi formulir panjang.

Sebelum diluncurkan, kirim tiga permintaan uji coba: barang katalog, pembelian dari pemasok baru, dan layanan berulang. Jika penyetuju masih menanyakan hal yang seharusnya sudah jelas, tambahkan kolom atau perjelas kolom yang ada.

Buat katalog yang mempercepat permintaan

Katalog menghilangkan pekerjaan berulang. Daripada meminta setiap karyawan menjelaskan laptop, lisensi perangkat lunak, atau kursi kantor dari awal, berikan daftar pilihan yang sudah disetujui.

Setiap barang katalog harus memiliki deskripsi sederhana, harga satuan yang umum, dan pemasok pilihan. Tambahkan detail yang dapat mencegah pesan lanjutan, seperti kode barang, masa kontrak, ukuran yang tersedia, atau kebutuhan konfirmasi manajer.

Sebagai contoh, entri «Laptop standar» dapat mencantumkan model, pemasok yang disetujui, harga $1.200, dan garansi tiga tahun. Pemohon memilih jumlah dan menjelaskan siapa yang akan menggunakannya. Tim pengadaan menerima informasi berguna yang sama setiap kali.

Buat pilihan tetap sederhana

Jangan ubah katalog menjadi salinan semua situs web pemasok. Mulailah dari barang yang paling sering dipesan karyawan, lalu tambahkan entri ketika permintaan isian bebas yang sama muncul berulang kali. Katalog yang panjang dan tidak teratur justru menciptakan keterlambatan baru.

Kelompokkan barang ke dalam kategori yang mudah dikenali, seperti perangkat lunak, peralatan, perlengkapan kantor, dan layanan profesional. Gunakan pencarian dan nama singkat agar orang dapat menemukan barang sebelum mulai mengetik deskripsi.

Entri katalog biasanya memerlukan nama barang, deskripsi, harga satuan atau kisaran yang diharapkan, pemasok pilihan, unit penagihan, dan batasan apa pun. Misalnya, langganan dapat menampilkan «per pengguna, per bulan» dan menyatakan bahwa persetujuan manajer diperlukan.

Sediakan ruang untuk pengecualian

Karyawan terkadang membutuhkan barang yang belum terdaftar. Pertahankan opsi isian bebas, tetapi minta informasi yang cukup untuk memungkinkan langkah berikutnya: kebutuhan, perkiraan biaya, pemasok jika diketahui, dan alasan bisnis.

Anggap permintaan isian bebas sebagai antrean peninjauan, bukan kegagalan katalog. Tim pengadaan dapat membandingkan penawaran, menyetujui pemasok, atau menambahkan barang tersebut ke katalog untuk permintaan berikutnya.

Dalam aplikasi pengadaan tanpa kode yang dibuat dengan AppMaster, pemilihan barang katalog dapat mengisi harga, pemasok, dan kolom permintaan secara otomatis. Data yang lebih bersih membantu proses persetujuan anggaran dan mengurangi pekerjaan koreksi sebelum serah terima pesanan pembelian.

Tambahkan pemeriksaan anggaran sebelum persetujuan

Permintaan harus menunjukkan konteks keuangannya sebelum tugas persetujuan dimulai. Minta pemohon memilih departemen dan pusat biaya, lalu catat jumlah dan mata uangnya. Sistem dapat menggunakan kolom tersebut untuk menemukan anggaran yang sesuai.

Buat pemeriksaan ini sederhana bagi pemohon. Mereka harus dapat melihat total permintaan, anggaran yang tersedia, dan sisa anggaran setelah persetujuan. Pesan seperti «Permintaan ini melebihi sisa anggaran sebesar $420» mencegah manajer menemukan masalah tersebut belakangan di rangkaian email.

Bagian keuangan harus memiliki kendali atas angka anggaran. Staf dapat memperbarui jumlah yang disetujui untuk setiap departemen atau pusat biaya pada awal periode dan mengubahnya ketika rencana berubah. Sistem juga harus melacak permintaan yang sudah disetujui tetapi belum menjadi faktur. Jika tidak, sebuah tim dapat tampak masih memiliki dana padahal dana tersebut sudah terikat.

Periksa total permintaan secara menyeluruh

Hitung jumlah yang benar-benar akan dibayar tim pembelian. Sertakan jumlah, harga satuan, pajak, pengiriman, biaya penyiapan, dan biaya berulang jika berlaku. Langganan perangkat lunak seharga $900 dengan biaya penerapan $150 berarti total permintaannya $1.050.

Jalankan proses persetujuan anggaran saat pemohon mengirim formulir, sebelum sistem mengirimkannya kepada penyetuju. Dengan begitu, waktu peninjauan tidak terbuang dan pemohon dapat memperbaiki pusat biaya, mengurangi pesanan, atau menjelaskan pengecualian.

Dalam aplikasi pengadaan tanpa kode, ini dapat dibuat sebagai aturan visual: baca pusat biaya yang dipilih, bandingkan total permintaan dengan sisa anggaran, lalu simpan hasilnya pada permintaan. AppMaster dapat memodelkan data permintaan, membuat logika di Business Process Editor, dan menampilkan hasilnya dalam formulir internal.

Tentukan jalur untuk permintaan yang melebihi anggaran

Jangan biarkan permintaan yang melebihi anggaran berada dalam status yang tidak jelas. Berikan jalur yang sesuai dengan kebijakan pengeluaran. Anda dapat mengembalikannya kepada pemohon dengan selisih yang ditampilkan, mengirimkannya kepada pemilik anggaran untuk pengecualian, meneruskan kebutuhan mendesak kepada keuangan, atau menahannya hingga periode anggaran berikutnya dengan tanggal dan alasan yang jelas.

Catat hasil pemeriksaan anggaran dan keputusan pengecualian. Saat tim pembelian memulai pesanan, staf dapat melihat apakah pengeluaran sesuai dengan anggaran awal dan siapa yang menyetujui jumlah tambahan. Keuangan juga dapat menjelaskan alasan pusat biaya melebihi rencana.

Tetapkan jalur persetujuan yang mudah diikuti

Sistem permintaan pembelian internal memerlukan aturan rute sebelum seseorang mengirim permintaan. Kirim setiap permintaan kepada orang yang dapat menilai pengeluaran tersebut, bukan ke kotak masuk umum yang hanya sesekali diperiksa.

Dasarkan rute pada informasi yang sudah dikumpulkan di formulir. Departemen, pusat biaya, kategori pembelian, dan total nilai biasanya sudah cukup. Permintaan perlengkapan kantor senilai $40 mungkin hanya memerlukan persetujuan manajer tim. Kontrak perangkat lunak baru dapat memerlukan pemilik anggaran, IT, keamanan, dan pengadaan.

Buat rute tetap singkat jika risikonya rendah. Menambahkan penyetuju «untuk berjaga-jaga» mengubah alur persetujuan pembelian sederhana menjadi rangkaian keterlambatan. Setiap penyetuju harus memiliki alasan yang jelas untuk menyetujui, menolak, atau meminta informasi tambahan.

Gunakan aturan yang dapat diprediksi

Karyawan harus tahu ke mana permintaan mereka akan dikirim sebelum mengajukannya. Aturan yang konsisten juga mengurangi perselisihan ketika permintaan tertahan.

Contoh aturan yang dapat digunakan perusahaan:

• Permintaan di bawah $500 dikirim kepada manajer departemen.
• Permintaan $500 hingga $5.000 dikirim kepada manajer dan pemilik pusat biaya.
• Permintaan perangkat lunak dan layanan cloud juga dikirim kepada IT atau keamanan.
• Permintaan di atas $5.000 dikirim kepada pengadaan setelah persetujuan anggaran.
• Pembelian aset dikirim kepada pemilik keuangan tanpa memandang nilainya.

Aturan tidak harus sama persis di setiap departemen. Tim penjualan mungkin memerlukan persetujuan untuk alat yang berhubungan dengan pelanggan, sedangkan operasional mungkin memerlukan pemeriksaan peralatan tambahan. Gunakan logika dasar yang sama di seluruh perusahaan agar staf tidak perlu mempelajari ulang proses setiap kali.

Rencanakan ketidakhadiran dan jaga catatan tetap lengkap

Setiap penyetuju membutuhkan pengganti. Jika manajer sedang cuti, sistem harus mengirim permintaan baru kepada pengganti yang telah ditentukan atau memungkinkan administrator mengalihkan pekerjaan yang tertunda. Pemohon tidak seharusnya mengejar seseorang melalui email atau chat.

Tetapkan target respons. Misalnya, beri tahu penyetuju setelah dua hari kerja dan kirim permintaan kepada pengganti setelah lima hari. Eskalasi harus menggerakkan permintaan ke depan sambil mempertahankan rute awal dan riwayat keputusan.

Simpan setiap keputusan pada catatan permintaan. Tampilkan siapa yang menyetujui atau menolak, kapan tindakan dilakukan, dan komentarnya. Penolakan seperti «Gunakan lisensi tim yang ada sampai masa perpanjangan» memberi pemohon langkah berikutnya dan memberi konteks kepada pengadaan.

AppMaster memungkinkan tim memodelkan kolom permintaan, membuat logika persetujuan dalam proses bisnis visual, dan menunjukkan status terkini kepada pemohon. Kepemilikan tetap terlihat dan tidak hilang di antara rangkaian email.

Bangun alur permintaan langkah demi langkah

Alur yang jelas mencegah pembelian sederhana menghilang di email. Setiap status harus menjelaskan keadaan saat ini, dan setiap orang harus tahu kapan mereka perlu bertindak.

Mulailah dengan sejumlah kecil status: Draf, Dikirim, Disetujui, Ditolak, Dipesan, dan Diterima. Hindari label yang hampir sama, seperti «sedang ditinjau» dan «menunggu persetujuan». Orang akan menggunakannya secara tidak konsisten dan pelaporan akan terganggu.

Permintaan dimulai sebagai draf. Pemohon dapat menyimpannya, mengubah barang atau jumlah, atau menghapusnya. Sistem tidak boleh mengirim notifikasi atau mencadangkan anggaran pada tahap ini.

Saat pemohon mengirim formulir, status berubah menjadi Dikirim. Kunci harga, detail pemasok, dan jumlah yang diminta kecuali permintaan dikembalikan untuk diperbaiki. Penyetuju dapat menyetujui, menolak, atau mengembalikannya dengan komentar singkat.

Setelah disetujui, serahkan permintaan kepada tim pembelian. Staf hanya boleh menandainya sebagai Dipesan setelah membuat atau menempatkan pesanan pembelian. Izin untuk membelanjakan dana bukan bukti bahwa barang sudah dibeli.

Saat barang tiba, akses layanan dimulai, atau langganan dikonfirmasi, penerima menandai permintaan sebagai Diterima. Dengan begitu, keuangan dan pemohon memiliki catatan yang dapat diandalkan tentang apa yang sudah diterima.

Berikan tindakan yang jelas untuk setiap peran

Sistem permintaan pembelian internal bekerja paling baik ketika setiap perubahan status memiliki pemilik.

• Pemohon membuat draf, mengirim permintaan, dan memperbaiki permintaan yang dikembalikan.
• Manajer dan pemilik anggaran menyetujui, menolak, atau mengembalikan permintaan dengan alasan.
• Staf pembelian mencatat informasi pemasok, detail pesanan pembelian, dan status pemesanan.
• Penerima mengonfirmasi pengiriman dan menandai permintaan sebagai diterima.
• Staf keuangan melihat riwayat lengkap dan memperbaiki kolom terbatas, seperti referensi akuntansi.

Administrator harus menangani pengecualian, seperti penyetuju yang meninggalkan perusahaan atau permintaan duplikat. Simpan jejak audit untuk setiap perubahan status, termasuk siapa yang melakukannya, kapan, dan komentarnya.

Beri tahu orang ketika mereka harus bertindak

Kirim notifikasi ketika permintaan yang dikirim mencapai penyetuju. Sertakan judul permintaan, jumlah, departemen, dan keputusan yang diperlukan. Pesan samar seperti «Anda memiliki tugas baru» memperlambat tindakan karena orang harus mencari konteksnya.

Beri tahu pemohon ketika seseorang menyetujui, menolak, atau mengembalikan permintaan. Wajibkan komentar untuk penolakan atau pengembalian. «Anggaran tidak tersedia pada kuartal ini» memberi arahan, sedangkan «Tidak» tidak.

Tim pembelian harus menerima pemberitahuan setelah persetujuan akhir. Pemohon harus menerima pembaruan ketika tim pembelian menandai permintaan sebagai Dipesan dan Diterima. Jika tidak ada tindakan setelah jangka waktu tertentu, ingatkan pemilik saat ini dan salin penyetuju pengganti.

Dengan AppMaster, aplikasi pengadaan tanpa kode dapat memodelkan status di Data Designer dan menerapkan perubahan yang diizinkan di Business Process Editor. Setiap serah terima tetap berada pada catatan dan tidak bergantung pada ingatan seseorang.

Contoh: permintaan langganan perangkat lunak

Maya, seorang manajer pemasaran, membutuhkan 15 langganan alat perencanaan media sosial. Ia membuka sistem permintaan pembelian internal dan memilih alat tersebut dari katalog perangkat lunak, bukan membuat permintaan isian bebas.

Entri katalog berisi pemasok, jenis paket, harga per pengguna, siklus penagihan, dan tim pemilik kontrak. Maya memasukkan 15 kursi, memilih pusat biaya Marketing, dan menambahkan alasan: tim membutuhkan penjadwalan bersama serta persetujuan untuk unggahan kampanye.

Aplikasi menghitung biaya tahunan sebelum ia mengirim permintaan. Anggaran perangkat lunak Marketing mencukupi sehingga permintaan lolos pemeriksaan anggaran. Jika anggaran kurang, aplikasi dapat menghentikan permintaan dan meminta Maya memilih pusat biaya lain atau mengajukan dana tambahan. Ini mencegah manajer menyetujui pembelian yang tidak dapat dibayar keuangan.

Kepala departemen Maya menerima permintaan karena nilainya masih berada dalam batas pengeluaran manajer. Layar persetujuan menampilkan biaya, jumlah pengguna, alasan bisnis, dan saldo anggaran. Manajer menyetujuinya.

Tim pembelian menerima catatan lengkap yang berisi pemasok dan paket, total tahunan dan tanggal perpanjangan, pusat biaya dan hasil anggaran, alasan Maya, serta waktu persetujuan manajer. Koordinator pembelian memeriksa apakah perusahaan sudah memiliki perjanjian dengan pemasok tersebut. Jika ada, ia membuat pesanan pembelian dari detail yang tersimpan. Jika tidak, ia memulai peninjauan pemasok sebelum menempatkan pesanan.

Koordinator mencatat nomor pesanan pembelian dan menandai permintaan sebagai Dipesan. Maya dapat melihat pembaruan tanpa menanyakan status kepada tim pembelian. Saat pemasok mengonfirmasi 15 lisensi, koordinator menandai permintaan sebagai Diterima dan mencatat siapa yang akan mengelola akun.

Alur ini menjaga setiap keputusan tetap melekat pada permintaan. Keuangan dapat melihat alasan tim membeli perangkat lunak, anggaran yang digunakan, dan siapa yang menyetujui pengeluaran tersebut.

Kesalahan yang memperlambat pembelian

Proses pembelian dapat terlihat sederhana di diagram, tetapi tetap membuat pengguna frustrasi. Masalah biasanya muncul ketika sistem memperlakukan setiap permintaan sebagai kasus khusus atau kehilangan kendali atas perubahan setelah persetujuan.

Mengirim semua permintaan kepada pimpinan

Banyak tim mengirim setiap permintaan kepada satu manajer senior. Orang itu akhirnya menjadi antrean untuk barang rutin seperti penggantian keyboard, perpanjangan perangkat lunak bulanan, atau perlengkapan di bawah batas pengeluaran kecil. Jika manajer tidak hadir selama dua hari, semua orang menunggu.

Sesuaikan jalur persetujuan dengan biaya, departemen, dan jenis permintaan. Pimpinan tim dapat menyetujui barang katalog standar di bawah batas tertentu. Pemilik departemen dapat meninjau pembelian yang lebih besar. Keuangan dapat ikut meninjau ketika permintaan memengaruhi anggaran atau melewati batas. Pimpinan senior sebaiknya menerima pengecualian, bukan permintaan biasa.

Membiarkan perubahan pada permintaan yang disetujui

Persetujuan akhir berlaku untuk barang, jumlah, pemasok, dan harga tertentu. Jika detail tersebut berubah kemudian, persetujuan mungkin tidak lagi sesuai dengan pengeluaran.

Tetapkan aturan untuk perubahan penting. Perubahan dari 10 menjadi 12 lisensi, atau dari $500 menjadi $1.200, harus mengembalikan permintaan kepada peninjau yang relevan. Catatan kecil, seperti kontak pengiriman, dapat tetap diedit tanpa memulai ulang alur persetujuan pembelian.

Aplikasi pengadaan tanpa kode dapat menyimpan riwayat perubahan dan membuka kembali persetujuan ketika kolom yang dikendalikan berubah. Ini mencegah kejutan saat keuangan membandingkan jumlah yang disetujui dengan faktur.

Menutup permintaan terlalu cepat

Persetujuan bukan akhir dari proses pembelian. Tim pembelian masih perlu mencatat pemasok, nomor pesanan pembelian, harga akhir, tanggal pemesanan, dan status pengiriman. Jika seseorang menutup permintaan sebelum detail tersebut tersedia, staf harus mencari email dan spreadsheet di kemudian hari.

Gunakan status yang jelas seperti Disetujui, Dipesan, Diterima, dan Ditutup. Pindahkan permintaan ke Ditutup hanya setelah tim pembelian mencatat detail pesanan dan memastikan serah terima. Langganan tahunan yang disetujui harus tetap berstatus Disetujui sampai pembeli mencatat pesanan vendor atau referensi perpanjangannya.

Pembedaan ini membuat laporan lebih dapat diandalkan. Tim dapat melihat permintaan yang disetujui tetapi masih memerlukan tindakan, pesanan yang menunggu pengiriman, dan pembelian yang sudah selesai.

Pemeriksaan singkat sebelum diluncurkan

Uji coba singkat dapat menemukan sebagian besar masalah sebelum karyawan bergantung pada sistem permintaan pembelian internal. Minta kelompok kecil mengirim permintaan yang realistis, seperti perlengkapan kantor, perpanjangan perangkat lunak, dan kontrak layanan. Sertakan pemohon, penyetuju, dan staf yang membuat pesanan pembelian.

Setiap permintaan memerlukan satu penanggung jawab yang jelas dan status yang terlihat. Penanggung jawab harus berubah ketika tanggung jawab berpindah dari pemohon kepada manajer atau pembeli. Label status harus menjelaskan apa yang terjadi, seperti Draf, Dikirim, Disetujui, Ditolak, atau Diserahkan kepada pembelian.

Sebelum membuka aplikasi untuk semua orang, pastikan setiap permintaan menampilkan pemilik, status saat ini, jumlah, dan penyetuju berikutnya. Bandingkan aturan persetujuan dengan batas pengeluaran dan aturan departemen yang sebenarnya. Periksa apakah tim pembelian dapat melihat pemasok, harga penawaran, jumlah yang disetujui, dan tanggal kebutuhan.

Uji permintaan yang melebihi anggaran dan pastikan aplikasi menghentikannya atau mengirimkannya kepada orang yang tepat. Tolak permintaan lain dengan alasan yang jelas, lalu pastikan pemohon menerima alasan tersebut dan dapat memperbarui formulir.

Gunakan angka nyata untuk pengujian anggaran. Berikan sebuah tim sisa anggaran bulanan sebesar $2.000, lalu kirim permintaan senilai $2.400. Tentukan apakah sistem harus memblokirnya, meminta persetujuan keuangan, atau memungkinkan pemilik anggaran memindahkan dana. Semua pihak harus melihat hasil yang sama.

Uji juga perubahan setelah persetujuan. Pemohon mungkin menaikkan pesanan dari 10 monitor menjadi 15, atau pemasok mungkin menaikkan harga penawaran. Alur persetujuan pembelian harus mengirim permintaan untuk disetujui kembali atau menjelaskan perubahan mana yang tidak memerlukan peninjauan ulang. Perubahan diam-diam akan menimbulkan perselisihan.

Terakhir, uji serah terima pesanan pembelian. Tim pembelian harus menerima detail yang disetujui di satu tempat, bukan mengetiknya ulang dari email atau chat. Di AppMaster, tim dapat menguji jalur ini dengan catatan contoh dan menyesuaikan aturan visual sebelum menerbitkan aplikasi. Simpan catatan singkat tentang pengujian yang gagal, perbaiki aturan di balik setiap masalah, lalu jalankan pengujian lagi.

Tentukan langkah berikutnya

Mulailah dari satu departemen yang memiliki pembelian berulang dan rantai persetujuan yang mudah dikelola. Perangkat lunak IT, perlengkapan kantor, atau langganan pemasaran merupakan titik awal yang praktis. Berikan kelompok tersebut katalog singkat berisi barang umum, perkiraan harga, dan informasi yang dibutuhkan tim pembelian.

Jaga versi pertama tetap terfokus. Pemohon harus dapat mengirim kebutuhan yang jelas, penyetuju harus melihat biaya dan status anggaran, dan tim pembelian harus menerima permintaan lengkap setelah persetujuan. Tambahkan jenis permintaan yang tidak biasa setelah jalur dasar berjalan dengan baik.

Mintalah masukan dari orang-orang yang menggunakan setiap bagian sistem setelah beberapa minggu pertama. Pemohon dapat menemukan kolom yang membingungkan. Penyetuju dapat menjelaskan konteks tambahan yang mereka perlukan. Staf pembelian dapat menunjukkan detail pemasok yang hilang atau permintaan yang masih datang di luar aplikasi.

Gunakan masukan tersebut untuk menghapus kolom yang tidak digunakan, menambahkan entri katalog untuk pembelian berulang, memperjelas batas persetujuan, menampilkan orang yang bertanggung jawab berikutnya, serta mencatat alasan pengembalian atau penolakan permintaan.

AppMaster dapat membantu tim membuat aplikasi pengadaan tanpa kode tanpa memulai dari proyek teknis kosong. Tim dapat membuat formulir permintaan karyawan, memakai Business Process Editor untuk pemeriksaan anggaran dan jalur persetujuan, serta membuat layar terpisah untuk manajer dan staf pembelian. Data Designer dapat menyimpan barang katalog, departemen, pemasok, anggaran, dan permintaan di satu tempat.

Uji coba kecil dapat memperlihatkan masalah praktis dengan cepat. Jika karyawan masih mengirim permintaan lewat email, cari tahu alasannya sebelum menambahkan aturan baru. Bangun jalur permintaan yang dipilih orang karena lebih jelas dan cepat daripada cara lama. Setelah uji coba berjalan lancar, sesuaikan strukturnya untuk departemen berikutnya sambil menjaga katalog dan aturan persetujuannya tetap sesuai dengan cara departemen tersebut membelanjakan dana.