PLAGIARISM FREE "A" WORK

Chapter 7 Structuring of a Business Analytics Competency Center In Chapter 6, we looked at the business's creation of source data and thus completed our

presentation of the business analytics (BA) model from Chapter 1. In this chapter, we discuss

how the activities of the BA model can be carried out via a BA competency center (BACC).

The trend today is that more and more analytical competence centers are created. They work

independently from or control the Business Intelligence division, which in turn typically only

works with maintaining the data warehouse and provisioning user front ends. As a result, the big

shift is that it is the analytical department which leads the way, not the data warehouse teams.

Another concern today is the lack of skilled analysts. A quote from McKinsey's Big Data Report from June 2011 claims: “The United States alone faces a shortage of 140,000 to 190,000 people with deep analytical skills, as well as 1.5 million managers and analysts to analyze big

data and make decisions based on their findings.”

The answers to this lack of skilled analysts have come from three directions: more advanced and

easy‐to‐use self‐service systems, outsourcing of the analytical function, and development of the

analytical factories.

We already have covered the new trends within self‐service systems in Chapter 5, where market

leading companies today produce systems that a user can simply talk to or write to in natural

language. These self‐service systems also give the user access to analytical tools like decision

trees, which pushes the borders for the kinds of decision support that non‐analysts can create for

themselves today. In‐memory technology also has improved the user experience for non‐analysts

drastically, as market leading systems now ensure that the users don't have to wait for the system

to do calculations, since possible combinations already have been pre‐estimated overnight; these

combinations are stored in memory and can be delivered in a split second.

Hiring analysts in countries such as the Philippines and, in particular, India is another way to

gain access to more analysts. This is a counter‐trend to traditional outsourcing, in which low‐

skilled jobs were moved away from salary‐heavy areas around the globe; this time around, it is

about insourcing specialist skills. To insource new organizations around the world into our local

operating model is not an easy task. Some literature on the subject is, however, beginning to pop

up. Our suggested way of how to make successful cultural integration programs is described in

the book International Leadership: How To Make Cultural Integration Programs, which is based on our experience with establishing BACCs in countries like India and the Philippines.

The analytical factory, which will be presented during the last paragraph of this chapter, is

another way to cope with the undersupply of advanced analysts. In its simplest form, it has to do

with creating some very strong processes for analytical processes and relying on less‐advanced

analysts to manage the individual procedures in the process. The advantage of this approach is

that the production time of, for example, an analytical process at a global telecom operator was

reduced from months to hours. Similarly, in a bank for whom we consulted, the analytical

process—including business sign off and model implementation into real time omnichannel

systems—was taken from impossible to around eight working hours.

WHAT IS A BUSINESS ANALYTICS COMPETENCY CENTER?

A BACC is a forum that includes analytical and business competencies as well as IT

competencies. This combination of competencies ensures that BA has the necessary impact on

the organization. The establishment of a BACC is based on experiences that show barriers in

relation to competencies and organizational structure to be the most limiting factor when it

comes to the successful creation and execution of BA. The creation of a BACC is the

establishment of an organizational entity, which includes different competencies across the

organization and which becomes a problem‐solving forum. Its purpose is to maximize the

revenue flow from business analytics initiatives and to make BA a business process, rather than

an IT process. In other words, a BACC works to ensure that the business's needs drive all

technical initiatives, thereby making sure that the business does not get a data warehouse with a

life of its own, independent of the needs of the business. Similarly, a BACC works to ensure that

the business realizes the potential benefits of BA and that the necessary analytical competencies

are present and accessible. That, by the way, is entirely in line with our BA model from Chapter

1.

WHY SET UP A BUSINESS ANALYTICS COMPETENCY CENTER?

Typically, companies that create a BACC want the BA function to have more impact. Often,

there are quite a few analysts in large organizations, but they are spread out in different

departments and divisions and have no common forum. This means that problems that the

individual analyst has extraordinary scope for solving will only be formulated locally in his or

her department, depending on the analyst's ability to promote the ideas and depending on

whether these ideas are compatible with local strategies and management preferences.

If, however, we gather analysts and the closest related competencies—which we will look at in

the following section—into one single organizational entity, this entity might now have a voice

so strong it can be heard throughout the organization. This can be done in either of two ways.

The first is by giving the manager of the BACC a formal influence on and access to management

forums, where both potential and existing problems in connection with BA can be addressed in a

strategic context. The second way a BACC will be able to create synergies is at the functional

level. An analyst with data mining competencies placed in marketing will be able to see and

promote the potential of data mining methodology in human resources (HR) via dialogue with

the analyst from HR. In other words, the purpose of a BACC is to give the BA function the

critical mass to be heard at a strategic level as well as to create synergies at an operational level.

One element that we also will address in this chapter for the first time is knowledge

management, so that we now will deal with three Ls: lead, lag, and learning information.

The overall argument for the establishment of a BACC is that it is a precondition for an efficient

linking of the business's strategy with a BA strategy. If analysts are spread around different

departments without a common forum, the IT/data warehouse section, on the one hand, and the

business, on the other hand, will have very poor chances of establishing an ongoing dialogue. It's

an essential part of the analyst's function to build a bridge between specified business needs and

the data warehouse via an understanding of which methodology and which data, once combined,

can fulfill the needs. If the company does not have an analytical function to link business and IT,

the result of the dialogue will, in all likelihood, become a large number of technical solutions

created without insight into the best method of generating knowledge and information. Since the

rest of the organization will still require decision support, they will then start building

workarounds in order to get access to the data they need. In the worst case, they will stop using

the data warehouse completely or will only use it only as a provider of lag information.

TASKS AND COMPETENCIES

In this section, we take a closer look at which tasks and therefore also which competencies are

required in a BACC. As always, we want to emphasize that competence profiles are not

individuals, but roles. One person may well fulfill several roles. For example, a data miner will

typically be statistically knowledgeable and thereby able to take on two roles or competence

areas. Likewise, an IT‐oriented person may well have business and strategic insight, too.

Similarly, a competence profile could easily require a combination of several employees.

Establishing an Information Wheel

The primary task for a BACC is to deliver the right information and the right knowledge to the

right people at the right time. This is the whole definition of BA used in this book. In other

words, it's a question of keeping the information wheel turning, as shown in Exhibit 7.1. The

information wheel sums up the concepts that were described in Chapters 2 through 6. First we

specify which knowledge and which information the business requires, based on its chosen

strategy. Data is then retrieved and condensed to information and knowledge, which is delivered

to users. In the model, we have introduced the concept of wisdom, which refers to knowledge management, which seeks to create and retain learning over time—in this context, to be activated at a strategic level.

Exhibit 7.1 The Information Wheel: From Demand to Supply of Business Support

Knowledge management is essentially being able to summarize overall learning about how we

establish, improve, maintain, or close down business processes and store them for the use of

others. One common feature across strategies is that they have the tendency of centralizing

company activities to capture and benefit from local skills and make use of these throughout the

organization. It is also not uncommon that a few years later, another decentralization strategy is

presented, with the purpose of releasing the creativity of the organization. Over time, this

strategic heartbeat keeps organizations adapting to new market conditions via decentralizing and

implementing new ideas organization‐wide during the next centralization strategy. It is, however,

a very costly maneuver for an international organization to make strategy changes at this level,

and this is where knowledge management comes in. The purpose of knowledge management is

to have the best of both: a decentralized organization releasing its full creative potential while at

the same time making sure that other decentralized units reuse the good ideas generated.

In the simplest form, this could be done via a follow‐up procedure on all campaigns: A document

is created that describes the campaigns, how they were managed, and what their results were

(lead and lag information). Now a business unit in France can search on how to make a cross‐

selling campaign toward small customers and be given decision support on how that was done in,

say, Ghana, Brazil, and China. Not only might France get knowledge person‐to‐paper, but they

might be able to see who actually executed the campaigns and contact them person‐to‐person.

Suddenly, we have created task‐specific virtual networks that, say, a strategy team could rely on,

as shown in the information wheel in Exhibit 7.1. In smaller organizations, this could mean

making knowledge that is specific to a person public, and making that knowledge sustainable

across generations of employees and jobholders.

As discussed here, we are talking about many information wheels that need to be established and

maintained, typically one per business process that is based on BA information.

Creating Synergies between Information Wheels

The BACC must therefore establish and maintain these information wheels, but at the same time,

we should be clear that the processes illustrated in the information wheel are not necessarily

performed in just one place in the organization; they can easily be performed in several places.

The person responsible for CRM activities wants to generate customer information to monitor

activities. So does the person responsible for sales in connection with the planning and

monitoring of sales activities. The same thing is true in connection with HR, production,

logistics, procurement, and others. In this context, people talk about the occurrence of

information islands or the silo syndrome, which occurs when the different business units create

and maintain their BA systems without any coordination. Not surprisingly, this results in

different terminologies, technology strategies, and procedures across the organization. This leads

to the creation of data redundancy and knowledge‐sharing barriers, resulting in a considerable

amount of uncoordinated tactical BA projects, each delivering limited insight and effect on the

bottom line.

One of the most important tasks of a BACC is therefore to coordinate all these information

wheels in order to create synergy on the data side via a correct combining of data. In addition,

synergies must be created across analysts (knowledge sharing among analysts) as well as on the

IT side. As an example, it has been estimated that software costs could be reduced by

approximately 25 percent if solutions were standardized via fewer platforms, which would also

give the organization a better negotiating position as a major customer with software vendors. A

similar number is mentioned in relation to costs in terms of external consultants and employees,

since a reduced number of technologies means that the organization does not need to have

expertise in as many technologies and can therefore minimize the number of integration projects.

The number can, of course, be formulated positively; we get proportionally more performance

for the money we pay consultants and staff in our IT department.

As illustrated in Exhibit 7.2, a BACC must assume responsibility for the establishment of an

ongoing dialogue between the business and IT to ensure that the chosen information architecture

and the chosen technologies support the information strategy. Information architecture describes the ways in which we move data and information around the organization, while the technologies refers to the software and hardware solutions that will subsequently perform the task. This terminology corresponds perfectly with the definition of BA

used in this book; otherwise the right people won't be getting the right information at the right

time, as part of an automated process. As illustrated in Exhibit 7.2, we first set up our

information architecture. Only then can we formulate the requirements to individual

technological solutions—both individually and combined. We would like to stress that a BACC

does not design information architecture or technology strategies. This is the system owners' job.

A BACC enters into a dialogue with the system owners to ensure that the chosen information

architecture and the chosen systems support the organization's information strategy. If this does

not happen, we find ourselves again in the situation where the scope of the BA function is

determined by technological solutions rather than by the information needs of the business.

Exhibit 7.2 Interrelationships between Information Strategy, Information Architecture, and

Information Technology

Educating Users

It's perfectly possible to have a good technological solution supporting the information strategy

and yet not add value. That's just a question of not using it. If there are no users, there will not be

any improved decision making, and thereby no value creation as a result of the solution. In BA, a

solution is never better than its users. If we want successful implementation of BA solutions, a

rule of thumb is that three elements need to be in place: user friendliness, relevant information,

and general support.

In terms of user friendliness, the system must be inviting, intuitive, and clear. This is best achieved by asking the users themselves for input in relation to design. A simple solution like a

report requires only one or two feedback processes between the BACC and the end users. A

more complicated system that must support many business processes and many users in a

changing business environment requires much more in terms of user interface and flexibility. We

must therefore expect that the system will be developed in an ongoing dialogue with the

business. In other words, we wouldn't start the programming of the different modules until their

design was discussed with and approved by the users.

The relevance of the information is what comes out of the system. The format doesn't matter if the contents of the system are of no value. Here we can refer to another rule of thumb, which is

that information—with the point of departure being the users' perspective—must be available,

accurate, and actionable. If it takes a long time for the user to obtain the required information, the

information cannot be said to be accessible, and users are therefore wasting their time. Similarly,

the information must be precise so that users dare to base their decisions on it. Solutions

obviously need to deliver useful information in relation to the business process they're

supporting.

When implementing new information systems, general support means that users should be trained in using them, if we want them to actually do so. Equally, users must have easy access to

support, which means that if they have questions or suggestions for improvements, they will be

listened to.

If user‐friendliness, relevance of information, and general support do not live up to the users'

needs and expectations, user satisfaction will drop and so will the use of the systems. This

situation is a nonstarter, simply because the solution was not based on the users' needs. We have

created a BA system to assist with a business need, but it doesn't work, because the solution

we've created has failed in one or more of the previous three dimensions.

All this brings us back to the fact that the delivery of BA information is a chain that is only as

strong as its weakest link. If the system is used only half as much as expected, it has lost half its

value. The costs, however, remain the same—plus introducing an increased wariness in relation

to BA solutions.

Prioritizing New Business Analytics Initiatives

The final major role of a BACC is to coordinate and prioritize new BA initiatives. Since we

consider this to be a key issue, we have reserved a separate chapter (Chapter 8) for this subject.

Competencies

A BACC must contain all the tasks already described. Typically, these are divided into three

domains. Exhibit 7.3 shows the three domains, as well as which tasks might lie in each of these

and at their intersections. We've included this exhibit because there is a difference between the

competencies needed in a BACC and the way in which information moves about an

organization, which is described via the information wheel. The information wheel is based on

considerable preparatory work, created, among other things, through the performance of the

tasks described in Exhibit 7.3.

Exhibit 7.3 Competency Areas and Types of Tasks in a BACC

CENTRALIZED OR DECENTRALIZED ORGANIZATION

The establishment of a BACC can be carried out by creating a new, formal organizational entity.

It can be created, too, by establishing it as a virtual organization, as illustrated in Exhibit 7.4. On

the left‐hand side of the exhibit, a BACC is shown as an organizational support function, which

indicates that the BACC is given a strategic role in its work. On the right‐hand side of the

exhibit, a BACC is established as a virtual function. This indicates that the department to a lesser

extent is given a strategic role and to a greater extent has been created as an analytical forum to

facilitate synergies, and that the focus is on strengthening the BA function at an operational

level. This interpretation, however, is not without exceptions. Small or medium businesses, for

example, are more likely to make use of virtual departments or “work teams,” as they are often

called in this context. These work teams will naturally contain members with a strategic focus,

which ensures coordination between BA and strategy. In large organizations, a BACC can easily

be created without involving people with strategic focus, and in these cases, the BACC can

become a purely operational entity.

Exhibit 7.4 BACC as a Formal Organizational Unit or a Virtual Organizational Unit

As previously illustrated, the way in which we establish our BACC is not of vital importance. It's

a question of the organization's ambitions for the BACC. As always, we have to ask ourselves

the key question: What are we trying to achieve with this change? In this case, the answer will be

along the lines of either more strategic focus or simply an increase in performance.

Strategy and Performance

As always, when a new business initiative is launched, we must assess whether it supports the

company's strategy, performance, or both. If it does neither, we should wonder whether we have

lost track of what we are trying to accomplish. Similarly, in connection with the activities of the

BA function, we must ask ourselves whether the aim is to optimize the company's performance,

or whether the aim is to achieve a closer relationship between the company's strategy and the

way in which information is used.

If we focus first on how to improve our performance, the aim is to be more proactive at an

operational level, as illustrated by Exhibit 7.5. A good example of a reactive operational BA

function would be if our procedures are based on users coming to us. They order the information

or knowledge they need, and then we agree on a deadline of, say, three days for delivery. On the

face of it, all seems fine here. But try looking at it from the business's point of view. Let's say

they are in a creative meeting, and at one point they are having discussions where they want to

know how many of their customers in a given region have a consumption of over $400 per

month. They can have their answer, of course; it just takes three days. The next time marketing is

in a creative situation, they are not going to use the BA function to answer questions like that;

they simply do not have the time to wait, unless it's an absolutely vital question. The result is that

the business uses the BA function less because of the long response time. Maybe the business

chooses to use the BA function in only 30 percent of all the cases for which it was expected to be

used when the BA function was established. All of a sudden, we have a situation in which either

the BA function represents a bottleneck or the business completely avoids using it. Business

support and thereby improved decision making is reduced to 30 percent, as is the value creation

based on the data warehouse. We are not getting a return on investment from our data

warehouse.

Exhibit 7.5 Performance and Strategy

One way of improving the BA department's performance is to make sure that its analysts

participate in meetings that will result in the business subsequently drawing on them as a

resource. First, this means that analysts can advise on which data in combination with which

methods will deliver optimum results in relation to any given problems. This constitutes an

ongoing briefing of the analysts, which in turn means that they will be working in a more

targeted way with the delivery of the relevant information and knowledge. Typically, analysts

have a large number of data sets or programs at hand that can generate answers quickly. Second,

if the business therefore asks questions in a way that means that answers can be generated via

these data sets, then the analysts can deliver complex ad hoc reports in a couple of hours or less.

This means that answers can be a direct result of the creative processes. The only condition is

that the analysts and the business create a dialogue that enables analysts to develop data sets on

an ongoing basis, with a view to solving future problems that may arise. A bonus is that an

analyst will feel more obligated and motivated to deliver quickly. All of this does, however,

place demands on the analyst's business insight or tool kit, as explained in Chapter 4.

The previous scenario means that analysts must be included in the work teams that draw on their

resources. If the company wishes to go down this route, a virtual BACC is sufficient. The analyst

will be ensured direct access to the end users of the decision support that they generate and can

become involved in the development of the value‐creating processes. Equally, analysts are given

a common forum, which means that they can complement each other's competencies.

If the objective of a BACC is to achieve a closer integration between the BA function and the

company's strategy, we've got a strong case for the establishment of the BACC as a formal

organizational entity. The primary argument is the impact it gives to have a BACC manager,

who can focus on this project and who has a number of employees working for him or her as

direct resources that can come into play. If the person responsible for the BACC does not have

the formal authority to prioritize strategic tasks, a lot of the analysts' time will be spent on the

operational tasks they're performing for their respective departments. At the same time, IT

competencies' time in a BACC will be spent on data warehouse maintenance rather than working

on enabling what the commercial side of the organization requires.

Further steps toward the goal are to identify where the organization is currently and where it

would like to be. In Chapter 2, we designed a model showing different degrees of integration

between the organization's strategy and the deployment of BA. The model can be used as

inspiration for this analysis. Alternatively, a maturity analysis can be ordered from most IT

consultancy firms, and this can lift the dialogue further. Maturity analyses are usually built on a

description of current information systems based on a number of dimensions, such as technical

elements, people competencies, and the business processes they must support. Similarly, a

description is made of the information systems that, in relation to strategies, must be built on the

same dimensions. Where we are and where we want to be are thus found—and the problem has

been broken down into a number of dimensions, which makes everything clearer.

When organizational clarity has been established as to where we are and where we want to be,

the next analysis looks at whether we've got the necessary resources and competencies to move

from (A) to (B). As mentioned previously, information systems can be divided into three

dimensions:

1. Technical elements, where the question is: Are we internally in possession of the technical leverage that may be required?

2. People elements, where the question is: Are we internally in possession of the competencies and resources to solve the analytical tasks and train users in future

solutions as required?

3. Business process elements, where the question is: Are we organized businesswise in such a way that we will get full value from our new strategic BA initiatives? Just as the

term maturity assessment is used to describe where we are and where we should be going, the term readiness assessment is used in connection with an analysis of whether we as an organization are ready to move from where we are to where we want to be.

After these two analyses, we've answered the two questions: Where should we be going?

How do we get there?

When the Analysts Report to the IT Department

The alternative to analysts being employed in the business is to place them under the IT function.

This structure has its obvious weaknesses, since we're turning the whole value chain upside

down, so that analysts go from requesting information and knowledge based on business

problems to offering information based on what's accessible in the data warehouse—in direct

opposition to our BA model. The difference occurs, among other reasons, because analysts' time

now becomes prioritized by the data warehouse section's management. This means that analyst

competencies move from solving business problems to taking their point of departure in the data

warehouse universe. It's a question of employee loyalty, too. When the analyst acts in a gray area

between business and IT, where should the analyst place his or her loyalty? Should it be with the

business that insists IT must find a different way of doing things, or with IT, which insists that's

not possible?

The answer should be considered in relation to the overall purpose of establishing a data

warehouse in the first place (i.e., to improve the business's decision making). It is therefore an

integrated part of the analyst's role to constantly challenge the data warehouse on behalf of the

business in terms of the quality of the solutions he or she delivers. This is not different from what

goes on elsewhere in companies. If the sales department is dissatisfied with the products that are

produced or the advertisements that are developed, they must be able to object. Equally, people

who deliver and implement sold solutions must be able to raise concerns with sales, if they

promise more than the organization can deliver. Also, finance must be able to interfere if sales is

pricing products too cheaply, so even though they may be selling enough products, the business

is not making money. There are, in other words, a large number of value chains in an

organization, all of which result in the delivery of services to customers. If these value chains are

turned upside down, or rather, if we create an organization where there is no correlation between

responsibility and value chains, we take away the platform for quality assurance.

If the sales manager is responsible for the delivery and implementation of sold solutions, with

whom do technicians then have the critical dialogue, if the sales manager won't acknowledge that

customers are actually being promised more than the organization can deliver? Technicians then

have the option of approaching the next management level. This involves a real risk of being

fired, and anyway, it won't be a great career move for the individual employee who's actually

risking his own neck for the good of the organization. We therefore find ourselves in a situation

in which we have an unhelpful correlation between the value chain and the responsibility for the

quality of this value chain. If the problem is not solved, our customers will suffer as a result of

the lack of internal quality in sales and delivery processes.

The same thing happens in an organization if the value chain is arranged in such a way that

analysts owe their loyalty to the data warehouse and not to the business. The only difference is

that nobody complains. In the data warehouse framework (which is the business), customers will

find it very difficult to formulate arguments for what can be done without the analysts'

competencies. As a result, the analysts will have no option but to keep quiet.

The reason consideration should be given to establishing a BACC as an independent business

entity is that it's a way of giving BA both the necessary organizational impact at a strategic level

and the potential synergies this will render at an operational level. Consideration should be

given, too, to how this business entity is embedded, to ensure the correlation between the

organization's value chains and the responsibility for the quality of these value chains. This

reasoning applies in the long term as well, so that a change of management will not put the

BACC at risk of coming under technically oriented management. As we stated at the beginning

of this chapter, consideration should be given to whether the company's strategy and

performance are supported by placing a BACC in the technically oriented part of the

organization.

WHEN SHOULD A BUSINESS ANALYTICS COMPETENCY CENTER BE ESTABLISHED?

As discussed previously in this chapter, we'll split up this question: Is the primary purpose of

establishing a BACC to optimize day‐to‐day business processes at an operational level, or is it to

achieve a closer integration between the company's strategy and the way in which information is

used? If the establishment of a BACC has the primary purpose of achieving improvements at an

operational level (performance), then the BACC can be established as a virtual organization, as

already discussed. The BACC should also work to ensure that analysts are placed as centrally as

possible in connection with the decision process at a departmental level. An obvious time to

establish a virtual organization would be in connection with the start‐up of new data warehouse

projects, since analysts would be able to contribute with requirement specifications in terms of

which information to collect in the future and in which format.

Even more relevant is whether the BACC would be in connection with the completion of a data

warehouse project, where new information is made available to the organization. If, so the

creation of a new virtual organization could work as a kick‐off for the new data warehouse

project. But there are other reasons that the creation of a BACC would be a good idea at this

time, especially if external consultants have been in on the project. At the end of the project,

these consultants will typically leave the organization, taking with them considerable knowledge

about subjects such as these: Why did we structure the data warehouse as we did? Which

departments and functions in the business requested which information and in which format? To

whom should the BA function then start its deliveries? Do we as the BA department have the

necessary analytical competencies to meet the organization's information requirements? Do we

even have the necessary analytical software? Then there's the issue of being able to navigate the

new data warehouse. We must therefore ensure a transfer of SQL code to enable our analyst to

use all the tables in the new data warehouse from day one. A data warehouse is an information

system like any other. If analysts cannot use its full potential, we're already taking a value loss.

Another argument for establishing a BACC in connection with the kick‐off of new data

warehouse projects is amusingly explained by Douglas Adams. In his book, The Hitchhiker's Guide to the Galaxy (1979, reprinted by Del Rey in 2010), a civilization on a planet would like the answer to “the ultimate question of life, the universe, and everything.” To that end, they build

a computer that provides the answer millions of years later. The problem is that the civilization

had not formulated the question to reach that answer, and therefore has to make a new computer,

which for additional millions of years will be calculating the question for which the original

computer had delivered the answer. There are strong parallels here to what may happen in an

organization: Some years ago, when the data warehouse project was launched, the business was

interviewed about which information they might want in relation to its different business

processes. The problem with this is that not a soul is able to remember this now. The analysts are

therefore asked to investigate the potential of the new data warehouse for the business. This is

where a knowledge transfer should have happened when the project was completed—from the

people who made the initial requirement specification to the data warehouse to its users: the

business and the analysts.

We also mentioned the concept of knowledge management. In essence, this will force the BACC

to focus on what the business demands and will potentially give the BACC the task of promoting

a knowledge library, including a methodological way of gathering learning from the

organization. At the same time, the BACC must be an active creator and provider of decision

support to the strategic level.

Another good time for a company to establish a BACC is when people at a strategic level realize

that information can be used as a strategic resource in the given competitive environment. Who

will now drive the process further? It's important to note here that these situations often require

much more than analytical resources. It takes insight into strategy and the strategy development

process to adapt the right BA initiatives to a strategic context. Moreover, we've got a change

management task to perform. That is, we often need to address the soft issues, such as the

corporate culture. We now need to train the entire organization in when it's supposed to deploy

factual decision making based on BA information—and, equally, when it's not expected to do so.

New attitudes must be taught, formed, and strengthened. Similarly, we need to challenge,

transform, and dissolve old and reluctant attitudes via positive learning processes. Further, the

organization must understand the importance of data quality. If the people in sales do not enter

their prospects in the CRM system, then the CRM system itself is a wasted investment. If

customer names are not entered carefully, we won't be able to find them later. We have to find

and reward good examples of fact‐based decisions, promote these in the rest of the organization,

and also point out incorrect or insufficient use of the established information systems. It's

important, too, to continually ensure that management at all levels is supporting the

implementation of this kind of decision‐making, since their role as advocates is significant to the

successful implementation of the project.

If this does not happen, we risk getting into a vicious circle where the system has no users or

where data is used unsystematically, which again will result in poor data quality. Poor data

quality will be evident when information may be accessible, but it is imprecise and irrelevant.

This will make users even more reluctant to use the information systems and the entire

information strategy; it now looks like a failed project, which will lose its sponsors at an overall

management level. We cannot stress enough the fact that an organization is made up of people.

Since they are the ones who must change their behavior, it's a critical success factor for the

project to be able to win, retain, and develop their commitment. The technical part is the easier

part of the project. The soft part (the people part) is the tough one.

APPLYING THE ANALYTICAL FACTORY APPROACH

The analytical factory approach is about standardizing procedures to drastically reduce the

development time of analytics, and this is especially important if digitalized processes are

making decisions. The main idea is to “force” all analysts to reuse data sets, various templates,

and documentation practices in order to save money and time and to bring campaigns to market

closer to real time. An example could be a telecom operator that frequently needs to send

relevant offers to customers in real time.

If the telecom operator has 400 product combinations, 200 pieces of service advice, and 100

product‐specific messages, in addition to ad hoc communications, it becomes a complex task.

Also consider that there are multiple customer segments in multiple countries. We will also have

to put some business rules on top, so that only the most relevant messages are sent, and never too

often. If we don't, we will create what is known as “monkey with a gun”—a dumb marketing and

communication system that simply spams the receivers.

Now imagine a traditional analytical department where the development of a model to support a

campaign is done from scratch from time to time on local laptops and on data sets developed by

individual analysts. It will take weeks or month for a model to be developed, signed off by the

business. And as we need to develop at least 700 models and business rules for the system to

send the right communication to the right receivers at the right time, the analytical development

time will take hundreds of analyst years. Not good news for those in a rapidly changing business,

so strong procedures seem to be the answer.

By using the analytical factory approach, all analysts working on different campaigns would

simply start out with the same data sets, documentation procedures, and real‐time

communication engine. Where the communication real‐time engine is the server that is

responsible for sending out communication to customers the same second a rule is triggered. For

example, if a customer changes their address, we would like to inform him or her of the location

of the company's nearest physical outlet. This data will typically be on a customer

level/subscription level, which also means that we easily can map a target variable on to the data

set. Therefore, if we would like to model which customers are likely to buy a certain kind of

phone, we would identify those who just bought it versus those who did not chose to buy it, and

assign a buying probability to the rest.

The analytical factory approach improves upon the company's efficiency and readiness for

change, as it drives down the development time of models from months to days or even hours.

SUMMARY

In this chapter, we looked at how the activities of the BA model can be carried out via a business

analytics competency center, or BACC.

A BACC is a forum that includes analytical and business competencies as well as IT

competencies and works to ensure that the needs of the business drive all technical initiatives,

thereby making sure that the business does not get a data warehouse with a life of its own. One

of the most important tasks of a BACC is to coordinate information wheels in order to create

synergy on the data side, as well as synergies across analysts and IT professionals.

If the objective of a BACC is to achieve a closer integration between the BA function and the

company's strategy, we recommended the establishment of the BACC as a formal organizational

entity. However, if the objective of a BACC is to optimize the company's performance, we

recommended the establishment of the BACC as a virtual organizational unit.