Что такое on-premise CRM? Что на самом деле значит хранить данные в компании

Пример: представьте текстильного производителя в Бурсе. Политика группы требует, чтобы данные клиентов и заказов не покидали инфраструктуру компании. Отделу продаж нужна CRM, но ИТ не одобряет предложенное облачное решение. Спор застревает не на самой программе, а на том, где она работает.

Тогда у компании остаётся два пути: отказаться от CRM или запустить CRM на своей инфраструктуре. On-premise это название второго пути. Бывают и смешанные варианты: приложение работает в одном месте, файлы в другом. Тогда на вопрос «это on-premise?» отвечают по уровням.

Для пользователя разница чаще всего незаметна: менеджер так же входит из браузера или телефона и открывает ту же карточку клиента. Разница за экраном. Чей сервер, чей диск, кто делает резервные копии, кто ставит обновления? On-premise переносит ответы на эти вопросы внутрь компании.

Данные не хранятся в одном месте. Есть база данных с записями клиентов, файлы договоров и предложений, а также резервные копии того и другого. Сказать «наши данные в компании» значит, что все эти уровни под контролем компании. Бывают установки, где база данных стоит на вашем сервере, а резервная копия уходит куда-то ещё, поэтому вопрос нужно задавать отдельно для каждого уровня.

То, что данные остаются в компании, само по себе ещё не безопасность. Серверная может быть заперта, но если все входят под одной учётной записью администратора, кто что видел, всё равно неясно.

Нужно задать ещё один вопрос: могут ли данные покинуть сервер? Если пользователь может выгрузить список клиентов и отправить его на личную почту, местоположение сервера само по себе не защищает. Выгрузки и скачивания тоже должны фиксироваться.

Ответ на один вопрос тоже должен быть в договоре: если служба поддержки подключается к вашему серверу удалённо, когда и с чьего разрешения открывается это подключение и фиксируется ли оно?

• Политика группы не допускает выхода данных за пределы компании.
• Договор с госорганом или крупным клиентом оговаривает, где должны храниться данные.
• У компании уже есть серверная и IT-отдел, который её обслуживает.
• Данные клиентов должны оставаться в той же внутренней сети, что и другие системы.

On-premise подходит далеко не всем. Для небольшой компании без ИТ-отдела обслуживание сервера, его электропитание и резервное копирование становятся дополнительной нагрузкой; такой компании облачный вариант обычно даёт меньше работы. Решение не стоит принимать по привычке; оно должно исходить из политики и возможностей компании.

При решении положите на стол вопрос: если этот сервер однажды ночью остановится, кто поднимет его утром? Если ответ это одно имя и подменить этого человека некому, решение об on-premise неполное.

На собственном сервере есть частая ловушка: программу устанавливают, а потом никто её не обновляет. Версия устаревает, копятся патчи безопасности, и в итоге программа не открывается на новом телефоне. Это часто упускаемая разница между облаком и on-premise: в облаке обновления делает провайдер, а на собственном сервере кто-то должен взять это на себя.

Команда Corex360 выполняет обновления по плану, составленному вместе с вами, а примечания к версиям открыто публикуются на странице «Новое». План входит в договор на установку CRM на собственном сервере.

Пункты, которые нужно проверить в договоре на установку, ясны: кто готовит сервер, по какому плану ставятся обновления, куда делается резервная копия, как проверяется восстановление и к кому обращаться при проблеме. Если эти пункты не записаны, свой сервер со временем превращается в сервер без хозяина.

Пример: представьте сервер дистрибьюторской компании: резервная копия делается на внешний диск, который стоит в том же шкафу. Если шкаф зальёт водой, пропадут оба. Или учётную запись уволившегося сотрудника не закрыли, и никто этого не заметил. В обоих случаях данные находятся в компании; в обоих случаях защиты не хватает.

У безопасности есть и сторона непрерывности. Сделать резервную копию мало; восстановление нужно проверить. Резервная копия, которую ни разу не проверяли, может не сработать при настоящем сбое.

На вашем собственном сервере Corex360 работает с тем же уровнем безопасности, что и в Corex360 Cloud: входы, устройства, скачивания и изменения прав фиксируются, доступ строится по ролям; на собственном сервере место хранения резервных копий определяете вы. О необычном событии владелец учётной записи узнаёт сразу. Весь уровень по пунктам описан на странице безопасности Corex360.

Ценность журнала доступа зависит от того, кто его читает. Если журнал ведут, но никто в него не смотрит, необычное скачивание заметят, только когда будет поздно. Поэтому рядом с журналом нужен порядок оповещений.

Решение о размещении фиксируется в договоре Corex360. Если позже понадобится сменить размещение, это обсуждается при пересмотре договора.

На демо мы сопоставим оба варианта с вашей корпоративной политикой. Для пользователей разницы между двумя вариантами не видно: та же карточка клиента, те же правила, тот же утренний отчёт. Что означает выбор размещения с точки зрения KVKK (турецкий закон о защите персональных данных, сопоставимый с GDPR и российским 152-ФЗ), мы разобрали через понятия оператора данных и обработчика в статье об облаке и собственном сервере с точки зрения KVKK.