Kiat untuk pelanggan fungsional. Tekan Δ untuk membaca

Terkadang ada beberapa tips selama implementasi misi proyek TI - “tekan W untuk maju” . Untuk setidaknya membantu mereka yang menggantikan pelanggan fungsional (banyak tergantung pada proyeknya), kami telah mengumpulkan 10 tips teratas yang akan membantu Anda menyelesaikan misi dengan sukses, yang diberi nama kode "implementasi sistem otomatis".

Yang dimaksud dengan pelanggan fungsional (FZ) adalah seseorang atau sekelompok orang yang menerjemahkan persyaratan fungsional dasar sistem TI. Jika Anda termasuk dalam deskripsi ini, atau mengelola proyek, maka artikel itu akan bermanfaat bagi Anda dan, semoga, menarik.



Artikel ini adalah "jeritan jiwa" dari salah satu manajer proyek perusahaan kami Digital Design Sasha. Sasha telah melakukan banyak proyek bagus dan sangat bagus, jadi kami percaya dan mendengarkannya. Dia tahu persis bagaimana cara berhasil menutup proyek. Sasha berbagi algoritme dengan kami, dan kami berbagi dengan Anda.

Sebelumnya, Desain Digital memiliki lebih banyak proyek otomatisasi kantor, sekarang vektor telah bergeser ke proses bisnis individu. Dengan demikian, cerita telah terakumulasi tentang proyek otomatisasi audit, tata kelola perusahaan, proses SDM, alur kerja kontrak dan pengadaan, klaim dan klaim, dan bahkan menangani kecurigaan penipuan di bank.

Kami melakukan ini semua di platform BPM asli kami Docsvision, tetapi rekomendasi ini berlaku untuk otomatisasi proses lain menggunakan platform lain.

Langkah nomor 1. Kumpulkan Informasi


Agar lengkap dan untuk mengevaluasi skala proyek, Anda perlu mengumpulkan informasi yang komprehensif dan mempelajarinya:

  • kontrak
  • dokumentasi tender
  • Kerangka Acuan
  • informasi tentang kontraktor,
  • tanggal proyek
  • unit / anak mana yang terlibat,
  • informasi tentang proses bisnis otomatis (bagaimana itu dijalankan, peraturan apa yang didokumentasikan, seberapa relevan mereka),
  • keadaan otomatisasi saat ini (jika, misalnya, Anda mengubah sistem lama ke yang baru).

Sadar - berarti bersenjata. Hanya saja, tidak perlu bersiap untuk bertarung. Jika perang, maka pertimbangkan proyek yang sudah bisa dimakamkan.

Langkah nomor 2. Identifikasi Stakeholder


Jika RP membaca artikel ini (dan kami ingin mempercayainya), maka frasa ini telah membentak mereka. Sebagai aturan, RP terlibat dalam penentuan pemangku kepentingan.
Tetapi mengapa kami menyarankan pelanggan fungsional untuk melakukan ini? Ya, karena dia tahu jauh lebih baik bagaimana semuanya berjalan di dalam perusahaan, di mana dan bagaimana kepentingan kolega bersinggungan.
Dalam buku teks tentang manajemen proyek ada klasifikasi yang membantu untuk tidak melewatkan pihak yang berkepentingan - kami serahkan ke RP, dan Undang-Undang Federal, untuk menyusun daftar ini, lebih baik untuk menjawab pertanyaan-pertanyaan ini sedetail mungkin:

  1. Siapa yang akan terpengaruh oleh proyek selama implementasi? Siapa yang harus pindah? Siapa yang harus memberikan sesuatu (anggaran, sumber daya, waktu mereka)?
  2. Siapa yang akan terpengaruh selama operasi industri (ketika semua orang akan menggunakan sistem)? Pekerjaan siapa yang akan berubah setelah implementasi?

Ketika proyek menerima permulaan resmi (misalnya, berdasarkan pesanan), penting untuk tidak lupa memberi tahu semua orang ini, untuk menyatakan tujuan proyek, untuk menetapkan tenggat waktu dan memperkenalkan para peserta.

Lebih jauh di sepanjang jalannya proyek, perlu untuk kembali secara berkala ke daftar ini dan merencanakan tindakan Anda dengan mempertimbangkan kepentingan para pihak yang tercantum di dalamnya. Untuk masing-masing dari mereka, Anda perlu memahami bagaimana dan kapan kami harus melibatkan mereka dalam proyek, dalam konteks apa untuk melakukannya dan di bawah saus apa mereka harus diberi informasi.

Langkah nomor 3. Temukan RP




Pelanggan harus memiliki manajer proyek sendiri. Percayalah, RP kontraktor tidak akan dapat sepenuhnya menggantikannya. Setidaknya, tenggat waktu pasti tidak akan dipenuhi jika hanya kontraktor yang bertanggung jawab atas seluruh organisasi kerja.

RP harus menjadi manajer proyek, mis. memiliki pengalaman dalam manajemen proyek adalah entitas unik yang bahkan tidak bisa diganti oleh kabinet buku teks. Dan seorang akuntan dengan keterampilan organisasi yang baik tidak akan bekerja di sini. Jika kita berbicara tentang proyek TI, sangat diharapkan bahwa RP pelanggan berpengalaman dalam bidang TI. Jika tidak, maka biarkan dia mengambil orang tim dari departemen TI.

Tanpa pria emas ini, Anda dapat segera meningkatkan waktu yang direncanakan empat kali! Lebih baik menghabiskan kekuatan, waktu, dan pengaruh Anda untuk mengisolasi orang ini dari kantor proyek (jika ada) atau menemukan, menyewa dengan cara lain.

Dan ketika Anda menemukannya, pastikan bahwa dia melakukan langkah 1 dan langkah 2.

Langkah nomor 4. Tentukan kelompok kerja


Kelompok kerja adalah mereka yang akan merumuskan persyaratan untuk sistem, baik fungsional maupun teknis.

Penting untuk menentukan kelompok kerja bersama-sama dengan RP, berdasarkan daftar Anda dan orang-orang yang berminat (lihat ayat 2).

Ketika menentukan kelompok kerja, seseorang harus dipandu oleh aturan bahwa kelompok lebih dari 10-12 orang sulit untuk dikelola, dan akan sulit untuk mengoordinasikan kepentingan dalam kelompok tersebut. (Jika KPI akan menyelesaikan proyek sebelum akhir tahun ini, maka 10 adalah batasnya).

Kelompok kerja harus mencakup (kecuali untuk Hukum Federal dan Republik Polandia):

  1. Pemilik proses (jika bukan Undang-Undang Federal) adalah faktor kunci keberhasilan. Harus ada seseorang yang secara tegas akan mengatakan apa yang dibutuhkan dan apa yang tidak, yang akan menyelesaikan semua persyaratan yang saling bertentangan dan siapa yang dapat memutuskan bahwa proses akan diubah setelah implementasi sistem, jika perlu. Sebagai aturan, ini adalah kepala unit yang memiliki proses otomatis: direktur departemen manajemen kasus, jika kita berbicara tentang pekerjaan kantor; direktur audit internal, jika kita berbicara tentang audit kegiatan keuangan dan ekonomi, dll.
  2. Spesialis departemen, yang akan menggunakan sistem, yang bekerja cukup baik di perusahaan dan tahu bagaimana proses bisnis otomatis bekerja, tahu di mana itu berbeda dari prosedur yang terdokumentasi dan apa "celah" yang ada di dalamnya ... Sangat bagus jika ada di antara mereka Pernah bekerja dalam sistem seperti itu sebelumnya, atau sudah berpartisipasi dalam pembentukan persyaratan untuk sistem otomatis (belum tentu serupa). Jika ada - ke tim!
  3. Jika proses otomatis melampaui batas organisasi (misalnya, perwakilan anak perusahaan akan bekerja di sistem masa depan), maka menurut prinsip yang dijelaskan dalam paragraf di atas, perwakilan organisasi pihak ketiga yang tertarik harus ditarik, sambil mengingat aturan 10-12 peserta.
  4. Harus memiliki penjaga keamanan! Semakin cepat Anda menghubungkannya ke proyek, semakin baik.
  5. Perwakilan TI akan diperlukan ketika datang ke alokasi kapasitas untuk meng-host sistem, organisasi infrastruktur, bandwidth jaringan, dll.

Omong-omong, satu orang dapat menggabungkan beberapa fungsi.
Kelompok kerja, sebagai suatu peraturan, juga ditetapkan berdasarkan pesanan (dekrit).

Langkah nomor 5. Berpartisipasilah dalam pertemuan pengantar


Secara umum, ini adalah tugas dari kedua manajer proyek dan sebagian besar memeras dokumen "Piagam Proyek", yang mereka persiapkan pada awal proyek.

Dan inilah yang baik untuk dinyatakan pada pertemuan ini:

Tujuan proyek.
Dan tujuan apa, pada kenyataannya, yang ingin kita capai. Dan apakah tujuan proyek yang dinyatakan dalam dokumentasi bertepatan dengan rasa sakit yang nyata yang kita hilangkan? Jika dokumentasi mengatakan omong kosong (ini terjadi), maka jangan malu untuk mengatakan yang sebenarnya kepada kontraktor. Dia akan mengerti segalanya.

Tahapan dan ketentuan proyek.
Biarkan kontraktor memberi tahu kami apa yang akan terjadi pada setiap tahap proyek, ketika partisipasi aktif dari kelompok kerja diperlukan, dan ketika tidak, bagaimana pekerjaan tertentu akan diatur (tes, misalnya).

Dokumen proyek yang dihasilkan.
Singkatnya, apa yang disiratkan oleh setiap dokumen dan mengapa diperlukan.

Ketentuan persetujuan dokumentasi proyek.
Adalah penting bahwa semua anggota kelompok kerja memahami berapa hari mereka harus merumuskan komentar dan berapa lama kontraktor harus memprosesnya.

Menginformasikan tentang proyek.
Seberapa sering dan dalam format apa pertemuan pelaporan dan laporan kemajuan akan berlangsung? Siapa yang harus diberitahu: hanya kelompok kerja atau semua karyawan perusahaan, jika proyek, misalnya, memengaruhi seluruh organisasi. Dalam hal ini, Anda dapat mempublikasikan berita tentang proyek di media perusahaan.

Prosedur untuk membuat perubahan.
Bagaimana prosedur untuk memberi tahu para peserta tentang permintaan untuk perubahan yang berpotensi mempengaruhi waktu, biaya, atau konten proyek, dan tindakan apa yang harus diambil setelah memberi informasi?

Untuk bagian selanjutnya dari presentasi instalasi - tambahkan garam, lada secukupnya (jadwal kerja di proyek, saluran komunikasi, dll.)

Langkah nomor 6. Wawancara secara bertanggung jawab


Saat membuat persyaratan, kami menyarankan agar semua peserta dalam kelompok kerja mematuhi aturan berikut:

Jangan diam
Ketika selama wawancara, pikiran itu merayap ke kepala bahwa dalam proses tersebut ada pengecualian atau sedikit nuansa yang "tidak mempengaruhi", orang tidak boleh diam. Lebih baik menghabiskan beberapa menit untuk menjelaskannya dan memberikan kesempatan kepada kontraktor untuk mengevaluasi apakah ini memengaruhi atau tidak.

Jadilah sensitif
Ya, ya, sensitif. Jika Anda tiba-tiba meragukan bahwa kontraktor telah memahami dengan benar makna yang mendasari proposal, lebih baik luangkan beberapa menit untuk menjelaskannya dan memastikan bahwa semua peserta sama-sama memahami apa yang telah dikatakan.

Periksa kelengkapan dokumentasi
Saat memberikan peraturan, Anda perlu memastikan bahwa set dokumen yang disiapkan untuk dikirim ke kontraktor sudah lengkap. Biarkan semua anggota kelompok kerja memverifikasi integritasnya. Satu juta kasus ketika beberapa peraturan dilupakan dan muncul di suatu tempat dalam tes pendahuluan.

Secara umum, adalah praktik yang baik untuk membaca kembali aturan-aturan ini sebelum memulai proyek dan memulai wawancara untuk memahami dalam waktu di mana mereka berbeda dari kenyataan atau dari harapan, dan kemudian sorot informasi ini kepada kontraktor.

Izinkan kontraktor untuk berpartisipasi dalam proses
Penting untuk memberi kontraktor kesempatan untuk berpartisipasi dalam kegiatan kerja sebagai bagian dari proses otomatis. Biarkan dia mengamati jalan ini - dari awal hingga tahap akhir dari proses - dan dia akan mengerti bagaimana ini terjadi. Tapi ini bukan pengganti untuk wawancara; dan bahkan lebih baik melakukannya setelah wawancara.

Langkah nomor 7. Koordinasikan dokumen dengan cermat


Lama berpikir, apakah perlu untuk menyatakan aksioma ....

Itu perlu.

Dokumen proyek harus dipelajari! Belajar dengan cermat dan terperinci. Dan juga periksa bahwa semua anggota kelompok kerja melakukan ini dengan cermat dan terperinci. Dan intinya bukan bahwa kontraktornya sangat buruk dan mungkin tidak menulis apa yang telah didiskusikan (walaupun itu juga layak untuk diperiksa dengan pasti), itu hanya akan jauh lebih buruk jika prosesnya tidak dijelaskan dengan benar.

Langkah nomor 8. Lakukan tes nyata


Pengujian dengan data uji tidak buruk. Tetapi semua inkonsistensi yang paling tidak menyenangkan muncul ketika mereka bekerja dengan kasus nyata dalam sistem. Ya, ini melelahkan, dan tidak pernah ada sumber daya yang tersedia untuk ini, tetapi ini sangat meningkatkan keberhasilan implementasi.

Biarkan karyawan mengambil tugas nyata dan, bersama dengan kontraktor, melalui PIMI (program dan prosedur pengujian) dengan skenario nyata.

Langkah nomor 9. Jangan takut untuk masuk ke produksi percontohan


Pernahkah Anda mendengar tentang sindrom siswa yang sangat baik? Mereka harus sakit jika Anda mengotomatiskan proses penjadwalan tinggal landas dan mendarat di bandara atau sesuatu seperti itu. Dalam kasus lain, anggap saja sistem tidak akan 100% siap pada saat ia mulai beroperasi.

Ya, itu menyedihkan. Ya, integrator perlu dilempar dengan tomat busuk dan mengatakan bahwa ini tidak boleh dan, secara umum, "apakah Anda menguji sistem Anda di sana atau bagaimana ..." (c) . Tetapi kenyataannya adalah bahwa Anda kemungkinan besar harus menjalani operasi pilot. Untuk keberatan bahwa pengguna tidak akan menyukai ini, saya akan mengatakan bahwa ini akan terjadi dengan sistem 100% siap. Untuk menghindari hal ini, perlu secara bertahap mempersiapkan pengguna untuk kehidupan baru dan untuk stres, berbicara tentang proyek di media perusahaan, buletin, dll.

Karena itu, Anda hanya perlu keberanian dan mulai.

Langkah nomor 10. Selesaikan proyek dengan indah



Saat mengimplementasikan proyek, Anda harus ingat bahwa Anda tidak dapat mencakup semuanya sekaligus. Lakukan sekarang apa yang dapat Anda lakukan sekarang. Biarkan sisanya untuk pengembangan sistem.

Di sini gagasan kontrak masa depan mungkin muncul, menanam dengan “jarum keuangan”, dll. Tapi ini tidak benar. Mencoba untuk memahami yang besar memiliki risiko yang sangat tinggi untuk menjadi konstruksi jangka panjang, yang tidak hanya dapat melewati tenggat waktu, itu mungkin tidak berakhir sama sekali.

Setelah akhir proyek, penting untuk mengadakan pertemuan akhir, mengambil stok proyek, menilai tingkat pencapaian tujuan dan membahas rencana masa depan.

PS


Di atas

  1. Berlaku untuk perusahaan modern, besar dan kecil.
  2. Ini berlaku (anehnya) untuk implementasi proyek sesuai dengan GOST 34 dan dokumentasi sesuai dengan RD 50.
  3. Dapat dikombinasikan dengan metodologi yang fleksibel, tidak ada kontradiksi.
  4. Itu diderita melalui pengalaman pribadi, tidak lengkap, tetapi pasti akan ditambah.
  5. Itu disebut untuk membantu pelanggan lebih memahami kontraktor dan meningkatkan peluang keberhasilan yang saling menguntungkan.

Source: https://habr.com/ru/post/id436590/


All Articles