Я (Кинзябулатов Рамиль) часто встречаю описания бизнес процессов которые или придуманы или не несут какой либо ценной информации, поэтому решил выложить для людей изучающих вопросов описания бизнес процессов примеры из реальных проектов c некоторыми изменениями.
Данные о потенциальном участнике и билете поступают в систему из внешней базы данных или в виде электронного сообщения с сайта.
Система автоматически проверяет правильность заполнения данных:
Если данные заполнены корректно, запрос отправляется в обработку. Иначе игнорируется как ошибочный.
Автоматическая проверка на наличие лида или контакта в системе по параметрам: email, телефон, ФИО.
Производится проверка наличия оплаты за билет.
Если оплата выполнена:
Клиент оповещается об оплате;
Если клиент новый, создается карточка клиента и на ее основе карточка участника.
На основе данных из карточки участника формируется билет и отправляется покупателю.
Если оплата не выполнена:
Производится проверка срока оплаты:
Если стоимость билетов осталась неизменной, покупателю отправляется напоминание об оплате.
Если срок вышел и стоимость билета изменилась, билет аннулируется, бронь снимается, участник оповещается о снятии брони.
Цена билетов растет по мере приближения мероприятия. В случае аннуляции неоплаченного билета из-за изменения цены покупатель может заново создать запрос и забронировать билет по обновленной цене.
Цикл «проверка оплаты – напоминание об оплате» повторяется вплоть до изменения цены и аннуляции билета или получения оплаты. В последнем случае выполняются действия из пункта «Оплата выполнена», т.е. формируется карточка клиента, участника, создается и отправляется покупателю билет.
Основное отличие продажи билетов B2B от предыдущего процесса заключается в том, что покупатель не предоставляет личных данных каждого участника.
Информация при закупке билетов от организации:
Если при продаже B2C покупатель является участником мероприятия, то при продажах B2B покупатель (представитель компании) и участники (для кого покупают билеты) не совпадают, покупатель в данном случае может одним из списка.
После того, как в систему поступает заявка на участие от юридического лица, покупателю отправляется запрос на количество билетов.
Реализуется это действие при помощи автоматической отправки анкеты, где покупатель заполняет количество билетов, тариф, по которым он планирует их приобрести, реквизиты для выставления счета и другие данные, необходимые для обеспечения участия представителей компании в мероприятии.
После получения анкеты правильность данных проверяется. В случае выявления ошибок запрос анкетных данных повторяется либо выполняются уточнения любым другим удобным способом, например, в телефонном режиме.
На основе предоставленных данных формируется счет на оплату и отправляется клиенту.
Перед проверкой оплаты необходимо проверить условия оплаты, согласованные с клиентом. Это может быть 100% предоплата, частичная предоплата и т.д.
Если по условиям договора возможно формирование билетов до получения оплаты, они формируются согласно анкете и отправляются клиенту.
Если для формирования билетов необходимо получить предоплату, действия производятся аналогично работе с B2C:
Производится проверка срока оплаты:
Если срок вышел и стоимость билетов изменилась, стоимость билетов обновляется, покупатель получает новый счет.
Бизнес-процесс продажи завершен.
Покупатель билетов B2B регистрируется в системе в качестве клиента. Лид – это потенциальный покупатель, с которым планируются переговоры. В случае запроса на покупку билетов – это уже клиент, и работа с ним ведется в рамках Сделки.
Ниже описан бизнес-процесс работы отдела маркетинга с учетом возможностей автоматизации.
Процесс начинается с того, что маркетолог создает новый бриф. В результате формируется документ «Бриф», который должен быть загружен в базу данных системы.
В финале этого шага маркетолог отправляет документ Бриф руководству.
Руководитель изучает бриф, после чего возможны два варианта развития событий:
В системе обязательно должна быть возможность создать документ Бриф, добавить к нему замечания, создать на основании документа Бриф с замечаниями новый Бриф. Это позволит удобно работать с документами, при этом иметь возможность просмотреть предыдущие версии и замечания к ним.
Выбор площадок для рекламы выполняет руководитель на основе анализа брифа и возможностей каждой из площадок.
Это могут быть:
Необходимо предусмотреть возможность выбора одной или нескольких площадок одновременно.
Одобренный бриф вместе со списком выбранных площадок отправляется маркетологу.
Рекламная кампания в данном случае – это документ, который создается в системе на основе одобренного брифа и выбранных рекламных площадок.
Все расчеты проводит маркетолог на основании брифа и тарифов выбранных площадок. После выполнения непосредственно расчетов, данные вносятся в специальные поля документа Рекламная кампания, который отправляется на согласование руководителю.
Руководитель проверяет расчет бюджета. Если выявляются ошибки и неточности, к документу Рекламная кампания добавляются замечания по бюджету и отправляются маркетологу внутри системы.
Если замечаний не выявлено, бюджет одобряется, маркетолог получает соответствующее подтверждение и переходит к запуску рекламы.
На этом этапе также важно предусмотреть в системе возможность видеть предыдущие варианты бюджета и замечания к ним.
Непосредственная работа по этому этапу проводится на выбранных рекламных площадках. В системе маркетолог после получения одобрения бюджета нажимает кнопку «Запустить рекламную кампанию», т.е. меняет статус кампании соответствующим образом.
Работа выполняется маркетологом на рекламных площадках. Все это время статус кампании активен, т.е. руководитель видит, что кампания – в работе.
По результатам рекламной кампании маркетолог обязательно собирает статистику, которую вносит в соответствующий документ в системе. Документ «Статистика» должен быть привязан к текущей Рекламной кампании в системе.
На этом процесс завершен.
Процесс оказания услуги начинается с прихода клиента в компанию для оказания услуги и завершается моментом оплаты услуги клиентом.
В процессе участвуют 3 исполнителя:
На этом этапе администратор взаимодействует с клиентом и уточняет, пришел человек за услугой по предварительной записи или нет. Даже если клиент пришел без записи, услуга по возможности должна быть оказана.
Возможны два варианта:
На этом этапе система должна на основе введенного номера определить и открыть для администратора Запись. Рекомендуется реализовать возможность считать запись с мобильного телефона клиента по штрих-коду. Т.е. в процессе записи клиент получает на телефон уведомление не только в текстовом виде, но и со штрих-кодом. В результате при посещении администратор сможет максимально быстро и безошибочно открыть нужную Запись.
На основании уже заполненных полей система автоматически определяет, нужно ли дополнять данные и уведомляет об этом администратора.
Если данные дополнить нужно, администратор задает соответствующие вопросы и дополняет:
Далее клиенту выдаются раздаточные материалы. После чего клиент направляется к доктору на прием. Если данные уже все заполнены, клиент отправляется к доктору сразу.
Доктор принимает клиента по записи. В системе в момент начала приема доктор фиксирует, что прием состоялся. После нажатия соответствующей кнопки система начинает отсчет реального времени приема.
Этот этап выполняет доктор, в системе непосредственно оказание услуги не отражается. Эти операции выполняются непосредственно специалистом вне системы.
После непосредственного оказания услуги доктор в системе заполняет форму «Оказание услуги», в котором отображает, какие услуги были оказаны, вносит необходимые сведения для карточки питомца и т.д. После того, как проделаны необходимые действия в рамках приема, доктор завершает прием в системе.
После того, как доктор внес все необходимые сведения в документ «Оказание услуги», формируется пакет документов для клиента, которые можно распечатать пакетом. Доктор отправляет документы на печать и передает клиенту документы для расчетов в кассе, а также информацию о состоянии питомца, выполненных процедурах, рекомендации и т.д. Клиент направляется в кассу.
В этот раз процедуру получения номера записи, в том числе, в случае реализации, через штрих-код, выполняет сотрудник кассы. На основании этого номера открывается запись с уже заполненными услугами, после чего автоматически формируется сумма и необходимые финансовые документы.
Кассир выполняет наличный или безналичный расчет с клиентом, распечатывает финансовые документы, в том числе, для клиента.
После того, как оплата завершена, система автоматически формирует sms-сообщение и/или email и отправляет его клиенту с просьбой оценить качество работы.
На этом процесс завершен.
Этот процесс описывает ситуацию, когда клиент пришел по записи получать животное из стационара. В отдельных случаях животное клиент получает из клиники, для них этот процесс также подходит. Но так как чаще всего речь идет о стационаре, здесь также будет использоваться именно этот термин.
Если животное передают от специалиста к специалисту внутри организации, в системе это никак не отмечается. Факт смены доктора отслеживается по записям об оказанных услугах.
В бизнес-процессе участвуют:
Процесс начинается с момента, когда клиент приходит забирать животное. К этому моменту само животное должно быть готово к передаче, а также должны быть актуализированы все соответствующие записи, в том числе, финансовые.
Первое, что должен проверить администратор, по записи пришел клиент или нет.
В этом процессе также будет полезно использование штрих-кодов, которые система будет отправлять при записи на телефон клиента. Такой подход ускорит процесс нахождения записи и снизит вероятность ошибок, связанных с человеческим фактором.
Здесь возможны два варианта:
Во втором случае Кассир принимает оплату, фиксирует эту информацию в системе, после чего клиент возвращается к администратору уже на этап «Распечатать документы Выдача животного».
Если задолженности нет, администратор должен проверить наличие переплаты. При ее выявлении он предлагает вернуть клиенту деньги.
Если Клиент согласен получить сумму переплаты, ему выдается расходный кассовый ордер, после чего он отправляется в Кассу, где получает неиспользованный аванс.
Если клиент предпочитает оставить сумму переплаты в счет будущих посещений, то сразу можно переходить к следующему пункту.
После решения всех финансовых вопросов администратор распечатывает клиенту пакет документов «Выдача животного».
Администратор передает клиенту пакет документов «Выдача животного» и направляет клиента к доктору, который занимается животным в данный период времени.
Животное выдает клиенту доктор на основании переданных ему данных в системе о том, что клиент получил пакет документы «Выдача животного». После выдачи доктор также делает соответствующую пометку в карточке.
После того, как доктор подтвердил в системе выдачу животного, автоматически формируется email или sms-сообщение с просьбой оценить качество работы по данному процессу.
В последнем случае рекомендуется использовать SendPulse или Mailchimp.
В документах большая часть полей должна заполняться автоматически на основании предыдущих записей в системе. Все документы распечатывает администратор. Кассир получает и выдает деньги, может выдать чек, который распечатывается автоматически. Доктор выдает только животное.
Потому в рамках этого бизнес-процесса доступ к печати документов необходим только администратору.
Хорошие примеры, но кажется, что вы выбрали преимущественно простые процессы. Я понимаю, их проще показывать. Но было бы не плохо увидеть где-то хоть 1-2 примера сложных, многослойных процессов, с какими-то уровнями вложенности. Например, такие часто нужны на производстве или в IT.
Есть посложнее, но в них просто больше элементов. Не вижу смысла их сюда выкладывать
Все примеры в статье статические. Они сравнительно просты, и представляют интерес для новичков. А хотелось бы увидеть подходы к динамическому моделированию, например, учитывать сезонное колебание спроса или какие-то временные факторы. Этот аспект очень мало раскрыт в статьях и учебниках по моделированию.
Подскажите, где почитать, как правильно отслеживать и документировать изменения в процессах, чтобы актуальная модель всегда была под рукой. И вообще, побольше бы о документировании узнать.
https://trinion.org/blog/chto-takoe-biznes-process-opisanie-biznes-processa
Моделирование процессов, насколько помню, начинается с ситуации «как есть». Это помогает выявлять проблемные точки. Как-то можно на диаграммах подчеркивать такие места, не нарушая правил нотации? И в как есть, и в готовом решении, как должно быть?
Насколько важно включать в описание всех участников процесса? Есть ли критерии для того, чтобы отсеять второстепенные роли? Т.е. нужно ли включать в модель все отделы и сотрудников или тут бывает какой-то нижний порог детализации? Само собой, я не про «вася и петя», а про роли участников.