顧客との関係強化とIT 誤解のないように先に筆者の考えを書いておく。ITを使うことで、企業と顧客との関係におけるすべての課題を解決できるわけではないと常々考えている。あくまでも従であると。 ただ、すでに社会もITを前提に動き始めている。ITの恩恵を全く受けずに企業活動を行っていくことは、コストも時間軸も見合わないものになってきていることも事実である。 これまでこの連載では、第1回から第5回まで企業と顧客の間の関係強化についてさまざまな角度から述べてきた。今回は連載の最終回として、企業と顧客の間の関係強化について、ITとしての実装を述べていきたい。 顧客との関係についての要求分析 企業と顧客という関係において、現在よりも良い関係に変えていきたいとする場合、企業内のITシステム各種を、現在よりも進化させることとなる。顧客との関係を強化するためのプロジェクトを正式にスタートする前に、何を対象とす

サービスとは、「ティッシュ」や「携帯電話のストラップ」などを配ることではない。いかに要望を満たすか、いかに利便性を提供するか、どのようにコンサルティングニーズを満たすかといったカスタマー・エクスペリエンスの観点を考えるべきものである。 売れ行きを左右するもの 現代は製品・サービスがなかなか売れない時代である。同じ分野にさまざまな企業が参入し、多くの製品・サービスが投入されていて、市場の競合は厳しい。 製品の機能差、価格差、デザインの違いなどがあまりないのに、売れ行きに大きく差が付く場合がある。同様に、同じようなサービス内容であるにもかかわらず、他事業者と比べて売り上げに大きく差が付く場合もある。 これは開発者側・提供者側の大きなよりどころである、「製品が良ければ必ず売れる」という考え方が誤りであるという証拠である。ここから分かることは、「よく売れるかどうかは、製品・サービス内容の表面的なス

グッド・カスタマー・エクスペリエンスを実現する情報システムとするためには、経営者の視点で演繹的に考えることや、ITアーキテクトとして企業のバリューチェーン、ビジネスプロセスを俯瞰（ふかん）し、ヒトや組織が遂行する部分と、ITにより支援する部分をバランスさせる必要がある。 グッド・カスタマー・エクスペリエンスを生み出す組織 顧客に「次も買いたい」「次も使いたい」と明確に意思を持って選択してもらうためには、「グッド・カスタマー・エクスペリエンス＝良好な商品／サービスの経験」を提供しなければならない。 グッド・カスタマー・エクスペリエンスを生み出す企業組織とは、どのようなものであろうか。連載第3回「ナレッジマネジメントのIT化と家族経営の八百屋」では、組織内の構成員、部門・部署間のナレッジの共有について述べた。今回は、企業組織のバリューチェーン、顧客に商品やサービスが提供するまでのサプライチェー

ビジネス環境の変化が激しい現在では、環境に適応して自社のビジネスを俊敏に進化させなくてはならない。ビジネスモデリングによる「可視化」を活用することで、何が改善されるのか？ 「ITシステムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値に基づいて『開発』されるべきものである」という考えに立って、ビジネス的な価値を生み出すITシステムのシステム要求を体系的に開発する方法論を提唱する団体がある。ビジネス主導によるIT化のための真のシステム開発方法を作り出し実践することを目標とした、ユーザー企業とソフトウェア開発企業のメンバーからなる「要求開発アライアンス」である。 同アライアンスが提唱する要求開発方法論「Openthology」は、オブジェクト指向分析・開発やUML（Unified Modeling Language）といったシステム開発で活用されてきた手法を利用してビジネスをモ

ERP、SCM、CRMの次に打つべき“一手”－データ活用がビジネスを変える－：情報マネジメント　提言 ERPやSCM、CRMなどのビジネスアプリケーション導入は一巡した。ただし、これらのアプリケーションを導入しただけでは経営は変わらない。次の一手として来るビジネスITは何か？ 情報マネージャに次の道しるべを示す。 ERP、SCMやCRMなどのビジネスプロセスを施行するためのシステムは、企業が業務を遂行する上で当然必要となるインフラである。あって当たり前である。ところが、これらのシステムから発生するデータの活用について考える企業は意外に少ない。 「ITを経営に生かす」ということは、単にビジネスプロセスをシステムによって自動化するだけではない。そこからいかに経営に必要な“知恵”を獲得するかということだ。経営に必要な“知恵”、すなわちインテリジェンスを獲得するためのヒントがここにある。 基幹系シ

Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、

ソースコードの一行一行は、経営判断そのものだ。 どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。 「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは

われわれは日常的にたやすくシステムという言葉を使ってしまうけれど、システムって何だ？ システムズ・エンジニアって誰だ？ 「最近システムがよく落ちるんで困るっすよ」ってどーゆーことだ？。 システムとは相互作用する複数の要素の集合。だから太陽系もシステムだし、会社もシステムだし、計算機もシステムだ。仏教的にはあらゆるモノはほかのモノとの相互作用においてのみ存在するわけだから、（仏教的世界においては）あらゆるモノはシステムということになる。とはいっても、例えば地球、月、太陽というたった3つのモノの（古典）力学的相互作用にさえ、厳密な一般解はないといわれているくらいで、カンタンではないのもシステムとゆーやつの特徴だ。 この複雑で厄介なシステムを「エンジニアリング」的に相手にして、飯を食っているのがわれわれシステムズ・エンジニアである。じゃあ、こんなものをどうやって相手にすればよいか。大きく分けて2