ОСНОВЫ МОДЕЛИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ AS-IS и TO-BE

Аннотация. В рамках данной работы проведено исследования особенностей моделирования бизнес-процессов, выявлены основные модели, используемые при описании бизнес-процессов. Автором также проведен анализ и определены особенности построения моделей AS-IS и TO-BE, представлена модель AS-IS, отражающая описание бизнес-процесса регистрации и оповещение в системе управления несоответствиями.

Ключевые слова: бизнес-процесс, моделирование бизнес-процессов, модель «как есть», модель «как будет», информационные системы, функциональное моделирование.

Моделирование бизнес-процесса и его осуществление должен проводить один человек, это начальник, директор, руководитель проекта или сам предприниматель. Но всегда один! Если руководителей одного процесса несколько, то он распадется на столько частей, сколько лиц будет им командовать, как бы они гордились, что у них «дружная и сплоченная» команда. Бизнес-процессы организации, которых всегда присутствует не менее 10, всегда управляются ответственными лицами. Но бизнес-процесс основной, включающий множество мелких, должен управляться одним человеком – генеральным директором, управляющим предприятием, владельцем. Только так предприятие может выйти на более организованные, грамотные и современные пути развития [4, c.84].

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

С точки зрения актуальности содержания модели делятся на:

- Модель «Как есть» (англ. «AS IS»): отражает РЕАЛЬНОЕ положение дел на момент описания, фактически имеющуюся, сложившуюся технологию работы.

- Модель «Как должно быть» (англ. «TO BE»): отражает целевое состояние, которое в дальнейшем предполагается претворить в жизнь. Например, модель работы вновь открываемого предприятия, или же новый (совсем новый или улучшенный старый) порядок выполнения каких-либо работ.

- Модель «Как должно бы быть» (англ. «SHOULD BE»): отражает «идеализированное» положение дел (например, согласно регламентирующим документам, тогда как фактическая схема работ в реальности может быть несколько иной). На практике необходимость в построении таких моделей встречается нечасто [3, c.95].

Причем эти модели одного и того же процесса могут различаться весьма значительно.

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

Однако, к сожалению, на практике, часто и описания конкретных процедур (а, по практике, именно они и представляют наибольшую ценность и на них приходится больший объем работ, именно они отражают основное организационное ноу-хау организации) пытаются моделировать с помощью средств функционального моделирования. Результат получается, да простят меня авторы таких работ, похожий на большую плату с микросхемами и большим количеством проводов. Однако, для этих целей предназначены модели потоков работ (worklow-модели) [1, c.4436].

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

Рассмотрим модель бизнес-процесса «TO BE», описывающей моделирование информационной системы управления несоответствиями, а именно процесс регистрации и оповещения в системе (рисунок 1).

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

1. «Зарегистрированные несоответствия из эксплуатации» - запускается при получении сообщения/сигнала о выявлении несоответствия в составе изделия.
2. «Зарегистрированные несоответствия в производстве» - запускается при обнаружении несоответствия в производстве (внутри цехов объединения) и соответствует получению ДСЕ отклонения от КД или списанию в брак.
3. «Зарегистрированные несоответствия при входном контроле потребителя» - запускается при получении претензии от завода-кооперанта и свидетельствует о наличии проблем с ДСЕ на входном контроле у завода-потребителя.
4. «Зарегистрированный пропуск несоответствий из цеха в цех» - запускается при обнаружении пропуска несоответствия из цеха в цех внутри объединения.
5.  

Рисунок 1. Модель «TO BE». Регистрация и оповещение в системе управления несоответствиями

Действия в модели обозначены как   . Если обратить внимание на модель, то можно заметить, что ключевые действия для любого из несоответствия независимо от его источника, одинаковы. Примеры таких действий:

1. «Система оповещает соответствующие подразделения о наличии несоответствия».
2. «Выбор мероприятий по работе с несоответствием, назначение сроков и ответственных». Назначаются первичные мероприятия. Полная проработка запланирована на этапе 2, где будет генерироваться документ «Программа работы с дефектом».

У данного процесса 2 выхода:

1. Основной – обозначен как  «Завершение этапа 1. Блокировка изменений». Срабатывает при успешном завершении рабочего процесса и в свою очередь переводит ПО из состояния «Этап 1» в состояние «Этап 2». Таким образом, выход процесса «Этап 1» является входом для процесса «Этап 2».
2. Эскалация – обозначена как  «К процедуре входного контроля». Является частным и весьма специфическим случаем завершения процесса, когда объединением было выявлено несоответствие на ДСЕ или ПКИ, которое они по условиям договора не могли подвергать процедуре входного контроля. Данное завершение запускает соответствиющие юридические и технические процедуры по урегулированию прецедента и недопущению в будущем подобных ситуаций.

Таким образом, именно на основе модели TO-BE рекомендуется производить автоматизацию бизнес-процессов и проектировать информационную систему. Подразумевается, что это позволяет существенно снизить риск проявления автоматизации как исключительно источника затрат из-за автоматизации несовершенных процессов.

Список литературы:

1. Никулина Т. Н., Фартушина А. С. Проблемы моделирования бизнес-процессов в современных организациях // Научно-методический электронный журнал «Концепт». – 2015. – Т. 13. – С. 4436–4440.
2. Репин, В.В. Процессный подход к управлению. Моделирование бизнес-процессов / В.В. Репин. - М.: Манн, Иванов и Фербер, 2013. - 544 c.
3. Селецкая А. С. Моделирование бизнес-процессов: подходы, методы, этапы // Молодой ученый. — 2018. — №9. — С. 95-96.
4. Чукарин, А.В. Бизнес-процессы и информационные технологии в управлении современной инфокоммуникационной компанией / А.В. Чукарин. - М.: Альпина Паблишер, 2016. - 512 c.