За время работы с ELMA365 наша команда участвовала в десятках проектов внедрения — от стартовых до тех, где требовалось исправлять последствия неудачного запуска. На основе этого опыта мы выделили 7 типичных ошибок. Три связаны с бизнес-процессами, три — с инфраструктурой, одна — с организацией проекта.
Ошибки в процессах решает интегратор. Инфраструктурные — системный администратор. Но знать о них полезно обеим сторонам: когда бизнес-процессы настроены правильно, а платформа сбоит из-за сервера, теряют время все.
Ошибки в бизнес-процессах
1. Автоматизация без предварительного анализа
Компания приобретает лицензии, разворачивает платформу и сразу переносит в неё процесс согласования договоров. При этом до внедрения процесс не был формализован: каждый участник действовал по-своему, часть решений принималась устно.
Автоматизация фиксирует существующий порядок работы. Если этого порядка нет — платформа воспроизводит хаос. Сотрудники быстро находят способы обходить систему, и она превращается в формальность.
Решение. До начала работы в ELMA365 необходимо описать процесс: сначала «как есть», затем «как должно быть». На наших проектах аналитика занимает 30–40% бюджета внедрения. Это не избыточная мера — переделка автоматизированного процесса обходится значительно дороже, чем качественная проработка на старте.
2. Попытка автоматизировать всё одновременно
На старте заказчик формирует список из 10–15 процессов: CRM, документооборот, заявки на отпуск, заказ пропусков, согласование счетов. Ожидание — запустить всё за один проект.
На практике одновременная проработка более 2–3 процессов снижает качество каждого из них. Каждый процесс требует интервью с участниками, моделирования, настройки, тестирования и обучения. При распылении ресурсов результат — набор полуготовых процессов, которыми сотрудники не пользуются.
Решение. Начать с 2–3 процессов, выбранных по двум критериям: максимальная текущая проблема и видимый результат для руководства. Пилотный этап занимает 2–4 недели. После запуска — сбор обратной связи и переход к следующей группе процессов.
3. Отсутствие внутреннего владельца платформы
После завершения проекта интегратор передаёт систему заказчику. Если в компании нет сотрудника, ответственного за развитие платформы, ELMA365 останавливается в развитии. Новые процессы не появляются, существующие не оптимизируются, пользователи возвращаются к прежним инструментам.
Это не обязательно выделенная штатная единица. Достаточно одного сотрудника, который понимает принципы low-code, знает бизнес-процессы компании и имеет полномочия вносить изменения. ELMA365 позволяет решать до 80% задач без привлечения разработчика.
Решение. Определить внутреннего владельца платформы до начала проекта. Включить его обучение в бюджет. На наших проектах мы передаём экспертизу: проводим обучение, документируем настройки, показываем как вносить изменения самостоятельно.
Ошибки в инфраструктуре
Серверная часть — техническая специализация, поэтому здесь кратко. Однако последствия технических ошибок мы наблюдаем регулярно: бизнес-процессы работают корректно, но платформа нестабильна по причинам, не связанным с настройкой процессов.
4. Платформа не работает после перезагрузки сервера
ELMA365 on-premise использует Kubernetes-кластер (KinD) внутри Docker-контейнера. Для корректной работы кластера требуются определённые параметры ядра Linux. Если администратор применил их временно, но не сохранил в конфигурации ОС, после перезагрузки сервера платформа внешне выглядит работоспособной, однако внутренние компоненты не функционируют.
Подробнее о настройке sysctl и других сетевых требованиях — в статье нашего партнёра Константина Тютюнника из IT For Prof.
5. Истечение внутренних сертификатов через год после установки
Внутренние сертификаты Kubernetes-кластера ELMA365 выпускаются сроком на один год. По истечении этого срока появляются ошибки: TLS handshake timeout, обрывы соединений, невозможность загрузки файлов. Симптомы напоминают сетевые проблемы, и поиск причины может занять значительное время.
Важно: стандартная команда обновления HTTPS-сертификата (--reload-cert) эту проблему не решает — требуется обновление именно внутренних сертификатов кластера.
6. Отсутствие мониторинга инфраструктуры
Без системы мониторинга IT-отдел узнаёт о проблемах от пользователей. Контейнер запущен, страница входа открывается — формально «всё работает». При этом очередь RabbitMQ переполнена или PostgreSQL исчерпал лимит соединений.
ELMA365 Enterprise поддерживает мониторинг через Prometheus и Grafana на уровне платформы. Инфраструктурный уровень (диски, сертификаты, базы данных) требует отдельных инструментов — Zabbix или аналогов.
Организационная ошибка
7. Отсутствие бюджета на развитие
Внедрение — начало работы с платформой, а не завершение проекта. После запуска первых процессов появляются запросы на доработки, новые интеграции, обучение дополнительных сотрудников. Если бюджет исчерпан на этапе первичного внедрения, развитие останавливается.
Рекомендация. Закладывать на поддержку и развитие платформы 20–30% от стоимости первоначального внедрения ежегодно. Эти средства покрывают доработку процессов, обучение новых сотрудников и адаптацию системы под изменения в бизнесе.
Итоги
| № | Ошибка | Зона ответственности |
|---|---|---|
| 1 | Автоматизация без анализа процессов | Интегратор, аналитик |
| 2 | Одновременный запуск всех процессов | Интегратор, руководитель проекта |
| 3 | Нет внутреннего владельца платформы | Заказчик, интегратор |
| 4 | Некорректная настройка ОС | Системный администратор |
| 5 | Просроченные сертификаты кластера | Системный администратор |
| 6 | Отсутствие мониторинга | Системный администратор |
| 7 | Отсутствие бюджета на развитие | Руководство, интегратор |
По вопросам внедрения и настройки бизнес-процессов ELMA365 — свяжитесь с нами.
