Схемы бизнес процессов как есть

Ответим Вам в течение 5 минут

Заказать услугу

Ответим Вам в течение 5 минут

  • Главная
  • Организационные решения
  • Описание бизнес-процессов «как есть»
  • Анализ бизнес-процессов
  • Улучшение бизнес-процессов
  • Автоматизация бизнес-процессов
  • Внедрение бизнес-процессов
  • Контроллинг бизнес-процессов
  • Process Mining [Процесс Майнинг]
  • Настройка системы управления показателями
  • Разработка и контроль реализации стратегии развития компании
  • Процессная трансформация
  • Анализ и совершенствование организационной структуры
  • Внедрение и развитие системы мотивации персонала
  • Аудит бизнес-процессов и диагностика системы процессного управления
  • Внедрение и развитие системы управления бизнес-процессами
  • Обучение руководства и сотрудников
  • Документирование системы процессного управления
  • Подходы к разработке стратегии
  • Школа дизайна
  • Школа планирования
  • Школа позиционирования
  • Школа предпринимательства
  • Когнитивная школа
  • Школа обучения
  • Школа власти
  • Школа культуры
  • Школа внешней среды
  • Школа конфигурации
  • Определения и описание стратегии
  • Типы стратегий
  • Три способа создания изменений
  • Три формы стратегии
  • Корпоративная стратегия: Управление пакетом видов бизнеса
  • Стратегия бизнес-единицы
  • Направляющие вопросы для мониторинга макросреды
  • Распределение стратегий по уровням
  • Три задачи создания стратегии
  • Создание конкурентного преимущества
  • Стратегия для малого бизнеса
  • Стратегическое управление
  • Принципы и составляющие стратегического планирования
  • Задачи страт.менеджмента
  • Методы и инструменты
  • Методы и инструменты (A-Z и А-В)
  • PIMS-анализ
  • SWOT-анализ
  • Анализ «разрывов»
  • Анализ ресурсов
  • Бенчмаркинг (benchmarking)
  • Бизнес-инжиниринг
  • Внутренний аудит
  • Дерево целей
  • Диагностическая самооценка
  • Качественное развертывание планов
  • Конкурентный анализ
  • Конкурентный анализ по модели «5 сил» М. Портера
  • Метод Бостонской консалтинговой группы (матричный)
  • Методы внутреннего и внешнего PR
  • Метод жизненного цикла товара
  • Метод кривых освоения
  • Метод «Маккинзи» (матричный)
  • Методы нейро-лингвистического программирования
  • Метод оценки по системе баллов
  • Метод проверочного списка
  • Модель ADL/LC
  • Модель Shell/DPM
  • Модель Г. Стейнера
  • Модель Д.Абеля
  • Модель И. Ансоффа
  • Модель чистой (итоговой) ценности
  • Мозговой штурм
  • Система сбалансированных показателей
  • Сравнительный отраслевой анализ
  • Стратегический аудит
  • Структура Разбиения Работ
  • Функционально-стоимостной анализ
  • Определение бизнес-процессов
  • Три силы, действующие на компании
  • Классификация бизнес-процессов
  • Цикл PDCA
  • Документирование процесса
  • Измерение показателей
  • Самооценка и оценивание показателей
  • Построение оргструктур: требования
  • Виды орг.структур
  • Изменения в оргструктурах
  • Мотивация персонала
  • Экспресс-анализ организационной структуры
  • Примеры организационных структур
  • Бизнес-Студио
  • Business Studio — готовые решения
  • Как определить необходимое число лицензий для Business Studio
  • Бизнес-инженер
  • Как начать работать в Бизнес-инженер и Business Studio
  • О системе «Бизнес-инженер»
  • Ключевые особенности и преимущества системы Бизнес-инженер
  • Краткое описание программных продуктов и модулей системы Бизнес-инженер
  • Решаемые задачи и используемые методы в системе Бизнес-инженер
  • Схемы лицензирования системы Бизнес-инженер
  • Требования к компьютерам и программному обеспечению для работы с системой Бизнес-Инженер
  • Управление бизнес-процессами
  • Электронный документооборот
  • Управление показателями
  • CRM
  • Управление проектами
  • Внутренний портал
  • Модуль интеграции с 1С
  • Штрих-код
  • ELMA для BITRIX
  • ELMA для IPAD
  • ELMA для SHAREPOINT
  • SOA CONNECTOR
  • Управление бизнес-процессами
  • Электронный документооборот
  • Управление показателями
  • Управление проектами
  • BPM SUITE
  • ECM
  • CRM Expert
  • Дополнительные модули

Организационные решения

    Вы здесь:
  1. Главная
  2. Организационные решения
  3. Описание бизнес-процессов «как есть»

Описание бизнес-процессов «как есть»

Image

О чем молчат графические схемы бизнес-процессов?

Анализ графической схемы бизнес-процесса в нотации BPMN

Задать вопрос

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

  • анализ и улучшение бизнес-процесса;
  • регламентация бизнес-процесса;
  • автоматизация бизнес-процесса;
  • организационное планирование (внесение изменений в организационную структуру);
  • обучение персонала;
  • измерение (количественная оценка) показателей эффективности бизнес-процесса;
  • установление ограничений и целей бизнес-процесса (при разработке и контроле реализации стратегии развития компании).
Читайте также:  Есть ли бизнес у кийосаки

Модели «как есть» и «как должно быть»

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

модель «как есть»;

модель «как должно быть».

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

Модель «как есть»;

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

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

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

Модель «как должно быть».

Модель «как должно быть» («to be»)отражает представление о новых для предприятия технологиях организации деятельности.

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

В этом случае осуществляется реорганизация деятельности предприятия, т.е. реинжиниринг.

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

Описание бизнес-процессов «Как есть» (AS IS) и «Как должно быть» (TO BE)

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

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

Описывать нечего

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

Здесь нет ничего необычного. Каждый человек мыслит немного по-своему, у каждого за плечами — собственный опыт. В результате даже самые простые задачи мы все склонны выполнять по-разному.

Читайте также:  Бизнес идеи транспортные компании

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

Еще ярче, в тех же продажах, заметна разница между действиями при работе с лидами:

  • Один менеджер отправит прайс-лист или коммерческое предложение и успокоится на этом.
  • Другой сначала позвонит, все уточнит.
  • Третий будет добиваться личной встречи даже там, где без нее можно прекрасно обойтись.

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

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

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

Описывать незачем

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

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

Зачем создают нотации AS IS?

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

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

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

Читайте также:  Как открыть бизнес it специалисту

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

Потому не имеет смысла тратить силы и время на составление полноценной нотации AS IS с сопроводительной документацией, включать этот этап в план работ и т. д. Если ваш клиент не ждет от вас этого этапа в обязательном порядке, что иногда случается в крупном бизнесе или в случаях, когда заказчики тоже читали те самые учебники, предоставляйте сразу решение — TO BE. Вы должны быть на стороне клиента, и давать ему то, что реально нужно. Это подход продуктивности.

‍Пример использования нотации AS IS и TO BE

Я сотрудничал с хлебокомбинатом, который имеет цех выпечки, склад и подразделение охраны. При составлении нотации AS IS стало очевидно, что участие охраны в процессе выпечки хлеба абсолютно не нужно.

Как выглядит процесс:

  1. Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
  2. Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
  3. Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
  4. Выполняют выпуск хлеба.
  5. Далее они должны сдавать полученную партию и документы охране.
  6. Охрана проверяет партию и дает разрешение. Причем, разрешение дается всегда, так как что может охрана? Убедиться, что в партии есть хлеб. Максимум – подсчитать его количество
  7. Охрана выдает разрешение.
  8. Цех выпечки передает партию товара на склад.
  9. Склад принимает товар.

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

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

Процесс TO BE будет таким:

  1. Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
  2. Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
  3. Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
  4. Выполняют выпуск хлеба.
  5. Цех выпечки передает партию товара на склад.
  6. Склад принимает товар.

Источник: Блог компании Системный интегратор Тринион

Источник: datafinder.ru

Рейтинг
( Пока оценок нет )
Загрузка ...
Бизнес для женщин