Der Code, der dort beginnt, wo der Standard aufhört.

Reports, Masken und Formulare

Die Reports, die jemand jeden Morgen öffnet, die Erfassungsmasken, die Druckausgaben, die Nachtjobs. Wir richten die Entwicklung danach aus, wie die Person tatsächlich arbeitet, und entwerfen die Maske als Teil eines Arbeitsablaufs statt als technische Notwendigkeit.

Ob ein objektorientierter oder ein klassischer Ansatz besser passt, entscheiden wir anhand der vorhandenen Codebasis und dessen, was das Team des Kunden künftig pflegen kann.

Erweiterung des Standards

Beim Eingriff in einen Standardablauf ist die Wahl des richtigen Punktes meist wichtiger als der Code. Ein Eingriff an der falschen Stelle bricht beim ersten Release-Wechsel; einer an der richtigen fällt jahrelang niemandem auf.

Jede Regel, die sich ändern kann, landet in einer pflegbaren Tabelle statt im Code. Regeln, die je Gesellschaft, Land oder Produktgruppe abweichen, lassen sich so ohne Entwickler steuern.

Integration zwischen SAP-Systemen

Datenflüsse zwischen verschiedenen SAP-Systemen desselben Konzerns, zwischen getrennten Gesellschaften oder zwischen Alt- und Neusystem während einer Umstellung. Stammdatenabgleich, Belegübertragung und Abstimmberichte gehören standardmäßig dazu.

Jeder Fluss, den wir bauen, ist nachvollziehbar: Welcher Beleg wann übertragen wurde, welcher fehlgeschlagen ist und wie ein Fehler nachbearbeitet wird, ist von Anfang an mitgedacht. Ein Beleg, der stillschweigend verschwindet, ist der teuerste Fehler einer Schnittstelle.

Integration mit Nicht-SAP-Anwendungen

Hier liegt der Schwerpunkt. Wir bringen SAP mit Fertigungsleitsystemen, Laborsoftware, Lager- und Logistikanwendungen, E-Rechnungsdiensten, Bankschnittstellen, E-Commerce-Plattformen, Reportingwerkzeugen und mit dem, was das Unternehmen selbst entwickelt hat, ins Gespräch.

Bevor wir die Verbindung bauen, schreiben wir den Vertrag: Welches Ereignis erzeugt welchen Beleg, wie werden die Felder abgebildet, was geschieht, wenn die Gegenstelle nicht antwortet, und wann ist ein erneutes Senden gefahrlos. Eine Schnittstelle, die vor diesen Antworten entsteht, legt beim ersten Ausfall das Geschäft still.

Technisch entscheiden wir anhand dessen, was die Gegenstelle tatsächlich kann: servicebasierte Verbindung, Datei- oder Ordneraustausch, Datenbankanbindung oder Nachrichtenwarteschlange. Authentifizierung, Verschlüsselung und Protokollierung gehören immer zum Umfang.

Datenübernahme und Massenverarbeitung

Daten ins System zu bekommen ist eine eigene Ingenieursaufgabe. Bei einmaligen Übernahmen wie bei nächtlichen Läufen achten wir auf dieselben drei Dinge: Validierung, Umgang mit Teilerfolgen und die Möglichkeit, von vorn neu zu starten.

Statt Rohdaten so zu laden, wie sie kommen, schicken wir sie zuerst durch Prüfungen. Einen fehlerhaften Datensatz gar nicht erst hereinzulassen ist immer günstiger, als ihn später zu bereinigen.

Performanceoptimierung und Übergabe

In jahrelang gewachsenen Systemen ist das die häufigste Anfrage: Jobs, die nicht mehr ins Nachtfenster passen, Masken, die minutenlang aufbauen, Reports, die mit wachsendem Datenbestand langsamer werden. Wir messen, bevor wir den Code anfassen — Optimierung ohne Messung ist Raterei.

Ob wir den Code geschrieben oder übernommen haben: Wir hinterlassen ihn so, dass ein anderes Team ihn pflegen kann. Code-Review, Namenskonventionen und Dokumentation sind für uns keine Zusatzleistung, sondern die Arbeit selbst.