カテゴリー
成功するプロジェクト・失敗するプロジェクト

ベンダーのミスリード

残念ながら、全てのベンダーが「正しい情報をユーザーに伝えている」訳ではない事を、改めて記しておきます。

ネット上で見かける SAP S/4HANA® 移行サービスでも、担当者の誤解なのか、意図的にミスリードを誘っているのか不明ですが、ユーザー企業の知識不足を狙った感のある記述があったので、これを例に挙げて解説と補足説明を残しておきます。

(ミスリードを誘う記載例1)修正するAdd-On量で単純移行か再構築かを提案します。

(解説1)「少し言葉が足りないだけ」なのかもしれませんが、ユーザー企業側から見れば、判断基準は以下の2点に絞られるはずです。

  • 「保守期限が迫っているので、とにかく現状の業務を変えずに、最低限のコストで乗り換えたい」→ 単純移行
  • 「DXを見据えて業務を見直す(見直せる従業員が存在する)ので、これまで投資してきたAdd-Onも捨てて、一から業務とシステムを見直したい」→ 再構築

(ミスリードを誘う記載例2)Add-Onはバージョンアップの弊害になる場合があるため、なるべく標準機能の利用をお勧めします。

(解説2)SAP®は2通りの拡張方法を提示しています。一つ目は従来のAdd-On開発等でお馴染みの「In-App 拡張」です。二つ目は、SAP®以外のクラウドサービスやシステムとの連携機能や、不足する機能をSAP® Cloud Platformで開発する「Side-by-Side 拡張」です。SAP®のメッセージを纏めると以下の2点に集約されます。

  • 従来のAdd-On(In-App 拡張)はECCのバージョンアップ時、検証コスト増となる可能性があるので、影響を見極めて、必要であれば Side-by-Side 拡張で移管して下さい。
  • 新たにAdd-Onする場合は Side-by-Side 拡張で実装して下さい。ECCのバージョンアップによる影響はありません。(標準機能の利用を強く勧めている訳ではない)

(ミスリードを誘う記載例3)SAP S/4HANA® はクラウド時代の設計で、SAP®のクラウド製品との連携が容易です。

(解説3)❝ SAP S/4HANA® はインメモリデータベースであるHANAの能力を最大限に発揮できるような設計になっている ❞ が正しい伝達の仕方でしょうか。SAP®のクラウド製品との連携が容易である事に間違いはありませんが、他社のクラウドサービスとの連携アダプタも、世界中のパートナーが開発し販売していますので、❝ 他のクラウドサービス連携も容易です ❞ が正しい情報です。

いかがでしょうか。ベンダーからの提案が「ベンダー都合の提案」なのか、「ユーザー企業の目線に立った提案」なのか、こうやって見ると、とても分かりやすい例だと思います。

ベンダー選定の一助となれば幸いです。

カテゴリー
運用面でのコスト削減

運用時の失敗要因

導入時の失敗要因では、導入時の失敗原因を分析しましたが、システム稼働後の運用現場でも緩い失敗(コストに見合わない運用)が見受けられます。通常、 SAP® R/3®を導入したベンダーの何名かが保守メンバーとして残り、システムの運用を行います。保守マネージャーがユーザー業務を理解し、あらゆる方面との交渉力を持っている現場は、何も心配ありません。

では緩い失敗が起こる要因とは何でしょうか。導入時の成否がそのまま引きずられる事になります。

No.ユーザー側ベンダー側結果
1リーダークラス機能熟知成功
2リーダークラス機能知識に乏しい要求された機能をAdd-Onや手作業で逃げる。
3担当者レベル機能熟知現状維持を求められ、ベンダーの提案が通らない。
4担当者レベル機能知識に乏しい既存システムと同じシステムが出来上がる。
導入時の失敗要因

これを運用場面に当てはめるとこうなります。

No.保守マネージャー保守メンバー結果
1リーダークラス固定・熟練度UP熟練度が上がり機能知識が深まる事で、コストパフォーマンスの高い保守が可能。
2リーダークラス頻繁に入れ替え熟練度が上がらず、単純なAdd-Onや手作業ばかりが増える。
3担当者レベル固定・熟練度UP何度も拒否され続けると改善意欲も失せ、単純なAdd-Onや手作業ばかり増える。
4担当者レベル頻繁に入れ替え効率化や自動化とは程遠く、体力と根性で運用するシステムと化す。
運用時の失敗要因

保守メンバーの熟練度を高めながら、保守マネージャーも業務知識を深め、ユーザー側との交渉能力を高める事が重要です。

どちらか一方だけが秀でても上手く回りません。今後は労働人口が減少するため、No.4のように「体力と根性で運用する」形からは脱却して、テスト自動化ツール等を積極的に導入する等、少人数で、さらには有事でも事業を止めないシステム運用にシフトする事が望まれます。

タイミングとしては、SAP S/4HANA®への移行と同時期に、または移行後に少しずつ自動化を取り入れて行く事をお勧めします。クラウドに移行するのは、災害対策としても非常に有効です。

カテゴリー
成功するプロジェクト・失敗するプロジェクト

導入時の失敗要因

2020年6月でビッグドライブ株式会社は、創業から10期目を迎える事ができました。私は1996年からSAP®のAdd-On開発者としてキャリアをスタートさせ、今年で25年目を迎えました。

これから将来を担う技術者のためにも、そしてSAP S/4HANA®を導入して運用していくユーザーのためにも、これまでERPの導入現場で何が起こってきたのか、時代背景を踏まえて記そうかと思います。

1990年代後半。ホストコンピューターからのダウンサイジングニーズ、そして2000年問題の対応手段としてSAP® R/3® は飛ぶように売れました。当時はBPR(ビジネス プロセス リエンジニアリング)という言葉も流行り、「R/3® に業務を合わせて下さい!極力 Add-Onを減らしましょう!」を合言葉に導入プロジェクトが進められました。しかし、導入する側もプロフェッショナルは少ない訳です。

SAP® R/3® に精通していない人達が導入するわけですから、あちらこちらで「これがSAP®の標準ですから。Add-Onしましょう!」となってしまいました。

標準プログラムやパラメータ設定、Exitでどうにかなる範囲でも、Add-On開発が増えれば増えるほど、システム導入会社の儲けは大きくなるため、「標準機能では実現できないと説明してAdd-Onにしちゃえ!」というベンダーもいました。

そうして「SAP® vs ユーザー企業」という一番望ましくない対立構図が、皮肉にも「SAP®のパートナー企業」の手によって作り上げられていったのです。

プロジェクトメンバーに導入企業の業務担当者を据えた事も、Add-Onが増えた材料の一つでした。何故なら業務を担当している方は「今の業務をこなす」のが仕事であり、「新しい業務を作りだすのは自分の仕事では無い」と感じている方が多いからです。

業務改善を考え、責任を負う覚悟のある各業務のリーダークラス、SAP® R/3®の機能を熟知しシステム稼働後の運用まで考えていたベンダーが揃った「幸運なるプロジェクト」だけが成功を収めていました。下記表のNo.1は大成功と言ってもいいでしょう。No.2は保守メンバーの熟練度が上がり、稼働後にシステムの改善余地があるので、小成功といったところでしょうか。No.3はベンダー側(システム稼働後に残る保守メンバー含む)が疲弊している場合が多いので、運用フェーズでの改善提案は望みにくいケースです。No.4にいたっては、残念ながら既存システムを使い続けていた方が良かったレベルです。

No.ユーザー側ベンダー側結果
1リーダークラス機能熟知成功
2リーダークラス機能知識に乏しい要求された機能をAdd-Onや手作業で逃げる。
3担当者レベル機能熟知現状維持を求められ、ベンダーの提案が通らない。
4担当者レベル機能知識に乏しい既存システムと同じシステムが出来上がる。
導入時の失敗要因