Пресс-центр
Журнал «Складские технологии» 10 Янв 2007

Разделение информации между КИС и WMS

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

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

Справочные данные

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

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

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

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

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

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

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

Данные о складских операциях

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

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

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

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

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

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

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

Отчетность

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

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

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

Схема взаимодействия систем при операции поставки

Максим Власов, директор по развитию компании AXELOT

Мы используем файлы cookie для улучшения работы сайта