IPA Best Practices from a Recent Internal Session at ININ

I had the good fortune recently to present a topic during an internal session at ININ on Interaction Process Automation. These aren't the best formatted notes you'll ever see, but if you've built a process in IPA, or at least seen the Process Automation Designer, I figured I'd just get'em out there as food for thought.

Suffice to say this little event was the largest gathering to date of folks who have IPA implementation experience. There's already a few who have more than a year or two experience, which ain't bad considering the product's initial release was in 2009. Some great ideas and best practices were shared.

My topic was the Work Items Sprint, and in an upcoming post, I'll expand on that concept into the design and implementation phase, tying everything together using complex data types that are auto-generated by IPA if you use the database tools (40SU2 and later). I've done this with the latest process I'm developing and find it extremely effective and efficient.

Configuration and Implementation

Consider storing IC-server specific information in an external configuration location, such as an IC Server Parameter, and use variables in your IPA process to reference the data. A perfect example is a workgroup name. If you hardcode your workgroup name into your process and import that process into another IC server, if that workgroup hasn't already been created in IA on that server, your process will go into error immediately, plus you'll have to change every occurrence of the workgroup name. Structured Parameters in IA can be exported and imported, making this process easy and efficient, plus you can later change the workgroup name in IA and not have to touch your process. This is especially important for people considering building Templates for the MarketPlace.

Work Items Sprint

After As-Is, To-Be and the Work Items mock ups have been signed off, go build the work items immediately and then demo them for the customer. Sprint is an agile concept and is described in more detail in the Benefits of a Work Items Sprint with IPA post. No logic is needed and just use process-level variables (preface them with something like TEMP so you can clean up and push them down into work items later). Sprint is an agile concept and is described in more detail in the Benefits of a Work Items Sprint with IPA post.

Troubleshooting

Consider adding an "i" icon button for information to each page of your work items. Keep track of a process-level string that is constantly updating what has happened in the process. Think of this as Process History, the IPA version of Call Details when you right-click on a call in the Interaction Client. This way you don't have to jump into PAM to look at stuff or start with logs. If you're keeping good track of Process History, you can simply click on the information button in your process and see how you got there. Use a var to keep track of where you came from when you press the "i" button and Destination conditions for each page and the "i" page so you can reuse the page on each work item.

Error handling for Web Services and to a lesser extent for Handlers

Instead of simply letting the process crap out and have to jump to PAM to start troubleshooting, handle them in the process flow. By default for the Call Web Services Operation and Run Handler tools, the Errors and Timeouts tab will have Stop the process (refer to Process Monitor) selected. Change these to Handle the timeout/error in the process flow. This presupposes you will also have return values in your handlers and web services that indicate whether or not the operation succeeded, because you'll have to add process logic to evaluate those return codes. If you get an error, do a Parallel Split - keep the work item with the user encountering the error and launch a separate error handling process. Once you've determined if you can restart the process or retry the process, then the user can continue.

Many thanks to Geoff Calhoun, the new product manager for IPA and content management at ININ. We'll see about getting a few words from him at some point in the future as well.

In the meantime...

Happy Holidays and Happy Processing!

When Not to Put a Business Rule in IPA

Oh Great Masses (well, soon to be masses) of Interaction Process Automators, Beware of Ye Olde Scope Creep! Interaction Process Automation is great for providing workflow between multiple applications. In order to try to deploy rapidly and start getting ROI, try to resist tailoring your process for every single use and error case that can occur.

Example: A process I'm working on currently will pull data from a 3rd party CRM system that houses customer information via web services. IPA isn't a CRM (more on that another time) and it isn't replacing the CRM solution. IPA will automate a process for annotating some customer survey data and collecting internal feedback between various departments in the company.

The business analyst with the customer made an astute decision that data would need to be more or less cleaned up in the CRM before launching the process. Could IPA have been made to provide additional functionality to reclassify and update the data while the process was mid-flight? Sure. Did it make sense to do it here? Not no, but hell no! The goal is to get the process published and get some ROI to the business, not stay in perpetual development.

And that's the challenge. IPA and CIC in general have an expansive set of tools to build a multitude of functionality but you must resist the urge to cover all of those use cases and errors that could possibly occur. Outlier cases can stay on the fringe.

In the above example, we're replacing a manual process that uses, you guessed it, spreadsheets and emails, one of the perfect business cases for IPA. The customer is going to get significant value from the process, even though we're not including a business rule to allow them to update all of their data.

Have any other suggestions of what not to include? Feel free to drop a comment or contact me.

Happy Processing!

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!

Introducing Your New IPA-Powered Rewards Program

This our first guest blog posting here at ProcessMyBiz.com and thanks to Ross for his contribution! Ross works at ININ as an IPA Template Developer in Marketing, getting to do, among other things, really cool kick-ass stuff for the upcoming ININ Marketplace! Enjoy!

Introducing Your New 

IPA-Powered Rewards Program

by Ross Blaettner

In a group or team environment, how does work become an addictive, enjoyable, and entertaining experience? Live statistics? Leaderboards? Free pizza? Vacations? Rewards? All of the above. Definitely.

Example Gamify Dashboard

It’s no secret: people love getting rewards. The newest consumer loyalty and incentive programs, from airlines, to restaurants, to banks, add a little glamour to our routine lives. Businesses give away free stuff to encourage participation and to reward customers for being good customers. The extra gratification may be especially important, adding a little spice to otherwise bland business transactions. Participants may get a little enjoyment, satisfaction, and achieve some status but, as in Vegas, the house always wins.

Casino games (games, in general) can be addicting and rewarding. It’s nice to conquer a level, defeat a competitor, to win a seemingly limited supply of something. The house designs the rules and earns the profits. The participants give their time, money, and energy, and just enjoy the game. The players study the rules, the processes, the interactions, learn to play, and play to win, all within the context of the game sponsor’s overlying goals. At some level, certainly, this is about friendly competition and making ‘work’ fun.

After all, work is about rules, profits, time, money, and energy, processes and interactions, competition and winning. In our core biology, people are born to survive, to enjoy the game, and to thrive as a collective.

Business is once again learning from those areas of human psychology and development. The gaming industry has captivated billions across the world. Give people activities they can enjoy, and prosper as a business. “Put the ‘fun’ back in functional.” Design the software and use performance data to accelerate growth. Now, on to the next level...

How can IPA and Interaction Center harness “game mechanics” in customer environments? 

1. Read:  "Using Game Mechanics in User Experience Design"
2. Watch:  Applying Game Mechanics to Functional Software
3. Review:  Gartner Press Release about Gamified Innovation

In a follow-up post we’ll apply game mechanics to “gamify” some example IPA processes.

In the meantime...

Happy Processing!

ps - feel free to contact Rick if you'd like to submit or collaborate on a guest blog post.

Contribute to ideas.inin.com for IPA

Hey there Process True Believers! In the not too distant past, ININ has made a slick new website available for posting, voting and collaborating on ideas for their products: the not so cryptically named ideas.inin.com!

Of course the site is only open to employees, partners and customers. If you're among the few and the proud, please get on ideas if you're not already there.

Interaction Process Automation has its very own topic, which you can find along the right column when you login. I've posted several IPA ideas myself this evening, which are all aimed at effencies:

1. Process Variable requests
2. Button action to minimize a Work Item back to My Work Items just like clicking x
3. Reason not required when you Cancel a process in Test mode
4. Select the data in the next field of a Work Item when tab is used to move between fields

Feel free to comment/expand on them and add your own ideas.

Happy Processing!

IPA Design Best Practice with an Actions Process

An Actions Process is created to act as a library for your main process so the main process does not necessarily always have to be republished in order to make changes. Here's a quick overview:

1. For each process you implement, create a second process with the same name ending in Actions.
2. Call the Actions Process at the start and end of major steps in your Tasks in the main process with a text tag to indicate what you've just done or are about to do.
3. In the Actions Process, have a Select statement evaluate the variable passed as the tag. If it's found, do some work. If it's not, drop through and do nothing.
4. As you find the need for minor tweaks, notifications, etc., consider if you can add those to the Actions Process instead of having to enhance and republish your main process.

Once you start doing some implementations during IPA, as with all custom software, you may notice the need for some tweaks after the initial go live. We discovered that with the Timecard Process, and had to make a few adjustments for the unforseen during the first week in production. The rest, including several enhancements, will be done in Phase 2.

Generally speaking, the larger and more complex your IPA process is, and the more active processes you have running, the less the frequency you want to republish that process. If you implement your process with Restart/Reroute design logic, which is a topic I'll cover in a later post, it gets easier to publish changes to a process in production. The Actions Process is something to build into your main process up front to reduce the need for the main process to be republished.

Some changes related to providing a notification once the Timecard was Submitted by the Team Member. Initially at go-live, largely due to the "need it yesterday" time constraint, we simply sent a basic email that said "you've successfully submitted your timecard," and left it at that.

In phase 2 we're going to enhance that message to include the data entered in the Timecard. With 70+ fields on it, that email will take some time to format with variables we'll pull from our Database Driven Design (of course).

Enter the Actions process into the Best Practices for IPA. When the Timecard Approval process was created, I immediately also created a process called Timecard Actions. Actions is called all over in the Tasks for Timecard Approval. As you may or may not know, a Task is the only place you can call another process in IPA. All that is needed to call Timecard Actions is a TimecardID, which is how we track individual timecards in the database, and some kind of a tag to indicate what just happened in Timecard Approval process.

In the example with the email notification, right after the Team Member clicks Submit on the Work Item for their timecard, the next step in the Task after we're done with the Work Item is to call the process Timecard Actions with the TimecardID and a tag for "Team Member Submit."

Over in the Timecard Actions process, we only need one State. That State calls a Task that has a Select step in it. All the Select step does is see if the label passed to Timecard Actions is found. If it is, we have some work to do. If it isn't, the call to Timecard Actions is currently a "no-op" and we just fall through the Timecard Actions process without doing anything.

Currently there are at least a dozen or so calls in Timecard Approval to the Timecard Actions, but as I've said we're only using one right now for the notification. The beauty of an Actions Process is I can enhance the format and data in the email notification and republish Timecard Actions without having to touch my main process, Timecard Approval.

Another benefit is in the future, if we have needs to implement other notifications, we can simply enhance Timecard Actions to add the label sent over from Timecard Approval, which means we can do some work in a Task whenever that call in Timecard Approval is made to Timecard Actions.

Lastly, an Actions Process is useful for debugging purposes while you're developing your process. Since there are many calls to Actions throughout your main process, they act as "I made it here" points in the main process. Instead of adding extra debugging code in your main process, you can simply add and remove tags from the Actions Process as needed.

Generally speaking I'm calling an Actions Process with the Wait To Complete radio button set to No. If you would need to wait to do processing, that logic probably needs to stay in your main process as a rule of thumb. Save the Actions Process for simple stuff like sending a notification, which might start as an email but later turn be enhanced to also call a handler to make a phone call.

Once you become familiar with IPA you'll realize it's helpful to minimize publishing your main process. With the Timecard Actions process, I can enhance the email, just republish Actions and the next Timecard benefits from this new feature without having to re-publish the main process. This IPA Best Practice, by the way, of course came from the Punk Rockers. Brilliant!

I covered the Actions Process when I co-presented at Interactions 2012 last month and my apologies for not getting this post out sooner as promised.

Have any thoughts on the Actions Process? Feel free to share them in the comments.

Happy Processing!

IPA Product Manager Position Open at ININ

I originally heard about this opening from Gina Clarkin at Interactions 2012. She's the current product manager for what is referred to as BPA and ECM at ININ. BPA obviously stands for Business Process Automation (read: IPA) and Enterprise Content Management. ECM is the offering that has resulted from rebuilding the Acrosoft document management solution (from scratch) after ININ acquired Acrosoft in 2009.

Great job Gina and congrats on your new position at ININ!

For anyone interested here's the link to the current job openings at ININ on their website. Look for the Product Management section and select Product Manager, BPA & ECM.

Good luck prospective candidates. I look forward to working with you!

In the meantime, Happy Processing!