Целью построения функциональных моделей обычно является определение наиболее слабых и уязвимых мест в деятельности организации, анализ преимуществ новых бизенс-процессов и степени необходимых изменений существующей структуры бизнеса. Анализ недостатков и «узких мест» начинается с построения модели AS-IS (Как есть).
Эта модель строится на основе изучения документации (должностных инструкций, приказов, отчетов и т.п.), анкетирования и опроса служащих предприятия, протоколирования действий сотрудников в течение рабочего дня и других источников. Полученная модель AS-IS служит для выявления неуправляемых и не обеспеченных ресурсами работ, ненужных, неэффективных и дублирующих друг друга действий и других недостатков в организации деятельности предприятия. Исправление недостатков, перенаправление информационных и материальных потоков приводит к созданию модели TO-BE (Как будет). Как правило, строится несколько моделей TO-BE, среди которых выбирается наилучший вариант.
Распространенная ошибка при моделировании – это создание идеализированной модели. Примером может служить моделирование на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнять работы согласно руководствам и должностным инструкциям, и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно использовать в дальнейшем для анализа. Такая модель называется SHOULD-BE (Как должно быть).
Как спланировать работу по описанию бизнес процессов
Технология проектирования информационных систем подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов. Затем создается модель TO-BE и на ее основе строится модель данных, прототип а затем и окончательный вариант информационной системы. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли». Иными словами автоматизируются несовершенные бизнес-процессы и дублируется существующий документооборот.
Иногда текущая модель AS-IS и будущая TO-BE различаются очень сильно и переход от начального состояния к конечному становится неочевидным. В этом случае необходима третья модель, описывающая переход от начального состояния к конечному, поскольку такой переход – это тоже бизнес-процесс.
Воспользуйтесь поиском по сайту:
Источник: studopedia.org
Модель AS-IS
AS-IS — модель «как есть», модель существующего состояния организации. Данная модель позволяет систематизировать протекающие в данный момент процессы, а также используемые информационные объекты. На основе этого выявляются узкие места в организации и взаимодействии бизнес-процессов, определяется необходимость тех или иных изменения в существующей структуре.
На этапе построения модели AS-IS важным считается строить максимально приближенную к действительности модель, основанную на реальных потоках процессов, а не на их идеализированном представлении.
С чего начать описание бизнес процесса? Простая анкета вместо тех задания.
На основе анализа текущих процессов организации учета товаров на фирме была создана следующая AS-IS модель, которая позволяет выделить и систематизировать процессы, протекающие в данной системе при её функционировании. Главная контекстная диаграмма данной модели приводится на рисунке 1.1.
база данные таблица экранный
Рисунок 1.1 — Главная контекстная диаграмма (модель AS-IS)
Для более детального понимания логики бизнес-процессов, протекающих в текущей проблемной области разработанная выше контекстная диаграмма была разбита на три следующих процесса:
зачисление и регистрация товаров;
регистрация заказа товаров.
Декомпозиция контекстной диаграммы представлена на рисунке 1.2.
На диаграмме прослеживаются этапы процесса обучения: в начале происходит регистрация поставщика. Поставщик поставляет товары. Далее сотрудник, заведующий складом, регистрирует товары и оформляет заказы от клиентов.
Для детального понимания процесса «Регистрация поставщика» он разбивается на следующие три процесса:
проверка данных поставщиков;
Декомпозиция процесса «Регистрация поставщика» приводится на рисунке 1.3.
Рисунок 1.2 — Декомпозиция контекстной диаграммы
Рисунок 1.3 — Декомпозиция процесса «Регистрация поставщика»
Для детального понимания процесса «Зачисление и регистрация товара» он разбивается на следующие два процесса:
1) проверка товара;
2) выгрузка товара на склад;
3) распределение товара по категориям;
4) хранение на складе.
Декомпозиция процесса «Зачисление и регистрация товара» приводится на рисунке 1.4.
Рисунок 1.4 — Декомпозиция процесса «Зачисление и регистрация товара»
Модель TO-BE
Модель TO-BE («как должно быть») создается на основе AS-IS, с устранением недостатков в существующей организации бизнес-процессов, а так же с их совершенствованием и оптимизацией путём устранения выявленных на базе анализа AS-IS узких мест.
В соответствии с моделью TO-BE целью предмета разработки является упрощение организации учета и движения товаров на фирме. При этом предмет разработки должен обеспечить:
формирование базы данных, информацию о товарах клиентах и поставщиках;
средства доступа к этой базе для редактирования, добавления, удаления данных;
сортировку и фильтрацию данных, содержащихся в базе;
средства поиска нужной информации в базе данных;
удобный просмотр запрошенной информации.
На основе анализа созданной выше AS-IS модели процессов проблемной области была создана TO-BE модель, контекстная диаграмма которой приводится на рисунке 1.5.
Рисунок 1.5 — Главная контекстная диаграмма (модель TO-BE)
Для уточнения понимания логики бизнес-процессов, протекающих в текущей проблемной области контекстная диаграмма была разбита на четыре следующих процесса:
1) регистрация и поддержка пользователей;
2) работа с товарами;
3) работа с заказами товаров.
Декомпозиция контекстной диаграммы представлена на рисунке 1.6.
Рисунок 1.6 — Декомпозиция контекстной диаграммы
Процесс «Регистрация и поддержка пользователей» для детального рассмотрения разбивается на четыре процесса:
1) регистрация студентов и преподавателей;
2) изменение личных и секретных данных регистрации;
3) восстановление пароля;
4) удаление пользователя.
Все процессы в результате своей деятельности обмениваются информацией с хранилищем данных: добавляют новую информацию, извлекают и модифицирую её, а также производят удаление ненужных данных, причём на данном этапе декомпозиции видно, что только «Администратор» может выполнять данные функции. Декомпозиция данного процесса приводится на рисунке 1.7.
Рисунок 1.7 — Декомпозиция процесса «Регистрация и поддержка пользователей»
Процесс «Работа с новыми поставками товаров» был разбит на следующие три процесса:
1) добавление данных о товаре;
2) изменение данных о товаре;
3) удаление данных о товаре.
В качестве объектов, которыми оперируют процессы, выступают данные о товарах. Все процессы в результате своей деятельности обмениваются информацией с базой данных «Mysql»: добавляют, модифицируют и удаляют данные, причём вводимые данные должны удовлетворять требованиям, предъявляемые базой данных. Данные действия может выполнять «Администратор». Декомпозиция процесса «Работа с данными о товарах» приводится на рисунке 1.8.
Рисунок 1.8 — Декомпозиция процесса «Работа с данными по дисциплине»
Процесс «Работа с новыми заказами» был декомпозирован на следующие три процесса:
1) добавление нового заказа;
2) изменение нового заказа;
3) удаление нового заказа.
Все процессы в результате своей деятельности обмениваются информацией с базой данных «Mysql»: добавляют, модифицируют и удаляют данные, причём вводимые данные должны удовлетворять требованиям, предъявляемые базой данных. Данные действия может выполнять только «Администратор».
Декомпозиция процесса «Работа с данными» приводится на рисунке 1.9.
Рисунок 1.9 — Декомпозиция процесса «Работа с соответствующими данными»
Источник: studentopedia.ru
От as-is к as-to-be: что такое Service Blueprint и при чем здесь BABOK
В этой статье мы продолжим разговор про Customer Journey Map (CJM) и рассмотрим, чем карта взаимодействия с клиентом отличается от Service Blueprint, зачем вообще нужен сервисный сценарий и как он связан с классикой бизнес-анализа: моделями as-is и as-to-be, а также с руководством BABOK.
Что такое Service Blueprint и чем он отличается от CJM
Начнем с определения: Service Blueprint или карта сервисного сценария – это визуальное представление идеального процесса взаимодействия с клиентом, направленное на достижение конкретной бизнес-цели с учетом всех возможных точек контакта: физических и цифровых [1]. Обычно Service Blueprint рассматривают как модификацию CJM, которая включает не только элементы потребительского поведения, но и бизнес-процессы обеспечения контактов, в т.ч. те, которые находятся «за сценой» [2]. Например, работа банковского бэк-офиса, складские операции в интернет магазине и прочие действия, которые не видны пользователю напрямую, но непосредственно связаны с оказанием бизнес-услуги. Таким образом, CJM — это внешний взгляд на продукт, сервис или бренд с позиции пользователя, а Service Blueprint – это представление бизнес-процессов, обеспечивающих эффективное взаимодействие с клиентом [3].
Как построить карту сервисного сценария
Карта сервисного сценария включает следующие компоненты [4]:
- Действия клиента (Customer Actions), выполняемые непосредственно потребителем как часть процесса предоставления им услуг. Например, приход на сайт или в физическое пространство, звонок в кол-центр и т.д. Обычно этот уровень представляет собой улучшенную CJM.
- Фронт-энд или действия на переднем этапе с видимым контактным лицом (Front-stage), которые предпринимаются сотрудниками компании в рамках личной встречи. К примеру, администратор гостиницы, хостес в ресторане, продавец в магазине и пр.
- Бэк-энд или действия на заднем плане (Back-stage), выполняемые сотрудниками за пределами видимости для потребителя: бронирование гостиницы или ресторана по телефону.
- Поддерживающие процессы (Support Processes), которые необходимы для оказания услуги: техническая поддержка, информационное обеспечение и пр.
- Физическое обеспечение (Physical Evidence): материальные элементы, которые могут повлиять на восприятие потребителем услуги: униформа официантов, оформление входной зоны и т.д.
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
MODP
Ближайшая дата курса
14 июня, 2023
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.
Разделение бизнес-процессов по уровням показывается с помощью линий:
- видимости (Line of Visibility), которая отделяет фронт-энд от бэк-энда;
- взаимодействия (Line of Interaction), которая отделяет действия клиента от действий поставщика услуг;
- внутреннего взаимодействия (Line of Internal Interaction), которая разделяет бэк-офис и процесс поддержки;
- реализации (Line of Implementation), которая отделяет управление от поддержки – менеджмент отвечает за планирование и контроль мероприятий, а вспомогательные подразделения – за их подготовку.
Как и в случае CJM, наиболее популярным способом практического построения Service Blueprint является ручной – по крайне мере, на первом этапе проектирования. Действия на каждом уровне бизнес-процессов изображаются с помощью графических примитивов (круг, квадрат, прямоугольник), связанных между собой. Здесь не идет речь об использовании строгих нотаций бизнес-моделирования (IDEF, EPC, UML, BPMN), хотя на практике имеет смысл определить правила для изображения элементов и придерживаться их.
А что скажет BABOK: сервисный сценарий и классический бизнес-анализ
С точки зрения классического бизнес-анализа, подробно описанного в профессиональном руководстве BABOK®Guide (A Guide to the Business Analysis Body of Knowledge®), CJM описывает текущее состояние (модель «как есть», as-is). А Service Blueprint можно рассматривать в качестве модели желаемого будущего («как должно быть», as-to-be), которая будет реализована с помощью соответствующих решений: программных средств или организационных мероприятий. Примечательно, что BABOK не включает понятия CJM и Service Blueprint в перечень наиболее распространенных техник бизнес-анализа. Впрочем, это руководство подчеркивает, что за его рамками осталось еще множество полезных методов и средств. Некоторые из них, в частности, CJM, международный институт бизнес-анализа упоминает в качестве техник продуктового анализа в Guide to Product Ownership Analysis.
Кроме того, главные достоинства CJM и Service Blueprint (наглядность, понятность, простота построения и удобство использования) позволяют работать с ними не только профессиональным аналитикам, но и руководителям, маркетологам, дизайнерам, менеджерам и прочим профильным специалистам. Подробнее о том, что такое BABOK, мы рассказываем здесь.
С прикладной точки зрения Service Blueprint – отличный инструмент для построения целостной картины предоставления услуги в рамках процессного подхода к управлению, когда разные структурные единицы вовлечены в единую деятельности по созданию ценности. Благодаря наглядности карта сервисного сценария позволяет менеджеру найти возможности для оптимизации деятельности:
- выявить и предупредить дублирование операций;
- снизить операционные затраты на выполнение процессов, сократив количество шагов или уровень изменчивости;
- эффективно распределить нагрузку на персонал с учетом количества и длительности задач, выполняемых на каждом уровне.
Подобная оптимизация актуальна для любого бизнеса. Поэтому карта сервисного сценария – это полезная техника бизнес-анализа, которая пригодится каждому руководителю.
Как построить CJM и Service bluePrint, а также прочие вопросы продуктовой аналитики в контексте бизнес-анализа рассматриваются в нашем новом курсе «От процессов к продуктам: Product ownership и Agile-практики для бизнес-аналитика». Узнайте, как вписать продуктовое мышление, юнит-экономику и Agile-практики в классический бизнес-анализ, подружив продуктовые метрики с процессными показателями, а требования – с фичами. Построенный на изучении лучших практик из профессиональных сводов знаний от IIBA® (BABOK®Guide, Agile Extension и Guide to Product Ownership Analysis) с примерами их практического применения, курс также содержит советы и лайфхаками для подготовки к экзаменам ECBA, CCBA, CBAP, AAC, CPOA.
Источник: babok-school.ru