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

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

Аннотация

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

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

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

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

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

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

В основном применяется в ПТИ методология 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. Определить события бизнес-процесса. Определить типы событий: начальное, конечное, промежуточное. Привязать промежуточные события к действиям.
5. Определить ресурсы: документы, информацию, и др. потребляемые действиями бизнес-процессов. Привязать ресурсы к действиям.

Схема, иллюстрирующая алгоритм моделирования показана на рисунке ниже:

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

• дополнить существующую модель ответвлениями;
• предусмотреть отдельно действия «альтернативного» процесса.

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

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

Для фиксации бизнес-процессов в графическом виде используется система условных обозначений элементов (нотация). Наиболее известные нотации: SADT/IDEF0, IDEF3, DFD, BPMN, ARIS, UML. Рассмотрение и сравнительный анализ нотации не входит в предмет обсуждения данной статьи; интересующимся в интернете можно найти массу статей на темы сравнения нотаций, например «IDEF vs ARIS».

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

Пример описания бизнес-процесса

Приведем пример описания бизнес-процесса. В качестве примера возьмем процесс предоставления неоплаченного отпуска. Рассмотрим порядок и документооборот, возникающий при указанном выше процессе. Метод сбора информации: законодательство РФ как предварительный материал перед интервью с экспертами предметной области и Владельцем процесса. Нотация описания: ARIS eEPC.

1. Сбор исходного материала.

1.1 Предоставление отпуска регламентируется Трудовым Кодексом (при сборе материала необходимо опираться на последнюю редакцию, на момент написания статьи – с изменениями от 30 декабря 2015 г. № 434-ФЗ), статьей 128 Отпуск без сохранения заработной платы

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

Работодатель обязан на основании письменного заявления работника предоставить отпуск без сохранения заработной платы:

• участникам Великой Отечественной войны — до 35 календарных дней в году;
• работающим пенсионерам по старости (по возрасту) — до 14 календарных дней в году;
• родителям и женам (мужьям) военнослужащих, сотрудников органов внутренних дел, федеральной противопожарной службы, органов по контролю за оборотом наркотических средств и психотропных веществ, таможенных органов, сотрудников учреждений и органов уголовно-исполнительной системы, погибших или умерших вследствие ранения, контузии или увечья, полученных при исполнении обязанностей военной службы (службы), либо вследствие заболевания, связанного с прохождением военной службы (службы), — до 14 календарных дней в году;
• работающим инвалидам — до 60 календарных дней в году;
• работникам в случаях рождения ребенка, регистрации брака, смерти близких родственников — до пяти календарных дней;

 

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

1.2. Документооборот при оформлении отпуска регламентируется постановлением Госкомстата РФ от 05.01.2004 N 1 «Об утверждении унифицированных форм первичной учетной документации по учету труда и его оплаты», раздел «Приказ (распоряжение) о предоставлении отпуска работнику».

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

Составляются работником кадровой службы или уполномоченным им на это лицом, подписываются руководителем организации или уполномоченным им на это лицом, объявляются работнику под расписку. На основании приказа (распоряжения) о предоставлении отпуска делаются отметки в личной карточке (форма N Т-2 или N Т-2ГС(МС)), лицевом счете (форма N Т-54 или N Т-54а) и производится расчет заработной платы, причитающейся за отпуск, по форме N T-60 »Записка-расчет о предоставлении отпуска работнику».

Приводим данные, необходимые для моделирования бизнес-процесса (действуем согласно описанной ранее схеме): 

1. Результат бизнес-процесса — оформленные согласно законодательству РФ и стандартам организации документы. 

2. Владелец бизнес-процесса: руководитель кадровой службы. Как определить владельца? Владелец – это сотрудник, обладающий ресурсами для осуществления бизнес-процесса (в данном случае ресурсы – сотрудники кадровой службы) и несущий ответственность за результат бизнес-процесса.

3. Набор и порядок действий:

написание заявления -> составление приказа -> подписание приказа у руководителя инициатора -> подписание приказа у инициатора –> оформление кадровых документов.

В последовательности действий отсутствует расчет заработной платы, т.к. статья Трудового Кодекса, согласно которой оформляется отпуск, – Отпуск без сохранения заработной платы.

4. Исполнители бизнес-процесса.. Для более наглядного предоставления информации приведем последовательность шагов и исполнителей в таблице:

5. События. Дополним вышеуказанную таблицу информацией о событиях:

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

7. Проведем анализ «что если».

• Что если заявление будет содержать ошибки (начиная от грамматических, заканчивая неправильным указанием реквизитов)? Инициатор заявления не обязан иметь достаточную квалификацию для безошибочного заполнения заявления (а обязан уметь грамотно выполнять свои непосредственные обязанности). Для устранения случая неправильного заполнения заявления добавим действие проверки заявления в основной процесс, т.к. нам важно предотвратить наличие ошибочного документа в процессе.
• Что если приказ на отпуск будет неправильно составлен? Т.к. в обязанности специалиста кадровой службы входит составление кадровых документов, то мы предполагаем, что в большом количестве случаев приказ составляется правильно. Это не отменяет проверку квалификации специалиста кадровой службы (процессы приема на работу и аттестации) и проведение периодической проверки документов (процесс аудита кадровых документов).
• Что если руководитель не подпишет приказ и инициатор:
  • имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос запишем в открытые вопросы по данному процессу и зададим его Владельцу процесса при согласовании процесса. Всю ответственность за исполнение процесса несет Владелец процесса, именно он определяет правила выполнения работы во вверенном ему подразделении;
  • не имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос также запишем в открытые вопросы.

• Что если инициатор откажется подписывать приказ (например, у него изменились обстоятельства, согласно которым он брал отпуск)? Мы прекращаем процесс.
• Что если внесение отметок в кадровые документы Т-2 и Т-54а будет некорректным? Данный вопрос аналогичен вопросу, рассматриваемому в п. 3.2.

Дополним существующую таблицу полученной информацией. Фактически мы получили предварительное описание процесса в табличном виде:

Открытые вопросы

• Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор имеет право на отпуск, согласно 128 статье Трудового кодекса
• Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор не имеет право на отпуск, согласно 128 статье Трудового кодекса

Краткое обозначение элементов нотации ARIS eEPC приведено в таблице ниже (описаны не все элементы нотации, а используемые. Графическое обозначение элементов взято из пакета MS Visio):

Схема, отображающая взаимодействие элементов показана ниже:

Графическое отображение процесса предоставлено выглядит следующим образом:

 

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

Вместо заключения

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

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

— Смотри, бизнес-процессы снижают вариабельность результатов за счет стандартизации операций. Вариабельность означает снижение разброса допустимых вариантов результатов процесса. Я описал простой пример, бизнес-процессы применимы не только к кадровому делу, но и к деятельности организации. Представь себе, что организация, специализирующая на поставке запчастей, будет производить детали с разным уровнем качества (мы помним, что качество – это соблюдение характеристик изделия). Далее автозапчасти будут ставиться на автомобили, и мы получим… продукцию АвтоВАЗа. Продукция АвтоВАЗа находит своего покупателя, но мы в последнее время предпочитаем автомобили качественной сборки.

— Я думаю, все дело в исполнителях. Достаточно найти грамотных исполнителей и мы получим хороший результат. Как в твоем примере – надо найти грамотного кадровика, только и всего.

— Хорошие исполнители, уже обеспечены работой, их труд стоит дорого. Ты не думаешь об оптимизации расходов организации, найма толковых специалистов, и обеспечения специалистов методической поддержкой. Еще один фактор – масштабирование работы. Представим, что в нашей организации работает 2 000 сотрудников. В данном случае у нас будет несколько специалистов кадровой службы и у них будет разный опыт. Наша задача в данном случае – предоставить инструмент обучения, осуществления операций и контроля операций со стороны руководителя подразделения.

— Даже если 2 000 человек и даже если специалисты будут ошибаться. Какова цена ошибки – всего-лишь неправильно оформленные кадровые документы, эти бумажки.

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

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

Автор

Евгений Пономарёв

Evgheny.Ponomarev@ya.ru