Чешский стартап Passwd предложил довольно приземлённое, но болезненно актуальное решение для компаний на Google Workspace: автоматизировать управление доступом для сотрудников по структуре команд и ролей. Для русскоязычных IT-команд это знакомая история: аккаунт новичку заводят быстро, а вот доступы к реальным рабочим инструментам он может выбивать ещё неделю.
О продукте 28 мая 2026 года сообщает EU-Startups. Passwd описывает проблему, которую в компаниях часто считают мелочью на фоне найма, адаптации и закупки софта: формально сотрудник уже оформлен, почта и мессенджер работают, но к клиентским кабинетам, продовым средам, маркетинговым сервисам или общим учётным данным он не допущен. На бумаге онбординг завершён, по факту работа ещё не началась.
Именно на этом разрыве стартап и строит свою логику. По версии Passwd, сбои в онбординге обычно происходят не на этапе создания учётной записи, а на этапе выдачи прав. Новичок ждёт, пока кто-то из коллег вспомнит, кому писать. Разработчик не может выкатывать изменения, маркетолог не может зайти в нужный сервис, аккаунт-менеджер не видит клиентский кабинет. Каждый отдельный эпизод выглядит как бытовая накладка, но в сумме из них собираются дни, а иногда и недели потерянной продуктивности.
В материале приводится и финансовый фон этой проблемы: средняя стоимость найма одного сотрудника оценивается примерно в 4,700 долларов, а до полной продуктивности люди часто выходят только через несколько месяцев. На этом фоне потери из-за ручной раздачи доступов редко считаются отдельно, хотя они напрямую влияют и на скорость адаптации, и на впечатление человека от новой работы. Первый рабочий опыт у многих начинается не с результата, а с очереди за правами. Для HR это раздражающий процесс, для менеджмента скрытая потеря времени, для сотрудников довольно быстрый способ почувствовать себя лишним элементом в системе.
Passwd заходит в эту точку не как очередной парольный сейф с красивой витриной, а как надстройка над уже существующей структурой Google Workspace. Логика простая: если в компании уже определены пользователи, группы и команды, то права на доступ к общим учётным данным и инструментам должны автоматически наследоваться из этой структуры. Когда человек присоединяется к команде в Google Workspace, Passwd выдаёт ему доступ к тем данным и сервисам, которыми эта команда пользуется. Если сотрудник переходит в другой отдел, набор доступов меняется вместе с ним. Если увольняется, доступы должны исчезать в рамках того же процесса офбординга.
На практике это попытка убрать из уравнения человеческую память и корпоративный фольклор. Во многих компаниях управление доступом до сих пор устроено как цепочка личных сообщений, устных инструкций и знания «к кому подойти». Такой подход терпим, пока команда маленькая и все сидят в одном чате. Как только появляются распределённые роли, несколько функций, подрядчики и рост штата, система начинает расползаться. Учётку бывшего сотрудника отключить несложно, но shared credentials, доступы к сторонним SaaS-сервисам и старые пароли часто живут собственной жизнью. Именно тут тема удобства быстро превращается в тему безопасности.
В этом смысле у Passwd довольно удачное позиционирование. Стартап не обещает перевернуть identity management и не продаёт идею тотального контроля как что-то героическое. Напротив, он исходит из того, что базовая часть уже более-менее решена самими платформами вроде Google Workspace: пользователей создавать умеем, роли и организационную структуру хранить умеем, группы собирать умеем. Проблема в следующем слое, который часто остаётся ручным и несогласованным: кто и к чему реально имеет доступ в повседневной работе. Для многих IT-команд это как раз та часть инфраструктуры, которую все признают важной, но никто не хочет делать руками до конца.
Для рынка это ещё один сигнал, что онбординг всё сильнее рассматривают не как HR-процесс, а как операционную и security-задачу. Если сотрудник в первую неделю не может получить доступ к средам, репозиториям, кабинетам и внутренним сервисам, это уже не «неудобство», а сбой в рабочем контуре. Особенно в компаниях, где продукт, продажи, поддержка и разработка завязаны на десятки SaaS-инструментов. Чем больше стек, тем выше цена ручной ошибки. И тем привлекательнее выглядит модель, в которой доступы следуют не за тикетами и напоминаниями, а за оргструктурой.
Для русскоязычной аудитории здесь важен и более практический вывод. Компании годами обсуждают автоматизацию найма, внутренние базы знаний и сценарии адаптации, но управление доступом часто живёт в отдельной реальности. Его либо отдают на откуп админам, либо размывают между тимлидами, HR и «тем, кто знает пароль». На небольшом масштабе это работает, на растущем бизнесе начинает дорого скрипеть. Поэтому интерес к таким инструментам будет расти не потому, что это модный сегмент, а потому что никто не хочет оплачивать простои новых сотрудников и одновременно держать в системе забытые доступы бывших.
Вопрос теперь не в том, нужна ли автоматизация доступов как таковая, а в том, насколько глубоко компании готовы привязать её к своей реальной оргструктуре и процессам офбординга. Если такие решения закрепятся, онбординг будут оценивать уже не по принципу «почту выдали в первый день», а по более честному критерию: когда человек действительно смог начать работу.