Советы по увеличению прибыльности аптечного бизнеса от Павла Лисовского

Шпаргалка № 1. Последовательность действий имеет решающее значение 

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

И представим обратную ситуацию, когда любой документ подписывает сначала генеральный директор, а затем его согласовывают в остальных отделах. А какой-нибудь рядовой сотрудник может наложить свое veto на документ. Это ненормальная ситуация (хотя, конечно, и такое бывает). 

То же самое и при организации любых процессов в аптечной сети: правильная последовательность имеет важное значение. 

Для примера рассмотрим процесс аптечного ценообразования.

Вот правильный порядок действий:

1. Применение наценки (матрицы ценообразования или других способов расчета базовой цены). 

2. Обработка малых ценовых волн. 

3. Обработка больших ценовых волн.

4. Подстройка под конкурента/парсинг.

5. Изменение цены от скорости продаж. 

Почему так?

1. Происходит стандартный расчет базовой цены без учета внутренних и внешних факторов. Базовый расчет — это то значение, которое получается, если нет никакой дополнительной информации.

2. Малые волны — внешняя информация малой коммерческой значимости.

3. Большие волны — внешняя информация большей коммерческой значимости.

4. Парсинг — внешняя информация наибольшей коммерческой значимости для части ассортимента.

5. Скорость продаж — внутренняя коммерческая информация, которая важнее и точнее внешней. 

Если измените порядок действий в процессе, то вся его архитектура и коммерческая логика будет разрушена. Например:

• Если в сети сначала обрабатывают большие волны, то потом точно не смогут учесть малые.

• Если сначала идет подстройка под конкурента, а потом учет ценовых волн, то точный «подгон» цен исправят волны, в этом случае информация о ценах конкурентов становится бессмысленной. 

• Если скорость продаж ставить в начало, а потом подстраиваться под конкурента, то легко впасть в классическую ошибку — «у конкурента дешевле, делаем ниже». Подстраиваться под конкурента имеет смысл там и только там, где скорость продаж неудовлетворительная, а если скорость продаж выше среднего, то зачем снижать доходность?

Шпаргалка № 2. Аптечное программное обеспечение и облачные решения: можно ли совместить? 

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

«Чужое» облако даже для небольшой сети — недопустимая беспечность и критический уровень зависимости от сторонней организации.

Говоря про зависимость, я имею в виду несколько связанных аспектов:

1. Безопасность (конфиденциальность) данных: 

a. Компания-оператор может передавать данные как в «обезличенном», так и в открытом виде. Если кто-то имеет доступ к вашим данным, то с вероятностью 99% можно говорить о том, что он их транслирует заинтересованным компаниям. 

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

2. Сохранность данных. Компания-оператор произвела какие-то обновления/изменения, и все ваши наработки за полгода сгорели в один день (неоднократно сталкивался с такими проблемами в своей практике).

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

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

Шпаргалка № 3. Связь процессов должна быть прозрачна, понятна, автоматизирована 

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

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

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

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

Например, пересмотр ширины товарной категории, должен обязательно сопровождаться:

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

• сменой цены на «новые» и/или «старые» товары автоматически;

• возможно, изменением скидки на новые/старые товары, тоже автоматически;

• изменением уровня выплат;

• сменой выкладки и т.д.

Все эти действия могут проходить автоматически, это несложно реализовать в любом аптечном ПО (кроме ПО, которое не принадлежит сети и поэтому не предполагает каких-либо вмешательств)*. 

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

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

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

*Как это можно реализовать, рассказано в главе 9 книги «Аптека в плюсе».