Thursday, December 20, 2012

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.


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!

Friday, December 7, 2012

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!

Tuesday, October 9, 2012

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 ( 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!

Sunday, September 16, 2012

Introducing Your New IPA-Powered Rewards Program

This our first guest blog posting here at 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.

Wednesday, August 8, 2012

Contribute to 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!

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!

Wednesday, July 11, 2012

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!

Tuesday, June 19, 2012

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!

Thursday, June 7, 2012

IPA Biz and Tech Learnings to Share from Interactions 2012

The Interactions 2012 event in Indy was tremendous! Lots of good mojo about IPA was flowing from customers who presented to discuss their various states of deployments. We heard from healthcare, insurance, consumer electronics and other industries who were so excited about Interaction Process Automation they could hardly contain themselves (so it's not just me)!

Of those customer presenters, it was my distinct pleasure to see both business and IT representation from a global medical diagnostics manufacturer discuss efforts on their implementation with IPA. They're automating a couple of relatively small processes for a proof of concept, which is a great way to get started with IPA. I've been doing the consulting on As-Is and To-Be for one of those processes. The session was a lot of fun and equally gratifying regarding our experiences with them to date.

As for our IPA session at the conference, Mr. Jason Loucks did a bang up job discussing Eventing, Log tips and tricks and other details and was kind enough to leave me plenty of time to plough through "light" topics like the Database Driven Design, Restarter Process, and Actions Process design best practices. We had some long time ININ partner and customer tech folks in the room who ate it up. Our apologies to any business-side folks who weren't expecting a deep dive.

The lab that Development ran gave us a great sneak peek at some up and coming features with IPA.

I'll write in more detail on some of the points in the future. For now, here's some food for thought:

Business Considerations
  • Involve all of the stakeholders in the business and IT from the start.
  • The making of a process with IPA: As-Is first, To-Be and Work Item mock-ups second, implement third. No exceptions.
  • An IPA deployment done right takes time, so be reasonable with expectations.
  • Take a bite of the elephant (processes) to start, not TheWholeDamnThing. In other words, don't try to automate your entire business to start.
  • User Experience and good GUI design is critical for IPA Work Items.
  • MarketPlace!!! MarketPlace!!! MarketPlace!!!
Tech Stuff
  • The Data Grid View for Work Items is huuuge!
  • Eventing will change the way you process with IPA. More on that later.
  • MarketPlace!!! MarketPlace!!! MarketPlace!!!
Yes the MarketPlace is going to be superfreakingcool in case you were wondering. Think App Store for IPA Templates and other custom offerings for ININ solutions. Can't wait until ININ has something live we can share. Your truly will be making IPA Templates available for sale there for sure.

Feel free to drop a comment about Interactions 2012 or any requests for further detail on the above points.

Happy Processing!

Saturday, June 2, 2012

Co-Presenting IPA Best Practices at the Interactions 2012 Conference Event for Interactive Intelligence

Hey there IPA Process-meisters! I'll be at the Interactions 2012 Conference event for Interactive Intelligence the week of June 4th. I'll be co-presenting with Jason Loucks, an IPA Template Developer at ININ on Interaction Process Automation IPA Best Practices.

Here's the details on our session:

IPA Best Practices, Tips and Tricks
Tuesday June 5, 2012 3:45pm - 4:30pm
Room 103 - 104 at the JW Marriott, Downtown Indianapolis, IN

This session will highlight some IPA best practices and help you avoid some common pitfalls. You will also get an overview of Database Driven Design and how to add eventing to your processes. As if that wasn’t enough, we’ll also share the log filters that we commonly use.

Check over in the right column for my schedule at Interactions 2012 and click on the Interactions 2012 header to see the full schedule.

Feel free to look me up if you'll be in Indianapolis. Hope to see you there!

Happy Processing!

Sunday, May 20, 2012

IPA Timecard Process Published

Hey there IPA True Believers! Granted it's been several weeks since I've put up anything new here and the main reason is I've been heads down with a customer putting a process in production, which went live this past Friday! This was not a large, complex process but rather a smaller, complex process because remember, there's no such thing as a simple process to automate with Interaction Process Automation (IPA).

You Mission, Should You Choose To Accept It: Make This Suck Less
The customer was moving internal systems for tracking time-off requests and as a result they would no longer have the ability for their hourly employees to submit timecards. Prior to this solution they had a... wait for it... a manual process with emails and spreadsheets, which seems to be pretty common, low hanging fruit that's a perfect place to start with IPA.

The basics of the process are as follows:
  1. Non-exempt (hourly) Team Members submit time sheets for a two week period to their Supervisor.
  2. Supervisor can Approve or Reject a Timecard. Approve sends it along to Payroll, Reject routes it back to the Team Member.
  3. Payroll can Reject to Team Member, Reject to Supervisor or Approve the Timecard.
Sounds simple enough, right? Oh I didn't use the word simple. Nope. Far from it. We're using Active Directory via a Handler to pull the Supervisor of the Team Member, another Handler to grab the Process Version and lots of other fun stuff that made this anything but simple. Did I mention the Timecard Work Item has over 50 Edit Boxes on it? Try placing that many fields plus labels on a Work Item. I have a tip on that for another upcoming post as well. Looks pretty once you get there but it takes considerable effort and good GUI design to make it usable.

They had a very short timeframe, which hopefully is more of the exception than the norm with an Interaction Process Automation deployment. From contract to Phase 1 go live, we were just a little over 5 weeks, which was very aggressive moving from As-Is, To-Be flows and Work Items, to go live this past Friday. Thankfully the requirements were manageable so the initial consulting with As-Is and To-Be were relatively short, with the bulk of the effort going into implementation, testing and training.

Keys to Success:
  • Phase 1 requirements management - with an aggressive timeline the best way to set everyone up for success is stripping down an absolute minimum set of requirements and making sure to keep it simple, because it's easy to start going sci-fi with all the tools of CIC and the unlimited potential of Web Services.
  • Well Defined Existing Process - we weren't inventing anything new with this process, we simply moved it out of emailed spreadsheets into Interaction Process Automation. Granted there are many super neat-o keen things we did with Phase 1 and additional upcoming Phases, but it's helpful with a tight timeline to have a nice, smaller-ish known existing process to get started with a client.
  • IPA Best Practices - I was able to incorporate the Database Driven Design (with the kick-ass 4.0 SU1 IPA Database Tools woo hoo!!!) and what I'll call an Actions process into the Timecard, both of which set us up for ease of making changes in the future.
  • Done is Better Than Perfect - and I tend to cringe at this being somewhat of a perfectionist. I'll add some more error handling as we go but suffice to say in our training sessions I emphasized if you try to break it you probably will. We were on a very aggressive timeline so some of the finer points of error handling were not possible due to time constraints.
Quick aside about an Actions process: I'll dedicate an upcoming post to this but for now suffice to say it's helpful to create a secondary process to accompany each main process you build with Interaction Process Automation. Right now the Actions process sends emails on Submit. This will make it easy to introduce more detailed email notifications without having to re-publish the main process.

Click Me To See The Awesome!
Here's a peek at Timecard Work Item (from hell) for the Team Member to Log Time. It's got big, sharp pointy teeth. Look at the bones!!! Oh I know what you're thinking, why are Changes Saved on the screen? Well we don't have a modeless dialog to pop such things in IPA, at least not at this stage...

So we're live and will be adding some additional features and fleshing things out a bit more, time permitting (har har). For not it's onto some slightly larger and more complex processes with the same customer to implement with Interaction Process Automation.

Speaking of IPA Best Practices, I'll be co-presenting with Jason Loucks, an IPA Template Developer at ININ, during the upcoming Interactions 2012 conference next month in Indianapolis, aka, the Heart of the Silicorn Valley. Hope to see you there!

In the meantime...

Happy Processing!

Sunday, April 15, 2012

The Importance of the As-Is Process Flow with IPA

A colleague recently asked me if it was helpful to create the "As-Is" process flow before the "To-Be" flow. In short, the answer is "hells yes", it's absolutely critical to the success of an IPA deployment!!!

"As-Is" should be viewed as the Yin to the "To-Be’s" Yang. Definitely worth the time because together, you and the customer need to agree how they’re doing it today. As-Is helps put that visual together on paper so the stakeholders, subject matter experts and the implementation team can see it, discuss and finally sign-off. Gotta have sign-off before moving To-Be yo.

Since the process isn’t yet automated, different people tend to think it works differently than it does and/or some folks might be doing it different ways. This has been validated to me by Rachel Wentink, Director of Strategic Initiatives in Marketing at ININ and other on her team on the Lighthouse Program for IPA program implementations. Her team has done several deployments and have many a story of questions and confusion during the As-Is part of the engagement. Folks get to talking about what they do and find:

  • Subject Matter Experts might not all follow the same manual process today, even if that process is documented. They might have shortcuts or gaps in knowledge that prevent them from using the documented process, assuming the existing process is documented...
  • Management usually finds the As-Is part of the process a learning experience for them. "But we don't do it that way" or "we're supposed to be doing it like this" they'll say, and the Subject Matter Experts shake their head and say "well this is how we're doing it today." All good notes as business rules when you get to To-Be.
  • The Implementation Team uses As-Is to insure they understand terminology of the business as well as identifying discrepancies, gaps and manual labor-intensive aspects of the process.
  • Looking back at As-Is as you further evolve the To-Be in later phases can be helpful, lest you repeat mistakes made before you started automating with IPA.

Rachel's team typically allots 40 hrs on site (the better part of a week) to document and agree on this.

Once we agree what they’re doing As-Is, then we can talk about the To-Be, which is typically blocked out for a week as well, because remember, there's no such thing as a simple process...!

We use the term "quick start" as the initial process or sub-process selected to automate. One of the projects I'm co-leading is a massive internal process that touches almost every department in the organization. It's simply too much to expect to automate TheWholeDamnThing for phase 1, which might explain why the project has stopped and started a few times in recent years.

Unless the process happens to be very small, which few are, for the quick start, it might be more of a focus on one area that’s a bottleneck or heavily repetitive task. That's where you'll get the most value with an Interaction Process Automation IPA deployment. Then long jumps toward the rest of the process.

Especially with the early processes you'll want to take, not so much baby steps, but reasonable steps to add value but not bite off too much at the start. Make sure you take the time to document the As-Is flow with your customer!

Monday, March 19, 2012

Using a Database Driven Design with IPA

The Database Driven Design is a consideration for every process you automate with IPA. That doesn't mean every process will require a Database Driven Design, but I suspect most will if they're of any size, complexity and/or duration (start to finish elapsed time for the process).

As with many of the Best Practices I'll post here, the concept of a Database Driven Design for your IPA Processes most definitely is not mine. I'm not the creator, merely the conveyor. The concept originated with a couple of guys deploying, maintaining and ever-enhancing a large, highly complex internal process that also has customer facing components at a software vendor with which I am vaguely familiar. I'll simply refer to them as the PRs, short for Punk Rockers. Anything else I call'em would probably too easily identify them and where they're employed, and they're plenty busy as it is.

Much thanks to these gents and their 3rd partner in crime for their willingness to share their lessons learned, which are the foundation of the evolving Best Practices for IPA. Without their insight, the IPA community would collectively have to stumble across applying these concepts the hard way. Thankfully, they've already applied considerable thought to some common problems they already encountered, so we won't have to. We'll find our own challenges along the way, of course...!

The PRs have been working with IPA coming on a couple of years now, and I'll go out on a limb to say they're probably the most experienced with deploying IPA. As a result, mostly over time and through trial and error, they've developed many of the Best Practices that I'll explain in detail as I'm applying them to my own IPA deployments.

So one of the first things I was told by these Jedi Masters of IPA was "Use a database driven design, you will." I nodded slowly as I wrote this down in my trusty old school black cover composition notebook. "Yeeeesss... a database driven design," I mumbled as I double-underlined the words before finally looking up and saying "um, what the heck does that mean exactly?"

"Well," one of them began, "there are several reasons to use a Database Driven Design in IPA..." and a fury of note-taking and questions ensued for the remainder of our session. The concept is as simple as it is powerful, and I'll use my Finance Purchase Order (PO) Request to illustrate.

The first point is having a custom unique identifier for your entire process instance, including as it calls other processes and external systems. The CIC system and IPA will assign a unique process identifier, which we'll call processid or pid for short. For the CIC-initiated, processid is like the callid for the process, a unique, system-generated and assigned number for an IPA process. This is very helpful but it's not really what will benefit us the most as a unique identifier for our overall process because we might call additional processes from our main process.

Here's an overview of the Database Driven Design concept:
  1. Each time when a new process instance is launched, it will first go out to a custom database for that process to pull a new unique, Custom Process Identifier (or cpid for short). The cpid will be used throughout any activities associated with this process instance.
  2. The process will then immediately update that record for the cpid in the custom database with initial pertinent information, such as the requesting user and initial State. 
  3. As the process moves through it's various States, Task, Work Items and any associated Actions, there will be frequent updates to the database for the custom processid for the process.
  4. This means, at any time, we or our process can look in the custom database and see where all of our processes are State-wise and also any data associated with it.
Clear as mud, right? Let's move to the example and dive right into the custom database.

The PO Request will have a custom database, or custom db, for storing all of the required process information associated with each individual process run, such as the management approval chain that will be passed Work Items to Approve or Reject the request until the proper approval level has been reached. The custom db will also store dynamic business rules that are created along the way, which will be covered in another post.

Concerning the PO Request, my first Work Item when someone launches the PO Request will give the Requester the opportunity to create a new PO Request, or simply click the link to the Sharepoint page we're setting up for status and reporting purposes. Notice I didn't say anything about hitting the database to assign the cpid yet? The purpose of this first Work Item is to give them a chance to see the status link if they haven't bookmarked it, so we don't burn through PO Request IDs needlessly.

If the Requester has launched the PO Request process to actually request a PO, and if they click Next instead of Cancel, that's the first time we'll hit the database to assign the cpid, which in this case would be referred to as the PO Request ID. The name of the cpid will be determined by the type of process you're creating and language of the business that will use it.

Benefits of a Database Driven Design in IPA:
  • Use fewer Global Variables in IPA - leaving more system resources available to CIC. It's always good software development technique to use Global Variables sparingly, regardless of the system or application. With a custom database and a unique custom process id for each instance of your processes, basically all you need to pass around is the cpid, which also means fewer changes to functional calls since the parameters passed will tend to be fewer with adds going into the database instead.
  • Re-starter Processes after Re-Publishing - so that active processes can pick up the changes. I'll cover the PRs concept of a Re-starter Process in depth in a later post, the whole goal of which is to allow you to re-publish your process and re-start all of them from scratch. Much like a handler, a process instance lives until it's complete, which is fine for phone calls that usually last no more than an hour or so, but a process instance might last up to weeks or months. Make a change to the process and you can Re-start all of your processes to pick up the changes.
  • Custom, Detailed Real-Time and Historic Reporting - that is, if you make data available via any kind of pulling mechanism, such as Sharepoint page or a custom report. We'll cover custom reporting in an upcoming post. One point to consider for now is the out-of-the-box reports for IPA will contain State Labels, outcomes and other info along those lines, but not many deeper details of the processes and their custom data.
Considering Reporting, think of CIC and calls. We can use call detail and Distribution Queue Reports reports to get volume information, IVR reports (assuming we've enabled them and used meaningful labels in the Attendant Profiles...), Recorder and iFeedback. The IPA Standard reports will cover basically the equivalents to call detail and Distribution Queue Reports. Knowing more about what's happening inside of your process requires custom logging and therefore a custom database to get the equivalent data in IPA that roughly correlates to IVR Reporting, a recorded call and iFeedback for calls.

Now one important question to ask might be when wouldn't I use a Database Driven Design? I'm pressed to think of any to be honest. The process would have to be short lived and infrequently used to avoid spending a little time up front to use a custom database. There might be a customer application that does not want a detailed record of in-process data, even though they risk losing a process instance if the system is taken offline before a process completes. I'll update this post if any concrete examples arise.

The IPA Design and Implementation Certification course that I completed at ININ did not use a Database Driven Design for any of the labs, but that's largely because the concept didn't exist when the material was written. The course is going to be re-written and hopefully we can get some of these Best Practices worked into it.

Storage is cheap these days and from a system resource perspective on the CIC server, it's more cost-efficient to have a few more database calls than to store all the data for a process as global variables, especially if there's a lot of data and a lot of concurrent process instances running. I'd expect all of the above to be typical.

For any business making the effort to use IPA to automate a process, they should strongly consider the Database Driven Design! Once again many thanks to the PRs for their valuable input an insight into this IPA Best Practice.

The concept of a Database Driven Design with IPA is a breeze to illustrate or talk through pretty easily but as you can see to write it out is more involved. Comments are especially welcome if there are areas in the article that can be enhanced for clarity.

Happy Processing!

Monday, March 12, 2012

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.

IPA is the Greatest Thing Since Sliced Bread!

Hello Process World! I'm Rick McGlinchey and this is my blog about all things related to Interaction Process Automation IPA from I3 / ININ / Interactive Intelligence, Inc.

I worked for Interactive Intelligence, Inc. for over a decade and did all kinds of stuff before taking a break, then branching out on my own. I still do some work for them, and others, as interesting projects come up. More on my story another time.

So why blog about IPA? The answer is simple: Interaction Process Automation (IPA) is the greatest thing since sliced bread. I'll go so far as to say Chuck Norris is the best thing since IPA (thank Kev)! Yes, those might be an outrageous statements. To put it into slightly more realistic perspective, it's at least the greatest thing since the product initially known as Enterprise Interaction Center (then Customer Interaction Center and EIC and now... back to CIC) and here's why:
  • Save Time, Paper and Rework - The obvious one is you can save time (read: money) by automating processes.
  • Consistency - For companies that need to deal with compliance, regulation, and other fun stuff like that get a product that allows you to run your process consistently.
  • Dynamic Processes - let's your procedure behave more like a guideline (that's ISO:9001-ese), but still with constraints. In other words, you can branch off or change directions with decision points as needed based on user input or other data.
You can read more about the product on the IPA page of ININ's website. There's also a short, 3 video segment of a customer case study on AccuQuote that ININ put up on YouTube. Definitely worth watching.

But that's the obvious stuff.  There's more magic with IPA. In addition to the intent and benefits of the product, I'm jazzed because with IPA we finally get a GUI on top of all of the power of CIC!

Let that sink in a minute... Light bulb still not going on? Read on. First some history if you can tolerate some MindFibre(TM):

I've thought for years it would be huuuge (wink wink, nudge nudge) to have some GUI tools in Interaction Designer, but they never arrived in that manner. Since the 90's there have been API's to create applications. In the bad (I mean really bad) old days, the first and only was using a dinosaur and somewhat unreliable interface known as DDE. Sure it worked, mostly.

Then came the COM API. The Interaction Client wasn't written with it, mind you, so there were some things you could do with it the Client couldn't, and vice versa, and people built some slick applications. Slick, custom applications in C++, VB and the like, which is fine if you have that sort of developer resource available.

Finally ICELib arrived and with it the 3rd party developer API was now the same one used to build the Interaction Client. Since the early part of the last decade we've had Generic Objects available. Support at I3 has been using them for years to use the ACD for routing tickets with skills. So have some notable reference customers. 

Still, ICELib and incorporating generic objects to deliver a solution is pretty involved, relatively speaking.

With IPA, to bust out an antique term, we now get a complete 4GL. Woo hoo!!! Some folks might even consider it KML on top of CIC, but I digress. Now we have GUI. I don't necessarily have to define a business process to automate. Sure I can do that with IPA and it's super-honkin' powerful, don't get me wrong. Anything I build with IPA is a process to be sure. I can ALSO write a variety of applications big and small that require user input and use them to leverage all of the goodies and power of handlers, notifications, databases and web services.

You don't necessarily have to automate a process to get use out of IPA. Imagine a small application that requires user input and functionality of CIC such as placing a call. Now you can do this within CIC without having to build a 3rd party application, and without having to dive into C# or other programming languages. The beauty is it's maintained version to version as you upgrade CIC without having to recompile, adjust for changes in an API, etc. CIC and IPA take care of all of that for you. Brilliant!

Is anyone going to buy CIC just for IPA? Eventually, probably. I hear it's already helping win CIC deals because customers know they'll want to automate processes. The other huuuge opportunity is with existing customers. They already bought CIC. Wanna automate some processes, or build some custom apps with GUI to leverage CIC's communication capabilities? Just activate some licenses and you're off to the races (now complete with a GUI)!

In short, IPA is a kick-ass product with enormous potential. I don't know about you but I'm as geeked about IPA as when I first drank the punch with CIC back in 1997!!!

Feel free to share your thoughts, preferably about IPA if you have a minute.