Leistungen

Die drei Felder hängen zusammen. Ich beginne dort, wo Ihr Vorhaben gerade steht: mit einem Bestand, einer offenen Frage oder einem Ziel, das noch keinen Weg hat. Daraus entsteht ein Vorschlag, der zu Ihrem Betrieb passt — nicht ein Katalog, aus dem Sie auswählen. Welches Feld zuerst gebraucht wird, klärt ein erstes Gespräch. Manchmal ist die Antwort kleiner als erwartet: ein Review, ein Prototyp oder ein klarer Schnitt.

Auftragsentwicklung

Auftragsentwicklung heißt: Ein Vorhaben bekommt eine Form, die zu Ihrem Betrieb passt. Nicht das größtmögliche System, sondern das kleinste, das die Aufgabe trägt und sich weiterentwickeln lässt. Der Ablauf beginnt mit einem Blick auf den Bestand, dann folgt ein Prototyp für den kritischsten Teil, danach die schrittweise Fertigstellung.

Typische Aufgaben

• Web-Anwendungen: Portale für Kunden, interne Werkzeuge und Oberflächen für Abläufe, die heute in Tabellen und E-Mails liegen.
• Schnittstellen zwischen bestehenden Systemen: Daten austauschen, Zustände abgleichen und Fehler sichtbar machen, statt sie zu verstecken.
• Datenbankentwurf und -migration: ein Modell, das mitwächst, und ein Umzug der vorhandenen Daten mit prüfbaren Zwischenschritten.
• Erweiterung von Client/Server-Anwendungen: neue Funktionen in einem Bestand, der währenddessen weiterläuft.
• Werkzeuge für wiederkehrende Aufgaben: Auswertungen, Abgleiche und Berichte, die heute von Hand entstehen.
• Ablösung von Tabellenlösungen: ein Ablauf bekommt eine Anwendung, ohne dass die vertrauten Daten verloren gehen.

Was Sie davon haben: Ein Werkzeug, das den Ablauf abbildet, statt ihn zu behindern. Sie können nachvollziehen, welche Daten wann wohin gehen, und Fehler zuordnen, statt sie zu erraten.

Ergebnis: Software, die im Betrieb besteht — installiert, dokumentiert und übergeben.

Architektur & Modernisierung

Ein System wird nicht dadurch besser, dass man es neu schreibt. Oft ist der Bestand wertvoll; die Aufgabe ist, ihn zu ordnen und in eine Form zu bringen, die weitere Jahre trägt. Das gilt besonders, wenn der Betrieb während der Veränderung weiterlaufen muss. Ich trenne dabei, was kurzfristig entlastet und was langfristig trägt.

Typische Aufgaben

• Bestandsaufnahme: Komponenten, Datenflüsse, Abhängigkeiten und Engpässe — bevor über Ersatz gesprochen wird.
• Zielarchitektur: Entscheidungen zu Aufbau, Datenhaltung, Schnittstellen und Betrieb, begründet und dokumentiert.
• Migrationspfad in Etappen: Reihenfolge, Übergänge und Rückfallwege, damit jeder Schritt einzeln prüfbar ist.
• Architektur-Review: eine zweite Meinung zu einem Entwurf, bevor gebaut wird.
• Umgang mit technischen Schulden: priorisieren, tilgen, wo es sich lohnt, und den Rest bewusst dokumentieren.

Was Sie davon haben: eine begründete Zielarchitektur und einen Weg dorthin, den Sie in Etappen gehen können. Sie wissen vorher, was ein Schritt verändert und was er voraussetzt — auch im Betrieb.

Ergebnis: ein Plan, der ohne mich lesbar bleibt — mit Diagrammen, Entscheidungen und offenen Punkten.

Beratung

Manche Fragen brauchen keinen Code, sondern eine belastbare Einschätzung. Beratung heißt hier: eine Entscheidung vorbereiten, nicht abnehmen. Die Grundlage sind Ihr Vorhaben, Ihre Grenzen und die Alternativen, die tatsächlich zur Verfügung stehen. Die Grenze zur Entwicklung ist fließend; ich sage vorher, was ich selbst umsetzen kann und was nicht.

Typische Aufgaben

• Machbarkeit prüfen: Geht das, mit welchen Annahmen, und wo liegen die Grenzen?
• Technologieauswahl: Alternativen vergleichen, Kriterien offenlegen und eine Empfehlung begründen.
• Begleitung von Vorhaben: regelmäßig prüfen, ob Richtung, Umfang und Aufwand noch stimmen.
• Zweite Meinung: ein Konzept, ein Angebot oder eine Architektur gegenlesen, bevor Sie sich binden.

Was Sie davon haben: eine Empfehlung mit Begründung und Alternativen, nicht nur ein Ja oder Nein. Sie können die Entscheidung vor Ihrem Team und Ihrer Geschäftsführung vertreten.

Ergebnis: eine dokumentierte Entscheidung, auf der Sie aufbauen können — auch wenn ich nicht weiter mitwirke.

Herkunft

EnBeZ kommt aus der klassischen IT-Beratung. Netzwerke, Server, Telekommunikation und Schulungen gehörten zum Alltag, bevor der Schwerpunkt auf Software und Architektur lag. Diese Herkunft hilft bis heute: Ich sehe ein Vorhaben nicht nur als Anwendung, sondern als Teil Ihres Betriebs. Wenn Hardware, Telefonanlagen oder Netzwerktechnik Teil des Vorhabens sind, sage ich, ob ich der richtige Partner bin — und wenn nicht, worauf Sie bei der Auswahl achten sollten. Aus dieser Zeit stammt die Gewohnheit, zuerst den Betrieb zu fragen und dann die Technik.

Zusammenarbeit

Sie sprechen mit einer Person, die den Entwurf und den Code kennt. Absprachen werden festgehalten, Entscheidungen begründet und dort dokumentiert, wo sie später gebraucht werden. Übergabe heißt: Ihr Team kann übernehmen, ohne mich zu fragen. Für Vorhaben, die über Jahre laufen, ist das der Unterschied zwischen einem Dienstleister und einem System, das Ihnen gehört. Feste Absprachen heißen auch: Ich sage früh, wenn etwas nicht geht oder sich verschiebt.

Häufige Fragen

Grenzen

EnBeZ ist kein Designbüro, liefert keine Hardware und übernimmt keine Rufbereitschaft rund um die Uhr. Für Gestaltung, Beschaffung oder einen Betrieb mit Bereitschaft nenne ich auf Wunsch, worauf Sie achten sollten — ausführen werde ich es nicht. Besser ein ehrliches Nein als ein Auftrag, der nicht zu mir passt.