macOS-Forschungssoftware remote nutzen: Abnahmecheckliste 2026

Apple bestätigt für macOS Tahoe 26 einen festgelegten Kreis kompatibler Mac-Modelle; die Systemversion allein beweist jedoch noch nicht, dass Ihre Forschungssoftware geeignet ist. Die offizielle Kompatibilitätsübersicht zu macOS Tahoe 26 ist deshalb nur der erste Prüfpunkt. Für eine kurzfristige Nutzung, eine Reproduktion einer Publikationsumgebung oder einen plattformübergreifenden Test sollten Sie einen Remote Mac mieten und ihn anhand eines echten, repräsentativen Forschungsauftrags abnehmen. Entscheidend sind vier abgeschlossene Stationen: Software starten, reale Aufgabe durchführen, Ergebnis exportieren und Umgebung sauber verlassen.

Diese Woche sollten Sie einen anonymisierten Beispieldatensatz, die benötigten Installationsquellen, die Lizenzbedingungen und das erwartete Ergebnis zusammentragen. Wenn Ihr Vorhaben eine direkte Instrumentenverbindung, streng getaktete Stimulation oder nicht freigegebene sensible Daten verlangt, stoppen Sie die Mietentscheidung zunächst und holen die Zustimmung Ihrer Hochschule oder Arbeitsgruppe ein.

Diese Anleitung richtet sich an:

• Studierende, die nur einen Windows- oder Linux-Rechner besitzen, aber macOS-Forschungssoftware für ein Seminar, eine Abschlussarbeit oder ein gemeinsames Projekt benötigen;
• Promovierende, Forschende und technische Verantwortliche, die eine Mac-Umgebung für Reproduktion, Kompatibilitätstests oder Softwareentwicklung benötigen;
• Arbeitsgruppen, die zwischen dem Kauf eines physischen Mac und einer Nutzung nach Projekt- oder Monatszyklus entscheiden müssen.

Vor der Miete: Forschungsaufgabe und Risikogrenzen festlegen

Eine entfernte macOS-Umgebung ist kein allgemeiner Ersatz für einen Linux-HPC-Cluster und auch nicht automatisch eine geeignete Steuerungsebene für Laborgeräte. Klären Sie zuerst, warum macOS erforderlich ist. Es gibt einen belastbaren Grund, wenn die benötigte Anwendung nur für macOS bereitsteht, ein bestimmtes Plug-in nur dort unterstützt wird, die Publikationsumgebung auf einem Mac erstellt wurde oder Sie eine Mac-Version Ihrer eigenen Software prüfen müssen.

Ordnen Sie die Software in drei Stufen ein:

1. Offiziell unterstützt: Das Handbuch nennt Ihre macOS-Version und Ihre Prozessorarchitektur ausdrücklich.
2. Startfähig: Die Anwendung öffnet sich, obwohl der Anbieter Ihre Kombination aus System, Architektur und Plug-ins nicht vollständig zusichert.
3. Für Forschung geeignet: Ein repräsentativer Auftrag läuft durch, erzeugt ein plausibles Ergebnis und lässt sich unter denselben Bedingungen wiederholen.

Nur die dritte Stufe rechtfertigt eine produktive Nutzung. Ein geöffnetes Programmfenster ist kein Kompatibilitätsnachweis.

Prüfen Sie außerdem die Lizenz. Eine Campuslizenz kann an institutionelle Netzwerke, einzelne Benutzerkonten, einen Lizenzserver oder eine bestimmte Zahl gleichzeitiger Sitzungen gebunden sein. Eine persönliche Lizenz darf nicht automatisch auf einem gemieteten Rechner eingesetzt werden. Schreiben Sie vor der Bestellung auf, wer die Lizenz besitzt, wo die Zugangsdaten verwaltet werden und ob ein Gerätewechsel erlaubt ist.

Apple Silicon verdient eine eigene Prüfung. Wenn der Remote Mac einen Apple-Silicon-Prozessor verwendet, muss Ihre Software entweder nativ laufen oder die Ausführung von Intel-Anwendungen unterstützen. Apple beschreibt sowohl die Migration von macOS-Anwendungen auf Apple Silicon als auch die Erstellung universeller macOS-Binärdateien in den Entwicklerdokumentationen zu Apple Silicon. Für Intel-Anwendungen erklärt Apple die entsprechende Kompatibilitätsschicht in einer separaten Support-Anleitung. Das bedeutet nicht, dass jedes Plug-in, jeder Treiber und jede Lizenz automatisch funktioniert.

Entscheidungstool: Abnahme mit Bedingungen oder Nutzung stoppen

Verwenden Sie die folgende ausfüllbare Entscheidungscheckliste vor der Buchung und erneut nach dem ersten Test. Setzen Sie ein Häkchen nur dann, wenn Sie einen konkreten Nachweis gespeichert haben. Ein nicht belegter Punkt gilt als „Nein“.

• [ ] System: Die Zielsoftware nennt die vorgesehene macOS-Version und die verwendete Prozessorarchitektur als unterstützt.
  Wenn ja: Fahren Sie mit dem Minimaltest fort. Wenn nein: Prüfen Sie eine andere System- oder Architekturvariante, statt produktive Daten zu verwenden.

• [ ] Lizenz: Die Lizenzbedingungen erlauben die Nutzung auf dem gemieteten Rechner und die Anmeldung ist einer verantwortlichen Person zugeordnet.
  Wenn ja: Dokumentieren Sie Lizenztyp und Abmeldeweg. Wenn nein: Stoppen Sie die Miete, bis der Anbieter oder Ihre Hochschule die Nutzung freigibt.

• [ ] Zugang: Grafische Verbindung, SSH und Dateitransfer funktionieren mit der vorgesehenen Berechtigung.
  Wenn ja: Testen Sie Dateiintegrität und Wiederaufnahme. Wenn nein: Fordern Sie eine Korrektur an oder wählen Sie eine andere Plattform.

• [ ] Minimalbeispiel: Die Anwendung startet, liest einen öffentlichen oder anonymisierten Datensatz, führt den Kernschritt aus und speichert das Ergebnis.
  Wenn ja: Beginnen Sie den repräsentativen Forschungsauftrag. Wenn nein: Mieten Sie nicht länger in der Erwartung, dass ein späterer Produktivlauf den Fehler von selbst beseitigt.

• [ ] Repräsentativer Auftrag: Ein typischer Arbeitsablauf aus Ihrer Publikation, Lehrveranstaltung oder Softwareprüfung läuft vollständig durch.
  Wenn ja: Vergleichen Sie die Resultate mit Ihrer bisherigen Umgebung. Wenn nein: Wechseln Sie Version, Plug-in, Architektur oder Plattform.

• [ ] Unterbrechung: Nach einer kontrollierten Trennung bleiben Prozessstatus, Dateien und Protokolle nachvollziehbar.
  Wenn ja: Legen Sie Regeln für lange Jobs fest. Wenn nein: Vermeiden Sie unbeaufsichtigte Berechnungen über die grafische Sitzung.

• [ ] Export: Code, Umgebung, Protokolle und Ergebnisse lassen sich auf einem zweiten Gerät öffnen.
  Wenn ja: Bereiten Sie die Übergabe vor. Wenn nein: Die Umgebung ist noch nicht lieferfähig.

• [ ] Datenschutz: Ihre Hochschule oder Arbeitsgruppe hat die Verarbeitung der vorgesehenen Daten in der externen Umgebung freigegeben.
  Wenn ja: Arbeiten Sie innerhalb dieser Freigabe. Wenn nein: Verwenden Sie nur öffentliche oder vollständig anonymisierte Daten und stoppen Sie den produktiven Einsatz.

Entscheidungsregel: Wenn alle für Ihr Projekt relevanten Punkte erfüllt sind, können Sie einen Remote Mac für den vereinbarten Zeitraum einsetzen. Wenn der Softwaretest, der repräsentative Auftrag oder der Export scheitert, sollten Sie nicht nach dem Kriterium „Login war möglich“ entscheiden. Wechseln Sie dann zu einer lokalen oder institutionell kontrollierten Umgebung beziehungsweise begrenzen Sie den Remote Mac auf einen nicht sensiblen Test.

Diese Abgrenzung beantwortet zugleich die Frage, ob ein Remote Mac für Reproduktion und Datenanalyse geeignet ist: Ja, wenn die Software- und Datenschutzbedingungen erfüllt sind und der Arbeitsablauf mit einem repräsentativen Datensatz abgenommen wurde. Nein, wenn die Verbindung lediglich den Desktop anzeigt, aber die tatsächliche Mess-, Lizenz- oder Datenkette nicht kontrollierbar ist.

Beim ersten Login: System, Rechte und Verbindungen dokumentieren

Nach dem Zugang erstellen Sie eine neutrale Ausgangsbasis. Notieren Sie die macOS-Version, die Prozessorarchitektur, den verfügbaren Speicherplatz, das Benutzerkonto und die vorgesehenen Aktualisierungsregeln. Die Systemversion lässt sich nach Apples Anleitung über die Mac-Systeminformationen prüfen; verwenden Sie dafür die offizielle Anleitung zum Anzeigen der macOS-Version. Dokumentieren Sie die Werte ohne Passwörter, private Schlüssel, Tokens oder Forschungsdaten.

Die Architektur prüfen Sie nicht nur anhand einer Anbieterbeschreibung. Öffnen Sie die Systeminformationen und halten Sie fest, ob die Anwendung nativ oder über die Intel-Kompatibilitätsschicht ausgeführt wird. Dieser Unterschied kann bei Plug-ins, Bibliotheken und numerischen Ergebnissen relevant sein. Ein späteres automatisches Systemupdate kann eine zuvor funktionierende Kombination verändern. Legen Sie daher fest, ob Updates während Ihres Projekts automatisch erfolgen dürfen oder vorher angekündigt und geprüft werden müssen.

Testen Sie die drei Zugangsebenen getrennt:

1. Grafische Verbindung: Öffnen Sie die Anwendung, kopieren Sie eine kleine Datei und prüfen Sie, ob Menüs, Dialoge und Dateiauswahl zuverlässig bedienbar sind.
2. SSH: Melden Sie sich mit einem möglichst eingeschränkten Konto an, führen Sie einen harmlosen Prüf
   befehl aus und beenden Sie die Sitzung wieder.
3. SFTP oder vergleichbarer Dateitransfer: Übertragen Sie eine nicht sensible Testdatei in beide Richtungen und vergleichen Sie Dateiname, Größe und Prüfsumme.

Apple beschreibt die Einrichtung von Remote Login mit SSH und SFTP sowie die Konfiguration von Bildschirmfreigabe und VNC. Diese Dokumentation bestätigt, dass die technischen Zugangswege vorhanden sind. Sie bestätigt weder die Eignung Ihrer Forschungssoftware noch eine bestimmte Netzwerklatenz oder die Genehmigung Ihrer Hochschule.

Prüfen Sie die Rechte nach dem Prinzip der geringsten Berechtigung. Fragen Sie sich:

• Können Sie nur die für das Projekt benötigten Verzeichnisse erreichen?
• Ist ein Administratorkonto wirklich erforderlich?
• Wer kann den Rechner außer Ihnen betreten?
• Sind gemeinsam genutzte Konten und gespeicherte Zugangsdaten ausgeschlossen?
• Gibt es eine Regel für den Zugriff durch Supportpersonal?
• Wird der Rechner nach Ende der Nutzung zurückgesetzt?

Speichern Sie eine kurze Umgebungsdatei mit Systemversion, Architektur, Softwareversionen, Installationsquellen und Konfigurationsparametern. Lassen Sie sensible Werte weg. Diese Datei ist später wichtig, wenn ein Ergebnis nicht reproduzierbar ist oder ein anderes Mitglied der Arbeitsgruppe die Umgebung übernehmen soll.

In der ersten Stunde: macOS-Forschungssoftware mit einem Minimalbeispiel prüfen

Installieren Sie nicht sofort die gesamte persönliche Arbeitsumgebung. Beginnen Sie mit dem kleinsten Satz an Programmen, Bibliotheken und Erweiterungen, der für den Zielauftrag erforderlich ist. Bevorzugen Sie offizielle Installationspakete, vom Projekt bereitgestellte Paketquellen oder eine ausdrücklich dokumentierte Umgebungsdatei. Ungeprüfte Skripte aus Foren können nicht nur Abhängigkeiten verändern, sondern auch Zugangsdaten oder Forschungsdaten gefährden.

Verwenden Sie einen öffentlichen Beispieldatensatz oder eine vollständig anonymisierte Kopie. Das Beispiel muss mindestens vier Funktionen abdecken:

• Start der Anwendung und Laden der Projektdatei;
• Einlesen der vorgesehenen Dateiformate;
• Durchführung des zentralen Analyse- oder Verarbeitungsschritts;
• Speichern und erneutes Öffnen des Ergebnisses.

Setzen Sie nicht „Anwendung startet“ mit „Umgebung bestanden“ gleich. Ein Programm kann öffnen, aber beim Laden eines Plug-ins, beim Zugriff auf eine Bibliothek oder beim Export abbrechen. Prüfen Sie deshalb auch Protokolle, Warnungen und Dateirechte. Wenn die Software eine zufallsbasierte Berechnung enthält, speichern Sie den Zufallsstartwert. Bei numerischen Verfahren dokumentieren Sie Parameter, Versionen und Eingabedateien.

Die häufigsten Abbruchgründe liegen nicht beim macOS-Desktop selbst:

• Ein Plug-in wurde nur für Intel kompiliert und verhält sich auf Apple Silicon anders.
• Ein Lizenzdienst erkennt das Rechenzentrum oder die neue Geräteumgebung nicht.
• Eine Anwendung benötigt eine ältere Systemkomponente, die mit der aktuellen macOS-Version nicht mehr mitgeliefert wird.
• Der Benutzer darf zwar die Anwendung öffnen, aber nicht in das vorgesehene Projektverzeichnis schreiben.
• Die grafische Verbindung bricht bei großen Darstellungen ein, obwohl der Rechenprozess weiterläuft.

Bewerten Sie jeden Fehler nach drei Fragen: Ist die Ursache eindeutig? Lässt sie sich ohne Umgehung der Lizenz- oder Sicherheitsregeln beheben? Bleibt die Lösung nach einem Neustart und einer erneuten Anmeldung bestehen? Wenn eine dieser Fragen mit „Nein“ beantwortet wird, stoppen Sie die produktive Nutzung und wechseln Sie entweder die Systemvariante, die Softwareversion oder die gesamte Plattform.

Am selben Tag: Rechenweg, Fernbedienung und Wiederaufnahme getrennt bewerten

Jetzt folgt der entscheidende Test mit einem repräsentativen Auftrag aus Ihrer Publikation, Lehrveranstaltung oder Entwicklungsaufgabe. Wählen Sie nicht nur eine kleine Demo, sondern eine Aufgabe mit typischen Eingabedateien, realistischen Parametern und einem erwarteten Ergebnis. Verwenden Sie weiterhin nur freigegebene oder anonymisierte Daten.

Trennen Sie zwei Messgrößen:

• Rechenzeit auf dem Host: Wie lange benötigt die Software für Analyse, Konvertierung oder Export?
• Interaktionsqualität der Fernverbindung: Wie schnell reagiert die grafische Oberfläche, wie gut lassen sich große Ansichten bedienen und wie zuverlässig werden Tastatur- und Mausaktionen übertragen?

Eine verzögerte VNC- oder Bildschirmfreigabe ist kein Beweis für eine langsame CPU. Umgekehrt kann eine flüssige Oberfläche einen fehlerhaften oder unvollständigen Hintergrundprozess verdecken. Starten Sie deshalb, sofern möglich, einen Auftrag über die grafische Oberfläche und einen zweiten kontrolliert über SSH. Vergleichen Sie Protokoll, Endstatus und Ausgabedateien.

Prüfen Sie anschließend die Unterbrechung:

1. Starten Sie einen kurzen, wiederholbaren Analyseauftrag.
2. Trennen Sie die grafische Sitzung kontrolliert.
3. Stellen Sie die Verbindung erneut her.
4. Prüfen Sie, ob der Prozess weiterläuft, beendet wurde oder unvollständige Dateien hinterlassen hat.
5. Öffnen Sie die Ausgabe und vergleichen Sie sie mit dem erwarteten Ergebnis.
6. Wiederholen Sie den Dateitransfer in Richtung Ihres Arbeitsrechners.

Der Test ist nicht bestanden, wenn ein Verbindungsabbruch den Rechenprozess beendet, temporäre Dateien überschreibt oder den Status nicht nachvollziehbar macht. Verwenden Sie in diesem Fall einen wiederaufnehmbaren Arbeitsablauf, speichern Sie Zwischenergebnisse in klar benannten Verzeichnissen oder verlagern Sie den langen Batch-Prozess auf eine Plattform, die für diesen Zweck besser kontrolliert wird.

Hinweis aus der Praxis: Ein Remote Mac kann für interaktive Auswertung, Softwaretests und die letzte macOS-spezifische Verarbeitung sinnvoll sein, während Rohdaten, große Batch-Läufe oder gerätekritische Schritte auf der vorhandenen Hochschulinfrastruktur bleiben. Die geteilte Architektur ist oft sicherer als der Versuch, den gesamten Forschungsprozess auf einen einzigen Zugang zu zwingen.

Achten Sie auf die Dateiintegrität. Vergleichen Sie bei wichtigen Exporten Dateigröße, Änderungszeit und, wenn der Arbeitsablauf dies zulässt, eine Prüfsumme. Prüfen Sie, ob Sonderzeichen, lange Pfade und große Einzeldateien beim Transfer unverändert bleiben. Der Ergebnisexport ist erst bestanden, wenn Sie die Datei auf einem zweiten Rechner öffnen und fachlich plausibel prüfen können.

Vor dem produktiven Einsatz: Reproduzierbarkeit, Datenschutz und Zusammenarbeit absichern

Nutzen Sie für den Vergleich denselben Input auf Ihrer bisherigen Umgebung und auf dem Remote Mac. Identische Ergebnisse sind nicht in jedem wissenschaftlichen Verfahren bitgenau zu erwarten; Sie müssen deshalb vorher festlegen, welche Abweichung fachlich akzeptabel ist. Bei Bildern können Rendering und Farbdarstellung variieren, bei numerischen Verfahren können Bibliotheken und Rundungseinstellungen eine Rolle spielen.

Halten Sie mindestens diese Reproduktionsbedingungen fest:

• macOS-Version und Prozessorarchitektur;
• Name und Version der Zielsoftware;
• Plug-ins, Bibliotheken und Umgebungsdateien;
• Eingabedateien und relevante Dateiformate;
• Parameter, Filter und Konfigurationsdateien;
• Zufallsstartwerte;
• verwendetes Benutzerkonto und Lizenzmodus;
• erwartete Kennzahlen oder Vergleichsbilder.

Die Frage, ob sensible Forschungsdaten auf einen Remote Mac dürfen, lässt sich nicht pauschal mit „ja“ beantworten. Entscheidend sind Datenkategorie, Auftragsverarbeitung, Speicherort, Zugriffskontrolle, Verschlüsselung, Löschprozess und die Freigabe Ihrer Institution. Bei personenbezogenen oder klinischen Informationen reicht eine technische Verbindung nicht als Genehmigung. Verwenden Sie für die erste Abnahme ausschließlich öffentliche oder de-identifizierte Daten. Wenn die Hochschule keine externe Speicherung erlaubt, darf auch ein technisch geschützter Mietrechner nicht ohne weitere Freigabe produktiv eingesetzt werden.

Für die Zusammenarbeit testen Sie den vollständigen Ablauf mit einer zweiten Person. Lassen Sie diese Person anhand Ihrer Umgebungsbeschreibung:

• sich anmelden;
• die Zielsoftware finden;
• das Minimalbeispiel laden;
• einen festgelegten Auftrag starten;
• das Ergebnis exportieren;
• die relevanten Protokolle finden.

Wenn nur Ihr persönliches Konto und Ihr Gedächtnis den Ablauf reproduzierbar machen, ist die Umgebung noch nicht lieferfähig. Eine kurze README-Datei mit Installationsquelle, Startbefehl, Verzeichnissen, Lizenzhinweisen und bekannten Einschränkungen ist für eine Arbeitsgruppe wertvoller als ein allgemeiner Screenshot.

Vor dem Ablauf: Ergebnisse exportieren und die Mietentscheidung treffen

Beginnen Sie den Exit-Prozess nicht am letzten Nutzungstag. Exportieren Sie frühzeitig den Code, die Umgebungsdateien, Installationshinweise, Protokolle, Lizenzfreigaben und die finalen Forschungsergebnisse. Öffnen Sie die wichtigsten Dateien anschließend auf einem anderen Gerät. Ein Export, der nur auf dem Remote Mac lesbar ist, ist kein abgeschlossener Übergang.

Erstellen Sie eine Übergabeliste:

• Originaldaten und anonymisierte Arbeitskopien getrennt;
• Skripte und Konfigurationsdateien vollständig;
• Protokolle mit Zeitstempeln;
• Ergebnisdateien in einem zweiten System geöffnet;
• Lizenz abgemeldet oder für den nächsten Einsatz freigegeben;
• private Schlüssel, Tokens und gespeicherte Passwörter entfernt;
• temporäre Dateien und Cache-Verzeichnisse geprüft;
• Zugang für weitere Nutzer beendet;
• Löschung oder Zurücksetzung mit der zuständigen Stelle geklärt.

Apple dokumentiert die Funktion zum Löschen aller Inhalte und Einstellungen auf einem Mac. Diese Funktion zeigt, dass ein technischer Löschpfad existiert; sie ersetzt jedoch nicht die Vorgaben Ihrer Hochschule, einen vertraglich vereinbarten Löschbeleg oder eine Prüfung von Sicherungskopien. Verlangen Sie bei geschützten Projekten nach Möglichkeit eine Bestätigung, wie Konten, Daten und temporäre Kopien behandelt wurden.

Treffen Sie danach die Infrastrukturentscheidung:

• Weiter mieten, wenn die Zielsoftware offiziell oder nachweisbar stabil läuft, der repräsentative Auftrag bestanden ist, Ergebnisse exportierbar sind und der nächste Projektabschnitt zeitlich begrenzt bleibt.
• Auf die vorhandene Plattform zurückgehen, wenn der Mac nur für einen kleinen Konvertierungs- oder Kontrollschritt benötigt wurde und die Hauptanalyse auf Linux oder Windows zuverlässiger läuft.
• Einen physischen Mac beschaffen, wenn Ihre Arbeitsgruppe dauerhaft interaktiv arbeitet, lokale Peripherie benötigt oder wiederkehrende Mietzyklen organisatorisch aufwendiger werden.
• Eine gemischte Umgebung einsetzen, wenn macOS für Kompatibilität und grafische Anwendungen nötig ist, während große Batch-Berechnungen, Rohdatenhaltung oder gemeinsam verwaltete Pipelines besser auf der vorhandenen Infrastruktur bleiben.

Für einen zeitlich begrenzten Forschungsauftrag können Sie die Remote-Mac-Mietoptionen von VPSMAC anhand Ihres Projektzeitraums prüfen. Wenn Sie anschließend einen bestimmten verfügbaren Knoten für Ihre Arbeitsgruppe vergleichen möchten, finden Sie die Übersicht der bestellbaren M4-Knoten als zweiten Bezugspunkt. Die Entscheidung sollte aber erst nach dem Minimalbeispiel und dem repräsentativen Export fallen, nicht nach einem erfolgreichen Login.

Warum die Abnahme oft wichtiger ist als der Kaufpreis

Der direkte Kauf eines physischen Mac bindet Kapital, verlangt Beschaffung, Wartung und eine lokale Sicherheitsprüfung. Ein institutioneller Windows- oder Linux-Rechner spart diese Anschaffung, kann aber die benötigte macOS-Software, bestimmte Plug-ins oder die geforderte Plattform nicht bereitstellen. Ein Remote Mac liegt dazwischen: Er vermeidet den Kauf für ein kurzes Projekt, bringt aber laufende Mietkosten, Netzwerkabhängigkeit, Zugriffsverwaltung und eine zusätzliche Datenablage mit.

Die tatsächlichen Nachteile Ihrer bisherigen Lösung sollten Sie konkret benennen:

• Ein Windows- oder Linux-Arbeitsplatz kann die macOS-spezifische Anwendung nicht vollständig validieren.
• Ein zentraler Hochschulserver bietet möglicherweise keine grafische macOS-Umgebung und keine passenden Lizenzbedingungen.
• Ein einmaliger Kauf eines physischen Mac ist für eine kurze Reproduktion oder einen begrenzten Kompatibilitätstest möglicherweise organisatorisch und finanziell überdimensioniert.
• Eine lokale Lösung hilft nicht automatisch, wenn mehrere Arbeitsgruppenmitglieder kurzfristig dieselbe Umgebung benötigen.

Wenn dagegen Instrumente direkt angeschlossen werden müssen, die Verbindung zeitkritisch reagieren muss oder Ihre Datenrichtlinie externe Systeme ausschließt, ist eine Miete nicht die bessere Lösung. Für kurzfristige Tests, Lehrveranstaltungen, Reproduktionen und plattformübergreifende Prüfungen kann VPSMAC jedoch eine passendere Übergangslösung sein als ein ungeprüfter Kauf. Mieten Sie zunächst nur für den Zeitraum, in dem Ihr repräsentativer Auftrag, die Ergebnisprüfung und der Export tatsächlich stattfinden. Verlängern Sie erst, wenn die vier Stationen der Abnahme dokumentiert bestanden sind.