A release has been sitting in an inbox for days, even though all the required information is there. At the same time, another person enters the same data into a second system. Such tasks are obvious candidates for automation. However, not every manual step is unnecessary, and a bad process done quickly doesn't automatically make it better.

Automating business processes means designing rules and transitions so that recurring work can be carried out reliably. Exceptions and responsibility must be expressly retained. The economic benefit depends on whether the automation actually makes a relevant task easier and can be managed during operation.

Choose a process with a beginning and an end

A good start is clearly limited: for example, a recurring document release, a daily data import or the forwarding of a fully recorded request. A vague order such as “automate sales”, on the other hand, is hardly meaningful. First, the trigger, the information required and the desired result must be described.

A simple process recording also shows which steps only exist because of missing data or unclear responsibilities. Perhaps the additional check is necessary because a mandatory field is never reliably filled out. Then better capture can be more effective than a complex memory mechanism. Automation should support a comprehensible process, not make unclear rules invisible.

Distinguish rules from decisions

Clear rules can be easily automated: an application is complete if certain information is available. A release may only be carried out by a defined role. Decisions that require negotiation, expertise, or an assessment of conflicting information are more difficult. There, software can prepare, sort and document while a human makes decisions.

The limit should be visible in the system. An automatically calculated proposal is not the same as a binding release. Employees must understand what action is required and on what basis value was created. Otherwise, unclear automation creates either blind trust or additional control work outside of the application.

A fictitious example: procurement applications

A team reports required equipment using a form. The application checks mandatory fields and assigns the process to the appropriate cost center. The responsible person then receives a task. After approval, purchasing will be informed. Every status change is clearly linked to the time and responsible role.

The exceptions are important: What happens in the event of substitution, a subsequent change in the amount or no feedback? Does a significant change need to trigger the release again? Can the applicant approve themselves? Such questions determine the quality of the process more than the visual representation of a process diagram.

Use notifications sparingly and specifically

An automated email is easy to create, but can create additional clutter. Anyone who receives many similar reports every day may overlook this important exception. Notifications should therefore communicate a specific action or relevant change in status. Summaries can be more useful than a message for each individual technical event.

The application should contain the binding state, not just the mailbox. A message may be lost or read later. A distinction must also be made between the creation of an email, its delivery to a mail server and the actual delivery. For critical processes, a visible task status and, if necessary, an agreed escalation path are required.

Plan data imports with test routes

Regular import can avoid significant manual work. To do this, field assignment, data types and unique identifiers must be clarified. A file without an expected column cannot be partially processed silently. Likewise, a restarted import must recognize which processes have already been adopted.

A preview with an error report is helpful: How many data records are valid, which ones will be changed and which ones will be put on hold? Those responsible should be able to process problematic entries. Separate background processing may be required for larger amounts of data. Their progress and completion must remain clearly visible so that a second start does not accidentally create duplicate processes.

Secure interfaces and repetitions

Automation often depends on other systems. An unavailable service or a delayed response is not a rare special case, but an expected operating condition. For writing processes, it must be checked whether a repetition could create the same job again. Stable operation identifiers and appropriate retry rules help avoid such errors.

The receiving side must also limit access and check technical rules itself. An automated call is not automatically trustworthy. Our article describes details about data responsibility, authorizations and error processing APIs and interfaces. Diese Grundlagen sollten bereits im Automatisierungskonzept berücksichtigt werden.

Evaluate profitability using observable assumptions

For an initial assessment, frequency, processing time and typical correction effort are recorded. There are also development, licensing and operating costs. The bill should make uncertainty visible. A process that occurs only a few times a year may not warrant extensive specialized application, even if it is cumbersome to handle manually.

Not every benefit can be expressed as a direct personnel hour saved. Better traceability, fewer media disruptions or more reliable representation can also be relevant. However, they should be specifically described and checked. A claimed productivity gain without a basis for comparison is not a reliable basis for decision-making. The pilot must show what effect is created in the actual working environment.

Consciously design rights and protocols

Automated services require limited access. For example, an import may update articles, but not automatically change user accounts. Logs should show which process triggered which process. At the same time, confidential content and technical secrets do not needlessly belong in every log line.

For personal data, the purpose, recipient and storage must be clarified. New automation can create additional data flows, even if it initially appears to be just a technical simplification. Before external tools are used, their access options and contractual conditions must be checked. Technical and data protection responsibility remains with the company.

Start small, operate fully

A sensible pilot contains a normal procedure, at least one exceptional case and a restart procedure. It can't just be an impressive demonstration. Employees must recognize whether the process was completed successfully and how they can correct an error. A manual replacement option can be important for the transition.

After the introduction, rules and actual usage will be reviewed. Has the process changed? Are new exceptions emerging? Are there reports that no one responds to? Automation requires maintenance like other software. Otherwise, an outdated process can continue to reliably do the wrong thing.

Provide a shutdown and correction path

Automated processes require a controlled option for pausing. If an import suddenly returns incorrect data, the entire server should not have to be shut down. A suitable pause prevents new processing and makes it clear which processes have already been completed or are still open.

The question then arises about corrections. Not every action can be easily undone. A message that has already been sent remains with the recipient; an order that has been placed may require a technical cancellation process. Irreversible steps should therefore be particularly carefully safeguarded. A preview or release step can be useful for certain processes.

For the restart, it is determined from which status work will continue. If data has been partially transferred, the application must recognize it and not process it again without checking it. A protocol with stable process identifiers supports reconciliation. Technical corrections are documented in a comprehensible manner instead of becoming invisible through direct database changes.

Such procedures initially seem like additional work. However, in the event of a disruption, they prevent improvisation under time pressure. The crucial question during acceptance is therefore: Can authorized employees recognize a faulty process, stop it and correct it in an orderly manner? Only then is automation fully described as an operational process.

The right starting point

  • Choose a frequent, clearly defined activity.
  • Document triggers, dates, decisions and responsibilities.
  • Determine exceptions, repetitions and restarts in advance.
  • Evaluate benefits and costs using a pilot.
  • Bindingly assign operations and later rule changes.

GRITTMANN can implement such processes as an individual web application or targeted integration. A Employee portal can offer a common entry point for applications and tasks. However, the right tool follows the process described, not the other way around.

Sources and further documentation

Technical basics and additional information from the respective editors. Links last checked on 16.09.2026.