DeskGate Yardım Merkezi
DeskGate Personel Takip Sistemi Seçimi ve Kurum İçi Kurulum
Personel takip sistemi seçimi: ihtiyaç analizi, kendi altyapınızda kurulum, pilot kabulü, yetkiler ve sürdürülebilir işletim.
Personel takip sistemi seçerken ilk karar, hangi çalışma bilgisinin yönetileceğidir. Fiziksel giriş ve çıkış, bilgisayar etkinliği, görev durumu, izin planı ve ücret hesabı birbiriyle ilişkili olabilir; ancak aynı veriyi veya aynı işlevi ifade etmez. Bu alanları tek bir özellik adı altında toplamak, satın alma aşamasında yanlış beklenti oluşturabilir. İhtiyaç belgesinde her sorunun hangi kayıtla yanıtlanacağını ve kararın hangi ekip tarafından verileceğini açıklamak, ürün değerlendirmesini daha somut hale getirir.
DeskGate, bilgisayar etkinliği ve kullanım raporlarını kurumun kendi altyapısında değerlendirmek isteyen kuruluşlar için ele alınabilir. İş Analizi, Günlük Aktivite, kullanıcı ve cihaz kapsamı gibi mevcut özellikler farklı yönetim sorularına yardımcı olur. Bu rehber; ihtiyaçların yazılması, kurulum sorumluluklarının belirlenmesi, pilot kapsamın seçilmesi ve kabul kontrollerinin hazırlanması üzerinde durur. Bir sistemin kurum içinde çalıştırılması, bütün güvenlik ve işletim sorumluluklarının kendiliğinden çözüldüğü anlamına gelmez. Sağlıklı seçim, ürünün yaptığı işleri doğrulamak kadar kurumun üstleneceği işleri de açıkça tanımlamayı gerektirir.
Personel takibinden beklediğiniz sonucu tarif edin
Bir değerlendirme toplantısına özellik isimleriyle başlamak yerine çözülmek istenen soruları yazın. Yöneticiler bilgisayar kullanımına ilişkin görünürlük mü istiyor, teknik ekip hangi cihazların kapsama girdiğini mi görmek istiyor, yoksa insan kaynakları fiziksel devam kayıtlarını mı düzenliyor? Bu sorular birbirine benzeyen kelimelerle ifade edilse de farklı veri kaynakları gerektirir. Sistem seçiminin ilk aşamasında her soruyu işin sahibiyle birlikte netleştirmek, sonraki ürün görüşmelerinin daha verimli olmasını sağlar.
İhtiyaç belgesinde beklenen çıktıyı ve kullanılacağı kararı birlikte belirtin. Örneğin belirli bir uygulamanın kullanımını incelemek isteyen yönetici için kullanıcı, dönem ve uygulama kapsamı önemlidir. Fiziksel giriş ve çıkış sorusunda ise geçiş kaydının kaynağı ve düzeltme süreci belirleyicidir. Bu ayrım yapılmadan hazırlanan genel bir personel takip listesi, karşılaştırılması mümkün olmayan özellikleri aynı satıra yerleştirebilir. İyi tanımlanmış gereksinim, değerlendirmeyi yalnızca sunumun etkileyiciliğine bırakmaz; hangi bilginin hangi koşulda gösterilmesi gerektiğini önceden belirler.
Zorunlu ihtiyaçlarla tercihleri birbirinden ayırın
Kuruluşun vazgeçemeyeceği gereksinimler ile işleyişi kolaylaştıran tercihler aynı öncelikte değerlendirilmemelidir. Verinin hangi ortamda tutulacağı, hangi kullanıcı gruplarının kapsanacağı ve gerekli raporun hangi soruyu yanıtlayacağı temel kararlar olabilir. Bir raporun görünümüne ilişkin tercih ise bu kararları destekleyen ayrı bir konudur. Değerlendirme sırasında her talebin gerekçesini açıklayın. Böylece yalnızca alışılmış olduğu için istenen bir özellik ile belirli bir iş sorununun çözümü için gereken özellik ayrılabilir.
Zorunlu gereksinimler için doğrulama yöntemini de yazın. Bir özelliğin sunumda anılması yerine seçilen sürümde, kararlaştırılan kapsamda ve kurumun koşullarına uygun şekilde gösterilmesi istenebilir. Tercihler için ise ürünün mevcut yaklaşımının iş akışına uyup uymadığı değerlendirilir. Üründe doğrulanmamış bir işlevi gelecekte yapılacak varsayımıyla temel ihtiyaç olarak kabul etmeyin. Geliştirme veya entegrasyon gerekiyorsa kapsamı, sorumlusu ve kabul yöntemi ayrıca belirlenmelidir. Bu ayrım, değerlendirme tamamlandıktan sonra ortaya çıkabilecek beklenti farklılıklarını azaltır.
Veri türlerini ve kaynaklarını bir envanterde toplayın
Kurumda zaten bulunan kayıtları incelemek, yeni sistemin rolünü tanımlamaya yardımcı olur. Bilgisayar etkinliği, fiziksel geçiş, görev yönetimi ve çalışma takvimi farklı kaynaklardan gelebilir. Her kaynak için verinin anlamını, kim tarafından yönetildiğini ve hangi dönemi kapsadığını belirleyin. Aynı kullanıcı adı iki sistemde farklı kişi veya hesap anlamına gelebiliyorsa bu eşleştirme sorunu kurulumdan önce görülmelidir. Veri kaynağını bilmeden yalnızca ortak bir rapor görünümü istemek, yanlış birleştirmelerin önünü açabilir.
DeskGate değerlendirmesinde bilgisayar kullanımına ilişkin bilgiler ile kurumun başka sistemlerden aldığı kayıtlar ayrıştırılmalıdır. Kullanıcı ve cihaz kapsamı, uygulama kullanım bilgisi ve aktif ya da pasif süreler kendi tanımlarıyla ele alınır. Başka bir kaynaktan gelen devam kaydı varsa onun geçerliliği ve düzeltme süreci ayrı kalır. Envanter, bütün verilerin tek yere taşınması gerektiği anlamına gelmez. Bazen gerekli sonuç, farklı kaynakları yetkili kişilerin belirli bir amaçla karşılaştırmasıyla elde edilir. Gereksiz veri çoğaltmadan karar için gereken bağlantıyı kurmak, sistemin işletimini de sadeleştirir.
Kurum içi dağıtımın sahipliğini belirleyin
DeskGate'in kendi altyapınızda çalıştırılması, uygulama ortamının kurumun belirlediği koşullarda işletilmesine olanak verir. Bunun karşılığında altyapı, yedekleme, erişim, güncelleme ve sorun yönetimi gibi konuların kimin sorumluluğunda olduğu açık olmalıdır. Uygulama ekibi ile sunucu ekibinin aynı kişiler olması şart değildir; ancak hangi kararın kim tarafından verileceği belli olmalıdır. Kurulumun tamamlanması ile günlük işletimin devralınması ayrı aşamalardır. Proje planı yalnızca yazılımın çalışır hale geldiği güne odaklanmamalıdır.
İşletim sahipliğini kişi adına değil görev sorumluluğuna bağlayın. Sunucu erişimini yöneten rol, veritabanı bakımını izleyen rol ve uygulama yetkilerini düzenleyen rol tanımlanabilir. İzin veya görev değişikliği olduğunda sürecin devam edebilmesi için gerekli dokümanlar tutulmalıdır. Sorun halinde ürün desteğine hangi bilgilerin sağlanacağı ve kurum içi incelemenin nerede başlayacağı da önceden kararlaştırılmalıdır. Böylece her olayda kimin ilgileneceğini yeniden belirlemek gerekmez. Kendi altyapısında çalışan sistemin faydası, bu işletim sorumlulukları düzenli biçimde yerine getirildiğinde sürdürülebilir olur.
Kapasite planını gerçek kapsam üzerinden hazırlayın
Sunucu kapasitesini yalnızca çalışan sayısına bakarak belirlemek yeterli değildir. Kapsamdaki cihazlar, kullanılan özellikler, rapor dönemleri, erişim yoğunluğu ve saklama ihtiyaçları birlikte değerlendirilmelidir. Bir çalışanın birden fazla bilgisayarı olabilir; bazı bilgisayarlar farklı kullanıcılar tarafından paylaşılabilir. Bu nedenle kullanıcı sayısı ile cihaz sayısını birbirinin yerine kullanmayın. Ürünün seçilen sürümü ve planlanan işlevleri için teknik gereksinimler doğrulanmalı, kurumun altyapı planı bu bilgiler üzerine kurulmalıdır.
Pilot aşamada hedef, kapasite hakkında kesin ve genellenebilir sonuç uydurmak değil, gerçek kullanım koşullarının hangi noktaları etkilediğini görmektir. Rapor açma davranışı, aynı anda çalışan yöneticiler ve seçilen tarih aralıkları değerlendirmeye dahil edilebilir. Küçük bir pilotun sonuçlarını doğrudan bütün kuruma ölçeklemek yerine, büyüme sırasında hangi ölçümlerin tekrar kontrol edileceğini belirleyin. Ek cihazların veya yeni rapor ihtiyaçlarının hangi aşamada altyapı değerlendirmesi gerektireceği bilinmelidir. Teknik plan, satın alma anındaki sayıya sabitlenmiş bir varsayım değil, kapsam değiştikçe gözden geçirilecek bir işletim belgesi olmalıdır.
Ağ erişimini kullanım senaryolarına göre tasarlayın
Uygulamayı kullanacak yöneticilerin ve kapsamdaki cihazların hangi ağ koşullarında bulunduğunu belirlemek kurulum hazırlığının parçasıdır. Tek ofis, birden fazla şube ve uzaktan çalışan cihazlar aynı erişim modelini gerektirmeyebilir. Ağ ekibi, bağlantı gereksinimlerini seçilen ürün sürümünün dokümanlarıyla birlikte değerlendirmelidir. Doğrulanmamış port veya erişim bilgilerini varsayımla açmak yerine, gerekli iletişim yollarını ve bunların sorumlularını netleştirin. Ağ tasarımı güvenlik sınırlarını korurken uygulamanın ihtiyaç duyduğu erişimi sağlamalıdır.
Pilot değerlendirmesine yalnızca merkez ofisteki kolay bağlantı koşullarını dahil etmeyin. Gerçek dağıtımda bulunacak farklı ağ durumlarını temsil eden kapsam seçin. Bağlantı değiştiğinde hangi verinin ne zaman görülebildiği ve sorun durumunun nasıl araştırıldığı anlaşılmalıdır. Ancak bir bağlantı testi, kurumun bütün güvenlik gereksinimlerini karşıladığının kanıtı olarak sunulmamalıdır. Erişim kuralları, kimlik doğrulama, sertifika yönetimi ve olay takibi kurumun ilgili ekiplerince ayrı sorumluluklarla ele alınır. Uygulama kurulumu ile ağ güvenliği kararlarının birbirine bağlı olduğu noktalar açıkça belgelenmelidir.
Kullanıcı ve cihaz modelini kurulumdan önce netleştirin
Kurulum listesindeki her cihazın kim tarafından ve hangi görev için kullanıldığını bilmek, raporların anlamını etkiler. Paylaşılan bilgisayarlar, geçici cihazlar, birden fazla hesabı olan kullanıcılar veya farklı ekipler arasında dolaşan cihazlar için açık bir kapsam gerekir. İsimlerin benzemesi, kayıtların aynı kişiye ait olduğunu göstermeyebilir. Kullanıcı eşleştirmesinde kurumun güncel organizasyon bilgisi ile teknik hesap bilgisi birlikte değerlendirilmelidir. Bu hazırlık yapılmadan başlayan pilot, raporların doğruluğundan önce kimlik belirsizlikleriyle uğraşmak zorunda kalabilir.
Grup yapısı seçilirken yalnızca mevcut organizasyon şemasını kopyalamak yerine rapor sorumluluklarını düşünün. Hangi yönetici hangi ekibi değerlendirecek, geçici görevlendirmeler nasıl açıklanacak ve ekip değiştiğinde erişim kim tarafından gözden geçirilecek? Bu soruların yanıtı, raporların yanlış kişilere veya yanlış kapsamla paylaşılmasını azaltır. Geçmiş dönem verisinin bugünkü organizasyon yapısıyla aynı olduğu varsayılmamalıdır. Bir cihazın veya kullanıcının grubu değiştiğinde, karşılaştırmalarda bu değişikliğin nasıl dikkate alınacağı belirlenmelidir. Temiz bir kimlik modeli, sistemin yalnızca kurulmasını değil, zaman içinde anlaşılır kalmasını sağlar.
Rapor gereksinimlerini ekran adından daha ayrıntılı yazın
Bir değerlendirme belgesinde yalnızca rapor var yazılması yeterli değildir. Raporun hangi kullanıcıları, hangi tarih aralığını ve hangi veri türünü kapsaması gerektiği belirlenmelidir. DeskGate İş Analizi ekranında grup, kullanıcı ve tarih seçimleriyle kapsam oluşturulur; aktif ve pasif süreler ile uygulama ve web kullanımına ilişkin bilgiler incelenebilir. Bu özelliklerin kurumun sorusunu nasıl desteklediği, seçilen bir inceleme senaryosuyla gösterilmelidir. Ekranı açabilmek ile ihtiyacı karşılayan değerlendirmeyi yapabilmek farklı kabul ölçütleridir.
Rapor çıktıları için de alıcı ve amaç tanımlayın. Özet PDF ile detaylı PDF aynı kullanım ihtiyacına hizmet etmek zorunda değildir. Detaylı çıktının sınırsız olay geçmişi içerdiğini varsaymak yerine kullanılan çıktının kapsamını ve detay sınırlarını doğrulayın. Raporu devralan kişi, seçilen tarih ve kullanıcı kapsamını anlayabilmelidir. Bir yönetici genel görünüm isterken teknik ekip belirli bir olayın bağlamına ihtiyaç duyabilir. Kabul değerlendirmesinde bu iki ihtiyacı aynı dosyanın karşılayacağı varsayımına bağlamadan, her biri için uygun görünümü ve paylaşım yolunu kontrol edin.
Zaman ve etkinlik tanımlarını kabul belgesine ekleyin
Günlük Aktivite raporunun zaman temeli, bir personel takip sistemi değerlendirmesinde açıkça anlaşılmalıdır. DeskGate'te bu görünüm günün tamamını, yani 00.00 ile 24.00 arasındaki 1.440 dakikayı temel alır. Aktif ve pasif sürelerin anlamı bu çerçevede okunmalıdır. Pasif süreyi doğrudan mesai içindeki devamsızlık veya çalışılmamış ücret süresi olarak tanımlamak doğru değildir. Görevin bilgisayar dışındaki kısmı ve planlanan çalışma koşulları ayrı kaynaklarla değerlendirilir.
Aynı rapor PC açılış ve kapanış saatlerini göstermez. Kabul sırasında bu ayrım yazılı olduğunda, uygulama kullanıma alındıktan sonra rapordan başka bir veri türünün beklenmesi önlenir. Fiziksel giriş ve çıkış, oturum erişimi, bilgisayar etkinliği ve çalışma takvimi ayrı tanımlardır. Birinin kaydını diğerinin kanıtı haline getirmeden, kurumun her soru için hangi kaynağa başvuracağını belirleyin. Bu yaklaşım ürünün kapsamını küçültmek için değil, onu doğru kullanım yerine yerleştirmek için gereklidir. Veri tanımları net olduğunda raporlardan alınan sonuçlar da daha tutarlı olur.
Entegrasyon talebini somut bir veri akışı olarak değerlendirin
Bir personel takip sistemi için entegrasyon istendiğinde önce hangi verinin hangi yönde aktarılacağı belirlenmelidir. Kullanıcı eşleştirmesi, organizasyon bilgisi veya başka bir kaynaktan gelen kayıtlar farklı ihtiyaçlardır. API bulunması, bütün insan kaynakları veya devam sistemleriyle hazır bağlantı olduğu anlamına gelmez. DeskGate değerlendirmesinde kullanılacak bağlantının, sürümün, veri biçiminin ve eşleştirme yönteminin desteklendiği doğrulanmalıdır. Doğrulanmamış bir bağlantı, kurulum planında hazır özellik gibi gösterilmemelidir.
Entegrasyonun kabulü yalnızca ilk aktarımın başarılı olmasıyla bitmez. Eksik kullanıcı, tekrarlanan kayıt, yanlış tarih veya başarısız aktarım gibi durumların nasıl fark edileceği ve kimin düzelteceği belirlenmelidir. Kaynak sistemde yapılan bir değişikliğin hedefte hangi etkiyi oluşturduğu anlaşılmalıdır. Fiziksel PDKS verisi söz konusuysa geçiş kaydının anlamı korunmalı, bilgisayar etkinliğiyle aynı ölçüm gibi sunulmamalıdır. İki kaynağı bir arada kullanmak yararlı olabilir; ancak bu yarar doğru eşleme, açıklanmış veri sorumluluğu ve doğrulanmış destek kapsamına bağlıdır.
Yetkilendirmeyi gerçek görevlerle eşleştirin
Uygulama erişimi planlanırken yalnızca kaç yönetici hesabı açılacağı sorulmamalıdır. Kimin hangi kullanıcı grubuna, hangi rapora ve hangi amaçla erişmesi gerektiği değerlendirilmelidir. Teknik işletim sorumluluğu ile personel değerlendirme sorumluluğu aynı kişide olmak zorunda değildir. Bir sunucuyu yöneten kişinin bütün personel raporlarını incelemesi gerektiği varsayılmamalıdır. Yetki tasarımı, kurumun görev dağılımına ve gerçek erişim ihtiyacına dayanmalıdır. Seçilen ürün sürümünde bu ihtiyaçların nasıl uygulanabildiği doğrulanmalıdır.
Kabul aşamasında farklı görevleri temsil eden yetkili hesaplarla kapsam kontrolü yapılabilir. Burada amaç gerçek çalışanların gereksiz ayrıntılarını açmak değil, kurumun onayladığı sınırlar içinde erişim davranışını doğrulamaktır. Görev değişikliği ve işten ayrılma durumlarında erişimin kimin tarafından güncelleneceği işletim sürecine eklenmelidir. Yönetici yetkileri zamanla genişleyip unutulmamalıdır. Düzenli kontrol yöntemi ve sorumlusu belli olduğunda, ilk kurulumda alınan kararların sonraki aylarda da geçerli kalıp kalmadığı izlenebilir. Yetkilendirme bir defalık ayar yerine sürdürülen bir sorumluluk olarak ele alınmalıdır.
Pilot kapsamı gerçek çalışma çeşitliliğini temsil etsin
Pilot uygulama için yalnızca teknik açıdan sorunsuz birkaç cihaz seçmek, geniş dağıtımda karşılaşılacak koşulları göstermeyebilir. Farklı görev türleri, ortak cihaz kullanımı, değişen ağ erişimi ve farklı yönetici ihtiyaçları göz önünde bulundurulmalıdır. Pilotun kapsamı gereksiz yere büyütülmeden, gerçek çalışma düzeninin önemli çeşitliliğini temsil etmesi hedeflenebilir. Hangi durumların denendiği ve hangi durumların henüz değerlendirilmediği açıkça yazılmalıdır. Böylece sınırlı bir deneme bütün kurum için kesin sonuç gibi sunulmaz.
Pilot boyunca gözlemleri ürün işlevi, yapılandırma, veri kalitesi ve organizasyon süreci olarak ayırın. Bir raporun beklentiyi karşılamaması bazen yanlış filtre seçimiyle, bazen ihtiyacın yanlış tanımlanmasıyla ilişkili olabilir. Sorunu doğrudan tek bir nedene bağlamak yerine hangi aşamada oluştuğunu araştırın. Çözülen sorunların yeniden kontrol edildiği ve açık kalanların sorumlusunun belirlendiği bir kayıt tutulabilir. Pilotun sonunda yalnızca çalışıyor sonucuna ulaşmak yerine, hangi koşullarda hangi gereksinimlerin doğrulandığını açıklayabilmek gerekir. Bu bilgi geniş dağıtım kararının somut dayanağını oluşturur.
Kabul ölçütlerini gözlenebilir davranışlara bağlayın
Başarılı bir kabul belgesi, belirsiz memnuniyet ifadeleri yerine gözlenebilir sonuçlar içerir. Yetkili kişinin doğru kullanıcı grubunu seçebilmesi, istenen tarih aralığında rapor oluşturabilmesi ve çıktının kapsamını anlayabilmesi kontrol edilebilir davranışlardır. Aynı şekilde bir kimlik eşleştirme sorununun fark edilmesi ve belirlenen süreçle düzeltilmesi de işletim açısından önemlidir. Ölçütler, ürünün doğrulanmış özellikleri ve kurumun gerçek ihtiyaçlarıyla uyumlu olmalıdır. Gösterilmeyen veya kapsam dışı bırakılan özellikler tamamlanmış gibi kaydedilmemelidir.
Her ölçüt için sonucu kimin değerlendireceği ve hangi bilgiyle karar vereceği yazılabilir. Teknik ekip bağlantı ve işletim koşullarını, raporu kullanacak yönetici ise kapsamın anlaşılabilirliğini inceleyebilir. Kabul sürecinin sonunda açık konular kalmışsa bunların dağıtıma etkisi belirtilmelidir. Küçük bir görsel tercih ile veri eşleştirmesini etkileyen bir sorun aynı ağırlıkta değildir. Önceliklendirme, kararın sonradan anlaşılmasını sağlar. Kabulün amacı sorunları gizlemek değil, kullanılacak kapsamın hangi koşullarla hazır olduğunu ve hangi adımların devam edeceğini netleştirmektir.
Yedekleme ve geri dönüş sorumluluğunu devre hazırlayın
Kurum içi kurulumda verinin korunması, uygulama çalışmaya başladıktan sonra düşünülecek bir ayrıntı değildir. Hangi bileşenlerin yedekleneceği, yedeklerin nerede tutulacağı, erişim sorumluluğu ve geri dönüş sürecinin nasıl doğrulanacağı ilgili teknik ekiplerle planlanmalıdır. Bu plan ürünün seçilen kurulum biçimiyle uyumlu olmalıdır. Bir dosyanın kopyalanması veya yedekleme işinin çalışmış görünmesi, geri dönüşün uygulanabilir olduğunu tek başına göstermez. Kurumun işletim yöntemi, gerçek bir ihtiyaç oluştuğunda izlenecek adımları açıklamalıdır.
Güncelleme ve bakım işlemlerinde de sorumluluk dağılımı açık olmalıdır. İşlem öncesi hangi kontrollerin yapılacağı, hangi kullanıcıların bilgilendirileceği ve sorun halinde kime başvurulacağı belirlenebilir. Uygulama sürümü değiştiğinde rapor veya bağlantı davranışlarını etkileyen değişiklikler gözden geçirilmelidir. Bu rehber belirli bir yedekleme ürünü veya teknik komut önermek yerine, sahipliği ve doğrulama ihtiyacını vurgular. Kurumun kullandığı altyapı ve güvenlik standartları farklı olabilir. İşletim planının amacı bu koşullar içinde uygulamanın sürdürülebilirliğini sağlamaktır.
Eğitimde raporun sınırlarını da anlatın
Kullanıcı eğitimi yalnızca hangi düğmeye basılacağını göstermekle sınırlı kalmamalıdır. Raporun ölçtüğü bilgi, seçilen filtrelerin sonucu nasıl değiştirdiği ve yorumun hangi koşullarda ek açıklama gerektirdiği anlatılmalıdır. Özellikle Günlük Aktivite raporundaki pasif süre ile fiziksel devam veya görev sonucu arasındaki ayrım, raporu kullanacak yöneticiler tarafından anlaşılmalıdır. Yanlış bir yorum alışkanlığı oluştuğunda teknik kurulum doğru olsa bile sistemden beklenen yönetim faydası zayıflayabilir.
Eğitim, kurumun gerçek kullanım soruları üzerinden yürütülebilir. Bir ekip kapsamının seçilmesi, tarih aralığının doğrulanması, İş Analizi görünümünün incelenmesi ve uygun PDF çıktısının belirlenmesi birlikte gösterilebilir. Sonraki aşamada yanlış kullanıcı seçimi veya eksik kapsam gibi durumların nasıl fark edileceği konuşulmalıdır. Eğitim sonunda katılımcının yalnızca raporu açabilmesi değil, raporun hangi soruyu yanıtladığını açıklayabilmesi hedeflenmelidir. Yeni yöneticiler göreve başladığında aynı yaklaşımın tekrarlanması, kişilere bağlı farklı değerlendirme alışkanlıklarının oluşmasını azaltır.
Dağıtımı aşamalara ayırın ve değişiklikleri kaydedin
Pilot sonrasında geniş dağıtımın hangi sırayla yapılacağı, teknik kapasite kadar destek ve eğitim imkanlarına da bağlıdır. Her aşamada hangi kullanıcıların kapsama alındığı ve hangi yöneticilerin raporları kullanmaya başladığı bilinmelidir. Değişiklikler kaydedilmezse raporlardaki artış veya azalışın gerçek kullanım davranışından mı, kapsam genişlemesinden mi kaynaklandığını anlamak zorlaşır. Bu yüzden dağıtım planı ile rapor değerlendirmesi arasındaki ilişki korunmalıdır. Yeni eklenen cihazları önceki dönemde de mevcutmuş gibi değerlendirmeyin.
Aşamalı dağıtım, geri bildirimleri değerlendirmek için de alan sağlar. İlk gruplarda ortaya çıkan kimlik, eğitim veya işleyiş sorunları sonraki gruplardan önce ele alınabilir. Ancak her değişikliğin aynı anda bütün kuruma uygulanması gerekmez; etkisi ve kapsamı değerlendirilmelidir. Teknik ekip, yöneticiler ve operasyon sorumluları aynı dağıtım durumunu görebildiğinde iletişim daha açık olur. Projenin tamamlanması için yalnızca cihaz kurulumlarının bitmesi değil, rapor kullanımı ve destek sorumluluklarının da devralınmış olması gerekir.
Destek talebinin hangi bilgiyle açılacağını belirleyin
Uygulama kullanıma alındıktan sonra sorun bildiriminin nasıl yapılacağı da kurulumun parçasıdır. Raporun beklenen kullanıcıyı göstermemesi, belirli bir tarihte verinin eksik görünmesi veya bir bağlantı işleminin başarısız olması farklı inceleme yolları gerektirebilir. Destek talebinde sorun tanımı, ilgili kapsam, zaman aralığı ve gözlenen davranış anlaşılır biçimde verilmelidir. Yetkisiz kişisel ayrıntılar veya gereksiz dosyalar paylaşmadan incelemeyi başlatacak bilgi belirlenebilir. Böylece ilk görüşme yalnızca hangi sorunun konuşulduğunu anlamak için harcanmaz.
Destek sürecinde kurum içi sorumlular ile ürün desteğinin görevleri ayrılmalıdır. Kullanıcı hesabının kurumsal durumunu doğrulamak, ağ erişimini incelemek veya rapor filtresini açıklamak aynı uzmanlığı gerektirmeyebilir. Talebin doğru ekibe yönlendirilmesi için basit bir sorumluluk düzeni oluşturun. Bir sorun çözüldüğünde hangi değişikliğin yapıldığı ve hangi kapsamda sonucun kontrol edildiği kaydedilmelidir. Aynı belirti tekrar ortaya çıkarsa önceki çözümün koşulları bilinmelidir; farklı bir olaya eski işlemi düşünmeden uygulamak yeni sorunlar doğurabilir. Destek kayıtlarından edinilen bilgi, eğitim ve işletim dokümanlarının güncellenmesine de yardımcı olur. Sık tekrarlanan bir filtre hatası için eğitim yeterli olabilirken, veri kaynağıyla ilişkili bir sorun ayrı teknik inceleme gerektirebilir.
Son kararı ürün kapsamı ve işletim hazırlığıyla birlikte verin
Personel takip sistemi seçiminin sonucu, özellik sayılarının toplamından ibaret değildir. Ürünün doğrulanmış işlevlerinin kurumun sorularına ne kadar karşılık verdiği ve kurumun sistemi hangi sorumluluklarla işleteceği birlikte değerlendirilmelidir. DeskGate için bilgisayar etkinliği, kullanıcı ve tarih kapsamı, İş Analizi ve Günlük Aktivite gibi özellikler somut kullanım senaryolarıyla incelenebilir. Fiziksel devam, bordro veya başka bir kaynaktan bilgi aktarımı gerekiyorsa bunların destek durumu ayrıca doğrulanmalıdır.
Karar belgesinde doğrulanan kapsam, açık konular, pilotun sınırları ve işletim sahipleri yer almalıdır. Böylece satın alma görüşmesindeki beklenti ile günlük kullanım arasındaki bağlantı korunur. Kendi altyapınızda çalışmak, verinin ve uygulama ortamının yönetiminde belirli tercihler sunar; bu tercihlerin anlamlı olabilmesi için erişim, bakım, yedekleme ve değerlendirme süreçleri düzenli yürütülmelidir. İyi hazırlanmış bir kurulum, yalnızca çalışan bir uygulama teslim etmez. Hangi verinin neden kullanıldığını bilen yöneticiler, sorumlulukları belirli teknik ekipler ve kapsamı açıklanmış bir çalışma düzeni oluşturur.