- Implementasi dimulai dengan prototipe, dimana rantai proses bisnis telah dilaksanakan, yang dapat diterima oleh pelanggan sebagai target. Pada saat yang sama, mungkin ada perbedaan yang harus dihilangkan selama proyek berlangsung.
- Untuk mengerjakan proyek, satu tim dibuat yang terdiri dari konsultan, perwakilan pelanggan dari bisnis dan layanan TI. Perwakilan pelanggan dilatih selama proyek dan, bersama dengan konsultan, menguji prototipe sistem, merumuskan persyaratan sistem, dan menerima penerapannya. Layanan TI mengambil bagian aktif, menerapkan beberapa persyaratan, dan pada akhir proyek mengambil sistem untuk dukungan.
- Selama proyek, beberapa prototipe disiapkan, yang dengan setiap iterasi menjadi lebih dekat dengan kebutuhan pelanggan. Selama proyek berlangsung, persyaratan ditentukan dan diubah beberapa kali.
Faktanya, dalam proyek implementasi ERP yang besar, prinsip-prinsip gesit diterapkan - orang dan interaksi lebih penting daripada proses, produk yang berfungsi lebih penting daripada dokumentasi, kerja sama dengan pelanggan lebih penting daripada kontrak, dan kesiapan untuk perubahan lebih penting daripada mengikuti rencana awal.
Namun, dalam kondisi kontrak yang ditandatangani dengan harga tetap, bekerja dengan sistem terpadu yang besar, prinsip-prinsip ini perlu tanah. Tanpa syarat dan batasan tambahan, proyek kemungkinan besar tidak akan selesai, dan pasti akan melampaui anggaran.
Pertama, ini bukanlah pengembangan sistem yang dapat dimulai dalam beberapa bagian, seperti yang sering terjadi dalam proyek agile, ketika setiap iterasi harus diakhiri dengan pengembangan blok fungsional lengkap yang siap digunakan. Suatu sistem ERP hanya dapat dijalankan secara keseluruhan, bukan sebagian.
Kedua, jika Anda tidak membatasi persyaratan, maka klarifikasi dan perubahan mereka tidak akan ada habisnya, proyek akan meregang, dan akan membutuhkan dana tambahan.
Jadi, masalah pertama adalah bahwa sistem ERP terdiri dari bagian-bagian yang saling berhubungan erat, diresapi dengan proses ujung ke ujung. Oleh karena itu, diperlukan suatu sistem yang holistik dalam segala ruang lingkupnya pada setiap iterasi. Tugas difasilitasi oleh fakta bahwa sistem tersebut tidak dibuat dari awal, ini adalah produk jadi. Seringkali ada solusi industri atau sistem pra-konfigurasi dengan proses standar yang dapat Anda gunakan sebagai prototipe kerja pertama Anda.
Butuh waktu untuk mempersiapkan prototipe berikutnya. Sistemnya besar, kompleks, peserta proyeknya banyak, jadi butuh waktu paling tidak dua bulan untuk menyiapkan prototipe, mengujinya, dan memberi komentar. Dalam kasus kami, iterasi bukanlah dua minggu, seperti pada agile biasa, tetapi 2-5 bulan.
Pada setiap iterasi kami membuat sistem yang lengkap, tetapi ada perbedaan di antara keduanya. Pada iterasi pertama, ini adalah sistem tipikal dengan proses standar atau khusus industri. Proses standar bisa sangat jauh dari apa yang diharapkan pelanggan pada akhirnya. Proses di tingkat atas sama, tetapi detailnya akan sangat berbeda. Dengan mengatakan "pelanggan" yang saya maksud adalah orang-orang yang akan menggunakan sistem - terlepas dari hubungan apa yang menghubungkannya dengan kontraktor - kontrak, atau ini adalah proyek internal perusahaan, di mana kontraktor dapat menjadi departemen TI.
Setelah mengumpulkan persyaratan berdasarkan hasil pengujian prototipe pertama, kami menyiapkan prototipe kedua, di mana semua persyaratan yang dapat diimplementasikan dengan pengaturan diimplementasikan, data uji pelanggan dimuat, semua pertanyaan yang muncul selama pengujian prototipe pertama diselesaikan. Pelanggan menjalani proses bisnis dalam sistem, memeriksa sejauh mana penerapan saat ini sesuai, seberapa efisien sistem tersebut dan memenuhi persyaratannya.
Pada iterasi kedua, pengguna masa depan sistem melihatnya bukan untuk pertama kalinya, merasa lebih nyaman, mengedepankan persyaratan baru yang sudah lebih bermakna dan detail. Idealnya, semua masalah utama harus diselesaikan selama periode ini, karena perubahan menjadi lebih mahal semakin sedikit waktu tersisa sebelum peluncuran.
Pada iterasi ketiga, kita sudah mampu untuk mulai mengembangkan ekstensi atau, seperti yang kita sebut dalam jargon, "penyesuaian" sistem. Ini bisa berupa laporan, prosedur, formulir yang tidak ada dalam sistem standar, tetapi sangat diperlukan, karena tidak selalu mungkin untuk menyesuaikan proses bisnis dengan standar sistem. Keputusan untuk mengembangkan ekstensi dibuat setelah mempertimbangkan semua kemungkinan lain, sejak itu perkembangan dan dukungan mereka adalah kesenangan yang agak mahal, dan ini adalah uang tambahan.
Kami telah mempersiapkan prototipe ketiga selama beberapa bulan sehingga menjadi sistem lengkap yang mendekati target satu. Biasanya, sistem dikonfigurasi sepenuhnya, dengan sejumlah besar data dimuat, dan semua ekstensi penting diinstal. Ini sedang diuji dengan sangat teliti dengan sejumlah besar pengguna. Pengujian ini biasanya berlangsung sekitar satu bulan.
Setelah menguji prototipe ketiga, komentar dan pertanyaan tetap ada, di mana kami menyusun rencana untuk pengembangannya. Dan semua komentar kritis harus dihilangkan dengan peluncuran.
Laju proyek saat ini menjadi sangat intens, waktu dikompresi, seperti saat pertarungan. Penting untuk menyiapkan instruksi, melatih pengguna, mengonversi data, melakukan perubahan organisasi. Masalah yang belum terpecahkan sebelumnya muncul, seseorang ingat bahwa dia lupa mengumumkan beberapa keadaan penting ... Sebelum peluncuran, satu lagi, pengujian penerimaan dilakukan - dan selanjutnya, dimulainya sistem baru.
Ini, tentu saja, adalah deskripsi yang sangat dangkal dari pendekatan iteratif untuk implementasi sistem ERP. Metodologi menjelaskan secara rinci semua proses, termasuk dokumentasi, melatih tim proyek dan pengguna, mengubah data, melakukan perubahan organisasi, dll., Yang sebenarnya tidak berbeda dari pendekatan lain untuk manajemen proyek.
Pertanyaan yang muncul secara alami: bagaimana mengatur proses sedemikian rupa sehingga tidak pergi ke iterasi keempat, dan kemudian ke iterasi kelima atau keenam? Bagaimana Anda dapat menghindari risiko perubahan yang tidak terkendali dan klarifikasi persyaratan, yang secara alami berkembang saat Anda mempelajari detailnya, dan terkadang karena perubahan bisnis?
Tentu saja ada resiko seperti itu, dan ini sangat signifikan. Di pintu masuk ke proyek, persyaratan ditetapkan dalam kontrak, tetapi sebagai aturan mereka diformulasikan secara umum, dan detailnya ada di dalamnya.
Dengan “pendekatan waterfall” di awal proyek, persyaratan diperbaiki, penugasan teknis ditandatangani, yang kemudian menjadi alasan formal untuk menolak mengubah persyaratan atau meminta uang tambahan untuk perubahan. Dalam pendekatan berulang, trik ini tidak dapat diterapkan.
Kami memahami bahwa persyaratan dapat berubah dan akan berubah tanpa gagal. Kami berinvestasi dalam waktu dan uang. Pertanyaannya adalah sejauh mana perubahan ini. Kita bisa membuat kesalahan besar, dan mendapatkan gelombang komentar baru di akhir, terutama jika pelanggan pada awalnya mengacu pada partisipasi dalam proyek "slipshod", memilih orang yang salah untuk berpartisipasi, tidak merumuskan persyaratan dengan jelas, berharap "semuanya akan baik-baik saja" bergantung pada konsultan - maka pada akhirnya kami memiliki masalah yang serius.
Oleh karena itu, komponen terpenting untuk mengurangi risiko persyaratan yang meluas di akhir proyek adalah keterlibatan pelanggan. Implementasi yang sama dari prinsip pengembangan tangkas, yang dengannya tim bekerja sama - pelanggan dan pengembang, dalam kontak dekat sejak awal proyek. Ini memiliki beberapa konsekuensi penting. Pertama, identifikasi awal dari kebutuhan nyata dan ketidaksesuaian dengan kebutuhan sistem ini. Kedua, terlibat dalam proses persiapan sistem, pelanggan menjadi pemiliknya bukan pada saat transfernya dalam bentuk jadi, tetapi secara bertahap, selama keseluruhan proyek. Ini menjadi hasil karyanya, dan pada akhir proyek menjadi tidak mungkin untuk membuat klaim seperti "sistem Anda tidak berfungsi", karena ini adalah sistemnya.
Ini adalah praktik yang baik ketika orang yang paling memenuhi syarat, yang mampu membuat keputusan, dialokasikan untuk proyek 100% dari waktu. Dalam praktik kami, mereka adalah pemilik proses bisnis, wakil mereka, atau karyawan yang menikmati kepercayaan penuh dari manajer layanan. Ya, itu sulit, ya - tidak ada orang tambahan, ya - sulit untuk memberikan yang terbaik. Tetapi ini adalah satu-satunya cara untuk membuat proyek dengan cepat dan mendapatkan sistem berkualitas tinggi. Peserta proyek mendapatkan lompatan besar dalam memahami cara kerja perusahaan, memperoleh pengetahuan baru, belajar bekerja dengan cara baru, dan, sebagai aturan, ini menciptakan peluang karier baru bagi mereka. Anda dapat menganggap proyek implementasi ERP sebagai acara pengembangan personel yang sangat kuat, sebagai penciptaan cadangan personel baru untuk manajer.
Hal kedua yang perlu diperhatikan adalah keterbatasan waktu proyek. Jadwal proyek harus agresif dan tanggal peluncuran tidak boleh berubah. Jika proyek diperpanjang, kemungkinan perubahan persyaratan bisnis meningkat. Jika tanggal proyek bergeser, persyaratan baru muncul, dan situasinya berulang: sekali lagi sistem belum siap, mari kita tunda peluncuran. Kesempurnaan sistem tidak akan tercapai bahkan dengan jangka waktu proyek yang sangat lama, dan semua persyaratan tidak akan pernah teridentifikasi sepenuhnya sebelum peluncuran. Hanya operasi nyata yang menunjukkan semua hambatan dan apa yang benar-benar penting. Oleh karena itu, setelah peluncuran, ada periode stabilisasi setidaknya tiga bulan, di mana tim proyek membantu dan mendidik pengguna, memperbaiki kesalahan, menerima persyaratan baru, dan melakukan perbaikan yang diperlukan.
Untuk menahan godaan untuk menunda tenggat waktu dan memperluas tuntutan, setiap orang harus memiliki insentif yang kuat untuk memenuhi tenggat tersebut. Bagi kontraktor, tentu saja, ini adalah kewajiban kontrak dan anggaran. Motivasi pelanggan biasanya terbentuk dari atas, dari pimpinan atau pemegang saham perusahaan. Misalnya, seorang CEO yang membuat keputusan kesiapan peluncuran mungkin terbelenggu oleh kewajiban kepada pemegang saham. Manajer proyek dan tim proyek dapat dimotivasi oleh bonus di akhir proyek, sesuai dengan tenggat waktu. Kepala departemen akan dihadapkan pada kebutuhan untuk memulai berdasarkan perintah perusahaan.
Ini sangat jarang terjadi jika ada keinginan yang tulus untuk meluncurkan sistem secepat mungkin karena harapan yang menyenangkan akan peluang baru yang diberikannya. Sistem baru ini, pertama-tama, menekankan dan kebutuhan untuk beralih dari antarmuka yang akrab ke antarmuka yang awalnya tidak nyaman, ke kontrol yang lebih besar, ke kebutuhan untuk memasukkan lebih banyak informasi. Pengguna akhir hampir tidak pernah menyambut sistem baru. Butuh waktu bagi mereka untuk berdamai dan menemukan keuntungan di dalamnya. Dan jika motivasi internal untuk meluncurkan tepat waktu pada awalnya tidak dimasukkan ke dalam proyek, peluncuran akan ditunda, karena sistem tidak akan pernah 100% siap untuk diluncurkan.
Mengingat tanggal peluncuran yang ketat, menjadi tidak mungkin untuk memperluas dan menyempurnakan persyaratan tanpa henti. Tim proyek, yang mencakup perwakilan pelanggan, berhenti menominasikan mereka dan mulai memikirkan tentang prioritas, tentang kemungkinan untuk menunda sesuatu, dalam menghadapi tenggat waktu yang tak terelakkan. Tugas manajer proyek adalah dari awal proyek untuk membentuk perasaan peluncuran yang akan segera terjadi, kurangnya waktu. Suasana yang terlalu tenang di paruh pertama proyek membuat paruh kedua akan sangat menegangkan karena balapan yang tidak bisa dihindari. Untuk melakukan ini, tujuan antara harus ditetapkan, dan jadwal proyek dibentuk sedemikian rupa sehingga fase pertama proyek dikompresi dalam waktu, dan karenanya, cadangan dibentuk untuk fase terakhir sebelum peluncuran. Ada berbagai strategi dalam lari jarak jauh,tetapi di sini strateginya harus sama - Anda harus berlari cepat dari awal, Anda mungkin tidak memiliki cukup kekuatan untuk berakselerasi di akhir.
Ringkasan dari semua hal di atas:
- Pendekatan berulang memberikan hasil yang jauh lebih baik dalam hal kedekatan sistem dengan persyaratan pelanggan yang dinyatakan dan tersirat.
- Keterlibatan penuh pelanggan dalam proyek sangat penting untuk menerapkan pendekatan ini.
- Untuk menghindari perkembangan dan penyempurnaan persyaratan yang tak ada habisnya, jadwal proyek harus dibatasi dengan ketat, dan peserta proyek harus termotivasi untuk memenuhinya.
Tentunya ini hanya prinsip-prinsip dasar, masih banyak seluk-beluk yang bergantung pada kondisi spesifik, karakteristik perusahaan dan kepribadian peserta. Dalam setiap kasus, semuanya diputuskan secara individual.