BT SOP’leri, teknoloji operasyonlarını tutarlı, güvenli ve mevzuata uygun tutan şeydir. Trupeer ile ücretsiz bir BT SOP şablonuyla başlayarak, marka yönergeleriniz ile özelleştirerek ve her prosedürü net bir video anlatıma dönüştüren yapay zekâ SOP oluşturucumuzu kullanarak BT SOP’leri yazmak için saatler kazanabilirsiniz.

Bir BT SOP nedir ve bunun iki yanında neler yer alır?

Standart işletim prosedürü, tekrar eden bir görevin yazılı sıralamasıdır; uzman olmayan ama yetkin birine yöneliktir. İki kişinin bunu izleyerek aynı sonucu üretmesini sağlayacak kadar nettir.

Bunun iki yanında iki doküman daha bulunur ve sürekli onunla karıştırılır.

Bir politika bir kural ve bir sınır belirtir. Belirli bir eşiğin üzerindeki satın alımların onay gerektirdiğini söyler. Satın alma emrini hangi butonun oluşturduğunu söylemez. Politikalar nadiren değişir ve yönetişim tarafından onaylanır. “must” ve “may not” yazdığınızı fark ederseniz, bu politika yazdığınız anlamına gelir ve bunun yerine bir politika dokümanında yer almalıdır.

Runbook veya prosedür yöntemi, çoğu zaman bir gecelik tek bir icra edilen tek bir değişikliktir; zamanlamalarla birlikte yazılır. Kullanılır ve ardından arşivlenir. SOP, runbook’un ödünç aldığı yeniden kullanılabilir şeydir. İş tek seferlik bir geçiş (cutover) ve geri alma penceresi içeriyorsa, SOP değil prosedür yöntemi istersiniz.

SOP, bunların arasında durur: kural başka yerde, takvim başka yerde ve geriye, bu hafta gerçekten sahip olduğunuz sistemlerde işin nasıl yapıldığı kalır.

Bu dokümanın, herhangi bir ekibe uygulanabilen genel amaçlı sürümünü istiyorsanız, SOP şablonumuz standart yapıyı kapsar. Bu sayfa, prosedürün bir BT prosedürü olması durumunda nelerin değiştiğini anlatır.

Bir BT SOP’yi diğer her türden farklı kılan şey nedir?

Restoran SOP’leri, İK SOP’leri ve depo SOP’leri, bir kişinin beş yıl sonra da yapacağı işleri anlatır. Birisi her zaman müşteriyi karşılar ve stokları kontrol eder.

BT prosedürleri bunun gibi değildir. Çoğunun anlattığı iş, bir kişinin yapmayı bırakması gereken iştir. Bir hesabı sağlama (provisioning), bir anahtarı döndürme, bir dosyayı geri yükleme, bir birimi yeniden boyutlandırma, bir kuyruğu temizleme, paylaşılan bir sürücüye erişim verme: Bunların her biri, insan prosedürü olarak hayatına başlar ve ekip iyi ise hayatını bir script olarak, kendi kendine hizmet (self-service) aksiyonu olarak ya da soruyu sormayı imkânsız kılan platform ayarı olarak bitirir.

Bu da demek oluyor ki bir BT SOP kütüphanesi aynı anda iki şeydir. Hem bir dizi talimattır hem de ekibin el yordamıyla yaptığı her şeyin bir envanteridir. İkinci kullanım daha değerlidir ve neredeyse kimse bunu kullanmaz; çünkü şablon bunu istemez.

Bu şablon da bu yüzden, diğer SOP şablonlarında olmayan bir alan ekler. Her prosedür kendi geleceği hakkında bir hüküm taşır ve kütüphane yalnızca doğruluk için değil, bu hükümlere göre de gözden geçirilir. Bir yılda kırk SOP yazıp bunlardan on ikisini silen bir ekip, kırk yazıp hepsini tutan ekipten daha iyidir ve şablon bunu görünür kılmalıdır.

Trupeer’da bu şablon nasıl özelleştirilir?

Adım 1: Şablonlar bölümünü açın

Ana navigasyondan Şablonlar bölümüne gidin.

Adım 2: Bir şablon seçin ve açın

Açmak istediğiniz herhangi bir şablonun üzerine tıklayın.

Adım 3: Şablon görünümünü genişletin

Gerekirse, tam düzeni ve ayrıntıları net görmek için şablon görünümünü genişletin.

Adım 4: Şablonu düzenleyin

Seçili şablonda değişiklik yapmaya başlamak için Düzenle’ye tıklayın.

Düzenleyici içinde şunları yapabilirsiniz:

• Yeni bölümler ekleyin

• Biçimlendirme kurallarını tanımlayın veya güncelleyin

• Bir logo ekleyin ve konumunu ile ilgili ayarları düzenleyin

Adım 5: Özelleştirilmiş şablonunuzu kaydedin

Gerekli tüm değişiklikleri yaptıktan sonra, güncellenmiş şablonu kendi şablonunuz olarak saklamak için Kaydet’e tıklayın.

Adım 6: Şablonu önizleyin ve ince ayar yapın

Özelleştirilmiş şablonunuzun nasıl göründüğünü görmek istediğinizde Önizleme’yi açın.

Önizleme ekranından, gerekirse doğrudan ayarlamaya devam edebilir; böylece şablonun tam olarak istediğiniz gibi göründüğünden emin olursunuz.

Bir BT SOP şablonuyla şunları yapabilirsiniz:

• Yazmak için saat kazanın: BT prosedürleri için oluşturulmuş bir yapıyla boş sayfayı atlayın.

• Denetime hazır kalın: Yerleşik bölümler SOC 2, ISO 27001 ve benzeri denetimleri destekler.

• Markanızla uyumlu kalın: Trupeer’ın marka kitini kullanarak logonuzu, yazı tiplerinizi ve renklerinizi uygulayın.

• BT ekiplerini eğitin: SOP’leri BT eğitim videoları ile eşleştirin.

• Prosedürleri standartlaştırın: Her BT SOP için aynı şablonu kullanın.

• Küresel ekiplere ulaşın: Tek tıklamayla BT SOP’leri 65+ dile çevirin.

Hüküm (disposition) alanı

Başlıkta kaydedilen üç hüküm; çeyreklik olarak gözden geçirilir.

Otomatikleştirin. Prosedür deterministiktir; içinde yargı yoktur ve mühendislik açısından değerli olacak kadar sık çalıştırılır. Anahtar rotasyonu, onaylı bir talepten hesap sağlama, sertifika yenileme, yedek doğrulama, günlük (log) rotasyonu, standart yeniden boyutlandırma işlemleri. Belirsiz bir niyet değil, hedef bir çeyrek belirleyin. Otomasyon yayına çıkana kadar SOP canlı kalır; ardından SOP, onun yanında çürümeye bırakılmak yerine silinir. Bu, iki farklı “tek doğru” kaynağı üreten hatadır.

Talep edene verin. Prosedür deterministiktir ama ekip dışından biri bunun yapılmasını ister; BT’nin dahil olmasının tek nedeni, butonun bir izin arkasında olmasıdır. Şifre kendi kendine hizmet, grup üyeliği talepleri, lisans ataması, yaygın yazılım kurulumları. Buradaki iş bir script değildir; kendi kendine hizmet yolu ve bunu açık hale getiren bir job aid’dir. SOP, bu yolun spesifikasyonu haline gelir.

İnsanda tutun. Gerçek yargı; otomasyonun maliyeti, sağladığı faydadan daha fazla olacak kadar nadirdir ya da sonuçları öyle ki kararın sorumluluğu bir kişide olmalıdır. Olay (incident) triage’ı, kapasite kararları, bir tedarikçiyle müzakere etmeyi gerektiren her şey, doğru aksiyonun sistemin durumuna değil işin durumuna bağlı olduğu her şey.

Karar vermek için, yıllık saatleri bulmak üzere çalıştırma sıklığını ortalama süreyle çarpın; ardından herhangi bir adımın, bir kuralın kodlayamayacağı bir yargı gerektirip gerektirmediğini sorun. Yılda altmış saat ve içinde yargı yoksa, yalnızca aritmetik üzerinden bile otomasyon adayıdır. İçinde üç yargı çağrısı olan yılda dört saat, ne kadar sıkıcı hissettirse de insanda kalır.

Şablon yapısı

Buradan kopyalayın. Başlık bloğu, çoğu SOP şablonunun atladığı alanları taşır.

Başlık. SOP numarası ve başlığı; fiil ile başlayacak şekilde yazın. Örneğin “Silinmiş bir posta kutusunu geri yükle” ifadesini “Posta kutusu geri yükleme süreci” yerine kullanın. Sahibi. İnceleyen. Oluşturulma tarihi. Son doğrulama tarihi; bu, birinin bu prosedürü en son ne zaman çalıştırdığını ve adımların hâlâ gerçeğe uyduğunu doğruladığını ifade eder; birinin metnin ifadesini ne zaman düzenlediğini değil. Hüküm ve hedef çeyrek. Çalıştırma sıklığı ve ortalama süre. Gerekli erişim; gerçek rol veya grup adıyla. Dokunulan sistemler. Geri alınabilir evet ya da hayır.

Tetikleyici. Bu prosedürü başlatan olay veya talep; o kadar net ifade edilmelidir ki bir kişi kapsamda olup olmadığını anlayabilsin.

Şunu yapmayın: Bu prosedürü şu durumlarda çalıştırmayın. Prosedürün yanlış olduğu koşullar. Bu bölüm, adımların kendisinden daha fazla olayı (incident) önler.

Ön koşullar. Erişim, onaylar, bilgiler ve adım bir başlamadan önce doğrulanması gereken her şey. Tüketici kontrolünü ekleyin: Değiştirmeye hazırlandığınız şeyden hangi diğer sistemler, işler veya entegrasyonlar etkileniyor? Buna yanıt veremiyorsanız, cevap “yok” değildir; cevap “bilinmiyor”dur.

Adımlar. Numaralı; her adımda tek bir aksiyon. Her aksiyonun yanında beklenen sonuç yer alır. Bir adımın gözlemlenebilir bir sonucu yoksa, ya adım değildir ya da başarı tanımını henüz netleştirmemişsinizdir.

Doğrulama. Son adımın tekrarı değildir. Doğrulama, sonucun gerçekleşip gerçekleşmediğini yanıtlar ve değişikliğin dokunduğu en uzun döngüyü kapsamalıdır. Gece çalıştırılan batch, replikasyon gecikmesi, önbellek (cache) süresi dolumu, cron zamanlaması, aşağı akış senkronizasyonu. Yalnızca senkron bir testle doğrulanan bir prosedür, hayatının ilk on saniyesi için doğrulanmış demektir.

Geri alma (Rollback). Nasıl geri alınacağı ve geri alamayacağınız nokta.

Yükseltme (Escalation). Kimin, hangi yolla ve onlara ne söylenmesi gerektiği.

Değişiklik kaydı. Tarih, kim, ne değişti ve neden. Üç satır yeterlidir.

Uygulamalı bir örnek ve maliyeti

Brightmoor Insurance, “Ödeme ağ geçidi imzalama anahtarını döndür” adlı bir prosedürü her doksan günde bir çalıştırıyordu. Altı adım vardı. 2023’te yazılmıştı ve herhangi bir olay olmadan on dört kez yürütülmüştü.

Mart ayındaki bir Salı günü, bir mühendis bunu 14:20’de çalıştırdı. Ağ geçidi portalında yeni anahtarı oluşturun, bunu konfigürasyon deposuna ekleyin, konfigürasyonu dağıtın, ödeme servisini yeniden başlatın, sandbox’ta bir test ödemenin başarılı olduğunu doğrulayın ve eski anahtarı iptal edin. Her adım tamamlandı. Sandbox’taki ödeme başarılı oldu. Bilet, rotasyonun tamamlandığını belirten bir notla 14:35’te kapatıldı.

02:10’da gece çalışan prim toplama batch’i kimlik doğrulamada başarısız oldu. Aynı imzalama anahtarını kullanıyordu; bu anahtar, konfigürasyon deposuna hiç taşınmamış ayrı bir konfigürasyon dosyasında tutuluyordu. Çünkü bu sunucu, taşımadan önce vardı ve taşıma işlemini yapan kimse bunun varlığından haberdar değildi.

Dört bin yüz doğrudan borç tahsilatı (direct debit) gönderilmedi. Arıza 06:40’ta bulundu; finans sabah uzlaştırmasını (reconciliation) çalıştırmıştı. Tahsilatlar 11:00’a kadar yeniden işlendi; ancak gece çalıştırılan mektup süreci, etkilenen tüm müşterilere daha önce başarısız tahsilat bildirimleri üretmişti ve çağrı merkezi sonraki iki gün boyunca toplam üç yüz seksen arama aldı. Dört kişi iki gün boyunca bununla uğraştı; ayrıca bir özür posta gönderimi daha yapıldı.

SOP yanlış değildi. Altı adımın her biri doğruydu ve her biri takip edilmişti. İki nedenle başarısız oldu; ikisi de bürokratik değil, yapısaldı. Bu anahtarı hangi sistemlerin tükettiğini soran bir ön koşulu yoktu; bu yüzden ikinci bir tüketici üç yıl boyunca görünmez kaldı. Ayrıca doğrulaması bir sandbox çağrısıydı; bu da ödeme servisinin 14:32’de sağlıklı olduğunu kanıtladı ama başka bir on iki saat çalışmayacak olan batch işi hakkında hiçbir şey kanıtlamadı.

İlginç olan, bir sonraki adımda ne yaptıklarıdır. İçgüdü yedinci bir adım eklemekti. Oysa yaptıkları şey, olayın onları derlemeye zorladığı tüketici envanterini oluşturmak oldu ve bu envanter ortaya çıktığında rotasyon otomatikleştirilebilir hale geldi. Prosedür bir sonraki çeyrekte planlı bir iş (scheduled job) olarak yayına alındı ve SOP silindi.

Dokümanın en değerli çıktısı asla talimatlar değildi. Talimatların ihtiyaç duyduğu envanterdi ve hüküm alanı, bir ekibin bunu bir arızadan sonra değil özellikle aramasını sağlayan şeydir.

Biçimler ve BT işlerinde hangisini kullanmalısınız?

Çoğu rehber dört SOP biçimini listeler ve seçimi size bırakır. BT işleri için seçim, göründüğünden daha dardır.

Adım adım, başlangıcı ve bitişi bilinen doğrusal operasyonel görevler için doğrudur. Geri yüklemeler, sağlama (provisioning), rotasyonlar, dağıtımlar. Bu, BT SOP’lerinin çoğunluğu ve yukarıdaki yapının varsaydığı biçimdir.

Akış şeması veya karar ağacı, bir sonraki aksiyonun az önce ne bulduğunuza bağlı olduğu tanılama (diagnosis) için doğrudur. Olay triage’ı, bağlantı arızaları, performans incelemesi. Bunları numaralı bir listeye zorlamayın; çünkü numaralandırma, var olmayan bir sıra ima eder ve insanlar yine de onu takip eder.

Kontrol listesi, ön uçuş (pre-flight) ve değişiklik sonrası doğrulama için doğrudur; burada sıra, eksiksizlikten daha az önemlidir. Birini yerine koymak yerine, bunu adım adım bir prosedürle eşleştirin.

Hiyerarşik, yalnızca bir prosedür gerçekten ortam veya katman (tier) bazında dallanıyorsa doğrudur ve genellikle tek bir başlık altında iki prosedür taşıdığınızın işaretidir.

Doksan dakikada bir tane yazmak

Görevi gerçek bir sistem üzerinde, normal hızda yaparken ekran kaydı alın; ilerlerken neyi kontrol ettiğinizi konuşarak anlatın. Bu kayıt taslaktır.

Kayıttan adımları yazın; yalnızca gezinme yaptığınız her adımı silin. Kalan her adımın yanına beklenen sonucu ekleyin. Tetikleyiciyi ve “şunu yapmayın: bu prosedürü şu durumlarda çalıştırmayın” bölümünü en sona yazın; çünkü adımlar var olmadan oraya neyin ait olduğunu yalnızca o zaman bileceksiniz.

Ardından bunu görevi hiç yapmamış birine verin ve yardım etmeden takip etmelerini izleyin. Durdukları her yer, eksik bir adım ya da varsayılan bir bilgi parçasıdır. Bunları düzeltin, son doğrulama tarihini bugüne ayarlayın ve yayımlayın.

Doksan dakika, zaten bildiğiniz bir prosedür için gerçekçidir. Başkasının bilgisinden dokümante ettiğiniz bir prosedür için bunu ikiye katlamak normaldir ve bu konuşmayı yapılandırmaya yardımcı olan knowledge transfer SOP bunu destekler.

Önce hangi BT SOP’leri yazmalısınız?

Önemli hissettirenler değil. Aynı anda üç konuda yüksek puan alanları yazın: sık çalışır, yanlış yapıldığında zarar verir ve şu an tek bir kişinin kafasında yaşıyordur.

Bu kural genellikle aynı başlangıç setini ortaya çıkarır. Erişim ve kimlik prosedürleri; yani katılanlar, ayrılanlar, ayrıcalık yükseltme ve paylaşılan hesap yönetimi. Yedekleme ve geri yükleme; neredeyse her ekip yedek için dokümante etmiştir ama geri yükleme için etmemiştir. Olay bildirimi ve yükseltme; bunun kimlerin arayabileceğini de içerir. En sık dokunduğunuz sistem için değişiklik ve yayın adımları. Sertifika ve anahtar rotasyonu. Uç nokta yeniden oluşturma ve varlık devri.

Ayrılanlar (leavers) ve geri yükleme (restore), en güvenilir şekilde dokümante edilmemiş çıkan iki şeydir ve doğaçlama yapmanın maliyetinin en yüksek olduğu iki alandır.

Buraya yazdığınız her şey, onu tarif etmek yerine sistem envanterinize işaret etmelidir. uygulama ve kimlik bilgileri kaydı bunun için doğru yerdir; daha geniş sistem açıklaması ise BT dokümantasyonunuzda yer almalıdır.

Kütüphaneyi gözden geçirmek

Çeyrekte bir kez listeyle oturun ve her kayıt için üç soru sorun.

Son altı ay içinde doğrulandı mı? Yani birisi gerçekten çalıştırdı mı? Doğrulanmamış prosedürler, hiç olmayanlardan daha kötüdür; çünkü insanlar onlara güvenir.

Hükmü değişti mi? Geçen yıl nadir olan bir prosedür artık haftalıksa, otomasyon alanına taşınmıştır.

Bir şey yayımlandı mı? Arkasında yapılan iş otomatikleştirildiği veya devredildiği için bu çeyrekte silinen SOP’leri sayın. Bu sayı art arda üç çeyrekte sıfırsa, kütüphane çalışan bir set olmaktan çıkıp bir dosyalama egzersizine dönüşmüştür.

Neler dışarıda bırakılmalı?

Değişen şeylerin ekran görüntüleri; yani tedarikçinizin kendi takvimine göre güncellediği herhangi bir arayüz. Bu görseller, kelimelerden daha hızlı dokümanı eskitir ve insanların bir prosedüre güvenmeyi bırakmasının ana nedenidir. Hedefi ekrandaki konumuna göre değil, adıyla tanımlayın.

Sistemin neden bu şekilde çalıştığına dair açıklamalar. Gerçek bir merak sorun değil; ancak bu, dokümantasyonda yer alır; kuyruk birikirken birinin okuduğu bir prosedürde değil.

Onay kuralları ve eşikler. Bunlar politikalardır ve bunları prosedürlere kopyalamak, bir sayı değiştiğinde on dört dokümanı güncellemek anlamına gelir.

Yazmak yerine prosedürü kaydetmek

Bir SOP kütüphanesi oluşturmanın en yavaş kısmı, ne yazacağınıza karar vermek değildir; yazmaktır (typing). Ayrıca hafızadan yazılan bir prosedür, yazarın yıllar önce fark etmeyi bıraktığı iki tıklamayı her zaman eksik bırakır.

Trupeer AI, bir ekran kaydını dokümante edilmiş bir prosedüre dönüştürür; bu sayede yukarıdaki doksan dakikalık yöntem tek bir geçişe (single pass) iner. Görevi bir kez kaydedin; adım adım bir rehber, adımları zaten yazılmış şekilde; izlemeyi tercih eden kişiler için bir video ve kendi markanızla bilgi bankanıza (knowledge base) eklenmiş bir doküman elde edersiniz.

Kaydedin. Markalayın. Çevirin. Trupeer’layın.

SOP creator tam olarak bunun için tasarlanmıştır, documentation prosedürleri ve sistem açıklamalarını birlikte tutar ve çeviri, “güneşin doğduğu ekip” (follow the sun) aynı prosedürü kendi dilinde okuduğu anlamına gelir. Kurulum talimatları doküman şablonu kurulum rehberinde yer alır.

Sık Sorulan Sorular

Excel’de ücretsiz bir BT SOP şablonu var mı?

Excel, prosedür için yanlış; kütüphane için doğru kapsayıcıdır. Başlık, sahip, son doğrulama tarihi, hüküm, çalıştırma sıklığı, yılda saat ve hedef çeyrek için sütunları olan, her SOP’yi listeleyen tek bir sayfa oluşturun. Bu sayfa, çeyreklik gözden geçirmeyi mümkün kılan şeydir. Prosedürlerin kendisi ise sürüm geçmişi ve arama içeren bir yerde bulunmalıdır.

Word sürümü var mı ya da Word dokümanı ücretsiz indirilebilir mi?

Yukarıdaki başlık bloğu ve bölüm başlıkları, Word veya Google Docs’a doğrudan yapıştırılacak ve ev yapısı (house structure) olarak kullanılacak şekilde yazılmıştır. Kontrollü (gated) bir indirme yoktur; bu da sizinle şablon arasında bir form olmadığı anlamına gelir. Doldurulmuş sürümünüzü her seferinde yeniden kopyalamak yerine, departmanınız için başlangıç noktası olarak kaydedin.

PDF sürümü var mı?

Prosedür doğrulandıktan sonra kendi PDF’inizi dışa aktarın. PDF, imzalanmış ve denetim için dolaşıma çıkarılan bir prosedür için uygundur; çalışan bir doküman için doğru değildir. Çünkü kimsenin düzenleyemediği bir prosedür, yerinde eskimeye başlar.

Ücretsiz olarak indirebilir miyim?

Yapı, hüküm alanı ve uygulamalı örnek ücretsizdir ve kısıtlama olmadan kullanılabilir. Bunları kullanın, düzenleyin; kendi adınızla, atıf vermeden kendi şablon kütüphanenize ekleyin.

Ücretsiz bir SOP oluşturucu var mı?

Evet ve oluşturucular ilk taslak için gerçekten faydalıdır. Trupeer AI’nin SOP creator’ı, bir ekran kaydından prosedürü oluşturur; bu da adımların sistemden geldiği, sizin onu hatırlamanıza dayanmadığı anlamına gelir. Hangi aracı kullanırsanız kullanın, bir oluşturucunun sağlayamadığı parçalar hüküm, tüketici kontrolü ve doğrulama penceresidir; bu yüzden bunları elle eklemeyi bekleyin.

Ekibim için bir SOP formatını nasıl oluşturabilirim?

Tek bir yapı seçin, üç gerçek prosedür için doldurun; sonra durup şablonun ifade etmekte zorlandığınız kısmına bakın. Bir kez ayarlayın, ardından dondurun. Formatı sürekli geliştiren ekipler prosedür biriktirmez; çünkü her yeni SOP, işin içeriğinden çok dokümanın biçimi hakkında bir tartışmayı tetikler.

En iyi SOP şablonu hangisi?

Ekibinizin doğrulanmış halde tutacağı şablon. Yapı, sahiplik ve gözden geçirme tarihi kadar önemli değildir; geçen ay çalıştırılmış, sade altı bölümlü bir prosedür, yazıldığından beri kimsenin açmadığı karmaşık bir prosedürü geçer.

Bir BT SOP ne kadar uzun olmalı?

Çoğu durumda adımlar için tek bir ekran. Adımlar yaklaşık on beşin üzerine çıkarsa, prosedür genellikle iki prosedürdür ya da kesilmesi gereken bir gezinme (navigation) içerir. Başlık, ön koşullar ve doğrulama, ihtiyaç duyulduğu kadar uzun olabilir; çünkü bunlar olayları önleyen parçalardır.

BT SOP’leri ne sıklıkla gözden geçirilmeli?

Her prosedürü en az her altı ayda bir, çalıştırarak doğrulayın ve tüm kütüphaneyi çeyreklik olarak hüküm alanına göre gözden geçirin. Erişim, anahtarlar veya geri yüklemeye dokunan her şey daha kısa bir döngüyü hak eder ve bir olayla ilişkili herhangi bir prosedür, olay kapatılmadan önce yeniden doğrulanmalıdır.