Teknik Borcun Finansal Etkileri

Yönetici Özeti

Ya ne kadar borcun olduğu hakkında hiçbir fikrin olmasaydı? Bunun ne kadara mal olduğunu veya şirketinizin operasyonel iyileştirmeler yapmasını, pazar değişikliklerine tepki vermesini ve hatta işi tamamen dönüştürmesini ne derece engellediğini bilmemek, içinde olmak rahatsız edici bir durum olurdu.

Ayrıca, ya kuruluşunuzdaki herhangi bir kişi izin almadan borca ​​girebilirse? Örneğin, emlak müdürünüz, düşük bir yıllık kira ile çok yıllı bir kira sözleşmesine hızlı bir şekilde girebilir, ancak geçen yıllarda kiralar önemli ölçüde artar - kimse bunu konuşmadan ifşa etmeden.

Bunların hepsi ihtiyatsız yönetim gibi geliyor, ancak aslında işletmelerde oldukça yaygın. Buradaki sorun şu ki, bu tür bir “borç” hepimizin çok iyi bildiği geleneksel finansal araçlar biçiminde gelmiyor.

Teknik borç bu özelliklerin hepsine sahiptir.

Borç, en basit haliyle, gelecekte geri ödeme niyeti ve vaadi ile bugün ödünç almaktır. Borç, bugünün borçlanmasının daha iyi bir yarına yol açacağı durumlarda anlamlıdır, örneğin kolej için borç almak veya bir ev satın almak. Borç genellikle kötüdür, çünkü bugün borç almak yarın daha kötü bir duruma yol açacaktır, örneğin pahalı bir akşam yemeğine çıkmak ve hemen ödemeyeceğiniz bir kredi kartına borç yüklemek.

Kurumsal anlamda borç, borcun maliyetinden daha fazla getiri sağlayacak yatırımları finanse etmek için yapıldığında iyi olabilir. Borç vadesinden çok önce işi satmayı planlıyorsanız da mantıklı olabilir. Borcun dezavantajı, nakit ve karı sürükleyen, esnekliği kısıtlayan ve sonunda iflasa yol açabilecek kadar külfetli hale gelebilecek çok gerçek bir masrafa sahip olmasıdır.

Şimdiye kadar bahsettiğimiz metafor finansal borçla ilgili, yine bir başka borç türü – teknik borç (veya “teknoloji borcu”) – birçok benzer özelliğe sahiptir ve ölçülmeli, yönetilmeli ve kasıtlı bir şekilde girilmelidir. . Şirketinizin pazara rekabetin önünde girmesine izin veriyorsa, büyük olasılıkla buna değer. Benzer şekilde, potansiyel olarak ciddi bir güvenlik açığını azaltmak için teknoloji borcunu üstlenmek de muhtemelen buna değer.

Bununla birlikte, teknik borcun olumsuz yanları vardır, bu da verimsizliğe ve atalete yol açar - örneğin bir departmanın diğerinin yazılımını kullanmak istememesi veya kısa vadeli finansal hedeflere ulaşmak için bir yükseltmeyi birkaç kez geciktirmeniz gibi.

Peki, Teknik Borç Nedir?

Teknik borç, bir bilgisayar programcısı olan Ward Cunningham'ın 1992'de ortaya atmasından bu yana öncelikle teknik topluluk içinde kullanılan bir terimdir. Kullanımı son zamanlarda hız kazandı ve çevik programlamanın yaygınlaşmasıyla birlikte merkez sahneye çıktı. Bu makalede tartışılan teknik borç, programlama metodolojisi değil, varlığının stratejik sonuçları ile ilgilidir.

Basit bir ifadeyle, teknik borç, yeni sistemleri uygularken veya mevcut sistemleri sürdürürken zamandan veya paradan tasarruf etmek için alınan önceki kararların bir sonucu olarak artan maliyet ve şirketinize çeviklik kaybıdır. Sistemler doğru şekilde entegre edilmediğinde veya kod aşırı karmaşık olduğunda ortaya çıkar. Bunun nedeni, verimsizlikler, pazara sunma süresi ile ilgili hususlar veya yazılımın güncel olmayan sürümlerinin çalıştırılması gibi diğer birçok nedendir.

Bazı net örnekler şunlar olabilir:

1. Yeni yazılım kullanmanızı veya bir güvenlik yükseltmesi uygulamanızı engelleyen eski Windows sürümlerini kullanmak
2. ERP sistemleri çok eski ve özelleştirilmiş olma kısır döngüsünde, bir “kop ve değiştir” çabası olacağı için yükseltilemezler
3. Kuruluşunuzun farklı bölümlerinde örtüşen işlevlere sahip benzer sistemler

Aşağıdaki şema, teknoloji borcunun bir şirketin teknoloji yığını içinde yapılabilecek diğer teknolojik uygulamalardan ne kadar farklı olduğunu çerçevelemek için kullanışlı bir grafiktir. Genellikle bir hata olarak algılanan teknik borç, mevcudiyeti bariz bir şekilde açık olmayabileceğinden çok farklıdır. Tehlike burada yatar, ne kadar uzun süre dokunulmazsa, etkinin büyüklüğü gelecekte o kadar yüksek olacaktır.

Hem BT içinde çalışmış hem de yüksek kaldıraçlı kurumsal şirketlerde bana BT raporu yaptırmış bir CFO olarak, teknik borcun geleneksel borca ​​ne kadar benzer olduğunu görmek beni çok etkiledi. Ayrıca ne kadar opak ve riskli olduğu beni etkiledi. Mali geçmişe sahip olanlar, mali borç mekanizmaları konusunda çok bilgilidirler—somuttur ve hesaplanması kolaydır. Ancak, genellikle yanlış anlaşılan veya yanlışlıkla başka birinin sorunu olarak kabul edilen teknik borç için durum böyle değildir.

Teknik Borcun Maliyetleri Tam Olarak Nedir ve Gerçek mi?

Kısa cevap, nakit maliyetlerin çok gerçek olmasıdır. Ayrı ayrı ölçülmesi ve yönetilmesinin yanı sıra tanımlanması gereken bazı önemli yumuşak maliyetler de vardır. Aşağıda bu maliyetlerin bazı örneklerini detaylandıracağım:

Nakit Maliyetler

Teknik borç, faiz ödemeleri kadar gerçektir. Bununla birlikte, genellikle, aşağıdaki şekillerde olduğu gibi, basit bir "faiz" satırı giderinden daha dolaylı bir şekilde P&L'de kendini gösterir:

Yoklama yapmak

• Mevcut sistemlerin bakımını yapmak için daha fazla personele ihtiyaç var
• Yeni yetenekler getirmek için ek geliştirici zamanı

havai

• Edinme entegrasyonu sinerjilerinin gecikmeli gerçekleşmesi
• Güvenlik ihlallerinden kaynaklanan düzeltme ve cezalar

Satış

• Sistem kesintileri nedeniyle satış kaybı
• Daha az verimli pazarlama harcaması

İşletme Sermayesi

• Özellikle yüksek stok bakiyesi olan işletmeler için artan gereksinimler

Yumuşak Maliyetler

Sabit maliyetlerin kendileriyle ilişkili gerçek dolar tutarları olsa da, sayısallaştırması ve tasarruf gerçekleştirmesi daha zor olmasına rağmen, iş sonuçlarınız üzerinde mutlak bir etkisi olan yumuşak maliyetler de vardır. Bunlar şunları içerir:

Pazar İstihbaratı

• Pazardaki fırsatlara veya değişikliklere hızla uyum sağlayamama
• Daha iyi kararlar almak için verileri bilgiye dönüştürme yeteneğinde azalma
• Gerçeğin birden çok versiyonu

üretkenlik

• Sistem kesintileri nedeniyle daha düşük personel verimliliği
• Verileri analiz etmeye ve analiz etmeye daha fazla zaman harcayan daha az üretken personel
• Büyük bir güvenlik ihlali meydana gelirse üst yönetimin zamanını ve dikkatini dağıtmak

Teknik ve finansal borcun bir karşılaştırmasına bakıldığında, temel farklılıklardan biri, birincisinin resmi bir kontrolünün olmamasıdır. Finansal borçta genellikle kredi komiteleri, varlık ve borç yönetimi ekipleri ve seviyeleri şahin gibi izleyen hazine personeli bulunur. Ancak teknik borç söz konusu olduğunda, geleneksel işletmelerde bu kontrollerin çok azı mevcuttur.

Teknik Borç Nasıl ve Neden Oluşur?

Geleneksel borçla, yönetim kurulu, CEO ve CFO ile birlikte, tipik olarak sermaye yapısını, yani ne kadar öz sermaye, ne kadar borç ve ne tür borç (tabanca, varlığa dayalı veya teminatsız) belirler. Üst sınır tablosu, hangi borcun ne zaman ödeneceği konusunda bile açıktır. Tüm bunlar resmi olarak kararlaştırıldıktan sonra, borcu yükseltmek için yapılandırılmış bir süreç başlatılır.

Borç verenler, bir işletmenin borcunu geri ödeme geçmişine, kredi notlarına ve onu destekleyen teminatın kalitesine ilişkin değerlendirmeler yoluyla borcu geri ödeme kapasitesine bakar. Ancak, bu resmi süreç, miktar belirleme ve imzalamanın hiçbiri teknik borç oluştuğunda gerçekleşmez. Bunun nasıl ve neden teknik borcun oluştuğu süreçlerden geçtiğine bir göz atalım:

Zaman Kısıtlamaları Uzlaşmaya Yol Açar

Pazarlama zamanı iş hayatında her şeydir. Tek başına yapılabildiğinde, yeni teknolojinin uygulanması çok daha hızlıdır. Ne yazık ki, bunun sonuçları, diğer sistemlerin uygulama ile senkronize olmamasıdır. Basit bir teknoloji yığınına sahip yalın organizasyonlar için bu o kadar da kötü görünmeyebilir.

Bununla birlikte, sistem konfigürasyonları karmaşıklıklarında çoğaldıkça sorunlu hale gelir. Sonunda, teknoloji süreçleri otomatikleştirir ve bilgiye dönüştürülen verileri yakalar. Entegre olmayan teknoloji, birlikte çalışmayan iş süreçlerine ve gerçeğin birden çok versiyonuna neden olur.

Hız için zaman feda edildiğinde, yerleşik test protokolleri göz ardı edilebilir veya feragat edilebilir. Bu genellikle, kendilerini bir tür sistem bozulmasına ve bunları düzeltmek için geliştirici zamanının dağılmasına yol açan yolda "hatalara" neden olur.

Teknoloji borcunun zaman içindeki etkisine bakarsak, bir konuya ne kadar uzun süre dokunulmazsa, etkinin büyüklüğü o kadar yüksek olur. Küçük bir kod yeniden düzenleme alıştırması olarak başlayan şey, hat boyunca tüm modernizasyon ve değiştirme çabalarına kartopu yapabilir.

Kısa Vadeli Maliyet Tasarruflarının Cazibesi

Kabul edelim - üst düzey ekipler sayıları yakalamak için sürekli baskı altında. Bugün harcamayı ertelemek, çeyreği tamamlamanıza yardımcı olabilir, ancak borç almak gibi, bir noktada geri ödemeniz gerekir. Şirketlerin kısa vadede para biriktirmelerinin ancak sonunda teknik borçla sonuçlanmalarının bazı yolları şunlardır:

Yazılım güncellemeleri

Zaman zaman, periyodik bir yazılım güncellemesini uygulamanın maliyeti ve zorluğu, gecikmeye neden olabilir. Bazen bu yıllarca devam eder. Uygunsuz zamanlarda göründüğünde Microsoft AutoUpdate'den zorla çıkmaktan hepimiz suçluyuz.

Sistemler mevcut sürümlerinin çok gerisinde kaldığında, onunla entegre olması gereken daha yeni yazılımlar bunu yapamaz. Ayrıca, birden fazla sürümü aynı anda yükseltmek genellikle daha pahalıdır ve hemen hemen her zaman, güncellemeye devam etmekten daha fazla zaman alır.

Donanım Değiştirme

Kuruluşların karmaşıklığı arttıkça, donanım güncelleme döngülerini senkronize etme çabası bunaltıcı ve maliyetli hale gelebilir. Bu, mevcut donanımın, ekipler arasında donanım kalitesi arasında var olan aşırı ve büyük eşitsizliklere kadar gerilmesine neden olabilir. Bazı ekipler hüsrana uğrar, yeni donanım satın alır ve BT'nin yükseltmeleri başlatmasını beklemek yerine sadece masa bütçeleri üzerinden harcama yapar.

Bu eşitsizliğin, ortak çalışmalar için üretkenlik ve donanım/dosya uyumluluğu üzerinde etkileri vardır.

Teknik Borç Durumunu Ele Alma Taktikleri

Sadece sorunlardan bahsetmek yerine, şimdi biraz proaktif olalım ve teknik borcu çözmek için bazı çözümler önerelim.

Bunun için finansal borcu yönetmek için kullanılan teknikleri kullanabiliriz. Borçlarınızı yönetebilmek için öncelikle ne olduklarını, ne kadar olduklarını ve ödeme koşullarını bilmeniz gerekir. Şimdi teknik borç için bunun üzerinde çalışalım.

1. Ne Kadar ve Ne Kadar Teknik Borcunuz Olduğunu Belirleyin

Finansal borç, her bir parçanın kıdemine göre tanımlanan dilimler halinde gelir (örneğin, kıdemli, asma kat veya revolver), bu da hangisinin önce geri ödendiğini gösterir. Teknik borç benzer bir kıdeme sahiptir; başlangıç ​​olarak, kritik görev sistemlerinizle başlamalısınız. Hangi teknik borçları var? Ardından, daha geniş ekosisteme bakın - daha iyi bir deyişle, sistemleriniz arasındaki hangi teknik borç masrafa neden oluyor?

Bu süreci fazla karmaşık hale getirmeyin. Bir noktada, yukarıdan aşağıya bir değerlendirmeye geçmek isteyeceksiniz, ancak oradan başlamak zorunda değilsiniz. BT şefinizin bu ödevle birlikte yönetim ekibinizi çekmesini sağlayın:

Tüm teknik borcumuzu bir yıl önce tamamen temizlemiş olsaydık, bu yıl (veya önümüzdeki yıl) nasıl daha iyi sonuçlanabilirdi?

En iyi on fikrinizi alın ve bunları 2x2'lik bir matrise koyun: bir eksende ödemesi kolay/zor ve diğer eksende faydaların derecesi. Umarım görsel nereden başlayacağınızı anlamanıza yardımcı olur.

Oradan, ödülün boyutu ve çaba ile ilgili varsayımlarınızı doğrulamak için detaya inin. Tarafsızlık burada anahtardır, bu nedenle "ücretsiz değerlendirme" yapmayı teklif eden yazılım satıcılarına karşı dikkatli olun.

2. Ne Yapacağınıza Karar Verin

Hangi teknik borcunuz olduğunu öğrendikten sonra, şimdi bununla nasıl başa çıkacağınıza karar vermeniz gerekiyor. Almak için birçok seçenek var.

Sonunda hiçbir şey yapmamak en iyisi olabilir. "Küçük" veya "düşük faiz oranı" olarak değerlendirilen borç için, aynı şekilde, erken ödemenin önemli bir "ön ödeme cezası" varsa, onu bırakmak en uygun olabilir. Stratejik avantajlar da olabilir. Bir versiyonun gerisinde olmak ve orada kalmak genellikle iyidir ve bazen bir başkasının kuruşunda karışıklıkların çözülmesine izin verme avantajına sahiptir.

Teknik borcun geri ödenmesi veya azaltılması, sistemlerin değiştirilmesini ve maliyet isabetinin alınmasını içerecektir. Bu, ya hemen ya da kademeli bir iyileştirme süreciyle zaman içinde yapılabilir. Finansal borçta olduğu gibi, teknik borcu “yeniden finanse edebileceğiniz” yaratıcı yollar vardır ve bakım için dış kaynak kullanımı bunlardan biridir. Bu, nihayetinde çözülmesi daha pahalıya mal olabilir, ancak anında ortaya çıkan maliyeti düşürmek için yayılabilir ve işbölümü ilkeleri aracılığıyla görevi daha uzmanlaşmış bir varlığa devredebilir.

Bulut tabanlı yazılım ve donanım hizmetlerinin ortaya çıkışı, kiralamaya dayalı finansmanın popülaritesi ile bir karşılaştırma da getiriyor. Bulut hizmetlerini kullanmak, hem CAPEX gereksinimlerini ortadan kaldırmada hem de geliştirme odağını bulut sağlayıcısına kaydırmada teknik borcu azaltmak için de etkili bir araçtır.

3. Bir Ödeme Planı Oluşturun

Teknik borcunuzu azaltmanın maliyetine kapılmayın ve hepsini bir anda ödemeye çalışmayın. Bu, herhangi bir büyüklükteki veya bilançodaki bir organizasyonu bunaltabilecek iddialı bir uygulama olacaktır.

Yine finansal karşılaştırmalara dönecek olursak, en yüksek faizli kredi kartını önce ödeme mantığına sahip olun. Bu basitçe, önce yüksek değerli/düşük çaba gerektiren faaliyetlere saldırmak anlamına gelir.

Önceki bölümde, teknik borçla mücadelenin çeşitli yollarını tartıştım. Her birinin maliyetini değerlendirirken, bir karşılaştırma alıştırması yapmak en iyisidir. Her potansiyel sonucun nakit akış maliyetini sıralamak, paydaşların her bir yolun avantajları ve takasları hakkında net bir görüşe sahip olmalarını sağlayabilir. Böyle bir görselin bir örneği aşağıda yer almaktadır.

Bu karşılaştırma, teorik bir çözüm ile sorunu çözmek ile hiçbir şey yapmamak (“mevcut temel çizgi”) arasındaki keskin karşıtlık arasındaki dengeyi gösterir. Bu örnekte, bir buluta geçiş, SaaS tabanlı çözüm, işletme için en ekonomik seçenek olacaktır.

İleriye Dönük Teknik Borç Yönetimi

Temel çizginizi ve saldırı planınızı oluşturduktan sonra, hem bu görünürlüğü korumak hem de yeni borçların sızmasını önlemek isteyeceksiniz. Alıştırmayı yeni bir başlangıç ​​ve sorunları önlemek için en iyi uygulamaları uygulama şansı olarak düşünün. gelecekte tekrar yükselecek.

Bir Kredi Açıklama Beyanı Uygulayın

Çoğu teknoloji projesi, bir yönetici sponsoru, üst düzey hedef, beklenen faydalar, program ve elbette maliyetlerle tamamlanmış resmi bir onay sürecine sahiptir. Bu, ortaya çıkacak yeni teknik borçları ve bunun gerekçesini temizlemek için harika bir yerdir.

Borçlanma Eşiklerini Belirleyin

Yeni standartlar belirleme konusunda fazla hevesli davranmayın. Kurumsal kredi kartlarını önceden belirlenmiş limitlerle bastığınız gibi, teknik borçları gereğinden fazla yönetmek istemezsiniz. Pek çok teknik borç küçüktür ve çabucak ödenecek kod yazımı ile ilgilidir. Bu özellikle çevik geliştirme için geçerlidir. Bu eşiği belirlemek ve izlemek için BT şefinize güvenin.

Sigortacılarınızı Yeniden Eğitin

Daha büyük şirketlerde BT'nin "değişim yönetimi" adı verilen bir süreci vardır. Yeni yazılım yayınlanmadan önce, genellikle değişiklik yönetiminden geçer. Basit bir ifadeyle, değişiklik yönetiminin görevi, şirketin teknoloji sistemindeki yeni değişikliklerin diğer sistemleri etkilememesini sağlamaktır. Bunu, yeni sistemin standartlaştırılmış yöntem ve prosedürlerle uyumlu olmasını sağlayarak yaparlar. Yeni borcun ortaya çıkmasını önlemek veya en azından belirlemek için bu süreci kullanmayı düşünün.

Teknik borç, iş yapmanın gerçek bir maliyeti ve sistem kesintilerinin gerçek bir nedenidir ve şirketin genel çevikliğini etkiler. Bununla birlikte, devam eden bir yük olmak zorunda değildir ve akıllı CFO'lar, kuruluşlarının ne kadar teknoloji borcu olduğunu ve bunu optimize etmek için ne gerektiğini bilecektir.