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

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

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

Модуль в интегрированной системе управления предприятием

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

При использовании WMS (Warehouse Management System — система управления складом) акцент делается на автоматизации управления. С помощью сложных алгоритмов, учитывающих данные о складе и о размещаемых на нем товарах, WMS-системы максимально оптимизируют процесс организации складской деятельности, по сути принимая все управление складом на себя. Для организации эффективной работы склада необходимо выбрать WMS, отвечающую всем требованиям организации бизнес-процессов на складе: работа со штрих-кодами, считывание сроков годности, номеров ГТД и т.п. Одновременно с внедрением WMS потребуется закупить дополнительное оборудование (специальную складскую технику, стеллажи, терминалы), смонтировать сеть и установить серверы. Важно учитывать не только разницу в ценах у различных поставщиков, но и технические характеристики выбираемого оборудования, его возможности и работоспособность, а также наличие центров сервисного обслуживания.

Достоинства. Минимальные затраты на сопровождение приложения и БД. Затраты на сопровождение системы могут существенно различаться в зависимости от того, нужно ли поддерживать одно приложение или два, особенно если они работают на разных платформах.

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

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

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

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

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

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

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

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

Сложность архивирования данных. В интегрированной системе все складские проводки связаны с соответствующими операциями в модулях "Закупки", "Заказы", "Расчеты с поставщиками", "Расчеты с клиентами", "Управление запасами", "Налоги" и, наконец, в "Главной книге". Если понадобится избавиться от истории товародвижения по ячейкам и переместить ее в архив, сделать это будет не так-то просто.

Какой же вариант больше подходит лучше всего? Как обычно, универсального ответа нет. Даже не прибегая к утомительным расчетам, можно предположить, что совокупная стоимость владения интегрированной системой, включающей модуль управления складом, будет ниже, чем в случае использования сложной гетерогенной информационной системы с разнородными программами, объединенными посредством многочисленных интерфейсов. Возможно, для автоматизации собственного склада торговой компании среднего размера интегрированный модуль будет лучшим решением. Если только объем и интенсивность операций не слишком велики, если не требуется создавать надежную распределенную систему на базе ненадежных каналов связи и не слишком остро стоит задача последующих модификаций системы с учетом изменений складских технологий, используемых компанией. С другой стороны, крупной организации с распределенным складским хозяйством, по-видимому, лучше подойдет отдельная складская система. Впрочем, и здесь есть свои "если". К примеру, в компании, специализирующейся на оказании услуг по хранению и складской обработке товара, используемое решение должно обладать функциями биллинга.[2]

На практике, однако, дела могут обстоять иначе. Большинство автоматизированных систем класса ERP*, к которому относится и WMS, как правило, состоят из трех компонентов. Первый из них — это интерфейс, с помощью которого пользователи взаимодействуют с системой. Второй — хранилище данных, обеспечивающее доступ к информации. Третий — бизнес-логика, то есть специальные процедуры, посредством которых реализуются алгоритмы обработки данных в ответ на запрос пользователя. Внедрение ERP-систем, относящихся к классу "тяжелых" и практически не предлагаемых в виде коробочных решений, связано с большими затратами и может растянуться на большой срок. Большинство компаний приходят к необходимости иметь WMS, когда объем складской деятельности велик и для реорганизации требуются значительные изменения. Руководство должно понимать, что повысить эффективность работы склада, внедрив WMS, можно только со временем.

Наиболее значимые критерии для выбора системы управления складом с точки зрения потенциальных заказчиков представлены в таблице 1

Таблица 1. Критерии выбора системы управления складом.

Всего было опрошено 48 компаний, потенциально заинтересованных в автоматизации склада. Участники опроса могли выбирать до трех критериев в качестве наиболее значимых, поэтому общая сумма больше 100%. Результаты полученных цифр округлялись до целого[3].

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

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

Таблица 2. WMS решения, представленные в России[4]

Страницы: 1, 2, 3, 4, 5, 6