Thursday, September 19, 2013

Past the Demo to Implementing IPA

Greetings IPA True-Believers and Happy Processors! I recently got a great set of discussion topics about Interaction Processor Automation (IPA) from some colleagues at Altivon, ININ Reseller since the bad old '90s that I've known since my pre-sales engineering days when I lived on the Left Coast. I'd like to address as briefly as I (a long winded talker) can. In addition to these quick hits, you might also check the "Getting Started" tab I added to the blog recently.

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:
  1. 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.
  2. 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.
  3. 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.
  4. 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. 
Unless you're in the process app business or hopefully starting small, because you can't start too small with IPA to start gaining experience with it, you'll usually need an existing data store and/or a small custom table. The partner and customer are both going to learn as you deploy IPA, more so than you did with call flow, because of the whole GUI component and workflow that goes beyond call routing.

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?
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):
  1. 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?
  2. 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. 
  3. 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.
  4. 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!

Monday, September 16, 2013

Choosing the First Part of Your Process for IPA

Note I didn't say which process, it's which part of your process to automate with Interaction Process Automation (IPA). Feedback from some folks I've talked to over recent months and garnered from places like community.inin.com and ideas.inin.com tends to indicate they could have started smaller. At a session at Interactions 2012 I half-jokingly asked a customer during one of the IPA sessions "Were you ever concerned that you started too small?" That got a few chuckles and they said quite the contrary, they had probably bitten off too big of a bite to start.

IPA is highly flexible and, depending on the complexity of the requirements, can be rapidly deployed. The challenge, however is to avoid falling into to the trap of building a sprawling custom application instead of keeping it simple to automate a process. Yes, IPA is custom software since you have to design it from the Work Items (screens / GUI) up, so keep this in mind when you're dreaming up the make-all, be-all process. If you're racking up the buttons that will go off and require a bunch of custom stuff with Handlers or other interfaces, ask yourself if this process is the appropriate place for the business rule.

A recent process I've implemented turned out to be not one, but 4 separate processes. We hashed it all out with stickies on the whiteboard and by the time it all ended up As-Is in Visio, we had 4 pretty complete 11x17 pages for 4 separate processes. Thankfully we immediately agreed to reign in the scope (and urge) to not automate TheWholeDamnThing for phase 1. The customer (internal ININ) has learned quite a bit about all of the manual stuffs that has to happen today As-Is, and while they're eager to get it all automated, implementing in multiple iterations will allow us to make incremental improvements along the way to maximize their ROI.

Especially when you're first getting started with Interaction Processor Automation, whether you're a partner or customer, try to remember your first exposure to CIC and all of the glorious tools, features, bells and whistles. The CIO of a customer presented at what used to be known as the Customer Conference several years ago and said "we saw all these features and were like kids in a candy store." Less is more applies with IPA as well and you will be better served with a scaled back, I'll dare say basic, phase 1 or first iteration for any new solution.

Keep in mind the Work Items Sprint as well to get the screens going soon so the user interface you've put on paper can evolve as it inevitably will. You'll learn plenty from your first processes, just like you did with Handlers, Attendant and CIC in general as you gained experience with them.

To Recap:
  1. Start small.
  2. Everyone will learn.
  3. Iterate and grow from there.
Happy Processing!

Thursday, August 8, 2013

Custom Applications vs. Automating a Process with IPA

Considering IPA? Or maybe you're an ININ Reseller looking to automate your first internal process to get your feet wet with the product. If either of these are the case, please read on! I had lunch with one of the IPA folks from ININ a while back and one of the topics we discussed was using Interaction Process Automation to automate a business process vs. building a custom application with it.

What's the difference?

Automate a Business Process
Employee Onboarding
IT Change Requests
Loan Origination
Insurance Application

Build a Custom Application
Case Management / Incident Management, such as a trouble ticketing system
Customer Relationship Management (CRM)
Just about anything where there are multiple off the shelf or cloud-based solutions available

While these two types of solution are similar, it's the areas where they differ that are worth considering before you implement. After Interactions 2013, where I co-presented at 4 IPA sessions and talked to lots of partners, customers and prospects about IPA, it became clear the initial customers deploying fall into one of these two types of solutions and the overall success and customer satisfaction varies depending on what type of solution was deployed.

When it comes to the Automate a Business Process, the best chances for overall success, customer satisfaction, maintainability and ROI present themselves when the customer has an existing data store.

Take AccuQuote, an early customer in the insurance industry, who had an existing brokerage management system. They wrapped IPA around it to great success. No secrets here - they reduced paper, increased efficiency, with all the value you'd expect from IPA. Watch the AccuQuote video and see for yourself. Yes, that's the same Geoff Calhoun who now works for ININ as the product manager for IPA.

Automating a Business Process and Integrating IPA with an Existing Solution
So you have an existing CRM solution, which after a couple of years in production does about 90% of what you need, but with some enhancement you could get to 95% plus for your most critical business functions. Might not be time to rip it out and replace it something new. Maybe there could be measurable gains from automating parts of it with IPA.

What do you gain from automating a business process around another solution?

  1. The Data Store - this is pretty huge. Less need to create a custom database, although you still might want to consider a Database Driven Design for the events when you republish and process and want to restart your running processes.
  2. Web Services - in the relatively modern world of tech solutions, these magical things called Web Services are available or can be implemented relatively cheaply. IPA happens to have an extremely slick Web Services Call Operation tool that does the work in one step for many SOAP-based Web Services. I'm told RESTful is planned, but for now let's just talk what's available.
  3. Reports - if you have a CRM, or as in AccuQuote's case, a brokerage management system, it already has reports that come with it. Remember IPA's reports are more along the lines of call-type stats: handle time, volume, etc., but not necessarily what's going on in the process (who clicked or entered what) outside of the Dynamic Details.
  4. Enhance the existin gsolution - push work, add or simplify business rules as needed and translate them into the other solution. Large implementations of stuff like SAP, Salesforce, etc., could greatly benefit the organization with some automation. Yes, many have workflow engines built in, but can they push and pop work to individuals or workgroups like we can to the Interaction Client with IPA? Why expect one solution to do everything under the sun? I've seen it time and again with customers over the years. AccuQuote used the word synergize. That's fancy-schmancy for integrate. Seamlessly. No solution is perfect. IPA helps make it more perfect, or suck less depending on how dire the situation is...!
  5. Give very limited access to an existing system to other people in the organization who don't need direct access. I built a process for ININ that allows some folks who spend lots of time in Salesforce to summarize and share data with others in the organization who rarely or never use it.
Drawbacks? Pretty much none. Take your existing process, automate it, and make it even more awesome. Probably save some money too. AccuQuote and DefenderDirect are great examples of successful customers who have taken this approach. Double-bonus if you're hooking into an IPA Template you bought from the ININ MarketPlace. Talk about Happy Processing!

Now what's a custom application? Well, as suggested above, pretty much anything that you could buy. I mentioned about a year ago that ININ had commissioned me to implement a Timecard process for their hourly team members, which, while fun, certainly can be sourced. Thankfully that process was relatively small and quick to implement, but it definitely wasn't simple. Remember, there's no such thing as a simple process.

There are a couple of customers who have used IPA to build relatively large custom applications, which sounds a little scary. Because it could be, but don't necessarily let that stop you. One in particular that did essentially case management said they suggested customers start smaller when they spoke at Interactions 2012 last year.

Creating a Custom Application
The biggest benefit of creating a custom application is you have complete control. Make it as small or grand as needed. Don't like the order of the radio buttons? Change'em. Need another value in the drop down list? Add it. Test. Republish. Voila!

What are the potential drawbacks to creating a custom application?
  1. Potentially reinventing the wheel. While you or some of your colleagues might be definitive subject matter experts on trouble ticketing systems, for example, building one from scratch is probably going to take more time and resources than buying one. Why not buy the one that is the best fit and potentially use IPA to enhance a few aspects of it? 
  2. You built it - you and your team (or maybe it's just you?) get to maintain it for the lifecycle of the solution. Now of course you're in this mode with any IPA deployment, just consider the bigger it is, the more complex the process, the more there is to maintain, (hopefully) including your process flows and other documentation. Customers have strategic reasons for Do-It-Yourself solutions and they happen all the time. Does that make them wrong? Depends. It's kinda like the trade-offs of using Attendant vs. custom Handlers for call flow. We'll get to some points to ponder in a minute.
  3. Biting off too much at the start. This could apply to wrapping around an existing application as well, but your risk is even bigger here. You'll have to think the whole data model through, your custom database, and unless you're very controlled about starting small, you'll likely spend weeks to months implementing something that may or may not meet the exact requirements. Use Agile, Scrum or another similar methodology suited to your organization for rapidly deploying smaller-ish, multiple iterations/phases/sprints.
Here's some potential warning signs you might have gone too far down the path with a custom application:
  • Lots of buttons on your Work Item pages that go off and do many complex things, like launch lots of different Handlers or make heavy use of Run Process.
  • Lots of Parallel Splits. Use this feature sparingly and try to resist including it in your first phase.
  • There are many pages of To-Be process flows. How many is too many? Hard to say, but if you have more than a handful or two to start in your first phase, iteration or sprint of your process, you might be biting off more than you could try to chew to start with IPA. 
  • First process is a custom application that's "bigger than a breadbox." Timecard could be a potential exception. It was pretty small. Unless you've already deployed multiple processes in your business, which at this date most have not, you're going to be in learning mode. It's the same learning we go through with Handlers, our call flows, and everything else with the ININ solutions, or most any technology implementation for that matter. Start small. Start with a small iteration (or sprint if you prefer) in your first process. You'l be glad you did. But don't take my word for it - show up at Interactions or ask for a customer reference. There's a learning curve, and I mean that in a good way!
Things careening all over the place, kinda like my old '74 Chevy Caprice when I went a little too fast down a dirt road one time in high school and was over-compensating to get'er going straight again. So let's try to summarize things a bit.

Best Chances for Success with IPA
  • No matter what, smaller processes or a small piece of your process is the best place to start or use an IPA Template from the MarketPlace.
  • Custom Applications - the smaller the better. Acquire an existing solution and enhance it with IPA for best results.
  • Existing Applications - make them more accessible to others in the business, push work and use existing reports when you integrate with IPA.
Got any initial IPA experience to share? Feel free to contact me or drop a comment.

And Happy Processing!







Sunday, June 16, 2013

IPA Time Saving Hacks Part 1

Clocks
Clocks by renbostelaar
Wanna save some time when developing a Process with Interaction Process Automation? Me too, so I'll just jump right into five quick little hacks for IPA that I've come up with over time.

"Disable" Steps in a Task or State

Have something you're working on but want to continue testing your process? Just put it after the End Task step in your Task or after an End Process in a State. IPA will put a nice gray shade over the step(s) with the word "Unreachable" on them. If Disable is something you think should be an option or attribute for steps, feel free to up-vote and comment on idea D1064 IPA deactivate/activate Step(s) in PAD.

Get Your Database Complex Types to Auto-Gen Ahead of Use

The Database Tools because available as of 4.0 SU2 and they rock! What took a minimum of 5 steps in a Handler, and many more if you're doing anything of use, to select a row now only takes 1 step in IPA. Yep, it's that simple. One of the many useful features of the IPA database tools is they will inspect your table and auto-magically create a complex collection type for database results. Usually you'll get to this point when you need to use your first Select Row(s) step for the table.

But what if you already have the database designed before your process and need the var before your first query? Just like we talked about in the previous hack, Drop a Select Row(s) step after an End Task step and assign the results to a local collection instance. Even though the step is Unreachable, the auto-gen executes.

When or why might I do this? Sometimes the Tables I'm going to use in a process are pre-existing. When this happens, most likely I'm doing stuff at the Work Item level, implementing a Page and need a "display instance" of the variable before I'm using Select Row(s) to fetch data from the database. You don't get the Complex Type defined for Database Results until you do a Select Row(s), so just drop one in at an innocuous spot and voila.

You can go back to the Task where you stashed the Select Row step later and delete it once you've reached the point in your process when you've done your first real Select Row(s).

Set a "Poor Man's Breakpoint"

Yeah we all know debug in IPA isn't, so first please take a minute to go up-vote idea D858 Debug in PAD, and then read on. To set a "poor man's breakpoint," simply perform an operation on a variable that is NOT_SET and you'll stop your process RightDamnNow. Guaranteed. Have a process level string var called Breakpoint and make the initial value NOT_SET. Anywhere in your process where you want it to stop, do an Update Variables with something like If(Breakpoint == "boom", "boom", "huh, guess it's gonna continue 'cos it's set."). Since Breakpoint is NOT_SET, this one's gonna go boom with an error performing an operation on a variable that is NOT_SET. Of course the Waiting Process is a gentler approach if you want to be able to continue instead of a hard stop.

"Bookmark" Your Process to Easily Pick Up Where You Left Off

When you reach a stopping point, drop in an Update Variables step. Use the Notes tab to remind yourself what's next on the to do list. Don't make any assignments in the Update Variables, which will result in a Yellow "Caution" flag for this step. This is harmless because the Process will still run in Test mode and can still be published. Nice thing is, next time you're back in ICSM you can follow the process tree down to the caution step to the exact spot where you left off. The bigger your process, the easier this will make finding where to continue. Oh, and of course don't forget to delete that step or cut out your Notes and start using the Update Variables to do some work.


Please feel free to share any timesavers you've discovered while working with IPA!

And Happy Processing!

Wednesday, June 5, 2013

Debugging Made Easier with a Waiting Process

UPDATED June 16, 2013 12:15 PM EST:

The "Waiting Process" trick was taking advantage of unintended functionality. Processes will no longer be able to launch with "Wait to Complete" in a Work Item as of SU5, but of course "Wait to Complete" will still be available as an option at the Task level.


Hey There Process-meisters! This is no earth-shattering discovery, and hopefully some of you already figured it out. As I had my debug-on this evening (yes, it's all pretty much DIY debug with IPA today) I needed a way to look at some variables mid-process while in a Work Item.

Ye Olde Elder Box Bug
Image Credit: Orkin.com
Unfortunately we don't have a Breakpoint tool (yet, fingers crossed) in Interaction Process Automation and the Wait tool doesn't exist at the Work Item level, but guess what? Run Process does, so....

1. Make a New Process.
2. Initial State - call a Task, which I naturally called WAITING.
3. Within that Task, set a Wait for 1 minute.

I wouldn't recommend going higher than a minute on the Wait, just in case you forget to remove one before putting your process into production.

Call this process from your main process for debugging purposes with the Wait To Complete radio button selected. Don't forget to take them out. I tend to set the Notes of my steps with something like ZZZ or DEBUG that's easy to find using the IPA search capabilities.

Since I wanted to look at some Work Item variables, from Process Automation Monitor, I made new Process-level variables that start with TEMP. I do this so I remember to delete them before production to use less resources with the process.

The nice thing is, after you've had a chance to inspect your process-level variables in PAM, you can Cancel the Waiting process and your other process will continue on it's merry way.

It ain't rocket science, and you might argue it's barely computer science, but hey, it works for me, at least until SU5.

Got any debugging or troubleshooting tips and tricks? Please share in the comments. PLEASE! Pretty please...?

As always,

Happy Processing!

Sunday, April 28, 2013

IPA Tech Discussion Added Interactions 2013 Agenda

Hi Gang! Quick note to let everyone know we've added an IPA session to Interactions 2013 that won't make the printed agenda. Much thanks and props to the rockstars on the Conference Team!

Thursday May 16th: IPA Technical Roundtable
Hosts: Geoff Calhoun and Rick McGlinchey
Room: 200
9:00 until 10:15-ish (to give folks time to get to the must see"Where we are going" session with the Don.

Target Audience: Ideally those who have worked with Interaction Processor Automation in some way, shape or fashion. We had a little internal session back in December and everyone involved found the it beneficial to get together to share some ideas and lessons learned.

The numbers in the IPA community are relatively small but growing, and we're all still very much in the learning phase as we get experience and develop design principles and best practices around improving the experience with the product.

All the better if you have had your hands in Process Automation Designer, or have at least taken one of the IPA courses, but those certainly aren't required. We'll try to grab some of the ININ folks who work with IPA as well.

Goal is to let folks as questions and have everyone share lessons learned about IPA. Very informal and you're sure to learn something!

I'll also be co-presenting at these two sessions. There's lots more to learn with IPA, to be found in the agenda for Interactions 2013.

Wednesday May 15th: Looking to automate business processes? Start here!
Geoff Calhoun and Rick McGlinchey
1:45 to 2:30 in White River Ballroom I‐J

Automating business processes is a daunting task and can lead to many questions. Which process should we automate first? How to map out a new process? Is there anyone who can help us? Get the answer to these questions and more as we explore process automation best practices to help your business gain productivity and cut costs.

Wednesday May 15th: Interaction Process Automation (IPA) Technical Best Practices
Rick McGlinchey & Jason Loucks, Senior Business Process Template Developer, Interactive Intelligence
4:45 to 5:30 in Grand Ballroom 7

IPA is an amazingly flexible tool for process automation. Come learn design best practices from seasoned IPA process developers. They will walk though how to use IPA’s features and explain concepts such as using database driven design to help you get the most from your IPA processes. This will be an interactive session; we want to hear from other process developers. What tricks have you used and what obstacles are you trying to overcome?

Jason and I did this session at Interactions 2012, which was standing room only. Jason has been working with the product as partner, customer and now ININ since the 90's and has mad technical skillz. Make sure to get there early to get a seat!

Some conference suggestions:

  1. Download the conference app - it's pretty slick and easy to pick the sessions you want to create your own schedule. If you would like to get in touch, it has a message application built in for conference attendees.
  2. Bring an extra layer of clothing, like a sweater or lightweight jacket. Temps vary in the hotel and sessions.
  3. Be prepared to learn lots and HAVE FUN!!!

See you soon at Interactions 2013! Until then...

Happy Processing!

Wednesday, April 17, 2013

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.
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?