I Finished \"The Goal\". Here's What We Can Learn from It

Yes, I truly finished the book now. And sorry for creating this title like a Medium article.

“What Should We, as An Analyst, Do After Knowing This Concept?”

Hello there! It’s been a while.

As I mentioned in the last edition of Data and Decision, I’ve been immersed in Eliyahu Goldratt’s book, “The Goal,” for nearly two months now.

Originally, my intention was quite straightforward. I was struggling to grasp the concept of “systems thinking,” a critical process given my current responsibilities. Upon seeking advice from a Twitter friend, they recommended this book as an introductory guide. So, I delved into the world of “Theory of Constraints” (ToC) and its intriguing applications.

Prompt: Cat reading a book from 18th century Gothic style.

However, as I continued reading, an interesting question popped on my head: hey, somehow when I reading this book, I put more attention to what the factory’s analyst do to help the team implement this ToC’s concept. What’s up with that?

This question kept resurfacing in my mind.

Perhaps it was the pressure to extract practical insights that made me notice the analyst’s role more keenly. Maybe it was because what analyst do was more relatable to me, leading to a bias in my observations.

But, I’ve just come to realize that asking the question, “What should we as an analyst do after knowing this concept?” is an inherently powerful prompt. I felt that no one asking that specific question, but I do know I’ll be interested in reading more about it.

I understand that at this point, you may find this shift in focus somewhat unexpected. You might think, “ Wait, you initially want to learn system thinking, and then read about Theory of Constraint, now you want to distill insight from the book to focus only analytics profession?”

However, you see, it turns out that this inclination has been lurking in the back of my mind all along (though I lacked a way to articulate it until I came across Cedric’s tweet that mention similar POV, albeit he’s coming from operator stand point).

I’ve experienced this same instinctual curiosity when I’m reading Hamilton’s 7 Power.

In the past, I found myself kept asking, ” Okay, Counter Positioning is a brilliant strategy, but what specific metrics and data points do we need to track? What kind of reports should we provide to business owners to demonstrate the effectiveness of our strategy? Can we engage in a more technical discussion on this?”

This will be my new area of exploration — and because I haven’t come across any newsletters addressing this, it could become my unique niche — a peculiar topic that you, the reader, might come to anticipate from me.

2 Insights

What analyst actually do in “The Goal”?

That was quite a lengthy rant I had there. Now, let’s get back to the main topic.

I’d like to revisit the earlier question I mentioned: What practical aspects from “The Goal” can we, as an analytics team, implement? Or, to put it simply: if the book mentions an analyst performing certain tasks, what exactly did they do?

Answering this question, I believe, isn’t too complex. What I feel I need to do is identify all the tasks that the analysts in the book undertook and categorize them into a few general actions.

In general, I noticed that analysts bring three kinds of contributions to the table:

Gathering data for the “True Goal” and its derivatives
Collecting as much data as possible related to the bottleneck (The book emphasizes that this is an ongoing effort).
Once enough data has been gathered from the second action, employing statistical techniques to squeeze every ounce of predictive power for managing the system. To quote Deming, it’s about “generating knowledge.”

The first action is quite common and widespread. Most companies around the world have some form of budgeting that consist of forecasted revenue and cost managed by business leaders. This is something we intuitively grasp.

Therefore, I’d like to place more emphasis on the second and third actions.

Now, the second action may sound simple too, but it’s not necessarily easy. There’s a chance you might underestimate how well you truly understand your system and its bottleneck.

If you’re an analyst, try this quick exercise: without checking any dashboards or spreadsheets, can you identify the bottleneck in your current company and quantify how much data you have about it? Are you entirely confident that all the relevant data your company needs is readily available?

Moving on to the third action, the part about “squeezing predictive power” might require a bit more explanation. Even for me personally, I didn’t initially consider this part significant when I first read the book. It wasn’t until I saw how the main character actually employed it for a crucial part of his plan.

Now, let me introduce you to Ralph, the individual responsible for “running data processing for the plant,” or essentially our analyst. While he’s not the book’s main character (that would be Alex Rogo), Ralph is someone who caught my attention every time his name appeared in the book.

2nd Action - Gathering data around bottleneck

Let me set the stage for this. After Alex, the plant’s leader, discovered the Theory of Constraints, he immediately recognized the importance of giving more attention to the bottleneck. He shared this insight with his subordinates, and they too quickly grasped the critical nature of addressing bottlenecks.

This background story is vital because, as you’ll soon see, our analyst Ralph encountered some issues right from the beginning, even after he tried to help in this critical component.

One significant initiative undertaken by Ralph was gathering data related to the bottleneck. In the story, the factory had two bottlenecks, one of them known as “heat-treat.” The person in charge of this particular bottleneck was Ted Spencer.

So, what problem did Ralph face with Ted? Below, you’ll find the conversation between Ted and Alex, the main character. Analytics folks, pay attention, and see if you chuckled a bit when reading this dialogue.

Ted: “Al, you’ve got to get that computer guy off my back.”

Alex: “You mean Ralph? What have you got against him?”

Ted: “He’s trying to turn me into some kind of clerk or something. He’s been coming around and asking all kinds of dumb questions. Now he wants me to keep some kind of special records on what happens in heat-treat.”

Alex: “What kind of records?’’

Ted: “I don’t know. He wants me to keep a detailed log of everything that goes in and out of the furnaces. The times we put ’em in, the times we take ’em out, how much time between heats, all that stuff. And I’ve got too much to do to be bothered with all that. In addition to heat-treat, I’ve got three other work centers I’m responsible for.’’

Alex: “Why does he want this time log?”

Ted: “ How should I know? I mean, we’ve already got enough paperwork to satisfy anybody, as far as I’m concerned. I think Ralph just wants to play games with numbers. If he’s got the time for it, then fine, let him do it in his own department. I’ve got the productivity of my department to worry about.”

I’ve included this dialogue here to emphasize something that might seem obvious: the importance of instrumentation and data quality.

However, in reality, this responsibility often falls outside the scope of the analytics team. We typically rely on other teams to gather the necessary data.

And if you’re like me and have worked with traditional companies in the past, you know that not everyone will be enthusiastic about requests similar to Ralph’s to Ted.

But I didn’t include this dialogue just to reiterate the importance of these factors. No, no. Now, let’s move on to another conversation between Alex and Ralph, in which Alex tries to understand Ralph’s intentions.

Ralph: “You wanted to see me?”

Alex: “Yeah, come on in and sit down. So tell me what you did to light Ted Spencer’s fuse?”

Ralph: (rolling his eyes) “All I wanted from him was to keep an accurate record of the actual times for each heat of parts in the furnace. I thought it was a simple enough request.”

Alex: “What prompted you to ask him?”

Ralph: “I had a couple of reasons. One of them is that the data we have on heat-treat seems to be very inaccurate. And if what you say is true, that this operation is so vital to the plant, then it seems to me we ought to have valid statistics on it ”

Alex: “What makes you think our data is so inaccurate?”

Ralph: “Because after I saw the total on last week’s shipments I was kind of bothered by something. A few days ago on my own, I did some projections of how many shipments we would actually be able to make last week based on the output of parts from the bottlenecks…… The projections were so far off that I figured at first I must have made a big mistake. So I took a closer look, double-checked my math and couldn’t find anything wrong. Then I saw that the estimates for the NCX-10 were within the ballpark. But for heat-treat, there was a big difference.”

Alex: “And that’s what made you think that the data base must be in error.”

Ralph: “Right. So I went down to talk to Spencer. And, ah…”

In case you missed it, Ralph does two crucial things here: he provides context for how his seemingly unconventional actions are important to Alex (understanding the bottleneck and collecting valid statistics). Additionally, he mentions that he’s working on some projections, something that intuitively every leader would want to have.

In the book, conversations between these two goes for a while, revolving around heat-treat, culminating in Alex making the following statement:

Alex: “Ralph…I want you to take all the measurements down there that you need. Don’t worry about Ted**. And do the same thing on the NCX-10**.’’

This part is crucial. I would even argue that developing political support for initiatives like this is an essential skill for an analyst, and Ralph showed us an example.

3rd Action - The Predictive Power

Now, this provides a smooth transition to introduce the third action, which is squeezing predictive power, into the picture.

But first, let’s step back and ask: why search for predictive power?

I’ll borrow from my favorite writer, Cedric, who wrote in his article ‘Operational Excellence is the Pursuit of Knowledge’:

All of this, of course, is ‘knowledge’.

And so we may restate Wheeler’s assertion a little more concretely: the type of thinking that usage of XmR charts should lead to is an org-wide commitment to the pursuit and use of ‘knowledge’, which is defined as beliefs or models that enable you to predict business outcomes more accurately**.**

This sounds deceptively simple — almost too simple to be useful. But as with most things in SPC, simple axioms tend to lead to interesting practices.

It’s a truly insightful article that delves deep into how businesses function as a series of processes with inputs and outputs. What’s truly brilliant about it is that it reiterates the old adage that ’ management is prediction ’. By now, you must have noticed that Alex, our main character, is the management in this story, and he absolutely craves ‘predictions’.

Now, I’ll detail all of Ralph’s actions related to this, beginning with how he floated the idea to Alex, how he assisted the factory when they were in a tight spot, and how Alex utilized Ralph’s predictive equation to resolve a critical bottleneck: sales.

Let’s commence with Ralph’s pitch. After Alex gave Ralph the green light to collect data around the two bottlenecks, he inquired about what else was motivating Ralph and getting him excited about data instrumentation.

Here’s the continuation of their conversation:

Alex: “By the way, what was the other reason? You mentioned you had more than one.”

Ralph: “Oh, well, it’s probably not that important.”

Alex: “No, tell me.”

Ralph: “I don’t really know if we can do it or not, but it occurred to me we might find a way to use the bottlenecks to predict when we’ll be able to ship an order.”

Alex: “Sounds interesting. Let me know what you come up with.”

Fast forward to a critical juncture in the factory’s operations: they inadvertently created an artificial bottleneck and unleashed an excess of inventory, hurting their overall bottomline.

Following internal discussions, they came to the realization that they required a scheduling mechanism capable of predicting how to release materials precisely when the bottlenecks required them.

Coincidentally, this was precisely what Ralph had already developed.

Alex: “What we need is some kind of signal to link the bottlenecks with the release-of-materials schedule.”

Ralph: “(..) maybe we can predict when to release material by some kind of system based on the data we’ve kept on both the bottlenecks. ….Since we started keeping data on the bottlenecks, I’ve been noticing I’m able to predict several weeks in advance what each bottleneck will be working on at a particular time. See, as long as I know exactly what’s in queue, I just take the average setup and process times for each type of part, and I’m able to calculate when each batch should clear the bottleneck. Because we’re only dealing with one work center, with much less dependency, we can average the statistical fluctuations and get a better degree of accuracy”

(Narrator: Ralph knows from observation it takes about two weeks, plus or minus a day or two, for material to reach the bottlenecks from the first operations.)

Ralph: “So by adding two weeks to the setup and process times of what’s in queue at the bottleneck. I know how long it will take until the bottleneck is actually working on material we release. And as each batch leaves the bottleneck, we can update our information and calculate a date when Stacey should release more red-tag material.”

Now is the right moment for me to introduce our final scene: Alex’s discussion with Johnny Jons, a marketing manager responsible for handling company’s sales. Because all the efficiencies that Alex and his teams had introduced to the factory, the product backlog vanished rapidly. He understood that he needed to generate more demand to keep it with the momentum; it was only a matter of time before the bottleneck shifted to the market.

Observe how Alex employed the predictive power that Ralph found earlier to persuade Johnny into providing him with more demand.

Alex: “All right, listen. I’m going to lay my cards out for you. I’m not exaggerating when I say everything is going well. It is. We’ve worked off our backlog of overdue orders, as you know. At the beginning of last week, the plant began producing strictly to meet projected due dates.”

Jons: “Yes, I’ve noticed my phone hasn’t been ringing lately with complaints from customers missing their orders.’’

Alex: “You see, we can predict to within twenty-four hours one way or the other when an order will leave the plant.’’

Jons: “This is impressive”

Alex: “As you can see by comparing a few recently shipped orders with ones of a month or so before, our production lead times have condensed dramatically. Four months’ lead time is no longer a holy number with us. From the day you sign the contract with the customer to the day we ship, the current average is about two months. Now, tell me, do you think that could help us in the marketplace?’’

Jons: “Sure it could,’’

Alex: “Then how about four weeks?” (editor: Alex put a bit conservative here than Ralph’s number, which is two weeks)

Jons: “What? Al, don’t be ridiculous. Four weeks!”

Alex: “We can do it”

Jons: “Come on! Last winter, when demand for every damn thing we make was way down, we were promising delivery in four months, and it was taking six! Now you’re telling me you can go from contract to finished product in four weeks?’’

Alex: “I wouldn’t be here talking to you if we couldn’t. Johnny, the truth is I need more business. With our over dues gone, and our current backlog declining, I’ve got to get more work into my plant. Now we both know the business is out there; it’s just that the competition is getting more of it than we are.”

Jons: “You can really turn around an order of 200 Model 12’s or 300 DBD-50’s in four weeks?”

Alex: “Try me. Get me five orders—hell, get me ten orders—and I’ll prove it to you.”

Epilogue

Huh, that’s quite a long post right there.

I hope that you shared the same sentiment with me about “The Goal” after reading this review. And you get kinda precise answer for our question earlier, “What analyst can take from this concept?”.

Prompt: An expressive oil painting of a office worker creating a chart on his desk

Becoming Data Driven: The Politics - A reflection

I’ve noticed a recurring pattern in my newsletters: one segment features an in-depth explanation of certain topics, while the second insight usually just a couple paragraph about weird article that I found.

Now, let’s transition to the second insight I’d like to share with you.

One of the aspects that draws me to Commoncog is Cedric’s ability to infuse his unique personal perspective into his observations. I’m not ashamed to admit that I often try to emulate his writing (and thinking) style.

The article we’ll discuss today is one of his best, titled ” Executing on Becoming Data Driven: The Politics.” You might guess the content by its title.

There are two intriguing points in that article that deserve repeating:

Cedric asserts that there are only two ways to shift an organization towards a data-driven approach: either a strong CEO leads the charge from the top-down, or you bring in enough data-driven executives to form a majority, which leads to self-selection (i.e., those who don’t align with the data-driven approach tend to leave the company). This list isn’t exhaustive, though. Cedric is still searching for the third way.
Analytics projects consist of two main components, as termed by Cedric: the “Technical” and the “Politics”. The “Technical” aspect encompasses all the hard skills required (reporting, data instrumentation, storage, scalability, and more). The “Politics” focuses on changing how the organization adopts the new analytics project, including how they use it, their weekly routines, and other elements that drive project adoption. As you might already suspect, Cedric argues that the latter is the more challenging part. I agree with him, and to add my own perspective, many companies (and the data industry as a whole) have tackled the first component, making it less complex over time. I believe that folks who work or running data consultancies that can effectively address this aspect will reap significant profits.

It’s essential to read Cedric’s article in its entirety to grasp his complete perspective. However, I want to extract these two observations and examine them from a different angle.

Let me bring the same central question I have from section earlier: given these insights, what should we, as analytics professionals, take away from them? Here are a few observations that come to mind:

CEOs with a data-driven mindset are increasingly rare. When you find one, it’s vital to hold on tight and actively support them in driving the organizational changes they envision.
With automation taking on more and more of the technical workload, the most strategic move may be to dive into the “Politics” aspect of analytics project. Expanding on my first observation, when we encounter a highly data-driven company, we shouldn’t limit our inquiries to questions like, “What data stack does the company use?”, but we should also ask, “What is the landscape within this company? that bring them data-driven culture?”. Or, another one that I loved, “What is their industry landscape so that being data-driven is a must adopt-or-die moment for them?”. We can use these question as a proxy answer for “Politics”.

Is there anything I might have overlooked?

Personal Update - My Discussion with My Mentor Last Week

I had the honor of conversing with my mentor and one of my idols in the analytics industry: Mr. Athi. I’ve known Athiratt for a year now, and he continues to amaze me with the insights he shares during our conversations.

(Side note: I typically address him as Mr. Athi. In my culture, we use titles like “Mister” or “Bapak” in Bahasa to show respect. Just a bit of trivia for you.)

Ahh now, here’s the essence of our discussion, which revolved around our career strategies, industries that are and will remain favorable to the analytics profession, and the analytics value chain.

On Building Career Moat

A career moat, by definition, is something rare and relative to your competitors in the market. To build a moat, you must possess skills that set you apart from your competition.
When considering if you want to learn skills needed for your position, always aim to be above average. If you can also anticipate the future demand for your skill, strive for that and position yourself as an above-average performer.
For example, in the past, the ability to build self-service analytics tools might have been a competitive advantage. However, as the field evolves, such skills become commonplace and no longer create a moat. You need to predict what else that might be important for the role.

Industries That Love and Foster “Analytics” Culture

Industries like Telecommunications, Banking, Investments, and Lending will continue to be major players driving advancements in analytics capabilities.
Keep a watchful eye on the field; sometimes, industries that previously had no knowledge of analytics can experience significant growth (like baseball in Money Ball). Athi specifically mentioned the story of the two shoe salesmen to instill the mindset.
Fintech is particularly a special industry for us. Analytics can be applied to both credit scoring models, governing company growth and sustainability, as well as operational aspects and risk management.

The Analytics Value Chain and Our Role

Analytics, like what I stated above, comprises two main components: the technical aspect and the business value/“politics”. Athi believes that automation will initially impact the technical side, encompassing ML Ops and Data Engineering tasks.
I respectfully differ in this regard because I believe we might be underestimating the complexity of machine learning, especially when dealing with intricate data-intensive systems.
Following the path of software engineers? Athi observes a split in data roles between non-operational (“data strategists,” “data architects”) and operational (“data engineers,” “data analysts”). I have some reservations about this trend. It appears reminiscent of the past trends in software engineering roles, such as “software architects”, which have shown a decreasing trend over time. You can read a fascinating article by Gergely about this here

Thank you folks. See you another week!