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!