The BIOS

When you turn on a BIOS based (as opposed to firmware based) system, which is still the most common today, the first thing loaded will be the BIOS. It is like a small operating system of its own and has the purpose of configuring the system hardware and provide an environment that a more high level operating system can work with. For example it configures PCI devices, harddrive controllers, USB, the processor itself and sets up ACPI tables in main memory.
Current BIOSes are quite a bit more advanced than they were in the past, commonly having support for USB keyboards and USB mass storage to allow operating in so called legacy free configurations (i.e. without the old PS/2 input and maybe without some of the more traditional PC architecture components).
OK, not going into more detail as that's not essential here.

So when the BIOS has done its job, it will try to find a MBR on any of the harddisk-like medias or other boot method specific block on other media (El-Torito on CDs/DVDs for example). Something like a USB memory stick is regarded as being harddisk-like, because it really is emulating a SCSI harddisk to the system. When it finds a boot record, it then loads that into memory and instructs the CPU to start execution of the instructions present.

The Master Boot Record

Generally this is just the first block of any harddisk-like medium, usually 512 bytes in length. It contains boot code in the first part and the partition table at the end of the block. What you have there as boot code depends on what boot manager you have installed. You have either installed a boot manager explicitly, for example GRUB or BeOS' bootman, or it was implicitly installed for you when partitioning the device (during Windows setup for example).
Boot managers range from totally simple ones that are just enough to find the partition marked active and jump to the partition boot code of said partition, to almost complete operating systems with editing capabilities and other fancy features.

The Partition Boot Record

Additionally to the Master Boot Record, there can also be a partition boot record. It's located at the start of a partition and contains further boot code. Depending on the boot manager you are using and how you configured it, this boot code will be executed or not. In the case of Haiku the partition boot code does locate the /boot/beos/system/zbeos" file which then starts the operating system boot process.
Additionally it contains the partition offset needed to access this partition during boot. A wrong value for that offset is probably one of the most common reason why a Haiku installation doesn't start to boot.

As mentioned, whether or not the partition boot code is used depends on the boot manager and boot manager configuration. If you take GRUB installed as boot manager in the MBR and booting Linux. GRUB knows how to handle most Linux filesystems and it does know how to load and start a Linux kernel off of it. Therefore it can directly load Linux without the need for any additional boot code.
However GRUB does neither know how to handle BFS and find the zbeos boot loader, nor would it really know how to execute it. Therefore you cannot use GRUB to directly boot Haiku.
Instead you need to chainload the partition boot code of the BFS partition, as it knows how to handle both the BFS and zbeos.

The Boot Loader

After the boot loader (zbeos in case of BeOS/Haiku) has been found and loaded into memory, it is executed. The boot loader is the one providing you with the Haiku boot menu when pressing the space bar in early boot and is the one detecting basic system configuration. It also contains the logic to find and load the kernel (kernel_intel on BeOS and kernel_x86 on Haiku) as well as some boot modules required. Boot modules include the bus managers, bus and device drivers required by the kernel to successfully access the boot volume to load the rest of the modules and execute anything it needs to fully boot the system.
If you boot to an ATA harddisk it would require for example the IDE or ATA bus manager, the harddisk controller driver and the helper modules used by them. Booting from USB would require the USB bus manager, the host controller drivers and the usb_disk driver for example. The boot loader also provides the kernel with configuration information and info about initial memory layout for example. This data passing between the boot loader and the kernel is specific to Haiku and the Haiku revision, it is possible that the information passed changes from one revision to another. This also makes it obvious that a zbeos from a BeOS installation cannot work with a Haiku kernel. Likewise using a BeOS bootfloppy that provides such a zbeos is not going to boot Haiku.

The Kernel

Once the kernel is loaded and starts executing it sets up a working environment. Memory management, bootstrapping and configuring non-boot CPUs, timers, interrupts, filesystems, module infrastructure, drivers... Everything that is needed for a fully working system and has not yet been loaded. Once this environment is set up, the kernel will start the bootscript, that then launches the different servers to provide a usable userland.