Книги
Рамиль Кинзябулатов

Моделирование бизнес-процессов. От идеи к результату

Aleksandr Dokasцитирует4 месяца назад
Есть два подхода к формированию стоимости описания бизнес-процесса:

— Подсчет потраченного времени;

— Создание пакетов услуг.
Aleksandr Dokasцитирует4 месяца назад
Кроме того, есть замечательная фраза, после которой обычно вопрос с возможными убытками закрывается раз и навсегда: «Если мы совместно будем нести убытки, то нужно обговорить и совместное получение прибыли».
Aleksandr Dokasцитирует4 месяца назад
Я рекомендую такую последовательность действий:

1. Цель описания бизнес процесса

2. Цели бизнес процесса

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

4. Поговорить с сотрудниками

5. Выявить наиболее важные задачи бизнес процессе

6. Сделать первый вариант бизнес процесса

7. Выявить начало и конец процесса, начало должно быть только одно, финалов много.

8. Составить список задач с условиями

9. Обсудить детали с руководством и с ключевыми сотрудниками

10. представить финальный вариант

11. Подготовить текстовое описание бизнес процесса
Aleksandr Dokasцитирует4 месяца назад
— Необходимо запланировать начало и конец процесса. С этого начинается моделирование любого процесса. Так мы обозначаем рамки, в которых будем работать.

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

— Пришло время определить ответственных лиц. До этого мы работали с событиями «в чистом виде». Теперь у них появились исполнители и ответственные.

— Добавляем данные, сноски, комментарии.
Aleksandr Dokasцитирует4 месяца назад
Неисполняемые бизнес-процессы нужны исключительно для демонстрации какой-либо бизнес-модели. Это может быть диаграмма, отображающая реальное положение дел на предприятии, может быть наглядной иллюстрацией к предложенным изменениям при реинжиниринге. В этом случае, конечно, можно использовать любые удобные инструменты, в том числе, традиционный для многих IDEF0. А соблюдение правил языка моделирование необходимо исключительно для достижения взаимопонимания.
Aleksandr Dokasцитирует4 месяца назад
Исполняемые бизнес-процессы обязательно должны быть выстроены в строгом соответствие всем правилам нотации BPMN, так как в противном случае программное обеспечение не сможет работать корректно с составленной бизнес-моделью. Исполняемые процессы нужны, например, на предприятиях, где принят процессный подход к деятельности. Программное обеспечение позволяет вести контроль всех процессов в режиме реального времени, и на основе получаемых на каждом из этапов данных, руководитель компании и подразделений всегда смогут понимать, на каком этапе находится работа по тому или иному процессу. Подобный метод позволяет значительно повысить эффективность управления.
Aleksandr Dokasцитирует4 месяца назад
бизнес-моделировании процессы можно условно разделить на два вида — исполняемые, которые действительно будут работать при помощи специального обеспечения, например, Bizagi, и неисполняемые, т.е.бизнес-модели, необходимые только для изучения и демонстрации вариантов работы предприятия.
Aleksandr Dokasцитирует4 месяца назад
Обычно действия делят следующим образом:

— Процесс — крупное действие, которое требует дальнейшей детализации при моделировании.

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

— Event — Событие;

— Activity — Действия;

— Gateway — Шлюзы или Развилки;

— Flow — Поток.

— Date — Данные;

— Artefact — Артефакты;

— Swimline — «плавательные дорожки»;

— Pool (Пул) — набор.
Aleksandr Dokasцитирует4 месяца назад
Я особенно хочу подчеркнуть этот момент, так как и сам столкнулся поначалу с непониманием, зачем те или иные вещи усложнять? Ведь для описания бизнес-процессов, например, при GAP-анализе (анализ разрывов) или для представления заказчику бизнес-модели в какой-то упрощенной форме, всего многообразия элементов BPMN вам не нужно. Но когда начинается автоматизация, когда бизнес-модель становится не просто удобной схемой, а может экспортироваться в другие программные продукты в качестве исполняемых данных, все становится на свои места. Последняя версия BPMN действительно стабильна и все требования к языку обоснованы.
Aleksandr Dokasцитирует4 месяца назад
Только если ваша функциональная модель «как есть» будет действительно отражать реальное положение вещей, можно вносить какие-то изменения и предложения. А для достижения качественных результатов в такой работе требуется, прежде всего, практический опыт и знание особенностей того или иного вида бизнеса.
Aleksandr Dokasцитирует4 месяца назад
При этом я считаю, что бизнес-аналитик — это не совсем профессия, бизнес-аналитикой занимается каждый руководитель бизнеса или разработчик каких-то систем, который анализирует бизнес и стремится выстроить наиболее эффективную систему. Именно для этих людей и для этих целей предназначен инструмент IDEF0.

А потому очень важно при составлении функциональной бизнес модели «как есть» постоянно советоваться с руководителем компании, чтобы не совершить ошибки, которая повлечет за собой автоматически ошибки на этапах декомпозиции. Также на последующих этапах могут потребоваться дополнительные согласования с руководителями структурных подразделений и сотрудниками.
Aleksandr Dokasцитирует4 месяца назад
Важно запомнить простое правило: управляющие стрелки называют именами существительными, блоки — глаголами. Так принято в стандарте IDEF0, и такой подход помогает избежать путаницы и ошибок. Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе — это действия, а потому они должны быть всегда глаголами.
Aleksandr Dokasцитирует4 месяца назад
Внимательно следите за тем, чтобы не возникло путаницы или процессов без входящих, исходящих и других важных элементов.

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

Аналогично, если я решу добавить какой-то блок, важно убедиться, чтобы он также имел все необходимые атрибуты. Здесь очень важна внимательность, так как при моделировании сложных бизнес-процессов изменения в одной части модели могут повлечь за собой изменения в другой. Их обязательно нужно внести.
Aleksandr Dokasцитирует4 месяца назад
При этом важно понимать, что в результате потребуется 2 нотации. Первая будет отображать бизнес-процессы в виде «как есть». Ее вы создаете на основе интервью и согласовываете каждую детализацию с сотрудниками компании и руководителем. Очень важно, чтобы ваше видение существующих процессов совпало с реальностью, именно для этого и требуется подтверждение на всех уровнях. Вторая нотация — «как должно быть». Она создается на основе первой и тех изменений, которые вы предлагаете внести в структуру работы для оптимизации и автоматизации работы компании в рамках выполнения поставленной задачи.
Aleksandr Dokasцитирует4 месяца назад
нотации можно назвать языком программирования при бизнес-анализе
Aleksandr Dokasцитирует4 месяца назад
последний этап — текстовые пояснения. Любая графическая модель, как я уже писал, ограничена определенными рамками и несколько абстрактна. Обойти эти рамки и донести суть модели поможет текст, где будут описаны все подробности каждого действия.
Aleksandr Dokasцитирует4 месяца назад
Далее, создается первый вариант графической нотации и вносятся уточнения. Т.е. вы по итогам опросов создаете модель, после чего демонстрируете ее тем людям, у которых брали интервью. В результате обсуждения и уточнений модель корректируется. Этот этап завершается только тогда, когда все обсуждения пройдены, а сама модель утверждена заказчиком
Aleksandr Dokasцитирует4 месяца назад
Следующий этап — изучаем поставленную задачу. Если речь идет о работе с людьми, как в примере выше, необходимо понять, что и как они делают. Для этого проводятся интервью с руководителем подразделения и его подчиненными. В других случаях список опрашиваемых может быть другим. Но он обязательно необходим, даже если в будущем функции этих людей заменит программа
Aleksandr Dokasцитирует4 месяца назад
Для начала вспомним бессмертную истину — «нельзя объять необъятное». А потому необходимо очертить границы модели. Например, если поставленная цель — автоматизация работы отдела продаж, то ваша модель должна быть ограничена рамками работы этого подразделения. Все, что находится вне продажи, в том числе, бухгалтерские отчеты, производство или закупка товаров, может присутствовать только как входящие или исходящие «стрелки», если в этом есть необходимость.
fb2epub
Перетащите файлы сюда, не более 5 за один раз