Способы нивелирования ошибочных действий пользователей в ИС
В этой статье я хотел бы поделиться собранной мной информацией о том, как можно противодействовать ошибочным действиям пользователей в информационных системах. Актуальность темы, а также отсутствие единого и чёткого представления об этих методах на просторах сети являются причиной подготовки и публикации этого материала. Я постарался рассмотреть этот вопрос как системный, бизнес-аналитик и специалист по информационной безопасности.
В статье будут перечислены 5 методов, а также их преимущества и недостатки. Информация о каждом методе представлена для ознакомления и без подробностей, так как каждый из методов представляет собой большую тему, с который каждый по мере интереса может ознакомиться отдельно.
Стоит сразу обозначить, что автор вкладывает в значение «ошибочное действие».
Ошибочное действие заключается в умышленном или случайном действии пользователей ИС, которые влечёт ошибки, сбои в работе ИС или наносит другой ущерб компании, такие как нарушения целостности, доступности и конфиденциальности информации.
1. Обучение пользователей работе с ИС
Этот способ заключается в том, чтобы обучить пользователей, как нужно работать с ИС в общих чертах и в рамках их специальности. В процессе обучения нужно рассказать:
о возможностях системы в общем и для конкретного пользователя;
об интерфейсе;
о правилах работы и ответственности за нарушения.
Существует множество способов обучения. Помимо написания инструкции пользователя для каждой роли, предусмотренной ИС, можно проводить очные и онлайн семинары, инструктажи со специалистами, которые знают аспекты работы системы. Такими специалистами могут быть разработчики, специалисты по внедрению, аналитики, консультанты, специалисты отдела кадров, администраторы, специалисты техподдержки.
Выбор метода зависит от специфики предприятия, от корпоративной культуры, от её финансовых и организационных возможностях. Так, например, наиболее популярным методом для корпораций сегодня является онлайн-курсы с видеороликами. Несмотря на высокую стоимость разработки, оно выгодно для больших компаний, так как не нужно отвлекать менеджмент и использовать организационные ресурсы каждый раз, когда появляется новый сотрудник. Однако для малых компаний, где работа происходит в малой социальной группе (коллективе), из-за возможности индивидуального подхода к каждому сотруднику разрабатывать такие онлайн-курсы было бы нецелесообразно.
Таким образом, минусами превентивной меры по обучению сотрудников пользованию ИС, являются следующие факты:
Если пользователь — внешний по отношению организации, и обучение происходит онлайн, проверить его знания будет почти невозможно. (Например, показав подсказки и небольшие инструктажи, как использовать сайт маркетплейса, мы не можем пользователю для доступа к сайту заставить пройти тест на знание интерфейса и возможностей сайта).
Составление инструкций, образовательных программ требует много времени работы аналитиков и, соответственно, затрат.
Проведение инструктажа отвлекает сотрудников от выполнения их непосредственных обязательств.
Инструктаж не может гарантированно защитить от ошибок по незнанию, так как возможности системы и различные комбинации взаимодействия с ней бессчётны.
Плюсами данного метода является:
2. Разграничение доступа к функционалу АО, СПО и ПО
Данная превентивная мера заключается в том, чтобы на основе функционального (в MRP, ERP) или процессного (в BPMS, DSS) разделения настроить полномочия (права) пользователей в ИС на разных стадиях взаимодействия: непосредственно с машиной (АО — аппаратное обеспечение), к системе (СПО — системное программное обеспечение), к программам (ПО — программное обеспечение). Ошибочное действие может быть произведено в том случае, когда пользователь по незнанию или злому умыслу активирует функционал, который не соответствует его должности. Чтобы этого действия не допустить, нужно заранее озаботиться чётким разграничением прав пользователей, а также обеспечить его контроль и учёт.
Примером разграничения доступа к АО является клавиатура со считывателем карт в виде разъёма для ключ-карты. Без вставленной корректной ключ-карты, клавиатура не будет работать, а значит у пользователя не будет возможности вводить информацию в аппарат.
Примером разграничения доступа к СПО является создание локальной сети Active Directory на ОС Windows Server. Администратор на сервере может создать пользователей и задать их права к системе на тех машинах, которые подключены к сети и к Active Directory (должны быть под управлением ОС Windows). При входе в систему, в зависимости от пользователя, ОС изменяет параметры доступа и открывает (или закрывает) доступ к её компонентам. Например, система может блокировать подключение внешних носителей, использование командной строки или выход в сеть Интернет (если имеется техническая возможность).
Примером доступа к функционалу ПО является настройка прав доступа пользователей. Например, в 1C: ERP есть возможность каждому пользователю назначить роль или профиль (совокупность ролей). В роли содержится список объектов и какие права есть у пользователя по отношению к нему. Права могут быть на просмотр, чтение, изменение (вплоть до конкретного элемента), удаление, создание. Объектами могут быть как объекты конфигурации (документы, отчёты и т.д.) и их атрибуты, так и подсистемы или отдельные методы/процедуры.
Преимуществами данных мер является то, что они:
блокируют возможность ошибочного действия по неосторожности полностью;
существенно затрудняют злоумышленнику сделать ошибочное действие;
если система отслеживает попытку ошибочного действия (СПО и ПО — через журнал событий, АО — через блок прослушивания), она может сообщить об этом, и на основе этого можно будет принять меры по привлечению к ответственности лица, попытавшегося произвести ошибку.
Необходимо отметить также и недостатки этого способа:
если планируется использовать разграничение по АО — нужно закупить такое оборудование, или модернизировать имеющееся, если возможно.
если планируется использовать разграничение по СПО или ПО — потратить множество времени и ресурсов на анализ возможностей каждой должности. Необходимо собрать не только из устава, описаний процесса или инструкций (если они имеются или к ним есть доступ) список прав, обязанностей и соотнести их с возможностями и объектами в системе, но также собрать информацию о реальной работе пользователей и с какими они объектами системы как работают. После внесения изменений, крайне высока вероятность появления инцидентов, когда пользователь жалуется на потерю ранее имеющейся или предполагающейся возможности. Следствием этого как минимум является понижение эффективности труда/удовлетворённости на короткий срок.
3. Создание мастер-данных или НСИ
Даже если пользователь имеет только те права в ИС, которые ему предусмотрены, это не значит, что он не сможет внести ошибочные данные. Краеугольным камнем проблемы всех информационных систем является неправильный ввод информации. ИС — это совокупность множества подсистем, и именно разница в введённых в них данных об одной и той же информации может привести к убыткам. Например, в бухгалтерии название организации пишут как ООО «Рога и Копыта», в то время как в отделе закупок название записывают как например «Общ. с орг. отв. Рога и Копыта». В результате для системы это будет две разные сущности, и когда менеджменту или отделу финансов понадобиться отчётность по предприятию, они могут получить ошибочные результаты и на основе этого получить убытки, столкнувшись с последствиями или пытаясь эту проблему решить.
Появление мастер-данных и MDM-систем (от англ. Master Data Management — управление мастер-данными) призвано решить эту проблему. Мастер-данные — это условно-постоянные данные, определяющие состав автоматизируемой предметной области и основу для описания бизнес-логики приложения, например, информация о потребителях, поставщиках, об оборудовании, организационной структуре предприятия, топологии сети.
Мастер-данные немыслимо без MDM. Чтобы обеспечить целостность и непротиворечивость данных, необходимо очистить их и нормализовать. За счет синхронизации информации из разных источников в системе удаляются дубликаты и устаревшие фрагменты, восполняются пробелы. Таким образом, в базе данных MDM собирается и накапливается только актуальная информация.
Основными задачами такой системы являются:
консолидация и централизованное хранение;
управление записями и их актуализация;
автоматизация ручного анализа и сбора данных из разных источников;
группировка данных по признакам и быстрый доступ к необходимой информации;
упрощение процесса формирования отчетности;
На сегодняшний момент существуют три вида MDM.
Централизованная система
Аналитическая система
Гармонизированная система
В первом случае, одна IT-система, будь она новая или уже существующая, собирает воедино все справочники и впоследствии считается единственно верной, с эталонными данными. Однако, недостатком является то, что редактирование этих записей в других системах становится невозможным.
Аналитическая система работает так, что из справочников различных IT-систем формируется общая база, где содержатся актуальные данные, при этом дубли могут сохраняться в исходных системах. Это решение позволяет быстро внедрять MDM, с минимальными изменениями в задействованных системах.
Сочетание первых двух подходов представляет собой гармонизированную MDM — наиболее эффективную систему управления данными. Эта система предполагает синхронизацию с внешними IT-системами, удаление дублированной информации, актуализацию данных через сравнение. Она также способна разрешать конфликты, возникающие при одновременном редактировании одних и тех же записей в различных IT-системах.
Решение о внедрении MDM-систем складывается из существующей ИТ-инфраструктуры предприятия, её потребностей и целей, а также возможностей. Внедрение этой системы, как и любой IT-проект — это риск, который нужно принять.
Многие существующие КИС имеют встроенную MDM-систему. Например, в 1С: ERP мастер-данные и MDM-система реализована в разделе «НСИ» (НСИ — нормативно-справочная информация). НСИ — это фиксированные, исходно наполняемые и изменяемые только в редких случаях справочники (общероссийские или внутренние классификаторы, справочники стран, регионов, валют и т. д.). В НСИ также ведётся сбор информации по каждой кросс-функциональной информации: о сотрудниках, реквизитах организации и контрагентов, ТМЦ (ТМЦ — товарно-материальные ценности) и т.д.
Подытожив всё вышесказанное, единственным, но очень важным преимуществом данного решения является достоверность информации в любой подсистеме, как следствие — стойкая опора для управленческих решений. Случайная ошибочность данных в такой системе сведена на нет. В условиях, когда информация — самый важный ресурс для организации, особенно корпораций, это преимущество заставляет управленческий персонал задуматься о внедрении данной системы.
Однако от повального внедрения этой системы в организации (особенно, небольшие) руководителей останавливают следующие объективные недостатки:
Высокая стоимость в денежном эквиваленте;
Отвлечение сотрудников, входящих в проектную команду, от их основных обязанностей, и как следствие — потерю части эффективности труда
Риск провала проекта
Возможность отсутствия нужного для компании решения, что актуально для российских компаний в связи с введением против России санкций, блокирующих возможность взаимодействия с иностранными вендорами и интеграторами.
4. Форматирование ввода данных
Данный метод заключается в создании формата ввода данных. Это не убережёт от опечаток, однако существенно снизит количество неверно введённых данных, не позволив пользователю ввести данные неверного формата и внести их в систему.
Формат данных заключается не только в определении типа объекта, например, тип строка (String, Text), число (Integer, Double, Float, Byte), булево, дата, и т.д., но также в определении маски ввода.
Маска ввода — это строка символов, указывающая формат допустимых значений входных данных. Несмотря на наличие регулярных выражений, символы и их значения разные для каждого ПО, языка программирования, системы.
Например, формат написания номера телефона +1 (234) 567–89–01 будет выглядеть по-разному:
Как регулярное выражение запись будет выглядеть так:
[\+]0–9 \({0–9}(3)\) {0–9}(3)(\-{0–9}(2))
Где [\+] означает, что номер телефона может быть без +;
0–9 — любой символ от 0–9;
{выражение}(множитель) — показывает, сколько раз повторить выражение;
Символ »\» экранирует круглые скобки, знак плюса и минуса, так как они являются метасимволами (то есть символами, универсальными для любой грамматики), но при этом участвуют в написании маски как обычные символы. В таком случае их называют терминальными.
В системе управления базами данными (СУБД) MS Access подобная запись будет выглядеть иначе:
+9 (999) 999–99–99 или
+0 (000) 000–00–00
Где »0» означает, что пользователь должен ввести цифру от 0 до 9;
а »9» означает, что пользователь может ввести цифру от 0 до 9.
Различия в записи становятся очевидными, если сравнить каждый язык или ПО между собой. Например, в том же MS Access требование или возможность ввести только букву отображается как соответственно «L» или »?», хотя во встроенном языке программирования 1С запись разделятся ещё и на регистр:
»@» | «U» — ввод символов алфавита и чисел, и при этом они будут преобразованы в верхний регистр;
«N» — разрешен ввод алфавитных символов и чисел, но уже можно контролировать регистр;
»!» — любой введенный символ автоматический преобразуется к верхнему регистру;
«X» (латинская буква «икс») — разрешен ввод только латиницы.
Недостатком, конечно, это нельзя назвать. Один разработчик не сможет запутаться в значениях символов, так как вряд ли будет использовать несколько разных языков программирования. А аналитикам, которые создают технические задания для разработчиков разных ЯП, необходимо знать только общие для всех регулярные выражения.
Таким образом, выгодами от форматирования данных является:
снижение количества ошибочно введённых данных;
низкая затратность на воплощение относительно других методов, не нужно поддерживать;
возможность указывать несколько масок для разных условий (для нашего примера, разные маски для городского или мобильного номера)
Однако, существенными недостатками являются:
отсутствие проверок семантических (смысловых) ошибок написанного. Даже если пользователь написал название своей организации по формату как ООО »{Аа-Яя | » »}+», но при этом допустит опечатку (ООО «Рпга и Кпыта»), система допустит ввод ошибочного значения.
трудность добавления после введения системы в эксплуатацию. Ранее введённые данные после приведения к формату могут исказиться или вовсе не добавиться в систему.
В целом, это базовый метод, который обязаны знать как аналитики, так и разработчики на этапе проектирования и разработки ИС. Затраты на форматирование данных зависят от того, как поздно это добавить в систему.
5. Ограничения на уровне проектирования реляционных баз данных
Реляционные системы управления базами данных (РСУБД) позволяют контролировать данные, помещаемые в таблицу. Этот контроль выполняется при помощи ограничений.
Ограничения в SQL (Structured Query Language — «язык структурированных запросов») — это правило, применяемое к столбцу, которое определяет, какое значение в него можно записать, а какое нет. Если введённая строка информации не соответствует хотя бы одному правилу, то запись строки (отдельной записи) отменяется и выдаётся соответствующая ошибка.
Стандарт SQL формально определяет всего пять ограничений:
PRIMARY KEY
FOREIGN KEY
UNIQUE
CHECK
NOT NULL
PRIMARY KEY, или по-русски «первичный ключ» — это ограничение на столбец, который совмещает в себе два ограничения — UNIQUE, то есть «особенный», «неповторимый», и NOT NULL, «непустой».
Это ограничение позволяет любому экземпляру, который заносится в таблицу, присвоить уникальное значение (обычно, типа integer), которое однозначно идентифицирует запись среди прочих других.
Это поле бывает необходимым, когда есть малейшая вероятность повторения у разных объектов одних и тех же значений атрибутов. Например, если в таблице employees есть только атрибуты firstName (имя) и lastName (фамилия), то велика вероятность дублирования данных и нарушения целостности данных. Этого можно избежать, если добавить поле id, которое автоматически будет присваивать номер новой строке. Таким образом, даже если у двух сотрудников будут совпадать имя и фамилия, их всё равно в системе можно будет различить, как раз по значению первичного ключа id.
Необходимо отметить, что PRIMARY KEY разделяются на два типа: естественные и суррогатные ключи. Естественный — это тот атрибут, который есть у объекта в реальном мире. Например, номер телефона или номер документа. То есть нелогично делать столбец id, если есть столбец passportNumber, так как номер паспорта удовлетворяет критериям, чтобы стать первичным ключом.
Суррогатным же называют тот атрибут, которую сущность не имеет в реальном мире. Например, у человека с рождения есть ФИО, но нет никакого id, поэтому без дополнительных атрибутов, может быть проблематично выяснить, каким записям соответствуют люди с одинаковым ФИО.
Рекомендуется всегда использовать естественные ключи, так как по сравнению с суррогатным он использует меньше дискового пространства и его легче соотнести реальным объектом.
FOREIGN KEY, или внешний ключ, позволяет связать между собой запись об одной и той же сущности в разных таблицах. Это столбец в одной (дочерней) таблице, значения которого берутся из столбца в другой (родительской) таблице. Это способ выразить связь между двумя таблицами: ограничение FOREIGN KEY требует, чтобы значения в столбце, к которому оно применяется, уже существовали в столбце, на который оно ссылается.
Вспоминая пример выше с таблицей работников, мы можем создать таблицу salaryForDate, где будет указана выплаченная зарплата сотрудников за текущий месяц. Для предотвращения тех же ошибок, дублирования данных и нарушения целостности данных, мы сделаем столбец id_employees в этой таблице внешним ключом столбца id ранее созданной таблицы employees. Таким образом, чтобы добавить запись о выплате з/п сотруднику, нам нужно знать его id в таблице employees, и нам не нужно будет волноваться о несоответствии сущностей в этих двух таблицах.
Однако следует озаботиться следующим: скольким записям в родительской таблице будет соответствовать записей в дочерней. Либо отношение »один к одному», то есть одному сотруднику соответствует только одна выплата, значит и в таблице salaryForDate нужно придумать своё поле id, например, номер транзакции; или »один ко многим», то есть одному сотруднику может быть сделано несколько выплат.
При проектировании базы данных, нужно избегать отношения »многие ко многим», так как это нарушает принцип неизбыточности данных, а также имеет аномалии каскадного удаления (каскадное удаление — автоматическое удаление связанных записей при удалении родительской записи), обновления и вставки.
Также существует тип ограничения CHECK, который позволяет устанавливать свои требования. Например, очевидно, что в компании не могут работать сотрудники старше 1900 года рождения, так что мы можем добавить соответствующее ограничение на столбец birthYear.
CHECK (birthYear > 1900)
Таким образом, преимуществами метода создания ограничений в базе данных являются:
Избавления от дублирования информации;
Обеспечение целостности данных;
Проверка корректности введённых данных;
Соблюдение бизнес-правил (бизнес-правило — это указания, которые определяют или ограничивают работу КИС. Бизнес-правила устанавливают бизнес-структуру и влияют на деятельность компании. Их источниками могут быть как вышестоящие органы, так и сама организация).
Недостатками этого метода является сложность разработки. Существует множество принципов и правил проектирования реляционных баз данных (как минимум — шесть нормальных форм (НФ)), которые с одной стороны, дают вышеописанные преимущества, с другой стороны требует профессионализма у специалистов, которые разрабатывают базу данных, и определённой степени развития архитектуры предприятия.
