İş için iç araçlar geliştirmeye yönelik pratik bir rehber: araca ihtiyaç duyan süreci nasıl fark edersiniz, çoğu iç araç neden terk edilir, dağınık bir manuel akıştan yazılıma giden inşa yolu ve kimsenin bakmadığı bir araç daha eklemek yerine sahipliği nasıl elinizde tutarsınız.
Kritik bir süreci manuel adımlar, sohbet mesajları ve hafızayla yürüten operasyon ekipleri, ofis yöneticileri, kurucular ve büyüyen işletmeler.
- Hangi manuel sürecin gerçekten bir araca ihtiyaç duyduğunu fark etmenin bir yolu
- Dağınık bir akıştan insanların güvendiği bir yazılıma giden bir inşa yolu
- Sahibi olduğunuz ve değiştirebildiğiniz bir iç araç, sıradaki bir madde değil
Büyüyen her işletme, hiçbir yerde yaşamayan birkaç süreç üzerinde döner: sohbette gerçekleşen bir onay, birinin kafasında takip edilen bir devir, hiçbir yere yazılmadığı için herkesin sorduğu bir durum. İç araçlar tam da bunun içindir. Bunlardan bu kadar azının yapılmasının nedeni artık maliyet değil; hiçbir zaman mühendislik iş listesinin üstüne çıkamamış olmaları. Bu rehber, doğru olanı kendiniz geliştirmeniz ve böylece gerçekten yapılması hakkında.
Araca ihtiyaç duyan süreç, insanların birbirine sürekli sorup durduğu, işin bir devir beklerken tıkandığı ve şu an yalnızca sohbet mesajları ile hafızayla bir arada tutulan süreçtir. Ekibinizde tekrar eden soru şu ya da bu biçimde “X'in durumu ne?” veya “Y şu an kimde?” ise, o soru bizzat şartnamedir: araç, kimsenin sormasına gerek kalmadan cevabı görünür kılmak için vardır.
İç araçlar insanların yerini almakla ilgili değildir; ekiple birlikte büyüyen koordinasyon vergisini ortadan kaldırmakla ilgilidir. Beş kişilik bir işletme kafasında koordine olur. Hâlâ kafasında koordine olan yirmi kişilik bir işletme ise her günün giderek büyüyen bir bölümünü durum güncellemelerine, onayların peşinden koşmaya ve işlerin nerede olduğunu yeniden anlatmaya harcar. Bu görünmez yük, tam da odaklı bir iç aracın kaldırdığı şeydir; bu yüzden doğru ilk araç, koordinasyonda en çok zaman kaybettiren süreci hedef alır.
Acıya göre seçin, dürüstçe ölçerek. Birkaç gün boyunca hangi sürecin en çok “kısa soru”, en çok düşen devir ve en çok “ben senin yaptığını sanıyordum” ürettiğini gözlemleyin. Kazanan nadiren en karmaşık süreçtir; en sık koordine edilen süreçtir.
İç araçlar öngörülebilir nedenlerle başarısız olur ve bunları önceden bilmek, sizinkini hayatta tutan şeyin büyük kısmıdır.
Bir iç araç, kullanmak kullanmamaktan kolay olduğunda işe yarıyor demektir. Herhangi bir özellik eklemeden önce, aracı kullanımda daha hızlı mı yoksa daha yavaş mı yaptığını sorun. Terk edilen iç araçların çoğu iyi niyetten öldü: birinin isteyebileceği alanlar, kapsamlı görünen adımlar; bunların hepsi günlük yolu insanlar ondan çekilene dek ağırlaştırdı.
İnsanların kafasındaki bir süreçten bir araca geçiş, güvenilir bir sırayı izler. İlk adımı atlamak, bu kadar çok aracın yanlış sorunu çözmesinin nedenidir.
Bir lojistik ekibinin en kötü süreci ekipman teslimiydi: hangi cihaz kimde, ne zamandan beri ve gecikmiş mi, hepsi bir sohbet kanalında ve bir kişinin hafızasında takip ediliyordu. Bir hafta izlendiğinde dört şeye indi: varlıklar, kişiler, teslimler ve bir “iade edildi/gecikti” durumu. Birinci sürüm herkesin bir cihazı teslim almasına izin verdi, tüm filonun durumunu tek ekranda gösterdi ve geciken öğeleri otomatik işaretledi. Günlük “tarayıcı kimde?” sorusu basitçe kesildi, çünkü cevabı ekran veriyordu.
Yaşayan bir iç araçla ölen bir iç araç arasındaki fark genellikle özellikler değildir; ekibin onu gerçeğe uygun tutup tutamayacağıdır. İki şey onu korur.
İşte burada süreci anlatıp aracı onun etrafında geliştirtmek, hem katı bir şablonu hem de sonra çekip giden bir geliştiricinin tek seferlik betiğini geride bırakır. Gerçek akışınıza göre biçimlenmiş, akış geliştikçe her seferinde mühendislik kuyruğuna yeniden girmeden yeniden biçimlendirebileceğiniz bir yazılım elde edersiniz. Araç yaşamaya devam eder çünkü süreci yürüten insanlar onu dürüst tutabilir.
İnsanların birbirine sürekli sorup durduğu ve işin devirlerde tıkandığı süreci hedefleyin. Birkaç gün boyunca hangisinin en çok “kısa soru” ve düşen devir ürettiğini gözlemleyin; en karmaşık süreç değil, en sık koordine edilen süreç, aracın en çok boşa giden zamanı kaldırdığı yerdir.
Çünkü gerçek süreç yerine onun derli toplu bir sürümünü çözerler, çünkü güncellenmeleri yerini aldıkları sohbet mesajından yavaştır, çünkü süreç değiştiğinde değişemezler ya da çünkü bir veri adasına dönüşürler. Çözüm; önce gerçek işi izlemek, aracı en hızlı yol yapmak ve onu kendiniz değiştirebilmektir.
Yalnızca ana yolu: kaydı oluşturun, gerçek durumlarından geçirin, durumunu görün ve devredin; bir de kimin ne yaptığını ve kimin yalnızca izlemesi gerektiğini belirleyen rolleri. Hayali değil, gerçekten gözlemlediğiniz istisnaları ekleyin ve geri kalan her şeyi insanlar kullanmaya başladıktan sonrasına bırakın.
Artık yok ve onu kendiniz geliştirmenin gerçek bir avantajı var: iç süreçler sürekli değişir, dolayısıyla süreç kaydıkça düzenleyebildiğiniz bir araç kullanışlı kalır, oysa her değişiklik için mühendislik talebi gerektiren bir araç gerçekten kopar ve terk edilir. Akışı anlatın ve onu değiştirebilme yeteneğini elinizde tutun.