フレームワークで分析するのを本当にやめて欲しい - やまもといちろうBLOG（ブログ）
資料読んでて思うのだが… メソッドとしてフレームワークやマインドマップが使いやすいのは認める。問題の整理をするのに役立つのも分かる。でも4象限や8象限で分析できることなんて多寡が知れている、それを分かっていて割り切って使っているならともかく、成功や失敗、商品企画やマーケティングのあり方を説明するのにフレームワーク「だけ」を使って説明し説得しようというのはよろしくないと思う。 タスク分析とかで、重要度と緊急度で分類するのは一般的だし、その重要度を使いながらPDCサイクルを回そうというのは分かるんだけれども、毎回要素に還元して、事柄を分解してから整理するやり方になるから、問題解決（とか、成功分析、失敗分析とか）のアプローチとしては逆に遠回りになるわけで。 取り組むべき事柄が大量生産だったり、ミッションが明確であるならば、効率を目指してQC的に組織が改善を繰り返すのは効果あると思います。でもさあ
ステートメント分解：事例：チャート編 | 開米のシンキング・ラボ
さて、昨日ステートメント分解をした続きで、今度はグループ化（クラスター化）をするところですが、この問題のように情報量が少ない場合はあまり目立ったグループができないことが多いので、省略。 次、キーワード抽出です。 本部、各店舗 発注用端末、収集用端末、パソコン データ（発注、在庫、売上、ロス、返品） 作業（送信、取り込み、集計） 集計方式（店舗別、商品別） 出力先（プリンタ、ファイル） 販売・仕入管理ソフト 連動 こんなところですね。 で、これを並べ替えていくわけです。 並べ替える順序が問題ですが、何か一本、スジが見つかれば、それを核にして枝葉をつけていくことができる場合が多い。 この問題の場合は↓たとえばこの辺に注目しましょう （図１） 送信、取り込み、集計という３つの「作業」に注目したわけです。 この問題に限らず、「作業」は手順が決まっていることが多く、「並べる」場合の軸としてよい手がか
ステートメント分解：事例 | 開米のシンキング・ラボ
先日発行したメルマガで「ステートメント分解」についてちょっと書きましたので、その実例をちょっとやってみましょう。 下記は、あるシステムの概要説明資料に書かれていたテキスト（と思ってください。商品名等は架空のものです）。 テキストだけでは味気ないし印象が薄いですから、これを図解しよう、と思うわけですが、そのためにどんな手順を踏むかが問題です。 受発注システム「忍者ＳＳ」は、各店舗の発注用端末「忍者ＳＳ/手裏剣300」から本部の収集用端末に送信した発注データ・在庫データ・売上データ・ロスデータ・返品データなどの内容をパソコンに取込み、そのデータを本システムにて管理するものです。取り込んだデータは店舗別や商品別などに集計して、プリンターやファイルに出力する事が可能なため、販売・仕入管理のソフトなどに連動することが容易に行えます。 まず最初にするのがステートメント分解です。 地味な作業ですから、地
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
