IPA Best Practices, Design Techniques, tips and tricks, from the field and from inside the vendor, relating to the Interaction Process Automation product from ININ / I3 / Interactive Intelligence, Inc.
Author is Rick McGlinchey, an I3 employee from '97 to '08, who now works as a Process Architect and Consultant for Hire.

Pages

Sunday, April 15, 2012

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!