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!

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!

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!

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!

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!