Бизнес-модель
Если Вы задумались над открытием своего бизнеса, либо развитием существующего, предлагаем составить свой бизнес-план, который поможет понять размер необходимых инвестиций и уровень доходности бизнеса на рынке спутникового мониторинга автотранспорта.
План продаж
1. Определите количество автомобилей, которые вы будете ежемесячно подключать к своей системе мониторинга: шт.
2. Вместе с GPS/ГЛОНАСС оборудованием клиенты покупают датчики, которые позволяют контролировать расход топлива и другие показатели работы транспорта. Введите процент клиентов, которые вместе с системой мониторинга будут покупать датчики: %
3. Заложите ежемесячный рост объема продаж GPS/ГЛОНАСС оборудования: %
Затраты
1. Определите закупочную стоимость GPS/ГЛОНАСС оборудования, которое вы будете устанавливать на автомобили ваших клиентов: руб.
2. Определите закупочную стоимость датчиков, которые вы будете продавать: руб.
3. Для установки оборудования требуются специалисты, которые могут быть как в штате, так и на подряде.
Зарплата специалиста по установке:
4. Вместе с оборудованием клиентам необходимо предоставить доступ в систему мониторинга транспорта — Wialon Hosting в серверном центре Wialon. Средняя стоимость – 150 руб. за 1 единицу транспорта.
5. Для соединения оборудования с сервером используется GPRS канал одного из операторов сотовой связи. На клиентском оборудовании устанавливается SIM-карта и оплачивается GPRS-трафик. Абонентская плата за GPRS-трафик: руб.
6. Постоянные расходы в месяц (аренда офиса, связь и др.): руб.
Выручка
1. Определите доходность от продажи оборудования: %.
2. Определите доходность от продажи датчиков: %.
3. Определите доход от установки оборудования: руб.
4. Определите размер ежемесячной абонентской платы за мониторинг 1 единицы транспорта: руб.
Расчет прибыли
Исходя из заданных вами параметров, ниже будет приведен расчёт прибыли бизнеса по спутниковому мониторингу транспорта на первые 12 месяцев после нажатия кнопки Рассчитать.
Источник
Бизнес-план компании по мониторингу подземного кабеля
Бизнес-план компании по мониторингу подземного кабеля
Авторы данного бизнес-плана разработали инновационную систему мониторинга подземного кабеля, электрических проводов и резервуаров для хранения.
Они планируют получить финансирование для вывода своего продукта на потребительский рынок и увеличения объемов продаж.
К настоящему моменту компания уже получила примерно $6 млн. на проведение исследований и развитие, на разработку продукции для телекоммуникационного рынка, а также на первоначальные продажи.
Для дальнейшего развития предприятия требуется дополнительные $5 млн. Эти средства пойдут на обеспечение оборотных средств, расширение продаж и реализацию маркетинговых программ в течение последующих двух лет.
$500 тыс. планируется потратить на разработку новых телекоммуникационных продуктов и не только. Так, уже сейчас получены патенты на производство систем выявления утечек опасных веществ на производственных комплексах и систем обнаружения дефектов и утечек в водопроводных и газовых трубах в частных домовладениях.
Согласно прогнозам, приведенным в бизнес-плане, ежегодный объем продаж составит к пятому году существования компании $34 млн., а чистая прибыль – $10, 8 млн.
Системы проверки оптоволоконных и медных кабелей, которые будет производить предприятие, работают по принципу раннего оповещения и позволяют обнаружить повреждения на первоначальном этапе, до того, как они приобретут критический характер. Это поможет телефонным компаниям сэкономить до $1 млн. Именно такие потери приносят повреждения на линии и их ремонт.
Такая система также способна значительно увеличить срок эксплуатации телефонной кабельной сети вне станции.
Руководство компании уверено, что на рынке не существует подобных систем, способных тестировать и определять место повреждения оптоволоконного кабеля с максимальной точностью.
Большинство технологий и продукции, предлагаемых конкурентами, являются скорее дополняющими, а не заменяющими системы мониторинга.
Таким образом, у компании есть все шансы стать высокорентабельным предприятием с минимальными потребностями в крупных капиталовложениях.
Источник
Торговля под присмотром: пример системы бизнес-мониторинга
Инструментов мониторинга ИТ-инфраструктуры существует много десятков, если не сотни. Есть бесспорные народные любимцы вроде Zabbix, с помощью которых можно сваять мониторинг для компании средней руки, и легион утилит, сервисов и мощных пакетов на любой вкус и размер.
А вот с бизнес-мониторингом всё сложнее. На рынке не сказать чтобы много готовых продуктов, на основе которых можно быстренько собрать дашборд, чтобы высокое начальство могло отслеживать уровень продаж и расторопность доставки. Обычно бизнес-мониторинг представляет собой узкоспециализированный проект, который делается для данной конкретной компании, с учётом особенностей её информационных систем. О подобном проекте — наш рассказ.
Одному нашему клиенту понадобилась система бизнес-мониторинга, которая в удобном виде сводит и наглядно показывает текущие показатели бизнеса. Например, как идут продажи, выросли они или упали по сравнению с тем же временем предыдущего периода, в каких филиалах торговля идёт бойчее, как работают разные сервисы, как оформляются кредиты на покупки, объём оплат через онлайн-каналы, распределение по видам доставки и так далее.
В то время мы как раз пробовали разные APM-решения (application performance monitoring). И среди них нам понравилась Instana. Довольно свежий продукт, вероятно, поэтому дешевле конкурентов. К тому же и технологии в Instana использованы свежие — Cassandra, Kafka, Elastic Search. Система способна прослеживать всё насквозь от самого железа до конечного сервиса и конечного пользователя. Также в Instana два уровня отображения данных мониторинга. Первый уровень — инфраструктура, состояние железа и ПО: операционные системы, приложения, контейнеры и прочее. Второй уровень — бизнес-логика: сервисы в приложении, их взаимодействие друг с другом. Например, можно отслеживать работу сервиса корзины в интернет-магазине. При этом сервис может состоять из группы микросервисов: один подсчитывает общую стоимость, второй подтягивает промо-акции, третий вычисляет стоимость доставки.
Для администрирования Instana очень удобна: есть различные виды поиска, гранулярность данных (в отличие от конкурентов) – всего 1 секунда. У конкурентов обычно усредняются данные за минуту, при этом нагрузка вырастает до 30%, и чем меньше гранулярность, тем выше нагрузка. У Instana же данные собираются каждую секунду и нагрузка на приложение минимальна — до 5%. Благодаря этому можно отслеживать самые короткие перебои, ошибки, рост нагрузки и прочее.
Ещё одно из преимуществ продукта — корреляция событий. Допустим, на сервере возникла проблема, которая потянула за собой прикладное приложение и соответствующий сервис – в итоге конечные пользователи столкнулись со сбоями и ошибками на сайте. Instana коррелирует все события, по которым срабатывают триггеры, и выдает инженеру один инцидент, в котором описывается вся причинно-следственная цепочка. Это помогает сразу найти источник бед.
В общем, нам Instana понравилась и мы пришли с ней к заказчику. Там на неё посмотрели и сказали, что всё очень красиво. Для админа. А им нужен более простой и наглядный инструмент – для бизнес-пользователей. Чтобы те могли в режиме реального времени видеть причины падения тех или иных бизнес-показателей.
Начали думать, как реализовать все требования по бизнес-мониторингу и простоту отображения. Радовало, что в Instana есть удобные API для получения всех нужных метрик из имевшихся у заказчика систем.
Перепробовали кучу алгоритмов и подходов. Готовое решение написали на Ruby on Rails, использовали Redis, связку Elastic Search и данных из БД. Туда зашили логику на основе машинного обучения для всяческих триггеров. То есть система сама учится, по каким пороговым значениям нужно включать «красные лампочки»: проводит технический анализ всех данных, по которым нужны триггеры, сравнивает разные факторы и автоматически выставляет пороги. Допустим, днем идёт по 100 заказов в пять минут, а ночью – по 10. В Zabbix пороговые значения прописываются вручную. Но бизнес растёт, изменяется, и приходится постоянно корректировать пороговые значения по многим показателям. Instana благодаря машинному обучению способна понять, что днем заказов явно больше, чем ночью, и самостоятельно рассчитать адекватные пороговые значения.
Это что касается бизнес-метрик. Если брать метрики технические, то система мониторинга должна знать, как себя ведёт каждая технология, как использует ресурсы, насколько резкими могут быть изменения. Если поведение не соответствует заложенному шаблону, загорается «красная лампочка». При этом «шаблон» — это сложный алгоритм, а не просто какие-то пороговые значения.
Instana собирает метрики из различных систем заказчика и передаёт в наш дашборд, где всё это наглядно и просто визуализируется.
На главной странице можно посмотреть количество заказов, выручку, количество клиентов. Всё это коррелируется с ценами и складскими остатками. Также можно посмотреть доступность сайта и количество ошибок в различных сервисах.
Здесь можно увидеть среднее количество заказов за каждый час, а цвет ячейки отражает разницу между текущим и средним значением за тот же час в тот же день недели в течение месяца. Если сегодня заказов больше, чем среднее значение за предыдущий период, ячейка зелёная, если меньше — красная. Справа графики по типу оплаты и доставки оформленных заказов, а также ошибки на основных сервисах, отвечающие за оформление. Можно применить фильтр и выбрать самые проблемные периоды, чтобы потом искать причины.
Если кликнуть мышью на график, то мы «проваливаемся» в него и видим конкретные трейсы с ошибками за этот период. Выводятся подробные данные: где происходили ошибки, какие именно, вплоть до декомпиляции кода: на каком методе и в каком классе.
В дашборде можно отслеживать успешность выполнения основных заданий по обработке данных, и если они еще выполняются, то через сколько завершатся. Например, нужно обновить цены и ассортимент на сайте. Информация о товарах и ценах в течение дня выгружается из нескольких систем, а ночью обрабатывается. 43 задания выполняются в течение 6 часов: на одни уходят минуты, на другие – часы. И бизнес-пользователям нужно понимать, какие задания выполнились, какие упали, когда закончились.
Мы реализовали интересную функцию: в дашборе можно увидеть, кто из пользователей ушёл из интернет-магазина, ничего не купив из-за ошибок на самом сайте или в связанном с ним ПО. Причём показывается, какая именно ошибка сорвала каждую из сделок. Между прочим, задача вовсе не праздная, учитывая количество посещений и объём продаж через интернет-магазин.
Выводится вся информация по каждому ушедшему клиенту: контактная информация, оформленные заказы и те, которые не удалось оформить. Сотрудники колл-центра могут позвонить, отправить SMS или письмо, вроде такого: «Мы видим, что вы хотели купить у нас смартфон, но столкнулись с затруднением. Инженеры уже разбираются с этим. Вот вам промокод, возвращайтесь завтра и купите смартфон со скидкой».
На другой вкладке можно посмотреть ситуацию в филиалах: объёмы продаж, количество заказов, остатки на складах, статус обработки новых цен и так далее. Всё это в тесной связке с Instana.
Наша система может коррелировать самые разные бизнес-метрики с техническими метриками, собирая данные из различных систем — той же Instana (но не обязательно, на её месте может быть и другая система мониторинга), из всевозможных баз данных, из хранилища логов.
Заказчик нашу систему пока тестирует. Что касается дальнейших перспектив решения – его, конечно, нужно адаптировать под задачи того или иного конкретного бизнеса. Но после некоторого количества уже собранных на этой ниве граблей, сделать такое будет куда быстрее и проще. А сфер применения бизнес-мониторинга масса – по сути это любой бизнес, где есть необходимость отслеживать в реальном времени работу бизнес-приложений и связанных с ними бизнес-метрик.
Сервисный центр компании «Инфосистемы Джет». Группа поддержки CRM и web-приложений.
Источник
Как наладить бизнес-мониторинг продукта
Сегодня расскажем, как можно обеспечить эффективный мониторинг для сложного ИТ-продукта и какие процессы можно автоматизировать, чтобы упростить работу саппорт-инженеров.
Именно с мониторинга стоит начинать постановку продукта на техподдержку. И уже на этом фундаменте выстраивать технологию обработки обращений (Incident Management) и развивать системный подход к решению проблем (Problem Management).
Мониторинг даёт возможность выстраивать проактивный подход в техподдержке. Специалисты узнают о проблемах не когда сбой уже произошёл, а реагируя на первые тревожные сигналы.
В общем и целом мониторинг отвечает на два главных вопроса:
Жива ли вообще система?
Могут ли пользователи выполнять нужные им операции?
Далее расскажем, как организовать мониторинг, который даст вам эти ответы.
Какой бывает мониторинг
Технический – проверяет состояние программно-аппаратных компонентов.
Этот мониторинг отвечает на вопросы: как работает каждый отдельный компонент системы? Все ли сервисы пингуются? Не теряются ли запросы к модулям? Всё ли в порядке с сетевой инфраструктурой?
Бизнесовый – проверяет состояние ключевых фич и их влияние на бизнес-показатели.
Здесь применяются пользовательские сценарии, чтобы проверить, как система справляется со своими верхнеуровневыми функциями.
Как правило, с техническим мониторингом у команд проблем не возникает. Трудности зачастую вызывает настройка бизнес-мониторинга – нашему подходу к решению этой задачи и посвящен этот выпуск.
Четыре шага к запуску бизнес-мониторинга
1. Встаем на место пользователя
На первом шаге вы описываете все действия, которые пользователи выполняют в продукте. Расписываете по шагам, что нужно сделать в интерфейсе, чтобы получить тот или иной результат.
Удобно это делать в таблице. На этом этапе в ней появляются колонки:
тип ситуации (штатная/нештатная)
На выходе вы получаете подробное руководство по всем операциям, для которых в принципе используется продукт. По этим данным далее можно готовить тесты, чтобы автоматически проверять, выполняет ли система свои задачи с точки зрения непосредственных пользователей.
2. Переводим с человеческого на машинный
Чтобы автоматизировать эти проверки, это руководство нужно перевести на язык скриптов. Действия пользователя нужно соотнести с конкретными запросами в конкретные сервисы.
Чтобы понять, на что смотреть в выдаче, в таблице добавляем данные:
на что смотрим в ответе.
По результатам этой работы ваша таблица превращается из описания сценариев в полное руководство со всеми запросами, данными в логах, которые говорят о положительном или негативном результате (работает – не работает).
3. Налаживаем авторизацию (опционально)
Большинство корпоративных систем закрыты от внешнего интернета, и для таких случаев нужно решить вопрос авторизации. То есть технически обеспечить возможность системам мониторинга отправить запрос в микросервис и получить данные.
Для этого пишется отдельный модуль, который умеет получать авторизационные данные и передавать их службе мониторинга. Технически это похоже на кукисы в браузере – система, которую мы отслеживаем, передаёт авторизационному сервису токен с ограниченным периодом жизни, а средства мониторинга по этому токену подтверждают право доступа.
4. Автоматизируем и запускаем в работу
Теперь можно начинать автоматизацию и готовить алёрты для процессов. Разработчики пишут скрипты, чтобы имитировать пользовательские действия по списку сценариев. Здесь нужно опираться на бизнес-задачи, смотреть, к какому времени поддержка должна узнать о сбое процесса, чтобы успеть предпринять действия.
Эти скрипты можно «скормить» практически любой системе мониторинга. Лично нам нравится Zabbix, но это может быть Grafana или другой аналитический движок, с которым вы работаете. В вашей таблице есть всё что нужно для настройки.
В результате у нас появляется механизм, который умеет авторизоваться в системе и отправить post-запросы её службам. Остаётся обозначить пороговые значения алёртов и настроить логику отчётов. И ваш мониторинг запущен в эксплуатацию.
Заключение
Наш опыт показывает, что зачастую продуктовая команда сама усложняет себе задачу, слишком погружаясь в технологические параметры. На самом деле процесс прост и прозрачен. Мы показали это на живом примере.
Ключ к решению – это побывать в шкуре пользователя, который каждое утро заходит в систему и проверяет, справляется ли она с его задачами. Если идти к технике через смысл продукта, путь к цели становится гораздо короче, а результаты мониторинга оказывается проще трактовать и контролировать.
В следующем посте поделимся инструментами, которые помогают нашей поддержке работать с мониторингом без лишних манипуляций с кодом.
Источник