BAB II LANDASAN TEORI

Transkripsi

1 BAB II LANDASAN TEORI 2.1 Landasan Teori Landasan teori yang digunakan dalam penelitian dan pengembangan APLIKASI RETAIL MINIMARKET MENGGUNAKAN METODE ENTERPRISE RESOURCE PLANNING ini adalah : Enterprise Resource Planning Enterprise Resource Planning [1] merupakan sebuah sistem informasi perusahaan yang dirancang untuk mengkoodinasikan semua sumberdaya, informasi dan aktifitas yang diperlukan untuk proses bisnis lengkap. Sistem Enterprise Resource Planning didasarkan pada database pada umumnya dan rancangan perangkat lunak modular. Enterprise Resource Planning merupakan Software yang mengintegrasikan semua departemen dan fungsi suatu perusahaan kedalam satu sistem komputer yang dapat melayani semua kebutuhan perusahaan, baik dari departemen penjualan, HRD, produksi atau keuangan. Syarat terpenting dari sistem Enterprise Resource Planning adalah integrasi. Integrasi yang dimaksud adalah membangun berbagai kebutuhan pada Software dalam Logical Database, sehingga memudahkan semua departemen berbagi informasi dan berkomunikasi. Database yang ada dapat mengijinkan setiap departement dalam perusahaan untuk menyimpan dan mengambil informasi secara Real-Time. Informasi tersebut harus dapat dipercaya, dapat diakses dan mudah disebarluaskan. Rancangan perangkat lunak modular artinya bahwa sebuah bisnis dapat memilih modul-modul yang diperlukan, dikombinasikan dan disesuiakan dari setiap Vendor yang berbeda serta dapat menambah modul baru untuk meningkatkan unjuk kerja bisnis Tujuan Dan Perencanaannya Dalam Organisasi Tujuan sistem Enterprise Resource Planning [1] adalah untuk mengkoordinasikan bisnis organisasi secara keseluruhan. Tujuan Enterprise Resource Planning dalam organisasi atau perusahaan yaitu untuk : II-1

2 1. Otomatisasi dan integrasi banyak proses bisnis. 2. Membagi database yang umum dan praktek bisnis melalui Enterprise Resource Planning. 3. Menghasilkan informasi yang Real-Time. 4. Memungkinkan perpaduan proses transaksi dan kegiatan perencanaan Tahap Evolusi Enterprise Resource Planning 1. Material Requirement Planning Material Requirement Planning [2] merupakan cikal bakal dari Enterprise Resource Planning, dengan konsep perencanaan kebutuhan material. 2. Close-Loop Material Requirement Planning Close-Loop Material Requirement Planning [2] merupakan sederetan fungsi dan tidak hanya terbatas pada Material Requirement Planning [, terdiri atas alat bantu penyelesaian masalah prioritas dan adanya rencana yang dapat diubah atau diganti jika diperlukan. 3. Manufakturing Resource Planning II Manufakturing Resource Planning II [2] merupakan pengembangan dari closeloop Material Requirement Planning yang ditambahkan 3 elemen yaitu: perencanaan penjualan dan operasi, antarmuka keuangan dan simulasi analisis dari kebutuhan yang diperlukan. 4. Enterprise Resource Planning Enterprise Resource Planning [2] merupakan perluasan dari Material Requirement Planning II yaitu perluasan pada beberapa proses bisnis diantaranya integrasi keuangan, rantai pasok dan meliputi lintas batas fungsi organisasi dan juga perusahaan dengan dilakukan secara mudah. 5. Extended Enterprise Resource Planning II Extended Enterprise Resource Planning II [2] merupakan perkembangan dari Enterprise Resource Planning yang diluncurkan tahun 2000, serta lebih kompleks dari Enterprise Resource Planning sebelumnya. II-2

3 Implementasi Enterprise Resource Planning 1. Inplementasi sitem Enterprise Resource Planning [2] tergantung pada ukuran ruang bisnis, ruang lingkup dari perubahan dan peran serta pelanggan. 2. Perusahaan membutuhkan jasa konsultasi, kustomasi dan jasa pendukung. 3. Migrasi data adalah salah satu aktifitas terpenting dalam menentukan kesuksesan dari implementasi Enterprise Resource Planning. Langkah strategi migrasi data yang dapat menentukan kesuksesan implementasi Enterprise Resource Planning : 1. Mengidentifikasi data yang akan dimigrasikan. 2. Menentukan waktu dari migrasi data. 3. Menentukan alat untuk migrasi data. 4. Memutuskan persiapan yang berkaitan dengan migrasi. 5. Menentukan pengarsipan data Kelebihan Enterprise Resource Planning 1. Integrasi antara area fungsional yang berbeda untuk komunikasi, produktifitas dan efisiensi yang tepat. 2. Rancangan perekayasaan. 3. Pelacakan pemesanan dari penerimaan sampai Fulfillment. 4. Mengatur saling ketergantungan dari proses penagihan material yang kompleks. 5. Pelacakan 3 cara yang bersesuaian antara pemesanan pembelian, inventori, dan pembiayaan. 6. Akuntansi untuk keseluruhan tugas : melacak pemasukan, biaya dan keuntungan pada level inti Kelemahan Enterprise Resource Planning 1. Terbatasnya kustomasi dari perangkat lunak Enterprise Resource Planning. 2. Sistem Enterprise Resource Planning sangat mahal. II-3

4 3. Perekayasaan kembali proses bisnis untuk menyesuaikan dengan standar industri yang telah dideskripsikan oleh sistem Enterprise Resource Planning. 4. Enterprise Resource Planning sering terlihat terlalu sulit untuk beradaptasi dengan alur kerja dan proses bisnis tertentu dalam beberapa organisasi. 5. Sistem Enterprise Resource Planning terlalu kompleks jika dibanding dengan kebutuhan dari pelanggan. 6. Data dalam sistem Enterprise Resource Planning berada dalam satu tempat, contohnya : pelanggan, data keungan. Hal ini dapat meningkatkan resiko kehilangn informasi sensitif, jika terdapat pembobolan sistem keamanan Retail Retail [3] adalah sebuah rakaian kegiatan dalam proses pendistribusian barang dan jasa dari pihak produsen kepada konsumen. Perusahaan retail merupakan salah satu bentuk usaha yang tidak melibatkan proses pengubahan bentuk dari produk. Retail sendiri memiliki peranan penting dalam proses pendistribusian poduk dan jasa dari produsen ke konsumen. Salah satu fungsi penting tersebut adalah pengaturan persediaan barang dengan mentukan jumlah barang yang tepat, waktu yang tepat dan tempat yang tepat secara reguler atau berkala serta menanggung resiko dalam penyimpanan persediaan sebelum barang sampai ke konsumen Metode Kualitatif Metode penelitian kualitatif [4] merupakan metode yang lebih menekankan pada aspek pemahaman secara mendalam terhadap suatu masalah dari pada melihat permasalahan untuk penelitian generalisasi. Metode ini lebih menggunakan teknik analisis mendalam (In-Dept Analysis) yaitu mengkaji masalah secara kasus perkasus karena metodologi kualitatif yakin bahwa sifat suatu masalah satu akan berbeda dengan sifat dari masalah lainnya. Tujualan dari metodologi ini bukan suatu generalisasi tatapi pemahaman secara mendalah dari suatu masalah. Penelitian kualitatif berfungsi memberikan kategori substantif dan hipotesis penelitian. II-4

5 Dasar penelitian kualitatif [4] adalah konstruktivisme yang berasumsi bahwa kenyataan itu berdimensi jamak, interaktif dan suatu pertukaran pengalaman sosial yang diinterpretasikan oleh setiap individu. Peneliti kualitatif percaya bahwa kebenaran adalah dinamis dan dapat ditemukan hanya melalui penelaahan terhadap orang-orang melalui interaksinya dengan situasi sosial mereka. Penelitian kualitatif mengkaji perspektif partisipan dengan strategi-strategi yang bersifat interaktif dan fleksibel. Penelitian kualitatif ditujukan untuk memahami fenomena-fenomena sosial dari sudut pandang partisipan. Dengan demikian arti atau pengertian penelitian kualitatif tersebut adalah penelitian yang digunakan untuk meneliti pada kondisi objek alamiah dimana peneliti merupakan instrumen kunci. Menurut Bogdan dan Biklen menjelaskan bahwa bahwa ciri-ciri metode penelitian kualitatif [4] ada lima yaitu: 1. Penelitian kualitatif mempunyai setting yang alami sebagai sumber data langsung, dan peneliti sebagai instrumen kunci. 2. Penelitian kualitatif adalah penelitian yang deskriptif. Data yang dikumpulkan lebih banyak kata-kata atau gambar-gambar daripada angka. 3. Penelitian kualitatif lebih memperhatikan proses daripada produk. Hal ini disebabkan oleh cara peneliti mengumpulkan dan memaknai data, setting atau hubungan antar bagian yang sedang diteliti akan jauh lebih jelas apabila diamati dalam proses. 4. Peneliti kualitatif mencoba menganalisis data secara induktif. 5. Penelitian kualitatif menitikberatkan pada makna bukan sekadar perilaku yang tampak Waterfall Model Sejarah Waterfall Model Nama model ini sebenarnya adalah Linear Sequential Model [5]. Model ini sering disebut dengan Classic Life Cycle atau Waterfall Model. Model ini pertama kali yang diperkenalkan oleh Winston Royce sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam II-5

6 Software Engineering. Model ini melakukan pendekatan secara sistematis dan berurutan. Disebut dengan Waterfall Model karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan Pengertian Waterfall Model Waterfall Model [5] adalah model yang dikembangkan untuk pengembangan perangkat lunak, membuat perangkat lunak. model berkembang secara sistematis dari satu tahap ke tahap lain dalam mode seperti air terjun. Model ini mengusulkan sebuah pendekatan kepada pengembangan Software yang sistematikdan sekuensial yang mulai dari tingkat kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Model ini melingkupi aktivitas-aktivitas sebgai berikut : rekayasa dan pemodelan sistem informasi, analisis kebutuhan, desain, koding, mengujian dan pemeliharaan. Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan sistem yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya Karakteristik Waterfall Model Dalam model ini terdapat beberapa sifat-sifat yang menojol dan cenderung menjadi permasalahan pada model waterfall. Berikut adalah karakteristik Waterfall Model : a. Ketika problem muncul, maka proses berhenti karena tidak dapat menuju ke tahapan selanjutnya. Apabila terdapat kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul. b. Karena pendekatannya secara sekuensial, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya. II-6

7 Tahapan Waterfall Model Tahapan proses alur kerja dari Waterfall Model. Berikuta adalah tahapan alur kerja dari Waterfall Model : Gambar Waterfall Model [5] a. Requirement Analysis Seluruh kebutuhan Software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan Software yang diharapkan pengguna dan batasan Software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya. b. System Design Tahap ini dilakukan sebelum melakukan Coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan Hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan. c. Implementation Dalam tahap ini dilakukan pemrograman. Pembuatan Software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap II-7

8 berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum. d. Integration & Testing Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah Software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak. e. Operation & Maintenance Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru Unifield Modeling Language Unified Modeling Language [6] adalah sebuah bahasa untuk menentukan, memvisualisasikan, memkontruksikan dan mendokumentasikan Artifact (bagian dari informasi yang digunakan atau dihasilkan dalam suatu proses pembuatan perangkat lunak. Artifact dapat berupa model, deskripsi atau perangkat lunak) dari sistem perangkat lunak, seperti pada pemodelan bisnis dan system non-perangkat lunak lainnya. Unifield Modeling Language merupakan suatu kumpulan teknik terbaik yang telah terbukti sukses dalam memodelkan sistem yang besar dan kompleks. Unifield Modeling Language tidak hanya digunakan dalam proses pemodelan perangkat lunak, namun hampir dalam semua bidang yang membutuhkan pemodelan Bagian-Bagian Unifield Modeling Language Bagian-bagian utama dari Unifield Modeling Language adalah View, Diagram, Model Element, dan General Mechanism. II-8

9 a. View View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi sejumlah diagram. b. Use case View Mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang diinginkan external actors. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem lainnya. Use Case View digambarkan dalam use case diagrams dan kadang-kadang dengan activity diagrams. Use case view digunakan terutama untuk pelanggan, perancang (Designer), pengembang (Developer), dan penguji sistem (Tester). c. Logical View Mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (Class, Object dan Relationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan ke Object lain dalam suatu fungsi tertentu. Logical View digambarkan dalam Class Diagrams untuk struktur statis dan dalam State, Sequence, Collaboration, dan Activity Diagram untuk model dinamisnya. Logical View digunakan untuk perancang (Designer) dan pengembang (Developer). d. Component View Mendeskripsikan implementasi dan ketergantungan modul. Komponen yang merupakan tipe lainnya dari code module diperlihatkan dengan struktur dan ketergantungannya juga alokasi sumber daya komponen dan informasi administrative lainnya. Component View digunakan untuk pengembang (Developer). e. Concurrency View Membagi sistem ke dalam proses dan prosesor. Concurrency view digambarkan dalam diagram dinamis (State, Sequence, Collaboration, dan Activity Diagrams) dan diagram implementasi (Component dan Deployment Diagrams) serta digunakan untuk pengembang (Developer), pengintegrasi (Integrator), dan penguji (Tester). II-9

10 f. Deployment View Mendeskripsikan fisik dari sistem seperti komputer dan perangkat (Nodes) dan bagaimana hubungannya dengan lainnya. Deployment view digunakan untuk pengembang (Developer), pengintegrasi (Integrator), dan penguji (Tester). g. Diagram Diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan biasanya dialokasikan untuk View tertentu Jenis-Jenis Diagram Dalam Unified Modeling Language) [4] Adapun jenis-jenis diagram dalam Unified Modeling Language adalah sebagai berikut : a. Use Case Diagram Use Case Diagram adalah abstraksi dari interaksi antara sistem dan Actor. Use Case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah sistem dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah sistem dipakai. Use case merupakan konstruksi untuk mendeskripsikan bagaimana sistem akan terlihat di mata user. Sedangkan Use Case Diagram memfasilitasi komunikasi diantara analis dan pengguna serta antara analis dan client. b. Class Diagram Class adalah dekripsi kelompok obyek-obyek dengan Property, perilaku (operasi) dan relasi yang sama. Sehingga dengan adanya Class Diagram dapat memberikan pandangan global atas sebuah system. Hal tersebut tercermin dari Class- Class yang ada dan relasinya satu dengan yang lainnya. Sebuah sistem biasanya mempunyai beberapa Class Diagram. Class Diagram sangat membantu dalam visualisasi struktur kelas dari suatu sistem. c. Component Diagram Component Software merupakan bagian fisik dari sebuah sistem, karena menetap di komputer tidak berada di benak para analis. Komponen merupakan II-10

11 implementasi Software dari sebuah atau lebih Class. Komponen dapat berupa Sourcecode, komponen biner, atau Executable Component. Sebuah komponen berisi informasi tentang Logic Class atau Class yang diimplementasikan sehingga membuat pemetaan dari Logical View ke Component View. Sehingga Component Diagram merepresentasikan dunia nyata yaitu Component Software yang mengandung Component, Interface dan Relationship. d. Deployment Diagram Menggambarkan tata letak sebuah sistem secara fisik, menampakkan bagianbagian Software yang berjalan pada bagian-bagian Hardware, menunjukkan hubungan komputer dengan perangkat (Nodes) satu sama lain dan jenis hubungannya. Di dalam Nodes, Executeable Component dan Object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh Node tertentu dan ketergantungan komponen. e. State Diagram Menggambarkan semua State (kondisi) yang dimiliki oleh suatu Object dari suatu class dan keadaan yang menyebabkan state berubah. Kejadian dapat berupa Object lain yang mengirim pesan. State Class tidak digambarkan untuk semua Class, hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi Class berubah oleh State yang berbeda. f. Sequence Diagram Sequence Diagram digunakan untuk menggambarkan perilaku pada sebuah skenario. Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antara Object juga interaksi antar Object, sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem. g. Collaboration Diagram Menggambarkan kolaborasi dinamis sepertisequence diagrams. Dalam menunjukkan pertukaran pesan, collaboration diagrams menggambarkan Object dan hubungannya (mengacu ke konteks). Jika penekannya pada waktu atau urutan II-11

12 gunakan Sequence Diagram, tapi jika penekanannya pada konteks gunakan Collaboration Diagram. h. Activity Diagram Activity Diagram menggambarkan rangkaian aliran dari aktifitas, digunakan untuk mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktifitas lainnya seperti Use Case atau interaksi. II-12