Türkiye Sürdürülebilirlik Raporlama Standartları (TSRS) kapsamındaki şirketler iklim ve sürdürülebilirlik verilerini finansal raporlarla tutarlı biçimde raporlamak zorunda. KGK’nın 27 Ekim 2026 duyurusuna göre bankalar 2026 dönemi için eşik aranmaksızın kapsamda; rapor, dönem sonundan itibaren dokuz aya kadar yayımlanabiliyor (kaynak). 360 Soft, raporun dayandığı verileri toplayan ve denetime hazır tutan yazılımı geliştirir.
Bu sayfada TSRS raporlamasının veri tarafını uçtan uca ele alıyoruz: kimlerin kapsamda olduğu, TSRS 1 ve TSRS 2’nin yazılımdan ne beklediği, hangi modüllerin gerektiği, kurulumun nasıl ilerlediği, maliyeti neyin belirlediği ve bir çözüm seçerken nelere bakmanız gerektiği. Amacımız, sürdürülebilirlik ekibinin, finans biriminin ve bilgi işlemin aynı tabloya bakarak karar verebilmesi.
TSRS nedir, kimleri ilgilendirir?
Türkiye Sürdürülebilirlik Raporlama Standartları, Kamu Gözetimi, Muhasebe ve Denetim Standartları Kurumu (KGK) tarafından yayımlanan ve Uluslararası Sürdürülebilirlik Standartları Kurulu’nun (ISSB) IFRS S1 ve IFRS S2 standartlarıyla uyumlu iki temel standarttan oluşur. TSRS 1, sürdürülebilirlikle ilgili finansal bilgilerin açıklanmasına ilişkin genel hükümleri; TSRS 2 ise iklimle ilgili açıklamaları düzenler. İki standardın ortak fikri şudur: sürdürülebilirlik bilgisi artık ayrı bir “kurumsal sosyal sorumluluk” broşürü değil, finansal tablolarla aynı raporlama dönemine, aynı raporlayan işletmeye ve benzer kalite beklentisine tabi bir finansal bilgi türüdür.
Kapsam, KGK’nın kurul kararlarıyla belirlenir. Genel olarak sermaye piyasasında işlem gören şirketler, bankalar, sigorta ve emeklilik şirketleri gibi kamu yararını ilgilendiren kuruluşlar ile aktif büyüklüğü, net satış hasılatı ve çalışan sayısı ölçütlerinden belirli eşikleri aşan büyük işletmeler kapsamdadır. Eşikler ve muafiyetler dönemden döneme güncellenebildiği için kesin değerlendirmeyi her raporlama dönemi başında güncel kurul kararlarına bakarak, mali müşaviriniz veya denetçinizle birlikte yapmanızı öneririz. Kapsam dışında kalan pek çok şirket de, kapsamdaki bir müşterinin ya da finansman sağlayan bir bankanın tedarik zinciri veri taleplerini karşılamak için benzer veriyi üretmek durumunda kalır.
TSRS 2’nin dört temel başlığı
| Başlık | Ne açıklanır? | Yazılımdan beklenen |
|---|---|---|
| Yönetişim | İklim risk ve fırsatlarının hangi kurul ve yöneticiler tarafından, hangi sıklıkla izlendiği | Komite toplantı kayıtları, rol ve sorumluluk matrisi, onay geçmişi |
| Strateji | İklim kaynaklı risk ve fırsatların iş modeline, değer zincirine ve finansal duruma etkisi; senaryo analizi ve dayanıklılık | Risk-fırsat envanteri, senaryo varsayımlarının sürümlenmesi, finansal etki notları |
| Risk yönetimi | İklim risklerinin nasıl belirlendiği, değerlendirildiği ve genel risk yönetimine nasıl entegre edildiği | Risk puanlama şablonları, kurumsal risk kaydıyla bağlantı, aksiyon takibi |
| Metrikler ve hedefler | Kapsam 1, 2 ve 3 sera gazı emisyonları, sektöre özgü metrikler, iç karbon fiyatı, hedefler ve ilerleme | Faaliyet verisi toplama, emisyon faktörü kütüphanesi, hesaplama motoru, hedef izleme |
TSRS 1 ise iklim dışındaki sürdürülebilirlik risk ve fırsatlarının da aynı mantıkla belirlenmesini, önemlilik değerlendirmesinin yapılmasını ve bilgilerin finansal tablolarla bağlantılı sunulmasını ister. Standartlar ilk uygulama yıllarında bazı geçiş kolaylıkları tanır; örneğin karşılaştırmalı bilgi verilmemesi, ilk yılda iklim konularına odaklanılması ya da Kapsam 3 açıklamasının ertelenmesi gibi. Bu kolaylıkların hangi dönemlere uygulanabileceğini güncel düzenlemeden teyit edin; yazılım tarafında önemli olan, geçiş dönemi biterken eksik kalan veri setlerini önceden toplamaya başlamaktır.
Sektöre göre tipik zorluklar
- Sanayi ve üretim: Onlarca tesisten gelen elektrik, doğalgaz, yakıt ve proses emisyonu verisi farklı formatlarda tutulur. Aynı veri SKDM (CBAM) emisyon raporlaması için ürün bazında da istenir; iki ayrı tablo tutmak tutarsızlık doğurur.
- Bankacılık ve finans: Kendi operasyonel emisyonu küçüktür, asıl yük kredi ve yatırım portföyünden kaynaklanan finanse edilen emisyonlardır. Binlerce müşteri için tahmini ve gerçek veriyi ayrı veri kalitesi skorlarıyla tutmak gerekir.
- Perakende ve lojistik: Mağaza, depo ve araç filosu verisi dağınıktır; Kapsam 3’te satın alınan ürünler ve dağıtım kalemleri baskındır. Tedarikçi anketleri ve harcama bazlı tahminler birlikte yönetilir.
- Enerji ve altyapı: Yüksek emisyon yoğunluğu, uzun ömürlü varlıklar ve geçiş riski nedeniyle senaryo analizi ve sermaye harcaması planlarıyla bağlantı kritik hale gelir.
- Holdingler: Farklı sektörlerdeki iştiraklerin konsolidasyon yaklaşımı (operasyonel kontrol, finansal kontrol, pay oranı) finansal tablolarla uyumlu kurulmazsa denetimde ilk sorgulanan konu olur.
Ortak sorun her zaman aynıdır: veri e-posta ekleriyle dolaşan Excel dosyalarında toplanır, kimin hangi rakamı ne zaman değiştirdiği izlenemez ve güvence denetimi sırasında bir rakamın faturaya, sayaca veya ERP kaydına kadar geri izlenmesi günler alır. TSRS yazılımının temel değeri, bu izlenebilirliği varsayılan hale getirmesidir.
Yazılım kapsamı: modüller
| Modül | İşlev | Tipik kullanıcı |
|---|---|---|
| Organizasyon ve sınır tanımı | Tüzel kişilikler, tesisler, konsolidasyon yaklaşımı ve pay oranları | Sürdürülebilirlik ve finans ekibi |
| Veri toplama ve görev akışı | Dönemsel veri talepleri, sorumlu atama, hatırlatma, belge yükleme, onay | Tesis ve departman veri sahipleri |
| Entegrasyonlar | ERP, muhasebe, enerji yönetim sistemi, sayaç ve IoT verisi, akaryakıt kartı ve fatura aktarımı | Bilgi işlem |
| Emisyon hesaplama motoru | Kapsam 1, 2 (konum ve piyasa bazlı) ve 3 hesapları; sürümlenmiş emisyon faktörü kütüphanesi | Sürdürülebilirlik uzmanı |
| Tedarikçi portalı | Kapsam 3 ve ürün karbon ayak izi için tedarikçi anketleri ve veri doğrulama | Satın alma |
| Risk ve senaryo | İklim risk-fırsat envanteri, fiziksel ve geçiş riski değerlendirmesi, senaryo varsayımları | Risk yönetimi |
| Hedef ve aksiyon takibi | Azaltım hedefleri, baz yıl yeniden hesaplama, proje bazlı ilerleme | Üst yönetim |
| Denetim izi ve kanıt arşivi | Her değerin kaynağı, değişiklik geçmişi, onaylayan kişi ve ekli kanıt | Güvence denetçisi |
| Raporlama ve dışa aktarım | TSRS açıklama şablonları, gösterge panoları, Excel ve PDF çıktıları, finansal tablo bağlantısı | Yatırımcı ilişkileri, finans |
Modüller birbirinden bağımsız devreye alınabilir. Çoğu şirket veri toplama, hesaplama ve denetim izi ile başlar; tedarikçi portalı ve senaryo modülü ikinci fazda eklenir. Ürün bazlı karbon verisine ihtiyaç duyan şirketlerde aynı altyapı dijital ürün pasaportu çalışmasına da veri sağlayabilir.
Teknoloji ve veri altyapısı
Tipik mimaride web tabanlı bir uygulama, ilişkisel veritabanı, entegrasyonlar için API ve zamanlanmış veri aktarım işleri bulunur. Büyük veri hacmi olan şirketlerde ayrı bir veri ambarı veya veri gölü katmanı kurulur; burada veri mühendisliği desteği, ETL süreçlerinin doğru ve tekrar üretilebilir olması için önemlidir. Emisyon faktörleri, kaynağı ve geçerlilik yılı ile birlikte sürümlenir; bir faktör güncellendiğinde geçmiş dönem sonuçları sessizce değişmez, yeniden hesaplama bilinçli bir işlem olarak kayda geçer.
Teslim modelleri: SaaS, kurulum ve yönetilen hizmet
| Model | Nasıl çalışır? | Kimin için uygun? |
|---|---|---|
| SaaS (bulut) | Uygulama 360 Soft tarafından işletilen bulut ortamında çalışır; güncellemeler ve yedekleme hizmete dahildir | Hızlı başlamak isteyen, iç bilgi işlem kaynağı sınırlı şirketler |
| Özel bulut veya şirket içi (on-prem) | Uygulama sizin sunucunuza veya bulut hesabınıza kurulur; veri sizin altyapınızda kalır | Veri yerleşimi politikası sıkı olan bankalar, kamu iştirakleri, holdingler |
| Özel geliştirme projesi | ERP ve veri ambarınızın üzerine size özel modüller sabit kapsamla geliştirilir | Süreçleri standart şablonlara uymayan, karmaşık yapıdaki gruplar |
| Yönetilen hizmet | Yazılımın yanında veri toplama takibi, entegrasyon bakımı ve dönem sonu destek ekibi de sağlanır | Sürdürülebilirlik ekibi küçük olan, raporlama yükünü dışarıya vermek isteyen şirketler |
| Ek ekip desteği | Kendi projenize geliştirici, veri mühendisi veya analist eklenir; yönetim sizdedir | İç ekibi olan ama kapasitesi yetmeyen şirketler |
Çalışma biçimi olarak ekip uzaktan, yerinde veya hibrit çalışabilir. Gereksinim analizi ve tesis ziyaretlerinde yerinde çalışma, geliştirme ve bakımda uzaktan çalışma en verimli birleşimdir. Ek ekip veya yönetilen hizmet modelinde 360 Soft, 4857 sayılı İş Kanunu’nun 2. maddesi çerçevesinde hizmet alımı (gerektiğinde alt işverenlik) olarak çalışır; çalışanlar 360 Soft’un bordrosunda ve yönetiminde kalır. Kanunun 7. maddesindeki geçici iş ilişkisi İŞKUR’dan izinli özel istihdam bürolarınca kurulabilir; 360 Soft özel istihdam bürosu değildir ve bu modelde personel sağlamaz.
Kurulum süreci ve tipik süreler
| Adım | İçerik | Tipik süre |
|---|---|---|
| 1. Ön değerlendirme | Kapsam, raporlama sınırı, veri kaynakları ve ilk dönem hedefi | 1–2 hafta |
| 2. Veri haritası | Her gösterge için kaynak sistem, sahip, sıklık ve kanıt türünün belirlenmesi | 2–3 hafta |
| 3. Yapılandırma | Organizasyon yapısı, emisyon faktörleri, roller ve onay akışları | 2–4 hafta |
| 4. Entegrasyon | ERP, enerji ve fatura verilerinin otomatik aktarımı | 3–8 hafta (sistem sayısına göre) |
| 5. Geçmiş veri aktarımı ve paralel çalışma | Baz yıl ve önceki dönem verilerinin yüklenmesi, Excel ile karşılaştırma | 2–4 hafta |
| 6. Eğitim ve canlıya geçiş | Veri sahipleri, onaycılar ve yöneticiler için eğitim | 1–2 hafta |
| 7. Dönem sonu desteği | İlk raporlama döneminde kapanış, denetçi talepleri ve düzeltmeler | Rapor dönemi boyunca |
Süreler tipiktir; tesis sayısı, entegrasyon sayısı ve veri kalitesi takvimi en çok etkileyen üç değişkendir. Rapor tarihine geriye doğru plan yapmak gerekir: güvence denetçisinin çalışma süresi de hesaba katıldığında, yazılımın dönem sonundan birkaç ay önce canlıda olması sağlıklıdır.
SLA ve KPI örnekleri
| Gösterge | Tanım | Tipik hedef aralığı |
|---|---|---|
| Uygulama erişilebilirliği | SaaS ortamında aylık çalışma süresi | Sözleşmede belirlenir, genellikle %99 ve üzeri |
| Kritik hata yanıt süresi | Raporlamayı durduran hataya ilk müdahale | Mesai içinde birkaç saat |
| Veri toplama tamamlanma oranı | Dönem içinde zamanında gönderilen veri taleplerinin oranı | Her dönem için şirket tarafından belirlenir |
| Otomatik veri oranı | Manuel giriş yerine entegrasyonla gelen verinin payı | Fazlar ilerledikçe artması hedeflenir |
| Kanıt kapsaması | Kaynak belgesi eklenmiş değerlerin oranı | Önemli göstergelerde tam kapsama |
| Denetçi talep kapanış süresi | Güvence denetçisinin sorusuna kanıtla yanıt verme süresi | Gün değil saat mertebesi hedeflenir |
Buradaki hedefler örnektir; gerçekleşmiş sunulmaz. Sizin için geçerli değerler sözleşme aşamasında birlikte belirlenir ve ölçüm yöntemi yazılı olarak tanımlanır.
Fiyatlandırmayı belirleyen faktörler
Sayfada sabit fiyat paylaşmıyoruz, çünkü iki şirketin TSRS ihtiyacı nadiren aynıdır. Maliyeti belirleyen unsurlar ve kullanılan fiyatlama modelleri şunlardır:
| Faktör | Maliyete etkisi |
|---|---|
| Tüzel kişilik ve tesis sayısı | Yapılandırma, veri talebi ve onay akışı sayısını artırır |
| Entegrasyon sayısı ve türü | Hazır bağlantısı olan sistemler daha hızlı, özel veya eski sistemler daha fazla emek ister |
| Kapsam 3 derinliği | Tedarikçi portalı ve kategori bazlı hesaplar ek modül ve analiz gerektirir |
| Barındırma modeli | SaaS abonelik bazlı; şirket içi kurulum lisans, kurulum ve bakım kalemleri içerir |
| Özelleştirme düzeyi | Standart şablonların dışına çıkan ekranlar ve raporlar geliştirme süresi ekler |
| Destek ve yönetilen hizmet | Dönem sonu destek ekibi ve veri toplama takibi ayrı fiyatlanır |
- Adam/ay: Ek ekip veya uzun soluklu geliştirmede, ekipteki her uzmanın aylık tam zamanlı çalışma bedeli üzerinden hesaplanır.
- Saatlik: Küçük değişiklikler, danışmanlık ve dönem sonu destekte gerçekleşen saat üzerinden faturalanır.
- Sabit fiyat: Kapsamı yazılı olarak netleşmiş kurulum ve entegrasyon projelerinde kullanılır; kapsam değişikliği ayrı değerlendirilir.
- Sonuç bazlı (outcome-based): Belirli bir teslimatın (ör. bir entegrasyonun canlıya alınması) kabulüne bağlı ödeme; ölçüt sözleşmede tanımlanır.
- Abonelik: SaaS kullanımında kullanıcı, tüzel kişilik veya modül sayısına göre yıllık bedel.
Kendi ekibiniz, serbest çalışan veya dış kaynak
| Kriter | Şirket içi geliştirme | Serbest çalışan (freelancer) | Dış kaynak (360 Soft) |
|---|---|---|---|
| Başlangıç hızı | Ekip kurma ve işe alım süresi gerekir | Hızlı başlar ama tek kişiye bağlıdır | Hazır modüllerle hızlı başlar |
| Mevzuat ve standart bilgisi | Edinilmesi gerekir | Kişiye göre değişir | TSRS ve SKDM veri yapıları üzerinde birikim |
| Süreklilik | Personel değişiminde risk | Kişi ayrıldığında bilgi kaybı | Ekip ve dokümantasyonla devamlılık |
| Denetim izi | Sıfırdan tasarlanmalı | Çoğunlukla göz ardı edilir | Temel tasarımın parçası |
| Kontrol | Tam kontrol | Sınırlı | Sözleşme, SLA ve kaynak kod hakları ile tanımlı |
| Maliyet yapısı | Sabit personel maliyeti | Düşük başlar, belirsiz büyür | Model seçimine göre öngörülebilir |
Riskler ve önlemler
| Risk | Önlem |
|---|---|
| Veri sahiplerinin zamanında veri göndermemesi | Otomatik hatırlatma, yönetici görünürlüğü, eskalasyon kuralı |
| Emisyon faktörü hatası | Sürümlenmiş kütüphane, kaynak referansı, dört göz onayı |
| Konsolidasyon tutarsızlığı | Organizasyon sınırının finansal tablolarla aynı ana veriden beslenmesi |
| Denetimde kanıt bulunamaması | Değer bazında belge yükleme zorunluluğu, değişiklik geçmişi |
| Mevzuat değişikliği | Şablonların parametrik olması, düzenleme takibi ve sürüm notları |
| Tek kişiye bağımlılık | Dokümantasyon, yetki matrisinin yedekli kurulması, eğitim kayıtları |
Güvenlik, KVKK, gizlilik ve fikri mülkiyet
Sürdürülebilirlik verisi çoğu zaman kişisel veri içermez, ancak kullanıcı hesapları, çalışan sayıları, iş sağlığı ve güvenliği kayıtları ve tedarikçi irtibat bilgileri 6698 sayılı KVKK kapsamındadır; Avrupa’daki iştirakler söz konusuysa GDPR de gündeme gelir. Rol bazlı yetkilendirme, iki aşamalı doğrulama, iletimde ve saklamada şifreleme, erişim kayıtları ve düzenli yedekleme temel gereksinimlerdir. Veri işleme sözleşmesi ve gerekiyorsa yurt dışı aktarım değerlendirmesi kurulumdan önce yapılır.
Projeye başlamadan karşılıklı gizlilik sözleşmesi (NDA) imzalanır. Size özel geliştirilen kodun fikri mülkiyet ve kullanım hakları sözleşmede açıkça yazılır; standart ürün bileşenleri ile size özel geliştirmeler ayrı tanımlanır. Şirket içi kurulumda kaynak kodun teslimi veya emanet (escrow) seçeneği de konuşulabilir. Uygulamanın dışarıya açık bölümleri için sızma testi yapılması önerilir.
TSRS yazılımı seçerken kontrol listesi
- Her açıklanan değer, kaynak belgesine ve onaylayan kişiye kadar tek tıkla izlenebiliyor mu?
- Emisyon faktörleri kaynak ve yıl bilgisiyle sürümleniyor mu; geçmiş dönem yeniden hesaplaması kayıt altına alınıyor mu?
- Konsolidasyon yaklaşımı ve raporlama sınırı finansal tablolarla aynı ana veriden besleniyor mu?
- Kapsam 2 için konum bazlı ve piyasa bazlı hesap birlikte yapılabiliyor mu?
- Kapsam 3 için tedarikçi verisi, ortalama veri ve harcama bazlı yöntemler ayrı veri kalitesi işaretiyle tutulabiliyor mu?
- ERP ve enerji sistemlerinizle entegrasyon için hazır bağlantı veya açık API var mı?
- SaaS ve şirket içi kurulum seçenekleri, veri yerleşimi politikanıza uyuyor mu?
- Güvence denetçisine salt okunur erişim verilebiliyor mu?
- SKDM, banka anketleri veya müşteri talepleri gibi diğer raporlamalarda aynı veri yeniden kullanılabiliyor mu?
- Sözleşmede SLA, veri iadesi, kaynak kod hakları ve çıkış planı yazılı mı?
Temsili senaryo
Temsili senaryodur. Beş üretim tesisi ve iki yurt dışı satış şirketi olan bir sanayi grubu, ilk TSRS dönemine Excel ile hazırlanmaya başlıyor. Ön değerlendirmede 140’tan fazla göstergenin dokuz farklı kişi tarafından e-postayla toplandığı görülüyor. Kurulumun ilk fazında organizasyon sınırı finansal konsolidasyonla eşleştiriliyor, elektrik ve doğalgaz faturaları muhasebe sisteminden otomatik çekiliyor ve her tesise veri talebi takvimi tanımlanıyor. İkinci fazda en büyük on tedarikçi için Kapsam 3 anketi portal üzerinden yürütülüyor ve aynı emisyon verisi AB’ye ihracat yapılan ürünler için SKDM raporlamasında kullanılıyor. Bu senaryo bir müşteri projesini değil, tipik bir ihtiyacın nasıl ele alınabileceğini anlatır.
Sık sorulan sorular
TSRS ile IFRS S1 ve S2 arasındaki ilişki nedir?
TSRS 1 ve TSRS 2, ISSB tarafından yayımlanan IFRS S1 ve IFRS S2 ile uyumlu olarak KGK tarafından Türkiye’de yayımlanan standartlardır. Yapı ve temel gereklilikler aynıdır; kapsam, yürürlük ve geçiş hükümleri KGK kararlarıyla belirlenir.
Kapsamda olup olmadığımızı nasıl anlarız?
KGK’nın yayımladığı kapsam kararlarına ve eşiklere bakılır; nihai değerlendirme için mali müşaviriniz veya danışmanınızla görüşün.
Rapor metnini de yazıyor musunuz?
Biz veri ve yazılım tarafını üstleniyoruz; rapor içeriği danışmanınız ve denetçinizle hazırlanır.
SKDM ile aynı sistem kullanılabilir mi?
Evet, emisyon verisi SKDM raporlamasıyla ortak kullanılır. Aynı faaliyet verisi hem kurumsal TSRS açıklamasında hem ürün bazlı SKDM beyanında tutarlı biçimde kullanılabilir.
Kapsam 3 emisyonlarını nasıl hesaplıyorsunuz?
Kategori bazında tedarikçiye özgü veri, ortalama veri ve harcama bazlı yöntemler desteklenir. Her değer hangi yöntemle hesaplandığı ve veri kalitesi işaretiyle birlikte saklanır.
Hangi emisyon faktörlerini kullanıyorsunuz?
Uluslararası kabul görmüş kamuya açık faktör kaynakları ile şirketinize özgü faktörler kütüphaneye eklenebilir. Hangi kaynağın kullanılacağına danışmanınız ve denetçinizle birlikte karar verilir; her faktör kaynak ve yıl bilgisiyle sürümlenir.
Yazılım güvence denetimini kendisi sağlar mı?
Hayır. Sürdürülebilirlik güvence denetimi yetkili bağımsız denetçiler tarafından yapılır. Yazılım, denetçinin ihtiyaç duyduğu kanıtı ve değişiklik geçmişini hazır tutarak süreci hızlandırır.
SaaS mı, şirket içi kurulum mu seçmeliyiz?
Veri yerleşimi politikanız ve bilgi işlem kapasiteniz belirleyicidir. Hızlı başlamak için SaaS, veri sizin altyapınızda kalsın istiyorsanız özel bulut veya şirket içi kurulum uygundur.
Kurulum ne kadar sürer?
Tesis ve entegrasyon sayısına bağlıdır. Tipik olarak ilk faz birkaç ayda canlıya alınır; ayrıntılı takvim ön değerlendirmeden sonra yazılı olarak paylaşılır.
Excel dosyalarımızı aktarabilir miyiz?
Evet. Geçmiş dönem ve baz yıl verileri şablonlarla aktarılır, ilk dönemde Excel ile paralel çalışılarak sonuçlar karşılaştırılır.
ERP sistemimizle entegre olur mu?
Yaygın ERP ve muhasebe sistemleriyle API, veritabanı görünümü veya dosya aktarımı yoluyla entegrasyon kurulabilir. Yöntem, sisteminizin sunduğu erişim seçeneklerine göre belirlenir.
Fiyatlandırma nasıl yapılıyor?
Tesis ve entegrasyon sayısı, modül kapsamı ve barındırma modeline göre abonelik, sabit fiyat, adam/ay veya saatlik model önerilir. Yazılı teklif ön değerlendirmeden sonra hazırlanır.
İlgili sayfalar
- SKDM emisyon raporlama yazılımı
- Dijital ürün pasaportu yazılımı
- Veri mühendisi kiralama
- Outsourcing hizmetleri
- Staff augmentation
- Sızma testi hizmeti
TSRS veri altyapınızı birlikte planlayalım
Raporlama sınırınızı, veri kaynaklarınızı ve ilk dönem hedefinizi kısaca paylaşın; size uygun teslim modelini, tipik takvimi ve yazılı teklifi hazırlayalım. Telefon: +90 850 335 10 87 · E-posta: info@360-soft.com · İletişim sayfası. 360 Soft Marketing Yazılım ve Danışmanlık Ltd. Şti., Nidakule Ataşehir, İstanbul.
Projenizi konuşalım İhtiyacınızı kısaca yazın; kapsam, takvim ve yazılı teklifi paylaşalım. Teklif alın · WhatsApp · +90 850 335 10 87
Bu sayfa 360 Soft Yetkili Temsilcisi Yasir Bünyamin İncedere tarafından hazırlanmıştır. Son güncelleme: Kasım 2026.