18 KiB
Sales Positioning: AWatch-rus
Документ для первой встречи с заказчиком.
Цель: объяснить ценность AWatch-rus без погружения в техническую архитектуру.
Короткая формула:
AWatch-rus показывает не только активность сотрудников,
а доверие к данным, бизнес-риск подразделений и проверяемую цепочку разбора.
1. Проблемы заказчика
Непонятно, кто реально работает
Во многих компаниях есть учет рабочего времени, отчеты из 1С, RDP-сессии, табели и оценки руководителей. Но утром директор все равно не видит простую картину:
- какие подразделения работают в нормальном режиме;
- где активность просела;
- кто перегружен;
- где есть простой;
- где проблема в людях, а где в сломанном сборе данных.
Без такой картины управление превращается в набор частных мнений.
KPI недостоверны
Обычный KPI часто считается по неполным или спорным данным. Рабочее место могло не прислать телеметрию. RDP-сессия могла быть определена резервным способом. Агент мог работать в диагностическом режиме. Внешне отчет выглядит красиво, но руководитель не понимает, можно ли ему верить.
Для бизнеса это критично. Нельзя принимать кадровые и организационные решения по метрикам, источник которых сам не проверен.
Нет связи между активностью и рисками
Отдельно существуют отчеты по активности. Отдельно - ИБ-события. Отдельно - инциденты и служебные проверки. В результате руководитель видит фрагменты, но не видит причинно-следственную картину:
- активность подразделения падает;
- часть рабочих мест не присылает данные;
- растет число кандидатов в инциденты;
- появляются открытые дела;
- но все это не связано в один управленческий вывод.
Нет прозрачного расследования
Когда появляется риск, обычно непонятно:
- почему система считает это риском;
- кто должен проверить ситуацию;
- какие признаки это подтверждают;
- кто изменил статус проверки;
- почему кандидат признан инцидентом или ложным срабатыванием;
- какой отчет можно показать руководителю.
Без прозрачной цепочки разбор быстро превращается в спор между ИТ, ИБ, руководителем и сотрудником.
2. Решение AWatch-rus
Workforce Analytics
AWatch-rus показывает управленческую картину по активности:
- индекс активности;
- активное время;
- подразделения и ответственные;
- тренды;
- просадки;
- рабочие приложения и RDP-сценарии;
- проблемные зоны, требующие внимания.
Это не система для наказания за каждую минуту простоя. Это инструмент для понимания загрузки, дисциплины процессов и качества операционного управления.
Trust KPI
AWatch-rus отдельно показывает, можно ли доверять текущему KPI.
Система учитывает:
- источник данных агента;
- наличие ошибок коллектора;
- свежесть телеметрии;
- покрытие рабочих мест;
- диагностические fallback-режимы;
- долю узлов, данные которых приняты в KPI.
Если данные собраны ненадежным способом, система не маскирует это красивой цифрой. Она прямо показывает: KPI требует проверки.
Business Risk
AWatch-rus переводит технические признаки в язык руководителя:
- подразделение стабильно в норме;
- подразделение требует внимания;
- риск высокий;
- риск критический;
- причина: низкий Trust KPI, падение активности, слабое покрытие агентов, устаревшая телеметрия, проблемные рабочие места, открытые проверки.
Главная ценность не в том, что система показывает еще один график. Ценность в том, что она объясняет, почему конкретная зона бизнеса требует внимания.
Investigation Workflow
AWatch-rus не создает инциденты автоматически.
Он формирует кандидатов для проверки и дает понятный ручной workflow:
риск -> кандидат -> проверка -> audit trail -> investigation pack -> дело
В этом контуре видно:
- почему кандидат попал в очередь;
- какие признаки есть;
- кто проверял;
- какой статус поставлен;
- какой комментарий оставлен;
- какой пакет расследования можно выгрузить.
Это важно для ИБ и руководителя: решение принимает человек, а система дает материал и прозрачную историю.
3. Для кого продукт
Банки и финансовые организации
Подходит там, где важны контроль рабочих мест, RDP, операционная дисциплина, качество KPI и разбор спорных событий без немедленного перехода к тяжелой DLP или SIEM-программе.
Холдинги
Полезен для распределенной структуры: несколько подразделений, разные ответственные, разные рабочие роли, необходимость сравнивать зоны бизнеса в одном формате.
Торговые сети
Подходит для контроля операторов, офисных сотрудников, логистики, back-office и подразделений, где важны рабочие приложения, смены, простои и понятная управленческая сводка.
Логистика
Полезен там, где работа распределена между операторами, диспетчерами, складскими и офисными ролями, а простои или падение активности быстро влияют на сроки обработки.
Государственные организации
Подходит для технического аудита рабочих мест, контроля регламентов, управленческой отчетности и внутреннего разбора событий при аккуратном позиционировании: не как сертифицированная СЗИ, а как платформа операционного контроля и аналитики.
4. Чем отличается
От Стахановца
Классические системы контроля сотрудников часто воспринимаются как инструмент наблюдения за человеком. AWatch-rus делает акцент на другом:
- не только активность, но и доверие к данным;
- не только сотрудник, но и подразделение;
- не только “кто работал”, но и “можно ли верить KPI”;
- не только событие, но и связанная картина риска;
- не автоматическое обвинение, а очередь проверок.
От StaffCop
StaffCop-подобные решения сильны в детальном контроле действий пользователя. AWatch-rus продается как управленческий слой поверх активности и рисков:
- руководителю не нужно начинать с технических логов;
- риск объясняется через причины;
- качество данных показывается отдельно;
- инцидентная часть строится через ручную проверку и audit trail.
От Kickidler
Kickidler ассоциируется с визуальным наблюдением и контролем экранной активности. AWatch-rus не строит ценность вокруг постоянного просмотра экранов.
Главный фокус:
- агрегированная активность;
- Trust KPI;
- подразделения;
- риски;
- расследовательский пакет;
- управленческий отчет.
Если evidence включается в пилоте, это отдельный согласованный сценарий, а не базовая идея продукта.
От DLP
DLP отвечает на вопрос: “Есть ли утечка или нарушение политики данных?”
AWatch-rus отвечает на другой вопрос: “Что происходит в организации, где падает активность, можно ли доверять данным и какие ситуации нужно проверить?”
В AWatch-rus есть DLP-lite/ИБ-сигналы, но продукт не заявляется как enterprise DLP и не заменяет сертифицированные DLP-комплексы.
От SIEM
SIEM собирает и коррелирует события ИТ- и ИБ-инфраструктуры.
AWatch-rus ближе к рабочему месту, подразделению и управленческой картине:
- активность сотрудников;
- качество данных агентов;
- покрытие рабочих мест;
- бизнес-риск подразделений;
- кандидаты в проверки;
- понятный отчет для руководителя.
AWatch-rus может быть источником или соседним контуром для SIEM, но не должен позиционироваться как замена промышленной SIEM.
5. Сценарий пилота
Рекомендуемый пилот:
- срок: 2 недели;
- масштаб: 10-50 рабочих мест;
- охват: 1-3 подразделения;
- доступ: закрытый портал через VPN или auth gateway;
- роли: директор/владелец, ИТ, ИБ, руководитель пилотного подразделения;
- режим: наблюдение, аналитика, ручная проверка кандидатов;
- без автоматических блокировок и сетевого enforcement по умолчанию.
Типовой ход пилота:
- Согласовать подразделения, роли, список рабочих мест и данные, которые можно использовать.
- Развернуть серверный контур и портал.
- Установить агенты на выбранные рабочие места.
- Проверить Trust KPI и покрытие агентов.
- Накопить несколько рабочих дней телеметрии.
- Показать руководителю сводку: активность, просадки, риски, причины.
- Провести один согласованный сценарий проверки кандидата в инциденты.
- Выгрузить управленческий отчет и investigation pack.
- Зафиксировать результат пилота и список доработок.
Что заказчик должен увидеть в конце пилота:
- где активность стабильна;
- где есть просадка;
- каким данным можно доверять;
- какие рабочие места портят KPI;
- какие риски требуют проверки;
- как выглядит прозрачная цепочка разбора.
6. Критерии успеха пилота
Пилот успешен, если:
| Критерий | Что считается хорошим результатом |
|---|---|
| Руководитель понимает главный вывод | Портал за 1-2 минуты отвечает, где норма, где риск и почему. |
| KPI не выглядит “черным ящиком” | Видно, какие данные приняты в KPI, а какие нет. |
| Покрытие рабочих мест понятно | Есть список ожидаемых узлов, свежих узлов, stale/missing nodes. |
| Риски объяснимы | По каждому проблемному подразделению есть причины и рекомендация. |
| ИБ получает очередь проверки | Есть кандидаты в инциденты без автоматического создания инцидента. |
| Решения проверяемы | Есть audit trail: кто изменил статус, когда и почему. |
| Отчет пригоден для обсуждения | Есть Markdown/PDF/JSON-отчет для руководителя и ИТ/ИБ. |
| Ограничения приняты | Заказчик понимает, что это proxy-аналитика, а не сертифицированная СЗИ. |
Минимальный целевой результат: заказчик видит управленческую ценность даже без масштабного внедрения и может принять решение о расширении пилота.
7. Ограничения продукта
AWatch-rus в текущем позиционировании:
- не является сертифицированной СЗИ;
- не заменяет enterprise DLP;
- не заменяет SIEM;
- не является EDR/XDR;
- не принимает дисциплинарные решения автоматически;
- не создает инциденты автоматически;
- не должен использоваться без локальных регламентов уведомления сотрудников;
- не должен публиковаться наружу без VPN, reverse proxy или auth gateway.
Что важно проговорить на первой встрече:
- индекс активности - это управленческая proxy-метрика;
- качество данных важно не меньше самой активности;
- DLP-lite/ИБ-сигналы требуют ручной проверки;
- evidence включается только по согласованному сценарию;
- сетевой enforcement и блокировки не входят в базовый пилот.
8. Как говорить о продукте коротко
Для директора:
AWatch-rus показывает, какие подразделения работают стабильно, где есть просадка и можно ли доверять этим данным. Это не просто контроль сотрудников, а управленческая картина риска.
Для ИБ:
AWatch-rus дает очередь ситуаций для проверки, evidence-признаки и audit trail решений. Он не заменяет DLP/SIEM, но закрывает важный слой между активностью рабочих мест и внутренним разбором событий.
Для ИТ:
AWatch-rus показывает покрытие агентов, свежесть телеметрии и узлы, из-за которых управленческий KPI становится недостоверным.