Відкриті Системи - 8 липня 2013

Впровадження систем класу ERP стало звичайною практикою для російських підприємств. Уже накопичена велика статистика впроваджень, яка дозволяє підсумувати проектний досвід і виділити тенденції. Про переваги клієнтів, замовних розробках і типових рішеннях розповідає Аркадій Бархан, керівник підрозділу SAP ERP Delivery компанії EPAM Systems.

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

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

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

Виходить, замовники менш схильні до побудови унікальних замовних рішень, а вважають за краще «збирати» системи з більш-менш готових блоків?

Як мінімум, пропоноване замовнику рішення повинно мати зрозумілу основу, яку можна поступово допрацьовувати. І слід відразу ж чітко визначити місце цього рішення в тому самому перспективному плані, на який орієнтується підприємство. Сьогодні вже не можна прийти до замовника з пропозицією розробити будь-який необхідний йому функціонал. Коли замовник вибирає продукт і партнера по впровадженню, він чекає не обіцянок, а чогось більш відчутного -хочет подивитися готовий прототип, вивчити реальні приклади впровадження. І для кожного реалізованого проекту необхідно визначити межі - функціонал, терміни, бюджет, і запропонувати зрозумілі критерії оцінки успішності. До того ж рішення має спиратися на потужну технологічну платформу, таку як SAP ERP, наприклад. Саме тому ми звернулися до відносно нової сфері застосування SAP - Rapid Deployment Solutions (RDS), або швидко розгортаються рішення.

Що таке RDS, у чому їх переваги і обмеження?

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

Подібні рішення і раніше пропонувалися компанією SAP та її партнерами, але остаточно це напрям оформився близько двох років тому, тоді і з'явився термін SAP RDS. Мета RDS- мінімізувати ризики впровадження, запропонувавши замовнику рішення з фіксованими і зрозумілими можливостями, певним бюджетом і термінами. Фактично, в кожному SAP RDS укладена певна частина функціоналу SAP ERP. Раніше цей пакет купувався цілком і включав в себе весь спектр можливостей по автоматизації управління підприємством. У ньому можна було виділити окремі сценарії і кращі практики, які замовник хотів би використовувати, але до впровадження пропонувалася вся «коробка» цілком. З появою SAP RDS ця велика «коробка» може бути розділена на більш дрібні, і замовник сам вибирає, що саме він буде впроваджувати. Проекти виходять менш складними і трудомісткими.

Коли замовникам слід робити вибір на користь RDS? У чому особливості реалізації таких проектів?

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

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

RDS можуть мати і функціональну, і галузеву спрямованість. Наприклад, в цьому році EPAM Systems сертифікувала RDS для автоматизації бюджетування в рітейл-компаніях, побудоване на платформі SAP BPC. Нещодавно ми розробили RDS-рішення для управління дискретним виробництвом.

Що потрібно для створення такого RDS і що це рішення вам дає?

Потрібні знання, причому не тільки продуктів і технологій, але і предметної області. У EPAM Systems досить серйозна експертиза в сфері автоматизації управління виробництвом: за останній час ми виконали п'ять великих і складних проектів в Росії і Білорусі. Найзначніший з них - проект на «Гомсільмаш» (Гомельський завод сільськогосподарських машин), де система запущена в продуктивну експлуатацію в січні 2012 року і де сьогодні з нею працюють близько 1000 користувачів.

Проектний досвід показав, що в рішеннях SAP недостатньо опрацьовані деякі моменти, обумовлені російською специфікою бізнесу (наприклад, складська логістика - міжскладських операції, переміщення товарів). Тому при створенні RDS ми беремо за основу рішення SAP і розширюємо частина процесів. Наприклад, наше RDS для дискретного виробництва покриває управління продажами, виробництвом, матеріально-технічними потоками (в тому числі закупівлі), а також ведення бухгалтерського обліку та контролінгу. Тим самим забезпечується підтримка наскрізного планування збуту, МТО і виробництва, автоматизуються всі основні завдання в сфері управління виробництвом. Для цього в рішенні реалізовано близько 60 сценаріїв бізнес-процесів. Більшість з них - це стандартний функціонал SAP. Але частина сценаріїв розроблені EPAM (знову-таки на базі SAP) з урахуванням вітчизняної специфіки і нашого досвіду роботи з виробничими підприємствами. Це, наприклад, операції із закупівель з авансовими платежами, розподілу відхилень у вартості напівфабрикатів і готової продукції. Все допрацьовані RDS ми кваліфікуємо в SAP, що є гарантією їх якості та подальшої підтримки.

Для EPAM Systems розробка RDS дозволяє з більшою ефективністю працювати в сегменті виробничих підприємств середнього масштабу. Як правило, у таких замовників обмежені бюджети на ІТ, вони менш схильні до проектних ризиків і очікують швидких і передбачуваних результатів. Наявність Переднастроєні рішення дозволяє задовольнити цей попит. RDS «вбирає» наше розуміння того, як краще перекласти технології SAP на потреби бізнесу і представити можливості продуктів так, щоб замовники могли їх сприйняти, оцінити, вибрати, впровадити і потім успішно використовувати.

Але сильною стороною Ерамов Systems завжди були саме замовні розробки. Чи означає це, що настала пора переорієнтувати бізнес і переходити до створення якщо не коробкових продуктів, то більше оформлених, завершених рішень?

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

Чи існують які-небудь обмеження щодо застосування RDS?

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

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

Чи є у Ерамов Systems плани по розробці інших RDS?

У компанії ведеться внутрішній проект SAP Innovation Lab, в рамках якого ми інвестуємо в розробку перспективних рішень і технологій, в тому числі RDS. Зараз, наприклад, ми готуємо RDS для банків для управління платежами і фінансовими потоками. Ведеться розширення функціоналу RDS для управління дискретним виробництвом. Реалізуються перші проекти по впровадженню RDS для бюджетування в рітейлових компаніях - за їх результатами, можливо, буде доопрацьовуватися і це рішення.

Яке ваше ставлення до останніх технологічних інновацій, таким як SAP HANA, мобільність, Visual Enterprise і інші популярні тенденції. Чи знаходять вони відображення в RDS?

У пропонованих SAP прототипах, які ми беремо за основу при створенні власних RDS, присутні ці нові технології. У EPAM Systems є досвід роботи з SAP HANA. Спільно з вендором ми беремо участь в тестуванні і розробці рішень, що базуються на цій платформі, зараз ведемо два проекти з впровадження SAP HANA у західних замовників, є навіть тестовий проект в Білорусі з побудови звітності за допомогою SAP HANA. Як тільки ми побачимо, що російські компанії готові сприйняти ці рішення, відразу ж почнемо активно пропонувати їх. Можна навіть сказати, ми бачимо нашу місію в тому, щоб нести ці технології «в народ». При розвитку RDS з управління виробництвом ми додаємо в ряд процесів сценарії для використання мобільних пристроїв. Нам здається, що їх застосування дозволить надати додатковий ефект «класичним» процесам виробничих компаній, які зможуть отримати нові вигоди з точки зору бізнесу.

Коли ж відбудеться їх проникнення на російський ринок?

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

оригінал публікації