Transcription
Perfect. Well, um, hi. I'm Maddie, as you can tell by my name badge. Um, but I'm gonna be answering, oh, sorry, not answering, I'm gonna be asking the questions today. So, we're just gonna get started, um, straight off the bat. Um, so Adrian, why did Mayosh develop the CCM, or Critical Control Management module, um, and what's the methodology behind it?
There's quite a few different reasons. One is we were getting customer feedback as to their people were trying to, and customers were trying to manage critical controls and critical risks, and there wasn't really anything out there that allowed them to do it in a way that made things easy. It's sort of, there was a, there's some, there were some things out there, but there was a sort of a little bit hit and miss, um, that did parts of the approaches that you needed to actually implement, um, critical control management.
The why we did it, basically, what we were wanting to do is provide a meaningful way of, of minimizing fatalities in all industries. Um, the methodologies that we looked at, um, they, um, there are methodologies out there. They've been mainly targeted the mining industry, but they are actually applicable to all industries, um, particularly ones that have critical risks, ones that can have fatalities or, you know, um, some very serious injuries. But it can also be applied to other situations as well. So, we, we saw there was a major gap in what was available, um, and how it could actually, um, assist organizations to the task. And what we did find is people often weren't implementing critical control management because it was just too hard. It was just too difficult to do. So, we wanted to just make it easy to be able to do that.
Awesome. So, do you say you want to make it easier to implement? So, what types of companies should be implementing critical control management?
Yeah, I, while a lot of the, um, CCM is, um, targeted or been stemmed out of the mining industry, where there's been, you know, probably the vast number of fatalities, um, and whether they, they are very, very safety-focused. So, there's a bit, there's been a lot of work in those areas. But really, anywhere, um, that has anything that can cause injury, particularly serious injury, and particularly fatalities. So, it's something that people just have to take very, very seriously and have processes around avoiding those sorts of things. So, we, I've, I've looked at the, various different industries and seen that you could actually apply it to every industry that I can think of, um, that that has those same situations.
Right. So, what stops companies from implementing CCM then?
It's, what I see is it's, um, the significant overhead in trying to manage it. You've got to do lots and lots of different things. It's not complex, it's actually relatively simple. You identify your critical risks, you've got your critical controls, and you verify them. But to try to do that in a systematic way that's repeatable and understandable is actually quite, it can be quite difficult, um, particularly without software to be able to automate those processes and to be able to report on that information. If you don't do it properly, or if you try to do it manually, you'll then get resistance by staff because they don't want the extra work, they don't want the extra load of things in place on top of them. And, and historically, that's what's actually happened when people have tried to implement CCM, they've just basically loaded people with more work.
The other aspect is, there's, because it's quite piecemeal at the moment, you know, without the software, it's, people don't necessarily understand the process and can get lost in the process, and they don't see the importance of it. The other thing that I think stops it being implemented effectively is not engaging key staff, getting people at the ground level, making sure that you're talking to the people that are doing the dangerous tasks. What are the things that worry them about coming home safely at night? What are the things that, you know, while you might have all your processes and policies and procedures, they don't always capture everything. And getting the engagement by the people on the ground doing the job, doing the jobs, you also get engagement in it, you know, you get people fully engaged in the process, and they can see that they've actually contributed towards it. Also, getting external consultants can be useful as well, but can help. But there's a lot of information on the web, and, um, there's some very good sites that can tell you the processes for implementing, um, CCM.
Perfect. So, what does the Critical Control Management module do?
Okay, it's probably easier for me to basically show you, um, but what it, what it basically does is it automates the, um, it all might, it automates the process, um, and the methodologies that you see in CCM. So, um, some, some of the audience, they might have seen this diagram in the ICMM document, which is basically an implementation guide to critical control management. And this is basically a process that works really well. So, essentially, you identify the material unwanted events, um, you do that through consultation, you do that through reviewing what fatalities have been in your industry, what serious injuries they've been in your industry, and so forth. You identify the controls, um, and then you basically select the critical control. So, this is again, you go through, you identify the controls, you select the critical controls, and also the non-critical ones as well. You then define the performance standards and reporting standards. So, what are the things do you have to do to make sure this control is effective? When implementing the control, another important component is accountability. So, making sure that people are accountable, not just for the unwanted event and being aware of what that is, but also for each of the controls as well. And you've got to implement it. So, you've got to make sure that it's somehow measured, and then you've got to verify that it's actually working. And one of the things I'd like to talk about with this diagram is these are the things here that actually often fall down. People implement or try to implement these things, but the verification processes is can be difficult, and it can also be difficult to monitor without, you know, without the software.
So, what I'm going to do today is I'm going to go through our software. I'm going to occasionally jump back to this diagram and sort of refer back to what the process I'm doing and what, you know, where it relates to this particular process of critical control management. So, let's get rid of that for a moment, and we'll come back to it, um, as we need to. It doesn't, let's see if it wants to get rid of itself. Let's have a look first of all at the module itself that we've implemented. Um, I'm going to, I'm not going to spend too much time looking at this screen here, but this is when we look here, this is looking at the material unwanted events, or MUEs, as they're sometimes referred to as. Um, and this is fairly typical. You'll see these sorts of things in lots of places when you're looking at risk management and risk registers and so forth. You'll see risk ratings and residual risk ratings and so forth. So, what we do with this is rather than creating the documents in here and filling out forms, although we do come into here and we do complete forms, we actually use the bow tie diagram to basically automate the creation of the documents in here. So, when every time I create, uh, add something to the bow tie, it's in fact adding information either into these documents or creating controls in the control module.
Okay, so if I look at a new diagram, I might, and I'm just going to add a few boxes here. So, I'm just going to call this unwanted event. Oops. And as you can see, I'm going to try to avoid typing too much because it'll just take up time. But essentially, what you can do is you can basically add the items in here. And as you add those items, it's actually adding it into the, um, it's, it's basically adding it into the, um, the actual system itself. So, into that, into that list of documents. So, that'll basically be created in there. Now, you then go through, you add your causes, you add your preventative controls, and you just simply, as you add these things here, so you can sort of see, I can add a cause, um, basically, as, as I add the cause, it then basically goes through and adds the cause into, into the system. And, um, then, um, so I'll just call cause one, and I can add more causes if I want to. Then I can go under here and I can add the preventative controls. So, this is, for those who haven't seen much of bow ties, this is basically a cause and effect diagram. So, you've got your causes, you've got the things that prevent the unwanted event from occurring. So, that's a control now. But just simply by doing that, it's actually adding it into the system. So, it's added that control into the system, and I can modify it from here as well. And then I then go through, and there's the hazard, there's the mitigating control. So, I'd go through and add those, and the consequences as well. And basically, I'd build up this bow tie diagram. So, the mitigating controls are controls after the event occurred to try to minimize the damage. So, I like to point out the seat belts that you wear after, after the car crash stops you from getting injured.
Now, rather than looking at one that I'm building, what I'm going to do is look at one that's been built already. So, this is actually linking into a, unwanted event within the system. And what you can see is this information here. Now, when I drill down into these items, you can see here, I can either modify it by clicking inside there, or each of these actually has a link. So, when I click on that link, what it does is it goes away and opens up that particular control. And once that control opens up, I can then go through and see all the various information that I need to see inside that, inside that control. So, there'll be, um, of right information. I'll just wait for that to load. I'll just expand it out in just a second.
So, if I just jump back to the diagram for the moment, so let's just, excuse me for a second as I get the screen correct. So, we've done some of these things. We've identified beyond the, the material unwanted event, we've identified some controls. Um, we're now going in and we're actually editing those controls. So, what I've just done is I've clicked on the control, it's opened up the control, and I'm now going to modify some of the details inside there. So, if I, again, just get rid of that, that diagram for a moment, what I've got here is the actual control itself. So, this control document, which was the isolate the energized lockout, etcetera. You can see inside here, there's this control type. So, I can define whether it's critical or not. If it's a non-critical control, this document becomes a lot simpler because you don't need to put in all the various other, all the various information. Now, as I scroll down, you'll see there's a whole series of things in here. One of the things that's important is accountability, which we looked at on the diagram. So, this person is accountable for ensuring that this control is effective or stays effective. And you can see straight away that this control is currently effective. So, we then have a whole other information. I'll just go through it fairly quickly. But when you look at the, the ICMM implementation guide, or if you go and look at the, the implementation guide, it gives you a lot of information on what they call performance standards. So, I've touched on this a little bit earlier on. Um, the performance standards are basically making sure that the functionality is met, it's doing what it's meant to do, that it's available when it's meant to be available, um, that it's reliable, um, and how reliability is measured and so on and so forth. It can survive a damaging event, um, what is it dependent on, maybe electricity or water or whatever else that might be there. So, the control is not just a, so while you're looking at that control in the diagram here, um, there's a lot of information that underlies and defines that particular impact. Any of the controls within this diagram.
So, some of the other things in this diagram as well. So, a lot of people build bow ties, and they just typically fall away once they've built them. So, they're sort of like a historically, they've been a document that you build, you then put away in a filing cabinet. So, what we're doing here is we're making it is actually a live document, and it's working with the system to be updated based on things that are happening out in the workforce. So, this gets back to some other aspects of the, of the, um, of the diagram that I was looking at before. So, one of the things I can see straight away in here is I can see critical controls. So, it highlights the controls that are critical. So, I can see those on. So, that one obviously there's not critical. I can also say which ones have control issues because based on things you do within the Mayosh system, will then automatically change the statuses of these documents. So, you can see here that one, it wasn't a critical control, but it does have some control issues at the moment.
Now, what I'm, what I'm going to do now is I'm going to bring in, the look at the verification side of things. So, again, getting back to this diagram again, we've shown how we can identify controls, identify which ones are critical, define performance standards, um, set accountability, both within the control and within standard. We need to now implement. I'm not going to go through how we implement it, but basically, what we've done is we've configured the system with automations. So, it allows us to verify the, the controls, whether they pass or fail, and then allow us to report on that information. So, what I'm going to do now is I'm going to jump into the mobile app. In fact, I'll just also jump back into the system as well.
Let's do that. And I'm going to jump to this screen here for a moment. So, I've got my mobile app sitting here, and I've actually started an inspection. So, it's an inspection that's been configured. You can configure the questions and the data that you want to collect. You can put pictures in there. You can have extra questions pop up. So, if you answer in a certain way, it might ask another question, for example. So, it's, this is a fairly lengthy inspection, but this inspection is recording both critical and non-basically doing inspection, which some are relating to critical controls, some aren't. So, what we're doing here is we're making sure that the ins, we're not adding any extra workload onto people. They're already doing inspections. We're just making sure that we have the critical controls identified in the inspections that we do.
Now, I'm in this particular case, you can see this question here, we've got an issue with it. So, let's say there's a tag missing. So, I'm going to say no there, and I'm going to choose more details. I'm just going to go into the observation section and just type in tag missing. Okay. So, at this particular point, um, I'm going to basically finish this particular inspection. So, I'm not going to worry about filling out the rest of it, although you can make things mandatory, so you can't do what I'm doing right now. But we just want to get this going. So, I'm going to click tick the completed button. So, in this particular case, we've got a critical control failure, a tag's missing. We could have serious injury as a result of it. So, I'll just mark that as completed. So, if I'm offline, which the app allows you to do, it'll update when you come back online and start the app. I'm just going to move that out of the way for a moment. So, I've completed inspection out in the field.
Now, what's happened is a whole series of things in the background to make sure that the, um, that things are going to happen. So, we've got us, we've got something serious that's happened. Um, the event hasn't happened, but we've got to control. Obviously, the event could happen now because we're not controlling it properly. So, you'll see straight away here, if I, um, refresh this stage here, the status of this document, once it loads, will show that we actually have a control issue for this particular unwanted event. Now, if I jump back to the actual, to the bow tie diagram and do a refresh, what that's going to do is it's also going to highlight that on the bow tie diagram that we actually also have a control issue with this area here. Now, so what I could be doing is I could be drilling down into there and finding out what is the issue. So, what is the, what is the problem, what's actually occurred? So, that'll open up the control, and I'm going to be able to see more information about that control inside there. Now, at the same time, what's actually happened is the risk owner has been emailed. So, there's been an email sent out to the risk owner to basically say, in whatever format you want. I've got a fairly simple format here, but it could be a, you know, a more, a more sophisticated format. And I'll bring that up in just a moment, once the email arrives.
So, just opening up that email, hopefully that'll open up on the screen in a second. Okay, so basically, an email has just come into my mailbox. So, I can click on that link, and it will actually open up the information that I need. Okay, so that's happened immediately. So, that could be a push notification, or it could just be a straight email, as it was in this particular case. Okay.
So, if I just collapse all this for a moment, I can look at the control history. And from here, when I expand that section out, what it's showing is that there was a tag not attached to a piece of equipment, and it's actually recorded a non-performance. So, that happened immediately. Now, if I clicked on that link there, what that would do is it would open up the inspection that I just did, and I'd be able to get more context behind what's actually going on. So, that gives me the, the, um, a lot of information about that particular control. Now, you'll, you'll also notice if, um, if I open up the, um, control, uh, the material unwanted event in here, and I go and actually have a look at this in a different setting, outside the bow tie, I can now see also visually green and red, what's failed, um, what's except, or what's not. So, I can now see that that has also failed in there as well. And the owner of the critical risk would have also been emailed too. But beyond that, there's other things that have happened, and it's fully configurable. So, it's really up to you what you want to happen when the critical control has failed. But it's one of those things where you should be jumping up and down, and you should be mobilizing the appropriate people.
So, another thing that's happened within the system is, if I jump over to my actions, and I'll just close down that assessment in a second, but, so once that loads, the actions, what you'll see is there's actually an open action there that's been assigned to a particular person that says, urgently investigate the missing tag. And then that will have escalations on it as well, if it's not followed up within a certain period of time.
So, how do you report your control verifications to a more, a higher level?
Yeah, good point. Um, basically, what we're doing here is there's a lot more going on behind the scenes than that's not, that's that's immediately apparent. One of the things that customers fed back to us is that they want to be able to demonstrate and look at the critical control verifications. So, when they've actually verified whether it's passed or failed, it doesn't really matter. So, what they want to be able to do is they want to be able to see, and I'll just jump into some data here as, as an example. So, they want to be able to look at information about what was the critical control, did it pass, did it fail? Can I, can I, can I go into here and look at individual fails or passes? And then drill down into the files or passes. They also, the system also enables you to collect whatever information you want to collect. So, in this case, on the screen, it's showing you things like the critical control name and the pass or fail, um, who verified it. But it also can store things like the equipment number, the site that it applied to, any other data. And because it's collecting that data in the background, I'll just open up one of the ones that, um, that failed. You can see here, it's got the verification date, who verified it, the equipment number, the fact that it failed, and so on and so forth. So, we could be collecting more information. Now, that was a direct result of just doing the inspection. The person doing the inspection didn't, you know, didn't even know about it, really. But essentially, it's creating that verification. Now, these verifications, um, somehow customers are creating really, really large numbers of verifications, and those verifications are really, really useful. And they're then used on the dashboard to be able to report the information that people want to be able to see.
So, in this particular case, I'll just jump to the appropriate place. That's it. Then cool. So, on our dashboard, you can configure the widgets, these graphs, if you want to use a nicer term. So, what this is doing is it's recording the verifications, both passes and fails. So, it's telling us if we've done enough verifications, and you can set KPIs on them if you really want to. But you can analyze these at the end of the month and see whether you're doing as many as you should be. You can also look at the red and see what, what's failing and what's passing. You can see here, I can draw down, say, get rid of the passes, and I want to find out which ones have actually failed. So, if I click back into, say, this one here. So, I've clicked on that link there. What that's going to do is it's going to open up the list of the verifications that failed. And then I can click into those and see the more detail about the fail. And then I even go back to the inspection, and see, um, or what it's not necessarily an inspection, by the way, it could be something else, might be an observation, or any other part of the system for that matter, um, where you're recording information. But it's then allowing me to drill down and say, okay, what was that failure in more detail? Why did it happen?
Now, we've got customers where the CEO literally looks at this, these graphs on a monthly basis, and they're starting to ask more questions about, have we done enough verifications? Why am I not seeing any values? Surely something's failing. Um, and, you know, they'll start looking at the data, they'll start, they start looking at when they get a failure, they say, okay, how does this relate to the work that we do? How can we improve the work we do? And, and so forth. So, it's giving them insights as to what's happening within their business, and basically what they're needing to do to keep their workers, essentially safe within their organizations.
You've mentioned inspections quite a bit. Are there any other modules that you can use with this?
Yeah, absolutely. So, if I, if I jump to say, incident reporting. So, this is an incident that's occurred within the organization. So, so far, we've been looking at lead, you know, processes like, um, you know, like like inspections and observations and those sorts of things. In this particular case, an incident occurred. It's a, what was it? It was an uncontrolled release of water. And we've configured the system in this particular, in this particular case to say, well, did this involve a critical risk? You can say if it didn't, there's no. But if you say yes, you can then select the critical risk. So, in this case, it almost causes drowning. So, in this particular case, as we go through the investigation process, this would then be updating the, the critical or the unwanted event, and highlighting that we've actually had an incident that that related to this particular critical risk, which could then again go towards your reporting.
Um, some of the other things that I've seen with integrations is, let's say you've got a failure. It doesn't have to be a critical risk failure, but it could be anything. It could go off and create a non-conformance in the non-conformance module. So, all of these modules are optional, and really will depend upon what modules you actually have within the system. So, you could link them in all sorts of different ways. You could also be linking them, linking verifications and other things back to pieces of equipment as well. So, you could be looking at pieces of equipment and seeing where we've had failures. So, it's not just limited, it's not limited to say inspections and, and the critical risk and the control modules. It can basically tie in in an integrated approach, which is configurable across all modules.
Brilliant. Well, do you have any feedback from customers who, uh, well, with regards to safety performance after having implemented the Critical Control Management module?
Yeah, absolutely. Let's have a look at, this is some feedback was actually given to us, I think was last week. And I'll just explain the statistics behind this one. So, this line here is the, is the TRIFR, so the lag indicators, so basically total recordable injuries. Um, and they've just averaged it over the year. They haven't done the rolling totals, but it's similar. So, you can sort of see around about here, they started, they started. And this blue line here, by the way, is your number of verifications that they're doing. So, as they implemented the, the CCM, what you can see is the TRIFR is actually coming down over time. Okay. So, they've been honing it, getting it better, automating it more, getting more learnings, and over time, it's just gradually, in fact, not necessarily gradually, it's coming down quite quickly. So, they're seeing reductions in the, um, in their in their TRIFR rates. They're also looking at in relationship to high potential events. Now, this at first might look a little bit strange, but what they were doing back here is they weren't focused on high potential events as much. And now they're a little bit more liberal as to what they call, call a high potential event. So, they're now focused on, if we have an event, it doesn't relate to critical risk, is it, could it be, um, you know, could it cause, could it have caused serious injury, et cetera, et cetera. So, they're now being, they're now calling out any event and they're going and they're really focusing on whether it is a high, high potential event. So, the reporting back here is probably not really accurate in this case. They're going a little bit, maybe even too much the other way in calling out those events. So, but what this is clearly showing is that they are getting a significant reduction in performance, and they haven't had a major injury since they've actually implemented, um, this particular customer implemented the system. So, what it's not showing you is the severe injuries. There haven't been any severe injuries, and there were, um, previously, um, prior to implementing the CCM. So, that's that's also quite telling.
Yeah, amazing. Um, and my last question to you is, do you have any feedback from customers with regards to other areas of improvement at all?
Yeah, so what they're finding is, um, is they're the areas of improvement. They're seeing staff being more engaged. Um, they're, they're stuck because they, because they're able to give feedback, um, within the system and be involved in it. They're also being able to react quickly to changing events. So, one of our customers had, um, a situation where, um, there was a control that needed to be put in place very quickly as a result of an event that occurred at a place with one of their customers. So, I think it was something with unstable ground, and they actually had to ensure that a control was put in place because it did actually relate to a critical risk. The ability for them to be able to put that information, put that control in place, and to be able to verify that control within an hour, that actually updated the system, ensured that the control was there, made sure that there was an owner, and made sure that was being verified, and then they could report back to their customer to basically say, this is what we've done about it, and this is our metrics moving forward.
The other things for the, for the companies that do try to implement CCM without software, or with bits and pieces that aren't totally integrated and automated like, like the Viking platform is, um, what they found is to try to do, you know, what this does was was the equivalent for, you know, for this particular customer, the feedback was, was basically two full-time positions to be able to do this effectively without software. So, the software basically allowed them to be able to do this effectively without, um, having, you know, multiple people having to to, um, to to do all these things manually. So, I've seen people try to do it manually where they get their inspections and they try to export all the questions out that have been answered, and then, you know, it's possible, but it's just not a lot of fun, and it takes a lot of work. And again, typically, it falls down after a while because as people change, they don't necessarily do things the same way or consistently. So, there's time savings, there's obviously huge safety savings, which we've seen demonstrated, or improvements and culture improvements within workforce, especially when they go through that implementation process, um, in the, in the appropriate way. The other thing is, we saw that it doesn't have to be bigger than Ben Hur. It doesn't have to be a massive project. So, it made it easier to implement CCM because it's a nicely defined process that the software drives, basically. Sorry, my mute button wasn't working.
Awesome. Thank you so much for that, Adrian. Um, anyone that is attending at the moment, I'd like to open the floor to you. If you have any questions that you'd like to ask us, and we do have a few here already that have come through. Um, so the first one, Adrian, is, uh, what about phone notifications when there is a failure?
Phone notifications? Yeah, so basically, with the app, you've got push notifications. Um, so, basically, that's essentially immediate. Um, so the, um, the push notifications can go to whoever's got the app on their phone, and they'll see that information. So, rather than waiting for an email to come through, with CCM, we'd normally encourage the use of the mobile app and to be able to receive that as a push notification.
Okay. And what level of system maturity would you expect to see in a business implementing CCM?
Um, I guess you'd need, you'd need to have implemented a system that allows you to do inspections, it allows you to do, and you've got these things in place. I guess it's, it's a process that will drive a lot of those other systems as well. So, you don't, I don't think you need to be necessarily really mature to do it. And I think a lot of people actually put it off because I think our systems are relatively mature. I think it actually drives the rest of the processes within the business. So, when you have the CCM module, you start to put in other things in place to support the CCM module, like your inspection regime and so forth. You, you do need to obviously have a culture of people wanting to improve and to, to, to minimize incidents and improve safety. Um, but yeah, I don't, I don't think you need to be terribly mature in the approach. I think you can also, um, if you are not sure, there's some very, very good guidelines out there. So, the RCM guidelines for implementing are excellent. Um, the other thing is, I don't think you need to go completely overboard as well. So, for some, because the system's configurable, you don't have to do everything that I just showed you. You can, you can implement parts of it. And we've got organizations that are implementing just the definition of the critical control management, um, so the bow tie, basically, they're building their unwanted events, they're building their controls, and they're basically saying, when we get a little bit more mature, we're going to now implement all the rest of the automation that do things.
Awesome. And can you give an example for a failed critical control? What further action is taken or made through Mayosh if a critical control is failed?
Okay, so basically, um, the, the action will depend upon the control itself. But an action gets created in the system. It gets assigned to the control owner. It gets escalated if something's not done. You'd typically go back and you'd review the sorts of actions. You'd do is you review the performance standards. You sort of say, okay, did this control fail due to a performance standard not being accurately defined? Um, alternatively, um, so you'd need to, you know, look at those sorts of things. Um, the, the control owner would need to clearly identify what they're doing about the fact that we've had a critical control failure, um, in the, um, within the control document. So, the other thing is, you, the other thing is, you also have, because these documents are all have their own workflows, you can define the workflows yourself. So, it can really be up to the individual business as to what they do. But the other thing that we always, always encourage is that there's review processes. You don't just wait for failures, but you also have, so for example, a control would have a periodic review, and there'd be a status change where it might, that control might be under review, um, with all of those things being reviewed, and with all the data that's been collected over the last period of time being monitored.
Okay. Uh, and how many critical controls do you generally see in an organization?
That's, um, that'll vary from organization to organization. Um, you'll typically see, um, with critical controls with high risk industry, somewhere between 20 and 30 critical risk events, or material unwanted events. So, they're the main component. Now, depending upon, um, depending upon the, the material unwanted event, will depend upon what sorts of controls you're putting in place. So, that will vary. It's a bit, it's, um, um, it's a bit hard to answer that question, apologies for that. But, um, 20 to 30, uh, critical risks. So, you're not, you're not talking about hundreds and hundreds of critical risks. So, it's not impossible to manage. And it could be substantially less than that if you, if your organization's not doing really high risk of high-risk work. The controls will vary considerably.
Okay. And is it possible to see the critical controls verified status sorted by control? I believe your example was sorted by equipment inspected.
Yeah, absolutely. You can slice and dice this to however you want. Um, so that's all configurable. So, you can just, you can define, and you can do that within, within the record list as well. So, you can, you can sort by just simply clicking on a heading. Um, you can define your dashboard, so they, so they can be sorted in any way, shape or form. So, um, today, we've just shown you some examples of the way we've done it in a demonstration environment, but basically, that'd be some of the things that you set up with configuration. And you can also save the sortings as well. So, you, in the record list, you can say, I want to save this record list, I want to show it in this way, I want to show these columns, I want to show between these dates, all those sorts of things. I want to show the ones that, um, have control issues sorted. I want to show the ones, I want to show the ones that, um, are pending review or about to be need to be reviewed in the next three months, those sorts of things. And you can save all that information and then jump between those saved, um, basically views of documents.
Awesome. So, that was the last, um, question that we've received from the chat. I'm just going to hand it back to Sarah to dismiss the webinar.
Great. Thanks, Maddie. Myself, I'm having unmute problems. Um, okay, so I'm just putting a link there in the chat. Um, it's a landing page for Critical Control. The first video on that landing page is a very short case study, but, um, excellent case study with Mitchell Services, and, and they talk about how they're implementing and going through the process of critical control management. There's also a really short video explaining this whole process, you know, just a couple of minutes, and a form. So, if anyone wants to arrange an online demo with the consultants or get some pricing, you can do that with that form. I'll also put those short videos in the landing page later today. That comes out via email. Um, there's also one more webinar that I just want to put in here. It's in a couple of weeks. Um, it's on, operational leadership and critical risk management. It's been presented by Centers. If you do come to our webinars, you'll know they've presented quite a few excellent webinars, and this is also relating to critical risk management. So, I'll drop that in the chat too. Um, if there's any other questions, I think there could be, um, I'll let them go on. Is there one, Maddie? And since it looks great, thanks for showing how it works. Really appreciate how the system makes risk management live by linking it with inspections and triggering reviews. Great. Thank you. Um, and, um, I'll just wait a couple of minutes, but yes, um, there's plenty of information will come out by the email later today. Remember to check your spam because it does slip in there. And that webinar in two weeks is in the chat there. So, um, come along to that. And we've got a lot of webinars on that academy relating to critical risk, if you look at the category there too. So, there's a lot of information on how organizations are doing that. Um, I think that's it, everyone. Thank you, um, Maddie and Adrian and Mel. Mel can assist with, um, consultations and demos as well, if you, if you want to arrange one. And we're also going to do this webinar again in about three or four weeks, so stay tuned for that as well. Um, if you want to invite other people along. So, thank you, everyone. Um, see you in a couple of weeks. Thanks, Maddie. Thanks, Adrian. Bye.