Dış kaynak bilgi işlem hizmeti teklifinde neler olmalı?

Dış kaynak bilgi işlem teklifinde önce ne belirlenmeli?

Dış kaynak bilgi işlem hizmeti teklifinde kullanıcı ve cihaz envanteri, desteklenecek sistemler, çalışma saatleri, yerinde ziyaretler, talep yönetimi, raporlama ve kapsam dışı giderler açık olmalıdır. Sağlıklı karşılaştırma için bütün adaylara aynı ihtiyaç belgesi verilmelidir. Yalnızca bilgisayar sayısını yazıp aylık fiyat istemek, farklı hizmet kapsamlarının aynı iş gibi görünmesine neden olabilir.

Bu yazı bir bakım sözleşmesinin bütün hukuki maddelerini hazırlamaz. İşletmenin teklif isterken teknik ve operasyonel ihtiyacını nasıl tarif edebileceğine odaklanır. Genel seçim ölçütleri için kurumsal IT destek seçim rehberini kullanabilirsiniz. Burada ise talep belgesine hangi bilgilerin yazılacağı, sağlayıcıların yanıtlarının nasıl karşılaştırılacağı ve teslimin nasıl tanımlanacağı üzerinde durulur.

İşletmenizin ihtiyacını bir paragrafta anlatın

Başlangıç açıklaması şirketin bütün geçmişini içermek zorunda değildir. Kaç lokasyonda çalışıldığını, yaklaşık kullanıcı sayısını, kritik uygulamaları ve çözülmesini istediğiniz ana sorunu yazın. İçeride bir bilgi işlem çalışanı varsa dış ekibin hangi konularda destek olacağını belirtin. Tamamen dış kaynak modelinde ise günlük kararların ve onayların kim tarafından verileceği ayrıca belirlenmelidir.

Örnek bir ihtiyaç cümlesi şöyle kurulabilir: “Ofis bilgisayarları, ortak dosya erişimi ve e-posta kullanıcı işlemleri için düzenli destek arıyoruz; sunucu taşımasını ayrıca değerlendirmek istiyoruz.” Bu bir müşteri vakası değildir, talebin nasıl sınırlandırılabileceğini gösteren örnektir. Böyle bir açıklama, “bütün IT işlerimizi yapın” ifadesine göre daha uygulanabilir teklifler hazırlanmasını sağlar.

Envanteri yalnız bilgisayarlardan oluşturmayın

Desteklenecek varlıkları kullanıcı bilgisayarları, sunucular, ağ cihazları ve kullanılan bulut hizmetleri şeklinde ayırın. Yazıcı veya özel iş uygulamaları da destek beklentisinin parçası olabilir. Hangi sistemin başka bir firma tarafından yönetildiğini işaretleyin. Sağlayıcının erişemediği veya yetkili olmadığı bir uygulamadan sorumlu tutulması, ileride gereksiz gecikmelere yol açabilir.

Eksiksiz bir envanteriniz yoksa bunu gizlemek yerine ilk incelemenin çıktısı olarak isteyin. Başlangıç kaydı oluşturulması ayrı bir iş yüküdür. Yaklaşık sayıların kesin sayılardan ayrılması da önemlidir. Teklifin hangi varsayımla hazırlandığı bilindiğinde, daha sonra ortaya çıkan cihaz veya lokasyon farklarının kapsamı nasıl etkilediği daha anlaşılır hale gelir.

Günlük destekle proje işini ayrı yazın

Kullanıcının erişim sorunu, yeni personel hesabı ve rutin yazılım ayarı günlük destek içinde değerlendirilebilir. Yeni şube açılışı, sunucu kurulumu veya bütün e-postaların başka platforma taşınması ise proje niteliğinde olabilir. Bu işlerin hepsini tek bir belirsiz aylık bedelin içine yerleştirmek, neyin dahil olduğunun anlaşılmasını zorlaştırır.

Talep belgesinde devam eden ihtiyaçlarınızı ve beklediğiniz projeleri iki ayrı başlıkta verin. Sağlayıcıdan da aynı ayrımla yanıt isteyin. Bir projenin ayrıca fiyatlandırılması tek başına olumsuz değildir; önemli olan bunun başlangıçta bilinmesidir. Yeni bir işin nasıl talep edileceği, hangi aşamada onay alınacağı ve bedelin ne zaman netleşeceği açıkça anlatılmalıdır.

Talep kanalı ve onay sorumlusu belirli olsun

Çalışanların destek talebini hangi kanaldan ileteceğini yazın. Telefon, e-posta veya kayıt sistemi kullanılabilir; tercih edilen yöntemin işletmenin çalışma biçimine uygun olması gerekir. Kullanıcı hesabı açma, yetki verme ve cihaz teslimi gibi işlemlerde onay verecek kişileri belirleyin. Her çalışanın bütün yönetim değişikliklerini tek başına isteyebileceği varsayılmamalıdır.

Özellikle ortak adresler ve yönetici hesapları için görev ayrımı önemlidir. Teknik ekibin işlemi uygulamasıyla, şirketin erişim kararını vermesi farklı sorumluluklardır. Teklif yanıtında bu akışın nasıl işleyeceğini görmek isteyin. Bir sorun çıktığında kimin karar beklediği ve hangi bilginin eksik olduğu anlaşılabiliyorsa, destek süreci daha izlenebilir yürütülebilir.

Yanıt, inceleme ve çözüm sürelerini ayırın

Bir talebin alındığının bildirilmesi, teknik incelemenin başlaması ve sorunun kalıcı olarak çözülmesi farklı aşamalardır. Sağlayıcının sözleşmede hangi aşama için süre verdiğini öğrenin. İşin internet operatörüne, cihaz tedarikine veya başka yazılım ekibine bağlı olması çözümü etkileyebilir. Bu bağımlılıkların nasıl kayda alınacağı ve takip edileceği teklif içinde açıklanmalıdır.

Önceliği yalnız talebi açan kişinin unvanına göre belirlemeyin. Etkilenen kullanıcılar, iş kaybı ve alternatif çalışma olanağı değerlendirilmelidir. Tek kişinin bir uygulamaya erişememesiyle şirketin tamamının dosya sunucusuna ulaşamaması aynı etkiye sahip değildir. Talep belgesine bu ayrımı anlatan örnekler eklemek, hizmet sağlayıcıların aynı öncelik anlayışıyla teklif vermesine yardımcı olur.

Yerinde ziyaret ve uzaktan destek koşulları

Lokasyonları ve her lokasyonda beklenen çalışma biçimini belirtin. Düzenli ziyaret, yalnız gerektiğinde saha çalışması veya ağırlıklı uzaktan destek seçenekleri farklı iş yükleri oluşturur. Ziyaretin süresi, ulaşım ve mesai dışı çalışma gibi kalemlerin nasıl ele alınacağını sorun. Bir teklifin düşük görünmesinin nedeni yerinde çalışmayı hiç içermemesi olabilir.

Uzaktan erişimde yetkili kişi onayı ve gerekli erişim sınırları belirlenmelidir. İlk teklif aşamasında parolaların bir dosyada paylaşılması gerekmez. Teknik inceleme için hangi erişimin gerektiği, ne kadar süre kullanılacağı ve çalışma sonunda nasıl kaldırılacağı planlanabilir. Bu süreç, hem müşterinin kendi sistemini kontrol edebilmesini hem de hizmetin belirli sorumluluklarla yürütülmesini destekler.

Bakım ve güvenlik işlerinin doğrulamasını isteyin

“Güncellemeler yapılır” ifadesini daha somut hale getirin. Hangi sistemlerin değerlendirileceği, değişikliklerin nasıl onaylanacağı ve işlem sonrası hangi kontrolün yapılacağı sorulabilir. NIST'in kurumsal yama yönetimi rehberi, güncellemelerin belirlenmesi ve önceliklendirilmesinden kurulumun doğrulanmasına kadar bir süreç yaklaşımı açıklar. Bu kaynak bir hizmet sağlayıcısının sertifikası veya belirli bir sözleşmenin uygunluk belgesi değildir.

Yedekleme takibi de benzer şekilde açıklanmalıdır. Başarılı görünen iş kaydı, geri yükleme testinin yapıldığı anlamına gelmez. Hangi yedeklerin kontrol edileceği, testin dahil olup olmadığı ve sorun halinde kimin onay vereceği belirtilmelidir. Teknik raporlar yalnız işlem sayısını değil, açık kalan riskleri ve müşteriden beklenen kararları da göstermelidir.

Teklifleri aynı başlıklarla karşılaştırın

Karşılaştırma tablonuzda desteklenecek varlıklar, çalışma saatleri, saha kapsamı, talep kanalı, raporlama, başlangıç incelemesi ve ek giderler bulunsun. Her adaydan bu başlıklara ayrı yanıt isteyin. Böylece bazı kalemleri hiç içermeyen bir teklifi, daha geniş kapsamlı teklifin doğrudan ucuz alternatifi olarak değerlendirmezsiniz. Eksik yanıtların tamamlanması görüşmenin doğal bir parçasıdır.

Fiyatın yanında hizmet devrini de sorun. Çalışma sona erdiğinde envanter, yönetici erişimleri ve açık taleplerin nasıl aktarılacağı belirli olmalıdır. Şirketin kendi verisi ve sistemleri üzerindeki kontrolü korunmalıdır. Düzenli bilgi işlem hizmeti, her şeyin tek bir kişinin hafızasında kaldığı bir yapı yerine, izlenebilir kayıt ve açıklanabilir sorumluluklar oluşturmalıdır.

Hizmet kabulünü rapor örneğiyle tarif edin

Sağlayıcıdan rapor formatını teklif aşamasında açıklamasını isteyebilirsiniz. İşin yapıldığı tarih, etkilenen sistem, uygulanan işlem, sonuç ve açık kalan başlıklar yararlı alanlardır. Her kurumun aynı ayrıntıyı istemesi gerekmez; rapor işletmenin karar vermesine yardımcı olmalıdır. Yalnız kapanan kayıt sayısı görmek, hangi kritik konuların devam ettiğini anlamaya yetmeyebilir. Açık işlerle tamamlanan işlerin ayrılması bu nedenle önemlidir.

Örnek bir kabul yaklaşımında yeni kullanıcının hesabının açılması, gerekli ortak adrese erişiminin denenmesi ve şirket yetkilisinin sonucu onaylaması istenebilir. Bu gerçek müşteri uygulaması iddiası değil, görev tanımlama örneğidir. Farklı bir sistemde kabul ölçütü değişecektir. Sağlayıcının hangi işlemi yapacağı ve müşterinin hangi kontrolü gerçekleştireceği yazıldığında, yalnızca bir e-posta mesajıyla işin tamamlandığı varsayılmaz.

Aylık değerlendirmede raporun işe yarayıp yaramadığını da gözden geçirin. Sürekli tekrar eden bir sorun yeni proje ihtiyacını gösterebilir; eksik müşteri onayı ise teknik ekibin ilerlemesini durduruyor olabilir. Bunların birbirinden ayrılması, hizmetin yalnız arıza çözme faaliyeti olarak kalmasını önler. Talep belgesinde bu değerlendirme beklentisini belirtmek, raporlama için hangi emeğin ayrılacağını da netleştirir.

Talep belgesine kapsam değişikliğinin nasıl yönetileceğini de ekleyin. Yeni çalışan, yeni lokasyon veya yeni uygulama geldiğinde hangi bilginin paylaşılacağı ve teklifin ne zaman gözden geçirileceği belirli olsun. Büyüme ihtiyacını gizlemek yerine yaklaşık olarak anlatmak daha uygundur. Sağlayıcıdan da başlangıç fiyatının hangi envanter ve kullanım varsayımlarına dayandığını açıkça göstermesini isteyin. Böylece değişiklikler iki taraf için de daha anlaşılır ilerler.

Gönderebileceğiniz teklif talebi taslağı

Bir sayfalık talep belgesinde şirket ve lokasyonlar, yaklaşık kullanıcı/cihaz sayısı, kritik uygulamalar, mevcut sorunlar, günlük destek beklentisi ve ayrı projeler yer alabilir. Buna çalışma saatleri, yerinde ziyaret ihtiyacı, onay sorumlusu ve raporlama beklentisini ekleyin. Sağlayıcıdan dahil olmayan işleri ve başlangıç incelemesinde doğrulanacak varsayımları ayrıca belirtmesini isteyin.

İz Medya bilgi işlem ve IT hizmeti için bu taslakla kapsam görüşmesi başlatabilirsiniz. Belgenizin eksiksiz olması gerekmez; bilinmeyen başlıklar ilk incelemede ele alınabilir. Önemli olan, hangi ihtiyacın hazır bilgiye dayandığını ve hangi konunun araştırılacağını ayırmaktır. Böylece alınan teklif, yalnız aylık bir rakam yerine uygulanabilir bir çalışma düzenini tarif eder.

Sık Sorulan Sorular