.png)
Frontline Mobility Edge
Frontline Mobility Edge takes a look at mobility in the enterprise, focusing on workforce devices, business applications, and the technology behind them.
Frontline Mobility Edge
5 Phases of a Successful Clinical Mobility Deployment (feat. Tony Belisch from Zebra)
Most clinical mobility deployments fail before the first device hits a nurse's hands.
In this episode of The Frontline Mobility Edge, Brett Cooper and Lee DeHihns sit down with Tony Belisch, Executive Sales Engineer at Zebra Technologies (Healthcare), to break down the 5 phases of a successful clinical mobility solution. This is a framework his team developed from years of real-world healthcare IT deployments.
Whether you're deploying 50 devices or 5,000, this conversation covers what separates successful rollouts from costly failures.
Tony shares the common mistakes he sees, like IT security teams stepping in after the fact, MDMs that can't push OS updates, and why nurses don't want to be technologists.
If you're in healthcare IT, nursing informatics, or clinical operations, this is a must-watch.
Book a demo with BlueFletch: https://bit.ly/4k6zCSI
Learn more about BlueFletch: https://bit.ly/4qTeeTI
Listen to the Frontline Mobility Edge podcast: https://bit.ly/3NNHo82
#healthcareit #ClinicalMobility #MDM #EnterpriseAndroid #FrontlineWorkers #Zebra #DeviceDeployment #BlueFletch
I'm Brett Cooper and this is the Frontly Mobility Edge, where we discuss the latest in mobile device technologies and how they're shaping the frontline landscape of the software. Thank you for joining us. Let's get started. Hello, and welcome to another episode of the Blue Fletch Frontly Mobility Edge. Today we're joined by Tony Bellish from Zebra. He is an executive sales engineer in the healthcare group. So been doing it for quite a while. And this uh podcast was is based on an outline that Tony and a number of folks from his team did. Lee and I sat through this last month in Lincolnshire, which is Zebra's head office, where they covered a number of their um uh lessons learned or experiences. And it was a presentation called The Five Phases of the Clinic Mobility Solution, which um I I told Tony and a couple other folks in his team, this is probably one of the better presentations I sat through in the last couple of years. It was both um both strategic on one side and and pragmatic on the other. So it's definitely a lot of um insights combined with lessons and experience, which was uh, you know, for me, I I walked away with a lot of takeaways. So wanted to walk through I'll do a high level of the five areas, repeat what what I took away from it, and then Lee and I had questions for Tony that we were gonna dive into. So we'll go ahead and get get started. Um, I guess Lee, before I hop into anything else you had to add, add color to the um your your takeaways.
SPEAKER_01:I would say just Tony and his team put you could tell they put a lot of team effort and time into this. Um so in Lincolnshire in December when they put it on, it was four of them. Um you could tell that it was a lot of thought and a lot of experience. So I think this is going to be super valuable.
SPEAKER_02:Awesome. Um so we'll start with the first one, which was uh solutions or the the first phase of the clinical delivering or providing a clinical mobility solution, which was um solution discovery and design. You guys talked about doing a lot of work upfront, uh looking at what are the pain points, what are the actual requirements from both a technical and operational side, and thinking through how do you capture those, how do you get feedback into them? Um and then Tony, you guys talked about some of the pitfalls, but I guess from your experiences for projects you've worked on, how how often do you see discovery go well? And then are there certain things that you were into, you're like, we we got to do better, organizations need to do better on the discovery phase around these one or two things? Anything that stood out to you?
SPEAKER_00:Absolutely. So the just you know, from my experience and and certainly the experience of my colleagues as well, you know, we've seen some deployments that have gone very, very well that have been very successful. Um, obviously, there's always going to be, you know, just your your road bumps along the way because nothing ever goes perfect. But uh, and then we've had some other ones that haven't gone so well that have been very forced and uh just a lot of time spent troubleshooting, going back and reworking things, uh just having not happy clinicians at the end. Uh it's so that's where we think that this solution discovery, uh the workflow design stage is very, very important. It's bringing in the people who are actually going to be using the devices that you're deploying. And so again, when I've seen IT departments just make a decision of this is the device we're gonna use, this is the software we're gonna use, and they just put it in the nurses' hands and just send them off to start using it, those typically are not a good way to start. It it the nurses they they just never feel like they're getting, you know, their input uh is not being um regarded. And so sitting down at the solution discovery and workflow design stage and actually working with the people who will be using the devices and the software, the people who will be managing the devices and the software, bringing them all together, establishing a project manager, establishing a project owner, and then you know that's what we'll do in this stage, and uh and even getting so far as to you know start picking the MDM that's gonna be used if there's not already one, and start making some decisions about those things before we actually put a device in anybody's hands.
SPEAKER_01:And Tony, from your perspective, would you say going into um a project like this, are most organizations accepting of the reality that they need to put a lot of team effort and a lot of time and man hours against a project in order to get it work? Or do you think that typically the expectation is we picked our device, this is our software, these are our users, we're just gonna deploy it?
SPEAKER_00:So I see both. And again, the ones that do realize the scope of the project, the comp the complexity of the project, because in situations, for instance, where they have just a phone today, that literally it's just a phone, that all you can do is uh make phone calls with it, but now you're putting an Android device in that person's hands, which has a lot more capabilities and you can do a lot more stuff with it. And if you don't lock down that device, then the people will do stuff with it, and then you end up with a bunch of devices that are in all sorts of different states, and and and it just becomes unmanageable. So again, at this at this initial uh stage is where we would want to start scoping those things, and and certainly the organization has to have the realization of you know just the complexity of the of the deployment and start uh you know putting time frames around things that are that are realistic, um, which would include things like you know just uh budgeting for time, IT's time, uh making sure that the nurses are aligned, informatics, if there's an informatics department at the uh at the hospital, you know, just getting everybody involved and making sure that everybody understands what their their part of the project is going to be.
SPEAKER_02:I it follow up one of the things that I think you guys called this out during your previous presentation about just change management processes and governance. I know I've been in projects where you know IT started something and then all of a sudden, you know, the legal or HR or somebody showed up and they're like, what are you guys doing? And um I I feel like in a clinical environment, this is even more important. Do you have any pro tips around how to involve or pull in governance earlier when you know, like you said, IT might be trying to just push some things out the door?
SPEAKER_00:So again, yeah, I think that's where the just you know identifying the project manager, identifying the project owner, and and just starting to bring in the project manager should be talking to all those different departments to see if they have any concerns, any input. You know, certainly um in some deployments that we've done, the IT security department is completely separate from the mobile engineering department. And so you get so far down the road, and then security steps in and says, Whoa, whoa, whoa, you can't do that on my network. And so then, you know, now we're having to go back and retrofit certificates and things, and which is just not uh a lot of fun. And it becomes very time consuming to go back and do that uh after the fact. So that's where I would start uh you know defining the scope of the project because we want to certainly want to contain scope creep, and you certainly want to have a change management process though, if we do need to change things, if we need to add to the to the project. But this is absolutely where we'd want to define exactly what is going to be in this deployment and uh you know and try to contain it to make it you know ideally as simple as possible, because then we can always come back and add things, add features, add software, all those sorts of things after the fact, um, once we've got a successful deployment.
SPEAKER_02:That that scope creep item you you just called out, that's I think that's super underrepresented on how a lot of people think about this discovery phase. I feel like the um I some of my favorite projects, project managers to work with are those that are very hard line on you know, we draw a line, everything beneath the line is not in scope. And I feel like too many organizations I work with want to do everything up front. Um I g I guess you know, one of the sense I got out out of the presentation I saw is that you guys try to push very hard on containing that scope. Do you have any like guidance or thoughts on how to do that or how to like really get people to focus on the core pieces as opposed to all the other added value they could do?
SPEAKER_00:Sure. Again, just having a strong project manager is you know key to that and and having defined what the scope is. And you know, then it would be up to that project manager to make sure that we do stay within the defined scope of the project. And then you've got the project owner that we can go to, you know, if if we need to have a judge on anything that you know can make the determination whether or not we need to add to the scope or or just keep within the boundaries that were set from the beginning.
SPEAKER_02:Like that uh that title judge. Your role is judge, arbitrary. You're the arbiter of scope.
SPEAKER_00:Sure, we'll say arbiter.
SPEAKER_02:You see somebody like who's the LinkedIn title is arbiter of scope, not project manager. Um we're gonna move on to the the the second area that you guys talked about, which is the um staging, provisioning, and enrollment. So you have you know you've gotten your your you define your done your discovery, define what the project looks like, define what scope you're gonna have. Um the next phase you guys started talking about was thinking about how you take these mobility devices, set them up, provision and enroll. Um I feel like a lot of times this is a an afterthought for a lot of people, they'll just put software on a device, go test it, and then won't think about these other pieces as part of their their pilot initial testing. But for you, when you think about that you know, staging, provisioning, setup, and configuration enrollment as the the second phase after discovery, what are the things you try to start getting um organizations you work with to do during that phase?
SPEAKER_00:So certainly the the MDM is a very, very critical piece of of all of this. And and so you know some organizations are already gonna have an MDM and you just have to work with what they've got. Um sometimes at this stage is you know when they're looking to actually um select an MDM. And that's where you want to make sure that the MDM is gonna be able to do everything that you need it to do, or start working on what your alternatives are. And for instance, is it going to you know allow you to automatically update applications if you want applications to automatically update? What if you don't want them to automatically update because you don't want versions just rolling overnight and now all of a sudden you wake up and things are broken? So you know, those are things to consider here and to make sure that your uh management system can do what you want it to do or find an alternative. Another one is uh operating system updates. So I've actually had some customers that their MDM was not capable of pushing operating system updates, and nobody really thinks about that at this initial you know staging and provisioning stage because we don't need to do an operating system update now. We'll just stay with whatever version is on there. Well, the fact of the matter is at some point in the future, you do have to update because either your applications are going to support that old version, or there is some new feature that you need, or there's some new security protocol that you need, uh, and you will have to do an operating system update. So you want to make sure at this point, not only that you can do an operating system update, but that you've figured out how to do that. You actually got that process in place so that when we get in that situation where we need to push it out, we're not having to figure everything out at that time. So, you know, just having that plan in place. And um and then just also at this stage is where you want to start thinking about like, you know, how am I gonna lock down the device? Do I want to uh I mean things as simple as just like the the volumes on the device? Uh, you know, if it's a phone, do you want your staff to be able to put it to do not disturb mode? Do you want them to be able to put it to a no-ring mute mode? You know, because if it's a phone and the phone call is coming in from you know a doctor and it's critical or the charge nurse and is trying to call a nurse, then uh, you know, you don't want it to be on mute. And so those are the kinds of things that you can consider here. And and uh and certainly, you know, working with your zebra sales engineer or uh or your you know value-added reseller, we can figure out you know how to uh how to get those settings the way that you want them, you know. And then what applications are the are there, you know, are the staff going to have access to? You know, there's things that we can do, um, you know, but like there's a flashlight app. So you may not want them to be able to pull down the settings and turn on the flashlight, but we could provide you with an app that would allow you to um to use the device as a flashlight and just put that icon on the on the screen while taking away you know all the other icons that they don't need and um shouldn't have access to.
SPEAKER_02:Yeah, I love the uh the EMM, like making sure you know what it can and can't do before you start. I've definitely seen that or OS upgrades are not not included. Um Lee, did you have any questions or or thoughts around the staging and provisioning and other pieces there?
SPEAKER_01:Yeah, I think some you know some other parts of that too is staging and provisioning. Tony, to what extent do like multiple sites come into question as well? Um, you talked a lot about on-device settings, but how often is if one site differs from another and what those devices are going to be doing, does that get overlooked typically, or is that something you find you have to bring up in order to make sure it happens?
SPEAKER_00:So that is something that I will always bring up, that I will always suggest to my customers. And uh, you know, and some of them would need a different configuration for different sites, because for instance, the Wi-Fi credentials might be different, um, you know, or things like that. But I would say for the most part, that's not the case. And at least in my uh experience, typically from site to site, all the basic settings are this the same. But what I do always recommend is that for different job functions. So for instance, um, just the applications that you uh that you show on the screen would be different for a nurse versus somebody that's in supply chain versus somebody that's in transport. And you know, so not everybody needs access to every application and by having it on there just you know gives people more opportunity to to get things in a state of disarray. So um so I always you know suggest that we take the devices that are going to be used in different areas and actually have configurations specific to those areas.
SPEAKER_01:Is is this the point in the process typically where you mentioned the different user groups, um, you know, supply chain versus a frontline clinician, for example. Is this the point in the process where you make sure that devices are getting in their hands or at least their persona, for lack of a better term, their user persona is being represented in the room in terms of the meetings and things like that?
SPEAKER_00:Yeah, absolutely. So this is where we would want to start building uh, you know, a few devices and start playing with those and start sharing those with the the other team members, you know, whether it be clinical or informatics um or supply chain, wherever this, you know, this particular project happens to be rolling out. And so um, so yeah, so that's where we would want to start doing that and actually, you know, just letting people just kind of play around with the devices and give us their feedback on it at this stage. It makes sense.
SPEAKER_02:And one of the things that came up was the the term first article, which I've I know I'm pretty familiar with this, but can you talk about what a what you think uh how you use the definition first article and what that looks like as you hand that off or as a a VAR or our partner hands it off to a customer?
SPEAKER_00:Absolutely. So that's yeah, that's exactly where once we've been making all these tweaks and we've been locking down the device and we've been uh sharing that with people to get their feedback. And then once we've uh got all that hardened to where uh you know we think it's gonna be the final um configuration that we're gonna roll out, then you know that's where we would identify our first article uh you know being in that configuration.
SPEAKER_02:And that's I I guess that the phrase I've always seen it as the first article is the thing that you're on day one, you're putting in front of the pilot users and getting feedback on. And it's definitely not the last article, but it's uh it is the first thing that goes in their hands. It's the one that's been it's been signed off and approved by by your IT IT and operation stakeholders before it gets in the hand of the clinicians and nurses, right?
SPEAKER_00:Right. It's the one that we think is gonna be the the final article, but it's probably not to your point. That's what the pilot's all about, right? Is we we actually want to have to make changes turn to the pilot. We want for people to find stuff.
SPEAKER_02:It's a good that's a good segue. I think that the third area you guys covered is uh pilot and and readiness, which is you know, getting devices into pilot and running a pilot for long enough, but not too long, um, and collecting data and feedback. But I guess when you think about a pilot, what is what is your thoughts around the the entry criteria for a pilot? And then you know what makes you know what what do you do along the way, and then what what is the exit criteria um for a pilot?
SPEAKER_00:Yeah, absolutely. So that you know, all the things that you want to identify in that pilot, um, I mean, first of all, it's don't let the pilot be too big and don't let it go too long. So 30 days, 60 days is probably the longest that I would ever recommend. Um, and keeping it as confined as possible. So again, in a hospital, that may be a nursing unit. So maybe it's 10 devices that are going to be used by you know 40 or 50 nurses over the the life of the pilot. But you want to identify you know exactly what we are expecting of this from all the different uh stakeholders. And so, you know, we we want to be getting feedback from the nurses who are using the devices. We certainly want to be getting feedback um from you know clinicians and and other people um during that pilot stage. And um, so you know, again, just identifying what everybody's responsibility is going to be during that pilot, and then um, you know, and certainly we want to uh identify methods for making changes during the pilot. So, you know, whenever somebody does come back and identifies you know something that we need to change, again, maybe it's a setting or or whatever, maybe it's because of the display is going dark too soon and they want the display to stay on for 10 minutes, um, you know, just those sorts of things is, you know, then how are we going to actually make those changes uh during the pilot and then identify whether or not you know that's the the setting that we do want because we don't want things getting changed and then rolling out into production later just because we forgot to put them back. So uh so again, the project manager would help a lot with that. And um you know, and then identifying what would be successful criteria also. So when we get to the end, what can we look at to to decide whether or not this was you know a successful pilot and we're ready to move on, or do we need to go back and um and you know step back a whole step and reevaluate and plan for another pilot?
SPEAKER_02:Yeah, one of the things that stood out to me, and you guys had talked about this and covered it in depth, and it it definitely rang true was around the um the readiness piece. And I can't remember if it was if it was Hector or you that called this out, but you know, when you put devices, a bunch of devices on a network, it's a lot different than having a device in a lab. And network readiness is something that a lot of people overlook. Can you talk about when you think about the infrastructure side of the network and these devices, you know, multiple devices being in a site, you you know, things to look out for, things that you've learned along the way?
SPEAKER_00:Sure. It so I and again, that is just um, I mean, to your point about just the like the network readiness, that is always a key because you know, as we've been doing the testing and you've got you know one or two or five devices sitting on the desk and you know, in IT and you're working on it, you know, that's one thing. But then whenever I've got 25 nurses in a huddle or I've got 300 nurses in the the cafeteria at lunchtime and everybody has their device in their pocket, what is that doing to my network? You know, what um what if uh you know the like a code blue goes out so that everybody's getting a notification at the same time? And um, you know, so those are the things that certainly need to be considered is you know, putting that stress on the various parts of the system, um, you know, not only the network, but then also applications. You know, are the servers, are the routers going to be able to handle um the data that's gonna be going through them? And um, so those are certainly all things that that we'd want to be uh thinking about and testing uh as much as possible during this pilot stage. And you know, and another thing I didn't mention before is about doing multi-stage uh pilots, which I've always thought is a really good idea too, that you pick two or three different areas uh within the hospital, and then we're gonna go into, you know, maybe like the ICU, which is typically a pretty quiet, uh, pretty slow-paced department. So maybe we want to start there because that's gonna give us an opportunity to really spend time with the nurses, getting feedback, to follow them as they're actually rounding, things like that, um, watching their workflows. And then, you know, maybe phase two, once that one was successful, we move into like the emergency department where things are a lot crazier and it's uh not always as easy to get nurses to sit down and talk with you because when they get a chance to take a break, they want to take a break. Um, so it's you know, but again, it it gives you an opportunity to see um you know everything in a different uh use case and a little bit different environment uh as you move through the pilot. So just even just keeping the pilot to one area is not always, I think, a great idea. I like to see multi phase pilots.
SPEAKER_01:I think you bring up an excellent point there there, Tony. From I I I almost look at that as like stress testing the pilot in different scenarios, but learning you know from the the less ri the lower risk scenario first before you try to. move on from there. Um one of the things you talked about too that I think is super important is defining the success criteria for a pilot. And I'm curious how you manage that with changes that occur in the pilot or things that you learn in the pilot that maybe aren't working. And then how to make sure the team stays focused on the the fact that the pilot is something where we're supposed to learn and determine what success looks like based on what we define as opposed to everything going 100% correct. Is there a way to keep the team on track with that mindset or stay positive? You know, just because something isn't working as anticipated doesn't mean it's broken. It just means we learned something. Correct.
SPEAKER_00:Right. And so and it's also important to remember you know so we had the success crit for success criteria of why are we even doing this project? Right? What what what did we want to get out of it? Is it to put you know mobility into the nurse's workflow so that they're not having to wheel around a while or use the computer in the room with their back to the patient. You know, now we're putting this Android device in their hands so they have more FaceTime with their patient and still all the capabilities. You know, is that the reason for this? Or is there some other um you know just primary reason for this whole project? And um so that's certainly one of the things that we want to keep in mind. And again I would hope that the project manager and the project owner are um you know staying very aware of that. But then there's also the other things that come along again with having this Android device that you're putting out there that now also have to be the success criteria of you know is it locked down enough that the devices aren't getting uh you know just put into various unusable states but then it's not locked down so much that they that the nurses can't use it right so the or the uh the you know whoever it is it's um whatever department it is it's going to be using the device. And so it's you know you there's that balance that you have to work out. And to me that is uh one of the success criteria as well is you know are people happy with it? Are they being able to use it for what they're supposed to use it for, but then we're not having them come back broken all the time and IT's having to deal with them and reconfigure them. So you know you you certainly want to work that balance and that is absolutely to me part of the success criteria.
SPEAKER_01:Yeah so it's the clinical mobility is supposed to make the work easier for the practicer, the practitioner to perform not we're trying to make it smoother not not harder, right? Exactly.
SPEAKER_00:Well and and again one of the other things that I've learned uh in my time in healthcare is nurses didn't go to nursing school to become technologists for the most part nurses went to nursing school because they want to take care of patients. They want to help people get better. They want to spend time with their patients. They don't want to spend time working on a computer they're going to use the computer as a tool just like they would use any other tool. And if it's not going to be easy for them, if it's not going to do what they need it to do, then they just won't use it. It will be a tool that just you know sits over on the the um on the counter in the nurses station. So you know it's really important that that we find that balance to all those things to to make the nurses happy. And then certainly when you start talking about supply chain and transport and areas like that, you know um I mean that's just a different kind of user. So we still have those same things that we want to balance uh for that other user push persona in that case. I like that I think it's really good insights.
SPEAKER_02:Really thinking about the the postpilot so like Tony was saying you've gotten through the pilot um you've maybe had a couple iterations of your first article uh which you know second third fourth article and gotten to the point where you have I think what what we refer to as golden image you have this this tested proven um setup for your various departments that you want to roll out to from there you go into deployment um which is seems easy you know just chip 2000 devices uh people will turn them on it should work um not necessarily the case I feel like most deployments you want to do phase deployments you want to have rollback uh the ability to back up you have uh certain supports you have to start training your help desk like I I guess Tony as as you think about the deployment what are the most important pieces that come to mind or that you've seen especially in the in the hospital environment for uh for pushing and deploying once you've gotten through pilot and have your your golden image I I think you just hit on a lot of them uh so certainly training training training it's the the again the the deployments that I've seen that have not been successful or not very successful are the ones where they just just gave the devices to the users.
SPEAKER_00:Here you go and you really can't do that you've got to actually this is how you turn it on this is how you log into it this is how you get into the application um you know this is how you can change the volume you know just all those and and as just remedial as that seems because we all have phones and we're all very used to those things it's not necessarily always the case there are uh people uh in the you know the hospitals that need that training and so if they don't then maybe they just aren't paying attention to you but uh but certainly offering that and making sure that that uh your training staff is available and again you mentioned the help desk you you know you gotta make sure that the help desk is ready on day one um actually day negative one you want your help desk ready because whenever you give people the devices you're gonna start getting those phone calls you need to have your RMA process in place because devices will break um you know sometimes people get into emergency situations and they will use it as a weapon and then it needs to go back and get the the screen fixed on it again or whatever. So you know we need to have all those things in place on day one of deployment and and not be putting those processes together after the fact. And um and and again the the phase deployment as you mentioned I think is um is very critical to do it just one area at a time so that if we do find something that we missed in the pilot, if we need to go back and make changes, I don't want to have to go back and make changes to all 2500 devices that we're rolling out. I'd really rather just do the hundred that we've rolled out so far. So it's you know the the opportunity to just go department by department and uh come across any more you know things that we need to work on that we need to modify um you know then having the ability to just pause and take care of that as we go without being you know affecting the entire enterprise.
SPEAKER_01:And Tony you we talked you know in the pilot phase around having success criteria um similarly in a deployment phase of a project after deployment what constitutes a successful or healthy rollout versus one where maybe you're just not hearing people complain uh and so it's quiet but so you assume everything's good but when you dig in it's actually not is there a similar set of success criteria for the deployment that you need to have in addition to you know the one you might have for the pilot?
SPEAKER_00:So I absolutely think I mean you know any project should have an ROI. So you know whoever the project owner is should be you know monitoring the project to you know to to see if it's uh achieving its goals and you know within budget and everything else. So that's certainly success criteria uh going through the deployment and uh in post-deployment. But then uh I think that one of the other you know certainly you should I don't know if everybody defined the success criteria in during deployment and probably they should um could but it is very similar to the pilot and you want to have happy users you want to have users that you know to your point it's just because they're not complaining because things are quiet sometimes they don't complain because they're just so mad and they're not using them whatever it is that we you know put out there. And so everything's just in a drawer somewhere and we think that everybody's happy because they're not opening you know help desk tickets but the fact is is that we just spent all this money and all this you know team effort and nothing's actually being used. So um so that's where we get into rounding and that's where IT informatics um uh senior leadership should be going and talking to the users and literally just stopping them in their shift and asking them how are things going you know are you happy with this are you unhappy with it anything you think that we should change on it um and again in my successful deployments I see that I see that uh that the um that IT and informatics and nursing leadership are out there visiting with the nurses or that um you know if it's a a supply chain that uh that the supply chain management is actually staying in touch with um with IT and with the users and uh you know it's a constant thing that and that doesn't end that just because we're through the pilot or we're through deployment that shouldn't end because we can always find uh you know places to improve and make changes.
SPEAKER_02:So that's a good segue into like the I think the fifth area you guys covered in your presentation which is actually the the post-deployment support and the thing that stood out to me the most was I think you you sort of just touched on it here but the I think you you framed it as the 28 days later um you know making sure you're inspecting and continuing to iterate with your expectations and then the other one was analytics actually having analytics off the devices like usage logins app uh a lot of those pieces I I guess for you when you think of the I call it day two but you've rolled out you've gotten your 10,000 devices out the door what are those next four months for post-deployment support look like when when you guys are working with clients?
SPEAKER_00:Yeah absolutely and so this is where you know the and we certainly we offer some tools your MDM is going to have some functionality um you know just for monitoring the devices and so for instance we have a utility called visibility IQ that will let you go in and actually look at the utilization of your devices. And so you can see department by department site by site um how many devices are being used versus how many are deployed there. So you know for instance do I have a department that has 80 devices in it but only 15 are ever in use at a time and then I have another department that has 20 devices and all 20 are always in use. You know maybe I need to be moving things around maybe we didn't um you know deploy them uh in the right numbers to the right departments. So those are things that you can do um and with that same tool and certainly with the MDM you can do it as well is look to see when was the last time you know devices checked in did I deploy a thousand devices and two of them haven't checked in in the last you know 30 days um you know where where are those it's you know what what are you know did they walk away were they stolen or they just turned off at a desk um but again monitoring those things and not waiting 30 days right so monitoring those things you know on day two and day five and just you know keeping up with those trends um so that you can um you know research and identify those uh those issues uh uh as they they come up and so you know that's I guess what I would consider asset tracking uh and utilization and then certainly there's other um ways that we can monitor like the application and the system performance um you know network performance things like that so there's you know all sorts of tools out there some from Zebra some from other providers um for you know just just monitoring the system after the fact and making sure that things are being utilized um to you know to a high efficiency makes a ton of sense Lee for you I know you've done a lot of these these large deployments are the things that stand out to you whether it's healthcare even some of the other industries in regards to the the the day two supports and just lessons learned you've had you know three months on after you've gotten to myself door I think something I'd like to echo is actually something that that Tony brought up is um I think with technology there can be uh an inclination to once something is deployed and working let's say for 90 days to assume that you're done and think that like well that's finished we can now do something else and that will just continue to run in perpetuity.
SPEAKER_01:But to Tony's point you have this is a constant thing that you have to monitor and keep updates with. So from that perspective I think you made up I one of the my favorite things that you said Tony was that's where rounding comes in. That's where getting on the floor and talking to those end users and actually understanding what problems or issues they may be having or what successes they're having on those devices. The good thing is you know the device itself can be changed in terms of the configuration and how um the users are interacting with it and you can always improve on that. So it's a it's a living breathing thing and I think that's one thing that a lot of people tend to lose uh perspective on is just this is done. I'm now going to move on to um redoing all the access points in the building or you know changing all my door locks because it comes in the same department. But you know you really need to be thinking of perpetual improvement in this.
SPEAKER_00:Absolutely I just one example of that I uh one of my customers they had a uh our phone app was on their their zebra device and after we had done deployment they came back and they wanted to put some uh speed dial numbers on the main screen just on the regular phone screen when you open the app and so we did that for them we gave them the configuration to put the speed dial numbers on there but then like the pharmacy started getting 400 phone calls a day from people just accidentally hitting the button and so then they came back and they said well can we put them in a folder somewhere and so we did that so we put a folder on the main screen to put the speed dials in that so again that's the kind of thing we got the feedback that we want you to add this feature that we did and then we got you know oh this isn't really working the way we want um and so we went back and changed it again and now they're really happy now they love how it works.
SPEAKER_01:So yeah I would say it's just that Brad for me the biggest thing is now that it's out you can always improve on it you can always change it.
SPEAKER_00:Fortunately or unfortunately it's something you're always going to have to pay attention to correct you know and I again one of my uh comments to IT managers is always you know you didn't put all those Windows workstations out there and just walk away from those. And so again this isn't just a phone you're putting a device with an operating system on it and it has to be managed just like all your Windows workstations have to be managed and you will have to manage software and versions of apps and versions of operating system and patches and all those things that you know it's not any different. And so uh so IT needs to commit to having those resources up front.
SPEAKER_01:Yeah I think it's interesting that there is that disconnect there um when people are like well you know there's a phone it can do what it can do it all. And then you're like well you know actually you do have to you do have to manage monitor and manage these things.
SPEAKER_02:Yeah absolutely awesome um and so the let's that cover the five areas and then Tony I really appreciate that presentation and you also just chat with us today about it. And I'll I'll reiterate this I know I've said this to people all the time one of the the biggest advantages I I see around working with Zebra is uh there are sales engineering teams across all the different divisions like the like Tony's team where if you need help if you need guidance years and years of experience doing this mobility you guys bring a wealth of knowledge and um it's just awesome so if you are uh if you're out there looking for devices uh you know zebra has some incredible sales engineers that can help you out and um support you in that so definitely reach out to to Tony and his uh his um compatriots across different divisions depending on who you're working with but um just want to say I really appreciate it um Tony I know you guys it's a zebra.com is all website uh in and you know the healthcare organization I think most uh most folks know how to get get get in touch with their uh their zebra sales we're app for their SD through their reseller um anything else you need to call out or wanted to to to uh talk about for zebra uh no I I think that you hit it so yes so zebra.com is our website um certainly you can get a hold of us uh through that and um and yes I really appreciate this opportunity with you guys really enjoyed working with Blue Fletch awesome excellent well thanks for joining us today and uh as always if anyone has any questions for Blue Fletch we can reach out to us at bluefletch.com or if you have questions for Tony and his team uh take a look at zebra.com some great devices great engineering and Lee and Tony thanks for uh for joining me today on this thanks a lot thank you for tuning in to Frontline Mobility Edge if you enjoyed this episode make sure to subscribe for more content every month or if you'd like to learn more about blue fletch check out the link in the description or visit at bluefletch.com. See you next time