第2回「業務フローが無いと何が困るのか(1)」
第1回目のブログでは、物流現場に業務フローがない背景について記述しましたが、2回目の今回と次回のブログでは、「業務フローが無いと何が困るのか」という点について記述していきたいと思います。
・・・ある物流システム導入プロジェクト：要件定義前の会話・・・
私＝私（システムベンダー） ク＝クライアント様
ク：納品物として新システム導入後の業務の流れがイメージできるドキュメントが必要です。
私：システムの機能や画面遷移を記述した「システム機能フロー」は要件定義中に整理していくつもりです。
ク：それは業務フローですか？
私：業務の流れをシステム中心に記述したものですので、業務フローとは似て非なるものです。
プロジェクトの成果物について
どのようなプロジェクトにしても、プロジェクトで作成する成果物をどのようなドキュメントとし、誰がどのプロジェクト工程で作成するのかという点が、プロジェクト開始前に決めておくべきポイントとなります。
私が多く携わってきた倉庫管理システムの要件定義及び設計フェーズで作成することになっていた成果物には以下のものが含まれています。
①システム機能フロー：
システム機能を業務の流れに沿って記述したもの②システム基本設計書（スクラッチ開発の場合）：
開発対象のシステム機能の概要を記述した設計書③カスタマイズ設計書（パッケージの場合）：
標準では備わっていない機能の概要を記述した設計書
これらのドキュメントは、基本的にはシステム開発を受諾したシステムベンダー側が作成します。
私がこれまで携わってきた多くのプロジェクトはパッケージを中心とし、スクラッチ開発によってパッケージシステム周辺に限定的な機能を有したシステムを補完していくというものでした。
そのため、プロジェクト内で作成するドキュメントは、パッケージベンダー固有のフォーマットによるドキュメント（主にシステム機能フローとカスタマイズ設計書）とシステム開発ベンダーが一般的に作成するドキュメント（システム基本設計書）の両方がありました。
ここでポイントとなるのは、「システム機能フロー」の位置づけとその中身についてです。
「システム機能フロー」に対する認識の差が発生
～クライアントとシステムベンダーの認識の違いとは～
前出のクライアントとのやり取りの中で、「システム機能フロー」について説明しているセリフがありますが、このドキュメントに対するシステムベンダーの認識とクライアントの認識にかい離があるということが頻繁に起こります。
システムベンダーは、プロジェクトが対象とする業務を一定レベルで理解しています（そもそも理解していることが受注の条件となるため）が、同業務を実務としてこなしているクライアントと比べると、詳細レベルまでは理解できていないことが一般的です。
また、システムベンダーはシステム側の目線で業務を見るため、どうしても実業務についての理解度や実務感覚という点で、クライアントと比較すると低いものになってしまいます。
これらの結果、システムベンダーが記述する「システム機能フロー」はその名のとおり、「システム」が対象とする業務に対して提供する「機能」を業務の「流れ（フロー）」に沿って記述したものになります。
クライアントのニーズは「システム以外の範囲」も含まれている
一方のクライアント側にとってシステム開発の対象業務は業務そのもののため、システムが対象とする業務とシステム対象外の業務も包括的に記述した、新システム導入後の「業務プロセスフロー」を必要としています。
つまり、システムの機能を中心としたドキュメントではなく、「業務」を中心としたドキュメントを必要としています。
システムベンダーの認識は「システム機能を中心」としたもの
つまり、システムベンダーは、システム開発のプロとして、システム機能を中心としたドキュメントを作成しますが、必ずしも対象業務の業務の専門家ではないため、業務を中心としたドキュメントの作成には役不足といった面があります。
私自身10年以上物流センターへのパッケージ導入やシステム開発に携わっており、倉庫業務運営を支援する仕事もしてきましたが、やはり業務プロセスを書くときの目線はシステム中心となってしまい、業務の専門家から見ると抜け漏れだらけだったりするようです。
私の経験上、上記のようなギャップに対してクライアントと共に具体的な対策を打つことなく進めてしまったプロジェクトで、その後直面することになった課題は以下のようなものでした。
「実業務・実運用のイメージが持てない」というクライアントの不満
システムベンダーがリード役で推進するシステム要件定義工程は、どうしてもシステム寄りの協議となってしまい、クライアントの業務部門から参画される担当者にとっては、業務イメージを持ち辛いといった意見を私もこれまで良く耳にしました。
システム要件定義工程が始まる時点で、既存の業務フローが無いということに強い問題意識を持つようになった以降は、システムベンダーとして可能な限り業務の流れに沿ってシステム機能を記述したドキュメントを作成することにより、クライアント側がよりイメージを持ちやすいように工夫をするような取り組み方をするようになりました。
問題意識を持つ以前はシステムベンダーとしては、あまり適切な対策は打てず、クライアント側の曖昧な理解のままシステム要件を固めていくような進め方をしてしまったプロジェクトもあり、今となっては反省しきりです。
このような進め方をしてしまった場合は、当然ながら後工程において、「そんなはずじゃなかった」、「そういう理解はしていなかった」等の問題が浮上し、仕様変更が相次ぐといった事態が頻発し、予算面やスケジュール面への影響が出る結果となることが多くありました。
業務プロセスフローがないとテストシナリオを作れない
開発されたシステムは、要件定義及び設計工程で合意されたシステム仕様に沿ってシステムベンダーが開発を行い、その結果をシステム観点でテストした後にクライアントに納品されます。
これに対して、業務要件通りにシステムが出来ているかを検証する受入テスト、更には業務運用観点で検証する運用テストが行われますが、こちらはクライアント側の役割となります。
これらのテストを行うに当たっては、テストシナリオが予め必要になりますが、新システム導入後の業務プロセスフローが無い限り、テストシナリオを作る元がないという状況となります。
解決策のひとつは「業務プロセスフロー」
私の経験上、取り組み方法を変え、システム機能フローを準備・提供するようにした以降のプロジェクトでは、同書を元に受入テストのシナリオはクライアント側で作成して頂けるようになりました。
ただし、やはりシステムベンダーが作成するドキュメントは「システム目線」であるが故、実運用面でのシナリオ作りのベースになるようなものではないため、「新しいシステムで運用が適切に回るのか」という観点で検証する運用テスト用のシステムシナリオの元にはなり得ないということが分かっております。
その点についてはこれまで記述しているように、「業務プロセスフロー」が必要となってくると考えています。
業務プロセスフローがないことによる課題と対策
上記の例は私のこれまでの経験をもとに記述したものですが、「業務プロセスフロー」がないことによって発生する課題は、プロジェクトの最初の工程である要件定義から開発後のテスト工程にまで及ぶことになり、予算面やスケジュール面でもプロジェクトに大きなリスクを生じさせることになります。
すでに記述したように、システム機能フローは「システム機能」を「業務の流れ（フロー）」に沿って記述したものであり、「業務」が主体ではありません。
クライアントとしては、要件定義開始前までに現状の「業務プロセスフロー」を整理しておくことで、システムの入れ替えや改修による業務への影響や、その影響がサービスレベルを維持向上させる上で受け入れられるものなのか、現業の課題解決に有効な変更なのかなどの検証が可能となります。
また、現状を記述したドキュメントがあることにより要件定義や設計工程の中で「導入後の」業務プロセスフローを作成することができるため、プロジェクトの全工程において非常に有効な取り組みであると思われます。
「業務フローがないと何が困るのか」というテーマでは、上記のほかにも多数の「困った経験」が思い起こされます。
私自身のこれまでの反省も踏まえ、次回のブログでも引き続き同テーマで書いてみる予定です。
ITコンサルティングとソフトウェアの提供サービス、また、ウルグアイの製品であるジェネクサスという開発ツールを使ったシステム開発を行い、独自のソリューションを作ってユーザーに提供しています。コンサルとITを融合したサービス提供会社です。
株式会社イノベーティブ・ソリューションズ 取締役
【得意分野】
・物流・製造
・サプライチェーンマネジメント
