Как надо и как не стоит автоматизировать торговлю в аптеке

Мое мнение — это всего лишь мнение, накопленное в процессе многолетней работы в среде фармацевтических торговых предприятий, как розничных, так и оптовых. Но речь пойдет все-таки о розничной части.
Кому интересно — добро пожаловать.
Предупреждаю: ни одной картинки и много букв.

1С Управление Торговлей В ПРИНЦИПЕ не приспособлена для торговли в фармбизнесе! А заслуживающие внимания потуги любимой дочки 1С на поприще адаптации Розницы все так же не решают до конца главных проблем этой системы. А при этом условии это решение не имеет права стоить таких денег, за которые оно продается.

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

Оборудование и прочие мелочи

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

• Системники на рабочих местах — стандартные Win PC под управлением XP Prof
• Специфика работы с медпрепаратами, как это уже верно подмечено, подразумевает обширные списки и множество дополнительных параметров, поэтому чаще всего стандартных торговых мониторов на 13-дюймовых не хватает, практически везде стоит 17-дюймовые. Исключение — приемка товара, где достаточно жать две с половиной кнопки и видеть список накладных
• Принтер этикеток (один на точку) — Godex BZB2. Ниже объясню, зачем вообще этикетки
• Стандартный принтер документов, тут вариаций море, главное чтобы был совместим с ОС и исправно печатал документацию
• Сканер штрихкода (ШК) используем простейший Zebex или Cipher — навернутые смысла брать нет. И уж тем более всякий раз настаиваю, чтобы сканеры были с интерфейсом USB — чтобы избежать лишнего геморроя с COM-портами. Совсем его не избежать, ибо фискальная техника и дисплей покупателя, но хотя бы на сканере — можно.
• Дисплей покупателя стоит Firich-2029. Простенький, и его достаточно.
• Сеть везде проводная на стандартных свичах D-Link, не вижу смысла на этом заостряться.

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

Data-flow и ответственность подразделений

В условиях, когда удаленных торговых точек становится больше 3-5, контроль ценообразования, закупку и множество прочих операций уже имеет смысл централизовать в «офисе». В нашем случае в офисе собственно торговля не ведется, это центр ответственности за документооборот, ценообразование, распределение товара. И это оправдано, ибо торговая точка должна торговать, «бить выручку», а не документы оформлять. Люди, которые находятся на кассе и зарабатывают живые деньги, должны как можно меньше внимания уделять бэк-офису, и как можно больше — покупателю. Запомните это условие, оно еще будет упоминаться.
А пока оно означает, что упомянутая чуть выше нагрузка переносится на подразделение, предназначенное для этого. Туда же (пока не в моих случаях, к сожалению) переносится анализ остатков и, как следствие, централизованный заказ с учетом сезона и потребностей рынка (маски и распираторы все помнят?) И в этом же подразделении идет весь бумажный документооборот, насколько это возможно (товарные накладные таки обязаны приходить с товаром на торговую точку. Но и их мы потом переправляем в «офис»).

Итак, товарная накладная пришла в офис (задержка на 1-2 дня), проведено ценообразование по закупочным ценам и требованиям законодательства (еще 1 рабочий день), данные по розничным ценам отправляются на торговую точку (еще 1-2 дня). Итого в оффлайновом варианте работы имеем задержку в продажах на 3-5 дней с момента поступления товара.

А в нашем, реально существующем варианте автоматизации, мы имеем старт продажи примерно через 1-2 часа после того, как он приехал. И это стандарт отрасли на сегодняшний день. Достигается это вот как:
Самое главное: в фармбизнесе никто давно не работает с бумажными документами. Каждый уважающий себя поставщик имеет каналы доставки информации о содержимом документов до покупателя. Чаще всего это программа электронного заказа, включающая в себя возможность доставки так называемых Электронных Накладных (ЭН). Это не электронный документ в моем понимании: он не защищен от копирования, не шифруется, не представляет из себя юридически достоверный документ. Эта ЭН — сведения о содержании бумажного документа. Но ее обычно достаточно для проведения всех небумажных процедур с данными: усвоение информации в системы учета, обработка этих данных (читай процедура ценообразования и распределение по торговым точкам).

• Кстати, вот вам первый недостаток ЛЮБОЙ системы торговли в аптечной сети: загрузка ЭН в коммерческих и предоставляемых системах чаще всего настроена только для ограниченного набора поставщиков. Для остальных — плати разработчику или разбирайся и настраивай сам, если вообще есть такая возможность. Предвидя вопрос, сразу обрублю: стандарта ЭН нет. Есть попытки таковой создать, но они натыкаются на множество особенностей оборота препаратов и НЕ-препаратов, торгуемых в аптеках.
• А вот и второй недостаток, опять же, ЛЮБОЙ системы торговли в аптечной сети. Недостаток основной и непреодолимый без изысков или финансовых вливаний. Это — отсутствие общедоступного и всеохватывающего ассортимент аптек КЛАССИФИКАТОРА препаратов и НЕ-препаратов. Казалось бы, чего проще — берешь Видаль или Регистр Лекарственных Средств, заставляешь всех поставщиков (еще не охватила паника?) привести представление своего ассертимента к этому списку – и вуаля. Осталось только понять, кто этим будет заниматься, как его пополнять и обновлять (РЛС выпускается раз в квартал — и катастрофически не успевает за выпуском новых препаратов, а уж о наличии НЕ-препаратов в нем я и вовсе молчу). Отсюда берутся основные затраты времени оператора или менеджера, который работает на приемке товара: он должен сопоставить наименования поставщика с наименованиями в базе. Заваптеками, с которых не сняли эту нагрузку, не дадут соврать — на это уходит от 2 до 6 часов в день в зависимости от оборота аптеки. Задача облегчается, конечно, хранением таких «привязок» в базе, но ведь все время появляются новые поставщики, новые препараты и, что самое грустное, НЕ-препараты. В своей практике даже видел систему, которая не поддерживала никаких хранимых привязок кроме прямого совпадения наименований. И при всем при этом мы помним, что сотрудники торговой точки должны «бить выручку», а не задачей сопоставления классификаторов заниматься.

Дальше по data-flow — передача данных по каналам общедоступной сети. У нас данные передаются незашифрованными пакетами через выделенный под это FTP-сервер. Не нужна никакая «внутренняя сеть», VPN и прочие извраты. Кого заботит шифрование и безопасность пакетов, — можно шифровать, наша система, например, позволяет добавить обработку отправляемых и принятых файловых пакетов любым необходимым способом.
Почему не VPN? Нет смысла. Зашифровать данные можно до передачи и после передачи расшифровать, а стабильность VPN в наших сетях под очень большим вопросом. Конкретно сейчас наблюдаю многочисленные проблемы в области обмена данными между офисом и торговыми точками в одной дружественной аптечной сети, оттого что используется VPN.

Кстати, сразу из описанной схемы работы вытекает такой нюанс: для скорости продаж, характерной для аптек, практически неприемлемо использовать торговлю по штрих-коду (ШК) завода-изготовителя. Мало того, что некоторые товары в принципе их не имеют (когда вы видели в последний раз ночной горшок российского производства с заводским ШК? А бутылочку или детскую соску? А это все ассортимент стандартной аптеки, и это далеко не все позиции, не имеющие заводского ШК). Мало того, что далеко не по каждому ШК можно найти описание товара в базе Юнискан. Мало того, что эта информация не всегда достоверна (и сметану вместо панадола получали, и много чего еще). Ну и в нагрузку: какой ШК считать штрих-кодом товара, если их на упаковке три? И все в разных форматах. И еще в нагрузку: где (как и в ситуации с классификатором товаров) взять таблицу соответствия ШК-наименование. А из этого наименования еще получить указание на товарную позицию в нашей номенклатурной базе.

В дни дикой молодости на внедрение системы автоматизации в аптеке по заводскому ШК вместо 1 дня я угробил 7 (СЕМЬ) дней! В цифрах выручки той аптеки это сложилось примерно в 350тыс.р. И это еще никто не считал оплату работы сотрудников, которых на процесс задействовали весь доступный состав — порядка 8 человек ежедневно.
Тогда сработала проблема отсутствия привязок заводских ШК к товарным позициям (РЛС содержит далеко не всю информацию, да и парафармации в нем нет, не говоря уже о косметике). А потом еще с задержкой сработала проблема отсутствия привязок номенклатурных классификаторов поставщиков к нашему. Это уже когда пошел потоковый приход товара в обычном режиме. Ибо без существующих привязок менеджер на приемке вынужден их делать самостоятельно. А это процедура не из приятных — копаться в деталях дозировок, количества в упаковке, производителей.

Как это решается?

Ну с заводскими ШК решается очень просто: в связи с таким количеством проблем, поставляемых заводскими ШК, их не следует использовать. Вообще. Использовать только собственные «технические» ШК. Практически любая современная коммерческая система розничной фармторговли включает подсистему вывода этикеток со служебными ШК. Помните, у нас на каждой торговой точке есть принтер этикеток – вот для этого он и нужен. Этикеток в день печатается не меньше 300, так что варианты для разовой печати не подходят. Поэтому используется минимальное для малого и среднего бизнеса решение – BZB2. Не стану утверждать, что это оптимальное решение: есть у него и недостатки, и достоинства. Но в заботливых руках наших операторов на приемке в аптеках эти принтеры не капризничают и ведут себя достойно.
А раз решена проблема идентификации на местах товара текущих приходов, остается только вопрос первоначального внедрения системы автоматизации (это когда надо провести полную инвентаризацию товара и «обштриховать» весь текущий ассортимент аптеки, это — отдельная история и отдельная статья) и вопрос привязки товара, свежепоступающего от поставщика, в офисе.
И вот вопрос привязки классификатора поставщика к нашему — это, как я уже писал, головная боль любой системы автоматизации розничной фармторговли. Вариантов несколько:

• Использовать приоритетного поставщика и его классификатор. Проблему полностью не решает, но хотя бы делает ее не глобальной и преодолимой. Чаще всего такой вариант предлагается в качестве бесплатного бонуса при использовании систем автоматизации розничной торговли, разработанных крупными игроками фармбизнеса — они тут же предлагают свой классификатор и прочие мелочи, иногда даже бесплатно дают программу. В обмен на минимально гарантируемый оборот и статус приоритетного поставщика. Такой подход считаю неоптимальным, ибо, помимо сомнительности экономической выгоды, от них не дождешься макетов импорта ЭН других поставщиков, а возможность самому эти макеты настроить, как правило, сильно ограничена или вовсе отсутствует. Да и редко такие системы автоматизации, разработанные в отделе ИТ такой компании как побочный продукт, бывают по-настоящему удобными и на 100% удовлетворяющими всем требованиям по скорости обработки данных, надежности обмена данными, полноте отчетной подсистемы и масштабируемости. А уж доработки по запросу или система багфиксов — что тут говорить, если даже некоторые коммерческие системы грешат их отсутствием.
• Использовать РЛС или Видаль и наработать совокупность привязок классификаторов разными ухищрениями (использовать набор заводских ШК, которые есть и в РЛС, и у поставщика; затем использовать усилия отдела снабжения «офиса» — пусть потеют привязывают. Есть еще варианты, но это, опять же, тема целой отдельной статьи). Путь затратный, но надежный. Лишен опасности «подсесть» на программу, поставки по объему и прочие услуги приоритетного поставщика.
• Путь, который предлагают правильные разработчики специализированного ПО для аптечных сетей: свой классификатор, вылизанный годами работы доверенных рабочих аптек, с привязками по основным поставщикам. Одна вот только проблема: такой классификатор обычно не «привязан» теперь уже к классификаторам других систем автоматизации, используемых на в компании. Например, системы учета 1С в бухгалтерии. Или если, не дай Бог, в компании используется несколько систем автоматизации торговли. Но и при всем этом мне такой путь кажется наиболее оптимальным.

ПО для автоматизации

И вот теперь, когда вы, терпеливые и упорные читатели, уже имеете представление об основной специфике фарм-торговли мы можем обсуждать самое интересное: ПО для автоматизации торговли.
Сразу обозначу свою позицию: мне нравится система, которую я буду называть только в приватной обстановке, дабы не обвинили в рекламе. И которую сейчас считаю на российском рынке оптимальной по соотношению цены и качества. Более того, я считаю ее весьма недорогой при условии, что функциональность, доступная за эти деньги, весьма широка и удовлетворяет всем потребностям практически любой сети — от одной до 20, 200 аптек. Принципиальных проблем с бОльшим количеством торговых точек не вижу, система очень хорошо масштабируется.

Исторически сложилось так, что сейчас эта система почти не используется, и я имею опыт в использовании нескольких других, в связи с чем имею возможность оценить принципиальные недостатки, которые есть практически в ЛЮБОЙ из них.
Итак, по мотивам всего, что написано выше, чего чаще всего в нынешних системах не хватает:

• Надежности обмена данными между офисом и торговыми точками. Тут уж как повезет: либо пакеты уникальны и не могут формироваться заново, что недопустимо при вероятных потерях, либо пакеты не хэшируются, что приводит к дублированию информации в базе-приемнике. В общем, разных косяков на обмене видел великое множество. А система должна позволять как много раз отправлять одно и то же, так и однозначно идентифицировать пакеты как дублирующие если чо.
• Гибкости в выборе способа обмена данными между подразделениями. Ну не идиотизм ли, — ограничить возможность пересылки пакетов выкладкой файлов в папочку по VPN? И потом еще жаловаться, что «у вас Интернет плохой, поэтому связь все время рвется». Или ограничить электронной почтой.
• Как это ни грустно, но юзабилити и минимализма в пользовательском интерфейсе. Фармацевт — девушка лет 20, которую научили долбить по кассе. Или в лучшем случае она работала в какой-нибудь другой системе продажи. Любое новое расположение окушек и кнопочек на экране — катастрофа. И уж тем более новая последовательность действий при продаже. Когда «чикнуть» дисконтную карту, когда — ШК скидки по пенсионному, на что и когда нажать, чтобы уже наконец чек выбить. А если используется дисконтная карта — уже не нажимать. Или нажать? Так вот, большинство систем автоматизации, которые я видел, грешат тем, что интерфейс кассира неюзабельный совершенно.
• Отсутствия откровенных заскоков в сознании разработчиков. Использование COM-сканеров ШК — это что-то. Почему-то все 1Сные решения предпочитают именно этот вариант (или сканеры в разрыве клавиатуры), ставят какие-то специальные драйвера. Или и вовсе ставят себе в достоинство то, что драйверы этих устройств идут в комплекте поставки системы учета. Когда давно уже существуют USB-сканеры, работающие как HID-совместимое устройство ввода и элементарно заменяющее ввод ШК с клавиатуры.
• И снова юзабилити. Основная доля времени менеджера снабжения уходит на привязку классификаторов товаров поставщиков к нашему классификатору. Так сделайте его лучше, быстрее, интуитивнее! Не видел ни одной системы, которая бы достаточно адекватно работала с этой задачей. Максимум, на что хватает разработчиков – это фильтр локального классификатора по первым нескольким буквам наименования. Я считаю, что это неоптимально и можно потратить время на разработку системы поиска соответствия по более гибким алгоритмам.
• Грамотной клиент-серверной работы. Камень в огород одного очень крупного поставщика. Товарищи, время, когда данные хранились в локальной памяти в программе в текущий момент, — давно минули! Клиентская станция должна быть если и не тонким клиентом, то уж точно не центром обработки данных!
• Поддержки свободно-распространяемых ОС. Вот тут вообще глютеус максимус. Только одна из известных мне компаний разрабатывает (и кажется мне, только под давлением моих пытливых расспросов двухлетней давности) интерфейс под Linux. Понятное дело, главное — не интерфейс (win-версия клиентской части прекрасно пашет под Suse+Wine), а сопряжение с оборудованием. Но ведь на то вы и разработчики софта!
• Грамотного сопряжения с другими системами учета. Наверное, только решение от Раруса не страдает отсутствием такового, ибо оно само по себе — уже монстр со включенной бухгалтерской подсистемой. А вот остальным стОит хотя бы быть более открытыми для импорта данных. А то одна за другой системы проходят через мои руки, — и каждый раз одна и та же проблема: зачастую даже сами разработчики достаточно уверенно не знают, в каких местах базы хранятся какие данные и как их выковырять для бухгалтерского учета. А предоставляемые возможности экспорта данных «для бухгалтерии», как правило, представляют из себя довольно жалкое зрелище. Даже в моей любимой @@@.
• Устойчивой работы в неустойчивых условиях. Это грустно, когда используется СУБД, не допускающая настройки (а лучше бы подразумевающая ее по умолчанию) режима работы, рассчитанного на быстрый запуск без потери данных при перебоях в питании, в работе локальной сети, в работе RAID-массива под файлами базы. Это очень увеличивает нестабильность работы торговых точек и затраты компании на специалистов по восстановлению данных, на поддержку (если например нужно исправлять косяки, возникающие в учетных данных при таких сбоях).

Это все к тому, что автоматизировать торговую сеть из нескольких торговых точек не стОит впопыхах и абы на чем. Смотрите на цены, на условия обслуживания. Не ведитесь на имя и красивый интерфейс — кассиру не красота нужна, а скорость и удобство. Да будь он хоть текстовым (а есть на рынке и такие), — главное чтобы сбоев не давал. Кассир деньги зарабатывает, он не должен рыться в настройках и бороться с интерфейсом.


Источник: Habrahabr.ru