Business Activity Monitoring may sound, to many CIOs and business managers, like a tool that is good to have if they are running a very large and complex business management environment. Then, keeping on top of the activity - what is happening across those applications and datasets – can seem an obvious requirement because the scale of such environments can send even a small operational problem spiralling into something major very quickly.
Why Business Activity Monitoring?
That task – identifying that a problem with business processes is occurring, and finding where that problem lies – is one of the core reasons for employing Business Activity Monitoring (BAM) systems. Yet one of the most common approaches for implementing such systems often has the side effect of making that important task both difficult and time consuming.
When a problem with business processes occurs most companies will want to find the cause, and have some idea of how to fix it, in the shortest time possible. Yet one of the most common approaches to using BAM suggests that it should be implemented in the same way as business process management solutions such as workflow applications……from the ground up across everything.
Automation of End-to-End Business Processes
In my experience that doesn't really work, and this is not because the technology is weak, more that it runs against human nature. People usually want answers to specific problems `now’ (or as close as possible to `now’). Using a ground-up, re-integration approach requires real, up-front effort, for it requires the end-to-end automation of as many business processes as possible.
This is needed so that a centralized business process management solution can monitor anything at all. The cost can be ridiculously high, and very few companies manage to get all their processes covered by such tools.
The common result is that any process problem creates the need to manually open up all the applications to find the right data and identify the issues. It becomes a tremendous effort, in both time and cost, to collect the right information from the right applications.
In essence, the vendor is saying something like: 'ok, in order to get visibility the first thing is we have to introduce a Business Process Management Solution which requires you, Mr. Customer, to map out your 10, 15 Key processes you're feeling some pain with, so we can understand them and implement a solution. And in only two years you will get insight into all of your business processes'.
Visibility into Business Transactions independent from the IT implementation
But a good BAM solution should give that to users now, when they need it, not in two years when the problem may have even killed the company. It should guide and support them in getting that data easily from all the applications, and put them in context without having a huge, central management application.
The trigger is the proof, from simple observation if nothing else, that business processes are not running as expected – for example, not executing at the pace or the level of execution excellence that is expected or required.
The trick, therefore, is to work with data produced by business processes that are already implemented and working. After all, it is that data which will contain the evidence of how – and probably why – one of them is not working correctly. If that data can be moved into a BAM system so that we can give companies the visibility they need without having these massive integration implementation projects, that would make a great deal of sense.
The nJAMS (Not Just Another Monitoring System) approach to Monitoring End-to-End Business Processes
That is the approach we have adopted at Integration Matters. The goal is to use all the data that is already being collected anyway, put it into a solution and get visibility within a couple of days – a couple of weeks at most – without being swamped for a year by an army of extra consultants mapping out business processes that might produce a solution a year after that.
We work with tools that are designed with a more iterating or more evolving approach that naturally adapts to whatever the customer has, making sense out of the data, and identifying the important monitoring points, such as the KPIs for the business. The key question for the user then becomes more open: `where do you want to focus now?’
Tracking Business Transactions KPIs in real time
So this means extracting a subset of the data from factors like KPIs, the performance of the system against SLAs, the business data and the combinations of business data that are associated with a business transaction to identify which process has got the problem. It means that users can identify problem areas in a couple of days rather than setting off on a year-long re-integration process.
This about monitoring and identifying, so the remediation of problems is down to using other tools. But the information they get to work with is quite specific. This is not just saying there is a problem in `sales order processing’, for users can drill down and find the individual transaction of an individual customer, and track its impact across internal systems and external partners. They can identify where a process is stuck, how it is stuck, and why it is stuck.
We may not be in the business of actually fixing these problems, but we are in a position to provide the customer with a pretty good specification for the fix.
And in the end, isn’t that what most business managers want, and what they look to CIOs and IT departments to provide?