Evaluating Automation Use Cases

Objective

After completing this lesson, you will be able to Evaluate use cases and determine when to build an automation for a customer’s business process.

Typical Use Cases for Automations

Let's look at some use cases covered by automations in SAP Build Process Automation. These include the following:

  • Extracting data using different connectors and putting that data into a finance system
  • Searching for invoice numbers in countless ERP instances
  • Logging on to multiple SAP ERP Central Component instances, collecting purchase requisitions, and distributing them to shared services

Automations in SAP Build Process Automation is all about making tasks more efficient. For example, during activity peaks, it can reduce the errors made by personnel who are under pressure to enter significant amounts of information in a short time frame.

Use Case Typology

During the course of a working day, users are often unaware of all the simple tasks they complete. Hidden tasks get lost in their daily work. At first you think you only need to automate the boring tasks. However, consider also the short, hidden tasks, where the potential for automation is lower (approximately 50%). These tasks may be performed, for example, 40 times a day or more. If for example, 50 people are doing the same thing, the potential for time saving is significantly higher than the time saving for boring tasks, estimated at approximately 12 full-time equivalents.

Use Case Example With and Without Automation

Use Case Constraints

Let's look at another example. An asset management system is in place with its relevant screens.

Web services or APIs are a good idea, but require significant time to develop because of all the mandatory checks that must be performed. Migration is also a possibility, but is not an option at the moment because the time and budget required are not available.

Time and budget constraints are often key points in promoting the use of robots:

  • Too expensive to add a user-friendly interface in the asset management system.
  • No time to add a web service between the two applications.
  • No time for migration. It is planned, but some years from now.

Manual Purchase Order Creation

The following describes a typical Purchase Order (PO) creation process.

The Purchasing department receives purchase orders by email on a daily basis. An initial filter is required for various reasons. Once filtered, the team needs to identify the products, quantity, customer, and so on.

If you have just one product for sale, it is straightforward. The list is defined and you can enter the data in your system. You launch the corresponding transaction, navigate the screens, look for all the mandatory fields, and so on, and perhaps you are done.

However, the team must repeat these activities over and over again, often for many different products.

Purchase Order Creation – Manual Steps

Automated Purchase Order Creation

In this approach, you have a robot that first reads the spreadsheet. Row after row, it copies all the field values to the corresponding transaction in your favorite SAP ERP system.

Once in place, this robot works continuously to help the team. The following figure illustrates how automation can handle this process.

Use Case Criteria

Here we will summarize the use case criteria for automations in SAP Build Process Automation.

There are four main criteria:

You can imagine many great use cases for automations in SAP Build Process Automation.

Be creative and listen to end users who create processes daily. The possibilities are endless. That concludes this lesson.

Log in to track your progress & complete quizzes