Statement of Work Nedir? Kapsam, Kabul ve Riskler Rehberi

Statement of work nedir sorusunun kısa cevabı şu: Statement of work, kısaca SOW, bir hizmet sözleşmesinin hangi işin, hangi teslimatla, hangi tarihte, kim tarafından ve hangi bedelle yapılacağını anlatan kısmıdır. Bunu, hukuki temel hükümlerin altında duran proje düzeyindeki belge olarak düşünebilirsiniz. Sözleşmeler arasındaki "bu teslim edilmedi" tartışmalarının çoğu tam bu belgede kazanılır ya da kaybedilir.

SOW'da ne bulunur?

Bir SOW tek bir iş paketini tanımlar. İki şirket arasındaki bütün ilişkiyi düzenlemeye çalışmaz. İyi hazırlanmış olanlar genellikle aynı temel bloklardan oluşur.

• Kapsam: Tedarikçinin ne yapacağı, açık fiillerle, ve ne yapmayacağı.

• Teslimatlar: Somut çıktılar. Örneğin taşınmış bir veritabanı, bir marka rehberi ya da 40 saatlik destek.

• Zaman planı ve kilometre taşları: "Çeyrek sonunda" gibi belirsiz ifadeler yerine teslimatlara bağlı tarihler ya da süreler.

• Ücretler ve ödeme takvimi: Sabit fiyat, zaman ve malzeme ya da ikisinin karışımı, fatura tetikleyicileriyle birlikte.

• Kabul kriterleri: Müşterinin bir teslimatın tamamlandığına nasıl karar vereceği.

• Roller ve bağımlılıklar: Erişim, veri, onay ya da test ortamını kimin, ne zaman sağlayacağı.

• Değişiklik süreci: İş başladıktan sonra kapsam, fiyat ya da tarihlerin nasıl değiştirileceği.

Bu yapının gerçekte söylediği şey şudur: SOW, el sıkışarak anlaşılmış bir fikri, üçüncü bir kişinin okuyup doğrulayabileceği bir metne dönüştürür. Bu üçüncü kişi çoğu zaman bir hâkim, bir denetçi ya da projeyi devralan yeni bir çalışandır.

Bir SOW'un iyi yazılıp yazılmadığını anlamak için üç basit soru sorabilirsiniz. Birincisi, belgeyi okuyan biri projenin ne zaman bittiğini ve hangi çıktıların teslim edildiğini tahmin etmeden anlayabilir mi? İkincisi, ödenecek fiyatın hangi işe karşılık geldiği açıkça yazılmış mı? Üçüncüsü, iş değiştiğinde kimin neyi, hangi yolla onaylayacağı belli mi? Üç cevap da evetse belge büyük ihtimalle iyi iş çıkarmıştır. Biri hayırsa, o eksik bölüm imzadan önce tamamlanmalıdır.

SOW, MSA, teklif ve satın alma siparişi arasındaki fark nedir?

Karışıklığın kaynağı, bir anlaşmada birbirine yakın duran ve benzer görünen belgelerdir.

Master hizmet sözleşmesi (MSA), kalıcı hukuki şartları taşır: sorumluluk, fikri mülkiyet, gizlilik, kişisel verilerin korunması, fesih ve uygulanacak hukuk. Bir kez imzalanır. Her SOW bu sözleşmeye bağlanır ve tek bir projeyi kapsar. Bir MSA, yıllar içinde bir düzine SOW'u taşıyabilir.

Teklif bir satış belgesidir. Tedarikçinin ne yapmayı umduğunu ve neden seçilmeniz gerektiğini anlatır. Genellikle bağlayıcı değildir, ama sık sık SOW'un ilk taslağı olarak yeniden kullanılır. Sorun da burada başlar, çünkü pazarlama dili sözleşmeye girer.

Satın alma siparişi bir ödeme yetkisidir. Bir fiyat ve miktar belirtir, kapsamı nadiren anlatır. Hizmet projesinde yalnızca satın alma siparişine dayanmak işi tanımsız bırakır.

Tek seferlik bir iş için, SOW'un ek olarak yer aldığı tek bir birleşik sözleşme gayet yeterli olabilir. MSA ile SOW ayrımı, aynı tedarikçiden tekrar tekrar alım yapacağınızda değer kazanır.

MSA ile SOW çelişirse hangi madde geçerli olur?

Çoğu insanın atladığı soru budur ve para kaybettiren de bu sorudur.

İyi hazırlanmış sözleşmeler basit bir düzeni izler. MSA hukuki şartları yönetir. SOW kapsamı, takvimi ve ücretleri yönetir. Bir öncelik sırası maddesi bunu bir ya da iki cümleyle söyler ve çelişki olduğunda hangi belgenin geçerli olacağını belirtir.

Bu madde yoksa, bir mahkemenin belgeleri birlikte nasıl okuyacağına bağlı kalırsınız. Örneğin İngiliz hukukunda sözleşme belgeleri genellikle tek bir anlaşma olarak okunur. Dolayısıyla bir tutarsızlık kendiliğinden ortadan kalkmaz. Tartışma doğurur ve tartışmaların bedeli vardır. Hangi belgenin hangi konuda üstün geleceği, sözleşmenin tabi olduğu hukuka göre de değişebilir. Bu yüzden bir ülkede işe yarayan bir öncelik sırası, başka bir ülkede aynı sonucu vermeyebilir.

Aranacak yazım türüne bir örnek şöyle olabilir. Bu, belirli bir yargı alanı için tavsiye değil, yalnızca bir taslak örneğidir:

§ Çelişki halinde MSA hükümleri SOW'a üstün gelir; ancak SOW, ilgili proje için kapsam, teslimatlar, takvim ve ücretler bakımından üstün gelir.

Bir tuzağa dikkat edin. SOW, sorumluluk sınırını ya da fikri mülkiyet hükmünü "yalnızca bu proje için" sessizce değiştiriyorsa ve iki taraf bunu bilerek istiyorsa bu meşrudur. Kimse fark etmemişse sorun olur. SOW'u imzalayan kişi onu bir proje planı gibi değil, bir sözleşme gibi okumalıdır.

Kapsam ifadesi baskı altında nasıl ayakta kalır?

SOW'lar çoğu zaman kapsam yüzünden başarısız olur. Belirsiz bir kapsam tarafsız değildir: sonradan tartışmaya daha istekli olan tarafı kayırır. Pratikte bu genellikle daha fazla kaldıraca sahip taraftır.

Kapsamı sağlam tutan üç alışkanlık var.

Birincisi, dışlamaları yazın. Kapsam dışında kalanların listesi, kapsam içindekilerin listesinden çoğu zaman daha faydalıdır. "Müşterinin eski faturalama sistemiyle entegrasyon bu kapsamda değildir" gibi bir cümle, üç toplantıya yayılabilecek bir tartışmayı tek satırda kapatır.

İkincisi, teslimatları sıfatlara değil isimlere bağlayın. "Duyarlı bir web sitesi" tartışmaya açıktır. "İki isimli tarayıcının son iki sürümünde test edilmiş sekiz şablon" ise kontrol edilebilir.

Üçüncüsü, varsayımları açıkça belirtin. Takvim, müşterinin geri bildirimi beş iş günü içinde vermesine bağlıysa bunu yazın ve vermezse takvimin ne olacağını da belirtin. Gecikme talepleri, bağımlılık yazılı olduğunda çok daha kolay savunulur.

Hazır bir şablonu kopyalayıp boşlukları doldurma cazibesine direnin. Şablon size başlıkları gösterir. Hangi varsayımların sizin projenize özgü olduğunu ise söyleyemez.

Basit bir test de işe yarar. Kapsamı okumamış birine, bu işte neyin dahil olmadığını sorun. Cevabı belirsiz kalıyorsa dışlama listesi eksiktir ve eklenmelidir. Bu küçük test, kapsam tartışmalarının büyük kısmını imza öncesinde ortaya çıkarır ve proje sırasında yapılacak pazarlığı çok daha ucuza indirir.

Kabul ve değişiklik talepleri nasıl yazılmalı?

Kabul kriterleri tek bir soruyu yanıtlar: Bir teslimat, ödeme yapılacak kadar tamamlandı mı? "Yüksek kalite" ya da "müşterinin memnuniyetine uygun" bu soruyu yanıtlamaz. Test edilebilir bir kriter yanıtlar. Örneğin bir veri taşıma işinde ifade şöyle olabilir: "Tüm kayıtlar aktarılmış ve mutabakat raporunda açıklanamayan bir fark yer almıyor."

Kabul varsayımına dayalı bir mekanizma da ekleyin. Yaygın bir kalıba göre teslimat, müşteri belirli bir süre içinde yazılı eksiklik bildirmezse kabul edilmiş sayılır. Bu süre çoğu zaman on iş günü civarındadır. Bu madde yoksa müşteri onayı süresiz geciktirebilir ve son fatura da onunla birlikte askıda kalır. Müşteriyseniz, tedarikçinin bildirdiğiniz sorunları düzeltmesi için net bir süre isteyin. Böylece saat iki taraf için de adil işler.

Değişiklik taleplerine de aynı özeni gösterin. Kapsam kayması nadiren tek ve büyük bir talep olarak gelir. Her biri makul görünen on küçük talep olarak gelir. Bir paragraflık bir değişiklik süreci bunu çözer: Kapsam, fiyat ya da tarihlerdeki her değişiklik, iş başlamadan önce iki tarafça imzalanmış yazılı bir değişiklik emri gerektirir. Birçok tedarikçi, SOW sözlü anlaşmaya izin verdiği için projelerde kâr kaybeder.

Sabit fiyat mı, zaman ve malzeme mi? Hangisi SOW'a uyar?

Fiyatlandırma bölümü riskin nasıl paylaşılacağını değiştirir, bu yüzden bilinçli seçilmelidir.

Sabit fiyat, teslimat riskini tedarikçiye yükler. Kapsam iyi anlaşılmışsa ve değişmesi pek olası değilse işe yarar. Kapsam muğlaksa kötü çalışır, çünkü tedarikçi tampon payı ekler ya da her değişikliğe karşı çıkar.

Zaman ve malzeme, emek riskini müşteriye yükler. Keşif niteliğindeki işlere uygundur, ancak bir tavan ya da aşılamayacak bir üst sınır gerektirir. Aksi halde bütçe bir görüşten ibarettir.

Kilometre taşı başına sabit fiyatlı bir hibrit model çoğu zaman en dürüst uzlaşmadır. Her kilometre taşının kendi teslimatı, kabul testi ve faturası olur. Bu da SOW'u denetlemeyi kolaylaştırır ve proje ters giderse durdurmayı kolaylaştırır.

Örneğin üç kilometre taşından oluşan bir web sitesi projesinde birinci kilometre taşı tasarım onayı, ikincisi geliştirme ve test, üçüncüsü yayına alma olabilir. Her biri ayrı bir fatura ve ayrı bir kabul süresi taşır. Müşteri ikinci aşamada durursa, ödenen işin hangi kısmının teslim edildiğini tartışmak yerine bunu tek bakışta görürsünüz.

İmzalamadan önce: sık hatalar ve kontrol listesi

Çok sayıda bu tür belge okuyunca aynı hatalar tekrar tekrar ortaya çıkıyor:

• MSA henüz yokken SOW'u imzalamak. Böylece proje hiçbir sorumluluk ya da fikri mülkiyet şartı olmadan yürür.

• Tarihleri "yaklaşık" bırakmak ve kaçırıldığında hiçbir sonuç doğurmamasını sağlamak.

• Teslimatları çıktıyla değil faaliyetle tanımlamak. "Destek sağlamak" yerine "öncelikli talepleri dört iş saati içinde yanıtlamak" yazılmalı.

• Tedarikçi kişisel veri işleyecekse veri korumayı unutmak. AB ve Birleşik Krallık'ta bu genellikle SOW'un yanında bir veri işleme sözleşmesi anlamına gelir ve doğru ayrıntılar ilgili yargı alanlarına bağlıdır.

• Sözlü bir değişiklikten sonra SOW'u güncellememek, ardından bir yıl sonra hafızaya güvenmek.

Bu teorik bir risk değildir. Hukukçuların düzenli olarak gördüğü bir durumdur. Bunların hiçbirinden kaçınmak hukuki bir dehâ gerektirmez. Yalnızca birinin imzalamadan önce belgeyi yavaş ve dikkatle okuması gerekir.

İmzalamadan önce şu üç adım çoğu riski kapatır:

1. MSA'nın var olduğunu kontrol edin ve SOW'da hukuki şartlar ile kapsam ve ücretler arasında hangi belgenin geçerli olacağının yazılı olduğunu doğrulayın.

2. Her teslimatı, bir yabancının teslim edilip edilmediğini evet ya da hayır diye söyleyebileceği biçimde yeniden yazın. Dışlamaları ve varsayımları ekleyin.

3. Kabul süresini, düzeltme süresini ve yazılı değişiklik emri kuralını doğrulayın. Her değişikliği SOW'a ekli tutun.

Proje büyükse, kişisel veri içeriyorsa ya da sınır ötesi bir boyut taşıyorsa hukuk danışmanınız belgeyi okusun. Cevap uygulanacak hukuka bağlıdır ve kısa bir inceleme, bir uyuşmazlığın maliyetinden çok daha düşüktür.

Hangi araçlar SOW hazırlamaya yardımcı olur?

Araç sizin yerinize iyi bir kapsam yazamaz. Ama kapsamın etrafındaki tekrarlayan işleri azaltabilir.

Yeniden kullanılabilir bloklardan taslak hazırlamak, onayları ve elektronik imzayı tek bir akışta yürütmek istiyorsanız bir belge platformu pratiktir.

Yalnızca imza gerekiyorsa, denetim izi ve karşı tarafların geniş kabulü olan özel bir elektronik imza hizmeti yeterlidir.

Yılda çok sayıda SOW yöneten ve bunları bir MSA'ya bağlaması gereken ekipler için, ana şartlar ile her proje belgesi arasındaki bağı koruyan bir sözleşme yaşam döngüsü platformu işe yarar.

Word içinde maddelerin ilk risk taramasını yapmak için, bir insan okumadan önce eksik dışlamaları ya da çelişen sorumluluk maddelerini işaretleyebilen bir yapay zeka inceleme eklentisi kullanılabilir.

Bunların hiçbiri, riskin yüksek olduğu durumlarda bir avukatın yerini tutmaz. Yazılımı rutin sorunları yakalamak için kullanın. Alışılmadık, büyük ya da sınır ötesi olan her şeyi hukuk danışmanınıza götürün.