You first need to start by understanding the existing manual processes. Identify what the inputs and outputs are, how the process starts, what activities it includes to transform the inputs into the outputs, in what sequence do those activities occur, what are the actors involved in those activities, what are their roles, etc.
Then, think about where you will add the automation. Will you be automating the entire process or just parts of it? For example, you mentioned that "We want to automate moving data from one excel workbook to another". This seems like part of a process to me. Is that it or is there more? Find out!
You first need to understand the "what" so that you can then figure out the "how" and the "where".
This activity is basically requirements gathering (that you can do in various ways). You can end up with a Software Requirements Specification Document, but the point of it is to understand what you need to build. Once you do, you can then plan out your work, which I would suggest you do incrementally and not all at once.
The problem with manual processes is that, unless there is a strict documented standard to follow (in which case you already have your Requirements Specification), a lot of things can live in people's heads and managed through their experience, things that are so ingrained in people's work that it doesn't even occur to them that it's important to mention explicitly. So figure out what you need to build and automate some of it. Then get feedback. Automate some more. Get feedback. That way you make sure you build the complete solution (that maybe you might not have captured fully when doing the requirements gathering).
Another thing to be aware of is that people may ask for "extras". That thing that's not in the manual process that they always wanted to do but was labor intensive, maybe you could build it also, right? So be sure to first automate the existing manual process and then enhance it, otherwise the goal of the automation might become fuzzy or too generic with time.