Students

IT evolution, part two: Could REA analysis topple ERP systems?

Enterprise resource planning (ERP) systems have a growing reputation for being big, slow, pricey and just about impossible to change once they're installed. Those aren't exactly promising survival traits in competitive environs that demand IT agility. In the conclusion of our two-part story, Julie Smith David, associate professor of information systems at the W. P. Carey School of Business, discusses REA (resources, events and agents) analysis, a method of system modeling that may meet the information and agility requirements of corporate computing today.

2007-03-14

Back when dinosaurs were stomping their final footfalls in murky puddles, who knew skittish little tree-huggers would ultimately climb to the top of the food chain as Homo sapiens? Between their size and supremacy, great dinosaurs certainly didn't look vulnerable, but they were. Today, many information technology professionals view enterprise resource planning (ERP) systems as being a bit like the dinosaurs of long ago. They may look like king of the corporate-computing swamp, but the days of dominance for these lumbering beasts may be numbered. That's because ERP systems have a growing reputation for being big, slow, pricey and just about impossible to change once they're installed. Those aren't exactly promising survival traits in competitive environs that demand IT agility. What is waiting in the shadows as a possible usurper to ERP preeminence? According to Julie Smith David, an associate professor of information systems at the W. P. Carey School of Business, it could be systems built with resources, events and agents — or REA — in mind. REA analysis offers a method of system modeling that may meet the information and agility requirements of corporate computing today. Primal parts of business The online encyclopedia Wikipedia describes REA as a "model of how an accounting system can be reengineered for the computer age." William E. McCarthy, professor of accounting and information systems at Michigan State University, came up with this alternative to traditional accounting systems. "It's a simple set of ideas," McCarthy says. "It says that when you're modeling a business, you keep track of the basic occurrences -- events, so to speak." Events include things like placing a purchase order, paying an invoice, or as Wikipedia identifies them: "business transactions or agreements that affect resources." Resources include assets such as inventory, cash or fixed assets, but resouces are also defined more broadly -- including employee time and advertising services. They're items that are rare, under the firm's control, and add value. Agents are the people or companies that participate in the events -- buying or selling products, for instance. Not surprisingly, events and resources have a dual nature. "Every resource has at least one event that increases it and one that decreases it," notes David. "If you get something, you have to give something. If you give something, you expect to get something. They don't have to happen at the same time, but you have to link that cause-and-effect economic exchange." McCarthy illustrates REA to his MSU students with a little help from Sesame Street's Cookie Monster and Elmo. Say Elmo has a cookie, and Cookie Monster has a dollar. As we all know, Cookie Monster would probably rather eat a cookie than own a dollar, so he trades the cash for the treat. That exchange is the event. The cookie and cash are the resources. Elmo and Cookie Monster are the agents. As McCarthy says, it's simple stuff. But, it's also powerful stuff. According to David, REA concepts can go far beyond the limitations of ERP systems. They also can facilitate business analysis and identification of strategic opportunities for organizations. Missing links   "ERP systems do a good job at what they were designed to do," says Mark Nittler, vice president and chief financial-management strategist at Workday, a software development firm. Nittler previously presided over financial applications at PeopleSoft, and he has a pretty good idea of what ERP systems can do. "They were built to address financial accounting requirements," he says. That means they're fine for processing reports that meet generally accepted accounting principals. "But, you cannot find an accounting textbook that ever claims to be a good model for running a business," he says. According to Nittler, the beneficiaries of ERP systems are back-office workers: the accounting team, the purchasing folks, and human resources pros are examples he cites. "ERP systems were built around these support processes, driving down the cost of administration," he continues. "That's a good thing, but an ERP system hiccups mightily when you try to get it to deliver good information about the business." That's where REA comes in. "REA tries hard to be a natural model of what the business is trying to do," MSU's McCarthy says of his 25-year-old brainchild. According to him, a problem of early computing systems is that they "instantly converted information to the terminology of accounting." REA models, on the other hand, describe basic business activity without accounting jargon. Done right, "everybody who might want to use the data -- accounting people, marketing people, logistics people -- can go back to one basic data set," McCarthy adds. Don't blow it At Workday, software developers are using both REA analysis methods and object-oriented programming, notes the W. P. Carey School's David. In object-oriented programming, developers specify "classes" and operating rules for those classes. Then, all the subclasses that follow automatically inherit the same rules. So, for instance, resources, events and agents are the classes in the Workday system, David notes. For something in the "resource" class, she explains that rules might spell out how you increase the resource, how you decrease it, who is responsible for these actions and so on. Nittler likens such information in his company's REA model to the seeds of a dried dandelion. If the dandelion itself is an event, each seed is a data element. "What happens in traditional systems is that the system grabs onto that dandelion and blows on it really hard, sending all those bits of data all over the place in terms of where they are in data tables," he says. "It takes all the king's horses and all king's men to pull that stuff back together. That's what business-intelligence systems do for you." An REA system easily does the work of all the king's horses and men. Without REA, those strewn seeds of data necessitate lots and lots of tables to eventually hold them. "PeopleSoft, I think, had something on the order of 47,000 different tables when they were acquired by Oracle," Nittler recalls. "Trying to keep all that in sync becomes a pretty big problem." Because of they way it uses object orientation, Workday's systems run with a smaller number of tables — three. Nittler says the real beauty of this model is that "the system keeps that dandelion intact. Anything you need to know about an event is right there." Tribal wisdom   When all the data surrounding an event is linked together, system users can query the data according to their needs rather than being hampered by rigid pre-filtering that limits how and what data become accessible. David points to the example of a system that does journal entries on a LIFO — last in, first out — basis. "Suppose your boss wants an income statement on a FIFO basis — first in, first out?" she asks. "You can't do it. Your journal entry has already used whatever rule was in effect at the time you made it." David maintains that traditional systems take one view of the world at a particular point in time and freeze it. "But, there are a whole bunch of different views that people in the organization might want. What an REA system would do is capture all the dimensions of inventory — sales, manufacturing activities, purchases, cash disbursements -- and link all those data together." Then, varied users can ask varied questions. "REA isn't trying to serve a specific master at the outset," Nittler adds. "To support financial accounting, all you need is an amount, a date and an account or classification of where you want that money recorded." But, he adds, there are many other things businesspeople might want to know about a sale: Who was the customer? Who was the salesperson? What was the product? Was payment made by cash or credit? How long did it take -- or how many sales visits were needed — before the customer finally wrote a check? The list goes on and on. So do possible uses of those data. "REA models the sales event or any other business event as richly and accurately as possible," Nittler says. "Then, everybody looking for information can go at that event from any perspective and get what they need." Nittler adds, "REA is user neutral and does a much better job of serving the line managers and knowledge workers of today, a market tremendously underserved by ERP systems." Toward a service orientation Speaking of ERP systems, it isn't uncommon to hear them compared to concrete: easy to pour, then set like stone. "They're very fluid when you're first installing the system," David says. Once implementation teams sort through the system's many options and settle on all the specifics, "getting it into a different shape is almost impossible." That inflexibility is one reason companies are moving toward service-oriented architectures that break up processes into smaller components. "If your process changes, the system underlying it should automatically change, also," she adds. And therein lies another plus for REA, which can be used to model any business event. "You don't pre-configure this giant, best-practice business process and pour concrete around it," Nittler says. "You're modeling events, not processes. Then, you link the events together to form process. That provides process agility, which is a very difficult thing for any traditional system to provide." Such agility opens opportunities. As MSU's McCarthy notes, companies today often get things done by "connecting seamlessly to each other." Whether it's the systems links necessary for efficient outsourcing, software-as-a-service applications or some other collaboration, "REA facilitates breaking the language barrier." With all the benefits REA modeling could offer, why hasn't this approach taken hold with software developers before now? Because systems from the 1980s, when REA first surfaced, couldn't handle the processing requirements such a model presents, David notes. McCarthy says technological ability still lags behind his original REA vision. On top of that, accounting traditions put a damper on REA development. "I have always underestimated how entrenched current philosophies are," McCarthy says. Nevertheless, McCarthy's notions took hold in many scholarly hearts, and over the past 25 years, they have earned a strong academic following. REA is simply an alternate way of looking at activities in a business," David concludes. Now that technology is catching up with McCarthy's vision, "this alternate model is gaining acceptance." Bottom line  

• Today's corporate-computing environment demands agility that ERP systems can't easily — if ever — deliver.
• A 25-year-old modeling method now shows promise. Called REA analysis, it translates business activities into resources (such as cash or goods), events (sales, for example) and agents (including people and companies that participate in events).
• REA provides a rich but user-neutral view of business activity, so anyone in an organization can use and benefit from the data.
• REA also facilitates process analysis and reengineering, as well as connections between users, companies and applications.

KnowIT