Softwarewartung und AMS aus der Türkei

Zuletzt aktualisiert: 11. November 2026

Application Management Services (AMS) bedeuten, dass ein externes Team den Betrieb, Support und die Weiterentwicklung Ihrer Geschäftsanwendungen nach ITIL-Prozessen übernimmt – mit klaren Prioritäten, SLA, Monitoring und monatlichem Reporting. 360 Soft stellt Softwareentwickler, Support-Ingenieure, DevOps- und Service-Manager aus der Türkei bereit: remote, vor Ort oder hybrid, vom einzelnen Spezialisten bis zu Teams mit über 200 Personen, auf Wunsch mit 7/24-Schichten und einem typischen Start innerhalb von 1–2 Wochen. Individualsoftware, Kundenportale, interne Tools und Schnittstellen laufen oft jahrelang – aber das ursprüngliche Projektteam ist längst weitergezogen. AMS sorgt dafür, dass diese Anwendungen stabil, sicher und weiterentwickelbar bleiben, ohne dass Ihr Kernteam ständig von Tickets unterbrochen wird.

Was ist AMS und wer braucht es

Typische Auftraggeber

Unternehmen mit Individualsoftware, deren Entwicklungsdienstleister gewechselt hat oder nicht mehr verfügbar ist.
IT-Abteilungen, die ihr Team auf neue Projekte konzentrieren und den Betrieb abgeben wollen.
Softwarehersteller und SaaS-Anbieter, die L2/L3-Support und Wartung skalieren müssen.
Konzerne und Mittelständler mit vielen Fachanwendungen, die einen einheitlichen Serviceprozess brauchen.

Typische Auslöser für den Wechsel zu AMS

Fehler werden behoben, kehren aber immer wieder zurück.
Wissen über das System liegt bei einer oder zwei Personen.
Es gibt keine definierten Prioritäten oder Reaktionszeiten.
Sicherheitsupdates von Frameworks und Bibliotheken werden aufgeschoben.
Änderungen gehen ohne Test in Produktion und verursachen neue Störungen.
Der Ticket-Backlog wächst schneller, als er abgearbeitet wird.

Leistungsumfang: AMS-Leistungen auf Basis von ITIL

ITIL-Praxis	Umsetzung im AMS	Typische Ergebnisse
Incident Management	Annahme, Klassifizierung und Behebung von Störungen nach Priorität	Wiederhergestellter Service, Ticket-Historie
Problem Management	Ursachenanalyse wiederkehrender Störungen	Root-Cause-Analysen, dauerhafte Fixes, Known-Error-Datenbank
Change Enablement	Bewertung, Test und Freigabe von Änderungen	Change-Records, Freigabeprotokolle
Service Request Management	Standardanfragen wie Benutzer, Daten, Konfiguration	Erledigte Anfragen nach Katalog
Release Management	Planung und Durchführung von Releases	Release-Kalender, Release-Notes
Monitoring und Event Management	Überwachung von Anwendungen, Logs und Schnittstellen	Alarme, Dashboards, proaktive Tickets
Wissensmanagement	Dokumentation, Runbooks, Wissensdatenbank	Aktuelle Betriebsdokumentation

Support-Level

Level	Wer	Aufgaben
L1	Service Desk	Annahme, Erfassung, Standardlösungen, Weiterleitung
L2	Anwendungs-Support-Ingenieure	Analyse, Konfiguration, Datenkorrekturen, bekannte Fehler
L3	Entwickler	Code-Fehler, Fixes, kleine Weiterentwicklungen, Performance
L4 (Dritte)	Hersteller oder Plattformanbieter	Produktfehler in Fremdsoftware – wir steuern die Eskalation

Korrektive, adaptive, perfektionierende und präventive Wartung

Korrektiv: Behebung gemeldeter Fehler und Störungen.
Adaptiv: Anpassung an neue Betriebssysteme, Browser, Schnittstellen oder gesetzliche Vorgaben.
Perfektionierend: Verbesserungen von Bedienbarkeit, Performance und kleine neue Funktionen.
Präventiv: Updates von Frameworks und Bibliotheken, Abbau technischer Schulden, Sicherheits-Patches.

Unterstützte Technologien

Ebene	Beispieltechnologien
Backend	Java/Spring,.NET, Node.js, Python, PHP/Laravel, Go
Frontend	React, Angular, Vue, klassische Server-Rendering-Anwendungen
Datenbank	PostgreSQL, MS SQL Server, Oracle, MySQL, MongoDB
Integration	REST/SOAP, Message Queues (Kafka, RabbitMQ), ESB, ETL
Infrastruktur	Linux/Windows-Server, Docker, Kubernetes, AWS, Azure, GCP
Monitoring	Prometheus, Grafana, ELK/OpenSearch, Sentry, Application-Performance-Tools

Standards und regulatorischer Rahmen

Methodisch arbeiten wir nach ITIL 4; für Informationssicherheit orientieren wir uns an ISO/IEC 27001-Prinzipien und für sichere Entwicklung an OWASP. Das Team arbeitet aus der Türkei und berücksichtigt dort das Datenschutzgesetz KVKK sowie – bei Finanz- oder Behördenanwendungen – die jeweiligen türkischen Branchenvorgaben. Für Ihre Organisation in der DACH-Region gelten DSGVO und je nach Branche weitere Anforderungen, etwa DORA und BAIT/VAIT im Finanzsektor oder NIS2 für wichtige Einrichtungen. Wir unterstützen die technische Umsetzung und Dokumentation; die regulatorische Verantwortung bleibt beim Auftraggeber, und maßgeblich sind die lokalen Vorschriften im Land des Auftraggebers.

Liefermodelle

Arbeitsort

Modell	Arbeitsweise	Geeignet für
Remote	Zugriff über VPN, Ticketsystem und Monitoring-Tools	Laufenden Betrieb, L2/L3, Entwicklung
Vor Ort	Präsenz bei Ihnen oder in Ihrem Rechenzentrum	Übernahme, kritische Releases, Workshops
Hybrid	Überwiegend remote mit geplanten Präsenztagen	Wissenstransfer, Transformationsprojekte

Vertragsmodell

Modell	Beschreibung	Geeignet, wenn
Managed Service (gemanagtes AMS)	Verantwortung für Service und SLA, monatlicher Bericht	Der Betrieb vollständig abgegeben werden soll
Dediziertes Team	Fest zugeordnetes Team in Ihren Prozessen	Hohes, gleichmäßiges Volumen besteht
Teamverstärkung	Einzelne Ingenieure ergänzen Ihr Team	Bestimmte Kompetenzen fehlen
Projektbasis	Abgegrenzte Vorhaben, z. B. Framework-Upgrade	Ein klares Ergebnis gebraucht wird

Transition: von der Übernahme zum stabilen Betrieb

Schritt	Inhalt	Typische Dauer
1. Discovery und Inventar	Anwendungen, Architektur, Abhängigkeiten, offene Tickets, Dokumentationsstand	1–2 Wochen
2. Service-Design	Support-Level, Servicezeiten, Prioritäten, SLA, Eskalation, Tools	Parallel zur Discovery
3. Wissenstransfer	Schattenbetrieb und umgekehrter Schattenbetrieb mit dem bisherigen Team, Runbooks	2–6 Wochen
4. Hypercare	Erhöhte Aufmerksamkeit nach der Übernahme, tägliche Abstimmung	2–4 Wochen
5. Stabiler Betrieb	Ticketbetrieb nach SLA, Monatsbericht, Problem-Management	Fortlaufend
6. Transformation	Abbau technischer Schulden, Automatisierung, Modernisierung	Nach Roadmap

SLA- und KPI-Tabellen

Die folgenden Werte sind typische Startpunkte einer Leistungsbeschreibung und werden nach der Transition gemeinsam kalibriert.

Priorität	Beispiel	Typische Reaktionszeit	Typisches Ziel für Lösung/Workaround
P1 – Kritisch	Anwendung komplett nicht erreichbar, Zahlungs- oder Bestellprozess steht	15–30 Minuten	Workaround innerhalb von 4 Stunden
P2 – Hoch	Wichtige Funktion ausgefallen, kein Workaround	1 Stunde	1 Arbeitstag
P3 – Mittel	Funktion teilweise gestört, Workaround vorhanden	4 Arbeitsstunden	3–5 Arbeitstage
P4 – Niedrig	Kosmetischer Fehler, Informationsanfrage	1 Arbeitstag	Im geplanten Release

KPI	Was gemessen wird
SLA-Erfüllungsquote	Anteil der Tickets innerhalb der vereinbarten Zeiten
MTTR (Mean Time to Repair)	Durchschnittliche Zeit bis zur Wiederherstellung
Wiedereröffnungsquote	Anteil erneut geöffneter Tickets
Alter des Backlogs	Wie lange offene Tickets warten
Problem-Abschlussquote	Anteil gelöster Ursachen wiederkehrender Störungen
Change-Fehlerquote	Anteil von Änderungen, die Störungen verursachen
First-Contact-Resolution	Anteil der beim Erstkontakt gelösten Anfragen
Anwenderzufriedenheit (CSAT)	Kurzumfrage nach Ticketabschluss

Preismodelle und Kostenfaktoren

Abgerechnet wird als monatliche AMS-Pauschale, nach Personenmonat, Ticket- oder Stundenkontingent oder als Festpreis für Projekte. Ein Angebot folgt nach der Discovery. Wesentliche Kostentreiber:

Faktor	Wirkung
Anzahl und Komplexität der Anwendungen	Mehr Systeme und Technologien erfordern breiteres Know-how
Servicezeiten	Geschäftszeiten, erweiterte Zeiten oder 7/24-Schichtbetrieb
Ticketvolumen	Bestimmt die Kapazität im L1/L2-Bereich
SLA-Ziele	Kürzere Reaktionszeiten erfordern mehr Bereitschaft
Code- und Dokumentationsqualität	Schlechte Dokumentation verlängert Transition und Analyse
Entwicklungskontingent	Umfang der monatlichen Weiterentwicklung
Compliance-Anforderungen	Audits, Nachweise und besondere Sicherheitsauflagen

Internes Team, Freelancer oder AMS-Outsourcing

Kriterium	Internes Team	Freelancer	AMS-Outsourcing
7/24-Abdeckung	Nur mit großem Team möglich	Praktisch nicht möglich	Schichtbetrieb vertraglich vereinbar
Abhängigkeit von Einzelpersonen	Hoch bei kleinen Teams	Sehr hoch	Vertretung, Dokumentation und Ersatzprozess
Prozessreife	Abhängig von der Organisation	Meist ohne formale Prozesse	ITIL-basierte Prozesse und Reporting
Kostenstruktur	Fixkosten	Variabel, schwer planbar	Planbare Pauschale oder Kontingent
Technologiebreite	Begrenzt auf vorhandene Skills	Ein Schwerpunkt	Mehrere Technologien über ein Team

Softwarewartung und Support (AMS) — overview

Risiken und Gegenmaßnahmen

Risiko	Gegenmaßnahme
Wissensverlust bei der Übernahme	Strukturierter Wissenstransfer mit Schattenbetrieb, Runbooks, Abnahmekriterien
Ungetestete Änderungen in Produktion	Change-Prozess mit Test- und Staging-Umgebung, Freigabe durch Fachbereich
Wiederkehrende Störungen	Problem-Management mit Ursachenanalyse und dauerhaften Fixes
Veraltete Bibliotheken und Sicherheitslücken	Regelmäßige Abhängigkeitsscans und Patch-Zyklen
Intransparente Leistung	Monatsbericht mit SLA-Erfüllung, KPIs und Verbesserungsvorschlägen
Lock-in beim Dienstleister	Code, Dokumentation und Zugänge beim Kunden, geregelter Exit-Plan

Sicherheit, Datenschutz und rechtliche Hinweise

Zugriffe erfolgen über personalisierte Konten, VPN und MFA nach dem Minimalprinzip; privilegierte Zugriffe werden protokolliert. Produktionsdaten werden nur verarbeitet, soweit es für die Störungsbehebung notwendig ist, und Testumgebungen werden – wo möglich – mit anonymisierten Daten betrieben.

Vertragsrahmen für Auftraggeber aus der DACH-Region: Die Leistung wird als Dienstvertrag (laufender Betrieb und Support) oder Werkvertrag (abgegrenzte Ergebnisse) zwischen Unternehmen erbracht – es handelt sich ausdrücklich um keine Arbeitnehmerüberlassung. Fachliche Steuerung und Weisungen an die Teammitglieder laufen über die Teamleitung von 360 Soft; Sie steuern über Tickets, Leistungsbeschreibung und SLA. Ob das Arbeitnehmerüberlassungsgesetz (AÜG) berührt ist oder ein Risiko der Scheinselbständigkeit besteht, hängt von der tatsächlichen Durchführung ab; wir empfehlen daher eine rechtliche Prüfung des Vertrags- und Steuerungsmodells vor Projektstart. Datenschutzseitig schließen wir einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO mit EU-Standardvertragsklauseln (SCC) für die Übermittlung in die Türkei; auf türkischer Seite gilt zusätzlich das Datenschutzgesetz KVKK (Nr. 6698). Geheimhaltungsvereinbarung (NDA) und vollständige Übertragung der Nutzungsrechte an allen Arbeitsergebnissen sind Standard. Quellcode und Dokumentation liegen in Ihren Repositories.

Beispielszenario (illustrativ): Händlerportal nach Dienstleisterwechsel

Das folgende Szenario ist illustrativ und beschreibt keinen realen Kunden. Ein Großhändler betreibt ein individuell entwickeltes Händlerportal auf Java- und Angular-Basis. Der bisherige Dienstleister beendet die Zusammenarbeit, die Dokumentation ist lückenhaft, und Bestellungen brechen sporadisch ab, ohne dass die Ursache bekannt ist.

Ein mögliches Vorgehen: In einer zweiwöchigen Discovery werden Architektur, Schnittstellen und offene Tickets erfasst. Während eines vierwöchigen Schattenbetriebs entstehen Runbooks, ein Monitoring für die Bestellstrecke wird eingerichtet, und das Problem-Management analysiert die abbrechenden Bestellungen. Danach übernimmt ein kleines AMS-Team mit SLA den Betrieb. Ziel ist ein stabiler, dokumentierter Betrieb – Dauer und Ergebnis hängen vom Zustand des Systems ab.

Checkliste für die Auswahl eines AMS-Anbieters

Arbeitet der Anbieter nach dokumentierten ITIL-Prozessen?
Gibt es einen strukturierten Transition-Plan mit Abnahmekriterien?
Sind Prioritäten, Reaktions- und Lösungszeiten schriftlich definiert?
Ist 7/24-Betrieb bei Bedarf möglich?
Werden Problem-Management und Ursachenanalysen aktiv betrieben?
Gibt es Monitoring und proaktive Alarmierung?
Werden Abhängigkeiten und Sicherheitslücken regelmäßig geprüft?
Sind AVV nach DSGVO, SCC, NDA und Rechteübertragung geregelt?
Ist der Vertrag als Dienst- oder Werkvertrag ohne Arbeitnehmerüberlassung aufgesetzt?
Gibt es einen geregelten Exit-Plan?

Häufige Fragen

Was ist der Unterschied zwischen AMS und einem klassischen Wartungsvertrag?

Ein Wartungsvertrag deckt meist nur Fehlerbehebung ab. AMS umfasst den gesamten Betrieb nach ITIL: Incident, Problem, Change, Release, Monitoring und Reporting mit SLA.

Können Sie Software übernehmen, die ein anderes Unternehmen entwickelt hat?

Ja. Nach Discovery und strukturiertem Wissenstransfer übernehmen wir den Betrieb, auch bei lückenhafter Dokumentation.

Was ist der Unterschied zwischen Incident und Problem?

Ein Incident ist eine einzelne Störung, die schnell behoben werden muss. Ein Problem ist die Ursache wiederkehrender Incidents, die dauerhaft beseitigt wird.

Wie werden Notfalländerungen gehandhabt?

Über einen beschleunigten Emergency-Change-Prozess mit Freigabe durch eine benannte Person und nachträglicher Dokumentation.

Bieten Sie 7/24-Support an?

Ja, als Schichtbetrieb oder Rufbereitschaft, abhängig von Kritikalität und vereinbarten SLA.

Welche Technologien unterstützen Sie?

Unter anderem Java,.NET, Node.js, Python, PHP, React, Angular, Vue, gängige Datenbanken sowie Cloud- und Container-Plattformen.

Wie lange dauert die Transition?

Typischerweise 4–10 Wochen von der Discovery bis zum stabilen Betrieb, abhängig von Anzahl und Zustand der Anwendungen.

Gehören Weiterentwicklungen zum AMS?

Kleine Verbesserungen ja, über ein monatliches Entwicklungskontingent; größere Vorhaben werden als Projekt geplant.

Wie berichten Sie über die Leistung?

Mit einem Monatsbericht zu SLA-Erfüllung, KPIs, Problemen, Changes und Verbesserungsvorschlägen sowie regelmäßigen Service-Reviews.

Wem gehören Code und Dokumentation?

Ihnen. Code und Dokumentation liegen in Ihren Repositories, die Nutzungsrechte werden vollständig übertragen.

Wie wird abgerechnet?

Als monatliche AMS-Pauschale, nach Personenmonat, Ticket- oder Stundenkontingent oder Festpreis. Ein Angebot folgt nach der Discovery.

Handelt es sich um Arbeitnehmerüberlassung?

Nein. Die Leistung wird als Dienst- oder Werkvertrag erbracht; eine rechtliche Prüfung des Steuerungsmodells empfehlen wir dennoch.

Ihr AMS-Vorhaben besprechen

Nennen Sie uns kurz Ihre Anwendungen, Technologien, Servicezeiten und den aktuellen Stand der Betreuung. Wir melden uns mit einem Vorschlag zu Transition, Teamzuschnitt und nächsten Schritten – ein typischer Start ist innerhalb von 1–2 Wochen möglich. Telefon: +90 850 335 10 87 · WhatsApp: +90 850 335 10 87 · E-Mail: info@360-soft.com · Kontaktformular 360 Soft Marketing Yazılım ve Danışmanlık Ltd. Şti., Nidakule Ataşehir Batı, Barbaros Mah. Begonya Sk. No:1 D:2, 34746 Ataşehir/İstanbul.

Softwarewartung und Support (AMS)