Is there a Corporate mentality that resists change?

Over my past twenty years of consulting to large enterprises, I have been surprised by the frequency of repeated patterns in corporate behaviour. No matter what the business, be it Government, Retail, Utility, Manufacturing, Service or whatever, the same patterns come up again and again. It has to be said that these patterns are more acute in some business verticals rather than others, but nevertheless, they are apparent across the board.

I'll probably analyse these patterns in greater depth in some future blog, but for now I'm particularly interested in the apparent corporate mentality that resists change; especially in the areas of process or IT system.

I am struck that this "Resistance to Change" is apparent no matter how strong or obvious it is to the detached observer that such change is needed. So what are the underlying reasons for all this?

In my view those people that don't like change fear being changed themselves. When change is in the air, fear and resistance to change follow, despite potential benefits that are obvious to others.

People fight against change because they:

• fear losing position/control/influence,
• don't understand why the change has been suggested or what it implies,
• weren't consulted about the change,
• don't think the changes makes sense or will improve "the business",
• like things the "way we've always done it",
• are being moved out of their comfort zone into the "unknown".

If we make the assumption that the proposed changes have obvious and real benefits to the company or department in question, then in all cases fear and resistance of change may be seated either in ignorance, self-interest or resentment.

Beyond the individual there are, in my view, two corporate-wide factors at work in the "Resistance to Change" that exacerbate the situation and are endemic; the Silo Mentality and Decision Accountability.

Silo Mentality

The "Silo Mentality", as I'll call it, is a form of tribalism that is encouraged and nurtured at the bosom of most businesses (especially government, quasi-governmental institutions and the more "mature" corporation, in my experience).

Officially, within the organisation, the Silo will be seen as a division and subdivision of the business into logical business units (departments) responsible for a specific, ring-fenced range of tasks within the business with the idea of fitting into the wider, overall strategic business activities.

The problem with this  approach is that it creates both a fundamental lack of awareness of, and total indifference to, the overall goals of the business. Instead people become mired in the workings of their own little area and locked in a form of combat against all other areas - a real "them" and "us" mentality.

Often this Silo Mentality starts at Board level and is not helped by the fact that senior management are either very poor at disseminating the strategic goals to their area(s) of the business or are, sadly, somewhat ignorant of the strategic goals themselves.

Importantly, most significant changes proposed for any business affect many areas of the business and cut across many vested interests within that business, even if they have their origins for one specific area of the business.

In the modern corporate such changes inevitably mean that the IS department or the IT department (where there is still in-house development) are involved. 

Very commonly the initiative for change lies outside of the IT department, with Sales or Finance for example, or may have been instigated by an external agency, such as a consultancy, looking at the business with fresh eyes.

Frequently the initiative for change is rooted either in the observation that the business is losing competitive advantage to competitors who are perhaps perceived to have better, slicker systems in certain areas, or through chronic internal dissatisfaction with the performance of current systems.

Thus, the very proposition of change is seen as both a threat to those in IT and as an insult to their work, for both of which they will be, not unnaturally, highly protective. The very nature of IT being devolved to its own department from Board level downwards, encourages an insular, self-serving protectionism. 

This is especially true where, in today's highly connected World, the proposition would mean the adoption of either outsourcing of current systems (e.g. the Accounting systems taken over and run by an external company), or increasingly, the adoption of new, more flexible web-based software systems through Software as a Service, Cloud Computing and so forth.

Understandably, they will see anything of this nature as a reduction of both their influence within the business and a potential threat to jobs; both for those involved in architecting, designing and developing systems and for those running and maintaining them.

Decision Accountability

Decision Accountability is also an issue found at the base of most businesses (again, especially government, quasi-governmental institutions and the more "mature" corporation, in my experience). Although most strategic decisions should start at Board level, this is less common when it comes to IT.

A Board that possess a number of influential and far thinking Non-Executive Directors may be able to challenge a more reactionary team of Executive Directors away from their traditional lines of thinking.

The rest of the Board will defer to the IT Director as their expert to advise them on the best means of handling change from an IT systems perspective and whether such changes are possible, feasible, affordable and worth the effort and time. Some companies will be lucky enough to have an IT Director who remains dispassionate about the IT department, is fully informed with respect to the most effective technologies and is looking for the most effective, flexible and scalable solutions for the business.

However, these contingencies are not common and it is all too frequently the case that the IT director (and other directors) will, in turn, defer to their more technical managers and their senior technical and project staff to advise them of the "right way" forward.

In other words, no one wants to be seen to be making the wrong decision, so, in the end, no decision is made. This inevitably results in a protracted cycle of "Specification", "Functionality" or "Architecture" meetings that produce much in the way of documentation and diagrams and little in the way of genuine progress.

Should a decision be reached, then perhaps as often as not the easiest answer is the answer with the least risk to the individuals making it i.e. they either get IT to build on current systems or, on the recommendation of the IT department, they buy and install a costly, off-the-shelf ERP package from one of the "big 3" vendors for IT to customise over the next few years.

Does SOA really deliver flexible business process management?

To keep customers purchasing services and products, continuous improvement of processes must be an ever-evolving strategy for most organisations. The more flexible that business processes are, the more agile an organisation can be in responding to market demands and customer needs.

Service-oriented architecture (SOA) is a method for linking business and IT resources on demand so that desired services can be provided for customers. The objective is that, when SOA is properly implemented, businesses can respond relatively quickly and cost-effectively to changing market conditions.

Principally, SOA is intended to connect applications across networks through a common communications protocol, allowing organisations to reuse old software, often with the help of Web services.

There are certainly examples of enterprises succeeding with SOA, building services that can be shared across business units, and lowering long-term expenses. SOA is intended to make it easier to do compliance reporting, software-as-a-service, legacy modernisation, unified communications, business intelligence, and various other important tasks.

But does this really work in practice? Even more importantly, does it pay off?

SOA is architecture and is thus applied across the business, not project-by-project.

For SOA to work it must be applied uniformly across the enterprise. Furthermore, any changes or additions to underlying systems must also undergo the additional work required to bring them into the SOA compliant framework.

SOA needs to prove itself to the business. They need to know not only what the ROI is, but when it will happen. So, what is the potential return to the business to justify the usually very high costs?

Many companies would look to use SOA in order to service enable legacy systems. SOA is a big up-front cost and should be justified. SOA should be thought of as  an enabling software infrastructure. In other words SOA cannot in itself be cost justified as no particular ROI could ver be attributed to it.

Therefore, you have to look at future individual projects and their tangible benefits to cost justify the underlying SOA infrastructure. IT departments have been calculating the cost and benefits of infrastructure for years, such that a single project cannot be expected to cover the initial cost of any corporate-wide change to its systems infrastructure.

Reuse is the most important metric by which large companies will be measuring the success of their SOA efforts – but most don’t expect high levels of reuse to happen any time soon.

A new survey commissioned by BEA Systems finds that a majority of the largest global organizations (61%) expect no more than 30 percent of their SOA services to be eventually reused or shared across business units. In fact, only five percent expect to see more than half of their services to be reused.

However, despite the management support and inflow of new money, Sara Hepner, senior director of services marketing for BEA, observed that 40% of these enterprises said their “SOA projects were impeded due to justifying the investment financially. They’re having a hard time building strong ROIs.” Software infrastructure was the most significant cost involved in SOA projects, she said. 

So how much will an SOA project will really cost the business? Dave Linthicum recently posted some guidelines on estimating the cost of a service-oriented architecture project.

Dave offers the following formula:

Cost of SOA = (Cost of Data Complexity + Cost of Service Complexity + Cost of Process Complexity + Enabling Technology Solution)

How do you measure the cost of complexity? Here's how Dave says the calculation is done, for example, to arrive at the first variable, the cost of data complexity:

Cost of Data Complexity = (((Number of Data Elements) x Complexity of the Data Storage Technology) x Labor Units))

• The "Number of Data Elements" is the number of semantics you're tracking in your domain, new or derived.
• Express the "Complexity of the Data Storage Technology" as a decimal between 0 and 1. (For instance, Relational is a .3, Object-Oriented is a .6, and ISAM is a .8.)
• "Labor Unit" is the amount of money it takes to understand and refine one data element, e.g. £100

As an example, you could arrive at a solution such as this:

Cost of Data Complexity = (((5,000) x .5) x £100) This equals £250,000 for this portion of your SOA costs.

The next step is to apply the same formulas to determine the costs of other variables, including Cost of Service Complexity, Cost of Process Complexity, and Enabling Technology Solution.

Conclusion

Inevitably it would be prudent to allow a generous contingency for both cost and time in any estimate.

From this you will see that costs are likely to escalate into the £M's and that timescales are also likely to be measured in years and months, not weeks and days. IT system designs sometimes overlook the desirability of modifying systems readily.

Many systems, including SOA-based systems, hard-code the operations, goods and services of the organisation, thus - once again - restricting their online service and business agility in the global marketplace.

Trends in the use of ERP in Europe

It has been estimated that annual spend on maintenance and process customisation in the ERP and CRM market represents around 20% to 33% of the overall market spend – indicating an annual spend on maintenance and process customisation of between £1.75 and £2.75bn.

Today, however, ERP systems face serious problems.  Many companies are abandoning traditional ERP systems and are looking for more effective options to meet their business requirements – including software-as-a-service and hosted solutions.

According to Upside Research Inc., almost all enterprise organisations have made significant investments in ERP, CRM, and other packaged applications. Yet in many cases, business drivers are requiring an ever-increasing stream of process changes and additional functionality (or simply integrations) that need to leverage ERP capabilities.

However, these systems are also costly to maintain. Companies spend between 20% and 33% of their implementation costs every year on maintaining the systems (Forrester Research). Customisation increases ownership costs, as the applications become more difficult to upgrade.

Once installed ERP systems become quite rigid and are very difficult to change - "It's like concrete," says Julie Smith David, an associate professor of information systems at the W. P. Carey School of Business, "Pour it out, and you can form it to any shape you want. Once it settles, getting it into a different shape is almost impossible."