Rank: Forum user 
|
Dear all,
I'm confronted with certain situations where the team is confused or not getting aligned regarding incident or unsafe conditions classification.
A broken hydrocarbon (not operational) pipeline was observed during a line walk and as per classic definition it is an unsafe condition and not an incident. However team wants to classify it as an incident coz the very fact that the broken pipeline is a result of some incident.
Similar examples were given of an observed damaged condition as an incident and not an unsafe condition. How do one explain the distinction under these circumstances. Damaged pipeline if taken to service has a potential to cause a loss of containment incident. So in that sense its an unsafe condition. But the very fact that it is damaged as a consequence of some incident thats unknown when observed. So isn't it an incident.
Seeking your expert views pls.r
|
|
|
|
|
|
Rank: Super forum user 
|
My view is that it doesn't really matter what it gets called as long as it is reported and investigated. You will have some in-house definitions of these terms (which are the single source of truth here) and of course it makes sense to train people on these with some examples that you ask them to classify and then tell them the correct answer and the reason for it. I would see this as part of a wider training on the whole topic of incidents not something worth doing on its own.
If you really care about the consistency of the classification, I suppose because the counting and comparison of these things is used as an indicator, then it's just a case of adding a quality control check to the reports, at which point if something has been wrongly classified the classification is changed. If someone is already reviewing these reports then that shouldn't be too much trouble. Another way to deal with it is to have categories of these things so that your unsafe conditions have to be categoised as damage discovered, corrosion, sharp edges, unprotected edges, etc, all the kinds of unsafe conditions that can be imagined, and incidents as struck by vehicle, interference by trespasser, etc etc etc, all the kinds of incident that can be imagined. This way, someone who classifies it wrongly will see at the next step that they are in the wrong list. However this would be quite laborious and annoying to do and there will be some conditions and incidents that no one has ever envisaged and so don't get on the list. Captcha: rRSe Edited by user 05 October 2022 06:35:25(UTC)
| Reason: Not specified
|
 3 users thanked Kate for this useful post.
|
|
|
|
Rank: Super forum user 
|
I am reading line walk as factory inspection or Gemba walk - here as Kate has stated the categorisation is a wholly secondary activity to what should be the primary purpose identification of issues requiring rectification either immediately or as and when resources permit.
|
|
|
|
|
|
Rank: Super forum user
|
I am reading line walk as factory inspection or Gemba walk - here as Kate has stated the categorisation is a wholly secondary activity to what should be the primary purpose identification of issues requiring rectification either immediately or as and when resources permit.
|
|
|
|
|
|
Rank: Super forum user
|
Morning Prads I don't recognise the concept of a "classic definition" of an unsafe condition or incident. Some years back we had our annual audit to let us continue working in a particular sector (which I am not going identify on an open forum). The Lead Auditor advised me that they were going to issue a Non Conformance Report for not having a policy/procedure for the reporting and investigation of all "near misses". I advised them that whatever I thought, WE (the company) would have to reject the NCR. They asked me why and I told that it is impossible to come up with an authoritative definition of a "near miss". So they asked me to explain and I used the same example that I always use. Brick falls off scaffold So, we went through a series of variables relating to said brick falling off said scaffold until eventually they said that it was NOT a "near miss" and I advised them why it WAS a "near miss" - at any point in the exercise I was quite prepared to argue the opposite!! It doesn't actually matter what you call it - rather - as Kate and Roundtuit have said - that you take appropriate action to learn and improve. The only real reason for needing to classify it as an A or a B is for the metrics you maintain, and, in all probability what you count and how is likely to be somewhat different from the business next door. What you can almost guarantee is that if you decide you want more "near misses" to be reported and you incentivise (by whatever means) the reporting of "near misses" then you will get more of them and less reports of "incidents". .....but if you decide you want more "incidents" to be reported and you incentivise........... P
|
2 users thanked peter gotch for this useful post.
|
|
|
|
Rank: Forum user
|
Thank you everyone for your insights. My question was more related to entering the particular condition/event into the system (SAP EHS) where the worflows are designed differently for Incidents, Near-misses and Safety Observations (Unsafe Conditions/Acts). If users are going to mix it up due to lack of clarity in the definition of terms, then the system is not being helpful. If it was manual reporting, then yes there is a room to people to make learned decisions as to how it should be categorised. Here, things become a bit reactive and then we have to go back and get them revised and corrected in the system.
|
|
|
|
|
|
Rank: Super forum user
|
I haven't used the particular system that you have, but a similar kind of thing that I have used has a validation stage in the workflow so that the incident report is checked and amended if need be by a designated person before it progresses through the system. It also has little information buttons that tell you the definitions of things.
|
|
|
|
|
|
Rank: Super forum user
|
Hi Prads Like Kate I am not familiar with the system that you refer to. However, from what you have written it exhibits precisely the same problem as any system that TELLS you what to do next, thereby limiting the ability of the team handling the information to make case by case choices e.g. as to what depth of investigation might be appropriate. So, you could have: 1. An incident - this might only merit a skim across look but it might merit a full root cause analysis. 2. A near miss - this might only merit..... 3. An observation report - ditto Why have a system that stops you (a team when appropriate) from making the appropriate professional decisions. I have always taken the view that the depth of investigation should be influenced mostly by an assessment of what could easily have happened, NOT what the actual outcome was. "What could easily have happened" does NOT equal the worst foreseeable consequence which is almost invariably at least one dead body.
So you could have a fatal accident that only merits a very short investigation - it may be entirely obvious that there is an unsafe condition to be fixed. So fix it. Conversely, you can have a "near miss" or whatever you categorise it, that gives a signal that this could easily be the precursor of something disastrous. This should prompt a much more deeper analysis. But doing this requires PEOPLE to think, not some preprogrammed system that cannot predict EVERYTHING. YOU are much more clever than the software!!!
|
1 user thanked peter gotch for this useful post.
|
|
|
|
Rank: Super forum user
|
Deepest sympathies If this is the same style of SAP (S All Progressing) used in financial management then the input is very important to release the next step in the activity. Rather than ask this forum about the interpretation perhaps step back and ask the implimentation team to create a visual reference guide of the various system inputs required. Any form of bespoke tailoring in SAP (Solution As Provided) is normally attached with a massive invoice
|
|
|
|
|
|
Rank: Super forum user
|
Deepest sympathies If this is the same style of SAP (S All Progressing) used in financial management then the input is very important to release the next step in the activity. Rather than ask this forum about the interpretation perhaps step back and ask the implimentation team to create a visual reference guide of the various system inputs required. Any form of bespoke tailoring in SAP (Solution As Provided) is normally attached with a massive invoice
|
|
|
|
|
|
Rank: Super forum user
|
Computer based systems are good if they are used to RECORD incidents etc and link together the various steps in something like a process. What they should not be used for is to DRIVE a process and to remove human insights. There are people who like the idea of systems that do the H&S for you and at the end tell you categorically if something is safe or not, except experience shows that in the real world they never deliver and you end up trying to make the data fit the desired outcome rather than actually trying to manage any issues- tail wagging the dog sort of thing.
|
1 user thanked A Kurdziel for this useful post.
|
|
|
|
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.