UNESCO Regional Office for Education in Asia and the Pacific, dijelaskan bahwa monitoring adalah upaya yang dilakukan secara rutin untuk mengidentifikasi pelaksanaan dari berbagai komponen program sebagaimana telah direncanakan, waktu pelaksanaan program sebagai mana telah dijadwalkan, dan kemajuan dalam mencapai tujuan program.
Menurut Nikolaos Bourbakis, Kosntantina S. Nikita and Ming Yang (2013) monitoring adalah melakukan kegiatan pengawasan untuk program atau suatu kinerja dari suatu kelompok dalam organisasi. Dari pendapat diatas didapat, bahwa monitoring adalah suatu upaya, tindakan, dan kegiatan yang bersifat mengawasi suatu kinerja program yang telah direncanakan semula agar dapat berjalan sesuai dengan tujuan program semula. Tindakan tersebut memerlukan kinerja yang ada di dalam perusahaan.
2.2 UAT (User Acceptance Test)
Dalam membangun suatu sistem, penting bagi tim proyek untuk mengetahui apakah sistem yang mereka buat atau kembangkan telah sesuai dengan apa yang diharapkan oleh klien. Untuk mengetahui hal tersebut, tim proyek harus melakukan uji coba testing dengan mengacu pada harapan klien. Harapan klien untuk suatu sistem biasanya ditetapkan di awal pengerjaan atau pembuatan dari suatu sistem. Harapan – harapan yang telah ditetapkan ini merupakan tolak ukur yang membuat tim proyek mengetahui apa saja yang masih kurang dari suatu sistem yang dibuat itu.
Menurut Roberta M. Roth, Alan Dennis dan Barbara Haley Wixom (2013,pp. 453-454), acceptance testing dibagi menjadi 2 tahap yaitu alpha testing dan beta testing. Perbedaan dari kedua testing ini terletak pada data yang digunakan saat pengujian. Alpha testing menggunakan data buatan (dummy) sedangkan beta testing menggunakan data asli (real). Pada umumnya, acceptance testing yang digunakan adalah alpha testing di mana pengujian dilakukan oleh user sendiri untuk memastikan mereka menyetujui sistem tersebut. Pengujian dengan menggunakan alpha testing bersumber dari system tests yang telah
dilakukan sebelumnya. Pengujian dengan alpha testing bertujuan untuk menjamin bahwa user telah menyetujui sistem tersebut. Sedangkan beta testing dilakukan jika sistem tersebut bersifat penting, di mana user terus memantau sistem bila terdapat error atau peningkatan yang bermanfaat. Acceptance testing sangat penting peranannya bagi keberhasilan sistem. Hal ini disebabkan karena sudut pandang pertama yang dibayangkan oleh user yaitu ketika mereka pertama kali mencoba sistem tersebut, yaitu pada saat acceptance testing itu. Oleh karena itu, acceptance testing ini harus dilaksanakan dengan sebaik-baiknya dan harus melalui system testing yang sukses terlebih dahulu.
Kriteria dari acceptance test ini adalah untuk menjaga kestabilan produk saat produk tersebut dirilis, menunjukkan keuntungan-keuntungan dari produk perangkat lunak saat diberikan kepada klien, dan memastikan bahwa produk perangkat lunak tersebut sudah sesuai dengan kriteria atau requirement yang diinginkan oleh pihak klien. Acceptance testing di desain untuk menentukan apakah perangkat lunak yang menjadi objek untuk melakukan pengujian telah sesuai dengan kriteria sehinga dapat digunakan oleh klien. Pengujian yang terpusat pada struktur dan kriteria juga dapat gagal dalam pengukuran terhadap kecocokan dari klien, dan dengan demikian gagal juga untuk melakukan pengujian terhadap value dari aplikasi otomatis untuk bisnis. Dalam melakukan user acceptance test, ada beberapa kegiatan dan peran yang akan dilakukan, diantaranya adalah sebagai berikut:
1. Klien, selaku orang yang dapat menentukan keberhasilan dari user acceptance test, harus terlibat dan melakukan acceptance test.
2. Project manager harus berpartisipasi selama proses acceptance test dengan klien (jika diperlukan).
3. Tim development harus menyelesaikan bugs dari laporan yang diberikan oleh pihak klien.
4. Mendapatkan customer sign off.
5. Memberikan pelatihan kepada klien (jika pelatihan merupakan komponen perjanjian kerja).
2.3 Testcase
Menurut Black (2013:610), Test case adalah urutan langkah-langkah, substep, dan tindakan-tindakan lain yang dilakukan secara bertahap atau paralel, atau kombinasi turutan, yang membuat kondisi pengujian yang dirancang untuk dievaluasi dari test case. Quadri dan Farooq (2014:2) mengatakan bahwa user requirement harus diketahui sebelum merancang test case. Sebuah test case harus 36 mengandung sebuah deskripsi dari output yang benar dari program untuk satu set input data.
2.4 Test Result
Menurut Perry (2013:463), seorang penguji harus mendokumentasikan hasil dari pengujian sehingga dapat diketahui hal apa yang telah tercapai ataupun yang tidak tercapai.
Dari definisi di atas, dalam melakukan suatu pengujian, penguji perlu mendokumentasikan hasil dari pengujian yang telah dilakukan untuk memberikan informasi mengenai apa yang telah tercapai ataupun tidak tercapai.
2.5 Metode Pengembangan Sistem
Metode pengembangan sistem yang digunakan adalah System Development Life Cycle (SDLC) atau biasa disebut dengan siklus hidup pengembangan sistem yaitu metode pendekatan yang sistematis dan juga berurutan pada pengembangan perangkat lunak, dimulai dengan spesifikasi kebutuhan pengguna lalu berlanjut melalui tahapan-tahapan perencanaan (planning), permodelan (modeling), konstruksi (construction), serta penyerahan sistem ke para pelanggan/pengguna (deployment), yang diakhiri dengan dukungan pada perangkat lunak lengkap yang dihasilkan (Pressman, 2012). Definisi terbaru yang diungkapkan Menurut Pressman (2015:42), model waterfall adalah model klasik yang bersifat sistematis, berurutan dalam membangun perangkat lunak. Dengan tahapan seperti pada gambar berikut :
Gambar 2.1 Waterfall Pressman (R.S Pressman,2015:42) 1. Communication (Project Initiation & Requirements Gathering)
Tahapan awal sebelum memulai suatu kegiatan, sangat diperlukan adanya komunikasi dengan customer demi memahami dan mencapai tujuan yang ingin dicapai. Hasil dari komunikasi tersebut adalah inisialisasi proyek, seperti menganalisis permasalahan yang dihadapi dan mengumpulkan data-data yang diperlukan, serta membantu mendefinisikan fitur dan fungsi software.
2. Planning ( Estimating, Scheduling, Tracking )
Tahap berikutnya adalah tahapan perencanaan yang menjelaskan tentang estimasi tugas-tugas teknis yang akan dilakukan, resiko-resiko yang dapat terjadi, sumber daya yang diperlukan dalam membuat sistem, produk kerja yang ingin dihasilkan, penjadwalan kerja yang akan dilaksanakan, dan tracking proses pengerjaan sistem.
3. Modeling ( Analysis & Design )
Tahapan ini adalah tahap perancangan dan permodelan arsitektur sistem yang berfokus pada perancangan struktur data, arsitektur software, tampilan interface, dan algoritma program. Tujuannya untuk lebih memahami gambaran besar dari apa yang akan dikerjakan.
4. Construction ( Code & Test )
Tahapan Construction ini merupakan proses penerjemahan bentuk desain menjadi kode atau bentuk/bahasa yang dapat dibaca oleh mesin.Setelah pengkodean selesai, dilakukan pengujian terhadap sistem dan juga kode yang sudah dibuat. Tujuannya untuk menemukan kesalahan yang mungkin terjadi untuk nantinya diperbaiki.
5. Deployment ( Delivery, Support, Feedback )
Tahapan Deployment merupakan tahapan implementasi software ke customer, pemeliharaan software secara berkala, perbaikan software, evaluasi software, dan pengembangan software berdasarkan umpan balik yang diberikan agar sistem dapat tetap berjalan dan berkembang sesuai dengan fungsinya. (Pressman, 2015:17)
2.5.1 Analisis Pieces
Menurut James Wetherbe (2012), PIECES adalah untuk mengoreksi atau memperbaiki sistem informasi bagi pengambil keputusan dalam suatu organisasi. Berikut ini daftar identifikasi masalah yang sesuai dengan yang dihadapi oleh organisasi.
1. Performance
Masalah organisasi yang terkait dengan performance adalah :
a. Produksi – jumlah kerja selama periode waktu tertentu. Pada bagian ini dideskripsikan situasi saat ini tentang jumlah kerja yang dibutuhkan untuk melakukan serangkaian kerja tertentu dalam satuan orang jam, orang hari, atau orang bulan. Misalnya : untuk memperioses berkas yang masuk kepada oraganisasi dibutuhkan berapa orang jam? Kemudian hal ini dianalisis apakah hasil kerja yang demikian ini sudah bagus atau perlu ada peningkatan kerja.
b. Waktu respons – penundaan rata-rata antara transaksi atau permintaan dengan respons ketransaksi atau permintaan tersebut. Pada bagian ini dideskripsikan situai saat ini tentang waktu respons yang terjadi ketika ada suatu transaksi yang masuk hingga transaksi tersebut direspons untuk diproses. Penundaan ini bisa jadi karena antrian dalam pemrosesan transaksi-transaksi sebelumnya.
2. Informations
Informasi merupakan komoditas krusial bagi pengguna akhir. Evaluasi terhadap kemampuan sistem informasi dalam menghasilkan informasi yang bermanfaat perlu dilakukan untuk menyikapi peluang dan menangani masalah yang muncul. Dalam hal ini meningkatkan kualitas informasi
tidak dengan menambah jumlah informasi, karena terlalu banyak informasi malah akan menimbulkan masalah baru. Situasi yang membutuhkan peningkatan informasi meliputi:
a. Kurangnya informasi mengenai keputusan atau situasi yang sekarang. b. Kurangnya informasi yang relevan mengenai keputusan atau situasi
sekarang.
c. Kurangnya informasi yang tepat waktu. d. Informasi tidak dalam format yang berguna. e. Terlalu banyak informasi.
f. Informasi tidak akurat.
Informasi juga dapat merupakan fokus dari suatu batasan atau kebijakan. Sementara analisis informasi memeriksa output sistem, analisis yang tersimpan dalam sebuah sistem. Permasalahan yang meliputi:
a. Data tersimpan tidak akurat – pada bagian ini dideskripsikan situasi saat ini tentang data apa saja yang tersimpan tidak akurat (tidak sama dengan kenyataannya), penyebab data yang tersimpan tidak akurat, dan dampak yang ditimbulkan ketika hal tersebut terjadi.
b. Data tersimpan tidak akurat – pada bagian ini dideskripsikan situasi saat ini tentang data apa saja yang tersimpan tidak akurat (tidak sama dengan kenyataannya), penyebab data yang tersimpan tidak akurat, dan dampak yang ditimbulkan ketika hal tersebut terjadi.
3. Economics
a. Biaya tidak diketahui – pada bagian ini dideskripsikan situasi saat ini tentang biaya yang dikeluarkan untuk memproduksi informasi, melakukan proses bisnis, dan mengambil keputusan tidak diketahui jumlahnya dan pos pembiayaannya. Selain itu juga dideskripsikan penyebab biaya tidak diketahui, dan dampak yang ditimbulkan ketika hal tersebut terjadi.
b. Biaya tidak dapat dilacak ke sumber – pada bagian ini dideskripsikan situasi saat ini tentang biaya yang dikeluarkan untuk memproduksi informasi, melakukan proses bisnis, dan mengambil keputusan tidak dapat dilacak ke sumbernya sehingga tidak dapat diketahui keakuratan biayanya.
Selain itu juga dideskripsikan penyebab biaya tidak dilacak ke sumbernya, dan dampak yang ditimbulkan ketika hal tersebut terjadi.
c. Biaya terlalu tinggi – pada bagian ini dideskripsikan situasi saat ini tentang biaya yang dikeluarkan untuk memproduksi informasi, melakukan proses bisnis, dan mengambil keputusan terlalu tinggi dan banyaknya pos pembiayaan. Selain itu juga dideskripsikan penyebab biaya terlalu tinggi, dan dampak yang ditimbulkan ketika hal tersebut terjadi.
Secara umum keuntungan-keuntungan yang didapat ketika menerapkan sistem informasi, selain yang tersebut dibawah ini masih ada lagi keuntungan-keuntungan yang lain yang secara lebih lengkap diidentifikasikan. Sehingga pada bagian ini dideskripsikan manfaat yang akan didapatkan ketika menerapkan teknologi informasi atau sistem informasi dalam menjalakan proses bisnisnya.
4. Control
Pada bagian ini dideskripsikan situasi saat ini tentang kendali terhadap aliran data dan informasi ketika keamanan atau kendali terlalu lemah sehingga data dan informasi rentan terhadap pemanfaatan oleh pihak-pihak yang tidak berwenang terhadap pemanfaatan data dan informasi tersebut. Juga ketika keamanan atau kendali terhadap aliran data dan informasi terlalu ketat sehingga sistem menjadi terbebani oleh prosedur keamanan atau kendali tersebut dan juga mengganggu kenyamanan para pengguna dan pengambil manfaat dari data dan informasi yang dihasilkan oleh sistem tersebut. Keamanan atau kontrol terlalu lemah akan menyebabkan sebagai berikut :
a. Input data tidak diedit dengan cukup b. Kejahatan terhadap data
c. Etika dilanggar pada data atau informasi – mengacu pada data atau informasi yang mencapai orang-orang yang tidak mempunyai wewenang
d. Data tersimpan secara berlebihan tidak konsisten dalam file-file atau database-database yang berbeda
f. Error pemrosesan terjadi (oleh manusia, mesin, atau perangkat lunak) g. Error pembuatan keputusan terjadi
Keamanan atau kontrol berlebihan :
h. Red tape (prosedur) birokratis memperlamban sistem i. Pengendalian mengganggu para pelanggan atau karyawan j. Pengendalian berlebihan menyebabkan penundaan pemrosesan 5. Efficiency
Efisiensi menyangkut bagaimana menghasilkan output sebanyak-banyaknya dengan input yang sekecil mungkin.Berikut adalah suatu indikasi bahwa suatu sistem dapat dikatakan tidak efisien:
a. Banyak waktu yang terbuang pada aktivitas sumber daya manusia, mesin, atau komputer.
b. Data dimasukkan atau disalin secara berlebihan. c. Data diproses secara berlebihan.
d. Informasi dihasilkan secara berlebihan.
e. Usaha yang dibutuhkan untuk tugas-tugas terlalu berlebihan. f. Material yang dibutuhkan untuk tugas-tugas terlalu berlebihan. 6. Service
Pada bagian ini dideskripsikan situasi saat ini tentang layanan yang disediakan oleh sistem yang berjalan saat ini. Sederatan kelemahan layanan data sistem telah teridentifikasi dibawah ini, berikut ini kelemahan layanan sistem yang teridentifikasi :
1. Sistem menghasilkan produk yang tidak akurat. 2. Sistem menghasilkan produk yang tidak konsisten. 3. Sistem menghasilkan produk yang tidak dipercaya. 4. Sistem tidak mudah dipelajari.
5. Sistem tidak mudah digunakan. 6. Sistem canggung untuk digunakan. 7. Sistem tidak fleksibel.
2.6 Unified Modeling Language
Unified Modeling Language (UML) adalah satu set standar teknik diagram yang memberikan representasi grafis cukup kaya untuk model setiap proyek pengembangan sistem dari analisis melalui implementasi menurut Alan Dennis (2012). Saat ini sebagian besar berorientasi objek analisis sistem dan pendekatan desain menggunakan UML untuk menggambarkan suatu sistem yang berkembang. UML menggunakan satu set yang berbeda diagram untuk menggambarkan berbagai pandangan dari sistem berkembang. Berikut adalah definisi mengenai diagram-diagram UML :
2.6.1 Use Case Diagram
Use Case Diagram merupakan inti fungsionalitas koheren yang diekspresikan sebagai transaksi-transaksi yang terjadi antara actor dan system. Menurut Alan Dennis (2012) Use case diagram merupakan suatu diagram yang menangkap kebutuhan bisnis untuk menggambarkan interaksi antara sistem dengan lingkungannya.
Tabel 2.4.1. Simbol Use Case (Alan Dennis, 2012:156)
No Simbol Nama Keterangan
1 Aktor Seseorang atau sesuatu yang
berinteraksi dengan sistem.
2 <<include>> Include
Include memungkinkan Use Case untuk menggunakan fungsional yang di sediakan oleh Use Case lainnya.
3 <<Extends>> Extends
Memungkinkan suatu Use Case memiliki kemungkinan
memperluas fungsionalitas yang disediakan oleh use case lainnya.
4 Association
Untuk mendokumentasikan aliran
-aliran logika dalam setiap Use Case.
5 System Boundary
Merupakan lingkup subjek , misalnya, sistem atau individu proses bisnis.
6 Use case
Menggambarkan bagaimana seseorang akan menggunakan sistem.
Contoh Use Case diagram:
Gambar 2.2 Use Case Diagram (Alan Dennis, 2012:157) 2.6.2 Activity Diagram
Secara grafis digunakan untuk menggambarkan rangkaian aliran aktivitas baik proses bisnis maupun use case. Menurut Alan Dennis (2012) Pegertian diagram activity adalah yang menggambarkan alur kerja bisnis independen dari
Tabel 2.4.2 Simbol Diagram Activity (Alan Dennis, 2012)
No Gambar Nama Fungsi
1 Node Awal
Merupakan tanda awal dari sebuah aktivitas.
2 Node Akhir
Merupakan tanda berakhirnya sebuah aktivitas.
3 Aktivitas Merupakan sebuah gambaran aktivitas yang terjadi.
4 Keputusan
Pilihan untuk pengambilan keputusan.
5 Percabangan
Asosiasi ini bisa dugunakan dalam percabangan menjadi 2 aktiitas
6 Penghubungan
Asosiasi ini bisa digunakan dalam penggabungan dari 2 aktivitas
7 Generalisasi Relasi antar kelas dalam activity
Contoh activity diagram :
Gambar 2.3 Activity Diagram (Alan Dennis, 2012:167) 2.6.3 Sequence Diagram
Secara grafis menggambarkan bagaimana objek berinteraksi dengan satu sama lain melalui pesan pada sekuensi sebuah use case atau operasi. Menurut Alan Dennis (2012) Diagram Sequence merupakan urutan model dinamis yang menggambarkan contoh class yang berpartisipasi dalam use case dan pesan yang lewat di antara mereka dari waktu ke waktu.
Tabel 2.4.3 Simbol Sequence Diagram (Alan Dennis, 2012)
No Gambar Nama Fungsi
1
Object1
Object
Objek merupakan instance dari sebuah class dan dituliskan tersusun secara horizontal.
berkomunikasi dengan objek, maka aktor juga dapat
diurutkan sebagai kolom.
3 Lifeline
Lifeline mengartikan keberadaan sebuah objek dalam basis waktu.
4 Activation
Activation dinotasikan sebagai sebuah kotak segi panjang yang digambar pada sebuah lifeline, mengindikasikan sebuah obyek yang akan melakukan sebuah aktifitas
5
Message
Message
Message dilakukan dengan anak panah horizontal antara activation message
mengindikasikan komunikasi antara objek
Contoh sequence diagram :
2.6.4 Class Diagram
Menggambarkan struktur object system. Diagram ini menunjukkan class object yang menyusun sistem dan juga hubungan antara class object tersebut. Menurut Alan Dennis (2012:) Diagram kelas adalah model statis yang menunjukkan kelas dan hubungan di antara kelas yang tetap konstan dalam sistem dari waktu ke waktu.
Tabel 2.4.4 Simbol Class Diagram (Alan Dennis, 2012) Nama
Komponen
Keterangan Simbol
Class
Kelas pada struktur sistem.
Class name +Atribut +Atribut +Method
Association
Asosiasi merupakan sebuah relationship paling umum antara 2 class dan dilambangkan oleh sebuah garis yang menghubungakan antara 2 class. Garis ini bisa melambangkan tipe-tipe relationship (Contoh One-to-one, one-to-many, many-to-one).
1..1 Owned by 1
Composition
Jika sebuah class tidak bisa berdiri sendiri dan harus menjadi bagian dari class yang lain maka class tersebut memiliki relasi composition terhadap class tempat dia bergantung tersebut.
Depedency
Untuk kondisi tertentu sebuah class menggunkaan class yang lain. Hal ini disebut dependency.
Aggregation
Aggregation mengindikasikan keseluruhan bagian relationship dan biasanya disebut sebagai relasi.
Contoh class diagram:
Gambar 2.5 Class Diagram (Alan Dennis, 2012:218) 2.7 Software
2.7.1 Balsamiq MockUps
Balsamiq mockup adalah program aplikasi yang digunakan dalam pembuatan tampilan user interface sebuah aplikasi. Software ini sudah menyediakan tools yang dapat memudahkan dalam membuat desain prototyping aplikasi yang akan kita buat. Software ini berfokus pada konten yang ingin digambar dan fungsionalitas yang dibutuhkan oleh pengguna.
Alih-alih menggambar sketsa (wireframe) atau prototype rancangan desain website di atas kertas balsamiq mockups membantu seorang web desainer membuat tampilan web dalam bentuk gambar di komputer. Tujuannya selain agar
membuat tampilan (desain) website menarik juga dapat menyesuaikan dengan kebutuhan customer (pelanggan). Dengan alat pembuat mockup maka seorang web desainer dapat menganalisa tata letak, desain dan fungsi.
Kelebihan Balsamiq Mockups dibanding software pembuat mockup lainnya adalah aplikasi ini berbasis cloud, disertai aplikasi desktop yang memungkinkan kita dengan cepat dan mudah membuat rancangan website. Dengan konten yang terbuat seperti dari gambaran tangan, akan membuat kita fokus pada pemecahan masalah user interface yang lebih besar, daripada pada perincian website. Di websitenya sendiri ada dua pilihan untuk para pengguna, ada versi trial for dekstop dan ada juga yang bisa kita download untuk versi dekstop. Namun ada juga yang disediakan dalam versi berbayar. Aplikasi ini bisa digunakan untuk sistem operasi Windows, Mac OS, dan Linux.
2.8 Penelitian Terdahulu
Penelitian terdahulu ini menjadi salah satu acuan dalam melakukan penelitian sehingga dapat memperkaya teori yang digunakan dalam mengkaji penelitian yang dilakukan. Dari penelitian terdahulu, tidak menemukan penelitian dengan judul yang sama seperti judul penelitian ini. Namun mengangkat beberapa penelitian sebagai referensi dalam memperkaya bahan kajian pada penelitian ini. Berikut merupakan penelitian terdahulu berupa beberapa jurnal terkait dengan penelitian yang hampir sama.
2.8.1 Sistem Informasi Monitoring Impor Studi Kasus PT. Sinar Quality Internusa Menggunakan Metode Analisa Pieces
Jurnal oleh Agita Ratnasari Talka (2017), dari Fakultas Sistem Informasi, Universitas Mercubuana dengan judul “Sistem Informasi Monitoring Impor Studi Kasus PT. Sinar Quality Internusa Menggunakan Metode Analisa Pieces”. Dalam jurnal ini menjelaskan tentang proses kegiatan impor barang, Proses bisnisnya yaitu importer tidak dapat melakukan proses impor barang sendiri karena banyaknya procedural dan persyaratan yang harus dipenuhi. Perusahaan importer melakukan kerjasama dengan freight forwarder sebagai vendor agar dapat membantu mengurus serta memenuhi persyaratan dokumentasi dan pengurusan
kepabeanan. Namun yang terjadi proses bisnis yang berjalan tidak dapat termonitor. Untuk menjawab kebutuhan bisnis tersebut dibutuhkan suatu sistem informasi project monitoring yang dapat digunakan untuk memonitoring proses bisnis yang berjalan agar sesuai dengan kebutuhan perusahaan agar aktifitas operasional lebih efektif, efisien dan transparan. Perbedaan penelitian ini adalah kasus yang dibahas lebih kepada sistem monitoring proses kegiatan impor barang sedangkan penelitian saya lebih kepada sistem monitoring proses kegiatan UAT (User Acceptance Test).
2.8.2 Aplikasi Sistem Quality Control Produk pada PT. Astra Daihatsu Motor
Jurnal oleh Sunarto (2016), dari Fakultas Sistem Informasi, Universitas Mercubuana dengan judul “Aplikasi Sistem Quality Control Produk pada PT. Astra Daihatsu Motor”. Dalam jurnal ini menjelaskan pada PT. Astra Daihatsu Motor lebih mengutamakan kualitas terhadap produk mobilnya untuk loyalitas konsumen. Adanya Quality Gate yang merupakan sistem yang menggaransi produk tersebut memenuhi standar kualitas yang telah ditetapkan oleh perusahaan. Masalah yang terjadi yaitu Quality Gate masih menghadapi kendala dalam proses kegiatannya. Yaitu proses penyerahan laporan hasil pengecekan kualitas perakitan dan part mobil kepada supervisor dan manager sering terlambat dan sering terjadi hilangnya data hasil pengecekan yang mengakibatkan terlambatnya analisa dan tindakan dari departemen terhadap kualitas barang yang NG (Not Good). Tujuan dari jurnal ini, dengan adanya aplikasi sistem Quality Control dapat meminimalisir adanya kehilangan data hasil inspeksi, menghasilkan laporan yang cepat, tepat dan akurat guna mendukung dalam kegiatan peningkatan kualitas produk. Dalam penelitian ini penulis menggunakan metode pengembangan sistem SDLC. Perbedaan penelitian ini adalah aplikasi sistem yang dibuat lebih kepada kegiatan control kualitas produk mobil sedangkan penelitian saya lebih kepada kegiatan UAT kualitas produk telekomunikasi yang ada di PT.Indosat Ooredoo.
2.8.3 Analisis Desain Input Template dan User Acceptance Test Cognos TM1 pada Perusahaan Penyedia Listrik oleh PT. Accenture.
Jurnal oleh Celia Paramita Pontoh, Vella Kristiany dan Natalia Hillary (2015), dari Jurusan Sistem Informasi, Universitas Bina Nusantara dengan judul “Analisis Desain Input Template dan User Acceptance Test Cognos TM1 pada Perusahaan Penyedia Listrik oleh PT. Accenture. Pembahasan masalah yang diambil dalam jurnal ini adalah Salah satu klien PT Accenture yaitu Perusahaan Penyedia Listrik masih menggunakan spreadsheet untuk laporan keuangan dimana penggunaan spreadsheet begitu menyita waktu dalam pengoperasian dan penyimpanan datanya. Terdapat banyak masalah dalam proses perencanaan dan anggaran yang masih tradisional yaitu dengan menggunakan spreadsheet dalam bidang keuangan beresiko terjadi human error selama proses pemindahbukuan karena prosesnya dilakukan secara manual. Metode atau solusi yang digunakan perusahaan adalah menggunakan sistem perencanaan Cognos TM1. Perusahaan Penyedia Listrik mengimplementasikan Cognos TM1 untuk membuat laporan keuangan konsolidasi perusahaan yang merupakan gabungan dari laporan-laporan keuangan dari anak dan unit-unit Perusahaan Penyedia Listrik di seluruh Indonesia. Namun sebelum proses implementasi memasuki tahap go live, perlu dilakukan UAT (User Acceptance Test) terhadap sistem yang akan digunakan agar sesuai dengan user requirement yang telah ditentukan oleh Perusahaan Penyedia Listrik. Tujuan adanya UAT pada Cognos TM1 sangat penting peranannya yaitu untuk mengetahui apakah semua persyaratan yang diberikan oleh para pemangku kepentingan (stakeholder) telah terpenuhi. Memberikan informasi laporan keuangan yang akurat, sehingga dapat menjadi acuan untuk pengambilan keputusan dan perencanaan yang akan datang, dapat menyelesaikan temuan error atau bug pada Cognos TM1 sebelum digunakan oleh end user dan hasil dari dokumentasi testing dapat digunakan kembali oleh PT Accenture sebagai referensi untuk proyek Cognos lainnya. Perbedaan penelitian ini dengan penelitian saya adalah Analisis yang diambil lebih kepada bagian Keuangan sedangkan penelitian saya lebih ke bagian Produk Quality Assurance. Dan perusahaan penyedia listrik tersebut mengimplementasikan tools Cognos TM1
untuk analisis dalam pembuatan laporan keuangannya. Sedangkan penelitian saya tidak membutuhkan tools tersebut.
