Методика выбора информационной системы для автоматизации бизнес-процессов (БП) на предприятиях

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Оглавление

Введение

Глава 1. Анализ подходов к решению задачи выбора ИС из множества альтернатив

1.1 Анализ существующих решений задачи многокритериального выбора ИС из множества альтернатив

1.2 Экспертный подход к разработке критериев для выбора автоматизированной информационной системы

1.2.1 Затратные методы

1.2.2 Методы оценки прямого результата

1.2.3 Методики, основанные на идеальности процесса

1.2.4 Квалиметрические методы

1.2.5 Сравнение методов оценки эффективности внедрения ИС

1.3 Метод совокупного экономического эффекта

1.3.1 Обобщённые критерии выбора ИС

1.3.2 Метод расчёта совокупной стоимости

1.3.3 Рассмотрение подходов к обоснованию выбора ИС на примере системы бюджетирования и финансового планирования

Выводы

Глава 2. Представление и генерация журналов регистрации событий в различных системах

2.1 Стандарт представления журналов регистрации событий: PCI DSS

2.1.1 Основные положения, необходимые условия внедрения стандарта

2.1.2 Требования в части журналирования событий

2.2 BPMS-системы

2.2.1 Runa WFE

2.2.2 Bizagi Studio

2.3 Workflow-системы

2.4 1С: Предприятие8

Выводы

Глава 3. Анализ логов событий и формирование системы взвешенных критериев

3.1 Метод получения системы взвешенных критериев

3.1.1 Получение весов критериев

3.1.2 Weighted Sum Method

3.1.3 Процесс получения системы взвешенных критериев

3.2 BizAgi-Studio

3.3 Rapid Miner - ProM библиотека

3.4 Disco Analysis Studio

Выводы

Заключение

Список литературы

Введение

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

Отправным этапом решения проблемы является анализ предметной области. Широко распространенным подходом к анализу предметной области является онтологическое моделирование. В данном научном направлении работают многие ученые: И.Л. Артемьева, Т.А. Гаврилова, В.В. Грибова, T. Gruber, N. Guarino, J. Lugger, D. McGuinness, N. Noy, R. Studer.

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

Задачи выбора наилучшей альтернативы отличаются большим разнообразием и решаются различными методами в зависимости от типа входной информации. Однако в реальных задачах принятия решений критерии выбора взаимозависимы, следовательно, традиционные операторы агрегации на основе аддитивных мер для объединения таких критериев не применимы. Для моделирования субъективного принятия решений используются нечеткие меры (G. Choquet, M. Grabish, M. Roubens, M. Sugeno), а в качестве оператора агрегации применяются нечеткие интегралы (А.Н. Алфимцев, С.Л. Блюмин, В.В. Девятков, M. Detyniecki, C. Labreuche, J. Marichal). Несмотря на обширные исследования в рассматриваемой области, которые показали высокую адекватность нечетких моделей при решении отдельных задач, до сих пор не найдено оптимальное решение проблемы выбора наилучшего программного продукта, которое бы исключало влияние предпочтений покупателей, но учитывало их функциональные потребности ИС.

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

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

Объект исследования: методика выбора информационной системы для автоматизации бизнес-процессов (БП) на предприятиях.

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

Цель работы: разработать методику, формирующую систему критериев и их весов сводящую к минимуму влияние предпочтений экспертов на процесс выбора ИС для автоматизации БП на предприятиях.

Задачи:

1) проанализировать подходы к разработке критериев для выбора информационной системы автоматизирующей БП предприятия;

2) проанализировать стандарты и требования к представлению и получения протоколов работы из ИС;

3) смоделировать и сгенерировать с помощью ИС протоколы работы при выполнении экземпляров БП;

4) разработать метод, позволяющий из моделей БП, построенных на основе протоколов ИС, преобразовывать в систему взвешенных критериев;

5) провести проверку применимости разработанного метода на примере протокола реального БП.

Глава 1. Анализ подходов к решению задачи выбора ИС из множества альтернатив

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

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

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

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

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

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

1.1 Анализ существующих решений задачи многокритериального выбора ИС из множества альтернатив

А.А. Белых в своей работе посвященной разработке методологии прогнозирования и оценки эффективности информационных систем заостряет внимание на необходимость анализа системы в текущем состоянии, а также прогнозирования эффективности ИС через некоторый промежуток времени (с учётом изменяющихся требований к ИС и возрастающих вычислительных мощностей) [6]. Процесс оценивания эффективности систем выполняется в несколько этапов, и заключительным является учёт гносеологической и структурной сложности человеческого фактора, охватывающего предпочтения пользователей системы. Основной упор в работе сделан на рассмотрение актуальности системы в прогнозируемом будущем, а проблема человеческого фактора решается с помощью методов системного анализа.

Мещеряков О.А. в работе посвященной разработке моделей и алгоритмов многокритериального выбора систем планирования ресурсов агропромышленных предприятий решает задачу объективной оценки экономической эффективности внедрения на предприятиях новых ИС. В ходе работы, им решается проблема ошибочных оценок функциональных возможностей ИС и их производительности, а также вопросы тестирования специализированного ПО. Среди проблем, обозначенных в данной работе, также присутствует проблема субъективизма выбора ПО на основе опыта и личных предпочтений, однако в ходе работы, ей не было уделено должного внимания, а основной упор был сделан на алгоритмы оценки функционального соответствия и оценку стоимости владения системами [5]. Таким образом, формализованный алгоритм выбора наилучшей ИС всё ещё остаётся субъективным, в силу влияния человеческих предпочтений и опыта, который присутствует в алгоритме в виде экспертных оценок значимости критериев оценивания систем.

Ахаев А.В. в работе «Методика, модели и алгоритмы выбора программных продуктов на основе онтологии и нечёткой меры» осуществляет выбор ПП на основе двух факторов: бизнес предпочтений, отражающие общие требования к ПП, которые определяют область применения ПП и пользовательские предпочтения, отражающие специализированные требования к ПП, которые определяют соответствие функциональных возможностей в ПП [4]. При этом, для полного и корректного учёта предпочтений и оценок экспертов, используется интеграл Шоке, являющийся инструментом аппарата нечётких множеств, нечётких мер и интегралов. Таким образом, интеграл Шоке агрегирует множества экспертных оценок с функциональными и общими требованиями к ПП и определяет множество бизнес и пользовательских предпочтений, однако не решает проблему субъективности оценок экспертов.

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

1.2 Экспертный подход к разработке критериев для выбора автоматизированной информационной системы

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

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

(1.1)

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

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

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

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

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

· Квалиметрические подходы рассматривают ИС, как сложные иерархически зависимые программные комплексы, с различными параметрами работы на каждом уровне иерархии. При анализе используются экспертные, социологические и статистические методы [1].

Рассмотрим каждую группу методов более подробно.

1.2.1 Затратные методы

Выделяют три основных затратных метода оценки:

· котловой метод;

· метод функциональной точки;

· метод совокупной стоимости владения.

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

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

Метод совокупной стоимости владения (total cost of ownership ТСО) представляет собой экономическую оценку затрат, необходимых для приобретения, внедрения и сопровождения программного обеспечения, и в общем случае, рассчитывается по формуле:

(1.2)

где З^приобр - затраты на приобретение ИС (базовая стоимость ИС, без доработок), З^внедр - затраты на внедрение ИС, включающие в себя затраты: на установку вспомогательного ПО, на доработку ИС, на обучение персонала и т.д., З_t-затраты на поддержку, обслуживание ИС, понесённые в период времени t. Часто можно встретить данную формулу, с учётом процентной ставки (ставки дисконтирования) для затрат на поддержку и обслуживание ИС.

В статье [26] описывается метод оценки совокупной стоимости владения системой и приводится пример его использования, с привлечением экспертов, оценивающих каждую статью затрат, исходя из своих знаний предметной области. Преимуществом такого подхода является использование математического аппарата при подсчёте стоимости системы. Также можно использовать различные методы экспертных оценок, например, покер планирование или метод Дельфи.

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

1.2.2 Методы оценки прямого результата

К методам оценки прямого результата относят:

· метод потребительского индекса;

· оценка источников экономической стоимости;

· оценка добавленной стоимости.

Метод потребительского индекса (customer index) предполагает оценку результатов внедрения ИС в виде совокупности индексов, отражающих положительные изменения в работе компании (увеличение доходов, снижение затрат, увеличение оборотов, увеличение клиентской базы и т.п.). Также, к этому классу методов относят метод, основанный на оценке прикладной информационной экономики (Applied information economics - AIE), но в дополнении к методу потребительского индекса, отражает измерение различных субъективных факторов, например, удобный интерфейс подсистемы работы с клиентами, степень удовлетворённости клиентов и т.д.

Оценка источников экономической стоимости (economic value sourced - EVS). Оценивает положительный эффект от внедрения ИС, рассчитанный по строго установленному перечню: повышение выручки/прибыли, сокращение времени выполнения БП, повышение производительности труда, минимизация рисков.

Оценка добавленной стоимости (economic value added - EVA) рассчитывается по бухгалтерскому балансу деятельности предприятия и равняется добавленной чистой операционной прибыли за вычетом изменения стоимости капитала компании. Но для применения данного метода к ИТ проектам, следует учитывать следующее:

· при использовании капитала в ИТ проектах, необходимо учитывать его стоимость, за него необходимо платить также, как и за труд работников;

· предполагается, что ИТ-специалисты продают свои услуги другим подразделениям по рыночным расценкам.

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

1.2.3 Методики, основанные на идеальности процесса

Группа методов, основанных на сопоставлении рассматриваемого проекта внедрения ИС с аналогичными проектами внедрения (Best Practice). Таким образом, чем больше схожих признаков рассматриваемого проекта, с неким примером внедрённой системы, тем выше вероятность того, что рассматриваемая система является наиболее подходящей в рамках проекта внедрения.

К таким методам относятся:

1. оценка среднеотраслевых результатов;

2. Gartner measurement;

3. оценка коэффициента возврата инвестиций.

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

Gartner Measurement (Гартнер-измерение). Выбор ИС основывается на основании отчётов компании Gartner, которые оценивают ИС по двум критериям, определяющих эффективность систем конкретного вида. При этом, анализ проводится не только по функциональным возможностям систем, но и учитывает мнения и опыт клиентов опробовавших эти системы.

Для этого проводится оценка следующих показателей:

· трудозатраты на установку и настройку системы;

· степень проработанности функциональных модулей;

· среднее количество пользователей системы;

· среднее и пиковое число транзакций в единицу времени;

· себестоимость проведения транзакции;

· среднее и пиковое время отклика системы;

· качество и полнота обучающих материалов к системе;

· стоимость поддержания ИС на одного пользователя.

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

Коэффициент возвратности (окупаемости) инвестиций (Return of investment - ROI) - финансовый коэффициент, иллюстрирующий уровень доходности проекта, учитывая сумму сделанных инвестиций. Его смысл заключается в анализе и выборе только типовых «коробочных» решений, которые бы были оптимальны с точки зрения сроков возврата инвестиций в ИС.

1.2.4 Квалиметрические методы

Квалиметрически методы включают в себя:

1. модель совокупного экономического эффекта;

2. сбалансированную систему показателей.

Модель совокупного экономического эффекта (Total economic impact - TEI) - это модель, построенная на основе модели TCO (расчёт затратной компоненты), а получаемый от внедрения эффект рассчитывается исходя из следующих принципов:

· Оценка преимуществ, подразумевающая сопоставлений бизнес-процессов AS-IS и TO-BE (как было - как будет). Такое сравнение и количественная оценка различий процессов, позволяет определить преимущества и недостатки оцениваемых ИС. Для такого анализа, используются методы онтологического моделирования и Process Mining.

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

· Оценка рисков производится на основе вероятности финансовых потерь при выборе системы с заданным уровнем затратной компоненты.

Сбалансированная система показателей (Balanced scorecard - BSC) представляет собой систему стратегического управления предприятием на основе анализа и прогнозирования эффективности её работы через вектор показателей, включающий в себя различные аспекты деятельности предприятия (производственные, маркетинговые, финансовые).

К таким показателям относятся:

· критические факторы успеха (Critical Factors of Success, CFS) - стратегические показатели: финансы, клиенты, внутренние бизнес-процессы, обучение и рост;

· ключевые показатели эффективности (Key performance indicators, KPI), включая достигнутые результаты деятельности компании.

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

1.2.5 Сравнение методов оценки эффективности внедрения ИС

Выбор универсального метода оценки эффективности внедрения ИС должен основываться на следующих положениях:

· метод должен оценивать затраты и положительные эффекты;

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

· метод должен быть универсальным, т.е. должно быть доступно изменение параметров анализа и эти изменения должны улучшить точность выбора.

Сравнение методик оценивания эффективности внедрения ИС приведено в таблице 1.1.

Таблица 1.1 - Выбор методик оценивания эффективности внедрения ИС.

Метод	Оценка эффекта и затрат	Определение эффекта для систем бюджетирования	Необходимость глубокого обследования организации	Универсальность
Котловой метод	затраты	не считается	не требуется	универсален
Метод функциональной точки	эффект, затраты	применим	не требуется	не универсален
ТСО	затраты	не считается	не требуется	универсален
Потребительский индекс	эффект	не применим	требуется	не универсален
AIE	эффект	применим	не требуется	универсален
EVS	эффект	не применим	требуется	не универсален
EVA	эффект, затраты	применим	требуется	универсален
Среднеотраслевые результаты	эффект	не применим	не требуется	универсален
Gartner Measurement	эффект, затраты	применим	не требуется	универсален
Return of investment	эффект, затраты	не применим	не требуется	универсален
TEI	эффект, затраты (ТСО)	применим	не требуется	универсален
BSC	эффект, затраты	применим	требуется	универсален

Только два метода оценки соответствуют всем перечисленным факторам: это Gartner Measurement и TEI.

Сложность применения на практике метода Gartner Measurement, для выбора автоматизированной ИС, состоит в наличии подготовленного компанией Gartner исследования для данной предметной области и с анализируемыми альтернативами. Этот фактор делает затруднительным использование Gartner Measurement для выбора ИС, особенно в России.

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

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

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

Более подробно, метод TEI и TCO рассмотрены в следующей подглаве.

1.3 Метод совокупного экономического эффекта

Совокупный экономический эффект (TEI) рассчитывается по четырём блокам:

1) преимущества;

2) гибкость;

3) риски;

4) стоимость владения (TCO).

Понятно, что чем полнее программный продукт соответствует функциональным потребностям предприятия, тем лучше. Однако доработка программы обычно неизбежна, и если она обещает быть значительной (более 25% функционала исходной программы), то предприятие станет ее заложником, к тому же потребуется содержать внушительный штат IT-специалистов. Скорее всего, затраты на проект значительно превысят бюджет, а сам проект окажется чрезмерно сложным, и не исключено, что невыполнимым.

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

1) идентифицировать, описать и классифицировать бизнес-процессы, требующие автоматизации, на основе этой информации определить цели и задачи, которые должна решить новая программа;

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

3) составить представление о функционале существующих на рынке программ, оценить их по заданным критериям;

4) сделать окончательный выбор.

1.3.1 Обобщённые критерии выбора ИС

Метод TEI подразумевает оценку соответствия выбранного ПО требованиям как прикладных специалистов, так и менеджеров различных уровней, работающих на предприятии заказчика. Для выявления подобных требований, компанией IBM было проведено соответствующие исследование, в результате интервьюирования организаций, были выделены основные требования, предъявляемые пользователями к ИС, в результате выяснилось, что пользовательские требования к ПО у фирм различных типов (малые/средние/крупные) практически одинаковы:

· знакомство ПО

· удобство интерфейса

· простота использования

· быстрота работы

· стабильность работы

Для средних и крупных предприятий так же характерно наличие административных требований, определяющих удобство установки и конфигурирования ИС, а именно:

· быстрота развертывания

· возможность удаленного администрирования

· возможность автоматической установки

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

Компания IBM провела оценку значимости выявленных требований методом непосредственной оценки [26]. Для оценки важности факторов использовался метод «непосредственной оценки», где пользователям и администраторам предприятия, предлагалось оценить их по шкале от 1 до 10. На основе опросов и полученных из них данных можно построить таблицу «важности» для каждого типа предприятия. Результаты опроса для каждого предприятия среднего масштаба приведены в таблице 1.2.

Таблица 1.2 - Важность факторов для средних предприятий

Фактор	Вес	Стандартное отклонение оценок	Достоверность показателей
Знакомство с ПО	7	2	Достоверен
Удобство интерфейса	9	2	Достоверен
Простота использования	8	1	Достоверен
Быстрота работы	9	1	Достоверен
Стабильность работы	10	2	Достоверен
Быстрота развертывания	8	1	Достоверен
Возможность удаленного администрирования	7	1	Достоверен
Автоматическая установка	7	3,57	Недостоверен

1.3.2 Метод расчёта совокупной стоимости

В главе 1.2.1 (Затратные методы) уже приводилось общее представление о методе TCO, сейчас же, рассмотрим его более подробно [26].

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

В общем случае для расчета ТСО информационными системами необходимо учитывать такие показатели, как стоимость ЭВМ, стоимость ИС, стоимость установки, стоимость поддержки и обслуживания, стоимость потерь, возникающих из-за ошибок в работе систем, а также затраты на переобучение персонала (1.3):

(1.3)

При этом необходимо учитывать, что данные затраты имеют разные сроки использования: если средний срок эксплуатации ЭВМ составляет 4-5 лет, то для ИС этот показатель зависит от типа и вида лицензии, но в среднем составляет 3 года. Соответственно для расчета TCO данные показатели необходимо привести к единому расчетному периоду (в России обычно рассчитывается на один год). Тогда расчет затрат на оборудование будет осуществляться по формуле(1.4)

, (1.4)

где n - это срок эксплуатации системы.

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

Стоимость установки ИС рассчитывается по формуле(1.5)

(1.5)

где З_сп - затраты на 1 час работы специалиста, которые определяются условиями конкретного региона и отрасли; Вр_уст - время установки одной копии; N_коп - количество устанавливаемых копий; период - расчетный период эксплуатации; К_над - коэффициент, определяющий среднее количество переустановок данной ИС за 1 год (определяется эмпирическим путем для каждого конкретного вида).

Стоимость поддержки рассчитывается по формуле(1.6)

(1.6)

Цена поддержки, обычно определяется на 1 год. У заказчика, существует возможность выбора способа поддержки: собственными силами и через аутсорсинг. В первом случае кроме требуемых поставщиком обязательных расходов на поддержку заказчик несет затраты на содержание собственной ИТ-службы, в основном определяемые зарплатой специалистов, работающих в отделе. Затраты же на аутсорсинг определяются договором на обслуживание с выбранной организацией. При этом необходимо также учитывать, что в подобных организациях работают специалисты более высокой квалификации, чем в ИТ-службах предприятий.

Потери связанные с неработоспособностью приобретенного ПО теоретически рассчитывается по формуле(1.7):

(1.7)

где Цена потерь - упущенная прибыль предприятия, за один час неработоспособности системы; t_вост - время, необходимое на восстановление работоспособности конкретного вида ИС, t_ожид - среднее время ожидания, от момента возникновения неисправности до момента прибытия специалиста; период - расчетный период эксплуатации; К_над- коэффициент надёжности, определяющий среднее количество неисправностей за один год. Значение данного показателя также зависит от типа выбранной предприятием поддержки: в случае выбора схемы аутсорсинга ведет к увеличению времени ожидания устранения (по сравнению с внутренней ИТ-службой предприятия), но при этом время на устранение как правило уменьшается. Основной проблемой при расчете потерь является невозможность оценки упущенной прибыли. Поэтому данный компонент целесообразно выделить из ТСО в отдельный временной показатель - «Время потерь».

1.3.3 Рассмотрение подходов к обоснованию выбора ИС на примере системы бюджетирования и финансового планирования

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

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

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

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

Таблица 1.3 - Цели автоматизации бюджетирования и способы их достижения

Цель автоматизации	Способы достижения цели
Дальнейшее развитие системы бюджетирования	1. увеличение достоверности а точности планируемых результатов; 2. автоматизированная консолидация, корректировка и актуализация бюджетов; 3. бюджетирование, учитывающие фактическую и ожидаемую кредиторскую и дебиторскую задолженность; 4. интегрирование с системами банк-клинт.
Увеличение эффективности работы сотрудников финансового департамента	1. увеличение скорости доступа и обработки данных; 2. рассчитывать в режиме реального времени финансовые и экономические индикаторы для сотрудников; 3. обеспечить полную автоматизацию повторяющихся функций; 4. увеличение профессиональных навыков и мотивации сотрудников, за счёт замены рутинной работы на аналитическую.
Укрепление бюджетной дисциплины	1. управление издержками благодаря управлению своевременной и достоверной финансовой и экономической информацией4 2. минимизация нарушений оплаты по заключенным договорам; 3. полный контроль за финансовым состоянием отдельных подразделений и предприятия в целом за счёт использования унифицированной системы.
Повышение прозрачности бизнеса	1. предоставление актуальной информации управляющей компании.
Рост эффективности принятия управленческих решений	1. обеспечение полноты, быстроты и прозрачности информационных потоков; 2. исключение ручного ввода и дублирования данных; 3. организация потока рабочих документов (особенно в процессах утверждения и актуализации бюджетов) 4. контроль выполнения бюджетов; 5. увеличение системности и читабельности аналитических отчётов; 6. возможность рассчитывать и анализировать KPI на основе плановых и фактических данных.

Выводы

Из анализа традиционных подходов к определению критериев выбора систем и определению их весомости для вынесения решения сделаны следующие выводы:

· в процесс выбора вовлечено большое количество сотрудников предприятия, что влечёт за собой большие трудозатраты;

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

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

· сотрудники склонны ставить в приоритет те задачи, которые для них наиболее сложны или, наоборот, наскучившие, в то время как цель внедрения ИС - автоматизация самых трудозатратных и некорректно исполняемых сотрудниками БП.

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

Глава 2. Представление и генерация журналов регистрации событий в различных системах

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

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

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

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

К преимуществам использования журналов можно отнести:

· отражение значимой для выполнения процесса информации, в определённые временные интервалы;

· известный, формальных подход к построению и отражению информации;

· известный математический аппарат для анализа и извлечения информации из логов.

2.1 Стандарт представления журналов регистрации событий: PCI DSS

Обычно, когда речь идет о журналах регистрации событий - «логах» - имеются в виду технические логи, нужные администраторам для того, чтобы разобраться, что, где и почему сломалось и как это починить. Однако требования PCI DSS подразумевают журналы иного типа, позволяющие отследить (и, следовательно, предотвратить либо расследовать) инциденты безопасности. В чем же разница, и какие особенные требования предъявляет к журналам стандарт?

2.1.1 Основные положения, необходимые условия внедрения стандарта

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

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

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

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

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

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

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

· Должна быть разработана Политика ведения журналов регистрации событий и другие нормативные документы, детализирующие и систематизирующие требования PCI DSS в отношении журналирования событий.

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

· Факты отключения или прерывания процесса журналирования событий должны регистрироваться и отслеживаться.

· В журналы регистрации событий должны записываться все события, требуемые PCI DSS и Политикой ведения журналов регистрации событий.

· Создаваемые журналы регистрации событий должны соответствовать требованиям PCI DSS (в частности, требованиям п.10.3).

· Время на всех системах, входящих в область действия PCI DSS, должно быть синхронизировано с использованием надежного сервера времени (с помощьюNTPили другой технологии, соответствующей требованиям п.10.4 PCI DSS).

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

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

· Человек, чьи действия журналируются на определенной системе, не может быть единственным, кто выполняет анализ журналов регистрации событий этой же системы [10].

· Все попытки получения доступа к журналам регистрации событий должны регистрироваться и отслеживаться для выявления попыток отключения журналирования событий или иных попыток воздействия на ведение и содержимое журналов [10].

2.1.2 Требования в части журналирования событий

В этом разделе рассмотрены требования PCI DSS в части журналирования событий. Следует отметить, что вопросы ведения и мониторинга журналов регистрации событий рассматриваются не только в разделе 10, раздел 12 также затрагивает эти вопросы.

«Реализуйте процесс, обеспечивающий связь любых фактов доступа к системным компонентам (в особенности доступа, с использованием административных привилегий, например, root) с конкретными пользователями». PCI DSS не просто требует обеспечить наличие журналов регистрации событий или организовать процесс их сбора, он требует обеспечить связь событий, отраженных в журнале регистрации, с конкретными людьми (а не компьютерами или устройствами, которые были источником события). Это требование часто создает проблемы для внедряющих PCI DSS. Многие начинают думать о журналах, как о «записях о действиях людей», тогда как в действительности они являются «записями о действиях компьютеров». Требование п.8.1 PCI DSS, которое говорит, что «каждому пользователю должно быть присвоено уникальное имя (идентификатор) до предоставления ему доступа к системным компонентам или данным платежных карт», помогает и при реализации требования п.10.1, делая журналы регистрации событий более полезными.

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

Ниже представлен список событий, которые должны журналироваться в соответствии с этим пунктом:

· любой доступ к данным платежных карт;

· все действия, выполненные с использование административных привилегий;

· доступ к любым журналам регистрации событий;

· неудачные попытки логического доступа;

· использование механизмов идентификации и аутентификации;

· инициализация журналов регистрации событий;

· создание и удаление системных объектов.

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

Далее раздел 10 PCI DSS опускается до еще более детального уровня и указывает конкретные данные, которые должны записываться в журнал регистрации событий для каждого события. Это вполне разумные минимальные требования, которые обычно не превышают стандартных возможностей механизмов регистрации событий большинства ИТ-платформ. Записи подлежат следующие данные:

· идентификатор пользователя;

· тип события;