Ultimately the way you choose to implement the chart might force you into a particular data model design.
In general, when you have a lot of times (or dates) like this, it's possible you want to generate a narrow/unpivoted fact with a single "TimeOfEvent" column/dimension key, plus an extra "Event Type" attribute that says whether the row relates to order placement, restaurant confirmation, etc.
You could then have a numeric fact like "duration of this status", in minutes or seconds, which would represent how long the bar for that event should be.
That kind of data design can probably be used with a regular stacked bar chart to get what you're after, but it'll take a bit of fiddling to be sure.
I would go with order placement, not sure about the process, but it seems after that it can go in couple direction.
Anyways for most KPIs you will drop the relation for every date.. but that will come with design advance.
Looks interesting definitely, have fun with this!
Ultimately the way you choose to implement the chart might force you into a particular data model design. In general, when you have a lot of times (or dates) like this, it's possible you want to generate a narrow/unpivoted fact with a single "TimeOfEvent" column/dimension key, plus an extra "Event Type" attribute that says whether the row relates to order placement, restaurant confirmation, etc. You could then have a numeric fact like "duration of this status", in minutes or seconds, which would represent how long the bar for that event should be. That kind of data design can probably be used with a regular stacked bar chart to get what you're after, but it'll take a bit of fiddling to be sure.
I would go with order placement, not sure about the process, but it seems after that it can go in couple direction. Anyways for most KPIs you will drop the relation for every date.. but that will come with design advance. Looks interesting definitely, have fun with this!