Yazılım Bakım Outsourcing | Uygulama Yönetim Hizmeti (AMS)

Son güncelleme: 8 Kasım 2026

Yazılım bakım ve destek (AMS, Application Management Services) outsourcing, canlıda çalışan iş uygulamalarınızın günlük işletimini, hata çözümünü, küçük geliştirmelerini ve sürekli iyileştirmesini sözleşmeyle tanımlı hizmet seviyeleri altında bir dış ekibe devretmenizdir. Yazılımın teslim edildiği gün, toplam yaşam döngüsü maliyetinin başlangıcıdır; asıl yük, yıllarca süren bakım, uyum güncellemeleri, kullanıcı talepleri ve kesintisiz çalışma beklentisidir. Bu sayfada AMS kapsamını, ITIL 4 pratiklerine dayalı olay (incident), problem ve değişiklik (change) yönetimini, destek seviyelerini, SLA tablolarını, fiyatlandırma modellerini ve doğru sağlayıcıyı seçmek için kontrol listesini bulacaksınız. Projeniz kritik bir noktadaysa önce yazılım proje kurtarma sayfamıza bakmanızı öneririz.

Yazılım Bakım ve Destek (AMS) Outsourcing

AMS nedir, kimler ihtiyaç duyar?

AMS, “yazılımı yazdık, şimdi kim yaşatacak?” sorusunun yanıtıdır. Özel yazılımlar, kurumsal portallar, entegrasyon katmanları, mikroservis tabanlı arka uçlar ve iş akışı uygulamaları teslimden sonra da sürekli bakım ister: kütüphane ve çatı (framework) sürümleri eskir, güvenlik açıkları yayımlanır, iş kuralları değişir, entegre olunan üçüncü taraf API’ler sürüm atlar ve kullanıcılar her ay yeni talepler iletir.

Tipik ihtiyaç sahipleri

Projeyi teslim alan ancak geliştirici ekibi dağılmış şirketler: Uygulamayı geliştiren ajans veya yüklenici artık destek vermiyor; kod tabanını bilen kimse kalmamış.
Kurumsal BT birimleri: İç ekip yeni projelere odaklanmak istiyor; yaşlanan uygulamaların bakımı bu kapasiteyi tüketiyor.
Çok sayıda iç uygulaması olan holdingler: Farklı teknolojilerle yazılmış onlarca uygulama için tek bir destek merkezi ve ortak SLA ihtiyacı.
Kritik iş süreçlerini yazılıma bağlamış KOBİ’ler: Sipariş, üretim planlama veya bayi portalı durduğunda iş duruyor; ancak tam zamanlı yazılım ekibi tutmak ekonomik değil.
Regülasyona tabi sektörler: Değişikliklerin kayıt altına alınması, onay süreçleri ve denetim izi gereken finans, sağlık, enerji gibi alanlar.

AMS’e geçişi tetikleyen tipik sorunlar

Aynı hataların tekrar tekrar açılması, kök neden analizinin yapılmaması
Destek taleplerinin e-posta ve telefonla gelmesi, önceliklendirme ve takip olmaması
Bilginin bir veya iki kişinin kafasında olması (“bus factor” riski)
Güvenlik yamalarının ve bağımlılık güncellemelerinin aylarca ertelenmesi
Değişikliklerin test edilmeden canlıya alınması ve geri alma planı olmaması
Dokümantasyonun eksik veya güncel olmaması

Kapsam: ITIL tabanlı AMS hizmet kalemleri

AMS kapsamını tanımlarken ITIL 4’teki hizmet yönetimi pratiklerini ortak dil olarak kullanırız. ITIL bir sertifika zorunluluğu değil, olgunlaşmış bir iyi uygulama çerçevesidir; amacı kimin neyi, hangi sürede ve hangi onayla yapacağını netleştirmektir.

ITIL pratiği	AMS’teki karşılığı	Tipik çıktılar
Olay yönetimi (Incident Management)	Hizmet kesintisini veya bozulmasını en kısa sürede gidermek; geçici çözüm (workaround) uygulamak	Önceliklendirilmiş kayıtlar, çözüm notları, SLA raporu
Problem yönetimi (Problem Management)	Tekrarlayan olayların kök nedenini bulmak ve kalıcı çözüm üretmek; bilinen hatalar (known error) veritabanı	Kök neden analizi (RCA) raporu, kalıcı düzeltme önerisi
Değişiklik yönetimi (Change Enablement)	Her değişikliğin risk değerlendirmesi, onayı, test edilmesi ve geri alma planıyla canlıya alınması; standart, normal ve acil değişiklik ayrımı	Değişiklik kaydı, CAB kararları, sürüm notları
Servis talebi yönetimi (Service Request)	Rapor, yetki, parametre değişikliği, veri düzeltme gibi standart talepler	Talep kataloğu, karşılama süreleri
Sürüm yönetimi (Release Management)	Değişikliklerin paketlenmesi, ortamlar arası geçiş, sürüm takvimi	Sürüm planı, dağıtım kayıtları
İzleme ve olay (Monitoring and Event Management)	Uygulama, log ve performans izleme; alarm eşikleri	Gösterge panoları, alarm kuralları
Bilgi yönetimi (Knowledge Management)	Çözüm makaleleri, işletim el kitabı (runbook), mimari dokümantasyon	Bilgi bankası, runbook’lar
Sürekli iyileştirme (Continual Improvement)	Trend analizi, teknik borç azaltma, otomasyon fırsatları	Aylık iyileştirme planı

Destek seviyeleri

Seviye	Kim	Ne yapar
L1	Servis masası / ilk temas	Talebi kaydeder, sınıflandırır, bilinen çözümleri uygular, kullanıcıyı bilgilendirir
L2	Uygulama destek uzmanı	Konfigürasyon, veri ve iş kuralı kaynaklı sorunları analiz eder, log inceler, geçici çözüm uygular
L3	Geliştirici / mimar	Kod düzeyinde hata düzeltme, performans sorunları, kök neden analizi, küçük geliştirmeler
L4 (üçüncü taraf)	Ürün üreticisi veya altyapı sağlayıcısı	Lisanslı ürün, bulut servis veya donanım kaynaklı sorunlar; AMS ekibi koordine eder

Düzeltici, uyarlayıcı, mükemmelleştirici ve önleyici bakım

ISO/IEC 14764 yazılım bakım standardı bakım faaliyetlerini dört türe ayırır ve AMS sözleşmelerinde bu ayrım bütçe planlaması için kullanışlıdır:

Düzeltici bakım: Bildirilen hataların giderilmesi.
Uyarlayıcı bakım: Yeni işletim sistemi, veritabanı, tarayıcı veya üçüncü taraf API sürümlerine uyum; mevzuat değişikliklerinin uygulanması.
Mükemmelleştirici bakım: Performans iyileştirme, kullanıcı deneyimi ve küçük fonksiyonel geliştirmeler.
Önleyici bakım: Teknik borcun azaltılması, bağımlılık güncellemeleri, kod kalitesi iyileştirmeleri, olası arızaların önceden giderilmesi.

Desteklenen teknolojiler

Katman	Örnek teknolojiler
Arka uç	Java/Spring,.NET, Node.js, PHP/Laravel, Python/Django
Ön yüz	React, Angular, Vue, sunucu tarafı şablon motorları
Veritabanı	PostgreSQL, MS SQL Server, Oracle, MySQL, MongoDB, Redis
Entegrasyon	REST/SOAP servisleri, mesaj kuyrukları (RabbitMQ, Kafka), ETL süreçleri
Altyapı	Linux/Windows sunucular, Docker, Kubernetes, AWS, Azure, Google Cloud
İzleme	Prometheus, Grafana, ELK/OpenSearch, uygulama performans izleme (APM) araçları

Altyapı tarafındaki işletim için DevOps ve bulut operasyonu ve ağ izleme için NOC outsourcing hizmetleriyle AMS birlikte kurgulanabilir.

Standartlar ve düzenleyici çerçeve

ITIL 4: Hizmet yönetimi için iyi uygulama çerçevesi; olay, problem, değişiklik ve servis talebi süreçlerinin tasarımında referans alınır.
ISO/IEC 20000-1: BT hizmet yönetim sistemi standardı. Kurumunuz bu standarda sertifikalıysa AMS süreçlerinin sizin hizmet yönetim sisteminizle uyumlu çalışması gerekir.
ISO/IEC 27001: Bilgi güvenliği yönetim sistemi. Erişim kontrolü, değişiklik yönetimi ve tedarikçi ilişkileri kontrolleri AMS sözleşmelerini doğrudan etkiler.
ISO/IEC 14764: Yazılım bakım süreçleri ve bakım türleri.
Sektörel düzenlemeler: Bankacılık, ödeme hizmetleri, sigorta, enerji ve sağlık gibi alanlarda bilgi sistemleri, dış hizmet alımı ve iş sürekliliğine ilişkin ek yükümlülükler bulunabilir. Bu yükümlülükler kurumun tabi olduğu düzenleyiciye göre değiştiği için sözleşme öncesi uyum gereksinimlerini birlikte çıkarırız.

Teslim modelleri

Çalışma lokasyonu

Model	Nasıl çalışır	Ne zaman uygun
Uzaktan	Destek ekibi güvenli uzaktan erişimle, sizin ticket sisteminiz veya bizim servis masamız üzerinden çalışır	Bulut veya uzaktan erişilebilir sistemler; 7/24 vardiyalı destek
Yerinde	Ekip veya bir kısmı lokasyonunuzda çalışır	Kapalı ağ, fiziksel donanım, yoğun kullanıcı etkileşimi
Hibrit	Yerinde koordinatör veya L1, uzaktan L2/L3	Kullanıcı yakınlığı ile maliyet verimliliğini dengelemek isteyen kurumlar

Sözleşme modeli

Model	Tanım	Uygun olduğu durum
Managed service (yönetilen AMS)	Uygulama portföyü için SLA tabanlı, sonuç sorumluluğu 360 Soft’ta olan hizmet	Çok sayıda uygulama, öngörülebilir bütçe ihtiyacı
Dedicated team	Uygulamanıza ayrılmış sabit destek ve geliştirme ekibi	Yoğun değişiklik talebi, derin ürün bilgisi gerektiren sistemler
Staff augmentation	İç ekibinize L2/L3 uzman takviyesi; bkz. staff augmentation	Geçici kapasite açığı, belirli teknoloji uzmanlığı
Proje bazlı	Teknik borç temizliği, sürüm yükseltme, stabilizasyon projesi	AMS öncesi uygulamayı desteklenebilir hale getirmek

Hukuki not: Personel sağlanan modellerde yapı, hizmet alımı ve 4857 sayılı İş Kanunu’nun 2. maddesi kapsamındaki alt işverenlik kurallarına göre kurulur; iş 360 Soft’un yönetiminde ve sözleşmedeki çıktılara göre yürütülür. Personelin doğrudan sizin emir ve talimatınızla çalıştığı geçici iş ilişkisi (md. 7) İŞKUR izinli özel istihdam bürosu üzerinden kurulabilir; 360 Soft özel istihdam bürosu değildir.

Geçiş süreci: devralmadan kararlı işletime

Adım	İçerik	Tipik süre
1. Keşif ve envanter	Uygulama listesi, mimari, kod depoları, ortamlar, talep geçmişi, kritik iş süreçleri	1–3 hafta
2. Hizmet tasarımı	Kapsam, destek seviyeleri, öncelik matrisi, SLA, eskalasyon ve raporlama	1–2 hafta
3. Bilgi transferi (KT)	Ekip veya tedarikçiden gölge çalışma (shadowing), ters gölge (reverse shadowing), dokümantasyon	2–6 hafta
4. Kararlılık dönemi (hypercare)	SLA’ların izlendiği ancak cezai şartların uygulanmadığı ilk dönem; runbook’ların tamamlanması	4–8 hafta
5. Kararlı işletim	Tam SLA, aylık hizmet raporu, problem yönetimi ve iyileştirme planı	Sözleşme dönemi
6. Dönüşüm	Teknik borç azaltma, otomasyon, izleme iyileştirmeleri, modernizasyon önerileri	Sürekli

Bilgi transferi süresini en çok etkileyen etken, dokümantasyonun durumu ve önceki ekibin erişilebilirliğidir. Önceki ekibe ulaşılamıyorsa kod analizi ve tersine mühendislikle süre uzayabilir.

SLA ve KPI tabloları

AMS sözleşmesinin kalbi öncelik matrisidir. Öncelik, etki (kaç kullanıcı veya hangi iş süreci etkileniyor) ve aciliyetin (iş ne kadar süre bekleyebilir) birleşimiyle belirlenir. Aşağıdaki değerler tipik bir başlangıç önerisidir; nihai değerler iş kritikliğinize ve destek saatlerinize göre birlikte belirlenir.

Öncelik	Örnek	Tipik yanıt süresi	Tipik çözüm/geçici çözüm hedefi
P1 – Kritik	Uygulama tamamen erişilemez, ödeme veya sipariş akışı durmuş	15–30 dakika	4 saat içinde geçici çözüm
P2 – Yüksek	Önemli bir fonksiyon çalışmıyor, geçici çözüm yok	1 saat	1 iş günü
P3 – Orta	Fonksiyon kısmen çalışıyor, geçici çözüm	4 iş saati	3–5 iş günü
P4 – Düşük	Kozmetik hata, bilgi talebi	1 iş günü	Planlanan sürümde

KPI	Ne ölçer
SLA uyum oranı	Yanıt ve çözüm hedeflerinin karşılandığı kayıtların oranı
MTTR (ortalama onarım süresi)	Olayların ortalama çözüm süresi
Tekrar açılan kayıt oranı	Çözüldü denip yeniden açılan kayıtlar; çözüm kalitesinin göstergesi
Kayıt birikimi (backlog) yaşı	Açık kayıtların bekleme süresi dağılımı
Problem kapatma oranı	Kök nedeni bulunup kalıcı çözüm üretilen problemler
Başarısız değişiklik oranı	Canlıya alındıktan sonra geri alınan veya olaya yol açan değişiklikler
İlk temasta çözüm oranı	L1 seviyesinde çözülen talepler
Kullanıcı memnuniyeti (CSAT)	Kapanan kayıtlar sonrası kısa anket

Fiyatlandırma faktörleri

AMS fiyatlandırmasında dört model kullanılır: adam/ay (sabit ekip kapasitesi), saatlik (gerçekleşen efor; düşük hacimli işler için), sabit fiyat (uygulama veya kayıt hacmi bandı başına aylık sabit ücret) ve outcome-based (ücretin bir kısmının SLA uyumu, MTTR veya kullanıcı memnuniyeti gibi hedeflere bağlanması). Pek çok sözleşmede aylık sabit bir “çalışır tutma” bedeli ile değişiklik talepleri için bir saat havuzu birlikte kullanılır.

Faktör	Etkisi
Uygulama sayısı ve karmaşıklığı	Entegrasyon sayısı, kod büyüklüğü, teknoloji çeşitliliği
Destek saatleri	İş saatleri (ör. 5×9) ile 7/24 arasında belirgin fark; vardiya ve nöbet ihtiyacı
Kayıt hacmi	Aylık olay ve servis talebi sayısı ve dağılımı
SLA hedefleri	Daha kısa yanıt/çözüm süreleri daha fazla hazır kapasite gerektirir
Kod ve dokümantasyon kalitesi	Teknik borç arttıkça her değişikliğin eforu artar
Geliştirme saat havuzu	Aylık küçük geliştirme ihtiyacının büyüklüğü
Uyum gereksinimleri	Denetim raporlaması, değişiklik onay katmanları, ortam ayrımı

In-house, freelancer veya AMS outsourcing?

Kriter	In-house ekip	Freelancer	AMS outsourcing
7/24 kapsama	Vardiya için çok sayıda kişi gerekir	Pratikte mümkün değil	Nöbet ve vardiya düzeniyle sağlanabilir
Kişiye bağımlılık	Orta-yüksek	Çok yüksek	Düşük; ekip ve bilgi bankası
Süreç olgunluğu	Kuruma bağlı	Genellikle yok	ITIL tabanlı süreçler hazır
Maliyet yapısı	Sabit personel maliyeti	Değişken ama öngörülemez	Sözleşmeyle öngörülebilir
Teknoloji genişliği	Ekibin bildiğiyle sınırlı	Kişinin uzmanlığıyla sınırlı	Gerektiğinde farklı uzmanlıklara erişim
Ürün bilgisi	En yüksek	Değişken	Bilgi transferi ve dokümantasyonla birikir

Yazılım Bakım ve Destek (AMS) Outsourcing — konu başlıkları

Riskler ve önlemler

Risk	Önlem
Bilgi transferinin eksik kalması	Yapılandırılmış KT planı, gölge çalışma, kabul kriterli devir kontrol listesi
SLA’ların kağıt üzerinde kalması	Ticket sistemi verisinden otomatik SLA raporu, aylık hizmet gözden geçirme toplantısı
Plansız değişikliklerin kesintiye yol açması	Değişiklik yönetimi, test ortamı, geri alma planı, değişiklik takvimi
Teknik borcun büyümesi	Bütçenin bir kısmının önleyici bakıma ayrılması, çeyreklik teknik borç gözden geçirmesi
Güvenlik açıklarının gecikmesi	Bağımlılık taraması, yama takvimi; gerekirse zafiyet yönetimi ile entegrasyon
Sağlayıcıya kilitlenme	Kod, dokümantasyon ve runbook’ların size ait olması; sözleşmede çıkış planı

Güvenlik, KVKK/GDPR, NDA ve fikri mülkiyet

NDA: Görüşmelerin başında karşılıklı gizlilik sözleşmesi; ekip üyelerinin bireysel gizlilik taahhütleri.
KVKK ve GDPR: AMS ekibi canlı sistemlere eriştiği için çoğu durumda veri işleyen konumundadır. Veri işleme şartları, alt işleyenler, yurt dışı aktarım durumu ve ihlal bildirim süreçleri sözleşmede yazılır. Uyum tarafındaki operasyonel destek için KVKK uyum operasyonu sayfamıza bakabilirsiniz.
Ayrıcalıklı erişim: Üretim erişimi kişiye özel hesaplar, MFA, mümkünse ayrıcalıklı erişim yönetimi (PAM) aracı ve oturum kaydı ile verilir; “ortak admin şifresi” kullanılmaz.
Değişiklik izlenebilirliği: Her değişiklik bir kayda, bir kod incelemesine ve bir onaya bağlanır; denetimde geriye dönük izlenebilir.
Fikri mülkiyet: Bakım kapsamında yazılan kodun, dokümantasyonun ve runbook’ların mülkiyeti size aittir; kod sizin depolarınızda tutulur.

Temsili senaryo: tedarikçisi değişen bir bayi portalı

Temsili senaryodur. Bir üretim firmasının bayi sipariş portalı, birkaç yıl önce bir ajans tarafından.NET ve SQL Server ile geliştirilmiş, ERP ile gece çalışan bir entegrasyon servisiyle bağlı. Ajans artık destek vermiyor; sipariş aktarımı haftada birkaç kez takılıyor ve sorunlar IT müdürünün kişisel çabasıyla çözülüyor. AMS kapsamında önce kod ve veritabanı envanteri çıkarılır, entegrasyon servisinin logları merkezi bir log platformuna yönlendirilir ve aktarım hataları için alarm kurulur. Tekrarlayan aktarım hataları problem kaydı olarak ele alınır, kök neden analiziyle kalıcı düzeltme planlanır. Tüm değişiklikler test ortamında doğrulanıp değişiklik takvimine göre canlıya alınır. Sorunlar bayi aramadan önce fark edilebilir hale gelir ve IT müdürü yangın söndürmek yerine iyileştirme planına odaklanabilir.

Sağlayıcı seçim kontrol listesi

Öncelik matrisi, yanıt ve çözüm süreleri yazılı ve ölçülebilir mi?
SLA raporu ticket sistemi verisinden mi üretiliyor, yoksa elle mi hazırlanıyor?
Olay ile problem yönetimini ayırıyor mu; kök neden analizi raporu örneği paylaşabiliyor mu?
Değişiklik yönetimi süreci (onay, test, geri alma) tanımlı mı?
Bilgi transferi planı ve kabul kriterleri net mi?
7/24 destek gerekiyorsa nöbet düzeni ve eskalasyon zinciri nasıl?
Teknoloji yığınınızda gerçek deneyimi olan L3 geliştiriciler var mı?
Erişim yönetimi ve KVKK veri işleme şartları sözleşmede mi?
Kod, dokümantasyon ve runbook mülkiyeti size mi ait?
Çıkış planı ve devir yükümlülükleri tanımlı mı?
Hukuki model hizmet alımı / alt işverenlik kurallarına uygun mu?

Sık sorulan sorular

AMS ile klasik “bakım anlaşması” arasındaki fark nedir?

Klasik bakım anlaşması genellikle sadece hata düzeltmeyi ve belirli bir saat havuzunu kapsar. AMS ise olay, problem, değişiklik ve servis talebi yönetimini, izlemeyi, dokümantasyonu ve sürekli iyileştirmeyi ölçülebilir SLA’larla bir hizmet olarak sunar.

Başka bir firmanın yazdığı yazılımı devralabilir misiniz?

Evet. Kod deposuna, ortamlara ve mümkünse önceki ekibe erişimle bilgi transferi yapılır. Dokümantasyon yoksa kod analizi ve tersine mühendislikle sistem haritası çıkarılır; bu durumda bilgi transferi süresi uzayabilir.

Olay ile problem arasındaki fark nedir?

Olay, kullanıcıyı etkileyen bir kesinti veya bozulmadır ve amaç hizmeti en kısa sürede geri getirmektir. Problem ise bir veya birden fazla olayın altında yatan nedendir; amaç kök nedeni bulup tekrarı önlemektir.

Acil değişiklikler nasıl yönetilir?

Acil değişiklikler hızlandırılmış bir onay akışıyla uygulanır, ancak yine kayıt altına alınır ve uygulama sonrası gözden geçirilir. Standart değişiklikler önceden onaylı prosedürle, normal değişiklikler ise risk değerlendirmesi ve onayla yapılır.

7/24 destek veriyor musunuz?

İhtiyaca göre iş saatleri, uzatılmış saatler veya 7/24 nöbet modeli kurgulanır. 7/24 destek genellikle P1 ve P2 öncelikli olaylar için tanımlanır; bu yapı maliyeti dengeler.

Hangi ticket sistemini kullanıyorsunuz?

Sisteminiz varsa (Jira Service Management, ServiceNow, Freshservice vb.) onu kullanırız. Yoksa size ait bir servis masası kurulumunu öneririz; veri ve geçmiş sizde kalır.

Küçük geliştirmeler AMS kapsamında mı?

Genellikle evet. Aylık bir geliştirme saat havuzu tanımlanır; büyük geliştirmeler ise ayrı iş emri veya proje olarak planlanır.

SLA karşılanmazsa ne olur?

Sözleşmede hizmet kredisi veya fiyat indirimi gibi mekanizmalar tanımlanabilir. Daha önemlisi, her SLA ihlali için kök neden ve düzeltici eylem planı raporlanır.

Bilgi transferi ne kadar sürer?

Tipik olarak 2–6 hafta sürer. Süreyi uygulama sayısı, karmaşıklık, dokümantasyon durumu ve önceki ekibin erişilebilirliği belirler.

Uygulamamızı modernize etmeden AMS alabilir miyiz?

Evet. AMS haliyle uygulamayı işletir; zamanla teknik borç ve modernizasyon ihtiyaçları önceliklendirilmiş bir yol haritası olarak sunulur.

Fiyatlandırma nasıl belirleniyor?

Adam/ay, saatlik, sabit aylık ücret veya kısmen sonuç bazlı modeller kullanılır. Uygulama sayısı, destek saatleri, kayıt hacmi, SLA hedefleri ve geliştirme saat havuzu fiyatı belirler.

Bu hizmet hangi sözleşme modeliyle yürür?

Dış kaynak (hizmet alımı) modelinde iş, 360 Soft’un ekibi ve yönetimiyle, sözleşmede tanımlanan çıktı ve hizmet seviyelerine göre yürütülür; yapı İş Kanunu’ndaki alt işverenlik kurallarına göre kurulur. Personelin doğrudan sizin emir ve talimatınızla çalıştığı geçici iş ilişkisi ise İŞKUR izinli özel istihdam bürosu üzerinden yapılmalıdır.

İlgili sayfalar

İletişim

Yazılım bakım ve destek (AMS) için kapsamınızı birlikte netleştirelim. +90 850 335 10 87 numarasından arayabilir, info@360-soft.com adresine yazabilir veya iletişim sayfamızdan bize ulaşabilirsiniz. 360 Soft Marketing Yazılım ve Danışmanlık Ltd. Şti., Nidakule Ataşehir, İstanbul.

Bu işi bize devredin Kapsamı ve hacmi yazın; kurulum planını 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.

İlgili hizmetler

Tüm hizmetler: Outsourcing Hizmetleri