5. Complexities of change
The complexities of change are primarily based on, and involve, two issues. The first is the human interaction. This is because humans have differences in needs, culture background, personality, learning capacities and abilities, skills and talents, languages, dialects, and communication abilities. In addition, humans have different education levels. The second complexity is the involvement of Information Technology (IT) in change which involves humans and requires humans to correspond to the changes caused through the IT involvement. Because people, as Goleman et al (2002) and Davenport (1993) have explained, have different needs to fulfill, it is highly possible that not one single IT system or process change will correspond to a general mass of humans affected by a process change involving IT. This is why:
5.1. Human side of Change
Hammer and Champy (2001) said: “No one is in charge” to cover process requirements from the beginning to the end, because of departmental job boundaries where people begin and end their jobs, however not consider what happens with the task once it leaves sight (p12). Here are a few critical issues to consider:
5.2. Lack of Change Process Management
The first issue is that nobody is in charge to manage all groups, teams, and corresponding tasks, although this is where the project manager comes in. But a project manager usually does not manage associated and consequential change-causalities that fall outside his/her project boundaries. For instance the project involves the process change of collections. A change in that department also will probably affect customer service, sales, marketing, distribution, and other departments. Ideally, according to Meredith and Mantel Jr. (2003), the project manager will consider outside affects of his/her project initiatives when evaluating risks and opportunities.
5.3. Job Boundaries and Beyond
The second critical issue in human complexities of change are the job boundaries and beyond. Hammer and Champy (2001) suggested that under most circumstances, the people involved in change usually look at their job activities if they know and understand them. If they do not understand their job tasks requirements, then they have probably a problem with their supervisor anyway since they might not perform well within their task requirements (Goleman et al, 2002). But if they know their task requirements and their boundaries, they usually won’t look beyond because their motivation stops where their boundary stops. This is especially critical in large organizations (Hammer and Champy, 2001).
Davenport (1993) suggested that change often takes place or is implemented as a casual decision without regard to the consequences across the boundaries. Managers pass on the bottle necks to other teams. Their focus might then be on how their performance looks. They rather let the other team across the boundaries worry about the ultimate solution. And so the problem and the bottle neck are passed (p16). Also when making a change-decision, the effects are not considered while according to the author, it might be tremendously beneficial to have a plan of how to deal with the consequences. Even better, Davenport (1993) suggested, participants and those affected by the change should be included.
Change managers should let the staff know what is happening and how they are affected by it. This will buy him/her very likely more effective change than just dictating a decision and let the employees deal with it themselves. When team-workers do not look beyond their own boundaries, they likely will not be able to perform work to the best interest of who ever performs tasks associated across the job boundary.
5.4. IT Complexities
The next complex-critical issue is whether IT functions as an oppression or opportunity during change. Davenport (1993) said that “even a poor IT infrastructure can be an opportunity for process innovation; many firms today need to rebuild major systems, but they should not construct them to support inadequate or inferior processes” (p4). This means, inadequate or inferior processes already existent are bad processes which are now being automated into bad processes functioning faster (Davenport, 1993). This also means that an opportunity for affected people could arise to realign and completely redesign their processes from scratch.
But IT-laid-over processes would oppress the participants, if they did not improve their processes according to their needs instead, and IT forces a system onto them that will not address the human need and cross-boundary issues. Hammer and Champy (2001) said “…reengineering has been the key that unlocked the potential of this technology. Merely overlaying new technology on old ways of doing business achieves very little. …IT allows us to make worse decisions sooner” (p3).
“Putting a Website in front of lousy business processes merely advertises how lousy they are. In the absence of robust, re-engineered processes, electronic commerce is a nightmare, not a dream” (Hammer and Champy, 2001, p6).
In respect to Information Technology (IT) used in business re-engineering, “it should by now be clear that re-engineering is not the same as automation…Automation simply provides more efficient ways of doing the wrong kinds of things” (Hammer and Champy, 2001, p51). Hammer and Champy (2001) suggested that without first re-engineering (starting with a clean slate) and just automating existing processes, the system will yield in an automated mess; “Automating a mess yields an automated mess” (p6).
However those organizations “…that linked the two… achieved prodigious payoffs” (Hammer and Champy, 2001, p6). Re-engineering completely from scratch and using IT as an enabler to automate these newly developed processes, as Davenport (1993) referred to process innovation, and Kotter (1995) to leadership, it is suggested to do following: Innovate, and improve (Davenport, 1993); re-engineer and automate (Hammer and Champy, 2001); and lead and manage according to situations required (Kotter, 1995).
5.5. Change Resistance
Resistance to change can be a big reason for a failed reengineering project. Or at the very least, it can increase the cost of the project. People or human interests can be resistant. IT and mechanisms, or the processes themselves are never resistant, but so often are the cause of it, because they conflict with the participant’s interest. For instance “[a] manager likely to lose people, power, or other resources as a result of process innovation will naturally be tempted to resist the change” Davenport, 1993, p14).
Davenport (1993) said that effective process improvement or innovation, both require a “willingness to change” (p14). Without that willingness to change and follow, the leadership has been deactivated and has become ineffective. When leadership neither motivates, stimulates, or gets the people moving into the desired direction of change, then the appropriate level of force or leadership style may have to be applied. This may as well be a dissonant style and result into radical change, as it has been suggested, to wipe existing processes out, and start out once again with a clean slate (Davenport 1993; Goleman et al 2002; Hammer and Champy 2002; and Kotter 1995).
5.6. Process management, collaboration, and leadership
Processes are responsible of how well people collaborate. Collaboration is the result of leadership. This is because leaders either create an environment in which collaboration functions well or badly. The better people collaborate the better the information travels between them, required to achieving one common goal, all according to the leader’s objective.
Communication in a positive work environment will travel clearer, which will result to increased relationships. And positive relationships, when mistakes and errors are discovered, are more forgiving than bad relationship. In fact, bad relationships result in a bad work environment, which results to stress, less forgiving in unclear communication and blaming, with the result of high personnel turnover and customer dissatisfaction (Hammer and Champy (2001), p28).
So when process-steps need to be performed and poor collaboration and/or communication between the individual process-steps exist, the process efficiency level declines and cost increases. And how does this revert back to leadership? Leadership is responsible for effective task completion and therefore also in the position to see the entire process view, and manage (or lead-Kotter, 1995) it.
Hammer and Champy (2001) defined process: The measure whether the process works is “…a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer…but none of them matters one whit to the customer if the overall process doesn’t work-that is, if the process doesn’t deliver the goods” (p38). The measure of whether a process is good is if the customer is satisfied with the product and keeps coming back for more. If the competition takes the sales then the process quality does not matter.
Davenport (1993) laid out his opinion about processes: They have costs, time, output quality, and customer satisfaction. When we reduce costs and increase customer satisfaction we have improved the process itself. The measure for effective processes is the reception of the product by the customer, which is the level of satisfaction. And the customer measures satisfaction by the time of output, the cost, and the quality. If a process, therefore, does not serve the customer, it is a bad or poor process, although it may have been perfectly and efficiently delivered. (p6 and p9).