CC BY
55Петербургский экономический журнал. 2022. № 1-2. С. 167-177. St. Petersburg Economic Journal. 2022. № 1-2. Р 167-177.
Научная статья УДК 007.3
DOI: 10.24412/2307-5368-2022-1-2-167-177
МОДЕЛИРОВАНИЕ ПРОЦЕССОВ РАЗРАБОТКИ И ВНЕДРЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ В ОРГАНИЗАЦИИ
MODELING OF DEVELOPMENT AND IMPLEMENTATION PROCESSES INFORMATION SYSTEMS IN ORGANIZATION
ИАлжанат Эльдеркадиевна МОСИЯШ (Сулейманкадиева)
доцент кафедры прикладной экономики института ИМПРОТЕХ Санкт-Петербургского государственного электротехнического университета («ЛЭТИ»), доктор экономических наук, доцент, saljanat@mail.ru
Alzhanat E. MOSIYASH (Suleimankadiyeva)
Associate Professor of the Department of Applied Economics of the IMPROTEСH Institute of St. Petersburg State Electrotechnical University (LETI), Doctor of Economics, Associate Professor, saljanat@mail.ru
Артем Владимирович КАШИРСКИЙ
аспирант кафедры прикладной экономики института ИМПРОТЕХ Санкт-Петербургского государственного электротехнического университета («ЛЭТИ»), artemk@mail.ru
Artem V. KASHIRSKY
post graduate student, Department of Applied Economics, IMPROTECH Institute, St. Petersburg State Electrotechnical University (LETI), artemk@mail.ru
Аннотация. В статье рассматривается процедура анализа существующей модели информационных систем и разработки новой более эффективной которая представляет собой поэтапную методику (последовательный алгоритм действий) включающий: процесс построения и анализа существующей модели (модели «как есть»); построение эффективной модели (то есть модели «как надо») и разработка регламента и формирование плана перехода к новой модели. Для проведения анализа эффективности существующих информационных систем и моделирования изменений используется методология структурного анализа и проектирования (методология SADT), которая включает совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы, часть которой официально опубликована в виде стандарта IDEF0.
Ключевые слова: моделирование процессов, информационная система, проект, методология SADT
© Мосияш (Сулейманкадиева) А. Э., Каширский А. В., 2022.
Abstract. The article discusses the procedure for analyzing the existing model of information systems and developing a new, more efficient one, which is a step-by-step methodology (sequential algorithm of actions) including: the process of building and analyzing an existing model (model "as is"); building an effective model (i.e., the "right" model) and developing regulations and forming a plan for the transition to a new model. To analyze the effectiveness of existing information systems and model changes, the methodology of structural analysis and design (SADT methodology) is used, which includes a set of methods, rules and procedures designed to build a functional model of the system, part of which is officially published as the IDEF0 standard.
Key words: process modeling, information system, project, SADT methodology
Введение. В условиях современной экономики моделирование процессов разработки и внедрения информационных систем (ИС) нашло самое широкое применения в таких сферах деятельности, как наука, образование, реальный сектор экономики (бизнес), сфера услуг и т. д. И это связано, прежде всего, с интенсивным развитием цифровых технологий и их глубоким проникновением в жизнь современного общества. С другой стороны, данная проблема приобрела наиболее острый характер в условиях санкционной политики Запада, когда общая социально-политическая и экономическая обстановка обосновала объективную необходимость оптимизации процессов моделирования и внедрения отечественных эффективных информационных систем.
Предметом исследования являются процессы формирования и внедрения информационных систем в организациях, как реального сектора экономики, так и сферы услуг, что и предопределяет актуальность вопросов, связанных с оптимизацией бизнес-процессов и их регламентацией для разработки ИС российской организации, функционирующей в бизнес-среде и сфере услуг. Существующие ограничения (финансовые, трудовые, временные и организационные) обосновывают объективную целесообразность применения принципов эффективного проектного управления процессами создания и внедрения ИС в системе банковских услуг [1-9]. В связи с этим в данной статье ставится цель построения эффективной модели ИС бизнес-процессов
банка и осуществления перехода к ней (к ее реализации).
Анализ и моделирование процессов разработки и внедрения ИС. Процедура анализа существующей модели ИС и создания новой более эффективной являет собой поэтапную методику, представляющую последовательный алгоритм действий: 1. Процесс построения и анализа существующей модели (модели «как есть»); 2. Построение эффективной модели (то есть модели «как надо») и 3. Разработка регламента и формирование плана перехода к новой модели [5]. Обобщенная поэтапная модель оптимизации ИС выглядит следующим образом (рисунок 1).
Для проведения анализа эффективности существующих ИС и моделирования изменений целесообразно воспользоваться методологией структурного анализа и проектирования (Structured Analysis and Design Technique), которую кратко называют методологией SADT. Она представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы [1], часть которой официально опубликована в виде стандарта IDEF0 (IcamDEFinition), используемого в методике оптимизации [7]. Данный стандарт, с одной стороны, целесообразно применять на ранних этапах разработки ИС; с другой, - он может быть использован для анализа функций существующих систем и выработки решений по их улучшению (оптимизации). В построении диаграммы кроме прямоугольников и стрелок, которые позволяют любому не профессионалу читать и понимать
Рисунок 1 - Методика построения эффективной модели ИС Figure 1 - Methodology for building an effective IP model
диаграмму, не используется никаких других графических элементов. Она строится в виде последовательной иерархии в порядке углубления и детализации, то есть декомпозиции процессов.
На первом этапе определяются все виды (системы) управления, механизмы и вызовы, которых можно встретить в данном проекте (процессе), а также определяются его входы и выходы. Эта диаграмма называется диаграммой нулевого уровня (рисунок 2).
После определения диаграммы нулевого уровня как исходного этапа производится первая декомпозиция на три-восемь фаз процесса, в каждой из которых фиксируются управление, механизмы и вызовы, определенные в диаграмме ранее, моделируются взаимные внутренние входы и выходы. Так получают диаграмму декомпозиции первого уровня (рисунок 3).
Далее в полученной диаграмме проводится дальнейшая декомпозиция каждой из ее фаз
Рисунок 2 - Диаграмма нулевого уровня Figure 2 - Zero level diagram
Рисунок 3 - Диаграмма декомпозиции первого уровня Figure 3 - Decomposition diagram of the first level
по выше описанным правилам. Так получают набор диаграмм второго уровня.
Процесс дальнейшей декомпозиции и построения диаграмм высших уровней не имеет теоретических ограничений, но фактически он останавливается в момент, когда каждая рассматриваемая отдельная фаза представляется законченной для проводимого анализа, и более глубокая детализация уже является бессмысленной. В качестве дополнения к спецификации могут быть использованы блок-схемы алгоритмов. Процесс функционального моделирования заключается в постепенном выстраивании иерархии функций [1].
Далее определяются все участники проекта, то есть определяются основные механизмы проекта: инициатор (И) - подразделение или сотрудник, который выступает заказчиком разработки или внесения изменений в информационную систему (им может быть любой из нижеперечисленных); проектный офис; управление разработки; менеджер проекта; бизнес-офис; технический директор; управление эксплуатации; служба главного бухгалтера; юридическая служба (в том числе служба
управления Рисками и Внутреннего аудита); председатель правления.
В качестве входа (входного элемента) проекта может быть принята заявка от инициатора на разработку (изменение) информационной системы [3-5]. А выходом (выходными данными) могут выступать: разработанная и введённая в эксплуатацию информационная система; инструкции по сопровождению и использованию системы; отказ от ее разработки и введения в эксплуатацию (как альтернативный вариант).
Система управления (то есть система регламентирующих и управляющих факторов) включает: регуляторную базу (Законы РФ, Положения и указания ЦБ РФ, подзаконные нормативные отраслевые акты); внутреннюю учетную политику. Никакие действия за пределами проекта не рассматриваются, поэтому вызовов нет.
Таким образом, в результате анализа текущих процессов появляется возможность построения модели ГОЕБО действующих процессов в проекте. Попытка проведения дальнейшей декомпозиции модели при анализе
существующих процессов (которая включает три фазы и проводится на один уровень ниже), демонстрирует бессмысленность проведения дальнейшей декомпозиции (рисунок 3) [1; 7].
Во всех процессах проекта в качестве механизмов задействованы все участники, кроме того, в проекте имеет место достаточно большое количество обратных связей промежду фазами. Следует отметить, что два макропроцесса не имеют управляющих входов, что свидетельствует о неуправляемости всей деятельности. Результаты каждой из фаз представляются сильно размытыми, что делает очевидными такие негативные явления, как: низкая прозрачность и недостаточная управляемость процессов.
Следовательно, можно сделать вывод о целесообразности как пересмотра проектной работы по разработке ИС в организации, так и перестройки и моделирования всех процессов [6-8].
Построение новой модели процессов. Первичная декомпозиция. Процесс перестройки процессов начинается с исключения из первого уровня декомпозиции «паразитного влияния» механизмов (участников), которые: нарушают процесс исполнения фазы, добавляют неопределенность и/или берут на себя роль управления вместо роли механизма, что, в конечном счете, ведет к дезорганизации структуры.
В качестве управляющих входов может выступать обеспечение организации ясной внутренней нормативной и правовой базой (то есть регламентными и шаблонными документами). Для повышения прозрачности реализации проекта, целесообразно создание соответствующей информационной среды для всех участников с целью обеспечения эффективного контроля за выполнением планов. Такой подход позволяет исключить рекурсивные связи между фазами.
В процессах моделирования ИС целесообразно полностью исключить влияние проектного менеджера на процессы, освободить его от функциональной нагрузки, сохранив за ним сервисную услугу, то есть его роль необходимо свести только к участию в планировании ресурсов и к осуществлению контроля
за соблюдением прозрачности процесса, а технологический процесс разработки ИС должен регулироваться другими механизмами. Кроме того, рекомендуется инициатора больше не рассматривать как механизм воздействия, сохранив роль остальных участников (механизмов) без изменения.
На данном этапе рассматриваемый процесс создания новых ИС предлагается разделить на три логические и последовательные фазы, позволяющие более качественно распределить механизмы воздействия, системы управления и взаимосвязи. В результате таких перестроек можно получить новую схему, показанную на рисунке 4.
Получившаяся декомпозиция фазы первого уровня подлежит более глубокому анализу и предлагаемой новой декомпозиции.
Декомпозиция фазы «Формулирование и согласование»
Данную фазу декомпозируем и выделяем три последовательные подфазы: «Формулирование бизнес требований»; «Согласование бизнес требований»; «Формирование технического задания».
1.«Формулирование бизнес требований» в данном списке является первой фазой, которая позволяет определить границы проекта и его суть.
Входом этой фазы являются: заявка от инициатора и требование на корректировку бизнес требований. Управлением фазы выступает шаблон бизнес-требования, а механизмами: бизнес офис, проектный офис. Выходами фазы выступают два взаимоисключающих варианта: бизнес-требование и отказ в разработке. При этом в данной фазе какие-либо другие механизмы намеренно не участвуют.
Таким образом, на данном этапе (фазе), с минимально задействованными механизмами возможно прекращение дальнейших необоснованных действий, так как результат позволяет существенно сократить неоправданное потребление ресурсов в процессе реализации проекта.
2. «Согласование бизнес требовании». На этом этапе бизнес требование проходит техническую, юридическую и бухгалтерскую экспертизу, по результатам которых председатель
Рисунок 4 - Новая модель ИС Figure 4 - New IP model
правления может либо согласовать возможные риски, либо потребовать их снижения посредством переработки бизнес требований, или отказать в реализации.
Входом этой фазы является бизнес-требование, а управлением этой выступают: регуляторная база и внутренняя учетная политика. Механизмами фазы являются: технический директор, председатель правления, служба главного бухгалтера и юридическая служба. Выходом фазы являются взаимоисключающие варианты: согласованное бизнес требование, отказ в разработке, рекомендация корректировки бизнес требований.
На данной фазе также возможно прекращение дальнейших необоснованных действий за счет минимизации влияния различных участвующих механизмов на процессы.
3. «Формирование технического задания». Данный этап является уже финальной частью согласования проекта до перехода его в активную фазу разработки.
Входом этой фазы выступает согласованное бизнес-требование; управлением является шаблон технического задания; механизмами
фазы является проектный офис, а выходом -техническое задание.
В результате реализации таких мероприятий по перестройке процессов создания и внедрения ИС в организацию можно получить жестко типизированный процесс, не требующий лишних механизмов.
В такой модели каждая фаза потребляет минимальное количество ресурсов в виде механизмов и имеет достаточно определенную (предсказуемую) систему управления.
В результате декомпозиции фазы «Формулирование и согласование» можно получить схему процесса моделирования ИС (рисунок 5).
Декомпозиция фазы «Разработка»
Важным отличием данной фазы от предыдущей является то, что она не имеет негативных выходов. Здесь можно выполнить декомпозицию до получения трех последовательных подфаз: «Анализ технического задания (ТЗ) и определение программно-аппаратного стека»; «Разработка модулей программного обеспечения и баз данных (ПО и БД)» и «Тестирование».
Рисунок 5 - Модель ИС, полученная в результате декомпозиции фазы «Формулирование
и согласование» Figure 5 - The IC model obtained as a result of the decomposition of the «Formulation and coordination» phase
Итак, целесообразно рассмотреть более подробно все выделенные подфазы.
1. «Анализ ТЗ и определение программно-аппаратного стека». На данном этапе экспертами проводится докомпозиция ТЗ на разработку ИС декомпозируется до отдельных юнитов, для каждого из которых выбирается программно-аппаратный стек, наиболее подходящий для решения задач, поставленных в ТЗ. Важное отличие от многих других фаз заключается в том, что данный этап не имеет управления и ограничивается исключительно экспертизой самих механизмов проекта.
Следует отметить, что входом этой фазы является техническое задание; управлением выступает внутренняя экспертиза механизмов (так как внешнего управления нет); к механизмам относятся: проектный офис, технического директора и управление разработки. Выходом фазы является декомпозированное ТЗ.
2. «Разработка модулей ПО и БД» является основным этапом разработки информационной системы, поскольку представляется наиболее ресурсоемким и продолжительным
во времени. Именно здесь происходит подготовка предварительного продукта всего проекта - разработанной, но еще не внедренной ИС. Кроме того, на этой подфазе подготавливается управляющий документ для следующей фазы - Инструкция по развертыванию информационной системы.
Входом этой фазы являются декомпозированное техническое задание и результаты тестов; управлением являются регламент по работе с БУЫ и шаблон инструкции по развертыванию, а механизмами выступает управление разработки, а выходом - разработанная информационная система, инструкция по развертыванию и предварительные результаты для тестирования.
3. «Тестирование». Данная фаза намеренно выделена в отдельную, хотя выполняется параллельно с описанной в предыдущем пункте и связана с ней непосредственно. Данная фаза выделена в отдельную в стратегическом плане. Так как организация планирует выделить для нее отдельный механизм - отдел тестирования.
Рисунок 6 - Модель ИС, полученная в результате декомпозиции фазы «Разработка» Figure 6 - The IC model obtained as a result of the decomposition of the «Development» phase
Входом этой фазы является предварительные результаты для тестирования; управлением этой фазы является внутренняя экспертиза отдела тестирования; механизмом фазы выступает управление разработки (при отсутствия в организации отдела тестирования). Выходом фазы являются результаты тестов.
В результате декомпозиции всей фазы «Разработка» можно получить схему процесса, показанную на рисунке 6.
Декомпозиция фазы «Ввод в эксплуатацию»
Данную фазу можно декомпозировать до уровня, когда выделяются следующие последовательные подфазы: «Предварительное развертывание»; «Рабочее тестирование»; «Доработки и устранение замечаний»; «Создание сопроводительной документации»; «Рабочее развертывание»; «Публикация».
На этой фазе к процессу возвращается бизнес-офис и подключается управление эксплуатации.
1. «Предварительное развертывание» представляет собой фазу, которая подготавливает ИС к предварительному тестированию на реальных или специально подготовленных данных, чтобы выявить максимально возможное количество недочетов перед итоговым промышленным развертыванием.
Входом этой фазы является разработанная ИС; управлением этой фазы выступает инструкция по развертывания информационной системы; механизмами фазы можно считать системы управления эксплуатации и выходом фазы является предварительно развернутая ИС.
2. «Рабочее тестирование». Данная фаза подготавливает ИС к пилотному тестированию [9]. Входом этой фазы являются предварительно развернутая ИС и доработки ИС. Управлением выступает внутренняя экспертиза управления эксплуатации (внешнего управления нет); механизмами этой фазы является: управление эксплуатации; выходом являются результаты тестирования.
3. «Доработки и устранение замечаний» - это мини фаза разработки. Любое тестирование на этапе самой разработки не может выявить все возможные недочеты. Согласно многолетнему опыту, большинство ошибок находится именно при тестировании на предварительном старте (пилоте) или тестировании на рабочих данных. Поэтому по результатам такого тестирования управление разработки почти в 100%-ном случаем получает негативные результаты рабочих тестов и устраняет большинство выявленных проблем.
Входом этой фазы являются результаты тестов (только негативные); управлением выступает регламент по работе с 8УЫ; механизмами этой фазы является управление разработки и выходом фазы рассматривается разработанная и исправленная ИС.
4. «Рабочее развертывание». Эта фаза развертывает информационную систему уже для использования в промышленном масштабе. Входом фазы выступает разработанная и исправленная ИС; управлением является инструкция по развертывания информационной системы; механизмами фазы является управление эксплуатации и выходом выступает готовая к публикации ИС.
5. «Создание сопроводительной документации» представляет собой одну из важнейших фаз, так как ИС в обязательном порядке требует соответствующей организации сопроводительной документации, обеспечивающей эффективную внутреннюю экспертизу проекта.
Входом этой фазы является разработанная и исправленная ИС; управлением фазы выступают инструкция по развертывания информационной системы; шаблон пользовательской инструкции; шаблон инструкции по эксплуатации и настройке ИС; механизмами фазы выступает проектный офис; выходом являются пользовательская инструкция и
инструкция по эксплуатации и настройке ИС.
6. «Публикация» является финальной фазой и включает прием развернутой ИС в промышленную эксплуатацию. Входом этой фазы является промышленно развернутая ИС; управлением фазы являются инструкция по эксплуатации и настройке ИС и пользовательская инструкция; механизмами этой фазы выступают управление эксплуатации; бизнес офис; технический директор; выходом фазы является готовая к эксплуатации ИС.
В результате декомпозиции всей фазы «Ввод в эксплуатацию» можно получить схему процесса, показанную на рисунке 7.
Регламент. Таким образом, выше был нами смоделирован и оптимизирован процесс создания ИС до степени, превращающей проектную деятельность в повторяемую и процессную, следовательно, имеющую значительно низкую внутреннюю неопределенность.
Для того, чтобы организовать эффективный процесс разработки новой модели ИС, необходимо создать и принять официальный документ, в котором конкретно описана последовательность выполнения бизнес-процессов, распределена ответственность и определен порядок взаимодействия участников бизнес-процессов. Такой документ называется регламентом.
Рисунок 7 - Модель ИС, полученная в результате декомпозиции фазы «Ввод в эксплуатацию» Figure 7 - The IC model obtained as a result of the decomposition of the «Commissioning» phase
В регламенте текстовыми описаниями детально фиксируются все этапы процессов, описываются участники и регламентирующие их работу сторонние документы. Так же предлагается соответствующие изменения во внутренних положениях задействованных подразделений и должностных инструкциях сотрудников.
Регламент согласовывается со всеми участниками процесса, по ходу согласования которого могут быть внесены мотивированные изменения, но после его принятия и утверждения приказом руководителя организации он становится уже обязательным для исполнения.
Контроль за исполнением регламента возлагается на службу внутреннего контроля и на основных заинтересованных участников процесса. На примере нашей модели такая ответственность возлагается на технического директора и руководителей управлений разработки и эксплуатации.
Любой регламент не является неизменяемой догмой. В процессе его следования постоянно проводится аудит процессов, в случае необходимости в регламент вносятся соответствующие дополнения и изменения.
Заключение. В процессе выполнения исследования авторами данной статьи были получены результаты, которые можно кратко резюмировать в виде следующих выводов и обобщений.
1. В исследовании была проведена большая работа по диагностике и построению существующей модели ИС на примере организации, оказывающей банковские услуги,
! Список источников
на основе метода БЛБТ и определено, что она сопряжена высокой степенью неэффективности, большой функциональной нагрузкой на механизмы управления, несогласованность большого количества входов, выходов, механизмов (участников процессов), которые наглядно продемонстрировали несостоятельность существующей ИС в организации.
2. В процессе исследования выявлено, что очень важно правильно определить внутреннюю среду проекта по разработке ИС, определить среду, выявить ее недостатки, и создать новую среду для превращения проекта в стандартизованный повторяющийся процесс.
3. Достаточно важным параметром при управлении внутренней средой проекта является выбор структуры управления, так как любая структура имеет свои особенности построения, преимущества и функциональные недостатки. Проектную структуру необходимо использовать при масштабных проектах, большом количестве участников и определенной сложности работы.
4. Углубление декомпозиции и типизация разработки ИС переводит моделирование ИС из плоскости проектной деятельности в процессную, которая отличается высоким уровнем прозрачности разработки, то есть выполнение типизируемых процессов обосновывает целесообразность формализации и превращение всей работы в прозрачную процессную деятельность. Для чего эти процессы должны быть описаны и формализованы в обязательном для исполнения регламенте.
: 1. Анисимов А. А. Методология IDEF0. URL: https://sites.google.com/site/anisimovkhv/
• learning/pris/lecture/tema6/tema6_2 (дата обращения 15.06.2022).
| 2. Банковские информационные системы и технологии: учебник / В. Е. Косарев, : Я. Л. Гобарева, С. Л. Добриднюк [и др.] ; под ред. О. И. Лаврушина, В. И. Соловьева. | М.: КноРус, 2021. 527 с. URL:https://book.ru/book/941842 (дата обращения: 19.06.2022). | 3. Воропаев В. И. Управление проектами в России: Основные понятия. История. До: стижения. Перспективы, М.: АЛАНС, 1995.
• 4. Вoрoпaeв В. И. Упрaвлeниe прoeктoм. Moc^a: Альянс, 2010.
: 5. Данелян Т. Я. Информационные системы и информационные технологии в бизнес-
• процессах: учебно-практическое пособие / Т. Я. Данелян, И. А. Бакай. М.: Русайнс, : 2022. 179 с. URL:https://book.ru/book/944016 (дата обращения: 19.06.2022).
: 6. Лыскова И. Е. Управление проектами: учебник / И. Е. Лыскова, О. С. Рудакова. М.: : КноРус, 2022. 188 с. URL:https://book.ru/book/942136 (дата обращения: 19.06.2022). : 7. Марка Д. А. и МакГоуэн К. Методология структурного анализа и проектирования | SADT, М.: МетаТехнология, 1993.
j 8. Морозова О. А. Информационные системы управления портфелями и программа: ми проектов: учебное пособие / О.А. Морозова. М.: КноРус, 2021. 266 с. URL:https:// • book.ru/book/936552 (дата обращения: 19.06.2022).
: 9. Управление проектами в области информационных технологий: учебное пособие / : И. В. Трифонов, Н. Н. Трифонова, Н. А. Череповская [и др.]; под ред. А. В. Лукьяновой. М.: КноРус, 2022. 235 с. URL: https://book.ru/book/942673 (дата обращения: 19.06.2022).
Статья поступила в редакцию 19.06.2022; одобрена после рецензирования 22.06.2022; принята к публикации 30.06.2022.
The article was submitted 19.06.2022; approved after reviewing 22.06.2022; accepted for publication 30.06.2022.
