Q. Persistent Data – when to store it “in IPA” and when to keep other systems (e.g. CRM, Incident Management, ERP systems, etc.) as the system of record / data store?
A. There's some considerations for this of equal importance. In short, generally at least a single custom table per process and ideally, the larger the process, the outputs are stored in another data store with the customer, so we're not building large, complex custom applications with their own island of data unless, after the conversation with the customer about pros and cons, that's what the customer really, really, REALLY wants (to pay for and maintain). Here's why:
- Duration of Process (minutes/hrs vs weeks/months or longer) - the longer the life of an individual instance of the process must run, the more you should consider using a database driven design to allow for existing processes to pick up new changes and also to insure survivability of your most important process data. Note I didn't say all. I recently attended a great support webinar on Troubleshooting IPA, given by Chiranjeevi Rathnaala, Senior PE in Support covering IPA and other applications type stuff. While there is survivability for events like switchover, you generally want to implement at least a single custom table of columns for your key data points, with one row per process in it for processes that are running into weeks, definitely if they're going for months. Lightweight stuff. This allows you to build your process with restart logic in it from the start, which is really easy to do on the front end.
- Reporting - I know, it's seems like reporting sometimes feels like the "bane of our existence" as solutions providers, right? Gotta ask the hard questions up front because, even more so than with IC, you could get bit, harder, by metrics with IPA if you don't understand what they provide vs. what they don't. The IPA out of the box reports provide more "call" type data like volume, handle time, etc, but they couldn't, for example, tell you how many outage minutes were reported for a utility or the discount provided on the insurance quote and by whom in the approval process. In 4.0 (at least SU3) for PCI compliance, when you create a new variable there's a checkbox on variables that says "store the final value in the database" which means it's there for IPA, but you'd need to write a custom report to parse some XML to get at it. With the Timecard process I built, metrics were covered in part with a SQL transform tool on a SharePoint page and some data was pulled directly into Excel (as we know is very typical with customers) for some additional number crunching.
- Data Store - or IPA as the data store vs. a 3rd party application like CRM, ERP, etc. The data store question is also covered in Building a Custom Application vs. Automating a Business Process with IPA, where reports and the data store are mentioned specifically.
- Exceptions / None of the above - when you're implementing a small "process app," which is what I call something that only routes to 1 person. No approvals, no inputs that need to be stores. For example, you can do some easy viewing of metrics, maybe even with some custom calculations on the data, in 4.0SU3 and later using data grids, that could just run a query and display some data.
Q. What about Troubleshooting and debugging with IPA?
A. The basic non-IC logs concept is covered in this troubleshooting suggestion from an internal session at ININ last year. I'll elaborate with a separate article and a process at some point. There was a good webinar from ININ Support recently that covered troubleshooting from the log side of things, which is one approach. For the process author who is coming more from the business analyst and consultant side of things, they'll want to build in their own "DIY log" built directly in the process flow as is mentioned in the link above, and I'll further detail some best practices around that in the future.
Q. A basic description of how to think about developing apps using the concept of states/stages in a process.
A. The general rule of thumb is create a State for each swimlane in your To-Be process flow, so that anytime you're crossing to another individual or workgroup you'll change States. That of course assumes you've gone through the effort of As-Is where you've documented the customer's business process and written a To-Be process flow that is specific to implementing the process with IPA. See the importance of As-Is and To-Be if these are new terms or if you're not able to articulate their necessity for that consulting time to a customer.
Implementing a "process app" could be an exception to this rule, if you're building something very small that's only routing to one user and not doing much. Remember you need sufficient documentation in the flows to share with folks outside of the immediate project team, so they know what you've built and for future reference.
Q. Got any good user interface design tips?
Q. Got any good user interface design tips?
A. Ah yes, you've realized at some point a human being, who probably doesn't implement communications solutions for a living, is going to be the end user of your process and consumer of the Pages on those Work Items! Kudos for that realization. So we have a couple of considerations for the User Experience (UX):
- Know your user(s). I'm adapting some Agile techniques to deploying IPA to insure I understand the personas of the users of the process, and there could be more than one. Is it just agents in the contact center? What's their profile, such as proficiency with a computer, experience (yes, including age so sue me for saying it), subject matter expertise, education, etc? When I say IPA is the greatest thing since sliced bread, there's a bit in there about it being the first time we have an easy way to implement a GUI for user presentation. And we need to consider what that means as we deploy IPA. Will one big-ass work item page crammed full 'o stuff cover it because your users have the skillz, or maybe should you consider breaking the inputs out over a couple, few pages on the same work item?
- Consider Good GUI design. Resources on UX abound on the internets. Your expertise with building Work Item Pages is sure to evolve over time, provide you keep in mind that humans are using the Pages. I'm not going to recommend any GUI/UX 101 resources but like I said there's tons of them. Personally, once I've taken the personas into consideration for the users, I tend to keep it simple and when I run into questions like "how to display radio buttons inside a group box" I tend to start with Microsoft's Reference for Controls. Not all are available in IPA, but it's an easy place to find examples.
- Data Grids Are Our Best GUI Friends! (4.0SU3 and later) - for folks used to using the Interaction Client, the Company Directory is a good example of a data grid, and they're available in IPA starting in 4.0 SU3. If you have to display complex data, like rows of stuff or anything resembling a spreadsheet, you'll be faced with working around the lack of the data grid. I've seen "formatted text" using Currier Font and spacing, that kind of turns out like a report run on an old dot-matrix printer, but it can work if you don't have a choice. Or... maybe considering upgrading to 4.0 if you're going to be doing a lot of this, because you'll be ripping out that "bandaid" and replacing it with data grids later.
- If the tools ain't there, consider a custom web page to accompany the solution. This isn't ideal since it's extra effort to build and maintain, but it can work, for example if you're implementing IPA with 3.0 and prefer more of a grid representation of your data.
So there you have it. Some good stuffs on Interaction Process Automation IPA to consider before you deploy. I'll flesh some of these topics and techniques out in the future, but that should be enough to get the juices flowing for now.
Happy Processing!
