Методы бизнес анализа в it проекте

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

Файлы: 1 файл

2.2 Методы оценки эффективности ИТ-проектов

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

• финансовые (количественные),
• качественные,
• вероятностные.

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

Финансовые методы оценки7

Финансовые (количественные) методы условно можно разбить на 2 группы:

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

Для начала рассмотрим классические методы оценки инвестиций в ИТ:

1. Чистый приведенный доход (NPV) – это разница между суммарным эффектом проекта и первоначальными капиталовложениями, где эффект проекта – это разница между текущими доходами и расходами. NPV определяется по классической формуле дисконтирования.

NPV = NCF1:(1 + Re) + ….. + NCFi:(1 + Re)i,
где: NCFi — чистый денежный поток на i-том интервале планирования;
Re — ставка дисконтирования (в десятичном выражении).Если NPV больше нуля – проект эффективен, если меньше – нет. Эффект проекта и размер капиталовложений рассчитываются с учетом их обесценивания во времени – дисконтирования (рис.1). В качестве нормы дисконтирования при анализе могут быть использованы индекс инфляции, ставка банковских депозитов или же норма доходности, которая устраивает инвестора.

1. Индекс рентабельности инвестиций (ROI).8

ROI представляет собой отношение суммарного эффекта проекта к объёму первоначальных капиталовложений. Если ROI > 1 – проект эффективен, если < 1 – нет.

ROI непосредственно связан с NPV. Если NPV > 0, то ROI > 1 и наоборот. В случае если ROI = 1, то NPV = 0. ROI показывает относительное превышение полученной выгоды над первоначальными капиталовложениями, а NPV – абсолютное значение этой выгоды.

1. Внутренняя норма доходности (IRR) – это норма дисконтирования, при которой суммарный эффект проекта равен объёму первоначальных капиталовложений, т. е. при условии, что в конце жизненного цикла проекта его NPV = 0.

IRR сравнивается с нормой доходности, определённой инвестором. Если IRR выше желаемой нормы доходности – проект выгоден, если ниже – нет.

1. Срок окупаемости проекта – это период, в течение которого суммарный эффект возмещает первоначальные капиталовложения, т. е. период от начала проекта до того момента, когда NPV станет равным нулю. Чем меньше срок окупаемости, тем привлекательнее проект.
2. Экономическая добавленная стоимость (EVA) является достаточно простой методикой, суть которой в вычислении разницы между чистой операционной прибылью предприятия и всеми затратами, понесёнными предприятием на IT-инфраструктуру. Применять результаты данной методики можно лишь в динамике, т.е. рассматривая изменения величины показателя EVA с течением времени. Методика предложена компанией Stern Stewart
3. внутрифирменный аспект – какие процессы могут обеспечить ему исключительное положение;
4. инновационный аспект – каким образом можно добиться дальнейшего улучшения положения;
5. финансовый аспект – как оценивают предприятие акционеры [3].

Техника интервьюрирования в бизнес-анализе

Все, что нужно знать о профессии бизнес-аналитика

Ещё больше конкретности в этот подход вносит метод, получивший название BITS (Balanced IT Scorecard). BITS служит развитием методики BSC в сторону большей применимости для компаний, ключевые бизнес-процессы которых зависят от информационных технологий. Фактически единственным изменением в данной методике, по сравнению с BSC, является дополнительная формализация показателей эффективности анализируемого процесса.

Третий метод, который можно упомянуть, получил название информационной экономики (Information Economics, IE). IE является качественным методом оценки IT-проекта или портфеля проектов, основная идея которого заключается в том, что топ-менеджмент компании и ИТ-служба организуют некую систему координат – определяют приоритеты в развитии бизнеса компании и расставляют приоритеты проектных критериев ещё до рассмотрения какого-либо ИТ-проекта. И тогда проект оценивается на соответствие этим разработанным критериям.

Вероятностные методы оценки

Последняя группа методов оценки экономического эффекта от ИТ-проекта – вероятностные. Их, в общем-то, два: прикладная информационная экономика (Applied Information Economics) и справедливая цена опционов (Real Options Valuation, ROV).

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

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

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

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

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

Источник: www.yaneuch.ru

Как мы делаем аналитику IT-проектов: прояснение требований

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

5664 просмотров

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

Vision/Виденье проекта

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

Проще говоря, в Vision формулируется:

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

В Vision зафиксированы наиболее существенные требования, ограничения и приемлемые уровни качества.

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

Пример Vision
User Stories/Юзер сторис

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

Текст каждой формулировки — User Story — должен объяснять роль или действия юзера в системе, его потребность и профит, который он получит после того, как история случится.

Особенности User Stories:

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

Именно на основании User Stories проводится дальнейший анализ.

Пример User Stories
Use Cases/Юзкейсы

Так же как и User Stories описывают, как пользователь должен взаимодействовать с системой, чтобы достичь конкретной цели. В чём же тогда отличие? User Story помогает определить задачу и намерение. А Use Cases не сообщают о задачах и намерениях, они более подробно фиксируют функциональные возможности.

Посмотрим на эти различия на примере гипотетической разработки обычного калькулятора.

Формулировка User Story может быть такой: «Я как пользователь хочу иметь возможность совершать математические операции, чтобы упростить механические расчеты».

А кейсы, соответствующие данной User Story, могут быть такими:

• Ввести число
• Добавить число
• Отнять число
• Разделить на число
• Умножить на число
• Подвести итог
• Добавить результат в память
• Очистить память
• Показать число в памяти
• Сбросить все
• Отключить устройство

Пример Use Cases на проекте iFarm — AgroTech информационной системы
Инструменты для наглядного описания процессов, алгоритмов, взаимосвязей между сущностями

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

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

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

Описание сущностей

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

Список Entities
Диаграммы компонентов

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

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

Таким образом, диаграмма компонентов помогает:

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

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

Диаграмма развертывания

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

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

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

Карта экранов

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

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

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

Эффективность внедрения it — проектов

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

Современные IT — проекты c каждым днем занимают все более значимое место в современном мире, будь то бизнес, производственная или социальная сфера.

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

The Standish Group, международная независимая консультативная фирма, проводящая исследования в области IT, опубликовала следующие данные. В проектах, которые были рассмотренных с точки зрения внедрения информационных систем, а это более 9000 проектов, успеха добились лишь 16,2 %, в категорию «спорные» проекты попало 52,7 %; в категории проектов потерпевших крах (от реализации которых отказались) оказалось 31,1 % [1, с. 9 — 14]. В среднем затраты на IT — проекты превышены в 1,5-2 раза, а время их реализации в 2 — 3 раза.

При этом риски и угрозы IT — проектов определяются в основном качественными факторами, достаточно трудно формализуемыми и преобразуемыми в количественные. Например, таковыми факторами являются: неполнота требований к IT — проекту, отсутствие участия пользователя в проектировании, отсутствие ресурсов, завышенные требования к проекту, отсутствие планирования, изменение рынка IT — товаров и услуг и другие.

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

• прогноз и дальнейшая оценка экономического эффекта от внедрения IT — проекта на всех этапах создания и эксплуатации,
• выделение рисков внедрения IT — проекта и их количественная оценка,
• а также принятие итогового решения о запуске проекта внедрения на

основании объединения результатов двух предыдущих задач.

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

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

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

Итак, исследователи выделяют следующие методики оценки эффективности IT — проектов [2, с. 20-21]:

Все перечисленные методики экономической оценки можно разделить на три основных блока, это количественные методы (финансовые), качественные методы и вероятностные. Количественные методы используют в своей основе традиционные финансовые расчеты, но с учетом специфики IT, потребности и необходимости оценки риска. Блок качественных методов характеризуется тем, что количественные расчеты дополняются качественными оценками. Третий блок, который включает вероятностные методы, основывается на применении математических и статистических моделей, с помощью которых можно оценить вероятность возникновения риска [3, с. 4 — 8].

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



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

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

В этом случаи лицо, принимающее решения может самостоятельно определить необходимые параметры IT и устанавливать между ними соотношения. Однако использование качественных методик имеет и недостатки, например высокую сложность обусловленную множеством рассматриваемых взаимозависимых связей и фактор влияния субъективного мнения на выбор системы показателей. Также следует учитывать, что эти методологии в первую очередь служат инструментом формирования стратегии управления, а не методики оценки эффективности затрат на внедрение ГГ-проектов. Однако решение о внедрение комплексных IT — проектов на крупных предприятиях является в большей степени политическим и подчиняется стратегическим планам долгосрочного развития, нежели цели скорейшего получения финансовой прибыли в ближайшем будущем [3, с. 8 — 10].

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

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

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

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

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

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

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

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

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

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

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

Еще один подход к управлению рисками IT — проекта связывает риски с вероятностью явным образом, например, в [1, с. 9 — 14] риск IT — проекта (IT — Related Risk) — это вероятность убытка от некоторых средствами программного обеспечения, информации, технических средств, административных, физических, коммуникационных или людских ресурсом ИС, исполнения проекта или управленческой деятельности. Авторы рассматривают управление рисками ЕГ-проекта с точки зрения семиуровневой оценки вероятности угроз и двухфакторной модели оценки риска Microsoft Solutions Framework. Модели построены на классическом подходе к потери стоимости IT и оценивании угроз информационной безопасности и защищенности.

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

• влияние на численные показатели деятельности предприятия (связь IT — факторов с показателями эффективности функционирования предприятия);
• оценка с учетом ресурсного подхода (IT — проект рассматривается как один из ресурсов предприятия);
• вклад в сложные бизнес — ориентированные показатели (структурированная система показателей, связанных с бизнес — стратегией);
• оценка ценности информации;
• улучшение процессов (оценка улучшений в бизнес — процессах);
• ценность как соответствие системным целям, повышение качества сервисов, достижение качественных выгод. [5, с. 10-15].

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

Таким образом, можно сделать вывод о том, что необходимо дальнейшее исследование по развитию и детализации методов по оценке экономической эффективности и рисков от внедрения IT — проектов.

Литература:

1. Ткалич Т.А. Прогнозирование рисков инвестиционных IT — проектов, — Інвестиціі: практика та досвід № 6 / 2017. — С. 9 — 14.
2. Анисифоров А.Б., Анисифорова Л.О. Методики оценки эффективности информационных систем и информационных технологий в бизнесе, Учебное пособие. — Санкт — Петербург, 2014 г.-С. 20-25.
3. Д.А. Градусов, А.В. Шутов. А.Б. Градусов. Корпоративные информационные системы, Учебное пособие. — ВлГУ. 2015. — С. 4 — 10.
4. Е.М. Клейменова и др. Метод оценки рисков в мультиагентной системе управления проектами НИР и OKP в реальном времени — Информационно — управляющие системы, № 2(63), 2013,- С. — Петербург.
5. Середенко Е.С., Оценка экономической эффективности аналитических информационных систем, диссертация на соискание ученой степени кандидата экономических наук. — Москва, 2014.-С. 10-15.

Источник: articlekz.com