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:
- Technical elements, where the question is: Are we internally in possession of the technical leverage that may be required?
- 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?
- 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.