The C-suite needs to understand IT

Consider companies such as Google, e-Bay, Amazon.com. What if they did not have top level decision makers (the C-suite – CEO, COO, CFO) with an intimate knowledge of information technology? The answer is simple: these companies would not even exist. Their business IS information technology.

This indicates that there are enormous efficiencies and new competitive services and products to be wrung out of most organizations, if only management got IT. So it should be clear that the C-suite needs to understand IT as innately as they do the balance sheet, marketing and sales and inventory management.

However, the reality is that there is a huge lack of understanding represents a crisis in leadership, whereby decision makers have ceded responsibility of a crucially important aspect of their business to a non-business group. The C-suite without understanding of IT have given up a lot of strategic control.

One of the areas that C-suite executives should have knowledge is related to business intelligence, the collection and use of organizational data to refine organizational efficiency and gain competitive advantage.  Nearly business will have some means of recording the interactions between the organization and its clients in the delivery of products and services. Understanding these interactions is a critical, if not the key, aspect of operating the business, getting competitive advantage, finding efficiencies to cut costs, improve service delivery, focus on highest margin clients or activities, etc. All of this information has to be stored in a database, entered, used, manipulated, reported on by applications and reports.

However, you will be hard pressed to find executives who really get these technical issues.  Instead you will find most executives relegating the responsibilities to specialized technical parts of the organization.  This lack of informed leadership leaves many  organizations with siloed business process, applications and data sources, disjointed, and not tightly bound to strategy or consistent throughout the organization.

Given the enormous efficiencies and competitive advantages that could be gained, it is inconceivable that top level decision makers often do not have even a cursory knowledge of the technology required to do all of this. They should. It is a core aspect of their business, key to literally all aspects of the business.

How has this become such a huge challenge? Are non-technical executives embarrassed or shy to make their ignorance of IT known? Is no one challenging them to gain these skills?  Do they just not understand how beneficial this knowledge could be?

Clay tablets to modern information technology

Here is a scene for you to imagine.

Imagine it is 1000 BC and a bunch of Sumerians are sitting around a table making impressions on clay tablets.  Others are taking the stamped tablets and putting them into ovens.  These are scribes in the hire of a merchant sitting across the table from them.  He is reciting the day’s sales to the scribes.  The scribes are tallying up the sales of sheep and bushels of wheat.

Lets jump forward 2000 years in time.  Now we are in medieval England.  A king has a bunch of scribes that are helping to account for the annual taxation of his subjects. They are doing more or less the same thing as the scribes 2000 years ago except now they are using crude paper or tanned hides.

Remember the scene at the beginning of the Monty Python film, “The Meaning of Life” where two buildings collide and armies of accountants fend off the pirates?  Now there are armies of scribes and the clay tablets have become paper ledgers and filing cabinets.

You know where I am going with this.  The methods of tabulating and communicating information resulting from business activities is age old, and has remained unchanged for a very long time.

However, in recent times, the method of tabulating and communicating information has begun to change drastically.  The scribe and the tablet bakers have largely been supplanted by information technology. Your data may be recorded on paper or clay, or a hard drive.  The tools change but the purpose remains the same.

That is all that IT is doing for you.

The clay table or ledger in paper form was walked from one office to the next.  Ledgers were passed along from one scribe to the other.  Today, the tools we use are spreadsheets, electronic documents, emails, databases in applications, and networks and the internet to transmit them to others and store the data in a central location. For the moment let’s ignore that a lot, too much, of business today continues to use paper and manual processes.  That’s another topic of discussion worth having though.

However, the information technology we use today is so complex, and often too arcane or specialized for most people to understand, let alone use.  So most of the people creating, implementing and supporting information technologies are not directly involved with the business.  It would be like having clay tablets or pencils that used invisible ink, or that the scribes wouldn’t know how, or even be interested in how to record the numbers of sheep, but instead made clay tablets that met their needs first, and conformed to their arcane sensibilities.

While business has recorded and communicated its activities since almost the dawn of civilization, the introduction of information technology reset the clock.    Thousands of years of pervasive experience with relatively unchanging set of tools and processes has been completely replaced over the past 20 years or so.  We are almost literally starting from scratch.

This presents an enormous challenge.  For most of human history most humans knew how to communicate information about organized activities, it wasn’t hard to learn to use a pencil or make impressions in clay, and it would be relatively easy to manage someone else doing these activities to achieve desired goals and objectives.  However, today, IT is a black box.  This interchangeability of function would be like unthinkable today.  Business users cannot swap place with technology workers.

The resolution is simple:  IT workers must learn what the business does, and business users must learn what IT does.

IT black box – must extend into business domain

The domains of knowledge and capability of business and IT are not synchronous in terms of understanding and contributing to the business goals and strategies. In fact they are rather mutually exclusive.

IT is very poorly defined. Inside most organizations, IT is often poorly understood in terms of what it does, what it can deliver, in support of the business’ goals and strategies.

The IT ‘black box’ (as seen from the business side) is full of technical skills, experience and knowledge and rarely has elements that extend into the business domain.  In contast, the business ‘white box’ elements do go into the IT domain generally in roles of business analysts and project managers who work on IT projects.  It is true that there are IT relationship managers that extend into the business domain but they are more focused on IT interests.

This is clearly a communication issue. People in IT need to be able to articulate their potential contributions to their business counterparts. There is too much jargon and technical detail that leaks into this communication. That is where the obfuscation fog rolls in. Also, there is a special kind of nuance and perception required for understanding business strategy that requires focusing on the ‘big picture’ which is something IT doesn’t do.

It is crucially important that the IT black box be bust wide open, and that IT extend its knowledge into the business domain.  Cross-training, measuring IT contributions in terms of business success, Agile development, are some of the ways to do this.  Critically, business and IT management must recognize this and encourage the extension of IT into the business domain.

So what can IT workers do to break open the black box? Get away from the computer, go meet the people who use your tools. Look over the their shoulders. Find out what problems or challenges the face. Learn about the business’ goals and objectives. Try to think business, try to measure your value in business terms.

Try to do your best to explain to non-technical people in your organization what you do as an IT person.

Try to envision how everything you do as an IT person can directly contribute to the success of the goals and activities of the business. Try to to describe the value of what you are doing and the results of your activities, and if possible try to determine how you and the business can measure the results.

If you can’t identify what your contribution is, stop what you are doing, and start asking questions.

Connecting strategy to IT

IT is very poorly defined. Inside most organizations, IT is often poorly understood in terms of what it does, what it can deliver, in support of the business’ goals and strategies.

This Forrester Research article points out that it is connection of business strategy to how IT can help that is the issue.

This is clearly a communication issue. People in IT need to be able to articulate their potential contributions to their business counterparts. There is too much jargon and technical detail that leaks into this communication. That is where the obfuscation fog rolls in. Also, there is a special kind of nuance and perception required for understanding business strategy that requires focusing on the ‘big picture’ which is something IT workers often never do.

There is a real irony here that some of the strategic benefits are found in details. For example, a strategy may be to define products in a unified manner across an organization. The IT contribution is to get very detailed in tables and application code to ensure that product references align with strategy.

This highlights how IT could really increase their contribution by relating what they do and how the bits and pieces of IT can help meet strategic goals.

Of course, the business must also come half way. Strategic communications could be better phrased or aligned in IT terms, to focus on how they will be delivered, which is often via IT, eg by updating application pick lists (updating product types).

Business-IT alignment is one of those persistent ‘Top 3′ CIO issues. It has been this way just about as long as I’ve been in IT. You would think this has been solved by now. After all, you put in business-driven IT governance, relationship managers, and some really nice dashboard, and you’ve covered about 90% of the advice out there. I’m going to suggest that business-IT alignment is being held hostage by complexity. Not technology complexity, since business leaders seem to be coming to terms with that. And not the mind-numbing spaghetti charts that show how complex our application and infrastructure landscapes are. The complexity I’m referring to lies between their goals and the ‘stuff’ IT delivers. They don’t see the connection.

Forrester – A Different Kind of Complexity Holds Business-IT Alignment Hostage

Stop dreaming, you need IT!

There is a lot of talk about how the cloud will relieve any organization from having an IT department.  But it is just not possible to do anything related to IT without IT. Full stop. Your organization needs someone who has  information technology skills and experience.

That same, tired storyline is playing out once again—as it has with other enterprise software apps in the past, such as with SaaS CRM and salesforce automation. This time around it’s business intelligence.

The tale goes something like this: Business meets recession; CEO cuts IT spending. But users want new data insights! But IT can’t spend resources! Then business meets SaaS company, users like functionality, and LoB manager likes price. Sold! IT stays in the dark.

 

People without IT skills may be able to perform limited tasks using the cloud services, very limited. There are many concepts that are technical in domain but practical in application to business needs. Most applications will need to be customized or at a minimum setup for your organization.  It is rare that any business or organization can find a perfect fit for its operations and business processes in an off-the-shelf application.

So, stop dreaming! You will always need IT people.  You may lighten your hardware and software ownership and support burdens by using the cloud.  But do not let go of your IT people just yet. Engage your IT people in your business. Business people, start learning about IT. Share desks, do some shoulder surfing. Cross-train. And most importantly, management needs to take the lead!

Stating the obvious: IT investment can boost business performance

A recent CIO.com article  Does this Sybase Study Matter? highlights the obvious:  “IT investments can boost its overall business performance”.

That yet another study and subsequent discussion reveal this ‘startling’ observation can be viewed as either frustratingly maddening or delightedly confirmatory.

Integration is a fundamental business issue

Another CIO.com article Taming the ERP Integration Beast: A Work in Progress presents some of the technical complexity that challenges organizations to get all of their various applications to interact with each other.

The key challenge is that, as a rule, most applications have proprietary processes of working with data and storage of data.  Consider the following simple example.

Application #1 only allows you to view cars by their model name.  It has no data field for a model’s colour.  If a new car is added to the database using this application, it can only be categorized by its model name, not by its colour.

Application #2 only allows you to view cars by their colour.  It has no data field for a model’s name.  If a new car is added to the database using this application, it can only be categorized by its colour , not by its model name.

If you now want to have both Application #1 and #2 work with each other seamlessly (or as the article notes “integrate”), you have a challenge.  You need a way to translate between model name and colour.   The obvious solution to this challenge is to make sure that both Application #1 and #2 have the ability to record a model’s name AND colour.

However, imagine that instead of the simple example above, with just one categorization difference between two applications, you have many categorization differences between many applications.  The variety of differences can range from subtle to stark.  This disharmony arises for a number of reasons including:

• Marketing thinks of a product or service differently than does the engineering department
• Applications bought “off the shelf” simply do not have the required fields to categorize a product or service as specifically as required
• The business has changed its categorization, adding new categorizations or revising existing categorizations
• IT workers create IT-centric categorizations in an application code or database that emerge into the business side via the application user interface or reporting

Given this disharmony it is not surprising that an entire industry has developed to address this. It is one of business’ biggest challenges surrounding its use of information technology.

As most IT shops know all too well, “integration challenges are often the foremost obstacle to getting the full value from packaged ERP solutions,” as the Forrester report notes. If CIOs can actually overcome today’s integration challenges, just think how easy it’ll be demonstrate IT’s value and align IT’s efforts with the business once and for all.

But going back to the simple example of a car colour and model, the obvious solution was to make sure that both Application #1 and #2 have the ability to record a model’s name AND colour.  If we consider the reasons disharmony arises, is it possible that an organization could nip a lot of this disharmony in the bud by mandating that all applications “speak the same language”?

Before answering, consider that this disharmony is not really an IT issue but one of organizational goals and strategies, relating to how an organization categorizes its products, services, employees, customers, partners and activities.

If everyone in an organization was aware of the strategic and practical implications of categorizing the organization’s products, services, employees, customers, partners and activities, a lot of disharmony would vanish – and integration of IT process and data would be much easier.

It could be mandated that ANY categorization of a product be done ONLY in a way that aligns with strategic goals.  This would include references to that product internally, in marketing material, in supply chain procurement, etc.  Too often, and to the productive detriment of an organization’s bottom line, there are numerous ways of referring to its product, services, activities, employee or customer groupings, etc.  The inherent inefficiencies are obvious.

It is worth noting that these fundamental organizational issues are highlighted by IT.  Information technology, specifically applications, databases and reporting are very rigorous in that they require specific categorization of products, services, people and activities in order to properly group, sum, and perform operations.  Before IT became a core business tool,  categorization of products, services, people and activities didn’t have to be as rigorous.  Grouping, summing and performing operations were manual processes, and people could ‘fudge’ the data to make it fit.  The topic of this article, ‘integration’, is essentially an automating this formally manual process.  It is also worth noting that it is likely IT workers doing the ‘fudging’ now whereas in the past it was done by business workers, and that business workers can probably make informed judgments about fudging the data and process than can IT workers!

Put in this light, it is clear that the challenges discussed in this article arise from much more fundamental organizational issues, and that addressing these challenges as an IT issue is not sufficient.   To properly address integration challenges, the direction needs to come from the business side, and specifically from the leadership of the organization.

Familiarity can make the complex routine: Integrate IT workers into the business

A CIO.com article A Different Kind of Complexity Holds Business-IT Alignment Hostage touches on how the ‘complexity’ of an organization’s goals and strategies presents a big challenge its IT team.

The complexity I’m referring to lies between their goals and the ‘stuff’ IT delivers. They don’t see the connection.

One of the most important issues that this article highlights is the lack of communication within an organization, and specifically the fact that IT is often left out of loop when it comes to communicating business goals and strategies.

One of the tools that this article suggests would be useful in communicating with IT are Business Capability Maps.

Business architecture helps IT-business alignment by helping execs clarify goals, strategies and the needed changes in the business operating model, and by helping IT understand and deliver to these goals, strategies and needed changes. There are several approaches to doing this – we believe that Business Capability Maps [can help].

Indeed, Business Capability Maps are a useful tool.

Forrester defines a business capability map as “A model of the firm associating the business capabilities, processes, and functions required for business success with the IT resource that enables them.“ (Capability Maps Anchor Business Complexity, Bobby Cameron, Forrester, November 16, 2007) link

However, not to dismiss Business Capability Maps, but there are still other more fundamental reasons for the lack of effective communication and understanding between the business and its IT group that need to be addressed first.

IT must first be a willing to communicate.  I think  IT often keeps itself out of that loop.  This happens simply by default.  IT is a ‘black box’, its technical aspects ward off understanding by non-IT parts of organization.   This keeps it separate from the organization in many respects. IT literally speaks a different language.

In addition, many IT groups purposefully keep themselves segregated from the organization at large for a variety of reasons.  Lack of time for engagement is the big culprit here, combined with lack of ability or sanction to take time out to sit with business workers and really understand their requirements.  In order to deliver on often narrowly defined scope of work, IT must avoid understanding too much because requirements could increase or worse business expectations could be raised too high.

In the extreme, I have seen IT groups that do not even attend social events held by organization because they fear having people use the social contact as a shortcut past the help desk to help resolve some desktop issue or past the business analyst to slip in a few extra requirements on the new build.

Which brings us to one of the most critical impediments for business-IT communication.  Most business-IT interaction happens at the help desk or through the key-hole view of the business via a narrowly defined project.  Often this is filtered through the perspective of an IT business analyst’s interaction with a handful of business side project members who themselves are not cognizant of wider business goals and strategies.

The complexity described by this article in an organizational issue.  Everyone, from both business and IT, needs to understand an organization’s goals and strategies and tools such as capability maps are important means of doing this.  However, when it comes down to it, the only way for people to understand and communicate is to have some kind of meaningful participatory interaction.

IT workers and business workers need to interact on a practical level.  The only way for this to happen is to literally have both sit side by side and learn practical aspects of the other’s routines.  Developers and analysts need to be given significant time to do business work alongside business workers as a means of understanding requirements.  No more key-hole views or filtered perspectives.

It can practically be guaranteed that application developers, database analysts and reporting analysts will have ‘epiphanies’ as they sit with business workers and actually use the applications and reporting (that they had a hand in developing) and participate in business process.  Of course, these epiphanies can only make their way back into the development, support and implementation process if the organization allows it to happen eg enable a process to record these epiphanies and time and money to enable them to be integrated into IT.

Complexity is often something that exists in the eye of the unengaged beholder, at least in terms of understanding and taking action.  Life is fraught with complexity but familiarity has a way of making the complex routine.

“BI” is often just plain old reporting

This Globe and Mail article Data dive reveals an ocean of trends provides examples of what are purported to be business intelligence (BI) and “analytics” but which I would consider to be just plain old reporting.

Consider the following example:

Say you offer 10 products, and you notice that sales of one of them are way down. By clicking on that line in the report, BI software lets you look at lower-level information – model or colour – and find that a certain item is not selling. Another click may show you that one salesperson’s volume, or lack thereof, is the problem, or it may indicate that you didn’t have sufficient inventory and couldn’t sell more.

You don’t need “BI software” to do the type of reporting described in the example above.  Can anyone honestly believe that no one reviewed records of sales prior to the introduction of so-called “BI software”?

A company could be manual tallying sales using paper and pencil and is surprisingly still the way many small businesses operate today.

More likely though many companies record their sales in something like an Excel spreadsheet.  They may use some bespoke or off-the-shelf application to record sales.  In both cases the data is being recorded in a structured format which can be easily accessed to retrieve the sales data for review and reporting.   Often this is a feature of the application in which the data was recorded or it would be relatively simple to export the application’s data, or directly link to the data, and do the reporting using Excel, Access, SAS, Filemaker or any number of database,  query and reporting tools.

“BI software” does more or less the same thing as the relatively simple methods described above.  Granted, some “BI software” does much more such as helping the user relate different data sources or properly format data but in order to really help a user, the user needs to have some level of awareness of what the software is doing in order to use it.  The key message here is that “BI” is not about the software, or any other tool, that is being used.  “BI” is really a process and methodology in which data is organized and reviewed in a way that delivers information about the activity that the data comes from.

Viewed from this perspective, “BI” has been conducted for literally 1000′s of years.  Some Mesopotamian trader in 3000 BC would have conducted a very similar review of sales data and he sure didn’t have “BI software” though he most surely would’ve used the same analytical process to review his business’ activities.

Calling this type of reporting “BI” is often misleading.  There is a degree of marketing hype that intimates that the software will minimize the need for the user to have a basic understanding of structuring, relating and formatting the data.  Marketing of “BI” and “analytical” software and related services make the promise that if you simply buy the software and services, you will magically be able to transform your data into accurate and useful information.

This likely leads to many instances where companies who are jumping on the “BI” and “analytical” software and related services band wagon, would be much be served by simply implementing basic systematic and structured data collection and reporting.

Now all of that said, “BI” and “analytical” software sell related services are real and do have an important role.  Some of the other examples in this article more properly describe “BI” such as the following:

Mike Der, MAB’s manager of business intelligence systems, says the company purchases raw data on sales of its products and those of its competitors, sold both at retail and in the hospitality space, from places such as the Liquor Control Board of Ontario. It imports the information into its data warehouse and uses IBM Cognos tools to analyze what types of beverages are purchased, and when and where they are purchased, often down to the individual store level.

This example describes a higher level of data collection and reporting and purpose than simple operational and management reporting.  Still this could just be called more complex and focused operational and management reporting with a broadened scope to relate the company’s data to that of its industry peers.

However, I would call this work “BI” and more realistically, a company might be better served buying “BI software” to conduct this work.  “BI software” is developed to get data from various related but different sources and allow the user to match up similar things so that comparisons can be made for example matching up your company’s sales of beer to another company’s sales of beer.  It may be that your competitor tallies sales by month but your company tallies sales by week, or you may tally by province, but your competitor tallies by city.  “BI software” makes it easy for you to match up this different types of grouping of data.

“BI software” also provides built-in grouping, counting, statistical comparisons and analysis of the data in addition to built-in ability to drill-down into data to see greater detail.  Usually you get nice table and charting creation functions too.

As the article notes ..

Regardless of the solution you choose, Mr. Der advises, take baby steps. Know where the gaps exist in your data and look for a solution to provide insight into the information you have. Start with reporting, then grow into the other functions. “Then you’ll have confidence,” he says. “You’ll understand how the tool creates value.”

.. if your company is considering jumping on the “BI” and “analytical” software and related services band wagon, you would be best served asking whether you already have a systematic and structured means of collecting data and reporting on that data!

CVS gets it right: No IT projects, just business projects with IT components

A very refreshing CIO.com interview with CVS Caremark CIO Stuart McGuigan CVS IT Chief on the Remedy for Business-IT Alignment highlights how business and IT should work together, and specifically how the CEO and senior management’s perspective of what IT should be …  (hint: IT is business!)

“Technology starts with really good business thinking”

Likely there are very few people who would disagree with the above statement but in practice this is not how most technology gets integrated into a company.  Very often, technology hijacks the business agenda.   McGuigan has a useful suggestion for business people to get involved and keep the agenda on good business thinking.

“[T]here’s the perception that [business partners] have to understand IT at some technical or mechanical level before they can have the conversation.”  However, McGuigan says: “Don’t get into the technology. Just be able to get a clear answer to the question: What will I be able to do after I build the system that I can’t do today?”

It is critical that this message about how to integrate technology come from the very top of the organization.  CVS’s successful use of  information technology is directly related to their CEO’s understanding of how to integrate it into the business and clearly communicates this to all senior management.

“In my first meeting on the BPC [business planning council], our CEO Tom Ryan said, and I remember this very clearly: Welcome and we expect you to contribute to the dialogue here and not just on technology questions.”

“So it’s not just encouraged, but our CEO insists that business, technology and operations all participate in that. And it is that mix, which is focused on key business strategies, that produces excellent operations and technology. You can’t do them separately.”

This top-down communication of how to integrate IT into the business is very different from the ‘alignment of IT and business’ school of thought.

“[IT governance structure] is actually business governance with IT as a component. It’s about recognizing that there’s no such thing as technology projects; they are all business projects with technology components. ”

“McGuigan: It is one of the things that has always amazed me over the years, in looking at CIO surveys: That IT-business alignment or strategy pops up in [those surveys] as the top one or two issue. Because if you don’t know how what you’re doing in IT is going to benefit the business, if you can’t even verbalize the connection in the investment in IT and a benefit to the business, then why are you doing it at all? “

At a practical level, McGuigan offers more detailed advice on how to manage all IT activity in a way that keeps a regular focus on business thinking rather than alignment.

“I consider a project that allows us to make better use of our IT assets, to be more efficient, reduce cycle time for deploying capabilities, make better use of capacity—even though it’s done entirely within IT—that’s a business project.”

McGuigan highlights that often IT has very little understanding of business needs and the critical requirement that IT know what the business does.

“For IT, you also need to be at least conversant with every area of the business you support, which can be many. So that is a challenge, which is one of the most exciting parts of job: You have to keep up with every aspect of the business and every area of technology, so that you can participate in those conversations intelligently.”

The challenge for an organization is how IT can become conversant with every area of the business.  I believe that the only way is through a regular program of secondment where IT workers get swapped into various business roles for a significant percent of their working hours.

The most important message from this interview is McGuigan’s dismissal of the discussion of ‘alignment’ of IT and business as “been there, done that.”  Instead he states,

“It’s about recognizing that there’s no such thing as technology projects. They are all business projects with technology components.”

So much productivity and value could be unlocked if all businesses paid attention to these simple two sentence!