Leah, you are getting a little off topic with your comments about the NWA crash in Detroit. The bottom line is the NTSB ruled the crash was a result of human pilot error and a back up warning system did not function due to an unknown electrical problem. The speculation is the pilots may have disconnected the fuse for the backup system but this is pure speculation but it was still a backup when humans (not computers) failed which they did in this case.
The NTSB probable cause statement is as follows: "The National Transportation Safety Board determines that the probable cause of the accident was the flightcrew's failure to use the taxi checklist to ensure the flaps and slats were extended for takeoff. Contributing to the accident was the absence of electrical power to the airplane takeoff warning system which thus did not warn the flightcrew that the airplane was not configured properly for takeoff. The reason for the absence of electrical power could not be determined." The cockpit voice recorder (CVR) provided the evidence regarding the flightcrew omission of the taxi checklist. The stall warning was annunciated. Using the CVR the investigators determined that the aural takeoff warning was not annunciated. The NTSB was unable to determine why there was an electrical power failure to the Central Aural Warning System (CAWS). http://en.wikipedia.org/wiki/Northwest_Airlines_Flight_255 David Frenkel ________________________________ From: Leah Halpin <[email protected]> To: Michael Mattias/LS <[email protected]>; [email protected] Sent: Fri, October 22, 2010 10:54:17 AM Subject: Re: [EDI-L] SAP Alerts for forecasting / scheduling agreements My Dear Mr. Mattias, snip <If "no schedule received" is a critical thing for Mr. Garwick's firm, I have to suggest it would be "less than optimal" to rely on "some person" remembering to check> snip Ah, but that is their job. There are a number of problems with automated "alerts" Problem one: "alerts" make people lazy Problem two "alerts" go to a person - does not solve the "out, on vacation, quit, etc." Problem three a computer can't tell that you're not going to get data this week because the plant shut/slowed down unexpectedly, the TP had computer issues of their own, the buyer decided they'd over ordered and now instead of adjusting the forecast, they're just going to use up what they've got and not send one at all this week, there's a production delay for some reason and so a particular part is not needed. Ah, you say, but how does the user know this? You'd be surprised, buyers communicate the "old fashioned" way, fax, telephone, email, they, after all, are people, too. Problem four real "alerts" get ignored along with the numerous false ones, the users dump them all, route them elsewhere or just ignore them Problem five computers do crash, upgrades happen and things l(ike alerts) get missed, changes are made which can interfere with "alerts" (among other things) then your "dependent" user never knows he's missing anything and life goes on until you shut your customer down and then, pink slip for all of you. Problem four (and, to some extent one and two) resulted in the crash of a NW flight killing all on board except one small child. Give me a person any day. Use the right tool for the right job. I'm not saying it can't be done, I'm just saying it shouldn't. Leah ________________________________ From: Michael Mattias/LS <[email protected]> To: [email protected] Sent: Fri, October 22, 2010 11:17:08 AM Subject: Re: [EDI-L] SAP Alerts for forecasting / scheduling agreements >Well, my answer was meant to be somewhat funny, but your observation is >correct, >things that "don't" happen are harder for COMPUTERS to deal with. However, >in >my many years of experience with SAP and EDI in the manufacturing vertical, >I >have found that users are acutely aware of when they're "supposed" to get >their >data and of any reasons why they may not, resulting in a near zero false >reporting and near 100% accurate recognition of problems they can't even >see in >SAP or elsewhere. >There is no true substitute for human cognition. True enough; but it's also true that computers aren't out today because they are taking a vacation/presonal day because their child is ill; had a bad night and are not quite as sharp today; or got commandeered for some other 'important special project.' If "no schedule received" is a critical thing for Mr. Garwick's firm, I have to suggest it would be "less than optimal" to rely on "some person" remembering to check, especially when I can set an alarm clock to remind him or her - or someone. See also: Link, weakest, relation to strength of chain as a whole. Michael C. Mattias Tal Systems Inc. Racine WI [email protected] [Non-text portions of this message have been removed] [Non-text portions of this message have been removed] ------------------------------------ ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix.Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/EDI-L/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
