CHAPTER 16
Analytical Organization: Getting Organized

As we mentioned at the beginning of the book, the explosion of information is accelerating and the next big explosion, the Internet of Things, is upon us. When our machines begin talking to each other the rate of information produced each year will go exponential. The CEO of Alphabet, Eric Schmidt, commented,

Just in case you do not know the definition of an exabyte, which we did not, it is defined as “a unit of information equal to one quintillion bytes, or one billion gigabytes.”

Organizations are capturing as much of this information as they can, trying to figure out what can be monetized and what can be discarded. Most organizations are collecting everything, assuming it will be useful eventually. This may be the right approach, but what can be done today to monetize the information you have collected?

To make sense of this amassed information, different roles are needed inside the organization to collect, codify, and monetize this abundance of information. We propose several new roles and a team structure to accomplish this challenge.

Decision Architecture Team

Our recommendation is the creation of a cross-functional team focused on monetizing the company's information assets by leveraging the Decision Architecture methodology we present in this book. This team should be organized across divisions, sharing best practices, tools, and techniques.

Many organizations have started on the journey of implementing data governance as a centralized function that captures data standards, linage, and metadata. The purpose of the Data Governance group is to serve as a centralized governing body providing oversight of the company's data standards and quality. The question we ask most organizations is, why stop there? Wouldn't collecting your organization's major decisions and actions provide as much value if not more? We believe the next evolution is the collection of organizational wisdom through the gathering of decisions and actions. Once these are collected and processed, systems and analytical solutions can be created and embedded with this wisdom to drive better decisions.

To accomplish this, your organization needs to establish a Decision Architecture team as either a part of the data governance team or a completely new organization. The Decision Architecture team will have several roles with a varied set of disciplines. The individuals within this team can be part of a centralized team or matrixed in. We will review these options in the next section. For now, let's focus on the structure, capabilities, and governance of the team.

Project Based versus Business Functional

One of the first decisions to make is to decide if the team should be purely project focused or business functional in nature. This is a tough decision and may differ by organization and maturity of the analytical capabilities of the company.

A project-focused team is easier to enable within a company. The work load is dependent on a backlog of projects from various departments, and even the smallest of projects can get the team started. The team can work in a matrixed environment with team members rolling back to their respective groups once the project is completed. Or the team can work part time on these projects if there is not enough demand for a full workload.

There are a few drawbacks to a project-based approach. If the team is project driven, the larger groups with bigger budgets receive the majority of the focus. In addition, it is hard to scale best practices, tools, and techniques across the organization since the focus is on the current project at hand. Lastly, the nature of project work creates a finite timeframe, implying the group may not be around after the project is completed, limiting investment in needed infrastructure. If your organization starts with a project-based approach, it will probably want to move to a business functional model once the project work is self-sustaining.

A business functional model is a centralized team with various members aligned to specific departments within an organization. There may be a decision architect assigned to each department, such as Finance, Marketing, IT, Sales, and so forth. This focused approach can help the decision architect become more familiar with the department's business, data, decisions, and challenges. They will also be able to build strong relationships within the department they serve, facilitating faster project completion with a higher degree of relevance. This focus will enable them to bring in best practices and monetization strategies from peers and other departments to help their area mature faster. Lastly, the architect will stay around long after the project is completed to see the results of prior initiatives and take these learnings with them to the next project.

The downside of this model is that it takes longer to implement and achieve success. Patience is needed on behalf of the business as the team builds the infrastructure necessary to support this function. In addition, this type of approach may become bureaucratic through sheer weight and size; projects that go across departments may take longer and require additional resources.

Both of these approaches have benefits and drawbacks. You should assess your organization's politics, culture, analytical capability, maturity, and quality of data to determine the right approach.

Capabilities

There are many capabilities that the Decision Architecture team is able to provide in building analytical solutions. The overall focus and goal of the team is to help the organization monetize its data and make better-quality decisions. They are able to meet this goal by the use of the techniques, methods, and processes we have outlined in this book. Let's review several of them:

  1. Decision Architecture—The core capability of the team is the production of the Decision Analysis, Monetization Strategies, and Guided Analytics. This capability includes methods for capturing information as well as codifying and distributing it to various stakeholder groups. For example, if a new monetization strategy is developed that drives a higher Asset ROI for a vehicle type centered on maintenance scheduling and predictive wear and tear, this solution along with the decisions and actions it enables may be useful to other departments within the organization. The Decision Architecture team is on point to propagate this solution to the various stakeholder departments to drive cost savings for the company.
  2. Facilitating Techniques—The team needs methods for conducting interviews and working sessions to capture the elements of the Decision Architecture. This includes leveraging facilitation techniques such as icebreakers, root-cause analysis, cause-and-effect diagrams, brainstorming, and prioritization methods. In addition to the various techniques, the team needs a base understanding in conducting interviews and working sessions. These involve leveraging tools such as ground rules, issues and risks lists, and action plans.
  3. Inventory and Cataloging—Collecting and codifying the elements of the Decision Architecture is another key capability focused on organizing and inventorying the various data elements, decisions, questions, metrics, and actions. This includes documenting the use of the Decision Architecture elements across the organization, the quality of these elements, and the effectiveness of their use. For example, after building the Decision Architecture for two departments, the team notices that the groups are making similar decisions for one of their diagnostics. This is a great opportunity to collaborate between the two groups to share the collective wisdom and approaches of both teams to drive synergy across the organization.
  4. Defining Metrics and Decisions—Defining the various metrics and decisions throughout an organization is another key capability. This function may overlap with Data Governance somewhat. The major difference between the two groups is that the Data Governance team is focused on definitions and standards for business metrics whereas the Decision Architecture team is focused on decisions and actions derived from the metrics. Both have a focus on business metrics with different outcomes.
  5. Monetization Strategies—Another key capability is Monetization Strategies, which are specific strategies for driving economic value from a company's data assets. These include analytics or diagnostics that can be utilized at a departmental or corporate-wide level. Examples include: Pricing, Valuation, Retention, Cross-Sell/Up-Sell, Revenue Opportunity, Cost Saving, and Asset Utilization. One of the team's core capabilities is to develop specific repeatable strategies to monetize the company's data.
  6. Data Science and Decision Theory—Another key capability is the use of data science and decision theory techniques to help monetize company data or perform specific studies. These techniques include Thresholds for Metrics, Correlation Analysis, Segmentation, Clustering, Forecasting, Scenarios, Decision Matrix, Probability, Choice Architecture, and Optimization. For example, when trying to determine the probability of achieving a specific opportunity, the data scientist calculates the value of the opportunity and a corresponding ability to achieve. Not only is the metric usage repeatable, so is the design pattern that can be leveraged for similar metrics.
  7. Data Analysis—Data analysis capabilities are a core capability of the team. Data analysis is the technique or method of inspecting, transforming, and analyzing data with the goal of using it to develop a quality decision that is actionable. Everyone on the Decision Architecture team should have a deep familiarity with data analysis and its concepts.
  8. Guided Analytics—When the Decision Analysis is completed, development of a Guided Analytics solution is another responsibility of the Decision Architecture team. Development of guided analytical solutions helps users visually navigate through information and diagnostics to make quality decisions that drive actions. These tools are easily deployed, visually intuitive, and provide exception-based analysis to quickly identify issues and opportunities. These tools can be leveraged by executives, analysts, managers, and field workers. The level of automation can vary from an Excel-based tool to a fully automated system. Much of the work we do to build monetization strategies encompasses some type of Guided Analytics tool.
  9. Measurement—Once an action is taken, measurement is a key capability of the team. Tools and techniques are needed to measure performance of specific monetization strategies and actions. In addition to measurement, the tools should provide feedback on success of the overall strategy, progress on tests, and learnings for continuous improvement.

Based on your company and the team's maturity, you may decide to add additional capabilities to their portfolio. These may include the addition of data science techniques, specific tools like SAS, R, Tableau, QlikView, Power BI, Data Architecture and Development, and Six Sigma methods. The team's evolution and capability will increase as they add value to the organization.

Governance

Governing the Decision Architecture of an organization is important as adoption and enablement increase through the use of analytical solutions. We recommend that a company develop a governing board for Decision Architecture to oversee direction and strategy.

The governing board should be made up of a matrixed team of functional leaders with a stake in the success of the company's monetization strategies, decisions, and actions. This group is responsible for establishing the charter, ensuring consistency, prioritization, standards and policies, compliance and security, and communications of the Decision Architecture team. Below is a detailed description of the recommended governance board responsibilities:

  • Team Charter—Establishing the charter for the team should be one of the first deliverables for the governing board. This includes ensuring the mission, objectives, and efforts of the team are aligned to corporate objectives. In addition, the team may want to build a roadmap, approved by the board, that lays out their agenda for a forthcoming period.
  • Standards and Policies—As an organization develops its Decision Architecture and analytical solutions for various functional business capabilities, standards and policies should be established. Standards can be as simple as the list of decisions for a particular group or as complicated as the definition of the Success Metrics for a company. A policy is a principle adopted for the organization to follow. In the case of Decision Architecture, an example of a policy might be to set rules for the types of diagnostics for certain roles within the organization. To further the example, if an organization has a store manager who is responsible for staffing of the store, the policy might dictate they need to use a specific staffing diagnostic as the primary analytical tool to make hiring decisions.
  • Decision Architecture—Overall responsibility for the Decision Architecture of the company, including Decision Analysis, Monetization Strategies, and Agile Analytics, as well as endorsement of the tools and techniques utilized and governance of the analytical solutions.
  • Monetization Strategies—Reviewing and maintaining the various strategies for monetizing the organization's data assets, and leveraging these strategies across departments to scale and improve the quality of decisions and actions. These strategies will constantly evolve as business and market conditions change.
  • Team Resources—Administration of roles and responsibilities of the team aligned to the charter. Depending on the capabilities required of the team, the mix of team skillsets may vary. This includes the decision for which roles should be full time within the team and which should be matrixed. Lastly, resource leveling of the roles to ensure adequate staffing will be another responsibility.
  • Financial Resources and Prioritization—Each of the work efforts under the Decision Architecture team should have a business case and alignment to the business objectives of the organization. Based on value to the company, the governing board should approve financial resources. If there are a large number of projects and competing resources, the governing board should also prioritize work efforts, which may influence both financial and team resources.
  • Risks and Issues—Resolving major risks and issues as they arise for the team and removing roadblocks and providing timely resolution, enabling the team to deliver without impediments.
  • Compliance and Security—As decisions and actions are cataloged, compliance with the overall standards and policies of the organization is necessary to ensure that a specific action does not contradict a corporate or government policy. Lastly, securing the business architecture of the company to ensure competitive intelligence does not end up in the wrong hands.
  • Communications—Providing communications to various stakeholders on the progress of the Decision Architecture team, issues and risks, policies and standards, and general updates.

Collaboration

Another responsibility of the Decision Architecture team is collaboration with various stakeholders and groups within your organization. Understanding the various team's agendas, capabilities, and initiatives helps the Decision Architecture team plug into existing capabilities and initiatives. This will save the team time, remove competitive barriers, and increase the likelihood of collaboration.

A great example of collaboration comes from Space X's work with NASA. Space X wanted to make faster decisions to speed up its time to market for its customer NASA. Eric Winquist, in his article, “How Companies Can Learn to Make Faster Decisions,” discusses the costs of delayed decisions:

Fortunately for Space X, they were able to solve for this issue.

When establishing the Decision Architecture team, work to build an engagement model of how the team will work with other teams, both internal and external, to avoid delayed decisions, competing initiatives, and overall lack of communication.

Training

Another responsibility of the Decision Architecture team is training the end users of the analytical solution, which we covered in the Enablement chapter (Chapter 15). User adoption and coaching is a key aspect to ensure the solution is utilized. How well the users adopt the solution and how often it is used will dictate the value derived by the organization. As a reminder, the key training components include content, medium, and adoption.

Decision Architecture Roles

In order to execute on the capabilities outlined earlier in this chapter, we propose several roles for the Decision Architecture team. The roles can be matrixed into the team or they can be a direct report, depending on the work capacity, career path, and organizational structure of the company. The roles we recommend include a manager/leader, decision architect, data librarian, data/decision analyst, trainer, UI developer, dashboard developer, and data architect/developer. Let's review each:

  1. Manager/Leader—The manager of the Decision Architecture team is responsible for the overall guidance of the team, participating in the governing board, career management for team members, success of the work efforts, and aligning value to the organization with these work efforts. A background in analytics, statistics, business intelligence, and data analysis is recommended.
  2. Decision Architect—The Decision Architect is a new role for most companies. This role is a mix of business architect combined with a data analyst who understands analytics. The Decision Architect is responsible for engineering the analytical solution leveraging the various disciplines within the team. They are the main facilitator in the user interviews and working sessions, designing the architecture through Question Analysis, Key Decisions, Success Metrics, and Action Levers. They apply these to Category Trees while utilizing Data Science and Decision Theory to articulate a monetization strategy for the analytical solution.
  3. Data Scientist—The data scientist applies mathematical techniques to the data to turn it into actionable insights. The techniques include metric definition, correlation analysis, segmentation, profiling, clustering, forecasting, optimization, and opportunity analysis. These individuals should have a math degree and strong understanding of data and statistical techniques.
  4. Data Librarian—The data librarian is a new role for most organizations, especially those with big data investments. Knowing where to find data in an organization is often based on tribal knowledge and requires a data detective. With more data entering an organization than ever before, and much of it unstructured within a big data environment, the cataloging and organizing of this data is vital to being able to fully utilize it. The data librarian is responsible for knowing where data exists, cataloging it, moving it, and stitching it together to enable analysis.
  5. Data/Decision Analyst—The data/decision analyst understands how to source, transform, and manipulate data. They are able to deconstruct the Question Analysis into a set of information needs and align them to the decisions and actions. They work with the data librarian and data developer to source the information and bring it together into an analytical structure for the dashboard developer. In addition, they often work hand-in-hand with the data scientist to implement correlations, thresholds, opportunities, and other techniques.
  6. Trainer—The trainer assembles training material and trains the user of the analytical solution. They teach, guide, and coach individuals up the learning curve until there is a level of proficiency for adoption and usage to drive value to the organization.

If the solution will have a certain level of automation, the following additional roles will be needed:

  1. UI/UX Designer—The UI/UX designer produces intuitive designs that are easy for users of the analytical solution to interpret and adopt. The designs that the UI/UX designer produces allow you to quickly interpret information and guide you to an issue or opportunity that needs further investigation. Consistency across analytical solutions for the UI enables a shorter ramp-up time as the users do not have to relearn how to use the tool; they simply have to learn the data.

    For example, the UI element in Figure 16.1 displays two pieces of information: ability to achieve an opportunity, and potential revenue lift. The UI element is telling a user that the potential lift for a particular action is 10 percent, but the ability to achieve it is low. It is this type of intuitive design that the UI/UX designer enables in the analytical solution.

    Image described by caption and surrounding text.

    Figure 16.1 Using UI to Communicate Efficiently

  2. Data Architect/Developer—The data architect/developer extracts information from the various source systems and develops the analytic structure to support analytics and reporting. This might entail extraction, transformation, and formatting of data into various analytical structures. Data quality is key and determines how much transformation is needed. This role works closely with the data librarian, data analyst, and data scientist.
  3. Guided Analytics Developer—The Guided Analytics developer develops dashboards, visual analytics, and visual diagnostic tools to make the analytical solution accessible to end-users utilizing the Decision Architecture, the data architecture, and the UI design. They also enable any monetization strategies developed through data science and decision theory techniques. This role brings together the various disciplines to create the Guided Analytics experience for the user.

Subject Matter Experts

One of the most important aspects of this process is to identify your subject matter experts (SMEs). These individuals are knowledge experts in a particular role, function, subject, process, or capability. They know the business rules, history, lessons learned, and often the questions to ask to make effective decisions. You may need more than one SME depending on the breadth and depth of the subject matter you are covering.

Leveraging these individuals is useful during many touchpoints in the process. During the interview process, they are often a leading source of questions and decisions that we ask or make about the data. When creating the diagnostics elements, they are often the source of Success Metrics. When creating the Category Tree, they can validate the information flow and the use of the questions, decisions, and metrics for each of the nodes in the tree.

Once an SME trusts the data and the outcome of the decision process, they can help to ensure the relevancy of the information is on target with how the information user will leverage the tool. In addition, the Monetization Strategy will need their validation to gain broader adoption and their stamp of approval during the rollout, which will often be a key measure of adoption.

One note of warning: be aware of any biases that may exist with the individual. We cover these in our Decision Theory chapter (Chapter 8). We all bring these with us; your job is to recognize them and make sure it does not affect the analytical solution.

Analytical Organization Mindset

A person who never made a mistake never tried anything new.

Albert Einstein

You don't learn to walk by following the rules. You learn by doing and falling over.

Richard Branson

There is only one way to avoid criticism: Do nothing, Say nothing, and Be nothing.

Aristotle

As we conclude this section, we want to raise issues of changes in the organizational mindset needed to be successful. When an organization adopts a Decision Architecture framework, they begin to measure business decisions and actions to a larger extent than previously. With this measurement comes the need to develop a mindset that failure is okay. The measurement is there to guide the company on whether the actions are working or need to be changed. This culture where failure with adaptability is okay is typically referred to as “test-and-learn” or “fail early, fail often.” As long as the organization is learning from actions that do not work, there is no failure.

This organizational ethos of test-and-learn is driven by hypotheses that are developed and tested in everyday actions. For example, if you are a product company that is developing new products, there is constant innovation occurring around new flavors, styles, technology, and package sizes to drive the next product wave of innovation for your company and industry.

This philosophy can be adopted by service companies as well. If you sell life insurance, your company can test new insurance services in particular markets to gauge the likelihood to buy and profitability. This level of innovation should not be a once-a-year activity; it should occur continuously. Great test-and-learn organizations are constantly testing new products and services in their various markets to see which ones might be the next big winner.

We recommend starting small, looking for quick wins, and evolving through iteration. The process of developing an analytical culture is a journey. If an organization starts on this journey without tangible results in the short term, the initiative will often fail under its own weight as the organizational energy to support it collapses or wanes with business cycles or shifting priorities.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset