KLIPedia

Kita mulai dengan presentasi awal, proposal pertama kali waktu mengajukan konsep, sebagai refreshment juga untuk yang sudah melihat. Dan sama seperti dulu yang sedikit terpengaruh presentasi IHT, kita juga ada post test.

Karena hanya refreshment dan bukan IHT asli, pertanyaan untuk post testnya sederhana saja. Apa itu KLIP?

Dan sama seperti IHT, selain post test, saya juga akan langsung share jawabannya. Share dua jawaban malah. Jawaban pertama, Kantor Layanan Informasi dan Pengaduan.

Atau yang saya sebut sebagai jawaban 5 detik. Kalau jawaban 30+ menit atau jawaban yang lebih panjang, kita lihat dari hal yang KLIP sediakan. Informasi.

Dengan sekitar 300 agent, ini sebagian besar kerja kita, apa yang kita hasilkan. Selain memberikan informasi, kita juga menerima Pengaduan.

Ketika WP ada masalah dan meminta solusi. Dari kedua hal ini, informasi dan pengaduan, bisa disimpulkan bahwa produk yang kita sediakan adalah Jawaban.

Ini adalah pikiran pertamaku, bahwa KLIP adalah pusat Jawaban. Tapi di KLIP saat ini, Jawaban bukan fokus. Di KLIP tidak ada sistem kelola Jawaban. KLIP tidak punya Knowledge Management System.

Yang ada adalah resume tkb, suatu bentuk pengetahuan tidak terpelihara. Yang kita punya adalah siklip, dengan fungsi awal berupa repositori, tempat arsip. Dan sistem yg harusnya utama dalam sistem kelola jawaban, justru terasa sekadar ada, Fitur pencarian, sistem utama dalam Knowledge Management System, khususnya pencarian dua atau lebih kata tidak berurutan.

Ini adalah fitur inti dalam Knowledge Management System. Apabila dicontohkan mencari dalam sistem yang ada saat ini, misalnya penghasilan tidak kena pajak.

Pencarian di tkb ada hasilnya, tetapi jika kita ulangi pencarian tanpa kata “kena”.

Sistem pencarian tkb hanya memfasilitasi kata-kata yang berurutan, demikian juga dengan siklip.

Sistem kita, siklip punya administrasi faq sc, tempat arsip jawaban dari sc. Ketika sc adalah assessor, entri dalam menu ini jadi bisa dianggap valid. Sekali lagi ini hasil contoh mencari penghasilan tidak pajak di siklip. Tapi misalkan kita ambil satu contoh entri yang memang ada di siklip pertanyaan terkait “SPT Tahunan” juga tentang “PPh final” apakah “dilaporkan” atau tidak masuk “perhitungan”. Jika semua keywordnya, “SPT tahunan PPh final dilaporkan perhitungan”, kita coba cari di siklip.

Tidak ada, fitur pencarian dua atau lebih keyword tidak urut itu penting untuk navigasi peraturan pajak. Karena dalam pencarian jawaban terkait peraturan pajak, akan lebih efisien dengan menggunakan keyword.

Pencarian di siklip, meski saat ini sudah lebih baik dengan memfasilitasi pencarian yang lebih fleksibel, masih belum sepenuhnya memenuhi kebutuhan kecepatan pencarian untuk melayani kebutuhan Wajib Pajak. Untuk fitur ini aku buat situs pribadi, berikut hasil pencarian contoh sebelumnya, “SPT tahunan PPh final dilaporkan perhitungan”.

Situs ini aktif aku gunakan selama agent, meski tidak sempurna, hanya 15 entri yang terlihat kutipan misalnya. Tapi bisa pencarian multi keyword. Kembali ke siklip, selain belum bisa keyword, kelemahan lainnya adalah Sentralisasi.

Waktu agent, satu hal yang bisa jadi sumber keraguan adalah adanya perbedaan jawaban.

Ini salah satu contoh di siklip, terkait penginputan bunga obligasi pph 26 dalam ebuni. Entri atas menyebut input di DOSS, tapi entri bawah menyebut di DOPP. Suatu perbedaan berpengaruh tapi bisa dimaklumi, mungkin kesalahan ketik. Tapi masalah yang utama adalah adanya 2 entri untuk 1 pertanyaan. Pengulangan kerja, pembahasan topik yang sama.

Dalam tkb sendiri bisa dibilang sudah memfasilitasi karena dalam resume bisa dibilang cukup sentral, satu resume untuk satu pembahasan. Sayangnya karakter tkb adalah bukan tipe memelihara apa yang dimiliki, hanya menyajikan. Dengan demikian banyak resume yang sebagian besar tepat tapi beberapa hal sudah tidak sesuai dengan ketentuan terbaru.

Penyajian informasi dalam bentuk seperti resume tkb juga bisa difasilitasi dalam FAQSC.

Dengan pengetahuan yang ada dalam wadah milik sendiri. Kita memiliki kesempatan untuk menjadi pemelihara pengetahuan yang ada. Dua hal utama, Pencarian Keyword serta Sentralisasi Jawaban bisa aku hadirkan sendiri secara mandiri. Tapi ada dua hal lagi yg aku ingin ada dalam knowledge management system ini, Valid dan Update.

Dua hal ini adalah alasan pengajuan proposal awal. Aku ingin ada tempat jawaban valid, kalau jawaban agent bersumber dari tempat ini, jawaban itu akan selalu dianggap benar. Kalau jawaban dianggap salah, kita update informasi sumber jawaban di tempat ini. Dua fitur sebelumnya aku bisa buat secara mandiri. Tapi dua fitur ini akan lebih mudah terwujud jika dilaksanakan bersama oleh KLIP. Menjaga Kualitas Layanan dengan menggunakan sistem pencarian yang efektif menghadirkan jawaban yang tepat. Memelihara jawaban tepat tersebut dengan pembaruan dan penyesuaian informasi dan pengetahuan secara tersistem. Sistem Pengelolaan Pengetahuan, mulai dari penggunaan hingga pemeliharaan dalam satu sumber sistem. Karena sedari awal sampai saat ini menurutku KLIP itu adalah Knowledge Management System.

Knowledge Management System yang kusebut FAQSC ini adalah wujud jawabanku atas pertanyaan post test kita, “Apa itu KLIP?”.

Titik ini adalah akhir presentasi pertama. Presentasi dengan tujuan mengangkat konsep Knowledge Management System serta FAQSC sebagai tempat dan alat untuk mewujudkannya. Presentasi dengan undangan kepada Pihak Manajemen KLIP untuk membentuk Knowledge Management System yang ideal menurut Pihak Manajemen KLIP.

Tapi ada dua hal yang kurang ditekankan dalam presentasi pertama. Hal pertama adalah pertanyaan “Apa itu KLIP?”

Pertanyaan ini pertanyaan penting yang sebelumnya belum memperoleh penekanan yang layak. Pertanyaan ini adalah blueprint bangunan. Dan tiap hari kerja di KLIP adalah hari kita mendirikan bangunan jawaban. Tiap hasil pekerjaan adalah bata penyusun wujud jawaban masing-masing pegawai KLIP. Sayangnya tidak semua sadar sudah menjawab. Seringnya jawaban yang dihasilkan hanya sekadar “menjalankan perintah”. Beberapa faktor fenomena ini adalah, ketidaktahuan dan ketidakpedulian. Tidak sadar adanya pertanyaan ini atau tidak melihat pilihan jawaban lain serta menganggap ringan inti pertanyaan. Jawaban ini aku sebut sebagai “Jawaban Apatis”. Konsep akan dikunjungi ulang nanti.

Selanjutnya adalah hal kedua yang kurang ditekankan dalam presentasi pertama, Fleksibilitas Infrastruktur. Aku kurang menekankan apa saja yang bisa dilakukan oleh Knowledge Management System. Hal yang perlu diwujudkan dalam Prototipe FAQSC.

Pertemuan pertama adalah presentasi proposal. Pertemuan kedua membahas kendala implementasi di siklip juga terkait bentuk konkret Knowledge Management System atau Prototipe FAQSC, yang tulisan ini sedang coba jabarkan.

Aku menamai bentuk konkret ini sebagai Prototipe FAQSC karena sumber inspirasi adalah administrasi faq sc yang ada di siklip. Kemudian aku membeli domain dengan nama FAQSC.xyz. Jika suatu saat Knowledge Management System ini mengubah nama FAQSC menjadi nama lain dalam Penerapan Resmi. Ini beberapa nama yang mungkin bisa dipertimbangkan:

• FASY, Frequently Asked System - Sistem yang nantinya akan kita sering beri pertanyaan.
• KLIPWiki, KLIP + Wiki - Wiki milik KLIP
• TAJAKLIP, Tanya Jawab KLIP.

Tapi untuk sementara, untuk penjabaran di halaman ini, aku akan menggunakan nama Prototipe FAQSC seperti nama sumber inspirasi. Dan seperti jawaban panjang yang aku bagikan untuk Post Test di atas, menurutku KLIP adalah Knowledge Management System. Untuk diberi kesempatan mewujudkan bentuk konkret Knowledge Management System ideal adalah sama artinya dengan diberi kesempatan membentuk KLIP ideal.

Berangkat dari dasar kerja itu, membentuk KLIP ideal akan menyinggung beberapa hal yang bisa ditingkatkan dari KLIP saat ini melalui implementasi Prototipe FAQSC. Beberapa hal yang mungkin dirasa terlalu luas. Beberapa hal juga yang menurutku cukup kontroversial.

Untuk saat ini kita mulai penjabaran Prototipe FAQSC dimulai dengan Infrastruktur.

Ini hanya akan menjadi penjabaran singkat terkait beberapa detil informasi teknis cuma sekilas saja. Tapi ada beberapa link jika berminat untuk mendalami terkait informasi teknis yang ada.

Infrastruktur yang cocok untuk mendokumentasikan pengetahuan dalam Knowledge Management System dan yang aku pilih adalah struktur Wiki.

Ini beberapa alasan Wiki bagus untuk dokumentasi pengetahuan. Banyak kemudahan, tampilan sederhana yang konsisten, serta kolaboratif.

Klik Untuk Terjemahan Indonesia:

Dan di antara banyak jenis infrastruktur Wiki, ini alasan DokuWiki dipilih menjadi pondasi Prototipe FAQSC. Utamanya adalah wujud dasar tiap entri pengetahuan ada dalam bentuk yang memudahkan untuk dipindahkan. Sehingga jika suatu saat diputuskan untuk berpindah infrastruktur, tiap pengetahuan yang dihasilkan lewat DokuWiki bisa dengan mudah dipindahkan.

Klik Untuk Terjemahan Indonesia:

Beberapa informasi fitur-fitur DokuWiki yang bisa dilihat juga di https://www.dokuwiki.org/features

Fitur-fitur yang mencakup

• Mudah digunakan
• Kendali akses
• Cepat
• Mudah dikembangkan

Detil info teknis ini cukup sekilas. Tapi ringkasannya adalah, bahwa infrastruktur DokuWiki amat fleksibel dan mampu memfasilitasi banyak hal. Termasuk dalam tampilan yang adaptif. Meski informasi teknis cukup sekilas, tapi yang perlu dicermati adalah filosofi Wiki.

Sesuai definisi dari wikipedia, Wiki adalah publikasi yang diedit secara kolaborasi. Hal ini yang ingin aku bawa ke KLIP, kolaborasi pemeliharaan Knowledge Management System, pemeliharaan KLIP. Pemeliharaan Sinergi

Dalam menyusun Prototipe FAQSC ada satu hal yang saya simpulkan ketika mengamati hal-hal yang bisa ditingkatkan dari KLIP, hal terkait sinergi. Kesimpulan yang saya tarik adalah “Semua Tanggung Jawab Akhir Ada Di Agent”.

Seiring penjabaran terkait komponen Prototipe FAQSC ini akan dijabarkan juga tentang hasil pengamatan ini. Karena kesimpulan ini juga adalah salah satu dasar pembangunan Prototipe FAQSC. Untuk saat ini tolong diingat kesimpulan ini sembari kita masuk ke 4 topik besar Prototipe FAQSC.

Prototipe FAQSC sudah berkembang melampaui 4 topik besar ini, tetapi sebagai dasar awal akan dijabarkan dari 4 topik besar ini. Dimulai dari Resume.

Hal paling kentara yang bisa ditingkatkan, Resume dari TKB, yang memang sedari awal bukan mengambil peran pemelihara. Prototipe FAQSC bisa menampilkan dan memelihara pengetahuan sesuai dengan informasi terbaru.

Saat ini menurutku paling cocok untuk dikelola oleh trainer yang ahli dalam meringkas juga menyampaikan materi pengetahuan. Mengingat trainer juga sudah memiliki banyak materi IHT yang bisa diadaptasi menjadi Resume di Prototipe FAQSC. Contohnya IHT Materi Refreshment 1771.

Contoh adaptasi bisa dilihat di link ini → Materi Refreshment 1771 Atas contoh adaptasi Materi Refreshment 1771 ini, dengan ada di Prototipe FAQSC, juga bisa difasilitasi dengan fitur pencarian keyword. Selain itu, format ini juga bisa menjadi pilihan cara menyajikan materi sebagai pengganti slide.

Tapi kalau ingin menyajikan dalam bentuk yang benar-benar slide …

Slide awal presentasi proposal juga merupakan slide yang difasilitasi dan ditampilkan lewat Prototipe FAQSC. Presentasi bisa dilihat di link ini → Slide Knowledge Management

Jika memelihara Resume dalam Prototipe FAQSC sekaligus menyusun slide IHT dirasa seperti mengerjakan 2 pekerjaan yang sama. Prototipe bisa mengubah tampilan resume menjadi tampilan slide.

Terkait template, Prototipe FAQSC juga sudah memfasilitasi template slide sesuai Standarisasi Identitas.

Contoh adaptasi bisa dilihat di link ini → Standarisasi Identitas

Jadi slide yang dihasilkan juga bisa dibuat sesuai dengan ketentuan terbaru. Tapi meski begitu tetap ada beberapa hal yang perlu diperhatikan untuk slide bentuk ini. Penyusunan Resume juga harus menyesuaikan bentuk akhir Slide. Selain itu juga ada Kelebihan Kekurangan.

Ini beberapa kelebihan dan kekurangan dari bentuk Slide Prototipe FAQSC ini. Masing-masing diwakili 3 poin karena lebih dari 3 perlu ke halaman slide lain. Dikarenakan untuk besarnya tulisan juga diusahakan bisa sesuai dengan Ketentuan Standarisasi Identitas.

Berbicara terkait Ketentuan, kita akan berlanjut ke topik besar kedua kita, Peraturan.

Peraturan sebenarnya cukup terfasilitasi di tkb. Dengan fitur pencarian isi ataupun judul ditambah filter sesuai nomor juga tahun. Fitur pencarian peraturan di tkb sudah cukup dalam membantu kerja Agent.

Meski begitu, dalam pembuatan Prototipe FAQSC ini ada 2 hal yang bisa ditingkatkan juga. Pertama adalah Format Dalam Satu Naskah (DSN) yang tersedia umum adalah untuk Peraturan besar UU PPh atau UU PPN. Prototipe FAQSC bisa memfasilitasi format DSN ini untuk peraturan minor contohnya (DSN) Ketentuan formulir SPT Tahunan atau (DSN) Ketentuan KLIP.

Peningkatan ini untuk mengurangi waktu Agent memastikan perubahan yang terjadi dalam satu Peraturan. Peningkatan lain adalah alat bantu Peraturan Hari Pertama

Hari pertama ketentuan baru dikeluarkan adalah masa Agent dituntut berjuang sendiri. Ini adalah contoh Tanggung Jawab Akhir yang dibebankan ke Agent. Di akhir hari muncul Peraturan baru, belum ada resume ataupun IHT dan pagi sudah ditanya dan sudah dituntut jawaban sempurna karena kalau salah akan dinilai jelek.

Meski tidak bisa menyalahkan Trainer mengingat materi IHT juga memerlukan waktu untuk disusun. Tetapi masih ada hal yang bisa disusun untuk menjadi alat bantu Agent menghadapi Hari Pertama ini. Salah satunya adalah Ringkasan per pasal, seperti contoh pada gambar, suatu Resume Peraturan Hari Pertama. Tentu saja bisa disesuaikan hanya per pasal atau sampai per ayat. Dilakukan oleh Seksi Penjamin Kualitas Layanan untuk memastikan bahwa hanya dengan melihat sekilas sudah memperoleh pemahaman kasar terkait Peraturan baru tersebut, menjamin kualitas layanan yang diberikan menjadi lebih cepat dibandingkan membiarkan para Agent bekerja sendiri. Contoh berbagi tanggung jawab dengan TL/SPV yang mendampingi secara real time. Seksi PKL bisa membagi beban kerja meringkas ke beberapa orang, supaya ringkasan bisa lebih cepat tersedia. Untuk prosedur praktiknya bisa jadi bahan diskusi terkait beban kerja, keefektifan, serta kecepatan peringkasan. Yang kemudian hasil diskusi bisa diwujudkan dalam suatu prosedur.

Berbicara tentang prosedur, kita akan beralih ke SOP dan Panduan.

Untuk bagian ini, kita akan mulai dengan SOP. Kemudian masuk ke bagian yang menurutku sedikit kontroversial.

Terkait SOP sebenarnya juga sudah difasilitasi di siklip. Untuk Daftar SOP di Prototipe FAQSC ini lebih ke menunjukkan bahwa Prototipe FAQSC bisa memfasilitasi pdf. Selain itu, juga penambahan fitur kemampuan pencarian atas judul SOP. Jika ingin pencarian isi, memang harus melakukan pengetikan ulang. Tapi ini ada di prioritas yang rendah. Mengingat SOP jarang dicari. Sedangkan yang sering dicari adalah kumpulan panduan

Yang sering digunakan oleh Agent adalah Buku Saku. Suatu kumpulan panduan yang saat ini beredar dalam bentuk pdf.

Hal pertama yang bisa ditingkatkan adalah dari bentuknya. Kumpulan panduan seharusnya bukan pdf yang sukar diedit, sukar diperbarui, sukar diralat. Seperti contoh di gambar, dalam panduan inbound tidak ada tahap menjawab pertanyaan. Tahap yang seharusnya ada di antara nomor 8 dan nomor 9. Melakukan perubahan untuk bentuk pdf akan lebih sulit untuk memastikan semua Agent memperoleh kumpulan panduan versi paling baru. Tetapi dengan bentuk yang ditampilkan di Prototipe FAQSC, memudahkan Agent karena tidak perlu mengunduh pdf juga memudahkan untuk mengubah panduan yang ada dengan informasi paling baru serta memastikan informasi yang ditampilkan ke semua Agent memang sama. Atau dengan kata lain Sentralisasi.

Peningkatan lain adalah kemampuan untuk menambahkan fungsi interaktif. Contoh di samping adalah terkait konversi alfabet nato yang juga sudah ditambahkan ke Buku Saku. Memberikan tools yang membantu untuk Agent mengeja kata, misalnya kode NTPN.

Berikut beberapa contoh NTPN yang bisa diinput di kotak konversi untuk mencoba langsung fitur tambahan:

• 1B2DF67K42NQLN7D
• C485183A1JC1O1J3
• F1B5E0T35396S983
• 889285DU4A32MA5O
• 28DDC836JPQ7TBI7
• 4A8480VQL575QHVN

Dan penambahan fungsi bisa dilakukan dalam infrastruktur yang mendukung penambahan fungsi tambahan seperti di Prototipe FAQSC. Dengan meningkatkan alat bantu, kita juga mengurangi Tanggung Jawab Akhir yang dibebankan kepada Agent. Salah satu contoh terkait Tanggung Jawab Akhir dalam kaitannya dengan Sinergi ada di panduan Mention Twitter.

Dalam Buku Saku terkait Panduan Mention Twitter ada 3 tahap. Dan di tahap Jawaban diberikan 5 Catatan Tambahan. Tolong dicermati Catatan nomor 3, “Memaksimalkan penggalian informasi (maksimal dalam 5 reply)”. Ini satu lagi contoh dari “Semua Tanggung Jawab Akhir Ada Di Agent” yang akan dijelaskan dengan 2 alternatif.

Alternatif A adalah kondisi saat ini. Catatan ini pasti dirasa cukup baik hingga layak ditambahkan ke dalam Panduan Buku Saku. Tapi ada beberapa hal yang meski lebih baik dari instruksi pada umumnya, menurutku masih kurang bagus. Beberapa hal sebagai berikut:

• Fokus pada perintah
  • Meski lebih baik dibandingkan Catatan-Catatan lain di dalam Panduan, karena menunjukkan Tujuan, tetapi pada akhirnya tetap memberi perintah terkait penggalian.
• interaksi satu arah (psychological reactance
  
  wiki
  people will often do the opposite of what you ask them to if they feel that their autonomy is taken away from them
  
  Sesekali kita tidak sadar bahwa apa yang kita komunikasikan akan menghasilkan respon permusuhan dari orang lain. Jika kita ingin berkomunikasi secara efektif, untuk memastikan pesan didengar, perlu memperhatikan bahwa tiap individu memiliki kebutuhan autonomi diri–untuk merasa bahwa mereka melakukan sesuai cara yang mereka inginkan. Jadi jika seseorang merasa kita memaksakan sudut pandang kita pada mereka, mereka akan (entah secara sadar atau tidak) melawan.
  
  Satu cara untuk menghindari psychological reactance adalah untuk meminta sudut pandang mereka–pertanyaan sederhana “bagaimana menurut pendapatmu?” sudah cukup untuk memberi rasa kolaborasi, tapi sebegitu mudah untuk dilupakan dan tenggelam pada apa yang kita mau dan pikirkan.
  
  )
  • Perintah yang diberikan terwujud dalam pemberian batas, menonjolkan kebebasan Agent yang diambil. Dengan demikian bila tidak dikomunikasikan dengan tepat akan menimbulkan reactance.
• Hasil akhir adalah hukuman.
  • Dengan memberikan perintah, memberi batas, maka Penyusun Panduan memindahkan tanggung jawab kepada Agent. Menambahkan Tanggung Jawab Akhir. Apabila tanggung jawab tidak dijalankan maka akan timbul hukuman. Karena hasil akhir dari Perintah hanya Hukuman. Dengan demikian, Penyusun Panduan tidak memberikan apa pun yang membantu Agent menjalankan tugas bahkan mungkin memberikan hukuman berdasarkan Catatan ini.

Dengan hanya mengetahui pendapatku di atas, mungkin ada yang menyimpulkan bahwa aku tidak suka diperintah. Dan aku akan merespon bahwa kesimpulan itu setengah benar. Aku tidak suka “perintah” digunakan semudah itu. Jika “perintah” dianggap remeh, dilemparkan tanpa pikir, dan tidak memperhatikan efek akibatnya, “perintah” hanya akan dianggap sebagai “pesan” dan memperkuat kesan bahwa semua “perintah” itu tidak penting dan dengan demikian tidak perlu diperhatikan. Yang aku tidak suka adalah cara mengkomunikasikan panduan yang selalu jatuh dalam bentuk “perintah”. Cara mengkomunikasikan panduan yang menurutku lebih baik adalah panduan seperti Alternatif B.

Alternatif B adalah Panduan yang lebih baik menurutku. Dan sudah ditambahkan dalam halaman Buku Saku. Berdasarkan hal-hal yang bisa ditingkatkan dari Alternatif A. Dan juga terkait bagaimana mengkomunikasikan “perintah”, yang aku ringkas dalam 3 Poin Panduan berikut:

1. Mengutamakan Informasi Tujuan
   • Bukan fokus kepada perintah tetapi fokus kepada tujuannya. Dengan tujuan yang terkomunikasikan dengan jelas, tujuan akan lebih mudah dicapai. Dan dengan menginformasikan tujuan, akan lebih mudah menyesuaikan dengan tujuan mereka yang menerima Panduan dan lebih mudah mengambil posisi bersinergi untuk mencapai tujuan yang sama. Bukan sekadar mengabaikan tujuan penerima Panduan.
2. Memberikan Rekomendasi Cara Mencapai Tujuan
   • Bukan memberikan perintah tapi rekomendasi. Karena bukan perintah, tidak perlu mengawasi apakah perintah dijalankan atau tidak. Tidak ada tanggung jawab untuk memberikan hukuman. Meski tidak harus dilaksanakan, bukan seperti perintah, tetapi rekomendasi masih tetap penting untuk diberikan karena dengan memberikan rekomendasi Penyusun Panduan tidak begitu saja melemparkan tanggung jawab kepada penerima Panduan tetapi juga memberikan alat bantu awal untuk mencapai tujuan. Karena merupakan rekomendasi, bisa memfasilitasi lebih dari 1 cara. Kalau tujuan merupakan hal yang layak dituju tetapi pelaksanaan tidak sesuai rekomendasi, hasil bukan hukuman tetapi diskusi. Perbedaan rekomendasi dari perintah adalah bahwa rekomendasi tidak menyinggung rasa hormat seperti perintah yang tidak dilaksanakan. Dan dengan menyampaikan dalam bentuk rekomendasi akan lebih mudah untuk membuka jalur diskusi.
3. Membuka Jalan Diskusi
   • Untuk perubahan dan penambahan rekomendasi cara juga bahkan mengubah dan menyesuaikan tujuan awal. Ketika rekomendasi tidak dijalankan, bisa menjadi titik awal diskusi, karena ada kemungkinan cara lain yang lebih efektif efisien dalam mencapai tujuan. Meski taruhan ego tidak sebesar bentuk perintah, tetapi rekomendasi tidak diterima juga tetap bisa menimbulkan rasa tersinggung. Menjaga Jalan Diskusi juga bisa dibilang sukar karena harus bisa besar hati mengakui apa yang kita anggap baik, bisa jadi dianggap buruk. Sebagai contoh Rekomendasi Penggalian di Alternatif B, misalnya ada yang lebih cocok dengan bentuk flowchart, atau mungkin penambahan di jenis pajak yang tidak ada PBB, atau penyederhanaan di jenis pajak dengan PBB dan meterai masuk ke jenis lainnya. Kemudian untuk membuka Jalan Diskusi bukan sekadar menyediakan tempat saja, tapi juga mendengarkan apa inti masukan. Demikian juga dengan adanya Jalan Diskusi bukan untuk mengumbar komentar sia-sia berkedok masukan. Prosedur Diskusi jelas perlu pembahasan lebih jauh di lain waktu.

Bentuk ini yang aku ingin ada di KLIP, 3 Poin Panduan - Tujuan, Rekomendasi, dan Diskusi. Sebagai pribadi yang seringnya tidak mendengarkan perintah, bentuk ini yang aku ingin lebih sering digunakan. Bentuk yang membangun sinergi dan bukan melempar tanggung jawab. Bentuk yang memberi bantuan atau jalan atau rekomendasi dan bukan sekadar hukuman. Alternatif A memang lebih mudah. Seperti yang bisa dilihat, Alternatif A hanya perlu sebaris kalimat. Dan karena itu bentuk perintah lebih sering muncul dalam komunikasi. Tapi Alternatif B lebih mungkin tercapai, lebih mungkin dilaksanakan, lebih mungkin dikembangkan. Meski ini merupakan bentuk yang kuanggap lebih baik tapi memang tidak bisa diterapkan di semua hal, misalnya menyangkut kebijakan di luar wewenang atau proses tahapan seperti usul masukan terkait pondasi yang dimasukkan saat tahap pembangunan dinding. Memahami batasan suatu tools seperti 3 Poin Panduan ini juga penting untuk mengetahui kapan bisa memanfaatkan. Ada satu lagi yang seharusnya menyediakan tools bukannya sekadar menjatuhkan hukuman.

Tools yang seharusnya disediakan ini menyangkut ND-550, yang saat ini dalam proses pembaruan, di bagian Penilaian Kualitas yang kebetulan juga dicantumkan di buku saku. Terkait gaya berbicara khususnya di bagian ini, ketentuan terkait selamaaaat pagi ini. Sejauh yang saya tahu, ketentuan ini hanya berdasar selera. Suatu standar hanya untuk ada standar. Alasan lain adalah terkait “tanda” tidak fokus, mengabaikan kondisi penyebab ataupun hasil interaksi dan langsung menghukum. Hal ini sering jadi topik perdebatan, antara yang menganggap ada banyak hal yang lebih layak memperoleh tingkat perhatian tersebut, dengan yang mengagungkan suatu standar rapuh profesionalisme yang akan runtuh jika ada satu Agent tidak tunduk pada selera pengucapan tertentu. Tapi dengan berdebat justru kita fokus kepada hal yang salah. Dengan mendebatkan standar, kita terjebak anggapan bahwa mengubah cara bicara adalah hanya dengan menggunakan standar. Karena jalan meningkatkan cara bicara bukan dengan standar, tapi dengan teknik. Sampai sekarang aku terus merasa janggal atas KLIP yang utamanya memberi informasi melalui suara, tapi tidak ada pelatihan teknik bicara.

Pelatihan yang paling mendekati yang pernah ada di KLIP adalah teknik komunikasi. Tapi itu pun hanya membahas terkait komunikasi, bukan teknik bicara. Untuk meningkatkan teknik bicara, diperlukan suatu program vocal coach. Karena itu FAQSC juga menyediakan Program perfect voice.

Program perfect voice adalah suatu program vocal coach dari Roger Love (untuk mengenal lebih jauh, silakan ikuti link wiki yang disediakan) untuk melatih menguasai penggunaan suara kita. Di program ini dijabarkan apa saja komponen suara. Dijabarkan juga karakter suara sesuai beragam contoh profesi. Meski begitu, penyesuaian karakter ini bukan menetapkan suatu standar. Karena mencapai Perfect Voice artinya mampu menguasai suara dalam semua sisi dan tahu kapan menggunakan karakter tertentu untuk membawa pengaruh yang diinginkan.

Yang menarik dari Program Perfect Voice ini adalah adanya latihan untuk meningkatkan teknik vokal dan pemanasan vokal, yang jika dilakukan tiap hari otomatis akan meningkatkan teknik bicara. Dengan kata lain cukup membudayakan satu waktu yang didedikasikan untuk melakukan pemanasan vokal dan kemampuan teknik bicara akan secara rutin meningkat. Kondisi saat ini dengan memakai standar akan ada 2 jenis hasil, mereka yang memenuhi dan mereka yang tidak. Dan untuk golongan tidak ini, akan muncul hukuman. Artinya dengan memakai standar yang kita hasilkan cuma hukuman. Sementara dengan program ini tidak peduli seberapa tinggi atau rendah teknik vokal yang dimiliki pada saat memulai, semua akan memperoleh resource dan sumber daya untuk bisa meningkatkan kemampuan diri.

Sayangnya program ini juga punya kelemahan. Seperti yang bisa dilihat, program ini dalam bahasa inggris. Walau seluruh teknik, latihan, prinsip, dan pemanasan, semuanya masih bisa diterapkan dalam Bahasa Indonesia. Keterbatasan perbedaan bahasa ini memang bisa menurunkan semangat untuk mengadopsi teknik. Untuk ini saya sudah membagi file program ini ke trainer, satu yang bisa diakui fasih dengan bahasa inggris, Miss Anggel. Jadi misalnya dirasa perbedaan bahasa ini merupakan halangan yang dianggap cukup besar dalam proses penerapan, bisa didiskusikan terkait penyesuaian ke dalam Bahasa Indonesia oleh trainer termasuk cara penyajian.

Sama seperti “perintah”, bukan berarti aku membuang “standar” tapi ada penerapan baik dan buruk atas “standar” yang akan dijabarkan setelah 1 topik besar terakhir FAQ. Topik terakhir ini akan aku awali dengan satu pendapat kontroversial.

Nilai Angka Hasil Assessor Adalah Hal Tidak Berguna

Hanya untuk konfirmasi, Nilai Angka yang aku maksud adalah angka 100 seperti yang ditunjukkan di gambar. Hanya yg ini. Angka total dari penerapan ND-550 oleh assessor. Assessor yang hanya bisa memberi nilai normal, yang akan diabaikan atau dianggap tidak kerja, atau memberi nilai di bawah normal, yang akan dianggap hukuman. Kalau hasil yang bisa terlihat adalah hukuman, kalau yg dimiliki hanya palu, maka semua akan kelihatan seperti paku. Pertimbangan yang dilakukan dan pemikiran yang diproses hanya sebesar apa hukumannya, seberapa keras memukul paku. Pendapat Kontroversial ini setengah pondasi bentuk FAQ. Setengah lain adalah beda trainer dan assessor.

Fokus Trainer adalah kepada sumber pembuat pengetahuan. Kepada maksud, tujuan, dan hal-hal di balik layar. Kemudian dengan IHT menyebarkan pengetahuan ke keseluruhan KLIP.

Fokus Assessor adalah kepada tujuan pengetahuan. Kepada pengetahuan yang diminta WP, menyusun bentuk ideal pengetahuan itu. Kemudian membandingkan dengan bentuk yang diterima WP dengan Nilai Angka sebagai hasilnya.

Bentuk Konkret FAQ berhenti di bentuk ideal, di nomor 1. Karena tidak ada gunanya mengkonversi ke dalam bentuk angka untuk kemudian melemparkan tanggung jawab kepada Agent untuk merancang lagi bentuk ideal dari angka tersebut. Jika Assessor sudah menyusun bentuk ideal pengetahuan, akan lebih efisien jika menyebarkan dalam bentuk ideal tersebut. Dengan demikian Agent memiliki suatu bentuk pedoman yang bisa membantu mereka menyusun pengetahuan yang diminta oleh WP. Proses ini selanjutnya akan dijabarkan menggunakan Alur Interaksi FAQ.

Gambar di samping adalah drafting awal flow chart teknis, serta alur prosedur. Penyusunan alur disesuaikan dengan kondisi KLIP saat ini, efisiensi hasil kerja, juga ada inspirasi output “rekomendasi” oleh Assessor dari Pak Nico. Dan disusun di atas dua pondasi yang dijelaskan sebelumnya.

Flow chart dibagi dalam 3 bagian. Bagian pertama adalah interaksi WP - Agent.

Alur Kerja:

1. Interaksi dimulai dari pertanyaan yang diajukan WP kepada Agent.
2. Agent mengumpulkan Keyword atas pengetahuan yang diinginkan WP.
   • perlu memperdalam teknik pencarian, jika perlu bisa dibuat kodifikasi Best Search Practice.
3. Agent mencari seluruh Keyword bahkan meski Agent merasa “mengetahui” Jawabannya.
4. Hasil Pencarian memiliki 2 Kemungkinan berikut:

Alur Kerja:

1. Alur dimulai dari hasil pencarian Agent atas Keyword yang diminta WP sesuai Bagian 1: WP - Agent
2. Mendiskusikan bentuk Jawaban untuk disajikan kepada WP sesuai prosedur Konsultasi SC.
3. Hasil Diskusi terdiri dari 2 Kondisi berikut:

Alur Kerja Trainer:

1. Bagian 3 dimulai dari Trainer memproses Entri FAQ dengan tanda Tag Draft.
2. Trainer melakukan Review atas Draft Entri FAQ tersebut dengan dua hasil Kondisi berikut:

Alur Kerja Assessor:

1. Assessor memproses Entri FAQ yang memiliki tanda Tag Reviewed.
2. Atas Jawaban yang sudah diperiksa oleh Trainer, Assessor menyusun Rekomendasi Jawaban atau bentuk ideal untuk menyajikan Jawaban tersebut ke dalam 4 bentuk media berikut:
   1. Telepon, media pemberi jawab utama KLIP. Medium paling dinamis di antara semua media pemberi jawab KLIP. Arus informasi dan pertanyaan bisa dianggap paling cepat, dengan demikian kemungkinan kesalahan ucap, kemungkinan memotong penjelasan/pertanyaan juga tinggi. Penyesuaian untuk media pemberi jawab ini adalah dengan menempatkan informasi paling kritis di awal penjelasan, dengan demikian ketika Wajib Pajak ingin berpindah topik, informasi penting sudah diberikan.
   2. Twitter, media ini lebih mengutamakan keringkasan jawaban, sebisa mungkin informasi yang diberikan tercakup dalam karakter seminimal mungkin tetapi masih berisi informasi yang diminta. Penyesuaian yang diberikan adalah penggunaan singkatan, pemilihan kata yang lebih singkat, serta link untuk memberikan informasi yang lebih detil.
   3. Live Chat, media ini bisa dibilang seperti gabungan Telepon dan Twitter, dengan karakteristik dinamis mendekati Telepon, juga menghindari penjelasan yang terlalu panjang. Penyesuaian juga gabungan antara Telepon dan Twitter, yaitu prioritas informasi serta menghindari penjelasan panjang.
   4. Email, media yang berfokus pada informasi umum. Penyesuaian yang dilakukan adalah menyesuaikan dengan format Email baku KLIP, serta redaksi untuk korespondensi.
3. Setelah Entri FAQ tersebut diberikan Rekomendasi Jawaban, Entri FAQ diberi tanda Tag Recommended
4. Tanda Tag Reviewed dihapus

Alur di atas merupakan alur ideal untuk tahap pemeliharaan. Saat ini sebagian besar Entri FAQ yang ada masih perlu melalui proses review dan recommend. Dengan total sekitar 200.000 lebih Entri FAQ, akan diperlukan proses pilah, pilih, dan hapus ganda. Untuk Proses Merapikan ini, rekomendasi yang bisa kuusulkan (sedikit berbeda dari alur pemeliharaan di atas) adalah sebagai berikut:

1. Mengambil daftar seluruh Entri dengan Tag Draft.
2. Memilih satu Entri untuk menjadi Entri Awal Proses
   • memilih Entri yang termasuk baru dalam hitungan waktu pembuatan untuk mengurangi kerja penyesuaian kepada ketentuan terbaru, atau
   • memilih Entri dengan Jawaban yang memerlukan paling sedikit penyesuaian
3. Apabila diperlukan menyesuaikan Jawaban yang ada pada Entri Awal Proses
4. Mengeluarkan inti pertanyaan menjadi rangkaian Keyword
5. Menggunakan fitur pencarian untuk mencari rangkaian Keyword dari Entri Awal Proses
6. Membandingkan Entri Awal Proses dengan Entri lain hasil pencarian dalam 4 kemungkinan tindakan yang bisa diambil sebagai berikut:
   1. Jika Entri lain serupa baik itu Pertanyaan juga Jawaban, maka Hapus Entri
   2. Jika Jawaban serupa tetapi Pertanyaan berbeda Keyword, maka Tambah Pertanyaan pada Entri Awal Proses
   3. Jika Pertanyaan serupa tetapi Jawaban berbeda, dan jika
      1. perbedaan jawaban bisa menyempurnakan Jawaban pada Entri Awal Proses, maka Sempurnakan Jawaban pada Entri Awal Proses
      2. perbedaan jawaban dan tidak menyempurnakan Jawaban atau mungkin jawaban salah, maka Hapus Entri.
   4. Jika Pertanyaan dan Jawaban berbeda karena memang terkait topik yang berbeda, maka pastikan ada Keyword Pembeda di antara Entri Awal Proses dan Entri lain tersebut.

Di Tahap Pemeliharaan, memang proses Review ada di Trainer, tapi untuk Tahap Merapikan di awal, proses bisa dilakukan bersama oleh Trainer dan Assessor dengan hasil kerja bisa diperhitungkan seperti melakukan Live Monitoring.

Gambar di samping adalah bentuk akhir FAQ di dalam Prototipe FAQSC ini. Bentuk akhir yang disusun melalui pengalaman kerja, gagasan ideal, serta inspirasi “rekomendasi” dari Pak Nico di atas Dua Pondasi yang dijabarkan sebelumnya.

Karena Dua Pondasi itu juga aku mengusulkan supaya Assessor tidak lagi membuat Nilai Angka tidak berguna. Kemudian mengganti kerja pembuatan Nilai Angka dengan membuat Rekomendasi Jawaban yang lebih efektif efisien dalam meningkatkan kualitas layanan.

Dengan Program Perfect Voice yang memastikan bahwa kualitas teknik bicara para Pegawai KLIP akan selalu meningkat dan semakin mewakili Karakter Profesionalisme yang layak jadi “Suara KLIP”. Yang tersisa adalah penyusunan redaksi kata-kata pengantar pengetahuan yang disusun dengan mempertimbangkan efektivitas dan efisiensi pemberian pemahaman. Agent yang selalu dituntut untuk menyeimbangkan pencarian bentuk ideal Jawaban (semakin lama waktu digunakan, semakin ideal Jawaban) dengan kebutuhan menyediakan Jawaban secepat mungkin bukanlah tempat yang tepat untuk menanggung Tanggung Jawab menyusun Jawaban Ideal.

Sesuai dengan kesimpulan “Semua Tanggung Jawab Akhir Ada Di Agent”, kondisi yang menurutku tidak adil. Aku ingin memindahkan beban tanggung jawab penyusunan Jawaban Ideal kepada Assessor. Dengan mengganti kerja memproduksi Hasil Angka dengan memproduksi Rekomendasi Jawaban, kita juga mengurangi beban kerja Assessor dalam mengkonversi perbandingan Jawaban ke dalam Hasil Angka, juga mengurangi beban kerja Agent dalam mengkonversi Hasil Angka ke dalam Jawaban Ideal yang dituntun dari mereka. Dengan demikian bagian FAQ di Prototipe FAQSC bisa menjadi tempat sumber jawaban Valid + Update melalui kerja sesuai filosofi Wiki, sinergi Kolaborasi.

Format FAQ dirancang untuk menguatkan sinergi semua pihak mendukung pemberian jawab paling ideal. Meski begitu infrasruktur Wiki tetap ada yang perlu diperhatikan. Filosofi kolaborasi juga bisa mengundang edit sembarangan. Karena itu perlu diperhatikan juga fitur Sejarah Revisi dari DokuWiki.

Misalnya pada tanggal 10 April 2023 Agent menjawab pertanyaan terkait penerapan Pasal 31E untuk BUT yang merupakan Entri FAQ berikut dengan jawaban “Maaf, saya tidak tahu.” dan mengaku jawaban itu dari FAQSC. Kita bisa membandingkan pada Sejarah Revisi apakah ada sejarah edit di sekitar tanggal tersebut. Dan sesuai gambar Sejarah Revisi di samping, bisa dikonfirmasi bahwa Agent memang benar. Dari fitur ini juga bisa diketahui oknum yang melakukan edit sembarangan dan siapa yang bertanggung jawab. Fitur ini tersedia untuk tiap halaman yang ada dalam infrastruktur DokuWiki, dengan demikian mencakup seluruh halaman yang sebelumnya sudah dijabarkan.

Dengan 4 topik besar sudah dijabarkan, selanjutnya adalah terkait halaman muka Prototipe FAQSC, seperti yang terlihat pada gambar di samping.

Di topik Panduan, sudah dijabarkan terkait 3 Poin Panduan - Tujuan, Rekomendasi, dan Diskusi. Seluruh Prototipe FAQSC ini bisa dibilang poin 2, Rekomendasi. Sementara poin 1, Tujuan, adalah Tugas KLIP.

Di halaman muka ini adalah tempat untuk selalu mengingatkan Tujuan KLIP. Alasan kenapa KLIP ada. Pondasi dari seluruh kerja para pegawainya. Dengan selalu mengingatkan tujuan ini, akan lebih mudah bagi pegawai KLIP untuk mengambil arti dari pekerjaan mereka, merasa bangga dalam rutinitas hari karena bisa membawa efek positif. Ada alasan lain mengutamakan Tugas KLIP menyangkut aktualisasi diri, ICV, jalan hidup, mencegah “jawaban apatis” tapi itu diskusi panjang lain waktu. Selain Tugas, hal lain yang ditonjolkan adalah fungsi, wewenang, lalu definisi “umum”. Terkait definisi ini bisa dijabarkan lebih jauh dalam diskusi panjang lain waktu juga. Selain Tugas, juga menetapkan batas kebebasan berkreasi dalam menjalankan tugas. Seperti tiga komponen 3 Poin Panduan, Tugas sebagai Tujuan, Prototipe FAQSC sebagai Rekomendasi. Terakhir adalah Tempat Diskusi.

Satu hal yang menurutku ganjil dalam KLIP adalah seringnya mendengar sebutan “Kesepakatan” yang jadi halangan menerima masukan. Wajar sukar menyatukan sudut pandang banyak pihak dalam 1 waktu. Bisa dibilang halangan timbul dari kesukaran tersebut. Memang bisa jadi juga berasal dari sumber lain, tapi untuk halangan ini Prototipe FAQSC bisa sedikit mengatasi.

Di contoh bentuk akhir FAQ ditunjukkan ada Kolom Diskusi. Itu adalah salah satu alternatif tampilan Tempat Diskusi. Alternatif lain yaitu Halaman kumpulan Diskusi. Tempat untuk mengaktualkan prinsip diri dalam meningkatkan pelaksanaan tugas. Kolom Diskusi dimaksudkan untuk pembaruan lebih cepat. Usulan tidak perlu mengumpulkan banyak pihak dalam satu tempat. Pertimbangan tidak dibatasi waktu, tidak mengandalkan ingatan terkait progress diskusi panjang. Membuka banyak diskusi mungkin tidak cocok untuk semua hal. Tapi untuk proses kerja KLIP yang banyak iterasi singkat, Diskusi berlanjut bisa memfasilitasi perubahan efisien efektif lebih cepat. Lebih lagi jika bentuk akhir bukan perintah tapi rekomendasi. Untuk memudahkan semua pihak di KLIP dalam mengerti alasan suatu prosedur juga mengekspresikan usulan akan lebih mudah dalam pengelompokan topik. Untuk format bentuk, juga bisa didiskusikan bentuk yg lebih efisien. Dengan mempermudah alur peningkatan akan mempermudah KLIP menjadi lebih baik, lebih cepat, lebih efisien.

Salah satunya tercermin di Status Layanan. Bagian Sidebar akan selalu terlihat di mana pun, jadi Agent akan lebih cepat mengetahui jika ada info error. Selain itu TL/SPV juga bisa dengan cepat mengupdate jika ada info terbaru.

Kemudian sempat ada masukan juga dari Bli Dwipa, untuk juga ada tempat dokumentasi keluhan error. Tempat yang fleksibel edit dan mencatat hitungan semisal ingin proaktif mengabarkan berapa banyak keluhan error ke pihak terkait. Dengan demikian, Agent tidak merasa mengabaikan keluhan WP, bukan sekadar menyebut c3l, tapi mengumpulkan dalam satu tempat untuk mengabarkan ke TIK. Terkait laporan rutin bisa didiskusikan apakah 1-2 kali sehari, atau melaporkan jika melebihi jumlah tertentu, atau kriteria lain. Hal ini bisa ditingkatkan selanjutnya melalui Diskusi.

Di dalam Sidebar juga ada bagian Input FAQ yang bisa digunakan oleh TL kapan pun untuk membuat Entri FAQ. Format penamaan sudah disesuaikan dengan informasi pegawai yang login dan tinggal disalin lalu ditambahkan jam dan menit sebagai pembeda. Bagi pegawai yang tidak memiliki kewenangan untuk membuat Entri FAQ, bagian ini akan menyebutkan batasan kewenangan tersebut. Untuk resume, panduan, dan presentasi, memang harus masuk ke halaman mereka masing-masing.

Sekarang kita ada di bagian akhir, bagian pilihan dan biaya. Terus terang semua ini sudah bisa langsung digunakan, sudah bisa diakses, tapi untuk Penerapan Resmi memang perlu dipilih jenis aksesnya, jenis lokasi. Jenis jaringan yang digunakan untuk mengakses Hasil Jadi Prototipe FAQSC. Internet atau Intranet. Dua lokasi ini memiliki beberapa karakteristik yang berbeda. Dan ini beberapa poin positif dua pilihan ini:

• Intranet
  • Kemudahan akses IT, karena server bisa diakses secara langsung
  • Kecepatan akses selama jadwal kantor
  • Keamanan paling tinggi
• Intranet
  • Kemudahan update infrastruktur, khususnya plugin yang menjadi pondasi fitur
  • Bisa diakses di mana saja
    • Jadi ketika di luar kantor, kita bisa menjawab pertanyaan sukar pajak apa pun
  • Bisa dikembangkan lebih jauh menjadi suatu jalur layanan ke WP, KPP, juga PP
    • DokuWiki memiliki fitur pembatasan akses, jadi semua tidak akan bisa melihat apa yang di luar wewenangnya.
    • KPP dan PP bisa melihat bentuk jawaban yang diterima WP melalui KLIP, dengan demikian ketika ada yang dirasa kurang tepat informasi penerapan, KPP bisa memberi masukan, atau terkait informasi ketentuan, PP bisa memberi masukan.

Perbedaan kedua lokasi ini juga dari biaya, menggunakan jaringan Internet pasti ada biaya sewa server, termasuk biaya domain tahunan itu adalah biaya pastinya. Untuk Biaya ada dua biaya yang ingin saya angkat juga:

1. Donasi DokuWiki
   • Teknologi infrastruktur ini menggunakan DokuWiki yang free dan open source, semisal Penerapan Resmi memang menggunakan infrastruktur ini. Kalau untuk penggunaan pribadi, seperti situs awalku, aku sendiri tidak begitu memikirkan terkait Donasi. Tapi karena penggunaan ini merupakan Penerapan Resmi dalam suatu Instansi, ada baiknya jika kita memberikan Donasi ke proyek DokuWiki ini. Terkait jumlah, bisa didiskusikan berapa jumlah uang yang dirasa layak.
2. Program Perfect Voice
   • Program ini bisa digunakan dari awal sampai akhir tidak ada batasan, tapi yang ada di Prototipe FAQSC ini bukan dari sumber resmi. Saya menyediakan program ini karena apa yang ada di KLIP bukan sesuatu yang layak dibanggakan. Hanya menghukum tanpa memberi jalan untuk meningkatkan kemampuan. Sehingga bisa sampai dimanfaatkan adalah jauh lebih baik untuk menggantikan apa yang saat ini ada di KLIP. Meski begitu, karena aku sendiri merasa memperoleh banyak manfaat dari program ini ada baiknya juga jika kita membeli secara resmi. Terkait harga program ini terakhir saya lihat ada di 147 dollar. Satu kali bayar untuk seterusnya menurutku layak beli, tapi bisa dicoba dicek dulu programnya.

Semua ini adalah bentuk jawabanku atas pertanyaan “Apa itu KLIP?” Meski mungkin belum seluruh jenis bentuk konkret, masih ada pengaduan dan layanan lain yang bisa ditelusuri untuk dibuat alat bantu lain, tapi sudah cukup mewakili. Sudah dijabarkan juga prinsip filosofi yg mendasari. Seperti “Semua Tanggung Jawab Akhir Ada Di Agent”, hal yang ingin kuubah melalui proyek ini.

Pada bagian penutup ini aku ingin membagi satu contoh lagi terkait Tanggung Jawab Akhir. Sempat ada keluhan yang disampaikan ke Pihak Manajemen terkait headset yang digunakan para Agent. Dan Pak Agus juga sempat menjelaskan alasannya dalam suatu forum. Bahkan untuk masalah yang sudah diketahui, dan sudah ada penjelasan yang memang sudah diterima dan dimaklumi forum. Bahkan untuk hal itu, para Agent masih menanggung Tanggung Jawab Akhir. Dengan masalah headset yang ada, Agent akan menghabiskan lebih banyak waktu berusaha mendengar WP juga mengulang penjelasan. Dan pada akhirnya mereka menanggung dalam penghitungan kinerja mereka. Karena sesuatu yang ada di luar kuasa mereka. Demikian juga kondisi auditori yang lebih bising dibanding sebelum renovasi, dan banyak hal lain yang pada akhirnya menjadi Tanggung Jawab Akhir para Agent.

Semua materi presentasi ini bisa diakses secara online, termasuk juga speakernote yang aku gunakan untuk memastikan inti-inti penjabaran memang tersampaikan. Jika ingin membaca-baca dulu, atau mau coba praktek fungsi dan sebagainya. FAQSC.xyz sudah bisa beroperasi dan digunakan.

Tapi tentu saja ini adalah jawaban pribadiku, termasuk seluruh filosofi yang mendasari. Dengan karakter Wiki yang bersifat kolaborasi, bentuk akhir jelas akan berbeda. Karena nantinya akan mencerminkan jawaban seluruh KLIP. Aku boleh meletakkan batu pertama, tapi tiap bata penyusun adalah hasil kerja tiap-tiap unsur KLIP. Bata yang merupakan hasil jawaban pertanyaan kita setiap hari bekerja, pertanyaan yang tetap harus ditanyakan. Menurut anda, Apa itu KLIP?