BAB 2 LANDASAN TEORI. komponen yang saling berhubungan yang bekerja sama menuju suatu tujuan dengan

Transkripsi

1 BAB 2 LANDASAN TEORI 2.1 Teori teori Dasar/Umum Pengertian Sistem Informasi Sistem menurut O Brien (2001, p8) merupakan kumpulan dari komponen komponen yang saling berhubungan yang bekerja sama menuju suatu tujuan dengan menerima input dan menghasilkan output melalui proses transformasi yang terorganisir. Sistem menurut Mathiassen et al (2000, p9) mengatakan bahwa sistem adalah sekumpulan komponen yang mengimplementasi persyaratan modelling, functions, dan interfaces. Dari pengertian pengertian tersebut, dapat disimpulkan bahwa pengertian sistem secara umum adalah sekumpulan komponen yang saling terintegrasi yang mengimplementasi persyaratan modelling, functions dan interfaces untuk mencapai suatu tujuan melalui transformasi. Informasi menurut Mcleod (2001, p15) adalah data yang telah diproses atau data yang memiliki arti. Laudon dan Laudon (2003, p7) mengatakan bahwa informasi adalah data yang telah diubah menjadi suatu bentuk yang lebih berarti dan berguna bagi manusia. Berdasarkan definisi definisi di atas dapat disimpulkan bahwa informasi merupakan data yang mengalami pemrosesan sehingga menjadi lebih berguna bagi pihak yang membutuhkan. Sistem Informasi menurut Laudon dan Laudon (2003, p7) adalah komponen komponen yang saling berhubungan dan bekerja sama untuk mengumpulkan, memproses, menyimpan dan mendistribusikan informasi untuk mendukung pengambilan keputusan, koordinasi, kontrol, analisis, dan visualisasi dalam suatu organisasi. Sistem informasi dapat berupa kombinasi sumber daya sumber daya yang terorganisir dari 6

2 manusia, perangkat keras, piranti lunak, jaringan komunikasi, dan data yang mengumpulkan, mengubah, dan mendistribusikan informasi pada suatu organisasi (O Brien, 2001, p7). Jadi Sistem Informasi adalah sekumpulan komponen yang saling berinteraksi guna mengumpulkan, memproses, menyimpan dan mendistribusikan informasi dalam suatu organisasi Pengertian Sistem Informasi Manajemen Menurut Laudon dan Laudon (2003, p43) Sistem Informasi Manajemen adalah Sistem Informasi pada tingkat fungsi manajemen dengan menyediakan laporan-laporan untuk manajer atau dengan akses langsung ke dalam kegiatan terakhir dan data-data sebelumnya. Sistem Informasi Manajemen menyediakan informasi dalam bentuk laporan dan menyajikannya bagi manajer dan para profesional bisnis (O Brien, 2001, p29). Berdasarkan pengertian-pengertian di atas, dapat ditarik kesimpulan bahwa Sistem Informasi Manajemen adalah Sistem Informasi yang menyajikan informasi berupa laporan untuk mendukung pihak manajemen Pengertian Analisis Sistem Analisis sistem menurut McLeod (2001, p190) adalah penelitian atas sistem yang telah ada dengan tujuan untuk merancang sistem baru atau diperbarui. Analisis lebih menekankan pada penyelidikan atas suatu masalah daripada bagaimana sebuah solusi didefinisikan (Larman, 1998, p6). Dari beberapa pendapat di atas, maka dapat disimpulkan bahkan analisis sistem secara umum adalah penelitian atas sistem yang telah ada dengan lebih menekankan pada masalahnya untuk mendapatkan informasi yang diperlukan guna merancang sistem yang baru. 7

3 2.1.4 Pengertian Perancangan Sistem Rancangan sistem adalah penentuan proses dan data yang diperlukan oleh sistem baru (McLeod, 2001, p192). Dalam bukunya, Whitten et al (2001, p13) mengatakan bahwa perancangan sistem merupakan spesifikasi atau konstruksi dari solusi teknikal berbasis komputer bagi persyaratan bisnis yang diidentifikasikan dalam analisis sistem. Dengan demikian, dapat disimpulkan bahwa perancangan sistem adalah penentuan spesifikasi yang diperlukan oleh sistem baru sebagai solusi teknikal dari permasalahan yang diidentifikasikan dalam analisis sistem Object-Oriented Dari tahun 1950 sampai dengan tahun 1970-an, perusahaan-perusahaan menekankan proses saat mengembangkan Sistem Informasi dan menggunakan alat-alat pembuatan model proses seperti bagan arus (flowchart) dan diagram arus data (Data Flow Diagram). Selama tahun 1970-an dan 1980-an, penekanan bergeser ke data, dengan menggunakan diagram hubungan entitas (Entitas Reationship Diagram ERD) dan kamus data. Selama tahun 1990-an, kecenderungan berubah ke mengkombinasikan proses dan data menjadi object (McLeod, 2001, p330). Keuntungan Object-Oriented menurut Mathiassen et al (2000, p5-6) adalah : 1. Merupakan konsep umum yang dapat digunakan untuk memodelkan hampir semua fenomena yang ada di dunia dengan menggunakan bahasa alami. - Noun menjadi object atau class - Verb menjadi behavior - Adjective menjadi attributes 2. Menyediakan informasi yang jelas mengenai context dari sistem 8

4 3. Mengurangi biaya maintenance atau development Object-Oriented Analysis and Design (OOA&D) Object-Oriented Analysis and Design (OOA&D) berusaha untuk menggabungkan data dan proses menjadi suatu gagasan tunggal yang diebut objects. OOA&D memperkenalkan object diagrams yang mengdokumentasikan sistem dipandang dari segi objects dan interaksinya (Whitten et al, 2001, p97). Menurut Larman (1998, p6) intisari dari OOA&D adalah penekanan pada pertimbangan Problem Domain dan solusi logis dari persepsi objects (sesuatu, konsep, entitas). Menurut Mathiassen et al (2000, pp14-15) terdapat 4 aktivitas utama dalam OOA&D, yaitu Problem Domain Analysis, Application Domain Analysis, Architectural Design, dan Component Design. 9

5 System Definition Problem Domain Analysis - Classes - Structure - Behavior Application Analysis - Usage - Functions - Interface Requirements for use Model Component Design - Model Component - Function Component - Connecting Component Spesification of architecture Spesifications of components Architectural Design - Criteria - Components - Processes Gambar 2.1 Aktivitas utama dalam OOA&D (Mathiassen et al, 2000, p15 & p332) System Choice Sebuah proyek pengembangan berawal dari berbagai macam ide yang berbeda tentang sistem yang diinginkan. System Choice didasarkan pada tiga subaktivitas. Subaktivitas yang pertama dipusatkan pada tantangan-tantangan, kita mencoba mendapatkan kedua gambaran umum dari situasi dan berbagai cara orang-orang menginterpretasikannya. Subaktivitas yang kedua adalah menciptakan dan mengevaluasi ide-ide untuk perancangan sistem. Metode kita menawarkan berbagai urutan teknikteknik untuk mendukung kreativitas dan memperkenalkan cara baru dalam berpikir. Dalam aktivitas yang ketiga, kita memformulasikan dan memilih system definition, 10

6 membicarakan dan mengevaluasi alternatif system definitions dalam hubungannya pada situasi yang kita hadapi (Mathiassen et al, 2000, p25) System Definition System definition merupakan deskripsi singkat dari sebuah sistem komputerisasi yang dinyatakan dalam bahasa alami (Mathiassen et al, 2000, p24). Sebuah system definition menyatakan bagi pengembangan sistem dan penggunaannya. Yang juga menggambarkan sistem dalam hubungannya, informasi apa yang harus dikandungnya, fungsi mana yang harus disediakan, dimana akan digunakan dan kondisi pengembangan apa yang akan diterapkan. System definitions dapat membantu untuk menampung pandangan umum dari pilihan yang berbeda-beda, dan bisa digunakan untuk perbandingan alternatif. System definition yang akhirnya dipilih harus menyediakan landasan-landasan yang baik untuk kelangsungan analisa dan aktivitas perancangan Problem Domain Analisys Pada tahap ini dilakukan pengidentifikasian informasi-informasi yang harus ada pada suatu sistem untuk menghasilkan sebuah model sistem. Problem Domain merupakan bagian dari keadaan yang akan diatur, dipantau, dan dikontrol oleh sistem (Mathiassen et al, 2000, p6). Sumber dari aktivitas ini adalah system definition, yaitu deskripsi singkat dan jelas dari sistem terkomputerisasi dengan menggunakan bahasa alami (Mathiassen et al, 2000, p24). Terdapat tiga subaktivitas yang harus dilakukan untuk membuat system definition, yaitu usaha untuk mendapatkan pandangan menyeluruh dari situasi, membuat dan 11

7 mengevaluasi ide-ide untuk pendesainan sistem, dan diakhiri dengan memformulasi dan mengevaluasi system difinition sesuai dengan situasi yang ada (Mathiassen et al, 2000, p25). Rich Picture dapat memperjelas pandangan user mengenai situasi, permasalahan, dan mendapatkan pandangan keseluruhan situasi dengan cepat, Rich Picture adalah gambar informal yang mempresentasikan pemahaman ilustrator mengenai situasi (Mathiassen et al, 2000, p26). Menurut Cosgrave, Rich Picture menggambarkan orang-orang yang terlibat, tujuan, keinginan dan ketakutan mereka (biasanya dalam balon-balon pikiran). Rich Picture juga menggambarkan detil lingkungan dengan lebih banyak dibanding kebanyakan diagram (aktivitvas manusia, seperti proses-proses, melewati batas organisasional), serta menggambarkan bagaimana elemen-elemen sejalan atau bertentangan. Rich Picture adalah kartun rich picture bisa lucu, sedih, politikal dan lebih baik lagi jika semuanya menjadi satu. Berikut ini merupakan karakteristik dari rich picture : 1. Harus diungkapkan sendiri dan mudah dimengerti 2. Tidak ada cara yang benar dalam menggambarkan rich picture karena merupakan proses yang subjektif 3. Tidak terstruktur 4. Bagian-bagiannya meliputi fakta, benda, orang, aktor eksternal, hubungan, pertentangan, kebingunan. 5. Perlu mengidentifikasi tugas utama bagi sistem Mathiassen (2000, pp39-40) menulis bahwa di dalam system definition terdapat enam elemen kriteria FACTOR, yaitu : 12

8 1. Functionality : fungsi-fungsi sistem yang mendukung tugas-tugas Application Domain 2. Application Domain : bagian dari organisasi yang mengatur, memonitor atau mengontrol suatu Problem Domain. 3. Conditions : kondisi dimana suatu sistem dikembangkan dan digunakan 4. Technology : teknologi yang digunakan untuk mengembangkan sistem dan teknologi saat sistem dijalankan 5. Objects : object-object utama di dalam Problem Domain 6. Responsibility : tanggung jawab seluruh sistem dalam hubungannya dengan konteks. Mathiassen (2000, pp46-47) di dalam bukunya menulis bahwa terdapat tiga subaktivitas dalam Problem Domain Analysis, yaitu : System Definition Classes Behavior Model Structure Gambar 2.2 Aktivitas dalam Problem Domain Analysis (Mathiassen et al, 2000, p46) 13

9 1. Classes Merupakan tahapan dilakukannya pemilihan class dan event dari system definition untuk menghasilkan event table. Class adalah deskripsi dari kumpulan object yang mempunyai structure, behavioural pattern, dan attributes yang sama. Object adalah suatu entitas yang memiliki identity, state, dan behaviour (Mathiassen et al, 2000, p4). Pada tahap analisis, biasanya sebuah class cukup dideskripsikan dengan namanya saja, tetapi dapat juga ditambahkan detail attributes dan operation. Event adalah kejadian bersifat instan yang melibatkan satu atau lebih object (Mathiassen et al, 2000, p51). Class Object : Class Class -attribute +operation() Class with attributes and operation Gambar 2.3 Notasi dasar dari class ( Mathiassen et al, pp ) Menurut Mathiassen et al (2000, pp53-55) untuk menjalankan aktivitas classes dapat dimulai dengan mengidentifikasikan kandidat/calon yang mungkin untuk classes dan events dalam model Problem Domain. Setelah itu, evaluasi dan pilih secara kritis classes dan events yang benar-benar relevan dengan konteks sistem. 2. Structure Tujuannya adalah untuk mendeskripsikan hubungan struktural antara class dan object. Sumber dari tahap ini adalah event table yang dihasilkan dari tahap sebelumnya, sedangkan hasil akhirnya adalah membuat Class Diagram, yaitu diagram yang menyediakan gambaran ikhtisar Problem Domain yang bertalian secara logis dengan menggambarkan seluruh hubungan struktural antara classes dan objects di dalam model (Mathiassen et al, 2000, pp69-70). 14

10 Vehicle Truck Ow ner * 1 1 * Wheel Gambar 2.4 Class Diagram Menurut Mathiassen et al (2000, pp72-77) terdapat dua tipe structure dalam Object-Oriented, yaitu : 1. Class Structure, mengekspresikan hubungan konseptual yang statis antar class. Hubungan statis ini tidak akan berubah, kecuali terjadi perubahan pada deskripsinya. Class structure dibagi menjadi dua macam, yaitu : a. Generalization Structure, merupakan hubungan antara dua atau lebih subclass dengan satu atau lebih superclass (Mathiassen et al, 2000, p72). Sebuah class yang umum (superclass) mendeskripsikan properti umum kepada group dari spesial class (subclass). Atau dengan kata lain, terjadi penurunan attributes dan behaviour dari superclass, tetapi subclass juga diperkenankan untuk memiliki attributes dan behaviour tambahan. Secara ilmu bahasa, generalization structure diekspresikan dengan formula is a. 15

11 Passenger Car Taxi Private Car Gambar 2.5 Generalization Structure (Mathiassen et al, 2000, p73) b. Cluster, merupakan kumpulan dari class yang berhubungan (Mathiassen et al, 2000, p74). Cluster digambarkan dengan notasi file folder yang melingkupi class-class yang saling berhubungan di dalamnya. Class-class dalam satu cluster biasanya memiliki hubungan berupa generalization atau aggreagation. Sedangkan hubungan class dengan cluster yang berbeda biasanya berupa association structure. <<cluster>> Generalization Gambar 2.5 Notasi Class Structure (Mathiassen et al, 2000, p337) 16

12 <<Clusters>> Cars <<Clusters>> People Car Owner Engine Passenger Car Clerk Cylinder Taxi Gambar 2.6 Cluster Stucture (Mathiassen et al, 2000, p75) 2. Object Structure, mengekspresikan hubungan dinamis dan konkret antar object. Hubungan ini dapat berubah secara dinamis tanpa mempengaruhi perubahan pada deskripsinya. Biasanya terdapat multipicity yang menspesifikasikan jumlah dari object yang berelasi. Multiplicity dapat berupa string of numbers dan penyebaran interval dengan koma, seperti 0,3,7,9..13,19..* ; * disebut many; dan 0..*. Ada 2 macam object structure yaitu : a. Aggregation Structure, mendefinisikan hubungan antara dua atau lebih object. Sebuah superior object (whole) memiliki beberapa object (parts) (Mathiassen et al, 2000, p76). Secara ilmu bahasa, aggregation structure diekspresikan dengan formulasi has a, a-part-of, atau is-owned-by. Terdapat 3 tipe aggregation structure (Mathiassen et al, 2000, p79) yaitu : Whole-part, dimana whole merupakan jumlah dari parts, sehingga jika salah satu parts dihilangkan maka secara tidak langsung telah mengubah whole. 17

13 Container-content, dimana whole adalah kontainer (tempat tampung) dari parts-nya, sehingga bila terdapat penambahan atau pengurangan terhadap isinya (parts), tidak akan mengubah pengertian dari whole-nya. Union-member, dimana whole merupakan union/gabungan yang terorganisir dari anggotanya (parts), sehingga jika terdapat penambahan atau pengurangan anggota, tidak akan mengubah union-nya. Terdapat batasan jumlah anggota terendah, karena tidak mungkin sebuah union tanpa anggota. b. Association Structure, mendefinisikan hubungan antara dua atau lebih object, tetapi berbeda dengan aggregation (Mathiassen et al, 2000, p76). Hubungan antar class-class pada aggregation mempunyai pertalian yang kuat sedangkan pada association tidak kuat. Secara ilmu bahasa, association structure diekspresikan dengan formulasi knows atau associated-with. * * - a..b - c..d * * - a..b - c..d Ket : a - d adalah multipicity Gambar 2.7 Notasi Object Structure (Mathiassen et al, 2000, p337) Car 0..* 1..* Person Gambar 2.8 Association Structure (Mathiassen et al, 2000, p77) 18

14 3. Behavior, tujuan dari aktivitas ini adalah untuk memodelkan keadaan problem domain yang dinamis dengan memperluas definisi class yang terdapat dalam Class Diagram, yaitu dengan menambahkan behavioural patterns dan attributes untuk setiap class. Sumber dari tahap ini adalah event table dan class diagram yang telah dihasilkan dari tahap-tahap sebelumnya. Sedangkan hasil akhirnya adalah behavioral patterns yang diekspresikan secara grafis dalam Statechart Diagram (Mathiassen et al, 2000, p89-p90). Dalam class activity, behavior dipandang sebagai kumpulan events yang tidak berurutan yang meliputi suatu object. Sedangkan dalam behavior activity, behavior secara lebih tepat dideskripsikan dengan menambahkan waktu terjadinya events. Object behavior diidentifikasikan dengan event trace, yaitu serangkaian events yang berurutan yang meliputi suatu object. Events trace antara satu object mungkin berbeda dengan object lain meskipun kedua object tersebut berada dalam class yang sama. Hal ini disebabkan karena sifat event trace yang unik untuk object tertentu. Deskripsi dari event trace yang mungkin untuk seluruh object dalam sebuah class disebut behavioral pattern (Mathiassen et al, 2000, p90). Dalam memodelkan Problem Domain, dilakukan pengidentifikasian requirements untuk data-data yang akan disimpan oleh sistem. Untuk menspesifikasikan data tersebut digunakan attributes, yaitu deskripsi properti dari class atau events (Mathiassen et al, 2000, p92). Menurut Mathiassen et al (2000, p93) behavioral pattern memiliki struktur kontrol sebagai berikut : - Sequence adalah suatu set events yang akan terjadi satu per satu (secara berurutan). Notasinya : +. 19

15 - Selection adalah satu event yang terjadi dari suatu set events. Notasinya : - Iteration adalah satu event yang terjadi berulang-ulang kali. Notasinya : *. Jika menghadapi situasi behavior patterns yang kompleks, akan sulit sekali untuk mengekspresikannya dalam notasi-notasi umum sehingga untuk pengekspresiannya lebih cenderung menggunakan Statechart Diagram. InitialState Final State State event(attributes)[condition] Transition with event and condition Gambar 2.8 Notasi dasar Statechart Diagram (Mathiassen et al, 2000, p341) Sequence Selection Transition State 1 State 1 State State n Gambar 2.9 Struktur Kontrol Statechart Diagram (Mathiassen et al, 2000, p95) 20

16 Application Domain Analysis Tahap ini mendefinisikan requirements dari suatu sistem. Application Domain merupakan bagian yang mengatur, memantau, atau mengontrol Problem Domain (Mathiassen et al, 2000, p6). Atau dengan kata lain, berhubungan dengan aktivitas yang dikerjakan/dijalankan oleh sistem. Prinsip dari Application Domain analysis adalah bekerja sama dengan user untuk menentukan usage, function dan interface. Sumber dari aktivitas ini adalah system definition dan model dari tahap sebelumnya. System Definition and Model Usage Interfaces Funtions Requirements Gambar 2.10 Aktivitas dalam Application Domain Analysis (Mathiassen et al, 2000, p117) Menurut Mathissen et al (2000, p117) terdapat tiga subaktivitas dalam Application Domain Analysis, yaitu : 1. Usage Hasil akhir dari aktivitas ini adalah membuat deskripsi dari actors dan use cases, dimana relasinya diekspresikan dengan menggunakan actor table atau use case Diagram. Actor merupakan abstaksi dari user atau sistem lain yang berinteraksi dengan sistem (Mathiassen et al, 2000, p119). Sedangkan use case adalah pola interaksi antara 21

17 sistem dengan actors dalam application domain (Mathiassen et al, 2000, p120). Hubungan antara actor dan use case adalah association. System UseCase * * * * Actor Actor.. Gambar 2.11 Use Case Model (Schmuller,1999, p76) Menurut Armour dan Miller (2001, p7) untuk mendokumentasikan actors dapat menggunakan actor specifications yang berisi informasi mengenai actor name (nama actor), abstract (menjelaskan peranan actor sebagai abstract actor atau bukan), dan description (menjabarkan peranan actor dalam sistem). Abstract actor menggambarkan behavior yang sama antara dua actor atau lebih. Actor Spesifications Template Actor name : <nama> Abstract : <Yes/No> Description : <deskripsi dari peran aktor> Tabel 2.1 Actor Specification (Armour and Miller, 2001, p16) Adanya use case description dapat mempermudah pemahaman mengenai interaksi antra actors dan sistem serta tanggung jawab dan behavior sistem dalam responsnya terhadap interaksi tersebut (Armour dan Miller, 2001, p90) use case description berisi 22

18 informasi mengenai nama use case, use case ID, actor yang terlibat dan description (menjelaskan garis besar dari use case tersebut). Deskripsi use case harus dapat memungkinkan para developer untuk mengidentifikasi kebutuhan elemen function dan interface. UseCase1 Actor Usecase : Nama usecase usercaseid : ID usecase Actor(s) : nama actor yang berinteraksi dengan sistem Description : deskripsi cara actor dan sistem berinteraksi serta tanggungjawab sistem Tabel 2.2 Initial Use Case Template (Armour dan Miller, 2001, p90) Representasi use case dapat menggunakan base use case description yang mengidentifikasi behavior yang spesifik dan interaksi yang terjadi antara actor dan sistem di dalam batasan urutan kejadian (flow of events) dari use case (Armour dan Miller, 2001, p107). Use Case Name: Unique Use Case ID: Primary Actor(s): Secondary Actor(s): <nama dari use case> <identitas unik untuk use case> <nama dari primary actor atau actors yang berinteraksi dengan sistem> <nama dari secondary actor atau actors yang berinteraksi dengan sistem> 23

19 Brief Description: <deskripsi dari Use case> Preconditions: <state sistem ketika use case dipicu> Flow of Events <aktivitas-aktivitas dan interaksi-interaksi yang dilakukan ketika use case dilakukan> Postcondition: <state ketika use case meninggalkan sistem> Priority: <prioritas pengembangan use case yang relatif> Alternative flows <alternatif mayor atau pengecualian yang mungkin terjadi di and exceptions: dalam flow of events> Nonbehavioral <kebutuhan seperti pertunjukan, keamanan, dll> requirements: Assumptions: <asumsi-asumsi yang dibutuhkan> Issues: <isu-isu yang menonjol> Source: <rapat, wawancara, dokumen, dll yang merupakan asal dari use case> Tabel 2.3 Base Use Case Description Template (Armour dan Miller, 2001, p110) 2. Function Tujuan dari aktivitas ini adalah untuk menentukan kemampuan pemrosesan dari suatu sistem sehingga menghasilkan suatu function list beserta spesifikasi untuk function yang kompleks. Function memfokuskan pada apa yang bisa dilakukan oleh sistem untuk membantu actor. Dengan kata lain, function merupakan fasilitas untuk membuat sebuah model berguna bagi actor (Mathiassen et al, 2000, p138). Menurut Mathiassen et al (2000, p138) terdapat empat tipe utama dari function, dimana masing-masing tipe mengekspresikan hubungan antara model dan konteks sistem. Keempat tipe tersebut antara lain update function, signal function, read function, dan compute function. Sumber untuk mengidentifikasi function berasal dari deskripsi Problem Domain, yang diekspresikan oleh class dan events, dan juga dari deskripsi application Domain, yang diekspresikan oleh use case. Tipe function yang berasal dari classes biasanya 24

20 adalah read dan update function. Sedangkan dari events adalah update function. Use cases memungkinkan untuk semua tipe function (Mathiassen et al, 2000, p139-p144). Pemahaman mengenai functions yang kompleks akan lebih jelas dengan adanya detail spesifikasi baik dalam format mathematical expresison, algorithm in structured language, maupun functional partitioning in the function list (Mathiassen et al, 2000, p145). 3. Interface Tujuan dari aktivitas ini adalah menentukan antar muka (interface) dari sistem yang sedang dikembangkan. Interface adalah fasilitas yang membuat model sistem dan function tersedia bagi actor (Mathiassen et al, 2000, p151). Adanya interface memungkinkan actor untuk berinteraksi dengan sistem. Sumber aktivitas berasal dari Class Diagram, Use cases, dan Function List. Menurut Mathiassen et al (2000, p152) terdapat dua macam interface : 1. User Interface, menghubungkan human actor (manusia) dengan sistem. Dalam merancang user interface dibutuhkan feedback dari user. Terdapat empat Usre Interface Pattern, yaitu : menu selection (diekspresikan sebagai daftar pilihan pada user interface), form filling (pola klasik untuk entri data), command language (dibutuhkan daya ingat user untuk mengoperasikan sistem), dan direct manipulation (memungkinkan manipulasi langsung dengan representasi objects) (Mathiassen et al, 2000, p154-p155). 2. System Interface, menghubungkan system actor (sistem lain) dengan sistem yang sedang di-develop. Sistem lain bisa berupa : external device (misal: sensor, switch, dll) dan sistem komputer yang kompleks sehingga dibutuhkan suatu protokol komunikasi. Biasanya interface ini tidak dipakai untuk sistem 25

21 administratif tetapi lebih sering untuk monitoring and controlling system (Mathiassen et al, 2000, p163-p164). Untuk menentukan elemen dari user interface dapat mengunakan object dan class pada model serta functions. Elemen tersebut harus direpresentasikan dalam bentuk yang mudah dipahami oleh user, seperti icon, fields, tables, diagrams, windows, button. Sedangkan untuk kasus yang kompleks, dapat mengunakan Sequence Diagram untuk merelasikan interaksi antara elemen interface dengan use case-nya. Sequence Diagram mendeskripsikan langkah-langkah interaksi individual dan menghubungkannya dengan window yang relevan. Diagram ini juga menggambarkan functions yang akan diaktivasi selama interaksi terjadi (Mathiassen et al, 2000, pp ). Deskripsi dari user interface dapat mengunakan Navigation Diagram, dimana menyediakan gambaran keseluruhan dari elemen user interface dan transisi di antaranya. Diagram ini terdiri dari gambar yang diperkecil di setiap window, panah yang menunjukkan bagaimana mengunakan button dan seleksi lain yang akan mengaktivasi function atau membuka window lain (Mathiassen et al, 2000, p159). Untuk menggambarkan elemen-elemen user interface dalam prototype atau menspesifikasikannya lebih detail dapat menggunakan Window Diagram. Diagram ini mendeskripsikan tampilan dari single window yang mencakup bentuk detail dari elemenelemen window (Mathiassen et al, 2000, pp & p344) Architectural Design Pada tahap ini, akan dilakukan penstrukturan sistem berdasarkan bagianbagiannya dan pemenuhan beberapa criteria desain. Tahap ini juga merupakan suatu framework bagi aktivitas pengembangan selanjutnya. Aktivitas architectural design bertujuan untuk menstrukturkan suatu sistem yang terkomputerisasi. Hasil yang 26

22 diperoleh berupa struktur dari komponen komponen dan proses proses sistem. Tahap Architectural Design memiliki tiga subaktivitas yaitu (Mathiassen et al, 2000, p173). : Analysis Document Criteria Component Architecture Process Architecture Architectural Spesification Gambar 2.13 Aktivitas dalam Architectural Design (Mathiassen et al, 2000, p176) 1. Criteria Criteria adalah suatu prioritas dari arsitektur (Mathiassen et al, 2000, p176). Tujuan aktivitas criteria adalah untuk menentukan prioritas desain. Hasil yang diperoleh dari tahap ini adalah kumpulan criteria untuk desain yang telah diprioritaskan. CRITERIA Usable Secure Efficient Correct Reliable Maintainable Testable PENGUKURAN DARI Kemampuan adaptasi sistem tehadap konteks organisasi, hubungan kerja dan teknikal Suatu pencegahan melawan akses yang tidak terotorisasi terhadap fasilitas-fasilitas yang ada Penggunaan yang ekonomis terhadap fasilitas technical platform Pemenuhan terhadap persyaratan-persyaratan Pemenuhan terhadap eksekusi function yang benar-benar tepat Besarnya usaha untuk melokasikan dan memperbaiki kecacatan sistem Besarnya usaha untuk memastikan bahwa sistem menampilkan 27

23 fungsi-fungsi yang telah ditentukan Flexible Besarnya usaha untuk memodifikasi sistem Comprehensible Usaha yang dibutuhkan untuk mendapatkan pengertian yang masuk akal terhadap sistem Reusable Potensi penggunaan bagian-bagian sistem dalam sistem lain yang terhubung Portable Besarnya usaha untuk memindahkan sistem ke technical platform Interoperable Besarnya usaha untuk menggabungkan suatu sistem ke sistem lain Tabel 2.4 Criteria klasik untuk mengukur kualitas software (Mathiassen et al, 2000, p178) 2. Components Component Architecture adalah sebuah struktur sistem yang terdiri dari komponen - komponen yang saling terhubung. Component adalah kumpulan dari bagian - bagian program yang membentuk sistem dan memiliki tanggung jawab yang telah terdefinisikan dengan jelas (Mathiassen et al, 2000, p190). Menurut Mathiassen et al (2000, pp ), terdapat beberapa pola umum yang dapat digunakan untuk mendesain suatu component architectrure yaitu : The Layered Architecture Pattern Arsitektur ini terdiri dari beberapa components yang didesain sebagai layers. Desain dari setiap component menggambarkan tanggung jawabnya masing-masing serta interface bagian atas maupun bagian bawah. Interface bagian atas akan menggambarkan operasi yang tersedia untuk layer dibawahnya. The Generic Architecture Pattern Model Component merupakan dari sistem object yang diletakkan pada layer yang paling bawah, kemudian diikuti dengan layer sistem function, dan yang paling atas 28

24 merupakan component interface. Layer interface dapat dibagi menjadi dua bagian yaitu user interface dan system interface. «component» Interface «component» User Interface «component» System Interface «component» Function «component» Model «component» Technical platform «component» UIS «component» DBS «component» NS Gambar 2.14 The Generic Architecture Pattern (Mathiasen et al, 2000, p196) The Client Server Architecture Pattern Komponen dari arsitektur sebuah server dan beberapa clients. Server memiliki kumpulan operasi yang tersedia bagi client. Server bertanggung jawab untuk menyediakan hal hal yang umum bagi client-nya, seperti database atau sumber daya lain yang bisa digunakan bersama. Server menyediakan operasinya bagi client melalui suatu jaringan. Client bertanggung jawab untuk menyediakan interface lokal bagi para user (Mathiassen et al, 2000, p197). 29

25 «component» Client 1 «component» Client 2 «component» Client n «component» Server Gambar 2.15 The Client Server Architecture Pattern (Mathiassen et al, 2000, p197) 3. Process Tahap ini menentukan bagaimana suatu proses sistem didistribusi dan dikoordinasikan. Tujuan dari tahap ini adalah untuk mendefinisikan struktur fisikal dari suatu sistem. Hasil yang akan diperoleh berupa sebuah deployment digram. Processor adalah suatu bagian peralatan yang dapat mengeksekusi sebuah program(mathiassen et al, 2000, pp ). Deployment Diagram, menggambarkan unit - unit teknologi (khususnya perangkat keras seperti processor dan penyimpanan besar, beserta hubungan komunikasi fisiknya) dimana sistem akan diimplementasi. Deployment Diagram juga dapat memodelkan bagaimana perangkat keras akn didistribusikan di antara unit unit teknologi terpilih, dengan cara menambahkan komponen perangkat lunak dan hubungannya, ke dalam deployment diagram yang menggambarkan teknologi fisikal asli (Jones, 2000, p202). 30

26 <<Processor>> Node 1 Component1 <<Device>> Node 2 Depedency Component2 Gambar 2.16 Deployment Diagram (Schmuller, 1999, p383) Component Design Tujuannya adalah untuk menentukan implementasi dari kebutuhan di dalam kerangka arsitektur. Yang menjadi titik awal dari tahap ini adalah architectural specification dan system requirement yang akan menghasilkan connected component specification. Menurut Mathiassen et al (2000, p232), terdapat dua subaktivitas dalam component design, yaitu : 31

27 Architecture Specification Design of components Design of Components Connections Component Specification Gambar 2.17 Subaktivitas dalam Component Design (Mathiassen et al, 2000, p232) Design of Components Merupakan tahapan untuk merancang komponen sistem, yaitu : Model Component Model Component adalah bagian dari sistem yang mengimplementasi model problem domain (Mathiassen et al, 2000, p236). Tujuan dari model component design adalah untuk menggambarkan model dari problem domain. Model tersebut merupakan hasil dari kegiatan ini yang digambarkan oleh class diagram yang telah direvisi dari hasil kegiatan analisis. Revisi class diagram dapat dilakukan dengan memperhatikan private events dan common events. Private events adalah event yang melibatkan hanya satu object domain (Mathiassen et al, 2000, p239). 32

28 Representasikan event-event ini sebagai state attribute Event-event yang pada class yang dijabarkan oleh statechart diagram. hanya terjadi pada Setiap kali ada kejadian yang melibatkan salah satu Urutan/sequence event tersebut, maka sistem akan menugaskan dan selection yang baru kepada state attribute Integrasikan attribute dari event yang terlibat ke dalam class Representasikan event-event ini sebagai suatu class baru, dan hubungkan class tersebut dengan class yang Event-event yang dijabarkan pada statechart diagram dengan terjadi berulang- menggunakan struktur aggregation. Untuk setiap ulang (iteration) iterasi, sistem akan menghasilkan suatu object baru Integrasikan attribute event ke dalam class yang baru Tabel 2.5 Guidelines atau panduan dalam merepresentasikan private events (Mathiassen et al, 2000, p241) Jika suatu event adalah common /umum sehingga mempengaruhi beberapa object, maka event tersebut perlu dihubungkan dengan salah satu object dan dibuat hubungan struktural dengan object lain agar tetap dapat mengaksesnya. Common Event Jika event yang terlibat dalam statechart diagram dalam cara yang berbeda, representasikan event tersebut dalam hubungan ke class yang menawarkan representasi paling simple. Jika event yang terlibat dalam statechart diagram dalam cara yang sama, pertimbangkan alternatif representasi yang mungkin dapat digunakan Tabel 2.6 Guidelines untuk merepresentasikan common events (Mathiassen et al, 2000, p241) Untuk menyederhanakan class diagram yang telah direvisi dari hasil tahapan sebelumnya, dilakukan restrukturisasi class baik melalui generalization, association, maupun embedded iteration. 33

29 Function Component Function component adalah bagian sistem yang mengimplementasikan kebutuhan fungsional (Mathiassen et al, 2000, p252). Tujuannya adalah agar user interface dan komponen komponen sistem lainnya dapat mengakses model. Sedangkan tujuan dari function component design adalah menentukan implementasi functions. Hasil dari kegiatan ini adalah class diagram dengan operations dan spesifikasi dari operations yang komlpleks. Langkah pertama yang harus dilakukan adalah mendesain functions sebagai operations, yaitu mengidentifikasi tipe utama dari functions tersebut. Ada empat tipe functions (Mathiassen et al, 2000, pp ), yaitu : Update, Read, Compute, dan Signal. Patterns (pola) dapat membantu memilih functional design yang mana dapat digunakan dari beberapa pilihan yang dapat membantu merealisasikan functions sebagai sekumpulan operations. Empat pola menurut Mathiassen et al (2000, pp ) adalah : a. Model Class Plecement. Pola ini menempatkan operation dalam model component class dan berguna ketika sebuah operation mengakses hanya sebuah single object atau struktur aggregation yang sederhana. Pola ini juga dapat digunakan ketika beberapa object terlibat namun hanya jika tanggung jawab operation tersebut dapat dengan jelas ditempatkan pada salah satu dari model class. b. Function Class Placement 34

30 Pola ini digunakan ketika tanggung jawab operation tidak dapat dengan jelas ditempatkan dalam model class. Sebaliknya satu atau lebih functional-component class dapat digambarkan dengan menempatkan operation yang merealisasikan function. c. Strategy Pola ini digunakan untuk mendefinisikan sekumpulan operations yang umum terenkapsulasi dan dapat dipertukarkan. d. Active Function. Active signal function dapat direalisasikan sebagai operation yang secara permanen aktif dan berkala memberikan sinyal kepada interface. Active function ditempatkan sebagai active object dan performance-nya tergantung dari state pada model component. Apabila terdapat operation yang kompleks harus dideskripsikan dengan lebih detail lagi sehingga di dalam desain tidak ada ketidakpastian yang penting. Menurut Mathiassen et al (2000, pp ) ada 3 (tiga) cara untuk melakukannya, yaitu operation specification, sequence diagram, dan statechart diagram Connecting Components Tujuan dari aktivitas ini adalah menghubungkan komponen-komponen sistem yang akan menghasilkan class diagram dari komponen-komponen tersebut. Jadi pada aktivitas ini, hubungan antara komponen-komponen dirancang untuk mendapatkan desain yang fleksibel dan comperehensible. Untuk itu dibutuhkan evaluasi dari coupling dan cohesion. Coupling adalah ukuran tentang seberapa dekat dua classes atau components dihubungkan (Mathiassen et al, 2000, p272). Cohesion adalah ukuran tentang seberapa 35

31 baik sebuah class atau component terikat bersama (Mathiassen et al,2000, p273). Prinsipnya adalah: highly cohesive classes and loosely coupled components. Hasil dari aktivitas connecting components ini adalah class diagram yang dimana dependencies-nya berubah menjadi connections. Tiga bentuk connections menurut Mathiassen et al (2000, p275, p281) adalah: Class aggregation, yaitu mengagregasikan class-class dari component lain. Koneksi ini berguna ketika class definition sudah ada di dalam component lain. Umumnya coupling-nya rendah, namun sulit mencapai cohesive. Contoh : <<component>> Function Account Management 1 <<component>> Model 1..* Account Gambar 2.18 Koneksi oleh class agregation (Mathiassen et al, 2000, p275) Class specialization, yaitu menspesialisasikan public class dari component lain. Contoh : 36

32 <<component>> User Interface PersonW SessionW <<component>> UI Library Window Gambar 2.19 Koneksi oleh class specialization (Mathiassen et al, 2000, p276) Operation call, yaitu memanggil public operations di dalam object-object dari component lain. Umumnya coupling-nya rendah dan cohesion-nya tinggi. Contoh : <<component>> System Interface <<component>> Model Throttle Engine throttle position throttle setting position <<call>> read Gambar 2.20 Koneksi dalam memanggil sebuah operasi (Mathiassen et al, 2000, p277) 37

33 2.2 Teori Khusus Definisi Pembelian Definisi pembelian menurut Mulyadi (1997, p301) adalah pengadaan barang yang diperlukan perusahaan. Pembelian merupakan salah satu fungsi yang penting dalam berhasilnya operasi suatu perusahaan yang di bebani tanggung jawab untuk mendapatkan kuantitas dan kualitas bahan bahan yang tersedia pada waktu dibutuhkan dengan harga yang sesuai dengan harga yang berlaku (Assauri, 1993, p205). Secara umum pembelian dapat didefinisikan sebagai usaha pengadaan barang atau jasa dengan tujuan untuk mendapatkan kuantitas dan kualitas bahan bahan yang tersedia pada waktu dibutuhkan dengan harga yang sesuai, untuk kepentingan proses produksi maupun untuk dijual kembali. Jenis transaksi pembelian dapat digolongkan menjadi 2 (dua) menurut Mulyadi (1997, p301), yaitu : 1. Pembelian Lokal Pembelian lokal merupakan pembelian dari pemasok dalam negeri 2. Pembelian Impor Pembelian Impor merupakan pembelian dari pemasok luar negeri Tugas dan Tanggung Jawab Fungsi Pembelian Menurut Hammer dan Usry yang diterjemahkan oleh Sirait, A (1996), tugas dan fungsi pembelian adalah sebagai berikut : 1. Menerima surat permintaan pembelian untuk bahan, perlengkapan dan peralatan. 2. Mencari informasi tentang sumber- sumber pasokan, harga, pengiriman dan jadwal penyerahan. 38

34 3. Menyiapkan dan mengirimkan surat order pembelian. 4. Menyusun laporan yang memadai dan sistematik antara departemen pembelian, penerimaan dan akuntansi. Mulyadi (1997, p302) menyebutkan bahwa tanggung jawab dan fungsi pembelian adalah untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang dan mengeluarkan order pembelian kepada pemasok yang dipilih Fungsi yang terkait dalam Sistem Pembelian Menurut Mulyadi (1997, p302) fungsi yang terkait dalam sistem pembelian adalah sebagai berikut : 1. Fungsi Gudang, yang bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan. 2. Fungsi Pembelian, bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan berang, dan mengeluarkan order pembelian kepada pemasok yang dipilih. 3. Fungsi Penerimaan, bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang diterima dari pemasok guna menentukan dapat atau tidaknya barang tersebut diterima perusahaan. 4. Fungsi Akuntansi, ini berkaitan dengan transaksi pembelian adalah fungsi pencatatan hutang yang bertanggung jawab untuk mencatat transaksi pembelian ke register bukti kas keluar dan untuk menyelenggarakan arsip dokumen sumber bukti kas keluar dan untuk menyelenggarakan arsip dokumen sumber bukti kas keluar yang 39

35 berfungsi sebagai catatan hutang atau menyelenggarakan kartu hutang sebagai buku pembantu hutang Prosedur Pembelian yang Lazim Mengacu pada pendapat Mulyadi (1997, p322-p324), prosedur pembelian yang lazim diterapkan oleh perusahaan diuraikan sebagai berikut : 1. Jika persediaan sudah mencapai titik pemesanan kembali (reorder point), maka Bagian Gudang membuat Surat Permintaan Pembelian 2 (dua) rangkap yang didistribusikan kepada : a. Rangkap ke-1 didistribusikan kepada Bagian Pembelian b. Rangkap ke-2 di simpan oleh Bagian Gudang sebagai arsip 2. Berdasar Surat Permintaan Pembelian dari Bagian Gudang, Bagian Pembelian membuat Surat Permintaan Penawaran Harga yang ditujukan kepada berbagai pemasok, untuk memeperoleh informasi mengenai harga barang dan berbagai syarat pembelian yang lain. 3. Bagian Pembelian menerima Surat Penawaran Harga dari berbagai pemasok, Bagian Pembelian menyeleksi pemasok berdasarkan penawaran harga yang paling menguntungkan. 4. Bagian Pembelian membuat Surat Order Pembelian (SOP) 5 (lima) rangkap yang akan didistribusikan kepada : a. Rangkap ke-1 diberikan kepada pemasok yang dipilih, sebagai order pembelian resmi yang dikeluarkan oleh perusahaan. b. Rangkap ke-2 didistribusikan kepada Bagian Gudang sebagai bukti bahwa barang yang dimintanya telah dipesan. 40

36 c. Rangkap ke-3 didistribusikan kepada Bagian Penerimaan sebagai otorisasi untuk menerima barang yang jenis, spesifikasi, mutu, kuantitas dan pemasoknya seperti yang tercantum dalam dokumen tersebut. d. Rangkap ke- 4 didistribusikan kepada Bagian Akuntasi sebagai salah satu dokumen dasar yang akan digunakan untuk mencatat transaksi pembelian tersebut ke dalam catatan akuntansi yang terkait. e. Rangkap ke-5 disimpan oleh Bagian Pembelian menurut nama pemasok, sebagai dasar untuk mencari informasi mengenai pemasok, apabila diperlukan dikemudian hari. 5. Pemasok mengirimkan barang kepada perusahaan dan diterima oleh Bagian Penerimaan. Bagian Penerimaan melakukan pemeriksaan terhadap jenis, spesifikasi, mutu, dan kuantitas barang yang diterima dari pemasok dan mencocokkannya dengan yang tercantum dalam Surat Order Pembelian guna menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan, maka Bagian Penerimaan membuat Laporan Penerimaan Barang (LPB) 4 (empat) rangkap, yang akan didistribusikan kepada : a. Rangkap ke-1 didistribusikan kepada Bagian Pembelian b. Rangkap ke-2 didistribusikan kepada Bagian Gudang beserta barang. c. Rangkap ke-3 didistribusikan kepada Bagian Akuntansi d. Rangkap ke-4 disimpan oleh Bagian Penerimaan sebagai arsip. Jika barang tidak sesuai dengan keinginan perusahaan, maka barang tersebut akan dikembalikan kepada supplier. 41

37 6. Bagian Gudang melakukan penyimpanan barang dan mencocokkan SOP dengan LPB, lalu mencatat kuantitas barang yang diterima kedalam Kartu Gudang, kemudian mengarsipkan kedua dokumen tersebut. 7. Bagian Pembelian menerima faktur dari pemasok dan memeriksa faktur tersebut, kemudian mengirimkan faktut kepada Bagian Akuntansi. 8. Bagian Akuntansi mencocokkan faktur dengan SOP dan LPB. Jika telah sesuai, Bagian Akuntansi mencatat transaksi pembelian tersebut kedalam Jurnal Pembelian dan Kartu Utang, serta mencatat harga pokok persediaan barang yang dibeli ke dalam kartu persediaan. Faktur dari pemasok diarsipkan sementara menurut tanggal jatuh tempo pembayaran, untuk digunakan kembali dan diproses dalam transaksi pembayaran faktur pada saat jatuh tempo, sedangkan SOP dan LPB diarsipkan menurut nomor atau tanggal dokumen tersebut dibuat. Dari prosedur pembelian diatas, dapat disimpulkan bahwa terdapat praktik yang sehat antara lain meliputi sebagai berikut : a. Bagian gudang mengajukan Surat Permintaan Pembelian hanya jika tingkat persediaan di gudang telah mencapai titik pemesanan kembali. b. Bagian pembelian melakukan pembelian hanya berdasarkan SPP. c. Pemasok dipilih berdasarkan perbandingan penawaran harga bersaing dari berbagai pemasok, tidak berdasarkan hubungan istimewa dan pribadi diantara Bagian Pembelian dengan pemasok. Dengan cara ini, kemungkian pengadaan barang yang lebih tinggi dari harga yang normal dapat dihindari. d. Barang hanya diterima dan diperiksa oleh Bagian Penerimaan, jika bagian itu telah menerima tembusan SOP dari Bagian Pembelian. 42

38 e. Bagian Penerimaan melakukan pemeriksaan barang yang diterima dari pemasok dengan cara menghitung dan menginspeksi barang tersebut dan membandingkannya dengan tembusan Surat Order Pembelian. f. Pembayaran faktur dilakukan sesuai dengan syarat pembayaran guna mencegah hilangnya kesempatan untuk memperoleh potongan tunai. Jika perusahaan memperoleh potongan tunai dari pemasok karena melunasi kewajibannya dalam jangka waktu potongan( cash discount period ) berarti dapat menghemat kekayaan perusahaan Pengertian Persediaan Persediaan dalam suatu perusahaan adalah faktor pendukung penting dalam menjalankan operasi perusahaan. Berikut beberapa pendapat para ahli tentang persediaan : Persediaan merupakan sejumlah bahan-bahan yang disediakan dan bahan-bahan dalam proses yang terdapat dalam perusahaan untuk proses produksi, serta barang - barang jadi/produksi yang disediakan untuk memenuhi permintaan dari konsumen atau langganan setiap waktu (Assouri 1993, p219). Persediaan menunjukkan barang yang dimiliki untuk dijual dalam kegiatan normal perusahaan (Handoko, 1994,p ). Pada umumnya persediaan barang dagangan diterapkan untuk barang-barang yang dimiliki oleh perusahaan dagang apabila perusahaan tersebut diperoleh dalam keadaan siap untuk dijual kembali. Sedangkan persediaan barang produksi termasuk barang dari hasil produksi perusahaan itu yang belum didistribusikan ke konsumen. 43

39 Dari definisi persediaan tersebut maka dapat disimpulkan bahwa persediaan adalah aset yang sangat penting karena persediaan merupakan barang yang tersedia untuk dijual (barang dagangan/barang jadi), barang yang masih dalam proses produksi untuk diselesaikan dan dijual(barang dalam proses pengolahan) dan barang yang akan dipergunakan untuk produksi barang jadi yang akan dijual (bahan baku dan bahan pembantu) dalam kegiatan usaha normal perusahaan Perencanaan Persediaan Persediaan mempermudah atau memperlancar jalannya operasi perusahaan pabrik yang harus dilakukan secara berturut-turut untuk memprodusir barang-barang serta selanjutnya menyampaikannya pada langganan atau konsumen (Assouri, 1993, p177). Persediaan dikatakan sangat penting bagi perusahaan karena persediaan berguna untuk : a. Menghilangkan resiko datangnya keterlambatan barang b. Menghilangkan resiko dari produk yang dipesan tidak bagus atau rusak c. Untuk menumpuk bahan-bahan yang dihasilkan secara minimum sehingga dapat dipergunakan bila barang tersebut tidak ada dalam pasaran d. Mempertahankan stabilitas operasi perusahaan atau menjamin kelancaran arus produksi e. Mencapai penggunaan mesin yang optimal f. Memberikan pelayanan kepada pelanggan dengan sebaik-baiknya dimana keinginan langganan pada setiap waktu dapat terpenuhi atau memberi jaminan tetap tersedianya barang tersebut g. Membuat pengadaan atau produksi tidak perlu sesuai dengan penggunaan atau penjualannya 44

40 Pengendalian Internal Atas Persediaan Pengendalian Internal Atas Persediaan merupakan hal yang sangat penting karena persediaan adalah bagian yang amat penting dari suatu perusahaan dagang. Menurut Render dan Heizer (2001, p318) elemen yang harus ada untuk mendukung pengendalian internal yang baik atas persediaan adalah : 1. Pemilihan karyawan,pelatihan, dan disiplin yang baik. Hal-hal ini tidak pernah mudah dilakukan, tetapi sangat penting dalam bisnis makanan, perdagangan besar, dan operasi bisnis eceran di mana karyawannya mempunyai akses kepada barangbarang yang langsung dikonsumsi. 2. Pengendalian yang ketat atas barang yang datang. Melalui sistem kode batang (bar code) 3. Pengendalian yang efektif atas semua barang yang ke luar dari fasilitas Metode Pencatatan Persediaan Ada dua sistem yang dikenal dalam menentukan jumlah persediaan pada akhir suatu periode menurut Mulyadi (1997, p558), yaitu dengan : 1. Metode Mutasi Persediaan Dalam metode mutasi persediaan, setiap mutasi persediaan dicatat dalam kartu persediaan 2. Metode Persediaan Fisik Dalam Metode Persediaan Fisik, hanya tambahan persediaan dari pembelian saja yang dicatat, sedangkan mutasi berkurangnya persediaan karena pemakaian tidak dicatat dalam kartu persediaan 45

41 Metode Penilaian Persediaan Dalam menilai persediaan metode yang digunakan (Soemarso, 1995, p424), adalah sebagai berikut : 1. Metode LIFO LIFO adalah metode penetapan harga pokok persediaan dimana dianggap bahwa barang-barang yang paling akhir dibeli dan merupakan barang yang dijual pertama kali. Dalam metode ini persediaan akhir akan dinilai dengan harga pokok pembelian terdahulu. 2. Metode FIFO LIFO adalah metode penetapan harga pokok persediaan dimana dianggap bahwa barang-barang yang pertama dibeli akan merupakan barang yang dijual pertama kali. Dalam metode ini persediaan akhir akan dinilai dengan harga pokok pembelian yang paling akhir. 3. Metode Rata-rata (Average) Rata-rata dalam penetapan harga pokok persediaan dimana dianggap bahwa harga pokok rata-rata dari barang yang tersedia dijual akan digunakan untuk menilai harga pokok barang yang dijual dan yang terdapat dalam persediaan Manajemen Persediaan Menurut Handoko (2001, p334) sistem Persediaan adalah serangkaian kebijaksanaan dan pengendalian yang memonitor tingkat persediaan yang bertujuan untuk meminimumkan biaya total. Menurut jenisnya dapat dibedakan menjadi : 1. Persediaan bahan mentah, yaitu persediaan barang berujud yang digunakan dalam proses produksi 46

42 2. Persediaan komponen-komponen rakitan, yaitu persediaan barang-barang yang terdiri dari komponen-komponen yang diperoleh dari perusahaan lain, dimana secara langsung dapat dirakit menjadi suatu produk 3. Persediaan bahan pembantu atau penolong, yaitu persediaan barang-barang yang diperlukan dalam proses produksi, tetapi tidak merupakan bagian barang jadi 4. Persediaan barang dalam proses, yaitu persediaan barang-barang yang merupakan keluaran dari tiap-tiap bagian dalamproses produksi atau yang diolah menjadi suatu bentuk 5. Persediaan barang jadi, yaitu persediaan barang-barang yang telah selesai diprosesatau diolah Lead Time, Safety Stock, Reorder Point, EOQ dan Minimum Stock a. Lead Time Beberapa definisi lead time : Render dan Heizer (2001,p324), lead time adalah waktu antara dilakukannya pemesanan Handoko (2001, p341), lead time adalah waktu antara pesanan dilakukan dan barang-barang diterima, adalah konstan Berdasarkan definisi di atas maka dapat ditarik kesimpulan bahwa lead time merupakan waktu yang dihitung sejak satu pesanan pembelian pada suplier dilakukan sampai saat barang tersebut diterima oleh pembeli b. Safety Stock 47