SIMULATION MODELING BUSINESS PROCESS OF DEVELOPMENT AND CUSTOMIZATION OF INTEGRATION DECISIONS IN THE INTERESTS OF IT-COMPANY MANAGEMENT

Full Text

Введение Для современного бизнеса умение сотрудников работать в команде приобретает очень большое значение. Команда, работающая слаженно, продвигает компанию вперед, в то время как плохо функционирующая команда препятствует развитию компании. По сравнению с административным управлением, командный метод работы является более эффективным. Однако переход на него - процесс нелегкий, он требует перестройки мышления, поведения и способов принятия решений. Особенно остро вопросы командообразования и командоуправления стоят в сфере информационных технологий (ИТ), где имеет место высокая степень неопределенности в постановках задач от бизнес-заказчиков - лиц, принимающих решения (ЛПР) [1]. Целью исследования является совершенствование деятельности ИТ-компании путем повышения качества принимаемых управленческих решений при формировании команд, разрабатывающих интеграционных решения, на основе результатов статистического имитационного моделирования (СИМ) по методу Димова-Маслова (МДМ). В качестве объекта исследования рассматривается ИТ-компания системный интегратор. Предмет исследования - процесс формирования команды, реализующей разработку и кастомизацию интеграционных решений. Кастомизация (customization) - это адаптация массового продукта под запросы конкретного бизнес-заказчика путем частичного изменения продукции под конкретный запрос. Термин происходит от английского customer - клиент, потребитель. Статья посвящена важнейшему этапу СИМ по МДМ - постановке задачи моделирования исследуемого бизнес-процесса в интересах управления им. Данный этап содержит вербальное описание процесса работы системы управления с включением СИМ-модели в контур управления вместе с ЛПР-оператором для оперативного поиска и реализации воздействий, управляющих социально-экономической системой с целью обеспечения наивысшей эффективности ее функционирования в каждый текущий период времени. Описание объекта исследования Основные бизнес-процессы ИТ-компании представлены на рисунке 1. Такие компании разрабатывают и реализовывают собственные консалтинговые решения с одновременной интеграцией электронных приложений в рабочие процессы. Этим они отличаются от компаний, представляющих и продвигающих на ИТ рынке лишь какой-то определенный комплекс программного обеспечения, целенаправленно поставляя под него оборудование, или оказывая услуги по его установке и наладке. Системный интегратор предлагает комплексное решение под конкретного заказчика, которое начинается с разработки ИТ-стратегии, построения инфраструктуры, внедрения прикладных компьютерных систем и приложений, а заканчивается автоматизацией и обслуживанием рабочего процесса. Такая компания специалистов объединяет работу программистов и оптимизаторов, решает уникальные инженерные и маркетинговые задачи [2]. Рисунок 1. Карта основных бизнес-процессов ИТ-компании Специфика предметной области Воплощение в жизнь принимаемых управленческих решений зачастую требует оперативного изменения бизнес-процессов, для чего необходимо резко повысить степень гибкости и адаптивности имеющихся корпоративных информационных систем, поддерживающих бизнес-процессы. Без внедрения современных аналитических и интеграционных решений это невозможно. Интеграционные решения являются технологическим фундаментом для цифровой трансформации. Традиционные архитектурные подходы и стили решений на базе замкнутых коммерческих или заказных систем поддержки отдельных направлений деятельности не были ориентированы на эффективную реализацию сквозных интегрированных бизнес-процессов, которые должны опираться на функциональные сервисы множества корпоративных информационных систем компании, ее подразделений, филиалов и внешних контрагентов. Многие компании видят выход в том, чтобы переориентировать деятельность и ее информационно-технологическую поддержку на управляемую бизнес-требованиями сервис-ориентированную архитектуру (Service-Oriented ArchИТecture, далее SOA), предложенную компанией IBM [3]. Согласно [4], SOA - это «архитектурный стиль для создания ИТ-архитектуры предприятия, использующий принципы ориентации на сервисы для достижения тесной связи между бизнесом и поддерживающими его информационными системами». Архитектурный подход SOA поддерживают практически все мировые лидеры ИТ-индустрии. Интерес к использованию SOA во многом определяется наличием в компаниях мощной системы средств автоматизации, оперативную модернизацию которой проводить становится все сложнее и сложнее. Рисунок 2. Интеграция через ESB Сервисы - это базовые компоненты архитектуры, которые представляют видимый ресурс, выполняющий повторяющуюся задачу и описанный внешней инструкцией. Сервисы позволяют вызывать функциональность из других приложений и подсистем. Интеграционная сервисная шина предприятия ESB, (аббревиатура Enterprise Service Bus) играет роль транспорта для сервисов и служит для формирования единой среды взаимодействия различных приложений предприятия. АС-инициатор (сервис или модульное приложение) отправляет запрос на сервисную шину, которая преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет запрос АС-получателю. АС-получатель обрабатывает полученный запрос и возвращает ответ в сервисную шину, которая преобразует сообщение в формат отправителя (см. рисунок 2). Все взаимодействие идет через сервисную шину, так что если она падает, то с ней падают и все остальные системы. Другими словами, ESB является ключевым посредником и достаточно сложным компонентом системы [5]. Рисунок 3. Схема бизнес-процесса разработки и кастомизации интеграционного решения Анализ бизнес-процесса разработки и кастомизации интеграционных решений в интересах управления Формализованная модель бизнес-процесс разработки и кастомизации интеграционных решений (см. рисунок 1) в нотации блок-схема представлена на рисунке 3. Бизнес-процесс начинается с поступления в отдел интеграции АС заявки на разработку интеграционного решения. Получив заявку, владелец АС распределяет задачу на проведение аналитики. Аналитик разрабатывает документ «Спецификация требований к АС». В документе фиксируется перечень необходимых к выполнению работ: разработка, доработка или использование сервиса (сервисов). Рисунок 3 (продолжение) В процессе подготовки спецификации требований к АС аналитик опирается на информацию, описанную в бизнес-требованиях и концептуальной архитектуре. В случае отсутствия этих документов или неполноты информации в них - аналитик консультируется непосредственно с ИТ аналитиком, бизнес-аналитиком, ИТ архитектором, руководителем проекта. Также аналитик сервиса выстраивает коммуникации с аналитиками смежных АС. Смежные АС являются поставщиками и потребителями разрабатываемого сервиса. В случае если информации недостаточно, то аналитик останавливает задачу до момента предоставления информации и берет в работку новую задачу. Рисунок 3. (продолжение) Рисунок 3 (продолжение) Если информации достаточно для функционального проектирования сервиса, аналитик фиксирует информацию о назначении сервиса в спецификации требований к АС. Кроме документа аналитик готовит схему данных сервиса, с помощью которой АС-поставщик сможет корректно сформировать сообщения, которые затем будут приняты и прочитаны сервисом для последующего выполнения инструкций, заложенных в сообщении, как правило, - это передача данных АС-потребителю. После подготовки спецификации требований к АС аналитик сервиса последовательно согласовывает документ со всеми заинтересованными лицами: руководителем разработки, смежными АС, отделом тестирования. Рисунок 3 (продолжение) В первую очередь требования должны быть согласованы со стороны руководителя разработки. Если у руководителя разработки имеются замечания, то документ возвращается аналитику сервиса. Аналитик сервиса фиксирует протокол замечаний и приступает к их устранению. Если подготовленное аналитиком решение возможно к реализации, то руководитель разработки согласовывает спецификацию требований. После успешного согласования с руководителем разработки спецификация требований должна быть согласована со смежными АС, которые будут использовать разрабатываемый сервис. Далее спецификация требований согласовывается с отделом интеграционного тестирования. Рисунок 3 (окончание) В случае успешного согласования отдел интеграционного тестирования включает задачу в свой перечень работ и ожидает выпуск дистрибутива на стенд тестирования. После согласования спецификации требований к АС со всеми заинтересованными лицами начинается этап программной разработки интеграционного решения. Для этого аналитик делает запрос руководителю разработки на назначение разработчика. Руководитель выбирает разработчика и назначает задачу. Разработчик получает задачу, проверяет наличие входных артефактов, как правило, это спецификация требований к АС, но в отдельных случаях может понадобиться информация технического характера от разработчиков смежных АС. Разработчик вносит необходимые изменения в исходный код. Результатом выполнения задачи является Pull Request - запрос к руководителю разработки, управляющему репозиторием, на выполнение изменений из репозитория разработчика. Далее Pull Request подвергается проверке исходного кода программы с целью обнаружения и исправления ошибок, которые остались незамеченными в начальной фазе разработки. Целью просмотра является улучшение качества программного продукта и совершенствование навыков разработчика. Данная процедура проверки кода называется Code Review. Проверку исходного кода может проводить сам руководитель разработки или он может делегировать проверку другому разработчику. После устранения всех замечаний (при их наличии) разработчик передает Pull Request руководителю разработки для включения его в основной код. Следующий этап предусматривает проведение тестирования. Первый этап тестирования называется модульным и проводится каждой АС (АС 1, АС 2, АС интегратором) независимо друг от друга. Успешное прохождение модульного тестирования всеми участниками интеграционного решения является стартом для подготовки работ к интеграционному функциональному тестированию (ИФТ), при котором отдельные программные модули объединяются и тестируются в группе. В качестве входных данных используются модули, над которыми было проведено модульное тестирование. Если в ходе тестирования были выявлены ошибки, инженер по тестированию заводит дефект на АС, которая является причиной дефекта. Результатом успешного завершения ИФТ является работоспособное интеграционное решение, что подтверждает протокол ИФТ, подготовленный инженером по тестированию. Протокол ИФТ также является документом, обеспечивающим начало приемо-сдаточных испытаний (ПСИ). Если в ходе ПСИ у комиссии возникают замечания функционального или программного характера относительно разработанного решения, то все указанные замечания фиксируются в протоколе ПСИ и прикладываются к заявке. Далее инициатор заявки, как правило, руководитель проекта закрывает заявку окончательно или с возможностью доработки. В случае успешного прохождения ПСИ в протоколе фиксируется рекомендации к внедрению решения в промышленную эксплуатацию. Этапы ПСИ и внедрения находятся за рамками исследуемого бизнес-процесса, и рассмотрены только в качестве логического понимания завершения работ над заявкой. Постановка задачи СИМ В конкурентной борьбе ИТ-компании соревнуются не только за долю на рынке, но и за инвестиции и персонал. Для получения конкурентных преимуществ ИТ-компании вынуждены трансформировать бизнес. Трансформация подразумевает переход компании с одного типа управления ИТ-проектами на другой. Для цифровой трансформации характерен переход на гибкие методологии в управлении ИТ-проектами, ориентированные на организацию работ небольшими командами. Процесс формирования команды - задание, требующее высокой управленческой компетенции. При его осуществлении требуется не только наличие правильно подобранных, высококвалифицированных ИТ-специалистов, но и людей, желающих работать вместе, сообща, как команда [1]. Определений «команды» существует несколько десятков, например, М. Армстронг приводит следующее определение: «Команда - это небольшая группа людей, взаимодополняющих и взаимозаменяющих друг друга, которые собраны для совместного решения задач производительности и в соответствии с подходами, посредством которых они поддерживают взаимную ответственность» [6]. Применительно к сфере ИТ под командой понимают кросс-функциональную группу в 5-10 чел., которая наделена полномочиями и способна определить, разработать и протестировать инкремент ценности решения за обозначенный временной интервал. Включает следующие роли: команда разработки (аналитики, разработчики, тестировщики), Scrum-мастер и владелец продукта. В своем развитии команды проходят несколько этапов, которые сменяют друг друга (см. таблицу 1). На этапе формирования команда не определяет свой состав сама, она формируется сверху, от руководства. Фактическую производительность команды можно оценить только на этапе функционирования команды. Получить прогнозные значения производительности команды возможно, если на этапе формирования команд ЛПР будет иметь данные о результатах того или иного распределения исполнителей по командам. У каждого участника команды есть две роли: функциональная и командная. Функциональные роли относятся к должностным обязанностям и охватывают навыки, умения, знания и опыт. Командные роли отражают личностные качества, которые являются устойчивой характеристикой сотрудника и остаются неизменными в разных командах. Таблица 1. Этапы формирования команд Этап Описание этапа Формирование На этапе формирования происходит создание команды и постановка целей, распределение и закрепление функциональных ролей. Бурление На этапе «бурления» участники осознают цели. Здесь возможны конфликты и противостояние между членами команды. Нормализация На этапе нормализации члены команды «притираются» друг к другу и начинают двигаться сонаправлено. Функционирование На этапе функционирования команда становится самоуправляемой и способной оптимизировать свою производительность. Расформирование Этап расформирования наступает, когда цели, поставленные перед командой достигнуты. Рекомендации по распределению командных ролей описывают качества, которыми должна обладать сформированная команда, однако вопросам распределения сотрудников на команды по функциональным ролям уделено недостаточно внимания [6-8]. Оценку производительности команды, риск срыва сроков разработки и внедрения невозможно рассчитать по аналитическим моделям, поскольку на эти показатели влияют несколько факторов, среди которых есть стохастические. Например, количество поступивших заявок на релиз, длительность подготовки требований, длительность согласования требований, длительность разработки, вероятность обнаружения дефекта при тестировании, длительность исправления дефекта в документации, длительность исправления дефекта в коде и др. В гибких командах работа ведется параллельно: контроль и «власть» распределены между командами. Решения, из которых складывается конечный результат, принимаются каждой командой отдельно, разделяя ответственность, но, не размывая ответственность, между всеми командами. Распараллеливание процедур сбора и обработки информации приводит к децентрализации процедур принятия решений, то есть к созданию самостоятельно функционирующих подсистем, что означает появление в системе иерархической структуры. Для управления социально-экономической системой, обладающей иерархической структурой необходимо рассмотреть исследуемый бизнес-процесс разработки и кастомизации интеграционных решений как систему нерефлекторного типа. Нерефлекторная система - это система, которая может неоднозначно, многовариантно реагировать на одно и то же внешнее воздействие. Управление в таких системах связано с наличием человеческого фактора, что значительно усложняет процесс управления. Рассмотрим пример нерефлекторной системы [9-10]. Имеется объединение N промышленных предприятий (концерн или трест), выпускающих однотипную продукцию. Назовем такое объединение центром. Обозначим через Pi продукцию, выпускаемую i-ым предприятием из общего их числа n, то есть i [1; n]. Результат функционирования центра определяется результатами функционирования отдельных производителей. Оценки этого результата могут быть различными. Центр также производит продукцию, и его целевая функция однозначно определяется продукцией производителей J = J (P1 ; P2 ; P3… Pn) (1) Центр не имеет права назначать объемы производства Pi, но может влиять на эти объемы. Величина продукта, произведенного i-ым производителем, определяется объемом его фондов xi и количеством рабочей силы Li: Pi = fi (xi ; Li). (2) Функция fi (xi; Li) в теории управления именуется производственной функцией. Существуют различные способы аппроксимации производственной функции. Доход i-го производителя Ji равен стоимости произведенной продукции за вычетом накладных расходов. Для простоты будем считать, что накладные расходы состоят только в оплате рабочей силы. Если обозначить через ωi фиксированную ставку заработной платы, то каждая величина Ji будет равна Ji = с Pi - ωi Li (3) Если величина фондов xi также фиксирована, то объем продукции определяется количеством рабочей силы Li . Таким образом, Li является управляющим параметром, который полностью находится в распоряжении производителя. Для того чтобы управлять действиями производителей, центр должен располагать способами эффективного воздействия на них. Рассмотрим простейший способ: распределение экзогенного ресурса U, который полностью находится в распоряжении центра и может расходоваться, например, на инвестиции, на создание основных фондов производителя и т.п. Тогда задача центра, которую можно назвать задачей планирования, состоит в таком распределении ресурса U, которое приводит к максимуму функцию (1): . (4) При этом эффективность распределения U будет зависеть не только от действий центра, но и от значений Li, которые выбираются производителями. Таким образом, складывается игровая ситуация, в которой, по определению Ю.Б. Гермейера, имеется N + 1 игроков: N производителей и центр [11]. Для того чтобы эффективно реализовать процедуру управления, игрокам необходимо условиться о «порядке ходов», «гипотезе информированности» и «гипотезе поведения». В данной игровой ситуации право первого хода принадлежит центру - который делает этот ход, передавая i-му производителю ресурс ui и учитывает, что производитель с этого момента знает величину ui. Основным теперь становится вопрос о гипотезе поведения игроков: предположим, что центр знает (или считает, что знает) интересы производителей, полагая, что они описываются целевой функцией (1). Тогда гипотеза центра о поведении производителя состоит в том, что он должен так выбрать свое управление Li , чтобы максимизировать доход (1). Применительно к сфере исследуемого бизнес-процесса центром является объединение N-команд, ведущих разработку для одного или нескольких ИТ-проектов. Выпускаемой продукцией являются готовые интеграционное решения, которые разрабатываются каждой командой в отдельности. Целевая функция будет зависеть от производительности всех команд. Исследование данного процесса привело к выводу о том, что наиболее перспективным методом его моделирования в интересах совершенствования управления, является СИМ по МДМ [12]. Применение СИМ по МДМ предполагает использование наиболее развитых (по сравнению с другими подходами) способов целенаправленного повышения эффективности управления сложными системами на основе моделирования динамики их функционирования с учетом случайных факторов, влияющих на принятие управленческих решений. Прикладная ценность СИМ по МДМ заключается в том, что он позволяет на основе хорошо апробированных и относительно простых графических средств, без потери необходимой точности и достоверности, формализовать исследуемые сложные системы на выбранном уровне их абстрагирования, а затем перейти от содержательного описания сложной системы к непосредственной программной реализации СИМ-модели. Целесообразность разработки и практического применения данной модели обусловлено необходимостью использовать метод альтернативных вариантов (сценариев) при проектировании и анализе эффективности сложной системы, предусматривающий сравнение между собой разных форм организации сложной системы с последующим выбором и реализацией наилучшей из них. Рассматриваются следующие сценарии: Сценарий 1. В стандартном сценарии заявка поступает в отдел интеграции, где назначается на любого аналитика, далее на разработчика. После заявка поступает в отдел тестирования и распределяется на любого тестировщика. Выбор исполнителя осуществляется руководителем разработки, исходя из имеющейся у него информации о занятости исполнителей. Исполнитель каждой роли «аналитик», «разработчик», «тестировщик» выполняют строго обозначенный перечень работ, обязанностей, которые соответствуют компетенциям роли. Сценарий 2. Здесь рассматривается вариант реорганизации структуры управления в компании в условиях цифровой трансформации бизнеса, которая предполагает объединение отделов разработки и тестирования с целью разделения исполнителей на команды. Вопрос укомплектования команд является актуальным и сложным, так как необходимо учесть влияние большего числа случайных факторов и условий. Предполагается разделить N исполнителей на k команд, при этом должны выполняться условия: - команда обязательно должна включать представителя каждой роли «аналитик», «разработчик», «тестировщик»; - команды должны быть примерно равные между собой по производительности (то есть нельзя, например, чтобы в одной команде были только опытные сотрудники, а в другой команде объединить «новичков»). При этом нужно учесть распределение исполнителей не только по командным ролям, но и по функциональным ролям; - необходимо учесть, что исполнители N территориально находятся в разных городах G, поэтому важно исключить ситуацию, когда исполнитель оказался бы единственным участником команды в городе Gn; - необходимо оценить влияние на общую производительность принцип функционального укомплектования команд. Функциональное распределение предполагает, что каждая команда будет специализироваться на каком-то конкретном виде интеграции (функции). Здесь может возникнуть ситуация, когда команда будет наращивать опыт в интеграции с выделенными ей функциями, достигнет максимума, что позволит быстро, с минимальным количеством ошибок проектировать интеграционные решения, но при этом есть и отрицательная сторона - закрепление за командой конкретных видов интеграции не позволит наращивать компетенции и опыт по другим видам интеграций; - необходимо оценить влияние на общую производительность принципа горизонтального развития компетенций, который предполагает возможность одной функциональной роли выполнять другие роли. То есть аналитик может при необходимости выполнить некоторые задачи разработчика, если, например, разработчик перегружен или может протестировать самостоятельно часть кода, если тестировщик заболел, ушел в отпуск или просто перегружен работой и т.д. Целью исследования сложной системы является предсказание ее поведения в будущем - на основе прошлых и настоящих фактических данных о ней, с учетом возможной динамики параметров внешней среды, влияния внешних и внутренних случайных факторов. В качестве входных данных ЛПР будет вводить данные о желаемом распределении исполнителей по командам, задавать условия, ограничения и требования, предъявляемые к командам. Далее будет эмулироваться обработка заявок за период моделирования (один спринт или один релиз) получившимися командами. Моделирование позволяет выявить узкие места, учесть влияние случайных факторов на бизнес-процесс разработки и кастомизации интеграционных решений, отследить подробную статистику и поведение системы во времени и проиграть сценарии при различных вариантах укомплектования команд. Практическая значимость работы заключается в возможности принятия ИТ-менеджерами обоснованных решений на стадии формирования команд разработки с целью повышения эффективности работы команд в условиях трансформации бизнеса и перехода на командное управление. Заключение В статье рассмотрена функциональная характеристика объекта исследования и специфика предметной области, разработана содержательная и формализованная модели бизнес-процесса разработки и кастомизации интеграционных решений, разработаны и описаны задачи управления сложной системой, которые можно решить с помощью СИМ по МДМ.

About the authors

Eduard Mikhailovich Dimov

Povolzhskiy State University of Telecommunications and Informatics

Email: e.m.dimov@gmail.com

Oleg Nikolayevich Maslov

Povolzhskiy State University of Telecommunications and Informatics

Email: maslov@psati.ru

Svetlana Vladimirovna Khadzhieva

Povolzhskiy State University of Telecommunications and Informatics

Email: ssv2507@mail.ru

References

Supplementary files