ビジネスプロセスの「キッカケ（開始）」と「成果物（終了）」さらにはビジネスプロセスを構成する「タスク」が定義されれば、およそビジネスプロセスの概要は想定されている事と思います。
最後は、各タスクの順序や経路を決めます。

順序や経路を議論する上で、常に検討すべき事は、

1. タスク滞留の発生確率を低減する
2. タスク待ちの発生確率を低減する
3. リスクの発生を検証する

などです。ただ実際問題、ビジネスプロセスを運用する前に論理的に改善方法を検討するより、実際にビジネスプロセスを運用し実際に発生した（発生してしまった）問題に対処する経験的改善の方が有効である事は確かでしょう。
なお、あまり実現されるケースは多くありませんが、多くの課題に対して意外と有効な手法に、「並行処理化」が挙げられます。たとえば、制作チームメンバの複数人が「内部工数見積タスク」をそれぞれ独立して対処することで、それらを平均化して「より確からしい見積内部工数」を実現する事が出来ます。あるいは、一人の見積担当者が中々見積もり作業に着手できない場合でも、期限に間に合う見積があれば見積内部工数を決定でき、クリティカルな滞留を回避する事が出来ます。

ビジネスプロセスを運用すると、必ずと言って良いほど発生する問題に「放置」があります。「滞留」と同義と言っても良いかも知れませんが、「放置」はタスクを処理する意味がなくなった状態を指します。

原因は実に様々で、組織によっても傾向が異なりますが、多く見受けられるケースとして「締切問題」が挙げられます。すなわち、完了させようと思って開始したプロセスも、実際にビジネスプロセス定義に従って流れている途中で締切が迫り、定義通りには進められなくなるようなケースです。たとえば、すでに提出済みの提案書を「リーダチェック」に回す意味はありません。

この様な時間制約のあるケースにおいては、逐一プロセスを中途終了させ作業指示を行うより、想定経路として途中タスクを飛ばすルートを定義しておく事が極めて有効です。