Membangun model rantai pasokan perangkat lunak

Penggambaran standar aliran nilai pengembangan perangkat lunak dimulai dengan pengkodean dan diakhiri dengan kode dalam produksi. Anda sering melihat diagram pengembang yang dimulai dengan "bisnis" dan diakhiri dengan "pelanggan". Namun, penggambaran ini tidak secara akurat mencerminkan kompleksitas pengiriman perangkat lunak pada skala perusahaan.

Mengambil langkah mundur, Anda melihat lebih banyak aktivitas yang terlibat dalam penyediaan perangkat lunak kepada pelanggan, tetapi pendekatan saat ini untuk mengelola aktivitas ini berakar pada kerangka penyampaian layanan dan bukan dalam model produksi. Dengan demikian, mereka tidak menghubungkan semua aktivitas yang terlibat sebagai satu sistem ujung ke ujung.

Model yang digunakan dalam industri produk lain adalah model rantai pasokan, dan dengan menerapkan model tersebut pada pengiriman perangkat lunak, Anda dapat memperluas pemahaman Anda tentang "sistem" pengiriman perangkat lunak di luar pengembang, memberi Anda wawasan baru tentang cara mengoptimalkannya.

Apa rantai pasokannya?

Rantai pasokan dimulai dengan gagasan bahwa Anda dapat mengoordinasikan semua aktivitas produksi dan nonproduksi sebagai satu sistem. Manajemen rantai pasokan sering disalahartikan sebagai "manajemen pemasok", padahal sebenarnya itu hanya salah satu aspek dari manajemen rantai pasokan (meskipun sangat penting).

Semua bisnis produk dan layanan memiliki rantai pasokan, dan aktivitas yang terlibat serta kepentingan relatifnya terhadap sistem rantai pasokan akan bervariasi. Gagasan intinya, bagaimanapun, adalah bahwa dengan mengoordinasikan aktivitas-aktivitas ini sebagai satu sistem, Anda mendapatkan nilai yang lebih besar daripada jumlah bagian dan mengalirkan penyampaian yang efisien dari nilai tersebut kepada para pemangku kepentingan.

Aktivitas berikut hanyalah sebagian kecil dari aspek penting dari semua rantai pasokan, tetapi untuk perangkat lunak, aktivitas tersebut dijalankan secara unik:

Perencanaan

Dalam rantai pasokan tradisional, aktivitas perencanaan melibatkan koordinasi aset dan mengoptimalkan aliran proses untuk menyeimbangkan pasokan bahan dengan permintaan produk. Dalam rantai pasokan perangkat lunak, koordinasi tersebut melibatkan memastikan kode yang tepat dikembangkan untuk fitur produk yang paling dibutuhkan. Dalam skala besar, dengan ratusan aplikasi dan ribuan pengembang perangkat lunak, ini adalah upaya yang monumental.

Luasnya aktivitas perencanaan sering diminimalkan oleh model devops yang ada. Maka agak ironis, bahwa perusahaan besar yang paling membutuhkan pengembang harus bersaing dengan kewajiban hukum, peraturan, kontrak, dan pelanggan yang membuat perencanaan menjadi panjang dan rumit. Pendekatan rantai pasokan untuk perencanaan melibatkan pengoptimalan antarmuka antara berbagai peran perencanaan dan disiplin yang terlibat, dan faktor kunci keberhasilan adalah mampu mengintegrasikannya secara efektif.

Di satu sisi, metodologi tangkas yang memandu pengembangan di perusahaan sering kali dimasukkan ke dalam proses air terjun. Beberapa bisnis dapat lolos dari siklus perencanaan fiskal, dan proses yang gesit dapat berisi abstraksi yang bertentangan dengan siklus tersebut; misalnya, sprint mungkin tidak sejalan dengan batas-batas kuartal fiskal. Kurangnya komunikasi dan koneksi antara proses pengembangan yang menggunakan aktivitas agile dan nonproduksi menggunakan waterfall dapat menyebabkan pemborosan dan inefisiensi di seluruh bisnis.

Di sisi lain, perencanaan produk perusahaan selalu melibatkan sistem manajemen persyaratan dan keterlacakan yang ekstensif, dan ini tidak berbeda untuk produk perangkat lunak. Manajemen persyaratan sangat penting dalam industri yang sangat diatur seperti perawatan kesehatan, di mana perangkat lunak dapat dikembangkan untuk perangkat medis yang dapat berarti hidup atau mati bagi pengguna. Manajemen persyaratan melibatkan alat dan metodologi khusus, dan kemampuan untuk melacak ketepatan dan kualitas penerapannya di seluruh siklus hidup pengembangan dapat menjadi sangat penting untuk produk perangkat lunak perusahaan.   

Sourcing

Dalam rantai pasokan tradisional, komponen sumber melibatkan pengelolaan hubungan dengan pemasok dan pengembangan strategi pengadaan untuk suku cadang dan bahan. Perangkat lunak juga sangat bergantung pada komponen yang bersumber — menurut penelitian terbaru oleh Sonatype, sumber terbuka sekarang merupakan mayoritas dari produk perangkat lunak: sebanyak 80 hingga 90 persen kode dalam aplikasi modern berasal dari komponen sumber terbuka. Dan komponen ini menciptakan tantangan manajemen yang unik.

Pertama, mungkin sulit untuk memutuskan bagaimana menentukan kualitas komponen, dengan banyak faktor yang memengaruhi keputusan seperti konsumsi, pengujian, dokumentasi, komunitas, dukungan, dan tren teknologi. Memiliki strategi dan pendekatan yang jelas untuk memilih komponen sangat penting.

Kedua, karena banyaknya balon komponen sumber terbuka, bahkan mengetahui apa saja yang diizinkan untuk mengelola semuanya secara efektif adalah sebuah tantangan. Manajer dan teknisi produk perlu memperhatikan masalah perizinan dan masalah keamanan. Status komponen open source Anda dapat berubah setiap hari saat kerentanan baru ditemukan dan pengelola mengubah strategi kekayaan intelektual mereka. Dan pelanggan ingin tahu persis apa yang mereka terima — banyak perusahaan besar tidak akan membeli perangkat lunak tanpa tagihan barang yang menjelaskan apa yang ada di dalam kotak. Mengelola semua masalah open source ini adalah aspek inti dari pengembangan produk perangkat lunak.

Distribusi

Menyerahkan perangkat lunak ke tangan pelanggan dapat melibatkan semua jenis jaringan mitra yang kompleks: penerapan, distribusi, integrasi, pengecer; semua jenis perjanjian: OEM, lisensi, NDA, RFP; semua jenis pertemuan: demo, PoC, presentasi; dan masih banyak lagi.

Hubungan ini berfungsi sebagai masukan, keluaran, dan bahkan langkah-langkah dalam proses pengiriman perangkat lunak. Keadaan salah satu hubungan ini dapat berdampak langsung pada aktivitas pembangunan. Tanpa mengelolanya dengan cermat dan menghubungkannya dengan pekerjaan yang dilakukan, akan terjadi pemborosan yang sangat nyata.

Bayangkan menyampaikan epik untuk prospek yang diam-diam menjadi peluang yang hilang, atau menerapkan fitur untuk mitra yang membatalkan perjanjian mereka sebulan yang lalu. Ini terjadi secara teratur ketika perangkat lunak dikirimkan secara independen dari aliran nilai bisnis — ketika fungsi pengiriman perangkat lunak tidak ditautkan ke rantai pasokan.

Pipeline devops harus terhubung erat dengan kemitraan, perjanjian, dan tujuan di mana pekerjaan tersebut dilakukan. Kode dapat dilacak dan ditautkan dari cerita ke persyaratan hingga ke catatan pelanggan di CRM Anda, semua dengan memperlakukan pengiriman perangkat lunak Anda seperti rantai pasokan dan menindaklanjuti dengan strategi integrasi.

Bayangkan, sebaliknya, dapat menampilkan semua aktivitas yang sedang berlangsung yang dilakukan untuk kontrak tertentu, atau semua fitur yang direncanakan untuk pelanggan baru — ini adalah hasil dari manajemen rantai pasokan perangkat lunak — visibilitas dan keterlacakan di seluruh siklus hidup.

Alat

Meskipun perkakas manufaktur klasik Anda mungkin terdiri dari mesin pemotong mati dan oven perlakuan panas, rantai pasokan perangkat lunak melibatkan kelas alat (berbagai disebut alat ALM, alat siklus hidup, atau alat devops) yang digunakan untuk mengelola berbagai tahap pengiriman perangkat lunak .

Strategi untuk mengelola alat ini sangat berbeda dari pendekatan klasik karena investasi teknis dan intelektual dalam alat pengembangan perangkat lunak sangat besar dan sangat berpengaruh. Jenis alat ini juga berkembang dengan cepat dan sangat terfragmentasi — Jenkins masa kini akan menjadi Hudson masa lampau. Sebuah organisasi perlu diposisikan untuk memiliki tumpukan alat yang tangguh namun modular, yang menyediakan apa yang dibutuhkan tim, sambil mempertahankan fleksibilitas untuk beradaptasi.

Selain itu, rantai alat tidak dapat diputuskan — ia perlu mengalirkan informasi kembali ke hulu dan ke hilir melintasi rantai nilai untuk mendapatkan pengetahuan di tempat yang diperlukan. Area ini juga penting untuk diperiksa dari sudut pandang integrasi — bagaimana Anda dapat menghubungkan aktivitas pada lapisan tertentu dengan aktivitas pengelolaan rantai pasokan di sekitarnya dan mendukung?

Kesimpulan

Bisnis secara historis memisahkan manajemen teknologi dari lini bisnis yang menghasilkan pendapatan, memperlakukannya sebagai serangkaian aktivitas pendukung yang didorong oleh nilai dan tujuan yang selaras dengan penyampaian layanan. Namun, dalam dunia yang ditentukan perangkat lunak, model bisnis itu tidak lagi cocok.

Kemampuan pengiriman perangkat lunak telah keluar dari ruang dukungan yang didefinisikan secara klasik dan telah menjadi penentu semua aktivitas penghasil pendapatan utama.

Oleh karena itu, Anda perlu memikirkan kembali model Anda sebagai sistem produksi dan beralih ke model yang menangkap hubungan kompleksitas di seluruh aktivitas value stream. Rantai pasokan mewujudkan pemikiran itu, dan seiring dengan perkembangan produksi produk perangkat lunak, kita pasti akan melihat model ini matang.