Как узнать сколько BPM?
Как понять сколько BPM?
Когда вы почувствовали ритм песни, засеките, сколько щелчков пальцами, кивков или притопов ногой вы сделаете за 15 секунд. Умножьте полученное число на 4 и получите количество ударов в минуту. Например, если вы насчитали 24 удара за 15 секунд, то, умножив 24 на 4, вы получите 96. Это и будет темпом песни.
Сколько BPM в разных жанрах?
Даб: 60-90 bpm. Хип-хоп: 60-100 pbm. Хаус: 115-130 bpm. Техно/транс: 120-140 bpm.
Как понимать метроном?
Сколько bpm в музыке?
BPM — это количество четвертных нот в минуту, например, 120 BPM означает, что в минуту играется 120 четвертных нот (следовательно, 2 четверти в секунду), или 120 четвертных ударов метронома в минуту.
Как определить темп музыки в FL Studio?
Темп – это ключевой показатель скорости ритмических ударов в минуту. В Fl studio показатель темпа вы можете посмотреть сверху вот в этом окошке. Поменять темп можно зажав левой кнопкой мышки на указатель темпа и двигая мышку вверх или вниз ваш показатель будет меняться. У каждого жанра есть свои темпы а т.
Сколько BPM в Дрилле?
Дрилл-музыка зародилась в Чикаго в начале десятилетия благодаря таким артистам как Chief Keef и Pacman. Главные особенности нового рэп-поджанра это медленный темп (70 bpm против 140 bpm у трэпа и 160 bpm у грайма), жёсткая и местами жестокая лирика и нигилистический посыл.
Сколько BPM в трансе?
Характерные признаки: гимны, повторяющиеся музыкальные фразы, арпеджио, минорные гаммы, внимание к тембрам и гармоническим партиям, темп как правило от 135 до 150 ударов в минуту.
Сколько BPM в секунде?
Темп измеряется в BPM (количество ударов в минуту). Отметка темпа в 60 BPM равна одному удару в секунду, а в 120 BPM — двум ударам в секунду.
Как подогнать песню под темп?
Что такое темп в музыке кратко?
Темп (итал. tempo от лат. tempus время, нем. Zeitmaß) — мера времени в музыке, упрощённо — «скорость исполнения музыки».
Как узнать сколько BPM?
Как понять сколько BPM?
Когда вы почувствовали ритм песни, засеките, сколько щелчков пальцами, кивков или притопов ногой вы сделаете за 15 секунд. Умножьте полученное число на 4 и получите количество ударов в минуту. Например, если вы насчитали 24 удара за 15 секунд, то, умножив 24 на 4, вы получите 96. Это и будет темпом песни.
Сколько BPM в разных жанрах?
Даб: 60-90 bpm. Хип-хоп: 60-100 pbm. Хаус: 115-130 bpm. Техно/транс: 120-140 bpm.
Как понимать метроном?
Сколько bpm в музыке?
BPM — это количество четвертных нот в минуту, например, 120 BPM означает, что в минуту играется 120 четвертных нот (следовательно, 2 четверти в секунду), или 120 четвертных ударов метронома в минуту.
Как определить темп музыки в FL Studio?
Темп – это ключевой показатель скорости ритмических ударов в минуту. В Fl studio показатель темпа вы можете посмотреть сверху вот в этом окошке. Поменять темп можно зажав левой кнопкой мышки на указатель темпа и двигая мышку вверх или вниз ваш показатель будет меняться. У каждого жанра есть свои темпы а т.
Сколько BPM в Дрилле?
Дрилл-музыка зародилась в Чикаго в начале десятилетия благодаря таким артистам как Chief Keef и Pacman. Главные особенности нового рэп-поджанра это медленный темп (70 bpm против 140 bpm у трэпа и 160 bpm у грайма), жёсткая и местами жестокая лирика и нигилистический посыл.
Сколько BPM в трансе?
Характерные признаки: гимны, повторяющиеся музыкальные фразы, арпеджио, минорные гаммы, внимание к тембрам и гармоническим партиям, темп как правило от 135 до 150 ударов в минуту.
Сколько BPM в секунде?
Темп измеряется в BPM (количество ударов в минуту). Отметка темпа в 60 BPM равна одному удару в секунду, а в 120 BPM — двум ударам в секунду.
Как подогнать песню под темп?
Что такое темп в музыке кратко?
Темп (итал. tempo от лат. tempus время, нем. Zeitmaß) — мера времени в музыке, упрощённо — «скорость исполнения музыки».
Популярность BPM в разных жанрах музыки. Python: анализ скорости исполнения 500 лучших песен
Несколько лет назад, занимался изучением теории музыки, продавал и писал аудио-инструментал для аренды или заказов. Изначально, процесс явно творческий, но вскоре, мой интерес к коммерческой части превысил и возник вопрос: «В каком же темпе создавать ритм музыки?».
BPM [в музыке] — показатель, для определения скорости исполнения композиции, путём измерения количества тактовых долей в минуту.
1: Пролог
Устанавливаем «Matplotlib» и «Pandas» с необходимыми зависимостями через pip-менеджер в консоли/терминале.
Создаём директорию, а потом виртуальное окружение для проекта. После, подключаем библиотеки в IDE [в моём случае: PyCharm].
File — Settings — Project: [. ] — Python Interpreter
2: BPM
BPM будем вычислять через функцию «Detect tempo» в FL Studio и через сайт tunebat.com
ПКМ по верхней левой иконке на звуковой дорожке — Detect tempo — Выбрать диапазон
3: DataSet
Начинаем создание DataSet’а [выборки-коллекции данных] в Excel, для каждого жанра. Экспортируем в CSV-формат с настройками разделителя — запятой. Следующие CSV-файлы создавал в IDE, так удобнее. Выборки перемещаем в директорию, где находится файл самой программы.
В первой строке CSV-файлов указываются параметры, которые разделяются запятыми. Следующие строки содержат уже значения этих параметров. При окончательной проверке, DataSet должен последовательно содержать данные: названия трека, BPM и год выхода композиции. Будем использовать информацию выборки в сто песен, для каждого жанра из выбранных пяти.
Параметры: «name» — название трека; «bpm» — темп; «year» — год релиза
4: Rap — построение точечной диаграммы и гистограммы
На основе информации DataSet’а, создаём точечную диаграмму [Scatter Plots] для изучения взаимосвязи между BPM и годом выпуска, а также для отображения концентраций при ранжировании данных.
Видно, что с 1980 по 2005 гг. основным темпом был диапазон в 90-105 BPM «Код точечной диаграммы с комментариями»
Если диаграмма отражает точечное положение трека в зависимости двух переменных, — BPM и года релиза, — то гистограмма покажет частоту-количество попаданий значения BPM для каждого диапазона на шкале. Таким образом, определится популярность определенного темпа.
Самый популярный диапазон: 80-100 BPM «Код гистограммы без комментариев»
5: Рок
Однозначности пока что нет, — особенность жанра. — поэтому, второй график построен при округлении параметра «year/год выхода композиции».
«Код точечной диаграммы с комментариями»
6: Блюз
Видно высокую концентрацию использования темпа около 100 BPM в 90-х «Код точечной диаграммы с комментариями»
7: Chillout
Много наложений точек друг на друга. К сожалению, не знаю, как это исправить. Пришлось сделать точки более прозрачными, с помощью аргумента «alpha» функции «.scatter».
«Код точечной диаграммы с комментариями»
8: EDM
Здесь также для наглядности пришлось сделать точки ещё более прозрачными. Если кто-то знает, как исправить дефект наложения, прошу написать в комментариях.
Довольно однозначно вышло. «Код точечной диаграммы с комментариями»
9: Заключение
Самым простым графиком сравним количество попаданий в каждый диапазон, композиций, из всех проанализированных ранее жанров*.
* такие жанры как ethnic, ambient, folk, dubstep, reggae и др, не удалось к сожалению разобрать из-за отсутствия качественной выборки.
Все что вы хотели узнать о BPM, но боялись спросить
В сети имеется множество публикаций о том, ради чего стоит внедрить BPM (Business Process Management) в вашей компании. Как обычно формулируются преимущества, которые дает бизнесу внедрение BPM:
На самом ли деле все так безоблачно? Не пора ли всем выбросить старые инструменты, и полностью перейти на новую платформу?
Я хотел бы рассказать о том, какие проблемы могут вас ожидать в процессе внедрения, а точнее — при разработке реальных приложений. Мои впечатления основаны на опыте работы с платформой IBM Websphere BPM, для определенности — с версиями с 7.5 по 8.5 включительно.
Рассмотрим перечисленные ранее пункты по порядку.
Визуальное моделирование
Чего мы пытаемся добиться? Чтобы аналитики, или даже бизнес-пользователи, могли нарисовать диаграмму процесса, которая затем будет выполнена ровно в таком же виде сервером. Или хотя бы могли понимать суть процесса, посмотрев на диаграмму, нарисованную кем-то другим.
Получаем ли мы то, чего хотели добиться? Скорее нет, чем да.
В чем тут корень проблемы? Я бы сказал, что их два:
Практика показывает, что без этих составляющих процесс практически бесполезен, и в тоже время, они на типичной BPMN диаграмме не видны.
С другой стороны, бизнес-процессы — это программное обеспечение, пусть и несколько необычное. Процессы имеют иметь достаточно длинный цикл разработки и сопровождения, причем удобство сопровождения достаточно быстро становятся важным. Также, весьма важным является управление изменениями в приложении вообще, причем в тесной связи с так называемыми issue tracking системами (например, JIRA). То есть, нам нужно знать, кто, когда, какие именно и зачем вносил изменения в процесс, и в рамках каких задач.
Таким образом, с одной стороны, у бизнес-пользователей создается скорее ложное впечатление, что они понимают логику процесса, часть которой от них скрыта в коде. С точки же зрения разработчиков представление в виде диаграммы лишь усложняет разработку, в первую очередь потому, что диаграммы плохо согласуются с жизненным циклом разработки, в том числе — с управлением изменениями.
Инструментарий
Теперь о поговорим о методах и инструментах для разработчика.
Если для традиционных средств разработки более-менее придуманы средства (например, рефакторинга), метрики и методики измерения, которые позволяют оценивать размеры проекта (в строках кода, обычно), и такие факторы, как покрытие тестами, число потенциальных ошибок на единицу кода, сложность кода, и многое другое, то при переходе к BPM о многом из этого можно забыть. Во всяком случае, мне неизвестны какие либо работы в этом направлении. Это в каком-то смысле отбрасывает разработку на много лет назад. Нужно заново учиться рефакторить, собирать статистику по проектам, и учиться оценивать их сложность и размеры, чтобы правильно планировать разработку.
Так, инструменты для анализа кода и автоматического рефакторинга, на практике не существуют. Хуже всего то, что само создание таких инструментов под большим вопросом. Представим себе достаточно типичный сценарий разработки на более традиционной платформе. У вас есть система версионирования, скажем SVN или Git, есть среда разработки (IDE), и есть другие инструменты. Так вот, если ваша любимая IDE чего-то не умеет, вы можете, как правило, либо разработать для нее расширение, либо применить сторонние инструменты непосредственно для работы с кодом. Например, copy&paste детектор, или любой другой инструмент, множество примеров которых известно нам с момента появления UNIX. Это стало возможным потому, что код вашей программы традиционно является просто текстом. Вы можете воспользоваться любым инструментом, и перенести измененный код обратно в Git, или просто собрать нужную статистику, провести анализ кода, и т.п.
В случае BPM такой подход вам недоступен, или сильно ограничен. Нельзя автоматизировать многие рутинные операции, и не всегда есть доступ для разработки сторонних инструментов автоматизации. Доступ к коду процесса хотя и возможен, но скорее теоретически — вы можете экспортировать процесс в виде набора схем BPMN, и применить различные инструменты для анализа кода — при условии, что сами их и разработаете.
В итоге такая тривиальная на традиционных платформах задача, как единообразное изменение свойств множества элементов диаграммы процесса вместо чего-то вроде Find&Replace выливается в унылую рутинную работу, которую можно сделать только руками, и которая заставляет вас ненавидеть этот инструмент уже через пять минут.
Ну и последнее, но вовсе не по важности. Если для более традиционных проектов вы умеете оценивать размеры создаваемого приложения (в строках кода, например), неформально, или согласно какой-либо модели типа CoCoMo, то в случае BPM вы оказываетесь в непонятной ситуации. У вас минимум два вида кода — диаграммы, и «обычный» язык программирования, возможно даже не один. Сколько времени нужно, чтобы нарисовать диаграмму процесса? От чего это зависит? В чем измерять «размер» и сложность диаграмм? И если для обычного кода вы можете применить известные модели для оценки трудоемкости, то для диаграмм подобные модели не построены и вопросы не имеют ответов.
Набор готовых компонент и повторное использование
Некоторые нужные компоненты для построения процессов: условия, параллельные ветки, ожидания, события конечно же имеются. Только вот их уровень является достаточно низким, а возможности комбинирования, и в итоге, повторного использования готовых компонент, оставляют желать много лучшего.
В процессе эволюции инструментов разработки и языков программирования способы создания повторно используемых компонент давно выработаны и более-менее устоялись. В основном они сводятся к типам данных и функциям над этими типами, а также к средствам композиции этих базовых элементов в законченное приложение.
Попробуйте, для примера, организовать в процессе цикл, пользуясь только стандартным набором средств. Вы как будто вернетесь во времена, когда в книгах по программированию еще рисовали блок-схемы — то есть, лет на 40 назад. Другой весьма типовой, но далеко не тривиальный случай — когда вам нужно организовать асинхронное взаимодействие с внешним для вас сервисом, то есть отправить ему запрос, и потом дождаться ответа. Даже если нужную вам логику вы можете реализовать — у вас вряд ли получится использовать ее повторно в другом похожем процессе, потому что реализация будет разбросана по приложению таким образом, что выделить повторно используемый компонент окажется невозможным. Причем корень зла в данном случае тривиален и лежит на поверхности: BPMN не содержит того, что называется «функции высшего порядка», если говорить терминами ФП. Или generics, если вспомнить ООП и Java. Вы не можете написать обобщенный компонент, например для сортировки списка, абстрагируясь от типа элемента списка. Вы не можете передавать функции (активные компоненты) как параметры. Тут нет способа описать метакомпонент, если можно себе позволить его так назвать.
На сегодня две парадигмы в виде функционального программирования и ООП можно считать преобладающими. В случае же с BPM таковых разработок нет, и текущее состояние теории прямо скажем, плачевное. Фактически, нет даже самой парадигмы — есть лишь некоторые практики, которые лишь с ограничениями могут быть рекомендованы к применению. Более того, если скажем функциональное программирование базируется на математике, и в некоторых случаях правильность программы может быть доказана формально, а в случае ООП и процедурного программирования иногда можно доказать правильность хотя бы частично, в случае BPM я не слышал про подобные работы.
Не определены и подходы к рефакторингу и тестированию процессов. Нет даже самого понятия рефакторинг. Все выгядит так, как будто разработчики инструмента считают, будто процесс строится раз и навсегда, и никогда не развивается. И в нем не бывает ошибок, технического долга, запахов и прочего.
При этом, поскольку процесс зачастую является набором параллельных активностей, и не может быть выполнен вне системы BPM, написание тестов также является задачей на сегодня не решенной. Имеющиеся для этого средства нельзя считать адекватными, при том что на сегодня тестировать можно только сервисы — т.е. синхронные компоненты процесса, для тестирования же самих процессов как BPMN-диаграмм (особенно с параллелизмом) автору никакие средства не известны (хотя они могут быть разработаны, имеющихся API для этого достаточно, но это задача непростая).
Поддержка версионности процесса
Все программы развиваются. Если программа не развивается — это скорее всего никому не нужная программа. Исключения бывают — но они очень редки. Это означает, что BPM процесс может и должен развиваться, и проходить через несколько версий. Эти изменения нужно отслеживать. Иногда мы развиваем две ветки приложения — скажем, багфикс для версии 1, и новую версию 2. Иногда нужно сливать изменения в них в одну версию.
Почему в случае с BPM все это получается плохо?
Во-первых, изменения плохо обозримы. Исходным видом диаграммы является не текст, а картинка. Квадратики, стрелочки, ромбики. И в сравнении с обычным кодом в виде текста, который как правило одномерный, и для которого давно определены всякие операции типа diff/merge/patch и пр., тут добавляется несколько новых измерений. Например, цвет раскраски квадратиков, или их взаимное расположение на листе. Вы получаете значительный уровень информационного шума, просто потому, что часть изменений диаграммы ровным счетом не влияет никак на ее работу.
В итоге, у нас нет такой простой и очевидной возможности, которую со времен unix принято называть словом diff. Вы не можете просто и автоматически сравнить две разные версии процесса между собой, на разных уровнях подробности (т.е. приложение, диаграмма процесса, компонент, часть диаграммы, строка кода на каком-либо языке).
В лучшем случае вы знаете, что такого-то числа такой-то пользователь изменил некий диаграмму. Что именно, зачем, и в чем собственно состояло изменение — вы узнать не можете, или это затруднительно. Все что имеется — это возможность открыть (для чтения), и посмотреть, как выглядела конкретная версия. При этом данный процесс вовсе не быстрый. И самое существенное — вы видите не разницу, вы видите либо одну, либо другую версию кода. Сравнивать и понимать, где есть различия — это ваша задача, и она оказывается совершенно нетривиальной.
И вторая привычная возможность — это merge или хотя бы patch. Она также отсутствует де-факто. Вы не можете перенести изменения из одной ветки в другую, из одной версии в другую, в том числе — выборочно, сохранив изменения, внесенные в обеих ветках. Практически это лишает ветки какого-либо смысла.
Соответственно, когда мы говорим о гибкости бизнес процессов — мы всегда должны иметь в виду только что рассмотренную проблему. Мы можем менять процесс как угодно гибко — но мы очень редко при этом будем точно знать, что конкретно поменялось. И когда что-то сломается — поиски причины могут вылиться в длительные раскопки в коде.
Итак, кратко просуммирую еще раз некоторые проблемы:
А что у других?
Так сложилось, что в текущем проекте мне пришлось столкнуться с очень в чем-то похожим продуктом. Это MS Business Intelligence Development Studio, и то, что в ней разрабатывают — SQL Server Integration Services. И вот что очень характерно — этот совершенно другой продукт, сделанный другой компанией для других задач, пытается в чем-то достичь тех же целей, и сталкивается ровно с теми же проблемами.
Обзор системы bpm’online
Я профессионально занимаюсь автоматизацией продаж и бизнес-процессов на разных предприятиях, постоянно интересуюсь продуктами, которые может предложить современный рынок программного обеспечения. И в будущем планирую написать еще 2 или 3 обзора популярных площадок для автоматизации продаж, после чего планирую написание статьи, в которой, основываясь на собранной информации, проведу сравнение разных CRM‐систем.
Вплотную CRM‐системами я лично занимаюсь более 2 лет, и за это время ко мне несколько раз обращались заказчики, которые интересовались внедрением системы bpm’online. По разным причинам другие предложенные CRM‐системы этих клиентов не устраивали. Как результат – у меня появился практический опыт внедрения bpm’online для разных компаний.
Что такое bpm’online?
Сервис управления продажами bpm’online я планирую рассматривать как CRM‐систему, тем более, что в отличии от того же Битрикс24 ил Мегаплана создатели bpm’online делают особый акцент на управлении продажами.
И для начала хотел бы напомнить, что такое CRM‐система:
CRM‐система (Customer Relationship Management или Управление отношениями с клиентами) — это — прикладное программное обеспечение для организаций, предназначенное для автоматизации стратегий взаимодействия с заказчиками (клиентами), в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путем сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процессов и последующего анализа результатов.
Подробнее о том, Что такое CRM‐системы и как их правильно выбирать? Читайте в моей статье, которая полностью посвящена этой теме. Систему bpm’online выпускает компания Terrasoft. Этот онлайн‐сервис имеет несколько глобальных модулей:
Эти модули чем‐то напоминают Saleforce, здесь также имеет место несколько, вроде как, близких друг другу направлений и сложная и запутанная система лицензирования. Хорошо это или плохо? Для пользователей и покупателей программных продуктов – плохо, так как очень сложно разобраться, что им нужно, а что – нет. Для компании вендора, скорей всего, хорошо.
Я давно заметил, что часть компаний преднамеренно ведут такую маркетинговую политику, при которой пользователь путается в продуктах компании, после чего пользуются его растерянностью и недоумением для того, чтобы направить клиента к своим партнерам, которые будут внедрять, обслуживать клиента, и, конечно же, постараются получить при этом максимальную прибыль.
В этом обзоре я буду говорить о возможностях пакета bpm’online sales, так как именно этот модуль наиболее соответствует по своим возможностям определению CRM‐системы.
Вся информация, которую предоставляет производитель о возможностях bpm’online sales, расположена здесь: https://www.terrasoft.ru/sales По этой же ссылке вы можете при желании зарегистрироваться, получить возможность бесплатно изучить тестовую версию системы или приобрести полноценный пакет для работы с 30‐дневным бесплатным периодом.
Анализировать я буду систему с самым широким спектром возможностей, это пакет enterprise, просто потому, что так удобнее увидеть все, что может предложить эта система. Возможности разных пакетов, а также их стоимость вы можете изучить на официальном сайте продукта здесь: https://www.terrasoft.ru/sales/price
Структура системы bpm’online sales Система управления продажами приставлена в 3 вариантах:
Структура системы строится на основе широкого перечня разделов:
О том, какими возможностями отличается тот или иной раздел, вы можете почитать на официальном сайте bpm’online sales на странице Документация. Я буду подробно рассматривать только те возможности, которые касаются непосредственно CRM, т.е. работы с покупателями.
Сегодня многие CRM‐системы включают в себя широкий перечень дополнительных возможностей, таких, как управление проектами, возможность работы с документами и т.д. Чаще всего, эти дополнения оказываются не просто ненужными, но вредными, так как вносят дополнительную путаницу. Есть такой недостаток и в системе bpm’online sales. Разделы, которые не имеют отношения к продажам, я подробно рассматривать не буду и напротив, максимум внимания постараюсь уделить непосредственно работе с покупателем и продажами.
Основные модули системы:
Также важно понимать, что в системе разработчиками заложен процессный подход. Здесь нет четкого распределения на репозитарии данных. В системе bpm’online sales вы не сможете работать отдельно с лидами или, например, заказами. Здесь каждый элемент является частью системы, связан с другими разделами, и, как и любая часть процесса, должен куда‐то уходить для дальнейшей работы.
Раздел Лиды
Лид (lead, целевой лид) — потенциальный клиент, тем или иным образом отреагировавший на маркетинговую коммуникацию. С точки зрения системы bpm’online sales: Лид (lead) — это факт потребности клиента в ваших товарах и услугах.
Процесс работы с Лидом делится на 3 части:
С моей точки зрения такой жесткий процессный подход является недостатком системы, так как при этом разработчики жестко навязывают определенную бизнес‐модель, далеко не всегда являющуюся оптимальной.
Пользователь обязан последовательно пройти все этапы работы с лидом. Причем, этапы эти непрозрачны, переход от одного этапа к другому немного запутанный и оставляет множество вопросов.
Например, после создания Лида появляется возможность нажать на кнопку «Квалифицировать» и перевести его во что‐то другое. Что такое Квалификация? В других системах аналогичные действия называются «преобразовать», «сконвертировать». Здесь выбрали слово «Квалификация», после которой Лид попадает в Контакты.
Таким образом, Лид остается исключительно лидом в его изначальном значении (входящим интересом потенциального покупателя) до момента «Квалификации». Далее с Лидом работает какой‐то сотрудник, и после чего либо квалифицирует лид в Контакт, либо – дисквалифицирует его.
Система bpm’online sales не просто привязывает действия пользователей к определенной бизнес‐модели, она также вводит собственную терминологию, отличную от других аналогов. И даже известные термины здесь могут означать не совсем то, к чему привыкли пользователи других CRM‐систем. Это обязательно нужно учитывать при работе с bpm’online sales.
Раздел Контакты
После того, как Лид был внесен в систему и по итогам переписки или телефонного общения прошел Квалификацию, он становится Контактом.
Контакты — это контактные лица ваших клиентов и партнеров, частные клиенты, сотрудники, а также прочие деловые и личные контакты.
В данном случае определение, которое дает система bpm’online sales, ничем не отличается от привычного.
Вся дальнейшая работа будет проводиться уже с контактами. Для контакта можно создавать Заказ или Продажу, с ним ведется основная работа в системе. Контакт можно создать с нуля вручную, а можно – на основе Лида при помощи Квалификации. У самого Контакта уже нет никаких жестких этапов работы (квалификации/дисквалификации). С Контактом можно работать относительно свободно.
Карточка Контакта состоит из множества вкладок: Основная информация, Место работы, Лента, Файлы и т.д. В принципе, карточка и список контактов ничем не отличаются от большинства аналогов. Но и здесь есть некоторая перегруженность информацией и возможностями, как и везде в системе bpm’online sales.
В карточке Контакта есть обязательные к заполнению поля, т.е. разработчики также заранее выбрали, какую информацию вносить нужно обязательно, какую – желательно. Но, в общем, настройки просты и проблем с этим разделом обычно не возникает.
Раздел Контрагенты
Контрагенты – это компании‐клиенты, с которыми пользователь может иметь какие‐то юридические взаимоотношения. Т.е. с контактом ведутся непосредственные переговоры, от контакта принимается заказ, но оформляется продажа на юридическое лицо Контрагента.
Контрагент может иметь один или несколько привязанных к нему Контактов, которые привязываются через вкладку «место работы». Карточка Контрагента также может иметь множество вкладок с разными полями. Как и Контакты, элементы этого раздела настраиваются, и могут быть такими, как нужно пользователю.
Раздел Продажи
После того, как пользователь заполнил Лид, Контакт, Контрагента, т.е. указал, с кем производится работа отдела продаж, можно переходить к оформлению непосредственно Продажи. И если предыдущие разделы, несмотря на некоторые особенности, в принципе, стандартны и привычны для многих CRM‐систем, то продажи стоит рассмотреть подробнее.
Продажи в bpm’online sales являются аналогом Сделки, которая принята в других CRM‐системах. Продажа (Сделка) – это важный документ, отражающий определенный бизнес‐процесс, и здесь обязательно должны быть указаны:
Стадия и потребности указываются вручную в соответствии с реальным положением вещей. При этом именно на основе этих полей строится сам бизнес‐процесс. Большая часть работы с Продажей точно такая же, как и в других CRM‐системах.
Обязательно указывается ответственный за Продажу (менеджер), стадия продажи должна соответствовать реальности, в Продаже можно указать ориентировочный бюджет сделки, вероятность положительного решения и другую важную для работы с клиентом и анализа эффективности работы информацию.
Важная особенность Продажи в bpm’online sales: здесь, как и в других разделах, разработчики предлагают свое видение бизнес‐процесса.
Плюсом является то, что Продажа все‐таки настраивается под те или иные потребности. Но если вы только начинаете работу в системе и смотрите на интерфейс Продажи, предлагаемый по умолчанию, вы обязательно увидите вкладки: Тактика и Конкуренты.
В этих вкладках отражаются сильные и слабые стороны вашей компании в сравнении с предложениями конкурентов, т.е. SWOT‐анализ сильных и слабых сторон компании, на основе которых менеджер или руководитель может разработать и указать тактику продажи.
Для российской действительности эти данные являются лишними и будут вносить дополнительную путаницу в работу отдела продаж. А потому от них лучше всего сразу отказаться. Дело в том, что рынок в России пока еще нельзя назвать сложившимся, а потому получение информации о конкурентах, их ценах, преимуществах – это сложный и трудоемкий процесс. И если на уровне разработки общей стратегии работы компании такой анализ проводить периодически необходимо, то на уровне каждой продажи проверять и анализировать сильные и слабые стороны я считаю излишним.
Что такое потребность?
Во всех перечисленных выше разделах, начиная от карточки Лида и оканчивая Продажей, есть такой раздел – Потребность. Что это такое и что в нем указывают? В Потребность вносят весь перечень товаров/услуг, которые нужны клиенту.
Потребность – это категория, которая может потребоваться для аналитики и планирования будущей работы. Но, на самом деле, к системе CRM этот параметр не относится. Продавать можно только то, что имеется на остатках, можно заказать «под клиента» или произвести своими силами. В Потребности входят также пожелания, касающиеся товаров и услуг, в принципе не предоставляемых компанией. И нужны они для анализа и планирования развития компании на уровне руководства, что явно не относится к компетенции отдела продаж. Тем не менее, такой параметр в системе имеется, и выписывать Счета или создавать Заказы можно, в том числе, на основе Потребности.
Раздел Заказы
Такие документы, как Договор, Счет и Заказ создаются на основе Продажи в тот момент, когда продавец получает согласие покупателя на оформление сделки. Но здесь возникает проблема, о которой я писал в статье Выбор CRM. Частые вопросы и ответы :
Казалось бы, заказ – это часть процесса продажи. Но при этом товарные остатки, взаиморасчеты, заказ поставщику – все это относится к системе учета, используемой в вашей компании.
Так, если вы хотите зарезервировать товар, это действие затрагивает напрямую работу со складом. А это – остатки, резерв для других заказов, брак, списание, оприходование товаров и т.д. И резервировать товары без остальных функций учета товарных остатков невозможно. А в CRM‐системе инструментов для полноценного складского учета не предусмотрено просто потому, что она предназначена для других целей.
А потому, чтобы вести систему Заказов в bpm’online sales, понадобится постоянно обмениваться данными с системой учета, причем, этот обмен должен проходить очень часто. А если продажи и движения по складу происходят в компании часто, если с остатками товаров могут работать одновременно разные люди, то гарантированно актуализировать в CRM‐системе товарные остатки не реально. А потому полноценно использовать функционал Заказа также становится невозможно.
При этом вполне реально использовать Счета для оплаты каких‐то услуг клиенту, а Заказы для того, чтобы зафиксировать сумму и в дальнейшем контролировать оплату. С другой стороны, такое наполовину «искусственное» применение Заказов и Счетов не корректно. Для того чтобы контролировать отгрузку и оплату необходимо произвести качественную интеграцию bpm’online sales с учетной системой (1С, Мой склад и др.). И если в других системах CRM все эти данные учитываются в Сделке, то здесь они получаются «размазаны» по разным документам и разделам, что не очень удобно.
Корпоративная лента и другие надстройки
Возможность вести корпоративную ленту и переписываться в системе с коллегами, разработчики рекламируют как дополнительный плюс системы. Есть у этой возможности и свои преимущества, есть и недостатки. Такое общение может помочь в обсуждении каких‐то вопросов с коллегами, находящимися вдали от офиса, но также может отвлекать сотрудников от работы.
Кроме того, многие возможности этого сервиса вообще не являются функциями CRM‐системы, и будут только отвлекать менеджеров по продажам от основной работы, что также становится вместо плюса минусом.
Бизнес‐процессы
Все действия, все лиды, контрагенты, продажи и заказы в системе bpm’onlihabrahabr.rune sales являются частью того или иного бизнес‐процесса, точно так же, как это реализовано в системах BPMS, т.е. в специализированных программных системах управления бизнесом. Подробно об этом типе программного обеспечения я писал в статье Что такое BPMS. И, конечно же, попытки объединить CRM и BPMS‐системы также я не считаю хорошей идеей, как и применение других надстроек, которые только вносят путаницу и отвлекают от основной работы сотрудников отдела продаж.
Работа с BPM подразумевает три этапа:
В системе bpm’online sales все эти этапы должны воплощаться в отношении процесса продаж. На практике оказывается, что моделировать (рисовать) в системе очень неудобно. Реализация графического редактора находится на очень низком уровне. Система проектирования, наоборот, очень усложнена. При проектировании бизнес-процессов вас ждет сложный перегруженный интерфейс, и даже для небольших изменений приходится совершать слишком много действий (открытия окон, перехода из одного меню в другое, подтверждений и пр.).
В SAAS‐решении (а оно является для этой системы основным) работа редактора крайне медлительна, настолько, что пользователи возмущаются или даже подозревают сбои в системе.
Редактор и программирование бизнес‐процессов в версии CLOUD находится на очень низком уровне, пользоваться им я не рекомендую. Возможно, при покупке версии On site (настройка работы на сервере заказчика) эти функции будут работать быстрее.
Интерфейс
Интерфейс системы я лично считаю не самым удобным, хотя, объективности ради, нужно признать, что именно такой вариант интерфейса считается современным и модным. Похожий интерфейс имеется и в других CRM‐системах, и основан он на том, что основное меню располагается не сверху, как многие уже привыкли, а слева от рабочего пространства.
При этом внешний вид рабочей области имеет гибкие и простые настройки, можно выбрать количество колонок, цветовую гамму и другие параметры. Здесь все действительно удобно.
Отчетность
Отчетность в системе имеется, и даже относительно развитая, но при этом отдельным разделом отчеты не выведены. Они присутствуют в каждом из разделов и доступны по нажатию на иконку с диаграммой. При этом для того, чтобы посмотреть отчеты по работе с лидами, нужно будет зайти в раздел Лиды, а для аналитики по работе с Контрагентами придется зайти в раздел Контрагенты.
Сводная отчетность собрана в разделе Итоги. Они выглядят красочно, но особо информативными эти отчеты назвать сложно. Встроенная система отчетов не самая удобная и не самая продуманная.
С другой стороны, в системе имеется простой и удобный конструктор отчетов, который позволяет создавать что‐то свое. Функционал этого конструктора также ограничен, но пользоваться им можно, и для получения большей части обычных рабочих отчетов отдела продаж его более чем достаточно. И все же, для настройки нужных отчетов может потребоваться помощь программиста, что не всегда удобно.
Интеграция и API
API в системе bpm’online sales присутствует, но организация обмена данными не самая простая в сравнении с аналогами. Вообще система получилась очень сложной, и API здесь не стало исключением. Готовые интеграции:
Цены и оплата
В системе bpm’online sales присутствуют две составляющие стоимости пользования система:
В числе дополнительных платных опций:
Остальные цены вы можете в любой момент времени посмотреть и оценить самостоятельно здесь. Лично я считаю, что при подробном рассмотрении стоимости дополнительных услуг, эта система проигрывает многим конкурентам по соотношению цена/качество.
Резюме
По итогам хотелось бы сделать акцент на основных плюсах и минусах системы bpm’online sales.
Из плюсов особенно выделяются:
Кроме того, к слабым сторонам системы bpm’online sales я бы отнес обилие лишних возможностей. Разработчики не только навязчиво навязывают определенный бизнес‐процесс для работы с лидами и клиентами, но также практически на каждом этапе работы предлагают какие‐то дополнительные функции, которые не столько помогают, сколько отвлекают от работы или вносят путаницу.
Скорей всего, уже в следующей статье я проведу анализ основных ошибок разработчиков при создании CRM‐системе, и ненужные возможности в этом анализе займут далеко не последнее место.
А о системе bpm’online sales я могу сказать так: если у вас имеется крупная компания, собственный программист и достаточно средств для сложной доработки CRM‐системы, то можно смело приобретать bpm’online sales. Обилие возможностей и вариант работы на собственных серверах компании при грамотном подходе окупят все вложения, и система bpm’online sales может стать оптимальным решением для вашего бизнеса. Если вы не считаете нужным постоянно работать с программистом, предпочитаете SAAS‐решения, а также, если ваша компания относится к малому или среднему бизнесу, я бы предложил вам обратить внимание на другие варианты.
