A process is one coherent set of instructions that an OS is currently executing. Everything else pretty much follows from that.
For instance, a process resides in memory, and each one has its own state. If your computer is running four instances of Bash simultaneously (not an uncommon situation), they are all the same program, but four different processes. Each has its own program counter, its own entry in the OS's process table, and either can currently be scheduled or not scheduled independent of each other. They may or may not share the same memory segments to hold parts of their opcodes - that depends on things like static/dynamic linking.
What else is part of a process? For instance, dynamically allocated memory. Programs that allocate memory get that memory allocated to them specifically, in a dedicated data segment. Again, your four Bash processes won't share that memory, unless they perform a coordinated protocol to explicitly share some of it. Then there is the bookkeeping info that the OS keeps about a process: its number, its priority, its owning user id, the amount of cycles it has already used, etc.
Handling processes reasonably efficiently is in fact quite complicated, and a big reason why writing an O.S. is not a trivial task. But in the end, processes are just instances of programs, i.e. opcode streams, and everything else is just accounting to keep those streams flowing efficiently. (Ask again if you have more specific questions or barriers to understanding.)