Управление доступом в ПО для бизнеса: как синдром вахтера сбивает эффективность работы?

Вспомните случай, когда корпоративная система отказывалась выполнять элементарное действие – например, перенести встречу в календаре, а на экране появлялось сообщение: «У вас недостаточно прав для редактирования встречи, созданной руководителем». Программе не объяснить, но вы не злоумышленник, а всего лишь сотрудник, который пытается сберечь общее время, избавив всех от путаницы с расписанием.

Дальше начинается знакомый многим обходной маршрут: звонок руководителю, который занят, заявка в службу поддержки, ожидание, нарастающее раздражение от того, что простейшая задача превратилась в многоходовую операцию. Встреча остается на старом месте, участники получают противоречивые уведомления, а вы чувствуете себя человеком, которого держит в подчинении собственный инструмент.

Это не случайный сбой и не ошибка конкретного разработчика, а явление, которое принято называть «синдромом вахтера». Если вы хотя бы раз сталкивались с ситуацией, когда система отказывает в праве нажать очевидно нужную кнопку, то вы уже знакомы с этим синдромом лично.

Классический вахтер задумывался как страж порядка, чья задача – отсекать посторонних и обеспечивать безопасность. Но в определенный момент человек на посту перестает пропускать сотрудников, которых видит годами, тормозит доставку важных документов из-за нехватки третьей подписи и, кажется, находит особое удовлетворение в возможности произнести «нет».

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

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

В какой-то момент система начинает относиться к каждому сотруднику как к потенциальному вредителю, и тогда бухгалтер не может выгрузить отчет без подтверждения безопасника, а оператор поддержки видит перед собой кнопку «Оформить возврат», которая навсегда останется серой именно для него.

И вот тут начинается самое интересное: программа-вахтер не просто мешает работать – она незаметно перестраивает само поведение людей внутри компании, приучая их к беспомощности или поиску обходных путей. Об этом механизме мы и поговорим дальше.

Как выглядят недочеты доступа в логике системы?

Полезно рассмотреть конкретные проявления этой болезни – те самые микроскопические стычки сотрудника с системой, которые день за днем формируют раздражение и отторжение от инструмента.

Первым делом мы выделили так называемое «поле, которое нельзя трогать». Менеджер по продажам готовит счет для клиента: заполняет сумму, выбирает условия, указывает сроки – и вдруг замечает опечатку в названии компании заказчика.

Казалось бы, исправить поле – 5 секунд времени, но поле «Наименование заказчика» не реагирует на клик, потому что право его редактирования отдано «Старшему оператору справочника контрагентов». Менеджер не может исправить опечатку сам – он вынужден создавать заявку, писать в соседний отдел, ждать, пока нужный человек освободится и внесет правку.

Обратите внимание: система не защитила бизнес от серьезной угрозы – она защитила поле ввода от сотрудника, который просто хотел сделать свою работу аккуратно. При этом «Старший оператор справочника» не обладает никаким особым знанием о том, как правильно пишется название компании клиента, у него просто есть исключительное право нажимать клавиши в этом месте.

Следующий недочет связан с призрачными кнопками, на которые, как и на поля, смотреть можно, а трогать нельзя. Сотрудник заходит в интерфейс и видит перед собой элемент, который нужен ему прямо сейчас: «Подтвердить заявку», «Отправить на согласование», «Сформировать отчет». Кнопка на месте, ее отлично видно, но она серая и никак не откликается на нажатие, при этом нигде не написано, почему она серая, кому она доступна и что нужно сделать, чтобы ее разблокировать.

Сотрудник начинает исследовать соседние вкладки, перечитывать регламенты, спрашивать коллег – и спустя сорок минут выясняет, что право нажимать на эту кнопку есть только у одного человека во всей компании, и этот человек сейчас на обеде.

Для сотрудника унизительна не сама задержка, а опыт: человек видит цель, видит инструмент для ее достижения, но не может им воспользоваться без объяснения причин. Это напоминает ситуацию, когда вам выдали ключ от кабинета, но замок открывается только в присутствии завхоза, который носит при себе какую-то особую, высшую версию того же самого ключа.

Третий сценарий возникает там, где система зеркально повторяет бюрократическую лестницу организации, не делая скидку на реальную жизнь.

Сотрудник оформляет заявку на отпуск длиной в два дня: по внутреннему регламенту ее должны завизировать три руководителя разного уровня. Двое из них, как назло, сами находятся в отпусках – в тех самых, которые они заблаговременно согласовали по той же цепочке.

У их заместителей формально есть полномочия принимать решения, но в настройках доступа это не отражено: право подписи привязано к конкретным учетным записям, а не к ролям. Заявка застревает в цифровом чистилище – она не отклонена и не одобрена, она просто лежит там, где ее никто не может достать.

В этот момент сотрудник оказывается перед выбором: ждать возвращения руководителей либо идти в обход системы – звонить, договариваться, фиксировать договоренности где-то вне программы. Большинство выбирает второй путь, и тогда замечательная система управления отпусками превращается в красивую, но бесполезную декорацию, а реальный учет снова ведется в почте и мессенджерах.

Объединяет все три сценария одна и та же конструкция: система не помогает сотруднику довести дело до конца, она фиксирует его беспомощность. Формально доступ к системе есть, но права на осмысленное действие нет.

Во что обходятся ошибки проектирования?

«Ну подумаешь, нажал не ту кнопку, подождал полчаса – не катастрофа же». В этом и кроется главное коварство «синдрома вахтера»: он действует как медленная коррозия, результаты которой становятся заметны только тогда, когда ущерб уже накопился.

Отдельно взятая ситуация с серой кнопкой или заблокированным полем крадет у сотрудника минут десять-пятнадцать. Но теперь представьте, что похожие заминки возникают у тридцати человек по несколько раз в день. Десять минут умножаем на три-четыре эпизода, затем на количество рабочих дней в месяце, затем на количество месяцев – и получаем цифру, которая измеряется не в минутах, а в человеко-месяцах.

Это время, которое компания оплачивает своим сотрудникам не для работы, а для борьбы с инструментом, призванным эту работу облегчать. Хуже того, эти потери почти никогда не фиксируются в отчетах: сотрудник не пишет в табеле «три часа спорил с системой», он просто не успевает сделать запланированное и переносит задачи на завтра, а завтра на послезавтра.

Ещё фатальнее сказывается на бизнесе не потеря денег, а постепенное снижение ответственности. Когда человек не может довести задачу до конца самостоятельно, он перестает чувствовать себя ее хозяином. Если менеджер знает, что не сможет выставить счет без сторонней подписи, его внутренняя мотивация проверять этот счет на ошибки падает. Зачем вычитывать цифры, если последнее слово все равно не за тобой?

Формируется удобная и разрушительная для бизнеса конструкция: «Я сделал свою часть, остальное не от меня зависит». Система-вахтер, сама того не желая, выращивает в коллективе культуру перекладывания ответственности – не потому что люди ленивы или безразличны, а потому что их реальные полномочия заканчиваются задолго до того, как работа считается выполненной.

Третья статья потерь – расцвет теневого информационного пространства. Сотрудники довольно быстро понимают, что корпоративная система вставляет палки в колеса именно там, где требуется скорость и гибкость. И тогда они находят альтернативу: клиентская база переезжает в общую таблицу на личной почте, потому что там можно исправить опечатку без визы «Старшего оператора справочника».

Важные договоренности фиксируются в переписках, до которых служба безопасности никогда не доберется. Компания платит за разработку, поддержку и обновление дорогой системы, а реальная работа тем временем утекает в неконтролируемые каналы – со всеми сопутствующими рисками утечки данных, потери версионности и полной невозможности восстановить историю решений.

Самый болезненный факт для бизнеса заключается в том, что страдает опыт клиента, причем клиента внешнего. Потому что «синдром вахтера» редко остается внутри компании, он почти всегда просачивается наружу. Клиент звонит с простым вопросом, оператор поддержки видит ответ на экране, но не может нажать кнопку «Оформить возврат» – у него нет прав. Оператор произносит сакраментальную фразу: «Извините, программа не дает», – и клиент в этот момент теряет веру не в программу, а в компанию целиком.

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

Откуда растут ноги проблем в проектировании?

Если спросить у разработчика, почему в системе оказалось заблокировано безобидное поле, он, скорее всего, пожмет плечами и скажет: «Так было в техническом задании». Если спросить у заказчика, почему в техническом задании появилось такое требование, он ответит что-нибудь про безопасность и порядок.

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

Первый корень проблемы – культ ложной безопасности. Когда бизнес формулирует требования к доступу, им часто движет страх: «А вдруг кто-нибудь что-нибудь сломает?» Стремление защитить систему от случайных или намеренных ошибок само по себе понятно и правильно, но проблема начинается там, где этот страх перестает соизмеряться с реальными рисками.

Поле «Наименование заказчика» блокируется не потому, что его изменение действительно опасно для бизнеса, а потому что «мало ли что». Кнопка «Подтвердить заявку» прячется за многоступенчатым доступом не потому, что нажатие на нее запускает необратимые процессы, а потому что «пусть лучше лишний раз проверят». В какой-то момент каждый сотрудник рассматривается не как квалифицированный специалист, а как потенциальный источник хаоса, которого нужно ограничить во всем, кроме самого узкого набора действий.

Второй корень – механическое копирование организационной структуры внутрь интерфейса. Компания устроена иерархически: есть начальники, есть подчиненные, есть промежуточные звенья. Эта лестница складывалась годами и в реальной жизни худо-бедно работает за счет человеческой гибкости: руководитель может крикнуть через стенку «да согласен я, делай», заместитель может принять решение в отсутствие начальника, коллеги договариваются между собой без формальных запросов.

Но когда та же самая иерархия переносится в программный код один в один, вся эта гибкость исчезает. В коде нет «крикнуть через стенку», есть только холодное: «У учетной записи отсутствует роль, необходимая для выполнения операции». Если в жизни за простую операцию отвечают три отдела, то и в программе возникнет три последовательных блокировки – без вариантов обхода, без учета контекста, без скидки на то, что два из трех держателей этих блокировок прямо сейчас находятся в самолете.

Третий корень связан с тем, что роли и доступы часто проектируются под некоего «идеального сотрудника», который существует только в воображении авторов регламентов. Этот идеальный сотрудник никогда не ошибается, всегда знает, к кому обратиться за разблокировкой, и работает строго в рамках своей должностной инструкции, не проявляя лишней инициативы.

Реальный же человек иногда хочет помочь коллеге из смежного отдела, иногда видит очевидную ошибку и хочет ее исправить, иногда просто учится и тыкается в разные углы системы, чтобы понять, как она устроена.

Новичок, который хочет изучить соседний раздел просто чтобы понимать общую картину, упирается в стену «Недостаточно прав». Специалист, заметивший несоответствие в чужой заявке, не может подсказать коллеге и исправить – он должен писать запрос, ждать, объяснять. Благое намерение помочь разбивается о настройки доступа, и в следующий раз этот специалист уже пройдет мимо, потому что связываться себе дороже.

Отсутствие градации между вредными и рабочими действиями приводит к тому, что система часто не отличает исправление опечатки в фамилии клиента от удаления клиента из базы данных. И то, и другое классифицируется как «редактирование записи», и если уж закрывать доступ к удалению – а его, безусловно, стоит закрыть для большинства – то под замком оказывается и опечатка.

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

Как проектировать без синдрома вахтера?

Хорошая новость в том, что «синдром вахтера» – не приговор и не неизбежная плата за безопасность. Это проектировочная ошибка, которую можно исправить, если на старте разработки заложить несколько принципов. Принципы эти не требуют сложных технологических решений, они лежат скорее в области логики и здравого смысла, но именно о них чаще всего забывают, увлекаясь более масштабными задачами.

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

• Плохой сценарий: кнопка серая, действие невозможно, сотрудник идет искать того, у кого есть права.
• Хороший сценарий: кнопка активна, но при нажатии появляется предупреждение: «Вы снижаете цену ниже минимально допустимой. Это потребует дополнительного согласования. Продолжить?»

В первом случае система относится к человеку как к ребенку, которому нельзя доверять. Во втором – как к взрослому специалисту, которому дают информацию и оставляют право на решение. Понятно, что для критически опасных операций – массового удаления данных, изменения финансовых проводок задним числом – полный запрет оправдан. Но таких операций в любой системе единицы, и они точно не включают в себя исправление опечаток или перенос встречи в календаре.

Второй принцип – динамические полномочия, или «замещение на время». Любая живая организация устроена так, что нужный человек не всегда на месте. Система, которая не учитывает этот факт, обрекает бизнес-процессы на периодический паралич. Что здесь можно сделать:

• Привязать право подписи не к конкретной учетной записи, а к роли. Если руководитель в отпуске, его заместитель автоматически получает ту же кнопку – без звонка администратору и без правки настроек вручную.
• Научить систему распознавать бездействие. Если заявка провисела без ответа больше суток, а сроки поджимают, право согласования автоматически передается на уровень выше или тому, кто назначен замещающим.
• Ввести механизм временного делегирования. Сотрудник может передать коллеге право нажать конкретную кнопку на ограниченное время – скажем, на два часа или до конца рабочего дня. Это особенно полезно, когда кто-то уходит на больничный посреди важного процесса.

Третий принцип – разделение вредных и рабочих действий. Система должна научиться отличать опасные операции от повседневных, вместо того чтобы сваливать их в одну кучу с одинаковым уровнем блокировки. Примерный список того, что стоит разграничить:

• Исправление опечатки в названии – не то же самое, что удаление контрагента из базы.
• Изменение даты встречи – не то же самое, что отмена всей цепочки совещаний.
• Просмотр данных соседнего отдела – не то же самое, что их изменение или выгрузка вовне.

Каждое из этих действий требует своего уровня доступа. Опечатку можно позволить исправлять любому, кто работает с карточкой клиента, удаление – только администратору базы, просмотр данных – всем, кому это нужно для понимания контекста, а выгрузку – ограниченному кругу лиц с обязательной фиксацией в журнале событий. Если на этапе проектирования потратить время на такую градацию, количество серых кнопок в интерфейсе сократится радикально.

Часто самое разрушительное в «синдроме вахтера» – не сам запрет, а его немота. Сотрудник видит серую кнопку и не понимает ни причин, ни дальнейших шагов. Это легко исправить, если следовать нескольким правилам:

• Если поле нельзя редактировать, рядом с ним должно быть объяснение: «Поле зафиксировано. Ответственный за изменение – Иванова А., отдел качества. Причина: сверка данных до 15-го числа».
• Если кнопка недоступна, при наведении на нее должно появляться сообщение: «Для подтверждения заявки требуется роль "Руководитель подразделения". Сейчас у вас эта роль отсутствует. Обратитесь к Петрову В. или дождитесь его визы».
• Если доступ временно заблокирован, система должна сообщать сроки: «Раздел откроется после завершения проверки, ориентировочно 20 марта».

Такая прозрачность делает три полезных вещи одновременно. Во-первых, она снимает тревогу – человек понимает, что происходит. Во-вторых, она дает четкий маршрут – он знает, к кому идти и что именно просить. В-третьих, она снижает нагрузку на службу поддержки, потому что половина вопросов отпадает сама собой.

Когда систему проверяют перед запуском, основное внимание обычно уделяют «счастливому пути»: нажал кнопку – всё сработало, заявка ушла, отчет сформировался. Но настоящую проверку на «синдром вахтера» дает только тестирование на отказ. Достаточно сесть и пройти по цепочке вопросов:

• Что видит сотрудник, когда система говорит ему «нет»?
• Понимает ли он, почему ему отказано?
• Знает ли он, что делать дальше?
• Есть ли у него обходной путь, и не уводит ли этот обходной путь работу в теневую зону – в почту, в мессенджер, в звонки?

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

Все перечисленные принципы объединяет общая логика: система должна страховать от дурака, но не мешать умному. Это не компромисс между безопасностью и удобством, это понимание того, что настоящая безопасность и есть удобство – удобство для тех, кто работает честно и быстро. Если сотрудник не думает о том, как обойти запрет, а спокойно делает свое дело, значит, доступы настроены правильно. Если он вынужден хитрить, ждать и искать виноватых – значит, где-то поселился вахтер, и его пора выселять.

Разработка ПО от 66 Бит

Всего за 10 минут мы разобрались в том, почему и какими методами вы собственноручно можете превратить свою систему в злого вахтера. Самое время спроектировать и разработать систему, которая будет работать на вас, а не вопреки!

Чтобы не проходить этот сложный путь самостоятельно, советуем обратить внимание на 66 Бит. Наши опытные специалисты спроектируют эффективную логику системы под ваши бизнес-задачи и разработают ПО, которое кратно повысит производительность вашего дела! Подробнее читайте на нашем сайте.