Дороги ведуть до “Сховища”. Обговорення “хворих тем” інформаційних проектів, Комерція, Різне, статті

– Я обіцяю навчити за 10 років віслюка всьому Корану
– Ходжа, що ти говориш?
Адже, шах тебе обезглавить, якщо ти не
виконаєш свою обіцянку!
– Так, за 10 років хтось помре – або шах,
або віслюк, або я …

Вільне тлумачення старої притчі для внедренцев ERP


Напевно, кожен, хто хоч раз стикався з «великими» інформаційними проектами, може підтвердити актуальність знаменитої жарти Ходжі Насреддіна.


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


У чому ж тоді проблема? Чому велика частина таких «серйозних проектів» закінчується відвертою невдачею? Чому такі відомі системи, як SAP, Oracle Financial, People Soft, не працюють ефективно, по Принаймні, в нашій країні? Буквально місяць тому один дуже серйозний начальник однієї з найвідоміших у нашій країні компаній зізнався на переговорах – що в Росії немає нормально впроваджених та ефективно функціонуючих проектів SAP R3.


Може, звичайно, мій співрозмовник і «перегнув палицю», але заперечувати проблему вже неможливо – серед кілька десятків добре відомих проектів SAP до «рапорту про впровадження» дійшли одиниці. А серед цих «успішних», мабуть, ні один не відповідає, ні заявленим цілям і очікуванням, ні декларованим можливостям системи, і, тим більше, не виправдовує мільйони доларів вкладень в проект.


Чому ж із завзятістю, гідною кращого застосування, все навколо повторюють свої заповітні «три літери»? З якої причини цей начальник знову і знову ініціює впровадження SAP R3? Чому консультантам цих непрацюючих систем готові платити зарплату, що перевищує дохід директора? Спробуємо, якщо й не розібратися в цих питаннях, то, хоча б поглянути на проблему «з іншого боку».


Що ж ми автоматизуємо?

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

Реальне рекламне оголошення,
яке, напевно, хтось прийняв всерйоз.


Років тридцять тому багато керівників були свято переконані, що головне для автоматизації – наявність техніки. Ось купимо великий, потужний комп’ютер, і він нам все порахує. Мабуть, з тих часів кочує жарт про радянських мікросхемах – найбільших мікросхемах у світі, з шістьма ніжками і двома ручками для перенесення за плечима. Та що там тридцять років? Ще рік тому один бухгалтер з жаром переконував автора, що баланс компанії складений без єдиної помилки, адже цей баланс «пораховано на комп’ютері». Коментарі зайві …


Минуло десятиліття. Люди, що приймають рішення, переконалися, що «програма партії і програма телепередач» не підходить для їх «самого потужного комп’ютера». Могутні сервера були завантажені на повну потужність … Але, чим завантажені? Весь персонал, від дівчинки-оператора до начальника відділу «захворів іграшками», сотні і тисячі годин робочого часу були присвячені набору і роздруку анекдотів, Камасутри та оповідань Дейла Карнегі. Настав час нових очікувань, нових ілюзій. Настала коротка епоха АСУ і АРМ-ів.


Ті, кому зараз за 30, добре пам’ятають цей час. Наївні дитячі ілюзії, що ще трохи, ще трохи і «зійде на нас АСУ». Нове загострення цієї «хвороби» прийшло з широким розповсюдженням «персоналок». Пам’ятайте lexicon, wd, перші, ще досить кострубаті електронні таблиці, вже грунтовно призабуті Multiplan, Lotus-123? А знаменитий FrameWork, який подекуди цілком серйозно розглядався як єдиного рішення всіх інформаційних задач (бажаючі «підтримати вітчизняного виробника» можуть згадати «Майстер»)? Історія повторюється – і на новому етапі розвитку такі ж “фахівці після двотижневих курсів перепідготовки »готові з апломбом« вирішувати всі ваші проблеми »за допомогою Excel або Access-а. А найбільш «просунуті» до кінця вісімдесятих знали слова FoxPro і Paradox (ті, хто чув про PAL, вважалися вже «зовсім крутими професіоналами»). Загляньте на будь-який форум програмістів. Сталий «дежавю» – так само, як 20 років тому, апологети 1С, Axapt’и, Oracle, Delphi намагаються переконати співрозмовників (а, може бути, себе?), що вони готові вирішити будь-яке завдання – проблема лише в тому, що замовник сам не знає, що хоче.


До абсурду така позиція була доведена в IT-відділі однієї великої фарм-компанії, основною функцією якого було обслуговування, підтримка та розвитку білінгу. Реакція на питання фінансистів була приблизно наступна:



  1. Наша задача – пояснити вам структуру даних системи, в яких таблицях зберігається інформація, які поля несуть смислове навантаження
  2. Якщо ви хочете щось порахувати, наприклад, «відвантаження» або «дебіторку», ви повинні мені написати ТЗ, вказавши з яких таблиць проводити вибірку з яких формальним критеріям
  3. На вашу ТЗ ми пишемо запит і надаємо вам результати цього запиту. Хто відповідає за отриману картину? Звичайно, ви самі – адже, ви ж визначили і таблиці і поля і критерії вибірки.

Оцініть ефективність роботи такого «транслятора»! Мимоволі згадується безсмертна фраза – «Я особисто пришивав гудзики! До гудзиків претензії є? “…


Минуло ще кілька років. Такі «круті прішівателі гудзиків» відважно провалили свої проекти, і деякі стали замислюватись – в чому причина постійних невдач? Новий час несло нові «рожеві ілюзії». Згадайте, як раптом стали шалено популярними IDEF, ERP, CRM – залежно від того, з чим зіткнувся такий «спеціаліст» або, що частіше, за продаж якого рішення він отримував свою «трудову копієчку».


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


Аргумент «всі так роблять» служив універсальним критерієм вибору. Автор був свідком як фраза «bestpractice»Консультанта одного з провідних аудиторських компаній, зовсім не розуміє суть і способи вирішення поставлених завдань, на Раді директорів послужила підставою запуску проекту вартістю понад півмільйона доларів.


Як ви думаєте, чим закінчився проект? Правильно – минув рік, бюджет був благополучно освоєний, результатів немає, і не передбачалося, а на порядку денному виник новий актуальне питання – «пошук крайнього». Ви здивовані? Автор, чомусь – ні.


Пропоную на деякий час стати «такими занудами», і спробувати хоч трохи розібратися в ситуації.


Коротко назвемо найбільш популярні «трьохбуквені поєднання»


В роботах Олівера Уайта (Oliver Wight) і Американського товариства по управлінню запасами і управління виробництвом [APICS92] були сформульовані алгоритми планування, сьогодні відомі як MRP (Material Requirements Planning) – планування потреб в матеріалах – наприкінці 60-х років, і MRP II (Manufacturing Resource Planning) – планування ресурсів виробництва – в кінці 70-х – початку 80-х рр.. Не вдаючись у тонкощі методології, підкреслимо суть підходу – «Оптимальне планування ресурсів, достатніх для виробництва продукції» .


Концепція ERP (Enterprise Resource Planning – управління ресурсами підприємства) запропонована на початку 90-х років аналітичною фірмою GartnerGroup. Суть ERP – ідентифікація та планування всіх ресурсів підприємства, які необхідні для здійснення продажів, виробництва, закупівель і обліку в процесі виконання клієнтських замовлень.


Не претендуючи на повноту, згадаємо ще кілька «трибуквених абревіатур»


CRM (Customer Relationship Management) – управління взаєминами з клієнтами


OPT (Optimised Production Technology) – оптимізована технологія виробництва


JIT (Just – in – time) – метод планування та управління


Бажаючі можуть легко продовжити цей список (наприклад, CAD / CAM / CAE, PDM …).


Спробуємо визначити спільну мету, яка об’єднує подібні методики.


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


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


Так що ж потрібно клієнту? Через що варто затівати такий складний і дорогий проект? Як не дивно, багато хто продовжує вірити рекламі і «солідним рекомендацій». Енергійні люди, готові продавати пінгвінам в Антарктиді старі радянські холодильники, переконують в «надкорисну чергового ERP». Чому завзятість і наполегливість комівояжерів змушує дуже недурних і впливових людей викидати на вітер шалені гроші – тема окремого дослідження.


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


Відразу ж відставимо убік маркетинговий аргумент – «клієнт сам визначить, що потрібно». Дійсно, якщо замовник знає проблему, бачить шляхи вирішення, то відпадає потреба в посереднику, в будь-якому разі гірше представляє собі реалії конкретного бізнесу.


Іноді вибір очевидний. Якщо в серійному виробництві основна проблема – нескінченно зростаючі запаси, треба думати про MRP. Торгової компанії, що визначила пріоритет в розширенні клієнтської бази, слід придивитися до CRM – рішенням. Промислові підприємства, стурбовані безконтрольно збільшуються витратами, можуть зважитися на ERP – проект.


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


Якщо відкинути лушпиння «рекламних ілюзій», «солідних рекомендацій» і «best practice», в сухому залишку виявиться головна мета і завдання впровадження інформаційних систем: « Забезпечити достовірну картину бізнесу, що дає основу для прийняття управлінських рішень ».


А всі інші доводи «вторинні». Великий проект не варто затівати через «понтів» або через «всі так роблять». У всякому разі, серйозний професіонал не повинен потрапляти на таку примітивну наживку …


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


Висновок : Основне завдання проекту – побудова адекватного фінансового управлінського обліку .


Хто такий «генерал Ледгер» і як він себе веде в «реальному житті».

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

Гімн Аеромех-а

– А тепер, Ваше Величносте,
звольте довести наступну теорем …
– Месьє, Ви – дворянин. І я – дворянин.
Дайте мені чесне слово дворянина,
що цей трикутник рівнобедрений …

Досить поширений метод прийняття рішень


Спробуємо розібратися, яким чином можна забезпечити вирішення основного завдання – побудова адекватного обліку.


Якщо задати це питання продавцеві «великого» рішення, відповідь буде приблизно наступний


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


Коротко прокоментуємо «Покриття функціональності основних бізнес – процесів підприємства». Які процеси віднести до основних? Що виходить за «рамки покриття»? Чи повинна система забезпечувати прозорість цих бізнес – процесів?


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


Як ви думаєте, зміна кількісного залишку за місяць повинно відповідати різниці надходження і відпуску цієї позиції? ..


Автор з великим інтересом познайомиться з керівником, який допустить безслідне зникнення товару на складі або поява запасів «з нізвідки». А як дадуть відповідь на це питання ERP – системи?


Пропоную провести наступний експеримент



  1. Як приклад вибирається компанія з працюючою системою ERP і реальними оборотами товару (не менше кілька сот товарних позицій і, відповідно, кілька тисяч прибуткових і витратних складських операцій щомісяця)
  2. Попросіть за місяць на основі даних цієї ERP-системи зробити контрольну вибірку (обов’язкове зазначення товарних позицій і кількості)
    – Кількісні залишки по кожній товарній позиції на початок місяця
    – Кількісні залишки по кожній товарній позиції на кінець місяця
    – Розшифровка надходжень товару по процесах
    закупівля (оприбуткування)
    повернення від покупців
    інше (з обов’язковим зазначенням процесу і посиланням на первинну операцію)
    – Аналогічну розшифровку за видатковими бізнес-процесів.

Тепер перевірте в Excel або Access (автор користується MS SQL Server) відповідність залишків парафіях і видатках. Робіть ставки, пані та панове!


Я зі свого боку готовий поставити проти ста доларів тисячу, що знайду декілька розбіжностей (природно, якщо перед цим не проведена ретельна інвентаризація з «вичищенні сміття»).


Такий експеримент автор проводив років три тому з досить популярною ERP-системою JDE (інформацію можна знайти, наприклад, тут vremya.org/jde.htm ).


Питаннями «звідки з’явилося 100 вінчестерів на складі» або «куди поділося 25 мишок» я довів команду консультантів до істерики. Професіонали, 5 років впроваджують JDE в різних компаніях, протягом 3 місяців шукали відповідь на такі прості питання.


Піднімаю ставки до 20 до 1 – готові сперечатися зі мною впроваджувачі SAP R3 або Oracle Financial? Може, серед консультантів Axapta або Exact знайдуться сперечальники, готові ризикнути сотнею доларів?


Тепер подивимося ситуацію з «інтегрованим рішенням».


«Інтеграція» полягає в зборі інформації з усіх модулів (продажу, закупівлі, склад, виробництво) в головну книгу – GeneralLedger(GL).


Спробуйте поставити питання – чи відповідає інформація GL первинним документам модуля – джерела? Впевнені, що так? А як щодо ручного введення проводок в головну книгу? Корекції сум? Виправлення первинних документів із закупівлі?


Запевняю вас, що відповідний експеримент на реальних даних призведе до дуже цікавих результатів.


Тепер запитаємо консультантів – а чи можна у вашій ERP-системі адекватно відобразити «все наші бізнес-процеси»? Ви впевнені?


Розкажіть, будь ласка, схему автоматичного визначення відповідності повернень від покупця і відвантажень (Якщо не було такої відвантаження, то звідки повернення?). А якщо повернення відповідає трьом відвантаженнях? Що, це відповідність встановлюється «вручну»?


Як відбувається розрахунок ПДВ? Що – в Excel або в бухгалтерській програмі?


Як реалізований бартер (Частковий залік поставок, послуг та інше, інше, інше)?
Що – знову «вручну» або в GL без проведення документів по модулям закупівля і продаж?


Чи можна розрахувати податок на прибуток і відкладені податкові активи і зобов’язання? …


За 20 років роботи з десятками найавторитетніших консультантів та аудиторів, автор жодного разу не зустрічав фахівців, які могли впевнено довести, що хоча б одна з цих проблем може бути ефективно вирішена в «трьохбуквені» системі.


А скільки таких питань «залишилися за кадром». Десятки? Сотні? Тисячі?


Невже всі ці процеси несуттєві?


А уявіть завдання управління холдингом, підприємства якого розкидані по всій країні. Якщо вже в центрі найпростіші та актуальні проблеми не мають задовільного рішення в рамках системи, що ж робити з філією в Томську або Благовєщенську? Переносити всю «головний біль» в регіони, множачи бардак місцевою специфікою, недостатньою кваліфікацією і слабкою керованістю?


Висновок : Системи класу ERP можуть ефективно вирішувати тільки «спеціалізовані завдання». Впровадження повноцінного обліку вимагає інших технологічних інструментів .


І як же вони, все-таки працюють?

Найбільше астронома мучило питання –
Як же вчені дізнаються назви зірок?

Все не так погано, як є насправді
Інакше – хіба було б так добре,
як нам здається?


Звичайно, не можна стверджувати, що ERP – «це погано». Ще раз підкреслимо, що в рішенні задач планування ресурсів підприємства, пов’язаних з безпосередньою виробничою діяльністю, такі системи є єдиним ефективним інструментарієм. Проблема в тому, що для отримання повноцінної фінансової картини бізнесу цього інструментарію недостатньо.


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


Варіант 1 – у нас все в системі, але баланс «в Excel».


За наявною у автора статистикою більше двох третин реально працюючих систем класу ERP не використовуються як інструмент формування балансу.


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


Останній крок – отримати адекватний баланс (General Ledger) натикається на нездоланні перешкоди. Спроба звести (хоча б проконтролювати!) Підсумки звітного періоду призводить до численних «дірок в обліку ».


Звичайно, такі питання вирішуються “менеджерським підходом». Призначається «головний по тарілочках» (найчастіше, керівник фінансової служби – CFO), який всіма правдами і неправдами «затикає ці діри». Якщо головна мета процесу – «здати баланс і забути», то проблему можна вважати вирішеною.


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


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


А далі – все залежить від кваліфікації такого CFO, співробітників інформаційної служби та готовністю «автоматизувати процес загортання риби».


Діапазон застосовуваних рішень досить широкий.


Наведемо найбільш популярні



  1. Звітні форми створюються в таблицях Excel.
    Заповнюються в більшості випадків «вручну». Найбільш «просунуті» імпортують зведені дані з облікових систем (ERP, бухгалтерія), але «ручна доведення» необхідна.
    За неофіційною статистикою такі рішення становлять 60-70%.
    І ця картина неявно визнається аудиторами і консультантами.
    Провідні компанії (в т.ч. з «великої четвірки») постійно проводять семінари на тему «Використання для підготовки фінансової звітності таблиць Excel».
  2. Звітні форми «автоматизуються на колінах».
    Натомившись з десятками, а то й сотнями, Excel-ів, дані яких постійно не сходяться, фінансові служби абияк самі «механизируют процес». Оскільки серед таких фахівців рідко зустрічаються IT-професіонали, діапазон рішень вельми специфічний – найчастіше це слабо пов’язані між собою програми Access (іноді – надбудова над Excel).
    Консультанти та аудитори »рідко сприймають такі рішення серйозно, хоча, в порівнянні з рекомендованим (см попередній варіант), в цьому випадку надійність і достовірність« генерала ледгера »підвищується і (якщо розробкою керував спеціаліст, професійно розбирається в фінансовому обліку) іноді досить істотно.
    Подібного роду рішення зустрічаються приблизно у 20% випадків.
  3. Консолідація в обліковій системі
    Розуміючи необхідність технологічного контролю основних облікових принципів (насамперед – безперервність, цілісність і подвійний запис), приблизно в 5-10% фінансові служби намагаються організувати консолідацію та отримання фінансового балансу в єдиній системі. Зазвичай спроби починаються з модуля GL «рідний ERP». Результати такого підходу найчастіше, більш, ніж скромні.
    Тоді (особливо, якщо CFO звик до «своєї обліковій системі») робляться кроки до впровадження «небудь бухгалтерії», зазвичай російської – 1С, Парус тощо
    Організовується імпорт первинних даних (іноді – зведених, зрідка – по операціях), потім результати «коригуються під чесне слово CFO».
    У чому ж проблема такого підходу? Перш за все, в «закритості рішення».
    Процедури імпорту, написані програмістом, вважаються «чорним ящиком». Ніхто, крім розробника (а дуже скоро і він сам) не може толком зрозуміти взаємозв’язок численних процесів «всередині імпорту». Намучившись рік-два з нікому незрозумілими «соплями і доробками», учасники проекту вважають за краще не «возитися з автоматизацією», а зводити баланс «руками» в тій же 1С. Проблеми знову повторюються …

Варіант 2 – у нас все в системі, «як в Excel».


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


Зазнавши невдачі в «повноцінному впровадженні ERP» (або просто не почавши проект), фінансова служба знаходить наступний вихід



  1. Оперативна звітність формується «зовнішніми засобами» – Найчастіше підсумкові форми заповнюються вручну (іноді робляться спроби механізації – див. вище).
  2. Дані звітних форм вручну вносяться в GL(Як варіант – звітні форми імпортуються в систему).

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


Так що ж порадити?


Спробуємо не «винаходити велосипед», а розібратися в проблемах і «рекомендаціях провідних стоматологів».


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


«Дорожня карта» проекту буде мати приблизно такий вигляд:



  1. Збір вихідної інформації про всі господарські операції.
  2. Первинна класифікація (з обов’язковою зворотним зв’язком!), Виділення основних бізнес – процесів. Обов’язковий розбір всіх первинних даних (!).
  3. Трансформація даних у відповідність до облікової політики та облікової схемою.
    Формалізація бізнес – процесів в термінах плану рахунків і аналітик фінансового обліку. Розрахунок сальдо балансових статей – активів і пасивів.
    Технологічний контроль базових облікових принципів.
  4. Додаткові розрахункові модулі – переоцінка ОС, розрахунок резервів, accruals тощо у відповідність до облікової політики та облікової схемою фінансового обліку. Формування General Ledger (обов’язкова зв’язок з джерелом даних – первинних та розрахункових!).
  5. Формування фінансової звітності – оперативної та підсумкового пакета.

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


Excel або Access? Модуль GL ERP або пакет консолідації з неможливістю розібратися у «нутрощах бізнес – процесів»?


Або, все-таки, найбільш ефективний інструментарій, призначений саме для роботи з даними?


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


Всі дороги ведуть до сховища?

Карфаген має бути зруйнований!

Постійно повторюється «порядок денний».


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


Особливо підкреслимо, що професійно вибудувана «відкрита» технологія дозволяє уникнути «залежно від постачальника», неминучою при впровадженні «великих систем». Адже, адаптувати ERP – рішення доведеться «На колінах». І керувати цими «чорними ящиками» імпорту і трансформації даних не зможе ні співробітник фінансовий служби, ні фахівець IT-відділу компанії, ні аудитор – консультант.


А при «грамотно» реалізованої «дорожній карті» «підхопити процес» може практично будь-який професіонал – інформаційників. Модульна композиція дозволить ефективно розвивати будь-яку частину такого проекту і оперативно модифікувати і навіть міняти первинні системи. Тим, хто сумнівається запропоную порівняти кількість і вартість фахівців настройки модулів SAP R3 і / або володіють інструментарієм РСУБД.


Таке технологічне рішення («грамотна реалізація дорожньої карти») автор і називає «Сховищем даних». Адже, основним результатом подібного проекту є база, що містить інформацію про всю діяльності підприємства, «розкладена по бізнес-процесам» і формалізована у відповідність до облікової політики та облікової схемою.


Природно, таке Сховище не цілком відповідає визначенню DataWarehouse , Введеному в 1992 г Біллом Інмоном (предметно-орієнтований, інтегрований, незрадлива, що підтримує хронологію набір даних, організований для цілей підтримки управління).


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*