335 lines
18 KiB
Markdown
335 lines
18 KiB
Markdown
# Sales Positioning: AWatch-rus
|
||
|
||
Документ для первой встречи с заказчиком.
|
||
|
||
Цель: объяснить ценность AWatch-rus без погружения в техническую
|
||
архитектуру.
|
||
|
||
Короткая формула:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
риск -> кандидат -> проверка -> 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 по умолчанию.
|
||
|
||
Типовой ход пилота:
|
||
|
||
1. Согласовать подразделения, роли, список рабочих мест и данные, которые можно
|
||
использовать.
|
||
2. Развернуть серверный контур и портал.
|
||
3. Установить агенты на выбранные рабочие места.
|
||
4. Проверить Trust KPI и покрытие агентов.
|
||
5. Накопить несколько рабочих дней телеметрии.
|
||
6. Показать руководителю сводку: активность, просадки, риски, причины.
|
||
7. Провести один согласованный сценарий проверки кандидата в инциденты.
|
||
8. Выгрузить управленческий отчет и investigation pack.
|
||
9. Зафиксировать результат пилота и список доработок.
|
||
|
||
Что заказчик должен увидеть в конце пилота:
|
||
|
||
- где активность стабильна;
|
||
- где есть просадка;
|
||
- каким данным можно доверять;
|
||
- какие рабочие места портят 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 становится недостоверным.
|
||
|
||
## Связанные документы
|
||
|
||
- [Customer Pilot Pack](CUSTOMER_PILOT_PACK_RU.md)
|
||
- [Описание продукта](../PRODUCT_DESCRIPTION_RU.md)
|
||
- [Аудит готовности к пилоту](PILOT_READINESS_AUDIT_RU.md)
|
||
- [Портал AWatch-rus](PORTAL_RU.md)
|
||
- [Business Risk](BUSINESS_RISK_RU.md)
|
||
- [Модель безопасности](SECURITY_MODEL_RU.md)
|