ERP、CRM/SFAのアドオン地獄に陥らない

スマートに機能を拡張する「aPaaS」とは

目次【1章】 その「ERP一本化施策」、アドオン地獄の覚悟はできていますか?
• 資産を持たない経営が「クラウド型」拡大の原動力• アドオン地獄への道は日本のカイゼン文化で舗装されている【2章】 スマートに機能を拡張可能な「aPaaS」とは• APIが可能にしたERPの「周辺システム開発の進化系」• ビジネスの価値に注力するaPaaS【3章】 aPaaS でアドオン地獄から脱却を実現「LaKeel DX」

2

1章
その「ERP一本化施策」、アドオン地獄に陥る覚悟はできていますか?

3

【1章】 その「ERP一本化施策」、アドオン地獄の覚悟はできていますか?

資産を持たない経営が「クラウド型ERP」拡大の原動力
2000年前後のERPブームから約20年。

多くの日本企業が1〜2回の基幹システム刷新を経てクラウド型ERPの導入へ舵を切ろうとしています。

ERPに関するトピック1990年
後半

ERP
ブーム

2000年

背景として、ERP製品の成熟や旧世代製品のEOL、企業のグローバル化もさることながら、IT資産を出来るだけ持たずに費用化する経営上の判断や、スクラッチ開発を行うだけのIT人材を確保できない等の事情も、クラウド型を後押しする一因となっています。

多くの企業では、ERPやCRM/SFAの周辺には多数の外部システムやパッケージを保有していますが、クラウド型のERP導入を機に「ERP一本化施策」を掲げる企業も少なくありません。

背景

2000年問題に端を発した
ERP導入ブーム
ERP製品の成熟

1~2回のｼｽﾃﾑ刷新

旧世代製品のEOL

2010年

IT資産の非所有化の流れ
クラウド型ERPの普及

2020年

ERP
一本化施策

スクラッチ開発のためのIT人材不足
自社の業務をERPの標準機能にあわせる機能開発をERPのアドオン開発に寄せる4【1章】 その「ERP一本化施策」、アドオン地獄の覚悟はできていますか?

アドオン地獄への道は日本のカイゼン文化で舗装されているERP導入の本質は「ベストプラクティスの導入」
ERP導入のメリットはさまざまですが、本質的には「ベストプラクティス」を入手することにあります。

諸外国で求められるERP• 人材の流動性が高い• 求められるのは標準的でベストプラクティスな業務やスキル• 日本のような大規模SIの文化などがない

ERPの普及が進む諸外国では、人材の流動性が高く、中途で入社した人間でもすぐになじむ事ができる「標準的でベストプラクティスな業務やスキル」が求められる傾向にあります。
加えて、日本のような大規模SIの文化や経済的バックボーンが無い事も踏まえ、ベストプラクティスをパッケージングした「ERP」が大きな支持を集めました。

ベストプラクティスをパッケージングしたERP

日本で求められるERP• 人材の流動性が低い• カイゼンの文化

一方で、日本においては、「カイゼン」の文化、もとよりレガシーシステムで既に実現済みであった高度な自社業務への適合を叶えるべく、多くのアドオンやカスタマイズが行われる傾向にあります。

• 高度な自社業務への適合が求められ、アドオンやカスタマイズで調整

スクラッチ開発に匹敵するカスタマイズやアドオン開発

5

【1章】 その「ERP一本化施策」、アドオン地獄の覚悟はできていますか?

アドオン地獄への道は日本のカイゼン文化で舗装されている「ERP一本化施策」においても避けられない「カイゼン」
ユーザサイドから求められるがままに進める「カイゼン」は、開発・バージョンアップ費用の高騰や、ベンダーによるロックインなど、さまざまな負債を残してしまいます。

開発などの費用の高騰
ベンダーによるロックイン

また、昨今の海外製ERPのEOLにおいては、既にエンジニアが市場に供給されておらず、日本中の企業がベンダーやパッケージの有識者を奪い合う状態に陥りました。
外部のベンダーやパッケージの有識者に依存しすぎることで、社内の情報システム部門の開発人材が育たず、空白化を招く事のリスクが再認識されました。

ベンダー

情報システム部門
自社に合わせたカスタマイズ依頼
カスタマイズ・アドオン開発

開発人材の空白化
他社には依頼しにくい

さまざなま技術的負債
企業IT継続性のリスク

6

【1章】 その「ERP一本化施策」、アドオン地獄の覚悟はできていますか?

アドオン地獄への道は日本のカイゼン文化で舗装されている
アドオン追加を避けても「無計画な周辺システム化」は起こり得るパッケージへのアドオン追加を避け、周辺システム化戦略を採る企業においても、「無計画な周辺システム化」は起こる可能性があり、その理由には以下が挙げられます。
【ERP導入時の例】
ERPに多くの予算が割かれ、周辺システムの構想を描くだけの予算や時間を確保できず、将来の拡張が考慮されていな
い必要最低限の周辺システムになる。
【保守運用時の例】
さまざまなスクラッチ開発システムや個別パッケージ等の濫立により、システム間の連携、個別の開発言語、多数のサーバ運用等、当初予定しなかった負債が残る。

ERP導入期

保守運用期

周辺開発

導入期はERP自体に時間もコストも多く割かれる

保守運用を通じて、使い勝手の調整が必要となる開発言語、サーバ等がバラバラな周辺システムが濫立将来の拡張が考慮されていな
い最低限の周辺システム

スクラッチ開発や、パッケージシステムの追加導入

保守運用コストの増加

ERP導入
周辺ｼｽﾃﾑ7

【1章】 その「ERP一本化施策」、アドオン地獄の覚悟はできていますか?

アドオン地獄への道は日本のカイゼン文化で舗装されている
CIOの尽きない悩みの種

前頁のようなケースは非常に多く、ERP導入時に掲げていた「ベストプラクティスの適用」、「運用保守費用の低減」は目論み通りに進まないことも少なくありません。

これにより、CIO/情報システム部⻑は「業務効率化=自社に最適なシステム開発」「導入・保守コストの低減」のバランスをどのようにとるかなど、尽きない悩みの種を抱えることになります。

運用保守費用の低減
情報システム部門の採用方針
ベストプラクティスの適用
周辺システムなどの戦略・戦術

ベンダー/パートナーとの取り組み戦略

CIO/情報システム部⻑

次章ではこの尽きない悩みを解消するヒントを紹介します。

どうすれば解決できるのか？

8

2章
スマートに機能を拡張可能な「aPaaS」とは9

【2章】 スマートに機能を拡張可能な「aPaaS」とはAPIが可能にしたERPの「周辺システム開発の進化系」
従来の「周辺システム開発」は、ERPとバッチで連携する方法が一般的でしたが、これはリアルタイム性に乏しく、マスタの二重管理や双方向連携の困難さが生じるなど多くの課題がありました。

従来の「周辺システム開発」

バッチ処理
マスタの二重管理

双方向連携の困難さ

最新のクラウド型ERPパッケージは、この問題を解決するために、多くの機能に「API」を用意しています。

このAPIを使用することによって、「周辺システム」とERPのリアルタイム連携、ERPの保守・バージョンアップの影響を受けない、オープン系プログラミング言語による開発を可能にするなど、「周辺システム開発」をより高度な形に進化させる事が可能となりました。

APIの活用により、クラウド同士の連携、SaaSの普及が急速に進んでいます。

最新のクラウド型ERPパッケージ

APIの活用リアルタイム連携

ERPのバージョンアップなどの影響を受けないデータの二重持ちの軽減し「拡張」に専念

オープンな開発言語
内製化・自由なベンダ
起用

10

【2章】 スマートに機能を拡張可能な「aPaaS」とはビジネスの価値に注力するaPaaS
SaaS はハードウェアから業務アプリケーションまでをクラウドサービス事業者に委ねるため、専門性が低くても利用できる一方、自由度は低く複雑な業務フローに適合しづらいものです。
この欠点を補うクラウドサービスとして近年、注目され始めているのが、「aPaaS (Application Platform as aService)」です。
aPaaS はインフラ・アプリ基盤部分はサービスとして提供され、業務アプリケーション部分は自社開発が可能です。また複数の周辺システムをAPI連携でまとめて共通プラットフォーム化し、小さな部品単位で取り出すことも可能としました。

これにより、システムを部分的に改修することや社内ニーズに合わせてスマートに機能拡張を進めることができます。

aPaaSとはSaaS

aPaaS

アプリケーション

アプリケーション

ミドルウェアミドルウェアOS

OS

ネットワークネットワーク

自社で開発

ハードウェアハードウェア

開発済み

業務アプリケーション部分
は自社で開発できる

aPaaSの特徴
メリット①

インフラ・アプリ基盤部分はサービスとして提供されるため、運用負荷が低減、アプリケーション開発に専念が可能
メリット②

アプリケーション部分を、内製化・自由なベンダー起用が可能
メリット③

複数の周辺システムをAPI連携し、共通プラットフォーム化

113章
aPaaSでアドオン地獄から脱却を実現「LaKeel DX」

12

【3章】 aPaaS でアドオン地獄から脱却を実現「LaKeel DX」

aPaaS でアドオン地獄から脱却、「LaKeel DX」の紹介「LaKeel DX」 は aPaaS に分類されるサービスです。
インフラ構築の手間も無く、アプリケーションの開発に注力できるため、最小の人数で自社の強みを生かしたシステム開発に取り組むことができます。また、周辺システムをAPIで連携することで共通プラットフォーム化も可能です。
また、「LaKeel DX」 では業務アプリケーションを小さな部品として組み立てる「マイクロサービス技術」を用いることで、過去に開発した業務アプリケーションも技術的負債から技術的資産に変えることができます。

オンプレミス型

クラウド型（非マネージド）

LaKeel DX

アプリケーション

アプリケーション

アプリケーション業務
アプリケーション業務
アプリケーション業務
アプリケーション

部品群

部品群

部品群

フレームワーク

フレームワーク

フレームワーク

スケーラビリティ

スケーラビリティ

スケーラビリティ

可用性

可用性

可用性

バックアップバックアップバックアップミドルウエアの導入

ミドルウエアの導入

ミドルウエアの導入

OSのパッチOSのパッチOSのパッチOSの導入

OSの導入

OSの導入

サーバメンテナンス

サーバメンテナンス

サーバメンテナンス

ラック導入管理

ラック導入管理

ラック導入管理

電源、ネットワーク電源、ネットワーク電源、ネットワーク

クラウドベンダ(PaaS)の責任範囲

LaKeel DX

凡例：

ユーザの責任範囲

13

会社概要と連絡先

会 社 名株式会社ラキール （Lakeel, Inc.）

所 在 地

東京都港区愛宕2-5-1 愛宕グリーンヒルズMORIタワー33階

設

2005年6月10日

立

代 表 者

代表取締役社⻑ 久保 努

資 本 金

341,062,000円

事業内容

LaKeel事業

本資料及び LaKeel DX に関するお問合せはこちらまでご連絡ください
お問合せ先

https://dx.lakeel.com/contact_dx/

14