All processes are a line of instructions fed to the processor through memory, which can jump to other parts of memory and manipulate parts of memory as data. That's how a simplest computer works. (check out https://en.wikipedia.org/wiki/Universal_Turing_machine and https://en.wikipedia.org/wiki/Von_Neumann_architecture for more info)
With modern computers you have processors that run in two different modes — real mode and user mode. When the computer starts, the first process can claim the real mode and in it, it sees the computer as it really is — with all the hardware it has.
That process is the OS kernel. What a Unix kernel does is it then starts a user process (the first program, usually called init on Unices), which has the illusion like it has the computer all for itself.
It's an illusion because the kernel will set up the hardware so that every now and then, the process will be forcibly and (to it) invisibly taken from the processor and the kernel will be let to do its managerial work for a short fraction of time. The memory the user process will see will not be real memory either, but fake memory which the kernel maps to real hardware memory (with some hardware help, see https://en.wikipedia.org/wiki/Memory_management_unit for more information).
The user process has no direct access to hardware but the Unix kernel presents to it a hierarchical structure for reading and writing (the filesystem) which the kernel translates to hardware manipulation (most simply to disk reads and disk writes but not just that). The kernel also presents couple of other services besides access to the filesystem. The user process can ask for all these services by contacting the kernel via a specified simple protocol (called a system call).
Two of the most fundamental services it can ask for is forking an execing. Forking asks the kernel to create another process to the image of the parent, and execing loads a new image from the file system. In this way, the initial process can start up a whole bunch of other user processes, which can then start other processes and so on.
Just like the initial process, each user child process can act as if it it was on the computer by itself, but it will be really only running on a virtual memory address space (which the kernel maps to real addresses behind the processes's back), and the kernel will forcibly take it out of the processor every once in a while so other processes could have their go at the processor too (this is called pre-emptive multitasking and the kernel has a part called the scheduler which is responsible for exactly how it's done).
Essentially, a kernel multiplexes the hardware resources (CPU, RAM, Hardrive, GPU, ...) of a computer among the user processes that have been started on it, and it does so reasonably fairly (each process gets a timeslice so that all processes can progress) and efficiently (if a process is waiting on data from a slow source (disk, network), the kernel won't waste CPU time by having it run on the CPU only to ask "is it in yet?" when the answer's logically going to be no for quite a while). All this default fairness gets adjusted with human-inputted policies. The kernel also ensures that processes can communicate with each other via various means offered by the kernel and that they get a reasonable view of the shared global state.