Ventana software support forum

Hi there,
it's my first time on here - I'll try to post all the information needed. Please let me know if I have missed anything.

I'm modelling a system where items are processed on a FIFO basis. We also need to plot the distributions of the items' ages in the queue. Hence the QUEUE FIFO function seems ideal. There are 3 categories of items hence we have an "Item Category" subscript. I've attached a simple version of a program which models this.

In reality, items can be taken out of the processing system and put "on hold". They are injected back into the processing system at a later date. They may subsequently be put on hold again. For the moment, I assign the time that the items go on hold as being 30 days.

I'm having great difficulty modelling this "on hold" process. I've attempted to have a DELAY CONVEYOR function which would look something like:
Items on hold = DELAY CONVEYOR(Items In Hand,30days,0,initialProfile,Initial items in hand,30days)
where initialProfile would be some sort of flat age distribution (definining this is the least of my worries!)

However, I'm getting into a real muddle trying to ensure that the items returning from being on hold will go back into the processing system at the correct time and that their ages will be accurately modelled. I have set up an "Item Age" subscript in preparation for this (see at the end of this message), but I am not sure how to apply it properly.

I would be extremely grateful for any tips about how to go about this or even more fundamental advice about whether I am using the right approach to model this. I am using Vensim DSS32 Version 5.0a - version determined by system administrators and beyond my control.

Thanks
Sarah

Item Age:
d0,d5,d10,d15,d20,d25,d30,d35,d40,d45plus
~ Dmnl
~ Age of item in days. Example: d0 is zero days old (i.e. "new"), d25 is 25 days old, d45plus is at least 45 days old.
~ Subscript divisions chosen in this way because targets are based on items that are 15 days and 45 days old
~ :SUPPLEMENTARY
|

ItemsAllButNew:
d5,d10,d15,d20,d25,d30,d35,d40,d45plus
~ Dmnl ~ |

AgeGroupYounger:
d0,d5,d10,d15,d20,d25,d30,d35,d40
->ItemsAllButNew
~ Dmnl ~ |

Do you really need discrete item age tracking for some kind of tactical planning process, or is this just a part of some larger strategic model, so that some kind of coflow formulation would work?

A solution might be possible with QUEUE ... ATTRIBUTE, where the attribute is the creation date of the item, but I'll have to think about it.

If I understand correctly, the challenge is that items need to jump in line into the queue, according to their age? I'm guessing that this will have to be done with an explicit stock/flow structure, because the QUEUE functions won't permit it.

Hi, thanks for your quick replies. Above all, I want the model to tell me how many items are in the system (either being processed or on hold) with an age of >=15 and >=45 days. The QUEUE FIFO and QUEUE AGE IN RANGE functions were doing the ideal job before I needed to introduce this procedure of putting some items on hold.

Now reading your 2nd reply.... yes essentially the items being released from hold would need to jump back into the correct position in the queue. We were previously using a stock/flow structure to attempt to achieve this.** Then we found that the QUEUE functions were so darn suited to our required outputs that we have been very keen to use them. (** and here I do mean "attempt".... this was rather difficult to model and another post about this may follow.....)

I'll have to think about this a bit more - from the dual-pronged attack of
- investigating the capabilities of Vensim
and/or
- seeing if we can model reality in a different way that will allow both a FIFO queue and an on hold process to be incorporated.

If yourself or others do have any ideas, regarding either prong of the attack, then I would be very grateful to hear them.
Thanks
Sarah

Can a given item go on hold more than once?

What's the maximum age in the system? Or does it really not matter beyond 45 days?

At this stage, I am assuming that an item can indeed go on hold more multiple times. However, I would need to check with the operations staff if this is the case. Do you envisage the on-hold-multiple-times scenario to be vastly more difficult to model than the on-hold-once scenario? It *may* be the case that the on-hold-multiple-times is actually rather rare and/or can be left out of the model without causing any significant effect. I just don't know at this stage but I will ask.

Regarding the ages of the items let me clarify the specifics. We want to monitor whether 80 (95) % of items incoming are processed out of the system within 15 (40) days. (Yes, sorry it's 40 days not 45 days that is the cut-off. As far as I know it is equally bad if an item has been in the system for 41 days or 141 days. N.B. I may need to adjust my "on hold time" down from 30 days, but I have at least been told that we can keep this as a constant for all items so that is one simplification that may help...)

I think the multi-hold scenario means no QUEUE option (or at least it's not obvious to me how to do it). Actually, I'm not sure it works anyway.

Here's a continuous version with arrays, based on your start.

Hi

Two other options.

One is to simplify your model (avoiding subscripts if possible for instance) to make it easier to understand its behavior. If you can make it work this way, you may keep the queue fifo.

The other is to avoid queue fifo and use arrays in replacement.

The queue fifo delivers aggregate information about the elements in the queue. It is very difficult, eventually impossible to trace individual elements in the queue.

Sometimes I avoid queue fifo, because it works a bit like a black box, and I use arrays eventually with delays, where I can trace each individual elements, especially if they are discrete. I can too program whatever I want if the process is tricky and I am not restricted to what the queue fifo does.

Here are just some suggestions without guaranty. You will have to experiment on your own.

Regards.

JJ