創立時、4年前、当社はその目的を理解していました。中小企業向けのSaaSの使用を簡素化します。 そして、元のビジネスモデルが誤って選択されていましたが、今回は常に自分のニッチを探し続けていました。 ロシアではクラウドサービスが急増し、景気後退が見られ、2番目の上昇が始まっています。 SaaS製品の組み合わせにおける当社の事業の詳細。 そして、私たちの主要なSaaS企業がどのように彼ら自身の市場の車輪にスティックを置くかを見ます。

SaaS開発者は頑固に価値のある製品を巨大なものとして販売しようとしています

SaaSはビジネスを構築するためのアプローチを決定するのではなく、ソフトウェアの配信方法を特徴づけます。 明確なアップ（たとえば、Google Keep）と複雑な製品（たとえば、Salesforce Sales Cloud）の両方がSaaSに属しているという事実は、いくらかの混乱を引き起こします。 SaaSがロシアで有望なビジネスと見なされたとき、2つの相反するアイデアが定着しました。 一方では、SaaSは大量販売向けの製品と同義語になり、他方では、作成される製品はビジネスのみに焦点を合わせています。



従うべき例は、37signals社（現在のBasecamp）です。 スタッフは18人の従業員で構成され、プロジェクト管理サービスである同社の製品は200万人の顧客に使用されました。 理想的なSaaS：多数の顧客が大きな収入をもたらし、規模の経済がインフラストラクチャと専門家を節約できます。 この印象的な例は、開発者に製品に集中し、費用のかかるオフライン活動を可能な限り避けるように促しました。 選択されたアプローチは、Evernote、Dropbox、Gmailでも確認されており、大規模な製品として成長しました。



同時に、創設者は2つのポイントに基づいてB2Bサービスを作成しました。

1. 個人も企業もまだSaaSに慣れていないが、後者には少なくともお金がある。
2. ロシアのビジネスには、確かに作業プロセスを自動化するツールが必要です。

2番目の論文は、ITアウトソーシングの経験によって補強され、欧米企業のプロセスアプローチが明らかになりました（同時に、「きれいな歩道があり、誰もが笑顔になる理由」という質問に答えました）。



開発者は、会社のビジネスプロセスを整理するサービスを作成したことがわかりました。つまり、既存の基盤を変更するふりをしながら、同時にオフラインアクティビティを除外しようとしました。 ビジネス向けの複雑なソフトウェア製品は、複雑な販売に加えて複雑な実装も伴う価値提案であり、大量生産として販売することは正しくありません。 この考えはまだ背景に残っています。 開発者は顧客からの迅速な結論を期待し、サイトをランディングページ（Megaplanなど）に類似させ、電話会社は実装の必要性（MySkladなど）を依然として否定しています。



顧客が会社の生活に大きな影響を与える衝動的な決定を下すように促されると、彼らは自然な混乱に陥ります。 その原因を理解するには、より広く考え、元の論文の真実を疑う必要があります。 この努力に集中して、販売とマーケティングを最適化することにより、st迷を排除しました。 朝、クライアントとのオフライン作業の必要性を感じて、メガプランは電話営業部を育成しました。 サブスクリプションでさまざまなトリックが考案されました。「エルバ」は月次期間を年次期間に置き換えました-感謝し、「落ち着く」ために、「ビジネス環境」は銀行サービスのアンケートの目に見えない点を通してクライアントに署名しました。 簡素化された登録および支払い機能。 自動的に最適化されたコンテキスト広告、リターゲティング、A / Bテストなどの強力なメカニズムが使用されました。 今日、「ライブサイト」と「コールバック」は流行しており、退屈で意欲の低い人を捕まえています。 Bitrix24やMegaplanなどの最も古いサービスのデータベースには、数百万の非アクティブなクライアントが含まれており、これらは期待が実現されなかったものです。



一部の創業者によって、販売方法の詳細な研究が宣教師の自己認識に変わったのは興味深いことです。 ビジネスマンは以前も現在もそうであり、CRMへの関心の欠如は彼らのビジネスにとってより重要な何かがあることの指標です。



今日、Wi-Fiに接続して、誰かの販売目標到達プロセスに進まないことは困難です。 サービスの登録および支払いシナリオは非常に最適化されています。 これらの手順は4分以内で完了します。 その後、システムにつまずいたクライアントは、高い確率で死んだリーダーになります。

ビジネス向けの複雑なソフトウェア製品は、複雑な販売に加えて複雑な実装も伴う価値提案であり、大量生産として販売することは正しくありません。

SaaS開発者はインテグレーターを抑圧し、顧客の世界観に彼らを置き去りにします。

SaaSの自己決定との混乱は、インテグレーターとの仕事に反映されました。 私は、企業の世界でよく知られているインテグレーターシステムインテグレーターを呼び出します。 SaaSの世界では、インテグレーターの概念はあいまいで、よりシンプルです（多くの場合、地方の流行に敏感なWebデザイナーであるため）。それらをパートナーと呼ぶのが習慣です。



SaaS企業は自社の製品をITスペシャリスト、インストール、および構成を必要としないものとして位置付けているという事実にもかかわらず、実装の複雑さを完全に無視できるとは限りません。 Salesforceの経験はプレイヤーによく知られているため、アフィリエイトプログラムは、クライアントとの大騒ぎを他の誰かの肩にかける試みで作成されました。



しかし、サービスクリエーターがアフィリエイトビジネスを構築する方法にはいくつかの機能があります。

1. サービス開発者は、実装を必要としないターンキーソリューションとして製品を顧客に提示しますが、これは顧客を誤解させます。 顧客の世界観にはインテグレーターはいません。 また、ほぼすべてのサイトに「パートナー」セクションがあり、そこにアプリケーションを残すことができますが、サービス開発会社はこれらのパートナーが必要であることを顧客に明確に知らせません。
2. まず第一に、サービス開発者は自分でサブスクリプションを販売しようとしています。 言い換えれば、彼らは代わりに複雑で高価なオフライン作業を行うことに同意した人々と競争します。 これらのSaaS企業は、権限を委任する意欲と権力喪失の恐怖の間を駆け巡る若いマネージャーに似ており、その結果、彼ら自身に疑問を投げかけ、全体的なプロセスを妨げています。
3. サービス開発者はパートナーの役割を認識していても、インテグレーターの存在をクラスとして除外しているため、パートナーはパートナーにすぎないことを意味します。 これにより、顧客はインテグレーターが顧客に最適なサービスを選択し、サービスインテグレーターとして行動できるという考えから遠ざかります。

したがって、SaaS企業は双方にとって有利な戦略を理解しているため、両方の勝利がSaaSに属している必要があります。 パートナーは忠実な犬の役割を果たし、運がよければ、アプリケーションは所有者のテーブルから外れることもあります。 そして、これが完全に倫理的に正しい戦略ではないことが今日の標準です。

サービス作成者は、複雑で高価なオフライン作業を代わりに行うことに同意した人と競争します。

SaaS開発者は統合を基本的なユーザー機能とは見なしません

過去8年間、サービスの統合に携わってきました。 最初はSesame Communicationsで、Practice Management System（略してPMS）と呼ばれる22のシステムとの統合をサポートしていました。 「PMSからのすべての問題」-これらのシステムは通常、警告なしに更新されたため、クライアント自体によってエラーが検出されることがよくありました（どこにも悪いことはありません！）。 次に、Startpackで、約20のロシアのSaaS製品を統合し、いくつかの発見をしました。



そもそも、ほとんどの場合、APIの存在はアーキテクチャに対する懸念によるものです。これにより、ビジネスロジックを別のレイヤーに取り込み、Web、モバイルアプリケーション、自動テストなどのユーザーインターフェイスを完成させることができます。 技術者は主に自分自身でAPIを作成します（それは単に楽しいからです）。 私たちはクライアントについて話しているのではありません。



技術者の2つのグループが出会うと、10のケースのうち10のケースで敵意が生じます。 この現象は1961年に社会学者のムザファーシェリフによって説明されました。 SaaS企業のリーダーの間違いは、そのような摩擦が無視され、時には奨励されることさえあるということです。 その結果、責任者のいないビジネスプロセスが発生し、バグの調査は「Again these rascals ...」という言葉から始まります。 非自明な統合エラーに直面したクライアントは、ほとんどの場合、同行する人を見つけることができません。



統合には、会社が会社自体を超える特別なワークフローを持つことが必要です。 これがないと、開発中のソフトウェア製品間の統合は脆弱で信頼性が低くなります。名誉の法律を遵守し、ソフトウェアインターフェイスを自動テストでカバーし、各配信後にバトルサーバーの統合を確認しても、パートナーが同じことを保証することはできません。



さらに、サービスにAPIがある場合、会社は仕様を空中に振ることで、今や複雑なタスクが解決されることを喜んでいます。 開発者は、APIが見知らぬ人と一致しない場合にイライラし、「悪役」（「RESTではなくSOAPを使用するほど愚かな」）に適応することに非常に消極的です。 したがって、クライアントがアクセス制御システムとの統合などの非標準ソリューションを要求すると、マネージャーは仕様を送信して「問題を解決」し、クライアント（家具メーカーなど）に矛盾する感情以外の何も与えません。 インテグレーターに連絡するというアドバイスは、開発者がクライアントの世界観にインテグレーターがいないようにすべてを行ったため、信じられないと信じられています。



市場（Bitrix24）および特別なセクション（amoCRM）を介した統合の拡張性に対するサービスの要望にもかかわらず、一般に、サービス間の通信は、最適化、意思決定者、およびサポートを必要とする本格的なユーザーシナリオとは見なされません。 この分野では、生命が活気づき、多様な生態系を生み出し、具体的な需要を満たすことができますが、サービスはこのユーザーニーズの層を無視します。

インテグレーターに連絡するためのアドバイスは、開発者がクライアントの世界観にインテグレーターがいないようにすべてを行ったため、ユーザー企業によって不信感を抱いています。

SaaS開発者は顧客の核となる恐怖を無視します

毎日、クラウドアプリケーション選択サービスのユーザーの1人と話をしています。 ストーリーの大部分は2つのタイプに分類されます。

1. 「私たちはそのような製品について知り、お金を払ったが、それを理解せずに捨てた」;
2. 「私がリーダーです。失うのが怖いので、私は今月、SaaS製品に関する決定を先送りしています。」

2番目のタイプについて話しましょう。 バックアップと移行の問題がIaaSとPaaSの誰にもわからない場合、システムイメージとダンプは簡単に保存、コピー、および他の場所に展開されます。SaaSでは、この問題が主な関心事です。 メガプランレポート「ロシアのSaaS / B2B市場の可能性」（2013年）で、オンラインサービスの価値を理解した回答者は、SaaSを使用しない次の理由に言及しました：27％-データを失う恐れ、26％-アクセスを失う恐れ。 正当な不信の53％。これは開発者によって「啓発の欠如」、「偏見」、「誤acy」と解釈されます。



正直に言うと、顧客がビジネス向けSaaSにサインアップするときは、インターネットへの支払いとは異なります。 彼は、サブスクリプション料金と調査と実装に費やした時間という形で投資を必要とする資産を取得します。 投資は自分で支払い、配当は増加し、投資を失うリスクは最小限でなければなりません。 日常の曇りの言語に翻訳されたクライアントは、サービスが利益をもたらすこと、利益が最大化されること（サービスが旗艦になること）、開発会社が閉鎖しないことを確信している場合、サインアップする準備ができています。 そして銀行の預金が何らかの形で国家によって保護されている場合、誰も保証を与えません。



起業家は愚か者ではありません。 サービスを選択すると、彼らは直感的にそれを資産として評価します。 RAIDとTier IIIレベルのデータセンターに関する意味不明な点には感心しません。 根本的に、彼らは「あなたの会社をあなたのサービスに植えます。あなたの会社が閉鎖したらどうなりますか？」という質問への答えを求めています。資産に関して、流動性の特徴は、迅速かつ損失なく交換を見つける能力です。



そして、ここでSaaS企業は答える必要がありません。 PlanFixシステムからプロジェクトをWireCRMなどに迅速かつ損失なくコピーすることは不可能です。MyBusinessからSkyに簿記を転送することはできません。 さらに、SaaS企業は戦略のこの部分を静かに考慮します。彼らは、私たちはそうではなく、SaaSであると言っています。 EvernoteとGoogle Freemiumのモデル「無料で座って、降りられないときに支払い」は、サービス開発者がさまざまなバリエーションで努力する理想です。 「すべてが私たちにとって信頼できる」というクライアントの恐怖に対する唯一の答えは、単に資産の流動性がゼロであることを意味します。



モバイル奴隷制の廃止に関する法律を覚えておいてください。 電話番号不寛容は競争を抑制し、顧客をオペレーターに人質のままにしました。 現在、私たちはクラウドの奴隷制を目の当たりにしています。SaaS企業は、顧客の最も重要な恐怖を無視して、顧客を追い出します。

現在、私たちは皆、クラウドの奴隷制を目の当たりにしています。SaaS企業は、顧客の最も重要な恐れを無視して、顧客を追い出します。

市場の減速を止める方法

SaaS開発者は、企業部門で採用されている「ベンダー-システムインテグレーター-顧客」に反対しています。 インタビューの1つで、アレクサンダープロゾロフ（当時-メガプランのパートナーリレーションディレクター）は、SaaSにはシステムインテグレーターと顧客の間にそのような利害の対立はないと強調し、SaaSは1回限りの使用ではないと考えていますいくつかのサービス、および長期的な協力に基づいて、サプライヤーと消費者の間の相互作用。 実際には、正反対が見えます。



ロシアの観光事業の構造を見てみましょう。 ツアーオペレーターは大量生産品を作成し、クライアントへの個人的なアプローチで旅行代理店を見つけます。 ツアーオペレーターは、製品作成の技術的問題を解決し、質量効果を使用して、コストを最適化します。 旅行代理店は、クライアントが適切な製品を選択するのを支援し、デザインを引き受け、付随し、恐れや疑念を取り除きます。



ツアーオペレーターは旅行代理店を尊重し、「私たちのすべて」と呼んでいます。旅行代理店は彼らと競合せず、旅行自体は良くなく旅行代理店は不要であるという考えをクライアントに与えません。 2010年までは、オペレーターのウェブサイトでツアーを購入することは不可能でした。現在でも、オペレーターからツアーを直接購入しても経済的利点はありません。 ツアーオペレーターは自分で代理店を押しつぶすのではなく、最適なツアーを選択する能力を尊重します。 これは、市場に必要な多様性を与え、空のニッチを満たし、不信を取り除きます。



考えてみてください。SaaS企業がツアーオペレーターと旅行代理店との関係を扱った場合、説明したすべてのSaaS問題はインテグレーターによって解決できます。 インテグレーターは、最適な製品を選択し、その場で製品を紹介し、ビジネスプロセスの変換を支援し、障害を取り除き、助言することができます。 リクエストに応じて統合し、同行できます。 インテグレーターは、SaaSでの移行とバックアップの問題を解決することにより、顧客の主な不安を取り除くことができます。 最終的に、これらの領域では、完全に調整された自動メカニズムを作成できます。 必要なのは、SaaSのインテグレーターが不要であるというふりをやめることだけです。



オフィスカートリッジの補充、家具の組み立て、ゴミの取り出しなどにお金を払うのが普通と考えられる驚くべき世界を作り出しましたが、SaaS製品を選択し、理解し、会社の活動に投影するのに非常に長い時間を費やすのが慣習です。



革新的な顧客はすでに既存のサービスを試しています。 大規模なマーケティングに巻き込まれた印象的な顧客はすでにお金を払っています。 実用主義者の時です。 私たちのビジネスマンは人々を信頼します。 ビジネスマンは、「サービス」という言葉が空のフレーズではない、オフラインでクライアントと仕事をする方法と愛好家を知っている責任者との長期的な関係を必要としています。 そして、この新しいドライバーはインテグレーターになります。 SaaS開発者がこれに気付くのが早ければ早いほど、ロシアでの新しいクラウドルネッサンスが早くなります。

ツアーオペレーターが旅行代理店に関連するのと同じ方法でSaaS企業がそれらを扱った場合、説明されているすべてのSaaS問題はインテグレーターによって解決できます。

雑誌In the Cloud.RF№3に掲載されました



スピーカー：アレクセイ・フェドロフ、 Startpack CEO



雑誌「In the Cloud。Russian Federation」の第3号は、 AppStoreおよびGoogle Playストアのモバイルデバイスに無料でダウンロードできます。