Check the
documentation
Ask the
Community
Take a look
at
Academy
Cognite
Status
Page
Contact
Cognite Support
- We need the ability to create check lists by Equipment Type in a generic way. For example, these are the checks for an overspeed trip on a compressor? The current checklists has an asset is assigned on a task level which only make sense If you are doing an operator round and moving from an equipment to another equipment in a round. We need the ability to have a checklist against one asset that has checks for that asset. Examples 1) Functional Test for a Pump 2) Overspeed Trip Test 3) Overhaul of a Compressor etc
- We would like those generic check lists to be then pulled by technician, completed, tied to the WO and the Asset it was completed for in the WO. It would be nice if some AI looks at the Work order, then tells the technican which checklist to use.
Nice to Have
- Ability to create checklists that are visual in nature or has infographics that you can put measurements around a bearing picture for example instead a routine scrolling checklists.
- Ability to have pictures on a task level
- Ability to have thresholds that are dynamic or calculations of other tags with some logic and not just static numerical values.
Hi@ibrahim.alsyed ! For transparency I’ll just copy-paste what we discussed on email here as well. Interested in hearing the thoughts from the rest of the community on this topic :)
The current Templates functionality in InField is largely built towards process operators in the context of doing operator/routine rounds type of work. As part of InField 2.0 we are, as you know, re-designing Templates to enable more flexibility in the tasks you can create and how you schedule them.
When creating tasks, one key new component is the ability to create "custom labels". In short, this means that you are not restricted to the simple "ok, not ok", but can define a task as for example "yes, no, etc.". However, you can also create tasks that might be more relevant for e.g. an inspection checklist like "compliant, non-compliant, not available, not applicable".
In short, I believe we are already developing functionality that makes it easier to create other types of Templates/Checklists than those for routine based tasks.
Now, the next step (as you point out), is to "liberate" the Template to connect it to an Asset (instead of each item being connected to individual ones) or a group of Assets (e.g. all PSVs). This is something we want to do in InField, and have seen as a need from multiple users & customers. Currently we have on the Roadmap to look at execution of SOPs in Q4, and I believe that from an InField perspective this is conceptually the same thing (similar functionality needed). If we are able to prioritize this sooner than Q4 is something we can evaluate once we have migrated to InField 2.0.
Tying a Template to both an Asset and a Work Order is also something we've seen the need for across. Typically we've heard these referred to as PM paperwork, basically a Template/Checklist attached to the e.g. an SAP Operations attached to the Work Order. Such as a Template/Checklist describing the actual step of isolating equipment X that you are doing work on. This is also something that I would want us to do in InField, but wrt sequencing it will be after tying a Template to an Asset. The reason for this is also that the Asset is the natural link between the SAP WO and the Template. The Asset <-> WO link exists today, so we just need the Asset <-> Template link.
In short, both 1 and 2 are gaps that we are looking to fill with InField. Based on the current Roadmap we are looking at Q4, but again, we can evaluate once we have migrated over to InField 2.0.
Nice to haves:
1. Hmm, this is a new one. Don't fully get the picture just now, but a walkthrough of how you envision this would be great!
2. Ability to have images, or relevant information in general, is another Template task "component" we've seen the need for at other customers as well. Believe we want to add this one, but we'll have to see when it can be prioritized.
3. Yes, we've seen this one as well. We'll not have dynamic thresholds on the "numerical reading" component now, but definitely something that can be relevant to build out in that component later.
Br,
Kristoffer
Thank you.