By Tom Inglesby

The paper continues this approach of dividing the IS/IT functions from the rest of the company by saying, "In more recent years, IS/IT has been increasingly seen as a tool to support the business. It is no more than a means to an end. Without looking at the whole integrated picture, the best IT in the world may produce little actual benefit."

Now, it must be understood that Bull has an agenda in this; it is a systems integration company that wants to do your next implementation, a job that might otherwise go to the internal IS/IT group. Still, they have a point when they add that people issues are perhaps more important than technology issues these days. While "elegance" in technology appeals to many in the "in" crowd, the real purposes of systems are to benefit workers and further the goals of the business. It's nice if they are elegant but the real hope is that they function flawlessly.

Bull lists several faults that can bite a poorly prepared project right in the corporate assets:

• Confusion over objectives — is it cost reduction, improved functionality, technical automation? Sending mixed signals to different functional areas gets groups set against each other.
• Poorly managed expectations — people are allowed to expect too much too soon and then get disappointed and cynical. Many projects are complicated by workers who have heard about a similar new system at a competitor. "When will we get these benefits?" they ask. Or worse, they don't ask and thus the expectation can't be addressed with facts.
• Tensions between centralized and decentralized philosophies don't get resolved early. If a company is going through the massive reorganization that comes with a changeover from mainframe to client/server, for example, the whole methodology of internal business processes will undergo radical changes. Unless management plans for it, these changes will cause turf battles that fester for ages.
• Lack of commitment from one or more groups of stakeholders in the project. Whether the organization is team-oriented or not, a systems integration project must get input from all areas, not just IS/IT and upper management. The stakeholders in question are you!
• Lack of clear and measurable responsibility for delivering the business benefits. The old saw about no quality without a metric holds true in an implementation, too. If you can't measure responsibility for change, how can you measure success?
• Active resistance to change. In many ways, this is the sum of all of the above compounded by an ineffective exchange of information from top to bottom and bottom to top.

Most people below the executive suite know the truth of these faults, not just in systems integration projects but in any type of change. Change management can be the most highly charged activity in a company undergoing a realignment of goals. What became known as business process reengineering through the popularity of the books of Michael Hammer, James Champy and others, has caused as much heartburn among those impacted by the changes as it has given benefits to the companies implementing them.

When a system implementation project is planned, it can be driven by technology needs — increased system hardware capabilities — that are thought of in terms of "things, not people." The reason may be to give the users more speed or throughput or access, but these will be relatively transparent to those users. Things might seem better for a while, until they get used to the differences, and then they'll complain that the new systems aren't fast enough. Instantaneous gratification is the unspoken buzzword of the computing industry. All users should be put on "green screen" terminals for a few hours each year so they appreciate the speed they have on a PC or networked client.

Bull lists advantages to using an integrator, including having the systems integrator (SI) take responsibility for change management in all human issues. They believe that two external forces — formal management and "soft leadership" — combine with personality to shape behavior in the workplace. Formal management is the overall mission, goals and objectives that flow down from above; soft leadership comes from the actual corporate culture and values — which are not always what management would like them to be.

This brings us back to the paper's title, "Should Systems Integrators be Change Managers?" The fact is, if they — internal as well as external integrators — aren't proper change managers, then what they wreak can have a greater negative impact on the users than the benefit received from faster processors and more applications. By leveraging their experiences with previous implementations, a good SI will know where to expend the efforts necessary to implement the people side of a system as well as the technical side. Someone, perhaps you, in the implementing organization had better be watching to make sure this vital factor isn't slipped in the press of deadlines and budgets. After all, when the SI goes home at the end of the project, your job will just be beginning.

Copyright © 2020 by APICS — The Educational Society for Resource Management. All rights reserved.

Web Site © Copyright 2020 by Lionheart Publishing, Inc.
All rights reserved.


Lionheart Publishing, Inc.
2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA
Phone: +44 23 8110 3411 | br> E-mail:
Web: www.lionheartpub.com


Web Design by Premier Web Designs
E-mail: [email protected]