Bagaimana cara mendokumentasikan strategi untuk meningkatkan perangkat lunak komersial?

Kami belum memutakhirkan RDBMS atau server OS kami selama hampir satu dekade. Paket perangkat lunak mission-critical lain sudah mendekati dua dekade dan telah tidak didukung oleh vendornya untuk sebagian besar waktu itu. Beberapa di antara manajemen kami tampaknya berpikir bahwa ini adalah hal yang baik - kami menghemat banyak uang dengan tidak membeli upgrade! Sekarang perangkat lunak yang kritis perlu ditingkatkan, tetapi versi yang baru tidak akan mendukung hal-hal yang sudah ada sejak dekade lalu. Sekarang beberapa dari kita kehilangan rambut kita mencoba mencari cara untuk meningkatkan semuanya sekaligus dengan waktu turun minimal.

Dalam upaya untuk menghindari ini di masa depan, beberapa dari kita sedang mempertimbangkan pembuatan dokumen rencana strategis TI (yang akan masuk ke dalam rencana strategi organisasi, menyempurnakan item dalam dokumen yang lebih besar terkait dengan IT ... mungkin itu membuat IT doc menjadi taktisplan?) dengan harapan kita dapat menerapkannya sebagai bagian dari keseluruhan rencana strategis agensi. Saya telah mengajukan diri untuk mencoba dan merakit bagian "Manajemen Siklus Hidup Perangkat Lunak" (atau sesuatu seperti itu) untuk mengatasi masalah yang disebutkan di atas (dengan kuningan yang kemungkinan dalam dokumen terpisah dari rencana strategis). Hampir semua vendor perangkat lunak menerbitkan siklus hidup dan rencana penghentian untuk produk mereka, dan cukup mudah untuk menentukan "sweet spot" untuk setiap bagian dari perangkat lunak mengingat info tersebut bersama dengan kebutuhan organisasi kami. Bagian yang sulit (bagi saya bagaimanapun) adalah menyusun rencana untuk setiap bagian menjadi sesuatu yang lebih kohesif.

Bagaimana saya bisa mendokumentasikan bahwa klien desktop A, B, C ... tergantung pada OS desktop X dan RDBMS Y, yang pada gilirannya tergantung pada server OS Z, dan kemudian inilah cara kami menyimpan semuanya di "sweet spot" mereka? Pasti ada buku di luar sana, tetapi semua googling saya hanya mengarahkan saya pada hal-hal tentang taktik meningkatkan satu perangkat lunak daripada strategi untuk menentukan kapan harus menerapkan taktik itu.

Sepertinya Anda sedang mencoba menyelesaikan banyak masalah sekaligus (dan itu sepertinya bukan ide yang bagus).

Dari apa yang saya baca:

• OS dan aplikasi yang sudah ketinggalan zaman
• tidak ada strategi jangka panjang
• masalah mendokumentasikan infrastruktur Anda
• kebutuhan mendesak untuk meningkatkan infrastruktur penting

Memutakhirkan "perangkat lunak penting"

Infrastruktur Anda ketinggalan zaman karena keputusan seseorang mudah dimengerti. Mungkin itu ide yang bagus di masa lalu. Ini bermuara pada apa yang ditulis Michael Hampton dalam komentar: Untuk manajemen, Anda berbicara tentang pro dan kontra (risiko). Jadi, jika manajemen mau mengambil risiko, maka oke (apa pun yang Anda pikirkan secara pribadi), dan itu adalah tanggung jawab mereka mulai sekarang. Tetapi seseorang dari orang-orang IT harus memberi tahu mereka apa risikonya.

Jadi hal pertama yang akan saya cari adalah: Apakah manajer tahu tentang risiko perangkat lunak yang sudah ketinggalan zaman? Apakah mereka diberitahu?

Jujur, saya merasa bahwa Anda mungkin tidak akan menemukan sesuatu yang berguna tentang hal itu, jadi saya tidak akan menghabiskan terlalu banyak waktu untuk itu. Itu hanya sesuatu yang dapat membantu Anda sepanjang garis "kami memberi tahu Anda selama lima tahun terakhir".

Saya hanya akan melakukan analisis apa artinya melakukan upgrade itu benar-benar berarti. Persiapkan spreadsheet sederhana dengan kegiatan dan berapa lama waktu yang dibutuhkan (jika Anda tidak tahu, berikan tebakan terbaik dan jelaskan secara eksplisit bahwa Anda tidak tahu pasti). Tapi ingat "tugas upgrade" ini tidak ditentukan dengan baik, tidak mungkin untuk melakukannya sebagai waktu perbaikan / harga perbaikan.

Membuat daftar semacam itu juga akan membantu Anda menelusuri seluruh masalah. Hal berikutnya adalah membuat log risiko dan daftar sumber daya yang Anda butuhkan.

Pada akhirnya, Anda harus memiliki daftar kegiatan, daftar risiko, daftar bahan / orang yang Anda butuhkan. Singkatnya, jangan menangani upgrade sebagai masalah sehari-hari, lakukan sebagai PROYEK. Ini akan memungkinkan Anda untuk memiliki setidaknya beberapa kendali atas kebutuhan akut perusahaan Anda.

Jika Anda memiliki masalah dengan menganalisis kegiatan apa yang perlu dilakukan, Anda dapat mencoba beberapa mind map (sw favorit saya adalah xMind) dan kemudian mengubahnya menjadi dokumen yang lebih formal.

Perhatikan bahwa jika Anda memiliki beberapa opsi tentang bagaimana melakukan peningkatan, Anda harus memberi manajer Anda solusi yang mungkin (jika ada lebih banyak), dirangkum dalam beberapa kalimat, termasuk biaya, hasil dan risiko; idealnya menyebutkan opsi yang Anda rekomendasikan dan mengapa. Karena pilihan terakhir adalah milik mereka - mereka adalah manajer.

Mungkin dalam kasus khusus ini: Sebutkan bahwa peningkatan mungkin tidak dapat dilakukan sama sekali.

Tidak ada strategi jangka panjang

Membuat rencana strategis tidak akan membantu Anda sekarang. Sama sekali tidak akan membantu Anda jika itu adalah dokumen yang dibuat di dalam departemen TI Anda. Rencana strategis adalah sesuatu yang perlu dikaitkan dengan kebutuhan bisnis.

Contoh kebutuhan bisnis: Dalam dua tahun kami akan membuka kantor baru di Cina dan Australia.

Tugas TI yang diturunkan: Bersiaplah untuk membuat karyawan baru mengalami hal yang terburuk, buat infrastruktur di kantor asing, berikan pelatihan bagi karyawan baru (mungkin menggunakan bahasa asli mereka), berikan konektivitas yang aman dari kantor-kantor itu ke pusat, ...

Jika semuanya berjalan dengan baik, Anda dapat memiliki strategi mungkin ... dalam beberapa bulan? Jadi sekitar setengah tahun sampai semuanya disepakati?

Memelihara dan mendokumentasikan infrastruktur Anda

Ini adalah warisan dari masa lalu dan sekarang Anda harus mengubah banyak hal. Memprioritaskan. Buatlah daftar hal-hal yang ingin / harus Anda lakukan sekarang untuk memperbarui sebagian besar hal. Pilih yang bisa menunggu, buat peta jalan kasar. (Peta jalan ini harus menjadi bagian dari strategi TI Anda saat Anda memilikinya.)

Jika Anda memperbarui sesuatu yang berjalan dengan baik, tangani itu sebagai bisnis sehari-hari. Jika Anda menangani sesuatu yang dapat menjadi buruk ("besar" dalam hal waktu yang dihabiskan, orang yang dialokasikan, dll.), Tangani sebagai proyek.

Ada alat yang dapat membantu Anda dengan dokumentasi dan dependensi layanan - CMDB (misalnya misalnya). Tetapi untuk membuatnya bekerja bisa memakan waktu dan Anda masih memerlukan beberapa alat dokumentasi. Ide terbaik adalah menyiapkan wiki untuk dokumentasi di mana setiap orang dapat mulai mendokumentasikan / membuat catatan mulai sekarang. Anda dapat mengatur wiki dalam waktu setengah jam, jadi ini adalah cara yang sangat efektif untuk memulai sesuatu.

Catatan pribadi: Memutakhirkan OS yang lama akan menjadi PITA besar, tidak menyebutkan dokumentasi (mungkin buruk / hilang). Bukankah lebih mudah menginstal server lagi, memigrasikan aplikasi, dan mendokumentasikan semuanya dari awal?