Question for you, how did IT sell this to the business folks (or the buyer)? Was this under the auspices of enterprise agility?
Exactly. If a customer called in an order at 6:30 a.m., it didn't even get to the data base for 18 hours. So there was no same day shipping and if it had to be scheduled, the schedulers weren't even aware of it until the next day. Real competitive disadvantage. Worth spending millions to solve.
Real time Accounts Receivables paid for itself by reducing Days Sales Outstanding by one day. But real time Accounts Payable? Made no sense.
The IT solution was a blanket decision made multiple levels (and cities) away from the people who actually did the work. Go figure.
Its pretty inane, as you point out, how companies blindly apply strategies. Alot of times this is caused by simply cutting corners. If they would have had a body write up requirements (even high-level) for each department the would have caught this.
Were there any problems with the actual implementation? If there are these kind of problems at the architecture level, I can only imagine the issues that came up actually initiating and executing the program.
Our project was to migrate all apps to a new real time package. They spent millions of dollars and when it was all done, the controller complained, "Who decided that we needed real time Accounts Payable? Why would we ever want to pay our bills faster?"
No one had ever asked that question before. No one even thought about it. We had spent $1 million on a module nobody wanted because IT decided it. Eventually he added procedures to continue to fill out all accounts payable transactions with pencil and paper and enter them into the on-line system at the end of the day. What a waste.
Same argument here. Some things you want faster. And you're willing to pay for them, one way or the other. But other things should just stay the way the are.
Some things never change: you actually have to think about your apps before you implement them.