November 2010 Archives

ビジネス実行体系の各フェーズの内容

前回は、ビジネス実行体系とその中の上流での肝はビジネスモデルであることを指摘しましたが、詳細に入る前に、提示した下記の体系にある各フェーズの内容について概観しておきましょう。

(1) 戦略
(2) ビジネス(事業)モデル
(3) ビジネス(事業)プロセス
(4) 業務プロセス
(5) 業務オペレーション

最初にある戦略ということですが、前回も言いましたが、戦略策定は通常トップダウン的に行われます。すなわち、企業理念やビジジョンをベースにして、様々な分析を行い、そのポジションに応じた戦略が講じられるわけです。しかしながら、トップダウン的だけではなく、ボトムアップ的なアプローチもあると考えています。それが、これまで書いてきた「ボトムアップ戦略立案」のことになります。簡単に言うと、ビジネスモデルに埋め込まれた自社の強みを生かして、どうビジネスモデルを変えていくのかも戦略になるということです。

さて、ビジネス実行体系の上流での要諦であるビジネスモデルということですが、ビジネスの基本的な構造と機能のモデルということになります。難しい言葉で言うと「組織能力」と「価値提供力」です。これも簡単に言うと、顧客を獲得してから、経営資源を使って、商品を提供して収益をあげる仕組みとなります。

ビジネスモデルは書いただけでは何もなりませんから、それをどう実行するかが大事なことになります。その実行の主体はプロセスと考えています。いきなり業務システムというようにはしないでください。ITはまだ出てきません。ビジネスプロセスを表現するのがビジネスプロセスということになります。

ただ、このレベルのものは、まだプロセスといっても、抽象度高い機能群を並べてものに近いと思います。そうした、ビジネスプロセスをさらに分解したものが業務プロセスです。ここでは、実行を意識した構造になってきます。そして、ここでプロセスという言い方をしていますが、業務システムというのは、システム機能を除けば、基本的にはプロセスだけではなくて、その他に、データ(情報)と機能(ユーザインターフェース)から成り立っています。

ですので、ここでは業務プロセスを広義に解釈して、それらを含んだ全体を業務プロセスと呼ぶことにします。つまり、データ(情報)を参照しながら、UIで操作して、プロセスを回して、新たなデータ(情報)を生成する仕組みと仕掛けを業務プロセスというふうに定義しています。

最後の業務オペレーションは、その業務プロセスを動かすプラットフォームのことで、業務処理案件が来たら、そこで受けて処理を行います。そして、その処理パフォーマンスを制御、モニタリングして、所定の効果を上げるようにします。モニタリングの結果で改善すべきことが出てきたら、業務プロセスの仕組みや仕掛けあるいはオペレーションマニュアルにフィードバックします。

実は、この最後の業務オペレーションという領域の重要性を感じることがビジネスエンジニアの重要なミッションとなります。従来では、ここが見落とされがちで、システムを作って終わりという例が多く見られます。


ビジネス実行体系

ビジネエンジニアというからには、ビジネスのことから考えていかなくてはいけないというのは自明のことです。従来、システム屋さんというのは概して、要件定義から入ります。つまり、ビジネス要求が決まってから、その要求に対してシステムをどう作ろうかというポジションにいるわけです。

ビジネスから要求を出す要求定義とそれを受けて行う要件定義との受け渡しが必ずしもうまくいっていないというのが、今の問題点ではないでしょうか。システムのことがよくわからないユーザが出す要求とビジネスのことがよくわからないシステム屋が受ける要件定義にギャップがあるのです。

では、そのギャップを埋めるには、それができる全く新しいスキルの人材を育成すればよいのでしょうか。そう簡単な話ではないですよね。その前に大事なことはその渡し方をどうするのかを決めないと人材も育てようがありません。ここらあたりはよく間違えるところで、順番は方法論を作ってから、その方法論にそって実行できる人材を育成するというのが順路であって逆ではありません。

ということで、まずはビジネスからシステム実装までの技法について考えていきましょう。ビジネスというと最上流のビジョンとか戦略というふうになりますが、そこは、理屈ではない部分や精神論的なところがあるのであまり深入りはしないようにします。まあ、トップダウン型の戦略はあるという前提です。

実際に行っているビジネスの実行体系は次のようになっています。

実行体系.bmp

このうち、ビジネス構造の要諦はビジネスモデルだと考えています。そして、意外とこのビジネスモデルを書けていないというのが、このところ様々な事例をみての実感です。すなわち、SWOT分析したり、バランススコアカードを作ったりといった戦略策定みたいなことは、例えばその領域のコンサルタントを入れてやったりします。それと要件定義のところは最初に言ったようにシステム屋さんが待ち構えています。ところが、このビジネスモデルを誰が書くのかという大事なところがあいまいになっているように思うのです。


これまで、mark-wada blog で"ボトムアップ戦略立案"というのと"ITエンジニアの育ち方"というシリーズで記事をエントリーしてきましたが、前者はほぼ完了したのと、後者も問題解決のし方や課題設定というフェーズが終わっって、これからその解決策を議論する段階になったこともあり、テーマを再設定して書いていこうと思います。

"IT エンジニアの育ち方"で出ていた課題が「事業に貢献できる業務システムとは」ですので、それに応えていくという流れになります。その答えを用意する役割を担うのが、"ビジネスエンジニア"(仮称)という呼び方をしようと思います。このビジネスエンジニア(BE)という名前はシステムエンジニア(SE)に並べるもので、システム構築の上流のパートを担当することになります。

実は、この領域のエンジニアはあまり多くないのではないでしょうか。最近では、BABOKで言及されたり、ビジネスアナリストとかビジネスアーキテクトなんて言葉もでてきていますが、BABOKは超上流と言われて、分析が主体でプロセス設計までの落とし込みが弱いと思われます。

ビジネスとIT との一貫性と連動性を担保できるシステムを設計する人が必要なわけで、これまではこの一貫性、連動性ができていないのと、それ故、そうしたデザインできる人材がいなかったのです。そのくせ、みなさんしゃあしゃあと経営とITの同期だとか、事業とITの融合だとかおっしゃいます。言うだけはだれでもできますが、実際に業務システムに落としこまない限り、意味がありません。

そこで、ビジネスエンジニアのやるべきこと、身につけるべきことについて議論するわけですが、前回にも指摘しましたが、「ビジネス」の定義を少し広くとっています。つまり、企業における事業だけではなく、イベントを実施する場合だとか、それこそボランティアみたいなことも含めて考えることにします。従って、定義は次のようになります。

「人々の要求に対して、それに見合う価値を提供することにより、相当の対価を得ること」

一方、エンジニアリングというのも定義しておく必要があります。こんなふうに考えてみました。

「価値を提供するための仕組みと仕掛けを設計すること」
こうして、ビジネスエンジニアが行った設計に基づいて、システムエンジニアがITの部分を担当することになるわけです。

オヤジが書きます

| No Comments | No TrackBacks | このエントリーを含むはてなブックマーク はてなブックマーク - オヤジが書きます
wadit.blogができたので、仕事のことやITがらみの話を書いていこうと思います。実は今、「mark-wada blog」というブログをやっていて、これは2006年から書き始めたのですが、ここ3年ほどは毎日欠かさエントリーしていました。

そこでは、私的なのも仕事のことまで混然としていましたので、公私を分けようと思います。ですから、ここでご覧になってくれた方々も、できたら私的な方のブログも見てください。そこは「シネマと書店とスタジアム、それとオヤジのひとりごと」というコンセプトで、映画と本、スポーツ観戦(特にサッカー)と日常のことについて書いています。

さて、このブログではITのことになりますが、今ぼくが力を入れているのは、ビジネスとITとの橋渡し、すなわちビジネスの要求に対して、一貫性と連動性を失わずにITに落とし込むということです。そのための仕組みと仕掛け、方法論を作ることと、それができる若手のエンジニアを育成することです。

そして、最近思うのは、「ビジネス」といっても何も企業がやっているようなことだけではなく、それ以外の公共あるいは社会的な活動も広い意味で「ビジネス」ではないかと思っています。ただ、ビジネスというとお金儲けという風になってしまいますが、これも短絡的で何らかの価値を提供して、その対価がお金ではなく、例えば「名誉」だとか「リスペクト」、「感謝」でもぼくは立派な「ビジネス」(言葉を変えた方がいいかもしれませんね)ではないかと思っています。

逆に言うと、そうした貢献をITはもっとやるべきだと思うし、やれると考えています。そんな、ことをみんなと一緒に議論できたらと思っています。

おーお、堅いなあ! いや、実体の本人は堅くはないですよ。わかるでしょ、エロギークのオヤジだから単なるエロオヤジなのです。ということで、これからよろしく。

裕介です。息子です。親父はもうすぐしたら登場するでしょう。さて、弊社のオフィス環境について紹介します。オフィスと言っても、別々で普段作業をしています。私は自室、親父は隣の祖母の家の一角をオフィス化したところでです。つまり息子は自分の部屋で親父はばあちゃんの家で仕事している家内制分業型オフィスとなります。ちなみに、ミーティングや外部から人を招いての打ち合わせをする時は私が祖母の家のオフィスに伺うことになります。

これがオフィスの外見です。というか普通に我が家です。

ピクチャ 57.jpg

オフィスの内部です。といっても普通のお家です。

ピクチャ 58.jpg

普段は離れているので、Google Talksを使ってやりとりしています。

一番よく行われるやり取りはこんな感じです。

Masanori: ひるめしは?
Yusuke:   食べるよ
Masanori: いく?
Yusuke:   はい
Masanori: いこうか
Yusuke:   はい
平和ですね。Waditの社長はお昼ごはんを作ってくれるお嫁さんを募集しています。

Blog、mixi/greeなどsns、Twitter、Ustream、Facebook... 数多くの「面白い」と思えるネットのメディアが登場してきました。個人がやろうと思えば広範囲にリーチできる手段があるわけですが、こうしたプラットフォーム上で行われているコミュニケーション。私はよく、それぞれの特性を捉える上で、リアルな空間における場所を想像します。

例えば、先日より一部界隈で流行りだしつつあるFacebookのコミュニケーションは、居酒屋やファストフード店における中人数でのたわいの無い「会話」に似ています。「これおもしろくねー?」「いいね!」という具合に。もちろん、ちょっと真剣な会話にも状況によって突入します。Ustreamも実験でいろいろとやってみていますが、あれは授業中にいきなり立たされて、演説してみろと言われるのに近く、けっして会話という具合ではないです。演説と言ってもUstreamの場合は個人が積極的に行うものですし、いい演説は賞賛され、興味がない人は去っていきます。よく政治の例えで「劇場型政治」と言う言葉が使われますが、劇場というのがそれこそメディアの空間であると考えればあながちおかしくはない捉え方だと思います。

ちなみにmixiの日記を書く、読むという行為はFacebookにおける場所感覚とちょっと違う気がします。どちらかというと友達の家に言ってちょっと緊張感ありながらお話をするとか... なので、Facebookとmixiというのは一概に比べることのできないコミュニケーションを持っていると思います。が、ソーシャルグラフは一大勢力が握るのではという議論もあって面白いですね。

ってな感じのノリで、このBlogでは、普段私が考えていることを書いて行くのでしょうか。

「親子二人でわだがITするからwadit(ワディット)だろ」とはじめて早4年が経ちました。こんにちは。社長であり、息子である、裕介です。先ほど昼飯を近所のジョナサンで食べながら、親父と話したところ、「うちの会社のホームページ作り直そうか」という結論になりました。

しかし「作り直したってコンテンツないとどーしょもない」ので、皆さんに見てもらえるようなコンテンツが必要です。といっても二人ともそこそこ文章を書くことは好きらしく、個人でそれぞれブログを持っています。二人が持つコンテンツ作成の方向性を「Wadit」という軸でまとめあげればどうなるか?それがこの「Wadit Blog.」のチャレンジとなります。

Blogというメディアは私達のような個人、小規模組織にとっては非常に有意義なツールです。現在飛ぶ鳥を落とす勢いのTwitterやFacebookでは伝えきれないものを伝えられると思っています。こうした現代のインターネットメディアについては、興味深いのでまた後ほどの機会に考察してみたいと思います。

さて、それぞれ個人のブログがありつつも飽きずに、「Wadit Blog.」が続くかどうか、こうご期待。

About this Archive

This page is an archive of entries from November 2010 listed from newest to oldest.

July 2008 is the previous archive.

December 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Categories

Pages

Powered by Movable Type 4.34-en