One of the challenges facing IT is that it is far more thought of for the “T” of technology than for the “I” of information.
Getting into the information game is a key challenge that will differentiate the ordinary from the value-adding IT group in the next few years.
So does this mean Back to the “Information Centre”?
In the 1980s, when PCs were new additions to the office and when the shift to transaction processing made organizations aware that analysing the transaction data might lead to opportunities, many IT groups contained an organizational unit known as the Information Centre.
This department’s raison d’être was to help business users get the analysis done, or get a report on certain elements of data.
The practitioners in the information centre, at first, simply were masters of “where to find it”; in short order, they began to build analyses for people.
Often, this group was divided into PC support, and the nucleus of those who built executive information systems in the late 1980s. The business, in turn, started hiring people who could do this work — the nucleus of business-area based business analysts.
In the intervening twenty years it’s been assumed that putting a PC on someone’s desk gave the person all the tools they needed to do whatever analyses they required.
Unfortunately, this has proven wrong — as the success of business intelligence products (Cognos, Business Objects, Hyperion, etc.) has shown: most organizations now own one of these.
Alas, using these well remains elusive for many, and the problem of making information out of data remains generally unsolved, despite expenditures in the tens of millions by most firms.
Today’s latest spin on this wheel is the concept of “big data”. Yes, “big data” and big lightly-structured datasets have their place.
They still are unlikely to create much information — and those expected to use them still will not be very good at working with them.
Enter the “Business Intelligence Competency Centre” — the notion of a group to help you with business intelligence (BI), performance management (PM), business process management (BPM) and big data tools.
Once these tools arrive, a group to help people use it — a BICC — is seldom far behind. Still, even with reorganization of the data in a data warehouse, and with the available tools, it is often still difficult to get the results from these tools that the business user wants.
The reason things remain difficult is that only a very few organizations have a solid information architecture.
Most aren’t even close to a master data model (MDM), despite purchasing and using MDM enforcers such as enterprise resource planning (ERP) packages.
The multiple definitions of, and occurrences of, suppliers, customers and the like mean that the business user remains at a loss.
So, too, the challenge of determining what ought to be analysed. Anyone who’s been stumped at the challenge of setting up analyses in Excel using pivot tables and statistical derivations (both are tools in this common piece of software) knows what I’m getting at!
So, re-enter Actual Help.
Fortunately change is in the wing, with CIOs who want to make the transition from “technology” to “information”. I’m seeing investments in groups of people able and available to help business colleagues get what they need, often doing the work of getting it for them.
Many of these are a form of business analyst (more on that in a moment); their knowledge of the user’s environment and needs helps make them more effective than the old Information Centre personnel often used to be.
This parallels other transformations in IT:
- help desks that are offering more than quick problem resolution or trouble ticket opening and referral of the problem;
- assistance in the business area with formulating their annual plan from the relationship managers;
- integrating outside resources (software as a service, platform as a service, etc.);
- integrating the social realm into the company’s systems.
It represents the change from a group fundamentally about building and running applications to one that offers services (one of which is “build an application” and another of which is “run it”).
The New Business Analyst
A trend that has emerged in the past few years is the combination of the business analyst (drawn from the business) and the senior analyst in development (drawn from the IT organization), who, with a solutions architect, are responsible for the direction a business project takes as an IT solution.
What I see, however, is the emergence of a class of people who aren’t part of IT — and have no intention of being considered as “IT people” — who are in some ways even more essential to the IT processes around solution provisioning than the subject-matter experts held onto by IT in the development organization.
First, let’s be clear about the type of business analyst we’re talking about here, for this is one of those job titles that is used for a variety of different jobs.
I find “business analysts” who:
- Act as consultants to the business and help them turn ideas into projects, build solid business cases for them, and figure out what the requirements ought to be to get the job done. They also are found doing process definition work in some organizations.
- Act as “representatives” of the business to IT, typically around defending work practices and defining what modifications will be required to packaged solutions to make them “acceptable”. (I do not consider this analysis work, despite the title.)
- Participate as part of the user test team, leading to deployment. (I do not consider this analysis, but do consider it a useful contribution.)
- Act as the person someone in the business goes to go get some data analysis done, or a report generated. (I also don’t think of this as business analysis — but the business does, in many cases.)
One role that ought to exist, but seldom does, is a deployment specialist, someone who can help with adoption issues in the workplace and find ways to simplify what has been delivered to improve productivity.
Alas, most solutions as delivered are severely over-specified, costing productivity, increasing training needs and generally not serving well, despite encompassing all the requirements given.
As consultants to the business, it is unsurprising that most of the practitioners (business analysts) doing this work do not want to be part of IT.
From their point of view, the work they do is a step up from the work their counterparts in IT do: it contains more of a financial, customer and process focus. To be “part of IT” is to have other IT jobs as a logical career path, instead of to business leadership.
The other types of “business analyst” we’ve found in the fieldwork we’ve done, on the other hand, often could just as easily be in the IT organization — although the resistance to making that move is just as strong as for the consultant types.
What this reflects is the age-old issue in corporations, where the business seldom wants someone to do a tour of duty in IT and then return. A bias, true, but one that must be worked at to overcome, not just ignored.
A CIO may, in their management role, be responsible for only those formally “in IT”. In their leadership role, all of these are part of your domain.
To get into the Information world, you’ll need all of them on side.