KİK Kararı: 2022/UH.I-781

KAMU İHALE KURULU KARARI
Toplantı No : 2022/034
Gündem No : 32
Karar Tarihi : 29.06.2022
Karar No : 2022/UH.I-781
Toplantıya Katılan Üyeler

BAŞVURU SAHİBİ:

Mor Yazılım Hizmetleri ve Bilgisayar Sis. Ltd. Şti.,

İHALEYİ YAPAN İDARE:

Güngören Belediyesi Kültür ve Sosyal İşler Müdürlüğü,

BAŞVURUYA KONU İHALE:

2022/433378 İhale Kayıt Numaralı “Akıllı Şehir Uygulamaları ve Sunucu Kiralama İle Bakım Onarım Hizmetleri Alımı” İhalesi

KURUM TARAFINDAN YAPILAN İNCELEME:

Güngören Belediyesi Kültür ve Sosyal İşler Müdürlüğü tarafından 03.06.2022 tarihinde açık ihale usulü ile gerçekleştirilen “Akıllı Şehir Uygulamaları ve Sunucu Kiralama İle Bakım Onarım Hizmetleri Alımı” ihalesine ilişkin olarak Mor Yazılım Hizmetleri ve Bilgisayar Sis. Ltd. Şti.nin 30.05.2022 tarihinde yaptığı şikâyet başvurusunun, idarenin 31.05.2022 tarihli yazısı ile reddi üzerine, başvuru sahibince 07.06.2022 tarih ve 26633 sayı ile Kurum kayıtlarına alınan 07.06.2022 tarihli dilekçe ile itirazen şikâyet başvurusunda bulunulmuştur.

Başvuruya ilişkin olarak 2022/585 sayılı itirazen şikâyet dosyası kapsamında yapılan inceleme neticesinde esas inceleme raporu tanzim edilmiştir.

KARAR:

Esas inceleme raporu ve ekleri incelendi. İtirazen şikâyet dilekçesinde özetle,

1. Teknik Şartname'nin 2'nci maddesinde belirtilen entegrasyon ve bütünleştirme ifadelerinin aynı hususları işaret ettiği, teklif vermek isteyenlerin kendilerinden ne beklendiğini net olarak anlamayacakları,

2. Teknik Şartname’nin 2’nci maddesinde sözleşmede bulunmak kaydı ile yeni modüllerin eklenmesi gerektiğine ilişkin düzenlemenin sağlıklı teklif oluşturulmasına engel nitelikte olduğu,

3. Teknik Şartname’nin 4’üncü maddesinde 15 modül ve entegrasyona yer verildiği, hâlihazırda hizmet veren listede yer almayan diğer modüllere ihtiyaç duyulmayacak ise listede belirtilmeyen modüllerin de düzenlemeye ilave edilmesi gerektiği, ayrıca modüllerin içerik ve kapsamının şartnamede düzenlenmemiş olduğu, mevcutta sahip olunan ve yeni yazılımın da sağlaması gereken fonksiyon listesinin detaylı bir şekilde düzenlemede belirtilmesi gerektiği,

4. Teknik Şartname’nin 7’nci maddesinde deneyim sahibi olunacak alanlar ve deneyim süreleri en detaylı şekilde belirtilerek açık bir şekilde tek bir şirketin sahip olduğu çalışan kadrosunun tanımlanmış olduğu, kadro tanımları yapılırken getirilen ön koşulların mantıklı ve tutarlı gerekçelere sahip olmadığı, ihale konusu iş ve işin kalitesi ile ilgisi bulunmayan deneyim şartlarının düzenlemeden çıkartılması gerektiği,

5. Teknik Şartname’nin 8.1.6’ncı maddesinde, belirtilen “Vaadin” web uygulama çatısını Universal Yazılım A.Ş.nin kullandığı, bu maddenin tek bir istekliyi işaret ettiği, 8.1.7’nci maddesinin verimliliği ve fonksiyonelliği sağlamadığı, hangi ihtiyaca istinaden bu özelliğin şartnameye eklendiğinin belirsiz olduğu, tek bir istekliyi işaret ettiği, 8.1.11’inci maddesinde yer alan “uygulama dışından çağırmak” ifadesinin neye karşılık geldiğinin anlaşılmadığı, hangi ihtiyaca tekabül ettiğinin belli olmadığı, tek bir firmayı işaret ettiği, 8.2.12’inci maddede yer alan “İdare LDAP ile çalışıyor ise” ifadesinin şartnamenin Universal Yazılım A.Ş. tarafından hazırlandığını gösterdiği, idarenin zaten bu bilgiye sahip olduğu, 8.6.16’ncı maddesinde yer alan düzenlemede hangi CRM ile bütünleşik çalışma istendiğinin belirsiz olduğu CRM dışındaki modüller ile bütünleşik çalışmaya gerek olup olmadığının anlaşılmadığı, 8.6.17’nci ve 8.16.18’inci maddelerde teknik koşulların açık bir şekilde Universal Yazılım AŞ’yi işaret ettiği, 8.6.18’inci maddede yer alan ‘‘Kendisine özgü olmalı’’ ifadesinin sübjektif olduğu belirsizlik oluşturduğu bu yüzden teklif verme hususunda isteklileri tereddüde düşürdüğü,

6. Teknik Şartname’nin 9’uncu maddesindeki düzenlemelerin üçüncü parti olmalıymış gibi tarif edildiği, bunun Universal Yazılım A.Ş.’nin bu çözümleri üçüncü parti sistemleri uyarlayarak sağlamış olmasından kaynaklandığı, sistem içerisinde yer alan “web tabanlı”, “responsive”, “sisteme girildiğinde IP’nin saklanması”, “ORM sistemi sayesinde veri tabanı bağımsız” türünden ifadelerin ana YBS uygulaması dışında üçüncü parti uygulamalar ile sağlanması durumunda anlamlı olabileceği, Universal Yazılım A.Ş.’nin sağladığı çözümlerin özellikle dayatıldığı, tek elden tasarlanmayan 3’üncü parti sistemleri uyarlayarak sağlanan çözümlerin bütünleşik çalışma noktasında ne kadar başarılı olabileceğinin tartışmalı olduğu, Teknik Şartname’nin 9.1’inci maddesinde akıllı şehir yönetimi platformuna ihtiyaç duyulmuştur vurgusunun yanıltıcı olduğu, mevcut sistemde mesaj bilgi sistemin zaten mevcut olduğu, Teknik Şartname’nin 9.2’nci maddesinde tarif edilenden çok daha gelişkin bir sistemin zaten hâlihazırda hizmet verdiği, bu nedenle akıllı şehir yönetimi platformuna ihtiyaç duyulduğu vurgusunun yanıltıcı olduğu, Teknik Şartname’nin 9.4’üncü maddesinde dolaşım, şablon, elektronik imza gibi tanımlamalar yerine TS 13298 standardına uyumlu olmanın istenilmesinin yeterli ve uygun olduğu, Teknik Şartname’nin 9.4.2’nci maddesinde yer alan düzenlemelerin Universal Yazılım A.Ş.’nin kullanmakta olduğu üçüncü parti çözümleri tarif ettiği, “içeriği özgün dosya biçiminde saklanmalıdır” ifadesinin muğlak olduğu, CMS platformunun belediye personelinin kullanımına uygun olmadığı, bu maddede yer alan teknik koşullarda kurumun ihtiyacı olan işlevlere ve süreçlere yer verilmediği,

7. Teknik Şartname’nin “Mobil Çözümler” başlıklı 10.8. ve 10.11’inci maddelerinde QR kod okumanın hangi amaçla kullanılacağının belirtilmediği, QR kod ile sisteme hızlı giriş yapabilme özelliğinden neyin ifade edildiğinin anlaşılamadığı, bu düzenlemenin anlaşılır bir şekilde düzeltilmesi gerektiği,

8. Teknik Şartname’nin “Yüklenicinin Yükümlülükleri” başlıklı 12’nci maddesinde yüklenici ifadesinin 4734 sayılı Kanunun Tanımlar başlıklı 4’üncü maddesine aykırı olduğu, istekli ifadesinin kullanılması gerektiği, yüklenici ifadesinin kullanılmasının Kanun da yer alan tanımlara aykırılık teşkil ettiği, bahsi geçen düzenlemede belgelerin sözleşme öncesinde sunulmasının istenmesi ile düzenlemedeki belgelerin sadece ihale üzerinde bırakılan istekli açısından yeterlik kriteri haline geldiği ve İdari Şartname’nin yeterlik kriterlerini düzenleyen 7’nci maddesinde bahsi geçen belgelere yer verilmemesinin mevzuata aykırı olduğu, Kamu İhale Genel Tebliğ’inin 74.4 maddesinde hizmet alımı ihalelerinde istenmeyecek belgelerin açık bir şekilde belirtildiği ancak bahsi geçen şartname maddesinde bu düzenlemeye aykırı bir biçimde belgelerin istendiği,

9. Teknik Şartname’nin “Bulut Sunucu Kiralama Hizmeti” başlık 18’inci maddesinde yer alan ifadeler dikkate alındığında; yönetişim bilişim sistemleri yazılımını üretmek ve bulut sunucularda konuşlandırma hizmeti sağlamanın birbirinden ayrı iş alanları olduğu, bu alanlarda faaliyet gösterecek olan firmaların tamamen farklı şekilde yapılanmaları ve uzmanlaşmaları gerektiği, İdari Şartname’nin 17’inci ve 18’inci maddelerinde konsorsiyumların ihaleye teklif veremeyeceği, ihale konusu hizmetin tamamının veya bir kısmının alt yüklenicilere yaptırılamayacağı belirtildiği, Teknik Şartname’nin 12.1’inci maddesinde kiralama hizmeti verilecek platformun yüklenicin kendi ürünü olacağı ifadesinin yer aldığı, bahse konu ifadelerden yalnızca yönetim bilişim sistemleri geliştirme ve bulut sunucu kiralama hizmetlerinin ikisini birden teklif eden isteklilerin ihaleye katılabilmesine imkan verdiği, yapılan düzenleme ile ihale konusu işin esasını oluşturan yönetim bilişim sistemleri yazılımı üreten şirketlerin ihaleye katılamamasına sebep olduğu, bu düzenlemelerin Universal Yazılım A.Ş.’nin ihaleye katılım sağlayabilmesine olanak tanıdığı, belirtilen özelliklerin doğrudan Universal Yazılım AŞ’nin sahip olduğu sistemden alındığı, 18’inci maddede belirtilen teknik özelliklerin bir değer aralığına işaret etmiyor olmasının mevzuata aykırılık teşkil ettiği iddialarına yer verilmiştir.

Başvuru sahibinin iddialarının değerlendirilmesi sonucunda aşağıdaki hususlar tespit edilmiştir.

1. Başvuru sahibinin 1’inci iddiasına ilişkin olarak:

Teknik Şartname’nin “Kapsam” başlıklı 2’nci maddesinde; “…Entegrasyon sırasında yeterli verim gözükmediği takdirde Yüklenici kurum bünyesinde bulunan mevcut sistemleri bütünleştirme çalışmasına başlarsa eğer, bu yazılımların ilgili olduğu mevzuatlarda oluşabilecek değişikliklerin sisteme uyarlanması, hizmetlerimizin mevcut sistemle uyumlu şekilde devam ettirilmesi ve güncelliğinin korunması işleri de bu alım kapsamındadır…” düzenlemesi yer almaktadır

Söz konusu düzenlemedeki entegrasyon ve bütünleştirme ifadelerinin birbirleri ile çelişecek ve isteklileri tereddüde düşürecek şekilde kullanılmadığı, kullanılan ifadelerin tekliflerin sağlıklı bir şekilde hazırlanmasına engel olabilecek nitelikte olmadığı anlaşıldığından başvuru sahibinin iddiasının yerinde bulunmadığı sonucuna varılmıştır.

2. Başvuru sahibinin 2’nci iddiasına ilişkin olarak:

Teknik Şartname’nin “Kapsam” başlıklı 2’nci maddesinde; “…Bu şartname kapsamında yapılacak hizmetler aşağıdaki şekilde tarif edilmiştir;

…

Sözleşme kapsamında bulunmak kaydı ile yeni modüllerin eklenmesi,…” düzenlemesi yer almaktadır.

Söz konusu düzenleme uyarınca sözleşme kapsamında yeni modüllerin eklenilmesinin öngörüldüğü anlaşılmakta olup, ihale dokümanına uygun olarak sözleşme kapsamında eklenecek modüllerin maliyete yansıtılması ve teklif fiyatının belirlenmesinin mümkün olduğu, söz konusu düzenlemenin isteklileri tereddüde düşürecek nitelikte olmadığı anlaşıldığından başvuru sahibinin iddiasının yerinde bulunmadığı sonucuna varılmıştır.

3. Başvuru sahibinin 3’üncü iddiasına ilişkin olarak:

Teknik Şartname’nin “Mevcut Modül Listesi” başlıklı 4’üncü maddesinde “4.1 EBYS Modülü, 4.2 Adres Bilgi Sistemi, 4.3 Sicil Bilgi Sistemi Modülü, 4.4 Sistem Yönetimi Modülü, 4.5 Personel Maaş Modülü, 4.6 Özlük Yönetimi Modülü, 4.7Varlık Yönetimi (Satın Alma) Modülü, 4.8 Bütçe Modülü, 4.9 Muhasebe Modülü, 4.10Ön Muhasebe Uygulaması, 4.11 Belediye Gelirleri Sistemi, 4.12 E-Belediye, 4.13 Kurumsal Mali Konsolidasyon Ekranı, 4.14 Makine ikmal Modülü, 4.15 Sosyal Yardım Modülü, 4.16 Entegrasyonlar, 4.16.1 10 Adet E-Devlet Servisi, 4.16.2 E-belediye ye e-devlet üzerinden giriş, 4.16.3 2 Banka Entegrasyonu, 4.16.4 NVİ, 4.16.5 GİB, 4.16.6 HİTAP, 4.16.7 KEP, 4.16.8 İBB, 4.16.9 Komşu Esnaf, 4.16.10 Çağrı Merkezi, 4.16.11 Kuruma ait Web Siteleri” düzenlemesi yer almaktadır.

İdare tarafından mevcut ihtiyaçlarına istinaden hangi modüllerin ihale konusu iş kapsamına alınacağının belirlenebileceği, söz konusu maddede mevcutta yer alan ve ihale konusu iş kapsamına alınan modüllerin idare tarafından sayılmış olduğu, mevcutta var olmasına bakılmaksızın hangi modülerin iş kapsamında olacağının belirlenmesinin idarenin takdir yetkisi kapsamında bulunduğu, söz konusu maddede yer alan modüllere ilişkin teknik şartnamede belirtilen özellikler esas alınarak istekliler tarafından tekliflerin oluşturulabileceği, dolayısıyla başvuru sahibinin iddiasının yerinde bulunmadığı sonucuna varılmıştır.

4. Başvuru sahibinin 4’üncü iddiasına ilişkin olarak:

Hizmet Alımı İhaleleri Uygulama Yönetmeliği’nin “Personel durumuna ilişkin belgeler” başlıklı 40’ıncı maddesinde “(1) İhale konusu işin niteliği esas alınarak, çalıştırılması öngörülen personelin sayısı ve nitelikleri dokümanda belirtilir. Ancak, idare tarafından ihaleye katılım ve yeterlik kriteri olarak, personel çalıştırıldığına, çalıştırılacağına veya personelin sayısı ya da niteliklerine ilişkin belge istenemez.

(2) Çalıştırılacak personelin nitelikleri ve deneyim süresi ile bunları tevsik edecek belgelere ilişkin düzenleme teknik şartnamede yapılır. Asgari deneyim süresi öngörülmesi halinde, bu süre bir yıldan az beş yıldan fazla olmamak üzere idare tarafından belirlenir. Deneyim süresi mezuniyet tarihi esas alınarak mezuniyete ilişkin belge ile tevsik edilir. Personelin niteliğini ve deneyim süresini gösteren belgeler sözleşmenin imzalanmasının ardından işe başlanmadan önce yüklenici tarafından idareye sunulur.” hükmü,

Teknik Şartname’nin “Yüklenici Merkez Ekibi” başlıklı 7’nci maddesinde; “7.1 Genel

7.1.1 Yüklenicin proje süresi boyunca tam zamanlı olarak çalışması gereken personellerin bilgisi aşağıda yer almaktadır.

7.1.2 Dijital Güngören Fazında Yüklenici 1 Proje Yöneticisi ve 2 Eğitim Destek Personelini tam zamanlı olarak kurum bünyesinde çalıştıracaktır.

7.1.3 Destek Fazında; Yüklenici 1 adet uzman personelini idare bünyesinde çalıştıracaktır.

7.1.4 Yüklenici personeli İdare’nin giriş-çıkış kurallarına, genel disiplin ve kılık kıyafet kurallarına uyacaktır.

7.1.5 İdare isterse yükleniciden bedeli karşılığında ilave personel temini gerçekleştirebilir.

7.1.6 Proje destek ekibinin yapacağı her türlü harcamalar (resmî tatiller, yemek, yol) yüklenici tarafından karşılanacaktır.

7.1.7 Proje destek ekibinde yer alan personel, herhangi bir şekilde işten çekilme yani istifa hakkına sahip olmakla birlikte bu hakkın kullanımı bazı şartlara bağlanacaktır. Görevinden ayrılabilmesi için aşağıdaki koşulların sağlanması gerekecektir.

7.1.7.1 İstifa eden personel kendisine verilen projenin/işinin devir ve teslimi ile yükümlü olacak, bu işlemlerin sonuna kadar görevlerini bırakamayacaktır.

7.1.7.2 Devir ve teslim işlemlerini tamamlamadan görevinden çekilen personel için yüklenici, projenin aksamaması için gerekli tedbirleri alarak işin devamlılığını sağlayacaktır.

7.1.8 Yüklenici personelinin terfi ettirilmesi, pozisyon değişikliği vb. işlemleri Bilgi İşlem tarafından değerlendirilecektir.

7.1.9 Yüklenici ve İdare projeyi gerçekleştirmek için ortak bir ekip kuracaktır. Projeye İdare’nin ve yüklenicin sağlayacağı ekip yapısı aşağıda yer almaktadır. Ekiplerin organizasyon yapısı ve proje görevleri yüklenici ile hazırlanacak proje planı içerisinde belirtilecektir.

7.2 İdare Proje Ekibi

7.2.1 Proje Denetim Kurulu: 3 (üç) asil ve 3 (üç) yedek kişiden oluşacak. Projenin durumunun gözden geçirilmesi amacıyla 15 (on beş) günlük periyotlarla PYT’ler gerçekleştirecektir. İlgili toplantılarda yüklenici tarafından verilen bilgiler ışığında, proje ilerleme durumu, risk değerlendirme, konfigürasyon, hata, kalite ve güvence yönetimi konuları görüşülecektir.

7.2.2 İdare aşağıdaki sayıda personeli projede yüklenici ile çalışabilmesi için hazır edecektir.

Proje Yöneticisi: 1 Kişi

İş Analisti: 2 Kişi

7.3 Yüklenici Merkez Ekibi

7.3.1 Yüklenici projenin zamanında ve hedeflenen seviyede bitirilmesi için aşağıdaki personel kadrosunu bünyesinde bulundurması gerekmektedir. Bu personeller yüklenici bünyesinde çalışacak olup, projenin hangi aşamasında kullanılması gerektiğine yüklenicinin proje yöneticisi karar verecektir.

Proje Yöneticisi:(1 kişi) Lisans mezunu, ayrıca PMI proje metodolojisi uygulayabilecek yetenekte, daha önce en az 5 (beş) kamu kurumunda kurumsal sistemlerin dönüşümü projelerini yönetmiş olması gerekmektedir.

Çözüm Mimarı:(1 kişi) Minimum mühendislik disiplini almış ve üniversitelerin 4 yıllık fakültelerinden mezun olmuş, en az 8 yıl kamu da bilişim projeleri ve Java konusunda deneyime sahip TDD (Test Driven Development) , DDD (Domain Driven Development), MDA (Model Driven Development) veya benzer geliştirme tekniklerini daha önce kullanmış olacaktır. Projede yarı zamanlı bulunacaktır, projenin hangi aşamasında dahil olacağını Proje Yöneticisi belirleyecektir.

Veri Mimarı:(1 kişi) Minimum mühendislik disiplini almış ve üniversitelerin 4 yıllık fakültelerinden mezun olmuş, kamu kurumlarında veri aktarımı konusunda en az 15 yıl bilişim projeleri deneyimine, 10 senelik kamu projeleri deneyimine ve en az 10 senelik UI Framework tecrübesine, Jenkis, Nexus, Tomcat, SOAP ve REST teknolojilerinde de deneyim sahibi olmalıdır.

Yazılım Uzmanı: (5 kişi) Üniversite mezunu, en az 3 (üç) yıl Java projelerinde yazılım geliştirme deneyime sahip olmalıdır.” düzenlemesi yer almaktadır.

Hizmet Alımı İhaleleri Uygulama Yönetmeliği’nin 40’ıncı maddesi uyarınca ihale kapsamında çalıştırılacak personelin nitelikleri ve deneyim süresine ilişkin teknik şartnamede düzenlemeler yapılabileceği, asgari deneyim süresi öngörülmesi halinde bu sürenin 5 yıldan fazla olamayacağı, Teknik Şartname’nin ilgili maddesinde 8, 10 15 yıllık deneyimlerin öngörülmüş olduğu, dolayısıyla bu düzenlemenin mevzuat hükmüne aykırılık içerdiği anlaşılmıştır.

5. Başvuru sahibinin 5’inci iddiasına ilişkin olarak:

Teknik Şartname’nin “Akıllı Şehir Platformun Özellikleri” 8’inci maddesinde “…8.1.6 Uygulama geliştirmesi yapılırken Spring ya da Vaadin gibi yaygın kullanılan Java web frameworkleri tercih edilmesi gerekmektedir.”

…

8.1.7 Uygulama veri tabanı tabloları ya da tablo alanları oluşturulmasını gerektirmemeli ve otomatik olarak gerekli tabloları ya da alanları oluşturabilmelidir.

…

8.1.11 Uygulama modül veya ekranlar uygulama dışından da çağırılarak erişebilme imkanını sağlamalıdır.

…

8.2.12 İdare LDAP ile çalışıyor ise son kullanıcıların şifre değişikliklerini uygulama üzerinden yapabilmesini sağlamalıdır.

…

8.6.16 Raporlar dışarıdan parametre alacak şekilde tasarlanabilir olmalı ve CRM uygulaması ile bütünleşik çalışabilmelidir.

8.6.17 Çoklu erişim kontrolü (Single Sign On) desteği olmalıdır.

8.6.18 Kendisine özgü bir kullanıcı-rol bazlı yetkilendirme mekanizmasına sahip olmalıdır…” düzenlemeleri yer almaktadır.

Teknik Şartname’nin 8.1.6’ncı maddesinde “Vaadin” dışında “Spring framework” de öngörülmüş olduğu, “gibi” denilmek suretiyle örneklendirme yapılmış olduğu görüldüğünden başvuru sahibinin bu konudaki iddiasının uygun olmadığı,

Teknik Şartname’nin 8.1.7’nci maddesinde yer alan düzenlemede idarenin kendi ihtiyacına istinaden veri tabanı tabloları ya da tablo alanları oluşturulmasını istediği, söz konusu özelliği sağlayabilecek tüm istekliler tarafından ihaleye teklif verilebileceği görüldüğünden başvuru sahibinin iddiasının uygun olmadığı,

Teknik Şartname’nin 8.1.11’inci maddesinde yer alan düzenlemede idarenin kendi ihtiyacına istinaden modül veya ekranlar uygulama dışından da çağırılarak erişebilme imkanının olmasını istediği, söz konusu özelliği sağlayabilecek tüm istekliler tarafından ihaleye teklif verilebileceği anlaşıldığından başvuru sahibinin iddiasının uygun olmadığı,

Teknik Şartname’nin 8.2.12’nci maddesinde yer alan düzenlemede idarenin LDAP ile çalışıp çalışmama durumuna göre şifre değişikliklerinin uygulama üzerinden yapılabilmesinin sağlanabileceği, söz konusu şartname maddesinin belli bir firma tarafından hazırlandığına ilişkin bir tespitin belirtilen madde lafzı üzerinden yapılamayacağı görüldüğünden başvuru sahibinin iddiasının uygun olmadığı,

Teknik Şartname’nin 8.6.16’ncı maddesinde raporların CRM uygulaması ile bütünleşik çalışabilmesinin istenildiği, istekliler tarafından CRM ile bütünleşik çalışılabilecek şekilde tekliflerin hazırlanabileceği, söz konusu düzenlemede CRM dışında bir modüle değinilmediği görüldüğünden başvuru sahibinin iddiasının uygun olmadığı,

Teknik Şartname’nin 8.6.17’nci ve 8.6.18’inci maddesindeki teknik koşulların açık bir şekilde Universal Yazılım AŞ’yi işaret edip etmediğine ilişkin olarak hususlarının özel uzmanlık gerektiren hususlar içerdiği, bu itibarla 4734 sayılı Kamu İhale Kanunu’nun “Kuruma itirazen şikayet başvurusu” başlıklı 56’ncı maddesinin altıncı fıkrası çerçevesinde ilgili alanda uzman kişilerin görüşüne başvurularak çözülmesi gerektiği değerlendirilmiş olmakla beraber, başvuru sahibinin 4’üncü, 8’inci ve 9’uncu iddialarına ilişkin yapılan tespitler neticesinde ihalenin iptal edilmesi gerektiği öngörüldüğünden 4734 sayılı Kanun’un temel ilkeleri ile usul ekonomisi gereğince görüş istenilmeden incelemenin sonuçlandırılmasının yerinde olacağı,

Teknik Şartname’nin 8.6.18’inci maddede yer alan ‘‘Kendisine özgü olmalı’’ ifadesinin sübjektiflik içermediği, kullanıcı rol bazlı yetkilendirme mekanizmasına atıf yapılarak düzenleme yapıldığı, söz konusu hususun isteklilerin tekliflerinin sağlıklı bir şekilde hazırlanmasına engel olmadığı,

Sonucuna varılmıştır.

6. Başvuru sahibinin 6’ıncı iddiasına ilişkin olarak:

Teknik Şartname’nin 9’uncu maddesinde “9 Akıllı Şehir Yönetim Platform Uygulamaları

Aşağıda belirtilen uygulamalar teknik şartnamenin 8. Maddesi başlığı altında tarif edilen genel ve teknik özelliklere göre geliştirilmesi gerekmektedir.

9.1 Mesaj Bilgi Sistemi (MBS)

9.1.1 Zamanlı mesaj kayıtları oluşturulabilmelidir.

9.1.2 Mesaj başlık içerik bilgileri girilebilmelidir.

9.1.3 Mesaj belirli bir alfanumeric ile gönderilebilmelidir.

9.1.4 Oluşturulan mesajlar yayın tarihi belirlenebilmelidir.

9.1.5 Mesaj türleri seçilebilmelidir. ( Uyarı, önlem, sistem vb. )

9.1.6 Mesajların okundu bilgileri ekran üzerinden takip edilebilmelidir.

9.1.7 Mesajlar kişilere, gruplara ya da aktif kullanıcılara atılabilecek şekilde gönderim listesi oluşturulabilmelidir.

9.1.8 Mesaj içeriğini oluştururken kullanıcı; Yayın tarihi, Hangi Birimlerde yayınlanacağı, Yayın türü, Yayının Bitiş tarihi, Başlık, Duyuru İçeriği bilgilerini girebilmelidir.

9.1.9 Duyuru içeriği alanına resim eklenebilmelidir.

9.1.10 Hazırlanan bildirimler gönderilmeden önce test yapılabilmelidir.

9.1.11 Geçmişte yayınlanmış bildirimler tekrar yayınlanması sağlanabilmelidir.

9.2 Stratejik Plan Uygulaması

9.2.1 Kurumda kullanılan mevcut otomasyon programı ile entegre çalışmalı ve uygulama üzerinden takip edilebilmelidir.

9.2.2 Stratejik Planlama ve Performans Programı Yönetim Yazılımı 5018 sayılı kanun ve bununla ilişkili olarak çıkarılmış bulunan kılavuz ve yönetmeliklere uygun olarak uzun vadeli Stratejik Plan Hazırlanmasına imkân sağlamalıdır.

9.2.3 Yıllık Performans Programının takibi sağlanabilmelidir.

9.2.4 Performans Esaslı Bütçe ve Faaliyet Raporlarının hazırlanması ile performans programının izlenmesi ve değerlendirilmesi de bu kapsam içinde mevcut kurum bütçesi ile entegre olarak takip edilebilmelidir.

9.2.5 Sistem Devlet Planlama Teşkilatı tarafından yayınlanan Stratejik Planlama Kılavuzuna uygun olarak İdare Stratejik Planının hazırlanmasını desteklemelidir.

9.2.6 Stratejik planın hangi yılları kapsadığını belirleyen bilgiler dönemler altında tanımlanabilmelidir.

9.2.7 Stratejik Plan elemanları arasındaki hiyerarşik ilişkiler tanımlanabilmelidir.

9.2.8 Plan dönemi devam ederken yeni dönem için stratejik plan hazırlama özelliği olmalıdır.

9.2.9 Stratejik amaç ve faaliyetler plan döneminde yıl bazında bütçesel olarak detaylandırılabilmeli, plan ve gerçekleşme değerleri izlenebilmeli ve raporlanabilmelidir.

9.2.10 Performans Programı Stratejik plan ve Organizasyonel yapı ile ilişkili olarak tanımlanabilmelidir.

9.2.11 Performans programında yer alan faaliyet ve proje maliyetleri ekonomik bütçe kodları bazında planlanabilmeli veya dönüştürülebilmelidir.

9.2.12 Proje ve faaliyetlerin gerektirdiği kaynak ihtiyaçları maliyet unsurları ve analitik bütçe kodları detayında planlanabilmelidir.

9.2.13 Maliyet unsurları için ölçü birimi, birim maliyet, miktar ve toplam maliyet tanımlanabilmelidir.

9.2.14 Performans programında yer alan proje ve faaliyetler dönemler itibariyle nakdi ve fiziki gerçekleşmeler olarak raporlanabilmeli ve izlenebilmelidir.

9.2.15 Sistemde geçerli dönem devam ederken yeni dönem için performans programı hazırlama özelliği olmalıdır.

9.2.16 Sistem göstergelerin kullanıcı tarafından tanımlanan esnek ve parametrik periyotlarda izlenmesine imkân sağlamalıdır.

9.2.17 Sistem gerektiğinde Gösterge ve proje verilerini mevcut kurumsal bilgileri içeren veritabanlarından alabilecek özellikte olmalıdır.

9.2.18 Göstergeler stratejik planlama kılavuzunun öngördüğü kategorilere uygun olarak (Girdi, çıktı, sonuç, kalite vb.) sınıflandırılabilmelidir.

9.2.19 Göstergeler için hedefler tanımlanabilmelidir.

9.2.20 Sistem Maliye Bakanlığı Bütçe ve Mali Kontrol Genel Müdürlüğünün yayınlamış olduğu Performans Esaslı Bütçeleme Rehberi’nde belirtilen şekilde İdare ve Birim Faaliyet Raporlarının hazırlanmasına ve dönemsel bazda izlenmesine imkân sağlamalıdır.

9.2.21 Kullanıcılar sorumlu oldukları göstergeler, yatırım planları, projeler ve faaliyetlere kolayca ulaşıp görüntüleyebilmelidir.

9.2.22 Performans göstergeleri idare ve birim bazında topluca veya tek tek izlenip raporlanabilmelidir.

9.3 Kurumsal Arşiv Yazılımı

9.3.1 Web tabanlı olmalıdır. Uygulama modülleri hiçbir şekilde istemci kurulumu gerektirmemelidir.

9.3.2 Web tabanlı uygulama herhangi bir kullanıcı ya da süre sınırı bulundurmayacaktır.

9.3.3 AYS minimum çözünürlüğü destekleyen her türlü tablet, cep telefonu vb. Mobil Cihazlarda düzgün görüntülenebilir çözünürlüğü (responsive) desteklemelidir.

9.3.4 Arşiv belgeleri, PDF, JPEG, TIF, Video, ses gibi çeşitli dosya türlerinde olabilecektir. Kurulacak sistem tüm dosya tiplerini destekleyebilecektir.

9.3.5 Büyük boyutlu TIF dosyalarını son kullanıcı bilgisayarında ek bir kurulum gerektirmeden tarayıcı ortamında performanslı bir şekilde görüntüleyebilmelidir.

9.3.6 Başbakanlık Devlet Arşivleri Genel Müdürlüğü’nün kamu kurum ve kuruluşlarınca elektronik ortamda veya evrak düzeninde oluşturulan belgelerin dosyalanmasında genel bir yöntem olarak belirlediği Standart Dosya Planı’na uyabilecek yapıda olmalıdır.

9.3.7 Üst veri bilgileri kullanılarak arama yapma olanağı sağlamalıdır.

9.3.8 MS Word, MS Excel, HTML, Zengin Metin Biçimi, Metin belgesi ve metin içerikli PDF gibi belgelerin içeriklerini indeksleme özelliğine sahip olmalı, bu tür belgelerin içeriğinden sorgulama yapılması mümkün olmalıdır. Bu bağlamda, uygulamanın tam-metin arama motoru (Full-Text Search Engine) desteği olmalıdır.

9.3.9 Kullanıcı yönetimi ve yetkilendirme yapısı kurumda hali hazırda kullanılan YBS sistemi ile uyumlu çalışacaktır. Kullanıcı yönetimi için kurumca belirlenen standartlar korunacaktır.

9.3.10 Uygulama erişimlerinde her bir kullanıcının sisteme giriş yaptığı zaman ve IP adresi bilgisi sistem üzerinde saklanabilmelidir ve gerektiğinde raporlama aracı ile raporlanabilmelidir.

9.3.11 Uygulamanın kurum dışından erişileceği durumlarda, uygulamaya sadece yetki verilen kullanıcıların giriş yapabilmesi için SMS ile doğrulama yapılabilmelidir.

9.3.12 Single Sign On özelliğini desteklemelidir. Kullanıcılar aynı giriş yöntemini kullanan bir uygulamaya girdiklerinde bir başkasına tekrar şifre girme gerekliliği olmadan girebilmelidir. Kurum isterse tekrar şifre girmeyi de desteklemelidir.

9.3.13 Arama sırasında kullanıcılar sadece yetkili oldukları dokümanları görebilmelidir. Diğer dokümanlar arama sonuçlarında listelenmemelidir.

9.3.14 Arama motoru eklenen verilerin anahtar indeks alanları ile aranmalarına olanak vermelidir.

9.3.15 Kurumun hali hazırda kullandığı BI aracı ile entegre olarak çalışabilmeli ve raporlamalar bu araç üzerinde hazırlanabilmelidir.

9.3.16 Sunucu üzerinde tutulan elektronik dosyalar istenildiği takdirde şifrelenmiş olarak tutulabilmelidir.

9.3.17 AYS içerdiği ORM sistemi sayesinde veri tabanı bağımsız bir şekilde yazılım geliştirilebilmesini sağlamalıdır.

9.3.18 AYS uygulaması idare bünyesinde hali hazırda kullanılmakta olan Oracle VTYS üzerinde çalışabilmelidir.

9.3.19 Üst verileri personeller sadece kendi organizasyonundakileri görerek kullanabilmelidir.

9.3.20 Birim bazlı standart klasör isimleri tanımlanabilmeli ve istenildiği takdirde klasör içinde alt kategoriler oluşturulabilmelidir.

9.3.21 Yüklenecek içerikler üst verilere göre standart isimler belirlenerek dosya isimleri standart halde yüklenebilmelidir.

9.3.22 İçerikler indirme sırasında dosya ismi ile indirilmelidir.

9.3.23 Yüklenmiş içerikler tarih sırasına en sondan en eskiye göre sıralanmalıdır.

9.3.24 AYS ile geliştirilecek uygulamalarda bütün kısıtlamalar ve yetkilendirmeler kullanıcı, grup ve rol bazında sağlanabilmeli.

9.3.25 Uygulama ile uyumlu çalışacak bir belge tarama uygulaması olmalıdır.

9.3.25.1 Tarama uygulaması için herhangi bir lisans, kullanıcı adedi ve süre sınırı gibi kısıtlamalar olmamalıdır.

9.3.25.2 Tarama uygulamasının test modu olmalıdır.

9.3.25.3 Taranan belgesi sağa sola döndürme, rötuş yapma, kırpma gibi fonksiyonlara sahip olmalıdır.

9.3.25.4 Kontrast, parlaklık, keskinlik ayarlanabilmelidir.

9.3.25.5 AYS içerisine klasör oluşturulabilmelidir.

9.3.25.6 Üst veriye göre arama yapılarak istenilen klasörler kolayca bulunabilmelidir.

9.3.25.7 Tif formatında çoklu dosyalar yüklenirken istenirse tek bir pdf dosyası olarak kaydedilebilmelidir.

9.3.25.8 Localde kayıtlı olan dosyalar taranan dosyalar ile aynı işlemlere tabi tutulabilmelidir.

9.3.25.9 Önlü arkalı tarama yapılabilmelidir.

9.3.25.10 Tarayıcı uygulaması taranan belgeyi kurum arşivine gönderebilmelidir.

9.4 İş Takip Sistemi

9.4.1 Gelen Kutusu

9.4.1.1 Genel

9.4.1.1.1 Organizasyon hiyerarşisi tanımlama olanağı sunmalıdır.

9.4.1.1.2 Tanımlı kurum personel bilgisi ile organizasyon hiyerarşisi arasında ilişki kurulmasına olanak vermelidir.

9.4.1.1.3 Kurum servisleri tanımlanabilmelidir.

9.4.1.1.4 Personel ve organizasyon konumu arasında bire çoklu ilişki olmalı, bir personelin birden fazla organizasyon konumunu işgal etmesine olanak sağlamalıdır.

9.4.1.2 Dolaşım, İzleme

9.4.1.2.1 Sevk işlemleri kişi veya organizasyon konumu göz önüne alarak yapılabilmelidir.

9.4.1.2.2 Vekâlet ataması halinde sevkedilen belgenin alıcısına vekâlet eden kullanıcı işi otomatik olarak almalıdır.

9.4.1.3 Şablon Kullanımı

9.4.1.3.1 Belgenin dolaşımı esnasında doc ve rtf formatında üretilmiş belgelerin işle ilişkili standart şablon olarak tanımlanmasına olanak verilmelidir.

9.4.1.4 Elektronik İmza Entegrasyonu

9.4.1.4.1 Elektronik İmza Sistemi, 15/1/2004 tarihli ve 5070 sayılı Elektronik İmza Kanununu ve yönetmeliklerini esas alarak hazırlanmalıdır.

9.4.1.4.2 Kullanıcıların sisteme ekledikleri dokümanları imzalı dosya olarak oluşturabilmelerine olanak sağlamalıdır.

9.4.1.4.3 İmzalanan dosyalar ile ilgili bir tür sınırı olmamalıdır.

9.4.1.4.4 Elektronik imza ile imzalama yapılırken kullanıcının elektronik imzasının geçerliği kontrol edilecektir. Geçersiz imza ile imzalama işlemine izin verilmemelidir.

9.4.1.4.5 Aynı doküman üzerinde seri olarak farklı kullanıcıların imza atmasına olanak sağlamalıdır.

9.4.1.4.6 Aynı doküman üzerinde paralel olarak farklı kullanıcıların imza atmasına olanak sağlamalıdır.

9.4.1.4.7 Elektronik imzalama işlemi Zaman Damgası eklenmesini sağlamalıdır.

9.4.1.4.8 KamuSM tarafından sağlanan e-imza uyumluluk denetiminden herhangi bir müşteri için onay almış olmalıdır.

9.4.1.4.9 İmzalanmış dokümanlar üzerinde doğrulama işlemleri yapılabilmelidir.

9.4.1.4.10 İmzalanmış dokümanlar üzerinden imzalayan bilgisi ve doğrulama verilerini göstermelidir.

9.4.1.4.11 İmzalanmış veriler üzerinde herhangi bir değişiklik yapılmasını engellemelidir. Bu tür dosyalar doğrulama işleminden geçememelidir.

9.4.2 İş Yönetim Sistemi

9.4.2.1 Genel Özellikler

9.4.2.1.1 İçerik depolamak için kayıt havuzu (repository) sağlamalıdır.

9.4.2.1.2 Uygulama, içeriği özgün dosya biçiminde saklamalıdır.

9.4.2.1.3 Uygulama ile istemci arasında sürücülerin eşlenmesini (Map) gerektirmemelidir.

9.4.2.1.4 Uygulama, eklenecek dosya ve içerikler için kullanılacak üst veri alanlarının tanımlanabilmesine olanak tanımalıdır.

9.4.2.1.5 Uygulama, sistemde tanımlanacak kullancılara erişim seviyeleri (Tasnif dışı, Hizmete özel, Kişiye özel, Özel, Gizli, Çok gizli) tanımlanabilmesine olanak vermelidir.

9.4.2.1.6 Kullanıcılar kendilerine tanımlanmış erişim seviyesinden daha yüksek erişim seviyesine sahip belgelere erişememelidir.

9.4.2.2 Doküman İşlemleri (Ekleme, Silme, Güncelleme)

9.4.2.2.1 Dosya ve içerik silme işlemi gerçekleştirilebilmelidir.

9.4.2.2.2 Belge sorgulama sonucunda gelen sonuçlar içinde sayfalama yapabilmelidir.

9.4.2.2.3 Birden çok dokümanın tek bir işlem ile yüklenmesine izin vermelidir.

9.4.2.2.4 Birden çok dosyanın yüklenmesi esnasında aynı isimde dosyaların yüklenmesi söz konusu olduğunda dosya adını tarih ve saat ekleyerek farklılaştırmalı ve yükleme işlemine devam etmelidir.

9.4.2.2.5 Uygulama, sisteme bir belge, sürüm veya klasör eklendiğinde kullanıcıdan otomatik olarak bunların meta veri özelliklerini girmesini istemelidir.

9.4.2.2.6 Kullanıcıların yetkiye bağlı olarak kullanıma alma işlemini iptal etmelerine olanak tanımalıdır.

9.4.2.2.7 Doküman ekleme, silme ve güncelleme işlemleri kullanıcı bazında yetkilendirilebilmelidir.

9.4.2.2.8 Kullanıcının uygun güvenlik erişimine sahip olmadığı klasörler listelenmemelidir.

9.4.2.2.9 Kullanıcıların belgeleri kullanıma almadan ECM sunucusundan, kullanıcı bilgisayarına kopyalamasına olanak sağlamalıdır.

9.4.2.2.10 Kullanıcıların ECM Sunucusundan bir belgeyi kopyalayıp e-posta yoluyla göndermesine olanak sağlamalıdır.

9.4.2.2.11 Dokümanlar üzerinde kullanıcılar tarafından “Kullanıma Alma” ve “İade Etme” işlemleri yapılabilmelidir. Kullanıma alınmış doküman diğer kullanıcılar tarafından salt okunur olarak görüntülenebilmeli, üzerinde değişiklik yapılmasına izin verilmemelidir.

9.4.2.2.12 İşletim sistemi güvenliği sağlanması halinde kendi sunduğu erişim özellikleri, web arayüzleri ve web servisleri dışında, başka bir yoldan, belgelere ulaşılmasına izin vermemelidir.

9.4.2.2.13 Meta veri girişlerinde kontrollü alanların tanımlanmasına ve kullanılmasına izin vermelidir

9.4.2.3 Doküman Tarihçe İzleme

9.4.2.3.1 Dokümanların versiyonlanmasını (dokümanda değişiklik yapılmasına ilişkin kayıt oluşturulmasını ve değişikliklerin öncesine ulaşılabilmesini) sağlamalıdır.

9.4.2.3.2 Kullanıcıların belgenin herhangi bir sürümünü görüntülemelerine olanak sağlamalıdır.

9.4.2.4 Görüntüleyici

9.4.2.4.1 Sık kullanılan uluslararası dosya formatlarının, sadece görüntüleme amaçlı olarak açılmasını desteklemelidir.

9.4.2.4.2 Görüntüleyici, görüntülediği her bir belgeye kullanıcının belgeye ilişki açıklamalarını ilişkilendirebilmelidir. Eklenen açıklamalar kullanıcı, tarih, saat, ünvan bilgilerini içermelidir.

9.4.2.4.3 Ek açıklamalar özgün görüntüyü değiştirmemelidir.

9.4.2.4.4 Görüntüleyici, yalnızca uygun güvenlik erişimine sahip olunması durumunda ek açıklamaların silinmesine izin vermelidir.

9.4.2.5 Dosya Sınıflama

9.4.2.5.1 Başbakanlık Devlet Arşivleri Genel Müdürlüğü’nün kamu kurum ve kuruluşlarınca elektronik ortamda veya evrak düzeninde oluşturulan belgelerin dosyalanmasında genel bir yöntem olarak belirlediği Standart Dosya Planı’na uyabilecek yapıda olmalıdır.

9.4.2.6 Arama

9.4.2.6.1 Üst veri bilgileri kullanılarak arama yapma olanağı sağlamalıdır.

9.4.2.6.2 MS Word, MS Excel, HTML, Zengin Metin Biçimi, Metin belgesi ve metin içerikli PDF gibi belgelerin içeriklerini indeksleme özelliğine sahip olmalı, bu tür belgelerin içeriğinden sorgulama yapılması mümkün olmalıdır. Bu bağlamda, uygulamanın tam-metin arama motoru (Full-Text Search Engine) desteği olmalıdır.

9.4.2.6.3 Arama sırasında kullanıcılar sadece yetkili oldukları dokümanları görebilmelidir. Diğer dokümanlar arama sonuçlarında listelenmemelidir.

9.4.3 İzlediklerim

9.4.3.1 İş Yönetim Sistemi üzerinden oluşturulan işler aynı bir ekran üzerinden liste halinde takip edilebilmelidir.

9.4.3.2 İzlenilme başlatılan iş hakkında değişiklik olduğunda sistem üzerinden bildirim gelmelidir.

9.4.3.3 İzlenilme işleminin nasıl tamamlanacağını kullanıcı tarafından seçilmelidir. Burada 2 tür sonuçlanma yöntemi olmalıdır

9.4.3.3.1 İş Tamamlandığında

9.4.3.3.2 Kullanıcının manuel işlem yaparak

9.4.4 Takvim

9.4.4.1 Kullanıcının üstünde olan işlerin ya da görevlere ait bir etkinlik oluşturulduğu takdirde, işler takvim gösterimde gösterilmesi gerekir.

9.4.4.2 Etkinlik türleri sistem tarafından değiştirilebiliyor olmalıdır.

9.4.4.3 Oluşturulan etkinliğe başka kullanıcılar da davet edilebilmelidir.

9.4.4.4 Etkinlik detay ekranında ilgili işlemlere basıldığında aşağıdaki işlemler yapılabilmelidir.

9.4.4.4.1 SMS Gönderimi

9.4.4.4.2 Son İşlem Bilgisi gösterimi

9.4.4.4.3 Mail gönderimi

9.4.4.4.4 Etkinlik ile ilişkili İş’in gösterimi” düzenlemesi yer almaktadır.

Teknik Şartname’nin 9’uncu maddesindeki düzenlemelerin üçüncü parti olmalıymış gibi tarif edildiği, bunun Universal Yazılım A.Ş.’nin bu çözümleri üçüncü parti sistemleri uyarlayarak sağlamış olmasından kaynaklandığı, sistem içerisinde yer alan “web tabanlı”, “responsive”, “sisteme girildiğinde IP’nin saklanması”, “ORM sistemi sayesinde veri tabanı bağımsız” türünden ifadelerin ana YBS uygulaması dışında üçüncü parti uygulamalar ile sağlanması durumunda anlamlı olabileceği, Universal Yazılım A.Ş.’nin sağladığı çözümlerin özellikle dayatıldığı, tek elden tasarlanmayan 3’üncü parti sistemleri uyarlayarak sağlanan çözümlerin bütünleşik çalışma noktasında ne kadar başarılı olabileceğinin tartışmalı olduğu ve Teknik Şartname’nin 9.4.2’nci maddesinde yer alan düzenlemelerin Universal Yazılım A.Ş.’nin kullanmakta olduğu üçüncü parti çözümleri tarif ettiğine ilişkin iddiaların özel uzmanlık gerektiren hususlar içerdiği, bu itibarla 4734 sayılı Kamu İhale Kanunu’nun “Kuruma itirazen şikayet başvurusu” başlıklı 56’ncı maddesinin altıncı fıkrası çerçevesinde ilgili alanda uzman kişilerin görüşüne başvurularak çözülmesi gerektiği değerlendirilmiş olmakla beraber, başvuru sahibinin 4’üncü, 8’inci ve 9’uncu iddialarına ilişkin yapılan tespitler neticesinde ihalenin iptal edilmesi gerektiği öngörüldüğünden 4734 sayılı Kanun’un temel ilkeleri ile usul ekonomisi gereğince görüş istenilmeden incelemenin sonuçlandırılmasının yerinde olacağı,

Teknik Şartname’nin 9’uncu maddesinin başlığının Akıllı Şehir Yönetim Platform Uygulamaları olarak belirlendiği ve buna ilişkin düzenlemelerin yapılmış olduğu, idarenin kendi ihtiyaçlarına istinaden alacağı sistemde Akıllı Şehir Yönetim Platform Uygulamaları’nın olmasını isteyebileceği, ihtiyacına istinaden şablon, elektronik, imza gibi tanımlamalara şartnamede yer verebileceği, tercih ettiği platformların kullanılmasına ilişkin düzenlemeler yapabileceği öngörüldüğünden başvuru sahibinin iddiasının uygun olmadığı,

Teknik Şartname’nin 9.4.2.1.2’nci maddede yer alan “Uygulama, içeriği özgün dosya biçiminde saklamalıdır.” düzenlemesinin muğlaklık içermediği, uygulamanın saklama türünün özgün dosya biçiminde olmasının idarenin ihtiyaçları doğrultusunda istenildiği, istekliler tarafından söz konusu düzenlemeye istinaden tekliflerin tereddüde düşülmeden hazırlanabileceği anlaşıldığından başvuru sahibinin iddiasının uygun bulunmadığı,

Sonucuna varılmıştır.

7. Başvuru sahibinin 7’inci iddiasına ilişkin olarak:

Teknik Şartname’nin “Mobil Çözümler” başlıklı 10’uncu maddesinde “10.1 Teknik şartnamede istenilen mobil kurum çözümleri bu başlıkta yer alan özelliklere göre geliştirilecektir.

10.2 Cihazın ekran boyutuna uygun bir şekilde uygulama kullanım sağlayan ekran tasarımları olmalıdır. Bu ekran tasarımlarında düğme büyüklükleri, düğmelerin yerleşimleri, menülerin yerleşimi, vb. gibi mobil cihazlar için uygulama geliştirmede kullanılan görsel arayüz standartları sağlanmalıdır.

10.3 Mobil uygulamalar bütünleşik sistemle aynı kullanıcı, parola, rol ve grup tanımlarını kullanmalıdır.

10.4 Mobil uygulama react native ya da flutter gibi günümüzde yaygın kullanılan teknolojiler ile geliştirilmesi gerekmektedir.

10.5 Uygulamalar iOS ve Android tabanlı mobil cihazlarda sorunsuz ve takılmadan çalışmalıdır.

10.6 Uygulamalardaki ekranlar rol tabanlı bir yapıda olmadır. Bunlara istenilen rollerdeki kişiler erişebilmelidir.

10.7 Uygulamalar GPRS/3G/4,5G ve Wireless altyapısı kullanarak servislere bağlanıp canlı işlem yapabilmelidir.

10.8 Uygulamaya hızlı giriş yapılabilmesi için otomasyon tarafından oluşturulan QR kodları okutarak hızlı giriş yapılabilme özelliği olmalıdır.

10.9 Uygulamaların tüm veri alışverişi web servisler üzerinden olmalıdır.

10.10 Bütün mobil uygulamalarda yapılabilecek işler kurumsal sistemler ile entegre olmalıdır.

10.11 Uygulama içerisinde QR kod okuma özelliği olmalıdır. Aynı zamanda bağlantı ekranında mobil kullanıcıların sisteme daha hızlı bağlanabilmesi için kurumsal sistem tarafından üretilen QR kod’u okutarak sisteme bağlanabilmelidir.

10.12 Yüklenici, proje süresi boyunca şartname kapsamındaki mobil uygulamaların ihtiyacı olan uygulamanın güncelleme işlemlerini ücretsiz olarak devam edecektir.

10.13 Uygulamada mobil imza ve elektronik imza desteği bulunacaktır.

10.13.1 M-İmza İşlemleri (EBYS Çözümü ile entegre çalışan)

10.13.2 Paraf İşlemleri

10.13.3 Kullanıcı Özet Ekranı (İzin, Bordro, Üzerindeki İşler, İmzalaması Gereken Evrak Sayısı)

10.13.4 İzin Talep ve İzin Yönetimi

10.13.5 Çek Gönder

10.13.6 Zabıta Tutanak/Ceza İşlemleri

10.13.7 Sicil Analizi

10.13.8 Taşınmaz Analizi

10.13.9 Beyan Arama İşlemleri

10.13.10 Mali Yönetici Konsolu (Tarih Filtreli Günlük Nakit Akışı, Günlük Ödemeler, Kasa Durumu, Müdürlüklerin Gider Bütçe Durumları)” düzenlemesi yer almaktadır.

Teknik Şartname’nin 10.8’inci maddesinde yer alan düzenlemede uygulamalara hızlı giriş yapılabilmesi için QR kodu okutularak giriş yapabilmenin mümkün kılınması istenildiği, 10.11’inci maddede sisteme daha hızlı bağlanılabilmesi için uygulama içinde QR kod okumanın yer alması gerektiğinin belirtildiği, söz konusu düzenlemelerde muğlaklık olmadığı, QR kodunun istenilmesini nedenin belirtildiği, istekliler tarafından söz konusu düzenlemeye istinaden tekliflerin tereddüde düşülmeden hazırlanabileceği sonucuna varıldığından başvuru sahibinin iddiasının uygun bulunmadığı sonucuna varılmıştır.

8. Başvuru sahibinin 8’inci iddiasına ilişkin olarak:

4734 sayılı Kanun’un “Tanımlar” başlıklı 4’üncü maddesi “…..Yüklenici : Üzerine ihale yapılan ve sözleşme imzalanan istekliyi, ….. İstekli : Mal veya hizmet alımları ile yapım işlerinin ihalesine teklif veren tedarikçi, hizmet sunucusu veya yapım müteahhidini, ….” hükmü,

Kamu İhale Genel Tebliği’nde “74.4. Hizmet alımı ihalelerinde; Tehlike Analizi ve Kritik Kontrol Noktaları Yönetim Sistemi (HACCP), İş Sağlığı ve Güvenliği Yönetim Sistemi (OHSAS), Bilgi Teknolojisi-Bilgi Güvenliği Yönetim Sistemi, Gıda Güvenliği Yönetim Sistemi (ISO 22000), Sosyal Sorumluluk Standardı (SA 8000), İyi Hijyen Uygulamaları (GPP) gibi kalite ve standarda ilişkin belgeler ve sertifikalar istenmeyecektir.

74.5. Hizmet alımı ihalelerinde kalite yönetim sistem belgesi ve/veya çevre yönetim sistem belgesinin istenip istenmeyeceği, 74.7. maddesindeki açıklama ve aşağıdaki esaslara uygun olarak idarelerce belirlenecektir.

74.5.1. İdarelerin kendi hizmet binalarında veya diğer görev sahalarında gerçekleştirilen hizmet alımı ihaleleri (örneğin; temizlik, özel güvenlik, hasta ve ziyaretçi yönlendirme, veri işleme ve otomasyon sisteminin işletimi, yemek hazırlama ve dağıtım hizmetleri gibi) ile personel/ öğrenci taşıma hizmetleri ve araç kiralama hizmet alımı ihalelerinde kalite yönetim sistem belgesi istenmeyecektir.

74.5.2. İdarelerin kendi hizmet binalarında veya diğer görev sahalarında gerçekleştirilen hizmetler (örneğin; temizlik, özel güvenlik, hasta ve ziyaretçi yönlendirme, veri işleme ve otomasyon sisteminin işletimi, yemek hazırlama ve dağıtım hizmetleri gibi) ile niteliği gereği çevre yönetim sistem belgesi istenmesi uygun olmayan hizmet alımı ihalelerinde (personel ve öğrenci taşıma hizmetleri, araç kiralama, mesleki eğitim, toplantı ve organizasyon hizmetleri gibi) çevre yönetim sistem belgesi istenmeyecektir.

74.6. Hizmet yeterlilik belgesinin kuruluş yapısı, planlama faaliyetleri ve sorumluluklar göz önünde bulundurulduğunda; idarelerin kendi hizmet binalarında gerçekleştirilen hizmetler (idarelerin hizmet binalarında, servislerce gerçekleştirilecek montaj, bakım ve onarım hizmetleri hariç) ile niteliği gereği hizmet yeterlilik belgesi istenmesi uygun olmayan (personel ve öğrenci taşıma hizmetleri, araç kiralama, mesleki eğitim, toplantı ve organizasyon hizmetleri gibi) ihalelerde bu belge istenmeyecektir. İdareler, hizmet yeterlilik belgesine yönelik düzenlemelerde; hizmet yeterlilik belgesinin hizmet kapsamını ve standardını açık olarak yazmalıdır.

74.7. Çöp toplama ve/veya kent temizliği hizmet alımı ihalelerinde; kalite yönetim sistem belgesi, çevre yönetim sistem belgesi ve İşyerleri-Kent Temizliği Hizmet Yeterlilik Belgesi (TS 13111) istenebilecektir.

74.8. 4734 sayılı Kanunun 13 üncü maddesinin birinci fıkrasının (b) bendinin (2) numaralı alt bendinde hizmet alımları için öngörülen üst limit tutarının dört katının altında kalan ve hizmet alımı ihalesiyle gerçekleştirilecek olan danışmanlık hizmeti alımlarında kalite ve standarda ilişkin belgeler kapsamında sadece kalite yönetim sistem belgesi istenebilecektir.” düzenlemesi yer almaktadır.

Teknik Şartname’nin 12’nci maddesinde “12.22 Yüklenicinin kuruma sunması gereken sertifikalar aşağıda belirtilmiş olup Sözleşme Öncesinde sunulması gerekmektedir;

ISO 22301:2012 - Toplumsal Güvenlik - İş Sürekliliği Yönetim Sistemleri Sertifikası

ISO/IEC 27001:2013 – Bilgi Güvenliği Yönetim Sistemi Sertifikası

ISO/IEC 20000-1:2011 - Bilgi Teknolojileri Hizmet Yönetim Sistemi

Yerli Malı Belgesi

ISO 9001:2015 – Kalite Yönetim Sistemi Sertifikası

TS 13149 – Hizmet Yeterlilik Belgesi” düzenlemesi yer almaktadır.

Kamu İhale Genel Tebliği’nde yer alan düzenleme uyarınca hizmet alımı ihalelerinde Bilgi Teknolojisi-Bilgi Güvenliği Yönetim Sistemi belgelerinin istenilemeyeceği, idare tarafından Teknik Şartname’nin 12.22’inci maddesinde ISO/IEC 27001:2013 – Bilgi Güvenliği Yönetim Sistemi Sertifikası ile ISO/IEC 20000-1:2011 - Bilgi Teknolojileri Hizmet Yönetim Sistemi belgelerinin söz konusu Tebliğ düzenlemesine aykırı olarak istenildiği görüldüğünden başvuru sahibinin bu hususa ilişkin iddiasının yerinde olduğu sonucuna varılmıştır.

İhale konusu iş veri işleme ve otomasyon sisteminin işletimi işine benzer bir nitelikte iş olduğu için Kamu İhale Genel Tebliği’nin 74.5.1’inci maddesinde belirtilen düzenleme uyarınca ISO 9001:2015 – Kalite Yönetim Sistemi Sertifikası’nın istenilmesinin uygun olmadığı sonucuna varılmıştır.

İdari Şartname’nin 7’nci maddesinde ihaleye katılabilmek için gereken belgeler ve yeterlik kriterlerine yer verilmiş olup, sözleşmenin imzalanmasından önce sunulması istenilen belgelerin anılan maddede belirtilmesine gerek bulunmadığı sonucuna varılmıştır.

İdare tarafından yüklenici tarafından sözleşmenin imzalanmasından önce söz konusu belgelerin sunulması gerektiğine ilişkin düzenleme yapıldığı, yüklenici ifadesinin sözleşme imzalamış olan ihale üzerinde bırakılan istekliyi ifade ettiği, belgelerin ise sözleşmenin imzalanmasından önce sunulmasının istenildiği, bahsi geçen düzenleme uyarınca söz konusu belgelerin sözleşmenin imzalanmasından önce ihale üzerinde bırakılan istekli tarafından mı, sözleşmenin uygulanması aşamasında yüklenici tarafından mı sunulması gerektiğinin anlaşılamadığı, bu hususun ihale ve sözleşmenin uygulanması aşamasında uyuşmazlıklara neden olabilecek nitelikte olduğu anlaşıldığından başvuru sahibinin bu hususa ilişkin iddiasının yerinde olduğu sonucuna varılmıştır.

9. Başvuru sahibinin 9’uncu iddiasına ilişkin olarak:

Teknik Şartname’nin 18’inci maddesinde “18- Bulut Sunucu Kiralama Hizmeti

18.1 Proje süresi boyunca sunucu kiralama hizmeti verilecektir.

18.2 Hizmet sağlayıcının veri merkezi Türkiye sınırları içinde yer almalıdır. Temin edilecek Sanal sunucular VM Ware ortamında çalışacaktır.

18.3 Bu kapsamda: Temin edilecek Sanal Sunucuların toplam işlemci kaynağı 104 adet GHZ (VCPU) olmalıdır.

18.4 Temin edilecek Sanal Sunucuların toplam Bellek (RAM) kaynağı 256 GB olmalıdır.

18.5 Temin edilecek Sanal Sunucuların toplam Disk kaynağı 4000 GB SAS 1000 GB SSD ve Backup Disk Alanı 10 TB SSD türünde olmalıdır.

18.6 Temin edilecek Sanal Sunucuların internet erişim bant genişliği simetrik (upload ve download eşit olacak şekilde) ve 100 Mbps kapasitede olmalıdır.

18.7 Temin edilecek Sanal Sunucular önünde 100 Mbps kapasiteye kadar destekli yönetilebilir güvenlik duvarı yer almalıdır.

18.8 Kuruma, 100 Mbps Ddos atak koruması sağlanmalıdır. Ddos atak koruması hizmet sağlayıcının internet omurgasında yapılmalıdır.

18.9 Kritik dataların yedeğinin alınması için 2000 GB kotalı sanal sunucu yedekleme hizmetli al yapısı sağlanacaktır.

18.10 Hizmet sağlayıcının veri merkezi 2 farklı gerilim hattından beslenmelidir. Jenaratör ve ups sistemleri yedekli olarak çalışmalıdır. Herhangi bir enerji kesintisinde sistem 72 saate kadar kesintisiz çalışmaya devam etmelidir. Servis sağlayıcının en az iki farklı şehirde tier 3 veri merkezi olmalıdır.

18.11 Hizmet sağlayıcının iklimlendirme sistemi yedekli olarak çalışmalıdır.

18.12 Yüklenici, sanal sunucular ve erişim devreleri için 7x24 e-posta ve telefon ile teknik destek hizmeti sağlayacaktır.

18.13 Bulut Hizmeti Resmi Gazetede yayımlanan 30823 Sayı, 6 Temmuz 2019 tarihli “Bilgi ve İletişim Güvenliği Tedbirleri” genelgesine uygun olmalıdır.

18.14 Bulut Hizmeti T.C. Cumhurbaşkanlığı Dijital Dönüşüm Ofisi’nin 10.07.2020 tarihli Bilgi ve İletişim Güvenliği Rehberi’nde belirtilen Kapsam ve Kriterlere uygun olmalıdır.” düzenlemesi yer almaktadır.

Başvuru sahibinin söz konusu iddialarının özel uzmanlık gerektiren hususlar içerdiği, bu itibarla 4734 sayılı Kamu İhale Kanunu’nun “Kuruma itirazen şikayet başvurusu” başlıklı 56’ncı maddesinin altıncı fıkrası çerçevesinde ilgili alanda uzman kişilerin görüşüne başvurularak çözülmesi gerektiği değerlendirilmiş olmakla beraber, başvuru sahibinin 4’üncü, 8’inci ve 9’uncu iddialarına ilişkin yapılan tespitler neticesinde ihalenin iptal edilmesi gerektiği öngörüldüğünden 4734 sayılı Kanun’un temel ilkeleri ile usul ekonomisi gereğince görüş istenilmeden incelemenin sonuçlandırılmasının yerinde olacağı anlaşılmıştır.

Teknik Şartname’de yer alan 104 adet GHZ (VCPU), 256 GB, 4000 GB SAS 1000 GB SSD ve Backup Disk Alanı 10 TB SSD, 100 Mbps, 2000 GB ifadelerinin en az ve en çok değerleri veya belli aralıkları ifade edecek şekilde belirlenmediği, doğrudan belirli kapasitedeki cihaz ve sistemleri işaret etmek suretiyle rekabetin daraltıldığı, söz konusu düzenleme uyarınca belirtilen özelliklerden daha üstün olan cihaz ve sistemlerin dahi teklif edilebilmesine olanak verilmediği, dolayısıyla kaynakların verimli kullanılması ilkesine de aykırılık teşkil ettiği anlaşıldığından başvuru sahibinin iddiasının yerinde olduğu sonucuna varılmıştır.

Sonuç olarak, yukarıda mevzuata aykırılıkları belirtilen işlemlerin düzeltici işlemle giderilemeyecek nitelikte işlemler olduğu tespit edildiğinden, ihalenin iptali gerekmektedir.

Açıklanan nedenlerle, 4734 sayılı Kanun'un 65'inci maddesi uyarınca bu kararın tebliğ edildiği veya tebliğ edilmiş sayıldığı tarihi izleyen 30 gün içerisinde Ankara İdare Mahkemelerinde dava yolu açık olmak üzere,

Anılan Kanun'un 54'üncü maddesinin onbirinci fıkrasının (a) bendi gereğince ihalenin iptaline,

Oybirliği ile karar verildi.