Моделирование бизнес процесса на примере предприятия

Моделирование бизнес-процессов на примере ООО ‘ПромТрансИнформ’

Аннотация

информационный моделирование бизнес

В данной работе рассматриваются бизнес-процессы ООО «ПромТрансИнформ» —
далее ПТИ.

Были рассмотрены и изучены:

·   общая характеристика предприятия;

Были рассмотрены виды деятельности организации, какие продукты она
внедряет и какие услуги оказывает, с какими организациями (в частности
крупнейшими) заключены договоры и как это влияет на деятельность организации.

·   описаны методологии описания бизнес-процессов;

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

·   построены диаграммы бизнес-моделей (в нотациях ARIS с помощью CASE-средства
Microsoft Visio) «AS IS» (как есть);

·        найдено «узкое место» и, на примере модели eEPC, изображена модель «AS TO BE» (как должно быть);

«Узким местом» в данной курсовой является слабая организация рабочего
процесса, которая возникает, когда обязанности распределены не рационально, что
тормозит выполнение заказа.

·   написано соглашение по моделированию и документирование бизнес-процесса;

·        проведен анализ процесса.

Введение

Цель работы заключается в моделировании бизнес-процессов ООО «ПромТрансИнформ»,
выявление недостатков в деятельности конкретных отделов и предложение способа
их устранения.

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

Объектом изучения, в данной курсовой работе, является ООО ПТИ и его
отделы, главной услугой которого — автоматизация предприятий промышленного
железнодорожного транспорта.

Предметом изучения является взаимодействие отделов и сотрудников в этих
отделах, подчиняющихся Генеральному директору.

Задачи работы: обучение навыкам работы с методологией моделирования
бизнес-процессов ARIS, сбор
информации и изучение бизнес-процессов предприятия, процедур моделирования,
построение диаграмм бизнес-моделей, разработка соглашения по моделированию и
документирование бизнес-процесса, проведение анализа процесса.

Методы работы. Работа выполняется с целью повышения навыков построения
диаграмм бизнес-моделей в нотациях ARIS с помощью CASE-средства Microsoft Visio на примере бизнес-процессов ОАО «ПТИ».

В качестве исходных данных в работе используются следующие сведения:

·   организационно-штатная структура предприятия;

·        характеристика предприятия;

·        организация проектирования в консалтинговых предприятиях;

·   сведения об используемых прикладных системах ПТИ.

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

1. Архитектура интегрированных информационных систем ARIS как методология
моделирования бизнес-процессов

Разработчиком методологии ARIS (Architecture of Integrated Information Systems) является компания IDS Scheer AG, основанная в 1984 г. профессором Августом-Вильгельмом
Шеером в г. Саарбрюккен (Саар, Германия). Методология ARIS представляет собой современный подход к
структурированному описанию деятельности организации и ее представлению в виде
взаимосвязанных и взаимодополняющих графических моделей, удобных для понимания
и анализа.

Модели, используемые в ARIS,
представлены на рисунке 1.1.

Рисунок 1.1 — Классификация моделей ARIS

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

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

Методология ARIS основывается
на концепции интеграции, предлагающей целостный взгляд на процессы, и
представляет собой множество различных методик, объединенных в рамках единого
системного подхода. Среди них такие известные, как:

·   диаграмма eEPC (Extended Event Driven Process Chain — событийная цепочка
процесса)

·        диаграмма Чена (ERM — Entity
Relationship Model — модель
«сущность — связь»)

·        язык UML (Unified Modeling Language — универсальный язык моделирования)

·        методика OMT (Object Modeling Technique — методика объектно-ориентированного
моделирования)

·        методика BSC (Balanced Scorecard — система сбалансированных
показателей)         Достоинством такого подхода является то, что появляется
возможность описания процессов и их окружения с различных, взаимодополняющих
точек зрения.

2. Преимущества и недостатки существующих методологий моделирования
бизнес-процессов

Методология ARIS.

Преимущества:

·   возможность рассматривать объект с разных точек зрения; разные уровни
описания, обеспечивающие поддержку концепции жизненного цикла систем;
дифференцированный взгляд на анализируемый объект (организацию, систему
управления и т.д.);

·        богатство методов моделирования, отражающих различные аспекты
исследуемой предметной области, позволяет моделировать широкий спектр систем
(организационно-хозяйственных, технологических и прочих);

·        единый репозиторий; все модели и объекты создаются и хранятся
в единой базе проекта, что обеспечивает построение интегрированной и целостной
модели предметной области;

·        возможность многократного применения результатов
моделирования; накопленное корпоративное знание о всех аспектах деятельности
организации может в дальнейшем служить основой при разработке различных
проектов непосредственно в среде ARIS и с использованием интерфейсов и других
средств.

Недостатки:

·   Для некоторых процессов чрезмерная формализация не только малоэффективна,
но даже вредна в силу их специфики. Примером могут являться те составляющие
бизнес — деятельности, которые напрямую связаны с творческими решениями
малопрогнозируемых проблем, возникающих в ходе этой деятельности.

·        Высокая стоимость продукта.

SADT (Structured Analysis and Design Technique) — методология
структурного анализа и проектирования, интегрирующая процесс моделирования,
управление конфигурацией проекта, использование дополнительных языковых средств
и руководство проектом со своим графическим языком. Процесс моделирования может
быть разделен на несколько этапов: опрос экспертов, создание диаграмм и
моделей, распространение документации, оценка адекватности моделей и принятие
их для дальнейшего использования. Этот процесс хорошо отлажен, потому что при
разработке проекта специалисты выполняют конкретные обязанности, а библиотекарь
обеспечивает своевременный обмен информацией.возникла в конце 60-х годов в ходе
революции, вызванной структурным программированием. Когда большинство специалистов
билось над созданием программного обеспечения, немногие старались разрешить
более сложную задачу создания крупномасштабных систем, включающих как людей и
машины, так и программное обеспечение, аналогичных системам, применяемым в
телефонной связи, промышленности, управлении и контроле за вооружением. В то
время специалисты, традиционно занимавшиеся созданием крупномасштабных систем,
стали осознавать необходимость большей упорядоченности. Таким образом,
разработчики решили формализовать процесс создания системы, разбив его на
следующие фазы:

·   Анализ — определение того, что система будет делать

·        Проектирование — определение подсистем и их взаимодействие

·        Реализация — разработка подсистем по отдельности

·        Объединение — соединение подсистем в единое целое

·        Тестирование — проверка работы системы

·        Установка — введение системы в действие

·        Эксплуатация — использование системы

Метод SADT в наибольшей степени подходит для
описания моделей верхнего уровня. Его основные преимущества заключаются в
следующем:

·   полнота описания БП (управления, информационные и материальные потоки,
обратные связи).

·        Комплексность декомпозиции

·        Возможность агрегирования и детализации потоков данных и
информации (разделение и слияние дуг)

·        Наличие жестких требований, обеспечивающих получение модели
стандартного вида.

·        Простота документирования процесса

·        Соответствие подхода к описанию процесса стандарту ИССО

В то же время SADT обладает
рядом недостатков:

·   Сложность восприятия — большое количество дуг на диаграмме.

·        Большое количество уровней декомпозиции

·        Трудность увязки нескольких процессов, представленных в
различных моделях одной и той же организации.

IDEF0

Методология функционального моделирования. С помощью наглядного
графического языка IDEF0, изучаемая система предстает перед разработчиками и
аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в
терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым
этапом изучения любой системы.

Основные преимущества IDEF0 состоят в следующем:

·   полнота описания бизнес-процесса (управление, информационные и
материальные потоки, обратные связи);

·        комплексность при декомпозиции (мигрирование и туннелирование
стрелок);

·        возможность агрегирования и детализации потоков данных и
информации (разделение и слияние стрелок);

·        наличие жестких требований методологии, обеспечивающих
получение моделей процессов стандартного вида;

·        простота документирования процессов;

·        соответствие подхода к описанию процессов в IDEF0 стандартам
ISO 9000:2000.

Отсюда и общее назначение IDEF0 — это перестройка структуры функций,
которая позволит повысить производительность и эффективность системы.

Методология IDEF3 (Integrated Definition Process Description Capture
Method) была разработана с целью более удобного описания рабочих процессов
(Work Flow), для которых важно отразить логическую последовательность
выполнения процедур. Эта методика, в отличии от IDEF0, не стандартизирована. —
это структурный метод, показывающий причинно-следственные связи и события. Он
также показывает, как организована работа, и какие пользователи работают с
моделируемой системой. С помощью IDEF3 описываются сценарий и
последовательность операций для каждого процесса. Сценарием называется описание
последовательности изменения свойств объекта в рамках рассматриваемого процесса
(например, описание последовательности этапов обработки детали в цеху и
изменение ее свойств после прохождения каждого этапа). Исполнение каждого
сценария сопровождается соответствующим документооборотом, который состоит из двух
потоков: документы, определяющие структуру и последовательность процесса
(технологические указания, описания стандартов) и документы, отображающие ход
его выполнения (результаты экспертиз, отчеты о браке).

Средства документирования и моделирования IDEF3 позволяют выполнять
следующие задачи:

·   документировать имеющиеся данные о технологии процесса;

·        определять и анализировать точки влияния потоков
сопутствующего документооборота на сценарий технологических процессов;

·        определять ситуации, в которых требуется принятие решения,
влияющего на жизненный цикл процесса (например, изменение технологических
свойств конечного продукта);

·        содействовать принятию оптимальных решений при реорганизации
технологических процессов;

·        разрабатывать имитационные модели технологических процессов
по принципу «как будет, если…».

IDEF3 имеет прямую взаимосвязь с методологией IDEF0 — каждая функция
может быть представлена в виде отдельного процесса средствами IDEF3. Но
функциональное моделирование в IDEF3 отличается от моделирования в IDEF0 и DFD,
тем что она отражает функции системы во временной последовательности их
осуществления.

Методология DFD (Data Flow Diagrams) — диаграммы потоков данных — это
способ представления процессов обработки информации. Авторы методики Гейн и
Сарсон разработали ее независимо от IDEF0. Эта методика, в отличии от IDEF0 не
стандартизирована.

В отличие от стрелок IDEF0, которые представляют собой жесткие
взаимосвязи, стрелки DFD (потоки данных) показывают, как объекты (включая и
данные) реально перемещаются от одной функции к другой. Это представление
потока данных обеспечивает отражение в модели DFD таких физических
характеристик системы, как движение объектов, хранение объектов,
распространение объектов.

Диаграммы DFD обеспечивают удобный способ описания передаваемой
информации как между частями моделируемой системы, так и между системой и
внешним миром. Это качество определяет область применения DFD — они
используются для создания моделей информационного обмена организации, например,
модели документооборота. Также DFD широко применяется при построении
корпоративных информационных систем. Modeling Language (UML), унифицированный
язык моделирования, непатентованный язык моделирования и спецификации,
предназначенный для использования в области разработки программного
обеспечения. Тем не менее, сфера его применения не ограничивается областью
моделирования информационных систем. Он также может быть использован для
моделирования инженерных систем, бизнес-процессов, организационных структур.
UML — язык используемый системными инженерами для спецификации, визуализации,
конструирования и документирования сложных информационно-насыщенных объектных
систем.

Преимущества
UML

·      UML объектно-ориентирован, в результате чего методы описания
результатов анализа и проектирования семантически близки к методам
программирования на современных объектно-ориентированных языках;

·              UML позволяет описать систему практически со всех возможных
точек зрения и разные аспекты поведения системы;

·              Диаграммы UML сравнительно просты для чтения после достаточно
быстрого ознакомления с его синтаксисом;

·              UML расширяет и позволяет вводить собственные текстовые и
графические стереотипы, что способствует его применению не только в сфере
программной инженерии;

·              UML получил широкое распространение и динамично развивается.

Недостатки:

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

·              Неточная семантика. Так как UML определён комбинацией себя
(абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки
правильности) и Английского (подробная семантика), то он лишен скованности
присущей языкам, точно определённым техниками формального описания. В некоторых
случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в
других случаях они неполные. Неточность описания самого UML одинаково
отражается на пользователях и поставщиках инструментов, приводя к
несовместимости инструментов из-за уникального трактования спецификаций.

·              Проблемы при изучении и внедрении. Вышеописанные проблемы
делают проблематичным изучение и внедрение UML, особенно когда руководство
насильно заставляет использовать UML бизнес-аналитиков при отсутствии у них
предварительных навыков.

·              Пытается быть всем для всех. UML — это язык моделирования
общего назначения, который пытается достигнуть совместимости со всеми
возможными языками разработки. В контексте конкретного проекта, для достижения
командой проектировщиков определённой цели, должны быть выбраны применимые
возможности UML. Кроме того, пути ограничения области применения UML в
конкретной области проходят через формализм, который не полностью
сформулирован, и который сам является объектом критики.

3. Выбор бизнес-процесса для моделирования и его содержательное описание

.1 Общая характеристика предприятия

ООО ПромТрансИнформ занимается автоматизацией
предприятий промышленного железнодорожного транспорта за счет внедрения
информационных компонентов программно-технического комплекса Интегрированной
информационной системы управления «Транспортно-логистический комплекс»,
управлением проектами внедрения специализированных информационных систем
управления на магистральном железнодорожном транспорте, а также управлением
проектами внедрения на территории Республики Казахстан приборов, устройств и
информационных систем железнодорожной автоматики и телемеханики,оказывает
консалтинговые услуги в этой сфере.

Основными направлениями деятельности ООО «ПромТрансИнформ» являются:

-Автоматизация железнодорожных предприятий, которая работает с такими
ИТ-продуктами, как ИАС «Транспортная работа»,ИАС «Эксплуатационные расходы»,
ИАС «Транспортные активы»,ИАС «Взаимодействие с клиентами»,ИАС «Эффективность
логистики».

Аппаратно-программный комплекс ИАС ТР является частью
программно-технической платформы «PTI Framework .Net.2.1.», на котором построена Интегрированная
информационная система управления «Железнодорожный комплекс» (ИИСУ «ЖДК»)

Данный комплекс является специализированным решением ООО «ПромТрансИнформ»,
базирующимся на ИТ-продуктах линейки .NET компании Microsoft.

ИАС ТР использует значительный объем встроенной бизнес-логики,
обеспечивающей автоматизированное ведение процессов управления железнодорожным
комплексом Заказчика.

Информационно-аналитическая система «Транспортная работа» (далее «ИАС
ТР»), разработана специалистами ООО «ПромТрансИнформ» (г. Новосибирск).

Основной целью внедрения ИАС ТР является комплексная автоматизация
управленческих бизнес-процессов производственного планирования и учета объемов
и стоимости:

      Транспортной
логистики (перевозок);

  Транспортной (логистической) работы;

      Транспортного
обслуживания клиентов (оказания транспортных услуг);

      Транспортных
расходов (себестоимости работ и тарифов на услуги);

  Эксплуатации транспортных активов железнодорожного
предприятия на подъездном пути и в магистральном движении.

Она учитывает отраслевые отличия
производственно-экономической деятельности железнодорожных предприятий (по
сравнению с деятельностью промышленных предприятий)

Также ООО ПромТрансИнформ занимается транспортным и экономическим
консалтингом (Транспортно-логические комплексы на ж/д, Транспортный консалтинг
на ж/д транспорте, Экономический консалтинг на ж/д транспорте, ИТ-Консалтинг на
ж/д транспорте, Методические руководства по ж/д тарифам) и управлением
проектами на ж/д предприятиях (внедрение информационных систем на ж/д
транспорте, оптимизация бизнес-процессов железнодорожной транспортной
логистики, оптимизация эксплуатационных расходов железнодорожного транспортного
комплекса, внедрение систем управления проектами).

Основными партнерами и заказчиками ООО
«ПромТрансИнформ» являются предприятия промышленного железнодорожного комплекса
железнодорожной отрасли Республики Казахстан и России.

Основным методологическим партнером ООО
«ПромТрансИнформ» является ГОУ «Сибирский государственный университет путей
сообщения» (г.Новосибирск).Специалисты компании имеют 6 — летний опыт работы в
железнодорожной отрасли.

3.2 Область обследования

В качестве исследуемого объекта возьмем ООО «ПромТрансИнформ», а именно
процесс организации рабочего процесса. Исследовав это предприятия и пообщавшись
с сотрудниками, можно определить, что налицо слабая организация рабочего
процесса. Более полное описание «узкого места» и способы его устранения
представлены в разделе «Анализ процесса».

Организационная структура ООО «ПромТрансИнформ» (рисунок 3.1):

Рисунок 3.1-Оргструктура ПТИ

3.3 Порядок проведения обследования

·   Место проведения обследования — здание ООО ПромТрансИнформ ул.Красный
проспект, 220/5,оф.326 (Сибирская Ярмарка);

·        Способ обследования — интервью с сотрудниками ООО
ПромТрансИнформ в устной форме, получение необходимой документации в
электронном виде.

4. Моделирование «AS IS» (как есть), описание подхода. выбор и
обоснование типов диаграмм, используемых для описания бизнес-процесса
средствами ARIS

Каждое предприятие имеет структуры, правила и документы, которые
составляют основу для исправного функционирования корпоративных процедур и
должны быть интегрированы с новой системой управления качеством. Анализ
«Как есть» предполагает исследование внедряемого стандарта с учетом
спецификации компании. Цель такого анализа — выяснение требований стандарта, и
в какой мере они затрагивают конкретные аспекты деятельности компании. На этом
же этапе в рамках компании проводится инвентаризация документов и информационных
систем, имеющих отношение к качеству.

Для моделирования процессов ООО «ПромТрансИнформ» будем использовать
следующие диаграммы:

·   Organizational chart — описание организационной структуры отдела.

·        Knowledge map — отображение типов знаний работников ПТИ и
структуризации форм их хранения для определения возможностей, которыми они
располагают.

·        Authorization map — описание полномочий работников.

·        Informational carrier diagram — описание документов для удобства описания
процессов, происходящих в отделе.

·        Function Tree — разделение функций, выполняемых отделом, на уровни
для более наглядного представления деятельности отдела.

·        Function allocation diagram — описание объектов, окружающих функцию, для
наглядного представления сложной функции.

·        Communication diagram — представление взаимодействий организационных
единиц, для описания выполнения всего процесса производства.

·        Risk diagram — для описания рисков, возникающих в процессе
деятельности.

·        Product/Service Tree — для
структурирования продуктов, полученных в результате деятельности отдела.

·        Technical resources model — для описания технических ресурсов, используемых в
отделе.

·        Value-added chain diagram — описание процессов отдела,
влияющих на качество функционирования. Для описания видов деятельности ПТИ,
создающих добавленное качество выпускаемой продукции.

·        Event-driven process
chain diagram — описание действий в рамках бизнес-процесса. Для
наглядного представления процессов, выполняемых отделом.

5. Соглашения по моделированию

Цель проекта по моделированию совпадает с целью курсового проекта и
представлена во введении. В донной работе рассмотрены модели «AS IS» (как есть) и «AS TO BE» (как должно быть). Способ
моделирования — сверху вниз.

Рассмотрено моделирование на следующих уровнях абстракции: типовые
бизнес-процессы и экземплярные бизнес-процессы.

Рассмотрены модели, относительно исходных данных: описание требований,
описание полномочий, должностные инструкции, услуги компании, функции
сотрудников.

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

процессы верхнего уровня, к которым относятся диаграммы Organizational chart- Организационная структура ПТИ, Technical resources model — Технические ресурсы, Product/Service Tree -Продукты и
услуги ПТИ

подпроцессы, к которым относятся диаграмма Informational carrier diagram — Документы ПТИ

сценарии процессов, к которым относятся диаграмма Authorization map — Полномочия бизнес-аналитика

процедуры (операции), к которым относятся диаграммы Event-Driven Process
Chain , Knowledge map — Карта знаний бизнес-аналитика, Function allocation diagram — Окружение функции — процесс модернизации ИАС
«Транспортная работа» под клиента, Value-added chain diagram — Процедуры для процесса участия в конкурсе.

В предыдущем разделе были перечислены виды диаграмм, которые представлены
в курсовой работе. Элементы этих диаграмм детально описаны в соглашении по
моделированию.

5.1 Глоссарий терминов проекта

Соглашение по моделированию определяет трактовку следующих терминов,
используемых в проекте (таблица 5.1):

Таблица 5.1 — Глоссарий

Термин (рус.)	Термин (англ.)	Определение
Функция	Function	Действия сотрудников, выполняемые при появлении заданного комплекса условий (событий) и направленные на получение требуемого результата.
Событие	Event	Отражение изменения состояния внешней или внутренней среды, выражающееся в наборе документов, принятых решениях, наступлении определенного срока и пр. Является результатом выполняемого действия, а также необходимостью выполнения одного или нескольких следующих действий. В отличие от функций, которые отражают процесс, протекающий во времени и имеющий определенную длительность, события происходят в одной точке во времени.
Бизнес-процесс	Business process	Связанный набор повторяемых действий (функций), преобразующих исходный материал и (или) информацию в конечный продукт (услугу) в соответствии с предварительно установленными правилами.
Продукт	Product	Продукт/услуга — результат человеческой деятельности или технологического процесса. Продукт может быть как материальным, так и нематериальным (услуга).

.2 Диаграмма событийно-управляемой цепочки процесса (extended Event-driven Process
Chain, eEPC)

Используемые объекты и их символы представлены в таблице 5.2.1.

Таблица 5.2.1 — используемые объекты

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Событие (Event)		Отображение событий, происходящих при выполнении бизнес-процесса	Имя начинается с имени объекта, состояние или событие по отношению к которому произошло
Носитель информации (Information carrier)		Представление информационного носителя данных в нематериальной форме (напр., на магнитном диске или флеш-памяти)	Именуется названием файла или именем информационной базы данных
Носитель информации (Information carrier)		Представление информационного носителя данных в материализованном виде (напр., на бумаге)	Имя должно содержать наименование документа
Экземпляр функции (Function instance)		Описание экземпляра бизнес-функции в цепочке выполнения бизнес-процесса.	Имя начинается с действия или обозначения процесса, существенные характеристики которого приводятся далее в имени.
Должность (Position)		Представление должности сотрудника организации.	Полное название должности
Прикладная система (Application system)		Представление используемых прикладных систем	Имя содержит название экземпляра прикладной системы

Типы связей, используемых в диаграмме событийно-управляемой цепочки
процесса, представлены в таблице 5.2.2.

Таблица 5.2.2 — типы связей

Тип объекта-источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта-приемника связи
Событие (Event)	Вызывает (activates)	Предназначена для вызова функции	Функция (Function)
Функция (Function)	Создает (creates)	Предназначена для описания создаваемого на выходе события	Событие (Event)
Функция (Function)	Приводит к (leads to)	Предназначена для описания итога выполнения	Правило (Rule)
Правило (Rule)	Вызывает (activates)	Предназначена для вызова функции	Функция (Function)
Правило (Rule)	Приводит к (leads to)	Предназначена для описания итога выполнения	Событие (Event)
Организационная единица (Organizational unit)	Выполняет (executes)	Предназначена для указания подразделения/лица, выполняющего функцию	Функция (Function)
Должность (Position)	Выполняет (executes)	Предназначена для указания подразделения/лица, выполняющего функцию	Функция (Function)
Носитель информации (Information carrier) Функция (Function)	Имеет на входе (Provides input for)	Предназначена для описания документирования функции	Функция (Function)
	Создает на выходе (Creates output to)		Носитель информации (Information carrier)
Прикладная система (Application system)	Поддерживает (Supports)	Предназначена для описания используемой прикладной системы	Функция (Function)

.3 Диаграмма организационной структуры предприятия (Organizational chart)

Таблица 5.3.1 — Используемые объекты

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Организационная единица (Organizational unit)		Обозначение отдельного штатного подразделения.	Полное название подразделения
Должность (Position)		Представление должности сотрудника организации.	Полное название должности

Типы связей, используемых в диаграмме организационной структуры,
представлены в таблице 5.3.2.

Таблица 5.3.2 — типы связей

Тип объекта-источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта-приемника связи
Должность (Position)	является непосредственным руководителем (is disciplinary superior)	предназначена для указания руководителя организационной единицы	Организационная единица (Organizational unit)
Должность (Position)	Организатор для (Is org manager)	предназначена для описания состава организационной единицы	Должность (Position)

5.4 Диаграмма структуры знаний (Knowledge structure
diagram)

Типы объектов, используемых в диаграмме структуры знаний, представлены в
таблице 5.4.1.

Таблица 5.4.1 — типы объектов

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Документированное знание (Documented knowledge)		Объект используется для идентификации формализованного (задокументированного) объема знаний, необходимых для выполнения бизнес-функции.	Полное название документа, содержащего информацию
Категория знаний (Knowledge category)		Представление знаний или умений, которыми должен обладать сотрудник или необходимыми для успешного выполнения бизнес-функции.	Полуформальное определение необходимого объема знаний
Должность (Position)		Представление должности сотрудника организации.	Полное название должности

Типы связей, используемых в диаграмме структуры знаний, представлены в
таблице 5.4.2.

Таблица 5.4.2 — типы связей

Тип объекта-источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта-приемника связи
Должность (Position)	Требует (requires)	Предназначена для описания требуемых знаний для данной должности	Категория знаний (Knowledge category)
Категория знаний (Knowledge category)	Содержит (subsumes	Предназначена для описания документированных знаний, необходимых сотруднику	Документированное знание (Documented knowledge)
Категория умений (Knowledge category)	Содержит (subsumes)	Предназначена для описания умений, необходимых сотруднику	Документированное знание (Documented knowledge)

.5 Диаграмма информационных носителей (Informational carrier diagram)

Типы объектов, используемых в диаграмме, представлены в таблице 5.5.1

Таблица 5.5.1 — Типы объектов

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Носитель информации (Information carrier)		Представление информационного носителя в материальной форме	Имя должно содержать наименование совокупности (картотеки) документов
		Представление носителя информации	Имя содержит название информации

Типы связей, используемых в диаграмме, представлены в таблице 5.5.2.

Таблица 5.5.2 — типы связей

Тип объекта-источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта-приемника связи
Носитель информации (Information carrier)	Включает в себя (encompasses)	Предназначена для структурирования документов организации	Носитель информации (Information carrier)

.6 Карта полномочий (Authorization map)

Типы используемых объектов представлены в таблице 5.6.1.

Таблица 5.6.1 — типы объектов

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Полномочие (Authorization condition)		Представление полномочия для данного сотрудника	Название полномочия
Должность (Position)		Представление должности сотрудника организации.	Название должности

Типы связей представлены в таблице 5.6.2.

Таблица 5.6.2 — типы связей между объектами

Тип объекта-источника связи	Целевое использование	Тип объекта-приемника связи
Должность (Position)	Требует (requires)	Предназначена для описания полномочия	Полномочие (Authorization condition)

.7 Дерево функций

Типы используемых объектов представлены в таблице 5.7.1.

Таблица 5.7.1 — типы объектов

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Функция (Function)		Описание бизнес-функции в цепочке выполнения бизнес-процесса.	Имя начинается с действия или обозначения процесса, существенные характеристики которого приводятся далее в имени.

Типы связей представлены в таблице 5.7.2.

Таблица 5.7.2 — типы связей

Тип объекта-источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта-приемника связи
Функция (Function)	Является процессно-ориентированным вышестоящим (Is process-oriented superior)	Предназначена для описания типа подчиненности функций	Функция (Function)

.8 Диаграмма окружения функции (Function allocation diagram)

Типы используемых объектов представлены в таблице 5.8.1.

Таблица 5.8.1 — типы объектов

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Цель (Objective)		Описание цели процесса	Имя начинается с действия или обозначения процесса, существенные характеристики которого приводятся далее в имени.
Операционный ресурс (Operating resource)		Представление используемых ресурсов	Имя содержит название ресурса
Прикладная система (Application system)		Представление используемых прикладных систем	Имя содержит название экземпляра прикладной системы
Должность (Position		Представление должности сотрудника организации.	Полное название должности
Письмо (мэйл)		Письмо по электронной почте	Имя содержит название прикрепленного письма, отправленного по электронной почте
Носитель информации (Information carrier)		Представление информационного носителя в материальной форме	Имя должно содержать наименование совокупности
Местонахождение (Location)		Место,где находится объект	Имя должно содержать координаты места

Типы связей приводятся в таблице 5.8.2.

Таблица 5.8.2 — типы связей

Тип объекта-источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта-приемника связи
Функция (Function)	Поддерживает (supports)	Предназначена для описания подчиненности функций	Цель (Objective)
Должность (Position)	Отвечает по ИТ за (Is IT responsible for)	Предназначена для описания вклада в выполнение функции данным сотрудником	Функция (Function)
Носитель информации (Information carrier)	Имеет на входе (Provides input for)	Предназначена для описания документирования функции	Функция (Function)
Функция (Function)	Создает на выходе (Creates output to)		Носитель информации (Information carrier)
Прикладная система (Application system)	Поддерживает (Supports)	Предназначена для описания используемой прикладной системы	Функция (Function)
Функция (Function)	Выполняется в (Is executed at)	Предназначена для описания места выполнения функции	Местонахождение (Location)

.9 Диаграмма коммуникаций (Communication diagram)

Типы объектов представлены в таблице 5.9.1.

Таблица 5.9.1 — Типы объектов

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Взаимодействие (communication)		Представление взаимодействия между орг.единицами	Название взаимодействия
Должность (position)		Представление должности сотрудника организации	Полное название должности
Организационная единица (organization unit)		Обозначение отдельного штатного подразделения	Полное название подразделения

Типы связей представлены в таблице 5.9.2.

Таблица 5.9.2 — типы связей

Тип объекта-источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта-приемника связи
Организационная единица (Organizational unit)	Посылает (sends)	Описание взаимодействия между организационными единицами	Взаимодействие (communication)
Взаимодействие (communication)	Получает от (Is received from)		Организационная единица (Organizational unit)
Организационная единица (Organizational unit)	Посылает (sends)	Описание взаимодействия между организационной единицей и должностью	Должность (position)

.10 Модель технических ресурсов (Technical resources model)

Типы объектов представлены в таблице 5.10.1.

Таблица 5.10.1 — типы объектов

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Операционный ресурс (Operating resource)		Имя содержит название ресурса	Используется вид конкретного ресурса

Типы связей представлены в таблице 5.10.2

Таблица 5.10.2 — типы связей

Тип объекта-источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта-приемника связи
Operating resource type	Принадлежит (Belongs to)	Описание принадлежности к виду	Operating resource class

5.11 Дерево продуктов/услуг (Product/Service tree)

Типы используемых объектов представлены в таблице 5.11.1.

Таблица 5.11.1 — типы объектов

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Продукт (Product)		Представление выпускаемой продукции	Имя содержит название продукта

Типы связей представлены в таблице 5.11.2.

Таблица 5.11.2 — типы связей

Тип объекта- источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта- приемника связи
Продукт (Product)	Содержит (subsumes)	Описание структуры выпускаемой продукции	Продукт (Product)

Типы используемых объектов представлены в таблице 5.12.1

.12 Диаграмма рисков (Risk diagram)

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Категория рисков (Risk category)		Представление рисков	Имя содержит полуформальное описание риска
Риск (Risk)

Типы связей представлены в таблице 5.12.2.

Таблица 5.12.2 — типы связей

Тип объекта-источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта-приемника связи
Категория рисков (Risk category)	Содержит (contains)	Описание содержания категории рисков	Категория рисков (Risk category)
Категория рисков (Risk category)	Включает в себя (encompasses)		Риск (Risk)

5.13 Диаграмма цепочки добавленного качества (Value-added chain diagram)

Типы объектов представлены в таблице 5.13.1

Тип объекта рус. (англ.)	Символ с именем по умолчанию (рус./англ.)	Целевое использование	Правила именования
Функция (Function)		Описание бизнес-функции в цепочке выполнения бизнес-процесса.	Имя начинается с действия или обозначения процесса, существенные характеристики которого приводятся далее.

Типы связей представлены в таблице 5.13.2

Таблица 5.13.2 — типы связей

Тип объекта-источника связи	Тип связи рус. (англ.)	Целевое использование	Тип объекта-приемника связи
Функция (Function)	Предшествует (Is predecessor of)	Описание последовательности выполнения	Функция (Function)
	Является процессно-ориентированным вышестоящим (Is process-oriented superior)	Описание типа подчиненности

6. Диаграммы бизнес-модели

.1 Событийно-управляемая цепочка процесса

Рисунок 6.1.1 — Событийно-управляемая цепочка обработки заявки от клиента
(в нотации диаграммы ARIS extended
Event-Driven Process Chain)

.2 Диаграмма организационной структуры ПромТрансИнформ (Organizational chart) представлена на рисунке 6.2

Рисунок 6.2 — Организационная структура ПТИ (в нотации диаграммы ARIS Organizational chart)

6.3 Карта знаний и диаграмма структуры знаний бизнес-аналитика
представлены на рисунках 6.3.1, 6.3.2, 6.3.3

Рисунок 6.3.1 — Карта знаний бизнес-аналитика (в нотации диаграммы ARIS Knowledge map)

Таблица 6.3.1 — Детализация

№	Наименование детализируемого объекта	Тип объекта	Наименование модели	Тип модели
1	Знания	Knowledge category	Знания бизнес-аналитика	Knowledge structure diagram
2	Умения	Knowledge category	Умения бизнес-аналитика	Knowledge structure diagram

Рисунок 6.3.3 — Умения бизнес-аналитика (в нотации диаграммы ARIS Knowledge structure diagram)

Рисунок 6.3.4 — Знания бизнес-аналитика (в нотации диаграммы ARIS Knowledge structure diagram)

6.4 Диаграмма информационных носителей ПТИ представлена на рисунке 6.4

Рисунок 6.4 — Информационные носители ПТИ (в нотации диаграммы ARIS Informational carrier diagram )

.5 Карта полномочий бизнес-аналитика представлена на рисунке 6.5

Рисунок 6.5 — Полномочия бизнес- аналитика (в нотации диаграммы ARIS Authorization map)

.6 Дерево функций для процесса выполнения заказа представлено на рисунке
6.6

Рисунок 6.6 — Дерево функций для процесса выполнения заказа

6.7 Диаграмма окружения функции представлена на рисунке 6.7

Рисунок 6.7. — Окружение функции — Модернизация ИАС «Транспортная работа»
под клиента (в нотации диаграммы ARIS Function
allocation diagram)

.8 Диаграмма коммуникаций представлена на рисунке 6.8

Рисунок 6.8 — Диаграмма коммуникаций — Передача результатов между
отделами (в нотации диаграммы ARIS Communication diagram)

.9 Модель технических ресурсов представлена на рисунке 6.9

Рисунок 6.9 — Технические ресурсы ПТИ (в нотации диаграммы ARIS Technical resources model)

6.10 Дерево продуктов/услуг представлено на рисунке 6.10

Рисунок 6.9 — Продукты и услуги ПТИ (в нотации диаграммы ARIS Product/Service tree)

.11 Диаграмма рисков представлена на рисунке 6.11

Рисунок 6.9 — Диаграмма рисков ПТИ (в нотации диаграммы ARIS Risks diagram)

6.12 Диаграмма цепочки добавленного качества для процесса участия в
конкурсе представлена на рисунке 6.12

Рисунок 6.12 -Процедура цепочки добавленного качества для процесса
участия в конкурсе (в нотации диаграммы ARIS Value-added chain diagram)

7. Документирование бизнес-процесса

При управлении бизнес-процессами, менеджмент компаний сталкивается с тем,
что уровень сложности их управления резко возрастает за счет значительного
увеличения количества объектов в управлении и взаимодействия организационных
структур, а также диверсификации бизнеса, и расширения географии и/или
ассортимента.

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

Таблица 7.1.1 — Результаты обследования ПТИ

№	Должность	Отдел	Функция	Кому подчиняются	Входящая информация	Исходящая информация
1	Бизнес-аналитик	Отдел аналитики	Написание  БП	Гендиректор	пожелания клиента, данные обследования ПП клиента	ТЗ, бизнес-процессы
2	Программист	Отдел разработки	Кодинг ПО	Начальник отдела разработки	БП, пожелания клиента	ПО (программы)
3	Тестировщик	Отдел разработки	Тестирование ПО	Начальник отдела разработки	Готовое ПО	Рабочая программа
4	Гендиректор	Начальник ПТИ	Поиск клиентов, заключение с ними договоров	—-	пожелания клиента,заключенный договор с клиентом	Указания начальнику рабработки
5	Директор	Начальник ПТИ	Соработа вместе с гендиректором	Гендиректор	пожелания клиента, заключенный договор с клиентом	Указания гендиректора
6	Разработчик	Отдел разработки	Проекти-рование архитектуры ПО	Начальник отдела разработки	БП, пожелания клиента	Сформированная архитектура
7	Веб-разработчик	Отдел разработки	Програм. для веб на стороне клиента и сервера, конфигурирование веб-сервера, верстка	Начальник отдела разработки	БП, пожелания клиента	Конфигурированный сервер,веб-сервер
8	Начальник отдела разработки	Отдел разработки	——	Гендиректор	Задание от директора	Указания подчиненным

Уточненный список процессов и их владельцев представлен в таблице 7.1.2.

Таблица 7.1.2 — список процессов и их владельцев

№	Процесс	Тип	Владелец	Входящие подразделения и должностные лица
1	Производство	Основной	Гендиректор,директор
2	Обеспечение IT	Основной	Начальник отдела разработки	Отдел разработки
3	Контроль качества	Основной	Тестировщик	Отдел разработки
4	Управление организацией	Вспомогательный	Гендиректор,директор	Гендиректор, директор
5	Хранение данных	Вспомогательный	Бизнес-аналитик	Отдел аналитики

Итого, в отделе выделено 5 процессов. Из них 3 основных и 2
вспомогательных.

Документирование процесса производства представлено в таблице 7.1.3.
Таким образом, при внесении необходимых изменений в процесс и его модель, в
выходном документе не будет тех ошибок в логике и расстановке полномочий
структурных подразделений, присутствующих при ручном подходе.

Например, при внесении изменений в процесс, в ARIS новые функции необходимо отразить на соответствующем
БП указанием ответственного подразделения и соответствующего пользователя.

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

Таблица 7.1.3 — Процесс производства

№	Функция	Должность	Подразделение	Входящая информация	ИС
1	Согласование условий с заказчиком	Директор	начальство	Условия заказчика	—
2	Заключение договора	Гендиректор	начальство	Техническое задание	—
3	Информирование сотрудников о заказе	Директор	начальство	Заказ на автоматизация (мэйл)	MS Office
4	Описание и документирование БП	Бизнес-аналитик	Отдел аналитики	Комплект документов БП	ARIS
5	Проектирование архитектуры ИС	Разработчик	Отдел разработки	Технологические инструкции, данные об архитектуре данных заказчика, комплект документов БП, требования к ПО	—
6	Кодирование ПО	Программист или веб-программист	Отдел разработки	Комплект документов БП, Лицензия на ПО	Visual Studio
7	Тестирование ПО	Тестировщик	Отдел разработки	ИС заказчика	—
8	Внедрение ИС	Разработчик	Отдел разработки	Заключение по внедрениию ИС	—

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

8. Анализ бизнес-процесса

Анализ процессов следует понимать в широком смысле: в него включается не
только работа с графическими схемами, но и анализ всей доступной информации по
процессам, измерения их показателей, сравнительный анализ и т. д.  Существует
как качественный анализов ,так и количественный анализ бизнес-процессов. Начнем
с качественного анализа процесса. Выделение проблемных областей — простейшее
средство качественного анализа процесса. Основное назначение этого способа
анализа состоит в том, чтобы определить направления дальнейшего более
углубленного анализа. На рисунке 8.1 показаны четыре проблемные области.

Первая из них связана с планированием работы, вторая — с выполнением
заказов, третья — со взаимодействием с клиентами, четвертая — со
взаимодействием с кадрами. Приводятся краткие формулировки проблем для каждой
проблемной области.

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

Рисунок 8.1 -Проблемные зоны ПТИ

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

Именно этот процесс подробно представлен на диаграмме (рисунок 6.1.1).

Так как данный процесс имеет проблемы, это надо реструктурировать.

До модернизации процесс выглядел следующим образом: после заключения
договора с клиентом, гендиректор ПТИ передавал руководство над проектом
менеджеру проекта (рис. 8.2 ).

Но в случае возникновения каких — либо вопросов, менеджер проекта был
вынужден обращаться к гендиректору, чтобы тот отзвонился клиенту и уточнил всю
необходимую информацию. Зачастую это бывало крайне неудобно, так как
гендиректор постоянно в командировках, и не всегда можно было с ним созвонится.

Поэтому менеджеру проекта постоянно приходилось ждать гендиректора, чтобы
уточнить информацию.

Следовательно, сотрудники ждут дальнейших указаний, и работа перестает
двигаться.

Рисунок 8.2 -Процедура выполнение заказа до устранения «узкого места» (в
нотации диаграммы ARIS extended Event-Driven Process Chain)

Теперь процесс выглядит так: после заключения договора с клиентом,
гендиректор ПТИ передает руководство над проектом менеджеру проекта (рис. 8.3).

Передается не только руководство, но и все данные о клиентах (их телефлны
и т.д.).

Теперь ожидать гендиректора не нужно (он может работать спокойно,
заключать новые договоры),а менеджер проекта сам ведет всю работу. В приложении
А должностная инструкция бизнес-аналитика.

Рисунок 8.3 — Процедура выполнение заказа после устранения «узкого места»
(в нотации диаграммы ARIS extended
Event-Driven Process Chain)

Для того, чтобы посчитать, на сколько эффективна модернизация процесса,
рассчитаем KPI (см. глоссарий).

Требования к системе KPI:

·      каждый показатель должен быть четко
определен;

·              показатели и нормативы должны быть
достижимы: цель должна быть реальной, но в то же время являться стимулом;

·              показатель должен быть в сфере
ответственности тех людей, которые подвергаются оценке;

·              показатель должен нести смысл;

·              показатели могут быть общими для всей
компании, т. е. «привязаны» к цели компании, и конкретными для каждого
подразделения, т.е. «привязаны» к целям подразделения.

Проведем анализ задержек во времени (за какое время
выполнялся заказ до модернизации процесса и после) (таблица 8.1). Расчеты
берутся на один заказ.

Таблица 8.1 — Анализ задержек во времени

i	Actual, ч	Plan,ч	qiплан	qiфакт	Вес, wi	qiп*wi	qiф*wi
Уточнение информации у клиента	11,00	4,00	100,00%	275,00%	0,29878	29,88%	82,16%
Написание БП	20,00	18,00	100,00%	111,11%	0,273762	27,38%	30,42%
Кодинг	30,00	25,00	100,00%	120,00%	0,203252	20,33%	24,39%
Тестирование ИС	7,00	6,00	100,00%	116,67%	0,224205	22,42%	26,16%
Внедрение ИС	10,00	9,00	100,00%	111,11%	0,176441	17,64%	19,60%
Интегральная оценка степени достижения цели							163,13%
Плановая интегральная оценка степени достижения цели						100,00%

Итого эффективность от модернизации (KPI) составляет 63,13%.   Данные анализа БП по
результатам отчета анализа модели процесса «БП выполнения заказа (eEPC)»
представлены в таблице 8.2.

Таблица 8.2 — Отчет по результатам анализа модели процесса «БП выполнения
заказа (eEPC)»

Наименование показателя	Значение показателя по результатам анализа модели на итерации
	1	2
Number of functions Количество функций	9	9
Total allocated application system elements Общее количество используемых элементов прикладных систем	6	4
Application systems В том числе прикладных систем	2	0
Application system types В том числе типов прикладных систем	2	4
Computer В том числе компьютеров	0	0
Application system class В том числе классов прикладных систем	2	0
Functions with application system elements in % Всего функций, поддерживаемых элементами прикладных систем, в %	77,78	100
Functions with application system in % В том числе поддерживаемых прикладными системами, в %	22,22	0
Functions with application system type in % В том числе поддерживаемых типами прикладных систем, в %	33,33	100
Functions with computer in % В том числе поддерживаемых компьютерами, в %	0	0
Functions with application system class in % В том числе поддерживаемых классами прикладных систем, в %	33,33	0
Number of function transitions Количество переходов функций (пар функций, каждая из которых поддержана хотя бы 1 элементом прикладных систем)	8	10
Application system breaks Количество переходов функций с разрывами элементов прикладных систем	6	0
Relationship between application system breaks/function transitions Коэффициент, отражающий степень интеграции информационных систем (0…1 ® min)	0,75	0

Для генерации отчетности из системы ARIS используются скрипты отчетности
— программы, набор специальных команд, которые выполняются системой ARIS, и в
результате выполнения которых формируется файл отчета или изменяется наполнение
базы данных ARIS (атрибуты).

Скрипт открывается для редактирования только в ARIS, и применение других
редакторов для его просмотра и изменения невозможно. Помимо простого вывода
информации, содержащейся в базе данных ARIS, с помощью скриптов возможно
проводить анализ всей совокупности моделей и объектов, обрабатывать статистику
и выполнять любые другие действия, необходимые для документирования и анализа
созданных моделей.

Заключение

При
выполнении данной работы была рассмотрена архитектура ARIS,ее достоинства и недостатки, а также другие
методилогии анализа и проектирования (SADT, IDEF0, IDEF3,UML),также
и их плюсы и минусы.

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

Также был модернизирован процесс организации рабочего процесса, так как
он напрямую связан с взаимодействием с клиентами.

Как было уже сказано, этот процесс тормозит работу всей компании и
соответственно влияет на прибыль организации. Модернизация этого процесса была
связано с ликвидацией функции «Сообщить о необходимости уточнения информации у
клиента», так как теперь нет необходимости обращаться к гендиректору, чтобы тот
связал с клиентом и уточнил нужную информацию. Теперь всеми организационными
делами проекта (заказа) занимается сам менеджер проекта. Также был посчитан
коэффициент эффективности (KPI),
эффективность составила 63,13%. Результаты анализа процесса представлены в
отчете. Процесс документирования проанализирован в разделе 7.

Глоссарий

1) KPI (кей пи ай) (key performance indicator)
— это ключевой показатель эффективности. Они позволяют оценить эффективность
выполняемых действий. Применять KPI можно как для оценки работы всей компании,
ее отдельных подразделений так и конкретных работников. С помощью системы KPI
можно не только контролировать и оценивать эффективность выполняемых действий,
но и построить эффективную систему оплаты труда.

Список источников

1.  Август-Вильгельм Шеер. Бизнес-процессы. Основные понятия.
Теория. Методы

2.      Август-Вильгельм Шеер. Моделирование бизнес-процессов

.        Войнов И.В., Пудовкина С.Г., Телегин А.И.
Моделирование экономических систем. Опыт построения ARIS-моделей. Монография

.        Елиферов В.Г., Репин В.В. Бизнес-процессы.
Регламентация и управление

.        Тельнов Ю.В. Реинжиниринг бизнес-процессов (Учебное
пособие)

.        Хаммер М, Чампи Дж. Реинжиниринг корпорации —
Манифест революции в бизнесе

.        Справочник ARIS 6 methods

.        Документы «ПромТрансИнформ» (орг.структура
предприятия, орг.структура ЦКР, должностная инструкциябизнес-аналитика)

9.  Брусакова И. А.http://10.242.45.114/cgi-bin/irbis64r_01/cgiirbis_64.exe?Z21ID=&I21DBN=BOOK&P21DBN=BOOK&S21STN=1&S21REF=3&S21FMT=fullwebr&C21COM=S&S21CNR=20&S21P01=0&S21P02=0&S21P03=M=&S21STR=
Информационные системы и технологии в экономике : учеб. пособие для вузов по спец.
«Прикл. информатика» (по обл.) / И. А. Брусакова, В. Д. Чертовской. —
М. : Финансы и статистика, 2007. — 351 с.

Приложение

Утверждаю

ООО “ПромТрансИнформ”                          
Замятин И.Н

                                                                  (Фамилия,
инициалы)

(наименование организации)                        (директор)

.05.2014г.

ДОЛЖНОСТНАЯ ИНСТРУКЦИЯ

БИЗНЕС-АНАЛИТИКА

(наименование учреждения)

08.05.2014г. №20

. Общие положения

1.1.Настоящая должностная определяет права,
ответственность и должностные обязанности бизнес-аналитика ООО “ПромТрансИнформ”

                                                                  (далее
«предприятие»).

.2.Бизнес-аналитик принимается на работу и увольняется
по приказу руководителя организации по представлению начальника отдела.

.3.Бизнес-аналитик находится в подчинении у начальника
отдела.

.4.На должность бизнес-аналитика принимается лицо с
высшим образованием в области экономики, математического анализа и опыт работы
в аналогичной должности не менее двух лет.

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

.6.В своей деятельности бизнес-аналитик
руководствуется действующим законодательством, касающимся его деятельности:

-стандартом организации по регламентации, описанию, и
внутреннему аудиту бизнес-процессов;

утвержденным действующим описанием системы
бизнес-процессов организации;

приказами и распоряжениями руководства организации по
вопросам анализа и оптимизации бизнес-процессов, а также касающиеся общей
организации деятельности сотрудников компании;

правилами внутреннего трудового распорядка;

нормами и правилами охраны труда;

правилами пожарной безопасности;

данной должностной инструкцией.

.7.Бизнес-аналитик должен знать:

Федеральный закон от 27 декабря 2002 г. № 184-ФЗ «О
техническом регулировании»;

ГОСТ Р ИСО 9004-2001 «Системы менеджмента качества.
Рекомендации по улучшению деятельности»;

ГОСТ Р ИСО 9001-2001 «Системы менеджмента качества.
Основные положения и словарь»;

ГОСТ Р ИСО 9001-2001 «Системы менеджмента качества.
Требования»;

основы теории организации;

основы управления персоналом;

основы маркетинга и менеджмента;

основы логистики;

основы рыночной экономики;

правовые аспекты бизнес-анализа и управления проектами;
— основы законодательства об интеллектуальной собственности;

внутрикорпоративное бюджетирование и управленческий
учет;

контроллинг;

локальные нормативные акты организации, ее стратегию;

структуру компании, направления ее деятельности,
распределение обязанностей между высшими должностными лицами компании;

действующую утвержденную бизнес-процессную модель
функционирования компании;

современное программное обеспечение;

возможности применения программных продуктов для
выполнения работ по анализу и оптимизации бизнес-процессов;

правила оформления и проведения презентаций;

персональный компьютер на уровне опытного
пользователя;

этику делового общения;

инструкции и положения, определяющие порядок
взаимодействия подразделений компании;

стандарты предприятия по описанию, регламентации и
внутреннему аудиту бизнес-процессов;

приказы и распоряжения руководства организации по
вопросам анализа и оптимизации бизнес-процессов;

передовой зарубежный и отечественный опыт
совершенствования системы менеджмента организаций;

нормы и правила охраны труда;

правила пожарной безопасности.

.8. Бизнес-аналитик должен уметь:

использовать в работе программы графического
отображения аналитической информации;

пользоваться корпоративными базами данных.

. Должностные обязанности

Бизнес-аналитик обязан:

.1.Составлять план интервью и перечень ресурсов,
необходимых для проведения моделирования новых бизнес-процессов.

.2.Подготавливать календарные планы работ по
моделированию, анализу и оптимизации бизнес-процессов и его согласование с непосредственным
руководителем и руководством организации.

.3.Проводить процедуры обследования бизнес-процессов.

.4.Осуществлять моделирование, оптимизацию и анализ
бизнес-процессов с использованием принятых в организации инструментальных
средств моделирования.

.5.Формировать общий аналитический отчет после
проведения анализа бизнес-процессов в виде аналитических таблиц и текстовых
комментариев.

.6.Разрабатывать структуру критериев оценки
эффективности моделируемых бизнес-процессов и функций.

.7.Осуществлять подготовку рекомендаций по внедрению
оптимизированных бизнес-процессов и изменению организационной структуры.

.8.Контролировать процесс внедрения изменений в КИС, в
соответствии с оптимизированными бизнес-процессами.

.9.Осуществлять описание оптимизированных
бизнес-процессов.

.10.Участвовать в написании технического задания на
внесение изменений в КИС в соответствии с оптимизированными бизнес-процессами.

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

.12.Эффективно выполнять все возложенные на него
обязанности.

.13.Своевременно предоставлять достоверную информацию,
касающуюся анализа протекающих в организации бизнес-процессов, их оптимизации.

.14.Контролировать соблюдение плановых сроков и прочих
условий выполнения возложенных на него проектов.

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

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

.17.Проводить презентацию результатов работы по
оптимизации бизнес-процессов.

.18.Принимать участие в проведении обучения
сотрудников компании работе в инструментальной среде моделирования
бизнес-процессов, в условиях оптимизированных бизнес-процессов.

.19.Проходить обучение и повышение квалификации
согласно плану, разработанному в организации.

.20.Предлагать рекомендации по внедрению новых
технологий оптимизации бизнес-процессов. 

.21.Разрабатывать демонстрационные материалы,
требующиеся для проведения презентации бизнес-процессов.

.22.Осуществлять обеспечение презентации необходимыми
информационными материалами, программными и техническими средствами.

.23.Обеспечивать выполнение политики компании в
области качества в рамках своей компетенции.

.24.Обеспечивать функционирование в компании системы
управления качеством в рамках своей компетенции.

.25.Самостоятельно определять необходимость и
осуществлять корректирующие и предупреждающие мероприятия в рамках настоящей
инструкции.

.26.Соблюдать все требования, прописанные в
нормативных и методических документах, регулирующих сферу профессиональной
деятельности.

. Права

Бизнес-аналитик вправе:

.1.При возникновении необходимости выезжать в
служебные командировки.

.2.Осуществлять информационное взаимодействие со всеми
должностными лицами всех структурных подразделений организации.

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

.4.Запрашивать и получать от должностных лиц компании
необходимые материалы и документацию, относящуюся к протекающим
бизнес-процессам.

.5.Получать в установленном порядке от должностных лиц
компании отзывы (рецензии) на вновь разрабатываемые документы, относящиеся к
бизнес-процессам, в которых они задействованы.

. Ответственность

Бизнес-аналитик ответственен за:

.1.Несвоевременное представление сведений и
отчетности, установленной в организации. 

.2.Несоблюдение Правил внутреннего трудового
распорядка.

.3.Несоблюдение правил техники безопасности, охраны
труда и противопожарной безопасности.

.3.Невыполнение или недолжное выполнение своих
должностных обязанностей, предусмотренных настоящей должностной инструкцией.

.4.Предоставление своему руководителю и руководству
организации недостоверной информации о соответствии качества бизнес-процессов,
протекающих в организации, установленным соответствующим показателям.

.5.Разглашение информации, являющейся коммерческой и
иной охраняемой законом тайной.

.6.Причинение предприятию материального ущерба.

Руководитель

структурного подразделения: _____________ 
__________________

                                               (подпись)  
(фамилия, инициалы)

.05.2014г.

С инструкцией ознакомлен,

один экземпляр получил: _____________ 
__________________

                                               (подпись)  
(фамилия, инициалы)

Примеры бизнес-процессов в организации

На данной странице представленны готовые примеры бизнес-процессов.
Моделирование данных примеров бизнес-процессов производилось в Дизайнере BPM-системы ELMA

Работа службы поддержки

В модели бизнес-процесса «Служба поддержки» запрос регистрируется из различных источников. С целью рационального использования рабочего времени сотрудников запросы типизируются. К примеру, в IT-компании адресатом может выступить как тестировщик, так и разработчик. Пример моделирования бизнес-процесса работы службы поддержки в системе ELMA BPM:

Попробуйте моделировать бизнес-процессы в Low‑code
BPM-системе ELMA365

Согласование бюджета

Пример описания бизнес-процесса «Согласование бюджета», подразумевает реализацию параллельных шлюзов, между различными департаментами и бухгалтерией/отделом планирования. Локальные подразделения в контексте должны независимо друг от друга огласить свои потребности на ближайший год (квартал).

Поиск нового сотрудника отделом кадров

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

Попробуйте моделировать бизнес-процессы в Low‑code
BPM-системе ELMA365

Заказ билетов через туроператора

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

Проверка работы оборудования

Процесс «Проверка работы оборудования» начинается в зоне ответственности Продавца, который вносит заявку на проверку, а далее, после проверки Инспектором и Начальником ТО, заявка отправляется как задача на ремонт. Продавец оповещается о результатах проверки и ремонта.

Больше примеров описания бизнес-процессов компаний можно найти и скачать бесплатно в магазине готовых решений ELMA Store

Попробуйте моделировать бизнес-процессы в Low‑code
BPM-системе ELMA365

Моделирование бизнес-процесса на примере процесса опробования и клеймения ювелирных изделий

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

1. Описание деятельности госинспекции

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

• осуществляет опробование, анализ и клеймение государственным пробирным клеймом всех ювелирных и других бытовых изделий из драгоценных металлов отечественного производства, а также указанных изделий, ввезенных на территорию Российской Федерации для продажи;

• проводит экспертизу оттисков государственных пробирных клейм, контрольные анализы и техническую экспертизу драгоценных металлов и продукции из них, а также лома и отходов драгоценных металлов, экспертизу и диагностику драгоценных камней, экспертизу по постановлениям органов дознания, следователя, прокурора, суда и арбитражного суда;

• проводит экспертизу музейных и архивных предметов, изготовленных из драгоценных металлов и драгоценных камней, а также контроль за обеспенением сохранности указанных предметов;

• обеспечивает постоянный государственный контроль за производством, извлечением, переработкой, использованием, хранением и учетом драгоценных металлов и драгоценных камней в организациях;

• осуществляет государственный контроль при вывозе из Российской Федерации и ввозе в Российскую Федерацию драгоценных металлов в соответствии с порядком.

Бизнес-стратегия госинспекции направлена на выполнение текущих задач, т.е. на выполнение текущих функций в соответствии с законодательством.

Финансово-хозяйственная деятельность характеризуется двумя основными составляющими: сбор государственной пошлины (далее госпошлина) за совершение действий при осуществлении федерального пробирного надзора и исполнением сметы расходов.

2. Управление бизнес-процессами в организации

Бизнес-направления госинспекции можно выделить следующим образом.

Все бизнес-процессы госинспекции делятся на основные, бизнес-процессы управления и обеспечивающие бизнес-процессы. Дерево бизнес-процессов представлено ниже.

Для построения модели выбирается один из основных процессов —  «Опробование, анализ и клеймение государственным пробирным клеймом ювелирных и других бытовых изделий из драгоценных металлов».

3. Описание процесса опробования и клеймения

Приведем краткое понятие опробование и клеймения и его сути.

Государственное пробирное клеймо — это специальный знак, который чеканится на изделиях различными способами (или накладывается немеханическим способом: электроискровым или с помощью лазера) государственными инспекциями пробирного надзора.

Государственное пробирное клеймо — знак гарантии, осуществлённого, в интересах покупателя, государственного контроля. Наличие оттиска клейма означает, что изделие проверено в госинспекции, и имеет пробу не ниже, указанной в пробирном клейме. В государственное пробирное клеймо входит именник (клеймо изготовителя), а также знак удостоверения, знак пробы, и шифра госинспекции, которые могут проставляться как вместе (в одном контуре), так и раздельно.

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

Перед операцией клеймения производится операция опробования изделий. Проба сплавов благородных металлов, из которых разрешается изготовлять ювелирные и другие изделия, устанавливается законодательным путём и гарантируется государством. Анализ изделий и сплавов  (в том числе экспертиза), изготовленных из драгоценных металлов, обычно проводят:

• на пробирном камне, с помощью пробирных игл (эталонный образец) и реактивов и (или) рентгенофлуоресцентным (РФА) способом, которые позволяют опробовать изделие, не разрушая его;

• методом купелирования, электрохимическим методом анализа, которые основаны на выделении из образца сплава чистого драгоценного металла, по которому определяют количество драгоценного металла в сплаве (целостность изделия при этом нарушается).

• методом потенциометрического титрования.

За совершение действий при осуществлении операций по клеймению начисляется государственная пошлина (далее – госпошлина) в размере, установленном законодательством. Госпошлина уплачивается плательщиков в доход федерального бюджета. Госинспекция является администратором доходов при начислении и поступлении госпошлины.

4. Модель бизнес-процесса

Владелец процесса – главный пробирер госинспекции. Хоть в процессе и участвуют другие подразделения, но это лицо несет полную ответственность за процесс и наделено полномочиями в отношении этого процесса, так как имеет наибольшую компетентность и профессиональные знания.

Первичный вход – поступление от сдатчика ювелирных изделий (далее – клиент) заявления на прием изделий.

Первичный выход —  выдача изделий клиенту после совершения всех необходимых действий.

Первичный поставщик и он же первичный потребитель —  сдатчик ювелирных изделий.

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

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

Исполнители процесса — приемщик на приеме изделий, пробирер, осуществляющий опробование и клеймение, лаборант, бухгалтер.

Ресурсное окружение процесса – документы (квитанции установленной формы для учета операций по опробованию и клеймению), данные (программное средство для учета работ, начисления госпошлины, учета уплаты госпошлины), технические ресурсы (оборудование для проведения операций по опробованию и клеймению), материальные ресурсы (хим.реактивы).

Метрика процесса – размер начисленной госпошлины.

Функционирование процесса происходит следующими этапами:

1. на приеме изделий пробирер принимает от клиента заявление, в котором указаны наименование изделий и(или) их вес и количество, и сами изделия;

2. при совпадении данных, указанных в заявлении, пробирер оформляет три экземпляра квитанции, которая является бланком строгой отчетности и имеет свой номер, одинаковый на все трех экземплярах. Первый экземпляр квитанции передается клиенту. Одновременно с приемом изделий начисляется госпошлина, размер которой фиксируется во всех трех экземплярах квитанций и остается в базе данных инспекции;

3. если заявленное в заявлении количество и (или) масса не совпадают с фактическим наличием, в заявлении клиент делает исправление, и потом происходят действия п.2;

4. изделия вместе с третьим экземпляром квитанции  выдаются исполнителю (пробиреру) в работу, второй экземпляр остается у приемщика;

5. проводятся операции по опробованию. Выбор метода опробования представляет собой отдельный подпроцесс, в данном случае рассматриваться не будет;

6. выявленные в партии изделия, не соответствующие заявленной пробе, клеймятся ближайшей нижней установленной пробой. Изделия, имеющие пробу ниже установленной минимальной пробы, не подлежат клеймению и возвращаются сдатчику в неклейменном виде;

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

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

Модель в нотации BPMN представлена на рисунке.

5. Анализ маршрутных технологических процессов в нотации DFD

Контекстная диаграмма моделирует систему наиболее общим образом и отражает связь (интерфейс) системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана.

Контекстная диаграмма взаимосвязи с внешними системами представлена на рисунке.

Декомпозиция DFD (диаграммы потоков данных) осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня. DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме.

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

Далее проводится процесс декомпозиции нижнего уровня, для примера это процесс приема изделий.

6. Выделение операций в процессе и методика анализа ОТП (операционные технологические процессы) в нотации IDEF0

Под операцией понимается совокупность действий по обработке одного или нескольких ПТ (предметов труда), выполняемых на одном рабочем месте с использованием одного вида оборудования. Под оборудованием понимается как отдельные аппаратные средства, работающие автономно, так и прикладные программные средства, используемые на рабочем месте.

Контекстная диаграмма рассматриваемых процессов представлена на рисунке. При этом входы и выходы данной контекстной диаграммы должны полностью соответствовать потокам данных в контекстной диаграмме нотации DFD.

Далее строится диаграмма декомпозиции рассматриваемых процессов с выделением каждого процесса в отдельную активность.

И диаграмма декомпозиции одного из процессов – приема изделий.

7. Синхронизация процессов обработки и моделирование технологических процессов в нотации IDEF3

В маршрутных технологических процессах (МТП) к недостаткам относят нарушение линейности движения информационных потоков (ИП) (наличие циклов, контуров), поступление на вход активности ИП, который не используется при формировании выходных ИП (транзитный поток); формирование на выходе активности ИП, который не имеет конкретного потребителя и т.п.

В операционных технологических процессах (ОТП) к недостаткам следует отнести отсутствие управления и/или механизмов, использование управления, не соответствующего требованиям к процессу, «жёсткое» управление не соответствующее динамике анализируемого процесса; использование устаревшего оборудования, применение инструмента, не обеспечивающего требуемую точность обработки, отсутствие приспособлений и т.д.

Указанные выше недостатки после выявления могут быть устранены при построении диаграмм DFD и IDEF0 модифицированного процесса TO-BE.

Но что делать, если в процессе анализа МТП и ОТП не найдено недостатков, а процесс выполняется с отклонениями от заданного поведения (плана). Наиболее вероятным ответом может быть следующий – технология рассматриваемого процесса соответствует требованиям, но необходимо провести анализ синхронизации обработки ИП. Задержка одного из материальных или информационных потоков на входе активности может привести к задержке одного или множества выходных объектов и процесс будет отставать от заданного плана поведения, что снижает его эффективность.

Для анализа синхронизации операций обработки предметов труда применяется нотация IDEF3.

Рассматриваем процесс «Клеймение». Контекстная диаграмма в нотации IDEF3 и диаграммы декомпозиции представлены на рисунках.

Факторы, влияющие на синхронизацию рассмотренного процесса:

• результат предыдущего действия является входными данными для следующего;

• начало последующего действия зависит от результатов выполнения предыдущего;

• все действия выполняет один специалист.

Стоит заметить, что декомпозициями чрезмерно увлекаться не нужно, их уровень, как правило, определяется на начальном этапе и может быть изменен в процессе моделирования.

Иллюстрация: Andrea Piacquadio / Pexels / Colowgee для Skillbox Media

Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.

Дипломированный специалист по автоматизации бизнес-процессов. Девять лет опыта в бизнесе и консалтинге. Смоделировал более тысячи процессов для торговых и промышленных предприятий. Основатель OkoCRM.

---

Фото: личный архив Александра Завьялова

Ни один процесс нельзя улучшить, предварительно не описав его. Это касается не только бизнес-процессов больших компаний, но и алгоритмов работы ИП или самозанятых. Прежде чем оптимизировать бизнес-процессы, важно зафиксировать, как они работают, — то есть смоделировать.

О базовых терминах и идеях в области бизнес-процессов мы рассказали в большом гайде. В этой статье разберём подробнее:

• что такое моделирование бизнес-процессов и нотации для моделирования;
• какие есть подходы к моделированию и кто этим обычно занимается;
• как изображают бизнес-процессы;
• как самостоятельно описать бизнес-процессы.

---

Бизнес-процессы — любые операции внутри компании, которые помогают решать бизнес-задачи и зарабатывать. Моделирование бизнес-процессов — описание этих операций и документирование требований к ним.

Ответственные за моделирование разбираются в процессах компании и описывают, кто, что и как делает. Изучают каждую операцию и разбивают её на этапы. Сначала описывают всё это текстом, затем превращают описание в схему.

В профессиональном моделировании бизнес-процессов часто используют нотации. Нотация — это набор правил для графического описания бизнес-моделей. Нотации описывают:

• какие иконки использовать в моделировании и как их читать;
• как отображать последовательность действий в процессе и отношения внутри него;
• какие элементы обязательно нужно включить.

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

Специалисты придумали много вариантов нотаций. Их делят на две основные категории:

• Структурные. Они показывают элементы процесса и взаимосвязи между ними. Это нотации стандарта IDEF: IDEF0, IDEF1x, IDEF4, IDEF5.
• Динамические. Они показывают логику выполнения процессов, последовательность и варианты их использования. Это нотации DFD, EPC, BPMN.

Ниже, когда мы будем говорить о подходах к моделированию, расскажем о двух вариантах нотаций — IDEF0 и BPMN.

С получившейся моделью бизнес-процесса работают дальше. Двигают элементы так, чтобы корректировать продолжительность цикла, влиять на качество результата или снижать себестоимость. Это называется оптимизацией бизнес-процесса — подробнее о ней говорили в статье. Но прежде чем оптимизировать и улучшать, важно провести качественное моделирование.

В моделировании бизнес-процессов есть три основных подхода: функциональный, процессный и ментальный. В следующих разделах разберём их подробнее.

Иногда можно встретить и другие подходы, но обычно это гибридные решения, собранные из основных. Каждый из трёх подходов предполагает, что процессы нужно визуализировать — рисовать их в виде схем. Различия подходов — в принципах визуализации.

При этом подходе описывают результаты, которые нужно получить, и ресурсы, которые при этом будут задействованы, без учёта последовательности действий.

У модели есть точки входа и выхода: то, что имеем на старте, и то, что хотим получить. Внутри — промежуточные результаты, ресурсы и факторы, которые влияют на процесс.

Задача функционального подхода — показать, какие факторы нужно учесть и какие ресурсы задействовать, чтобы процесс состоялся. Подробного описания действий в этом случае не будет, но появится общее представление о процессе.

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

На мой взгляд, функциональный подход понятнее всего реализован в нотации IDEF0. Она рассматривает процесс как совокупность логически связанных между собой работ. Нотация показывает, как объекты подчинены друг другу внутри процесса.

Разберём на примере. Пусть это будет изготовление рекламного ролика.

Процесс изготовления рекламного ролика — основной блок с процессами. Я называю его «чёрный ящик». У него есть три входа и один выход:

1. Сверху — вход для информации о контроле и ограничениях. Это данные, которые определяют условия для реализации процесса. Например, при разработке ролика нас будет ограничивать законодательство и стайлбук заказчика. А ещё мы будем опираться на перечень услуг клиента — чтобы в рекламе были корректные данные.

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

О том, как составить бриф для клиента в рекламе и digital, писали в статье.

3. Снизу — вход для механизма, который будет осуществлять функцию. В примере с роликом это CRM, где хранятся данные о заказчике, и сотрудники телеканала, которые будут снимать ролик.

4. Справа — выходы. Это результаты, которые мы получим: заключим договор, снимем ролик и предложим сотрудничать на постоянной основе.

Вот как функция будет выглядеть в виде диаграммы.

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

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

При процессном подходе описывают не результат, а действия, которые необходимо совершить для достижения результата. Процесс можно детализировать сколько угодно — вплоть до операций каждого сотрудника. Получается блок-схема.

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

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

У процессного подхода есть свои нотации. Стандартом считается BPMN — базовый набор условных обозначений. Его используют для изображения бизнес-процесса в виде блок-схемы.

Нотация BPMN есть в каждом конструкторе для моделирования, но пользоваться ей не обязательно. Гораздо важнее, чтобы схема процесса была читаемой и понятной для руководителя и исполнителей.

Для примера нарисовали блок-схему обработки заявки в учебном центре. Она не соответствует канонам BPMN, но всё равно наглядна и понятна.

Это вариант моделирования «для себя». Его используют, чтобы структурировать общие представления о бизнес-процессе, но не раскладывать его на этапы и не составлять алгоритмов.

При ментальном подходе на процесс смотрят не как на последовательность результатов или действий, а как на набор связанных друг с другом понятий. Обычно их собирают на интеллект-карте: в центре «чёрный ящик» с процессом, на орбите — связанные с ним идеи и элементы. Жёстких рамок и нотаций нет — карты рисуют в произвольной форме.

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

Ниже дан пример ментальной карты процесса снабжения предприятия. На карте собраны понятия, которые связаны между собой внутри процесса. Но по этапам они не распределены.

Обычно моделированием бизнес-процессов занимаются внутренние сотрудники компании или подрядчики. Выбор исполнителя зависит от размеров бизнеса и целей моделирования.

Например, если нужно построить воронку продаж для CRM и при этом нет цели улучшать процессы, можно строить модель можно своими силами. Когда цель моделирования в том, чтобы оптимизировать процессы, лучше обратиться к аналитикам. Для оптимизации нужно глубоко разобраться в процессах и ещё и думать над тем, как их доработать. Потребуется опыт и знание инструментов.

Рассмотрим, кто может заниматься моделированием процессов.

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

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

Подрядчики. В среднем и крупном бизнесе моделировать бизнес-процессы внутренними силами точно не получится — количество и объём всех процессов уже не укладываются в голове собственника.

В этом случае моделированием занимается экспертная группа. В неё входят приглашённые бизнес-аналитики и специалисты, участвующие в моделируемых процессах.

Моделирование как отдельную услугу заказывают редко. Чаще это один из этапов внедрения систем автоматизации — CRM, ECM или ERP. Это работает по такой схеме:

• Команда внедрения — подрядчик — приходит на территорию заказчика.
• Она описывает процессы, проводит аудит и составляет аналитический отчёт с вариантами оптимизации.
• Заказчик утверждает отчёт.
• Подрядчик внедряет систему автоматизации с уже оптимизированными процессами.

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

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

В специальных программах. Это способ для профессионалов в моделировании.

Специальный софт удобен тем, что шаблоны нотаций уже вшиты в него, — не нужно изучать правила иллюстрирования дополнительно. Но придётся разбираться в функциональности программ.

Вот четыре конструктора, которые я использовал в своей практике для моделирования процессов:

• Microsoft Visio 2010 — векторный графический редактор для создания разных видов схем: блок-схем, схем технологических процессов, моделей бизнес-процессов, планов зданий и этажей, трёхмерных карт и так далее. Платный.
• Bizagi Process Modeler — программа для моделирования процессов по нотации BPMN с возможностью совместной работы. Бесплатная.
• ARIS Express — программа для моделирования бизнес-процессов и оргструктуры с нотациями eEPC или BPMN. Бесплатная.
• Business Studio — система, в которой можно описать, оптимизировать и регламентировать бизнес-процессы предприятия. Платная.

Как правило, у всех платных конструкторов есть демоверсии, которых хватает, чтобы смоделировать простой процесс. Но повторюсь, специальное ПО — вариант для профессионалов. Не нужно тратить на него время, если вы не планируете моделировать бизнес-процессы постоянно.

В графических редакторах. Этот способ подойдёт для новичков, которые только знакомятся с моделированием бизнес-процессов. Проще всего взять обычный графический редактор — например, Microsoft Paint, Figma или Adobe Photoshop — и самостоятельно нарисовать интуитивно понятную схему процесса.

Также для изображения бизнес-процессов используют сервисы для создания ментальных карт. На мой взгляд, самые удачные из них — XMind, Diagrams и MindManager.

При выборе сервиса главное, чтобы пользователю было удобно пользоваться им и чтобы было понятно, что получается в итоге. Стандартизация и каноны при этом не так важны. На первых порах для внутреннего использования этот вариант самый доступный.

Покажем, как описать и смоделировать бизнес-процесс, на примере обработки заявки учебного центра. Использовать конструкторы не будем — все модели из примера построим в графическом редакторе.

1. Задаём точки входа и выхода. Вход — первое событие в процессе, выход — результат. Так обозначают границы, чтобы потом наполнить процесс действиями. Нужно определить:

• Когда начинается процесс. В нашем примере это момент получения заявки от клиента. Если компания использует CRM, точкой входа будет попадание заявки в систему.
• Когда процесс закончится. Это момент успешной реализации сделки: клиент оплатил счёт, а продавец и логист организовали доставку.

Можно придумать несколько вариантов точек входа и выхода — для разных вариантов развития события.

2. Описываем элементы. При составлении схемы перед глазами нужно держать основную информацию о процессе, чтобы ничего не забыть. Для этого в любом файле подробно описываем:

• зачем нужен процесс;
• из каких шагов и действий он состоит;
• кто исполнители;
• есть ли ограничения по срокам — сколько времени должен занимать весь процесс и его отдельные шаги;
• какие события сопровождают действия исполнителей — например, обмен документами, информацией, денежные переводы;
• какого результата нужно достичь — например, нужны подготовленные документы или оплата по счёту;
• перечень ресурсов — что исполнителю нужно для реализации процесса;
• показатели эффективности — по каким параметрам отслеживать, достигнута цель процесса или нет;
• детали и особенности отдельных этапов.

Здесь лежит шаблон текстового описания процесса.

3. Выделяем основные этапы процесса. На основе описанного в предыдущем пункте процесса составляем блок-схему. В графическом редакторе рисуем каркас — основные этапы в пределах границ входа и выхода.

4. Добавляем детали. Наполняем каркас «мясом» — основными событиями по процессу и действиями исполнителя по алгоритму.

5. Задаём роли. В процессе может быть несколько исполнительских ролей. Их может выполнять один или несколько сотрудников. Обычно роли обезличены, без уточнения фамилий, — только должности.

6. Наполняем схему ресурсами. Отмечаем на схеме источники ресурсов, которые будут использовать в бизнес-процессе. Например, какие документы кто кому и на каком этапе отправит, какие базы и системы для этого будет использовать.

В нашей «ручной» схеме — это просто дополнительные элементы в алгоритме. Если для моделирования используется специальный софт, к схеме можно прикрепить ссылки.

Блок-схема готова. Если таких схем несколько, их процессы можно связать друг с другом на одной карте.

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

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

Другие материалы Skillbox Media для менеджеров

Эффективный руководитель

Вы научитесь разрабатывать стратегию, ставить цели, создавать бизнес‑процессы и комфортный климат в команде. Найдёте точки роста в своей компании, сможете претендовать на повышение или масштабировать бизнес.

Узнать про курс