Maybe a year ago I realized something about the systems that I work on. It has to do with the status of a Work Order. We have a status, "complete", which is used for when we make something. We have a status, "cancelled", which is used for something that we started but didn't finish. I assumed that when we cancelled a Work Order that it was set in the "cancelled" status.
This is, of course, my workplace, and so that is not the case. When the users cancel a Work Order they zero out all the made quanitites and set the status to "completed". It's almost logical -- except for the part where as far as the computer is concerned, there isn't any real difference between a Work Order that was cancelled and one that was completed. Both are marked with the status "completed". Sure, if a human looked at the record they could probably guess from all the quantities being set to zero that nothing was made and that the Work Order was probably cancelled. Asking computers to make such fine differentiations is possible, but can lead to very time consuming queries and is in general not very wise. The best route is to just mark completed Work Orders completed and cancelled Work Orders cancelled and never the twain shall meet, tra la, tra la.
Being a good, proactive employee, as soon as I spotted this little system problem I pointed it out and immediately proposed the solution: a "Cancel Work Order" screen which would leave all the data entered to that point in tact, but which would set the status to "cancelled". Along with this we would need to sit down and to the analysis to hunt down all the supposedly cancelled Work Orders that were actually marked "completed" and change their status to "cancelled".
I thought this sounded straightforward. The status field is not something any of the users can view, and it doesn't appear on any reports. It's for internal use only. An auditor coming in wouldn't be able to tell that the field was changed. (Unless, of course, we did the correct thing and provided full and complete documentation including before and after snapshots of every order changed.) The status field is not one that contains any FDA-regulated information, so it would not be violating anything. Heck, any theoretical auditor looking at this would probably appreciate having cancelled orders marked "cancelled" rather than "completed" anyway. It's less confusing that way.
My user group didn't agree. The Chihuahua On A Stick was open to the idea of changing how we do things in the future, but refused to let me fix the status for past orders. I saw no point in changing their processes if they wouldn't let me completely fix the data. If I couldn't always count on "completed" orders really being completed and "cancelled" orders always being marked "cancelled" then from a technical standpoint I wasn't getting a lot of value out of the change anyway. The entire matter was dropped.
Fast forward to today. We had a problem where the same lot was used on two different Work Orders. (This is pretty normal.) On the first order processed, the expiration date was entered wrong. (This is not as uncommon as one would hope.) As a side result, when the lot was run on the second order, it picked up the expiration date for the first order.
(The systems will do this sometimes, as the original developers 1) assumed that the expiration date for a given lot must always be the same for every piece of that lot, no matter what order it is processed on, and 2) that the users would never input data incorrectly. The first assumption -- though incorrect in practice, as bizzare as that thought might be -- was logical enough. The second one... well, they were young and new to programming. I sure hope they've learned better by now. 'Cause if they haven't, it says poor things about the level of their intellegence.)
So, problem solved in my mind. The Chihuahua On A Stick, understandably, wondered what we could do to make the computer not pick up an expiration date from a cancelled order. After all, cancelled orders are cancelled for a reason, right?
I cheerfully pitched my old idea of making a screen so that users could cancel Work Orders in a way that is really cancelled and not just "completed" masquarading as "cancelled", and added that as part of that we MUST go back and change all the previously cancelled Work Orders that are marked (incorrectly) as "completed".
"Oh, absolutely," the Chihuahua On A Stick replied firmly.
I appreciate all the experience I've had in support and customer-oriented positions. It gives me the tools necessary to respond calmly to statements like that, rather than jumping up and shaking the user the way my reptilian brain says I should.
At any rate, my triumph over the illogic of leaving a known data problem alone is very short-lived. I certainly won't be here to enjoy having cancelled orders actually being marked "cancelled". And for whatever reason, the Chihuahua On A Stick has decided that even if she submits a Change Request no one will allocate programming resources to handle it. (She may be right, though the departmental line is that everything is "business as usual".) Winning is good. Winning when you actually can enjoy the rewards is better.