Розвиток ERP-системи

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


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


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


Специфіка сприйняття


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


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


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


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


Віддача на інвестиції


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


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


Особливості проектування


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


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


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


Погляд користувача: як руйнуються відносини. Коротка хронологія


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


Керівництво замовника пропонує користувачам взяти участь в автоматизації своїх процесів: опрацювати спільно з консультантами свої вимоги до системи.


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


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


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


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


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


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


Погляд з боку: три ключові проблеми


Проблеми, які можуть призвести до описаного вище розвитку подій, наступні:


1. Функціональні вимоги формулюють користувачі


2. Функціональні вимоги до модифікації підміняються описом модифікації


3. Керівництво замовника відмовляється від скрупульозної оцінки економічного ефекту від кожної модифікації.


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


Які причини і наслідки перерахованих проблем?


Помилка перша, вона ж основна: вимоги формулюються користувачем


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


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


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


Обгрунтування помилковості даного рішення можна сформулювати наступним чином.


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


Виникає в результаті такого підходу надмірність вимог до модифікації можна продемонструвати таким чином. Припустимо, що при описі варіативності реалізацій деякого автоматизується бізнес-процесу працює спрощене правило Парето 20/80 1 (Використовуємо правило Парето просто як приклад закономірності, яку прийнято застосовувати для опису практично будь-яких нескладних економічних закономірностей). У цьому випадку 20% варіантів реалізації (приватних випадків) бізнес-процесу становлять 80% всіх випадків реалізації. 36% варіантів реалізації – 96% всіх випадків. 49% варіантів реалізації – 99% всіх випадків.


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


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


Користувач же, як показує практика, в більшості випадків впевнений, що автоматизація 50% приватних випадків – нісенітно малий результат. Той факт, що ці 50% закривають 99% всіх реалізацій процесу, його навряд чи вразить: адже він бачить, що залишилися 50% приватних випадків, як би рідко вони не траплялися, доведеться розв'язувати "руками". Тому користувач готовий довго і вдумливо опрацьовувати окремі випадки, нескінченно розширюючи вимоги до системи.


Помилка друга, обтяжуючих: погоджуємо "як" замість "навіщо"


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


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


Винятки


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


Описані проблеми не відносяться до "користувачам-виключень".


Якщо дві помилки допущені: як шукати вихід


Якщо компанія-виконавець допустила такий розвиток подій, у неї є, за великим рахунком, два виходи.


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


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


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


Помилка третя, контрольна: замовник платить не дивлячись


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


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


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


Всі помилки допущені. Що робити


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


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


Після того, як проблеми позначені, необхідно прийняти два принципових рішення.


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


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


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


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


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


При аналізі поточного процесу ми з'ясовуємо наступне: згідно з діючими правилами приблизно 80% рахунків на оплату повинні комплектуватися після того, як надходить 100% передоплата за цими рахунками. У 16% випадків – Досить оплати 70% (VIP-клієнти). У 3% випадків рахунку йдуть на комплектацію після одержання гарантійного листа (клієнти з бездоганною репутацією).


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


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

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


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

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

Ваш отзыв

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

*

*