Kimin ne zaman müdahale edeceği baştan yazılı olan Gaziantep yazılım bakım ve destek hizmeti
Yazılım teslim edildiği gün bitmez; asıl orada başlar. Yıllık bakım sözleşmesi, aylık geliştirme kapasitesi ve acil müdahale ile sistemin ayakta kalmasını üstleniriz. Kendi yazdığımız yazılımlara da, başkasından devraldığımız programlara da bakarız. Aynı şehirde olmanın anlamı şudur: ekran paylaşarak çözülmeyen işte Başpınar'a ya da Şehitkamil'e gelir, sunucunun başına geçeriz.
- Kendi saha araştırmamızda Gaziantep OSB'de 1108 firmayı taradık; bunların 90'ını büyük, 83'ünü çok büyük ölçekte işaretledik. Geri kalan çoğunluk, tam zamanlı bir bilgi işlem ekibi taşımayan ölçekte çalışıyor. Yani yazılım arızası çıktığında müdahale edecek kişi çoğu firmada şirketin içinde değil, dışarıda ve genelde tek kişi.
- Başpınar OSB'nin bölgeleri ile Şehitkamil arasındaki mesafe, arıza anında somut bir değişken. Uzaktan bağlantı çoğu işi görür; ama sunucu açılmıyorsa, kantar cevap vermiyorsa ya da depodaki el terminali ağa bağlanmıyorsa uzaktan bağlanacak bir yer de kalmamış demektir. Bu tür işlerde aynı şehirde olmak, başka şehirden gelecek bir ekibin yol süresini baştan devreden çıkarıyor.
- Mevzuat ve karşı taraf sabit durmuyor. e-belge kapsamı kademeli olarak genişliyor, banka ekstre formatı değişiyor, pazaryeri arayüzünü güncelliyor, ihracat yaptığınız müşteri kendi portalına yeni bir alan ekliyor. Bakım sözleşmesinin en sık atlanan işlevi budur: sistemi olduğu yerde tutmak değil, dışarısı değiştikçe onu birlikte değiştirmek. Bu iş yapılmadığında sistem bir sabah, kimse hiçbir şeye dokunmamışken çalışmayı bırakıyor.
- Şehirde yıllar önce tek bir yazılımcıya yazdırılmış, hâlâ üretimi taşıyan çok sayıda program çalışıyor; dokuma ve halı tarafında gece vardiyası sürdüğü için bu programların durması sabah mesaisini değil, o anki vardiyayı etkiliyor. Kendi işlerimizde de bu tabloyla defalarca karşılaştık: derlenmiş bir kurumsal uygulamanın günlük hesap formülünü tersine mühendislikle çözdük, bir kesim sipariş sisteminin yirmi dokuz bölümlük analizini çıkardık ve altmışın üzerinde veritabanı nesnesinin çağrı sözleşmesini kanıtıyla ortaya koyduk. Yani kaynak kodu olmayan bir programın bakımının nasıl bir iş olduğunu tahmin ederek değil, yaparak biliyoruz.
Teslimden sonra yaşanan asıl hikaye
- Yazılımı yapan kişiye ulaşılamıyor. Telefon açılmıyor, mesaj günler sonra cevaplanıyor ya da mesai dışı diye geri dönülüyor. Sistem çalıştığı sürece kimse fark etmiyor; durduğu gün ise elinizde numara var ama karşılık yok.
- Program tek bir kişinin kafasında. O kişi izne çıktığında ya da işi bıraktığında sistemde en küçük değişikliği yapacak kimse kalmıyor; arızanın çözülmesi bir yana, teşhis edilmesi bile mümkün olmuyor.
- Sunucu yıllardır kimsenin bakmadığı bir odada duruyor. Disk doluyor, yedek alındığı sanılıyor ama alınan yedeğin geri dönüp dönmediği hiç denenmemiş. Yedek, geri yüklenene kadar sadece bir varsayımdır.
- Küçük bir değişiklik için aylarca bekleniyor. Yeni bir rapor kolonu, değişen bir oran ya da yeni bir müşteri formatı gibi yarım günlük iş, sırada olduğu söylenerek çeyrek boyunca ertelenebiliyor.
- Mevzuat veya karşı taraf değişince sistem sessizce durabiliyor. Pazaryeri arayüzünü güncelliyor, banka formatı değişiyor, e-belge tarafında yeni bir alan zorunlu oluyor; kimse haber vermediği için sorun ancak fatura kesilemediğinde anlaşılıyor.
- Destek faturası tahmin edilemiyor. Kimi ay hiç fatura gelmiyor, kimi ay küçük bir iş için beklenmedik bir rakam çıkıyor. Bütçelenemeyen bir gider, işletmede en çok gerginlik yaratan gider türü.
- Arıza gece vardiyasının ortasında çıkıyor ve kimin arayacağı belli değil. Üretim müdürü mü, muhasebe mi, patron mu arayacak; hangi numaradan aranacak, cevap gelmezse ne yapılacak konusunda yazılı bir şey yok.
- Sistem yavaşlıyor ama kimse ölçmüyor. Ay sonu raporunun açılması giderek uzuyor, herkes alışıyor ve bu yavaşlık normal kabul ediliyor. Ölçülmediği için ne zaman başladığı ve neden büyüdüğü de bilinmiyor.
- Değişiklik yapılıyor ama nereye ve neden yapıldığı yazılı değil. Aylar sonra aynı yere dokunulduğunda eski davranış geri geliyor ve kimse önceki değişikliğin gerekçesini hatırlamıyor.
Üç ayrı ihtiyaç, üç ayrı sözleşme biçimi
Bakım tek bir şey değil. Sistemi ayakta tutmak ayrı, geliştirmeye devam etmek ayrı, üretim durduğunda müdahale etmek ayrı bir iştir ve bunları tek kalemde toplamak genelde iki tarafı da mutsuz eder. Biz üçünü ayırır, hangisine ne kadar ihtiyacınız olduğunu keşifte birlikte belirleriz. Ne kadar geliyorsunuz, hangi işler dahil, hangileri değil sorularının cevabı sözleşmenin içinde yazılı durur.
| Yaklaşımımız | Pratikte ne demek |
|---|---|
| Yıllık bakım sözleşmesi | Sistemin çalışır kalması için gereken düzenli işler: hata düzeltme, sunucu ve veritabanı sağlığının izlenmesi, yedeklerin alındığının ve geri yüklenebildiğinin düzenli olarak sınanması, güvenlik güncellemeleri ve mevzuat ya da karşı taraf kaynaklı zorunlu uyarlamalar. Kapsamın içinde ve dışında ne olduğu maddeler halinde yazılır; sonradan tartışma çıkmasın diye. |
| Aylık geliştirme kapasitesi | Yeni özellik ve geliştirme için ayda belirli bir iş günü ayırırız. Her talep için ayrı teklif ve onay süreci beklemezsiniz; iş listesi ay başında birlikte önceliklendirilir, ay içinde sıralama değişebilir. Kullanılmayan kapasitenin devredip devretmeyeceği kuralı da sözleşmede açıkça yazılır. Bu model, sürekli küçük geliştirme ihtiyacı olan işletmelere uyuyor. |
| Acil müdahale ve olay yönetimi | Üretimi veya faturalamayı durduran arızalar için ayrı bir yol. Kimin arayacağı, hangi numaradan aranacağı, ilk cevabın ve yerinde müdahalenin hangi sürede beklendiği baştan tanımlanır. Bu süreler herkese söylenen standart bir vaat değil, sizin vardiya düzeninize göre belirlenir; gece vardiyası dönen bir dokuma tesisiyle mesai saatinde çalışan bir ofisin ihtiyacı aynı değil. |
| İzleme, yedek provası ve erken uyarı | Arızayı kullanıcıdan önce görmek için sistemi izleriz: disk ve bellek durumu, entegrasyon akışlarının çalışıp çalışmadığı, hata kayıtları, işlem sürelerindeki uzama. Yedeği almak yetmediği için düzenli aralıklarla geri yükleme provası yaparız. Sessizce duran bir entegrasyonun günler sonra fark edilmesi, bakımın olmadığı yerlerde sık gördüğümüz bir tablodur. |
| Başkasının yazdığı yazılımın bakımı | Yazılımı biz yapmadıysak da bakabiliriz; şartı önce ne olduğunu anlamaktır. Kaynak kod elinizde yoksa çalışan sistemden kanıta dayalı olarak iş kuralı çıkarır, kayıp veritabanı nesnelerini çağrıldıkları yerlerden yeniden kurar ve derlenip çalışan bir ortam kurmaya çalışırız. Bu işi daha önce yaptık; neyin çıkarılabildiğini ve neyin çıkarılamadığını raporda ayrı ayrı işaretler, tahmini bilgi gibi devretmeyiz. |
| Değişiklik kaydı ve devir dosyası | Yaptığımız her değişiklik gerekçesiyle birlikte kayıt altına alınır; sürüm geçmişi, yapılandırma ve bilinen riskler yazılı olarak elinizde durur. Amaç, bizden sonra da bu sistemi başka birinin sürdürebilmesi. Bakım hizmetinin sizi bize bağımlı hale getirmesi, çözmeye çalıştığımız problemin aynısını yeniden üretmek olurdu. |
Bakım ilişkisi nasıl başlar
- 01
Envanter ve durum tespiti
Elinizde ne var sorusunun cevabını çıkarırız: hangi programlar çalışıyor, kaynak kod var mı, sunucu nerede duruyor, yedek nasıl alınıyor, lisanslar kimin adına, hangi entegrasyonlar aktif. Bu çalışma için fabrikaya gelir, sunucu odasına da gireriz. Sonunda dürüst bir tablo verilir; bazı sistemler için doğru cevabın bakım değil devralma veya yenileme olduğunu da söyleriz.
- 02
Riskin durdurulması
Sözleşme konuşmadan önce en acil riskleri kapatırız: yedek alınmıyorsa alınır, alınan yedek geri yüklenerek sınanır, üretimi durdurma ihtimali yüksek açık varsa öne alınır. Bir sistemi devralırken ilk iş onu geliştirmek değil, düşmesini engellemektir.
- 03
Kapsamın ve çağrı yolunun yazılması
Neyin dahil olduğu, neyin ayrı ücretlendirileceği, kimin kimi hangi kanaldan arayacağı ve hangi durumun acil sayılacağı yazılı hale gelir. Bu belgenin bir kopyası üretim müdüründe, bir kopyası muhasebede durur; çünkü arıza anında sözleşmeyi arayan kişi genelde onu imzalayan kişi olmuyor.
- 04
İzlemenin kurulması ve aylık ritim
İzleme ve uyarı düzeni kurulur, ardından aylık bir ritme geçilir: ay başında iş listesinin önceliklendirilmesi, ay içinde geliştirme, ay sonunda ne yapıldığının yazılı olarak paylaşılması. Ne yaptığını anlatmayan bir bakım hizmeti, ödendiği sürece görünmez kalır ve ilk bütçe sıkışmasında kesilir.
- 05
Çeyreklik gözden geçirme
Üç ayda bir masaya oturur, geçen dönemi ölçtüğümüz veriyle konuşuruz: kaç arıza çıktı, hangi kök nedenden geldi, hangi işler tekrar tekrar geliyor. Aynı arızanın tekrarlanması bir bakım konusu değil, bir tasarım konusudur; buradan çıkan işler bir sonraki dönemin geliştirme listesine girer.
Sık sorulanlar
Yazılımı siz yapmadınız, yine de bakım verir misiniz?
Evet, ama önce bakarız. Bir sistemi anlamadan bakım sözü vermek dürüst olmaz. İlk aşama envanter ve durum tespitidir: kaynak kod, veritabanı, sunucu ve entegrasyonlar incelenir. Sonunda dürüst bir cevap alırsınız; bazen bu cevap bakım verebiliriz olur, bazen de bu sistemin bakımını üstlenmek yerine önce devralma çalışması yapmak gerekiyor olur. İkisi farklı işlerdir ve ayrı ayrı fiyatlanır.
Kaynak kodumuz elimizde yok, bu iş yürür mü?
Çoğu durumda yürür. Derlenmiş uygulama ve veritabanı elinizdeyse programın ne yaptığı büyük ölçüde çıkarılabilir. Bunu daha önce yaptık: bir kurumsal uygulamanın günlük hesap formülünü kanıtıyla çözdük, ancak aylık hesaplama katmanı eksik kaldı ve bunu raporda açıkça eksik olarak işaretledik. Bazı bilgiler yalnızca kaynak kodda yaşar ve geri getirilemez; size vaat değil, neyin bilinip neyin bilinmediğini gösteren bir harita veririz.
Kaç saatte müdahale ediyorsunuz?
Herkese aynı süreyi söyleyen bir tabelamız yok, çünkü ihtiyaç aynı değil. Süreler sözleşmede, sizin çalışma düzeninize göre yazılır: üretimi durduran arıza için ilk cevap süresi, yerinde müdahale gerektiren durumlar ve mesai dışı kapsamı ayrı ayrı tanımlanır. Aynı şehirde olmamızın somut faydası burada görülüyor; yerinde bakılması gereken bir işte Başpınar veya Şehitkamil'e gelmek, başka şehirden ekip beklemekle aynı şey değil.
Aylık geliştirme kapasitesi tam olarak ne demek?
Ayda belirli sayıda iş gününü sizin geliştirme listenize ayırmamız demek. Her küçük talep için ayrı teklif, onay ve fatura döngüsü yaşamazsınız; iş listesi ay başında birlikte sıralanır ve ay içinde öncelik değişebilir. Kullanılmayan kapasitenin devredip devretmeyeceği, hangi işlerin bu kapsamın dışında sayılacağı sözleşmede açıkça yazılır. Sürekli küçük geliştirme ihtiyacı olan işletmelerde bu model bütçeyi öngörülebilir yapar.
Mevcut yazılımcımızla birlikte çalışabilir misiniz?
Çalışabiliriz ve bazı durumlarda doğru olan budur. Sistemi yıllardır tanıyan birinin bilgisi değerlidir; onun yerini almak yerine yükünü paylaşmak, özellikle geçiş dönemlerinde daha az risklidir. Böyle bir düzende kimin hangi alandan sorumlu olduğunu ve değişikliklerin nasıl kayda geçeceğini baştan netleştiririz. İki ekibin aynı yere habersiz dokunması, tek ekibin yavaş çalışmasından daha büyük sorun çıkarır.
Bakım sözleşmesi olmadan tek seferlik iş yapıyor musunuz?
Evet. Belirli bir arıza, tek bir rapor, bir entegrasyonun düzeltilmesi ya da sistem yavaşlığının teşhisi gibi işler kapsamı ve süresi baştan yazılı tek seferlik paketlerle yapılabilir. Bakım sözleşmesini bir ön koşul olarak dayatmayız. Yalnızca şunu söyleriz: tek seferlik müdahale, sistemin ayakta kalmasını üstlenmek anlamına gelmez ve o sorumluluk sözleşme olmadığı sürece sizde kalır.
Sunucumuz fabrikada duruyor, buluta taşımamız şart mı?
Şart değil. Sunucunun fabrikada durmasının haklı gerekçeleri olabilir: makinelere yakınlık, internet kesintisinde üretimin durmaması, veri sahipliği. Biz iki düzende de bakım veririz. Yerinde duran sunucuda kritik olan şey konum değil, yedeğin gerçekten geri yüklenebilmesi ve odanın elektrik ile sıcaklık tarafının düşünülmüş olmasıdır. Bunları tespit aşamasında yerinde kontrol ederiz; OSB'de sunucunun üretim alanının içindeki bir dolapta durduğu tesisler gördük.
Sözleşmeyi bitirmek istersek ne oluyor?
Ayrılırsınız ve elinizde her şey kalır: kaynak kod, veritabanı, yapılandırma, değişiklik kayıtları ve devir dosyası. Bakım ilişkisini bir kilit olarak kurmayız; devir dosyasını zaten ilişkinin ilk gününden itibaren, başkasının da devam edebileceği varsayımıyla hazırlarız. Bizimle devam etme nedeniniz mecburiyet değil, işi doğru yapmamız olsun isteriz.
Gaziantep'te diğer yazılım başlıkları
Önce sistemin durumuna bakalım
Hangi programların üzerinde iş yürüdüğünü, kaynak kodun nerede olduğunu ve yedeğin gerçekten geri yüklenip yüklenmediğini birlikte çıkaralım. Bu tespit tek başına bile işe yarar; bakımı üstlenmek gerekip gerekmediğine ondan sonra karar verirsiniz. Aynı şehirdeyiz, gelmek bir telefon meselesi.