Sejak 2006, kami telah terlibat dalam sistem penagihan. Total - lebih dari 12 tahun. Kami mulai bekerja dengan pasar televisi, sekarang di antara para pelanggan kami ada bank, operator seluler, dan penyedia TV Internet. Sistem penagihan itu sendiri telah berkembang dari solusi yang kurang lebih sederhana untuk televisi menjadi penagihan konvergen penuh dengan kemungkinan menerapkan skema pra-bayar. Dan selama ini kami berhasil mengisi banyak kerucut baik dari segi implementasi maupun dukungan penagihan. Kesalahan sering terjadi karena pelanggan tidak tahu "materi", dan pengembang penagihan tidak memahami ketakutan dan kebutuhan klien.Tagihan bukan hanya kalkulator
Untuk waktu yang lama, sistem penagihan tidak hanya menjaga keseimbangan dan tagihan pelanggan. Mereka sangat terintegrasi ke dalam bisnis: mereka memberikan kontrol lalu lintas, mengelola prosedur untuk menyediakan akses ke layanan, menyediakan klien dengan laporan tentang pengeluaran di bagian yang berbeda - selama sebulan, selama satu tahun, dari saat pembayaran terakhir. Plus, sistem penagihan, sebagai suatu peraturan, harus mendukung banyak saldo pengguna: moneter dan beberapa materi (bonus, menit percakapan, lalu lintas gigabyte, dll.). Belum lagi program afiliasi dan opsi cross-selling lainnya. Apa yang disebut penagihan konvergen modern. Ini diterapkan karena integrasi tarif dengan modul dan subsistem lain: CRM, PRM, BPM, dll. Bagi pengembang, ini bukan pengetahuan "rahasia". Seperti yang mereka katakan, bagilah fungsi dan aturan. Tetapi bagi pengguna penagihan, bahkan kompeten secara teknis, gagasan bahwa sulit untuk berkomunikasi langsung dengan "kalkulator", kadang-kadang ternyata menjadi baru.
Contoh dari latihan kami. Klien adalah perusahaan kecil tapi menjanjikan. Mereka tidak memiliki anggaran untuk seluruh kompleks penagihan, mereka meminta untuk menghapus modul BPM (manajemen proses bisnis). Kami harus membayar upeti, ada yang cukup maju dalam hal teknis guys. Mereka mengatakan akan mengambil solusi open source, mengkonfigurasi, mengintegrasikan dengan sistem. Kami sepakat. Empat bulan kemudian, mereka "tenggelam" dalam panggilan mereka untuk dukungan teknis tentang data yang salah.
BPM adalah sistem yang, antara lain, saat menghubungkan pelanggan, terlibat dalam validasi data, dan tidak melewatkan Anda ke langkah berikutnya sampai Anda menyelesaikan semua parameter yang diperlukan - teknis dan pribadi. Dan mereka menolak BPM, dan hanya menggambar antarmuka untuk entri data. Orang yang menerima aplikasi untuk koneksi bukan spesialis yang dibayar tinggi, ada omset besar, waktu pelatihan singkat untuk staf. Secara alami, mereka terus melakukan kesalahan saat memasukkan data. Intinya - pada akhir bulan perusahaan mengeluarkan tagihan, dan penetapan tarif tidak memiliki parameter. Dia "bersumpah", memberikan pesan kesalahan. Dukungan panggilan pelanggan. Pada akhirnya, kami memutuskan untuk memberi mereka BPM di pengaturan default. Mereka semua mulai berkumpul, dan dukungan teknis kami berkurang sakit kepala. Sekarang kami sama sekali tidak menjual penagihan tanpa BPM, kecuali jika sudah diterapkan dan ada opsi untuk mengintegrasikannya. Jika klien tidak memiliki cukup uang untuk set minimum yang diperlukan, kami menawarkan sewa atau sewa dengan kemungkinan penukaran dalam lima tahun. Atau, jika ini semacam startup, tetapi jelas bahwa orang-orang serius tentang masalah ini dan mereka memiliki prospek, kami menawarkan skema rhubarb. Bagaimanapun, ini melindungi sel-sel saraf untuk kita dan manajemen perusahaan klien.
Fleksibilitas adalah konsep yang longgar.
Arsitektur yang salah dipahami dari sistem penagihan tidak hanya menghasilkan kegagalan teknis. Dalam pengalaman kami, dalam 70% kasus, kebutuhan untuk mengganti tagihan muncul karena fleksibilitas pemasaran yang tidak memadai. Pasar telekomunikasi sekarang terlalu jenuh, dan perusahaan hanya bisa mendapatkan pelanggan baru dengan memukul mundur mereka dari pesaing. Bahkan penyedia besar, menguasai ceruk baru dan memperluas kehadiran mereka, mulai membuang, dan Tuhan sendiri memerintahkan pemain baru di pasar untuk menarik perhatian dengan penawaran unik. Perang tarif yang sesungguhnya sedang berlangsung. Dan di sini pemasar sudah mencengkeram kepala mereka: "Kami akan dapat meluncurkan tarif Super-New Year inovatif baru Anda hanya pada bulan Juli," sebuah pesan datang dari departemen TI.
Apa masalahnya? Dalam sejumlah kecil sistem penagihan, ada, misalnya, modul katalog produk terpisah, yang memudahkan untuk menggabungkan layanan ke dalam paket dan mengonfigurasi promosi. Parameter yang dia operasikan dapat berupa parameter layanan dan individual seperti menit percakapan, paket lalu lintas, atau layanan yang ditawarkan oleh mitra (yang disebut layanan pihak ketiga), misalnya tiket film atau naik taksi. Diyakini bahwa katalog produk umumnya merupakan elemen dari sistem CRM, bukan penagihan. Namun demikian, tidak semua perusahaan memiliki CRM yang terpisah. Banyak layanan pelanggan mengarah langsung ke sistem penagihan. Dan ini berarti bahwa setiap layanan baru, tarif baru, promosi baru - dan orang-orang TI tidak perlu mengumpulkannya di perancang, tetapi menambahkan bidang dan menulis baris kode. Sekarang, Juli sudah dekat.
Benar, pemasar biasanya tidak mengerti apa artinya vendor dengan mengatakan bahwa sistemnya “cukup fleksibel”. Cukup untuk apa? "Kommersant" terutama tertarik pada waktu-ke-pasar, waktu yang diperlukan untuk merilis layanan ke pasar. Suatu kali perwakilan dari klien - operator regional di mana pemain federal wilayahnya datang - langsung ke pertemuan presentasi membawakan kami deskripsi 3 kasus pesaing yang tidak dapat mereka sadari di rumah. Mereka mengajukan pertanyaan dengan tajam: untuk berapa lama Anda bisa mengkonfigurasi di sistem Anda? Bukan dosa untuk bermegah - kami menyiapkan satu kasus di lingkungan pengujian bersama mereka saat presentasi berlangsung. Secara umum, dengan arsitektur penagihan yang matang dan menggunakan katalog produk, paket atau stok apa pun dapat disesuaikan dan dibawa ke pasar dalam 2-3 hari, tidak termasuk waktu pemasaran dan pengujian fungsional. Lebih baik untuk memeriksa apakah ini bisa menjadi tagihan tertentu pada tahap kencan. Karena sering ada kasus ketika menetapkan tarif baru dalam sistem "cukup fleksibel" sebenarnya membutuhkan waktu beberapa bulan.
Antara sentralisasi dan otonomi
Perusahaan pemasaran besar menghadapi masalah yang sama dalam hal pemasaran dan penjualan, yang telah tumbuh karena pengambilalihan operator regional. Sistem penagihan yang berbeda di cabang tidak memungkinkan, misalnya, segera meluncurkan promosi skala besar di seluruh negeri. Pelaporan dan analitik menderita: tidak mungkin mengumpulkan data tentang koneksi dan penggunaan layanan dari semua sistem yang berbeda ini. Solusi parsial untuk masalah ini adalah payung CRM, di mana ada katalog produk. Beberapa perusahaan melakukan hal itu - mereka berdagang dari CRM, dan mereka mengenakan biaya dalam penagihan. Untuk ini, perusahaan harus memiliki departemen TI yang benar-benar canggih. Mengintegrasikan sistem penagihan yang ditulis dalam berbagai bahasa dan prinsip yang berbeda dengan satu CRM bukan tugas yang mudah.
Tetapi ada satu masalah abadi yang tidak bisa diselesaikan oleh sistem terdistribusi - ini adalah penipuan biasa di lapangan. Kami punya beberapa contoh. Khususnya, di Ukraina, tempat kami memperkenalkan tagihan terpusat, mentransfer data dari cabang regional yang baru saja diakuisisi. Ketika kami memigrasikan data, kami melakukan serangkaian pemeriksaan dan perbandingan, semua inkonsistensi masuk ke dalam laporan terkait, dan setelah itu layanan keamanan perusahaan pelanggan biasanya mulai bergerak. Apa yang tidak ada di sana. Pelanggan yang terhubung dengan sistem akuntansi, rencana tarif "nol", dll. ... Ada penipuan nyata: perusahaan itu dijual, dan kwitansi kepada pelanggan disiapkan untuk detail kiri untuk beberapa waktu.
Organisasi pusat penyelesaian tunggal membuat semua situasi seperti itu transparan; di daerah, hanya fungsi layanan informasi pelanggan tetap, sehingga praktis tidak ada peluang untuk penipuan. Plus, basis pelanggan yang besar, digabungkan menjadi satu sistem tunggal, memungkinkan kami untuk menganalisis dan memprediksi perilaku pelanggan pada tingkat yang sama sekali berbeda. Kami secara bertahap mulai menerapkan sistem analitik kami berdasarkan pembelajaran mesin untuk data sebesar itu. Misalnya, kita dapat mengidentifikasi dalam "kelompok risiko" basis klien - mereka yang mungkin segera menolak layanan perusahaan. Ini diungkapkan oleh cara orang membayar, bagaimana mereka menggunakan layanan, akun pribadi mereka, bagaimana mereka berkomunikasi dengan pusat panggilan, berapa banyak dan untuk alasan apa mereka memiliki kunci.
Benar, sentralisasi tagihan membawa masalah lain. Adalah perlu bahwa cabang regional mempertahankan bagian dari kemandirian teknis. Jika tidak, jika tiba-tiba pusat penagihan pusat berada "di luar zona akses", layanan pelanggan di wilayah tersebut dapat mengalami kerugian. Kami menyelesaikannya dengan mengorbankan "offset" ke pinggiran: server otorisasi, pengumpulan lalu lintas dan elemen pemrosesan, elemen penyediaan layanan. Khususnya, untuk operator seluler, platform Forward Fusion kami dapat membebankan biaya layanan secara offline dan menunggu hingga koneksi dipulihkan untuk menyinkronkan data dengan pusat penagihan. Pada saat yang sama, pelanggan regional dapat memperhatikan bahwa akun pribadi mereka telah menjadi tidak tersedia, tetapi degradasi layanan yang diberikan tidak terjadi.
Server yang dipasang Jack: di mana data disimpan?
Ada banyak opsi untuk bagaimana dan di mana menempatkan sistem penagihan. Seringkali perusahaan khawatir tentang keamanan data pelanggan, mereka membeli server sendiri dan menginstalnya di pusat data mereka. Tetapi tidak semua orang dapat menarik layanan berkualitas mereka. Terkadang klien memecahkan sesuatu, tetapi ia bahkan tidak mengerti bahwa itu ada di pihaknya. Menghubungi kami dalam dukungan teknis, dan admin kami memberi tahu dia di mana kegagalannya, server mana yang tidak merespons. Sistem kami dikonfigurasikan sehingga secara konstan "memonitor" sistem yang diservis dengan banyak cara, dan menimbulkan alarm jika ada sesuatu yang salah. Jadi kami dapat memberi tahu Anda sebelumnya bahwa kehabisan memori atau kecepatan proses penting telah turun di bawah normal. Namun sayangnya ini tidak membatalkan force majeure.
Pilihan lain adalah ketika klien ingin meng-host dirinya sendiri, dan kami memberikan perangkat keras dan perangkat lunak yang kompleks, ini dilakukan ketika klien ingin kami menjadwalkannya kinerja tertentu untuk layanan yang penting baginya. Dalam hal ini, biaya "perangkat keras" segera termasuk biaya dukungan tiga tahun dari produsen. Kemudian mereka memegang suku cadang dan jika sesuatu rusak, maka spesialis mereka pergi ke tempat itu dengan suku cadang dalam waktu 24 jam dan memperbaiki kerusakan.
Ada situasi ketika, sebaliknya, mereka membawa server mereka dan menempatkannya di pusat data bersertifikat Tier III kami.
Pilihan umum lainnya - kami menyewakan semuanya. Kemudian kami bertanggung jawab penuh untuk perangkat keras - baik untuk pemeliharaan dan untuk meningkatkan kapasitas yang dibutuhkan tepat waktu. Untuk alasan ini, pada titik tertentu, kami mulai menggunakan cloud pribadi. Jika kami telah menambah beban, kami mengubah pengaturan, dan kami dialokasikan kekuatan komputasi tambahan. Tidak perlu tanpa henti melakukan “peningkatan” peralatan non-inti bagi kami. Sayangnya, perusahaan Rusia yang saat ini menawarkan layanan cloud publik belum dapat memberikan tingkat kinerja yang dijamin yang dibutuhkan oleh sistem penagihan. Mereka dapat meng-host situs, Anda dapat menggunakan toko online atau menempatkan 1C. Oleh karena itu, kami masih harus berpartisipasi aktif dalam mengoptimalkan dan menguji solusi untuk berbagai cloud pribadi, misalnya, kami baru-baru ini mulai menggunakan OpenStack.
Basis data: penting bukan hanya di mana, tetapi bagaimana
Pentingnya memilih database untuk penagihan sulit ditaksir terlalu tinggi. Kinerja tinggi di sini hanya dapat dicapai dengan mengoptimalkan sistem penagihan untuk produk tertentu. Forward Billing dioptimalkan untuk bekerja dengan dua DBMS: Oracle Database dan PostgreSQL). Tahun lalu, Forward Billing dimasukkan dalam daftar perangkat lunak Rusia yang disetujui untuk digunakan di perusahaan milik negara. Dan baru-baru ini, muncul berita bahwa dalam enam bulan dari registri akan mulai mengecualikan pengembangan berdasarkan DBMS asing. Dari sudut pandang negara, ini bisa dimengerti. Dalam kondisi ketika hampir setiap hari perusahaan-perusahaan baru Rusia dikenai sanksi, mereka ingin memastikan kemerdekaan penuh dari perangkat lunak Rusia. Tetapi untuk vendor, ini menimbulkan biaya tambahan yang layak. Saya pikir dalam hal ini kita, seperti halnya pasar lainnya, sedang menunggu penjelasan yang lebih jelas dari legislator dalam hal ini, dan setelah itu kita akan menyesuaikan strategi kita.
SLA: Tetapkan Prioritas
Di suatu tempat di dunia yang ideal, tingkat dukungan teknis dari pemasok ditentukan oleh Perjanjian Tingkat Layanan SLA yang jelas, yang juga merupakan Perjanjian Tingkat Layanan. Bagaimana SLA berbeda dari hanya kontrak di mana jam dukungan yang ditetapkan untuk klien dicatat? Ini menjabarkan persyaratan spesifik untuk layanan: kecepatan menerima aplikasi, waktu untuk menyelesaikan masalah - dan sistem denda yang dikenakan pada pemasok jika persyaratan tidak terpenuhi.
Seperti yang ditunjukkan oleh praktik, agar SLA menjadi alat yang efektif untuk mengatur hubungan antara pelanggan dan pemasok, pelanggan harus melakukan beberapa pekerjaan analitis. Anda perlu memahami bagaimana insiden akan menjadi penting untuk bisnis tertentu, dan mana yang tidak layak untuk panik. Sebagian besar pelanggan kami, dengan satu atau lain cara, menggunakan SLA dasar kami yang berulang kali diuji dan, menurut pendapat kami, optimal.
Sebagian dari kenyataan adalah bahwa perusahaan-perusahaan kecil yang membeli solusi penagihan "kotak" yang sudah jadi, jika ada masalah, berubah menjadi 376 dalam antrian untuk dukungan teknis. Seringkali untuk perusahaan seperti itu, bantuan komunitas pengguna produk ini di forum online lebih cepat.
Benar, ekstrem lain memang terjadi. Salah satu pelanggan potensial, operator seluler virtual kecil, datang kepada kami setelah "dibakar" berat dengan dukungan untuk sistem penagihan. Akibatnya, klien ini menawari kami SLA "gila", melipatgandakan persyaratan standar kami untuk waktu respons dan denda hampir seratus kali. Sayangnya, kami tidak dapat meyakinkannya dan dia terus melayani pelanggannya dengan risiko sendiri.