アクセスカウンタ

生涯続学

プロフィール

ブログ名
生涯続学
ブログ紹介
自分が仕事のキャリアにおいて学んだことや考えたことを、第三者にも分かるように出来るだけ整理して発信することにより、同様のことで苦労している方に、少しでも参考になればと思いこのブログを開設しました。
zoom RSS

こうすれば、情報システム構築プロジェクト及びホワイトカラーの業務改革が成功する。

2017/03/11 07:48
掲載意図
 Singularityいわゆる情報革命により世の中が劇的に変化すると予想されています。そのような状況下でIT部門不要論が叫ばれています。悩めるIT部門に対して、具体的にこうすれば、存在価値を発揮できる(真に経営に貢献できる)と勇気付けたい
 日本はもっとホワイトカラーの生産性を上げなければ、今後ますますジリ貧に陥ってしまいます。これに対する一つの処方箋を探究したいと思っています。

問題は何か?
 従来、情報システム構築プロジェクトが成功しない原因、及びホワイトカラーの業務改革が成功しない原因、それに対する解決策が提言されてきました。しかし「未だに情報システム構築プロジェクト及びホワイトカラーの業務改革の成功率が低い」という現実があります。

★何故か?
 「今迄提言されてきた解決策は、企業の平均的な人が実行可能で、具体的な解決策ではなかった。」からだと考察します。

★本稿は従来の主張と、どこが違うのか?
 企業の平均的な人が実行可能で、具体的な新しい解決策について、誰もがイメージし易い「モデル事例を交えて提言」しています。

★本稿で論じる具体的で新しい解決策とは
 企業の平均的な人達が「これから述べる5つのことを理解する」ことにより、経営層、事業(ユーザー)部門とIT部門相互の理解力が大幅に向上します。その結果、情報システム構築プロジェクトの成功率及びホワイトカラーの業務改革成功率を上げることができると確信しています。

●アジェンダ

01. ITプロジェクトやホワイトカラーの業務改革成功率が低いことに対する従来の解決策

02. 従来の解決策は、『企業の平均的な人が実行可能で、具体的な解決策ではなかった。

03. 従来解決策と新しい解決策の違い

04. 社内業務及びシステムを可視化するときのポイント

05. 事業(ビジネス)活動の本質を考える

06. ビジネス管理対象とBPRSとういう考え方

07. 社内ドキュメント及びインタビューに関する問題点

08. ビジネス管理対象とそれに対するBPRS/BPをシステマティックに展開していく事例

09. キーオペレーションを把握、確認する

10. BPRSの主な成果物4つの具体例

11. BFDを作成する

12. 問題点及び検討課題に対する【解決案(含仮説)】を作成する

13. 具体的な解決策について検討する

14. 非IT部門の人とは情報システム実装設計の世界の言葉で話をせずに、BPRSの成果物で会話する。


記事へブログ気持玉 / トラックバック / コメント


ITプロジェクトやホワイトカラーの業務改革成功率が低いことに対する従来の解決策

2017/03/11 07:44
なぜITプロジェクトやホワイトカラーの業務改革成功率は低いのか?

 IT投資の効果については、総務省のアンケート調査の結果(*1)をみると、効果があったとの回答が米国では約70%に達するのに対して、日本では50%強とかなり低くなっており、特に「IT投資効果が充分あった」とする日本企業は、3.5%に過ぎず、IT投資に対する満足度が非常に低くなっています。

 また、ホワイトカラーの業務改革が成功していないデータとしては、2014年の日本の労働生産性は72,994ドル、OECD加盟34カ国の中では第21位(*2)でした。

 さらに情報システム構築プロジェクトの成功率は、日経コンピュータの調査によると2003年調査では平均26.4%、2008年調査では平均31.1%でした。一方「2014年10月16日号」では、これより成功率が上った調査結果もありますが、この数値は“成功をどう定義するか”によって、変わります。たとえば成功の定義に、予算及び利用開始までの期間等が当初計画の範囲内か、の他に「投資を回収できる見込み(目的を達成することにより経営に貢献する)」も入れると、“相変わらず、成功率は高くない”と推察されます。

 一方で調査会社ITRの「IT投資動向調査」によると、IT部門が決定権を持つIT支出の割合が、2015年度には42.7%に落ち込んでいる。2年前の2013年度に比べると10ポイントも低下している。IT部門の影響力は崩落状態にあると言えます。

*1 平成17年度版情報通信白書
*2 日本生産性本部調査

そこで、情報システム構築プロジェクト、及びホワイトカラーの業務改革に対して、従来言われてきた「成功しない原因」とそれに対して提言されてきた「解決策」を振り返ってみます。

従来、情報システム構築プロジェクトの成功率が低い「原因」と言われてきた代表的な例をKJ法的に纏めます。

●原因グループ1
・経営レベルでIT化の目的や要件の詰めが充分でないまま投資が決定されている。

・ビジネスが理解できないIT部門とITが理解できない経営層、事業(ユーザー)部門

・投資の全体額(ライフサイクル全体コスト)とその影響が充分に理解されずに議論・判断が行われる。

これらの原因を要約すると
★「情報システムに関して、経営層、事業(ユーザー)部門、IT部門相互間のコミュニケーション力不足」に原因があります。

●原因グループ2
・経営者はビジネスに対する影響には関心がありますが、業務の詳細やデータの詳細までは興味がありません。
また事業部門は、自分達に関係する業務及びデータには関心がありますが、全社的な関係までは関心がありません。

・経営層が深く理解しなければいけないところはどこかが分かっていない。

その結果⇒事業部門の経験豊富なキーパーソンやエース級の人材は非常に忙しく時間が取れない。

その結果⇒事業(ユーザー)部門が成果物に対するレビューに充分な工数を取れない。

その結果⇒IT部門の成果物に対する理解が不充分なまま進めてしまう。

その結果⇒★ビジネス(経営)課題との整合性が担保されていない。


●原因グループ3
・事業戦略を踏まえたうえでビジネス(経営)課題を解決するオペレーションとシステムを作り上げることが重要であるが、業務の見直しと管理・ルールの見直しが不充分であることが多い。

・役割と責任が曖昧で決まらない。

その結果⇒業務に対する義務と責任が曖昧

その結果⇒IT投資効果に関係する業務のパフォーマンスが不充分

その結果⇒★IT投資効果に不満


次に従来、「解決策」として言われてきた代表的な例を揚げます。
・事業(ビジネス)とIT の両方を理解し、IT を活用した業務改革を企画・推進できるIT人材を育成する。その為に、相互に人材を派遣して相手の業務を学ばせる。

・事業(ユーザー)部門からプロジェクトに参画する担当者についても、IT活用の企画・推進をリードする経験豊富なキーパーソン、エース級人材を投入する。

・ビジネス(経営)と情報システムのインターフェースが不可欠であり、そのためにIT部門の役割や位置付け、責任や権限など抜本的に見直す。

 これらを図で表現すると下図のようになります。
画像

これら従来の解決策は全て尤もなことばかりです。では何故、未だに情報システム構築プロジェクト及びホワイトカラーの業務改革の成功率が向上しないのでしょうか?
トップページへ戻る
記事へブログ気持玉 / トラックバック / コメント


従来の解決策は、『企業の平均的な人が実行可能で、具体的な解決策ではなかった。

2017/03/11 07:43
 『従来の解決策は全て尤もなことばかりです。では何故、未だに情報システム構築プロジェクト及びホワイトカラーの業務改革の成功率が向上しないのでしょうか?』と問題提起をしましたが、これについて私は、従来の解決策が、『企業の平均的な人が実行可能で、具体的な解決策ではなかった。』からだと考察しています。

従来の解決策と新しい解決策の違い
(1)IT部門の役割や位置付け、責任・権限はどうあるべきでしょうか?
「ビジネス(経営)と情報システムのインターフェースが不可欠であり、そのためにIT部門の役割や位置付け、責任・権限など抜本的に見直す。」が提言されています。では、具体的にどう見直すべきなのかハッキリしません。一方で、最近は『IT部門不要論』があります。企業規模等によって違うという意見もあると思いますが、総ての企業内IT部門に共通する必須のミッションが存在すると私は考えています。

企業内IT部門の必須ミッション
 企業内IT部門の必須のミッションは経営者並びに事業部門と一緒になって、「ビジネス(経営)課題を把握/整理」して、「解決策を検討する」こと及び「その解決策を情報システム設計に繋げる」ことです。その為には企業(グル−プ)内で管理対象とすべき総てのデータを、把握/維持管理して、孤立化させずに連携させて、活用することが必要です。

 企業内で管理すべきデータは、事業規模、組織規模によって違いますが、大きいものではテーブル数で数千、データ項目数で万を超えることも有ります。これを適切に維持管理しなければ、折角時間とコストを掛けて蓄積した企業(グル−プ)内データを使いビッグデータ分析等を行い、ビジネスに有効に活用することは出来ません。

 一般的に物/事を識別するために物/事に識別コードを付与しますが、同一の物/事に該当するデータであっても、識別コード、データの定義が企業グル−プ内の組織、及び企業間で一致していることが保障されているとは限りません。それは対象としているデータを他の業務で活用することを考えずにプロジェクトがシステム(業務)設計を行った結果、往々にして生じます。

 例えば、データの定義が一致しているか否かの例として有効在庫を考えてみます。「有効在庫」に「発注残」を含むと定義するか、含まないと定義するかによって結果が変わります。この場合は、さらに「発注残」自体の定義が一致しているのかも問題です。この様に、データの定義が違うと当然対象となるデータの範囲が変わります。その場合は、ビッグデータの収集・利用範囲を単純に拡張することは出来ません。

 またビジネスの変化に合わせて情報システムを変更(統廃合)する場合、企業グループ内のデータの把握/維持管理を適切に行っていないと、変更(統廃合)による既存業務、既存システムへの影響を把握しきれずに、大きな問題を起こすことになりかねません。

 「企業(グループ内)データの把握/維持管理/有効活用を考える」のは誰が一番相応しいのでしょうか? それは企業内IT部門であると考えます。これが企業内IT部門の最大のミッションです。
<理由>
 情報システムはビジネス課題を解決するための手段の1つです。ビジネス課題が戦略的であればあるほど、情報漏洩リスクを低減するためにも、社内の人間がやる必要があります。また、ビジネス課題を解決する為に企業内(パートナー企業含む)のデータを連携させて活用する必要性が益々高まっています。それは当然、企業内のデータを維持管理すべき企業内IT部門が行う必要があります。

業務プロセス及びデータの変更/追加が現状のプロセス、データ、相互にどのような影響を与えるのかを把握する為には社内の人間がやる必要があります。また、影響把握に時間が掛かるようでは、ビジネス競争に負けてしまいます。
一方、情報システム構築・運用は企業内IT部門の必須のミッションではありません。
トップページへ戻る


記事へブログ気持玉 / トラックバック / コメント


社内業務及びシステムを可視化するときのポイント

2017/03/11 07:42
 前述で、実際に可視化に取り組んでみると
@苦労して業務及びシステムの可視化を行った割には、成果が出ない。
A業務の可視化作業の負荷が大変
Bそもそも業務の可視化とは、どうすれば良いのか分からない。

などの問題をよく耳にします、と述べました。

この問題の原因は
可視化で押さえるべきポイントが曖昧であり、可視化が必須の物/事に抜けがあり、必ずしも可視化する必要がない物/事が混じっているためです
。また、往々にして可視化自体が目的になってしまっていることに起因しています。

私たちに最も必要なのは、何が重要で何が重要でないか、どの変数に焦点を当て、どれにはあまり焦点を当てなくてよいかを知る方法である。そして私たちには、これを行うために、グループやチームが共通の理解を深める方法が必要である。

木も森も見る−広範なパターンと詳細なパターンの両方に関する情報を見る−両方を見ることによってのみ、複雑性と変化の難題に力強く対処することができる。

相対的に足並みのそろっていないチームに必ず見られる特徴は、エネルギーを無駄にしていることだ。ひとり一人は一生懸命やっているのに、その努力が効率よくチームの成果に結びつかない。
----- ピーター・M・センゲ『学習する組織』英治出版社、2011年 ------

●社内業務及びシステムを可視化するときのポイント
-----
ビジネスや人間によるそのほかの企てもまたシステムである。それらは相互に関連する行動が織り成す、目に見えない構造でつながっていることが多く、お互いへの影響が完全に現れるまでには、何年もかかる場合も多い。

原因と結果は、時間的にも、空間的にも、近くにあるわけではない。最もレバレッジの高いところは往々にして最も分かり難い。
システム思考は全体を見るためのディシプリンである。物事ではなく、相互関係を見るため、そして静態的なスップショットではなく変化のパターンを見るための枠組みだ。

複雑性には大きく二つのタイプがある。多くの変数があるタイプの複雑性と、もう一つのタイプの複雑性がある。後者のタイプはダイナミック(動的)な複雑性であり、この状況では、原因と結果がとらえにくく、相互作用が長期に及ぼす効果が明らかではない。

従来の予測・計画・分析方法は、ダイナミックな複雑性を扱う機能を備えていない。
問題の根底にある主要な相互関係に目を向けることが、可能な打ち手についての新たな洞察につながる。

線形の因果関係の連なりよりも、相互関係に目を向ける。スナップショットより、変化のプロセスに目を向けることが必要。
----- ピーター・M・センゲ『学習する組織』英治出版社、2011年 -----

可視化により成果を出すためには下図のような条件が必要だと考えます。
画像

また、社内業務及びシステムを可視化するときのポイントを考えるに当たっては、事業(ビジネス)活動の本質を考える必要があります。
トップページに戻る

記事へブログ気持玉 / トラックバック / コメント


従来解決策と新しい解決策の違い

2017/03/11 07:42
 私が考えるビジネス課題を解決するための情報システム構築・運用Stepと企業内IT部門の役割は下図の通りです。
画像

 SI(System Integrator)に全て任せる訳にはいきません。これがコストセンターであるIT部門を社内に置く最大の理由です。
 一方でITの技術進歩は速いので、一般的な企業内IT部門が最新のITをキャッチアップし続けていくことは非常に大変です。したがって、RASIS(*)に関連する部分は費用対効果でアウトソージングしても構いません。
* Rは“Reliability”(信頼性)
Aは“Availability”(可用性)の略で、稼働率の高さ、障害や保守による停止時間の短さを表す。
Sは“Serviceability”(保守性)の略で、障害復旧やメンテナンスのしやすさを表す。
Iは“Integrity”(保全性・完全性)の略で、過負荷時や障害時のデータの破壊や不整合のなさを意味する。
Sは“Security”(機密性)の略で、外部からの侵入・改ざんや機密漏洩の起きにくさを表す。

従来解決策と新しい解決策の違いの1つは以下の通りです。
画像

 次に事業(ビジネス)とITの両方を理解し、成果を出す為には具体的にどうすべきでしょうか?
「事業(ビジネス)とIT の両方を理解し、IT を活用した業務改革を企画・推進できるIT人材を育成する。その為に、相互に人材を派遣して相手の業務を学ばせる。」が提言されています。

 しかし、派遣する人材は誰でも良い訳ではなく、現在または将来その部門のエースとなるべき人材でなければ効果はありません。そのような人材を長期間、自部門から外す余裕のある企業は少ないのが一般的です。また、成果を出すためには、限られた一部の人間だけが、事業(ビジネス)とITの両方を理解すれば良い訳ではありません

 次の5つを企業の平均的な人が理解することで、ビジネス課題に対する解決策を確実にシステム設計に繋げることができます。また結果にコミットすることにより成果を出すことができます
1. 対象とする組織が外部に提供する価値とその提供先を確認する。
2. ビジネス全体の関係者(社)と其々の関係を図で表現する。
3. ビジネス全体の関係図を基にしてキーオペレーションを把握、確認する。
4. キーオペレーションをベースにして現状BPRSを作成する。
5. 業務改善後の新BPRSを作成する。


BPRS構成要素と成果物の例を示します。
画像

具体的には後のモデル事例で説明します。
従来解決策と新しい解決策の2つめの違いは次の通りです。

画像

 また、事業部門の経験豊富なキーパーソン、エース級人材は非常に忙しく、情報システム構築プロジェクトの為に充分な時間が取れないことに対する工夫が必要です。

 その理由は、「事業(ユーザー)部門からプロジェクトに参画する担当者についても、IT活用の企画・推進をリードする経験豊富なキーパーソン、エース級人材を投入する。」が提言されていますが、現実には事業部門の経験豊富なキーパーソン、エース級人材は多忙であり、情報システム構築・導入プロジェクトの為に充分な時間が取れないのが一般的です。これに対する工夫がないと画餅に終わってしまうからです。

●上記問題に対する工夫
 常日頃から、「社内業務及びシステムを可視化」しておくことにより、情報システムの構築・導入及びホワイトカラーの業務改革による影響を、事業部門の平均的な人が理解し易くなります。
 一方、事業部門の経験豊富なキーパーソン、エース級人材は、事業部門内での影響力という意味では、相変わらず重要な存在です。

 全社業務の可視化も企業内IT部門が行うのが望ましいと考えます。その理由は、事業部門は自分達の業務と自分達が利用するデータには関心がありますが、一般的に業務とデータの全社的な関係までは関心が薄い。(*1)

*1 組織内の人達が自分の職務にだけ焦点を当てていると、すべての職務が相互に作用したときに生み出される結果に対して、責任感を殆どもたない。私達が自分の職務にだけ焦点を当てていると、自分自身の行為が、その職の境界を越えてどのように影響するのかが見えなくなる。--- ピーター・M・センゲ『学習する組織』英治出版社 2011年 ---

 情報システムもホワイトカラー業務も、データを扱います。

 システムがうまく機能しない理由の中で最もよく見られるもののひとつが、情報の流れの欠如である。情報を追加したり取り戻すことは強力な介入となる。通常は物理的なインフラを再構築するよりも、すっと簡単でコストもかからない。重要なのは、正しい場所に説得力のある形で欠けているフィードバックを復活させることである。(*2)
*2 ドネラ・H・メドウズ『世界はシステムで動く』英治出版社 2015年

 管理対象である全社のデータを把握し管理するのは企業内IT部門が相応しいと前述しました。最近ではSingularity 所謂、情報革命が盛んに言われています。そうであれば尚更です。

 管理対象である全社のデータを把握するということは、データにアクセスする業務も当然、把握する必要があります(*3)。その結果、全社のデータを把握している企業内IT部門が、必然的に業務とデータの全社的な関係を把握することになります。

*3 業務プロセスの変更はデータの構造にも影響を与える可能性があります。またその逆もあり得ます。下図参照
画像

 情報システム構築プロジェクトの成功率が低い原因、及びホワイトカラーの業務改革の成功率が低い原因は、下記因果関係図からも分かるように、「社内業務及びシステムを可視化」することにより解決できます。
画像

従来解決策と新しい解決策の違い(3)

画像

 しかし、実際に可視化に取り組んでみると次のような問題をよく耳にします。
@苦労して業務及びシステムの可視化を行った割には、成果が出ない。
A業務の可視化作業の負荷が大変
Bそもそも業務の可視化とは、どうすれば良いのか分からない。

トップページに戻る
記事へブログ気持玉 / トラックバック / コメント


事業(ビジネス)活動の本質を考える。

2017/03/11 07:41
 前述で、社内業務及びシステムを可視化するときのポイントを考えるに当たっては、事業(ビジネス)活動の本質を考える必要があります、と述べました。

 ではビジネス活動の本質とはなんでしょうか?
 事業(ビジネス)とは、(1)当該企業外に価値を提供して利益を上げるために、(2)必要な経営資源を調達し、(3)調達した経営資源をオペレーションして、成果を出すことです。経営資源の具体例等を次表に示します。
画像

 ビジネスにおける管理対象には、上表A列の“経営資源”自体、B列の“経営資源に附随する情報(データ)”、及びC列の“経営資源間の関係情報”があります。
また、事業(ビジネス)活動では、経営資源が単独でオペレーションされることは殆どなく、下図のような関係があります。
画像

 例えば、地域による売れ筋商品を分析する場合、主に次の6つが関係すると考えられます。@商品(有形物)、A商品を販売した店(有形物)、B店がある地域(有形物に関係する情報)、C販売金額(無形物;販売情報の一部)、D販売数量(無形物;販売情報の一部)、E商品が売れた日時(無形物;販売情報の一部)

管理対象である経営資源をオペレーションする為には、行動と行動主体(責任/権限を有する)及び機能が必要です。
 これら三者の関係は下図のようになります。
画像


以後、業務プロセスをBP(Business Process)と呼ぶことにします。
トップページに戻る
記事へブログ気持玉 / トラックバック / コメント


ビジネス管理対象とBPRSとういう考え方

2017/03/11 07:40
 これからビジネス管理対象とBPRS(Business Process Relationship)とういう考え方について説明します。

●ビジネス・プロセス・リレーションを把握する
 企業はビジネス(事業)の目的を達成するために、多数のオペレーション行います。また、オペレーションは、複数のBP(業務プロセス)から構成されます。それらは相互に関連する行動が織り成す構造で繋がっています。
 線形の因果関係の連なりよりも、相互関係に目を向ける。スナップショットより、変化のプロセスに目を向けることが必要です。

 そのため以後、ビジネスに関係するオペレーションを別名でビジネス・プロセス・リレーションシップ(Business Process Relationship)と呼ぶことにしたいと思います。BPR(Business Process Re-engineering)と区別するために、BPRSと表記することにします。
●ビジネスルールを把握する
 BPにはビジネスルールが存在します。例えば、商品を調達するBPでは、“必要な商品を発注する為のルール”、“届いた商品を検品する為のルール”、“検品済みの商品を在庫計上する為のルール”、“受け取った商品の代金を支払う為のルール”等々。ビジネスルールの無いBPは存在しません(ルールが複雑/単純の違いはあります)。また、BPRSにもルールが存在する場合があります。
 BPには下表のように3つの種類があります。
画像

●BPRS及びシステムを可視化するときのポイント
 人間同士がコミュニケーションを取りながら(確認しながら)理解する上で、効果的な方法は、ダイアグラム(図・表等)で表現することです。但し、詳細を理解するためには文章による説明が必要なことは変わりません。

 更にダイアグラムで表現すべき内容も、立場によって変わってきます。一般的に、経営者に近い人ほど、BPRSの表現は粗くても、全体を鳥瞰して、重要な箇所だけは詳しく知りたく、業務担当に近い人ほど、自分に関係するBPRSには詳細な表現を求めます

 マネージャーは上位に行くにしたがって広い範囲である程度集約された内容で良い傾向があります。これは経営者として、マネージャーとして、何を、どう管理/把握すべきかによって変わってきます。下図参照
画像

 一方、必要に応じて自分が関係するBPRS/BP及び扱うデータが、ビジネス(事業)全体とどの様な関係にあるのかを理解することが、業務改善、情報システム変更(統廃合)による影響を理解する上で非常に重要です。

 従来は、現状のビジネス管理対象及びBPRS/BPを把握する上で、真っ先に頼り(手掛かり)としたのは、社内にあるドキュメント類です。
トップページに戻る

記事へブログ気持玉 / トラックバック / コメント


社内ドキュメント及びインタビューに関する問題点

2017/03/11 07:40
 従来は、現状のビジネス管理対象及びBPRS/BPを把握する上で、真っ先に頼り(手掛かり)としたのは、社内にあるドキュメント類です。
しかし、社内ドキュメント類に関しては次のようなことがよく見うけられます。

★ドキュメント化されていない。
★ドキュメント内容が不充分。
★ドキュメントが更新されていない。
★同じ社内用語でも定義が曖昧なため、ドキュメントにより用語の意味が違う。


 歴史のある企業、複雑な組織、変化の激しいビジネスを行っている企業、頻繁に組織変更を行っている企業等々では、(ドキュメントが更新されていないため)ドキュメントの記述と現状のBPが違うことがよく見受けられます。

 そこで、業務に精通している人(事業部門の経験豊富なキーパーソン)にインタビューをしてドキュメントの補修を試みますが、今迄何度も問題にしているように、事業部門の経験豊富なキーパーソンは一般的に多忙であり、なかなか時間が取れません。
 また、インタビューには次のようなデメリットがあります。

★例外事項や問題点など、インタビュー対象者の心の中に強く印象づけられている事柄に影響されることがある。
★自分にとって不都合なことなど、意識的に説明を省いたり、強調したりして、事実の判断を誤らせることがある(*)。
★手間がかかる 。
★時間と空間の制約をうける 。


*人は全ての真実を、しかも真実のみを知らせてくれる能力があるとは限りません(未確認の意見と事実を混同することがある)。インタビューを受ける人は嘘をつくつもりはありません、彼等の目から見る限りは...

 一方でインタビューを受ける人は、インタビューをする人が何に関心があり、何を重要だと考えているのか、完全に理解できている訳ではありません。したがって、インタビューを受ける人は、訊かれたことには答えますが、自発的に、何を、どこまで、説明する必要があるのかは、分かりません。

 そのため、対象業務に関するインタビューにおいて、「重要なことを訊くのが漏れていた、さほど重要ではないことを一生懸命訊いていた(調べていた)ことに後から気付く」ということがよく起こります。当然インタビュー(調査)の効率も良くありません。

 上記の問題を解決するために、もっと効率の良い方法を考える必要があります。
それは、ビジネス管理対象とそれに対するBPRS/BPをシステマティックに把握する方法です。
トップページに戻る
記事へブログ気持玉 / トラックバック / コメント


ビジネス管理対象とそれに対するBPRS/BPをシステマティックに展開していく場合の事例

2017/03/11 07:39
 これから、具体的なビジネスモデルを使いシステマティックに展開していくプロセスを順番に説明していきます。

●ビジネス管理対象とそれに対するBPRS/BPをシステマティックに展開していくプロセスの事例

 ビジネスモデルとして誰もがイメージし易いコンビニ・ビジネスを使い説明します。但しコンビニ・ビジネス自体を説明することが目的ではなく、理解し易さを優先しているため、実際のコンビニ・ビジネスを正確に表現している訳ではありません。

1. コンビニフランチャイズ本部が外部に提供する価値とその提供先を確認します

 フランチャイズ本部が直接価値を提供する相手は、加盟店のオーナーです。加盟店のオーナーが価値を提供する相手は、“自分が経営するコンビニ店舗で買い物をしてくれるお客様”です。一方、お客様から見たコンビニ店舗の魅力は何かを再確認すると、お客様が、「欲しい時に」、「欲しい商品が」、「欲しい量」買えることです。

 故に、フランチャイズ本部は加盟店に対して、お客様が、「欲しい時」に、「欲しい商品」が、「欲しい量」、販売出来るようにすることです。一方で売れ残った商品(特に弁当・惣菜等の生鮮食品類)は加盟店の責任で廃棄処分されます。また、一般的にコンビニ店舗は商品陳列スペースが狭いため、売れない商品をいつまでも陳列しておく訳にはいきません。

 従って、売れ残りがなく且つ「欲しい時に」、「欲しい商品だけが」、「欲しい量だけ」、加盟店舗に有るようにすることが、フランチャイズ本部が目指すべき姿になります(*)。

*最近はコンビニ店舗に無い商品でも「ネットで注文を受け付けて、店舗に商品を配送し、お客様が店舗に受け取りに来る。」というビジネスモデルもあります。これもやはり来店してもらうことがキーとなります。

2. ビジネス全体の関係者(社)と其々の関係を図で表現します

 コンビニ・ビジネス全体の関係図の例を次に示します。
画像

 時々、関係図の矢印線に行動ではなく、アウトプットを書いた図を見掛けますが、この段階でアウトプットを記入するのは早すぎます(不適切)。理由はアウトプットに注意が向き過ぎて、目的(機能)を探究するという非常に重要なことが疎かになる可能性が高いからです。

目的(機能)を探究した結果、現状のアウトプットを変えた方が良い場合もあり得ます

 「情報」に基づく関係性が見えにくいとしたら、既存の「機能」や「目的」はさらに見えにくいものです。システムの目的を推測する最良の方法は、そのシステムがどのように挙動するのかをしばらく見ることです(行動から推測される)。重要なのは、管理対象に影響を与える行動(Action)が分かる様にすることです。
アウトプット指向が強すぎると、本質(本来の目的等)から外れて行く可能性があります。

 当該企業内IT部門(IT部門がグループ会社の場合もあります)に所属する人なら、この程度の知識はあるはずですので、直ぐに作成出来るはずです。もし企業内IT部門にこの程度の知識が無いとしたら、それこそが問題です。

 これを作成する目的は、事業(ビジネス)全体においてコアとなるビジネス活動(ビジネス・オペレーション)を鳥瞰的に把握するためです。これにより、枝葉末節に入り込むことを防ぐことが出来ます。これをベースに事業(ビジネス)のライフサイクルをシステマティックにブレークダウンしていきます。
トップページに戻る


記事へブログ気持玉 / トラックバック / コメント


キーオペレーションを把握、確認する。

2017/03/11 07:38
 ビジネス全体の関係図を基にして、キーオペレーションを把握、確認します。

 当該企業外に価値を提供に関しては、コンビニ・ビジネスのKFS(Key Factor of Success)は売れ残りがなく且つお客様が、「欲しい時に、欲しい商品が、欲しい量、加盟店舗に有る」、ようにすることです。その為のキーオペレーションを前回の図「コンビニ・ビジネス全体の関係図」で確認していきます。

 例えば、下図の太線のチェーンがキーオペレーションの1例です。
画像


 この図からキーオペレーションは@加盟店が「お客様が欲しがる商品」をフランチャイズ本部に発注するAフランチャイズ本部が商社(卸)またはメーカーにお客様が欲しがる商品を過不足なく発注するBメーカーが商品を作るC物流会社が加盟店に発注商品を届ける等であり、各BPが間違いなく且つ効率良く連携することが生命線です。

 さらにマーケットを拡げる、マーケットで優位なポジションを得る、という意味で「店舗展開計画〜実施」もキーオペレーションの1つです。

 これらのキーオペレーションは各社が取り組んでいることであり、このキーオペレーションを徹底的に磨くことは当然ですが、他社と差別化するために、フランチャイズ本部が「お客様が欲しがる(コンペチターにない)商品をメーカーと共同開発する」ということもキーオペレーションの1つです。

 当該企業外に価値を提供して利益を上げるに関しては、加盟店と顧客間の「顧客に商品を販売する」、フランチャイズ本部と加盟店間の「販売情報を伝える」、「売れ筋商品に関する情報を伝える」、フランチャイズ本部と加盟店オーナー間の「ロイヤリティ等を請求する」、「ロイヤリティ等を支払う」がキーオペレーションです。

 必要な経営資源を調達に関しては、フランチャイズ本部と加盟店オーナー間の「フランチャイズ契約をする」、フランチャイズ本部と商社間、及びフランチャイズ本部とメーカー間の「取引契約をする」、フランチャイズ本部とメーカー間の「商品を共同開発する」とフランチャイズ本部と契約店長間の「雇用契約をする」等々がキーオペレーションになります。

 次にキーオペレーションをベースにして、現状BPRS(Business Process Relationship)と改善後のBPRSを作成します。
トップページに戻る

記事へブログ気持玉 / トラックバック / コメント


BPRSの主な成果物4つの具体例

2017/03/11 07:38
 キーオペレーションをベースにして、現状BPRS(Business Process Relationship)と改善後のBPRSを作成します。

 その前にBPRSの主な成果物4つの具体例を紹介しておきます。以後、総ての成果物はツール(*1)を利用して作成しています。
画像

*1 XupperU
*2 ビジネス・データをモデル化したものであり、これはビジネスにおける4つの管理対象(人、有形物、無形物、金)の相互依存・参照関係をダイアグラムで表現したものです。

 一番重要な成果物は、データ(テーブル)とプロセスの相互関係を分析するための成果物であるテーブルVsプロセス_マトリックス分析表(クロスリファレンス)です。なぜこれが一番重要かと言いますと、着目しているデータにアクセスする全てのプロセスが検索できるからです。これによりデータ(テーブル)を変更/追加/削除する場合、どのプロセスに影響を与える可能性があるかを漏れなく検討することが可能になります。

 また、あるプロセスを変更する場合、当該プロセスが追加/更新/削除するデータを参照しているプロセスへの影響を漏れなく検討することが可能になります。

 BP同士が直接関係を持っていなくても、データを介して思わぬ処で他のBPと間接的に関係していることがあります。これを把握する方法に、データ(テーブル)とプロセスの相互依存関係を検索(クロスリファレンス)するための、テーブルVsプロセスのマトリックス分析表があります。
成果物1 テーブルVsプロセス_マトリックス分析表(クロス・リファレンス)の例
画像

 次に、BPに関する仕様書(業務ルール記述書、ITプロセス仕様書など)を変更する場合、その仕様書を参照しているプロセスを漏れなく把握する必要があります。
成果物2 BP(人間作業プロセス,ITプロセス)と当該仕様書の検索結果の例
画像


 さらにBPを変更する場合、どの組織(人)にどんな影響を及ぼすのか、把握する必要があります。その助けになるのがBP Vs 組織_マトリックス分析表(クロスリファレンス)です。
成果物3 BP Vs 組織 マトリックス分析表(クロスリファレンス)の例
画像


 最後に、重要なドキュメントがどのBFD(Business operation Flow Diagram)で参照されているのか、把握する必要があります。
成果物4 各種ドキュメントを参照しているBFD検索結果の例
画像

トップページに戻る


記事へブログ気持玉 / トラックバック / コメント


BFD(Business operation Flow Diagram)を作成する

2017/03/11 07:37
 それではBPRSをシステマチックに展開していきます

 最初に、ビジネス全体関係図から得られたキーオペレーション基に、ビジネス全体の現状_最上位BFDを作成します。
現状_事業(ビジネス)全体BFDの例
画像

 これは下図BPRS階層構造における最上位BFDに該当します。
画像

 KFSの1つである「商品発注〜商品受領オペレーション」をダイアグラム化(BFD)します。
BFD商品発注〜商品受領の例
画像

 これは前掲のBPRS階層廣造における中間のBFDに該当します。

 この段階では、あまり正確である必要はありません。更に下の階層のBFDを調査した結果、当該BFDを変更する場合もあります。

 最下層のBPまで把握が済んだら、BFDのUp/Down双方向から、矛盾が無いか、漏れ・重複が無いか、検証し必要に応じて修正します。

 次に、「BFD商品発注〜商品受領」における【問題点及び検討課題】を把握します。
 各オペレーションを、誰がどうやって実行するのか、及びそのビジネスルール等を可視化するために、「現状調査シート」を使い“調査インタビュ−”を行います。

 「現状調査シート」を基に、当該主担当部門にインタビューを実施して、“「調査結果シート」店舗_商品発注”、“「調査結果シート」本部_商品発注”、“「調査結果シート」店舗_商品受領”を作成します。

     【現状調査結果シート】店舗_商品発注の例
画像


 各「調査結果シート」をBFD商品発注〜商品受領ダイアグラムにアイコン化リンク貼り付けします。
画像


 ツールを使用することにより、BFDのダイアグラムを入口として関係するドキュメントを直接参照することができます。BFDの階層(ブレークダウン)に応じて、同様に関係するドキュメントを直接参照することができます。

 これにより、以前記述した「ダイアグラムで表現すべき内容も、立場によって変わってきます。一般的に、経営者に近い人ほど、BPRSの表現は粗くても、全体を鳥瞰して、重要な箇所だけは詳しく分かる程度でよく、業務担当者に近い人ほど、自分に関係するBPRSに詳細な表現を求めます。

 マネージャーは上位に行くにしたがって広い範囲である程度集約された内容でよい傾向があります。これは経営者として、マネージャーとして、何を、どう管理/把握すべきかによって変わってきます。」に対応できます。

 商品発注〜商品受領オペレーションの一部である「店舗_商品発注」オペレーションをブレークダウンします。
       BFD店舗_商品発注の例
画像

トップページに戻る
記事へブログ気持玉 / トラックバック / コメント


問題点及び検討課題に対する【解決案(含仮説)】を作成する

2017/03/11 07:36
店舗_商品発注の【問題点及び検討課題】に対する【解決案(含仮説)】を作成します

 コンビニ・ビジネスのKFSであり、キーオペレーションの1つである「加盟店がフランチャイズ本部に商品を発注する時の、商品需要予測精度を向上させる」ために、ここだけは必ず、当該BP主担当部門の多忙なキーパーソンも企業内IT部門の人間と協力して、ここまでに作成したBFD、「調査結果シート」店舗_品発注、及び「問題点&検討課題シート」店舗_品発注を参照しながら、解決案(仮説を含む)を検討します

 ここで、どれだけ効果的で実現可能な解決案(仮説を含む)を出せるかが、まさしく当該主担当部門とIT部門の存在価値になります。特にIT部門はデータの視点から、そのための実現可能性及び施策を検討することになります。

例えば、解決案(仮説)として下記を検討したとします。
【解決案(含仮説)】店舗需要予測精度向上の例
画像


解決案(仮説)として大きく次の3つ挙げられています。
@商品別の販売速度を分析することにより売れ筋(死筋)商品の精度が向上するのではないか?
これは今後、所謂KPI(key performance indicator)に相当するものになる可能性があります
商品別_販売速度分析イメージの例
画像


A店舗立地環境を分類整理して、店舗分類と各店舗を紐付けると、店舗分類と商品の売れ筋(死筋)に相関関係があるのではないか?
店舗分類別_販売傾向分析イメージの例
画像


B店舗分類の違いと地域の違いをクロスさせると、売れ筋(死筋)の相関関係がもっと強くなるのではないか?

 次に、解決案(仮説)に基づき、加盟店がフランチャイズ本部に商品を発注する時の、商品需要予測精度を向上させる為の「具体的な解決策」について検討を行います。
トップページに戻る

記事へブログ気持玉 / トラックバック / コメント


具体的な解決策について検討する。

2017/03/11 07:35
 解決案(仮説)に基づき、加盟店がフランチャイズ本部に商品を発注する時の、商品需要予測精度を向上させる為の「具体的な解決策」について検討を行います

 解決策実現の為の新規または変更するBP(人間作業プロセスまたはITプロセス)を検討します。
●新規BP
従来のエリア別販売傾向分析に加えてフランチャイズ本部が、全加盟店の販売実績情報等をベースに、前記3つの解決案を基に「加盟店毎に発注商品と数量を推奨する」ことにします。
     新規BPに伴うBFDの例
画像

●変更BP
加盟(コンビニ)店舗の発注担当者は、商品発注時に、加盟店毎の本部推奨の商品と数量を参考にして商品を発注します。
     変更されたBPの例
画像


●追加ビジネスルール
追加されたビジネスルールとして、「店舗_分類ルール」、「店舗と店舗分類コードの対応付けルール」を作成したとします。
 これらを関係するBFDにアイコン化リンク貼り付けします。
画像

 ここから解決策実現の為の新規または変更するデータとそれに対するIT仕様を検討します。
解決策実現の為の新規または変更するデータとそれに対するIT仕様を検討します

 ここからはIT部門が得意な分野です。
 ここで大事なのは、BDM(ビジネス・データモデル)です。BDMを作成する目的は大きく2つ有ります。

 一つは、日常使うビジネス・データの構造を非IT部門の人にも、比較的分かり易く表現できます。そのため、IT部門の人と非IT部門の人が管理対象データについてコミュニケーションが取り易いことです。

 もう一つは、情報システムで実装される実際のデータ構造は採用するITインフラ(OS、ミドルウェア、ツール、ネットワーク等)及び要求されるRASISのレベルにより変わりますが、BDMはこれ等には影響されません。

 BDMをERD(Entity Relationship Diagram *1)を利用して表現することにします。ERDの表記方法には幾つかありますが、これ以降説明で使うERDの表記方法はツールのデフォルト表記です。

*1 ERDはRelational Databaseとの親和性が高いので、情報システムのデータベースとしてRelational Databaseを使う場合は、情報システム構築(実装)のための元情報として非常に利用価値が高いと言えます。詳しく知りたい方はこちら

(1)商品別_販売速度を分析するために必要となるBDMとITP(ITプロセス)仕様を検討します。
【商品別_販売速度を分析するために必要となる】BDMの例

画像

 BDMを基に、商品別_販売速度(アウトプット)データを得る為の算出ルールとITP仕様を検討します。
【商品別_販売速度算出】ルールの例
画像

【商品別_販売速度算出】ITP仕様の例
画像

 このITP仕様を基に新しいITPである新_商品別_販売速度算出でアクセスするテーブルとアクセスの関係を定義します。
【ITPと仕様書/テーブルアクセス(CURD)】関係定義の例
画像

(2)以下同様に、店舗分類別_販売傾向分析、店舗分類別_エリア別_販売傾向分析で必要となるBDMとITP仕様を検討します。
(3)同様に他のBPRSも作成して全体を完成させます。

トップページに戻る

記事へブログ気持玉 / トラックバック / コメント


非IT部門の人とは情報システム実装設計の世界の言葉で話をせずに、BPRSの成果物で会話する。

2017/03/11 07:34
他のBPRSも作成して全体を完成させます

 変更/追加/削除するBP及び変更/追加/削除するデータ(テーブル)を検討する場では、必ず関係するBPRSの(途中)成果物を使い他のBP/テーブルへの影響を検討するようにします

 例えば、商品別_販売速度を算出するITプロセスは、テーブルN_店舗在庫推移の在庫増(店舗において在庫計上)のタイミングによって、販売速度、販売ロス時間が影響を受けます。下表参照
画像

 商品別_販売速度、商品別_販売ロス時間の分析が店舗の需要予測精度向上に結びつく可能性があることが分かった場合、より精度を上げるためには、加盟店の店員が陳列棚に無い商品を実際に陳列棚に補充した時間が重要になります。しかし、これは店員への負荷増になりますので、省力化の手段を検討(投資?)する必要が出てくるかもしれません。

 業務プロセスやシステムを大きく変更する場合、全国で1万店以上ある全加盟店に一気に導入するのではなく、実験店(直営店等)で試行するのが一般的だと思われます。

 今のシステムの不具合は理解できても、どのようなシステムが実際にうまくいくかは簡単にはわからない。そんなときには現場に行って、実験したり、プロトタイプを創ってみる。システムの知恵というのは、現場で実際に動いてみることでずいぶんと明らかになる。(*)

* ドネラ・H・メドウズ『世界はシステムで動く』英治出版2015年

 今、流行の深層学習に基づくAIの神髄は、高速シミュレーション(実験)を圧倒的な回数行うことだと思います。ビジネスにおいて実験を行うためには、BP及びテーブルの変更/追加が現状のBP、テーブル相互にどのような影響を与えるか把握するのに時間が掛かるようでは、ビジネス競争に負けてしまいます。
事業(ビジネス)全体のBPRSを作成しておけば、直ぐにリソースに対する影響を把握することが可能です。

 また、実験(試行)に大きなコストが掛かるようでは、簡単に実験(試行)を繰り返すことが出来ません。事業(ビジネス)全体のBPRSを作成しておけば、実験(試行)に掛かるコスト見積の精度も向上します。

 BPRSの主な要成果物4つが完成すれば、後は情報システムの実装設計ですので、アウトソースが可能になります。(SIに発注する)

 情報システム完成後に、社内IT部門は実装データ(テーブル)Vs実装ITPのクロスリファレンスを把握・管理する必要があります(BDM、ITP仕様と実装設計のマッピングが必要)
画像

 事業部門の人達とシステムの変更(統廃合)について会話をする場合は、情報システム実装設計の世界の言葉で話をせずに、必ずBPRSの成果物で会話するようにします
 なぜなら、情報システム実装設計の世界は非IT部門の人達にとって非常に分かり難い世界であること。また、採用するITインフラ及び要求されるRASISのレベルによって情報システム実装設計が変化するためです。
トップページに戻る

記事へブログ気持玉 / トラックバック / コメント


月別リンク

生涯続学/BIGLOBEウェブリブログ
文字サイズ:       閉じる