OK, dear readers, are we ready for another TWO examples of sub-optimal information systems design?

Example 1. I cannot order printed cheques for a new account from a third-party vendor, because I have never ordered cheques before.

BMO cannot give me a sample cheque nor an authorized MICR encoding sample. This is absurd. The default method supported by the Online Banking  is to order through Davis+Henderson, who charges about twice as much as other vendors. Somehow the MICR encoding or specification is communicated between BMO and D+H, but the Customer Service doesn’t have it and can’t get it.

This is a perfect example of how a series of reasonable decisions can result in a ridiculous situation. This often happens in information systems design, especially when it’s bound up in business processes. It’s not unreasonable for a bank to contract out cheque printing. It’s not unreasonable for a bank to not give out starter cheques, because many people can get by without paper cheques and it’s not practical to yoke new account creation to having pre-printer starter cheques in the branch. It’s also not unreasonable for a bank to stop producing counter cheques, because some customers take advantage of this service and it’s an undesirable work-around for other policies. However, it *is* unreasonable for a bank to force me to purchase cheques only from the vendor of their choice. It would not be difficult to set up Online Banking with an area where I could download a PDF of the MICR encoding of my account information.

Example 2. I cannot change my bank plan on the first or second of the month, because accounts are charged for bank plans on these days and so changes are forbidden. A bank plan is like a prepaid bundle of services for a set of accounts. BMO offers plans with varying features, such as the minimum balance, number of ATM withdrawals per month, number of bill payments per month, etc, and corresponding fees.

I can come up with a plausible reason for why the bank would make a rule like “no plan changes on the first or second of the month.” They want a stable set of accounts and plans for a large scale debit that can take many hours. But this is poor system and process design. Why is it necessary to process all of these on the same day? Why not distribute them over the month, as is the case with credit card statement and due dates? Alternatively, if you insist on charging the accounts on the same day, then you need to design an information system that can handle changes on the 1st and 2nd of the month.

I don’t mean to vilify Bank of Montreal here, as they are not especially bad. On the other hand, perhaps I should give them a good roast, because banks are a commodity product in Canada. If they are competing on price, then it’s a race to the bottom. Consequently, it’s not a good result for the bottom line or for the customers. The alterative is to compete on service, which banks are doing more and more. Information systems are key to improving customer service and reducing code. Consequently, they need to get rid of absurdities such as the two that I have described here.

Now, it’s your turn. Do you have any examples of ridiculous situations? Or times that you’ve been told that a reasonable request could not be fulfilled because there was no way to enter it into the computer?