We want to measure this metric on a 75 day rolling period the executive stated confidently.

Excuse me, what? A 75 day period?!? How random is that? I thought to myself. I was in the middle of a stakeholder meeting about a report that I was in the middle of developing for a key piece of a senior executive’s weekly operating review (WOR). I thought the date window request was totally random, but didn’t flinch, because I had my trusty date table with offsets, that would make implementing this request a breeze.

Here it was again, reinforced for the 5,587th time that a quality dimensional date table is foundational in operations intelligence.

What makes a date table foundational? One word: context.

You can have millions of rows of data from all of your machines or your finish dates or a list of things that a process has “accomplished” but there’s no context. No way to related to today. Or to last week, last month, or year, or whatever the case is. The date table gives that to you.

Yes, if you had the skills to dive into SQL (a data language), you could technically group by that date and have some sort of idea of what is going on. But what about the dates where nothing was accomplished? Was work completed on a weekend? What about holiday? A high quality date table has all of these attributes defined and provides context in that specific scenario.

Building off of that, what was the execution rate over the past week? Did it increase or decrease from the prior week. Again, the date table helps you do that.

Now that we understand why a date table is important, let’s look at what a quality date table includes.

• Date

• Year start/end

• Quarter start/end

• Month start/end

• Week start/end

• Offsets for all period intervals (year, quarter, month, week, day)

• Weekend flags/Booleans

• Holiday flags/Booleans

• Custom calendars definitions as needed (4-4-5, non-standard start month, and others)

Handling Missing Dates

For the technical readers, let’s talk about handling dates where nothing happens. This is also known as data sparsity.

How does a date table help you handle this? Let’s look at how we would write SQL to solve for this:

What’s happening here?

First, we call the date table. Next, we pull in the production/ERP data. Finally, we join the two tables together with a left join.

What makes this work is the date table being on the left side of the join. This means a date will always return, even if there was no production for that day. If desired, you can use the coalesce function to return a zero instead of a null value.

Date Offsets

Let’s go back to the opening story about the rolling 75 days metric. How do you handle that? How do you do that confidently and quickly? Date offsets are the answer.

What are date offsets?

Date offsets are pre-calculated columns that tell you “how many days/weeks/months ago was this date compared to today?”

For example:

• offset_day = -75 means “75 days ago”

• offset_week = -10 means “10 weeks ago”

• offset_month = -3 means “3 months ago”

• offset_year = 1 means ”next year”

This pattern makes complicated date analysis simple and context aware.

In SQL this looks like:

No complex DATEDIFF logic. No fragility when the year rolls over.

Where to get a quality date table

I was very fortunate to have learned from the best, and find them very early. For Power BI/Power Query users, Melissa de Korte’s Date table is the gold standard for date tables. Her date table can be found on the Enterprise DNA website:

Enterprise DNA Date Table

Melissa’s table is a great place to start. If you want to add time zone awareness, here is a GitHub link to bolt that on to Melissa’s table for your locale.

I actually loved Melissa’s date table so much, that I created a trimmed down in SQL. Here’s a link to the GitHub repo.

That’s it for now

We covered date tables why they are important:

• How to identify when data is missing from dates

• How to execute arbitrary date calculations with ease

• Shared date table resources for those looking to get started

If you have any comments/questions, drop them below.

Thanks for reading!

What do you do when IT says it will take 4-6 weeks for a dashboard?

I had the monthly executive and legal review in a couple of weeks. I was tired of doing the same basic calculations and pivot tables in Excel every time. I did what I had to do. Figured out how to build it myself.

Naturally, because my company uses Microsoft products, I looked at Power BI. It was free and would integrate with my SharePoint list. There were also a ton of YouTube videos. Let’s go.

I started with drag and drop, but quickly dove deeper: dimensional data modeling, star schemas, DAX, date tables, Power Query. It didn’t take long (though there was a lot of dragging and dropping early on) before I had my first report ready for the monthly executive and legal updates.

Leadership started asking me for recommendations. Should we bring on more contract inspectors? Where did we need additional staffing? Or most often: can we cut staffing? Are we finally caught up?

Power BI became how I built the business case for those decisions. It allowed me to answer questions in minutes instead of spending 4 hours recalculating in Excel every time.

What I had built: item-level tracking, aggregated program views, inspector performance metrics, and real-time risk identification that actually changed how decisions got made.

None of this was in my job description. I just needed this information to execute my job well.

That’s where my obsession with operations intelligence really started, in the middle of trying to get my actual work done.

What is operations intelligence?

Raw operational data is everywhere. Turning it into clear, actionable next steps, that’s operations intelligence. This blog exists to explore exactly how to do just that. We will explore translating crew logs, maintenance records, enterprise resource planning and other data types into actions that help operations leaders move the needle.

What The 345 Report Covers

• Why operations intelligence matters in high-stakes environments

• Where operators commonly fail today and how to surface risks early

• Technical deep dives

  • Foundational data principles

  • How to present and render data

  • Data architecture and why it matters

  • How to build durable systems that scale

  • Big Query (SQL)

  • Power BI (DAX and M deep dives)

Why “345”?

345 (three forty-five) refers to 345 kV (kilovolts), the backbone voltage of the electric transmission system in Texas and across most of the United States. These 345 kV lines form the critical interstate highways of the electric grid moving massive amounts of power efficiently from generation sources to load centers.

The name is a direct nod to my background in energy delivery. Here, I am building and learning in public and sharing lessons from the field to help others create reliable operations intelligence systems.