2.5 Organisasi sebagai Konteks
Pekerjaan pengguna tidak terjadi di ruang hampa. Ia terjadi di dalam organisasi yang punya proses, peran, aturan, dan batasan. Itulah konteks yang harus kita pahami.
Coba bayangkan Anda bekerja di rumah sakit. Seorang perawat meminta aplikasi pencatatan obat pasien yang lebih cepat. Anda sudah paham pekerjaan yang ingin diselesaikan: perawat ingin mencatat pemberian obat dalam waktu kurang dari tiga puluh detik per pasien, tanpa harus membuka tiga layar berbeda. Anda pun mulai membayangkan antarmuka yang bersih, tombol besar, dan dropdown obat yang pintar.
Tapi sebelum Anda menggambar satu pixel pun, ada pertanyaan yang harus dijawab. Siapa yang berwenang mengubah data obat? Apakah perawat boleh menandai obat sudah diberikan, atau harus ada verifikasi dari apoteker dulu? Bagaimana jika pasien alergi terhadap obat tertentu—siapa yang memasukkan data alergi itu, dan sistem mana yang menyimpannya? Apakah catatan ini harus ditandatangani secara digital? Berapa lama data harus disimpan sebelum bisa diarsipkan?
Inilah yang dimaksud dengan konteks organisasi. Solusi teknis yang sempurna secara antarmuka bisa gagal total jika tidak cocok dengan proses bisnis, peran, aturan, kepemilikan data, dan batasan operasional yang sudah berjalan.
Proses bisnis adalah urutan langkah yang sudah ditetapkan organisasi untuk menyelesaikan pekerjaan. Mungkin prosesnya mengharuskan setiap pemberian obat diverifikasi oleh dua perawat. Mungkin ada tahap pencatatan yang harus dilakukan dalam sistem tertentu karena alasan regulasi. Kalau solusi Anda melewati proses ini, solusi itu tidak akan dipakai—atau malah menimbulkan masalah baru.
Peran menentukan siapa boleh melakukan apa. Di rumah tadi, perawat boleh mencatat, tapi mungkin tidak boleh mengubah dosis. Apoteker boleh memverifikasi, tapi mungkin tidak boleh melihat data pasien di luar konteks obat. Kalau solusi yang Anda buat memberikan akses terlalu luas atau terlalu sempit, organisasi akan menolaknya.
Aturan bisa datang dari berbagai tempat: kebijakan internal, regulasi pemerintah, standar industri, atau bahkan kesepakatan dengan mitra. Aturan ini bukan penghalang yang harus diakali—ia adalah batasan yang harus dipahami dan dihormati. Solusi yang baik bekerja di dalam batasan itu, bukan melanggarnya.
Kepemilikan data adalah pertanyaan siapa yang bertanggung jawab atas kebenaran dan keamanan data. Data pasien mungkin milik unit rekam medis. Data obat milik instalasi farmasi. Data alergi bisa dimiliki oleh kedua unit sekaligus. Kalau solusi yang Anda buat menyimpan data di tempat baru tanpa koordinasi dengan pemilik data, Anda sedang menabung masalah.
Batasan operasional adalah hal-hal yang membatasi bagaimana solusi bisa berjalan: jam operasional, ketersediaan jaringan, perangkat yang dipakai, kebiasaan pengguna, atau bahkan budaya organisasi. Mungkin rumah sakit hanya punya satu shift IT support. Mungkin perangkat yang dipakai perawat adalah tablet lama dengan baterai cepat habis. Mungkin budaya organisasi tidak terbiasa dengan perubahan yang terlalu cepat.
Semua ini bukan alasan untuk tidak membuat solusi. Ini adalah informasi yang harus Anda kumpulkan sebelum merancang. Caranya? Bicara dengan orang yang menjalankan proses, bukan hanya atasannya. Baca dokumen kebijakan yang relevan. Tanyakan apa yang terjadi kalau aturan dilanggar. Amati bagaimana pekerjaan benar-benar berjalan, bukan bagaimana seharusnya berjalan menurut manual.
Diagram berikut merangkum hubungan antara solusi teknis dan lima dimensi konteks organisasi yang saling memengaruhi.
Setelah Anda memahami konteks organisasi, barulah Anda bisa merancang solusi yang tidak hanya secara teknis berfungsi, tetapi juga secara organisasi bisa berjalan. Solusi yang cocok dengan proses, menghormati peran, mematuhi aturan, mengakui kepemilikan data, dan bekerja dalam batasan operasional.
Pemahaman ini juga yang akan membantu Anda nanti saat harus menjelaskan mengapa solusi tertentu dipilih, mengapa fitur tertentu tidak bisa dibuat, atau mengapa timeline perlu disesuaikan. Karena Anda tidak hanya menjawab pertanyaan teknis, tetapi juga pertanyaan organisasi.
Setelah konteks organisasi mulai terpetakan, langkah selanjutnya adalah turun ke lapangan dan melihat bagaimana pekerjaan benar-benar dilakukan—bukan bagaimana seharusnya dilakukan menurut dokumen. Itu menjadi fokus subbab berikutnya.