Around 1999, the CS department of the University of Manchester developed a software solution to assist the ambulance dispatching service of Manchester. Until then, they were working with pen and paper.
Attempts to do the same thing in London had failed, partly because they were overambitious—they had tried to make the software decide which ambulance to dispatch each time. In Manchester, they did great; but the only thing they did was provide human dispatchers with better information to help them make the decision. (Today, making the software decide, or at least propose, which ambulance to dispatch may be feasible; but at that time, probability modelling hadn’t advanced so much.)
This strategic decision about supporting a human vs. replacing him certainly played an important role, and so did the quality of the software and the work. One additional factor in the success of the project, which is the main reason I’m writing this, is that they reviewed and re-examined the entire process of ambulance dispatching, and changed the way in which the four members of the dispatching team were seated in the room.
Implementing an IT project requires you to modify your company’s processes. Sometimes simple changes such as how someone is seated may be required. Other times, changes in the structure of the company may be required. If you rush to adopt some automation without thinking about the repercussions first, you are headed towards a nasty disruption. Technology is not a solution in and of itself.