BPM.com

             

Articles

Realizing the Real-Time Enterprise

Real time comes in various flavors. If we turn to the definitions proffered at Carnegie-Mellon University, we can see that real-time systems can be classified as hard (catastrophic, dangerous), firm (significant loss of service, annoying) and soft (usefulness, it’s late), depending on the implications of not meeting their timing requirements. But, regardless of their classifications, the impact of time is key to a working definition of real time:

- “In real-time computing the correctness of the system depends not only on the logical result of the computation but also on the time at which the results are produced.”

- “A real-time system is universally accepted in the engineering field to be one in which time is a factor in determining the correctness of the result. Usually, this means that some deadline exists which, if the system exceeds this time, it can be considered to have failed.”

Furthermore, time is relative to the context of the system. Dr. David Stewart explains, “Real time does not mean fast; it means that a system has timing constraints that must be met to avoid failure. A real-time system is one in which the correctness of the computations not only depends on their logical correctness, but also on the time at which the result is produced. In other words, a late answer is a wrong answer.”  In most business interactions, real time describes a human rather than a machine sense of time. In an aerial dogfight between military jets, real time better mean real fast, milliseconds to be sure. To the airline passenger whose connecting flight was just cancelled and who is trying to catch the next available flight, it could mean minutes—in time enough to make a difference.

In context of the real-time enterprise, our working definition of the real time can be put in everyday terms, “in time enough to make an effective decision and act, and where a late answer is a wrong answer.” The measure of time depends on the context, and the properties of predictability, fault tolerance and reliability all combine to determine the requirements for the system. Online financial trading will have one set of requirements far different from obtaining online requests for proposals in the construction industry. They have different real-time requirements, but both need information in time enough to make effective decisions and act—in time enough to make a difference.

University of Virginia’s Dr. John Stankovic enumerated several real-time misconceptions:

- Design is ad hoc

- Faster computing hardware will solve real-time problems

- Real-time just means fast

- Real-time programming = assembly language programming

- Guaranteed real-time performance is unattainable

In the world of business and commercial information systems, the term real time cropped up with the advent of the online terminal that replaced the punched card and the batch computer systems they fed. In the early days of business computing, business transactions that resulted from selling something or receiving something into inventory were recorded on paper. The paper forms were put together in batches, and each batch had a control total to ensure that all transactions in a batch were included in data entry for later computer processing. For example, the totals on each order form would be added up to create the batch control total. Once keyed and verified, the batch of transactions was submitted for computer processing. All transactions in the batch were processed at the same time.

The advent of on-line systems and the computer terminal changed the batch transaction processing cycle. Each transaction, not each batch, could be keyed in, validated, and completely processed as a stand-alone activity. To distinguish between the two styles of transaction processing, the term on-line real-time system was used. The results of processing a single transaction were immediately available to all users of the system, all at once, in real time.

The users were, however, clerical back office personnel, and the information delivered to the shop floor, to the sales force, to management or to the warehouse still came in time-delayed paper reports. Although they were fast on line systems, because time has no impact on the results, even if they were correct, such systems are not real time.

So Simple, Yet So hard
In 2001, Cisco Systems, the company once touted to be the first ever to reach a trillion-dollar market capitalization took a $2,500,000,000 inventory hit. Although Cisco has electronic connections to its suppliers and contract manufactures that made its supply chain so efficient, that it is probably the most documented case study of Internet-driven efficiency, it relied on its customers’ purchasing agents to estimate their up-coming requirements for Cisco gear. The purchasing agents of Cisco’s customers would place large orders, sufficient to keep up with the exploding dot-com market, knowing they could cancel those orders at any time. They did. Cisco’s supply chain worked as it was supposed to, but Cisco’s blind spot was its demand chain, and it paid the price for the lack of accurate sensing of actual market data in the demand chain.

The business of keeping business information up-to-date and accurate is no small matter. Today, almost every business has its blind spots, and considering that there are about six million firms in America, information-induced waste, write-offs and snafus are staggering.

Something so seemingly simple, yet so powerful, as keeping information accurate and up-to-date, becomes a problem of immense proportions when it’s considered that much of the needed information is outside any given organization. Companies are struggling for true breakthroughs now that, for the past ten years, they have reengineered, streamlined and rightsized themselves. They have tinkered with new age Internet initiatives, and, still, they are desperate for actionable information. Solutions won’t be found by speeding up computers, for they already operate in speeds measured in teraflops—a trillion floating point operations per second. Solutions won’t be found by recording more data into companies’ information vaults—vaults already so full, they create information overload.

Considering all the overflowing silos of information scattered throughout most large enterprises, companies certainly have huge quantities of information. Just about every thing they do, day in and day out, is digitally recorded somewhere, and that state of affairs could suggest why the search for actionable information is so elusive. Companies don’t need tons of historical information locked away in data vaults; they need live information—they need breaking news in a format they and their computers can understand, and on which their business process management systems can act to make course corrections, create demand and set new trends. When information is recorded, it’s history. While information is being created, that’s when it’s really useful, actionable.

Breaking news, events occurring right now, is the stuff of action, the kind of information companies can use to make decisions here and now. Why is there such a dearth of actionable “news” available to companies? It has to do with three factors.

First, today’s automated information systems are essentially record keeping devices. They dutifully record the transactions of the business after the events that triggered those transactions have happened. The haggling salesman closing the sale with a customer is the event; the order entry system later records the transaction of the event. Sometimes those events are recorded directly into computer systems. In other cases, they may be recorded on paper, faxed and collected into batches so they can be cross checked for accuracy, then entered into the computer system. A large enterprise has hundreds of computer systems scattered throughout its many divisions and lines-of-business. In conglomerates such as GE, lines-of-business operate autonomously, as though they were independent businesses: GE Capital, GE Aerospace, GE Plastics and so on. Each line-of-business operates with its own set of policies and procedures regarding its business processes and their underlying information systems. Typical of such autonomous organizations, there is often little or no synchronization of information across all lines-of-business. Each sets its own policies concerning when events in the business are recorded as transactions and stored in the many information vaults it controls.

Second, the autonomy of the many lines-of-business and their divisions has resulted in situations where the information they process and control only flows through their own islands. The manufacturing division is custodian of product and work-in-progress inventory information; operations maintains finished goods inventory records; the sales organization custodians customer information and marketing tracks and records market and economic trends and activities. Oh, what a story this disparate information could tell, if it was consolidated, aggregated and synchronized—if it was always up-to-date and made available anywhere, anytime to those who can act on the news it would reveal. No doubt, companies could predict and shape markets, as well as spot bottlenecks, redundancies and other sources of needless costs.

Unlocking information, and business processes stowed away in silos scattered throughout the enterprise, is a right step in the search for new productivity, but only a first step. The second step is to bring together all the islands of information, all the information precincts, so that a complete, accurate and balanced picture is rendered. For that to happen, the picture will be distorted unless the information is current and synchronized across all relevant organizations and systems. Since the information is housed in disparate computer systems that are in and of themselves incompatible, not to mention the incompatibility of their data formats and meaning, the search for actionable information becomes increasingly arduous. But that’s not all. Even if actionable information can be obtained, companies then must ask, “Is it financially feasible to act? Is it feasible to ‘recompile’ existing monolithic systems to implement new business processes, regardless of how vital they may be?” With current technology, analysts have run the numbers, and the answer is “no.”

Third, as Peter Drucker explained, the notion of “a company” is, economically, fiction. No company is an island unto itself. It cannot exist or operate without those vital parts that do not show up on the organization chart—its suppliers trading partners and customers. What about their islands of information that are parts of the complete picture of actionable news? Cisco could have acted much faster if it had a complete picture of its customer channels as the demand for Internet routers fell, when the dot-com bubble burst.

These three challenges, unlocking information in disparate application silos, synchronizing the currency of information across multiple sources, and providing 360 degree visibility across the entire value chain, are the keys to obtaining actionable information—these are the challenges taken head-on by the real-time, process-managed enterprise.

The third and final part of the Peter Fingar’s trilogy - Defining The Real-Time Enterprise - will be published soon on BPM.com.

 

 
About The Author: Peter Fingar

Peter Fingar is one of the industry’s noted experts on business process management and a practitioner with over thirty years of hands-on leadership at the intersection of business and technology. He delivers keynotes worldwide and is an author of Business Process Management: The Third Wave, The Real-Time Enterprise: Competing on Time, and the just-released Extreme Competition: Innovation and the Great 21st Century Business Reformation. 

BPMN 2.0 Handbook

Co-authored by BPM.com's Nathaniel Palmer, and with a forward by Dr. Bruce Silver, the BPMN 2.0 Handbook offers both the business and technical perspectives written by the standard's authors, leading implementors, and most respected experts; The 47-page excerpt contains the complete Forward, Introduction, BPMN Glossary, and Making a BPMN 2.0 Model Executable; authored by Nathaniel Palmer and Lloyd Dugan. Free to registered BPM.com members.
Click Here to Download