0301. Why Asset Onboarding Gets Harder as Organizations Get Bigger

Asset onboarding often feels like it should get easier with experience. But for many growing biopharma and manufacturing organizations, it does the opposite.

In this episode of Lean by Design, Oscar Gonzalez and Lawrence Wong explore why asset onboarding becomes more chaotic as organizations get bigger. Despite having SOPs, templates, and experienced teams, new equipment still arrives late or incomplete, ownership feels unclear, and validation, IT, EHS, and operations are forced to negotiate readiness in real time.

Rather than framing this as an execution or communication problem, the conversation reframes onboarding as a risk transition that is rarely designed explicitly. As organizations scale, experience masks risk, accountability becomes assumed, and operational teams quietly inherit fragility they never agreed to own.

This episode isn’t about best practices or speeding things up. It’s about understanding why onboarding chaos is predictable at scale—and why fixing it starts with seeing the risk clearly.

Order Predictably Broken Now! https://books2read.com/predictablybroken

Learn more about us by visiting:  https://sigmalabconsulting.com/

Check out video episodes: https://www.youtube.com/@LeanByDesignPodcast

Want our thoughts on a specific topic? Looking to sponsor this podcast to continue to generate content? Or maybe you have an idea and want to be on our show. Fill out our Interest Form and share your thoughts.

Transcript

Season Three And Global Reach

SPEAKER_00 1:01

So here we are with season three. It is twenty twenty-six. I don't know about you, Lawrence, but uh last year went by very fast for me, and I'm still trying to I'm not quite writing the five instead of a six at the end of the year, but uh I'm still trying to trying to grapple the fact that it's January um of this year. So uh here we are. We made it around the board, and I'm excited for what we're gonna do in season three in this year. You know, we took some time earlier in the year to or or uh later last year to understand what you know our listeners where they are, and and we've been super fortunate to just see the reach that this podcast has brought. And I mean, we have people going as far out as Germany in some areas of Europe, some Asia countries as well, that it's it's pretty incredible to see that the things that we're talking about, they matter globally. Like these are challenges that people are having every day. And that's what we want to focus on in season three is how are we addressing what are these problems really look like in biopharma, in the manufacturing space, in the facilities and RD and clinical operations, you know, even in other functions that are critical to operations, whether you are pre-commercial or a commercial enterprise. So I think it's gonna be really important for us. It seems like our listeners really connected to the problems that we talked about last year in season two. So this one's gonna be especially uh, especially, I think, really good and really informative for people because we're gonna tackle some issues that touch different areas of the organization and present problem personas. We're gonna be presenting situations that we've experienced, situations that our clients have experienced, and situations that uh others that uh you know we've connected to have experienced. So I'm looking forward to this year and this season to just take a strong lens into how we're working every day and recognizing what that does to the culture of an organization, the consistency, the executive leadership alignment when those things are not in line, when they're not really well thought out. And so today, you know, it's when I when I was prepping for this episode, I thought of a story that we can bring in later on, but it has to do with uh with bringing in new equipment online, bringing in new assets, and this notion that it feels much harder than it should be to bring something in. So I think it's important for us to really make sure that our listeners understand this problem, they feel this problem, you know, what is actually happening here, and then sort of what are those, how do we identify that these are going to be problems in the future? And why do we care? Why do we care? And then, you know, we could talk about solutions too. I think a lot of these things, we've talked about it before, are related to how the business decides to operate, how they decide to communicate, how they decide to create process and to, you know, decide what to standardize or not to standardize, or maybe they don't even make a decision. Maybe they just allow that to the folks that are in that space or responsible for that work if you actually know who those people are. But it's interesting because this is a problem. Onboarding assets from from my experience, and and please chime in, this doesn't just show up in inexperienced teams. It shows up organizations that have been doing this time and time again, but it becomes a friction point that is seen as a task-related issue as opposed to this sort of transformative transition that this this bringing in new assets, making sure, you know, IT is connected, ES knows what's happening, this is going to be producing this kind of waste, having all of that documentation, making sure that quality is there, making sure that it is validated prior to anyone working and that people are trained on it. Like this is a whole thing. I mean, is is is this something that you're that you're also seeing as well?

Simple Lab Moves Vs Complex GMP Sites

SPEAKER_01 5:28

Yeah, it's I mean, it's this problem is has been a problem for a long time and it continues to exist. You know, whether you're in the simplest kind of situation, maybe you're moving into a a non-GMP space. It's just a lab and there's no product quality impact to some of the equipment. And so it might just be a space that you leased and you're moving in equipment, and it's a brand new space, very easy to do. You get the shipment, you move it up to the spot where the scientist wants, you connect it, and then you start using it after the vendor maybe comes in and sets it up, right? So that's the simpler situation. Um, maybe your footprint's pretty small, but then we go to the other end of it where in this is a lot of the the larger companies kind of have this problem where you're bringing in equipment, or maybe you're working on an expansion of an existing site and you already have so many different policies and workflows in place, and you're having to integrate with those folks that are already at the campus, right? So some of the things you might run into are we didn't know the shipment was coming today. Who's responsible for actually onboarding this equipment? Because you have all these different activities that are already going on. I think a lot of workflows are designed, especially at these large companies, to onboard a single asset at a time. And so when you think of like, oh, we actually have a thousand things coming in, the volume just gets very overwhelming to really think about. But think about moving into a small apartment versus moving into a giant mansion where you have lots of people already doing stuff. It's right, it's just there's a lot of activities going on, right? And I I think the that these the process and the the workflow is I would say pretty standard across the industry as far as the sequence of steps that you have to take. I think the difficulty is in coordination with all the people involved, right? Because that's usually nobody is most of the time fully dedicated to just doing this one task because they have all these other responsibilities.

Who Owns What In Onboarding

SPEAKER_00 7:31

Right, right. Can you talk a little bit more about who you would typically find to be involved in in your experience and what you've seen with with larger um facilities? And I can certainly speak to the ones that are not GMP that are moving from one building to the next. And when there is no, and and I had to do one of those things personally. Um, and it was absolute chaos. It was, I mean, I had everybody showed up at the same time. There were some, I had no idea that there were people specifically that had to come in and they had to be the ones to move CO2 cylinders from one building to the next. I was being tasked with doing that on my own. I had the only card that could let any of the vendors into the buildings, and we had to transfer things, and there was no internal space, so they had to go outside of the loading dock, down across the street, into another loading dock, up inside. And I was the only one that that had my own card. None of the vendors did, but I had to like walk them to each space. This included fume hoods, this included incubators and shakers and just like massive refrigerators, freezers, and I'm trying to coordinate across two buildings with I think we had like five groups of people at the same time. And I was told, don't bother any of the scientists, you take care of this. And so this was something where everybody showed up, there was no plan. I had to keep like pointing and running back to another building. Like it was just, it was just so chaotic. So I I can't even imagine having that extra regular, you know, that that extra layer of of being uh GMP compliant that could really kind of throw a wrench into it, especially when trying to group all these people together. So when you're looking at this from uh a large business, uh large enterprise, let's say you're you have to onboard, you know, 2550 uh pieces of equipment. Who are the different groups of people that are involved? I imagine in some case the the scientists are involved to let you know like where they need something done, but also maybe EHS because something is going to either you know produce fumes that need to go out or they need to be close to a sink to go down the proper drain. You know, who are all these people and who actually is the one that is supposed to be coordinating those things?

SPEAKER_01 10:46

Yeah. So for that specific example, think of so let's just say like it's 25 pieces of equipment, right? So when we talk about assets, assets um it again Yeah, define that for us. Well, define it differently, right? So asset is in my mind anything that you would need to maintain to support your operations, right? At a very basic level. And um you can how you structure the management of that asset, I think makes a huge difference in the amount of data that comes along with it. So, as an example, let's say your one equipment is a chromatography skid. And so in this skid, it's imagine it's a fairly large piece of uh footprint. You know, you've got pumps, you've got valves, you've got different sensors. Sensors. And so each of those things I would consider an asset, right?

SPEAKER_00 11:42

So within the system itself, you have a there's different components that each system, which is the elements, the conditions, the constraints, each element can have a number of system, each system can have a number of assets that play a role in that system, is what you're saying.

Project, Support, And End User Handoffs

SPEAKER_01 12:00

Right. So like if even if you go like you know one level higher than that, think of the facility as as you know, one building. Within the building, you have different systems. They might be plumbing, they might be HVAC, they might be electrical, they might be mechanical, they might be process systems, they might be safety systems. So each of these system categories will have individual systems within that higher category, right? So let's take uh like plumbing as an example. That would include any of your gases, right? So CO2, oxygen, each of those things are systems. And so within the plumbing category, you have, let's say, CO2. Within CO2, now you look at how the system is designed, and it's maybe it has filters, maybe it has some pressure transmitters, pressure gauges. Each of those things I would consider an asset because you have to calibrate them on a defined frequency, you have to replace the filters at a defined frequency. So each of those things would essentially be assets. So now think of an entire building, you have all these systems, all these different assets within the system, right? And it gets overwhelming. So back to your question about the different parties that are involved. I would think of it in sort of like three groups. You have the project team, which is really responsible for designing and installing and delivering that piece of equipment or system to the space, right? So they're more think of like construction and and this is all the the project work that has to do with the designers, the builders, and the the project engineers that really have to coordinate between the the different contractors that actually make sure the space is ready, bring the equipment in, install it, and test it. And now the other group is going to be the support functions, right? So these are already existing functions at the campus. So think of safety, you think of the facilities team. There might be an existing validation team that helps with qualifying the equipment that's being installed. So those that I would consider support functions. Quality control might be another group, right, where you have to do sampling when you install equipment. So once you do testing, you might need to sample to make sure that the equipment is doing what it's intended to do so that you can actually qualify the piece of equipment. And then the last group, which is the one that kind of brings everything together, is going to be the end user, right? So, like you said, they might be a scientist, it might be an engineering group, it might be a manufacturing manager, but that is really the person who's going to be having their teams run the equipment for whatever their the that business purpose is going to be. And so when you think about equipment onboarding, it's very important for the project team to be on the same page with the support functions and also the end user because all three of these groups really have to coordinate in order for the whole thing to be a success. And so, what I like to say, like the the person who is in charge of the asset onboarding is really like handling the handoffs between these different groups and making sure that what the project is building is going to meet both the testing requirements for the support functions, but also it actually meets the operational functions for the end user. And so that's why it gets very complicated because even though you might have an asset onboarding process, if you're not frequently using it and people are involved, if it's just one thing that happens every five years or so, you're not going to remember the exact process for like moving stuff in. Whereas on the project side, there's usually a lot of, I would say, consults, consultants, and contractors where they're brought in specifically for this type of um process. And so they might approach it one way, and then the campus itself, the support functions, might say, Wait, wait, wait, we actually have SOPs, work instructions, trainings on like how we actually do the asset onboarding because it has to fit their requirements. And then there's other, I would say, things that the end user is going to look for because they might manage their systems and equipment very differently than say, you know, if you're installing one thing, that's that's kind of like one scenario, but using it every day is a different thing to think about, right? Making sure people are trained, maybe making sure they're familiar with all the buttons, all the alarms, all the different recipes that you might be able to run. And so the the the asset onboarding person or the team has to be aware of like, okay, they're looking for this information. We got to make sure that they're comfortable with the stuff after we've introduced it into their uh site.

SPEAKER_00 16:34

Right. I mean, I think what you're pointing out is something that, you know, a lot of us, you know, in principle, we would think, oh, yeah, you gotta connect with people. But oftentimes these things are not communicated well. So either they're happening very quickly and you have a very short notice, you might get an email on a Friday that says, hey, scientists, uh, leave this area alone because we have stuff coming in on the next, you know, Monday or Tuesday or something like that, or this is going to be offline and you've already scheduled things for like a week, a week in advance. And so, you know, the um, the the stage that you've set for us, you know, where there's this, you have to have this ability to have extreme coordination across vendors, internal contractors, internal employees and scientists, the support functions as well. Also understand what processes you guys have, you know, in line, which ones are not, and a real technical understanding of where do these assets fit? You know, are they things that require a lot of validation and quality control, et cetera? Or is this something that is sort of a one-off that doesn't require as much, it doesn't take much of a footprint, doesn't really link into the systems, but we need to sort of onboard it. And as you know, when things are happening very quickly and sort of catch us by surprise, there's a lot of things that sort of add to the scramble. And I'm talking, you know, things not having the right documentation, trying to rush installation because the planning was not adequate and we didn't know when they were coming in. We didn't realize there was a four-day validation, we didn't know there was a wait list to have somebody specifically come and works on this piece of equipment because that's that's the reality of it, right? When we buy these very complicated pieces of equipment, the idea is not that the scientists are gonna come and validate and onboard it. These businesses, these companies usually have somebody that is technically sound to say, this is how we're gonna validate it, this is how we make sure that, you know, I know in in my small asset space going through the lab, we had to make sure that even when we were moving centrifuges, these are very large pieces of equipment, even table centrifuges, that they should be level, there should be no shaking, there should be no sounds, because these things are moving at G's that are just beyond comprehension, right? 2100 G's, etc. Uh so you need uh you need something, you know, and some are tens of thousands, these giant vats, so that you can create massive quantities of of material. So when you're when we're seeing those things, um and and we see that there's this sort of like single person that's running around trying to align everybody, where do you see where do you see most of those breakdowns happen? And how do how do you identify that those things are actually taking place?

SPEAKER_01 19:33

Yeah. So the I think if you you have to look at it from a couple of different uh views. And I'll start with the project side because I think that's a very fairly easy thing to explain because when you're on the project team, you're aware of all the different things that are potentially coming because maybe you have access to the latest and greatest project updates, drawings, delivery dates, and things like that. And it's important to package that information so that the other, like the supporting functions and also the end user groups understand what is happening, right? If you just send them a giant list of, hey, you're getting this stuff on this date, that doesn't mean anything because they already have a thousand things going on and they're like, uh, well, what am I supposed to do with this information, right? I think we we have often joke about secondhand stress. This is a real thing. I think people often don't realize, like, you know, their scope is this, and so they don't have to worry about the the stress that they're handing off to other people when they complete the output of their work. And so on the project side, if you see that the information for understanding what is being delivered and when it's being delivered, how it's gonna be installed, how the information is gonna be collected, if there is no sort of clean and standardized ways to package that data, that's a huge red flag, and you should probably figure that out and not give this pile of mush to the other teams that are already on campus because they're not gonna know what to do.

SPEAKER_00 21:00

It's just incomplete information.

SPEAKER_01 21:01

It's just it's it's not it's not it's not the best way to go about onboarding assets because it it decreases the confidence they have at you to deliver what you you're supposed to do, right? So so that's from from there. Like so really important to make sure that that information is is packaged correctly. Um I and I think so on the supporting function side, I think you know, knowing that there's a project going on, I think one of the things that I've seen happen, and and this is not to their fault, it's it's just because they don't know the amount of capacity it's going to involve with their teams, right? Like you you if you already have stuff going on, you know a project is happening, you may not know the volume of assets coming in, and so the the volume of assets coming in really dictates the volume of work that the supporting functions really have to do, right? So now from the supporting function side. I think it's it's on them to perhaps educate the project team on the expectations for delivering a piece of equipment or a system or an asset is this. And this is what we typically do. These are the durations. This is the expectation based on the current capacity of our team, and to relay that information to the project team. Because if you don't, the project team is just going to assume that you're just going to be sitting on your hands and there's like you're not busy with all this other stuff that you're doing, right? And so really understanding what from the supporting function side, what are the uh workflows and processes that you guys are constantly managing to help onboard the assets, right? You you gotta we can't assume that the project team knows 100% exactly how to do these things because they're not involved with the day-to-day. So they would they would lack the capability sometimes to provide that expertise.

SPEAKER_00 22:44

And in this scenario, just quickly, in this scenario, the project team's main responsibility is to identify the assets that they need in order to carry out whatever manufacturing or experimentation they need to do, right? So they're more of like, here's the technical, you know, gist of it in terms of getting it in, how it gets up and running, all that stuff. Like they typically would not be the ones that have that knowledge. But like you mentioned before, it's going to be important for them to understand what that workflow looks like. Does that mean that the asset comes in here and it's a week before we can use it? Because I've seen assets come in and people are planning experiments for the day, the day the machine comes into the space, and it is the silliest thing because they become very disappointed that, oh, I can't use this today. Absolutely not. It arrived. That's it.

Communication Breakdowns And Secondhand Stress

SPEAKER_01 23:37

Yeah, it's I I was gonna get to the the end user group, which is kind of you gotta worry about both of those different uh groups, but yeah, I just want to finish my thought on the supporting functions group. So think about it like this if the project is, let's say, installing a bunch of freezers and the supporting functions are having to, let's say, maybe they have to do some temperature mapping of these potential freezers, right? It would be very helpful to know the specifications of the freezer so they can buy the right equipment to do the temperature mapping. Or for the facilities team, they need to have the right tools to maintain the things that you're gonna be installing.

SPEAKER_00 24:12

So that's the level of the temperature mapping. You're talking about like you have to detect the, you know, in this case, a freezer, it's gonna go up and down in terms it's gonna bounce a little bit in terms of temperature cycle, but you got to make sure it's within a certain range, right?

SPEAKER_01 24:26

Exactly, right. So it would help to like know, okay, well, if it's this kind of freezer, then I would need this length of wire or sensor, and so that you can actually do the things that you need to do to get that equipment to the right state. And also, you know, when when you're called upon to fix something, it would be helpful to know where you're putting it so that I can actually access it. Yes, it's a very like you know, uh common sense thing to think about, but it you'd be so shocked by how little the project team sometimes thinks about those things. And I I think the industry is getting a little bit better by incorporating some of those, a lot of those supporting functions early on so that they get eyes on the drawings and the design so they can comment on those things. And now from the um the the end user side, you're right, they can't wait to get their hands on these things. They got stuff planned, they got they're they're hiring people to work on this stuff. Yeah. So there's there's these deadlines that they've scheduled with their product teams or whatever functional groups. And so I think for them, the one thing that is often, you know, they they they they often have a lot of communication with the project team because they have things that they want to buy or things that they want to change in the design based on what they need the area to do. But they often forget to talk to the supporting functions to say, hey, you got to make sure that this equipment is safe and ready to operate. It's not the fact that you install something and it's ready, right? Like I think people often see, oh yeah, the incubator is here, and then they start using it. It's like, no, no, no, no, no, no. You can't just do that. You have to make sure that that incubator is actually onboarded into the, let's say, the maintenance program so that we have to service this every six months and these different departments that have to support the end user once they're up and running. And I think a lot of times that's often forgotten. And the worst situation is you have something installed, the end user starts using it, and then they go, Oh, it broke, and then they call the facilities guy to come over and they're like, I didn't even know you like bought this thing.

SPEAKER_00 26:24

Where was this? Right. Yeah.

SPEAKER_01 26:25

And and you think about the whole thing, there's a lot of financial implications when people do this. Is I didn't budget this in my maintenance and repair spend. So now there's an increase that I have to justify because you didn't tell me that you were you know buying and installing this thing. So there's a lot of uh from a business point of view, a lot of communication that has to happen, and and also on the technical end, right? Making sure that the actual physical equipment itself is designed, installed, tested in the way that the end user is going to be used, but also wherever the final location is, the the supporting functions have to be able to support that operation. Right.

Readiness, Validation, And Misaligned Timelines

SPEAKER_00 27:04

Right. No, I mean that's you're hitting on some really important parts here. And, you know, I think from my side, a lot of my exposure to this area has been from the end user. Um, and it's you know, I've seen a lot of the we're really, we're ready to use it, let's just use it. It can and and when you do this without the proper testing, the proper validation, I've seen people put things into an incubator and come out and look under the microscope and go, why do my cells look like this? Like they shouldn't. The morphology of the cells is not the morphology of this particular cell line. What happened? And it's well, we set this up, the CO2 was acting kind of funny. We didn't, you know, whatever the situation is, but it's it's those lack of of really setting things up so that you're not being met with speed bump after speed bump trying to get up and running. Because what all of this, you know, really comes down to is that it's going to take longer to get things up and running when we don't do these things. The you said it before, the trust, the confidence that we have that this is giving us the right thing. I've done experiments on machinery and been like, you know, on equipment, been like, wow, this is fantastic. And then come to find out we had not had the system calibrated in like four years. It's like, well, how I mean, maybe for maybe for a paper, but this is definitely not going to be able to, you know, this is not gonna work out once we're trying to really move this asset, move this biological to say that it acts this way or acts that way if the equipment we used was never onboarded, which means it never went into the maintenance program. Uh and, you know, we're we are making, we're, you know, the conversation that we're having here is probably geared more toward more mature organizations that have a maintenance program, that have an onboarding process. But I would venture to say that there's a lot of, you know, as these companies grow, there's this over-reliance in tribal knowledge of like, oh yeah, you know, asked Pete, he knows what the setup is, but there's no documentation, there's no training to actually do these things. So as these new sites are being built out, uh, either people are starting things from scratch or they're just not using anything and just we're just gonna get everything all set up and and it's gonna be hunky-dory. But as you, you know, as you're aware, uh, you know, if there's a lack of of standardized um framework to onboard the things, we're gonna fall into these problems. If we're um undefined in what that readiness criteria meant, you were talking about the functions before the uh support functions and them being able to communicate what does it mean that this is ready to be used? What is what is the the go light, the live, this machine is live, it's hot, let's let's make some science. What does that mean across the functions? What does that mean for the vendor that came in to bring it in? What does that mean for the validation expert? What does that mean for your own experiments? Because even if people validate, you should run a few controls, right? You should run a few controls before you do any kind of scientific exploration to make sure that yes, in our old system, we got this as the data. In our new system, we got something that was within standard error. This is good to go. We've done it three times. You know, taking the diligence, and I think sometimes that's where we where we fall is, you know, that extra thing that we're thinking, well, this is just something extra. It's not that important. But the people that are saying that are the people that don't understand the intricacies of that whole system. Because, like you said, it's it's a system. A system is in itself living and breathing, expanding, and requires that maintenance, requires that that that keen eye into what's happening, how things are moving in and out, how they're being brought into those programs. Because as you mentioned before, those everybody has a budget. And when we're not aligned, everybody's budget's gonna go up. Your timelines are gonna be delayed. I now have more work to do because we did not go through the proper channels, we did not involve the right people. So that's a that's a real risk that you know is the risk is not that we can't execute quickly, it's that when you don't have those systems set up, you're introducing fragility to any reproducibility. Okay, that was a great smooth asset. Maybe that was a one-off because you only had two or three that were in one domain of science. But now you're onboarding assets that touches you know the gene space and the molecular space and the cell space. And now these are all different kinds of assets that have different kinds of requirements. So there's, you know, that we want to go fast, but if you try to, you know, it's almost like driving off the lot and you know, they didn't get to lock in the the the bolts of your tires, or they didn't finish putting in the brake line. You know, it's it's gonna work, but it's it's it's probably gonna fail soon.

SPEAKER_01 32:20

Right. It's it's gonna fail. And and also, you know, I I think a lot of times when um you get to the end of all this, when people find out that maybe there were things missed as part of the asset onboarding process, it often may or may not create quality events, right? So quality events I I would refer to as like a deviation, and now they find that certain things were missing, and now you have to open up a uh a kappa. There's just just added work for stuff that we should have been better at if we had just coordinated better, right? And now you have to open up a change control, and like there's there's just all this added work that you have to do because we didn't because we were rushing, or maybe the timelines, well, whatever it was, the more I think in sync, you know, all these these different uh groups are, the the better. The risk is you're right, it's it's to not only you being able to run the site or the facility or the the the group in a certain way, but it's all the added cost, the wasted time, the the people that now have to focus on a problem that shouldn't have been there in the first place. And right. And that you when you when you have those things start to pile up in addition to the things that are already happening on the campus, it starts to um I don't know if degrading the the culture is the right word, but it definitely increases the level of distrust among the different groups, right? Because now it's like, okay, well, who's assigned to do this investigation? It's is it my fault that or is it their fault that they didn't provide this? And it becomes this blame game, and it's just not it's a very toxic situation that starts to happen.

Culture, Cost, And Quality Events

SPEAKER_00 33:56

People are looking for that too. Like, well, who is it to blame? Well, the system is sort of the issue, is that there wasn't that there was a little, you know, I I'm I'm partial to just saying it's laziness, but sometimes it could be that, you know, the wrong person was given the tas to do something that they were not fully qualified to do. So there was a lot of things that were missed. But this is again the creating the rework, creating the duplication. Well, now we have to do this again because we didn't do it right the first time, which means we have to call the person back to come up. And they have a backlog of three months because the only person that facilitates or that that that works on this type of equipment and does the validation in this region is not here or is gone, or you know, there's so many little things that we fail to sort of recognize and and understand that those early parts in the process can really be damaging to your ability to be up and running and producing the things because ultimately that's what you're trying to do. You're trying to get these things set up so that the science can continue and assets, you know, those kinds of assets can be experimented, can be delivered. And that's when we really forget about those foundational things, you're you're you're building that toxic culture. And it's uh in some ways out of ignorance, in some ways out of laziness. In some ways, you know, perhaps you're not giving the the the due respect to that process. And especially in a GMP facility, there's no real rationale to skip those pieces, you know, whether or not they deliver a quality event. You know, so if if people are out there and they're just like, if there's if there's listeners out there and they're thinking, anytime we do this asset onboarding, anytime we're bringing in something new, it's like a disaster. And the people are hard to work with. And every time I go somewhere else, they point me to somewhere else. If I think this group is responsible for providing X, they go, Yeah, you know, I'll get it to you when I can get it to you. You know, what are what are some of the things that people can be doing to sort of improve how they onboard assets into their into their facilities or even whether or not it's a it's a GMP facility or not, even if it's just moving an academic research lab from one building on campus to the next? What are what are sort of some baseline things that we could be doing and looking out for?

SPEAKER_01 36:23

Yeah, and and I'm all right. So whatever I'm gonna say is very biased because it's it's gonna come from the point of view of both like the the supporting function, because usually they get all the blame for this because they're interacting with the project team and they they have uh their customer essentially is is the uh the end user, right? And so I I think the the the best thing to do if you find yourself in a situation like this is to look at the the onboarding process to get a single asset into the system, right? So now don't pick the easiest one, obviously. You you'd want to pick the one that is the most difficult to get through the system, right? One that has many different components, one that maybe has a lot of safety implications, something that has a lot of risk to the business, right? And so there's a lot of emphasis on how what is what is the best way to kind of get this through the the business process so that we have a happy customer that can operate the equipment safely and in in the way that it's designed. We have a supporting group that their teams can maintain and test and do whatever activities they need to do to support the end user. And then the project team for them to deliver the asset in in the best way possible so that you don't have to call contractors back in to do any rework on the space and you know, because you don't want that as well, is you know, think about how you would get a single system or asset through this business process and make sure that everybody is is on board with what that looks like, right? And it might be one of the it might be having to do with the project team having a checklist of like these are the things I need to have so that I can get the right information so I can give it to the validation team or the facilities people so they can put it into their maintenance program. It might be having the manuals ahead of time so that the end user can draft the right trainings and and write their SOPs and work instructions, right? So there's understanding how you would get one through the system, and then look at where the things take the most time or people are saying that this is the most painful and try to focus on that. Okay, so you're you're mentioning that it it takes a long time for you to develop the trainings. Okay, well, why? Well, we don't know what the equipment looks like until it's installed. Okay, well, could you talk to the project team and maybe get some of the drawings and maybe get in touch with a vendor so they could do a visit so they can show you what it is that you're gonna be using? Yeah, maybe that would help you draft the training. Maybe there's something already exists, maybe you can bring them in, maybe they can do the training for your team. So having that coordination would help. But I that's how I would approach it by like a system by system kind of approach. And once you've kind of ironed that process out, now you can streamline it and then now you can do a bunch of systems at the same time, but you really have to iron it out for a single system. How would you get the most complicated and high risk thing through through this this business process? And it's it's it doesn't have to be complicated. A lot of these things are very obvious, right? Like once you understand how it impacts other people around you, you're gonna ask the right questions to say, oh, um, I know so and so is gonna be actually, you know, he has to get up on a ladder to reach the certain thing. Is there space for a ladder? There's this like very simple things like this, and then another person is like, oh, this person has to kneel down to like maybe um undo a clamp to replace a certain seal when they you know connect a hose. It's like, does that person have enough space to do that work? Is there a drain nearby? So maybe there's you know potential liquid coming out of that pipe. Is safety aware? So maybe we need to get some PPE for that space. Like there's there's certain things that you need to ask. You just look at it from a system-by-system basis. How are you gonna operate and maintain this thing at the end? And then the project team, you know, looking to see, you know, their their incentive is really to like wrap this thing up on time, on budget, right? But you also want the supporting functions and your end users to be happy with the product that you're delivering to them, right? So they don't come back to you and go, oh, we need a change order, and now you're gonna have to write a check for however much money. Kind of looking at it from from the start to the finish. How do I install, test, operate, and maintain this thing safely, you know, for the for the business? Think about it as a whole thing. And and then once you kind of do that for one system, you you just apply the same philosophy to everything that else is going into the the facility itself.

A Practical System-By-System Approach

SPEAKER_00 40:59

Well, Lawrence, you make it sound so simple, and it's and it's great. And you know, I think one of one of the challenges that I think is presented in the way that we conduct work, the way that we think about things, is that we we like to look at things through a system lens to understand what are all the connecting pieces and the elements and the stakeholders and the potential impact to different people, which is not a natural thought. You know, folks are typically gonna say, what's my job today? Oh, I got this thing coming in, and then I gotta like let people know that it's happening, and then you know, that's kind of it. It might be sort of nonchalant in that way. And, you know, as you mentioned before, there are you have to sort of do a deep dive into understanding what do you already have set up internally, what systems in place, what scheduling do you have in place, what uh workflows and frameworks and SOPs and quality, like understanding. You know, really what that workflow looks like. And if it is not available, draw it out. Draw it out. Like, here's all the steps that happen. And then, you know, it's, as you mentioned before, like it seems a little bit obvious, perhaps, when you're actually doing it and thinking about steps that happen later on. But in the moment when people are moving things, and oh, I just called somebody coming in to validate or called somebody coming in to do this, but you're sort of ignoring all the other aspects of onboarding an assessment, you sort of end up with half-completed assessments. Oh, we have a few change orders, because there's a lot of things to consider. And it all depends on the type of asset that's coming in. You know, as you mentioned before, what is the cycle for maintenance for this particular piece of equipment? What are the things that are likely to go or to break down earliest? And are those things that we can replace, or are those things that we have to preemptively schedule support for that? Because these assets are in the tens, hundreds, even millions of dollars, depending on what it is. And those are things that they are literally assets to the business. So having them up and running as functional as possible is the best opportunity for success with everyone aligned. So if someone were to come and say, you know, Lawrence, we have a few things, but it just feels bumpy. And I don't know which part of our process is the most bumpy or is the one that requires more attention. We are so thrilled to say this today, here and now, that we actually have an assessment that can help pinpoint where your biggest issues are, where your, when we look at these risk factors from the data of the asset to handing it off, who's making decisions, is the support ready? And then how are you going to train and and look at the competency that people can actually use this uh piece of equipment and be trained and validated in doing so? We have an assessment that's part of our suite of assessments that we're launching in 2026. It is actually now available. This uh assessment is specific for asset and facility onboarding readiness. So I invite everyone to take a look at our website and see what we have made available to you all. And now you can really take all this knowledge that Lawrence has, these were things that we have built in-house. We built these assessments and these modules based on our philosophy for how we operate and look at organizational problems through a systems thinking lens. So it is a fantastic. If you want to add a couple of more points to there, uh Lawrence, please do. But I think this is a fantastic opportunity for anyone that's sort of we we feel like we have things going, but there's always just some rockiness, and we're not exactly sure is you know that we're not training people the right way. Is it that our support teams are not in the conversations as much as we should have them? But this helps really tease out a lot of the he said, she said, they did, they did this, they did that, removing the issue that people assume is other people and looking at it as what is the process? What did you put down on paper? What are you lacking to communicate how these things should be done? So I'm excited to announce that our assessment suite is up and live, and we have something specifically to address these types of issues here.

SPEAKER_01 45:35

Yeah, and then the the assessment itself is it's agnostic to the the size of the facility you have or whether or not it's GMP or non-GMP. And it's it's really we've built it in a way that it's it's almost like a self-reflection, and we're providing some guidance on some of this, the m a lot of the mistakes that we've made so that you don't have to make them again. And I I think that's really the the biggest thing I I want to promote is you know there there's no right answer into how you navigate the asset onboarding process. Every company has different policies, your assets are gonna be different, the whatever you're doing in the building is gonna be different, the departments are different. And so I think what we're trying to do here is to help our clients, but also just the industry kind of step back and take a look at if I answer some of these questions, it kind of highlights to us what those problem areas are. And 99% of the time, these problems are not siloed problems, they're somewhat related. Yes. The idea is to really focus on a problem statement that kind of combines these things, right? Because it's not like when you fix, you know, if if you collect all the asset data, great. But if nobody knows how to order any parts, then well, did you really did you really make it effective? And so these pe these pieces are are very uh interconnected. And I think it's it's something that we're we're proud to put out there, and we we hope that uh you guys find it useful and you can check it out on our website. And there's gonna be some more content that we're putting out in relation to the the assets. But our website's kind of the best place to learn about it, and not just that assessment, but the other ones, and and just a little bit about how we think about these these issues.

SPEAKER_00 47:18

And that's Sigma Lab Consulting.com. You can go there right on the home page. You're gonna see sort of a lead into what the assessment is gonna be like, what that experience is like, and you can further go, as Lawrence said, go in and see like what are the types of challenges that we're tackling by creating these assessments. And it also, you know, ultimately these assessments are a reflection tool, but they end in a one-on-one virtual engagement with Lawrence or myself, where we can walk you through these multiple risk factors that are playing a role in the chaos that you're experiencing. Because as Lawrence said, we are working in the biopharma industry. These are connected systems. And in many cases, they are fragmented. So they're connected in some areas, but they're sort of these little pockets of black holes, almost like a giant thousand-piece puzzle where just a couple of pieces are missing, and your brain is going to connect the whole picture and say, Yeah, I see the whole picture. But these pieces that are missing are absolutely critical to having a solid foundation of operations. And I think it's, I'm really excited that we're putting this out there. And I really hope that people see the value and really feel that this is giving them time to slow down and reflect on what they've actually been dealing with. And at the end, you're also gonna end up with a report that you can surface to leadership to start having these conversations. And if you ever decide in the future to engage with us, we'd be more than happy to continue that conversation and see how we can help support your facility readiness. So I'm very excited for 2026. Um, there's a lot of things coming out. And, you know, again, check out our website, SigmalabConsulting.com for more information on all of that. Lawrence, I think this was great. I I felt the pain. I just kept playing back in my head, just like so many areas where things will just stop in the process of onboarding assets that we not not just that that stop, but maybe they go all the way through, and then your equipment's on board, and it's one speed bump after the next because things were not done as they were intended to in the beginning, as they should have been in the beginning. So I think this is a super important topic, and I'm glad that we were able to talk about it today. So, Lawrence, thanks. I think it was a great conversation, and I'm sure that some of our listeners out there are are feeling the pain right now. So hopefully they can get some relief after checking out those assessments.

SPEAKER_01 49:52

Yeah, for sure. And uh we'll we'll see you guys in the next one.