Nicht möglichst viel programmieren. Die richtige Architektur bauen.
Sage 100 an den Prozess anpassen – auf der richtigen technischen Ebene
Nicht jede fachliche Lücke verlangt eine Individualentwicklung. Manchmal reicht eine Einstellung im Standard, manchmal ist der AppDesigner ideal – und manchmal braucht es .NET, SQL, eine API oder eine eigenständige Anwendung.
Diese Entscheidung prägt Wartbarkeit, Performance und Updatefähigkeit. Deshalb beginnt ein gutes Projekt nicht mit einer Maske, sondern mit dem Verständnis von Prozess, Daten und Systemgrenzen.
Was mit dem AppDesigner möglich ist
Der AppDesigner spielt seine Stärke dort aus, wo sich ein individueller Ablauf natürlich in Sage 100 einfügen soll. Aus einer einfachen Auskunft kann durch Aktionen, Prüfungen und Folgeprozesse ein echtes Arbeitswerkzeug werden.
Vom zusätzlichen Feld zur integrierten Fachanwendung
Die Spannweite reicht von einer kleinen Ergänzung bis zur Fachlösung mit eigenem Datenmodell. Entscheidend ist, dass die Erweiterung zum täglichen Arbeitsablauf passt – nicht, wie spektakulär die Technik dahinter wirkt.
Zusatzdaten, Freigaben, Preislogik, Disposition oder branchenspezifische Erfassung.
Geführte Kontrollen, ergänzende Buchungsinformationen und nachvollziehbare Verarbeitung.
Kontakte, Anlagen, Servicefälle und Aufgaben in einer gemeinsamen Arbeitssicht.
Individuelle Logik dort, wo der allgemeine ERP-Standard bewusst endet.
AppDesigner, .NET und SQL sinnvoll kombinieren
Komplexe Lösungen werden robuster, wenn jede Aufgabe in der passenden Schicht liegt. Die Oberfläche führt den Anwender, .NET kapselt anspruchsvolle Logik, Sage-Geschäftslogik schützt fachliche Regeln und SQL liefert Daten effizient.
Lange Läufe gehören nicht in eine blockierende Benutzeraktion. Import, Berechnung oder Synchronisation lassen sich bei Bedarf entkoppeln, protokollieren und kontrolliert wiederholen. So bleibt die Oberfläche reaktionsfähig und der Betrieb nachvollziehbar.
Datenmodell vor Oberfläche
Eine Maske lässt sich schnell zeichnen. Ob die Lösung später trägt, entscheidet aber ihr Datenmodell. Ein zusätzliches Feld ist ideal für eine einzelne Information; eigene Tabellen sind richtig, wenn Beziehungen, Historien oder Zustände entstehen.
API, Schnittstelle oder externe Anwendung?
Nicht jede Aufgabe gehört in den Sage-Client. Für Portale, mobile Nutzung, umfangreiche Integration oder abweichende Bedienkonzepte kann eine externe Anwendung die sauberere Lösung sein.
Direkte Schreibzugriffe auf die Sage-Datenbank vermeiden wir grundsätzlich, wenn dadurch Geschäftslogik oder Folgeverarbeitung umgangen würde. Wie eine Integration belastbar aufgebaut wird, zeigen wir auch unter Sage 100 Schnittstellen.
Qualität ist Teil der Entwicklung
Eine Erweiterung ist erst dann fertig, wenn sie im Alltag stabil betrieben, aktualisiert und verstanden werden kann.
Bei bestehenden Engpässen ergänzen wir die Entwicklung um eine gezielte Performanceanalyse. Vor Updates oder einer Migration prüfen wir technische Abhängigkeiten rechtzeitig.
Quellcode als echtes Qualitätsmerkmal
Unsere Individualentwicklungen liefern wir grundsätzlich vollständig im Sourcecode aus. Der Quellstand wird mit Git in einer DevOps-Umgebung versioniert – nicht nur als technische Ablage, sondern als fester Bestandteil unserer Qualitätssicherung.
Das ist mehr als eine formale Übergabe. Sourcecode, Versionshistorie und dokumentiertes Deployment machen aus einer funktionierenden Anpassung eine langfristig beherrschbare Softwarelösung.
Bestehende Anpassungen übernehmen
Eine fremde oder historisch gewachsene Lösung muss nicht automatisch neu gebaut werden. Zuerst klären wir Struktur, Datenmodell, Abhängigkeiten, Quellstand und Deployment. Daraus entsteht eine wirtschaftliche Entscheidung.
Unsere Entwicklungsprinzipien
So entsteht eine Individualentwicklung
Agil entwickeln – kaufmännisch steuerbar bleiben
Agile Entwicklung bedeutet für uns nicht, ein Projekt ohne festes Ende zu beginnen. Sie bedeutet, ein großes Vorhaben in kleine, überprüfbare Investitionsentscheidungen zu zerlegen. Zielbild, Budgetrahmen, Verantwortlichkeiten und Erfolgskriterien werden zu Beginn gemeinsam festgelegt. Innerhalb dieses Rahmens wird konsequent nach Geschäftsnutzen priorisiert.
Am Ende jedes vereinbarten Arbeitsabschnitts sehen Entscheider und Key User funktionierende Software statt abstrakter Fortschrittsmeldungen. Gemeinsam prüfen wir Ergebnis, verbrauchtes Budget, offene Risiken und den noch erwarteten Nutzen. Erst danach wird der nächste Abschnitt priorisiert und freigegeben.
Neue Anforderungen dürfen entstehen – sie werden aber nicht unbemerkt auf den Projektumfang addiert. Ein neuer Wunsch ersetzt entweder eine weniger wichtige Position im Backlog oder wird mit seinen Auswirkungen auf Budget und Termin bewusst entschieden. Dadurch bleiben Umfang und Kosten sichtbar, während fachliche Erkenntnisse trotzdem früh einfließen können.
Entwicklung im direkten Austausch mit den Stakeholdern
Fachverantwortliche, Key User und Management werden passend zu ihrer Rolle eingebunden: Entscheider sichern Ziel, Priorität und Budget; Key User prüfen Bedienung und fachliche Sonderfälle; unser Entwicklungsteam verantwortet Architektur, technische Qualität und eine realistische Aufwandseinschätzung. Offene Punkte und Risiken werden nicht bis zum Projektende gesammelt, sondern im gemeinsamen Takt geklärt.
Unsere besondere Stärke liegt dabei zwischen Fachbereich und Technologie. Wir verstehen betriebswirtschaftliche Abläufe in Warenwirtschaft, Rechnungswesen, xRM und Service und kennen zugleich Sage-100-Standard, AppDesigner, .NET, SQL und Schnittstellen. Dadurch entfallen viele Übersetzungsschleifen. Wir erkennen früh, was konfiguriert werden kann, was wirklich entwickelt werden muss und welche Lösung dauerhaft wirtschaftlich bleibt.
Warum Appontes?
Wir verbinden die Sicht auf den Geschäftsprozess mit der technischen Tiefe, die eine langlebige Sage-100-Lösung braucht.