メイン

ITシステム構築の極意 アーカイブ

2013年11月25日

イノベーションを支援するITシステム構築の極意

ちょっと前に「プロセス中心アプローチによるシステム構築の極意」というタイトルで記事を書くと宣言しましたが、How toやWhatも大事だが、結局Whyがしっかりしていないと目的にかなったものにならないわけで、上流の戦略的なところとの一貫性と連動性が担保されたものでないと意味がないのではないかと思い考え直しました。

ビジネスモデルを起点としてオペレーション、コントロールまでを体系立てて見ていくことが重要である。そこで改めて、「イノベーションを支援するITシステム構築の極意」と題して連載していくことにする。最近やたらとインベーションという言葉が使われているので躊躇してしまうのだが、大げさな技術革新といったものだけがイノベーションでもなく、ちょっとした気づきをアイデアにして差別化を図るなんてことでもよいとして進めていく。

一応、目次らしきものを作ったのでそれを提示します。これは現時点のものなので書いていくうちに変わる可能性があります。大きな流れとしては、ビジネスモデルからプロセスへ展開し、設計されたプロセスを実装して、それを使ってオペレーションするというものです。

【1】ビジネスモデルからプロセスへ
  1. 2つのイノベーションタイプ
  2. 4つの創造ステップ
  3. 6つのビジネス構造体
  4. 8つのビジネスモデル要素 *BMGより
  5. 10の提案価値     *BMGより
  6. 12の主要対応プロセス

【2】プロセス設計からシステム構築へ
  1. 3つのパラダイム変化
  2. 5つの誤解
  3. 7つの作法
  4. 9つの成功要因
  5. 11のサンプル

【3】システムオペレーションからコントロールへ
  1. 4つのオペレーションの心得
  2. 4つのコントロール指標


これまでのITシステムはどうしてもシステ開発というところに目がいってしまって、ビジネスが成功するためにどうあるべきかを見失っているのではないかという問題意識から記事を書こうと思っています。さて、うまくまとまるでしょうか。乞うご期待。
  

2013年12月 2日

イノベーションを支援するITシステム構築の極意(1)

-- はじめに --

企業は何らかの形で常に変化していかなくては生き残ることができない。また変化しなくてはいけないスピードがどんどん早くなってきている。それはビジネスを取り巻く環境がめまぐるしく変わっているからである。そして、変化も予測できるものから、不確実なものが増えてきていることがある。

変化はイノベイティブなものであればあるほど企業の体質を強化し持続的なものになっていく。逆にこれまで優良と思われていたような企業も変化対応をしくじるとあっという間に消えていってしまう恐ろしい時代でもある。ですから、企業はいかにして環境の変化を読み取り、素早く対応する組織能力をもったものにしてくことが大変重要なことなのである。

一方、IT技術の進展は目を見張るものがあり、毎年のようにあたらしい技術やサービスが登場してきている。しかも、個人で使うようなものがいつの間にか会社に中でも使われるように、個人的な生活と会社生活とのボーダーもだんだんと取り払われようとしている。特にインターネットは必要不可欠なインフラとして確固たる地位を築いている。もはや、顧客接点のところではインターネットなしでは成立しなくなってきている。

こうしたIT技術の高度化は企業の変化対応力を強化するための武器としては非常に強力なものになろう。しかしながら、ITを使いさえすればうまくいくという短絡的な考え方では失敗するのは目に見えている。ITはあくまで道具であるから、道具は使う人、使い方でいかようにも変わり得るのである。つまり、ITという道具をうまく使いこなすリテラシーを持たないとうまくいかない。むしろそちらのほうがより重要性を帯びてくる。

そして、これまでITを現場での効率化の道具として主に捉え現場まかせにしていた経営者は、これからは経営の道具として見直して行く必要がある。極端な話、経営方針や事業戦略らしきものもなしで経営していた時代もあったかもしれないが、そんな会社は存続すらできなくなる。であれば、経営方針や事業戦略、あるいは自分の経営者としての思いをどうやって実現させるかは経営者の最たるミッションであるはずだ。

経営者自らが経営システム、事業プロセス、業務オペレーションに関心をもち自らの手のひらに乗せて操ることが大切なことになってくる。そのためにも是非不断のイノベーションを実行していくのに適切な企業システムとは何のかを真剣に考えていくべきだろう。もちろん経営者のみならずミドルあるいは現場の人たちも一緒に考えてほしいと思う。

ただし、少し前提を理解しておいてください。企業システム全体というと最上流の経営理念、経営方針、戦略立案といった部分についてはここでは言及しません、また製造現場作業のようなものも含みません。つまり、経営戦略とKGI(Key Goal Indicator)は所与ものとしてありそれを受けてビジネスモデルを描くところから始めていきます。
  

2013年12月 9日

イノベーションを支援するITシステム構築の極意(2)

第1部 ビジネスモデルからプロセスへ

ここでイノベーションということを考えてみましょう。わが国では2006年7月に策定された「経済成長戦略大綱」において、 「イノベーション・スーパーハイウェイ構想」の構築を掲げられました。そこから各所でイノベーションという言葉が発せられ、こぞってイノベーション創出を志向しだしました。

この「イノベーション・スーパーハイウェイ構想」とは、「科学技術創造立国の実現に向けて、イノベーションを創出する仕組みを強化するため、(1)双方向の知の流れの円滑化、(2)異分野の融合、(3)出口(価値創造)との効果的なつながりの構築を推進するもの」となっています。そして、イノベーションの定義として、「単に「技術革新」と訳されることが多いが、技術革新に留まらず、広く経済活動全般において、新しい方法を取り入れて革新していくこと。経済学者のシュンペーターは、イノベーションの類型を次の5つとしている。《 新製品の開発、新生産方式の導入、新市場の開拓、新原料・新資源の開発、新組織の形成 》である」としています。

ただ、この説明を聞いて少し違和感というか物足りなさを感じざるを得ません。例えば、単なる技術革新に留まらずと言いながらも結局は革新的なことをすればいいのだというふうに読み取れるからである。ですから「科学技術創造立国」に実現に向けてという表現になるわけで、従来型日本のものつくりの延長でしかないように思えます。つまり、いいものを作れば売れるという品質至上主義から抜け出ていないのではないでしょうか。

シュンペーターがいうイノベーションとは「発明と市場との新結合」ということです。個別の開発や革新を言っているわけではなく、大事なのは市場との関係なのです。つまり、ちゃんと結果を出す、市場にダントツに受け入れられてこそ初めてイノベーションと呼べるのです。

とかくわが国の企業は市場との対話がうまくなく、プロダクトアウト型のやり方から脱皮できないない傾向があります。日の丸半導体がサムソンにしてやられたのは、マーケティングの重要性を軽視したとも言われています。ただ、このことは、国がああしろこうしろと言ったところでおいそれとできるわけではなく、経営者のセンスとか、事業責任者のマインドとか、研究開発の市場感覚とかいった企業自体の組織能力に依存するのだから、国としてはそういったアクティビティを阻害せずに、やりやすい環境を整えることが大事になるのでしょう。

従って、結果を出す仕組みまで作って初めてイノベーションを見届けることができるのです。新しいビジネスモデルを作っただけ、技術革新をしただけでは不十分です。ですから戦略からオペレーションまで一貫されていて、かつ連動していかなくてはいけません。多くの人が使ってくれて役に立つ、どんどんファンが増えるようなものを作ってこそ評価されるべきなのです。
  

2013年12月16日

イノベーションを支援するITシステム構築の極意(3)

1. 2つのイノベーションタイプ

イノベーションといってもどこの領域でイノベーションを起こすのかというのがあります。イノベーションの対象は何かということです。2つの対象があると考えます。

① プロダクト主導イノベーション
② ビジネスモデル主導イノベーション

プロダクトというのは、単に物理的なモノだけではなく、商品すなわち製品やサービスをいいます。画期的な商品が大きな市場を獲得して断トツの地位を占めることです。ただ、これが最初に言ったように全く新しい技術とかデバイスを使っていなくてはいけないということはありません。iPodの例を挙げるまでもなく、既存技術や既存部品を組み合わせて新しい製品をつくるのがよくあるイノベーションです。

サービスでも同じことが言えます。今までなかったようなサービスも大事ですが組み合わせたものとか、サービスの適用箇所が今までにない斬新なところだったりすることもイノベーションであると考えます。なんだそんなこと気が付かなったよというものであるかもしれません。

どちらかというと、プロダクトイノベーションのほうが発明という言葉から浮かぶイメージからイノベーションの主流だと感じられますが、ビジネスモデルのイノベーションも立派なイノベーションになります。古くはフェデックスだとかサウスウエスト航空、最近ではアマゾンとか、多くのネットビジネスなどビジネスモデルを変えることで他社との競争に勝利し、顧客を拡大しています。もう成熟したと思っていた市場でもまだ効果的なビジネスモデルが形成できることは決して少なくないように思えます。

この2つのタイプのイノベーションはそれぞれが独立してあるわけではなく、当然のように相互に絡み合っています。新規のプロダクトが開発されたらそのビジネスモデルも新しいものになるだろうし、ビジネスモデルを変革したら、製品コンセプトも少し変えようなんてこともおこります。要は、どちらが主導的な位置にいるかでアプローチの仕方が変わるわけです。

イノベーションを起こそうと言うことの大事な前提は既成の概念を取り払ってものごとを考えることだと思います。不連続の連続と言ってもいいかもしれませんが、できあがったものの延長にはイノベーションは待っていてくれないでしょう。それと、プロダクトであれ、ビジネスモデルであれ、これからのイノベーションは、顧客(個客)の視点、グローバル対応、ITの活用など従来にはなかった新たな考え方が重要になるのではないでしょうか。
  

2013年12月25日

イノベーションを支援するITシステム構築の極意(4)

2. 4つの創造ステップ

イノベーションには、プロダクト主導型のものとビジネスモデル主導型の2種類があるという指摘をしました。そのどちらにしても他のものと違った価値をもったものでなければいけません。プロダクト主導型であれば製品やサービスが従来なかったものであるとか、顧客が待ち望んでいたものだったとかいうものです。ビジネスでは、新しい顧客との関係だとか、考えつかなかったサービス提供の仕組みだったりとか、なるほどそういう手があったかというものでしょう。それを発見し作り出すには創造のプロセスが必要になります。そのステプは次のような4つのステプになります。

(1)ビジョンを描く (ウオンツ)
(2)アイデアを創出する(技術棚卸・フィールドワーク等の調査観察)
(3)コンセプトを生成する  (概念化、構造化)
(4)プロトタイピングデザインを行う (反復試作) 

これは。慶応大学の奥出直人教授の「デザイン思考の道具箱」からもってきたものです。デザインというとどうしても"モノ"の形状のデザインを思い浮かべがちですが、それだけではなく、"コト"や、ここで取り上げているビジネスモデルにも適用できるものだと考えています。新しく何かを生み出す時に使うプロセスというふうに捉えてみてはいかがでしょうか。

最初のビジョンは何のためにイノベーションを起こすのか、どうしたいから、どうなってほしいから、新たな価値を提供するのかというものです。ここは非常に重要なところで、最初の大きな方向を示すことです。これがしっかりしていないとあとでブレてしまうことにもなりかねないのです。ビジョンは顧客(サービス受給者)の立場になって「〜したい」というウオンツを表現します。

注意しなくてはいけないのが、あまり抽象的でもいけないし、さりとて細かく過ぎてもいけないということです。「人類の平和に貢献したい」なんて言われてもピンと来ないでしょうし、「今期の売上高を20%上げたい」なんていうのもビジョンではないですよね。ちなみにアップルのiPodの例で言えば「どこへでも自分の音楽を持ち歩いてもっと音楽を楽しみたい」です。

さらに注意しなければいけないのが、問題解決型ではないということです。つい、こういう問題、課題があるのでそれを解決するにはどうしたらいいのかと考えがちであるが、それだとデザインしようとする"モノ"や"コト"を矮小化してしまう可能性があります。例えば、問題は個人的なものであったり、本質からずれていたりすることも多いからです。

ただ、最初に設定したビジョンは金科玉条のものとして頑なに守らなくてはいけないかというとそうとも言えません。後の工程で現場を観察したり、プロトタイプを作ったりしているうちに変わる場合もあります。創造のプロセスでは杓子定規な進め方ではなくもっと柔軟なプロセスで行っていくのです。創造性はもともと枠をはめないところから出てくるわけですから自由に行きつ戻りつやっていけばよいと思います。
  

2014年1月 6日

イノベーションを支援するITシステム構築の極意(5)

創造のプロセスでは、ビジョンの描いたあとはアイデアを創出するステップにいきます。アイデアを創出するために必要な主なものは技術の棚卸しとフィールドワークです。わかりやすく言うと、ニーズとシーズの探索といったことになります。

アイデアはこんなことができる、あんなことがしたいというところから湧いてくることがあります。つまり、手持ちの技術やノウハウ、あるいは思いみたいなものも含めて供給サイドからの発想です。一方、現場に出てユーザと接することから思いつくこと、気がつくことがあります。直接これから使おうとしている人たちにインタビューすることもあるでしょうし、まだ曖昧なものならユーザの人たちの振る舞いや行動をつぶさに観察することからも生み出されることもあるでしょう。

どちらでなくてはいけないということはありません。両方とも必要であることは言うまでもありません。勝手な思い込みで、きっと使ってくれるだろうといって世に出しても誰も見向きもしれくれなかったとか、逆に、顧客第一主義と称して、お客さんの言うことを何でも聞いてそのまま作ったはいいが、環境が変わったりとか、要求を出した担当の人が辞めてしまったりするとそこで使われなくなったといったケースはよくあるのではないでしょうか。

ただ、イノベーションという面から考えると、シーズ志向の方に重心があるように思います。 ビジョンのところでも言ったように何々したいという思いが強くなくてはいけないわけで、そうなると創造したもので新たな市場・顧客を作り出すということまでしてしまうということが考えられるからです。おそらく真のイノベーションはこうしたプロダクトと市場・顧客の創出がセットになったものなのでしょう。

アイデアは、たくさん出すことが大事です。アイデアを出すには、ブレーンストーミングとかKJ法など多くの手法があると思いますが、思いついたことをポストイットなりホワイトボードなりに書き出すことがよいでしょう。ここでは、素晴らしいアイデアを出すことより、生半可なものでも単なる思いつきでもいいので数多くのアイデアを手当たり次第に吐き出すことが肝要です。

ここまでの工程でものになるようなアイデアはそうそう生まれてくるわけではありません。後工程でいろいろな議論や検討をしているうちに、ここで拾い上げたアイデアを思い出していけばよいのです。それとアイデアは単発ですごいものになるというよりも、複数のアイデアの組み合わせから新しいプロダクトやモデルが生成されるのが多いものです。
  

2014年1月17日

イノベーションを支援するITシステム構築の極意(6)

さて、アイデアが集まってきたら、それらを吟味しながらコンセプトを作成することになります。一般的に考えられるのは様々なアイデアを分類して、それらの類似性や従属性といったような関係性をみつめ、組み合わせを考えるといった方法になろうかと思います。点から面、立体に向かって推論しながら発想していくというやり方です。この時大事なのは、既成概念や過去の例に囚われないようにすることです。どうしても、ある枠組みに縛られてしまいそこから抜け出せないということがあります。固定観念は捨ててかかる必要があります。

しかしながら、実際の局面では、論理的な流れですんなりとコンセプトが作られるかというとそんなことはありません。おそらく、逆の流れ、すなわち最初に"ひらめき"があって、それを検証していくというスタイルが多いように思います。セレンディピティと呼ばれるような偶発的な発見に近い話です。

ただ、そうだからといって単に偶然を期待しても何も出てこないでしょう。必要なことは、概念化とか構造化といったスキルを磨くことではないでしょうか。この力がないとアイデアをコンセプトに落とし込むのが難しくなります。ある程度の抽象度で表現しなくては、様々な角度からの要請に応えられるものにはならないからです。

さて、コンセプトはアイデアをいくつか組み合わせて、具体的にどのような技術でそれが可能になるのかを検討したものになります。ビジョンを達成するための具体的な方法とその構造のことなのでです。そして、できあがったモノを前に人が「これは何?」と聞いた時ひと言で答えることができるものになります。たとえば例として、コンビニとiPodを取り上げてみます。

「小規模の他店舗システムを共通に運営する新しい経営にすることで、フランチャイズ制を使う」

「持っている全ての曲を持ち運べるカッコいいポータブル音楽プレイヤー」

また、できあがったコンセプトを評価することも大切です。作りっぱなしではなく、実際に多くの人に使ってもらえるような魅力的なものなのかどうかのチェックです。その評価ガイドラインをあげておきます。

(1) コンセプトの図を描いたときに、そこに人間が含まれているのか
(2) コンセプトをユーザが利用するときのコンテキストがきちんと描かれているのか
(3) 提示されているコンセプトはユーザのコンテキストに置いてみて、今まで存在していなかったものであるかどうか
(4) コンセプトが加わることで、コンテキストが魅力的になったかどうかを確認する
(5) コンテキストを明確にしてコンセプトを描く


2014年1月24日

イノベーションを支援するITシステム構築の極意(7)

さて、4つの創造のプロセスの最後はプロトタイピングデザインということです。日本語では"反復試作"という言い方をしようと思います。すなわち、試作を繰り返しながら最終成果物に近づけていきます。こうしたプロトタイプ思考は非常に重要なプラクティスになります。

よくプロトタイプは上司やクライアントを説得するためのものだと誤解している人がいますが、全く違って、作ることで考える=build to thinkというアプローチです。考えたらまず作ってみる。作ることで考え、作りながら考えるといことです。ですから、プロトタイプは素早くできないと意味がない。しかも早い段階で生焼けでもいいから作ってしまうことが大事なのです。

ここで大切なことは、既成の技術で作れるからという制約を意識しないことです。つまり、使うべき形、使えるような形をプロトタイプを作ることで思考して、それで作れるように技術を集めていくという順序なのです。そして、技術が追いつたらもっと安くていいものになったということなのです。こういうスタンスは、競争相手に先んじることができるし、ひいてはイノベーションにつながるはずです。

では、初期のプロトタイプで検証すべきことは何でしょうか。次の3点が大事になってきます。
・スケール感     どのくらいの大きさが適しているのか
・インタラクション  どのようなインタラクションがあるのか
・特徴のディテール  その形のアイデンティティ、オリジナリティに当たる部分は何か

有名なダイソンの掃除機や扇風機も何回も何回もプロトタイピングを行っています。その後もだんだん商品に近づけるようにいろいろな工夫をしたプロトタイピング(例えば映像にするとか)を繰り返します。昔は、この商品に近づくほど時間とコストがかかってしまっていましたが、最近では3Dプリンターや光造型機なども登場し、また、コンピューターや電子デバイスも安価に手に入るようになってきました。従って、プロトタイピングがますます重要性を帯びてくるでしょう。

この創造プロセスは、プロダクトやビジネスモデルを創出する場合について述べてきましたが、実はITシステムもプロダクトでもありサービスでもあるので創造プロセスの対象でもあるわけです。つまり、ビジョン→アイデア→コンセプト→プロトタイプという流れはITシステム開発にも適用すべきなのです。このことについてはあとの章で書いていきますので覚えておいてください。
  


2014年1月30日

イノベーションを支援するITシステム構築の極意(8)

さて、今回からはビジネスの構造体に入っていきます。前回までに創造のプロセスを議論してきました。ビジョンを描き、アイデアを創出し、コンセプトを作り、プロトタイプを行って、新しい製品やサービスを創造するプロセスです。こうした創造プロセスによって作られた商品をいかにして売るか、使ってもらえるかが非常に重要なこととなります。

日本のモノづくり現場で陥りやすいワナがいいものを作れば売れるという考え方であると指摘されるようになりました。それが過剰品質を産んだり、高コスト化を招いて中国をはじめとした国に製造拠点が移行してしまったのは周知の通りです。つまり、商品を作っただけで終わりでなくそれをいかに売るのかというビジネスモデルをきちんと構築しないといけないとうことです。

そうしたビジネスモデルはどういう構造をしているのか、どんな構成要素から成り立っているのかを検討するのがこの章の目的になります。そこで、提示するのが6つのビジネス構造体です、つぎのようになります。

(1) どこの誰に
(2) どういう関係で
(3) どんな商材を
(4) どのリソースを使って
(5) どのように提供して
(6) どうやって儲けるか

この6つの"ど"から成り立つモデルはビジネスを実行していく上で必須の要素になります。「どこの誰」というのは市場と顧客をどこに置くかということで、お客さんと「どういう関係」を築いて商品を販売するのか、そこに売るものは「どんな商材」なのか、そして多くの経営資源の中から「どのリソースを使って」ビジネスを動かすのか、商材をお客さんに「どのように提供して」いくのか、最終的には収益をあげなくてはいけないから「どうやって儲けるか」の仕組みを作るのです。

これが、わかりやすいビジネスモデルの定義です。ビジネスモデルというと、ついひところアメリカなどでビジネスモデル特許といった言われ方もされたように収益モデルという狭義の解釈がされがちですが、それだけではなく、製品やサービスの価値とか顧客やサプライヤーとの関係、サプラチェーンといったものを含んだ総合的なモデルとして捉えています。
  


2014年2月 6日

イノベーションを支援するITシステム構築の極意(9)

6つの"ど"で表されるモデルがビジネスモデルと言われるものですが、最近かなり普及して来たものにビジネスモデルジェネレーションあるいはビジネスモデルキャンバスというものがあります。翔泳社から本が出ていますのでその本に従ってみていきましょう。著者はアレックス・オスターワルダーとイヴ・ピニュールで、45ヶ国470人の事例に基づいて作られたフレームワークが肝になっています。

このフレームワークは9つの構成要素から成り立っていて、それらを描くことでビジネスモデルが構築できるというものです。とてもビジュアルなのでわかりやすいという利点があります。ただ、書くだけと言ってもその内容についてはかなり詳細な分析・検討が必要ですし、簡単ではありません。むしろそれを見ながらみなでディスカッションすることが大事になってきます。

それと重要なこととして、目的によって使い方も変わって来るということです。例えば、全くのゼロから起業する場合のビジネスモデルの検討の仕方と既存ビジネスをベースにしてビジネスモデルを変革してく場合ではアプローチ法とかフォーカスポイントが違ってきます。そのあたりは後々検討していくとしてまずは各要素についてみていきましょう。9つの要素 が配置されたビジネスモデルキャンバスは次の通りになります。


BMC.png
(1) CS (Customer Segments) 顧客セグメント
(2) VP (Value Proposition) 価値提案
(3) CH (Channels)    チャネル 
(4) CR (Customer Relationship)顧客との関係
(5) R$ (Revenue Streams)収益の流れ
(6) KR (Key Resource) リソース
(7) KA (Key Activity)主要活動
(8) KP (Key Partner)パートナー
(9) C$ (Cost Structure) コスト構造

前半の部分は顧客接点のところでいわば需要側の要素になります。後半部分は内部要件で供給側の要素ということが言えます。すなわち、どこのどんな顧客に対してどのような価値をどのようにして提供し収益を得るのかが、一つの図の中に書かれるということに意味があります。視覚的に全体を俯瞰できることは大事ですね。
  

2014年2月16日

イノベーションを支援するITシステム構築の極意(10)

ビジネスモデルの9つの構築ブロックをキャンバスに書き込むことを提案しました。これは、ビジネスモデル・ジェネレーション(BMG)という考え方をベースにして埋め込むものですが、どういうことを書くのかというのを概観してみます。実はこの方法論では、最初にあげた6の"ど"を書くことを推奨していますが、なぜそのまま使わないかという理由を探る意味でもおさらいしておく必要があるので見ていきます。

各ブロックの定義の順番はどこからでも構わないのですが、一応本に書いてある順番にします。最初は顧客セグメントです。顧客ニーズ、行動、態度によって、顧客をグループ化してセグメントに分けることが重要です。どのグループをターゲットにして、逆にどのグループを無視するのかを決めることになります。マーケティングでいうところのSTPのSですね。

この顧客セグメントの例があげられています。「マス市場」「ニッチ市場」「細分化」「多角化」「マルチサイドプラットフォーム」です。この中では最後のマルチサイドプラットフォームというのがわかりずらいかもしれません。複数の独立したセグメンテーションをもつケースになります。例としてはクレジットカードがあります。カード保有者とカード利用可能店という2つの顧客を持っているケースです。こうして、どういう市場・顧客を対象にするかを決めます。

次は価値提案です。価値提案とは、顧客の抱えている問題を解決し、ニーズを満たすもので、顧客がなぜその会社を選ぶかという理由になります。価値を生み出す製品とサービスと記述します。価値にはどんなものがあるのかは次章の「10の提案価値」で詳述します。

3番目はチャネルです。顧客セグメントとどうやってコミュニケーションし、価値を届けるのかを書きます。チャネルの機能としては、「企業の製品やサービスの認知度を上げる」「企業の価値を評価してもらう」「製品やサービスを購入できるようにする」「顧客に価値提案を届ける」「購入後のカスタマーサービスを提供する」というのがあります。それぞれはバリュー・チェーンプロセスの各フェーズ、すなわち、認知・評価・購入・提供・アフターサービスに対応しています。

さて4つ目は顧客との関係になります。企業が顧客セグメントとどういう関係を結ぶかです。いわゆる営業プロセスがここに含まれます。顧客獲得・顧客維持・販売拡大というステップを持った関係になります。こうした局面でどういう関係を築けば、スムーズに顧客獲得し、優良顧客化でき、販売が拡大できるかを記述します。

こうした顧客との関係はいくつかのカテゴリーに分けられます。「パーソナルアシスタンス」「専任のパーソナルアシスタンス」「セルフサービス」「自動サービス」「コミュニティ」「共創」などがあります。最初の2つは、顧客担当者のことで通常は営業とか相談員、コールセンターなどで後者はその顧客に専属でついてくれる場合になります。

最近増えているもの「コミュニティ」や「共創」というのがありますね。顧客同士のつながりを促進するためにユーザコミュニティを活用するとかが行われています。フェイスブックなどを利用する場合もあります。また、企業が顧客と一緒になって価値を創造しようという動きも出てきていて、アイデアを創出する段階やコンテンツを製作する時など様々な場でコラボレーションが進んでいます。
  

2014年2月23日

本が出ました

うちの社長とその仲間が著した本が刊行されました。「Webアプリエンジニア養成読本」という本で技術評論社からムック本形式で発売されています。共著者が石田絢一(uzulla)さん、すがわらまさのりさん、斉藤祐一郎さんの3人です。4人はほぼ同世代でそういった仲間の集まりで知り合い意気投合した人たちで、それぞれが同じことをやっているのではなく、活躍フィールドが違っているという。だから、コラボレーションできるかもしれませんね。

それと、ITの本というと案外狭い範囲を深く掘り下げるタイプが多いように思うのだが、全体を網羅していること、特にわりと忘れがちになる運用のところもきちんと書き込んであることが特徴的です。アマゾンの内容説明文によれば「Webアプリケーション開発の基礎を、前提知識、開発、デプロイ、運用の各フェーズに分けて解説し、全体像の体系的な理解を促すもの」であるようです。

社長は電子書籍も合わせると3冊目になるのですが、だいぶ本を書くことに慣れて来たみたいで、手際よく効率的なやり方になっているのがときどき進捗報告を受けると感じられます。また今回は共著ということで、それぞれのパートを齟齬がなくまとめることがむずかしいのですが、gihubを上手く使いながらスムーズに進行させていたのには感心させられた。これから、こうした書籍の出版に限らず働く場所は別々のでありながら、ネット上では一つのワークスペースで仕事をするというプロジェクトが当たり前になるかもしれませんね。

ということで、Webエンジニアにななりたいと思っている人、Webエンジニアを育てたいと思っている人、さらに現役のWebエンジニアの方々にお薦めですので是非手にしてはいかがでしょうか。トークイベントもありますのでそちらのほうもどうぞ。
  

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用...全体像を最新知識で最初から! ] (Software Design plus)
和田 裕介 石田 絢一 (uzulla) すがわら まさのり 斎藤 祐一郎
技術評論社
売り上げランキング: 466

  

2014年2月25日

イノベーションを支援するITシステム構築の極意(11)

ここまでは、市場とか顧客との関係を見てきましたが、つまり需要サイドのモデル要素ということができます。顧客との接点のところです。顧客に製品やサービスを提供してその対価を得るという部分でもあるわけで、そうしたお金の流れが「R$(Revenue Streams)収益の流れ」ということになります。よくこの流れの形をビジネスモデルと言う人もいましたが、これはビジネスモデルの構成要素である「収益モデル」というふうに規定したほうがよいでしょう。

収益の流れには異なる2つのタイプがあります。
1. 一見客による取引収益
2. 既存顧客への価値提案、もしくはカスタマーサポートによる継続支払いからなる二次収益

こうした収益の流れを生み出すための方法として下記のようなものが考えられます。
・ 資産価値のある商品の販売
・ 使用料
・ 購読料
・ レンタル/リース
・ ライセンス
・ 仲介手数料
・ 広告

そして、これらは異なった価格メカニズムを持っています。大きくは固定メニュー価格と変動価格があり、その中でも前者では「リスト価格」「製品特性に基づく価格」「顧客セグメントに基づく価格」「量に基づく価格」、後者には「交渉による価格」「利益率管理に基づく価格」「市場価格」「オークション」があります。

最近ではネット販売などの登場やフリーミアムといったような新しいモデルも生まれて多様な形態があり多くのアイデアが出てきています。その流れを顧客・代理店・仲介者・供給者といった関係を絵に描いておくのがわかりやすいと思います。そうした図解されたモデルとして、「ピクト図解」(板橋悟氏考案)というのがあります。8つの代表的なモデルが提案されています。
① シンプル物販モデル
② 小売モデル
③ 広告モデル
④ 合計モデル(ついで買いを狙う)
⑤ 二次利用モデル(商品を何度も再利用)
⑥ 消耗品モデル
⑦ 継続モデル(使用料や賃料)
⑧ マッチングモデル(仲介業)

こうしたものも参考にしながら自分たちのビジネスを記述したらよいでしょう。
  

2014年3月 3日

イノベーションを支援するITシステム構築の極意(12)

顧客接点つまり需要サイドのビジネスモデル要素のあとは、供給サイドのほうを見ていきます。最初は、ビジネスモデルを実行するに際して必要な経営資源です。いわゆる、ヒト・モノ・カネといったことになります。もう少し別な言い方をすると、物理的なリソース、人的リソース、ファイナンスリソースですが、そこに知的財産を加えるようになってきています。現代のビジネスではこの知的財産の重要性が増してきているように思います。

物理的なリソースは具体的には工場、ビル、車両、機械、システム、販売システム、流通ネットワークのようなものです。設備・インフラ・システムといったものがあげられます。最近では、ネットビジネスのように物理的なリソースをあまり持たないでもビジネスが始めるので参入がしやすくなっています。ただ、ネットビジネスだから物理的なリソースが大事ではないということはなくて、典型的な例ではアマゾンの物流システムは非常に大がかりでそこがキーポイントになっています。

これからますます重要性を帯びてくるのが情報システムではないでしょうか。ここの議論ではITシステムを構築するというゴールになっていますが、強いあるいは特徴的なITシステムがあるからこそ新しいビジネスができるとか、ビジネスモデルの変革にすぐに対応できるとかといったことが可能になるように思います。ですから、重要な経営資源であると言えそうです。

人的リソースでは文字通り人材ということになりますが、少し拡げて組織とか人脈といったものも含んで考えてみたらどうでしょうか。人といっても企業では組織活動という形でパワーが発揮されますので、個人のスキルを効果的に集合できる組織能力は大きな経営資源だと思います。また、中小企業など企業間連携が必要になってくるケースも増えてきています。そんな時に、社長同士のつながりとか、技術者同士の交流とかが強みになることもあります。

企業は何だかんだといっても最終的には資金的な問題が大きくなります。時には一時的な運転資金や多額の設備投資が必要になったりします。そうした資金の保有や調達が可能なファイナンスリソースも重要なものになっています。その場合、自力で出来ることもあるかもしれませんが、他力に頼るには信用力も問われてきますので、信頼される経営というものも間接的な経営資源の一つかもしれません。

知的財産には、ブランドや知的所有権、特許や著作権、パートナーシップ、顧客データベースなどがありますが、最初に言いましたように重要性が増してきています。差別化要素や競争優位性を知的財産として管理することも大事です。ただ、今日のようにすぐに真似られてしまうということとか、変化が激しい場合にどう管理するかは難しくなっています。最近のオープン化の流れの中ではかえって閉じた形で管理しない方がよいなんてケースもあり柔軟な対応が必要になってきます。ただ言えることは、長い時間の中で優れた組織文化のもと醸成されたようなブランドや知的財産はすぐには真似されることもないし、変化対応ができやすいものであることは間違いないと思う。
  

2014年3月10日

イノベーションを支援するITシステム構築の極意(13)

企業が経営を成功させるためにやらなければならない重要なアクションが主要活動です。BMGでは主要活動をたった3つの種類に分類しています。それは、「製造」「問題解決」「プラットフォーム/ネットワーク」の3つです。製造はいわゆる設計・製作・配送というサプライチェーンで、Dellなんかは大事な主要活動になります。問題解決はコンサルティング会社とか病院などのサービス産業が典型的な活動です。

プラットフォーム/ネットワークというのはちょっとわかりにくいかもしれません。ネットワーク、マッチメイキングのプラットフォーム、ソフトウエアやブランドはプラットフォームとして機能を果たしています。このプラットフォームを管理、サービス供給、プラットフォームプロモーションといったものが主要活動になるわけです。最初の方の顧客との関係でマルチサイドプラットフォームということでクレジット会社の例を示しましたが、こうしたビジネスではプラットフォーム管理が主要活動となります。他ではeBayとかマイクロソフトなどがあげられます。

こうしてスパっと分けられとなるほどと思うのですが、ただちょっとひっかかるものがあります。製造だって顧客の抱える問題を解決する手段でもあるわけですし、プラットフォームだってサプライチェーンを支えるインフラともとれるからです。要するに、大雑把にいえば主要活動というのは、顧客の要求に応えるサービスを提供する活動で、しかもその活動のベースがプロセスであると考えると、バリューチェーン、もっと絞ってサプライチェーンという括りで構わないように思います。

そのサプライチェーンの中で調達という機能がありますが、そこでは他のサプライヤーとのパートナーシップのもとに原材料、部品、技術、人材などを調達してきます。また、アウトソーシングなどもパートナーシップの一つでしょう。なお、パートナーシップを分類は次のとおりになります。

1. 非競合企業による戦略的アライアンス
2. 競合企業との戦略的なパートナーシップ
3. 新規事業立ち上げのためのジョイントベンチャー
4. 確実な供給を実現するためのバイヤー・サプライヤーの関係

さらにパートナーシップを作るための動機には次の3つがあります。
・ 最適化と規模の経済
・ リスクと不確実性の低減
・ リソースと活動の獲得

最近では、1社だけでなにもかも完結させることは大変難しくなっていて、様々な分野で何らかのパートナーシップを結んでいます。しかも、従来型の下請け的な垂直分業も減り、対等のパートナーシップである水平分業も盛んになっています。さらに、オープンな関係を持った複数の企業間連携も増えてきています。今後はWin-Winの関係が生じるパートナーシップが重要となるでしょう。

さて最後は、コスト構造です。どこでどんなコストが生じるのかを記述しますが、ビジネスモデルには大きくコスト主導型か価値主導型かがあります。すなわち、コストを最小化することが重要なモデルと、コストにそれほど注意をせずに価値を生み出すことに集中するパターンです。ビジネスモデルの成功要因からどちらを選択するのかを決めて行くことになります。コスト主導のビジネスモデルは結局は消耗戦になってしまい限界があるので最近は減っているように思います。
  


2014年3月17日

イノベーションを支援するITシステム構築の極意(14)

8つのビジネスモデル構成要素が終わったのですが、つぎの10の提案価値に行く前に、実際にビジネスモデルの検討を行う場合に使うビジネスモデル構成要素について考えてみます。つぎのような考え方をとったほうがわかりやすいように思います。

(1) 商品
(2) 市場・顧客
(3) 顧客との関係
(4) サプライチェーン
(5) サプライヤーとの関係
(6) コスト構造
(7) 収益モデル
(8) 経営資源

ビジネスモデル・ジェネレーション(BMG)との違いは、価値提案を商品としていること、チャネルを顧客との関係の中に包含させたこと、活動をサプライチェーンとしたこと、パートナーとの関係をサプライヤーとの関係にしたことです。それと、列挙しただけではわかりませんが、リソースすなわち経営資源は全体にかかるようにしています。

なぜそのまま使わないのかという理由がいくつかありあります。まず、価値提案というのを商品というふうにしていますが、BMGでも製品・サービスのことだと言っているので、素直に商品=製品とサービスというので構わないと思うからです。それと、価値提案は商品だけにあるとは限らないわけだから、本来はビジネスモデル要素の全部にありえるから、モデルとは違った次元の定義になるのではないでしょうか。

次に活動をサプライチェーンとしたのは、BMGでは活動には「製造」「問題解決」「プラットフォーム/ネットワーク」の3つしかないと言っていますが、この3つを眺めると、同じ土俵のものとは思えないところがあります。例えば、問題解決のための手段として製造があるわけですし、商品開発のような仮説検証型の活動だってあるあります。プラットフォームもそれ自体というよりそこから発せられるサービス提供が活動になるわけです。ですから、素直にサービス提供の仕組みなのかという意味でサプライチェーンという言い方で構わないと思うのです。

つまり、商品があって、需要サイドである市場・顧客と顧客との関係、供給サイドであるサプライチェーンとサプライヤーとの関係がベースの構成になります。まずはここの関係を基本として、そのビジネスを行うときの需要サイドにおける収益モデル(収入)と供給サイドにおけるコスト構造(支出)があり、それぞれの構成を成立させるための経営資源は何を使うのかということになります。こうしてシンプルな構成にしたほうがわかりやすいのではないでしょうか。
  

2014年3月31日

イノベーションを支援するITシステム構築の極意(15)

次は、10の提案価値ということになります。ビジネスモデルというのは最終的には顧客に対してどういう価値を提供するのかということになります。逆に言えば、顧客は自分が欲する価値を提供してくれる製品やサービスまたその提供者を選択するわけです。BMGでは次のような10の価値を提案しています。ではそれぞれを簡単に見ていきましょう。

(1) 新奇性
「新規性」ではありません。つまり単に新しければよいということではないのです。そのニーズを満たすものがなかったため、顧客自身さえ気づいていなかった新しいニーズを満たすものです。
(2) パフォーマンス
製品やサービスのパフォーマンスを上げて価値を生み出すことです。最速の処理スピードをもったコンピュータといったものです。ただ、これは製品やサービスだけではなく、圧倒的に短い納期なんていうのも価値となるでしょう。
(3) カスタマイゼーション
個人や顧客セグメントが抱える特定のニーズに合わせて、製品やサービスをカスタマイズすることで価値を生むことです。最近、受注設計生産や試作といったニーズが増えているように思います。これもカスタマイゼーションですね。
(4) 仕事を終わらせる
ちょっとわかりづらい表現ですが、顧客の抱えている仕事を手伝うことで価値を生み出すことです。例えば販売して終わりではなく、その後のメンテナンスも請け負うといった形で、アウトソーシングのようなものです。
(5) デザイン
優れたデザインにより差別化することです。単に機能的に優れているだけでは製品は売れない場合もあります。見た目のきれいさとか、機能美のようなものは今や非常に大事な要素となっています。アップル製品とかダイソンのデザイン性は有名ですね。
(6) 価格
低価格はよくある価値だといえます。やはり多くの顧客は安価なものを求めるものです。逆に価格を高くするという戦略もないことはないでしょう。ブランドに近い意味になります。今では、更に進んで無料提供の流れも広がっています。
(7) コスト削減
顧客のコスト削減に寄与することで価値を生み出すこともあります。最近の例でいうと、クラウドサービスなんかそうかもしれませんね。ITの「運用コストを格段に下げることに寄与しています。
(8) リスクの低減
商品やサービスの購入時に顧客が被るリスクを減らすことによる価値です。中古車の1年サービス保証とかITサービスレベルの保証といったものがこれにあたります。
(9) アクセスしやすさ
これまで製品やサービスを購入できなかった顧客にも利用できるようにすることで価値を生み出す方法です。例えば、大きな投資を分割して少額の商品にし買いやすくするといったことです。
(10)快適さ/使いやすさ
製品をより快適に使いやすくすることは大きな勝ちになります。iPodとiTunesの組み合わせで非常に使いやすい音楽プレーヤーになった例などはまさにこれです。

(注)BMGにはもうひとつブランドというのがあります。ただ、ブランドというのは長い時間で確立されるものだから、起業した時などは価値にはなりませんし、商品提供側から見るとブランドというのは経営資源の一つだとしたほうがよいので外してあります。
  

2014年4月 7日

イノベーションを支援するITシステム構築の極意(16)

ビジネスモデルを書いて、お客さんにどんな価値提案をするのか、別な言い方をするとどのように差別化され、競争優位性をもたせた製品やサービスを提供するのかが決まると、それをどう実現していくかに移っていきます。PDCAで言うと、こうしたいというPlanがビジネスモデルとして表現されますが、次のDoをどうするかになります。

ビジネスモデルは静的で構造的な側面をもったものですが、実行ということになると動的で流動的な側面を持ったものになります。すなわち、プロセスへの展開が必要になってきます。往々にしてビジネスの実行はプロセスをオペレーションすることで成果を出すからです。ビジネスモデルで導出された課題であるビジネス要求を受けるものとしてプロセスが存在するわけです。

さて、ビジネスモデルの構成要素は、それぞれで背後にプロセスを持っています。その対応を見ていきましょう。

(1) 商品          ・・・商品企画、商品開発
(2) 市場・顧客       ・・・顧客獲得
(3) 顧客との関係      ・・・商談・見積、アフターサービス
(4) サプライチェーン    ・・・受注、出荷、設計、製造
(5) パートナーとの関係   ・・・調達
(6) コスト構造       ・・・(全体)
(7) 収益モデル       ・・・代金回収・支払
(8) 経営資源        ・・・リソース管理

ということで、ビジネスモデルと関係する12の主要なプロセスが選択されてきました。ビジネスモデルで提供商品としてのコンセプトができたら、それを実際に企画して開発するプロセスへと展開されるわけです。

市場や顧客ではセグメンテーションやターゲッティングにより絞られた顧客に向かってプロモーションをしたりして顧客を獲得します。さらに顧客は潜在顧客から見込み顧客化し、受注をもらう顧客となり、リピートオーダーが来るような優良顧客へと進化させます。また、最近ではただ売ればいいというのではなく、買ってもらったあとのアフターサービスで顧客との結びつきを強くすることも大事になってきています。

次は、供給サイドのビジネスモデル要素として、サプライチェーンやパートナーとの関係がありますが、それらは基本的にはサプライチェーンプロセス、すなわち、受注出荷、調達、設計、製造というプロセスが関連付けられます。パートナーとの関係では主に調達プロセスが関係します。パートナーもひところのような元請け下請けのような垂直関係もありますが、今は分業的な水平関係も増えてきました。また、単に物品の調達にとどまらずに、技術、ノウハウなどのソフト面でのパートナーシップも盛んです。

これ以外のコスト構造、収益モデル、経営資源というのはプロセス的な意味合いが薄いものです。しいてあげれば、お金の流れのところになりますが、日常のオペレーションも少なく、最初にどういうフォーメーションにするかが重要になります。また、経営資源については、個別リソース管理の仕組みが必要になります。要するにマスタ管理です。ですから、プロセス管理というよりもデータ管理の色彩が強くなります。
  
これで、第1章の「ビジネスモデルからプロセスへ」を終わります。次回からは第2章の「プロセス設計からシステム構築へ」に入っていきます。ビジネスモデルを記述し、そこにあるビジネス要求をどのプロセスへ展開していくのかまでを議論してきましたが、次はそのビジネス要求をプロセスがどのように受けて実際に動かせるものを作っていくかになります。
  


2014年4月30日

イノベーションを支援するITシステム構築の極意(17)

さて、今回からは第2章の「プロセス設計からシステム構築へ」に入っていきます。最初のテーマは3つのパラダイム変化ということになります。コンピュータが登場して、それらが業務システムに使われて長い時間が経過してきましたが、それほど大きな変化はなかったように思います。

しかしながらビジネス環境もさることながら、インターネットの出現が非常に大きなインパクトを与えています。そうした中で、ITシステムを取り巻くパラダイムも変化せざるを得なくなってきています。技術の進化がシステムの構造あるいは作り方、使い方を変えていくのです。それらは次のような3つのパラダイム変化ではないでしょうか。

(1) データ・機能中心からプロセス中心へ
(2) 作って終わりから使ってナンボへ
(3) 個人作業からチームワークへ

最初のプロセス中心への転換ですが、元来ITは情報処理と言われるようにインプットされたデータを計算処理してアウトプットとして結果を出し、それをストアするというものでした。従って、データを中心として考えられ、その入力画面の機能をどうするのか、どんなレイアウトの帳票を出力するのかといった観点でシステムが作られていました。

ところが、現実のビジネスの世界ではそれだけで成り立っているわけではけっしてなく、むしろデータの処理以外のところのほうが時間をとっているし、重要なことが多いはずです。その世界はどちらかと言うと属人的でインフォーマルな領域になっていたわけです。タバコ部屋で大事なことが決まっていると揶揄されたものです。

いまや隠すことは許されないことも多くなりオープン性へのシフトが進んでいます。つまり、情報共有とかコミュニケーション、あるいはWebで言われるような集合知といった考えが広く取り入れられるようにもなってきました。タバコ部屋で行われていた意思決定が表に引きずり出されてきたのです。

そうした動きに不可欠なものがプロセスになります。ビジネス上で発生する様々な事案はほとんどの場合プロセスを経て処理されて行きます。従って、システム作りも従来のようなデータ・機能中心からプロセスへ中心へと変えて行く必要があります。

ただ、こういうとデータやUIはどうでもいいのかとか思われがちですがけっしてそういうことではありません。どれもが重要なのですが、軸足をずらすというか、何を先行して考えるかでプロセスを中心に、あるいはプロセスを先行して考えていくというアプローチを推奨しています。
  

2014年5月12日

イノベーションを支援するITシステム構築の極意(18)

3つのパラダイム変化の2番目の「作って終わりから使ってナンボへ」というのは、システム構築のゴールはどこかという話になります。つまり、作ることがゴールではなく、動かしてみて、もっと言えば成果を上げた時点がゴールですよと言っているのです。こんなことは至極当たり前だと思われるかもしれませんが、存外そうなっていない例を多くみかけます。

なぜそうなってしまったのかは、ユーザとITベンダーやSIerとの関係に見ることができます。ユーザはITのことがわからないからといってこんなものが作りたいと言っただけでITベンダーやSIerに丸投げします。特に一昔前の経営者は最初からITを遠ざけている人が多かった。また、ITベンダーやSIerはあいまいな要求仕様のままプログラム仕様書を書き、プログラマーに丸投げします。無責任連鎖です。

さて開発会社はそうやってできたシステムはこれだけ人月を要したのでそれに見合う費用を請求して受け取るわけです。だから、開発会社は極端な話その時点で仕事は終わります。ITベンダーもSIerも同様にユーザに対して言われたことをやりましたと言って、"プログラムが正常に動くこと"を確認して検収してもらうことになります。

これってどこかおかしいと思いませんか。ITベンダーやSIerにしても受託した開発会社にしても「作ってナンボ」と考えているわけです。そうした成果物を使いだしたユーザは使おうと思ったら使えないとか、使い出すとこう変えたいとかいったことが出てくるがもうどうしようもない。というわけで、半数以上のシステムが使うことなく眠ってしまっているのだ。

ユーザにとってのゴールは、当然のようにビジネス上の成果が出ることである。そのために大きな投資をしているのである。ではどうしたら、使って役に立ったというところまできちんと確認して終わりとなるシステム作りができるようになるのでしょうか。もちろん意識の持ち方もあるだろうし、契約の問題もあるでしょうが、大きいのは開発方法とか体制の問題だと思います。

つまり、ウオータフォールのようなフェーズドアプローチだとフェーズ間の受け渡しがうまくいかないとか、できあがりイメージがつかめない中でユーザが要求仕様を出していかなくてはいけないといった問題がどうしてもおきてくるから、そこから変えていく必要があります。

こうした問題を解決するには、いきつ戻りつでき、早い段階である程度動くものをみせていく反復型のやり方にするとともに、そこにユーザが参画してIT技術者と一体になって進めていくのが必須になってきます。こうすれば、ユーザーが真に欲しいものが具体的イメージとして出てきてそれをブラッシュアップしていくのでできた時は必ず使いものになるシステムになっているわけです。

こうしたやり方を前提として、使い手側も作り手側も意識を変革し、難しいかもしれませんが、契約形態も受託開発ではなく成功報酬に近いようなものにしていけばよいのではないでしょうか。そのくらいのことをしないとイノベーションを支援することはできないと思います。
  

2014年5月29日

イノベーションを支援するITシステム構築の極意(19)

さて、3番目の「個人作業からチームワークへ」というのをみていきましょう。仕事というものは、特に会社の中で行われるものはほとんどが全く個人で独立してやるものではなく、複数の人間が関わって行われます。だからこそ、会社には組織というものがあるわけです。

最近ではネットが発達したから組織に属さないノマドワーカーなんていう人種も現れてきていますが、彼らだって、というより彼らこそチームで仕事をやっています。ただ、それはルーティンワークというのではなくプロジェクト的な動きにはなっていますが、より密な関係性を維持することが重要になっているように思います。

むしろ、企業の中のほうが個人的な振る舞いが多いのではないでしょうか。昔はそういった状況をよく見かけました。サラリーマンでも職人的な人が多かったのです。しかしながらいまだに変わっていない会社も少なからずあるのではないでしょうか。

ですから、業務にITが入り込んできた時、そうした個人の仕事を助けることが目的になっていました。すなわち、個人の仕事、作業が楽になるように機械が代わりにやってあげるというためのツールがITというわけです。従って、そろばんをはじく代わりに数字を打てば計算してくれるものでした。そこでの必要な機能は早く、正確に、大量に処理することです。

ところが、これだけ年月も経るとそうした処理マシンとしてのITはかなり行き渡りました。では普及した結果どうなったのでしょうか。みな仕事をITがやってくれていますか。どうも、ある程度は自動化も進み、生産性も上がってきたとは思いますが、ITでできない仕事がまだまだあるのが現状ではないでしょうか。残った仕事はどんなものなのか、おそらく個人のルーティンワークではないようですね。

非定型で複数の人が関係して進めていくような仕事が残ったように思えます。これは、実は昔は「タバコ部屋」で行われたものです。たばこを吸いながら関係する人たちが"摺り合わせ"てものごとを決めていたのです。これは、インフォーマルの世界ですから、表に出てこないのでごく一部の人だけが知っているというクローズしたものになってしまっていました。

これからは、こうした隠れた意思決定を表に出して、組織の皆が知った上で仕事を進めていくオープンなものにしていく必要があります。そのために、ITはどう使ったらいいのかを真剣に考えていかなくてはいけません。つまり、チームとしてコラボレーションを行いながら進めていくイメージです。まさに、個人作業からチームワークへの転換が重要なパラダイムになるのです。
  

2014年6月12日

イノベーションを支援するITシステム構築の極意(20)

さて、ここまで3つのパラダイム変化である「データ・機能中心からプロセス中心へ」「作って終わりから動かしてナンボへ」「個人作業からチームワークへ」ということを説明してきました。ただ、変わるというと全面的に移行しなくてはいけないように思われがちですが、"軸足を移す"といったくらいに受け止めてください。

次の議論はそのことにも関係するのですが、「5つの誤解」です。次のようなものになります。

(1) プロセス志向アプローチはどこにでも適用すべきだ
(2) IT化、自動化を目指す
(3) 新たな業務プロセスを開発する
(4) データや機能は重要ではない
(5) ワークフローのことである

では、まずは最初の「プロセス志向アプローチはどこにでも適用すべきだ」という誤解についてです。どういったアプローチにしろ、データ、機能、プロセスはみな必要です。ここで機能というのがわかりづらいかもしれませんが、まあざっくり言うとユーザインターフェースと考えてください。

プロセス志向アプローチは"プロセスを中心にして"みていきましょうという主張です。中心ということは先行してと言い換えてもかまいません。つまり、最初にプロセスを考えましょうということで、その後にデータだとか機能を考えるというやり方です。こうしたやり方がどこにでも通用するのかというとそうではないというのはお分かりになると思います。

データや機能を中心にしたアプローチは従来のITシステムでよくやられていたものです。画面とか帳票をベースにして、そこに登録・検索・出力といった機能を作るというものです。販売実績とか出荷実績といったデータを入力するとか、リソース系のデータ、商品、顧客、取引先、従業員といったものを管理するためのDRUD画面です。

確かに、こうしたシステムはもちろんバックヤードには必須ですし、それがないと決算出来ないわけです。ただ、単純なデータの出し入れですからプロセスはないのです。こうしたシステムがなぜか"基幹システム"と呼ばれて、ITシステムの本丸であるように捉えられていました。そこを考えなおそうというのがプロセス志向の問題提起なのです。

だから、こうしたデータの出し入れだけで済んでしまうような領域にはプロセス志向はなじまないのです。では、それ以外の領域はどういったところなのでしょうか。最も典型のところが「顧客接点」です。お客さんのさまざまなサービス要求に応えるところです。ここは単なるデータベースアプリケーションではうまくいきません。なぜならば、登録するデータを生成するまでが大事だからです。データを生成する過程がプロセスといえます。

このように適用する領域によってプロセス中心で考えるのか、それともデータを主体としてシステムを構築したほうがいいのかをきちんと見極めることが重要なのです。やみくもにデータ志向だプロセス志向だと一方に偏らないようにしたいものだ。
  

2014年6月24日

イノベーションを支援するITシステム構築の極意(21)

5つの誤解の2つ目は「IT化、自動化を目指す」です。プロセス設計からシステム構築へ向かうときに、何がなんでもITを使ってシステムを作るということは少ないかもしれませんが、大方の人はプロセス設計の段階においてもIT化してそれを自動的に動かすということを頭に浮かべているのではないでしょうか。

それはそうかもしれませんね。ITシステム構築プロジェクトだからどうしてもそういう態度になってしまいます。しかし、一旦そうした頭を空にしてみたらいかがでしょうか。つまり、プロセスを描くときに自分たちの業務の流れをITを使っていようがいまいが関係なしに書いてみることです。

実はこのことはプロセスの本質的な意味合いを理解する上で大事なことだと思います。よく現状の業務フローを書いてくださいというと端末画面が出てきてそれを使ってフローが進む図を書きます。画面の遷移で業務を進めているフローになっています。こうした書き方をやめたらどうかと言っているわけです。あるいは申請・承認フローを描くことも多いでしょう。

ただ、前回に議論したようにバックヤードシステムではこうした業務フローになっています。プロセス的な要素が少ない領域ではあり得ることです。しかしながら、そうではない顧客接点プロセスといった領域では、端末の画面が出てくるようなフローを書くのは避けたいものです。

それと、次回にも議論になるかと思いますが、どこの会社でも必ず業務プロセスはあるわけです。IT化されてないものはプロセスではないと誤解している人が、「IT化、自動化を目指す」間違いを犯すのではないでしょうか。コンピュータがない時代でもビジネスをやっていたし、業務プロセスはあったのです。いまでも、ITをそろばんとして使っている会社がいっぱいあります。人手で業務を回していてもそこにはプロセスがあるのです。

ですから、プロセス設計はITとは無関係に設計すべきなのです。つまり、どういう意思決定をして、どういう判断をして依頼者に応答していくか、そのために必要な作業はどんなことでどういう手順でやっていくのかを定義してくわけですが、それはITとかは関係ないのです。そうして設計されたプロセスをオペレーションしていくにはITを使ったほうが良いのかを吟味すればいいのです。

もしITが使えないようなところ、あるいはわざわざITを使う必要がなければ人間がやればいいのです。また、自動化も無理してやることもないわけで、自動化というのは一見良さそうだが、自動化のロジックを一生懸命考える割にはそれだけの効果がない場合もありますし、例外が起きた時の影響などを考えると慎重にやるべきだと思うのです。「IT化、自動化を目指す」のもいいけれど適材適所でやるべきなのです。
  

2014年7月 4日

イノベーションを支援するITシステム構築の極意(22)

次なる誤解は「新たな業務プロセスを開発する」ということになりますが、誤解が誤解を生むかもしれないので少し注意が必要です。というのは、新たな業務プロセスを全く開発しないのかというとそんなことはなくて、場合によっては開発することもあるからです。

ここであえてこういう表現をしたのは、最初から新しいプロセスをつくり上げるのだと意気込まないほうがよいという警鐘をならしたかったからです。業務システム構築のプロジェクトが発足すると、IT化されていない部分がプロセスがないかのように錯覚して、そこが問題だと言わんばかりに新業務システムを開発するのだということになる。

ただ、最初に言ったように結果的には新たなプロセスにはなるのだが、順序が逆なのです。つまり、AsIsとかToBeというのをあまり意識せずに素直に業務プロセスを記述することから始めたらどうだろうか。なぜなら、業務プロセスというのは、ビジネスをやっている以上必ず存在するもので、意識、無意識に関わらず日々プロセスを回しているのです。

それは、マクロレベルのプロセスを見ればわかると思いますが、会社の大小、業種・業態に関係なしに共通的なもので、例えば販売、購買、受注出荷、生産なんていうプロセスは同じプロセスです。ですから、それをIT化しているから高度なプロセスであるというのも一概には言えないわけです。ホワイトボードとメールで仕事していても良いプロセスということだってありえます。

システム化のアプローチとして、最初に新しい業務プロセスを開発するのを目的化するのではなく、あくまで、自分たちのビジネスをオペレーションするためにはどんなプロセスになっているのがよいのかの観点でプロセスを記述することです。そこから、さまざまな問題が浮かび上がってきます。

個人の裁量で進めていたり、お客さんを無視して自分たちの都合だけで処理していたり、時間がかかっても平気だったり、ルールに従わなかったりといったプロセスの仕組みというより、プロセスを進めるための仕掛けのところの不備だとかが問題になってくる。こうしたプロセス管理に不可欠な組織能力をどう醸成していくかが大きいような気がします。

広義の意味ではこれもプロセスとも言えるのですが、フロー的な部分よりもこちらのほうが開発要素が多くあるのではないでしょうか。例えば多く見受けられるのはルールの欠如と役割の不明確です。このことは、別な言い方だと業務フローを変えるのが業務プロセスを開発することだとは必ずしも言えないのです。ルールがない中で業務フローを変えても意味がないのです。今回はプロセスとはが頭に入っていないとちょっとわかりづらかったかもしれませんね。
  

2014年7月15日

イノベーションを支援するITシステム構築の極意(23)

誤解の4つ目は「データや機能は重要ではない」ということで、ITでよく出てくる3文字熟語とかキャッチフレーズは、ぱっと注目されて流行りだすと、あたかもそれ一辺倒になることがしばしば起こります。昔のことでいうとクライアント・サーバーが言われた時は、メインフレームは全部駆逐されるのではないかくらいの勢いだったし、ERPの登場は猫も杓子もERPだと叫んでいた。だからBPMというと(まだは流行っていませんが)プロセスだけだと誤解するかもしれません。

システムだからどれか一つだけということはありえないわけで、さまざまな要素が複合して構成されているから、どこを重要視するのか、どこから始めるのかとかいった軸の置き方が違って来るだけなのです。筆者はITシステムは大きくプロセス、データ、機能(UI)から構成されているという捉え方をしている。フローとストックとインターフェースということです。

このシリーズで強調しているのはITシステム構築はプロセス中心、プロセス先行で行こうよねということです。そうなると、データとかUIはどうなるのかということなります。もちろん両方とも絶対に必要です。ただ、イノベーションを支援するという目的を考えると、データをマネジすること、UIを充実させることがそれにあてはまるかというとこうではないように思います。

画期的な商品の開発とか、圧倒的な市場占有率の獲得とか、卓越した商品提供力といったことはプロセスを重視したアプローチが有効であると言えそうです。では、データとかUIの出番はどこなのだろうか。まず、データですが、以前DOAというのが注目されました。データ中心アプローチでシステム開発をするというもので、せっせとER図を書いたものです。
  
しかしながら、それはあくまでITシステム、もっと正確に言うとデータベースシステムを作るためのものであったと言わざるを得ないと感じています。つまり、データの登録・更新、検索、帳票出力の仕組みをDOAで作ったわけです。DOAにおけるデータの捕捉を画面と帳票から行うということはそれを意味しています。ですから、プロセス表現が難しいしわかりにくいのです。

では、データ中心は必要ないのかというとそうではありません。データには大きくリソース系のものとイベント系のものがありますが、リソース系すなわちマスタデータはデータ中心で捉えるべきなのです。ビジネスを行うためのリソースを整理しておかなくてはビジネスモデルを変えるにしても、プロセスを改革するにしてもできないわけで、先行してデータベースを設計しておかなくてはいけません。

一方、UIは最近ではスマホに代表されるデバイスの多様化、進化があります。これは、顧客やサプライヤーといった外部接点にしても、あるいは内部の従業員にとっても使い勝手のよい、効率的な機能を要求していけるようになったわけです。ですから、プロセスサイドからの要求としての機能は当然ありますが、マンマシンインターフェースはプロセスとは必ずしも関連しないでも設計していくことになります。繰り返しますが、プロセス、データ、UIは重要となるエリアが違うのでそれ相応のアプローチが必要であるということです。
  

2014年7月22日

イノベーションを支援するITシステム構築の極意(24)

さて、最後の誤解は「ワークフローのことである」です。これはよくある誤解ですね。ただ、プロセスとワークフローの違いについて明確に規定したものはないでしょう。ということは定義の仕方でプロセスにもなるしワークフローにもなると言えます。ですから、ここは筆者の定義をベースに明らかにワークフローなのに業務プロセスと名乗っていることの間違いを指摘したいと思います。

また、ワークフローとBPMの違いをいう人がいますが、これは土俵が違うので比較することに意味がありませんので注意してください。業務とか仕事の流れをどう呼ぶかという観点になります。両者とも言い方としては、インプットがあってそれに対して何らかの処理を経てアウトプットを出すということでは一緒です。従って、どんな構造をもっているのか、どんなことをするのか、どういう使われ方をするのか、そして何のためにあるのか、という切り口でみていくことにします。構造、機能、使い手、目的の違いを検討するということななります。

まずは構造という問題です。先ほど言ったように両者ともインプットとその中間の過程とアウトプットから成っているといいましたが、ワークフローの場合は、そのフローが基本的には一層になっています。つまり、中間の過程がアクションとか単位作業になっていてそれは分解できない構造になっていることです。それに対してプロセスは、しばしば階層構造をとることになります。

プロセスでは中間過程は複数のアクティビティから構成されますが、その個別アクティビティにサブプロセスを持つことがあります。そして、そのサブプロセスがワークフローであることもあるわけです。中間過程の粒度が違うのです。つまり、プロセスはワークフローも内包したような大きな包括的な構造をもったものなのです。

次にどんなことをしたいのか、どのような機能をもたせているのかというところです。モニタリング機能が大きいように思います。そこから、パフォーマンス管理やプロセスコントロールといったところへ持っていくことがプロセスの重要な機能です。

使い手の問題が一番わかりやすいかもしれません。ワークフローは基本的には個人が使うものです。典型的なワークフローに申請承認ワークフローというのがありますが、これは個人が願い出てそれを承認してもらうという流れですから割と単純なフローで個人用になります。プロセスは組織としてチームとして業務処理を行うためのものです。要するに個人競技と団体競技の違いです。

最後の目的という側面では、ビジネスとの結びつきの程度が問題になります。ビジネス上の要求に応えられるかどうかです。戦略とか事業方針、あるいは改革課題といったところから絶えずビジネス要求が出てきますが、その受け皿にワークフローはなれるでしょうか。個人の仕事の流れであるところでは無理です。すなわち、重要な差異はビジネス要求を実行する仕組みとしてプロセスがあり、個人レベルのタスクを処理する仕組みとしてワークフローがあるということではないでしょうか。

2014年8月 3日

イノベーションを支援するITシステム構築の極意(25)

5つの誤解のあとは、7つの作法になります。いよいよシステム構築のHowの領域に入っていきます。その7つの作法というのが下記のとおりです。

(1) プロセス名を決め、始点と終点を決める
(2) プロセス構成に従って中間アクティビティを記述する
(3) 主要なアクティビティである意思決定では確定すべきデータあるいは判断項目を定義する
(4) 作業プロセスがある場合はそれをサブプロセスとして記述する
(5) プロセス構成モデルからケース分割とタスク分解を検討する
(6) プロセス要素表を作成する
(7) 実装する

ここで"作法"と言っているのは、厳格な技法でその通りにやらなくてはいけないというものではないことを意味しています。だいたいのやり方があって、人によって違っても構わないということでもある。ただ、勝手にやっていいかというわけではなく、最低限の決まりは守ってよねというものです。

では、最初の「プロセス名を決め、始点と終点を決める」です。プロセスというのは必ず始まりと終わりがあります。その時何を持って始まって、どうなったら終わるのかは決めておいたほうだがいいですよね。というか、それがないと業務という意味がなくなってしまいます。目的がないことをやるのは組織では許されませんから、きちんと始点と終点を決めないといけません。しかも、始点と終点は密接に関係していて始点が決まれば必然的に終点が決まるし、その反対もあるということです。

では、始点と終点はどちらを先に決めたらよいのでしょうか。これはプロセスの性格によって違ってきます。ざっくりと言うと顧客接点プロセスか、内部プロセスで決め方が変わります。顧客接点では始点を先に決めていきます。お客さんの要求が起点になるからです。

一方、内部プロセスでは逆に終点から決めていきます。内部プロセスというのは、企業としての事情で起こされたプロセスを指していて、例えば、決算で売上の集計が欲しいといったような場合は、初めにアウトプットがあってそのためにどういうインプットがいるのかという流れになるからです。

始点と終点が決まると自ずとプロセス名も決まってきます。この時気を付けなくてはいけないのが、プロセスの具体的な動きがわからないような曖昧な名前にしないことです。よくつけられる名前に〇〇管理プロセスというのがありますが、こういった名前は避けましょう。単に「見積管理プロセス」なんてつけないで「標準品見積提示プロセス」というふうにします。
  

2014年8月11日

イノベーションを支援するITシステム構築の極意(26)

プロセス名を決め、始点と終点を決めると、次はプロセス構成に従って中間アクティビティを記述することを行います。ここでプロセス構成に従ってと言っているからには、プロセス構成について説明しておかなければいけませんね。基本的な構成は下記のようになっています。

プロセス構成.JPG

まず大きく意思決定プロセスと作業プロセス、タスク管理から成り立っています。ここで詳細に行く前にこのプロセス構成のバリーションを考えてみます。現実のプロセスでは意思決定プロセス、作業プロセス、タスク管理の重要度というか構成割合が違ってきます。そのバリエーションが下図となります。

構成バリエーション.JPG

ここも大きく3層と2層の構造に分かれます。3層では意思決定主体か作業主体かがあります。また、2層のものもあって、同じように意思決定が主体か作業が主体かでタイプが違ってきます。それぞれの説明は省きますが、従来システム化の対象となったのはDタイプです。どんな作業をすべきかがすでにあって、それをいかに効率的に実行するのかが焦点となるケースです。

ですから、ここはITを使って自動化することが目的になる場合が多く見られます。ところが、このプロセス構成では、段取りが与件としてあるという前提なのですが、実はこの段取りをどうするかが重要なのです。段取りが悪いものをいくら効率的にやったとしても手戻りが発生したりしたら何もならないわけです。

さて、プロセスの構成にある中間アクティビティを見ていきましょう。意思決定プロセスでは、「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」という要素が提示されています。前回始点と終点を先に決めると言いましたが、その始点は「依頼受付」、終点は「報告・登録」になります。つまり、内部でも外部でもいいのですが、何かこうしてほしいという依頼が出発点となります。その依頼に対する答えを作って依頼主に報告しでデータベースに登録するのが終点になります。

その間にあるのが中間アクティビティです。まず依頼がきたらその依頼の内容、どんな要求なのかをきちんと把握して固めておくことが大事です。あいまいなままにしておくと手戻りが発生してしまいます。依頼者は往々にしてこんな感じにといった抽象的な依頼をしてくる場合が多いのできちんとつめておいたほうがよいと思います。

その後は、単位意思決定を連鎖させたものになります。要求項目は複数のものがほとんどですから、複数の意思決定や判断になります。そして、作業がある場合には作業プロセスに落とし込みます。意思決定したものと作業プロセスから生成されたデータを合わせて報告・登録に持って行くことになります。


作業プロセスでは始点が「作業依頼受付」から作業指示がだされ、終点が「作業結果」ということになります。そして中間アクティビティは基本的には様々なアクションのつながりになります。このように、どんなリクエストがあってその内容を確定し、どんな答えを返してあげればよいのかを決め、どんな意思決定や判断を行うのか、作業な何があるのか定義していくことになります。

2014年8月19日

イノベーションを支援するITシステム構築の極意(27)

始点と終点と中間アクティビティが決まったら、主要なアクティビティである意思決定で確定すべきデータあるいは判断項目を定義することになります。この辺になるとわかりづらくなりそうなので具体的なプロセスを例にして説明していくことにします。

「見積提示プロセス」を例に今までのおさらいも含めて見ていきましょう。このプロセスの始点は「見積依頼」で、終点は「見積書提出」です。このプロセスは典型的な顧客接点プロセスですから、始点から先に決めます。お客さんはこういうものが欲しいから見積書を作って送ってくれと言いますのでそこが出発点になります。

見積依頼は見積書をお客さんが受領して終わります。つぎの商談から受注までを一つのプロセスと考えてはいけません。顧客は見積をもらってから発注するかどうかはわかりませんから別のプロセスとして扱います。このように、リクエストに対するレスポンスという関係がプロセスの骨格となるわけです。

次に中間アクティビティをみていきましょう。意思決定プロセスでは、「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」という要素からなっていることを前回示しました。ですから、「見積依頼受付」が最初で最後が「見積結果報告」ということになります。2番目の「要求仕様確定」というのは、どんなものあるいはどんなことを見積もって欲しいかを確定することです。

お客さんの頼み方も様々できちんとした依頼書を書いて提出してくれる場合もあるでしょうし、逆にだいたいこんなものでといった曖昧な表現で頼んでくる場合もあります。話は少しそれますが、この両極端の場合は注意が必要です。きちんと仕様を決めてくれるというのは一見良さそうですが、あまりに詳細に決められると提供側の裁量を入れられないという事態が起こるケースもあってやめたほうがよいと思います。

普通は見積を依頼する側よりも提供側のほうが情報が高度で多いはずだからプロの意見を取り入れたほうがいいからです。素人が玄人のことに口出しするなですね。反対に、曖昧な依頼も困ったものです。往々にしてベテラン同士のやりとりにあったりします。手戻りに泣かされることになります。

ここでの主題は「意思決定」の中身の定義の話ですから、「見積提示プロセス」ではどうなるのでしょうか。その前に意思決定と言うのはどういうことをすることなのでしょうか。それは、"データを確定すること"と"ある判断をすること"と考えています。データ確定も原則一つのデータです。こういう数値にするという決定のことです。

ここでおわかりかと思いますが、「依頼」から「要求仕様」を確定するというのは、確定してほしいデータ、判断をしてほしいことを書き出すことに等しいのです。「見積提示プロセス」では、実際には顧客要求を聞いてから意思決定アクティビティが決まりますが、理解しやすいように常識的なものをあげておきます。

見積書に記入する項目として主なものは、「商品仕様」「数量」「納期」「価格」といったものになるでしょう。こうしたデータをプロセスの中で順番に決めて行くわけです。そして、意思決定ともう一つの中間アクティビティに「作業」というのがあると言いました。この例では、「見積書作成」というのが作業になるわけですが、今どき手書きではないので、確定データを中間登録しておけば自動的に作成してくれるでしょうから、ほとんど作業なしでプロセスオペレーションできることになります。
  

2014年8月25日

イノベーションを支援するITシステム構築の極意(28)

7つの作法の4つ目は「作業プロセスがある場合はそれをサブプロセスとして記述する」です。毎回言っていますが、プロセスの基本構成は、「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」ですが、その作業プロセスのことになります。作業プロセスは前回例に出した見積提示プロセスのようなものだとほとんど作業らしきものがない場合もあります。

一方で主として作業プロセスからなる場合もあります。例えば製造プロセスのようにもうやるべきことが決まっていて、依頼がきたら手順に従って実行するといった場合です。要求仕様は逆に決まったものを受け付けるから与件としてあるし、段取りにあたる意思決定も既定のものとして扱うからです。ですから、プロセスの性格が意思決定が大事なのか作業が主たるプロセスかで多少構成が変わってくることもあります。

作業プロセスの基本構成は、「作業依頼受付」「作業項目確定」「期日決定」「担当者割当」「作業結果報告」というものになります。意思決定に基づき作業すべき内容がこの作業プロセスに受け渡されます。それを受けた作業プロセスでは、作業内容に従って、作業項目(タスク)にブレークダウンし、タスクごとに期日と担当者を決めて、作業の結果を集約することを行います。

意思決定プロセス→作業プロセス→タスク管理というようにつながって行くわけですが、キーとなる作業名、作業内容、期日はちゃんと継承されていきます。こうして実行された作業結果はデータ、報告書などの帳票、制作物などとして大元の意思決定プロセに戻されます。

さて次に5つ目の作法である「プロセス構成モデルからケース分割とタスク分解を検討する」になります。これはわかりにくいかもしれませんが、作業プロセスがいくつかのケースに分割されることがあるのでそれを見ていきましょうということです。作業プロセスに受け渡す作業内容が複数の作業プロセスになる場合です。

例をあげると、新規顧客獲得プロセスというものを考えてください。いつまでに何人を見込顧客として獲得しなくてはいけないのでキャンペーンを行うというようなプロセスの場合です。例えば、展示会たけのキャンペーンでいいなら1つの作業プロセスで済みますが、他にもDMだとか訪問だとかといったものも実施するとなると作業プロセスが複数になる場合です。こうした時にはケース分割とタスク分解を行います。
  

2014年9月 1日

イノベーションを支援するITシステム構築の極意(29)

今回は(8)の「プロセス要素表を作成する」になります。実装に近いプロセス設計です。前回、プロセスを構成するアクティビティのモデルは「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」というふうに定義しました。ここでは、作業プロセスがない単純な意思決定プロセスを例にとって見ていきます。

プロセスを設計するときに大事なことは、オペレーションから発想することです。どういうオペレーションをすれば戦略の実行が可能か、ひいてはビジネスに貢献できるのかという観点です。これがちょっと大げさなら、こんなことができれば自信をもってマネジメントができるというものは何かということです。

オペレーションプラットフォームの要件は次のようなことになります。
① ビジネスの進捗がわかること
② 意思決定(データの確定・判断)に必要な参照情報を得られること
③ コミュニケーションをしながら意思決定が行えること
④ プロセス全体と単位意思決定の責任者が明確になっていること
⑤ パフォーマンスの状況がわかり対応アクションがとれること
⑥ オペレーションの結果がアーカイブされて、次に生かされること

こうした要件を導き出した背景には、ハーバート・サイモンの「意思決定論」があります。少々長くなるが引用します。

■限定合理性と満足化原理に基づく意思決定

人間が完全に合理的な存在であるなら、あらゆる代替案のなかから、一定の評価基準に照らして最も有利な選択を行うという最適化原理に基づく意思決定ができる。しかし、合理性に限界(限定合理性)があるゆえに、人間は満足化原理に基づく意思決定をせざるを得ない

■意思決定プロセス

情報活動(情報収集 )➝設計活動(代替案の探索・評価 )➝選択活動(代替案の選択)➝ 検討活動(代替案の実施 ・フィードバック)

■組織目的の階層化と組織の意思決定

人間 は、限界合理性ゆえに、大きな問題に一挙に対処することはできず、複雑な問題の解決にあたる場合、問題を分解して組織の目的の階層化を行う。意思決定の複合体系としての組織は、その組織目的の階層化に併せて組織の意思決定も階層化して、人間の合理性の限界を克服しつつ、組織目的の合理的達成を追求する。


簡単に言うと意思決定を自動化してロジカルに意思決定できないので、意思決定プロセスを通じてより合理的な決定をくだすしかない。また、ひとりで全部意思決定できなから組織を作って分担させなくてはいけないということです。プロセス構成要素の各アクティビティは広義の意味で単位意思決定ですから、サイモンの理論を適用することができます。

オペレーションプラットフォームの要件がこの考え方に沿っていることがお分かりになったでしょうか。次回に具体的な「プロセス要素表」の要素と書き方を説明します。
  


2014年9月 8日

イノベーションを支援するITシステム構築の極意(30)

前回からの続きで「プロセス要素表を作成する」です。プロセスオペレーションプラットフォームの要件となぜそうした要件になったかをサイモンの意思決定プロセスで説明しました。ここでは、具体的にプロセス要素表とはどんなものか、どうやって書いていったらいいのかを見ていきます。このテーマのタイトルが「イノベーションを支援する」ですからそういった目的に合っているかどうか考えてみてください。

まずは、プロセス要素表を示しておきましょう。

ProcessElment.jpgのサムネイル画像

表の一番左のアクティビティの列には意思決定プロセスの基本の項目が入ってきます。そして、次の「確定データ・判断」では、意思決定とはデータを確定することとある判断をおこなうことだと定義してありますからその要素を入れます。「依頼受付」「要求仕様確定」「作業」「報告・登録」も一種の意思決定ですから同じように記します。例えば、依頼受付だと依頼内容とか依頼受付日といったものが確定データになります。

「付帯登録情報」は必須情報ではないが参考のためとか、付記したほうがわかりやすいといった情報になります。例えば、住所に対する地図だとか納期に納入条件を入れるとかいったことです。「業務ルール」は意思決定を行うための則るもので、その中には概念ルール、数値ルール、アクションルールなどがあります。非常に重要なものでサイモンの意思決定プロセスでも代替案の選択の基準もこのルールになります。

ルールは単純なものから、ある条件を入れてデシジョンテーブルを通して答えを返してもらうなんていうものもあります。BPMとBRMが連携するというのはこういうケースのことです。参照情報は意思決定するときは何らかの情報を参照しながら行うのが普通です。できるだけ有用な多くの情報に基づくほうがより正しい意思決定が行われるはずです。参照情報には、マスタとか履歴といった事実情報、リソース状況、シミュレション結果などの判断情報、契約とか規約などの成約情報があります。業務ルールも判断情報のひとつですが重要であるので独立した要素として抜き出しています。

「ロール」は起案、チェック、承認などを規定しておくところです。プロセス全体もさることながら、単位意思決定でも責任者を決めておくべきでしょう。パフォーマンス指標は、コントロールすべき対象と閾値を書きます。例えば、報告日の3日前に作業が終わっていなかったら担当者にアラートを出すとかいったことになります。最後のデータ連携は取り込みデータ、提供データ、連携システムとの関係などを記入します。

もちろんこの表を全部埋める必要はありません。最初に設計すると大抵は書くセルが少ないでしょうが、大事なのはオペレーションを重ねていきながら増や
していくことなのです。例えば、最初は業務ルールもちゃんとしていなくてもまずは慣例でもいから運用してみて、やっていくうちにルール化されたら、それを業務ルールとして記述していく。他の項目についても絶えずブラッシュアップしていいものに近づけることが非常に重要なのです。

意思決定プロセスのシステム化の最も重要な過程はここの「プロセス要素表」の記述です。この表が適切に書けること、すなわちこのレベルのプロセス設計ができれば実装に移ることができます。
 

2014年9月17日

イノベーションを支援するITシステム構築の極意(31)

さて、7つの作法の最後になります「実装する」です。最終的にはITに実装して、それを使って日々オペレーションしていくことが大事になります。前回作成した「プロセス要素表」から実装していきます。こういうと、要件定義をしてプログラム仕様書を書いてそれから実装するのでしょう、あるいはパッケージを持ってきてFitGapをやるのでしょうと言われる。

ここでは、そんなことはしません。まず対象が"意思決定プロセス"であることがあります。また、プロセス要素表を見てもらうとわかるようにプログラムできっちりと作れるような定型的なものではないということです。つまり、非定型で人間が介在するような仕組みでプロセス要素表にある各要素が仕込めるプラットフォームがあればそこに"設定"すればよいのです。

プラットフォームは基本的にデータ管理とプロセス管理そしてコミュニケーションができるものであればいいのです。そういったものにBPMSがありますが、意外と定型業務向きなので、ここではサイボウズ社の「kintone」を採用することにします。kintoneの謳い文句である"データとプロセスとコミュニュケーションを一体化させた"というのがコンセプトですからぴったりですね。多少使い方の工夫が要りますが十分使えるツールと言えます。
   
kintoneを使った実装の手順は本ブログの「ビジネスサービスのつくり方」という記事に詳しく出ていますのでそちらの方を参照してください。ざっとした手順だけは記しておきます。

1. Portalからアプリケーション作成方法を選択します。

portal.JPG

2.はじめから作成の場合
  ステップ1  アプロの名前を入力します
  ステップ2  一般設定(アイコンやデザインテーマなど)
  ステップ3  フォームの設定(データの入力フォームを作る)
  ステップ4  一覧の追加(データの一覧画面に表示する項目を選ぶ)
  アプリの運用を開始するために「設定完了」をクリックする。

フォーム設定.JPGのサムネイル画像

このように、設定だけでアプリケーションを組むことができます。フォームの設定でも、あらかじめ用意されたフィールドパーツ(ラベル、文字列、数値、日付、ラジオボタン、チェックボックス、ドロップダウンなど)をドラッグ&ペーストで貼り付けるだけです。その他にも、通知の設定やアクセス権の設定、グラフ化なども簡単にできます。最近ではAPI連携とかJavaScript/CSSカスタマイズもできるようになりかなり機能が充実してきています。ということで、7つの作法を終わることにします。
  

2015年2月12日

イノベーションを支援するITシステム構築の極意(32)

本タイトルの記事が昨年の9月を最後に追加されていなかったが、そろそろ復活しようと思う。そこでおさらいの意味を込めてこれまでどんなことを書いてきたかを振り返ってみることにする。とりあえず大きなタイトルだけを載せます。

【1】ビジネスモデルからプロセスへ
  1.2つのイノベーションタイプ
  2.4つの創造ステップ
  3.6つのビジネス構造体
  4.8つのビジネスモデル要素
  5.10の提案価値        
  6.12の主要対応プロセス

【2】プロセス設計からシステム構築へ
  1.3つのパラダイム変化
  2.5つの誤解
  3.7つの作法
  4.9つの成功要因
  5.11のサンプル

【3】システムオペレーションからコントロールへ
  1.4つのオペレーションの心得
  2.4つのコントロール指標

ということである。第2章の3の「7つの作法」まで書き終わっているので、(詳しくは記事を読んでいただくとして)次の「9つの成功要因」から再開することにします。

イノベーションを成功に導くためのITシステムにはどんなことが求められるのだろうか。考え方や技術的なこと、運用面など様々な領域での成功要因をあげてみる。

(1) プロセスファースト
業務システムを考えるときに大事なことはプロセスを先行させて見るということである。イノベーションを起こすのは、内部プロセスを効率化させたり、管理を強化してコストを低減するといったアプローチでは難しい。そこではなく、顧客やサプライヤーとの関係の中で起こってくるのではないでしょうか。

つまり、外部プロセスというか、顧客とサプラーヤーとの接点をどう構築していくかが問われることが多くなります。そこでは、データを中心に、あるいはユーザーインタフェースといったころから入るのではなく、要求に対してどういう意思決定の連鎖で対応していくのかといったプロセスが重要になるのです。

(2) 業務コンテ
プロセスを描くときにいきなり細かいフローを書いてはいけません。イノベーションは、新しいプロダクトやビジネスモデルなのですから、既成概念から、すなわち現状の作業レベルから見るのではなく、抽象度の高いところ、いってみれば新しいストーリーを書くことが大事なのではないでしょうか。

それを"業務コンテ"と読んでみたいと思います。映画で"絵コンテ"というものを書きます。シーンの展開をマンガのような絵で表現したものですが、それでだいたいのストリーイメージを共有するわけです。それと同じように、業務の展開、業務プロセスの進捗を必要少限の要素で表現していきます。

実際どんなものになるかというと、要求の内容、それに対してどんな意思決定しているのか、もっと具体的には確定するデータを順番に書いていき、最終的にどんな回答になるのかを書いたものになります。
(続きは次回に)  
  

About ITシステム構築の極意

ブログ「mark-wada blog」のカテゴリ「ITシステム構築の極意」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

次のカテゴリはBPMです。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type