Whether it's "worth it" is a business decision that may involve more than just the number of person-hours spent and saved.
Obviously you want to look how many hours you're going to spend developing the system versus how many hours it saves per week to get an idea of how long it will take to pay for itself in that narrow sense. But there are plenty of other things for which it's not as easy to assign a value (especially a specific number) that may be considered benefits from a project.
For example, it may be surfacing (more clearly exposing) problems within parts of your system or organization that are affecting other projects as well, or would affect future projects. These could be that there's no good mechanism for handling authentication of automated tools to the DBMS, there's no place to store temporary or semi-permanent data that offers appropriate sharing between various systems, details (or even existence) of the "band-aids" in the "band-aid systems" you describe, or even just that certain people are designing or running their systems in a way that makes automation harder.
Another goal might be to gain experience with particular technologies that are going to be or are being considered for use in future projects. This may let you later do more accurate estimation in a project where accurate estimation is important (such as for an external client) while learning in an environment where missed "deadlines" are not such a big deal. Or it might lead you to use different technologies for a future project because you've found out that the technologies you tried don't work as well as you had hoped.
What you should do is avoid telling your manager whether the project is "worth it" or not, and simply put together the data you have now and present it to him. If you're running into problems, explain the problems and how that will affect the schedule, or how you are finding it difficult to tell how that will affect the schedule. (The description of those problems may be exactly what he's looking for from the project!) Of course, if you had previously given him estimates of how much time would be saved and when the project would start paying itself off, you should give him whatever refined estimates you have for that as well.
You can also propose any changes, such as reducing project scope, that you feel might make the project more "worth it." But keep in mind, you don't necessarily know everything about what's making the project "worth it."