ITIL UYUMLU YARDIM MASASI (HELP DESK) YAZILIMI ÖRNEK TEKNİK ŞARTNAMESİ

1.GENEL ŞARTLAR 1.1. Teklif edilecek ürün hazır, ticari olarak satılan bir ürün olacak, Kurum için özel olarak

geliştirilmeyecektir.

1.2. UYGULAMA’nın Kurumun göstereceği sunuculara kurulması/ konfigürasyonu/uyarlanması (onay mekanizmaları, organizasyon yapısı, sistem yönetim konfigürasyonları, yetkiler, gruplar, aktif dizin/LDAP sunucusu ile senkronizasyon, aktif dizin SSO konfigürasyonunu vb.) Yüklenici tarafından yapılacaktır. Entegre olacak system Api desteğini sağlamalıdır.

1.3. Teklif edilecek UYGULAMA, ITIL süreçlerine göre Olay Yönetimi, Problem Yönetimi, Değişiklik Yönetimi, Konfigürasyon Yönetimi, Servis Seviye Yönetimi ile uyumlu modüllere sahip olacaktır.

1.4. Teklif edilecek UYGULAMA eşzamanlı olarak en az X kullanıcıya hizmet verebilecek düzeyde olmalıdır. Uygulamada kurumun ihtiyacı kadar (x) uzman kullanıcı tanımlanabilmelidir.

1.5. Teklif edilecek uygulama ile ağ içinde x envanter (Kurum ihtiyaçlarına gore değişebilir) taranabilmelidir. Ayrıca manual olarak girilecek envanter sayısı sınırsız olmalıdır. Manual eklenecek envanter için ilave lisans gerekmemelidir.

1.6. UYGULAMA’da kurumun farklı bölgeleri tanımlanabilmelidir, bu bölgeler için bağımsız atamalar, iş akışları, çalışma saatleri, öncelikler tanımlanabilmelidir.

1.7. Farklı bölgeler için farklı konfigürasyon yapılabilmesi desteklenmeli, her bölge kendi içerisinde çağrıları değerlendirilebilmelidir.

1.8. Uygulama üzerinden memnuniyet anketleri gönderilebilmeli, sorular değiştirilebilir olmalı ve sonuçları grafiksel olarak görüntülenebilmelidir.

1.9. Uygulama üzerinde anketler aynı anda farklı dillerde yayınlanabilmelidir.1.10. Uygulama arayüzü üzerinden kurum logoları eklenebilmelidir. Ekranların renkleri

arayüzden kurumsal renklere gore düzenlenebilmelidir. (-Sonradan ekleme) 1.11. UYGULAMA’da yer alan standart ITIL Süreçleri Sistem Yöneticisi tarafından araya ek

süreçler eklenerek kuruma özgü bir şekilde uyarlanabilmelidir.

2.UYGULAMANIN TEKNİK ÖZELLİKLERİ2.1. UYGULAMA, %100 web tabanlı olacak ve merkezi bir sistem üzerinde çalışacaktır.

Https desteği olmalıdır. Kullanıcı bilgisayarlarına ek bir uygulama yüklenmesi gerekmeyecektir.

2.2. UYGULAMA, modüler yapıda olmalı, ara yüzü sade, kolay anlaşılır olmalıdır. Sistem Yöneticisi, kullanıcı ekranlarında Kurum ihtiyaçlarına göre drag-drop(sürükle bırak) tarzı yöntemlerle değişiklikler yapabilmeli, yeni menü, form oluşturabilmelidir. Herhangi bir sayfaya yeni web komponenti ekleyebilmeli, kaldırabilmelidir. Yapılan değişiklikler anında sistemde görünür olmalıdır. Sistemi yeniden başlatma vb. gerektirmemelidir.

Sayfa 1 / 14

2.3. Madde 4.3.’de bahsedilen işlemler Sistem Yöneticisi tarafından UYGULAMA üzerinde kolaylıkla yapılabilmelidir, web üzerinden yapılacak bu işlemler dışında, herhangi bir yere dosya aktarımı, herhangi bir yerdeki dosyaya müdahale, dosyayı güncelleme vb. tarzı işlemlere gereksinim duyulmamalıdır.

2.4. UYGULAMA çoklu dil desteği verebilmelidir, tüm ekranlar, bilgi ve hata mesajları kullanılan dil ile uyumlu olmalıdır. Kullanıcılar web üzerinden sisteme giriş yaptıklarında, UYGULAMA, tarayıcıda kullanılan (browser) dil ne ise, o dille kullanıcıya hizmet vermelidir. Kullanıcı browser da seçili dil den başka bir dil ile sayfayı görüntülemek isterse, browser dilini değiştirmeden, UYGULAMA üzerinde kolay erişilebilir bir kısımdan dil tercihi ayarını yapabilmelidir. Sisteme giriş yapan kullanıcının browser dili, UYGULAMA tarafından desteklenmeyen bir dil olması durumunda, UYGULAMA Türkçe olarak hizmet verecektir. Yani tarayıcı dili desteklenmeyen durumlarda varsayılan dil Türkçe olacaktır.

2.5. Sistem Yöneticisi işlemleri, UYGULAMA üzerinden yapılmalıdır. Sistem yöneticisi Kurum ihtiyaçlarına göre, kullanıcı ekranlarında değişiklikler yapabilmeli, drag-drop(sürükle bırak) tarzı yöntemlerle yeni menü, form oluşturabilmelidir.

2.6. Kendi kurulumu dışında herhangi bir lisanslı uygulama gerektirmeden çalışabiliyor olmalıdır.

2.7. İstendiği takdirde PostgreSQL ve MSSQL 2000, 2005, 2008 desteği olmalıdır.

2.8. İleride Veritabanı sürüm yükseltilmesi gibi durumlarda da sorunsuz çalışabilmelidir.

2.9. Uygulama sunucusu istendiği takdirde sanal sunucu üzerinde çalışabilmelidir.

2.10. UYGULAMA, Windows ve Linux üzerinde sorunsuz çalışabilmelidir.

2.11. UYGULAMA Mozilla Firefox 3.5, Google Chrome 8.0, Internet Explorer 7.0, Safari 5.1 ve üzeri sürümlerinde sorunsuz çalışabilecektir. Kullanıcılar açısından ise platform bağımsız olarak web üzerinden sorunsuz çalışabilmelidir.

2.12. UYGULAMA’da, kullanıcılarının rollerine gore yetkilendirmelerinin yapılabileceği bir yetkilendirme mekanizması olmalıdır. Kullanıcıların sisteme veya belirlenen fonksiyonlara erişimi yetkilendirmeler ile yapılabilmelidir. Bu tanımlamalar parametrik olmalı ve UYGULAMA üzerinden düzenlenebilmelidir.

2.13. Sistem Yöneticisi roller tanımlayabilir, tanımlanan roller ile kullanıcıları ilişkilendirilebilir. Bir kullanıcı birden fazla role sahip olabileceği gibi, roller de birçok kullanıcı ile ilişkilendirilebilir. Sistem Yöneticisi oluşturduğu role ilişkin yetki verme işlemlerini yapabilmelidir. Yetkiler ile roller ilişkilendirilebilir olmalı, roller bir ya da birden çok yetkiye sahip olabilmelidir.

2.14. Bir kullanıcı birden fazla role sahip olabilecektir. Kullanıcı sahip olduğu rollerin birleşimi şeklinde yetkiye sahip olacaktır.

2.15. UYGULAMA’da bulunan formlar tanımlanan farklı kullanıcı profillerine özel olarak düzenlenebilir olmalıdır.

2.16. Sistem Yöneticisi, kullanıcı/birim/rol/grup tanımlayabilecek, bunları aktif /pasif hale getirebilecektir.

Sayfa 2 / 14

2.17. Kullanıcı, rol ve gruplar bazında menüler UYGULAMA üzerinden uyarlanabilmelidir. Hangi kullanıcı, rol ve grubun hangi menü ve alt menüleri görebileceği belirlenebilmelidir.

2.18. Operatörlerin yaptığı tüm işlemlerin kaydı tutulacak, kayıtlar geriye dönük olarak sorgulanabilecek, raporlanabilecektir.

2.19. UYGULAMA üzerinden envanterlerin özet çıktıları alınabilmelidir.

2.20. UYGULAMA’da gerçekleştirilen tüm işlemlere ait kayıtlar envanter, çağrı, olay, problem, değişiklik bazında (tarih, saat, yapılan işlem, yapan kişi, değiştirilen alan, vb.) tutulmalı ve istendiği zaman sorgulama yapılabilmeli, raporlanabilmelidir.

2.21. Tüm kayıtlar üzerinde detaylı arama, görüntüleme, filtreleme ve sıralama fonksiyonları uygulanabilecektir. Veri tabanında tutulan ilgili kayıtların özelliklerinden, hangilerinin ekranda gösterilmesi isteniyorsa seçilebilmelidir. Örneğin Envanter Kayıtları ile ilgili bir aramada, envanterin 20 özelliği var ise, Bu özelliklerden adı, kodu, yeri, kullanan kişi, bulunduğu bölge gibi 5 özellik ekranda gösterilebilmelidir.Hangi alanların gösterilip gösterilmeyeceği anlık olarak yapılabilmelidir.

2.22. Sistem yöneticileri için izleme ekranları olacaktır. Yöneticiler bu ekranlarda envanter, olay, problem, değişiklik, talep, servis seviye anlaşmaları gibi tüm kayıtları izleyebilecektir.

2.23. Ürünün tüm fonksiyonları teknik personel ve son kullanıcı tarafından yükleme gerektirmeden İnternet tarayıcısı yardımıyla kullanılabilecektir.

2.24. Sistemin yöneticiler için düzenlenebilir, grafiklerden oluşan yönetici paneli olacaktır. Yöneticiler tüm işlemleri buradan yapacaktır.

2.25. Teklif edilecek UYGULAMA’nın API desteği olmalıdır.(Rest Api, Servlet Api)

2.26. UYGULAMA, mevcut LDAP-Active Directory ile entegre çalışabilmeli ve kullanıcılar istenilen bilgileri ile beraber LDAP-AD yapısından aktarılabilmeli, mevcut kullanıcı adı ve şifre ile UYGULAMA’ya giriş yapılabilmelidir

2.27. Yazılım,manuel ve CSV dosyası şeklinde kullanıcı eklemeyi desteklemelidir2.28. Domain de oturum açmış bir kullanıcı, tekrar kullanıcı adı ve şifre girişi

yapmadan SSO çerçevesinde sisteme giriş yapabilmelidir.

2.29. E-posta entegrasyonu olmalıdır. SMTP ve POP, IMAP protokolleri ile entegrasyon sağlayabilecektir. Giden ve gelen e-posta sunucuları için farklı sunucular tanımlanabiliyor olmalıdır.

2.30. UYGULAMA IPHONE, Blackberry ya da android işletim sistemi yüklü akıllı mobil cihazlar tarafından desteklenmeli, teknik personel bu araçlardan programa giriş yapabilmelidir. Android ve IOS uygulamaları ücretsiz olarak sağlanmalıdır.

2.31. UYGULAMA donanım ve işletim sistemi bağımsız olarak IT envanterlerini (MAC, IBM, Fujitsu Siemens, HP gibi(Linux, Solaris, MAC and IBM-AIX)) tarayabilmeli ve envanter özelliklerini çıkarabilmelidir.

Sayfa 3 / 14

2.32. Network ve Uygulama Yönetimi programıyla entegre bir şekilde çalışabilmeli. Network programından gelen uyarılar sisteme ticket olarak düşebilmelidir.(Örn: Network izleme yazılımından alınacak mail ile senaryo oluşturulabilmelidir.)

2.33. UYGULAMA kendi backup’ını belirlenen aralıklarla otomatik alabilmelidir.2.34. İstenilen alanların görünen isimleri değiştirilebilmeli bu değişiklik uygulama ara

yüzünden yapılmalı ve daha sonra çıkacak bir güncelleme/yama geçilmesi ile değişmemelidir.

2.35. UYGULAMA en az bir network-sistem-uygulama izleme yazılımı, ya da yama ve bilgisayar yönetimi yazılımı ile basit bir şekilde entegre olabiliyor olmalı bu entegrasyon ekstra bir kurulum, uzun bir çalıştırma gerektirmemelidir.

2.36. Uygulama tek bir ajan kurulumu ile tüm niteliklerini sağlayabiliyor olmalıdır.(Örn: Ajan kurulumu ile uzak bağlantı, lisans takibi vb bilgileri alabiliyor ise yazılım takibi için ekstra bir add-on ajan vb. kuruluma gerek duyulmamalıdır.)

2.37. Kayıt oluşturan kişinin tanımlı envanterine uzak bağlantı yine kayıt içerisinden yapılabiliyor olmalıdır. (Örn: A kişisi kayıt açarak problemini bildirdi, B kişisi gelen kayıt üzerinden tek bir tıklama ile A kişisinin tanımlı bilgisayarına uzak masa üstü bağlantısı şeklinde erişebiliyor olmalıdır.)

2.38. Uzak Bağlantı yapılan bilgisayarda bir onay penceresi görülmeli ve son kullanıcı istemediği durumlarda red ederek uzak bağlantıyı engelleyebilmelidir, onay verdiğinde ise kabul edebilmelidir.

2.39. UYGULAMA içerisinde istenilen durumlarda ve belirli tarihler arasında yayınlanmak üzere duyurular yapılabilmelidir. Yapılacak duyurular tüm kullanıcılara veya sadece belirli bir gruba yapılabilmelidir.

2.40. Sisteme istenen durumlar için, belirli tarihler arasında yayınlanmak üzere duyurular eklenebilmelidir.

2.41. Uygulama üzerinden önceden tanımlanan kullanıcı gruplarına göre duyuru eklenebilmelidir

3.ENVANTER YÖNETİMİ3.1. Ajanlı ve ajansız olarak envanter taraması yapılabilmelidir.

3.2. Her envanterin tekil bir kimlik numarası olmalıdır.

3.3. Envanterin kayıtlara girmesinden hurdaya ayrılana kadar geçen tüm aşaması modellenebilecektir.

3.4. Kurum kendi bünyesinde tuttuğu mevcut envanterleri, excell ortamına aktaracak, Yüklenici excell ortamında verilen kayıtların UYGULAMA’da kullanılabilir olacak şekilde düzenleme işlemini, Bilgi Teknolojileri Dairesi Başkanlığı’nın görevlendireceği bir personel ile birlikte yapacaktır. Yüklenici düzenlenen envanterleri UYGULAMA’nın veritabanına aktaracaktır.

3.5. Envanter tek bir cihaz olabileceği gibi, birden fazla envanterin oluşturduğu bir sistemde olabilir. Bu yüzden envanterler arası ilişki türleri tanımlanabilmelidir.

3.6. Envanterler arası ilişkiler:

3.6.1. Envanter içerir envanter. (Örn: Sistem Odası birçok envanterden oluşuyor.)

Sayfa 4 / 14

3.6.2. Envanter kullanır envanter. (Örn: X projesinde birçok envanter kullanılıyor.)3.6.3. Envanter bağlantılıdır envanter ( Örn: A switchine bağlı cihazlar kritikcihazlar olarak nitelendiriliyor. 3.6.4. Envanterler gruplandırılabilmelidir. (Örn: Cluster Exchange Grubu içerik: Sunucu

A1 Sunucu B1 Switch A2 Switch B2)

3.7. IT envanterleri (IP si olan envanterler) UYGULAMA tarafından taranabilmeli ve envanterlerin kaydı otomatik olarak yapılabilmelidir.

3.8. UYGULAMA belirlenen IP aralığını veya belli bir networkü SSH ve Telnet protokolleri ile tarayabilmeli, Linux iş istasyonları üzerinde bulunan yazılımları yakalayabilmeli ve istenirse Linux iş istasyonları için public key verilebilmelidir.

3.9. UYGULAMA tarafından, ek bir araca gerek duyulmaksızın, IT envanterleri üzerinde network, domain taraması yapılabilmeli, verilen ip bloğu taranabilmelidir.

3.10. Uygulama SNMP Community ile belirlenen IP aralığını veya belli bir networkü tarayabilmelidir.

3.11. Uygulama farklı bölgelerde konuşlandırılmış envanterleri yine aynı bölgede koşacak bir ek kurulum ile Agent,SSH,TELNET,WMI protokolleri ile üzerine alabilmelidir ve 2 bölge arasında network bağlantısı açılmasına gerek duymadan import export ve benzeri methodlar ile ana sunucuya taşınabilmelidir.

3.12. Uygulamada CMDB fonksiyonu olmalıdır. (Örnek: Her envanter CI olarak tanımlanabilmeli ve bunlar birbirleri ile ilişkilendirilebilmelidir, ilişkilendirmede tanımlı bir sınır olmamalıdır.)

3.13. Yazılım lisans takipleri program üzerinden yapılabilmeli, önceden belirtilmiş yasaklı yazılımlar kullanıcılar tarafından yüklendiğinde ilgili kişiye ve kullanıcıya bilgilendirme yapabilmelidir.

3.14. UYGULAMA yukarıdaki maddede belirtilen tarama işlemlerini belirli zaman aralıklarında (Sistem Yöneticisi zaman aralıklarını belirtebilmelidir ) yapıp, ilgili envanterler üzerinde meydana gelen değişiklikleri, aksaklıkları UYGULAMA üzerinde bildirmelidir, ayrıca belirlenen gruplara/kişilere mail atabilmelidir.

3.15. Envanterler aşağıdaki özellikleri ile birlikte sistemde tutulabilmelidir.

Envanter modeli, tipi, alt tipi

Kullanım durumu

Zimmetli olduğu kişi/birim

Kritiklik seviyesi

Kullanan Ünite

Envanter ile ilişkili envanterler

Envanteri içeren envanterler

Envanterle bağlantılı kontratlar

Envanterin amortisman bilgileri, Envanter tutar bilgileri

Sayfa 5 / 14

Envantere ait satıcı, üretici, garanti veren firma, garanti tarihleri gibi ek bilgiler

3.16. Envanter bilgileri UYGULAMA üzerinde yukarıda belirtilen özellikler ile birlikte grafiksel olarak modellenebilmelidir.

3.17. Envanterlerin kullanım durumları (kullanımda, tamirde, kullanım dışı, arızalı gibi) tanımlanabilecektir.

3.18. Envanter bir kullanıcı ya da birim ile ilişkilendirildiği anda sistemde tanımlı olacaktır. (Kurum envanterlerinin sisteme ilk girişi sırasında, network, domain taraması sonucu elde edilen ip tabanlı envanterler, envanter üzerinde oturum açılmış ise, son oturum açan kişi envanter ile ilişkilendirilecek, Kurum envanter kayıtları ile karşılaştırılıp doğrulama yapılacaktır.)

3.19. Envanter Veri Tabanında bulunan envanterlerin birim, kullanıcı, kritiklik seviyesi vb. gibi istenilen alanlardan sorgulaması yapılabilmelidir.

3.20. Envanterler için kritiklik seviyeleri belirlen ve bu seviyeleri içiren envanterlerin sorguları yapılabilemli.Sorgulama sonucunda kritik envanterlerve bu envanterler ile ilişkili diğer envanterler görüntülenebilmelidir.

3.21. Envanter için Periyodik Bakım tanımlanabilecektir. Bakım zamanı yaklaşan envanterler için, belirlenecek gruplara / kişilere bilgilendirme maili gönderilecektir. Hatırlatma mailleri farklı zamanlarda olacak şekilde(Bakım Zamanından 1 ay önce, 1 hafta önce, 1 gün önce gibi…) birden çok defa gönderilebilmelidir. Sistem Yöneticisi tarafından bu ayarlar UYGULAMA üzerinden değiştirilebilmeye açık olmalıdır.

3.22. Bilgisayarlardan envanter bilgileri dinamik olarak alınabilmelidir.3.23. Taranan bilgisayarlarda işletim sistemi (id vs), bios (bios tarihi, versiyon vs) ve tüm

donanım (sanal-fiziksel ram, ram frekans bilgileri, CPU, CPU adımı, HDD, multimedia ayrıntıları gibi) ve yazılım ayrıntıları bulunabilmelidir.

3.24. Tüm CI’lar için türe göre bağımsız ek-alan tanımlanabilmelidir.3.25. Uygulama bilgisayarlar üzerinde tanımlı kullanıcı hesap bilgilerini getirebilmelidir.3.26. Uygulama bilgisayarlar üzerinde yazılımları, versiyonlarını getirebilmelidir.3.27. Yazılım lisans ihlalleri e-posta olarak gönderilebilmelidir3.28. CI tipleri için hiyerarşiyi desteklemelidir.3.29. Problem esnasında yada harhangi bir değişiklik öncesinde görsel haritalandırma

sayesinde CI ilişkilerini detaylı olarak görülebilmelidir.3.30. Yazılım lisans takipleri program üzerinden yapılabilmeli,önceden belirtilmiş yasaklı

yazılımlar kullanıcılar tarafından yüklendiğinde ilgili kişiye ve kullanıcıya bilgilendirme yapabilmelidir.

3.31. IT departmanının yaptığı işleri Servis Kataloğu şeklinde kullanıcılara sunulabilmeli. Bu servisler resimlerle olarak gösterilebilmelidir.

3.32. Yama yönetimi yapan bir programla entegre edilebilmeli.3.33. Taranmış iş istasyonlarına uzaktan bağlantı yapabilmeli

Sayfa 6 / 14

4.OLAY/TALEP YÖNETİMİ

4.1. UYGULAMA, bir çağrı ve yardım masası uygulaması olarak intranet ortamında çalışabilmeli ve web desteği ile kullanıcılar çağrı kaydı (ticket) oluşturabilmelidir. Açılan talep kayıtlarının her birine tekil bir talep takip numarası verilecektir. Kullanıcıların arıza, şikayet ve istek bildirimleri kayıt altına alınacaktır.

4.2. Birden fazla çağrı tipi oluşturulabilmeli ve kullanıcılar, birden fazla türden çağrı açabilmelidir (örneğin : “Bilişim sorunları çağrısı”, “Elektrik / sıhhi arıza çağrısı”, vb) Her bir çağrı türü için farklı alıcılar tanımlanabilmeli ve çağrılar bu tanımlanan kullanıcıların ekranına düşmelidir.

4.3. Oluşturulan bir çağrı tipi altında “sorun türleri” tanımlanabilmelidir (örneğin “Bilişim sorunları çağrıları” için “Donanım Sorunu”, “Uygulama Sorunu”, “İletişim Sorunu”, vb.) Kullanıcı bu sorun türleri içinden belirlenen bazılarını seçtiğinde, çağrı isteği birden fazla kullanıcının onayından geçebilmelidir.

4.4. Bir çağrı için tanımlanmış iş akışı adımlarında “Onay”, “Red” (veya benzer nitelikte) seçenekler olmalı, “Not” vb bölümü bulunmalıdır.

4.5. Çağrı istekleri portal aracılığı ile ya da mail ile oluşturulabilmelidir.

4.6. UYGULAMA’da mail yoluyla gelen çağrılar için filtre mekanizması olmalıdır.

4.7. UYGULAMA’da mail ile ya da portal aracılığı ile oluşturulan isteklerde otomatik önceliklendirme yapılabilmelidir.

4.8. Gelen çağrıların otomatik olarak ilgili kişilere ya da gruplara yönlendirilmesi sağlanabilmelidir. Gelen taleplerin kategorisine göre farklı atama gruplarına yönlendirme, otomatik olarak sistem tarafından yapılabilecektir

4.9. Uygulama teknisyenlere kayıt atarken eşit atama veya sırası ile atama seçenekleri verebilmelidir.

4.10. Kayıt çözecek olan personel izinlerini uygulamaya girebilmeli ve personelin izinli olduğu tarihte kayıtlar seçilen yedek personele otomatik olarak sistem tarafından atanabilmeli yada atanmasına engel olunabilecektir.

4.11. Çağrılara manuel ya da otomatik olarak servis süresi belirlenebilmeli, servis süresi aşımından önce ve sonra ilgili uyarılar gönderilebilmelidir.

4.12. Çağrı, servis süresi aşımında seviye yükseltilebilecektir. Çağrı belirtilen durumlarda birden fazla eskale edilebilmelidir.

4.13. Çağrı servis süreleri çalışma saatlerine göre, 7*24, tatiller hariç gibi süreler göz önünde bulundurularak belirlenebilmelidir.

4.14. Çağrılar için 3 seviye kategorilendirme yapılabilmelidir.

4.15. Gelen çağrılar için kurallar oluşturularak, kategorilere, kullanıcılara, Sayfa 7 / 14

departmanlara göre farklı süreçler oluşturulabilmelidir.

4.16. Kullanıcıların çağrı oluşturabileceği formlar düzenlenebilmelidir.

4.17. Uygulama üzeirnde kullanıcı grupları tanımlanabilmeli, hangi servis ve formların hangi kullanıcılara sunulacağı kısıtlaması yapılabilmelidir.

4.18. İstek kapatırken kapatma kodları tanımlanabilmelidir . Ör : başarılı, başarısız, iptal, sorun gözlenemedi vs gibi.

4.19. Sistemde öncelik ve etki analizi için öncelik matrisi tanımlanabilmesine olanak vermelidir (sadece enter. versiyonda)

4.20. Tüm kayıtlar manuel olarak da onay süreci başlatılabilmeli, arayüzden ve mail ile gelen link üzerinden onay işlemi gerçekleştirilebilmelidir.

4.21. Çağrı ekranlarında her kullanıcı kendi filtrelerini oluşturulabilmeli ve kaydedebilmelidir.

Kullanıcı arayüzü verilen aralıkta sayfa yenilemesi yapabilmelidir.4.22. Benzer isteklerde birleştirme ve birbiri arasında link verilebilmelidir.4.23. Link oluşturulmuş kayıtlarda bir kayıt kapatıldığında ilişkili kayıtlar da otomatik

olarak kapatılmalıdır.4.24. Her kayıt için birbirinden bağımsız hatırlatıcı uyarıları tanımlanabilmelidir.4.25. Kayıt üzerinden kullanıcın açtığı önceki kayıtlarda listelenebilmelidir.4.26. Istek formlarının dışında uygulama arayüzünde hızlı istek açma formu alternatif

olarak belirtilebilmelidir.4.27. Her kayıt için birbirine bağımlı (sırası ile aktif olan ) görevler tanımlanabilmelidir.4.28. Bir çağrı ile ilgili olarak gönderilen ve alınan tüm mailler arayüz üzerinde ayrıntıları

ile beraber loglanabilmelidir.4.29. Kapatılan çağrıların kullanıcılar tarafından tekrar açılabilmesi için süre sınırı

tanımlanabilmelidir.4.30. Farklı çağrılar için farklı formlar tasarlanılabilmelidir.

4.31. Çağrı şablonları oluşturulabilmeli, kullanıcının çağrısını bu şablonlar ile kolaylıkla oluşturabilmesi sağlanabilmelidir.

4.32. Çağrılara dosya eklenebilmelidir.

4.33. Çağrılar zamanlanarak otomatik olarak oluşturulabilmelidir.

4.34. Çağrılar için durum bilgileri sistem üzerinden takip edilebilmelidir.(Açık, beklemede, kapalı vs..) Durumlar kişiselleştirilebilmeli ve servis süresi işleme ya da işlememe durumları belirtilebilmelidir.

4.35. Tüm çağrılar için sisteme görevler eklenebilmeli, bu görevler için ilgililere uyarılar gönderilebilmelidir.

Görevi yeniden atandığında görev sahibine

Görevi yeniden planlandığında görev sahibine

Görevine bir yorum eklendiğinde görev sahibine

Görevine bir Harcanan Zaman Girdisi eklendiğinde görev sahibine

Önceki tüm görevler kapandığında, görev grubuna/teknikerine

Sayfa 8 / 14

Bir görev yeniden planlandığında ilişkili girdi sahibine

Bir görev kapandığında ilişkili girdi sahibine

Tüm görevler kapandığında ilişkili girdi sahibine

Çağrı Bilgi İşlem görevlisine yönlendirildiğinde kullanıcıya, Bilgi İşlem yetkilisine

ve 3. şahıslara uyarı ve bilgilendirme mesajları gönderebilmedir.

4.36. Yukarıda belirtilen Uyarıların şablonları düzenlenebilmeli kayıt içerisinde bulunan değişkenler tanımlanabilmelidir.(Örn: Gelen mail içeriği: Merhaba kayıt altına alınmıstır kayıt_numarası_degiskeni)

4.37. Farklı yetkili rolleri tanımlanabilmeli, her yetkilinin sadece izin verilen çağrılara ve UYGULAMA özelliklerine erişim hakları (oluşturma, silme, düzenleme) belirlenebilmelidir.

4.38. Sistem üzerinde kullanıcıların erişebileceği bir çözümler portalı bulunmalı, çağrılara belirtilen çözümler burada kullanıcılar için belirlenen anahtar sözcükler ile aranabilmelidir.

4.39. Çözümler sadece Bilgi İşlem yetkilileri arasında ya da tüm kullanıcıların erişimine açık olarak ayarlanabilmelidir. Sistemden tüm çağrıların;

Kategoriye göre

Departmanlara göre

Yetkiliye göre

SLA göre

Duruma göre sorgulaması yapılabilmelidir.

4.40. Çağrılar Web arabiriminden, telefon çağrıları ile, e-mail ile ve 3. Parti network yazılımları ile açılabilmelidir.

4.41. Gelen çağrılar en az 3 farklı hiyerarşik kategorizasyon içerisinde konumlandırılabilmelidir. Gelen çağrılarda,

Özet ve açıklama, kategori,alt kategori, öğe

öncelik, aciliyet, etki

seviye

çağrıyı oluşturan, departman,

ilgili helpdesk yetkilisine,

uzman kullanıcı grubuna,

servis seviyesi bilgisi,

durumu, aciliyeti bilgileri otomatik olarak belirlenebilmelidir.

Çagrı içinde alınmak istenen ek bilgiler oluşturulan ek kutucuklarla belirlenebilmelidir. Bu alanlar Numerik,tarih,tek satır,çoklu satır yada

Sayfa 9 / 14

seçenekli olarak eklenebilmelidir.

4.42. Çağrılar için çağrının aciliyeti ve iş akışına etkisine göre otomatik olarak öncelik atanabilmelidir.

4.43. Çağrılar için oluşturulacak formlar tamamen kişiselleştirilebilir olmalı, bazı bölümler sadece yardım masası yetkililerine, istenilen bölümler kullanıcılara açılabilmeli ya da doldurulması zorunlu alan olarak belirtilebilmelidir.

4.44. Farklı çağrılar farklı formlar, çağrı şablonları oluşturulabilmeli, alanların seçili olarak gelmesi sağlanabilmelidir.

4.45. Rutin olarak gerçekleştirilen işler için otomatik oluşacak çağrılar zamanlanabilmelidir.

4.46. Çağrılar oluştuğunda kullanıcıya ve uzman personele ilgili durumlar için bilgilendirme postaları gönderilebilmeli, bu posta içerikleri tamamen kişiselleştirilebilir olmalıdır.

4.47. Çağrılar içerisine bilgiler eklenebilmeli, aynı zamanda çözüm ekranında çözümler modülünde arama yapılabilmelidir. Talep son kullanıcı tarafından girilebileceği gibi, son kullanıcı adına Servis Masası Uzmanları tarafından da girilebilecektir. Her aktivitenin tekil bir kodu olacak ve sistemde aranabilecektir.

4.48. Çağrılara girilen çözümler istenilirse çözümler bölümüne anahtar sözcükler verilerek aktarılabilmelidir. Bilgi Bankası olacaktır. Bilgi Bankası, yetkili uzmanlar tarafından oluşturulabilecektir.. Uzmanlar, Bilgi Bankası’na, talep ekranından çıkmadan ulaşılabilecektir. Talebin, bilgi bankasından verilen cevabın yeterli olması halinde, aktarılan bilgi veya özeti, çağrı ekranına aktarılarak çağrı kapatılabilecektir. Bilgi Bankası, Son Kullanıcı tarafından da görüntülenebilecektir.

4.49. Girilen çözümlerin kullanıcılara ya da sadece servis masası yetkililerine açılacağı belirtilebilmelidir.

4.50. Servis masası uzman kullanıcısı çağrıya çözümü girdikten sonra kullanıcı çağrıyı tekrar açmaz ise sistem belirli süre sonunda çağrıyı otomatik olarak kapatabilmelidir.

4.51. Çağrının istenilen bilgileri girilmeden kapatılması engellenebilmelidir.

4.52. Uygulama üzerinde belirli bir tarihten eski kayıtlar yine bu kayıtların DURUM gibi alanları kriter olarak seçilip arşivlenebilmelidir.(Örn: Açık, Kapalı)

4.53. Kullanıcılara, belirlenen çağrıları sonunda sorularının ve memnuniyet seviyelerinin özel olarak hazırlanabileceği anketlerin gönderilmesini UYGULAMA desteklemelidir.

4.54. Çağrılar Yardım Masası personeli tarafından talep sahibi adına girilebileceği gibi talep sahibi tarafından da girilebilmelidir.

4.55. Çağrı kaydı Yardım Masası personeli tarafından girildiğinde talep hangi kullanıcı adına girilirse o kullanıcıya mail ile bildirim yapılabilmelidir.

4.56. Otomatik olarak envanter bilgisi üzerinde değişiklik yapılabilmeli, bir departman ile ilişkilendirilebilmeli ya da tipi değiştirilebilmelidir.

Sayfa 10 / 14

4.57. ITIL’daki Olay Yönetimi, Problem Yönetimi ve Değişim Yönetimi’nin birbirleriyle bağlantıları olmalıdır. Kullanıcılar sisteme bağlandığında, açık servis talepleri ve kullanıcı ile ilişkilendirilmiş envanterler görüntülenecektir.

4.58. Servis masası uzman kullanıcı takvimi olmalıdır. Bu takvimde uzman kullanıcıların işleri, hastalıkları, izinleri görülebilmelidir. Uzman kullanıcılar izinli oldukları zamanları bu takvimde gösterip gelen çağrıların önceden belirledikleri destek personeline otomatik atanması sağlanabilmelidir.

4.59. Active Directory’den belli zaman aralıklarına ayarlanmış olarak kullanıcılar çekilebilmelidir.

4.60. Arıza yönetimi, problem yönetimi ve değişim yönetimlerinde iş akışları gerçekleştirilebilmeli.

4.61. Son kullanıcılarının kendi kayıtlarını açabileceği ve durumunu takip edebileceği şekilde düzenlemiş son kullanıcı erişim ekranları olacaktır.

4.62. Açık servis çağrılarının durumunu takip edebilecek, çağrı geçmişini inceleyebilecek ve gerekiyorsa çağrıya bilgi ekleyebilecektir.

4.63. Çözülmüş servis cağrıları inceleyebilecek, çözümü onaylayabilecek veya tekrar işleme alınmasını talep edebilecektir.

4.64. Bir çağrı kaydının yapılabilmesi için belirlenecek zorunlu alanlar girilmeden kayıt açılmayacaktır.

4.65. Bir çağrı kaydı yapıldığında, uygun kriterli tepki süresi servis seviyesi seçilebilmelidir; aynı zamanda ilgili envanterin tanımlı kullanılabilirlikservis seviyesi bulunuyorsa tanıma uygun işletilmelidir.

4.66. Çağrılar, tanımlı atama gruplarının iş listelerinde görüntülenebilecektir. Sistem Yöneticisi talepleri farklı uzmanlara atayabilecektir.

4.67. Çağrı durumları tanımlanabilecektir. Standart olarak sistemde bir talebin açık, üzerinde çalışılıyor, askıda, kullanıcı bekliyor, çözüldü, kapandı durumları bulunacaktır.

4.68. Çağrının her bir durumunda yapılabilecek görevler tanımlanabilecektir Görevlerin hangi durumlarda, hangi gruplar için kullanılabileceği Sistem Yöneticisi tarafından düzenlenebilecektir.

4.69. Her aktivitenin açıklaması olacak, başlangıç ve bitiş tarihleri Uzman Kullanıcı tarafından girilebilecektir.

4.70. Bir çağrının görevleri, talebin içinde tarihsel sırada görüntülenecektir.

Sayfa 11 / 14

Tanımlanan bir görev ;

Başka bir görev tetikleyebilecek,

Görev durumunu değiştirebilecek,

Görev atama grubunu değiştirebilecek,

İlişkili başka bir görev yaratabilecektir.

Görevin durum değişikliklerinde e-posta bilgilendirilmeleri yapılabilecektir. E-posta içerikleri Sistem Yöneticisi tarafından düzenlenebilir olacaktır. Hangi aşamalarda hangi e-postaların gönderileceği düzenlenebilecektir.

4.71. Çağrı arama listelerinde çağrının durumu ve son görevle birlikte görüntülenebilecektir.

4.72. Bildirilen çağrılar, Kurum personeli tarafından çözülüp kapatılabileceği gibi, garanti veya bakım anlaşması sorumluluğunu taşıyan harici bir firmaya yönlendirilebilecek ve bu yönlendirme sonucunda firmanın tanımlı eposta adresine eposta gönderilecektir.

4.73. Çağrı hızlı kapatabilmesi için çağrı kapatma özetleri tanımlanabilecektir. Bu özetler Sistem Yöneticisi tarafından düzenlenebilecektir. Çağrı Özetleri, çağrı Kategorileri ile ilişkilendirilebilecektir.

4.74. Çağrıların atandığı kişiler sonradan değiştirilebilir olmalıdır.

4.75. Arayüz üzerinden uygulama logları görüntülenebilmelidir.

4.76. Teklif edilecek olan yazılım ile taleplerin geçmişleri kontrol edilebilmeli, gerektiğinde kapanmış bir talep tekrar açılabilmelidir.

4.77. Servis katalogları için birden fazla aşamalı onay süreçleri olmalıdır.

4.78. Yapılan servis taleplerinin ve servis düzey seviyelerinin kullanıcı arayüzünden görüntülenmesi gerekmektedir.

4.79. Servis isteklerine bağlı olarak otomatik görev atamaları yapılmalıdır.

4.80. Yönetim menüsü altında görev türleri oluşturabilme ve renk kodları verebilmelidir

5.SATIN ALMA VE KONTRAT SÜREÇLERİ

5.1. Sistem Yöneticisi tarafından satın alma süreçleri UYGULAMA üzerinde tanımlanabilmelidir. Bu süreçler UYGULAMA üzerinden takip edilebilmelidir. Satın alınan envanterler UYGULAMA’ya eklenebilmelidir.

5.2. Satın alma süreç akışlarında onay ve ret aşamaları tanımlanabilmelidir.

5.3. Satın alma süreç akışları aktif/pasif hale getirilebilmelidir.

Sayfa 12 / 14

5.4. Envanter alımlarına ait sözleşmeler sistemde tanımlanabilmeli ve sözleşmelerin geçmişi takip edilebilmelidir. Sözleşme kapsamında aşağıdaki bilgiler tutulmalıdır.

5.4.1. Sözleşme Adı Sözleşme Sahibi-Yüklenici Firma ve bilgileri tanımlanabilmelidir.

5.4.2. Sözleşme kapsamında satın alınan envanterler için, garanti süresi boyunca destek verecek firmaların bilgileri (Firmalar, ilgili envanterlerin hangi bölgede bulunduğuna bilgisine göre tutulmalıdır. ) tanımlanabilmelidir.

5.4.3. Sözleşme Versiyonu (Yenilenen sözleşmeler için), Sözleşme Başlangıç ve Bitiş Tarihleri tanımlanabilmelidir.

5.5. Sistemde tanımlı sözleşmeye, yapılan sözleşme dokümanı ek olarak eklenebilmelidir.

5.6. Sözleşme kapsamında alınan envanterler, sözleşme altında birleştirilebilmelidir. Hangi sözleşme ile hangi envanterler alındı sorusunun cevabı UYGULAMA üzerinden sorgulanabilmelidir.

5.7. Bir sözleşme kapsamında alınan envanterlerin toplu girişi ve toplu dağıtımı yapılabilmelidir.

5.8. Sözleşmelere istenilen ek alanlar tanımlanabilmelidir.

5.9. Sözleşmenin bitiminden önce, belirlenecek gruplara sözleşme süresinin biteceği ile ilgili bilgilendirme e-postası gönderilmelidir. E-posta içeriği sistem yöneticisi tarafından UYGULAMA üzerinden değiştirilebilir olmalıdır.

5.10. Kontratları CSV üzerinden import edebilmelidir.5.11. Satın Alma için çoklu seviye onay oluşturabilmelidir.

5.12. Kontrata bağlı alt kontrat oluşturulabilmeli

6. PROJE YONETİMİ

6.1. Proje Yönetimi süreçleri program aracılığıyla yönetilebilmeli.

6.2. Proje Tipi, Başlangıç tarihleri, Bitiş tarihleri, Proje tarihi, Tahmin edilen tutar programada belirtilebilmeli

6.3. Proje rolleri, kullanıcılara projeler için ayrıntılı roller oluşturabilmeli6.4. Görevler proje aşamalarına, aşamalarda projeye bağımlı olup birbirleriyle

ilişkilendirlebilmelidir6.5. Görev bağımlıklarını oluşturabilmelidir6.6. Proje genel görünüm haritası bulunmalıdır6.7. Tahmin edilen tutarı, çalışma kayıtlarını ve zaman çizelgesi üzerinden takip

edebilmelidir6.8. Renk kodlu takvim görünümleri üzerinden proje durumunu ve detaylarını takip

edebilmelidir6.9. Tüm görevleri projeler ile eşleştirebilmelidir6.10. Var olan projelerde kullanılabilen durumlar için renk kodları oluşturabilmelidir

Sayfa 13 / 14

7. SERVİS SEVİYE YÖNETİMİ (SLA)

7.1. Servis Seviye Yönetimi, olayın durumuna göre tanımlanabilen Müdahale Süresini, Servis Seviyesi Anlaşmasını (Response Time SLA) ve envanterin durumuna göre tanımlanan kullanılabilirlik Servis Seviye Anlaşmasını (Availability SLA) desteklemelidir.

7.2. Bir Servis Seviye Anlaşması birden fazla durum (açık, üzerinde çalışılıyor, askıda, son kullanıcı bekleniyor, kapalı, vb) içerebilmelidir. Bu statüler 7x24, mesai saatleri ve hafta sonu zamanlarına göre düzenlenebilmelidir.

7.3. Servis talebi geldiğinde, olay kaydı yaratılırken Servis Seviye Anlaşması seçimi, UYGULAMA tarafından eşleşen Servis Seviye Anlaşma tanımlarına göre otomatik olarak yapılabilmelidir.

7.4. Servis Seviye anlaşması seçimi lokasyon, kontak, öncelik, olay kategorisi ve envanter kriterlerine göre olmalıdır.

7.5. Servis Seviye Anlaşmaları’ndaki hedefler geçildiğinde UYGULAMA e-posta ile tanımlı yöneticileri uyarabilmelidir.

8. RAPORLAMA

8.1. Sistemde raporlar istenilen bilgilerin alınabileceği şekilde, bir sihirbaz aracılığı ile oluşturulabilmelidir. Raporlama için ek bir araca gereksinim duyulmamalıdır.

8.2. Sistemde uzman kullanıcıların kullandığı her türlü sorgu sonucu için aynı zamanda rapor alınabilmelidir.

8.3. Raporlar PDF, XLS, HTML veCSV formatlarında oluşturulabilmelidir.

8.4. Belirli kişilere, belirli zamanlarda, istenilen raporlar otomatik olarak UYGULAMA tarafından mail atılabilmelidir. Sistem Yöneticisi, hangi raporların, kimlere, hangi aralıklarla ya da ne zaman gönderilebileceği gibi bilgileri UYGULAMA üzerinde bulunan Yönetim Konsolu üzerinden belirtebilmelidir. Mail gönderilecek kişi sayısında sınırlama olmamalıdır.

8.5. UYGULAMA envanterler, çağrılar, talepler, servis seviye yönetimi, süreç yönetimi gibi veri tabanında tutulan UYGULAMA verileriyle ilgili, en az 100 adet standart rapor şablonu içermelidir. Bu raporlar statik raporlar olmamalı, Sistem Yöneticisi tarafından, UYGULAMA üzerinden kolaylıkla değiştirilebilir olmalıdır.

8.6. Sistem Yöneticisi Kurum’da ihtiyaç olması durumunda, rapor sihirbazı yardımıyla ek raporlar oluşturup, yeni bir rapor şablonu ekleyebilmelidir. Oluşturulan yeni raporlar da diğer tüm raporlar gibi, belirli zamanlarda ya da belirli zaman aralıklarında, belirlenen kişilere/gruplara UYGULAMA tarafından belirlenen zamanlarda gönderilebilmelidir.

8.7. Uygulama üzerinde database şeması sağlanmalı, gerektiği durumlarda rapor arayüzü üzerinden db sorgusu yazılarak rapor alınabilmeli ve şablon oluşturulabilmelidir

Sayfa 14 / 14