リセラーとの協調を可能にするソリューション

コンサルティングを要する複雑なソフトウェアの場合、自国内での販売であっても困難が伴います。さらに、グローバル展開という壁を、中小規模のソフトウェアベンダーが単独で乗り越えられるケースは非常に限られます。この課題を解決するには、エンドユーザーの言語を話すことができ、現地の要件や状況を知り、理解し、アドオンでソフトウェアを磨き上げることが可能な「現地のリセラー」の存在が不可欠です。本稿では、この現地のリセラーへの、ライセンスの作成・配布・請求に関して紹介します。

また、CodeMeterユーザーの経験だけでなく、私たちWibu-Systemsの経験からもお伝えできることが多くあります。実際、CodeMeterのライセンスは、世界中の子会社やパートナー企業へ販売されており、さらに、そのパートナー企業は、各地域のソフトウェアベンダーへとライセンスを販売しています。多くのソフトウェアベンダーと同じく、弊社もサブスクリプションモデルを採用しています。本記事では合わせて、その詳細、特に請求面に関してお伝えします。

「在庫」を起点とした生産

可能な戦略の1つとして、事前にライセンスを作成し、そのライセンスを、リセラー側で保管するという手が考えられます。この戦略には、大きなメリットがあります。それは、ハードウェア製品と同じワークフローで対応できる点です。作成・保管したライセンスを、エンドユーザーやリセラーに配布することができます。また、リセラーは、どのアイテムを注文するか、必要に応じて中間倉庫に保管するか、自身で決めることが可能です。もう1つの利点として、ライセンスの作成を生産部門で行える点が挙げられます。これは、合理的であり、慣例にもなっています。

しかし、私の経験から言うと、メリットを上回るデメリットがあります。まず、ハードウェアであれば、例外的な委託品を除き、受領時に代金を支払わなければならない理由を、どのリセラーも理解しています。一方、ソフトウェアの場合、エンドユーザーに販売してはじめて、請求されると考えるリセラーがほとんどです。2点目として、保証、メンテナンス、またはサブスクリプション期間の開始時期が、製造時点で全く不明瞭であるために、追加のフィードバックチャネルを用意しなければなりません。そして3点目のデメリットとして、複雑なライセンスの組み合わせが挙げれます。どのライセンスの組み合わせを在庫として持つべきか、それとも、機能ごとに個別のライセンスを作成するべきか。ー必要なものが在庫にないリスクは、売れ残りを抱えるリスクよりも、遥かに大きいです。

「オーダー」を起点とした生産

代替案もあります。リセラーは、希望する要件のライセンスを注文します。このオーダーは、ERPシステムに記録され、個々のライセンスの作成が開始されます。

このメリットは、明らかです。注文時に請求書される、在庫として「間違った」ライセンスを抱えずに済む、個別に設定されたハードウェアと同様のプロセスが使える、作成時に保証・メンテナンス、またはサブスクリプションの期間が明白である、といった点が挙げれます。

しかし一方で、重大なデメリットも存在します。プロセスや時差によっては、受注から受注記録、作成、納品まで数時間～数日かかる場合もあります。

ポイントシステム

「ポイントシステム」という方法もあります。このシステムでは、エンドユーザーやリセラーが、ソフトウェアの機能に応じて付与された「ポイント」をベンダーから購入します。

ベンダーは、ポイントを作成し、それらを在庫として保管します。リセラーは、ベンダー元で保管されたポイントを仕入れ、ソフトウェアの設定時に、そのポイントをエンドユーザーに渡します。

しかし、個人的にはあまりおすすめしません。このシステムを使用すると、どの機能がどれくらいの頻度で販売されたのかという情報が見えにくくなってしまうことが理由としてあります。また、サブスクリプションやメンテナンス契約の表現も難しくなり、保証期間の証明は複雑化します。さらに、「ポイント失効」といったサポートプロセスも、複雑さを倍増させる要因となります。もちろん、これら全てをCodeMeterで実装することは可能ですし、成功例もあります。しかし、ここで最終的な決断を下す前に、まずは、次の第4の選択肢をみることをおすすめします。

「オンデマンド」での作成

私個人の意見ではありますが、リセラーに「オンデマンド」でライセンス作成を許可する方法が、最も現代的かつ柔軟性の高いソリューションであると考えています。そしてこれは、私たちWibu-Systemsが、自社ライセンスのために導入したソリューションでもあり、CodeMeter、CodeMeter License Central、CodeMeter License Portalで既に採用されています。

リセラーは、CodeMeter License Portal上でライセンスを作成します。それと同時に、バックグラウンドにて、CodeMeter License Central上にも、同様のライセンスが作成されます。弊社では、リセラーが、ポータル上でエンドユーザーを「顧客」として追加し、ライセンスを自動で割り当てています。

ポータルへのエンドユーザーの追加は、すべてのプロセスにおいて任意ではありますが、ベンダー・リセラー・エンドユーザーにとって、多くのプロセスが簡素化される点で非常に大きなメリットです。さらに、ベンダーは、自社のソフトウェアを使用しているエンドユーザーを把握することも可能です。また、CodeMeter製品とGDPRに関するインフォメーションシートには、最小限のデータ収集、正当利益、削除の可能性など、このデータを収集する法的根拠も記載されているため、安心して使うことができます。

さらに、このソリューションは、既に紹介した、その他の3つのソリューションがもつ利点をすべて持ち合わせています。つまり、ライセンスは、柔軟性を備え、正確な時間指定、即時利用が可能です。また、ライセンス作成後の請求が可能であるとともに、サブスクリプションなどの期間は、特別なプロセス無しに、自動的に正しく取得することができます。

メリットだけでなく、デメリットも気になるところでしょう。以下では「権限」と「請求」という2つの側面から見ていくことにします。

リセラーへの権限付与

ベンダーは、リセラーに対し、ライセンスを作成する「権限」を与えます。CodeMeter License Portalを通じて、リセラーが作成できるライセンスやその設定を、個別に設定することができます。また、サブスクリプションの最短期間や最長期間など、個々のパラメーターの閾値を指定することも可能です。さらに、リセラーはライセンスを作成できる一方、ベンダーは、ライセンスがどのCmContainerでアクティベートされたかを確認し、不正使用が発覚した際には、CodeMeter License Centralのすべてのオプション（例：リコール、ブラックリスト）を使用することが可能です。

また、追加のオプションとして、ライセンス作成許可専用の「ポイントシステム」も用意されています。ベンダーは、一定の数または値をもったライセンスの作成を許可する権限をリセラーに与えるだけです。前述の、リセラーにポイントが付与される「ポイントシステム」とは異なり、これらのポイントは、CodeMeter License Portalにのみ存在し、オンデマンドで、実際のライセンスと交換できます。そのため、販売されたライセンスの透明性が担保されます。このポイントシステムは、弊社のプロフェッショナルサービスチームが、ベンダーの希望や要件をお聞きしながら、実装することも可能になっています。

ライセンスの請求

2つ目の観点は「請求」です。リセラーがライセンスを作成すると、この情報がまず、ERPシステムではなくCodeMeter License Portalに保存されます。従って、これらの請求データをCodeMeter License PortalからERPシステムへ転送する新たなプロセスが必要です。

しかし、先述の「ポイントシステム」を使うことで、この追加プロセスが不要になります。まずベンダーは、リセラーにポイントを販売し、ERPシステムを通じて請求を行います。その後、ポイントは作成され、ポータル上に配布されます。これにより、リセラーは、ポイントを希望するライセンスと交換することができます。

では、サブスクリプションの場合はどうなるのでしょうか。ここでは、「個別のプロセス」というデメリットが大きなメリットへと変貌を遂げます。私個人としても、プロジェクトの中で、ERPシステムがサブスクリプションをサポートしていなかったり、大規模な調整や設定、追加モジュールが必要となったりする場面を経験してきました。

CodeMeter License Portalは、請求月に作成されたすべてのライセンスと、請求月に有効なすべてのサブスクリプションを合わせた請求レポートを作成します。請求は、エンドユーザーまたはライセンスごとに個別で行うだけでなく、リセラー向けに合算して行うことも可能です。すべてを合算して請求書を作成する場合、ERPシステムは、合算した請求書のみ作成しますが、ポータルは、その請求書の個別証明としての役割を果たします。私たちWibu-Systemsでは、子会社やパートナーに対し、このプロセスを採用しています。もちろん、各リセラーやエンドユーザーごとに異なるプロセスを構築することも可能です。

サブスクリプションの請求時には、日割り計算を適用可能です。請求は、日単位または締め日のルールに従います。

特にドイツのソフトウェアベンダーにとって興味深いのは、会計上の区別ではないでしょうか。ドイツでは、サブスクリプションは購入時に計上されるのではなく、サービス期間にわたって計上されるのが一般的です。そうすると、通常暦年である会計年度、あるいは月ごとに計上しなければなりません。そのため、ドイツのプロバイダーの多くは、暦年に合わせて、契約期間を設定しています。しかし世界的には、サブスクリプションを、購入日に合わせるのが主流です。CodeMeter License Portalのレポートでは、この会計に準拠したサブスクリプションのの割り当てが可能です。

ソリューション

製品

ユーザー実績

サービス

サポート＆ダウンロード

リソース

パートナー

会社情報