What is the difference between validations done in transaction systems and the exceptions handled in OpsVeda? This is a most frequently asked question from customers in every introductory meeting. So, I thought it might be useful to do a post that elucidates the difference.
Validations are inspections/“checks” that are done to ensure whether the transactions are recorded without basic errors. Few example scenarios such as checking the entered product id in a transaction doesn’t belong to an obsolete product, verifying the shipping address entered etc. are good examples. The key characteristic of validation is it’s a “one-time check” that should suffice. Once the transaction has passed after several checks there should not be any chance of failure at a later stage in the process.
Exceptions are situations that can impede or decelerate the natural progression of a transaction even after several related transactions are completed. Scenarios such as credit blocks applied to a customer with confirmed orders due to ship today or tomorrow, a pricing review not completed on time, or confirmed order that did not consume a linked contract etc. are good examples. These are timer-less ticking bombs that can go-off silently, and the operations user may not even know about the impact till it is too late for redemption. Exceptions often have business impact and costs associated with them. So, continuous & proactive monitoring is a must for managing exceptions.
Often, customers question us about how exception monitoring system could be built into the transaction systems. That generally is incorrect because exception detection needs continuous monitoring that transaction systems are not architected for. Listed below are a few traditional approaches of how exception detection were done before customers deploy OpsVeda’s Exception Management.
|Tool/ Mechanism for Exception Detection||Drawback|
|Have validations at each step of the process. For example do a credit block check at order creation, confirmation and delivery.|
|Normal Credit check just stops shipment against Customer on hold, rather than highlighting the issue in advance so pro-active action could be undertaken.|
For example: there can be many days’ time gap between the order confirmation & delivery. If a credit block was identified may be a few days before the delivery, the operations team would have still had a chance of getting the order out on time.
Unfortunately, often they come to know only at the time of delivery and by that time it might be too late to prevent the delay.
|Batch processes that simulate the exception checks on every open transaction, and prepare a report of the problem transactions.|
|In transaction systems, such resource intensive reports run only occasionally – mostly once a day during off-peak hours. This means that the team gets a set of reports with stale exceptions leading to:|
1.Cases where it is too late to intervene and resolve the situation.
2.Wasted time on situations that may already have been addressed.
|Reports that push out data into an Excel sheet. Exception identificat|
ion carried out manually through formulae and macros and …well, huge pivot tables.
Too many spreadsheets, multiple sources of truth across the organization. By the time the master spreadsheet is out, data is already outdated.
All the above mentioned methods have a common drawback – the operations team cannot act on time! That means compromising on Business Speed and Scale. ‘Manage’ by Exceptions should be the mantra for every enterprise.OpsVeda helps eliminate numerous such validation reports and replaces then with one user/role specific Story board with view into relevant exceptions, KPI’s and business scenarios.
Make an impact on your operations, do proactive monitoring using Exception Management Solution delivered by OpsVeda! Make smart decisions ahead of time!