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