Бизнес такси - форум директоров ИДС (реклама, бизнес, налоги, закон) => Программы такси => Тема начата: RTFM от 27 Мая 2013, 14:34:54
-
Вначале очень важная ремарка.
К обсуждению в этой теме приглашаются в первую очередь руководители диспетчерских служб, работающих по принципу обмена (покупки/продажи) заказами с другими диспетчерскими службами. А так же лица, хорошо знакомые с принципами работы «Сервера отмен» от компании EvoS или как называют в России его аналоги - «биржи заказов».
В этой теме (https://forum.taxiservice.com.ua/go.php?url=aHR0cDovL2ZvcnVtLnRheGlzZXJ2aWNlLmNvbS51YS9pbmRleC5waHAvdG9waWMsODAxLjAuaHRtbA==) я уже говорил, что приступил к работе над создание программного обеспечения для службы заказа такси. Мои заказчики пока не проявили интереса к сервису обмена заказами между диспетчерскими. Но я понимаю, что без этого модуля мою программу будет тяжело продвигать в крупных городах Украины, где большинство служб заказа такси уже привыкли работать по перекидке.
Чтобы не повторять чужих ошибок, я надлежащим образом изучил решения по обмену заказами, которые сейчас представлены на рынке. В частности модуль «Сервер отмен» от крупнейшего украинского игрока на рынке ПО для такси – компании EvoS. Меня интересовали все аспекты работы этого модуля, начиная от технических (стабильность, скорость, пропускная способность и т.п.) и до практики критических ситуаций организационного характера (выемка серверов, хакерские атаки, слив прав доступа), которые имели место быть в работе упомянутой компании.
Прошу не воспринимать это обсуждение как попытку критики чужого продукта! Я уважаю чужой труд, особенно лидеров отрасли. Это обсуждение попытка найти своё решение, которое будет лучше тех решений, которые уже существуют на рынке.
Перехожу к анализу существующей системы и предложения возможных альтернативных решений.
Начну с самого простого – архитектуры системы. Модуль «Сервер отмен» компании EvoS построен по принципу центрального сервера, к которому в качестве клиентов подключены сервера диспетчерских служб такси, участвующие в перекидке заказами. Это иллюстрирует картинка снизу. Прямоугольником с надписью EvoS обозначен центральный сервер обмена заказами, а кружками с цифрами 1-2-3-4-5 обозначены пять разных служб такси, участвующих в обмене заказами на данном конкретном сервере. Все кто работают сейчас на такой программе в Киеве могут сказать что система ещё сложнее и позволяет подключаться одновременно к пяти разным серверам. Но это не совсем так. Да, действительно, каждая диспетчерская служба одновременно может подключается ДО пяти виртуальных серверов обмена заказами. Но в результате принципиальная схема взаимодействия между диспетчерскими службами та же, только внутренний квадрат на рисунке нужно разбить на множество ячеек по количеству виртуальных серверов в городе.
[вложение удалено администратором]
-
Главное, и пожалуй единственное, преимущество такого архитектурного решение – простота. Вся информация по заказу, который один партнёр хочет передать/продать другому проходит через центральный сервер обмена заказами. К такому обмену информацией можно относиться как угодно, но я вижу в этом определённые риски для бизнеса. Шутка ли, через сервер проходят, и соответственно могут быть сохранены, обработаны и систематизированы миллионы чужих заказов! С номерами телефонов клиентов, адресами их поездок, контакты водителей и информация по их автомобилям. Можно сколько угодно заверять, что эта информация не собирается и ни куда не уходит, но факты вещь упрямая. Мой киевский приятель недавно жаловался, что потерял свой телефон и был вынужден купить новую SIM карту. На такси он ездит часто, и после того как он сделал несколько вызовов машины у одной и той же службы, к нему стали приходить SMS-ки из других служб такси, а так же спам от туроператора. Но это всё мелочи по сравнению с тем, если вся информация за несколько лет из центрального сервера обмена заказами попадает к более заинтересованным людям. К примеру к налоговикам. Даже если у Вас всё чисто и гладко, не думаю что ваши контрагенты и водители такси обрадуются такой утечке. Прошу прощения за опечатку в тексте рисунка, исправлять не буду по причине дефицита времени. :)
[вложение удалено администратором]
-
Теперь поговорим о стабильности и надёжности такого архитектурного решения. Казалось бы, что поддерживать устойчивую работу одного сервера проще чем нескольких и можно обеспечить ему полную защиту. Теоретически да. Но на практике за последний год у названной компании было не мало аварийных ситуаций, которые останавливали работу центрального сервера на время от нескольких часов до одной недели. Естественно, что без центрального сервера ни о каком обмене заказами между диспетчерскими службами не может быть речи. Все каналы обмена информацией разорваны. Что и показано на рисунке ниже.
[вложение удалено администратором]
-
Теперь перейдём к моему предложению. Проанализировав объёмы и темп передачи данных между диспетчерскими службами, я пришел у выводу, что если оптимизировать процесс обмена заказами, то нет ни какой необходимости использовать центральный сервер обмена заказами. Вместо этого можно связать партнёрские службы заказа такси по принципу "каждый с каждым", без передачи и накопления массивов информации на стороннем центральном сервере. Что и показано на рисунке.
[вложение удалено администратором]
-
При такой архитектуре система становится существенно более устойчивая к любым форс мажорным обстоятельствам. Если одна из диспетчерских служб по любым причинам (техническим или организационным типа "маски шоу" и изъятие оборудования) не может работать, то это разрушит только связи с данной конкретной службой.Если и вторая (третья, четвёртая... надцатая) служба тоже не работает, то вся система будет работоспособна до тех пор пока остаются хотя бы две работоспособных службы. Что и показано на рисунке снизу.
[вложение удалено администратором]
-
Я не претендую на изобретение чего то нового. Подобную или очень похожую архитектуру используют довольно широко для различных задач и решений. Из вероятных недостатков схемы я пока вижу только один - отсутствие единого центра обмена заказами не позволяет "держателю бочек" диктовать условия по обмену заказами между партнёрами. Полная децентрализация приводит к тому, что уже не нужно создавать виртуальные сервера с дружественными компаниями и платить за их использование кому то деньги. Не нужно выбирать администратора сервера, вырабатывать политику сервера и правила обмена, следить за их соблюдением, призывать к ответу нарушителей. Всё это становится не нужным. Каждый с каждым может договориться о размере комиссии за купленный или проданный заказ, об очерёдности перекидки - просто установив напротив имени партнёра значение таймера задержки. Можно прописать автоматический баланс по количеству взятых и отданных заказов, и тем самым при желании отгородиться от компаний "вампиров", которые много берут и очень мало дают заказов. Полная свобода.
Жду критику идеи. ;) pivo
-
Жду критику идеи. ;) pivo
Правильно думаете. Все рассуждения идут в правильном направлении. Еще годик и поймете что все можно было сделать круче, быстрее и дешевле.
А самое главное поймете то, что "бочки/обменники/отменники/агрегаторы" имеют очень короткий срок жизни и умирают едва родившись. Хотите толкаться локтями с Эвосом и Уклоном, предлагая тоже самое, но лучше, но без актива "счастливых клиентов" - Welcome!
Честно говоря для меня ваша идея морально устарела, потому как это пройденный этап размышлений.
-
Честно говоря для меня ваша идея морально устарела, потому как это пройденный этап размышлений.
Вы считаете толкаться локтями в любой сфере бизнеса пагубное дело? Уточните, что именно вы имели ввиду под выделенными словами, почему это устарело?
-
Вы считаете толкаться локтями в любой сфере бизнеса пагубное дело? Уточните, что именно вы имели ввиду под выделенными словами, почему это устарело?
Интереснее создавать то чего нет, и оно в корне отличается от того что есть, а значит полное отсутствие конкуренции.
Это означает новые термины, новые инструменты, новые принципы.
В свое время Эвос создал это "новое". Создал термины "сервер отказов, бочку, обменник" и на этом заработал. У него всегда есть фора, потому что он первый+раскрученный. В любом случаи сначала нужно потратить деньги "чтоб догнать", а потом еще потратить денег "чтоб обогнать".
С другой стороны у Эвоса вполне хватит и средств и специалистов чтоб в кратчайшие сроки перестроить свою систему или замутить "дочку". А с учетом того, что у него есть "счастливые клиенты" осуществить переход на "дочку" стоить для него будет копейки. А вот новой площадке, сначала нужно постараться оторвать клиента от Эвос уговорами, скидками и прочими пряниками объяснять что на ней они будут "более счастливы" чем с Эвосом.
-
В этом предложении вижу два положительных момента: возможное отсутствие платежей за перекидку( но тогда возникает вопрос о целесообразности софта для самого разработчика) и теоретическая безопасность бизнеса. Во всем остальном согласен с autooz
-
Жду критику идеи. ;) pivo
Не видя реализации идеи критиковать особо нечего.
Мне, как пользователю, важна не архитектура ПО, а его функционал и интерфейс.
Разумеется, при гарантии его стабильной работы и разумных требованиях по железу.
Перекидка заказов это только один из модулей диспетчерского ПО.
Его условно можно сравнить с одним из узлов/агрегатов автомобиля, скажем стартером или генератором.
Если стартер/генератор автомобиля работает надёжно, то водитель даже не задумывается о том, что в автомобиле есть такие агрегаты.
Ведь сами по себе в отдельности они не есть автомобиль.
И ни кто не будет хвалить транспортное средство только потому что там хороший стартер или генератор.
Водитель/владелец оценивает машину в комплексе, а не по частям.
Ведь для эксплуатации ему нужен автомобиль сразу "целиком", а не по запчастям.
-
А самое главное поймете то, что "бочки/обменники/отменники/агрегаторы" имеют очень короткий срок жизни и умирают едва родившись.
Откуда у Вас такие глубокие познания в работе "бочек"? ;)
Владеете или руководите ДС в Киеве?
Не буду говорить про всю Украину, но в Киеве за последние три года не открылось ни одно "типа такси" чтобы не влиться в те или иные "бочки/обменники/отменники/агрегаторы".
Скай не в счёт... там совсем другой расклад.
Есть и обратные примеры.
Много, в том числе и личный.
Те службы, кто позднее других перешел на обмены заказами потеряли как водителей, так и клиентов.
Хотите толкаться локтями с Эвосом и Уклоном, предлагая тоже самое, но лучше, но без актива "счастливых клиентов" - Welcome!
До Эвоса и Уклона лучшим продуктом для ДС такси был Такси Диспетчер.
И где он сейчас?
Где сейчас мобильные телефоны от Мотороллы, Сони, Эриксона да даже Нокии?
Наличие чего то "лучшего на сегодня" не означает что и завтра будет так.
Научно технический прогресс... знаете ли...
Честно говоря для меня ваша идея морально устарела, потому как это пройденный этап размышлений.
Сама идея возможно и устарела, но Ваша аргументация, как говорит молодёжь, "доставила" :-[
На жизненном пути мне неоднократно встречались "бизнесмены теоретики".
Которые теоретически уже давно миллионеры, и вопросы практического ведения бизнеса их мало волнуют.
Стратеги!
Как в том анекдоте: "Зайцы, станьте ёжиками, тогда вас коршун волновать не будет". :)
-
Интереснее создавать то чего нет, и оно в корне отличается от того что есть, а значит полное отсутствие конкуренции.
Интересно - да!
Согласен!
Но будет ли это "новое" в коммерческом плане успешно - хороший вопрос.
А если новинка будет коммерчески успешна, то кто именно получит этот успех, что называется "звонкой монетой"?
История знает только единицы коммерчески успешных изобретателей и новаторов.
Обратных примеров миллионы.
Вам ли этого не знать?
Это означает новые термины, новые инструменты, новые принципы.
Новые термины, это БП круто!
Вы не хуже меня знаете, что если взять некий давно известный процесс и придумать к нему новую терминологию, то всё это можно даже запатентовать!
:) applodism
В любом случаи сначала нужно потратить деньги "чтоб догнать", а потом еще потратить денег "чтоб обогнать".
Верно, но только отчасти.
Поскольку "срисовать готовое" всегда проще, быстрее и дешевле чем придумывать с ноля.
Поэтому и существует промышленный шпионаж.
С другой стороны у Эвоса вполне хватит и средств и специалистов чтоб в кратчайшие сроки перестроить свою систему или замутить "дочку".
Ведь у меня нет достоверной инсайдерской информации о состоянии дел компании и её учредителей/владельцев.
Возможно, что Вы более информированы, а значит и правы.
С другой стороны, я бы не рассматривал как конкурента для нового ПО именно Эвос.
Игрок он конечно серьёзный, но у наших ближайших соседей россиян есть куда как более серьёзные игроки.
Как минимум пяток монстров, по сравнению с которыми Эвос нервно курит в сторонке.
А с учетом того, что у него есть "счастливые клиенты" осуществить переход на "дочку" стоить для него будет копейки.
idea "счастливые клиенты" у Эвоса...?
Это что то новое. :)
-
Мне, как пользователю, важна не архитектура ПО, а его функционал и интерфейс.
Функционал и интерфейс это мясо и сало, архитектура ПО - основа/скелет.
А потому если архитектура спроектирована правильно, то гарантии его стабильной работы и разумных требованиях по железу, гарантированны.
Откуда у Вас такие глубокие познания в работе "бочек"? Скоро ДС не будет вообще, все к этому идет семимильными шагами.
Но будет ли это "новое" в коммерческом плане успешно - хороший вопрос.
А если новинка будет коммерчески успешна, то кто именно получит этот успех, что называется "звонкой монетой"? История знает только единицы коммерчески успешных изобретателей и новаторов.Если один будет создавать, а другой продавать, то успех будет. А если один будет и создавать и продавать, то на самом деле он будет либо "недосоздавать", либо "недопродавать" ;). Если для успешной коммерции чего-то или кого-то не хватает, нужно объединяться, а не разбегаться, тогда успех будет.
Вы не хуже меня знаете, что если взять некий давно известный процесс и придумать к нему новую терминологию, то всё это можно даже запатентоватьЭто действительно так. Неизвестное сочетание известных вещей есть изобретение. То что топик стартер нарисовал, называется "распределенная отказоустойчивая сеть" где отказоустойчивость выполнена за счет избыточности. И эта известная схема, по отношению к тому что есть сейчас в такси Украины (Эвосу) есть новацией и возможно изобретением.
Поскольку "срисовать готовое" всегда проще, быстрее и дешевле чем придумывать с ноля.
Проще новое и с нуля. Главное чтоб был продавец, который будет это продавать и продвигать. Легко написать когда у себя есть в этом необходимость и самому юзать. Сложнее это продвинуть тем кто мягко говоря "консервативен", еще хуже с теми кто занимает выжидательную позицию по отношению ко всему новому.
Те службы, кто позднее других перешел на обмены заказами потеряли как водителей, так и клиентов.Вот и я о том же. Кто занимает консервативную позицию или еще хуже выжидательную те как правило сами того не замечая отдают лидирующие позиции тем кто первыми подхватывает все то, что более эффективнее. Им остается потом только догонять молодежь (и это в их то годы, с их багажом опыта). И что самое главное у них есть два аргумента с которым спорить не возможно:
1. Это незнакомо клиенту, а потому априори оно невозможно
2. Это не удобно мне, а значит будет неудобно тем кто с этим будет работать
И самый главный аргумент (и одновременно самая главная ошибка)
3. Я не вижу массового использования этого.
Да тут же все просто. Если есть массовое использование - значит ты уже в позиции догоняющего!
-
Функционал и интерфейс это мясо и сало, архитектура ПО - основа/скелет.
А потому если архитектура спроектирована правильно, то гарантии его стабильной работы и разумных требованиях по железу, гарантированны.
Спасибо за разъяснение! :)
Но мне почему то кажется, что даже при правильно спроектированной архитектуре софта, итоговый продукт может иметь проблемы по причине ошибок кода и логики.
Я не программист, а потребитель программного продукта.
Пусть даже "продвинутый" но всё равно потребитель. :)
Поэтому меня в первую очередь интересует то, что и должно интересовать потребителя:
- функционал
- интерфейс
- надёжность/стабильность софта плюс техподдержка
- требования к железу
- цена приобретения и стоимость владения.
Всё остальное уходит на второй план.
-
Скоро ДС не будет вообще, все к этому идет семимильными шагами.
На сколько скоро? kofe
Я уже не раз говорил, повторю и здесь, что не считаю бизнес ДС/ИДС чем то статичным и непоколебимым.
Безусловно, научно технический прогресс внесёт существенные изменения в работу диспетчерских.
Вполне возможно, что эти изменения будут на системном уровне, что кардинально поменяет бизнес посредников, коими и являются ДС/ИДС.
Весьма вероятно, что большинство нынешних игроков окончательно уйдёт с рынка, освободив место новым игрокам или наиболее "продвинутым" старым.
Но не думаю, что то кардинально изменится в ближайшую пару лет.
З.Ы.
На мой вопрос:
Откуда у Вас такие глубокие познания в работе "бочек"?
Вы так и не ответили... kofe
-
Но мне почему то кажется, что даже при правильно спроектированной архитектуре софта, итоговый продукт может иметь проблемы по причине ошибок кода и логики.
Да нет.
Если неверная логика - не будет нужного результата вообще.
Если кривой код, то это просто увеличит нагрузку на процессор или потребует больше памяти.
Если ошибки кодирования, то будет глючить в местах ошибок или их тихонько накапливать проблему до "критической массы".
90% из этого вылавливается еще на этапе отладки, еще 5% на этапе тестирования. еще 3% в "разведке боем".
Но если изначально заложено неправильное использование БД, сети, процедур обмена и мпрочее, прочее, прочее ....., или софтина предполагает наличие "лабораторных условий", а в реальных условиях обеспечить этого невозможно, то это трындец.
-
На мой вопрос:
Откуда у Вас такие глубокие познания в работе "бочек"?
Вы так и не ответили... kofe
Не на публике. Это есть маленькая коммерческая тайна. Стоит только произнести вслух, как сразу все скажут, что в этом ничего нового нет, оно итак понятно как божий день, и мы как раз мыслим в этом направлении.
-
Если один будет создавать, а другой продавать, то успех будет. А если один будет и создавать и продавать, то на самом деле он будет либо "недосоздавать", либо "недопродавать" ;). Если для успешной коммерции чего-то или кого-то не хватает, нужно объединяться, а не разбегаться, тогда успех будет.
Всё верно.
Но здесь мы опять подходим к тому, от чего Вы так активно отмахивались в другой теме обсуждения.
А именно - распределению ролей и полномочий.
Я помню Вашу позицию в ТОЙ дискуссии.
Потому не буду варить воду.
Просто напомню:
Но будет ли это "новое" в коммерческом плане успешно - хороший вопрос.
А если новинка будет коммерчески успешна, то кто именно получит этот успех, что называется "звонкой монетой"?
История знает только единицы коммерчески успешных изобретателей и новаторов.
Обратных примеров миллионы.
-
Проще новое и с нуля.
Ну да! Конечно!!!
Наверное чистая случайность, что:
- первая советская ракета носитель использовала все наработки немецкой Фау-2
- первая советская ядерная бомба появилась только после утечки информации у американцев
- первый советский сверхзвуковой пассажирский самолёт ТУ-144 так сильно похож на Конкорд.
Список можно продолжить очень и очень.
Воровали бизнес идеи а то и целые модули/блоки/конструкции, все и у всех.
Это принято называть "промышленным шпионажем".
И что совсем НЕ зазорно, так это взять в открытом доступе готовое изделие конкурента, проанализировать его слабые/сильные стороны и сделать своё изделие ещё лучше.
-
- первая советская ракета носитель использовала все наработки немецкой Фау-2
- первая советская ядерная бомба появилась только после утечки информации у американцев
- первый советский сверхзвуковой пассажирский самолёт ТУ-144 так сильно похож на Конкорд.
Продолжу список
-Андроид, продолжатель Java и ПК и написан на Java с использованием наработок из мира ПК
- топик стартер додумался до своей идеи после изучения существующего Эвоса
Но это вовсе не означает что:
- в ракете заюзан движок от Фау а не созданый с нуля.
- что ядерная бомба америкосов была всунута в оболочку немцев, а не сделана самостоятельно
- в дельтавидном крыле Ту-144 применялись те же лонжероны что в Конкорде.
- в андроиде использована плата от ПК
- топик стартер будет писать но том же языке что Эвос
В основе лежат идеи и технологии, но не материалы. Их пощупать нельзя (в отличии от материального). Они не нематериальны (если не находятся на носителе информации).
И что совсем НЕ зазорно, так это взять в открытом доступе готовое изделие конкурента, проанализировать его слабые/сильные стороны и сделать своё изделие ещё лучше.
Проанализировать можно, но делать придется с нуля. Потому как проанализировать можно "видимую оболочку", а "внутренности" все равно придется делать с нуля.
По иному говоря - Просчитать идею и использованные технологии, и на их основе создать улучшенный либо совершенно новый продукт. И это всегда дешевле и быстрее чем "перестраивать построенное, а потом перестраивать перестроенное".
-
Спасибо участникам обсуждения! Я всё конспектирую! ;) Не хочу уводить обсуждение в сторону от моей работы, поэтому в двух словах о затронутых темах. Патентовать пока ничего не намерен. Жалко не денег а времени. ;D Продукты Эвоса и ещё трёх разработчиков хорошо изучены и взяты во внимание. Это сильно помогает в моей работе. Вижу где предшественники допустили ошибки и стараюсь их не повторять. Жду дальнейшей критики. pivo
-
. Жду дальнейшей критики. pivo
Не! Я не понял! Какой критики?
Идеи не критикуются -они обсуждаются!
Вы выложили идею - Вам сказали "Мысль верная."
Что еще нужно? Других то идей не озвучено с вашей стороны, а на эту уже есть "одобрямс".
Или вы хотите "команду форума", которая более детализирует идею и наметит пути ее реализации?