Keeping a watchful eye on your business with Alerter

Business process automation and business intelligence specialist Ovations Technologies would like to alert the market about the positive impact its OvaFlo Alerter and Barometer systems can have on work management. Productivity details and process information is made available in an instant.

OvaFlo is an application written in-house at Ovations Technologies and works with K2.net, ViewStar and FileNet solutions to speed up the workflow process.

Ovations Technologies sales and marketing director, George Smalberger describes OvaFlo as a "business process automation suite of applications offering a standard set of applications and functions to suit the requirements of typical business processes.

"With OvaFlo`s Alerter and Barometer, a manager has instant access to information regarding the productivity of any worker involved in the business process, and an up-to-date status report of any work within that process. These features allow OvaFlo users to view the workload and monitor their work in more detail using different service levels for each process," says Smalberger.

Alerter is a real-time monitoring sub system that fits seamlessly into the OvaFlo solution. It can also run as a standalone sub-system to give users a view of the system in order to help locate existing problems or bottlenecks.

"It is not always practical to wait for the MIS reports to run at day-end. The Alerter enables users to be proactive rather than reactive and handle situations before they become problematic. Many problems that surface within a distributed solution, such as workflow solution, can result in failure. This has a negative impact on the business process because work typically jams at some point and requires a complex investigation to establish the cause," he continues. The Alerter system is made up out of three main components - the Engine, the Configurator and the Client.

Alerter Engine

The Alerter engine monitors all custom events defined in the system. These events can include anything from monitoring queue depths to NT services running on the server. Each event can have different thresholds - some time-based and others volume-based. The Engine is responsible for raising these events, depending if they have been defined as such, and closing them as well.

Alerter Configurator

Users can define custom events in the Alerter system. These events can range from monitoring volumes of items to an indication of how long an item has been in a certain state. These events can then also be "broadcast" to users in the system. Publication groups can also be defined in the Configurator, these are the groups that can receive these Alerter events, each publication group can have different escalation times so that managers do not have the same escalations as clerks. Subscribers are then defined which belong to the publication groups.

The Alerter events are built in a header/detail relationship meaning your event might be "Documents are not being scanned", this being the header portion of the event and the actual documents being the drilled down detail of the event.

Alerter Client

This allows users to see what Alerter events they have subscribed to. Users are able to view a list of events and drill down to see the respective details. They are then in a position to acknowledge, close or take ownership of these events.

"Alerter is permanently visible to users working within the process. It provides automated policing, consolidation and collaboration of information, e-mail notification and summarised events for non-interactive users - or managers, for example. It also serves as an early warning - alerting managers to potential hazards like workloads exceeding capability limits or informing technical personnel of component failure or that a network is down," Smalberger concludes.