No Such Thing as a Simple Process for IPA

Lately I've been working on an internal process for a client's Finance Department. If there's one thing I've learned so far it's there are small, complex process and larger, complex process.

However, there's no such thing as a simple process. Elegant perhaps. Short, as in referring to the time frame and steps to complete the process? Sure. Just try to avoid the term "simple" if you can, because it tends to imply "easy to scope and implement," which most processes simply aren't.

As-Is Swim Lane

When I was brought into the project, a fairly straightforward To-Be process mapping had been defined. Take a look at the As-Is graphic. It's a pretty straightforward set of approvals though management and ends with the Accounts Payable group. All the detail isn't important at this point, just seeing that the process flows through several different people with some decision points is sufficient for the moment.

Seems simple, right...?At first glace it most certainly does. What we don't see in the As-Is are some of the sneaky little business rules and requirements that came up over time.

To-Be Swim Lane

By the time we got done peeling back the layers of the onion, if you will, the process is still straightforward but it is noticeably a bit more complex when we talk about the To-Be swim lane to implement in IPA:

• Business Rules - as much as possible, are described in a flexible means so they can stay "in the business," which means they're stored and pulled into Work Items in IPA so the business can modify them as needed. No need to involve IT or Operations to make changes. For example, the same Task will be called in the process multiple times, so the management approval chain can be dynamic. All those levels showed up in the first process by Swim Lane. In the To-Be they're collapsed and called in a loop until we're done.
• External Systems - it's nice to imagine your process can be handled completely within IPA but that will probably rarely be the case. It's likely you'll need to move a file from one place to another or have some data database interaction. Lucky you if it can all be done with existing or new web services, but that's probably the exception.
• Complex Logic - if process contains logic that's easy for a human, such as having some approval level amounts by role in your head or on a piece of paper, which happen to change based on department and role (with exceptions of course), it's easy to look at someone's title and department to determine where they fit into those rules. That doesn't always translate easily into a process with IPA, which I'll cover in more detail in an upcoming post.

Suffice to say some or all of the above are going to apply in some way, shape or form. Just be prepared to spend some time with your As-Is process and your To-Be documentation, which should include a To-Be process flow, Screen Mock-Ups for your Work Items and also your Detailed Requirements document, to contain your business rules, system integration(s) and To-Be mapping of the business rules to your IPA Process (the pseudo-code version of the process).

More on all of that to come. For now, just remember there ain't no such thing as a simple process, especially if you want to get it right. Interaction Process Automation can help, but getting it right assumes you do your diligence and eliminate assumption.

Ever fallen into the "oh it'll be simple" mindset? Feel free to drop a comment.