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
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p144)
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
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p244)
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
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p187)
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
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p191)
2. Association
Merupakan class yang merepresentasikan many-to-many relationship antara
dua class lainnya.
Gambar 2.6 Contoh Association
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p188)
3. Generalization
Merupakan suatu super class yang menjelaskan properties umum kepada
kelas-kelas khusus yang disebut dengan subclass.
19
Gambar 2.7 Contoh Generalization
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p190)
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
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p410)
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
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p253)
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
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p454)
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
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p492)
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
Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2010, p558)
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