Категории

Cуществуют следующие способы оплаты за занятия:

  • Абонемент на 8 посещений (срок действия 1 месяц) - 300 грн.;
  • Абонемент на 4 посещения (срок действия 1 месяц) - 200 грн.;
  • Абонемент на 12 посещений(срок действия 1 месяц) - 400 грн.;
  • Разовое посещение - 60 грн.
(ДЛИТЕЛЬНОСТЬ ЗАНЯТИЙ ПО 1,5 ЧАСА)

Як навчити WMS спілкуватися із зовнішніми системами

Наше деловое партнерство www.banwar.org

Ви плануєте впровадити на складі WMS і хочете, щоб вона стала органічною частиною вашої інформаційної структури, хочете налагодити взаємодію між відділом продажів, складом і транспортом, виключивши втрати даних. Що потрібно зробити і про що подумати, щоб

Що потрібно зробити і про що подумати, щоб

Завдання організації взаємодії складської і корпоративної облікової системи актуальна практично завжди. Винятки можуть бути пов'язані з автоматизацією складів відповідального зберігання, для яких WMS виконує роль основної бізнес-системи, де оформляються всі комерційні операції компанії, тому необхідність в обміні іноді відсутній. Проте і склади відповідального зберігання в рамках проекту автоматизації часто організовують інтеграцію зі своїми системами бухгалтерського обліку, обліковими системами постачальників, транспортними системами та іншими суміжними інформаційними системами. Тому, узагальнивши наявний досвід, можна сказати, що інтеграція WMS і зовнішніх систем - задача при автоматизації складу обов'язкова.

Обмін інформацією - процес не тільки необхідний, але і дуже відповідальний. WMS-система є носієм найбільш точної та актуальної інформації про стан залишків товару на складі, на яку спираються інші інформаційні модулі компанії. Нестійка зв'язок між системами, втрата даних в процесі обміну або некоректна їх трактування в системі-одержувачі чревата великими проблемами в роботі складу і компанії в цілому.

Процес розробки інтеграції між WMS і будь-який інший зовнішньою системою складається з трьох типів завдань: функціональних, технічних і організаційних. До функціональних завдань відносяться визначення складу синхронізованої довідкової інформації, точок взаємодії систем по кожному з процесів, що інтегруються бізнес-процесів, способів запуску обмінних процесів і складу мігруючої інформації. Технічні завдання - це вибір технології інтеграції, визначення форматів обміну і засобів контролю механізму інтеграції. Основна організаційна завдання - забезпечити взаємодію сторін при розробці та впровадженні інструментів інтеграції.

Розглянемо докладніше кожну із завдань на прикладі взаємодії між системою WMS і торговельною системою.

функціональні завдання

Для організації взаємодії потрібно пройти кілька етапів.

Синхронізація даних

На першому етапі з'ясовується, які дані необхідно синхронізувати в обох системах для забезпечення коректного обміну даними.

В першу чергу це, звичайно, каталог товарів, що зберігаються на складі. Крім унікального ідентифікатора і найменування товару на складі часто потрібні дані про фасовках товару із зазначенням кратності вкладення одиниць, їх вагогабаритні характеристики, штрих-коди і інша значуща для даного складського технологічного процесу інформація. Щоб уникнути плутанини і дублювання в роботі з товаром вкрай бажано, щоб ведення каталогу товарів підпорядковувалося жорстким правилам і виконувалося тільки в одній системі - тієї, де працюють менеджери із закупівель. WMS в даній ситуації - ведена система, яка може доповнювати каталог своїми специфічними даними (наприклад, правила обробки), але не повинна створювати нові позиції в списку товарів.

Крім каталогу товарів часто синхронізуються дані про контрагентів, іноді - про співробітників. Більшого обсягу пересічної довідкової інформації зазвичай не потрібно.

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

Ці роботи необхідні, навіть якщо існує єдине джерело даних - наприклад, уже працює торгова система. При появі WMS іноді виникає спокуса керувати новими позиціями довідників в обох інформаційних базах, так як саме склад першим бачить новий товар і може внести інформацію про нього в систему. Якщо піддатися цій спокусі, то буде отриманий заплутаний довідник товарів з дубльованими позиціями. У правильно побудованому бізнес-процесі обробки нового товару інформацію першими отримують і вносять в систему закупівельники. Склад вже може доповнити або виправити окремі дані - такі як, наприклад, вага або габарити товару.

Якщо ж з WMS буде взаємодіяти більш однієї зовнішньої системи, тоді питання вивірки і визначення єдиного джерела даних стає ще більш значущим. Наприклад, зі складом взаємодіють виробнича і торговельна компанії єдиного холдингу, кожна з яких має свою інформаційну базу, де каталоги номенклатури не збігаються, хоча фізично працюють з одним і тим же товаром.

Синхронізація бізнес-процесів

На цьому етапі необхідно зрозуміти, які події на складі повинні відображатися і в корпоративній системі і, навпаки, які плани і / або рішення торгової системи повинні викликати руху на складі. Як приклад можна привести оформлення замовлення постачальнику або наказу про планову інвентаризації. У першому випадку на склад прийде інформація про очікувану постачання ( «план»), у другому - конкретна задача на проведення інвентаризації ( «рішення»).

Наприклад, замовлення покупця, оформлений в торговельній системі, обов'язково повинен бути переданий на склад, де почнеться його обробка. У свою чергу склад повинен повідомити в корпоративну систему результат відвантаження: весь замовлення виконано або щось не знайдено і не було відвантажено.

Іншим прикладом може служити процес відбору товару. Потреба торгової системи в даних результату відбору залежить від того, як організований бізнес-процес продажів в компанії. Цей приклад ілюструє унікальність інтеграції WMS і торгової системи в кожному конкретному випадку. Якщо склад обслуговує зовнішніх покупців, то торговельній системі важливо своєчасно знати, як пройшов процес відбору, щоб коректно оформити фінансові документи на товар. У цьому випадку між передачею замовлення на склад і відвантаженням товару покупцеві в інтеграції обов'язково повинен бути зафіксований момент завершення відбору. Якщо ж склад працює зі своєю роздрібною мережею, то ця стадія обміну даними може бути пропущена, так як недопоставка у власні магазини може бути заповнена в наступному замовленні, без виправлення фінансових документів - для контролю залишків досить знати, що в результаті було фактично відвантажено в кожен момент.

В результаті на цьому етапі повинен бути складений список операцій в складської і торгової інформаційних системах, які повинні викликати відгук у парній системі.

точки взаємодії

Наступний крок - визначення моментів обміну даними і ініціаторів взаємодії.

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

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

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

На цьому етапі повинні бути визначені ті події або документи (рахунки, накладні, листи відбору), їх статуси (створений, записаний, проведено, «в роботу», «на склад»), терміни їх обробки і інші значущі параметри, однозначно визначають момент , коли кожна з систем має (або не повинна) передати свої дані в іншу систему.

Способи запуску процесів обміну

На цій стадії потрібно визначити, чи буде обмін повністю автоматичним, напівавтоматичним або ручним в кожній з точок взаємодії.

Практично завжди висловлюється побажання повної автоматизації. Але на практиці не все так очевидно. Програмне забезпечення може виконати дію, якщо умови його виконання однозначно визначені, а це не завжди можливо. Найбільш характерний приклад: торгова система потребує даних про результат відбору замовлення на момент його закінчення. В який момент можна вважати відбір закінченим? У процесі підбору товару можливі різні відхилення: щось не знайшли, щось знайшли, але браковане або іншого сорту і т. П. Відбір може йти в кілька ітерацій, і однозначно визначити на кожній ітерації, чи буде відбір продовжений, можуть тільки людина відповідальна за відбір замовлення, і менеджер клієнта. Якщо при відборі проблем не виникло, то результат може бути переданий в торговельну систему автоматично, без участі користувачів. Якщо ж були проблеми, то рішення можуть бути прийняті різні - починаючи з повної відмови від замовлення, якщо не знайдена ключова позиція, закінчуючи відправкою «як є», якщо проблема незначна. В такому випадку результат відбору після з'ясування всіх обставин підготовки і відправки замовлення відправляється в корпоративну систему з WMS по сигналу користувача. Для прихильників абсолютної автоматизації зауважу, що ця схема, звичайно ж, не єдино можлива при обробці відбору, але часто зустрічається на практиці.

В результаті на цьому етапі має бути вироблено рішення про те, як буде запускатися процедура обміну в кожній з точок взаємодії систем.

Склад мігруючої інформації

Цей етап відносно простий. Тут потрібно зрозуміти, які дані необхідно передати в кожен момент взаємодії між системами для того, щоб приймаюча сторона змогла однозначно їх трактувати і обробляти. Наприклад, при передачі плану поставки з торгової системи в систему WMS потрібні загальні відомості про постачання (номер документа, найменування постачальника, очікувана дата поставки) і відомості про товари (унікальний ідентифікатор товару, очікувана кількість). Залежно від потреб процесу обробки, даних може бути значно більше.

На цьому етапі повинні бути складені списки необхідних даних по кожній з точок взаємодії систем.

Технічні завдання

Технічні способи інтеграції можуть бути дуже різними, і рішення про вибір конкретного способу також потрібно приймати в процесі розробки інтеграції.

При цьому повинні бути визначені всі необхідні механізми і інструменти, що забезпечують контроль працездатності обміну і зручний моніторинг відхилень. Це можуть бути різні системи відгуків про успішне отримання даних, системи сигналізації про втрату зв'язку або проблемних транзакціях, журнали реєстрації подій обміну з можливістю ідентифікації причин, що викликали проблеми. У число засобів контролю входять, наприклад, спеціальні каталоги для зберігання оброблених файлів, як вдало завантажених, так і не пройшли вхідний контроль однієї з систем.

В результаті повинен бути сформований список вимог до створення, зберігання і обробки даних про діяльність механізму обміну.

організаційні завдання

Приступаючи до розробки механізму інтеграції між WMS і торговельною системою, необхідно забезпечити тісну взаємодію всіх учасників процесу. Інтеграція вимагає модифікації обох систем, причому в торговельній системі вона зачіпає відразу кілька процесів, тому в обговоренні інтеграції повинні брати участь люди, компетентні у всіх функціональних областях, пов'язаних зі складом (закупівлі, продажу, бухгалтерський облік та ін.), Або навіть групи співробітників . Тут слід звернути увагу на комунікації і швидкість узгодження рішень. В ідеалі керівник проекту з боку замовника повинен володіти достатньою компетенцією і повноваженнями, щоб прийняти консолідоване і остаточне рішення.

На особливу увагу заслуговує ситуація, коли виконується паралельне впровадження торговельної та складської систем із залученням різних підрядників для кожної з систем. В цьому випадку пред'являються підвищені вимоги до комунікацій між трьома сторонами. Як показує практика, поставити завдання по інтеграції систем на базі готових продуктів (наприклад, типових рішень «1С») можна до етапу узгодження і реалізації їх базового функціоналу. Обговорення і узгодження робіт по інтеграції необхідно проводити за участю трьох сторін, а результат повинен бути відображений в документі, завізованому усіма учасниками. Це допоможе уникнути проблем при реалізації функціоналу інтеграції та його впровадженні, а якщо вони все ж виникнуть, то дозволить розмежувати відповідальність між замовником і підрядниками.

Розробка інтеграції між WMS і ERP вимагає відповідального підходу, великий деталізації і компетенції. Головна складність полягає в розмаїтті компаній, їх бізнес-процесів, організаційних регламентів і способів реагування на нестандартні ситуації. Саме тому не можна сказати, що існує якийсь «типовий» варіант інтеграції, навіть якщо мова йде про типові продуктах з відомим функціоналом. Безумовно, можна використовувати вже наявні напрацювання і досвід, але в більшості випадків на логіку інтеграції накладає значний відбиток індивідуальність конкретної компанії.

Дарина Любовіна - керівник проектів компанії Axelot Logistics; [email protected]

В який момент можна вважати відбір закінченим?