Transcription
So, uh, once again, welcome. Uh, a very quick overview of what we are planning to do. Uh, so, uh, we'll talk a little bit about why, uh, some organizations choose to start Critical Control Management, or CCM. Uh, we'll, uh, go a little bit over the process and some of the tips and challenges that we see along the way. I mean, we've been involved with some of the implementations of this, this process, and there's always things to learn, always things to improve, and we'd like to share some of these ideas. Um, but first and foremost, it's a, a basic introduction into the concept. So, uh, yeah, we can't go into unlimited depths here, but, uh, I hope you understand. If you have any questions, please, uh, do ask.
Um, very quick an introduction from my side. Um, my name is Jer Smith. I am one of the Consultants of Resilium. Um, we as Resilium focus on, uh, barrier-based risk management, or control-based risk management, where we, uh, help organizations identify their, uh, controls, their safety, uh, safeguards, basically their safety mechanisms, um, and, uh, also help measure those, those safeguards or those controls the best way we can. So perhaps we can use existing information in the, in the organization to, to, to say something about the quality of these controls, uh, or we can, uh, try to find new ways of measuring these kinds of things. Um, and by doing that, we help organizations understand how they control their risks and, uh, and present how well they are doing with their risk scope.
So, uh, Critical Control Management is all about, well, identifying the most critical controls and then trying to manage those controls and, and trying to, uh, uh, periodically, for example, evaluate the performance of those controls. So we can, uh, well, pick up on flawed controls and do something about it before, uh, bad stuff happens. Um, so, uh, yeah, you can imagine that Critical Control Management fits very well into that, uh, uh, into our scope.
My personal background, uh, is I'm a cognitive psychologist. So, uh, I look at how humans make choices or decisions, for example, or how human behavior is influenced by, for example, the environment in which people operate. Which always, uh, like prompts the questions, why do you end up in risk management? But I guess it's quite logical, as most of the, uh, uh, risk management activities that that people do or happens within an organization, of course, uh, a lot has to do with, uh, with human behavior, like people doing certain things or maybe refraining from doing certain things. And, uh, from that regard, of course, there's a big psychological aspect, uh, involved there as well. Uh, and also when managing your critical controls, of course, there's a lot of behavior involved. So from that point of view, psychologists want to have something to say about it. So that's where I come in, basically. Um, but, uh, yeah, I've been involved in, uh, uh, uh, barrier-based risk management since, uh, 2010, I think, around that time, so quite a while now. Um, but as a psychologist, of course, I do not claim to have any, uh, knowledge about very specific processes, like, for example, I'm not an expert in the oil and gas industry, or in steel making, or in aviation. Uh, we serve as all those industries, but more from the perspective of the method and try to help people in that, that regard.
Um, yeah, our vision always is that, uh, like the, the true knowledge about how to control the risks would reside, of course, in the company that is actually taking those risks. And our role often is only to make sure that the information, uh, is brought out into the, onto the table and, uh, is managed in a correct way. Um, but, uh, yeah, this is the journey that I wanted to take you on. So first, a bit on why do we want to do CCM in the first place, uh, and then basically the question of what is CCM by looking at its process, and then some of the tips and challenges. I hope you, uh, enjoy it.
Um, as we are starting, I would also like to quick launch a little poll. I have never done this before, so I hope it goes, uh, fine. Um, quick question, uh, for you all, uh, like, uh, why are you interested in CCM? Is it perhaps because you're already using it or implementing it, or, um, uh, is it because you are, uh, um, uh, just interested in to know what it is, or maybe you're, uh, contemplating implementing it? Um, just for our understanding, it might be, uh, good to know.
All right, very good. So a couple of people are very new to the topic. Some of them are already using it to some extent. So, uh, I hope you can get some new information from this as well. Um, but, uh, um, yeah, feel free to enjoy the ride as we go along. And since it's a basic course, we'll, I'm sure that even if you're completely new to the topic, you, you came to the right place as well. Um, so without further ado, let's dig in.
Um, yeah, I think as, as Critical Control Management really is a sort of risk management process, and, uh, uh, it basically comes from a very simple paradigm, uh, which tries to answer these three questions. So, do we understand the risks that are involved with our processes that we do on a daily basis? So if we are, let's say, an oil and gas company, do we, uh, uh, uh, do we store, uh, hydrocarbons, or do we get it out of the ground? What are the risks associated with that? Then we want to understand what the most critical controls are on those risks. So which, which, what, which are the safeguards that we have to make sure that those risks don't take on, uh, unwanted forms? And then lastly, do we understand, uh, how those controls are actually performing? So do we know, do we have a grasp of how well those controls, uh, work? If we know that our controls are failing, then, well, we, it might tell us something that our risks might not be as well, well under control as we would like. So those are the three main questions. I think, I think if you have a good answer to each of those three questions, you are well on your way, uh, on, uh, uh, from a risk management perspective, but also from a Critical Control Management perspective. Uh, of course, answering those questions is, uh, uh, easier said than done. There's usually a bit more involved to this, to, to, to genuinely be able to answer these questions correctly. Um, and that's what the, uh, CCM process, for example, comes in and can for you.
Um, so why do this? Like, why, why do Critical Control Management over other, uh, paradigms? I think, uh, um, there's usually a couple of answers to this question. I've selected just four of them, uh, to look at. Um, so one reason why some organizations want to adopt CCM is, uh, that they, uh, have difficulty with answering the question, so, are we really in control over our risks? So when you, you think of it, when, when people, or organizations, evaluate how they are doing from a safety perspective, or from a risk management perspective, uh, one typical thing that people look at would, for example, be incident statistics. And then, for example, like the number of LTIs, and whatever those are, are increasing or decreasing, which is, of course, a good thing to do, I would say. Um, but it does, uh, only tell you something about how the system had been performing. And we've, we've seen organizations, for example, come to us and say, well, we, uh, uh, we see that there is a decline in our LTI. So, for example, we, in the blue line, we see a decrease in LTI, so the, the number of incidents overall, the smaller types of incidents are decreasing, but the number, uh, of like serious incidents, or maybe even fatalities, or serious injuries, for example, is not decreasing in the same manner as we see, uh, for our LTI. So, even though the LTIs are going down, apparently, it doesn't necessarily mean that we are fully in control over our risks.
Um, especially this is also true for industries that might be dealing with, uh, uh, low frequency but high potential events. If we're trying to measure those, uh, our performance on, uh, on those types of events by just looking at how many incidents we've had, we're probably not getting a very good picture, because, well, since there are low frequency events, we don't have a lot of observances of it, so there's very little data to go on. So we are looking then, uh, perhaps more at other types of data, and CCM can provide such a different type of data.
Another, uh, option would be to, uh, to try to get more leading indicators when it comes to safety. Um, so by measuring critical controls or important safeguards directly, uh, we're having a more direct measurement of, uh, uh, of how we control that risk, rather than just using incidents statistics, let's say. Um, but it also gives us the opportunity to already spot that there might be weaknesses in some of our critical controls. So we can actually do something, something before the incident happens. Um, like one weak control does not necessarily always mean that it will lead to an incident. I mean, there usually needs to be some kind of a triggering event that has to happen at the same time as well, or an initiating event, in a sense. But of course, if there's a weakened control in our system, uh, it's probably just waiting around for an initiating event to happen, and then, uh, the weakened control will be challenged and might very likely fail because it's weakened. So if we get, uh, early warnings on the performance of our controls, uh, we have an opportunity to, to do something about it, maybe strengthen the control, maybe think about other options as well, before actually incidents occur. So that's, of course, very nice if we can achieve that.
Another option might be, uh, uh, to help focus on very specific items. So, uh, we might also have other, uh, ways of, uh, assessing our safety performance, for example, by means of audits, or, like, maybe adherence to, to some kind of a standard, which are all, of course, good things to do. I am not trying to, to tell you not to do that. I think that's still a very good practice, of course. Um, but what CCM adds to that is a more specific focus on items that the operation deems, uh, essential. So when you're doing an audit, you're usually looking at a quite a broad perspective of different items that you want to check, and, uh, different systems and processes that need to be in place. Um, within CCM, we basically go out and ask the operation, like, what items do you, is most essential to keep our control safe? And we focus on those particular things. So, rather than looking at the huge breadth of all the options, we look at a couple of very specific things, but then also go into a lot of detail in, uh, in measuring them and, uh, uh, and, and saying something about it. And it's, uh, because the operation has originally identified them to be critical, it is obviously also information that the operation should find interesting, uh, when you, when we start measuring them.
Um, and lastly, as well, uh, there's an option there. Um, uh, a lot of organizations, larger organizations, would have multiple sites, multiple departments, or business areas, or business units, for example, uh, that might be dealing with similar risks. So it could be that you are operating in, uh, in the UK and in the Netherlands, and, uh, um, in Australia, for, for that matter, it doesn't really matter, of course, but you can expect that, uh, those individual sites, no matter where they are in the globe, they might have similar, um, uh, similar risks that they have to deal with on a, on a, on a basis. And if they have similar critical controls as well, there's an opportunity to exchange, uh, information, uh, on the performance of those critical controls with other sites as well. So if you see, for example, that one of your critical controls is failing in one area, but you see that it's doing quite well in another area, uh, well, then there's an opportunity to learn from that, and lessons learned about one critical control can easily be shared through the other business areas as well. So those are some of the, the, the advantages of, while zooming in on that critical control level and, and trying to get some, some measurements in.
Um, I hope that's, uh, U somewhat clear, or some, some options to, to think about, like, why do we actually engage in this, the CCM process? Um, but then, of course, there remains the question of what is it exactly? Um, and I think the best way of looking at it, uh, from that perspective, is actually looking at the, the process, or the typical core process that we, that we see as, as part of the, the CCM, which is basically these eight steps. These, like I said, this is sort of the core process, I would say. Uh, typically, if you want to embed this in an organization, there's, there's a lot more to it, of course, like there's other processes that need to happen to be able to sustain this, this core, uh, process. Um, but I think this is a good starting point to, uh, to get going.
Um, so we basically say, uh, you need to start with identifying first your, your primary processes, which might seem a little bit dumb, but it's basically getting a good understanding of what kind of activities we do, uh, as our primary process. Um, then for those processes, we want to identify, uh, what the hazards are, and we want to probably already select a couple of the hazards that we feel are, uh, the major hazards, let's say, so the ones that we really want to, uh, uh, analyze and dig a little bit deeper into. Uh, we'll talk a little bit more about that in a minute, uh, but the idea is, of course, that those hazards should be tied into the original processes.
Um, then we want to analyze those hazards. Uh, typically within CCM, we use bow ties for that purpose, but you could also, of course, use other methods like, like a HAZOP or something else. Um, we can then, uh, on those bow ties, or those risk, uh, uh, those, uh, hazard analyses, we can, uh, identify our critical controls. So within one, uh, risk study, we might find quite a few controls, of course, maybe, uh, like 40 controls is not a strange number, I think in some cases. Um, but we want to select from those 40 controls, the ones that we feel are most critical, and actually not, not just us, but basically the operation feels is most critical. Um, and then we can create critical control definitions, uh, for those critical controls. So that's basically describing that control in, uh, in some more detail, understanding what kind of processes go, uh, into making this control effective. Because that will later on help us in the data, in the analytics step, uh, to find points where we can measure the performance of those controls, which is what we do with point six. So how do we measure this control? And, uh, we typically try to look into maybe existing data, so data that is already being collected for, for purpose, uh, for, uh, other purposes that we can reuse. Um, but we can also look at more, uh, uh, qualitative data, for example, just evaluating the controls periodically. Actually, all, already often shows quite a lot of interesting results that we can go into as well.
Um, well, the data needs to be subjected to some analysis, of course, uh, because in step seven, we'll be using and presenting the data, uh, and making it, uh, ready for, uh, more decision-making purposes. So this could be in the form of a dashboard, or some, some, some sort of a report, uh, that will help decision makers decide, okay, these controls are now weakening, or, uh, we have multiple controls weakening on the same risk, that might be an issue. So we want to look deeper into that. Uh, and then if we indeed see that there's a critical control, uh, that is lacking, we might look at some options for interventions. Um, and we'll, we'll also have some ideas on that, on those topics. So roughly, that's the, uh, uh, the process. We'll, we'll go through it step by step to, to look at some of more of the details.
So identifying the processes, like I said, it, it sometimes feels a bit like a dumb thing, like because this is the, the primary thing that we do as a business, like, why do we still have to describe this? Um, well, we often see a lot of companies that already have, like, hazard registers, for example, listed to it. But sometimes the link between that, those hazard registers and where the hazards actually pop up in their primary processes, uh, can sometimes be lost. So I, we always still think that this is a good, uh, starting point. So just listing the way you do your primary processes. So I've recently been doing some work on, uh, with the World Steel Association for, uh, creating bow ties around coke creation, which I had never looked at before, but it's quite an interesting process, I can tell you. But it might be something very similar, very simple as this. So, uh, at some point, we store gas, uh, maybe we bunker coal on our side. Those two things come, come together in a coke, coke oven where cokes are being created, and then the cokes is put into storage. For those of you not from the steel industry, the cokes is a, uh, coal product, basically, uh, that is used in blast furnaces, for example, to create the, the carbon content for steel, or have a session in that. Um, and it's done by heating up the coal indirectly. And, well, it's a very fascinating process. I highly recommend learning a little bit about it. But it could be something like this, uh, for your own organizations. It will, it, it's very likely to, to look differently, of course. Uh, but this is an, an option.
Once we know what the process looks like, uh, we can look at some of the, uh, the hazards associated with these processes. Um, so this can be very varied. Uh, so some things would look more at the process safety side of things. So when the coke oven, for example, uh, like scenarios like loss of containment might come into mind, where the heating gas, for example, might escape and cause a fire, or, uh, uh, well, be a pollutant as well. Um, it could also, uh, uh, be related to more of the maintenance tasks associated with it. So if we're storing gas, uh, on site, we might have a large, large gas holder which needs to be maintained from time to time. So there might also be, like, working at height activities going on there, that might also be a hazard. Um, so it's basically just a hazard identification type of session, but then linked to your processes.
The idea is, uh, when we're doing Critical Control Management, you typically set a particular scope. So, uh, some organizations say, well, we only want to focus on the risks that might result in a fatality. So they're really looking at fatality prevention. So, uh, things like, uh, slip, trips, and falls, for example, would not be on their radar because it's not going to likely result in a fatality. But, but they might be looking at, uh, other things like maybe working at height might be causing fatalities, or maybe like, uh, the, the loss of containment might be a good candidate, as it can maybe even lead to multiple fatalities. Um, in other organizations, they also say, well, we do care, of course, about the safety aspect, but we also want to care about the, uh, the asset integrity, or, uh, business continuity aspect, for example, that brought us in scope a bit, and that may, uh, make some, uh, additional hazards to be included in it. I think an important, uh, idea here is, of course, that you want to, before you start a project, scope it out pretty well. So you want to make sure that you have certain criteria on which you select hazards that need to be included in the study and need to be excluded from the study. Um, if you leave that a little bit open to fuzzy, it can lead to, uh, a bit of a scope creep, where you have, uh, well, a lot of, uh, lot of types of hazard, for example, being included, and it will, uh, greatly increase the amount of work, of course, associated with the project.
Well, let's say we've selected some of our hazards, then it becomes time to analyze those hazards, and like we said, like we typically use bow ties for that purpose. Um, it's a, a nice diagram because it can be used for a variety of different types of, uh, hazards. So you can look at some process hazards, but you can also look at the more personal safety hazards, like working at height and stuff like that. You can, can do it with hazard, uh, like with a bow tie. But, like I said, other options are of course also available, like HAZOP for the more, uh, process safety related things could be a choice. U, but also HASTI, where you have just lists of controls might be a possibility. Um, but, uh, yeah, we, we typically prefer bow tie for this purpose. Um, and in the bow tie, we, yeah, we identify, uh, around the loss control moment, various, uh, scenarios that can lead to a loss of control, and then once loss of control has happened, we can look at some of the, the consequences that, uh, might be a result of it. And then, uh, of course, the most important part, the controls, which are typically identified specifically against those, uh, threats, or the blue boxes on the left hand side, or the red boxes on the right hand side. So the controls are specifically, uh, uh, looking at particular scenarios from happening. Um, that's typically what we do.
Um, of course, uh, this will result in, uh, quite a few controls, typically. Uh, so like, like I said, the number of 30 or 40 controls is not, uh, unheard of, it's quite common. Um, so how then do you select the critical, the critical controls from it? And there's, of course, again, uh, different choices to be made here. Uh, typically, uh, you, you create some guidelines on how to select what, what controls are considered critical. One thing that we often take into account, for example, is the, let's say, the likelihood of the, uh, the threats leading to the, uh, the unwanted event, assuming that the controls are, uh, well, realistically unimpaired, impaired, for example. Um, so, uh, we can often find that there are some scenarios that the organization will tell us are, uh, probably more, uh, likely to, to, to result into an unwanted event. Uh, well, if we know that those scenarios are heavier, in a sense, or more concerning, uh, in that regard, it's also likely that the critical controls will reside on those, uh, uh, uh, threats, because they're more likely to be challenged, more likely to, to have to do something, uh, to stop the situation. So that can be an indication.
Another factor that comes into account here is the, uh, potential effectiveness of the control. If you have multiple controls to choose from, the one that is most effective is probably going to be the most reliable, let's say, is most likely going to be the more critical one. Which brings us to the third one, there's usually multiple controls on the same line. So control redundancy can also, uh, change the way, uh, we, we look at criticality. And then another thing to look at is, uh, the how often the control appears in our bow tie. So sometimes we see a control, like, I don't know, like a railing, when we're looking at working at, for example, having a good railing or some kind of a physical barrier to prevent people from falling off the platform. That's typically, uh, a good control, because it also, uh, helps against multiple different scenarios on the same bow tie. So if you see multiple, uh, uh, controls working against multiple scenarios, that can also increase its overall criticality, because you can imagine that if that control would fail, it would fail for all of those scenarios simultaneously, and exposing us to a larger amount of risk that way. So, uh, there's a lot to be said here. I mean, like identifying the critical controls is quite, uh, an important step. Um, but, uh, yeah, we can talk a lot, a lot about this, but in the end, there is a way of finding probably a couple of critical controls to give you an indication on one single bow tie. Yeah, our go-to number would be somewhere between two and four critical controls. So you want to be quite limited in the amount of controls that you, uh, uh, identify as critical, as each of those controls, of course, will have to be measured. So if you select 15 critical controls, you'll be very busy, uh, measuring these kind of things. And it also, uh, inflates the, uh, uh, the, the critical part of the critical control. So if you have 15 or 20 critical controls, like, are they really still critical, because there are so many of them?
Um, then, uh, comes the critical control definition step. And, uh, that's basically a step that, once we have selected which controls are critical, we want to really understand how that control works, what is going on underneath the hood of that control, uh, how can we be sure that this control is, uh, effective? And there's multiple different ways of, uh, defining such a critical control. It often has to do with setting, like, uh, minimum requirements, for example, for the control, and stuff like that. But a good place to start, uh, from our perspective, often is to look at this operational, technical, and organizational components as a sort of a, uh, a brainstorming tool. So the idea is that, for the critical control, we'll have several operational component, components, which is usually basically the steps that need to take be happening in out in the field in order for the control to be effective. There might be technical, uh, aspects to it, so this would be the hardware related to it, uh, and the, the tools and, and, and the technical stuff, basically. And then the organizational stuff would be more related to, uh, which roles are related, uh, uh, to this activity, how many people do you need to have to, uh, to, uh, really operate control effectively, what competencies do these people need in order to execute that control? So these are basically three main pillars, or or guide words, I guess you could say, to identify some of these activities.
So if you're looking at the critical control, it could just be a couple of words in the box, like, for example, like using a fall arrest harness might be the control. But actually, when you dig into it, there's quite a lot of activities going on to make sure that out in the field, people actually can use this fall arrest harness, uh, effectively. So from an operational point of view, of course, people in the field need to be able to wear it. Uh, they need to be able to hook it up, uh, to some, some hookup point. Like, it's nice if you can wear the harness, but if there's nothing to attach it to, there's no real purpose to it, of course. Um, but in order to wear it, of course, there's other activities related to that. So you probably have to be trained in how to wear it correctly. Uh, you might have to be capable of identifying if it is still in sound condition, so to check the straps and check if there's no tears, for example, in the materials. Um, but it might also be related to permit to work systems, where, or permit to work, uh, documentation, which says when to use fall arrest harnesses in which situation, for example, to help people, well, use it at the right point in time in the organization as well.
So from the technical point of view, you'll be, of course, looking at the harness itself, but also then the hookup points and the lines in between, uh, I guess you could say. And in order to ensure that maybe we have some kind of an inspection regime around it, uh, stuff like that. Uh, and from the organization, uh, point of view, you might have some familiarity with it. Oh, I see there's a weird duplication there, but there might be competency requirements, familiarity with the site, and where, where the hookup points are. Um, and perhaps some instructions related to it as well. So the reason why we do this drill down and, and this, this, uh, drill is that these different, uh, uh, activities that we do, or these requirements, uh, uh, can help us later on identify potential, uh, data points that we can, uh, can look at. So the idea is that we can, uh, either try to measure, uh, the control directly in action. Sometimes that's difficult. So sometimes then we're looking at some of the supporting activities and see if we can, we do have some data on those kind of things as a sort of a substitute. There's a danger here, of course, because if we are measuring activities that are too far removed from the actual control, uh, performance. So if we're starting measuring, let's say, just, uh, if we're, if we are doing a, uh, a training once in a while on on this kind of thing, yes, it does give us an indication that, if the training is failing, for example, that can give us an indication that the fall arrest harness is not doing so well. But even if we're doing the training correctly, it's not a guarantee, of course, that people are using their fall arrest harnesses when it really matters. So there's a danger in measuring things that are too far removed from the actual critical control operation. But sometimes it's the only thing that we really practically can do. So there's a bit of practicality involved there. But ideally, of course, we'll be measuring the, the performance of the control directly. Um, and sometimes there, there's good opportunities for that. So, for example, by using sensor data, or, uh, using, uh, some, some smart tools that can help us really register if people are hooking on. Um, stuff like that could happen.
Um, ideally, we typically find, uh, information or data on the performance of these critical controls that all is already being gathered in the organization. So maybe for maintenance purposes, we're already collecting some type of data. Sometimes we can reuse that data to say something about the quality of our critical controls there. Um, well, then we have to, of course, collect that data. Um, and typically there's, uh, yeah, different things that we can, can look at. So the operational data would be more related to, uh, yeah, existing data that being collected in the organization that we can reuse. Sometimes that simply doesn't exist, or it does exist, but it is such of a poor quality that we can't really use it. Um, and then there's no real shame, I think, in, uh, in using more opinion-based data. So this would basically ask people periodically, so maybe once every quarter, or once every month, uh, how they feel the control is currently working. And it might feel, feel like a bit of a touchy-feely type of, uh, of data type, like, how do you know that people are actually, uh, uh, uh, being honest in this, for example, or or not? Um, but, uh, the way we've, uh, we've tried it out with various organizations, we actually, uh, often feel that we get very, uh, uh, high-quality feedback from this, and we're getting a lot of information just by periodically asking people how they feel this control has been working. We get a lot of information that we otherwise would not have found. Um, so, for example, um, uh, people were, uh, um, saying, for example, well, there's this, uh, uh, uh, escape procedure that we have to get out of a, uh, enclosed space here. We practice that once in a training setting, in a training environment, where everything is clean and, and nice. But we actually don't ever try this in the field, where we actually have to do it, and where we can't rely on other people, uh, being present, and there's all kinds of messiness in in the place where we are not really sure if it actually works well. That kind of information we typically don't get from, let's say, incident reports, uh, or only after the fact when something happened. Uh, but also when, when there's like a, uh, a reporting system in place where they, uh, can report, uh, uh, things, this kind of information often does not pop in, pop in there because they don't feel it's important enough to really type a report. But if we actually go out in the field and ask people, they will return this information to you, uh, quite, quite frankly. And since these controls are, uh, the controls that the operation also feels is important, they do feel that, uh, that they are then being heard in that, in that regard.
Um, yeah, the other one is the operational data. And last but not least, of course, there might also be incidents and all the data that we can rely on. But we try to, to stay, uh, uh, I mean, that, that we can still do that, of course. U, but, uh, yeah, we, we prefer the, the other types of data initially. Then we can, uh, put it on, on a dashboard, which could look like something like this, where you have the performance of the controls, uh, well, highlighted. So, for each of the risks, you can have a, uh, uh, performance of the, uh, the control, like in blue would be, uh, effective controls, and then in red, you will have a section of, uh, people, uh, uh, data suggesting that the control is not, uh, as, as well controlled as we would like. You can break it down per site, of course. We can look at it per individual critical control, and then, uh, look into that. So it's giving you very, uh, precise information, uh, about how those critical controls are working, and how that overall risk is then, uh, controlled, by looking through the lens of the, the critical controls.
Well, having that information ready will, of course, uh, uh, spark perhaps the need to, uh, to intervene or do something about it. Um, and, uh, we like to, to think about that in terms of, um, innovation teams as well. So, uh, uh, things that we, uh, uh, basically for each of the critical controls, you can, uh, form an innovation committee or, uh, an action team, basically, with experts from perhaps different business areas. I mean, they don't have to be located in the same location. Uh, we often do this with, uh, groups of people from all kind of different countries within the same company that just happen to be working with the same critical control. We can bring them together, and they can share, uh, ideas or try to find innovative solutions to, uh, to certain controls and really come up with, uh, uh, with interesting ideas. And just, uh, by doing this, this, these exercises with these innovation teams, we've actually seen quite nice results about, uh, uh, yeah, different ways. Also, just the fact of sharing this information can already lead to, uh, to good stuff. But we've also seen, like, cool implementations that, uh, yeah, otherwise wouldn't have been, uh, uh, attempted, basically, on a single site level. But if you can see it, uh, throughout the entire organization, then they can actually see, well, we should actually at, at least try a pilot with this new type of equipment, for example, to see, uh, how it is working. So it's a nice way to bring people together and have a little bit more power of actually changing the way, uh, we do the, we work with that critical control, let's say.
So that's very briefly, uh, what the process, uh, uh, mainly looks like. But I think it's very important that if you want to introduce this in your organization, uh, it's important to realize that, well, this is just the, the core process, in a way. If you wanted to, uh, to have a longer life than just after the, the, the project implementation, you'll have to think about introducing, uh, or setting up review cycles, in a way, around these, uh, these core elements. And the way we see it, there's sort of like a fast review cycle and a slower, uh, review cycle. So the fast cycle, you might want to do, maybe on a monthly basis, in some cases, maybe even on a daily basis, if it's a super critical type of thing. Um, but it could be on a quarterly, monthly, like relatively fast, a couple of times a year, at least you want to, to do this. The slow cycle would be a lot slower, so it would be maybe once a year, maybe once every two years, depending on, uh, on, on what, how you want to set it up, of course.
Um, the fast cycle, uh, is mainly focused on that critical control performance. So just, uh, periodically getting information about how well the control is working. Um, so that's where a dashboard, for example, is handy, because you'll expect the information to be, uh, in flux quite heavily. Um, so you can see the improvement over time, or the decrease over time, and, uh, and, uh, do some trending information on it. Um, so that's, that's where you want the, the fast cycle. The slow cycle, um, is more suited at, uh, making sure that you're still measuring the right kind of thing. So this is more about measuring the thing, this is more about, are we still measuring the right thing? Is it still valid, uh, that sort of stuff? So you probably want to, once in a while, review your risks. So, so check if, maybe due to operational changes, new risks have have occurred, or maybe you have changed the scope of CCM. So you now also want to include, uh, as an integrity stuff. Well, then you will have to review your risks as well, to make sure that you're that you're looking at the still the right risks. Uh, the bow ties might want to, uh, uh, be revised from time to time, of course. The bow ties, ideally, uh, uh, or the risk analysis method, whatever you have chosen, need to be, uh, kept up to date. So, if you are no longer using sort of controls, you don't want them to be, uh, uh, to end up in your bow tie, or maybe, let's say, you're now using drones or something like this, that might change the way, uh, you, uh, uh, you have to manage your risks as well. Uh, the definitions might change. So maybe, uh, over time, when we're trying to improve our controls, it might also mean that we're now changing the way we work with those controls. So, uh, those definitions that we've created need to be kept in line. And, uh, last not, but not least, of course, the, the report that we're using, like the dashboard, or whatever we choose to use, uh, also probably needs to be updated from time to time in terms of layout. So is it still serving the purpose, uh, that we wanted, uh, uh, to serve? And then we can, can change it and make it better as we go along. So, uh, by building in these review cycles, we can make sure that the, uh, the underlying processes remain accurate enough, uh, while we, uh, uh, measure our the performance of our controls directly.
Um, yeah, so, um, one of the, uh, the, the, the challenges we might have have, uh, in, in, in a process like this, is that you can imagine that going through all these steps, that's quite a lot of work. Um, but then if you have an organization which has multiple sites, that means that you'll have to go through these steps at different sites, perhaps multiple times over the process. So it can quickly spiral out of control, or in the sense of it can, can quickly, uh, uh, quadratically, basically, increase the amount of work involved with a project like this. So there's a couple of ways of, of, of trying to deal with that, uh, um, uh, in a smart way, we hope. And that's, uh, for example, by, uh, using a sort of an inheritance system for your, uh, for your bow ties, or for your, uh, uh, risk assessments. So, uh, what some companies, for example, do is, they want to identify, uh, uh, at the group level, so at the highest level in the organization, at the staff level, uh, identify a couple of risks that are shared amongst all of the sites. So things like working at height, you probably will expect that to happen to some degree at every single site, at, at some point. So you might want to create a generic risk assessment for, for that particular risk, with, maybe already identify some of the, the, the critical control candidates there. Once you have finished those, those core bow ties, you can, uh, offer them up to the, uh, the business areas, or the sites underneath it. So they may take a copy of it, maybe make some, some local adjustments. And I mean, they already have a starting point that is the same, at least. So that, that forces people to have a somewhat similar view on the matter. But they can, of course, still make their local adjustments. I mean, uh, per country, there might be different legislation, there might be different, uh, uh, practices, for example, and you want to make sure that the bow tie reflects that. But at least probably scenario-wise, in terms of what can go wrong, it will probably be, uh, well, 90% similar, perhaps. But there's always like this 10%, uh, room to, to optimize it for your, individual location. And the idea is that there would also be a bit of a review cycle. So if the Netherlands, for example, makes an adjustment to their bow tie, it will be fed back to the group level, and they can see, okay, well, they've made these kind of changes, that's actually a good idea for them. So that's fine. If they're moving too far away from it, or they're making choices with which the group level does not agree with, then you can have a discussion about this and say, okay, why did you decide to do that? Is that a good choice? Or, um, maybe there's a misunderstanding or something like this, then we can talk about it. But the idea is that at some point, you, you do end up with a localized bow tie, so something that's applicable to that local business area. And then you can push it down to an additional layer, uh, in between. And it can very well be that those sites feel that that the bow tie at this local level is already similar enough, so they don't feel the need to make any changes. So they just basically make a copy of it, and it's, it's the same thing. Um, but, uh, in other sites, it might be that, well, this is more like a project organization with a very new type of installation that they're doing compared to an existing site. So they have actually quite a few changes that they want to make. Well, they can still, of course, make those changes, and then feedback what they have changed, uh, upstairs. So they, they know where the, the differences lie. Uh, this saves a bit of time in constructing all these risk assessments. So not every single site will have to do their own, uh, bit. They will be able to borrow from what has happened before. And a nice thing about setting up these review cycles, I think, is that, uh, if you see that, uh, all the business areas are basically making similar changes, well, then you probably, uh, should change your original bow tie to begin with, because if everybody's making that same change, probably we've missed something at the group level, and we can improve it. So that's an option. But it also builds up this, this cycle, um, where we can, uh, uh, uh, the structure, basically, where we can share information, uh, uh, cross. So it could be, for example, that here in the beautiful town of Suir in the Netherlands, they have a local bow tie, and they have flagged an issue with it. So maybe they have had an incident, or maybe they have had some, uh, some, uh, critical control performance data, uh, that shows that it is not working as well. They can raise the flag and say, hey, we have this change in, uh, in this control, or we have an issue with this, uh, or, for example, we have made a change to this control, and we think it's a great idea. So, uh, uh, they flag it up to, uh, to the, uh, uh, the, the Netherlands as a, as a whole, and they, uh, pass it on to the group level and say, hey, our one of our sites has made this particular change, might
be a good idea to, uh, uh, to consider for the other sites as well. And then they can, uh, uh, the group level can trigger a review, uh, on, let's say, the other business area, such as the UK, and say, "Well, they've made this particular change. Is that something that you might benefit from?"
And then, uh, well, Newcastle may say, "Well, that's not really applicable to us because we're using new type of controls." But in CLI, the row, they might say, "Well, that's actually quite a good idea. So let's, uh, let's actually change that as well, or at least consider changing it." So it's a way of, of, uh, like handing information, uh, in a structured way to, to other sites as well.
Of course, there's still also an option not to go through all the way up the tree. You can also just talk with sites directly. But this is at least a more formalized approach, which you can, uh, maintain in the long run as well.
Um, so to close off, I have a couple of, uh, like success factors, I guess, that we, that we have talked about or like that we've experienced so far when implementing these kinds of things. Um, so, uh, one important part is the fact that ideally, uh, the, the critical control management process should be business owned. So it should be, uh, not like there can be a, it can be tempting to, to make this sort of an, an HSQ type of party where the HSQ Department really wants like it forces this this this process through. But, um, it, it can only really work, I think, effectively if the business intentionally owns that process.
So, um, one way of doing that, for example, is to say, "Well, um, as a, the way the business evaluates itself, it's not only by the, uh, the amount of, uh, money we make or the, uh, the the incident rate that is going down. We should also be looking at, uh, the performance of our critical controls, and the, the business needs to be evaluated on those critical controls as well." So they should basically intrinsically be interested in the way those controls are are working. So having ownership in the business and having managers that that that really feel like, "Oh yeah, we should really be looking at this, and this will help us make a safer system and a more reliable system." That's a very, uh, key factor. So making sure that you have the right, uh, sponsors, basically, in your organization to do this is, is of course critical, as it is the case for any other project, I think.
Of course, um, it's also important to, uh, prefer validity over availability of the data. So it can sometimes be tempting to use, um, existing data, uh, that's not of very good quality to to assess the the control itself. So it's better to to choose, uh, data sources that are a little bit more valid than, uh, the ones that simply are available. So it's better to to spend a little bit of extra effort to trying to get new data, for example, in rather than using wonky data that might be already available. And there for the pickup, it is probably better to use the valid data, uh, often because it tells you more about the the quality of it. Because if you're just using poor but available data, yeah, you get some results back, but it will be very often reverted because it's, it's not telling you the the the full story. So having some more valid data is usually preferred over just going for the the available stuff.
Um, another thing to make it quickly, uh, uh, matter, basically, or make this the CCM process an important part of the way the business works is by quickly measuring and reporting. So, uh, the idea is that, don't try to wait until you have the perfect descriptions for all of your controls and the perfect Boti is ready. Just start measuring and reporting on the information as you go along. If then you realize that the the results are like, if the business feels that their results are not completely reflective of the way they are doing things, they'll be the first one to tell you and to to improve this, uh, this process.
And it's just a great way of showing, "Yes, we, we do care about this information, and we can, uh, uh, uh, we, we report it. If you're not happy with it, we can of course change it, and we can, uh, uh, make improvements to it." But that enforces a cycle of improvement, uh, as we go along.
It's always great to communicate some some, uh, impact stories as well. So, uh, as we are finding new information about, uh, uh, critical controls and we are improving some of the critical controls because of the information we found, it's great to share that with the rest of the organizations to also show that this CCM process does have a a good impact, and we've seen improvements with controls, uh, through measuring these these controls directly. And, uh, people on the workforce can then also see, "Okay, there's actually stuff happening with the information that that I, uh, uh, put put up front. So there's actually controls that I am working with on a daily basis are actually improved by, uh, by evaluating these kind of things, and we, we do get money for, uh, for better things that way."
Yeah, and, uh, uh, make sure that you define your success factors with the decision makers as well. So, uh, the people that actually need to use the data, of course, need to, uh, uh, want want to make sure that the, uh, that you have proper success factors defined for it. So you can also say that we have now delivered this information to you, uh, that which closes off the project in a way.
And the last bit, because I'm running a little bit out of time, um, is the using of the, uh, the carrot rather than, uh, the stick. Uh, uh, so the carrot rather than, uh, the stick. For example, what we mean by that is that, uh, ideally the information, like if people are evaluating critical controls and they're seeing that controls are not working as well, um, it should be an encouragement to then, uh, uh, uh, to the, uh, the business owners, basically, to make sure that, uh, funds and resources end up in the place to fix those controls, rather than slapping them on the wrist and saying, "Oh, you should do a better job at implementing that control." That's not, uh, uh, what we try to do here.
Of course, we try to make sure that, uh, uh, uh, funds become available, uh, to improve these controls and do something before an incident happens, rather than slapping people on the wrist that the, that the, uh, performance of the controls is lacking, for example. So it's about finding, uh, where the weak spots are so we can allocate resources to those, uh, resources. And you can quickly, uh, uh, kill, uh, a good buzz in the project if, uh, if it ends to be ends up becoming used as a sort of a punishment tool. Of course, that that's something that should always be avoided.
One way, um, to do this is actually to have a budget available for these innovation teams and these critical control performance, uh, teams, so that if controls are indeed performing poorly, there is already budget available to directly tackle these kind of things. And then then actual stuff can happen on the workflow as well.
That's as far as I wanted to take you, uh, today. Um, if there's any questions, I'd be happy to, uh, to ask them. We also have a little poll. I, I've prepared another poll for you. Um, since we've gone through the the, uh, the overall, uh, uh, CCM process here, I was wondering if you've already have some experience with, uh, with implementing CCM. Which of these steps do you feel is is challenging? I'll, uh, send up the poll while we wait for some other questions to come in. Um, if you haven't done it yet, for example, you can, uh, um, skip the poll if you want to, or maybe say, "Okay, well, I don't fully understand this part of the process." Feel free to, uh, to analyze that.
Those, um, so any, any questions, uh, on what I've said? I mean, there's a lot of information to take in. I am well aware. Um, but hopefully, uh, there might be some some questions from you. If not, let's take a look at some of the poll results. Um, so we see, uh, uh, a part in the the data analytics and the, uh, identification of the critical controls and the definitions of the critical controls, um, as being some of the people that have noted this this to become a, uh, become slightly more problematic.
Yeah, what I can say on on this topic, I think, um, uh, don't feel, uh, uh, try to, uh, to start measuring. I think just by asking these kinds of opinions, that's the most simple thing that you can do. For some organizations, for example, we just, uh, uh, for a select number of people in a particular site, for example, they get a, a very simple question, every quarter, maybe two or three questions about about control, like, "How do you feel this is performing? Have you noticed in the recent time to, uh, that there's any issues with this, or you feel that the control might fail at some point?"
It is a very, uh, qualitative type of, uh, uh, data, of course, but we have seen very good results, and it's relatively easy to set up, uh, compared to, for example, using the operational data, because that's not always available, of course, to you. So we can, uh, can use that. Um, but it's also, uh, uh, uh, like like sometimes the operational data is much easier. So sometimes we do have this information, and then it's always better not to bother people with additional questionnaires like that's typically what we try to avoid.
So if we have this data, it can be very beautiful to use, but it's not always a possibility. And then, uh, there's no harm in going for the, uh, the opinion, as we have already seen quite a lot of good outcomes with this approach as well. And then at least you can start, um, working with with the data as it comes in. If people then start to complain about, "Yeah, well, this is just opinion, like, uh, like I don't see it this way, or, uh, something like this," well, then at least we can, uh, uh, we, we can feel a drive for getting some more objective data in there, for example. So then if people are worried about that the opinion is not clear, is not, uh, honest, or is not, uh, U valid in in some cases, we can then look at other options of, uh, uh, of finding data. And there might be a more willingness to to do that from that point on. Because if you have to spend a lot of effort in getting operational data to begin with, before any data has been collected upfront, can be challenging because they like, "Yeah, why, why do we spend so much effort doing this?" Whereas if you're first collecting some opinion data and get the process rolling and show how it can, uh, uh, can inform your decisions, it's an easier sell in that later stage.
For the critical control definitions, yeah, I don't have too much time to go into this at at this stage, but we have a couple of, uh, forms or like templates, uh, that you can fill out for your critical controls to help identify these, uh, these definitions, and then also, for example, identify what your, uh, minimum requirements might be, or stuff like that. Who is the the critical control owner, for example, per per site? This kind of information can be, uh, uh, laid out in these kinds of templates. And then if you've filled out the template, you'll probably have a better understanding of what that critical control looks like. If people are interested, I'm I'm happy to share that, um, with you, or let's talk about it. Those of course are possibilities as well.
All right, if there's no other questions, or is there people posting questions in the, uh, in the chat? I see. Ah, okay. Thank you, Roy, for the for the comment. Glad that you enjoyed it.
Well, with having said that, I think we can, uh, can wrap up the call. It's still five minutes before time, which is excellent. Um, yeah, if you have any questions, feel free to stick around. I'll be here for another couple of minutes. Uh, if not, I'd like to thank you very much for your participation. Great to see so many people, uh, out in the group as well. Um, and also very nice to see some of the familiar faces here. So I hope you enjoyed. I hope you liked it. I hope I didn't overwhelm you with information, but if I did, I'm happy to discuss it at a later later stage, uh, uh, a little bit more slowly if you want to. Thanks so much.
Um, yeah, goodbye. Have a very nice day. I hope you enjoy it.