Bab 4

RANCANGAN

4.1 Proses Bisnis

4.1.1 BPMN Level Manajerial
BPMN merupakan pemodelan proses bisnis yang memperluas denisi interaksi

dan mendenisikan perancangan pada proses bisnis. Pada Gambar 4.1 menje-

laskan BPMN Level Manajerial pada Pendaftaran Lembaga Keagamaan. Pada

sistem ini terdapat 3 swimlane pool yaitu Pemohon, Loket Pendaftaran, dan

Kantor Pusat. Swimlane pool digunakan untuk memisahkan dan mengelom-

pokan aktor. Tahap awal proses bisnis pada Pendaftaran Lembaga Keagamaan

dimulai dari pemohon datang ke Kanwil lalu menyampaikan keperluan terkait

pembuatan SKT kemudian loket pendaftaran memberikan formulir yang akan

diisi oleh pemohon, setelah selesai mengisi formulir pemohon scan formulir dan

dokumen persyaratan tersebut kemudian pemohon mengirim berkas tersebut

melalui email lalu menunggu balesan email tersebut. Jika berkas pengajuan

yang dikirim oleh pemohon tidak disetujui maka pemohon diminta untuk da-

tang ke Kanwil lagi untuk mengulang proses pendaftaran dan terakhir jika

berkas pengajuan disetujui oleh kantor pusat maka pemohon diminta datang

kembali ke Kanwil untuk mengambil surat keterang terdaftar (SKT).

25
 26

Gambar 4.1: BPMN Level Manajerial Pendaftaran Lembaga Keagamaan

4.1.2 Business Process Reengineering (BPR)

Business Process Reengineering (BPR) adalah mendesain ulang terhadap pro-

ses bisnis untuk menigkatkan kinerja proses dengan melakukan analisis terlebih

dahulu terhadap proses yang telah ada sebelumnya. Pada Gambar 4.2 proses

bisnis pada Pendaftaran Lembaga Keagamaan mengalami perubahan atau di-

lakukan proses reengineering. Proses bisnis sebelumnya memiliki tiga aktor,

kemudian setelah dilakukan reengineering bertambah menjadi 6 aktor. Pro-

ses reengineering yang dilakukan untuk mempercepat proses sehingga dapat

memangkas waktu dari proses bisnins sebelumnya. Proses diawali oleh pe-

mohon yang langsung dapat melakukan registrasi akun kemudian login pada

sistem tanpa harus datang ke Kanwil. Setelah itu pemohon mengisi form ber-

upa data lembaga dan mengupload persyaratan berkas pengajuan. Setelah

berkas pengajuan berhasil di submit, pemohon langsung dapat melihat status

permohonan berkas secara berkala pada sistem.

 27

Gambar 4.2: BPR Pendaftaran Lembaga Keagamaan

Jika berkas pengajuan sudah disetujui semua hingga Dirjen, maka pemo-

hon sudah dapat mengunduh Surat Keterangan Terdaftar (SKT) tanpa harus

mendatangi kanwil begitupun sebaliknya jika berkas pengajuan tidak disetujui,

pemohon hanya perlu mengulang upload dokumen pada sistem tanpa harus

mendatangi kanwil. Dalam business proses yang diatas maka dibutuhkan nya

penambahan sebuah sistem untuk menampung data-data berkas pada pendaf-

taran lembaga keagamaan.

4.2 Pemodelan IDEF0

IDEF0 adalah metode dalam mendesain untuk pengambilan keputusan. Me-

tode ini memodelkan keputusan, tindakan, aktivitas, proses, dan operasi pada

bisnis atau sistem. Pemodelan ini dilakukan untuk komunikasi perspektif fung-

sional dari suatu sistem. Model IDEF0 menggambarkan fungsi yang termasuk

suatu sistem termasuk data dan infromasi yang terkait dengan fungsi tersebut.
 28

4.2.1 Hirarki Aktivitas

Hirarki aktivitas ini dibuat untuk memberikan nomor atau proses id pada seti-

ap proses sehingga dapat memudahkan dalam melakukan pemodelan. Hirarki

aktivitas dapat dilihat pada gambar berikut ini.

Gambar 4.3: Hirarki Aktivitas

A0 Website Pendaftaran Lembaga Keagamaan

A1 Registrasi
A11 Pengisian Form Registrasi

A12 Pengecekan Data

A13 Proses Pembuatan Akun Baru Pemohon

A2 Login
A21 Pengisian Form Login

A22 Pengecekan Level

A23 Proses Masuk Ke Halaman Pemohon atau admin

A3 Pengajuan Pendaftaran Berkas

A31 Pengisian Form Persyaratan Berkas Pengajuan

A32 Proses Pengecekan Berkas Pengajuan

A4 Pengecekan Status Berkas

A41 Tampilan Persetujuan Berkas

A42 Tampilan Hasil Surat Keterangan Terdaftar

4.2.2 Pemodelan Fungsi IDEF0

Untuk memahami proses secara keseluruhan maka dilakukan pemodelan fung-

si menggunakan IDEF0. Pemodelan ini dilakukan berdasarkan aktivitas yang

terjadi pada sistem website pendaftaran lembaga keagamaan. Pada Gambar

4.4 dijelaskan proses A0 yang merupakan proses awal dari semua proses yang
 29

ada. Proses A0 merupakan juga kerangka proses dari proses yang lain secara

detail. Pada proses ini terdapat input yang merupakan data-data pendaftaran

lembaga keagaaman. Kemudian terdapat control dari proses ini yang terdiri

dari form registrasi, form login, prosedur verikasi berkas, prosedur persetuju-

an berkas. Terdapat aktor yang berperan atas proses tersebut yaitu unit-unit

registrasi. Terakhir yang menjadi output dalam proses ini adalah registrasi,

login, hasil verikasi berkas, hasil persetujuan berkas, dan SKT atau surat

keterangan terdaftar.

Gambar 4.4: IDEF0 Proses A0

Pada Gambar 4.5 merupakan IDEF0 proses A1,A2,A3, dan A4 yaitu proses

apa saja yang dilakukan oleh sistem website pendaftaran lembaga keagama-

an. Pada proses A1 yaitu register merupakan proses pembuatan akun baru,

pada bagian ini yang termasuk input pada proses adalah data pendaftaran

akun. Kemudian yang merupakan control dari proses ini adalah form register.

Proses A1 menghasilkan output yaitu akun baru yang merupakan bagian dari

input proses A2. Proses A2 yaitu login yang mempunyai control form login.

Kemudian output dari proses A2 yaitu akun yang telah terdaftar yang akan

menjadi salah satu bagian input dari proses A4. Proses A3 yaitu pengajuan

pendaftaran berkas merupakan proses prosedur verikasi berkas dan proses

persetujuan berkas, pada bagian ini yang termasuk input pada proses adalah

data berkas pengajuan. Kemudian yang merupakan control dari proses ini

adalah form pengisian berkas pengajuan. Proses A3 menghasilkan output yai-

tu hasil status berkas. Setelah itu terdapat proses A4 yaitu pengecekan status
 30

berkas yang mempunyai input berupa data-data berkas pengajuan dan akun

terdaftar yang merupakan hasil dari output A2. Proses A4 mempunyai control

yaitu hasil persetujuan berkas pengajuan , kemudian proses A4 menghasilkan

output yaitu surat keterangan terdaftar atau SKT semua proses ini dilakukan

oleh unit-unit pendaftaran.

Gambar 4.5: IDEF0 Proses A1,A2,A3 dan A4

Pada gambar 4.6 merupakan IDEF0 proses A11,A12,dan A13 yang meru-

pakan penjelasan dari A1 secara lebih detail yaitu register. Pada proses A11

yaitu pengisian form registrasi yang menjadi input adalah informasi data pen-

daftar. Kemudian terdapat control pada proses ini yaitu nama,email,password,

dan konrmasi password. Proses A11 ini menghasilkan output yaitu data peng-

guna baru yang merupakan bagian dari input pada proses A12. setelah itu ter-

dapat proses A12 yaitu pengecekan data mempunyai input yang merupakan

bagian dari output dari A11 yaitu data pemohon baru. Proses A12 mempu-

nyai control prosedur pengecekan data. Kemudian menghasilkan output data

terkonrmasi yang merupakan bagian dari proses A13. Pada proses selanjut-

nya yaitu A13 merupakan proses pembuatan akun baru. proses ini mempunya

input yang merupakan bagian dari output pada proses A12 yaitu data terkon-

formasi. Kemudian proses ini mempunyai control prosedur pembuatan akun

baru. proses ini menghasilkan output akun baru berhasil dibuat. Seluruh

proses yang terjadi pada A11,A12,dan A13 dilakukan oleh unit pendaftar.
 31

Gambar 4.6: IDEF0 Proses A11,A12 dan A13

Pada Gambar 4.7 merupakan proses A21,A22, dan A23 yang merupakan

penjelasan dari proses A2 lebih detail yaitu login. Pada proses A21 yaitu

pengisian form login mempunyai input informasi data pendaftar. Kemudi-

an proses A21 ini mempunyai control yaitu email dan password. Proses ini

menghasilkan output data lengkap yang menjadi bagian dari input pada pro-

ses A22. Selanjutnya terdapat proses A22 yaitu pengecekan data mempunyai

input data lengkap yang merupakan hasil output dari proses A21. Proses ini

menghasilkan data terkonrmasi yang akan menjadi bagian input dari proses

A23. Proses selanjutnya adalah A23 yaitu proses masuk ke halaman mempu-

nyai input yang merupakan output dari proses A22 yaitu data terkonrmasi.

Kemudian proses A23 mempunyai control yang sama dengan proses A22 yaitu

prosedur pengecekan data. Proses A23 menghasilkan output yaitu masuk ke

halaman. Seluruh proses yang terjadi pada A21,A22 dan A23 dilakukan oleh

unit pendaftar.
 32

Gambar 4.7: IDEF0 Proses A21,A22 dan A23

Pada Gambar 4.8 merupakan proses A31, dan A32 yang merupakan pen-

jelasan dari proses A3 lebih detail yaitu pengajuan pendaftaran berkas. Pada

proses A31 yaitu pengisian form persyaratan berkas pengajuan mempunyai

input informasi data pendaftar. Kemudian proses A31 ini mempunyai control

yaitu nama lembaga, alamat, no.tlp, email, surat permohonan, surat rekomen-

dasi kanwil, surat keputusan, susunan pengurus lembaga, foto ktp, sekretaris

dan bendahara. Proses ini menghasilkan output data lengkap yang menjadi

bagian dari input pada proses A32. Selanjutnya terdapat proses A32 yaitu

pengecekan berkas pengajuan mempunyai input data lengkap,kurang lengkap,

dan tidak lengkap yang merupakan hasil output dari proses A31. Kemudian

proses A32 mempunyai control yaitu prosedur verikasi berkas dan prosedur

persetujuan berkas. Proses A32 menghasilkan output yaitu data hasil perse-

tujuan berkas.Seluruh proses yang terjadi pada A31 dan A32 dilakukan oleh

unit pendaftaran.
 33

Gambar 4.8: IDEF0 Proses A31 dan A32

Pada Gambar 4.9 dijelaskan proses A41 dan A42 proses ini merupakan

penjelasan dari proses A4 secara lebih detail yaitu pengecekan status berkas.

Proses A41 memiliki input data-data berkas pengajuan yang telah di unggah

oleh pendaftar. Kemudian mempunyai kontrol prosedur verikasi berkas serta

persetujuan berkas dan menghasilkan output status berkas berupa tampilan

halaman yang berisi alur berkas berjalan. Selajutnya proses A42 memiliki

input prosedur verikasi berkas. Kemudian mempunyai control prosedur per-

setujuan berkas dan menghasilkan output surat keterangan terdaftar atau SKT

dengan tampilan halaman hasil surat keterangan terdaftar berupa lembar PDF

yang bisa di unggah oleh pemohon. Seluruh proses yang terjadi pada A41 dan

A42 dilakukan oleh unit-unit pendaftaran.

Gambar 4.9: IDEF0 Proses A41 dan A42

 34

4.3 Task Model

Task model dibuat dan dirancang menggunakan bantuan Hierarchial Task

Analysis (HTA). Keluaran HTA adalah hirarki task dan sub task serta ren-

cana yang menggambarkan urutan dan kondisi yang memunkinkan sub task

berjalan. Pada penelitian ini penulis membuat beberapa HTA untuk bagi-

an pemohon, Operator Tanda Daftar, Kasi Penguatan Lembaga, Kasubdit

Kelembagaan, Direktur Urusan, dan Dirjen. Tujuannya adalah untuk meng-

gambarkan aktivitas setiap kelompok dalam melakukan pendaftaran lembaga

keagamaan. Berikut ini merupakan Task Model dari pengguna sistem.

1. Pemohon

1.1 Melakukan Register

1.2 Melakukan Login

1.3 Mengajukan berkas pendaftaran

1.4 Melihat status berkas

Berdasarkan task di atas dapat digambarkan Hierarchial Task

Analysis (HTA) dari sisi pemohon Pada Gambar 4.10

Gambar 4.10: HTA Pemohon

Berdasarkan Gambar 4.10 terdapat perluasan yang dapat dilakukan oleh

Pemohon. Adapun perluasan task tersebut adalah sebagai berikut :

 35

1.1 Melakukan Register

ˆ Mengisi nama

ˆ Mengisi email

ˆ Mengisi password

ˆ Mengisi Password Conrmation

1.2 Melakukan Login

ˆ Mengisi email

ˆ Mengisi password

ˆ Berhasil masuk ke akun.

1.3 Mengajukan berkas pendaftaran

ˆ Mengisi Nama lembaga

ˆ Mengisi Alamat

ˆ Mengisi No Tlp

ˆ Upload surat permohonan

ˆ Upload surat Rek.Kanwil

ˆ Upload Susunan Lembaga

ˆ Submit

1.4 Melihat Status Berkas

ˆ Edit berkas

ˆ Download SKT

2. Operator Tanda Daftar yang berkepentingan dalam melakukan

verikasi kelengkapan berkas.

2.1 Melakukan Login

 36

2.2 Melakukan Verikasi

Berdasarkan task di atas dapat digambarkan Hierarchial Task

Analysis (HTA) dari sisi Operator Tanda Daftar pada Gambar 4.11

Gambar 4.11: HTA Operator Tanda Daftar

Adapun perluasan task tersebut adalah sebagai berikut :

2.1 Melakukan Login

ˆ Mengisi email

ˆ Mengisi password

ˆ Berhasil masuk ke akun

2.2 Melakukan Verikasi kelengkapan berkas

ˆ Memilih berkas

ˆ View atau melihat berkas

ˆ Pilih status kelengkapan berkas

ˆ Kirim

3. Kasi Penguatan Lembaga yang berkepentingan dalam melakukan

verikasi dan menyetujui berkas

3.1 Melakukan login

3.2 Melakukan verikasi berkas

 37

3.3 Melakukan persetujuan berkas

Berdasarkan task di atas dapat digambarkan Hierarchial Task

Analysis (HTA) dari sisi Kasi Penguatan Lembaga pada Gambar

4.12

Gambar 4.12: HTA Kasi Penguatan Lembaga

Adapun perluasan task tersebut adalah sebagai berikut :

3.1 Melakukan Login

ˆ Mengisi email

ˆ Mengisi password

ˆ Berhasil masuk ke akun

3.2 Melakukan verikasi berkas

ˆ Memilih berkas

ˆ View atau melihat berkas

3.3 Melakukan persetujuan berkas

ˆ Pilih setuju atau tidak setuju

ˆ Kirim

4. Kasubdit Kelembagaan yang berkepentingan dalam melakukan

verikasi dan menyetujui berkas
 38

4.1 Melakukan login

4.2 Melakukan verikasi berkas

4.3 Melakukan persetujuan berkas

Berdasarkan task di atas dapat digambarkan Hierarchial Task

Analysis (HTA) dari sisi Kasubdit Kelembagaan pada Gambar 4.13

Gambar 4.13: HTA Kasubdit Kelembagaan

Adapun perluasan task tersebut adalah sebagai berikut :

4.1 Melakukan Login

ˆ Mengisi email

ˆ Mengisi password

ˆ Berhasil masuk ke akun

4.2 Melakukan verikasi berkas

ˆ Memilih berkas

ˆ View atau melihat berkas

4.3 Melakukan persetujuan berkas

ˆ Pilih setuju atau tidak setuju

ˆ Kirim
 39

5. Direktur Urusan yang berkepentingan dalam melakukan perse-

tujuan berkas

5.1 Melakukan login

5.2 Melakukan persetujuan berkas

Berdasarkan task di atas dapat digambarkan Hierarchial Task

Analysis (HTA) dari sisi Direktur Urusan pada Gambar 4.14

Gambar 4.14: HTA Direktur Urusan

Adapun perluasan task tersebut adalah sebagai berikut :

5.1 Melakukan Login

ˆ Mengisi email

ˆ Mengisi password

ˆ Berhasil masuk ke akun

5.2 Melakukan persetujuan berkas

ˆ Memilih berkas

ˆ Pilih setuju atau tidak setuju

ˆ Kirim

6. Dirjen yang berkepentingan dalam melakukan persetujuan berkas

 40

6.1 Melakukan login

6.2 Melakukan persetujuan berkas

Berdasarkan task di atas dapat digambarkan Hierarchial Task

Analysis (HTA) dari sisi Dirjen pada Gambar 4.15

Gambar 4.15: HTA Dirjen

Adapun perluasan task tersebut adalah sebagai berikut :

6.1 Melakukan Login

ˆ Mengisi email

ˆ Mengisi password

ˆ Berhasil masuk ke akun

6.2 Melakukan persetujuan berkas

ˆ Memilih berkas

ˆ Pilih setuju atau tidak setuju

ˆ Kirim
 41

4.4 Interaksi Model

Dalam suatu website, penting untuk memperhatikan sistem yang berjalan agar

dapat dimengerti pengguna. Untuk melaksanakan tiap task maka ditelusuri

tahapan-tahapan yang harus dikerjakan dan interaksi yang terjadi. Interkasi

model adalah penggambaran proses pemodelan antara user dan task. Tujuan

dari interaksi model ini adalah untuk memperkirakan user dalam menggunakan

suatu task. Interaksi dapat dijelaskan menggunakan skenario task.

4.4.1 Skenario Task

Berikut ini skenario task dari pengguna sistem yaitu Pemohon, Operator Tan-

da Daftar, Kasi Penguatan Lembaga, Kasubdit Kelembagaan, Direktur Urusan

dan Dirjen.

1. Pemohon

Task 1.1 Melakukan Registrasi

Gambar 4.16: Skenario Task Register

Task 1.2 Melakukan Login

Gambar 4.17: Skenario Task Login Pemohon

Task 1.3 Mengajukan Berkas Pendaftaran

Gambar 4.18: Skenario Task Mengajukan Berkas

Task 1.4 Melihat Status Berkas

Gambar 4.19: Skenario Task Melihat Status Berkas

 42

2. Operator Tanda Daftar

Task 2.1 Melakukan Login

Gambar 4.20: Skenario Task Login Oleh Operator Tanda Daftar

Task 2.2 Melakukan verikasi kelengkapan berkas pengajuan

Gambar 4.21: Skenario Task Verikasi Kelengkapan berkas

3. Kasi Penguatan Lembaga

Task 3.1 Melakukan Login

Gambar 4.22: Skenario Task Login Oleh Kasi Penguatan Lembaga

Task 3.2 Melakukan Verikasi Berkas

Gambar 4.23: Skenario Task Verikasi Berkas Oleh Kasi Penguatan Lembaga

Task 3.3 Melakukan Persetujuan Berkas

Gambar 4.24: Skenario Task Persetujuan Berkas Oleh Kasi Penguatan Lem-
baga

4. Kasubdit Kelembagaan

Task 4.1 Melakukan Login

 43

Gambar 4.25: Skenario Task Login Oleh Kasubdit Kelembagaan

Task 4.2 Melakukan Verikasi Berkas

Gambar 4.26: Skenario Task Verikasi Berkas Oleh Kasubdit Kelembagaan

Task 4.3 Melakukan Persetujuan Berkas

Gambar 4.27: Skenario Task Persetujuan Berkas Oleh Kasubdit Kelembagaan

5. Direktur Urusan

Task 5.1 Melakukan Login

Gambar 4.28: Skenario Task Login Oleh Direktur Urusan

Task 5.2 Melakukan Persetujuan Berkas

Gambar 4.29: Skenario Task Persetujuan Berkas Oleh Direktur Urusan

6. Dirjen

Task 6.1 Melakukan Login

Gambar 4.30: Skenario Task Login Oleh Dirjen

 44

Task 6.2 Melakukan Persetujuan Berkas

Gambar 4.31: Skenario Task Persetujuan Berkas Oleh Dirjen

4.5 Interaction Design

Interaction design adalah gambaran interaksi yang dilakuan oleh pengguna

dan sistem. Digambarkan dalam bentuk wireframe, wireframe digunakan un-

tuk menjelaskan rancangan kasar sebagai kerangka awal sebuah halaman web

yang disusun secara beruntun serta dilengkapi dengan penjelasan yang meng-

ikuti peta navigasi yang telah dibuat. Penjelasan langkah-langkah ini akan

menggambarkan aktivitas yang terjadi di dalam sistem dan akan dijelaskan

apa saja yang dapat dilakukan pengguna di dalam sistem.

1. Registrasi Akun

Sebelum mengakes website pemohon harus mendaftarkan akun baru de-

ngan mengisi nama, email, password, dan password conrmation. Sete-

lah berhasil buat akun baru, data tersebut yang akan dijadikan proses

pada halaman login.

Gambar 4.32: Interaction Design Register atau Pendaftaran Akun

2. Login

Pengaksesan website memerlukan tahap login yang menjadi jalan masuk

ke halaman pengguna dengan mengisi email dan mengisi password. Pro-

 45

ses ini dilakuakan jika pengguna (pemohon) telah memiliki akun yang

dibuat pada saat registrasi.

Gambar 4.33: Interaction Design Login

3. Mengajukan Berkas Pendaftaran

Pemohon atau pendaftar bertugas mengajukan berkas untuk mendaf-

tarkan lembaga agama. Oleh karena itu disediakan form pengajuan

berkas yang dapat diakes pada saat berhasil login. Mengajukan ber-

kas pendaftaran dengan mengisi nama lembaga, mengisi alamat, mengisi

no.tlp, upload surat permohonan, upload surat rek.kanwil, upload susun-

an lembaga kemudian klik submit. Setelah klik submit maka halaman

selanjutnya adalah halaman tahapan berkas yang harus dilewati.

Gambar 4.34: Interaction Design Mengajukan Berkas Pendaftaran

4. Melihat Status Berkas Pengajuan

Halaman ini berfungsi untuk melihat status berkas yang diajukan oleh

pemohon yang berisi informasi sudah melewati tahap apa saja. Jika

berkas yang diajukan pemohon kurang lengkap atau tidak lengkap maka
 46

pemohon harus upload ulang berkas. Terakhir, jika berkas yang diajukan

pemohon telah melewati semua tahap maka dapat mendownload surat

keternagan terdaftar (SKT) berupa lembar PDF.

Gambar 4.35: Interaction Design Melihat Status Berkas Pengajuan

5. Verikasi Kelengkapan Berkas Pengajuan

Operator Tanda Daftar bertugas memverikasi kelengkapan berkas yang

diajukan oleh pemohon. Oleh karena itu disediakan halaman verikasi

berkas yang dapat diakes pada saat berhasil login. Pada gambar 4.36

merupakan Interaction Design verikasi kelengkapan berkas dengan me-

milih berkas , View atau melihat berkas, Pilih status kelengkapan berkas

dan Kirim.

Gambar 4.36: Interaction Design Verikasi Kelengkapan Berkas Pengajuan

 47

6. Verikasi dan Persetujuan Berkas Tahap 1

Kasi Penguatan Lembaga bertugas pada tahap pertama yaitu memveri-

kasi berkas dan menyetujui berkas yang diajukan oleh pemohon. Oleh

karena itu disediakan halaman verikasi dan persetujuan berkas yang

dapat diakes pada saat berhasil login. Pada gambar 4.37 merupakan

Interaction Design verikasi berkas dengan memilih berkas, View atau

melihat berkas. Kemudian melakukan persetujuan berkas dengan memi-

lih setuju atau tidak setuju lalu kirim.

Gambar 4.37: Interaction Design Verikasi dan Persetujuan Berkas Tahap 1

7. Verikasi dan Persetujuan Berkas Tahap 2

Kasubdit Kelembagaan bertugas pada tahap kedua yaitu memverikasi

berkas dan menyetujui berkas yang diajukan oleh pemohon. Oleh kare-

na itu disediakan halaman verikasi dan persetujuan berkas yang dapat

diakes pada saat berhasil login. Pada gambar 4.38 merupakan Intera-

ction Design verikasi berkas dengan memilih berkas, View atau melihat

berkas. Kemudian melakukan persetujuan berkas dengan memilih setuju

atau tidak setuju lalu kirim.

 48

Gambar 4.38: Interaction Design Verikasi dan Persetujuan Berkas Tahap 2

8. Persetujuan Berkas Tahap 3

Direktur Urusan bertugas pada tahap ketiga yaitu menyetujui berkas

yang diajukan oleh pemohon. Oleh karena itu disediakan halaman per-

setujuan berkas yang dapat diakes pada saat berhasil login. Pada gambar

4.39 merupakan Interaction design melakukan persetujuan berkas dengan

memilih setuju atau tidak setuju lalu kirim.

Gambar 4.39: Interaction Design Persetujuan Berkas Tahap 3

9. Persetujuan Berkas Tahap 4

Dirjen bertugas pada tahap keempat atau terakhir yaitu menyetujui berkas

yang diajukan oleh pemohon. Oleh karena itu disediakan halaman persetu-

juan berkas yang dapat diakes pada saat berhasil login. Pada gambar 4.40

melakukan persetujuan berkas dengan memilih setuju atau tidak setuju lalu

kirim.
 49

Gambar 4.40: Interaction Design Persetujuan Berkas Tahap 4

4.6 IDEF1 (Information Modelling)

Pada pemodelan ini dijelaskan model informasi pada proses bisnis pendaftaran

lembaga keagamaan. Dibentuk dengan sebuah matriks hubungan antar enti-

tas, sehingga dapat menyimpulkan hubungan setiap entitas pada proses bisnis

pendaftaran lembaga keagamaan. Matriks hubungan dapat dilihat pada Tabel

4.1 menggambarkan struktur tabel yang berelasi dengan tabel lainnya.

Tabel 4.1: Matrix Hubungan

Entitas Berkas Data Pemohon SKT Data Admin

Berkas X X X
Data Pemohon X X X
SKT X X
Data Admin X

Pada gambar 4.41 menjelaskan sebuah informasi yang saling berkomunikasi

antara informasi lainnya. Pertama data pemohon dibuat berdasarkan berkas

yang diisi oleh pendaftar pada saat mengisi form pengisian data dan upload

pengajuan berkas. Setelah pendaftar selesai mengisi form pengajuan berkas,

berkas tersebut masuk ke tahap verikasi dan persetujuan berkas yang dikaji

oleh 4 tahapan admin pejabat. Kemudian setelah selesai di verikasi dan dise-

tujui oleh keempat admin pejabat maka akan menghasilkan surat keterangan

terdaftar (SKT) yang nantinya akan diberikan kepada pemohon. Hubungan

antara entitas dalam setiap domain proses ditelusuri menggunakan matriks

hubungan seperti pada Tabel 4.1.

 50

Gambar 4.41: IDEF1 Pendaftaran Lembaga Keagamaan