Suasana Workshop Digitalisasi Pengumpulan dan Review Soal Ujian Menggunakan AppSheet yang diselenggarakan Departemen Bahasa, Seni, dan Manajemen Budaya Sekolah Vokasi UGM, Senin (31/8/2026), di Meeting Room DBSMB Lantai 1.

Alhamdulillah pada hari Senin, 31 Agustus 2026, saya mendapat kesempatan berbagi dalam Workshop Sistem Akademik DBSMB SV dengan topik Digitalisasi Pengumpulan & Review Soal Ujian Menggunakan AppSheet. Workshop berlangsung pukul 08.00–12.30 WIB dan membahas workflow mulai dari dosen mengunggah soal, proses administrasi akademik, review, sampai soal dinyatakan siap dicetak.

Bagi saya, bagian paling menarik dari workshop ini sebenarnya bukan AppSheet-nya. Teknologinya hanyalah alat. Persoalan utamanya adalah bagaimana mengubah proses yang sebelumnya sangat bergantung pada file, pesan WhatsApp, ingatan petugas, dan pengecekan manual menjadi sebuah workflow yang bisa dipantau, memiliki status yang jelas, dan meninggalkan jejak aktivitas.

Masalahnya bukan sekadar “sudah upload atau belum”

Dalam proses pengumpulan soal ujian, pertanyaan administratif cepat sekali bertambah. Siapa yang sudah mengumpulkan? Mata kuliah dan kelas apa? File mana yang merupakan versi terakhir? Sudah direview atau belum? Kalau perlu revisi, siapa yang harus menindaklanjuti? Siapa yang melakukan review? Kapan status berubah menjadi siap dicetak?

Jika semuanya ditangani melalui email, WhatsApp, dan folder penyimpanan biasa, informasi itu mudah tersebar. Materi workshop memang dimulai dari persoalan tersebut: file tersebar, status pengumpulan sulit diketahui, review tidak terdokumentasi dengan baik, akses terhadap soal perlu dibatasi, dan reminder sering masih dilakukan secara manual. Karena itu saya mencoba menggeser cara pandangnya.

Bukan:

“Bagaimana membuat form upload soal?”

Tetapi:

“Bagaimana mengelola perjalanan sebuah soal dari dikirim dosen sampai siap digunakan dalam ujian?”

Perubahan pertanyaan ini ternyata cukup menentukan desain sistem.

Satu database, tetapi dua aplikasi

Salah satu pola yang saya perkenalkan dalam workshop adalah penggunaan dua aplikasi AppSheet yang menggunakan database yang sama. Aplikasi pertama digunakan oleh dosen untuk mengunggah soal, melihat daftar soal miliknya, memantau status, serta melihat metadata pengumpulan. Aplikasi kedua digunakan untuk administrasi dan review. Aksesnya dibatasi kepada pihak yang memang diberi kewenangan, yaitu Admin Program Studi, Ketua Tim Reviewer atau Manajer Jaminan Mutu, Ketua Program Studi, serta Koordinator Mata Kuliah yang ditunjuk. Dengan pola seperti ini, tampilan dan fungsi aplikasi dapat disesuaikan dengan pekerjaan masing-masing pengguna tanpa harus membuat database terpisah.

Bagi saya, prinsip desainnya sederhana:

Satu sumber data, beberapa pintu masuk, kewenangan berbeda.

Transparan pada proses, rahasia pada isi

Contoh Tampilan menu yang menganut prinsip “Transparan pada proses, Rahasia pada Isi”

Ada tantangan menarik ketika membangun aplikasi soal ujian. Di satu sisi, transparansi diperlukan. Dosen sebaiknya dapat mengetahui apakah mata kuliah tertentu sudah mengumpulkan soal dan sampai di tahap mana prosesnya. Di sisi lain, isi soal tentu tidak boleh terbuka kepada semua pengguna.

Karena itu aplikasi dosen dirancang sehingga pengguna dapat melihat metadata seperti mata kuliah, kelas, dosen, status, dan waktu pengiriman, tetapi tidak dapat membuka atau mengunduh file soal milik dosen lain. Konsep ini saya rangkum dalam workshop dengan kalimat:

Transparan pada proses, rahasia pada isi.

Prinsip tersebut juga menjadi salah satu pokok desain aplikasi dosen yang dibahas dalam materi. Menurut saya, ini salah satu pelajaran penting ketika membuat aplikasi internal. Jangan menyamakan “informasi proses” dengan “isi dokumen”. Keduanya bisa memiliki tingkat akses yang berbeda.

Satu kali Save, workflow mulai bergerak

Contoh Tampilan Form Soal Saya

Form pengumpulan soal sendiri terlihat sederhana. Dosen memilih mata kuliah, kelas, dosen pengampu, mengunggah file, menentukan sifat ujian dan durasi, kemudian menyimpan. Namun di belakang form sederhana tersebut, kita bisa membuat banyak proses berjalan.

Email pengirim dapat diambil otomatis melalui:

USEREMAIL()
Waktu dapat dicatat dengan:
NOW()
Status awal dapat langsung diberikan:
"Sudah Dikirim, Belum di-review"
Dalam materi workshop, form upload memang dirancang sebagai titik awal workflow, bukan sekadar tempat memasukkan file. Setelah tombol Save ditekan, data tersimpan, status berubah, dashboard ikut diperbarui, dan automation dapat mulai bekerja. Inilah bagian yang menurut saya membuat no-code menjadi menarik. Satu aksi sederhana di layar pengguna dapat menggerakkan beberapa proses administratif sekaligus.

Reviewer tidak hanya menekan tombol “Approve”

Bagian lain yang saya anggap penting adalah desain proses review. Reviewer tidak hanya diberi pilihan menerima atau menolak soal. Di dalam aplikasi tersedia instrumen review, antara lain untuk memeriksa kesesuaian dengan CPMK, pembobotan soal, kejelasan petunjuk pengerjaan, penggunaan bahasa yang baku, serta kesesuaian soal dengan materi pembelajaran. Dari hasil tersebut, status dapat bergerak menuju:

Perlu Revisi

atau:

Siap Dicetak

Dengan begitu aplikasi tidak hanya menjadi tempat pengumpulan dokumen. Ia juga menjadi bagian dari proses quality assurance. Ini menurut saya jauh lebih bernilai daripada sekadar mengganti Google Form dengan AppSheet. WhatsApp menjadi bagian dari workflow

Dalam implementasinya, notifikasi juga menjadi elemen penting. Ketika dosen mengunggah soal, informasi dapat diteruskan ke beberapa grup WhatsApp dengan tujuan berbeda. Ada grup yang beranggotakan dosen aktif untuk transparansi pengumpulan dan reminder, grup Petugas Akademik/Admin Prodi untuk monitoring administratif, serta grup Reviewer untuk memicu proses pemeriksaan soal. Materi workshop juga membedakan fungsi ketiga kanal tersebut. Secara konseptual alurnya menjadi:

AppSheet → Automation → Webhook/API → WhatsApp

Hal yang menurut saya penting adalah jangan menjadikan notifikasi sekadar “bunyi tambahan”. Notifikasi sebaiknya muncul ketika memang ada sesuatu yang harus dilakukan.

Contoh Notifikasi di Grup Notifikasi Akademik

Ada soal masuk → reviewer mendapat informasi.

Reviewer selesai memeriksa → petugas akademik mendapat informasi.

Status berubah → pengguna yang berkepentingan mendapat informasi.

Dengan begitu WhatsApp tidak berdiri di luar sistem, tetapi menjadi salah satu kanal respons terhadap event di dalam sistem.

Audit trail: bagian yang sering terlupakan

Setelah workshop, saya juga lupa menginfokan desain bagian activity logging.

Setiap perubahan pada data pengumpulan soal idealnya meninggalkan jejak:

Waktu
User
Aktivitas
Data sebelum
Data sesudah

Untuk penambahan data, log mencatat data yang baru dibuat. Untuk update, sistem menyimpan keadaan sebelum dan sesudah perubahan. Sedangkan ketika sebuah record dihapus, informasi record sebelum penghapusan tetap tercatat. Bagi aplikasi akademik, menurut saya bagian seperti ini penting karena suatu saat pertanyaan yang muncul bukan lagi:

“Statusnya sekarang apa?”

melainkan:

“Siapa yang mengubah status ini, kapan, dan sebelumnya datanya bagaimana?”

Di titik itulah sebuah tabel log sederhana berubah menjadi semacam kotak hitam kecil bagi aplikasi.

Yang saya pelajari dari workshop ini

Semakin sering membuat aplikasi operasional, saya semakin merasa bahwa persoalan terbesar biasanya bukan pada formula AppSheet.

Formula seperti:

USEREMAIL()
UNIQUEID()
atau:
LOOKUP()
relatif mudah dipelajari.

Yang lebih sulit adalah menentukan proses bisnis, siapa boleh melakukan apa, status apa saja yang diperlukan, apa yang harus otomatis, dan informasi mana yang boleh terlihat oleh siapa.

Karena itu dalam workshop saya menekankan agar pengembangan dimulai dari proses dan database, bukan langsung dari tampilan aplikasi. Materinya sendiri menempatkan pemetaan proses, penyusunan database, pembangunan aplikasi, pengaturan akses, automation, dan persiapan implementasi sebagai sasaran workshop. AppSheet kemudian menjadi alat untuk menerjemahkan aturan-aturan tersebut ke dalam aplikasi.

Ke mana sistem ini bisa dikembangkan?

Sistem pengumpulan soal sebenarnya baru satu pintu. Setelah workflow-nya stabil, pola yang sama dapat diperluas menjadi sistem yang lebih besar: bank soal, penjadwalan ujian, penugasan pengawas, berita acara digital, monitoring hasil ujian, hingga dashboard kesiapan pelaksanaan ujian. Roadmap dalam workshop pun diarahkan dari MVP berupa upload, monitoring, review dan status, kemudian menuju reminder, WhatsApp automation dan log, lalu integrasi dengan modul akademik lainnya.

Tetapi saya tetap menyukai prinsip:

Mulai kecil, pastikan bekerja, lalu kembangkan.

Aplikasi yang mempunyai lima fitur tetapi benar-benar digunakan jauh lebih berharga dibanding aplikasi dengan lima puluh fitur yang membuat penggunanya ingin kembali ke Excel. 😄

Penutup

Workshop ini kembali mengingatkan saya bahwa digitalisasi sebenarnya bukan perkara membuat semuanya menjadi aplikasi. Digitalisasi yang bermanfaat adalah ketika teknologi dapat membuat proses menjadi:

lebih jelas, lebih tertib, lebih mudah dilacak, lebih aman, dan mengurangi pekerjaan berulang manusia.

Pada akhirnya AppSheet, Google Sheet, webhook, maupun WhatsApp API hanyalah kepingan-kepingan Lego, yang menentukan bentuk akhirnya adalah bagaimana kita merancang proses kerjanya.

Dan untuk kasus pengumpulan soal ujian, tujuan akhirnya sebenarnya sederhana:

Dosen mudah mengirim soal, reviewer mudah melakukan pemeriksaan, petugas akademik mudah memantau, dan soal tetap aman sampai digunakan.