The dispatcher is the piece of software responsible for actually sending a process on its merry way, using information stored in the process table. It's part of the kernel, so it has privileged access to the process table and user pages. The dispatcher does not decide which process to run; it's told which process to run (by the scheduler---we discuss the scheduler later). All the dispatcher does is extract the various bits of state from the process's user page---CPU registers, stack pointer, and set up the processor with them. It then switches the processor from kernel mode to user mode (basically enabling the hardware memory protection), and the process begins to run.
This doesn't happen in UNIX, but it does in several other operating systems (including Windows and MacOS). Basically, the OS only changes to a different process when the current process says 'okay, you can swap tasks now'. Whenever a process makes a certain system call, the OS saves all the process state (stack, registers, program counter) back to its user page, then calls the dispatcher with a different process. The dispatcher starts up the new process, which runs until it makes the special system call.
Worth noting that with preemptive multitasking of this kind, processes may still volunteer to give up the processor, and not just out of the kindness of their programmers' hearts. If a process wants to wait for a certain event---and this may include implicitly waiting for some I/O operation to complete, the system call which puts the process to sleep also calls the scheduler and dispatcher so that another process may run while the first one is waiting.
It's worth noting that as a practical matter, there's always a 'do nothing' process sitting in memory, with a very low priority. This means that if there are no other tasks to run, there is always at least one process which the scheduler can pick to run.
We haven't touched on how the scheduler works, or how it chooses which process to run; we'll cover that later.