Tag: Business Intelligence

The Business Analyst Career Road

Written by Tejasvi Addagada on November 7, 2017. Posted in Articles.

The BA career road-map shows a bird’s eye view of the roles that Business Analysts can navigate in their career.

This also states in which function, the skills of a BA are best required. But, there are other functional spaces that a Business Analyst can embrace apart from the Business Analysis, Decision Support Analysis and Enterprise Architecture. One such functional area is Data management and Governance.

Every organization today, is looking forward to transform their business models emphasizing direct and in-direct Monetization as one of the primary drivers. This calls for a change to the current Business, Information technology landscapes while there is also a need to govern data. This can be a regulatory requirement or an enabler.

Often, we keep referring to hundreds of processes in a firm that are supported by thousands of systems that create, store data in again thousands of data stores, in a fragmented way. Thus, complexity of landscape remains the largest challenge that most organizations are tackling to simplify.
The organizational priorities for the much-required landscape transformation is driving the definition of data strategy. Data is the plasma that reaches every corner of an organization and keeps its actively functioning. There are dimensions of data management including data quality, metadata, risk, security and architecture management that help in simplification and benefits enablement using data.

There is a need for information capabilities and skills governed by Data Governance that manage and control this data. This enables the organization to look beyond regular business models, cost and risk reduction while aiding discovery of new revenue streams.
The benefits of having to manage and govern data are multi-fold, in reducing future costs associated with mergers and transformations, upfront integration costs, operational costs of maintaining redundant data, reducing product time to market, competitive advantages and the list goes on.

Data Governance is the process of setting standards, defining rules, establishing policy and implementing oversight to ensure adherence to data management best practices. Governance is the formalization and empowerment of the data management program, to ensure propagation and sustainability throughout the organization.

Most Business Analysts performing Data Analysis in these organizations, gradually moved into well established roles of Data Management and Governance. A business analyst has the necessary skills to gather data requirements, analyze and model the specifications, translate them in a way that designers and architects understand to build solutions. He further understands the need for Governance, performs enterprise analysis and assesses the solution capabilities.

Is it time that this functional area should be included in the BA career roadmap? The Business Analyst can traverse the roles from a Business Analyst or Data Analyst to being a Chief Data Officer.

A Business analyst followed by a Data Governance consultant and then an executive dimension owner, Business Data Steward and a chief data officer are some established roles that exist in this functional area.

The Algorithmic Business Analyst

Written by Lakshmi KP on October 10, 2017. Posted in Articles.

Fortune introduced the term “Algorithmic CEO” in 2015. The trends we have seen in the last two years have only added credibility to that term.

Analysts have been talking about how algorithms will transform enterprises. We have seen several new businesses launched with focus on machine learning, cognitive computing and artificial intelligence. We have also seen several existing businesses going the algorithmic route, by investing heavily in technology that relies on algorithms. These are typically cases where advanced big data analytics solutions are being used to optimize operations, or to improve customer experience.

The algorithmic age is forcing everyone – including the CEOs, CMOs and CIOs – to find a new balance. What about the Business Analyst who has been the bridge between “business” and “technology” all these years? To survive and thrive in this algorithmic age, what skills does a Business Analyst require? One way to answer this is to look at the five different domains that Project Management Institute (PMI) has defined for Business Analysis, and see what additional skills or knowledge are required.

1. Needs Assessment

The Needs Assessment domain relates to understanding a business problem or opportunity, and evaluating various inputs to help develop an effective solution. This assessment is typically crucial to get funding approved and have the project initiated.

The Business Analyst needs to be abreast of the technology trends that are driving the algorithmic age – big data, cloud computing, artificial intelligence, machine learning, internet of things etc. The Business Analyst should be familiar with the nuances of the trends that are most relevant for the project. This is essential to articulate the business opportunity in a relevant manner.

The algorithmic age is heavily dependent on data. The Needs Assessment will most likely require data to provide justification for the initiative, or to showcase how data can be used to solve a problem, or how data can be used to improve the business outcomes. The Business Analyst, hence needs to be proficient at identifying the potential of data, and to tell a story using data. The ability to build a data-driven business narrative to support a business case is crucial.

One of the challenges of algorithmic solutions is to be able to evaluate if the solution met its objectives. This evaluation process often is as complex as building the solution itself. As part of the Needs Assessment, the Business Analyst should be able to cover the expected evaluation process, so that the project team can plan for it.

2. Planning

The Planning domain comprises of all activities related to effectively managing all the business analysis activities such as establishing requirements management, requirements traceability, change control, document control and acceptance criteria.

Establishing acceptance criteria is an area where there could be additional complexities for an algorithmic project. The Business Analyst is expected to translate the business objectives to the goals of a specific algorithm. Defining this goal may need to clearly define the data conditions and boundaries. It may be required to do an extensive study of the business data to be able to come up with these goals. Also, a simulation platform may be required to run an algorithm against data. The Planning should also cover if there is need for such additional platforms, or additional data.

3. Analysis

The Analysis domain focuses on elicitation, analysis, decomposition, acceptance, approval, specification and validation of requirements.

The requirements may need to be defined in the context of the technology trend driving the algorithmic initiative. The Business Analyst’s expertise in the technology trend, hence is relevant in Analysis too.

The Business Analyst needs to be data savvy to be relevant. Depending on the organization and complexity of the project, there may be a Data Analyst on the project. Even if there is a separate Data Analyst role, the Business Analyst needs to have certain level of proficiency in data analysis and data visualization. The Business Analyst will be expected to put in a structure around the analysis done by the Data Analyst. For example, the Business Analyst should be able to drive discovery of data correlations, trends and outliers – to build a data story.

What about user stories, use cases, process flow diagrams and everything else that Business Analysts typically prepare? They are all still important. The Business Analyst will in fact need to go one level deeper as all these standard artifacts will also need to get connected to the data story.

4. Traceability and Monitoring

The Traceability and Monitoring domain related to activities needed to manage the lifecycle of requirements. The requirements lifecycle, and the tasks to manage the lifecycle are no different for an algorithmic project as compared to a standard project. The artifacts used to capture requirements could be different, but the process remains the same as for a standard project.

5. Evaluation

The Evaluation domain relates to activities that assess how well the solution met the requirements and business needs. Typically, a Business Analyst does evaluation by running some tests or by reviewing the test results from a Quality Assurance team or by reviewing a demo of the product or feature. While these still hold good, there are additional tasks required in the case of an algorithmic project.

Once the solution has been built, the Business Analyst should be able to run the algorithm against realistic data, and see whether the algorithm is meeting its goals. Depending on the complexity of the project, this may need additional infrastructure, and involvement from other team members. If the algorithm fails to meet its goals, the Business Analyst may be required to do additional data analysis and identify the conditions under which the failure occurs.

Summary

The standard rigor expected for Business Analysis applies to the algorithmic projects as well. However for a Business Analyst to really thrive in this age, it is important to have these additional skills and interests.

Ability to translate business goals to relevant metrics
Passion for data analysis
Deep interest in the technology trends driving the algorithmic age

With these three in place, an already successful Business Analyst is bound to succeed, and take the organization further in its algorithmic journey!

How to Discover Useful Requirements for Business Intelligence

Written by Kent McDonald on May 31, 2017. Posted in Articles. 1 Comment on How to Discover Useful Requirements for Business Intelligence

“My users are asking for a report, but how do I make sure I truly understand their needs and properly convey that to the rest of the delivery team?”

Asking for a report is great, but it is a loaded word. People use the word “report” to mean many different things.

A report is a solution in search of a problem. You may know what your stakeholders want on the report, but until you identify why they want the report, you enable their solution seeking.

When you want to understand a stakeholder’s business intelligence needs completely, the following steps often prove very helpful:

Start with the questions stakeholders want to answer and decisions they want to make
Focus on value and feasibility to determine what to do next
Dive into detail only when you need to

Start with Questions and Decisions

When your stakeholders ask for a report, you want to know why they want that report, but you do not want to ask why. Why not?

Asking “why do you need a report?” is not going to provide you with the key insights and information you need and may make your stakeholders think you do not believe they have a need at all.

To avoid that uncomfortable situation, I have found that Socratic Questioning is a good route to go. The question I like to start off with is “What questions are you trying to answer or what decisions are you trying to make?”

When your stakeholders describe the questions/decisions, listen for phrases such as:

I want to know…
I want to decide…
I want to determine…

These help to identify the initial big chunks of value you can deliver in your business intelligence efforts.

Say you are working on a product to allow the audience at Olympic events to vote on the competition – say platform diving – and your stakeholders want to incorporate reporting into that product.

You talk with your stakeholders and find out that they want to know how votes can vary depending on characteristics of the audience or the competitors. That may result in the following things that you want to explore:

I want to know if audience members vote differently based on their gender
I want to know if audience members favor athletes from their country
I want to know if audience members evaluate athletic performances the same as judges
I want to know if audience member age impacts how they evaluate performances.

You can easily capture these in a user story, job story, or another template of your choice. The key is that you know what your stakeholders hope to accomplish with the reports, so you can guide the discussion to find out what your stakeholders hope to accomplish.

When you have those conversations, listen for nouns. They represent the pieces of information you need to know. Also listen for phrases such as “by gender” or by country They indicate how to organize the data, including what dimensions you may need.

In our examples above, the nouns you will most likely pick up on are audience members, athletes, and judges. The dimensions then may be audience member gender, audience country, athlete country, and audience member age.

Focus on Value and Feasibility

Once you have identified what you want to work on, you need to decide the order in which you work on it.

Start by prioritizing the questions and decisions your stakeholders are interested in based on value. Which of those questions and decisions are most vital to your stakeholders’ objectives? It may be the question/decision that provides your stakeholders the biggest lift or is most critical to address other questions and decisions.

Then, consider feasibility. Feasibility focuses on whether the data you need to address the questions and decisions is availability and organization of the available information. If the information is not readily available, consider alternative methods and their difficulty in obtaining that information.

Some pieces of data may present some substantial risks from the perspective of whether you will be able to get that data. If that data is critical to some of the more important questions/decisions, you may decide you need to tackle that data first.

Feasibility also drives the order in which your team delivers the data for a specific question/decision. As a result, you may provide overall prioritization of which questions/decisions to address in what order, and then leave it to your team to decide the order of the smaller bits of work necessary to deliver the ability to answer a given question or make a specific decision.

Dependencies play a part in considerations of feasibility. Often the answer to one question becomes an input to answer another question, so you have to consider those interdependencies when you decide the order of the questions you tackle.

Prioritization is most effective when it is a team discussion. Start with which questions you want to answer or decisions you want to make first, but then revise that order based on the feasibility involved in getting the data necessary for those questions or decisions.

Only Dive Into Detail When Needed

I noted above that you want to listen for nouns and pointers to possible dimensions. Noting what comes up during the normal course of conversation is ok, just avoid the temptation to dig too deep too soon.

You do not know which stories you are going to need to do, so you do not want to expend too much effort fully understanding stories you are not going to do. When do you dig into the details?

When you have initial conversations with your stakeholders to understand the information they seek, you may sketch out a very rudimentary report during the conversation to make sure you understand what they are asking for. Stop when you have enough information to determine what order you want to deliver those questions and decisions.

In some cases, you may need to dig a little bit if you identify a piece of data which may prove a somewhat difficult to obtain.

Wait to delve into all the details of the data (definitions, transformation rules, valid values, or other factors) until you are preparing information for a team to deliver the necessary data to answer a question or make a decision.

Business Intelligence Can Be Done Iteratively

It is possible to deliver data warehouses in an iterative, incremental fashion. The key to making that happen and work is to organize your increments around questions your stakeholders want to answer or decisions they want to make. Then consider value and feasibility to prioritize those questions/decisions, and avoid the temptation to dive too deep too soon.

What experiences do you have working on business intelligence projects? Leave your thoughts in the comments.

Product Manager’s Guide to Embedded BI: Empowerment with Self-Service Analytics

Written by Marcus Hodges on May 17, 2017. Posted in Articles.

A product’s roadmap is no secret to its product manager. The job entails planning future development in response to requests for enhancements, new requirements, and competitors’ offerings.

One priority making it to the top of the list for product development is intuitive self-service business intelligence (BI), data analytics, and visual data discovery. End users across a wide range of industries expect these capabilities in the applications they use regularly. Self-service BI helps organizations spot outliers and trends, improve business processes, save money, and grow revenue.

Software Vendors Respond to Growing Demand for Self-Service BI

Software companies realize the benefits of improving analytics in their solutions. Delivering value extends beyond simply offering self-service functionality. It requires the ability to embed analytics in the workflow where users need them to make decisions and to give users the ability to create new reports and dashboards for true data exploration.

However, coding this functionality in-house poses complications:

Lengthy time to market – an analytics project beyond superficial functionality may take years to launch, especially if analytics is not a core competency of the developers tasked with the project
Opportunity costs – resulting from having developers focus on analytics and deferring essential development of enhancements, upgrades, or other changes; licensing of toolkits beyond the use of open source libraries and toolkits adds to the expense line
Ongoing maintenance and enhancements
Scalability – resale requires developing a BI application that is customizable, scalable, and compatible with other infrastructures

Purchasing and embedding an analytics offering from a third-party software company with a core competency in analytics is a more cost effective approach. Many options for embedded analytics products exist in the market today. Understanding the differences between these products starts with scoping:

Functional needs – like self-service, a short learning curve, easy-to-use query functionality, real-time reports and responsiveness across devices
Business needs – project costs and return on investment (ROI), factors associated with selling the solution profitably (licensing, third-party support costs, updates to existing infrastructure requirements, add-on product cost, personnel resource requirements), and long-range organizational issues (growth plans, ability to scale a growing customer base, pricing model for monetizing analytics)
Technical needs – organization’s technology stack, database and other data source technologies, availability of the different technical resources and skillsets needed to support the project (deploying the BI tool in the cloud, on-premise or as a hybrid, or requirements for a data warehouse or changes to an existing database)

Where to Start – Research and Product Demonstrations

Early research takes place using software review sites that offer verified reviews from the user base and studying research reports published by industry analyst firms that specialize in BI. Vendor websites are another source for information. They may include case studies to learn how they handle BI implementations.

An organization will often target three to six vendors for product demos. To narrow down the list of prospective product trials to two or three, an organization can use a comparison matrix to prioritize and track requirements against the different solutions. Demonstrations need not be exhaustive, but there are key takeaways from each:

Does the solution work with the organization’s technology stack?
Does the solution does it have the ability to utilize specific functionality required by the software company, like a particular type of visualization?
Does pricing align with the organization’s budget?
How will the end user experience look?
What will the deployment process entail?

Additional questions might include:

Is there support for arithmetic operations like addition, subtraction, and aggregation?
What database support exists?
Is complete white labeling of the solution available?
Is it fully web-based, or do desktop dependencies exist?
Is there a user interface (UI) for administering tenants and mapping data fields, or is coding required?
How long before the solution is live?
What percentage of customers embed the solution?
What options for monetizing analytics exist?
What have companies charged for it?

Obtaining Value from Trials and References

The next step is conducting the software trial to vet the software against an organization’s key test cases.

The goal of the trial should be to create a core set of analytics deliverables — reports, dashboards, visualizations, and key performance indicators (KPIs) most important to an organization’s customers. The trial allows companies to:

Vet the embedding process and integration
Test how solutions handle user and database security
Determine support for multi-tenancy
Confirm compliance with regulatory standards like HIPAA, SOC2, or PCI

References from other customers using the same software version trialed, and in the same vertical and of approximately the same size are gold. Listening carefully to answers to specific questions can expose red flags. Use conversations with references to obtain clarity into issues that the demo only lightly touched upon, and determine how easy it is to work with the company. Suggested questions to ask include:

How long have you been using this product?
What were the major reasons for choosing this solution? What were your expectations? Has this product met your expectations?
How long did it take to embed analytics? Did you encounter any problems during the process?
Was your implementation on time and within budget?
How many end users are using the analytics solution?
Has the solution allowed you to monetize analytics in your application? What model are you using to monetize analytics?
Did the product require any workarounds?
How much internal IT support was needed for the project? How much support did the vendor provide?
Overall, how satisfied are you with the solution? Would you choose the vendor again?
Was there anything you wish you had known before implementing this solution?

Beta Testing and Phased Roll Outs to Identify Deployment Issues

In addition to trialing functionality and soliciting feedback from others, organizations should assess how well the solution will deploy on existing infrastructure. Organizations may require a scaling strategy, such as scaling up by upgrading hardware and memory or scaling out by replicating servers, adding load balancers or containerizing with a solution like Docker.

It is not easy to predict performance without knowing what to expect of self-service BI regarding usage. Many software companies opt for a soft launch of a beta release to one or two customers. Discounted pricing to beta customers is offset by the value obtained from their involvement in beta testing, which can address issues early on before they become system-wide problems.

Rolling out functionality in stages can help ensure stability. For example, by gradually introducing features, companies can identify potential stresses to application infrastructure from increased demand. Other companies may opt to deploy analytics as a standalone BI portal. A less robust, in-context analytics experience, this is the fastest approach to implementing analytics when speed to market is most important.

Avoiding Licensing Pitfalls

A product’s licensing model is an important factor in ensuring monetization of analytics. Organizations create value with improved analytics in one of four ways:

Selling enhanced functionality as an add-on
Winning new business
Retaining current customers
Reducing service costs

The embedded BI product selected should not lock a company into an unworkable price model. Scaling can dramatically influence overall costs. User- or session-based pricing models can reduce ROI as businesses grow and the number of end users expands.

Organizations should look for a licensing structure that complements the value derived from analytics, is easy to understand, and maintains transparency regarding costs associated as the application scales. When determining pricing, also consider proprietary software, infrastructure enhancements, and ongoing maintenance.

Contract Negotiations

A company’s flexibility and responsiveness during negotiations are excellent indicators of how a company will operate as an OEM partner. Lengthy, drawn out legal processes that outweigh moving quickly to address needs often foreshadow future implementation and services processes.

A list of recommended service partners and suggested service hours can indicate a solution’s maturity and how well it is designed for embedding. Look for a model based on shared value creation. A line item for a discount of any size should call into question the vendor’s commitment to a partnership. Showing a big number is often an attempt to sell value, and then an arbitrarily assigned discount indicates what they believe they can extract as a total cost.

Conclusion

The movement of self-service analytics from a nice-to-have to an application requirement need not be a burden for application development teams. With proper planning, product managers can ensure deployment of a rich analytics interface that helps end users gain more value from data, takes the report creation workload off developers, and allows opportunities for further monetization of the application.

Embedded BI Changes the Strategic Role of the Business Analyst

Written by Marcus Hodges on April 13, 2017. Posted in Articles.

The world of business intelligence (BI) and data analytics has existed for decades; what started as simple Business Analysis reporting in the late 1980s has evolved to today’s near real-time querying.

Departments rely on BI to make daily decisions, and at the highest-level organizations turn to BI and data analytics to make strategic business decisions that can dramatically affect a company’s bottom line and future direction.

Business intelligence is going through a transition. Its evolution combined with new capabilities provided by embedded BI empowers Business Analysts to serve a more direct, visible and strategic role in delivering analytics to organizations. As technology evolves to meet new market demands, departmental, and organizational needs, the functionality offered by BI and data analytics is dramatically evolving. This extends to change who manages BI and data analytics.

As organizations mature and become more sophisticated, business leaders realize that mining the data that already exists within the organization affords them opportunities to influence more effective strategic decision making.

With BI innovations, including new features, functions, and end-user capabilities, Business Analysts can also drive efficiencies with more timely data analysis.

BI Use Comes from Disciplines, Departments Across the Organization

Traditionally the information technology (IT) department was responsible for deploying and managing the BI solution, as well as fulfilling requests to produce reports and delivering them to end users, departmental level managers, and the executives who needed them. Once IT deployed the BI solution, the Business Analyst became the intermediary for end users and IT to develop reports and dashboards that met business objectives. Unfortunately, the process to meet user requests for new reports could take weeks.

Beyond serving as the IT and end user-intermediary, the Business Analyst historically had the pivotal role of dictating the processes and developing business systems, so the organization achieved its business goals. The role of the Business Analyst included:

defining business needs through detailed functional requirements
evaluating potential solutions to business problems
analyzing and evaluating business systems and user needs

Evolving Business Analyst Solutions Changing Roles

While the Business Analyst always worked with end users to understand and prioritize business goals and information needs, that role has now evolved to include understanding the analytics methodology for their organization. The Business Analyst translates critical objectives into the key performance indicators (KPIs) and metrics.

In many organizations, IT teams are resource constrained – having to do too much with too little, especially time. The evolution of BI hands more responsibilities to end users, who require greater and immediate access to real-time data.

With this shift, the Business Analyst has moved from the role of facilitator or gatekeeper working with the IT department and end users to a more strategic role. Business Analysts can now directly influence how business applications and their outputs are used by organizations to meet specific needs. In our fast-paced world, end users expect much quicker response times, and now the Business Analyst has become responsible for getting them analytics they need in real time.

Today’s Business Analyst is responsible for the following roles:

administrating the analytics experience for all users
managing data sources and access rights
creating and distributing reports, dashboards and data visualizations
performing complex analysis and implement change to improve organizational performance.

The Power of BI Today in Form and Function

Solution providers sensing this shift have responded by offering capabilities that make BI more than just a stand-alone platform. They are embedding BI capabilities in their applications to allow for self-service analytics. Available purpose-built embedded BI capabilities are becoming intuitive functions that end users access as part of their daily workflow.

An administrative graphical user interface (GUI) allows the Business Analyst to customize the BI and data analytics functions, enabling them to set up user roles and permissions. Through the GUI, the Business Analyst tailors the user’s analytics for departments and individual users.

The Business Analyst can also define data sources and blend data from multiple sources, other tasks previously handled by IT. Rather than relying on a database administrator (DBA), the GUI allows the Business Analyst to alias data fields as business-friendly terms – making analytics more approachable to the business user, thereby increasing adoption.

A powerful GUI and embedded BI functionality equips end-users with self-service capabilities to produce the reports, visualizations, and dashboards, which previously required engagement from the IT team and Business Analyst. The evolution of BI and organizational changes shift report writing and dashboard creation from the IT team to the end user.

Self-service BI empowers end-users and enables the Business Analyst to work as a true analyst, freeing them to create reports and dashboards to ensure the company follows its business model and makes effective strategic business decisions based on real-time data analysis. The Business Analyst can take learnings gleaned from analytics to better forecast and plan for the effects specific actions might have on the business. This makes the Business Analyst’s role more powerful, helping them play a pivotal role in strategic decision-making.

BI’s Evolution Makes These Skills Important for the Business Analyst

As the amount of analyzable data continues to grow, current and future Business Analysts may want to consider strengthening or adding to their skillset. There is certainly no shortage in the growth of data creation, capture, management, and analysis that will require such skills as:

Business Acumen – Understanding the industry and its KPIs to create value for the organization
Application Proficiency – Mastering the organization’s business application and its BI solution
UX/UI Design – Knowing where users need to utilize analytics within the business application
Report and Dashboard Design – Understanding what data and reports are relevant to the end user and utilize their eye for storytelling and knowledge of charting to identify the most appropriate visualizations, tables, and charts to help users find insight
Methodology and Business Process – Understanding the processes of the organization to identify opportunities to redesign for improvement and apply analytics to improve operational performance
Automate Decision-Making – Analyzing and determining which reports and alerts can be scheduled and automated to move users toward additional data discovery and insight

Embedded BI Aids BUSINESS ANALYST’s Strategic Role

The demand for interactive data has helped BI to evolve from a rigid technology managed by IT to a business requirement. Today’s Business Analyst deals with BI as a business function, not an enabling technology. The continued growth of solutions that empower the end user allows the Business Analyst to further cement their role as a strategic asset for the company. Where the Business Analyst once took on the role of a project manager, embedded self-service BI empowers the Business Analyst to shift that role Business Analyst to strategic analysis.