I have become astutely aware of the impact of change on an organization. Without mentioning customers, the abilities for some organizations to change (improve hopefully) the way they do business have amazed me.
As an example; in the mainframe business world, yes the mainframes still exist! The institutionalization of a workflow process can be one of the largest hurdles one can possibly face in a sales cycle to include implementation. What does this mean to current organizations and how can this apply to every day life?
I have a friend who has posted a similar topic on his blog: http://pragmaticarchitect.wordpress.com/2011/03/05/how-to-build-a-roadmap/, where he provides details to organizational change (gap analysis) for using software design and development principles to help organizations change. I see this being used across the enterprise to help organizations align themselves from mergers or for annual reviews. Now you maybe thinking I am saying - change for change sake. This could not be further from the truth. Just look at the amount of mergers and acquisitions going on today and the amount of consolidations over the last decade. These organizations have to some extent, combined so many different business units of the same type, but continue to run them as completely separate business units.
What does this have to do with organizational change? The companies merge to provide continued growth to the shareholders. The growth, if managed properly (In My Humble Opinion) can provide huge savings in the reduction of common jobs. Hold that thought that this is not a job reduction discussion; I will get back to that thought. What I am talking about here is the excessive amounts of money (software maintenance alone can be in the 100's of thousands of dollars); time and effort companies waste by not standardizing on a single and even unified business process.
Take for example the process of Workload automation. Working in the mainframe world these days and having that experience in my past (I am proud to say), shows the tremendous strengths of having a workload automation (formerly called schedulers) available to manage the hundreds of thousands of jobs a mainframe can and does run every day. Now, extend that functionality out to the distributed servers where a lot of data for one reason or another either starts or ends for any number of given business processes.
Now with these as examples, the ability of an organization to centralize all of the scheduling packages throughout an organization can be very difficult due to the organizations resistance to change. The issue is, can the organization change to provide value to the solution? There is the cost of the software, then the cost of the organizational change. Keep in mind; most mainframe people do not even know how many distributed computers connect to the mainframe other than those possibly at the application layer who wrote the program.
My point being here, that organizational change can be the largest part of a project and in my humble opinion, is why most organizations defer change for years. To get back to the "Job" discussion. What if we as a computer worker, were more acceptable to change. Not change for change sake, but change for improving organizational efficiencies. The jobs that shift from using in most cases a old technology that is inefficient in today's highly computerized world to a new centralized business process provide ongoing job security, show the ability to change and provide time for improving other business processes.
As noted with the release of the iPad II already, technology is constantly changing. Removing the barriers too many of us bring to work every day can help everyone of us bring more value to our companies, to the industry and to the bottom line of the companies we work for.
