BAB 2 LANDASAN TEORI

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. 11

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 halhal 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 konfigurasikonfigurasi 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.

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. 29 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