docs: add sales positioning
This commit is contained in:
igor04091968
@@ -0,0 +1,334 @@
|
|||||||
|
# Sales Positioning: AWatch-rus / DetMir
|
||||||
|
|
||||||
|
Документ для первой встречи с заказчиком.
|
||||||
|
|
||||||
|
Цель: объяснить ценность AWatch-rus / DetMir без погружения в техническую
|
||||||
|
архитектуру.
|
||||||
|
|
||||||
|
Короткая формула:
|
||||||
|
|
||||||
|
```text
|
||||||
|
AWatch-rus / DetMir показывает не только активность сотрудников,
|
||||||
|
а доверие к данным, бизнес-риск подразделений и проверяемую цепочку разбора.
|
||||||
|
```
|
||||||
|
|
||||||
|
## 1. Проблемы заказчика
|
||||||
|
|
||||||
|
### Непонятно, кто реально работает
|
||||||
|
|
||||||
|
Во многих компаниях есть учет рабочего времени, отчеты из 1С, RDP-сессии,
|
||||||
|
табели и оценки руководителей. Но утром директор все равно не видит простую
|
||||||
|
картину:
|
||||||
|
|
||||||
|
- какие подразделения работают в нормальном режиме;
|
||||||
|
- где активность просела;
|
||||||
|
- кто перегружен;
|
||||||
|
- где есть простой;
|
||||||
|
- где проблема в людях, а где в сломанном сборе данных.
|
||||||
|
|
||||||
|
Без такой картины управление превращается в набор частных мнений.
|
||||||
|
|
||||||
|
### KPI недостоверны
|
||||||
|
|
||||||
|
Обычный KPI часто считается по неполным или спорным данным. Рабочее место могло
|
||||||
|
не прислать телеметрию. RDP-сессия могла быть определена резервным способом.
|
||||||
|
Агент мог работать в диагностическом режиме. Внешне отчет выглядит красиво, но
|
||||||
|
руководитель не понимает, можно ли ему верить.
|
||||||
|
|
||||||
|
Для бизнеса это критично. Нельзя принимать кадровые и организационные решения
|
||||||
|
по метрикам, источник которых сам не проверен.
|
||||||
|
|
||||||
|
### Нет связи между активностью и рисками
|
||||||
|
|
||||||
|
Отдельно существуют отчеты по активности. Отдельно - ИБ-события. Отдельно -
|
||||||
|
инциденты и служебные проверки. В результате руководитель видит фрагменты, но
|
||||||
|
не видит причинно-следственную картину:
|
||||||
|
|
||||||
|
- активность подразделения падает;
|
||||||
|
- часть рабочих мест не присылает данные;
|
||||||
|
- растет число кандидатов в инциденты;
|
||||||
|
- появляются открытые дела;
|
||||||
|
- но все это не связано в один управленческий вывод.
|
||||||
|
|
||||||
|
### Нет прозрачного расследования
|
||||||
|
|
||||||
|
Когда появляется риск, обычно непонятно:
|
||||||
|
|
||||||
|
- почему система считает это риском;
|
||||||
|
- кто должен проверить ситуацию;
|
||||||
|
- какие признаки это подтверждают;
|
||||||
|
- кто изменил статус проверки;
|
||||||
|
- почему кандидат признан инцидентом или ложным срабатыванием;
|
||||||
|
- какой отчет можно показать руководителю.
|
||||||
|
|
||||||
|
Без прозрачной цепочки разбор быстро превращается в спор между ИТ, ИБ,
|
||||||
|
руководителем и сотрудником.
|
||||||
|
|
||||||
|
## 2. Решение AWatch-rus / DetMir
|
||||||
|
|
||||||
|
### Workforce Analytics
|
||||||
|
|
||||||
|
AWatch-rus / DetMir показывает управленческую картину по активности:
|
||||||
|
|
||||||
|
- индекс активности;
|
||||||
|
- активное время;
|
||||||
|
- подразделения и ответственные;
|
||||||
|
- тренды;
|
||||||
|
- просадки;
|
||||||
|
- рабочие приложения и RDP-сценарии;
|
||||||
|
- проблемные зоны, требующие внимания.
|
||||||
|
|
||||||
|
Это не система для наказания за каждую минуту простоя. Это инструмент для
|
||||||
|
понимания загрузки, дисциплины процессов и качества операционного управления.
|
||||||
|
|
||||||
|
### Trust KPI
|
||||||
|
|
||||||
|
DetMir отдельно показывает, можно ли доверять текущему KPI.
|
||||||
|
|
||||||
|
Система учитывает:
|
||||||
|
|
||||||
|
- источник данных агента;
|
||||||
|
- наличие ошибок коллектора;
|
||||||
|
- свежесть телеметрии;
|
||||||
|
- покрытие рабочих мест;
|
||||||
|
- диагностические fallback-режимы;
|
||||||
|
- долю узлов, данные которых приняты в KPI.
|
||||||
|
|
||||||
|
Если данные собраны ненадежным способом, система не маскирует это красивой
|
||||||
|
цифрой. Она прямо показывает: KPI требует проверки.
|
||||||
|
|
||||||
|
### Business Risk
|
||||||
|
|
||||||
|
DetMir переводит технические признаки в язык руководителя:
|
||||||
|
|
||||||
|
- подразделение стабильно в норме;
|
||||||
|
- подразделение требует внимания;
|
||||||
|
- риск высокий;
|
||||||
|
- риск критический;
|
||||||
|
- причина: низкий Trust KPI, падение активности, слабое покрытие агентов,
|
||||||
|
устаревшая телеметрия, проблемные рабочие места, открытые проверки.
|
||||||
|
|
||||||
|
Главная ценность не в том, что система показывает еще один график. Ценность в
|
||||||
|
том, что она объясняет, почему конкретная зона бизнеса требует внимания.
|
||||||
|
|
||||||
|
### Investigation Workflow
|
||||||
|
|
||||||
|
DetMir не создает инциденты автоматически.
|
||||||
|
|
||||||
|
Он формирует кандидатов для проверки и дает понятный ручной workflow:
|
||||||
|
|
||||||
|
```text
|
||||||
|
риск -> кандидат -> проверка -> audit trail -> investigation pack -> дело
|
||||||
|
```
|
||||||
|
|
||||||
|
В этом контуре видно:
|
||||||
|
|
||||||
|
- почему кандидат попал в очередь;
|
||||||
|
- какие признаки есть;
|
||||||
|
- кто проверял;
|
||||||
|
- какой статус поставлен;
|
||||||
|
- какой комментарий оставлен;
|
||||||
|
- какой пакет расследования можно выгрузить.
|
||||||
|
|
||||||
|
Это важно для ИБ и руководителя: решение принимает человек, а система дает
|
||||||
|
материал и прозрачную историю.
|
||||||
|
|
||||||
|
## 3. Для кого продукт
|
||||||
|
|
||||||
|
### Банки и финансовые организации
|
||||||
|
|
||||||
|
Подходит там, где важны контроль рабочих мест, RDP, операционная дисциплина,
|
||||||
|
качество KPI и разбор спорных событий без немедленного перехода к тяжелой DLP
|
||||||
|
или SIEM-программе.
|
||||||
|
|
||||||
|
### Холдинги
|
||||||
|
|
||||||
|
Полезен для распределенной структуры: несколько подразделений, разные
|
||||||
|
ответственные, разные рабочие роли, необходимость сравнивать зоны бизнеса в
|
||||||
|
одном формате.
|
||||||
|
|
||||||
|
### Торговые сети
|
||||||
|
|
||||||
|
Подходит для контроля операторов, офисных сотрудников, логистики, back-office и
|
||||||
|
подразделений, где важны рабочие приложения, смены, простои и понятная
|
||||||
|
управленческая сводка.
|
||||||
|
|
||||||
|
### Логистика
|
||||||
|
|
||||||
|
Полезен там, где работа распределена между операторами, диспетчерами,
|
||||||
|
складскими и офисными ролями, а простои или падение активности быстро влияют на
|
||||||
|
сроки обработки.
|
||||||
|
|
||||||
|
### Государственные организации
|
||||||
|
|
||||||
|
Подходит для технического аудита рабочих мест, контроля регламентов,
|
||||||
|
управленческой отчетности и внутреннего разбора событий при аккуратном
|
||||||
|
позиционировании: не как сертифицированная СЗИ, а как платформа операционного
|
||||||
|
контроля и аналитики.
|
||||||
|
|
||||||
|
## 4. Чем отличается
|
||||||
|
|
||||||
|
### От Стахановца
|
||||||
|
|
||||||
|
Классические системы контроля сотрудников часто воспринимаются как инструмент
|
||||||
|
наблюдения за человеком. AWatch-rus / DetMir делает акцент на другом:
|
||||||
|
|
||||||
|
- не только активность, но и доверие к данным;
|
||||||
|
- не только сотрудник, но и подразделение;
|
||||||
|
- не только “кто работал”, но и “можно ли верить KPI”;
|
||||||
|
- не только событие, но и связанная картина риска;
|
||||||
|
- не автоматическое обвинение, а очередь проверок.
|
||||||
|
|
||||||
|
### От StaffCop
|
||||||
|
|
||||||
|
StaffCop-подобные решения сильны в детальном контроле действий пользователя.
|
||||||
|
DetMir продается как управленческий слой поверх активности и рисков:
|
||||||
|
|
||||||
|
- руководителю не нужно начинать с технических логов;
|
||||||
|
- риск объясняется через причины;
|
||||||
|
- качество данных показывается отдельно;
|
||||||
|
- инцидентная часть строится через ручную проверку и audit trail.
|
||||||
|
|
||||||
|
### От Kickidler
|
||||||
|
|
||||||
|
Kickidler ассоциируется с визуальным наблюдением и контролем экранной
|
||||||
|
активности. DetMir не строит ценность вокруг постоянного просмотра экранов.
|
||||||
|
|
||||||
|
Главный фокус:
|
||||||
|
|
||||||
|
- агрегированная активность;
|
||||||
|
- Trust KPI;
|
||||||
|
- подразделения;
|
||||||
|
- риски;
|
||||||
|
- расследовательский пакет;
|
||||||
|
- управленческий отчет.
|
||||||
|
|
||||||
|
Если evidence включается в пилоте, это отдельный согласованный сценарий, а не
|
||||||
|
базовая идея продукта.
|
||||||
|
|
||||||
|
### От DLP
|
||||||
|
|
||||||
|
DLP отвечает на вопрос: “Есть ли утечка или нарушение политики данных?”
|
||||||
|
|
||||||
|
DetMir отвечает на другой вопрос: “Что происходит в организации, где падает
|
||||||
|
активность, можно ли доверять данным и какие ситуации нужно проверить?”
|
||||||
|
|
||||||
|
В DetMir есть DLP-lite/ИБ-сигналы, но продукт не заявляется как enterprise DLP
|
||||||
|
и не заменяет сертифицированные DLP-комплексы.
|
||||||
|
|
||||||
|
### От SIEM
|
||||||
|
|
||||||
|
SIEM собирает и коррелирует события ИТ- и ИБ-инфраструктуры.
|
||||||
|
|
||||||
|
DetMir ближе к рабочему месту, подразделению и управленческой картине:
|
||||||
|
|
||||||
|
- активность сотрудников;
|
||||||
|
- качество данных агентов;
|
||||||
|
- покрытие рабочих мест;
|
||||||
|
- бизнес-риск подразделений;
|
||||||
|
- кандидаты в проверки;
|
||||||
|
- понятный отчет для руководителя.
|
||||||
|
|
||||||
|
DetMir может быть источником или соседним контуром для 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 / DetMir в текущем позиционировании:
|
||||||
|
|
||||||
|
- не является сертифицированной СЗИ;
|
||||||
|
- не заменяет enterprise DLP;
|
||||||
|
- не заменяет SIEM;
|
||||||
|
- не является EDR/XDR;
|
||||||
|
- не принимает дисциплинарные решения автоматически;
|
||||||
|
- не создает инциденты автоматически;
|
||||||
|
- не должен использоваться без локальных регламентов уведомления сотрудников;
|
||||||
|
- не должен публиковаться наружу без VPN, reverse proxy или auth gateway.
|
||||||
|
|
||||||
|
Что важно проговорить на первой встрече:
|
||||||
|
|
||||||
|
- индекс активности - это управленческая proxy-метрика;
|
||||||
|
- качество данных важно не меньше самой активности;
|
||||||
|
- DLP-lite/ИБ-сигналы требуют ручной проверки;
|
||||||
|
- evidence включается только по согласованному сценарию;
|
||||||
|
- сетевой enforcement и блокировки не входят в базовый пилот.
|
||||||
|
|
||||||
|
## 8. Как говорить о продукте коротко
|
||||||
|
|
||||||
|
Для директора:
|
||||||
|
|
||||||
|
> DetMir показывает, какие подразделения работают стабильно, где есть просадка
|
||||||
|
> и можно ли доверять этим данным. Это не просто контроль сотрудников, а
|
||||||
|
> управленческая картина риска.
|
||||||
|
|
||||||
|
Для ИБ:
|
||||||
|
|
||||||
|
> DetMir дает очередь ситуаций для проверки, evidence-признаки и audit trail
|
||||||
|
> решений. Он не заменяет DLP/SIEM, но закрывает важный слой между активностью
|
||||||
|
> рабочих мест и внутренним разбором событий.
|
||||||
|
|
||||||
|
Для ИТ:
|
||||||
|
|
||||||
|
> DetMir показывает покрытие агентов, свежесть телеметрии и узлы, из-за которых
|
||||||
|
> управленческий KPI становится недостоверным.
|
||||||
|
|
||||||
|
## Связанные документы
|
||||||
|
|
||||||
|
- [Customer Pilot Pack](CUSTOMER_PILOT_PACK_RU.md)
|
||||||
|
- [Описание продукта](PRODUCT_DESCRIPTION_RU.md)
|
||||||
|
- [Аудит готовности к пилоту](PILOT_READINESS_AUDIT_RU.md)
|
||||||
|
- [Портал AWatch-rus](docs/PORTAL_RU.md)
|
||||||
|
- [Business Risk](docs/BUSINESS_RISK_RU.md)
|
||||||
|
- [Модель безопасности](docs/SECURITY_MODEL_RU.md)
|
||||||
Reference in New Issue
Block a user