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