Bagaimana saya bisa mengkomunikasikan risiko mengubah perangkat lunak vendor?

Kami memiliki masalah besar di mana saya bekerja, dan namanya adalah "penyesuaian". Kami memiliki sistem perangkat lunak vendor lama (10+ tahun) yang sebelumnya sangat disukai oleh departemen IT dan akuntansi kami . Di suatu tempat di sepanjang garis perangkat lunak ini mulai menjadi sangat kereta. Kemudian, saya dipekerjakan setelah melakukan penyesuaian.

Hampir setiap masalah yang saya temukan dengan sistem adalah akibat langsung dari penyesuaian; semua yang kita ubah berisiko melanggar perangkat lunak keuangan penting bisnis. Namun departemen akuntansi terus menyarankan perubahan (karena kami selalu mengatakan ya!) Dan tampaknya ada sedikit rasa hormat terhadap seberapa besar dampak perubahan itu.

Beberapa perubahan tidak menyebabkan masalah; formulir dapat (dan dimaksudkan untuk) dikustomisasi dalam perangkat lunak vendor, kita dapat bergerak di sekitar bidang formulir, menghapusnya, dll. Tetapi untuk setiap kustomisasi yang tidak berbahaya seperti itu mereka juga menyarankan perubahan seperti prosedur tersimpan dan pemicu untuk memanipulasi data dalam database untuk aplikasi vendor.

Saya baru-baru ini (nyaris) membuat mereka berhenti mencoba untuk mengimpor pelanggan dari satu program vendor ke yang lain karena informasinya sama sekali tidak kompatibel. Masalah saya dengan bagaimana itu diselesaikan adalah karena saya menemukan sistem tidak bekerja di sisi pengguna; tugas itu lebih rumit daripada yang mereka pikirkan sehingga mereka menyerah. Terlepas dari betapa mudahnya tugas sisi pengguna, operasi yang mereka inginkan seharusnya tidak dilakukan.

Bagaimana saya bisa berkomunikasi bahwa mengubah cara kerja sistem ini memiliki risiko, terutama ketika validitas data dipertaruhkan? Saya seorang karyawan baru (6 bulan) dan itu menjadi status quo, tetapi mempertaruhkan validitas data keuangan kami dan kontrak dukungan kami - setelah dukungan vendor mendengar "X telah disesuaikan" yang memberi mereka banyak alasan untuk tidak untuk mendukung kami atau memberi tahu kami itu salah kami.

Risiko / imbalan dari sistem penyesuaian adalah untuk memberikan keunggulan kompetitif yang memungkinkan perusahaan Anda untuk menawarkan sesuatu yang berbeda dari bisnis lain di ruang Anda.

Organisasi yang lebih besar yang telah bekerja dengan saya memperoleh keunggulan kompetitif dari penyesuaian dan dalam pola pikir itu, mereka membuat mereka melakukan sesuatu dengan lebih efisien, menyediakan lebih banyak fitur atau menghasilkan lebih banyak uang.

Fakta bahwa saya berkomunikasi dalam situasi ini adalah bahwa itu merupakan trade off. Dalam membuat perubahan pada suatu sistem, organisasi sedang mengembangkan basis pengetahuan / keahlian internal sistem mereka sendiri yang mereka tidak akan dapat melakukannya dengan mudah. Basis pengetahuan internal ini perlu dipelihara dan diatur dengan lebih baik sehingga perubahan ini dapat dilacak dan dikelola. Ini juga berarti bahwa itu dapat membatalkan kontrak dukungan vendor dan aspek-aspek lain yang menjadi aset TI yang digunakan perusahaan untuk proses ini.

Risiko terbesar yang saya bicarakan adalah peningkatan versi ke perangkat lunak vendor ketika perusahaan mengadopsi filosofi manajemen data ini. Ini adalah salah satu risiko yang paling mungkin terjadi ketika sesuatu akan pecah. Perusahaan perlu memahami pengorbanan yang dibuat dan semua orang harus mengikuti proses yang diperlukan untuk mendukung mereka.

Untuk budaya Anda, Anda dapat memperkenalkan analogi atau filosofi tetapi Anda membutuhkan seseorang yang bertanggung jawab untuk bisnis untuk menyadari bahwa mereka menciptakan lingkungan yang bahkan lebih bergantung pada spesialis bisnis internal yang membuat perubahan pada sistem ini.

Untuk analogi mobil, bukan mekanik yang perlu tahu perubahan apa yang dilakukan pada mobil, pemiliknya yang perlu memahami bahwa mungkin diperlukan mekanik khusus, lebih banyak uang atau kehilangan layanan untuk jangka waktu tertentu. Mendidik pemilik adalah kunci dari percakapan ini.

Berkomunikasi dengan penghuni kantor? Saya akan menggunakan analogi.

Beri tahu mereka bahwa semua perubahan ini mengubah sedan domestik 4 pintu khas Anda menjadi mobil asing yang eksotis. Setiap kali Anda membawanya ke toko mekanik, dari tune-up, ke lampu rem, ke perbaikan transmisi, itu akan menjadi lebih mahal. "Kami tidak memiliki suku cadang, hanya dealer dengan pengetahuan khusus yang bisa menyentuhnya, kami mencoba tetapi manualnya ada di Jerman".

Anda adalah mekanik yang bertugas membuatnya tetap berjalan. Basis data adalah mesin. Seluruh sistem adalah mobil. Para akuntan mengemudikan mobil. Kelinci kecil yang lucu yang dilewatkan akuntan adalah karakter yang tidak sopan dalam nama belakang pelanggan baru. Tiang lampu yang mereka gunakan untuk membungkus mobil mereka adalah bug penting yang diperkenalkan ketika mereka ingin menambahkan bola disko di dalam mobil.

Yang lain telah memberikan beberapa contoh baik menggunakan analogi dan bahasa lain untuk menjawab pertanyaan utama Anda, yaitu "Bagaimana saya bisa berkomunikasi bahwa mengubah cara kerja sistem ini memiliki risiko, terutama ketika validitas data dipertaruhkan?"

Tetapi berdasarkan komentar klarifikasi Anda tentang bagaimana penugasan tugas itu diberikan kepada Anda, saya tidak yakin analogi apa pun akan membantu Anda dalam situasi tersebut - tampaknya tidak benar-benar ada orang yang salah memahami apa yang mereka minta, tetapi bukannya mereka tidak peduli. Saya pernah berada di sana - mungkin kita semua pernah berada di sana - dan dalam situasi ini saya cenderung melakukan upaya yang lebih besar untuk memperjelas masalah-masalah itu, daripada menuliskannya dengan istilah yang dimaksudkan untuk mengajar daripada memperingatkan .

Fokus pada apa yang dapat Anda lakukan, yang tidak sendirian mengubah pikiran semua orang yang meminta penyesuaian yang membahayakan integritas data dan kontrak dukungan vendor, tetapi sebaliknya berbicara langsung kepada CTO Anda (dan pada gilirannya, CFO) dan menjadi sangat jelas untuk masalah yang dihadapi.

Secara khusus:

• Mintalah CTO atau CFO Anda (atau siapa pun yang memegangnya) untuk melihat kontrak layanan dengan vendor, karena (dan saya akan mengatakan kata-kata ini) Anda diminta untuk melakukan tugas-tugas yang berpotensi melanggar perjanjian dan Anda ingin dapat menunjukkan hal itu dalam laporan kelayakan tugas Anda. Mereka mungkin tidak memberikannya kepada Anda, tetapi mengatakan kata-kata itu sering membuat orang-orang di posisi itu lebih memahami bahwa Anda serius, dan situasinya berpotensi serius.

• Jika Anda melakukan mendapatkan salinan dari perjanjian tersebut, maka ketika Anda menulis laporan tugas kelayakan Anda, mengutip langsung dari itu ketika ada pelanggaran yang jelas.

• Jika Anda tidak mendapatkan salinan perjanjian, maka buat reservasi Anda dengan sangat jelas tentang bagaimana perubahan itu dapat menempatkan perusahaan pada posisi yang buruk sehubungan dengan hubungan dengan vendor.

• Jika kekhawatiran Anda tidak bermasalah karena perjanjian vendor tetapi "hanya" bermasalah karena efek perubahan yang terjadi, uraikan apa artinya: jika itu berantakan seperti yang Anda katakan, maka Anda mungkin hanya memiliki satu atau dua poin-poin sebelum Anda dapat menggunakan baris "dan itu akan roboh seperti rumah kartu".

Singkatnya, lakukan apa yang Anda bisa untuk dengan sangat jelas dan ringkas menunjukkan masalah dan dampaknya bahkan satu atau dua langkah ke depan. Bahwa Anda sudah memiliki kesempatan untuk meletakkan laporan kelayakan di depan para pembuat keputusan adalah hal yang baik; Anda tidak memiliki struktur atau dukungan manajemen (atau etos) untuk mengatakan "Saya ingin Anda menandatangani ini dengan mengatakan Anda mengerti bahwa ini adalah hal yang buruk dan saya tidak merekomendasikannya dan tidak akan bertanggung jawab atas efek dari ini. keputusan buruk "(seperti Anda mungkin jika Anda adalah vendor dan mereka adalah klien), tetapi Anda masih bisa meletakkan banyak hal di atas kertas yang menunjukkan Anda mempertimbangkan apa yang menjadi kepentingan terbaik perusahaan dan asetnya.

Jika mereka memberi tahu Anda untuk menerapkan prosedur dan pemicu yang tersimpan - Anda memiliki masalah proses bisnis utama.

Tantangan terbesar Anda adalah membuat pengguna di sini mengubah cara berpikir mereka. Mereka harus memberi Anda masalah atau persyaratan. Misalnya, kita perlu data bergerak dari sini ke sini .

Ini harus Anda yang menerapkan solusi dengan risiko minimal / paling gain, dan itu adalah Anda yang dapat melakukan ini dengan cara yang akan membantu mencegah masalah perkembangan masa depan.

Beberapa kontrol dalam bentuk pengguna sign-off atau persyaratan, dan kemudian sign-off pengembangan yang dikirimkan juga akan membantu. Jika pengguna harus mengambil tanggung jawab / pertanggungjawaban atas apa yang mereka minta, mereka mungkin akan sedikit memikirkannya.

Tampaknya Anda menyiratkan pilihan Anda adalah antara penerapan berisiko persyaratan bisnis atau tidak sama sekali. Jarang hitam dan putih. Saya kesulitan meyakini akuntan secara langsung meminta prosedur yang tersimpan, tetapi jika ya, Anda perlu memberi mereka apa yang mereka maksudkan alih-alih apa yang mereka minta. Cari tahu apa persyaratan bisnisnya, lalu cari tahu cara paling tidak berisiko untuk mengimplementasikannya.

Jika vendor Anda tidak menyediakan kait yang Anda butuhkan untuk mengimplementasikan persyaratan yang diinginkan pengguna dengan aman, maka masalahnya adalah pada vendor, bukan pengguna Anda.

Anda pada dasarnya mengembangkan perangkat lunak dan karenanya Anda memerlukan metodologi pengembangan. Bagaimana perubahan didokumentasikan? Diuji? Dikerahkan ke QA? Digunakan untuk produksi? dll. Saya pikir jika Anda mulai dengan metodologi dan biaya yang terkait dengannya, mereka akan mulai mengerti. Mungkin biaya dibenarkan dengan baik dan Anda hanya perlu menerapkan prosedur agar mobil tidak pernah membungkus dirinya sendiri di sekitar tiang lampu.