PT Sun Artha Putra Mandiri
Standard Operating Procedure – ACR Client Approved
Nomor SOP: 0005/SAPM/SOP-FN/IX/2021
> TUJUAN
Sebagai acuan alur dan teknis pembuatan dokumentasi Acumatica Change Request (ACR) supaya permintaan
dari Client dapat terdokumentasi dengan baik dan benar.
> SCOPE
1. Tahapan-tahapan pembuatan Acumatica Change Request (ACR).
2. Teknis pembuatan Acumatica Change Request (ACR).
> DEFINISI
Acumatica Change Request (ACR) merupakan dokumen berisi detail customisasi yang akan dilakukan.
> PROSEDUR BAKU
1. REQUEST CLIENT
Request Client adalah cikal bakal terbentuknya Acumatica Change Request (ACR). Request client
yang dapat dibuatkan ACR adalah request yang tidak terdapat pada default Acumatica (gap).
Request client dapat ditemukan pada BRM bagian fit and gap pada proses assessment. Selain pada
proses assessment, request client juga dapat diperoleh saat setelah go-live.
2. PENENTUAN BUDGET CLIENT
Tim Commercial akan menentukan budget yang diperlukan untuk pengerjaan request client. Setelah
budget ditentukan akan dikonfirmasikan kepada Client untuk mengetahui apakah Client setuju atas
budget yang dibutuhkan. Penentuan budget ini hanya dibutuhkan jika request client tidak termasuk
di dalam scope implementasi (fit and gap).
3. DISKUSI DENGAN TECHNICAL
Setelah mendapatkan request dari Client, Functional akan mengolah informasi dari Client dan
mendiskusikannya dengan Technical mengenai proses bisnis, possibility, metode pengerjaan, dan
waktu development. Pada tahap ini akan link dengan SOP cek possibility Technical di SOP nomor
0002/SAPM/SOP-TC/IX/2021.
4. PEMBUATAN ACR
Pada tahap ini Functional akan membuat dokumentasi rancangan customisasi yang direquest oleh
Client berdasarkan diskusi dengan Technical. Berikut ini merupakan prosedur pengisian Acumatica
Change Request (ACR):
4.1. Header Dokumen
Pada header dokumen terdapat nomor dokumen dan Judul ACR yang akan dibuat.
4.1.1. Format Nomor ACR
ACR Number: [inisial project] no urut dokumen - inisial
project - jenis custom (screen/report) – nama
screen/report_Versi.
Contoh: ACR Number: [PL] 001-PL-Screen-Purchase Order_Ver00.
4.1.2. Judul ACR dapat dituliskan secara singkat di bawah ACR Number
Contoh: ACR Number: [PL] 001-PL-Screen-Purchase Order_Ver00
New Field in Purchase Order
4.2. Halaman Pertama
Pada halaman pertama terdapat summary ACR mengenai custom case yang akan dibuat.
4.2.1. Bagian A
4.2.1.1. Custom Request Title
Menampilkan Judul ACR atas custom yang akan
dibuat.
4.2.1.2. Summarize of Work Description
Pada bagian ini dapat dituliskan nama screen
yang akan dicustom dan penambahan field/button
pada screen tersebut. Berikut contoh penulisan
summarize of work description:
- Screen Purchase Order
- Additional Field: Tipe
- Additional Field: Penomoran
4.2.1.3. Use Case Name
Menampilkan nama use case atas custom yang akan
dibuat. Use case adalah interaksi atau dialog
antara sistem dan actor, termasuk pertukaran pesan
dan tindakan yang dilakukan oleh sistem.
4.2.1.4. Document Type
Terdapat dua pilihan yaitu New dan Custom
Existing. New dipilih apabila customisasi membuat
screen/report/GI baru atau tidak ada sebelumnya di
Acumatica. Sedangkan, custom existing dipilih
apabila custom akan dilakukan pada
screen/report/GI yang ada di Acumatica.
4.2.1.5. Develop Type
Terdapat tiga pilihan yaitu Screen, Generic
Inquiries, dan Printout Form.
- Screen
Apabila customisasi akan membentuk
screen baru, screen report baru, atau
penambahan custom seperti
field/button/fungsi pada screen existing.
- Generic Inquiries
Apabila customisasi berbentuk GI
(Generic Inquiries).
- Printout Form
Apabila customisasi akan dilakukan pada
report designer baik berupa form atau
report.
4.2.1.6. Reason of Change
Berisikan informasi mengenai alasan adanya
perubahan atau permintaan customisasi.
4.2.2. Bagian B (Document Revision)
Pada bagian ini merupakan informasi mengenai versi ACR yang
telah terbentuk. Sehingga pembaca dapat mengetahui bahwa ACR
tersebut telah direvisi berapa kali pada tanggal berapa, dan
pembuatnya siapa. Serta pada bagian ini terdapat nama screen dan
kode screen yang akan dicustom.
4.2.3. Bagian C (Estimate Duration)
Pada bagian ini terdapat estimasi durasi waktu pengerjaan
dokumen. Estimasi durasi pengerjaan dibagi menjadi:
4.2.3.1. Documentation of ACR
Waktu yang diperlukan untuk membuat dokumentasi
ACR.
4.2.3.2. Development Process
Waktu yang diperlukan untuk development.
4.2.3.3. Quality Control
Waktu yang diperlukan untuk proses QC.
4.2.3.4. User Acceptance Test
Waktu yang diperlukan untuk menunjukkan hasil
custom ke Client.
4.3. Halaman Kedua
Pada halaman kedua berisikan tanda tangan dan note yang diberikan oleh pihak
Client dan pihak Sunartha.
4.3.1. Bagian D (Requestor & Approval)
Pada bagian ini terdapat tanda tangan dari requester dan
approval yang ada di pihak Client. Requester dan approval dapat
memberikan note pada kolom note jika diperlukan.
4.3.2. Bagian E (Functional & Technical Review)
Pada bagian ini terdapat tanda tangan dari pembuat dokumen ACR,
Technical yang mengerjakan, serta approval dari tim Sunartha.
Terdapat kolom note yang diisikan untuk memberikan feedback atas
catatan/note yang diberikan oleh Client.
4.4. Halaman Ketiga
4.4.1. Bagian F (Functional Section)
Berisikan informasi mengenai detail customisasi yang akan
dikerjakan. Pembaca dapat mengetahui custom yang akan dibentuk
berdasarkan informasi pada bagian ini:
4.4.1.1. Remarks
Berisikan catatan mengenai custom yang akan
dikerjakan.
4.4.1.2. Database
Berisikan informasi database custom yang akan
dikerjakan. Berikut rincian dari database custom:
- Header
Informasi mengenai nama screen yang
akan dicustom.
- Table Name
Menampilkan table name header yang akan
dicustom.
- Field Acumatica
Menampilkan nama field tampilan
Acumatica.
- Field DAC
Menampilkan nama field pada DAC.
- Field Name
Menampilkan nama field pada database.
- Data Type
Menampilkan jenis data yang digunakan
pada field tersebut.
- Length
Menampilkan panjangnya karakter yang
dapat di-input-kan pada field tersebut.
- Primary
Menginformasikan apakah field tersebut
adalah field primary atau tidak.
- Description
Menampilkan deskripsi atas field yang
akan dicustom, seperti menginformasikan
asal data pada field yang akan ditarik
(jika berhubungan dengan screen lain).
4.4.1.3. Use Case Scenario
Menampilkan interaksi atau dialog antara sistem
dan actor, termasuk pertukaran pesan dan tindakan
yang dilakukan oleh sistem.
- Use Case Name
Menampilkan nama use case yang akan
dijabarkan.
- Deskripsi
Menampilkan deskripsi mengenai use
case yang akan dikabarkan.
- Actor
Informasi aktor yang akan melakukan
action pada use case.
- Pre-Condition
Kondisi awal ketika aktor belum
melakukan action/kondisi awal ketika
customisasi belum diterapkan.
- Post-Condition
Kondisi akhir yang diharapkan ketika
customisasi dijalankan.
- Normal Scenario
Skenario normal yang dijalankan user
sesuai dengan alur customisasi. Terdapat
interaksi atau dialog antara sistem dan
aktor yang menjalankan sistem.
- Alternate Scenario
Skenario yang tidak normal atau
menyimpang yang dilakukan aktor dan
tanggapan sistem terhadap perilaku
menyimpang tersebut.
- User Interface
Menampilkan tampilan UI sistem hasil
custom.
4.5. Halaman Keempat
Pada halaman ini terdapat catatan-catatan Technical mengenai development yang
dilakukan.
4.5.1. Bagian G (Technical Information)
4.5.1.1. PIC
Nama PIC Technical yang mengerjakan custom.
4.5.1.2. No. Telepon
Nomor telepon PIC Technical yang mengerjakan
custom.
4.5.1.3. Email
Email PIC Technical yang mengerjakan custom.
4.5.1.4. Date Start
Informasi tanggal customisasi mulai di-develop.
4.5.1.5. Date End
Informasi tanggal customisasi selesai
dikerjakan.
4.5.1.6. Duration
Menampilkan jumlah durasi yang dibutuhkan
untuk mengerjakan custom yang direncanakan pada
halaman ketiga.
4.5.2. Bagian H (Technical Section)
Bagian ini merupakan catatan Technical selama pengerjaan.
Catatan yang diinformasikan yaitu kendala, penambahan code, dan
progress.
4.5.2.1. Dev Date
Menampilkan tanggal development ketika
penambahan catatan.
4.5.2.2. Activity
Aktivitas yang dilakukan.
4.5.2.3. Comment
Catatan atas aktivitas yang dilakukan.
4.5.2.4. Paraf PIC
Paraf dari PIC Technical yang mengerjakan
custom.
4.6. Halaman Kelima
Pada halaman ini terdapat Quality Control Section dimana terdapat list field
yang perlu dilakukan QC. Apabila list telah di QC pembaca dapat memberikan
keterangan pada kolom status Pass/Fail.
4.6.1. Bagian I (Quality Control Section)
4.6.1.1. Owner Company
Nama instansi yang melakukan request custom.
4.6.1.2. System Name
Nama sistem yang akan di QC.
4.6.1.3. QC Test Date
Tanggal QC dilakukan.
4.6.1.4. Type Custom
Tipe custom yang akan di QC
4.6.1.5. Version
Versi QC yang dilakukan (versi berdasarkan
berapa kali QC dilakukan).
Pada tabel dapat dituliskan list yang akan di QC:
4.6.1.6. No
Nomor urut.
4.6.1.7. Description/Actions
Deskripsi dan action yang dilakukan pada
field/button.
4.6.1.8. Remarks
Catatan mengenai description/actions.
4.6.1.9. Validasi
Validasi yang dipasangkan pada
description/actions.
4.6.1.10. Before
Kondisi sebelum dilakukannya actions/belum
diterapkannya customisasi.
4.6.1.11. After
Kondisi setelah dilakukannya actions/telah
diterapkannya customisasi.
4.6.1.12. Status Pass/Fail
Hasil dari QC, pass (sesuai? dan fail (belum
sesuai).
4.7. Halaman Keenam
Pada halaman ini terdapat User Acceptance Test Section dimana terdapat list field
yang perlu dilakukan UAT. Apabila list telah di UAT pembaca dapat memberikan
keterangan pada kolom Status Pass/Fail.
4.7.1. Bagian J (User Acceptance Test Section)
4.7.1.1. Owner Company
Nama instansi yang melakukan request custom.
4.6.1.2. System Name
Nama sistem yang akan di QC.
4.6.1.3. User Acceptance Test Date
Tanggal QC dilakukan.
4.6.1.4. Type Custom
Tipe custom yang akan di QC
4.6.1.5. Version
Versi QC yang dilakukan (versi berdasarkan
berapa kali QC dilakukan).
Pada tabel dapat dituliskan list yang akan di UAT:
4.6.1.6. No
Nomor urut.
4.6.1.7. Description/Actions
Deskripsi dan action yang dilakukan pada
field/button.
4.6.1.8. Remarks
Catatan mengenai description/actions.
4.6.1.9. Validasi
Validasi yang dipasangkan pada
description/actions.
4.6.1.10. Before
Kondisi sebelum dilakukannya actions/belum
diterapkannya customisasi.
4.6.1.11. After
Kondisi setelah dilakukannya actions/telah
diterapkannya customisasi.
4.6.1.12. Status Pass/Fail
Hasil dari UAT, pass (sesuai? dan fail (belum
sesuai).
5. DISKUSI DENGAN TECHNICAL MENGENAI ACR FINAL
Pada tahap ini tim Functional akan mendiskusikan ACR yang telah dibuat kepada tim Technical
untuk memastikan apakah dokumentasi pada ACR sudah sesuai dan possible untuk dikerjakan.
6. DOCUSIGN ACR
ACR yang final dan siap diberikan ke Client di-docusign untuk ditandatangani secara digital.
Apabila ACR adalah ACR di luar scope implementasi maka Commercial akan mengirimkan invoice
kepada Client. Pada tahap ini akan link dengan SOP Memproses ACR Berbayar yang Telah Disetujui
Oleh Client di SOP nomor 0000/SAPM/SOP-CM/IX/2021.
7. DEVELOPMENT
ACR yang telah di-docusign dan mendapat tanda tangan penuh dari Client dikerjakan sesuai
dengan durasi yang telah ditentukan. Apabila ACR termasuk di dalam scope implementasi (fit and
gap) dapat langsung dikerjakan, jika tidak termasuk scope implementasi ACR hanya dapat
dikerjakan apabila Client telah memproses pembayaran invoice yang diberikan oleh tim Commercial.
Pada tahap ini akan link dengan SOP Development di SOP nomor 0004/SAPM/SOP-TC/IX/2021.
> FLOWCHART
