Baru-baru ini, di ruang obrolan yang nyaman, tanggal para Setan mengajukan pertanyaan tentang bagaimana cara "menjual" proyek pembelajaran mesin internal dengan benar. Ternyata banyak dari kita sangat mudah tersinggung tentang kelayakan ekonomi dari kegiatan kita. Sementara itu, untuk melakukan penilaian minimal terhadap profitabilitas proyek, tidak diperlukan MBA - dalam sebuah artikel pendek (10 halaman teks, ke-ke-ke). Saya akan memberi tahu Anda apa ROI itu, bagaimana cara mengevaluasinya untuk proyek internal, peran apa yang dimainkannya. Bukti Konsep, dan mengapa dalam kehidupan nyata semuanya bisa salah. Kami akan melakukan semua ini di sekitar proyek fiktif untuk mengotomatiskan penjadwalan untuk pusat panggilan. Selamat datang di kucing!
Proyek fiksi kami
Pusat panggilan memiliki 100 operator. Mereka bekerja dengan jadwal mengambang, akan bekerja dalam shift 8 atau 12 jam. Pergeseran dimulai pada waktu yang berbeda dan diatur sedemikian rupa untuk memastikan pengawasan banyak orang pada jam-jam sibuk dan sejumlah kecil orang pada jam-jam dingin di malam hari dan pada akhir pekan. Jadwal sedang direncanakan oleh supervisor call center pada malam Jumat gelap, dengan mata merencanakan beban untuk minggu depan.
Satu hari 8 jam dari operator pusat panggilan membebani perusahaan 2.000 rubel. Jika kita berasumsi bahwa ada 250 hari kerja dalam setahun, maka pusat panggilan akan membebani perusahaan 100 2.000 250 = 50 per tahun. Jika kita mengotomatiskan penjadwalan, kita dapat memprediksi beban per jam dan mengatur shift untuk memvariasikan jumlah operator tugas tergantung pada beban perkiraan. Jika perkiraan dan pengaturan pergeseran kami setidaknya 10% lebih baik dari perkiraan dan pengaturan pengawas, kami akan menghemat sebanyak 5 juta rubel. per tahun. Jika kami benar-benar berhasil memeras peningkatan 10%, proyek pasti akan membuahkan hasil. Atau tidak? .. Mari kita berpikir tentang bagaimana membuat keputusan seperti itu.
Menurut ROI
Sebelum memulai proyek besar, alangkah baiknya untuk mengevaluasi kelayakan ekonominya. Cara buku teks untuk melakukan ini adalah menghitung laba atas investasi, ROI.
ROI (Pengembalian Investasi) adalah indikator profitabilitas proyek yang setara dengan rasio pendapatan terhadap investasi yang dihabiskan. ROI <100% berarti proyek tidak akan membuahkan hasil.
Pengeluaran pertama untuk proyek terjadi segera, di awal - untuk pembelian besi dan lisensi, pengembangan sistem dan implementasinya. Ini disebut belanja modal. Selama masa proyek, ia juga harus menanggung biaya - untuk menyewa perangkat keras dan lisensi yang sama, mendukung pengoperasian sistem dan, kadang-kadang, pekerjaan operator. Ini disebut biaya operasi.
Proyek-proyek ML, sebagai suatu peraturan, tidak memiliki "pendapatan instan". Pendapatan proyek hanya beroperasi, mis. tepat waktu. Misalnya, dalam hal pusat informasi kami, pendapatan dibentuk sebagai penghematan biaya bagi operator. Jika biaya operasi proyek melebihi pendapatan, proyek tidak akan pernah berhasil.
Karena pengeluaran modal "instan" pada awal proyek, ROI akan tergantung pada waktu kami mengevaluasi profitabilitas. Biasanya, tahun, cakrawala perencanaan, atau masa pakai sistem digunakan untuk menghitung ROI. Semuanya jelas dengan tahun - ini adalah cara mudah untuk memahami apakah proyek akan membayar dalam setahun atau tidak. Cakrawala perencanaan adalah interval waktu di mana strategi perusahaan direncanakan dan anggaran disusun. Di perusahaan kecil dan dinamis, cakrawala jarang melampaui satu tahun, di perusahaan besar dan stabil bisa dari tiga hingga sepuluh tahun.
Di cakrawala perencanaan, Anda dapat mengganti sampah apa pun, tetapi kehidupan umum dijaga oleh waktu hidup sistem. Biasanya, setelah beberapa tahun sistem berhenti untuk memenuhi persyaratan bisnis, dan itu baik diganti dengan yang baru, dibuang, atau (paling sering) dibiarkan membusuk pada dukungan abadi. Dengan pertumbuhan bisnis yang cepat, sistem tidak selalu dapat hidup selama enam bulan, di pasar yang stabil, sistem menjadi usang dalam 3-5 tahun tanpa modifikasi, dan hanya kotak yang sangat konservatif dalam lingkungan yang sangat konservatif yang dapat bertahan lebih dari 10. Tingkat diskon, penyusutan dan keajaiban akuntansi lainnya akan diserahkan kepada pemodal profesional.
Dengan demikian, perhitungan ROI dilakukan sesuai dengan rumus berikut:
Bukti konsep
Bagaimana kita bisa tahu bahwa implementasi baru akan meningkatkan angka 10%?
Pertama, kita dapat memilih nomor ini secara acak, kocok dari pejabat terdekat. Ini sering berhasil, tetapi tidak jarang menyebabkan bencana. Vanging seperti itu tidak dianjurkan secara publik, namun, para penatua menyadari bahwa banyak keputusan yang sukses, pada kenyataannya, diambil βdengan tanganβ.
Kedua, kita bisa mengandalkan pengalaman implementasi masa lalu. Sebagai contoh, kami memperkenalkan otomatisasi ke dalam call center kelima berturut-turut, sebelum itu kami melihat hasil 7-10%, kami tahu dan dapat menyelesaikan semua masalah umum, dan sepertinya tidak ada yang mengecewakan kami. Semakin banyak implementasi yang kami lakukan, semakin akurat perkiraan kami, dan semakin baik kami memahami efek dari berbagai penyimpangan dari yang ideal pada hasilnya.
Bahkan dengan pengalaman satu implementasi tunggal, perkiraan jauh lebih bermakna dapat dibuat daripada dengan Chuyka. Konsekuensi yang berani dari ini - tampaknya bahkan satu implementasi yang belum selesai akan memberi kita awal yang besar di depan Chuyka. Jadi kita sampai pada ide Proof of Concept, atau PoC.
PoC diperlukan untuk mengkonfirmasi atau menyangkal kinerja hipotesis, serta mengevaluasi efektivitasnya. PoC tidak menyiratkan implementasi yang lengkap, yang berarti dapat dilakukan dengan cepat dan murah. Apa cara mempercepat dalam proyek Ilmu Data?
- Untuk mengambil data secara manual, kotor, langsung dari tempat-tempat yang paling mudah dianalisis. Bahkan jika sumber ini tidak dapat diterima untuk produksi, ini tidak penting.
- Gunakan heuristik paling bodoh sebagai garis dasar. Misalnya, garis dasar untuk memperkirakan muatan hari berikutnya adalah muatan untuk hari ini. Bahkan lebih dingin - beban rata-rata selama 5-7-30 hari terakhir. Anda akan terkejut, tetapi heuristik seperti itu tidak selalu dapat dilampaui.
- Nilai kualitas dengan pengujian balik - jangan melakukan eksperimen lama yang baru. Semua data sudah ada dalam sejarah, kami akan mengevaluasi efeknya.
- Jangan mencoba membuat kode yang dapat digunakan kembali. Semua kode setelah PoC akan dibuang ke dalam ember. Kami mengulangi ini setiap pagi sebelum duduk ke kode.
- Jangan mencoba membuat model yang keren. Tetapkan tenggat waktu yang sulit bagi Anda - satu hingga tiga hingga lima hari per model. Untuk periode seperti itu, itu tidak akan bekerja untuk "menggali" ke dalam implementasi yang kompleks, tetapi akan berubah melalui banyak opsi sederhana. Untuk opsi-opsi ini, estimasi lebih rendah yang andal diperoleh.
- Secara agresif mencari garu, menginjak semua tempat yang konyol, menguji ide-ide berbahaya. Semakin banyak rake yang kami kumpulkan pada tahap PoC, semakin sedikit risiko selama pengembangan produksi.
Tahapan PoC
Durasi PoC biasanya bervariasi dari satu minggu hingga beberapa bulan. Tugas akan dikerjakan oleh satu orang yang memimpin tanggal Setan. Melakukan PoC juga membutuhkan banyak perhatian dari pelanggan bisnis - berbicara di awal PoC dan memahami hasilnya di akhir. Secara total, PoC akan menghabiskan biaya dua bulan kerja untuk DS terkemuka dan beberapa hari kerja pelanggan bisnis. Ini adalah indikator pertama - jika pelanggan tidak menemukan waktu untuk PoC, maka hasil dari proyek besar tidak akan benar-benar diminati.
Jadi, langkah-langkahnya.
- Mulai dari Wishlist dan Buzz Words hingga persyaratan bisnis tertentu. Ini adalah tugas analisis bisnis tradisional, tetapi sangat disarankan bagi DS untuk melakukannya sendiri. Sehingga ia dapat lebih akurat memahami kebutuhan pelanggan dan menyelesaikan tahap kedua ...
- Rumuskan percobaan. Kata-kata yang benar adalah kunci keberhasilan suatu proyek. DS harus menentukan di mana dalam proses bisnis keputusan otomatis dibuat, informasi apa yang tersedia pada input, apa yang diharapkan pada output, seperti apa tugas pembelajaran mesin yang dapat dikurangi, data apa yang akan diperlukan selama pelatihan dan produksi, metrik teknis dan bisnis apa yang akan digunakan untuk penilaian kesuksesan.
- Menangani data. DS harus memahami data apa yang umumnya tersedia untuk kita. Untuk mengevaluasi komposisi atribusi mereka, kelengkapan, kedalaman sejarah, konsistensi. Secara cepat mengumpulkan dataset yang cukup untuk membangun sebuah model dan menguji hipotesis. Akan menyenangkan untuk segera menyadari apakah data dalam produksi akan berbeda dari apa yang tersedia di kereta, dan apa yang telah kami kumpulkan di sini.
- Fitur insinyur dan membangun model. Setan muda dari kuku muda hanya memikirkan model (EROPA), jadi komentar itu berlebihan.
- Nilai kualitas model. Lakukan validasi silang dengan benar, hitung metrik teknis dan bisnis, serta nilai batas yang dapat berfluktuasi dalam produksi. Semua ini harus dilakukan DS juga.
- Evaluasi ROI yang dihasilkan - itu saja demi itu. Untuk evaluasi, Anda dapat menarik perwakilan pelanggan dan seseorang yang tahu bagaimana mendenda. model.
Mari kita lakukan PoC fiksi berdasarkan proyek fiksi kami.
Tahap 1. Transfer "Wishlist" ke tugas
Inilah kata-kata dari Wishlist:
Tampaknya jika kita mengotomatiskan penjadwalan, kita tidak hanya akan menghemat waktu dalam perencanaan, tetapi juga belajar bagaimana memvariasikan jumlah shift tergantung pada beban.
Apa maksudnya ini?
Penting untuk membuat sistem yang, menurut riwayat shift dan panggilan, akan memprediksi beban untuk periode berikutnya, serta mengatur shift sedemikian rupa agar dapat secara efektif memanfaatkan beban.
Metrik ramalan prakiraan beban adalah kesalahan dalam jumlah klik per irisan waktu.
Metrik Efisiensi Pemanfaatan Muatan - persentil ke-95 dari waktu tunggu.
Metrik ekonomi - jumlah pergeseran untuk periode akuntansi.
Tugas terbagi menjadi dua - bagaimana memprediksi beban, dan bagaimana mengatur shift.
Pertama, kami ingin memprediksi jumlah panggilan dua minggu sebelumnya sehingga perkiraan tersebut tidak turun di bawah nilai riil lebih dari persentase tertentu.
Kedua, kami ingin meminimalkan jumlah shift per periode untuk menjaga persentil ke-95 dari waktu tunggu dalam batas yang dapat diterima, sementara beban akan seperti yang diperkirakan.
Tugas 1. Prediksi beban
Pada hari Jumat minggu 1, kami ingin memprediksi jumlah panggilan pada setiap jam dalam minggu 3. Hasil perkiraan akan menjadi 168 angka - satu nomor untuk setiap jam pada minggu berikutnya.
Interval satu minggu harus dilakukan sehingga operator punya waktu untuk menyesuaikan dengan jadwal.
Kami akan membuat perkiraan pada hari Jumat sore - di satu sisi, sedekat mungkin dengan tanggal target, di sisi lain, masih ada setengah hari untuk menyelesaikan jadwal secara manual. Kami akan memiliki akses ke data historis tentang permintaan untuk seluruh riwayat, serta kalender. Kami akan membangun banyak fitur dari ini. Akan lebih baik untuk mengikat beban ke rilis kami, tetapi kami tidak akan memiliki data seperti itu di tahap PoC.
Kami mengurangi masalah menjadi regresi. Untuk setiap jam dalam sejarah, kami akan membuat vektor fitur dan memperkirakan bebannya pada jam tersebut. Biarkan metrik sukses menjadi MAPE (atau WAPE, kami akan memikirkannya sepanjang jalan). Validasi silang "dahi" pada data sementara tidak dimungkinkan - kami akan melihat ke masa depan. Jalan keluar yang biasa adalah memecah cerita menjadi lipatan berpotongan dengan shift mingguan (empat minggu?), Dan menganggap minggu terakhir sebagai kontrol. Kriteria keberhasilan adalah apakah WAPE kami (atau siapa lagi?) Dapat disimpan dalam batas yang masuk akal. Sekali lagi, pikirkan batas-batas yang masuk akal ketika percobaan berlangsung.
Tugas 2. Pengaturan shift
Menurut perkiraan beban, kami ingin menutupinya dengan shift sehingga jumlah shift minimal, dan indikator kualitas tetap pada tingkat yang dapat diterima.
Saat ini, kami tidak mengatur operator pada kalender, kami hanya menentukan berapa banyak shift pada hari yang akan dimasukkan dan dengan apa yang tumpang tindih.
Perhitungan akan dilakukan segera setelah selesainya perkiraan beban. Ternyata semua data yang sama tersedia, ditambah perkiraan untuk memuat.
Tampaknya masalahnya dapat direduksi menjadi masalah terbalik dari ransel, yang disebut Masalah Kemasan Bin . Ini adalah masalah NP-complete, tetapi ada algoritma untuk solusi suboptimalnya. Tugas percobaan adalah untuk mengkonfirmasi atau membantah penerapannya. Metrik target adalah jumlah perubahan dalam kombinasi, kondisi batas adalah durasi rata-rata atau maksimum dari menunggu (atau semacam persentil). Kami akan dipaksa untuk memodelkan durasi menunggu sebagai fungsi dari jumlah panggilan dan jumlah operator dalam pekerjaan.
Tahap 3. Kami mempelajari data yang tersedia
Kami pergi ke administrator CRM kami. Kami akan menendang mereka sedikit, dan mereka akan membongkar kami daftar semua panggilan ke pusat panggilan selama beberapa tahun terakhir. Bahkan, kami terutama tertarik pada fakta banding dan waktu penerimaan. Dengan sedikit keberuntungan, kami akan dapat mengumpulkan data tentang durasi panggilan, pengidentifikasi operator dan pelanggan. Di pusat-pusat panggilan yang lebih maju, bahkan mungkin ada semacam klasifikasi panggilan berdasarkan topik dan hasil, tetapi kami belum membutuhkannya.
Sekarang kita pergi ke supervisor call center dan meminta untuk meningkatkan semua jadwal operator selama beberapa tahun. Supervisor akan meminta kami beberapa kali, pucat, minum validolchik - dan beberapa hari kemudian ratusan surat dengan excel terlampir akan diteruskan ke kotak surat kami. Kita harus menghabiskan tiga hari lagi untuk membawa semua ini ke satu meja besar dengan shift. Untuk mengubah, kita akan tahu tanggal, waktu mulai, durasi dan ID operator.
Segera berpikir bahwa semakin banyak pelanggan yang kita miliki, semakin mereka memanggil kita. Informasi historis tentang jumlah pelanggan atau volume output akan berguna - sehingga kami dapat memperhitungkan tren makro akun. Kami kembali ke administrator CRM atau ERP dan meminta mereka membongkar berdasarkan volume penjualan, jumlah pelanggan, atau sesuatu seperti itu. Katakanlah Anda berhasil mendapatkan data berlangganan. Sekarang kita dapat membangun tabel di mana untuk setiap tanggal jumlah klien aktif terlihat.
Secara total, kami memiliki tiga entitas yang diletakkan dalam tiga tablet:
- Panggilan ke pusat panggilan - nomor, tanggal dan waktu, durasi, pelanggan dan pengidentifikasi operator.
- Pergeseran operator - nomor, tanggal, waktu mulai, durasi, pengidentifikasi operator.
- Tren makro memuat tanggal, jumlah klien aktif
Tahap 4. Menghasilkan tanda dan melatih model
Seperti yang Anda ingat, tugas setelah pembusukan dibagi menjadi dua. Bagian kedua, tentang pengaturan shift, kita tidak akan menyentuh sekarang - tidak perlu belajar mesin. Mari kita bicara tentang bagian pertama - memuat perkiraan.
Kami merumuskan percobaan sebagai tugas regresi - "untuk setiap jam dalam sejarah, kami akan membuat vektor fitur dan memperkirakan bebannya pada jam ini." Mari mengumpulkan sampel pelatihan. Baris dalam sampel akan menjadi jam kalender. Setiap jam sesuai dengan target - jumlah klik untuk jam itu.
Sekarang mari kita pikirkan tanda-tanda apa yang bisa kita gunakan.
- Sebagai permulaan, mari manfaatkan sifat kalender dari data kami. Tambahkan tanda-tanda hari dalam seminggu, jam, hari dalam sebulan. Mereka dapat dikunci dalam cincin .
- Tambahkan jumlah panggilan per jam pada hari-hari dan jam-jam tersebut. Anda dapat mengambil jumlah hit di minggu lalu, serta rata-rata untuk bulan dan tahun.
- Kami menambahkan dengan cara yang sama jumlah hit pada jam dan hari yang sama dalam seminggu.
- Buka jendela agregasi lebih luas - tambahkan jumlah rata-rata hit pada hari ini dalam seminggu dan saat ini.
- Mari kita coba untuk segera menormalkan jumlah panggilan ke tren pemuatan. Kami akan menguji keduanya pada nilai normal dan normal.
- Tambahkan musiman - jumlah klik per bulan tahun lalu, dinormalisasi dengan tren beban.
- Untuk jaga-jaga, kami juga menambahkan data mentah tentang tren beban. Dan kami akan mengambil nilai pada saat ini dan nilai "bergeser" - seminggu yang lalu, sebulan yang lalu.
Kami akan mencoba tidak hanya fungsi kesalahan "normal" RMSE, tetapi juga WAPE - itu lebih cocok untuk tujuan masalah. Untuk validasi, kami tidak akan dapat menggunakan validasi silang K-fold - akan ada kesempatan untuk melihat ke masa depan. Oleh karena itu, kami akan menggunakan partisi Nested Folds , dan memperbaiki ukuran lipatan uji sama dengan, katakanlah, tepat 4 minggu. Dan batas lipatan akan ditetapkan tepat pada tengah malam Senin.
Untuk PoC kami akan mencoba dua model - yang linier dengan regularisasi L1 dan potongan kayu yang paling disukai. Untuk model linier, jangan lupa untuk membakukan (dan logaritma jika perlu) tanda-tanda, dan untuk sepotong kayu, buka sekrup parameter regularisasi lebih agresif.
Langkah 5 dan 6. Kami akan mengevaluasi kualitas model dan efek ekonomi.
Jadi, semua persiapan telah selesai, dan kami akhirnya dapat beralih ke bagian paling menarik dari PoC - menganalisis hasil dan membuat keputusan.
Sayangnya, seluruh contoh itu spekulatif, tanpa data nyata, sehingga hasilnya akan tersedot keluar dari jari. Agar tidak terlalu malu, saya mengambil angka sesuai urutan dari buku "Optimalisasi Pusat Panggilan" oleh Ger Koole (saya tidak sengaja menemukannya saat menulis artikel ini Β―\_(γ)_/Β― ). Gambar dari sana adalah contoh perkiraan beban.
Untuk memulainya, kami dapat memprediksi beban per jam dengan WAPE = 14%. Dimungkinkan untuk mencapai kesalahan kurang dari 10% pada 43% jam, kurang dari 20% pada 70% jam.
Secara umum, ini sangat bagus - kami cukup akurat menangkap fluktuasi harian, siklus mingguan, dan tren jangka menengah. Kami membakar hanya pada fluktuasi acak, dan, kemungkinan besar, kami tidak akan bisa menghindarinya.
Menurut beban, kita dapat dengan mudah menghitung jumlah operator yang harus dalam shift pada waktu tertentu. Kami menulis algoritme shift scheduler non-optimal yang rakus dan menghitung bahwa kami dapat menghemat 10% shift pada beban perkiraan. Ternyata jika, selain shift 12 jam, kami memperkenalkan shift 8 jam dan secara cerdik mengaturnya selama berhari-hari, kami dapat menghemat 5% lagi.
Kami menerjemahkan indikator menjadi uang. Biaya pemeliharaan pusat panggilan tahunan saat ini adalah 50 juta rubel per tahun. Percobaan kami menunjukkan bahwa kami dapat mengurangi jumlah ini hingga 15%, yang akan menghasilkan penghematan hingga 7,5 juta rubel per tahun, dan untuk seumur hidup - hingga 22,5 juta rubel.
Ini adalah efek yang sangat bagus, dan saya hanya ingin mengenali PoC sebagai sukses. Namun, marilah kita berlama-lama dan menganalisis apa yang salah.
Risiko yang Mempengaruhi Manfaat Ekonomi
Kami mendapat efek positif karena pengurangan jumlah karyawan. Kami mampu mengurangi jumlah karyawan dengan mengurangi jumlah shift. Kami dapat mengurangi jumlah shift karena redistribusi mereka sesuai dengan perkiraan beban. Kami dapat memprediksi beban menggunakan simulasi berdasarkan data historis.
Pertama, jika pola penggunaan produk yang dilakukan oleh call center kami berubah, data historis akan kehilangan relevansinya. Kemungkinan bahwa polanya tidak akan berubah selama tiga tahun ke depan cukup kecil. Adalah perlu untuk meletakkan biaya pelatihan lebih lanjut dan koreksi model dalam perjalanan hidupnya.
Kedua, kami memperkirakan bebannya cukup akurat, namun, dalam 30% kasus kami membuat lebih dari 20% kesalahan. , . .
-, PoC' , , . - , , . - , .
, "" . , .
, .
,
PoC , .
-, . , CRM. , . , . , . , CRM -. , , .
-, , , , . , , β , . , , . - β .
-, β , , . , , - . , . - - , !.. , . , β 2-5 , 3-5 .
, .
20 . . .
β 5 CRM, 40 , 5 , 10 , 5 , 3120,5 , 23 . 65 , 24 . β 1,3 + 0,48 3 .
β 10 + 60 + 10 + 20 + 10 + 3121 + 53 = 110 51 , 2,2 + 1,02 .
β . 20 + 80 + 20 + 40 + 10 + 3122 + 55 = 170 97 , 3,4 + 1,94 .
, 40% , .
ROI
15% , 22,5 , 7,5 . 1,3 + 0,48 , +6,2 (+377% ROI) +21 (+1160% ROI) . .
, , . , 50% , 10%- , 5% . 2,5% β 7,5% 15% . 3,75 , 11,25 . .
β 2,2 1,02 . +55% ROI , +252% . , .
20%- . 5% , 2,5% , 1,25 , 3,75 . , . , 3 +17% ROI. , . , 20%- .
3,4 . ROI +121% . 3 +108% ROI "" .
, , ROI +55% +252% , , . , .
| | Income | Dev | Support | ROI 1 | ROI 3 |
|---|
| Optim | Optim | 7,5 | 1,3 | 0,5 | +4x | +11x |
| Optim | Real | 7,5 | 2,2 | 1,0 | +2x | +6x |
| Optim | Pessim | 7,5 | 3,4 | 1,9 | +85% | +3x |
| Real | Optim | 3,75 | 1,3 | 0,5 | +155% | +5 |
| Real | Real | 3,75 | 2,2 | 1,0 | +48% | +2,5 |
| Real | Pessim | 3,75 | 3,4 | 1,9 | -7% | +112% |
| Pessim | Optim | 1,25 | 1,3 | 0,5 | -14% | +108% |
| Pessim | Real | 1,25 | 2,2 | 1,0 | -50% | +17% |
| Pessim | Pessim | 1,25 | 3,4 | 1,9 | -69% | -29% |
PS
PoC, , ? , ...
-, , WFM, WorkForce Management. , β , . - , , . $1000 $2500. WFM , . , WFM -. , ?
, β , . DS', . . , . , . .
, . "" 7,5%, 37,5 . . . β ROI. β . ROI 26,66 , 53 . ROI 27 .
.
-, . - - . .
-, . , . .
β .
Kesimpulan
- WFM -. , - . WFM β .
- β .
- , ,
? , PoC'. - PoC' , ?
- β - .