クラウド利用の「本当のところ」とメリット享受のための４か条 | クラウドに踊らされないための指南書

• 対象とする読者
  ・クラウドだとかSaaSだとかよく聞くけど何なの？という人
  ・「とりあえずクラウド化すればDXになる！」と勘違いしている人
  ・上記のような勘違いしている人（主に上司）に説明したい人

前回「クラウドの概要と「概念上の」メリット」として一般的に言われるクラウド利用のメリットやデメリットのお話をしましたが、これはどこのクラウドベンダーでも、SIerですら使う「クラウドのメリット」のお話です。

これはあくまで「概念上の」お話です。
ここからは企業の現場で起こっている「本当のところ」のお話をしていきたいと思います。

今更ではありますが、本記事は「企業・法人で利用するエンタープライズ系システム（所謂エンプラ系）のクラウド化」についてがメインになります。
個人向けサービスだと少し様相が異なるかもしれませんのでご了承ください。

ご注意いただきたいのは、お伝えしたいのは「本当はクラウドってそんなにメリット無いから辞めといたほうがいいよ」ということではなく、「メリットを享受するためには知っておかなければいけないこともやらなければいけないことも色々あるよ。自分は何もしなくてもクラウドが何でも解決してくれるような魔法の杖ではないよ」ということです。

クラウドだけではなくAI・IoT、ひいてはDXも、IT・デジタルのトレンドワードは「魔法の杖」のように扱われがちです。「省力化」「自動化」など耳障りのいいメリットだけが宣伝され、「導入・適用も省力化・自動化できるんでしょ、我々は何もしなくても全部やってくれるんでしょ」のような都合のいい勘違いをユーザー側に持たせてしまっているように感じます。

どんな革新的な最新技術が生まれようとも、使い手が理解できていなければ十二分に活用することはできません。

クラウド利用の「本当のところ」

「初期投資がかからない」は物理インフラのみ

所謂ある程度の規模のエンプラ系システム導入の費用構成はこんな感じです。
ちなみにクラウドの例２には意図的に「なんちゃってクラウド」の要素をいくつかちりばめてあります。

オンプレミスの場合とクラウドの例２を比較すると、ハードウェアやミドルウェアの費用が無くなっている以外はそんなに違いません。

もちろん全てのソフトがこういうわけではありませんし、例１のように手軽に導入できるものもあります。例１に該当するものは、SaaSならOfficeOnlineやGSuite、Dropboxあたりでしょう。
しかしSaaSだからといってSalesforce（クラウド型SFA）やSAP Business ByDesignとかNetSuite（クラウド型ERP）を導入支援無しに利用できるかというとそうはいきません。
（ここで記載したソフトが図の例２かというとそれも少し違いますが。）

また前回メリットの所で「月額料金でお試しして」と書きましたが、個人利用のサービスであれば無償版やトライアルもありますが、法人利用の大規模システムになると、最初に契約書を取り交わしてライセンス費用と初年度の利用料を支払って…のように「月額料金でお試し」が困難な場合もあります。

トータルの費用で見ると導入支援やライセンス保守などにはさほど差が無く、ハード・インフラの初期投資が浮くくらいで、それ以上の費用的な効果をサービス本体に求めないほうがよいでしょう。
クラウド利用の費用的な効果は業務プロセスを見直したことによって発生するものであり、システムそのものが安いという意味ではありません。

サブスクリプション契約は利用している間継続的に費用が発生するため、長期利用になるとトータル費用でオンプレミスの方が安価になることもあります。
金額だけではなく、支払いに一時的に纏まったキャッシュが必要だが帳簿上資産として計上されるオンプレミスと、経費扱いのクラウドの経理上・会計上の損得も関係する場合があります。

しかし、５年で数十万～百万くらいの金額の差に拘泥して（この辺の金額は事業規模にもよるので、身近な金額に読み替えてください）業務プロセス革新を先送りにすることのほうが大きな損失ではないでしょうか。

ノンカスタマイズ利用を阻むメインフレームの亡霊

図の例２の落とし穴の１つ目は適用作業におけるカスタマイズです。
クラウドで提供されている製品の多くは設定値を多数準備していますがカスタマイズは行いません。

「ノンカスタマイズでシステムに業務を合わせる」とはベンダーやコンサルが判を押したように唱えるお題目ですが、容易なことではありません。
特に日本は「システムをカスタマイズして業務に合わせる」ことに慣れきってしまっています。それは何故なのでしょうか。

「システムに業務を合わせる」は何も最近言われだしたことではありません。
時代は汎用機やオフコンと呼ばれたメインフレームのオープン化まで遡ります。

パソコンやネットワークがオフィスに普及しはじめたのは1990年代、インターネットの普及にはそこからさらに10年近くかかりました。
それまでオフィスにおけるコンピュータ処理を担ってきたのがメインフレームです。
メインフレームとは計算処理を行うための高額で巨大なコンピューターです。高額で巨大なだけあって処理性能は高いし稼働は安定していますが、独自OSのため汎用ソフトは無く必要な処理はほぼ手作りです。

オフィスにパソコンが普及し始めると、（メインフレームと比較すると）安価なサーバや業界標準に規格化された（スクラッチ開発と比較すると）安価なパッケージソフトに置き換える「オープン化」の取り組みがはじましたました。2000年代にはSCM、CRM、ERPなどの概念と共にオープンシステムパッケージが多数送り出されます。

しかしこの時に多くの企業はメインフレームからオープンシステムへの移行において、パッケージに業務を合わせることなくメインフレームで行っていた処理をそっくりそのまま新システムに焼きなおしたのです。
パッケージ導入のはずがゴテゴテのカスタマイズによりパッケージの原型を留めないシステムが出来上がり、「安価で規格化された」メリットは消し飛び、何よりメインフレーム前提で作られた業務手順はそのまま引き継がれたのです。

ネットワークを介してパソコン毎に業務が分散できるメリットは享受されず、汎用機より性能が劣るバッチ処理（汎用機はバッチ処理が非常に高速）に長時間の待ちが発生し、カスタマイズ箇所の品質問題により稼働が安定せず、結果的にオープン化前より業務に時間を要するようになってしまい、「これならメインフレームのままの方がよかった」と言われるような状態になったのです。

車で例えると、2トントラック（メインフレーム）からコンパクトカー（オープンシステム）に乗り換えたのに、「梱包した段ボール100箱を100キロ先の倉庫からここまで運んでくる」業務を続けるようなものです。
2トントラックなら１～２往復で済むかもしれませんが、コンパクトカーだと往復200キロを何回往復しなければいけないか分かりません。そこで「コンパクトカーを段ボールがたくさん積めるように改造して、2トントラックの時と同じように運べるように」しようとしたのです。
普通に考えるとそんな車がまともに走るわけありません。でも実際やってしまったのが「メインフレームからオープンシステムへの焼き直し」なのです。

なぜそうなったのか。
それは「メインフレームで業務に合わせたシステムを作っていたから」だと考えます。

メインフレームは処理をベンダーの技術者が、時にはユーザーの担当者が必要に応じて構築していました。今でいう「業務の個別最適化」状態ですが、メインフレームによる業務効率は人力とは比較にならなかったため全く問題にはなりませんでした（そもそも標準化という考えが浸透するまでは個別最適化が悪という発想すらなかった）。
それにメインフレームには必ずメーカーの保守があったので技術者が張り付きに近い状態でサポートして新たなリクエストにも応えてくれます（当時のメーカーにとって、ソフトとは高額なメインフレームを売るためのオマケみたいなものだったので喜んでサポートした）。

その結果メインフレームの中には個別最適化のお化けができあがるのですが、その当時これが一番効率的だったので、メインフレームの担当者は「このやり方を続けたい、だって効率的だから」となるわけです。
メインフレームを使ってどのような業務を行っているか理解している人は社内のほんの一部でした。今でも「パソコンやシステムは苦手だから」と言って寄り付かない人が結構いますが、それと同じと思ってよいと思います。
その担当者が「これが一番効率的だ」と言っていることを会社として覆すこともできず（あるいは覆そうともせず）、メインフレームと同様の「効率的な」業務を実現するためのシステムが構築され、メインフレームの時と同様に適時必要な処理を作るサポートが継続されたのです。

この体質は高価なメインフレームを持たなかった中小企業にも引き継がれ「システムをカスタマイズして業務に合わせる」構造は広く日本中に定着したと考えます。

あれから四半世紀近くが過ぎましたが、当時とどれくらい状況は変わっているでしょうか。
社員のほぼ全員が１人１台パソコンや携帯電話を持つようになり、様々な業務がシステム化されていますが、経営層はそれを利用する部門や担当者がどのような業務を行っているか正しく把握して、「このやり方を続けたい、だって効率的だから」を覆せる知識と論理を持つことができているでしょうか。
ただ単に上意下達で「やり方を変えろ！」と命令しても、元のやり方を知らない人に変わったかどうか判断することはできません。費用をかけて導入したシステムは実は元の業務の焼き直しでしかないことは多々あります。
クラウド移行と言いながら「うちのやり方に対応できる＝カスタマイズに対応してくれるベンダー（＝十中八九既存システムのベンダー）」に依頼してせっせと焼き直しを行っている、それが冒頭の費用明細の「カスタマイズ費用」の正体です。

これは「サービスとして利用する（as a Service）」ではありません。
従ってクラウド利用ではありません（IaaSを使っていたとしても）。

経営層が「パソコンやシステムは苦手だから」といってシステムを利用する現場の業務を把握せず、クラウドサービスで経営上の恩恵を受けるために必要な知識やノウハウも学ばず、「システム更新時期だな、（流行ってるみたいだし）我が社のシステムもクラウドに切り替えるか」の一声で行われるクラウド導入は、メインフレーム時代から脈々と続く亡霊のような業務手順が温存され、現行システム焼き直しのためのカスタマイズで初期導入コストは高騰し、運用管理コストは何一つ軽減されない（むしろクラウド利用料によってコストは増える）という「クラウドのメリットを何一つ享受できていないクラウド化」が完成してしまうのです。

「運用管理コストの削減」は何が減る？

カスタマイズ云々の話はかなり大規模なシステムに対する課題ですが、その逆の小規模なシステムを考えてみたいと思います。カスタマイズをせずに既製品のソフトをベンダーの提示したマニュアル通りに運用してきた中小企業のオンプレミス業務システムの場合です。

オンプレミスの場合の運用管理コストをざっと洗い出してみます。

ハード更新や制度変更／法令改正はベンダー側から見ると運用管理ではなく更新案件かもしれませんが、例えばサーバOSやクライアントOSのバージョンアップ伴う改修はユーザー側から見ると機能的・業務的な付加価値がほとんど無いのに費用だけかかる運用管理的な業務です。

クラウド利用によってこれらの課題から解放され、代わりにランニングコストが発生するが相殺してもおつりが来る、というのが理想的なシナリオです。

しかしベンダー（が契約したSES）の運用要員が常駐して３や６を日々行っているような大規模システムではなく、中小企業で運用している埃をかぶったタワーサーバで稼働している10年物塩漬け熟成二次発酵中Windows2003Server現役ですみたいなシステムの場合どうでしょうか。担当者（仮想）に上記の１～６についてどのように運用管理をおこなっているか聞いてみましょう。

大げさに書きましたが、少なからず心当たりがある企業もあるのではないでしょうか。
このような管理（管理と呼ばないが）からクラウドに移行すれば、単純に言えばコストは増えます。正しくはこれまでかけていなかった管理コストがきちんと発生するようになったと言うべきでしょう。

逆にこういう企業こそクラウド移行して、これまで行ってこなかった管理を正しくお金をかけて末期的状況を脱却すべきなのですが、「システムはお金をかけて正しく管理しなければいけない」という意識が根本的に欠如している場合はただのコストとしてしか捉えられない恐れもあります。

きちんとシステムを運用していればクラウド化は負荷軽減になりますが、いい加減にしか管理しない場合はむしろ負荷が高まるかもしれません。

スケールアップやアカウント増減は絵に描いた餅？

クラウドのメリットとして負荷や利用者の増減によりリソースを追加（スケールアップ）したりアカウントを増減させることがありますが、これも少し気を付けなければいけません。

例えばWebサービスをAWS上で公開して、負荷によって自動スケールするように設定していたとします。そのサービスがテレビ等で公開されたことによりアクセスが瞬間的に増加した場合、自動スケールが追いつかずにサービスがダウンすることもあります。

別の例としてSFAを一人１アカウント利用していて、アカウント毎に料金が発生していたとします。ある社員が退職したのでアカウントを消そうとすると、その社員に紐づいていた案件も同時に消えてしまうので別の社員に振り分けようとするのですが、ステータスが正しく更新されておらず過去案件がクロージングしているかどうか判断できずに振り分けに時間がかかったり、共有をかけている資料が多すぎて所有者の切替が進まなかったり、アカウントを削除するとチャット等で過去に行っていた発言が全部消えてしまったり等の問題があり、結局なかなか消せないということが起きたりします。

クラウドがオンプレミスよりスケールが容易なことは間違いありませんが、機能を過信しすぎてはいけません。自動スケールにしていたためにいきなり想定をはるかに上回る費用が請求される可能性もあります。負荷と費用を勘案しながら適切なリソースとプランを調整するには、ある程度人の目が必要になる場合もあるのです。

SaaSだとアカウント廃止時のデータ引継ぎ等の機能にも注意を払う必要があります。社員が100名なのにアカウント数が200個もあり、しかも100個はデータ引継ぎできていない退職者アカウントなんてことになれば、かかる費用は倍になります。
アカウントの追加／削除の操作方法だけではなく、それを行った場合のルール（データ引継ぎ、履歴等への表示等）まで確認をしておくべきでしょう。

データを活用したいのにできない！？

業務機能はノンカスタマイズ、管理機能もノンカスタマイズですから、当然データの取込・出力もノンカスタマイズということになります。
基幹系業務だと受発注情報や会計システムへの仕訳データの授受等が想定されます。出力・取込のファイル形式・レイアウトが設定で変更可能か確認が必要ですが、最悪出力後にコンバートすることで回避することもできます。

ここまでは旧来からのデータ入出力についての危惧ですが、クラウドに限らずシステム内で蓄積されたデータを分析・活用していくというのがデジタライゼーションの方向性です。
オンプレミスであればシステムにデータ出力機能が無くても、データベースが社内にあるのでODBCなりJDBCでデータを抜き取ることが技術的に可能です。IaaS/PaaSでも同様です。

ただしSaaSでWebサービス提供のみの場合、システム自体にデータ出力機能を有していないとデータを取得することができなくなります。製品によってはBIツールが付属していたりしますが、一昔前にEUCとか呼ばれていたレベルのデータの抜き取りだけで、分析・活用には不十分な場合もあります。それすら無いとなると、せっかく蓄積したデータを活用することができなくなります。

付属のBIツールを基準にソフト・サービスを選択するよりは、生データでもいいのでデータ出力ができる機能の有無だけ確認し、分析・活用は外部ツールを活用するという選択でもよいと思います。付属のBIが優秀であるに越したことはありませんが、システム外のデータも活用した多角的な分析をしようとすると外部にデータウェアハウスを構築するほうが有効です。

データを１件ずつ呼び出してPDF帳票を出力するような仕組みではなく、最低でもデータ全件をCSV出力できるような仕組みが必要です。API連携で外部ツールがデータを読み込める等がベストですが、「優秀な付属BIツール」と同様にここに固執するよりシステム本体の使い勝手を優先すべきと考えます。

「リフトアンドシフト」はクラウド化か

カスタマイズの所の話と重複する部分もありますが、クラウド移行の方法として「リフトアンドシフト」という手法があります。
現行システムを仮想イメージ等で一旦IaaS/PaaSに移行（リフト）して、徐々にクラウドベースのサービスに更新（シフト）していくという方法です。

メリットとしてはハード等インフラの懸念を解消しつつ、サービス移行にかける時間を確保できることなのですが、この方法は賛否が分かれます。

インフラ面については確かにクラウドのメリットを享受できるかもしれませんが、肝心の業務は何一つ変わりません。うまく次期サービスへシフトしていければいいのですが、延命に成功した既存システムがそのまま生き残る余地を残してしまいます。

利用者側のシステムのリフトアンドシフトもデメリットを内在しますが、より悪いのが提供者側のシステムのリフトアンドシフト（というかリフトしただけ）です。

これまでオンプレミスの「〇〇システム」として提供していたソフトが「〇〇システムクラウド」という名前になり、クラウドベースのサービスが提供されるようになったのかとおもいきや、データセンターやパブリッククラウドで既存と同じソフトが稼働しているのをVPNやRemortAppsで接続するだけという代物も世の中には存在しています。

確かに「所有ではなく利用」ではあるのですが、ソフトライセンスの考え方も今まで通りの買い切りだし、SaaS利用なのにパブリッククラウドの利用料も何故か併せて請求されるし、WebAPI連携なんて言う高尚な機能はおろか、マルチプラットフォーム利用もできないという代物です。

こうしたサービスを提供するベンダーは、Webアプリの開発技術が無いというだけではなく、そもそも自分たちが提供しているソフトで実現している業務がWebベースになったときにどのように変わるのか業務設計することができないのです。
「業務ソフトを売っているベンダーが業務設計ができないなんて」と思われるかもしれませんが、ユーザー側もベンダー側も現在の業務（及びソフト）がどのような目的を達成するために構築されたものかという初期の知見は失われ、「こういう使い方（売り方）をする」というマニュアルと事例だけで「作業」をしているに過ぎない会社が多々あるのです。

自身で業務設計できないベンダーが提供するサービスを使い続けるとどうなるか。何の変化も起こりません。画期的な新機能はおろか、細かなUIの変更すらも無く、オンプレ塩漬けシステムと同じものをインターネットを通じてただ使うだけになってしまいます。

クラウドのメリットを享受する４か条

サービス選定は「先進性・継続性・発展性」のバランス

クラウド利用の一般的なメリット・デメリットほぼそのままです。

先進性を求めすぎると後発サービスにデファクトスタンダードを奪われたり、そもそも時代が付いてこれない可能性があります。必ずデファクトの製品がいいとは言いませんが、他サービスとの連動やAPI拡充等の発展性や、そもそも利用者が伸びずにサービス継続が危ぶまれる継続性の面でリスクがあるものは法人のシステム選定としては選びづらいです。かといって10年この方同じ味で勝負してますみたいなサービスも、時代に取り残されて同じ道を歩む可能性がありますし、新技術で得られる効果の恩恵に与れません。

継続性はサービスの内容だけではなく、提供している会社の経営状態、開発体制等も影響します。SIer系の会社は昔から「設立から今まで無借金経営です！」が売り文句のところが多いですが、在庫を持たず人的リソースは外注の増減で調整しているので当然と言えば当然です。急成長しているスタートアップは、知名度アップと市場占有率の確保のために利益度外視の価格設定と広告宣伝で売上は倍々ゲームだけど利益は全く出ていないというところも少なくありません。突然倒産してサービス終了までいかなくても、サービス内容が突然変わることは考えられます。

具体的な事例としてクラウド会計サービスを提供していた「会計freee」が、株式上場のタイミングで法人向けサービスを実質10倍値上げ（3,980円／月のプランで提供していた配賦等の機能が廃止され、39,800円／月のプランでしか使えなくなった）してSNS等で大きな話題になりました。一期も黒字化したことが無く累積赤字100億円、財務を健全化しなければ市場に受け入れられないことは理解するとしても極端な値上げは大きな反発を招きました。

ただしSaaSモデルの場合、低料金で利用者拡大→料金値上げで収益化は決して珍しいケースではありません。さすがに10倍は極端ですが、元の価格が安すぎて適正価格になったと思える範囲であれば利便性を優先しても良いのではないでしょうか。

最後に発展性です。テクノロジーの進化がプロダクトを日進月歩で発展させます。
今現在便利なサービスであっても、来年には他にもっと便利なサービスが提供されているかもしれません。発展しないサービスはこの流れに取り残されます。サービス開始から一度も機能が変わらないのであれば、インフラ面以外は塩漬けオンプレミスと何ら変わりは無く、むしろオンプレミスの方がコストが安い可能性すらあります。

ただしアップデートが必ずしも恩恵だけどは限りません。「改悪」と揶揄されるような利便性の後退も選択の余地なく受け入れざるを得ない場合もあります。

先進性、継続性、発展性のどれもが考慮すべきポイントですが、全部を求めれば価格に跳ね返ってくる可能性があります。その点GSuiteやOffice365は上記３点の全てが優秀で且つリーズナブルです。

「じゃあGSuiteを導入しよう！」「Office365を導入しよう！」となるかといえば、そういうわけにもいきません。そもそもGSuiteやOffice365で何をしようとしているのか、やろうとしていることに対して払う対価が妥当か考えなければいけません。
導入することで産み出される価値の大きさはソフトやサービスによってだけ決まるわけではありません。使う側がどう使うのかによって、価値は大きくも小さくもなります。

また導入するタイミングというのも考慮すべき要素の一つです。
決算期末でライン部門が多忙な時期にグループウェアの切替を行うなど狂気の沙汰ですし、利益やキャッシュを手元に残したいタイミングなら大規模投資は控えたいでしょう。

サービス導入が産む業務上のインパクト、導入にかけられる労力、導入直後のオーバーヘッドを乗り切る人や時間のリソース、検討すべきことはたくさんあります。これはクラウドだろうがオンプレミスだろうが同じことです。

また先進性・継続性・発展性の全てを兼ね備えた理想のサービスがあれば良いですが、必ずしも全てを満たすものが無い場合もあります。会社規模やIT投資予算との兼ね合いもあり、製品品質だけで自由にサービスを選択できるわけではありません。
落とし所というと妥協したように感じるかもしれませんが、最後は総合的なバランスを見る必要があります。「総合的」に評価する要素として、価格や機能だけではなく先進性・継続性・発展性を加味した判断をすべきでしょう。

「業務プロセスの一般化」と「自社の強みの内製化」

クラウド利用のメリットは利用形態によって享受されるものと利用者の運用方法の変化によって享受されるものがあり、前回紹介した「概念上の」メリットはどちらかといえば前者に該当します。

では後者のメリットはなにか。それは企業における「業務プロセスの一般化」です。「一般化」という表現が正しいか難しいですが、「効率化」や「近代化」では間違った伝わり方をすると思いあえて「一般化」にしました。

簡単に言えばメインフレームのオープン化の時にできなかった「ノンカスタマイズのパッケージに業務を合わせる」をやりきることです。パッケージが推奨する手順が本当に今より効率的なのかは「できたら効率的なほうがいい」くらいで考えたほうがいいかもしれません。とにかく非コア業務の事務作業手順は、現行の方法に拘泥せずに素直にソフトに合わせてしまうこと、それ自体が「効率的」なのです。

仕入先の選定や価格交渉等は事務作業ではありませんが、注文書や納品書の出力／受取やその結果の入力は事務作業です。そこに自社の独自性を見出してカスタマイズを求めるくらいなら素直にパッケージにあわせましょう。

自社の強みとなるコア事業は、他社との差別化のために先進性・独創性が求められることがあります。こだわるべきはそこで、カスタマイズやスクラッチ開発を通り越して自社で内製化する会社もあります。自社開発のハードルを下げたのもクラウドの存在と言っていいでしょう。IaaS/PaaSにより開発環境・動作環境が容易に立ち上げられ、クラウド＝Webベース開発が主流になったことによりベンダーに属さないエンジニアの数も増えています。

非コア業務のノンカスタマイズ利用とコア業務の内製化、どちらもがクラウドの恩恵を受けることができる方法です。とはいえ多くの非IT系企業にとって、システムの自社開発など経験したこともない未知の領域です。だからこそせめて「非コア業務のノンカスタマイズ利用」だけでも達成させるべきなのです。間違っても「非コア業務のカスタマイズ利用」で大事な経営資源を浪費してしまうべきではありません。

業務プロセス変更の難易度は非常に高いです。
既存業務の棚卸、業務手順の変更には多大な労力がかかります。でもそれは他人（コンサルやベンダー）に任せられる作業ではありません。あなたの会社の現行業務は、あなたの会社しかわからないのです。
社内のしがらみもあるでしょう。変化を嫌う保守的な層もいると思います。売上にも利益にも直接的に貢献しない内部システム導入であれば猶更です。やりきったって誰も評価してくれなければ途中で心が折れて「もうカスタマイズしてしまえば」と思ってしまうかもしれません。

ノンカスタマイズのパッケージ導入の難易度が高いのはテクニカルな部分ではなく、もっとベタで泥臭い社内調整なのです。「そんな前近代的で面倒くさいことしなければいけない会社でシステム導入なんかしたくない」と思われるエンジニアや情シスさんはたくさんいらっしゃるでしょう。しかしそれが現実です。そもそも「そんな前近代的で面倒くさいこと」が不要な会社は、今から外部の手を借りてシステム導入するような要件など残っていないでしょう。

データに基づく意思決定に転換する

SaaSのサービスからとりあえずデータが出力できるように、とは言ったもののそもそも何の情報を取得してどのように活用したいかのイメージが無ければ、結局活用せずに終わってしまうかもしれません。

出力したデータをどこに蓄積するのか、それをどのように可視化して、何の目的で誰に届けるのか、そのために必要な環境とツールは何にするのか。一次目的迄を明確にしておくべきでしょう。

前述したように外部ツールに蓄積して複数のデータを結合した分析のような形を目指すのも良いですが、最初から取り組むにはハードルが高いかもしれません。かといって定型的な統計帳票を出すようにシステムをカスタマイズするのも本末転倒です。
最初はBIツールでもExcelでも何でも良いのでまずは何種類かの定型的なフォーマットを出力できるようにしましょう。そしてその定型フォーマットを関連する会議体で必ず使用するように運用を変えていきます。

重要なのは「フォーマットを作ること」より「会議体の運用を変えること」です。
予算未達を叱責して次回の予算が達成させるような気合と根性の前近代的な管理ではなく、データに基づく分析から本質的な原因を追及し対策を講じる論理的・科学的管理ができてこそ、はじめてデータは活きてきます。
前月比・前年同期比・月別推移や予実対比などの比較データを提示し、異常値（比較元データと著しく数値が異なる値）の原因確認を中心に会議を進めるのです。
原因を分析しようとすれば、集計の元になったデータを個別に確認する必要があります。BIツールであれば集計元データのドリルダウン等も容易にできます。
意思決定者の階層によって見たい数値は違ってきます。現在Excel等でデータ収集・集計・加工している情報がどのようなものか、何の情報を管理する必要があるのか棚下しする必要があります。

データの切り口や粒度を変えて色々な見せ方ができるようになると、次第に新たな分析のニーズが出てくるようになります。各自が自発的にBIでデータ分析をするようになるにはかなりハードルが高いですが、まずは意思決定の場にデータによる判断を持ち込むことで、自分の主張を通すためにはデータに頼らねければならない状況を作っていくのです。必要性のあるものは自然に覚えていきます。

「魔法の杖」の夢から覚めて、自社の人的リソースを整備・育成する

一口にクラウドと言っても、企業が対象にする領域はデジタルマーケティング、営業支援、生産・調達・物流などの基幹系業務、グループウェア・ストレージなどのコラボレーションツール、サーバやハードウェアの仮想化まで、何をターゲットにするかによって効果は様々です。

しかし全てに共通して言えることは、クラウドは「魔法の杖」ではないということです。
IaaSに移行してしまえば、SaaSでサービス利用さえしていれば、当社のクラウド化は進んでいて2025年の崖も怖くないなんてことは無いのです。

業務プロセスの一般化やデータに基づく意思決定への転換を決意し、その手段としてクラウドを選んだ場合、クラウドは強力なツールになります。早期サービス立ち上げにより改革の速度を加速させ、ベストプラクティスによる業務標準化をサポートし、様々なデータ分析・加工ツールを提供してくれます。
それを推進するのはクラウドサービス自身ではなく、業務標準化のために既存業務を棚卸して新業務フローに合わせるために苦戦したり、データ活用のために意思決定方法の変更を全社に展開・浸透させたり、それら各サービスやツールについての問合せに適時対応できる製品知識と業務知識とテクニカルスキルを併せ持った人材です。

「そんな奴おれへんやろ〜」とこだま師匠に言われそうですが、実際に多くの企業、特に中小企業が必要としているのは、プログラマーでもWebデザイナーでもAIスペシャリストでもデータサイエンティストでも無くこの領域だと思います。
そして情シスがその人材になることが求められることになるでしょう。外部コンサルに頼ることもあると思いますが、社内調整には内部メンバーが必要ですし、自社の業務や意思決定プロセスを把握して社内の調整を行えるのは社員なのです。

経営層もその覚悟を持ち人材を確保・育成することを理解してもらう必要があります。
何度も言いますが、クラウドは「魔法の杖」ではありません。動作環境がインターネットの向こうにあるだけのシステムです。しかしそこにはこれまでのオンプレミスでは得られない恩恵がたくさんあります。それを享受できるかどうかは受け手である企業次第なのです。