プロセス改善はなぜ成功しないのか？

稼働率99.999%のクラウドサービス

KDDIクラウドプラットフォームサービス

セキュリティ

イントラネット

必要なときに必要なだけ使える！

クラウドのように

インターネット セキュリティアプライアンス

イントラネットファイアウォール

1 2

3 4

過去から現在 新たなる課題

CPQという選択 これから

2

3 4

新たなる課題

CPQという選択 これから

1

過去から現在

1. プロセス改善のはじまり 2. パイプラインマネジメント 3. クラウドという選択

プロセス改善のはじまり

営業稼働が低下している

ボトルネックがどこか分からない

事務処理が仕事の60％

お客さま満足度も低下？

気合 科学

「気合」と「根性」の限界

事務処理職人の技

気合の正体

営業の個人技

コスト削減という名の我慢

部門最適の集合

結 果

補助ツール乱立

属 人 化 が 進 む

独 立 国 家

七 つ 道 具

名人の誕生

負の連鎖

全体力の低下

業務改善圧力

プロセスの歪み

改善の大玉送り

負の連鎖を断ち切り、科学的営業へ！

パイプラインマネジメント

経営

リアルタイムマネジメント

お客様

目標

高速PDCA

お客様の声

ジャストインタイム

ITコンシェルジュ

お客様満足度

問合せ/ﾘﾃﾝｼｮﾝ 申込・事務処理 営業活動 マーケティング

マーケティング オートメーション

お客様 サポート WEB

案件管理 商談管理

企 画

開 発

検 証

申込書 作成

契約管理 請求発行

申込書

請求書

案件／商談情報集約 利用状況/お客様の声集約

回線開通 工程管理

ｿﾘｭｰｼｮﾝ 受発注

発注書

社内 問合せ サイト

商品開発

概念図

アジャイル開発

CRM

さて、どうやって開発を進めるか

「クラウドを軸に検討しよう！」

クラウドという選択

クラウドのメリット

所有から利用へ

コスト削減

必要な時に、必要な分だけ

導入スピード・柔軟性

ユビキタス環境

セキュリティ

クラウドファーストの落とし穴

なぜクラウドでなければいけないの？

社内システムとの同期とれるの？

障害の切り分けが難しいでしょ

どうせカスタマイズしちゃうんでしょ

コスト削減にならないって聞いたよ

問1.

問2.

問3.

問4.

問5.

クラウド （パブリック）

自社設備

導入スピード ○ △

安定性・可用性 △ ○

コスト ○ △

セキュリティ △ - ○ ○

よく見る星取表（客観的に比較）

クラウドにこだわらないで比較

クラウドにこだわらないで比較

クラウド （パブリック）

自社設備

導入スピード ○ ○

安定性・可用性 × ○

コスト ○ △

セキュリティ △ ○

自社設備、ウォーターフォール型開発目線

標準化・グローバル 世の中標準 社内標準

開発方法 ダイレクト 要求→翻訳→開発

あらためて、なぜクラウド

シンプルさ 使いたい機能優先 ほぼ使わない機能65%

クラウド 一般的開発

コスト 短い 長い 時間

コミュニケーション 単純 複雑

第2の目的

コストの見える化（経費）

第2のメリット

内製化（アジャイル）

一体感（部門間連携）

最初から使えるものがある

標準にない機能に意味がある

2007年（風）問題 開発者異動問題

1年後のことなんてわからない 3か月単位で考えたい！

システムが複雑になり過ぎていて もはやトレースできない！

じゃあ、クラウドで

いろいろ言いましたが

クラウド導入の壁を超えるには 余談

一般的開発

開発費

運用費

開発費

運用費

開発費

運用費

時間

費用

機能

クラウド

ライセンス費

開発費

時間

費用

機能

開発費

バージョンアップ

コストの考え方を共有する

余談

一般的開発は、今への投資、クラウドは未来への投資

未来の投資の半分は提供者とシェア

固定費から変動費

余談

RFP作成 競争入札 評価

通常

クラウド

必 要 な 機 能 を 定義する

普 通 に 入札する

費用 技術 納期 いま実現

したいこと

将来機能

評価ポイント の違い

従来のフローで検討し、評価の違いを理解する

余談

念のため機能を除いても、機能差分はあるか

何を費用に含めているのか、切り分けできているか

基本的にどちらもやればできる やる（一般的開発） お勧めできない（クラウド）の違い

壁は本当にあるのか？ 余談

クラウドにこだわらず普通に比較する

費用・評価・判断ポイントの違いを共有する

「ローカル・ルール」と「グローバル・ルール」

リスクを具体化する

漠然と評価しない

必要なものは何か

「 今 」と「未来」

リスクを具体化する

国内トップの技術力と実績を誇るセキュリティ監視センター 『JSOC（Japan Security Operation Center）』

※ラックのJSOCでは、行政機関、官公庁、大企業を中心とした約850の組織を24時間365日監視し、 サイバー攻撃などのネットワークの脅威を監視しています。セキュリティ監視機器が検知する警報 ログは1日に4億件にものぼり、経験豊かなエンジニアが脅威を監視し、お客さまをお守りします。

×

セキュリティ×ネットワークをトータルでサポート

株式会社ラックとKDDIのパートナーシップ

責任分界点の意識

クラウド導入にあたり注意したこと

余談

運用の継続性

ユーザー部門の負担は増える

「できない」ではなく「やらない」

システム

商 談

マーケティング 営業活動 事務処理 リテンション

AARON 提 案

顧客応対

プロモ

提案Tab プロビ

問合せ

営業情報集約ハブ

MA

SFA/CRM

SFA/CRM SFA/CRM

SFA/CRM

利用部門 法人部門

利用人数 4,700人

開発体制 システム部門：3名 ユーザー部門：3名

推進体制

体制

ユーザー部門：3名

開発期間 営業系：4ヶ月 プロビ系：6か月 （開発中）

1

過去から現在

3 4

CPQという選択 これから

1. プロセス改善のはじまり 2. パイプラインマネジメント 3. クラウドという選択

2

新たなる課題

1. 利用率があがらない 2. 足りないピース

利用率が上がらない

ユーザー

使うメリットがない

記憶しているからいい

仕事の仕方を変えると効率が下がる

スタッフ

データが蓄積されないとメリットが出せない

エクセルが好き

営業活動

商談開始 提案活動 結果

最初と 最後の

情報だけがある

実績管理以外に使い道がない…

足りないピース

ニワトリ・タマゴを脱却し、使える情報を蓄積したい！

勉 強 1

・ CRMとは

・ 本部長を交えて

・ PL/CF

共 感 2

・ 成功体験

・ 活用している証明

・ トップが全部見る

「使い方」ではなく「意義」の共有

必然性 3

日常導線の中で、必然性のある処理を組み込む

Oracle CPQ Cloud SFA/CRM

商談開始 提案活動 結果

承認 提案 見積作成 提案 ・・・ ・・・

2

新たなる課題

1. 利用率があがらない 2. 足りないピース

1

過去から現在

4

これから

1. プロセス改善のはじまり 2. パイプラインマネジメント 3. クラウドという選択

3

CPQという選択

1. 導入のねらい 2. 開発 3. 見えてきた課題

導入のねらい

CPQは見積もりシステムではない

ポジション

営業プロセスのハブ機能である

役割

見積り

決裁 CRM S F A

プ ロ ビ ジョニング

勘定系 システム

連 携 マスタ

料 金 システム

商品 マスタ

CPQ

①CRMフローの一部 ②システム間の接着剤

役割 ③ガバナンス ④パラメータ管理（オーダー登録）

CPQ SFA/CRM

承認 受注 見積作成 提案

商談進捗 価格

承認

パラメータ

ガバナンス

オーダー処理

工事手配

役割

⑤ミス防止

CPQ

見積りミス 提案ミス 誤登録

誤請求

誤手配 チェック

2,500 パターン数

品目数

余談

計算不能 組み合わせ数

期待効果

115,000 /年

200,000,000 /年

費用 時間

開 発

4ヶ月

開発期間

※ モバイル4ヶ月,ネットワーク4ヶ月 ※ リリース2016年1月

利用人数

3,000人

費用

システム

商 談

マーケティング 営業活動 事務処理 リテンション

AARON

見積作成

承 認

提 案

顧客応対

プロモ

提案Tab プロビ

問合せ

Oracle CPQ Cloud

営業情報集約ハブ

MA2

SFA/CRM

SFA/CRM SFA/CRM

SFA/CRM

仕様 検討 開発 ユーザー

テ ス ト ①小さなゴール の積み重ね

開発の進め方

（アジャイル風）

仕様 検討 開発 ユーザー

テ ス ト

仕様 検討 開発 ユーザー

テ ス ト

企画 開発 ユーザー

②企画・開発・ユーザー一体の体制

チーム

設計

③引き継ぎでなく実践

開発 設定

Oracle KDDI KDDI

チーム チーム

小さなゴールの 積み重ね

企画・開発・ユーザー 一体の体制

引き継ぎでなく実践

1

2

3

スピード感 手戻りあり

ジブンゴト化

スキルアップ

成 果

部分最適の集合

まとめ ① プロセス改善が成功しないのは

開発スピードが遅い

企画・開発・ユーザーの距離が遠い

改善の大玉送りになっていませんか？ 年中改善していませんか？

開発に半年以上かかっていませんか？

コミュニケーションロス、タニンゴト化が起こっていませんか？ 要望と成果物にギャップはありませんか？

価値基準を共有し、あいまいに判断しない

まとめ ② クラウドの導入の壁を超えるには

考え方 クラウド 漠然とした 不 安

優先順位

Coming soon

まとめ ③ CPQの効果的活用方法は

1/4リリース(予定)

見えてきた課題

スピード化の代償 本来は別システムにすべき苦手な機能を無理に挿入

システムA

何でも

かんでも

何でも

かんでも

何でも

かんでも 何でも

かんでる

何でも

かんでも かんでも

何でも かんでも

何でも

かんでも

何でも かんでも

何でも かんでも 何でも

システムB

かんでも

本当はB . . .

何でも

かんでも

実はフローがまわっていない 部門間をチェーン化しても部門最適は簡単には直らない

部署A

部門最適

部署B 部署C

部門最適

部門最適

部署A 部署B 部署C

システムA システムB

歪み 歪み

標準化の浸透度

まだシステム改善を行っていない部署にとって 他部門の標準化はストレスが大きい

部署A

標準化

部署B 部署C

まだ 標準化

ストレス

入口

改善活動

カスタマーエクスペリエンス（顧客経験価値）

・ 顧客体験価値あわせて活動を再配置

出口

・ 全体をウォークスルーし業務の再定義

・ 全体最適維持機能の立上げ

2

新たなる課題

1. 利用率があがらない 2. 足りないピース

1

過去から現在

1. プロセス改善のはじまり 2. パイプラインマネジメント 3. クラウドという選択

3

CPQという選択

1. 導入のねらい 2. 開発 3. 見えてきた課題

4

これから

これから

クラウドの活用

システムリプレースにストレスがないレベルまで

超標準化

CPQへの期待

相談先が少なくて寂しい...

日本のユーザー増