> The Fund Sighting Manual explains that, in order to suppress payment of a principal amount, “ALL of the below field[s] must be set to the wash account: FRONT[;] FUND[; and] PRINCIPAL”
and checklists:
> Raj then emailed Fratta, seeking final approval under the six-eye review process, explaining “NOTE: Principal set to Wash and Interest Notice released to Investors.”
and confirmations:
> which prompted a warning on his computer screen — referred to as a “stop sign” — stating: “Account used is Wire Account and Funds will be sent out of the bank. Do you want to continue?” But “The ‘stop sign’ did not indicate the amount that would be ‘sent out of the bank,’
To answer your question "Why were these 3 employees left to assume they were using the tool correctly, rather than referring to a definitive documented procedure that would give them the answer for sure?" My guess is that the manual is a million pages long and incredibly confusing.
My takeaway from this is that you can't train and document your way out of a core human factors issue. Your point about SQL queries is apt; that's why you don't just give humans access to prod.
Just like in Hawaii when they sent the wrong cell phone warning of an incoming NK missile attack, it could easily have been prevented if there was a dialog which said "You're sending this 'prompt' as a live alert to millions of cellphones (yes/no)".
Software always assumes people are paying attention but for serious usecases like this (which can't be undone for example, or sending hundreds of millions) there should be a sanity check dialog with real information.
The form looks like it can accomplish all sorts of things and business logic, just like a SQL query can accomplish all sorts of things and business logic in a database.
There's nothing inherently wrong with that. But like you say, the issue is with training.
The fact that 3 people who were presumably trained in how to use this tool, used it wrong, means it's absolutely a failure of training.
Business logic very often isn't "intuitive", because tools are used in all sorts of ways. When it comes to business logic, what's often most important is documented procedures and checklists.
The real question is, since this was a procedure that had been performed regularly and correctly in the past, why did it fail this particular time? Why were these 3 employees left to assume they were using the tool correctly, rather than referring to a definitive documented procedure that would give them the answer for sure?
Oftentimes it's an employee turnover/transfer/vacation issue that exposes the lack of documentation, and the real issue is too much knowledge in employee's heads that isn't committed to paper in the right places -- pure sloppiness of business procedures.