🚶🏻 🙍🏽 🏊 Desain teknologi untuk implementasi sistem penagihan untuk klien korporat (bagian 1) 👩🏽‍🔧 🐐 🥐

Ya, semuanya telah ditulis 100 kali tentang manajemen proyek

Sangat benar bahwa kecuali jika malas menulis tentang manajemen proyek menggunakan metodologi yang berbeda. Oleh karena itu, kami tidak akan membahas situasi umum dan kesenangan metodologi yang berbeda. Tetapi kami akan memberi tahu Anda tentang beberapa kasus ketika risiko berhasil, meskipun menggunakan beberapa metodologi manajemen proyek, dan bagaimana kami keluar dari situasi masalah.

Kesulitan khas

Pertama, yang utama dan paling menarik - tentang masalah dari sudut pandang kontraktor-pelaksana proyek otomasi. Semua metodologi harus membantu menyingkirkan masalah bahkan sebelum mereka - kesulitan - muncul. Tetapi dalam hidup ini tidak terjadi.

gambar

Berikut adalah kesulitan khas yang paling sering kita temui dalam proyek:

.
, , - . , . , , , , .

, , , Forward, - - .
CRM- .
CRM , , . , CRM, .

, , , , . CRM . , CRM - , : « / ?».
«» open-source .

- IT-, , . : “ open-source, ”, — , . - « , !»

. , - , , . open-source , - . , 1 .
Ekspektasi berdasarkan waktu.
Sebelumnya, pilihan sistem informasi untuk penagihan dilakukan oleh layanan TI perusahaan. Sekarang semakin sering pilihan dibuat oleh unit yang bertanggung jawab untuk penjualan dan pemasaran. Kurangnya latar belakang teknis, penyebaran layanan cloud dan pertumbuhan informatisasi kehidupan secara umum menciptakan ilusi kesederhanaan. Tidak ada yang berpikir bahwa untuk pekerjaan nyaman saat ini secara gratis untuk pengguna biasa Sumber daya Gmail dari sebuah organisasi besar telah dikeluarkan selama bertahun-tahun.

Karenanya, kami terus-menerus mendengar bahwa harapan untuk waktu pelaksanaan penagihan adalah 3-4 bulan. Jarang pelanggan memperkirakan jumlah pekerjaan pada enam bulan atau satu tahun.

Jika saya mengkompilasi subsistem TOP dengan mana berbagai masalah muncul dalam proyek yang kompleks, maka ini akan menjadi:

CRM
Meja pelayanan,
Akuntansi / inventaris teknis.

Sekarang mari kita beralih ke tiga kasus kecil dan sedikit berlebihan. Semua kebetulan dengan orang sungguhan dianggap sebagai kecelakaan. Tidak ada platypus tunggal yang terluka dalam produksi film.

Saat air terjun terbalik

Sekali waktu ada penyedia internet, dan bukan yang sederhana, tetapi terdiri dari banyak badan hukum yang menyediakan layanan di berbagai kota. Di setiap kota, sebuah badan hukum memiliki tagihan historisnya sendiri, dukungan, kepemimpinan lokal dan banyak lagi yang dibutuhkan oleh sebuah bisnis
.
Jadi mereka memutuskan di badan hukum utama penyedia untuk menggabungkan semuanya menjadi satu sistem, mempertimbangkan uang dan lalu lintas di satu tempat, dan tidak membiarkannya terpisah dengan sistem historis. Untuk menghidupkan semuanya, glavurlitso meluncurkan tender dan memilih pemasok otomasi.
Kami mempelajari dokumentasi tender. Kami melihat bahwa kami memenuhi persyaratan, berpartisipasi dalam tender dan berubah menjadi pemenang yang bahagia.

Masalah mulai

Dan kemudian kesenangan dimulai. Ternyata direktur utama ingin segera mengontrak proyek untuk seluruh badan hukum, untuk memperbaiki persyaratan dan total anggaran dengan ketat. Air terjun klasik air jernih alat tenun.

Kami berkomunikasi dengan staf yang bertanggung jawab atas tender, mendaftarkan BPI (rencana pelaksanaan dasar) proyek, mempelajari informasi terperinci yang disediakan dan mencatat semua persyaratan yang didokumentasikan. Sekelompok kertas ditandatangani, kami memasuki proyek.

Dan kita dihadapkan dengan realitas brutal dalam bentuk ketidakcocokan antara dokumentasi yang disediakan sebelumnya dan situasi nyata di lapangan di kota-kota di mana penyedia hadir. Kami membuat risiko berhasil:

Meregangkan ketentuan implementasi.
Peningkatan tenaga kerja proyek.
Tingkat tanggung jawab penyelenggara tender yang sulit dipahami dalam situasi di mana mereka tidak mengelola sistem historis di lapangan.
Kurangnya minat beralih ke penagihan tunggal di badan hukum lokal.

Mengulang kembali

Kesenjangan yang jelas antara persyaratan formal dan situasi aktual di kota-kota di mana penyedia hadir memaksa kami untuk menghitung kembali persyaratan dan anggaran. Berikan informasi ini kepada pelanggan. Pada saat yang sama, kami memasukkan biaya tenaga kerja tambahan untuk studi sistem historis dalam anggaran.

Kami harus melakukan banyak negosiasi dengan perwakilan perusahaan induk. Kami menawar. Perusahaan induk benar-benar menginginkan penagihan tunggal, sehingga ada penandatanganan kesepakatan tambahan untuk setiap kota.
Hasil keseluruhan dari proyek ini adalah positif. Kesulitan di pintu masuk proyek diselesaikan, transisi ke penagihan tunggal baru untuk kelompok perusahaan berjalan tanpa insiden.

Mengikuti metodologi klasik tidak membantu mengidentifikasi kekurangan pernyataan persyaratan teknis, dan membutuhkan revisi lengkap dari semua perjanjian dengan klien dan penulisan ulang semua dokumentasi proyek.

Tarik anggur

Seorang klien datang kepada kami yang ingin meluncurkan operator virtualnya. Kami menghitung proyek peluncuran MVNO dengan berbagai tingkat independensi dari MNO. Klien menganggap proyek tersebut sebagai diversifikasi bisnis dan tidak memiliki pengalaman yang cukup di bidang telekomunikasi. Penganggaran proyek ini direncanakan akan dilaksanakan berdasarkan dana yang dikeluarkan dari bisnis utama. Pada saat yang sama, pemilik ingin bekerja secara eksklusif pada Agile, mengingat metodologi ini sebagai progresif mungkin dan cocok untuk memulai bisnis baru.

Diputuskan untuk membagi tugas meluncurkan operator ke dalam kuanta kerja kecil dan bekerja pada sprint, menarik sumber daya yang tersedia untuk setiap sprint yang cukup untuk mengembangkan anggaran. Aktivasi seharusnya didasarkan pada hasil sprint.

Hasilnya muncul bahwa kami tidak akan bangga. Masalah yang awalnya dapat diprediksi menunjukkan dalam semua kemuliaan mereka:

Ketidakstabilan penerimaan dana untuk bekerja.
Jeda waktu antara kemunculan anggaran dan alokasi spesialis untuk pengembangan anggaran.
Godaan pemilik untuk membelanjakan dana yang diakumulasikan untuk proyek alih-alih menunggu akhir dari sprint dan pembayaran tindakan. Akibatnya, jeda waktu antara akhir sprint, penandatanganan tindakan, dan pembayaran.

Seiring waktu, minat pemilik dalam meluncurkan operator virtual menurun, dan pada beberapa titik, pelaksanaan pekerjaan sprint pertama kali tertunda untuk periode yang tidak dapat dipahami, dan kemudian dibatalkan sepenuhnya.

Karena itu, keluar dari proyek juga hasilnya, meskipun tidak positif.

Tanpa motivasi pelanggan yang memadai untuk mencapai hasil, metodologi yang fleksibel hanya dapat meminimalkan biaya tenaga kerja kami yang tidak aktif dan tidak dibayar. Tetapi bekerja dalam mode ini sangat mengurangi dan mengalihkan sumber daya dari implementasi proyek yang lebih hemat biaya. Ini adalah pengalaman negatif, dan kami tidak akan meluncurkan proyek dengan kondisi serupa.

Tangkas dengan keterbatasan waktu, anggaran, dan fungsionalitas - WTF ?!

Ya, ada hal seperti itu. Pelanggan mungkin ingin bekerja pada Agile, tetapi pada saat yang sama memperbaiki tenggat waktu, anggaran, dan fungsionalitas. Bagi kami, ini menyebabkan disonansi.

Bagi kami, bekerja pada Agile murni dengan klien menyiratkan bahwa kami menyediakan tim, dan pelanggan mengambil bagian yang signifikan dari upaya untuk mengelola proyek. Kami bertanggung jawab atas pelaksanaan sprint dan manajemen tugas operasional. Manajer proyek pada bagian dari pelanggan sebenarnya bertanggung jawab atas keseluruhan hasil proyek. Pengalaman kami mengatakan bahwa untuk mendapatkan hasil / MVP yang dapat diterima, uji hipotesis pada beberapa area fungsional sistem informasi masa depan, diperlukan 3-4 sprint. Ini adalah periode waktu dan tenaga yang cukup besar. Dan ingat, kami katakan sebelumnya bahwa periode otomasi yang diharapkan sekarang 3-4 bulan? Tidak, kami biasanya tidak keberatan, kami dapat bekerja dengan tenggat waktu seperti itu, tetapi tidak tanpa bantuan tim klien.

Pelanggan yang menganggap Agile sebagai metodologi progresif, karena terdengar pemahaman yang berbeda. Dia ingin kita menyebutkan jangka waktu tertentu, anggaran tertentu, sehingga kita mengelola seluruh RUANG LINGKUP proyek, tetapi pada saat yang sama membuat semuanya terjadi "melalui udara".

Jarang ada manajer pelanggan yang siap untuk bertanggung jawab atas hasil proyek. Seringkali ada substitusi konsep - hampir air terjun klasik mulai disebut "Edge", hanya dengan presentasi dan menampilkan hasil antara setiap dua minggu. Dan di sini kita dengan lancar beralih ke kasus berikutnya menggunakan metodologi hybrid.

Apakah Hybrid Hemat?

Situasinya mirip dengan kasus sebelumnya - pemilik ingin meluncurkan MVNO Lengkap di samping jenis bisnis utama. Klien memiliki tenggat waktu yang ketat, dan proyek peluncuran MVNO terikat dengan beberapa proyek otomasi internal yang terkait.

Pelanggan memberikan batasan yang signifikan pada anggaran, waktu proyek dan memerlukan integrasi sistem Forward dengan sistem informasi internal menggunakan Oracle DBMS. Selain itu, sebagai MVNO penuh diluncurkan, pembelian, pemasangan, dan konfigurasi peralatan telekomunikasi diperlukan. Pekerjaan akan bersamaan dengan tim TI pelanggan dan beberapa tim kontraktor lainnya.

Proyek ini dimulai, beban yang sangat besar di tim kami. Kami harus bekerja dengan pemurnian, berkomunikasi sangat erat dengan rekan kerja. Komposisi tugas dalam sprint berubah sangat dinamis, pelanggan terlibat dalam proyek dan flexit tidak kurang dari tugasnya.

Hasil proyek ini positif. Itu sulit dan sangat menegangkan, tetapi fungsi minimum untuk meluncurkan MVNO dilaksanakan sesegera mungkin, ditentukan oleh pelanggan dalam pernyataan kerja.

Tenggat waktu dan anggaran yang ketat, keterlibatan pelanggan yang tinggi dan pendekatan yang fleksibel untuk pembentukan kumpulan tugas sprint adalah cadangan yang baik untuk keberhasilan penyelesaian proyek. Fitur utama dari proyek ini adalah sinkronisasi sprint semua tim yang meluncurkan sistem otomasi.

Proyek apa yang tidak kita ambil untuk bekerja?

Literasi desain rendah

Bagi kami, literasi proyek diekspresikan terutama di hadapan pengalaman dalam mengimplementasikan proyek dengan karyawan klien, pelanggan fungsional, pengambil keputusan, dan RP dari klien. Kami membuat penilaian pada tahap negosiasi awal. Kami mencoba berkomunikasi dengan DM dan RP secara pribadi. Jika pengalamannya tidak jelas dari komunikasi, maka kita bisa bertanya langsung.

Terkadang pembuat keputusan tidak memiliki latar belakang TI, ia kurang memahami apa pengembangan perangkat lunak, integrasi perangkat lunak yang berbeda satu sama lain, tetapi pada saat yang sama, pembuat keputusan memiliki banyak ambisi. Pembuat keputusan seperti itu dapat mempertimbangkan bahwa otomasi itu sederhana, cepat dan murah, dan vendor dan integrator mengenakan biaya udara. Selama negosiasi, sikap seperti itu cukup mudah dilihat. Adalah penting apakah ada orang yang kompeten di lingkungan DM dan bagaimana mereka dapat mempengaruhi DM. Jika ada orang dengan pengalaman IT dan pembuat keputusan mendengarkan mereka, percaya, maka ini meningkatkan kemungkinan bahwa kita akan memasuki proyek.

Anda dapat bekerja dengan mereka yang tidak memiliki pengalaman proyek, tetapi yang tertarik dengan hasilnya, mempelajari tugas-tugas dan menggunakan pengalaman rekan kerja dan kontraktor.

Anda tidak dapat bekerja dengan manajer yang keras kepala, bangga, dan tuli.

Persyaratan yang Tidak memadai

Pada tahap pra-proyek dan TK, Anda dapat memahami seberapa memadai persyaratan untuk anggaran yang diumumkan. Sikap yang tidak memadai terhadap persyaratan, uang adalah bel penting dan risiko manajerial, yang kemudian akan mengalir ke risiko proyek, karena harapan pelanggan tidak akan dibenarkan. Penyelesaian berkualitas tinggi dari proyek semacam itu sangat sulit.

Kasus sebenarnya: mereka menyiapkan penjualan selama setahun, melakukan proyek pendahuluan, dan menyiapkan dokumentasi. Tetapi pelanggan tiba-tiba mengumumkan di tender kondisi di mana risiko pekerjaan terlalu besar, dan kami menolak untuk berpartisipasi dalam kompetisi pemasok. Kami kehilangan banyak waktu untuk pekerjaan pendahuluan, tetapi salah mengambil risiko dan memasuki proyek dengan persyaratan yang dinyatakan dalam tender.

Contoh lain: MVNO diluncurkan, persyaratan untuk fungsionalitas sistem informasi diperkirakan beberapa ribu poin. Persyaratan ini disusun berdasarkan pengalaman operator di seluruh dunia dan tidak berkorelasi baik dengan kondisi bisnis operator ini. Selain itu, pemilik berarti bahwa peluncuran MVNO adalah jenis startup yang tidak direncanakan untuk menginvestasikan sejumlah besar dana. Pengalaman kami mengatakan bahwa daftar 100+ persyaratan akan normal dalam situasi ini. Untuk sekadar melihat ribuan persyaratan ini dan memberikan masing-masing jawaban dengan indikasi dokumentasi untuk platform Forward, ini adalah biaya tenaga kerja yang tidak akan terbayar, dilihat dari sikap pelanggan terhadap penganggaran proyek.

Kualifikasi rendah dari spesialis teknis pelanggan

Kualifikasi departemen TI pelanggan tidak menjadi masalah tersendiri, jika ini cukup untuk berfungsinya bisnis. Masalah muncul ketika orang berketerampilan rendah digantung dengan tugas-tugas penting dalam proyek otomasi, dengan alasan bahwa "kami memiliki tim TI kami sendiri, biarkan mereka bekerja."

Jika Anda beruntung, maka sebagai hasil dari proyek ini, departemen TI pelanggan akan meningkatkan kompetensi dan mengatasi tugas-tugas tersebut. Tapi mungkin tidak beruntung. Tetapi tidak selalu mungkin untuk berbicara secara dekat dengan pemain biasa, untuk memahami kemampuan dan motivasi mereka pada tahap negosiasi awal.
Kualifikasi yang rendah dari tim pelanggan bukanlah faktor penghambat, tetapi ini adalah alasan serius untuk berpikir dan mengevaluasi kembali semua kondisi interaksi dengan klien.

Artikel selanjutnya adalah tentang risiko.

Proyek perusahaan besar selalu merupakan risiko finansial dan reputasi. Jadi kami akan merilis bagian kedua artikel dan berbicara tentang risiko dari sudut pandang kontraktor otomatisasi.

Sementara itu, kami mengundang Anda di komentar untuk membagikan pengalaman Anda tentang kesulitan dan masalah pada proyek!

Desain teknologi untuk implementasi sistem penagihan untuk klien korporat (bagian 1)