❓ What is the role of a Solution Architect 👉 Session follow-up discussion

News Events
7

In my approach, the way of how we document depend on the size of the process, its ownership, clarity of happy path, goals, products and automation workload - which often turns out crucially as we want to deliver results fast. So we shouldn’t limit ourselves to the current definition in a given organization, but rather make a division according to chances for quick wins.

Because, after all, according to Porter Value Chain, a process is both a macro-process and its minor component at the sub-process level. And yet we can also robotize activity sets separately. So a process definition itself is very elastic.

We usually call something around 2-3 BPM the “process”. Of course, it depends on how the client defines the process and we include in the analysis all aspects mentioned in the first paragraph, but as I wrote above - this limit is only in our head. Automation is the excellent moment to reenginering and optimization.

In practice, we are trying to divide “processes” above 60 MD into subprocesses from the point of view of work planning and faster delivery of first RPA benefits.

From the documentaion point of view, we are trying to document sub-processes (similar in nature of activities of the path of the same process, with one goal, leading to similar work products under one process owner) together and if we extend the process contained in one document with subsequent paths, we do it as part of the Change Request procedure.
On the other hand, we document separately processes, which clearly differs in the nature of activities, purpose, products or has different owners.

In the case of sub-processes documented together, we are talking de facto about different paths of the same process, so we make a business case for the whole process, and then we divide it into happy path, other main paths (if they have a significant share in the task volume) and remaining paths we count collectively as the Other.
Then the Pareto principle applies and we focus on the automation of subsequent paths, according to their importance, leaving sparse paths clearly as a collective issue - what is left after the total estimates and subtracting the happy path + 1-2 significant paths. So it is easy to prepare a business case per path for what is important.

Then, within one document, we make a detailed description (business values, risks, map and flow) for what is planned for implementation, with only a general indication of the rest.
For example, process flow, is accurate for paths which are subject to automation, with an indication of the places where the branch takes place. We treat it as the end of automation and variants that are not subject to it, apart from their briefly marked existence and the collective counting of the business values on a residual basis, are not marked in the RPA documentation.

For the purposes of compliance/audit, etc., we assume that they remain in manual implementation, and therefore the responsibility for them and theri documentation is on the side of the business owner, as before.
From the existing documentation (process cards, procedures, instructions, control tools, etc. before automation) we extract only what changes and document it in the RPA documentation.

14 Likes