Inhaltsverzeichnis
Das Wichtigste vorab
Wie bleibt Business Central nach einem Update für den GMP-Einsatz geeignet?
Erfassen Sie Zielversion, Extensions und betroffene Prozesse, bewerten Sie die Auswirkungen und prüfen Sie die relevanten Abläufe auf einem geeigneten Teststand. Klären Sie offene Fehler vor der Betriebsentscheidung und dokumentieren Sie den tatsächlich installierten Stand. Bei Business Central Online müssen Sie diese Arbeit innerhalb der verfügbaren Updatefristen organisieren; ein unbegrenzt eingefrorener Cloud-Stand ist keine tragfähige Strategie.
- Online-Fristen, Wartungsfenster und On-Premises-Installationen verlangen unterschiedliche Planung.
- Eine Produktionskopie benötigt kontrollierte Daten, Testverbindungen und einen belegten Zielstand.
- Kompatible Apps und ein technisch erfolgreiches Update belegen noch keinen geeigneten Geschäftsprozess.
- Die Betriebsentscheidung umfasst Testergebnisse, offene Fehler, Einschränkungen und Nachkontrolle.
1. Betriebsform und konkreten Änderungsumfang festlegen
Beginnen Sie mit der eindeutigen Systemidentität: Online oder On-Premises, Umgebung, Landversion, Anwendungsstand, installierte Apps und relevante Schnittstellen. Notieren Sie außerdem, welche qualitätsrelevanten Aufgaben dort stattfinden. Ein Update kann beispielsweise einen dokumentierten Materialstatus, eine Chargenzuordnung oder eine Übergabe an ein Lagerverwaltungssystem betreffen. Diese Beispiele sind Prüfgegenstände Ihres Prozesses, keine Zusage zu einer bestimmten Standardfunktion.
Für Online betreibt Microsoft den Aktualisierungsprozess. On-Premises organisiert Ihr Betrieb beziehungsweise Partner die Installation. Die Microsoft-Anleitung für Version 28 unterscheidet Plattform- und Anwendungsänderungen sowie die zugehörigen Daten- und Extension-Schritte. Daraus folgt kein allgemeiner Upgradepfad für jede Altversion. Maßgeblich bleiben Ausgangsstand, unterstützter Zielstand und die passende Installationsanleitung.
Regulatorischer Bezug ist hier die Nutzung in der Humanarzneimittelherstellung. Annex 11 ist die GMP-Leitlinie für computergestützte Systeme und verlangt kontrollierte Änderungen sowie risikobezogene Nachweise. Part 11 ist zusätzlich zu prüfen, wenn die betreffenden elektronischen Aufzeichnungen oder Signaturen in seinen FDA-Geltungsbereich fallen. Ein ERP-Update allein erzeugt diesen Geltungsbereich nicht.
2. Den Online-Kalender mit echten Fristen führen
Microsoft beschreibt zwei Hauptversionen jährlich, im April und Oktober, sowie kleinere Updates in den übrigen Monaten. Der konkrete Tenanttermin ist daraus nicht ableitbar. Führen Sie einen Kalender mit verfügbarer Zielversion, geplantem Update, zulässigem Verschiebungszeitraum, Testabschluss und Vertretung für die Entscheidung. Verantwortliche müssen die Benachrichtigungen tatsächlich erhalten und bearbeiten.
Die dokumentierte Updateperiode einer Hauptversion umfasst fünf Kalendermonate, gefolgt von einem Monat Grace Period. In dieser Nachfrist lässt sich der Termin nicht weiter nach hinten verschieben. Danach kann Microsoft inkompatible Extensions deinstallieren, damit das erzwungene Update gelingt; zugehörige Daten werden laut Dokumentation dabei nicht gelöscht. Eine fehlende Branchenfunktion bleibt dennoch ein erhebliches Betriebsproblem.
Planen Sie deshalb einen internen Entscheidungstermin vor dem letzten technischen Spielraum. Für kritische Korrekturen und zugrunde liegende Servicekomponenten gelten zusätzliche Betriebsmechanismen; nicht jede Wartung wartet auf Ihren Projektplan. Im Änderungsverfahren sollte feststehen, wer bei kurzfristigen Informationen die Auswirkungen bewertet und welche Mindestkontrollen vor der weiteren Nutzung erforderlich sind.
3. Wartungsfenster und Betriebsunterbrechung abstimmen
Das Online-Updatefenster wird je Umgebung mit Zeitzone festgelegt und muss mindestens sechs Stunden umfassen. Es ist ein zulässiger Zeitraum, keine garantierte Startminute und keine zugesagte Dauer. Während des Updates ist die Anmeldung gesperrt. Stimmen Sie deshalb Schichtübergaben, laufende Buchungen, technische Hintergrundabläufe und die Erreichbarkeit des Partners auf das tatsächliche Fenster ab.
Ein innerhalb des Fensters nicht abgeschlossenes Update wird im beschriebenen Normalfall abgebrochen und erneut eingeplant. Die Option, ein Update außerhalb des Fensters laufen zu lassen, verändert diese Begrenzung. Sie gehört in eine bewusste Betriebsentscheidung, besonders wenn ein Folgeschritt morgens zwingend verfügbar sein muss.
Beschreiben Sie den Übergang konkret: Bis wann werden neue Aufträge angenommen? Welche Schnittstellen werden kontrolliert angehalten? Wer prüft nach dem Update offene Übertragungen? Halten Sie notwendige Ersatzabläufe und deren spätere Abstimmung fest. Eine telefonische Bereitschaft ohne Zugriff, Befugnis und nachvollziehbare Handlungsanweisung löst diese Aufgaben nicht.
4. Releaseinformationen in eine begründete Testauswahl übersetzen
Eine Auswirkungsbewertung verbindet jede relevante Änderung mit einer Anforderung und einem möglichen Fehler. Verwenden Sie Releaseinformationen, Partnerhinweise, Konfigurationsvergleich und bekannte Vorfälle. Die folgende Arbeitsmatrix ist eine eigene Planungshilfe. Sie schreibt weder eine pauschale Testanzahl noch eine vollständige Wiederholung aller früheren Prüfungen vor.
Die Auswahl sollte auch bestehende Kontrollpunkte berücksichtigen. Hat ein unveränderter Ablauf belastbare Nachweise und keine betroffene Abhängigkeit, kann eine begründete Dokumentenbewertung ausreichen. Berührt eine Änderung dagegen kritische Daten oder eine Sperrentscheidung, benötigen Sie passende Funktions- und Fehlerfallprüfungen. Ein technischer Kompatibilitätsbefund allein beantwortet diese fachliche Frage nicht.
| Änderung oder Signal | Mögliche Auswirkung | Sinnvoller Nachweis |
|---|---|---|
| Geänderte Buchungslogik | Falsche Menge oder Zuordnung im Folgeprozess | Repräsentative Buchung mit Sollwerten und Abstimmung des empfangenden Systems |
| Neue App-Abhängigkeit | Branchenfunktion fehlt oder arbeitet anders | Versionen und Abhängigkeiten abgleichen; betroffenen Ablauf vollständig durchlaufen |
| Geänderte Berechtigung | Unbefugte Änderung eines kritischen Status | Positive und negative Rollenprüfung mit normalen Benutzerkonten |
| Geänderte Schnittstelle | Datensatz fehlt, kommt doppelt oder verspätet | Übertragung, Unterbrechung, Wiederholung und fachliche Abstimmung prüfen |
| Nur dokumentierte Oberflächenänderung | Bedienfehler oder geänderte Arbeitsanweisung | Auswirkung begründen; gezielte Bedienprüfung und gegebenenfalls Schulung |
| Offener Fehler aus dem vorherigen Release | Bekannte Einschränkung besteht weiter | Korrekturbeleg oder weiter gültige, bewertete Ersatzkontrolle dokumentieren |
5. Eine belastbare Sandbox vorbereiten
Eine Online-Umgebungskopie startet auf derselben Anwendungsversion und übernimmt installierte Apps. Das Kopieren aktualisiert die Lösung also noch nicht auf den Zielstand. Microsoft stoppt unter anderem Auftragswarteschlangen, bereinigt bestimmte Integrationskonfigurationen und blockiert ausgehende HTTP-Aufrufe von Extensions zunächst. Verknüpfte Power-Platform-Umgebungen werden nicht mitkopiert. Dokumentieren Sie, welche Testverbindungen Sie danach bewusst herstellen.
Eine Produktionskopie ist keine anonymisierte Datenmenge. Zugriffe, personenbezogene Informationen und Maßnahmen zur Datenbereinigung sind für die Kopie gesondert zu behandeln. Nachträgliche Datenschutzmaßnahmen im Original synchronisieren sich nicht automatisch. Verwenden Sie geeignete Testdaten, begrenzte Berechtigungen und eindeutig erkennbare Testempfänger. Die Freigabe einer HTTP-Verbindung darf keine versehentliche Kommunikation mit einem Produktivdienst erlauben.
Die spezifische Microsoft-Preview-Dokumentation erlaubt das Aktualisieren einer vorhandenen Sandbox auf eine Previewversion. Previewumgebungen sind jedoch vorläufig und werden nach Ende des vorgesehenen Zeitraums gelöscht; sichern Sie benötigte Nachweise außerhalb dieser Umgebung. Prüfen Sie den endgültigen freigegebenen Zielstand gesondert. Außerdem ist eine Sandbox wegen ihres anderen Leistungstarifs kein verlässlicher Maßstab für Produktionsperformance.
6. App-Stände und Abhängigkeiten gemeinsam einfrieren
Notieren Sie vor jedem Testlauf die tatsächlich installierten App-Versionen einschließlich Bibliotheken. Bei einer Hauptversionsaktualisierung können zusätzlich Marketplace-Apps aktualisiert werden. Für kleinere Versionswechsel steuert die Einstellung Apps Update Cadence Teile dieses Verhaltens; notwendige Kompatibilitätsupdates bleiben relevant. Diese Einstellung steuert keine Updates kundenspezifischer Per-Tenant Extensions.
App-Abhängigkeiten können weitere Installationen oder Aktualisierungen verlangen. Klären Sie mit dem Branchenpartner, welche Kombination geprüft wurde und welche Korrektur für Ihren Zielstand vorgesehen ist. Erst ein vollständiger Versionssatz erlaubt einen nachvollziehbaren Vergleich zwischen Sandbox und Produktion. Wenn nach dem Test noch eine Bibliothek wechselt, bewerten Sie diesen zusätzlichen Unterschied.
Besondere Aufmerksamkeit verdienen Entwicklungs-Extensions: Direkt aus der Entwicklungsumgebung veröffentlichte Sandbox-Apps können beim Umgebungsupdate entfernt werden, während ihre Daten erhalten bleiben. Testen Sie deshalb den vorgesehenen Bereitstellungsweg und keinen zufällig noch vorhandenen Entwicklerstand. Welche Partnerunterlagen Sie für das Branchenmodul benötigen, behandelt der separate Extension-Leitfaden; hier zählt ihre Verwendung im konkreten Update.
7. Illustratives Beispiel: Materialstatus und Lagerübergabe
Das folgende konstruierte Beispiel beschreibt einen Betrieb mit einer kundenspezifischen Materialfreigabe-Extension und einer Schnittstelle zum Lager. Es ist kein ausgeführter Kundentest und keine Beschreibung des unveränderten Business-Central-Standards. Die Anforderung lautet: Ein gesperrtes Material darf nicht als verfügbar an das Lager übergeben werden; eine berechtigte Freigabe muss mit der richtigen Charge und Menge ankommen.
Der Testverantwortliche erstellt zwei definierte Materialdatensätze und dokumentiert Ausgangsstand, App-Versionen, Rollen und Schnittstellenendpunkte. Die erwarteten Statuswerte und Meldungen stammen aus der eigenen Spezifikation. Ein Update ist erst fachlich beurteilt, wenn auch abgelehnte und unterbrochene Vorgänge nachvollziehbar sind.
| Prüffall | Durchführung | Erwarteter Nachweis |
|---|---|---|
| Gesperrtes Material | Übertragung mit gesperrtem Ausgangsstatus versuchen | Kein verfügbarer Lagerbestand; verständliche Ablehnung und passende Aufzeichnung |
| Berechtigte Freigabe | Mit freigegebener Rolle den Status wechseln und übertragen | Richtige Charge, Menge und Status im Ziel; eindeutige Zuordnung zum Ausgangsvorgang |
| Unberechtigte Freigabe | Gleiche Aktion mit normaler Lagerrolle versuchen | Aktion bleibt gemäß Berechtigungskonzept gesperrt |
| Kommunikationsabbruch | Testverbindung während der Übergabe gezielt unterbrechen | Fehler erkennbar; definierter Wiederanlauf ohne stillen Verlust |
| Wiederholung | Fehlgeschlagenen Vorgang nach Wiederanlauf erneut senden | Keine unbeabsichtigte Doppelbuchung; Abstimmung beider Seiten möglich |
| Historischer Datensatz | Vor dem Update abgeschlossenen Vorgang lesen | Wesentliche Inhalte und Zuordnungen weiterhin richtig und nachvollziehbar |
| Nachkontrolle | Nach Produktivupdate einen freigegebenen Kontrollablauf prüfen | Installierter Stand und betriebliche Funktion stimmen mit der Entscheidung überein |
8. Bei Fehlern den zulässigen Handlungsraum kennen
Unterscheiden Sie einen fachlichen Fehler im Test, ein technisch fehlgeschlagenes Update und einen Fehler nach erfolgreicher Aktualisierung. Beim Testfehler dokumentieren Sie Reproduktionsschritte, Daten, Versionen und Auswirkungen. Entscheiden Sie mit QA und Prozessverantwortlichem, ob eine Korrektur, ein zulässiger Terminwechsel oder eine bewertete Einschränkung nötig ist. Die Aussage „Partner ist informiert“ genügt nicht als Entscheidung.
Ein fehlgeschlagenes oder abgebrochenes Online-Update führt nach Microsofts Beschreibung zur bisherigen Anwendungsversion zurück; der nächste Versuch wird erneut eingeplant. Der manuelle Abbruch hat Grenzen, insbesondere während der erzwungenen Updateperiode. Das ist etwas anderes als ein beliebiger Rücksprung nach einem bereits erfolgreichen Update. Auch Restoremöglichkeiten sind versionsabhängig eingeschränkt.
Bei einem Fehler im produktiven Ablauf sichern Sie den Befund und bestimmen den betroffenen Zeitraum, Datenbestand und Folgeprozess. Halten Sie kritische Vorgänge gegebenenfalls an und stimmen Sie bereits übertragene Daten ab. Für die technische Eskalation helfen Operationsdaten und eindeutige Fehlerreferenzen. Der Wiederanlauf benötigt ein überprüfbares Kriterium, etwa korrigierte Übertragung und abgeschlossene Bestandsabstimmung.
9. Freigabe und Nachkontrolle als gemeinsame Entscheidung
Ein sinnvoller Updateabschluss benennt den installierten Stand, die bewerteten Änderungen, durchgeführte Prüfungen, Abweichungen und die Entscheidung zur weiteren Nutzung. Halten Sie Einschränkungen so fest, dass der Betrieb sie tatsächlich umsetzen kann: betroffener Prozess, zulässiger Ersatzablauf, verantwortlicher Ansprechpartner und Termin zur Neubewertung. Eine unbestimmte Restpunktliste erschwert die tägliche Anwendung.
Microsoft liefert den Dienst und Produktinformationen; der Branchenpartner liefert seinen vereinbarten Anteil an Apps, Analyse und Korrektur. Beim Anwender bleiben die Kenntnis des vorgesehenen Einsatzes und die Bewertung der eigenen Abläufe. Legen Sie fest, wer Termine verwaltet, Auswirkungen beurteilt, Tests ausführt und die fachliche Entscheidung trifft. In kleinen Teams können Aufgaben kombiniert werden; Befugnisse und geeignete Kontrolle müssen klar bleiben.
Der Aufwand hängt insbesondere von Varianten, Schnittstellen, App-Abhängigkeiten und der Qualität vorhandener Regressionstests ab. Wiederverwendbare Testdaten und nachvollziehbare Sollwerte verkürzen Abstimmungen, ohne einen festen Zeitgewinn zu versprechen. Führen Sie wiederkehrende Fehler, manuelle Ersatzschritte und überfällige Maßnahmen in die periodische Systembewertung zurück.
10. Checkliste für den nächsten Updatezyklus
Nutzen Sie diese Checkliste als Arbeitshilfe für den gemeinsamen Termin von IT, QA, Prozessverantwortlichem und Partner. Ein fehlender Punkt verlangt eine Entscheidung über seine Bedeutung; nicht jedes leere Feld löst denselben Testumfang aus.
- Betriebsform, Umgebung, Ausgangs- und Zielversion sowie Ansprechpartner sind eindeutig erfasst.
- Updateperiode, Zeitzone, Wartungsfenster und interner Entscheidungstermin sind bekannt.
- Benachrichtigungen erreichen einen verantwortlichen Mitarbeiter und seine Vertretung.
- Releaseinformationen, Partneränderungen und bekannte Fehler wurden auf den eigenen Einsatz bezogen.
- Sandbox, Datenzugriff, Testempfänger und Schnittstellen sind kontrolliert eingerichtet.
- Der geprüfte Versionssatz enthält alle relevanten Apps und Abhängigkeiten.
- Tests decken kritische Prozesspfade sowie passende negative und unterbrochene Abläufe ab.
- Offene Fehler besitzen eine Auswirkungsbewertung und eine konkrete Behandlung.
- Betriebsentscheidung, mögliche Einschränkungen und Nachkontrolle sind dokumentiert.
- Nachweise bleiben unabhängig vom Lebensende einer Sandbox oder Preview verfügbar.
Häufige Fragen zu Business-Central-Updates
Müssen wir Business Central nach jedem Update vollständig neu validieren?
Nein. Bewerten Sie die Änderung gegenüber Ihrem belegten Ausgangszustand und den betroffenen Anforderungen. Daraus folgen geeignete ergänzende Nachweise. Ein kleiner technischer Versionsschritt kann einen kritischen Ablauf berühren; ein größerer Release kann viele für Sie ungenutzte Funktionen enthalten. Entscheidend sind nachvollziehbare Auswirkungen und verbleibende Unsicherheiten, nicht allein die Versionsnummer oder ein pauschaler Wiederholungsplan.
Quellen: [8]
Können wir Business Central Online auf unserem validierten Stand belassen?
Nicht unbegrenzt. Die Online-Updatepolitik sieht begrenzte Zeiträume und anschließend eine erzwungene Aktualisierung vor. Richten Sie Ihr Änderungsverfahren auf diese Fristen aus. Wenn eine wesentliche Branchenfunktion noch nicht kompatibel ist, benötigen Sie früh eine belastbare Lösung mit dem Anbieter und eine betriebliche Entscheidung. Dauerhaftes Verschieben ist kein Ersatz für die Bearbeitung des Konflikts.
Quellen: [1]
Sind sechs Stunden Updatefenster eine zugesagte Ausfallzeit?
Nein. Sechs Stunden sind die dokumentierte Mindestbreite des einstellbaren Fensters. Der tatsächliche Start und die Dauer hängen vom Update und der Umgebung ab. Planen Sie die mögliche Nichtverfügbarkeit mit dem Betrieb und prüfen Sie die Auswirkungen auf Schnittstellen. Eine Option für Updates außerhalb des Fensters darf nicht versehentlich eine zugesagte Betriebsbereitschaft am nächsten Morgen unterlaufen.
Quellen: [2]
Reicht ein Test in einer Preview-Sandbox für die Produktionsentscheidung?
Ein Preview-Test liefert frühe Hinweise, ersetzt aber nicht den Abgleich mit dem endgültigen Zielstand. Apps, Fehlerkorrekturen und Konfiguration können sich unterscheiden. Halten Sie fest, welche Nachweise weiter gelten und welche ergänzenden Prüfungen nötig sind. Bewahren Sie Ergebnisse außerhalb der Preview auf, weil diese Umgebungen nur vorübergehend bestehen und nicht als dauerhaftes Nachweisarchiv vorgesehen sind.
Ist eine kopierte Produktionsumgebung sofort als Testsystem nutzbar?
Sie muss zuerst kontrolliert eingerichtet werden. Microsoft verändert beim Kopieren bestimmte Hintergrund- und Integrationsfunktionen. Prüfen Sie daher Testverbindungen, Empfänger, Rollen und die benötigten Daten. Die Kopie enthält weiterhin relevante Geschäftsdaten und ist nicht automatisch anonymisiert. Außerdem reproduziert sie weder eine angebundene Power-Platform-Umgebung noch ohne weitere Arbeit die vollständige Ende-zu-Ende-Landschaft.
Quellen: [3]
Sind erfolgreiche Microsoft-Kompatibilitätsprüfungen ausreichend?
Sie sind nützliche Produktnachweise, beantworten aber nicht alle Fragen Ihres vorgesehenen Einsatzes. Eine App kann installierbar sein und dennoch einen fachlichen Status falsch an ein angebundenes System übergeben. Bewerten Sie Hersteller- und Partnernachweise auf Passung und Lücken. Die verbleibenden Prüfungen sollten Ihre kritischen Abläufe mit der tatsächlich vorgesehenen App-Kombination abdecken.
Warum kann der Teststand nach dem Update anders aussehen als erwartet?
Neben Business Central selbst können sich Apps und Abhängigkeiten geändert haben. Außerdem sind Entwicklungs-Extensions in einer Sandbox anders bereitgestellt als regulär installierte Pakete. Vergleichen Sie deshalb nach dem Update die tatsächlich vorhandenen Versionen mit der Testplanung. Eine erfolgreiche Ausführung auf einem zuvor manuell ergänzten Entwicklerstand ist nicht automatisch auf die spätere Produktionskombination übertragbar.
Können wir bei einem Problem einfach auf die alte Version zurück?
Verlassen Sie sich darauf nicht. Der Rückweg eines fehlgeschlagenen oder abgebrochenen Updates ist vom Restore nach einem erfolgreichen Update zu unterscheiden. Microsoft dokumentiert dafür Einschränkungen, unter anderem abhängig von der Updateperiode. Klären Sie den verfügbaren Wiederherstellungsweg vorher und berücksichtigen Sie neue Buchungen sowie Daten in angeschlossenen Systemen. Eine technische Wiederherstellung ersetzt deren fachliche Abstimmung nicht.
Was ist bei On-Premises anders?
Die Installation und das Betriebsfenster liegen bei Ihrem Betrieb beziehungsweise Dienstleister. Dazu gehören versionsbezogene Plattform-, Datenbank- und Extension-Schritte; die Online-Fristen werden nicht unverändert übertragen. Nutzen Sie die Anleitung für Ihren konkreten Ausgangs- und Zielstand und bewerten Sie Sicherung, Wiederanlauf sowie die betroffenen Geschäftsprozesse. Mehr Terminkontrolle bedeutet nicht, dass Änderungen ohne Bewertung durchgeführt werden können.
Welche Unterlagen sollte ein KMU für den nächsten Zyklus zuerst zusammenstellen?
Beginnen Sie mit Umgebung und Versionen, App-Liste, Schnittstellenübersicht, kritischen Prozessanforderungen und den letzten Testergebnissen. Ergänzen Sie Updateankündigung, Partnerhinweise sowie offene Fehler. Diese Unterlagen machen sichtbar, was geändert wird und wer handeln muss. Daraus entsteht ein konkreter Prüf- und Entscheidungsplan. Pauschale Tagessätze, Testmengen oder Zeitversprechen helfen ohne diesen Umfang wenig.
Quellen & fachlicher Stand
Quellenstand: 6. Oktober 2026. Die Online-Mechanismen sind nach aktueller Microsoft-Dokumentation beschrieben; konkrete Tenanttermine und App-Stände bleiben zu prüfen. Regulatorischer Bezug: Humanarzneimittel-GMP, FDA-Anforderungen nur im passenden Geltungsbereich. Matrizen, Beispiel und Checkliste sind eigene Arbeitshilfen.
- Microsoft Learn: Update cycles
- Microsoft Learn: Managing updates in the Business Central admin center
- Microsoft Learn: Copy an environment
- Microsoft Learn: Prepare for major updates with preview environments
- Microsoft Learn: Managing production and sandbox environments
- Microsoft Learn: Managing apps
- Microsoft Learn: Install a Business Central 2026 release wave 1 update
- EU-Kommission: EU-GMP Annex 11, Revision Januar 2011
- EU-Kommission: EudraLex Volume 4
- eCFR: 21 CFR Part 11
- FDA: Part 11 – Scope and Application
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Den nächsten Business-Central-Updatezyklus vorbereiten
Wir verbinden Ihre Änderungsinformationen mit den qualitätsrelevanten Abläufen und vorhandenen Nachweisen. Daniel Herrmann Consulting unterstützt Sie dabei, offene Entscheidungen vor dem Update sichtbar und bearbeitbar zu machen.
- IT-GxP-Consulting →
Updateumfang, Prüfungen und Betriebsentscheidung für Ihren konkreten Einsatz vorbereiten.
- IT-GxP-Audit →
Den bestehenden Updateprozess und seine Nachweise auf relevante Lücken untersuchen.