Business Process Reengineeringの略で、業務のプロセスやフロー、組織構造を分析・最適化することを指す。
* 概要 [#q2433afb]
広義では組織や事業の合理化が伴う大手術だが、SAPの世界では専ら標準機能に実業務を合わせることを意味する。
このプロセスは、''日常的に且つ継続的に取り組むべき''と考える。
** 手法 [#gc5e32a9]
*** 担当者やマネージャなど人から拾い上げる方法 [#w19a538a]
一般的に用いられることが多いのはこちら。
よい点は困っていることを本人の口からダイレクトに聞くことができることだが、裏を返せば誇張や個人ベースの不平不満レベルのものが混入することが多いとも言える。
他によい点は、相手に「ちゃんと話を聞いてくれている」という安心感を与えられることがある。
人間は所詮感情の生き物であることを鑑みれば、これは中々馬鹿にならないもので、いざ実現に向けて動き出せる体制や状態が整ったとしても、普段「時間がない」とか「予算がない」とかの一言で邪険に扱ってしまっていると、実担当者レベルからの協力が得られず捗らなかったりする。
そうなってから「トップダウンでやってくれないと」とか「協力しない人が悪い」とか言う人も少なくないが、捗捗しくない理由を論っても事態は好転しないので、こういうことを軽んじてはいけない。
*** 科学的に分析する手法 [#x55fd7c1]
これは、[[業務フロー>成果物/業務プロセスフロー]]および[[業務プロセス一覧>成果物/業務プロセス一覧]]などから機能数やプロセス数から定量的に分析する手法となる。
但し、前提としてそのためには実際のトランザクション数の加重を加味する関係からアセスメントが必要で、このためのツール（受注発注の伝票タイプ別の集計ツール、NASTでどれだけのメッセージが出ているかなど）などは予め用意しておいて良いかもしれない。
この手法のメリットは定量的な論拠を示しやすいことで、プロジェクトの決裁権限を持つ人間に話をしやすいことに直結する。デメリットというか留意すべきポイントとしては、前提として[[業務フロー>成果物/業務プロセスフロー]]や[[業務プロセス一覧>成果物/業務プロセス一覧]]などの業務設計ドキュメントが正しく運用されていることで、多くのユーザはこの足きりにあうと言っていい。
なので、提案する側はここからスコープとすることを検討するのも一案だろう。
** SAPバージョンアップや新システム導入との関係 [#t4b5163f]
バージョンアップやシステムの切替を機にBPRが実施されることも多いが、''これは本質的に良いことはない。''
もちろんBPRが悪いということではなく、何かのタイミングでまとめて実施するというのは本来的ではなく、「よりよい業務を」という活動は、絶え間なく実施していくべきということ。
具体的に弊害となるのは、バージョンアップを機に、とした場合、逆に言えばそれまで放置されっぱなしだったわけで、ネタのボリュームはそれなりになってしまい、自然コストも膨らむわけで、予算が超過するからダメ、となりやすいことが挙げられる。
もちろんバージョンアップを機に何かするというのは止せ、ということではなく、日常的に業務改善活動をしつつ、そういったイベントで普段なかなか取り組めないボリュームのものもやろう！というのが健康なBPRの在り方ではなかろうか。
余談だが、運動不足の人間ほどダイエットを決意した時に突然激しい運動をしたがるのに酷似しており、準備運動をロクにしないことも共通している。
普段からフルマラソンなんかする必要は無いが、エスカレーターでなく階段で上がるようにするのは日ごろから心がけるべきだということで、そういう基礎準備をした結果、「たまには」ということで何かの大会にエントリーしたりできる基礎体力がつくのではないだろうか。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
