angel/site_aegisone
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Sergey Korotonozhko
2026-05-17 05:22:06 +03:00
commit ca4d00c895
155 changed files with 45216 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
service/docs/AEGISONE_INFRASTRUCTURE_PLAN.md
+836
View File
@@ -0,0 +1,836 @@
# AegisOne Engineering — План миграции инфраструктуры и переписывания сервисной части
> **Статус:** План утверждён, готов к реализации
> **Дата:** 2026-05-17
> **Команда:** Владелец + AI-ассистент
> **Примечание:** Если при реализации возникнут вопросы — лучше уточнить, чем переделывать потом.
---
## 1. Текущее состояние
### 1.1. Публичная часть (aegisone.ru)
- **Технологии:** PHP 7.4, MySQL, inline CSS/JS
- **Хостинг:** Shared-хостинг (проблемы: HTTP 302-редирект, блокировка `/assets/`, отключённый `RewriteEngine`, PHP 7.4 тупик)
- **Страницы:** Главная, услуги, блог, контакты, форма обратной связи
- **SEO:** `robots.txt`, `sitemap.xml`, канонические URL
- **Решение:** **Не трогать.** Перенести на VPS как есть в Docker-контейнер.
### 1.2. Сервисная часть (service.aegisone.ru)
- **Технологии:** PHP 7.4, MySQL, inline CSS/JS
- **Функционал:** Админ-панель (управление пользователями, объектами, SLA, опросниками, блогом, документами), расчёты (Risk Score, Object Index, SLA price), паспорта объектов
- **Проблемы:** PHP 7.4 ограничивает развитие, нет автоматизации отчётов, нет интеграций
- **Решение:** **Полностью переписать на Python/FastAPI + Jinja2**
### 1.3. Инфраструктура
- **VPS:** Уже есть, на нём один проект (FastAPI + Uvicorn + Celery + Nginx + PostgreSQL + Redis + Alembic)
- **Хостинг:** Платный, планируется отказ
- **Git:** Нет централизованного сервера, работа на локальной машине
- **SSL:** От регистратора домена (статический, неудобно для мультидомена)
- **Домены:** `aegisone.ru` (публичная часть), планируется `service.aegisone.ru` (админка)
---
## 2. Целевая архитектура
```
┌─────────────────────────────────────────────────────────────────────┐
│ VPS │
│ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Nginx (reverse proxy + SSL) │ │
│ │ порт 80/443, Let's Encrypt │ │
│ │ │ │
│ │ aegisone.ru ──────────────► php-fpm container (порт 9000) │ │
│ │ service.aegisone.ru ─────► fastapi container (порт 8000) │ │
│ │ other-project.ru ────────► project2 container (порт 8001) │ │
│ │ git.aegisone.ru ─────────► gitea container (порт 3000) │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │
│ │ AegisOne PHP │ │ AegisOne Python │ │ Other Project │ │
│ │ (публичная) │ │ (админка) │ │ (FastAPI) │ │
│ │ │ │ │ │ │ │
│ │ • Главная │ │ • Аутентификация│ │ • ... │ │
│ │ • Услуги │ │ • Пользователи │ │ │ │
│ │ • Блог │ │ • Объекты │ │ │ │
│ │ • Контакты │ │ • Клиенты │ │ │ │
│ │ • FAQ │ │ • SLA │ │ │ │
│ │ • Карусель │ │ • Опросники │ │ │ │
│ │ • Форма │ │ • Расчёты │ │ │ │
│ │ │ │ • Отчёты (PDF) │ │ │ │
│ │ │ │ • Документы │ │ │ │
│ │ │ │ • Yandex Disk │ │ │ │
│ └────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘ │
│ │ │ │ │
│ └──────────┬──────────┘ │ │
│ │ │ │
│ ┌──────────▼──────────┐ ┌─────────▼────────┐ │
│ │ PostgreSQL │ │ PostgreSQL │ │
│ │ (AegisOne БД) │ │ (Project 2 БД) │ │
│ │ │ │ │ │
│ │ • users │ │ • ... │ │
│ │ • customers │ │ │ │
│ │ • objects │ │ │ │
│ │ • sla_contracts │ │ │ │
│ │ • questionnaire_* │ │ │ │
│ │ • blog_posts │ │ │ │
│ │ • cases │ │ │ │
│ │ • documents │ │ │ │
│ │ • photos │ │ │ │
│ │ • audit_log │ │ │ │
│ └─────────────────────┘ └──────────────────┘ │
│ │ │
│ ┌──────────▼──────────┐ │
│ │ Redis │ (кэш, Celery broker) │
│ └─────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Celery Workers (Python) │ │
│ │ │ │
│ │ • Генерация отчётов (PDF, Excel) │ │
│ │ • Загрузка фото на Yandex Disk │ │
│ │ • Интеграция с 1С (по мере необходимости) │ │
│ │ • Фоновые расчёты, уведомления │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Gitea │ │ Certbot │ │
│ │ (Git-сервер) │ │ (Let's Encrypt) │ │
│ │ │ │ │ │
│ │ • aegisone-php │ │ • aegisone.ru │ │
│ │ • aegisone-py │ │ • service.aeg.. │ │
│ │ • project2 │ │ • other.ru │ │
│ │ • CI/CD Actions │ │ • автообновление│ │
│ └──────────────────┘ └──────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Yandex Disk API (облачное хранилище) │ │
│ │ │ │
│ │ /AegisOne/ │ │
│ │ ├── objects/{object_id}/ │ │
│ │ │ ├── photos/{photo_id}.jpg │ │
│ │ │ └── documents/{doc_id}/ │ │
│ │ │ ├── {photo_id}.jpg │ │
│ │ │ └── report_{doc_id}.pdf │ │
│ │ └── ... │ │
│ │ │ │
│ │ В PostgreSQL хранятся: file_id, file_url, привязка к объекту│ │
│ └─────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
```
---
## 3. Технологический стек
### 3.1. Публичная часть (без изменений)
| Компонент | Технология | Примечание |
|---|---|---|
| Язык | PHP 7.4 | Не обновлять, не трогать |
| БД | MySQL | Мигрировать на PostgreSQL позже (опционально) |
| Веб-сервер | Nginx + PHP-FPM | В Docker-контейнере |
| CSS/JS | Inline | Без изменений |
### 3.2. Сервисная часть (Python)
| Компонент | Технология | Примечание |
|---|---|---|
| Язык | Python 3.11+ | |
| Фреймворк | FastAPI | REST API + серверный рендеринг |
| Шаблоны | Jinja2 | Серверный рендеринг, как сейчас PHP |
| Веб-сервер | Uvicorn | ASGI-сервер |
| ORM | SQLAlchemy 2.0 + Alembic | Миграции БД |
| БД | PostgreSQL 15+ | Единая БД для всех проектов |
| Аутентификация | JWT (python-jose) | Токены для API и сессий |
| Фоновые задачи | Celery + Redis | Отчёты, загрузка файлов, интеграции |
| Генерация отчётов | WeasyPrint (PDF), openpyxl (Excel) | |
| Yandex Disk | yandex-disk SDK / REST API | OAuth 2.0 |
| Валидация | Pydantic | Схемы данных |
### 3.3. Инфраструктура
| Компонент | Технология | Примечание |
|---|---|---|
| Контейнеризация | Docker + Docker Compose | |
| Reverse proxy | Nginx | Маршрутизация по доменам |
| SSL | Let's Encrypt + Certbot | Автообновление |
| Git-сервер | Gitea | Лёгкий, встроенный CI/CD |
| CI/CD | Gitea Actions | Автоматический деплой |
| Мониторинг | (опционально) Uptime Kuma | |
### 3.4. Мобильные приложения (будущее)
| Компонент | Технология | Примечание |
|---|---|---|
| Фреймворк | Flutter | |
| API | FastAPI REST endpoints | Те же, что для веб-админки |
| Аутентификация | JWT | |
---
## 4. Почему Jinja2, а не SPA
### 4.1. Сравнение
| Критерий | Jinja2 (SSR) | SPA (React/Vue) |
|---|---|---|
| Серверная нагрузка | Рендерит HTML на сервере | Отдаёт статику + JSON API |
| Масштабирование | Горизонтальное: Nginx → N FastAPI инстансов | CDN для статики + Nginx → API |
| Сложность разработки | Один стек, один деплой | Два стека, два деплоя, CORS |
| Скорость разработки | Быстро | Медленнее |
| Команда | 1-2 Python-разработчика | Python + JS/TS разработчики |
| SEO | Не нужен (админка закрыта) | Не нужен |
| Мобильные приложения | API тот же — Flutter подключается | API тот же — Flutter подключается |
| Поддержка | Проще | Сложнее (два кодовых базы) |
### 4.2. Масштабирование Jinja2 по России
При росте нагрузки:
1. **Вертикальное:** Увеличить ресурсы VPS (CPU, RAM)
2. **Горизонтальное:** Несколько инстансов FastAPI за Nginx (load balancing)
3. **Кэширование:** Redis для кэширования тяжёлых запросов
4. **CDN:** Для статики (CSS, JS, изображения) — Cloudflare или аналог
Jinja2 **не является узким местом**. Узким местом будет БД или внешние API (Yandex Disk, 1С).
### 4.3. Вердикт
**Jinja2 — правильный выбор.** Для B2B-админки SPA — это оверинжиниринг. Jinja2 даёт:
- Быструю разработку
- Простую поддержку
- Легкое масштабирование
- Единую кодовую базу
- Готовность к мобильным приложениям (тот же API)
---
## 5. Этапы реализации
### Этап 1: Docker-фундамент на VPS (1-2 недели)
**Цель:** Подготовить VPS для мультипроектной работы с Docker.
#### 1.1. Установка Docker и Docker Compose
```bash
# На VPS (Ubuntu/Debian)
apt update && apt upgrade -y
curl -fsSL https://get.docker.com | sh
systemctl enable --now docker
curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
```
#### 1.2. Базовая структура директорий на VPS
```
/opt/
├── nginx-proxy/ # Nginx reverse proxy + Certbot
│ ├── docker-compose.yml
│ ├── nginx.conf
│ └── certs/ # Let's Encrypt сертификаты
├── gitea/ # Git-сервер
│ ├── docker-compose.yml
│ └── data/ # Данные Gitea
├── aegisone-php/ # Публичная часть (PHP)
│ ├── docker-compose.yml
│ └── src/ # Исходный код (git clone)
├── aegisone-py/ # Сервисная часть (Python)
│ ├── docker-compose.yml
│ ├── app/ # FastAPI приложение
│ ├── migrations/ # Alembic миграции
│ └── requirements.txt
└── project2/ # Существующий проект
└── docker-compose.yml
```
#### 1.3. Nginx reverse proxy + Certbot
- Один Nginx-контейнер на портах 80/443
- Маршрутизация по `server_name`:
- `aegisone.ru` → `aegisone-php:80`
- `service.aegisone.ru` → `aegisone-py:8000`
- `git.aegisone.ru` → `gitea:3000`
- `other-project.ru` → `project2:8000`
- Certbot в отдельном контейнере или встроенный (nginx-proxy + acme-companion)
#### 1.4. Gitea (Git-сервер)
- Docker-образ `gitea/gitea:latest`
- Порт 3000 → `git.aegisone.ru`
- PostgreSQL для данных Gitea
- Встроенный CI/CD (Gitea Actions)
- Репозитории:
- `aegisone-php` (публичная часть, перенос с текущего хостинга)
- `aegisone-py` (новая сервисная часть)
- `project2` (существующий проект)
- `infra` (конфигурации Docker, Nginx, CI/CD)
#### 1.5. Обёртка существующего проекта в Docker
- Создать `docker-compose.yml` для project2
- Протестировать работоспособность
- Настроить домен `other-project.ru`
**Критерий завершения этапа:**
- [ ] Docker + Docker Compose установлены
- [ ] Nginx reverse proxy работает, маршрутизирует по доменам
- [ ] Certbot выдаёт SSL-сертификаты (Let's Encrypt)
- [ ] Gitea запущен на `git.aegisone.ru`
- [ ] Существующий проект работает в Docker
- [ ] Все домены доступны по HTTPS
---
### Этап 2: Перенос AegisOne на VPS (1 неделя)
**Цель:** Перенести публичную часть с хостинга на VPS, отключить хостинг.
#### 2.1. Docker-контейнер для PHP
```yaml
# /opt/aegisone-php/docker-compose.yml
services:
nginx:
image: nginx:alpine
ports:
- "9080:80" # Внутренний порт, внешний через reverse proxy
volumes:
- ./src:/var/www/html
- ./nginx.conf:/etc/nginx/conf.d/default.conf
depends_on:
- php
php:
image: php:7.4-fpm
volumes:
- ./src:/var/www/html
environment:
- DB_HOST=mysql
- DB_NAME=aegisone
- DB_USER=aegisone
- DB_PASS=<password>
mysql:
image: mysql:5.7
environment:
MYSQL_ROOT_PASSWORD: <root_password>
MYSQL_DATABASE: aegisone
MYSQL_USER: aegisone
MYSQL_PASSWORD: <password>
volumes:
- mysql_data:/var/lib/mysql
volumes:
mysql_data:
```
#### 2.2. Перенос файлов
- Скачать все файлы с хостинга (FTP/SFTP)
- Загрузить в `/opt/aegisone-php/src/`
- Настроить `config.php` для нового окружения (DB_HOST=mysql)
#### 2.3. Миграция БД
- Экспорт MySQL с хостинга: `mysqldump -u user -p db_name > backup.sql`
- Импорт в Docker MySQL: `docker exec -i aegisone-php-mysql mysql -u aegisone -p aegisone < backup.sql`
- Проверить работоспособность
#### 2.4. Настройка домена
- DNS: `aegisone.ru` → IP VPS
- Nginx reverse proxy: `server_name aegisone.ru` → `aegisone-php:9080`
- SSL: Certbot для `aegisone.ru`
#### 2.5. Тестирование и отключение хостинга
- Проверить все страницы: главная, услуги, блог, контакты, форма
- Проверить карусель, FAQ, тему (светлая/тёмная)
- Проверить Яндекс.Карту с переключением темы
- После подтверждения — отключить хостинг
**Критерий завершения этапа:**
- [ ] Публичная часть работает на VPS
- [ ] Все страницы загружаются корректно
- [ ] Форма обратной связи работает
- [ ] Яндекс.Карта переключает тему
- [ ] Домен `aegisone.ru` указывает на VPS
- [ ] Хостинг отключён
---
### Этап 3: Python-админка (FastAPI + Jinja2) (3-5 недель)
**Цель:** Полностью переписать сервисную часть на Python.
#### 3.1. Структура проекта
```
aegisone-py/
├── docker-compose.yml
├── Dockerfile
├── requirements.txt
├── alembic.ini
├── migrations/ # Alembic миграции
├── app/
│ ├── __init__.py
│ ├── main.py # FastAPI приложение
│ ├── config.py # Настройки (env vars)
│ ├── database.py # SQLAlchemy engine, session
│ ├── models/ # SQLAlchemy модели
│ │ ├── __init__.py
│ │ ├── user.py
│ │ ├── customer.py
│ │ ├── object.py
│ │ ├── sla.py
│ │ ├── questionnaire.py
│ │ ├── blog.py
│ │ ├── case.py
│ │ ├── document.py
│ │ ├── photo.py
│ │ └── audit_log.py
│ ├── schemas/ # Pydantic схемы
│ │ ├── __init__.py
│ │ ├── user.py
│ │ ├── customer.py
│ │ └── ...
│ ├── api/ # API endpoints
│ │ ├── __init__.py
│ │ ├── auth.py # Логин, JWT
│ │ ├── users.py
│ │ ├── customers.py
│ │ ├── objects.py
│ │ ├── sla.py
│ │ ├── questionnaire.py
│ │ ├── blog.py
│ │ ├── cases.py
│ │ ├── documents.py
│ │ └── reports.py
│ ├── templates/ # Jinja2 шаблоны
│ │ ├── base.html # Базовый шаблон
│ │ ├── login.html
│ │ ├── dashboard.html
│ │ ├── users/
│ │ ├── customers/
│ │ ├── objects/
│ │ ├── sla/
│ │ ├── questionnaire/
│ │ ├── blog/
│ │ ├── documents/
│ │ └── reports/
│ ├── static/ # CSS, JS, изображения
│ │ ├── css/
│ │ │ ├── service.css # Стили админки
│ │ │ └── ...
│ │ ├── js/
│ │ │ ├── main.js
│ │ │ └── ...
│ │ └── img/
│ ├── services/ # Бизнес-логика
│ │ ├── __init__.py
│ │ ├── auth_service.py
│ │ ├── calc_service.py # Расчёты (Risk Score, Object Index, SLA)
│ │ ├── report_service.py # Генерация отчётов
│ │ ├── yandex_disk_service.py # Интеграция с Yandex Disk
│ │ └── ...
│ ├── tasks/ # Celery задачи
│ │ ├── __init__.py
│ │ ├── reports.py
│ │ ├── yandex_disk.py
│ │ └── ...
│ └── utils/ # Утилиты
│ ├── __init__.py
│ ├── password.py
│ └── ...
└── tests/ # Тесты (опционально)
```
#### 3.2. Миграция данных из MySQL в PostgreSQL
- Создать Alembic миграции для всех таблиц
- Написать скрипт миграции данных:
- `users` → `users`
- `customers` → `customers`
- `objects` → `objects`
- `sla_contracts` → `sla_contracts`
- `questionnaire_sessions`, `questionnaire_answers`, `questionnaire_items` → аналогично
- `blog_posts` → `blog_posts`
- `cases` → `cases`
- `audit_log` → `audit_log`
- Протестировать миграцию на копии БД
#### 3.3. Аутентификация
- JWT-токены (python-jose)
- Логин/пароль (bcrypt)
- Роли: `owner`, `engineer`, `technician`
- Сессии через cookies (для Jinja2) + JWT (для API)
- CSRF-защита для форм
#### 3.4. CRUD-модули (по порядку приоритета)
**3.4.1. Пользователи (`/service/users/`)**
- Список, создание, редактирование, удаление
- Роль `owner` нельзя удалить, нельзя изменить роль
- Блокировка/разблокировка
- Аудит действий
**3.4.2. Клиенты (`/service/customers/`)**
- Список, создание, редактирование, удаление
- ИНН, КПП, юридический адрес, контакты
- Связь с объектами и SLA
**3.4.3. Объекты (`/service/objects/`)**
- Список, создание, редактирование, удаление
- Привязка к клиенту
- Тип, адрес, площадь, сотрудники
- Risk Score, Complexity Index, Object Index (авторасчёт)
- SLA price (авторасчёт)
**3.4.4. SLA контракты (`/service/sla/`)**
- Список, создание, редактирование, удаление
- Привязка к клиенту и объекту
- Тарифы: Базовый, Оптимальный, Максимальный
- Время реакции, периодичность ТО
- Статус: active, expired, cancelled, negotiation
**3.4.5. Опросник (`/service/questionnaire/`)**
- Создание новой сессии
- 5 шагов: Коммерческий, Технический, Эксплуатация, Риски, Расчёт SLA
- Вопросы из БД (`questionnaire_items`)
- Сохранение ответов
- Авторасчёт: Risk Score, Complexity Index, Infrastructure Load, Service History, Object Index, SLA Price
- Формирование паспорта объекта
**3.4.6. Блог (`/service/blog/`)**
- Список, создание, редактирование, удаление
- Категории: audit, sla, incident, supervision, documentation, risk, cases
- HTML-редактор (toolbar)
- Автогенерация slug из заголовка
- Статус: draft, published
**3.4.7. Примеры из практики (`/service/cases/`)**
- Список, создание, редактирование, удаление
- Заголовок, текст, эффект
- Сортировка, активность
**3.4.8. Документы (`/service/documents/`)**
- Список документов (из `service/docs/*.md`)
- Ручная сортировка
- Переименование
- Гранулярные права: view, edit, cancel (по ролям)
- JSON-хранилище прав (`docs_permissions.json`)
#### 3.5. Расчёты (перенос из PHP)
- `calc_risk_score()` — Risk Score
- `calc_complexity()` — Complexity Index
- `calc_infrastructure_load()` — Infrastructure Load
- `calc_service_history()` — Service History
- `calc_object_index()` — Object Index
- `calc_sla_price()` — SLA Price
- `risk_multiplier()` — множитель риска
- `risk_label()` — текстовая метка риска
- `object_class()` — класс объекта
- `fmt_money()` — форматирование денег
Все функции переписать на Python, покрыть тестами.
#### 3.6. Дашборд (`/service/dashboard/`)
- Метрики: количество объектов, активных SLA, открытых задач
- Графики (Chart.js или аналог)
- Быстрые действия
- Последние активности (audit_log)
#### 3.7. Фронтенд (Jinja2)
- Базовый шаблон (`base.html`) с:
- Боковой панелью (sidebar) с навигацией
- Верхней панелью (header) с пользователем и переключателем темы
- Основным контентом
- Темы: system → dark → light (localStorage, как сейчас)
- Кастомные скроллбары
- Тултипы на кнопках
- Модальные окна (создание/редактирование)
- Таблицы с поиском и пагинацией
- Адаптивность (мобильная версия)
**Критерий завершения этапа:**
- [ ] Все CRUD-модули работают
- [ ] Расчёты корректны (сравнить с PHP-версией)
- [ ] Миграция данных завершена
- [ ] Фронтенд полностью функционален
- [ ] Темы переключаются
- [ ] Мобильная версия работает
- [ ] `service.aegisone.ru` доступен по HTTPS
---
### Этап 4: Интеграции (2-3 недели)
**Цель:** Добавить генерацию отчётов, интеграцию с Yandex Disk, фоновые задачи.
#### 4.1. Yandex Disk API
- Регистрация приложения в Yandex OAuth
- Получение OAuth-токена
- SDK: `yandex-disk` или REST API через `requests`
- Структура папок:
```
/AegisOne/
├── objects/{object_id}/
│ ├── photos/
│ │ └── {photo_id}.jpg
│ └── documents/{doc_id}/
│ ├── {photo_id}.jpg
│ └── report_{doc_id}.pdf
└── ...
```
- Эндпоинты:
- `POST /api/documents/{id}/upload-photo` — загрузка фото
- `GET /api/documents/{id}/photos` — список фото
- `DELETE /api/photos/{id}` — удаление фото
- В БД: таблица `photos` (id, document_id, object_id, yandex_file_id, yandex_file_url, uploaded_at, uploaded_by)
#### 4.2. Генерация отчётов
- **PDF:** WeasyPrint (HTML → PDF)
- Шаблон паспорта объекта
- Шаблон отчёта по аудиту
- Шаблон SLA-контракта
- **Excel:** openpyxl
- Экспорт списка объектов
- Экспорт SLA-контрактов
- Экспорт отчётов по KPI
- Фоновая генерация через Celery (для тяжёлых отчётов)
#### 4.3. Celery (фоновые задачи)
- Broker: Redis
- Задачи:
- Генерация PDF-отчётов
- Загрузка фото на Yandex Disk
- Отправка уведомлений (email, Telegram)
- Интеграция с 1С (по мере необходимости)
- Мониторинг: Flower (веб-интерфейс для Celery)
#### 4.4. Интеграция с 1С (опционально, по мере необходимости)
- REST API 1С или OData
- Синхронизация: клиенты, объекты, договоры
- Фоновая задача Celery
**Критерий завершения этапа:**
- [ ] Yandex Disk API интегрирован
- [ ] Фото загружаются и привязываются к документам
- [ ] PDF-отчёты генерируются
- [ ] Excel-экспорт работает
- [ ] Celery запущен, задачи выполняются
- [ ] (Опционально) Интеграция с 1С настроена
---
### Этап 5: CI/CD и автоматизация деплоя (1 неделя)
**Цель:** Настроить автоматический деплой при push в Git.
#### 5.1. Gitea Actions (CI/CD)
- Встроенный CI/CD в Gitea (совместим с GitHub Actions)
- Workflow для `aegisone-py`:
```yaml
name: Deploy AegisOne Python
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build and push Docker image
run: |
docker build -t registry.git.aegisone.ru/aegisone-py:latest .
docker push registry.git.aegisone.ru/aegisone-py:latest
- name: Deploy to VPS
run: |
ssh user@vps "cd /opt/aegisone-py && docker compose pull && docker compose up -d"
```
#### 5.2. Структура репозиториев в Gitea
```
git.aegisone.ru/
├── aegisone/aegisone-php # Публичная часть (PHP)
├── aegisone/aegisone-py # Сервисная часть (Python)
├── aegisone/infra # Docker, Nginx, CI/CD конфиги
└── aegisone/project2 # Существующий проект
```
#### 5.3. Автоматический деплой
- Push в `main` → Gitea Actions → сборка Docker-образа → деплой на VPS
- Rollback: `docker compose down && docker compose up -d` с предыдущим образом
- Миграции БД: Alembic `upgrade head` автоматически при деплое
#### 5.4. Локальная разработка
- `docker-compose.dev.yml` для локальной разработки
- Hot-reload для Python (uvicorn --reload)
- Локальная БД (PostgreSQL в Docker)
- Синхронизация с VPS: `git push` → автоматический деплой
**Критерий завершения этапа:**
- [ ] Gitea Actions настроены для всех проектов
- [ ] Push в `main` → автоматический деплой
- [ ] Rollback работает
- [ ] Миграции БД применяются автоматически
- [ ] Локальная разработка через Docker
---
## 6. Миграция данных: MySQL → PostgreSQL
### 6.1. Таблицы для миграции
| MySQL таблица | PostgreSQL таблица | Примечание |
|---|---|---|
| `users` | `users` | Без изменений |
| `login_attempts` | `login_attempts` | Без изменений |
| `audit_log` | `audit_log` | Без изменений |
| `objects` | `objects` | + `customer_id` FK |
| `object_assignments` | `object_assignments` | Без изменений |
| `tasks` | `tasks` | Без изменений |
| `task_comments` | `task_comments` | Без изменений |
| `customers` | `customers` | Новая таблица |
| `sla_contracts` | `sla_contracts` | + `customer_id` FK, `contract_number`, `description`, `response_time_hours` |
| `incidents` | `incidents` | Без изменений |
| `engineer_kpi` | `engineer_kpi` | Без изменений |
| `questionnaire_sessions` | `questionnaire_sessions` | Без изменений |
| `questionnaire_answers` | `questionnaire_answers` | Без изменений |
| `questionnaire_items` | `questionnaire_items` | Новая таблица |
| `object_passports` | `object_passports` | Без изменений |
| `blog_posts` | `blog_posts` | ENUM категории изменён |
| `cases` | `cases` | Без изменений |
### 6.2. Скрипт миграции
```python
# scripts/migrate_mysql_to_postgres.py
import mysql.connector
import psycopg2
from psycopg2.extras import execute_batch
# Подключение к MySQL
mysql_conn = mysql.connector.connect(host='...', user='...', password='...', database='...')
mysql_cursor = mysql_conn.cursor(dictionary=True)
# Подключение к PostgreSQL
pg_conn = psycopg2.connect(host='...', user='...', password='...', database='...')
pg_cursor = pg_conn.cursor()
# Миграция каждой таблицы
tables = ['users', 'customers', 'objects', 'sla_contracts', ...]
for table in tables:
mysql_cursor.execute(f"SELECT * FROM {table}")
rows = mysql_cursor.fetchall()
if rows:
columns = rows[0].keys()
placeholders = ', '.join(['%s'] * len(columns))
cols = ', '.join(columns)
execute_batch(
pg_cursor,
f"INSERT INTO {table} ({cols}) VALUES ({placeholders}) ON CONFLICT DO NOTHING",
[tuple(row[col] for col in columns) for row in rows]
)
pg_conn.commit()
```
### 6.3. Проверка миграции
- Сравнить количество записей в MySQL и PostgreSQL
- Проверить FK-связи
- Протестировать CRUD-операции на PostgreSQL
- Откат: сохранить бэкап MySQL до миграции
---
## 7. Безопасность
### 7.1. Аутентификация и авторизация
- JWT-токены с expiration (1 час)
- Refresh tokens (7 дней)
- Роли: `owner`, `engineer`, `technician`
- Гранулярные права для документов (view, edit, cancel)
- CSRF-защита для форм
### 7.2. Защита данных
- Пароли: bcrypt (cost factor 12)
- HTTPS для всех доменов (Let's Encrypt)
- Firewall: только порты 80, 443, 22 (SSH)
- Docker: изоляция контейнеров, нет root в контейнерах
- БД: нет внешнего доступа, только из Docker-сети
### 7.3. Бэкапы
- PostgreSQL: `pg_dump` ежедневно (cron)
- Yandex Disk: файлы уже в облаке
- Gitea: бэкап репозиториев (tar)
- Хранение бэкапов: отдельный диск или облако
### 7.4. Мониторинг
- (Опционально) Uptime Kuma для мониторинга доступности
- Логи: Docker logs + ротация
- Алерты: email/Telegram при ошибках
---
## 8. Риски и митигация
| Риск | Вероятность | Влияние | Митигация |
|---|---|---|---|
| Ошибка миграции данных | Средняя | Высокое | Тестирование на копии, бэкап MySQL |
| Простои при деплое | Низкая | Среднее | Zero-downtime деплой (docker compose up -d) |
| Проблемы с SSL | Низкая | Среднее | Certbot автообновление, мониторинг |
| Yandex Disk API лимиты | Низкая | Низкое | Кэширование, retry logic |
| Нехватка ресурсов VPS | Средняя | Высокое | Мониторинг CPU/RAM, масштабирование |
| Ошибки в расчётах | Средняя | Высокое | Тесты, сравнение с PHP-версией |
---
## 9. Оценки времени
| Этап | Описание | Оценка |
|---|---|---|
| Этап 1 | Docker-фундамент | 1-2 недели |
| Этап 2 | Перенос AegisOne на VPS | 1 неделя |
| Этап 3 | Python-админка | 3-5 недель |
| Этап 4 | Интеграции | 2-3 недели |
| Этап 5 | CI/CD | 1 неделя |
| **Итого** | | **8-12 недель** |
---
## 10. Контрольные точки
| Точка | Описание | Критерий успеха |
|---|---|---|
| КП1 | Docker-фундамент готов | Все сервисы запущены, домены работают по HTTPS |
| КП2 | Публичная часть на VPS | aegisone.ru работает, хостинг отключён |
| КП3 | Python-админка MVP | CRUD для пользователей, объектов, SLA работает |
| КП4 | Python-админка полная | Все модули, расчёты, миграция данных завершены |
| КП5 | Интеграции | Yandex Disk, отчёты, Celery работают |
| КП6 | CI/CD | Автоматический деплой при push |
---
## 11. Открытые вопросы (уточнить перед реализацией)
> **Важно:** Если при реализации возникнут вопросы — лучше уточнить, чем переделывать потом.
1. **Миграция данных:** Переносим все данные из MySQL в PostgreSQL или начинаем с чистой БД? (Рекомендация: мигрировать)
2. **Домен для админки:** `service.aegisone.ru` или `app.aegisone.ru`? (Рекомендация: `service.aegisone.ru`)
3. **Yandex Disk OAuth:** Использовать токен приложения или OAuth с авторизацией пользователя? (Рекомендация: токен приложения для простоты)
4. **Генерация отчётов:** Какие именно отчёты нужны в первую очередь? (Паспорт объекта, отчёт по аудиту, SLA-контракт?)
5. **Интеграция с 1С:** Какая версия 1С? Какой метод интеграции (REST API, OData, файловый обмен)?
6. **Мониторинг:** Нужен ли Uptime Kuma или другой мониторинг? (Рекомендация: да, для продакшена)
7. **Бэкапы:** Где хранить бэкапы PostgreSQL? (Отдельный диск на VPS, облако, другой сервер?)
8. **Тестирование:** Покрывать ли код тестами? (Рекомендация: да, хотя бы критические расчёты)
9. **Документация:** Вести ли документацию по API? (Рекомендация: да, через FastAPI автоматическую /docs)
10. **Логирование:** Какой уровень логирования? Куда писать логи? (Рекомендация: INFO в stdout, Docker logs)
---
## 12. Следующие шаги
1. **Утвердить план** — ответить на открытые вопросы (раздел 11)
2. **Начать Этап 1** — Docker-фундамент на VPS
3. **Параллельно** — создать репозитории в Gitea, настроить CI/CD skeleton
4. **После Этапа 1** — приступить к Этапу 2 (перенос PHP)
5. **После Этапа 2** — приступить к Этапу 3 (Python-админка)
---
**Документ создан:** 2026-05-17
**Версия:** 1.0
**Автор:** AI-ассистент + Владелец
**Статус:** Готов к реализации после утверждения
service/docs/KPI_инженеров.md
+485
View File
@@ -0,0 +1,485 @@
Ниже — система KPI, которая превращает инженеров и техников из “выездных исполнителей” в управляемую часть инженерной SLA-модели AegisOne Engineering.
Главная цель системы:
> не “оценивать занятость”, а измерять качество эксплуатации, скорость реакции и снижение рисков объекта
---
0. ПРИНЦИП СИСТЕМЫ KPI
Ты НЕ измеряешь:
сколько выездов сделал инженер
сколько он “починил”
Ты измеряешь:
1) надежность объектов
2) соблюдение SLA
3) качество диагностики
4) снижение повторных инцидентов
---
1. СТРУКТУРА KPI (3 УРОВНЯ)
2. Операционный KPI (ежедневный)
3. SLA KPI (контрактный)
4. Инженерный KPI качества (экспертный)
---
2. ОПЕРАЦИОННЫЙ KPI (Execution KPI)
Это “что сделал инженер”.
---
KPI 1: Время реакции (Response Time)
Формула:
RT = (фактическое время реакции / SLA время реакции)
---
Оценка:
RT Оценка
≤ 1.0 норма
1.0–1.2 допустимо
> 1.2 нарушение
---
Пример:
SLA: 2 часа
факт: 3 часа
RT = 3 / 2 = 1.5 → ❌ нарушение
---
KPI 2: Время устранения (Resolution Time)
TTR = фактическое время устранения / нормативное время
---
Важно:
Норматив зависит от типа инцидента:
P1 (критический) — 2–6 часов
P2 — до 24 часов
P3 — до 3 дней
---
KPI 3: Закрытие заявок в SLA
SLA Compliance = (заявки в SLA / все заявки) × 100%
---
Норма:
≥ 95% — отлично
90–95% — допустимо
< 90% — проблема инженера
---
KPI 4: Повторные обращения (Reopen Rate)
RR = (повторные заявки / общее число заявок) × 100%
---
Норма:
≤ 5% — хорошо
5–10% — средне
> 10% — плохая диагностика
---
3. SLA KPI (контрактный уровень)
---
KPI 5: Выполнение SLA по объектам
Object SLA = (объекты без нарушений SLA / все объекты) × 100%
---
Норма:
≥ 95% — стабильная сеть объектов
< 90% — системная проблема команды
---
KPI 6: Доступность систем (System Uptime)
Uptime = (время работы системы / общее время) × 100%
---
Цель:
99%+ для критических объектов
97–99% допустимо
< 97% — риск SLA разрыва
---
4. ИНЖЕНЕРНЫЙ KPI (КАЧЕСТВО ЭКСПЕРТИЗЫ)
Это ключевой уровень, который отличает тебя от монтажников.
---
KPI 7: Точность диагностики
Accuracy = (подтвержденные неисправности / выявленные) × 100%
---
Пример:
выявил 10 проблем
9 подтвердились
→ 90%
---
Норма:
≥ 85% — хорошо
< 80% — инженер слабый
---
KPI 8: Глубина диагностики (Risk Coverage Score)
Оценивает, насколько инженер видит системные риски.
---
Формула (балльная система):
Каждый объект оценивается по 5 зонам:
видео
СКУД
пожарка
питание
сеть
RCS = (проверенные зоны / 5) × 100%
---
Норма:
100% — стандарт AegisOne
< 80% — поверхностная работа
---
KPI 9: Снижение повторных инцидентов
IRR = ((инциденты до - инциденты после) / до) × 100%
---
Это ключевой KPI бизнеса
---
5. ФИНАНСОВЫЙ KPI ИНЖЕНЕРА
---
KPI 10: Доход на инженера (Revenue per Engineer)
RPE = общий SLA доход / количество инженеров
---
Норма:
500k – слабая загрузка
800k – норм
1.2M+ – сильная модель
---
6. ИТОГОВЫЙ ИНДЕКС ИНЖЕНЕРА (ENGINEER SCORE)
Это твой главный инструмент управления.
---
Формула:
ES =
(0.25 × SLA Compliance) +
(0.20 × Response Time Score) +
(0.20 × Resolution Time Score) +
(0.15 × Diagnosis Accuracy) +
(0.10 × Reopen Rate Score) +
(0.10 × Risk Coverage Score)
---
Интерпретация:
Score Уровень
90–100 Senior Engineer
80–89 Strong Engineer
70–79 Middle
< 70 требует обучения
---
7. ДОПОЛНИТЕЛЬНЫЕ KPI (ОЧЕНЬ ВАЖНЫЕ)
---
KPI 11: Документирование (Documentation Quality)
DQ = (полные отчёты / все выезды) × 100%
---
KPI 12: Качество отчёта (Report Quality Score)
Оценивается по чек-листу:
есть ли риски
есть ли вывод
есть ли рекомендации
есть ли фото/фиксация
---
KPI 13: Самостоятельность инженера
Autonomy = (самостоятельные решения / всего решений) × 100%
---
8. КАК ЭТО ВЫГЛЯДИТ В CRM
---
Инженер:
- SLA Compliance: 96%
- RT: 1.1
- TTR: 0.9
- Diagnosis: 88%
- Reopen: 3%
- Score: 91 (Senior)
---
9. СИСТЕМА МОТИВАЦИИ (ВАЖНО)
---
БАЗОВАЯ ЛОГИКА:
фикс оклад
бонус за KPI
штрафы только за SLA нарушения
---
БОНУС:
Score 90+ → +20% к премии
Score 80–89 → +10%
Score < 80 → без бонуса
---
10. ГЛАВНЫЙ ПРИНЦИП СИСТЕМЫ
Ты НЕ платишь за:
❌ “работу”
❌ “выезды”
Ты платишь за:
стабильность инфраструктуры клиента
---
11. КАК ЭТА СИСТЕМА МАСШТАБИРУЕТ БИЗНЕС
---
1 инженер = управляемая единица SLA
Ты можешь:
добавлять инженеров
сравнивать эффективность
масштабировать регионы
контролировать качество без присутствия
---
12. СВЯЗЬ С ТВОЕЙ БИЗНЕС-МОДЕЛЬЮ
---
KPI инженера
↓
качество SLA
↓
удержание клиентов
↓
MRR рост
↓
масштаб компании
---
13. СЛЕДУЮЩИЙ УРОВЕНЬ (если продолжать систему)
Я могу дальше собрать:
систему грейдов инженеров (Junior → Lead → Chief)
модель расчёта зарплаты под KPI
автоматическую таблицу KPI в Excel/Notion
SLA dashboard (как у IT-компаний)
систему контроля качества через аудит отчётов
---
ИТОГ
Ты получил не “мотивацию сотрудников”.
Ты получил:
> систему управления инженерной эксплуатационной компанией через измеримые риски и SLA
Это уровень компаний, которые продают не услуги — а надежность инфраструктуры бизнеса.
service/docs/Owner.md
+520
View File
@@ -0,0 +1,520 @@
Ты сейчас описываешь переход от “владельца инженерной фирмы” к роли:
операционного директора инженерной системы (Engineering Operations System Owner)
В такой модели ты уже не контролируешь людей напрямую — ты контролируешь поток рисков, денег, SLA и загрузки системы.
Я разложу это как управленческую “панель управления” (CEO Dashboard), разделив на:
1. критически важные метрики (must have)
2. важные (should have)
3. полезные (nice to have)
4. формулы
5. графики и визуализации
6. как это связывается в одну систему управления
---
1. КРИТИЧЕСКИ ВАЖНЫЕ ПАРАМЕТРЫ (CEO CORE CONTROL LAYER)
Это то, без чего ты не управляешь компанией, а просто “наблюдаешь бизнес”.
---
1.1 MRR / ARR (регулярный доход SLA)
Формула:
MRR = Σ (все SLA контракты / 12)
ARR = MRR × 12
---
Почему это главное:
Ты продаёшь не монтаж, а:
> стабильность объектов
---
График:
📈 линия роста MRR по месяцам
📊 разбивка по типам объектов
---
Управленческая логика:
если MRR растёт → система здорова
если нет → маркетинг/воронка сломана
---
1.2 RETENTION RATE (удержание клиентов)
Формула:
Retention = (клиенты в конце периода / клиенты в начале) × 100%
---
Норма:
95–100% = отлично
85–95% = нормально
<85% = проблема в SLA
---
График:
📉 “утечка клиентов по месяцам”
---
Интерпретация:
Если падает retention — проблема не в продажах, а в:
инженерах
SLA
качестве реакции
---
1.3 SLA COMPLIANCE (исполнение контрактов)
Формула:
SLA Compliance = (выполненные заявки в SLA / все заявки) × 100%
---
Норма:
95–99% = система стабильна
<90% = начинаются разрывы контрактов
---
График:
📊 compliance по инженерам / регионам
---
1.4 COST PER SLA OBJECT (стоимость обслуживания объекта)
Формула:
Cost per Object = (ФОТ + выезды + оборудование + накладные) / количество объектов
---
Почему важно:
Ты должен видеть:
> объект приносит деньги или сжигает ресурс
---
График:
📊 распределение стоимости по типам объектов
---
1.5 ENGINEER PRODUCTIVITY (производительность инженера)
Формула:
EP = SLA Revenue / количество инженеров
---
Или глубже:
EP2 = (закрытые заявки × сложность) / часы работы
---
График:
📊 эффективность по инженерам (ranking)
---
2. ВАЖНЫЕ ПАРАМЕТРЫ (OPTIMIZATION LAYER)
Это влияет на прибыль, но не ломает систему сразу.
---
2.1 LEAD → SLA CONVERSION RATE
Формула:
Conversion = SLA contracts / all qualified leads
---
График:
📈 воронка: лиды → аудит → SLA
---
Диагностика:
низкая конверсия → проблема продаж/аудита
высокая → система сильная
---
2.2 AVERAGE SLA CONTRACT VALUE
Формула:
ARPC = Total SLA revenue / number of contracts
---
График:
📊 средний чек по объектам
---
2.3 INCIDENT RATE (частота аварий)
Формула:
IR = incidents / objects
---
Почему важно:
Показывает:
> реальное качество эксплуатации
---
2.4 REOPEN RATE (повторные заявки)
Reopen = повторные обращения / все обращения
---
Если растёт:
→ инженер плохо диагностирует
---
3. ПОЛЕЗНЫЕ ПАРАМЕТРЫ (NICE TO HAVE)
Это усиливает контроль, но не критично.
---
3.1 CUSTOMER SATISFACTION (CSAT)
CSAT = (положительные оценки / все оценки) × 100%
---
3.2 RESPONSE TIME DISTRIBUTION
Не среднее, а распределение:
📊 0–2 часа
📊 2–6
📊 6–24
---
3.3 EQUIPMENT HEALTH INDEX
EHI = (исправное оборудование / общее оборудование) × 100%
---
3.4 ENGINEER UTILIZATION RATE
Utilization = рабочие часы / доступные часы
---
4. ГЛАВНЫЙ CEO-ИНДЕКС (SYSTEM HEALTH SCORE)
Это твоя “панель управления бизнесом”.
---
Формула:
SHS =
(0.25 × MRR growth) +
(0.20 × SLA compliance) +
(0.20 × retention) +
(0.15 × engineer productivity) +
(0.10 × conversion rate) +
(0.10 × incident stability)
---
Интерпретация:
SHS состояние
85–100 масштабируемый рост
70–85 стабильный бизнес
50–70 проблемы в системе
<50 системный кризис
---
5. КЛЮЧЕВЫЕ ГРАФИКИ CEO (ДОСКА УПРАВЛЕНИЯ)
---
5.1 MRR Growth Curve
📈 рост повторного дохода
---
5.2 SLA Compliance Heatmap
🟥 красный = проблемные инженеры
🟩 зелёный = сильные
---
5.3 Client Retention Funnel
📊 где теряются клиенты
---
5.4 Engineer Performance Ranking
📊 топ / низ производительности
---
5.5 Incident Map
📍 какие объекты ломаются чаще
---
5.6 Cost vs Revenue per Object
📊 прибыльность каждого SLA
---
6. КРИТИЧЕСКАЯ ЛОГИКА УПРАВЛЕНИЯ
Ты управляешь не людьми.
Ты управляешь:
рисками → SLA → деньгами → нагрузкой инженеров
---
7. ЧТО ТЕБЕ ОБЯЗАТЕЛЬНО ВИДЕТЬ КАЖДЫЙ ДЕНЬ
---
DAILY CEO DASHBOARD:
SLA compliance
аварии за 24ч
новые SLA контракты
просрочки
перегруз инженеров
---
8. ЧТО ТЕБЕ НУЖНО ВИДЕТЬ РАЗ В НЕДЕЛЮ
---
MRR рост
retention
эффективность инженеров
конверсия аудита в SLA
---
9. ЧТО СМОТРЕТЬ РАЗ В МЕСЯЦ
---
прибыльность объектов
эффективность регионов
нагрузка команды
системные сбои
---
10. ГЛАВНЫЙ ПРИНЦИП
Ты не управляешь:
❌ монтажами
❌ выездами
❌ людьми
---
Ты управляешь:
системой инженерной надежности объектов бизнеса
---
11. ЕСЛИ СВЯЗАТЬ ВСЁ В ОДНУ МОДЕЛЬ
Аудит → Risk Score → SLA цена → контракт → MRR → KPI инженеров → retention → рост
---
12. ИТОГ
Ты как CEO должен видеть не “что происходит”, а:
> где именно в системе возникает прибыль или утечка денег/риска
---
13. ЕСЛИ ДАЛЬШЕ РАЗВИВАТЬ СИСТЕМУ
Я могу собрать:
полноценный CEO-dashboard (Excel / Notion / Power BI)
автоматическую систему расчёта SHS
дашборд инженеров в реальном времени
модель прогнозирования MRR на 3–6 месяцев
систему раннего предупреждения потерь клиентов
---
Если коротко:
ты строишь не компанию — ты строишь управляемую инженерную систему с финансовыми законами внутри неё.
service/docs/SEO.md
+488
View File
@@ -0,0 +1,488 @@
Сейчас мы подходим к одному из самых важных этапов.
Потому что SEO для тебя — это НЕ “трафик ради трафика”.
Тебе не нужны:
- тысячи посетителей;
- B2C заявки;
- мусорные лиды.
Тебе нужен:
# узкий B2B SEO с высокой экспертностью.
И здесь у тебя огромный шанс, потому что рынок безопасности:
# SEO делает ужасно.
Большинство сайтов:
- про “монтаж камер”;
- про оборудование;
- про бренды;
- про “низкие цены”.
А ты можешь занять:
# нишу инженерной эксплуатации.
---
# ГЛАВНАЯ СТРАТЕГИЯ SEO
---
# НЕ ПРОДАВАТЬ:
- камеры;
- оборудование;
- монтаж.
---
# ПРОДАВАТЬ:
- эксплуатацию;
- SLA;
- аудит;
- контроль;
- сопровождение;
- надежность.
---
# ТВОЯ SEO-МОДЕЛЬ
---
# УРОВЕНЬ 1
# КОММЕРЧЕСКИЕ СТРАНИЦЫ
Это:
# страницы услуг.
Они приводят клиентов.
---
# УРОВЕНЬ 2
# ОТРАСЛЕВЫЕ СТРАНИЦЫ
Это:
# страницы под конкретный бизнес.
Они повышают доверие и SEO.
---
# УРОВЕНЬ 3
# ЭКСПЕРТНЫЙ БЛОГ
Это:
# двигатель доверия.
---
# СТРУКТУРА САЙТА
Вот идеальная структура для тебя.
---
# ГЛАВНАЯ
## URL:
`/`
---
## Цель:
- показать позиционирование;
- перевести из “монтажников”;
- дать B2B доверие.
---
# РАЗДЕЛ УСЛУГ
---
## `/services/`
Общая страница услуг.
---
# ОСНОВНЫЕ СТРАНИЦЫ
---
## `/services/audit/`
# Технический аудит систем безопасности
---
## `/services/sla/`
# SLA сопровождение объектов
---
## `/services/maintenance/`
# Техническое обслуживание систем безопасности
---
## `/services/external-engineer/`
# Внешний инженер безопасности
---
## `/services/recovery/`
# Восстановление проблемных объектов
---
## `/services/fire-alarm/`
# Обслуживание пожарной сигнализации
---
## `/services/video-surveillance/`
# Эксплуатация видеонаблюдения
---
## `/services/access-control/`
# Обслуживание СКУД
---
# ОТРАСЛЕВЫЕ СТРАНИЦЫ
Это очень важно.
---
## `/industries/hotels/`
# Системы безопасности гостиниц
---
## `/industries/logistics/`
# Склады и логистика
---
## `/industries/medical/`
# Клиники и медцентры
---
## `/industries/commercial/`
# Коммерческая недвижимость
---
## `/industries/agro/`
# Агропредприятия
---
# БЛОГ
---
## `/blog/`
---
# КАТЕГОРИИ
---
## `/blog/video/`
Проблемы видеонаблюдения.
---
## `/blog/fire-alarm/`
Пожарная безопасность.
---
## `/blog/sla/`
Эксплуатация и SLA.
---
## `/blog/audit/`
Технический аудит.
---
# ПОЧЕМУ ЭТО ТАК ВАЖНО
Google и Яндекс сейчас любят:
- структуру;
- экспертность;
- тематичность;
- глубину.
---
# ЧТО НЕЛЬЗЯ ДЕЛАТЬ
---
# НЕ ДЕЛАТЬ:
- 1 страницу “все услуги”;
- короткие SEO-тексты;
- переспам;
- “установка камер Краснодар”.
Это мусорный рынок.
---
# ТВОЯ SEO-СТРАТЕГИЯ
---
# НЕ:
“дешевый монтаж”
---
# А:
# “эксплуатационные риски объектов”.
---
# ГЛАВНЫЕ SEO КЛЮЧИ
Вот где деньги.
---
# АУДИТ
- аудит систем безопасности
- технический аудит объекта
- аудит видеонаблюдения
- аудит пожарной сигнализации
- проверка систем безопасности
---
# SLA
- SLA обслуживание
- сопровождение систем безопасности
- техническое сопровождение объекта
- эксплуатация систем безопасности
---
# ОБСЛУЖИВАНИЕ
- обслуживание пожарной сигнализации Краснодар
- обслуживание видеонаблюдения Краснодар
- обслуживание СКУД Краснодар
---
# ОТРАСЛЕВЫЕ
- системы безопасности гостиниц
- обслуживание гостиниц Краснодар
- безопасность складов Краснодар
---
# ТЕПЕРЬ ГЛАВНОЕ
# КАК ПИСАТЬ SEO-ТЕКСТЫ
---
# ТВОЯ ЦЕЛЬ
НЕ: “набить ключи”.
---
# А:
# показать инженерную экспертность.
---
# ПРИМЕР SEO-ТЕКСТА
---
---
# ТЕПЕРЬ:
# КОД СТРАНИЦЫ УСЛУГИ
Например:
# `/services/audit/index.php`
---
---
# SEO РЕКОМЕНДАЦИИ ПО ТЕХНИЧЕСКОЙ ЧАСТИ
---
# ОБЯЗАТЕЛЬНО:
---
# 1. ЧПУ URL
---
# ХОРОШО:
`/services/audit/`
---
# ПЛОХО:
`/page.php?id=123`
---
# 2. TITLE И DESCRIPTION
Для каждой страницы.
---
# Пример:
## TITLE:
Технический аудит систем безопасности в Краснодаре
---
## DESCRIPTION:
Проверка состояния систем безопасности коммерческих объектов. Аудит видеонаблюдения, СКУД и пожарной сигнализации.
---
# 3. H1 ТОЛЬКО ОДИН
Это важно.
---
# 4. schema.org
Очень желательно.
---
# 5. СКОРОСТЬ
Не перегружать:
- анимацией;
- тяжелыми видео;
- конструкторами.
---
# 6. GEO SEO
На каждой странице:
- Краснодар;
- Краснодарский край.
---
# 7. ВНУТРЕННЯЯ ПЕРЕЛИНКОВКА
Например:
- из статьи → на аудит;
- из отрасли → на SLA;
- из кейса → на услугу.
---
# ЧТО ДАСТ РЕАЛЬНЫЙ РОСТ
---
# НЕ:
- покупка ссылок;
- SEO-магия.
---
# А:
- экспертные статьи;
- кейсы;
- отраслевые страницы;
- техническая глубина;
- регулярность.
---
# САМОЕ ВАЖНОЕ
Ты должен выглядеть:
# не как “сайт монтажников”.
А как:
# инженерная эксплуатационная компания.
И это:
- редкость;
- слабоконкурентная ниша;
- высокий уровень доверия;
- хороший B2B SEO.
service/docs/SLA.md
+795
View File
@@ -0,0 +1,795 @@
SLA — ЭТО ОСНОВА ТВОЕГО ПЕРЕХОДА ИЗ “МОНТАЖНИКОВ” В B2B-СЕРВИС
Большинство компаний безопасности в Краснодарском крае:
“иногда приезжают”;
“что-то смотрят”;
“делают отметку”;
работают хаотично.
SLA делает тебя:
инженерной сервисной компанией;
предсказуемым подрядчиком;
частью эксплуатации бизнеса клиента.
Именно SLA позволяет:
продавать дороже;
получать абонентку;
заходить в сети;
работать с коммерческой недвижимостью;
уходить от демпинга.
---
ЧТО ТАКОЕ SLA ПРОСТЫМИ СЛОВАМИ
SLA (Service Level Agreement)
это:
соглашение об уровне сервиса.
То есть: ты заранее фиксируешь:
что обслуживаешь;
как быстро реагируешь;
что считается аварией;
что входит в обслуживание;
какие обязательства у сторон.
---
ПОЧЕМУ B2B ЭТО ЛЮБИТ
Потому что бизнес покупает:
предсказуемость;
контроль;
ответственность;
понятные сроки.
---
ТВОЯ ЦЕЛЬ
НЕ:
> “мы обслуживаем камеры”
А:
“мы гарантируем работоспособность критической инфраструктуры объекта”.
---
КАК SLA ПОДНИМАЕТ ТЕБЯ НАД РЫНКОМ
Без SLA:
“звоните если что”.
С SLA:
регламенты;
сроки реакции;
журналирование;
прозрачность;
ответственность.
---
ГЛАВНАЯ ОШИБКА
Многие делают:
> “приедем в течение суток”.
Это НЕ SLA.
---
НАСТОЯЩИЙ SLA ВКЛЮЧАЕТ
---
1. КЛАССИФИКАЦИЮ ИНЦИДЕНТОВ
Например:
Приоритет Пример Реакция
P1 Критический Не работает пожарка 2 часа
P2 Высокий Нет архива камер 4 часа
P3 Средний Частично не работает СКУД 24 часа
P4 Низкий Настройка доступа Планово
---
2. ВРЕМЯ РЕАКЦИИ
Очень важно: не “устранения”.
А:
начала работ.
---
3. РЕГЛАМЕНТНЫЕ РАБОТЫ
Например:
ежемесячные проверки;
тестирование;
резервное копирование;
контроль архивов;
проверка питания;
чистка;
тест тревог.
---
4. ОТЧЕТНОСТЬ
Это критично.
Ты должен быть:
“прозрачным подрядчиком”.
---
5. SLA ПО КАНАЛАМ СВЯЗИ
Например:
Telegram;
email;
аварийный телефон;
сервисный портал.
---
6. SLA ПО ДОСТУПНОСТИ
Вот тут начинаются большие чеки.
Например:
Система Целевая доступность
Пожарка 99.9%
Видеонаблюдение 99%
СКУД 99%
---
ТЕПЕРЬ ГЛАВНОЕ:
КАК ТЕБЕ ДЕЛАТЬ SLA В РЕАЛЬНОСТИ
Тебе НЕ нужен корпоративный монстр.
Тебе нужна:
простая инженерная система.
---
БАЗОВАЯ МОДЕЛЬ SLA ДЛЯ ТЕБЯ
---
START SLA
Для:
небольших объектов;
офисов;
клиник;
магазинов.
---
Реакция:
до 24 часов
---
Регламент:
1 раз в месяц.
---
Что входит:
проверка состояния;
диагностика;
журнал;
рекомендации;
консультации.
---
Стоимость:
25–40 тыс ₽/мес
Для Краснодара — нормально для качественного B2B.
---
BUSINESS SLA
Твой основной продукт.
---
Реакция:
критическая авария — 4 часа;
обычная — 24 часа.
---
Регламент:
2–4 раза в месяц.
---
Входит:
аварийные выезды;
удаленная диагностика;
контроль архива;
контроль питания;
фотоотчеты;
журнал;
рекомендации;
сопровождение проверок.
---
Стоимость:
60–120 тыс ₽/мес
Для:
гостиниц;
складов;
коммерческой недвижимости.
---
ENTERPRISE SLA
Вот это путь к большим деньгам.
---
Реакция:
2 часа
---
Формат:
“внешний инженерный отдел”.
---
Входит:
постоянный контроль;
участие в эксплуатации;
работа с подрядчиками;
аудит;
сопровождение модернизаций;
приемка;
развитие систем.
---
Стоимость:
180–500 тыс ₽/мес
---
ВАЖНО:
SLA НЕЛЬЗЯ ПРОДАВАТЬ КАК “ТО”
Иначе: ты вернешься в дешевый рынок.
---
SLA ПРОДАЕТСЯ КАК:
“управление рисками объекта”.
---
ПРИМЕР ТЕКСТА ДЛЯ САЙТА
---
SLA-сопровождение систем безопасности
Мы работаем по регламентированным SLA-моделям обслуживания.
Это означает:
— фиксированное время реакции;
— контроль состояния систем;
— прозрачную отчетность;
— регламентные проверки;
— ответственность за работоспособность инфраструктуры объекта.
SLA позволяет снизить риски простоев, исключить скрытые неисправности и обеспечить стабильную эксплуатацию систем безопасности.
Для каждого объекта разрабатывается индивидуальный регламент обслуживания.
---
ПРИМЕР SLA ТАБЛИЦЫ ДЛЯ САЙТА
---
Приоритет| Описание| Реакция
P1| Полный отказ критической системы| до 2 часов
P2| Частичная потеря функционала| до 4 часов
P3| Некритичная неисправность| до 24 часов
P4| Плановые работы и настройки| по графику
---
ТЕПЕРЬ САМОЕ ВАЖНОЕ
КАК ТЕБЕ СЧИТАТЬ ЦЕНУ SLA
Не “от количества камер”.
Это ошибка рынка.
---
ТВОЯ МОДЕЛЬ ЦЕНООБРАЗОВАНИЯ
Цена считается по:
критичности объекта;
количеству систем;
SLA;
расстоянию;
времени реакции;
рискам;
сложности эксплуатации.
---
МОДЕЛЬ ДЛЯ КРАСНОДАРСКОГО КРАЯ
---
КРАСНОДАР
Можно:
быстрые выезды;
дешевле логистика.
---
СОЧИ
Цена должна быть:
выше на 30–50%.
Из-за:
логистики;
сезонности;
срочности.
---
УДАЛЕННЫЕ РАЙОНЫ
Нужно:
отдельное SLA.
---
Например:
Базовая реакция:
24 часа.
Срочный выезд:
дополнительная ставка.
---
КАК СЧИТАТЬ SLA
Вот модель.
---
БАЗА
Например:
35 000 ₽
---
ПЛЮС:
Параметр Доплата
24/7 доступность +20%
SLA 2 часа +35%
Удаленный район +15–40%
Несколько объектов индивидуально
Высокая критичность +25%
---
ПРИМЕР
Гостиница:
64 камеры;
СКУД;
пожарка;
архив;
Краснодар.
---
SLA:
4 часа.
---
Цена:
85–120 тыс ₽/мес
И это нормальный рынок для качественного сервиса.
---
ТЕПЕРЬ САМОЕ ВАЖНОЕ
КАК ТЕБЕ ВЫПОЛНЯТЬ SLA БЕЗ БОЛИ
---
НЕ БРАТЬ ВСЕХ ПОДРЯД
Только:
нормальные объекты;
нормальные бюджеты;
адекватные заказчики.
---
НЕ ПРОДАВАТЬ “ДЕШЕВО”
Иначе SLA развалится.
---
ОБЯЗАТЕЛЬНО:
журнал заявок;
регламент;
чек-листы;
фотофиксация;
история обслуживания.
---
ТЕХНИЧЕСКИ ТЕБЕ НУЖНО
---
1. HELP DESK
Минимум:
Telegram;
1С;
Google Sheets.
---
Лучше:
GLPI;
Zammad;
Jira Service Desk.
---
2. БАЗА ОБЪЕКТОВ
Для каждого:
схемы;
пароли;
оборудование;
IP;
контакты;
история.
---
3. ЧЕК-ЛИСТЫ
Например:
Видеонаблюдение:
запись;
архив;
питание;
доступ;
фокус;
время.
---
4. SLA-ДОКУМЕНТ
Это обязательно.
---
ПРИМЕР СТРУКТУРЫ SLA ДОГОВОРА
---
1. Предмет SLA
Исполнитель обеспечивает техническое сопровождение
и контроль работоспособности систем безопасности объекта.
2. Время реакции
P1 — до 2 часов
P2 — до 4 часов
P3 — до 24 часов
3. Регламентные работы
— диагностика
— тестирование
— проверка журналов
— контроль архива
— проверка питания
4. Отчетность
По результатам работ предоставляется отчет.
5. Ограничения SLA
SLA не распространяется на:
— физическое повреждение оборудования
— аварии электропитания
— действия третьих лиц
— форс-мажор
---
ИТОГ
SLA — это:
не “дополнение”.
Это:
фундамент твоего нового бизнеса.
Именно SLA:
выводит тебя из монтажников;
делает recurring revenue;
дает стабильность;
повышает чек;
позволяет масштабироваться.
И это идеально совпадает с твоим профилем инженера и системного человека.
service/docs/SQL-запросы.md
+69
View File
@@ -0,0 +1,69 @@
# SQL-запросы для администрирования
## Как выполнить
1. Войдите в phpMyAdmin на хостинге
2. Выберите базу данных `j30663893_engineering`
3. Перейдите на вкладку «SQL»
4. Вставьте запрос и нажмите «Вперёд»
## Смена пароля владельца
```sql
UPDATE users
SET password_hash = '$2y$10$e0MYzXyjpJS7k0ggKtqjGOcMFU.h9S1sGqf3qJ6qJ6qJ6qJ6qJ6qO'
WHERE login = 'ваш_логин';
```
**Важно:** Замените хеш на реальный. Для генерации хеша используйте PHP:
```php
<?php echo password_hash('новый_пароль', PASSWORD_DEFAULT); ?>
```
Создайте файл `hash.php` в корне сайта с этим кодом, откройте в браузере, скопируйте хеш, удалите файл.
## Разблокировка пользователя
```sql
DELETE FROM login_attempts WHERE login = 'логин_пользователя';
```
## Активация всех кейсов на главной
```sql
UPDATE cases SET is_active = 1;
```
## Просмотр всех пользователей
```sql
SELECT id, login, role, full_name, is_active, created_at FROM users;
```
## Просмотр активных SLA контрактов
```sql
SELECT sc.id, sc.contract_number, o.name as object, sc.client_name,
sc.sla_price_monthly, sc.start_date, sc.end_date, sc.status
FROM sla_contracts sc
JOIN objects o ON o.id = sc.object_id
WHERE sc.status = 'active'
ORDER BY sc.start_date DESC;
```
## Сброс опросника (удаление черновиков)
```sql
DELETE qs, qa
FROM questionnaire_sessions qs
LEFT JOIN questionnaire_answers qa ON qa.session_id = qs.id
WHERE qs.status != 'completed';
```
## Просмотр документов и прав
```sql
-- Файлы в базе не хранятся. Проверьте папку service/docs/ на хостинге.
-- Права хранятся в service/permissions/docs_permissions.json
```
service/docs/Архетиктура бренда.md
+934
View File
@@ -0,0 +1,934 @@
Хорошо, это важный шаг — ты фактически выбираешь архитектуру бренда (brand architecture), а не просто название. От этого зависит:
как тебя воспринимают (монтажники vs инженерная компания),
как ты продаёшь SLA,
насколько легко масштабируешься по РФ.
Я разложу каждый вариант строго по твоей модели:
👉 аудит → эксплуатация → SLA → инженерный сервис → масштабирование
---
1. AegisOne Engineering
Суть позиционирования:
инженерная компания полного цикла
---
Как воспринимается рынком:
“серьёзная инженерная организация”
ближе к проектированию / эксплуатации
высокий уровень доверия B2B
---
Сильные стороны:
подходит под SLA и аудит
звучит “дорого и системно”
легко масштабируется на РФ
не привязан к монтажу
---
Слабые стороны:
не сразу понятно “сервис”
нужно объяснение через сайт/контент
---
Лучше всего подходит для:
✔ SLA обслуживание
✔ аудит объектов
✔ эксплуатация систем безопасности
✔ B2B рынок (гостиницы, склады, УК)
---
Итог:
> ❗ ЛУЧШИЙ ОСНОВНОЙ БРЕНД (ядро компании)
---
2. AegisOne Service
Суть:
сервисная эксплуатационная компания
---
Восприятие:
обслуживание
ремонт
“сервисники”
---
Сильные стороны:
понятный вход для клиентов
хорошо продаёт обслуживание
легко объяснить
---
Слабые стороны:
слишком “сервис/ремонт”
занижает статус инженера
хуже для крупных B2B объектов
---
Лучше для:
✔ абонентское обслуживание
✔ выездной сервис
✔ мелкие и средние клиенты
✔ поддержка SLA как продукт
---
Итог:
> ⚠ можно как подразделение, но не основной бренд
---
3. AegisOne Security Engineering
Суть:
инженерия безопасности (очень сильный B2B бренд)
---
Восприятие:
высокий уровень экспертизы
ближе к проектированию и системной безопасности
звучит “международно”
---
Сильные стороны:
максимальная экспертность
идеально под аудит и SLA
хорошо для РФ + будущего выхода за регион
не “монтажники”
---
Слабые стороны:
длинное название
чуть тяжеловесно в маркетинге
требует сокращений (AegisOne SE)
---
Лучше для:
✔ аудит
✔ техническая экспертиза
✔ корпоративные объекты
✔ крупные B2B сделки
✔ федеральное масштабирование
---
Итог:
> ⭐ ЛУЧШИЙ ДЛЯ ЭКСПЕРТНОСТИ И PREMIUM B2B
---
4. AegisOne Facility Security
Суть:
безопасность объектов (facility management)
---
Восприятие:
управление объектами
эксплуатация зданий
FM-компании уровня “facility management”
---
Сильные стороны:
очень сильный корпоративный сегмент
подходит для УК, ТЦ, гостиниц
легко встраивается в FM-рынок
---
Слабые стороны:
менее технический фокус
может размывать “инженерность”
ближе к управлению недвижимостью
---
Лучше для:
✔ управляющие компании
✔ гостиничные сети
✔ торговые центры
✔ facility management подрядчики
---
Итог:
> ⚠ хорошо как направление, но не ядро
---
5. AegisOne TechService
Суть:
техсервис / техническое обслуживание
---
Восприятие:
ремонтная служба
IT/техподдержка стиль
---
Сильные стороны:
простое и понятное
легко продаётся “в лоб”
подходит для мелких объектов
---
Слабые стороны:
дешёвое восприятие
не тянет премиум SLA
теряет инженерный статус
---
Лучше для:
✔ массовое обслуживание
✔ низкий чек рынок
✔ быстрые заявки
✔ простые сервисные работы
---
Итог:
> ❌ не подходит под твою стратегию роста
---
6. РЕКОМЕНТИРУЕМАЯ СТРУКТУРА БРЕНДА (ОПТИМАЛЬНАЯ)
Вот как это должно выглядеть в системе:
---
🧠 ГЛАВНЫЙ БРЕНД (основа)
AegisOne Engineering
👉 ядро:
SLA
аудит
эксплуатация
инженерный контроль
---
🔧 СЕРВИСНОЕ ПОДРАЗДЕЛЕНИЕ
AegisOne Service
👉 внутри:
выезды
ремонт
поддержка
реакция по SLA
---
🧪 ЭКСПЕРТНЫЙ КОНТУР
AegisOne Security Engineering
👉 используется для:
сайта экспертного уровня
презентаций
коммерческих предложений
крупных B2B переговоров
---
🏢 ФУТУРОЛОГИЧЕСКИЙ КОНТУР (масштаб)
AegisOne Facility Security
👉 когда выйдешь в:
УК
сети отелей
FM-контракты
---
⚙️ ТЕХПОДДЕРЖКА (НЕ ОСНОВНАЯ)
AegisOne TechService
👉 можно использовать как:
внутренний бренд
дешёвый сегмент (если вдруг нужен)
---
7. ЛУЧШАЯ СТРАТЕГИЯ (РЕАЛЬНО ПРАВИЛЬНАЯ)
Вот как это делает сильная инженерная компания:
---
AegisOne Engineering
↓
AegisOne Security Engineering (экспертиза / доверие)
↓
AegisOne Service (исполнение SLA)
↓
AegisOne Facility Security (масштаб на УК и сети)
---
8. ВАЖНОЕ РЕШЕНИЕ ДЛЯ ТЕБЯ
Если брать твою стратегию:
уход от монтажа
переход в SLA
рост до 2–3 млн+
B2B рынок
экспертность
---
ТОП-1 выбор:
✔ AegisOne Engineering
---
ТОП-2 усиление:
✔ AegisOne Security Engineering
---
НЕ РЕКОМЕНДУЮ КАК ОСНОВУ:
Service (снижает статус)
TechService (дешевит бренд)
Facility Security (узкая ниша на будущее)
---
9. ЕСЛИ ХОЧЕШЬ ДАЛЬШЕ УСИЛИТЬ БРЕНД
Я могу собрать тебе следующий уровень:
нейминг архитектуры сайта (как разложить домены/страницы)
логотип-систему (как должен выглядеть бренд инженерной компании)
упаковку КП под каждый бренд
позиционирование для тендеров
“как выглядеть как федеральный подрядчик при локальном бизнесе”
---
Если коротко:
> тебе нужен не набор названий, а система уровней доверия
И из всех вариантов:
AegisOne Engineering — фундамент бизнеса.
---
Отлично, теперь мы фиксируем **архитектуру компании как инженерной системы**, а не сайта.
Ты строишь не “фирму услуг”, а:
# AegisOne Engineering — операционную систему эксплуатации объектов
Ниже даю тебе:
1. структуру компании (как она “разложена в голове клиента”)
2. все разделы сайта / системы
3. документы (шаблоны, которые продают SLA сами)
4. сценарии взаимодействия с клиентом
5. стандарты (как ты выглядишь как федеральный подрядчик)
---
# 1. СТРУКТУРА AEGISONE ENGINEERING
## 🧠 ЯДРО КОМПАНИИ
# AegisOne Engineering
> Инженерная компания по эксплуатации и контролю систем безопасности объектов
---
## ФУНКЦИОНАЛЬНЫЕ БЛОКИ
```text
1. Engineering Audit (аудит и диагностика)
2. SLA Operations (эксплуатация)
3. Incident Response (аварийные работы)
4. Technical Supervision (контроль подрядчиков)
5. Documentation & Compliance (документация)
6. Risk Engineering (анализ рисков)
```
---
# 2. СТРУКТУРА САЙТА (КАК ДОЛЖЕН ВЫГЛЯДЕТЬ AEGISONE)
---
# 🏠 ГЛАВНАЯ
## `/`
### Название:
AegisOne Engineering
### Смысл:
> инженерная эксплуатация систем безопасности объектов
---
# 3. РАЗДЕЛЫ САЙТА
---
# 3.1 ENGINEERING AUDIT
## `/engineering-audit/`
### Описание:
```text
Технический аудит систем безопасности с оценкой рисков эксплуатации.
Проверка:
- видеонаблюдения
- СКУД
- пожарной сигнализации
- инфраструктуры объекта
Результат:
инженерное заключение и карта рисков объекта
```
---
### Подразделы:
- `/engineering-audit/video-surveillance`
- `/engineering-audit/access-control`
- `/engineering-audit/fire-alarm`
- `/engineering-audit/risk-report`
---
# 3.2 SLA OPERATIONS
## `/sla-operations/`
### Описание:
```text
Постоянное техническое сопровождение объектов с регламентами и SLA.
Мы обеспечиваем:
- стабильную работу систем
- контроль состояния оборудования
- аварийное реагирование
- регулярные проверки
```
---
### Подразделы:
- `/sla-operations/start`
- `/sla-operations/business`
- `/sla-operations/enterprise`
- `/sla-operations/sla-regulations`
---
# 3.3 INCIDENT RESPONSE
## `/incident-response/`
### Описание:
```text
Экстренное устранение неисправностей систем безопасности.
Сценарии:
- отказ видеонаблюдения
- потеря архива
- сбой СКУД
- проблемы пожарной сигнализации
```
---
### Подразделы:
- `/incident-response/critical`
- `/incident-response/emergency-call`
- `/incident-response/post-incident-report`
---
# 3.4 TECHNICAL SUPERVISION
## `/technical-supervision/`
### Описание:
```text
Контроль подрядчиков и проверка качества работ сторонних организаций.
Мы выступаем как независимый инженерный контроль объекта.
```
---
### Подразделы:
- `/technical-supervision/contractor-check`
- `/technical-supervision/acceptance-testing`
- `/technical-supervision/project-review`
---
# 3.5 DOCUMENTATION & COMPLIANCE
## `/documentation-compliance/`
### Описание:
```text
Ведение и восстановление инженерной документации объектов.
Системы:
- схемы
- журналы
- паспорта оборудования
- регламенты эксплуатации
```
---
### Подразделы:
- `/documentation-compliance/passport`
- `/documentation-compliance/regulations`
- `/documentation-compliance/reporting`
---
# 3.6 RISK ENGINEERING
## `/risk-engineering/`
### Описание:
```text
Анализ рисков эксплуатации инженерных систем безопасности объекта.
Мы оцениваем не оборудование, а последствия его отказа.
```
---
### Подразделы:
- `/risk-engineering/video-risk`
- `/risk-engineering/fire-risk`
- `/risk-engineering/access-risk`
---
# 4. ШАБЛОНЫ ДОКУМЕНТОВ (ЭТО ВАЖНЕЕ САЙТА)
Это твой “продукт доверия”.
---
# 4.1 ИНЖЕНЕРНОЕ ЗАКЛЮЧЕНИЕ
```text
AegisOne Engineering
Инженерное заключение по состоянию систем безопасности
Объект: __________
Дата: __________
1. Проведённые проверки:
- видеонаблюдение
- СКУД
- пожарная сигнализация
- инфраструктура
2. Выявленные отклонения:
- __________
- __________
3. Критические риски:
- __________
4. Оценка состояния системы:
[ ] стабильная
[ ] частично стабильная
[ ] требует вмешательства
5. Заключение инженера:
Система безопасности объекта требует/не требует
технического сопровождения по SLA модели эксплуатации.
```
---
# 4.2 SLA СОГЛАШЕНИЕ
```text
AegisOne Engineering
Service Level Agreement (SLA)
1. Объект обслуживания
2. Перечень систем
3. Время реакции:
P1 — 2 часа
P2 — 4 часа
P3 — 24 часа
4. Регламент обслуживания:
- ежемесячные проверки
- отчётность
- диагностика
5. Зоны ответственности:
- заказчик
- инженерная компания
6. Исключения:
- повреждение третьими лицами
- форс-мажор
```
---
# 4.3 АКТ ТЕХНИЧЕСКОГО АУДИТА
```text
Проверено:
- видеонаблюдение
- СКУД
- пожарная система
Результаты:
- __________
Рекомендации:
- критические
- важные
- плановые
```
---
# 4.4 ПАСПОРТ ОБЪЕКТА
```text
AegisOne Engineering
Паспорт инженерных систем объекта
Содержит:
- схема систем
- оборудование
- IP-адреса
- точки отказа
- история обслуживания
```
---
# 4.5 ОТЧЁТ ПО ИНЦИДЕНТУ
```text
Описание инцидента:
Время реакции:
Причина:
Последствия:
Устранение:
Рекомендации:
```
---
# 5. СЦЕНАРИИ ВЗАИМОДЕЙСТВИЯ
---
## СЦЕНАРИЙ 1 — ВХОД
```text
Контакт → мини-диагностика → аудит → отчет → SLA
```
---
## СЦЕНАРИЙ 2 — АВАРИЯ
```text
Инцидент → выезд → устранение → отчет → предложение SLA
```
---
## СЦЕНАРИЙ 3 — ПАРТНЁРСКИЙ ВХОД
```text
Партнёр → объект → аудит → сопровождение
```
---
## СЦЕНАРИЙ 4 — ТЕНДЕР / КОММЕРЧЕСКИЙ ВХОД
```text
Запрос → аудит → КП → SLA контракт
```
---
# 6. КАК ЭТО ВОСПРИНИМАЕТСЯ РЫНКОМ
Ты становишься не:
❌ монтажной фирмой
❌ сервисниками
❌ подрядчиком
---
А:
# 🧠 инженерной эксплуатационной системой объектов
---
# 7. ГЛАВНЫЙ ЭФФЕКТ ЭТОЙ УПАКОВКИ
## Клиент думает:
> “Это не монтажники. Это те, кто контролирует безопасность объекта как систему.”
---
# 8. СЛЕДУЮЩИЙ УРОВЕНЬ (ЕСЛИ ПРОДОЛЖАЕМ)
Я могу собрать тебе дальше:
- автоматическую CRM (Notion / 1C модель под эти разделы)
- шаблон коммерческого предложения под каждый блок
- визуальную архитектуру сайта (UI/UX)
- систему KPI инженеров
- модель масштабирования до федерального уровня
---
# ИТОГ
Ты только что получил:
> полноценную архитектуру инженерной компании уровня enterprise
И если это внедрить — ты перестаёшь быть “подрядчиком”.
Ты становишься:
# операционной системой эксплуатации объектов безопасности.
service/docs/Архитектура компании.md
+459
View File
@@ -0,0 +1,459 @@
Отлично, теперь мы фиксируем архитектуру компании как инженерной системы, а не сайта.
Ты строишь не “фирму услуг”, а:
AegisOne Engineering — операционную систему эксплуатации объектов
Ниже даю тебе:
1. структуру компании (как она “разложена в голове клиента”)
2. все разделы сайта / системы
3. документы (шаблоны, которые продают SLA сами)
4. сценарии взаимодействия с клиентом
5. стандарты (как ты выглядишь как федеральный подрядчик)
---
1. СТРУКТУРА AEGISONE ENGINEERING
🧠 ЯДРО КОМПАНИИ
AegisOne Engineering
> Инженерная компания по эксплуатации и контролю систем безопасности объектов
---
ФУНКЦИОНАЛЬНЫЕ БЛОКИ
1. Engineering Audit (аудит и диагностика)
2. SLA Operations (эксплуатация)
3. Incident Response (аварийные работы)
4. Technical Supervision (контроль подрядчиков)
5. Documentation & Compliance (документация)
6. Risk Engineering (анализ рисков)
---
2. СТРУКТУРА САЙТА (КАК ДОЛЖЕН ВЫГЛЯДЕТЬ AEGISONE)
---
🏠 ГЛАВНАЯ
/
Название:
AegisOne Engineering
Смысл:
> инженерная эксплуатация систем безопасности объектов
---
3. РАЗДЕЛЫ САЙТА
---
3.1 ENGINEERING AUDIT
/engineering-audit/
Описание:
Технический аудит систем безопасности с оценкой рисков эксплуатации.
Проверка:
- видеонаблюдения
- СКУД
- пожарной сигнализации
- инфраструктуры объекта
Результат:
инженерное заключение и карта рисков объекта
---
Подразделы:
/engineering-audit/video-surveillance
/engineering-audit/access-control
/engineering-audit/fire-alarm
/engineering-audit/risk-report
---
3.2 SLA OPERATIONS
/sla-operations/
Описание:
Постоянное техническое сопровождение объектов с регламентами и SLA.
Мы обеспечиваем:
- стабильную работу систем
- контроль состояния оборудования
- аварийное реагирование
- регулярные проверки
---
Подразделы:
/sla-operations/start
/sla-operations/business
/sla-operations/enterprise
/sla-operations/sla-regulations
---
3.3 INCIDENT RESPONSE
/incident-response/
Описание:
Экстренное устранение неисправностей систем безопасности.
Сценарии:
- отказ видеонаблюдения
- потеря архива
- сбой СКУД
- проблемы пожарной сигнализации
---
Подразделы:
/incident-response/critical
/incident-response/emergency-call
/incident-response/post-incident-report
---
3.4 TECHNICAL SUPERVISION
/technical-supervision/
Описание:
Контроль подрядчиков и проверка качества работ сторонних организаций.
Мы выступаем как независимый инженерный контроль объекта.
---
Подразделы:
/technical-supervision/contractor-check
/technical-supervision/acceptance-testing
/technical-supervision/project-review
---
3.5 DOCUMENTATION & COMPLIANCE
/documentation-compliance/
Описание:
Ведение и восстановление инженерной документации объектов.
Системы:
- схемы
- журналы
- паспорта оборудования
- регламенты эксплуатации
---
Подразделы:
/documentation-compliance/passport
/documentation-compliance/regulations
/documentation-compliance/reporting
---
3.6 RISK ENGINEERING
/risk-engineering/
Описание:
Анализ рисков эксплуатации инженерных систем безопасности объекта.
Мы оцениваем не оборудование, а последствия его отказа.
---
Подразделы:
/risk-engineering/video-risk
/risk-engineering/fire-risk
/risk-engineering/access-risk
---
4. ШАБЛОНЫ ДОКУМЕНТОВ (ЭТО ВАЖНЕЕ САЙТА)
Это твой “продукт доверия”.
---
4.1 ИНЖЕНЕРНОЕ ЗАКЛЮЧЕНИЕ
AegisOne Engineering
Инженерное заключение по состоянию систем безопасности
Объект: __________
Дата: __________
1. Проведённые проверки:
- видеонаблюдение
- СКУД
- пожарная сигнализация
- инфраструктура
2. Выявленные отклонения:
- __________
- __________
3. Критические риски:
- __________
4. Оценка состояния системы:
[ ] стабильная
[ ] частично стабильная
[ ] требует вмешательства
5. Заключение инженера:
Система безопасности объекта требует/не требует
технического сопровождения по SLA модели эксплуатации.
---
4.2 SLA СОГЛАШЕНИЕ
AegisOne Engineering
Service Level Agreement (SLA)
1. Объект обслуживания
2. Перечень систем
3. Время реакции:
P1 — 2 часа
P2 — 4 часа
P3 — 24 часа
4. Регламент обслуживания:
- ежемесячные проверки
- отчётность
- диагностика
5. Зоны ответственности:
- заказчик
- инженерная компания
6. Исключения:
- повреждение третьими лицами
- форс-мажор
---
4.3 АКТ ТЕХНИЧЕСКОГО АУДИТА
Проверено:
- видеонаблюдение
- СКУД
- пожарная система
Результаты:
- __________
Рекомендации:
- критические
- важные
- плановые
---
4.4 ПАСПОРТ ОБЪЕКТА
AegisOne Engineering
Паспорт инженерных систем объекта
Содержит:
- схема систем
- оборудование
- IP-адреса
- точки отказа
- история обслуживания
---
4.5 ОТЧЁТ ПО ИНЦИДЕНТУ
Описание инцидента:
Время реакции:
Причина:
Последствия:
Устранение:
Рекомендации:
---
5. СЦЕНАРИИ ВЗАИМОДЕЙСТВИЯ
---
СЦЕНАРИЙ 1 — ВХОД
Контакт → мини-диагностика → аудит → отчет → SLA
---
СЦЕНАРИЙ 2 — АВАРИЯ
Инцидент → выезд → устранение → отчет → предложение SLA
---
СЦЕНАРИЙ 3 — ПАРТНЁРСКИЙ ВХОД
Партнёр → объект → аудит → сопровождение
---
СЦЕНАРИЙ 4 — ТЕНДЕР / КОММЕРЧЕСКИЙ ВХОД
Запрос → аудит → КП → SLA контракт
---
6. КАК ЭТО ВОСПРИНИМАЕТСЯ РЫНКОМ
Ты становишься не:
❌ монтажной фирмой
❌ сервисниками
❌ подрядчиком
---
А:
🧠 инженерной эксплуатационной системой объектов
---
7. ГЛАВНЫЙ ЭФФЕКТ ЭТОЙ УПАКОВКИ
Клиент думает:
> “Это не монтажники. Это те, кто контролирует безопасность объекта как систему.”
---
8. СЛЕДУЮЩИЙ УРОВЕНЬ (ЕСЛИ ПРОДОЛЖАЕМ)
Я могу собрать тебе дальше:
автоматическую CRM (Notion / 1C модель под эти разделы)
шаблон коммерческого предложения под каждый блок
визуальную архитектуру сайта (UI/UX)
систему KPI инженеров
модель масштабирования до федерального уровня
---
ИТОГ
Ты только что получил:
> полноценную архитектуру инженерной компании уровня enterprise
И если это внедрить — ты перестаёшь быть “подрядчиком”.
Ты становишься:
операционной системой эксплуатации объектов безопасности.
service/docs/Блог.md
+543
View File
@@ -0,0 +1,543 @@
Хороший вопрос — блог в твоей нише (системы безопасности + SLA + B2B + обслуживание) это не “контент-маркетинг”, а:
> инструмент продажи доверия, SLA и инженерной компетентности
Если блог сделан правильно, он заменяет:
отдел продаж (частично)
коммерческие предложения (частично)
презентации
кейсы
и даже тендерные обоснования
---
1. ГЛАВНАЯ ОШИБКА БОЛЬШИНСТВА БЛОГОВ В ТВОЕЙ НИШЕ
Они делают:
“мы установили систему”
“мы молодцы”
“как выбрать камеру”
“новости компании”
👉 директору (заказчику B2B) это НЕ интересно
---
2. ЧТО ХОЧЕТ ВИДЕТЬ ДИРЕКТОР (ЗАКАЗЧИК B2B)
Директору не нужен контент.
Ему нужно:
1. Снижение риска
“у меня не сломается объект”
“меня не оштрафуют”
“у меня будет доказательная база”
---
2. Управляемость
SLA
контроль
прозрачность
ответственность
---
3. Деньги и потери
сколько стоит простой
сколько стоит отказ системы
где риски потерь
---
4. Компетентность подрядчика
понимает ли подрядчик реальные риски
умеет ли он управлять системой, а не “чинить камеры”
---
3. КАК ДОЛЖЕН БЫТЬ УСТРОЕН БЛОГ (АРХИТЕКТУРА)
BLOG AEGISONE
1. Risk Engineering (риски объектов)
2. SLA & Service (обслуживание)
3. Incident Cases (разбор аварий)
4. Infrastructure Deep Dive (техническая экспертиза)
5. Compliance / MCHS / Audit (регуляторика)
6. Economics of Security (экономика потерь)
7. Case Studies (реальные объекты)
---
4. КАТЕГОРИИ БЛОГА (ПОЛНАЯ СТРУКТУРА)
---
4.1 RISK ENGINEERING (САМАЯ ВАЖНАЯ)
Суть:
Показывает директору:
> где он уже теряет деньги, даже если всё “работает”
---
Примеры статей:
“Почему 70% объектов теряют видеодоказательства и не знают об этом”
“Что происходит, когда SLA пожарной системы формальный”
“7 скрытых точек отказа в СКУД”
---
Формат:
риск
последствия
реальные сценарии
стоимость потерь
---
Почему это продаёт:
👉 вызывает страх + осознание потерь
---
4.2 SLA & SERVICE (ТВОЯ ДЕНЕЖНАЯ КАТЕГОРИЯ)
Суть:
объясняет, почему SLA = бизнес-стабильность
---
Примеры:
“Почему обслуживание пожарной сигнализации — это не обслуживание, а юридическая ответственность”
“Как SLA снижает риск остановки бизнеса”
“Почему разовые выезды не работают”
---
Формат:
объяснение SLA
цифры
последствия без SLA
кейсы
---
4.3 INCIDENT CASES (СИЛЬНЕЙШИЙ ДОВЕРИТЕЛЬНЫЙ БЛОК)
Суть:
реальные аварии
---
Примеры:
“Как один отказ СКУД остановил склад на 14 часов”
“Пожарная система без регламента: разбор инцидента”
“Почему не работал архив видеонаблюдения 3 месяца”
---
Структура:
1. Что случилось
2. Почему это произошло
3. Какие были последствия
4. Как это выявили
5. Как исправили
6. Как избежать
---
Это:
👉 главный доверительный инструмент
---
4.4 INFRASTRUCTURE DEEP DIVE
Суть:
показывает инженерную глубину
---
Примеры:
“Как устроена современная система видеонаблюдения на объекте 10 000 м²”
“Почему сеть — это главный риск безопасности”
“UPS как критический элемент безопасности”
---
4.5 COMPLIANCE / MCHS
Суть:
работа с нормативкой
---
Примеры:
“Что проверяет МЧС в 2026 году”
“Типовые ошибки объектов при проверках”
“Почему формальное ТО приводит к штрафам”
---
4.6 ECONOMICS OF SECURITY
Суть:
деньги, потери, риск
---
Примеры:
“Сколько стоит 1 час простоя склада”
“Стоимость потери видеодоказательства”
“Почему дешёвый подрядчик обходится дороже”
---
4.7 CASE STUDIES (ОСНОВА ПРОДАЖ)
Суть:
твои реальные объекты
---
Формат:
объект
проблемы
что сделали
результат
SLA модель
---
5. КАК ДОЛЖЕН ВЫГЛЯДЕТЬ БЛОГ (UI/UX)
---
5.1 НЕ ДОЛЖНО БЫТЬ:
❌ “новости компании”
❌ “мы молодцы”
❌ маркетинговых текстов
❌ воды
---
5.2 ДОЛЖНО БЫТЬ:
Главная страница блога:
“инженерные риски”
“разбор инцидентов”
“стоимость отказов”
“кейсы объектов”
---
5.3 Визуально:
строгий технический стиль
таблицы
схемы
диаграммы
риск-блоки
---
6. КАЖДАЯ СТАТЬЯ ДОЛЖНА ПРОДАВАТЬ
---
структура статьи (обязательная):
1. Проблема
2. Реальный сценарий
3. Что происходит технически
4. Риски
5. Финансовые последствия
6. Как решается
7. Как это делает AegisOne
---
7. ПРИМЕР “ПРОДАЮЩЕЙ” СТАТЬИ
---
Заголовок:
> “Почему 80% систем видеонаблюдения не дают доказательств в момент инцидента”
---
Внутри:
потеря архива
сбои HDD
неправильная настройка
отсутствие контроля
---
Финал:
> “в AegisOne это решается через SLA мониторинг и инженерный контроль”
---
8. КАК БЛОГ ПРИВОДИТ КЛИЕНТА
---
Статья → Осознание риска → Страх потерь → Аудит → SLA контракт
---
9. ГЛАВНАЯ ЛОГИКА БЛОГА
Ты не пишешь статьи.
Ты создаёшь:
> систему формирования потребности в SLA
---
10. ЧТО ДЕЛАЕТ БЛОГ СИЛЬНЫМ (КРИТИЧНО)
---
1. РЕАЛЬНЫЕ ЦИФРЫ
потери
простои
риски
---
2. РЕАЛЬНЫЕ ИНЦИДЕНТЫ
аварии
сбои
последствия
---
3. ИНЖЕНЕРНАЯ ГЛУБИНА
схемы
логика систем
причины отказов
---
4. ЭКОНОМИКА
сколько стоит ошибка
---
11. ЧТО НЕЛЬЗЯ ДЕЛАТЬ
---
❌ SEO-статьи “для трафика”
❌ поверхностные обзоры
❌ “лайфхаки безопасности”
❌ маркетинг
---
12. ИТОГ
Правильный блог в твоей модели — это:
> “система инженерного страха + доверия + экспертизы”
---
13. ЕСЛИ РАЗВИВАТЬ ДАЛЬШЕ
Я могу дальше собрать:
30 готовых статей под твой блог (с заголовками + структурами)
SEO-структуру под Краснодарский край
Telegram-воронку из блога
автоматическое превращение статей в заявки на аудит
систему “контент → SHS влияние”
---
Если коротко:
👉 блог в твоей модели — это не контент
👉 это “машина продажи SLA через понимание риска”
service/docs/Воронка.md
+445
View File
@@ -0,0 +1,445 @@
Ок, здесь мы уже собираем не “маркетинг”, а полноценную B2B-машину:
# вход → доверие → аудит → SLA → долгий повторяющийся доход
Ты как раз в нише, где деньги делаются не на разовых монтажах, а на:
> эксплуатации + рисках + ответственности
---
# ЧАСТЬ 1. ПЕРВАЯ ВОРОНКА КЛИЕНТОВ (КРАСНОДАРСКИЙ КРАЙ)
---
# 0. ЛОГИКА ВОРОНКИ
Твоя воронка НЕ классическая:
❌ “реклама → заявка → продажа”
У тебя:
# контент → доверие → аудит → выявление проблем → SLA
---
# 1. ВХОД В ВОРОНКУ (ТОЧКИ ПРИКОСНОВЕНИЯ)
## 1.1. Локальный B2B рынок (основа)
Ты работаешь не по всей РФ, а:
- Краснодар
- Сочи
- Новороссийск
- Анапа
- Армавир
- промзоны + логистика + гостиницы
---
## 1.2. Каналы входа (без агрессивного маркетинга)
### 1) Telegram (основной канал доверия)
Контент + кейсы + разборы
---
### 2) Яндекс / Google SEO
Страницы:
- аудит систем безопасности
- SLA обслуживание
- обслуживание видеонаблюдения Краснодар
- обслуживание пожарной сигнализации
---
### 3) Партнеры (очень важно)
- электрики
- IT-аутсорс
- управляющие компании
- проектировщики
- пожарники
- строители
---
### 4) Прямые инженерные выходы
НЕ продажи.
Формат:
> “если нужен технический аудит или проверка систем — можем подключиться”
---
# 2. ПЕРВЫЙ ПРОДУКТ (ВХОД В ДЕНЬГИ)
# 🔥 Технический аудит объекта
---
## Почему это ядро воронки
Потому что:
- легко продать без давления
- низкий чек
- высокая ценность
- выявляет проблемы
- логично ведёт в SLA
---
## Цена (Краснодарский край)
- малый объект: 15–25 тыс
- средний: 25–50 тыс
- крупный: 50–100 тыс
---
## Что важно
Аудит НЕ продаёт услуги.
Он:
# показывает проблемы → создаёт необходимость SLA
---
# 3. ВТОРОЙ ЭТАП
# 🔥 “Диагностика + отчет”
После аудита:
Ты выдаешь документ:
- риски
- неисправности
- слабые места
- последствия
- рекомендации
---
## Ключевая мысль отчета:
> “Система формально работает, но не защищает объект”
---
# 4. ТРЕТИЙ ЭТАП
# 🔥 ПЕРЕХОД В SLA
---
## Это главный момент денег
Ты НЕ продаешь обслуживание.
Ты продаешь:
# “устранение рисков эксплуатации”
---
## Как выглядит оффер
> Мы берем объект на техническое сопровождение с SLA контролем состояния систем безопасности.
---
## Конверсия
Из аудита → в SLA:
- 30% слабые объекты
- 50% средние
- 10–20% сильные (очень хорошие деньги)
---
# 5. SLA (ПРОДУКТ ДЕНЕГ)
---
## Структура:
### START
25–40k
---
### BUSINESS
60–120k
---
### ENTERPRISE
150–400k
---
## Что ты продаешь на самом деле:
НЕ обслуживание
А:
# “инженерную стабильность объекта”
---
# 6. ПОЛНАЯ ВОРОНКА В ВИДЕ СХЕМЫ
```
Контент / SEO / партнеры
↓
Лид (запрос)
↓
Мини-аудит (или первичная диагностика)
↓
Полный технический аудит
↓
Отчет с рисками
↓
SLA предложение
↓
Долгосрочный контракт
```
---
# ЧАСТЬ 2. МОДЕЛЬ РОСТА ДО 2–3 МЛН ₽/МЕС RECURRENT
---
# 1. КЛЮЧЕВОЕ ПРАВИЛО
Ты не масштабируешь монтаж.
Ты масштабируешь:
# количество объектов на SLA
---
# 2. МАТЕМАТИКА МОДЕЛИ
---
## Вариант реалистичный (Краснодар → край → РФ)
### Средний чек SLA:
80 000 ₽
---
## Тебе нужно:
### 25–35 объектов
---
## Доход:
```
30 объектов × 80 000 ₽ = 2 400 000 ₽/мес
```
---
# 3. КАК ЭТО ДОСТИГАЕТСЯ
---
## ЭТАП 1 — 0–500k
Фокус:
- аудит
- первые SLA
- 5–7 объектов
---
## ЭТАП 2 — 500k–1.5M
Фокус:
- стабильные SLA
- отбор клиентов
- отказ от токсичных объектов
- первые крупные клиенты
---
## ЭТАП 3 — 1.5M–3M
Фокус:
- стандартизация
- регламенты
- техподдержка
- 2–3 инженера
- удаленный контроль
---
# 4. КЛЮЧЕВОЙ РЫЧАГ РОСТА
---
# НЕ реклама
# НЕ продажи
# А:
## “плотность объектов на инженера”
---
# 5. СИСТЕМА РОСТА
---
## 1 инженер = 8–12 объектов
---
## значит:
|Кол-во инженеров|Доход|
|---|---|
|1|0.8–1.2M|
|2|1.6–2.4M|
|3|2.4–3.6M|
---
# 6. ГЛАВНЫЕ РЫЧАГИ МАСШТАБА
---
## 1. Аудит как продукт входа
(дешево / легко / продается сам)
---
## 2. SLA как подписка
(деньги каждый месяц)
---
## 3. Контент как доверие
(заменяет рекламу)
---
## 4. Партнерки
(дают теплые объекты)
---
## 5. Отказ от дешевых клиентов
(самый важный фактор)
---
# 7. КРИТИЧЕСКИЙ МОМЕНТ
---
Если ты не сделаешь это:
> “мы не берем монтаж без SLA”
ты останешься в рынке:
- демпинга
- разовых работ
- кассовых разрывов
---
# 8. ИДЕАЛЬНАЯ ЭВОЛЮЦИЯ БИЗНЕСА
---
## Было:
монтажники
---
## Стало:
SLA + эксплуатация
---
## Будет:
# внешний инженерный отдел объектов
---
# 9. СИЛЬНЫЙ СДВИГ МЫШЛЕНИЯ
---
Ты больше не продаешь:
❌ камеры
❌ монтаж
❌ оборудование
---
Ты продаешь:
# “спокойствие собственника за техническую инфраструктуру объекта”
---
# ЕСЛИ СЖАТЬ В ОДНУ ФОРМУЛУ:
---
> Аудит → выявление рисков → SLA → долгосрочный инженерный доход
---
# ЕСЛИ ДАЛЬШЕ ДВИГАТЬСЯ
Я могу следующим шагом собрать тебе:
- точную систему продаж аудита (скрипты + сообщения)
- упаковку Telegram как лидогенератора
- CRM воронку под SLA
- регламент инженера (чтобы масштабироваться)
- финансовую модель до 5–10 млн/мес
Это уже будет не “бизнес идея”, а:
# операционная система инженерной компании.
service/docs/Воронки телеграм и crm.md
+397
View File
@@ -0,0 +1,397 @@
Отлично, это уже уровень, где бизнес начинает “дышать сам”:
Telegram → доверие → аудит → SLA → регулярный доход.
Разобьём на две системы:
# 1) Telegram как лидогенератор (не блог, а воронка)
# 2) CRM-воронка под SLA (повторяемые деньги)
---
# 1. TELEGRAM КАК ЛИДОГЕНЕРАТОР (ИНЖЕНЕРНАЯ МОДЕЛЬ)
---
## 1.1. Главная ошибка всех
Обычно делают:
- “посты про монтаж”
- “новости компании”
- “фото объектов”
👉 это НЕ генерирует SLA
---
## 1.2. Твоя роль канала
Твой Telegram — это:
# “инженерный журнал рисков объектов”
Не маркетинг. Не реклама. Не блог.
---
## 1.3. Главная цель Telegram
Не подписки.
А:
> заявки на аудит
---
# 2. СТРУКТУРА TELEGRAM-КАНАЛА
---
## 2.1. Закреп (ОБЯЗАТЕЛЬНО)
```text
Мы занимаемся инженерной эксплуатацией систем безопасности коммерческих объектов.
Перед обслуживанием всегда проводим технический аудит:
— видеонаблюдение
— СКУД
— пожарная сигнализация
— инфраструктура
Цель — выявить скрытые риски, которые не видны в ежедневной работе.
📌 Если нужно — можем провести аудит объекта и выдать инженерное заключение.
Написать: @your_contact
```
---
## 2.2. 3 типа контента (ВСЕГДА)
---
### 1) РИСКИ (60%)
👉 основа роста
Примеры:
- “Почему архив видеонаблюдения исчезает незаметно”
- “Почему пожарка работает, но не защищает”
- “3 скрытые ошибки СКУД”
---
### 2) КЕЙСЫ (25%)
👉 доверие
Примеры:
- “Аудит склада: 12 критических ошибок”
- “Гостиница без резервного питания”
---
### 3) ЭКСПЕРТИЗА (15%)
👉 статус
Примеры:
- “Как должен выглядеть нормальный SLA”
- “Что проверяет инженер, а не монтажник”
---
# 2.3. ФОРМАТ ПОСТОВ (СТАНДАРТ)
```text
1. Проблема
2. Инженерное объяснение
3. Последствия для бизнеса
4. Спокойный вывод
```
---
## Пример готового поста
```text
Большинство объектов уверены, что видеонаблюдение работает корректно.
На практике часто есть скрытая проблема — архив.
Камеры могут показывать картинку, но запись:
— не сохраняется полностью
— перезаписывается раньше срока
— теряет часть каналов
— сбоит из-за питания или дисков
Это не видно в ежедневной работе.
Проблема проявляется только после инцидента.
По сути, система существует, но не выполняет свою функцию хранения доказательной базы.
Именно поэтому видеонаблюдение нужно рассматривать как систему эксплуатации, а не просто установленное оборудование.
```
---
# 2.4. CTA (ОЧЕНЬ ВАЖНО)
Каждый 3–4 пост:
```text
Если нужно — можем провести технический аудит объекта и проверить состояние систем безопасности.
```
---
# 2.5. ЛИД-МАГНИТ (ОЧЕНЬ СИЛЬНЫЙ РЫЧАГ)
---
## PDF:
# “Чек-лист скрытых рисков систем безопасности”
или
# “10 ошибок эксплуатации объектов”
---
## Telegram пост:
```text
Мы собрали чек-лист из 10 критических ошибок, которые встречаются на большинстве объектов.
Если хотите — отправим бесплатно.
```
👉 это даёт первые контакты без давления
---
# 3. TELEGRAM → ВОРОНКА
```text
Контент
↓
Интерес
↓
Чек-лист / диалог
↓
Диагностика (мини-аудит)
↓
Полный аудит
↓
SLA
```
---
# 4. CRM-ВОРОНКА ПОД SLA
Теперь самое важное.
Ты не продаёшь “услуги”. Ты ведёшь объекты по состояниям.
---
# 4.1. СТРУКТУРА CRM (СТАДИИ)
---
## 1. ЛИД
Источник:
- Telegram
- сайт
- партнер
- холодный контакт
---
## 2. ПЕРВИЧНЫЙ КОНТАКТ
- написал / ответил
- уточнение объекта
---
## 3. КВАЛИФИКАЦИЯ
Вопросы:
- тип объекта
- системы
- есть ли подрядчик
- проблемы
---
## 4. ДИАГНОСТИКА (мини-аудит)
- быстрый осмотр
- удаленно или выезд
- выявление боли
---
## 5. ПОЛНЫЙ АУДИТ
- инженерный выезд
- отчет
- риски
---
## 6. ПРЕДЛОЖЕНИЕ SLA
- тариф
- регламент
- реакция
---
## 7. ПЕРЕГОВОРЫ
- согласование цены
- условия
---
## 8. ДОГОВОР SLA
- подписан
- объект активен
---
## 9. АКТИВНЫЙ SLA
- обслуживание
- отчёты
---
## 10. РАСШИРЕНИЕ
- новые объекты
- доп. системы
---
# 4.2. ВИЗУАЛЬНАЯ CRM-СХЕМА
```text
ЛИД
↓
КОНТАКТ
↓
КВАЛИФИКАЦИЯ
↓
МИНИ-ДИАГНОСТИКА
↓
АУДИТ
↓
SLA ОФФЕР
↓
ДОГОВОР
↓
ОБСЛУЖИВАНИЕ
↓
РАСШИРЕНИЕ
```
---
# 5. ПРОСТАЯ CRM В ТАБЛИЦЕ (СТАРТ)
Если без софта:
|Клиент|Объект|Статус|Проблема|Этап|Потенциал|
|---|---|---|---|---|---|
|X|гостиница|аудит|нет архива|прогрев|80k/мес|
---
# 6. КЛЮЧЕВОЙ ПРИНЦИП CRM
Ты не ведёшь “продажи”.
Ты ведёшь:
# инженерные объекты
---
# 7. МЕТРИКА УСПЕХА (ВАЖНО)
Не:
- подписчики
- заявки
А:
## 1 объект = SLA контракт
---
# 8. РОЛЬ TELEGRAM В МОДЕЛИ ДЕНЕГ
```text
Telegram = генератор доверия
Аудит = генератор денег входа
SLA = генератор повторного дохода
```
---
# 9. СИСТЕМА РОСТА (СВЯЗКА ВСЕГО)
```text
Контент (Telegram)
↓
Диалог
↓
Аудит
↓
SLA контракт
↓
Постоянный доход
↓
Масштаб через инженеров
```
---
# 10. СЛЕДУЮЩИЙ УРОВЕНЬ (если хочешь усилить систему)
Я могу дальше собрать тебе:
### 1. Полную CRM в Notion / 1C структуру под SLA
### 2. Скрипт “закрытия в SLA после аудита”
### 3. Таблицу квалификации клиента (кого брать/кого нет)
### 4. Финмодель роста до 3 млн+
### 5. Регламент инженера (чтобы масштабировать команду)
---
Если коротко: ты сейчас строишь не маркетинг, а:
> инженерную подписочную сервисную компанию
И Telegram + CRM — это её нервная система.
service/docs/Дашборд инженера.md
+537
View File
@@ -0,0 +1,537 @@
Ниже — полноценная модель **“Дашборд инженера (тимлид / руководитель техников)”** для AegisOne Engineering.
Это ключевой слой между:
- техник → (исполнение)
- директор → (управление системой)
Инженер тут не “старший техник”, а:
> операционный контроллер SLA, качества и рисков на объектах
---
# 1. РОЛЬ ИНЖЕНЕРА В СИСТЕМЕ
## 1.1 Основная функция
```text
Инженер = управление качеством исполнения SLA + распределение нагрузки + контроль рисков объектов
```
---
## 1.2 Он НЕ делает:
- не чинит оборудование (это техник)
- не продаёт SLA (это коммерция)
- не ведёт бухгалтерию
---
## 1.3 Он ДЕЛАЕТ:
- распределяет заявки
- контролирует SLA
- проверяет качество работ
- снижает инциденты
- управляет техниками
- влияет на SHS
---
# 2. АРХИТЕКТУРА DASHBOARD ИНЖЕНЕРА
```text
CEO DASHBOARD
↓
ENGINEER DASHBOARD
↓
TECHNICIAN DASHBOARD
↓
OBJECT SYSTEMS
```
---
# 3. DASHBOARD ИНЖЕНЕРА (REAL-TIME)
## 3.1 Главные блоки интерфейса
### Блок 1 — SLA контроль региона
- SLA compliance (%)
- просроченные заявки
- риск нарушения SLA
- критические объекты
---
### Блок 2 — команда техников
- загрузка каждого техника
- эффективность
- ошибки / reopen rate
- скорость реакции
---
### Блок 3 — инциденты
- P1 / P2 / P3
- открытые критические
- повторяющиеся аварии
---
### Блок 4 — объекты
- риск-уровень (Risk Score)
- SHS влияние объекта
- проблемные системы
---
### Блок 5 — KPI инженера
- качество управления SLA
- распределение нагрузки
- снижение инцидентов
- эффективность команды
---
# 4. PHP АРХИТЕКТУРА
---
## 4.1 API инженера
```php
<?php
header('Content-Type: application/json');
$pdo = new PDO("mysql:host=localhost;dbname=aegisone","user","pass");
$data = $pdo->query("
SELECT
e.id,
e.name,
AVG(t.sla_compliance) as sla,
COUNT(i.id) as incidents,
AVG(t.response_time) as response_time
FROM engineers e
LEFT JOIN tasks t ON t.engineer_id = e.id
LEFT JOIN incidents i ON i.engineer_id = e.id
GROUP BY e.id
")->fetchAll(PDO::FETCH_ASSOC);
echo json_encode($data);
?>
```
---
## 4.2 SHS ENGINEER IMPACT API
```php
<?php
header('Content-Type: application/json');
$pdo = new PDO("mysql:host=localhost;dbname=aegisone","user","pass");
$k = $pdo->query("
SELECT
AVG(sla_compliance) as sla,
AVG(response_time) as rt,
AVG(reopen_rate) as rr
FROM tasks
")->fetch(PDO::FETCH_ASSOC);
/* Engineer Impact on SHS */
$EIS =
(0.5 * $k['sla']) +
(0.3 * (1 - $k['rr'])) +
(0.2 * (1 - $k['rt']/10));
echo json_encode([
"ENGINEER_IMPACT_SCORE" => round($EIS * 100, 2)
]);
?>
```
---
# 5. ФОРМУЛЫ ИНЖЕНЕРА (КРИТИЧЕСКИЕ KPI)
---
## 5.1 ENGINEER CONTROL SCORE (ECS)
```text
ECS =
(0.30 × SLA Compliance Control)
+ (0.25 × Task Distribution Efficiency)
+ (0.20 × Incident Reduction Rate)
+ (0.15 × Team Performance Score)
+ (0.10 × Response Coordination Speed)
```
---
## 5.2 SLA CONTROL INDEX
```text
SCI = closed_tasks_in_SLA / total_tasks
```
---
## 5.3 TEAM LOAD BALANCE
```text
TLB = std_dev(tasks_per_engineer)
```
👉 чем меньше → тем лучше распределение
---
## 5.4 INCIDENT REDUCTION RATE
```text
IRR = (incidents_previous - incidents_current) / incidents_previous
```
---
## 5.5 ESCALATION RATE
```text
ER = escalated_tasks / total_tasks
```
---
# 6. DASHBOARD (HTML + JS)
---
## 6.1 HTML
```html
<!DOCTYPE html>
<html>
<head>
<title>Engineer Control Panel</title>
<style>
body { background:#0f172a; color:white; font-family:Arial; }
.grid {
display:grid;
grid-template-columns: repeat(3, 1fr);
gap:15px;
padding:20px;
}
.card {
background:#1e293b;
padding:15px;
border-radius:12px;
}
.big { font-size:28px; font-weight:bold; }
.green { color:#22c55e; }
.yellow { color:#facc15; }
.red { color:#ef4444; }
</style>
</head>
<body>
<h2 style="padding:20px;">Engineer Live Dashboard</h2>
<div class="grid">
<div class="card">
<div>SLA Control</div>
<div id="sla" class="big">--</div>
</div>
<div class="card">
<div>Engineer Impact (SHS)</div>
<div id="shs" class="big">--</div>
</div>
<div class="card">
<div>Incidents</div>
<div id="inc" class="big">--</div>
</div>
</div>
<div id="team"></div>
<script src="engineer.js"></script>
</body>
</html>
```
---
## 6.2 JS realtime
```javascript
async function loadEngineer(){
const res = await fetch('/api/engineer.php');
const data = await res.json();
let sla = 0;
let inc = 0;
let html = "";
data.forEach(e => {
sla += parseFloat(e.sla);
inc += parseInt(e.incidents);
let color =
e.sla > 0.9 ? "green" :
e.sla > 0.75 ? "yellow" : "red";
html += `
<div class="card">
<h3>${e.name}</h3>
<p>SLA: <b class="${color}">
${(e.sla * 100).toFixed(1)}%
</b></p>
<p>Incidents: ${e.incidents}</p>
<p>Response: ${e.response_time}</p>
</div>
`;
});
document.getElementById("team").innerHTML = html;
document.getElementById("sla").innerText =
((sla / data.length) * 100).toFixed(1) + "%";
document.getElementById("inc").innerText = inc;
let shs = (sla / data.length) * 100 - inc * 0.5;
document.getElementById("shs").innerText =
shs.toFixed(1);
}
setInterval(loadEngineer, 15000);
loadEngineer();
```
---
# 7. ДОКУМЕНТЫ ИНЖЕНЕРА (ОБЯЗАТЕЛЬНЫЕ)
---
## 7.1 РЕГЛАМЕНТ ИНЖЕНЕРА
```text
AegisOne Engineering
Engineer Operational Standard
1. Назначение
Инженер отвечает за выполнение SLA и контроль качества работ техников.
---
2. Обязанности
- распределение заявок
- контроль SLA выполнения
- контроль качества диагностики
- управление инцидентами
- предотвращение повторных аварий
---
3. Запрещено
- закрывать задачи без проверки
- игнорировать SLA нарушения
- делегировать без фиксации
```
---
## 7.2 ESCALATION MATRIX
```text
P1 → инженер → директор (немедленно)
P2 → инженер → инженер контроль
P3 → техник
Если SLA риск > 80%:
→ обязательная эскалация
```
---
## 7.3 ЧЕК-ЛИСТ ИНЖЕНЕРА
```text
AegisOne Engineering
Engineer Control Checklist
[ ] Все заявки распределены
[ ] SLA риск оценён
[ ] Техники назначены
[ ] P1 инциденты закрыты
[ ] Повторные аварии проанализированы
[ ] Отчёты проверены
```
---
## 7.4 ОТЧЁТ ИНЖЕНЕРА
```text
Engineer Report
Период:
Инженер:
---
1. SLA состояние:
-
2. Проблемные объекты:
-
3. Инциденты:
-
4. Перегруз команды:
-
5. Принятые меры:
-
6. Риски:
-
```
---
# 8. ЧТО ИНЖЕНЕР ДОЛЖЕН ИМЕТЬ В СИСТЕМЕ
---
## ОБЯЗАТЕЛЬНО:
- SLA статус всех объектов
- список техников
- инциденты P1–P3
- риск объектов
- SHS влияние
---
## РЕКОМЕНДУЕМО:
- история объектов
- схемы систем
- фото оборудования
- прошлые ремонты
- нагрузка по часам
---
# 9. ЧТО ЕМУ НЕЛЬЗЯ ДАВАТЬ
---
## КАТЕГОРИЧЕСКИ НЕ НУЖНО:
- прямые продажи
- финансовые данные прибыли
- доступ к CRM сделкам
- доступ к договорам без SLA слоя
- административные функции директора
---
# 10. РИСКИ СИСТЕМЫ
---
## РИСК 1 — инженер превращается в диспетчера
👉 решение:
- оставить KPI, а не “ручное управление”
---
## РИСК 2 — перегруз инженера
👉 решение:
- TLB (load balance)
---
## РИСК 3 — потеря SLA контроля
👉 решение:
- SHS alert system
---
# 11. ГЛАВНАЯ ЛОГИКА
```text
Техник → выполняет
Инженер → управляет качеством
Директор → управляет системой
```
---
# 12. ИТОГ
Ты получаешь:
> управляемый слой контроля SLA между исполнением и бизнесом
---
# 13. ЕСЛИ РАЗВИВАТЬ ДАЛЬШЕ
Я могу собрать:
- автораспределение заявок (AI dispatch)
- прогноз поломок объектов
- система “умного SLA риска”
- мобильный кабинет инженера
- интеграция с Telegram уведомлениями
---
Если коротко:
👉 это уже не “дашборд”
👉 это уровень операционной системы инженерного бизнеса (mini-SAP под твою нишу)
service/docs/Дашборд техника.md
+424
View File
@@ -0,0 +1,424 @@
Ниже — полноценная система **“Дашборд техника в реальном времени” + пакет документов и инструкций**, который превращает техника не в “исполнителя заявок”, а в **узел управляемой SLA-системы**.
Я разделю на 3 уровня:
1. Дашборд техника (web / PHP система)
2. Документы и регламенты (полные тексты)
3. Шаблоны (акты, чек-листы, отчёты)
---
# 1. DASHBOARD ТЕХНИКА (REAL-TIME)
## 1.1 Логика системы
```text
Заявка → Назначение → Выезд → Диагностика → Исполнение → Закрытие → SLA фиксация → SHS влияние
```
---
## 1.2 Что должен видеть техник (главное)
### Блок 1 — текущая нагрузка
- активные заявки
- срочность (P1–P3)
- дедлайн SLA
- расстояние до объекта
- статус выполнения
---
### Блок 2 — SLA контроль
- осталось времени до нарушения SLA
- критичность заявки
- штрафной риск
---
### Блок 3 — оборудование объекта
- камеры / СКУД / пожарка
- история неисправностей
- последние ремонты
---
### Блок 4 — чек-лист работ
- пошаговый регламент
- обязательные проверки
- фотофиксация
---
### Блок 5 — результат
- закрытие заявки
- причина
- подтверждение клиента
- влияние на KPI
---
# 2. PHP ДАШБОРД ТЕХНИКА (ГОТОВЫЙ ШАБЛОН)
---
## 2.1 API задач техника
```php
<?php
header('Content-Type: application/json');
$pdo = new PDO("mysql:host=localhost;dbname=aegisone","user","pass");
$stmt = $pdo->query("
SELECT
t.id,
t.title,
t.priority,
t.status,
t.deadline,
t.address,
t.system_type,
t.sla_remaining_hours
FROM tasks t
WHERE t.status != 'closed'
ORDER BY t.priority DESC, t.deadline ASC
");
echo json_encode($stmt->fetchAll(PDO::FETCH_ASSOC));
?>
```
---
## 2.2 FRONTEND (ТЕХНИК DASHBOARD)
```html
<!DOCTYPE html>
<html>
<head>
<title>Technician Panel - AegisOne</title>
<style>
body { background:#0f172a; color:white; font-family:Arial; }
.card { background:#1e293b; padding:15px; margin:10px; border-radius:10px; }
.grid { display:grid; grid-template-columns: repeat(2, 1fr); gap:10px; }
.red { color:#ef4444; }
.yellow { color:#facc15; }
.green { color:#22c55e; }
</style>
</head>
<body>
<h2 style="padding:10px;">Technician Live Dashboard</h2>
<div id="tasks"></div>
<script src="tech.js"></script>
</body>
</html>
```
---
## 2.3 JS realtime обновление
```javascript
async function loadTasks(){
const res = await fetch('/api/tech_tasks.php');
const data = await res.json();
let html = "";
data.forEach(t => {
let color =
t.sla_remaining_hours < 2 ? "red" :
t.sla_remaining_hours < 6 ? "yellow" : "green";
html += `
<div class="card">
<h3>${t.title}</h3>
<p><b>Priority:</b> ${t.priority}</p>
<p><b>Address:</b> ${t.address}</p>
<p><b>System:</b> ${t.system_type}</p>
<p><b>SLA:</b>
<span class="${color}">
${t.sla_remaining_hours}h left
</span>
</p>
<button onclick="startTask(${t.id})">Start</button>
<button onclick="closeTask(${t.id})">Close</button>
</div>
`;
});
document.getElementById("tasks").innerHTML = html;
}
setInterval(loadTasks, 10000);
loadTasks();
```
---
# 3. ДОКУМЕНТЫ ДЛЯ ТЕХНИКА (ОБЯЗАТЕЛЬНЫЕ)
---
# 3.1 РЕГЛАМЕНТ РАБОТЫ ТЕХНИКА
```text
AegisOne Engineering
Регламент работы инженера-техника
1. Общие положения
Техник обязан выполнять работы строго по SLA и чек-листу объекта.
Любое отклонение фиксируется в системе.
---
2. Прибытие на объект
- зарегистрировать прибытие в системе
- подтвердить время начала работ
- сделать фото объекта до начала работ
---
3. Диагностика
- проверить систему по чек-листу
- зафиксировать неисправности
- определить причину (если возможно)
---
4. Выполнение работ
- устранить неисправность
- не изменять конфигурацию без согласования
- использовать только разрешённые материалы
---
5. Завершение работ
- тестирование системы
- фото после выполнения
- подтверждение работоспособности
---
6. Закрытие заявки
- заполнить отчет
- указать причину неисправности
- получить подтверждение клиента (если возможно)
```
---
# 3.2 ЧЕК-ЛИСТ ВЫЕЗДА
```text
AegisOne Engineering
Checklist Technician Visit
[ ] Прибытие на объект зафиксировано
[ ] Фото “до”
[ ] Проверка питания системы
[ ] Проверка камер / датчиков
[ ] Проверка СКУД
[ ] Проверка пожарной панели
[ ] Локализация неисправности
[ ] Устранение проблемы
[ ] Тестирование системы
[ ] Фото “после”
[ ] Закрытие заявки
```
---
# 3.3 СТАНДАРТ ДИАГНОСТИКИ
```text
AegisOne Engineering
Diagnostic Standard
1. Неисправность фиксируется только после проверки:
- питания
- сети
- оборудования
- конфигурации
2. Причина должна быть классифицирована:
- Hardware
- Software
- Network
- Human error
- External factor
3. Запрещено:
- закрывать заявку без причины
- менять систему без фиксации
```
---
# 3.4 ОТЧЁТ ТЕХНИКА (ШАБЛОН)
```text
AegisOne Engineering
Technician Report
Объект:
Дата:
Техник:
---
1. Выполненные работы:
-
2. Выявленные проблемы:
-
3. Причина неисправности:
(Hardware / Software / Network / Other)
4. Что было сделано:
-
5. Результат:
[ ] Исправлено
[ ] Частично исправлено
[ ] Требует повторного выезда
6. Фото до/после:
(вложение)
7. Комментарий:
-
```
---
# 4. ОБЯЗАТЕЛЬНЫЕ ДАННЫЕ ТЕХНИКА В СИСТЕМЕ
---
## 4.1 Минимум данных
- текущие заявки
- SLA таймер
- адрес объекта
- тип системы
- приоритет
---
## 4.2 Рекомендуемые данные
- история объекта
- прошлые неисправности
- схема оборудования
- контакт ответственного
- тип неисправности по базе
---
# 5. КЛЮЧЕВАЯ ЛОГИКА СИСТЕМЫ
```text
Техник не “чинит оборудование”
Техник:
→ закрывает SLA
→ влияет на SHS
→ формирует retention
```
---
# 6. КОНТРОЛЬ РИСКОВ
---
## РИСК 1 — “закрытие без факта”
👉 решение:
- фотофиксация обязательна
---
## РИСК 2 — “ложное устранение”
👉 решение:
- reopen rate KPI
---
## РИСК 3 — перегруз техника
👉 решение:
- utilization tracking
---
## РИСК 4 — нарушение SLA
👉 решение:
- live SLA countdown
---
# 7. ИТОГОВАЯ МОДЕЛЬ
```text
CRM → SLA → TASK → TECH DASHBOARD → EXECUTION → KPI → SHS
```
---
# 8. СУТЬ СИСТЕМЫ
Ты создаёшь не “работу техника”:
> ты создаёшь управляемый процесс физической эксплуатации инфраструктуры бизнеса
---
# 9. ЕСЛИ ДАЛЬШЕ РАЗВИВАТЬ
Можно собрать:
- мобильное приложение техника (PWA)
- GPS контроль выездов
- автоакты выполненных работ
- голосовые отчёты
- AI диагностику неисправностей
- автоматическое распределение заявок
---
Если хочешь следующий шаг:
👉 я могу объединить дашборд техника + инженера + CEO в одну единую систему управления AegisOne (как ERP уровня SAP, но для твоей ниши)
service/docs/Докозательная экспертиза.md
+574
View File
@@ -0,0 +1,574 @@
Ниже — система, которая делает тебя не “компанией по безопасности”, а:
доказательным инженерным экспертом
Это ключевой переход.
Потому что рынок верит не словам, а:
> измерениям, проверкам и воспроизводимым результатам
---
0. ЧТО ТАКОЕ “ДОКАЗАТЕЛЬНАЯ ЭКСПЕРТИЗА”
Это подход, где каждое твоё утверждение:
проверяется тестом
фиксируется
документируется
повторяется на любом объекте
подтверждается результатом
---
1. ГЛАВНАЯ ИДЕЯ СИСТЕМЫ
Ты перестаёшь говорить:
❌ “у вас плохое обслуживание”
❌ “система работает неправильно”
Ты начинаешь говорить:
✔ “мы провели тест №X”
✔ “результат измерен”
✔ “отклонение от нормы”
✔ “риск подтверждён”
---
2. СТРУКТУРА СИСТЕМЫ ДОКАЗАТЕЛЬНОСТИ
3. Тест (что проверяем)
4. Методика (как проверяем)
5. Норма (как должно быть)
6. Фактический результат
7. Отклонение
8. Риск для бизнеса
9. Вывод инженера
---
3. БАЗОВЫЕ ТЕСТЫ (ЯДРО ТВОЕЙ ЭКСПЕРТИЗЫ)
---
ТЕСТ №1 — РЕАЛЬНОСТЬ АРХИВА ВИДЕОНАБЛЮДЕНИЯ
---
🔧 Методика
Выборочно проверяется запись с камер за последние:
- 1 день
- 7 дней
- 14 дней
- 30 дней
Проверяется:
- наличие записи
- непрерывность
- пропуски
- доступность воспроизведения
---
📏 Норма
запись 100% камер
непрерывность без пропусков
доступность архива согласно заявленному сроку
---
📉 Частая реальность
часть камер не пишет
архив “дыры”
перезапись раньше срока
сбои HDD
---
⚠️ Риск
> Потеря доказательной базы при инциденте
---
🧠 Заключение от тебя
> “На объекте система видеонаблюдения формально функционирует, но не гарантирует сохранность событийного архива.”
---
ТЕСТ №2 — СИНХРОНИЗАЦИЯ ВРЕМЕНИ
---
Методика
Сравнение времени:
- на камерах
- на регистраторе
- на сервере СКУД
- фактическое время события
---
Норма
отклонение ≤ 1–2 секунды
---
Часто
разрыв 2–15 минут
разные часовые зоны
нет NTP синхронизации
---
Риск
> невозможность юридически доказать момент события
---
Вывод
> “Система не обеспечивает юридически корректную фиксацию времени событий.”
---
ТЕСТ №3 — РЕЗЕРВНОЕ ПИТАНИЕ
---
Методика
Проверка:
- UPS
- время автономной работы
- отключение питания
- поведение систем
---
Норма
15–60 минут автономии минимум
---
Часто
UPS “для галочки”
не держит нагрузку
отсутствует тестирование
---
Риск
> полная остановка системы при отключении электричества
---
Вывод
> “Инфраструктура объекта не защищена от отключения электропитания.”
---
ТЕСТ №4 — ПОЛНОТА КАМЕРНОГО ПОКРЫТИЯ
---
Методика
Проверка зон:
- входы
- кассы
- периметр
- слепые зоны
---
Норма
отсутствие “мертвых зон”
---
Часто
перекрытия нет
камеры направлены неправильно
часть зон не контролируется
---
Риск
> невозможность фиксации инцидентов
---
Вывод
> “Фактическое покрытие объекта не соответствует заявленной системе безопасности.”
---
ТЕСТ №5 — ЖУРНАЛ СОБЫТИЙ СКУД
---
Методика
Проверка:
- записи проходов
- корректность пользователей
- история событий
---
Норма
полный лог всех проходов
---
Часто
потери логов
сбои базы
отключённый журнал
---
Риск
> невозможность отследить перемещения персонала
---
Вывод
> “СКУД не выполняет функцию контроля доступа в полном объёме.”
---
ТЕСТ №6 — СОСТОЯНИЕ ПИТАНИЯ СИСТЕМ
---
Методика
Проверка:
- напряжения
- нагрузки
- перегрева
- стабильности питания оборудования
---
Часто
перегрузка линий
дешёвые блоки питания
нестабильное напряжение
---
Риск
> деградация оборудования и внезапные отказы
---
Вывод
> “Система имеет скрытую деградацию по питанию.”
---
ТЕСТ №7 — СОСТОЯНИЕ ХРАНЕНИЯ ДАННЫХ
---
Методика
Проверка:
- HDD/SSD
- заполнение
- циклы перезаписи
- ошибки записи
---
Часто
диски в деградации
нет мониторинга
потеря данных без уведомлений
---
Риск
> потеря архива без внешних признаков
---
Вывод
> “Система хранения не контролируется и не мониторится.”
---
4. КАК ТЫ ПРЕЗЕНТУЕШЬ ЭТО КЛИЕНТУ
---
НЕ так:
❌ “у вас проблемы”
---
А так:
✔ “мы провели тест №3 и зафиксировали отклонение”
---
5. ШАБЛОН ТВОЕГО ЭКСПЕРТНОГО ЗАКЛЮЧЕНИЯ
ИНЖЕНЕРНОЕ ЗАКЛЮЧЕНИЕ
Объект: ________
Проведены тесты:
- архив видеонаблюдения
- синхронизация времени
- резервное питание
- СКУД
- хранение данных
Выявленные отклонения:
1. ________
2. ________
3. ________
Риски:
- ________
- ________
Заключение инженера:
Система безопасности объекта требует технического сопровождения
для обеспечения стабильной эксплуатации и снижения рисков отказов.
---
6. СИЛА ЭТОЙ СИСТЕМЫ
Ты становишься:
не монтажником
не продавцом услуг
не подрядчиком
---
А ЧЕМ?
инженером, который доказывает состояние объекта
---
7. ПОЧЕМУ ЭТО ПРОДАЁТ SLA
Потому что клиент видит:
факты
отклонения
риски
И сам приходит к выводу:
> “это нужно сопровождать постоянно”
---
8. КАК ЭТО МАСШТАБИРУЕТСЯ
Ты можешь:
обучить инженеров тестам
стандартизировать отчёты
превратить это в продукт аудита
автоматизировать CRM
---
9. СЛЕДУЮЩИЙ УРОВЕНЬ (если продолжим)
Я могу дальше собрать:
автоматический шаблон отчёта (PDF + PHP генерация)
систему балльной оценки объекта (risk scoring)
SLA-переход на основе результатов тестов
“паспорт объекта безопасности”
стандарты для инженеров в команде
---
Если коротко:
> ты превращаешь “услуги безопасности” в инженерную измеряемую систему контроля риска
И это уже не рынок монтажников.
Это рынок эксплуатационных инженеров уровня enterprise.
service/docs/Инструкция по админ-панели.md
+85
View File
@@ -0,0 +1,85 @@
# Инструкция по админ-панели AegisOne
## Вход в систему
1. Перейдите на `https://aegisone.ru/service/`
2. Введите логин и пароль, выданные владельцем
3. При 3 неверных попытках — блокировка на 3 минуты
## Дашборд
Главная страница после входа. Карточки показывают ключевые метрики:
- **Активные объекты** — количество обслуживаемых объектов
- **Активные задачи** — открытые и в работе
- **Открытые инциденты** — текущие инциденты
- **SLA контракты** — активные договоры
- **SLA Compliance** — процент соблюдения SLA
- **SHS** — общий индекс здоровья системы
Нажмите на любую карточку для перехода в соответствующий раздел.
## Управление сотрудниками (только владелец)
- Создание учётных записей с ролями: Владелец / Инженер / Техник
- Блокировка/разблокировка сотрудников
- Сброс пароля
## Объекты
- Добавление объектов с параметрами: тип, площадь, регион
- Автоматическое создание из опросника
- Просмотр Risk Score, Object Index, SLA цены
## Назначения
Привязка сотрудников к объектам. Роль сотрудника определяется автоматически из его профиля.
## SLA контракты
- Создание контрактов с привязкой к объекту
- Номер договора (для синхронизации с 1С)
- Уровень обслуживания: Start / Business / Enterprise
- Гибкое время реакции (в часах)
## Опросник объекта
Пошаговое обследование объекта:
1. **Коммерческий** — название, тип, адрес, контакты
2. **Технический** — видеонаблюдение, СКУД, пожарная сигнализация, инфраструктура
3. **Эксплуатация** — текущее обслуживание, регламенты, проблемы
4. **Риски** — критические риски объекта
5. **Расчёт SLA** — уровень обслуживания, дополнительные требования
После завершения автоматически рассчитываются: Risk Score, Complexity Index, Object Index, SLA цена.
## Блог
- Создание/редактирование статей
- **Slug** — адрес статьи, генерируется автоматически из заголовка (можно изменить вручную)
- **Категории**: Аудит, SLA, Инциденты, Технадзор, Документация, Риск-инжиниринг, Кейсы
- **Содержание** — HTML-формат. Используйте тулбар над редактором для вставки форматирования
- Статусы: Черновик → Опубликовать → Архив
## Документация
- Файлы `.md` в папке `service/docs/` автоматически обнаруживаются
- Владелец управляет доступом инженеров к каждому документу
- Инженер видит только разрешённые документы
## Примеры из практики (карусель на главной)
- Добавление кейсов с заголовком, описанием и эффектом
- Поле «Порядок» определяет порядок в карусели
- Флажок «Активен» — показывает/скрывает кейс на главной
## CEO дашборд (только владелец)
Обзор бизнес-метрик: MRR, удержание клиентов, конверсия, производительность.
## Коэффициенты формул
Все расчётные коэффициенты можно редактировать. Изменения применяются ко всем новым расчётам.
## Паспорта объектов
Автоматически генерируются при завершении опросника. Содержат полный расчёт рисков и рекомендаций.
service/docs/КП и структура аудита.md
+589
View File
@@ -0,0 +1,589 @@
Ниже — уже не просто “текст КП”, а фундамент твоей новой модели бизнеса.
Я делаю это в формате:
инженерного B2B;
без “маркетингового мусора”;
с акцентом на доверие, SLA и эксплуатацию.
Это можно:
сразу использовать;
конвертировать в PDF;
вставить на сайт;
генерировать автоматически через CRM.
---
1. ПОЛНОЦЕННЫЙ ШАБЛОН КП (.md)
# КОММЕРЧЕСКОЕ ПРЕДЛОЖЕНИЕ
## Техническое сопровождение систем безопасности
---
# AEGISONE ENGINEERING
### Эксплуатация и сопровождение систем безопасности коммерческих объектов
---
## Контакты
Телефон: +7 (XXX) XXX-XX-XX
Email: info@aegisone.ru
Сайт: https://aegisone.ru
---
# О компании
AEGISONE ENGINEERING — инженерная сервисная компания,
специализирующаяся на техническом сопровождении
и эксплуатации систем безопасности коммерческих объектов.
Мы обеспечиваем:
- стабильную работу систем;
- контроль инфраструктуры;
- регламентное обслуживание;
- SLA и контроль сроков реакции;
- технический аудит;
- сопровождение эксплуатации объектов.
---
# Какие проблемы мы решаем
Большинство неисправностей систем безопасности
выявляются только после возникновения проблем:
- отсутствует архив видеонаблюдения;
- системы работают нестабильно;
- часть оборудования неисправна;
- отсутствует документация;
- неисправности копятся месяцами;
- подрядчики не несут ответственности;
- проверки выявляют критические нарушения.
Это приводит:
- к рискам простоев;
- потере контроля;
- проблемам при проверках;
- финансовым потерям.
---
# Решение
Мы берем на себя техническое сопровождение
и контроль работоспособности систем безопасности объекта.
В рамках сопровождения обеспечиваем:
- регламентное обслуживание;
- диагностику;
- контроль состояния оборудования;
- аварийное реагирование;
- сопровождение эксплуатации;
- фотоотчетность;
- рекомендации по модернизации;
- технический контроль подрядчиков.
---
# Состав услуг
| Услуга | Описание |
|---|---|
| Регламентные проверки | Контроль состояния систем |
| Диагностика | Поиск неисправностей |
| Контроль архива | Проверка записи и хранения |
| Проверка питания | Бесперебойность работы |
| Аварийные выезды | Реагирование по SLA |
| Фотоотчетность | Подтверждение работ |
| Ведение журналов | История обслуживания |
| Консультации | Поддержка эксплуатации |
---
# SLA
| Приоритет | Описание | Время реакции |
|---|---|---|
| P1 | Полный отказ критической системы | до 2 часов |
| P2 | Частичная потеря функционала | до 4 часов |
| P3 | Некритичная неисправность | до 24 часов |
| P4 | Плановые работы | по графику |
---
# Почему выбирают нас
- более 20 лет инженерного опыта;
- лицензия МЧС;
- работа по SLA и регламентам;
- опыт эксплуатации коммерческих объектов;
- прозрачная отчетность;
- несем ответственность за результат;
- не работаем по принципу «сделали и забыли».
---
# Тарифы
## START
Для небольших объектов.
Включает:
- ежемесячный регламент;
- диагностику;
- удаленную поддержку;
- отчетность.
Стоимость:
от 25 000 ₽ / месяц
---
## BUSINESS
Для коммерческих объектов.
Включает:
- SLA;
- аварийные выезды;
- контроль архива;
- сопровождение проверок;
- фотоотчетность.
Стоимость:
от 60 000 ₽ / месяц
---
## ENTERPRISE
Формат внешнего инженерного отдела.
Включает:
- постоянное сопровождение;
- участие в эксплуатации;
- контроль подрядчиков;
- развитие инфраструктуры;
- аудит объектов.
Стоимость:
индивидуально
---
# Этапы работы
1. Предварительная консультация
2. Технический аудит объекта
3. Подготовка отчета и рекомендаций
4. Формирование SLA и регламентов
5. Постановка объекта на сопровождение
6. Регулярное обслуживание и отчетность
---
# Технический аудит
Перед постановкой объекта на сопровождение
рекомендуем проведение технического аудита.
Аудит позволяет:
- выявить скрытые проблемы;
- оценить состояние систем;
- определить риски;
- подготовить рекомендации.
---
# Контакты
AEGISONE ENGINEERING
Телефон:
+7 (XXX) XXX-XX-XX
Email:
info@aegisone.ru
Сайт:
https://aegisone.ru
---
2. СТРУКТУРА ПЕРВОГО АУДИТА
Вот здесь начинается твоя реальная экспертная модель.
ЦЕЛЬ АУДИТА
НЕ:
“найти поломку”.
А:
показать уровень инженерной зрелости объекта.
---
ЧТО ДОЛЖЕН ДАВАТЬ АУДИТ
После него клиент должен понять:
где риски;
что не работает;
что может привести к проблемам;
насколько объект управляем;
почему нужен SLA.
---
ИДЕАЛЬНАЯ СТРУКТУРА АУДИТА
---
ЭТАП 1
ВВОДНАЯ ИНФОРМАЦИЯ
---
Собираем:
тип объекта;
площадь;
количество систем;
ответственные лица;
история проблем;
подрядчики;
наличие документации.
---
ЭТАП 2
ВИЗУАЛЬНЫЙ ОСМОТР
---
Проверяем:
шкафы;
коммутацию;
маркировку;
кабельные трассы;
питание;
серверные;
доступ к оборудованию.
---
ЭТАП 3
ПРОВЕРКА РАБОТОСПОСОБНОСТИ
---
Видеонаблюдение:
запись;
архив;
синхронизация времени;
качество изображения;
доступность камер;
питание.
---
СКУД:
проходы;
журналы;
права доступа;
аварийное открытие;
контроллеры.
---
Пожарка:
индикация;
ошибки;
оповещение;
связь;
резервное питание.
---
ЭТАП 4
ПРОВЕРКА ДОКУМЕНТАЦИИ
---
Проверяем:
схемы;
пароли;
IP;
журналы;
проекты;
исполнительную документацию.
---
ЭТАП 5
ОЦЕНКА РИСКОВ
Это важнейшая часть.
---
Например:
Риск Последствие
Не пишется архив Потеря доказательств
Нет резервного питания Полный отказ
Нет документации Долгое восстановление
Ошибки пожарки Риски проверок
---
ЭТАП 6
РЕКОМЕНДАЦИИ
---
Разделяем:
Критические
Исправить срочно.
---
Важные
В течение 30 дней.
---
Плановые
При модернизации.
---
ЭТАП 7
ПРЕДЛОЖЕНИЕ SLA
Вот тут ты переводишь аудит:
в абонентское сопровождение.
---
3. ЧЕК-ЛИСТ АУДИТА
Это уже реальный инструмент продаж.
---
# ЧЕК-ЛИСТ ТЕХНИЧЕСКОГО АУДИТА
## Общая информация
- [ ] Тип объекта
- [ ] Адрес
- [ ] Ответственное лицо
- [ ] Количество систем
- [ ] Наличие документации
- [ ] Наличие подрядчиков
---
# Видеонаблюдение
## Сервер / регистратор
- [ ] Проверка записи
- [ ] Проверка архива
- [ ] Проверка HDD
- [ ] Проверка времени
- [ ] Проверка сети
- [ ] Проверка питания
## Камеры
- [ ] Наличие сигнала
- [ ] Качество изображения
- [ ] Наличие загрязнений
- [ ] Корректность обзора
- [ ] Наличие ИК подсветки
---
# СКУД
- [ ] Проверка контроллеров
- [ ] Проверка считывателей
- [ ] Проверка журналов
- [ ] Проверка доступа
- [ ] Проверка аварийного открытия
- [ ] Проверка резервного питания
---
# Пожарная сигнализация
- [ ] Проверка панели
- [ ] Проверка ошибок
- [ ] Проверка шлейфов
- [ ] Проверка оповещения
- [ ] Проверка резервного питания
- [ ] Проверка журналов событий
---
# Сетевая инфраструктура
- [ ] Проверка коммутаторов
- [ ] Проверка UPS
- [ ] Проверка кабельной инфраструктуры
- [ ] Проверка интернет-каналов
- [ ] Проверка температурного режима
---
# Документация
- [ ] Схемы
- [ ] IP-адресация
- [ ] Пароли
- [ ] Журналы обслуживания
- [ ] Исполнительная документация
---
# Риски
- [ ] Отсутствие записи
- [ ] Отказ резервного питания
- [ ] Отсутствие документации
- [ ] Ошибки оборудования
- [ ] Нестабильность сети
---
# Рекомендации
## Критические:
_________________________________
## Важные:
_________________________________
## Плановые:
_________________________________
---
САМОЕ ВАЖНОЕ
Вот что тебе нужно понять стратегически.
АУДИТ — ЭТО НЕ “ДОП. УСЛУГА”.
Это:
твоя система продаж.
Потому что:
не надо “впаривать”;
ты показываешь реальность;
ты становишься экспертом;
клиент сам понимает необходимость SLA.
И это идеально подходит под твою модель инженерного B2B.
service/docs/Контент план.md
+503
View File
@@ -0,0 +1,503 @@
Хорошо. Здесь ты фактически строишь не “контент”, а:
инженерную медийную репутацию компании
Это важно различать.
Контент в твоей нише выполняет 3 функции:
1. формирует доверие у B2B (директора, УК, собственники)
2. объясняет, почему эксплуатация важнее монтажа
3. подводит к SLA и аудитам (деньгам)
---
0. СТРАТЕГИЯ ЭКСПЕРТНОСТИ (ОСНОВА)
Твоя роль в контенте:
> “Спокойный инженер, который объясняет, где у бизнеса скрытые риски в системах безопасности”
НЕ:
продавец
маркетолог
“лиды”
“акции”
А:
диагност
эксплуатационный инженер
человек, который видит риски до аварии
---
1. КОНТЕНТ-СТОЛПЫ (PILLARS)
У тебя должно быть 5 контент-направлений:
---
1. Эксплуатационные проблемы (самый важный)
👉 “Что ломается в реальности”
Примеры:
камеры не пишут архив
пожарка работает “на бумаге”
СКУД пропускает ошибки
нет резервного питания
подрядчики исчезают
---
2. Разбор реальных кейсов (без раскрытия клиента)
👉 “Что мы нашли на объектах”
---
3. Ошибки монтажа и эксплуатации
👉 “Почему дешево = дорого”
---
4. Инженерные разборы систем
👉 “как это должно работать правильно”
---
5. Управление рисками (B2B язык)
👉 “что теряет бизнес”
---
2. ЧАСТОТА ПУБЛИКАЦИЙ
Идеально:
2 поста в неделю (Telegram / VK / VC)
1 длинная статья в неделю
1 кейс в неделю (может совпадать)
Итого: 👉 8–10 единиц контента / месяц
---
3. КОНТЕНТ-ПЛАН НА 3 МЕСЯЦА
---
МЕСЯЦ 1 — “ПРОБЛЕМЫ РЫНКА”
Цель: 👉 показать, что рынок систем безопасности работает плохо
---
Неделя 1
Пост 1
Почему камеры видеонаблюдения не защищают бизнес
Пост 2
Что происходит, когда не ведется обслуживание систем безопасности
Статья:
ТОП-7 скрытых проблем систем безопасности на коммерческих объектах
---
Неделя 2
Пост:
Почему 80% объектов не имеют реального архива видеонаблюдения
Пост:
Как подрядчики “сдают” объект и исчезают
Кейс:
“Объект без архива 4 месяца — как это обнаруживается”
---
Неделя 3
Пост:
Почему пожарная сигнализация чаще всего существует “на бумаге”
Пост:
3 ошибки, которые делают монтажники при установке СКУД
Статья:
Почему системы безопасности не работают в момент инцидента
---
Неделя 4
Пост:
Что на самом деле означает “обслуживание систем безопасности”
Пост:
Почему дешёвый монтаж всегда превращается в дорогое обслуживание
Кейс:
“Склад с критическими ошибками в системе доступа”
---
МЕСЯЦ 2 — “ЭКСПЕРТНОСТЬ”
Цель: 👉 показать, что ты знаешь, как должно быть правильно
---
Неделя 1
Пост:
Как правильно проверять видеонаблюдение на объекте
Статья:
Чек-лист эксплуатации систем безопасности для бизнеса
Кейс:
“Восстановление системы видеонаблюдения после 2 лет хаоса”
---
Неделя 2
Пост:
Что должен контролировать собственник объекта
Пост:
Почему отсутствие SLA = потеря контроля
Статья:
Как устроена правильная эксплуатация систем безопасности
---
Неделя 3
Пост:
Как проверить, работает ли ваша система безопасности реально
Пост:
Почему регламент важнее оборудования
Кейс:
“Объект после смены подрядчика”
---
Неделя 4
Пост:
Что такое инженерная эксплуатация (а не монтаж)
Статья:
Почему рынок безопасности живет в иллюзии надежности
---
МЕСЯЦ 3 — “ДОВЕРИЕ И ПЕРЕХОД В ПРОДАЖИ”
Цель: 👉 мягко переводить в аудит и SLA
---
Неделя 1
Пост:
Что показывает технический аудит объекта
Статья:
Как мы выявляем скрытые проблемы систем безопасности
Кейс:
“Аудит коммерческого объекта: 12 критических ошибок”
---
Неделя 2
Пост:
Почему бизнесу нужен внешний инженер безопасности
Пост:
Что происходит, когда нет технического контроля
Статья:
SLA в системах безопасности: зачем он нужен
---
Неделя 3
Пост:
Как выглядит нормальное техническое сопровождение
Кейс:
“Перевод объекта на SLA обслуживание”
Пост:
Почему обслуживание = защита бизнеса, а не ремонт
---
Неделя 4
Пост:
Когда нужно делать аудит (и почему его откладывают)
Статья:
Как мы снижаем эксплуатационные риски объектов
---
4. ФОРМАТ КОНТЕНТА (ВАЖНО)
Каждый пост должен иметь структуру:
---
1. Проблема
2. Реальный инженерный разбор
3. Последствия для бизнеса
4. Вывод (очень спокойный)
---
5. ПРИМЕР ЭКСПЕРТНОГО ПОСТА (ГОТОВЫЙ)
---
Тема:
“Почему камеры видеонаблюдения не защищают бизнес”
---
Видеонаблюдение часто воспринимается как система безопасности.
На практике это не всегда так.
Основная проблема заключается не в оборудовании, а в эксплуатации.
На большинстве объектов мы наблюдаем типовые ситуации:
— часть камер не записывает архив;
— запись есть, но не сохраняется нужный период;
— часть каналов отключена;
— время на устройствах не синхронизировано;
— отсутствует резервирование питания;
— система не тестируется регулярно.
В результате при инциденте система формально есть, но фактически не выполняет свою функцию.
Бизнес узнаёт об этом только постфактум.
Правильная эксплуатация видеонаблюдения — это не установка оборудования, а регулярный контроль:
— состояния записи;
— целостности архива;
— доступности камер;
— корректности времени;
— работоспособности хранения.
Без этого система превращается в формальность.
Именно поэтому в инженерной эксплуатации видеонаблюдение рассматривается как сервис, а не как установленное оборудование.
---
6. КОД ДЛЯ КОНТЕНТ-СТРАНИЦЫ (PHP БЛОГ)
---
<?php include '../header.php'; ?>
<section class="blog-post">
<div class="container">
<h1>Почему камеры видеонаблюдения не защищают бизнес</h1>
<p class="meta">Инженерный разбор систем безопасности</p>
<p>
Видеонаблюдение часто воспринимается как система безопасности...
</p>
<h2>Типовые проблемы эксплуатации</h2>
<ul>
<li>нет записи архива</li>
<li>сбои хранения</li>
<li>отсутствие резервирования</li>
<li>рассинхронизация времени</li>
</ul>
<h2>Почему это критично</h2>
<p>
Система формально работает, но не выполняет функцию защиты бизнеса.
</p>
<h2>Вывод</h2>
<p>
Без регламентной эксплуатации система безопасности превращается в формальность.
</p>
</div>
</section>
<?php include '../footer.php'; ?>
---
7. ГЛАВНЫЙ ПРИНЦИП ВСЕГО КОНТЕНТА
Ты должен повторять одну мысль:
> “Без эксплуатации система безопасности не существует”
---
8. ЧТО ЭТО ДАСТ ЧЕРЕЗ 2–3 МЕСЯЦА
Если делать системно:
тебя начнут воспринимать как эксперта;
появятся входящие заявки;
снизится необходимость продавать;
аудит станет естественным входом;
SLA станет логичным продолжением;
монтаж уйдет в фон.
---
9. СЛЕДУЮЩИЙ ШАГ (если хочешь дальше усилить)
Я могу дальше собрать тебе:
контент-воронку (как пост → аудит → SLA)
шаблоны кейсов (очень мощно работает)
систему “доказательной экспертизы”
сценарий продаж через контент
упаковку Telegram-канала под лидогенерацию
Это уже уровень:
построения сервисной B2B-машины, а не просто сайта.
service/docs/Маркеттинг.md
+673
View File
@@ -0,0 +1,673 @@
Вот здесь начинается настоящий B2B.
И это как раз твоя сильная сторона.
Потому что:
# тебе НЕ нужен агрессивный маркетинг.
Ты не:
- франшиза,
- массовый монтажник,
- “льем лиды”.
Твой рынок:
# доверительный инженерный B2B.
А там продают:
- компетенция;
- спокойствие;
- экспертность;
- репутация;
- предсказуемость.
---
# САМАЯ БОЛЬШАЯ ОШИБКА
Если ты сейчас:
- запустишь рекламу “монтаж камер”;
- начнешь конкурировать ценой;
- пойдешь в массовый трафик;
ты попадешь обратно:
# в болото монтажного рынка.
---
# ТВОЯ ИДЕАЛЬНАЯ СТРАТЕГИЯ
# “ИНЖЕНЕРНАЯ ЭКСПЕРТНОСТЬ + ЛОКАЛЬНОЕ ДОВЕРИЕ”
---
# ЧТО ТЕБЕ НУЖНО НА СТАРТЕ
НЕ:
- 100 клиентов.
А:
# 3–5 правильных объектов.
Это принципиально.
---
# ТВОЯ ЦЕЛЬ НА ПЕРВЫЕ 6 МЕСЯЦЕВ
Собрать:
- 5–10 объектов на SLA;
- с чеком 50–150 тыс.
Это уже:
# 500 тыс – 1.5 млн recurring revenue.
И это достижимо без рекламы.
---
# СТРАТЕГИЯ ПЕРВЫХ ПРОДАЖ
---
# ЭТАП 1
# НЕ ПРОДАВАТЬ ОБСЛУЖИВАНИЕ
Это критично.
Потому что: “ТО” воспринимается как:
- обязаловка;
- минималка;
- формальность.
---
# ПРОДАВАТЬ НУЖНО:
# АУДИТ И СНИЖЕНИЕ РИСКОВ.
---
# ТВОЙ ИДЕАЛЬНЫЙ ВХОД
НЕ:
> “давайте мы вас обслужим”.
А:
# “давайте проверим текущее состояние систем”.
---
# ПОЧЕМУ ЭТО РАБОТАЕТ
Ты:
- не впариваешь;
- не навязываешься;
- не демпингуешь.
Ты:
# инженер-эксперт.
---
# ЧТО ПРОДАВАТЬ ПЕРВЫМ
---
# ПРОДУКТ №1
# “ТЕХНИЧЕСКИЙ АУДИТ ОБЪЕКТА”
---
## Стоимость:
### 15–50 тыс ₽
Зависит:
- от объекта;
- площади;
- систем.
---
# ЧТО ВХОДИТ
- диагностика;
- проверка архива;
- проверка питания;
- тестирование;
- проверка документации;
- оценка рисков;
- рекомендации.
---
# РЕЗУЛЬТАТ:
PDF-отчет.
---
# ПОЧЕМУ ЭТО ГЕНИАЛЬНО ДЛЯ ТЕБЯ
Ты:
- умеешь находить проблемы;
- не любишь “продажи”;
- инженер.
То есть:
# это идеальная модель продаж под тебя.
---
# ЭТАП 2
# ПРОДАЖА SLA
После аудита.
---
# СХЕМА
## Ты показываешь:
### Сейчас:
- риски;
- неисправности;
- слабые места.
---
## Потом:
> “Чтобы это не накапливалось — нужен регламент эксплуатации.”
---
# И ТУТ ПОЯВЛЯЕТСЯ SLA
---
# КОМУ ИДТИ ПЕРВЫМИ
---
# НЕ:
- застройщики;
- тендеры;
- госка.
Это болото.
---
# ИДЕАЛЬНЫЕ ПЕРВЫЕ КЛИЕНТЫ
---
# 1. ГОСТИНИЦЫ / АПАРТЫ
(лучшая ниша для тебя)
---
## Почему:
- бардак;
- текучка;
- подрядчики пропадают;
- владельцы устали.
---
# 2. НЕБОЛЬШИЕ СКЛАДЫ
Очень хорошая ниша.
---
# 3. КОММЕРЧЕСКИЕ УК
Золото.
---
# 4. ЧАСТНЫЕ КЛИНИКИ
Отличная ниша.
---
# 5. СЕТЕВЫЕ КОМПАНИИ
Например:
- автомойки;
- рестораны;
- магазины;
- стоматологии.
---
# КАК ИСКАТЬ КЛИЕНТОВ БЕЗ РЕКЛАМЫ
Вот тут твой рынок.
---
# МЕТОД №1
# “ИНЖЕНЕРНЫЕ ЗНАКОМСТВА”
Ты недооцениваешь:
# насколько рынок маленький.
---
# ТЕБЕ НУЖНО:
- управляющие;
- инженеры эксплуатации;
- техдиры;
- собственники;
- УК.
---
# НЕ ПРОДАВАТЬ
А:
# знакомиться.
---
# ФОРМАТ
---
## Пример:
> “Мы занимаемся технической эксплуатацией систем безопасности коммерческих объектов. Если будет нужна диагностика или помощь — обращайтесь.”
---
# ВСЕ.
Никаких:
- впариваний;
- “акций”;
- скидок.
---
# МЕТОД №2
# АУДИТ КАК ВХОД
---
# ОЧЕНЬ МОЩНАЯ СХЕМА
## Предлагаешь:
# “экспресс-проверку объекта”.
---
## Например:
- проверка архива;
- отказоустойчивость;
- питание;
- документация.
---
# ПОЧЕМУ ЭТО РАБОТАЕТ
Большинство объектов:
# реально в плохом состоянии.
---
# МЕТОД №3
# LINKEDIN / TELEGRAM / VC / ДЗЕН
Это твоя золотая жила.
---
# ПОЧЕМУ
Рынок безопасности:
# чудовищно слаб по экспертности.
---
# А ТЫ:
- умеешь говорить по делу;
- инженер;
- системный.
---
# ТВОЙ КОНТЕНТ БУДЕТ ВЫДЕЛЯТЬСЯ
---
# ТЕПЕРЬ:
# КОНТЕНТ-ПЛАН НА 3 МЕСЯЦА
---
# ГЛАВНАЯ ЦЕЛЬ КОНТЕНТА
НЕ:
- “лайки”.
А:
# доверие B2B.
---
# ТВОЯ РОЛЬ В КОНТЕНТЕ
НЕ: “маркетолог”.
А:
# “спокойный инженер-эксперт”.
---
# СТИЛЬ КОНТЕНТА
---
# НЕ:
- хайп;
- кликбейт;
- “ТОП-5 камер”.
---
# А:
- реальные проблемы;
- эксплуатация;
- ошибки;
- риски;
- практика.
---
# КАНАЛЫ
---
# ОБЯЗАТЕЛЬНО:
- Telegram;
- сайт/блог;
- Яндекс Бизнес;
- VC.ru;
- Дзен.
---
# МОЖНО:
- YouTube Shorts;
- Rutube.
---
# ГЛАВНОЕ:
# не количество.
А:
# экспертность.
---
# КОНТЕНТ-ПЛАН
---
# МЕСЯЦ 1
# “ПОКАЗАТЬ ПРОБЛЕМЫ РЫНКА”
---
## Неделя 1
### Статья:
# Почему камеры не помогают в момент инцидента
---
## Пост:
5 причин потери архива видеонаблюдения.
---
## Короткое видео:
“Почему регистратор — не гарантия записи.”
---
## Кейс:
“На объекте архив не записывался 4 месяца.”
---
# Неделя 2
### Статья:
# Что реально проверяет МЧС
---
## Пост:
Почему ложные срабатывания — это не “нормально”.
---
## Видео:
3 ошибки обслуживания пожарки.
---
# Неделя 3
### Статья:
# Почему дешевый монтаж обходится дорого
---
## Пост:
Что чаще всего ломают монтажники.
---
## Фото-кейс:
“Как выглядит отсутствие эксплуатации через 2 года.”
---
# Неделя 4
### Статья:
# Что должно входить в нормальное SLA
---
## Пост:
Разница между “ТО для галочки” и эксплуатацией.
---
## Видео:
“Почему подрядчики исчезают после монтажа.”
---
# МЕСЯЦ 2
# “ПОКАЗАТЬ ЭКСПЕРТНОСТЬ”
---
# Темы:
- как проверить архив;
- как проверить подрядчика;
- как принимать объект;
- чек-лист эксплуатации;
- ошибки СКУД;
- проблемы гостиниц;
- проблемы складов.
---
# МЕСЯЦ 3
# “ФОРМИРОВАНИЕ ДОВЕРИЯ”
---
# Темы:
- реальные кейсы;
- аудиты;
- сравнения;
- “что нашли на объекте”;
- эксплуатационные риски;
- инженерные решения.
---
# КАК ЧАСТО ПУБЛИКОВАТЬ
---
# ИДЕАЛЬНО:
## 2–3 поста в неделю.
---
# НЕ НУЖНО:
- каждый день;
- “активность ради активности”.
---
# САМОЕ ВАЖНОЕ
Контент должен вызывать мысль:
> “Эти люди реально понимают эксплуатацию объектов.”
---
# ЧТО ДАСТ РЕЗУЛЬТАТ БЫСТРЕЕ ВСЕГО
---
# 1. АУДИТЫ
---
# 2. КЕЙСЫ
---
# 3. РАЗБОРЫ ОШИБОК
---
# 4. УЗКАЯ НИША
Например:
- гостиницы;
- склады.
---
# 5. ЛИЧНЫЙ БРЕНД ИНЖЕНЕРА
Вот это критично.
---
# ТЕБЕ НЕ НУЖНО БЫТЬ “ПРОДАВЦОМ”
Тебе нужно быть:
# человеком, которому доверяют сложный объект.
---
# ВАЖНОЕ ПОНИМАНИЕ
Твои клиенты:
- не ищут “самых дешевых”;
- не хотят “маркетинг”.
Они хотят:
# “нормального ответственного подрядчика”.
И рынок сейчас чудовищно голоден на таких людей.
service/docs/Опросник-расчет.md
+1087
View File
File diff suppressed because it is too large Load Diff
service/docs/Основа.md
+1518
View File
File diff suppressed because it is too large Load Diff
service/docs/Сайт и упаковка.md
+1417
View File
File diff suppressed because it is too large Load Diff
service/docs/Скрипты продаж.md
+340
View File
@@ -0,0 +1,340 @@
Ниже — тебе не “скрипты продаж”, а инженерная система входа в аудит, адаптированная под Краснодарский край и B2B-реальность (УК, гостиницы, склады, собственники).
Главная идея:
> Ты не продаёшь аудит. Ты предлагаешь проверку рисков объекта.
---
1. ПСИХОЛОГИЯ ПРОДАЖ АУДИТА (ВАЖНО)
Что продаёт аудит на самом деле:
снижение рисков проверок (МЧС, внутренние, страховые)
уверенность, что система реально работает
снятие ответственности с менеджера/собственника
“независимое мнение инженера”
---
Что НЕ работает:
“проверим камеры”
“сделаем диагностику”
“обслуживание дешевле”
---
Рабочая позиция:
> “Мы делаем техническую проверку систем безопасности объекта с выдачей инженерного заключения по рискам эксплуатации.”
---
2. ВХОД В ПРОДАЖУ (3 КАНАЛА)
---
2.1 Холодный вход (самый важный в регионе)
Кому пишем:
гостиницы
апарт-отели
склады
УК
коммерческая недвижимость
---
2.2 Тёплый вход (через знакомства)
электрики
IT
строители
подрядчики
проектировщики
---
2.3 Вход через контент
Telegram / статьи / кейсы
---
3. СТРУКТУРА ПРОДАЖИ АУДИТА
---
1. Контакт
2. Короткое позиционирование
3. Выявление боли
4. Предложение аудита
5. Подтверждение логики
6. Назначение выезда
---
4. ХОЛОДНЫЙ СКРИПТ (ТЕКСТ + WA / TG)
Вариант 1 — максимально инженерный (основной)
Добрый день.
Мы занимаемся техническим сопровождением систем безопасности коммерческих объектов в Краснодарском крае.
Перед тем как брать объекты на обслуживание, обычно делаем технический аудит:
— проверка видеонаблюдения (архив, запись, питание)
— проверка СКУД
— проверка пожарной сигнализации
— оценка рисков эксплуатации
По практике, на большинстве объектов выявляются скрытые проблемы, которые не видны в ежедневной работе.
Если у вас есть задача понять текущее состояние систем — можем провести аудит и дать инженерное заключение по рискам.
Подскажите, у вас сейчас системы на обслуживании или “как есть работают”?
---
Почему это работает:
нет продажи
есть диагностика
есть статус эксперта
есть вопрос (диалог)
---
5. ВТОРОЙ СООБЩЕНИЕ (если отвечают “работает/есть подрядчик”)
Понял.
В таких случаях чаще всего проблема не в “работает/не работает”, а в том, что:
— архив не проверяется регулярно
— резервирование не тестируется
— часть оборудования работает нестабильно
— нет объективного контроля состояния
А это всплывает обычно в момент инцидента или проверки.
Мы как раз делаем аудит, который показывает такие скрытые вещи до проблем.
Если интересно — можем сделать экспресс-проверку объекта с коротким отчётом по рискам.
---
6. КОНВЕРСИЯ В АУДИТ (КЛЮЧЕВОЙ МОМЕНТ)
Можем сделать так:
— выезд инженера
— проверка всех систем
— фиксация состояния
— короткий инженерный отчёт
— список рисков и рекомендаций
Обычно это занимает 1–2 дня в зависимости от объекта.
По стоимости — от 15 до 50 тыс, зависит от объёма систем.
Если удобно — могу уточнить объект и сказать точнее по формату.
---
7. СКРИПТ ДЛЯ ГОЛОСА (ЕСЛИ ЗВОНЯТ)
структура:
1. Позиционирование (10–15 сек)
Мы занимаемся техническим сопровождением систем безопасности коммерческих объектов.
Перед обслуживанием всегда делаем аудит состояния систем.
---
2. Боль
На большинстве объектов, которые мы смотрим, есть скрытые проблемы — архив, питание, доступ, пожарка.
Обычно это не видно в ежедневной работе.
---
3. Переход
Поэтому предлагаем сначала сделать техническую проверку объекта и дать инженерное заключение.
---
4. Закрытие
Если вам актуально — можем согласовать выезд инженера и формат проверки.
---
8. ОБРАБОТКА ВОЗРАЖЕНИЙ
---
❌ “У нас уже есть подрядчик”
Понял.
Аудит как раз часто показывает, что объект обслуживается формально, но без проверки ключевых параметров:
архив, резервирование, ошибки, питание.
Мы не конкурируем с подрядчиком — мы даём независимую оценку состояния систем.
---
❌ “Дорого”
Аудит не про “сделать дешевле”.
Это проверка рисков, которые могут стоить дороже:
— потеря архива
— отказ системы
— проблемы при проверках
Поэтому стоимость зависит от масштаба объекта, но обычно это разовая диагностика, а не постоянные расходы.
---
❌ “Нам не нужно”
Понял.
На практике аудит нужен не всегда “сейчас”, а когда появляются сомнения в стабильности систем или перед проверками.
Если актуализируется — можем подключиться.
---
9. СИСТЕМА ДОГРЕВА (ЕСЛИ НЕ КУПИЛИ СРАЗУ)
Через 3–5 дней:
Добрый день.
Подскажите, актуально ли сейчас техническое обследование систем безопасности?
По опыту, на объектах часто всплывают вопросы по архиву и резервированию, которые лучше проверить заранее, чем в момент инцидента.
---
10. МИКРО-CRM ЛОГИКА (ВАЖНО)
Каждый контакт делишь на:
не ответил
думает
есть подрядчик
отказ
сделал аудит
ушёл в SLA
---
11. КЛЮЧЕВОЙ МЕХАНИЗМ ПРОДАЖ
Твоя система должна работать так:
контакт → инженерная диагностика → выявление рисков → логичный переход в SLA
---
12. ПОЧЕМУ ЭТО РАБОТАЕТ ИМЕННО В КРАСНОДАРСКОМ КРАЕ
Рынок региона:
много частных объектов
слабая эксплуатация систем
подрядчики “формальные”
мало инженерных компаний уровня SLA
👉 значит: ты не конкурируешь по цене — ты создаёшь новый тип услуги
---
13. ЕСЛИ ДАЛЬШЕ УСИЛИВАТЬ СИСТЕМУ
Следующий уровень, который я могу тебе собрать:
скрипт “закрытия в SLA после аудита”
таблица квалификации клиента (кого брать/кого нет)
CRM-воронка под SLA (по стадиям)
шаблон отчёта аудита (который продаёт сам себя)
шаблон договора SLA (который не торгуется)
И это уже будет не продажи.
Это будет:
инженерная коммерческая система повторяемого дохода.
service/docs/УТП и КП.md
+556
View File
@@ -0,0 +1,556 @@
Сейчас мы выходим на ключевой этап.
Потому что:
УТП — это не “красивый текст”.
Это:
твоя позиция на рынке.
Именно здесь определяется:
будешь ли ты конкурировать ценой;
попадешь ли в “монтажников”;
или станешь инженерным B2B подрядчиком.
---
ГЛАВНАЯ ОШИБКА РЫНКА
Все пишут:
“качественный монтаж”;
“20 лет опыта”;
“индивидуальный подход”.
Это не УТП.
Это информационный шум.
---
ТВОЕ РЕАЛЬНОЕ ПРЕИМУЩЕСТВО
Ты НЕ:
продавец оборудования;
бригада монтажников;
дешевый подрядчик.
Ты:
инженерная сервисная компания.
И продавать нужно:
ответственность;
стабильность;
контроль;
снижение рисков;
эксплуатацию;
прозрачность.
---
ТВОЕ ОСНОВНОЕ УТП
Вот сильная база.
---
AEGISONE — инженерное сопровождение систем безопасности коммерческих объектов.
Мы не просто устанавливаем оборудование.
Мы берем на себя ответственность за стабильную работу систем безопасности объекта.
Работаем с коммерческой недвижимостью, гостиницами, складами, производствами и сетевыми объектами.
Обеспечиваем:
— регламентное обслуживание;
— SLA и контроль сроков реакции;
— технический аудит;
— восстановление проблемных объектов;
— сопровождение эксплуатации;
— прозрачную отчетность и контроль инфраструктуры.
Если система безопасности нужна не «для галочки», а для реальной работы объекта — мы подходим.
---
ПОЧЕМУ ЭТО СИЛЬНО
Тут нет:
“лучших цен”;
“монтажа под ключ”;
“любых работ”.
Это:
позиция эксперта.
---
ДОПОЛНИТЕЛЬНЫЕ УТП ДЛЯ РАЗНЫХ СЕГМЕНТОВ
---
ДЛЯ ГОСТИНИЦ
Обеспечиваем стабильную работу систем безопасности гостиниц и апарт-отелей без постоянного контроля со стороны управляющего.
Берем на себя техническое сопровождение:
— видеонаблюдения;
— СКУД;
— пожарной сигнализации;
— сетевой инфраструктуры.
Работаем по SLA и регламентам.
---
ДЛЯ СКЛАДОВ И ЛОГИСТИКИ
Снижаем риски потери архива, отказов систем и простоев инфраструктуры складских объектов.
Контролируем работоспособность:
— видеонаблюдения;
— контроля доступа;
— периметра;
— сетевой инфраструктуры.
Обеспечиваем регламентное обслуживание и аварийное реагирование.
---
ТЕПЕРЬ САМОЕ ВАЖНОЕ
СТРУКТУРА КОММЕРЧЕСКОГО ПРЕДЛОЖЕНИЯ
Большинство КП на рынке — мусор.
Там:
список оборудования;
цены;
таблицы;
“надежные решения”.
B2B это НЕ читает.
---
ТВОЕ КП ДОЛЖНО ПРОДАВАТЬ:
СПОКОЙСТВИЕ И КОНТРОЛЬ.
---
ИДЕАЛЬНАЯ СТРУКТУРА КП ДЛЯ ТЕБЯ
---
1. ТИТУЛЬНАЯ СТРАНИЦА
---
Заголовок:
Коммерческое предложение
по техническому сопровождению систем безопасности
---
Подзаголовок:
Для:
гостиницы;
склада;
коммерческого объекта;
производства.
---
Внизу:
логотип;
контакты;
дата.
---
2. КРАТКО О ПРОБЛЕМЕ
Это критически важно.
---
Пример:
---
Большинство неисправностей систем безопасности выявляются только после возникновения проблем:
— отсутствует архив видеонаблюдения;
— часть оборудования не функционирует;
— отсутствует документация;
— подрядчики не несут ответственности;
— неисправности накапливаются месяцами.
Это приводит к рискам простоев, потере контроля и проблемам при проверках.
Для снижения этих рисков необходимо регулярное техническое сопровождение и контроль состояния инфраструктуры объекта.
---
ПОЧЕМУ ЭТО СИЛЬНО
Ты:
не “продаешь услуги”;
а показываешь проблему бизнеса.
---
3. ЧТО ТЫ ПРЕДЛАГАЕШЬ
---
Заголовок:
Решение
---
Пример:
---
AEGISONE обеспечивает техническое сопровождение и контроль работоспособности систем безопасности объекта.
Мы берем на себя:
— регламентное обслуживание;
— диагностику;
— аварийное реагирование;
— технический контроль;
— сопровождение эксплуатации;
— контроль подрядчиков;
— отчетность и рекомендации.
---
4. ЧТО ВХОДИТ В ОБСЛУЖИВАНИЕ
Вот здесь уже конкретика.
---
Пример структуры:
Услуга Описание
Регламентные проверки Проверка состояния оборудования
Контроль архива Проверка записи и хранения
Аварийные выезды Реагирование по SLA
Диагностика Поиск неисправностей
Отчетность Фото и рекомендации
Поддержка Консультации персонала
---
5. SLA
Очень важно.
---
Пример:
Приоритет Время реакции
Критическая авария до 2 часов
Частичный отказ до 4 часов
Плановая заявка до 24 часов
---
6. ПОЧЕМУ ИМЕННО ВЫ
Вот тут нельзя писать банальности.
---
ПРАВИЛЬНО:
---
Почему заказчики работают с нами:
— более 20 лет инженерного опыта;
— лицензия МЧС;
— работа по регламентам и SLA;
— прозрачная отчетность;
— опыт эксплуатации сложных объектов;
— несем ответственность за результат;
— не работаем по принципу «сделали и забыли».
---
7. СТОИМОСТЬ
Очень важный блок.
---
НЕ ДЕЛАЙ:
“от 5000 ₽”.
---
ПРАВИЛЬНО:
Тариф Формат Стоимость
START Небольшие объекты от 25 000 ₽
BUSINESS Коммерческие объекты от 60 000 ₽
ENTERPRISE Внешний инженерный отдел индивидуально
---
8. ЭТАПЫ РАБОТЫ
Это резко повышает доверие.
---
Пример:
1. Технический аудит объекта
2. Формирование регламентов
3. Подписание SLA
4. Постановка объекта на сопровождение
5. Регулярное обслуживание и отчетность
---
9. CTA
Очень важно.
---
НЕ:
“оставьте заявку”.
---
ПРАВИЛЬНО:
Предлагаем провести технический аудит объекта и подготовить рекомендации по снижению эксплуатационных рисков.
---
КАК ДОЛЖНО ВЫГЛЯДЕТЬ КП ВИЗУАЛЬНО
---
НЕ:
“цветастая реклама”;
“маркетинговый шум”.
---
А:
спокойный инженерный документ.
---
ЦВЕТА
темно-синий;
графит;
белый;
серый.
---
СТИЛЬ
Как:
техническая компания;
инженерный аудит;
эксплуатация объектов.
---
САМОЕ ВАЖНОЕ
Твое КП должно вызывать мысль:
> “Эти люди понимают, как работает объект.”
А не:
> “Очередные монтажники.”
---
И ТУТ КЛЮЧЕВОЙ МОМЕНТ
Ты не должен пытаться понравиться всем.
Тебе нужны:
нормальные объекты;
нормальные бюджеты;
нормальные заказчики.
---
ТВОЯ СТРАТЕГИЯ
Не:
“много дешевых клиентов”.
А:
“мало, но качественных объектов на абонентке”.
Это огромная разница в бизнес-модели.
---
Следующий логичный этап:
1. Сделать полноценный шаблон КП (PDF-структуру).
2. Прописать тарифы глубже.
3. Сделать SLA-документ.
4. Подготовить скрипт инженерной продажи.
5. Сделать структуру первого аудита.
6. Составить чек-листы.
7. Построить первую воронку клиентов в Краснодарском крае.
8. Подготовить SEO-структуру сайта.
9. Разработать контент-план для выхода в экспертность.
10. Построить модель роста до 1–3 млн/мес recurring revenue.
service/docs/Формулы и расчёты.md
+157
View File
@@ -0,0 +1,157 @@
# Формулы и расчёты AegisOne
## 1. Risk Score (Оценка риска объекта)
**Формула:** Сумма весов выявленных нарушений
| Нарушение | Коэффициент (по умолч.) |
|-----------|------------------------|
| Нет архива видеонаблюдения | 25 |
| Нет резервного питания | 20 |
| Нет регламента обслуживания | 15 |
| Частые сбои систем | 20 |
| Нет документации | 10 |
**Максимум:** 100 баллов
**Интерпретация:**
- 0–20: Низкий
- 21–50: Средний
- 51–75: Высокий
- 76–100: Критический
---
## 2. Complexity Index (Сложность обслуживания)
**Формула:** Сумма баллов по компонентам
| Компонент | Значение | Коэффициент |
|-----------|----------|-------------|
| Камеры | до 20 | 10 |
| Камеры | 20–100 | 20 |
| Камеры | 100+ | 35 |
| Точки СКУД | до 5 | 10 |
| Точки СКУД | 5–20 | 20 |
| Точки СКУД | 20+ | 30 |
| Пожарная | Простая | 15 |
| Пожарная | Средняя | 25 |
| Пожарная | Сложная (>5000 м²) | 40 |
| IT-инфраструктура | Есть | 10 |
**Интерпретация:**
- до 30: Простой
- 31–70: Средний
- 71–120: Сложный
- 120+: Enterprise
---
## 3. Infrastructure Load (Нагрузка на инфраструктуру)
| Параметр | Состояние | Коэффициент |
|----------|-----------|-------------|
| Сервер | Нет | 15 |
| Сервер | Слабый | 10 |
| Сеть | Нестабильная | 20 |
| Сеть | Частично | 10 |
| UPS | Нет | 20 |
| UPS | Слабый | 10 |
---
## 4. Service History (История обслуживания)
| Состояние | Коэффициент |
|-----------|-------------|
| Не обслуживается | 30 |
| Нерегулярно | 20 |
| Формальный подрядчик | 10 |
| Есть SLA | 0 |
---
## 5. Object Index (Итоговый индекс объекта)
**Формула:**
```
Object Index = Risk × 0.4 + Complexity × 0.3 + Infra × 0.2 + History × 0.1
```
**Классы:**
- A (до 30): Лёгкий SLA
- B (31–60): Стандарт SLA
- C (61–90): Сложный SLA
- D (90+): Enterprise / Высокий риск
---
## 6. SLA Price (Стоимость SLA)
**Формула:**
```
SLA Price = Base Cost × Object Index × Region Factor × Risk Multiplier
```
| Параметр | Значение |
|----------|----------|
| Base Cost | 15 000 ₽ |
| Region Factor | Краснодар 1.0 / Край 1.1 / РФ 1.3 / Удалённые 1.6 / Москва 1.8 |
**Risk Multiplier:**
- Низкий риск: 1.0
- Средний: 1.3
- Высокий: 1.6
- Критический: 2.0
---
## 7. Engineer Score (ES)
**Формула:** Взвешенная сумма компонентов
| Компонент | Вес |
|-----------|-----|
| SLA Compliance | 0.25 |
| Response Time Score | 0.20 |
| Resolution Time Score | 0.20 |
| Diagnosis Accuracy | 0.15 |
| Reopen Rate Score | 0.10 |
| Risk Coverage Score | 0.10 |
**Грейды:**
- 90+: Senior
- 80–89: Strong
- 70–79: Middle
- <70: Junior
---
## 8. SHS (System Health Score)
**Формула:**
```
SHS = SLA Stability × 0.22 + Revenue Stability × 0.18 + Retention × 0.18
+ Engineer Performance × 0.15 + Incident Stability × 0.12
+ Sales Flow × 0.10 + Operational Efficiency × 0.05
```
**Статусы:**
- 85+: Growth
- 70–84: Stable
- 50–69: Risk
- <50: Crisis
---
## Автоматические правила
| Условие | Действие |
|---------|----------|
| SHS < 70 | Снизить продажи, запустить аудит, пересмотреть назначения |
| SLA Compliance < 90% | Заморозить неприоритетные проекты, увеличить частоту проверок |
| Retention < 90% | Обязательный аудит клиентов, пересмотр назначений |
---
Все коэффициенты можно изменить в разделе **Коэффициенты** админ-панели. Изменения применяются к новым расчётам.
service/docs/Цифровая модель общая.md
+458
View File
@@ -0,0 +1,458 @@
Ниже — единая цифровая операционная модель AegisOne Engineering в формате .md.
Это не просто документация — это “скелет системы”, который можно отдать разработчику, внедрить в Notion/Bitrix/1C/веб-CRM или развернуть как внутренний продукт.
---
# AegisOne Engineering
## Unified Digital Operating System (UDOS)
---
# 0. СУТЬ СИСТЕМЫ
AegisOne UDOS — это единая цифровая система управления инженерной эксплуатацией объектов безопасности.
Она объединяет:
- CRM (клиенты и сделки)
- SLA (контракты и обслуживание)
- KPI инженеров (исполнение)
- SHS (здоровье бизнеса)
- Финансовую модель
- Операционный дашборд
---
# 1. АРХИТЕКТУРА СИСТЕМЫ
┌──────────────────────┐
│ LEADS / CRM │
└─────────┬────────────┘
↓
┌──────────────────────┐
│ AUDIT SYSTEM │
└─────────┬────────────┘
↓
┌──────────────────────┐
│ SLA CONTRACTS │
└─────────┬────────────┘
↓
┌─────────────────────────────────────────┐
│ OPERATIONS (ENGINEERS) │
└─────────┬───────────────┬──────────────┘
↓ ↓
┌──────────────┐ ┌─────────────────────┐
│ KPI ENGINEERS │ │ INCIDENT SYSTEM │
└──────┬───────┘ └─────────┬───────────┘
↓ ↓
┌─────────────────────────────────────────┐
│ SHS ENGINE │
└──────────────┬──────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ CEO DASHBOARD │
└─────────────────────────────────────────┘
---
# 2. CRM СИСТЕМА
## 2.1 Структура клиента
```json
Client {
id,
company_name,
object_type,
location,
contact_person,
decision_maker,
number_of_objects,
systems: {
video: int,
access_control: int,
fire_alarm: bool,
it_infrastructure: bool
},
current_provider,
pain_points[],
budget_level,
status: [lead, qualified, audit, offer, sla, lost]
}
---
2.2 Воронка CRM
Lead
↓
Qualification
↓
Technical Audit
↓
Risk Report
↓
SLA Offer
↓
Contract
↓
Active SLA
---
3. AUDIT SYSTEM (ИНЖЕНЕРНЫЙ ВХОД)
3.1 Формирование Risk Score
Risk Score =
missing_archive (25)
+ no_power_backup (20)
+ no_regulations (15)
+ system_failures (20)
+ no_documentation (10)
---
3.2 Output аудита
Audit Report:
- Risk Score
- System condition
- Critical vulnerabilities
- SLA recommendation
- Cost estimation
---
4. SLA СИСТЕМА
4.1 Формула стоимости
SLA Price =
Base Cost × Object Index × Region Factor × Risk Multiplier
---
4.2 Object Index
Object Index =
(Risk × 0.4)
+ (Complexity × 0.3)
+ (Infrastructure × 0.2)
+ (Service History × 0.1)
---
4.3 SLA уровни
Class Index Description
A 0–30 simple SLA
B 31–60 standard SLA
C 61–90 complex SLA
D 90+ enterprise SLA
---
4.4 SLA метрики
Response Time
Resolution Time
Uptime %
Incident Rate
---
5. KPI СИСТЕМА ИНЖЕНЕРОВ
5.1 Engineer Score
ES =
(0.25 × SLA Compliance)
+ (0.20 × Response Time Score)
+ (0.20 × Resolution Time Score)
+ (0.15 × Diagnosis Accuracy)
+ (0.10 × Reopen Rate Score)
+ (0.10 × Documentation Quality)
---
5.2 KPI метрики
SLA Compliance
closed_in_SLA / total_requests
Reopen Rate
reopened_requests / total_requests
Diagnosis Accuracy
confirmed_faults / found_faults
Utilization
working_hours / available_hours
---
5.3 Грейды инженеров
Score Level
90–100 Senior
80–89 Strong
70–79 Middle
<70 Junior
---
6. SHS (SYSTEM HEALTH SCORE)
6.1 Формула SHS
SHS =
(0.22 × SLA Stability)
+ (0.18 × Revenue Stability)
+ (0.18 × Retention)
+ (0.15 × Engineer Performance)
+ (0.12 × Incident Stability)
+ (0.10 × Sales Flow)
+ (0.05 × Operational Efficiency)
---
6.2 Интерпретация
SHS Status
85–100 Growth
70–85 Stable
50–70 Risk
<50 Crisis
---
6.3 Alert System
SHS ↓ 5% weekly → Warning
SHS ↓ 10% → Critical
Retention drop → Immediate audit trigger
---
7. INCIDENT SYSTEM
7.1 Incident Classification
Level Description
P1 critical system failure
P2 partial failure
P3 minor issue
---
7.2 Incident Rate
IR = incidents / number_of_objects
---
7.3 SLA breach tracking
breach_rate = failed_SLA_cases / total_cases
---
8. FINANCIAL LAYER
8.1 MRR
MRR = Σ SLA contracts / 12
---
8.2 Revenue per Engineer
RPE = SLA Revenue / number_of_engineers
---
8.3 Cost per Object
CPO = total_operational_cost / number_of_objects
---
9. CEO DASHBOARD
9.1 Main indicators
SHS (system health)
MRR (monthly recurring revenue)
SLA Compliance
Retention
Incident Rate
Engineer Score Avg
Sales Conversion
---
9.2 Dashboard visualization blocks
1. SHS Line Chart
trend over time
2. SLA Heatmap
engineers vs performance
3. MRR Growth Curve
monthly recurring revenue
4. Client Retention Funnel
drop-off points
5. Incident Map
problematic objects
6. Engineer Ranking Table
top/bottom performers
---
10. AUTOMATION RULES
10.1 If SHS drops
IF SHS < 70:
reduce new sales
trigger audit cycle
reassign engineers
---
10.2 If SLA compliance drops
IF SLA < 90%:
freeze non-critical projects
increase inspection frequency
---
10.3 If retention drops
IF retention < 90%:
mandatory client audit
review engineer assignments
---
11. SYSTEM BEHAVIOR MODEL
DATA → KPI → SHS → DECISION → ACTION → FEEDBACK LOOP
---
12. STRATEGIC PRINCIPLE
AegisOne Engineering is not a service company.
It is:
> an operating system for managing engineering risk in physical infrastructure.
---
13. END STATE MODEL
The system evolves into:
predictive SLA risk detection
automated pricing
engineer auto-allocation
client churn prediction
MRR forecasting
---
END OF SYSTEM
---
Если хочешь следующий уровень, я могу собрать тебе:
1) визуальный UI дашборда (как он должен выглядеть как продукт)
2) структуру базы данных (SQL / 1C / Bitrix schema)
3) алгоритм “предикта потери клиента за 14 дней”
4) или автоматический генератор КП + SLA из этой системы
Это уже уровень **enterprise SaaS, а не просто инженерной компании**.
service/docs/автоматическая_система_SHS.md
+629
View File
@@ -0,0 +1,629 @@
Ниже — как должна работать автоматическая система SHS (System Health Score) в твоей модели AegisOne Engineering.
Это уже не “аналитика бизнеса”, а:
> инженерная система раннего предупреждения о деградации компании
---
0. ЧТО ТАКОЕ SHS (СУТЬ СИСТЕМЫ)
SHS — это единый индекс здоровья бизнеса (0–100), который показывает:
насколько стабильно работает SLA-модель
где теряются деньги
где растут риски разрыва контрактов
где перегружается команда
где падает качество эксплуатации
---
1. ЛОГИКА СИСТЕМЫ SHS
Данные (CRM + SLA + инженеры)
↓
Нормализация метрик
↓
Взвешивание показателей
↓
Расчёт SHS
↓
Детектирование отклонений
↓
Сигналы риска (alerts)
---
2. ФИНАЛЬНАЯ ФОРМУЛА SHS
SHS =
(0.22 × SLA Stability Index) +
(0.18 × Revenue Stability Index) +
(0.18 × Retention Index) +
(0.15 × Engineering Performance Index) +
(0.12 × Incident Stability Index) +
(0.10 × Sales Flow Index) +
(0.05 × Operational Efficiency Index)
---
3. РАСШИФРОВКА ВСЕХ КОМПОНЕНТОВ
---
3.1 SLA STABILITY INDEX (критический)
Смысл:
Насколько система выполняет SLA без сбоев.
---
Формула:
SSI = SLA_compliance × (1 - SLA_breach_severity)
---
Где:
SLA_compliance = выполненные заявки / все заявки
SLA_breach_severity = тяжесть нарушений (0–1)
---
Пример:
compliance = 0.96
нарушения = 0.1
→ SSI = 0.864
---
Риски:
падение ниже 0.85 = начинается утечка клиентов
---
3.2 REVENUE STABILITY INDEX
Смысл:
Стабильность денежного потока SLA
---
Формула:
RSI = 1 - (σ(MRR) / mean(MRR))
---
Интерпретация:
чем меньше колебания → тем выше индекс
---
Риски:
RSI < 0.7 → нестабильная финансовая модель
---
3.3 RETENTION INDEX (очень критично)
Формула:
RI = retained_clients / total_clients
---
Дополнение:
штраф за уход крупных клиентов:
RI_adjusted = RI - (lost_key_clients × 0.1)
---
Риски:
падение ниже 0.9 = системная проблема SLA
---
3.4 ENGINEERING PERFORMANCE INDEX
Смысл:
качество работы инженеров
---
Формула:
EPI =
(0.3 × SLA compliance engineers) +
(0.25 × diagnosis accuracy) +
(0.2 × reopen rate inverse) +
(0.15 × response time score) +
(0.1 × documentation quality)
---
Важный момент:
это единственный KPI, который напрямую влияет на:
> удержание клиентов
---
Риски:
EPI < 0.75 → будущие потери клиентов через 1–2 месяца
---
3.5 INCIDENT STABILITY INDEX
Смысл:
насколько система “ломается”
---
Формула:
ISI = 1 - (incidents / objects × severity_weight)
---
Где severity_weight:
критический = 1.0
средний = 0.5
низкий = 0.2
---
Риски:
рост ISI вниз = деградация инфраструктуры
---
3.6 SALES FLOW INDEX
Смысл:
здоровье входящего потока денег
---
Формула:
SFI = (audits → SLA conversion rate) × lead quality
---
Пример:
конверсия 0.35
качество лидов 0.8
→ SFI = 0.28
---
Риски:
SFI < 0.25 → нет роста MRR
---
3.7 OPERATIONAL EFFICIENCY INDEX
Смысл:
насколько эффективно работает компания внутри
---
Формула:
OEI = revenue / (engineer_hours × cost)
---
Риски:
падение → перегруз команды
---
4. ИНТЕРПРЕТАЦИЯ SHS
---
SHS Состояние системы
85–100 масштабируемый рост
70–85 стабильная работа
50–70 скрытые проблемы
<50 системный кризис
---
5. ГЛАВНАЯ СИЛА SHS — НЕ ЧИСЛО, А ДИНАМИКА
---
ВАЖНО:
Ты смотришь не на значение, а на:
Δ SHS (изменение)
ΔSHS = SHS_today - SHS_last_week
---
Критично:
падение > 5 пунктов за неделю → тревога
падение > 10 → кризис
---
6. СИСТЕМА АВТОМАТИЧЕСКИХ СИГНАЛОВ
---
GREEN ZONE:
SHS > 80
нет действий
---
YELLOW ZONE:
SHS 65–80
👉 действия:
проверить инженеров
проверить SLA просадки
проверить загрузку
---
RED ZONE:
SHS < 65
👉 действия:
аудит клиентов
пересмотр инженеров
срочный анализ SLA нарушений
заморозка новых продаж
---
7. КОГДА ПОЯВЛЯЮТСЯ РИСКИ
---
РИСК №1 — падение EPI
Причина:
инженеры начали “делать быстро, но плохо”
Симптом:
рост повторных заявок
жалобы клиентов через 2–3 недели
---
РИСК №2 — рост INCIDENT RATE
Причина:
старое оборудование
плохая эксплуатация
---
РИСК №3 — падение RETENTION
Самый опасный
👉 означает:
> клиент уже не верит системе
---
РИСК №4 — нестабильный SFI
Причина:
слабый маркетинг
неправильный аудит
некачественные лиды
---
РИСК №5 — падение OEI
Причина:
перегруз инженеров
хаотичные выезды
нет стандартизации
---
8. КАК ИСПРАВЛЯТЬ РИСКИ
---
ЕСЛИ ПАДАЕТ SHS:
---
ШАГ 1 — локализация
разбить SHS на компоненты:
где падение?
SLA?
инженеры?
продажи?
---
ШАГ 2 — точечное вмешательство
проблема действие
EPI падает обучение инженеров + чек-листы
retention падает аудит объектов
SLA падает перераспределение нагрузки
SFI падает фильтрация лидов
---
ШАГ 3 — стабилизация
ограничить новые продажи
усилить контроль SLA
снизить нагрузку
---
9. ВАЖНОЕ ПРАВИЛО СИСТЕМЫ
---
> нельзя “растить бизнес”, если SHS падает
---
10. ВИЗУАЛИЗАЦИЯ SHS (CEO DASHBOARD)
---
1. SHS LINE
📈 динамика здоровья компании
---
2. STACKED INDEX CHART
SLA
Revenue
Engineers
Retention
---
3. ALERT MAP
🟥 проблемные зоны
---
4. ENGINEER IMPACT MAP
📍 какой инженер влияет на SHS
---
11. ГЛАВНЫЙ СМЫСЛ SHS
---
Ты больше не управляешь:
❌ людьми
❌ объектами
❌ заявками
---
Ты управляешь:
системой стабильности инженерного бизнеса
---
12. ЕСЛИ ДАЛЬШЕ РАЗВИВАТЬ
Я могу собрать:
автоматический SHS калькулятор (Excel / 1C / web)
real-time dashboard
систему предиктивных предупреждений (падение SHS за 7–14 дней)
интеграцию SHS в KPI инженеров
систему автоматического “замедления продаж” при риске
---
ИТОГ
SHS — это не метрика.
> это “нервная система” твоей компании, которая заранее показывает, где бизнес начнёт терять деньги или клиентов
---
Если хочешь дальше, следующий логичный шаг:
сделать тебе полноценную цифровую модель AegisOne (дашборд + CRM + SHS + SLA + KPI инженеров в одной системе)