Выстраивание бизнес процессов что это
Что такое бизнес-процесс и описание бизнес процесса
И, тем не менее, ум человеческий тщетно пытался постигнуть ее в течение более чем 2 000 лет, между тем как, с другой стороны, ему удался, но крайней мере приблизительно, анализ гораздо более содержательных и сложных форм. Почему так? Потому что развитое тело легче изучать, чем клеточку тела. К тому же при анализе экономических форм нельзя пользоваться ни микроскопом, ни химическими реактивами. То и другое должна заменить сила абстракции.
Карл Маркс. Капитал. Том 1. Предисловие к первому изданию.
О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих статьях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я не нашел.
Многие авторы используют его «по умолчанию», как термин «интуитивно понятный» без расшифровки, либо вообще вносят дополнительную путаницу использованием альтернативной терминологии, например, пишут вместо бизнес-процесса «бизнес сущность» и т.д.
В этой статье я решил поговорить о том, что такое бизнес-процесс, рассказать об истории появления этого понятия и о том, где его можно и нужно применять. Также я планирую посвятить теме бизнес-процессов следующую статью, в которой расскажу, как правильно использовать бизнес-процессы.
Определение бизнес-процесса
Итак, в чем же разница между бизнес-процессом и функций или даже просто обычным процессом? В чем разница между этими терминами? Я пришел к следующему выводу:
Бизнес-процесс – это логическая последовательность действий человека (или нескольких человек) в коллективе. Цель описания бизнес-процесса – анализ и регламентация тех или иных действий в коллективе.
Почему я делаю особый упор на людях и коллективе:
Описание бизнес процесса
Также важно дать определение описанию бизнес процесса:
Описание бизнес-процесса – это описание последовательности действий сотрудников при выполнении определенных действий в графическом и текстовом виде с целью регламентации действий в коллективе, анализа и оптимизации их последовательности.
И здесь необходимо понимать, что бизнес-процесс без описания не существует. Только в процессе описания появляется бизнес-процесс, т.е. невозможно реализовать одно без другого.
При этом все действия, которые описываются в бизнес-процессе, должны быть логичными, их последовательность должна приводить к определенной поставленной ранее цели.
Описание бизнес-процессов – работа творческая. Даже если вы описываете «то, что есть», все равно допускаются некоторые неточности, «сглаживаются» углы, какие-то действия упускаются для простоты восприятия. А если описывается «то, что должно быть», то здесь на основе существующего создается нечто новое. При этом бизнес-аналитик все же ограничен строгими рамками – правил, синтаксиса, логических ограничений.
Лично я сравниваю создание нового бизнес-процесса с балансированием на тонкой нити гармоничного сочетания творчества, искусства и строгой математики.
При этом нужно понимать, что ни один бизнес-процесс не может быть совершенным и на 100% соответствовать реальности. Всегда есть место каким-то упрощениям и допущениям, где-то при реализации даже самого строгого регламента свои коррективы вносит человеческий фактор.
Кроме того, как известно, в любой новой сущности всегда заложена возможность дальнейшего совершенствования. И создание бизнес-процессов также подтверждает этот философский тезис. Как бы вы ни старались описать бизнес-процесс идеально, все равно в нем найдется что-то такое, что также можно улучшить либо сейчас, либо – в будущем.
И здесь очень важно с одной стороны, вовремя остановиться самому, ведь обновленные бизнес-процессы будут реализовывать реальные люди, которые привыкли работать «по старинке», и нужно учитывать их косность мышления и степень обучаемости. Также и автоматизация, которая обычно входит в модернизацию бизнес-процессов, требует определенных вложений. И здесь нужно исходить из реальных возможностей заказчика.
Все это бизнес-консультант должен четко понимать сам, знать, где и на каком уровне допущений он упростил описание бизнес-процесса, а где решил отложить на будущее какие-то решения по объективным причинам (финансы, человеческий фактор). И все это нужно уметь просто и понятно объяснить руководителю бизнеса.
Технологический процесс и бизнес-процесс
Главное отличие бизнес-процесса от технологического заключается в том, что в технологическом процессе на выходе предполагается один вполне определенный результат. Например, если речь идет о производстве, то на выходе должна получиться продукция с определенными параметрами.
Конечно, даже в технологическом процессе существует вероятность получения брака, но не один из закономерных вариантов, а последствия нарушения технологического процесса. В то время как в бизнес-процессе результат «на выходе» может отличаться в зависимости от выполнения тех или иных условий в «теле» бизнес-процесса, который выполнялся без нарушений и сбоев.
Для наглядности описание технологического процесса может выглядеть таким образом:
В бизнес-процессе вполне нормальной считается следующая ситуация:
История появления термина
Я не единожды читал информацию о том, что нотации бизнес-процессов IDEF0 появилось чуть ли ни в середине XIX века. Более реалистичные авторы пишут о периоде Второй Мировой войны. Но и они ошибаются.
Например, когда я написал статью об IDEF0, некоторые читатели в качестве примеров нотаций приводили примеры каких-то инструкций из министерств и ведомств времен Первой Мировой или даже раньше, а в качестве графического отображения обсуждались схемы и наглядные изображения военных действий. Но все это не является описанием бизнес-процесса. Все вышеперечисленное можно назвать методиками, наглядной демонстрацией, инструкциями, но нельзя назвать нотациями.
Нотации – понятие современное, причем, нотациями называется нечто устоявшееся, стандартизированное, т.е. набор команд и обозначений, которыми пользуется много людей, а не одна или две организации. Можно придумать свой особый язык для описания бизнес-процессов или, например, программирования. Но пока он не получит «обкатку» в массовом использовании, не будут выявлены и устранены противоречия, неоднозначные трактовки, другие недочеты, пока он не стает устоявшимся и привычным для людей стандартом, называть его нотацией нельзя. Подробнее о нотациях я планирую написать позже. А сейчас вернемся к вопросу появления термина «бизнес-процесс».
На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда повсеместно начали использоваться информационные системы. И сам термин, и нотации понадобились изначально именно для разработки информационный систем.
Дело в том, что после начала применения информационных систем сложность организации работы людей в организациях увеличилась во много раз. Кроме того, машины не понимают абстракции, им требуется строгий алгоритм и определенный порядок введения и обработки информации. Если до начала автоматизации, когда информация переходила непосредственно от человека к человеку, проблема взаимопонимания находилась на уровне человеческих коммуникаций, то теперь появилась необходимость ее строго регламентировать.
В результате понадобилось создавать описания работы не только людей в организации, но также их взаимодействия с информационными системами. И здесь стало недостаточно текстовых нотаций (инструкций), где все описания были в свободной текстовой форме, они оказались не актуальны и неудобны. Появилась потребность в стандартизации, по сути, в создании особого языка команд и однозначной последовательности действий. Причем, в отличие от машинных языков, эти нотации должны были стать одинаково удобными для перевода в машинный код, и для восприятия человека.
Первые методологически проработанные нотации бизнес-процессов (а я буду говорить именно о методологически проработанных нотациях, например, IDEF3***) появились у военных в США. Причина очевидна – уже тогда военные в США пользовались автоматизацией с использованием удаленных соединений, т.е. той самой системой, которая позже стала Интернетом. И при таком уровне применения информационных систем потребность в нотациях бизнес-процессов была особенно актуальной.
***По теме методологически проработанных нотаций хочу также сказать пару слов. Почему я привел в качестве примера IDEF3: я еще не видел более проработанной методологически системы описания бизнес-процессов. Даже BPMN 2.0 все еще развивается и дорабатывается. А если вы почитаете англоязычное описание IDEF3 (перевода на русский я пока не видел), то также сумеете оценить по достоинству глубину его проработки.
Очень быстро методология и нотации завоевали огромную популярность в бизнес-среде.
Нотации позволили получить инструмент описания взаимодействия людей и цифровых информационных систем.
С их помощью оказалось возможным оптимизировать бизнес, т.е. получить более высокую производительность при тех же затратах.
Особенно заинтересовала бизнес возможность оптимизации. Как известно, чтобы что-то улучшить, нужно четко понимать, что вы имеете, и что из этого вы желаете изменить. И графические нотации наглядно показывали обе ситуации – отправная точка и желаемый результат, а также наиболее проблемные области. На основе этих данных выбрать оптимальный путь решения и смоделировать оптимальный вариант модернизации оказалось намного проще, чем без столь удобных инструментов.
Именно тогда появились понятия бизнес-процессов и нотаций бизнес-процессов, два неразрывно связанных понятия.
Очень важно понимать, что не существует, например, отдельного «бизнес-процесса продажи». Есть процесс продажи, который станет бизнес-процессом, если его описать при помощи нотации. Т.е. без описания в нотации бизнес-процесса вы занимаетесь продажами, это никто не оспаривает. Но пока нет определенного незыблемого и однозначного описания ваши продажи – явление, в чем-то, стихийное. А бизнес-процессом они станут только после их описания в рамках нотации и реализации этого описания на практике.
Продажи – это самый простой и наглядный пример. Каждый из нас в роли покупателя, а многие, и в роли продавца знакомы с этим процессом. И все мы знаем, что даже один и тот же человек в разных ситуациях (для разных товаров, разных покупателей, в разную погоду и вообще, в зависимости от настроения) будет продавать несколько по-разному. Но если описать и четко регламентировать определенный бизнес-процесс, то независимо от того, «с какой ноги встал утром продавец», процесс продажи будет определенным образом стандартизирован, ограничен определенными рамками, и, в результате, более стабилен.
Зачем моделировать (описывать) бизнес-процессы
Как я уже не единожды писал, я работаю преимущественно с малым и средним бизнесом, где предоставляю широкий комплекс услуг – от выявления проблем и «узких мест» в работе компании до внедрения предложенных мною решений на уровне программных продуктов и систем автоматизации.
Моделирование бизнес-процессов помогает решить сразу две задачи:
Бизнес-процессы необходимы, чтобы представить сложную информацию в простой для восприятия форме для изучения и принятия решения.
Представьте себе обычную компанию, состоящую из разных подразделений: бухгалтерия, кадры, отдел продаж, склад, доставка, производство и т.д. Над всем этим стоит один человек – руководитель бизнеса. Он физически не может на экспертном уровне понимать все виды процессов в бизнесе. Именно потому и нанимают различных специалистов. Но ему необходимо эффективно всем этим управлять, а в определенных случаях – модернизировать.
И здесь на помощь приходят бизнес-процессы. При этом определенные виды человеческой деятельности в рамках компании описываются графическими нотациями и представляются в том виде, который помогает руководству понять, как именно происходит работа на каждом из этапов, и что здесь можно улучшить. При этом руководителю компании не обязательно обладать высокой квалификацией специалиста того или иного профиля.
Конечно, на этом уровне не обойтись без некоторых информационных потерь. Невозможно описать графической нотацией все нюансы и подробности работы каждого сотрудника. Но эти информационные потери оказываются несущественными для понимания процессов в общем и принятия решения.
Как описывать бизнес-процессы
Для того чтобы получить описание реально действующих бизнес-процессов, достаточно просто внимательно изучить последовательность действий каждого сотрудника. Т.е. необходимо получить информацию о входящих данных для запуска определенного процесса, исходящих – т.е. результата действий сотрудника, а также пошагово зафиксировать действия, которые потребовались.
После того, как вся информация собрана, ее нужно перевести в графическую нотацию. Здесь стоит понимать, что именно графические нотации считаются «хорошим тоном» при составлении описаний бизнес-процессов. Для себя вы можете составлять нотацию как вам удобнее, текстовые варианты описаний также существуют и применяются, например, некоторыми разработчиками программного обеспечения. Но если вы составляете нотацию, которую будут читать другие люди, не важно, разработчик программы или руководитель компании, выбирайте графику.
Причина такого решения проста: в графическом виде информация лучше воспринимается. Если вы предложите человеку «стену текста», ему потребуется много времени и сил, чтобы разобраться, о чем вы вообще говорите. А охватить задачу целиком в этом случае – почти не реально. Другое дело графические схемы – здесь можно изучать бизнес-процессы на разных уровнях детализации, да и быстро «охватить взглядом в общем» графическую схему сможет любой человек.
Рекомендуемая последовательность действий:
Правила описания бизнес-процесса
Выше я много сказал о творческом подходе, о возможностях включения условий и вариантов действий в описании бизнес-процессов. В результате может показаться, что любое описание действий человека «на работе» можно посчитать описанием бизнес-процесса. На самом деле, существуют строгие рамки и правила, которые определяют, можно ли назвать перечень действий описанием бизнес-процесса (в графической или текстовой форме) или нет:
Распространенные мифы и заблуждения
Не «изобретайте велосипед»! Не нужно придумывать свои нотации.
Нередко люди вместо того, чтобы изучить особенности существующих нотаций, рисуют графики в произвольной форме в различных графических программах.
Я не рекомендую так поступать. Во-первых, при использовании готовых инструментов вам не потребуется изобретать свои обозначения и стандарты. Все давно придумано до вас. При этом стандартные нотации действительно понятны интуитивно, читаются однозначно, известны многим людям. Во-вторых, в готовых системах (IDEF3, BPMN 2.0 и пр.) имеется проработанная методология и строгие ограничения. Их можно воспринимать как язык программирования и среду для работы с этим языком. Здесь вы просто не сумеете совершить многих ошибок, от этого вас уберегут стандарты синтаксиса и сама среда (ограничения в редакторе, автоматические проверки).
Не путайте описания бизнес-процессы компании и бизнес-процессы IT систем.
Во многих автоматизированных системах, например, 1С или Zoho CRM, существуют собственные сущности с названием «бизнес-процессы». Но к описываемым в этой статье бизнес-процессах эти сущности не имеют никакого отношения. Считайте их «омонимами», т.е. термины вроде звучат одинаково, но в нашем случае это – описание работы компании, а в IT системах – название группы функций и отчетов.
Распространенная ошибка: Бизнес-процесс обязательно приносит ценность (прибыль).
О том, что бизнес-процессы должны приносить прибыль, я слышал даже от известных спикеров. Более того, видел даже “разбор ошибок” при создании бизнес-процесса, в котором очень много внимания уделяется тому, что 70% действий не несут никакой ценности.
На самом деле, бизнес-процессы бывают разными. Результатом каких-то будет и правда получение прибыли, например, прямые продажи. В других случаях о приобретении ценности и вообще об оценке действий с этой точки зрения говорить сложно. Например, как можно оценить, какую ценность приносит бизнес-процесс отгрузки товара или формирования и отправки налоговой отчетности?
Я считаю, что бизнес-процесс совсем не обязательно приносит какую-то ценность, если понимать ее как непосредственную прибыль компании. Внедрение процессно-ориентированного подхода и реализация бизнес-процессов направлены больше на другое — на сохранность ценности, т.е. получению большей результативности при тех же затратах.
Возможно ли создать идеальный бизнес-процесс — когда следует остановиться?
Нет. Бизнес—процесс должен быть простым, понятным, удобным, читабельным. Но идеальным он не будет никогда.
Когда я начинал работать, мне и самому все время казалось, что я что-то недорабатываю, где-то можно было бы сделать лучше. А нередко и клиенты меня просили детализировать и описать подробнее тот или иной процесс. И я это также считал своим недочетом.
На самом деле, исходя из всего выше описанного, моделирование бизнес-процесса — это некоторое допущение, процесс творческий. С другой стороны, я в свое время не знал даже что ответить на просьбы описать еще “это” и “вон то”. Но со временем я понял, что бизнес-моделирование — это не просто творчество, но некий диалектический процесс. И уже само создание бизнес-процесса всегда будет нести в себе собственное отрицание. Здесь действительно стоит подходить к вопросу с философской точки зрения. И создавая бизнес-процесс, нужно помнить, что мы не можем охватить все и сразу, а потому он всегда будет несовершенен. Но при этом мы уже закладываем в него то, что будем совершенствовать в будущем. Стоит к этому подходить просто как к факту.
Ваш бизнес-процесс должен решать поставленную задачу, отвечать на тот вопрос, который рассматривается в рамках проекта. Все остальное — вопрос будущего возможного сотрудничества. Именно так и стоит пояснять заказчикам, почему вы не детализируете какие-то процессы или не рисуете еще какой-то бизнес-процесс, связанный с обсуждаемым.
Для лучшего понимания тематики рекомендую статьи:
Разбираемся с бизнес-процессами самостоятельно
Статья о том, как самостоятельно проанализировать, описать и систематизировать процессы, и какие инструменты для этого понадобятся.
Первая часть о том, как структуризация процессов и внедрение CRM помогло интернет-магазину увеличить количество заказов и прибыль в 2 раза находится тут.
Владелец бизнеса или директор любого уровня. Рабочие процессы давно ушли «в подкорку», как при вождении машины, поэтому при росте объемов работы делегировать «лишнюю» часть задач не получается, и приходится заниматься тушением пожаров. Клонирование пока тоже работает не так, как хотелось бы. Работать в состоянии пожара над развитием бизнеса крайне затруднительно.
«Туалетное делегирование» — постановка задач ртом, никак нигде не зафиксированная, без дедлайна и контрольных точек. Будет ли задача выполнена, да еще и так, как хотел постановщик? Вряд ли. Встречается чаще, чем хотелось бы. Чревато срывом сроков, недовольством заказчиков, выплатой неустоек, шрамами на карме.
На сайт приходит все больше трафика, телефон звонит, не переставая, заявки льются со всех каналов, но продажи не растут. Если рост трафика обеспечивается ростом рекламных бюджетов, то эти бюджеты «сливаются в трубу». Трафик должен превращаться в доход. Если не превращается — ищите проблему.
Непонятно, чем занимаются сотрудники. «Вроде что-то делают». Как понять, кто имитирует бурную деятельность, а кто работает? Кто движется в сторону цели и работает на результат, а кто тащит одеяло на себя в ущерб компании?
Общение с клиентом происходит в ворохе мессенджеров, и соединяется только в голове менеджера. Если он, например, умрет — вместе с ним умрет и картина этого общения, придется собирать ее, как пазл, изо тех мессенджеров, к которым есть доступ. Нет доступа — нет и кусочка пазла. А клиент тем временем ушел к другому подрядчику, который не забывает о договоренностях, задачах, сроках и днях рождения.
Какие конкретно проблемы вы хотите решить? Управление проектами? Персоналом? Продажами? Коммуникациями? Все вместе?
Перечислите проблемы в столбик. На бумажке, в табличке, носитель не важен.
Поставьте цель напротив каждой проблемы: что получится в результате исправления или оптимизации?
Какой конкретный результат покажет, что цель достигнута?
Если цель глобальная — разбейте ее на промежуточные. Чем мельче разобьете, тем больше шансов, что доберетесь.
Проанализируйте, как «проблемы» превратить в «задачи» и какие задачи двигают вас от одной промежуточной цели до другой в сторону главной.
Часто на этапе выписывания целей и формирования задач становятся видны «узкие места», и становятся очевидными решения, внедрить которые несложно, а часть проблем решается.
Приучив сотрудников записывать каждую выполняемую задачу и трекать по ней время, вы получите четкую картину того, что происходит на проекте без дерганья человека вопросами «А чем ты сейчас занят? А сколько еще задач можно тебе поручить без вреда для здоровья? А такая задача у тебя сколько времени займет? А такая?».
Экономия исчисляется в человеко-ВЕКАХ.
Цена внедрения: одно собрание и 15 минут на перенастройку «задачника».
Если система получается слишком сложной для восприятия в виде списков, попробуйте выписывать не в столбики, а в виде майнд-карты (см.картинку), на ней хорошо видна структура взаимосвязей в системе чего угодно. О работе с такими картами — чуть ниже.
Главное во всех этих приготовлениях: не терять из виду цель. И постоянно сверяться с логикой:
Эта задача приближает меня к цели?
Этап описания похож на проектирование дома. Можно построить дом и без проекта, но получится долго, дорого, и, скорее всего, развалится, погребя под обломками строителя и всех причастных.
Материалы по ссылкам даны для примера, темы можно копать и дальше.
В условиях нехватки времени и напряженного рабочего графика на этот этап уйдет пара недель. При полном погружении можно пробежать за 2-3 дня.
Гениальный в своей простоте инструмент, который позволяет превращать мысленный хаос в стройную систему блок-схем. Общая логика схем в том, что есть родительские элементы, и подчиненные им элементы по уровням.
Мой любимый инструмент для майндмаппинга — xmind. Мне хватает бесплатной версии. Второй любимый — draw.io
Многим удобно использовать браузерную версию такого инструменты, чтобы можно было работать совместно или делиться ссылками на карты. Условно для этого подходит draw.io, но его функционал шире, там можно рисовать любые схемы, не только майнд-карты.
Часть исходных данных удобно хранить именно в таком виде. Например, структуру компании, связи между разными логическими блоками бизнеса, логику построения маркетинговой стратегии и так далее.
Карт на проекте может быть несколько:
MS Excel и Google Sheets теперь ваши лучшие друзья. У них не только супер-подробная справка, но и тонны бесплатных материалов для изучения, включая видеоуроки. Не обязательно становиться «гуру Экселя», достаточно освоить базовый функционал: как работают сами таблицы, кнопки и панельки, форматирование. Например, по этому самоучителю.
Из формул пригодятся «Математические», «Ссылки и массивы» и «Логические». По конкретным задачам легко нагуглить конкретное решение с подробной инструкцией, в том числе и видео.
Мне встречались случаи, когда все процессы, включая систему учета клиентов, были реализованы с помощью таблиц. Здесь нужно исходить из технических требований, целей, и наличия специалиста, способного поддерживать эту систему в рабочем состоянии. Если таблицы могут покрыть весь нужный функционал, то можно ими и ограничиться.
Базовое освоение Экселя с нуля обычно занимает пару вечеров, или 4-5 часов теории, перемежающихся практикой.
Более глубокое погружение требует больше времени, но насколько — сказать трудно, так как зависит от задач, которые предстоит решать. От 30 до 60 академических часов обычно достаточно, чтобы освоить его до уровня бизнес-аналитика.
Самый ресурсоемкий пункт.
Для того, чтобы перейти к конструированию процессов, придется хотя бы поверхностно ознакомиться с методологией.
Начните со статьи в Википедии про бизнес-процессы, она даст общее понимание о том, как можно описывать процессы, и какие задачи это помогает решать.
Спецификация BPMN описывает условные обозначения и их описание в XML для отображения бизнес-процессов в виде диаграмм бизнес-процессов. BPMN ориентирована как на технических специалистов, так и на бизнес-пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции.
После этого можно перейти к изучению BPM-концепции и нотаций BPMN 2.0, так как они, на мой взгляд, ближе всего к логике «обычного» человека.
Я показывала готовые BPMN 2.0-схемы людям, далеким от темы, и они могли их читать и понимать, без подготовки. Другие системы, например, IDEF0 и EPC, ближе инженерам и программистам, в них не так хорошо читается хронологическая последовательность событий, поэтому их можно не трогать.
На Хабре, например, есть много хороших статей про бизнес-процессы и практическое применение нотаций BPMN 2.0.
Посмотрите видео (вебинары и уроки), и сразу начинайте рисовать свои процессы. Любые. Хоть поход в магазин за хлебом или разбор утренней почты.
На сайте ELMA есть замечательный бесплатный курс по BPMN.
Мой любимый конструктор, поддерживающий BPMN: camunda-modeler, в нем создана схема на картинке выше. На самом деле, Camunda — это «приложение для автоматизации бизнес-процессов», но я использую только его моделлер, как рисовалку (хаха). Потому что мне там удобно и красиво. В отличие от той же ELMA, например.
Подробная схема процесса, нарисованная в любом моделлере, позволяет «возвыситься над ситуацией», взглянуть со стороны, например, на пути прохождения заявок, и взаимодействие людей вокруг этого пути. Попробуйте начать рисовать любой процесс, имеющий какие-то нюансы, и поймете, что я имею в виду.
Схема процесса пригодится для создания грамотного ТЗ системному интегратору, поможет понять, какие части процесса можно перераспределить между исполнителями, в каких местах «визуально» можно подключить какие-то сервисы.
Путь до первой осознанной схемы занимает около недели, если тратить на изучение материалов хотя бы 2 часа в день.
Изучение же логики процессов, нюансов разных методологий и способов реализации может продолжаться всю жизнь =)
Подбирается по цене и функционалу, указанному на сайте выбранной системы. После проработки схемы процесса в голове уже сложится представление о том, что и как должно работать, а из этого станет понятно, какой функционал потребуется для реализации.
Рекомендую изучить сравнения и обзоры, чтобы понять, какая максимально отвечает требованиям. Примеры названий подобных статей: «Что выбрать? Сравнение шести популярных CRM систем», «Пятеро разных: как я выбирал CRM для своего сервиса». Нужно принимать во внимание, что статья может склонять в сторону какой-то конкретной CRM, поэтому чем больше таких статей изучить, тем более объективное понимание сложится.
Приведу пример последнего клиента, по каким критериям мы сравнивали CRM, что в итоге выбрали и почему.
Задача: Объединить 6 пользователей в единую систему, и перестать терять лидов. Телефонию, аналитику, регламенты, скрипты продаж — тоже надо иметь внутри системы. Максимально автоматизировать всё, что там можно автоматизировать: постановка задач в ответ на действие пользователя, контроль, SMS и e-mail уведомления клиентов, аналитика, отчеты.
Выбрали в итоге Б24, по совокупности факторов:
Минусы, конечно, тоже есть:
У любой популярной CRM на сайте есть разделы «Обучение» и «Справка», этого достаточно, чтобы провести базовую настройку системы и начать ею пользоваться. У большинства есть бесплатный пробный период от двух до четырех недель. Платные системы предоставляют оперативную техподдержку, отвечают на вопросы страждущих. На YouTube есть видеоуроки по всем популярным системам.
Вы уже определили свои цели и задачи, и задокументировали бизнес-процессы? Тогда с выбором CRM и ее базовой настройкой вы тоже справитесь! Ура!
Самый расплывчатый пункт.
Самый расплывчатый пункт. Что за сервисы? Зачем? Почему? Опять же, отталкиваемся от целей и задач: телефония/рассылки/склад/задачи/бухгалтерия/чертзнаетчтоеще, не входящее в функционал CRM. Хотя есть некоторые CRM, в которых «из коробки» настолько богатый функционал, что никакие дополнительные сервисы и не понадобятся.
Возвращаясь к примеру из пункта 4, расскажу о том, как и какие сервисы мы выбирали. Так как почти весь нужный функционал покрыла CRM, нам осталось выбрать сервисы для колл-трекинга, телефонии, и SMS-рассылок.
Получилось как-то так (кликабельно):
Зеленым помечены те варианты, на которых в итоге остановились.
После выбора можно связаться с техподдержкой, и получить помощь в настройке, так как любой платный сервис заинтересован в том, чтобы клиент остался с ним на веки вечные.
Еще где-то здесь должна быть аналитика, но базовые аналитические отчеты можно построить и без особой подготовки, используя внутренние возможности сервисов и CRM. Построение же единой общей системы сквозной аналитики — это целый отдельный мир, и тема для другой статьи.
Надеюсь, эта статья поможет всем заинтересованным в теме понять, что не так страшен черт, как его малютка, и любой человек, изучив предложенные материалы, сможет начать описывать и оптимизировать процессы вокруг себя.
Если хотя бы 1 человек это сделает, сердце мое наполнится радостью и счастьем.
В следующих статьях планирую ответить на вопросы:
Конечно интересно.
За ссылки по BPMN отдельное спасибо. Активно изучаю эту тему для дальнейшего применения в своей работе.
Крутая статья, спасибо. Очень буду ждать продложение. Хочу пообщаться вживую, оставьте контакты в личку.
не знаю, где тут личка.)
пишите в фб или вк Mariia Paap (Ma Xa)
Открывая статью, не ожидал ТАКОГО погружения в тему! Я даже не предполагал, насколько она может быть глубока! Да с такими знаниями офигенные горизонты светят, как специалисту)
Успехов и жду дальнейших статей!
Лайк-подписка-колокольчик)
какая хорошая статья.
я пошла изучать всё на свете + жду продолжения. х)
Если реально хотите разобраться в теме лучше изучите BABOK или почитайте статьи по BPMN, но не берите за основу эту статью, скорее всего у вас сформируется ложное понимание, что по сути хуже всего.
Интересно, насколько внимательно вы прочитали статью? Ok, на BABOK ссылки не было, но теперь она есть в комментариях.) но ссылка на статьи про BPMN и даде на целостный курс по BPMN там есть.
в чем же ложность понимания?
Абсолютно клиповая статья с полным отсутствием минимального набора сведений по методологии анализа — то есть приведён бессвязный перечень тезисов, который составляет неправильное/неполное = ложное представление/клиповое представление.
Статья выглядит как набор новостей ТВ из мира анализа. Тогда как нужно быть стратегом как Суворов. Хороший аналитик от плохого отличается наличием стратегии, а не тактики, как и хороший анализ.
Любой текст в виде случайных бессвязных обрывков с громким названием — это в моем понимании гораздо хуже, чем даже крохотное оглавление BABOK на 9 страниц.
Если вырвать гайку из двигателя — это не значит, что вы полетите.
Если вырвать рандомные тезисы из полного списка тезисов по теме — это просто гайка, а не двигатель.
Спасибо за конструктивную критику. В методичке обязательно построю всё как надо.
Слишком уж о многом хотелось в статье рассказать. Понятно, что получилось только по поверхности пошкрябать.
Вторая часть уже вышла, в профиле у меня висит =)