New enterprise software meets the most important requirements. However, the approval workflows don’t fit, responsibilities vary by location, and certain information is missing for processing. Does the company therefore need its own application?
Often, such requirements can be addressed through customization. The key factor is which customizations the software allows and which ones the company actually needs. Even configured rules must be understood, tested, and maintained later on.
What does “customizing” mean?
Customizing refers to the process of adapting standard software to a company’s requirements. In the narrower sense, this involves using the configuration options provided by the manufacturer without modifying the source code of the standard product. This includes, for example, settings for organizational structures, forms, roles, approval workflows, and process rules.
The software provides functions and technical building blocks. Customizing determines how the company uses them: What information does a request require? Who is authorized to process it? What decision must be made before it is finalized?
Customizing thus goes beyond the design of the user interface. It translates business requirements into the behavior of an application. This is particularly relevant when multiple roles, locations, or departments work with the same software.
Variations in Terminology and the SAP Context
Vendors do not use the term “customizing” uniformly. Some also use it to encompass scripts, interface adaptations, and custom development. The term alone therefore does not indicate which technical tasks a proposal includes or who will be responsible for maintaining them later.
In the SAP context, Customizing explicitly refers to system configuration. SAP describes this, among other things, in the Implementation Guide (IMG), where the necessary settings are made. This should be distinguished from changes to standard functions. Source: SAP Customizing
In a software project, it should therefore be documented which tasks are part of configuration, which generate additional logic, and which require custom software components.
Customizing, Configuration, Extension, and Modification: What's the Difference?
Customizing refers to the process of adapting software to an organization’s needs. Configuration is a key method for implementing this adaptation. The terms therefore overlap. Whether a requirement necessitates programming depends on what needs to be implemented and what customization mechanisms the software provides.
Parameterization is a typical part of configuration: it involves setting predefined values, such as deadlines or thresholds.
The following distinction is helpful for technical evaluation:
| Type of Adaptation | What Happens? | Example | What Should Be Considered? |
|---|---|---|---|
| Configuration / Customizing in the Narrow Sense | Existing functions are adapted using provided settings and tools. | A service request is given additional required fields and a different approval workflow. | Rules, data, and roles must align; changes must be tested. |
| Extension | Additional logic or a custom component supplements existing functions using designated mechanisms. | A specific calculation is added via a script. | Document dependencies, error handling, and maintenance responsibilities. |
| Modification | The source code of the standard product is altered. | An existing vendor function is rewritten directly. | Clarify the implications for support, updates, and operations with the vendor in advance. |
Custom development refers to the development of custom functions, components, or applications. A custom-developed component can extend existing software. However, it can also result in a standalone application that builds upon an existing platform or operates independently. Custom development is therefore not a completely separate alternative to the types of technical interventions listed in the table.
No-Code, Low-Code, and Pro-Code describe different implementation approaches:
- No-Code: No custom program code is written for the customization in question—for example, when graphically designing a workflow.
- Low-Code: Pre-built building blocks and visual tools reduce the amount of manual programming required. If necessary, additional code can be added, for example, for specific calculations or technical functions.
- Pro-Code: Functions and applications are implemented through traditional software development.
These approaches can work together within a single project. Even a graphically configured application can be technically complex.
What is customized?
Typical customizations involve four closely related areas:
- Forms and views: What information is captured? Which fields are required? What information does a user need for each step of the process?
- Data structures and relationships: Which objects are relevant, and how are they related—such as the request, location, cost center, and affected device?
- Roles and permissions: Who is allowed to view, modify, approve, or close a process?
- Process rules and workflows: What tasks arise, where are they forwarded, and what happens in the event of a rejection or a missed deadline? A workflow is a defined or rule-driven sequence of steps.
These areas should be planned collaboratively. An additional approval step is of little help if the responsible role is missing or the critical data is unavailable. The basics of this are explained in the article on rights management in ITSM.
Integrating another system is an additional integration task. If necessary, it can be configured using an existing connector. Nevertheless, the business-specific questions must be clarified: Which system provides the relevant data? How are changes transferred? What happens in the event of errors? Customizing alone does not answer these questions.
Example: Customizing a service request for the organization
A company wants to process requests for additional workplace equipment in a structured manner. The existing service management software can record requests, assign tasks, and document the processing status.
However, this is not yet sufficient for the specific process. The request must specify the location and cost center. Certain items of equipment require approval; above a defined request value, additional authorization is required. The responsible service team then handles the provisioning. If the request is denied, the requester should receive a response with an explanation.
The following illustrative example shows how the requirements are distributed across standard functions, configuration, and possible extensions:
| Requirement | Possible Solution |
|---|---|
| Record requests and display processing status | Use existing functions of the solution. |
| Query location and cost center | Configure the form and data fields. |
| Require approval based on features or request value | Configure conditions and approval steps in the workflow. |
| Assign tasks to the responsible team | Set up responsibility rules and roles. |
| Determine the request value according to a specific internal calculation rule | Check existing calculation options; add additional logic if necessary |
| Import cost centers from another system | check integration options and data ownership. |
The specific software determines where the line between configuration and extension lies. A requirement that a product maps graphically may require an extension in another. The evaluation should therefore be based on the actual process.
In IT Service Management (ITSM) - that is, the organization and management of IT services - this applies, for example, to service requests and processing rules. Enterprise Service Management (ESM) extends these principles to other business areas. As a result, procurement or facility management may also be involved. The core task remains the same: linking data, responsibilities, and decisions to create a functioning workflow.
What are the benefits of customization - and what does it cost in the long run?
Benefits Come from Concrete Improvements
Customization can ensure that software better meets requirements if the adjustment solves a specific problem. If the necessary information is already captured in the form, follow-up inquiries can be eliminated. If responsibility can be determined based on reliable data, requests need to be manually forwarded less often. A role-based view can provide users with the information they need to perform their tasks.
Another benefit is the use of existing functions. If a suitable standard function can be configured, there is no need to develop it from scratch. Whether this reduces overall costs, however, also depends on licenses, setup, training, operation, and maintenance.
The benefits should be measured against the project goals. In the service example, for instance, the number of follow-up inquiries, manual handoffs, or the time to decision would be relevant. The impact also depends on whether the rules are clear and the necessary resources are available.
Evaluate Complexity and Maintenance Effort
Additional variants can increase maintenance and testing efforts, especially if rules and forms are maintained separately. If there are many similar forms or differing approval workflows, a subsequent change may need to be implemented in multiple places. Conflicting rules make troubleshooting more difficult. Poorly documented settings make operations dependent on specific individuals.
The amount of effort required is determined primarily by the number of process variants, the interfaces involved, and the specific business rules. The quality of the source data and the frequency of subsequent changes also influence the costs. A graphically configured approval process can therefore result in significant coordination and testing efforts despite minimal programming. Reusable building blocks and centrally maintained rules can limit this effort.
The evaluation should cover the entire lifecycle: requirements analysis, configuration, data migration, testing, and training, as well as subsequent changes and update checks. Scripts and custom components can create additional technical dependencies.
Updateability does not mean that every individual customization will continue to function unchanged indefinitely without testing. Whether settings are retained and whether a process continues to function correctly are two separate questions. After an update, the affected processes should be tested. Whether additional technical work is required depends on the product and the type of customization.
When does customization make sense - and when should the process be adapted?
Not every deviation from the standard justifies an adaptation. An established workflow may be necessary. However, it may also stem from past limitations. Before technical implementation, therefore, the purpose of the deviation should be examined.
| Situation | Recommended First Step |
|---|---|
| The standard function meets the requirement. | Use the standard and train users in the intended workflow. |
| A necessary organizational rule is missing. | Check the available configuration options. |
| A custom solution has no discernible business benefit. | Simplify the process before creating an additional variant. |
| A necessary business rule cannot be configured. | Evaluate an extension or new development, including maintenance. |
| Another business system already fulfills the task. | Check for interoperability and integration. |
Five questions help with the decision: What problem does the customization solve? How often does it occur? What are the consequences of not implementing it? What dependencies arise? Who bears the ongoing costs and responsibility?
A rarely used custom solution may be justified if it meets a mandatory internal requirement. Conversely, even a frequently used process can be simplified if additional approvals do not provide any discernible benefit. The business purpose is decisive. The article on requirements management explains how requirements are captured and addressed in a project.
Customizing with EcholoN: From Standard Process to Custom Implementation
EcholoN integrates existing solutions into a common software platform. For a service project, for example, the ITSM solution or the Enterprise Service Management solution can serve as a starting point. A solution bundles functions and processes for a specific area of application. Existing service functions can be utilized and then adapted to the organization.
Linking Forms, Rules, and Approvals to the Service Request
In the service request described above, form fields and validation rules in EcholoN can be linked to a graphically modeled approval process. The EcholoN Workflow Engine provides, among other things, reusable actions for tasks, decisions, and notifications.
For example, an approval step may depend on the request value. Form content can be displayed and edited based on the user’s role, the process status, or previous entries. This ensures that data entry and processing steps are seamlessly integrated. Workflow changes can be versioned, tested in a test environment, and then deployed in a controlled manner.
Additional business logic can be added as needed via scripts and expressions. Expressions are used, for example, to formulate conditions or calculations. For data flows between applications, the EcholoN Data Workflow System is one option, depending on the integration scenario. The available features depend on the edition, modules, and system configuration.
When Custom Development Is Required
For extensive configuration, consider the Professional Edition. If custom applications, modules, or software components are required, the EcholoN Enterprise Edition provides the Pro-Code development capabilities.
The EcholoN Enterprise Application Framework forms the technological foundation of the platform. The Enterprise Edition is the tier that enables custom software development based on this foundation. The terms thus refer to different levels. Even an ESM project does not automatically require the Enterprise Edition. The decisive factors are the required functions and customization options. The Edition Overview helps with classification.
Configurations within the intended platform mechanisms remain part of the further-developed EcholoN product base. After updates, you should verify whether the affected processes continue to function as intended. In the event of technical changes, additional adjustments to individual scripts, integrations, and Pro-Code extensions may be necessary.
Further information on the shared technical foundation is available on the EcholoN Software Platform.
Evaluate Your Process with EcholoN
Would you like to determine which requirements your existing functions meet and where configuration or enhancements are needed? Request a customized EcholoN demo and bring a specific process with the necessary data, roles, and involved systems.