Analis bisnis dan analis sistem di bidang TI. Mengurutkan nilai

Masalah


Beberapa teman saya, kolega, manajer, eycharov, perwakilan dari "bisnis" di kepala mereka membentuk kebingungan di antara jenis analis. Konsep "analis" digunakan untuk profesi yang sangat berbeda - analis bisnis (BA), analis sistem (SA), analis data, analis UX, analis keamanan informasi, analis proses bisnis, dan 5-10 lainnya, semuanya spesies ini memiliki banyak perbedaan. Sekarang tentang dua spesifik, yang paling membingungkan, tetapi sangat berbeda dalam realitas IT domestik.



Siapa yang akan mendapat manfaat dari artikel ini:
Untukbagaimana
Analis dan kolega— , , . — , , .

: xml- , -.
HR, , . «, ».

: java, .
Targetkan pemilihan dan distribusi sumber daya yang siap untuk melakukan kombinasi tanggung jawab pekerjaan tertentu, meningkatkan komunikasi dalam tim. 

Contoh: Untuk posisi yang membutuhkan komunikasi dan fleksibilitas maksimum, "teknisi" dipilih tanpa keinginan untuk mengembangkan keterampilan tersebut.

Secara umum, "Kebahagiaan untuk semua, untuk apa-apa"

Asumsi


Artikel ini berbicara lebih banyak tentang IT.

Nilai "suling" dari posting dipertimbangkan. Dalam kehidupan nyata, terutama dalam tim yang mengembangkan keterampilan berbentuk T (model pengembangan kompetensi karyawan dari profesi terkait), itu lebih rumit dan membingungkan, tetapi jika analis Anda bukan Janus yang banyak sisi, maka transisi antara tanggung jawab yang berbeda bukanlah tugas yang mudah.

Bagian utama


Berkomunikasi dengan BA dan CA dari perusahaan dan proyek dari berbagai ukuran, saya melihat perselisihan dalam konsep yang menciptakan kontroversi. Seperti yang biasanya terjadi, kurangnya terminologi yang diterima secara umum mengganggu distribusi tugas dan tanggung jawab dalam proyek antara mereka yang mampu memenuhi mereka dengan efisiensi terbesar. Untuk menarik sumber obyektif dalam perselisihan ini, saya memutuskan untuk mencari pendapat di internet.

Saya membagikan hasil pencarian saya.

Analisis bisnis dan analisis sistem dalam TI adalah serangkaian praktik, metode, dan tugas yang menyederhanakan pengembangan sistem informasi yang diperlukan untuk menyelesaikan tujuan bisnis organisasi. Kebingungan antara kedua konsep ini ada tidak hanya di lingkungan domestik, jadi:

https://en.wikipedia.org/wiki/Systems_analyst :

Seorang analis sistem biasanya terbatas pada sistem yang ditugaskan atau diberikan dan akan sering bekerja bersama dengan analis bisnis. Peran-peran ini, meskipun memiliki beberapa tumpang tindih, tidak sama.

Sebagai sumber yang dapat membangun "garis pemisah" antara SA dan BA, saya mencoba menggunakan kode pengetahuan BA, literatur profesional yang diterima secara umum, dokumen peraturan dan artikel tentang berbagai sumber daya. Saya tidak dapat menemukan divisi yang diartikulasikan dengan jelas. Dan itulah kenapa:

  • , , — , . « », ( ), . 
  • ( / . ., BABOK, ., PMI Guide to business analysis . .), . , - -, . , . . -, « , , , , . , , , , - ». . PMI IIBA «system analyst» , «business analyst» .
  • ( ) , . , — . — , , , . — , , , , , .

Dalam situasi ini, saya menawarkan visi saya, berdasarkan pengalaman bekerja di perusahaan IT Rusia baik dari pelanggan maupun dari kontraktor dalam pengembangan sistem informasi. Pendekatan ini telah membantu dalam pekerjaan penulis Alan Vongsavanh, yang mempelajari literatur dan hasil beberapa wawancara dan mengumpulkan daftar keterampilan dasar yang membentuk bagian terbesar dari kegiatan rutin BA dan CA (sebagian besar waktu kerja):


* Sumber-sumber asing menggunakan istilah yang lebih tepat "berfokus pada teknologi" dan "fokus pada bisnis".

Dimana:
Identifikasi persyaratanproses penentuan persyaratan dari berbagai sumber melalui wawancara, seminar, analisis tugas, alur kerja dan dokumen serta metode lainnya
Pengetahuan bisnis, , -
.
-
 ,
 
,
( )
pengetahuan tentang teknologi, pemrograman, pembuatan dan konfigurasi basis data dan aspek teknis lainnya, standar dan aturan untuk merancang solusi

Bersama-sama, tindakan ini memungkinkan Anda untuk membentuk siklus lengkap analisis persyaratan, membawanya dari pelanggan ke pengembang, dan setelah itu - membawa produk jadi dari tim pengembangan ke pelanggan. Interaksi seperti itu dengan mudah jatuh pada kerangka kerja, misalnya, seperti inilah tampilannya dalam V-Model, model air terjun, atau metodologi fleksibel:





Mengapa pemisahan seperti itu


Keterampilan yang dibutuhkan oleh BA dan CA serupa tingkat atas, tetapi iblis ada dalam rinciannya. Seorang analis sistem membutuhkan keterampilan teknis yang jauh lebih praktis untuk kegiatan penuh, ia jauh lebih dekat dengan sekelompok spesialis teknis dan harus lebih memahami bahasa mereka (tanpa ini sulit untuk mencapai rasa hormat dalam tim, yang berarti tidak mungkin untuk mengirimkan visi Anda). BA di IT lebih terkonfigurasi untuk berkomunikasi dengan bisnis, tugasnya adalah menentukan kebutuhan (rasa sakit), menemukan, merumuskan dan mengusulkan solusi untuk masalah pelanggan bisnis menggunakan sistem TI, dalam beberapa cara untuk "menjual" solusi ini. Kedekatan dan pemahaman pengguna membantu BA untuk memprioritaskan tugas-tugas dengan lebih efektif, mendeskripsikan persyaratan dan batasan non-fungsional dalam kasus tertentu.

Selain itu, BA memiliki persyaratan yang melekat untuk sistem, ia berpikir dalam tujuan bisnis dan tidak boleh dibatasi oleh kemampuan teknologi, yang tidak dapat diterima untuk CA. Terkadang persyaratan BA yang berlebihan seperti itu membantu menemukan solusi terobosan yang benar-benar.

Namun ada keterbatasan. Untuk BA, ini adalah ruang lingkup domain atau industri yang diteliti (misalnya: pengetahuan mendalam tentang aturan perbankan), untuk BA, ini adalah teknologi dan sistem (misalnya: pengalaman luar biasa dengan produk oracle). Pembatasan ini dapat menjadi hambatan dalam transisi antara tim, proyek dan perusahaan, tetapi dapat dengan cepat dihilangkan jika diinginkan dan dengan bantuan rekan kerja.

Hampir selalu, analis dalam tim memainkan kedua peran pada tingkat yang lebih besar atau lebih kecil (oleh karena itu, saya ingin menghindari perselisihan tentang penggabungan "dan kami memiliki BA juga ahli virus"). Dalam beberapa kasus, analis mungkin tidak diperlukan, dalam beberapa kasus, satu spesialis dapat sepenuhnya melakukan kedua peran. Ini tidak melanggar aturan, tetapi menunjukkan kombinasi peran, tingkat kematangan dan nilai spesialis tertentu. Dalam kasus karyawan berpengalaman, ini cukup normal, tetapi lowongan BA junior dengan pengetahuan tentang SQL, JS dan API di situs terkenal terlihat aneh.

https://en.wikipedia.org/wiki/Systems_analyst :

Beberapa profesional yang berdedikasi memiliki pengetahuan praktis di kedua bidang (analisis bisnis dan sistem) dan berhasil menggabungkan kedua pekerjaan ini, secara efektif mengaburkan batas antara analis bisnis dan analis sistem.

Contoh abstrak:


Ivan - BA perusahaan "Kontraktor".
Eva adalah seorang analis sistem pada Pelaksana.
Perusahaan "Pelanggan" memerlukan revisi besar terhadap sistem yang ada. 

Dalam situasi ini, tugas-tugas Ivan (BA): untuk mengidentifikasi persyaratan fungsional dan non-fungsional dari Pelanggan dan Kontraktor, untuk menghilangkan kontradiksi antara pihak-pihak yang berkepentingan untuk menentukan solusi yang dapat diterima, untuk membuat prototipe, untuk berinteraksi dengan pelanggan selama proses pengembangan, untuk melakukan tampilan demo dan penerimaan pekerjaan. Melakukan semua ini bersama dengan Hawa.

Tugas Eve (CA): untuk merancang revisi dengan cara yang optimal, menggambarkan dampaknya pada sistem, batasan dan kemungkinan perbaikan, membuat spesifikasi, menguraikan dan mentransfer tugas ke pengembangan, dan memantau implementasi tepat waktu sesuai dengan persyaratan. Untuk melakukan semua ini bersama dengan Ivan.

Alih-alih output


Dari masing-masing besi, orang dapat mendengar bahwa seiring waktu, kompleksitas masalah bisnis dan solusi TI mereka meningkat secara eksponensial. Bersamaan dengan ini, tumpukan teknologi berkembang secara intensif dan ekstensif, luas dan mendalam. Memilih komposisi teknologi yang tepat dapat memberikan keunggulan kompetitif terobosan, tetapi juga dapat merusak, seringkali pilihan dibuat untuk tahun-tahun mendatang, menempatkan pengembang dalam kerangka kerja yang sempit. 

Situasi saat ini membutuhkan analis TI (1) untuk memiliki pengetahuan yang mendalam tentang bidang subjek bisnis, fitur proses internal, lingkungan eksternal dan tren, (2) pengetahuan teknologi yang tidak kurang mendalam, sering kali penggunaan praktisnya.

Anda bisa menjadi seorang idealis, mencari jenius, dan menuntut pemahaman tinggi tentang berbagai bidang pengetahuan, jika bukan kutub. Anda dapat turun ke bumi dan memahami bahwa dualitas tugas semacam itu cenderung mengarah pada fakap di kedua arah. Duduk di dua kursi bukanlah praktik yang baik. 

Jika kompleksitas proyek memerlukan BA dan CA, pertama Anda perlu membentuk konsep tingkat pengetahuan bisnis dan fitur teknis apa yang diperlukan dari seorang spesialis dan menerjemahkannya ke dalam lowongan yang dipublikasikan, wawancara dan strategi pengujian. Seseorang selalu menginginkan "satu ukuran cocok untuk semua", tetapi kita hidup dalam kehidupan nyata, di mana itu akan lebih mempersulit pencarian dan meningkatkan harga menarik "multi-alat".

Kepada kolega yang telah menemukan diri mereka atau berencana untuk bekerja di BA atau CA, saya menyarankan Anda untuk melakukan prosedur yang sama dan dengan jujur ​​memahami sendiri apakah Anda ingin (1) mencari benih kebenaran dalam algoritma dan logika yang sering menentang, terus-menerus mengubah bisnis atau (2) meneliti dan merancang kompleks sistem membingungkan tapi menarik. Ini akan membantu mempersingkat jalan ke puncak yang dipilih dan mengurangi ketidaknyamanan karena tidak pada tempatnya dalam mengejar "posisi indah". 

Lampiran



Glavred, apakah sekarang lebih jelas? =)

All Articles