РЕФЕРАТ
Выпускная квалификационная работа содержит 106 страниц, 39 рисунков,
16 таблиц и 70 использованных источников.
ИСКУССТВЕННЫЙ ИНТЕЛЛЕКТ, ИНТЕЛЛЕКТУАЛЬНЫЕ ТЕХНОЛОГИИ И СИСТЕМЫ, ПРОЕКТИРОВАНИЕ, АНАЛИЗ IT-ПРОЦЕССОВ,
АНАЛИТИЧЕСКАЯ ДЕЯТЕЛЬНОСТЬ, МОДЕЛИРОВАНИЕ, ЗАТРАТЫ РАЗРАБОТКИ.
Объектом исследования является АО «Биохимик».
Предмет исследования – аналитическая деятельность предприятия по
анализу IT-процессов поддержки бизнеса.
Цель выпускной квалификационной работы – проектирование интеллектуальной системы анализа IT-процессов предприятия.
В ходе выполнения работы применялись аналитический, монографический, функционально-структурный, логические и графические методы, методы
моделирования, сравнения и комплексного анализа.
В результате исследования были изучены теоретические основы проектирования интеллектуальных систем для анализа IT-процессов, исследована существующая процедура анализа IT-процессов АО «Биохимик» и спроектирована интеллектуальная система анализа IT-процессов АО «Биохимик».
Область применения – в ходе реализации процедуры анализа ITпроцессов отделом информационных технологий АО «Биохимик».
4
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
6
1 Теоретические основы применения интеллектуальных систем для
анализа IT-процессов
1.1
Интеллектуальные
9
системы:
понятие,
классификация,
архитектура
9
1.2 Методы и инструменты анализа IT-процессов в области
проектирования интеллектуальных систем
1.3 Технология проектирования интеллектуальных систем
2 Исследование процедуры анализа IT-процессов АО «Биохимик»
18
28
35
2.1 Организационно-экономическая характеристика АО «Биохимик»
35
2.2 Оценка деятельности IT-подразделения АО «Биохимик»
43
2.3 Процедура проведения анализа IT-процессов АО «Биохимик»
54
3 Совершенствование процедуры проведения анализа IT-процессов
АО «Биохимик»
64
3.1 Моделирование требований к интеллектуальной системе
64
3.2 Проектирование компонентов архитектуры интеллектуальной
системы
72
3.3 Расчет затрат на разработку интеллектуальной системы
ЗАКЛЮЧЕНИЕ
92
97
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
5
100
ВВЕДЕНИЕ
Постоянно меняющаяся современная экономическая ситуация, характеризующаяся условиями жесткой конкуренции, складывается таким образом, что
требует от предприятий способности оперативно реагировать на происходящие
изменения. В таком контексте управление предприятием подразумевает получение и учет менеджментом информации о собственных бизнес-процессах, что
позволяет определять текущее состояние процессов, выявлять и устранять их
проблемы. Отслеживание потоков информации – деятельность крайне сложная
и должна опираться на информационную систему предприятия, от построения
и организации которой во многом зависит эффективность хозяйствующего
субъекта.
В настоящее время на многих предприятиях внедрены и функционируют
автоматизированные информационные системы, которые позволяют собирать и
хранить информацию, необходимую менеджменту для анализа бизнеспроцессов и своевременного их улучшения посредством принятия обоснованных управленческих решений. Однако обычные информационные системы требуют достаточно больших временных и умственных затрат, направленных
непосредственно на анализ содержащейся в них информации. При этом лицу,
принимающему решения, важно получать объективную и достоверную информацию, в то время как обычные информационные системы не всегда могут это
обеспечить.
Развитие науки, технологий и необходимость качественной, подготовленной и отражающей реальное положение дел информации о своих бизнеспроцессах обусловило проникновение на предприятия нового класса систем,
получивших название интеллектуальных. Сегодня интеллектуальные системы
находят широкое применение при решении задач, для которых не существует
единого алгоритма действий. К таким задачам на предприятии, например, относится анализ процессов, в частности IT-процессов, который создает предпосылки для совершенствования информационной поддержки бизнес-процессов
6
предприятия. С этой точки зрения использование на предприятии интеллектуальных систем, в том числе и аналитических, становится одним из ключевых
факторов успеха, а их проектирование – одной из востребованных инвестицией
современности.
Актуальность выделенных проблем обусловила выбор темы выпускной
квалификационной работы.
Цель исследования – проектирование интеллектуальной системы анализа
IT-процессов предприятия.
Для достижения поставленной цели необходимо решить задачи:
– изучить теоретические основы применения интеллектуальных систем
для анализа IT-процессов;
– дать организационно-экономическую характеристику АО «Биохимик»;
– охарактеризовать деятельность отдела информационных технологий
АО «Биохимик» как объект проектирования интеллектуальной системы;
– исследовать существующую на предприятии процедуру анализа ITпроцессов;
– определить и формализовать требования к проектируемой интеллектуальной системе;
– спроектировать архитектурные компоненты интеллектуальной системы;
– рассчитать затраты на проектирование и разработку интеллектуальной
системы.
Объектом исследования является акционерное общество «Биохимик».
Предмет исследования – аналитическая деятельность предприятия по
анализу IT-процессов поддержки бизнеса.
Теоретической и методологической базой исследования послужили труды
отечественных и зарубежных ученых в области искусственного интеллекта,
проектирования интеллектуальных систем в экономике, анализа информационных процессов.
Информационную базу исследования составили нормативные правовые
акты, документация АО «Биохимик», в том числе положение об отделе инфор7
мационных технологий и должностные инструкции.
Практическая значимость работы заключается в разработке проекта интеллектуальной системы, способной на начальном этапе поддержать процедуру
анализа IT-процессов АО «Биохимик».
Основные публикации по теме исследования:
1. Зинина Л.И. Статистические методы управления бизнес-процессами
предприятия / Л.И. Зинина, А.Н. Чегодайкин // Информационные технологии в
экономике и управлении, 2018. – № 3. – С. 26-30.
2. Чегодайкин А.Н. Анализ развития ИКТ в регионе (на примере Республики Мордовия) / А.Н. Чегодайкин // XLVI Огарѐвские чтения: материалы науч.
конф.: в 3 ч., 2018. – № 46. – С. 198-202.
3. Чегодайкин А.Н. Интеллектуализация бизнес-процессов: от постановки
задачи до практического применения / А.Н. Чегодайкин // Огарев-online: экономические науки, 2019, – № 7. – С. 7-14.
4. Чегодайкин А.Н. Статистическая оценка развития ИКТ (на примере
республики Мордовия) / А.Н. Чегодайкин // Статистические методы анализа
экономике и общества, 2018. – № 9. – С. 268-269.
8
1 Теоретические основы применения интеллектуальных систем для
анализа IT-процессов
1.1
Интеллектуальные
системы:
понятие,
классификация,
архитектура
История развития интеллектуальных систем берет свое начало со второй
половины XX века, когда в 1956 г. на Дартмутской конференции (США) было
предложено использовать термин «искусственный интеллект», под которым
понималась способность вычислительной машины моделировать мыслительную деятельность человека [30, с. 8]. С тех пор ведутся бесконечные споры относительно двух крайностей. Одни считают искусственный интеллект прорывной технологией, способной решить множество проблем, в том числе и глобальных. Другие, напротив, настроены пессимистично и утверждают, что искусственный интеллект может привести к непоправимым последствиям.
После признания искусственного интеллекта как науки произошло его
разделение на два основных направления: нейрокибернетика и кибернетика
«черного ящика».
Усилия нейрокибернетики были направлены на разработку элементов,
моделирующих нейроны человека, и их объединение в нейронные сети и
нейрокомпьютеры. Первые нейронные сети и нейрокомпьютеры появились в
конце 1950-х гг. благодаря работам Маккалока, Питса и Розенблатта. Это были
системы, которые моделировали человеческий глаз и его взаимодействие с мозгом. Система позволяла распознавать буквы алфавита.
Кибернетике «черного ящика» (в отличие от нейрокибернетики) не интересна структура и принципы действия человеческого мозга. Центральное место
в таких системах занимает адекватное моделирование интеллектуальных функций человека. Это направление направлено на поиск алгоритмов решения интеллектуальных задач.
Конец 1950-х гг. ознаменовался новыми открытиями в области искус9
ственного интеллекта, в частности появилась модель лабиринтного поиска, согласно которому решение интеллектуальных задач подразумевало перебор
огромного количество вариантов, напоминающее движение по лабиринту. Сейчас такая модель решения задач признается тупиковой и практические не используется.
Начало 1960-х гг. ознаменовалось временем эвристических методов. Под
эвристиками понималась совокупность определенных приемов или правил, которые позволяли значительно сократить время и ресурсы на решение задач. Соответственно эвристическое программирование – подход, при котором задачи
решаются с помощью эвристик.
Серьезный прорыв в развитии искусственного интеллекта произошел в
середине 1970-х гг., когда появился класс систем, базирующихся на знаниях
человека-эксперта. Отсюда возникло одно из основных и прибыльных направлений искусственного интеллекта – экспертные системы. Примерно в то же
время начинают появляться первые коммерческие экспертные системы (MYCIN и DENDRAL) и разрабатываться глобальные программы развития интеллектуальных технологий.
С середины 1980-х гг. искусственный интеллект становится одним из
коммерческих направлений компьютерной индустрии. Искусственный интеллект находит активное применение в промышленности и в военном деле. В результате 1990-е гг. ознаменовались приходом искусственных нейронных сетей
в сферу бизнеса, где они показали свою реальную эффективность при решении
многих практических задач.
В последнее время, помимо упомянутых выше направлений, находит
практическое применение еще одно направление, смысл которого заключается
в том, что интеллектуальные системы моделируют процесс эволюции человека.
Это направление широко использует механизмы естественного отбора и генетического наследования, описанные Чарльзом Дарвином, и связано с разработкой интеллектуальных агентов.
Результатом развития искусственного интеллекта (в частности, эксперт10
ных систем) является появление новой технологии обработки информации, которая нашла свое отражение в интеллектуальных системах. В таблице 1.1 приведены публикации и работы, оказавшие ключевое влияние на современные исследования и разработки в области искусственного интеллекта.
Таблица 1.1 – Перечень основных событий в области искусственного
интеллекта
Период
1
Рождение искусственного интеллекта
(1943–1956 гг.)
Публикации
2
– Маккалок и Питс «Логическое исчисление идей, присущих
нервной деятельности», 1943 г.
– Тьюринг «Вычислительная машина и интеллект», 1950 г.
– Клод Шеннон «Программирование компьютера для шахматной
игры», 1950 г.
Подъем искусствен– Маккарти «LISP – язык программирования искусственного инного интеллекта
теллекта», 1958 г.
(1956 г. – конец 1960- – Куллиан «Семантические сети для представления знаний», 1966
х гг.)
г.
– Ньюэл и Саймон «Универсальный решатель задач», 1961 г.
– Минский «Структуры для представления знаний», 1975 г.
Открытие и разработ- – Фейгенбаум, Буханан и др. (Стэндфордский университет) «Экска экспертных систем пертная система DENDRAL», 1971 г.
(начало 1970-х – сере- – Фейгенбаум, Шортлиф «Экспертная система MYCIN», 1974 г.
дина 1980-х гг.)
– Стэндфордский исследовательский центр «Экспертная система
PROSPECTOR», 1975 г.
– Колмероэ, Ковальски и др. «Язык логического программирования PROLOG», 1975 г.
Возрождение искус– Хопфилд «Нейронные сети и физические с эмержентными колственных нейронных
лективными вычислительными способностями», 1982 г.
сетей (1965 г. и далее) – Кохонен «Самоорганизующиеся топологически правильные
карты», 1982 г.
– Румельхарт и Макклеланд «Распределенная параллельная обработка данных», 1986 г.
Эволюционное вы– Рехенберг «Эволюционные стратегии – оптимизация техничечисление (начало
ских систем по принципам биологической информации», 1973 г.
1970-х гг. и далее)
– Холланд «Адаптация в естественных и искусственных системах», 1975 г.
– Коза «Генетическое программирование: компьютерное программирование средствами естественного отбора», 1992 г.
– Фогель «Эволюционное вычисление – направление новой философии в машинном интеллекте», 1995 г.
Нечеткие множества и – Заде «Нечеткие множества», 1965 г.
нечеткая логика (се– Заде «Нечеткие алгоритмы», 1969 г.
редина 1960-х гг. и
– Мамдани «Применение нечеткой логики в приближенном расдалее)
суждении с использованием лингвистического синтеза», 1977 г.
11
Окончание таблицы 1.1
1
Вычисления при помощи слов (конец
1980-х гг. и далее)
2
– Нейгоца «Экспертные системы и нечеткие системы», 1985 г.
– Коско «Нейронные сети и нечеткие системы», 1992 г.
– Коско «Нечеткое мышление», 1993 г.
– Ягер и Заде «Нечеткие множества, нейронные сети и мягкие вычисления», 1994 г.
– Коско «Нечеткая инженерия», 1996 г.
– Заде: «Вычисления при помощи слов», 1996 г.
На современном этапе интеллектуальная система – это автоматизированная система, основанная на знаниях, или комплекс программных, лингвистических и логико-математических средств для реализации основной задачи – осуществления поддержки деятельности человека и поиска информации в режиме
продвинутого диалога на естественном языке [48, с. 7].
Принципиально интеллектуальные системы отличаются от обычных программ тем, что они способны самообучаться и накапливать знания во время работы, то есть обладают такими же качествами, которые свойственны человеческому интеллекту. Человеческий интеллект приспособлен к тому, чтобы эффективно решать уникальные, творческие задачи, в отличие от обычных программ,
которые оперируют четкой прописанной последовательностью действий. Отсюда можно сделать вывод, что интеллектуальные системы решают задачи, которые не имеют заранее известного алгоритма и метода решения.
Единой классификации интеллектуальных систем не существует, что
объясняется многообразием задач, которые они решают. В то же время, исходя
из свойств, присущих интеллектуальным системам, их классифицируют на системы с коммуникативными способностями, экспертные системы, самообучающиеся и адаптивные системы (рисунок 1.1).
Системы с коммуникативными способностями определяются наличием
способа взаимодействия (интеллектуального интерфейса) с конечным пользователем. Выражается это через возможность формулировать запросы в процессе диалога на языке, близким с естественному.
12
.
Рисунок 1.1 – Классификация интеллектуальных систем по присущим
им свойствам
Экспертные системы позволяют находить подход к решению сложных
задач, которые нуждаются в оригинальном, уникальном подходе в зависимости
от конкретной ситуации. Для таких систем характерна неопределенность, динамичность входных данных и знаний.
Самообучающиеся системы характеризуются возможностью автоматического извлечения знаний для решения какой-либо задачи из ранее накопленного опыта.
Интеллектуальные адаптивные системы позволяют им приспосабливаться
к объективным изменениям модели предметной области.
Искусственный интеллект – бурно развивающаяся область науки, где новые прикладные области осваиваются ежедневно. Однако, несмотря на многообразие интеллектуальных систем, их архитектура содержит ряд обязательных
компонентов.
13
Типовой состав компонентов любой интеллектуальной системы (архитектура) содержит три комплекса средств (рисунок 1.2).
Рисунок 1.2 – Типовая архитектура интеллектуальной системы
Первый компонент включает набор средств, которые выполняют программы, то есть исполнительную систему, решающую с помощью программного кода какие-либо прикладные задачи.
Второй компонент представляет собой совокупность средств интеллектуального интерфейса, обеспечивающего возможность удобного общения конечного пользователя с системой. Интеллектуальный интерфейс – система программных и аппаратных средств, обеспечивающих для конечного пользователя
использование компьютера для решения задач, которые возникают в среде его
профессиональной деятельности либо без посредников, либо с незначительной
их помощью [48, с. 27].
Третий компонент (база знаний) обеспечивает применение вычислительными средствами первых двух компонент. База знаний – это целостная и независимая от программных средств система знаний о проблемной среде [62]. Она
занимает центральное положение относительно исполнительной системы и интеллектуального интерфейса. Через базу знаний осуществляется интеграция
14
средств вычислительной техники, которые участвуют в решении задач.
Существуют несколько моделей (способов) представления знаний в интеллектуальных системах: логическая, продукционная, фреймовая и сетевая
модели.
Самой простой моделью является логическая, которая основана на
утверждениях. О каждом таком утверждении можно сказать, истинно оно или
ложно. Совокупность утверждений делится на факты и правила. Факты – это
база данных, которая лежит в основе базы знаний. Правила имеют структуру
«ЕСЛИ А, ТО Б». Механизм вывода решения в такой модели представляет собой исчисление предикатов первого порядка и реализуется в функциональных
языках программирования, например, в языке PROLOG. Логическую модель
используют редко, так как прикладные возможности ее ограничены.
Продукционная модель содержит три комплекса, представленные на рисунке 1.3.
Рисунок 1.3 – Функционирование продукционной модели
Первый комплекс определяет базу правил аналогичных логической модели: ЕСЛИ гололед, ТО идти осторожно; ЕСЛИ в холодильнике пусто, ТО сходить за продуктами и т.п.
В рабочей памяти хранятся исходные данные задачи (факты и правила) и
полученные выводы интеллектуальной системой.
Механизм логического вывода представляет собой интерпретатор правил,
который преобразует факты и правила в решение задачи.
Существуют два вида интеллектуальных систем, основанных на продукционных правилах: системы с прямым (от фактов к заключению) и обратным
15
(от заключения к фактам) выводом.
Достоинствами продукционной модели являются модульность, наглядность представления, простота вывода и легкость внесения изменений. К недостаткам можно отнести сложность применения модели для решения задач, где
число продукционных правил превышает тысячу.
В определенных случаях с большим количеством правил используется
фреймовая модель представления знаний, которая базируется на понятии
наследования. Наследование используется для установления зависимости между фреймами и экономии рабочей памяти. Фреймы – это специальные объекты
для представления стандартных ситуаций, некий образ ситуации, явления или
понятия [30, с. 34]. Существует два вида фреймов:
фреймы-образцы хранятся в базе знаний;
фреймы-экземпляры создаются для представления реальных ситуаций
на основе входных данных.
Фрейм имеет иерархическую структуру, верхний уровень которого соответствует фиксации некоторой характеристики явления, а последующие уровни
(слоты) хранят конкретную информацию о явлении. Фреймовую модель часто
используют совместно с сетевой, рассматривая фреймы как семантическую сеть
с блочной структурой.
Семантическая модель – способ представления знаний в виде понятий
(объектов) и отношений (связей). В семантической сети роль вершин выполняют элементы базы знаний, дуги задают отношения между элементами [4].
Основным достоинством этой модели является наглядность и соответствие современной организации долговременной памяти человека. Однако в
семантических моделях сложно вывести конечный результат или скорректировать саму сеть, то есть добавить или удалить элемент базы знаний. Пример семантической сети представлен на рисунке 1.4.
В общем случае все модели представления знаний универсальны и могут
преобразовываться одна в другую. Однако следует учитывать, что для различных задач и предметных областей эффективность моделей может варьировать.
16
Поэтому правильность выбора модели при проектировании базы знаний интеллектуальной системы может повлиять на достоверность результатов.
Рисунок 1.4 – Пример функционирования семантической сети
Несмотря на сравнительную молодость технологий искусственного интеллекта, интеллектуальные системы нашли применение во многих сферах.
Экономическая сфера является одной из основных, где применяются технологии искусственного интеллекта. Многие крупные компании постоянно
ищут пути снижения издержек и себестоимости продукции (услуг), а также пути снижения влияния человеческого фактора на прибыль компании. Поэтому
крупные банки используют экспертные системы, которые прогнозируют кредитоспособность (платежеспособность) клиента. Некоторые компании прогнозируют спрос на свою продукцию, конкурентоспособность, планируют ресурсы
(финансовые, человеческие, информационные), выбирают стратегии (развития,
ценообразования, производства), поставщиков, сотрудников, применяя интеллектуальные системы и методы искусственного интеллекта.
Последние пять лет становятся популярными технологии, суть которых
заключается в анализе бизнес-процессов с применением интеллектуальных систем. В связи с возросшими объемами информации, сложностью и трудоемкостью проведения анализа процессов интеллектуальные системы могут стать инструментом, который будет полезным и эффективным помощником компании.
17
В промышленности все большее количество бизнес-процессов автоматизируется с помощью искусственного интеллекта, а участие человека в производстве сводится к минимуму. К 2023 году компания LG планирует запустить
промышленное производство, где все процессы будут интеллектуализированны
(закупки, контроль качества продукции, отгрузка, контроль износа основных
средств и т.д.).
В медицине искусственный интеллект помогает не только поставить правильный диагноз, но и выявлять предрасположенность человека к конкретным
заболеваниям. Некоторые компании обещают в ближайшее время презентовать
систему, которая по фотографии человека определит его генетические заболевания.
В области дорожного движения интеллектуальные системы помогают
решать проблему пробок, собирая огромное количество данных со светофоров,
информацию о плотности движения, авариях, погодных условия, состоянии дорог и т.д. На основе этих данных система строит прогнозы развития ситуаций
на трассе и исходя из прогнозов может автоматически переключать светофоры.
В сельском хозяйстве искусственный интеллект используется для контроля качества посевов, уровня влажности, количества и качества удобрений,
дает рекомендации по уходу за растениями.
Примером применения искусственного интеллекта в бытовой сфере является технология «умных» домов, которая позволяет оптимизировать расход воды, электроэнергии, контролирует электроприборы и т.д.
1.2 Методы и инструменты анализа IT-процессов в области
проектирования интеллектуальных систем
Термин процессное управление, процессный подход используют руководители и специалисты компаний, которые имеют возможность, средства и
необходимость для потенциального роста и развития. Это объясняется тем, что
18
процессный подход может и должен применяться в качестве средства улучшения деятельности компании, которое выражается в анализе и дальнейшем совершенствовании отдельных групп процессов.
Современные компании не ограничивается совершенствованием только
основных процессов (маркетинга, закупок, производства и т.д.), уделяя значительное внимание и вспомогательным процессам. Кроме того, основные бизнес-процессы многих компаний давно отлажены практически до автоматизма и
не представляют возможностей для совершенствования в ближайшей перспективе. Поэтому компании постоянно ищут любые возможности совершенствования бизнес-процессов, и такая возможность находится во вспомогательных
процессах, которые только на первый взгляд добавляют незначительную эффективность.
Одной из групп вспомогательных бизнес-процессов, которая позволяет
существенно повысить результативность бизнеса, является группа
IT-
процессов.
Руководители IT-подразделений все чаще начинают применять анализ и
совершенствование IT-процессов в силу нескольких основных причин:
– уровень показателей, характеризующих IT-процессы, со временем имеет тенденцию к снижению;
– компания не развивается относительно конкурентов, если не занимается
совершенствованием IT-процессов;
– современный бизнес становится все более требовательным к процессам
IT-поддержки;
– развиваются технологии, в том числе интеллектуальные, позволяющие
более рационально подходить к анализу IT-процессов.
Перед тем как проводить совершенствование, необходимо выяснить, как
IT-процесс протекает в текущей ситуации и обосновать необходимость изменений, то есть всесторонне проанализировать процесс.
19
Современные интеллектуальные системы способны поддерживать получение достоверной информации по IT-процессу, необходимой для качественного анализа, на всех этапах его проведения (рисунок 1.5).
Рисунок 1.5 – Укрупненные этапы проведения анализа IT-процесса
Как правило, в компаниях существуют несколько IT-процессов и анализировать все сразу не предоставляется возможным, поэтому анализ проводится
последовательно по мере наличия соответствующих ресурсов. Из перечня всех
IT-процессов выбираются наиболее приоритетные в данный момент времени. В
качестве критерия приоритетности часто выступает важность процесса, его
проблемность, возможность и стоимость проведения анализа.
В большинстве случаев для оценки важности IT-процесса используется
экспертный метод тестирования критериев. Если компания имеет четкое представление о том, на каких ключевых факторах успеха построена ее деятельность, то тестирование критериев поможет определить, какие именно ITпроцессы наибольшим образом влияют на эти факторы [3].
Под ключевыми факторами успеха в данном контексте понимается ограниченное число факторов, которые в значительной степени оказывают влияние
на конкурентоспособность организации и ее положение на рынке [3, с. 75].
Наглядно представить результаты определения важности IT-процесса
позволяет построение матрицы сопоставления (таблица 1.2).
Таблица 1.2 – Матрица сопоставления IT-процессов
IT-процессы
Процесс 1
Процесс 2
Процесс 3
Ключевые факторы успеха
КФУ 1 КФУ 2 КФУ 3 КФУ 4
Х
Х
Х
Х
20
Количество КФУ
А
Б
В
Столбцы матрицы соответствуют сформулированным ключевым факторам успеха, строки – IT-процессам. В том случае, если IT-процесс поддерживает выделенный фактор успеха, то в клетке на пересечении ставится крестик.
Оценка важности процесса определяется максимальной суммой крестиков по
строке.
В отдельных случаях каждому ключевому фактора может присваиваться
весовая категория. При этом каждое соответствие IT-процесса и ключевого
фактора успеха также оценивается по определенной шкале экспертных оценок,
на которую впоследствии умножаются весовые категории.
Следующим шагом выбора приоритетного IT-процесса является определение его проблемности. В этом случае процессы рассматриваются с точки зрения различий между текущим состоянием и желаемым и оцениваются по пятибалльной шкале (таблица 1.3).
Таблица 1.3 – Шкала определения проблемности IT-процессов
Степень проблемности
1
2
3
4
5
Характеристика
Потребители и владельцы считают, что выход IT-процесса в
Отличные
значительной степени лишен дефектов. Нет серьезных недостатков. Достигнуто серьезное улучшение в работе процесса.
Было достигнуто значительное улучшение качества процесса
по сравнению с уже разработанными критериями отсутствия
Хорошие
дефектов. Ожидаются и планируются положительные изменения в будущем.
Используемые в процессе на данный момент процедуры являются эффективными, нет серьезных проблем. Проводятся
Удовлетворительные
мероприятия по улучшению качества процессов. Были разработаны критерии отсутствия дефектов.
Процесс обладает некоторыми операционными недостатками,
которые требуют принятия мер для исправления. Недостатки
Не очень хорошие
можно исправить. Проводятся основные мероприятия по
управлению качеством.
Процесс неэффективен или почти не действует. Существуют
недостатки, требующие принятия мер для исправления. ОсПлохие
новные мероприятия по управлению качеством не проводятся.
После оценки важности и проблемности IT-процесса строится матрица
оценки возможности проведения анализа. В определенных случаях процесс
21
может быть приоритетным с точки зрения важности и проблемности, но возможностей для его анализа практически нет.
Методика оценки возможности проведения анализа IT-процесса подразумевает описание барьеров, которые могут встретиться на пути анализа и совершенствования процесса. Описанные барьеры обычно объединяются в группы: финансы, персонал, законодательство и прочие барьеры.
После определения основных препятствий, которые могут помешать анализу IT-процесса, барьеры по каждому процессу оцениваются по пятибалльной
шкале, после чего рассчитывается суммарная оценка по всем барьерам, соответствующая степени возможности анализа (таблица 1.4).
Таблица 1.4 – Оценка степени возможности проведения анализа IT-процессов
IT-процесс
Процесс 1
Процесс 2
Процесс 3
Сила барьеров
Финансы Персонал Законодательство
А1
Б1
В1
А2
Б2
В2
А3
Б3
В3
Степень
возможности
анализа
Финансы
А1
А1+Б1+В1+Г1
А2
А2+Б2+В2+Г2
А3
А3+Б3+В3+Г3
Заключительным этапом выбора приоритетного для анализа IT-процесса
является построение матрицы ранжирования. Итоговый показатель, определяющий процесс требующего анализа, рассчитывается как сумма оценок важности, проблемности и возможности изменений процесса (таблица 1.5).
Таблица 1.5 – Матрица ранжирования IT-процессов
IT-процесс
Процесс 1
Процесс 2
Процесс 3
Важность
А1
А2
А3
Проблемность
Б1
Б2
Б3
Возможность анализа
В1
В2
В3
Приоритетность
А1+Б1+В1
А2+Б2+В2
А3+Б3+В3
Таким образом, для анализа, в первую очередь, выбирается IT-процесс,
имеющий максимальную оценку по шкале приоритетности.
Определив приоритетный IT-процесс, необходимо приступать к сбору
информации о процессе. Правильный выбор методов и источников сбора информации способствует более качественному анализу IT-процесса.
22
Классическими методами сбора и источниками данных об IT-процессе
принято считать рабочие семинары, интервью, вопросники и анкеты, документацию по процессу, наблюдение и информационные системы [8].
Результатом этапа сбора информации должно явиться заполнение анкеты
проекта анализа IT-процесса, которая содержит информацию о заинтересованных лицах, целях и задачах анализа, границах анализа, желаемом результате и
т.д.
Выявление узких мест IT-процесса – работа, направленная на оценку ITпроцессов, для получения сведений, которые способствуют принятию эффективных управленческих решений. Предварительные оценки узких мест аналитики могут сформировать на этапе сбора информации по процессу, которые
уточняются и конкретизируются на следующем этапе.
Одним из ключевых показателей эффективности IT-процессов является
уровень зрелости. Определение уровня зрелости процесса позволяет оценить
логическую структуру процесса, его управляемость, измеримость, контролируемость и результативность. Обычно рассматривают пять уровней зрелости ITпроцессов: начальный, повторяемый, определенный, управляемый и оптимизирующий.
Уровни зрелости, помимо определения узких мест процесса, дают возможность предварительно наметить варианты улучшений, которые позволили
бы перейти процессу на более высокий уровень.
В определенных ситуациях для анализа IT-процесса подходит метод анализа состояния процесса по отношению к типовым требованиям. Данный метод
позволяет выявить узкие места процесса уже на первых этапах анализа. Типовые требования к IT-процессам включают в себя следующее:
– IT-процесс должен иметь только одного владельца с четко выделенными правами и областью ответственности;
– границы и ресурсы IT-процесса должны быть четко выделены и задокументированы по функциям и ответственности;
– в IT-подразделении должны существовать и применяться регламенты
23
процессов, положение о подразделении, должностные инструкции и т.д.;
– каждый IT-процесс должен содержать четко определенный вход (выход) и их поставщиков (потребителей), должны быть разработаны спецификации, содержащие требования к входам (выходам) процессов, для каждого входа
(выхода) должен иметься ответственный, должна функционировать система
контроля качества входов и выходов;
– должна функционировать система сбалансированных показателей.
Отражением роли IT-процессов и их оптимизации в общей структуре
компании является процессная модель управления качеством информационных
услуг (ITSM), созданная в рамках проекта ITIL [27].
ITSM не дает конкретных рекомендаций по анализу и совершенствованию IT-процессов, однако такую модель можно применять, в первую очередь,
для сравнения функционирования собственных процессов с эталоном и максимально подстраиваться по него.
В настоящее время широкое распространение для анализа IT-процессов
получила эталонная библиотека Information Technology Infrastructure Library
(ITIL), которая содержит рекомендации и «лучшие практики» в области управления IT-процессами, организации и оценки деятельности IT-подразделения.
Основополагающими книгами ITIL v.2 считаются книги по поддержке и
предоставлению IT-услуг, которые определяют эталонную организацию и перечень IT-процессов компании.
Конкретный набор IT-процессов зависит от специфики, возможностей и
потребностей бизнеса. Тем не менее ITIL укрупненно выделяет процессы поддержки IT-инфраструктуры, бизнес-приложений и пользователей, а также общие параметры (показатели) оценки IT-процессов.
Вышеуказанные способы анализа процессов (уровни зрелости, эталонная
модель ITSM, типовые рекомендации и «лучшие практики» эталонной библиотеки ITIL) позволяют построить интегрированную экспертную шкалу оценивания IT-процессов по нескольким областям экспертных знаний (таблица 1.6), которая может быть использована при проектировании системы.
24
Таблица 1.6 – Перечень областей экспертных знаний оценки IT-процессов
Обозначение
области
01
02
03
04
05
06
07
Область экспертных знаний
Затраты на управление процессом
Ответственность за процесс
Документированность процесса
Ориентация процесса на «лучшие практики»
Обучение участников процесса
Рациональность использования ресурсов процесса
Удовлетворенность клиента результатом процесса
Интегрированная шкала оценки IT-процессов, представленная в таблице
1.7, предполагает оценку исходя из опросов владельцев, исполнителей, участников, а также руководства и потребителей процесса. Такая процедура требует
не только высокой квалификации аналитика, но и больших временных, трудовых и финансовых затрат на сбор, обработку, систематизацию информации от
экспертов.
Чтобы значительно снизить затраты, повысить уровень объективности и
достоверности результатов анализа, компания может инициировать процедуру
проектирования интеллектуальной системы, которая впоследствии будет поддерживать анализ IT-процессов.
25
Таблица 1.7 – Оценка IT-процесса по каждой области экспертных знаний
Обозначение
области
1
01
1
2
Организации сложно и затратно управлять процессом,
поэтому управление затратами не осуществляется
Уровень
2
3
3
4
Организация начинает управЗатраты и все усилия
лять затратностью процесса,
управления процессом
но затраты на управление посводятся к минимуму
прежнему высоки
В документах отражена информация об ответственных
Документально запроцесса, однако на деле откреплен ответственветственным за процесс счита- ный за процесс
ется все IT-подразделение
02
Ответственные за процесс
отсутствуют
03
Процесс происходит хаотично и не документирован
Процесс задокументирован
частично
Процесс полностью
задокументирован и
регламентирован
04
Стандарты управления процессом не внедряются, опыт
других организаций не применяется
По мере возможности применяются некоторые стандарты и
политики других организаций
в рамках управления процессом
Организация регулярно прибегает к использованию лучших
российских практик и
стандартов
Инвестирование в участников процесса не производится, на обучение сотрудники
не направляются
Понимается важность обучения участников процесса новым технологиям, обучение
проводится частично, когда
имеются ресурсы, и не систематизировано. Отсутствует
план обучения
Обучение участников
процесса происходит
постоянно
05
26
4
5
Затраты на управление минимальны. Инвестиции в процесс
дают быструю и заранее просчитываемую отдачу
Четко распределена ответственность, установлен уровень владения процессом
Документирование процесса автоматизировано, с этой целью
используется специальное программное обеспечение
Постоянное улучшение процесса
посредством сравнения с лучшим мировым опытом в IT, организация соблюдает и комбинирует ряд стандартов по управлению процессом
Обучение поддерживается на
должном уровне, самыми современными средствами. В организации есть мотивационная программа, предусматривающая
вознаграждение сотрудников за
совершенствование своих знаний и навыков в области процесса
Окончание таблицы 1.7
1
06
07
2
Ресурсы процесса используются не рационально, существует проблема нехватки
или наоборот избыточности
применяемых ресурсов на
процесс
Клиент полностью не удовлетворен результатом процесса
3
Методы планирования ресурсов процесса применяются неактивно. Важность оптимизации ресурсов подкреплена
прошлым опытом. Распределение ресурсов происходит
хаотично
4
5
Активно применяются
методы планирования
ресурсов на процесс,
распределение ресурсов происходит обосновано
Ресурсы на процесс распределяются рационально, применяются и автоматизированы экономико-математические методы
и методы оптимизации
Клиент частично удовлетворен
результатами процесса, существуют значительные недоработки результата процесса. Рекомендации клиента не учитываются
В ходе выполнения
процесса учитываются
пожелания и рекомендации клиента к конечному продукту
процесса, имеются незначительные погрешности в рамках
выхода процесса
Существуют и применяются мероприятия по постоянному
улучшению продукта процесса,
собираются требования клиента
к процессу, в том числе с помощью специализированного программного обеспечения. Оперативно исправляются дефекты
процесса. Клиент полностью
удовлетворен результатом процесса
27
1.3 Технология проектирования интеллектуальных систем
Проектирование интеллектуальной системы – итеративный процесс, требующий участия нескольких групп специалистов компании: эксперты в области
IT-процесса, инженер знаний, проектировщики интерфейсов, баз знаний и др.
Конкретный состав участников проектирования определяется объемом и трудоемкостью требуемых работ.
Этапы и технология проектирования интеллектуальной системы неразрывно связаны с понятием ее жизненного цикла, под которым понимается период времени от момента принятия решения о необходимости создания интеллектуальной системы до ее утилизации.
Как один из процессов жизненного цикла интеллектуальной системы
проектирование предусматривает действия и задачи, выполняемые проектировщиком, и охватывает весь объем работ по созданию проекта системы, ее
компонентов в соответствии с требованиями бизнеса (рисунок 1.6).
Описание
предметной
области
Проектирование
архитектурных
компонентов
системы
Моделирование
требований к
системе
Расчет затрат
разработки
системы
Рисунок 1.6 – Этапы проектирования интеллектуальной системы
Описание предметной области (предпроектное обследование) является
важным и определяющим этапом проектирования интеллектуальной системы.
При правильном подходе к реализации этапа значительно сокращаются эксплуатационные расходы и количество ошибок после сдачи системы.
Предпроектное обследование объекта интеллектуализации содержит процессы описания компании как хозяйствующего объекта, моделирования предметной области и предварительной оценки целесообразности проектирования
системы.
28
Описание компании как хозяйствующего субъекта предполагает изучение
организационно-экономической характеристики компании в целом и включает
описание:
– специфики деятельности компании;
– факторов внешней и внутренней среды, влияющие на компанию в целом;
– стратегии, целей и задач компании;
– бизнес-архитектуры компании.
Под бизнес-архитектурой в данном случае понимается перечень подразделений (организационная структура) и бизнес-процессов компании, которые
поддерживаются IT-процессами.
Моделирование предметной области включает определение аспекта рассмотрения проектируемой системы (точки зрения), объекта проектирования и
моделирование его организационной и функциональной структуры. В общем
случае моделирование предметной области осуществляется с применением
графических методов, поддерживаемых CASE-средствами, в некоторых случаях используется текстовое или табличное описание.
Предварительная оценка целесообразности проектирования позволяет
определить проблемы, решаемые посредством интеллектуальной системы, и
эффект, который получит компания после ее успешного внедрения.
Предпроектное обследование предметной области позволяет сформулировать перечень основных требований к проектируемой интеллектуальной системе, которые уточняются и дополняются на протяжении всего процесса проектирования.
Стандарт IEEE Standard Glossary of Software Engineering Terminology
(1990) определяет требования как условия или возможности, необходимые
пользователю для решения проблем или достижения целей, и выделяет три
уровня требований к системам [12]:
– бизнес-требования;
– требования конечных пользователей;
29
– функциональные требования.
Под бизнес-требованиями понимают высокоуровневые требования, которые обосновывают инициацию проекта, определяют перечень проблем бизнеса,
решаемых системой.
Требования пользователей (пользовательские требования) устанавливают
цели и задачи, которые способна решить система в терминах предметной области.
Функциональные требования определяют функциональность интеллектуальной системы, которую разработчики должны построить, чтобы удовлетворить пользовательские требования в рамках реализации бизнес-целей.
Как правило, при проектировании интеллектуальной системы требования
оформляются в виде моделей и документов. Согласно технологии Unified Process, к основным документам спецификации требований относится концепция,
глоссарий предметной области и дополнительные спецификации.
Концепция определяет глобальные цели проекта разработки системы
(бизнес-требования) и основные особенности проектирования системы. Определяющей частью концепции является постановка задачи проектирования,
определяющая требования к функциям системы.
Словарь предметной области (глоссарий) определяет общую терминологию для всех моделей и описание требований к системе.
Дополнительная спецификация (технические требования) содержит описание нефункциональных требований к системе, таких, как надежность, удобство использования, производительность, сопровождаемость и др.
Функциональные требования к системе моделируются и документируются с помощью диаграмм вариантов использования. Вариант использования –
связный элемент функциональности, предоставляемый системой при взаимодействии с действующими лицами, и соответствующий цели некоторого действующего лица [32].
Действующее лицо – роль, обобщение элементов внешнего окружения
системы, ведущих себя по отношению к системе одинаковым образом. Такие
30
роли исполняют либо пользователи системы, либо внешние системы, взаимодействующие с системой.
В контексте процесса управления требованиями варианты использования
трактуются следующим образом:
– вариант использования фиксирует соглашение между участниками проекта относительно поведения системы;
– вариант использования описывает поведение системы при различных
условиях, когда система отвечает на запрос одного из участников, называемого
основным действующим лицом;
– основное действующее лицо инициирует взаимодействие с системой,
чтобы добиться некоторой цели (если вариант использования имеет уровень
«цель пользователя»).
Модель вариантов использования состоит из диаграмм вариантов использования и текстовых описаний вариантов использования. Диаграмма вариантов
использования составляется системным аналитиком, который сначала выявляет
элементы модели, а затем устанавливает связи между ними, а также структурирует модель. Элементами диаграмм вариантов использования являются варианты использования и действующие лица, соединенные разного рода связями.
Функциональные требования подробно фиксируются в описаниях вариантов использования. Описания составляются специальным образом, чтобы
уменьшить вероятность неверного толкования и облегчить восприятие текста.
Каждое описание включает в себя:
– краткое описание, являющееся сжатым обзором варианта использования;
– основной поток событий, описывающий взаимодействие системы и
действующих лиц, при котором достигается цель основного действующего лица;
– альтернативные потоки, описывающие обработку ошибок и исключительных ситуаций;
– подчиненные потоки, которые облегчают описание основного и альтер31
нативных потоков;
– предусловия и постусловия.
Каждый поток событий задается перенумерованным набором шагов. Используются шаги трех типов:
– действие системы;
– реакция действующего лица;
– управление потоком.
Спецификации требований к системе позволяют перейти к проектированию архитектуры интеллектуальной системы, которое включает следующие задачи:
– трансформации требований к системе в соответствующую архитектуру,
определяющую структуру и состав компонентов интеллектуальной системы;
– проектирования интеллектуального интерфейса;
– проектирования базы знаний.
Под архитектурой интеллектуальной системы понимается совокупность
решений, определяющих такую организацию интеллектуальной системы, которая бы в полной мере удовлетворяла имеющимся спецификациям. Проектирование архитектуры системы предполагает выбор структурных элементов, из которых будет состоять будущая система, объединение элементов в отдельные
модули, а также определение поведения структурных элементов при взаимодействии между собой и внешней средой.
После определения архитектурных компонентов проектируемой системы
каждый компонент рассматривается по отдельности. Типовая архитектура интеллектуальной системы обязательно должна содержать исполнительную систему, интеллектуальный интерфейс и базу знаний (рисунок 1.2).
Исполнительная система обеспечивает вывод решения определенной системой задачи, закладывается при проектировании структурных элементов и их
взаимосвязей, а реализуется непосредственно при программировании системы.
При проектировании интеллектуального интерфейса необходимо учитывать, что интерфейс должен выполнять четыре основные функции:
32
– управление компьютером в зависимости от действий пользователя (открытие, закрытие системы, действия прерывания и т.д.);
– ввод данных пользователем и отклик системы, который определен на
этапе моделирования требований;
– отображение данных, введенных пользователем;
– поддержка пользователя в процессе взаимодействия с системой (случайные непреднамеренные действия).
Структура интеллектуального интерфейса состоит из визуального оформления, отвечающего за предоставление информации пользователю, реализации
функциональных возможностей системы. Описывается такая структура как совокупность экранных форм (окон), на которых располагаются активные или
пассивные элементы.
Совокупность экранных форм проектируется посредством диаграммы состояний. Диаграмма состояний преобразует требования к системе в состояния
интеллектуального интерфейса на различных этапах реализации данных требований, начиная от входа в систему и заканчивая выходом из нее. Каждое состояние характеризуется наличием на форме (окне) элементов (таблица 1.8).
Таблица 1.8 – Перечень основных элементов интеллектуального интерфейса
Элемент
Кнопка
Вкладка
Текст
Список
Поле
Флажок
Характеристика
Базовый элемент интерфейса. При нажатии на кнопку происходит программно-связанное с этим нажатием действие либо событие
Элемент интерфейса пользователя, позволяющий выбрать одну из нескольких перечисленных опций системы
Элемент графического интерфейса, предназначенный для вывода сообщений
Элемент графического интерфейса пользователя, который отображает прокручиваемый список с элементами. Позволяет пользователю выбрать один
или несколько элементов из списка, как правило с удержанной клавишей Ctrl
или Shift, чтобы сделать множественный выбор. Все элементы содержатся в
списке статически, но могут быть добавлены и динамически
Элемент графического интерфейса пользователя, позволяющий производить
ввод и вывод текстовой информации в определенной области интерфейса
Элемент графического пользовательского интерфейса, позволяющий пользователю управлять параметром с двумя состояниями – включено, выключено
Проектирование базы знаний – один из основных этапов разработки ин33
теллектуальной системы. Именно от правильности ее проектирования зависит
последующий вывод результатов системой.
Проект базы знаний представляется в виде деревьев решений, отображающих логику вывода решения интеллектуальной системы. В некоторых случаях для удобства восприятия деревья разбиваются на несколько блоков, реализующих один аспект вывода системы.
Каждое дерево содержит в неявном виде факты и правила базы знаний.
Факты представляют собой суждения экспертов, на основе которых по правилам формируются переходы по дереву решений, то есть в зависимости от ответов пользователя осуществляется переход по той или иной ветке дерева решений. В результате прохождения определенного пути дерева пользователь приходит к логическому заключению системы.
В завершении проектирования системы рассчитываются предварительные затраты на разработку систему. Статьи затрат могут различаться в зависимости от проекта разработки. Обычно рассчитывают расходы на себестоимость
разработки, затраты на распространение системы среди подразделений и единовременные затраты. С учетом бизнес-требований стоимость разработки корректируют на величину нормативной прибыли.
34
2 Исследование процедуры анализа IT-процессов АО «Биохимик»
2.1 Организационно-экономическая характеристика АО «Биохимик»
АО «Биохимик» является одним из ведущих промышленных предприятий
Республики Мордовия и одним из важнейших производителей лекарственных
препаратов в России, основанное в 1959 году. В настоящее время АО «Биохимик» производит более ста наименований лекарственных средств в инъекционных, таблетированных, ампульных и капсульных формах, мазях, гелях и суппозиториях. Порядка 70% выпускаемых предприятием препаратов входят в Перечень необходимых и важнейших лекарственных средств (ЖНВЛП).
Помимо производства в дополнительные виды деятельности АО «Биохимик» входят:
– печатание и издание газет;
– строительство жилых и нежилых зданий;
– торговля оптовая фармацевтической продукцией;
– торговля розничная лекарственными средствами в специализированных
магазинах (аптеках);
– аренда и управление собственным или арендованным недвижимым
имуществом;
– деятельность в области архитектуры и рекламных агентств;
– деятельность по уходу с обеспечением проживания;
– предоставление социальных услуг без обеспечения проживания.
Миссия предприятия формулируется как обеспечение сохранения здоровья и качества жизни людей. Основным направлением развития является выпуск импортозамещающей продукции, ориентация и координация производственной и экспертной политики в соответствии с требованиями рынка.
В качестве средства оценки стратегического состояния АО «Биохимик»
рассмотрим SWOT-анализ (таблица 2.1).
35
Таблица 2.1 – Матрица SWOT-анализа АО «Биохимик»
Сильные стороны
1. Квалифицированный персонал
2. Развитая сеть продаж продукции
3. Развитая IT-инфраструктура
4. Модернизация производства в соответствии со стандартом GMP
5. Широкие технологические возможности
6. Устойчивые позиции на рынке России
7. Отсутствие конкурентов в Мордовии
Возможности
1. Высокий потенциал роста для российского сегмента фармацевтического рынка
2. Повышение объема продаж ввиду роста
общей заболеваемости населения
3. Привлечение молодых специалистов
4. Активное сотрудничество с аптечным
сектором
Слабые стороны
1. Низкий уровень информационной прозрачности компании
2. Низкая рентабельность производства,
обусловленная издержками и износом оборудования
3. Ограниченный выбор поставщиков
4. Относительно низкие инвестиции в
НИОКР
5. Низкие расходы на маркетинг
Угрозы
1. Высокая степень регулирования государством фармацевтической отрасли
2. Ужесточение конкуренции на фармацевтическом рынке
3. Повышение цен на энергоресурсы
4. Санкции со стороны иностранных поставщиков ресурсов
Оценить влияние отдельных факторов внутренней среды (по пятибалльной шкале) позволяет экспертный метод определения степени воздействия выделенных в SWOT-матрице сильных и слабых сторон АО «Биохимик» (таблица
2.2).
Таблица 2.2 – Анализ влияния факторов внутренней среды АО «Биохимик»
Вес
Сильные стороны
Квалифицированный персонал
0,30
Развитая IT-инфраструктура
0,20
Модернизация производства в соответствии со
0,25
стандартом GMP
Широкие технологические возможности
0,25
Суммарная оценка
1,00
Слабые стороны
Низкий уровень информационной прозрачности
0,25
Низкая рентабельность производства, обуслов0,25
ленная издержками и износом оборудования
Относительно низкие инвестиции в НИОКР
0,30
Низкие расходы на маркетинг
0,20
Суммарная оценка
1,00
SWOT-факторы
Оценка
Степень воздействия
5
4
1,50
0,80
5
1,25
4
–
1,00
4,55
3
0,45
3
0,75
2
3
–
0,40
0,45
2,05
Таким образом, можно утверждать, что ключевыми внутренними факторами успеха АО «Биохимик» являются квалифицированный персонал, каче36
ственная продукция, произведенная по стандарту GMP, широкие технологические возможности. Совокупное влияние данных факторов обеспечивает высокую производительность труда.
АО «Биохимик» – одна из немногих организаций в Мордовии, которая
заботится о развитии и благополучии своих сотрудников. Компания постоянно
совершенствует не только систему стимулирования труда сотрудников, но и их
инновационную деятельность.
Целью компании является формирование организационных условий и
мотивационных факторов для личного успеха каждого сотрудника, а также вовлечение персонала в решение стоящих перед компанией задач, активное использование инициативы, опыта и знаний собственных специалистов. Одним из
способов реализации данной программы компания считает запуск масштабных
проектов развития сотрудников с высоким потенциалом роста, построение мотивационных схем таким образом, чтобы затраченные ресурсы приводили к росту производительности труда и реальным бизнес-результатам.
Начиная с 2015 года, среднесписочная численность персонала АО «Биохимик» постоянно увеличивалась, что связано с ростом объема производства и
появлением необходимости в новых квалифицированных сотрудниках (рисунок
2.1).
Рисунок 2.1 – Динамика среднесписочной численности персонала АО «Биохимик» за 2013–2017 гг., чел.
37
Исследование состава персонала позволяется сделать вывод, что молодежь на предприятие привлекается неактивно. Спросом пользуется опытная рабочая сила, о чем свидетельствует средний возраст (51 год) и стаж (17 лет) производственного персонала предприятия.
Одно из приоритетных направлений в области выпускаемой продукции
АО «Биохимик» – постоянное совершенствование и повышение результативности системы контроля качества применительно к разработке, производству,
хранению и реализации лекарственных средств в соответствии с требованиями
современных международных стандартов.
Контроль качества выпускаемой продукции осуществляется квалифицированными специалистами на современном оборудовании, обеспечивающем
достоверность результатов.
Система менеджмента качества компании сертифицирована на соответствие требованиям ГОСТ Р ИСО 9001 (ISO 9001:2015). Также компанией получено заключение Минпромторга РФ № GMP - 0075-000133/16 от 15.11.2016 г. о
соответствии производителя лекарственных средств для медицинского применения требованиям Правил надлежащей производственной практики (GMP).
Динамика объемов производства и продаж фармацевтической продукции
АО «Биохимик» за 2011–2017 гг. приведена в таблице 2.3.
Таблица 2.3 – Динамика производства и реализации продукции АО «Биохимик»
за 2011–2017 гг.
Год
2011
2012
2013
2014
2015
2016
2017
Объем производства, тыс. р.
1 764 107
1 388 859
1 347 488
1 067 083
1 682 992
1 930 476
2 015 731
Темпы роста, %
базисные цепные
100,00
–
78,73
78,73
76,38
97,02
60,49
79,19
95,40
157,72
109,43
114,71
114,26
104,42
Объем продаж, тыс. р.
1 816 704
1 445 691
1 425 518
1 125 586
1 703 600
2 018 297
2 121 027
Темпы роста, %
базисные
цепные
100,00
–
79,58
79,58
78,47
98,60
61,96
78,96
93,77
151,35
111,10
118,47
116,75
105,09
Среднегодовой темп роста объемов производства равен 102,25%, то есть в
год объем производства продукции АО «Биохимик» в среднем увеличивается
38
на 2,25% за исследуемый период.
Среднегодовой темп роста объемов продаж фармацевтической продукции
равен 102,61%. Объем продаж (выручки) фармацевтического предприятия за
исследуемый период в среднем за год растет на 2,61%.
Стратегические цели, которые направлены на поддержание эффективного
долгосрочного развития компании, представлены в виде системы сбалансированных показателей, характеризующих цели компании в разрезе различных аспектов ее деятельности (рисунок 2.2).
Рисунок 2.2 – Стратегическая карта АО «Биохимик»
В рамках реализации стратегических целей АО «Биохимик» использует
линейно-функциональную структуру управления (рисунок 2.3), во главе кото39
рой стоит исполнительный директор, делегирующий ряд своих полномочий по
управлению директорату.
Рисунок 2.3 – Организационная структура АО «Биохимик»
Директорат координирует взаимодействие между производством и структурными подразделениями, участвует в разработке стратегии, анализе финансового и экономического состояния компании, отвечает за выполнение приказов исполнительного директора и др.
Техническая служба обеспечивает непрерывное функционирование
средств автоматизации и управление ими, при необходимости проводит ремонтные работы, закупку и разработку новых средств автоматизации, организует плановые проверки состояния оборудования и т.д.
Структурное объединение технологии и качества разрабатывает новые
технологии производства лекарственных средств, контролирует соблюдение
действующих в компании стандартов качества.
Производство АО «Биохимик» включает в себя производство готовых лекарственных средств и активных фармацевтических субстанций.
Служба логистики отвечает за функции снабжения, управления запасами,
40
складирования, грузоперевозок и т.д.
Административная служба – подразделение, отвечающее за организацию
управления всеми службами компании, решение финансовых вопросов, вопросов кадрового обеспечения и прочее.
Как уже упоминалось, существующая организация работы АО «Биохимик» соблюдает требования системы менеджмента качества. В компании действуют и утверждены нормативные документы по управлению качеством (политика в области качества, руководства по качеству, концепция бережливого
производства и т.д.). Процессный подход к управлению в соответствии с требованиями ГОСТ Р ИСО 9001 реализуется, в первую очередь, посредством разработанной в компании карты процессов (рисунок 2.4).
Рисунок 2.4 – Карта бизнес-процессов АО «Биохимик»
41
Все бизнес-процессы АО «Биохимик» разбиты на три группы, среди которых наибольшую добавленную стоимость обеспечивают ключевые процессы.
Центральное место среди ключевых процессов занимает процесс производства. Он обеспечивает целенаправленное превращение исходного сырья и
материалов в готовую фармацевтическую субстанцию заданного свойства и качества (рисунок 2.5).
Рисунок 2.5 – Бизнес-процесс «Производство продукции» АО «Биохимик»
Все ключевые бизнес-процессы, в том числе процесс производства, АО
«Биохимик» задокументированы. Регламенты процессов содержат четкое описание владельцев, целей процессов, входы и выходы, а также критерии оценки
результатов процессов (таблица 2.4).
Таблица 2.4 – Характеристика бизнес-процесса «Производство продукции»
АО «Биохимик»
Аспект процесса
1
Наименование процесса
Владелец процесса
Цель процесса
Характеристика
2
Производство продукции
Директор по производству
Обеспечить выпуск запланированного объема продукции требуемого качества
42
Окончание таблицы 2.4
1
Материальные входы
Материальные выходы
Информационные входы
Информационные выходы
Критерии оценки результата процесса
2
Сырье и материалы
Готовая продукция
План продаж
Приемо-сдаточный акт
Предъявление и извещение на сдачу готовой
продукции
Отчет по производству
Выполнение плана производства
Прием продукции отделом качества
Таким образом, АО «Биохимик», являясь одной из лидирующих компаний в своей отрасти, имеет достаточно развитые производственные мощности,
которые подкреплены квалифицированным персоналом, эффективной системой
планирования и высокой степенью стандартизации качества. Разумеется, такая
крупная промышленная компания должна обладать сильной информационной
поддержкой не только ключевых, но и вспомогательных и управляющих бизнес-процессов для реализации приоритетных направлений развития.
2.2 Оценка деятельности IT-подразделения АО «Биохимик»
Отдел информационных технологий АО «Биохимик» является структурным подразделением компании, обеспечивающим информационную поддержку
бизнес-процессов.
Основными целями работы отдела информационных технологий компании являются:
– развитие информационных технологий и систем управления бизнеспроцессами компании;
– поддержание локально-вычислительной сети компании в работоспособном состоянии;
– обеспечение бесперебойной работы аппаратных средств вычислитель43
ной техники и пользователей;
– реализация IT-проектов в контексте развития информационного обеспечения бизнес-процессов.
Все IT-окружение АО «Биохимик» условно делится на зоны ответственности: сети и сетевое оборудование, сервисы и ресурсы, компьютерная и оргтехника, IT-телефония, системы контроля доступа и видеонаблюдение. Организационная структура отдела построена в соответствии с выделенными зонами
ответственности и IT-функциями (рисунок 2.6).
Рисунок 2.6 – Организационная структура IT-отдела АО «Биохимик»
Отдел поддержки пользователей обеспечивает программную поддержку
пользователей компьютерной и офисной техники. Целью отдела является бесперебойная работа компьютерной техники, офисного оборудования и программно-технических средств. В рамках своей работы отдел занимается:
– настройкой и обслуживанием компьютерного и офисного оборудования;
– установкой и настройкой операционных систем и программного обеспечения;
– настройкой и подключением периферийных устройств;
– настройкой сетевого оборудования.
Подразделение разработки информационных систем преследует цель создания и внедрения информационных ресурсов и автоматизированных систем
44
поддержки бизнес-процессов АО «Биохимик». Основными направлениями работы отдела являются:
– проектирование и создание автоматизированных систем управления
бизнес-процессами АО «Биохимик»;
– разработка корпоративных баз данных;
– оформление технической документации, пользовательских инструкций;
– обеспечение качества разрабатываемых систем;
– планирование внедрения информационных систем;
– организация обучения пользователей.
Отдел развития инфраструктуры предназначен для координации и регулирования деятельности IT-инфраструктуры, организационно-технического
обеспечения автоматизированных систем и баз данных. Цель функционирования отдела – создание единого информационного пространства АО «Биохимик»
посредством реализации совокупности организационных, методических и технических мероприятий и информационных технологий. Кроме того, отдел занимается анализом потребностей в технических и программных средствах, созданием технических заданий на разработку информационных систем. Основными задачами отдела являются:
– обеспечение проведения инновационной политики в области информационных систем компании;
– анализ требований бизнес-подразделений в технических, программных
средствах;
– контроль работ в области развития инфраструктуры;
– распределение технических и программных средств по бизнесподразделениям АО «Биохимик».
Отдел связи обеспечивает создание, техническое обслуживание и дальнейшее развитие информационной инфраструктуры, включающей корпоративную сеть передачи данных, средства и системы связи, коммуникации, IPтелефонию.
Отдел информационной безопасности разрабатывает единую политику
45
АО «Биохимик» в области защиты информационных ресурсов компании, определяет требования к системе защиты информации и документооборота, как в
бумажном, так и в электронном виде, контролирует и оценивает меры и средства защиты информации. В соответствии с задачами отдел реализует следующие функции:
– оценка защищенности информационных активов;
– обучение и консультирование сотрудников АО «Биохимик»;
– участие в рабочих группах по оценке рисков информационной безопасности;
– устранение внештатных ситуаций в области защиты информации;
– оценка и управление информационными рисками.
В отделе информационных технологий АО «Биохимик» внедрен и используется процессный подход к управлению. Все процессы отдела условно
разделяются по уровню управления на стратегические, тактические, оперативные и технологические (рисунок 2.7).
Рисунок 2.7 – Процессы отдела информационных технологий АО «Биохимик»
46
Определяющими IT-процессами, оказывающими поддержку бизнеса АО
«Биохимик», являются такие процессы, как управление запросами пользователей, проблемами, конфигурациями, разработкой и внедрением информационных систем, уровнем сервиса и информационной безопасностью.
Процесс управления запросами пользователей предназначен для оперативного восстановления IT-услуги и реагирования на обращения бизнесподразделений. Персональную ответственность за данный процесс несут системные администраторы. В некоторых ситуациях к процессу могут подключаться и другие группы специалистов отдела. Основные функции процесса
определяют выявление и регистрацию обращений пользователей, классификацию обращений, делегирование задач соответствующему специалисту и контроль закрытия обращений.
Инициируется процесс управления запросами с момента возникновения
инцидента в бизнес-подразделении. В большинстве случаев сотрудники бизнесподразделения не обращаются сразу в отдел информационных технологий за
помощью, а пытаются решить инцидент самостоятельно. В том случае, если
самостоятельное решение инцидента ни к чему не приводит, сотрудники обращаются за помощью к системному администратору. Опытный системный администратор, имеющий базу типовых решений инцидентов, предлагает сотрудникам варианты разрешения проблемы и проводит работы по закрытию инцидента. Предварительно инцидент обязательно фиксируется в информационной
системе отдела информационных технологий для его изучения и предотвращения последующих возникновений. Отдел информационных технологий АО
«Биохимик» реализует многоуровневую поддержку пользователей. Схематично
процесс управления запросами пользователей представлен на рисунке 2.8.
47
Рисунок 2.8 – Процесс управления запросами пользователей АО «Биохимик»
Предотвратить последующие возникновения инцидентов или свести их
количество к минимуму призван процесс управления проблемами. Под проблемой отдел определяет неизвестную причину одного или нескольких запросов
пользователей.
Отдел информационных технологий управляет проблемами посредством
организации деятельности по минимизации влияния инцидентов на ключевые
бизнес-процессы АО «Биохимик», вызванные ошибками в IT-инфраструктуре.
Реализуется процесс действиями по выявлению основных причин запросов
пользователей, определению способов обхода или устранения проблемы.
Управление проблемами (рисунок 2.9) включает контроль проблем и
ошибок, предотвращение и анализ основных проблем.
Рисунок 2.9 – Процесс управления проблемами АО «Биохимик»
48
Так как все инциденты (запросы пользователей) подлежат обязательной
регистрации, отдел имеет в своем распоряжении базу данных инцидентов. На
основе существующей базы данных выявляется и регистрируется перечень актуальных проблем, а также проводится их классификация (для делегирования
процесса решения сотрудникам с необходимыми полномочиями). Этим занимает исключительно руководитель отдела информационных технологий.
После классификации соответствующим специалистом исследуется проблема и, если проблемы нет в базе готовых решений, предлагается и осуществляется план ее разрешения с дальнейшим внесением плана в базу готовых решений. Если же похожая проблема уже решалась, то предлагается вариант из
базы решенных проблем, проводятся необходимые работы и закрытие проблемы. Как и управление запросами, управление проблемами имеет многоуровневую структуру контроля.
Управление конфигурациями – процесс, отвечающий за управление информацией о конфигурационных единицах IT-инфраструктуры компании. Процесс отвечает за сбор и систематизацию информации о составных частях ITинфраструктуры и обеспечение данной информацией других IT-процессов.
АО «Биохимик» выделяет три основных элемента конфигурации:
– конфигурационные единицы;
– активы;
– материально-технический ресурсы.
Конфигурационные единицы – строительные блоки для поддержки критически важных бизнес-процессов и сервисов. Они включают серверы, маршрутизаторы, программное обеспечение и т.д.
Активами признаются персональные компьютеры, ноутбуки, иная техника, которая находится на финансовом контроле и не требует управления.
Материально-технические ресурсы представляют собой различные периферийные устройства, флэш-карты, мышки, клавиатуры и т.д.
Процесс управления конфигурациями необходим не только для решения
проблем путем идентификации причин «поломок» (какой элемент вышел из
49
строя, и как его «починить»), но и позволяет полностью предотвращать их возникновение за счет оценки логики работы с данными.
Процесс начинается с подготовительного этапа, который выполняется
бизнес-подразделением. Затем на местах определяется исходное состояние
конфигураций программного и аппаратного обеспечения для того, чтобы понять из каких элементов состоит инфраструктура АО «Биохимик» сейчас.
Одним из определяющих и важных этапов управления конфигурациями
является контроль изменений – процесс, который должен применяться ко всем
действиям, производимым с объектами ИТ-инфраструктуры.
После идентификации элементов конфигурации отдел информационных
технологий организует процесс постоянного отслеживания жизненного цикла
конфигурационных единиц (учет состояний).
Заключительным этапом процесса является проверка и аудит. Этап обеспечивает гарантию достоверности данных, представленных в базе конфигурационных единиц (CI): все рабочие CI должны соответствовать тому, что указано в базе и потребностям бизнес-подразделений, а документация должна точно
описывать все CI. Схематично процесс управление конфигурациями представлен на рисунке 2.10.
Рисунок 2.10 – Процесс управления конфигурациями АО «Биохимик»
50
С учетом проблем, выявленных отделом информационных технологий
АО «Биохимик», а также требований бизнес-подразделений к качеству информационной поддержки функционирует процесс управления изменениями. Любое изменение в IT-инфраструктуре АО «Биохимик» подразумевает совокупность действий по сбору и отбору требований (то есть, какую задачу планируется решить после изменения). Собирает и отбирает требования по возможным
изменениям руководитель отдела.
Отдел информационных технологий выделяет стандартные изменения
(они, как правило, не требуют дополнительных согласований с руководством и
другими подразделениями), специфичные (требуют согласований) и экстренные. При этом экстренные изменения могут быть как стандартными, так и специфичными. Процесс управления изменениями представлен на рисунке 2.11.
Рисунок 2.11 – Процесс управления изменениями АО «Биохимик»
В некоторых случаях одобренные и согласованные изменения требуют
разработки (доработки) информационной системы или ее отдельных модулей.
Управление разработкой информационных систем – процесс, который отвечает
за внедрение, разработку и контроль качества всех видов программного и аппаратного обеспечения АО «Биохимик».
Процесс управления разработкой информационных систем АО «Биохи51
мик» состоит из последовательности этапов. На основе одобренных запросов на
изменения формируется план разработок, проводится начальная приоритезация,
анализ предметной области, предварительная оценка трудозатрат на анализ и
разработку. Затем проводится детальный анализ и оценка, подготовка спецификаций по изменениям, отобранным на основании приоритетов заказчика (бизнес-подразделения). На основе спецификаций происходит этап разработки и
исправления дефектов. После разработки группа программистов проводит
внутреннее тестирование системы и подготовку к приемочному тестированию,
которое проводит бизнес-подразделение. Если приемочное тестирование не
пройдено, то система возвращается на исправление выявленных ошибок и проведение необходимых доработок (по согласованию). Если приемочное тестирование прошло успешно, то система передается в бизнес-подразделение АО
«Биохимик» на постоянную эксплуатацию. Схематично процесс управления
разработкой информационных систем представлен на рисунке 2.12.
Рисунок 2.12 – Процесс управления разработкой информационных систем
АО «Биохимик»
Одними из значимых IT-процессов на тактическом уровне являются процессы управления информационной безопасностью и уровнем обслуживания.
Процесс управления информационной безопасностью предполагает оцен52
ку потенциальных и существующих рисков предприятия, предварительно систематически собирая информацию о них. Оценка рисков происходит в контексте оценки угроз и уязвимостей IT-инфраструктуры. Если наличие угроз и уязвимостей не выявлено, процесс завершается. В противоположном случае происходит планирование мероприятия по устранению или снижению рисков с
дальнейшей оценкой эффективности проведенных мероприятий. Схема процесса управления информационной безопасностью отображена на рисунке 2.13.
Рисунок 2.13 – Процесс управления информационной безопасностью
АО «Биохимик»
Управление уровнем обслуживанием – процесс, оказывающий определяющее влияние на бизнес-процессы АО «Биохимик». Бизнес АО «Биохимик»
предъявляет высокие требования к уровню предоставляемого ему IT-сервиса. В
рамках реализации процесса отделом информационных технологий разработано и функционирует соглашение об уровне сервиса (SLA), которое регулярно
обновляется в зависимости от требований бизнеса. Управлять уровнем обслуживания – значит постоянно отслеживать и контролировать IT-процессы, отвечающие за обслуживание. Схематично процесс управления уровнем обслуживания представлен на рисунке 2.14.
53
Рисунок 2.14 – Процесс управления уровнем обслуживания АО «Биохимик»
Одним
из
приоритетных
направлений
деятельности
отдела
информационных технологий АО «Биохимик» в области IT-процессов является
непрерывное
потребностями
развитие
бизнеса.
технологий,
инфраструктуры
Обеспечивается
это
с
в
соответствии
помощью
с
процедуры
постоянного анализа IT-процессов для нахождения возможностей повышения
уровня обслуживания путем принятия эффективных управленческих решений.
2.3 Процедура проведения анализа IT-процессов АО «Биохимик»
Важнейшим
элементом
системы
управления
IT-процессами
АО
«Биохимик» являются информационные потоки, характеризующие текущее
состояние IT-процессов. В АО «Биохимик» ежедневно генерируются большие
объемы информационных потоков, относящихся к различным областям
деятельности компании. Главной задачей в таких условиях становится
организация сбора, хранения и обработки значимой для повышения качества
информационных услуг информации. Так как отдельной должности аналитика
в
отделе
информационных
технологий
нет,
вся
ответственность
за
информационно-аналитическую деятельность возгалается на руководителя и
сотрудников отдела.
Информационно-аналитическая
деятельность
54
отдела
строится
на
постоянном
мониторинге
IT-процессов
посредством
информационного
обеспечения, поступающего из различных источников. Источниками знаний о
процессах выступают архивные документы, базы знаний, информационные
системы и т.д., то есть объективные знания, которые переведены в форму,
пригодную для потребителя. Как правило, проблем со сбором, обработкой и
хранением таких знаний у отдела информационных технологий не возникает.
Особый интерес информационного обеспечения анализа IT-процессов
представляют экспертные знания, которые имеются у сотрудников бизнесподразделений
АО
«Биохимик»,
но
никак
не
зафиксированные
на
материальных носителях. Выявление экспертных субъективных знаний
представляет для отдела крайне сложную задачу, требующую значительных
усилий.
В зависимости от масштаба решаемой проблемы и целей анализа
организацию процедуры сбора и обработки информации осуществляет или сам
руководитель отдела, или группа сотрудников отдела под его руководством.
Состав работ по сбору информации об IT-процессах представлен в таблице 2.5.
Таблица 2.5 – Состав работ по сбору и обработке информации в
АО «Биохимик»
Наименование этапа
1
Определение целей сбора
информации
Анализ и выбор
существующих источников
информации
Планирование работ по сбору
и обработке информации
Предварительный сбор и
анализ документации
Краткое описание
2
Определение целей сбора
информации
Руководитель отдела
информационных технологий
определяет перечень доступных
экспертов
Разрабатывается план сбора и
обработки информации,
формируется предварительный
перечень вопросов
Собираются и изучаются
нормативные документы
потребителей IT-услуг
55
Результат этапа
3
Спецификация целей
сбора информации
Список экспертной
группы
План работ, включая
предварительный
перечень вопросов
экспертам
Корретиктировка
переченя вопросов
экспертам,
окончательный
перечень вопросов
Окончание таблицы 2.5
1
2
Подготавливаются формы для
сбора информации в бизнесподразделениях
Проводится инструктаж по
методике и плану интервью
Время интервью
согласовывается с экспертами,
корректируется план работ по
сбору и обработке информации
Руководитель отдела
информационных технологий
проводит интервью среди
экспертов
Подготовка к сбору
информации
Подготовка к проведению
интервью
Согласование времени
проведения интервью
Проведение интервью
Проверка полученной
информации на корректность
Полученная информация
проверяется на корректность
Обработка полученной
информации
Проводится обработка
полученной информации и
документирование результатов
3
Формы для сбора
информации
Подготовленные
интервьюеры
Согласованное время
проведения интервью
Информация по ITпроцессу
Проверенная и
систематизированная
информация
Обработанная и
пригодная для
принятия
управленческих
решений информация
На первом этапе руководитель отдела информационных технологий
совместно с сотрудниками отдела определяют цели сбора информации и
структуру необходимой информации, которая в дальнейшем понадобится для
анализа
IT-процесса.
Цели
определяются
конкретными
условиями
и
специфичностью выбранного для анализа IT-процесса. Обычно обсуждения,
касающиеся
выбора
того
или
иного
процесса
для
анализа,
как
и
формулирование целей, происходят в результате организации рабочих
совещаний среди сотрудников отдела.
Рабочие совещания представляют собой один из наиболее продуктивных
способов получения информации о процессе. При этом качество и скорость получения информации при таком методе максимальны. Главным недостатком
является большие трудозатраты, сложность сбора участников совещания. Такие
семинары обычно затягиваются и отнимают много рабочего времени сотрудников.
Организация процедуры сбора экспертных знаний, необходимых для
56
анализа IT-процессов, предполагает выявление группы экспертов. Экспертная
группа опередялется исходя из анализируемого IT-процесса и целей,
поставленных на первом этапе.
Выполняя работу по подбору экспертной группы, в которую могут
входить как сотрудники бизнес-подразделений АО «Биохимик», так и
сотрудники отдела информационных технологий, требуется решить следующие
задачи:
– определение областей деятельности (подразделений), которые связаны с
анализируемым процессом;
– определение состава экспертов по каждой области деятельности;
– определение количества и предварительного состава экспертов в
группе;
– анализ квалификации отобранных экспертов;
– получение согласия экспертов на участие в анализе IT-процесса;
– составление окончательного списка состава экспертов.
Кроме организации подбора экспертной группы, которая предоставляет
знания об IT-процессе, должна быть уверенность в компетентности экспертной
группы.
Планирование работ по сбору и обработке информации включает в себя
определение временных рамок аналитической работы, методов и способов
сбора информации, предварительные варианты вопросов, которые будут
задаваться экспертам, и ответы, которые планируется получить, а также
ресурсы, выделяемые для сбора информации. Как правило, план работ
формируется, как и цели сбора информации, в результате рабочих совещаний
отдела и фиксируется в электронном виде.
На основе разработанного плана и целей сбора информации об ITпроцессе
сотрудники
отдела
информационных
технологий
изучают
нормативную документацию, определяющую работу бизнес-подразделений, в
которых работают эксперты. Документация позволяет определить специфику
деятельности подразделения и те аспекты IT-процесса, на которые нужно
57
обратить особое внимание при подготовке к интервью. Более детальное
изучение потребителя
IT-процесса дает основу для корректировки и
формирования окончательного перечня вопросов, обеспечивая качественный
сбор информации.
Подготовка к сбору сведений и непосредственному интервьюированию
складывается из формирования форм для сбора информации и проведения
инструктажа среди интервьеров. Предварительно перед процедурой интервью
руководитель отдела информационноых технологий согласует время и место
его проведения.
Опрос (выявление знаний) экспертов представляет собой заслушивание и
фиксацию суждений о исследумом IT-процессе. Наиболее часто применяется
такой способ опроса, как интервьюирование.
В процессе организации опросов экспертов руководитель отдела
информационных технологий создает условия, при которых эксперты
обеспечены в максимальной степени всей необходимой информацией и
возможностью для проявления творческой активности и самовыражения.
Интервьюирование
представляет
для
отдела
информационных
технологий продуктивный метод сбора информации об IT-процессах. Информация, наиболее приближенная к реальности, исходит из результатов последовательного общения руководителя отдела информационных технологий с экспертами предметных областей, участвующими в IT-процессе. Индивидуальные
или коллективные встречи с экспертами в сочетании с правильно заданными
вопросами позволяют получать достоверную информацию о процессе, однако
такие встречи отнимают много времени и трудозатрат.
Интервьюирование может проводиться с использованием двух методик.
Выбор методики проведения интервью определяется целями анализа ITпроцесса, сущностью решаемой проблемы, полнотой и достоверностью
исходной информации по процессу, временными и ресурсными ограничениями.
Первая методика подразумевает следующий состав работ:
– подготовка форм анкет для сбора информации;
58
– проведение обучения интервьюируемых;
– раздача и заполнение анкет интервьюируемыми;
– сбор и обработка анкет.
Данная методика предполагает разработку специальных анкет для
опрашиваемых сотрудников, к которой обязательно прикладывается пример и
инструкция по заполнению. Затем руководитель отдела информационных
технологий инициирует процесс проведения анкетирования и, в зависимости от
объема
экспертной
группы,
раздачу
необходимого
количество
анкет
участникам экспертной группы. За отведенное время экспертная группа
заполняет анкеты и возвращает их сотрудникам отдела информационных
технологий, проводящих анкетирование, после чего проводится их обработка.
Как показывает практический опыт обработки анкет, большая часть анкет
оказывается заполненной некорректно и неполно. Использовать такие анкеты
для анализа IT-процессов и интерпретации результатов крайне проблематично.
Подобная ситуация складывается из-за нежелания экспертной группы
полно и аккуратно отвечать на вопросы, поставленные в анкете. Такая работа
является для них дополнительной и не оплачиваемой. Во многих случаях
экспертная группа совершенно не понимает целей проведения анкетирования
или не обучена методике работы с анкетой. В результате это приводит к
значительным трудозатратам для получения информации, так как приходится
по несколько раз уточнять и переделывать.
Вторая методика интервьюрирования предполагает следующий состав
работ:
– подготовка анкет;
– проведение обучения интервьюируемых;
– проведение интервью;
– заполнение анкеты на основе полученной информации.
Непосредственно перед проведением интервью сотрудники отдела
информационных технологий подготавливают анкеты, но уже в несколько
другой форме, чем при первой методике. Анкета представляет собой перечень
59
вопросов, которые нужно узнать у интервьюируемого. Полагаясь на анкету,
интервьюер проводит опрос экспертной группы и фиксирует полученную
информацию в произвольной форме. После проведения опроса информация
заносится в анкету в электронном виде.
Вторая методика применяется более часто, чем первая, так как ее основой
является
проведение
квалифицированных
индивидуальных
интервью
с
последующей обработкой информации. Однако, данная методика предъявляет
значительные требования к квалификации и опыту сотрудников, которые
выполняют интервьюирование, а также является намного затратнее, чем первая,
поскольку требует индивидуального опроса каждого эксперта.
После того как выполнено интервьюирование экспертной группы,
сотрудники отдела информационных технологий АО «Биохимик» проводят
встречную проверку полученных данных путем сопоставления информации,
полученной от одного эксперта, с информацией, полученной от других
экспертов. В случае незначительных расхождений информации, полученной от
экспертов, организуется обработка информации для приведение ее в вид,
пригодный для принятия управленческих решений.
Процедура сбора и обработки субъективной информации по IT-процессам
АО «Биохимик» – важная задача с точки зрения оптимизации IT-процессов
поддержки бизнеса. Такая процедура требует специальной подготовки и
слаженной работы сотрудников отдела информационных технологий на
каждом этапе работ, что характеризует длительность реализации отдельных
этапов работ. Временные затраты на процедуру проведения анализа ITпроцессов АО «Биохимик» в усредненном виде представлены на рисунке 2.15.
60
Рисунок 2.15 – Среднее время реализации этапов анализа IT-процесса
АО «Биохимик», дни
Исследование информационного обеспечения анализа IT-процессов АО
«Биохимик»
показало,
что
значительное
количество
информационного
материала поступает руководителю отдела информационных технологий в
недостаточно обработанном виде. В результате нередко на обработку
информации не хвататает сил и времени, она быстро устаревает и становится
непригодной для принятия управленческих решений.
На организацию аналитической работы уходит значительный объем как
временнных, так и людских ресурсов. Начинается все с определения целей
анализа, которые не всегда точно отражают специфику ситуации. В связи с
этим цели приходится корректировать на протяжении всей аналитической
работы.
Не
совсем
верно
поставленные
цели
требуют
проведения
дополнительных работ по сбору сведений, на которые расходуются ресурсы не
только отдела информационных технологий, но и экспертной группы.
Дополнительные опросы негативно воспринимаются экспертами, которые
помимо этого должны заниматься основной работой. Вследствии этого
дополнительного опросы могут совсем не проводиться, или проводиться, но с
низким качеством информации на выходе. Кроме того, подбор экспертной
61
группы часто происходит наугад, потому что заранее предвидеть желание и
мотивацию экспертов сотрудничать и приносить пользу компании не всегда
предоставляется возможным.
Планирование работ обычно требует проведения рабочих семинаров
среди сотрудников отдела информационных технологий, на которые трудно
обеспечить явку всех сотрудников. Многие сотрудники относятся к этапу
планирования не совсем серьезно, что в дальнейшнем сказывается на качестве
собранной информации.
Подготовка к проведению интервью также требует значительных затрат и
усилий. Формы готовятся относительно долго, помимо этого их приходится
много раз переделывать, вносить изменения.
Полученная и зафиксированная в электронном виде информация в
результате интервью часто теряется. Единая база знаний экспертных групп не
организована.
Основная
часть
нагрузки
приходится
на
руководителя
отдела
информационных технологий, как на отвественного за процедуру анализа ITпроцесса. Интенсивная работа часто идет в ущерб другим обязанностям
сотрудников отдела и его руководителя.
Решением сложившейся ситуации может быть привлечение в штат
дополнительного сотрудника, который бы отвечал за анализ IT-процессов и
координаровал
данную
процедуру,
или
частичная
интеллектуализация
процедуры анализа IT-процессов посредством разработки интеллектуальной
системы.
Дополнительный сотрудник – это дополнительные затраты, которые
складываются из затрат на поиск сотрудника, заработной платы, обучения и т.д.
К тому же дополнительный сотрудник не всегда дает гарантии исправления
ситуации.
Интеллектуальная
система
поддержки
анализа
IT-процессов
даст
возможность руководителю отдела информационных технологий:
– разгрузить отдел информационных технологий и заниматься другими
62
важными обязанностями;
– своевременно получать качественную информацию об IT-процессе;
– не заботиться о наличии экспертных групп и об организации их сбора;
– организовать единое хранилище знаний;
– значительно снизить временные и ресурсные затраты на проведение
анализа;
– постоянно обновлять информацию об IT-процессах и собирать ее
только в условиях необходимости пополнения базы знаний;
– сэкономить денежные средства.
63
3 Совершенствование процедуры проведения анализа IT-процессов
АО «Биохимик»
3.1 Моделирование требований к интеллектуальной системе
Для устранения недостатков процедуры проведения анализа IT-процессов
отделом информационных технологий АО «Биохимик» ставится задача проектирования интеллектуальной системы, способной на начальном этапе оказать
поддержку анализа процессов. Предполагается, что система позволяет пользователю в диалоговой форме определить проблемные места анализируемого
процесса.
Проектируемая система должна поддерживать два режима работы: режим
консультации и режим редактирования базы знаний.
Основным пользователем системы в режиме консультации является руководитель отдела информационных технологий АО «Биохимик», обладающий
полным и актуальным перечнем знаний состояния предметной области.
Режим редактирования базы знаний реализует свойство динамичности
системы. Такой режим обеспечивает внесение администратором системы изменений в существующую базу знаний (по согласованию с экспертом предметной
области). В отдельных случаях роль пользователя консультационного режима и
режима редактирования может совпадать.
Система реализуется на основе модульного принципа и должна предоставлять доступ пользователя к модулю идентификации IT-процесса, выявления узких мест IT-процесса и внесения изменений в базу знаний посредством
интеллектуального интерфейса. Модули режима консультации реализуются занесением пользователем в систему ответов на вопросы, предложенные системой. Для каждого консультационного модуля должна существовать отдельная,
независимая база знаний, которая обеспечивает (в зависимости от ответов пользователя) логический механизм вывода результата.
На основе постановки задачи проектирования, описания системы и биз64
нес-моделей предметной области создается глоссарий проекта (таблица 3.1).
Таблица 3.1 – Глоссарий проекта
Термин
Руководитель отдела информационных технологий
Характеристика
Основной пользователь системы в режиме консультации
Пользователь системы в режиме редактирования базы
Администратор системы
знаний и поддержки системы
Вопрос, требующий от руководителя отдела информаВопрос системы
ционных технологий ответной реакции
Реакция руководителя отдела информационных техОтвет пользователя
нологий на вопрос системы
Идентификация IT-процесса
Определения IT-процесса, подлежащего анализу
Анализ IT-процесса по различным областям экспертВыявление узких мест IT-процесса
ных знаний
Исходя из постановки задачи проектирования и сформированного глоссария проекта можно выделить список действующих лиц и их интересов:
1. Руководитель отдела информационных технологий – идентифицирует
IT-процесс, выявляет узкие места его функционирования.
2. Администратор системы – своевременно вносит изменения в базы знаний, сопровождает систему на этапе эксплуатации.
Список интересов действующих лиц позволяет предложить следующие
варианты построения диаграммы вариантов использования нулевого уровня:
– войти в систему;
– идентифицировать IT-процесс;
– выявить узкие места IT-процесса;
– внести изменения в базу знаний.
Вариант использования входа в систему не соответствует явной цели действующих лиц. Данный вариант обеспечивает функциональное требование системы по разграничению доступа и имеет несколько действующих лиц. Полагая, что руководитель отдела информационных технологий и администратор
системы входят по одному и поведение системы постоянно при входе действующих лиц, введем абстрактное лицо Пользователь (рисунок 3.1).
65
Рисунок 3.1 – Диаграмма вариантов использования нулевого уровня
Подробнее функциональные требования фиксируются в описаниях вариантов использования. Создадим описания для каждого варианта использования,
при этом дополнив диаграмму нулевого уровня детализацией.
Вариант использования «Войти в систему»:
Краткое описание
Данный вариант использования описывает вход пользователя в систему.
Основной поток событий
1. Пользователь запускает систему.
2. Система запрашивает логин и пароль.
3. Пользователь вводит логин и пароль.
4. Система подтверждает правильность логина и пароля.
5. Система определяет тип пользователя и предоставляет доступ к функциям системы в соответствии с определенным типом.
Альтернативный поток событий
Неправильный логин или пароль.
1. Система обнаруживает, что введен неверный логин или пароль.
2. Система сообщает пользователю об ошибке и предлагает либо заново
ввести логин и пароль, либо отказаться от входа в систему.
3. Пользователь сообщает системе свой выбор.
66
4. В соответствии с выбором пользователя выполнение переходит либо на
этап 2 основного потока, либо вариант использования завершается.
Предусловия
Отсутствуют.
Постусловия
Система гарантирует, что пользователю, неправильно указавшему логин
и пароль, доступ в главное меню не будет предоставлен.
Детализированная диаграмма нулевого уровня для варианта использования входа в систему представлена на рисунке 3.2.
Рисунок 3.2 – Диаграмма вариантов использования «Войти в систему»
Вариант использования «Идентифицировать IT-процесс»:
Краткое описание
Данный вариант использования описывает процедуру выбора руководителем отдела информационных технологий IT-процесса для проведения детального анализа.
Основной поток событий
1. Пользователь открывает модуль идентификации IT-процесса.
2. Система предлагает выбрать IT-процесс для оценки целесообразности
проведения его анализа.
3. Пользователь выбирает IT-процесс либо из перечня, предложенного
системой, либо абстрактный IT-процесс.
67
4. Система предлагает пользователю поставить галочку напротив тех
ключевых факторов успеха, на которые оказывает существенное влияние выбранный IT-процесс.
5. Пользователь соотносит ключевые факторы успеха с IT-процессом.
6. Система формирует оценку важности IT-процесса.
7. Система последовательно предлагает пользователю перечень вопросов
для определения проблемности IT-процесса.
8. Пользователь последовательно дает ответы на вопросы, предложенные
системой.
9. Система формирует оценку проблемности IT-процесса.
10. Система предлагает пользователю оценить возможность проведения
анализа IT-процесса по нескольким факторам.
11. Пользователь оценивает каждый предложенный системой фактор по
пятибалльной шкале.
12. Система формирует оценку возможности проведения анализа ITпроцесса.
13. Система формирует интегральную оценку целесообразности проведения анализа выбранного IT-процесса и сообщает об этом пользователю.
14. Пользователь сохраняет результаты идентификации IT-процесса.
Альтернативный поток событий
Пользователь пытается выйти из системы, не сохранив результат идентификации IT-процесса.
1. Система обнаруживает попытку выхода из системы без сохранения результатов.
2. Система предлагает пользователю сохранить результат.
3. В зависимости от ответа пользователя происходит либо переход на
этап 14 основного потока событий, либо выход из системы.
Предусловия
1. Пользователь вошел в систему.
Постусловия
68
Система гарантирует, что на выходе пользователю будет предоставлена
консультация по вопросу приемлемости IT-процесса для детального анализа.
Детализированная диаграмма варианта использования нулевого уровня
для идентификации IT-процесса представлена на рисунке 3.3.
Рисунок 3.3 – Диаграмма вариантов использования «Идентифицировать
IT-процесс»
Вариант использования «Выявить узкие места IT-процесса»:
Краткое описание
Данный вариант использования описывает процедуру детальной оценки
руководителем отдела информационных технологий выбранного IT-процесса.
Основной поток событий
1. Пользователь открывает модуль выявления узких мест IT-процесса.
2. Пользователь выбирает IT-процесс либо из перечня, предложенного
системой, либо абстрактный IT-процесс.
3. Система последовательно предлагает пользователю перечень вопросов,
направленных на выявление узких мест IT-процесса.
4. Пользователь последовательно отвечает на вопросы системы.
5. Система формирует и предоставляет оценку узких мест IT-процесса.
69
6. Пользователь сохраняет результаты оценки узких мест IT-процесса.
7. Пользователь выходит из системы.
Альтернативный поток событий
Пользователь пытается выйти из системы, не сохранив результат оценки
узких мест IT-процесса
1. Система обнаруживает попытку выхода из системы без сохранения результатов.
2. Система предлагает пользователю сохранить результат.
3. В зависимости от ответа пользователя происходит либо переход на
этап 6 основного потока событий, либо выход из системы.
Предусловия
1. Пользователь вошел в систему.
Постусловия
Система гарантирует, что на выходе пользователю будет предоставлена
консультация по вопросу наличия узких мест исследуемого IT-процесса.
Детализированная диаграмма варианта использования нулевого уровня
для выявления узких мест IT-процесса представлена на рисунке 3.4.
Рисунок 3.4 – Диаграмма вариантов использования «Выявить узкие места ITпроцесса»
70
Вариант использования «Внести изменения в базу знаний»:
Краткое описание
Данный вариант использования описывает процедуру внесения изменений в базу знаний администратором системы.
Основной поток событий
1. Пользователь открывает модуль внесения изменений в базу знаний.
2. Пользователь вносит изменения в базу знаний системы (добавляет правила и факты).
3. Система предлагает сохранить изменения.
4. Пользователь сохраняет внесенные изменения и выходит из системы.
Альтернативный поток событий
Отсутствует.
Предусловия
1. Пользователь вошел в систему.
Постусловия
Система гарантирует, что внесенные изменения в базу знаний будут доступны пользователю в консультационном режиме.
Детализированная диаграмма варианта использования нулевого уровня
для внесения изменений в базу знаний представлена на рисунке 3.5.
Рисунок 3.5 – Диаграмма вариантов использования «Внести изменения в базу
знаний»
71
Кроме функциональных требований интеллектуальная система также
должна определять дополнительную спецификацию, которая выражается в ряде
нефункциональных требований.
К нефункциональным требованиям системы анализа IT-процессов можно
отнести требования к доступности, надежности, переносимости, безопасности и
удобства использования системы.
В условиях работы отдела информационных технологий АО «Биохимик»
доступность, то есть время непрерывной работы, должна определяться как длительность рабочей недели, в течение которой руководитель отдела имеет возможность воспользоваться системой. Так как в АО «Биохимик» принят восьми
часовой рабочий день, предполагается, что величина доступности должна быть
равна 40 часов в неделю.
Надежность системы должна определять возможность сохранения знаний, хранящихся в базе, и возврата к точке остановки при аварийных ситуациях, таких как непредвиденный перезапуск компьютера, сбои в электропитании
и т.д.
Интеллектуальная система также должна удовлетворять требованиям переносимости, то есть одинаково инсталлироваться и запускаться на нескольких
устройствах, имеющих в некоторых случаях различные конфигурации.
Система не должна позволять вносить изменения в базу знаний пользователю, не имеющему на это соответствующее право.
3.2 Проектирование компонентов архитектуры интеллектуальной
системы
Моделирование требований к интеллектуальной системе анализа ITпроцессов позволяет определить перечень необходимых компонентов системы
и их взаимосвязь между собой (рисунок 3.6).
Все компоненты системы разделяются на два уровня: уровень сервиса и
72
уровень ядра системы. Для выполнения консультационных функций используется ядро системы, а для внесения изменения в базу знаний – сервис.
Рисунок 3.6 – Компоненты архитектуры интеллектуальной системы
Компонент интеллектуального интерфейса отвечает за обмен информацией между пользователем и системой в форме вопрос-ответ, а также позволяет
проводить авторизацию и вносить изменения в базу знаний в диалоговом режиме. Данный компонент является одним из центральных, поскольку именно
он обеспечивает взаимодействие пользователей с системой. На рисунке 3.7
представлены варианты состояния интеллектуального интерфейса системы на
различных этапах взаимодействия с пользователем.
Окно авторизации обеспечивает вход пользователя в систему и содержит
на форме два поля для ввода (логин, пароль) и две кнопки (войти, выйти). При
наличии ошибок ввода на форме появляется соответствующее сообщение.
Главное меню содержит две либо три вкладки в зависимости от типа авторизованного пользователя. Вход в режиме консультации обеспечивает наличие на форме двух вкладок для выбора: идентификация IT-процесса и выявле73
ние узких мест IT-процесса. Режим редактирования дополняется третьей вкладкой: редактирование базы знаний.
Окна идентификации IT-процесса и выявления узких мест IT-процесса
содержат краткое текстовое описание назначения выбранного модуля, небольшую инструкцию по дальнейшему использованию модуля и две кнопки: начать,
вернуться в главное меню.
Доступ к окну выбора базы для редактирования предоставляется только
администратору системы. Окно содержит два элемента списка. Первый элемент
обеспечивает редактирование базы знаний идентификации IT-процесса, второй
– выявление узких мест IT-процесса. Формы редактирования обеих баз знаний
совпадают и включают в себя текстовые поля для ввода новых правил и фактов
и кнопку «Добавить», а также поля, отображающие списки существующих фактов и правил, и кнопку «Удалить».
Окно выбора IT-процесса включает список наименований IT-процессов
для выбора, где присутствует также особый тип процесса – абстрактный процесс, и две кнопки: продолжить, вернуться в главное меню.
После того как пользователь выберет IT-процесс, открывается либо окно
соотнесения ключевых факторов успеха с IT-процессом, либо вопросноответная форма. Если пользователь изначально выбрал модуль идентификации
IT-процесса, то вопросно-ответная форма открывается сразу после того, как будет нажата кнопка «Продолжить» в окне соотнесения ключевых факторов успеха с IT-процессом. В случае изначального открытия модуля выявления узких
мест IT-процесса, нажатие кнопки «Продолжить» в окне выбора IT-процесса
сразу влечет за собой появление окна вопросно-ответной формы.
Окно соотнесения ключевых факторов успеха с IT-процессом предполагает проставление галочек напротив тех ключевых факторов успеха, которые
пользователь считает наиболее влияющими на выбранный IT-процесс. Следовательно, на форме окна должно отображаться неизменяемое текстовое поле,
отображающее название ключевых факторов успеха. Рядом с названием располагается элемент типа флажок.
74
Вопросно-ответная форма и окно оценки факторов возможности также
имеют неизменяемое текстовое поле. В первом случае неизменяемое текстовое
поле соответствует вопросам системы, во втором – названию фактора, влияющего на возможности анализа. Рядом с текстовым полем в обоих случаях располагаются варианты ответов, предопределенные системой (да или нет, число
от 1 до 5). Каждый вопрос или фактор оценивания выводится на отдельных
формах последовательно.
После того как система задаст пользователю все вопросы, открывается
окно, предоставляющее результат работы системы в текстовой форме. Пользователь может сохранить результат в текстовом файле.
Компонент сборки исходных фактов хранит вопросы, которые задаются
системой пользователю, чтобы идентифицировать IT-процесс для анализа и выявления его узких мест. Ответы на вопросы соответствуют блоку исходных
фактов и хранятся вместе с заключением (выводом) системы в рабочей памяти.
Компонент вывода предназначен для получения новых фактов на основе
сопоставления исходных данных из рабочей памяти и знаний из базы знаний и
реализует алгоритм принятия решений системой.
Просмотр результатов обеспечивает руководителя отдела информационных технологий заключением, в котором указано обоснование выбора (или не
выбора) IT-процесса для анализа, а также узкие места исследуемого ITпроцесса.
75
Рисунок 3.7 – Диаграмма состояний интеллектуального интерфейса
Основным элементом архитектуры интеллектуальной системы является
база знаний.
Поскольку проектируемая система содержит два пользовательских модуля (модуль идентификации процесса и модуль выявления узких мест идентифицированного процесса), база знаний должна разрабатываться для каждого
модуля отдельно.
В свою очередь для удобства проектирования база знаний модуля идентификации IT-процесса разбивается на три блока вывода: вывод важности, проблемности и возможности анализа. В общем случае для всех блоков идентификации процесса входным параметром, указываемым пользователем системы,
будет являться наименование IT-процесса.
На вход блока определения важности поступают только данные о количестве ключевых факторов успеха АО «Биохимик», оказывающих влияние на выбранный IT-процесс. Основным фактом, содержащимся в базе знаний, является
факт: IT-процесс оказывает влияние на N ключевых факторов успеха. Так как
анализ предметной области выявил четыре ключевых фактора успеха АО «Био76
химик» (технологические возможности, высокая производительность, качество
продукции и квалифицированный персонал), то изначально в базу знаний закладываются именно они.
Дерево решений данного блока представлено на рисунке 3.8, на основе
которого формируется правило вывода базы знаний:
1. ЕСЛИ IT-процесс оказывает влияние на M ключевых факторов успеха,
ТО оценка важности процесса равна M.
Рисунок 3.8 – Дерево решений блока важности IT-процесса
Выделим основные факты, обуславливающие базу знаний блока определения проблемности процесса:
– в функционировании процесса присутствуют (отсутствуют) серьезные
недостатки;
– в ближайшее время планируются (не планируются) мероприятия по
улучшению процесса;
– большинство выполнений процесса завершается на выходе с дефектами
(лишено дефектов);
– критерии отсутствия дефектов выхода процесса определены (не определены);
– мероприятия по устранению дефектов выхода процесса проводятся (не
проводятся).
Дерево решений блока определения проблемности IT-процесса представлено на рисунке 3.9, правила вывода которого формулируются следующим образом:
77
1. ЕСЛИ в функционировании процесса присутствуют серьезные недостатки И мероприятий по улучшению процесса не планируется, ТО оценка проблемности IT-процесса (K) равна пяти (плохой процесс).
2. ЕСЛИ в функционировании процесса присутствуют серьезные недостатки И в ближайшее время планируются мероприятия по улучшению процесса И большинство выполнений процесса завершается на выходе с дефектами И
критерии отсутствия дефектов выхода процесса не определены ИЛИ в функционировании процесса отсутствуют серьезные недостатки И большинство выполнений процесса завершается на выходе с дефектами И критерии отсутствия
дефектов выхода процесса не определены, ТО оценка проблемности ITпроцесса (K) равна четырем (не очень хороший процесс).
3. ЕСЛИ в функционировании процесса присутствуют серьезные недостатки И в ближайшее время планируются мероприятия по улучшению процесса И большинство выполнений процесса завершается на выходе с дефектами И
разработаны критерии отсутствия дефектов выхода процесса И мероприятия по
устранению дефектов выхода процесса не проводятся ИЛИ в функционировании процесса отсутствуют серьезные недостатки И большинство выполнений
процесса завершается на выходе с дефектами И разработаны критерии отсутствия дефектов выхода процесса И мероприятия по устранению дефектов выхода процесса не проводятся, ТО оценка проблемности IT-процесса (K) равна
трем (удовлетворительный процесс).
4. ЕСЛИ в функционировании процесса присутствуют серьезные недостатки И в ближайшее время планируются мероприятия по улучшению процесса И большинство выполнений процесса завершается на выходе с дефектами И
разработаны критерии отсутствия дефектов выхода процесса И проводятся мероприятия по устранению дефектов выхода процесса ИЛИ в функционировании процесса отсутствуют серьезные недостатки И большинство выполнений
процесса завершается на выходе с дефектами И разработаны критерии отсутствия дефектов выхода процесса И проводятся мероприятия по устранению дефектов выхода процесса, ТО оценка проблемности IT-процесса (K) равна двум
78
(хороший процесс).
5. ЕСЛИ в функционировании процесса присутствуют серьезные недостатки И выход процесса в значительной мере лишен дефектов, ТО оценка проблемности IT-процесса (K) равна единице (отличный процесс).
Рисунок 3.9 – Дерево решений блока проблемности IT-процесса (в скобках указана количественная оценка)
Последний блок содержит на входе оценку по пятибалльной шкале влияния отдельных факторов (финансы, персонал, законодательство и прочие факторы) на возможность проведения анализа IT-процесса. Фактами блока оценки
возможностей анализа IT-процесса являются:
– оценка финансовых факторов имеет значение N1;
– оценка факторов персонала имеет значение N2;
79
– оценка факторов законодательства имеет значение N3;
– оценка прочих факторов имеет значение N4.
Дерево решений оценки возможности проведения анализа IT-процесса
представлено на рисунке 3.10, определяющего правило вывода базы знаний:
ЕСЛИ оценка финансовых факторов равна N1 И оценка факторов персонала
равна N2 И оценка факторов персонала равна N3 И оценка прочих факторов
равна N4, ТО оценка возможности проведения анализа IT-процесса (N) равна
N1 + N2 + N3 + N4.
Рисунок 3.10 – Дерево решений блока возможности проведения анализа
IT-процесса
Объединение выводов баз знаний отдельных модулей идентификации
позволяет определить интегрированную оценку процесса. В таком случае на
вход базы знаний поступает оценка важности (M), проблемности (K) и возможности проведения анализа (N). Интегрированная оценка вывода базы знаний
отражена на рисунке 3.11 и строится по следующим правилам:
1. ЕСЛИ значение M + K + N находится в интервале от 20 до 29, ТО данный IT-процесс следует выбирать для последующего анализа в первую очередь.
80
2. ЕСЛИ значение M + K + N находится в интервале от 10 до 20, ТО данный IT-процесс выбирается для последующего анализа на усмотрение пользователя.
3. ЕСЛИ значение M + K + N находит в интервале от 1 до 10, ТО данный
IT-процесс не рекомендуется выбирать для последующего анализа.
Рисунок 3.11 – Дерево решений модуля идентификации IT-процесса
Модуль анализа идентифицированного процесса для удобства представления также целесообразно разбить на компоненты по анализируемым областям знаний, которые впоследствии будут объединены в единую базу знаний.
Область экспертных знаний затрат на управление процессом содержит
следующий перечень фактов базы знаний:
– отдел управляет (не управляет) затратами IT-процесса;
– затраты на управление IT-процессом находятся на относительно низком
(высоком) уровне;
– инвестиции в IT-процесс дают (не дают) быструю и просчитываемую
отдачу.
Дерево решений для области затрат на управление процессом представлено на рисунке 3.12 и содержит следующие правила:
1. ЕСЛИ отдел управляет затратами IT-процесса И затраты на управление
81
IT-процессом находятся относительно на высоком уровне, ТО осуществляется
управление затратами IT-процесса, однако такие затраты находятся на высоком
уровне.
2. ЕСЛИ отдел управляет затратами IT-процесса И затраты на управление
IT-процессом находятся относительно на низком уровне И инвестиции в ITпроцесс дают быструю и просчитываемую отдачу, ТО отдел эффективно и рационально управляет затратами IT-процесса.
3. ЕСЛИ отдел управляет затратами IT-процесса И затраты на управление
IT-процессом находятся относительно на низком уровне И инвестиции в ITпроцесс не дают быструю и просчитываемую отдачу, ТО затраты на управление
IT-процессом находятся на низком уровне, однако затраты еще не дают быструю и просчитанную отдачу.
4. ЕСЛИ отдел не управляет затратами IT-процесса, ТО отделу сложно и
проблематично управлять затратами IT-процесса, или такая необходимость совсем отвергается.
Рисунок 3.12 – Дерево решений модуля выявления узких мест IT-процесса
области затрат на управление
Анализ области ответственности за IT-процесс предусматривает следующий перечень фактов базы знаний:
– ответственные за результат IT-процесса определены (не определены);
82
– за результат выполнения IT-процесса несет ответственность один человек (весь отдел);
– уровень владения IT-процессом установлен (не установлен).
Дерево решений для области ответственности за процесс представлено на
рисунке 3.13 и содержит следующие правила:
1. ЕСЛИ ответственные за результат IT-процесса определены И за результат выполнения IT-процесса несет ответственность весь отдел, ТО владелец
IT-процесса назначен, однако на деле ответственность распределяется на всех
сотрудников отдела.
2. ЕСЛИ ответственные за результат IT-процесса определены И за результат выполнения IT-процесса несет ответственность один человек И для ответственного за IT-процесс установлен уровень владения процессом, ТО ответственность за результат IT-процесса четко определена и закреплена за конкретным лицом, установлен уровень владения процессом.
3. ЕСЛИ ответственные за результат IT-процесса определены И за результат выполнения IT-процесса несет ответственность один человек И для ответственного за IT-процесс не установлен уровень владения процессом, ТО существует единственный владелец IT-процесса, но уровень его владения процессом не определен.
4. ЕСЛИ ответственные за результат IT-процесса не определены, ТО результат функционирования процесса не отслеживается и не управляется, ответственность отсутствует.
83
Рисунок 3.13 – Дерево решений модуля выявления узких мест IT-процесса
области ответственности за процесс
Ориентацию IT-процесса на «лучшие практики» определяют следующие
факты интеллектуальной системы:
– стандарты управления процессом или опыт других организаций применяются (не применяются);
– стандарты или опыт других организаций применяются постоянно (не
регулярно);
– применяется (не применяется) мировой опыт и комбинации стандартов
по управлению процессом.
Дерево решений для области ориентации IT-процесса на «лучшие практики» представлено на рисунке 3.14 и содержит следующие правила:
1. ЕСЛИ стандарты управления процессом или опыт других организаций
применяются И стандарты или опыт других организаций применяются не регулярно, ТО стандарты и опыт других организаций применяется только от случая
к случаю и по мере возможностей.
2. ЕСЛИ стандарты управления процессом или опыт других организаций
применяются И стандарты или опыт других организаций применяются постоянно И применяется мировой опыт и комбинации стандартов по управлению
процессом, ТО происходит постоянное улучшение процесса посредством российского и мирового бенчмаркинга, а также комбинации стандартов управле84
ния IT-процессами.
3. ЕСЛИ стандарты управления процессом или опыт других организаций
применяются И стандарты или опыт других организаций применяются постоянно И не применяется мировой опыт и комбинации стандартов по управлению
процессом, ТО отдел регулярно применяет при управлении процессом только
лучшие российские практики и стандарты.
4. ЕСЛИ стандарты управления процессом или опыт других организаций
не применяются, ТО отдел отрицает внедрение стандартов управления ITпроцессами и применение бенчмаркинга.
Рисунок 3.14 – Дерево решений модуля выявления узких мест IT-процесса
области ориентированности на «лучшие практики»
Задокументированность IT-процесса определяется следующим перечнем
фактов базы знаний:
– документация, определяющая функционирование IT-процесса, разработана (не разработана);
– все (не все) аспекты IT-процесса охвачены документацией;
– документация по процессу обновляется регулярно (редко);
– автоматизированные средства документирования процесса используются (не используются).
Дерево решений для области документированности IT-процесса представлено на рисунке 3.15 и содержит следующие правила:
85
1. ЕСЛИ документация, определяющая функционирование IT-процесса
разработана И не все аспекты IT-процесса охвачены документацией, ТО задокументированы только важные области IT-процесса, полная задокументированность отсутствует.
2. ЕСЛИ документация, определяющая функционирование IT-процесса
разработана И все аспекты IT-процесса охвачены документацией И документация по процессу обновляется редко, ТО документация IT-процесса существует
только формально и для управления не применяется.
3. ЕСЛИ документация, определяющая функционирование IT-процесса
разработана И все аспекты IT-процесса охвачены документацией И документация по процессу обновляется регулярно И автоматизированные средства документирования процесса используются, ТО с точки зрения задокументированности IT-процесс эффективен.
4. ЕСЛИ документация, определяющая функционирование IT-процесса
разработана И все аспекты IT-процесса охвачены документацией И документация по процессу обновляется регулярно И автоматизированные средства документирования процесса не используются, ТО IT-процесс полностью задокументирован, содержание документации постоянно корректируется только вручную.
5. ЕСЛИ документация, определяющая функционирование IT-процесса не
разработана, ТО IT-процесс протекает хаотично и не задокументирован, внутренние стандарты управления процессом отсутствуют.
86
Рисунок 3.15 – Дерево решений модуля выявления узких мест IT-процесса
области документированности процесса
Область обучения участников IT-процесса содержит следующие факты
базы знаний:
– обучение участников проводится (не проводится);
– обучение проводится постоянно (нерегулярно), на основе плана обучения (без плана обучения);
– присутствует (отсутствует) мотивационная программа по обучению.
Дерево решений для области обучения участников процесса представлено
на рисунке 3.16 и содержит следующие правила:
1. ЕСЛИ обучение участников проводится И обучение проводится нерегулярно, без плана обучения, ТО важность обучения участников процесса признается при наличии соответствующих ресурсов, обучение происходит хаотично, план обучения не предусмотрен.
2. ЕСЛИ обучение участников проводится И обучение проводится постоянно, на основе плана обучения И присутствует мотивационная программа по
обучению, ТО обучение участников процесса проводится на должном уровне,
сотрудники вознаграждаются за совершенствование своих навыков.
3. ЕСЛИ обучение участников проводится И обучение проводится постоянно, на основе плана обучения И отсутствует мотивационная программа по
87
обучению, ТО обучение проводится постоянно и по плану, однако сотрудники
отдела в большинстве случаях не заинтересованы в обучении.
4. ЕСЛИ обучение участников не проводится, ТО инвестиции в обучение
участников процесса не признаются.
Рисунок 3.16 – Дерево решений модуля выявления узких мест IT-процесса
области обучения участников
Рациональность использования ресурсов IT-процесса определяется следующими фактами:
– ресурсы процесса распределяются и используются рационально (не рационально);
– распределение ресурсов планируется активно (неактивно);
– используются (не используются) экономико-математические методы
планирования ресурсов;
– ресурсы процесса распределяются обосновано (не обосновано);
– планирование ресурсов происходит вручную (с применением автоматизированных средств).
Дерево решений для области рациональности использования ресурсов
процесса представлено на рисунке 3.17 и содержит следующие правила:
1. ЕСЛИ ресурсы процесса распределяются и используются рационально
И распределение ресурсов планируется неактивно, ТО методы планирования
ресурсов используются неактивно, применение ресурсов управления IT88
процессом подкреплено прошлым опытом.
2. ЕСЛИ ресурсы процесса распределяются и используются рационально
И распределение ресурсов планируется активно И используются экономикоматематические методы планирования ресурсов И планирование ресурсов происходит вручную, ТО применение экономико-математических методов планирования ресурсов процесса происходит вручную.
3. ЕСЛИ ресурсы процесса распределяются и используются рационально
И распределение ресурсов планируется активно И используются экономикоматематические методы планирования ресурсов И планирование ресурсов происходит с применением автоматизированных средств, ТО отдел не только использует специализированные методы планирования ресурсов процесса, но и
автоматизирует процедуру планирования.
4. ЕСЛИ ресурсы процесса распределяются и используются рационально
И распределение ресурсов планируется активно И не используются экономикоматематические методы планирования ресурсов И ресурсы процесса распределяются обосновано, ТО распределение ресурсов обосновано, однако не подкреплено использованием методов планирования.
5. ЕСЛИ ресурсы процесса распределяются и используются рационально
И распределение ресурсов планируется активно И не используются экономикоматематические методы планирования ресурсов И ресурсы процесса распределяются не обосновано, ТО распределение ресурсов планируется, но в большинстве случаев не обосновано, методы планирования не применяются.
6. ЕСЛИ ресурсы процесса распределяются и используются не рационально, ТО при управлении IT-процессом часто возникают ситуации нехватки
или избыточности ресурсов.
89
Рисунок 3.17 – Дерево решений модуля выявления узких мест IT-процесса
области рационального использования ресурсов
Последней областью выявления узких мест IT-процесса является область
удовлетворенности клиента результатом процесса. Область определяет следующие факты базы знаний:
– клиент удовлетворен (не удовлетворен) результатом процесса;
– клиент полностью (частично) принимает результат процесса;
– исправление дефектов продукта процесса происходит оперативно (не
оперативно);
– сбор требований клиента к продукту процесса автоматизирован (совершается вручную).
Дерево решений для области удовлетворенности клиента результатом
процесса представлено на рисунке 3.18 и включает следующие правила:
1. ЕСЛИ клиент удовлетворен результатом процесса И клиент частично
принимает результат процесса, ТО клиент частично удовлетворен результатом
процесса, существуют значительные недоработки результата процесса.
2. ЕСЛИ клиент удовлетворен результатом процесса И клиент полностью
принимает результат процесса И исправление дефектов продукта процесса
происходит не оперативно, ТО требования клиента по результату процесса учи90
тываются, однако исправление дефектов результата процесса происходит относительно долго.
3. ЕСЛИ клиент удовлетворен результатом процесса И клиент полностью
принимает результат процесса И исправление дефектов продукта процесса
происходит оперативно И сбор требований клиента к продукту процесса автоматизирован, ТО клиент полностью удовлетворен результатом процесса, отдел
постоянно ищет пути улучшения продукта процесса, в том числе с помощью
специализированного программного обеспечения.
4. ЕСЛИ клиент удовлетворен результатом процесса И клиент полностью
принимает результат процесса И исправление дефектов продукта процесса
происходит оперативно И сбор требований клиента к продукту процесса совершается вручную, ТО клиент полностью удовлетворен результатом процесса,
исправление дефектов происходит оперативно, однако требования клиентов собираются только вручную.
5. ЕСЛИ клиент не удовлетворен результатом процесса, ТО требования
клиента по результату процесса не учитываются, выход процесса полностью не
соответствует его ожиданиям.
Рисунок 3.18 – Дерево решений модуля выявления узких мест IT-процесса
области удовлетворенности клиента результатом процесса
91
Предполагается, что интеллектуальная система задает вопросы пользователю последовательно по спроектированным областям, в результате работы системы выводится общая оценка IT-процесса в отдельном окне.
На этом проектирование интеллектуальной системы можно считать завершенным, дальнейшая разработка осуществляется программистами, которые
на основе проекта системы предоставляют конечное, пригодное для использования на практике приложение.
3.3 Расчет затрат на разработку интеллектуальной системы
Расчет капитальных вложений производится исходя из трудоемкости,
длительности разработки, размера заработной платы, затрат на электроэнергию,
накладных расходов, отчислений на социальное страхование и прочих расходов. Порядок действий при разработке системы и расчет средств на оплату труда представлен в таблице 3.2.
В разработке интеллектуальной системы принимают участие на разных
этапах аналитик, инженер по знаниям и программист.
Таблица 3.2 – Расчет средств на оплату труда разработчикам интеллектуальной
системы
Этапы
Виды работ
1
2
Изучение
предметной области
Сбор требований
Постановка целей и задач
проектирования
Оформление
технического
задания
Начальный
Исполнители
КолДолжность
во
3
4
Часовая
ставка,
руб.
5
Длительность
выполнения,
дни
6
Размер
з/п,
руб.
7
1
Аналитик
156
4
4 992
1
Аналитик
156
3
3 744
1
Аналитик
156
1
1 248
1
Аналитик
156
1
1 248
92
Окончание таблицы 3.2
1
Внешнее проектирование
Разработка и
кодирование
компонентов
Основной этап
Внедрение
2
Проектирование
архитектуры системы
Проектирование
пользовательского интерфейса
3
4
5
6
7
1
Программист
188
2
3 008
1
Программист
188
2
3 008
Проектирование
базы знаний системы
1
Программист и инженер по
знаниям
357
2
5712
Разработка каждого компонента
и кодирование на
языке программирования
1
Программист
188
3
4 512
Отладка модулей
1
188
4
6 016
188
2
3 008
188
3
4 512
Тестирование
компонентов
Комплексное тестирование
Оформление программной документации
Отладка и тестирование при реальных воздействиях внешней
среды
Подготовка рабочих мест
Установка программ на рабочие
места
Обучение пользователей
1
1
Программист
Программист
Программист
1
Программист
188
2
3 008
1
Программист
188
2
3 008
1
Программист
188
3
4 512
1
Программист
188
1
1 504
1
Программист
188
3
4 512
38
57 552
Итого
Начальный этап разработки системы осуществляет аналитик с заработной
платой 25 000 рублей/мес.
С учетом 40-часовой рабочей неделей АО «Биохимик» фонд рабочего
времени, например, на июнь 2019 года составит 160 часов (8*20 дней). Следовательно, часовая ставка аналитика равна 156 рублей.
Внешнее проектирование осуществляет программист и частично инженер
93
по знаниям. Месячная заработная плата программиста равна 30 000 рублей,
инженера по знаниям – 27 000 рублей. Часовые ставки с учетом 160 часового
фонда рабочего времени составят 188 рублей и 169 рублей соответственно.
Суммарные затраты на заработную плату участникам разработки составят
57 552 рублей (таблица 3.2).
В себестоимость разработки системы включаются следующие статьи затрат:
– основная зарплата;
– отчисление на социальное страхование – отчисления на оплату перерывов в работе по временной нетрудоспособности и отчисления в пенсионный
фонд;
– прочие прямые расходы – расходы на обслуживание ЭВМ, плата за потребляемую электроэнергию, плата за доступ в сеть Интернет;
– накладные расходы.
Норматив отчислений на социальное страхование составляет 30% от величины заработной платы. Тогда сумма отчислений в социальное страхование
составит 17 266 рублей.
Стоимость 1 кВт/час электроэнергии 1,1 рубля, потребляемая мощность
400 Вт. Получим расходы на электроэнергию в размере 134 рублей (с учетом 38
дней, необходимых на разработку системы).
Стоимость 1 часа доступа в сеть Интернет 3,6 рубля. Интернет используется для отладки (4 дня), тестирования при реальных воздействиях внешней
среды (2 дня) и комплексного тестирования системы (3 дня). При условии пользования сетью Интернет 1 час в день, получим расходы в размере 32,4 рублей.
Таким образом, прочие расходы составят 166,4 рублей.
Норматив накладных расходов – 40% от величины основной и дополнительной заработной платы. Сумма накладных расходов составляет 23 021 рублей. Стоимость разработки модулей системы по статьям расходов отражена в
таблице 3.3.
94
Таблица 3.3 – Стоимость разработки модулей интеллектуальной системы
Статья расходов
Основная зарплата
Отчисления на социальное страхование
Прочие прямые расходы
Накладные расходы
Итого
Сумма, рублей
57 552
17 266
166,4
23 021
98005,4
Удельный вес, %
58,7
17,6
0,2
23,5
100
Расчет затрат на тиражирование системы производится по статьям:
– основная зарплата;
– единый социальный налог;
– материалы;
– прочие прямые расходы;
– накладные расходы.
Трудовые затраты складываются из затрат времени на запись системы на
дистрибутивный диск и печать документации всего 8 часов (1 день). При часовой ставке программиста 188 рублей размер основной заработной платы составит 1 504 рублей.
Единый социальный налог (норматив 30%) составляет 451 рубль.
Затраты на материалы (диски, бумага) составляют 120 рублей.
Прямые прочие расходы составят 10% от основной заработной платы –
150,4 рублей.
Накладные расходы (норматив 40 %) составляют 601,6 рублей.
Следовательно, себестоимость тиражирования системы составит 2 827
рублей.
С учетом одного объекта внедрения системы, себестоимость разработки
составит 98 005,4 рублей, себестоимость тиражирования 2 827 рублей, себестоимость системы на объект составит 100 832,4 рублей.
Цена системы с учетом нормативной прибыли 25% составит 126 040,5
рублей.
Единовременные затраты в сфере использования системы складываются
из стоимости приобретения системы и ее транспортировки.
95
Транспортные расходы составляют 1% от цены (12 604,05 рублей). Отсюда, суммарные единовременные затраты на разработку интеллектуальной системе составят 138 644,55 рублей.
96
ЗАКЛЮЧЕНИЕ
Деятельность современного предприятия характеризуется функционированием внутри него больших объемов информационных потоков. Отслеживание таких потоков требуется, в первую очередь, для подготовки эффективных
управленческих решений совершенствования бизнес-процессов.
На многих предприятиях учет и хранение информации организуется с
помощью автоматизированных информационных систем. При этом затраты на
анализ информации, содержащейся в информационных системах, по-прежнему
велики и не всегда обеспечивают достоверность и объективность информации.
Системы искусственного интеллекта, появившиеся сравнительно недавно, активно используются во многих сферах общества, в том числе в экономике. Интеллектуальные информационные системы позволяют качественно получать и анализировать информацию о бизнес-процессах с минимальными временными и ресурсными затратами.
Существенное влияние на бизнес предприятия оказывают IT-процессы,
так как именно они обеспечивают информационную поддержку ключевых бизнес-процессов. В такой ситуации предприятиям важно постоянно отслеживать
состояние и анализировать IT-процессы для осуществления дальнейшей их оптимизации.
АО «Биохимик» – одно из крупнейших промышленных предприятий республики Мордовия. Основополагающими факторам успеха предприятия являются квалифицированный персонал, качественная продукция, произведенная
по стандарту GMP и широкие технологические возможности. Влияние данных
факторов обеспечивает высокую производительность труда.
Среднегодовой темп роста объемов производства равен 102,25%, то есть в
год объем производства продукции АО «Биохимик» в среднем увеличивается
на 2,25% за исследуемый период.
Среднегодовой темп роста объемов продаж фармацевтической продукции
за период 2011-2017 гг. равен 102,61%. Объем продаж (выручки) фармацевти97
ческого предприятия за исследуемый период в среднем за год растет на 2,61%.
Рост объемов производства и продаж обеспечивает необходимость в росте среднесписочной численности персонала, которая (начиная с 2015 г.) постоянно увеличивается.
Оценка бизнеса АО «Биохимик» позволила сделать вывод о том, что
предприятие обладает мощной инфраструктурой, нуждающейся в качественной
информационной поддержке, которую должен предоставлять отдел информационных технологий. Однако исследование IT-процессов, поддерживающих
бизнес АО «Биохимик», выявило низкий уровень качества информации для
принятия управленческих решений руководителями отдела информационных
технологий. На сбор и обработку информации об IT-процессах расходуются
значительные ресурсы, причем полученная информация часто теряется, так как
отсутствует единая точка входа информации о процессах. Отсюда и высокая
нагрузка на весь отдел информационных технологий АО «Биохимик», несущий
ответственность за анализ IT-процессов.
Выходом из данной ситуации, позволяющим повысить качество информации об IT-процессах, снизить затраты ресурсов, разгрузить отдел информационных технологий и создать единую точку входа информации, может быть
инициация проекта разработки интеллектуальной системы, поддерживающей
на первоначальном этапе анализ IT-процессов АО «Биохимик».
В процессе проектирования интеллектуальной системы были специфицированы требования к системе в виде диаграмм вариантов использования и текстового описания их сценариев.
На основании спецификации требований была разработана архитектура
интеллектуальной системы, включающая перечень компонентов и их взаимосвязи. Все компоненты системы были поделены на два уровня: уровень сервиса
и уровень ядра. Для выполнения консультационных функций используется ядро системы, а для внесения изменений в базу знаний – сервис.
Компонент интеллектуального интерфейса несет ответственность за обмен информацией между пользователем и системой в форме вопрос-ответ, поз98
воляет проводить авторизацию, вносить изменения в базу знаний в диалоговом
режиме и представлен в виде диаграммы состояний экранных форм, текстового
описания элементов форм в зависимости от различных состояний.
Основным элементом архитектуры интеллектуальной системы является
база знаний. Так как проектируемая система содержит два пользовательских
модуля (модуль идентификации процесса и модуль выявления узких мест идентифицированного процесса), база знаний также проектировалась для каждого
модуля отдельно.
Деревья решений отразили модель базы знаний проектируемой системы,
обеспечивающей логический вывод системы и помощь руководителю отдела
информационных технологий в анализе IT-процессов. К каждому дереву решений приведены соответствующие факты и правила вывода решений базы знаний.
В заключение проектирования были рассчитаны предварительные затраты, необходимые для разработки интеллектуальной системы анализа ITпроцессов АО «Биохимик». Расчет капитальных вложений производился исходя из трудоемкости, длительности разработки, размера заработной платы инженера-программиста и аналитика, затрат на электроэнергию, накладных расходов, отчислений на социальное страхование, прочих расходов, а также затрат на
тиражирование системы.
99
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1. Абрютина М.С. Анализ финансово-экономической деятельности организации: учебник / М.С. Абрютина, А.В. Грачев. – М.: Дело и Сервис, 2017. –
256 с.
2. Александров Д.В. Моделирование и анализ бизнес-процессов: учебник
/ Д.В. Александров. – Саратов: Ай Пи Эр Медиа, 2017. – 227 с.
3. Андерсен Б. Бизнес-процессы: инструменты совершенствования /
Б. Андерсен. – М.: РИА «Стандарты и качество», 2015. – 56 с.
4. Балан В.П. Введение в системное проектирование интеллектуальных
баз знаний / В.П. Балан, А.В. Душкин., В.И. Новосельцев, В.И. Сумин. – М.:
Горячая линия – Телеком, 2016. – 107 с.
5. Бондаренко В.В. Информационные управленческие процессы на предприятии / В.В. Бондаренко, И.А. Игошина, Т.А. Глебова // Повышение управленческого, экономического, социального и инновационно-технического потенциала предприятий, отраслей и народно-хозяйственных комплексов, 2015. –
3-7 с.
6. Боровская Е.В. Основы искусственного интеллекта: учебное пособие /
К.В. Боровская, Н.А. Давыдова. – М.: Лаборатория знаний, 2016. – 130 с.
7. Бояркина А.К. Экспертные системы / А.К. Бояркина, В.В. Ермолаева //
Молодой ученый, – 2016. – № 3. – С. 286-289.
8. Варзунов А.В. Анализ и управление бизнес-процессами: учебное пособие / А.В. Варзунов, Е.К. Торосян, Л.П. Сажнева. – СПб: Университет ИТМО,
2016. – 112 с.
9. Владимирова Л.П. Прогнозирование и планирование в условиях рынка
/ Л.П. Владимирова. – М.: Издательский дом «Дашков и К», 2013. – 307 с.
10. Войт А.В. Информационный подход по управлению производственными процессами на предприятиях высокотехнологичных отраслей / А.В. Войт
// Симбирский научный вестник, 2015. – № 5. – 119-124 с.
11. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания. –
100
М.: Стандартинформ, 2009. – 6 с.
12. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология (ИТ).
Системная и программная инженерия. Процессы жизненного цикла программных средств. – М.: Стандартинформ, 2011. – 105 с.
13. Громов А.И. Управление бизнес-процессами: современные методы:
монография / А.И. Громов, А.Ш. Фляйшман, В. Шмидт. – М.: Юрайт, 2016. –
367 с.
14. Громов Ю.Ю. Теория информационных процессов и систем: учебник /
Ю.Ю. Громов, В.Е. Дидрих, О.Г. Иванова, В.Г. Однолько. – Тамбов: ФГБОУ
ВПО «ТГТУ», 2014. – 172 с.
15. Девятков В.В. Системы искусственного интеллекта: учебное пособие /
В.В. Девятков, И.Б. Фѐдоров. – М.: МГТУ им. Н. Э. Баумана, 2015. – 352 с.
16. Долганова О.И Моделирование бизнес-процессов: учебник и практикум для академического бакалавриата / О.И. Долганова, Е.В. Виноградова,
А.М. Лобанова. – Люберцы: Юрайт, 2016. – 289 с.
17. Дошина А.Д. Экспертная система. Классификация. Обзор существующих экспертных систем / А.Д. Дошина // Молодой ученый, 2016. – № 21. –
С. 756.
18. Елизаров Д.А. Моделирование архитектуры и инфраструктуры предприятия: учебно-методическое пособие / Д.А. Елизаров, А.В. Шилер. – Омск:
Омский государственный университет путей сообщения, 2017. – 39 с.
19. Елизаров Д.А. Моделирование архитектуры и инфраструктуры предприятия / Д.А. Елизаров // Символ науки, 2017. – № 5. – С. 87-89.
20. Елиферов В.Г. Бизнес-процессы: регламентация и управление: учебник / В.Г. Елиферов. – М.: НИЦ ИНФРА-М, 2013. – 319 с.
21. Жемчугов А.М. Цель предприятия и стратегия ее достижения. Концептуальные основы. Проблемы теории и практики управления / А.М. Жемчугов, М.К. Жемчугов, 2014. – 75-80 с.
22. Зараменских Е.П. Применение архитектурного подхода для построения модели многофилиальной организации / Е.П. Зараменских // Управленче101
ские науки в современном мире, 2017. – № 6. – С. 425-428.
23. Зинина Л.И. Статистические методы управления бизнес-процессами
предприятия / Л.И. Зинина, А.Н. Чегодайкин // Информационные технологии в
экономике и управлении, 2018. – № 3. – С. 26-30.
24. Зулаева З.У. Информационные технологии как фактор эффективности
управления бизнес-процессами на предприятиях / З.У. Зулаева // Современная
наука: проблемы и перспективы, 2017. – № 17. – С. 20-22.
25. Иванов В.М. Интеллектуальные системы: учебное пособие / В. М.
Иванов. – Екатеринбург: Изд-во Урал. ун-та, 2015. – 92 с.
26. Иванова Е.А. Теория менеджмента: учебное пособие / Е.А. Иванова. –
М.: МИИТ, 2014. – 176 с.
27. Ингланд Р. Овладевая ITIL: перевод с англ. / Р. Ингланд. – М.:
Лайвбук, 2011. – 200 с.
28. Инюшкина О.Г. Проектирование информационных систем (на примере методов структурного системного анализа): учебное пособие / О.Г. Инюшкина, Екатеринбург: Форт-Диалог Исеть, 2014. – 240 с.
29. Исаев Г.М. Информационные технологии в экономике: учебник для
студентов вузов / Г.М. Исаев. – М.: Омега – Л, 2015. – 462 с.
30. Кадырова Г.Р. Интеллектуальные системы: учебное пособие / Г.Р. Кадырова. – Ульяновск: УлГТУ, 2017. – 113 с.
31. Каюмова А.В. Визуальное моделирование систем в StarUML: учебное
пособие/ А.В. Каюмова. Казань. – Казанский федеральный университет, 2013. –
104 с.
32. Киреев Н.А. Практический анализ с моделированием на UML: методическое пособие / Н.А. Киреев. – Минск: WebMax, 2014. – 32 с.
33. Ковалев В.В. Анализ хозяйственной деятельности предприятия /
В.В. Ковалев. – М.: Проспект, 2015. – 424 с.
34. Козырев А.А. Информационные технологии в экономике и управлении: учебник / А.А. Козырев. – СПб: Издательство Михайлова В.А., 2014. –
290 с.
102
35. Кондратьев В.В. Моделируем и анализируем бизнес-процессы: навигатор для архитекторов бизнес-процессов: учебное пособие / В.В. Кондратьев. –
М.: ИНФРА-М, 2014. – 109 с.
36. Копылов И.А. Оценка эффективности отдела информационных технологий / И.А. Копылов // Актуальные экономические проблемы современного
общества, 2013. – № 8. – С. 171-172.
37. Костылева Н.В. Информационное обеспечение управленческой деятельности: учебное пособие / Н.В. Костылева, Ю.А. Мальцева, Д.В. Шкурин. –
Екатеринбург: Изд-во Урал. ун-та, 2016. – 148 с.
38. Купряева М.Н. Стратегический менеджмент: учебное пособие /
М.Н. Купряева, И.Н. Сотникова. – Кинель: РИЦ СГСХА, 2015. – 128 с.
39. Лапшин В.С. Методы и инструменты экономической идентификации
и анализа бизнес-процессов / В.С. Лапшин, Т.П. Шарашкина. ― Саранск:
Волжский университет имени В.Н. Татищева (институт), 2014. – 7 с.
40. Лещева М.Г. Особенности анализа в отдельных отраслях: учебник /
М.Г. Лещева, Т.Н. Стеклова. – Ставрополь: Ставропольский государственный
аграрный университет, 2014. – 176 с.
41. Литвак Б. Г. Экспертные технологии в управлении / Б. Г. Литвак. – М.:
Дело, 2015. – 670 с.
42. Люлякина Д.Н. Моделирование бизнес-процессов компании по производству окон как инструмент достижения стратегических целей с использованием balanced score card / Д.Н. Люлякина, А.Г. Лазуко // Модели, сети и системы в экономике, природе и обществе, 2015. – 64-71 с.
43. Маврина И.Н. Стратегический менеджмент: учебное пособие /
И.Н. Маврина. – Екатеринбург: УрФУ, 2014. – 132 с.
44. Манин К.В. Организация и управление IT-службой предприятия: выпускная квалификационная работа / К.В. Манин. – Екатеринбург: ФГБОУ ВО
«Уральский государственный педагогический университет», 2017. – 73 с.
45. Махметова А.Е. Ключевые направления моделирования бизнеспроцессов предприятий в контексте развития системы менеджмента качества /
103
А.Е Махметова // Евразийский союз ученых, 2015. – № 19. – С. 115-119.
46. Михеева Е.З. Процессный и функциональный подходы к управлению
современным предприятием / Е.З. Михеева // Актуальные вопросы менеджмента, 2015. – №1. – С. 50-56.
47. Муромцев Д.И. Разработка экспертных систем в Drools Guvnor: учебное пособие / Д.И. Муромцев, М.А. Колчин. – СПб: НИУ ИТМО, 2016. – 54 с.
48. Остроух А.В. Интеллектуальные системы / А.В. Остроух. – Красноярск: Научно-инновационный центр, 2015. – 110 с.
49. Пергунова О.В. Методические положения оценки эффективности отдела информационных технологий / О.В. Пергунова // Экономика и предпринимательство, 2014. – № 52. – С. 863-867.
50. Пирогова Е.В. Управление бизнес-процессами предприятия: учебное
пособие / Е.В. Пирогова. – Ульяновск: УлГТУ, 2017. – 107 с.
51. Попова Л.Ф. Влияние информационных технологий на формирование
устойчивого развития предприятия / Л.Ф, Попова // Вестник СГСЭУ, 2014. –
№1. – С. 73-77.
52. Представления знаний в интеллектуальных системах, экспертные системы.
–
2018.
–
[Электронный
ресурс].
–
Режим
доступа:
https://habr.com/post/346236.
53. Прыкина Л.В. Экономический анализ предприятия: учебник для бакалавров / Л.В. Прыкина. –М.: Издательский дом «Дашков и К», 2016. – 256 с.
54. Рассел С. Искусственный интеллект: современный подход: / С. Рассел,
П. Норвиг. – М.: Вильямс, 2015. – 1408 с.
55. Редько В.Н. Базы данных и информационные системы: учебное пособие / В.И. Редько, И.А. Басараб. – М.: Знание, 2016. – 478 с.
56. Ружанская Л.С. Теория организации: учебное пособие / Л.С. Ружанская, А.А. Яшин, Ю.В. Солдатова. – Екатеринбург: Издательство Уральского
университета, 2015. – 200 с.
57. Соколов М.Д. Экспертные системы / М.Д Соколов, Н. Ю. Носов // Современные научные исследования и инновации. – 2016. – [Электронный ре104
сурс].
URL:
http://web.snauka.ru/issues/2016/05/68338
(дата
обращения
–
19.05.2019).
58. Старцева Е.Б. Этапы построения модульной структуры базы знаний
экспертной системы на основе системного подхода / Е.Б. Старцева // Научные
сообщения, 2015. – № 2. – С. 178-181.
59. Стерлягов С.П. Совершенствование деятельности отдела информационных технологий налоговой инспекции на основе методологии ITSM/ITIL /
С.П. Стерлягов, Н.А. Безматерных // Интернет-журнал «Науковедение», 2017. –
№3. – С. 13.
60. Таунсенд К. Проектирование и программная реализация экспертных
систем на персональных ЭВМ: пер. с англ. / К. Таунсенд, Д. Фохт. – М.: Финансы и статистика, 2013. – 320 с.
61. Убейко Н. Экспертные системы: учебное пособие / Н. Убейко. – М.:
МАИ, 2016. – 480 с.
62. Уткин В.Г. Информационные системы в экономике: учебник для студ.
вузов / В.Г. Уткин, К.В. Балдин. – М.: Академия, 2017. – 288 с.
63. Частиков А.П. Разработка экспертных систем. Среда CLIPS BHV /
А.П. Частиков. – СПб: Знания России, 2014. – 606 с.
64. Чегодайкин А.Н. Статистическая оценка развития ИКТ (на примере
республики Мордовия) / А.Н. Чегодайкин // Статистические методы анализа
экономике и общества, 2018. – № 9. – С. 268-269.
65. Чекмарев А.В. Управление ИТ-проектами и процессами: учебное пособие / А.В. Чекмарев. – М.: Издательство Юрайт, 2018. – 228 с.
66. Чувашлова М.В. Информационно-аналитическое обеспечение принятия управленческих решений в контроллинге промышленных предприятий /
М.В. Чувашлова // Экономики и менеджмент организации, 2013. – № 8. –
С. 51-52.
67. Юрин А.М. Экспертные системы: учебно-методическое пособие /
А.М. Юрин. – Казань: Казан. ун-т, 2015. – 19 с.
68. Ясницкий Л.Н. Интеллектуальные системы: учебник / Л.Н. Ясницкий.
105
– М.: Лаборатория знаний, 2016. – 221 с.
69. Ясницкий Л.Н. Искусственный интеллект. Элективный курс: учебное
пособие / Л Н. Ясницкий. – М.: Бином, 2017. – 197 с.
70. Ясницкий Л.Н. Нейросетевая система оценки вероятности банкротства банков / Л.Н. Ясницкий, Д.В. Иванов, Е.В. Липатова // Бизнесинформатика, 2014. – № 47. – С. 49-56.
106
Отзывы:
Авторизуйтесь, чтобы оставить отзыв