Enterprise firmalarda Jira: adam gün, lead/cycle time ve finans raporlaması

Perakendede ürün yönetimi yapıyordum, e-ticaretle mağazacılığın kesiştiği yerde. Teknoloji tarafında dokuz ekip vardı: mobil, ödeme, veri, mağaza sistemleri, birkaç tane daha.

Bir sabah ürün direktörüm masama geldi. “Her ay başı finansa bir rapor vereceğiz,” dedi. “Hangi proje hangi ay kapandı, hangi projede hangi statüye ne kadar harcandı, bunları görmek istiyorlar.”

Arkasından da şu geldi: “Jira’da her şey var zaten, çıkarırsın.”

“İki günlük iş” dedim. Üçüncü günün sonunda yanıldığımı anladım.

Çünkü istenen tek bir rapor değildi, iki ayrı rapordu. Bunu ayırt etmem bile birkaç günümü aldı.

Statü kırılımı bizim meselemizdi. Bir iş neden altı hafta sürdü, o altı haftanın ne kadarı analizde geçti, testte ne kadar bekledi. Bu soruyu soran IT’ydi ve cevabı ekiplerin kendi süreciyle ilgiliydi.

Finansın derdi ise tek bir şeydi: hangi projeye ne kadar adam gün gitti. Statünün adı onları zerre ilgilendirmiyordu. Onlar için proje, üstüne emek yazılan bir kalemdi; o emeğin karşılığı da paraydı.

İki rapor da aynı veriden çıkacaktı. Çıkabilmeleri için de aynı ağacın üstünde durmaları gerekiyordu. İşin bütün zorluğu buydu.

O yılın Jira kaydı on bini geçmişti. Ekipler düzenli çalışıyordu, sprintler kapanıyordu, ortada aksayan bir şey yoktu. Ama “ödeme sayfası yenileme projesine geçen ay kaç adam gün gitti” sorusunun cevabı hiçbir ekranda yoktu. Jira’nın kendi raporları bana hız veriyordu, burndown veriyordu, kümülatif akış veriyordu; hiçbiri finansın sorduğu soruya cevap değildi. Marketplace’te para isteyen eklentiler vardı ama satın alma süreci ilk raporun teslim tarihinden uzun sürerdi.

Sonunda bir hafta sonu oturdum, REST API’den kayıtları ve statü geçmişini çeken küçük bir betik yazdım. Kod kolay kısımdı. Zor kısım, o kodun neyi toplayacağına karar vermekti.

Bu yazı da o kararların hikâyesi. Anlattığım yapı gerçek; yazıdaki kayıt kodları, ekip isimleri ve sayılar temsilî.

Aslında sorun Jira’da değildi

Bunu ilk gün anladım. Jira bir muhasebe aracı değil, iş takip aracı. Sorun, iş takibiyle finansın aynı ağacın üstünde durmuyor olmasıydı.

Kurumda iki ayrı dil konuşuluyordu ve bu ikisi kendiliğinden hiç buluşmuyordu.

Finansın dili projeydi, kendi tabiriyle yatırım kalemi. “Sadakat programı yenilemesi” diye bir kalem var; bütçesi var, sahibi bir departman, yıl içinde ne kadar tükettiği takip ediliyor. Kalem bir kere açılıyor ve on sekiz ay yaşıyor.

Ekiplerin dili görevdi. Bir backend geliştiricinin haftası “puan servisinin idempotency kontrolü” gibi bir kayıtla geçiyor. O kayıt üç gün yaşıyor, kapanıyor, yerine yenisi geliyor.

Arada iki üç seviye var ve o seviyeler doldurulmadıkça yukarıdaki kalemle aşağıdaki emeği kimse eşleştiremiyor.

O boşluğu o güne kadar Excel kapatıyordu. Ay sonunda biri oturuyor, ekip liderlerine soruyor, tahminî yüzdeler yazıyor, dosyayı finansa yolluyordu. Dosya yanlış değildi ama denetlenebilir de değildi. Direktörüme “geçen ayın dosyasındaki %35 nereden geliyor” diye sordum, cevap çok netti: “Kimse bilmiyor. Zaten sorun da bu.”

Önce ağacı çizdim

Kod yazmadan önce beyaz tahtaya dört kat çizdim. Katların adı firmadan firmaya değişiyor, mantığı değişmiyor.

Birinci kat, yatırım kalemi. Finansın “proje” dediği şey; raporda gördüğü tek satır da bu. Kendi Jira projesinde duruyor, bizde YTR diye bir projeydi. YTR-1042 Ödeme sayfası yenileme gibi. Sahibi bir ürün ya da program yöneticisi, geliştirici değil. Üstünde talep eden departman, yatırım tipi, hedef çeyrek ve planlanan bütçe var. Sprint’e girmiyor, story point almıyor, kimseye atanmıyor.

İkinci kat, geliştirme epikleri. Bir yatırım kalemi tek ekibin işi olmuyor. YTR-1042 altında mobil ekibin bir epiği, ödeme ekibinin iki epiği, veri ekibinin bir epiği var. Her biri kendi ekibinin projesinde: ODM-3310, MBL-880, VRI-214. Dokuz ekibi tek projeye toplamayı denemedim bile; denesem en az üç ayım giderdi ve kimse de kabul etmezdi. Bu kat, yatırımın ekiplere dağıldığı yer.

Üçüncü kat, görevler. Emeğin gerçekten harcandığı yer. Tahmin buraya giriyor, iş buraya kaydediliyor, statü geçmişi burada anlam taşıyor. Bir epiğin altında on beş görev olabiliyor.

Dördüncü kat, alt görevler ve hatalar. Genelde atlanan kat. Bir görevin altındaki test, düzeltme ve yeniden geliştirme kayıtları burada duruyor. Bu katı ayrı tutmak önemliydi, çünkü bir işin maliyetinin ne kadarının yeniden çalışma olduğunu ancak burada görüyorsunuz. Hatayı ana görevin içinde eritirseniz kalite maliyeti buhar oluyor.

Çizim bitince tahtada iki tane de ok vardı ve asıl fikri bana o iki ok verdi. Bütçe yukarıdan aşağı tahsis ediliyor, emek aşağıdan yukarı toplanıyor. YTR-1042’ye ayrılan tutar yukarıda belirleniyor, ama o kalemin gerçekte ne tükettiği en alttaki kayıtların toplamı. Direktörümün finansa anlatacağı hikâye de o iki sayının farkındaydı, tek bir sayıda değil.

İlk kurduğum bağ yanlıştı

Betiğin ilk sürümünde katları issue link ile bağladım. Jira’da hazır duruyordu zaten: “relates to”, “is part of”, “blocks”. İki hafta sonra rapor saçmalamaya başladı.

Sebep basit: link tipi serbest. Herkes farklı tip seçiyor, biri unutuyor, biri ters yöne bağlıyor. Benim betik beş farklı link tipini geziyordu ve zincirin ortasındaki bir kayıt koptuğu anda altındaki bütün emek sahipsiz kalıyordu. Bir epikte 60 adam gün buhar oldu, fark etmem üç gün sürdü.

İkinci sürümde linki tamamen bıraktım. Yerine ikinci kata zorunlu bir alan koyduk: Yatırım Kodu. Geliştirme epiği açılırken doldurulacak, boş bırakılamayacak. Üçüncü ve dördüncü katın doldurmasına gerek yok, bağlı olduğu epikten miras alıyor.

İş akışına da tek bir kural yazdık: bir epik, yatırım kodu boşken “Geliştirmede” statüsüne geçemiyor. Analizde serbest, geliştirmeye girerken zorunlu. Bu tek kural, raporu sonradan elle temizleme ihtiyacını neredeyse tamamen bitirdi.

Yine de bazı kayıtlar sahipsiz kaldı, ilk refleksim de onları rapordan atmak oldu. Direktörüm itiraz etti ve haklıydı: sahipsiz satırlar rapordan sessizce düşmez, “atanmamış” başlığı altında toplanıp gösterilir. Bir rapor, kapsadığı kadar kapsamadığını da söylediği için güveniliyor. “Bu ay 1.240 adam günün 96’sı hiçbir projeye bağlanamadı” cümlesi, o 96 günü sessizce yok saymaktan kat kat değerliydi.

Adam günü nereden bulacaktım

Ağaç kuruldu ama ağacın taşıyacağı sayı hâlâ yoktu. Üç yol denedim, üçü de aynı derecede kusurlu.

Worklog. En doğrusu buydu, uygulanmayanı da buydu. İnsanlar zaman girmiyordu; girenler de cuma öğleden sonra toplu ve tahminî giriyordu. Bir ay boyunca worklog disiplinini yukarıdan zorlamayı denedik. Veri düzelmedi, sadece uydurma veri düzenli hâle geldi.

Story point üzerinden dönüşüm. Ekibin geçmiş hızından bir katsayı çıkardım; ödeme ekibinde 1 puan yaklaşık 0,6 adam güne denk geliyordu. Çalıştı, ama ekipler arasında karşılaştırma yapamıyordum, çünkü puan ekibe özel bir ölçü. Bir ekibin 8 puanı diğerinin 3 puanı olabiliyor; bu bir arıza değil, puanın doğası bu. İlk sürümde dokuz ekip için tek bir ortalama katsayı kullanmıştım, o rapor da iki ekibi haksız yere pahalı gösterdi. Katsayı ekip bazında kalmalı, asla ortalamaya indirgenmemeli.

Planlanan adam günü elle girmek. Ürün yöneticisi ya da ekip lideri yatırım kalemine “bu iş yaklaşık 40 adam gün” yazıyor. O sayı da genelde yıl sonundaki yol haritası çalışmasından geliyor. Tahmin olarak değerli, gerçekleşen olarak hiçbir işe yaramıyor.

Sonunda ikisini birden tuttum: planlanan adam gün yukarıda, gerçekleşen adam gün aşağıdan toplanarak. Finansın istediği de tek bir sayı değildi, ikisi arasındaki sapmaydı. YTR-1042 için 40 gün planlanmıştı, 63 gün gitti. O %58’lik sapma bir başarısızlık değil, bir bilgi. Sapmanın nereden geldiğini ağacın alt katlarında gösterebildiğim gün sistemin çalıştığına ikna oldum.

Ayda 22 gün diye başladım, tutmadı

İlk tam raporu çıkardığımda kapasiteyi takvimden almıştım: ayda 22 iş günü. Rapor bütün ekipleri planın çok gerisinde gösterdi. Ekip liderleri de haklı olarak itiraz etti.

Oturdum, bir ekibin bir ayını tek tek çıkardım. Yıllık izin, resmî tatil, eğitim, işe alım görüşmeleri, ekip toplantıları, canlı ortam desteği, başka ekiplere verilen danışmanlık, idari işler… Hepsi düşüldüğünde bir geliştiricinin aylık net üretim kapasitesi 15 ile 18 gün arasında kalıyordu.

Bu farkı ihmal ettiğiniz anda bütçeyi baştan %20 yanlış kuruyorsunuz. 12 kişilik bir ekip için ayda 22 gün varsayımı yılda 3.168 adam gün veriyor, 17 gün varsayımı 2.448. Aradaki 720 adam gün, planlamada var sandığınız ama hiçbir zaman elinize geçmeyecek bir kapasite. Bütçe toplantısında ekiplerin sürekli geç kalıyor görünmesinin sebebi de çoğu zaman yavaş çalışmaları değil, işte bu varsayım.

Birim maliyet tarafında da bir tartışma çıktı. Finans kişi bazlı maliyet istiyordu, ben ekip bazlı önerdim ve ısrar ettim: maliyet ekip bazında tutulmalı, kişi bazında değil. Ekip başına karma bir gün maliyeti belirliyorsunuz; ödeme ekibinde 1 adam gün 18 birim, veri ekibinde 24 birim. Kişi bazlı maliyet hem kişisel veri tarafında sorun çıkarıyor hem de rapor bir şekilde dolaşıma girdiğinde (ki mutlaka giriyor) ekip içinde onarması zor bir huzursuzluk bırakıyor. Karma oran hem yeterince doğru hem de paylaşılabilir.

Raporun asıl işi kasımda başladı

Bunu ay başı raporu diye kurmuştum. En çok işe yaradığı ay ise ocak değil kasım oldu.

Kurumsal takvim şöyle işliyor: her yıl kasım aralık aylarında sonraki yılın yol haritası hazırlanıyor, büyük projeler için efor tahminleri çıkarılıyor, bu tahminler finansa onaylatılıyor. Onay da sadece bütçe onayı değil. Efor eldeki kapasiteyi aşıyorsa kaynak ihtiyacı da o masada konuşuluyor: yeni geliştirici alımı, tedarikçi kullanımı, bir projenin çeyrek kaydırılması, kapsamın kısılması. Yılın nasıl geçeceği büyük ölçüde o iki ayda belli oluyor.

O masaya o güne kadar tek bir dayanakla gidiliyordu: deneyim. “Bu iş üç ayımızı alır” cümlesinin arkasında bir kayıt yoktu, benzer bir işi hatırlayan birkaç kişi vardı. Tahmin de bu yüzden ne savunulabiliyor ne sorgulanabiliyordu.

Rapor kurulduktan sonra kasımda önümüze koyduğumuz her tahminin yanında iki sayı durdu: aynı kategorideki geçen yıl işlerinin planı ve gerçekleşeni. “Yeni yetenek işlerini ortalama %40 sapmayla kapattık” cümlesi tahmini değiştirmiyor, kullanılabilir hâle getiriyor. 40 adam gün yazdığınız kalemin 56 günle kapanma ihtimalini onay masasında konuşabiliyorsunuz.

Kaynak ihtiyacı tarafında hesap daha da doğrudan. Yol haritasının toplam eforunu net kapasiteyle karşılaştırıyorsunuz: 12 kişilik ekipte yılda 2.448 adam gün var, yol haritası 3.100 gün istiyor. Aradaki 650 gün ya işe alım, ya tedarikçi, ya da kapsam kararı. Bu üçünü kasımda konuşmakla mayısta konuşmak arasında ciddi fark var.

Bir de şu oldu: ay başı raporu geçmişin dökümü olmaktan çıkıp kasımda verilen sözün tutarlılık kontrolüne dönüştü. Plan ile gerçekleşen aynı ağaçtan çıktığı için bir kalemin plandan sapması yıl sonunu beklemiyordu. Nisanda gördüğünüz sapma, kasımda yazılmış bir tahminin geri bildirimi: hem o kaleme müdahale şansı, hem sonraki kasım için biriken bilgi.

Süreleri changelog’dan okudum

Raporun ikinci yarısı, yani statü kırılımı, bir para sorusu değildi. Finans o kısma bakmayacaktı bile. Bizim sorumuzdu: bir talep açıldığından teslim edildiğine kadar gerçekte ne kadar sürüyor ve o sürenin ne kadarında gerçekten iş yapılıyor.

Kayıtların üstünde “başlangıç tarihi” diye bir alan vardı. Bir öğleden sonra örnekleyerek kontrol ettim: yarısı boş, dolu olanların bir kısmı da kaydın açılış tarihiyle aynı. Elle doldurulan her alan bir süre sonra yalan söylemeye başlıyor. Changelog ise kimsenin geriye dönüp düzeltemediği tek yer; o yüzden bütün süre hesabını statü geçmişinin üstüne kurdum.

Betiğin ölçtüğü temel süreler şunlardı:

Burada iki hata yaptım, ikisi de rapora yansıdı.

Birincisi: cycle time’ı tek bir aralık olarak hesapladım. Kurumsal süreçte iş geri dönüyor; UAT’ten geliştirmeye düşüyor, tekrar teste çıkıyor, tekrar düşüyor. Ben “geliştirmeye ilk giriş” ile “son teslim” arasını ölçtüğüm için aradaki bütün bekleme sürelerini geliştirme süresi saymışım. Ekip liderlerinden biri bunu bir toplantıda tek bir örnekle çürüttü. Doğrusu, her statüde geçirilen süreyi kümülatif toplamak: iş geliştirme statüsüne dört kez girdiyse dördünün toplamı gerçek geliştirme süresi.

İkincisi: iptal ve dondurma sürelerini ham süreden düşmemiştim. Sonrasında iki ayrı lead time tuttum: ham lead time (açılıştan teslime, her şey dâhil) ve düzeltilmiş lead time (iptal, beklemede ve teslim sonrası süreler çıkarılmış). Yönetime anlatılan hikâye de çoğu zaman bu ikisinin farkından çıktı. “Bu talep 94 gün sürdü ama 41 günü bizde bekledi, 53 günü tedarikçi onayında geçti” cümlesi, tek başına 94 sayısından çok daha fazlasını anlatıyor.

Kapanmış işlere bakmak beni yanılttı

Betiğin ilk sürümü sadece kapanmış kayıtları topluyordu, çünkü süre hesabı için bitiş tarihine ihtiyacım vardı. Çıkan rapor süreci olduğundan hızlı gösteriyordu ve ben bir süre buna sevindim.

Sonra kafama dank etti: kapanmış işler, tanımı gereği bitebilmiş işler. Zor olanlar hâlâ açıktı ve raporda hiç görünmüyordu. Bu yanılgı, ölçmediğiniz sürece ay ay büyüyor.

Çözümü basitti: açık kayıtlar için de süre hesaplanacak, bitiş tarihi yerine bugünün tarihi konarak. Böylece raporda “ortalama teslim süresi 38 gün” cümlesinin yanına “hâlâ açık 61 kaydın ortalama yaşı 112 gün” cümlesi de geldi. Toplantılarda ikinci cümle birincisinden çok daha fazla konuşuldu.

Finansın üç sorusu aynı veriden çıktı

Ağaç kurulduktan sonra finans tarafının aslında üç soru sorduğunu gördüm; üçü de aynı veriden çıkıyordu.

Ne harcadık. Toplam adam gün çarpı ekip birim maliyeti, yatırım kalemi bazında toplanıyor. Rapordaki en üst satır bu.

Nereye harcadık. Kırılım burada devreye giriyor. Yatırım kalemlerini kategoriye ayırdık: yol haritası işleri, plan dışı gelen talepler, önceki yıldan devreden işler, zorunlu uyum işleri ve bakım. Bu kırılım olmadan “teknoloji bütçesinin %60’ı yol haritasına gitti” gibi bir cümle kuramıyorsunuz; o cümle kurulamayınca da bütçe tartışması sayılarla değil hislerle yürüyor.

Aktifleştirilebilir mi. Muhasebe tarafında en hassas soru buydu. Yeni bir yetenek geliştirmek genelde aktifleştirilebiliyor, bakım ve hata düzeltme gider yazılıyor. Bu ayrımı önce etiketle yönetmeyi denedim, kesin yoldan battı: etiket serbest metin ve altı ay içinde on farklı yazımı ortaya çıkıyor. Doğrusu, yatırım kaleminde kapalı listeli bir yatırım tipi alanı tutmak ve alt katların bu tipi miras alması. İstisna gerekiyorsa istisna açıkça işaretleniyor, varsayılan miras kalıyor.

Bir de dönemsellik meselesi vardı; onu tam da ilk raporu göndereceğim hafta fark ettim. Direktörümün istediği satırlardan biri “hangi proje hangi ay kapandı” idi ve ben ilk sürümde maliyeti de o aya yazmıştım. Yanlıştı. Kapanış ayı bir bilgi, maliyetin ayı başka bir bilgi. Maliyet, işin bittiği aya değil, emeğin harcandığı aya yazılmalı. Ocakta başlayıp haziranda biten bir proje, haziran ayının gideri değil. Worklog olsa bu sorun kendiliğinden çözülürdü. Olmadığı için yaklaşık bir yöntem kullandım: kaydın geliştirme statüsünde geçirdiği süreyi aylara bölüp adam günü o oranda dağıtmak. Kusurlu ama tek kalemde haziranı şişirmekten çok daha doğru.

Rapor bordroyla tutmadı

Raporu direktörüme götürdüm; ilk yaptığı şey sayıyı bordroyla karşılaştırmak oldu. Bir Jira raporunun doğruluğunu sınamanın tek pratik yolu da bu.

Ekip 10 kişiydi, aylık net kapasite 17 gündü; yani o ekipten ay içinde 170 adam gün çıkması bekleniyordu. Benim raporum 118 gün gösteriyordu. Aradaki 52 günü açıklamak zorunda kaldım.

Bir hafta ekiplerle konuşarak nereye gittiğini buldum: kaydı hiç açılmamış canlı ortam destekleri, başka ekibe verilen yardım, kayda geçmemiş toplantı ve analiz zamanı, bir de kimsenin bilmediği ama herkesin yaptığı küçük işler.

Bu farkı gizlemek yerine rapora ayrı bir satır olarak koyduk: “Kayıt dışı kapasite: %31”. İlk ay can sıktı, ikinci ay tartışma başlattı, üçüncü ayda düşmeye başladı. Ölçülmediği sürece hiç düşmüyor.

Jira tarafında ne kurduk

Bütün bu hikâyenin Jira’daki karşılığı şaşırtıcı derecede sade çıktı. Aşağıdaki alanlar yetti.

Bunun yanında iki yapısal karar aldık.

Statü şeması ortak olmalı, en azından eşlenebilir olmalı. Dokuz ekip kendi iş akışını kurunca süreler karşılaştırılamaz hâle geliyor. Ekiplerin kendi ara statüleri olması sorun değildi, ama her statünün ortak bir faza eşlenmesini şart koştuk: kuyruk, analiz, geliştirme, test, bekleme, kapanış. Betik statü üzerinden değil faz üzerinden çalışıyordu. Bir ekip yeni statü eklediğinde rapor bozulmadı.

Kapalı liste her zaman etiketten iyi. Etiketle yönetilen hiçbir alan iki yıl yaşamıyor. Bizde Roadmap2026, roadmap-2026, RM2026 ve Roadmap_2026 aynı anda vardı; ilk sürümde bunları birleştirmek için kod yazmıştım. Kapalı listeye geçince o kod da çöpe gitti, iyi de oldu.

Tek rapor değil, iki rapor

Betiğin ilk çıktısı tek bir sayfaydı ve içine bulduğum her şeyi koymuştum: proje, adam gün, statü süreleri, sapma, hepsi yan yana. Direktörüm baktı ve şunu dedi: “Bu bir tablo, rapor değil. Finans buradan kendi sayısını çıkaramaz.”

Haklıydı. Baştan beri iki ayrı okuyucu vardı, ben ikisini tek sayfada birleştirmeye çalışıyordum. Çıktıyı ikiye böldüm.

Finans katmanı, proje başına tek satır. Proje, sahibi, kategorisi, kapandıysa kapanış ayı, planlanan ve gerçekleşen adam gün, sapma. Statü adı yok, süre yok. Otuz kırk satır, tek ekran. Finansın ihtiyacı bundan ibaretti.

IT katmanı, aynı projelerin altındaki epikler ve görevler. Her satırda hangi statüde ne kadar durduğu, kaç kez geri döndüğü, hangi ekipte olduğu. Bu katmanı finansa hiç göndermedik, kendi içimizde kullandık.

Aradaki bağın şartı da şu: finans katmanındaki bir sapmanın sebebi, IT katmanında en fazla iki adımda bulunabilmeli. “YTR-1042 neden 63 gün oldu” sorusunun cevabı “çünkü ODM-3310 epiği UAT’ten üç kez döndü ve 22 gün beklemede kaldı” olabildiği gün rapor işini yapmaya başladı. Bulunamıyorsa elinizde rapor yok, gerçekten tablo var.

Geriye bakınca hata dediğim şeyler

Ölçüyü performans karnesine çevirmek. Rapor işlemeye başladıktan birkaç ay sonra beklediğim teklif geldi: cycle time kişi bazında görülsün, performans değerlendirmesine girsin. Karşı çıktım, bugün de aynı şeyi söylerim. Cycle time kişi bazında ölçülüp değerlendirmeye girdiği anda insanlar Jira’yı yönetmeye başlıyor. Kayıtlar erken kapatılıyor, iş küçük parçalara bölünüp sayı şişiriliyor, zor işler kaydı hiç açılmadan yapılıyor. O andan itibaren elinizdeki veri süreci değil, insanların rapordan korunma refleksini ölçüyor. Ölçü sürecin ölçüsü, kişinin değil. Bu ayrımı kaybeden her sistemin altı ay içinde ölü veri üretmeye başladığını gördüm.

Tek ekipte mükemmel, kurumda işe yaramaz kurulum. İlk pilotu tek bir ekiple yaptım, harika çalıştı: alanlar dolu, süreler temiz. Diğer sekiz ekibe açtığımda o ekiple hiçbir ortak noktaları olmadığı ortaya çıktı. Ortak olması gereken az sayıda şey var, onlar merkezden kurulmalı; geri kalanında ekipler serbest kalmalı.

Excel’de elle doldurulan alan bırakmak. Raporun iki sütununu “sonra otomatikleştiririm” diyerek geçici olarak elle bıraktım. Üç ay sonra ikisi de boştu. Elle doldurulacak bir bilgi varsa yeri rapor değil, kaydın kendisi.

Geçmişi geriye dönük düzeltmeye çalışmak. İlk refleksim son iki yılın kayıtlarını temizlemekti. İki hafta harcadım, hiçbir yere varamadım. Doğrusu, bir kesme tarihi koyup o tarihten sonrasını doğru toplamak. Geçmiş için kaba bir tahmin yeterli; kimse üç yıl önceki adam günü gerçekten merak etmiyor.

Sonunda ne oldu

İlk raporu ayın üçünde gönderdik, sonraki aylarda da ayın üçünde gitti. Rapor artık birinin oturup yazdığı bir Excel dosyası değildi; her ay başı kendini yeniden üreten iki sayfaydı ve içindeki her sayının hangi kayıttan geldiğini gösterebiliyordunuz.

Bütün işin özü de tek cümleye indi: finansın konuştuğu birim ile ekiplerin çalıştığı birim arasına, kimsenin elle doldurmadığı bir köprü kurmak. Köprü kurulunca adam gün de, lead time da, aktifleştirme raporu da aynı veriden kendiliğinden çıkıyor. Kurulmayınca her ay aynı Excel yeniden yazılıyor ve kimse ona güvenmiyor.

Kurumsal tarafta bu köprüyü kurmuş bir yapı gördüyseniz ya da denediğiniz farklı bir kırılım varsa duymak isterim.