Download - RS1 2020 1 191 2101639465 2101651994 Bab2
1
BAB 2
LANDASAN TEORI
2.1 Teknik Informasi dan Sistem Informasi
Teknik informasi adalah alat yang berbasis kompuiter yang digunakan oleh
orang untuk bekerja dengan informasi dan men-support informasi dan mengolah
informasi sesuai dengan kebutuhan organisasi. Sedangkan sistem informasi
mengumpulkan, memproses, menyimpan, menganalisis, dan menyebarluaskan
informasi untuk tujuan tertentu (R.Kelly Rainer Jr., 2015)
2.2 Supply Chain
Supply Chain adalah alur material, informasi, dana dan servis dari material
mentah supplier ke pabrik atau warehouse sampai ke end customers. Supply Chain
berfungsi untuk meningkatkan kepercayaan dan kolaborasi antar mitra supply chain,
dimana akan meningkatkan transparansi supply chain dan kecepatan inventory.
Transparansi supply chain adalah kemampuan organisasi dalam supply chain untuk
melihat data relevan untuk material yang dibeli dimana material ini berpindah antar
supplier, proses produksi, dan dikirimkan sampai ke tempat penerimaan perusahaan.
Sebagai tambahan, organisasi dapat melihat data relevan pada barang outbound
dimana akan dibuat, digabungkan atau disimpan dalam inventory dan akan dikirimkan
sampai ke tempat penerimaan customer. Kecepatan inventory adalah kecepatan
perusahaan dalam mengirimkan barang sampai ke area penerimaan customer (R.Kelly
Rainer Jr., 2015).
2.3 Supply Chain Management
Fungsi dari supply chain management untuk meningkatkan cara perusahaan
menemukan material mentah sebagai bahan produksi produk atau servis dan
pengiriman sampai ke customer. Komponen supply chain management (R.Kelly
Rainer Jr., 2015):
1. Plan
Planning adalah komponen strategis dari SCM. Organisasi harus
mempunyai strategi untuk me-manage semua resource untuk
memenuhi permintaan barang atau jasa customer. Planning melibatkan
pembuatan metrics (standard yang dapat diukur) untuk me-monitor
2
supply chain dari organisasi yang dapat memastikan efesiensi, kualitas
tinggi, dan nilai yang tinggi untuk customer dengan harga terendah.
2. Source
Source adalah cara organisasi dalam memilih supplier untuk mengirimkan
barang dan jasa yang dibutuhkan untuk membuat produk atau servis. Supply
chain manager mengembangkan harga, pengiriman, dan proses pembayaran
dengan supplier dan mereka menciptakan metric untuk me-monitor dan
meningkatkan relasi perusahaan dengan supplier. Supply chain manager juga
mengembangkan proses untuk me-manage barang dan jasa inventory termasuk
receiving dan memverifikasi pengiriman dan autorisasi pembayaran supplier.
3. Make
Make adalah proses pembuatan component. Supply chain manager membuat
jadwal aktivitas yang diperlukan untuk produksi, testing, packaging dan
persiapan untuk pengiriman barang. Pada komponen ini, organisasi akan
mengukur kualitas, hasil produksi dan produktivitas pekerja.
4. Deliver
Deliver sering disebut juga sebagai logistic, dimana organisasi mengkoordinasi
penerimaan pesanan customer, mengembangkan jaringan warehouse, memilih
pembawa barang atau jasa dari perusahaan ke customer dan membuat sistem
penerimaan pembayaran dari customer.
5. Return
Supply chain manager harus membuat sistem yang responsive dan flexible
dalam menerima barang cacat, dikembalikan atau kelebihan produksi dari
customer, dan juga harus bisa men-support customer yang memiliki kesulitan
atau masalah dari barang yang dikirimkan.
3
2.4 System Development Life Cycle (SDLC)
Adalah framework yang mengidentifikasi semua aktivitas yang dibutuhkan
untuk research, membangun, deploy, dan tidak jarang me-maintain sistem informasi.
Pada umumnya, SDLC melibatkan semua aktivitas yang dibutuhkan untuk
perencanaan, analisis sistem, design, programming, testing, dan pelatihan user. Pada
SDLC terdapat metode waterfall, yaitu metode proyek mengalir turun. Model ini
berasumsi bahwa fase dapat dijalankan secara berurutan. Pertama, rencana detail
dibuat, setelah itu dilakukan identifikasi dan pengelompokan kebutuhan, berikutnya
sistem di-design sampai ke algoritma, dan dilakukan programming, testing, dan
instalasi. Namun apabila fase sudah lanjut ke tahapan berikutnya, metodologi waterfall
tidak dapat kembali ke fase sebelumnya (John W. Satzinger, 2016).
Gambar 2.1 System Development Life Cycle (Sumber: Satzinger, 2016)
2.5 Unified Modelling Language (UML)
Merupakan standart diagram dalam pembuatan model konstruksi dan notasi
yang didefinisikan oleh Object Management Group (OMG), sebagai standart dalam
pengembangan sistem. Dengan menggunakan UML, analis dan pengguna sistem dapat
memahami dan mengambarkan dalam berbagai bentuk diagram tertentu secara
spesifik yang digunakan dalam proyek pengembangan sistem (John W. Satzinger,
2016).
1.5.1 Activity Diagram
Merupakan diagram yang menjelaskan berbagai aktifitas pengguna
atau sistem, orang yang melakukan aktifitas atau aktifitas yang dilakukan oleh
4
sistem dari awal sampai akhir proses aktifitas secara berurutan (John W.
Satzinger, 2016).
Berikut simbol-simbol pada activity diagram:
Gambar 2.2 Simbol Activity Diagram (Sumber: Satzinger, 2016)
Berikut contoh activity diagram :
Gambar 2.3 Contoh Activity Diagram (Sumber: Satzinger, 2016)
1.5.2 Use Case Diagram
Merupakan bagian dari UML model yang digunakan untuk
mengilustrasikan aktifitas yang dilakukan pada sistem dan berhubungan
5
dengan pengguna. Pengertian Use case adalah aktifitas yang dilakukan pada
sistem terhadap respon dari permintaan pengguna (John W. Satzinger, 2016).
Berikut langkah untuk membuat use case diagram :
1. Mengindetifikasi semua stakeholders dan users yang terlibat sebagai
aktor pada use case diagram.
2. Menentukan apa yang stakeholder atau user butuhkan sebagai aktifitas
yang dilakukan pada use case diagram.
3. Menghubungkan aktor dengan aktifitas yang dilakukan pada use case
untuk menggambarkan dalam bentuk use case diagram.
4. Berhati-hati pada penamaan setiap use case dan mencatat bagaimana
dan kapan diagram digunakan untuk menjelaskan aktifitas yang
dilakukan oleh stakeholders dan users.
Berikut simbol-simbol yang digunakan untuk membuat use case diagram:
Gambar 2.4 Simbol Use Case Diagram (Sumber: Satzinger, 2016)
6
Berikut contoh use case diagram :
Gambar 2.5 Contoh Use Case Diagram (Sumber: Satzinger, 2016)
1.5.3 Full Use Case Descriptions
Use case descriptions merupakan informasi yang lebih detail terhadap
setiap use case dalam bentuk deskripsi. Full developed use case descriptions
adalah metode yang paling formal dalam menjelaskan suatu use case. Dengan
full developed use case description dapat meningkatkan probabilitas dalam
memahami proses bisnis dan hubungan sistem dengan proses bisnis secara
menyeluruh (John W. Satzinger, 2016).
Berikut contoh full developed use case descriptions :
7
Gambar 2.6 Contoh Full Use Case Description (Sumber: Satzinger, 2016)
1.5.4 System Sequence Diagram
Merupakan bagian dari UML diagram yang digunakan untuk
mendeskripsikan interaksi antara aktor dengan sistem dalam bentuk flow, dari
informasi yang diterima dan dikirimkan oleh aktor ke sistem (John W.
Satzinger, 2016). Berikut step pembuatan SSD berdasarakan activity diagram:
• Mengindentifikasi pesan input, berdasarkan activity diagram
• Mendeskripsikan pesan diluar hubungan aktor ke sistem dengan
menjelaskan pesan notasi sebelumnya.
8
• Mengindetifikasi dan menambahkan kondisi tertentu pada saat pesan
dimasukan, termasuk iterasi dan kondisi benar/salah.
• Mengindentifikasi pesan output yang dikembalikan oleh sistem.
Berikut simbol-simbol yang digunakan pada system sequence diagram:
Gambar 2.7 Simbol System Sequence Diagram (Sumber: Satzinger, 2016)
9
Berikut contoh system sequence diagram :
Gambar 2.8 Contoh System Sequence Diagram (Sumber: Satzinger, 2016)
1.5.5 First Cut Sequence Diagram
First cut sequence merupakan bagian dari sequence diagram yang lebih
detail. Perbedaan sequence diagram dengan first cut sequence diagram
adalah sistem pada sequence diagram menjadi objek pesan antar sistem
(John W. Satzinger, 2016).
Berikut contoh dari first cut sequence diagram:
10
Gambar 2.9 Contoh First Cut Sequence Diagram (Sumber: Satzinger, 2016)
1.5.6 Domain Class Diagram
Class adalah kategori atau klasifikasi yang digunakan untuk
mendiskripsikan kumpulan objek. Domain class adalah classes yang
mendeskripsikan masalah domain. Domain Class Diagram merupakan bagian
dari UML diagram, yang digunakan untuk memahami dan informasi data yang
dibutuhkan oleh sistem. Domain class diagram merupakan tahap awal dalam
pembuatan database. Database adalah kumpulan integrasi class data yang
diatur dan dikontrol. Database diatur dan dikonrol oleh database management
system (DBMS) merupakan sistem software komponen yang dipasang secara
terpisah dengan sistem software components lain sebagai operating systems
(John W. Satzinger, 2016). Contoh modern DBMS: Microsoft SQL Server,
Oracle, MySQL. Berikut step pembuatan domain class diagram:
1. Membuat tabel dari setiap class di domain model.
2. Menentukan primary key dari setiap tabel.
3. Menambahkan foreign keys yang merepresentasikan one-to-many.
4. Membuat tabel baru yang merepresentasikan many-to-many.
5. Merepresentasikan klasifikasi hierarki.
11
6. Menentukan integrasi referensial.
7. Evaluasi kualitas dan pengembangan yang diperlukan.
8. Memilih tipe data yang sesuai.
9. Memastikan kontrol keamanan.
Berikut contoh domain class diagram :
Gambar 2.10 Contoh Domain Class Diagram (Sumber: Satzinger, 2016)
1.5.7 First-Cut Design Class Diagram
First-Cut Design Class Diagram dibuat dengan cara melanjutkan
Domain Class Diagram (John W. Satzinger, 2016). First-Cut Design Class
Diagram memiliki langkah pembuatan sebagai berikut:
1. Membuat Domain Class Diagram.
2. Menambahkan informasi dari attribute dan PK.
3. Mengubah connector antara kelas menggunakan arrow.
12
Berikut contoh First-Cut Design Class Diagram:
Gambar 2.11 Contoh First-Cut Diagram Class Diagram (Sumber: Satzinger, 2016)
2.6 User Interface
2.6.1 User Experience
User Experience (UX) adalah konsep luas yang mencakup segala aspek
dari interaksi orang atau user dengan produk atau servis. Ketika produk adalah
aplikasi lunak, UX mencakup aksi atau tindakan, respon, presepsi, dan
perasaan dari orang atau user yang menggunakan aplikasi lunak tersebut. UX
sangat penting untuk designer dalam memikirkan pengalaman dan perasaan
user secara keseluruhan sambil mempertimbangkan desain dari sistem baru
dan teruntuk user interface (John W. Satzinger, 2016).
2.6.2 User Interface
User Interface (UI) adalah kumpulan dari input dan output yang
berinteraksi secara langsung dengan pengguna. UI merupakan bagian dari
sistem yang dilihat dan berinteraksi langsung dengan user. Karena UI adalah
bagian yang dilihat oleh user, menurut mereka UI adalah sistem. Desain UI
bervariasi tergantung dari beberapa faktor seperti tujuan tampilan, karakteristik
user, dan karakterisktik dari perangkat yang digunakan. Sebagai contoh
meskipun UI didesain untuk memudahkan penggunaan, hal lain yang harus
dipertimbangkan seperti efesiensi operasional, target user yang mungkin sudah
dilatih untuk tampilan spesifik yang sudah dioptimisasi, hardware spesifik
yang digunakan (contoh keyboard, mouse, tampilan dengan resolusi tinggi). Di
sisi lain, User Interface dapat didesain menyesuaikan dengan kemampuan
perangkat user seperti telepon gengam sebagai perangkat input / output (John
W. Satzinger, 2016).
13
2.7 Client and Server Architecture
Dalam perancangan suatu sistem terdapat client/server architecture sebagai
metode pengorganisasian perangkat lunak dalam menyediakan dan mengakses
informasi dan sumber daya komputasi yang dibagi menjadi 2 kelas yaitu client dan
server. Dalam client/server architecture terdapat three-layer architecture yang
menggunakan untuk semua tipe dari sistem, dari penggunaan internal desktop
applications sampai didistribusikan web based application (John W. Satzinger, 2016).
Three-layer architecture dibagi menjadi 3 layer yaitu:
• View layer
Menerima dan menampilkan informasi hasil pemrosesan dari masukan
user.
• Domain layer
Mengimplementasikan aturan dan prosedur berdasarkan proses bisnis
• Data layer
Mengatur penyimpanan data, biasanya menggunakan 1 atau lebih database
2.8 Testing
Aktivitas testing adalah kunci dari implementasi dan aktivitas deployment,
walaupun terdapat beberapa jenis dari testing yang digunakan untuk setiap jenis
proses. Testing adalah proses dalam mengamati komponen, sub-sistem, atau sistem
untuk menentukan karakteristik operasional dan apakah terdapat cacat atau tidak.
Untuk melakukan test, developer harus memenuhi kebutuhan spesifikasi untuk
fungsional dan non-fungsional. Dari spesifikasi kebutuhan dan developer testing,
Developer dapat melakukan testing software dengan mendesain dan membangun
software, menjalankan fungsi, dan melihat dengan seksama hasilnya. Jika hasil testing
menunjukan kekurangan atau cacat, maka tim projek akan menjalankan kembali
proses implementasi atau deployment sampai kekurangan berhasil diperbaiki atau
cacat berhasil dihilangkan (John W. Satzinger, 2016).
Menurut (Wahyu Nur Cholifah, 2019) pengujian adalah sekumpulan atau
rangkaian aktifitas yang direncanakan secara sistematis untuk menguji kebenaran
berdasarkan keinginan penguji atau standard penguji.
Tipe test, proses inti yang beruhungan, dan cacat terdeteksi dan karakteristik
operasional mereka mengukur dan merangkum. Hal yang penting dalam membangun
14
test dengan cara mendetailkan test case dan data. Hal yang biasanya dilampirkan pada
testing:
1. Titik mulai atau kondisi awal
2. Satu atau lebih event dimana software harus merespon
3. Respon yang diinginkan atau kondisi akhir
Tipe test berdasarkan tujuan masing – masing:
Gambar 2.12 Tipe test (Sumber: Satzinger, 2016)
2.9 Managing Implementation, Testing, and Deployment
Setelah melakukan testing dan deployment activities, kita mengerti jika
implementasi, testing dan deployment secara dalam banyak terdapat ketergantungan
antara satu sama lain yang harus diperhitungkan secara terperinci. Ketergantungan ini
harus diidentifikasi secara penuh dan dipertimbangkan ketika mengembangkan
rencana yang dapat berjalan (John W. Satzinger, 2016). Beberapa aktivitas yang harus
dipertimbangkan sebagai berikut:
a. Development order
Development order dapat secara langsung berdasarkan struktur dari sistem itu
sendiri dan permasalahan yang ada seperti, use case, testing, dan efisiensi
dalam development staff. Berikut yang termasuk development order:
- Input, Process, Output Development Order
Berdasarkan data flow pada sebuah sistem atau program. Program atau
modules dapat mendapatkan input eksternal yang dikembangkan terlebih
dahulu. Program atau modules yang memproses input (seperti mengubah
15
menjadi output) akan dikembangkan berikutnya. Program atau class yang
membuat output akan dikembangkan terakhir.
- Top-Down and Bottom-Up Development Order
Top-down development dimulai dari CEO dan terus dikerjakan ke bawah.
Bottom-up development dimulai dengan development modul secara detail
pada level yang terendah dan dibuat menuju ke arah atas sampai CEO.
- Use Case Driven Development Order
Use-case-driven development dimulai dari developers memilih use cases
mana yang ingin dijadikan sebagai fokus utama berdasarkan dari
pertimbangan meminimalisir resiko projek, efisiensi dalam menggunakan
tenaga staff, atau deploying sebagian dari sistem lebih awal. Sebagai
contoh, use cases dengan requirement yang masih tidak menentu atau
resiko teknikal yang tinggi adalah biasanya akan dimasukan kedalam
pengulangan awal.
b. Source Code Control
Tim developer memerlukan sebuah tools dalam membantu untuk
mengkoordinasi programming tasks pada project yang dikerjakan. Source code
control system (SCCS) adalah sebuah alat automasi dalam melacak file source
code dan mengkontrol perubahan pada file tersebut. SCCS menyimpan file
source code pada repository, dan bertindak seperti pustakawan yang bertugas
dalam mengimplementasi prosedur check-in dan checkout, melacak
programmer pada file apa, dan memastikan hanya orang yang memiliki
otorisasi dapat membuka repository.
c. Packaging, Installing, and Deploying Components
Jika sistem atau sub-sistem memiliki skala besar dan rumit, maka biasanya
proses deployment terdapat beberapa stages atau versions, maka dari itu
diperlukan suatu metode formal dalam mengkonfigurasi dan change
management. Berikut termasuk tipe deployment:
- Direct Deployment
Pada direct deployment, sistem baru di-install dan langsung dibuat
beroperasi, dan sistem lainnya langsung dimatikan. Biasanya direct
deployment juga disebut immediate cutover.
16
Gambar 2.13 Direct Deployement (Sumber: Satzinger, 2016)
- Parallel Deployment
Pada parallel deployment sistem lama dan sistem baru akan dibiarkan
beroperasi sampai waktu tertentu (Biasanya beberapa minggu atau bulan).
Gambar 2.14 Parallel Deployement (Sumber: Satzinger, 2016)
- Phased Deployment
Pada phased deployment, sistem di-deployed dalam beberapa Langkah atau
tahap. Setiap tahapan menambahkan komponen atau fungsi untuk
operasional sistem. Dalam setiap fase, sistem akan di-test untuk
memastikan bahwa sistem sudah siap untuk tahapan berikutnya. Phased
deployment dapat digabungkan dengan pararel deployment.
17
Gambar 2.15 Phased Deployement (Sumber: Satzinger, 2016)
2.10 Support Activities After Deployment
Pada metodologi waterfall SDLC termasuk support phase, adaptive, iterative
SDLC. Faktanya, saat ini SDLC mempertimbangkan support sebagai aktivitas project
dengan metodologi support tersendiri. Tujuan dari aktivitas support untuk
mempertahankan sistem agar tetap berjalan secara produktif. Biasanya support
dimulai dari sistem baru dijalankan sampai siklus produktif dari sistem tersebut
berakhir (John W. Satzinger, 2016). Tiga hal yang termasuk aktivitas umum pada
support:
- Maintaining the system
- Enhancing the system
- Supporting the user
2.11 Change Version and Control
Walaupun tidak termasuk dalam aktivitas formal dari implementasi atau
deployment proses inti, change and version control adalah kunci dalam me-manage
software development, testing, deployment, and support activities agar sistem dapat
terus valid dan sesuai dengan pertumbuhan dan perkembangan sistem (John W.
Satzinger, 2016). Berikut aktivitas yang termasuk change version and control:
- Versioning
18
Sistem yang kompleks dikembangkan, diinstal, dan me-maintain dalam seri
dari versi untuk mempermudah proses testing, deployment, dan support.
Memiliki beberapa versi merupakan hal yang biasa pada sistem yang di-deploy
untuk end users. Versi sistem yang dibuat pada proses development disebut test
version. Test version memiliki fitur yang sudah ter-define secara baik dan
mewakilkan langkah konkrit menuju versi final dari sistem. Test versions
menyediakan static system snapshot dan checkpoint untuk mengevaluasi
progress dari project. Jenis versioning lainnya:
a. Alpha Version
Adalah versi test yang masih belum complete namun siap untuk beberapa
level integration testing atau usability testing. Beberapa versi alpha dapat
dibuat berdasarkan ukuran dan kompleksitas dari sebuah sistem. Biasanya
umur alpha version hanya berlangsung singkat beberapa hari atau bahkan
minggu.
b. Beta Version
Adalah versi test yang lebih stabil untuk dilakukan testing dengan user
untuk periode waktu yang lebih lama. Versi ini digunakan untuk pekerjaan
langsung user dan melihat apakah terdapat masalah atau tidak yang
nantinya akan diperbaiki melalui testing pada versi ini. Versi beta biasanya
akan di-test lebih lama yaitu beberapa minggu atau bulan.
c. Production Version
Atau bisa disebut sebagai release version, atau production release adalah
versi yang sudah final dan siap digunakan untuk produksi. Biasanya jika
terdapat beberapa perbaikan kecil atau minor akan release versi baru yang
disebut maintenance release.
o Submitting Error Reports and Change Requests
Untuk me-manage resiko yang berhubungan dengan
perubahan, kebanyakan organisasi mengadopsi formal untuk semua
sistem yang berada pada development dan dalam operasi. Formal
control dibuat untuk memastikan bahwa potensi pergantian atau
perubahan dideskripsikan secara baik, dipertimbangkan, dan
direncanakan secara matang sebelum diimplementasi dan di-
deploy. Perubuhan biasanya berupa:
� Metode standart untuk laporan
19
� Review request dengan project manager atau change
control committee
� Untuk sistem operasional, perencanaan lebih untuk design
dan implementasi
o Implementing a Change
Perubahan untuk maintenance release adalah development
bertahap pada project dimana user dan technical requirements
sepenuhnya diketahui terlebih dahulu. Aktivitas analisis biasanya
terdiri atas:
Mengidentifikasi bagian apa yang harus diubah, mengamankan
source (seperti personnel) untuk mengimplementasi perubahan,
Mengatur jadwal desain dan aktivitas implementasi,
mengembangkan kriteria test dan rencana testing untuk perubahan
sistem.
2.12 Development Activities
Setelah sistem baru berhasil dikembangkan dan di-testing, sistem tersebut
harus dimasukan kedalam operation. Deployment activities melibatkan banyak
batasan seperti cost, kebutuhan dalam menjaga relasi positif dengan customer,
kebutuhan untuk men-support karyawan, kompleksitas logistical, dan resiko secara
keseluruhan perusahaan (John W. Satzinger, 2016). Berikut tahapan lain yang
diterapkan dalam project deployment selain testing:
1. Mengkonversi dan Menginisialisasi Data
Sistem operasional memerlukan database yang lengkap dan dapat
diandalakan utnuk men-support proses yang sedang berjalan. Developer harus
memastikan informasi tersebut ada pada database saat ini yang dapat
digunakan untuk proses operasional. Berikut pilihan konversi dan inisialisasi
data:
a. Reusing Existing Database
Bentuk paling sederhana dari konversi data, database sistem yang lama
digunakan kembali secara langsung oleh sistem baru dengan sedikit atau
tidak ada perubahan sama sekali pada database structure. Menggunakan
20
ulang database cukup banyak digunakan karena tingkat kesulitan yang dan
harga yang rendah karena tidak perlu membuat database dari awal.
b. Reloading Database
Merupakan bentuk yang lebih kompleks karena membuat dari awal
database structure dan meng-copy dan konversi data dari database sistem
yang lama. Pada versi yang lebih rumit, staff implementasi harus membuat
suatu program untuk mengkonversi dan men-transfer data dari database
sistem lama ke database sistem baru.
Gambar 2.16 Reloading Database (Sumber: Satzinger, 2016)
2. Melatih User
Melatih dua kelas user end user dan system operators sangat penting
dalam segala jenis project deployment. End users adalah orang yang
menggunakan sistem secara harian untuk mencapai tujuan bisnis dari sistem
tersebut. System operators adalah orang yang menggunakan sistem secara
fungsi administrative dan maintenance secara rutin untuk menjaga
kelangsungan sistem dalam beroperasi.
21
Dokumentasi dan bentuk materi training dibuat sebelum pelatihan user
secara formal dimulai. Setiap jenis dokumentasi ditargetkan untuk tujuan dan
audience yang berbeda. Secara garis besar, dokumentasi dapat dibagi menjadi
dua tipe yaitu:
a. System documentation. Deskripsi dari requirement sistem, architecture,
dan detail
b. User documentation. Deskripsi dari bagaimana user berinteraksi dengan sistem.
3. Melakukan Konfigurasi Lingkungan Produksi
Aplikasi modern dibuat dari komponen software berdasarkan standard
interaksi sebagai contoh Common Object Request Broker Architecture
(CORBA), Simple Object Access Protocol (SOAP), and Java Platform
Enterprise Edition (Java EE). Setiap standard memiliki jalan yang spesifik
dengan bagaimana cara menemukan dan berkomunikasi antara satu dengan
lainnya.
Gambar 2.17 Konfigurasi Lingkungan Produksi (Sumber: Satzinger, 2016)
22
2.13 Internet Of Things
The Internet of Things (IOT) Atau bisa disebut sebagai industrial internet.
Teknologi internet menyebar melebihi laptop, desktop, komputer tablet dan perangkat
keras lainnya yang akan dihubungkan ke internet untuk dapat dikumpulkan secara data
untuk dianalisa menggunakan analytic software. IOT dapat dibangun berdasarkan
pondasi teknologi seperti RFID, sensor, dan lainnya (Kenneth C. Laudon, 2014).
Dalam konteks sistem warehousing, IoT dapat menghubungkan komponen fisik ke
jaringan, dimana mengatur fasilitas storage dan memfasilitasi storage. (Krešimir
BUNTAK, 2019).
2.14 Inventory Management
Setiap organisasi membutuhkan inventory untuk menangani supply dan
logistics dan sebagainya. Inventory mengurangi beban supply chain dengan cara
menggabungkan kemampuan prediksi, mengatasi fluktuasi permintaan, mengurangi
resiko supply dan proteksi harga periode. Pengawasan dan control dari inventory
disebut sebagai Inventory Management (Samir Yerpude, 2018).
2.15 Smart Manufacturing
Smart manufacturing adalah tentang membuat sebuah environment dimana
semua informasi tersedia dari dalam lantai plant dan sampai supply chain tersimpan
secara real-time, terlihat dan diubah menjadi insights yang bias diterapkan. Smart
manufacturing mencakup semua aspek dari sebuah bisnis, mengurangi hambatan
antara plant operations, supply chain, desain produk dan management permintaan.
Mengaktifkan virtual tracking dari aset kapital, proses, bahan mentah dan produk,
smart manufacturing memberikan pengelihatan penuh dimana membuat supports
streamlining proses bisnis dan mengoptimisasi proses supply dan permintaan (Dr.
R.Anita, 2017).
2.16 Web of Things
WoT sangat mirip seperti IoT untuk berkomunikasi dengan sepuluh perangkat
yang tidak mirip seperti hp, anda harus meng-install sepuluh aplikasi yang tidak
berbeda. Setiap object tidak dapat bertransaksi antara data dengan antara lainnya, tapi
tidak sepenuhnya mengerti arti data. Ini adalah Web protocols seperti HTTP
23
memperkenalkan Internet, cara yang universal untuk mendeskripsikan gamabr, teks,
dan media elements sehingga mesin dapat mengerti setiap data (Empowering, 2019).
2.17 Entity Relationship Diagram
Adalah pendekatan tradisional untuk pengembangan sistem yang
menempatkan sebagian besar dari kebutuhan data untuk sistem baru dan menggunakan
entitas data untuk hal dimana kebutuhan sistem untuk menyimpan informasi. Notasi
ERD
Gambar 2.18 Contoh Entity Relationship Diagram (Sumber: Satzinger, 2016)
2.18 Kerangka Pikir
Berikut merupakan kerangka pikir peneliti dalam melakukan penelitian:
Gambar 2.19 Kerangka Pikir Penelitian
1. Menganalisa masalah pada sistem operasional
Penelitian dimulai dari menganalisa masalah pada sistem operasional
yang sedang berjalan. Menganalisa masalah ini dilakukan pada sistem yang
sedang berjalan di operasional user lapangan yang memiliki kelemahan
dan kekurangan pada sistem yang dapat ditingkatkan lagi.
24
2. Membuat list topik berdasarkan permasalahan operasional
List topik permasalahan operasional dibuat berdasarkan laporan
permasalahan yang dialami oleh user berupa laporan atau ticket yang
diterima oleh divisi CIT. Harapannya sistem yang mempunyai list
permasalahan yang banyak dapat ditingkatkan lagi.
3. Diskusi topik dengan mentor
Diskusi topik dengan mentor untuk menentukan sistem mana yang
dapat digunakan sebagai topik penelitian berdasarkan list topik
permasalahan operasional yang sudah dialami oleh user.
4. Menentukan topik skripsi yang akan digunakan
Menentukan topik skripsi berdasarkan list topik permasalahan
operasional yang dialami oleh user dan persetujuan mentor. Setelah
mendapatkan topik Analisa dan Sistem Warehouse Management System
untuk Area SPD pada PT Astra Daihatsu Motor, proses dilanjutkan ke
presentasi topik skripsi yang digunakan ke mentor dan site supervisor.
5. Presentasi topik skripsi yang digunakan ke mentor dan site supervisor
Melakukan presentasi topik Analisa dan Perancangan Warehouse
Management System untuk Area SPD pada PT Astra Daihatsu Motor.
Memberikan gambaran latar belakang sistem yang saat ini beroperasi di
lapangan dan ide yang akan diajukan pada sistem yang baru akan diajukan.
6. Menganalisa masalah pada sistem yang diangkat pada topik skripsi
Melakukan analisa masalah pada sistem yang diangkat pada topik
skripsi yaitu RFT. Pada proses analisa, dilakukan observasi langsung ke
lapangan, wawancara user operasional, dan studi pustaka.
7. Mengumpulkan kebutuhan user
Mensortir dan mengumpulkan kebutuhan user berdasarkan analisa
observasi, wawancara user operasional, dan studi pustaka yang sudah
dilakukan. Proses berikutnya membuat list kebutuhan user.
25
8. Membuat desain sistem berdasarkan kebutuhan user
Membuat desain sistem berdasarkan list kebutuhan user sebagai bentuk
solusi yang diajukan untuk permasalahan operasional yang dialami oleh
user dan kebutuhan user.
9. Memberikan kesimpulan dan saran
Setelah membuat desain sistem sebagai solusi permasalahan yang dihadapi
pada operasional lapangan dan kebutuhan baru user, memberikan
kesimpulan dan saran untuk pengembangan Warehouse Management
System untuk Area SPD pada PT Astra Daihatsu Motor ke depannya.
26