Wer in Deutschland Sage im Mittelstand einsetzt, kommt früher oder später an den Punkt, an dem der Standard nicht mehr alles abdeckt: eine branchenspezifische Preislogik, ein besonderer Freigabeprozess, eine Auswertung für die Geschäftsführung, die so in keinem Menü steht. Dann stellt sich die Frage nach der Sage Entwicklung: Was lässt sich konfigurieren, was erweitern, und was muss tatsächlich programmiert werden?
Diese Seite ordnet das Thema so, wie ein erfahrener Integrator es im ersten Gespräch tun würde: von der günstigsten und wartungsärmsten Lösung bis zur aufwendigsten. Sie hilft Ihnen, Sage anzupassen, ohne sich eine Sonderlösung einzukaufen, die jedes Update zum Risiko macht.
Die Faustregel: Anpassungsstufen von leicht bis schwer
Bei jeder Anforderung lohnt sich dieselbe Reihenfolge. Sie klären zuerst, ob der Standard das Problem bereits löst, und gehen nur dann eine Stufe weiter, wenn es wirklich nötig ist.
| Stufe | Was passiert | Wartungsaufwand | Risiko bei Updates |
|---|---|---|---|
| Parametrierung | Einstellungen, Stammdaten, Belegarten, Berechtigungen, Workflows | gering | sehr gering |
| Auswertungen und Formulare | eigene Listen, Berichte, Belegvorlagen | gering bis mittel | gering |
| Vorhandene Erweiterungen | fertige Zusatzmodule und Branchenlösungen | mittel | abhängig vom Anbieter |
| Schnittstellen | Anbindung von Shop, DATEV, Lagerautomation, Fachverfahren | mittel | mittel |
| Individualentwicklung | eigene Programmlogik und eigene Module nach Maß | hoch | am höchsten |
Je weiter unten Ihre Anforderung steht, desto mehr tragen Sie später selbst: Pflege, Tests, Dokumentation und Abhängigkeit von dem, der den Code geschrieben hat.
Parametrierung: der unterschätzte Hebel
Viele Wünsche, die zunächst nach Programmierung klingen, sind reine Konfiguration. Typische Beispiele im deutschen Mittelstand:
- Nummernkreise und Belegarten, die zu Ihrer Organisation passen
- Kostenstellen- und Kostenträgerstrukturen, die Ihr Controlling braucht
- Rollen und Berechtigungen, die zur Aufgabenteilung zwischen Buchhaltung, Einkauf und Vertrieb passen
- Zahlungsbedingungen, Mahnstufen und Skontoregeln
- Freigabeschritte für Bestellungen oder Eingangsrechnungen
Hier liegt die beste Relation aus Nutzen und Aufwand. Eine saubere Parametrierung ist außerdem der Teil der Einführung, der Updates am zuverlässigsten übersteht, weil er sich innerhalb dessen bewegt, was Sage vorsieht. Wie das im Projektablauf aussieht, beschreibt die Seite zur Einführung von Sage.
Vorhandene Erweiterungen und Module nutzen
Bevor jemand etwas neu baut, gehört die Marktfrage auf den Tisch: Gibt es für Ihren Anwendungsfall bereits ein Zusatzmodul oder eine Branchenlösung? Für viele Standardthemen existieren erprobte Erweiterungen, die andere Unternehmen schon im Einsatz haben. Der Vorteil: Der Anbieter pflegt sie über Versionswechsel hinweg, und Sie teilen sich die Entwicklungskosten mit anderen.
Prüfen Sie dabei nüchtern:
- Deckt die Erweiterung Ihre Anforderung wirklich ab, oder nur ungefähr?
- Wird sie aktiv weiterentwickelt und für Ihre Sage-Version freigegeben?
- Wer leistet Support, wenn sie nach einem Update nicht mehr läuft?
- Welche Lizenz- und Wartungskosten fallen laufend an?
Einen Überblick über das, was bereits im Produktumfang steckt, finden Sie unter Sage Module. Wie sich Funktionsumfang und Möglichkeiten je nach Edition unterscheiden, erklärt die Seite zu Versionen und Editionen.
Schnittstellen statt Eingriff in den Kern
Ein großer Teil dessen, was als „Entwicklung" bestellt wird, ist in Wahrheit Anbindung: der Webshop, der Aufträge liefert, das Lagersystem, das Bestände zurückmeldet, der Datenaustausch mit dem Steuerberater über DATEV, der Abruf eingehender E-Rechnungen im Format XRechnung oder ZUGFeRD. Solche Anbindungen sind bewusst außerhalb des Kerns angelegt. Das ist der entscheidende Vorteil: Das Sage-System bleibt am Standard, die Logik sitzt in einer eigenen, austauschbaren Schicht.
Wer zwischen Eingriff in den Kern und Schnittstelle wählen kann, sollte fast immer die Schnittstelle nehmen. Mehr dazu auf der Seite zu Schnittstellen und Connectoren.
Individualentwicklung: wann sie berechtigt ist
Es gibt Anforderungen, die weder Konfiguration noch fertige Erweiterung erfüllen. Dann ist eine Individualentwicklung für Sage der richtige Weg, etwa wenn:
- Ihr Geschäftsmodell eine Berechnungslogik verlangt, die kein Standardprodukt kennt (zum Beispiel komplexe Konditionssysteme im Großhandel oder projektbezogene Abrechnungslogiken)
- ein Prozess wettbewerbsentscheidend ist und sich nur so abbilden lässt, wie Ihr Unternehmen ihn lebt
- ein branchenspezifisches Fachverfahren eng mit der Auftrags- oder Fertigungsabwicklung verzahnt werden muss
Entscheidend ist die Begründung. „Das haben wir immer so gemacht" ist kein Grund für Code. „Dieser Ablauf unterscheidet uns im Markt, und der Standard bildet ihn nicht ab" ist einer.
Sprache und Werkzeuge
Welche Programmiersprache, welche Entwicklungsumgebung und welche Programmierschnittstellen für ein Sage-Modul nach Maß zum Einsatz kommen, hängt vom konkreten Produkt und von der Version ab. Das ist keine Floskel: Sage umfasst unterschiedliche Produktlinien mit unterschiedlicher technischer Basis. Fragen Sie deshalb jeden Anbieter konkret, womit er für Ihre Version entwickelt, ob dafür die vorgesehenen Schnittstellen genutzt werden und wie er Kompatibilität bei Versionswechseln sicherstellt. Wer darauf nicht präzise antworten kann, kennt Ihr Produkt nicht gut genug.
Was Anpassungen mit Updates machen
Hier liegt der wichtigste Kostentreiber über die Jahre. Jede Abweichung vom Standard muss bei einem Versionswechsel erneut geprüft werden. Je näher eine Anpassung am Kern sitzt, desto größer ist das Risiko, dass sie nach einem Update nicht mehr läuft oder falsche Ergebnisse liefert.
Das betrifft besonders Bereiche mit gesetzlichen Anforderungen. Wenn sich Vorgaben zur E-Rechnung ändern oder Anforderungen aus den GoBD verschärft werden, liefert Sage Anpassungen im Standard. Eine Individualentwicklung, die Belege oder Buchungslogik verändert, muss dann von Ihnen oder Ihrem Entwickler nachgezogen werden. Zur revisionssicheren Archivierung und Nachvollziehbarkeit lesen Sie den Beitrag zu GoBD im ERP.
Planen Sie deshalb von Beginn an ein, dass jede Individualentwicklung laufende Pflege braucht. Wie Support und Wartung im Alltag organisiert werden können, steht auf der Seite Sage Support und Wartung.
Bewährte Praktiken: rein, getestet, dokumentiert
Aus Projekten im Mittelstand haben sich einige Regeln herausgebildet, die den Unterschied zwischen einer tragfähigen und einer belastenden Anpassung ausmachen.
Beim Standard bleiben
Jede Anforderung zuerst gegen den Standard prüfen. Manchmal ist es klüger, einen Prozess im Unternehmen leicht zu ändern, als das System dauerhaft zu verbiegen. Ein guter Integrator sagt das auch dann, wenn er an der Programmierung mehr verdienen würde.
Anforderungen schriftlich festhalten
Jede Anpassung braucht eine klare Beschreibung: Was soll passieren, in welchem Fall, mit welchem Ergebnis? Ein sauberes Lastenheft verhindert Streit über den Leistungsumfang und gibt dem Entwickler eine prüfbare Grundlage.
Getrennte Systeme für Test und Betrieb
Neue Funktionen gehören zuerst in ein Testsystem mit realistischen Daten, abgenommen von den Fachabteilungen, nicht nur von der IT. Erst danach geht eine Änderung in den Produktivbetrieb. Das gilt für kleine Korrekturen genauso wie für größere Module.
Alles dokumentieren
Dokumentiert werden sollten Zweck, Funktionsweise, Abhängigkeiten, betroffene Tabellen oder Objekte, Ansprechpartner und der Stand der Version, für die die Anpassung getestet wurde. Ohne diese Unterlagen hängt Ihr Unternehmen an einer einzigen Person.
Rechte und Quellcode klären
Im Vertrag steht, wem Quellcode und Dokumentation gehören, welche Nutzungsrechte bestehen und wie Sie im Ausfallfall an den Code kommen. Das ist kein Misstrauen, sondern Risikovorsorge.
Versionswechsel planen
Vor jedem größeren Update steht ein Regressionstest aller Anpassungen. Legen Sie fest, wer ihn durchführt, wer ihn bezahlt und wie lange Sie dafür das System anhalten dürfen.
So beurteilen Sie einen Sage-Entwickler oder Integrator
Nicht jeder, der Sage kennt, kann gut anpassen, und nicht jeder gute Programmierer versteht Buchhaltung, Warenwirtschaft und Steuerrecht. Folgende Fragen trennen die Anbieter schnell.
| Frage | Gute Antwort | Warnsignal |
|---|---|---|
| Wie gehen Sie mit einer neuen Anforderung um? | Erst Prozess verstehen, dann Standard prüfen, dann Optionen aufzeigen | sofortiger Code-Vorschlag |
| Welche Version und welches Produkt kennen Sie im Detail? | konkrete Projekte mit Ihrer Produktlinie | allgemeine „ERP-Erfahrung" |
| Wie testen Sie? | getrennte Testumgebung, Abnahme durch die Fachabteilung | „Das probieren wir live" |
| Wie dokumentieren Sie? | nachvollziehbare Unterlagen zu jeder Änderung | mündliche Zusagen |
| Wie sieht es mit Updates aus? | Regressionstest als fester Bestandteil | „Das sehen wir dann" |
| Wem gehört der Code? | klare vertragliche Regelung | ausweichende Antwort |
| Kennen Sie deutsche Anforderungen? | DATEV, E-Rechnung, GoBD, Steuerberaterabstimmung | nur allgemeine Aussagen |
Bitten Sie außerdem um Gespräche mit Anwendern, die ähnliche Anpassungen im Einsatz haben. Und achten Sie darauf, ob der Anbieter auch Nein sagt: Wer jede Wunschliste bestätigt, hat meist nicht verstanden, was sie später kostet. Wie Sie bei der Auswahl insgesamt vorgehen, beschreibt die Seite Sage Integrator wählen.
Wenn bereits viel angepasst wurde
Viele Unternehmen sind nicht am Anfang, sondern haben über Jahre Anpassungen angesammelt, deren Urheber nicht mehr verfügbar sind oder deren Dokumentation fehlt. In diesem Fall hilft zunächst eine Bestandsaufnahme: Welche Anpassungen existieren, welche werden tatsächlich genutzt, welche lassen sich durch Standardfunktionen ersetzen, welche sind kritisch? Das Vorgehen dazu beschreibt die Seite zum Audit und zur Projektübernahme bei Sage.
Hilfreich ist auch ein Blick auf den lokalen Kontext: Wie sich Sage im deutschen Markt positioniert und was das für Anpassungen bedeutet, steht unter Sage in Deutschland.
Fazit: so viel wie nötig, so wenig wie möglich
Eine gute Sage Entwicklung ist selten die größte, sondern die kleinste, die Ihr Ziel erreicht. Parametrieren Sie, wo es geht, nutzen Sie vorhandene Erweiterungen, binden Sie Fremdsysteme über Schnittstellen an und programmieren Sie nur, wo Ihr Geschäft es wirklich verlangt. Halten Sie jede Anforderung schriftlich fest, testen Sie getrennt, dokumentieren Sie lückenlos und regeln Sie die Rechte am Code im Vertrag.
Wenn Sie einen Integrator suchen, der Ihre Anforderungen sachlich einordnet, stellen wir über unsere kostenlose Vermittlung den Kontakt zu einem geeigneten Partner her. Der Integrator setzt das Projekt um, wir vermitteln nur.
Häufige Fragen
Was kostet eine Sage Entwicklung?
Eine seriöse Zahl lässt sich ohne Anforderungsanalyse nicht nennen. Der Aufwand hängt davon ab, ob Sie nur parametrieren, eine vorhandene Erweiterung einsetzen oder echten Code benötigen, und wie tief der Eingriff in Ihre Abläufe geht. Lassen Sie sich Aufwand je Anforderung getrennt ausweisen und fragen Sie nach den Folgekosten für Pflege und Updates.
Wie viel lässt sich in Sage ohne Programmierung anpassen?
Oft mehr, als Unternehmen zunächst vermuten: Stammdaten, Nummernkreise, Belegarten, Berechtigungen, Auswertungen und Workflows sind häufig reine Konfiguration. Welche Möglichkeiten genau bestehen, hängt von Produkt, Edition und Version ab. Prüfen Sie jede Anforderung zuerst gegen diese Optionen, bevor Sie eine Programmierung beauftragen.
Werden Individualanpassungen bei Sage-Updates überschrieben?
Das hängt von der Art der Anpassung. Saubere Erweiterungen, die über vorgesehene Schnittstellen andocken, überstehen Updates in der Regel besser als Eingriffe in den Standardcode. Verlangen Sie vom Entwickler, dass er vor jedem Versionswechsel einen Regressionstest seiner Anpassungen durchführt und dokumentiert.
Wem gehört der Quellcode eines Sage-Moduls nach Maß?
Das regelt allein der Vertrag. Halten Sie schriftlich fest, ob Sie den Quellcode erhalten, welche Nutzungsrechte gelten und was passiert, wenn der Entwickler nicht mehr zur Verfügung steht. Ohne diese Klärung entsteht eine Abhängigkeit, die sich später nur teuer auflösen lässt.
Woran erkenne ich einen guten Sage-Entwickler oder Integrator?
Er fragt zuerst nach dem Prozess und schlägt, wo möglich, den Standard vor. Er kann Referenzen zu vergleichbaren Anpassungen nennen, arbeitet mit getrennten Test- und Produktivsystemen und dokumentiert jede Änderung nachvollziehbar. Wer jede Anforderung sofort mit Code beantwortet, verkauft Ihnen vor allem künftigen Wartungsaufwand.
Die genannten Softwarenamen sind Marken der jeweiligen Hersteller und dienen ausschließlich der Information. Diese Website ist unabhängig und steht in keiner Verbindung zu den Herstellern.