A Primer on The Role of Automation Technology in Managing Transactional Complexity

One of the primary reasons behind the difficulty of automation is
complexity. From a technical perspective, this relates to the
attributes of data that pertain to structure, type, and form. From a
behavioral perspective, it has to do with varying needs and
requirements, and preferences unique to organizational entities or
people as individuals.

Largely driven by the private sector, most process automation
initiatives continue to face challenges due to the dynamics inherent and
characteristic of the market. There is simply no way for private
companies to accurately predict the fluctuations in market demands and
preferences. Since their sustainability is based on making their
products viable across a wide spectrum, competition naturally dictates
that a differentiator must be established in order to out perform the
competition. It is in this area where variability increases. Unlike a
a broad/generic approach, companies that wish to differentiate
themselves would have to cater to a specific segment of their target
market without alienating their larger base of customers. This area of
differentiation offers higher returns due to its uniqueness and value
proposition, but it also offers the highest levels of variability since
customer A will not have the same requirements as customer B--they will
always be differentiated.

You can imagine the amount of work that has to be done for private
companies to build automated systems that could adequately handle such
high levels of variation. But most of the time, they are left without a
choice. They either do it, or die. This inherent complexity gave rise
to the formation of industry consortias that were dedicated to creating
acceptable standards that could be shared within industries to allow
more efficient communication flows without having to sacrifice
differentiated service methods. These firms realized that they spent
hundreds of millions of dollars in sorting through the noise of data and
very little in terms of acting on data. Since then, several prominent
standards groups began to rise to the occasion and begun publishing
structures and methods that would allow firms to focus on differentiated
services rather than on making sure they understood each other.

Standards like the Internet, HTTP, EDI, XML, ebXML, and UDDI came as a
result of this collaboration. Over the past decade these standards have
been slowly adapted by major software developers into their products
giving their customer the ability to manage the technical aspects of
complexity. Today, unless a software comes as compliant out-of-the-box,
companies would not even visit the idea of making use of it. UDDI
<http://www.uddi.org/specification.html> which stands for Universal
Description, Discovery and Integration, for example is a standards
repository of structures and rules to allow companies to electronically
share and exchange data seamlessly regardless of geography.

Admittedly these standards cannot readily address the more prominent
issues of behavioral variability especially in the general market.
Companies often have to alter their directions at the blink of an eye in
order to capitalize on an opportunity that may never present itself
again while minimizing the risks that typically come with such rapid
movement. When this happens, they expect systems to generate the
information they need, when they need it--and usually, that was yesterday.

To control behavioral variability, software systems employ a rule-based
approach to parameterizing activity. These rules are a set of defined
algorithms that control where, when, how and who can use the system or
access the data. This is the layer that enforces policy and unique
process flows that is specific to each organization or company. This
layer encapsulates the uniqueness or differentiated activities of every
organization and units within that organization. Accounting, for
example, maintains a set of constraints and processes that are unique
from the processes of Sales or Manufacturing, or Inventory Management, etc.

We begin to encounter problems when each of these units superimpose
their uniqueness as a de facto that should govern the processes of
another department, or another organization. In reality, there is no
need to integrate processes at the functional level. The only thing
that concerns Accounting when it comes to Inventory Management, Sales,
or Manufacturing is data--and the specifics of data can be clearly
defined and more easily shared and exchanged. While the 1+1 clearly
equals 2 in this equation, how organizations chose to approach this has
presented more problems than was necessary. Even good governance, the
Sabranes-Oxley, or whatever standard you choose to employ, does not
warrant a tight-coupling between different functional processes.
History shows us that this untenable. And if we are to apply Reeds law
to map out future trends, the likelihood that we can gain mastery over
this is close to nil. It introduces more problems than its worth.

Your thoughts?

--
Dennis Reyes, Ph.D.
dennis@dbreyes.com

"Learners prepare for the world for tomorrow."

Learn More About:

Applied Knowledge Management
[http://appliedkm.blogspot.com]

Supply Chain Management
[http://blogs.ittoolbox.com/supplychain/emerging]

Mental Models and Contemporary Issues
[http://trendsofthought.blogspot.com]

-----------------------------------
IMPORTANT NOTICE
The information contained in this electronic mail is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged and/or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone and return the original message to us at the above address via the Postal Service. Thank you.