Get best of the week

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

Kami bekerja dengan risiko di tingkat global


Kami di artikel terakhir tentang kasus desain berbicara tentang masalah. Dalam satu contoh, air terjun harus memperluas batas proyek, mengubah BPI, dan merekonsiliasi anggaran. Dalam proyek kedua dengan metodologi yang fleksibel, pelanggan tidak mendapat manfaat sama sekali. Dalam kasus ketiga, pendekatan hibrida memungkinkan kami untuk menyelesaikan proyek dengan sukses dan tepat waktu hanya karena tim proyek di pihak pelanggan termotivasi dengan baik untuk hasilnya dan, mengenali sumber daya yang terbatas, memperkenalkan pengaturan baru, menghapus tugas yang kurang prioritas dari sprint. Kami akan merujuk ke artikel pertama, jadi jika Anda belum membacanya, masuk akal untuk melihatnya setidaknya secara diagonal - di sini adalah tautannya .

Sangat mudah untuk secara retroaktif menggambarkan kasus-kasus ini dan menunjuknya sebagai berhasil atau tidak berhasil. Tetapi dalam proses mengerjakannya, semuanya terlihat lebih rumit dan tidak mungkin untuk menunjukkan hasil negatif sebelumnya. Selain itu, kerugian finansial dan reputasi pada proyek perusahaan bisa sangat, sangat besar.

gambar

Pertama-tama, kami menilai risiko dari sudut pandang kami, sebagai organisasi pelaksana proyek otomatisasi:

  1. Kami menentukan risiko utama dari proyek baru dan kekritisannya.
  2. Kami membandingkan tujuan proyek yang diumumkan oleh pelanggan dengan fakta bahwa kami dapat menganggapnya sebagai kebutuhan nyata berdasarkan pengalaman proyek kami.
  3. Kami menentukan prioritas tenggat waktu, anggaran, fungsi yang dinyatakan.
  4. Maka kita harus membuat keputusan mendasar tentang skenario reaksi terhadap risiko yang telah berkembang.
  5. Kami memperbaiki jumlah kerugian yang dapat diterima untuk diri kami sendiri jika semuanya berjalan sangat buruk.
  6. Kami memperkirakan seberapa besar volume risiko meningkat di seluruh portofolio proyek yang sedang dilakukan Forward, jika kami mengambil proyek baru.
  7. Dan pada akhirnya, kami memutuskan berapa banyak kerugian atau kerusakan reputasi akan memaksa kami untuk memulai proses hukum, berapa banyak yang kami bersedia habiskan untuk dukungan hukum.

Yang penting, di sini kita menilai risiko bagi kita, sebagai sebuah organisasi secara keseluruhan - yang dapat merusak integritas kita, sebagai unit struktural dan menyebabkan keruntuhan organisasi. Penilaian risiko yang lebih rinci dari proyek tertentu dilakukan dalam kerangka kerja proyek itu sendiri dan dicatat dalam dokumentasi proyek sesuai dengan metodologi manajemen proyek yang dipilih.

Sekarang tentang risiko yang berada di luar kendali kami dan aspek-aspek utama yang tanpanya mustahil untuk menyelesaikan pekerjaan dalam proyek-proyek yang dijelaskan tanpa kehilangan reputasi dan finansial.

Itu tidak tergantung pada kita


Berikut adalah daftar risiko yang tidak banyak mempengaruhi atau tidak dapat memengaruhi sama sekali, tetapi kita harus mempertimbangkan:

  1. Kehilangan stabilitas keuangan
    . Pelanggan tidak dapat membayar lebih lanjut dan membekukan / mengakhiri proyek.
  2. /
    , . , . .

    : . — . , .
  3. / ()
    , , , , - .

    : MVNO-, , . , . , - , , , .

  4. , «», / .

    : — , , . , - . , , , .
  5. Perubahan regulasi
    Misalnya, hukum Spring. Ada hal-hal yang Anda tidak ketahui sebelumnya ketika Anda mulai bekerja. Tetapi perubahan-perubahan ini dapat mematikan ekonomi proyek, memaksa pelanggan untuk meninggalkan proyek.

Risiko-risiko ini mudah digabungkan dalam proyek nyata. Kami memiliki sedemikian rupa sehingga pada satu proyek regulator memblokir aliran keuangan dan pelanggan dipaksa untuk membekukan sebagian kegiatan kami. Kemudian manajemen pelanggan berubah dan paradigma manajemen perusahaan direvisi, masing-masing, diperlukan untuk implementasi subsistem yang berbeda dari yang direncanakan semula.

Jerami harus diletakkan di muka


Maksud kami adalah membuat kontrak dan perjanjian dengan benar.

Jika berdasarkan kontrak kita hanya perlu, kita tidak punya hak, dan pelanggan tidak bertanggung jawab atas apa pun - harga kontrak semacam itu tidak berharga. Tidak masalah seberapa baik hubungan pribadi dengan perwakilan pelanggan. Bahkan dalam proyek singkat, perubahan dapat terjadi yang secara fundamental akan mengubah peta kekuatan pada proyek. Pemilik dapat berubah, pelanggan fungsional utama akan meninggalkan organisasi, perusahaan akan memulai kesulitan keuangan.

Perjanjian tersebut harus secara eksplisit menjabarkan kemungkinan untuk mengubah batas-batas proyek atas inisiatif masing-masing pihak dan dalam kondisi apa perubahan dapat dimulai. Menghemat pengacara saat menyusun dan menyimpulkan kontrak adalah hal yang mustahil. Selain itu, perlu bahwa pengacara berpengalaman dalam aktivitas spesifik kami atau secara khusus menghabiskan waktu mempelajari masalah ini untuk mengatur kondisi kerja dengan benar.

Apakah ada komunikasi? Dan jika saya menemukannya?


Negosiasi adalah landasan. Dasar dari kewajiban dan tanggung jawab yang tetap, membentuk harapan dan pemahaman bersama tentang apa yang terjadi.

Tanpa negosiator yang baik, corong penjualan berkurang tajam, karena itu tidak bekerja untuk meyakinkan pelanggan untuk bekerja dengan kami. Dalam proyek di mana risikonya bekerja, negosiator harus membenarkan perubahan anggaran, menyetujui persyaratan baru atau membagi fungsi menjadi beberapa fase. Dalam skenario terburuk, akan perlu untuk menyelesaikan pekerjaan dengan klien dengan beberapa catatan netral, meminimalkan kerugian untuk diri mereka sendiri.

Sebagai contoh, dalam kasus kedua dari artikel terakhir, kami berbicara tentang fakta bahwa pelanggan tidak mendapatkan hasil akhir, pada suatu titik mencetak gol untuk melanjutkan pekerjaan dan tidak membentuk sprint baru. Jika kami memahami bahwa proyek telah dibekukan, maka perlu untuk meringkas pekerjaan yang dilakukan, menyajikan informasi ini kepada pemilik dan mencoba untuk menghidupkan kembali proyek. Ini juga merupakan tugas bagi negosiator.

Tugas negosiator juga termasuk membantu pelanggan fungsional dengan komunikasi dalam tim proyek pelanggan jika mereka tidak memiliki kompetensi.
Negosiator kami, tergantung pada ukuran proyek, fitur-fiturnya, tahap proses negosiasi, dapat penjualan, manajer proyek (RP), manajer akun, direktur.

Penjualan melakukan pembicaraan dan presentasi awal. Dalam proyek besar, setelah negosiasi awal yang berhasil, penjualan mentransfer informasi ke tim proyek dan tidak lagi terlibat dalam negosiasi. Dalam proyek-proyek kecil, penjualan dapat mengambil bagian dari komunikasi dengan pelanggan, sebagian memenuhi fungsi tenaga penjual dan manajer akun.

RP sering dianggap sebagai manajer yang murni bersifat teknis, yang tidak dapat mendiskusikan keputusan mereka tentang logika bisnis dengan pelanggan. Oleh karena itu, perlu untuk menghubungkan artileri berat.

Manajer akun adalah posisi yang tinggi dan akun harus dimasukkan dalam lingkaran yang sama dengan pelanggan. Kemudian kami mendapatkan percakapan yang terbuka dan substantif. Dalam sebagian besar proyek, manajer akunlah yang merupakan negosiator utama dan umumnya bertanggung jawab untuk mengelola risiko pada proyek. Jika perlu, akun tersebut menarik direktur.

Jika pada tahap awal diskusi direktur proyek dilibatkan untuk membahas isu-isu kritis, maka manajer tingkat bawah takut melanggar perjanjian dan meningkatkan situasi masalah agar tidak bertanggung jawab.

Algoritma untuk menganalisis risiko yang dipicu kira-kira sebagai berikut:

  • Kami menganalisis masalah, penyebabnya.
  • Kami mengembangkan opsi untuk model win-win, mengaturnya dalam bentuk peta jalan.
  • Kami duduk di meja negosiasi dan secara terbuka menawarkan opsi kepada pelanggan.

?


gambar

Apakah ada kontrak dan negosiator yang benar dari pihak pelanggan dan kontraktor? Penjual dan pelanggan fungsional menyetujui yang diinginkan, memperkirakan jumlah pekerjaan? Bahkan para pembuat keputusan menyepakati segalanya? Masih terlalu dini untuk bersantai.

Menjelang proyek itu sendiri berbulan-bulan, dan kadang-kadang bertahun-tahun bekerja dengan tenggat waktu, aktivasi pekerjaan pada tahapan proyek, komisioning fungsional untuk operasi eksperimental dan industri, pelatihan pengguna.

Agar pekerjaan menjadi efektif, motivasi dan minat yang memadai dari tim pelanggan dan kontraktor diperlukan. Dan baik bagi kita, sebagai pemain, untuk mengetahui motivasi apa yang dimiliki oleh tim pelanggan. Dan kadang-kadang bahkan masuk akal untuk fokus pada ini pada tahap awal proyek untuk lebih memahami keseimbangan kekuasaan dan kepentingan. Anda dapat menawarkan pembuat keputusan pelanggan untuk memperkenalkan motivasi khusus untuk timnya.

Secara global, ada dua pendekatan:

  1. Moneter

    Ketika proyek selesai tepat waktu dengan mempertahankan margin, tim menerima 5-7% dari biaya pekerjaan.

    Dalam praktiknya, sirkuit jarang bekerja. Sebagian besar proyek tidak selesai tepat waktu, karena dalam proses implementasi ada banyak perubahan. Karena itu, para peserta menjadi terdemotivasi - mereka bekerja selama hampir 6 bulan pada malam hari untuk memenuhi tenggat waktu, dan sekarang pengaturan telah berubah, rencana dasar proyek telah ditulis ulang, kalender telah diperbarui dan total periode telah meningkat tiga bulan.

    Kesenjangan dalam kepentingan pemain dan bisnis. Kontraktor menunggu insentif dalam periode waktu yang ditentukan dan terhadap perubahan yang mempengaruhi anggaran, biaya tenaga kerja, dan perubahan waktu. Dan bisnis tidak lagi membutuhkan pernyataan asli dari masalahnya. Bisnis menyadari bahwa sekarang trennya berbeda.

    , , .


  2. . — , , . . , , .

    — . . .

    Unsur ketiga awalnya adalah penghasilan yang layak. Tanpa ini, Anda tidak dapat merekrut tim yang memenuhi syarat untuk suatu proyek. Tanpa ini, spesialis tidak akan berpikir tentang kualitas kode atau kebenaran proses bisnis yang dikembangkan, tetapi tentang fakta bahwa ia dibayar sedikit.

Dalam kasus ketiga dengan metodologi hybrid, kami memiliki tenggat waktu yang ketat untuk meluncurkan MVNO. Tim pelanggan sangat termotivasi pada hal yang sama dengan kami - peluncuran yang sukses. Tidak ada permainan yang menyamar, persaingan antara unit dan latensi. Ada interaksi aktif, keinginan untuk setuju untuk mendapatkan hasil. Dan sebagai hasilnya, kesuksesan adalah peluncuran MVNO tepat waktu.

Kesimpulan


Otomasi bisnis adalah risiko yang lebih besar bagi klien daripada bagi kami yang berkinerja. Tapi pertama-tama, itu tergantung pada kita bagaimana situasi akan berkembang, jika ada masalah pada proyek. Kita harus dapat, tanpa kerusakan fatal pada klien dan diri kita sendiri, untuk membawa proyek untuk diluncurkan dan tidak meninggalkan klien pada belas kasihan nasib.

Setelah setiap proyek, kami melakukan retrospektif. Kami ingat apa yang kami miliki di input proyek dalam hal pekerjaan, evaluasi, biaya dan membandingkan dengan apa yang terjadi pada akhirnya. Kami menganalisis penyimpangan dan risiko yang terlibat: di mana kami membuat kesalahan dalam penilaian, di mana pelanggan sendiri mengubah tugas, di mana masalahnya tidak bergantung pada kami sama sekali. Tujuan retrospektif adalah untuk meningkatkan akurasi estimasi input tenaga kerja dalam proyek serupa di masa depan.

Hasil Retrospektif - Materi Pelatihan. Karyawan kami melihat di tempat apa kurangnya pekerjaan analis dan kekurangan TK mengakibatkan biaya tenaga kerja yang tidak perlu. Kami juga membuat repositori dari solusi terbaik. Dan ketika dalam proyek baru kita melihat bahwa tugasnya serupa, kita beralih ke repositori - menggunakannya kembali, dan tidak menciptakannya dari awal - sehingga mengurangi biaya pelanggan.

Bagi kami sendiri, kami telah mengambil aksioma berikut:

  1. Dokumentasikan semua keputusan dan pengaturan.
  2. Untuk mendekati negosiasi dan pembentukan harapan sebagai suatu proses. Setuju dengan sengaja, jangan jatuhkan semuanya dan jangan diam. Terus menerima umpan balik dari pelanggan.
  3. Pahami sendiri pentingnya memotivasi tim kami dalam proyek dan menjelaskan kepada pembuat keputusan pelanggan pentingnya membangun sistem motivasi untuk hasil dari tim pelanggan.

Bagikan pengalaman Anda dalam komentar. Apa yang paling banyak menyebabkan masalah pada proyek Anda? Risiko apa yang dipicu pada proyek Anda dan bagaimana Anda menangani konsekuensinya?

More articles:


All Articles