昨日のお話のうち、
今回のエントリにあります、
>４．人の流れのうち、業務の役割の流れ
>５．人の流れのうち、インセンティブの流れ
が分かり難かったので、もう少し詳しくご説明いただけないでしょうか？
というコメントがありました。
するどい！
この分け方、放送大学大学院の、この先生「だけの」分け方だと思うんですよ！
で、そこに感動したんですけど、なんにも説明してないでした。
実際、その講座（経営システム１）でも詳しくやってなかったんだけど、
たぶん、こういう意味と、私が感じていることを説明します。
分析するとき、人、物、金の分析は、すると思うんです。
つまり、ユースケースで、業務を描いた後、その業務が、成立するかどうか（情報不足とかが、ないかどうか、物が流れてるかどうか）を確認します（この確認には、ＤＦＤを書くと図形的に分かるけど、ＵＭＬでは、かかない）。
で、そこで、ユースケースのアクター（実際には担当者になると思うけど）を持ち出して、担当者の観点から、その業務をまとめなおすという行為をする、これをアクティビティ図で表現したり（スイムレーンを部署とか、担当者にする）、シーケンス図にする（アクターを１つのクラス、オブジェクトと捕らえて表現してしまう）とか、清水建設が提唱するLFDとか、古来から、いろんな表現方法があるので、何で表現してもいいんだけど、そういう表現方法で記述し、実際、担当者レベルで見て、なにをやっているのかを作成し、それを担当者にヒアリングで確認するということは、やると思います。
っていうか、ここまでなんですよね。
ここで分類しているのは、物と人の業務の流れと、それに付随する情報の流れだけです。
でも、実際には、ビジネスなら、物が流れる時、ふつう、お金も流れているので、このあと、お金の流れを確認する必要があります。
つまり、それぞれの物に対して、このお金は、どういう形で支払われるのか？ということを確認するという作業です。
この辺について、ＵＭＬも、それ以前の考え方でも、（お金の回収も業務だから）あまり強調されていないので、効率的な確認方法は無いと思います（知らないだけかも）。
地道に確認するしかないかも。
で、今までは、ここで終わりなんだけど、ちょっとまって、って考えたのが、放送大学の先生の偉いところ！
アクターは、業務を行ったんだよねえ。
っていうことは、そのアクターに、お金払わなくっていいの？っていう考え方。
これは、社会的に考えると、「学歴社会から成果主義」とかいう話から入るんだろうけど、まあ、そこは省略。最近の場合、アクターが働いた分に対して、お金を払うというケースが出ている。
社外の人に対してなら、キックバック（リベートっす）とか、割引、マルチ商法とか（って、いいのかな？まあ、それまがいのもんとか）
社内の人に対してでも、成績によって、インセンティブを払うとかいう場合がでてきた。
そうすると、そのアクターごとに、
１．行われた（全ての）仕事に対して、インセンティブを与えなくていいのか？って考える必要がある。
２．そして、インセンティブを与えるとなったら、そのインセンティブの管理方法
（記録方法、支払方法）を考える
→（これは動的な側面、ＵＭＬなんかが得意）
３．とともに、インセンティブだけをまとめて考え（データ構造のような静的な側面）、
そのインセンティブが成立するかどうか、矛盾がないかを確認する必要がある
ここまで考えないと、最近の成果主義に基づいた、ドライな社会でのビジネスモデルは成立しない。
たぶん、こういうことが、言いたかったんだと思います。
しかし、インセンティブをめぐる管理方法と、そのインセンティブの整理、矛盾の発見方法は、まだあんまり考えられていないと思います。
実務上では、
（１）ラダー（ある量を販売すると、上のステージにいき、有利なインセンティブになる）制度がある場合、今月分を集計してからラダーに照らし合わせるのか？先月の成果を元にラダーを決めてから計算するのか？とか、
（２）対象が二重にかかっていいのかどうか？
（この商品を売ったら、１０％のキックバック＋合計１億円の売上の人は５％割引っていったとき、１億円販売し、かつ対象商品を売った人は、どっちの割引？それとも合算？）とか、
（３）インセンティブの支払い時期と方法、カウント時期など
で、部分的にはＯＫなんだけど、全体で見るとおかしいという矛盾が起きることがあります。
（ＳＥに指摘されるまで、気づかない営業もいるほど）
このへんを、効率よく見つけられる手法って。。。ないんですよね。
（私が知らないだけかも）、成果主義や会計でもＡＢＣ分析が入ってくると、問題になると思うけど。
今回のエントリにあります、
>４．人の流れのうち、業務の役割の流れ
>５．人の流れのうち、インセンティブの流れ
が分かり難かったので、もう少し詳しくご説明いただけないでしょうか？
というコメントがありました。
するどい！
この分け方、放送大学大学院の、この先生「だけの」分け方だと思うんですよ！
で、そこに感動したんですけど、なんにも説明してないでした。
実際、その講座（経営システム１）でも詳しくやってなかったんだけど、
たぶん、こういう意味と、私が感じていることを説明します。
分析するとき、人、物、金の分析は、すると思うんです。
つまり、ユースケースで、業務を描いた後、その業務が、成立するかどうか（情報不足とかが、ないかどうか、物が流れてるかどうか）を確認します（この確認には、ＤＦＤを書くと図形的に分かるけど、ＵＭＬでは、かかない）。
で、そこで、ユースケースのアクター（実際には担当者になると思うけど）を持ち出して、担当者の観点から、その業務をまとめなおすという行為をする、これをアクティビティ図で表現したり（スイムレーンを部署とか、担当者にする）、シーケンス図にする（アクターを１つのクラス、オブジェクトと捕らえて表現してしまう）とか、清水建設が提唱するLFDとか、古来から、いろんな表現方法があるので、何で表現してもいいんだけど、そういう表現方法で記述し、実際、担当者レベルで見て、なにをやっているのかを作成し、それを担当者にヒアリングで確認するということは、やると思います。
っていうか、ここまでなんですよね。
ここで分類しているのは、物と人の業務の流れと、それに付随する情報の流れだけです。
でも、実際には、ビジネスなら、物が流れる時、ふつう、お金も流れているので、このあと、お金の流れを確認する必要があります。
つまり、それぞれの物に対して、このお金は、どういう形で支払われるのか？ということを確認するという作業です。
この辺について、ＵＭＬも、それ以前の考え方でも、（お金の回収も業務だから）あまり強調されていないので、効率的な確認方法は無いと思います（知らないだけかも）。
地道に確認するしかないかも。
で、今までは、ここで終わりなんだけど、ちょっとまって、って考えたのが、放送大学の先生の偉いところ！
アクターは、業務を行ったんだよねえ。
っていうことは、そのアクターに、お金払わなくっていいの？っていう考え方。
これは、社会的に考えると、「学歴社会から成果主義」とかいう話から入るんだろうけど、まあ、そこは省略。最近の場合、アクターが働いた分に対して、お金を払うというケースが出ている。
社外の人に対してなら、キックバック（リベートっす）とか、割引、マルチ商法とか（って、いいのかな？まあ、それまがいのもんとか）
社内の人に対してでも、成績によって、インセンティブを払うとかいう場合がでてきた。
そうすると、そのアクターごとに、
１．行われた（全ての）仕事に対して、インセンティブを与えなくていいのか？って考える必要がある。
２．そして、インセンティブを与えるとなったら、そのインセンティブの管理方法
（記録方法、支払方法）を考える
→（これは動的な側面、ＵＭＬなんかが得意）
３．とともに、インセンティブだけをまとめて考え（データ構造のような静的な側面）、
そのインセンティブが成立するかどうか、矛盾がないかを確認する必要がある
ここまで考えないと、最近の成果主義に基づいた、ドライな社会でのビジネスモデルは成立しない。
たぶん、こういうことが、言いたかったんだと思います。
しかし、インセンティブをめぐる管理方法と、そのインセンティブの整理、矛盾の発見方法は、まだあんまり考えられていないと思います。
実務上では、
（１）ラダー（ある量を販売すると、上のステージにいき、有利なインセンティブになる）制度がある場合、今月分を集計してからラダーに照らし合わせるのか？先月の成果を元にラダーを決めてから計算するのか？とか、
（２）対象が二重にかかっていいのかどうか？
（この商品を売ったら、１０％のキックバック＋合計１億円の売上の人は５％割引っていったとき、１億円販売し、かつ対象商品を売った人は、どっちの割引？それとも合算？）とか、
（３）インセンティブの支払い時期と方法、カウント時期など
で、部分的にはＯＫなんだけど、全体で見るとおかしいという矛盾が起きることがあります。
（ＳＥに指摘されるまで、気づかない営業もいるほど）
このへんを、効率よく見つけられる手法って。。。ないんですよね。
（私が知らないだけかも）、成果主義や会計でもＡＢＣ分析が入ってくると、問題になると思うけど。
アクセス
トータル
ランキング
