Статья опубликована в рамках: XXXVIII Международной научно-практической конференции «Естественные и математические науки в современном мире» (Россия, г. Новосибирск, 13 января 2016 г.)
Наука: Информационные технологии
Секция: Управление в социальных и экономических системах
Скачать книгу(-и): Сборник статей конференции
дипломов
Статья опубликована в рамках:
Выходные данные сборника:
РАЗРАБОТКА МЕТОДА КОНТРОЛЯ ВЫПОЛНЕНИЯ РАБОЧИХ ПРОЦЕССОВ В ОРГАНИЗАЦИИ
Калинина Надежда Александровна
аспирант 1 года обучения,
профиль подготовки «Управление в социальных и экономических системах»,
Школа экономики и менеджмента ДВФУ,
РФ, г. Владивосток
E-mail: kalinina.na@dvfu.ru
Шумский Алексей Евгеньевич
проф., д-р техн. наук, Школа экономики и менеджмента ДВФУ,
РФ, г. Владивосток
DEVELOPMENT OF METHODS FOR THE CONTROL OF IMPLEMENTATION WORKFLOW IN THE ORGANIZATION
Nadezhda Kalinina
post-graduate education,
the profile of training “Management in social and economic systems”,
School of Economics and Management, Far Eastern Federal University,
Russia, Vladivostok
Alexey Shumsky
doctor of Technical Sciences,
the School of Economics and Management, Far Eastern Federal University,
Russia, Vladivostok
АННОТАЦИЯ
В данной статье рассматривается проблема создания удобных для контроля механизмов, позволяющие вносить коррекции в происходящий рабочий процесс до момента получения результата и, таким образом, влиять на конечный результат. Это важно, когда неправильный результат рабочего процесса может привести к серьезным финансовым или человеческим потерям.
В статье предложен метод решения проблемы контроля выполнения рабочих процессов в организации, на примере «Процесса управления изменениями ИТ услуг».
ABSTRACT
This article deals with the problem of creating easy-to-control mechanisms that allow to make the correction in the workflow prior to receipt of the result, and thus affect the final result. This is important when the wrong result is a workflow can lead to serious financial or human losses.
This paper proposes a method of solving the problem of monitoring the implementation of work processes in the organization, by the example of “change management processes of IT services”.
Ключевые слова: человеко-машинные системы; автоматизация; рабочие-процессы; метод контроля; принятие решение.
Keywords: human-machine systems; automation; operating processes; quality monitoring; decision-making.
В настоящее время можно выделить следующую проблему управленческого контроля в организации: в теории и практике менеджмента внимание в большей степени акцентируется на обоснованности принимаемых решений, чем на контроле за их выполнением и как следствие отмечается смещение внимания в сторону разработки планов и принятия решений в ущерб контролю за их выполнением [3].
На текущий момент отсутствуют методы контроля выполнения рабочих процессов в организации, позволяющие отслеживать текущее состояние процесса и делать анализ о предстоящем результате рабочего процесса на основании наблюдаемых факторов, тем самым позволяя влиять на окончательный результат [2; 1].
Данное исследование заключается в разработке метода контроля выполнения рабочих процессов в организации, направленного на предотвращение появления незапланированных результатов.
Основой для создания нового метода послужили исследования в области человеко-машинных систем в части контроля работы оператора транспортных систем [4], где поднимается проблема контроля «правильного» поведения оператора транспортных систем. Под «правильным» поведение понимается поведение в соответствии с регламентами. Целью контроля является выявление возникновения неожиданных ситуаций и классификация этих ситуации на основе ожидаемого уровня угрозы [4; 5].
В связи с повсеместной автоматизацией рабочих процессов, происходящей в организации, участников рабочего процесса можно представить, как операторов машин, в данном случае, компьютерной техники [8; 7]. Поэтому для разработки метода контроля выполнения рабочих процессов в организации мы применили качественные или количественные модели человеко-машинных систем.
Так же в своей работе мы считаем, что при выполнении работ по регламенту всеми участниками процесса результат всегда будет удовлетворять поставленным целям данного процесса.
Идея разработанного метода контроля выполнения рабочих процессов в организации сводиться к анализу данных получаемых с автоматизированных систем, в частности с систем мониторинга, и сопоставлению их регламенту выполнения работ. Для реализации данной идеи необходимо обеспечить актуальность регламента выполнения работ и разработать механизм сопоставления данных системы мониторинга с регламентом выполнения работ.
Рассмотрим, разработанный метод контроля выполнения рабочих процессов в организации, на примере «Процесса управления изменениями ИТ услуг».
Цель данного процесса – поддержание актуального состояния ИТ услуг.
Описание «Процесса управления изменениями ИТ услуг» представлено следующими характеристиками [6]: вход процесса, выход процесса, роли участников процесса, регламент выполнения работ.
Вход процесса: запросы на изменения.
Выход процесса:
- изменение предоставление ИТ услуги и сопровождающие документы (журнал изменений, отчеты о работе процесса)
- уведомления пользователям, информирующие о планируемых изменениях, уведомления сотрудникам, принимающим участие в проведении изменений, оповещение о плановых изменениях, проводимых ИТ службой в организации, для оперативного предоставления диспетчером информации при запросах пользователей.
Роли участников процесса:
- Инициатор изменение – представитель департамента ИТ, осуществляющий первичную обработку, назначение и контроль над ходом выполнения изменений;
- Исполнитель работ – инженер, производящий изменения в элементах конфигурации или координирующий работы подрядчика по этим изменениям;
- Консультативный комитет по изменениям (далее – CAB) – консультативный орган, регулярно собирающийся для оценки и планирования изменений;
- Менеджер процесса управления изменениями – представитель департамента ИТ, осуществляющий контроль за процессом управления изменениями и формирующий предложения по его улучшению.
При описании регламента нами сразу определены будут состояния процесса и функции перехода из одного состояния в другое, для дальнейшей формализации «Процесса управления изменениями ИТ услуг».
Краткое описание регламента:
Шаг 1. Инициатор изменения формирует задание (состояние S1), которое за счет функции перехода i1 передается на согласование в комитет САВ (состояние S2),
Шаг 2. Комитет САВ принимает решение согласовать предложенный план внесения изменений (i2) или же отправить на доработку (i3), в случае, если план будет согласован комитетом САВ, план работ передается менеджеру процесса управления изменениями (S3),
Шаг 3. Менеджер процесса управления изменениями вносит соответствующие отметки в систему мониторинга, после этого передает согласованный план работ на исполнение (i3),
Шаг 4. Исполнитель получает задание и после выполнения сообщает менеджеру процесса управления изменениями о готовности (i5),
Шаг 5. Менеджер процесса управления изменениями проверяет выполненные работы и в случае, если они нуждаются в доработки отправляет данную информацию инициатору (i7), в случае если работы выполнены в соответствии с планом то закрывает работы (i 6),
Шаг 6. Работы выполнены (состояние S6).
Формализуем «Процесс управления изменениями ИТ услуг» представив в табличной форме (таблица 1).
Таблица 1.
Базовая модель «Процесса управления изменениями ИТ услуг»
|
i1 |
i2 |
i3 |
i4 |
i5 |
i6 |
i7 |
S1 |
S2 |
- |
- |
- |
- |
- |
- |
S2 |
- |
S3 |
S1 |
- |
- |
- |
- |
S3 |
- |
- |
- |
S4 |
- |
- |
- |
S4 |
- |
- |
- |
- |
S5 |
- |
- |
S5 |
- |
- |
- |
- |
- |
S6 |
S1 |
S6 |
- |
- |
- |
- |
- |
- |
- |
После построения базовой модели, дополним ее событиями, которые не входят в регламент, но могут иметь место быть. Для нашего примера мы взяли следующие события:
- когда инициатор не передает задание на согласование комитет САВ, а передает сразу менеджеру процесса управления изменениями (i1: S1-> S3 (неправильная функция перехода);
- когда исполнитель не передает выполненные работы менеджеру процесса управления изменениями, а сам закрывает работы (i5: S4-> S6 (неправильная функция перехода);
- когда менеджер процесса управления изменениями отправляет результат проверки выполненного задания на повторное согласование в комитет САВ (i7: S5-> S2 (неправильная функция перехода);
- когда менеджер процесса управления изменениями отправляет полученное согласованное задание обратно инициатору (i8: S3-> S1 (неправильная функция перехода);
- когда менеджер процесса управления изменениями отправляет полученное согласованное задание обратно на согласование в комитет САВ i8: S3-> S2 (неправильная функция перехода);
- когда исполнитель отправляет полученное согласованное задание обратно инициатору i9: S4-> S1 (неправильная функция перехода);
- когда исполнитель отправляет полученное и согласованное задание обратно на согласование в комитет САВ i9: S4-> S2 (неправильная функция перехода). Добавим данные события в базовую модель (Таблица 2).
Таблица 2.
Уточнённая модель процесса управления изменениями ИТ систем
|
i1 |
i2 |
i3 |
i4 |
i5 |
i6 |
i7 |
i8 |
i9 |
S1 |
S2 S3 |
- |
|
- |
- |
- |
- |
- |
- |
S2 |
- |
S3 |
S1 |
- |
- |
- |
- |
- |
- |
S3 |
- |
- |
- |
S4 |
- |
- |
- |
S1 S2 |
- |
S4 |
- |
- |
- |
- |
S5 S6 |
- |
- |
- |
S1 S2 |
S5 |
- |
- |
- |
- |
- |
S6 |
S1 S2 |
- |
- |
S6 |
- |
- |
- |
- |
- |
- |
- |
- |
- |
Уточненная модель «Процесса управления изменениями ИТ услуг», представленная таблицей 2, состоит из «правильного» порядка действий и возможных «неправильных» действий. Важно отметить, что нельзя однозначно сказать, что данные «неправильные» действия направлены на причинение ущерба, возможны ситуации, что из-за непредвиденных причин не было возможности использовать «правильный» порядок действий.
Теперь сделаем предобразование уточнённой модели «Процесса изменения ИТ услуг», приведем ее к детерминированному виду. Для этого с помощью преобразования описанного в работе [4] сделаем блоки разбиения по непересекающимся подмножествам состояний и функций переходов. Сделаем несколько последовательных итераций для выявления блоков разбиения. В первой итерации мы рассмотрим все состояния S1, S2, S3, S4, S5, S6 по всем функциям перехода i1, i2, i3, i4, i5, i6, i7, i8, i9 и выявим первый блок разбиения S*1, на второй итерации рассмотрим не вошедшие в блок разбиения S*1 состояния S1, S2, S3, S4, S5, S6, таким образом получим следующий блок разбиения и так далее, пока не останется состояния S1, S2, S3, S4, S5, S6, которые не вошли в один из блоков разбиения. И так повторим для всех состояний. Результат представлен в Таблицах 3 и 4.
Таблица 3.
Блоки разбиения по непересекающимся подмножествам состояний и функций переходов
|
i1 |
i2 |
i3 |
i4 |
i5 |
i6 |
i7 |
i8 |
i9 |
S*1 |
S*1 |
S*1 |
S*1 |
- |
- |
- |
S*1 |
S*1 |
S*1 |
S*2 |
- |
- |
- |
S*2 |
- |
- |
- |
- |
- |
S*3 |
- |
- |
- |
- |
S*3 |
S*3 |
- |
- |
- |
Таблицу 4.
Состояния, включенные в каждый блок разбиения
|
S1 |
S2 |
S3 |
S4 |
S5 |
S6 |
S*1 |
+ |
+ |
+ |
- |
- |
- |
S*2 |
- |
- |
- |
+ |
- |
- |
S*2 |
- |
- |
- |
- |
+ |
+ |
Продемонстрируем использование преобразованной уточненной модели «Процесса управления изменениями ИТ услуг».
Итак, существует вероятность того, что одна или более функция перехода i будет применена в изменившихся условиях, которые не были спрогнозированы и отображены в уточненной модели, а, следовательно, невозможно определить приведёт ли дальнейшее выполнения рабочего процесса к «неправильному» результату. Используем преобразованную уточненную модель, представленную в таблице 3, для того чтобы определить оказывают ли изменившиеся условия воздействия на результат рабочего процесса. Для этого, проверим результат применения функции перехода i к состоянию S, если будет произведен переход в состояние, не соответствующее таблицам 3, 4, то изменившиеся условия оказывают «разрушающие» воздействия на результат процесса, в противном случае – нет, результат процесса будет соответствовать прогнозированному.
Например: Если из состояния S1 по средствам функции перехода i1 мы оказываемся в блоке разбиения S*2, то еще до завершения рабочего «Процесса управления изменениями ИТ услуг» можно однозначно сказать, что результат выполнения процесса будет «неправильный». Если из состояния S1 по средствам функции перехода i1 мы оказываемся в блоке разбиения S*1, то результат рабочего процесс соответствует прогнозируемому.
Итак, метод контроля выполнения рабочих процессов в организации состоит их трех этапов:
На этапе создания базовой модели рабочего процесса в организации учитывались только регламентированные работы, которые были названы «правильными» действиями.
На этапе создания уточнённой базовой модели рабочего процесса в организации, учитывались «правильные» и «неправильные» действия. «Неправильные» действия – это реакция на ситуации, которые не были регламентированы, но данные ситуации можно предвидеть и продумать на них корректирующие действия.
На этапе преобразования модели рабочего процесса в организации предполагается возможность фиксировать и контролировать действия, которые не были зарегламентированы и действия, которые невозможно предвидеть, что они произойдут.
Таким образом данный метод позволяет поддерживать в актуальном состоянии регламенты рабочих процессов в организации, а также прогнозировать «неправильный» результат рабочего процесса, до момента появления этого результат, тем самым позволяя предпринимать превентивные воздействия на процесс.
Список литературы:
- Круглое Д.В. Эволюция контроллинга в контексте развития управленческих знаний // Проблемы современной экономики. – 2010. – № 2. – [Электронный ресурс] – режим доступа. – http://cyberleninka.ru/article/n/evolyutsiya-kontrollinga-v-kontekste-razvitiya-upravlencheskih-znaniy (Дата обращения: 15.12.2015).
- Ланская Д.В. Эволюция контроллинга // Научный журнал КубГАУ – Scientific Journal of KubSAU. – 2013. – № 93. – [Электронный ресурс] – режим доступа. – http://cyberleninka.ru/article/n/evolyutsiya-kontrollinga-1 (Дата обращения: 13.01.2016).
- Шкилёв В.В. Совершенствование управленческого контроля в организации // ГОУ ВПО «Орловская региональная академия государственной службы». – 2011 г. – 170 с.
- Berdjag D., Vanderhaegena F., Shumsky A., Zhirabok A. Unexpected situations detection: a model-based approach for human machine systems // Preprint submitted to Control Engineering Practice. – 2014. – № 17.
- Berdjag D., Vanderhaegena F., Shumsky A., Zhirabok A. Unexpected Situations Diagnosis: A Model-based Approach for Human Machine Systems // Preprint submitted to Control Engineering Practice. – 2013. – № 5.
- ITILV. 3 Лучшие практики: Поддержка Услуг. I-Tec. – 2012. – 418 с.
- Oborski P. Man-machine interactions in advanced manufacturing systems // Warsaw University of Technology. – 2013. – № 3. – С. 38–45.
- Smalko Zb. The man – machine type systems modeling approach // Journal of KONBiN – 2008. – № 5.
дипломов