I’m trying to implement a dynamic work instruction setup in my workspace while still accommodating our QMS requirements to have changes to procedures reviewed before they can be committed. I have a structure down for the review process, but I’m trying to figure out how to easily accommodate changing the order in which procedures are presented to the user, in cases where that matters.
Originally I was thinking of having a linked list-like structure, where each procedure record contains the address of the next procedure. However, it occurred to me that since linked records load as a text array, then they might be treated as a stack, with each additional record getting pushed onto a text array. In that case, it would be super easy to implement modifications, because instead of needing to update the procedure, we could instead just rearrange the order that the procedure addresses are stored in on the top record. Then, moving forward or backwards in the procedure would just be traversing the text array in the procedure, which is also easy.
Is this actually how linking new records work? The new address just gets pushed onto an array as the next ID in a stack? Or is it something non-deterministic so I can’t rely on it always loading in a specific order?
My suggestion is to have a Tulip table for the instructions.
In that table have columns for Step number, Instruction, Image, Approved, etc
Then you can filter for all approved instructions and then sort them by step number. (If you have multiple products you can also filter by product name)
Then use the “interactive table” widget to present the instructions to the operator.
If you want to re-arrange the sequence then you can renumber the step numbers. Also in manufacturing we typically increment step numbers by 10. (10, 20, 30…) that way if want to add an additional step in between steps one and two I will just create an instruction with step 15.
I personally did not like the linking records. It made the architecture to complicated for my use case. So I just prefer to have a dedicated column for product name and use filters.
Edit. Tulip support strongly discouraged what i described above for my application as I had many products and every product had many different instructions. So it might be a good idea to reach out to support. The solution in my case was to develop many smaller easy to manage apps rather than having one behemoth table.
@David2, you’re asking a really great question here about dynamic work instruction architecture, and @Rakitha, you’ve made a few great points about the pros and cons of dynamic work instructions, as well as our general recommendations.
Dynamic work instructions are a tricky use-case. They can add a level of complexity and admin work that can lead to diminishing returns.
All that said, there are plenty of situations when they make sense. If you’re looking for a reference build, we have “table based work instructions” templates in our work instruction suite in the library.
I would also recommend looking at the architecture we outline in the “table based work instruction” course in University.
@John@Rakitha
Thanks both of you. In our case, we are an FDA-regulated company and for regulatory reasons we have the following requirements:
Release of documents must be reviewed and approved before use. Same for changes to documents
Computer systems which impact the manufacturing process must be verified/validated when released or changed
For us, this means that to have a large number of independent apps with the potential for significant changes actually creates its own large overhead of admin work. It also means that our table workflow requires a couple intermediaries that make it more complicated than Rakitha’s suggestion.
I’ve been referencing most of the architecture from Tulip’s suites for the equipment logbook and work instruction templates, but I will take a look at the course. I suspect there’s a lot more detail that I can get there than from just reverse-engineering the templates and frankenstein-ing together features as needed.