Bagaimana kami mengotomatiskan pengiriman makanan pada Aiko

Dua tahun yang lalu, kami memutuskan untuk keluar dari rutinitas dan mengotomatiskan layanan pengiriman makanan kami di kota county N. Sehingga orkestra kami dari pusat panggilan, produksi, gudang, kantor, telepon, situs web, agregator pengiriman, aplikasi mobile, smartphone kurir, integrasi kami sendiri dimainkan oleh crescendo .

Dengan pos ini, kami merangkum hasil dua tahun penerapan sistem otomasi restoran - iiko ("Ayko", selanjutnya - sistem otomasi restoran, CAP, jika tidak, menurut aturan Habr, akan ada iklan). Ini tidak akan menjadi pujian. Kami berbicara apa adanya, tanpa menyembunyikan masalah. Pada saat yang sama, memahami bahwa bagi kita hari ini tidak ada solusi yang lebih bijaksana dan cocok.

Kami tidak tahu berapa banyak kisah serupa di negara kami. Paling tidak, di pusat regional kami tidak ada yang bertanya, tidak ada skala implementasi seperti itu.

Kami yakin bahwa longrid ini pasti akan membantu mereka yang hanya berpikir tentang mengotomatisasi restoran atau layanan pengiriman makanan. Berikut adalah perkiraan, perkiraan anggaran waktu / uang, dan ide per juta, dan kisah nyata tentang bagaimana tumbuh dari klien biasa menjadi mitra bersertifikat.

Siapa kamu Dan apa yang Anda izinkan sendiri?

Untuk memahami skala kami. Kami bekerja di wilayah itu, 500 km dari ibukota. Kami menganggap diri kami sebagai jaringan pengiriman makanan siap saji (sushi, pizza) terbesar di kota kami, kami hanya lebih kuat dari satu pesaing federal. Dalam struktur perusahaan: memiliki gudang, 4 poin (titik = produksi = dapur), pusat panggilan khusus, kantor.

Sejak Februari 2018, kami telah mengotomatisasi pengiriman dengan cara modern. Jika dari dalam dan pendek, prosesnya terlihat seperti ini. Operator call center menerima panggilan, melakukan pemesanan, meneruskannya ke salah satu industri. Seorang karyawan di lokasi produksi (logistik) di terminalnya (komputer) menerima informasi tentang pesanan, mencetak tanda terima, faktur, dll., Dapur mulai menyiapkan pesanan. Klien diberitahu tentang perubahan status pesanan, pesanan selesai menunggu pickup atau dikirim melalui kurir.

Jadi mengapa Anda memilih ATS baru?

Ketika menjadi jelas bahwa sistem otomasi yang digunakan ("1C-Rarus: Restaurant + Bar + Cafe", selanjutnya disebut sebagai RBC) tidak memungkinkan perusahaan untuk bergerak maju, kami mulai mencari solusi yang sesuai.

Melakukan “percontohan” implementasi beberapa produk: “Solusi yang mudah” , “Tardis Bistro” , Dooglys . Kami pergi ke PIR EXPO, dengan hati-hati bekerja di stan dengan demonstrasi R-Keeper, Poster, Tillypad, dll. Berminggu-minggu dan berbulan-bulan perbandingan solusi berbeda terjadi, tetapi saya tidak menyukai apa pun. Tidak ada pemain di pasar yang dapat menawarkan "kotak" yang 100% cocok untuk layanan pengiriman. Dan untuk terlibat dalam perbaikan yang dibuat khusus dan integrasi dalam realitas kita tampaknya kesenangan yang meragukan - setidaknya, lama dan mahal.

Tapi itu perlu untuk bergerak maju. Di antara optima lokal, plat komparatif menunjukkan satu pemimpin. Pada akhir 2017, ATS terpilih berjanji untuk memenuhi poin-poin berikut dari tugas teknis untuk otomatisasi:

• koneksi pusat panggilan ke sistem otomasi;
• memelihara satu basis data (pelanggan, pesanan, rute, bahan, dll.), tersedia di semua fasilitas perusahaan (kantor, pusat panggilan, gudang, produksi dapur);
• integrasi dengan situs, aplikasi seluler, dan agregator pengiriman;
• Peringatan pelanggan SMS;
• pemasangan aplikasi kurir pada smartphone kurir dengan riwayat dan status pesanan, navigasi;
• Akuntansi gudang dan perencanaan pengadaan.

Hari ini, hampir dua tahun setelah implementasi ATS yang sukses (meskipun, kadang-kadang, putus asa dari kesalahan integrasi reguler dan kurangnya konstruktif dalam berkomunikasi dengan dukungan dan pengembang), kami memahami: pilihan itu dibenarkan. Solusi yang lebih cocok untuk kita belum terlihat di cakrawala.

Berikutnya adalah arsitektur umum, fitur implementasi, penilaian anggaran waktu / uang dan petunjuk langkah demi langkah tentang cara menghapus rutinitas yang tidak perlu dan mengotomatiskan pengiriman makanan.

Implementasi

Anda dapat membeli dan memesan implementasi sistem otomasi yang dipilih baik di perusahaan induk atau dari dealer resmi.

Kami tidak mencoba keberuntungan kami dengan dealer lokal (pilihannya adalah dari satu alternatif), karena tidak ada lagi skala otomatisasi di kota kami. Karenanya, tidak ada pengalaman implementasi. Mungkin lebih mudah untuk warung kopi kecil dengan satu mesin kasir untuk bekerja “secara langsung” dengan seorang insinyur yang akan tiba dan “melakukan segalanya” di tempat (walaupun dengan data awal seperti itu, ATS yang dipilih memiliki banyak pesaing kuat - Evotor, Dooglys, Poster, Frontpad dan tidak hanya). Kami memutuskan bahwa kami dapat memperkenalkan sistem otomasi “in absentia”, bersama dengan para insinyur dari perusahaan induk, melalui saluran jarak jauh. Mereka tidak salah, solusinya ternyata cocok.

Kami menghabiskan hampir sebulan untuk mengoordinasikan arsitektur implementasi (sayangnya, metode trial and error bukan yang paling sukses dan cepat untuk tugas-tugas seperti itu), kami mendapat skema berikut:



Catatan, untuk setiap produksi, pengembang merekomendasikan mengalokasikan server terpisah dan menyinkronkannya dengan server pusat iikoChain. Mereka mencoba bekerja sesuai dengan skema lain (tanpa server produksi terpisah), umpan baliknya negatif.

Antara lisensi seumur hidup dan penyewaan solusi cloud, mereka memilih opsi kedua - iikoCloud. Ya, mungkin ini lebih mahal pada akhirnya dan ada ketergantungan ekstra pada penyedia layanan (tentang kegagalan - di bawah). Tetapi pada saat yang sama tidak perlu membeli server Anda, cadangan data, daya, saluran komunikasi.

Mereka mencapai kapasitas penuh secara bertahap, menghubungkan dua stasiun kerja operator pertama dan satu dapur. Kami melatih karyawan pertama, berurusan dengan IP-telephony dan printer penerimaan, mengatur program loyalitas. Dengan tidak adanya pengalaman, operasi paralel dari sistem otomasi sebelumnya dan implementasi baru, butuh hampir 4 bulan. Ya, kami setuju, terlalu lama. Layanan pengiriman kedua diotomatiskan dalam sebulan.

Keputusan anggaran

Berapa biaya semua kesenangan ini di musim panas 2019?

Peluncuran awal dan konfigurasi server di cloud dibayar secara terpisah - 6000 rubel. Selain itu, setiap server produksi harus disinkronkan dengan server pusat iikoChain, yang lain 6.000 rubel satu kali. Total biaya untuk meluncurkan produksi baru adalah 12.000 rubel.

Sekarang, untuk membuat anggaran menjadi jelas. Kami memulai uji coba dengan dua tempat kerja operator call center dan satu produksi. Anggaran skema semacam itu selama sebulan:

• 5990 rubel - “Lisensi untuk perangkat lunak iikoCloud 2017 (workstation pertama)” (dekripsi seperti itu ada pada tagihan);
• 1990 rubel - "Lisensi untuk perangkat lunak iikoCloud (1 add. AWP)";
• 1990 rubel - lain "Lisensi untuk perangkat lunak iikoCloud (1 add. AWP)".

Yaitu tempat kerja operator dan register kas di fasilitas produksi dipertimbangkan. Lisensi yang diperoleh dapat "mengaktifkan" tempat kerja mana pun - baik di pusat panggilan atau dalam produksi, itu tidak masalah. Yang terpenting adalah membayar total jumlah pekerjaan.

Hari ini kami memiliki 5 pekerjaan untuk operator call center dan 4 pekerjaan untuk industri. Total 9 AWP, perhitungannya adalah sebagai berikut:

• 5990 rubel - “Lisensi untuk perangkat lunak iikoCloud 2017 (workstation pertama)”;
• 5590 rubel - paket 3 meja kas tambahan;
• 5590 - paket kedua 3 meja kas tambahan;
• 1990 - satu meja kas tambahan;
• 1990 - Box office tambahan lainnya.

Total 9 pekerjaan, total anggaran bulanan: 5990 + 5590 + 5590 + 1990 + 1990 = 21150 (rubel).

Di bulan Juli, kami menerima pemberitahuan. Sampai akhir 2020, harga lama tetap untuk kami, dan mulai Januari 2021 kami beralih ke tarif baru. Perhitungan kasar menunjukkan bahwa biaya sewa untuk kami akan tumbuh "hanya" dua kali. Berpikir untuk diri sendiri, berpikir untuk diri sendiri.

Selain itu, kami masih membayar ekstra untuk menyewa konektor iikoDeliveryConnector (API), 500 rubel per bulan. Ini agar integrasi eksternal dapat terhubung ke cloud.

Jangan lupa tentang layanan tambahan, dibayar secara terpisah. Misalnya, menyiapkan integrasi dengan pertukaran telepon virtual "Mango Office" (selanjutnya - Mango) - 1.500 rubel. Menyiapkan satu tempat kerja operator - 6000 rubel. Peluncuran program loyalitas - 2000 rubel.

Kesempatan untuk menabung - membayar untuk pengaturan satu tempat kerja. Pengaturan dilakukan dari jarak jauh melalui TeamViewer, tidak ada yang melarang screencasting. Selama sesi pertama, para insinyur kami mempelajari, dan kemudian mereka secara mandiri mereplikasi konfigurasi ke pekerjaan lain.

Koneksi IP-telephony (kami segera membebaskan satu posisi operator)

Bagaimana cara kerja operator pusat panggilan dalam sistem otomasi sebelumnya? Setelah menerima panggilan dari klien, kami mengklarifikasi nama, alamat, komposisi pesanan, pengirimannya. Dalam kebanyakan kasus, menentukan nama dan alamat tidak perlu. Sistem pintar itu sendiri harus menentukan nomor dan "mengenali" klien, jika dia sudah memesan kepada kami.

ATS menyediakan kemampuan untuk menghubungkan IP-telephony, secara otomatis menentukan nomor klien dan segera menampilkan "konteks" klien dengan panggilan masuk: nama, alamat, riwayat pesanan. Ini tidak hanya nyaman, tetapi juga secara signifikan mempercepat proses penempatan pesanan.

Kami menghubungkan nomor sel dari MTS dan MegaFon ke Mangga, dan kemudian, menggunakan modul iikoPBX, ke komputer operator call center langsung ke sistem otomasi. Headset muncul alih-alih telepon tombol-tekan lama (tapi kami tidak membuang telepon lama, Mango telah gagal tiga kali pada 2019). Sekarang, dengan panggilan masuk, nomor telepon klien ditentukan. Jika dia sudah memesan dari kami, kartu dengan riwayat pesanan dibuka untuk operator. Selain itu, operator dapat memanggil pelanggan kembali segera dari aplikasi dengan satu tombol, menghemat waktu pada nomor panggilan.

Solusi yang tampaknya sederhana ini memungkinkan kami mengosongkan satu posisi operator pusat panggilan. Pesanan mulai diproses lebih cepat, layanan menjadi lebih baik. Para insinyur perusahaan mengambil alih gudang senjata: mereka mulai dari pusat panggilan, sekarang kami sedang menyelesaikan koneksi IP-telephony di semua fasilitas perusahaan. Sejauh ini, beberapa plus.

Menyiapkan diskon

Tidak, bagaimanapun, satu posisi operator tidak mungkin untuk segera dikosongkan setelah menghubungkan telepon. Butuh waktu lebih lama untuk memperkenalkan diskon kami ke dalam sistem iikoCard (sistem deposit bonus, semua program loyalitas perlu diformalkan di sini). Dan berhentilah menghitung diskon secara manual pada kalkulator.

Dan ini bukan lelucon, ini adalah kenyataan: sebelumnya, diskon dan bonus harus dihitung / diperiksa ulang pada kalkulator.

Konfigurasikan integrasi dengan agregator pengiriman

Pada bulan Desember dan Januari, serta mendekati akhir pekan dan hari libur, kami menerima hampir sepertiga dari semua pesanan dari agregator pengiriman - DeliveryClub (banyak) dan ZakaZaka (kurang dari satu persen). Pada hari dan bulan lain, sedikit kurang, tetapi proporsinya tetap signifikan. Yandex.Food belum bekerja di kota kami.

Bagaimana keadaan sebelumnya? Dalam aplikasi terpisah dari agregator pengiriman, operator pusat panggilan menerima pesanan dan secara manual "menginterupsi" sistem otomatisasi RBC. Mengapa Kami mengonfigurasi integrasi dengan CAP, DeliveryClub relatif cepat menerapkan semua pengaturan yang diperlukan.

Sekarang pesanan dari agregator pengiriman segera jatuh ke dalam sistem otomasi. Operator hanya dapat memverifikasi kebenaran data yang ditentukan dan mentransfer pesanan untuk produksi. Kami menyingkirkan operasi rutin berikutnya, bagus sekali.

Situs pengiriman Anda

Dalam skema kerja lama, pesanan dari situs juga diduplikasi secara manual dalam RBC. Tindakan ekstra, otomatisasi diperlukan. Kami mulai mencari artis untuk mengonfigurasi integrasi ATS dan situs.

Di situs web iiko.biz di toko aplikasi ada solusi seperti itu - iikoDeliveryWidget. Ini adalah widget yang dapat Anda sematkan di situs Anda untuk secara otomatis mentransfer pesanan dari situs ke ATS. Pengembang - jstore.me , mitra resmi, tim dari St. Petersburg. Kemampuan dasar widget tidak cukup bagi kami, kami beralih ke pengembang untuk solusi kustom. Waktu dan anggaran tampaknya terlalu tinggi.

Sementara itu, kami menemukan templat yang kami sukai untuk situs mendatang: https://sushi.bdbd.shop . Kemudian mereka menemukannya di pasar 1C-Bitrix (nama templatnya adalah “Delivery Shop” ), berkenalan dengan ulasan dan diskusi. Kami menghubungi pengembang templat dari Novosibirsk, sekali lagi, waktu dan anggaran penyesuaian (menggunakan metode API iikoDelivery untuk menghubungkan integrasi situs dan sistem otomasi) tampak berlebihan. Selain itu, secara umum, mereka tidak melihat keinginan untuk bekerja bersama kami pada kondisi individu di mata pengembang.

Pencarian dilanjutkan sesuai dengan pola yang terkenal. Menelepon selusin pelanggan dari portofolio jstore.me dan sushi.bdbd.shop. Direktur teknis layanan pengiriman Murmansk berbagi pengalamannya dan memberi tahu bagaimana mereka mengubah kinerja: alih-alih tim Novosibirsk, pengembang Naberezhnye Chelny terhubung dengan proyek vsem-edu.ru .

Setelah berkenalan, kami membuat perjanjian dengan tim ini untuk pengembangan dan integrasi. Lebih tepatnya, mereka membeli produk yang sudah jadi (120.000 rubel dengan cicilan selama 6 bulan, situs web + aplikasi seluler) dengan modifikasi kecil selama implementasi (1000-1500 rubel selama satu jam pekerjaan programmer).

Kami telah bekerja sama dengan mereka selama hampir satu tahun sekarang, kami dapat dengan aman merekomendasikannya dengan komentar minimal. Dari komentar - dalam masalah kompleks berinteraksi dengan API iikoDelivery, ketika mencari solusi optimal, saya harus menyelami kode itu sendiri, mengujinya, menemukan kesalahan di situs web resmi dengan contoh dan dokumentasi, dan secara aktif berkorespondensi dengan dukungan.

Perkembangan sendiri

Di sisi lain, konsekuensi dari pencelupan dalam kode adalah perkembangan kami sendiri: layanan pelacakan status pesanan, monitor pemuatan produksi, laporan biaya pengadaan, dan banyak lagi. Bagian dari kode PHP terbuka di sini: https://github.com/fisher85/iiko-api . Ada juga notebook Jupyter untuk penggemar pembelajaran mesin - dengan prediksi jumlah pesanan untuk tanggal yang berubah-ubah (python, scikit-learn).



Omong-omong, ada perkiraan penjualan di iikoWeb (akses gratis bagi mereka yang menyewa iikoCloud). Benar, kualitas solusi menyisakan banyak yang diinginkan: penambahan sederhana bendera boolean ke ruang atribut: "Apakah ini hari libur umum hari ini?" Dan "Apakah ada kampanye pemasaran untuk agregator pengiriman hari ini?" Secara signifikan meningkatkan hasilnya.



Cerita lain adalah pengembangan plugin untuk iikoFront di C #. Dari gagasan untuk masa depan: plugin untuk mengubah status pesanan dalam mode manual, monitor kesiapan pesanan untuk diambil oleh pelanggan, plugin untuk mencetak selebaran setelah cek.

Dukungan

Setelah penerapan ATS, kami mulai memiliki pertanyaan: "Bagaimana mengatur kondisi seperti itu dalam program diskon?", "Bagaimana mengedit templat penerimaan?", "Bagaimana mengatur pesanan otomatis untuk dapur?", "Mengapa kesalahan integrasi terjadi dengan DeliveryClub?", " Mengapa respons metode API iikoDelivery tidak cocok dengan dokumentasi? ”Dan jutaan lainnya. Pertanyaan diajukan ke layanan dukungan, dukungan pertama-tama melihat tarif. Jika tarifnya "Dasar", maka tiga aplikasi pertama per bulan ditutup segera, dan yang berikutnya, ketika spesialis dilepaskan, tidak ada yang terburu-buru untuk menjawab. Oleh karena itu, sejak bulan kerja kedua, kami telah memilih tarif "Standar" (versi baru dari tarif tidak memiliki ini, ada tarif "Lanjutan").

Secara kasar, biaya dukungan diperpanjang sekitar 2.000 rubel per bulan untuk satu tempat kerja. Semakin banyak pekerjaan, semakin besar diskon. Untuk pengiriman, AWP dianggap tidak hanya komputer dengan iikoFront dalam produksi, tetapi juga setiap komputer operator call center. Kami memiliki 9 stasiun kerja, biaya dukungan bulanan adalah sekitar 18.000 rubel. Ada sesuatu yang perlu dipikirkan, terutama jika prabayar penuh diperlukan untuk 3 bulan ke depan. Mitra juga dapat menghubungkan dukungan lanjutan, mereka menjanjikan waktu reaksi yang lebih sedikit, tetapi biaya pemeliharaan lebih tinggi (lihat dari dekat Lemma dan Open Service).

Bagaimana cara memahami jika Anda memerlukan dukungan tambahan (dengan biaya tambahan)? Berdasarkan ketentuan 2018, ketika beralih ke tarif Standar, kami menerima aplikasi dalam jumlah tidak terbatas per bulan dan ketentuan yang dijamin untuk menyelesaikan insiden. Sekarang, alih-alih rata-rata 24 jam, tenggat waktu 4 jam ditetapkan untuk menyelesaikan insiden.

Klarifikasi penting: kita berbicara tentang memblokir insiden. Insiden pemblokiran adalah ketika tidak mungkin untuk menjual sama sekali, misalnya, pemutusan saluran komunikasi dengan server iikoCloud. Contoh insiden non-pemblokiran adalah kesalahan integrasi: ya, pesanan dari DeliveryClub tidak tiba secara otomatis, tetapi pesanan dapat diterima melalui telepon. Seperti yang kita pahami, tenggat waktu untuk insiden yang tidak menghalangi tidak ditentukan di mana pun.

Selain itu, ketika membayar untuk dukungan, klien mendapat kesempatan untuk mengajukan perbaikan kecil dan perbaikan bug.

Selama sekitar setengah tahun kami menggunakan dukungan berbayar dan melakukan pengamatan: kami menetapkan waktu untuk memenuhi aplikasi kami dan waktu untuk menyelesaikan insiden. Dan kemudian, sebagai percobaan, mereka memutuskan untuk beralih ke dukungan gratis selama satu atau dua bulan. Ya, sekarang kami membayar untuk perbaikan kecil secara terpisah (satu jam pekerjaan seorang insinyur adalah ~ 1600 rubel). Tetapi tenggat waktu untuk menyelesaikan insiden tetap tidak berubah. Bulan keempat telah berakhir, kami tidak berencana untuk kembali ke dukungan berbayar.

Saran ahli: ketika memilih tarif dukungan, tentukan jumlah permintaan per bulan dan waktu untuk menyelesaikan insiden pemblokiran dan non-pemblokiran yang termasuk dalam tarif.

Pemeliharaan dan kegagalan

Kami membuat kesalahan, percaya bahwa setelah pengenalan dan penyempurnaan sistem otomasi, semuanya akan bekerja seperti jam. Itu tidak berhasil. Bukan tahap pengawalan yang paling menyenangkan dimulai.

Kami telah lama memiliki log kerusakan sendiri, di mana semua kerusakan dicatat: ketika musuh menggigit kabel jaringan dan internet utama menghilang, ketika telepon IP Mango gagal dan beralih dari headset ke "handset" yang biasa, ketika listrik mematikan daya dan harus memeriksa daya yang tidak terganggu . Dilakukan tanpa embel-embel di Google Documents.

Dalam jurnal yang sama, kami mulai mencatat setiap permintaan dukungan, menunjukkan nomor aplikasi. Dalam analisis selanjutnya (baik yang internal kami, dan, misalnya, ketika menangani klaim), nomor aplikasi adalah fakta dan bukti. Penyangkalan yang masuk akal dikesampingkan.

Misalnya, grafik di bawah ini menunjukkan statistik panggilan dukungan, kuartal pertama 2019. Gergaji dari bawah adalah jumlah hari dalam seminggu, di mana puncaknya adalah hari Minggu. Contoh aplikasi pada bulan-bulan pertama lebih tinggi, dari panggilan terakhir: "Ubah alamat produksi", "Perbarui versi perangkat lunak pada server", "Gagal! Perbaiki kesalahan integrasi. "



Perhatikan saja bahwa jumlah aplikasi yang mendukung lebih besar daripada jumlah kegagalan. Rata-rata, setiap bulan kami mengirim dukungan untuk 29 panggilan, dimana 3 panggilan gagal. Tetapi kegagalan didistribusikan secara tidak merata: Januari - 3 kegagalan, Juli - 7 kegagalan.

Pembaca yang penuh perhatian akan memperhatikan bahwa pada hari Jumat ada panggilan dukungan paling banyak. Dan dia akan benar. Ada dua maksimum dalam distribusi - Jumat (karena puncak pengiriman pesanan untuk hari itu, beban pada iikoCloud meningkat, jumlah kegagalan tumbuh secara proporsional) dan Selasa-Rabu (ketika kami memperbaiki pekerjaan yang belum selesai pada akhir pekan atau menyelesaikan tugas yang direncanakan).

Hal yang paling tidak menyenangkan dalam memperbaiki sistem otomasi kami adalah kegagalan rutin selama jam buka yang tinggi di iikoCloud. Frekuensi kegagalan semacam itu mengecewakan dan sulit diprediksi. Kami menyajikan statistik kesalahan integrasi pada Juli 2019, kami memperkirakan intensitasnya pada waktu tidak aktif (pada saat yang sama, kami telah membayar dukungan):

• 5 Juli, Jumat, 40 menit;
• Senin 8 Juli, 30 menit;
• 15 Juli, Senin, 1 jam;
• 20 Juli, Sabtu, 3 kegagalan, total downtime 2 jam 30 menit;
• Senin, 22 Juli, 30 menit.

Carl, 7 crash dalam satu bulan! Kami bergerak dengan lancar untuk menjamin ketersediaan cloud ATS.

Jaminan ketersediaan

Sayangnya, dalam penawaran (pada saat penulisan posting, versi saat ini tertanggal 22 April 2019) tidak ada sepatah kata pun tentang waktu yang diizinkan dari downtime iikoCloud. Dalam negosiasi lisan, departemen penjualan dan layanan dukungan dengan hati-hati berbicara tentang Tingkat 3, yang berarti kita dapat mengambil toleransi kesalahan 99,98% dan waktu henti 105 menit per tahun sebagai perkiraan perhitungan.

Kegagalan iikoCloud besar pertama yang terjadi pada Desember 2018 membuat kami tanpa akses selama hampir 2 jam (Anda juga dapat menerima pesanan dalam kasus-kasus seperti itu, tetapi Anda harus menghitung diskon secara manual, mentransfer pesanan dari pusat panggilan ke produksi melalui Telegram / WhatsApp dan sudah masuk di iikoFront). Kami menganggap bahwa situasi ini melanggar perjanjian pada tingkat layanan (yang sebenarnya tidak), dan mengajukan keluhan, melampirkan perhitungan jumlah pesanan yang terlewat. Keputusan itu dibuat untuk kita - untuk membebaskan iikoCloud dari membayar sewa bulan depan. Tapi kita mulai waspada dengan jaminan yang diharapkan.

Tampaknya dengan jaminan ketersediaan solusi cloud, semuanya baik-baik saja. Memang, crash iikoCloud jarang terjadi, kami memiliki 3 kali selama setahun terakhir, dalam satu kasus kompensasi telah diterima. Namun ada satu nuansa yang tidak menyenangkan.

Kasus yang paling umum dalam praktik kami adalah kesalahan di sisi iiko.Biz, iikoCard dan API iikoDelivery, tepat dua kali sebulan, dan pada Juni-Juli 2019 secara umum setiap minggu. Setiap kesalahan seperti itu menyebabkan penghentian semua integrasi eksternal (situs web kami sendiri, aplikasi seluler kami sendiri, DeliveryClub, ZakaZaka, Yandex.Food), pesanan dari mereka berhenti tiba dengan benar di ATS dalam mode otomatis dan memerlukan dukungan "manual". Sekarang kami memiliki lebih dari setengah pesanan yang datang dari integrasi eksternal, dapatkah Anda bayangkan berapa banyak (dan yang terpenting, tidak direncanakan) beban kerja yang muncul untuk operator pusat panggilan? Dan dengan biaya siapa beban ini.

Secara resmi, ketersediaan iiko.Biz, iikoCard dan API iikoDelivery tidak dijamin sama sekali. Tidak ada tempat dan apapun. Ini masih bisa ditoleransi ketika kegagalan dari Senin hingga Kamis dan selama setengah jam. Tetapi ketika kegagalan terjadi pada hari Jumat atau pada akhir pekan, pada jam sibuk, dan kemudian yang kedua, yang ketiga ... Sulit untuk menemukan penjelasan untuk ini.

Kami "mendidih" dan mulai mengutuk berat satu minggu ketika kesalahan integrasi API iikoDelivery dimulai pada malam Jumat. Pada saat yang sama, cloud bekerja tanpa gangguan, dukungan meyakinkan kami bahwa semuanya normal, tidak ada pekerjaan restorasi diperlukan. Argumen kami, kata mereka, metode API iikoDelivery mengembalikan kode kesalahan, tidak diterima. Spesialis dukungan utama disarankan untuk menghubungi dukungan profil pengembang. Dukungan untuk API iikoDelivery adalah divisi lain dari perusahaan, dengan akhir pekan pada hari Sabtu dan Minggu (per Juli 2019). Akibatnya, dua hari penjualan terpanas, kami dibiarkan tanpa integrasi eksternal, dengan sejumlah besar pesanan terlewat. Keluhan yang tersebar dari kantor kami dalam lusinan, sebagai hasilnya, bertemu dengan kepala departemen pendukung dan sekarang kami menyelesaikan kegagalan tersebut secara langsung melalui itu.

Ya, ini tidak benar, itu "melompati kepala", tetapi mereka tidak memberi kita jalan keluar. Dan selain itu, kami masih tidak memiliki jaminan ketersediaan iiko.Biz, iikoCard dan API iikoDelivery.

Sementara pos ini sedang dipersiapkan (hampir setengah tahun), ada peningkatan nyata dalam ketersediaan layanan cloud. Pada Desember 2019, kesalahan integrasi masih terjadi rata-rata pada frekuensi yang sama, tetapi durasinya telah dikurangi menjadi beberapa menit. Kami berasumsi bahwa ini disebabkan oleh transisi ke versi 7 (7.0.6022.0).

Apa yang bisa disarankan kepada mereka yang baru berkenalan atau baru saja memulai implementasi ATS?

1. Simpan log semua kegagalan di rumah dengan fiksasi panggilan dukungan dan nomor aplikasi.
2. : , ( : « »)? , ? iikoCloud – . , .
3. Mengingat kenaikan harga bulan Juli - mungkin masuk akal untuk meninggalkan rental iikoCloud dan membeli solusi seumur hidup. Kami masih berpikir, percaya, mengklarifikasi batasan apakah semua layanan yang kami gunakan dapat digunakan secara lokal. Informasi awal: dalam hal apa pun, integrasi eksternal akan terhubung ke solusi lokal melalui cloud yang disewa, oleh karena itu skema seperti itu pasti tidak akan menyimpan kesalahan integrasi.

Pelatihan

Bagaimana kita belajar dan terus belajar? Di mana mendapatkan pengetahuan?

1. Dokumentasi resmi. Tempat terbaik untuk memulai.
2. Kursus video resmi.
3. Webinar resmi gratis.
4. Screencasts selama sesi konfigurasi jarak jauh dari workstation kami oleh para insinyur dari perusahaan pengembangan ATS.
5. Banding dalam dukungan. Terutama menggunakan sumber ini secara aktif ketika berhadapan dengan API iikoDelivery.
6. ( ).
7. Telegram- (~200 , ). , .

Pada tahun pertama bekerja dengan ATS, tim kami yang terdiri dari 4 insinyur “memompa” diri kami sedemikian rupa sehingga kami menyadari bahwa kami siap membantu orang lain. Untuk menjual ATS dan menyediakan layanan, perlu untuk mendapatkan status mitra.

Kondisi terperinci dalam NDA, kami tidak memiliki hak untuk berbagi. Tetapi secara umum, maknanya sederhana: perusahaan mitra mengkonfirmasi tingkat kualifikasinya (setidaknya satu karyawan harus lulus ujian dan mendapatkan sertifikat) dan setelah itu menerima hadiah untuk setiap implementasi ATS. Plus memiliki hak untuk memberikan dukungan berbayar.

Sertifikasi dan ujian

Persiapan ujian dimulai pada Maret 2019. Kami mempelajari dokumentasi secara rinci, menyimpan dokumen bersama dengan komentar, dan secara aktif mendiskusikan detail di antara mereka sendiri. Dengan pertanyaan-pertanyaan yang tidak dapat dipahami, jangan ragu untuk menghubungi dukungan.

Ujian dibayar (1000 rubel), terdiri dari dua bagian. Teori dan praktik. Sebelum latihan hanya diperbolehkan setelah melewati teori. Upaya pertama berakhir dengan "deuce" dan mendapatkan daftar 80 pertanyaan yang jatuh dalam ujian. Butuh 2 bulan untuk menyelesaikan seluruh daftar.

Pada bulan Mei (upaya kedua) mereka berhasil melewati teori, meskipun persimpangan dengan isu-isu terkenal kurang dari yang diharapkan. Mereka mengaku berlatih, pertama kali lagi "deuce". Kami menganggap kerugian secara filosofis - kami tidak membayar untuk pelatihan, jadi kami membayar.

Kami tidak menyerah, di portal afiliasi kami meminta lisensi demo ATS gratis dan mulai pelatihan tentang berbagai skenario di mesin virtual. Pada bulan Desember 2019 (upaya ketiga), insinyur kami berhasil melewati bagian praktis dan menjadi spesialis bersertifikat:



Depan adalah pendaftaran resmi status mitra dan awal bekerja dengan klien pertama. Bagi kami, ini adalah "permainan kelas tinggi" dalam hal O. Bender, yang akan memikirkan hal ini dua tahun lalu.

Apakah game ini sepadan dengan lilin?

Ketika kami hanya melihat sistem otomasi, ATS dipilih sebagai hasil yang menonjol dari persaingan dengan beberapa harga tinggi. Bayangkan situasinya. Direktur layanan pengiriman sejauh ini menggunakan versi RBC "semi-bebas", dan di sini ia diberitahu oleh CTO muda baru: sebulan Anda perlu 50.000 rubel untuk menyewa perangkat lunak. Dan ini berada di wilayah di mana anggaran seperti itu melebihi gaji bulanan karyawan yang memenuhi syarat.

Tetapi enam bulan kemudian, hasil pertama menjadi nyata. Menghubungkan SIP-teleponi langsung ke sistem otomasi, mengatur perhitungan diskon otomatis dan integrasi dengan DeliveryClub memungkinkan membebaskan satu posisi operator. Beberapa bulan kemudian, pengembangan situs baru bersama dengan API iikoDelivery diizinkan untuk mengosongkan posisi operator lain. Orkestra mulai bermain dengan semangat baru.

Selain itu, dengan diperkenalkannya CAP, akuntansi dan gudang mulai menggunakan Diadoc dan DocsInBox, dan di kantor mereka menjadi tertarik dalam pemrograman dalam PHP dan C #. Tanpa keraguan: otomatisasi modern mengembangkan budaya rekayasa dalam perusahaan.

Sekarang tentang masalah dan masalah. Kesalahan integrasi, menurut pendapat kami, terlalu sering untuk solusi cloud. Tingginya harga dan penyewaan solusi itu sendiri, dan dukungan (pada saat yang sama, tidak mungkin untuk menolak fungsi yang tidak digunakan, kami memiliki pembukuan, integrasi dengan pengawasan video dan sistem kontrol akses, setengah dari laporan dan tidak hanya). Minat rendah dari kantor pusat dan dukungan API bekerja sama dengan mitra pembangunan "kecil". Perbaikan individu disepakati selamanya. Ketergantungan yang muncul pada ATS yang dipilih pada peluncuran masing-masing elemen otomatisasi berikut: situs, integrasi, aplikasi mobile, pengembangan sendiri.

Tetapi Anda dapat mengabaikan masalah ini sementara otomasi berfungsi dengan baik (terlepas dari kegagalan) dan menambah kualitas layanan kami. Dan sementara di cakrawala tidak ada pesaing yang kuat dalam hal fungsi dan anggaran.

Terakhir

Beberapa pengamatan lagi yang tidak menemukan tempat dalam teks.

1. Anda harus berteman dengan manajer perusahaan pengembang, ia adalah pemimpin perusahaan. Ini akan membantu untuk menyimpan di tempat yang tepat, menerima klaim, "mendorong" dukungan. Alexander, terima kasih! Buka topi.
2. Anda harus berteman dengan dukungan. Hanya mereka yang bisa menghemat satu menit dari kegagalan. Jika tidak mungkin berteman dengan dukungan, Anda setidaknya harus berteman dengan kepala departemen dukungan.
3. Masalah yang paling kompleks dan terkadang menemui jalan buntu diselesaikan secara tak terduga. Misalnya, layak untuk datang ke METRO EXPO, bertemu dengan direktur pemasaran dan mengeluh tentang kelambanan manajer pelatihan, dukungan API, penanganan kecelakaan - setelah beberapa hari semuanya berjalan seperti jam.
4. Jika Anda berasal dari kawasan ini, kunjungan ke setidaknya PIR EXPO harus menjadi tradisi tahunan Anda. Dalam satu hari, para insinyur akan dapat bekerja di semua stan dengan sistem otomasi terbaik di negara ini. Jangan terburu-buru membayar tiket: jika Anda sudah bekerja dengan seseorang dari pemain pasar utama, Anda dapat meminta undangan gratis.

Biarkan mesin pencari menemukan posting ini berdasarkan permintaan: "Umpan balik tentang otomatisasi restoran di Aiko." Kami yakin cerita ini akan bermanfaat bagi mereka yang hanya memilih sistem otomasi atau sudah melihat R-Keeper, VLSI Presto, Poster, Tillypad, Frontpad, Quick Resto, Dooglys, Traktir atau banyak lainnya.

Saya berjabat tangan dengan semua kolega yang dengannya kami telah mengotomatisasi pengiriman selama dua tahun. Dan, tentu saja, ini bukan final. Ini baru permulaan!

Foto sampul: Ulasan langsung tentang restoran hotpot pintar Haidilao di Beijing , South China Morning Post.