0308. The Space Between Systems

And we're back with another episode of Lean by Design Podcast. I'm your host, Oscar, alongside my co-host Lawrence. Today is a special episode, I think. Well, we're we're going to continue the conversation of the issues and the challenges that we're seeing inside of organizations, what those symptoms look like, what it's really telling us about the organization and how things have been set up.

And then we have a really, a really important announcement at the end of this episode that you're not going to want to miss. It is unfortunately some sad news, but we're going to keep you guys really engaged in this episode. And I think we're going to touch on things that everyone has experienced in one way or another. And it's when the tools at your organization are sound, they make sense.

They are executing as well as possible, but they're just disconnected. They're not connected to the remainder of the organization. So let me start by saying that nobody sets out to build a broken system. Every tool you have was the right call the day that you bought it.

The Limb solved a real problem. The CMMS solved a real problem. Somebody fought for that budget. Ran the validation, trained the team.

Well, we hope that they train the team. And they were right. But the work still does not flow. So here's what I want to talk about today.

Not the tools, but the space in between them. Because the space isn't empty. It's filled with people. Somebody exports a file, reformats it.

Some people even re-key the same numbers into a slide deck for a Thursday meeting and then defends those numbers when they don't match the ones that appear in the actual system. We call that person often as an analyst or a coordinator, or sometimes the scientist. But what they actually are that afternoon is the integration, a human API. And every time data has to be carried from one hand, carried by hand from one system to another, it gets translated.

Some context comes across and some doesn't. Nobody logs what got lost. And that's the tax. That's the cost of fragmented systems.

It's not on any budget line. It shows up as late nights. And the question I've heard in more conference rooms than I can count what's the right data? So let's talk about what happens when the data doesn't flow.

Lawrence, I think in one of our earlier episodes, perhaps in this season, I don't recall, you you said something to me, and I'm gonna tell you what I believe first, and you can feel free to tell me if something's wrong. I don't think anybody owns the space in between these systems. And what you've mentioned to me before was that somebody does own them, but they just don't know it yet. So where do we go from there?

Who is responsible to carry this translation burden? Who is responsible for connecting these desperate systems that are at that point in time the right choice? You know, I think this is something that we have seen time and time again, and it seems like there is no end to it. So, Lawrence, you've been a part of these organizations, these large organizations, facilities and manufacturing.

What's the first thing that tells you that there's an issue with data moving in between systems in your space? Uh I think we go many ways about this. So not everything needs to be connected, I think, first of all, right? I I think as new things or new technologies and new platforms come up, you you as a company will uh integrate them into your company, and you have to kind of figure out where they fit and how they work together.

And a lot of the times, I I know more so in the you know the last decade or so, because we've had such an acceleration with these uh you know software as a service companies, you you still have enterprise software. Uh obviously, all the the the language models now that we use have all been embedded into a lot of the the way that we work. But oftentimes what you'll see is like this uh the IT does their work and like, hey, we've offered you this tool, and it's kind of like up to everybody else who is now part of the you know company to kind of figure out how to best use it.

And it's not uh it depends on where your ownership is of the work that you do, right? So if you're in a specific department, like let's say you're in like a maintenance, right? You like a very simple example is you want your system that manages your your work activities to connect with your inventory system, right? Because you need to order parts, and you know, sometimes the platform doesn't, it's not connected to your procurement systems, and usually procurement is like its own separate sort of system because it has handles financial data for other departments, but for maintenance, like you have you know one software that you're using to manage activities and all your assets, and so they may not uh talk to one another.

Um and it's sometimes it's it has to do with both the two pieces that you need to integrate, right? So that integration may be very clunky and you have to do a lot of manipulation from you know one source to the other. I think the other part of it is um aside from just the the tools integrating with each other, I think the sometimes people want to keep it separate because the departments that handle procurement are not the same people that are doing the work. And so they're like, we don't need to connect it because our work has nothing to do with that, except when you do the handoffs, that's when the problem comes, right?

So if if your role involves both of the systems, obviously you would want the you know those two connected, so you're kind of pulling from the same data source and you're operating interchangeably between the two. But what I often find at large companies is that those groups of people that are you know executing the work orders are not the same people that are purchasing the parts. And so they have different responsibilities and roles, and so they don't they don't have to necessarily be involved with how the items are being purchased.

And then on the other end of it, the people purchasing the items don't really care how the items are being used, right? So it's this like where are the boundaries and where the handoffs are. So I think for a smaller company, when you do have less people, but then there's probably a lot of um different applications you can use, you have to be very aware of what your tech stack looks like. Otherwise, it's just gonna balloon and then you end up paying crazy amounts of money for licenses and tokens that you don't even use and becomes a huge waste of money, and then nobody owns anything because as you're growing and scaling, you're just you're adopting these new tools because you're building something, right?

And so I think you have to have that flexibility of okay, not everything that we sign up for has to have a specific need because we're trying to see where it's gonna fit within the company, and then you grow. I mean, just like how we've like grown the company, right? Like there's different tools that we adopt and we're experimenting and we're trying to see what things work and what don't work, and you're piloting it. And I think we have gotten to a point where like if we're using something and it really doesn't fit with what we're doing, we get rid of it.

That's easier to do when you're small at a large company that's not so straightforward because you have these agreements and like IT has signed up for some sort of contract with this company, so you can't just you know cut the cord and get rid of it. There's all this like uh data and compliance that you have to adhere to. You know, if you've been using the system for a couple years, you can't just yank it out because what do we do with all the data that they have? Where does it migrate to?

Who like what are the permissions and the roles and who else is using it in the company? Do we have to ask them if we get rid of it, or do we just pull the plug because it's too expensive, right? So there's all these like little questions that come up. And it makes it, you know, there are two different scenarios, and um it gets even more complicated when you have multiple sites across the network, right?

It's not just like one you know physical facility that you have. When you have multiple facilities in your company, everybody's using it differently, and you have to kind of figure out, you know, if you're going to adopt the new tool, how does it integrate into all these other sites that are using the same application? So yeah, lots of uh different ways to go about this, but I think there's not a single company in the world unless you're maybe like an Uber or like a DoorDash where like all your work is contained within the same system, where you have the the driver to the restaurant, like everything's kind of you can see all that movement and the transactions, but for in pharma, we we just there's there's so many different things that are happening between research and development, product development, manufacturing, and then your shipping and you know all of this that we're using different pieces of technology.

So it's it would be it wouldn't be wise to connect everything because you don't have to, because sometimes you know separate business units, separate scopes of work, like you don't need to connect all of them. Um but you do need to understand what things need to be connected, and for the things that aren't connected, are you gonna live with that, right? Are you gonna be okay with those things not being connected? So it's a very long answer to what you just asked, but that's kind of like my opinion on the whole thing.

It depends on the size of the company and then you know the the the boundaries of the work itself. Like where does it end and where does it start and what does it handoff? And yeah. I'm gonna push back a little bit on on what you said.

It's not that I believe systems need to be technically integrated, you know, as you would integrate Smartsheet to Excel outputs or Smartsheet into a PowerPoint that delivers a report, etc., through Chat GPT. I'm not really looking at that type of integration when I say that these systems should be integrated. These these systems, systems should talk to each other.

I'm looking more at the data itself, the underlying information. I agree. People do not necessarily care about how things are being conducted in procurement. However, they do need to have some understanding of what happens, because what I see often is when folks don't understand that process, they are met with a wall that is going to take them four weeks to get through.

When I say that these, you know, that our data, you know, or our tool, how does our data flow? They sit on a thread, whether it's an asset ID, a project name, a site, a location. One of the challenges that I see very often is the translation hurdles that happen from a budget that is designed for uh research operations. And about six, nine months later, when you go in to reconcile these were the things you said you were going to do, and here's all the expenses.

And the finance team is looking at them and saying, these listings of things that we have purchased, whether it's you know materials or support, don't match up to anything that I see on the budget because we're using different languages. We're talking about things differently. We don't care how this how the procurement goes, you tell me how it needs to go, and I'll try to be I'll try to be in preparation for that. But what it's causing is this sort of this is the symptom that I'm referring to, is that human API.

This is that fragmentation where it's not architecture diagrams, it's a person that has 10 tabs open, reconciling by eye. They have a Slack message that comes in. Sorry, I have a quick question about the tracker. The other spreadsheet that somebody created was the real system, but it's too slow.

So now it's it's it's not giving us the information we need. So we're gonna try to go this other direction to get the information we need, but the information doesn't actually connect. I can't look at these line items that are being delivered through this system and mash them with the line items in your system. But in order for us to develop a cohesive budget or expense report of what actually we've been expensing, et cetera, I need to understand what of these line items fit into each one of these spaces.

It is a very, very common challenge that I see in pretty much any of the organizations I have worked for in my career. You know, there's I mean, I think you've seen it sometimes. I, you know, in reconciling the the budgets and the expenses for Signal Lab Consulting, sometimes you, you know, when I email you and I say, uh, what is this for? Because I look at the description, the description doesn't tell me anything because the business names do not necessarily coincide with the name of a transaction.

So, you know, yeah, we went and had dinner over here, but for some reason I got a transaction in the credit card report that comes out from California that doesn't tell me that this is from a restaurant. It doesn't even, you know, QuickBooks is gonna do what it can do, but that language is causing that symptom that requires a human transcriber. You know, and then when you start to look at that, and let's say we're talking about two separate people, let's say we're talking about those folks that are in the facilities that are, you know, in the manufacturing facility, they're doing their work, and there's folks in procurement.

Who is responsible for ensuring that yes, the things that we are asking for, procuring are the things that exist in our budget. This is how they're lined up, or vice versa, since this is a financial type of issue, is that finance that has to come and seek you out and say, I need this information from you? You know, I think I find some of those challenges that we don't really know who this is supposed to who's supposed to be managing this. You know, when did when did copy and paste become part of that job description?

And how long is it going to sit with that person who decided to raise their hand and say, yeah, I can do it this time, that now they're being asked to do that month over month because the data is not connected. Not necessarily the systems themselves, because that can be a challenge. Unless you have a master coder, which now you can do a lot of coding, but you need an expert behind any kind of AI coding to make sure that it's sound. Creating these APIs to integrate various software that you might be using is really difficult to do and difficult to maintain.

You're creating a web of connections that is not native to those systems. So if that person leaves, there goes the knowledge, right? So it's, I think there's a lot of things for us to consider when we're talking about, you know, systems and data fragmentation. And then at what cost is that?

What is the who are we relying on? Are we relying on the group that set up the budget, that their budget is still sound? Or are we relying on the procurement and the finance group to tell us we're about to be over budget? The challenge here is that fragmentation, this type of fragmentation is usually invisible.

You don't see it until you're asked to deliver something that doesn't exist with the systems that you have right in front of you. Until these two systems disagree in front of leadership or someone in hierarchical power at the organization, it's probably not going to get resolved. It's going to get resolved through, you know, just one-offs. Oh, this person did it last time, this is what they did.

And you're going to continue to do that. But then it becomes a trust problem. Now we're creating a new system, a new workflow that involves a translation period that we're sort of creating the rules. But then once people stop trusting the information they're receiving, they're going to start carving their own methods, their own procedures, their own process, their own workflow that unfortunately probably does not get documented, does not get discussed to everybody else to say, hey guys, I've had to do this on my project, I've had to do this in my department.

You should consider doing this as well with that group. I don't see that often happening. I sort of see it as like everyone sort of creating their own methods to to get around the issues. Right.

And that doesn't scale. That's not you you can't have consistency if that's it's everyone is using their own methods to solve the simple challenge of a dis of a fragmented data. Yeah. I mean, and going back to your example too, I think it's it's pretty easy, or it should be easy, depending on the size of your company and how mature you are.

But for things that if if it's transaction-wise, like you're, you know, you need a certain number of bolts for a specific job, like you can forecast that and you can determine, you know, these items are going into this asset or this program, and you can figure out the amount of money that you're going to allocate for this job because you're doing it based on a defined frequency. And then you can order ahead of time so that you have that stock level when you actually do need the, you know, that item, right?

I think you're you're still going like that, that setup you would do initially so that the people that are purchasing it also understand that, okay, the reason why we need this many is because historically we've used, you know, eight, eight, nine, ten of these things, right? And so you don't need as much manual manipulation because the the data you know that you're you're going to be seeing is for this transaction, we're expecting to spend this amount of money on these amount of items.

I think it's very hard to do that same line of thinking when you're trying to do resource allocation, right? Then this is the whole thing. So how good are your projections? It's kind of what are your projections, right?

Because again, like I've said this before, Sally's time is not worth the same as Bob's because Sally's an A player in terms of how she does her work, right? So how are you, you know, no matter what you put in, no matter even if even if your systems are connected, there's still this level of uncertainty around what does this actually mean? Do I hire more FTEs? Do I hire temporary staff, right?

Because you you have to really take a look at a lot of things, like what is the bandwidth of said person? You know, what is their capacity to do this type of work? So it gets a little bit more nuanced when you try to look at these edge cases. But I think where you have situations where it's transaction and you know the defined amount of material that you're going to use for a certain activity, there is no reason you should be going into a spreadsheet reconciling things like that.

Doesn't make any sense. Like you know how many, you're not going to use a hundred gaskets for a job that requires 10. And if you are, then obviously you would flag that in your system, right? And so for like a facilities group, when you before you go do a work order, what usually happens is you have a kit of parts.

Within the kit, there's a it's a receipt, basically, it says like X number of items, and you know this is a quantity, and then within the quantity, there's a cost. And so you can estimate the amount of cost and then the amount of labor that you would need to actually do the job. And then based on the frequency, you have a defined amount you're going to spend every year. And that would go back to finance to forecast, okay, your facility is this large, you have X number of jobs, X number of parts, and this is what we're expecting to spend.

When you go over that or you go under it, then you start to dig into the details of like, okay, why are we like what are these non-routine activities that are coming up that are jacking up our spending? When you're trying to staff projects, much more complicated because when you bring in somebody, you don't know what, well, you'd hope to know what their capabilities are in terms of how you know their role impacts certain timelines. But then you're there are unexpected things that come up when you do have people come into the project that are dragging the timeline, right?

So it's it's not it's it's nuanced, right? It's the the the end, it's not black and white. Yeah, no, no, no. You you bring up a I mean let's let's talk about that for a second.

Uh you know, I I think there's a few issues that we've been sort of dabbling into. Um I do want to go back into sort of the space in between that nobody really owns and what that means. Uh, you know, we're talking about two separate lenses. You know, one is a small company, drug development, and I'll I'll give you this sort of example here.

30-person biotech runs on ELNs, a couple spreadsheets, they have a CRO portal, and they use Slack. Integration comes out as a scientist who remembers where things live. Um, and that works. That type of stuff works at a small organization because you have those quick touch points essentially with everyone at the company.

But when does that fail? When they go on PTO or the raw data from a CDMO never makes it back into your system. You don't actually have a way to sort of thread that into your organization. So, you know, the the risk that we're talking about here is more of like future risk.

Because when you're small, these blips in your in the foundations of your work and the fragmentation of your data, they don't hurt that bad because you don't have such large swaths of data that are coming in in a business in a company that's so small. Unless you are 90% outsourced, then yeah, you might have a lot of information. Coming externally, that you need to you need to essentially make sure that they are able to integrate into how your data is formatted, how you're going to be able to get the reads that you need in order to make the the right decisions.

Versus a mature company, these facilities and manufacturing spaces, we have a commercial stage organization running on CMMS, has LIMS, MES, QMS, ERP, each fantastic system, each owned by different functions. No one agrees on the source of truth, meaning that maintenance, quality, and production reconcile conflicting records before anybody can act. And so this becomes sort of that ownership problem of everyone owns their system, but not a single person is empowered to own the seams between each of those systems.

So now that fragmentation becomes a compliance or an audit readiness exposure to that business. So we have in a smaller organization, we're sort of trying to get ahead of that future risk as the data scales, as the business scales. And when we see those very finite ownership across different segments in a manufacturing facility, when there's no one there that owns that threading of the information, it becomes a risk from a compliance and an audit readiness standpoint. So two different systems that are or two different sort of lenses that have a different issue stemming from the same fragmentation.

Yeah. And that's that's a like, so what you brought up is more, I think like in the bigger picture of things, like for like a facility, you'll have these different departments. Obviously, they're responsible for different uh parts of the operation. And then usually there's usually like a site head.

This is what we refer to as the person who's responsible for the entire thing. And then, you know, there are certain things that the site head is responsible for. Obviously, it's going to be the output of the facility itself. Like, are you dispositioning drug product at a specific rate and like what you're spending to achieve that?

If you're having any deviations related to your operations, how much money, how much resources are you spending on reconciling or resolving some of those deviations? Obviously, with the perfect scenario, is you have these golden batches, nothing goes wrong, everything goes right, no issues, right? But that's not the reality of manufacturing. There's going to be problems, there's going to be issues coming up, and you'd want to minimize that as much as possible through whatever means is within the compliance and how the equipment is operating and things like that.

And so you're you're right that the the data in these systems are often not connected. So like the main like the system that you're using to run the equipment, like that will tell you the utilization of the equipment and alarms and things like that. Whereas on the maintenance side, it doesn't even talk to that one. It it tells you, okay, these are the amount of routine work that we have done.

This is non-routine work. But then you have to take a look at both of those things and go, okay, well, what like how are they related to each other, right? Like, okay, we're seeing a lot of issues with the uh alarms and there's lower utilization, but is that caused by be like some of these maintenance issues that we're seeing? Or is it the opposite, right?

Where, okay, they were we clearly have people that are not very good at at troubleshooting these things, and now we're having low low utilization, right? You gotta have to figure out like what is it that's who's responsible for those? Who's responsible to sort of investigate those things that ultimately when we talk about any of these things, they slow down the productivity, they slow down your output, and they just create these stalls in your work where you know you get momentum and then you stop, you get momentum and then you stop.

So who's responsible in in in this situation? Is this that site head that you were talking about? So site head, and then usually if they how depending on how mature your organization is, you should have an opex group that does look at these things, right? That looks at how uh not only productivity, but also from a financial point of view, you know, what are the what is the bottom line for the the actual site itself, right?

You're looking at overhead, you're looking at um capital expenses, operating expenses, and just basically looking at the balance sheet of this of the site and trying to figure out like where what are things not comparable to other similar sites that are doing the exact same thing? Usually there's an OpEx group that will look into that from that lens, but obviously there's stuff that you opEx can be applied to manufacturing specifically. You know, when you're moving from you know product from one area to the other, it could be applied to maintenance.

Like, how are we deciding what items to maintain at what frequency? Why are we doing these things, right? So you start to there's many ways where you could I don't want to say plant the opex group, but the focus, right? You have to decide where you're going to focus these efforts in because it's I've seen models where like you have an OpEx person in each of these groups, but the problem is the way that they go about resolving these things is not consistent.

And so they're driven by different incentives, and then that doesn't work out. You really have to have a it's it's almost a separate function where like you have an opex function that looks at the whole site. And with working with the site head and the rest of your site leadership team, okay, where do we feel that we're struggling the most? Because to your point before, like these things are not contained, right?

And it's not like one department suffers and nobody else suffers. Like everybody is is kind of dealing with it. This is taxing the entire workflow, right? However, however, minimal this is creating a tax, there's a there's a an actual cost on the amount of time that people are taking to recognize that there is some disconnection, and then finding that person or finding that group of people.

I think it's fantastic that there's you know these mature organizations that have OpEx coordinators. And I've seen some of those jobs floating around, you know, LinkedIn's always saying, hey, you know, look at this job, look at that job. So I've seen those. But yeah, that is definitely a marker of more mature businesses.

So there's there's there's that model where you have a basically a department that kind of you assign and you focus on certain initiatives across the company that will improve productivity, among other things, you know, the operations of your company. The other model is what they do, and I've seen this also, is they basically have a bunch of people that are very well trained in these methods on how you would do that. And so they hold these training programs and they train a bunch of people across all these groups and incentivize them to, hey, you can get your yellow belt or your green belt by doing a project.

I've seen that. And so what happens is people take these trainings, take these programs, and then they do a project and they say, This is great. Now I can go for a promotion somewhere. And the the incentives are not there for that to be like a sustainable uh way of really implementing operational excellence at the company.

And so the other method is obviously you bring in external help and they take a look, consultants like us or other groups will come in and actually focus on those things, right? And depending on obviously the size of your company and where you are, you have to determine does my team actually have the capability, the capacity, and the uh I forget what the other C is, but basically, do we have enough time for our team to focus on this or do we need help, right? So I think if if you're not thinking about that, there's probably all these gaps that are just ballooning and they just only get worse because these things never get better.

Yeah. And and you know, when you see those things that are ballooning, oftentimes you'll see people that say, you know, not my clown, not my circus, not my horse, not my rodeo, like kind of thing, or just like I've had people tell me straight to my face when I just had a very simple question. That's not my job. That wasn't my question.

If you know the answer, I'm looking for the answer. I don't care if it's your job or not. I'm asking if you have this piece of knowledge. I mean, this is something that I experienced, you know, when in the early days where that's where these side quests came in.

You know, no single function owns this space in between systems, especially when they cross functional boundaries. These are things that cannot be really solved inside of business operations. The data flow is really a governance question that needs to be answered by unifying that structure, creating that thread that goes all the way from, I don't care if it's HR where you're you know threading. For me, it reminds me of this idea of like, you know, uh six degrees of separation or you know, the the from Kevin Bacon, whatever that separation is, that you can pinpoint people and create those connections.

That's the way that I look at a system within an organization, even HR. HR is probably trying to figure out where are these people positioning themselves in the organization, not necessarily what are they doing, but what are they supposed to be working on, so that you can sort of say, okay, this person is in this department working on this project, specifically working on these types of activities, as this is part of their role, and sort of how that data goes back to feed, you know, resource allocation.

That's one of the biggest issues that people have is how much money, how many people, how much time is it going to take to execute on a project if we start here, if we start here, if we start here. That question goes in virtually every organization that I can think of that has a team more than like 20 or 30. And what happens is when you have a weak data structure, there's this constant translation between these pillars that we talk about in Predictably Broken, from research to portfolio, to the portfolio to governance and decision making.

And when that data cannot move without a human relabeling it, that insight starts to get diminished. And every decision starts with a reconciliation instead of a judgment call. And so that's a lot of what our 4.1 assessment is looking into is measuring that system-to-system connectivity, the manual data burden that we find often in reporting to management and leadership, ensuring that we have a source of truth, the data to decision flow is there, and data integrity.

I mean, there's I think we've talked about this before, where we had this experience. I had this experience where I um went into an organization and they were using a variety of applications. And one of them in particular, I kept getting ping-ponged when I was trying to understand what is the current timeline we are working from in relation to this project. I heard from one person, you need to go into JIRA.

That's where the whole thing is. And when I went into JIRA, I saw that nothing was being updated. When we discussed this issue with the person whose name was listed in the system as having updated this information, they told us I was only told to update the data. So I updated the data.

So when you looked, every activity had no active status and was dated about two, about three months prior to me arriving. And then as I brought that forth, and I said, okay, well, where is the timeline that you're working from? Oh, it's in this system. So this group didn't even couldn't even agree on the source of truth.

And this was just and believe me when I tell you, they had money coming in, investors coming in, funding rounds coming in. And there was no way to actually take a look at the portfolio and say, where are you with these projects? A little bit of research that I found, and this is and this is crazy. This is all within the last five years.

Um, you know, Mule Soft, uh, HBR, and Forrester, 2022 report from HBR. 12, about 1,200 app switches per worker per day. 1,200. Now that's not 1,200 applications.

That's going into Outlook, going into PowerPoint, going into Excel, going into Smartsheet, going into Notion, going into Monday, going into Trello, going into CMMS, et cetera, et cetera. 1,200 app switches per day. And they calculated roughly that burns around four hours per week jumping back and forth in and out of systems. MuleSoft, this was more of a full industry outlook at people that are using digital systems.

27% of enterprise applications are actually integrated. And companies have, on average, a thousand applications that they're running. And it doesn't, and it sounds kind of crazy, but when you start to look at, well, there's a Slack, there's a Teams, there's a Zoom, there's uh there's a there's a ELN, there's uh CMMS, there's LIMS, there's a project management software, there is a financial software, there's two, there's two legal for contracts, etc. They all have different purposes, they do, and they all have their own place.

Absolutely. This fragmentation begins to grow and becomes more difficult and more taxing for people throughout their day-to-day. And then this one last piece that I wanted to that really hits home for us is Accenture looked at uh this in 2024 and found that only 19% of biopharma RD organizations call their systems fully digital or connected. 19% and if you think about where the bulk of your money goes into, it's gonna be in that research and development phase.

It's gonna be right in there where you're trying to find the hits that can land a licensing agreement, selling off the asset, going into clinical trials, something that can generate revenue back to the organization. And there's a cost, and the cost is real. It will tax every part of this workflow. So Yeah, I think there's a classic like 80-20 um, you know, numbers that you you uh just told us about.

And it seems like the there's only a minority of actual applications that are connected, and even with this how things are fragmented, you think about like how that impacts productivity overall, and even if you move the number five, ten percent, like what would that do to an entire company or industry? Just like if we just didn't have as many applications and if things were connected, it makes you think like I'm like I yeah, I probably do a lot of switching as well because it depends on the the meeting that I'm in and like what they're looking for, and then I gotta switch back and forth, and okay, now I have to go get data and I have to jump into something else.

And it's um it's a lot for anybody to kind of figure out, and and you're always staring at the screen, and I I can see why people get um overwhelmed by by all of these um applications, and and it gets even more annoying when something gets stuck or something's not there, and that you gotta switch over to Dabigate and you gotta email somebody, and it just It really is. I think it puts us all in a position, you know, as professionals in this industry and in other industries that that are using you know swaths of of digital applications and tools that we have to take our ownership of our work, number one, but number two, be vigilant in understanding what is happening before the work gets to you and what is happening with your work when it moves forward.

I think there's too few of us that really try to bridge those connections. And the way that I look at this is, you know, because here's here's the conversation that happens. Hey, we want to bring in all of our systems and select a few that are really driving this organization. Who wins?

Is it the leadership? Whoever has the best leadership sponsor for their particular system? Is it somebody who talks the loudest? Is it the one that somebody can justify the best because they have the the best language for what they're justifying?

Yes, we all need these things, but there are other systems and other ways to manage a lot of the stuff that we have. So I think in some cases, you don't really have an option. If you have something like, you know, financial systems and and legal systems, I can understand why those are sort of like Fort Knox and we need this type of setup. Uh and then as you talk about these other spaces of like how you're managing projects or you know, managing the the sort of the day-to-day pieces of manufacturing, those might be a little bit more uh loose.

You can sort of choose different faces to perform the same duty, right? But then how do those things connect back to the greater picture? Because the question at the top is not gonna be what is give me the data about this specific thing from this specific function. They're gonna be looking for insights.

Are we in trouble? Where is the nearest trouble right now in the business? Where are we flourishing? What is different about that than about this one, than about this project or function?

They're gonna start to look at the health of the organization from the resource perspective, the money, the people, the time. And if we keep those pieces, you know, this is what I've discussed before and what's present in the book related to the biopharma Nexus. These are the pieces that leadership is trying to put together. That when our systems are separate and then we try to come together to bring an update, we have you know, a risk in this one system on slide seven, and we have resolutions to these same things somewhere on slide 15.

Well, we need to pull these things into a better light so that people can actually grasp what these things are doing in our business, how they're slowing things down, how we're not these are the these are those quiet handoffs that they don't make their way into a timeline. It usually comes as like a slack message or an email. Hey, I sent this to you. Oh man, I totally missed that.

And then it continues. No one else knows that that happened, except those two people that brought it up. So now you have this big gap in your timeline that has never been recorded. No one knows what happened.

You'll just say, Yeah, it just took longer. These are those quiet chat, these quiet issues that happen with fragmented tools, with fragmented flow of information, of data. And those are the things that our assessment 4.1 is set out to help uncover.

How does that look like at your organization? Is everything connected the way that you can pull out insights into the health of the operations, that you can have enough data to project and have tighter projections like we talked about before? I think oftentimes we don't. It's important to recognize the utility of creating the thread that builds the fabric of your organization in a way that allows you to make the right decision at the right time.

Yeah. I think uh the the assessment allows uh at least it it's an attempt to enable these organizations and teams to establish a criteria to you know where are we gonna focus, and then what is the prioritization based on the time, money, and resources question, right? Because that that that looks different depending on like how big or small you are and you know where you are in in the business cycle, too. So it's uh it's I think a lot of companies struggle with this, and it's it's it's this thing that you have to be aware of, or else it really spirals out of control, and then you get to a point where people upset is probably like very under underselling it there.

Underselling it there, but uh there's there's a real cost to your business, like in terms of thinking about culture and all these things intangibles that you can't even put a value on. And we see this all the time. I mean, there's there's one here, again, another another report from Neulsoft, where 86% of IT leaders say that the unintegrated tools are adding more complex more complexity than value. And the teams are burning about 30% of their technical time hand building integrations.

I mean, we have to think about that because we want to continue to bring in the newest software, the greatest software. We need to find that balance that allows us to retire things and allows us to bring in something new. And this is so critical put the support that it requires to have a software, an application actually flourish in your organization. Talk to the right people, look at the pros and cons.

Don't just look at it from one lens, look at it from the stakeholder lens and make sure. Sure, there is support for the training and a consistent, I mean, let's be honest, organizations are not immune from people moving in and out of the business, from attrition. Like we have to really talk about people coming in, people leaving, coming in, people leaving. So if you have these systems that are built within and integrated within your organization that are the requirements for how someone performs their duty, it is also your responsibility to make sure they have the support that puts them in line for being successful.

So, Lawrence, today is a very, I would say a somber day in some aspects of it. So I I guess do you this is we talked about this at the beginning of our episode that today we had some big news to share. Would would you like to share that? Yeah, I'm uh at the end of September, I'll be I'll be stepping away from the company and be taking some sort of a sabbatical as I um am approaching the late the second half of my 30s and trying to figure out uh just life and career and everything else that comes along with maturing.

Yeah. So Lawrence is going to be stepping away, and so this is uh our last podcast episode right now that we have planned together. Uh next week is actually gonna be a special episode. We're gonna have a special farewell episode for Lawrence.

Um, and he's gonna come here on site, Sigma Lab Consulting Offices. I say office is actually just my office, but we have a nice space over there where we're gonna sit down and have a conversation and just reflect and take that time to reflect on you know what this experience has meant to him, you know, thing lessons he's gonna carry, um, perhaps some feedback for me as a co-founder or uh I never looked at myself as being Lawrence's manager, but hell, I will take any any thoughts, you know, from that end as well.

But it's been an absolute pleasure. And I think the one thing that I cannot speak to enough is you chose and you constantly choose every day to stand your ground on things that you understand, that you know, that you're positioning, and I think that has only made our conversations better. I think that has made our business better for us to have to really deliver on the data, the information, the resources behind the things that we're promising, behind the things that we are uh holding on to from the business aspect, from the podcast, how we position ourselves.

It's never been uh you've never been a yes person, and I can't tell you how much I appreciate that, that I had somebody uh who respectfully felt comfortable pushing against or providing another perspective as we built this business. So I think I can, you know, saying this along, you know, I think all of the other listeners can agree with me. You're gonna be a missed voice here, you know, at lean by design amongst you know, Sigma Lab Consulting, but especially here with Lean by Design and Willa.

So we still have you for a couple more weeks, and I'm excited to sit down and and reflect on this time, but you are very appreciated in the work that you've done uh and what you what you brought to this podcast, the perspective, the voice. So for that, I thank you, and uh, you will surely be missed as a member of this podcast. And for for all those out there listening, we will have our farewell episode next week, and then we'll follow up. I'll bring this up again next in the next episode, but we will have a couple of uh sort of a mini-series where I'm gonna go into my new book, Predictably Broken, and we're gonna talk about a few themes in there and read a couple of passages to give you a feel for the type of book that it is, and uh end our season three with with that series before coming back in season four.

We're gonna come back probably in 2027 and have a whole new take on lean by design. And so, Lawrence, thank you. Yeah, no, it's been uh it's been fun. We'll save that for the next episode.

So thank you guys so much for spending time with us today. We truly appreciate you being part of the lean by design community. If this conversation resonated with you, we invite you to check out a new book, as I mentioned, that just launched uh Predictably Broken, where it take a candid perspective similar to one that we that we take here on the patterns of operational friction that quietly slow and degrade team progress and what to do about them. So if you're ready to take the next step, you can explore our operational risk assessments.

You can go to Sigmalab Consulting.comslash check and perform a risk check assessment that we will receive directly and can point you in the direction of the right assessment to help uncover these patterns that are showing up that might be quietly eroding the progress of your team. So don't forget to follow us on Instagram at SciGuy underscore insights, S-C-I-G-U-Y underscore insights. And you can now watch the podcast on YouTube so you can see Lawrence and myself for however long we have at Lean by Design Podcast.

All the links are in the show notes. We'll see you next time.