ワークフローサンプル

「営業マンが提出する提案書品質が上がらない…」　そんな悩みを持つセールスマネージャは少なくない。さて、ヒトが悪いのか？、業務プロセスが悪いのか？

単純な話、『過去のベスト提案書』をブラッシュアップし続ければ、確実に『ベスト提案書』ができあがる。セールスチーム全体で「提案書作成業務フロー」を遵守して作成すれば、相互助言が実現できるだけでなく、成果物としての提案書が様々なコメント付きでデータベース化される。（再利用性向上＝組織力）

ソフトウェアや情報システムの開発では「テスト工程」がつきもの。「要件と一致しているか」を確認するだけでなく、その確認行為を記録しておくことが大切だ。

機械テストを多用する事になるのだが、最後は人間によってレポートされる必要がある。以下の例は、一つの「テスト仕様書」に対して、二人のテスタが「テスト報告書」を完成させる業務フローだ。

請求書発行の遅延やモレを防止すべく、経理部門がToDoタスクを追加しておくワークフローは昨日紹介した。（『請求書発行フローは、部署横断に助け合うべきワークフロー』）
このワークフロー例は「人間系タスク」の集合としての「請求書発行プロセス」になっている。

システム連携による「機械的な業務処理」を目指す事で、更に請求書発行の遅延やモレを防ぐ事ができる。すなわち『0.請求書発行指示』を「自動化」する事を考えたい。

請求書の「発行遅延」は、かなりイケてない。
請求書の「発行モレ」は、究極にイケてない。
組織にあわせた請求書発行プロセスを模索し続け、「遅延」や「モレ」を撲滅したい。

そもそも「請求書発行プロセス」は、どの部署から開始されるべきか、会社によって異なる。すなわち『顧客に対峙しているセールス部門』、『完成納入を把握している業務部門（製造部門）』、『受注を把握している経理部門』のいずれも考えられる。以下の例は、業務部門（製造部門）自身が（完成納入後に）請求書発行を開始するワークフローサンプルだ。

どれだけ周到な準備やテストをしていても、Webサイトを新規公開する瞬間は緊張が走る。
現実問題として「テスト運用環境」と「本番運用環境」を100％完全に同じ条件にする事は不可能であり、公開してみて初めて発覚する『不具合』もある。
大切なことは『不具合』の発生時に、着手優先順位を付け、しかるべき手順で、冷静に対応する事だ。

受託事業において『検収報告書の獲得』は最優先事項だ。Webサイト制作にせよ、システム制作にせよ、『検収報告書』をもらう為に頑張ると言っても過言ではない。

プロジェクト全体では、『企業間プロジェクトにおける仕様書確定プロセス』で紹介したように、最終的に『検収完了』のステータスに持っていく必要がある。しかし多くのケースで、すんなり『検収完了』になる事はない。
すなわち納品物に対して「修正要望」が出てくる。それが２〜３箇所なのか、10箇所なのか、50箇所なのか…。いずれにせよ一つ一つの「修正要望」をキッチリと把握し、消し込んでいく必要がある。

ワークフローは『企業内に閉じたもの』と思いがち。ただ、「頻繁に発生する定型の業務」は企業内に限った事ではない。

例えば「仕様書」の『企業間やり取り』をメールで行うと、やり取りしている当事者同士ですら、結局どれが「最終的に確定した仕様書」なのか分からなくなる。このようなケースでは、『企業間やり取り』を可視化し、その進捗を委託側・受託側それぞれの多数関係者がいつでも確認できる様にしたい。
（そもそもメールやり取りは、会社記録に残らない可能性があるので避けたい）

以下の業務フローは、両社権限者の仕様書策定活動（と仕様書修正活動）をオープンに進捗させるためのフレームと言える。
（「SaaSワークフロー」であればプロジェクト期間中だけの利用も出来て便利）