業務プロセスを一覧化した[[業務設計ドキュメント>成果物/業務設計ドキュメント]]のひとつで、システムに要求される或いは実装された機能を網羅した[[機能一覧>成果物/機能一覧]]に、マニュアル処理を加えたもの。
Business Process Master List、および略称のBPMLとも呼ばれる。
----
#contents
----
* 作成目的 [#q534e575]
どのような業務プロセスがあるかを一覧化することで網羅性を担保し、後続の[[オペレーションマニュアル>成果物/オペレーションマニュアル]]の組み立て・テストのシナリオ作成および工数の見積もりなど幅広い用途で利用される。
ある意味では[[業務フロー>成果物/業務プロセスフロー]]と対になるものであり、こちらはビジュアルにすることで可読性や可視性を高めることを目的とするが、このドキュメントの価値は前述の網羅性を担保することの他に、''プロセスに属性を持たせることで定量的な分析を可能とする''ことがある。
例えば、総プロセスの中で占めるマニュアル作業や他システム作業の割合を分析したり、[[フォーム>アドオン/フォーム]]や[[レポート>アドオン/レポート]]のみを抽出して[[帳票一覧>成果物/帳票一覧]]を兼ねたり、何かと頼りになるドキュメントであるが、逆にこれらのような拠りどころとして値するよう作成しなければならない。
これが形骸化してしまっては、目的は果たせない。
* 作成単位 [#tebcb1e8]
分ける理由が無いため企業で一意、或いはロジ・会計・分析統計などの単位でひとつずつが妥当か。
SAPで言うコンポーネントくらいのレベル単位にしてしまうと、メンテ自体は楽だが可視性や網羅性など本来の目的が阻害されてしまうためお勧めできない。
* 作成担当 [#oa1e41fd]
少なくとも叩き台はアプリチームリード以上が作成すべきと考える。
理由は、細部はともかく自らがこうあるべきという大枠は一定程度の責任と裁量を持つロールがデザインすべきであるし、ジュニアレベルの人間にとってはAgendaにあたるものがはっきりすればイメージしやすく、また指摘を受けた際はダメなところが感覚的に受け止められるためである。
* 作成タイミング [#w3667485]
設計フェーズの半ばくらいまでに作成し、実現化フェーズにはfixする。
* 更新ルール [#ye1d7f1a]
[[機能一覧>成果物/機能一覧]]と同じく、あまり後続フェーズの変更が取り込まれないままとなるが、その本数と中身で大まかな流れを担保できることから、できれば都度都度の更新としたいところ。
逆に、メンテナンスを怠るとシステムや業務の改善を試みた場合に拠りどころに信頼が置けないという状態になってしまう。
これがもたらす災厄は、[[概要設計書>成果物/概要設計書]]や[[詳細設計書>成果物/詳細設計書]]が古いままの状態などとは比較にならない。
** フローのIDについて
たまにプロセスのIDにシーケンスを持たせようとする人間がいるが、これは''非常にどうでもいい''。
理由は、確かに初版を執筆する段で飛び番だらけというのは美しくないが、既存プロセスの中に新プロセスが割り込んできたら後続プロセスのIDをすべてずらすのか？という話。
するわけがないし、メリットもない。更新ミスによる混乱リスクを考えれば害悪とすら言うこともでき、シーケンスはフローのつながりで担保できるため、IDの連続性には神経質になることはない。
** プロセスとFunctionとの紐付けについて
業務プロセスと機能一覧上のFunctionの紐付けは、是非実施しよう。
業務的な意味が異なるためプロセスが分かれていても、利用するトランザクションコードは一緒・・・なんてのはよくある話だが、[[機能一覧>成果物/機能一覧]]上に似たような機能が散乱していても見づらいし、当初の目的は果たせない。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
