[[業務プロセス一覧>成果物/業務プロセス一覧]]に定義した業務プロセスについて、当該業務の登場人物、プロセス間の繋がりや順序、トリガを明記した上でフローにした[[業務設計ドキュメント>成果物/業務設計ドキュメント]]のこと。
----
#contents
----
* 作成目的 [#q534e575]
[[BPML>成果物/業務プロセス一覧]]のプロセス同士がどのような繋がりを持つか明示し、整合性のあるシーケンスの元リンクさせることで、業務全体とシステム機能を視覚的かつ直感的に理解できるよう形にする事が目的となる。
単体での価値もさることながら、後続の[[オペレーションマニュアル>成果物/オペレーションマニュアル]]の組み立てや、テストの工数見積およびシナリオ作成、ユーザトレーニング用のマテリアルへの記載など、幅広い用途で利用される。
[[アドオン]]関連のドキュメントも重要は重要だが、「会社としてのビジネスをどのように行っているか」や「システムをどのように利用しているか」を形に表すことは、どの[[成果物]]よりも重い役割を担っていると考える。
然るに、これを軽視していたり、まともな品質で仕上げられなかったり、更新を怠るような人間は、コンサルタントとしてあまりに未熟((便所コオロギレベル))と考えていい。
* 作成単位 [#tebcb1e8]
[[BPML>成果物/業務プロセス一覧]]とも関連するが、私の育った文化は、''レベルを4つに分け、Lv.1〜3を階層、Lv.4をプロセスとする''である。
他にも方法はあるのだろうが、これが一番しっくりきている。
具体的には、Lv.1にはロジとか会計といった規模を設定し、Lv.2には[[債権管理>財務会計/債権管理]]などコンポーネントに近いものや[[仕入先直送>販売管理/仕入先直送]]や締め処理といった代表的な業務を設定し、Lv.3には[[受注>販売管理/受注管理]]や[[出荷>物流管理/出荷管理]]などLv.2を構成する大きなまとまりとし、Lv.4に[[受注伝票>販売管理/受注伝票]]の登録など末端のプロセスを定義するというもの。
ここまでが前置きで、作成単位としては''ファイルはLv.2、シートやスライドをLv.3で分ける''が良いと考える。
作成する立場からは担当分けや分業がしやすく、レビューする立場からはキリがよく実業務担当もざっくりこれで分担範囲を明確にできるためだ。
ちなみに、Lv.1を[[販売管理]]や[[財務会計]]といったSAPモジュールおよびコンポーネントなどで分けることは、非常によろしくない。
理由は、それらはただの機能の話であって、業務 = 顧客のビジネスを定義するには必ずしも相応しくないため。
Lv.1〜2あたりの定義については、実は「顧客がしっくりくる単位」というのが良いかもしれない。
* 作成担当 [#oa1e41fd]
アプリチームなら誰でもよいと考えるか、ちょっとアドオン作ってみるのとはわけが違うため、最低でもサブリード以上のレビューは必要と考える。
* 作成タイミング [#w3667485]
設計フェーズの半ばくらいまでに作成し、実現化フェーズまでにfix
大抵はユーザトレーニングあたりでまた変更が入るのだが。
* 更新ルール [#ye1d7f1a]
[[機能一覧>成果物/機能一覧]]と同じく、あまり後続フェーズの変更が取り込まれないままとなるが、その本数と中身で大まかな流れを担保できることから、できれば都度都度の更新としたいところ。
逆に、放っておいてしまうとボリュームも業務も見えないこととなってしまう。
* misc [#q20e3d7b]
-メールや電話などの通信手段の書き方について
いちいち書くとフローがごちゃごちゃしてしまうという短所がある反面、ハコが少ないフローではアクセントになったり、通信手段自体を表現することでいちいちFAX送信していたり定型メールを送っていたところを自動化するなど、見直し図るきっかけになる・・・という長所もある。
そのため、基本的に社内の部門間は書かず、外部とのやりとりのみに記載するなどのルールを作るのは悪くない手かと思う。
-保管というプロセスを入れるか否か
実務上あまり破棄するようなものはないし、基本的に証憑は保管することが原則なので不要なのでは？とも思うが、監査要件上で明記しておくべきであったり、紙保存を電子保存にプロセス変更する切っ掛けになったりするので一概に括るのは難しい。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
