Принципы и приемы интеграции систем контроля и учета доступа с другими информационными системами предприятия

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

СКУД с интеграциями и без

Система контроля и управления доступом (СКУД) на предприятии на первый взгляд кажется простой системой для простых людей: "этого пущать, этого не пущать". Казалось бы, все просто и понятно. Оптимизировать нечего. Интегрировать некуда. Но это не так. Система контроля и управления доступом может не только стать поставщиком необходимой информации, но и управляться другими системами компании, вплоть до того, чтобы стать полностью автономной и независимой от службы физической охраны.

Объединение возможностей СКУД с программным обеспечением управления предприятием приводит к существенному экономическому эффекту. Большое количество ручных процессов, связанных с управлением доступом, формированием табелей, подготовкой отчетов и переговоров по рации о приходе или уходе транспорта уйдут в прошлое. Люди, занятые в этих процессах, могут быть переведены на более прибыльные для предприятия работы, количество используемой бумаги сократится, простои транспорта станут минимальными, а организационная культура станет более датацентричной, более цифровой. Как показывает опыт крупных компаний, цифровое предприятие имеет на рынке преимущество за счет более низкой себестоимости процессов управления и производства, а также большей гибкости и изменчивости в нашем сложном и быстро меняющемся мире.

Пока сведения о проходах и прочая статистика хранятся только в системе контроля и учета доступа, она практически недоступна для исследования и визуализации. В сфере информационной безопасности существуют системы защиты периметра, которые также фиксируют входящий и исходящий трафик, регулируют доступ. События пропуска и блокировки трафика фиксируются в журналах устройств и программного обеспечения. Но, в отличие от СКУД, эти журналы изначально предназначены для анализа и экспорта в специальные аналитические системы, способные не только анализировать данные, но и строить прогнозы, – SIEM (Security Information and Event Management). Специалистам по информационной безопасности такой инструмент доступен, а сотрудникам физической СБ – нет.

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

Современные СКУД бедны отчетами. Сотрудник СБ может посмотреть список событий, наличие людей на объекте и сформировать что-то отдаленно напоминающее табель. И все. Оценить загруженность проходных, потребность в увеличении количества турникетов, предупреждения о сбоях, например, если по одному из турникетов резко упали проходы, из отчетов СКУД невозможно или крайне затруднительно. Вместо того чтобы требовать от производителя СКУД очередные отчеты и аналитику, было бы логично отдать данные специализированной системе бизнес-анализа и специалистам по визуализации и анализу данных.

Перейдем к анализу возможностей интеграции с различными классами корпоративных информационных систем.

Рис. 1. Синергия безопасности

Рис. 2. Синергия СКУД и ИТ

HRM. Системы управления персоналом

Решение, можно сказать, напрашивающееся. Прежде чем сотрудник попадает на предприятие и в СКУД, данные о нем заносятся в систему кадрового делопроизводства (КДП), которая является частью информационной системы управления персоналом организации. В классическом варианте сосуществования систем сотрудник КДП после приема на работу распечатывает бланк заявки на предоставление прохода на предприятие, который каким-то образом попадает в службу режима и заносится в СКУД. На этом пути происходит множество человеческих ошибок, которые приводят к инцидентам безопасности и репутационным потерям компании. Представьте себе, что отдел кадров с трудом нашел и переманил ценного специалиста, а он не может попасть на предприятие, поскольку бланк в СКУД занесли неправильно, как исправить, не знают, а администратор СКУД в отпуске. В этом случае все усилия отдела кадров могут пропасть даром.

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

1. При оформлении сотрудника в системе КДП на основании сведений о подразделении, должности, графике работы система управления персоналом должна сформировать пакет данных для СКУД в составе:
   - фотографии;
   - перечня групп доступа;
   - ФИО;
   - других параметров, критичных для службы режима предприятия.
   На основании пакета СКУД должна полностью сформировать карточку сотрудника, назначить ему группы доступа, доступность площадок, видов авторизации, заполнить остальные поля карточки сотрудника в базе данных СКУД.
   В HRM также удобно настроить печать пропуска сотрудника, если компания использует персонифицированные пропуска на базе меток RFID. В таком случае уже после оформления документов новый сотрудник автоматически получает корректный согласованный доступ на территорию предприятия без ошибок и проволочек.
2. При оформлении кадрового перевода сотрудника или оформлении замещения HRM должна повторно определить группы доступа сотрудника на основании новой должности, места работы и оповестить СКУД об изменении.
3. После оформления приказа об увольнении СКУД должна получить команду на блокировку прохода сотрудника с момента увольнения.
   Службе режима не нужно будет следить за тем, чтобы на территорию не попадали бывшие сотрудники, у которых забыли изъять пропуска.
4. Замену пропуска после утери можно сделать как через отдел КДП, так и через пост охраны, но лучше отдать эту функцию КДП, чтобы полностью исключить операторский доступ комендантов в СКУД. Коменданту достаточно отображения фото и ФИО сотрудника, проходящего контроль.

Рис. 3. HRM – системы управления персоналом

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

• табелирование;
• контроль исполнения правил внутреннего трудового распорядка (опоздания, ранние уходы, частые перекуры, отлучения с предприятия);
• контроль начисления заработной платы "мертвым душам".

Поскольку HRM обладает сведениями о графике сотрудника, составить фактический табель на основании данных о проходах и уходах не составляет труда. Можно вычислять не только явку, но и реальную продолжительность смены, если СКУД установлена в цеху.

Контроль правил ВТР открывает обширное поле для работы сотрудников кадров, специалистов по мотивации и руководителей подразделений.

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

На исполнении правил внутреннего трудового распорядка нужно остановиться особо. Американские социологи-криминалисты Джеймсон Уилсон и Джордж Келлинг в 1980-х гг. сформулировали теорию разбитых окон². Название происходит от приводимого авторами типичного примера действия теории: "Если в здании разбито одно стекло и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна". Нужно также вспомнить историю про исправление криминогенной ситуации в Нью-Йорке, которая началась с борьбы с мелкими преступлениями, такими как безбилетный проезд, граффити и т.п.

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

Рис. 4. Теория разбитых окон (подробнее по QR-коду)

ERP. Управление ресурсами предприятия

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

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

Рис. 5. Автоматизация и фото-видеофиксация весовых пунктов и оборудования

Автоматическое формирование отгрузочных документов клиенту на горнодобывающем предприятии без участия сотрудников

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

Перед началом работ по интеграции нужно произвести следующую подготовку:

а) периметр компании должен быть огорожен, а въезд для клиентского грузового транспорта оборудован автоматическим шлагбаумом с системой СКУД, распознающей номер автомобиля;

б) автоматические автомобильные весы должны быть подключены к системе управления продажами предприятия так, чтобы ERP могла автоматически получать значение веса автомобиля;

в) на въезде на весы со стороны площадки хранения также нужно установить шлагбаум с системой распознавания номеров.

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

• Клиент оформляет заявку на отгрузку щебня с указанием номенклатуры щебня либо по электронной почте, либо на специальном портале. В заказе клиент указывает номера автомобилей, которые он планирует отправить. Возможно реализовать механизм, когда клиент указывает перечень номеров, которые предприятие должно считать номерами автомобилей покупателя.
• Заявка клиента попадает в ERP-систему предприятия. Мастер соответствующего участка видит в перечне заказов на отгрузку заказы клиента и готовится к их отгрузке. Система автоматически сообщает СКУД о том, что такому перечню госномеров разрешен въезд через КПП отгрузки.
• Когда транспорт клиента приходит на предприятие, СКУД сверяет его номер с номером разрешенных и если находит, то открывает шлагбаум на весы.
• Весы передают в ERP показатель веса пустого транспорта. ERP запрашивает у СКУД номер транспорта, сохраняет промежуточные данные и дает команду СКУД на выпуск транспорта с весов. СКУД открывает выпускной шлагбаум.
• Транспорт клиента загружается гравием и возвращается к весам.
• Операция пропуска обратно и считывания веса повторяется.
• ERP на основании разницы веса пустого и загруженного автомобиля оформляет и распечатывает транспортные документы, а электронные документы отправляет покупателю через электронный документооборот.

Человек в этом процессе нужен только для того, чтобы проконтролировать правильное положение машины на весах, но, учитывая возможности машинного зрения, процесс можно настроить так, чтобы водитель видел на мониторе рядом с весами, что именно он делает не так (расположение машины).

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

Рис. 6. Схема взаимодействия TMS и WMS и функциональность

Автоматический расчет логистического плеча при убытии транспорта с территории площадки

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

Анализ перемещений сотрудников по предприятию

Расстояние между считывателями вычислить несложно. По данным событий СКУД можно построить пути перемещения сотрудников по предприятию и выявить наиболее "длинные процессы". Перемещения – это один из видов потерь, по теории бережливого производства, с которым можно и нужно бороться. Анализ перемещений сотрудников поможет выявить производственные цепочки, которые построены неэффективно, а также административные процессы, которые требуют от сотрудника несколько раз за смену пересекать всю территорию предприятия для выполнения своих обязанностей.

Рис. 7. Табло информационной системы YMS

WMS/TMS. Системы управления складом и транспортом

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

• Разрешение на въезд под погрузку выдается только тем транспортным средствам, которые указаны в открытых маршрутных листах.
• Доступ на корпоративную стоянку регулируется списком разрешенных номеров, которые формируются TMS- и HRM-системами.
• Факт постановки автомобиля в конкретный док автоматически сообщается WMS, которая перестраивает работу участка отгрузки.
• Разрешение на выезд транспорта на КПП выдается WMS только при наличии всех оформленных документов и заключения врача.

На рынке даже присутствуют специализированные решения YMS (система управления двором), которые представляют собой конвергенцию СКУД и ТМS и предназначены для автоматизированного управления движением транспорта, очередями и механизацией ворот.

Охрана труда

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

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

Рис. 8. Схема SIEM-системы

SIEM. Система управления событиями безопасности

Современные системы сбора и анализа событий успешно справляются с поиском отклонений в событиях сетевой инфраструктуры и информационной безопасности. Но поскольку алгоритмы эвристического анализа в большинстве своем универсальны, то загрузка в SIEM сведений о событиях СКУД сильно упростит задачу поиска внутренних нарушителей.

Я уверен, что это далеко не полный список классов корпоративных информационных систем, с которыми имеет смысл интегрировать СКУД, но приведенные примеры помогут вам найти собственные уникальные решения для своей организации.

Принципы интеграции

Принципы интеграции СКУД с другими системами не отличаются от классических правил интеграции. Они очень просты и логичны.

1. Доверяйте профессионалом. Любые системы интеграции работают без человека, а пользователь доверяет тому, что они работают, и работают корректно. С развитием цифровой культуры компании руководители все больше и больше начинают полагаться на 100%-ную бесперебойность работы процессов, и каждый сбой грозит остановкой работы площадки или целого предприятия. В таких условиях было бы разумно доверить интеграцию между системами производителю или авторизованному партнеру производителя одной из систем. К примеру, если вы интегрируете СКУД с "1С: Зарплата и управление персоналом", поручите эту работу опытному франчайзи 1С, поскольку интеграцию нужно не только создать, но создать так, чтобы последующее обновление HRM не сломало ее.
2. Должно работать само. Если у вас по бизнес-процессу хоть в одном месте должен принимать решение человек, то такая интеграция работать не будет. Человек, принимающий решение, все равно руководствуется правилами или опытом.
   Правила нужно актуализировать, опыт оцифровать и описать, а на основе полученного документа определить автоматические правила и исключить человеческий фактор.
3. Если не работает – сообщает. В состав требований высокого уровня обязательно включите требование мониторинга работы интеграции и оповещение о наличии ошибок, конфликтов и блокировок. Это позволит узнать о проблеме раньше, чем ее влияние почувствует бизнес.
   Согласитесь, что если на вопрос бизнеса о том, что случилось, вы выдаете полную картину ситуации, то накал страстей бывает существенно ниже, чем если бы вы ответили, что впервые слышите о проблеме.
4. Учитывайте 152-ФЗ. Согласно разъяснению Роскомнадзора фотография сотрудника в совокупности с его ФИО являются биометрическими данными и должны быть защищены соответствующим образом. Если сервер СКУД размещен на территории третьего лица, то должно быть оформлено соглашение о передаче персональных данных.
5. Обрабатывайте исключения. В процессе проектирования необходимо рассмотреть все варианты отказов, которые можно предположить на этапе создания системы, например:
   - отказ одной из систем;
   - повреждение пакета с данными;
   - ошибка разработчика при формировании пакета с данными;
   - различие версий фактически используемого и поддерживаемого протокола и пр.
6. Оставляйте пути для работы вручную. Всегда должен оставаться аварийный план. Если вдруг интеграция сломалась серьезно и починить ее быстро невозможно, то ответственный сотрудник должен достать регламент бумажного процесса, сдуть с него пыль и начать работать без ИТ-систем.

Рис. 9. Интеграция по принципу точка-точка

Протоколы интеграции

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

Обмен файлами

Самый старый и самый простой механизм. Одна система записывает файл и сохраняет в общем каталоге, который доступен и отправителю, и получателю. Получатель при появлении файла в каталоге открывает его в режиме чтения и загружает информацию. Это самый ненадежный способ передачи. Он имеет множество уязвимостей и потенциальных мест отказа. Разработчику нужно следить не только за содержимым и версией разметки содержимого, но и за доступностью каталога, наличием необработанных пакетов и множеством других параметров для обеспечения максимальной отказоустойчивости. Данный протокол подходит для разовых или очень редких обменов, которые выполняются под контролем администратора.

Прямой вызов исполняемых файлов

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

Прямое обращение к базе данных

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

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

Вызовы веб-сервера

Самый распространенный и самый безопасный способ обмена. Системы взаимодействуют между собой как веб-серверы в сети "Интернет".

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

С другой стороны, наличие промежуточной системы уменьшает производительность системы интеграции. Из всех перечисленных он самый медленный.

Ремарка для коллег из ИТ. Приведенные выше оценки не являются исчерпывающими. Мне знакомы системы интеграции REST, которые работали гораздо быстрее, чем RPC, но это скорее исключение, чем правило.

Рис. 10. Интеграция по принципу точка-центр (рисунок автора)

Виды интеграции

"Точка-точка"

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

Преимущества:

• Быстро реализовать. Нужно знать протоколы только двух систем.
• Легко поддерживать. По интеграционной связи передаются четко определенные ограниченные данные.
• Стандартизация не нужна. Для каждой связи "точка-точка" может быть использован свой уникальный протокол.

Недостатки:

• Данные остаются в локальных системах.
  Невозможно агрегировать и анализировать данные нескольких систем и находить взаимосвязи.
• Трудно поддерживать множество разнородных связей интеграции. Если используются разные протоколы, то для каждого или группы сходных нужен отдельный профильный специалист.

"Точка-центр"

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

Преимущества:

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

Недостатки:

• Большая нагрузка на центральную систему.
  Множество связанных систем вызывают интеграционные компоненты центральной системы, что существенно увеличивает требования по производительности серверов приложений и базы данных. Учитывая, что центральная система и так сильно нагружена, большое количество интеграций может ее "уронить".
• Хранение избыточных данных. ERP, которую чаще всего выбирают в качестве центральной системы, не предназначена для хранения промежуточных данных обменов. Прежде всего это система управления предприятием, а не хранилище. Расширение базы данных центральной базы негативно сказывается на общей производительности ERP.
• Сложный поиск и исправление ошибок синхронизации. Использование различных протоколов усугубляется их взаимодействием с логикой транспорта до других связанных систем внутри центральной системы. Найти точку отказа, когда связанная система-"отправитель" отправила, а связанная система-"получатель" получила что-то не то, очень сложно.

Рис. 11. Шина данных (рисунок автора)

ESB. Шина данных

Шина данных – это специализированный программный продукт. Единственной его задачей является транспорт данных между информационными системами предприятия. Примерами таких решений могут послужить Microsoft Biztalk Server, Datarion, 1С: Шина данных и др.

Шина данных состоит из следующих компонентов:

1. Коннекторы. Они предназначены для взаимодействия с информационным системами, отправляя и принимая данные. Для распространенных систем есть готовые коннекторы. Для уникальных случаев их достаточно просто разработать.
2. Конвейеры преобразования нужны для преобразования данных, полученных от отправителя, в формат, понятный получателю или общий.
3. Транспортная система, отвечающая за доставку пакетов данных.

Преимущества:

• Легко подключать новые системы. Достаточно использовать коннектор, поставляемый поставщиком, или написать свой.
• Нет нагрузки на бизнес-системы. Шина данных работает в отдельной инфраструктуре.
• Удобный контроль и версионирование данных. Системы типа ESB имеют специальную функциональность для разрешения коллизий и гарантированной доставки пакетов данных.

Недостатки:

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

Наличие шины данных дает еще одно немаловажное преимущество. Шина упрощает развертывание озера данных (data lake) на предприятии. Data lake – это хранилище, в котором собрана неструктурированная информация любых форматов из разных источников. Озера данных дешевле обычных баз данных, они более гибкие и легче масштабируются. Озера данных можно использовать для любых целей – анализов, прогнозов, оптимизации бизнес-процессов. Система хранения озера данных будет получать все пакеты данных, которые передаются по шине, и, таким образом, содержать всю совокупность информации, которой обладает предприятие.

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

Рис. 12. Озеро данных как часть интеграции (рисунок автора)

Заключение

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

² Теория разбитых окон (англ. broken windows theor y) – криминологическая теория, рассматривающая мелкие правонарушения не только как индикатор криминогенной обстановки, но и как активный фактор, влияющий на уровень преступности в целом. Сформулирована американскими социологами Джеймсом Уилсоном и Джорджем Келлингом, впервые опубликована в 1982 г. в журнале The Atlantic Monthly.

Фото https://ru.freepik.com

Опубликовано в журнале "Системы безопасности" № 4/2022

Все статьи журнала "Системы безопасности"
доступны для скачивания в iMag >>