Thierry & Tobias - I have 99 Problems - Where Do I Start? The Theory of Constraints Applied (EN)

[00:00:15] There we go. They are slides. Um, and we're there. Hello everyone, and thank you for joining us for our little talk about the theory of constraints, which is aptly called, I have 99 problems, one of which is... the slides are actually pretty important. So, um, if I can give anyone in the audience one hint, make the slides window really big. You don't need to see our faces all that much. The slides are more important. Um, by the way, I am Tobias.
[00:00:46] And I am.
[00:00:47] And my presenter isn't working, which is one of the 99 problems. There we go.
[00:00:55] And, um, we have to, to sort of give you the disclaimer, this is not a talk. Um, it's actually more like a conversation. And, uh, we tried to make a little play out of it, and we're not actors. So, sorry for that. Um, this story, however, is, uh, made up, but it's made up of things that we experienced in real life. So it's not completely unrealistic, it's actually very realistic. And, um, the similarities that you might find for companies that you know of or have heard of are fully intended. So, let's get started. Um, hey Kiry. Can I ask you something? You're a consultant, right?
[00:01:37] Hello Tobias. Well, yes, um, let's say I'll try to advise companies on improving their organizational performance. Why do you ask?
[00:01:46] Well, that's great because I I I could really use your help with something. Um, you know I finally got that promotion I told you about and you're now looking at the head of IT of my company.
[00:01:59] Well, look at that. Congratulations. Well done, Tobias.
[00:02:02] Yeah, well, I don't know about that. It turns out that I'm totally out of my comfort zone and I've been struggling with just about everything the past few days, and to be honest, it's so horrible that I don't even really know where to start.
[00:02:18] Well, now you are making me curious. Tell me, what is it you're struggling with?
[00:02:24] Okay, so, uh, let me explain. So, as you know, I work for this bank, and it's not huge, doesn't deal with personal accounts. There's not a lot of transaction, it's not very public, but, um, we do a fair amount of business in real estate, and we make about half a billion euros of revenue per year, so I guess you could call that successful. And, um, well, for me personally, everything was great when I was just dealing with the computers. But now I have to worry about people, and I feel like, frankly, no one in the building has the slightest clue of what's going on. We have no idea who's working on what, where all the money is going. I mean, we have 100 people, 50 projects per year, a huge budget for IT, like 50 million euros. And, well, as far as I can see, nothing ever actually gets done. The only project that I know of that really got finished last year was a minor SAP release, and that took three months and 15 people to complete.
[00:03:23] Oh, dear.
[00:03:25] Oh yeah, I know, it sounds funny, but I'm totally serious. Um, my promotion came with a commitment. Improve IT performance by 10% until 2022. And now I feel like I don't even know what that means. I mean, 10% of what?
[00:03:42] Okay, so let's see. This might take some time. First of all, how do you think you can express performance?
[00:03:50] How can I express it? Well, I'm I'm sorry, you'll have to explain what that means.
[00:03:57] Well, how would you know you are productive? What does it mean to be productive?
[00:04:04] In general, you mean. I mean, I'd say we're productive when everybody's busy doing work that benefits the company, like when we don't have too many people slacking off and I don't have to feel bad for paying them.
[00:04:16] Okay, so people are busy doing stuff. But are they really productive then?
[00:04:23] Well, yeah, I mean, they're producing code, I guess, software.
[00:04:30] Okay. So, we say you are productive when you are accomplishing something in terms of your goal. Every action that brings the organization closer to its goal is said to be productive. Every action that does not, is just not productive. So, productivity on its own is meaningless if you don't know what the goal is. And in fact, there is only one goal, no matter what the company is.
[00:04:55] Well, that's obvious. I mean, we're a bank, so our goal is, well, peace. No, I'm just kidding, it's money, making money.
[00:05:05] Yes, the goal of any organization is to make money. I know, this sounds really, really bad, but well, it pays the bills.
[00:05:14] Well, you're serious. I mean, what about Greenpeace or Amnesty International? Aren't they supposed to be working for a better world at least? I mean, save the planet, all that kind of stuff.
[00:05:25] Well, yes, of course, they should do that. But still they need money to do their work and they have to make sure they don't run out of money so that they can continue to do that work.
[00:05:36] Okay, so I guess that makes sense. So, what you're saying is, whatever we do, it should be aimed at either making the company more efficient in terms of spending or making it earn more, right?
[00:05:49] Sort of, yes. Any action that moves you towards making money is productive. Any action that takes you away from making money isn't productive. Now, the important part is to figure out which is which.
[00:06:04] Oh, God. Oh, God.
[00:06:09] That that means our whole big IT budget is for the birds, right? I mean, we might as well just stop everything if we can't tell what people are working on.
[00:06:18] Yeah, well, that's right, but don't worry. You can still fix this. On one condition, you need to find out when you are making money and when you are not making money.
[00:06:30] Okay, I get that. But I mean, how do I do that? I mean, that SAP upgrade certainly cost money, but did it really help in any way? I mean, how can I measure that?
[00:06:42] And that's a very fair question. Indeed, how would you know you are making money? In fact, there is a set of metrics to inform organizations if they are reaching their goal or not. Do you have any idea what these metrics could be?
[00:06:56] Well, usually companies have yearly numbers. So, gross income minus spending minus taxes equals net profit.
[00:07:05] Yes, but net profit is not enough on its own. So, you also need to compare how much money is made versus how much money is invested, that is, your return on investment. But it is still possible to make profit, have a good return on investment and still go bankrupt. In most cases, the problem is cash flow.
[00:07:27] Okay, so if I got that right, then I first have to find out how much of the money that we spend in IT is actually used to make a profit, and at the same time, I have to figure out how much cash is available at any point in time? Um, I mean, I I understand why, but this is not easy. I'm I'm not even sure if the security clearance to get those numbers.
[00:07:50] And you are making a very relevant point here. So, in fact, for your daily operations, you cannot rely on net profit, return on investment and cash flow because, well, you don't necessarily have access to that information. So you need something else, something that shows you the relation between the overall performance of the company and your daily operations. Now, in fact, you can express net profit, return on investment and cash flow in terms of throughput, inventory and operational expense, and it is these metrics that you are going to use in your daily operations.
[00:08:25] Ah, finally something looks familiar. Operational expense, that's easy. Um, our operational expense is the money that we spend on salaries, plus the money that we spend on keeping the computers running, right?
[00:08:39] Or more precisely, operational expense is all the money the system spends in order to turn inventory into throughput.
[00:08:46] Throughput. Uh-huh. And inventory, you mean chairs, tables and laptops?
[00:08:54] No, no, no, no, no, it's not about the chairs, the table, the laptops and whatever else. Well, yes, they are inventory on your balance, but in your case that isn't really the problem. But let's start with throughput. So, throughput is the rate at which the system generates money through sales. And here the sales part is actually very important. If the company is only producing stuff without selling, well, it will go bankrupt.
[00:09:22] Okay, um, but we're a bank. I mean, we don't really produce anything. Well, okay, money, sort of, but we don't sell that, do we? We sell loans. Oh, okay. Well, now that I think about it, that is selling money, and the price is the interest rate. So, throughput would measure how much interest was collected over time.
[00:09:45] That would be correct for the bank as an organization. But what about your IT department? How does your IT department support selling these loans?
[00:09:54] Oh, in all sorts of ways. I mean, we have asset management software that keeps track of the loans and the contracts and the buildings that we help finance, and we have software for the call center, and then there's accounting and we help set up all these workstations and such, so IT is pretty much everywhere. And nothing would work at all if it weren't.
[00:10:14] But what happens if legislation around loans changes or the bank wants to sell a different product, let's say a new kind of loan? Can the bank do that without IT?
[00:10:25] Depends. Um, do you consider Excel IT? Because well, usually when those kinds of things happen then everybody just panics and it takes a year until we even start getting into the development and, well, the workflows usually, we set it up in Excel, then have people find up, uh, find ways around the system and then we wait until the update gets done in many, many months from now.
[00:10:52] All right, so, if all of this did not happen, will it impact your sales, will it impact your goal?
[00:11:00] Oh, for sure. I mean, if we can't sell the new product, that's going to mean losing customers to the competition, and if we can't keep up with the legislation, well, I don't even want to think about that, that's like the worst case scenario.
[00:11:14] Well, there you have it. Implementing these changes is actually your throughput because they will support the sales for the bank.
[00:11:22] Uh-huh. So, if my department wanted to improve the throughput, we'd have to try to deliver more of these changes or sooner, right?
[00:11:32] Right, yes. More features delivered means more throughput.
[00:11:36] Okay, but I still don't understand what inventory means.
[00:11:41] Um, I mean, we don't really produce anything else than money, and the money that we keep in the vault is probably just cash flow, right?
[00:11:49] So, inventory is all the money that the system has invested into purchasing or creating the things it intends to sell.
[00:11:58] Um, I I don't get it. We don't really create money, and we're also not really buying it, so I guess that would make an awesome product, but that's done somewhere else.
[00:12:10] Okay, let's see. You as an IT department produce software that supports selling loans, don't you?
[00:12:19] Uh, I think I get it now. So, if we spend our IT budget on creating a piece of software that handles the loans, then we've invested that money into our future sales, and then it becomes inventory, right?
[00:12:33] Right, yes.
[00:12:34] And if we don't finish that program or if it doesn't get released, then the money we invested doesn't work towards the goal, and thus it just remains inventory.
[00:12:44] Yes, indeed. Unfinished, unreleased IT programs are just inventory.
[00:12:50] Oh, wow. Uh, well, thank you, that has helped me a lot already. I'm I'm going to go have get those numbers and and then see how we're doing. Um, can I ask you again when I'm done with it?
[00:13:07] Of course you can.
[00:13:13] Hey, Kiry, it's me again.
[00:13:16] Hello Tobias. How are you doing? How are things going in your IT department?
[00:13:21] Oh, well, we've done a lot of research these past few weeks and I've come up with some numbers, so it's not all a mystery anymore. But well, I still feel like there's missing pieces all over the place or at least I'm not seeing the full picture yet.
[00:13:37] Um, but I'm I'm going to quickly, um, I do have an easy one first. So, we have some cases that are completely obvious, like there was a lot of money invested, we created a piece of software, the project is finished, it's even considered successful, but then it never goes to production. Am I correct in assuming that this means there was no throughput at all, but a lot of waste and that means total loss?
[00:14:02] Yes, you are definitely correct. There was no throughput and you've lost money in creating inventory and having operational expense.
[00:14:09] Okay, like I said, that's easy to find and easy to fix, we should just stop doing it. Um, have to make sure the software is needed or helpful or if we find out it isn't, then cancel the whole thing.
[00:14:23] Um, but then, well, there's a few other projects where we actually managed to get the software released, but only after severe delays and a lot of rework. Um, bugs were caught in QA, some major issues with the operations showed up after everything was finished, that kind of thing.
[00:14:40] Okay. So, now I need to ask you something because I feel this is going to be very important. How does your quality assurance work?
[00:14:50] Is there more than one way?
[00:14:53] I I think we do the same thing that everybody does. We spend time, make a plan, then we implement the plan, when that is done and it's released, then, uh, we take it from development and put the software on an integration environment, and then the QA department comes in and spends a couple of weeks to run tests. Until they stop finding defects.
[00:15:15] And how many defects does your QA find that development could have found before?
[00:15:21] Hmm. Well, I suppose there's a few.
[00:15:26] Well, now that I think about it, it probably a lot.
[00:15:30] I don't really know. I know sometimes it's just little stuff, like when something has the wrong color. But we do have some major defects and sometimes the thing just doesn't work at all, so we made those mistakes way earlier, like during the planning even.
[00:15:46] Okay, so now. Does development have automated acceptance tests? So I mean by that tests that execute the application as if a real user would use it. And are these tests executed continuously on any change to the software?
[00:16:00] Oh, I don't think we do that. I mean, we have developer tests, of course, but, um, well, people are always chasing some deadlines, so I think the general sentiment is that tests just take way too much time and we need to deliver more features.
[00:16:16] But wait a minute. What happens when a bug is found by QA? How how does it get solved?
[00:16:21] Well, the whole team is on call during QA, so they fix anything the testers find right away until it's all green.
[00:16:28] So, you're saying you do have budget to have expensive developers on call to fix bugs under pressure, but you don't have the budget for automated acceptance testing, do you?
[00:16:41] Well, now that you put it that way. Yeah, I mean, that sure adds up to a lot of money. Um, so we really block the whole team for the entire three weeks, so that alone should pay for some tests. And I also suppose that once we find a bug and we fix it, then the whole thing has to be tested again, and again, and again, because potentially we might introduce new bugs, um, and that'll add up.
[00:17:09] Ah, wait a minute. So, you're saying you are doing all of this manually? What this is going to take a hell of a lot of time.
[00:17:17] Now, imagine if development did actually invest in automated acceptance tests, right from the start, with the help of QA to define your scenarios.
[00:17:27] Now, once you have these tests in place and they are running continuously, you start implementing the feature. Now, as long as the test fails, well, you know there is still work to do. Once the test passes to green, you know instantly the feature is done and at that point you can safely release to production.
[00:17:43] Holy shit. Um, this is huge. I mean, I just realized that when you break a thing while you're still working on it, then it's also much quicker and easier to fix.
[00:17:55] Exactly. And you would also prevent that your QA is working on scrap, that is, your faulty software. Having QA work on faulty software is just a waste of time and a waste of money, and as a result, well, you lose throughput.
[00:18:08] Oh, well, that's one hell of an action item. Um, I I think we better get started on automated testing. Um, thank you, that helped a lot again.
[00:18:20] Well, you are very welcome.
[00:18:25] Hey, again, Cheri, it's been a while.
[00:18:29] Yes, it's been a while. How have things evolved in your IT department since last time?
[00:18:35] Oh, we've made some really big improvements with the automated testing. Um, our bug counts are down 80% and we managed to cut the time for manual QA by two-thirds. So now it's only one week. And the biggest improvement, at least for me, is that everybody's just happy while doing it because not only are there less incidents, the testers are now involved in designing the scenarios and they get to see that everything works as expected instead of always having to point out the bad stuff. So, yeah, things are looking good. But, okay, I don't I don't know how to explain this. So, now that the quality issues are no longer a problem,
[00:19:15] um, there are some projects where we finish on time, we manage to get all the features done and it still feels like the results aren't worth the cost, like not even close. And these make me worry, to be honest, because that's probably the most of our projects. It's like everybody is busy all the time, but there just isn't any progress. well doing it, because not only are there less incidents, the testers are now involved in designing the scenarios and they get to see that everything works, as expected, instead of always having to point out the bad stuff. So, yeah, things are looking good. But, okay, I don't I don't know how to explain this. So, now that the quality issues are no longer a problem, um there are some projects where we finish on time, we manage to get all the features done and it still feels like the results aren't worth the cost, like not even close. And these make me worried, to be honest, because that's probably the most of our projects. Um, it's like everybody is busy all the time, but there just isn't any progress.
[00:19:38] All right, so you're saying everybody is busy all the time, but what do you actually mean by that? Are they working on things that that help your customers?
[00:19:48] Uh, yeah, in sure, we removed all the things that don't help with the goal a while ago, as you suggested. Um, I I should say maybe that not everybody is always working on the project. Um, just about everyone has more than one project and they all have some legacy responsibilities to take care of, you know, like maintenance on old software, things like that.
[00:20:12] But why? Why are you keeping people working on different things that are not related to project that's the part to goal?
[00:20:19] Why are we keeping people busy? Uh, well, because they don't get paid to sit around, right?
[00:20:28] I mean, not everyone is needed for project work all the time, so in order to make the best use of their capacity, we try to give them work to fill their schedules.
[00:20:39] Uh-huh. Okay, this sounds interesting. But let me ask you something. Does everyone on your team have the same skills?
[00:20:49] No, I mean, of course not. We have front-end and back-end devs, database experts, AI specialists, really depends on the project context.
[00:21:00] So, what happens when for instance a database needs an urgent update but the expert is busy doing other work?
[00:21:07] Okay, I guess then they'll just have to wait. Well, or maybe when it's really urgent, they can come in on short notice. Uh, is that a problem? I mean, people can just continue doing other stuff in the meantime, can't they?
[00:21:22] So, what you are doing here is is balancing capacity of each and everyone with market demands, aren't you?
[00:21:29] I guess you could say that. That, and we're just trying to be efficient.
[00:21:36] Now, the problem with balancing capacity is that it is a sure way to bankruptcy, so not enough capacity will lead to losing throughput and losing money, and too much capacity is is just a waste.
[00:21:48] Isn't that exactly why we should try to balance it?
[00:21:53] No, you don't want this. Okay, I need to to explain something to you. You have to understand there is a difference between activating people and utilizing people. People are activated when they are just doing stuff to keep them busy. It's like pressing the on switch of a machine that runs regardless if it benefits the system. On the other hand, utilizing is using people to support the goal.
[00:22:20] Okay, um, that's confusing. I thought we were doing that. I mean, all the different things these people are working on is somehow important, like to some project or purpose. Doesn't that mean they're all supporting the goal?
[00:22:35] Well, when you look at the whole company as a system, yes, you are right, they are all supporting the goal, but every project by itself has a value stream that acts as a stand-alone system. If people are used on different projects, well, you end up having different value streams competing for the attention of these people. In theory, their capacity is enough, but people will never be available at the exact right time and for the right purpose.
[00:23:04] Oh.
[00:23:06] Let me help you here. A system is a black box. Stuff goes in on one end and finished a finished product that is customer value comes out at the other end. That is true for every product. And that's why you can't look at the whole company. You need to look at each value stream individually, because every value stream is such a black box. Unless the value stream actually depends on the value produced by another one. In addition, each of those systems has a base, a rate of throughput, and that base is determined by exactly one bottleneck. Have you heard of bottlenecks?
[00:23:44] Uh, yeah, I have, I mean, on bottles, of course. Ha. Um, but but seriously, okay, it's it's when there's one place where basically all the items have to pass through and it makes everything in front pile up while everything after gets a thin outpour, right? But, um, how can you be so sure it's only one?
[00:24:07] There may be several potential bottlenecks in a system. But we assure every system only has one governing bottleneck at a time that controls the overall system performance.
[00:24:19] Okay. And how do you find that bottleneck?
[00:24:26] In manufacturing, that's pretty easy, just go on the work floor and look around for stuff piling up. In IT, well, it's less obvious.
[00:24:35] So, let me ask you something. Do you use anything to visualize your work? Like a scrum board or a Kanban?
[00:24:42] We have Jira, so, yes.
[00:24:46] Uh-huh. Jira, right? Of course you have Jira. Who does not? Well, never mind. Um, do you have tickets piling up in one or more columns?
[00:24:58] Oh, hey, there's always more than one page of tickets on the board, so we scroll a lot, but I don't think we see any pileups, I mean, it makes no sense anyway. Um, things will be in doing until they go to done. And depending on whether you look at the done column as a pilot, but which I assume we don't because that's when we got throughput, um, there's really only one place where they can pile up and that's the to-do column, right?
[00:25:27] Okay, so we we need to clarify something here. What do you actually mean by done? So I I hope you mean deployed into production and and released to your users, don't you?
[00:25:38] No, of course not. I mean, we don't deploy until we're cleared by QA. So, when everything's finished.
[00:25:46] And why you don't have QA on your board then?
[00:25:49] QA? Well, if we added then that, then I guess we'd have everything pile up there. Until the final phase and then it would all drain at once. What would that tell us?
[00:26:04] Well, it would tell you where your bottleneck is, for instance. So, by visualizing all the steps of your value stream until releasing to your users, you will actually be able to discover that bottleneck.
[00:26:17] Wait, wait, wait, wait, um, am I understanding this correctly? We are supposed to move our work items to production before the whole project is finished? Like, users would see half existing features?
[00:26:31] It's a bit more subtle. Yes, you should move your work as fast as possible into production. No, users shouldn't see half existing features, there's no use for it. However, you can still roll out unfinished features without users actually noticing it. You want this because it will give you early feedback on how that code behaves in production, that is very valuable because it will allow you to make new decisions.
[00:26:58] Okay. So, the the feature would be deployed and tested but not visible, like, there's a difference between deployment and release or rather going live and going public.
[00:27:10] Yes, and you should visualize all of this. Also the distinction between deploying and releasing, because it also has no value to pile up unreleased features in production, that too is creating inventory.
[00:27:21] Wow, um, that makes sense. And continuing that thought, I'd have to find a way to get approval for one feature at a time instead of having a week of QA at the end of the project.
[00:27:37] Um, actually, that shouldn't be too hard to organize, the testers are involved in writing the acceptance tests, so they already know the product and they know how the team works. So, it would probably only take them half an hour to do a single features and they could come in every time that a test turns green.
[00:27:55] Yes, and and by doing so, well, you will improve your throughput.
[00:27:59] Um, okay, let me get this straight. The idea is to have to literally streamline the process into delivering every single piece of work through the whole system as quickly as possible?
[00:28:12] Exactly, the aim is is to create fast flow of work through your delivery process.
[00:28:18] Um, I understand, but doesn't that mean that I have to completely rethink how my workforce is organized? Like, assign everyone to just one project and only one, or better yet, one task until it's really entirely done?
[00:28:35] Right.
[00:28:37] And and by doing so, well, you are increasing throughput while simultaneously reducing inventory and operational expenses. In the end, you are you are improving all three metrics together. Where in the past, you were only focusing on one and only one metric, that is your operational expense by keeping people busy.
[00:28:56] Okay. Um, well, that's going to be one hell of a team meeting on Monday. Um, I better get going. Thanks, Julie.
[00:29:07] Hey, Jerry, I have great news. It really worked.
[00:29:14] Fantastic, how cool is that? What actually worked?
[00:29:18] Well, okay, I guess So, of of course people weren't too happy about committing to do only one project and reorganizing all the legacy stuff was painful, to say the least. Um, but once everybody figured out how much faster they were getting their results, it just took off.
[00:29:38] Well, that's great. So, you just experienced the benefits of handling your projects in sequence instead of in parallel. So, let me explain what happened. Let's say you have two projects, each taking three months to complete. If you do them in sequence, well, you should end the first one after three months and the second one after six months, right?
[00:30:01] On the other hand, if you do them in parallel, switching back and forth every two weeks, what happens? In theory, the first project should end after five and a half months. That is already two and a half months later than when you do them in sequence. Second project should still end after six months. Well, you hope so. But in fact, it will take even longer to finish both projects, because time will be lost due to context switching, setup times, and queues.
[00:30:32] And you have the same people shared between two projects, well, at some point, one project will have to wait for a person that is busy working on another project. So, what looked like a clever optimization, well, ends up being a huge waste.
[00:30:47] Okay, uh, that's a nice summary and in hindsight, totally obvious. Um, so as I was saying, things are going well. All in all, I'm no longer worried about the 10% improvements I promise. Because we're way ahead of that. Thank you. Um, there are a few odd projects that still puzzle me, though.
[00:31:09] Um, they look just like the other ones, but they somehow have other issues. Um, for example, uh, we have a third-party contractor that's working on a customer portal. And they have fixed release dates every six months and of course, no matter how fast our teams deliver the software that should connect to the portal, we always release on the same date.
[00:31:31] Um, am I right in thinking that they are now our bottleneck and we can do whatever we want, but we won't be able to improve the delivery time?
[00:31:42] Yes, you are right. So, the first step is always to identify your bottleneck. And in your case, it is that third party and their fixed cadence. So, how could you take advantage of knowing that?
[00:31:56] First of all, um, they shouldn't have to wait for us, or uh, be busy doing other stuff than just the portal work. Make sure that their entire time is used to deliver relevant features.
[00:32:08] That's it. As a second step, you exploit the bottleneck, you make sure that bottleneck only works on stuff that no one else can do.
[00:32:17] Okay. Um, and then I guess we could change our own delivery times, like, have the same cadence so that we don't have features half completed by the time they roll out and we always match the set of changes that they can handle. Or even better, um, stay ahead of their release by a couple of features so that we always have something to add in case they can put in a little extra. In other words, uh, we should completely sync our own production to theirs, correct?
[00:32:46] Correct, you should do that. And that is your third step. Subordinate everything else to the bottleneck and always match its pace.
[00:32:53] Yeah, I think I'm getting it now. And and how about once we manage to sync up with them, we start ask them asking them uh for half the release cycle? Like, release half the features at every three months so that we get earlier time to customer and if we keep the rest of the production in sync, that shouldn't be too hard, right?
[00:33:14] That's a very clever idea. So by halving the release cycle, you are cutting the batch size, as a result, your time to market will shrink and the flow of work, so your throughput will increase. And your users will now get their features sooner and you will get feedback faster. So in the end, you will be able to better respond to market.
[00:33:33] Well, not to mention we can sell earlier, so the ROI will be much sooner.
[00:33:38] And your cash flow will increase.
[00:33:41] Right. Um, I've been thinking about giving them access to our own delivery pipeline so that they could benefit from all the progress we made on automated testing and and maybe that will help to speed up their time and their own delivery.
[00:33:57] Well, that's a very good point. So, up until now, all you did was making better use of your bottleneck by exploiting it and then subordinating everything else to the bottleneck. That didn't cost you anything from an investment point of view, you somehow got that for free. It's only now that you are going to spend money by elevating your bottleneck in order to make it work faster and manage a higher throughput.
[00:34:23] Yeah, I think I'm really getting the hang of this. Um, it it isn't even really all that hard once you see the patterns.
[00:34:32] Indeed, it it isn't that hard, but well, I have to give you that, when you are used to classic cost accounting, well, this feels very counterintuitive.
[00:34:41] Thank. Oh, boy. Um, well, okay, uh, now there's just one more project team that has been bothering me. And um, well, now that you've explained, um, I can almost guess what you're going to say. So, there's a project, um, and everyone's always working at maximum capacity. So, it's not that they're all still working on other projects, it's just so much to do. Um, and now if I get the fixed cadence thing correctly, then shouldn't they be able to perform at a synced up pace, um, but they just can't somehow. Um, somebody's always waiting for someone else, and when you ask them why, it's usually some lame excuse about the server's not booting up correctly, or the internet connection was slow. I mean, I get that some unforeseen things will happen, but most of the reasons they tell me are things that might take minutes, but not full days or even weeks.
[00:35:39] Okay, so what is happening here are two phenomena, dependent events and statistical fluctuation. So you have dependent events when an event or a series of events must take place before another event can begin. Let's say you have a linear process where we have two processing steps and three delivery steps. The processing steps each take five minutes and every delivery step takes 10 minutes, so the whole process takes 40 minutes in total. Now imagine the first delivery step is a bit slow, it takes 15 minutes. That would make the whole process take 45 minutes to complete, that's unfortunate, but not really a problem.
[00:36:23] Now, let's imagine the middle delivery step is slow, it takes 20 minutes. Again, this will have an effect on the overall completion time, the whole process now takes 15 minutes. It also means that the first delivery step can now be executed twice during the time the middle delivery step delivers, so it will produce twice as much inventory. In the meantime, the other workstations behind the slow delivery step would starve because they would have nothing to work on. So, that's time wasted.
[00:36:55] And this would quickly get out of control because you'd never be able to catch up with the unwanted side effect.
[00:37:04] Exactly. Now, this is a very simple linear example. In real life, processes are much more complex, they might have parallel parts and dependencies with other teams or even companies. Even the smallest irregularity would have huge consequences. But the problem is, some things can be precisely planned, but most distractions and slight variations are just unpredictable.
[00:37:31] Okay, in other words, we can't ever make exact plans, but we have to accept that things will always go wrong.
[00:37:41] Indeed, all the all these events are subject to statistical fluctuations. So most factors critical to running a project successfully cannot be determined precisely ahead of time. In the end, you have to take both phenomena, dependent events and statistical fluctuation, into account together.
[00:37:57] And we can only solve it by
[00:38:02] leaving some wiggle room?
[00:38:07] Yes, I was coming to that. So you need to introduce some slack to absorb these unpredictable events. And that is why it is a bad idea to keep your utilization close to 100% because it will leave less and less room for slack. And as a consequence, any unpredictable event will have a huge impact on your lead time.
[00:38:27] Well, if that's what it takes to make them deliver anything, then I guess it's worth the budget. And we'll certainly get some happier faces for it, that's for sure. Um. Oh wow, Jerry, I can't believe it. It's it's only been a couple of months. We've completely reinvented the IT department and only a few more changes and now we're done.
[00:38:50] Whoa, whoa, whoa, hold your horses. It won't be finished after these few more changes. Do not allow inertia to become your next bottleneck.
[00:39:00] I don't understand. What does inertia mean?
[00:39:06] Well, it means don't be too happy with what you have accomplished. That will make you complacent. Once you remove the bottleneck in your IT department, another bottleneck will arise somewhere else. And it's up to you to find that new bottleneck.
[00:39:19] Yeah, I mean, you said that there's always one. So, even if the one we've been working on is no longer the limiting factor, then there'll always be something else that is. And therefore, we must keep repeating the same steps, right?
[00:39:36] Right, indeed. So, the new bottleneck could be in front of your IT department. In sales or in product development, perhaps you can't get orders approved quickly enough. Or it will be behind your IT department, in the market, maybe demand could be higher. So, you have to think about better marketing.
[00:39:54] So, the world doesn't stop and markets change. It's actually quite logical that this has to be somehow iterative.
[00:40:04] So, to conclude, let's first call the bottleneck a constraint from now on. That's a better term. Because it's more generic. A constraint could be a department, it could be people, it could be a server, it could be a policy. Now, to improve your performance, well, you need to repeat the following five steps. So, first of all, you need to identify the constraint. Next, you exploit the constraint. Then you subordinate everything to the constraint. After which you can elevate the constraint. And finally, well, you repeat. You go back to step one in order to identify your new goal.
[00:40:42] And doing that always built quality in
[00:40:47] and reduced batch sizes.
[00:40:52] Yes, you've got it Tobias, well done.
[00:40:54] I'm very good with that.
[00:41:00] Okay. So, everyone out there, thank you, uh, for staying through this with us, and we hope you had as much fun listening to it as we did making it up. Um, now, we have to admit that none of this was our own idea, of course.
[00:41:18] So all of this was based on the Elia who got work at school, which was published in 1984. Uh, so it's been there since a very, very long time. If you haven't read the book The Goal, well, you really, really should.
[00:41:34] All right, and now
[00:41:36] Thank you for your time.
[00:41:37] I have no idea how this uh remote thing works, but I guess we're going to have a chat. So, um, let's get into it and I'm probably going to have to grab a bottle of whiskey before I start that. Um, so thank you, everyone.

Transcript