既存のルールは既得利権者が作ったもの
既存のルールは既得利権者が作ったものであるかもしれないので、少しくらい無理をしてでも既成事実を作るという方法はイノベーションを生むために必要な方法かもしれない。
でもそこを打ち崩すのは労力大変なのよね 金も仲間もむこうにあるわけだから
同じ業界に今はいるが、PCのスペックは別に良くはないが開発に困ることはない程度。開発関連で妙に長い承認フローはなく、入れたいものは言えばOKしてくれる観客かな。
子供の頃、コンセントの両穴に針を差し込んで、その間に針を渡そうとして感電した事があったのを思い出した。なお実績
採用した企業側の問題なんだよなあ。多分別の場所なら輝く余地があったはずなのに…
行先さえ言えば、ちゃんとメーターを回して適正な金額を伝えてくれるタクシーというものは、実は世界的に見てレアなのかね。こんな小難しい分析をしてしまうくらいには。
メーカーの本体は蔵に入れるまでが責任で、販社が顧客と接するから不具合入れた時のコストが大きく保守的にならざるをえない。メーカーは、ソフトのビジネスに向かない。
「日本は近い将来に台湾並みになり、マレーシア並みになる。そこで止まらず、インドネシア並み、ベトナム並みになるのもそう遠い将来のことではないかもしれない」 経済
日本だとロビイングということなんだろうか / "今後重要になってくる起業家の資質の1つを「政策起業力」という言葉を使って説明しています。" スタートアップ社会
SIer内のデータサイエンティストの役割と働く環境としても魅力ないんだよね
SIer内のデータサイエンティストの役割
データサイエンティストの仕事ってモチベーションあがらんのよね
ゴールまでが遠くて
しかもユーザが数字にうといと、結果がでても、ふーんでおわってしまう
しかもデータを所有する企業って大きめの企業が多いから
打ち合わせもつまらんし
働く環境としても魅力ないんだよね
現在、日立は3000人、
富士通は1500人、
NECは1000人など
SIer各社がデータ活用人材の確保・育成を打ち出している
SIerは、データを保有するお客さまと分析技術を保有する自社の連携により、データの価値を競争力に転化して新たな事業を創出することを理想としています。
しかし、現実にはデータの価値を収益化するのはなかなか困難であり、多くの場合はお客さまの中にデータを活用する業務を作り出し、それを実現するシステムの構築、つまり従来のSIの仕事に帰着している現状があります。たとえば、データ分析基盤やデータ分析の結果を業務に活かすシステムの構築など
それでも、従来はお客さまへのヒアリングを起点に「機能」で要件を定義して問題解決につなげてきたのに対して、お客さまの業務・運用で日々蓄積される「データ」を起点に問題解決につなげる試みは、新たなSIのアプローチ
その中で、前述のAIの実装技術者は、学習済みAIモデルをお客さまに提供するという点で成果物(お客さまへの納入物)がはっきりしており、旧来のSIビジネスの枠組みで考えることができます。彼らは、今後発生するデータの分析を自動化する仕組みを構築します。ビッグデータを扱うことが前提となるため、周辺の社内システムと連携する大規模なデータ活用基盤の構築の仕事にもつながりやすい
一方で、統計解析手法によるデータ分析技術者は、現場の実務やデータに精通したお客さまと緻密に連携し、対話の中から分析のヒントを得たり勘を掴んだりしながらデータ分析を代行する役割であり、データ分析の知見を労働力の形で顧客に提供
ただセールスフォースがAIのサービスはじめたり
IBMはワトソンだったり、独立系ではc3aiだったりと
何やらにぎやかにはなりはじめてるんだけどね
このため、成果物や目的が明確にならず、SIerのビジネスにおいて「なぜこれに取り組むのか」が分からなくなってしまう場合があります。統計解析手法により導き出された問題解決の方法が、必ずしもITによる方法にならないのです。これがSIer側のPoC継続のモチベーション低下を招き、お客さまとのWin-Winの関係が崩れ、PoCの終結につながる恐れがある
企業のワークロードのうち35%がクラウドを介して行われる。今後1年間で55%に上昇
企業のワークロードのうち35%がクラウドを介して行われる。って日本だとまだまだすくないだろうな
この1/4ぐらいじゃなかろうか。
日本ではこの値がこれから増えるだろうけど
ITにうとい経営者と中間管理職を
クビにして、エンジニアを大事にする文化にならないとまだまだ衰退は続きそう
最近のリモートワークの風潮を背景にますます多くの企業がクラウドへと戦略的なシフトを進めており、
これがAzureの著しい成長をもたらしている。
コロナワクチンの接種が世界的に拡大することで、
労働者は年内に職場復帰が可能になり、
リモートワークへのシフトは緩らぐ可能性があるとした一方、
企業がワークロードをクラウドに移行する傾向は続くと同氏はみている。
現在、
企業のワークロードのうち35%がクラウドを介して行われると推定。
この割合は今後1年間で55%に上昇すると同氏は予想している。
20年7~9月期の世界のクラウドサービス市場におけるシェアはアマゾン AWSが32%。
Azureはシェアを19%まで拡大している
中国テック企業創業者は自社株売ってるのブームなん?
Anaplanってどうなんやろなー。kintoneで似たようなのつくればそれでいいんじゃないの?
Anaplanってどうなんやろなー。kintoneで似たようなのつくればそれでいいんじゃないの?
予算策定の「脱・Excel」、Anaplanで実現するリアルタイムの計画業務と着地予想
SaaSで計画ソリューションのプラットフォームを提供するAnaplan
あらゆる計画業務をサポートするために生まれたAnaplan
Anaplanは2006年に英国のヨークでMichael Gouldが創業した企業です。
彼は2003年にCognos(現IBM)に買収されたAdaytum Softwareで、ビジネスプランニングツールの開発責任者を務めていた人物です。
Cognosとの製品統合プロジェクトに従事した後、ゼロから最新テクノロジーを活用したビジネスプランニングのための全く新しいプラットフォームを開発するべく独立し、Anaplanを起業。
2008年にプロトタイプが完成、2010年に第一号顧客を獲得し、現在は世界13カ国、1400社超の幅広い業種のお客様が利用中です。
現在は米国サンフランシスコに本社を置き、2018年10月にはニューヨーク証券取引所への上場
日本では、三菱電機、パナソニック、オムロン、コニカミノルタなどの製造業を中心に導入
Anaplanの社名は「Analytics + Planning」に由来していて、その名の通り、私たちのビジネスの主軸はプランニングとアナリティクス
一つ目のプランニングのスコープは特定のドメインに限定されるものではありません。
経理・財務の他、営業、サプライチェーン、人事、ITに至るまであらゆる計画業務に対応できるのがAnaplanの特徴です。
もう一つのアナリティクスでは汎用的な分析ではなく、計画に関する分析の機能を提供しています。
例えば、計画を作った後の実績との比較、プランAとBのどちらが良いかを比較するシミュレーションがAnaplan上で可能になります。
多くの日本企業の経理部門にとって、中期経営計画や年度予算の策定と実績管理の業務を進めるのは継続的な業務ではありません。
典型的な日本企業の財務計画策定プロセスの問題はどこにあるのでしょうか。
計画業務は年間スケジュールが決まっていますが、一度の策定で終わるわけではありません。
3月に年度末を迎える企業の場合、予算編成を行うのは通常1〜3月で、4月以降は、毎月計画通りに進んでいるかを分析し、計画に乖離がある場合は見直しを行います。
この予実管理は次の予算編成までずっと続きますから、作りっぱなしではないことを強調しておきたいと思います。
本来、組織における計画業務の目的は、将来のある特定の時期における見通しを立てることにあります。
私たちが夏休みにどこに行って何にお金を使うかの計画を立てるように、年度末の売上見通し、月末の費用の見通し、今週の在庫保有水準、新年度の採用人数など、将来の予測を行うことがビジネスではとても重要です。
ところが、この将来予測をしたいと思った時、社内のシステムのどこを探してもその数字はありません。
どこにあるのかというと、人の頭の中です。
例えば、販売計画の場合、どこの会社をターゲットに何をいくら売るかは、人の頭脳(過去の経験からこれだけ売れそうという読み)、もしくは気持ち(とにかくこれだけ売るんだというガッツ)を統合して作ります。
システムにあるのは過去の実績データですから、この人の気持ちを集めて調整する「意思入れ調整」はRPAを使っても自動化することはできません。
また、担当者が時間と手間をかけてやる割には、不正確なものしかできないというジレンマを抱えています。
私たちがグローバルで調べた結果によれば、約8割の企業がExcelに代表される表計算ソフトとメールで計画策定を行うとわかっています。
具体的には、担当者が表計算ソフトでフォーマットを作り、関係者に「入力してください」とメールで送る。
入力してもらったシートが返ってきたら、集計し、レポートにまとめる。
その際、戻ってきた数字の妥当性のチェックや部門間の調整も必要です。
本来であれば、一元管理しているデータを「今はこうなっているが、期末の着地はこうなりそう」を予想し、関係者全員でディスカッションをして次のアクションを決めることに使ってほしいところですが、
これでは「作業」で終わってしまっています。
表計算ソフトとメールを使う計画策定では、情報のサイロ化とセキュリティが問題です。
計画には個人の思いや意思が反映されますが、それが個人のPCの中に分散していると、時間差が原因で、ある部門が言っていることと別の部門が言っていることの整合性が取れないことが起きてしまいます。
また、「クラウドの導入はセキュリティが心配」という会社は多いですが、クラウドファーストの時代にあって、表計算ソフトとメールでのやりとりを維持する方が情報漏洩リスクは高いのではないでしょうか。
計画担当者は企業の中ではエース級の人材が揃っています。
その人たちがもっと知的で付加価値の高い仕事ができるように業務プロセスを変えてもらうことがAnaplanの狙い
Anaplanは計画担当者のためのSaaSツールとして提供されていますが、私自身はPaaSに近い
従来のEPMが財務計画だけに焦点を当てているのに対し、Anaplanでは計画業務を水平に捉えていて、対象が財務か否かは問わず、Anaplanという単一プラットフォーム上に機能横断的に計画アプリケーションを構築できます。
今年からガートナーがExtended Planning & Analysisという概念を提唱するようになっていて、2024年までに70%の計画のスコープが財務単独からその他の機能ドメインにまで拡張するという予測をしています。
予実管理では財務だけでなく他の機能との横連携を考慮しなければならないと気づき始めたわけで、コネクテッド プランニングを以前から提唱しているAnaplanは将来の市場ニーズと合致したプラットフォームを提供していると考えています。
例えば、3カ年の中期経営計画があり、1年目が終わった段階だとしましょう。
計画には財務計画はもちろん、販売計画やその他のオペレーショナルな計画を伴っています。
2年目の計画における売上を下方修正したら、3年目の着地見込みがいくらになるかをAnaplanではすぐにシミュレーションすることができます。
もう一つ、単年度計画で、営業がある製品の売上目標を変えると、調達部門は関連する部品の調達計画にどんな影響があるかをリアルタイムに確認できます。
表計算ソフトでやっていると、ある数字を変えても別の表計算ソフトのシートで管理されている他の数字は変わりませんが、Anaplanでは関係者全員が信頼できる共通の数字を基にディスカッションを行うことができるので、意思決定をより迅速に行うことができるのです。
計画策定時の調整は残りますが、調整結果を全部門が共有できるように変わります。
端的に言えば、作業中心の業務が分析中心にシフトします。
あるお客様がAnaplanを導入する前に話していた印象的な言葉に「部下が表計算ソフトのシートを配って、集計して仕事した気になっている」というものがあります。
本来は集めてきたデータを使い、経営層にアドバイスをするのが財務プロフェッショナルとしてのあるべき姿です。
そうなるように変えるのがAnaplan
「強気」[弱気」の比較ができれば可能な着地見込みの予想
2つの例を紹介しましょう。
一つはオーソドックスなシナリオシミュレーションの例です。
図3では、製品の販売計画を例にベースの計画と、売上成長率が強気の場合と弱気の場合の2つの計画を作り、それぞれを比較できるようにしています。
これは売上だけのシナリオですが、費用のシナリオもベースと強気、弱気で作り、組み合わせて売上は強気、費用は保守的にして、期末のP/Lの着地見
込みを確認することができます。
P/Lだけでなく、B/SやC/Fに展開することもできますから、手持ちの現金が予定水準を下回ったらアラートを出すようにして、資金繰りの最適化に役立てることができます。
もう一つの例は、中長期の戦略テーマに合わせてシナリオを作るものです(図4)。
例えば、「サプライチェーンを強化する」というテーマに合わせ、「一般管理費を予定より10%削減する」場合の財務諸表へのインパクトを勘定科目レベルで確認することも可能です
シミュレーションができれば、最近のコロナウイルスの感染拡大で計画の前提が崩れた場合でも、見直しを行うことで「この製品の売上回復は秋口になりそうだ」などの着地見込みが見えてきます。
また、製品の需要計画を起点に売上がどう変わるかを見ることもできますし、サプライヤーへの部品発注をどうするかを検討し、次の手を迅速に打つこともできます。
多くの企業で着地見込みの予想ができないというのは、複数の計画を作り、比較できないから困っているのではないでしょうか。
いろいろなケースがあると思いますが、Anaplanはそこで困っている人たちのサポートに使えるツールだと考えています。
最後にこれから経営管理の高度化を真剣に考えている企業に向けてのアドバイスをお願いします。
組織全体で同じプラットフォームを使うことを考えると、予算策定のタイミングに合わせるのがベストです。
とは言え、作った予算に対する実績の評価は常に行なっていることですから、今困っているのであれば、検討を早く始めれば始めるほど、早く成果が得られるとも思います。
最近では、ERPをS/4 HANAに移行するプロジェクトが終わるまで、計画のことはとても考えられないというお客様も多いのですが、2025年まで表計算ソフトとメールで我慢するのは辛い。
でもAnaplanであれば、アジャイルに導入を始めて、数カ月後に一部の部門が使い始めることも不可能ではありません。
コロナをきっかけに、できるところから経営管理の高度化に向けて計画業務の見直しを始めてみることをお勧めします。
IBMはクラウドでいろんなサービス提供するより、IBM Cloudをとりあえず落ちないようにすることが大事だろな
IBMはクラウドでいろんなサービス提供するより、IBM Cloudをとりあえず落ちないようにすることが大事だろな
日本アイ・ビー・エム(IBM)は、金融業界のデジタル化の支援に注力する方針を発表した。第一弾として、認証、届け出の処理、口座の照会・振替、資金移動などに対応したAPIをクラウド経由で提供するサービス「金融サービス向けデジタルサービス・プラットフォーム」(DSP)をリリースした。システムの要件が共通する場合に、複数の金融事業者がAPIを共通利用できるのが特徴。業界内のシステム連携のニーズに対応する。
提供するAPIは、2020年5月時点で81種類。年内に147種類に増やし、2021年3月までに181種類に拡大する計画。金融事業者は、各APIを使って既存の基幹系システムにIBMのサービスをプラグインし、機能を柔軟に拡張できる。これにより、各社がサービスの仕組みを変更するたびに基幹システムを改修する手間を省く他、ワークロードの複雑化や運用コストの増加などを防ぐとしている。
先行事例では、導入企業の開発コストを40%削減し、サービス提供までの開発期間を30%短縮するなどの効果を確認したという。
DSPのAPIは、同じ米IBMグループの米Red Hatが手掛けるコンテナ基盤「Red Hat OpenShift」の上で開発。オンプレミスとクラウドを問わず、あらゆるシステム基盤で稼働する。21年3月からは、金融機関に自社のパブリッククラウドサービス「IBM Cloud」を提供し、その上でDSPのAPIなどを運用するマネージドサービスも始める予定だ。
IBMは今後、DSPの他にも金融機関に多様なサポートを行っていく計画。
(1)基幹系システムを簡素化するサービスの提供
(2)金融機関に特化した、可用性とセキュリティ性能の高いパブリッククラウドの開発と提供
(3)金融機関向けの人材育成サービスの提供
これらの戦略をまとめて「金融サービス向けオープン・ソーシング戦略フレームワーク」と称しており、順次スタートする