Журнал PC Magazine/RE №11/2009

Заметки эксперта В поисках идеальной ERP

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

Возраст самого термина – ERP, Enterprise Resource Planning – уже весьма почтенен. Однако его практическое применение, т. е. сами ERP-системы, на мой взгляд, и по сей день пребывают в состоянии едва ли не юношеском. До зрелости еще очень далеко, причем это относится не только к России. Да, на Западе много компаний, имеющих огромный опыт использования ERP (чего стоит одна только Toyota!), но все они, как правило, пользуются собственными разработками. Разработками, которые создавались десятилетиями и в которые вложены огромные деньги. Некоторые флагманы мировой промышленности даже значительно влияют на саму культуру планирования ресурсов как таковую, порой меняя привычные принципы планирования.

Первые достойные внимания попытки разработать и внедрить в России в промышленную эксплуатацию что-то подобное ERP-системе были предприняты еще в середине 90-х годов. В одном из таких проектов участвовал и автор этих строк. Это была компания из 1500 сотрудников, имевшая девять региональных филиалов (с содроганием вспоминаю, чего нам стоило все это объединить в единое информационное пространство, учитывая тогдашнее качество каналов связи). Конечно, назвать те попытки разработкой ERP-системы сегодня даже язык не поворачивается. Это скорее были прототипы, модели нынешних решений. Все мы тогда учились, причем в основном на своих собственных ошибках. О чужих-то мы не знали.

Много лет назад, еще в 90-е, разработчики рассматривали свои EPR-системы как вершину айсберга корпоративной автоматизации. Мол, не царское это дело – автоматизировать транзакционную часть. Пусть всякие низменные накладные, проводки и прочие мелочи проходят в других системах, а ERP должна только планировать. Попытки реализовать такой подход на практике приводили к тому, что заказчик получал некий «черный ящик». Количество проблем увеличивалось вдвое, расходы на поддержку зоопарка систем – в десятки раз. С нулевым результатом.

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

Любое изменение в транзакционной части (и, не приведи Господи, еще и задним числом, что мы в России очень любим делать) должно было сопровождаться соответствующими изменениями в ERP. Вот для обеспечения реакции на такие изменения и содержали «программистов-кочегаров», которые в случае чего засучивали рукава и в поте лица гоняли данные из системы в систему. И оказывались такие «кочегары» людьми едва ли не самыми важными в бизнесе, без которых ни одно производственное совещание не обходилось.

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

В конечном счете здравый смысл возобладал и пришло понимание, что ERP-система – единый организм. Отдача от ее эксплуатации может быть только в одном случае – когда все процессы замкнуты в рамках единой ИС масштаба предприятия, основанной на одном продукте. Лишь при этом условии можно обеспечить связь всех бизнес-процессов и целостность информации. Кроме того, устойчивость такой системы значительно выше. Ну скажите, какой смысл в цифре, агрегирующей, например, объемы продаж, если нельзя посмотреть, как эта цифра получилась. Чувство недоверия к показателям не покинет пользователя никогда, если система не обеспечивает возможности оперативной проверки любой цифры и не позволяет добраться из отчета до первичных данных. Получается, что отчетность смотрим в одной системе, первичные данные – в другой, и связь этих данных друг с другом поддерживается только до тех пор, пока не уйдет в отпуск «ответственное за интеграцию» лицо. А работать-то нужно всем.

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

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

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

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

Если говорить об идеальном решении, то система должна обладать встроенными инструментами для бизнес-анализа (BI, Business Intelligence). Современная отчетность – это не только привычные «прибыли и убытки», «движение денежных средств» и «баланс», но и другие инструменты для анализа и оптимизации бизнеса. Современная BI-система должна давать ответ на целый ряд важнейших вопросов, стоящих перед руководством компании. Вот лишь некоторые из них.

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

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

• BI-система должна позволять рассматривать показатели деятельности в различных разрезах с тем, чтобы проводить мероприятия по их оптимизации. Необходима возможность получить любой показатель в таких разрезах, как «клиент» («поставщик»), «товар», «сотрудник» («менеджер»), «отдел» (и «группа отделов»), «своя» организация, «проект». Это минимум. Плюс средства отслеживания динамики изменения показателей.

• Каков платежный баланс бизнеса? «Где деньги, Люся?» – иными словами. Руководство должно четко представлять финансовые потоки предприятия и понимать, насколько в компанию входит денег больше, чем из нее выходит. (Про «наоборот» говорить не хочется.) На такие вопросы однозначный ответ дает отчет о движении денежных средств (Cash&Flow). Но простой картины финансовых потоков недостаточно. Всегда хочется понять, какие подразделения принесли эти деньги, какие клиенты, по каким сделкам и т. д. И при этом необходимо иметь возможность все это делать непосредственно в отчете, только тогда видна ясная причинно-следственная связь. В то же время желание видеть платежный баланс в одном отчете автоматически накладывает на функциональность ERP-системы целый ряд требований по контролю движения денежных средств. Например, система должна позволять проводить огромное количество операций – от прихода денег по счету до банковских кредитов и налоговых компенсаций. В противном случае просто невозможно обеспечить в системе все финансовые операции и получить целостную картину. Так что система автоматизации должна позволять контролировать остатки в банке и кассе, т. е. плавно возникают требования по обеспечению финансовых транзакций.

• Каков баланс бизнеса? Руководству нужно однозначно знать дебиторскую и кредиторскую задолженность компании, причем отдельно по поставщикам и клиентам. Понимать, какие клиенты (поставщики) и в каких суммах ее сформировали, по каким сделкам, какие менеджеры в этом участвовали и т. д.

Для принятия правильных решений не помешало бы иметь не только финансовые показатели, но и количественные. Думается, что всем руководителям интересно знать, растет ли количество клиентов и новых проектов и как. Растет ли посещаемость сайта и как это стыкуется с объемом продаж. Как меняется количество сотрудников. Ну и масса других показателей.

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

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

Любая сделка – это довольно серьезный бизнес-процесс. Вот простой пример: «заказ клиента – коммерческое предложение – договор – счет клиенту – предоплата – заказ поставщику – счет поставщика – заявка на его оплату – платеж поставщику – накладная поставщика – приход товара – оформление доставки клиенту – отгрузка со склада – накладная, счет-фактура – закрытие сделки». И все эти процессы должны быть объединены в рамках какого-то проекта. (Заметьте, это еще без производства, а с ним все значительно усложняется.)

Идеальная ERP-система должна обеспечить автоматическое формирование бумажного отражения всех документов (если они требуются в процессе) без применения подручных средств. С последующим хранением копий этих документов (в отсканированном виде) в базе данных. Каждый документ сделки тоже может проходить определенный путь. Допустим, договор нужно оформить, подписать, получить подпись клиента. И всем должно быть ясно, на какой стадии договор находится в текущий момент, на какой стадии находится вся сделка в целом. Пользователь, заходя в систему, должен видеть, что в данный момент процесс находится, например, в стадии заказа поставщику. Посмотреть, как был оплачен счет, кто подписал договор с нашей стороны, когда и т. д. У какого поставщика заказан товар и когда ожидается его поступление. Масса вопросов по каждой сделке, отсутствие ответов на которые зачастую вызывает у руководства буквально истерику. Потому что каждый работает в каком-то своем «микрокосме», в своей частной системе (CRM, SCM, а то и просто Excel).

Современная ERP-система просто обязана обеспечивать прохождение всех бизнес-процессов, от получения заказа от клиента и до доставки груза. И не только обеспечивать, но делать эти процессы неразрывными и целостными. Это значит, что в любой момент должна быть возможность пройти по всему процессу от начала до конца. Да, это огромный функционал – но он не избыточен. Ведь именно так и обстоят дела в реальной жизни практически в каждой компании, где трудится хотя бы десяток человек.

В презентациях разнообразных консультантов, продающих ERP-системы, часто встречается термин Best Practice. В ERP-мире это, как правило, означает, что нам рассказывают: мол, на Западе уже давно все придумали, и изобретать велосипед вовсе не требуется, просто возьмите оттуда лучшее.

Идея сама по себе неплохая, но в России не всегда работает. Не потому что мы особенные, у нас просто экономика другая. Особенности налогообложения, специфика оформления сделок и многое другое. В отличие от зарубежных компаний в нашей стране чуть ли не на каждом предприятии имеется несколько «своих» юридических лиц одновременно. Встречались и случаи, когда их число доходило до полусотни! И все их необходимо обеспечивать правильной нумерацией документов (к чему у нас относятся строго).

Бывает и так, что 70% сделок проходят по весьма разветвленным схемам, связывающим интересы многих контрагентов. Возникают существенные – до 50%!– расходы на проведение сделки, а это чистейший убыток, значит, он должен закладываться в себестоимость сделки. Расскажите об этом западным компаниям – не поверят.

Простой пример. Представьте, что у вас есть клиент. У него – пять юридических лиц. Стандартная ситуация. Нужно вам знать, сколько вам задолжало каждое из этих пяти юридических лиц? Обычно нет, разве что при формировании бухгалтерского акта сверки. В большинстве случаев необходимы показатели по клиенту в целом. Это касается и дебиторской и кредиторской задолженности, и объемов продаж и дохода. Сплошные аффилированные структуры – чисто российская особенность. А для принятия решений нужно агрегировать все показатели.

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

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

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

2. Управление кадрами компании: невозможно.

3. Управление договорной деятельностью компании: невозможно.

4. Управление производством: невозможно.

5. Организация работы с клиентами: на уровне «1C:Предприятия» 7.x.

6. Управление ценообразованием: практически отсутствует. (Причем некоторые моменты просто препятствуют нормальной работе.)

7. Сквозной учет товара: разобраться не удалось. (Все закрыто и пользователю недоступно, остается только верить презентации.)

8. Формирование первичных документов: практически невозможно.

9. Управление логистикой: невозможно.

Более подробно эта история изложена на сайте http://www.avasystems.ru/press/prezent_erp.

Как можно пользоваться таким продуктом? Где эти пресловутые «наилучшие решения», Best Practice? Я не верю, что такая система может работать и на Западе, а в России приобретение подобного продукта однозначно приведет к потере времени и денег. И вот тут стоит отметить, что внедрять ERP-систему желательно с первого раза. Второй попытки внедрить что-то подобное компания может и не перенести, если сотрудники потеряют веру в непогрешимость и эффективность топ-менеджеров, восприняв очередной проект внедрения очередной ERP как очередную забаву руководства.

Разработчики давно поняли, что клиентам нужны именно ERP-системы. И поступают очень просто: называют ERP-системами свои продукты. Хотя в действительности больше половины продуктов на рынке не способны не только планировать, но даже учитывать. Сегодня любой программный продукт, умеющий печатать счета-фактуры, называют ERP-системой. Просто потому, что «клиенты хотят ERP».

Как результат – термин девальвировался, и теперь уже непонятно, что есть ERP, а что не ERP. Поэтому самое надежное при выборе решения – отбросить терминологию и оперировать потребительскими характеристиками продукта: «Система должна уметь это, это и вот это. Покажите, пожалуйста. Желательно на конкретных примерах».

В противном случае могут быть сюрпризы. Однажды мне довелось присутствовать на презентации некой ERP-системы, частью которой был модуль MRP (Material Requirement Planning, планирование потребности в материалах). Это, пожалуй, самая сложная часть в планировании, и наличие такого модуля – серьезное преимущество. Но … На практике все свелось к тому, что система автоматически формировала заказ, если остаток того или иного ресурса оказывается ниже «страхового запаса». Ни сроки поставок, ни тренды продаж, ни сезонность, ни текущие поставки не учитывались. И вот это доблестные продавцы системы (западные, замечу) назвали MRP. Мало того, страховой запас нужно было указывать для каждой товарной позиции отдельно. Легко представить, как это будет работать при наличии тысяч эдак тридцати учетных позиций.

Современное планирование запасов просто обязано учитывать плановые сроки поставок по поставщикам и желательно по этапам поставки, чтобы при планировании учитывать, что если груз только заказан, значит, он будет через N дней, а если есть товарная накладная – значит, через X дней. Инициировать пополнение склада материалов нужно не в момент, когда запас уже вошел в «красную зону», опустившись ниже границы страховой части, а так, чтобы он оставался стабильным. Страховые запасы и плановые сроки поставок желательно планировать по группам однотипных товаров. Если поставщик доставляет любые ноутбуки за 60 дней – зачем указывать этот срок для каждой модели отдельно, достаточно задать его для товарной группы. Иными словами, система планирования должна быть применима практически, в противном случае потеря времени и сил гарантирована. Не говоря уже про деньги.

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

Нередко со стороны консультантов в сторону заказчика звучат фразы: «Вы скажите, как вам надо, и мы сделаем». Да консультантов для того и приглашают, чтобы они подсказали, как делать нельзя, и что-то подправили в бизнесе. Но если консультант сам только что из института, откуда ему знать, как все сделать правильно?

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

Типовое решение Мобильная торговля: склад в кармане

Решения класса АСМТ (автоматизированная система мобильной торговли) – один из наиболее популярных способов оптимизации деятельности торговых компаний.

Как и всегда, в рубрике «Типовое решение» мы подготовили модельное ТЗ, попросив разработчиков сделать небольшой анализ, описывающий способ решения модельной задачи средствами их систем. В России сегодня довольно много компаний, создающих АСМТ; на наше предложение откликнулись фирмы «Гильдия разработчиков» (система «НАПОЛЕОН»), «Паритет» («Моби-С») и «Нео Матрикс» (с одноименным продуктом).

Участник уточнил базовую задачу так: модельная компания, занимающаяся оптово-розничными поставками товаров косметики, гигиены, бытовой химии, имеет четыре отдела, специализирующихся на дистрибуции нескольких коллекций национальных и импортных марок, а также два отдела, занятых реализацией бытовой химии. Общая товарная номенклатура насчитывает 50 тыс. наименований.

В компании имеется 50 мобильных сотрудников (торговых агентов) и шесть руководителей (супервайзеров), работу которых предстоит автоматизировать. Сорок агентов (торговых представителей из разных отделов) работают по схеме Pre-selling (сбор предварительных заказов «в полях») с возможностью сбора мерчендайзинговой информации. Каждый агент работает со «своим» перечнем товаров (максимум 20 тыс. наименований). Десять торговых представителей из отделов, занимающихся дистрибуцией, работают по схеме Van-selling (реализация товаров с мобильных складов, торговля «с колес») с возможностью оформления предварительного заказа. Их БД отражает реальное наличие товара на борту автомобиля и не превышает 300 наименований. В случае необходимости они могут принять предварительный заказ на маршруте.

Организация решения. При торговле используется следующая схема ценообразования: агент работает с базовыми «клиентскими» ценами, по необходимости предоставляя скидку в указанных пределах. Супервайзеры контролируют работу агентов (количество посещений, объем реализации, сбор информации), а также оформляют отчеты для руководителей территориальных подразделений (заполняя в Microsoft Excel типовую форму, утвержденную центральным офисом).

Для решения базового набора задач потребуется два программных продукта: «НАПОЛЕОН. Создание заказов (Pre-selling, мерчендайзинг)» и «НАПОЛЕОН. Выездная торговля (Van-selling)». Для реализации функций контроля работы торговых представителей и автоматизации процесса предоставления отчетности можно использовать модуль Microsoft Excel, данные предоставляет серверная часть комплекса «НАПОЛЕОН».

Чем обосновано такое решение? Во-первых, при переходе на другую КИС потребуется замена только модуля обмена данными (в «1С» готовые типовые модули обмена имеются в наличии). Простая схема обмена позволяет быстро разработать соответствующий модуль силами сотрудников ИТ-отдела компании (если потребуется). Во-вторых, ускоряется и удешевляется процесс внедрения. В-третьих, упрощается унификация в соответствии с принятыми компанией стандартами в области ПО.

Порядок реализации проекта. На первом этапе базовая версия системы (в которой возможно выполнение поставленных задач) инсталлируется на три КПК, проводится обучение пользователей и оператора, а также пилотный запуск (3–5 рабочих дней). На втором этапе производятся доработка системы и подготовка финальной версии с учетом пожеланий (1–2 рабочие недели). На третьем этапе выполняется тиражирование решения (установка финальной версии на все КПК и обучение персонала). В частности, доработка системы в соответствии с условиями модельного ТЗ потребовала 8 ч (стоимость – около 4000 руб.[1]).

Дополнительные возможности. Помимо процесса формирования заказа программа в базовой версии позволяет отображать контактную информацию (например, звонок по заданному телефону из адресной книги КПК/коммуникатора) и работать с ней. В БД имеются данные о предыдущих отгрузках и о дебиторской задолженности клиента. Агент может продемонстрировать покупателю фотографии товара.

Особенности и отличия системы. Прежде всего это возможность индивидуальной доработки. Финальная версия будет в точности соответствовать бизнес-процессам заказчика, программа содержит только необходимую для работы функциональность. Система разработана на Си++ с использованием WTL 7.5 и STL (что на практике означает отсутствие необходимости устанавливать на терминалы такие компоненты, как SQL Server Mobile или .NET Compact Framework) и позволяет добиться стабильной работы комплекса даже на не слишком мощном оборудовании. Кроме того, имеется отдельный модуль редактирования печатных форм (для Van-selling), позволяющий быстро настроить внешний вид и содержание документов. Предусматриваются модули обмена с пакетами «1С» 7.7 и 8.Х, Microsoft Dynamics NAV, «СБиС++» 1.9 и 2.Х

Обмен данными с КИС происходит с помощью внешнего отчета «1С» (ExchangePDA.ert); на КПК данные передаются в файлах DBF, обмен информацией возможен как локально, так и дистанционно (по каналам GPRS, WiFi; пользователь может контролировать частоту и масштаб сеансов связи).

Описание решения. Для решения базового набора задач использовано два программных продукта. Модуль «Создание заказов» (Pre-selling) позволяет на основе актуальной (на момент последнего соединения) информации о складских остатках и взаиморасчетах сформировать предварительный заказ, опираясь на рекомендованный перечень товаров для торговой точки и историю предыдущих заказов (анализируя динамку). Модуль «Выездная торговля» (Van-selling) позволяет отгружать товар непосредственно в торговую точку за наличный или безналичный расчет с печатью всех необходимых первичных документов (вид и содержание документов могут меняться администратором системы); при необходимости агент может сделать предварительный заказ. При этом учитывается актуальная информация по остаткам на мобильном складе (автомобиле) и истории взаиморасчетов.

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

Для автоматизации сбора мерчендайзинговой информации также используется программа «НАПОЛЕОН. Создание заказов (Pre-selling)», агент может собирать информацию о наличии товарных единиц в витринах торговых точек.

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

Экономическая часть. Ориентировочная полная стоимость проекта (оборудование, ПО, работы, доработки исходя из условий задачи) – 663 500 руб. В случае выполнения работ по внедрению специалистами заказчика стоимость составит примерно 643 500 руб.

Схема лицензирования программных компонентов:

• Лицензируется только клиентская (мобильная) часть.

• Лицензирование проводится с помощью регистрационных кодов.

• При замене оборудования (в случае поломки и т. п.) новую лицензию покупать не нужно.

Как и его коллеги, данный разработчик решал задачу внедрения мобильной торговли для оптово-розничной компании, специализирующейся на торговле продовольственными товарами. Имеется пять филиалов с количеством до 50 торговых агентов в каждом. В каждом филиале до 10 агентов занимаются прямыми продажами (торгуют «с колес»), остальные осуществляют сбор заявок. Оперативный учет ведется на конфигурации «1C:Предприятие 8.1. Управление Торговлей 10.3» с несущественными доработками, которые произвели программисты компании. Базовый набор задач для внедрения системы мобильной торговли предусматривал автоматизацию сбора заявок и мерчендайзинговой информации, а также доступ агента к актуальной информации о клиентах и номенклатуре. Обмен данными между учетной системой и торговым агентом осуществляется по каналу связи GPRS.

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

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

Описание решения. Основная задача внедрения комплекса мобильной торговли – оптимизация процесса сбора и обработки заявок клиентов. В процессе сбора заявок торговый агент обеспечивается информацией для принятия решения: реквизиты клиента, текущая задолженность, номенклатура, остатки, скидки, типы цен, история, план продаж. Особо стоит отметить функции работы с отчетами. Они не встроены в интерфейс мобильной части, а загружаются с сервера. Супервайзер без привлечения программистов может добавить торговому агенту любой отчет. На КПК отчет передается в виде HTML-страницы, а формируется на сервере, что позволяет снизить требования к быстродействию КПК.

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

Интерфейс. Процедура добавления заявки выполняется в несколько шагов. При выборе клиента автоматически заполняется шапка документа (фирма, от которой осуществляется продажа, реквизиты клиента, стандартный договор, тип цены и скидка, текущая задолженность). На втором этапе оформления заявки производится подбор товара. Список товаров содержит мощную систему фильтров, есть также поиск по наименованиям. К каждому наименованию товара может быть добавлено любое количество информационных сообщений, например, информация о проводимых акциях, выделение товаров-новинок и пр. Серьезную помощь в подборе ассортимента может оказать история продаж товара в данной ТТ и рассчитанный заранее план продаж. Еще одна интересная функция – формирование ассортимента заявки одним щелчком мыши (на основе данных о плане продаж). Формула подсчета плана продаж не является постоянной и определяется в модуле интеграции. Одновременно с формированием ассортимента торговый агент может в этом же документе отражать информацию об остатках товара в ТТ. В зависимости от введенного остатка производится автоматический перерасчет плана продаж. Заявка готова, ее можно отправлять в офис.

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

Отдача от внедрения. Практика использования «Моби-С» в сходных с модельными компаниях показала, что автоматизированный агент может обслужить на 30% больше торговых точек, чем не имеющий средств автоматизации. Использование GPS-навигации позволяет контролировать время и маршрут перемещения торгового агента, агент вынужден действительно посещать торговую точку, а не принимать заявку по телефону. Повышается качество обслуживания клиентов, снижается количество ошибок и нагрузка на операторов, принимающих заявки в офисе. Сокращается время приема заявки и доставки товара.

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

Серверная часть «Моби-С» представляет собой модуль интеграции (внешний отчет) с учетной системой клиента. Модуль интеграции одновременно является интерфейсной частью и служит для настройки параметров обмена данными с торговым агентом, формирования отчетов, просмотра маршрута перемещения и обмена сообщениями.

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

Оценочная стоимость реализации модельной задачи в целом:

• Общая стоимость: 3275 тыс. руб.

• Стоимость программной части: 750 тыс. руб. (в расчете на 250 лицензий).

• Стоимость лицензии на одно рабочее место: 3000 руб.

• Клиентом была выбрана лицензия «Моби-С» Pro, так как обязательным условием ТЗ был контроль торговых агентов с помощью GPS.

• Стоимость оборудования: 2525 тыс. руб. (в расчете на 250 торговых агентов, 50 заняты прямыми продажами).

• Стоимость коммуникатора на одно рабочее место: 8500 руб.

• Стоимость мобильного принтера на одно рабочее место: 8000 руб.

Правила лицензирования. Разработчик предлагает две версии системы: «Моби-С» и «Моби-С Pro», различающиеся по функциональности. Лицензионный ключ для «Моби-С» на один КПК стоит 2000 руб., «Моби-С Pro» – 3000 руб. Лицензирования требует только мобильная часть «Моби-С»; модуль интеграции с учетной системой (серверная часть) распространяется бесплатно и может использоваться на любом количестве компьютеров. Лицензия привязана к физическому устройству (КПК или коммуникатору) и в случае его поломки или утери не восстанавливается. Все обновления программы и переход на новые версии бесплатны.

«Нео Матрикс» – новый продукт на рынке программных решений по автоматизации мобильной торговли с использованием карманных компьютеров (КПК). Графический интерфейс табличных частей справочников и документов(data-grid), а также база данных (data-set) являются продуктами собственной разработки компании «Нео Матрикс».

Модельная задача для этого продукта предполагала автоматизацию региональной оптово-розничной компании с активной номенклатурой порядка 3,5 тыс. товарных позиций. Примером может служить любая торговая фирма, реализующая кондитерскую или алкогольную продукцию нескольких производителей. Учетная система компании – SQL-версия «1С:Предприятия 8.1.», компания не только лицензирует программный продукт, но и полностью осуществляет его обслуживание и настройку как программной, так и аппаратной части. Возможны обучение персонала и оперативные доработки программного комплекса по желанию заказчика.

Структура системы. Для хранения и обработки информации в АСМТ «Нео Матрикс» используется MS SQL Server 2005. В данном примере базы данных «1С:Предприятия 8.1» и АСМТ «Нео Матрикс» расположены на одной инсталляции SQL-сервера. Сервер мобильной торговли при помощи хранимых процедур обеспечивает обмен данными между базами мобильной торговли и учетной системы в двух направлениях. Время выгрузки полной информации по всем торговым агентам составляет несколько минут. (Выгрузка такого же объема информации с использованием внешней обработки на языке «1С» занимает несколько часов.) При этом для работы мобильной торговли нет необходимости запускать программу «1С:Предприятие».

Функционал АСМТ «Нео Матрикс» в целом соответствует возможностям программных решений, представленных на рынке другими разработчиками. В то же время средства быстрой разработки платформы .NET позволяют в разумные сроки создать новые или адаптировать текущие возможности программы под потребности клиента. Кроме того, следует отметить ряд оригинальных интерфейсных решений.

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

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

Синхронизация и связь. Остановимся более подробно на синхронизации ранее набранных заказов в КПК с офисной учетной системой компании. В торговой точке клиента агент оформил заказ и подготовил его для отправки в офис. Посредством мобильной связи заказ передается на сервер мобильной торговли, который сохраняет его в учетной системе компании. Далее учетная система по команде с сервера или по таймеру обрабатывает полученный заказ. Результат обработки возвращается на сервер мобильной торговли и далее попадает на КПК торгового представителя. Весь процесс проходит за один сеанс мобильной связи (длительностью в 2–3 мин). Результат обработки заказа выводится на экран КПК по каждой строке табличной части. Товарные позиции, в которых заказанное количество меньше остатков на складе, подсвечиваются. Торговому представителю достаточно на месте отредактировать табличную часть заказа и повторить сеанс синхронизации. В итоге для торговой точки будет зарезервирован товар и названа точная сумма заказа.

Дополнительные функции. Экономичный режим GPS-мониторинга передвижений торгового представителя на маршруте позволяет существенно увеличить продолжительность работы карманного компьютера на одной зарядке аккумулятора. К примеру, на коммуникаторе ASUS P527 при снятии показаний с GPS-приемника каждую минуту зарядки аккумулятора хватает на 18 ч работы, а при снятии раз в 10 мин – 44 ч.

Стоимость АСМТ «Нео Матрикс». Лицензия на одно рабочее место – 5000 рублей. Каждому новому клиенту бесплатно предоставляется пять лицензий. Стоимость часа работ по интеграции и обучению пользователей приравнивается к стоимости часа услуг местного представителя фирмы «1С».