1. Учет рабочего времени с момента выхода на линию.

Применяются различные подходы организационного и технического характера, например, водители выполняющие заказные случайные перевозки обязаны по приходу на АТП открыть автомобиль и включить зажигание (возможно попутно завести, прогреть, продиагностировать готовность ТС). С организационной точки зрения это несложно и вполне оправданно, а с технической дает возможность учета по событию “Зажигание” четкий момент появления водителя на АТП. Заказ может поступить в течение дня, однако водитель таким образом уже зафиксирован на работе .

Другой пример: все автомобили на АТП, выполняет доставку товара, причем АТП совмещено с предприятием выпускающем товар.  В этих случаях имеется фиксированное начало рабочего дня в 6:00 утра и хотя фактически автомобиль может выехать после загрузки товаром, начало рабочего дня фиксировано. Зато как узнать окончание? Т.к. автомобили развозят товар ежедневно, но по высоконагруженным и меняющимся маршрутам, время окончания рабочего дня зависит от множества факторов. Возникает понятие переаботки в некоторые дни недели. Оплата переработок, как и вообще отслеживание баланса в этом вопросе выполняется с использованием отчета о переработках. Он базируется на автоматической фиксации моментов въезда (возврата) на АТП с помощью географических зон GPSBOX.

Третий пример: автомобили вообще не на АТП, а на отстое у места жительства каждого агента. В этом случае руководитель вообще не в состоянии никаким ручным методом зафиксировать время начала рабочего дня у агента, особенно, если агенты в 26 городах страны! В этом случае используется засечка момента начала рабочего дня на основе механизма пользовательских точек интереса. Это типичные проблемы больших торгово-производственных предприятий с региональным распределением торговых представителей (агентов).

2. Учет рабочих процессов на протяжении дня. Еще интересней (и сложнее) варианты использования функций GPSBOX для учета рабочих процессов внутри рабочего дня. На рис.1  показаны оплаченные перевозки грузовых такси. В течение дня автомобили могут быть заказаны несколько раз на мелкие заказы или единожды на весь день. В этом случае технологии используются уже для рассчета стоимости обслуживания (по факту). Алгоритм, который использует уже в программе 1С, основан на продолжительности (чч:мм) или протяженности (км) рейса, а также географическом месте начала и (или) окончания рейса — тарифные зоны. Учитываются даже тарифные зоны всех остановок ТС для особых случев и конфигураций рейсов. Эти данные поступают из системы GPSBOX  по каждому автомобилю, что позволяет осуществлять достоверный биллинг заказов и приводит к повышению доверия заказчиков.

Картинка также наглядно показывает загруженность автопарка и то какие ТС пользуются наибольшим спросом.

Понятно,что и все количественные показатели временных показателей фиксируются и позволяют вычислять эффективность работы как служб доставки, так и специфических агентских заданий:

1. количество доставок/ посещений в день;
2. самая первая доставка дня/самое первое агентское посещение;
3. самая долгая, самая быстрая и средняя доставка/посещение;
4. суммарная длительность в доставках/посещениях и различные отношения ее к пробегу, к всему рабочему времени и т.п.

Если в некий отчетный период вы в состоянии приложить к этой статистике и финансовые показатели эффективности водителя/курьера или агента — вы можете эффективно управлять персоналом на основе реальных показателей. Это и должно быть целью любого руководителя!

на видео: расчет стоимости подачи (доставки) транспорта в любую точку Украины. Совмещенные способы тарифного зонирования и покилометрового расчета. В дополнение к рассмотренным ранее возможностям системы GPSBOX по пространственному анализу событий происходящих с транспортом и точек (POI, точек доставки и т.д.) в этом разделе объясняется использование пространственных зон. Данный метод применяется при зональной тарификации стоимости подачи в грузовых такси (случайные заказные грузоперевозки).
Практика достаточно проста: при получении заказа по телефону или иным способом, диспетчер в один-два клика в состоянии получить расчет стоимость подачи автомобиля в указанный район (кликом на карте или поиском улицы, адреса). Тарифное зонирование может быть простым или сложным, в данном случае — несколько замысловатое: недостаточно простого принципа удаленности от центра города, есть еще и нас. пункты (пригороды) в которых тарифный коэффициент меняется. Поэтому сформированы правила и исключения тарификации. Основание для такой тарификации — опыт автотранспортного предприятия.

рис.1

На рис.1 показана достаточно интересная зона — “центр г. Киева”, куда въезд крупнотоннажного транспорта осуществляется только по разрешениям. Тарификация этой зоны — максимальная, при этом эта зона-исключение находится в центре наименее тарифицированной зоны-правила (коэффициент=1).

По-сути, POI, это аналог рассмотренных ранее точек доставки (ТД), используемых в бизнесе регулярных доставок (развозок товаров). В  отличие от  точек доставки, пользовательские точки интереса — это более широко и вольно трактуемые объекты. У них нет связи с планом, графиком доставки, им необязательно  иметь бизнес-ориентированные идентификаторы. Это совершенно произвольные географические точки, с какими-угодно наименованиями и смыслом, вкладываемым в них исключительно самим пользователем.

Варианты применения:

1. скалывание на карте десятка АЗС на которых регулярно заправляются автомобили фирмы. (Мы также можем изначально залить всю сеть АЗС в качестве предустановленных POI по просьбе клиента). Позволяет получать в списке “Посещения POI” события (время, длительность) заправок на АЗС и проводить сводку с данными сети АЗС об обслуживани карточек безналичного рассчета за топливо(ссылка).
2. скалывание мест ночного отстоя транспорта, при распределенном хранении без АТП. Применяется для фиксации прибытия агентских автмобилей к месту жительства агентов.
3. скалывание мест регулярных посещений, например несколько офисов, ключевые заказчики, любые другие часто посещаемые места.
4. создание небольшой БД а-ля точек доставки. (до нескольких сотен ТД).

Метод создания POI исключительно пользовательский: клик на карте и задание наименования для POI — вот и все,что нужно! Соответственно вы можете редактировать и удалять элементы списка POI.

Важно понимать,что механизм POI может быть использован на начальном экспериментальном этапе создания системы контроля доставок самостоятельно клиентом и без привлечения администраторов GPSBOX, однако, полноценная реализация методики контроля план-факт требует чуть более сложной реализации. Прежде всего POI  статичны, т.е. их набор постоянный изо дня в день, а план-факт требует динамических данных ежедневного планирования: какие точки доставки (+ когда?) в этот конкретных день необходимо обслужить конкретному автомобилю.

Естественно, как и все в системе GPSBOX, посещения POI экспортируются в Эксель и могут быть проанализированы по количеству, суммарной длительности и т.д.

Процедуры, в свою очередь, обеспечивают фильтрацию событий, обратное геокодировние (взятие адреса), анализ пространственного пересечения  точки доставки (ТД) и события доставки и выдачу результата.  Все это функциональность программы, работающая для любых клиентов, однако она опирается на специфические данные — пространственную базу данных точек доставки (БД ТД). Создание такой БД в каждом случае особая задача, полностью зависящая от исходных данных, качества процесса и возможностей Заказчика выполнять эту работу. Это не автоматический и даже в некоторой степени творческий процесс

Поэтому мы всегда подстраховываем этот процесс и можем создать такую БД ТД. Разработана полностью документированная методика, доступная Закзачику, благодаря которой БД порядка 200-1000 шт. точек доставки Заказчик может создать сам, ежеденевно уделяя процессу 40-60 минут. Кроме того, мы обладаем возможностями организовать процесс массовой обработки данных для больших БД ТД ( около 10 тыс. записей). Создание качественной базы данных ТД размерности около 10 тыс. записей занимает примерно 2-2.5 месяца.

методика создания и поддержки базы данных точек доставки описана и доступна пользователям Заказчика. Проводится обучение.

В основе методики лежит  также необходимость подержания пространственной БД точек доставки. База данных точек доставки может самостоятельно поддерживаться сотрудниками клиента — для этого есть все механизмы. Первичное создание БД точек доставки  может быть сделано по согласованию с разработчиками в автоматическом режиме, что существенно уменьшит объем рутинных операций по внесению данных.

Кроме  того, в большинстве случаев в транспортном бизнесе точное местоположение  каждого клиента часто неизвестно сотрудникам клиента (логистам), хотя известно водителям. Этот парадокс* рождается из-за некачественного описания  используемых АДРЕСОВ, что оставляет место для неоднозначностей и ошибок. Водитель, обучаясь точкам доставки методом “проб и ошибок” в итоге знает куда везти оперируя десятками точек в день, однако руководящие им логисты, оперирующие тысячами точек виртуально, не в состоянии  знать где в точности  расположена каждая точка доставки. Это означает, что создать БД ТД с чистого листа без определнной методики они чаще всего не способны.

*) У этого парадокса есть и неприятная сторона: ведение бизнеса начинает полностью зависеть от знаний водителя, он, а не менеджмент логистики становится носителем знаний из-за который зависит качество доставки. Это зачастую делает невозможным элементарные действия по замене или увольнению водителей, не дает возможность управлять качеством процесса. Водитель становится малоуправляемым и искусственно переоцененным ресурсом компании.
p.s. Описание возможных проблем декодирования адресов выходят за рамки этого раздела,  некоторые будут собраны в разделе ошибки (ссылка).

Контроль нарушений своевременности доставки — это дальнейшая эволюция развития проектов мониторинга транспорта. Вы уже знаете СКОЛЬКО пробегает автомобиль выполняя задания, вы уже знаете ГДЕ и КОГДА он побывал и естественным шагом будет узнать ВОВРЕМЯ или нет он это сделал.

Есть и другая мотивация перехода к контролю своевременности и выявлению нарушений:  в автопарках уже от 20 и более ТС заниматься ежедневным и постоянным мониторингом всех событий достаточно сложно. В бизнесе регулярных доставок это сотни событий в день, зачастую в пиковое время это десятки событий в течение 5 минут и оператор физически не способен реагировать на все. В чем же выход?

Выход в применении принципа Реагируй на измененения/Реагируй на нарушения: внимания сотрудника требуют лишь нарушения процесса, а все,что является допустимым, вообще происходит естественным образом, накапливается в архив и может быть изучено, но не требует этого.

Применение этого простого принципа позволяет на порядки снизить количество времени необходимое на анализ происходящих в доставке событий и занять сотрудника действительно важным процессом, который  только ему под силу: выявить и устранить (возможно в будущем) реальные причины нарушения, устранить конфликты между участниками: перевозчик-заказчик, иногда скорректировать план выполнения.

На заглавной картинке два примера визуализации проблем своевременности доставки. В зависимости от того, насколько детально проработан план логиста, можно контролировтаь следующие параметры:

1. собственно факт доставки по конкретному клиенту (по его уникальному номеру и адресу).
2. реальный порядок доставки и плановый
3. величину опоздания по окну клиента.(Окно клиента, например 10:00-12:00 — это диапазон времени в который клиент-получатель согласен получить товар доставки. Нарушение окон, зачастую делает невозможным саму доставку или приводит к штрафным санкциям);
4. величину преждевременности доставки по окну клиента;
5. величину преждевременности или опоздания относительно планового времени (при наличии автоматизированного точного планирования);
6. величину задержки длительности доставки по отношению к плановой.

Простейший план представляет собой таблицу, например Эксель документ такого вида:

один из вариантов плана логиста

Даже такой простой документ загруженный в систему позволит контролировать одновременно и опоздания в пределах окон клиентов и смещения относительно планового времени. Причем для обоих параметров можно установить  допуск в минутах.

Система GPSBOX контролирует факт посещения и все временные параметры на его основе, оперируя исключительно формальными понятиями: точка доставки (код, расположение), время (фактическое, плановое, время окон, длительность фактическая, длительность плановая). Никакие реальные бизнес-данные заказчика не являются постоянно необходимыми.

Итак, вернемся к принципу: Реагируй на измененения/Реагируй на нарушения. Для приведенных в галерее иллюстрации это означает, что пользователь системы должен реагировать исключительно на отмеченное красным, причем критические ошибки — выделены жирным шрифтом. Вообще форматирование может быть каким угодно.

Но вот вопрос как пользователь узнает о том что нарушения произошли в реальном времени?

На картинке дана пошаговая диаграмма, изображающая то как это происходит в системе GPSBOX в реальном времени:

1. на почту менеджера-логиста приходит сообщение о нарушении: нарушении конкретной точки доставки или целый список нарушений по окнам клиентов.
2. в тексте письма, в списке нарушений содержится описание того кто, когда и на сколько опоздал относительно расписания доставок.
3. в тексте каждого нарушения содержится линк, при клике на котором, происходит открытие страницы расписания на которой можно увидеть нарушение: все его временные параметры, а также место и передвижения автомобиля. Видна также и общая тенденцию на данный момент.

Хорошо, узнать о случившемся нарушении можно практически мгновенно, а вот как предотвратить его?

И на это случай есть решение. Кроме уведомлений о нарушениях, существуют и предупреждения. За 30 минут до окончания конкретного окна доставки все недоставленные к этому моменту задания высылаются списком. По величине опоздания относительно планового времени менеджер-логист может принять решение и уделить внимание доставкам конретного автомобиля. Например, на рис.2 в галерее к этому разделу показан пример, как произошедший сбой (после 4-й доставки, 9:11 утра) привел к систематическому опозданию по нескольким следующим точкам.

Контроль своевременности доставки может быть сколь-угодно специфичным и удовлетворять особые требования клиента. Также способы загрузки плана, получения аналитических документов план-факт анализа и уведомлений могут быть адаптированы под конкретного клиента. В этом статье использовался пример высоконагруженного бизнеса с большой плотностью доставок как во времени, так и пространстве. Это, пожалуй, один из сложных случаев, требующий тщательной проработки пространсвенной базы данных точек доставки. Работы по созданию таких БД будут описаны в отдельном разделе .

это кусочек интерфейса сайта. Конечно же есть и соответствующие отчеты о Доставках в виде таблиц Экселя.Читайте об этом под тэгом "отчеты"

Адресация доставки это процесс определения текстового описания места в котором произошло событие “Доставка”. Откуда берется само событие можно прочитать здесь. Процесс адресации несколько сложен и требует понимания. Дело в том,что в основе его лежат процессы геокодирования/обратного геокодирования решаемые геоинформационной системой (а не GPS как таковой).  Там есть нюансы, мы их доводим Заказчикам на их конкретных примерах рассказывая и показывая. Все с целью сформировать у Заказчика правильное понимание процесса и самое главное — правильное ожидание результата!

Тем не менее, для большинства видов деятельности транспорта получаемые результаты очень хороши. Для еще большего качества и решения специфики малонаселенных районов и трасс (номерных автодорог) имеется функция “Радар”

Для клиентов не использующих кнопки “Доставка” возможна адресация остановок, однако имеется ограничение оговариваемое при создании сайта: адресации подвергаются только остановки с длительностью большей чем [параметр в минутах], к примеру больше чем 15 минут. Такой параметр выбирается исходя из особенностей бизнеса Заказчика. Сделано это для уменьшения нагрузки и попытки не засорять событиями остановка списки предназначеные для чтения. Ведь остановок, особенно кратковременных бывает много, а бизнес-событий связанных с остановками обычно на порядок меньше. Это неплохо работает, если к примеру автомобиль используется в задачах “склад-магазин”. В таких задачах 1-2 минутная остановка на светофоре и 40 минутная разгрузка никак не похожи и отфильтровывание непродолжительных остановок и адресация продолжительных улучшают понимание.

Гораздо сложнее, к примеру в доставке бутилированной воды: там бизнес-остановка (с целью доставки) и транспортная остановка (светофор, затор, уступи дорогу) очень похожи. Иногда бутилированую воду грузчики “сбрасывают” за минуту-две. Для транспортного бизнеса с кратковременными доставками и большой динамикой на малой территории мы однозначно рекомендуем нашу методику настоящей обратной связи. Тут можно прочитать какие дополнительные преимущества это дает. (ссылка…)

Также близким по реализации являетмся адресация текущего местоположения автомобиля. Этот “объект” всегда имеет адресацию, что помогает не вглядываясь в карту понять местоположение прочитав его одним взглядом.

Да, собственно любой объект в системе имеющий линк при клике на этом линке выводит адресное описание местоположения, поэтому даже безымянные остановки на самом деле могут быть адресованы.

Подведем итог

четкие, красивые адреса в стандартной манере описания адреса могут получать: Доставки, Остановки, Текущее Местоположение Автомобиля, да и вообще любая точка на карте, в которую вы кликнете и  построите маршрут. Что такое Маршрут читайте здесь (ссылка)

Да, конечно же есть и еще более изящное решение! О нем читайте в статье разъясняющей случайные доставки и доставки по клиентам

Да, автомобиль с GPS это уже не просто автомобиль, однако это еще и не полностью управляемая бизнес-единица.

Как в реальности управлять бизнесом перевозок?

Одним из принципов, которые мы внедряем является: принцип обратной связи. Он состоит в том, что связка водитель+автомобиль должна быть доступна для управления точно также как офисный работник, к которому руководитель всегда может подойти (или вызвать его) и задать ключевые вопросы:

1. Что ты делаешь сейчас?
2. Что ты уже сделал?
3. Что ты не сделал?
4. Как много еще требуется времени  на выполнение поставленной задачи? (Когда предположительно можно дать следующее задание)

При этом, само собой разумеется , что задача определена.

Обратная связь поступающая от работника в любой момент времени позволяет руководителю понимать процесс выполнения задач. (Тут нужно мыслить шире, ибо речь не идет о персоне руководителя как таковой и его человеческих возможностях в данный момент. Речь идет о том что данные о процессе выполнения задач должны накапливаться и быть доступными как мгновенно он-лайн, так и в архиве, должны быть подотчетны вместе с данными результата)

Итак, формулируем принцип обратной связи: Водитель с автомобилем должен предоставлять информацию о выполнении своих задач в реальном времени посредством обратной связи.

Реализация:

активация кнопки "Доставка"

Это не телефон, как можно было бы подумать (и как в множестве компаний происходит*). Это кнопка в кабине водителя. Она более формальна, не отвлекает, обязывает к четким и в то же время элементарным действиям:

В момент начала разгрузки (сразу после остановки автомобиля, перед или во время открытия кузова, выхода экспедитора из кабины) нажимается кнопка, зажигается оранжевая подсветка – «Идет разгрузка». В момент окончания разгрузки (закрытие кузова, возвращение экспедитора в кабину, непосредственно перед началом движения) кнопка отжимается, оранжевая подстветка гаснет – «Разгрузка завершена».

Все эти действия для водителя автоматичны и не требуют никаких мыслительных процессов.

Данная методика опробована и успешно применяется для предприятий транспортного обслуживания с высокими требованиями к оперативному управлению и (или) информированности о составляющих частях общего процесса транспортного обслуживания.

Есть также организационный эффект, выражающийся в повышении ответственности водителя, т.к. информирование о выполняемом задании он осуществляет в явном виде при каждой доставке. Это сильно отличается от традиционных подходов, когда менеджмент узнает о качестве и количестве доставок в конце дня (а по некоторым показателям в конце более длительного периода).

как обратная связь используется в системе? Читайте о Доставках…

*) примечание: несмотря на кажущееся удобство, телефон — враг в хорошо организованом бизнесе. Прежде всего тем, что никоим образом не подотчетен, порождает “эффект спама” , а иногда и трудности понимания особенно в описании места и понятий “скоро”, “вот прямо сейчас”, “еще делаю”, “уже сделал” . Он незаменим в экстренных случаях, но не должен быть инструментом постоянного управления. Кроме того, менеджеры злоупотребляющие телефонным прозвоном водителей часто отвлекают тех от выполнения задач, создают шум в рабочей комнате. Идеальное решение, косвенно свидетельствующее о том что у вас высокоэффективный и управляемый бизнес — почти полное отсутствие неоправданного вмешательства менеджеров в дела водителей по телефону. (ссылка)

При наличии региональных подразделений(офисов, магазинов, складов), у каждого  имеется собственный автопарк. Бывает и  сложнее: определенная группа автомобилей обслуживает определенные регион(ы), магазины или определенные задачи (магистральные перевозки, адресные доставки). Часто (всегда!) необходимо обеспечить единую систему отчетности, единую методику для передачи данных в бухгалтерию для покрытия расходов.

В этом случае одна из архитектурных особенностей нашей системы — единая БД и единая среда функционирования (корпоративный веб-сайт) являет собой явное преимущество. Каждый ответственный сотрудник, работающий с сайтом имеет персональный логин/пароль (учетную запись).

Особенно удобным является ввод нового сотрудника в дело.  Неважно в каком региональном офисе происходят кадровые изменения, администрирование сайта централизовано. В учетной записи уволенного (предыдущего) сотрудника меняется содержимое, а извещение о включении нового отправляется непосредственно по е-мейлу новому сотруднику.

Новый сотрудник переходит по ссылке и вуаля! он в среде, где накоплены все данные об автотранспорте. Это несравнимоудобнее, чем передача бумаг, записок, файлов и т.п.

Безопасность. Все пользователи сайта могу быть распределены по группам. Доступ к элементам сайта может управляться как на уровне групп, так и на уровне индивидуальных учетных записей. Если пользователь является автором, т.е. ведет запись каких либо данных на сайт, то его авторство фиксируется, как и фиксируется время создания записи, время изменения, и каждая версия изменения. Это позволяет наделять все сведения документными свойствами и фиксирует ответственность автора.

Ведется статистика посещения страниц сайта пользователями.

Автомобили, в свою очередь, также распределяются на группы, что влияет на их видимость в страницах сайта. Автомобиль может быть в одной или нескольких группах.

Удобство(юзабилити) Кроме групп, которые и в случае пользователей и в случае автомобилей являют собой сегмент безопасности, существуют и группировки в интерфейсах по любому описательному признаку: тоннаж, территориальная пренадлежность, тип топлива, тип кузова и т.д. Группировки помогают легче воспринимать информацию.

Заказчик  — довольно успешный  завод по переработке молока с собственным автопарком молоковозов собирающих сырье (МС). Такой тип бизнеса уже знаком нам и наше желание автоматизировать задачи оптимального и (или) контролируемого сбора МС весьма велико. Это интересно.

Со стороны Заказчика — уверенный в себе бизнесмен, по видимому успешно наладивший основной бизнес по производству молочных продуктов. Мы рассказываем и показываем реализацию основных принципов (ссылка), показываем сайты. Наиболее близкий из имеющихся у нас примеров — развозка бутилированной воды. Несмотря на то что это развозка, а не сбор, суть та же — адресный контроль процесса доставки, зонирование, контроль посещений.

Заказчик задает очень осмысленные вопросы, иногда дотошные, но все по сути. Это вдохновляет. Видно, что бизнесмен имеет в голове некую модель автоматизации, хотя и не готов пока ее изложить в формализованном виде. Бизнесмен берет таймаут на несколькодней для формализации Своей  Идеи. Ждем…

Результат неожиданный: представитель Заказчика заявил,что при просмотре системы обнаружил в ней (в страницах) слова набранные не с большой буквы, что по его мнению указывает на низкую грамотность и (или) невнимательность Исполнителя. Развивая свою мысль Заказчик обобщил,что раз в таких мелочах Исполнитель невнимателен, то в реализации основной идеи уж точно допустит ошибки. ¹
<- Справа эта картинка. Смешно то,что предполагаемый Заказчик смог сделать столь странный вывод по столь незначительным фактам. Не смешно то,что заказчик, построивший успешный бизнес и, по видимому страдающий перфекционизмом, не смог даже предположить, что показываемый ему интерфейс в некоторой степени выстрадан, и в немалой степени вылизан в результате кропотливого труда. Мало того, этот интерфейс принадлежит конкретному бизнесу, он является продуктом заказной разработки. И поэтому он таков!

Ситуация описывается известной пословицей: “За деревьями леса не увидел”.

Конечно, в любой системе есть ошибки или недоработки, но то что он видел ошибкой не является: названия колонок не только набраны строчными буквами сознательно, но и сами слова в заголовках подобраны таким образом,чтобы использовались понятия с наименьшим количеством букв — все только для того, чтобы как можно более компактно разместить заголовки таблицы. Это элементарное правило юзабилити — не нужно разъяснять то, что интуитивно понятно и на второй день пользования системой уже даже не замечается глазом.

В реальной системе клиента, которая эксплуатируется 2 года(!) ( картинка справа ->) можно убрать заголовки вообще! и пользователи не заметят этого. Для дотошных  картинки² и разъяснения к ним в конце главы.

Тренированный человеческий глаз (ум!) устроен таким образом, что Прописные буквы автоматически цепляют внимание и мозг расшифровывает их не как слова  в предложении, а как новые предложения. Это неосязаемая техника чтения, впитываемая с дошкольного возраста. Обилие Прописных Букв Близко Расположенных Друг К Другу Отвлекает и Утомляет,  Нарушает Привычную Технику Считывания Текстовой Информации. (неприятное предложение, не так ли?

Нам это не нужно. Нам не нужно,чтобы пользователь отвлекался от действительно важных параметров, а они на самом деле представлены цветом и формой.

Есть и совсем простое и эмоциональное объяснение — так было сделано, потому что так было сделано и это понравилось, это легло в концепцию и прижилось

Наш вывод: несмотря на неудачу с получением заказа на разработку, мы, в принципе довольны, т.к. работа конкретно с этим человеком в качестве Заказчика скорее всего стоила бы непомерно больших усилий и привела бы к потере денег, ввиду реализации бесчисленных мелочей, которые мешали бы увидеть (и реализовать) главное.

Да, мы будем использовать маленькие буквы, маленькие цветные квадратики и любые другие решения если они наилучшим образом способствуют юзабилити.

Да, и если вы после наших разъяснений все же настаиваете на собственном видении — мы сделаем и это, ведь вы наш Заказчик,  а смысл нашей работы – заказная разработка. Ключевое слово тут – после наших разъяснений

—————————————————————————————————

¹) Оставим на совести Заказчика само обобщение: он использует дедукцию (метод Шерлока Шолмса! :-), хотя в данном случае в нем не очень много рационального, прежде всего в области понятий: мелочи и главная идея, ибо Заказчик как бы дистанцируется, снимая с себя любое участие в процессе определении этих самых мелочей и главных вещей. Ведь про его Главную Идею мы  и не узнали, ибо она никогда не была записана даже на бумаге, в отличие от нашей системы, воплощенной во плоти.

Хотя по-человечески такая позиция как-то понятна. Такое встречается в жизни… Увы!

²) иллюстрации к теме.

Технически, услуга основана на принципах постоянного опеределения местоположения автомобилей посредством GPS и передачи данных каналами Интернет Заказчику. Вторым важным принципом является регистрация всех происходящих с автотрананспортом событий и накопление данных в Архиве.

все приниципы системы подробно… (ссылка)

Однако, несмотря на общие с множеством других GPS признаки: наличие карты, отрисовка треков движения автомобилей, подсчет пробега — мы делаем основной упор не на просмотр и визуальную оценку, а на аналитическую обработку данных и выявление нарушений.  Вот тут и кроется большая военная тайна

Для того, чтобы аналитическим путем вычислять правду и ложь нужно создать как можно более полную модель бизнеса и найти те показатели, которые отделяют нормальное течение бизнеса от нарушений. Это не так просто как кажется —  прежде всего это требует плотной работы с Заказчиком, кому как ни Заказчику знать что именно в его бизнесе его волнует?

Существуют простые реализации, когда достаточно создать программное решение “по шаблону”, однако существут реализации созданные “под Заказчика” настолько уникально, что они невозможны для шаблонирования.

Зачем тогда этот сайт?

Этот сайт является набором практик и демонстрацией возможностей.

Практики — это то,что Заказчик может примерить на себя, ведь самой доходчивой формой изучения является способ “посмотреть как у соседа”

Возможности — это наш опыт, знания и твердая уверенность в том,что в разработке решений нужно придерживаться принципов построения системы. Это более 6 лет инженерной деятельности в тематике систем GPS мониторинга, 15 лет GIS-анализа, геодезии, картографии — всего того, что связано с отображением пространственных данных и процессов.

Мы не продаем готовый продукт “как есть” (ну, кроме уж очень простых случаев), но создаем исключительные решения для требовательных Заказчиков.
При этом выяснение функциональных требований у Заказчика, их адаптация исходя их возможностей системы, является договорным процессом, осуществляемым в момент действия основного договора.