Science desk
< January 27	<< Dec \| January \| Feb >>	January 29 >

Welcome to the Wikipedia Science Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 28[edit]

Scheduling in a production line[edit]

I work in a factory and I find that management want me to do many jobs that they label as "urgent" before "non-urgent" jobs.

The non-urgent jobs represent about 70% of the work to be done. What happens though is because urgent jobs jump the queue all the time half the jobs that I produce by the end of the shift are "urgent".

My theory is that it is better to concentrate on maybe 10% "urgent" and then do 90% as "non-urgent"

I'm sure there's a science or maths behind this that can provide answers. What are the google search terms I have to look up so I can learn more?

- Urgent jobs are usually (1) those that have to be "remade". i.e. were rejects the first time they were processed (2) assigned priority from front office or sales (3) near their due date for expected completion. My suspicion is that urgent jobs are mainly of the (1) and (2) type. — Preceding unsigned comment added by 118.209.1.40 (talk) 04:44, 28 January 2021 (UTC)[reply]

A solution that worked once in a real workplace: ask for a priority ordering instead. And use logic to push back when they assign three top priorities. They get one first-priority job, one second-priority job, and so on.

It sounds like you don't know which of the 30% of jobs labelled "urgent" are most urgent, or which of the "non-urgent" jobs is closest to becoming "urgent". You are right that the risk of overdue jobs might be lower if they told you. If all the jobs get done in time, though, it may not matter to management. And they might say it would take too much work to decide on the precise order for the jobs.

The statistical concept you want is probably the Poisson distribution. The jobs are Poisson events if jobs arrive at random times, but at a fairly constant long-term-average rate (so sometimes there will be a short-term rush or a lull, randomly).

Also, I'm guessing working in a rush increases the chance of rejects that need to be remade, the old festina lente problem. If your workplace doesn't have statistics on that, they should. They might find out that the "urgent" jobs actually go slower, once you average in the remake time. The expected time taken for a job is the time needed to do it once, plus whatever number you get when you multiply the time to remake it by the probability of the remake being necessary (on a scale of 0-1, where "1" is "certain to need a remake" and "0" is "no chance of a remake").

Since I don't know how front office or sales are deciding whether a job is "urgent", it's hard to speculate on what would affect their decisions.

They can also adjust the "urgent" threshold. If a job becomes urgent with only six hours slack (that is, a 4-hour job becomes "urgent" 10 hours before it's due, and a 1-hour job becomes urgent 7 hours before it's due), there will be more urgent tasks than if a job becomes urgent when it only has one hour's slack. You could ask how they set the threshold. It is possible that they are automatically adjusting the "urgent" threshold so that 30% of jobs will always be labelled "urgent".

I assume that all jobs, if left undone, will eventually become urgent, because they have due dates. The proportion of jobs that are completed while "urgent" will be affected by

A) the average rate at which jobs arrive and

B) the average rate at which they are completed.

Technically, if A is faster than B, you won't be able to keep up at all, and a steadily-increasing number of jobs will be not just urgent but overdue. And if B is faster than A, there will be no jobs left and you will have bits of spare time.

What management really wants to avoid is having workers standing idle, even in the lulls. Waste of money. So their ideal situation is to have a bit of a lineup of jobs, but too big a lineup, or too many jobs will get overdue. They have to strike a balance; the job queue not to big or too small, but about right (though they will get random rushes and lulls no matter what).

Management probably adjust the job queue length by quoting longer due dates and paying overtime (and how do they decide when to do that?). They probably also rely on you working faster during rushes and relaxing a bit during lulls; this is standard human behaviour and tends to keep the job queue at a more constant length (a balancing feedback).

Some managers also assume that warning people that the job queue is long and the jobs are urgent will make them work faster. In some cases, in the short term, this is true. In the long term, it often annoys and stresses people. If you feel stressed that half of your jobs are labelled "urgent", then priority ranking might help with that.

These are all good questions. A lot of people seem to complete management courses without figuring this stuff out. HLHJ (talk) 06:02, 28 January 2021 (UTC)[reply]

They might find out that the "urgent" jobs actually go slower, once you average in the remake time. Thanks HJL. This clarifies things. Each job is for a client so they must be remade if rejected. The problem is that when jobs are rejected they are labeled as urgent. So these remake jobs always get in front of the queue - whether they are near their completed due date or not.

festina lente problem From what you've said before, I can see that it's mainly a quality control problem which has been compounded by they way they schedule things. 118.209.1.40 (talk) 04:10, 30 January 2021 (UTC)[reply]

Hmm. If you got it wrong last time, then do it in a hurry this time, even if the due date is months away... that does seem like it might not be the best system. The critical numbers are

what percent of jobs have to be re-done after being done as "urgent"? (ignoring whether they have been done before or not)
what percent of jobs have to be re-done after being done as not-"urgent"?

(divide the percentages by 100 to get the 0-1 probability used above). It does seem like telling you why the job is urgent might be useful, too. HLHJ (talk) 05:39, 30 January 2021 (UTC)[reply]

"Starvation" is the term of the art in computer science for that kind of situation. It has lots of literature, but I am not sure any of it would help your immediate problem (of convincing higher-ups that the current priorization system is flawed). Tigraan^{Click here to contact me} 09:23, 28 January 2021 (UTC)[reply]

The problem is studied in mathematics (operations research) and computer science under the name Job shop scheduling. In many smaller job shops the scheduling is performed manually (without computer assistance), often on-the-fly, but insights from mathematical considerations may also be helpful there. The problem can be very complicated (several production lines; compound jobs being able to be split over several lines but with a possible time ordering such as that sub-job A has to be completed before sub-job B can commence; soft deadlines with varying transgression costs; et cetera). In most practical cases, there are only a few complicating aspects. (Management not understanding the needs of the people on the floor may be one, but this is not studied in operations research.) For a mathematician to be able to offer usable practical advice, they need to understand the essential aspects of the practical situation, so that they can construct an abstract model that faithfully reflects it. In the simplest situation, with one line and atomic jobs, each job has a duration and a deadline, and then the question is whether the jobs can be ordered in such a way that all deadlines are met. Deadlines (required completion times) are essentially different from pre-assigned priorities. There may or may not be a need to keep some slack for new highly urgent jobs materializing unexpectedly. Such stochastic aspects turn the problem from a yes-no problem ("Can we do it?") into an optimization problem. --Lambiam 10:50, 28 January 2021 (UTC)[reply]

Thank you Tigraan and Lambiam. I'm interested in learning more about the subject even if I'm never going to bring this up at work. 118.209.1.40 (talk) 04:10, 30 January 2021 (UTC)[reply]

Looking at the question from the other end (i.e. practical rather than mathematical), why are there so many 'rejects' that need to be remade in the first place? Are they down to you, or are you fixing other people's (or machine's) sub-standard work? Sounds like you have a quality control problem. What's going wrong that produces so many failures that take up to 30% of your time? Can anything be done to improve the failure rate? MinorProphet (talk) 05:07, 30 January 2021 (UTC)[reply]

Opiate Allergy[edit]

I’m looking for any medical information regarding allergy to opiates resulting in anaphylaxis. Studies or articles are welcome information, protocols would be ideal. Thank you. — Preceding unsigned comment added by 2601:204:D300:B790:18B7:2007:902F:9BC8 (talk) 22:27, 28 January 2021 (UTC)[reply]

I'll be honest, I'm not sure this is the best place to be asking for professional help, but a quick Google (I actually used DuckDuckGo as my search engine; pick your favorite) turned up a couple of links to articles aimed at medical practitioners. The references listed by both seem reasonable places to follow up for studies or protocols.

https://www.pharmacytimes.com/contributor/jeffrey-fudin/2018/03/opioid-allergy-pseudo-allergy-or-adverse-effect

https://www.mypcnow.org/fast-fact/opioid-allergic-reactions/

--Anon423 (talk) 10:37, 29 January 2021 (UTC)[reply]