この記事では、タクシー市場がどのように発展しており、情報技術の発展がその形成にどのように影響しているかを説明しようとします。

回顧

オペレーターは電話に座って、顧客からのアプリケーションをノートに受け入れて記録します。 それから、トランシーバーで、彼は注文を取る人のためにドライバーにインタビューします。 このような作業の組織には、ライン上の同時マシン数に関して制限があるため、多くの注文は実行されませんでした。



電話は会話の記録を備えたIPテレフォニーゲートウェイに変わり、ノートブックはAWPに変わり、サーバーはアドレスでのクライアントの座標を決定し、最も近いドライバーを割り当てます（または、最も近いドライバーとそこにいる人に順番を示します）。 会計は自動です。 実現可能性が向上しました。 現在、優れたサービスにより、受信したすべての通話の80〜85％を占めています。



ウィル：人々は電話でタクシーを呼ぶのをやめます。 より正確には、彼らは呼び出しを停止します。 通話は、携帯電話のボタンを1つ押すだけで実行されます。 自分で比較してみてください。何が良いのか、1分ほど待って、現在地を説明してから30分間待つか、ボタンを押してください。 あなたが国中を旅行するなら、あなたは本当に異なる数字を覚えたくないという事実については話していない。



「いや、息子、これは素晴らしい！」とあなたは言います。 そして、私はいくつかの場所でこれがすでに機能していると言います。



輸送の楽園の差し迫った到来のために、現在の状況の変化が必要であることは明らかです。 それでは、何を変更する必要がありますか？

「ボタン」

ボタンでタクシーを呼び出すには、少なくともボタンを作成する必要があります。 これは、クライアントモバイルアプリケーションです。 このアプリケーションの主な目的は、クライアントの時間を節約し、できるだけシンプルに作業することです。 非常に異なる方法でそれを行うことができます。 一見すると、オプションは次のとおりです。



電話帳

これはボタンではなく、都市ごとの単なる電話のセットです。 自分で部屋を探すよりも良いのですが、ここでメリットが終わります。 その実装例はHadnoideaです。



Cab4meの西洋版もあります。 彼らはタクシーの運転手に彼らがサービスを提供するエリアを地図上で強調するために提供します。 クライアントがアプリケーションを起動すると、そのエリアで働くすべての人が見えます。 時々、アプリケーションは最寄りのタクシー乗り場を表示します。



ボタンアプリ

アプリケーション（登録）に電話番号を入力します。 ボタンを押すと、番号と座標がタクシーサービスに送信されます。 さらに、すべてが今のままで発生します（コールバック、SMSの送信など）。 不利な点は、あなたがいつ誰に来るか、彼らが来るかどうかについて長い間無知であるということです（約85％を覚えていますか？）。 私は生きている例を知りません。 たぶんあなたはユーザー名を試してみてください？



リモートアプリケーション

登録します。 簡単なフォームに記入します。 より正確には、「where」フィールドを1つ選択して、「order」をクリックします。 次に、アプリケーションのステータスを監視します。 必要に応じて、注文を確認するか、車が到着したときに通知するためにコールバックされます。 注文する際に、タクシークラス（およびタクシークラス）を選択し、他の設定を指定できます。







確認済みの番号と詳細な旅行の詳細が記載されたこのようなアプリケーションは、複数のタクシーパークに一度に、または取引所にさえ送信できます。 理論的には、このような注文が実行される可能性は高くなります。 実際には、注文の履行が正常に達するか、それを超える前に、アプリケーションでまだ多くのことを予測して実行する必要があります。



私たちのチームはそのような試みをして、 テレポートを得ました。 もちろん、私たちにはまだやるべきことがあります。より多くの公園を接続し、都市を追加し、応答時間と納車時間を短縮する必要があります...しかし！ すでに常連客と一定数の注文が毎日あります。



また、注文後、より高い価格で出発するか、より速くまたはより安く出発するかを選択するオプションが提供される場合、トピックに関するバリエーションがあります。 すべては、さまざまなタクシーパークからのオファーのリストの形式で配置されています。



ロシアのアナログ：

• estaxi.ru （開発中）、
• taxionline.ru （作品）、
• InTaxi （開発中）。
• Yeehayは証券取引所である可能性が高くなりますが、その詳細については下記をご覧ください。

別のアイテム、地域のキャリアからの悪夢の実装：

• タクシーからのJavaリモートコントロールはLUCKYです。ピッキングの2日目にのみ注文できました。 インテリジェンステストとして使用できます。
• WESTからの同じ便利なバージョンのタクシー（ウェブサイトダウン）
• WapTaxiはJavaアプリケーションです。 ウェブサイトはありませんが、フォーラムはあります。 2年間のように働きます。

他の同様の試みがあります。 しかし、それらのいくつかは開始さえしません。



ウエスタンアナログ：

• TaxiPal-伝えられるところによれば 、ヨーロッパとアメリカで営業しています。 実際、注文と追跡のスキームは一部の国でのみ機能します。 残りの部分では、アプリケーションは電話帳のように機能します。
• GetTaxi.com-ボタンを押して、車があなたに向かって行くと地図をたどります。
• Wheely-関連する何か、まだ開発中。 Rubiniusのコミッターと、新聞のスタジオの元デザイナーである Oleg Chirkunovの息子であるクールなオブジェクト開発者と、チームで4言語に堪能な人を作ります。 なぜ「西洋の対応」に陥ったのですか？ そして、これは正しい質問です:-)

このリストは完全にはほど遠いと思います。 タクシーを呼ぶためのアプリケーションのアイデアは、多くの明るい心を刺激します！



Webアプリケーション

モバイルブラウザ用のWebサイトを作成する方がはるかに安価なのに、なぜ異なるプラットフォーム用に作成するのですか？ ありがたいことに、彼ら（ブラウザ）は地理位置情報機能をサポートし、クライアントのデータベースさえサポートしています。 しかし、ご存知のように、Webアプリケーションではすべてが素晴らしいとは限りません。 したがって、どうやら、 品質が 「ネイティブ」アプリケーションに対応するアナログはまだありません。 おそらく、ちょうど数人の正しい仲間がまだ見つかっていませんが;-)

注文処理率の向上と応答時間の短縮

2番目の問題は、実行可能性の向上です。 正式には、それは簡単に解決されます。多くの車が必要です。 実際、システム内のすべての瞬間、および空間のすべてのポイントで、ドライバーと注文のバランスを確保する必要があります。



多数の法則に基づいて、大きな公園には利点があることは明らかです。 しかし、モスクワの最大の公園でさえ、みんなを「連れ出さない」。 理由は何なのかは定かではありません。機械の不足や技術の不完全さです。 私はそれと別の両方が起こると思います。 一番下の行は、これらの問題に基づいて、すべてのグローバルな統一によってそれらを解決する試みがあるということです。 しかし、繰り返しますが、さまざまな方法で組み合わせることができます...



取引所

すべてがシンプルです。 注文交換があります。 一部は、彼らが満たすことができない命令を与えます。 他の人がそれらを受け取って実行します。 ドライバーが与える手数料は、ほぼ等しい割合で削減されます。 繰り返しますが、私にはわからない理由で、トップのタクシー会社は両替所に参加していません。 おそらく、顧客の目にあなたのイメージを損なわないために。 または、たとえば、100台以上の自分の車で公園を管理します。 すべての車は新鮮なEクラスメルセデスです。 価格セグメントはプレミアムです。 クライアントは誰に注文すればよいですか？ はい、誰も、一般に。 そこに送られるのはローガンではありません。



交換に関する別の問題は、交換が仲介者であり、技術的な相互作用のプロセスに独自の「ノイズ」を追加することです。 つまり 実際、注文は複数のゲートウェイを通過する必要があります。各ゲートウェイは個別の会社が所有し、各ゲートウェイは独自の原則に基づいて構築および運用されます。 結局のところ、単一の標準はありません！



モスクワにはいくつかの交換所があります。 サンクトペテルブルクでは、すべてが平均的です。 他の都市では、交換交換は実際には存在しないか、私はこれについて何も知りません。 （地域のタクシー車両を食べて、それぞれの申請の流れを完全に制御している派遣事務所と交換を混同する必要はありません。）



ちなみに、すでにHabréで言及されているOpen-taxiプロジェクトは、本質的に独自の取引所であり、独自の生産の顧客向けの注文インターフェイスを備えています。 良いソフトウェアとモスクワでの成功した交換の例： RBTaxi



自身のネットワーク

上位のタクシー隊が同時にタクシー隊のAWPの開発者であることが判明しました（例外はInfinityです）。 理由はありふれている：パラノイア（すべてがそこにある！）そして、アプリケーションの実際のリストを持つベースが税務検査官の手に落ちるかもしれないという恐怖（そしてこれはほとんどどんな公園でも差し迫った執行である）。 したがって、異なる都市の100のタクシーパークがソフトウェアを使用する場合、共通のネットワークで全員を団結させず、アプリケーションを交換しないことは罪です。 例は同じです： taxionline.ruとestaxi.ru



繰り返しますが、特定の都市で特定のソフトウェアが世界的に支配されている例はありません。 したがって、実行可能性の％の増加に大きな結果はありません。



さらに、企業クライアント向けに約5年間ソフトウェアを既に使用しており、AWPが彼らにとって最も重要なものではないような大規模プロジェクトで使いやすさに慣れている場合（まあ、それはあなたが思うことです）、真剣なクライアントアプリケーションを作成する必要があります自分と従業員のための脳のリファクタリング。 上記のWESTタクシーおよびタクシーLUCKの経験（リーダーでもあります）、これは明確に示しています。

乗組員、ドライバー用の機器

タクシー乗務員の装備方法も、申請処理の速度に影響します。 車内にナビゲーターを備えたタクシーメーターがある場合、交通渋滞を考慮してルートを計算するサポートがあります。 また、Javaアプリケーションを備えた古いNokiaの場合、「from-where」アドレスが2つとクライアントの電話番号のみが表示される場合はまったく異なります。 注文のステータスと車の位置に関するクライアントへの即時通知について話す必要はありません。



さらに、サービスごとに異なるポリシーがあります。どこかで、ドライバーは自分が好きな注文のみを受け取ることができ、どこかですべての割り当てを履行する義務があります。 問題は、この場合、ドライバーの利益がクライアントの利益と対立することです。

コスト最適化

ビジネスプロセススキームに多くのコストと欠陥がある場合、価格を上げるか、品質を犠牲にする必要があります。 そして、これは、注文の高い最低コストの存在、空港からの旅行などの追加料金などを意味します。

誰が勝ちますか???

根元を目撃し、この場所への読書を成功裏に習得した人々は、「わかりました！ 私たちはサービスの形ですべてを自分でしなければなりません！ そして、ボタン、およびドライバー用のAWPとソフトウェア/デバイス！”ありがとう、キャップ。 Taxoflyの人々はこの素晴らしいアイデアを実現しようとしています。 また、すでに上で書いたGetTaxiについても。



しかし、このような巨大なアイデアでは、成熟した市場への参入は非常に問題があります。 一度に多くのドライバーと一度に多くの顧客を見つけて、これらすべてを同時に実行する必要があると思います！ ここでの利点は、ワークステーションの既存の開発者です。 クライアントアプリケーションを作成する方法を学ぶ必要があります。