Critical Control Management – A Configuration Case Study with Mitchell Services

Um, this is Sarah from Myosh, and welcome to this week's webinar. Uh, the topic today is critical control management, and it's a configuration case study with Mitchell Services. So, before I introduce the presenters, just a little bit of housekeeping. If you have any questions, there's a Q&A panel down there. Please use that to ask questions, and we'll get to hopefully most of those at the end of the session. If you want to chat to me directly, or any of the presenters, or everyone, you can use the chat panel. Um, we are recording this session. Um, just to note on that, if you want a copy of the recording, or if you want a copy of the slides, I'm going to put a link in the chat. We've got a web page. You'll just need to register your interest in the module on that web page, and we'll share that recording to you directly later via email.

So, um, today's presenters, we've got, uh, Josh Bryant from Mitchell Services. He's the General Manager of People and Risk. Mitchell Services Limited is a leading provider of drilling services to the global exploration, mining, and energy industries. And we also have Adrian Manasses, and he's the Business Development, um, Manager for Myosh. For those of you who don't know already, Myosh is a configurable cloud-based software that adopts to unique organizational requirements. So, thank you, Josh. Thank you, Adrian. Over to you, Josh.

Thank you. Thanks for everyone for tuning in, and those who will watch this at a, at a later date. Uh, I'll, I'll talk a little bit about the business first. Um, okay, sorry, a bit too quick on the trigger. Um, so first, introduce the company and myself. So, Mitchell Services, we're, we're a drilling business. We're based in Australia. Um, but I really don't want you to take the mindset that, oh, this is all about mining, etcetera. I really just want you, as an audience member, to have a look at it from the, from the terms of a business that implemented critical risk control that had never done it before, and then worked very closely with, uh, with Myosh on, on creating a configurable, um, critical, uh, control management solution.

So, we have over 650 employees all throughout Australia. We work as two businesses. So, we're Mitchell Services, and we're also Deep Core. Mainly based in Victoria, Deep Core Drilling. We work in a large range of environments. So, we work everywhere from surface operations near mine, and we even have underground operations as well. So, we've been in the industry for probably just over 50 years, and we've, we've actually received a lot of industry recognition for some of the work that we've done, particularly around our culture and applying the safety philosophy of Human and Organizational Performance.

So, we moved across to the Myosh platform probably about mid-last year, and, you know, we, we use that for all our field leadership, incident investigation, uh, injury management, etcetera. So, within our business, we operate under the philosophy of Human and Organizational Performance. And I want to thank Andy Shawn for allowing me to use this graphic. But Human Organizational Performance is made up of like five philosophies. So, the first philosophy is that error is normal, blame fixes nothing, systems drive behavior, learning is vital, and response matters. So, we've been operating with these philosophies probably for the last three to four years. But there's one, there's one that's always added on. It's usually added on by Dr. Todd Conklin, and it's around the factor around controls, and that controls save lives.

So, although we've been doing the, the top five quite well, we really wanted to put some work in on, do we really have an understanding of the controls in our business, particularly the cross controls for our fatal risk or high-risk tasks within the mining industry? Particularly in Queensland, unfortunately, we had five fatalities in a short period of time, and we had a number of operations shut down and did a safety reset. And then there was an independent review conducted, and this was released in February 2020 by Sean Brady. And one of the things that was highlighted in this review, and it's under recommendation five, was a focus on the effectiveness of your controls to manage hazards, also about implementing more effective controls. And they also found that after all these events and incidents, etcetera, that a lot of the controls that were put in place were administrative in nature. So, that was just something that we really wanted to take on board before we started this journey. Let's make sure that the controls are actually effective before we implement them. Make sure they're right and they follow the hierarchy of controls that are effective, and let's stay away from administrative controls.

The Queensland Coal Mining Board of Inquiry also released a report after an event in the middle of last year. And one of the, one of the big things that they highlighted in their report was that they believe that ongoing monitoring of critical controls is actually an appropriate lead indicator. So, stay away from, you know, total recordable injury frequency rate and, and all the lag indicators. Really use monitoring of your critical controls as an actual lead indicator. But one thing they did highlight is that if it's not done correctly, it can really add an excessive administrative burden onto an organization. And we, that was one thing that really stood out for us. Like, we cannot add more admin to what we already do in our business. And the management team also was trying to shy away from adding more and more software or processes into the business as well.

So, a leading guide in the implementation of critical risk management is from the ICMM guide. This is available online. It's been out since, I think, 2000, 2009 or 2015. So, this has been freely available. And we're not the first ones to implement critical controls. But for me, it was always something that was done by really large companies. It took a lot of resources, took a lot of external resources as well to do this work. And, and to do it well, it needed a lot of money to do it, a lot of specialist skills to do it. But this is, this is really, you know, this is the most important thing in our business is making sure that we've got critical controls to really control those high-risk hazards that, you know, our people are exposed to.

So, the guide, um, actually gives a, basically a flow of how things should be done when you're, when you're looking at implementing, uh, critical risk. So, there's planning, then you identify your material unwanted events, then look at the controls for those, select the critical controls, then look at your reporting and who's going to be accountable for it, and then look at the implementation of these. So, with the material unwanted events, you, um, some of this information is, is available quite freely if you search hard enough throughout Google. And what we want to do is go through and go, what are the actual fatal risks that apply to our operations? So, looking at all this data, what will apply to our operations? And the thing is, you can't just sit in the room with a group of HSE people to do this. You really need to lean on the experience of the organization and get that variety of skills and backgrounds going through all these events, going, could this really happen on one of our sites? Have you seen this? Have you heard this anywhere? We, you know, let's look at our own data, let's look at our own events and our own incidents and see, you know, what's happened, what could apply for, apply to us. So, really worked closely with our workforce on these material unwanted events. And the biggest thing is for us, and the guidance we got from Mark Olson, was that they have to be plausible. It's not just, oh, yeah, that could happen on my site. Is that plausible? Could that actually happen on one of our sites?

So, once we determined our material unwanted events, um, we said, oh, excellent. Look at this. We already had a communication sort of in place talking about fatal risk that the workforce termed the "Phalate." So, the workforce actually came up with this term "Phalate." And the way they approach that is that they sort of wrap their site in a bubble and go, when I'm at my site, these are the eight things that I really need to focus on and make sure that I've got controls in place and I'm aware of the hazards. And when I'm operating on my jewelry. But when we've done this material unwanted event work, we actually came out with 20 credible scenarios that could actually impact this. So, rather than getting rid of the "Phalate," which is something that the workforce came up with, and implementing a new, like, 20 material fatal risks, and we actually combined them and just said that these operational risks actually fall under the fatal eight. So, they're not new. We're not trying to push something new onto you. We're just trying to expand out the "Phalate" and really hone in on the controls for the, for the hazards that can actually, um, kill people on our sites. Again, these pictograms aren't new. I've seen similar examples from many other mines. But the one thing that our workforce wanted was when there was events specific to drilling. And the example there is entanglement. Like, have a picture of someone getting entangled, the way that it would happen on our drill site. When you look at a dropped object, like that's a drill pipe falling from a draw rig. Make it look like it's from our sites. Don't get some generic stuff online. It really needs to be stuff that looks like our workplaces so that'll actually stand out.

So, once we have our material unwanted events, we start to work through the controls. A lot of people use bow tie diagrams. Again, small business may not have access to bow tie type programs, so we were just using Excel and still working through the workforce. So, we came up with the risk scenarios, what are the causes of those risks, and then we link the preventive controls and mitigating controls to those events. And then what the ICMM guide does is it actually gives you a decision tree to work through what's a critical control and what's not. The one thing that the organization did, and particularly the leadership team made a commitment to, is that when we were doing the workshops with the workforce, if they said to us, "That is critical to us. I don't care about the decision tree. That is something that's really important. We believe it's critical," then we would actually make that a critical control. We could actually listen and would actually put the work in to make sure that we understood those critical controls.

So, once we had the critical controls, the ICMM, the ICMM guide actually gives guidance on how you should break those up and understand how those critical controls work, what's needed, how many checks, what processes are you going to use to check those. It just didn't give enough detail for us. So, we, we had some, um, we actually just watched a webinar online by a gentleman, Christian Young, and he actually broke down how we should really look at our controls and maybe in a bit more detail in the performance parameters. So, again, just using Excel, we're just using looking at our controls, going, okay, for each control, each critical control, what's the functionality? What's the availability of this control? How reliable does it have to be? How does it survive, like, what's its ability to survive a damage event? What does it depend on? What's its compatibility with other controls or systems? And is there any redundancy for this control if it were to fail?

So, we've come up with these performance standards. And for me, this is how I always used to look at critical risks is that you do all these performance standards and bow ties, and everyone would sit in the room, and they'd point at the person typing in the bow tie, and let's fix this, etcetera. So, we really workshop these with our teams to make sure that we understood that these were the right critical controls and the performance standards contained the right information, and they were actually things that we could practically implement in the business.

So, we went back to the workforce and said, okay, for these critical controls, we now need to do some tasks to do the verification. We need to make sure these are right. So, we worked very closely with our workforce in the design of the system, getting their feedback, how we're going to communicate this, what's it going to look like in the tablet. And again, the first pushback is, "Ah, more stuff, more work for us to do, more things. Ah, what else you're going to add? Oh, is this another software I have to, you have to learn and use?" It was like, no, actually, we're going to lean on the routines that we currently do, particularly the inspections. And we were doing, we were doing inspections outside the system. And when we implemented Myosh in the middle of the year, we actually looked at the inspections module and started to work it. And the, the teams in the field were, "If we're going to use the inspections module, how are you going to highlight to us which ones are the other critical risks and which ones aren't?" And because of, because of the inspections module in Myosh, it actually allows you to add pictures. So, you can actually add a picture of the control, you can add a picture of your pictogram of you, of your risk. And that's what, that's what was preferred by the workforce. They actually preferred having a pictogram of the critical risk that they were actually going out to verify. So, they were verifying an entanglement risk, there's the pictogram for verification for entanglement, and they would actually pause and go, "This is really important. This is a critical control. We've got to make sure this is right." And what the inspections module in Myosh allows you to do is that if it's a "no," it forces you to put a comment in. So, if it's a "no," you need to give detail about what you've found for that critical control to control the file, and what action are you going to take prior to work, um, proceeding.

So, this is an absolute positive. But again, going out and looking at physical controls. And when we first started the process, we really started to learn that although we were doing verifications and controls were in place, so we're looking at controls like interlocks, looking at whip checks for higher energy, looking at isolation points, spin cages for entanglement, we actually saw that there was a lack of standardization across some of our fleet for our controls. So, doing this process really opened your eyes to go, it's all good that the control may or may not be there, but is it the same across the drill fleet? And let's get some standardization in place. And because the Myosh inspections module is online, we've been able to use technology such as RealWear in remote sites and conduct inspections on our drill fleet through the inspections module as we're walking around. And, you know, we can hotspot into the rig and, and do a, a joint inspection with people like our CEO and our board, and they can actually do these critical control verifications in the field as well.

The, the one thing that I've really got out of this implementation of this critical risk management is that other CRMs that I've seen will focus on one risk. It will be, "Okay, let's look at the risk of entanglement," and there might be three questions or five questions for entanglement, and then it's like, "Okay, yep, they're in place. No problems." And then they move on. The way we approached it with our workforce, though, is to go, "Let's not look at the risk. Let's look at work. Let's look at the task. Let's look at the site." So, by using the inspections module, we can actually walk around one of our drill sites and verify all of our risks that apply to that site and that piece of machinery. So, we have verifications for our surface fleet, our underground, all different types of rigs as well. And so that's allowing us to verify all of our critical risks that apply to that site at once and making sure that the controls are in place for each of those risks. So, just, it basically gives a snapshot of the critical risk management for the entire site all at once.

Um, and again, we were, we were working with the inspections module, exporting the data into Excel, um, having a look at it. And Myosh were working very closely with us and seeing what we were doing. And probably the biggest thing is that they were actually seeing the impact this was having on the business in a positive way. It was having a real positive impact because it was doing the right work. Like, this is critical risk. This is, it's actually making a difference to a business. And so Myosh have actually created a new critical control module within the software that actually now links in and puts in all the performance standards and links in any verification activity that's done against that standard. So, that we can actually see how our critical risks are being managed in the business. And this has been the, it's been a game-changer for us as a business because it actually gives us a lot of transparency on how we're performing. We can look at each risk and is it being managed? We can look at each control for passes and fails and actually take action on those that fail. Um, and we can do it by rig, we can do it by client, we can do it by site. So, it's just, for a, for a business our size, it's just really opened our eyes. There is a saying within critical risk management that you should fear the green and embrace the red. And that's one big thing we've had is that if we hadn't have implemented the critical risk management, and now that we've got the visibility through the dashboards in Myosh, we can actually see where controls are failing in our business and where we need to take action and make sure that we've got action through.

So, throughout this process, what we've really learned is that, as I said at the beginning, I always thought that critical risk management was in the realm of like the massive companies, like, you know, they, they've got all the dollars, they can get all the resources. But we actually were able to do this work ourselves in collaboration with the front line because they've got all the answers. They know where all the risks are. They know what needs to be in place. So, really getting their input helped standardize our processes and also standardize our controls. It didn't introduce safety clutter. And again, it wasn't another system. It wasn't another process. We were using normal routines. So, we used the inspection routines to implement critical control verification, and the workforce took it up easily because they didn't see it as min, as administration. They could actually see what it was being used for. And in our case, in collaboration with Myosh, they were watching what we were doing the whole time, and the software was starting to be configured for us so that we could use the processes.

So, for us, and hence the webinar, is that we've now got a single HSE system, and we can do our critical control verification, our incident management, our injury management, etcetera, all in the one place. It's been easily adopted. Uh, it's easily configurable. So, if we want to change a question, we can actually do it ourselves. We don't need to lean into the software and go, "Oh, no, we've got to wait till seven other people want this." We've actually been able, we can make the changes ourselves. And again, it's that whole of work experience, looking at risk for whole of work, and not just a single risk. And as you saw on the tables before, it's got easy reporting and visibility.

So, I'm going to hand over to Adrian. He's actually going to demonstrate how the, how the software works and this new critical risk module and the massive change that it's made in our business.

Fantastic. Thank you, Josh. Um, and welcome everybody. Um, I'd like to also extend, uh, the, uh, Josh to be able to attend, uh, questions at the end, and also welcome Josh to even interrupt me or combine with me in a fairly informal way as, um, I go through the system and I go through, uh, the presentation, um, to put any additional experiences that he may have had. So, we'll be working together throughout this, uh, next session.

Um, okay, first of all, I'm just going to share my screen. So, just be with me for two seconds. Okay. So, um, let's go through the process. I've got quite a few screens up at the moment, so just bear with me while I'm getting my screens correct. So, I'm working up a couple of different screens here.

First of all, let's look at the first slide. So, our approach to critical control management was to basically support the process. So, look at the, look at the process that Josh was talking about, and basically make sure that we could make it as easy as possible to do it. So, one of those is to make sure that everyday processes can be used to verify critical controls. By the way, what I'm going to do with this presentation, I'm going to go through a few slides, and towards the end, I'm going to start actually showing the system and demonstrating through a few scenarios of actually how it's working or how it can work in practice. So, first of all, I'll be talking about the, our approach and a variety of different topics. I'll go through and do a demonstration, and then I'll talk about some of the next steps and some of the things that we're about to be doing fairly shortly.

Okay, so just jumping back again. So, everyday processes, verifying critical controls, making sure that it's easy to do, and that it's not just an extra thing that someone has to do. We make sure that it integrates with other modules and processes, both within Myosh and also within other systems. So, if there's an observations module, or an incidents module, or any other sort of module, make sure that it can actually be part of the critical control management process. We want to make sure that when something has become ineffective or uncontrolled, that we, that the system can escalate configurably to the appropriate people. So, you don't want to, you don't want people jumping up and down and getting in a panic, but you do want people to be notified to make sure that a controller is being managed, and that you can review it and make sure that it's in place and doesn't impact the business. The other thing you want to be able to do is make sure that you can report on the critical controls, so you can see what's happened over a period of time, and you get some sort of idea of trends, and you can look at, you can look at the reporting and look at the performance standards that Josh was talking about, and say, "Okay, well, based on the reports we've got, we can see there's failures in certain areas. Let's review our performance standards. Let's review, um, particular areas of business and so forth."

Okay, so, um, moving to the next slide. So, basically, verifying your critical control. So, every time you check something, you're doing a verification. But we want, the system is configurable. So, we want to, we made it, we've made it so when you do an inspection, or you do an observation, or some other process, that if you're verifying or checking a critical control, whether it passes or fails, that it actually records that you've verified that control. So, using Myosh, Mitchell Services verifies, verifies thousands of critical controls every month. Now, depending upon the size of your business, you may do a lot more of those. Now, it's an automated process, um, using your everyday inspections and, and other modules. So, what it allows you to do when you're generating the large number of verification documents is, you know, how many you're doing, are you doing enough? You can check that. You know, where you're doing them, are you doing them on pieces of equipment, are you doing a particular sites, and so forth? What are you doing them on? Um, you can see what's failed and what's passed. You can see where your, what controls actually need more attention, and essentially leading to, to review, and you can also see which critical risks have become uncontrolled.

So, this is a screen of the critical control verification. So, there could be thousands of these, and you can basically filter this information. And inside each of these documents, you'll have a lot more information that can be reported on, and that information then goes through the dashboard.

Okay, so what is the setup? Okay, first of all, using the, the processes that, um, and the methodologies that Josh was talking about, you identify your critical risks and you enter them into the system. And from my perspective, I'm going to assume that this has already been done and in the demonstration. So, the critical risks have been entered, the associated critical controls, and their, and their performance standards have also been, uh, put in there too. You then go through and you configure the system to be able to, um, essentially work with those critical risks. So, you configure your inspections. So, you can build your own inspections, and you can configure yourself. In fact, Mitchell Services did all the configuration themselves once we went through a little bit of training. So, basically, you need to make sure that if there's a question that's a critical control in an inspection, that it's set up and configured so it creates a control verification document in the critical control management module. You also set up your notifications and escalations when things, when controls become ineffective, or when risks have become uncontrolled. So, again, it's configured. So, you set it up to your requirements. Who do you want those to go to? Do you have particular risk owners? Do you have particular people that need to know, be notified immediately? And finally, you look at dashboards and analytics to understand the performance, um, of, of, uh, of all your verifications and, and, and risks and controls and so forth.

So, you can, sorry, Adrian. All I was going to add in there, mate, is that because of that configuration can be done by the owner, and you don't have to rely on Myosh, gives a lot more ownership. Uh, the, probably one of the, the bigger things with this, um, with this implementation and working with Myosh is the amount of upskilling and knowledge by the HSE team and anyone else who was involved because it's our configuration, and we can do it, and we know what's in it. And, you know, you're not having to rely on developers to do, you know, special things for you. You can actually do this yourself. And, and I think that's, it meant that Mitchell Services, because we don't necessarily know what Mitchell Services want to report on, and we don't necessarily know what they want to escalate and to who, and so forth. So, I think that's, that's an important point. Um, it allowed Mitchell Services to define those things themselves. So, we've got our base templates, but they're able to change those templates and configure it so as to who gets notified. Um, so I don't necessarily want people to panic when a control becomes ineffective. They want it to be dealt with. So, they didn't want to necessarily go to the, to the Managing Director, for example. They wanted to go to a particular path, and they can, and they can control that and have been able to control that themselves.

So, once you've done that, you basically build your dashboards, you set your KPIs. So, basically, in some cases, where you say, "Well, I expect to do a certain number of verifications," maybe based on equipment or site or particular risks or particular controls, and then you can use those dashboard reports to then review that information. And again, I'll show you some of the dashboards a little bit, a little bit later on in, in the session.

Okay, so let's talk a little bit about some of the technology behind it and some of the things that we're doing. Now, this doesn't just apply to smart inspections, but it is a fairly key area for the verifications. Um, historically, inspection software is really just asking questions and putting in answers and not much else happens. It's basically just copied, copied what paper's done. And if the person doing the verification or doing the inspection doesn't really know that something really important has failed, basically nothing happens until someone goes and reviews that inspection document. And even if they do, if so, you might get, you might get an untrained person going in there going, "Yeah, tick, tick, tick, tick, tick. Yeah, submit." And then you might have an uncontrolled risk that needs to be looked at fairly urgently. You may not know about it for quite some time.

So, with a smart inspection, things happen when you answer questions and you submit the inspection. So, does background processes occur, and the person doing the inspection doesn't necessarily need to know what's actually going on in the back end. So, people are getting notified, workflow processes, and workflow workflows are changing. So, if you've got a non-critical risk, it's not going to do much. If you've got a critical risk, it might send an action to somebody. It might, it will update the status of the critical control. It'll update the status of the critical risk, and so on and so forth. So, they can be configured to do whatever you want them to do, based on your specific requirements. And again, I'll go through some examples of those fairly shortly. So, basically, and that led me to the next point was automatically create these things. So, it, it will, you answer a certain question, it might automatically create an action. It may automatically do something, but it'll make sure that the business is aware that something needs to be done. And with a critical control, it needs to be done fairly urgently in most cases.

Okay, so I'm about to go into the actual system itself. And first of all, what we've looked at is the supporting of the process. So, as I said, you identify your critical risks, and as an example here, and then you identify your critical controls. So, what I'm going to do right now is I'm going to drag over one of my screens, and I'm just going to walk through some of the screens at the moment, and I'll walk through more of those a little bit later on. So, I'm in the risk assessment component, and I'm going to look at the Tyre and Rim Failure critical risk. Okay, I'm not going to go through every single aspect of these forms either. A, it'll probably bore you, and B, it's not necessary because we're recording a lot of information in some of these forms about performance measures, um, and performance standards that Josh talked about before. Um, we will be doing more webinars, um, I think with Mark Alston in a few weeks' time, which actually we'll talk about those in more detail. What you can see here is we've got a critical risk assessment. You can see that this is fairly standard at the moment. You just got, you know, a description and a score, um, some causes, you've got the linked controls here, and at the moment, you can see that they're all green. In fact, everything here is green, which is all my critical risks. That one hasn't been assessed, but what's going to happen through the session today is as things begin to fail, so I'm going to do some inspections and observations and different things, and things will start to fail, and these things will start to change color, and the critical controls will also change status and start to change color. So, at the moment, you can see everything's looking pretty good. My controls are effective. My, this particular critical risk, and the other ones here, apart from the not assessed one, are controlled.

Okay, so if I go into, say, one of the critical controls, okay, so a lot of the information that Mitchell Services was putting in spreadsheets before is actually now being put into sections in here. So, I'm not going to go through each of these sections, maybe just, um, one of these. So, it's asking questions about, in this case, the survivability. So, in this case, it's not designed to survive a significant damage event, but basically, there's questions throughout here that guide you through that. So, there'll be details of the critical control, what is the control name, and so on and so forth, who's the owner. There'll be a control history, and I'll go into that in a little bit more detail shortly, into the control history, because that's actually up being updated as things happen as well. Let's, um, close that down for a second, and let's actually go into some of the other forms just quickly.

So, while you move into the other forms, Adrian, what I'll do is that while, when you've got the performance standards within the system, you can actually trigger how often you want to review those standards. And because the standard is sort of the overarching document that controls the, the critical risk, everything can link back to that critical control performance standard. And again, like Adrian's about to go through, it keeps a record of every pass and fail for that one control. So, what you'll see here is, depending upon the module, the verification area that we're looking at, and we can have multiple verification forms. In this particular case, I've got one here. We've got some details. I'll go into that one. This is the verification. So, this is what was created when an inspection question was answered in a certain way, whether it was, whether that answered yes or no, it actually, it was, uh, if it was not applicable, it may not have actually created this, but if it was say, yes or no, it created this document. And then tells you, you know, what was the date, what's the verification date, what was the critical control name, um, uh, in some cases, which, which risks it applied to, what was the source, so it came from an inspection, whether it passed or failed, what was the equipment number, and anything else you wanted to store in there as well, including things like the hierarchy. So, you might have divisions, department, sites, etcetera. Now, you've got a lot of detail inside each of these documents, but you can also, you can change this. So, it can actually show extra columns to show that detail if you want to. And this information is reported on in the dashboard. But I can also do a little bit of work from here as well. So, if I want to look at my items of the stops, I can say, "They're the ones that have stopped." So, I can filter by date if I want to. So, I can go through and say, "I want to look between this date and this date," and it'll go through the appropriate filter process and show me the information.

So, ordinarily, you probably don't go in here that often because you'll probably look at your dashboards instead. But as you work through here, you'll see that things are actually being generated.

Okay, so let's move that out of the way for a moment, and then let's move to the next slide.

Okay, so we're onto some of our scenarios now. So, I'm going to go through three scenarios. The first one I'm going to go into in more detail. So, I want you to actually see what happens when we're going through an inspection. And again, I've set these up so we just have to answer a question and submit it, rather than you watching me fill out a lot of information. So, we're going to see that the verification document was created, the, the risk that the risk has become uncontrolled, um, that the critical controls become ineffective, we'll see that notifications will have been generated, and we'll also see an action has actually been generated within the systems or created in the system as well.

So, let me drag my screen back over for a moment. And the other thing I'd like to show is that I've got my mobile app as well. I could equally be doing this on my mobile device. In fact, I believe Mitchell Services does most of these things on iPads. Um, so it's all, it's all iPad, and it's all underground, offline, in the middle of nowhere, and as soon as we come back in the connectivity, it just syncs and, um, updates the system. Right. So, I can answer the question on the, on the, on the phone. I'm going to get rid of that for the moment and then just leave my phone up there for a moment. It's going to, um, and then I may do some more work on the phone a little bit later on. So, in this case here, I'm going to say no. Um, there's, I'm, I'm in the middle of a critical control verification. I can see a picture in the inspection because, as Josh mentioned, you can put pictures in these things to show what's right or what's not right, or you can put in those pictograms or whatever you want. It's all configurable. So, I've chosen no, and what this is, is it's configured to a critical control. When I complete it, so I'm going to hit the complete button, and if there's any mandatory fields, it's going to stop me, but there shouldn't be in this case because I believe I've filled them all out.

Okay, so what I'm going to do next is I'm going to, um, I'm going to basically, um, go back to the critical control management module. Now, my, why I pause slightly there is because I've got my, my, my, uh, Apple Watch on. Um, the actual a notification, and unfortunately, I was hoping it would go to my phone. It might do in a little while, but it's actually gone to my watch instead. So, I've got a notification sitting on my watch at the moment, says "Tyre and Rim critical control failure." So, it's actually notified me that that critical control has in fact failed, um, and that sort of buzzed me into like, "Oh, okay, something's happened." Um, if you don't have a watch, obviously, that would go to the screen instead. I'm just going to move that out of the way for the moment, and then I'm going to go back to my critical control module.

Okay, so you notice everything was green before. Okay, now everything's not green, uh, except for obviously the not assessed one. So, something's happened. So, I'm, I've been notified, and I've gone into the critical control module, and I can see, "Okay, we've got a not controlled critical risk" that's happened here. I'm going to click on that critical, critical risk, and I'm going to scroll down, and straight away, I can actually see the critical control that's actually failed. So, I'm going to go into that critical control. Okay, once I go into that critical control, I can also check the control history. So, what's happening here is this, as we're getting failures, the failures, in other words, when we're doing verifications and like an inspection, we've had, we've answered "no," it's not in place, um, it's now updating this, and it's keep giving me a list of all the failures. So, we've had a failure of this piece of equipment, of non-conformance, Martin Manager was doing it, and I could click there, and I could actually open up the inspection, um, that we're completing earlier. So, in this particular case, we can see that it's basically updated that to the one that I've just done. And it, Adrian, we may have lost your sound. Can you just verify that? Josh, can you hear me? Yeah, I can hear you. I think Adrian's just dropped out unfortunately. Okay, all right. Well, we'll just wait a couple of minutes. Um, I think, um, in the meantime, yeah, if anyone does have questions, you can start typing them in that Q&A panel, um, and, uh, also just a reminder that, um, if you want a copy of the recording, after you need to fill in the form that I put in the chat panel, um, and I think a headset value here, something had to fail at some point. Um, it hasn't updated our critical control module, but I might configure that to do that later. Um, so, basically, what's happened here is, um, what you can see is, um, we've got a control history. It's updated control history, but it's done more than that. So, let's jump into another section of the system, and let's look at the, uh, and I'll just close some of these windows down for a second. Um, so, what it's done here is it's also gone into the critical control verification, and you can see it's actually created a critical control verification document as well. Um, and the other thing that's done is if I go to my actions module, I can actually see that there's an urgent critical control, it's become ineffective action that's been created by the system and automatically assigned, um, with a due date of today. So, that's now gone to that particular person. So, we've had a notification, we've had an action created, we've had a verification document created, we've had a critical control, a critical control become ineffective, and we've had the status of critical control infected, and we've also had the risk become not controlled, and that's all verified within the system and modified to the right people at the right time.

So, I'm going to go through a few other scenarios, one in quite so much detail, but what you can see there is that was all done through configuration. That wasn't done through a programmer sitting there saying, "Okay, if this question equals this, then that," it was actually done through someone with non-programming skills going in and configuring it to for all of those things to happen. So, let's, let's move on to scenario two.

Okay, so in this particular case, I'm just going to move to a different module. So, the module that I'm going to move into is going to be the, the observations module. So, this is fairly similar. Um, so, in, in this particular case, um, I'm basically going to answer a question in an observation. And again, this observation module is configurable. It may not suit a lot of people. Change observations modules to suit their own specific requirements. So, this is just an example of a, of an observation module. So, you'll see here, just dragging that across, um, you'll see that the safety observations sitting there. Um, you can see that I've got one that I'm in the process of doing, and it's open at the moment, and we've got a critical risk that's being looked at, basically here, and we've determined that the cables are unsafe. Um, when you're done, it's not obviously put more details in, but the time being, I'm just going to just mark it as unsafe. I'm going to hit the submit button, click yes. As I do that, what's actually happening? Let's just jump back to my critical control module again. All of a sudden, electrocution has become not controlled. Notifications have gone out. Actions have been created. Verifications have been done. Verification's been done all the time, by the way, when you do, when I see Mitchell Services doing inspection, there is often like 10 or more verification documents that have been pushed into the system, not just, not just, but also the passes.

Okay, so in that particular case, I've done a, uh, observation. It's now gone through and highlighted an issue which people will then go back and look at. Let's look at scenario three.

So, scenario three is a reactive situation. Now, you could also apply this to say, your standard hazard register, where people are logging hazards as well. So, this is a situation where someone's actually logged an incident. And in this particular case, when they've logged the incident, what's actually happened is the, um, the, there's a question in there. Let me just bring this across to the, to the screen as well. So, I'm just going to drag that over.

Okay, so I'm not going to go through all the detail. I'm not going to go through all the details of the incident at the moment, um, but they've basically filled out a variety of information. At the top, there's a description that says there's an uncontrolled release of water that's caused a near drowning. So, someone's logged this. It's come to me as the supervisor to then answer a series of questions and to convince an investigation. So, first of all, I go through and it says, um, a little bit further down, I've just waited. It's extreme, and extreme, it would have eventuated the fatality. Fortunately, it didn't. Um, it's probably a notifier event, but I'll just leave that for the moment. Did this incident involve a critical risk? So, added by configuration, we've added this question. I click yes, and it wants to know, and we can have help in there too, so you can identify what are your critical risks to give people more information. So, this was a drowning. And at this particular point, they've identified that it's a critical risk. Acceptance related to this particular critical risk, they've chosen, "We now need to investigate and fill out the rest of the investigation." So, this would lead you to an incident investigation or a, you know, whatever tools that you specifically want to configure the system to use. Um, and when we go back into again, the critical control management module, again, just closing that particular form first, you'll see that drowning has now become not controlled. So, hopefully, you wouldn't have that many families in a half-hour period, but what I wanted to do is show you that by just everyday.

Use of the system, excuse me. What you're getting is verification has been generated. You're getting whether things have been good or bad. You're getting, um, critical risks and critical controls becoming changing status, and everyone getting notified. Okay, so let's move on to the next slide. We'll have a quick look at reporting, and then, um, I won't spend too much time on this, but I'd like to just show you a couple of dashboard widgets that are worth looking at.

Um, so again, this is considered depending on what you want to do. So the first one is looking at critical control verifications by risk. You can set your time period up here. Um, you can set your hierarchy, so you might want to look at a particular site, those sorts of things. I'll leave those for the moment. You can also set filters on those things, so I can decide which critical risks I actually want to look at. So I can choose different critical, you know, different critical lists that I want to look at there. So I can see in this case, it's the verifications, there's the, um, it's the passes and the fails. And if I want to drill down into that data, I can very simply just click the appropriate item, um, and it will then open up the documents where we've actually had phases. And now we drill down further into those, actually drop the base information itself.

If I scroll down a little bit further, this is one where we're looking at, um, by date, um, the number of critical controls that have been done for, in this particular case, we've filtered it down to a specific, um, as a specific risk. So we're interested in this particular risk and we've set a KPI. We've said, in this particular case, we should be doing four verifications. Um, a lot higher, by the way, but this is just a demo. But we've said we should be doing on the KPI line four verifications a month, and then we can see how we've actually performed. So this is getting back to the individual risk and then also how it performed against those verifications. Then we've got the passes and fails. So we can see that we've done 99 passes, we've done this many, and we've had this many values. And then we can drill down that if we want to. Um, we can then go and buy things like, in this case, it's equipment. So, and again, depending on what you do, you may not be equipment that you're looking at. It might be other things. But in this particular case, again, I can filter this down so it's more readable, but I'm just showing all equipment at the moment. If I want to control, just use filters again, but I can then see by each equipment and again, I can filter it by site or by whatever. Um, I can then see where my passes and fails are.

Okay, so let's, let's move on to the, uh, to the next slide. Okay, so what are we doing next? Um, we're already looking at Bowtie functionalities, so for reporting. So we will be adding, um, basically that Bowtie analysis into the system, um, as a, as a future piece of functionality. We're also looking at real-time integration with other systems, but also with sensors. So if you've got things like carbon monoxide sensors or, you know, sensors on guarding that fail, so rather than actually having to do a check, when you get a sensor trigger, then the system's rules will kick in and notify the appropriate people. The controls and the risks will become the status of change, etcetera, just like I've shown you through today. Um, and the other thing is is integration with other systems. And that's when I say it's a future feature, it's, I'm saying it's the future because it's going to depend upon setting up integration. But most systems these days can actually integrate with other systems. So we have a very, very expansive, what we call API, a programming interface, that other systems can use. So whether it's your maintenance system, so you might have a maintenance task, if you have a maintenance, let's say you notice, you notice some extremely unusual activity in the maintenance activity, like a, a very worn tire or brakes or whatever it might be, it could then trigger a, all of those sorts of processes that we've seen today that would be done through other systems.

Okay, that leads me to the end of my part of the presentation, and I'll hand back to Sarah, who will then coordinate the question and answer session. Thank you, Adrian. Um, just one that came through the chat, um, from Hannah. She said, the presentation is wonderful, great implementation and consultation process with the workforce, um, and I particularly like the tailoring of the critical risk logos. And she's asked, was there a particular design company which developed these logos you can refer to? So I guess that's one for Josh. It's a mate of a mate. That's a, that's a simple way to do it. Um, there's lots of design companies that could do it, but we didn't use any specialists, to be honest. Okay. Um, Michael, I'd happily send them through, um, and they can use that as a template for their designs. But, um, a couple of them, I just sketched on an iPad myself, uh, and then they just, um, you know, I guess tarted them up a bit. Very talented. Okay. Michael asked, hi Josh, what would you do different if you did it again? Uh, probably leave a little, okay. Um, the standards because we chose to go into that little bit of extra detail, um, as per Christian's advice, it just took a little bit more time. I guess, Michael, uh, I would have involved maintenance a lot earlier. We were really heavily working with the operations type people, but involving maintenance actually allowed us to learn when things get damaged, when things degrade, how often they check. So that's probably a big one, is involving maintenance early. And we implemented it at within one business first, and then when we implemented into our secondary business, so Deep Core Drilling, they use different terms, uh, than we did in, in Mitchell Services. So Mitchell Services and Deep Core Drilling were doing the same thing, but they'd use different terms. But the inspection was only written a certain way. So, um, the, the Deep Core Drilling would say, oh no, that's a fail because we don't do it that way. So that's, um, that was a big lesson as well. Uh, and also that education piece when you're going through and determining what's a critical control and what's not, is that when people put in controls like training, like that's just crap. You need to know what part of training, like what is the bit, what's the important bit? And that, that applies to procedures as well, is really honing in on what is the most important bit, what's the step, what's the critical step that we're, that we're actually trying to assess. It can't just be this bit of paperwork was in place. Um, so, yeah, Michael, that's, that's probably what I would, what I would change, mate. Okay. Um, uh, Steph asks, can the notifications be sent to a number of contacts? Is there a maximum number? That's probably for you, Adrian. Uh, all right, okay. Um, yeah, the notifications can go out to basically anybody. Yeah. So, um, and as many people as you want. So, and completely configurable, um, as to when and where they go out. And so, yeah, so, um, as well, yeah, you can actually filter, you can actually have the notifications go to certain departments, divisions. It all depends on how you've got your hierarchy set up, but it can basically follow the hierarchy and go to only certain divisions, certain areas, etcetera. So works, works really well for us. The, the last thing we want is a blanket email to go out with a failed critical control, and if the GM doesn't know about it, but the CEO does, um, you know, that just, that's just ineffective in our business. So we can choose who gets the notification so that they can act upon that. Okay, thanks. Um, Andrew asked, are all the fields and titles of module elements configurable to suit the language or control criteria existing in an organization? Yeah, absolutely. Um, basically, the entire system is, any of the questions, any fields, the workflows, the technology. So we, we start off with basic templates, um, and what we typically do is we work through with organizations, integration workshops. So we work with you to say, okay, this is our page template, um, what do you want to change? So you might call something by a different name, then either we can change it, or you can. Okay. Um, Adrian, just need you to probably speak a bit louder because of that, um, sound issue. Um, Andrew also asked, how far off is the Bowtie add-on? I, I don't have a specific time frame yet, but we'll, uh, we'll get back to the developers and, um, and try to come back to you with that as soon as possible. Okay. Janine asked, is the CCM module available? The classic or need to upgrade? Which you need to upgrade. Yeah, at this stage, it's really only available in, in the custom system because of the level of configuration that you actually need to do. So the classic, um, the classic and, uh, version specifically, um, is, you can configure certain things yourself, but not to the same degree that you can do so in, um, in the custom and enterprise versions. Yeah, I look, I, and I, as, as the customer, because I'm the client, right? So Marsh Myers is the system, and I'm the client. Having that configuration is really important to me so that I understand, you know, what's working, how it works, it uses my terminology, I can put the questions that I want in. Um, so, yeah, having that, having the ability to configure the system is basically one of the reasons that we went down this path as well, instead of buying another, another bit of software, like, you know, my, the Myers Viking platform's allowed to do it ourselves. Okay. Um, Michael has also said, well, thank you, Josh. He really appreciates your insight. Um, through the chat panel, I've also got a question from Mel. Have you seen, I think this is for Josh, have you seen an improvement in your safety performance, uh, overall? Uh, first, the first thing it did is open up hours and time, in opened up our eyes in terms of, uh, the lack of standardization of some of our controls. So once we got that underway, um, that was that was really good. And then we looked at the absence of presence of controls, and, you know, that was that was making an amazing impact as well. We're actually improving the workplace because that's what it's about. It's actually about improving the workplace. So we, um, we take a view within Mitchell's that, and it, and it's the new way of thinking, is that safety isn't just the absence of accidents, it's actually the presence of capacity and controls. So this gives us the knowledge that we've got controls in place. But look, in, in short, since the implementation of the critical risk management and improving our workplaces, if God, if we were, if we were measured on recordable injuries, um, which, which we don't within our own business, but if we were, I think we've had one minor recordable injury in 16,000 shifts. So I, I think it's, it's made a big difference. Sarah. Okay, thanks. Um, uh, anonymous asked, Josh, are there any government organizations that are currently utilizing this service? Look, I can speak with Adrian, but I think we're, we sort of worked with Mirage quite closely on the implementation of the critical control module within the software. Are there other government organizations utilizing this service? I could say no, but I wouldn't say these government organizations not doing critical control management. There's, uh, there's government organizations using the Viking platform. Um, the critical control management module is relatively new, um, so there won't be any at this stage, there won't be any government organizations actually that have configured the critical control management module yet. Um, so there are organizations using the platform that you've seen today, but just not configured it to the level that, um, that Mitchell Services has. Okay. Well, we haven't got any pending questions, um, just yet, but I do want to share, um, this next webinar through the chat panel. It's, um, on the 13th of May. Mark Olsen is only going to do a presentation on the practical guide to critical risk management, and he is going. It also, just a reminder that these webinars attract CPD points. So, um, he's going to cover, um, how to establish a framework, identifying the risk, facilitating workshops, some critical control selection, design, and how to monitor those risks. So that's, I'll put a link in the chat for that. And just wait if there's any more questions. Um, Josh, did you want to talk? No, not at all. Like, it's been, uh, it's been an amazing experience in terms of implementing critical control, critical risk management, being able to not do it in just an Excel spreadsheet, but also not adding clutter. That's the biggest thing is that we haven't actually had added administrative burden, um, and just the change that we've seen in our organization now that we actually have visibility on if controls are in place or not, and the management's response to controls as well. When we do find a fail, we actually embrace it and take that as a learning opportunity. It's something that we'll just get better as a business. But again, we didn't have that transparency before we implemented the, the CC module. Right. Um, Adrian, do you have anything further to say? No, just, uh, thank you everyone for your attention today. I appreciate the time and, um, uh, if you need further information on this module, um, please contact us. We do need to review your specific requirements to be able to work out, obviously, pricing and those sorts of things. But, you know, we want to talk to you if you're interested, and we can work through what the process is, um, uh, from there. Uh, yes, thanks. I'll just reiterate, I've shared that form, that last link in the chat. If you want, just to get back to you regarding pricing or an online demo for your organization, please fill in that form. Um, we're not automatically sharing this recording to everyone who registers, so you will need to fill in that form. Also, I shared the link to Mark Olsen's webinar in the chat, and a link to all of our future and past webinars, and also a link to a Mitchell Services video that was done some time ago with them. So, um, if you have any questions for either of the panelists, just feel free to contact us, and we'll forward them on. Um, so thank you, Josh. That was great. Thanks for joining us. I do believe the feedback through the chat has been fantastic. So I think people appreciated this information. And Adrian, thanks also to you. Maurice, thank you. Sarah, thank you, everyone. Have a great day. Bye.