Great BI: It’s Not About the Tools!

×

Shawn Alpay
Senior BI Architect
Senturus, Inc.

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.

Read more

×

0:13
Greetings everyone and welcome to the latest installment in the Senturus Knowledge Series today. Our topic is great BI. It’s not about the tools, how to Lead Your Team to BI Success.

0:27
First, some housekeeping items.

0:31
When you look at the Go to Webinar Control panel, you’ll notice that you have the ability to collapse and or restore the control panel using the orange arrow.

0:43
And, importantly, although all microphones are muted, you can submit questions via the questions section in the control panel. So enter your questions there. We monitor those questions, and to the extent possible, we will answer them here on the webinar.

1:01
Any questions that we are unable to answer during the live presentation, we will complete the question log and post it, along with the slide presentation and a recording of the video of the webinar. Which brings us to our next slide. And the first question that we get, always and repeatedly, as, Can I get the presentation slide deck to which the answer is a resounding yes? If you visit senturus.com slash resources, you’ll be able to find an extensive free library of past webinars, demos, white papers, et cetera, where you can also find the today’s content. So the presentation, the video, and the completed question log.

1:45
Our agenda today, we’ll do a couple of quick introductions, and then we’ll hand off to our presenter today to discuss how to decide how to structure your BI project around ideas versus the tools that execute on those ideas, And will then give you a brief Senturus. Overview, for those of you not familiar with our organization, will discuss some additional resources. And then I encourage all of you to stick around for the always valuable Q and A and wrap up.

2:12
So our presenters today, I’m pleased to be joined by Mister Shawn Alpay who has a BI architect here @ senturus.com, one of our foremost, Microsoft experts across the entire stack, certainly well versed in, in in, in this particular topic. I am your master of ceremonies here today, my name is Mike Weinhauer, and I’m our Practice Director for our Tableau Practice Solutions Architects and Software product manager for our connector products. Pleased to be here with you today.

2:45
And with that, I’m going to hand it over to Sean to discuss KPI. It’s not about the tools, Schon floor is yours.

2:52
Thank you very much, Mike. Yeah, like Mike said, I’m a Microsoft by architects, but I really want to downplay the idea of being well versed in one particular solution, one particular BI solution, even though I’m well versed in Microsoft. We’re going to be talking about some really technology agnostic ideas today. I really want to downplay the notion that our toolset will define how we execute on our projects and I’ll be reinforcing that idea several times as we go through our talk here. I want to start with a central premise, and I’m sure it’s something we can all agree with, which is that good business intelligence is hard to do.

3:31
OK, Gartner says that 70 to 80% of business intelligence projects fail.

3:35
Why is that?

3:36
Well, I would pause it that, in my experience, these failures are due to bad decisions, not bad technology. We’re all part of different organizations. And, yes, there’s overlap and how we execute on core BI ideas. But, the needs of every organization is going to be different and your situation is going to require someone thinking outside the box. Perhaps thinking about the solutions that pertain to your organization uniquely.

4:06
And so, another point that I want to make here is that, there are often many right ways to do something and BI, but only true thought leadership is going to yield the best way.

4:16
There are, so many tools that might be able to help you solve a particular problem your organization faces. But unless you have people filtering those possibilities through the lens of experience, then you’re not going to be able to yield the best solution, Right? So, how, how do we, How do we do that, right? I want to filter that question of how to execute well on a BI project through the lens of phases of a BI project. Typical phases of the PI projects, all right? So this is what we’re going to cover, and then we’ll also tell you what we’re not going to cover.

4:51
So, the phases of a BI project, we’re going to talk about Requirements. This is where everything starts. Obviously, what’s the business solution? What are we trying to do? Like? What, what’s the data we’re going to present? How are we going to present it right? We have to do that well. And that’s going to then flow into solution architecture. How are we going to build a technical solution, a logical structure of physical structure that’s going to respond to those requirements? And then once we’ve got that, how are we going to model the data in a database, or a data centric structure of some kind. And then how are we going to organize our metadata, or the data about the data in a semantic model, like English business, descriptions, and measure, definitions, and et cetera? Right.

5:33
Once we’ve got that, what are we going to? How are we going to design our visuals that are based on that? And what are the chart is going to be, what are the graphs going to be? What are the, what are the colors, et cetera. Right?

5:44
These, in my experience, are the biggest pain points in a BI project. This is where I have seen in BI projects.

5:52
Either get off the rails and get delayed or fail completely because there were not people making the right decisions in these phases.

6:03
And any dysfunction that is implemented in a project in, in, in this part of it in the front end will lead to issues on the backend. And those are things we’re not going to talk about today. But things like development and validation and QA and training and rollout. These are obviously incredibly important components of a BI project, but we’re going to focus on the front half on these first five things and, and the execution, theoretically of development. And training and all that should be straightforward based on the decisions, the heart of the decisions that were made upstream. And of course, we have, yes, there are nuances of how to develop well, but that’s not going to be the focus of our talk today.

6:49
So, what are the structures? What are the supporting structures we need to have in place in order to execute on these phase as well? Well, first of all, of course, is documentation. This is so important. If we’re not all singing off the same song book, then we’re not going to be able to execute well. So, communication is so important, and documentation as a place is, is, is a foundation to that communication.

7:11
So, while I won’t be spending any time talking to a particular slide on documentation, you are going to see this icon scattered across by other slides, the other phases. And whenever you see this, it’s going to represent a particular pain point that I’ve experienced with a particular artifact that I would encourage you to put pay particular attention to. I will not be calling out exactly every document that needs to come out of a BI project, but I will be pointing out the ones that I have seen done poorly over the course of my career.

7:45
What else do we need? We need governance, what is governance? It’s, it’s a framework by which we’re going to manage our data and it can be a very big squishy topic. I’m going to try to keep it as I’m as focused as possible, but we need a mechanism for talking to the business, for organizing the business. Getting people to champion our data. Solving governance is solving data quality issues. We need that in place or else our project will fail.

8:11
What else do we need? We need the right people in place, and I think I’ve already started to tell that story to you, right?

8:16
We need proper people and the proper roles serving the proper responsibilities in order to execute on each of these phases, right.

8:25
What are we not going to talk about? We’re not going to talk about technology again, I’m very well versed in Microsoft, Microsoft AI Stack, and I understand like, Power BI and SSRS. extremely well, but we’re talking about technology agnostic things. Even though I’m a Microsoft BI architect, a lot of what we’re talking about would add value to, any project. Doesn’t matter what technology you’re implementing. So I want you to, it as we go through this really downplay your particular technology solution and focus more on the decisions that go into the technologies we use and how we use them, OK? And the broader question I want you to have in your mind as we step through this, is, where does your organization need better thought leadership in each of these phases? I want you to be thinking, Oh, we do that well. Oh, we maybe don’t do that super well. What can I change about how we’re operating in our project to be, to add more value to the organization?

9:23
So, let’s start with requirements. Here’s a comic from Dilbert you can read through.

9:30
But, 80% of project failures can be traced back to the scope definition process. And I can’t stress enough how often I see Scope, not well defined and not printed on a piece of paper that I can read myself and share with others, right? We need to clearly communicate why we’re building a solution and what it’s supposed to do, and it has to exist on paper. I can’t tell you the number of times I’ve interacted with, with business analysts or other folks who have a lot of institutional knowledge in their heads, and it’s all really great information, but I’m tasked with extracting it from them. And they have not gone through the really important process of putting it down on a document, or a set of documents. They can then share with me as a solution architect, I often would like to receive such artifacts.

10:20
But I’m tasked with helping the analysts upstream from me sketch out this documentation. And I can’t profess to be a business analyst, but I spent a lot of time with BA’s PSAs and understand what I need to receive from them and can coach them into saying, OK, here’s how we’re going to, to, to flesh this out.

10:40
What we see in this comic here is that the director saying, hey, we don’t have time to gather requirements. We just need you to jump to design. And it’s a two-way street.

10:48
The manager saying, that’s what we’re going to do, but then the designer saying, pretty much, yeah, that’s fine. People are often willing to jump into design without requirements and that’s a problem both from the management side and the designer side, we need to challenge this idea that we can just go to our next phase without clearly communicating what the requirements are.

11:08
So how do we do that? Well when I, as a solution, architect, I’m looking for something that resembles a business requirements document or a BRD. And this term means many things to many people. What am I looking for in a BRD as an architect? I wanted to say the currently at the land. What does the business processes were wanting to capture and why? What, I mean, I don’t want to go super high level, and say, what’s the business about? What does a company trying to do? But, I do want a data centric story to be told of, here’s the events that we’re going to capture, and, here who we are: going to present it to you. And, here’s why we care about this: Here’s what the value proposition is for going through a project. Like this, right? I need that context. I can’t just jump into, let’s build a database, right?

11:54
Need to understand what your business is doing and why it’s doing it, OK? And that then decomposes into functional requirements, OK? So system shall do this. And in the case of a BI project, that’s data, and that’s use cases. So, what is the information I’m going to present, and, and who’s going to consume it, and how are they going to consume it, right? So, this is what the system is going to do.

12:17
And then I’m also looking for nonfunctional requirements. So, the system shall be like this. And this is everything that surrounds our functions, right? Like, this is the data access and security, right? This is cost, this is availability. This is how often the data’s going to get refreshed. This is the granularity of data, et cetera, and right? Like everything that surrounds the actual data and how it’s going to feel to the user, right? That’s what I’m looking for here.

12:45
In essence, a BRD as a business solution document and it doesn’t try to determine the technical solution. I can’t tell you the number of times in a BRD I’ve seen, we’re going to use this platform that that’s not a business solution it. It’s going to like it’s relevant but we’re going to save that answer for our architecture, OK? We want to describe from a technology agnostic standpoint in this document. What is it we’re trying to do, right? In my experience, this document is often not detailed enough. If it even exists at all, right, and more questions must be asked, from the point of view of the architect and designer, to start those phases, right. Like I said, I’ve often been tasked with partnering with the analysts to say, OK, what is it that you want to do, and then put it in a document that can be signed off and then can be built from, right? Because that’s going to inform everything downstream.

13:37
So when it and data is the most important functional requirement that I see not sketched out completely. And so what we often start with from a data centric perspective, because data is king, right. This is a picture of data from Star Trek: Next Generation, please forgive the pun here. But even though data modeling is going to come later, during architecture and design data, informs every phase of our project. So, we’re going to involve it as soon as we possibly can. So, we’re going to push that work upstream into this requirements phase. And how are we going to do that? We’re going to leverage an artifact that we call the bus matrix. So what is the bus matrix? It’s essentially going to help us answer the question. What are the business processes we’re going to measure, and how can we categorize them, right?

14:27
What are the all the events that we care about that are happening in an organization? And then how are we going to be able to, to categorize or slice that that information. The bus matrix looks, something like this. This is an example for a restaurant chain, OK? So what I have here, our business processes as the rows. So sales, discounts, payments, inventories, right? Everything that’s happening in this organization. And then across the columns, here, I have, how am I going to categorize that information? And I have an X where those things intersect. So, for instance, sales can be sliced by date. And by date, I also mean week, I mean quarter, I mean, year. Anything that pertains to time, right? And by location, I mean, perhaps the store, but also the region, and the district, and the zone or however you organize your organization in your field, right? And so on.

15:19
Employee and customer, and products, and there’s, there’s other dimensions here that may not be applicable to that particular business process.

15:26
Like, we can’t slice sales by payment type, alright? But we can size or payments by payment type. So, we won’t walk through this whole thing, but this gives you a feel for what we’re trying to do. This is the output of our conversation that will have all the analysts to say, what is it you actually care about? What’s the story we’re trying to tell?

15:45
Most importantly, this is high level. This is very conceptual. We’re going to refine this later in the data model process. We’re going to decompose this into a logical and then eventually physical structure, which we’ll talk through. But at this stage, we’re just collecting information. We’re just trying to it’s kind of like a cocktail napkin. We’re drawing out, at a high level, what’s the story we’re trying to tell and we’ll get down to brass tacks later?

16:08
OK, that brings us to then, architecture and design. Theoretically, now, we have the artifacts that we need, in order to turn the key on this phase. And I want you to imagine being an architect, and imagine building a house without a plan, right? Or the people who are going to live in it, right? Which is to say the people who are giving you your requirements, or the people who are going to build it. Which is to say, the designers, and the developers, and the people who are going to actually execute on your idea.

16:35
As an architect, you have to definitely speak multiple languages. You need to be able to talk very In very business language Perhaps squishier terms or higher level abstract ideas, and you need to be able to convert that over into ones and zeros into programming languages into Particular structures that are going to live on a server, right?

16:58
You need to be able to look upstream and downstream and Interface with both of those groups, and I want to make sure you understand that there’s an overlap between those functions between these phases, right? We may need to go back upstream to get clarification and the people downstream from us may need to look upstream to ask more questions, right?

17:21
I want to make the point that this may feel like a waste of time like that manager and the Dilbert comic. We don’t have time for this, right. We got to just jump to design, but I promise you that this is going all the time that we spend in, this phase is going to save so much time in later phases. And I want to relay to you. An anecdote that comes from my very first summer as an intern, right out of high school, that has stuck with me for a long time. I was a kid. Just out of high school, I hadn’t ever spent any time writing any code, or spending any time doing IT things.

17:53
And there was one guy on the team by the name of A Monte Hanson and he spent his whole summer poring over entity relationship diagrams and printing things out, putting them on his cubicle wall, and having meetings with users, et cetera. And I didn’t see him write any code the whole summer and near the end of the summer. I come to him and I say Money. What do you what are you doing, and why don’t you just want to write some code and he says Sean, I would like more than anything to write some code, but I promise you, and this is the quote every day. I spend designing is three days I save developing and it really didn’t quite get it at the time, but now so many years later, I look back on that, and, and, and I see how right he really was. And I really encourage people to pump the brakes and makes sure that we have well defined everything in this phase. In order to make the job of the person downstream, which is to say execute or make their lives easier because I’ve been there.

18:50
I’ve been them and I, I know what it feels like to be getting incomplete descriptions of what we’re trying to do in this phase, OK? So what am I, as an architect wanting to build in this phase?

19:02
I encourage people to write an architecture summary and what is in this document? Well, if the BRD told us the business solution, we need to communicate the technical solution. I like to think of this document as a response to the BRD. It’s going to be drawing bright lines back to the requirements and the use cases that were provided and recorded by the business. So how are we going to present that data? How are we going to respond to those nonfunctional requirements? How are we going to fulfill the use cases that were that were detail, right? And I think it’s important to write this in English. Yes, we’re going to have technical documents later that describe our topology, and our Dataflow, et cetera. But I think it’s really important to have a document that an analyst can read and say, hmm, hmm, and yeah. Technically, that’s going to make sense to me. Like, I may not understand this, the server configuration, and these IP addresses, and whatever. But I can read this, and I say, Yeah, this feels right to me.

19:57
So that we can get approval, and we can avoid spin later when the business analyst finally gets their hands on first version of the, the data structures you built and the visuals you built, and they say, hey, that’s not what I wanted! Right. If we could, in this phase, get them to sign off on things and feel better about what they’re going to eventually receive after development, then, hopefully we’re going to save a lot of time. A lot of money, and a lot of wasted effort, right.

20:24
All right. So what, what are some other artifacts we want to create during the solution architecture phase? We definitely want a data flow diagram. And this is a high level illustration that’s going to show all the components we need from a data perspective. Remember, we’re staying very data centric, we’re not talking about platforms yet, we’ll get to that, right. But we want it in, in a one page document. Visio, diagram, or whatever. Tell the story of the Dataflow, right, like, what is it whatever the business processes we care about, like we said, and how are they going to get to the end users? So from the, from the left-hand side, we’re going to start with the people who are executing business processes, which then decompose into these systems of record, Right, Which then there’s going to get into our data warehouse and go into our metadata semantic model and then get into some sort of analysis visualizations to these use cases, Right? We’re drawing lines back to the BRD.

21:19
Right, this is our flow of information. And then, from this high level illustration, we can then start to decide, how are we going to organize this, this logical idea from a physical perspective, right?

21:32
Topology diagram is going to be basically a technical version of that Dataflow diagram. It’s going to start describing the how, the when, the, where, the servers that are involved. Like, for example, our data warehouse might be in a cluster, might have two nodes. We didn’t have that in the previous diagram, right? We don’t care about that. Logically, it’s just a data warehouse physically. Maybe it has two nodes, right, and that’s going to be really important. For a sysadmin a DBA to know that information, we’re going to communicate that clearly.

22:01
So this is where we have our names or IP addresses are data refresh, cadence, et cetera. We may delineate. If it’s important between our Cloud infrastructure, and our on prem infrastructure, we might have more than one diagram per environment, right? Sorry, or one diagram for environment. So we might have one for Dev. I have one for QA for prod, if those are meaningfully different, Right? So, so we can look at this and say, OK, great. This is our physical instantiation of this logical idea that we conceptualized earlier, right? We’re flowing through those ideas of conceptual, logical, down to physical.

22:37
All right. So let’s move on to data modeling. Now that we have these artifacts that have sketched out our solution architecture, we can start to figure out what we’re going to put into that solution. In the top left here. It is an eye chart but it’s our bus matrix from earlier. Right? This is whether this was our cocktail napkin during requirements. And we’re going to take this, and we’re going to actually figure out, how can we instantiate this in a database like with actual fields and data types, et cetera.

23:03
So, we’re going to take this, and from this, we can create our conceptual model, right? This is a typical, very simple, what we call star schema, right? Which is to say, we have our business process here, in the middle, and then we have our, our dimensions are entities.

23:19
We’re going to categorize that information here, on the edges, forming what it kind of looks like a star, right? So, here’s our conceptual model. We don’t have any attributes here yet. We don’t have day, we quarter year, and we don’t have our measure names.

23:34
We’re going to do that next, right? From, from this, we’re going to then say, OK, let’s categorize all those attributes into our entities, right? And, that’s going to inform, then, our Logical model.

23:44
Which is the same set of structures, right, same number of objects, but now we’ve defined our day, or month, and our items sold in our store description, et cetera. Right? Once we’ve gotten this, then, we can start saying, OK, how are we going to put this on a database? Now? We need to start adding database friendly names and data types to then that decomposes into this, right? You can see that. There’s a lot of overlap between these three things. And, so, I’ll show you this. Here’s many features we look for in Data Model, and then Conceptual, Logical, Physical. And we won’t step through this right now, but it’s in the deck. You can refer to it later.

24:20
But there’s overlap between these ideas, but we’re driving towards handing something off to someone who can then actually build, A database, actually instantiate something that we can then leverage downstream for our metadata, for our visualizations, that, we can actually populate via, extract, transform, load processes. What have you write?

24:43
So from our data model, then we move into our Semantic Modeling, and what is semantic modeling, It’s our metadata layer, it’s data about our data, it’s measured definitions, business friendly names, English descriptions, in the past, we might have called this a cube. That’s parlance you may be familiar with. But we really like to call this a semantic model to tell the story that we’re capturing a lot of metadata here, right.

25:05
This is not the place that we start defining those things, but it is the place we’re going to capture those things. Hopefully we will have sketched out during requirements. Everything we care about Right in terms of measures here’s where we’re going to actually define it, right? Our business logic can be captured here, right, but it should be pushed as far upstream as possible, like for example, if we’re talking about net sales, right? We may want to calculate gross sales minus discounts equal’s net sales. Right? Where do we want to put that well, we might put it in the semantic model but, and maybe we’ll start there, but there are plenty of reasons why we might not want to push our calculations as far upstream as possible. Right, so here’s a design example. Let’s say we’re trying to figure out in the where are we going to put in that sales? Is it going to go into the data warehouse is going to go into semantic model and the visualization layer. Let’s, let’s pretend we want to define our gross sales minus discounts in the visualization layer.

26:04
Well, we can do that. We could physically do that. But then we don’t have the ability to execute on any use case that says, hey, I have something outside of the visualizations. That’s coming from the semantic model that I want to be able to house net sales.

26:18
Which is to say, have a single version of the truth, that everything downstream of the semantic model is able to leverage that.

26:25
So let’s say maybe we define that sales and semantic model. Well, then. What if we have a use case that says, I want to have net sales coming out of the data warehouse? Not the semantic model, right? So, this is where we need to look back to our business requirements and say, what’s the best way to design this? This is a great example of technologically. There are many quote unquote good answers, but we don’t necessarily have the best answer until we have a great understanding of our requirements, right? So we want to be looking upstream to, to our business requirements, to figure out how far upstream. We want to push our business logic, which we are going to present then to our users. Right?

27:04
Moving on to visualizations, OK, I want to make the point that if we did everything else right, so far, this is the easy part. This is obviously what’s going to be facing users. And so it is something that I think people jump to and worry the most about, but I feel strongly that, if we had good business requirements, good architecture, and good design sessions. Once we get to visualizations, I don’t want to trivialize it, but hopefully, we’re just dragging and dropping the model we’ve created in our visualization engine.

27:36
And it won’t be that hard, right? It won’t be that difficult to leverage the information that we have structured well, without good design. All that work upstream is wasted, so we still need to figure out what this visualization or set of visualizations going to look like. And if we don’t this, I mean, this is the last mile between all that good work we did, and the user. So, if we don’t apply good design principles, then we’re not going to be able to leverage the good work we did. And because, I’m a musician, and an audio engineer in addition to being a business intelligence architect, I want to present to you and musical metaphor.

28:13
Imagine that you’re recording a song. And you are using all sorts of really great tools and technology. Like for instance, you’re using a vintage German tube microphone and some Mike trees. Compressor. And converter and a great computer is going through a console, all this stuff costs so much money, and it sounded really good.

28:32
And then the user, the end user, which is to say, the audience, your fans, buy a 99% MP three. And then they listen to it on $12 earbuds.

28:41
It doesn’t matter, all that good work. All that costly work you did is wasted because the pipeline, the way in which it’s getting into the ears of the listener, is bad, right, and, and bad. Visual design is very similar to this musical idea here, so we do need to apply good principles, even though I said this is not maybe the easy part, we still need to apply good, fundamental design principles.

29:06
So what are those?

29:08
Well, first of all, we need to have some mock ups or some wire frames, we need to be able to, independent of our technology, be able to describe, from a requirement standpoint, what we want these things to look and feel like. And it will be a partnership between the, the, the developer and the designer, and the analysts. But we need some mechanism independent of Power BI or Tableau to be able to say, hey, here’s a story I want to tell. Here’s how I want to structure that, and there are plenty of great tools out there. Here’s an example of a tool called mockup Tiger, which is you can get it online It’s not that expensive, but you can then design your spreadsheet, your reports, your dashboards without worrying about whether technology can build this kind of graph or chart.

29:53
These can be drawn up without access to the technology and also the data, because people often say, Well, I want to be able to get that information before I start signing. But I really do feel that before you actually have that information at your fingertips, you can go through this exercise. Although, yes, I will admit, technology will inform what we can and can’t do. Right? As a Microsoft architect, I can I’ll be the first to tell you that Power BI, as a visualization platform, is changing all the time. It’s maturing quickly. They’re releasing new versions every 30 days, and it may or may not be able to do these things. We put in our mockup. But we need to be able to have that conversation because we want to design from our ideal and not necessarily what the technology can do. I want to work from ideas to technology, and not the other way around. I think that’s really, really important.

30:43
All right, what else do we need in the visualization? Phase: Well, we need some style guidelines, right? We need to know what this is going to look and feel like, and we need some, some standards, Right? Because there’s so many fonts. There’s so many colors, so many sizes. We need some sort of color palette and typography, right? But on top of that, we need some best practices of do’s and don’ts of how should a graph or a chart look and feel. On the left here, we have a way in which you could organize your information, and, on the right, we have a better way of presenting that, same information. And we want to be able to say, in every visualization, we build where applying these principles, these, these standards may or may not exist in your organization, depending on your size. But I have found often that an organization at least has some sort of brand identity, if not full, on chart and graph style guidelines.

31:37
But often they do. Like, I’m working with a client right now, who I was able to take this information from, from their design team, and they made that part of the process. So much less painful. Because I was able to then slot in the reports we’re building to have it look and feel like they’re larger framework that fits inside their larger organization.

32:00
OK, so let’s move on to Data Governance
.
32:02
What is Data Governance? Like I said earlier, Data Governance is a framework for managing corporate data and this could mean many things to many people, right? But, why do I care about data governance? Essentially, at the end of the day, data is messy, is because humans are messy. All the business processes that we’re going to be measuring and stewarding in our solution are going to have data quality problems.

32:28
Because every set of data that we ever have had, right we’ve ever created, represents what humans do, and humans make mistakes and humans sit outside the bounds of databases, the rules of databases. So we’re going to have data quality problems. Also, data’s going to be recorded by people who make data entry errors, so we have to enter into a data governance conversation, assuming we have data quality problems, data quality issues, how are we going to respond to those. What are a couple of examples?

32:58
Let’s say I have a new product for my company, and it’s in my forecast system. Because I’m forecasting for it, but it’s not my sale system, because I’ve never sold it before. Well, which one of these is my master dataset for products? Am I managing it in the forecast system? Is am I managing it in the sales system? Are those integrated or are two different groups of people managing them, and then are they starting to diverge in terms of their data? And therefore the quality of the data. How are we going to keep these in sync right? That’s a classic data governance question or how am I going to categorize these products.

33:31
It might sound like a simple exercise of building a product category to subcategory data products, but, um, I may not have the same organization in operations for products that I might have in marketing, or in HR, or whatever, right? Or in finance. So, I’m going to need to bring all these people together, and have them have a conversation. Can they coalesce around a single product category categorization, product hierarchy, right, another classic data governance issue?

34:01
So, what are we going to do, and Data governance? Well, we’re going to establish the business as the owners of that data, as the owners of those problems. IT is going to be stewards of that information, right? Often, I see did IT is holding the bag with ownership of data because they’re the ones who built the systems. But how’s IT going to know how to categorize products? How IT going to know exactly where we’re going to, which is our master dataset, we need to partner with the business, and further, we need business, the business, to own that problem, right? And then IT can respond to that with technology, with a technical solution, Help facilitate the solutions that the business comes up with. It might seem like a small nuance, but it’s so important. And I’ve seen projects fail because this, this ownership problem is not solved.

34:50
What else are we doing with data governance? We’re establishing those data issues as cross functional when we’re trying to categorize that product hierarchy, right? We need operations, and in finance, and all that, all those teams at the table, this is everyone’s problem to solve. It’s not just an operational problem, because it’s the datasets coming from operations. We need, we need everyone to feel like they have a stake in the solution here because ultimately, everyone’s going to be consuming the same data, because we want a single version of the truth, Right?

35:23
Governance is a process. It’s not a platform. I’ve seen a lot of technology solutions being sold in the marketplace that say, this is a data governance platform is going to solve all your data governance problems. And that’s just not true. It’s just not going to happen. I have yet to see a platform help solve for a process, Right? Well, it solves for process. It doesn’t, it doesn’t define the process for us. We need to go into governance, establishing a process, and then any platforms we leverage can help us execute on that process, right? Again, ideas into tools and not the other way around.

35:58
All right?

35:59
All of that said, I think often people see this data governance process as a roadblock to progress, and we don’t want to do that, right? It may be that the best way in which to help kick start data governance, data quality, and issues, to explain the problem is to, in your first version, maybe apply a garbage in, garbage out, and philosophy. I’m going to just give you your data in its bad state, and then this is going to help illustrate the point that we need to put together, perhaps, some data governance teams to help solve these kinds of problems.

36:32
What are the teams that we need to execute on these ideas? I’m going to walk you through.

36:38
The teams I put together for a client that’s roughly $2 billion Company, and your organization may be larger or smaller, but just know that this is roughly what I went for with this group, and you can scale for your organization. First of all, we start with an executive steering committee, this is, this team is focused on culture, and these are our data champions. These are the people at the top of your organization who are going to help their, their direct reports and those people’s direct reports, and so on.

37:08
Focus on the tasks at hand, Take it, seriously, change the culture of the organization to drive around data governance. Right?

37:15
In my experience, this was five executives, senior vice presidents. I had the CFO on the team.

37:21
This was cross functional for sure, and these people were helping me make sure that their direct reports were taking seriously, attending the other team which we’ll talk about in a second, helping resolve any issues, making sure that funding was secured, et cetera. Right. This team I had them meeting monthly, Sometimes it slipped to every other month, but ultimately, they took it really seriously what we were doing, and it was, we always had enough to talk about to justify meeting on a monthly basis. If they, if the organization already has some sort of data governance framework, that you can slot into great. In this, in this example, I had to carve this out from scratch, so it ended up being that. There were a lot of other things they wanted to talk about, other than the agenda that I was bringing to the table.

38:09
Second, team, data governance committee.

38:12
This team is comprised of vice president, director level people. I had roughly 12 people attending this meeting. They’re focused on strategy. What are the problems, and how are we going to help resolve them? And they’re going to make sure that the individual contributors in the next team we’ll talk about are actually able to turn the key on these solutions. They’re going to be ingesting the problems that are going to bubble up from the subject matter experts and they’re going to be prioritizing. They’re going to be resolving issues, they’re going to be focused on strategy.

38:41
Whereas, the third team, which is the business users, right? They’re going to focus on tactics on actual, like, doing the work. In my experience, this was about 30 people in small groups, I never organize them all at once. It would be two people from HR, three people from marketing, to people from finance, et cetera. Who I would meet with on ad hoc basis, to make sure that they could execute on the decisions that were coming out of the data governance committee, and if they discovered new issues, bubble them up to the data governance committee, right? That’s why we have bidirectional arrows here.

39:14
These teams are, are, are in communication, that orchestration between those three teams is being executed by the project team, which is to say, folks in IT. In my experience, this was about 15 people. This was the PM and it was the architect and Modeler and release manager, et cetera. Right? These people are helping the other three teams communicate there. They’re collecting information from those teams, et cetera. This is a partnership.

39:43
All right, that brings us to people.

39:47
All right? I want to tell you about a book that I read a couple of years ago, which has been very important to my growth as a consultant.

39:55
Has written in the 19 eighties by a fellow, by the name of Gerald Weinberg. And it’s called The Secrets of Consulting. And it has so many good tidbits in it. I cannot oversell this book to you enough.

40:04
But the quote that sticks with me the most in terms of when we talk about people and roles and responsibilities, is this quote you see on the screen, no matter how it looks at first, it’s always a people problem. People love to say that it is a technology problem, and the more that they insist on that, the more that I always know that it’s a people problem, We, if we don’t have the right people in place, in the right roles, serving the, right. Responsibilities. Everything, we’ve talked about so far will fail.

40:31
And I promise you, I have seen PI projects fail, because there were people confused as to what they were doing, people, not in the right place at the right time, and being roadblocks to our technological progress, all right, how do we avoid this? Well, I would encourage you to focus on team roles, right? Well, we see here are, across the rows here, we see, flowing from our context to our concept and implementation.

41:01
And across the columns here, we have business application, information, technology, and it really, it’s trying to stratify the many roles that we carry on a project team into buckets that, yes, have a little bit of overlap. But let’s think of each of these roles independently. Even if we have people, one person serving multiple roles, Like, for example, I’m often hired to serve in this sweet spot here of Solution Architect Information Architect very often Then tasked, even though I wasn’t told to serve as the business architect, like, how are we going to take our business requirements and ingest them and inform our solution architecture, right? Depending on the size of the project, I might be serving in multiple roles. But I always think of those roles separately, OK, so once we’ve defined our roles, then we can start figuring out how are we going to slot people into those roles? What are the tasks that we want to be performing, and what’s the way in which we can go through the exercise?

41:59
I would encourage you to become familiar with a Responsibility Assignment Matrix, or you may have heard of as a racy matrix which stands for our ACI, which is this is kind of what it looks like. You. You’re saying, who’s doing what? We’ve got people who are responsible, Accountable, consulted, informed, optionally, you can include a queue for quality reviewer, but Responsible is whose going to actually be executing on this task, right? You can have more than one.

42:26
Accountable is who’s going to make sure it gets done. You only ever have one for a given task, and then you could have multiple people who are going to be consulted in order to have the responsible party execute on that idea, and then people who are informed of the outcome. Alright. So, this is just an example of tasks and people, and if your organization is large enough, you might list groups or committees as well, but I find that listing specific people as isn’t really helpful exercise.

42:57
So, given all of that, I want you to be thinking, who are your thought leaders? Do you have the right people in place to implement, all of those ideas. Provide guidance and dedication for and all these. All this stuff gets hard. The people who are going to fight for the ideas they believe in. I feel. So, strongly that business intelligence is much more of an art than a science. And you need artists on your team, right. You need people who are going to be willing to think outside the box, people who are willing to push back and challenge the decisions that are coming upstream from them, and make sure that they can partner with the people downstream from them.

43:33
This is very much, we’re painting a picture with our story, right? It’s not just, yes, it’s going to finally decompose into ones and zeros and database structures and what have you? That is the results of our thought leadership, Right. It is. It is not where we start. And people jump so quickly.

43:51
I hope that, if there’s one takeaway that you have from, from this talk, is that people jump so quickly downstream, where we need to focus on making sure that we made the right decisions upstream, all right? And that requires us to be able to respond to unique challenges, unique situations. And that can only come from people who are true, true thought leaders.

44:15
So, I’m going to jump back to this first slide that I showed you. I took off the stuff we didn’t talk about, and I want you to walk away from this talk, thinking, where could your team change things here? Are the project phases of a BI Pro there? The phases of a BI project here are supporting structures. Which of these things do you think your team does? Well, where are things that you could invest value in your organization, what things could, could benefit from a change, so that, that’s where I’m going to leave you.

44:43
And, and I want to promise you, I recognize that these kinds of projects are difficult. They can take a lot of time. They require a lot of energy.

44:54
And we need to be introspective about how we can change our process, change our thoughts, and in order to better execute on the technologies, that we, of course, need to be extremely well versed in in, in, in building business intelligence.

45:11
So, thank you very much for, for sticking with me through all of that. If you have any questions, write me, this is my e-mail address, .com. If you have any particular questions or situations of any of those phases that we talked about, any of those structures we talked about, please feel free to drop me a line and I’d be happy to chat with you on this stuff that I hope you could recognize that this stuff excites me. And I feel like I have a lot of battle scars and we can trade war stories and chat about what might be a challenge for you in your organization. So feel free to do that.

45:48
That’s cool.

45:48
Yeah, with that, Yeah. Thank you so much. That’s some terrific comment, some terrific content. And those of you, on the line here, please stick around. We do have some, some good questions and discussion to occur here towards the end, so give me just a couple of minutes of your time.

46:04
You know, I think, as you said, these projects are really, they’re, they’re, they’re very complicated, they’re also a vital importance to your organization, right. They still, analytics. Projects still rank among the top priorities for any organization. And if I were to sort of summarize what Sean was talking about here, I’m reminded of one of my favorite Senturus Construction analogy approved quotes, from Frank Lloyd Wright, where he says, you can either use an eraser on the drafting table, or a sledgehammer at the construction site. And I think it really, you know, you see, all too often people rushing towards the, let’s implement things.

46:40
Or perhaps even worse, is they choose the technology and let the technology drive the solution that gets created.

46:47
The point here really is that these projects really transcend technology and need to start from these, these business requirements and that’s tough stuff and that’s you know, Sean has the battle scars, so does the entire team here at Senturus and that’s a great asset that we can bring to bear for all of you.

47:07
And I was particularly struck by your one comment you made where this is an iterative process, and too often, we see projects on timelines, and we drive down those timelines.

47:17
And you don’t see, kind of loops back to, you know, maybe we go down a path and it doesn’t bear fruit, and we have to go back and ask some more questions and, and, and iterate. So that iterative component is really pretty big. So, anyway, stick around for questions here. And I’m going to run through a quick few slides on who we are at saint Tourists can go to the next slide here.

47:38
So, we are business analytics consultants, who are known by our clients, for advancing the state-of-the-art, our clients know us for creating clarity, out of the chaos of myriad data sources, complex business requirements, and constantly moving targets.

47:53
Our strength really lies in bridging that gap between IT, and the business users, and the value that can be derived from all those myriad’s source data systems to make better decision.

48:05
We give you reliable, analysis, ready data across your organization, so you can quickly and easily get answers at the point of impact, the decisions you make and the actions you take.

48:17
Our consultants are top notch experts, the likes of Sean and others on our team. They all have years of Pragmatic, real-world experience and experience advancing the state-of-the-art.

48:28
We have pillars in dash boarding reporting and visualizations, data preparation, modern data warehousing, self-service business analytics, Salesforce reporting, big data, advanced analytics, as well as planning and forecasting, as well as some proprietary software, including our Analytics Connecter software that allows you to connect.

48:47
Things like Tableau and Power BI to your Congo’s metadata and reports were so confident in our team and our methodologies, some of which is outlined by Sean today, that we back our projects with 100 per 100% money back guarantee.

49:02
If you’re tired of, you know, if you’re, if you don’t want to be one of those 80% failed projects, and you want to achieve greater than the industry average, 25% adoption, it’s a good idea to talk to the folks here at Senturus.

49:15
We’ve been doing this for a while, we’ve been doing this for over 18 years.

49:19
If you want to go to the next slide, Shawn, we have over 1200 clients.

49:23
You may recognize many of them from the slide below, across 2000 plus projects.

49:28
So we’ve touch just about every vertical industry, and most of the lines of business. We’ve solved business problems across the office of Finance, sales and marketing, manufacturing, operations, HR, and IT.

49:39
So, if you need someone to help you with your next analytics project, whether it’s requirements gathering, architecture, and design, all the things that Sean was talking about through to the actual implementation of those and data repositories.

49:52
And, or front end content, upgrades, migrations, performance optimization, and tuning, and, of course, training, then Senturus should be coming to the front of your mind.

50:03
Some additional resources, before we get into the Q&A here, we have an upcoming event, a comparison of Power BI, Tableau, and Cognos. The differentiators demonstrated that’ll be on Thursday, February 28th, 2019. From 11 to 12 Pacific Time, you can register for that at saint tourists.com/events.

50:27
And wire over there, you can visit the Senturus’s resource library and blog. If you go to senturus.com/send tourists resources, you can visit our blog, which is a great place to find out what sort of top of mind here at Senturus, and nice, bite size, easily consumable chunks. And, you can find some great resources, past webinars, demos, white papers, presentations, et cetera, et cetera, by visiting the Resource library there.

50:54
And not to be left out our training options. We have a lot of great Cognos and Tableau training. We have regularly scheduled courses, large group and private instruction, as well as self-paced learning.

51:07
So, with that, I’d like to jump into some Q&A here. So, the question, the question I have for you, Sean, I don’t know if you pick this one up here but really is.

51:17
How does the traditional, though, the methodical sort of traditional waterfall approach juxtapose and sort of mesh with more, you know, modern agile approaches? So, it wasn’t spending your entire summer designing before cutting a line of code really old-school and perhaps, no longer relevant. You care to comment on that.

51:42
I mean, yeah, I mean, I have found in my experience that every project falls somewhere on the spectrum if we were to have one of the spectrum be Agile and the other B waterfalls falling. Somewhere in the middle, like, people call Agile. Right? Like, I think in the example I gave, you’re right, this was a long time ago, and it was probably a waterfall methodology that my, my, colleague was applying and perhaps is relatively old school. Agile is, is absolutely great in terms of helping us. Kind of put our functionality into bite sized chunks and, and keep things moving along the entire the entire pipeline. Yeah, like, if we have a larger team, we can then make sure that everyone’s always gathering requirements, and building solution, and, designing and developing.

52:32
In the case of my one colleague, he may have been operating as a one man show, in which case, perhaps he could have in an agile methodology been decomposing his features into something more manageable and something that he can always be providing value in. But, I have absolutely absolute faith in the agile process. I believe in it.

52:54
I have seen, did not talk about that in, in todays talk, but I have seen it. I don’t think I have yet seen it applied it correctly, fully correctly. I think that every organization applies Agile in their own particular way. And they like to think that they are doing it, because it is there are specific, it’s applying to their specific needs. But, But, Really, I think that’s a cover for, We just didn’t really learn how to use Agile appropriately. We haven’t sent people to proper training. We don’t have people with the right certifications, and so it becomes confusing. Right? When someone says, Oh, we’re applying the agile methodology to the solution. But then, Oh, wait, like, they haven’t used, like this or that, or they haven’t applied this normal usage of a tool like Jira to, to their methodologies, so it, it can create a lot of spin, right?

53:46
Because people are using a Semantic parlance of Agile, perhaps incorrectly.

53:52
So, whenever I see, on a project, the agile methodology being the leveraged. I, I stop, and I say, I asked myself first.

54:00
Where are they applying Agile, in my opinion, appropriately, and where are they not? Where, where are they off the rails that I need to be OK with going along with slash challenging? And perhaps turning the ship slowly over the course of time.

54:17
Sure. What’s there? What’s their definition of Agile in their organization? And, hopefully, they’re not, sort of using agile as an excuse to not do proper requirements gathering, Right. And you’re not using requirements gathering as an excuse to not actually execute on anything. So, I think that’s where, sometimes, you know, a third party.

54:34
Like, Senturus, you know, sometimes we can be the bad guy or the brokers, where we can sort of, you know, break those logjams and use our expertise, too.

54:44
You know, when to run and Windows. Windows, Windows slowdown. I also think that, you know, you showed that, that, that tool back, a little ways, that Markup Tool.

54:53
I think sometimes now, the, once you agree, that, the tools themselves have matured to a point where, you know, I know a Tableau Power BI and even things like Cognos now, In many cases, you could do a lot of mock ups. Right? Right in the tools, and that’s a great example of some agile development. You can throw something up in a conference room, and let people see it, and get immediate feedback on it.

55:15
Absolutely, and not to get too specific on technologies, but a tool like Power BI, is extremely good. Letting you put together, yeah, rapidly prototype something to tell a story that can serve in some cases, as part of your requirements, or help clarify what the requirements are supposed to be. Because, as I said, with governance, and this is true with every other phase of the project, until someone actually sees something, it’s often hard for them to, to get their head around it.

55:43
So if I can actually take some, maybe low data quality data source, and maybe it’s highly aggregated or whatever, and presented in a tool like Power BI, to a user, they can say, oh, OK, like I see what you’re talking about. This helps clarify, for me, the story we’re trying to tell so that we can start from the beginning of requirements and flow through solution architecture, et cetera, from a more functional place because people understand better, the end point that we’re going to get to and the challenges that are necessary to solve in order to get there.

56:16
Sure.

56:16
And everyone takes, you know, if you have the luxury of a BRD and if you’ve done all that, you’re sort of people are coming through that and translated out of their own visual of what the end product might look like. So if until you actually do that, two different people reading that BRD or having an idea of what that is in their head, can have extremely different ideas?

56:36
Absolutely. Yeah, I think you’re totally right, that the prototyping phase, I didn’t talk about, but it can be very elucidating for many parties to help clarify scope. Yeah.

56:49
I love that you used elucidating. It’s a great word. Then one other question for you. So when we do see organizations that are either, you know, Gardner, and many others say that we spend 80 to 85% of our time in any given analysis, and that’s projects large or small, getting the data ready for analysis.

57:07
So when you see people, either you’re taking a technology first approach or shortchanging the data, the required data preparation phase or they don’t have the BRT, is what in your experience, have been some of the ways that you’ve tackled that to kind of, you know, try to write that ship or to point them in the right direction.

57:29
I need to know where we’re going. I need a roadmap. I Anita, a set of stone Tablets That are handed down from the mountain to say, Here’s where we’re going to go Right, and then we can analyze the gap between that like our ideal. And then where are we actually are with our information.

57:46
It’s only if we understand what we actually want that we can then inform what we actually have right and close that gap.

57:56
So if I don’t have a business definition of what a particular data point supposed to be. How can I say, it’s wrong? I don’t know that yet. I can’t look at a database, and do data profiling, and write some SQL queries, or whatever, and then look at that information. And say, I don’t this Of course, this looks bad because I need some, sort of, like North Star to say, here where this is supposed to be going. Here’s the story we’re supposed to be able to tell that it without that, my data profiling may be incomplete.

58:27
It will be a complete, because I might be able to apply best practices of, like, Oh, this data looks bad because of my other experience with this other project, but without, without that partnership from the business side, I really might not be able to, in the first version, eliminate as much of the problems with the data as I could, if they had been involved.

58:48
That’s a great point, and I think that comes, that speaks to, you know, sort of an executive sponsorship and, or, at a minimum. Who cares about this, right? Does this tie to what does the company trying to doing? What are the pressures? Or opportunities that they’re seeing in their vertical industry or in their line of business, right, or whatever the regulatory requirements that they have to hit, all those sorts of things. Who who’s getting compensated or doesn’t get compensated because of the metrics that are falling out of this project. And they can help provide that sort of guidance in any way, always asked the question at any point of, you know, who cares? We’re doing this.

59:25
Why do we care about this particular thing that we’re doing?

59:28
I think that’s a great point, and, and flesh out that data governance example. I gave one exercise that I walked to the executive steering committee through, which was interesting, because I thought we would be able to do that at the data governance committee level is, what are your key performance indicators? There actually wasn’t an enterprise wide document that said, here’s what we’re measuring, and here’s what we’re comparing against. And here’s like the 10 that we care about the most, that if we change these numbers, this will have the largest impact on the organization, and walking the Executive Steering Committee through that process. It opened up everyone’s eyes to say, this is the availability of our data. This is the situation, this is where our company is currently. And here’s how we want to change the situation, right? And, and once I had those people on board, getting everyone who reports to them onboard became exponentially easier, because then we had a roadmap. We had a vision, right? And that was so important for getting our solution, right.

1:00:24
That’s great. That’s excellent insights. As always, we’re, we’re at the top of the hour now, and so I just want to thank Sean for an excellent, excellent presentation. And if you want to advance to the last slide here, thank all of you for taking time out of your busy days to spend an hour with us here at …, Invite you to reach out to us at our website or at info@.com. Or the good old AAA number there, and connect with us on various social media sites, LinkedIn, Slide share, YouTube, Twitter, and on Facebook. So, thank you for joining us today. Again, the recording the presentation. And any unanswered questions will be up there on our resources site.

1:01:03
So, please join us there, and we look forward to seeing you soon on one of our future knowledge series presentations. Thank you very much, and have a great rest of your day.

 

Read more