Softwareentwicklung für Heidelberg

Rund um Heidelberg arbeiten viele Organisationen, deren Ergebnis kein physisches Produkt ist: Universität und Universitätsklinikum, außeruniversitäre Institute, Biotechnologie im Neuenheimer Feld, wissenschaftsnahe Verlage und Dienstleister, die für all diese Häuser zuarbeiten. In einem Fertigungsbetrieb begleitet die Software ein Werkstück. Hier sind die Daten selbst das Ergebnis, und ihre Herkunft muss überprüfbar bleiben.

Praktisch heißt das: Jede Zahl in einem Zwischenbericht muss sich auf den Datensatz zurückführen lassen, aus dem sie stammt, samt Stand und Bearbeiter. Ein System, das nur den aktuellen Wert kennt, beantwortet eine Rückfrage aus einer Prüfung nicht. Es zeigt, was heute gilt, und schweigt darüber, was im März galt, als der Bericht rausging.

Wir entwickeln solche Systeme mit festangestellten Entwicklern in Deutschland. Der Quellcode gehört dem Auftraggeber ab dem ersten Commit, der Betrieb läuft auf Servern in Deutschland oder der EU. Für Häuser, die eine Auftragsverarbeitung nach Artikel 28 DSGVO dokumentieren müssen, spart das eine Zeile im Risikoregister und eine Diskussion mit dem Datenschutzbeauftragten.

Nachweispflichten scheitern selten am Willen, sondern an der Bauweise. Wenn Auskunft, Löschung und Archivierung nur über direkte Eingriffe in die Datenbank möglich sind, ist die Pflicht einmal erfüllt und beim nächsten Mal wieder ein Sonderfall. Diese Punkte gehören deshalb in die Anforderungsliste, bevor die erste Maske entsteht.

Pseudonymisierung ist keine Anonymisierung. Solange der Zuordnungsschlüssel existiert, bleiben die Daten personenbezogen und fallen vollständig unter die DSGVO. Wer beides in einem Projektantrag gleichsetzt, bekommt die Rückfrage spätestens bei der Prüfung.

Eine Grenze dieser Bauweise gehört dazu: Ein sauber protokolliertes System macht sichtbar, wer wann welchen Wert geändert hat. Das ist in einer Prüfung der Vorteil und im Arbeitsalltag zunächst eine Zumutung, weil Korrekturen sichtbar bleiben, die vorher niemand gesehen hat. Wer die Protokollierung einführt, ohne vorher mit dem Personalrat und den betroffenen Bereichen zu klären, wer welche Auswertung sehen darf, bekommt das Thema nach dem Go-live zurück.

Ein Bericht ist belastbar, wenn er sich mit demselben Stichtag ein Jahr später identisch reproduzieren lässt. Das gelingt nur, wenn die Auswertungslogik versioniert ist und die zugrunde liegenden Datenstände rückwirkend unangetastet bleiben. Auswertungen rechnen deshalb auf einem festgehaltenen Stand, den ein späterer Import nicht mehr verändert.

Das hat einen Preis, den man vorher kennen sollte: Ein Fehler in Altdaten lässt sich dann nicht mehr still korrigieren. Jede Berichtigung erzeugt eine zusätzliche Version, und alte Berichte behalten die alten Zahlen. Wer lieber immer die aktuelle Wahrheit sehen möchte, bekommt keine reproduzierbaren Berichte. Beides zugleich gibt es nicht, und die Entscheidung fällt in der Analysephase, nicht beim ersten Prüfungstermin.

Bei mexxenergie, einem Energiedienstleister in Baden-Württemberg, haben wir dieses Prinzip an einer Migration im laufenden Betrieb durchgehalten: Vor und nach jedem Übernahmelauf standen Abgleichszahlen, die zeigen, welche Datensätze übernommen wurden und welche liegen blieben. Der Mechanismus trägt genauso, wenn es um Probenreihen, Fördermittelabrufe oder Verbrauchsreihen geht.

• Stichtagsauswertungen, die auf eingefrorenen Ständen rechnen
• Änderungshistorie je Datensatz mit Zeitpunkt, Nutzer und vorherigem Wert
• Exporte nach CSV und Excel, die dieselben Zahlen liefern wie die Bildschirmansicht
• Schnittstellen zu vorhandenen Systemen, damit dieselbe Zahl nicht an zwei Stellen gepflegt wird

Unser Sitz ist St. Leon-Rot, zwischen Heidelberg und Karlsruhe. Im Alltag eines Softwareprojekts ändert diese Nähe wenig. Anforderungen werden schriftlich festgehalten, Zwischenstände laufen über eine Testumgebung, Rückfragen über Ticket und Telefon. Ein Anbieter aus Hamburg arbeitet in diesen Phasen genauso gut, und jede Standortseite, die Nähe zum Hauptargument macht, verschweigt das.

Es bleiben die Termine, bei denen der Weg tatsächlich zählt.

• Die Analysephase, wenn jemand danebensitzen muss, während ein Sachbearbeiter zeigt, wie er die Liste heute wirklich führt
• Die Abnahme, weil Fehlbedienungen im Videocall unsichtbar bleiben
• Die Schulung nach dem Go-live, bei der Rückfragen zwischen den Schreibtischen entstehen

Für diese Termine sind wir im Rhein-Neckar-Raum ohne Reisetag vor Ort. Eine Heidelberger Referenz steht auf dieser Seite trotzdem nicht: Die Projekte, die wir zeigen dürfen, liegen an anderen Orten in Baden-Württemberg und darüber hinaus.

Der Rahmen hängt daran, wie viele Fremdsysteme angebunden werden müssen und wie streng die Nachweisanforderungen sind. Ein abgegrenztes Fachsystem für eine Abteilung liegt anders als eine Plattform, die Daten aus Fachanwendungen, Buchhaltung und Antragsverwaltung zusammenführt.

Dazu kommt die Betreuung nach dem Go-live mit 12 bis 18 Prozent der Projektsumme pro Jahr. Darin stecken Sicherheitsaktualisierungen, Anpassungen an geänderte Vorgaben und ein benannter Ansprechpartner, der das Projekt von Anfang an kennt.

Arbeiten Sie mit öffentlichen Auftraggebern?

Wir liefern die Unterlagen, die in Vergabeverfahren üblicherweise verlangt werden, und richten uns nach den Vertragsbedingungen, die der Auftraggeber vorgibt. Angaben zu Rahmenverträgen oder Präqualifikationen machen wir hier nicht, weil sie sich von Haus zu Haus unterscheiden und im Einzelfall zu prüfen sind.

Können wir das System später selbst weiterentwickeln?

Ja. Der Quellcode gehört Ihnen ab Tag eins, Dokumentation und Deployment-Anleitung gehören zum Lieferumfang. Ein Wechsel zu einem anderen Dienstleister oder in die eigene IT-Abteilung ist damit möglich, ohne dass Daten neu erfasst werden müssen. Ehrlich dazu: Wer weiterentwickeln will, braucht Leute, die den Stack beherrschen. Wenn diese Rolle intern nicht besetzt ist, hilft der Codebesitz allein nicht weiter.

Wie lange dauert ein Projekt?

Analyse und Feinkonzept brauchen ein bis drei Wochen, die Entwicklung läuft in Zwei-Wochen-Takten über sechs bis zwanzig Wochen, Datenmigration und Tests zwei bis vier Wochen, Go-live und Schulung ein bis zwei Wochen. Die größte Unsicherheit liegt fast immer in der Migration, weil Altdaten selten so sauber sind, wie die Dokumentation behauptet.

• Individualsoftware im Überblick
• Schnittstellen zu vorhandenen Systemen
• Ablauf und Kosten
• Projekt mexxenergie
• Vertrauen und Sicherheit