A light weight integration, a great business benefit.
Introduction
OPX is the world leading Workforce Management solution from Corporate Modelling Services. It
provides the capability, and empowers the business operational teams, to increase their productivity
and utilisation while having a very low IT impact. This overview discusses the interfaces required, (or
optionally required), in order to implement an OPX solution. It does not cover the features or the
benefits of OPX.
Getting the workload (demand) into OPX
OPX, at a high level, manages the productivity, utilisation and work allocation of a workforce. It does this
by understanding the operational business in terms of the demands placed upon them, capacity they
have to deliver the workload, the SLA’s and business priorities.
Figure 1- High level view of demand aka workload sources.
Demand on a business unit comes from potentially several different sources, namely:













call centre
IVR systems
post room
email inbound
web site(s)
web based ordering systems
web based partner interfaces
web based exchange interfaces
existing systems generating work
management requirements
manually created by the team
flat file loaded
work referred from other business units
OPX provides a generic way for accepting this demand from existing solutions such as scan and indexing
solutions. Once the data has been loaded, OPX maps the information in the loaded demand data to one
or more business processes which are then initiated to process the demand request. As demand can
simply be entered into the system through the user interface, or automatically when files or
spreadsheets are dropped into a folder, it’s easy to get the workload into the system. CMS and its
partners have decades of experience in loading and parsing file formats, and if required, can assist in
getting the demand loaded from the underling sources.
Of course, it is possible but not always desirable to have higher levels of integration which can be added
over time, or at the start of your project including:





interfaces to the voice recording system to synchronise call ID with recordings
interfaces to the document management system to show images of documents
interfaces to your email solution
interfaces to your document production systems for creating ad-hoc letters
interfaces to any web based (or non-web based) application screens appropriate for executing
work.
Understanding the business object being processed
It’s not always enough to have the demand request for work in order for the Administrators to
understand the request; they may also need more details. For example a request for a Surrender of a
Policy may be an incoming letter with just a policy ID on it - the Administrator need to know more, such
as what type of Policy or what system the Policy is administrated on so they can carry out the work.
OPX holds this extra data in stub files. A stub file is a set of extra data about the business objects
referred to in the incoming demand that’s of use to the Administrator in deciding how to process the
work. OPX treats these as flat files which are loaded and merged whenever a new version is available
from the underlying systems. OPX can merge the data so it’s easy, for example, to dump the entire
policy file data every night, or you can send delta’s from a system that provides changes easily, whatever
is easiest.
Stub files do not usually need to be updated in real-time, and while OPX can read data directly from the
underlying systems, the integration and potential additional load on the back-end systems does not
usually have a good return on investment, it rarely takes more than a couple of days to write a report to
dump out stub file data on most back-end systems.
Mergers and Acquisitions and OPX
OPX can be used when a company has acquired or merged with another company relatively easily. The
solution can be deployed immediately into the new company as a standalone solution allowing the new
company to benefit from OPX in the same manner as the original company. Over a period of time,
business services and hence processes, may be merged or combined across the organisation. This can be
accomplished by simply disabling the process in one company while leaving those enabled in the other.
For example, if the Claims Department is merged across the two organizations, we simply ensure that
the stub files are available for the two companies and the demand from Claims initially being loaded into
Company A. OPX is now loaded into Company B’s OPX solution. This allows a slow and steady merging of
departments or functional areas as often training or systems migration may be required outside the
scope of the OPX Workforce Management. Ideally over a period of months or years the work is added
into a single OPX solution allowing for a single source of management data across the two companies.
However, if there is still a need for a single source then using a warehouse version of the OPX Schema
(OMIR) can be used. OMIR (OPX Management Information and Reporting) is a warehouse that has the
same structure as OPX and is merged nightly from the source OPX databases allowing offline reporting
and analysis using the same or third party tools.