Transformasi Digital: Harapan pada solusi yang akan diperoleh

La pemilihan perangkat lunak itu adalah proses yang rumit dan diartikulasikan:

kami sebutkan di posting sebelumnya tentang pilihan perangkat lunak terbaik, di mana kami fokusanalisis pendahuluan sendiri bisnis perusahaan (tanpanya tidak mungkin untuk membuat pilihan yang bijaksana). Kami juga akan melihat bahwa, untuk pemilihan yang baik, perlu untuk mempertimbangkan sejumlah vendor. Untuk kemudian menganalisis tidak hanya solusi dari sudut pandang "teknis", tetapi juga layanan yang mereka tawarkan dan organisasi sumber daya manusia yang, dalam perusahaan kami, akan diperlukan untuk mendapatkan hasil maksimal dari perangkat lunak baru. Kalau tidak, kita akan menghabiskan uang kita dengan tidak mendapatkan manfaat yang diinginkan.

Sekarang mari kita mundur selangkah dan bertanya pada diri sendiri yang mana persyaratan fungsional dan yang mana cara membeli harus menyajikan solusi ideal untuk kebutuhan kita: singkatnya, apa manfaat utama yang kita harapkan dari perangkat lunak terbaik. Juga dalam hal ini, seperti untuk analisis pendahuluan dari bisnis kami, kami tidak akan mempertimbangkan spesifikasi produk atau teknis tertentu: ini akan menjadi langkah selanjutnya. Untuk saat ini, kami hanya akan mengisi daftar periksa dengan item untuk "centang" yang akan berguna di langkah selanjutnya.

"Kami bertanya pada diri sendiri yang mana persyaratan fungsional dan yang mana cara membeli harus menyajikan solusi ideal untuk kebutuhan kita: singkatnya, apa manfaat utama yang kita harapkan dari perangkat lunak terbaik "

Dan juga dalam kasus ini, milik kita daftar yang harus dilakukan itu diartikulasikan dan melibatkan lebih banyak pengambil keputusan internal ke perusahaan kami: tentu saja bukan hanya departemen TI.

1. Daftar persyaratan fungsional: apakah kita semua selaras?

La pemilihan perangkat lunak kelas perusahaan itu bisa merupakan efek dari kebutuhan, dimanifestasikan oleh sektor internal perusahaan kami, atau mandat langsung dari manajemen puncak (yang memiliki pandangan keseluruhan tentang kepentingan masa depan perusahaan dan strategi untuk diikuti). Asal usul mandat itu sendiri sangat tergantung pada apakah proses yang dipertimbangkan itu inti atau sekunder dari bisnis. Mengingat bahwa seringkali pilihan perangkat lunak baru adalah kunci untuk mengubah proses.

Bagaimanapun, yang benar-benar penting adalah itu semua aktor yang terlibat (termasuk mereka yang mewujudkan kebutuhan, mereka yang membuat keputusan di tingkat tertinggi dan mereka yang memiliki keterampilan teknis dan fungsional untuk melakukan negosiasi di masa depan) harus selaras dengan tujuan pemilihan dan karakteristik dari solusi akan diperoleh.

Hanya dengan asumsi-asumsi inilah kita dapat menyusun konsep daftar persyaratan fungsional. Idealnya, tiga aktor kami (pengguna, manajer puncak, dan analis fungsional-teknis) akan berkumpul untuk bisnis bersama Brainstorming. Tidak diragukan lagi, kemungkinan ini tergantung pada variabel waktu (perlu untuk memperhitungkan biaya internal untuk definisi dan pengelolaan a proyek).

Dan aktivitas penyelarasan ini semakin penting jika kita mempertimbangkan aspek lebih lanjut dari seleksi: seperti pada setiap "Perjalanan pembeli", yaitu proses pembelian yang dimulai dari kebutuhan dan melewati pengambilan informasi tentang penawaran pasar, mungkin ada beberapa "Daerah abu-abu". Tidak jarang bahwa manajemen puncak, atau fungsi perusahaan yang akan mendapat manfaat dari solusi, menemukan diri mereka memiliki pengetahuan umum tentang solusi yang akan diadopsi: ia tahu apa yang diinginkan, bukan bagaimana cara mengatakannya dengan jelas dan eksplisit. Ini juga bermanfaat dukungan spesialis di sektor TI, jika diawaki oleh analis fungsional yang baik yang menempatkan keterampilan yang tepat.

Di sini kemudian beberapa pertanyaan yang akan ditanyakan oleh tim: apa daftar rinci persyaratan? Apakah setiap poin jelas bagi seluruh tim yang menyusun daftar periksa? Apakah siapa pun yang akan melakukan negosiasi sudah memikirkan mandatnya? Dan apakah mandat itu sendiri spesifik dan rinci ataukah ada celah-celahnya? Strategi yang baik untuk diadopsi bisa menjadi metode Scrum: mereka yang berpartisipasi dalam proyek menceritakan sebuah cerita sehingga presentasi diskursif disukai defikonsep-konsep yang akan digunakan untuk pekerjaan.

Daftar persyaratan fungsional: skala prioritas

Seringkali solusi perusahaan di pasar tidak memiliki semua fungsi yang diperlukan oleh pembeli. Manajer perusahaan mengetahui hal ini sejak awal. Dan inilah sebabnya, setelah daftar periksa disusun, kami melanjutkan untuk menetapkan a indeks dari prioritas: setiap perusahaan, begitu tujuan ditetapkan, memiliki tujuannya sendiri.

"Seringkali solusi perusahaan di pasartidak memiliki semua fungsi yang diperlukan oleh pembeli. Manajer perusahaan mengetahui hal ini sejak awal. Dan inilah sebabnya, setelah daftar periksa disusun, kami melanjutkan untuk menetapkan a indeks dari prioritas"

Beberapa menyarankan bergaul untuk setiap persyaratan skor kepentingan yang berbeda: skor keseluruhan dari setiap solusi yang diperiksa adalah jumlah dari persyaratan saat ini dan kepentingan relatifnya. Ini adalah saran akal sehat, asalkan Anda tidak terlalu skematis dalam evaluasi akhir: itu wajar bahwa dalam atribusi penilaian ada juga faktor-faktor di luar perangkat lunak, lebih dari apa pun yang terkait dengan pemasok. Kami akan melihatnya di pos selanjutnya.

3. Kualitas perangkat lunak: daftar indeks

Untuk mengevaluasi intrinsik kualitas perangkat lunak perlu untuk membangun beberapa metrik objektif (oleh karena itu di luar persyaratan fungsional, murni subjektif, disyaratkan oleh perusahaan).

Tidak mengetahui variabel mana yang mengukur produk berarti tidak bisa menjadi sadar akan variabelnya nilai. Sekali lagi, kami ingin menyusun daftar pertama untuk memeriksa solusi individu: kita akan menggunakannya sebagai meteran pada saat pemilihan aktual.

Ada banyak literatur tentang masalah ini: pada kenyataannya, ketikkan saja mesin pencari "Kualitas perangkat lunak" untuk menemukan posting dan buku tentang masalah ini. Titik awal yang bermanfaat adalah suara Wikipedia, yang berisi daftar satu set parameter luar (Yaitu menyangkut kualitas yang dirasakan oleh pengguna), untuk mengevaluasi kualitas solusi yang akan diperoleh. Di antaranya: kebenaran, keandalan, ketahanan, efisiensi. Tapi juga Pedalaman, diverifikasi oleh tim pengembang: rawatan, usabilitas, modularitas adalah beberapa contoh yang terdaftar.

Juga dalam hal ini tim memutuskan indeks prioritas untuk berbagai parameter: misalnya manajemen perusahaan, yang memiliki visi strategis proyek, dapat mengaitkan kepentingan sekunder dengan usabilitas ulang perangkat lunak. Dan tentu saja, dalam fase pemilihan perangkat lunak ini, ada baiknya untuk mengetahui pendapat fungsi kualitas perusahaan (jika ada).

4. Anggaran tersedia

Ini adalah variabel mendasar: sebelum memulai negosiasi, Anda harus memikirkannya anggaran belanja total yang Anda miliki untuk akuisisi perangkat lunak (baik untuk perangkat lunak itu sendiri maupun untuk biaya jam kerja yang diperlukan untuk kegiatan pemilihan). Untuk menetapkan jumlah yang realistis, beberapa sudah memiliki tolok ukur solusi yang sebelumnya diperoleh oleh perusahaan, yang lain mengandalkan dari mulut ke mulut di antara kolega dari sektor yang sama (atau dari kelompok industri yang sama). Memeriksa berapa banyak yang telah dihabiskan sebelumnya untuk solusi serupa memfasilitasi proses pemilihan perangkat lunak.

"Anda harus mengingat keseluruhan anggaran yang tersedia untuk akuisisi perangkat lunak: periksa berapa banyak yang telah dihabiskan sebelumnya untuk solusi serupa yang sebenarnya memfasilitasi proses pemilihan perangkat lunak "

Tentu saja, harga perangkat lunak tingkat perusahaan adalah konsekuensi langsung tidak hanya dari kualitas intrinsiknya, tetapi juga pekerjaan yang dilakukan oleh pemasok untuk merancang dan mengembangkannya: untuk mengamortisasi biaya, ada bentuk akuisisi yang fleksibel (kita akan melihatnya pada titik 6).

5. Keamanan data

Tidak akan pernah ada cukup banyak pembicaraan tentang hal itu: setiap perusahaan mendapati dirinya berurusan peningkatan jumlah data berkaitan dengan bisnis dan pelanggannya. Pada saat yang sama, kita tahu bahwa dalam beberapa tahun terakhir jumlah orang telah meningkat serangan cyber pada database perusahaan. Karena itu melindungi informasi Anda adalah tanggung jawab langsung dan tak terhindarkan dari mereka yang mengelolanya.

Salah satu tugas dari mereka yang melakukan negosiasi adalah mengetahui perlindungan yang dilakukan oleh penyedia. Sementara itu, pengetahuan dasar tentang risiko dan solusi tidak ada salahnya: Manajer departemen TIK dia akan dapat memberi tahu kontak perusahaannya tentang kedua aspek.

6. Administrasi perangkat lunak: preferensi mana?

Putuskan apakah Anda lebih suka solusi di awan (pada infrastruktur jarak jauh) atau on-premise (diinstal pada server perusahaan) bukan hanya kekhasan: anggaran dan jenis manajemen data berdampak langsung bagaimana perangkat lunak ini dikelola.

Bagi banyak manajer, satu solusi di tempat masih terkait dengan persepsi stabilitas dan kontrol: namun, investasi paling substansial harus dipertimbangkan. Di sisi lain, awan ini lebih fleksibel dan lebih murah dalam hal harga, tetapi mengharuskan pemasok untuk memberikan jaminan yang lebih besar dalam hal keamanan data dan kinerja saluran (yaitu kecepatan transmisi dan pelaksanaan program).

Cara diasumsikan biaya juga berubah: harga di tempat umumnya didasarkan pada pembayaran lisensi, biaya penyesuaian, pengaturan awal, biaya perawatan selanjutnya dan sebagainya. Cloud adalah sebuah model bayar per penggunaan: hasil yang lebih besar, biaya yang lebih tinggi. Biasanya, dalam mode cloud, semua biaya yang membentuk biaya diubah menjadi biaya yang merangkumnya, biasanya lebih rendah (dibandingkan dengan komitmen kontrak multi-tahun, sering dari tiga hingga lima tahun).

7. Jika perangkat lunak harus diubah: titik kelemahan dan kekuatan

Ini mungkin tampak paradoks, tetapi hanya tampaknya: daftar periksa yang baik dari harapan kita pada solusi baru ... tidak mengabaikan analisis perangkat lunak yang perlu diubah. Tentu saja, kami tidak merujuk pada situasi instalasi pertama.

"Daftar periksa yang baik dari harapan yang kami berikan pada solusi baru ... tidak mengacuhkan analisis perangkat lunak yang perlu diubah"

Pertama, tujuannya adalah untuk menunjukkan kelemahan: adalah kekhasan yang membuat kami mencari produk yang berbeda. Bahkan usia perangkat lunak dan perlakuan agresif pada saat yang sama dapat terbukti menjadi langkah yang salah.

Namun, kami mungkin juga harus menuliskan beberapa kekuatan: tidak dikatakan, pada kenyataannya, bahwa manajemen proses dengan solusi lama tidak lengkap dalam setiap aspek.

Juga selama analisis ini, berguna untuk melakukan pekerjaan bersama: pengetahuan fungsional e pengetahuan teknis keduanya berjalan beriringan dan keduanya berkontribusi pada evaluasi yang lebih konkret dari kualitas perangkat lunak. Bahkan yang berubah!

Secara pribadi, saya berpikir bahwa ketika perangkat lunak tidak lagi memadai itu tentu bukan kesalahan mereka yang membuat pilihan pada saat itu. hanya pasar telah berubah dan perangkat lunak itu tidak menanggapi kebutuhan bisnis baru. Inilah sebabnya mengapa orientasi terbaru semakin menuju a refactoring aplikasi terus menerus.

penulis Paolo Ravalli

CEO Mainline srl