Been my attitude all along.

My job is to eliminate myself. Always has been, always will be. Automate the things you can, delegate(or hand off as you say) the things you can't, in pieces if need be.

I run systems, I make em work and move on. I make systems run better and move on. I analyze tasks, piece them out, automate those pieces then move on.

The real work I do, is not so much the removal of people from these systems, but in making things run smoother, with fewer problems caused by people. Allowing those people to do other tasks, that may become automated in the future.

There are some things that will never be able to be FULLY automated, but pieces always will be. The more pieces you make automagic, the less problems you should have. Change capturing is the key to managing these pieces.

Now, as for the issue of taking 3 weeks the "old" way or 2 days the "new" way... that all depends on policy, specifically systems policy. If this new way would break 200 established automated tasks... then yes, 3 weeks would by far be the better choice. If those 200 tasks only rely on the "results" of the old way... then 2 days is the correct choice. BUT, if we can migrate all those tasks to be compatible to the new way in 3 weeks, then the new way it is.

Barry, you and I see things differently than most... I believe. We like to think what WILL be or COULD be or MAY be or SHOULD be.... not HAS TO be. Sure we understand what HAS TO be, but that is the end to the means... not using the ends to keep the means. If the work gets done in the right amount of time by the right amount of effort and the right amount of cost... does it really matter HOW? (barring legal and ethical matter that is)