BAB IV PERANCANGAN. 4.1 Proses Bisnis Pengadaan Barang

Transkripsi

1 BAB IV PERANCANGAN Pada tahap perancangan ini akan dilakukan perancangan proses pengadaan barang yang sesuai dengan proses bisnis rumah sakit umum dan perancangan aplikasi yang dapat membantu proses pengadaan barang. Perancangan proses akan dilakukan dengan menggunakan SCOR Framework sedangkan aplikasi menggunakan Rational Unified Process (RUP). 4.1 Proses Bisnis Pengadaan Barang Business Scope SCM Rumah Sakit Umum Dari hasil analisis didapatkan bahwa proses pengadaan barang melibatkan beberapa pihak baik internal rumah sakit maupun pihak eksternal yaitu pemasok. Hubungan antar pelaku dalam proses pengadaan barang tersebut akan menjadi lingkup bisnis dari proses yang akan dibahas pada tugas akhir ini. Lingkup bisnis tersebut biasa disebut dengan Business scope. Business scope ini perlu digambarkan sebelum melakukan perancangan proses dengan SCOR Framework, agar tidak ada proses yang tidak ikut serta dalam identifikasi. Aliran informasi dan barang antar pelaku SCM dapat dilihat dari penggambaran business scope. Gambar IV-1 merupakan business scope pembelian barang SCM RS Advent yang sedang berjalan saat ini. Jika dilihat dari penggambaran aliran informasi yang terjadi sebenarnya sudah cukup sederhana. Ketidakefektifan terjadi akibat dari cara yang dilakukan untuk mengalirkan informasi tersebut. Dari sisi aliran barang tidak ada perubahan dalam perancangan ini, karena aliran barang yang ada sudah sesuai dengan proses bisnis pengadaan barang dan kebutuhan setiap pelaku. Pada proses pembelian barang yang digambarkan dengan garis putus-putus terlihat bahwa informasi mengenai barang yang akan dibeli yang berasal dari unit dialirkan terlebih dahulu ke gudang. Barulah di bagian gudang permintaan pembelian tersebut ditulis ulang, digabungkan dengan barang-barang yang stoknya habis (pembuatan purchase requisition), kemudian diteruskan ke bagian pembelian. IV-1

2 IV-2 Dari hasil analisis dan pengamatan, disimpulkan bahwa terjadi pengulangan aktivitas pencatatan permintaan unit. Untuk itu, pada proses pengadaan barang yang baru, aliran informasi yang bersifat pengulangan ini akan dihilangkan. Informasi permintaan unit akan langsung dihubungkan ke bagian pembelian. Informasi barangbarang yang stoknya habis juga akan langsung dapat diakses oleh bagian pembelian. Tidak ada lagi purchase requisition yang pada dasarnya hanya bersifat pengumpulan barang-barang apa saja yang akan dibeli. &' (( % #$! " Gambar IV-1 Aliran Informasi Pembelian pada Business Scope Lama Gambar IV-2 merupakan aliran informasi yang baru pada proses pengadaan barang. Dari Gambar IV-2 terlihat arah panah dari bagian pembelian yang berlawanan dengan arah pada aliran informasi sebelumnya. Pihak pembelian akan aktif melakukan pengaksesan terhadap informasi stok gudang dan menentukan barang yang dibeli, sebelumnya hal ini dilakukan oleh staf gudang. Perubahan pelaku dari pembelian ini dipandang lebih efektif karena staf pembelianlah yang mengetahui perencanaan pembelian sehingga kesalahan dalam pembelian dan

3 IV-3 pengulangan aktivitas verifikasi diharapkan dapat dikurangi dengan pergantian pelaku ini. Staf gudang sendiri akan lebih terfokus untuk mengatur aliran keluar masuk barang di gudang dan melayani permintaan barang unit lebih cepat. &' (( % #$ %! " Gambar IV-2 Aliran Informasi Pembelian pada Business Scope Baru Aliran informasi ke pemasok masih tetap sama alurnya hanya cara pengaliran informasi yang berbeda. Sebelumnya menggunakan telepon, pada proses ini menggunakan bantuan aplikasi teknologi informasi. Proses lain yang juga terlibat dalam business scope dari pengadaan barang ini selain proses pembelian adalah proses pengembalian barang. Perubahan aliran informasi pada pembelian akan mengakibatkan perubahan pada pengembalian barang. Gambar IV-3 merupakan aliran informasi dan barang pada proses pengembalian barang yang ada saat ini.

4 IV-4 &' (( % #$! " Gambar IV-3 Aliran Informasi Pengembalian Barang Lama Pada proses pengembalian ini tanggung jawab untuk pemberitahuan adanya pengembalian barang ada pada pihak gudang. Pemberitahuan terjadinya penukaran atau pembatalan (pengembalian) kepada pemasok dilakukan oleh gudang atau staf penerimaan. Akibatnya, pemasok sering terlambat mengetahui adanya pengembalian. Ini dikarenakan pihak gudang atau staf penerimaan memiliki frekuensi pekerjaan pelayanan terhadap unit dan penerimaan barang tanpa henti selama jam kerja. Penggunaan aplikasi teknologi informasi yang akan membantu penyebaran aliran informasi pengembalian ini ke seluruh pihak yang terkait dalam satu waktu seketika ketika ada pemberitahuan dari unit bahwa terjadi pengembalian barang. Bagian gudang akan mendapatkan pemberitahuan pengembalian barang dan perubahan stok gudang secara otomatis. Pada bagian pembelian akan menerima pemberitahuan pembuatan purchase order yang baru jika pengembalian berupa penukaran. Perubahan status penerimaan barang di bagian penerimaan dan pemberitahuan kepada pemasok juga akan dilakukan secara otomatis melalui aplikasi. Aliran informasi tersebut dapat dilihat pada Gambar IV-4.

5 IV-5 Gambar IV-4 Aliran Informasi Pengembalian Baru Alur Global Proses Pengadaan Barang Berikut ini merupakan penjabaran perubahan dari setiap proses dalam pengadaan barang berdasarkan hasil identifikasi proses-proses apa saja yang dibutuhkan oleh setiap pelaku dalam SCM rumah sakit: 1. Persetujuan Aktivitas yang berupa persetujuan sebenarnya dapat dihilangkan. Hal ini dikarenakan, berdasarkan hasil pengamatan, aktivitas ini hanya formalitas agar dapat terjadi pembelian, kepala divisi yang terkait dengan proses SCM tidak akan melakukan pengecekan daftar order yang dibuat. Jika pembelian yang dilakukan bernilai besar, persetujuan ini dapat digantikan dengan proses otorisasi secara online melalui aplikasi SCM yang digunakan. Pada saat otorisasi ini dihadirkan pula informasi rencana pembelian agar pengawasan tetap dapat dilakukan. Untuk itu, terdapat proses tambahan dalam pengadaan barang ini yaitu penyediaan informasi rencana pembelian.

6 IV-6 2. Pemilihan pemasok Aktivitas pemilihan pemasok yang dilakukan oleh staf pembelian dapat dilakukan secara otomatis dengan bantuan aplikasi teknologi informasi, petugas tidak perlu melakukan pencatatan satu per satu pemasok yang akan dihubungi. Untuk penggunaan single pemasok pemilihan pemasok akan lebih mudah dilakukan sedangkan double pemasok dapat dilakukan dengan memfilter berdasarkan kriteria tertentu, sebagai contoh harga termurah, waktu kirim tercepat, atau diskon terbesar. 3. Penggunaan nota Penggunaan dokumen seperti nota terutama pada konsumsi barang-barang pembelian secara cash dan just in time dapat digantikan dengan penggunaan aplikasi dan pemberian otoritas bagi unit untuk membuat daftar pesanan barang langsung di aplikasi. Staf pembelian tidak perlu membuat daftar pesanan ulang. Bagian penerimaan juga tidak perlu melakukan verifikasi ketika terjadi penyerahan salinan nota penerimaan dan faktur bukti pemesanan barang secara just in time. 4. Verifikasi pembelian just in time Penghilangan nota dalam pembelian just in time mengakibatkan verifikasi tidak perlu dilakukan lagi, karena seluruh data pembelian telah tersimpan dan tidak dapat dimanipulasi. Bagian pembelian juga tidak perlu membuat purchase order berdasarkan nota seperti sebelumnya. Purchase order dibuat oleh unit dan hanya perlu persetujuan Kepala divisi SCM pada hari berikutnya. 5. Pembuatan daftar pesanan (purchase order) pada pembelian cash Penghilangan nota dalam pembelian secara cash akan mengakibatkan tidak ada lagi proses pembuatan daftar belanja atau penundaan input barang seperti yang dilakukan sebelumnya pada saat penerimaan barang cash. 6. Penyediaan informasi rencana pembelian Penyediaan informasi rencana pembelian diperlukan untuk mendukung proses pengawasan pembelian oleh Kepala divisi SCM dan Staf accounting. Informasi ini diperlukan untuk dijadikan pertimbangan sebelum merupakan otorisasi terhadap pembelian dan pembayaran.

7 IV-7 7. Penyediaan status tiap barang Proses ini dimunculkan karena status diperlukan untuk menghindari adanya pengulangan pembelian barang atau verifikasi yang harus dilakukan berulang kali selama proses pembelian dan pengiriman barang. 8. Pembuatan purchase requisition Kebutuhan utama diidentifikasi berdasarkan kebutuhan barang unit dan pengecekan ketersediaan stok. Tidak ada lagi permintaan pembelian yang dibuat oleh gudang. Perencanaan pembelian dan keputusan barang apa yang akan dibeli dilakukan langsung oleh bagian pembelian dengan mempertimbangkan posisi stok barang tiap gudang dan barang yang tidak tersedia sebelumnya di gudang tapi diminta. Tidak ada lagi purchase requisition 9. Menghubungi pemasok melalui telepon Pihak pemasok/vendor akan mengetahui pesanan terhadap dirinya dengan mengakses purchase order yang telah dibuat bagian pembelian secara langsung (melalui aplikasi teknologi informasi). Jika pemasok tidak dapat memenuhi, pemasok dengan segera akan memberitahukan bagian pembelian melalui pengubahan status dari order. Pihak pembelian dengan segera akan mengulang proses pembuatan order seketika menerima pemberitahuan. Pada bagian analisis terlihat bahwa terdapat pembedaan cara pembelian menjadi tiga jenis cara pembelian utama yaitu tender, kontra bon, dan cash. Pembelian kontra bon sendiri masih dibedakan menjadi bermacam-macam cara yaitu pembelian barang pada jam kerja, pembelian barang farmasi pada jam kerja, dan just in time. Pada rancangan proses pengadaan barang ini, pembelian barang secara umum hanya dibedakan menjadi dua macam yaitu pembelian tender dan kontra bon. Pembelian barang secara cash dihapuskan. Pada kenyataannya, pembelian cash mungkin tidak dapat dihindari karena kebutuhan yang sedikit bisa saja terjadi di rumah sakit. Proses pembelian ini tetap ada tetapi cara yang dilakukan sama dengan pembelian secara kontra bon dengan asumsi pasar atau toko tempat berbelanja diperlakukan seperti halnya pemasok. Proses-proses yang terjadi tidak ada perbedaan. Perbedaan terletak pada alur proses yaitu pembayaran dilakukan setelah proses otorisasi pembayaran bukan penerimaan barang.

8 IV-8 Dekomposisi proses pembelian secara kontra bon menjadi tiga macam seperti yang diungkapkan sebelumnya juga dihapuskan. Cara pembelian dilakukan hanya dengan satu cara. Tidak ada lagi perbedaan pembelian untuk barang farmasi dengan barang non-farmasi. Begitu pula, dengan cara pembelian pada jam kerja dan di luar jam kerja (just in time) dari segi proses-proses yang terjadi. Untuk pembelian pada jam kerja dan just in time perbedaan terletak pada pelaku pembuat purchase order, jika pada jam kerja pelakunya ialah staf pembelian, maka pada just in time pelakunya adalah unit rumah sakit yang sekaligus sebagai sumber dari kebutuhan unit. Seperti yang telah diungkapkan pada bagian 4.1.1, bahwa pada rancangan proses pengadaan barang ini terjadi eliminasi proses pembuatan purchase requisition yang berakibat perubahan tanggung jawab antara staf pembelian dan staf gudang. Staf pembelian yang tadinya hanya melakukan pemilihan pemasok kemudian meneruskan informasi barang yang dibeli ke pemasok melalui telepon, pada rancangan ini bertugas untuk membuat purchase order saja. Isi dari purchase order berasal dari permintaan khusus unit dan stok gudang. Proses pemilihan pemasok dan hubungan ke pemasok dilakukan secara otomatis dengan menggunakan aplikasi teknologi informasi. Pada proses pengadaan barang yang terjadi saat ini, informasi harus dilakukan antar pelaku. Pada alur yang baru, beberapa pelaku diberikan otoritas untuk mengakses informasi dari pelaku lain. Hal ini akan mengurangi waktu tunggu datangnya informasi antar pelaku SCM.

9 IV-9 Alur global dari rancangan proses pembelian ini dapat dilihat pada Tabel IV-1. Tabel IV-1 Alur Proses Pembelian

10 IV Pemodelan Proses dengan SCOR Framework Level 1 dari SCOR Framework untuk proses pengadaan barang dapat dilihat pada Gambar IV-5. Gambar IV-5 Pemetaan Proses SCOR Framework Level 1 Pada level 1 ini teridentifikasi proses-proses utama yang terjadi antar pelaku besar dalam SCM rumah sakit umum. Pelaku besar dikelompokkan menjadi tiga macam yaitu pemasok sebagai penyedia barang, Divisi SCM yang seolah-olah sebagai manufaktur, dan unit rumah sakit sebagai retail dalam SCM. Seluruh pelaku tersebut melakukan proses pertama yang didefinisikan SCOR yaitu plan. Disisi pemasok proses utama yang terkait adalah deliver dan return. Hal ini dikarenakan pemasok memiliki posisi sebagai pengirim barang yang diminta, ditukar, atau dibatalkan oleh rumah sakit. Divisi SCM dalam hal ini berlaku seolah-olah seperti pabrik dalam manufaktur. Namun, aktivitas produksinya bukan berupa produksi barang/jasa melainkan pengadaan dan pengiriman barang. Maka, proses yang teridentifikasi meliputi source untuk pengadaan, deliver untuk pengiriman ke customer, dan return untuk menangani pengembalian barang baik pengembalian dari unit ke gudang atau hingga ke pemasok. Jika dilihat dari segi operasional bisnis rumah sakit, unit rumah sakitlah yang sebenarnya seolah-olah seperti pabrik di rumah sakit karena proses produksi jasa terjadi di unit rumah sakit. Namun, jika dilihat dari segi jaringan SCM, unit merupakan retail yang menyalurkan barang ke perseorangan. Pada tugas akhir ini, peran produksi unit rumah sakit tidak dihilangkan. Hal ini dikarenakan proses

11 IV-11 produksi tersebut yang akan memunculkan kebutuhan akan barang yang harus dipenuhi. Proses yang teridentifikasi di unit di antaranya make yaitu produksi jasa yang akan mempengaruhi adanya permintaan barang, source yaitu permintaan barang ke divisi SCM, dan return untuk pengembalian barang. Untuk setiap proses besar di level 1 dari SCOR Framework tersebut akan didekomposisi menjadi proses yang lebih kecil lagi pada level 2. Pada level 2 ini, untuk setiap proses di level 1 akan diidentifikasi kategori apa yang cocok.. Pada tugas akhir ini, pemilihan kategori tidak didasarkan pada satu strategi operasional misal Make To Stock. Hal ini dikarenakan SCOR Framework dibangun berbasiskan manufaktur, sehingga dibutuhkan penyesuaian untuk kasus rumah sakit. Level 2 dari proses pengadaan barang dapat dilihat pada Gambar IV-6. Pada level 2 ini, diidentifikasi proses-proses lebih detil yang terjadi untuk setiap proses level 1. Proses ini merupakan bentuk eksekusi dari proses level 1. Adapun enable merupakan proses yang bertugas mempersiapkan, memelihara (maintain), dan mengatur informasi yang diperlukan untuk menjalankan setiap proses level 1 tersebut. Sebagai contoh, pada saat proses permintaan barang (source) maka informasi yang dibutuhkan adalah informasi terkait posisi inventori rumah sakit. Ketika barang yang dibutuhkan tidak ada, maka dibutuhkan informasi mengenai pemasok yang menyediakan. Jika ditemukan maka akan dibuat permintaan pembelian yang akan diatur oleh enable manajemen data pembelian. Pada level 3, seluruh proses yang diidentifikasi di level 2 ini akan digambarkan menjadi alur kerja (workflow) yang akan menggambarkan skenario dari pelaksanaan proses pengadaan barang. Level 4-5 merupakan dekomposisi dari level 3 yang akan menggambarkan alur kerja lebih detil berupa aktivitas dan task yang dikerjakan oleh pelaku SCM. Pda tugas akhir ini tidak digambarkan level 6 dari pengadaan barnag karena hingga level 5 alur kerja yang digambarkan sudah sangat detil dan dapat dijadikan dasar rancangan aplikasi. Rancangan level 3-5 dari SCOR Framework dapat dilihat pada Lampiran D.

12 Gambar IV-6 Pemetaan Proses pada SCOR Framework Level 2 IV-12

13 IV-13 Gambar IV-7 merupakan pemetaan seluruh proses termasuk proses enable yang diperlukan oleh setiap proses level 2 dari SCOR Framework yang didefinisikan sebelumnya. Gambar IV-7 Pemetaan Proses Bisnis pada Level 3 dengan Enable

14 IV Perancangan Aplikasi Arsitektur Aplikasi Hampir seluruh proses umum dari SCM telah dibantu dengan aplikasi komputer, hanya proses pembelian barang yang belum disediakan modulnya. Hal ini karena dibutuhkan investasi dan integrasi dengan pihak di luar rumah sakit. Namun, pada dasarnya integrasi ini mungkin dilakukan dan investasi yang dibutuhkan cukup rendah karena rumah sakit telah memiliki dukungan infrastruktur baik hardware ataupun aplikasi SCM yang terintegrasi. Bentuk dari aplikasi yang digunakan untuk mengintegrasikan pemasok dengan rumah sakit bermacam-macam. Bentuk aplikasi tersebut di antaranya : 1. Aplikasi single berupa desktop atau web based Aplikasi ini disediakan oleh rumah sakit dan dapat diakses oleh pihak pemasok. Baik pemasok maupun rumah sakit menggunakan bentuk aplikasi yang sama. Keuntungan dari aplikasi ini adalah pemasok kecil yang belum memiliki sistem manajemen informasi penjualan tetap dapat mengetahui order barang yang didapatkannya. Kekurangannya adalah beban pengelolaan ditanggung oleh rumah sakit. Bentuk hubungan aliran informasi pada aplikasi ini dapat dilihat pada Gambar IV-8 Gambar IV-8 Aliran Informasi pada Single Application Pola integrasi ini merupakan pola yang paling memungkinkan untuk dilakukan saat ini karena tidak perlu ada kesepakatan baru antara pemasok dengan rumah sakit mengenai data barang. Selain itu, rumah sakit telah memiliki infrastruktur yang sangat memadai. Penambahan fitur yang terjadi yaitu dengan pemberian akses ke pemasok untuk melihat pesanan yang terjadi.

15 IV-15 Seluruh pelaku internal dari SCM dihubungkan melalui jaringan LAN rumah sakit, sedangkan pemasok dapat mengakses aplikasi melalui jaringan komunikasi (internet). Terdapat sebuah server dapat berupa web server atau server aplikasi biasa yang terhubung dengan relational database management system untuk penyimpanan data. Jika single application yang digunakan berupa aplikasi web, maka didalam web server akan berisi modul-modul aplikasi seperti modul pembelian, permintaan barang unit, pengembalian barang, dan modul-modul manajemen. Arsitektur dari single application ini dapat dilihat pada Gambar IV-9. ) ) ) % (& ) *' & ' ! Gambar IV-9 Arsitektur Single Application 2. Integrasi aplikasi milik rumah sakit dengan milik pemasok. Bentuk aplikasi yang digunakan independen milik rumah sakit dan pemasok. Aplikasi dihubungkan dengan menggunakan teknologi integrasi. Terdapat bermacam-macam teknologi pendekatan integrasi di antaranya pendekatan point to point dan integrator standar yang bersifat terbuka atau satu untuk semua aplikasi. Aplikasi integrator point to point memiliki ciri jika ada N-entitas dan setiap entitas dalam sistem perlu saling terhubung maka diperlukan N x (N-1) konektor. Jika hubungan hanya pada satu titik maka N-1 konektor. Jika sebuah entitas melakukan perubahan atas aplikasi maka seluruh integrator yang terkait dengan entitas

16 IV-16 tersebut juga harus berubah. Cara integrasi ini merupakan cara integrasi termudah, tapi dalam jangka panjang akan menimbulkan potensi masalah baru dari segi kompleksitas dan biaya. Bentuk komunikasi dari integrator tipe ini dapat dilihat pada Gambar IV-10. &,, & ( Gambar IV-10 Bentuk Integrasi Sistem N-to-N Integrator standar berbentuk sebuah layanan yang berisi standar komunikasi data dan pengungkapan makna dari data tersebut, sehingga pada saat integrasi sebuah aplikasi hanya perlu melakukan pembuatan antar muka yang dapat berhubungan dengan integrator tersebut. Contoh teknologi integrator ini adalah service oriented architecture berupa penggunaan web service. Service oriented architecture (SOA) memiliki 3 elemen penting yaitu service provider, locator/broker, dan consumer. Service provider merupakan penyedia layanan yang dapat diakses oleh aplikasi lain. Locator/broker berfungsi sebagai penentu rute, pencari layanan yang tepat sesuai dengan permintaan dari consumer. Consumer merupakan aplikasi yang menggunakan layanan yang disediakan oleh aplikasi lain. Pada kasus pengadaan barang ini, baik aplikasi rumah sakit maupun pemasok sama-sama bertindak baik menjadi consumer maupun provider. Rumah sakit berperan sebagai provider ketika pemasok membutuhkan informasi barang-barang pesanan kedirinya (pengiriman purchase order), sedangkan peran consumer terjadi ketika rumah sakit membutuhkan informasi status pemesanan barangnya atau ingin mengetahui penawaran barang dari pemasok. Pemasok berperan sebagai provider ketika menyediakan informasi katalog dan sebagai consumer ketika mengakses pesanan terhadap dirinya. Arsitektur berbasiskan layanan (SOA) ini dapat dilihat pada Gambar IV-11. Arsitektur ini

17 IV-17 dibangun dengan asumsi seluruh pemasok memiliki infrastruktur teknologi informasi baik hardware maupun software. Pada Gambar IV-11 terlihat bahwa pada kasus pembelian, rumah sakit berperan sebagai provider yang menyediakan informasi pembelian barang. Informasi tersebut dikirimkan melalui sebuah antar muka ke service locator. Pada saat pemasok membutuhkan informasi tersebut, maka pemasok akan meminta layanan kepada service locator melalui sebuah antar muka yang terhubung dengan antar muka dari service locator. Service locator akan melakukan pencarian informasi yang sesuai kemudian akan dikirimkan kepada consumer. Pada akhirnya informasi tersebut akan ditampilkan oleh aplikasi disisi consumer. Gambar IV-11 Arsitektur Integrasi Sistem dengan SOA SOA berbeda dengan arsitektur web pada single application. Perbedaan utama terletak pada data yang disimpan antara dua belah pihak. Jika pada single application seluruh data baik milik pemasok maupun rumah sakit disimpan dalam satu tempat, sedangkan jika SOA disimpan di masing-masing pihak. Sebagai contoh, dalam kasus pengadaan barang ini, untuk informasi katalog

18 IV-18 barang dari pemasok, pihak pemasok tidak perlu melakukan input ke sistem yang digunakan bersama untuk penawaran barang. Informasi dapat langsung diberikan dengan mengakses langsung basis data milik pemasok kemudian dikirimkan melalui layanan ke rumah sakit. Perbedaan lain adalah bahwa seluruh transaksi dilakukan melalui layanan bahkan transaksi yang sederhana seperti menampilkan informasi. Keuntungan dari penggunaan SOA ini adalah tidak ada redundancy data dan biaya penyimpanan data lebih kecil di masing-masing pihak. Persoalan integrasi ini tidak hanya terbatas bagaimana melakukan pertukaran data secara fisik tetapi juga semantik. Pengungkapan atas isi dan konsep yang direpresentasikan oleh sekelompok data merupakan kunci bagi terciptanya sebuah integrator yang baik. Salah satu cara pengungkapan semantik dari data ini adalah dengan membangun ontologi. Ontologi adalah kumpulan kelas, relasi, dan fungsi yang merepresentasikan pengetahuan dalam semesta yang terdefinisi. Ontologi ini seolah-olah seperti knowledge repository atas seluruh aktivitas dalam supply chain management. Setiap perangkat lunak yang terlibat akan dipetakan terhadap knowledge repository tersebut melalui sebuah antarmuka tertentu. Pada tugas akhir ini bentuk aplikasi yang dirancang hingga seluruh modul adalah bentuk single application. Rancangan yang dibuat dapat diimplementasikan baik dalam bentuk aplikasi desktop maupun berbasis web Kebutuhan Fungsional dan Nonfungsional Aplikasi Dari identifikasi kebutuhan proses untuk setiap pelaku SCM yang dilakukan pada tahap analisis maka dapat disimpulkan kebutuhan fungsional dan nonfungsional dari aplikasi. Kebutuhan tersebut dapat dilihat pada Tabel IV-2 dan Tabel IV-3. Pendefinisian kebutuhan aplikasi ini merupakan awal dimulainya fase pembangunan perangkat lunak yaitu inception.

19 IV-19 Tabel IV-2 Kebutuhan Fungsional Aplikasi Pembelian Kode Kebutuhan Kebutuhan Fungsional F-01 Menambahkan, mengubah, dan menghapus permintaan unit F-02 Menambahkan, mengubah, dan menghapus stok barang F-03 Menambah, mengubah, dan menghapus order pembelian F-04 Menambah, mengubah, dan menghapus penerimaan barang F-05 Menambah, mengubah, dan menghapus informasi tender F-06 Menambah, mengubah, dan menghapus katalog F-07 Upload file tender F-08 Download File Tender F-09 Penerimaan penawaran barang F-10 Menambah, mengubah, dan menghapus pengembalian barang F-11 Menambah, mengubah, dan menghapus penukaran barang F-12 Membuat laporan F-13 Otorisasi pembelian F-14 Pemenuhan pesanan oleh pemasok Tabel IV-3 Kebutuhan Non Fungsional Aplikasi SCM Kode Kebutuhan NF-01 NF-02 Non Fungsional Dapat memisahkan hak akses setiap role Informasi antar role dapat diteruskan dalam waktu kurang dari 5 detik Overview dari spesifikasi kebutuhan fungsional dan nonfungsional digambarkan dalam bentuk diagram use case. Diagram use case tersebut dapat dilihat pada Gambar IV-12. Untuk skenario tiap use case pada fase inception dapat dilihat pada Lampiran E. Perancangan aplikasi dilanjutkan dengan fase elaboration yaitu pembentukan diagram kelas dan sekuensial analisis serta perancangan yang dapat dilihat pada Lampiran E.

20 Gambar IV-12 Diagram Use Case SCM Rumah Sakit IV-20