Представьте, что у вашей команды свой сервер — и одна буква на той стороне
Коротко
CRM на отдельном сервере даёт руководителю ясность: данные команды не лежат рядом с чужими, понятно, в какой стране они хранятся, кто к ним допущен и кто отвечает со стороны поставщика. Но безопасность это не делает автоматически — нужны обновления, резервные копии, журнал доступа и понятные правила. Решают это руководитель, юрист и служба безопасности, а не сама идея сервера.
Тишина рядом — тоже защита.
Этот сигнал — мысленный эксперимент. Не описание чьего-то продукта и не совет немедленно что-то менять. Попробуйте на несколько минут представить, где на самом деле живёт работа вашей команды, и посмотреть, какие вопросы появятся. Рамка та же, что в сигнале про «Алфавит»: сначала сцена, потом — честно о границах.
Представьте
У вашей команды свой сервер. Не «аккаунт в большой системе», а отдельная машина, на которой лежит только ваше: переписка, клиенты, база, история договорённостей.
Рядом никого. Нет соседней компании, чьи данные хранятся в той же среде. Нет чужой нагрузки, из-за которой у вас всё тормозит в понедельник утром. Нет общей ошибки, которая одним обновлением задевает всех сразу. Если что-то случится, оно случится у вас — и только у вас. Это неприятно, но понятно.
Внутри правила задаёте вы. Кто из команды видит какие разговоры, кто может выгружать, кто только читает. Посторонних в этом списке нет.
А на той стороне — у поставщика — один человек. Назовём его «K». Он знает вашу команду, помнит, что вы просили в прошлый раз, и не меняется от обращения к обращению. Любое изменение на вашем сервере приходит через него. Не через случайного дежурного, не через безымянный поток заявок — через «K».
Звучит почти как сюжет. Но если убрать антураж, остаётся простой вопрос: вы знаете, где лежит работа вашей команды и кто стоит по ту сторону?
Как обычно бывает
Теперь та же команда в обычной жизни. CRM — общая система на тысячи компаний. Ваши данные лежат где-то в ней. Где именно, в какой стране — написано в договоре мелким шрифтом, если написано вообще.
Однажды утром система не открывается. Не у вас — у всех. Вы ничего не меняли, но ждёте, как и все.
Вы пишете в поддержку. Отвечает человек, который видит вашу компанию впервые. Вы объясняете, как у вас всё устроено. Через неделю — снова, но уже другому человеку. На вопрос «кто из ваших сотрудников может видеть нашу переписку» приходит вежливый общий ответ.
Никто не виноват. Просто так устроена общая система: она удобна, пока не нужно ответить на конкретный вопрос.
Что меняется
Изоляция: чужих рядом нет
Главное в отдельном сервере — не мощность и не статус, а отсутствие соседей. Если рядом нет чужих данных, нет и случайной утечки «через соседа», общей ошибки на всех, чужого всплеска нагрузки. Поэтому такая система закрыта не потому, что её прячут, а потому, что показывать наружу нечего: внутри — только ваша работа.
Доступ определяет команда
В общей системе права часто выглядят как набор готовых ролей, придуманных для всех сразу. На своём сервере вопрос звучит иначе: кто именно из ваших людей видит что. Не «менеджер видит своих клиентов» в общем виде, а конкретно — этот отдел, эти разговоры, эта выгрузка. Как думать о доступах внутри команды, мы разбирали в сигнале о безопасности клиентской базы.
Буква на той стороне
Постоянный контакт у поставщика — не вежливость, а управляемость. Один человек, который знает вашу команду, — это одна точка, через которую к вам приходят изменения. Её можно спросить, что поменялось и почему. С ней можно договориться о порядке: что меняется только по согласованию, что фиксируется письменно, кто подменяет, если «K» в отпуске.
Понятно, где лежат данные
Страна хранения — не формальность. От неё зависят требования закона, ответы на проверки и спокойствие крупных клиентов, которые спросят об этом сами. Когда сервер один и ваш, ответ можно дать одной фразой, а не пересказом чужого регламента.
Понятно, кто отвечает
Когда что-то идёт не так, важно не только «починят ли», но и «кто». У отдельного сервера с постоянным контактом есть адрес ответственности. Это упрощает и разговор с поставщиком, и проверку юриста или службы безопасности: на вопросы «где», «кто» и «как фиксируется» есть конкретные ответы.
Можно уйти с данными
Своё — значит забираемое. Заранее стоит знать, в каком виде вы получите базу и переписку, сколько это займёт и что произойдёт с копиями у поставщика после ухода. Выход, о котором договорились на берегу, стоит дешевле любого спора потом.
Где граница
У эксперимента есть пределы. Если их не назвать, красивая идея превращается в ложное спокойствие.
Свой сервер не делает безопасность автоматически. Его нужно обновлять, резервировать и наблюдать. Нужны люди, которые за это отвечают, и журнал, в котором видно, кто и когда заходил. Заброшенный отдельный сервер опаснее ухоженной общей системы.
Технический доступ есть почти всегда. Администратор, поставщик, площадка, где стоит машина. Спросите прямо: у кого технический доступ к серверу, при каких условиях им пользуются и как это фиксируется. Обещание «никто не имеет доступа» почти никогда не бывает буквальным. Честный ответ звучит иначе: кто, когда и по каким правилам.
Это дороже и требует порядка внутри. Отдельная среда стоит больше общей. И она не исправит хаос в команде: если доступы раздаются «на всякий случай», а уволенным их не закрывают, свой сервер просто сохранит этот хаос в изоляции.
Закон о данных — с юристом. Где можно хранить персональные данные клиентов, какие нужны согласия и уведомления, что требуется при передаче данных за границу — зависит от страны и отрасли. Это вопрос к юристу, а не к статье.
Как подойти к этому без инструмента
Переезжать на свой сервер не обязательно. Полезнее ответить на вопросы, из которых вырос этот эксперимент. Часть из них — к поставщику, часть — к себе.
К поставщику:
- В какой стране и на какой площадке физически лежат наши данные?
- Лежат ли они в одной среде с данными других компаний?
- У кого из ваших людей есть технический доступ к нашим данным, и как фиксируется каждый вход?
- Кто наш постоянный контакт и кто подменяет его?
- Как вы сообщаете об изменениях и сбоях — заранее или после?
- Как часто делаются резервные копии и когда их последний раз проверяли восстановлением?
- В каком формате и за какой срок мы получим данные, если уйдём, и что станет с копиями?
К себе:
- Кто в команде решает, кто что видит, — и записано ли это где-нибудь?
- Кто у нас отвечает за отношения с поставщиком по вопросам данных?
- Сможем ли мы за один день ответить юристу или крупному клиенту, где лежит наша переписка?
Если на большую часть вопросов ответа нет, дело не обязательно в сервере. Возможно, сначала стоит навести порядок в требованиях к системе — об этом сигнал о том, как выбрать CRM для мессенджеров.
Чек-лист: где живёт работа команды
- Известно, в какой стране и на какой площадке лежат данные
- Понятно, делят ли данные среду с другими компаниями
- Записано, кто в команде что видит и кто это решает
- Известно, у кого технический доступ у поставщика и как он фиксируется
- Есть журнал доступа, и команда может его посмотреть
- Есть постоянный контакт у поставщика и тот, кто его подменяет
- Изменения на стороне поставщика согласуются и фиксируются письменно
- Резервные копии делаются и проверяются восстановлением
- В договоре описан выход: формат данных, сроки, судьба копий
- Юрист видел, где и как хранятся персональные данные клиентов
Говорят, где-то так уже работают. Мы не подтверждаем. И не опровергаем.
Всё остальное мы обсуждаем лично. Не в статье.
Чем меньше рядом чужого, тем понятнее, за что вы отвечаете.
Вопросы и ответы
Чем CRM на отдельном сервере отличается от облачной?
В общей облачной системе данные многих компаний живут в одной среде, и вы делите с соседями её ошибки, нагрузку и обновления. На отдельном сервере среда только ваша: соседей нет, и проще ответить, где лежат данные и кто к ним допущен. Взамен больше обязанностей — кто-то должен обновлять, резервировать и следить.
Безопаснее ли свой сервер для клиентской базы?
Сам по себе — нет. Он убирает часть рисков, связанных с соседями, но не защищает от слабых паролей, забытых доступов, устаревшего ПО и отсутствия резервных копий. Безопасность складывается из порядка: обновления, копии, журнал доступа и люди, которые за это отвечают.
Кто имеет доступ к данным на выделенном сервере?
Почти всегда кто-то, кроме вашей команды: администратор, поставщик, иногда площадка, где стоит сервер. Обещание «никто не имеет доступа» редко бывает буквальным. Важно другое: кто именно, когда, по каким правилам и где это фиксируется — и видите ли вы этот журнал.
Что проверить в договоре: где лежат данные и можно ли их забрать?
Страну и площадку хранения, кто имеет технический доступ и как он фиксируется, сроки и порядок резервного копирования, формат, в котором вы получите данные при уходе, и что происходит с копиями после расторжения. Формулировки под закон вашей страны стоит проверить с юристом.