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

          А.С. Логинов, зам. генерального директора торгового комплекса «Твой Дом».

Что такое «Твой Дом»? Представьте себе «магазинчик» общей площадью около 20 тыс. м2, находящийся на пересечении МКАД и Каширского шоссе, в котором работают примерно 400 человек. Номенклатура его товаров — более 100 тыс. наименований. Вполне понятно, что со всем этим без серьезной информационной системы и, следовательно, без компьютеров не справиться. Причем этот торговый комплекс работает ритмично, не закрываясь ни на выходные, ни на праздники. Ежедневно от 5 до 8 тыс. покупателей провозят через его кассы тележки, набитые товаром. Аппараты трещат без остановки, товар идет непрерывным потоком, печатаются и сканируются штрих-коды, проводятся инвентаризации, фиксируется перемещение товара между подразделениями. И за всем этим следит «нервная система» «Твоего Дома» — программный комплекс IBS Trade—«Домино»—«Дельфин».

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

Многие из рассмотренных программ создавались на основе «легких» СУБД, которые заведомо не справились бы с предполагаемым объемом данных.

Специалисты в один голос рекомендовали заказать разработку индивидуальной программы. Однако торговый комплекс «Твой Дом» создавался рекордными темпами, и на это просто не хватало времени. Было принято решение взять лучшее из того, что есть.

Предпочтение отдали программам, проверенным на практике. В итоге выбрали двух монстров в области программного обеспечения крупных торговых предприятий — IBS и Soft-West (стратегический партнер известной фирмы «Пилот»). Было решено соединить вместе те части этих систем, которые, по мнению специалистов АСУ, оказались наиболее удачно проработанными для торгового комплекса. От фирмы Soft-West был взят Back Оffice «Домино», от фирмы IBS — Front Office IBS Trade. Несмотря на некоторый скептицизм, разработчикам удалось организовать сотрудничество специалистов обеих фирм и в короткие сроки создать соединительный модуль. Он позволил наладить надежный обмен данными между кассами, управляемыми IBS Trade и Back Office «Домино». Результат оказался превосходным: была построена система, в которой одновременно могут работать до 60 пользователей с самым разнообразным уровнем подготовки и которая за полтора года работы не дала ни одного серьезного сбоя!

Этапы построения системы

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

Второй этап включал создание сети, охватывающей уже все технологические подразделения магазина. Она состоит из главного сервера компании Dell (процессор Pentium II-233, 128-Мбайт ОЗУ, шесть дисков с RAID-массивом), работающего под управлением ОС Novell NetWare, и вспомогательного сервера фирмы Kraftway; 50 компьютеров фирмы KN-Computers, 15 POS-терминалов производства IBM (поставлены IBS), 9 обычных принтеров, 4 принтеров для печати штрих-кодов и этикеток, а также сетевого оборудования. На этом этапе продолжилось формирование базы данных по товарам, а также были автоматизированы рабочие места кассиров, специалистов сервис-центра, операторов по расчетам с поставщиками и покупателями, работников группы, назначающей цены, и т. д. Фирма Soft-West разработала проект сети и руководила ее монтажом.

Организация корпоративной системы управления

торгового комплекса «Твой Дом»
Третий этап — автоматизация аналитических и экономических служб. Здесь сотрудники отдела столкнулись с проблемами, неизбежно возникающими на любом крупном и среднем розничном торговом предприятии. Перед компьютерной системой управления торговым предприятием стоят две большие задачи: обслуживание технологических операций (приемка, перемещение товара, назначение цен, обработка продаж и т. д.) и анализ данных. Первую — комплекс «Домино» — IBS Trade решает вполне успешно и надежно, а вот аналитическая обработка данных вызвала определенные затруднения, обусловленные объективными причинами. Во-первых, в «Твоем Доме», который имеет торговую площадь и количество наименований продаваемых товаров почти в 10 раз большие, чем обычный универсам, производятся огромные объемы операций. Во-вторых, некоторые стандартные и кажущиеся очевидными принципиальные решения, заложенные в идеологию большинства продаваемых на рынке программ, в том числе и в «Домино», при обработке поточных торговых операций организуют данные так, что при их анализе появляются ошибки.

Например, представим себе такую вполне реальную ситуацию. В торговый комплекс поставляется 1500 наименований различных товаров по нескольку сотен единиц каждого. Производится приемка, все выверяется, составляется приемочный акт, готовится комплект первичных (бумажных) документов с подписями и печатями в точном соответствии с количеством поступивших товаров, данные о которых заносятся в компьютер. Сами товары доставляются в торговый зал, и начинается продажа. Торговля идет без осложнений, но через неделю сотрудники замечают, что входившие в эту поставку отвертки еще не все проданы. В то же время компьютер показывает, что их остаток равен нулю. Выясняется следующее: оператор при вводе накладной в компьютер забыл напечатать один ноль. Получилось, будто пришло 100 отверток, хотя на самом деле их 1000. Как исправить положение? Конечно, можно наказать оператора, однако при столь широкой номенклатуре поставки вероятность ошибки была весьма велика, да и делу это не поможет.

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

К этому времени уже было продано 120 отверток. Для 100 из них система сразу определила, из какой они поставки, какова стоимость закупки и т. д. А вот 20 следующих с точки зрения системы появились «ниоткуда». Она восприняла их как излишки и назначила закупочную цену, равную нулю. Программа записала эти данные, они сохранились в БД. А чтобы внести изменения в компьютерный документ, его нужно изъять из действующей БД. Это понятно — одновременно и корректировать, и использовать данные в системе невозможно. Изменения в накладную внес оператор, потратив на это 40 мин, поскольку операция была нестандартная, пришлось разбираться и получать разрешение руководства. Кроме того, 5 мин ушло на телефонный разговор (оператор тоже человек) и 15 мин — перерыв (график работы соблюдается строго: опоздаешь — останешься без обеда). Следовательно, в течение всего этого времени накладная с точки зрения системы не существовала. К тому же, как назло, этот день оказался пятницей, когда дачники по дороге за город один за другим сворачивали с МКАД к «Твоему Дому», чтобы купить нужные в хозяйстве вещи. Отвертки тоже относятся к этой категории товаров, и за 40 мин было продано еще 15 штук, а данные с касс были переданы на главный сервер как раз перед тем, как оператор вновь акцептовал накладную. Таким образом, «Домино» зафиксировал продажу еще 15 отверток из «излишков».

Через месяц раскупят всю 1000 отверток, но по накладной будет списано только 965, ведь 20 продаж до исправления и 15 во время его система зафиксировала как реализацию «излишков». Из-за этого отвертки окажутся непроданными до конца навечно, а также исказятся аналитическая отчетность, расчеты долга поставщику и т. д.

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

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

Эти проблемы выявились с первых же дней работы комплекса, поэтому специалистами АСУ были разработаны специальные отчеты и определены организационные меры для устранения возникающих расхождений. Если бы магазин был поменьше, то, возможно, с подобными неувязками можно было бы смириться, поскольку в целом ошибок было бы относительно мало. Но для такого гиганта, как «Твой Дом», «ручная» работа программистов совершенно неприемлема.

Чтобы выйти из столь сложного положения, специалисты АСУ обратились к системе «Дельфин» компании «Светон», сотрудники которой, и в том числе разработчики, имеют опыт работы именно в торговом бизнесе. И они заложили в идеологию «Дельфина» именно те решения, которые требовались для развития системы автоматизированного управления «Твоим Домом».

Программы, разрабатывающие ПО для торговых предприятий, как правило, не разделяют между собой документы и события. С их точки зрения приход товара и приходная накладная, а также серия связанных с ними вторичных документов (бухгалтерские проводки и т. п.) являются неразделимыми. Увязки событий фиксируются один раз исходя из тех данных, которые находились в БД именно в тот момент, когда они произошли. Но с БД работают многие пользователи, и ввод данных часто не совпадает по времени с совершением события. Поэтому на момент фиксирования увязки может оказаться, что в БД не было всего, что следовало учесть. Такие системы требуют жестких правил, касающихся порядка и очередности внесения данных в компьютер. Когда же в сети работает много пользователей, а часть данных вводится автоматически (сканирование штрих-кодов в кассах), никакие организационные меры не обеспечивают их полного соблюдения. А иногда такая искусственная «заорганизованность» даже противоречит требованиям бизнеса.

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

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

«Дельфин» фиксирует события в такой последовательности, в какой они происходят в жизни, не создавая искусственных «твердокаменных» связей. Все вторичные данные и взаимные увязки создаются «на лету», в момент обращения пользователя к системе с запросом. В результате рассчитанные вторичные данные всегда соответствуют реальной картине исходных, имеющихся в системе в тот момент, когда составляется отчет. Не возникает никаких несуществующих излишков, «дырок» в увязке поставок и продаж. Отпадает необходимость в кропотливых проверках корректности базы, а актуальность данных всегда составляет 100%.

«Дельфин» хорош для аналитической работы с данными еще и потому, что создан на базе MS SQL Server и имеет удобный графический интерфейс, разработанный средствами Delphi. Широко распространенный язык SQL упрощает подбор программистов для отдела автоматизации магазина, а также позволяет обращаться к «Дельфину» из таких «вездесущих» офисных приложений, как Access и Excel и им подобных, в которых затем можно быстро и легко выполнять обработку данных. Причем это по силам любому специалисту, знакомому с Microsoft Office.

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

Простота доступа к информации обеспечила важный качественный переход — у управляющих предприятием появилась реальная возможность напрямую работать с данными. Раньше типичной была следующая ситуация. Когда руководителю требовалась информация, которой не было в регулярных отчетах, ему приходилось звонить в отдел АСУ и объяснять, что он хочет узнать. Программисты готовили отчет исходя из того, как они сами понимали вопрос. А надо сказать, что терминология и менталитет у коммерсантов и программистов существенно различаются. (Знаете шутку: компьютер выдает не ту информацию, которую вы хотели получить, а ту, которую у него запросили.) В результате управляющий через достаточно продолжительный промежуток времени зачастую получал ответ совсем не на тот вопрос, который задавал.

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

Сейчас в торговом комплексе «Дельфин» в основном внедрен. Каждую ночь в него копируются данные, накопленные за день в «Домино» и IBS Trade. Когда система управления «Твоим Домом» дополнилась «Дельфином», сформировался «слоеный пирог» из трех программ, причем каждая из них занимается тем, что умеет лучше всего. Компьютеры теперь помогают управлять всем происходящим в комплексе — от рутинных операций, требующих высокой точности и надежности, до сложных экономических расчетов, где нужны гибкость и быстродействие системы.

«Твой Дом», как и живой организм, постоянно изменяется, перестраивается, развивается и приспосабливается к запросам покупателей. Появляются и новые требования к системе автоматизации. Фирмы-разработчики ПО, участвовавшие в создании такого «слоеного пирога», сопровождают и обслуживают его «слои», а также совершенствуют и развивают их. Компания IBS помогла создать в комплексе выделенные «внутренние магазины»: один — для торговли мелкими и дорогостоящими предметами, другой — для продажи продуктов. Фирма Soft-West сейчас совершенствует систему бухгалтерской и налоговой отчетности, «Светон» программирует новые аналитические отчеты по заказу комплекса. В планы «Твоего Дома» включены создание встроенного в систему Internet-магазина, автоматизация процесса закупок и получение от постоянных поставщиков товара с накладными на электронных носителях информации.

ОБ АВТОРЕ

Михаил Глинников — научный редактор журнала «Мир ПК», контактный тел.: (095) 253-92-27.


Выбор системы автоматизации торговли

— Когда разработана система? Под управлением какой ОС она работает? Какая система управления БД используется?

— Функциональные возможности СУБД, используемые в системе, должны соответствовать масштабам предприятия. Для организаций, имеющих тысячи наименований товаров и достаточно развитую компьютерную сеть, необходимо использовать современные, достаточно мощные и надежные системы, такие как MS SQL Server, Oracle и т. д. (в зависимости от финансовых возможностей покупателя ПО).

— Позволяет ли система изменять или дополнять ее штатные функции?

— Необходимо, чтобы персонал, администрирующий систему на предприятии, имел доступ к данным системы на низком уровне. Для этого требуется выполнение двух условий: поставщик ПО обязан предоставлять структуру БД своего продукта и способ доступа к данным должен осуществляться с помощью широко распространенного языка программирования. Дело в том, что в ходе эксплуатации неизбежно возникнет необходимость выполнять операции, не предусмотренные штатным функционалом системы. Некоторые программные продукты имеют собственный встроенный язык (например, написанные на базе менеджера записей Btrieve). Это облегчает работу, но тогда потребуются программисты, специально обученные программированию на этом языке, и что еще хуже — будет затруднена оптимизация запросов с точки зрения скорости и эффективности выполнения. Гораздо лучше, если доступ к БД осуществляется на одном из диалектов SQL, а клиентское приложение написано на широко распространенном универсальном языке программирования, например на Object Pascal. В этом случае будет достаточно просто найти квалифицированных программистов, которые смогут адаптировать систему к изменяющимся потребностям предприятия. Тогда организация, использующая программный продукт, не будет находиться в постоянной зависимости от поставщика ПО, а это означает, по меньшей мере, существенную экономию средств.

— Имеет ли клиентская часть программного продукта Windows-интерфейс?

— Не надо верить рассказам, что не привыкшим к компьютеру работникам легче работать с «простым» DOS-интерфейсом, ведь Windows-интерфейс — это вопрос не только удобства. С его помощью решаются две очень важные практические задачи. Во-первых, снижается количество ошибок при вводе данных и ускоряется работа операторов, а это уменьшает затраты. Во-вторых, графический интерфейс позволяет руководящему персоналу предприятия напрямую общаться с данными, не обращаясь к посредникам типа системных администраторов и программистов. Можно быть уверенным, что ни один генеральный директор не станет разбираться, когда ему надо нажимать +F1, а когда +Z. Но в то же время многие управляющие среднего и верхнего звена владеют Word и Excel, а значит, быстро и легко справятся с любым графическим интерфейсом.

— Что является уникальным идентификатором товара в системе?

— Однозначной рекомендации дать не могу, но надо опасаться вариантов, когда, например, товар в системе идентифицируется по артикулу (это случай из жизни). Тогда валенки арт. В-135 и зубная паста арт. В-135 окажутся в вашей системе одним и тем же товаром. Идентификация по восьмизначному или штрих-коду с трудом воспринимается человеком и порождает ошибки. Метод идентификации товара (и прочих элементов БД) необходимо тщательно изучить и сравнить с принятым на предприятии при неавтоматизированной работе.

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

— Такие ошибки будут возникать обязательно. Это самая сложная проблема, с которой мы столкнулись на практике. Вариантов ответа на этот вопрос может быть, как минимум, три. Первый — система не позволит вам это сделать. Тупиковая ситуация. Однако многие программы работают именно так. Второй — система даст вам возможность внести изменения, но не исправит связанные с ним данные. Это лучше, но в данном случае для сохранения согласованности и непротиворечивости сведений надо предпринимать организационные меры, чтобы при каждом их изменении в прошлом тщательно проверять и исправлять всю вторичную информацию. На практике это приводит к путанице и недостоверности отчетов. Лучше всего третий вариант — когда система построена так, что позволяет вносить изменения в прошлом, но предоставляет эффективные средства для сохранения согласованности первичных и вторичных данных. Такая идеология — большая редкость на нашем рынке. Мне удалось найти лишь одну программу, которая работает именно так и находится в реальных пределах стоимости, — это «Дельфин».

— Насколько точно система отображает реальные события, происходящие в бизнесе?

— Если в системе одни физические явления подменяются другими (например, объявляется, что приход товара эквивалентен составлению приходной накладной) — это тревожный сигнал. Рано или поздно вам может понадобиться отдельно отразить приход товара и, например, составление нескольких связанных с этим приходных и возвратных накладных, а вы не сможете этого сделать. Чем больше происходящее в системе похоже на реальную жизнь, тем лучше.

— Обеспечивают ли функциональные возможности системы технологическую цепочку?

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

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

— В каком режиме работают кассы?

— Очень заманчивой кажется работа в режиме on-line, когда в любой момент можно увидеть количество совершенных продаж и даже наслаждаться увеличивающейся выручкой магазина в реальном времени. Однако такой режим для магазина неприемлем, так как он предусматривает хранение всех данных о продажах на общем сервере. Сбой последнего моментально парализует работу магазина. И тогда придется делать объявления типа: «Господа покупатели, по техническим причинам просим вас оставить выбранные товары и покинуть магазин». Для репутации торговой точки это трагедия. Поэтому кассы должны в течение торгового дня работать в автономном режиме, передавая данные на сервер лишь по запросу. Однако связь с кассами должна осуществляться в обоих направлениях и в любой момент, необходимый для пополнения прайс-листа на кассах или сбора информации о продажах.

— Как система обрабатывает платежи и различные виды взаимоотношений, которые возникают с поставщиками и клиентами?

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

— Какими готовыми отчетами располагает система, есть ли в ней генератор отчетов? Может ли она экспортировать данные в форматах, удобных для импорта в другие приложения?

— Можно с полной уверенностью утверждать, что функциональных возможностей программы окажется недостаточно. Очень удобно, когда данные из системы можно перенести в общедоступные приложения, такие как Excel или Access. Это расширит возможности проведения самых разнообразных расчетов и анализов, а также графического представления данных.

— Где используется и как зарекомендовала себя программа?

— Как бы внимательно вы ни изучали систему, о ее «подводные камни» вы натолкнетесь только при эксплуатации. Нужно попросить предоставить список предприятий, где она уже внедрена, проконсультироваться там, чтобы выяснить ее сильные стороны и недостатки, а также узнать, с какими затруднениями сталкивались пользователи. Если есть возможность, полезно переговорить и с конкурентами поставщика.

— Как поставщик собирается адаптировать программу под потребности конкретного предприятия и каким образом он будет ее внедрять?

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

Материал подготовлен заместителем генерального директора торгового комплекса «Твой Дом» Андреем Сергеевичем Логиновым.