4 ms·

>>I do hope this person's job was replaced by computer years ago. It was not (source: family & friends did that job at several Home Depots recently:) It takes

>>I do hope this person's job was replaced by computer years ago. It was not (source: family & friends did that job at several Home Depots recently:) It takes about 16 - 24 hours of work on a weekly basis to manually update schedule after it has been automatically generated based on policies, requirements, and all known constraints. Reasons, if you care - I got to hear about them weekly: 1. Department Supervisors are supposed to manage the schedules for their teams, but they did not at most stores, for various reasons from lack of training to lack of will/bother. So the job effectively gets "internally and unofficially outsourced" from a dozen leaders who know their teams, to a single HR / schedule person who now has 150-200 people they know less well (and other work to do as well). This was NOT well understood by corporate/HQ, so entire process is based on flawed assumptions from the get-go. 2. As part of that, nobody's preferences and working hours are correctly in the system. Again, should've been entered upon hire and maintained by DS, instead a single person needs to figure out and manage for 150-200 people. 3. As part of that, people made changes all the time - wedding, funeral, birth, movie, party, picnic, vacation, illness, whatever. Should: Be entered directly in the system by the DS. Actually: people leave voicemail, post it notes, yell in passing, or try to telepathically message, yes, the single person who's job it is strictly speaking not to maintain such information. 4. Software isn't great; training and documentation are worse; processes are not reflective of reality; and nobody does what they're supposed to do, from associates to DSs to ASMs. People TRY their best, mind you. But people are people, so see next point: 5. Basically, the problem there, as I see it: just like economists assume perfectly rational economic actors and physicists assume frictioneless spheres, programmers assume "well defined requirements understood by all and a process that is documented and accurately followed" when they say "this can definitely be easily automated" :->. Don't even get me STARTED on bright eager university graduates who come to companies to do robotic process automation of business processes in a quick agile way with fast ROI.... and the even quicker and painful lesson in real life they soon obtain :O This is NOT to say I don't feel your pain - I very much do! Not sure if a little bit of background will help or make it worse :-/

deleted 3y ago
[deleted]
Buttons840 3y ago
Why is the generated schedule so bad that it requires a couple dozen hours to fix? Does the schedule produced fail to meet the defined constraints? Or is it because some of the constraints have not been entered into the computer? Scheduling is NP complete, but the problems are small enough that I think computers can trivially find near optimal solutions, given some scoring function, better than a human can. Why doesn't this happen? Is defining the scoring function too hard? Am I wrong about computer's solving abilities? Language models have proven themselves reliable with natural speech and highly technical speech (like code), they could help make entering the constraints more approachable. Also, as my example demonstrates, if such a system fails occasionally, it's not worse than the status quo.
- NikolaNovak 3y ago
  I tried to provide detailed, bullet-point answers to that question, in the initial post, and the general comment on difficulty of automating seemingly discrete and simple business processes. I don't have much additional information, but perhaps to summarize: * Initial iteration of system is (by definition) imperfect * People who are supposed to maintain constraints and parameters, don't * Person who typically does end up maintaining the system is not aware of all constraints and parameters, and doesn't have power or channel to change system * Process for noting and updating constraints is poorly communicated and not enforced * Through entropy, system, which was not perfect in the first place, gets worse over time, which feedback loops because people keep overriding it and updating it less and less. My friends'/family experience has been that when a new HR Manager joins a store, they tend to "clean up" everything as much as they can; but then entropy sinks in again - people don't update constraints and requirements, system deteriorates, and provides more reason/excuses for people to not use it properly. ------------ On aside, in my own daily life, I've been working on ERP systems all my life, and as a techie it's a fascinating place to be. I assumed that numbers are numbers, business processes are well structured, defined and documented, and that people who's job it is to use a specific system will be at least somewhat proficient in that system. None of those things are necessarily broadly true :). On aside-aside, similar thing can be observed in MS Project btw. MS Project has an incredibly powerful scheduling engine. It's amazing! But! 99% of MS Project users don't know how to use MS Project. They try to use it as Excel. They type in some tasks, the dates aren't what they want them to be, then they override automatic scheduling by putting manual dates rather than putting constraints into the system... and the negative feedback loop commences. I've rarely seen a MS Project Plan file which properly uses the scheduling engine :-/

deleted 3y ago

[deleted]

Buttons840 3y ago

Why is the generated schedule so bad that it requires a couple dozen hours to fix? Does the schedule produced fail to meet the defined constraints? Or is it because some of the constraints have not been entered into the computer? Scheduling is NP complete, but the problems are small enough that I think computers can trivially find near optimal solutions, given some scoring function, better than a human can. Why doesn't this happen? Is defining the scoring function too hard? Am I wrong about computer's solving abilities? Language models have proven themselves reliable with natural speech and highly technical speech (like code), they could help make entering the constraints more approachable. Also, as my example demonstrates, if such a system fails occasionally, it's not worse than the status quo.

NikolaNovak 3y ago
I tried to provide detailed, bullet-point answers to that question, in the initial post, and the general comment on difficulty of automating seemingly discrete and simple business processes. I don't have much additional information, but perhaps to summarize: * Initial iteration of system is (by definition) imperfect * People who are supposed to maintain constraints and parameters, don't * Person who typically does end up maintaining the system is not aware of all constraints and parameters, and doesn't have power or channel to change system * Process for noting and updating constraints is poorly communicated and not enforced * Through entropy, system, which was not perfect in the first place, gets worse over time, which feedback loops because people keep overriding it and updating it less and less. My friends'/family experience has been that when a new HR Manager joins a store, they tend to "clean up" everything as much as they can; but then entropy sinks in again - people don't update constraints and requirements, system deteriorates, and provides more reason/excuses for people to not use it properly. ------------ On aside, in my own daily life, I've been working on ERP systems all my life, and as a techie it's a fascinating place to be. I assumed that numbers are numbers, business processes are well structured, defined and documented, and that people who's job it is to use a specific system will be at least somewhat proficient in that system. None of those things are necessarily broadly true :). On aside-aside, similar thing can be observed in MS Project btw. MS Project has an incredibly powerful scheduling engine. It's amazing! But! 99% of MS Project users don't know how to use MS Project. They try to use it as Excel. They type in some tasks, the dates aren't what they want them to be, then they override automatic scheduling by putting manual dates rather than putting constraints into the system... and the negative feedback loop commences. I've rarely seen a MS Project Plan file which properly uses the scheduling engine :-/