Melarang atau mengendalikan "TI Tersembunyi ..." Siapa yang harus menulis dan memelihara aplikasi perangkat lunak ad-hoc?


61

Perusahaan yang lebih besar biasanya memiliki masalah, bahwa tidak mungkin untuk menulis semua program yang diinginkan karyawan (untuk menghemat waktu dan mengoptimalkan proses) karena kurangnya staf dan uang.

Kemudian program tersembunyi akan dibuat oleh beberapa orang yang memiliki (setidaknya beberapa) pengalaman pengkodean (atau oleh siswa / magang murah ...). Dalam beberapa keadaan aplikasi ini akan meningkatkan kepentingan dan menyebar dari satu pengguna ke seluruh departemen.

Lalu ada titik kritis: Siapa yang akan memelihara aplikasi, menambahkan fitur baru, ...? Dan aplikasi ini sangat penting. Itu diperlukan. Tetapi magang telah meninggalkan perusahaan. Tidak ada yang tahu cara kerjanya. Anda hanya memiliki banyak sumber dan semacam dokumentasi.

Apakah masuk akal untuk mencoba dan mengendalikan atau melarang pengembangan aplikasi yang dilakukan secara ad-hoc di luar departemen TI (dengan pengecualian hal-hal kecil seperti makro Excel)?


3
Akan tergantung pada lingkungan. Anda dapat mengatur OS tempat kerja dengan cara yang hanya admin dapat menginstal perangkat lunak baru, Anda dapat melarang akses ke sumber daya yang relevan di server (database, sistem file) yang harus diakses oleh perangkat lunak ini. Anda dapat melakukan ini dengan cara teknis sehingga tidak mungkin, dapat menghindari memberikan kata sandi, alamat IP, dan informasi serupa yang diperlukan atau membuatnya menjadi politik perusahaan dan memecat semua orang yang gagal mematuhinya. Saya telah melihat kurang lebih semua ini.
thorsten müller

40
Tetapi jika "program tersembunyi" ini memang kritis, dan tidak dapat diimplementasikan oleh departemen TI yang sebenarnya, apa yang Anda dapatkan dengan melarangnya? Mereka sangat penting , jadi Anda tidak bisa tidak memilikinya. Mungkin merestrukturisasi departemen TI Anda? Atau memprioritaskan ulang? Tampaknya dapat dimengerti oleh saya bahwa orang-orang yang terampil menyelesaikan sesuatu di luar alur kerja normal, jika alur kerja itu tidak responsif ...
Andres F.

13
@ thorstenmüller Pada titik mana Anda akhirnya berakhir dengan program tersembunyi diimplementasikan sebagai Rumus Excel untuk urutan pemeliharaan yang lebih buruk daripada Excel VBA. Karena membuat lembar kerja Excel adalah kemampuan yang dibutuhkan oleh banyak pekerja kantor, Anda tidak dapat menutupinya seperti Anda dapat menggunakan platform pengembangan yang lebih cocok.
Dan Neely

5
@ thorstenmüller Maksud saya adalah bahwa apa pun yang Anda coba dan lakukan, ketika pilihannya melewati saluran, tunggu beberapa hari (jika bukan berbulan-bulan karena burrocrazy), habiskan beberapa jam untuk melakukannya secara manual, atau lakukan penyelesaian masalah dengan kebijakan yang dilakukan orang-orang. untuk melakukan yang terakhir. Dengan asumsi Anda dapat menghentikannya adalah delusi. Yang terbaik yang bisa Anda harapkan adalah memiliki proses yang efektif untuk menemukan dan mengadopsi alat-alat ini setelah fakta.
Dan Neely

16
Apa yang salah dengan 'orang biasa' yang mengotomatiskan proses bisnis mereka? Selama itu benar-benar menghemat waktu mereka, yang mungkin benar, saya menganggapnya hal yang baik . Jika alat otomatisasi khusus 'berantakan' 'ad-hoc' menjadi sangat tergantung, mungkin layak jika pengembang menulis versi yang dapat dipertahankan. Skenario kasus terburuk mereka harus mulai melakukan hal-hal secara manual lagi ketika persyaratan berubah, tetapi setidaknya mereka sudah menghemat banyak waktu!
Philip

Jawaban:


79

Saya dulu bekerja di perusahaan tempat setiap aplikasi yang kami berikan memunculkan pertanyaan: Bisakah kita mengekspor data ini ke Excel?

Setelah beberapa saat, saya memutuskan untuk mengetahui mengapa mereka terobsesi dengan ekspor Excel untuk semuanya. Ternyata banyak departemen memiliki satu orang yang ahli dalam Excel dan dapat menulis aplikasi analisis data yang berguna dalam waktu singkat. Aplikasi ini akan menyebar di seluruh departemen seperti api dan kami, para teknisi, tidak tahu mereka bahkan ada.

Mengapa mereka tidak datang lebih dulu kepada kita? Karena ada reputasi yang terlalu banyak dilakukan oleh tim teknis dan, jika mereka memintanya, mereka mungkin (jika beruntung) mendapatkannya dalam antrian enam bulan kemudian.

Itu bukan tuduhan yang tidak adil dan mereka tidak pernah meminta kami untuk mendukung aplikasi Excel mereka, jadi tidak ada yang benar-benar berpikir itu masalah. Ketika para pengembang Excel ini pergi, mereka selalu berhasil menemukan orang lain untuk mengambilnya.

Anda dapat berargumen bahwa itu berarti kami memprioritaskan secara tidak benar, bahwa pekerjaan penting tidak selesai. Tetapi saya berpendapat bahwa ini membebaskan pengembang yang dibayar lebih tinggi untuk melakukan pekerjaan yang lebih sulit. Apa yang bisa menyakitkan?

Sekarang saya akan melarang perangkat lunak yang memperbarui basis data yang ditulis di luar tim pengembangan. Dan saya akan menolak untuk mendukung aplikasi yang ditulis di luar tim pengembangan. Tetapi saya tidak akan mencoba untuk melarang semua perangkat lunak dari yang ditulis oleh bisnis itu sendiri, dan saya akan dengan senang hati menulis data-ekspor untuk memberdayakan mereka untuk melakukannya (selama itu tidak memaparkan data yang tidak seharusnya mereka lihat, jelas ).


36
Saya telah bekerja di lingkungan yang sama, dan reaksi departemen kami terhadap 'aplikasi' ini selalu membuat frustrasi. Banyak perguruan tinggi saya di departemen TI merasa terancam oleh aplikasi ini karena beberapa alasan, tetapi saya melihatnya sangat bagus. Itu memungkinkan pengguna departemen untuk menyempurnakan apa yang sebenarnya mereka BUTUHKAN, dan ketika database Access tunggal itu tidak bekerja untuk mereka, mereka bisa menyerahkannya kepada kami dan kami akan membangun solusi SQL 'nyata' untuk mendukung fungsi yang sama. Saya akan membunuh untuk proyek seperti itu lagi. Semua persyaratan diketahui pada hari pertama ketika kami mulai.
Graham

8
+1 Dinyatakan dengan baik. Memberdayakan para pengguna perangkat lunak kami harus menjadi salah satu prioritas tertinggi kami.
Steven Evers

Saya harus setuju sebagian besar dengan jawaban Anda. Tetapi intinya adalah bahwa permintaan yang ditulis dengan buruk dapat menurunkan server database; bahkan jika ditulis dalam Excel atau Access. Setelah harus menyeimbangkan komitmen SLA TI dengan kebutuhan bisnis.
Steve

@Stephen: Ya. Dan itu sebabnya lebih baik memberdayakan pengguna untuk melakukan hal mereka sendiri, daripada membiarkan mereka pada data produksi. Apakah itu hanya baca, salinan data harian, atau ekspor Excel, atau DSL, sangat tergantung pada kebutuhan keamanan / SLA Anda dan persyaratan data mereka.
pdr

1
@ mattnz: Saya akan sangat merekomendasikan itu. Ini memberi orang cara untuk membuat tim teknisi memprioritaskan masalah mereka selama sisa bisnis, hanya dengan mengetuk sesuatu bersama dan berkata, "Bisakah Anda melihat mengapa ini tidak berhasil?" Pernahkah Anda mengenal pengembang yang bisa menolak tantangan seperti itu?
pdr

50

Saya pikir orang tidak mengerti poin umum di sini:

Jika Anda tidak menyukai semua pengembangan kustom yang terjadi, melarang itu menyelesaikan masalah yang salah - Anda seharusnya bertanya mengapa mereka menggunakan IT, bukan hanya memberi tahu mereka bahwa itu tidak diizinkan. Ingat bahwa Anda (TI) ada untuk membantu mereka melakukan pekerjaan mereka dengan lebih baik, dan bahwa orang tidak menggunakan perangkat lunak karena itu keren atau rapi atau baru, mereka menggunakannya karena itu memecahkan masalah yang mereka miliki.

Mengapa aplikasi ini dibuat di tempat pertama?

Dalam semua kasus yang saya lihat, ada alasan umum:

Kelompok bisnis memprioritaskan kebutuhan mereka sendiri lebih tinggi daripada kebutuhan yang sama diprioritaskan dalam konteks keseluruhan perusahaan

Pemasaran hanya bertanggung jawab untuk pemasaran, sehingga inisiatif yang menguntungkan tujuan mereka tampak penting bagi mereka, sementara dianggap tidak baik bagi kelompok lain, dan cenderung diprioritaskan lebih rendah ketika menyangkut sumber daya terbatas seperti IT. Prioritas hanya berperan ketika mereka ingin menggunakan sumber daya bersama - jika mereka menyimpan proyek sepenuhnya di dalam departemen mereka sendiri, maka hanya kepala departemen yang harus peduli dengan anggaran dan jadwal waktu.

Tidak ada alasan saya akan melarang pengembangan semacam ini, karena alasan - itu memudahkan pembatasan pada sumber daya bersama (terutama IT), dan memungkinkan setiap kelompok untuk memberdayakan diri mereka sendiri untuk menyelesaikan masalah mereka sendiri (seperti orang yang mahir dalam Excel canggih sangat umum, karena ini adalah masalah umum, sebagian besar departemen memiliki setidaknya satu).

Namun, Anda tidak dapat diharapkan untuk menyelesaikan masalah yang muncul dari aplikasi ini, atau mendukungnya setelah pengembang asli meninggalkan perusahaan. Seperti yang diposting oleh orang lain, ini tidak menghentikan bos besar untuk menuntut agar Anda mendukungnya, tetapi jika Anda terus merasakan jenis-jenis aplikasi atau proses khusus di luar sana, Anda bisa merasakan ketika sesuatu menjadi kritis dan Anda mungkin perlu terlibat untuk membawanya "di rumah." Juga, jika sesuatu terhubung dan memodifikasi sistem yang berada di bawah kendali TI, maka TI harus dilibatkan, jika hanya untuk memastikan keamanan dan integritas sistem pusat mereka - namun, jika sesuatu itu terbatas pada desktop pengguna, mengapa merasa perlu untuk melarangnya?

Tetapi ada sesuatu yang perlu diingat: Setiap aplikasi khusus yang dikembangkan di luar TI sesuai dengan kebutuhan yang tidak terpenuhi oleh TI . Mungkin ada alasan bagus mengapa mereka tidak bertemu - bukan prioritas di perusahaan, masalah yang sangat terspesialisasi, tidak sebagus pilihan lain, bahasa khusus yang tidak diketahui oleh orang-orang TI Anda, dll - dan kurangnya keterlibatan TI mungkin sah, tetapi solusi ini dibuat karena beberapa departemen memiliki kebutuhan yang tidak dapat (atau tidak akan) dipenuhi oleh TI.

Cobalah untuk membantu mereka memecahkan masalah mereka, dan jika Anda tidak punya waktu atau sumber daya, biarkan mereka menyelesaikannya sendiri. Mengamanatkan beberapa bahasa yang memiliki kurva belajar yang curam, dengan tujuan tunggal menjauhkan orang dari bisnis Anda, hanya berfungsi untuk meningkatkan sikap elitis yang dimiliki sebagian besar pengguna bisnis terhadap TI, dan pada akhirnya, sikap elit semacam itu hanya mengarah pada lebih dari masalah yang sama, karena pengguna takut untuk mendekati IT dan yakin bahwa IT tidak memahami kebutuhan atau keinginan mereka. Buka hubungan - pahami apa yang mereka butuhkan adalah satu-satunya cara agar mereka tidak berada di sekitar Anda.


2
Tempat +1 di. Saya tidak melihat seorang pun di sini menyebutkan apa yang cenderung menjadi masalah besar dengan praktik-praktik ini yang saya lihat di banyak perusahaan. Apa yang berfungsi untuk satu atau dua orang dalam jangka pendek, dengan cepat berubah menjadi kekacauan perangkat lunak yang sangat besar, yang terdiri dari 30 aplikasi kecil yang telah tumbuh selama bertahun-tahun, beberapa di antaranya berfungsi dan mempertahankannya sepuluh kali lipat dari biaya jika departemen TI mempekerjakan orang untuk lakukan semuanya agar mereka konsisten dan memiliki basis kepemilikan pusat TI.
Jimmy Hoffa

4
Sebagai orang yang bekerja sebagai programmer "ops hitam", saya dapat memberi tahu Anda bahwa seringkali TI tidak memiliki keahlian untuk memahami kebutuhan departemen teknis tertentu. Beberapa program kami yang paling kritis dan inovatif dimulai sebagai program "operasi hitam". TI bukan tempat di mana inovasi dihargai, inovasi dan eksperimen sering berarti banyak proyek gagal untuk masing-masing yang sukses. Setelah program "operasi hitam" diadopsi dengan baik, biasanya program tersebut dialihkan ke IT untuk dipelihara.
Bill

+1 Pikiranku persis, tapi kata-katanya jauh lebih baik.
Phil

16

Satu juga harus mempertimbangkan kasus perusahaan di mana departemen TI berisi orang-orang tidak kompeten, sementara aplikasi tersembunyi akan dibuat oleh pengembang yang terampil yang memiliki pekerjaan non-pengembang dalam perusahaan. Dalam pengalaman saya, kasus-kasus itu sangat sering terjadi.

Bayangkan Anda memiliki profil ganda pengembang perangkat lunak dan seorang akuntan. Anda dipekerjakan sebagai seorang akuntan karena ini adalah kesempatan bagi Anda untuk mendapatkan pekerjaan yang dibayar dengan baik. Anda dengan cepat melihat bahwa kolega Anda (dan sekarang Anda) menghabiskan berjam-jam melakukan hal-hal yang berulang yang dapat dilakukan dalam beberapa detik oleh suatu program.

Anda menghabiskan beberapa malam untuk menulis aplikasi yang akan melakukan semua pekerjaan. Anda menunjukkannya di laptop pribadi Anda kepada kolega Anda, dan mereka merasa sangat berguna. Anda ingin menginstalnya ke PC perusahaan, tetapi Anda harus memiliki persetujuan departemen TI. Anda memintanya, tetapi mereka menolaknya karena mereka tidak akan mendukung aplikasi Anda.

Bukankah itu terdengar bodoh?

Selain kasus khusus ini, masalah dengan dukungan tidak jauh berbeda dari satu pertemuan banyak perusahaan dengan semua  perangkat lunak, bahkan satu ditulis dalam departemen TI: jika departemen TI tidak menegakkan praktik terbaik, kode akan buruk / tidak didokumentasikan, ditulis oleh orang yang tidak berpengalaman yang tidak peduli dengan pemeliharaan dan yang telah pergi bertahun-tahun yang lalu.

Untuk menyimpulkan, pertanyaan utama adalah profitabilitas . Jika Anda, departemen TI, diminta untuk memelihara aplikasi yang dikembangkan oleh petugas yang tidak memahami aturan paling dasar pengembangan perangkat lunak, tidak masalah seberapa menyenangkan tugas ini, Anda masih harus melakukannya jika membawa banyak uang untuk perusahaan . Atau Anda menulis ulang dari awal jika itu adalah cara termurah untuk menyelesaikan sesuatu.


2
"Dalam pengalaman saya, kasus-kasus itu sangat sering terjadi." - Jadi perusahaan Anda melakukan pekerjaan luar biasa dengan merekrut programmer hebat dalam pekerjaan non programmer dan kemudian programmer miskin dalam pekerjaan pemrograman? Saya pikir itu lebih mungkin bahwa seseorang yang tidak memahami praktik dan sistem yang mendasari akan BERPIKIR mereka menulis perangkat lunak yang lebih baik. Hanya 2 sen saya.
Ominus

2
@Minus: jika ada lowongan untuk pengacara, perusahaan akan mencari pengacara; jika kandidat juga merupakan pengembang yang terampil, pewawancara mungkin bahkan tidak mengetahuinya. Jadi tidak, perusahaan ini tidak "merekrut pemrogram hebat dalam pekerjaan yang bukan pemrogram": mereka merekrut orang yang memenuhi syarat untuk suatu pekerjaan, tanpa secara khusus menyadari bahwa orang ini juga merupakan pengembang yang hebat.
Arseni Mourzenko

@Ominus: perhatikan bahwa ketika Anda direkrut sebagai, misalnya, seorang pegawai, Anda tidak memberi tahu selama wawancara bahwa Anda adalah programmer yang hebat. Untuk banyak orang tanpa latar belakang teknis, programmer = hacker = dude yang akan menghabiskan waktunya untuk memecahkan PC perusahaan = banyak masalah.
Arseni Mourzenko

1
@Minus - Perusahaan tidak harus buruk dalam mempekerjakan orang TI untuk memiliki departemen TI yang tidak kompeten. Departemen IT yang buruk dapat terjadi karena TI dianggap 'overhead' oleh seseorang dan dikurangi sejauh mungkin. Ini membentang mereka di luar kemampuan aktual mereka dan mereka menjadi tidak kompeten sebagai organisasi - terus-menerus beralih di antara tugas, mode panik konstan, tidak berkomunikasi dengan siapa pun, tidak memenuhi janji.
Michael Kohne

2
@Minus: Apa yang lebih mungkin di sini adalah bahwa perusahaan melakukan pekerjaan yang sama-sama baik dalam merekrut kedua jenis peran, tetapi kemudian kelompok IT dibebani dengan beurokrasi, prioritas yang saling bertentangan, dan sistem PM yang tidak melakukan pekerjaan dengan baik, mencekik inovasi daripada memupuknya. Para teknisi di pekerjaan non-IT, begitu keterampilan mereka diperhatikan, diizinkan untuk benar-benar fokus pada suatu tugas, karena hanya kepala departemen mereka yang mengendalikan waktu mereka. Orang-orang yang melakukan pekerjaan yang sebenarnya memiliki dukungan otomatis pada inovasi, sedangkan kelompok TI tidak memiliki perspektif yang sama tentang kebutuhan.
SqlRyan

6

Anda tidak dapat sepenuhnya mengendalikannya ...

Saya akan mengatakan Anda tidak pernah dapat sepenuhnya mengendalikannya, karena karyawan akan selalu memiliki cara untuk menghasilkan kode jahat dan menyebarkannya dengan cara alternatif. Jadi tidak banyak gunanya terobsesi dengan hal itu, setelah Anda membuat konsep dan menegakkan beberapa aturan dan proses dasar, dan menyiapkan beberapa alat.

Idenya adalah agar Anda membuatnya semenarik mungkin bagi orang-orang untuk menghormati aturan-aturan ini dan menggunakan alat-alat ini, daripada membuatnya sangat mustahil untuk melakukan hal-hal baru sehingga mereka tidak menghasilkan apa-apa.

Tetapi Anda dapat membuat lingkungan yang ramah kode

Banyak perusahaan, seringkali sangat besar, melakukan ini. Contoh yang baik adalah Google, yang oleh perwakilannya dikatakan mereka menggunakan SCM tunggal untuk seluruh perusahaan, agar setiap orang dapat memantau dan melihat kode orang lain.

Saya sarankan Anda melakukan hal berikut:

  • memberikan akses publik ke beberapa area SCM Anda,
  • membuatnya mudah untuk meminta akses ke integrasi berkelanjutan dan server inspeksi berkelanjutan,
  • mendorong orang untuk menciptakan pekerjaan bangunan untuk alat mereka.

Masalahnya kemudian adalah proliferasi teknologi. Jelas, beberapa akan lebih suka menggunakan X lebih dari Y dan saat itulah semakin sulit untuk memasangnya dalam arsitektur Anda. Namun, itu bukan tidak mungkin, dan jika mereka ingin kode mereka dipelihara mereka mungkin akan mendapatkan tambahan jika, yah, itu hanya satu mil.

Anda juga bisa mengambil sikap yang lebih sewenang-wenang dan memutuskan bahwa hanya bahasa L dan Stack S yang diizinkan, tetapi kemudian Anda akan mendapatkan beberapa barang nakal di sana-sini, jadi saya sarankan untuk sedikit memperluasnya. Beberapa sistem CI akan melakukan keajaiban dengan beberapa plugin, jika karyawan Anda bersedia untuk menulis sedikit kode lem atau beberapa skrip konfigurasi untuk membuatnya cocok.

Berikan kebebasan pada tim

Sangat penting untuk memberikan kebebasan pada tim untuk melakukan kehendak dan memulai beberapa proyek kecil baru dengan hal-hal eksperimental. Itu membuat mereka tetap di ujung jari mereka, dan Anda serta memaksa Anda untuk mempertimbangkan teknologi ini daripada tetap terjebak dalam tumpukan selamanya sampai menyebabkan masalah bagi Anda.

Jadi pastikan mereka memiliki kemampuan untuk menginstal sistem mereka sendiri untuk menguji proyek kesayangan mereka. Tapi, pastikan mereka membiasakan diri berbicara dengan IT tentang hal itu.

Bicaralah dengan IT, libatkan mereka

Jauh lebih baik jika karyawan Anda mengembangkan refleks memotret permintaan email ke TI dan bertanya apakah mereka dapat mengatur sesuatu untuk mereka dan mengakomodasi. Mereka akan ditolak sebagian besar waktu, tetapi setidaknya ada beberapa gagasan kontrol dan siapa yang harus bertanggung jawab dan memberikan TI beberapa visibilitas pada tuntutan dari tim yang berbeda.

Setelah proyek mengambil massa yang lebih kritis, Anda dapat meminta lagi dan mereka akan mempertimbangkan kembali. Komunikasi adalah kunci, dan Anda perlu memiliki tim pengembang, konsultan, staf dukungan TI atau siapa pun yang berurusan dengan kode untuk bekerja bersama. Tidak ada dari mereka yang menginginkan program yang menyimpang, jadi ini demi kepentingan semua orang. Jauh lebih mudah untuk menegakkan aturan jika mereka mendukungnya sendiri.


3

Anda tidak dapat menghentikan aplikasi "tersembunyi" ini karena orang membuatnya untuk menyelesaikan masalah bisnis dunia nyata. Yang dapat Anda lakukan adalah membantu mereka melakukannya dengan cara yang "benar". Dan dengan "benar" maksud saya membuatnya agar aplikasi dapat dipertahankan setelah orang yang memulainya telah pergi. Saya sarankan menggunakan bahasa yang disarankan di Atas atau Di Luar : Saya ingin Anda mendokumentasikan proses ini secara terperinci sehingga setiap yahoo dapat memahaminya setahun dari sekarang setelah Anda pergi. Bantuan untuk mengatur kontrol versi (dan menunjukkan kepada mereka cara menggunakannya), wiki (untuk membuat catatan informal tentang bagaimana pekerjaan benar-benar dilakukan) dan sistem pelacakan bug sederhana. Jika Anda ingin membuat segalanya benar-benar licin, atur integrasi terus-menerus pada server cadangan (jika Anda memilikinya).

Anda akan melihat keinginan besar untuk integrasi Excel (atau setidaknya impor / ekspor) karena semua sekolah bisnis sekarang mengajarkan Excel dan itu adalah alat utama yang digunakan dalam banyak kursus bisnis.


3

Sarbanes-Oxley dan undang-undang serupa di luar AS, dikombinasikan dengan undang-undang privasi dan privasi serta proses keamanan yang diberlakukan secara internal dan kebijakan adalah "palu" yang dapat dan sering digunakan untuk menekan fenomena bayangan-IT.

Segera setelah pelanggan atau karyawan mengidentifikasi informasi pribadi (atau data apa pun yang tidak ingin Anda keluarkan) mulai beredar di spreadsheet ini, Anda mengalami kecelakaan yang menunggu untuk terjadi.

Demikian pula, segera setelah salah satu dari proyek skunkwork ini mengambil spreadsheet Excel dan menggunakannya sebagai data di balik aplikasi web yang menghadap ke luar yang diretas, Anda akan meminta CIO dan CEO Anda menyerbu ke kantor siapa pun yang membangun aplikasi itu di akhir pekan datang untuk menjelaskan konsekuensinya.

Dan kemudian ada masalah ketika Anda melihat upaya ini dikalikan ratusan (atau ribuan) departemen di perusahaan Fortune 500, Anda segera menemukan bahwa perusahaan Anda memiliki lebih dari 100 database "master" pelanggan. Pelanggan Anda mulai mengeluh bahwa mereka memperbarui informasi kontak mereka di satu tempat tetapi masih ketinggalan zaman di 10 tempat lain, atau bahwa Anda bahkan tidak tahu berapa banyak bisnis yang Anda lakukan dengan mitra besar Anda karena informasi tersebut tersebar di 10 bayangan Database IT.

Semua ini menimbulkan kepatuhan yang berat dan proses audit yang tidak menyenangkan bagi siapa pun, tetapi merupakan fakta sulit kehidupan TI di lingkungan perusahaan.

Strategi yang baik adalah dengan melihat seluruh departemen yang melakukan ini dan membuat kasus untuk memindahkan investasi mereka dalam bayangan IT menjadi IT yang tepat, membuat argumen bahwa TI dapat mencapai skala ekonomi dan melakukan pekerjaan ini lebih efisien daripada saat ini Model skunkwork terdistribusi ad-hoc. Ini bisa menjadi penjualan berat di lingkungan di mana kendala anggaran TI dan kecepatan pengiriman memunculkan skunkworks di tempat pertama, tetapi dikombinasikan dengan audit / risiko fiduciary dapat membuat pukulan satu-dua yang baik.


2

Keputusan untuk menulis aplikasi baru seringkali didasarkan pada analisis manfaat biaya dari permintaan tersebut; serta nilai keseluruhan untuk bisnis. Semua sambil mempertimbangkan banyak driver lain seperti sumber daya TI yang tersedia, ruang lingkup permintaan, tujuan bisnis dan arahan hanya untuk beberapa nama. Sering kali permintaan departemen tertentu ditolak karena manajer / direktur departemen gagal menunjukkan ROI yang wajar atau tidak mengikuti proses yang telah ditetapkan.

Terlepas dari alasannya, 'Departemen TI' sering menjadi kambing hitam, bahkan jika keputusan itu di luar kendali mereka. Jadi meskipun penolakan permintaan mungkin tidak mencerminkan buruk pada departemen TI persepsi sering sama sekali berbeda.

Meskipun demikian, Anda akan menemukan aplikasi jahat di hampir setiap organisasi bisnis di dunia. Beberapa ditulis dengan baik dan yang lain dengan baik, berisi kode yang seharusnya tidak pernah melihat cahaya hari.

Meskipun kita harus melakukan segala yang dapat kita lakukan untuk memenuhi kebutuhan pelanggan internal kita, ada saat-saat yang tidak bisa kita lakukan. Ketika itu terjadi, mereka akan mencari di tempat lain untuk mengatasi masalah mereka.

Jika grup TI terlibat aktif dalam proyek ini maka kami dapat menuntut kepatuhan terhadap standar kami, membantu konsultan untuk mengikuti pedoman pengkodean internal, dan memahami interaksi aplikasi dengan dan permintaan pada sistem kami (database, jaringan, firewall, ...). Tanpa keterlibatan itu kita akan ketahuan dan menghabiskan banyak waktu untuk mencari tahu mengapa sistem produksi kita tidak memenuhi SLA.

Apakah departemen TI memaafkan dan mendukung mereka atau tidak, mereka dapat, dan akan, memiliki dampak langsung dalam hal dukungan, komitmen OLA dan SLA yang diukur oleh departemen TI mana pun.


1

Mereka dilarang di perusahaan kami karena alasan ini:

  • Macro Excel yang dilindungi kata sandi tempat satu-satunya orang yang tahu kata sandi telah meninggalkan perusahaan,
  • Dianggap bertanggung jawab atas laporan yang salah yang ditulis oleh orang yang tidak berpengalaman karena itu
  • Diminta mengubah laporan yang belum pernah kita lihat atau dengar sebelumnya.

Saya mengerti ini bisa membuat frustasi bagi pengguna ketika TI sedang sibuk, dan mereka mungkin cenderung 'lakukan saja sendiri'. Tetapi TI tidak dapat dianggap bertanggung jawab atas hal-hal yang bahkan tidak diketahui keberadaannya, dan jika tidak ada yang bertanggung jawab atas keseluruhan TI, maka ada masalah besar di depan.


5
Dari apa yang saya pahami, TI ada untuk mendukung bisnis; bukankah tujuan di balik memiliki departemen TI untuk membantu orang melakukan pekerjaan mereka? Bagaimana mereka bisa melakukan pekerjaan mereka dengan baik jika Anda melarang mereka membuat alat yang mereka butuhkan? Tidak ada yang salah dengan mengatakan, "Jangan menganggap kami bertanggung jawab atas laporan yang salah itu - seseorang dalam penjualan menciptakan itu."
Phil

@ Phil - Setuju. TI ada di sana untuk membantu menjalankan bisnis, bukan untuk melayani fungsi apa pun sendiri - TI tidak akan ada jika tidak memungkinkan bisnis untuk melakukan pekerjaan mereka dengan lebih baik, dan semua yang dilakukan IT harus dilihat melalui lensa tentang bagaimana bisnis bekerja lebih baik karena usaha mereka. Setiap proses yang dibuat di luar TI sesuai dengan kebutuhan yang tidak dipenuhi oleh TI, dan melarang mereka lebih merasa tidak aman. Anda tidak dapat diharapkan untuk mendukung proses yang tidak Anda kembangkan, dan saya akan teguh, tetapi menolak untuk mengakui bahwa solusi "nakal" ini sesuai dengan kebutuhan nyata hanya keras kepala.
SqlRyan

1
Saya harus menambahkan bahwa langkah-langkah telah diambil untuk memperluas departemen TI untuk memenuhi kebutuhan ini.
Paul T Davies

Walaupun TI mendukung bisnis, seringkali bisnis tidak mendukung TI. Bisnis seringkali tidak memperhitungkan waktu yang dibutuhkan TI untuk mengambil alih atau memberi saran tentang spreadsheet atau aplikasi yang dikembangkan oleh pengguna akhir yang kompleks. Efek bersihnya adalah departemen TI yang kekurangan staf. Dan kita semua tahu cara kerjanya.
Mike Sherrill 'Cat Recall'

1

Jika ada masalah di sini, itu adalah departemen TI.

Tidak ada yang salah dengan mengizinkan orang dengan pengetahuan bisnis / domain khusus memanipulasi dan memproses data mereka sendiri.

Departemen TI perlu mengakui ini dan mendukungnya. Dengan menyediakan antarmuka yang dapat digunakan kembali, mengirimkan data dalam format yang nyaman seperti EXCEL atau Access DBs, dan menyediakan perkakas yang fleksibel (COGNOS, Laporan Jasper, dll.).

Departemen TI juga perlu memikirkan kembali prioritasnya - ada di sana untuk melayani bisnis, bukan untuk mengimplementasikan metodologi terbaru, atau, memasang perangkat keras paling seksi.


1

Yang membuat frustrasi banyak perusahaan, atau departemen dalam perusahaan, adalah departemen TI mereka menghalangi dan menyulitkan mereka untuk menyelesaikan pekerjaan atau melakukan hal-hal baru. Ini mengarahkan departemen, yang merasa seolah-olah mereka ditahan oleh kebijakan TI, untuk mencoba menyelesaikan masalah mereka sendiri. Komunikasi adalah kuncinya. Jika departemen bekerja di sekitar TI, apa yang Anda miliki sebenarnya adalah masalah TI. ITU tidak mampu dipandang sebagai musuh. Perusahaan, dan khususnya departemen TI, perlu menyadari bahwa mereka perlu bekerja sama, bukan saling bertentangan. Jika departemen berkomunikasi dengan staf TI mereka (terutama yang harus memiliki pengawasan) dan memberi tahu mereka kebutuhan mereka dan bagaimana mereka bekerja untuk menyelesaikan masalah mereka sendiri, TI setidaknya akan memiliki pilihan untuk membantu menyelesaikan masalah daripada mencari tahu setelah fakta ketika krisis terjadi. Pertahankan TI dalam lingkaran.


1

Hampir tidak ada aways adalah kebutuhan yang valid untuk alat khusus ini, baik itu aplikasi atau spreadsheet. Departemen TI memiliki dua pilihan. Mereka bisa menjadi enabler atau disabler. Dalam pengalaman saya, para disabler kehilangan karena mereka menghalangi kebutuhan bisnis yang valid dan menjadi musuh bersama. Pengaktif di sisi lain benar-benar membantu bisnis.

Ini tidak berarti bahwa pengembangan yang didanai departemen harus diberikan pemerintahan gratis. Beberapa persyaratan harus ditegakkan, seperti yang berikut:

  • Semua kode harus secara teratur berkomitmen pada sistem kontrol versi yang dijalankan oleh TI. TI harus secara bebas membuat akun dan direktori untuk memungkinkan hal ini. Bahkan mungkin ingin memberikan beberapa instruksi.
  • Apa pun yang melibatkan PII (Informasi Identifikasi Pribadi), otentikasi, otorisasi, kriptografi, data yang dilindungi oleh undang-undang, atau data yang dianggap penting oleh bisnis harus melibatkan dan disetujui oleh konsultan dari IT. IT / konsultan harus memberikan bantuan, perpustakaan, dll untuk melindungi bisnis dengan benar sambil memungkinkan pengembangan aplikasi.
  • Basis data primer harus dilindungi. Tergantung pada databasenya, akses baca harus relatif mudah untuk mendapatkan dan menulis akses lebih sulit. TI mungkin perlu menyediakan akun, masuk, atau mengaudit.

Mengaktifkan memiliki banyak manfaat.

  • TI belajar lebih banyak tentang memenuhi kebutuhan klien mereka. Ini mengarah pada prioritas dan pembagian yang lebih baik.
  • TI dilihat sebagai teman dan manfaat, bukan masalah.
  • Kebutuhan bisnis nyata terpenuhi.
  • Data bisnis dilindungi secara memadai karena TI terlibat, mencegah perlunya pintu belakang.
  • Alat deparment tidak hilang karena pergantian dan dapat lebih mudah dipindahkan ke IT, jika diperlukan.

0

Saya tidak bisa membantu tetapi mengidentifikasi dengan Anda. Masalah yang Anda gambarkan tampaknya bersifat universal, yang mencakup budaya, bahasa, dan benua.

Hal-hal yang dapat Anda lakukan:

  • Batasi pembuatan akun basis data , minta persetujuan penyelia. Memaksa mereka menggunakan mesin lokal sebagai server basis data atau menulis aplikasi agar berdiri sendiri, sangat mengurangi kegunaannya.

  • Jadikan semua pekerja magang yang terkait dengan TI untuk dikontrak melalui TI saja.

  • Membatasi melalui kebijakan OS, instalasi perangkat lunak . Setiap instalasi perangkat lunak harus disalurkan melalui meja bantuan TI, yang membutuhkan persetujuan penyelia. Dengan begitu pemasangan sesuatu seperti MS Access, PHP, Visual Basic, dll., Akan lebih sulit untuk dilewati tanpa diketahui.

  • Keluarkan kebijakan yang menyatakan bahwa setiap pengembangan baru, untuk mendapat dukungan, harus ditulis dalam, katakanlah Java, C #, C ++ , atau bahasa lain apa pun yang membutuhkan kurva belajar yang curam . Dengan begitu Anda mengurangi dunia orang-orang dengan "pengetahuan pemrograman tertentu" untuk dipusingkan.

  • The persyaratan orang harus melihat di "solusi Excel" di sekitar perusahaan, karena itu adalah mencerminkan kebutuhan IT perusahaan.

  • Menerapkan gudang data dan alat penambangan dan pelaporan data yang ramah pengguna akhir . Dengan begitu Anda mengurangi kebutuhan untuk aplikasi kecil yang dibuat khusus dan magang.

Tetapi: tidak ada satu hal pun yang Anda lakukan yang akan mengalahkan panggilan telepon dari Ketua Besar , memanggil Manajer TI dan memintanya untuk mendukung aplikasi yang dibuat oleh pekerja magang.


tentang poin 1, aplikasi yang berdiri sendiri dapat sangat membantu dalam memproses data bahkan tanpa DB, tentang poin 4 kurva pembelajaran yang curam tidak pernah menghentikan seseorang dari menulis hal-hal ketika mereka berada di dasar itu yang hasilnya akan lebih buruk untuk mendukung, atau bahkan soemone mengatakan "meh saya tidak perlu aplikasi ini didukung"
ratchet freak

Poin 3 tentang Pembatasan OS tidak berfungsi. Banyak perusahaan sudah pindah ke model "bawa laptop Anda sendiri".
Sulthan

5
Saya setuju dengan poin 4 (perlu diketahui bahwa alat kustom mungkin mencerminkan kurangnya respons dari TI), tetapi tidak dengan yang lain. Langkah-langkah berorientasi pembatasan berbau birokrasi. Dalam pengalaman saya, hasil akhirnya adalah hal-hal yang tidak diselesaikan , dan jarang dalam IT terlibat secara efektif. Misalnya "tidak, Anda tidak dapat melakukan X. Tanyakan kepada manajer dan setujui." (hasil: X tidak pernah selesai; tingkat frustrasi meningkat)
Andres F.

0

Salah satu cara yang membantu perusahaan saya dalam situasi semacam ini adalah tidak menjadi agnostik bahasa. Jika Anda ingin aplikasi / program dipertimbangkan, maka itu harus dalam bahasa pilihan kami (java). Kita mungkin meregangkan aturan sedikit untuk beberapa JQuery atau js tetapi itu harus menjadi aplikasi yang disusun dengan baik yang melayani kebutuhan kritis. Jangan datang dan katakan "Saya punya aplikasi PHP ini yang saya butuhkan untuk Anda host untuk saya" karena Anda mungkin hanya akan diberikan lembar kebijakan.

Sangat penting untuk menggigit hal-hal sebelum menjadi terlalu besar, karena sekali mereka Anda lebih baik memiliki seseorang yang dapat Anda dedikasikan untuk mempelajarinya, atau menulis ulang itu. Karena begitu wig besar di lantai atas itu memutuskan ia menyukainya, mungkin Anda tidak akan pernah menghilangkannya dalam pengalaman saya.


0

Arogansi Geeks!

Dalam banyak kasus, pengguna bisnis dapat menggunakan alat untuk melakukan hal-hal yang tidak dipahami oleh orang-orang TI. Ini bukan karena mereka secara inheren buruk tetapi karena mereka tahu bisnis, cara kerjanya, dan bagaimana mereka ingin itu bekerja.

Misalnya perusahaan perangkat lunak mengembangkan aplikasi untuk mengoptimalkan akses (untuk biaya) ke umpan data pasar. Sebagai renungan mereka menyediakan plugin Excel sehingga pengguna dapat mengakses harga saham terbaru melalui spreadsheet. Maju cepat satu tahun dan hampir setiap pedagang di perusahaan tempat saya bekerja memiliki satu atau lebih spreadsheet yang sangat rumit untuk mendukung strategi perdagangan mereka. Kadang-kadang mereka akan memiliki masalah dengan makro dan meminta salah satu dari orang-orang TI untuk bantuan, sebagian besar menolak (dan mereka bertanya-tanya mengapa bisnis membenci kita!). Namun saya sudah mencoba dan sementara saya bisa memperbaiki masalah teknis dengan berbagai parameter fungsi dan referensi melingkar saya bisa jujur ​​mengatakan saya tidak memiliki petunjuk sedikit pun apa yang sebenarnya dilakukan seluruh spreadsheet. Bukan karena mereka disatukan atau diprogram dengan buruk, tetapi karena saya tidak memiliki pengetahuan atau pengalaman untuk menghargai kehalusan dari apa yang ingin dicapai oleh para pedagang. Lebih jauh lagi saya akan memperkirakan 5 tahun manusia ditambah proyek TI untuk mereplikasi fungsi dari salah satu spreadsheet ini dalam bahasa pemrograman yang "tepat" sebagai proyek TI standar.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.