COVID-19危機におけるOracle NetSuiteのお客様に対するお約束

新規事業スタートアップとERP

新規事業スタートアップとERP


厳しい経済環境の中、企業が成長し続ける、あるいは生き残るためには、新たな成長分野への進出、M&Aによる事業統合、事業部の子会社化/分社化、新興国市場への進出など、さまざま取り組みが必要となっています。

しかし、いずれの場合にも、新たな会社・事業をスタートアップする際の業務アプリケーション基盤の構築が、大きな問題となって立ちはだかります。スタートアップ時の規模に合わせたスモールシステムの導入が、その後の成長を妨げることもあれば、過剰な初期投資が、成長に必要な資金をショートさせることもあります。

レガシーなオンプレミス型ERPの導入においては、各製品が企業規模に合わせて開発されているため、規模的に安定した企業への導入には対応できても、新規事業スタートアップの局面には対応できませんでした。

一方、クラウド上で利用できるアプリケーション(Saas)の最大のメリットの一つは、ユーザ数やデータ量の急激な増加に対しても、ハードウエアの増強やソフトウエアの切り替えを自前で実施することなしに、対応できることです。このメリットのおかげでクラウドERPは、新規事業スタートアップの局面において特に高い導入効果があります。

しかし、一口にクラウドERPといっても、その機能は様々で、そのすべてが新規事業スタートアップの局面において適切な選択となるわけではありません。新規事業スタートアップの局面におけるクラウドERP選択のポイントは、3つに整理することができます。

1つ目のポイントは、初期導入が短期間かつ低コストで行えるかどうかです。一般にクラウドERPは、インフラがすでにクラウド上に存在するため、オンプレミス型と比較して短期間に導入が可能であるといわれています。しかし、本当に導入期間を短くするためには、アプリケーションのセットアップやカスタマイズも短期間で行える必要があります。

2つ目のポイントは、性能とコストの両面においてスケーラビリティがあるかどうかです。スタートアップ当初は業務量も少ないため、システム性能を制限することで短期間かつ低コストで導入することができるかもしれません。しかし、事業が成功すればするほど、業務量は飛躍的に増大し、あっという間に当初想定した機能やシステム性能では追い付かなくなります。一方で、事業の成功を前提とした大規模システムを初期導入すると、限られたスタッフへの過大な運用負荷や、IT投資予算の超過といった事態を招いてしまいます。

つまり、クラウドERPは、業務量の急激な増大が発生しても追い付けるだけの性能をあらかじめ確保しつつ、業務量が少ない初期の段階においては、低コストでの運用を可能にすることがもとめられます。

3つ目のポイントは、必要な業務機能がすべて統合されているかどうかです。新規事業スタートアップの初期導入においてよく見られるやり方に、財務会計などの優先度の高いモジュールのみ導入して、残りは業務拡大に合わせて検討するというやり方があります。しかしこれは、成長を前提とした導入方法としては正しくありません。

事業が成功するためには、想定するビジネスモデルが機能するための業務プロセスが最初から確立している必要がありますが、必要な業務アプリケーション機能を欠いたままでは、業務プロセスは目標とするレベルには到達できませんし、業務量の拡大がすぐに業務プロセスの破綻を招き成長を阻害してしまいます。つまり、クラウドERPは、新規事業に必要な業務機能を最初から導入でき、かつそれらが統合されていることがもとめられます。

新規事業スタートアップ局面におけるクラウドERPの選択のためには、①初期導入が短期間かつ低コストで行えるかどうか、②性能とコストの両面においてスケーラビリティがあるか、③必要な業務機能がすべて統合されているかどうか、の3つのポイントを確認する必要があります。

短期間、低コストでの初期導入~マルチテナント型クラウド

一般にクラウドERPは、インフラがすでにクラウド上に存在するため、オンプレミス型と比較して短期間に、しかも低コストで導入が可能であるといわれています。しかし、インフラがすでに存在して、契約すればいつでも利用可能な状態にあるクラウドは、「マルチテナント型」である必要があります。

クラウド・サービスの中でも、ERPのようなアプリケーション・ソフトウエアを共有して使用する「パブリック・クラウド」のことをSaas(Software as a service)といいます。一方で、クラウドが登場する以前から、アプリケーション・ソフトウエアをデータセンターに置いて利用するASP(Application Service Provider)と呼ばれるサービスが存在していました。

しかし、ASPはあくまでも一つの顧客ごとに物理的に独立したサーバーを使用することが前提で、サーバーを数多くの顧客で共有し、効率的に低コストで利用できる「パブリック・クラウド」によるSaasとは明らかにちがっています。このため、古いASPのアーキテクチャを「シングルテナント型」、「パブリック・クラウド」によるSaasを「マルチテナント型」と呼んで区別しています。

クラウドERP

「シングルテナント型」のクラウドでは、ハードウエアは既に準備されているかもしれませんが、ソフトウエアの導入、セットアップは、個別の顧客ごとに行われる必要があります。また、コスト面でも、「マルチテナント型」のように他の顧客との共有によるコストダウンがなされるわけではありません。つまり、「シングルテナント型」クラウドでは、導入期間、コストのいずれについてもオンプレミス型と大差がないことになります。

最近のクラウド・ブームにのって、以前からあるASPがクラウドないしSaasと呼称しているケースもあるますので注意が必要です。本来のクラウド・サービスのメリットを得るためには、この「マルチテナント型」であることを確認しなければなりません。

短期間での初期導入~GUIによる簡易カスタマイズ

前編でご説明したようにマルチテナント型のクラウドERPを選択することで、確かに初期導入期間は短くなりますが、それだけでは十分ではありません。それはERPの導入にかかわる時間やコストの多くが、アプリケーションのセットアップやカスタマイズに費やされてきたためです。つまり、本当に導入期間を短くするためには、アプリケーションのセットアップやカスタマイズも短期間、低コストで行える必要があります。

アプリケーションのセットアップやカスタマイズを短期間、低コストで行う方法として、GUIによる簡易カスタマイズ機能を利用する方法があります。GUIによる簡易カスタマイズ機能とは、IT専門知識を持たない一般社員でもカスタマイズが可能な、プログラミングを必要としないGUIベースの開発環境のことです。

次の画面イメージは、GUIによる簡易カスタマイズの画面例です。

クラウドERP

この画面では、「Customer Vendor Bill」という名前の入力フォームをGUIで作成しています。

このようなGUI画面で、自社の業務に精通した一般社員が自らカスタマイズを行うことができれば、時間的にもコスト的にも理想的です。

多くのクラウドERPにはGUIによる簡易カスタマイズ機能が備わっていますが、カスタマイズを行える範囲は様々です。GUIによる簡易カスタマイズ機能でポイントとなる機能は以下のとおりです。

入力フォームの変更:既存の入力フォームに満足できない時には、レイアウトや入力方法を変更する必要があります。たとえば、自由文字列での入力フィールドをリストから選択するように変更したり、英数字のみを受け付けるフィールドを数字のみを受け付けるように変更したりといった柔軟な変更ができる必要があります。

フィールドの追加:既存の入力フォームに新たに入力フィールドを追加したい場合には、ERPのテーブルにフィールドを追加し、そのフィールドに対応した入力フィールドを追加できる機能が必要です。

名称の変更:ERPにもともと設定されているテーブルの名称や、テーブルのフィールド名称がわかりづらい場合は、それらの名称を変更できる機能が必要です。その際、実際のテーブルやフィールドの名称を変えてしまうと、他の機能に影響を与える可能性があります。 内部的な名称と、表示される名称が別々に管理されていれば、表示される名称のみを変更することで影響を最小範囲に抑えることができます。

フォームとテーブルの追加:既存の入力フォームにない新たな入力フォームを追加するためにはフォームだけではなく、入力データを格納するためのテーブルを作成する必要があります。クラウドERPでは、このテーブルはオブジェクトと呼ばれることがよくあります。また、単にテーブルを作成するだけではなく、入力フォームと連動させて伝票入力のような機能を実現するためには、マスターテーブルとの関係づけ(リレーションの作成)も必要になります。テーブル(オブジェクト)の作成やマスターテーブルとの関係づけ(リレーションの作成)が非IT技術者でも行えるかどうかは重要なポイントです。

出力フォームの変更・追加:入力済みデータの確認や社内業務フロー上での閲覧に利用される出力フォームには様々な形式が求められます。また、このようなフォームはクラウドERP導入後も随時変更・追加が求められます。したがって、この機能は一般社員が可能な限り簡単に操作できることが求められます。

性能のスケーラビリティ

事業が成功すればするほど、業務量は飛躍的に増大し、あっという間に当初想定したシステム性能では追い付かなくなります。従来のオンプレミス型では、システム性能が低下する度に、性能見積りをやり直し、システムの切り替えを自社で実施する必要がありました。

クラウドERPであれば、契約や料金の手続きを正しく行っておけば、システム性能の強化は自動的に行われます。ただし、このようなメリットを得るためには、シングルテナント型ではだめで、マルチテナント型である必要があります。シングルテナントの場合、個々の顧客に特定のハードウエアを割り当ててあるため、システム性能を強化するためには、顧客の要望に沿った増強を個別に実施する必要があります。

つまり、業務量の急激な増大が発生しても追い付けるだけの性能をあらかじめ確保しつつ、業務量が少ない初期の段階においては、低コストでの運用を可能にするためには、マルチテナント型のクラウドERPであることを確認する必要があります。

バージョンアップへの対応

一方で、業務量の増減にかかわらず発生する問題がソフトウエアのバージョンアップです。これは、導入時には軽視されがちですが、いったん必要になると多大な時間と工数を必要とする大きな課題となります。

オンプレミス型の場合、ERPソフトウエアの保守契約を締結していれば最新バージョンのソフトウエアを入手することは可能です。しかし、ソフトウエアの更新作業やテスト作業は自社で実施することが必要で、これには多大な時間と工数を必要とします。また、テスト環境を別に用意する必要があり、ハードウエアコストの面でも大きな負担となります。これは、シングルテナント型のクラウドERPでも同様です。作業自体は、クラウド・ベンダーが実施できるかもしれませんが、その費用は顧客が負担するのが一般的です。

マルチテナント型クラウドERPであれば、契約は通常サブスクリプション(期間更新)形式で、これにバージョンアップ費用も含まれており、かつソフトウエアの更新作業やテスト作業はクラウド・ベンダー側で実施されます。マルチテナント型の場合、システムリソースをすべての顧客で共有する関係上、使用するソフトウエアのバージョンも共通に保つ必要があるためです。

マルチテナント型クラウドの確認方法

ここまでの説明でお分りのとおり、同じクラウドERPであっても、クラウドであることのメリットを得るためにはマルチテナント型であることがもっとも重要なポイントとなります。

しかし、クラウドERPの選定にあたって、ベンダー側が必ずしも、この区別を明確にしているわけではありません。そのような場合は、ベンダーに以下のような質問をしてください。すべてについて「Yes」という回答が得られたら、そのクラウドERPはマルチテナント型であると思われます。

質問1:今日契約すれば、明日からシステムを利用できますか?

質問2:(料金は別として)システム性能上のユーザ数は無制限ですか?

質問3:(料金は別として)システム性能上のディスク容量は無制限ですか?

質問4:バージョンアップは自動的に行なわれますか?

質問5:バージョンアップの際のすべての費用は無料ですか?

質問6:稼働率などのサービスレベルはアプリケーションも含めて規定されていますか?

新規事業スタートアップの局面におけるクラウドERP選択で後回しにされがちなポイントが、必要な業務機能がすべて統合されているかどうかという点です。

新規事業スタートアップの初期導入においてよく見られるやり方に、財務会計などの優先度の高いモジュールのみ導入して、残りは業務拡大に合わせて検討するというやり方があります。しかしこれは、成長を前提とした導入方法としては正しくありません。

事業が成功するためには、想定するビジネス・モデルが機能するための業務プロセスが最初から確立している必要がありますが、必要な業務アプリケーション機能を欠いたままでは、業務プロセスは目標とするレベルには到達できませんし、業務量の拡大がすぐに業務プロセスの破綻を招き成長を阻害してしまいます。

小売業における業務機能の統合

たとえば、店舗と中心とした従来型の販売モデルは、インターネットに代表されるコミュニケーション手段の多様化にともなって、近年大きな変動を遂げています。すなわち、店舗・電話・インターネットなど受注形態の多様化、商品の引き当て方法の複雑化、決済手段の多様化などです。

このような背景のもと、受注から始まって、出荷・配送、さらには、請求・決済にいたる業務管理プロセスを総称してフルフィルメントという言葉が用いられるようになってきました。

従来、受注、出荷、配送、請求・決済という業務は、管理プロセス的にも、システム的にも分断されていましたが、フルフィルメントという概念においては、これらの業務を統合的に管理し、単一のシステムとして運用することが重要とされています。

このようなビジネス・モデルを前提とする新規事業のスタートアップにあたっては、初期の段階から、必要な業務機能がすべて統合されていることがクラウドERPにはもとめられます。

受注チャネル統合

店舗での販売や訪問営業による受注などの従来の形態に加え、電話やFAX、EDI、インターネットなど販売チャネルが増えたため、一つの商品についても多様な受注形態が存在するようになってきています。

新規事業スタートアップに際して、初期の段階での受注チャネルの統合を怠ると、販売チャネルごとにそのビジネス・プロセスの流れに合わせてシステムを追加していくことになります。このようなやり方では、結果として販売チャネルごとに、別々のアプリケーション、別のデータベースが存在するようになってしまいます。

このようなシステムの状態は、結果として全体の受注状況が管理できないなど、様々な業務上の問題を引き起こします。また、システムの安定的な保守を困難にし、運用コストの増大をも招きます。

受注チャネルを大別すると、訪問営業(SFA)、店舗(POS)、通販(受注センター)、eコマース(インターネット)の4つに分かれます。これらの複数の受注システムは、ユーザーインターフェースは異なっていても、注文トランザクションの処理と受注データの管理については、統一されていなければなりません。

このような受注チャネル統合は、急速な成長をもくろむ新規事業スタートアップにおいては、初期の段階で実現しておく必要があります。

多対多の商品引当

複数のチャネルからの受注を行うビジネス・モデルにおいて、商品の引き当ては複雑です。

業務プロセス及びシステムを単純化するためには、受注チャネルごとの在庫を確保するやり方が簡単ですが、そうすると、あるチャネルでは在庫が余っているのに、別のチャネルでは欠品しているという大変非効率な状況が発生します。つまり、このやり方では、不良在庫による財務的損失と欠品による機会損失という2つのマイナスを同時にかかえてしまうことになります。

したがって、複数のチャネルからの受注を行うビジネス・モデルにおいては、在庫を一元的に管理する必要があります。例えば、ECサイトでの受注が予想を大幅に上回った場合など他チャネルの受注状況を確認しながら在庫を調整するといった処理が必要となります。

新規事業スタートアップの局面では、このような複数チャネルからの受注に対しても、在庫を一元的に管理する機能が最初から実現されていなければなりません。

また、倉庫(及びサプライヤ)が複数にまたがる場合もありえますので、この場合は受注チャネルと倉庫(及びサプライヤ)が多対多の関係となり、商品引き当ては、より複雑化します。

加えて複数の倉庫(及びサプライヤ)が存在する際には、配送料、納期の回答において、複数のパターンが存在する可能性があります。このような場合は、あらかじめ決まられた判断基準(ロジック)に従って、営業担当者、店員、オペレータなどが一定の回答を行えるようになっていなければなりません。

たとえば、東京と大阪に倉庫があって、関東からの注文には東京の倉庫の商品を引き当てるとします。しかし、東京には在庫がなくて、でも大阪には在庫がある。このときに、大阪の在庫を引き当てるのか、東京に商品が補充されるまで待つのか。こういった判断は、配送料の問題などもあり意思決定が難しく、これまではその場その場で適当に判断されたり、あるいはある特定のスタッフに任されたりすることで、非効率であり、かつ受注チャネルやタイミングによってことなる回答が行われる可能性があります。

従って、統合されたシステムの中であらかじめ定められたロジックに従って納期、配送料などの回答が行われるようにする必要があります。

新規事業スタートアップの局面では、複数の倉庫(及びサプライヤ)が存在する場合、どのパターンで回答するかのロジックを定義し、受注担当者が一定の回答ができるような機能が最初から実現されていなければなりません。

顧客データの一元管理

受注チャネルの統合や多対多の商品引当は、多様な販売チャネルにより複雑化した業務を、初期の段階から正確、迅速、かつ効率的に管理・運用できるようにすることで急速な成長に備えることが目的です。しかし、業務機能統合の目的はこれだけではありません。

販売チャネルの多様化により、ある特定の顧客が、複数のチャネルを通じてアクセスしてくる可能性も増大しています。このような顧客に対しては、企業は特定のチャネル担当者だけではなく、その企業全体が、単一の顧客にたいして情報を共有し、対応していかなければなりません。つまり、業務機能統合は、単なる業務改善・効率化の観点だけではなく、顧客満足度の向上を目的とした顧客サービスの観点からも必要とされています。

従来、顧客サービスに必要な機能はCRM機能として、別システムとして扱われてきた関係で、新規事業スタートアップ局面でも、ある程度の成長の後に実現すべき、優先度の低い業務機能として、後回し手にされてしまいがちです。しかし、マルチチャネルのビジネス・モデルにおいては、この顧客サービス機能は、事業の成功のためには必須のものとなっている現状では、初期の段階で対応しておかないと事業の成長そのものが危ぶまれます。

したがって、新規事業スタートアップ局面においては、最初からCRM機能が統合された状態でのシステム導入が不可欠といえます。

販売チャネルの多様化により、ある特定の顧客が、複数のチャネルを通じてアクセスしてくる可能性も増大しています。たとえば、テレビコマーシャルや雑誌といった広告媒体を通じて商品を認知し、次に、インターネット経由で、価格や機能などの商品の情報を収集し、リアルな店舗に来店して実物を確認し、最終的にはインターネットで購入する、といったような行動をとる顧客が増大しています。

このような顧客は、アクセスするチャネルが変わっても、自分に対して一貫した対応を受けられるかどうかで、その企業に対する評価を決めてしまいます。たとえば、インターネットで一度見積もりを取った顧客が、店舗で購入を希望した際に、異なる条件で見積もりを行ってしまうと、それ自体が顧客満足度を下げる要因となってしまいます。

このような顧客に対して、競合企業と比較した場合により高い顧客満足度を獲得するためには、広告、インターネット、店舗といったチャネル単位ではなく、その企業全体が、単一の顧客にたいして情報を共有し、ひとつの企業として顧客に対応していく必要がありますが、そのためには、新規事業スタートアップにおける初期の段階で、顧客データの一元管理が実現されなければなりません。

新規事業スタートアップに対応するクラウドERPには、複数の販売チャネルにまたがって、コンタクトが発生する顧客データを、一元的に管理し、企業全体から、単一の顧客として認識できるような顧客データ統合機能が必要となります。

Sales Chat

Interested in growing your business with NetSuite?

Start chat