Çoğu izleme sistemi yerel bir Sunucuya veya PC'ye yüklenen yazılıma dayanır - izleme yazılımı tipik olarak test edilmiş ve doğrulanmıştır, çalışır, raporlama, alarm verme ve genel görüntüleme için gerekli olan olağan işlevleri yerine getirir. Ama herkes mutlu mu?
Zaman geçtikçe bazı düzenlemeler değişir - yazılımınızın bir parçası olmayan bazı özellik gereksinimleri olabilir veya sistemin hızı izlenen konumların genişlemesine ayak uyduramaz. BT, onaylanmış sisteminizin şirket ağında kalması için güvenlik yamalarına ihtiyaç duyduğuna karar verir - Sunucunuzun ek iş yüklerine ayak uydurmak için yükseltilmesi gerekir, veri yedeklemeleriniz çalışmayı durdurmuştur (sizin haberiniz olmadan) ve şimdi BT güvenlik yamaları izleme yazılımınıza erişimi durdurmuştur veya daha da kötüsü, izlemeyi tamamen durdurmuştur!
Bu senaryolar, 3. taraf bir uygulama veya izleme yazılımı ile yerel bir sunucuya bakmanın tipik bir örneğidir ve geçmişte genellikle işin bir parçası olarak kabul edilirdi. Yazılımı çalışır durumda tutmak için harcanan zaman ve çaba yorucu olabilir - ancak veri kaybı ya da sürekli izleme olanağı, şirket için mali açıdan kabul edilebilir değildir. Sadece bir yazılım parçasını çalıştırmak için QA, QC, Facilities ve IT'yi dahil etmek zorunda kalmak uygulanabilir bir çözüm değildir. Bir de işin içine Uygulamayı uzaktan destekleyen 3. taraf Satıcı girince, "ne yanlış gidebilir ki?" sorusunun çok fazla permütasyonu var. Peki cevap nedir?
Neden Sunucu bakımını, Yazılım desteğini, yedekleme/IT çözümlerini ortadan kaldırmayı ve Bulut'a devretmeyi düşünmüyorsunuz? Uğraştığınız tüm sorunlar doğrudan Satıcıya devredilebilirse, bu size büyük ölçüde zaman ve emek tasarrufu sağlayacaktır. Peki bu işin içinde ne var? Riskler nelerdir?
Çoğu şirket artık Bulut tabanlı ürünler veya Hizmet Olarak Yazılım (SaaS) kullanıyor - E-posta, Finans, CRM ve ERP sistemlerinin tümü Bulut tabanlı. Ancak birçok Eczacılık şirketi erken benimsemiyor - veri kaybı veya veri bütünlüğü riskleri çok yüksek görünüyor. Kalite Departmanı açısından bakıldığında, verilerin yerel olması ve kolayca doğrulanması onlara biraz rahatlık sağlar. Doğrulama Ana Planlarının tam olarak neleri kapsadığını bilmek, tüm veri setlerinin önlerine serilmesi - tüm kutuları işaretlemenin tipik yoluydu - kapalı, kontrollü bir sisteme sahip olmak. Şimdi siz onlardan Veliaht Mücevherlerini güvenli bir şekilde saklamaları için 3. bir Tarafa vermelerini istiyorsunuz. Bunu neden yapsınlar ki?!
Teknolojiler değişti. Çoğunlukla daha iyiye doğru. Ancak sorumluluklar değişmedi - aslında şimdi Satıcı Altyapınızı, Platformunuzu veya Hizmet Olarak Yazılımınızı devralıyor. tam Doğrulamanın Satıcı tarafından karşılanmasını sağlamak için daha fazla işbirliğine ihtiyaç vardır, ancak sonuçta sorumluluk Müşteriye aittir.
Aşağıda Şirket ve Satıcının tipik sorumlulukları - yerel Doğrulama ve Bulut Doğrulama senaryoları.
Ancak yine de, resmin tamamı bu değildir - Doğrulama tamamlandıktan sonra - bir Hizmet Seviyesi Anlaşmasının (SLA) yürürlükte olması esastır. SLA tipik olarak Bulut kurulumunuz, erişiminiz, çalışma süreniz, maliyetleriniz vb. ile ilgili bir anlaşmadır. Yönetişim, uyumluluk, depolama konumları ve saklama politikasını kapsayan daha ayrıntılı gereksinimler olabilir. Verilerinize erişimin belgelenmesini ve kabul edilmesini sağlamak için bir Müşteri olarak ihtiyacınız olan her şey.
Kapsamlı bir SLA kullanarak açık ve şeffaf beklentiler belirleyeceksiniz - normalde bu SLA'lar Satıcı tarafından şablon olarak verilir. Bir dizi turdan geçerek beklentiler belirlenebilir ve üzerinde anlaşmaya varılabilir. Ölçülebilir hedefler kullanarak - SLA'lar, devam eden maliyetleri ayarlayabilecek şekilde tanımlanabilir. 99,999 çalışma süresine mi ihtiyacınız var? Verilerinizin 5 dakika veya 5 saat içinde alınabilir olması gerekiyor mu? Buluttan Çıkarma seçeneklerine mi ihtiyacınız var, Bulut sağlayıcılarını değiştirmek ve verilerinizi yanınızda götürmek isteyebilir misiniz? Elbette, mümkün olan en iyi SLA'ya sahip olmak harikadır, ancak bunun uzun bir maliyeti olabilir. İşletmenin yaşayabileceği ve Satıcının sağlayabileceği makul beklentiler belirleyin. Müşterilerin ön pazarlıkların, risk seviyelerinin ve SaaS teslim edilebilirliğinin temelini üstlenebilecek bir İş Ortağı ile çalışmaya istekli olduklarının farkında olmaları gerekir.
Buluta geçmenin yerelleştirilmiş bir sisteme göre birçok avantajı vardır - verilerin erişilebilirliği ve Uygulama desteği sadece başlangıçtır - serinin ilerleyen bölümlerinde Büyük Veriyi ve verilerinizi nasıl akıllı seslere dönüştürebileceğini tartışacağız.
Bir sonraki LabWatch IoT blogunda Bulut GxP gerekliliklerini ve güvenlik politikalarını ele alacağız.
Telif hakkı: Amphenol Corporation