Author: Raja Mohan Ivaturi

Introduction

The conflict between Business and IT has been an acknowledge issue for a long time. There have been many suggestions and solutions implemented but the real success of complete alignment between Business and IT depends on a number of factors. These include

• Human factors
• New tools to support the people

While business is the driving force and IT need to support it, both the functions have their individual goals and objectives which must synchronize for achieving the organization level objectives. Making this happen is a big challenge for CXO’s. While there have been many issues already identified, acknowledged and addressed to some extent, this document covers a few other factors that influence the successful alignment between these two important functions.

Overview

In most businesses IT plays a critical role in enhancing the business with many benefits. To name a few of them:

• The ability to identify potential bottlenecks and other threats
• Decision making for addressing current issues as well setting up future plans
• Accelerating the business transactions
• Reducing paper work
• Improving transparency and so on

As business has grown to a level where any big business could not be visualized without IT Support, the issues of misalignment between business and IT have continued. Since the times of RDBMS based systems followed by ERP’s and now Enterprise 2.0, many solutions claimed to have addressed the conflicts among the stakeholder functions of a Business.

The focal points may be simple access by many functions for a relevant piece of information or a long time approval involving cross functional flow or a collaborative transaction which could include even stakeholders outside your organization. While the tools and technologies were trying to bridge the gap, the issues continued due to other factors that need not be technical. Major issues as we all know, were from the human factors which are critical for success with or without a tool and technology support.

Challenges

Concept of migrating the Focus from Function to Process

There is a correct migration path from function based focus to process based focus in the organizations. The migration happened correctly from a business point of view as well as from the supporting applications point of view. Today you see less numbers of best of breed applications whereas you see many applications extended to support the entire business value adding chain. For example you will see an enterprise application that supports:

• Supply chain
• Customer relations
• Financials and
• Human capital.

In addition the solution also supports business intelligence either from historical data or the real time based intelligence. The solutions are even extended to support integrations with other enterprise solutions in a secure manner, to allow legacy solutions to work together. Ultimately you may see the solutions supporting even collaborative business with business partners.

All this development from the ages of applications like Wings and tally kind of applications supporting only a few finance and accounting business transactions, happened because of the direction business was moving. Very soon the existing support applications were not preferred by the business for obvious reasons.

Does this mean, IT is very much aligned to the Business? To some extent it is true because the intention of IT vendor was in the right direction. At the peripheral level everything claimed to be serving the purpose. But what in reality happens in the business says the alignment still has cracks because of the way the tools were understood – or perhaps misunderstood – and the way they were handled.

In this context let me try to explain what we mean by alignment. Business and IT have their own goals. The goals ultimately need to be mapped.

• No IT goal must exist, if it doesn’t meet one or more of the business goals and objectives.
• No business goal should be allowed to stay with empty space without being mapped to one or more of the IT Goals.

Alignment in real sense

Business and IT needs to understand the alignment in its real essence. In the modern era everyone talks about collaboration and close alignment but in reality it is still missing. The fact that the alignment still has gaps today, requires a closer look because all stakeholders showcase a lot of data supporting how well they are collaborating with the other stakeholders. The data looks quite smart but a simple investigation reveals the alignment is missing.

Coming to the Business and IT relation, I feel IT must agree categorically that it is a support function to business. Without business who needs IT? Hence it is not an exaggeration to say IT needs to work in a Helpdesk model. It needs clear cut SLA’s and other performance measures to make sure it meets the business requirements in a true sense. IT quoting reasons based on impact on their goals, and refusing to support business goals is something undesirable if you are seeking the best results. For that matter IT goals need to be derived from the business goals. It is in fact the responsibility of IT to make business understand the IT level issues to make sure business provides the right inputs in line with the IT constraints.

On the other side, the business team must understand that there is a clear difference between a wish list and well defined requirements. Many times, business analysts fail to provide the logic when IT asks some relevant and intelligent questions for details about an algorithm to support the business requirement. In fact this is a good approach by IT. To always seek the logic on how the business wanted the solution. With some sort of pseudo logic in writing the business itself may understand the difficulties.

Simple Requirement Matrix Doesn’t Help

In a typical Project management scenario, we all might have followed the practice of creating a requirement-solution matrix which detailed the requirements mapped in a matrix form to the corresponding piece(s) of solutions / reports /software components that are expected to be fulfilled. The observation is that this matrix which is meticulously built at the time of the planning phase is not re-visited in all required scenarios. Any agents such as scope change, any technology change decision, any change in the quality norms could have directly or indirectly impacted the matrix when a review could have avoided the impact. Many agents which apparently do not affect the requirements or the corresponding solutions also needed to be revisited.

Illustration

In a lamination making organization, an ERP solution was being implemented. The plan was to implement Financial and Purchasing modules in the first phase. One of the requirements was to migrate Master data, and data for purchase and corresponding finance transactions. The major milestones included the data migrations for Master data and transaction data of Purchasing and Financials.

There was a critical path with Purchase data migration and User documentation being the independent bottleneck activities needing some overlapping resources to be involved in both activities.

In the meantime, the company as a matter of policy when sales were down, decided to freeze all the purchase activities for the next 3 months till all the pending stock was sold.

While the Key Business users in the implementation team and the Implementation team were pushing to get through the bottlenecks, long brain-storming sessions happened to decide on whether to give priority to Data Migration or Documentations.

The majority of the team – especially the IT team – preferred to go live without documentation as they felt data migration was more important than documentation. This was because the issue was discussed in isolation without considering the recent decision that with purchasing literally suspended, the migration of purchasing data may not be as critical as was understood earlier. It could still be wise to go with Data migration based on some other factors such as availability of a Migration expert, but the point to be noted was that any business event could have positive or negative impact on the requirements and the corresponding solution efforts.

Lessons Learnt

1. The way the stakeholders look at the problem must include the possible scenarios that can result from a triggering event. Hence all stakeholders must work in unity instead of in isolation
2. The learning as well as the sharing information is important but more important is the way these inputs are interpreted with a closer review of the combined goals.

Right Metrics in place of “Kitchen Metrics”

Why does a major conflict happen in the name of goals and objectives between Business and IT or for that matter between any two stakeholder functions? The most probable reason could be that either the wrong metrics that do not directly relate to the results are used or conflicting metrics between them.

I will call the first category of metrics “Kitchen Metrics”. The rewarding and compensating mechanism needs to be carefully designed in such a way that business and IT functions work towards the common goals and ultimately achieve business objectives. Any metric that doesn’t reflect the end result must be discouraged.

A typical list of business and IT goals may include some of the following even though the list may not cover all possible goals as given in INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 6, 2007. The journal also suggested the typical mapping of these goals at the primary and secondary level.

Table 1 : Business Goals

Table 2 : IT Goals

Source: INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 6, 2007

Aligning Business and IT Goals is the key but the effective execution happens when the right and relevant metrics are set for the success these metrics must be more or less common for Business as well as IT.

Illustration

I went to do a System Audit for a UK based Heavy Equipment Manufacturing Company. I came across a scenario where the customer wanted to improve the inventory accuracy through an IT Custom Solution. The solution must provide a report which looks at the existing Sales, Purchase and the Inventory data and shows the effectively available inventory of each item. The existing application was considering all the stock that was blocked for sales and production orders, stocks that are expected to be received from the running production, purchase orders and other sources. Comparing this data against physically existing inventory, the system was showing the effectively available inventory. The business however wanted the modification to include even soft blocked inventory (means blocking for expected demand which is yet to be confirmed) against sales orders and other delivery orders.

The IT team discussed the situation with business and developed a solution. The metrics followed by the IT team during the development of an IT solution were typically the defects per KLOC, time for generating the report, refresh time when 1000 users simultaneously access the page etc. The IT solution would meet all the norms and would provide the solution.

On the other hand the Business may have metrics like reduction of inventory levels, reduction of redundant purchase transactions etc. These metrics when tracked didn’t show the expected results. The IT said they met all the business requirements as given by the business and the business says there is no improvement even after implementing the new IT solution.

My investigation found reasons as follows:

1. The report algorithm may not be correct or not cover some scenarios because of which some available inventory is still not reflected in the report.
2. There were some Production Orders which were open for a long time against which the inventory is blocked in the system. These orders were created for simulation by the business users and remained incomplete forever. Surprising to see in a Production System but it happened.
3. The report which shows the data of items offered many selection parameters like Item code range, start date range, expected completion dates, item category range, order types (of orders to which the items might be blocked) and item’s ABC class range etc. The business actually wanted to track the inventory status of all items under the bill of material of one or more ordered item against a production / sales order. For example, if business wanted to know the shortage of inventory for making bicycles, it wants the shortage not only for bicycles but also the shortage for all the components and subassemblies required to make bicycles. And this whole information must be in a single report. This requirement needed a different logic to get the effective inventory of all items under the bill of material of manufactured items. It also needed to make sure overlaps of the same item existing in the bill of many manufactured items were avoided.

I explained this to the business and IT teams and both agreed the setbacks. However the learning I wanted to mention here is that the gap between IT and Business happened because of some technical reasons as well as human mindsets.

If we look at reason 1 – the algorithm being wrong and not considering some scenarios – it is because business probably didn’t provide the requirements in detail or the IT team didn’t ask the right questions to gather the requirements accurately.

It is also evident that the solution when developed was not tested to the desired level for which again, business and IT are equally responsible. The IT team’s analyst prepared some test scripts and the business users executed them blindly. They didn’t try other variants to check most of their critical business scenarios were supported.

Reason 2 indicates that business users were not aware of background logic of inventory blocking against active production orders. That’s where they created production orders just for some simulations and didn’t cancel them as they didn’t know the impact on the logic used by IT. On the other side, the IT Solution could have proactively provided a simulation option which could have been isolated from the real production environment.

Reason 3 is a classic case, where the business requirements were either not clearly defined, or IT totally failed to understand the requirements. While the users wanted to check the effective inventory while confirming a specific order, it is obvious that they wanted to look at the data for all the dependent items for the main item against that order. This point was sadly missed in all the phases of development.

Lessons learnt

1. Every stakeholder function has a tendency to choose safe metrics which can be managed on their own and pretend to avoid the right metrics that are linked to end results. This is the reason why an IT project manager opts for looking at typical project metrics but not business based acceptance criteria. We may hear some statements
   “we asked the business to test and verify and they didn’t complain in testing.”
   “We shared the design document and we didn’t hear any comments” etc.
   At the lowest level, both were stakeholders and IT needed to work together. The same is the case with business users who want to wait till the end and safely complain. Ideally business users should take ownership and be involved throughout the development.
2. At any point of time, the IT team was looking at building a report as per the requirements from business and within the time lines. They were not aware, nor tried to know the ultimate goal for which the report was being developed. Business level metrics are to be mapped to IT as well to make sure IT works for the common goals along with the business team.
3. Business users have enough intelligence to express their requirements but translating the requirements in to IT language is a challenge. IT may have to ask more intelligent questions to get a complete understanding of requirements and help business provide the right inputs.

Moderation through Technology plus Domain Expert

Even though we can’t generalize, one basic issue in many customer organizations was that the top decisions including the IT decisions were taken by the Business people as they are the people who take the top positions. CIO’s of such organizations used to look at technology journals or attend some technical forums and make decisions. They may be recommending many solutions such as migrating to ERP, SCM, Knowledge Management, Data mining, Enterprise 2.0 and a variety of software solutions. They trust these solutions will enhance Productivity and Revenue through effective decision making, transparency, short go to market cycles and new customer sources.

In many cases they do, but in most, the costs may offset the gains. From the Analyst’s point of view the company may be looking sound but in reality the results might be different. In summary such decisions needed to be coupled with the Cost / Benefit analysis.

On the other side there are a few cases where the CIO is from IT and the decision making was completely with an IT focus in isolation. In such cases, there is a tendency to reuse the existing IT Infrastructure, to go for high end technology without paying attention to how it helps business, and to optimize the IT investments in isolation etc. The technology selection is based on factors such as whether the performance is good, whether vendor support is reliable or eases of installation, reuse of existing infrastructure etc. Other factors such as alignment to the business needs and future expansion as well as cost / benefit ration in terms of business outcomes could also be considered.

The CIO with a good understanding of Business as well as technology is the right person who potentially can make great decisions.

Illustration

A popular Pizza Retailer wanted to go for an ERP solution supporting small and medium business. The decision maker who has a business background, made a purchasing decision for a small number of licenses but could not leverage the power of ERP to this organization which has multiple outlets across the country. The licenses went to cold storage and the units continued to manage the business in disconnected model. All data used to be synchronized periodically for reporting and analysis.

Issues of latency in arriving at consolidated data on sales, revenue and other parameters, caused ineffective decision making. It also led to slowing down of business enhancements. The ERP Solution was not tried with the understanding that the licenses were limited to be used by all the outlets. It was also perceived that the users, who keep changing in this kind of business, would have a long learning curve in using ERP.

There was a change in leadership when a CIO with both a business and technical background was hired. The CIO observed the business pattern and realized an effective way of leveraging the existing ERP licenses which were small in number.

He closely observed the business at every location and noticed that the major entry of all transactional data into the system when done once didn’t take more than 1 hour at any location. He also noticed that there was a way of scheduling synchronisation of data without forcing the users to learn a new application (ERP). He opted for a centralized server where the ERP solution was installed and implemented to suit to these requirements. Each outlet used to login at the specified time and synchronized all the transactions. He suggested investing a few more dollars in tailoring a business intelligence solution that generated reports every alternate day as scheduled. The senior management referred to the reports and used them for short and long term decisions.

There was a great improvement in the form of improved data availability and accuracy as well as the ability to make quick decisions.

Lessons learnt

1. The solution always arrives well, when we look at the overall perspective rather than looking at each perspective in isolation.
2. The decision maker with knowledge of both sides (business and IT) can make more effective decisions
3. The end results should be considered in the decision making rather than perceived or symptomatic factors.

Translation of Business requirements in to IT

As we discussed in earlier sections, one of the major gaps between Business and IT is because the requirements defined in the Business perspective are not translated into requirements from an IT Perspective. A business user has complete clarity around the requirements, data required, how to analyze and what to improve. When IT listens and interprets there is a big gap generated. It might be either because the IT team failed to understand, or because business analysts didn’t explain in the way IT could understand.

There were some efforts to translate each of the business level acceptance criteria into one or more IT level acceptance criteria but this was possible only by an expert with the exposure to both sides at equal and high levels. I believe, the mindset was one factor while the lack of understanding the dynamics of the other side was another factor creating this gap. The first one can be addressed at the organization level probably through change management and setting up the metrics and rewarding mechanism aligned to the results. The second factor can be controlled through the combination of change management and some tools.

Thanks to the combined effort by vendors and loyal customers there have been tools developed that help the alignment of business and IT. There are some tools developed where the business analysts can write the business requirements by themselves in the tools without much technical expertise. For instance there are many business intelligence tools which support the definition of business rules in the spread sheet kind of interface which is very native for the business users (The business users define all the rules in such sheets using additional features offering usage of operators like +,-,Between etc and set the business rules).

Similarly BPM tools provide the interface to the business analysts to define the business process in all aspects such as the sequence of tasks executed, who executes (Role/ person or an IT Application/web service etc), how executed (through IT application or Web Service with and without response etc), the data is used as inputs and outputs from each task, and what is the end service provided from the process etc.

The BPM tools have the ability to translate such process definitions in to executable IT blueprints from which IT can start fine tuning. There are also features which makes sure what is defined and translated into an IT Process is locked and can’t be changed. Any changes are supported only through a workflow based change management mechanism.

Illustration

I went to support the “TO BE” Process definitions for a Metal manufacturing company in the Middle East and had some specific learning. The IT head, after experience gained on a vendor organized seminar, wanted the Process definitions to be developed and published for the benefit of the entire organization. The team identified for making this happen was a core IT team.

The tool was quite good as business analysts could easily use it like VISIO or a similar process defining tool but with many other features to define the entire process definition in terms of:

•  Activities

•  Roles and Organization that is responsible at various levels for each activity

•  IT systems that might be doing some automations

•  Data that might be used at various activities etc.

In other words the entire process definition that might be defined in pages of Word document could be easily depicted with all the information in the form of a few process definitions in the tool. The tool also helped convert these definitions into a form that IT understands and takes forward to develop and implement the solution. While I was fascinated by the tool and the expected results, some of my observations inferred that there were still other factors which could contribute to the success.

The Core team which consisted of all members from IT didn’t understand the intention of the IT head who ordered them to take up this initiative as a priority. The team was very busy with important activities relating to the ERP implementation and never realized this was also an important initiative. The team was fine to work on Word documents for process definitions but didn’t realise that there is a difference in doing the same in this BPM tool.

Even after I insisted on the participation of the Business users in my activities, there was regular resistance from the IT team stating that if they understand leveraging this tool, than the business users cannot understand how to use it. I tried to explain them that in their busy schedule they could focus on another area where their presence was crucial. The business users are the ones who must do the process definitions. Somehow it didn’t occur until I involved the CIO to make it happen.

The team didn’t understand the essence of BPM, and instead of attempting to refined definitions they tried to define the exact definitions of their legacy system. The business users who had a fair understanding could have definitely done the job better as it was less likely for them to get influenced by Legacy application. As business users were kept in the dark for most of the duration, and the success was delayed.

Lesson learnt:

•  The effective use of new tools with a direct relation between requirements in a business perspective mapped to an IT perspective, coupled with the positive approach by IT and business is the key to successful alignment.

•  There is a human element involved in the success of any approach irrespective of how powerful the tools and technology and or the solution may be.

•  Change management is the key to tune the IT and business work together for achieving common goals

Conclusions

The Business and IT alignment in a true sense depends mainly on a positive mindsets from both sides. As well, usage of effective tools that support the requirements definition of business and IT perspectives by the right roles without the need of knowing the other side, are available in the market.

The success also lies with the right moderator – preferably in influential position like a CIO – with a good understanding of the dynamics on both the Business and IT side.

The shift to a process centric focus from function centric focus with result linked metrics make the alignment more feasible and effective. In other words the metrics needed to be commonly shared by both stakeholders with a focus on the overall process and end result instead of restricting to Kitchen metrics within one isolated function.

Author

Raja Mohan Ivaturi is an Engineering Graduate from Andhra University with 20 years of experience that included 7 years in Power Plant maintenance, and 13 years in ERP Implementation, Consulting, Practice Management and Development. He worked with Multi-National companies like Nova soft Information technology, Baan and Oracle Corporation. In this process, he has exposure of working under multiple cultures in countries such as US, Canada, UK, Ireland, Netherlands, UAE and Qatar.

He is currently Managing Off-shore Delivery for multiple projects of a prestigious customer in Mahindra Satyam. He was certified PMP in the year 2003 and holds other certifications such as Six Sigma Black Belt and Certified Global Business Leader by Harvard University, U21 global and SSL.

Copyright Project Perfect