SOP'tan yazılıma: İlk yapımdan önce süreci haritalayın

İlk sürümde SOP'lar neden başarısız olur

Yazılı bir SOP açık ve eksiksiz görünebilir, ama gerçek işler nadiren o kadar düzenlidir. Doküman ne olması gerektiğini gösterir. İnsanların baskı altındayken, eksik bilgi beklerken veya acil bir talebi hallederken gerçekten nasıl davrandığını genellikle kaçırır.

Bu fark, birçok SOP'tan yazılıma projesinin erken aşamada tökezlemesinin nedenidir. İlk versiyon sıklıkla dokümana fazla bağlı kalır. Sonra ekip, günlük operasyonların asla yazıya geçirilmemiş çözümlere, yan konuşmalara ve takdir kararlarına dayandığını keşfeder.

Gizli istisnalar sıkça işleri bozan sebeptir. Bir SOP "Yönetici 1.000$ üzerindeki talepleri onaylar" diyebilir, ama yönetici yoksa, tutar iki talebe bölündüyse ya da müşteri aynı gün cevap istiyorsa ne olur? Bu gibi küçük durumlar tüm iş akışını şekillendirebilir.

Onaylar başka bir zayıf noktadır. Kağıt üzerinde akış temiz ve doğrusal görünür. Gerçekte insanlar onayları e-posta, chat, toplantı veya kısa bir telefon görüşmesiyle verir. İlk yapı bunu görmezden gelirse, uygulama yavaş ve gerçek dışı hisseder çünkü kararların gerçekten nasıl alındığıyla örtüşmez.

Veri problemleri de hızla ortaya çıkar. Bir SOP adımları tanımlayabilir ama kullanıcıların bunları tamamlamak için hangi alanlara gerçekten ihtiyaç duyduklarını yazmayabilir. Yeni aracı açan kullanıcılar notları, tarihleri, istisnaları veya referans numaralarını takip etmek için hâlâ bir tabloya ihtiyaçları olduğunu fark ederler.

Genel desen basittir. Doküman niyeti yakalar, günlük davranışı değil. Uç durumlar nadir olaylar gibi ele alınır hâlbuki her hafta yaşanıyor olabilirler. Onay yolları yazılı sürecin dışında yaşar. Ana alanlar eksik olduğu için insanlar yan sistemler yaratır.

Bir satın alma talebi SOP'sini ele alın. Gönder, incele, onayla ve öde adımlarını listeleyebilir. Ama gerçek süreç tedarikçi durumunu kontrol etmeyi, finans'tan bütçe kodu sormayı ve acil siparişleri işaretlemeyi de içerebilir. Bu detayları atlayın, yazılım insanlar kullanmaya çalışana kadar tamamlanmış görünür ama kullanışsız olur.

Ama amaç SOP'u satır satır kopyalamak değildir. Amaç arkasındaki gerçek süreci yakalamaktır.

Dokümandan önce ne çıkarılmalı

Ekranlar veya otomasyonlar hakkında düşünmeden önce ham süreç gerçeklerini çıkarın. İyi bir SOP'tan yazılıma dönüşüm işi, tasarım fikirleriyle değil iş sırasıyla başlar.

Dokümanı bir kez genel resmi görmek için okuyun. Sonra tekrar okuyup gerçek iş sırasını işaretleyin. Adımları sırayla yazın, bariz görünseler bile. Yazılım tanımladığınız yolu izler, bu yüzden küçük detaylar önemlidir.

Her adım için dört şeyi not edin: ne oluyor, kim yapıyor, ne kullanıyor veya oluşturuyor ve bir sonraki adımın başlaması için ne doğru olmalı. Bu belirsiz bir dokümanı gerçekten inşa edilebilen bir şeye dönüştürür. Eğer iki kişi SOP'u okuduğunda akışı farklı tarif ediyorsa, süreç hâlâ hazır değildir.

Sonra tetikleyiciyi ve bitiş çizgisini işaretleyin. Her süreç bir yerde başlar: gönderilen bir form, bir müşteri talebi, bir yönetici e-postası veya planlanmış bir tarih. Her süreç bir yerde biter: onaylandı, reddedildi, sevk edildi, ödendi, arşivlendi veya devredildi.

Gerçek başlangıcı veya sonu atlarırsanız, uygulama bitmiş görünse de günlük kullanımda başarısız olabilir. Bir talep onay aracı, yönetici onay butonuna tıkladığı için bitmiş sayılmaz. O onaydan sonra ne olacağı ve sonraki görev kimin sorumluluğunda bilmeniz gerekir.

Daha sonra her adımda kullanılan materyalleri toplayın. Bunun içinde formlar, tablolar, PDF'ler, e-postalar, yüklenen dosyalar, notlar ve bir yerden diğerine kopyalanan veriler bulunur. Bu detaylar uygulamanın hangi girdi alanlarına ihtiyaç duyduğunu ve hangi kayıtları saklaması gerektiğini gösterir.

Basit bir inceleme tablosu burada işe yarar. Beş sütun kullanın: adım numarası, sahibi, tetikleyici, girdiler ve sonuç. Bu genellikle ilk yapı başlamadan önce eksik parçaları ortaya çıkarır. Eğer süreci Koder.ai'de taslaklıyorsanız, bu tür bir taslak yazılı prosedürü çalışan bir web veya mobil uygulamaya dönüştürmek için çok daha iyi bir başlangıç sağlar.

SOP'u iş akışına nasıl çevirirsiniz

Sözcükleri düzeltmeye çalışmadan SOP'u okumaya başlayın. Göreviniz üç şeyi bulmaktır: tetikleyici, eylemler ve bitiş noktası. Bunları bir cümleyle tarif edemiyorsanız, süreç hâlâ çok belirsizdir.

İyi bir iş akışı "müşteri bir talep gönderir" veya "yönetici bir faturayı alır" gibi net bir tetikleyiciyle başlar. "Talep onaylandı ve planlandı" veya "fatura ödendi ve arşivlendi" gibi görünür bir sonuçla biter. Aradaki her şey gerçekten birinin gerçekleştirdiği bir adım olmalıdır.

Çoğu SOP bir paragrafta birkaç eylemi saklar. O paragrafları tek eylemlere ayırın. Bir cümle "Formu inceleyin, bütçeyi onaylayın ve finansa bildirin" diyorsa, bu bir adım değil üç adımdır. Her biri farklı bir sahip, durum veya zaman sınırına ihtiyaç duyabilir.

"Eğer", "olmadıkça" veya "gerekirse" gibi kelimeler gördüğünüzde bunları evet-hayır kararlarına dönüştürün. Bu iş akışını oluşturmayı ve test etmeyi kolaylaştırır. "Limitin üzerindeyse yöneticiyi gönder" demek yerine dalı şöyle yazın: "Tutar limitin üzerinde mi? Evet - yöneticiyi gönder. Hayır - finansa devam et."

Dili sade tutun. Her adım için bir kural yazın. "Satış müşteri adını ekler" cümlesi "Müşteri verisi alım sırasında yakalanır" demekten çok daha iyidir. Net ifade, süreç haritalamadan gerçek bir yapıya geçişte hataları azaltır.

Küçük bir iş akışı taslağı beş sütuna sığabilir: tetikleyici, adım, sahip, karar ve sonuç. Bu basit yapı hızla boşlukları ortaya çıkarır. Eksik bir onay, belirsiz bir devralma veya SOP'un adını bile vermediği bir bilgiye bağımlı bir adım fark edebilirsiniz.

Hiç kimse inşa etmeden önce taslağı günlük işi yapan kişilerle birlikte yürütün. Gecikmelerin nerede olduğunu, hangi şeylerin atlandığını ve SOP gerçeğe uymadığında insanların ne yaptığını sorun. Bu detaylar cilalı ifadelerden daha önemlidir.

Çoğu ilk yapı burada yanlış gider. Doküman tamam görünebilir ama gerçek süreç alışkanlıklarda ve istisnalarda yaşar. Ekibiniz taslağı baştan sona ekstra açıklama olmadan takip edebiliyorsa, iş akışı gereksinimlerini tanımlamaya hazırsınız. Eğer hâlâ "bir tane daha şu var" diyorsa, taslağı geliştirmeye devam edin.

İstisnaları erken nasıl yakalarsınız

Çoğu süreç dokümanı iyi yolu tanımlar. Gerçek işler nadiren uzun süre o yol üzerinde kalır.

İlk sürümün günlük operasyonlarla eşleşmesini istiyorsanız, her adımda farklı bir soru sorun: bu planlandığı gibi gitmezse ne olur? SOP'tan yazılıma çabalarda yeniden işin çoğu buradan başlar.

Eksik bilgiyle başlayın. Bir form müşteri kimliği, fatura numarası veya yönetici adı olmadan gelirse iş durur mu, gönderene geri mi gider yoksa uyarıyla mı devam eder? Böyle küçük bir kural ekranları, bildirimleri ve durum etiketlerini değiştirir.

Acil vakalar da kendi yoluna ihtiyaç duyar. Ekipler genelde "normalde onay beklenir" der, ama acil talepler telefon, chat veya üst düzey yönetici tarafından hızlıca yürütülebilir. Manuel geçersiz kılmalar varsa kimlerin kullanabileceğini, ne zaman izinli olduğunu ve sonrasında hangi kaydın tutulması gerektiğini yazın.

Bir diğer yaygın istisna atlanan adımdır. Bazı talepler düşük tutar, tekrar sipariş, sözleşme türü veya müşteri seviyesinden dolayı normal onayı atlayabilir. Bu kuralı kaçırırsanız, ilk versiyon kullanıcılar için yavaş ve yanlış hissedilir.

İstisnaları keşfetmenin basit yolu her adımda aynı dört soruyu sormaktır:

• Gerekli bilgi eksikse ne olur?
• Bu durumu acil yapan nedir?
• Birisi bu adımı ne zaman atlayabilir veya geçersiz kılabilir?
• Çalışmanın reddedilmesine, iade edilmesine veya takılmasına ne sebep olur?

İşin takıldığı devralmalara yakından bakın. Öğeler genellikle sahiplik belirsiz olduğu için bir gelen kutusunda bekler, biri eksik bir alanı bekliyordur veya bir inceleyen görevi net bir gerekçe olmadan geri gönderir. Bu anların uygulamada görünür durumlar olarak yer alması gerekir, gizli yan konuşmalar değil.

Bir gider onayı SOP'sini düşünün. Normal yol gönder, incele, onay, geri ödeme olabilir. Ama gerçek istisnalar makbuz eksikliği, aynı gün yolculuk, küçük tutarlar için atlanan onaylar ve maliyet merkezinin yanlış olmasından dolayı iade edilen talepleri içerebilir. Bu durumları inşa öncesi yakalarsanız, ilk versiyon günlük operasyonlara daha yakın hisseder ve lansmandan sonra daha az düzeltme gerektirir.

Onaylar, sahipler ve devralmalar

Bir görev sahibinin net olmadığı yerde süreç bozulur. SOP'daki her adım için onu ilerletmekle sorumlu bir kişi veya rol tanımlayın. Mesaja kopyalanan kişiler değil. "Genelde yardımcı olan kişi" değil. Harekete geçmesi gereken tek sahibin kim olduğu net olmalı.

Sonra üç yetki türünü ayırın: kim onaylayabilir, kim reddedebilir ve kim düzenleyebilir. Bunlar genellikle farklı kişilerdir. Finans lideri harcamayı onaylayabilir, operasyon yöneticisi eksik talepleri reddedebilir, bir koordinatör detayları düzenleyebilir ama imza yetkisi olmayabilir.

Onay akışı tasarımı yapıyorsanız, belirsiz ifadelerin kötü yapılar ürettiği yer burasıdır. "Yönetici inceler" veya "ekip onaylar" gibi ifadeler yazılım için çok gevşektir. Uygulama hangi rolün görevi gördüğünü, hangi butonları göreceğini ve her seçimden sonra ne olacağını bilmek zorundadır.

Her devralma için ayrıca bir tetikleyici olmalıdır. İş, bir formun tamamlanması, bir belgenin yüklenmesi veya bir onayın verilmesi gibi belirli bir şey gerçekleştiği için bir sonraki kişiye geçmelidir. Bu tetik belirsizse, görev beklemede kalır veya kişiler arasında gidip gelir.

İyi bir devralma tanımı; mevcut adımı bitiren olay, sonraki sahibi, durum değişikliği, gerekli notlar veya ekler ve sonraki işlem için son tarihi içerir.

Zamanlama kurallarını erken ekleyin. Bir görev atandığında kim uyarılır, hatırlatmalar ne zaman gider ve geciken öğeler ne zaman yükseltilir kararını verin. Basit bir iş akışı bile doğru kişi doğru mesajı aldığında daha iyi çalışır.

Küçük bir örnek: Eğer bir satın alma talebi 5.000$ üzerindeyse departman liderinden finans direktörüne gidebilir. Eğer tedarikçi teklifi eksikse, talep isteyene düzenleme için geri döner. Bu tek dal sahip, onay yetkilerini, reddetme yolunu ve devralma koşullarını inşa edilebilir şekilde tanımlar.

Gerçekten ihtiyaç duyduğunuz veri alanları

Ekipler genellikle çok fazla veri topladıklarında ilk yapı karmaşıklaşır. İşi tamamlamak için gereken alanlarla başlayın, ileride faydalı olabilecek her detayla değil. Bir alan bir adı tanımlamalı, birinin sonraki adımı ne yapacağına karar vermesine yardımcı olmalı veya görevin tamamlandığını kanıtlamalıdır.

Önce olmazsa olmaz alanlar

Alanları iki gruba ayırın: olmazsa olmaz ve iyi olur. Olmazsa olmaz alanlar eksikse süreç durur. İyi olur alanlar ileride analiz için yardımcı olabilir ama ilk sürümü engellememelidir.

Pratik bir veri alanları kontrol listesi bazı soruları yanıtlamalı: Süreci başlatmak için neler girilmeli? Her adımın devamı için ne gerekir? Bir yönetici onay veya reddetme için hangi bilgilere ihtiyaç duyar? Sistem denetim veya raporlama için ne saklamalı? Hangi alanlar sonraya bırakılabilir?

Sonra her alanı kullanıldığı tam yere eşleyin. Eğer satın alma tutarı onayı etkiliyorsa, o karar adımında yer almalı. Bir sözleşme dosyası hukuki incelemeden önce gerekli ise, onu sürecin devredildiği noktada isteyin, en başta değil.

Format beklediğinizden daha fazla önem taşır. Bir alanın tarih, tutar, dosya yükleme, açılır liste, onay kutusu veya serbest metin olup olmadığını yazın. Bu, sonradan tarihler farklı biçimlerde girilmesi veya para biriminin ondalık olmadan yazılması gibi tanıdık sorunları önler.

Ayrıca ekiplerin alışkanlıkla takip ettiği kuralları yakalayın. Fatura numarası benzersiz olmalı mı? Tutar sıfırdan büyük olmalı mı? Bir ek, toplam belirli bir limitin üzerindeyse mi gerekli? Bunlar SOP adında açıkça yazmasa bile doğrulama kurallarıdır.

Son olarak, takımlar arasındaki tekrar veri girişlerine dikkat edin. Satış bir müşteri adını girip finansın sonra yeniden yazması varsa, iki kayıt yerine tek bir kaydı yeniden kullanmak gerekir. Pratikte küçük veri hataları günlük rahatsızlığa dönüşür. Temiz alan seçimi iş akışını daha kolay, daha hızlı ve gerçek operasyonlara daha yakın yapar.

Bir SOP'den basit bir örnek

Diyelim küçük bir şirket dizüstü, monitör ve benzeri ekipmanı e-posta ve tablolarla satın alıyor. SOP kağıt üzerinde açık görünebilir ama gerçek görev, bu adımları insanların tahmin etmeden kullanabileceği bir şeye dönüştürmektir.

Temel yolla başlayın. Bir çalışan talep açar ve üç temel bilgiyi girer: ürün, tahmini maliyet ve satın alma nedeni. Bu alanlar tamamlanana kadar talep ilerlememelidir çünkü sonraki adımları bunlar şekillendirir.

Sonra yönetici inceler. Talep mantıklıysa yönetici onaylar ve finansa gönderir. Bir şey eksik veya belirsizse yönetici notla geri gönderir, çalışan talebi günceller; baştan yeni bir talep açılmaz.

Finansın işi yöneticiinkinden farklıdır. Yönetici ihtiyacı kontrol eder; finans bütçeyi kontrol eder. Para varsa talep satın almaya gider. Yoksa reddedilebilir veya bir sonraki bütçe döngüsüne kadar bekletilebilir.

Yararlı kısım genellikle istisnalardadır. Yeni işe alınan birinin kırık bir dizüstü bilgisayarı acil değişim gerektirebilir. Bu durumda talep acil olarak işaretlenmeli ve normal sırayı atlamalıdır, ama yine de daha hızlı yolu onaylayan kişinin kaydını bırakmalıdır.

Bir diğer yaygın istisna eksik tekliftir. SOP belirli bir tutarın üzerindeki satın almalarda satıcı teklifi gerekli diyorsa, form bunu erken yakalamalıdır. Talebin finansa ulaşmasını ve orada başarısız olmasını beklemek yerine, sistem gönderim sırasında teklifi sorsun.

İlk yapı için anahtar alanlar muhtemelen basittir: ürün adı, maliyet tahmini, iş gerekçesi, aciliyet ve teklif eklenip eklenmediği. Bu örnek, sade bir dokümanın nasıl ekranlara, kararlara ve insanların her gün takip edeceği kurallara dönüştüğünü gösterir.

Projeyi yavaşlatan yaygın hatalar

Birçok ekip ilk kullanılabilir sürüm ortaya çıkmadan zaman kaybeder. Sorun genellikle SOP'un kendisi değil; insanların onu nasıl okuduğu, yorumladığı ve bir yapıya dönüştürdüğüdür.

Yaygın hatalardan biri, birinci sürüme her nadir senaryoyu dahil etmeye çalışmaktır. Bu dikkatli görünse de genellikle çok fazla ekran, kural ve karar noktası içeren karışık bir uygulama üretir. Daha iyi bir ilk sürüm ana yolu iyi işler, nadir durumları gerçek testlerden sonra ekler.

Bir diğer gecikme, dokümanı ticketlara kopyalayıp işi gerçekten yapanlarla konuşmamaktır. SOP'lar sıklıkla resmi süreci anlatır, gerçek süreci değil. Kağıt üzerinde bir adımı yönetici onaylıyor görünürken pratikte ekip onu hızlı bir chat veya paylaşılan gelen kutusuyla hallediyor olabilir. Bu konuşmaları atlarsanız, yazılım dokümana uyar ama işi yapmaz.

Politika dili de sorun yaratır. Birçok SOP iş kurallarını, uyum notlarını ve onay mantığını aynı paragrafta karıştırır. Bunların hepsini çok erken iş akışı kurallarına çevirmek uygulamayı takip etmesi zor hale getirir. Gerçek onay yolu ile arka plan politikayı ayırın. Sistem kimin neyi, ne zaman ve hangi koşulla onayladığını bilmelidir; birinci sürümde her politika cümlesi uygulanmak zorunda değildir.

Sürtünmeye dikkat edin, sadece mantığa değil

Ekipler ayrıca ilk günden çok fazla alan isteyerek kendi hızlarını keser. Form uzun olursa insanlar tahmin eder, atlar veya e-postaya geri döner. İşin ilerlemesini sağlayan, durum raporlayan ve kararları destekleyen alanlarla başlayın.

Birkaç basit soru yardımcı olur: Hangi alanlar bir eylem veya onayı tetikler? Hangi alanlar yalnızca iyi olur? İnsanlar hâlâ hangi bilgileri e-posta veya chat ile gönderiyor? Devralmalar bugün nerede başarısız oluyor?

Bu son soru birçok ekip için beklenenden daha önemli. Kullanıcılar hâlâ gelen kutusu dizileri, doğrudan mesajlar veya yan konuşmalara dayanıyorsa gerçek iş akışı SOP'un dışında gerçekleşiyor demektir. Bir talep dokümanda tamam görünse bile pratikte biri hâlâ bir ayrıntıyı açıklamak için mesaj atıyor olabilir. Uygulama o anı yakalamazsa gecikmeler devam eder.

Hızlı bir oluşturucu yardımcı olabilir, ama sadece süreç zaten netse. Koder.ai, haritalanmış süreci çalışır bir uygulama taslağına daha hızlı çevirmede faydalıdır, ama adımlar, onaylar ve alanlar önceden tanımlı olduğunda hız gerçekten işe yarar.

İlk yapı öncesi hızlı kontroller

Tüm süreç tek sayfaya sığdığında ilk sürüm çok daha iyi gider. Ne olduğunu açıklamak için uzun bir toplantıya ihtiyacınız varsa, akış hâlâ bulanıktır. Bir sayfa işin nerede başladığını, sonra neler olduğunu, kimlerin karar verdiğini ve sürecin nerede bittiğini göstermelidir.

Bu, SOP'tan yazılıma planı kullanılabilir hale getirmenin en hızlı yollarından biridir. Yeni bir ekip üyesi o sayfayı okuyup akışı size geri anlatabiliyorsa, doğru yöndesiniz. Adımlar, onaylar veya uç durumlar arasında kayboluyorlarsa inşa muhtemelen bir şeyi kaçıracak.

İnşa başlamadan önce beş temeli kontrol edin:

• Her adımın bir net sahibi olsun.
• Her karar noktasının bir sonucu olsun: reddetme, geri gönderme veya daha fazla detay isteği dahil.
• Yeniden iş yolları görünür olsun, notların içinde gizlenmesin.
• Zorunlu alanlar o adımda verilen kararı desteklesin.
• Gerçek bir kullanıcı taslağı ekstra açıklama olmadan takip edebilsin.

Sahiplik beklenenden daha önemlidir. "Finans inceler" demek üç farklı rolün bunu yapabileceği anlamına geliyorsa yeterli değildir. Gerçekten harekete geçen rolü isimlendirin.

Reddetme ve yeniden iş yolları da iyi yol kadar detaya ihtiyaç duyar. Bir talep eksikse kim düzeltir, ne değişir ve nereye geri gider? Birçok ilk sürüm yalnızca ideal durumu modellediği için başarısız olur.

Alanlarınız kararlarınıza uymalıdır. Bir yönetici bütçeye, departmana ve teslim tarihine göre onay verecekse, bu değerler yöneticinin eline ulaşmadan önce zorunlu olmalıdır. Aksi halde insanlar eksik bağlamla onay vermek zorunda kalır.

Basit bir test işe yarar: Gerçek bir kullanıcı yakın tarihli bir talebi baştan sona canlandırsın. Yardım almadan yapabiliyorsa, ilk yapı büyük olasılıkla gerçek operasyonlara dayalıdır. Yapamıyorsa sorun genellikle belirsiz kurallardır.

Kullanılabilir bir ilk sürüm için sonraki adımlar

En iyi ilk sürüm dar olandır. Bir süreç, bir ekip ve bir net hedef seçin. Yazılımın ilk gün her şeyi halletmesi gerekiyorsa proje genellikle kimsenin kullanamayacağı bir noktada takılır.

İyi bir hedef şöyle olmalı: "finans ekibi için satın alma taleplerini yönlendir" veya "müşteri işe alımını hesap yöneticileri için takip et". Bu, çözülecek gerçek bir problem verir ve SOP'tan yazılıma atlamayı çok daha kolaylaştırır.

Daha fazla özellik eklemeden önce taslağı geçen aydan gerçek örneklerle test edin. İdeal örnekler değil gerçek vakalar kullanın. Eksik talepleri, uzun süren onayları ve manuel müdahale gerektiren istisnaları inceleyin.

Bu inceleme genellikle en önemli boşlukları açığa çıkarır: eksik onay kuralları, devralmalarda belirsizlik, tanımsız veri alanları, alışılmadık vakalar için istisna yolları ve SOP'da olmayan ama pratikte var olan adımlar.

Önce bu kuralları düzeltin. Panolar, ek roller veya uç özellikler ekleme isteğine direnin. Kullanılabilir bir ilk sürüm yaygın yolu iyi idare etmeli ve en önemli istisnaları kafa karışıklığı olmadan çözmelidir.

Ayrıca gelen geribildirimlerle birlikte basit bir ikinci sürüm listesi tutmak yardımcı olur. Birisi "bunu da yapsa iyi olur" diyorsa not alın ve ana süreci engellemiyorsa ileri alın. Bu, birinci sürümü odaklı ve bitirmesi daha kolay tutar.

Eğer iş akışını zaten haritaladıysanız, Koder.ai bu taslağı web veya mobil için çalışır bir uygulama taslağına dönüştürmenize yardımcı olabilir. Ama yine aynı kural geçerlidir: süreç ne kadar netse, ilk yapı o kadar iyi gerçek operasyonlarla eşleşir.

İşte birinci sürüm için doğru bitiş çizgisi: net adımlar, net sahipler, doğru alanlar ve ekibin güveneceği kadar yapı.