Benefits of a Work Items Sprint with IPA

While working on my latest process with Interaction Process Automation, I had a bit of an ah-ha moment I'd like to share: A Work Items Sprint. It worked out great the the first try this past week. We recently finished the front end consulting with sign-off for As-Is, To-Be and the Work Item mock ups. Keep in mind I didn't mention Detailed Requirements doc.

In early discussions with the customer, I had suggested the idea of trying to get something in front of them "sooner than later," but I hadn't gotten any further than the idea stage. Once we got sign off I had briefly started digging into the Detailed Requirements document, filling in the State names and some other obvious details from the flows.

Then last week I had an eureka! moment - why not do a Work Items Sprint? I'm no Agile expert but I am familiar with the basic concepts. I have been trying to consider how this can be accomplished with IPA since John Heiberger (www.lucilium.com) suggested the idea at Interactions2012 back in June during an IPA session. He might not have been the first to suggest it but it's the first I'd heard of it, so great idea, John!

My customer liked the idea of getting to see the screens (which are called Work Items in IPA) and I mentioned it would help drive the Detailed Requirements as well. I also talked it over with the PM, who also has IPA development experience and we were all in agreement that there were no obvious drawbacks and it was \worth a try...

So Monday I dove into IPA and started created a new Process. Keep in mind you can't jump straight into the Work Items, unless of course you don't want to actually be able to Test or Publish the process, but what fun is that? The greatest benefit is seeing the Work Items rendered on the screen because they look slightly different in the Process Automation Designer (PAD).

Turns out you have to build just enough of a shell of your process that it really helps lay the groundwork. Since we'll also be using the Database Driven Design with this process, the Work Items Sprint also required a bunch of variable definitions, which in turn will become columns in the database.

Turns out I didn't need quite the entire week and was able to get the Work Items implemented and a process published in production, which I used to demo for the customer on Friday. They liked it and I learned a bunch as well. Here's the highlights:

1. Customer gets to see something live almost immediately after sign-off, as opposed to having to wait weeks or months.
2. The inevitable tweaks are made early in implementation. I noticed a few oversights where I needed to add a simple text label and read-only edit box or a Text Label bound to a variable for display purposes, and adding those drove a few format changes, all of which made for cleaner looking and more intuitive Work Items.
3. Rapid Implementation - there's no getting bogged down in details with the logic. Just build enough to route the Work Items.

The feedback was very positive from the customer, plus it's always gratifying to see something running in production!

So consider doing a Work Items Sprint on your next IPA implementation. In another post I'll go into technical detail to break down the anatomy of a Work Items Sprint.

If you have other Agile-esque suggestions for Interaction Process Automation, feel free to contact me or drop them in the comments and I'll consider taking them for a spin too!

Happy Processing!

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.