Eine neue Unternehmenssoftware erfüllt die wichtigsten Anforderungen. Doch die Freigabewege passen nicht, die Zuständigkeiten unterscheiden sich je nach Standort und für die Bearbeitung fehlen bestimmte Informationen. Braucht das Unternehmen deshalb eine eigene Anwendung?
Häufig lassen sich solche Anforderungen durch Customizing abbilden. Entscheidend ist, welche Anpassungen die Software ermöglicht und welche das Unternehmen tatsächlich braucht. Auch konfigurierte Regeln müssen verstanden, getestet und später gepflegt werden.
Was bedeutet Customizing?
Customizing bezeichnet die Anpassung einer Standardsoftware an die Anforderungen eines Unternehmens. Im engeren Sinn werden dafür die vom Hersteller vorgesehenen Konfigurationsmöglichkeiten genutzt, ohne den Quellcode des Standardprodukts zu verändern. Dazu zählen beispielsweise Einstellungen für Organisationsstrukturen, Formulare, Rollen, Freigabewege und Prozessregeln.
Die Software liefert Funktionen und technische Bausteine. Das Customizing bestimmt, wie das Unternehmen sie einsetzt: Welche Angaben braucht ein Antrag? Wer darf ihn bearbeiten? Welche Entscheidung muss vor dem Abschluss getroffen werden?
Customizing geht damit über die Gestaltung der Oberfläche hinaus. Es übersetzt fachliche Anforderungen in das Verhalten einer Anwendung. Besonders relevant ist das, wenn mehrere Rollen, Standorte oder Fachbereiche mit derselben Software arbeiten.
Unterschiedliche Begriffsnutzung und SAP-Kontext
Anbieter verwenden den Begriff „Customizing“ nicht einheitlich. Manche fassen darunter auch Skripte, Schnittstellenanpassungen und individuelle Entwicklung zusammen. Die Bezeichnung allein sagt deshalb noch nicht, welche technischen Arbeiten ein Angebot umfasst und wer sie später warten muss.
Im SAP-Kontext steht Customizing ausdrücklich für die Systemkonfiguration. SAP beschreibt dafür unter anderem den Implementation Guide, kurz IMG, in dem die erforderlichen Einstellungen vorgenommen werden. Änderungen an den Standardfunktionen sind davon zu unterscheiden. Fachquelle: SAP Customizing
Im Softwareprojekt sollte daher festgehalten werden, welche Arbeiten zur Konfiguration gehören, welche zusätzliche Logik erzeugen und welche eigene Softwarekomponenten erfordern.
Customizing, Konfiguration, Erweiterung und Modifikation: Wo liegt der Unterschied?
Customizing beschreibt die Anpassung einer Software an die Organisation. Konfiguration ist ein zentraler Weg, diese Anpassung umzusetzen. Die Begriffe überschneiden sich also. Ob eine Anforderung Programmierung erfordert, hängt davon ab, was umgesetzt werden soll und welche Anpassungsmechanismen die Software bietet.
Parametrisierung ist ein typischer Teil der Konfiguration: Dabei werden vorgesehene Werte gesetzt, etwa für Fristen oder Grenzwerte.
Für die technische Bewertung hilft folgende Unterscheidung:
| Anpassungsart | Was geschieht? | Beispiel | Worauf ist zu achten? |
|---|---|---|---|
| Konfiguration / Customizing im engeren Sinn | Vorhandene Funktionen werden über vorgesehene Einstellungen und Werkzeuge angepasst. | Ein Serviceantrag erhält zusätzliche Pflichtangaben und einen anderen Freigabeweg. | Regeln, Daten und Rollen müssen zusammenpassen; Änderungen müssen getestet werden. |
| Erweiterung | Zusätzliche Logik oder eine eigene Komponente ergänzt vorhandene Funktionen über vorgesehene Mechanismen. | Eine besondere Berechnung wird per Skript ergänzt. | Abhängigkeiten, Fehlerbehandlung und Wartungsverantwortung dokumentieren. |
| Modifikation | Der Quellcode des Standardprodukts wird verändert. | Eine bestehende Herstellerfunktion wird direkt umgeschrieben. | Folgen für Support, Updates und Betrieb vorab mit dem Hersteller klären. |
Individualentwicklung bezeichnet die Entwicklung eigener Funktionen, Komponenten oder Anwendungen. Eine individuell entwickelte Komponente kann vorhandene Software erweitern. Es kann aber auch eine eigene Anwendung entstehen, die auf einer bestehenden Plattform aufbaut oder eigenständig betrieben wird. Individualentwicklung ist deshalb keine vollständig getrennte Alternative zu den technischen Eingriffsarten in der Tabelle.
No-Code, Low-Code und Pro-Code beschreiben unterschiedliche Wege der Umsetzung:
- No-Code: Für die betreffende Anpassung wird kein eigener Programmcode geschrieben, etwa beim grafischen Aufbau eines Workflows.
- Low-Code: Vorgefertigte Bausteine und visuelle Werkzeuge reduzieren den manuellen Programmieraufwand. Bei Bedarf lässt sich zusätzlicher Code ergänzen, beispielsweise für besondere Berechnungen oder technische Funktionen.
- Pro-Code: Funktionen und Anwendungen werden durch klassische Softwareentwicklung umgesetzt.
Diese Ansätze können innerhalb eines Projekts zusammenwirken. Auch eine grafisch konfigurierte Anwendung kann fachlich komplex sein.
Was wird beim Customizing angepasst?
Typische Anpassungen betreffen vier Bereiche, die eng zusammenhängen:
- Formulare und Ansichten: Welche Informationen werden erfasst? Welche Felder sind verpflichtend? Welche Angaben braucht ein Bearbeiter in seinem Arbeitsschritt?
- Datenstrukturen und Beziehungen: Welche Objekte sind relevant und wie hängen sie zusammen, etwa Antrag, Standort, Kostenstelle und betroffenes Gerät?
- Rollen und Berechtigungen: Wer darf Informationen sehen, verändern, freigeben oder einen Vorgang abschließen?
- Prozessregeln und Workflows: Welche Aufgaben entstehen, wohin werden sie weitergeleitet und was geschieht bei einer Ablehnung oder einer überschrittenen Frist? Ein Workflow ist ein festgelegter oder regelgesteuerter Arbeitsablauf.
Diese Bereiche sollten gemeinsam geplant werden. Ein zusätzlicher Freigabeschritt hilft wenig, wenn die zuständige Rolle fehlt oder die entscheidenden Daten nicht vorliegen. Grundlagen dazu erläutert der Beitrag zur Rechteverwaltung im ITSM.
Die Anbindung eines anderen Systems ist eine zusätzliche Integrationsaufgabe. Sie lässt sich gegebenenfalls über einen vorhandenen Konnektor konfigurieren. Die fachlichen Fragen müssen trotzdem geklärt werden: Welches System liefert die maßgeblichen Daten? Wie werden Änderungen übertragen? Was geschieht bei Fehlern? Customizing allein beantwortet diese Fragen nicht.
Beispiel: Einen Serviceantrag an die Organisation anpassen
Ein Unternehmen möchte Anträge für zusätzliche Arbeitsplatzausstattung strukturiert bearbeiten. Die vorhandene Service-Management-Software kann Anfragen erfassen, Aufgaben zuweisen und den Bearbeitungsstand dokumentieren.
Für den konkreten Prozess reicht das noch nicht aus. Im Antrag müssen Standort und Kostenstelle angegeben werden. Bestimmte Ausstattungen benötigen eine Genehmigung; ab einem definierten Antragswert ist eine zusätzliche Freigabe erforderlich. Anschließend übernimmt das zuständige Serviceteam die Bereitstellung. Wird der Antrag abgelehnt, soll der Antragsteller eine begründete Rückmeldung erhalten.
Das folgende modellhafte Beispiel zeigt, wie sich die Anforderungen auf Standardfunktionen, Konfiguration und mögliche Erweiterungen verteilen:
| Anforderung | Möglicher Lösungsweg |
|---|---|
| Antrag erfassen und Bearbeitungsstand anzeigen | Vorhandene Funktionen der Lösung nutzen. |
| Standort und Kostenstelle abfragen | Formular und Datenfelder konfigurieren. |
| Genehmigung abhängig von Ausstattung oder Antragswert verlangen | Bedingungen und Freigabeschritte im Workflow konfigurieren. |
| Aufgaben an das zuständige Team übergeben | Zuständigkeitsregeln und Rollen einrichten. |
| Den Antragswert nach einer besonderen internen Berechnungsregel ermitteln | Vorhandene Berechnungsmöglichkeiten prüfen; bei Bedarf zusätzliche Logik ergänzen. |
| Kostenstellen aus einem anderen System übernehmen | Integrationsmöglichkeit und Datenverantwortung prüfen. |
Wo die Grenze zwischen Konfiguration und Erweiterung liegt, bestimmt die konkrete Software. Eine Anforderung, die ein Produkt grafisch abbildet, kann bei einem anderen eine Erweiterung erfordern. Die Bewertung sollte sich deshalb am tatsächlichen Ablauf orientieren.
Im IT Service Management (ITSM), also der Organisation und Steuerung von IT-Services, betrifft das beispielsweise Serviceanträge und Bearbeitungsregeln. Enterprise Service Management (ESM) überträgt entsprechende Prinzipien auf weitere Fachbereiche. Dadurch können auch Einkauf oder Facility Management beteiligt sein. Die fachliche Aufgabe bleibt dieselbe: Daten, Zuständigkeiten und Entscheidungen zu einem funktionierenden Ablauf verbinden.
Welche Vorteile bietet Customizing – und was kostet es langfristig?
Nutzen entsteht durch konkrete Verbesserungen
Customizing kann dafür sorgen, dass eine Software besser zu den Anforderungen passt, wenn die Anpassung ein nachvollziehbares Problem löst. Werden erforderliche Angaben bereits im Formular erfasst, können Rückfragen entfallen. Lässt sich die Zuständigkeit anhand verlässlicher Daten ermitteln, müssen Anfragen seltener manuell weitergeleitet werden. Eine rollenbezogene Ansicht kann Bearbeitern die Informationen bereitstellen, die sie für ihre Aufgabe brauchen.
Ein weiterer Vorteil ist die Nutzung vorhandener Funktionen. Lässt sich eine geeignete Standardfunktion konfigurieren, muss sie nicht eigens entwickelt werden. Ob dadurch die Gesamtkosten sinken, hängt allerdings auch von Lizenzen, Einrichtung, Schulung, Betrieb und Pflege ab.
Der Nutzen sollte an den Projektzielen gemessen werden. Im Servicebeispiel wären etwa die Zahl der Rückfragen, die manuellen Übergaben oder die Zeit bis zur Entscheidung relevant. Die Wirkung hängt auch davon ab, ob die Regeln klar sind und die nötigen Ressourcen zur Verfügung stehen.
Komplexität und Pflegeaufwand mitbewerten
Zusätzliche Varianten können den Pflege- und Testaufwand erhöhen, besonders wenn Regeln und Formulare getrennt gepflegt werden. Gibt es viele ähnliche Formulare oder abweichende Freigabewege, muss eine spätere Änderung möglicherweise an mehreren Stellen umgesetzt werden. Widersprüchliche Regeln erschweren die Fehlersuche. Schlecht dokumentierte Einstellungen machen den Betrieb von einzelnen Personen abhängig.
Wie hoch der Aufwand ausfällt, bestimmen vor allem die Zahl der Prozessvarianten, die beteiligten Schnittstellen und die individuellen Geschäftsregeln. Auch die Qualität der Ausgangsdaten und die Häufigkeit späterer Änderungen beeinflussen die Kosten. Eine grafisch konfigurierte Freigabe kann daher trotz geringer Programmierung erheblichen Abstimmungs- und Testaufwand verursachen. Wiederverwendbare Bausteine und zentral gepflegte Regeln können diesen Aufwand begrenzen.
Die Bewertung sollte den gesamten Lebenszyklus umfassen: Anforderungsanalyse, Konfiguration, Datenübernahme, Tests und Schulung ebenso wie spätere Änderungen und Updateprüfungen. Skripte und individuelle Komponenten können zusätzliche technische Abhängigkeiten erzeugen.
Updatefähigkeit bedeutet nicht, dass jede individuelle Anpassung dauerhaft ohne Prüfung unverändert funktioniert. Ob Einstellungen erhalten bleiben und ob ein Prozess weiterhin korrekt arbeitet, sind zwei unterschiedliche Fragen. Nach einem Update sollten die betroffenen Abläufe getestet werden. Ob zusätzlich technische Nacharbeiten nötig sind, hängt vom Produkt und der Anpassungsart ab.
Wann ist Customizing sinnvoll – und wann sollte der Prozess angepasst werden?
Nicht jede Abweichung vom Standard rechtfertigt eine Anpassung. Ein gewachsener Ablauf kann notwendig sein. Er kann aber auch auf frühere Einschränkungen zurückgehen. Vor der technischen Umsetzung sollte deshalb geprüft werden, welchem Zweck die Abweichung dient.
| Situation | Sinnvoller erster Schritt |
|---|---|
| Die Standardfunktion erfüllt die Anforderung. | Standard nutzen und Anwender im vorgesehenen Ablauf schulen. |
| Eine notwendige organisatorische Regel fehlt. | Vorgesehene Konfigurationsmöglichkeiten prüfen. |
| Ein Sonderweg hat keinen erkennbaren fachlichen Nutzen. | Prozess vereinfachen, bevor eine zusätzliche Variante entsteht. |
| Eine notwendige Fachregel lässt sich nicht konfigurieren. | Erweiterung oder Entwicklung einschließlich Wartung bewerten. |
| Ein anderes Fachsystem erfüllt die Aufgabe bereits. | Zusammenspiel und Integration prüfen. |
Fünf Fragen helfen bei der Entscheidung: Welches Problem löst die Anpassung? Wie häufig tritt es auf? Welche Folgen hat der Verzicht? Welche Abhängigkeiten entstehen? Wer trägt die laufenden Kosten und die Verantwortung?
Ein selten genutzter Sonderweg kann gerechtfertigt sein, wenn er eine verbindliche interne Vorgabe erfüllt. Umgekehrt lässt sich auch ein häufig genutzter Ablauf vereinfachen, wenn zusätzliche Freigaben keinen erkennbaren Beitrag leisten. Entscheidend ist der fachliche Zweck. Wie Anforderungen erfasst und im Projekt bearbeitet werden, erläutert der Beitrag zum Anforderungsmanagement.
Customizing mit EcholoN: Vom Standardprozess zur individuellen Umsetzung
EcholoN verbindet vorhandene Lösungen mit einer gemeinsamen Software-Plattform. Für ein Serviceprojekt können beispielsweise die ITSM-Lösung oder die Enterprise-Service-Management-Lösung als Ausgangspunkt dienen. Eine Lösung bündelt Funktionen und Prozesse für ein bestimmtes Einsatzgebiet. Vorhandene Servicefunktionen können genutzt und anschließend an die Organisation angepasst werden.
Formulare, Regeln und Freigaben am Serviceantrag verbinden
Beim beschriebenen Serviceantrag können in EcholoN Formularfelder und Prüfregeln mit einem grafisch modellierten Freigabeprozess verbunden werden. Die EcholoN Workflow Engine stellt dafür unter anderem wiederverwendbare Aktionen für Aufgaben, Entscheidungen und Benachrichtigungen bereit.
Ein Freigabeweg kann beispielsweise vom Antragswert abhängen. Formularinhalte lassen sich passend zur Rolle, zum Prozessstatus oder zu vorherigen Eingaben anzeigen und bearbeiten. Damit greifen Datenerfassung und Bearbeitungsschritte ineinander. Workflow-Änderungen können versioniert, in einer Testumgebung geprüft und anschließend kontrolliert bereitgestellt werden.
Zusätzliche Geschäftslogik lässt sich bei Bedarf über Skripte und Expressions ergänzen. Expressions sind Ausdrücke, mit denen beispielsweise Bedingungen oder Berechnungen formuliert werden. Für Datenflüsse zwischen Anwendungen kommt je nach Integrationsszenario unter anderem das EcholoN Data Workflow System infrage. Der verfügbare Umfang richtet sich nach Edition, Modulen und Systemkonfiguration.
Wann eigene Entwicklung hinzukommt
Für weitreichende Konfiguration ist die Professional Edition zu prüfen. Werden eigene Anwendungen, Module oder Softwarekomponenten benötigt, stellt die EcholoN Enterprise Edition den Pro-Code-Entwicklungsumfang bereit.
Das EcholoN Enterprise Application Framework bildet die technologische Grundlage der Plattform. Die Enterprise Edition ist die Ausbaustufe, die eigene Softwareentwicklung auf dieser Grundlage ermöglicht. Die Begriffe bezeichnen also unterschiedliche Ebenen. Auch ein ESM-Projekt benötigt nicht automatisch die Enterprise Edition. Maßgeblich sind die erforderlichen Funktionen und Anpassungsmöglichkeiten. Die Editionsübersicht unterstützt die Einordnung.
Konfigurationen innerhalb der vorgesehenen Plattformmechanismen bleiben Teil der weiterentwickelten EcholoN-Produktbasis. Nach Updates sollte geprüft werden, ob die betroffenen Prozesse weiterhin wie vorgesehen funktionieren. Bei technischen Änderungen können zusätzlich Anpassungen an individuellen Skripten, Integrationen und Pro-Code-Erweiterungen erforderlich sein.
Weitere Informationen zur gemeinsamen technischen Basis bietet die EcholoN Software-Plattform.
Ihren Prozess mit EcholoN prüfen
Sie möchten klären, welche Anforderungen vorhandene Funktionen erfüllen und wo Konfiguration oder Erweiterungen erforderlich sind? Fordern Sie eine individuelle EcholoN-Demo an und bringen Sie einen konkreten Prozess mit den benötigten Daten, Rollen und beteiligten Systemen ein.