У сучасному високотехнологічному світі середні і великі підприємства використовують більш десяти різних програмних рішень. Від поштових клієнтів, інформації про клієнтів, постачальників, продукції до складних систем CRM і ERP. Рано чи пізно з'являється необхідність в інтеграції, так як з ростом бізнесу розростаються і бази даних.
Використовуючи в роботі інтеграцію шин даних, Ви зможете вирішити частину найбільш гострих питань в управлінні свого бізнесу.
При інтеграції використовується не класична шина даних (ESB) *, а шина (API Layer), яка маршрутизує пакети з різними системами, займається тим, що ці ж дані зберігає і конвертує, при необхідності, з однієї системи в іншу.
*Шина - це ESB, яка займається: маршрутизацією, збором , відправкою, статистикою пакетів, зберігає інформацію про те, які системи отримали пакети і чи відбулися в системі трансформації.
Ця стаття опише схеми роботи і де може застосовуватися дана Перша технологія, які бізнес-завдання можна вирішити при її застосуванні.
В технології інтеграції шин даних використовують певні кейси та архітектурні рішення для врегулювання ряду прикладних задач бізнесу:
В основному всі ERP, CRM системи класичного типу. Сервера MS SQL в основному побудовані за нормальними формами. Іноді для систем BI необхідно ці дані денормалізувати в дуже широкі великі таблиці.
Дане рішення може використовуватися, коли необхідно проаналізувати великі проміжки даних. Використовуючи інтеграцію, ми не чіпаємо облікову систему для збору даних.
Коли ми з основної системи періодично вивантажуємо в шину набір даних (нормальний або денормалізований) для використання іншими системами - ми не навантажуємо основну облікову ERP систему.
Денормалізація даних допомагає:
Часто на сучасних підприємствах впроваджені досить старі завдання і системи, які в певний момент перестають бути актуальними. Тобто ми приходимо до тієї точки, коли технологічно платформа не надає нових інструментів. Неможливо в "1С:Підприємство 7" зробити, наприклад, API доступ для інших систем. І нам потрібен якийсь прошарок, який буде цей доступ надавати. Для цього використовується шина даних, коли налаштовується інтеграція з "1С:Підприємство 7". Вона виконується раз в якийсь проміжок, а шина даних вже в оперативному режимі віддає ці дані.
Ці продукти важливі і цікаві з точки зору історичної інформації, проте іноді вимагають переходу і інтеграцію з новими системами. І API layer в шині даних - цю можливість надає за рахунок того, що за API можна звернутися до будь-яких даних.
Звідси випливає відповідно наступне завдання: перевпровадження ERP, CRM систем
Завдання дуже непросте. У більшості фірм воно лежить в стратегії. Багато ERP систем, впроваджені кілька років тому, необхідно перевпровадити. Зробити це одним стрибком досить складно.
Можливості перевпровадження системи:
Можна використовувати ітераційний метод - виділення якихось шматків.
Є окремі незалежні ділянки, які можна вирвати в шину і забрати при цьому історичні дані. Ці дані можна: залишити в шині функціонал або мігрувати в нову систему. Плюс це дозволяє запаралелити роботи.
При переході на якусь іншу систему, якщо ми окремі функціональні блоки виділяємо в шину і працюємо за API з іншої системи з цими даними, ми зменшуємо загальний пул того, що нам потрібно перенести в нову ERP систему. Тобто ми, як би, розрізаємо на частини і ділимо момент переходу на нову систему.
Дуже часто використовується для різних інтеграцій, особливо з інтернет сайтами. Всі платформи інтернет-сайтів мають досить різну архітектуру, з точки зору класичних для нас позицій: номенклатура, характеристики номенклатури (кольори, обсяги), замовлення, контрагенти і так далі. Вони практично завжди не стикуються з самою ERP-системою - відрізняються або на технічному рівні, або на рівні логіки. Що мається на увазі?
Наприклад, ми продаємо олівці: зелені та червоні. І на сайті це одна номенклатура з різними кольорами. PrestaShop, OpenCart та інші CMS так відображають дані. У ERP історично склалося, що у цих олівців різні артикули. І дуже часто він заведений не в номенклатура-характеристика, а в самій номенклатурі. І, відповідно, обмін між цими системами порушений.
Треба мати десь цю відповідність. Тобто матрицю того, як одна позиція з ERP системи трансформується в позицію з характеристикою в системі інтернет сайту. Відповідно для цього можна або використовувати пряму інтеграцію "точка-точка" і написати десь матрицю відповідності. Або використовувати шину, яка буде цю матрицю відповідності в собі зберігати для обміну.
Приклад: кейс для компанії modnaKasta. У них вся система була цілісна, але вони захотіли її розбити. Так як захотіли більш просунуту WMS систему і не було необхідності в бухгалтерії бачити джинси в різних розмірах і різних кольорів.
Приїхало 10 тисяч в контейнері і в кінці місяця бухгалтерія може списати їх п'ять тисяч і не думати про те, якого вони формату. Але це абсолютно неможливо з точки зору складу. Кінцевому користувачеві треба відвантажувати конкретний колір і конкретний розмір.
Тому це - завдання згортки даних, коли в момент міграції з однієї системи в іншу систему, ми втрачаємо ряд інформації. Тобто, ми її згортаємо: ми в момент передачі згортаємо інформацію до рівня того споживання, яке потрібно іншій системі.
Наприклад, ми робимо чат бот "скільки співробітнику залишилося днів відпустки відгуляти". Цю інформацію можна отримати: звертаючись безпосередньо до ERP системи і розраховуя цю інформацію, навантажувати систему. Як правило, всередині системи немає точної цифри - вона розраховується. Або раз на добу цю цифру треба розраховувати. Частіше ніж раз на добу ця інформація не оновлюється - вона не потрібна. Тобто з'являється можливість звертатися в чат бот за даною інформацією (підсумувати), не навантажуючи основну систему.
Зараз стає актуальним питання поділу системи. Все частіше у компаній, які мають велику ERP систему, виникає необхідність робити режим самообслуговування. Як приклад, щоб замовники могли зайти в особистий кабінет, зробити замовлення, простежити інформацію. Таким чином зменшується навантаження на call-центр і менеджерів з продажу. Робота з постійними замовниками автоматизується. Це перше завдання.
Друге завдання - безінтерфейсні системи. Великі замовники просять, щоб за API записувалося замовлення. І тут виникає проблематика доступу до периметру.
Якщо периметр, сильно захищений - то він не дивиться в ERP систему. Є два варіанти:
Іноді, в момент надання доступу, є ряд обмежень. Як приклад, компанія Parfex - займаються парфумерією. Вони не видають своїм дистриб'юторам кінцеву цифру залишків на складі. Оскільки ринок у них насичений і деякі великі роздрібні мережі можуть створити штучний дефіцит певного товару. Вони можуть скупити весь парфум певної марки і спеціально завищити на нього ціну.
Тому в момент вивантаження в таку шину, вони надають доступ просто до інформації: є цей товар чи немає цього товару. Обмежують ряд контексту, того що можна бачити.
Те ж саме завдання для Ukravit робимо велику інтеграцію (близько 14 систем). Компанія своїм дистриб'юторам не повідомляє всю інформацію про склад. Показують індикативно: товару багато, товару унормовано або товару мало.
Тим самим, з одного боку, стимулюють. Коли товар закінчується - викупити залишки собі на склад. З іншого боку, не показувати конкретну цифру. Коли замовник бачить, що цього товару дуже багато - може момент покупки відкладати.
Коли ми всередині зі своєї ІТ системи надаємо нашим партнерам якусь інформацію. Тобто ми, наприклад, продаємо в величезій кількості роздрібних точок продукцію. На роздрібній точці, іноді є своя облікова система, іноді немає (тоді ведемо облік за ними). Надаємо партнерам інструменти аналізу їх же продажів. Ми показуємо скільки відвантажено, статистику замовлень, графіки і так далі.
Зворотнє завдання, яке вирішують за допомогою цього - коли є облікові системи і ми формуємо за них замовлення, яке вони зроблять. З боку клієнта є інтеграція до нашого API, яке пише, чого ми скільки продали і ми можемо відловити момент, коли готувати нове замовлення цьому замовнику і автоматом його передавати.
* сукупна вартість володіння інформаційною системою (Total Cost of Ownership )
В обліку сукупної вартості володіння дуже часто забувають один пункт - найостанніший. Всі розуміють що воно складається з: покупки ПЗ, впровадження, супроводу, якихось обов'язкових платежів ліцензійних і так далі. І завжди забувають пункт, який вкрай рідко навіть в документації зустрічається - це вартість виходу.
Тобто ви поставили софт і через час вам від цього софта доводиться відмовитися. Рано, пізно, десять, п'ять років. Через якийсь час це трапиться. І для кожного софта ця вартість виходу різна. Тому що є технології, з яких дуже важко забрати дані, у яких денормалізована структура, у яких неможливо зрозуміти (якщо дивитися в базу даних) які таблиці за що відповідають. Ось ця частина вона дуже сильно збільшує вартість.
Створенням для себе обмінів і винесенням інформації в шини, ви зобов'язані її якимось чином структурувати і у вас з'явиться API. Маючи шину інтегровану з ERP системою, при переході на інше програмне забезпечення - у вас залишається джерело доступу до цієї інформації. За рахунок цього доступу - зменшується сукупна вартість володіння інформаційною системою (Total Cost of Ownership - TCO). Даний доступ дуже простий, швидкий і автоматично задокументований.
Часто відбувається, що компанія грузне всередину однієї технології. Розвиваючи тільки одну технологію в стеці - стаєте заручником однієї системи. І як наслідок підприємство стає абсолютно залежним від дуже чіткого вузького кола фахівців. А в деяких випадках ще й від закритих систем, які вже не підтримуються.
Модульность функцій - це можливість винесення частини інформації, що допомагає зменшити залежність від однієї певної системи.
Своє рішення будуємо на C#/. NET, Web API і Vuetify JS Framework. Доступ за швидкістю максимально швидкий і дуже легко масштабується за рахунок, як технічного рівня, так і не технічного рівня. Що мається на увазі? Технічний рівень - коли ми просто розширюємо параметри серверів. Тобто було стільки - поставили більше - продуктивність збільшилася.
Система працює, як з реляційними, так і з нереляційними даними. Можливо використовувати в якості бази даних як MS SQL, так і якісь нереляційні бази: Mongo, Redis і так далі. Відповідно, можна використовувати для ряду завдань, якщо зручно - MS SQL, для ряду задач використовувати ненормовані структури, у вигляді документів/об'єктів нереляційних баз даних.
В разі впровадження додаткового модуля - немає необхідності в перезбірці додатку. Крім того, що це шина, яка обмінюється даними, вона має свій інтерфейс на Vue.js і є можливість додавати вже готові модулі. На сьогоднішній день, є ряд рішень, який пов'язаний з: інтеграцією інтернет магазинів, "1С:Підприємство" платформами і CRM платформами: з Bitrix, AmoCRM і іншими.
Власні розробки:
Система побудована на базі відкритого коду, що далеко не у всіх так, хоча це так і заявляється. Сама платформа, ядро, код всередині ядра - відкриті. C# - з боку бекенда, з боку фронтендів - це стандартний Vuetify на Java Script і також можна будувати свої модулі. Зараз готуємо окремий сайт під платформу і інструкцію яким чином зробити собі fork зі сховищ і використовувати для своїх цілей відкритість самого коду. Можна проінспектувати, що відбувається всередині коду і як це працює.
Ми спеціалізуємося на цьому вже останні років п'ять. За цей час ми накопичили великий досвід готових кейсів і теоретичну базу для інтеграції різних систем. Всі дані доступні в системі Genumis. На сайті є опис та можливість використовувати в хмарних і наших серверах або використовувати у себе на локальних машинах.
Використання платформи Genumis дає можливість вашому бізнесу поступово вибудовувати ІТ середовище нового покоління.
Зовнішні веб-сервіси, інтегровані з вашою основною обліковою системою за API дають можливість:
*Копіювання матеріалу можливо тільки з посиланням на джерело та із зазначенням автора матеріалу. Дякуємо за повагу інтелектуальних прав власності. TQM systems
SaaS сервіси
Програми 1С:Підприємство
CRM
ERP
Node.JS, .NET
1С:Підприємство
API, IPasS
Разработка Web Apps
1С:Підприємство Автоматизація
Аудит IT проектів
Інтеграція 1С:Підприємство
Отримуйте наші інформаційні матеріали:
Працюємо на IT-ринку з 2008 року.
Наша місія - спростити управління даними.
Copyright © 2008-2024 TQMsystems. Всі права захищені. Privacy Policy | Terms of Service