in reply to Rostering Staff: Architecture? Not strictly Perl

It seems to me that the aim of the app is more to help the manager assign the shifts than it is to store them. After all historical copies can be dealt with by printing out the week's roster and the future is not likely to be more than four weeks.

I would sit down and ask myself what information would be needed to decide who goes when: for example has Frank worked more than 30 hours in the last week? When was Jane's last shift? Does Bob do mornings?

It will probably also be helpful to create a big overview screen that shows all the shifts currently assigned, and where staff are needed.

Interesting problem. I think once you have the problem nailed the storage method will suggest itself...

--tidiness is the memory loss of environmental mnemonics

Replies are listed 'Best First'.
Re: Re: Rostering Staff: Architecture? Not strictly Perl
by castaway (Parson) on Dec 05, 2003 at 14:45 UTC
    (Edit: Oops, misread the previous post, thought it said 'automatically' in there somewhere, on second reading, it doesnt, anyway, argument against that still stands).

    That's not what it looked like to me. If it is, then Im also interested in the result, since I spent an hour or three recently looking for a similar app, to fit some specific requirements, I found a few Windows ones that came close (best: http://www.schedulerlite.com), but nothing that was exact enough, or could be changed to do it. There were a couple of OS apps on freshmeat etc, but nothing remotely useful (for what I needed anyway, no offense meant..)

    While pondering doing it myself, I decided that automatically assigning, while possible, isn't really very practical. You'd need very exact details of who can, when, and for how long. These are bound to change last-minute, someone gets sick, etc. Which would require either a complete recalc, meaning everyones schedules get changed at the last minute (they're going to love that), or that someone sit down and manually shuffle to minimise the knock-on effect. (I'm not going to suppose that you have people sitting around idle that you can swap-in, no business sense in that).

    In short the best way to do it seems to me, to have someone manually assign the shifts, and have the interface just be *really* helpful, ie add up hours/week on the fly, check constraints on the fly, be able to track vacations/stand-ins, when people like to work, drag+drop names to shifts.. and and and.. Manual assignment also has the advantage of the assigner actually knowing vaguely who is going to be when/where.

    SchedulerLite seems nearly perfect, its just missing that 'show total hours/week on the fly' thing, and a couple of other bits. After fiddling around with it a while, I might attempt coding one myself (in perl of course ,) (BTW it also has all the SQL/tables right there, so the OP might grab some ideas from it..)

    C.

[reply]
      You've all come up with fascinating questions and answers. Thanks a lot.

      I should clarify that the system was never required to do leave, resolve conflicts, remember staff preferences etc, just work as a kind of content-management system for one page, the "who's working when?" page. As Abigail said, just a dumb front end to a database.

      Questions like this are becoming more interesting to me now, I note, whereas before I would have just started writing something right away, I'm now much more concerned with the structure before I start on the code. 


      ($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
 =~y~b-v~a-z~s;                             print

      [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom