• 純国産ETL:データ連携ツールのWaha! Transformer > 
  • ERP移行・基幹系システムの再構築を成功させる5つのステップ
  • ERP移行・基幹系システムの再構築を成功させる5つのステップ

    • LINEで送る
    • このエントリーをはてなブックマークに追加

    ※本トピックは、withコロナの2020年7月に公開しました。

    いきなりの質問からで恐れ入ります。
    皆さんは昨年、どれぐらいの税金を払いましたか?

    私はまったくわかりません。(できれば、多くの方が同じ答えであることを願ってやみません。)
    所得税はおおよそ見当がつくとして、消費税や海外通販で支払った関税、酒税や入湯税などなど、いったい私たちはどれぐらい納税しているのでしょう?

    以前、会計士の先生と食事をご一緒する機会をいただいた時に、そんな話しになりました。
    会計士いわく

    私だって個人の納税総額なんて把握していないし、知ってしまったら後悔するだろうから調べる気も起きない。

    と、口角泡を飛ばしながら堂々とおっしゃっていました。

    でもその時に、日本国憲法に定められた国民の三大義務の話しになりまして、

    教育・労働・納税って言うでしょ?あれって義務教育→就職→納税のように時系列やライフステージで解釈してる人が多いんだけど、国家の立場になって見方を変えると面白い話しなんですよ。
    我々のようにビジネス社会で生きる人間を国家から見た時、実はゴールに納税があって、そのためにコツコツ働いて納税の原資を稼ぎなさい、その原資を増やすために毎日勉強して知恵とスキルを磨きなさい。って意味での義務なんですよ。

    といった講釈を拝聴し、生まれてはじめて憲法なるものを身近に感じたのでした。


    日本国民の三大義務:「教育」「労働」「納税」


    今回のテーマはERP:基幹系システムの移行・再構築としていますが、冒頭に納税の話しをしたのはERPの定義のためでした。
    要するにERPとは、経営資源である「ヒト・モノ・カネ」の動きをリアルタイムで記録・蓄積して、毎日いつでも納税できる“ぐらい”のデータ管理をしておくものなのではないかと考えたわけです。

    もう一つ経験談で恐縮ですが、私の親類に税務当局の職員が加わったタイミングがありまして、法事の後に食事していた時の話しです。
    当時在籍していた会社が2年連続で税務調査を受け、その対応で情報システム部門に在籍していた私が結構な工数を要したことを軽くクレームしたのですが、見事に論破されてしまいました。

    事情は知らないけど、2年連続の税務調査ということが利益を出し続けていることなんだとしたら、それは誇るべきことですよ。
    ただ、手間がかかったことについてどんなやり取りがあったかは別として、財務会計に関するデータがどのようなプロセスを経て記録され・確定しているのか、その妥当性や透明性など含めて一目瞭然になっていれば楽なんじゃないかな。
    そうすればあれこれ詮索されることもないはずだし、それ以前に、普段の仕事もしやすくなると思うんですよね。


    お説ごもっとも。「こんなところでクレーマーの真似事する前に、BPRちゃんとやれ」とたしなめられてしまったわけですね。

    今回は、以前のトピック「CIO・情報システム部門のミッション考察」の続編として、ERP移行や基幹系システムの再構築を目的ではなく手段と位置付けて、「So What?, Why So?」のアプローチで考察してみます。

    ※筆者注:
    税務調査の選定経緯は単純でして、リストラ不況やコンプライアンス不況と呼ばれていた時代にありながら、順調に営業利益を伸ばしていることに対する興味だったそうです。
    粉飾決算や脱税といった不正の要素は微塵もなく、業界内でも“○○正直”と揶揄されるぐらい真摯で誠実な経営姿勢を持つ優良企業での経験談であったことを添えさせていただきます。

    ~目次~

    長文になってしまったのでお急ぎの方は、最後の【まとめ】からご覧ください。

    ERP移行や基幹系システムの再構築を成功させる5つのステップ
    ERP移行や基幹系システムの再構築を成功させる5つのステップ

    “美しい情報システム”とは?

    先ほど登場した親類はさらに言ったのでした。

    実は今の話し、自分が担当したとある企業の受け売りなんです。まだ若手だった自分に、勉強になるから行ってこいと言われて補佐役で調査に携わった会社なんですけど、それはそれは美しい情報システムでした。

    調査期間中も毎日最新のデータが入ってくるので聞いてみると、新卒でも中途でも新入社員研修ではお金の取り扱いについて徹底的に叩き込まれ、新卒の若手でさえ経費精算の時に会計科目の仕分け付きで毎日入力されますし、客先への移動時間まで社内標準原価に置き換えて自動集計されているんです。

    顧客一人ひとり・製品1個ずつの出荷あたりというビジネス単位の付加価値生産性が、いつでも見えるようになっているんですから、情報システムの大前提として、使途不明金なんてものが発生する余地がないんです。

    もちろん何年にも渡って利益を出し続けて投資もされてましたから、「あれが本当の優良企業なんだ」と、勉強に来た意味を先輩が教えてくれたものでした。

    いかがでしょう?
    企業内の情報システムを形容する時に、“美しい”という言葉を聞いた体験をお持ちの方はいらっしゃるでしょうか?

    皆さんが企画されているERPの移行や基幹系システムの再構築は、“美しい”と称されるようなものになるでしょうか?

    経営資源である“ヒト”の動きも“モノ”の動きも世界共通言語である“カネ”や“時間”に置き換えて、発生ベースできちんと記録され、いつでも取り出せるようになっているわけですから、ERP:Enterprise Resources Planning どころか ERO:Enterprise Resources Optimization/経営資源最適化システムと呼べるレベルになっているのでしょう。

    基幹系システムの構築は、ビッグピクチャーを描ける数少ないチャンスだと思いますので、ビジネスエグゼクティブや監査法人はもちろんのこと、税務当局からも“美しい”と評されるような絵を描いてみようではありませんか。

    ERP移行や基幹系システム再構築のプロジェクトオーナーは誰か?

    “ヒト”が使う基幹系システムをつくる“ヒト”、プロジェクトオーナーは誰が担うのがよいのでしょうか?

    CEOやCOOでないことは明らかで、CFOやCHROでは荷が重すぎると思われますし、ましてやCIOはプロジェクトマネージャーとして納品責任を担う側ですから客観的な意思決定は難しいでしょう。

    本トピックではその役割を、生産部門・商品部門のトップが担うべきと考えます。

    その根拠は極めてシンプルで、メインフレームやオフコンの改廃、ERP移行や基幹系システムの再構築といった機会は、以前のトピックで掲載した「顧客中心経営」を具現化するものと考えるからです。

    ERP移行や基幹系システム再構築のプロジェクトオーナーは誰か?
    某グローバル製造業の統治機構図(CDO版)

    この統治機構図であれば、「デジタライズ」のボックスが生産部門の責任者でした。

    この図を掲載したトピック「CIOのミッション考察」に対しては、「2000年代の中盤に“デジタライズ”の責任者がいるのはおかしい。」といったご指摘をいただきましたが、こればかりは“実際にいた”らしいのですから、このグローバル製造業の先見性と先進性には驚くばかりです。

    一方、経済産業省が「DXレポート」を公表したのが2018年ですから、既に日本は2周も3周も遅れていることになり、ノンビリ構えていられないという危機感だけは共有していただけるはずです。

    ただ、Googleトレンドを見ると、日本でも2004年には[デジタライズ]の検索が一定量あったようですから、ビジネス現場では悲観するほどの遅れにはなっていないであろうところに期待が持てます。

    良い商品を佳き顧客に届ける責任者がCDO

    このグローバル製造業から学べるところは、生産部門・商品部門の責任者が「デジタライズ」を担っている点でしょう。
    日本国内のDX文脈で語られがちな新設部門やCIOのミッション拡張ではなく、「良い製品・サービスを供給し続け、佳き顧客に市場で選ばれ続けるためのデジタライゼーション」として、CDO:Chief Digital Officer(最高デジタル責任者)が選任されていることです。

    先のトピックで触れたように、このグローバル製造業は地球上のあらゆる場所で、産業財も消費財も生産・供給していますので、事業部制が主軸であることは想像に難くありませんが、各事業部長を束ねるポジションが既にあり、CDOの観点を加えてサプライチェーン全体を統制していると思われます。

    ではなぜ、基幹系システムの再構築というプロジェクトのオーナーが、そのCDOであるべきと考えたのでしょうか?

     

    「(仮称)2030年に勝ち残るビジネストランスフォーメーション」プロジェクトを立ち上げる

    2030年に勝ち残るビジネストランスフォーメーション
    2030年に勝ち残るビジネストランスフォーメーション

    まず一つ、発展途上国中心でありながらなぜか日本でもバズワード化してしまった感の強いDX:Digital Transformationは一度頭から消し去って、2000年頃に戦略系コンサルティングファームで言われれていた「ビジネストランスフォーメーション」をテーマにしてみましょう。

    なぜ、DXではなくビジネストランスフォーメーションを目的として掲げるのでしょう。
    それは、DXと類似する BPR:Business Process Re-engineering(ビジネスプロセス・リエンジニアリング)が現状を起点にした積み上げ・現状追認型で演繹的な取り組みであるのに対し、“10年後の姿”から帰納的に取り組むことに価値があると考えたからです。

    奇しくも、この記事の下書きをはじめた頃の“beforeコロナ”が“withコロナ”に変わり、「ニューノーマル:新しい日常」として人類全体にトランスフォーメーション(変革)が突きつけられてしまいましたが、私たちを含めて多くの現場では目先の状況に適応していくのに精一杯、“afterコロナ”に向けた変革は仮に検討課題に掲げられていたとしても、ついつい先送りになってしまっていると思われます。

    であれば尚更、この状況を神が与えてくれた機会:チャンスと捉えてみてはいかがでしょうか?

    DXレポートで示されたような部分最適ではなく事業全体のあり方として、10年後の未来に向けて変革すべきものと残すべきものを仕分けした後に、変革後に必要なインターフェースの一つとして、ERPや基幹系システムの再構築を位置付けてみてはいかがでしょうか。

    • 私たちは10年後も、今の情報システムを使い続けていたいのでしょうか?
    • その前提となるビジネスプロセスが今のままだとしたら、10年後も今の職務を続けていたいと思いますか?

    これまでのERP導入や基幹系システムの移行で聞かれた失敗事例では、「今使っているインターフェースがそのまま使えるようにしてください!!」という強烈なプレッシャーがエンドユーザーから寄せられ、新システムにはなかった画面・ビューを追加でかぶせた結果、パフォーマンスが劣化するばかりかバグをあちこちに内在させてしまったという声が少なくありません。
    今回、エンドユーザーに聞くべきは「自らが10年後に働いている姿」ですから、起点になるのは現状でも過去でもなく、未来であることを強く認識してもらう意味でも、前述のような質問を調査・分析フェーズに盛り込んでみるとよいのではないでしょうか。

    • “同じ釜の飯を食う”従業員すべてが、自分ゴトとして10年後のビジネスプロセスを考える。
    • 他人事で現状維持に固執しがちなシステム化要件をゼロベースで定義できる。

    情報システム部門にとってこんなにワクワクするシステム構築は、この機会を逃せば一生巡ってこないであろうと思えるプロジェクトが、「(仮称)2030年に勝ち残るビジネストランスフォーメーション」というプロジェクトなのです。

    ビジネストランスフォーメーションを、ERP・基幹系システム再構築の親プロジェクトにする

    • 部分最適な情報システムに矮小化されたものではなく、まず、10年後の事業全体のあり方を視覚化・共有する。
    • そのプロジェクトのオーナーは、事業全体の中核である商品部門・生産部門の責任者が担い、外部の専門家組織が客観的な調査・分析結果をもって提言を残す。
    • これら全体最適の合意形成プロセスを経てから、そこに紐づく個別最適の一つとして“美しい”情報システムを再構築する。

    このような取り組み方が唯一無二の正解などと言うつもりは毛頭ありませんが、過去にERP移行や基幹系システムの構築で失敗体験を持つ組織には、ぜひ検討していただきたい戦略として考えてみました。

    もちろん、このような進め方を認めてもらうには、CEO/COOはもちろんのこと、プロジェクトオーナーとして適切な人材が社内にいてこそであり、その方々が“本気のやる気”を見せてくれないことにはそれこそ絵に描いた餅になってしまうことは明白です。

    もし、CIOや情報システム部門長が彼らを説得し、“本気のやる気”を生じさせることが難しい場合は、私たち日本人が得意な“外圧”に頼らざるを得ません。

    そんな時でも役に立ってくれるのが、戦略系・ビジネス系のコンサルティングファームのはずですから、これまで述べてきたような問題意識と対策素案について、より良き戦略を提言・推進してくれるコンサルティングチームに代弁してもらうという意味でも、次項の進め方をご検討ください。

    親プロジェクトの実行は、客観的かつ合理的な判断基準を持つ外部の専門家組織を活用する

    経営幹部が親プロジェクトの実行に“本気とやる気”を見せてくれたら、経営トップ直轄で任命されたプロジェクトオーナーがまずすべきことはプロジェクト体制の構築です。

    今回は、「10年後のビジネスプロセスをリ・デザインする」プロジェクトですから、当事者である部下たちはネタバレになるので中核メンバーとしてはアサインできません。
    また、相応のキャッシュアウトを伴って外部委託する際は、バズワードを並べ立てただけのアウトプットでお茶を濁されては本末転倒ですから、世界各国で同様のプロジェクトを担い、その知見・失敗事例も活かしながら成果を出してくれる矜持(プライド)と実績も求めたいとなると、外部の専門家組織にリーディングしていただくのが得策です。

    過去に所属していた組織での失敗談をご紹介しますと、
    その時はもっとスコープの狭い人事関連のプロジェクトでしたので、オファーした戦コンのトップ3はすべて提案辞退となり、部下任せだった人事部長はトップから「推進能力なし」とプロジェクト開始以前のところで大目玉を食らいました。さらに、慌てて追加オファーした総研系のファームは調査・分析フェーズが時間切れとなって即効策だけアウトプットしてもらうという顛末で、そこに紐づいた人材管理システムの再構築も大炎上させてしまいます。
    結局は、新規人材管理システムは返品同様の状態で捨てられることとなり、情報システム部門主導で元からあった人事給与パッケージに追加カスタマイズを施すことで表面的に収束させるという、大損害案件を目の当たりにした経験があります。

    この失敗事例から学べることは、コンサルティング・スキルのない先に依頼してしまうと、言われたことに対応するだけ=課題解決型のアプローチになってしまうことです。
    オファーから提案に至るプロセスの中で、[So What? / Why So?]が染みついているプロフェッショナルとしての知見から本質的な問題を推定し、仮説検証型で深堀りしてくれるコンサルティングファームに依頼する方が、結果的に費用対効果の高いプロジェクト成果が得られるのではないでしょうか。

    コンサルティング:「分解と統合」が甘いから誤った解答になる
    コンサルティング:「分解と統合」が甘いから誤った解答になる

    やはり今回の「ビジネストランスフォーメーション」というスコープなら、戦略系コンサルティングファームのトップ3と称させるような外資系が第一候補となってしまうのでしょうが、可能であれば日系のビジネス系・総研系と称されるようなところにも初期のオファーを出してみて、提案辞退が発生した時のバックアップを用意しておきましょう。

    その時に大事なこととしてコンサルティングファームへのオファーでは、プロジェクトオーナー自らが窓口となることです。
    “○○企画室”と呼ばれるように決定権を持たないセクションとそのマネージャーを介在させることは、コンサルティングファームから“本気ではない”と判定され、オファーに対する真摯な提案が得られないことが少なくありません。
    普段から部下に対して「オーナーシップ:当事者意識を持て」というのであれば尚更、本件では部門長自らがオーナーシップの持ち方や立ち居振る舞いを体現していただくことで、魂の入ったプロジェクトがスタートできることでしょう。

    ビジネストランスフォーメーションのアウトプットの中で、ITプロジェクトのビジネス要件を明示してもらう

    親プロジェクトの「ビジネストランスフォーメーション」からは、業務分析の結果として導き出されたビジネスプロセス(実際には業務フローとデータフロー)の before/after と共に「JD:Job Description(ジョブディスクリプション:職務記述書)」をアウトプットしてもらいましょう。リンク先のWikipediaにも記載されているように、“人ではなく「ポスト」に用意されている文書”ですから、旧来型の“適材適所”という考え方も“適所適材“に変革していくことが求められます。

    なお、有効なJDを作るために忘れてならないことは、対象者全員が網羅された「スキル(技能)マップ」と、組織ごとに必要とされる職務一覧「ロール(役割)マップ」がセットで必要になることです。

    2000年代に多くの日本企業が雪崩を打って導入した「成果主義」が成果を出せないまま放置されているのは、組織横断で成果を評価するために必要な社内標準が定義されていないことに起因すると言われていますから、ビジネストランスフォーメーションの before/after を検証する意味でも、また、「ジョブ型雇用」や「同一労働・同一賃金」というトレンドに後れを取らないという意味でも、親プロジェクトのアウトプット:成果物の中で、重要な位置を占めるものになるでしょう。

    ビジネスプロセスとJDが全社的に整備されれば、これまたバズワード化している“働き方改革”そのものが視覚化されるでしょうし、さらにITプロジェクトのビジネス要件は下記「情報システムの5W3H」のように、概ね整理することができるでしょう。

    情報システムの5W3H

    情報システムの5W3Hは、データの入力・保管・出力というコンピューターの基本的な情報処理プロセスを、データフローとして視覚化・マニュアル化する時の切り口になるはずです。

    • When:いつ(定期/不定期)
    • Where:どこで(地域/社外/社内)
    • Who:誰が(部門/職位/職制)
    • What:何を(生産/販売/会計/人事)
    • Why:なぜ(重要度/緊急度)
    • How many:どれぐらい(数量/時間)
    • How to:どのようにして(デバイス/メディア)
    • How much:いくら(お金)

    このような切り口で整理されたデータフローが、JDやロールマップと連携したものとして視覚化されていれば、ITプロジェクトのビジネス要件を整理する上で、これ以上、客観的で明確な根拠はないでしょう。

    親プロジェクトの最後に、サブプロジェクトとして“ERP移行・基幹系システム再構築”を位置付ける

    • ★部分最適な情報システムに矮小化されたものではなく、まず、10年後の事業全体のあり方を視覚化・共有する。
    • ★そのプロジェクトのオーナーは、事業全体の中核である商品部門・生産部門の責任者が担い、外部の専門家組織が客観的な調査・分析結果をもって提言を残す。
    • ☆これら全体最適の合意形成プロセスを経てから、そこに紐づく個別最適の一つとして“美しい”情報システムを再構築する。

    いよいよ本トピックのテーマ、“ERP移行・基幹系システム再構築”のフェーズです。

    注意すべきなのはその体制で、プロジェクトオーナーは親プロジェクトのまま、その親プロジェクトの実行主体となった外部の専門家組織には、システム構築を担うパートナー選定からプロジェクト評価までプロジェクトオーナーの補佐役として、それぞれ関与し続けていただくことです。

    特に、パートナー選定にあたっては、既存のパートナーがオファー先の第一候補になることはよいとして、その他複数のオファー先を、どのような観点で選抜するかが重要です。

    わりと知らないIT産業マップ
    わりと知らないIT産業マップ

    既存のパートナーは、創業の経緯や現在のコア事業から見た時に、どの業界に属していると言えるでしょうか?
    例えば、私たちユニリタは、経営統合前から一貫してソフトウェア業界に軸足を置いています。

    一方、日本国内でSier:Systems Integrator(システム構築会社)の大手と呼ばれる企業は、電電公社時代の電話交換機も作っていたことから通信業界に属していたり、大型汎用機からPC・携帯電話まで作っているハードウェアメーカーだったりする企業が少なくありませんから、他社製のハードウェアやクラウドインフラを第一候補として提案してくれないことがあります。
    また、ここ数年で認知と実績が広まったSaaS型のERPを主要プロダクトとして提供するベンチャー企業は、生い立ちからしてインターネット業界に属していると言えるでしょう。

    親プロジェクトで定義された“10年後のビジネスモデル:afterトランスフォーメーション”におけるコア・コンピタンスやグローバル展開を見据えた時に、個別最適されたERP・基幹システムのライフサイクルをどのように計画・運用していくのか、ビジネスパートナーとなる企業の文化・風土も踏まえて選定されることをお勧めします。

    ここでまた経験談になりますが、2007年頃に急遽お声のかかったコンペ事例をご紹介しておきます。
    当時在籍していたのは、企業のwebサービスを受託型・SaaS型の両面で提供するインターネット企業でして、ある日、WEB問い合わせフォームから国内大手メディアが運営するコミュニティサイトのリニューアル案件が飛び込んできました。

    オファーメールに添付されていたRFPを見てビックリ仰天、既存のサイトでは年間保守費が自分たちの相場感の20倍もかかっていたのです。
    ハードウェア業界+ソフトウェア業界の常識が、インターネット業界から見ると完全な非常識なんだということを、強烈に印象付けられた経験でした。

    また、営業担当がコンペの進め方をヒアリングしてきたところ13社のコンペ案件で、自分たちは末席の13番目、感触としてはほぼ当て馬案件とのことでした。
    後から追加されたであろう当て馬に残されたわずかなプレゼン日程でしたが、奮起した我々はRFPをとことん吟味して、無駄な要件はバッサバサにカットした上で、納期も予算もきっちり圧縮。営業部長が担ったプレゼンの中で、インターネットユーザーが求めていることとの大きなギャップも指摘して、予算・納期・品質と共にコミュニティサイト運営の合理性を提言したことで二次コンペに残ってしまい、結果的に12社を飛び越えて受注するに至りました。

    ITベンダーの選定で、予算・納期と同等かそれ以上に大事なことは「パートナーシップ」

    その時にご評価いただいたポイントは、まずは何より予算・納期がプロジェクトマネージャーがバッファを持つことに充分寄与できたことはもちろんとして、それ以上に刺さってしまったのは“顧客の顧客の理解”と“プロフェッショナルな提案”だったそうです。

    ERPのようなエンタープライズ案件ではなく、大手メディアのオーディエンスがエンドユーザーとなるコンシューマー案件でしたから、エンタープライズ分野に強いソフトウェア業界では知見も実績も限られていたことは致し方ないとして、プレゼンの際の質疑応答に携わったスタッフ全員が一人のオーディエンスとして率直な意見を添えたことで、短期的なお付き合いのベンダーではなくビジネスパートナーとして認めていただいたとのことでした。

    今回のERPや基幹系システムであれば、提案参加するベンダーの組織内でも同様の情報システムは利用されているはずですから、RFPで示した要件に対する突っ込みどころや失敗事例を、どれだけ自分ゴトとして提案してくれるのか、ビジネスパートナーと呼ぶに相応しい提案・実行能力を、重要な評価ポイントにしていただけるとよいのではないでしょうか。

    ITベンダーの選定で、予算・納期と同等かそれ以上に大事なことは「パートナーシップ」
    ITベンダーの選定で、予算・納期と同等かそれ以上に大事なことは「パートナーシップ」

    情報システムのリプレースや再構築で忘れてはいけないのがデータ移行

    なぜ、ユニリタがこのようなトピックを掲載したのか、最後に補足させていただきます。

    まず、以前のトピックで掲載した図を再掲します。

    CIOのミッション遂行を補完するデータ連携インフラ
    CIOのミッション遂行を補完するデータ連携インフラ

    その際、メインフレームであれExcelファイルであれ、部分最適やサイロの象徴となり果てた情報システムから有用な“情報”を得るには、「シームレスなデータ連携基盤」を常設しておくことが有効であると提言させていただきました。

    これが、ERP移行や基幹系システムの再構築という期間限定の利用であれば尚更、旧システムから新システムへのデータ移行をいかにして迅速かつ精度高く実行できるかが、プロジェクトの成功に向けて無視できないタスクであることはご理解いただけると思います。

    【まとめ】ERP移行や基幹系システムの再構築を成功させる5つのステップ

    ついつい長文になってしまいましたが、5つのステップを簡単にまとめてみます。

    【ステップ1】プロジェクトオーナーはCIO・情報システム部門長ではなく、生産・商品部門の統括責任者に担ってもらう

    ERP移行や基幹系システムの再構築に取り組むのであれば、最上位に掲げられるであろうビジネス要件の責任主体に、プロジェクトオーナーを担っていただきましょう。
    情報システムの刷新が目的化したITプロジェクトに成功事例なし
    というぐらいの心構えでもよいかもしれません。

    【ステップ2】成し遂げるべきではDXではなくビジネストランスフォーメーション

    前項のようにプロジェクトオーナーを選定する理由は「(仮称)2030年に勝ち残るビジネストランスフォーメーション」というプロジェクトだからに他なりません。また、DXで言われるデジタライズに矮小化せず、ビジネスプロセスの before/after を視覚化・共有した上で、必要となるERPや基幹系システムをデザインしていきましょう。

    【ステップ3】ビジネストランスフォーメーションに必要な調査・分析・提言を任せられるパートナーは誰か

    10年後のビジネスプロセスを内部人材に定義してもらうことは、客観性や妥当性の観点からも避けるべきです。
    グローバル市場で同種のプロジェクトを成功させた実績を持ち、矜持・プライドのある提言につなげてくれるであろう外部の専門家組織を活用しましょう。

    【ステップ4】ITプロジェクトは、親プロジェクトを通じて全社的にビジネス要件が合意されてから始動する

    ERP移行や基幹系システムの再構築でよく聞かれる失敗が、既存のビジネスプロセスやユーザーインターフェースを踏襲することが重要な要件となってしまい、付加価値生産性の向上といった本来であればITが果たすべきミッションが置き去りにされがちなところにあるのではないでしょうか。
    このステップが、本トピックのキモになるところかと思いますので、くれぐれもITプロジェクトを目的化して部分最適に陥らないよう、ご留意ください。

    【ステップ5】新旧システムのデータ移行もカバーするデータ連携基盤を常設しておく

    新システムの要件を固めていく中で旧システムの特殊なデータを直接取り込める機能を盛り込むことは、新旧システムの移行期だけに使われる機能になることから、もったいないことこの上ない無駄な要件だと考えます。
    新システムのカバー範囲によっては、旧システムとは別に存続する業務アプリケーションもあるでしょうから、平行稼動する情報システム間のデータ連携基盤を用意しておくことは、新システムに無駄な機能を盛り込む愚策を回避できます。

    さらに、情報システムがどのように変わろうとも、エンドユーザーから求められている“情報”を効率よく抽出できるデータ連携基盤を持つことは、情報システム部門のミッション遂行に欠かせない機能と捉えていただければ幸いです。


    以上、最後までお付き合いいただきありがとうございました。

    本トピックをご覧いただいて、メインフレームやオフコンの改廃、ERP移行や基幹系システムの再構築に向けた企画・検討のお役に立てれば、これ以上の喜びはありません。

    ご相談は、お取りいただいたお時間にオンラインで柔軟に対応させていただきますので、どうぞお気軽にお声がけください。

    • LINEで送る
    • このエントリーをはてなブックマークに追加

    ETLツール『Waha! Transformer』を実際に操作できる

    ほぼ毎月開催! 参加無料!
    Waha Transformer ハンズオンセミナー
    お申し込みはこちらから

    関連コンテンツ

    社内のデータ活用でお悩みの方はお気軽にご相談ください。

    導入企業様の事例を資料にまとめました。
    「事例集」ダウンロード
    ご不明点などお気軽にご相談ください。
    お問い合わせ
    30日間、無料で体験いただけます。
    無料体験版

    注目トピック

    ETLとは、デジタルトランスフォーメーションの第一歩となる、データの整理・整頓ツールです

    ETLとは、デジタルトランスフォーメーションの第一歩となる、データの整理・整頓ツールです

    ETLツールとは、「組織の内外に散在するデジタルデータを抽出・収集(Extract)」し、「用途に応じて変換・加工(Transform)を行った上」で、「その先にある格納先に有用な情報として配信・送出(Load)してくれる」ITプロダクトのカテゴリーの一つです。

    データ連携の自動化で正しいデータをスムーズに有効活用

    データ連携の自動化で正しいデータをスムーズに有効活用

    Waha! Transformerは、異なる形式のデータをスムーズに連携・統合する純国産ETL:データ連携ツールです。1999年の提供開始以来、大手企業を中心に1,800ライセンスの導入実績。SQLやプログラミングの知識がなくても使いやすいシンプルな操作性と、圧倒的な処理スピードで組織内外のデータ活用を加速します。

    属人化Excelをデータベース化・情報システム化すべき理由

    属人化Excelをデータベース化・情報システム化すべき理由

    Excel更新ルーティンから解放されたいビジネスパーソンに向けて、Excel集計・加工作業を機械化・自動化する方法について整理してみました。

    お役立ち資料

    Excel業務からの脱却!属人化・共有・レポートに関する課題を解決

    Excel業務からの脱却!
    ~属人化・共有・レポート
    に関する課題を解決~

    Excelで作成されたレポートには「属人化」や「データ共有」、「データ準備」といった問題が存在します。本ホワイトペーパでは、皆様にも起こり得るこれらの問題をできる限り分かりやすく 解説・整理できればと思います。

    脱Excelではなく、Excelを生かして業務効率を上げる方法

    脱Excelではなく、
    Excelを生かして
    業務効率を上げる方法

    本ホワイトペーパーでは、数多くの企業が抱えるExcel業務効率化の悩みに対し、3つのステップで最適な回答を示すことで、できる限り分かりやすく解説・整理できればと思います。

    導入実績多数!数字で証明する、ETL/EAI製品をリプレイスした効果!

    海外製ETL/EAIの
    EOS/EOL対策

    2000年代初頭よりデータ連携基盤として多くの企業に導入されたETL/EAI製品。本資料では、お客様がどこに課題を抱いていて、ユニリタのソリューションを選択することでどのような効果があったのかを簡潔明瞭にお伝えいたします。