Baru-baru ini, seorang klien datang kepada kami dengan masalah yang akan dikenali oleh sebagian besar bisnis jasa yang sedang berkembang. Pekerjaan mereka tersebar di ClickUp dan Freshservice. Mereka menginginkan izin yang lebih terperinci untuk keterlibatan klien mereka yang sangat diatur, dan ruang otomatisasi yang mereka butuhkan untuk memberikan layanan pelanggan yang konsisten dalam skala besar. Mereka memutuskan ke mana mereka ingin pergi: HaloPSA, dan mereka memutuskan bahwa ini dapat menggantikan kedua alat tersebut. Namun, ada kendala untuk melakukan hal ini - mereka perlu menyimpan data historis selama bertahun-tahun yang diandalkan pelanggan mereka sendiri untuk kelangsungan layanan. Ini berarti bahwa penghalang untuk beralih ke alat baru adalah tugas yang tidak disukai siapa pun - migrasi data.
Jawaban teknologi biasanya sudah jelas pada saat kami dihubungi — ada platform target yang akan bekerja lebih baik. Hambatannya bukanlah alat mana yangtepat. Melainkan kekhawatiran bahwa proses menuju ke sana akan lambat, mahal, dan tidak dapat diprediksi. Tiket akan hilang. Pelaporan akan rusak. Tim akan memberontak. Regulator atau pelanggan mungkin keberatan. Biaya akan membengkak.
Tetapi semua itu bukanlah hal yang tak terhindarkan. Jika dilakukan dengan baik, migrasi data seharusnya tidak menjadi penghalang untuk menjalankan bisnis Anda dengan alat yang tepat. Konsolidasi dapat — dan seharusnya — menjadi kesempatan untuk meningkatkan cara bisnis sebenarnya berjalan, bukan hanya memindahkan data dari A ke B. Berikut adalah pendekatan kami.
Dua Bagian Konsolidasi
Proyek konsolidasi memiliki dua bagian yang mudah membingungkan tetapi sangat berbeda sifatnya.
Yang pertama adalah pemindahan data — memindahkan tiket, komentar, lampiran, pengguna, kolom kustom, dan catatan historis dari platform sumber ke platform target. Ini adalah pekerjaan yang benar-benar teknis. Untuk kasus yang lebih kompleks, Anda akan menggunakan API, seringkali dalam urutan yang ketat, karena lampiran bergantung pada tiket, komentar bergantung pada pengguna, kolom kustom bergantung pada skema, dan seterusnya. Impor file datar hanya membantu sebagian; tidak sepenuhnya. Inilah jenis pekerjaan yang ditangani oleh alat bantu khusus — seperti Help Desk Migration
Yang kedua adalah model operasional — memutuskan bagaimana platform baru tersebut seharusnya benar-benar berfungsi untuk bisnis. Kategori alur kerja apa yang melewatinya? Seperti apa pelaporan yang baik? Siapa yang bertanggung jawab atas antrean mana? Kemampuan baru apa yang sekarang tersedia — penagihan dan pembuatan faktur, layanan mandiri pelanggan, manajemen perubahan terintegrasi — yang sebelumnya tidak mungkin, dan mana yang layak diaktifkan sekarang dibandingkan nanti?
Kedua bagian ini saling membutuhkan. Melakukan hanya bagian pertama akan memberi Anda kekacauan lama dalam sistem baru. Melakukan hanya bagian kedua akan membuat Anda terjebak karena data historis tidak akan tersedia.
Kesalahan terbesar dalam sebagian besar proyek konsolidasi adalah memperlakukannya semata-mata sebagai latihan migrasi data. Keuntungan terbesar — dan risiko terbesar — terletak pada model operasionalnya.
Mengapa Konsolidasi Lebih Sulit dari yang Terlihat
Sebagian kompleksitasnya memang bersifat teknis. Sebagian lagi bersifat organisasional. Jebakan yang paling sering kita lihat:
1. Pemetaan data tidak rapi. Berbagai alat menyusun konsep yang sama dengan cara yang berbeda. Nama status, tingkat prioritas, jenis tiket, bidang kustom, kategori, jenis permintaan — hampir tidak ada yang dipetakan satu-per-satu. Bagian tersulit bukanlah menulis pemetaan; melainkan memutuskan seperti apa pemetaan tersebut, yang memaksa pengambilan keputusan model operasional sebelum Anda siap.
2. Model agen/pengguna/pelanggan bervariasi antar alat. Beberapa platform memisahkan agen internal dari pengguna eksternal dari pelanggan eksternal sebagai tiga jenis entitas yang berbeda. Yang lain menggabungkannya. Beberapa mengizinkan agen menjadi mitra eksternal; beberapa tidak. Cara Freshservice memodelkan orang tidak sama dengan cara Halo memodelkannya, tidak sama dengan cara Jira Service Management memodelkannya. Migrasi pengguna jarang berupa salin-tempel — ini adalah terjemahan, dan pilihan yang Anda buat di sini membentuk izin, pelaporan, dan lisensi selama bertahun-tahun.
3. Bidang kustom dan jenis tiket terakumulasi. Sebagian besar sistem sumber memiliki akumulasi kustomisasi selama bertahun-tahun, sebagian bermanfaat, sebagian besar terlupakan. Migrasi secara keseluruhan akan menciptakan kembali masalah pemeliharaan yang sama pada alat baru. Memigrasikan hanya apa yang dibutuhkan akan memaksa percakapan yang sulit dengan orang-orang yang membuat bidang-bidang tersebut.
4. Izin menjadi lebih rumit, bukan kurang rumit. Platform yang terkonsolidasi biasanya digunakan oleh lebih banyak tim daripada sumber individual mana pun. Itu berarti model izin baru, aturan visibilitas baru, dan standar yang lebih tinggi untuk melakukannya dengan benar — karena kesalahan lebih terlihat.
5. Pelaporan adalah tempat kesalahan pertama kali muncul. Sistem sumber sering kali memiliki laporan yang bergantung pada struktur bidang, status, atau konvensi penamaan tertentu. Ketika hal-hal tersebut berubah di target, laporan akan rusak — dan pemangku kepentingan akan segera menyadarinya. Persyaratan pelaporan harus dirancang ke dalam migrasi, bukan ditambahkan setelahnya.
6. Anda biasanya memerlukan migrasi uji coba penuh. Bukan sampel, bukan sebagian — migrasi UAT penuh dengan data nyata, terhadap target yang dikonfigurasi, dijalankan oleh orang-orang yang benar-benar akan menggunakan sistem baru. Di sinilah kejutan sebenarnya muncul: bentuk data yang tidak Anda duga, keputusan pemetaan yang ternyata salah, integrasi yang perlu disesuaikan. Alokasikan waktu dan biaya untuk itu. Mencoba melewatkan tahap ini adalah jalan pintas termahal dalam konsolidasi.
7. Persyaratan peraturan dan pelanggan sering kali menentukan apa yang harus dipertahankan. Terkadang pelanggan ingin "meninggalkan sistem lama dan memulai dari awal" — tetapi pelanggan mereka sendiri, atau regulator mereka, mengharuskan tiket, komentar, dan lampiran historis untuk disimpan untuk tujuan audit. Hal itu mengubah ruang lingkup migrasi sepenuhnya, karena jejak komentar dan lampiran adalah bagian yang membutuhkan pekerjaan API paling banyak dan pengurutan yang paling hati-hati. Kami pernah memiliki proyek di mana persyaratan penyimpanan data adalah satu-satunya alasan desain migrasi menjadi rumit. Cari tahu sejak dini.
Pendekatan Praktis
Setiap konsolidasi yang telah kami lakukan selalu mengikuti bentuk yang kurang lebih sama. Labelnya kurang penting dibandingkan urutannya.
1. Pahami apa yang sebenarnya digunakan. Sebelum memetakan apa pun, cari tahu bagaimana sistem sumber sebenarnya digunakan saat ini — bukan bagaimana sistem tersebut seharusnya digunakan, dan bukan apa yang tertulis dalam dokumentasi. Kumpulkan laporan penggunaan. Bicaralah dengan orang-orang yang mengerjakan pekerjaan tersebut. Anda biasanya akan menemukan bahwa sebagian besar kustomisasi dalam sistem sumber tidak aktif atau tidak lagi relevan. Itu bukan masalah; itu adalah kesempatan untuk melakukan konsolidasi ke target yang lebih sederhana.
2. Definisikan model operasi target. Ini adalah pertanyaan yang terus kita bahas: apa yang Anda inginkan agar platform baru lakukan untuk bisnis yang tidak dapat dilakukan oleh platform lama? Pelaporan SLA yang lebih baik? Penagihan dan pembuatan faktur terintegrasi? Portal permintaan layanan mandiri? Manajemen perubahan yang terhubung ke CMDB? Masing-masing hal ini mengarahkan konfigurasi ke arah tertentu. Putuskan apa yang Anda optimalkan sebelum Anda mulai memetakan data.
3. Rancang pemetaan data terhadap model baru, bukan model lama. Kesalahan yang paling sering dilakukan tim adalah memetakan struktur data sumber langsung ke target. Pendekatan yang tepat adalah memetakan data sumber melalui model operasi target — bidang mana yang mendapatkan tempatnya, mana yang diarsipkan, mana yang dihentikan, dan mana yang dikonsolidasikan bersama. Di sinilah keputusan model operasi dan migrasi teknis bertemu.
4. Jalankan migrasi uji coba yang ditargetkan. Sebelum gladi bersih penuh, — tiket satu tim, atau satu alur kerja khusus, atau satu grup pengguna — untuk memvalidasi bahwa logika pemetaan dan urutan API benar-benar berfungsi dari ujung ke ujung. Uji coba singkat ini menangkap masalah saat masih murah untuk diperbaiki.
5. Jalankan migrasi UAT penuh. Gladi bersih. Data lengkap, konfigurasi lengkap, pengguna nyata menguji skenario nyata. Alokasikan waktu. Ini adalah tahap yang menentukan apakah peralihan sebenarnya berjalan tenang atau kacau.
6. Lakukan peralihan dengan rencana, bukan harapan. Komunikasi, kriteria pengembalian, cakupan dukungan, siapa yang memutuskan apa selama periode tersebut. Peralihan itu sendiri biasanya antiklimaks jika UAT dilakukan secara menyeluruh.
7. Dukung adopsi dengan benar. Alat baru yang berfungsi sempurna tetapi tidak digunakan siapa pun adalah proyek yang gagal. Adopsi membutuhkan pendukung internal, dokumentasi yang jelas, pelatihan yang sesuai dengan cara kerja orang sebenarnya, dan dukungan kepemimpinan yang terlihat. Inilah bagian yang selalu diremehkan oleh proyek migrasi yang murni bersifat teknis.
Contoh terbaru
Migrasi tersebut harus menangani tiga bentuk data yang berbeda:
- Dokumen dari ClickUp, yang strukturnya mirip wiki dan terkait dengan proyek
- Tugas-tugas dari ClickUp, di mana modelnya bertingkat dan sadar akan ketergantungan
- Tiket dari Freshservice, di mana modelnya adalah skema tiket klasik dengan komentar, lampiran, dan hubungan pemohon
Masing-masing dari ini harus dipetakan — bukan ke replika persis seperti yang ada di sumber, tetapi ke model operasional yang telah kami rancang untuk target. Dokumen mengalir ke satu arah, tugas ke arah lain, tiket ke arah ketiga, dan dalam beberapa kasus harus dirujuk silang karena pekerjaan bisnis yang sama diwakili di berbagai sistem.
Ada alternatif DIY untuk pekerjaan semacam ini: menulis skrip migrasi langsung terhadap API sumber dan target. Ini adalah sesuatu yang telah kami lakukan pada proyek-proyek sebelumnya, dan alat bantu AI membuatnya lebih cepat. Tetapi pada proyek-proyek di mana bentuk data bervariasi, konfigurasi tujuan rumit, dan tenggat waktu penting, menggunakan alat bantu khusus Help Desk Migrationsecara substansial mengurangi risiko pemindahan data dan memperpendek tenggat waktu. Hal itu membebaskan kami untuk fokus pada apa yang sebenarnya diminta pelanggan kepada kami: konfigurasi, desain otomatisasi, dan model perizinan.
Hasil yang dipedulikan pelanggan bukanlah "kami berhasil memindahkan data." Melainkan platform baru yang memberi mereka kendali dan otomatisasi yang dibutuhkan bisnis mereka — tanpa kehilangan catatan historis yang diandalkan pelanggan mereka sendiri. Itulah perbedaan antara proyek migrasi data dan proyek konsolidasi.
Kita melihat dinamika serupa ketika tujuannya adalah platform PSA — menggabungkan kemampuan penagihan, pembuatan faktur, profitabilitas proyek, dan pelacakan waktu di samping pekerjaan operasional. Untuk contoh nyata konsolidasi ke HaloPSA, lihat studi kasus terbaru kami tentang bdq.cloud.
Di mana Help Desk Migration berperan?
Kami tidak berpura-pura menjadi perusahaan penyedia alat migrasi data. Pekerjaan teknis membangun dan menjalankan skrip migrasi terhadap berbagai API platform, dalam urutan yang tepat, menangani kasus-kasus khusus untuk lampiran, komentar, dan pemetaan pengguna — itu adalah keahlian khusus, dan Help Desk Migration benar-benar ahli dalam hal itu.
Yang tak kalah penting, penggunaan alat khusus membuat biaya dan jangka waktu pemindahan data tetap dapat diprediksi. Pengeluaran migrasi harus menjadi pos pengeluaran yang pasti, bukan risiko yang tidak pasti — dan ketika hal itu diketahui, alasan bisnis untuk konsolidasi yang lebih luas menjadi jauh lebih mudah untuk disetujui.
Poin yang terus kita bahas berulang kali
Migrasi data seharusnya tidak menjadi penghalang untuk menjalankan bisnis Anda dengan alat yang tepat. Proses ini bisa mahal, memakan waktu, dan berisiko—tetapi dengan mitra yang tepat dan pendekatan yang tepat, ini bukan alasan untuk tetap menggunakan platform yang tidak lagi bermanfaat bagi Anda.
Organisasi yang paling banyak mendapatkan manfaat dari konsolidasi adalah organisasi yang memperlakukannya sebagai peluang untuk meningkatkan model operasional, bukan hanya untuk mentransfer data. Aspek teknis dari skrip API dan pemetaan bidang seharusnya bukan tempat nilai bisnis berada. Nilai bisnis terletak pada pelaporan yang lebih baik, proses yang lebih baik, otomatisasi yang lebih baik, dan tim yang benar-benar dapat melihat dan bertindak atas pekerjaan yang penting.
Jika Anda mempertimbangkan konsolidasi, pertanyaan yang layak untuk dimulai bukanlah "bagaimana kita memindahkan data?" melainkan "seperti apa hasilnya setelah selesai?" Bagian data akan menyusul.
Tentang BDQ
BDQ Cloud adalah konsultan TI yang berbasis di London, yang berspesialisasi dalam migrasi, konsolidasi, dan modernisasi platform manajemen layanan. Kami bekerja dengan HaloITSM, Atlassian, Freshworks, Asana, dan alat modern lainnya, dan kami bermitra dengan Help Desk Migration untuk pekerjaan migrasi data teknis yang mendukung proyek konsolidasi kami. Jika Anda ingin membahas tantangan konsolidasi tertentu, kami menawarkan penilaian migrasi selama 30 menit yang berfokus pada model operasional dan hasilnya, bukan hanya sisi data.
