In-Depth
Best Practices for the Real-Time Enterprise
Overcoming the unexpected obstacles to business process change
A global inventory analyst with a large IT services company says that he’s skeptical about the new purchasing, return, and inventory management system his company is implementing. With just months to go, major project milestones have slipped, he says, and “it seems like for every step forward we take, we’re taking maybe two steps back.”
What’s more, he points out, many of his co-workers, including some of his immediate superiors, are also skeptical of the claims that have been made—by executives and consultants alike—about the efficacy of the system.
“We’re all skeptical. [My immediate supervisor’s] main concern is that we have something right now, and if it’s not broken, don’t try to fix it. Consultants tell you, ‘Look how much more efficient we can make everything!’ but we’re comfortable with the way it is now,” he says. “There are a lot of people here who, quite frankly, expect that this is not going to work out.”
This skepticism endures, he admits, in spite of the fact that the benefits of the system, which would deliver real-time or near-real-time information about inventory levels, as well as integrate his company’s inventory and return management systems with its purchasing system to automate a number of business processes, are compelling.
Skepticism is merely one of the potential bulwarks to be overcome by IT departments charged with building an infrastructure for the so-called real-time enterprise (RTE). Other potential issues include ownership clashes—over systems, data, business processes, or other assets—with individual business units; transforming business processes to better conform to the requirements of the RTE; managing multiple or conflicting projects; and, naturally, driving adoption of new technologies among end users.
Not surprisingly, these so-called “collateral” aspects of RTE implementation can’t readily be addressed by integrated business intelligence (BI) software packages. For that very reason, some vendors are understandably reluctant to discuss them. And yet, analysts say, they’re often among the most important issues confronting any RTE implementation.
For example, points out Forrester analyst Bruce Temkin, operational concerns—such as those described above—are more often than not at the bottom of failed or unsuccessful implementations of customer relationship management (CRM) software. Going into such implementations, Temkin suggests, IT organizations tend to concentrate on IT issues such as the integration of back-end systems, largely at the expense of managing process change. This is a problem, he points out, because resistance to process change among BI constituencies and individual business units alike is the leading cause of implementation failures.
In a recent Forrester survey, 48 percent of satisfied CRM adopters, along with 39 percent of unsatisfied users, cited resistance to process change as the most significant difficulty that they faced. Among both satisfied and unsatisfied CRM adopters, Forrester found that more companies (46 percent) encountered issues with process change predicaments than with back-end integration scenarios (34 percent) or software costs (33 percent). Asserts Temkin: “Organizations are inherently resistant to change, and there’s no constituency for change inside of any organization.”
Best Practices For Smooth RTE Implementations
Vendors are very aware of this problem. Most cite experiences with a variety of different customer implementations and suggest that there are best practices that companies can follow to insure as smooth an implementation as possible.
The first and most important, suggests Tho Nguyen, director of data management strategies with SAS Institute Inc., is to keep the lines of communication open, especially with upper-management, colleagues at other sites, executives in other business units, and—just as important—with end users.
Before SAS even talks about the technology issues associated with an implementation, Nguyen notes, it meets with representatives from IT and with upper level executives to ensure that the expectations of both groups are aligned with one another—as well as to vouchsafe sponsorship from executives. “If there’s no sponsorship at the top, there’s nothing that IT can do. We address this in both areas. We talk at the sea level to understand what their needs are and how IT can help. Technology is the last thing that we talk about.”
As far as open lines of communication are concerned, the inventory analyst we introduced in this article gives the project manager who oversees his company’s RTE implementation effort top marks. He says that this person holds regular meetings with users to discuss the benefits of the software and to field questions from them about its use, especially in terms of how it will be able to improve upon tasks that they exploit the company’s existing systems to perform. “He meets with users and [he and the other project managers] have these user group meetings and they address concerns. Sometimes if he can’t answer a question, he takes it back and thinks about how it’s going to be addressed, and then presents us with it during the next meeting in a way that he says should demonstrate the value of the new system to us.”
Another important practice, suggests Nguyen, is to make a plan and stick to it—even if timetables slip as a result of missed delivery milestones. “If you have a roadmap, make sure that phase one works before you proceed to phase two.” Organizations that change their original plans in the face of unexpected setbacks risk creating further confusion when incremental changes accrue and start to contribute to the management problem, Nguyen observes.
Jim Ivers, director of product marketing with enterprise application integration specialist WebMethods Inc., suggests that organizations and vendors establish a “competency center” to centralize communication and planning for RTE implementations. “A trend we’re seeing is the integration competency center, where people are creating single points of control or single centers of excellence, where any discussions are done at a broad integration level.” This has the effect, Ivers notes, of providing an outlet in which all business constituencies that could be affected by an RTE implementation can voice their concerns.
An important concern of effective project management, suggests Cathy Benko, global e-business practice leader with Deloitte Consulting, is to minimize the potential for disruption among business units and end user constituencies. To illustrate this point, Benko, who is the co-author, along with Dr. F. Warren McFarlan, of "Connecting the Dots: Aligning Projects with Objectives in Unpredictable Times," outlines a scenario in which a customer service department, for example, is the intersection of several different projects, IT-related and otherwise. Perhaps, she suggests, the department is moving into new digs at the same time that its desktop workstations are slated for replacement, even as IT prepares to implement a new CRM system.
The upshot, Benko says, is that unless these project timetables are staggered, there’s just too much change for a single department to successfully assimilate in so short a time: “If you take a look at the change required … in terms of the human ability to adapt and absorb change … it is no longer an acceptable risk.” On top of all of those changes, of course, are the technical, cultural, and business process changes associated with an organization’s RTE project.
SAS’ Nguyen stresses that it’s also important for organizations to be as pragmatic as possible when they approach the design of their architectures for the RTE. After all, he points out, not all information systems need to be re-designed for real-time information delivery. From this perspective, it’s also possible to minimize the potential number of users who are affected by an RTE implementation effort. Suggests Nguyen: “They have to ask themselves how much is a pain and how much is a need.”
Vendors and analysts agree that one of the most difficult aspects of any project implementation is driving end user adoption, whether it’s encouraging the use of new client tools or changing the internal process flows of business units. In the Forrester survey, respondents indicated they had more difficulty driving adoption among end users (23 percent) than with implementing the technology in the first place (11 percent).
In light of this, the inventory analyst previously mentioned says that there’s another consideration which project planners would do well to consider. In many cases, users are comfortable with the interfaces that they’re already working with. “A lot of them, if they’ve been here awhile [and using the same interfaces], they get intimidated by these new systems,” he admits. He says that when his company’s project is done—if it’s ever completed—he’ll get to use the analytic interfaces and tools that he’s already comfortable with. “As far as I know, what they’re doing all takes place in the background and won’t affect [the interfaces] that we use.”