IPA MarketPlace Download to Deployment Part 2

Hello again folks! It's been a while. I've been busy working on some more IPA projects plus an internal deployment of Interaction Analyzer at ININ that does a hand-off to IPA, but more on that later.

Today we're going to check out Ross Blaettner's article continuation of his previous piece, IPA MarketPlace Download to Deployment.

This topic is targeted at IPA Template and other developers who wish to sell their ININ wares on the ININ MarketPlace. We're assuming you're already on board, but if not, get signed up for the ININ MarketPlace with Dionne Flickinger and tell her RickM sent you.

Also, don't forget to get yourself registered for ININ's Interactions 2013 if you haven't already. The theme this year is "Deliver the Experience" and I'll be co-presenting on a couple of sessions on IPA with rockstars like Geoff Calhoun and, of course, Jason Loucks (as we did at Interactions last year). More on that before the conference. 

For now, take it away Ross and thanks again for your contributions!

MarketPlace Download to Deployment, Part Two:

Everything, and the kitchen sink!

by Ross Blaettner

There’s something special about the allure and mystique of a secret recipe. Surely, the ingredients exist—we might recognize them in their individual parts. However, it’s their varying combinations, preparations, and inspired creativity that make great cuisine.

The chef’s challenge is to concoct a palatable solution with wide-ranging appeal and consistent reproduction.

(Hopefully, you are making the connection with a pleasant installation experience, using varied operating environments, while achieving repeatable, quality deployments. If not, well, you are now.)

Here is a starting list of ingredients in my metaphorical kitchen. Feel free to add, or substitute with, your own. By the way, these components are freely available and graciously linked for the so inclined.

• Automate the OS: Auto-It
• Package the solution: Advanced Installer
• Tweak the settings: InstaEdit
• Verify and analyze: WinMerge
• Distribute to the masses: Interactive Update
• Monitor feedback: IC MarketPlace

Start with Auto-It. The macro language, with its basic-like syntax is refreshing, surprisingly powerful, and abstracts mundane OS details. It also interacts nicely with the Windows UI and GUI-based applications. At their primal core, the scripting commands originate from the IT profession, for purposes of automated software deployments, configuration, and the like. Use Auto-It for fine-grained control of operations, settings, and integration. You could quite practically build a basic installer with Auto-It alone, but more appropriate and overall effective tools follow.

Remember, pack what you will need. Regardless of whether or not you would want to, you cannot feasibly oversee every deployment of your solution. In that case, you need to package your intelligence and necessary resources into an automated installer. Advanced Installer provides a free offering that will copy, pack, unpack and install files, and generally get the table set for the next course.

If you need to tweak the install tables, you certainly can—with InstaEdit for MSI-based packages. The generated install packages contain, among other resources, tables of relational instructions that can dramatically alter the experience and “flavor.” Sometimes, some extra spice is good, and sometimes it’s not. Consult the guide. You’ll just have to test and decide.

If neither here nor there, check with delta, i.e., WinMerge. You can certainly test the generated installer by comparing conditions before it starts and after it finishes. Examine the difference to see what happens. Are you getting what you ordered?

Interactive Update. With all due compliments to Interactive Intelligence, this is the toaster oven of speedy rollouts. If your solution requires delivery to multiple destinations within an organization, then Interactive Update is one simple and intuitive option. Network administrators can associate MSI’s or MSP’s, a la Advanced Installer, with Interactive Update, for automated, scheduled deployment. Presto.

Come back again soon, to the Interaction Center MarketPlace. Socialize with the community. Exchange ideas. Monitor ratings and reviews. How is your solution performing? What general guidance can you provide to your install base to invigorate their interest? Is it time to update your recipe, to keep things new and fresh?

When you’re ready to improve or innovate, create an MSP revision from Advanced Installer. Zip and send it to MarketPlace@inin.com. Make sure that it’s ready to serve for the next appetite.

What are your favorite installer tools and utilities?

Interview with ININ Product Manager Geoff Calhoun

I had a chance to sit down recently for a little Q&A with ININ's Geoff Calhoun. Geoff is the Product Manager for IPA and Interaction Content Manager (ICM) at Interactive Intelligence.

Now keep in mind I'm no journalist and I'm biased as hell when it comes to ININ and IPA in particular. Some of the questions are blatant setups and I won't apologize for that. Enjoy.

Q: So Geoff, How did you first come to know about ININ?  

Calhoun: About six years ago at the previous company where I worked we were looking to replace our PBX system. We brought in CIC just for dialer at first and then when we got a demo. After that we decided to deploy CIC 2.4 to the whole enterprise. J

Q: What drew you to the company and the product manager position?  

Calhoun: I love the innovative atmosphere and all of the nice people at Interactive. I have thought about working for Interactive for years now. Having been in application development and support for a long time, I wanted to get out in front of the development processes, to get to guide where a product went in the Market.

Q: Anything about your background you'd like to share?  

Calhoun: I have been in IT for almost 15 years. I actually started at my last job as data entry clerk and after 14 years was the director of development and reporting. Went through all areas of IT from desktop and server support, to infrastructure installation and maintenance, and then on to database and application development.

Q: What's your vision for Interaction Process Automation longer term: go viral within the existing customer base, expand into IPA-only customers to compete with the variety of solutions, or something else?  

Calhoun: All of the above and more. My overall vision is to create a BPA product that everyone wants in their companies. IPA needs to continue to evolve its ability to bridge the gap between the ability to have complex integrations and being simple enough for a Business Analyst to develop process flows.  As to the specifics, well I am still working on that part.

Q: It's great to have someone helping drive the product who has used it as a customer. Is it a fair statement that every ININ customer could benefit from IPA in some way?

Calhoun: Absolutely. EVERY company has processes that can be automated.  From simple time sheet processes all the way up to something like a complex order management process.

Q: Where should customers start with IPA for their best chances at success? 

Calhoun: Start with a small process. Not because IPA is a complex product or hard to use, but because process optimization is very complicated and most companies don’t have subject matter experts in that area.  Don’t be afraid to bring a consultant if needed.  Be sure to do an as-is process map along with your to-be process map.  You will learn an enormous amount of useful information and probably be very surprised with what you find.

Q: Any new IPA features you can share that are particularly exciting to you?  

Calhoun: We are working on a web client for IPA that will be fantastic for users who don’t need our full features .Net client.  Also, we are working diligently on getting IPA into our cloud environment so that those customers can take advantage of all that IPA has to offer.

Q: Any plans to engage customers/developers of IPA outside of the Interactions Conferences?  

Calhoun: Absolutely.  I will be reaching out to many of our customers to understand how they are using IPA and how it can be improved.  Also, I will be hosting events for developers to help them share their best practices and learnings related to IPA.

Thanks to Geoff Calhoun of ININ for being a good sport and spilling the beans on IPA! He and I will be co-presenting an IPA Best Practices session called "Looking to automate business processes? Start here!" at ININ's upcoming Interactions 2013 in May in good old Indianapolis, IN, USA!

Until then...

Happy Processing!

IPA MarketPlace Download to Deployment Part 1

Hi there fellow IPA-lovers and Happy New Year! Well I guess that holiday greeting is a little belated, considering we have almost reached the end of January, but that's life in the Big City (of Indianapolis)...

Here's an article written by ININ's own Ross Blaettner, a guest blogger here at ProcessMyBiz.com with his second contribution (of a two parter, no less). You may recall an earlier post from Ross on gamification.

Ross works at ININ as an IPA Template Developer the Strategic Initiatives team, a fine group I've had the pleasure of working with on a couple of customer engagements for IPA. He and the gang are gearing up for launching the MarketPlace at ININ, which is very exciting stuff for IPA!

This time around Ross is helping us get ready to share IPA Templates and other stuff on the ININ MarketPlace.

Thanks again for your contributions Ross. Everyone else, enjoy!

MarketPlace Download to Deployment, Part One:

The Case for Next, Next, and FINISH!

by Ross Blaettner

When you buy and try new tech gear, do you ‘plug and play,’ or ‘plug and pray?’

Apparently, one letter—essentially, one factor—can re-express your entire deployment experience.

Perhaps this vital character forms the difference between seconds and hours, satisfaction or frustration.

(And there’s more to this question than comparing optimists versus pessimists.)

Enter the determinists. Fortunately, there are factors within development control. “Yes, you can get a fortune cookie and write the message, too.”

The implied corollary: “Yes, you can write software and control the deployment experience, too.” So, let’s now focus on the gift of giving a good, consistent deployment, sending a consistent, predetermined and favorable message.

When deploying your solution, think about the host environment and conditions. What’s the best case scenario? What’s the worst case scenario? Importantly, what factors exist between those two outcomes?

Sometimes better documentation and step-by-step verification can isolate certain problems before they become ‘lost’ as elusive and confounding effects. Unfortunately, however, in practice, the quantity of documentation can be inversely proportional to likelihood of its adherence.

Then, documentation introduces levels of interference, due to differences in language, interpretation, format, or human error. Honestly, technical writing is a specialty of its own; the reality: there’s more involved than “technical” and “writing.” Of course, even if the documentation is perfect, the reader may be distracted, thereby skipping steps 5 and 13. If you provide support, how do you know that all steps completed successfully? When troubleshooting, it would be nice to give people the benefit of a doubt, but real-world experiences suggest otherwise.

Well, fortunately, in many cases, you can communicate directly, quite frankly, in binary, with the host machine. Here’s the key proposition: let’s wrap all of the prerequisites, preconditions, and setup activities into a solution-centric installer for a fast, efficient, and consistent experience, complete with logging and unbiased step-by-step assurances. Instead of requiring a captive IT professional to follow steps, give him or her freedom to take a short break while your installer works its magic. (Chances are, you will both fare better as a result of this latter approach.)

If you rely on a certain subsystem, check for its running state or even perform an interoperability check during the install. Can files’ existence, versions, or registry keys validate expected conditions? What are your system requirements? How can you query the operating system for its proof of compliance? How can installation routines prove that they have appropriate levels of system permissions?

As the installer continues, check every step for success. Communicate exceptional conditions through the UI, with an emphasis on strategies for resolution. Remember, the presence or versioning of just one file could make the difference between play or pray!

In a follow-up article, I will present a few free, easy and amazing tools for crafting your very own installers. Now, get your MarketPlace solutions’ step-by-step instructions and pseudocode ready for “Next, Next, and FINISH” convenience and automation!

In the words of Rick McGlinchey, “Happy processing!”

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.