36
Процесс управления рисками - это процесс выявления, контроля и
устранения или минимизации последствий непредсказуемых событий.
Практически все риски, независимо от категорий, источников, подходов к
их управлению, можно классифицировать с нескольких разных позиций:
Собственные и предельные риски.
Классификация оценки риска операции, финансового инструмента вне и
внутри определенной деятельности, портфеля.
Собственный риск - оценка риска отдельной операции, финансового
инструмента отдельно от контекста операции или портфеля, который включает
финансовый инструмент.
Предельный риск - это величина, на которую изменяется оценка риска
деятельности всей деятельности, когда для оценки добавляется транзакция или
финансовый инструмент. Например, если отдельная сделка по покупке акций
РАО ЕЭС несет с собой рыночный риск, связанный с возможной
неблагоприятной переоценкой приобретенных акций, то такая же операция, если
она добавлена в портфель с короткой позицией в РАО ЕЭС, уменьшит
рыночный риск портфеля. Из этого примера также следует, что предельный риск
может быть отрицательным значением. При реализации процедур управления
рисками предельный риск представляет наибольший интерес, но его технически
сложнее получить, чем получить собственный риск.
Статические и динамические риски.
Классификация рисков по значимости для организации.
Динамический риск - это риск случайных колебаний результатов
деятельности как в худшую, так и в лучшую сторону, который не может оказать
существенного влияния на жизнеспособность организации. Как правило, это
спекулятивные риски, которые при принятии их организацией слабо
коррелируют друг с другом.
Статический риск - это риск событий, ситуаций, в результате которых
возникает угроза будущей деятельности организации, жизнеспособность
отдельных действий, отдельных проектов. Это риск качественных,
катастрофических потерь в результате презентации, которые организация
больше не сможет функционировать, как раньше.
37
Систематические и несистематические риски.
Классификация рисков с точки зрения их отображения в модели рисков.
Систематический риск - это риск, связанный с факторами, которые
считаются значимыми в модели. Систематические риски не должны быть
значительно снижены в большом портфеле или во времени, в противном случае
их определяющие факторы следует игнорировать, и эти риски можно
классифицировать как несистемные. Систематические риски являются основным
предметом исследований в области оценки и управления рисками.
Несистематический риск - это риск, источники и чувствительность
которого не учитываются в рамках модели оценки и управления рисками. При
построении адекватной модели бессистемные риски не должны приводить к
каким-либо значительным потерям, а при большом их количестве не должны
быть связаны друг с другом. Что касается несистематических рисков, должен
существовать закон больших чисел, определяемый путем анализа отдельных
элементов деятельности организации, отдельных компонентов определенного
портфеля ценных бумаг, в течение некоторого короткого периода времени в
рамках всей организации, портфеля или с течением времени их вклада. к
потенциальным потерям будет стремиться к нулю. Несистематические риски
обычно игнорируются при решении задач оценки и управления рисками.
Классическим примером систематических и несистемных рисков
являются риски портфеля корпоративных акций, когда он анализируется с
использованием бета-модели. В этом случае риски изменения цен, связанные с
изменениями индекса фондового рынка, будут систематическими, а изменения
цен из-за других, возможно, индивидуальных факторов для каждой акции будут
несистематическими. Очевидно, что эффективность этого подхода зависит от
структуры портфеля, к которому он применяется. Для хорошо
диверсифицированного портфеля модель будет достаточно хорошо отражать
реальность, но в случае портфеля из одной или двух ценных бумаг рассмотрение
отдельных рисков акций как несистематических может привести к значительным
ошибкам.
На этапе разработки концепции могут возникнуть следующие риски:
• Недальновидный анализ времени и бюджета проекта
38
Чтобы устранить этот вид риска, необходимо более детально проработать
цели и задачи проекта и установить больше контрольных точек.
• Неправильно выбранный персонал проекта может привести к полному
отсутствию командной работы.
Этот риск снижается благодаря более тщательному отбору специалистов в
проектной группе путем проверки не только профессиональных навыков, но и
личных качеств.
На этапе планирования могут возникнуть следующие риски:
• Неправильно или не совсем правильно сформированная архитектура
выбранного решения.
Возможность возникновения этого риска зависит от компетенции
менеджера проекта, который отвечает за выбор архитектуры разработанного
решения.
На этапе разработки возможны следующие риски:
• Неправильная интерпретация технической спецификации и, как
следствие, неправильное программирование архитектуры и временного сдвига.
Минимизация этого риска - более четкое написание технического задания,
понятного программисту.
• Другим важным риском в этом проекте является отсутствие надлежащей
квалификации программиста на языке, на котором было принято решение
реализовать клиентскую программу, которая будет распределять приложения
среди инженеров.
В случае, если программист не укладывается в указанные временные
рамки графика проекта, используйте внешнего разработчика, так называемого
«аутсорсинга» или «внештатного сотрудника», чтобы пройти.
На этапе тестирования могут возникнуть следующие риски:
• Риски неполного тестирования.
Может случиться, что программный продукт не полностью
протестирован.
Это решается повторным тестированием на следующей итерации
разработки.
На этапе реализации могут возникнуть следующие риски:
39
• Риски неправильного решения о законченности проектной части.
Возникновение этих рисков приводит к проблеме неполных решений и
возможности несоответствий с другими частями разрабатываемой ИС.
Исключается путем уточнения на следующей итерации.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Создание систем информационной безопасности в ИС основано на
следующих принципах: системный подход, принцип непрерывного развития
системы, разделения и минимизации полномочий, полноты контроля и
регистрации попыток, обеспечения надежности системы защиты, обеспечение
контроля функционирования системы защиты, предоставление различных
средств защиты от вредоносных программ, обеспечение экономической
целесообразности.
В результате решения проблем информационной безопасности
разработанная информационная система должна иметь следующие основные
характеристики:
- Доступность информации различной степени конфиденциальности.
- Обеспечение криптографической защиты информации различной степени
конфиденциальности при передаче данных.
- Иерархия полномочий субъектов доступа к компонентам ИС.
- Обязательное управление информационными потоками, как в локальных сетях,
так и во время передачи по междугородним каналам связи.
- Наличие механизма предотвращения несанкционированного доступа.
- Обязательная целостность программного обеспечения и информации.
- Наличие средств восстановления системы восстановления информации.
Основу нормативно-правовой базы составляют нормы и правила компании,
сервисы и средства, реализующие функции защиты информации, различные
виды методов, обеспечивающие деятельность пользователей при выполнении
работ в условиях строгих требований конфиденциальности.
Любая информационная система потенциально подвержена угрозам
безопасности - краже данных или сбоям в работе системы. Поэтому
40
разработчики IP-пользователей должны позаботиться о пользователях и их
безопасности.
Комплексная защита информации в компьютерных сетях предполагает
реализацию четырех уровней защиты:
- правовые (правовые нормы, законы; незаконное использование секретных
данных или информации, составляющей объект авторского права, преследуется
по закону)
- административные / организационные (определяется, кто и какую информацию
может собирать и хранить; способы доступа к ней и условия ее распространения,
права и обязанности работников, их компетенция и ответственность;
должностные инструкции)
- аппаратно-программное обеспечение (с использованием процедуры
идентификации пользователя, обеспечивающей доступ к данным и
программному обеспечению). Аппаратная защита может быть реализована в
виде кодовой карты, ключа и т. Д. Самым слабым местом в системе
информационной безопасности является персонал. Люди обычно отказываются
использовать какие-либо дополнительные средства, которые причиняют им
неудобства в работе. Поэтому использование аппаратной защиты требует
административной поддержки.
- криптографический (шифрование данных, чтобы скрыть свои значения от
злоумышленника). Пока пользователь не идентифицируется по ключу, значение
данных ему недоступно.
Административно-правовой уровень
В целях снижения рисков от внутренних угроз «Ситилинк» имеет
политику безопасности компании. Необходимо доработать нормативные
правовые акты по внутренней политике безопасности компании, с учетом
внедренного IP на складе, правила предоставления прав доступа к IP склада
должны быть добавлены к политике предоставления прав доступа к
информационным ресурсам.
Ответственным за соблюдение политики безопасности в подразделении
«Склад» должен быть назначен системный администратор, отвечающий за это
подразделение.
41
Организационно-процедурный уровень
Для обеспечения информационной безопасности в системе складского
учета необходимо:
- разграничить права пользователей на доступ к информационной системе;
- защищать папки с файлами и системными базами данных от
несанкционированного доступа;
- регулярно проводить архивирование данных.
Во-первых, следующие пользователи должны иметь доступ к справочникам
системы:
- менеджеры отдела закупок;
- отдел сбыта;
- кладовщик приемной площадки;
- кладовщик участка отгрузки;
- контролер качества приемного отдела.
Клиентские компьютеры будут установлены на их компьютерах, через
которые будет возможен доступ к определенным функциям системы, в
зависимости от занимаемой должности. В таблице 2.1.3 представлены данные о
разграничении прав доступа для разных групп пользователей.
Во-вторых, каждый пользователь должен иметь учетную запись,
защищенную паролем, состоящим из латинских букв и цифр длиной не менее 8
символов. Пароль следует менять не реже одного раза в год. Учетные записи
должны контролироваться системным администратором. Должно быть
ограничение на количество неудачных попыток входа в систему (не более 3
попыток), чтобы затруднить расшифровку паролей. Кроме того, вы должны
ограничить доступ к файлу паролей.
В-третьих, необходимо физически защитить серверную систему от
несанкционированного доступа. Он должен быть установлен в специальной
серверной комнате, запертой на ключ, или в запертом шкафу. Доступ к файлам
на жестком диске сервера должен быть закрыт для всех пользователей
локальной сети. Также в надежном месте должны храниться носители с
резервными копиями базы данных.
42
Группы
пользоват
елей
Справочник
и системы
Модуль
«Приемка
товара»
Модуль
«Отгрузка
товара»
Модуль
«Приемка по
качеству»
Отчеты
Менедже
ры отдела
закупок
Чтение
Доступ
ограничен
Нет доступа
Доступ
ограничен
Чтение
Отдел
сбыта
Чтение
Нет доступа
Доступ
ограничен
Нет доступа
Чтение
Начальни
к склада
Полный
доступ
Чтение
Чтение
Чтение
Чтение
Кладовщ
ик
участка
приемки
Доступ
ограничен
Полный
доступ
Нет доступа
Доступ
ограничен
Полный
доступ
Кладовщ
ик
участка
отгрузки
Доступ
ограничен
Нет доступа
Полный
доступ
Нет доступа
Полный
доступ
Контроле
р участка
приемки
по
качеству
Доступ
ограничен
Чтение
Нет доступа
Полный
доступ
Чтение
Бухгалтер
ия
Полный
доступ
Нет доступа
Нет доступа
Нет доступа
Полный
доступ
Сис.
Админ.
Полный
доступ
Полный
доступ
Полный
доступ
Полный
доступ
Полный
доступ
Таблица 2.1.3 – Разграничение прав пользователей
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Построение инфологической модели базы данных мы начнем с
реализации диаграммы потока данных (DFD). Стандарт описания бизнес-
процессов DFD – переводится как диаграмма потоков данных и используется
для описания процессов верхнего уровня и описания реальных потоков данных в
организации. Созданные модели потока данных компании могут быть
использованы для решения таких задач, как:
1. определение существующих хранилищ данных (текстовые документы, файлы,
система управления базами данных - СУБД);
2. определение и анализ данных, необходимых для выполнения каждой функции
процесса;
43
3. подготовка к созданию модели структуры данных организации, так
называемой ERD-модели (IDEF1X);
4. Выбор основных и вспомогательных бизнес-процессов организации.
Диаграммы потоков данных показывают, как каждый процесс преобразует
свои входные данные в выходные данные, и определяет взаимосвязь между
этими процессами. DFD представляет смоделированную систему как сеть
связанных работ.
Есть две схемы обозначений: графические обозначения Джордан де Марко
и Хейн-Сарсон. Разница заключается в графических формах объектов. [2]
Основными объектами обозначений являются:
• Процессы (Действия). Отображает процессы обработки и изменения
информации;
• Стрелы. Отображение информационных потоков;
• Хранение данных (Data Store). Отображение данных, к которым
осуществляется доступ, эти данные используются, создаются или
модифицируются работами;
• Внешние объекты (Внешние ссылки). Отобразить объекты, с которыми
происходит взаимодействие.
Работник склада
Склад
Т «Смартфоны»
Т «Ноутбуки»
T
«Телевизоры»
Спр.
«Поставщики»
Товарно-
транспортная
накладная
Спр. «Прайс-
лист»
Спр. «Прайс-
лист»
Спр. «Прайс-
лист»
Клиент
Кладовщик
Приходная
накладная
Журнал учета и
заявок
Рисунок 2.2.1 – Информационная модель
44
Информационная модель отображает процесс приемки товаров на склад:
- кладовщик участка приемки вводит в систему данные первичного документа
«Приходная накладная» и результаты приемки по количеству;
- введенные данные сохраняются в таблицах «Телевизоры», «Смартфоны» и
«Ноутбуки»;
- на основе этих данных формируются результатные документы «Журнал учета»
Работник склада и кладовщик имеют полный доступ ко всему модулю «Склад».
Цель моделирования инфологов - предоставить наиболее естественные
для человека методы сбора и представления информации, которая должна
храниться в создаваемой базе данных. Поэтому они пытаются построить
инфологическую модель данных по аналогии с естественным языком, но
естественный язык не может использоваться в чистом виде из-за сложности
компьютерной обработки текстов и неоднозначности любого естественного
языка. Основными конструктивными элементами инфологических моделей
являются сущности, отношения между ними и их свойства (атрибуты). [3]
Чтобы определить входные и выходные данные и построить модель
инфологической базы данных, мы более подробно рассмотрим операции,
которые происходят на складе:
Разгрузка товара. Это первый этап поступления товара на склад. Чтобы
осуществить доставку на склад, вам нужно знать, кому нужно разместить заказ
на желаемый продукт, поэтому вы можете определить сущность «Поставщики»,
которая хранит информацию о компании в виде атрибутов (название компании,
адрес, телефон, электронная почта, а также различные банковские и
юридические реквизиты). Поскольку поставщики доставляют нам товар,
определяется субъект «Доход», в атрибутах объекта хранится информация о
доставке (название продукта, дата доставки, количество продукта и цена
продукта).
Приемка товаров. Обычно проводится очистка (при необходимости),
предварительная регистрация и маркировка товара с помощью информационных
ярлыков. Предварительная регистрация осуществляется по счету, который
хранит работник склада, который также маркирует товар.
45
Размещение для хранения. Из названия видно, что эта операция формирует
задачу хранения товаров. Мы знаем, что на складе есть различные товары,
названные как товары. Хранящиеся товары нужно измерять во что-то, чтобы вы
могли определить сущность «Единицы измерения», в атрибуте которой хранится
название единицы измерения. Поскольку товары на складе разнообразны, то для
удобства и сокращения времени на размещение и отбор товаров необходимы
отделы товаров. В отдел входят определенные группы товаров. Отсюда мы
выбираем объекты «Отделы» и «Группы». Атрибутами будет название отдела
товаров.
Подбор товаров со складов. Эта операция происходит по нескольким
причинам, одной из которых является необходимость продажи размещенного
товара. Чтобы продать продукт, нам нужно знать, кому продавать, поэтому нам
нужны клиенты, появляется объект «Клиенты», атрибуты которого содержат
необходимую информацию о клиентах (имя клиента, тип, адрес, телефон,
электронная почта и т. Д.). некоторые банковские реквизиты). У клиента может
быть договор с нашей компанией на оптовые продажи, поэтому мы выделим
суть договора, включая номер договора, дату и процент скидки.
Остальные операции (сбор и упаковка товаров, погрузка, перемещение
товаров внутри склада) также используются работниками склада,
носильщиками.
В связи с тем, что сам склад необходим для работы с товаром, смело
можно назвать сущность «Товар», в атрибутах которой будет храниться
информация о товаре (наименование товара, отдел, группа, единица измерения,
цена, количество и комментарий).
Мы также определим вспомогательные объекты, необходимые для
управления пользователями, работающими с программным продуктом, и
некоторые другие: сотрудники, должности, организация (хранит адрес, название
компании и данные учетной записи, используемые в документах).
Выходные данные генерируются на основе существующих данных, в
конкретном случае делаются выписки, счета-фактуры, товарный чек, счет-
фактура и прайс-лист (документы должны быть отображены и распечатаны), а
также справочники.