BAB 2 LANDASAN TEORI. 2.1 Konsep Sistem Informasi Manajemen Sistem informasi dan manajemen, secara terpisah memiliki 2 definisi yang berbeda

BAB 2 LANDASAN TEORI 2.1 Konsep Sistem Informasi Manajemen Sistem informasi dan manajemen, secara terpisah memiliki 2 definisi yang berbeda. 2.1.1 Pengertian Sistem Informasi Pengertian sistem sendiri menurut Hitesh Gupta (2011), adalah pengelompokan secara teratur komponen yang saling terhubung satu sama lain sesuai dengan rencana untuk mencapai tujuan tertentu. Di mana dalam hal ini, komponen dapat berarti bagian material fisik, langkah-langkah manajerial, atau prosedur-prosedur dalam struktur di berbagai level. Menurut Turban dan Reiner (2008), sistem informasi, secara singkat, adalah menyalurkan informasi yang benar, untuk orang yang benar, pada waktu yang benar, dalam jumlah dan format yang benar. (p. 6) Sistem informasi juga dapat diartikan sebagai serangkaian komponen komputer yang mengumpulkan, memproses, menyimpan (biasanya dalam sebuah dalam database), dan menyediakan informasi sebagai output yang dibutuhkan untuk menyelesaikan tugas-tugas bisnis. (Satzinger, 2012) Menurut Turban & Reiner (2008), 6 komponen dasar dari sistem informasi adalah sebagai berikut: 1. Hardware atau perangkat keras, perangkat yang dapat menerima data dan informasi, memrosesnya, dan menampilkannya. 2. Software atau perangkat lunak, program yang dapat memungkinkan hardware untuk melakukan proses data. 3. Database, kumpulan file dan tabel berisi data yang saling terhubung. 4. Jaringan, sistem penghubung dengan atau tanpa kabel, yang memungkinkan beberapa komputer untuk saling berbagi sumber informasi 5. Prosedur, rangkaian instruksi tentang bagaimana menjalankan komponenkomponen di atas untuk memroses informasi dan mendapatkan hasil yang diinginkan. 6. User, individu yang menggunakan, berinteraksi dengan perangkat, atau menggunakan output yang dihasilkan sistem. 7

8 Dalam sistem informasi terdapat 3 hal penting yang saling berhubungan (Turban & Reiner, 2008), antara lain: a. Data Deskripsi dasar dari objek, event, aktivitas, dan transaksi yang direkam, diklasifikasikan, dan disimpan, tetapi belum diorganisir untuk memberikan arti yang spesifik. Data dapat berupa angka, huruf, gambar, bagan, atau suara. b. Informasi Merupakan data yang sudah diolah dan sudah memiliki arti dan nilai bagi penerima informasi. c. Pengetahuan / knowledge Terdiri dari data dan/atau informasi yang telah diolah dan diproses untuk memberikan pengertian, pengalaman, akumulasi pembelajaran, dan keahlian yang

dapat

diterapkan

pada

masalah

bisnis.

8

2.1.2 Pengertian Manajemen Untuk definisi dari manajemen sendiri, menurut Robbins & Coulter (2007), adalah proses mengoordinasikan aktivitas-aktivitas kerja sehingga dapat selesai secara efisien dan efektif dengan dan melalui orang lain. Di mana yang dimaksud dengan efisien adalah memperoleh output terbesar dengan input terkecil, dan efektif, yaitu melakukan aktivitas yang diperlukan dengan benar. (p. 8) Manajemen sendiri memiliki 4 fungsi umum, yaitu merencanakan, mengorganisasi, memimpin, dan mengendalikan (Planning, Organizing, Actuating, Controlling). (Robbins & Coulter, 2007) David (2011) menambahkan 1 fungsi lagi, yaitu Staffing, yaitu pengelolaan sumber daya manusia dalam perusahaan. (p. 99) 2.1.3 Pengertian Sistem Informasi Manajemen Dari 2 pengertian dari sistem informasi dan manajemen seperti di atas, maka definisi dari sistem informasi manajemen atau management information system

(MIS)

adalah

sistem

yang

berurusan

dengan

perencanaan,

pengembangan, manajemen, dan penggunaan tools teknologi informasi, untuk membantu melakukan tugas-tugas yang berhubungan dengan pemrosesan informasi dan manajemen. (Turban & Reiner, 2008) 2.2 Konsep e-Bisnis dan e-Commerce 2.2.1 Konsep e-Bisnis Menurut salah satu pencetus definisi komperhensif e-bisnis, Zwass (1996), dalam jurnal Electronic Commerce Research (Chen & Holsapple, 2013), ebisnis pada dasarnya dapat diartikan pertukaran informasi bisnis, mengelola hubungan bisnis, dan menjalankan transaksi bisnis dengan menggunakan jaringan telekomunikasi. Timmers (2000), dalam Australasian Journal of Information Systems (2009), mengemukakan bahwa e-bisnis dalam artian yang sebenarnya adalah menjalankan semua proses bisnis, seperti transaksi, marketing, pemesanan, dll secara elektronik. Beberapa tipe dasar dari e-bisnis di mana e-bisnis dapat membeli, menjual, dan berinteraksi dengan pelanggan atau rekan bisnis menurut Matlay (2004) dalam Australasian Journal of Information Systems (2009) , antara lain:

9

a. Business-to-Business (B2B) Dimana melibatkan aktivitas marketing dan penjualan produk antara perusahaan satu dengan perusahaan lain. b. Business-to-Customer (B2B) Di mana perusahaan menargetkan produk secara langsung dan eksklusif kepada pelanggan pribadi. c. Business-to-Government (B2G) Perusahaan menyediakan produk/jasa secara elektronik kepada pemerintah atau institusi pemerintah. d. Business-to-Portal (B2P) Melibatkan aktivitas marketing dari produk tertentu dalam portal berbasis Internet. e. Business-to-Affiliate (B2A) Termasuk pemasaran afiliasi produk atau layanan pada situs web komersial.

Gambar 2.1 Taksonomi e-Bisnis (Anumba & Ruikar, 2009) (Sumber : E-business in Construction, 2009, p. 8)

2.2.2 Konsep e-Commerce E-commerce diartikan sebagai transaksi antara suatu organisasi dan pihak ketiga yang terlibat melalui media elektronik. Perbedaan e-commerce dengan ebisnis adalah e-commerce digunakan sebagai istilah yang menggambarkan proses transaksi bisnis melalui Internet. Sedangkan e-bisnis, melibatkan

10 pembangunan fundamental dari model bisnis ke dalam perusahaan dengan jaringan berbasis Internet. (Chaffey, 2009) E-business

Sell-side e-commerce

Buy-side e-commerce

Intranet

Internet and extranet

Internet and extranet

Key Suppliers

Organizational processes and functional units

Customers

Supplier’s suppliers

Intermediaries

Customer’s customers

Gambar 2.2 Dua Jenis e-Commerce (Chaffey, 2009) (Sumber : E-Business and E-Commerce Management, 2009, p. 11) 2.3 Konsep Pengadaan atau Procurement 2.3.1 Pengertian Pengadaan Menurut Ross (2010), pengadaan (barang) atau procurement adalah sebuah fungsi supply chain strategis yang bertujuan untuk mengintegrasikan dan menyinkronisasi kebutuhan persediaan perusahaan individual dengan jumlah saluran aliran barang, kapasitas produktif mitra dagang, transportasi, kualitas, pemasaran, keuangan, dan sumber-sumber pasokan global. (p. 251) Menurut Kalakota & Robinson (2000) dalam buku E-business And ECommerce Management (2009), pengadaan merujuk pada semua aktivitas yang terlibat dalam mendapatkan barang dari supplier, termasuk pembelian, tetapi juga inbound logistics, seperti transportasi, barang masuk, dan pengelolaan gudang sebelum barang digunakan. (p. 414)

11 Procuring Organization

Approver Puchase Order

Requisition Originator

Buyer Supplier Purchase order copy

Invoice and delivery note

Warehouse Payment

Payment to customer

Accountant

Gambar 2.3 Aktivitas Kunci Pengadaan Barang dalam Organisasi (Chaffey, 2009) (Sumber : E-Business and E-Commerce Management, 2009, p. 382) 2.3.2 Proses Procurement Secara Umum Setiap perusahaan memiliki prosedur pengadaan barang / materialnya masing-masing, tetapi aktivitas-aktivitas kunci yang ada pada Gambar 2.3 biasanya selalu ada dalam proses pengadaan tersebut. Secara umum, proses pengadaan barang diawali dengan pencarian produk yang ingin dibeli, kemudian bagian procurement perusahaan (originator) mengisi surat permintaan barang dan dikirim ke bagian pembelian. Terkadang harus membutuhkan persetujuan dari bagian yang lebih tinggi seperti manajer, yang sekaligus menambah waktu proses. Lalu, bagian pembelian akan membuat form order ke supplier. Setelah barang dikirim, barang dan nota pengiriman akan dicocokkan dengan form order dan invoice, kemudian akan dilakukan pembayaran. Procurement juga meliputi transportasi, penyimpanan, distribusi barang yang diterima di dalam bisnis (inbound logistics). (Chaffey, 2009) 2.3.3 Jenis-Jenis Procurement Menurut Chaffey (2009), terdapat 2 kategori besar dari procurement berdasarkan barang yang dibeli (p. 385-386), yaitu: a. Pengadaan barang yang berhubungan dengan aktivitas produksi. Contoh : bahan baku, komponen produk, packaging, dsb.

12 b. Pengadaan barang yang tidak berhubungan dengan aktivitas produksi. Dalam hal ini, barang yang dimaksud adalah barang-barang yang mendukung jalannya operasional bisnis. Contohnya : sarana dan prasarana, sistem, peralatan, beberapa bentuk service. Sedangkan untuk kategori berdasarkan metode pembelian barang, juga terdapat 2 jenis procurement, yaitu a. Systematic sourcing Negosiasi kontrak dengan supplier tetap, biasanya dalam hubungan jangka panjang. b. Spot sourcing Pemenuhan kebutuhan yang mendesak, biasanya barang komoditi di mana kredibilitas supplier tidak menjadi prioritas utama. 2.3.4 Value Chain Value Chain adalah model yang menggambarkan bagaimana aktivitas dalam rantai persediaan dapat menambah nilai kepada produk dan layanan yang diberikan kepada customer. Dengan menganalisis bagian-bagian yang berbeda dari value chain, manajer dapat merancang kembali proses-proses internal dan eksternal untuk meningkatkan efisiensi dan efektivitas proses-proses tersebut. (Chaffey, 2009) 2.4 Manajemen Pengadaan Manajemen

pengadaan

atau

procurement

management

adalah

proses

perencanaan dan koordinasi antara aktivitas-aktivitas yang berkaitan dengan pembelian barang serta service pendukung yang bertujuan untuk membantu mencapai misi dari perusahaan. (Turban et al., 2010) 2.5 E-procurement 2.5.1 Definisi Pengertian dari e-procurement, menurut Chaffey (2009), adalah integrasi elektronik dan pengelolaan dari semua aktivitas pengadaan barang, termasuk permintaan pembelian, otorisasi, pemesanan, pengiriman, dan pembayaran antara bagian pembelian dari perusahaan dengan supplier. (p. 381) Menurut Baily (2008), e-procurement adalah proses jual beli barang persediaan, pekerjaan dan layanan antara B2B, B2C, atau B2G melalui Internet

13 dan sistem informasi dan jaringan lain, seperti Electronic Data Interchange (EDI) dan Enterprise Resource Planning (ERP). (p.394) 2.5.2 Penggerak E-procurement Kalakota & Robinson (2000) dalam E-business and E-commerce Management (2009) melihat pengurangan biaya (atau bahkan sesekali biaya pemesanan melebihi nilai dari produk yang dibeli) sebagai penggerak utama eprocurement dan sejak saat itu menganggap procurement menjadi isu strategis. Pengurangan biaya langsung dapat dicapai dengan efisiensi dalam proses. Di mana efisiensi proses ini akan menyebabkan waktu yang lebih sedikit bagi staff dalam mencari dan memesan produk, serta menyesuaikan pengiriman dan invoice. Hal ini berlanjut pada validasi yang terautomasi dari anggaran pengeluaran sebelum disetujui untuk setiap individu atau departemen, yang akhirnya mengurangi orang dalam proses order dan waktu yang dibutuhkan. (p. 387) Menurut Muffatto & Payaro (2004) dan Turban et al. (2006) dalam laporan Proceedings of European and Mediterranean Conference on Information Systems (2007) dengan judul Electronic Procurement System Success in Australia, sebagian besar dari biaya-biaya lain yang dikeluarkan karena aktivitas yang tidak bersifat menambah nilai, seperti memasukkan ulang data secara manual,

memperbaiki

kesalahan-kesalahan,

pembelian

premium

yang

disebabkan oleh ketidakmampuan untuk menemukan supplier yang kompetitif, pencarian dan evaluasi supplier, berikut produk yang ditawarkan, yang tidak efisien, serta proses panjang dalam mencapai kesepakatan & persetujuan sebelum pesanan dapat dibuat. (p. 2-3) Selain biaya, waktu siklus dan fleksibilitas pemesanan, serta aktivitas penambahan nilai, juga menjadi pertimbangan sebagai penggerak eprocurement. 2.5.3 Keuntungan Dan Permasalahan E-procurement Walaupun e-procurement sering disebut sebagai salah satu strategi terbaik saat ini untuk menjalankan bisnis dengan semua keuntungan yang bisa dihasilkan, e-procurement tetap tidak lepas dari permasalah atau isu-isu yang bisa menjadi hambatan.

14 Riggins dan Mitra (2007), dalam buku E-Business And E-Commerce Management (2009) membuat framework yang menggambarkan manfaat yang dapat dihasilkan e-procurement dan e-SCM. Framework ini meliputi 3 nilai, yaitu efektifitas, efisiensi, dan strategis; yang mencakup semua dimensi dalam e-bisnis. (p. 387)

Tabel 2.1 E-business Value Grid (Sumber : E-Business And E-Commerce Management, 2009, p. 387)

DIMENSION

VALUE CREATION Efficiency

Effectivity

Strategic

Planning

Implement Rich Media for Company Wide Interaction

Provide Online Executive Information Systems

Facilitate Knowledge Management between Partners

Development

Standarized Platform for Cross Functional Design

Share Detailed Requirements between Partners

Enable Concurrent Design across Virtual Organization

Inbound

Support Electronic Transactions with Supply Partners

Generate Supply Flexibility through E-Hub Communities

Offload Replenishment Responsibility to Supply Partners

Production

Integrate Internal Systems

Exchange Production Data between Partners

Optimize Utilization of Global Capacity

Outbound

Support Electronic Transactions with Customers

Furnish Customized Instantaneous Order Status

Institute Direct Fulfillment via Logistics Partners

Turban et al. (2010) merangkum keuntungan dari e-procurement seperti berikut: a. Mengurangi siklus waktu dan biaya pembelian. b. Meningkatkan kontrol atas penganggaran (dicapai melalui aturan untuk membatasi pengeluaran dan meningkatkan fasilitas pelaporan). c. Mengeliminasi kesalahan administratif (memperbaiki kesalahan adalah bagian besar dari beban kerja pembeli) d. Menambah

produktifitas

pembeli

(memungkinkan

mereka

untuk

berkonsentrasi pada isu strategis pembelian) e. Menurunkan harga melalui standarisasi produk dan konsolidasi pembelian.

15 f. Meningkatkan manajemen informasi (akses lebih baik ke harga dari alternatif supplier dan merangkum pengeluaran). g. Meningkatkan proses pembayaran (hal ini jarang terjadi sekarang karena pembayaran tidak selalu terintegrasi dengan sistem e-procurement).

Sedangkan untuk permasalahan dan isu yang dapat menjadi hambatan bagi supplier seperti yang diidentifikasi oleh Chartered Institute of Purchasing and Supply (2008), adalah sebagai berikut: a. Isu kompetisi, contohnya sebagai dampak dari pembelian kolaboratif. b. Kemungkinan persepsi negatif dari supplier, contohnya margin mereka lebih banyak dikurangi dari e-auction. c. Keuntungan procurement yang dinegosiasikan dapat dibagi dengan pihak lain yang mungkin saja adalah kompetitor. d. Penciptaan katalog dapat menjadi proses panjang dan berbiaya tinggi bagi supplier. e. Profil kultural di dalam organisasi, contohnya penolakan akan perubahan. 2.5.4 Resiko dan Dampak E-procurement Laporan pada survey yang dilakukan Tranmit (1999) dalam buku EBusiness and E-Commerce Management (2009) menunjukkan rendahnya jumlah perusahaan yang menggunakan dan mengadaptasi teknologi e-procurement. Hal ini dikarenakan oleh pertimbangan akan resiko dan dampak yang diberikan eprocurement. (p. 392) Salah satu penyebabnya adalah masalah autentikasi identitas yang berhubungan dengan masalah keamanan informasi. (Potter, 2000) Adapun beberapa bentuk resiko yang mungkin dihadapi dalam penerapan e-procurement sebagai berikut: a. Resiko organisasional Penghematan biaya, yang merupakan tujuan dari e-procurement, dalam keadaan terburuk dapat menjadi berlebihan (redundant). Hal ini berujung pada penolakan pada pengenalan sistem dan perlu untuk dikelola. Selain itu, karena penghematan biaya dicapai melalui pemberian kuasa lebih bagi originator, dalam hal ini bagian procurement, untuk melakukan pembelian secara langsung dan tanpa melalui bagian lain (contoh bagian

16 purchasing), akan ada kemungkinan beberapa originator dapat mengambil keuntungan dari hal ini. b. Resiko kegagalan mencapai pengurangan biaya sebenarnya Resiko tentang return of investment (ROI) dari pengenalan eprocurement mungkin lebih rendah dari yang diperkirakan dan pengenalan sistem e-procurement dapat saja tidak memberikan apa yang dipikir biasanya dikarenakan oleh asumsi yang terlalu sederhana digunakan untuk menghitung penghematan dari e-procurement. c. Resiko teknologi 60% dari responden survey Tranmit (1991) melaporkan bahwa halangan terbesar untuk automasi e-procurement adalah integrasi dengan sistem finansial yang sudah ada. Karena model e-procurement yang banyak dan berevolusi dengan cepat, perusahaan kesulitan untuk memilih salah satu dari banyak pilihan tersebut. Jangkauan pasar yang berbeda, yang belum mencapai massa kritis membuat perusahaan enggan untuk masuk. 2.5.5 Implementasi E-procurement CIPS (2008) menyatakan bahwa organisasi seharusnya tidak langsung melakukan automasi proses dan sistem procurement, tetapi mempertimbangkan peningkatan cara-cara re-engineering dan jalannya proses bisnis sebelum mengimplementasikan e-sourcing / e-procurement. Hildebrand (2002) dalam buku E-Business and E-Commerce Management (2009), mengilustrasikan tantangan dari penerapan e-procurement berdasarkan Poll of 50 dari 3500 perusahaan besar, dan implementasi Supplier Relationship Management (SRM) menjadi tantangan implementasi terbesar kedua dengan rasio 30% setelah training/manajemen perubahan (32%). Untuk mengenalkan e-procurement, manajer SI dan bagian procurement harus bekerja sama untuk menemukan solusi yang menghubungkan orang-orang dan tugas-tugas yang berbeda dalam procurement. Pada dasarnya, akan lebih mudah untuk mengenalkan sistem yang hanya melayani beberapa bagian dari siklus procurement tetapi saling melengkapi.

17 Beberapa contoh sistem berbeda yang dapat diterapkan dalam siklus procurement antara lain: • Sistem kontrol stock • Katalog berbasi web atau CD • Alur kerja berbasis e-mail atau database • Input pemesanan di website • E-procurement yang terintegrasi atau sistem ERP 2.6 Pemilihan dan Penilaian Kinerja Supplier 2.6.1 Pengertian Pemilihan dan Penilaian Kinerja Supplier Menurut Chauliah Fatma Putri (2012), Sistem Evaluasi dan Seleksi Supplier (SESS) yang selektif dan objektif diperlukan perusahaan untuk mendapatkan supplier yang baik untuk kerjasama jangka panjang. Sistem evaluasi dan seleksi supplier yang baik adalah yang menekankan pada aspek biaya dan penilaian subjektif lain. (p. 25) Menurut Heizer & Render (2008), pemilihan supplier / vendor dilakukan berdasarkan banyak faktor, seperti kecocokan strategi, kompetensi vendor, pengiriman, dan performa kualitas. (p. 465) Terdapat 3 fase dalam proses pemilihan supplier, yaitu: a. Evaluasi supplier Meliputi aktivitas-aktivitas seperti menemukan supplier potensial dan menentukan kemungkinan supplier tersebut memiliki kualitas yang baik. b. Pengembangan supplier Perusahaan harus meyakinkan bahwa supplier menghargai kebutuhan kualitas, spesifikasi produk, jadwal pengiriman, sistem pembayaran, dan kebijakan procurement. Selain itu, pengembangan supplier juga termasuk pelatihan, bantuan produksi dan pembuatan, hingga prosedur perpindahan informasi. c. Negosiasi Apapun strategi supply chain apapun yang diadopsi, negosiasi mengenai elemen kritis dari hubungan dengan kontrak harus terjadi. Negosiasi ini biasanya meliputi kualitas, pengiriman, pembayaran, dan biaya.

18 Kualitas supplier dan ketepatan dalam memilih mereka, menurut Dr. Dawei Lu (2011), akan memberikan implikasi langsung kepada tingkat kompetitif jangka panjang supply chain. (p. 88) Proses dalam memilih supplier adalah sebagai berikut: (Lu, 2011) • Membuat kriteria pemilihan • Kontak pertama • Evaluasi formal • Pembuatan kuota harga • Data finansial • Pemeriksaan referensi • Kunjungan supplier • Audit, penilaian, atau survey • Tes inisiasi 2.6.2 Kriteria Penilaian Kinerja Supplier Ada 3 pendekatan dengan perbedaan signifikan terhadap pemilihan supplier. a. Berdasarkan produk yang dapat ditawarkan supplier. Biasanya mengecek prototype produk untuk melihat kualitas dan spesifikasi teknikal dapat dipenuhi dan kondisi pengiriman sudah memuaskan. b. Berdasarkan kapabilitas yang dapat diperlihatkan supplier. Biasanya mengecek apakah supplier memiliki kapabilitas desain dan pengembangan, investasi strategis dalam teknologi dan skill, dan siap dengan manajemen awal. c. Kombinasi dari pemilihan produk dan kapabilitas. Diterapkan ketika bagian baru yang penting secara strategis akan di outsource ke supplier baru. Shpend (2013) menulis 23 kriteria penting dalam penilaian kinerja supplier dari survey atas 273 manajer purchasing di Amerika Utara oleh Dickson (1966). (p.64)

Tabel 2.2 Kriteria Pemilihan Supplier (Sumber : Management Research and Practice, 2013, p. 64) Rank

Factor

Mean Rating

Evolution

19

1

Quality

3.508

2

Delivery

3.417

3

Performance History

2.998

4

Warranties and Claim Process

2.849

5

Productions Facilities and Capacity

2.775

6

Price

2.758

7

Technical Capability

2.545

8

Financial Position

2.514

9

Procedural Compliance

2.488

10

Communication System

2.426

11

Reputation and Position in Industry

2.412

12

Desire for Business

2.256

13

Management and Organization

2.216

14

Operating Controls

2.211

15

Repair Services

2.187

16

Attitude

2.120

17

Impression

2.054

18

Packaging Ability

2.009

19

Labor Relations Record

2.003

20

Geographical Location

1.872

21

Amount of Past Business

1.597

22

Training Aids

1.537

23

Reciprocal Arrangements

0.610

Extreme importance

Considerable importance

Average importance

Slight importance

Penjelasan dari 23 kriteria pada Tabel 2.2 di atas adalah sebagai berikut: 1. Harga bersih (termasuk potongan harga dan biaya kirim) yang ditawarkan supplier.

20 2. Kemempuan tiap supplier untuk memenuhi spesifikasi kualitas secara konsisten. 3. Layanan perbaikan yang mungkin dapat diberikan oleh supplier. 4. Kemampuan tiap supplier untuk memenuhi jadwal pengiriman yang ada. 5. Lokasi geografi. 6. Posisi finansial dan rasio kredit dari tiap supplier. 7. Kapasitas dan fasilitas produksi dari tiap supplier. 8. Jumlah bisnis yang telah ditangani oleh tiap supplier. 9. Kapabilitas teknik (termasuk fasilitas riset dan pengembangan) dari tiap supplier. 10. Organisasi dan manajemen dari tiap supplier. 11. Pembelian di masa depan yang mungkin dilakukan oleh supplier dari perusahaan. 12. Sistem komunikasi (dengan informasi dari kelangsungan data pesanan) dari tiap supplier. 13. Kontrol operasional (termasuk melaporkan

sistem kontrol kualitas, dan

inventory). 14. Posisi di industri (termasuk kepemimpinan produksi dan reputasi) dari tiap supplier. 15. Rekam hubungan tenaga kerja dari tiap supplier. 16. Perlakuan dari tiap supplier terhadap perusahaan. 17. Ketertarikan akan perusahaan dari tiap supplier. 18. Garansi dan klaim kebijakan dari tiap supplier. 19. Kemampuan tiap supplier untuk memenuhi kebutuhan packaging untuk produk yang dibeli. 20. Kesan yang diberikan supplier dalam kontak personal. 21. Ketersediaan bantuan training dan edukasi penggunaan produk dari tiap supplier. 22. Kemungkinan bersedia bekerjasama dengan prosedur perusahaan dari tiap supplier. 23. Sejarah kinerja dari tiap supplier.

21 2.6.3 Metode Penilaian dan Pemilihan Supplier Dalam proses pemilihan supplier, terdapat beberapa metode yang sudah banyak digunakan selama beberapa dekade, diantaranya adalah metode kategorikal, rasio biaya, dan rata-rata linear (Lu, 2011). Selain ketiga metode di atas, metode yang mulai umum digunakan adalah Analytic Network Process (ANP) dan Analytic Hierarchy Process (AHP) (Saaty, 2007). Dan dalam penelitian ini, akan digunakan metode AHP dengan bantuan software Expert Choice 11 dalam pelaksanaanya, dengan tetap lengkapi dengan perhitungan di spreadsheet dengan Microsoft Excel (Ishizaka & Labib, 2009). Perbedaan antara kedua metode tersebut, menurut Saaty (2007), hanya terdapat pada bentuk model dalam perincian kriteria dan alternatif pilihannya, serta hubungan tiap node-nya. AHP sendiri adalah sebuah metode pembuatan keputusan dengan multikriteria atau multi-criteria decision making (MCDM) yang membantu menghadapi masalah kompleks dengan beberapa kriteria yang subjektif dan saling berbenturan (Ishizaka & Labib, 2009). Konsep dari metode ini adalah mengubah nilai-nilai kualitatif menjadi nilai kuantitatif, sehingga keputusan yang diambil menjadi lebih objektif (Putri, 2012), AHP juga disebut dapat digunakan untuk memilih keputusan, dari beberapa alternatif, yang paling mendekati 4 perspektif balance scorecard (keuangan,

customer,

operasional,

dan

SDM),

juga

dengan

strategi

organisasional. (Kendrick & Dan Saaty, 2007) Pengambilan keputusan dalam metode AHP berdasarkan 3 pokok (Putri, 2012), yaitu: • Penyusunan hierarki Untuk mendefinisikan masalah agar dapat lebih detail dan jelas. • Penentuan prioritas Dipandang sebagai bobot atau kontribusi terhadap tujuan pengambilan keputusan. • Konsistensi logis Konsistensi akan menentukan validitas data serta hasil keputusan.

22 Seperti metode MCDM lain, seperti ELECTRE, MacBeth, SMART, PROMETHEE, UTA, dsb, langkah-langkah dalam AHP juga terbagi menjadi 4 langkah, (Ishizaka & Labib, 2009; Kendrick & Saaty, 2007; Putri, 2012) yaitu: 1. Membuat model hierarki untuk mendefinisikan masalah dan tujuan solusi (goal). 2. Menentukan kriteria-kriteria penilaian dalam pengambilan keputusan, serta alternatif-alternatif kemungkinan. Kriteria yang digunakan adalah yang menurut perusahaan, merupakan faktor yang benar-benar berpengaruh pada goal, seperti kualitas, kuantitas, harga/biaya, waktu pengiriman, dsb. 3. Memberikan bobot dalam skala numerik berdasarkan prioritas dari masingmasing alternatif terhadap kriteria yang ada. Tujuannya untuk mengetahui tingkat kepentingan/preferensi dari pihak-pihak yang berkaitan dengan goal, terhadap kriteria dan struktur hierarki secara keseluruhan. Dilakukan dengan metode perbandingan berpasangan (pairwise comparison) dengan membandingkan setiap alternatif terhadap kriteria, dan antar kriteria sendiri. Berikut adalah tabel penilaian yang dipakai untuk pairwise comparison.

Tabel 2.3 Sistem Penilaian Perbandingan Berpasangan 2 Elemen (Sumber : Jurnal Widya Teknika, 2012, p. 27) Tingkat kepentingan

Definisi

1

Sama pentingnya

3

Sedikit lebih penting

5

Lebih penting

7

Sangat penting

9

Mutlak lebih penting

2,4,6,8

Nilai tengah diantara penilaian di atas

Jika elemen X mendapat nilai tingkat kepentingan n saat dibandingkan dengan elemen Y, maka elemen Y akan mendapat nilai tingkat kepentingan kebalikan dari n yang didapat elemen X. X dibandingkan Y = n

23 1 Y dibandingkan X = n 4. Menguji konsistensi, memproyeksikan hasil analisis ke dalam grafik sensitivitas. Inkonsistensi terjadi ketika beberapa penilaian tidak sinkron dan berubahubah, sehingga akan berdampak pada validitas penilaian dan keputusan. Tingkat inkonsistensi harus dibawah 0,10. Expert Choice dapat memantau level inkonsistensi untuk memastikan preferensi dari responden tetap konsisten. Grafik sensitivitas bertujuan untuk mengetahui dampak keputusan jika terjadi perubahan prioritas pada kriteria. 2.6.4 Expert Choice 11 2.6.4.1 Latar Belakang Expert Choice Pada tahun 1980an, Expert Choice sudah meluncurkan versi pertamanya dengan tujuan untuk dapat membantu penggunanya dalam pemahaman yang lebih dalam terhadap masalah yang kompleks, seperti masalah alokasi investasi, serta pemilihan vendor. Selama kurang lebih 30 tahun, Expert Choice telah dikembangkan dengan mengikuti teknologi yang juga terus berkembang dan mengikuti kebutuhan dari penggunannya, baik dari segi pemakaian cross-platform, penambahan bahasa, kemudahan pemakaian, dsb.

Gambar 2.4 Konsep Awal Expert Choice (Sumber : www.expertchoice.com)

24 2.6.4.2 Fungsi dan Kelebihan Expert Choice Proses pengambilan keputusan yang lebih baik, yang diikuti dengan hasil yang baik dengan membantu pengguna Expert Choice untuk lebih memahami pilihan keputusan yang sedang dihadapi oleh pengguna. Expert Choice menggabungkan keahlian, intuisi dan data dalam lingkungan yang kolaboratif dalam proses penggunaannya.

Gambar 2.5 Alur Kerja Expert Choice (Sumber : www.expertchoice.com)

Beberapa masalah yang dapat ditangani oleh Expert Choice: - Ketidaksesuaian antara objektif dengan tujuan strategis. - Fokus pada tujuan jangka pendek dengan harga tujuan jangka panjang. - Mengintegrasikan faktor-faktor kualitatif. - Mengintegrasikan pengalaman manajemen.

25 - Mengekstraksi pandangan nyata dari data yang besar. - Konflik cross-departemental. - Kurangnya partisipasi stakeholder. - Kurangnya transparansi dan pelaporan. 2.6.4.3 Penggunaan Expert Choice dalam Pemilihan dan Penilaian Supplier Karena kebanyakan pemilihan vendor/supplier meliputi banyak vendor requirements yang perlu disesuaikan dengan tujuan strategis, EC dibuat untuk membantu pengambil kebutuhan dalam mengatasi batasan kemampuan berpikir manusia dalam mensintesisasi input kualitatif dan kuantitatif dari beberapa stakeholder. Hasilnya adalah analisis dan pemikiran yang dapat dimengerti dan disetujui oleh pihak-pihak dalam organisasi.

Gambar 2.6 Contoh Hierarki AHP Sederhana (Sumber : www.expertchoice.com)

Expert

Choice

juga

memungkinkan

dilakukannya

analisis

sensistifitas (sensitivity analysis), yaitu uji coba atas data yang ada dengan mengubah data tersebut dan melihat apakah ada perubahan pada hasil akhirnya, jika tidak ada perubahan yang signifikan pada hasil akhir, maka hasil analisis dapat dikatakan kokoh atau robust. (Ishizaka & Labib, 2009)

26 2.7 Inventory 2.7.1 Pengertian Inventory Menurut Saxena (2009), inventory didefinisikan sebagai semua jenis sumber daya tak bergerak yang memiliki potensi nilai ekonomi dan dianggap sebagai modal tersimpan. Inventory juga dapat diartikan sebagai daftar barang dan bahan baku atau barang dan bahan baku itu sendiri yang disimpan sebagai persediaan oleh perusahaan. (p. 2) Menurut Heizer & Render (2008), inventory memiliki 4 fungsi utama, yaitu: (p. 500-501) a. Untuk memisahkan bagian-bagian terpisah dari proses produksi. b. Untuk memisahkan perusahaan dari fluktuasi dalam permintaan dan persediaan stock produk yang akan menyebabkan pelanggan untuk memilih supplier lain. c. Untuk mengambil keuntungan dari potongan harga kuantitas, karena pembelian dalam jumlah yang besar dapat mengurangi harga barang atau biaya pengirimannya. d. Untuk membendung inflasi dan kenaikan harga. Adapun macam-macam jenis inventory untuk mengakomodasi fungsifungsinya, antara lain adalah sebagai berikut : • Inventory bahan baku yang sudah dibeli, tetapi belum diproses. • Inventory Work in Process (WIP), di mana beberapa bahan baku sedang diproses, tetapi belum selesai. • Inventory pemeliharaan/perbaikan/operasi (MRO), khusus untuk menjaga agar bahan baku dan fasilitas pendukung produksi tetap berfungsi, sehingga proses produksi terus berjalan. • Inventory barang jadi, produk jadi yang telah selesai diproduksi dan siap untuk dikirimkan ke pelanggan. Beberapa variable cost yang berpengaruh pada inventory, antara lain: 1. Holding cost atau biaya penyimpanan barang di gudang. 2. Ordering cost atau biaya pemesanan barang, termasuk biaya formya yang digunakan, pembelian, dsb. 3. Setup cost atau biaya untuk mempersiapkan mesin atau proses untuk memproduksi.

27 2.7.2 Manajemen Inventory Menurut Saxena (2009), manajemen inventory merujuk pada proses mengelola persediaan barang jadi, setengah jadi, dan bahan mentah oleh perusahaan, yang jika dilakukan dengan benar, dapat menurunkan biaya dan meningkatkan pendapatan bagi perusahaan sendiri. (p. 2) Menurut Heizer & Render (2008), inverntory adalah salah satu aset paling mahal dari semua perusahaan dengan mewakili 50% dari total modal yang diinvestasikan. Perputaran persediaan di inventory berhubungan langsung dengan kepuasan pelanggan yang mungkin turun karena perusahaan kekurangan persediaan.

Oleh

karenanya,

diperlukan

pengelolaan

inventory

untuk

menyeimbangkan antara investasi persediaan dan layanan pelanggan. (p. 500) Terdapat beberapa metode analisis dan pengelolaan inventory bagi perusahaan. Khusus dalam penelitian ini akan digunakan metode model Economic Order Quantity (EOQ), dan Reorder Point (ROP). 2.7.2.1 Model Economic Order Quantity (EOQ) Model EOQ, menurut Heizer & Render (2008), adalah salah satu dari teknik kontrol inventory yang paling banyak digunakan. Teknik ini relatif mudah untuk digunakan, tetapi dibatasi oleh beberapa asumsi, seperti: (p. 507) 1. Permintaan atas produk diketahui, konstan, dan tidak bergantung pad keputusan untuk barang lain. 2. Lead time atau waktu proses antara pemesanan hingga penerimaan barang, diketahui dan konsisten. 3. Penerimaan inventory instan dan lengkap. 4. Potongan harga karena kuantitas dianggap tidak mungkin. 5. Satu-satunya variable cost adalah biaya setup dan pemesanan dan biaya penyimpanan. 6. Kehabisan persediaan dapat dihindari jika pesanan dilakukan pada saat yang tepat.

Economic Order Quantity

Q

Maximum inventory level (order quantity)

Inventory Level

Usage rate

28

Average inventory on hand (Q/2)

0 Maximum inventory level

Time

Gambar 2.7 Perubahan Tingkat Inventory untuk Model EOQ (Sumber : www.transportationfortomorrow.com)

Gambar 2.8 Grafik dari Model EOQ (Heizer & Render, 2008) (Sumber : www.resourcesystemsconsulting.com)

Dalam model ini, jumlah optimal pemesanan (EOQ) akan didapat dari persamaan kedua biaya tersebut. Jumlah optimal pemesanan atau EOQ (Q*) dengan rumus berikut: Q* =

√

2DS H

Dari persamaan di atas, perusahaan juga dapat mencari berapa jumlah pesanan yang dilakukan (N) dan waktu antar tiap pesanan (T) dengan rumus: N =

D Q*

T =

Jumlah hari kerja per tahun N

29 2.7.2.2 Reorder Point Ketika perusahaan sudah mengetahui berapa jumlah optimal barang yang harus dipesan, perusahaan juga harus mengetahui kapan tepatnya melakukan pemesanan ke supplier. (Heizer & Render, 2008) Perusahaan yang hanya memakai model inventory sederhana akan berasumsi bahwa mereka akan melakukan pemesanan ketika persediaan barang di gudang mencapai jumlah 0, dan pesanan akan diterima dengan seger. Asumsi ini dapat menimbulkan waktu antara pemesanan dan penerimaan (lead time), jika pesanan ternyata tiba terlalu lama. Oleh karenanya, ROP penting untuk diketahui dalam proses procurement. ROP didapat dengan mengalikan jumlah permintaan barang per hari (d) dengan lead time (L) untuk kedatangan pesanan. Di mana d didapat dari permintaan per tahun yang diterima perusahaan dibagi jumlah hari kerja efektif perusahaan. ROP = d × L Dari perhitungan ROP inilah nantinya akan didapatkan jumlah unit produk di inventory yang menandakan bahwa perusahaan sudah harus melakukan pemesanan kembali. 2.8 Object-Oriented Analysis and Design (OOA&D) Object-oriented analysis atau analisis berorientasi objek adalah metode analisis yang menggambarkan sistem informasi dengan mengidentifikasi objek. Objek sendiri adalah semua data yang mewakili orang, tempat, peristiwa, atau transaksi. Dan hasil akhir dari object-oriented analysis adalah model objek, yang mewakili sistem informasi dalam konteks objek dan konsep object-oriented. (Shelly & Rosenblatt, 2011, p. 250) Menurut Booch (1982) dalam buku Applying UML and Patterns karangan Craig Larman (2004), object-oriented analysis and design adalah metode, yang dengan menggunakan dekomposisi objek, mendefinisikan notasi dan proses untuk membangun sistem software kompleks, dan menawarkan serangkaian model logikal dan fisikal yang kaya, di mana kita dapat mempertimbangkan aspek berbeda dari sistem. Booch juga menyatakan bahwa object-oriented analysis and design

30 merupakan satu-satunya metode saat ini yang dapat digunakan dalam menghadapi kerumitan yang terdapat pada sistem yang sangat besar. (p. 52) Definisi object-oriented analysis and design dibagi menjadi object-oriented analysis, yaitu metode analisis yang memeriksa kebutuhan dari perspektif class dan objects yang ditemukan dalam problem domain; dan object-oriented design, yaitu metode perancangan yang mencakup proses dekomposisi berbasis objek dan notasi untuk menggambarkan model logikal dan fisikal, serta statis dan dinamis dari sistem dalam suatu rancangan. (Booch, 1982)

Tabel 2.4 Keuntungan dari Pendekatan Object-Oriented. (Dennis et al., 2012) (Sumber : System Analysis and Design, 2012) Concept Classes, objects, methods, and messages

Supports • A more realistic way for people think about their business • Highly cohesive units that contain both data and processes

Encapsulation and information • Loosly coupled units hiding

Leads to • Better communication between user and analyst or developer • Reusable objects • Benefits from having highly cohesive system • Reusable objects • Fewer ripple effects from changes within an object or in the system itself • Benefits from having a loosely coupled system design

Inheritance

• Allows us to use classes as standard templates from which other classes can be built

• Less redundancy • Faster creation of new classes • Standards and consistency within and across development efforts • Ease in supporting exceptions

Polymorphism

• Minimal messaging that is interpreted by objects themselves

• Simpler programming of events • Ease in replacing or changing objects in a system • Fewer ripple effects from changes within an object or in the system itself

Use case driven

• Allows users and analysts to focus on how a user will interact with the system to perform a single activity

• Better understanding and gathering of user needs • Better communication beetween user and analyst

Architectural centric and functional, static, and dynamic views

• Viewing the evolving system from multiple points of view

• Better understanding and modeling of user needs • More complete depiction of information system

Iterative and incremental development

• Continuous testing and refinement of the evolving system

• Meeting real needs of user • Higher quality systems

Satzinger (2012) membagi analisis dan perancangan sistem menjadi analisis sistem dan perancangan sistem. Analisis sistem terdiri dari beberapa aktivitas yang memungkinkan seseorang untuk mengerti dan menspesifikasi apa yang harus dapat dicapai oleh sistem baru. Sedangkan perancangan sistem terdiri dari aktivitas-aktivitas yang memungkinkan seseorang untuk menggambarkan secara rinci tentang sistem yang akan dapat memenuhi kebutuhan. 2.8.1 Unified Modeling Language (UML) Untuk mengembangkan model objek, akan digunakan Unified Modeling Language (UML). Menurut Shelly dan Rosenblatt (2011), UML adalah metode

31 visualisasi dan dokumentasi perancangan sistem software yang umum digunakan, metode ini memiliki konsep perancangan berorientasi objek, tetapi independen terhadap bahasa pemrograman dan dapat digunakan untuk menggambarkan proses dan kebutuhan bisnis secara umum. Menurut

Satzinger

(2012),

UML

adalah

serangkaian

standard

pengembangan model dan notasinya yang ditetapkan oleh Object Management Group (organisasi standarisasi pengembangan sistem), agar analis dan pengguna akhir dapat menggambarkan dan mengerti variasi diagram-diagram spesifik yang digunakan dalam proyek pengembangan sistem. (p. 46) UML menekankan pada 3 dasar untuk pendekatan berorientasi objek dalam mengembangkan sistem informasi, yaitu: (Dennis et al., 2012, p. 511) 1. Penggunaan use case. Artinya use case menjadi alat pemodelan utama yang digunakan untuk mendefinisikan perilaku sistem. Use case menggambarkan bagaimana user berinteraksi dengan sistem untuk melakukan suatu aktivitas, seperti melakukan pemesanan, membuat reservasi, atau mencari informasi. Use case digunakan untuk mengidentifikasi dan mengkomunikasikan kebutuhan sistem kepada programmer yang menulis sistem. 2. Berpusat pada arsitektur. Artinya pokok arsitektur dari mengembangan sistem digerakkan oleh spesifikasi, konstruksi, dan dokumentasi sistem. Terdapat 3 pandangan sistem secara arsitektural yang terpisah, tetapi saling berhubungan, yaitu: • Pandangan fungsional yang menggambarkan perilaku eksternal sistem dari perspektif user. • Pandangan statis yang menggambarkan struktur sistem dalam bentuk attributes, methods, classes, relationships, dan messages. • Pandangan dinamis yang menggambarkan perilaku internal sistem dalam hal message yang disalurkan antar objek dan perubahan status dalam objek. 3. Perulangan dan peningkatan. Penekanan pada pengembangan secara berulang dan meningkat yang dilakukan dengan testing terus menerus sepanjang siklus proyek.

32 Versi terkini dari UML adalah versi 2.0, yang terdiri dari 14 teknik pembuatan diagram untuk pemodelan sistem. Pengelompokan diagram UML 2.0 terbagi menjadi 2 bagian besar, yaitu: (Dennis et al., 2012, p. 513) a. Diagram struktur (structure) Digunakan untuk merepresentasikan data dan hubungan statis yang terdapat dalam sistem informasi. b. Diagram perilaku (behavior) Menyediakan cara untuk menggambarkan hubungan dinamis antara objek yang mewakili sistem informasi bisnis. Tabel 2.5 Rangkuman Diagram UML 2.0 (Dennis et al., 2012) (Sumber : System Analysis and Design; 2012, p. 513) Used to

Diagram Name Structure Diagrams Class Object Package Deployment

Illustrate the relationships between classes modeled in the system. Illustrate the relationships between classes modeled in the system. Function when actual instances of the classes will better communicate the model. Group other UML elements together to form higher level constructs. Show the physical architecture of the system. Can also be used to show software components being displayed onto the physical architecture. Illustrate the physical relationships among the software components.

Component Composite Structure Behavioral Diagrams Activity Sequence Communication Interaction Overview Timing Behavioral State Machine Protocol State Machine Use Case

Illustrate the internal structure of a class. Illustrate business work flows independent of classes, the flow of activities in a use case, or detailed design of a method. Model the behavior of objects within a use case. Focuses on the time-based ordering of an activity. Model the behavior of objects within a use case. Focuses on the communication among a set of collaborating objects of an activity. Illustrate on overview of the flow of control of a process. Illustrate the interaction that takes place among a set of objects and the state changes that they go through along a time axis. Examin the behavior of one class. Illustrate the dependencies among the different interfaces of a class. Capture business requirements for the system and to illustrate the interaction beteen the sustem and its environment.

Primary Phase Analysis, Design Analysis, Design Analysis, Design, Implementation Analysis, Design, Implementation Analysis, Design, Implementation Analysis, Design Analysis, Design Analysis, Design Analysis, Design Analysis, Design Analysis, Design Analysis, Design Analysis, Design Analysis

Dari banyaknya bentuk diagram dalam UML, terdapat 4 bentuk diagram inti yang umum digunakan dalam proyek, yaitu: (Dennis et al., 2012, p. 514) • Use case diagram • Sequence diagram • Class diagram • Behavioral state machine diagram (statechart diagram) Dalam analisis dan perancangan sistem dengan menggunakan UML, ada beberapa istilah yang perlu diketahui dan perlu dibuat sebelum mendapatkan

33 hasil akhir berupa model objek dan sistem e-procurement untuk PT. Elje Perdana, seperti sebagai berikut: • Objects Objects adalah semua data yang mewakili orang, tempat, peristiwa, atau transaksi. • Attributes Attributes adalah sifat-sifat yang menggambarkan karakteristik dari object. • Methods Methods adalah tugas atau tindakan tertentu yang dapat dilakukan oleh object. • Messages Messages adalah perintah yang memicu object untuk melakukan suatu method. • Classes Classes adalah kumpulan dari beberapa object yang memiliki attributes atau methods yang sama. • Relationships Relationships adalah hubungan antar object, di mana object dapat saling berinteraksi satu sama lain. Relationships menggambarkan apa yang harus dilakukan object, bagaimana object merespon perubahan yang terjadi pada object lain, dan bagaimana dampaknya pada classes. 2.8.2 System Analysis Activities System analysis meliputi semua aktivitas-aktivitas dan keputusankeputusan yang berkaitan dengan penemuan dan pemahaman elemen-elemen utama dari user dan system requirements. 2.8.2.1 System Vision Document Sebelum memulai aktivitas analisis sistem, harus dibuat system vision document sebagai dasar pengembangan sistem baru. Menurut

Satzinger

(2012),

system

vision

document

atau

dokumentasi visi sistem dilakukan untuk mengidentifikasi keuntungankeuntungan bagi perusahaan dan kapabilitas fungsional yang akan diikutsertakan dalam sistem. Dokumentasi visi sistem terdiri dari 3 bagian, yaitu:

34 a. Deskripsi permasalahan Berisi gambaran permasalahan ataupun kebutuhan perusahaan yang ingin diatasi oleh sistem nantinya. b. Kapabilitas sistem Rincian kemampuan dan fungsi dari sistem baru dalam bentuk poinpoin. c. Keuntungan bisnis Manfaat yang akan dicapai oleh perusahaan dari penggunaan sistem baru yang akan dikembangkan. Keuntungan yang dihasilkan harus dapat memberikan solusi atas permasalahan yang telah dikemukakan sebelumnya.

2.8.2.2 System Requirements System requirements atau kebutuhan sistem adalah semua aktivitas yang harus dilakukan atau didukung oleh sistem baru dan batasanbatasan yang harus dicapai sistem baru. (Satzinger, 2012, p. 42) System requirements dibagi menjadi 2 kategori, yaitu: (Satzinger, 2012, p. 42-43) 1. Functional requirements atau kebutuhan fungsional Functional requirements adalah aktivitas yang harus dilakukan oleh sistem. 2. Non-functional requirements atau kebutuhan non-fungsional Non-functional requirements adalah karakteristik dari sistem selain aktivitas yang harus dilakukan atau didukung.

Framework yang umum digunakan untuk dapat membedakan antara kebutuhan fungsional dan non-fungsional adalah FURPS. FURPS merupakan singkatan dari aspek-aspek karakteristik dari sistem, yaitu: (Satzinger, 2012, p. 43) • Functionality requirements atau kebutuhan fungsionalitas Aspek ini sama dengan penjelasan functional requirements di atas. • Usability requirements atau kebutuhan kegunaan

35 Menggambarkan karakteristik operasional yang berhubungan dengan user, seperti user interface, prosedur kerja yang berkaitan, fitur online help, dan dokumentasi. • Reliability requirements atau kebutuhan reliabilitas Menggambarkan ketergantungan dari sistem, seberapa sering sistem menunjukan perilaku seperti kekurangan pelayanan dan kesalahan proses, serta bagaimana sistem itu mendeteksi masalah tersebut dan melakukan tindakan recovery. • Performance requirements atau kebutuhan kinerja Menggambarkan karakteristik operasional yang berhubungan dengan kebutuhan beban kerja, seperti throughput dan waktu respon. • Security requirements atau kebutuhan keamanan Menggambarkan bagaimana akses ke aplikasi akan dikontrol dan bagaimana data dapat dilindungi selama proses penyimpanan dan transmisi.

FURPS+ adalah pengembangan selanjutnya dari framework FURPS, yaitu dengan menambahkan beberapa aspek sebagai berikut: (Satzinger, 2012, p. 44) • Design constraint atau batasan desain Menggambarkan batasan-batasan yang harus dipatuhi oleh hardware dan software. • Implementation requirements atau kebutuhan implementasi Menggambarkan

batasan-batasan

seperti

bahasa

dan

tools

pemrograman yang dibutuhkan, metode dokumentasi, tingkat perincian, serta protokol komunikasi spesifik untuk komponen terdistribusi. • Interface requirements Menggambarkan interaksi di antara sistem. • Physical requirements atau kebutuhan fisikal Menggambarkan karakteristik hardware, seperti ukuran, berat, konsumsi tenaga, dan kondisi operasi.

36 • Supportability requirements atau kebutuhan kemampuan dukungan Menggambarkan bagaimana sistem di-install, dikonfigurasikan, diawasi, dan di-update. 2.8.2.3 Use Case dan Use Case Diagram Menurut Satzinger (2012), use case adalah aktivitas yang dilakukan sistem, biasanya sebagai respon dari permintaan user. (p. 69) Terdapat 2 teknik dalam mengidentifikasi use case, yaitu: 1. Teknik tujuan user Identifikasi use case dengan menentukan tujuan spesifik apa yang harus dicapai oleh user.

Tabel 2.6 Contoh Penggunaan Teknik Tujuan User (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 70) User Potential customer

Marketing manager

Shipping personnel

User goal and resulting use case Search for item Fill shopping cart View product rating and comments Add/update product information Add/update promotion Produce sales history report Ship items Track shipment Create item return

2. Teknik dekomposisi event Salah satu teknik untuk mengidentifikasi use case dengan menentukan event-event bisnis eksternal yang harus direspon atau ditangani oleh sistem. Teknik ini dimulai dengan mengidentifikasi semua event bisnis yang akan menyebabkan sistem informasi merespon, dan setiap event menuntun pada use case. Teknik ini berfokus pada indentifikasi event yang harus direspon sistem dan kemudian menentukan bagaimana sistem harus meresponnya. (Satzinger, 2012, p. 70) 3. Teknik CRUD (create, read atau report, update, dan delete)

37 Teknik ini sangat berguna ketika digunakan untuk melakukan crosscheck bersama dengan teknik tujuan user karena teknik memastikan semua kemungkinan teridentifikasi.

Tabel 2.7 Verifikasi Use Case dengan Teknik CRUD (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 77) Data entity/domain class Customer

CRUD Create Read/report Update Delete

Verified use case Membuat account customer Mencari customer Membuat laporan pemakaian customer Memroses penyesuaian account Mengupdate account customer Mengupdate account customer (ke arsip)

Tabel 2.8 Use Case dengan Entity/Domain Class yang Bersangkutan (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 77) Use case vs. entity/domain class Membuat account customer Mencari customer Membuat laporan pemakaian customer Memroses penyesuaian account Mengupdate account customer

Customer C R R R UD (arsip)

Account C R R

Sale

U UD (arsip)

Adjustment

R R

C

Use case diagram sendiri, menurut Satzinger (2012), adalah model UML

yang

digunakan

untuk

menunjukkan

use

case

dengan

hubungannya dengan user secara grafik. Berikut adalah langkah-langkah dalam mengembangkan use case diagram: (Satzinger, 2012, p. 83) 1. Identifikasi semua stakeholder dan user yang akan menerima keuntungan dengan adanya use case diagram. 2. Tentukan apa yang diperlu ditinjau oleh setiap stakeholder atau user dalam sebuah use case diagram. 3. Untuk setiap kebutuhan komunikasi potensial, pilih use case dan aktor yang akan muncul dan gambarkan use case diagram-nya. 4. Beri nama tiap use case diagram dan kemudian berikan catatan bagaimana dan kapan diagram tersebut akan dipakai untuk meninjau use case dengan stakeholder dan user.

38

Create/Update customer account

Request friend linkup

Customer Service Representative

Reply to friend linkup

View “mountain bucks”

Browse messages

Process account adjustmen

Customer

Store Sales Representative

Send message

Transfer “mountain bucks”

Send/receive points

Management

Gambar 2.9 Contoh Use Case Diagram (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 82)

2.8.2.4 Domain Model Class Diagram Domain model class diagram adalah salah satu jenis class diagram yang hanya berisikan class-class dari problem domain saja. Class diagram sendiri adalah diagram yang terdiri dari class-class (contohnya serangkaian object) dan hubungan antar class. (Satzinger, 2012, p. 101) Sedangkan yang dimaksud dengan problem domain, menurut Satzinger (2012), adalah area spesifik (atau domain) dari kebutuhan (atau permasalahan) bisnis user yang termasuk dalam cakupan sistem baru. (p. 92)

39

Customer custNumber name billAddress homePhone officePhone

Order 1

0..* places

OrderItem

orderID orderDate amount

1

1..* Consists of

itemID quantity price

Gambar 2.10 Contoh Domain Model Class Diagram Sederhana (Satzinger, 2012) (Sumber : Systems Analysis and Design in A Changing World, 2012, p. 101)

Hubungan asosiasi dalam domain model class diagram dituliskan dalam notasi UML, seperti Zero or one (optional)

gambar berikut:

0..1 One and only one (mandatory)

1

1..1

Zero or more (optional)

0..* *

Zero or more alternate (optional)

1..*

One and only one alternate (mandatory)

One or more (mandatory)

Gambar 2.11 Notasi Hubungan Asosiasi antar Class (Satzinger, 2012) (Sumber : Systems Analysis and Design in A Changing World, 2012, p. 103)

2.8.2.5 Use Case Description Menurut Satzinger (2012), use case description adalah model tekstual yang mengumpulkan dan menggambarkan detail proses informasi dari setiap use case. Use case description dibuat berdasarkan scenario, yaitu sekumpulan aktivitas internal yang unik dalam use case. Use case description yang lengkap dapat meningkatkan kemungkinan dipahaminya proses bisnis dan cara-cara sistem dalam mendukung proses bisnis tersebut secara keseluruhan. (p. 121-122) Beberapa komponen yang ada dalam sebuah use case description, adalah sebagai berikut: (Satzinger, 2012) 1. Use case name

40 2. Scenario, komponen 1 dan 2 digunakan untuk mengidentifikasi use case dan scenario dalam use case yang sedang didokumentasikan. 3. Triggering event, berfungsi untuk mengidentifikasi event yang memicu use case. 4. Brief description, merupakan deskripsi singkat dari use case atau scenario. 5. Actors, berfungsi untuk mengidentifikasi aktor-aktor dalam use case. 6. Related use cases, berfungsi untuk mengidentifikasi use case lain dan hubungannya dengan use case yang sedang didokumentasikan. 7. Stakeholders,

berfungsi

mengidentifikasi

stakeholder

yang

berkepentingan selain dari aktor-aktor spesifik. 8. Preconditions, mengidentifikasi state atau status dari sistem untuk use case memulai proses, termasuk object apa yang sudah harus ada, informasi apa yang harus tersedia, hingga kondisi aktor sebelum dimulainya use case. 9. Postconditions, mengidentifikasi apa kondisi yang benar setelah use case selesai berjalan. Postconditions penting dituliskan karena membentuk dasar untuk menyatakan hasil yang diharapkan bagi use case

yang

akan

diuji

dan

ketika

diimplementasikan,

serta

mengindikasikan object mana yang terlibat dalam use case yang merupakan object penting dalam perancangan. Komponen ke 8 dan 9 menyediakan informasi kritis tentang state dari sistem sebelum dan sesudah use case dieksekusi. 10. Flow of activites, menggambarkan detail aliran aktivitas dari use case. 11. Exception conditions, berisi kondisi jika aliran aktivitas sebelumnya tidak terpenuhi. Tabel 2.9 Contoh Use Case Description (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 123) Use Case Name: Scenario: Triggering Event: Brief Description:

Membuat customer account. Membuat customer account online. Customer baru ingin membuat account online. Customer online membuat customer account dengan memasukkan informasi dasar dan kemudian diikuti dengan satu atau lebih alamat dan kartu kredit atau debit.

41 Actors: Related Use Cases: Stakeholders: Preconditions:

Postsconditions:

Customer. Mungkin dipicu oleh use case Check out shopping cart. Accounting, Marketing, Sales. Customer account subsystem harus tersedia. Otorisasi kartu kredit/debit harus tersedia. Customer harus dibuat dan disimpan. Satu atau lebih alamat harus dibuat dan disimpan. Informasi kartu kredit/debit harus divalidasi. Account harus dibuat dan disimpan. Alamat dan account harus berhubungan dengan Customer. Actor System 1. Customer mengindikasikan 1.1. Sistem membuat customer keinginan untuk membuat baru. customer account dan 1.2. Sistem meminta alamat memasukkan informasi customer. customer. 2. Customer memasukkan satu atau lebih alamat.

2.1. Sistem membuat alamat. 2.2. Sistem meminta kartu kredit/debit.

3. Customer memasukkan informasi kartu kredit/debit.

3.1. Sistem membuat account. 3.2. Sistem memverifikasi otorisasi untuk kartu kredit/debit. 3.3. Sistem menghubungkan customer, alamat, dan account. 3.4. Sistem mengembalikan detail customer account yang valid.

Flow of Activities:

Exception Conditions:

1.1. Data customer tidak lengkap. 2.1. Alamat tidak valid. 3.2. Informasi kartu kredit/debit tidak valid.

2.8.2.6 Activity Diagram Menurut Satzinger (2012), activity diagram adalah diagram yang menggambarkan berbagai aktivitas user (atau sistem), yaitu pihak yang melakukan setiap aktivitas, dan aliran dari aktivitas-aktivitas tersebut secara berurutan. (p. 57). Activity diagram juga digunakan untuk mendokumentasikan use case. Swimlane heading

Starting activity (Pseudo)_

Transition arrow Activity

Sychronization bar (Split)

Manager

Review financials

Prepare report

Ending activity (Pseudo) Decision activity

Synchronizatio n bar (Join)

42

[no]

Another way to show decision

[yes]

Gambar 2.12 Notasi-Notasi dalam Activity Diagram (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 58) 2.8.2.7 System Sequence Diagram (SSD) Menurut Satzinger (2012), SSD merupakan salah satu bentuk diagram interaksi yang digunakan untuk menggambarkan aliran informasi dari dan keluar dari sistem yang terotomatisasi, oleh karenanya,

SSD

mendokumentasikan

input

dan

output,

serta

mengidentifikasi interaksi antara aktor dan sistem. (p. 126) Beberapa objek atau notasi-notasi yang digunakan dalam sebuah SSD adalah sebagai berikut: a. Actor Digambar dengan figur “orang” seperti pada use case diagram, hanya saja dalam SSD, lebih ditekankan tentang bagaimana aktor berinteraksi dengan sistem dengan memasukkan input dan menerima output. b. Automated system Digambar dengan persegi panjang dengan label :System. Objek ini mewakili keseluruhan sistem yang terotomatisasi. c. Input message Digambar dengan anak panah mengarah ke sistem, mewakili pesan yang dikirim oleh aktor. (format lihat Gambar 2.13) d. Lifeline Digambar dengan garis putus-putus, merupakan perpanjangan dari objek diatasnya dalam sebuah use case. e. Return value Merupakan kebalikan dari input message, dengan anak panah mengarah ke aktor. Mewakili output yang diterima aktor sebagai respon sistem atas input message. f. Optional note Digambarkan dengan lambang dokumen. Biasanya digunakan untuk menuliskan detail isi return value.

43

An object (underfined) representing the automated system

The actor interacting with the system

:System

Clerk An input message

The object lifeline; shows the “sequence” of messages, top to bottom

inquireOnItem (catalogID, prodID, size)

Optional note to explain something in a diagram

Item information

item information: description, price, quantity

A returned value

Gambar 2.13 Contoh dan Penjelasan Notasi dalam SSD (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 127)

g. Loop frame Digambarkan dengan persegi panjang berlabel “loop” yang didalamnya berisi lifeline aktor dan sistem, serta input message dan return value. Notasi ini digunakan saat ada pesan yang dikirimkan berkali-kali.

44

Clerk

Test condition for repeatability

:System

loop for all items

addItem (itemID, quantity) Repeat everything in the rectangle

Description, price, extendedPrice

Gambar 2.14 Contoh Notasi Loop Frame (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 128) h. Opt frame Digambarkan sama seperti loop frame, hanya saja label yang digunakan adalah “opt”. Notasi ini digunakan ketika sebuah pesan atau serangkaian pesan merupakan pesan optional atau berdasarkan logika true/false condition. i. Alt frame Digambar juga sama seperti loop frame dan opt frame, dengan label “alt”. Notasi ini digunakan dengan logika if-then-else.

:System

Customer opt [accessory selected]

addAccessory (anAccessory)

accessoryDetails

45

:System

Sales Clerk alt [taxable item]

addSalesTax (locationCode)

Sales tax details [else]

addTaxExcemptionCode (eCode)

tax excemption details

Gambar 2.15 Contoh Notasi Opt Frame dan Alt Frame (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 130)

Pengembangan SSD yang berdasarkan activity diagram terdiri dari 4 langkah, yaitu: (Satzinger, 2012, p. 132) 1. Identifikasi input message. 2. Gambarkan pesan dari aktor eksternal kepada sistem dengan menggunakan notasi message. 3. Indentifikasi dan tambahkan kondisi khusus pada input message, termasuk perulangan dan true/false condition. 4. Identifikasi dan tambahkan pesan output dari sistem.

2.8.2.8 State Machine Diagram atau Statechart Diagram State dari sebuah object adalah kondisi yang terjadi selama hidup object tersebut ketika object itu memenuhi kriteria tertentu, melakukan suatu action atau tindakan, atau menunggu sebuah event. State merupakan kondisi semi-permanen karena event eksternal dapat menginterupsi dan menyebabkan sebuah object untuk masuk ke state baru. (Satzinger, 2012, p. 132-133) Menurut Satzinger (2012), state machine diagram adalah diagram UML yang digunakan untuk mencatat dan mendokumentasikan

46 informasi state dari sebuah object, termasuk perubahan yang dialaminya, dan state akhirnya. (p. 134)

State indicates a state of being of the object

Off

Transition-name has trigger name, guard, and action-expression.

onButtonPushed [Safety cover closed] / run self-test

On

offButtonPushed

Beginning pseudostate denotes start of state machine diagram

Transition moves the object from the origin state to the destination state

Gambar 2.16 Contoh State Machine Diagram Sederhana (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 134)

Notasi-notasi yang terdapat dalam state machine diagram, adalah: a. Pseudostate Digambar dengan titik hitam yang mewakili titik mulai dari diagram. b. Origin state State dari object sebelum terjadi perubahan. c. Transition Perubahan yang berupa trigger dengan format (trigger name, guardcondition, dan action-expression) d. Destination state State dari object setelah terjadi perubahan. e. Action-expressions Mengindikasikan proses yang harus terjadi sebelum perubahan dapat terjadi dan object yang bersangkutan sampai pada destination state. f. Guard-condition Adalah titik uji berupa true/false condition bagi sebuah transition dan harus dipenuhi sebelum transition atau perubahan dapat terjadi.

Selain notasi-notasi di atas, terdapat 2 jenis kondisi khusus yang dapat terjadi pada sebuah object, yaitu:

47 1. Composite state State yang berisikan state lain dan transition.

On Working Idle

print(document)

Load and print sheets

[finished]

Gambar 2.17 Contoh Composite State (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 136)

2. Concurrency atau concurrent state Kondisi di mana sebuah object mengalami lebih dari satu state dalam waktu yang sama. On

Off

onButtonPushed()

Empty

fill()

Full

flowMsg()

Low

fill() trayEmpty()

Working offButtonPushed()

Idle

print(document)

Load and print sheets

[finished]

Gambar 2.18 Contoh Concurrent State (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 137)

Langkah-langkah dalam mengembangkan state machine diagram adalah sebagai berikut : (Satzinger, 2012, p. 137-139) 1. Tinjau ulang class diagram dan pilih class yang mungkin membutuhkan state machine diagram.

48 2. Untuk setiap class yang dipilih, buat daftar semua status kondisi yang dapat diidentifikasi. 3. Mulai membuat bagian-bagian state machine diagram dengan mengidentifikasi transition yang dapat membuat perubahan terhadap state sebuah object yang sudah teridentifikasi sebelumnya. 4. Urutkan kombinasi perubahan state tersebut dalam urutan yang benar. 5. Tinjau kembali jalur-jalur dalam diagram, cari dan bedakan antara jalur independen dan jalur concurrent. 6. Cari transition tambahan. 7. Perluas setian transition dengan pesan event, guard-condition, dan action-expression yang tepat. 8. Tinjau kembali dan uji coba setiap state machine diagram.

2.8.3 System Design Activities Tujuan dari perancangan sistem adalah untuk mendefinisikan, mengatur, dan membuat struktur komponen dari solusi sistem akhir yang akan bertindak sebagai blueprint untuk pembangunan sistem. (Satzinger, 2012, p. 156) 2.8.3.1 Environment Design Lingkungan di sini adalah semua teknologi yang dibutuhkan untuk mendukung aplikasi software yang sedang dikembangkan. Lingkungan ini meliputi komputer-komputer dan hardware lain yang dibutuhkan dalam eksekusi aplikasi. Lingkungan teknologi bukan hanya tentang hardware saja, komponen penting lainnya juga dibutuhkan, seperti sistem operasi, protokol dan sistem komunikasi, serta software pendukung lainnya. (Satzinger, 2012, p. 163) Perancangan desain arsitektural hardware dan jaringannya dibagi menjadi 2 jenis, yaitu: (Satzinger, 2012, p. 168 & p. 171) 1. Desain penerapan internal, yaitu lingkungan teknologi dalam internal perusahaan. 2. Desain penerapan eksternal, yaitu lingkungan teknologi di luar perusahaan.

49 Untuk perancangan penerapan internal sendiri, terdiri dari 3 jenis arsitektur, yaitu: (Satzinger, 2012, p.168-170) 1. Sistem software berdiri sendiri (stand-alone). Adalah sistem software yang dieksekusi dalam satu komputer tanpa konektivitas secara eksternal dengan Internet atau koneksi jaringan. 2. Sistem berbasis jaringan internal. Adalah sistem software yang dibangun atau dibeli oleh sebuah perusahaan secara eksklusif. Sistem ini terdiri dari beberapa unit komputer, biasanya terhubung satu sama lain dalam sebuah gedung oleh sebuah jaringan, seperti Local Area Network (LAN). Jaringan ini menggambarkan arsitektur client-server sederhana untuk sistem jaringan internal, dimana komputer yang digunakan oleh user disebut client, dan komputer utama disebut server.

Wireless Laptop Client

Printer

Apple Client

Desktop Client Application Server

Database Server

Gambar 2.19 Diagram Jaringan dari Sistem Jaringan Internal (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 169)

3. Arsitektur three-layer client-server. Adalah arsitektur client-server yang membagi sebuah aplikasi menjadi 3 layer atau lapisan utama, yaitu:

50 • User interface atau view layer, yaitu layer yang menerima input user, melakukan format, dan menampilkan hasil proses. • Logic

business

atau

domain

layer,

yaitu

layer

yang

mengimplementasikan aturan-aturan dan prosedur proses bisnis. • Data layer, yaitu layer yang mengatur data yang tersimpan, biasanya dalam satu database atau lebih.

Information request

User request

View Layer Formatted response

Data access request

Data Layer

Domain Layer Data access response

Unformatted response

Gambar 2.20 Contoh Arsitektur Three-Layer (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 170)

Untuk desain penerapan eksternal, komponen yang paling penting adalah jaringan Internet. Konfigurasi dengan menggunakan Internet mirip dengan arsitektur three-layer yang sudah dijelaskan di atas karena hampir semua aplikasi dengan konfigurasi Internet menggunakan arsitektur three-layer. Selain itu, Internet dan teknologi web memberikan alternatif menarik untuk mengimplementasikan sistem informasi yang digunakan oleh customer eksternal dan karyawan organisasi. (Satzinger, 2012, p. 171) Implementasi aplikasi melalui web memiliki beberapa keunggulan dibandingkan

dengan

aplikasi

client-server

tradisional,

seperti:

(Satzinger, 2012, p. 172) • Aksesibitas. Aplikasi berbasis web dapat diakses oleh banyak user potensial, termasuk customer, supplier, dsb. • Komunikasi biaya rendah. Koneksi Internet dapat didapatkan dari berbagai penyedia layanan Internet dengan biaya yang relatif rendah. • Standar yang terimplementasi secara luas. Standar web sudah dikenal luas, dan banyak tenaga profesional dibidang komputasi sudah terlatih.

51

Selain keunggulan-keunggulan seperti di atas, terdapat beberapa aspek masalah dari penyampaian aplikasi melalui teknologi Internet dan web, seperti berikut: (Satzinger, 2012, p. 172) • Keamanan. Hal ini menjadi salah satu masalah paling serius karena standar web yang terbuka dan diketahui secara luas. Perlindungan harus disediakan untuk sistem utama, termasuk data, dan ketika data ditransmisikan melalui Internet. • Input atau output yang diberi atau diterima dalam sebuah proses atau sistem. Ketika muatan besar dibebankan ke sistem, aliran input-output dan waktu respon dapat terbebani dengan signifikan. • Standar yang terus berubah. Standar web berubah dengan cepat, bahkan beberapa software client diperbaharui tiap beberapa bulan. 2.8.3.2 Design Class Diagram Menurut Satzinger (2012), design class diagram merupakan pengembangan dari problem domain class diagram, dengan ditambah desain informasi yang digunakan untuk mendokumentasikan elemen perancangan dari class-class software. (p. 298) Karena banyaknya jenis-jenis design class yang diidentifikasi saat proses desain, UML menyediakan notasi khusus, yaitu stereotype. Stereotype adalah cara mengelompokkan elemen model ke tipe tertentu. Notasi ini dituliskan dengan simbol “<>”. (p. 309) Beberapa jenis stereotype, antara lain: (Satzinger, 2012, p. 309) a. Entity class, yaitu identifier desain untuk problem domain class. Class ini juga biasanya berupa persistent class, yaitu class dengan object yang ada setelah program keluar. b. Boundary class atau view class, yaitu class yang secara spesifik dibuat untuk memberikan batasan automasi sistem. c. Control class, yaitu class yang menghubungkan boundary class dengan entity class.

52 d. Data access class, yaitu class yang digunakan untuk mengambil dan mengirim data dari dan ke database.

Dalam membuat design class diagram, biasanya akan dibuat firstcut class diagram terlebih dahulu, yang berisi nama class dan attribute, serta arah hubungan antar class. Setelah itu, baru dibuat design class diagram yang lebih detail (contoh : menggunakan CRC cards) dengan menambahkan function-function dari class yang berkaitan. (Satzinger, 2012, p. 312-317)

Student studentID name address dataAdmitted lastSemesterCredits lastSemesterGPA totalCreditHours totalGPA major

Student -studentID: integer {key} -name: string -address: string -dataAdmitted: date -lastSemesterCredits: number -lastSemesterGPA: number -totalCreditHours: number -totalGPA: number -major: string +createStudent (name, address, major): Student +createStudent (studentID): Student +changeName (name) +changeAddress (address) +changeMajor (major) +getName ( ) : string +getAddress ( ) : string +getMajor ( ) : string +getCreditHours ( ) : number +updateCreditHours ( ) +findAboveHours (int hours): studentArray

Elaborated attributes

Method signatures

Gambar 2.21 Bentuk Design Class Diagram (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 305)

2.8.3.3 Sequence Diagram Menurut Satzinger (2012), sequence diagram adalah salah satu bentuk dari 2 jenis interaction diagram. Sequence diagram adalah jenis interaction diagram yang menekankan pada urutan pesan yang dikirimkan antar object dalam suatu use case yang spesifik. Jenis lain dari interaction diagram adalah communication diagram yang lebih menekankan pada onject yang mengirimkan dan menerima pesan untuk suatu use case spesifik. (p.332)

53 Pada perancangan sistem untuk PT. Elje Perdana sendiri akan digunakan sequence diagram. Dalam proses perancangan sistem berorientasi objek, terutama berkaitan

dengan

use

case

yang

sudah

dibuat

sebelumnya,

pengembangan interaction diagram digunakan untuk menentukan object mana saja yang berkolaborasi dan pesan yang saling dikirimkan untuk menjalankan suatu use case. (Satzinger, 2012, p. 332) Sequence diagram merupakan pengembangan dari SSD yang telah dibuat sebelumnya dalam aktivitas analisis sistem. Perbedaan SSD dengan sequence diagram yaitu dalam SSD sistem diperlakukan sebagai object tersendiri (:System) dan SSD hanya memiliki 2 lifeline (aktor dan sistem). (Satzinger, 2012, p. 332)

<> :CustomerHandler

:CustomerForm

Clerk

createNewCustomer (name, phones, email) createNewCustomer (name, phones, email)

aC:=createNewCustomer (name, phones, email)

aC:Customer

(custID, name, phones, email) SQL Insert enterAddress (address) enterAddress (address) enterAddress (address) (updated address)

enterCreditCard (cc-info) enterCreditCard (cc-info) enterCreditCard (cc-info) (updated cc-info)

Gambar 2.22 Bagian Sequence Diagram dari 1 Use Case (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 334)

54

:CustomerDA

Customer

aC:Customer

:CartHandler

:ProductItemDA

:PromoOfferingDA

aC:=findCustomer (acctNo) addItemToCart (promoNo, prodID, size, color, qty)

aC:=readCust (acctNo)

:ProductItem

:InventoryItemDA

:InventoryItem

:PromoOffering :OnlineCartDA

[firstItem]createCart()

aCrt:=CreateCart () :aCrt:OnlineCart

addItemToCart (promoNo, prodID, size, color, qty)

:OnlineCartDA

createItemToCart (promoNo, prodID, size, color, qty)

:aCrt:CartItem

findPromo (promoID, prodID) readPO()

price := getPrice () findProdItem (prodID) readProd() description := getDesc ()

findInvItem (prodID, size, color) readInv() status := updateQty (qty) (description, price, extendedPrice) saveCartItem (aCI)

(description, price, extendedPrice) saveCartItem (aCI) (description, price, extendedPrice)

Gambar 2.23 Contoh Sequence Diagram Multilayer (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 346) Pada sequence diagram seperti pada Gambar 2.23 di atas, juga terdapat satu notasi baru, activation lifeline, yaitu representasi dari periode ketika method dari satu object dieksekusi dan sedang berjalan. (Satzinger, 2012, p. 335) 2.8.3.4 User Interface dan System Interface Menurut Satzinger (2012), interface dalam sebuah sistem terdiri dari 2 jenis, yaitu: (p. 189) 1. User interface atau UI. Jenis interaksi yang meliputi input dan output yang lebih melibatkan user secara langsung. UI dapat diperuntukkan bagi user internal atau eksternal. Desainnya juga bervariasi tergantung pada beberapa faktor, seperti tujuan UI, karakteristik user, dan karakteristik alat interaksi tertentu. 2. System interface. Jenis interaksi yang meliputi input dan output yang membutuhkan intervensi user secara minim. System interface dapat berupa input

55 yang diterima secara otomatis oleh alat input spesial seperti scanner, pesan elektronik dari atau kepada sistem lain, atau transaksi yang diterima oleh sistem lain. Perancangan berpusat pada user adalah satu teknik perancangan user interface yang memberlakukan interaksi user adalah bentuk sistem secara keseluruhan. Teknik ini sendiri menekankan pada 3 prinsip penting, yaitu: (Satzinger, 2012, p. 189) • Fokus awal pada user dan pekerjaannya. • Evaluasi desain untuk memastikan usability. • Penggunaan pengembangan yang berulang.

Perceptual aspects Physical aspects

Colors, shapes, textures, fonts, sounds, speech, windows, menus, buttons.

Desk, chair, light, keyboard, mouse, touch screen, Keypad.

Conceptual aspects Customers, partners, friends, orders, shipments, inquiries, feedback, ratings.

Gambar 2.24 Konsep Teknik Perancangan Berpusat pada User (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 190)

Konsep dalam perancangan UI terdiri dari beberapa aspek, sebagai berikut: (Satzinger, 2012, p. 193-197) 1. Affordance dan visibilitas Affordance

artinya

adalah

tampilan

dari

kontrol

tertentu

mencerminkan fungsinya atau tujuan kontrol tersebut digunakan. Sedangkan visibilitas artinya suatu kontrol terlihat sehingga user tahu jika kontrol tersebut tersedia, atau dapat juga berarti kontrol tersebut

56 menyediakan feedback dengan segera untuk mengindikasikan bahwa sistem atau kontrol tersebut meresepon aksi user.

Gambar 2.25 Aspek Affordance dan Visibilitas dalam UI Kontrol (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 193)

2. Konsistensi Bagaimaan informasi disusun dalam form, nama dan peletakan item menu, ukuran dan bentuk dari ikon, dan urutan yang dilakukan untuk melakukan sebuah proses yang harus konsisten di seluruh sistem. 3. Shortcut User yang bekerja dengan sebuah aplikasi secara berulang atau dalam periode waktu yang lama menginginkan shortcut untuk function yang digunakan secara terus-menerus, yang dapat mengurangi jumlah tombol yang diketik, klik mouse, dan pemilihan menu yang dibutuhkan untuk melakukan sebuah tugas. 4. Feedback Feedback dibutuhkan agar user dapat tahu bahwa sistem telah mengenali aksi yang dilakukan user. Feedback dapat berupa suara (bunyi klik, dsb), dan visual (perubahan ikon, dsb). 5. Dialog yang memberikan hasil akhir. Semua tugas yang didefinisikan dengan baik memiliki awal, pertengahan, dan akhir, sehingga tugas yang dilakukan user juga harus memiliki hal yang sama agar user tidak kebingungan. 6. Penanganan error

57 Desain UI yang baik dapat mengantisipasi error yang biasa terjadi dan dapat membantu user untuk menghindarinya. Ketika error terjadi, UI membutuhkan suatu mekanisme untuk mendeteksinya, memberikan informasi error, dan atau menyediakan cara untuk memperbaikinya jika memungkinkan. 7. Pembatalan aksi yang mudah User dapat mengeksplorasi pilihan-pilihan dan melakukan aksi yang dapat dibatalkan atau dikembalikan tanpa kesulitan. Hal ini dapat menjadi salah satu cara user mempelajari tentang sistem dengan bereksperimen. 8. Pengurangan beban memory jangka pendek Pembuat UI harus menghindari hal-hal yang membuat user harus mengingat semua isi satu form ke form lain selama interaksi dengan sistem. Beberapa panduan dalam merancang window dan form, antara lain: (Satzinger, 2012, p. 201-203) a. Format dan layout interface (konsistensi, label dan heading, distribusi dan urutan, serta font dan warna) b. Input data (text box, list box, combo box, radio button, check box) c. Navigasi dan kontrol support (tombol minimize, maximize, dan close) Beberapa pertimbangan dalam merancang UI web browser, yaitu: (Satzinger, 2012, p. 204-206) a. Konsistensi Penting karena kebanyakan situs memiliki banyak halaman yang menyediakan banyak tujuan berbeda dan melayani pengguna yang berbeda. Konsistensi dalam UI web dapat dicapai dengan penggunaan CSS (Cascading Style Sheets), yaitu standar kode halaman web yang memungkinkan spesifikasi bagian dari halaman akan terlihat sama dan beberapa bagian akan bervariasi sesuai dengan tugas dan pengguna. b. Pertimbangan performa Situs web dan form berbasis browser pada umumnya sensitif terhadap desain aplikasi dan kualitas koneksi jaringan antara komputer user dan server yang menyediakan situs.

58 c. Gambar, video, dan suara UI berbasis web juga disukai karena kemampuannya dalam mengkombinasikan teks, gambar, dan suara, terutama dalam sistem yang berhadapan dengan customer. Tetapi penggunaan suara dan gambar yang berat dapat memperburuk masalah performa yang ada dan juga menciptakan masalah kompatibilitas. d. Pengguna dengan keterbatasan Karena web adalah sumber yang fundamental dalam dunia modern, beberapa standar sudah dikembangkan untuk memastikan kemampuan penggunaan maksimal bagi user yang memiliki keterbatasan penglihatan atau keterbatasan fisik lain. Hal ini dapat dibantu dengan software tambahan seperti text-to-speech, dan teknologi bantuan lainnya.

Pertimbangan tambahan untuk perancangan UI peralatan mobile, yaitu: (Satzinger, 2012, p. 207) • Ukuran layar yang kecil • Ukuran keyboard yang kecil dan layar sentuh • Kapasitas jaringan yang terbatas • Pedoman-pedoman dan toolkit desain aplikasi

Gambar 2.26 Contoh UI Aplikasi Mobile (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 207)

59 Dalam interface sistem sendiri terdapat beberapa jenis input dan output, seperti berikut: (Satzinger, 2012, p. 208) 1. Input dari dan output ke sistem lain. 2. Input dan output terotomatisasi. 3. Input dan output dari database eksternal.

External Database

External Database

Our System

External System External System

Interactive data entry

Interactive queries & reports

Gambar 2.27 Cakupan Input dan Output dalam Sistem Informasi (Satzinger, 2012) (Sumber : System Analysis and Design in a Changing World, 2012, p. 209) Dalam merancang system interface harus berfokus pada 3 area, yaitu: (Satzinger, 2012, p. 210) a. Identifikasi perangkat dan mekanisme yang akan digunakan untuk melakukan input. b. Identifikasi semua input sistem dan pengembangan daftar dengan isi datanya. c. Penentuan jenis kontrol yang diperlukan untuk setiap input sistem.

Menurut Satzinger (2012), agar dapat mencapai input dan output data yang bebas dari kesalahan, dapat diterapkan beberapa hal seperti berikut: (p. 210)

60 • Menggunakan peralatan elektronik otomatis kapanpun. • Menghindari keterlibatan manusia sebanyak mungkin. • Menggunakan

informasi

dalam

bentuk

elektronik

daripada

memasukkan informasi ulang jika mungkin. • Memvalidasikan dan memperbaiki informasi pada waktu dan lokasi ketika informasi tersebut dimasukkan. Untuk output dari sistem, menurut Satzinger (2012), memiliki tujuan untuk menyediakan informasi pada tempat yang tepat, waktu yang tepat, dan kepada orang yang tepat, yang berfokus pada 4 area, yaitu: (Satzinger, 2012, p. 211-212) 1. Penentuan jenis dari tiap output sistem. 2. Pembuatan daftar output sistem yang dibutuhkan berdasarkan desain aplikasi. 3. Spesifikasi semua kontrol yang dibutuhkan untuk melindungi informasi yang disediakan dalam output. 4. Perancangan dan percobaan layout output. 2.8.3.5 Database dan Database Management System (DBMS) Database adalah kumpulan data yang terhubung secara logikal berikut deskripsi yang dapat dibagi dan disebarkan, yang dibuat untuk memenuhi kebutuhan informasi sebuah organisasi. Database berupa sebuah penyimpanan data yang besar yang dapat digunakan secara bersamaan oleh beberapa departemen dan user. (Connolly & Begg, 2010) Database Management System (DBMS) sendiri adalah software yang berinteraksi dengan program aplikasi user dan database. Bahasa query yang paling banyak digunakan adalah Structured Query Language (SQL), yang juga merupakan bahasa standar untuk relasional DBMS atau RDBMS. (Connolly & Begg, 2010)

61 Database system Data entry and reports

Sales

PropertyForRent, PropertyForRent PrivateOwner, Client, PrivateOwner Client and Lease details + File definitions

Sales application programs

DBMS Database

Data entry and reports

Contracts

Contracts application programs

PropertyForRent (propertyNo, street, city, postcode, type, rooms, rent, ownerNo) PrivateOwner (ownerNo, fName, lName, address, telNo) Client (clientNo, fName, lName, address, telNo, prefType, maxRent) Lease (leaseNo, propertyNo, clientNo, paymentMethod, deposit, paid, rentStart, rentFinish)

Gambar 2.28 Proses Database (Sumber : Database Systems, 2010, p. 17) Programmers

Users

DBA

Application programs

Queries

Database schema

DML preprocessor

Query processor

DDL compiler

Program object code

Database manager

Catalog manager

Access methods

File manager

DBMS

System buffers Database and system catalog

Gambar 2.29 Komponen Utama dari DBMS (Sumber : Database Systems, 2010, p. 77)

CARDINALITY

RELATION

62

Model relasional dibuat dalam bentuk tabel, digunakan untuk menyimpan informasi tentang object yang akan direpresentasikan dalam database.

Tabel 2.10 Contoh Model DBMS Relasional dalam Bentuk Tabel (Sumber : Database Systems, 2010, p. 77) ATTRIBUTES

BRANCH branchNo B005 B007 B003 B004 B002

street 22 Deer Rd 16 Argyll St 163 Main St 32 Manse Rd 56 Clover Dr

City London Aberdeen Glasgow Bristol London

postcode SW1 4EH AB2 3SU G11 9QX B599 1NZ NW10 6EU DEGREE

PRIMARY KEY

FOREIGN KEY

STAFF

R E L A TI

staffNo SL21 SG37 SG14 SA9 SG5 SL41

Attribute

fName John Ann David Mary Susan Julie

Domain Name

lName White Beech Ford Howe Brand Lee

Meaning

Position Manager Assistant Supervisor Assistant Manager Assistant

sex M F M F F F

DOB 1-Oct-45 10-Nov-60 24-Mar-58 19-Feb-70 3-Jun-40 13-Jun-65

salary 30000 12000 18000 9000 24000 9000

branchNo B005 B003 B003 B007 B003 B005

Domain Definition

63 branchNo street city postcode sex DOB

BranchNumbers StreetNames CityNames Postcodes Sex DatesOfBirth

The set of all possible branch numbers The set of all street names in Britain The set of all city names in Britain The set of all postcodes in Britain The sex of a person Possible values of staff birth dates

salary

Salaries

Possible values of staff salaries

character: size 4, range B001-B999 character: size 25 character: size 15 character: size 8 character: size 1, value M or F Date, range from 1-Jan-20, format dd-mmm-yy monetary: 7 digits, range 600040000

2.9 Kerangka Pemikiran TOPIK e-Procurement

OBJEK PENELITIAN PT. Elje Perdana

METODOLOGI PENELITIAN Observasi Studi Pustaka Wawancara

ANALISIS DATA

PERANCANGAN SISTEM

Analytic Hierarchy Process

Object-Oriented Analysis &

64 Design dengan UML

Economic Order Quantity Reorder Point

KESIMPULAN Sistem e-Procurement