BI Development and First Principles Thinking

Good Day to all! 

Recently I have heard more and more talk in the business world of the concept of first principles thinking. Elon Musk has been quite vocal about it, and as his star continues rising, and people are taking more notice into the methods to his madness, it has become something I have heard around the water cooler so to speak.



This is not a new concept, in fact it is one of the oldest in philosophical thought (Thank you to my lovely wife for helping me get a grasp on the history of this) and in classical circles has been more commonly referred to as Aristotelian Process, standing in stark contrast to Socratic thought which has existed for around the same amount of time.



Although Socratic thought is a common element in clinical psychology, and Socratic methods are a leading component of academia, there is something truly wonderful about Aristotelian methods, and there are advantages in using first principle methods in developing and delivering business intelligence.



With that minor digression complete, let us take a moment to talk about how we apply what we know, what we have learned, and understand how it is we measure, define, predict and otherwise provide intelligence for business.



Developing our mini-marts, and the business should primarily lead our Minimally Viable Products that are delivered to the business users in developing the scope, scale, and content of intelligence that we deliver. What happens then when we have to build a proof of concept? Do we just throw random numbers up on a dashboard and hope that we are on the right track? I would argue this is where we apply some element of first principle thinking.



Every single business in the history of business, and existence today is nearly entirely focussed on one primary goal. Make money. That is it. Some people want to change the world, looking at you, Mr. Musk, and some people have businesses that are designed solely to break even. They all, though, have the commonality that money comes in, money goes out, and the goal is to have more of the former than the latter. This means that no matter how you look at things within any business, whether it is public sector, private sector, healthcare, education, sales, manufacturing, shipping, retail, service, hospitality, or any other we can make the very safe assumption that the movement and management of money will be important. If it is a department within a larger organization, it will remain the same; money will be the ultimate tip of the balance in the decision-making process.



As we are in the business of decision support, that means, we need to ensure that we look at the money, as the questions about the money, and find out how our users are interacting with their money. Ultimately, it is very hard to go wrong with delivering a proof of concept that looks at gross revenue and breaks it down by department, division, location, what have you.



Money doesn’t materialize from thin air though (Unless you are in financial management) however the adage that time is money has a lot of truth to it. Most, if not all businesses, rely on the trading of time as a resource toward the making of money. The time that people invest in producing, manufacturing, selling, shipping, delivering services, or just waiting (Looking at financial management again). This means we can, again, make a very safe assumption that the measurement of time is going to be important to the business, regardless of what business it is. I am not referring to the dimensional split of time into a period of reporting, but rather the measurement or fact of time passing. This can be cycle times, time to complete, manufacturing time, time to fill positions, time of training, transition times, client contact delays, constituent engagement times, etc. Regardless of the exact context, time will be an important factor in determining the success of the business, and as such, will be something important to deliver in reporting.



Time, though, is also the bridge between what the business does, and what the business makes in revenue; this is the reason why the last thing we need to focus on in this triad of business intelligence delivery is volume. This doesn’t mean the relative audio level of business (Looking at Matthew), but rather the amount of something the business does. This is easy in sales, manufacturing, retail, but sometimes can get a bit muddy in more service-oriented businesses and departments. Let me assure you, the volume, or amount of time a service is completed, delivered, fulfilled, or otherwise remains a measurable and important facet in these businesses too. To find the thing that the business does, which I would hope you have a firm grasp on if you are working within it, and describe the volume of that thing. The number of interaction with customers, the number of sales, the number of widgets produced and shipped. There will always be an easy win by delivering a measure of the volume of business the business does.



Everything else in developing KPIs, Metrics, Measures, Decision supports, and all manner of analytics will ultimately be delivering a measure of either money, time, or volume, or more likely a combination of these things. If you are new to interacting with a business, a department, or an industry, just remember, that business can be as complex and multi-faceted as the people that make it up, but it will only ever really measure these three things. Find them in your data, earmark them, understand them, and then everything past that becomes considerably easier in the long run.  

Cheers!
SQLDoch

Mini-Marts Redux! Directors cut.

In my previous post, I discussed the outline of utilizing mini-marts to the organization while also building towards a robust and sustainable framework on which to build additional value in the future. I want to come back and revisit this in slightly more depth, as I have had a chance to employ these techniques through a couple of different positions over the last couple years, and there have been some definite opportunities for learning along the way.

First off, let’s revisit the overall outline, as it has been found that we can find ways to engage even earlier with our business users, and allow them to outline or outright define the solution with just some gentle guidance along the way.

First up, we engage in reconnaissance with the business unit. This stage is a pre-engagement phase where we speak with individual users, managers, and others from in and informally associated to our target department. We attempt to gain some insight into the pain points that we may be able to address.  In most cases, this will be something that everyone has become aware of, but no one yet knows how to solve, or has the time to devote to building solutions.

From this recon phase, we can build out a wire frame. A basic representation of the capabilities of our BI solution. Within the Microsoft BI Stack. We can generally find that the department in question will have more than one Excel report they are compiling utilizing manual compilation and some system extract, either scheduled or ad-hoc. This sort of basic excel report can form an excellent foundation for the building of a wireframe.

Once this wireframe is complete, we can begin the engagement with the target department. The wireframe acts as a central talking point to the discussion and helps solidify the idea in our user’s minds of the direction we can go. A majority of the time, the users may not even be aware, as you and I are, of the changes made to what our capabilities are in delivering business intelligence over the last decade. The advances in the platform, capability, and delivery are our purview, and as such, we should be helping to guide our users towards seeing the best value on the investment in ourselves, and in the data platform.

Once we have a go ahead, we can begin work. We will take the ideas from our users, and the wireframe discussions, and develop a proof-of-concept. Consider this to be a first draft of the MVP. This proof of concept can be built from stage one extract. We are not aiming for performance, translated values, or complete usability. The idea with the proof is that it can be developed in an incredibly short turn around times. We build the source extract, move data into our warehouse in a flat format, and build a basic concept dashboard or BI product from this flat extract. Functions will be there, and some basic layout, but we know this will be the first draft only.

With the proof of concept in hand, we then re-engage with our users, forming the core of the focus group for the ongoing design and development of the dashboard product. We give access to a limited number of people in the user group and allow them to interact with the product. They are instructed only to provide as much feedback as possible. We begin the pre-validation of our source extract at this stage, and we work with our users to enhance and clarify the design vision. This is the first half of the first cycle. From here, we begin the real work involved in developing a mini-mart and a BI product for the users.

With our fresh feedback in hand, relevant to the product, and based on real usage, we begin the work of putting together the mini-mart. Stage 2 ETL is design and completed, deployed in a segmented development zone. This isolated zone in our warehouse development environment is the core of our new mini-mart. It may include elements or dimensions even from other areas, that we have previously developed, or it may be in isolation, depending on the context of the business.

 We can build our MVP once we have completed stage 2 ETL, or we can dive right into the final stage 3 ETL build, which should be relatively rapid if we have been building for future scope all along. (Further on scoping in future articles) Ideally with our stage 3 ETL complete, validation feedback in hand from our focus group working with the proof of concept dashboard, all the pieces are falling into place to develop the MVP with as little pain as possible. The wireframe, to proof to MVP cycle, is complete.

With the MVP launched, we move then onto the full sized focus group, engaging further with our users, showing the fruits of their labours and feedback, and showing them a product they feel not only happy to use, but a part of creating. As has been discussed previously, we are always aiming above buy-in on our projects, and the goal is to have the business users feel ownership of the product. This ownership comes from early and ongoing engagement, and from feeling that they have been heard and understood through every phase of development.

The addition of the proof of concept phase over the last year has been a great boon in my works in developing BI value rapidly for my organizations, and for increasing uptake and ownership within the business group to the BI products developed. Ultimately, if I have developed something they will use and will make their ability to consume and work with data easier and less painful for the business, I have achieved some measure of success in my role.

Until next time, Cheers!



SQLDoch