Концепції побудови ERP-систем на підприємстві

Румянцев Костянтин, Директор ТОВ "Софтоматіка"

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

Для чого взагалі потрібні концепції?

Спробуємо відповісти на це питання іншим питанням: яким буде Ваше підприємство через 10 років? Які властивості ERP системи будуть тоді затребувані? Загалом, ніхто не зможе чітко відповісти на завдання з такою віддаленою перспективою. При цьому підприємство має бути впевнена, що й у віддаленому майбутньому наявне у нього програмне забезпечення (ПЗ) буде сприяти розвитку бізнесу, і тільки таке ПЗ затребуване. Так от, для того, щоб конструювати систему, в т.ч. для цілей, які неясні, і завдань, появу яких ми не можемо передбачити, і існують концепції.

Приклад: Починаємо автоматизувати маленьке підприємство, в ньому три людини, одна комп'ютер. Кількість клієнтів - 10, найменувань товару - 20. Питання - яку архітектуру даних вибрати? Звернемося до концепції. По-перше, визначимося, що підприємство буде розвиватися (тобто ми його не закриємо через місяць). По-друге, галузь, у якою ми зараз працюємо - це тисячі найменувань, хоча на даний момент у нас всього 10 (наприклад, ми продаємо виключно мило, видів мила у постачальника може бути 100, ну 200 максимум, однак, якщо дивитися ширше - зубна паста, щітки, гелі і т.п., що називається господарчими товарами, а це вже десятки тисяч найменувань). Отже, виключити те, що ми будемо представляти весь асортимент, ми не можемо так само як не можна виключити, що з часом підприємство перетвориться на велику структуру. Тоді додаємо в концепцію постулат, що наша ERP-система повинна підтримувати довільну кількість найменувань товару і робочих місць, плюс повинна бути не вимоглива до мережі. Інакше, як створювати філії, якщо кожен з них потребують прокладки високошвидкісний мережі на багато кілометрів? Тепер очевидно, що найбільше підходить архітектура -- Клієнт-Сервер. Ось і рішення!

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

Імітаційна концепція: імітує реальне будова підприємства.

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

Адитивна концепція: інформаційна система доповнює людини (звідси і назва -- адитивна).

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

Як поводиться ентропія при зростанні системи?

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

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

По-друге, основним засобом для зменшення ентропії є ІНФОРМАЦІЯ. Наведемо приклад: на складі є товар, але продавці не мають інформації про залишки на складі. Немає інформації - немає відвантажень, система не працює, хоча і комірники, і продавці готові виконати свої обов'язки.

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

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

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

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

Тепер подивимося, що відбувається, якщо людська система починає укрупнюватися. Уявімо одного робітника. Припустимо, він помиляється вкрай рідко і випускає 1 браковану деталь до машини на 1000 не бракованих. Загалом, дрібниця. Але як тільки вузлів у машині стає близько 1000, і їх так само роблять робітники з таким же відсотком браку, то виявиться, що в кожній машині що-небудь, та не працює. Цей приклад говорить про те, що якщо така система збільшується, її ентропія теж зростає, і треба вживати заходів до її зменшення. Інакше система просто помре - кому потрібні 100% бракованих машин?

Стосовно до аддитивной і імітаційної концепціям.

Подивимося, як все це ставиться до наших концепцій.

Імітаційна. Припустимо, є абсолютно неавтоматизоване підприємство, воно складається з відділів, співробітники обмінюються папірцями, вважають на калькуляторах і т.п. Ось ми вирішили автоматизувати це підприємство виходячи з імітаційної концепції. Для цього ми з'ясовуємо, що робить кожен відділ, і, таким чином, отримуємо деякий набір завдань за кількістю відділів, які і вирішуємо. Хочу чітко позначити, що ми розуміємо під словом "відділ". Зовсім не обов'язково, що це буде саме ВІДДІЛ, в тому розумінні, як це прийнято на підприємствах. Це можуть бути і кілька відділів, і групи людей у різних відділах і підрозділах. Важливо, щоб була можливість згрупувати завдання таким чином, щоб при автоматизації підприємства вона розбивалася на підзадачі. Приміром, якщо в підприємстві 10 складів, то пишеться 1 модуль під назвою "Склад", бо він вирішує завдання складського обліку.

Як така автоматизація впливає на роботу підприємства?

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

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

Чому ж очевидний на перший погляд, спосіб вирішувати велику і складну задачу по частинах не гарантує стабільної роботи системи?

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

Поставимо завдання:

Необхідно, щоб система "людина - комп'ютер" функціонувала з мінімальною ентропією.

Ентропія на рівні комп'ютера.

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

Ентропія на рівні людини.

Оскільки ми вже визначили, що на рівні комп'ютера ентропія мінімальна, то відповідь однозначна - джерелом зростання ентропії в системі є людина! Це він помиляється, не може швидко переключатися з однієї справи на іншу і погано сприймає більше 9-ти об'єктів одночасно.

Як звести до мінімуму людські помилки (зменшити ентропію системи)?

По-перше, кількість можливих рішень повинно бути максимально обмежено.

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

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

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

Отже, випишемо ланцюжок, за якої ентропія системи мінімальна, а система, відповідно, найбільш стабільна і організована.

Всі просто: достовірна аналітична інформація - людина - правильне рішення -- коректне заклад даних за цим рішенням - зберігання даних - аналітична інформація

Як бачимо, коло замкнулося і перетворився на позначену раніше адитивну концепцію.

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

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

Адитивна концепція стійка і ефективна при постійно мінливих зовнішніх і внутрішніх умовах.

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

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

Які наші дії?

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

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

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

По-четверте, етапи повинні ставиться до будь-який документ (документ "замовлення", етапи - складання товару, його пакування, відвантаження зі складу, доставка до клієнта; документ "рахунок" - етапи розпечатано, відправлений і т.д.).

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

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

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://citcity.ru/