Phase 2: Planning Your First Discovery

Once Process Discovery has been installed and your administrators and business analysts have been trained, as described in Getting Started with Process Discovery, you will create detailed plans for onboarding and implementing Process Discovery in your first business units. This includes setting goals and designating responsibilities, as described in Setting Goals and Deadlines, and selecting the first business unit and processes for discovery, as described in Selecting Processes for Discovery.

Setting Goals and Deadlines

Roles: Nintex Customer Success Manager and Customer Project Owner

Setting target goals and milestones at the onset helps align the scope and efforts between all stakeholders to guarantee the success of your discovery journey. To identify these goals, consider what pain points you want to address using Process Discovery. This enables our experts focus your journey to resolve these pain points, and guarantees a positive return on investment.

Your team should determine all the steps that need to be completed, the planned implementation timeline to reach your target roll-out date, and the individual responsible for each item. We strongly suggest using a task spreadsheet that can be shared with the tea, including columns for Start Date, Due Date, Person Responsible, Notes, and any other relevant fields.

Planning a Discovery

Roles: Nintex Customer Success Manager and Customer Project Owner

During a discovery run, the Discovery Robots running on the end-user computers capture keyboard actions and mouse clicks from all included applications during a specified timeframe. The Discovery Server then analyzes this information to identify processes.

Already automated tasks, such as executing macros and database lookups are not recorded. If steps are performed by an RPA or automation platform using API, they too might not be recorded.

For the best results, carefully plan which processes you are targeting, and which applications you need to record to capture these processes, as described in Selecting Applications and Processes. You can then choose the environment on which to execute the recording, as described in Environment. The processes you are targeting determine the recording timeframe, as described in Timeframe.

Selecting Applications and Processes

Begin by identifying the processes you want to target during the discovery run, and specifying the applications and systems that need to be recorded to capture these processes. It is helpful if you can see some of the processes upfront so that you know what to expect.

Recording a limited number of processes makes it easier to properly identify each individual process. For this reason, we highly advise running the recording within a specific process domain (such as Accounts Payable) of a single business unit, instead of running it on a broader scope. If you require process data from different domains and departments, run the discovery on these processes in subsequent stages.

There is no minimum or maximum number of process steps (actions) that you can record. Anything with distinct start and end steps will be recorded as a process. Process Discovery can also recognize different individual processes, and variants of a specific process.

Application Inclusion and Exclusion Lists

Discovery Robots can record user actions on any desktop application. This includes Windows applications, Java, Silverlight, web browsers, Virtualized (such as Citrix), and legacy applications (emulators such as IBM I or Z series). If the desktop application is an Emulator, make sure you make a note of this.

To make a discovery run more efficient, define detailed lists of the applications that should be included in the discovery run, and the applications that should not be recorded, based on your organization's privacy requirements.

An empty inclusion list significantly increases data and network consumption, and can add noise to the discovery process. When you first compile your inclusion list, err to the side of caution and include all applications that might be part of the process you want to record. You can always remove unnecessary applications later, before the discovery run.

If you do not have access to information regarding the applications that are relevant for a process, begin by compiling the exclusion list based on your organization's privacy requirements. Then, record one day of data with an empty inclusion list. The Discovery Robots will record all applications that are not on the exclusion list. This recording will help you identify which applications are used by the end-users for the process.

Generic Applications vs. Task-Specific Applications

Most organizations use generic applications, such as Microsoft Office applications, as well as task-specific applications like ERP and CRM applications. We advise, if possible, to exclude generic applications, especially when they are a very minor part of a process. If, for example, Outlook is only used to open a PDF attachment, consider not including Outlook in the inclusion list, because this will result in recording email- and agenda management tasks as well, which are unstructured by nature.

If a generic application is important for capturing a targeted process, then make sure that:

1. End users are instructed to complete the targeted process in one go, as structured as possible. Consider limiting the recording period to the execution of multiple instances of the specific task.

2. If possible, execute the targeted processes on a second, temporary workstation (laboratory approach).

Environment

Once you know what processes you want to record, you need to select the end-user environment on which to record. Unless there is a specific limitation, the Discovery Robots should run on end-user production systems. Wherever there is a security concern with running the robots on the production environment, they can be installed on a test or controlled environment, with users running their processes in a specific timeframe in these environments.

Timeframe

The recording timeframe depends on the targeted processes. As a rule, a large number of repetitions of a specific process helps improve the accuracy of the identified process. Therefore, if a process happens every couple of minutes, one day of data collection will be enough. If a process happens hourly or daily, a longer recording period is required. Likewise, if a process is seasonal, plan the discovery for a time when end-users will be executing that process.