Posted by Patrick Connaughton on April 30, 2010
Lately I’ve been really focused on process automation -- specifically, how software can help but also potentially cripple cycle times. When it comes to enterprise applications, my strong view is that event and alert management solutions are two of the most critical components to achieving success.
Services Procurement (aka Vendor Management Systems) are no exception to this rule and since we are currently in the process of writing a Forrester Wave™ evaluation on this topic, I thought I’d share a few thoughts on what companies should look for in the context of these tools. Let’s start with a snapshot of a recent interview I conducted with a VMS end-user . . .
This company’s main goal was to free up key staff by automating services procurement processes and managing by exception only. The company viewed the software’s event management and associated alerting capabilities as core to achieving this. So when they found a vendor reporting over 200 alerts “out of the box,” that was a big factor in why they chose the solution.
The implementation team diligently gathered the requirements and presented the wide range of alerts to the end-user community. Business line managers were initially very excited at the prospect of being alerted via email when key events took place. The implementation team ended up enabling nearly all of the 200+ alerts.
The result? On Day 1 of acceptance testing, each primary stakeholder on the project who had signed up to do quality assurance received over 100 alerts from the application -- some in their email inboxes, others only in the dashboard. Now, this was clearly a setback but not necessarily a shop stopper. The team regrouped and decided to change the alerting philosophy to really only highlight exceptions in the process. Unfortunately, this is where the project started to come off the rails . . .
The issue? When the team sat down to set up exceptions-only alerts, they found that the configuration was limited to a set of static dropdowns with a limited ability to create any business rules. When the company asked the software vendor about this, it responded “sure, we can certainly help you, but the types of alerts you want will require an enhancement request -- would you like us to give you an estimate for that?” This enhancement request (for what boiled down to 10 specific alerts) that included conditional business rules was quoted out as 120 hours of work. Needless to say, things were not off to a good start. The customer felt like this flexibility should be part of the base solution and that it was being nickel and dimed. Eventually the vendor and customer negotiated a middle ground, but the relationship was scarred and the whole situation could have been avoided.
How? By picking the right software to begin with. Software evaluation teams will sometimes mistakenly focus on the sheer number of alerts available out of the box. While pre-configured alerts can be useful, this is not the best approach. Inevitably, you will need to generate an alert based on a series of events that even the smartest vendor R&D teams did not think of. It’s in that scenario where a process modeling tool / rules engine to configure alerts will come in handy. Look for a solution with a user interface that allows the customer to create IF/ELSE statements from attributes of multiple objects (i.e. Requisition, Contractor, Invoice) and build nested, conditional rules to generate the alert. A non-technical person should be able to create these rules. Some solutions also include a view that shows a process flow once it was created. That can be really helpful for design teams building out more complicated rules. These rules are then used to kick out the alert versus the static parameters I described before.
Here’s an example: In the first phase, this company simply turned on alerts based on these types of events: Requisition, Opened | Requisition, Approved | Requisition, Filled | Candidate, Requires Review | Project Milestone, Acceptance Required | Contractor, On-boarding Checklist Complete | Timesheet, Requires Approval | Timesheet, Approved | Receipt, Overdue | Receipt, Paid | Assignment, Expiring In X Days | Assignment, Extended, Required Approval | Contract, Expiring In X Days | Budget, Within X % Of Maximum, etc.
After the initial information overload, what they really wanted to achieve was something like this: IF the hourly rate is greater than or equal to $200 AND the vendor is NOT EQUAL to Acme Corp. AND the assignment duration is greater than 4 weeks, THEN send an alert message to the “Finance -- Requisition Exceptions Approval” role. Then, if the message is not acknowledged and approved in 48 hours, escalate the message to “VP, Finance.”
This is the difference between basic event alerts and rules-based alerts that help you manage by exception.
Key takeaway: When evaluating a VMS (or any application for that matter), don’t be over-enamored with the sheer number of alerts available out of the box. Instead, look for a solution that includes a modeling tool that a non-technical person can use to build conditional rules that generate alerts. This will give you not only the flexibility required to achieve actual automation you can trust, but you can make changes over time without having to customize the software.
Patrick Connaughton | Senior Analyst - Sourcing and Vendor Management Forrester Research Phone: +1 617-613-6486 | Email: firstname.lastname@example.org | 400 Technology Park | Cambridge, MA 02139 | www.forrester.com