成果物 の変更点
Top/成果物
- 追加された行はこの色です。
- 削除された行はこの色です。
- 成果物 へ行く。
- 成果物 の差分を削除
プロジェクト成果物としての、ドキュメント群について。 ---- #contents ---- * 概要 [#x6b3cd0a] 同じ名称であるが位置付けがベンダによって異なったり、異なる名称で同一のものを指していたりすることがあるため、ここでは独断と偏見と筆者の充分でない経験に基づき、ドキュメントを下記に分類する。 ** 管理ドキュメント [#m58db99c] プロジェクト管理に関わるものと、ここではプロジェクト方針に関わるものも併せて取り扱う。 -[[提案書>成果物/プロジェクト提案書]] -[[体制>成果物/プロジェクト体制]] -方針系ドキュメント --課題管理方針 --移行方針定義書 --統合テスト方針定義書 -マスタスケジュール -[[WBS>成果物/WBS]] -[[課題管理表>成果物/課題管理表]] -[[変更管理表>成果物/変更管理表]] -[[不具合管理表>成果物/不具合管理表]] -[[移行対象一覧>成果物/移行対象一覧]] -[[追加開発一覧>成果物/追加開発一覧]] -[[議事録>成果物/議事録]] ** 設計ドキュメント [#ib67e981] [[業務設計ドキュメント>成果物/業務設計ドキュメント]]を参照のこと。 *** 用法 [#ybde248b] どのドキュメントにも言えることだが、作成するだけでなく、より良く利用することを考えるべきであり、具体的には科学的な分析アプローチがある。例えば・・・ -[[業務フロー>成果物/業務プロセスフロー]] これをテストやトレーニングの見積の根拠とするという事までは実施しているところは少なくないが、この数でどれだけ多岐にわたる業務をこなしているかの証左とうかがい知るアプローチを取っているところは少なくない。 ここに実際の取引数を乗算したり粗利と突き合わせれば、会社としてのコアビジネスがわかるため、改善や新規プロジェクトの提案の取っ掛かりになることは気に留めておいたほうが良い。 -[[業務プロセス一覧>成果物/業務プロセス一覧]] 単純にプロセスの数でワークロードの規模は予測できるし、総プロセスとシステム化済プロセスの割合でどれだけITを活用しているかが分析できる。 また、はじめはフロー単位で月別の発生数を算定し、このプロセスに落とすと、どのプロセスが投資対効果が高いかがわかる。 例えば、半期や年次など頻度の低い業務フローの半分をシステム化するのと、日次など頻度の高い業務フローのプロセスをひとつだけシステム化するのは、どちらがよい？という、誰でも直感的に簡単に答えられる問いに対して、裏付けを添えた回答が用意できるということ。 -[[機能一覧>成果物/機能一覧]] どの分野でシステム化が顕著であり、また標準機能を活用しており、アドオンが多いのかなど。 *** 会計系の業務設計 [#uc3c58fd] 金勘定という厳密さを求められる業務に従事しているせいか、ユーザにしても100%確かなものを積み上げていくというアプローチになることが多い。 これは何かをピックアップしたときに「いい加減なものがない」「全てが説明可能」という状態が多くなるという、個々の精度の高いアプローチとなる。 欠点は、確からしいものを積み上げるのだが、全体を鳥瞰するアプローチでないために見渡したときに綺麗でない傾向があること((美しくないものは、大抵ムリ・ムダ・ムラを抱えている))、また厳密性を追求するため、むやみやたらにハコが多くなってしまい、業務フロー本来の目的である視認性を損なうこともしばしば。 *** ロジ系の業務設計 [#kd7263b7] 経理系とは対照的にOverviewから入る人が多く、全体のデザインとしては綺麗にまとまることが多い。 が、ロジ系には須らくざっくりした人が多いため、全体的にokだなと思ったら「もうok」となってしまい、細部にケアが足らず、シーケンスの誤りやプロセスの抜け漏れが出ることもしばしば。 それがワークロードの高いアドオンの元だったりすることもあり、そういう意味でも後続フェーズでのトラブルが多いのはロジ系と言えよう。 *** 大企業における業務設計について [#bff560b5] 例えば個別の取引先ごとに連絡の頻度や手段が異なるなど、関わる人が多くなればなるほど業務が多様化するが、これに対して網羅性を求めて全てをドキュメンテーションの対象としてしまうと、そもそも業務設計の目的の一つである可視化や視認性を損なってしまう。 これについて、細分化のひとつの判断基準としては、[[フォーム>アドオン/フォーム]]や[[レポート>アドオン/レポート]]など何らかのOutputが存在するか否か？がある。 これは、そのプロセスがシステム化し得るか否か、また廃止あるいは簡素化できるか否かという、BPRの余地があるかが挙げられる。 が、シニアならともかくジュニア同士であったり複数人で実施する場合（大抵そう）は、こういったファジーな判断条件で運営するのはなかなか難しいのは事実。 ** 開発ドキュメント [#ib67e981] [[追加開発ドキュメント>成果物/追加開発ドキュメント]]を参照のこと。 * 関連ページ [#gea38251] #ls2(成果物/) #ls() ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_book_sap_system_implement) ~ ~ ---- #pcomment(reply)