Situasi yang cukup standar: dalam mencari kontraktor untuk mengembangkan solusi TI, pelanggan mengirimkan pertanyaan ke beberapa perusahaan. Tujuannya untuk memutuskan kerjasama dengan kontraktor dengan mengumpulkan dan menganalisis proposal. Proses seleksi diperumit oleh fakta bahwa ruang lingkup pekerjaan, teknologi yang diusulkan, dan harga berbeda secara signifikan satu sama lain. Muncul masalah yang sering tidak disadari: proposal ini tidak hanya tidak setara, tetapi juga mengevaluasi solusi yang berbeda.
Artikel ini memberi pembaca pandangan sistematis tentang pemilihan kontraktor. Tujuan kami adalah untuk merangsang pencarian pendekatan inovatif untuk memecahkan masalah pada tahap merumuskan masalah dan mengumpulkan perkiraan.
Di seluruh teks, istilah "solusi TI" dan "objek pengembangan" digunakan secara bergantian. Yang mereka maksud adalah perangkat lunak apa pun (seluler, web, aplikasi desktop, situs web, dll.) Yang dibuat selama proses pengembangan untuk mencapai tujuan bisnis tertentu dari pelanggan. Ada istilah "objek penelitian" - tahap pembuatan objek pengembangan hingga implementasi solusi.
Situasi dan masalah
Proses pemilihan kontraktor yang khas adalah sebagai berikut.
1. Kerangka Acuan
Bagian dari proses pengadaan adalah dokumen yang menjelaskan solusi - kerangka acuan (TOR). Manajer Pelanggan adalah orang yang berminat pada jasa pengembangan (selanjutnya disebut subjek), mengirimkan TK ke beberapa organisasi. Subjek dalam organisasi ini menerima TK dan mengevaluasi pekerjaan berdasarkan persyaratan yang ditentukan. ( Bagaimana pelanggan mendapatkan tugas teknis - lihat paragraf "Kerangka acuan untuk studio!" Untuk contoh "situasi yang mendekati ideal") Secara
skematis, hubungan ini adalah sebagai berikut.
2. Tanggapan dari organisasi dan analisis proposal
Pelanggan menerima penawaran dari calon kontraktor. Proposal adalah format dokumen yang paling sering menunjukkan ruang lingkup pekerjaan, tenggat waktu, perkiraan biaya, deskripsi pengalaman dan keahlian tim. Proposal dipelajari dan dibandingkan satu sama lain menurut sejumlah kriteria.
3. Daftar organisasi yang dipilih
Berdasarkan analisis proposal, daftar calon kontraktor dikurangi. Pilihan akhir dibuat setelah komunikasi dengan masing-masing dari mereka dan pembahasan dokumen yang diserahkan.
4. Kontrak
Menandatangani kontrak layanan dengan kontraktor terpilih.
Seringkali pada tahap 2 dan 3 muncul masalah: ini dibuktikan dengan pengalaman saya bekerja sama dengan usaha kecil dan menengah. Proposal dengan komposisi pekerjaan yang berbeda dan perkiraan yang berbeda menciptakan ilusi bahwa data ini cukup untuk mengambil keputusan. Pada saat yang sama, kriteria pemilihan dikurangi menjadi biaya dan ruang lingkup pekerjaan.
Menurut saya, pendekatan ini tidak memberikan syarat kelengkapan dan kecukupan informasi untuk mengambil keputusan. Tidak ada pemahaman sadar tentang situasi dan adanya proses "tidak lengkap" dalam mentransfer pengetahuan tentang solusi potensial antara kedua subjek.
Kerangka acuan untuk studio!
Penugasan teknis (TOR, penugasan teknis) - dokumen yang berisi persyaratan pelanggan untuk objek pengadaan. TK menentukan kondisi dan prosedur pengadaan, sesuai dengan itu, pengiriman barang, pelaksanaan pekerjaan, penyediaan layanan dan penerimaannya dilakukan.
Saya akan mencoba melengkapi definisinya.
Kerangka Acuan adalah seperangkat artefak yang melaluinya pengetahuan formal tentang objek pengadaan dalam konteks ini ditransfer - pengetahuan tentang solusi TI yang dibuat.
Untuk menganalisis langkah # 1-3, sekarang mari kita secara singkat membangun situasi yang mendekati ideal dari langkah 1. Saat ini, ada banyak standar GOST di pasar untuk menulis spesifikasi teknis untuk pengembangan sistem informasi. Saya tidak akan menjelaskan mereka, mereka semua berkembang dengan baik dan memiliki pro dan kontra.
Misalkan klien, untuk menentukan solusi optimal, melihat objek penelitian dari berbagai sudut. Dengan memeriksa proyeksi yang berbeda, Anda dapat menemukan solusi optimal. Proyeksi satu sisi tidak akan menampilkan gambar secara penuh. Seperti pada ilustrasi di bawah, silinder adalah persegi di satu proyeksi dan lingkaran di proyeksi lainnya. Untuk orang yang berbeda, solusi untuk masalah yang sama akan berbeda pula.
Anda juga dapat mencapai solusi optimal melalui analisis sistematis masalah, dengan memeriksa objek dengan proyeksi fungsional, genetik, dinamis, prosedural.
Skema 1 - Proyeksi pemeriksaan objek berdasarkan konsep ke-2 dari sistem menurut Dubrovsky.
Saya tidak akan memikirkan pendekatan ini, tetapi saya dapat membagikan di komentar pengalaman saya aplikasi dalam praktik, jika ada permintaan.
Dengan demikian, setelah tindakan tertentu, subjek telah membentuk Pengetahuan tentang bagaimana menyelesaikan masalah. Pengetahuan mungkin tidak cukup, dan masalah mungkin berbeda dalam perjalanan menuju tujuan, tetapi pengetahuan ada dalam volume tertentu.
Bagaimana kita mentransfer pengetahuan tentang solusinya?
Pembelajaran - perolehan pengetahuan, keterampilan, keterampilan - terjadi dalam beberapa tahap: produksi, akumulasi, distribusi, penggunaan.
Gambar 2 - Langkah Pembelajaran
Pertimbangkan diagram ini dalam kaitannya dengan proses interaksi dengan kontraktor.
- Produksi pengetahuan implisit. Manufaktur adalah kumpulan informasi dari berbagai sumber: rekomendasi konsultan, penelitian pesaing, pengalaman pribadi dalam mengembangkan solusi TI, informasi tentang organisasi objek di sekitar masalah yang diteliti, dan banyak lagi. Pengetahuan implisit tidak diformalkan, yaitu tidak diungkapkan dengan cara apa pun. Dengan kata sederhana, pengetahuan implisit ada dalam memori subjek, manajer perusahaan yang tertarik pada pengembangan.
- . . , — ! — , , , , . , , , , , - , . , . .
- . , . , (, , ..). . , , , N ( ).
3 — . - . , , , , .
Daftar periksa proyeksi untuk memformalkan pengetahuan dan menggambarkan situasi sebelum pemilihan kontraktor
Untuk membantu manajer dan manajer menghindari kesalahan saat membuat dan mentransfer spesifikasi teknis untuk penilaian kepada kontraktor TI, saya mengusulkan daftar proyeksi untuk memformalkan pengetahuan tentang solusi TI dan daftar periksa dengan deskripsi situasi yang akan membantu menerapkan skema "tahapan pembelajaran" yang telah saya jelaskan.
Menurut saya, solusi IT harus dipertimbangkan dari setidaknya 4-5 posisi untuk mendapatkan gambaran yang paling lengkap.
Daftar Periksa No. 1 - "Daftar proyeksi"
- Deskripsi situasi di sekitar objek dalam kerangka aktivitas pada saat penelitian: bagaimana orang bekerja, jenis aktivitas apa yang mereka lakukan, kesulitan apa yang muncul, dll.
- Proyeksi fungsional mengenai peran utama dalam solusi.
- Proyeksi non-fungsional dengan model karakteristik teknis yang mempengaruhi keputusan.
- Proyeksi bisnis dalam kaitannya dengan pemangku kepentingan utama, dimana Tujuan dirumuskan melalui Metode dan Hasil.
- Proyeksi visual dari prototipe solusi (asalkan Anda telah melewati tahap penelitian pada prototipe).
Tentu saja, mungkin ada lebih banyak posisi dan proyeksi, dan seseorang akan mengatakan bahwa daftar periksa ini akan berubah dalam kaitannya dengan industri, tugas, dll. ... Kemungkinan besar memang demikian, tetapi tugas utama saya adalah fokus pada fondasi metodologis. Jadi mereka dapat digunakan di mana saja, dan membuat daftar periksa untuk setiap situasi.
Jenis situasi di mana seorang manajer mungkin menemukan dirinya sendiri sebelum menarik kontraktor:
- Anda memiliki keinginan untuk melakukan sesuatu yang bermanfaat, tetapi tidak mengerti apa sebenarnya.
- , . .. , , , . , .
- , , . .. , . , : , , , ...
- , ( = + ), 1- , - №1.
- , 4-5 , - № 1.
- , - . , 1-5 .
Tugas Anda adalah sampai pada poin 4 atau poin 5. Pada saat yang sama, di setiap tahap, Anda harus menghasilkan pengetahuan dan mengumpulkannya. Anda harus memiliki produk formal dan nonformal dari aktivitas Anda: diagram, deskripsi, keterampilan pribadi dan pengalaman cara kerjanya, deskripsi melalui posisi checklist # 1. Dan ketika Anda sampai pada poin 4, maka tugas Anda adalah menyebarkan pengetahuan - untuk mentransfernya ke kontraktor dan mitra Anda.
Tahap diseminasi paling sering berisi prosedur berikut: analisis, diskusi dan asimilasi.
Jika Anda hanya mengirimkan TK ke kontraktor untuk melihat harga dan menganalisis ruang lingkup pekerjaan, maka ini sama saja dengan mencoba duduk di kursi tanpa meletakkannya di bawah pantat Anda. Seseorang mungkin beruntung dan dia akan duduk, tetapi bagi seseorang akan ada konsekuensi yang tidak menyenangkan =)
Jadi, tanyakan pada diri Anda pertanyaan: bagaimana, saat mentransfer pengetahuan kepada kontraktor mengenai situasi Anda, Anda:
- menganalisis pengetahuan formal dan non-formal tentang objek transfer
- berdiskusi dengan kontraktor pengetahuan formal dan non-formal tentang objek transfer
- mengasimilasi pengetahuan ini.
Beberapa pembaca akan mengatakan bahwa sulit dan seringkali secara fisik tidak mungkin untuk melaksanakan prosedur ini saat mengirimkan TOR dan mengumpulkan harga dari kontraktor. Saya sangat setuju dengan mereka. Tapi itu membuatku berpikir bahwa tujuan dirumuskan dengan tidak tepat.
Jika saya perlu mencari kontraktor, maka pencarian harus dilakukan melalui penelitian kontraktor. Oleh karena itu, kita dapat menerapkan analisis sistem yang sama dan, misalnya, skema # 1, untuk merencanakan program untuk mencapai tujuan ini. Dan kemungkinan besar tugas akan berubah dan akan sangat berbeda dari langkah-langkah yang dijelaskan di bagian “Situasi dan masalah”.