BAB 2 LANDASAN TEORI - library.binus.ac.id · Berdasarkan referensi [http 1] dalam Database Jurnal Ilmiah Indonesia yang berjudul Peranan Sistem Informasi dalam Meningkatkan Daya

11

BAB 2

LANDASAN TEORI

2.1 Teori-Teori Umum

2.1.1 Pengertian Sistem

Sistem Menurut pendapat Satzinger, J.W., Jackson, R.B., & Burd, S.D.

(2010, p6) adalah kumpulan komponen-komponen yang saling berkaitan yang

berfungsi bersama untuk mencapai beberapa hasil.

Sistem menurut pendapat O'Brien, J. A., & Marakas, G. M. (2008, p24)

adalah sekelompok komponen yang saling berkaitan dan bekerja sama kearah tujuan

bersama dengan menerima masukan-masukan dan menghasilkan keluaran dalam

proses pengelolaan transformasi atau perubahan.

2.1.2 Pengertian Informasi

Informasi menurut pendapat O'Brien, J. A., & Marakas, G. M. (2008, p24)

adalah data yang ditempatkan dalam konteks yang berarti dan berguna untuk

pengguna terakhir.

Informasi menurut pendapat Stair, R.M., & Reynolds, G.W. (2010, p5)

adalah sekumpulan fakta-fakta yang diolah dengan sedemikian caranya sehingga

memiliki nilai tambah dibalik nilai dari fakta individu itu sendiri.

12

2.1.3 Pengertian Sistem Informasi

Sistem informasi menurut pendapat Satzinger, J.W., Jackson, R.B., & Burd,

S.D. (2010, p6-7) adalah kumpulan komponen-komponen yang saling berkaitan yang

mengumpulkan, memproses, menyimpan, dan menyediakan sebagai keluaran

informasi yang dibutuhkan untuk menyelesaikan tugas-tugas bisnis.

Berdasarkan referensi [http 1] dalam Database Jurnal Ilmiah Indonesia

yang berjudul Peranan Sistem Informasi dalam Meningkatkan Daya Saing Organisasi

mendefinisikan sistem informasi adalah komponen-komponen yang saling

berhubungan dan bekerja sama untuk mengumpulkan, memproses, menyimpan, dan

mendistribusikan informasi tersebut untuk mendukung proses pengambilan

keputusan, koordinasi dan pengendalian.

2.1.4 Pengertian Analisis Sistem

Analisis sistem menurut pendapat Satzinger, J.W., Jackson, R.B., & Burd,

S.D. (2010, p4) adalah proses pemahaman dan penentuan secara rinci apa yang

seharusnya dicapai oleh sistem informasi.

Pengertian analisis sistem yang dikutip dari Database Jurnal Ilmiah

Indonesia yang berjudul Pengembangan Sistem Informasi dan Keunggulan

Kompetitif berdasarkan referensi [http 7], analisis sistem merupakan tanggung jawab

untuk pengembangan rancangan umum aplikasi-aplikasi sistem. Analisis sistem

bekerja sama dengan pemakai untuk mendefinisikan kebutuhan kebutuhan informasi.

Kebutuhan-kebutuhan informasi tersebut selanjutnya dikomunikasikan ke fungsi

perancangan sistem.

13

2.1.5 Pengertian Perancangan Sistem

Perancangan Sistem menurut pendapat Satzinger, J.W., Jackson, R.B., &

Burd, S.D. (2010, p4) adalah proses penentuan secara rinci bagaimana banyak

komponen dari sistem informasi harus diimplementasikan secara fisik.

Berdasarkan referensi [http 3] dalam Database Jurnal Ilmiah Indonesia

yang berjudul Perancangan Sistem Informasi Perhotelan Berbasis Jaringan Pada

Hotel Liberty Kota Gorontalo mendefinisikan perancangan sistem adalah sebagai

penggambaran, perencanaan dan pembuatan sketsa atau pengaturan dari beberapa

elemen yang terpisah ke dalam suatu kesatuan yang utuh dan berfungsi.

2.1.6 Pengertian Human Capital

Human Capital menurut pendapat Schermerohorn, J.R. (2011, p286) adalah

nilai ekonomi masyarakat dengan pekerjaan-terkait kemampuan, pengetahuan, ide,

energi, dan komitmen.

2.1.7 Pengertian Human Capital Management

Human Capital Management menurut Kearns, P. (2010, p20) adalah sebuah

pendekatan kepada pengelolahan orang dengan memperlakukan sebagai tingkat yang

tertinggi, persoalan strategi dan berupaya secara sistematis untuk menganalisis,

mengukur, dan mengevaluasi bagaimana mengatur kebijakan orang dan praktek

menciptakan nilai.

14

2.2 Teori-Teori Khusus

2.2.1 Object Oriented Analysis

Menurut Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010), diagram yang

digunakan di dalam object-oriented analysis adalah sebagai berikut:

2.2.1.1 Activity diagram

Activity diagram merupakan jenis workflow diagram yang menggambarkan

aktivitas pengguna di dalam sistem secara berurutan.

Gambar 2.1 Simbol dalam Activity Diagram

Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p142)

Di bawah ini merupakan penjelasan simbol-simbol yang digunakan dalam

activity diagram:

1. Swimlane

Merupakan area persegi pada activity diagram yang mewakili seluruh

aktivitas di dalamnya.

2. Starting activity

Merupakan awal dari aktivitas di dalam sistem.

15

3. Activity

Merupakan aktivitas yang dilakukan di dalam sistem.

4. Decision activity

Merupakan aktivitas yang harus dipilih.

5. Concurrent activities

Merupakan aktivitas yang dilakukan secara bersamaan atau paralel,

biasanya diawali dengan synchronization bar.

6. Synchronization bar

Merupakan simbol di dalam activity diagram yang digunakan untuk

mengendalikan pemisahan atau penyatuan beberapa aktivitas.

7. Ending activity

Merupakan akhir dari aktivitas di dalam sistem.

Gambar 2.2 Contoh Activity Diagram


16

2.2.1.2 Use Case Diagram

Use case diagram digunakan untuk menunjukkan interaksi pengguna

(actors) dengan suatu sistem. Actor merupakan pengguna dari suatu sistem yang

secara langsung berinteraksi dengan sistem itu sendiri.

Berikut ini adalah komponen-komponen dari suatu Use Case Diagram:

1. System Boundary

Menggambarkan batasan antara sistem dengan actor.

2. Use case

Menggambarkan apa yang dilakukan oleh actor di dalam sistem.

3. Actors

Menggambarkan user atau pengguna dari suatu sistem.

4. Flow

Menggambarkan hubungan antara use case dengan actor.

Gambar 2.3 Contoh Use Case Diagram


17

2.2.2 Object-Oriented Design: Design the use case realization

2.2.2.1 Domain Class Diagram

Class diagram digunakan untuk menunjukkan class dari objek tertentu di

dalam suatu sistem.

Menurut pendapat Satzinger, J.W., Jackson, R.B., & Burd, S.D (2010,

p185), class diagram memiliki tiga bagian penting, yaitu sebagai berikut:

1. Class name

Merupakan nama dari suatu class.

2. Attribute

Merupakan atribut-atribut yang dimiliki oleh suatu class.

3. Method

Menjelaskan apa saja yang bisa dilakukan oleh objek-objek di dalam suatu

class.

Gambar 2.4 Contoh Class Diagram


Hubungan di dalam class diagram ada tiga, yaitu sebagai berikut:

1. Aggregation

Merupakan hubungan antara objek dengan bagian-bagiannya di mana

bagian-bagian tersebut dapat muncul secara terpisah.

18

Gambar 2.5 Contoh Aggregation


2. Association

Merupakan class yang merepresentasikan many-to-many relationship antara

dua class lainnya.

Gambar 2.6 Contoh Association


3. Generalization

Merupakan suatu super class yang menjelaskan properties umum kepada

kelas-kelas khusus yang disebut dengan subclass.

19

Gambar 2.7 Contoh Generalization


Stereotype merupakan suatu cara untuk mengkategorikan elemen model

dengan karakteristiknya masing-masing dan ditandai dengan «» Ada beberapa

stereotype standar yang dapat ditemukan di dalam perancangan model, yaitu:

Entity class («entity») Merupakan design identifier untuk problem domain class.

1. Control class («control»)

Merupakan sebuah class yang menjadi perantara antara boundary class

dengan entity class dan bertindak sebagai switchboard antara view layer

dengan domain layer.

2. Boundary class («boundary»)

Merupakan sebuah class yang ada di batas otomatisasi suatu sistem, sebagai

contoh adalah sebuah window untuk melakukan input.

3. Data access class («dataAccess»)

Merupakan sebuah class yang digunakan untuk menerima data dari database

dan mengirim data ke dalamnya.

20

Gambar 2.8 Standard stereotypes


2.2.2.2 Sequence Diagram

Sequence diagram digunakan untuk menjelaskan interaksi beberapa objek

pada waktu tertentu secara berurutan.

Menurut pendapat Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010,

p252), notasi di dalam sequence diagram adalah sebagai berikut:

1. Actor

Merupakan pengguna yang berinteraksi secara langsung dengan sistem.

2. Input message

Merupakan pesan input dari pengguna ke dalam suatu sistem.

3. Returned value

Merupakan pesan output dari suatu sistem ke pengguna, hasil dari

pemrosesan input.

4. Object

Merupakan objek-objek yang berinteraksi di dalam sequence diagram.

5. Object lifeline

Menggambarkan urutan pesan dari atas ke bawah.

21

Gambar 2.9 Sequence Diagram


Dalam perancangan sistem perlu merancang user interface class dan data

access class. Untuk itu sequence diagram yang dirancang perlu ditambahkan data

access layer dan view layer yang disebut dengan multilayer sequence diagram.

Langkah pertama yang perlu dirancang adalah data access layer.

Beberapa hal yang perlu diperhatikan dalam mengembangkan data access

layer:

1. Inisialisasi domain objects dengan data dari suatu database.

2. Buatlah query untuk database dan kirim sebuah objek referensi.

3. Masukkan return information di dalam objek referensi.

Kemudian langkah selanjutnya dalam pembuatan Multilayer Sequence

Diagram dengan menambahkan user interface class dengan mengidentifikasi user

interface class yang merupakan bagian dari user interface design.

22

Gambar 2.10 Contoh Multilayer Sequence Diagram


2.2.2.3 Design Database

Database Management System adalah perangkat lunak sistem yang

mengelola dan mengontrol akses ke database.

Relational Database Management System adalah sebuah sistem manajemen

database yang menyimpan data ke dalam tabel.

Langkah-langkah membuat Relational Database:

1. Membuat sebuah tabel untuk setiap jenis entitas.

2. Memilih sebuah primary key untuk setiap tabel.

23

3. Menambah foreign key untuk setiap tabel untuk merepresentasikan relasi

one to many.

4. Membuat tabel baru yang merepresentasikan relasi many to many.

5. Menentukan batasan integritas referensial.

6. Mengevaluasi kualitas skema dan melakukan perubahan yang diperlukan.

7. Memilih tipe data yang sesuai dan pembatasan nilai (jika perlu) untuk setiap

bidang.

Gambar 2.11 Contoh Database Design


2.2.2.4 Design User Interface

User interface terdiri dari input dan output yang melibatkan pengguna

sistem secara langsung.

24

User-centered design merupakan koleksi teknik yang meletakkan pengguna

di tengah-tengah proses pengembangan user interface.

Ada tiga prinsip penting user-centered design, yaitu sebagai berikut:

1. Fokus awal pada pengguna dan pekerjaan mereka.

2. Evaluasi desain untuk memasikan kegunaan.

3. Gunakan pengembangan yang berulang.

Gambar 2.12 Contoh User Interface


2.2.3 Gap Analysis

2.2.3.1 Pengertian Gap Analysis

Menurut pendapat Ray, R. (2011, p163), Gap Analysis merupakan analisis

kesenjangan antara daftar kebutuhan bisnis, yang diakibatkan oleh berbagai alasan.

Sehingga dibutuhkan suatu upaya untuk mengidentifikasi bagian mana yang ternyata

mungkin memiliki gaps, sebab mustahil untuk menemukan suatu bagian yang 100%

fit atau sempurna.

25

Mengacu pada pendapat dari Bens, I. (2011, p160), Gap Analysis memiliki

arti yaitu mengidentifikasi langkah-langkah yang hilang, yang diperlukan untuk

mencapai tujuan. Gap Analysis adalah alat perencanaan yang menciptakan

pandangan bersama tentang apa yang perlu dilakukan untuk menghilangkan

kesenjanagan antara keadaan sekarang dan masa depan yang diinginkan.

2.2.3.2 Tujuan Gap Analysis

Bens, I. (2011, p160) berpendapat bahwa tujuan dari Gap Analysis adalah

untuk mendorong review realistis dari sekarang dan membantu mengidentifikasi hal-

hal yang perlu dilakukan untuk sampai pada keinginan masa depan.

Gap Analysis bertujuan untuk mengevaluasi kebutuhan pengguna terhadap

sistem dan mengidentifikasi apakah ada fit atau gap antara kebutuhan dan pengguna

dengan sistem. Fit berarti kebutuhan (requirement) terpenuhi oleh sistem. Sedangkan

Gap berarti kebutuhan (requirement) tidak terpenuhi oleh sistem.

Tujuan dari Fit Gap Analysis adalah:

1. Mengumpulkan requirement dari perusahaan.

2. Langkah awal untuk menentukan penyesuaian (customization) yang

diperlukan.

3. Memastikan sistem yang baru memenuhi kebutuhan proses bisnis

perusahaan.

4. Memastikan bahwa proses bisnis akan menjadi “best practice”.

5. Mengidentifikasi permasalahan yang membutuhkan perubahan kebijakan.

2.2.3.3 Functionality Gap (Kesenjangan Fungsi)

Functionality Gap dibagi menjadi lima jenis, yaitu:

1. ERP mendukung proses, tetapi perusahaan melakukan dengan cara yang

berbeda tanpa alasan.

26

Jika perusahaan memiliki cara yang berbeda dalam menjalankan proses

bisnis (misalnya: proses pengadaan) dari apa yang disarankan oleh ERP

standar, maka kesenjangan ditemukan. Perusahaan sering mengotomatisasi

cara yang mereka lakukan sekarang dan hal itu mungkin memerlukan

perkembangan dalam ERP. Proses ini harus diselidiki secara rinci dan jika

tidak ada manfaat khusus dalam melakukannya dimana cara tersebut

berbeda dari ERP, maka proses ini perlu diubah dengan cara ERP.

2. ERP mendukung proses, tetapi perusahaan melakukan dengan cara yang

berbeda untuk alasan tertentu.

Ini adalah proses dimana perusahaan ingin melakukan bagian dari proses

secara berbeda dari standar ERP untuk alasan bisnis yang spesifik.

3. ERP tidak mendukung proses

Dalam banyak kasus, ini adalah proses industri tertentu atau perusahaan

tertentu. Perbedaan dengan sebelumnya adalah pengganti bagian dari

proses, proses penuh itu sendiri tidak didukung. Pengembangan kategori ini

kompleks dan mungkin memerlukan biaya dan usaha yang besar. Solusi

ERP semakin berusaha untuk menjembatani kesenjangan ini dengan

pemahaman yang lebih baik dari kebutuhan spesifik industri dan solusi

industri yang baru. Namun, jumlah kesenjangan (gap) selalu diharapkan

muncul dalam kategori ini dan biasanya dapat dijumpai oleh konfigurasi-

konfigurasi atau mengembangkan "Perangkat Tambahan" dari pembawaan

yang kompleks.

4. ERP sendiri tidak akan mendukung proses dan membutuhkan baut

tambahan.

27

Hal ini biasanya didefinisikan sebagai scope creep. Misalnya, setiap solusi

ERP memiliki kemampuan optimasi (yang adalah aplikasi rantai pasokan

perencanaan). Jika beberapa kebutuhan memerlukan perencanaan, melihat

kapasitas yang sebenarnya tersedia dalam dasar penjualan atau berdasarkan

kendala, maka solusi ERP tidak akan berada dalam posisi untuk

melakukannya. Dengan cara yang sama, jika seseorang ingin mengelola

seluruh proses pengembangan semua produk dalam ERP, ada kemungkinan

yang tinggi memiliki area dimana ERP tidak mendukung hal ini (ini

didukung oleh kategori khusus dari aplikasi yang disebut Product Lifecycle

Management atau PLM)

5. ERP dapat mendukung proses tetapi kebutuhan bisnis seperti daftar

keinginan

Dalam banyak kasus kebutuhan bisnis adalah pernyataan, daftar keinginan

atau yang sangat generik seperti “ERP harus memberikan visibilitas dari

ujung ke ujung”. Merupakan hal yang penting untuk terlebih dahulu

mendefinisikan ruang lingkup kebutuhan dengan sangat jelas dan batasan

untuk sesuatu yang dapat dikelola dan dapat dicapai selama jangka waktu

proyek. Ekspektasi manajemen dari pengguna bisnis adalah penting disini

karena kadang-kadang dalam mencoba untuk mencapai hal ini mungkin

membutuhkan banyak investasi dalam hal waktu dan biaya dengan hasil

yang sangat sedikit. Sebagian dari kesenjangan ini mungkin tetap sebagai

kesenjangan dan perusahaan hanya perlu meninggalkan kesenjangan

mereka.

28

2.2.3.4 Cara Melakukan Gap Analysis

Menurut Bens, I. (2011, p160), ada enam langkah dalam melakukan Gap

Analysis, yaitu:

a. Langkah 1: Mengidentifikasi situasi mendatang. Menggunakan alat seperti

visi atau pendekatan lain yang menghasilkan gambar dimana suatu

kelompok ingin berada pada waktu tertentu. Deskripsi dari gambaran masa

depan harus rinci. Melakukan posting informasi di sisi kanan dinding

kosong yang besar.

b. Langkah 2: Mengidentifikasi situasi sekarang. Menjelaskan komponen yang

sama yang ditampilkan dalam situasi mendatang, hanya melakukannya

dalam sekarang ini. Sekali lagi, sangat rinci. Melakukan posting ide-ide

yang dihasilkan di sisi kiri dinding ruang kerja.

c. Langkah 3: Meminta anggota untuk bekerja dengan mitra

untukmengidentifikasi kesenjangan (gap) antara masa sekarang (present)

dan masa depan (future).

d. Langkah 4: Ketika mitra telah menyelesaikan diskusi mereka, berbagi ide

sebagai kelompok total dan melakukan posting kesenjangan antara

"sekarang" dan "masa depan".

Gambar 2.13 Langkah-langkah Melakukan Gap Analysis

Sumber: Bens, I. (2011), Facilitating with Ease!: core skills for facilitators, team

leaders,and members, managers,consultants, and trainers.

29

e. Langkah 5: Ketika ada kesepakatan mengenai kesenjangan, maka akan

membagi kelompok besar menjadi beberapa subkelompok. memberikan

setiap kelompok satu atau lebih item kesenjangan untuk memecahkan

masalah atau melakukan rencana tindakan.

f. Langkah 6: Memasang kembali seluruh kelompok untuk mendengar

rekomendasi dan rencana tindakan. Mintalah anggota untuk mengesahkan

rencana, kemudian membuat mekanisme tindak lanjut ke depan.

2.2.3.5 Tahap Menganalisis Gap

Tahap selanjutnya dalam tahap analisis adalah menentukan tingkat

kesesuaian (degree of fit) diantara kebutuhan pengguna dan perangkat lunak, serta

menentukan sejauh mana kebutuhan atau requirement dapat diakomodir oleh sistem

yang baru. Kategori ini terdiri dari:

Tabel 2.1 Degree of Fit dalam Analisis Gap

Kode Nama Keterangan

F Fit Kebutuhan seluruhnya dapat dipenuhi oleh software. G Gap Software tidak dapat memenuhi kebutuhan pengguna.

Kritik (komentar) dan saran alternatif yang dibuat akan menghasikan rekomendasi untuk melakukan customization terhadap software.

P Partial Fit Software mempunyai fungsi yang memenuhi kebutuhan. Perubahan sementara, laporan khusus atau customizations, akan dibutuhkan agar dapat memenuhi kebutuhan secara maksimal di kemudian hari.

2.2.3.6 Gap Development Options

Ray, R. (2011, p168) berpendapat bahwa ada empat cara yang berbeda di

mana sistem ERP dapat disesuaikan untuk memenuhi persyaratan, yaitu:

1. Customer Development (Pengembangan Pelanggan): Sistem ERP berisi

namespace dari pelanggan dimana perusahaan tertentu tersebut kepunyaan

30

sendiri (dalam hal ini perusahaan menerapkan solusi ERP) tempat

penyimpanan objek dapat diciptakan.

2. Enhancements (Perangkat Tambahan): Hal ini memungkinkan pelanggan

untuk meningkatkan tempat penyimpanan objek ERP tanpa menggunakan

modifikasi.

3. Customising (Penyesuaian): Hal ini adalah dimana parameter sistem

ditetapkan. Penyesuaian merupakan bagian wajib dalam menyiapkan sistem

ERP.

4. Modification (Modifikasi): Modifikasi adalah perubahan ke tempat

penyimpanan objek ERP. Ketika sistem ditingkatkan, semua versi dari objek

yang dimodifikasi harus dibandingkan dengan versi ERP yang baru dan

disesuaikan.

2.2.4 Konsep Modul Time and Labor PeopleSoft HCM

2.2.4.1 Attendance

Attendance bedasarkan referensi [http 8] PeopleSoft Enterprise Time and

Labor 9.1 PeopleBook (2010) adalah suatu kejadian dimana seorang karyawan

menghadiri jadwal kerja yang telah dijadwalkan.

Jadwal kerja mempunyai beberapa fungsi:

1. Menyediakan fasilitas untuk membuat, melihat, dan mengelolah jadwal

2. Menyampaikan dan mengelolah ekspektasi kerja

3. Mengaktifkan perkiraan biaya tenaga kerja

4. Menyediakan data administrasi waktu yang dapat digunakan untuk

mengevaluasi waktu yang dilaporkan

5. Menerima jadwal dari sistem eksternal

31

6. Menyediakan informasi jadwal yang dapat dikirimkan ke time collection

devices

Langkah-langkah dalam membuat jadwal kerja:

1. Membuat shifts

Terdapat tiga tipe shift kerja, yaitu:

a. Punch: jadwal kerja yang statis yang telah ditetapkan sebelumnya.

b. Elapsed: jadwal kerja yang telah ditetapkan dimana waktu kerja

karyawan harus melebihi minimal jam kerja yang telah ditetapkan

dalam satu minggu.

c. Flex: jadwal kerja yang telah ditetapkan dimana waktu masuk dan

waktu keluar kerja karyawan tidak kurang dari jam kerja yang telah

ditetapkan dalam satu hari.

2. Membuat workday

Workday berdasarkan referensi [http 8] PeopleSoft Enterprise Time and

Labor 9.1 PeopleBook (2010) adalah komponen pilihan dari schedule

definition yang menambahkan informasi deskriptif.

Terdapat tiga tipe workday, yaitu:

a. Fixed: pola jadwal kerja yang statis yang telah ditetapkan sebelumnya

dan hanya berubah dalam situasi khusus.

b. Rotating: pola jadwal kerja yang berputar dan telah ditetapkan

sebelumnya.

c. Dynamic: pola jadwal kerja yang tidak memiliki jadwal yang

ditetapkan.

3. Membuat schedule definition

32

Schedule definition berdasarkan [http 8] PeopleSoft Enterprise Time and

Labor 9.1 PeopleBook (2010) adalah bagian mendasar untuk menjelaskan

jadwal kerja yang berisi daftar shift dan digunakan untuk membuat

serangkaian hari kerja dalam jangka pendek atau jangka panjang.

2.2.4.2 Permission

Absence berdasarkan [http 9] PeopleSoft Enterprise Global Payroll for the

Netherlands 9.1 PeopleBook adalah suatu kejadian dimana seorang karyawan tidak

memenuhi waktu kerja yang telah dijadwalkan.

Terdapat dua jenis absence:

1. Absence entitlement: jumlah waktu ketidakhadiran yang dibayar dimana

karyawan berhak mengambil setiap jenis absence. contoh: pernikahan,

hamil.

2. Absence take: jumlah waktu ketidakhadiran yang dibutuhkan karyawan.

contoh: sakit.

Absence dapat dilakukan oleh karyawan itu sendiri dengan memilih jenis

absence, memasukkan tanggal absence, dan alasan penyebab absence. Karyawan

juga dapat melihat apakah permintaan lembur telah disetujui atau ditolak. Pada

proses persetujuan absence dimana sistem dapat menyetujui absence tersebut secara

otomatis atau membutuhkan persetujuan lebih lanjut oleh manajer.

2.2.4.3 Overtime

Overtime berdasarkan [http 10] PeopleSoft Enterprise Global Payroll for

Mexico 9.1 PeopleBook adalah suatu kejadian dimana seorang karyawan melewati

atau melebihi waktu kerja yang telah dijadwalkan.

Langkah-langkah dalam menentukan lembur:

1. Menentukan waktu lembur untuk pay group pada kalender lembur.

33

2. Menentukan parameter lembur untuk pay group.

3. Mencatat jam lembur karyawan baik harian atau mingguan.

4. Menghasilkan laporan detil lembur karyawan berdasarkan harian atau

mingguan.

Lembur dapat dilakukan oleh karyawan itu sendiri dengan memasukkan

tanggal lembur, dan alasan penyebab lembur. Karyawan juga dapat melihat apakah

permintaan lembur telah disetujui atau ditolak. Manajer dapat melihat permintaan

lembur, menyetujui atau menolak permintaan lembur, dan juga memberikan

komentar terhadap permintaan lembur.

Konsep perhitungan upah kerja lembur merujuk referensi [http 11] pada

peraturan Kepmenakertrans No. KEP.102/MEN/VI/2004: Tentang Waktu Kerja

Lembur dan Upah Kerja Lembur. Waktu kerja lembur adalah waktu kerja yang

melebihi 7 (tujuh) jam sehari dan 40 (empat puluh) jam 1 (satu) minggu untuk 6

(enam) hari kerja dalam 1 (satu) minggu atau 8 (delapan) jam sehari, dan 40 (empat

puluh) jam 1 (satu) minggu untuk 5 (lima) hari kerja dalam 1 (satu) minggu atau

waktu kerja pada hari istirahat mingguan dan atau pada hari libur resmi yang

ditetapkan pemerintah.

Peraturan perhitungan waktu kerja lembur dan upah kerja lembur adalah

sebagai berikut:

1. Apabila kerja lembur dilakukan pada hari kerja:

a. Untuk jam kerja lembur pertama harus dibayar upah sebesar 1,5 (satu

setengah) kali upah sejam.

b. Untuk setiap jam kerja lembur berikutnya harus dibayar upah sebesar

2 (dua) kali upah sejam.

34

2. Apabila kerja lembur dilakukan pada hari istirahat mingguan dan/atau hari

libur resmi untuk waktu kerja 5 (lima) hari kerja dan 40 (empat puluh) jam

seminggu, maka perhitungan upah kerja lembur:

a. Untuk 8 (delapan) jam pertama dibayar 2 (dua) kali upah sejam.

b. Jam kesembilan dibayar 3 (tiga) kali upah sejam.

c. Jam kesepuluh dan kesebelas dibayar 4 (empat) kali upah sejam.

2.3 Kerangka Pikir

Di bawah ini disajikan kerangka pikir yang merupakan landasan atau alur

tahapan yang dilakukan dalam penulisan Standarisasi Modul Time and Attendance

berbasis Oracle PeopleSoft Human Capital Management.

35

Gambar 2.14 Kerangka Pikir Penulisan Standarisasi Modul Time and Attendance

Berbasis Oracle PeopleSoft Human Capital Management

BAB 2 LANDASAN TEORI - library.binus.ac.id · Berdasarkan referensi [http 1] dalam Database Jurnal Ilmiah Indonesia yang berjudul Peranan Sistem Informasi dalam Meningkatkan Daya

Documents