Правильно устроенные бизнес-процессы повышают эффективность работы организации. Рассмотрим на примерах, как их анализировать, описывать и оптимизировать.

Определение

Бизнес-процессы (БП) – это последовательность определенных действий, отвечающая следующим условиям:

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

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

Владелец процесса – то самое звено, которое отличает процессное управление от функционального. Функциональные задачи отдельно взятого подразделения часто противоречат задачам другого подразделения или компании в целом.

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

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

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

Группы бизнес-процессов

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

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

Обеспечивающие. Эти процессы предназначены для обеспечения эффективной работы основных БП. Примеры: процесс подготовки и обучения персонала, регламентированные документооборот и работа IT-подразделения. В теории нередко выделяют управленческие процессы , но, по сути определения, они являются частным случаем обеспечивающих БП.

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

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

Описание и анализ бизнес-процессов в организации: пример

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

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

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

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

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

При описании бизнес-процесса в организации целесообразно придерживаться следующих правил и принципов:

• Ответственным за написание и утверждение БП должен быть его владелец . Это позволит снизить вероятность «саботажа» основными исполнителями, если они не принимали участия в составлении соответствующего регламента.
• Результаты, которые получаются на выходе процесса, должны быть четко сформулированы, измеримы и понятны . Если на объяснение положений регламента сотрудникам уходит много времени, то следует поработать над изменением формулировок в регламентирующем документе.
• Используйте простые схемы . Правила описания алгоритма представлены в любом учебнике информатики для старших классов. Это простой и интуитивно понятный язык. Выбор программы для визуализации процессов не принципиален: можно успешно обойтись стандартными программами пакета MS Office.
• Основное внимание следует уделять наиболее критичным для развития бизнеса процессам. Наука, производство и продажи – это три столпа добавленной стоимости. Нет большого смысла вкладывать ресурсы в контроль работы бэк-офиса, если продажи и производство никак не контролируются.
• Все участники процесса должны быть учтены и прямо указаны . Каждый из них должен знать:
  • что от него требуется,
  • в какие сроки следует выполнять поставленные задачи,
  • как будет измеряться результат его работы,
  • каким будет вознаграждение в случае успешного исполнения
• Используйте простые и стандартные термины и определения. Процесс описывается для сотрудников компании, а не для самовыражения.
• Акцентируйте внимание руководства компании, что самым дисциплинированным исполнителем принятых регламентов должны стать генеральный директор и топ-менеджмент компании. Процесс перестанет генерировать добавочную стоимость, если будет периодически нарушаться руководством компании.
• Контролируйте исполнение положений принятого документа и применяйте дисциплинарные взыскания за необоснованные нарушения.
• Акцентируйте работу на поиске узких мест . На практике приходится сталкиваться с удивительными вещами. Например, новое современное производство не оснастили линией розлива достаточной мощности. В итоге качественные препараты были произведены, но розлив в тару существенно замедлил весь процесс и свел на нет большую часть работы коммерческого департамента.
• Привлечение консультанта для описания и утверждения БП сопоставимо с привлечением высоко классифицированного модератора, но не более. Никто не знает ваш бизнес лучше вас и вашей команды. Бизнес-процесс в организации эффективнее описывать совместно с командой.
• Если процесс «не работает», то уделяйте время анализу причин и внесению необходимых изменений. Методы оптимизации БП хорошо известны:
  • Упрощение (например, когда из процесса исключаются не влияющие на результат звенья);
  • Объединение (исключение дублирующих частей БП);
  • Аутсорсинг (передача исполнения дискретных задач сторонним компаниям);
  • Оптимизация сроков (сокращение или увеличение сроков для регламентированных задач);
  • Стандартизация (например, подготовка шаблонов документов или ввод дополнительных инструкций).

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

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

Моделирование – процесс исследования деятельности организации с целью построения формализованного (графического, табличного, текстового) описания бизнес-процессов организации.

• интервьюирование;
• работа с законодательством, документами организации;
• методы мозгового штурма и т.д.

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

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

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 человек и даже если специалисты будут ошибаться. Какова цена ошибки – всего-лишь неправильно оформленные кадровые документы, эти бумажки.

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

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

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

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

Почему хорошая формализация бизнес-процесса важна?

1. Она позволяет сделать наши мысли предметом широкого обсуждения.
2. Она дает возможность донести новые правила работы до тех сотрудников, которые будут их выполнять.
3. Формализованные бизнес-процессы легче изменять и модернизировать.
4. Формализация бизнес-процессов является хорошей основой для последующей автоматизации бизнеса в компании: создания/настройки различных информационных систем и стандартных пакетов автоматизации.

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

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

В качестве примера я взял крупный магазин по торговле мебелью и его бизнес-процесс "Покупка клиентом товара". На рис. 9.1 представлена диаграмма этого бизнес-процесса в нотации BPMN , с комментариями по нотации.

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

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

1. "Оформление заказа". Сначала клиент оформляет заказ. Предполагается, что перед этим он определился в главном - что ему нужно. Например, кухонный гарнитур. Тогда в отделе по торговле кухонной мебелью он, вместе с одним из менеджеров этого отдела, составляет дизайн-проект для своей покупки (в соответствии с размерами его кухни и своими пожеланиями), уточняет параметры своего заказа и точно определяется с комплектующими и материалами.
2. "Получение товаров". Клиент идет на склад и сам выбирает все составные части своего заказа, имея точный перечень того, что ему нужно. При этом ему помогают работники склада.
3. "Оплата товаров и оформление доставки". Клиент вместе со своими выбранными товарами (он везет их на тележке) следует к кассе и оплачивает то, что он выбрал. Далее, с оплаченными товарами, он переходит в отдел доставки, где оформляет и оплачивает доставку своей мебели, а также ее сборку (если ему это нужно); после этого он уезжает домой.
4. "Доставка". Оплаченные товары клиенту доставляют в течение трех дней.
5. "Сборка". После этого, если клиент оформил сборку, то к нему приезжает мастер-сборщик и собирает доставленную мебель.

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

Декомпозиция бизнес-процессов

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

Понятие бизнес-процесс, структура процессов и подпроцессов

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

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

Группы бизнес-процессов

Выделяют основные, вспомогательные и процессы управления – это главные группы БП. Как выполняемый единожды уникальный процесс отдельно выделяется БП развития. Направленность БП основной группы:

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

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

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

Процессы управления координируют всю совокупность БП (основные, поддерживающие, БП развития).

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

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

Описание основных БП для производственно-торговой компании (пример):

• маркетинговые процессы;
• проектирование, разработка продукта или услуги;
• производство конечного продукта;
• логистические процессы (сбыт, доставка, снабжение);
• управление продажами и обслуживанием

Поддерживающие БП:

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

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

БП развития – совершенствование деятельности, своего рода бизнес-инжиниринг.

Описание и анализ БП

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

Визуализация модели.

Модель обычно отображают в виде схем, таблиц с описаниями, либо сочетание графика и текстового описания (нотация) и т.п. Степень детализации объекта, полнота описания, зависят от конкретного применения данной модели. Задачей любого из этих способов будет описание БП по принципу: «действие-функция». У каждого БП есть свой исполнитель – это тоже нужно указывать. Им будет являться подразделение либо определенная должность. «Входы» - это материальные, информационные и финансовые, а «выходы» представляются в виде перечня продуктов либо услуг. Результатом действия исполнителя будет являться «выход», действия также могут объединяться по принципу логической связи между собой, тогда «входы» и результаты должны быть согласованы между ними. Связь «входа» и «выхода» обеспечивается деятельностью, направленной на достижение результата при переходе между ними.

Как реализуется описание БП

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

1. Текстовое описание.

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

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

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

3. Графическое описание в виде моделей и диаграмм.

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

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

Технологии, которые используются для описания БП:

1. IDEF - принята за стандарт практически повсеместно. Integration Definition for Function Modeling –технология моделирования функционала. Поддерживается следующим программным обеспечением – BPWIN, MS Visio и пр. Это совокупность методов моделирования позволяет детализировать БП всех уровней, представляя их как в одном блоке, так и в отдельных схемах.

2. Технологии моделирования используют унифицированный язык моделирования (UML). Он позволяет описывать БП непосредственно на языке понятном компьютерным программам, является средством автоматизации. Поддерживается ведущими разработчиками ПО, основным инструментом для реализации является программное средство Rational Rose от IBM.

3. Диаграммы еЕРС (extended Event-Process Chain). Благодаря им, есть возможность отобразить последовательность операций, участников, используемые ресурсы, отображая состояние на текущий момент времени.

4. Технология ARIS (Architecture of Integrated Information Systems) используется как встроенный инструмент в одну из крупнейших систем автоматизации – SAP R/3.

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

Алгоритм действий при моделировании:

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

2. Описания всего окружения БП, а именно указание всех процессов с которыми он связан на «входе» и «выходе», включая все ресурсы на этих этапах.

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

4. Описание БП потоков и их структуры. Определяется целями, которое оно преследует. Если необходимо улучшить информационную систему, тогда описываются потоки информации, документооборот и т.п., если цель распределить правильно финансы – тогда финансовый поток и БП в них.

Аннотация

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

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

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

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

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

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

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

SADT возникла в конце 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 позволяют выполнять следующие задачи:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Транспортной логистики (перевозок); Размещено на http://www.сайт/

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

Транспортного оРазмещено на http://www.сайт/

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

Транспортных расходов (себестоимости работ Размещено на http://www.сайт/

и тарифов на услуги);

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

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

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

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

Основным методологическим партнером ООО «ПромТрансИнформ» является ГОУ «Сибирский государственный университет путей сообщения» (г.Новосибирск).Специалисты компании имеют 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 - Глоссарий

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

5.2 Диаграмма событийно-управляемой цепочки процесса (extended Event-driven Process Chain, eEPC). Используемые объекты и их символы представлены в таблице 5.2.1.

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

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

Типы связей, используемых в диаграмме событийно-управляемой цепочки процесса, представлены в таблице 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)			Функция (Function)
			Носитель информации (Information carrier)
Прикладная система (Application system)	Поддерживает (Supports)		Функция (Function)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.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 - Детализация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.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 - Результаты обследования ПТИ

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

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

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

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

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

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

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

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

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

		Должность	Подразделение	Входящая информация
	Согласование условий с заказчиком	Директор	начальство	Условия заказчика
	Заключение договора	Гендиректор	начальство	Техническое задание
	Информирование сотрудников о заказе	Директор	начальство	Заказ на автоматизация (мэйл)
	Описание и документирование БП	Бизнес-аналитик	Отдел аналитики	Комплект документов БП
	Проектирование архитектуры ИС	Разработчик	Отдел разработки	Технологические инструкции, данные об архитектуре данных заказчика, комплект документов БП, требования к ПО
	Кодирование ПО	Программист или веб-программист	Отдел разработки	Комплект документов БП, Лицензия на ПО
	Тестирование ПО	Тестировщик	Отдел разработки	ИС заказчика
	Внедрение ИС	Разработчик	Отдел разработки	Заключение по внедрениию ИС

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

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:

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

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

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

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

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

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

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

Уточнение информации у клиента
Написание БП
Тестирование ИС
Внедрение ИС
Интегральная оценка степени достижения цели
Плановая интегральная оценка степени достижения цели

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

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

Подобные документы

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

дипломная работа , добавлен 11.02.2011


Создание бизнес-модели процесса выдачи потребительских кредитов. Организационное обеспечение кредитного процесса. Моделирование и документирование бизнес-процессов в программе BPwin. Построение модели AS IS. Предложение по автоматизации бизнес-процесса.

курсовая работа , добавлен 07.01.2012


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

курсовая работа , добавлен 28.07.2013


Моделирование информационной системы (ИС) бизнес-процессов продуктового супермаркета "Большая Ложка" на ранней стадии (фазе формирования концепции предприятия) стандартами UML. Сценарий для моделирования ИС, начальные данные и структура управления.

курсовая работа , добавлен 16.09.2011


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

курсовая работа , добавлен 18.03.2015


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

курсовая работа , добавлен 17.07.2014


Построение имитационной модели бизнес-процесса "Управление инцидентами" компании "МегаФон" с целью прогнозирования совокупной стоимость ИТ-сервиса по обслуживанию инцидентов. Разработка моделирующих алгоритмов для реализации компьютерных программ модели.

курсовая работа , добавлен 09.04.2012


Применение метода равномерного расположения для оптимизации бизнес-процессов. Программное обеспечение Staffware Process Suit, суть его работы и преимущества. Разработка приложения-прототипа для автоматизации применения метода равномерного расположения.

дипломная работа , добавлен 21.08.2016


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

контрольная работа , добавлен 09.11.2012


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