Корпоративные информационные системы

1.

ФГБОУ ВО Уфимский государственный авиационный технический университет
Кафедра автоматизированных систем управления
«Корпоративные информационные
системы»
Демченко Марина Сергеевна,
старший преподаватель кафедры АСУ
[email protected]

2.

Введение
• ОРГАНИЗАЦИЯ УЧЕБНОГО ПРОЦЕССА ПО ИЗУЧЕНИЮ ДИСЦИПЛИНЫ «КОРПОРАТИВНЫЕ
ИНФОРМАЦИОННЫЕ СИСТЕМЫ»
• ПОНЯТИЕ «КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ»
• РОЛЬ «КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ» В УПРАВЛЕНИИ ПРЕДПРИЯТИЯМИ
• СОДЕРЖАНИЕ И ЗАДАЧИ ДИСЦИПЛИНЫ «КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ»
• ПРЕДМЕТ И ОБЪЕКТЫ ДИСЦИПЛИНЫ «КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ»
• БАЗОВЫЕ ПОНЯТИЯ, НЕОБХОДИМЫЕ ДЛЯ ИЗУЧЕНИЯ КУРСА «КОРПОРАТИВНЫЕ
ИНФОРМАЦИОННЫЕ СИСТЕМЫ»

3.

Организация учебного процесса по изучению
«Корпоративные информационные системы»
дисциплины Дисциплина
изучается в цикле дисциплин специализации
Виды учебной работы
Общая трудоемкость дисциплины
____ часов
Аудиторные занятия
46 часов
Лекции
20 часов – 10 лекций
Лабораторные работы
24 часа – 6 лабораторных работ
Практические занятия
4 часа – 2 занятия
Самостоятельная работа студентов ____ часа
РГР
____
Форма итогового контроля:
Экзамен (_____ зачетные единицы)

4.

Организация учебного процесса по изучению
информационные системы»
дисциплины «Корпоративные
Лекции - по части лекций необходимо выполнить домашнее задание (письменно от
руки), скан загрузить в определенный срок.
Лабораторные работы - 6 лабораторных работ, одно сквозное задание, разбитое на 3
раздела, каждый из которых необходимо загрузить в определенный период.
Итоговый отчет со всеми разделами, выполненный в соответствии с требованиями
необходимо загрузить в определенный день.
Практические занятия - 2 занятия в виде семинара, защита выполненной работы на
лабораторных.
Самостоятельная работа студентов - список тем на самостоятельную проработку
будет опубликован в разделе "Самостоятельная работа студента«
Форма итогового контроля: Экзамен - для допуска, необходимо сдать итоговый
отчет по лабораторным работам; выступить с докладом на семинаре; выполнить все
домашние задания по лекциям.

5.

6.

Понятие «Корпоративные информационные
системы» КИС - это масштабируемая система, предназначенная для комплексной
автоматизации всех видов хозяйственной деятельности больших и
средних предприятий, в том числе корпораций, состоящих из группы
компаний, требующих единого управления.
КИС
-
ЭТО
ИНТЕГРИРОВАННЫЕ
СИСТЕМЫ
УПРАВЛЕНИЯ,
территориально
распределенной корпорацией, основанные на углубленном анализе данных, широком
использовании систем информационной поддержки принятия решений, электронных
документообороте и делопроизводстве.
КИС
призваны
объединить
стратегию
управления
предприятием
и
передовые
информационные технологии.
КИС - это совокупность технических и программных средств предприятия, реализующих
идеи и методы автоматизации.

7.

Понятие «Корпоративные информационные
системы» Корпоративная информационная система (КИС) – система управления
предприятием (корпорацией), в которой процессы сбора, хранения,
обработки, преобразования, передачи и обновления информации
осуществляются
с
использованием
современной
компьютерной
техники и средств телекоммуникаций.
Назначение КИС:
отражение целостной и максимально объективной картины состояния
дел на предприятии в реальном масштабе времени;
постоянной
поддержке
управления предприятием.
организационно-технологической
модели

8.

Понятие «Корпоративные информационные
системы»

9.

Понятие «Корпоративные информационные
системы»
Указанные на рисунке функциональные приложения приведены в качестве
примера. Их конкретный набор определяется организацией в части целей ИС

10.

РОЛЬ «КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ» В
УПРАВЛЕНИИ ПРЕДПРИЯТИЯМИ

11.

РОЛЬ «КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ» В
УПРАВЛЕНИИ ПРЕДПРИЯТИЯМИ

12.

РОЛЬ «КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ» В
УПРАВЛЕНИИ ПРЕДПРИЯТИЯМИ

13.

РОЛЬ «КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ» В
УПРАВЛЕНИИ ПРЕДПРИЯТИЯМИ

14.

РОЛЬ «КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ
СИСТЕМ» В УПРАВЛЕНИИ ПРЕДПРИЯТИЯМИ

15.

РОЛЬ «КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ»
В УПРАВЛЕНИИ ПРЕДПРИЯТИЯМИ
Ключевыми преимуществами нового флагманского решения фирмы «1С»
являются:
•широкие функциональные возможности на уровне ERP-систем международного класса;
•гибкая и производительная современная платформа «1С:Предприятие 8.3»,
поддерживающая работу через Интернет, в том числе «облачные» технологии и работу
на мобильных устройствах;
•большое количество специализированных решений, расширяющих возможности
системы (PDM, EAM, PMO, ITIL, CRM, MDM, WMS, TMS, BSC, ECM, CPM и др.);
•широкая сеть партнеров с многолетним опытом внедрения ERP-систем;
•невысокая
стоимость владения
и возможность
получения
существенного
экономического эффекта с ростом производительности труда и быстрым возвратом
инвестиций.

16.

РОЛЬ «КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ»
В УПРАВЛЕНИИ ПРЕДПРИЯТИЯМИ

17.

РОЛЬ «КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ
СИСТЕМ» В УПРАВЛЕНИИ ПРЕДПРИЯТИЯМИ
Отраслевые и специализированные ERP-решения:
• 1С:ERP+PM Управление проектной организацией 2
• 1С:Рыбопереработка
• Модуль 1C:PM Управление проектами для 1С:ERP
• 1С:Управление строительной организацией
• 1С:ERP Агропромышленный комплекс 2
• 1C:ERP Энергетика 2
• 1С:Спиртовое производство
• 1С:ERP Управление строительной организацией 2
• 1С:ТОИР Управление ремонтами и обслуживанием оборудования
• Модуль 1С:Аренда и управление недвижимостью для ERP
• 1С:Управление водоканалом
• 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2
КОРП
• 1С:Комбинат ЖБИ
• Модуль 1С:Управление автотранспортом для 1С:ERP
• 1С:Управление металлургическим комбинатом
• 1С:MES Оперативное управление производством
• 1С:Управление мукомольно-крупяным производством
• 1С:PDM Управление инженерными данными
• 1С:Управление переработкой отходов и вторсырья
• Модуль 1С:Аренда и управление недвижимостью для 1С:УПП
• 1С:Управление предприятием ЖКХ
• 1С:Девелопмент и управление недвижимостью
• 1С:Управление проектной организацией
1С:Горнодобывающая промышленность. Управление карьером
1С:Управление производственным предприятием с английским
интерфейсом/1C:ERP English Interface
1С:Лесозавод
1С:Управление птицефабрикой
1С:Ликероводочный и винный завод
1С:Управление ремонтным предприятием
1С:Молокозавод
1С:Управление сельскохозяйственным предприятием
1С:МТО Материально-техническое обеспечение
1С:Управление теплосетью
1С:Мясокомбинат
1С:Управление транспортным предприятием
1С:Пиво-безалкогольный комбинат
1С:Фармпроизводство
1С:Полиграфия
1С:Хлебобулочное и кондитерское производство
1С:Процессное производство. Химия
1С:Энергетика. Управление распределительной сетевой компанией
1С:Риэлтор. Управление продажами недвижимости. ПРОФ

18.

Задание на лабораторные работы

19.

Задание на лабораторные работы
Модуль A. Системный анализ и проектирование
• Блок 1: Проектирование структуры данных; Анализ исходных
файлов данных, спроектировать на их основе структуру данных.
• Блок 2: Импорт данных; Приведение исходных файлов данных к
виду, подходящему для импорта. Импортировать данные в базу
данных.
• Блок 5: Проектирование архитектуры; Создание ERD на основе
анализа предоставленных документов, проектирование
архитектуры программного продукта

20.

Задание на лабораторные работы
Модуль B. Разработка программного обеспечения.
• Блок 3: Программирование; Создание настольного приложения,
различных окон, таблиц, форм.
• Блок 4: Реализация отчетов; Разработка и реализация отчетов,
необходимых пользователям приложений, с графиками и
возможностью вывода на печать.
• Блок 6: Тестирование; Интеграционное тестирование, модульное
тестирование. Разработка тест-кейсов.
• Блок 7: Разработка мобильного приложения; Разработка мобильного
приложения под ОС Android.
• Блок 8: Разработка API; Разработка API, реализация GET и POST
запросов

21.

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

22.

Задание на лабораторные работы
Модуль D. Документирование программного решения.
Блок 10: Документация Создание пакета сопровождающей
документации по разрабатываемой информационной системе.

23.

Задание на лабораторные работы
Модуль E. Презентация программного решения.
Блок 9: Презентация Создание профессиональной презентации,
демонстрирующей информационную систему заказчику, и ее
представление.

24.

Подход системной инженерии
к управлению жизненным циклом
Системная инженерия – это гармонизация подходов:
• системного (назначение, границы и элементы системы)
• процессного (деятельность и акторы)
• архитектурного (методы описания и их группировка)
• жизненного цикла (4D-эволюция системы)
• оценки зрелости процессов (стадии ЖЦ процесса)
• оценки специальных свойств системы (процессные
выписки)
• Подход (approach) - способ Объектового
(сущностного) описания.
27-мара-24
24

25.

Системный подход
• Система имеет:
• назначение, элементы, границу системы с окружением, связи
элементов (в том числе с окружением)
• Описания: полное, включающее архитектурное
• Стейкхолдеров (имеющих к ней интересы)
• процессы, которые с ней выполняются в ходе ее жизненного
цикла
• Система никогда не бывает «вообще», система всегда
конкретна (поэтому слово «система» пишется только в
общетеоретических текстах, употребление слова «система»
вдобавок к названию конкретной системы излишне).
• Примеры систем: АЭС, ГЭС, самолёт, процесс,
информационная модель, подход. Система может
включать людей и организации.
27-мара-24
25

26.

Процессный подход
27-мара-24
• Процесс: деятельность, разделенная на практики
(элементы деятельности, activities), которые выполняют
(ролевые) акторы (actors, agents, «деятели») над/c
системой.
• Процессы выполняются над/с системой (система
эволюци онирует под действием различных процессов –
это и есть ЖЦ)
• В процессах взаимодействуют Акторы (Акторы
организованы). Описать «связи процессов» = нужно
назвать акторов и трансакции между ними (подход
DEMO).
• Виды описаний процессов:
а) as is – для анализа
б) to be – нормы
• процессы состоят из вложенных подпроцессов и
реализуют практики, которые определяют работы
26

27.

Основные понятия и их термины для
метаязыка
По материалам компании FutureModels
Из чего состоит организация?
Что существенно в организации?
27-мара-24
27

28.

Описание процесса (из практик)
Описание группы процессов (из процессов)
Архитектурное
• Опорное
(функция: что и зачем)
• Принципиальное
(конструкция: как)
• Выполняемое
(инструкция: норма)
• Историческое
(измерения, отчеты,
задания, прогнозы)
27-мара-24
28

29.

Внедрить процессы в жизнь
(регламенты на уровне линейных менеджеров, контракты с
внешними организациями)
производство
администриров
ание
ответственность
полномочия
компетенция
•Администрирование – договориться, кто что кому когда делает.
•Производство – делать то, что надо. Не больше, и не меньше.
• Убедиться, что все производство администрируется (то, что надо
делать совпадает с тем, что договорились делать).
•Айтишники не могут прописать правила администрирования (не могут
устанавливать полномочия).
•Айтишники не могут прописать правила производства (не могут задавать
27-мара-24технологию проектирования и строительства).
29

30.

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

31.

Кто хозяин процессов на предприятии? По чьим регламентам жить?
1.
Проектное управление (Primavera).
2.
Процессы/качество – стандарты серии ISO 9000.
3.
Безопасность/качество – ПОКАС, МАГАТЭ.
4.
Заложенные в купленный софт (они там невидимы, но есть)
5.
Особенности работы, определяемые специалистами (технологами).
6.
Расказанные консультантами по реинжинирингу бизнес-процессов.
7.
Стандарты системной инженерии (кто ответственный за их соблюдение?)
8.
Оставшиеся обычаи, происхождение и обоснование которых мало кто помнит.
По материалам компании FutureModels
Айтишники правила работы не устанавливают и не могут настоять на их выполнении, но
почему-то при слове «процесс» всегда зовут их.
27-мара-24
31

32.

Жизненный цикл процесса:
вверх по ступенькам зрелости
(С применением ПЛ модели времени)
4. Практики систематически пересматриваются и
изменяются с целью их улучшения
3. практики описаны, и то, что делается,
определяется этим описанием (дисциплина
исполнения правил)
2. практики используются и описаны
(отрефлектировано, что же именно делается), они
обсуждаемы.
1. Новые практики как-то (ad hoc) используются,
результаты достигаются
27-мара-24
32

33.

ISO 15288: «Что делать»
25 обязательных процессов системной инженерии
Обеспечения
проектов
• управление описанием
жизненного цикла
• управление
инфраструктурой
• управление портфелем
проектов (программой)
• управление персоналом
• управление качеством
27-мара-24
Проектные
управление проектами
планирование
проекта
управление
выполнением и
контроль проекта
поддержка проектов
управление
решениями
управление
рисками
управление
конфигурацией
управление
информацией
измерения
Технические
сбор требований
анализ требований
архитектурный дизайн
изготовление
интеграция
проверка (Verification)
переход к эксплуатации
приёмка (Validation)
эксплуатация
обслуживание
вывод из эксплуатации
33

34.

Разнообразие жизненных циклов
Софт
Оборудование
Идея
Определение
требуемых
компетенций
Персонал
Здание
Концепция
Визуализация
Природный
ресурс
Процесс
Система
Идея
Поддержка
Списание
Проектирование
Изготовление
Эксплуатация и
поддержка
Списание
Приобретение
Обучение
Использование
и рост
Отставка
Эксплуатация
и поддержка
Разборка
Проектирование
сооружения и
площадки
Приобретение
Определение
выхода
Разработка
Согласование
Разработка
Графическое
представление
Описание
Разработка
Изготовление
Строительство
Эксплуатация
Пилотное
внедрение
Рекультивация
Использование и
совершенствование
Использование
Поддержка
Ликвидация
Списание
34

35.

Вариант жизненного цикла
непрерывного производства
по версии ISO 15926
Схема из стандарта ISO 15926-1:2003г. (по схеме Process Industries STEP Consortium 1994г.)
Инженеринговые и производственные процессы
Организационно-функциональные процессы (обеспечивающие, проектные,
технические)
35

36.

Что такое бизнес-процесс и описание
бизнес-процесса
Бизнес-процесс — совокупность взаимосвязанных мероприятий или работ, направленных на создание определённого продукта или
услуги для потребителей. ... business process management) рассматривает бизнес-процессы как важные ресурсы предприятия, и
предполагает управление ими как одну из ключевых организационных систем.
Итак, в чем же разница между бизнес-процессом и функций или даже просто обычным процессом?
Бизнес-процесс – это логическая последовательность действий человека (или нескольких человек) в коллективе. Цель описания бизнес -процесса –
анализ и регламентация тех или иных действий в коллективе.
Бизнес-процесс всегда происходит с участием человека. Если действия выполняются автоматической
системой или программой, это уже не бизнес-, а технологический процесс или спецификация. И тогда в силу
вступают несколько иные стандарты, методы описания и особенности реализации.
1.
2.
В бизнес-процессе всегда задействованы несколько людей в явной или неявной форме. Даже если
человек работает один (например, писатель), все равно у него есть заказчики (издательские агентства) и
потребители (читатели). Также продавец работает не в «вакууме» — у него есть поставщики и покупатели
продукции, и все эти люди также задействованы тем или иным образом в бизнес-процессе.
Бизнес консультант Кинзябулатов Рамиль

37.

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

38.

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

39.

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

40.

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

41.

Для наглядности описание технологического процесса может выглядеть таким
образом:
1. Берем заготовку A;
2. Соединяем ее с заготовкой B;
3. Обрабатываем под параметры C;
4. Получаем деталь.
Все однозначно и никаких условных «вилок» не предусматривается.

42.

В бизнес-процессе вполне нормальной считается следующая ситуация:
1. Получаем вводные данные A:
2. Если данные соответствуют условию B, переходим на последовательность действий
C;
3. Если данные соответствуют условию D, выполняем действия E.
4. Полученный результат передается на выход.
Т.е. уже в алгоритме процесса предусмотрены возможные условия и разные
действия, зависящие от исходных или промежуточных данных.

43.

История появления термина
Например, когда я написал статью об IDEF0, некоторые читатели в качестве примеров нотаций
приводили примеры каких-то инструкций из министерств и ведомств времен Первой Мировой или
даже раньше, а в качестве графического отображения обсуждались схемы и наглядные изображения
военных действий. Но все это не является описанием бизнес-процесса.
Все вышеперечисленное можно назвать методиками, наглядной демонстрацией, инструкциями, но
нельзя назвать нотациями.
Нотации – понятие современное, причем, нотациями называется нечто
устоявшееся, стандартизированное, т.е. набор команд и обозначений,
которыми пользуется много людей, а не одна или две организации. Можно
придумать свой особый язык для описания бизнес-процессов или, например,
программирования. Но пока он не получит «обкатку» в массовом
использовании, не будут выявлены и устранены противоречия, неоднозначные
трактовки, другие недочеты, пока он не стает устоявшимся и привычным для
людей стандартом, называть его нотацией нельзя. Подробнее о нотациях я
планирую написать позже. А сейчас вернемся к вопросу появления термина
«бизнес-процесс».
На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда
повсеместно начали использоваться информационные системы. И сам термин, и нотации
понадобились изначально именно для разработки информационный систем.

44.

Дело в том, что после начала применения информационных систем сложность
организации работы людей в организациях увеличилась во много раз. Кроме того,
машины не понимают абстракции, им требуется строгий алгоритм и определенный
порядок введения и обработки информации. Если до начала автоматизации, когда
информация переходила непосредственно от человека к человеку, проблема
взаимопонимания находилась на уровне человеческих коммуникаций, то теперь
появилась
необходимость
ее
строго
регламентировать.
В результате понадобилось создавать описания работы не только людей в организации,
но также их взаимодействия с информационными системами. И здесь стало
недостаточно текстовых нотаций (инструкций), где все описания были в свободной
текстовой форме, они оказались не актуальны и неудобны. Появилась потребность в
стандартизации, по сути, в создании особого языка команд и однозначной
последовательности действий. Причем, в отличие от машинных языков, эти нотации
должны были стать одинаково удобными для перевода в машинный код, и для
восприятия
человека.
Первые методологически проработанные нотации бизнес-процессов (а я буду говорить
именно о методологически проработанных нотациях, например, IDEF3***) появились у
военных в США. Причина очевидна – уже тогда военные в США пользовались
автоматизацией с использованием удаленных соединений, т.е. той самой системой,
которая позже стала Интернетом. И при таком уровне применения информационных
систем потребность в нотациях бизнес-процессов была особенно актуальной.

45.

***По теме методологически проработанных нотаций хочу также
сказать пару слов. Почему я привел в качестве примера IDEF3: я
еще не видел более проработанной методологически системы
описания бизнес-процессов. Даже BPMN 2.0 все еще развивается и
дорабатывается. А если вы почитаете англоязычное описание
IDEF3 (перевода на русский я пока не видел), то также сумеете
оценить по достоинству глубину его проработки.
Зачем моделировать
(описывать) бизнес-процессы
Как я уже не единожды писал, я работаю
преимущественно с малым и средним бизнесом, где
предоставляю широкий комплекс услуг – от
выявления проблем и «узких мест» в работе
компании до внедрения предложенных мною
решений на уровне программных продуктов и
систем автоматизации.
Бизнес консультант
Кинзябулатов
Рамиль

46.

Моделирование
бизнес-процессов
помогает
решить
сразу
две
задачи:
Изучение бизнеса. Графическое изображение в виде схем, т.е.
моделирование бизнес-процессов позволяет быстрее понять особенности
работы компании и выявить возможные «узкие места».
Обеспечение наглядности. Как известно, «одна картинка стоит тысячи
слов». А потому схематическое изображение работы компании помогает
руководителю и владельцу бизнеса намного быстрее понять суть проблемы и
оценить предложенные варианты решения. В работе бизнес-консультанта
(кстати, как и специалиста по внедрению программных продуктов) очень
важно, чтобы клиент понимал все преимущества решения. Не менее важна и
обратная связь – руководитель на схеме сможет увидеть какие-то недочеты
еще на этапе обсуждения проекта, и внедрение обойдется без дополнительных
сложностей и внесения изменений в проект «на ходу».

47.

Бизнес-процессы необходимы, чтобы представить сложную
информацию в простой для восприятия форме для изучения и
принятия решения.
Как описывать бизнес-процессы
Для того чтобы получить описание реально действующих бизнес-процессов, достаточно просто
внимательно изучить последовательность действий каждого сотрудника. Т.е. необходимо получить
информацию о входящих данных для запуска определенного процесса, исходящих – т.е. результата
действий сотрудника, а также пошагово зафиксировать действия, которые потребовались.
После того, как вся информация собрана, ее нужно перевести в графическую нотацию. Здесь стоит
понимать, что именно графические нотации считаются «хорошим тоном» при составлении описаний
бизнес-процессов. Для себя вы можете составлять нотацию как вам удобнее, текстовые варианты
описаний также существуют и применяются, например, некоторыми разработчиками программного
обеспечения. Но если вы составляете нотацию, которую будут читать другие люди, не важно,
разработчик программы или руководитель компании, выбирайте графику.

48.

Рекомендуемая последовательность действий:
1. Собираем участников процесса (сотрудников);
2. Собираем входящую информацию, необходимую и достаточную для запуска
процесса;
3. Собираем используемые системы. Это может быть учетная система, CRM,
электронная почта, таблицы Excel и т.д. Все, что реально используется в работе,
необходимо зафиксировать.
4. Определяем ожидаемый результат – что будет в конце процесса.
5. Собираем последовательность действий, которые выполняет человек.
6. Вычленяем условия. В зависимости от разных входящих данных и
промежуточных результатов действия могут быть разными.
• Описываем всю собранную информацию в графическом виде в удобной нотации
(IDEF3, BPMN 2.0 и т.д.).

49.

Правила описания бизнес-процесса
Законченность. Бизнес-процесс должен четко отвечать на вопрос, стоящий перед ним. Если мы говорим о
процессе продажи определенного товара или услуги, то бизнес-процесс должен полностью описывать действия,
необходимые для получения указанного результата, и завершающегося именно таким результатом (с
определенными допущениями, о которых я говорил выше).
Лаконичность. Бизнес-процесс должен сочетать в себе достаточность, т.е. описывать все необходимые этапы и
действия, при этом быть максимально лаконичным для простоты восприятия. Лично я вывел для себя «правило
15 минут» — если за этот период времени я могу объяснить руководству компании представленный бизнеспроцесс, значит, его можно показывать заказчику. Получается быстрее – прекрасно, требует больше времени и
слов
–
надо
подумать,
что
можно
сократить
и
упростить.
Я когда-то лично видел графическое описание бизнес-процесса, выполненное на листе 2 метров длиной (и
соответствующей шириной). Его даже просто рассмотреть и понять, куда ведет какая стрелка крайне сложно. А
как
его
пояснять
заказчику,
я
лично
не
представляю.
Помните, что человек воспринимает зрительно определенный объем информации, ограниченный, в том числе,
определенным размером листа или экрана (это связано с особенностями зрения), а также числом элементов
(возможности мозга также ограничены). Простой и лаконичный бизнес-процесс заказчик поймет, просто
«охватив» схему взглядом. Сложный и перенасыщенный деталями придется изучать не один час просто для
того, чтобы понять, что там отображено. Скорей всего, руководитель компании, который не является экспертом
в работе отдельных подразделений, а также ограничен по количеству свободного времени, просто не будет
изучать столь сложную конструкцию и не поймет сути даже самых выгодных предложений.

50.

Правила описания бизнес-процесса
Использование общепризнанных нотаций. Не стоит изобретать собственные обозначения и правила.
Используйте нотации, которыми пользуются во всем мире. Я видел в книгах некоторых отечественных
авторов попытки создания собственной системы обозначений. И, честно говоря, так и не понял, зачем они
усложняют жизнь и себе, и своим читателям. Здесь как с языком – вы можете придумать свой особый язык,
но понимать его никто, кроме вас, не будет. А если он окажется похож на существующие, то может еще и
путаница появиться. Либо вас сочтут безграмотным, так как вы не по правилам известных языков
используете пунктуацию, склоняете слова и т.д. Так и с нотациями – есть уже устоявшиеся, известные
людям и, что также немаловажно, интуитивно понятные нотации. Они потому и стали популярны, что в
процессе их создания и доработок постоянно тестировались на простоту, однозначность и удобство. Если вы
будете использовать готовые нотации, вас будут понимать, воспринимать, как эксперта, да и сами правила
нотаций уберегут вас от логических ошибок. Я лично рекомендую IDEF3 и BPMN 2.0.
Все участники бизнес-процесса должны быть учтены и прямо указаны. И делать это необходимо
без использования сносок с нумерациями, комментариях в объектах Swimm line (специальные сноски) и т.д.
Этим нередко «грешат» любители создавать собственные конструкции вместо использования готовых
нотаций. Где-то у них названия не помещаются, где-то им кажется, что длинное название в теле бизнеспроцесса будет неудобным. В результате либо приходится искать в сносках, о ком именно идет речь, либо
создатели таких бизнес-процессов просто забывают указать кого-то из участников.
Понятное потребителю описание. Самое главное – ваш потребитель, тот, кто будет читать эту нотацию,
должен быстро и, в идеале, даже без ваших пояснений понимать описание бизнес-процесс.

51.

52.

53.

54.

55.

56.

57.

58.

59.

60.

61.

62.

63.

64.

65.

66.

67.

68.

69.

70.

71.

72.

73.

74.

75.

76.

77.

78.

79.

80.

81.

82.

83.

84.

85.

86.

Рис.2.12 Второй вариант дерева основных бизнес-процессов компании «Эврика»,
построенный на основе последовательного применения критериев декомпозиции
«продукт» и «функция» (рекомендуемый)