Great BI: It’s Not About the Tools!
How to Lead Your Team to BI Success
Where is your organization going with its data? Are there people in place who truly understand how to steward and leverage that information? And are you willing to recognize that there are problems? (Spoiler alert: there are definitely problems.)
Every BI team has its problems. Focusing on the tools as the source of these woes is a mistake. More often than not, the tools haven’t been applied properly to meet the organization’s functional needs.
In this webinar recording, Senturus Senior BI Architect Shawn Alpay provides the playbook to make you the leader your team needs to build out a solid BI foundation. Topics include approaches to good data governance, BI architecture, partnerships with gatekeepers and how to build a roadmap that meets your organization’s business needs. He also provides tips and tricks for how to apply best practices to business analytics. Plus, there are juicy anecdotes of the dysfunction he’s encountered in his years helping clients.
Technology isn’t the problem! Your team needs a thought leader—is it you?
Senior BI Architect
Shawn is well-versed across the entire BI stack. He has built ETL, data warehouse, reporting and analysis solutions from the ground up. In his various development and architecture roles, he often serves as the project manager and business analyst, partnering directly with clients to gather requirements and deliver insight.
▼ PRESENTATION OUTLINE 1
- Good business intelligence is hard
- “70-80% of business intelligence projects fail”— Gartner, 2011
- Failures are due to bad decisions, not bad technology
- There are often many “right” ways to do something in BI, but only true thought leadership will yield the “best” way
- What we’ll cover (and what we won’t)
- Business intelligence project phases
- Solution architecture
- Data model design
- Semantic model design
- Visual design
- Supporting structures
- Documentation governance
- “80% of project failures can be traced back to the scope definition process” — AMA Briefing
- Clearly communicate WHY we’re building a solution – and WHAT it’s supposed to do – on paper
- Management and designers jump into design without requirements
- Business requirements document
- What does it describe?
- Current lay of the land: what are the business processes we want to capture and why
- Functional requirements: system shall do X
- Non-functional requirements: system shall be Y
- Security, cost, availability
- BRD is a business solution document, it does not try to determine the technical solution
- BRD is not detailed enough (if it exists at all!), and more questions must be asked to start architecture and design
- Data is king
- Even though data modeling comes later, it informs every phase of our project – so involve it as soon as possible!
- Business matrix requirements
- What are the business processes we will measure, and how can we categorize them?
- High level plan that will be refined later
- Architecture and Design
- Imagine building a house without a plan (or the people who will live in it or the people who will build it)
- “Every day I spend designing is three days I save developing” — Monte Hansen, my first BI mentor
- Solution Architecture
- The business requirements document told us the business solution and we need to communicate the technical solution
- Address all requirements and use cases provided and recorded by the business
- This should be written in English
- Data flow diagram
- High-level illustration that shows components from a data/user perspective, not a platform perspective (the what rather than the how)
- Topology diagram
- Technical version of the data flow diagram: describes the how, when, where
- All servers involved (e.g. data warehouse is clustered with two nodes)
- Names, IP addresses, data refresh cadence
- Delineates between cloud and on-prem
- One diagram per environment (Dev, QA, Prod, etc.)
- Semantic modeling
- Metadata layer: measure definitions, business-friendly names, English descriptions of all attributes
- In the past, we might have called this a “cube”
- Business logic can be captured here (or in the reports downstream), but it should be pushed as far upstream as possible
- …But there are plenty of reasons why this might not be best
- Design example: where to define net sales?
- If we did everything else right, this is the easy part
- Without good design, all that work upstream is wasted
- These can be drawn without access to data and technology (although, technology will inform what we can/can’t do)
- Style guidelines
▼ PRESENTATION OUTLINE 2
- Data governance
- Framework for managing corporate data
- Why should I care about it?
- Data is messy because humans are messy!
- Example: product in forecast system but not in sales system
- Example: how do we want to categorize products?
- What does it do?
- Establishes the business as data owners and IT as data stewards
- Establishes data issues as cross-functional: these issues are everyone’s problem to solve
- Governance is a process, not a platform
- Don’t let process be a roadblock to progress
- Garbage in, garbage out: showing everyone the problem is sometimes the only way to kickstart solving it
- Responsibility assignment matrix (people)
- Who’s doing what?
- Responsible, accountable, consulted, informed, (quality reviewer)
- If the team is big enough, list groups/committees
- Who are your thought leaders? Do you have the right people in place to:
- Implement these ideas
- Provide guidance and dedication when things get hard
- Fight for ideas they believe in
- Business intelligence is much more of an art than a science… and you need artists on your team
- Where could your team change things?