Відомо, що маркетингові заяви вендорів часом серйозно розходяться із реальністю. Проте прийнято вважати, що авторитетні гравці ринку до подібної практики не вдаються. Проте, керівник проекту впровадження SAP Business One у невеликий російської компаніїна особистому досвіді переконався, що «ніщо людське не чуже» та респектабельним компаніям.

Грані виживання

Кілька років тому практично всі світові розробники ERP-систем розпочали рух у бік сегменту СМБ, який був оголошений чи не найперспективнішим та найпріоритетнішим. На ринок були представлені нові продукти, орієнтовані невеликі компанії, з невеликими бюджетами на ІТ. Не став винятком і російський ринок бізнес-додатків. У вітчизняній пресі з'явилися переконливі статті, що інформують російських бізнесменів про те, що в умовах жорсткої конкуренції (у тому числі при вступі до СОТ) вони не зможуть вижити, якщо у них не буде сучасної, автоматизованої системи управлінського обліку, планування та контролю. Наведені аргументи були цілком переконливі. В результаті керівництво багатьох середніх і малих підприємств Росії всерйоз задумалося про перехід на щось краще, ніж Excel і 1С. Наша компанія також належить до сегменту СМБ і через зазначені вище фактори, прийняла пропозицію одного з партнерів корпорації SAP на впровадження тоді нового для ринку продукту - SAP Business One (B1).

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

Ось – новий поворот

Компанія SAP не стала винятком у світових перегонах за підприємствами СМБ і кілька років тому заявила про «серйозні зміни в продуктовому портфелі компанії» та рішення здійснити «тотальний розворот у бік ринку СМБ» та включити у свою продуктову лінійкурішення, орієнтоване на невеликі компанії, що розвиваються. Більше того, було оголошено, що ринок рішень для СМБ є одним із пріоритетних для компанії SAP. Керуючий директор SAP СНД Олексій Шликовтоді прокоментував цей крок так: SAP вчасно розпізнала момент, коли ринок великого бізнесу, На які, перш за все, були орієнтовані бізнес-додатки компанії, виявився близьким до насичення, і настав час шукати наступні ринки збуту».

В результаті в 2003 році на російський ринок була виведена локалізована версія SAP Business One - рішення, що принципово відрізняється від того, чим займалася SAP раніше. Втім, SAP Business One не є розробкою німецької компанії: продукт придбано в ізраїльських розробників. Цікаво, що вихід SAP Business One не супроводжувався масштабними рекламними кампаніями- всі зусилля з просування вилилися в кілька інформаційних статей у пресі та серію регіональних семінарів, які потенційних клієнтіворганізовували партнери SAP. Також було офіційно оголошено, що вартість одного робочого місця «під ключ» (ліцензії плюс консалтинг із впровадження) становитиме €2500–€3000, а тривалість впровадження не перевищуватиме 8 тижнів. Крім того, було відомо, що продукт має одну істотну перевагу в порівнянні з альтернативними пропозиціями – він налаштовується, його не треба програмувати, на відміну від рішень «1С», і він уже містить готові бізнес-процеси.

Фактично, при прямому продажу нашої компанії було заявлено наступне: «За 2 місяці ми впровадимо продукт, і у вас почне працювати повноцінна система управлінського обліку». У тому, що маркетингова інформаціяпро продукт відповідає його реальної суті, ми переконалися вже своєму досвіді пізніше. Поки що все звучало дуже переконливо. Нас також вразили демо-ролики рішення презентовані партнером SAP (шановна, давно існуюча компанія в нашому регіоні). Крім того, був висловлений найвагоміший аргумент – «ви під крилом надійного бренду SAP». І це розвіяло всі наші сумніви.

Сувора реальність

Після трьох місяців впровадження стало зрозуміло, що функціональність SAP Business One відверто недостатня для ведення навіть невеликого (70 співробітників) бізнесу. російських умовах. Чому ми цього не зрозуміли раніше? Тяжке питання.

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

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

Необхідно також відзначити кілька серйозних недоліків SAP Business One, які на перших презентаціях неочевидні, а спливають тільки в процесі:

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

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

Перелічені «недоопрацювання» взагалі унеможливлюють надання коректної інформації про діяльність компанії. При цьому не зовсім зрозуміло, як у такому разі можна позиціонувати SAP Business One як систему управлінського обліку. Роздріб, гуртова торгівлята інший бізнес, що швидко розвивається, з цією системою працювати не зможе через обмеження її продуктивності. Збереження документа з 40-50 позиціями наводить систему в ступор. Якщо таких документів буде хоча б 200-300 на день, то просто перестає працювати.

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

З розмови з компанією-внедренцем ми дізналися, що SAP, взагалі кажучи, змушує партнерів самостійно доопрацьовувати функціонал і писати звані add-ons (додаткові компоненти). Ці компоненти можна отримати у готовому вигляді на комерційній основі в інших партнерів, які вже реалізували цю функціональність. Наприклад, для обліку операцій з основними засобами потрібно купити відповідний add-on, те саме, якщо ми хочемо вести облік фактичних та планових витрат, інший окремий модуль призначений для стикування рішення із системою банк-клієнт. Крім того, що вартість проекту збільшується, є ще одна сторона: якщо ми купуємо add-on в іншої компанії, то нам треба або залучати їх до впровадження за, знову ж таки, додаткові гроші, або наш партнер-впровадженик розбиратиметься з цим самостійно. , Але теж не безкоштовно. Фактично, виходить своєрідна «піраміда», яка розростається тим сильніше, що ширша функціональність потрібна підприємству.

Продати та забути?

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

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

В результаті, у нас склалася думка, що « технічна підтримка» відображає загальний підхід вендора до бізнесу із підприємствами СМБ. Компанія SAP в Росії орієнтована саме на великих клієнтів, тому що вони мають можливість інвестувати у проект невизначену кількість часу та коштів. А ось СМБ нескінченно чекати не може і «годувати» консультантів SAP весь цей час – також. Понад те, судячи з «оперативності» і «змістовності» відповіді наші запити, склалося враження, що SAP зацікавлена ​​лише у продажу ліцензій, саме по товару нічого не робиться. Примітним є той факт, як часто змінюються в SAP люди, відповідальні за клієнтів по SAP Business One. Частина з них після старту проекту SAP для СМБ дуже швидко переключилася з вирішення питань просування SAP Business One на створення власної кар'єри всередині SAP, інша частина перейшла в інші компанії.

Арифметика маркетингу

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

З початку запуску продукту SAP Business One на російський ринок було заявлено, що це рішення для середнього та малого бізнесу. Чи це так насправді? Самою компанією SAP у ЗМІ було заявлено вартість 1 робочого місця «під ключ» (тобто ліцензія + впровадження) – близько €2,5-€3 тис. Крім того, було оголошено (як перевага продукту), що ціна – кінцева.

Для того, щоб дійсно автоматизувати ключові бізнес-процеси в невеликій компанії, скажімо зі штатом 100-200 осіб (фінанси, продажі, склад, закупівлі), необхідно придбати близько 10-15 АРМ. Тобто, треба розраховувати на суму порядку €30-€45 тис. Як показує практика, власники російських невеликих компаній, які заробляють кожну свою копійку «потім і кров'ю», не так просто виплатять 30 тисяч євро/доларів за «софт». Тим більше, що податковий облік та бухгалтерію в системі вести неможливо і, як мінімум, «1С: Бухгалтерія» все одно буде потрібна. Більше того, якщо придивитися до вже оголошених впроваджень, то видно, що повноцінні проекти – рідкісний виняток і мова, як правило, йдеться про 3-5 ліцензій. Висновки напрошуються самі по собі.

Таким чином, на наш досвід, SAP Business One може працювати за умови існування не більше 10 користувачів, у компанії, де немає повноцінного складу продукції, при цьому може оброблятися реально не більше 2-3 замовлень продукції на день. Виникає питання: «А чи потрібна така система невеликої компанії, що розвивається, по дві з лишком тисячі євро за робоче місце? Навіщо, якщо на такому рівні досить використати просто Excel?».

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

Якщо ж конкретно про російську реальність, то, може, причина в тому, що останні 10 років SAP тут існував дуже комфортних умовах? Досить згадати навіть офіційні суми інвестицій у ІТ наших промислових монстрів. І коли справа дійшла до реальних дій, нормального розвитку та просування конкретного продукту, можливо, тут знадобилися навички та компетенція, які не були потрібні раніше? І проекти стали більш прозорими і тепер уже не так просто замовчати проблеми, як у масштабних впровадженнях, де занадто багато задіяно інтересів, щоб надати непривабливі результати розголосу.

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

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

Владлен Татарський

Використання SAP з нуля

Впровадження нових або вдосконалення діючих інформаційних систем управління на базі програмних продуктівкомпанії SAP SE виконуються компанією СКАЙРАЙЗ у формі проектів із перевірених методологій ASAP, ASAP Focus, PMBOK.

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

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

Системно організований проект проходить такі стадії:

• Ініціювання проекту
• Концептуальне проектування (розробка проектних рішень)
• Технічна реалізація проектних рішень
• Тестування
• Навчання користувачів
• Підготовка у запуску ОПЕ
• Запуск системи у продуктивну експлуатацію та її супровід

Компанія СКАЙРАЙЗ бере на себе управління змістом робіт, графіками та термінами, ресурсами та якістю результатів проекту. При цьому Керівна рада та учасники проектної групи з боку Замовника завжди мають можливість контролювати та бути залученими до вирішення проекту.

Велике значення компанія СКАЙРАЙЗ надає наявному галузевому досвіду створення інформаційних систем та моделям найкращих галузевих практик (SAP Best Practices) (див. також галузеві рішення).

У яких випадках потрібне впровадження SAP з нуля

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

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

Рол аут SAP корпоративного шаблону

З розроблених потреб у автоматизації на її прискорення можна використовувати вже опрацьоване рішення – Шаблон (Template).

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

Також можливе використання галузевого шаблону із набору галузевих рішень (SAP Best Practices).

Розширення функціональності SAP продуктивної системи

Розширення функціональності продуктивної системи

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

1. Усі зміни повинні проводитися на підставі вивіреної методології
2. Усі зміни мають бути заплановані
3. Завжди має бути план скасування змін
4. Функціонал повинен бути перевірений як за розширеним функціональним обсягом ключових бізнес-процесів,
   так і за розширеним організаційним обсягом

Розширення функціональності зазвичай проводиться з допомогою методології застосування ASAP.

Розробка користувальницької функціональності

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

1. Інструменти сканування штрих-кодів за допомогою мобільних пристроїв- посилання
2. Система управління комерційним обладнанням
   посилання
3. Система управління забезпеченням засобами індивідуального захисту- посилання

Перехід на SAP HANA

Перехід на SAP HANA (High-Performance Analytic Appliance) здійснюється відповідно до методології SAP Activate.
1. Спочатку описується весь перелік використовуваних бізнес процесів
2. Описується весь перелік довідників, що використовуються.
3. Описується весь список використовуваних інтерфейсів
4. На придбане обладнання (у разі On Premise версії) встановлюється програмне забезпечення SAP HANA.
5. Виробляються доопрацювання функціоналу
6. Здійснюється міграція довідників та історичних даних із старої системи в нову за допомогою спеціальних інструментів
7. Проводиться тестування роботи функціоналу у новій системі.
8. Проводиться активація інтерфейсів
9. Здійснюється перехід на нову платформу

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

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

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

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

Результати впровадження SAP

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

До основних переваг, досяганих за допомогою впровадження SAP, можна віднести:

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

Основні етапи впровадження SAP

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

Основними етапами впровадження SAP є:

• Підготовка проекту (Готується статут проекту, план проекту, регламенти. Проводиться обстеження та розробляється архітектура рішення)
• Розробка концептуального бізнес-проекту (Опис «to be» у термінології SAP. Оргструктури; основних даних; бізнес-процесів; вихідних форм; звітів; доопрацювань. Підготовка сценаріїв для функціонального тестування)
• Налаштування прототипу та ФТ (Налаштування прототипу системи та тестування згідно з підготовленими сценаріями. Підготовка основних даних замовником (довідники). Підготовка сценарію інтеграційного тестування)
• Донастройка системи та ІТ (Інтеграційне тестування) (Донабудова системи за результатами функціонального тестування. Проведення інтеграційного тестування. Доробка основних даних. Необхідні розробки протягом проекту, що займають зазвичай, не більше 10-15% від загального обсягу робіт)
• Підготовка системи до продуктивного старту (Розгортання робочих місць. Навчання кінцевих користувачів. Завантаження основних та змінних даних.)
• Продуктивний старт та підтримка продуктивного старту (Дозавантаження основних та змінних даних. Оперативний супровід кінцевих користувачів. Закриття перших періодів)

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

Навіщо проект розділений на фази, і яким принципом, зазвичай, керуються при дробленні проекту по фазам?

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

Створення проектного офісу

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

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

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

Обстеження

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

Найкращою практикою вважається підготовка опису бізнес-процесів у вигляді діаграм у якомусь CASE-продукті. Таку схему називають "Схема бізнес-процесів "Як є (AS-IS)". Але, на жаль, через дорожнечу програмних продуктів, а також низьку затребуваність з боку замовника, ця технологія дуже рідко використовується на проектах. А шкода, адже її використання дозволяє проводити різні аналітичні висновки про стан бізнес-процесів, оптимізувати і, найголовніше, надалі при концептуальному проектуванні та побудові моделі «Як має бути» (TO-BE) дозволяє проводити порівняльний аналіз, тобто . дозволяє прогнозувати вигоди від застосування ERP-системи. Результатом даної фази також є уточнене технічне завдання.

Концептуальне проектування (модель TO-BE)

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

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

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

Реалізація

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

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

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

Початкова підтримка

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

Доброго дня, колеги, читачі, друзі!

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

Вступ

Не стверджуватиму однозначно, але думаю, що практично кожен консультант/прожект менеджер/менеджер зі змін, що має достатній досвід впроваджень ERPсистеми (тут може йтися не обов'язково про систему SAP), знайде в цій статті те, з чим він реально стикався, і погодиться (можливо, частково) з моїми міркуваннями. Все що я описуватиму – це мій особистий проектний досвід. І представлена ​​мною нижче класифікація, не більш як умовність. Хтось може бачити і класифікувати це інакше. Готовий до дискусії у коментарях до статті.

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

Знайомо? І з погляду непосвяченого, цілком закономірне питання. Можливо, колеги чули ті самі питання, але дещо в іншому контексті, але впевнений, що вони були. І ми переходимо до першої помилки.

Помилка №1: Система працює за Вас або «синдром червоної кнопки»

Отже, ми впроваджуємо велику і дорогу ERP систему у Замовника (давайте для простоти вважатимемо, що йдеться про впровадження системи SAP, хоча, як я писав вище, мої аргументи стосуються інших великих ERP-систем). Більшість співробітників компанії, навіть якщо вони не беруть безпосередньої участі у впровадженні, щось десь чули. Чули про вартість ліцензії (що вони є позамежними), про вартість впровадження, про зарплати консультантів тощо. Співробітники компанії Замовника, які працюють на впровадженні безпосередньо з консультантами, також часто до останнього не розуміють, як це буде працювати після продуктивного старту. Але вони також мають уявлення про вартість застосування. Всі ці люди мають повне право припускати, що використання системи дозволить багато ручні/рутинні операції виконувати автоматично, тобто. система працюватиме за вас.

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

Був у моєму досвіді такий випадок. Коли після здобуття практичного досвіду роботи в системі вже після продуктивного старту, у компанії сформувалася «опозиційна коаліція». Ця група людей спеціально накопичувала весь негатив, всі проколи консультантів, всі обмеження функціоналу системи (а як ви розумієте, «функціональними обмеженнями» системи SAP, порівняно, наприклад, з 1С, може бути неможливість видалення багатьох даних, неможливість «підчистки хвостів») . Ну так ось, настала година «Х», коли весь цей цят бруду вилився на команду впровадження, а також був наданий власнику бізнесу, як основний аргумент на користь повернення до старої облікової системи. У результаті все закінчилося добре. І через якийсь час люди, які були найзапеклішими противниками нової системи, зрозуміли, в чому її переваги змінили свою думку. АЛЕ, якби менеджер проекту (з того чи іншого боку) вчасно розпізнав би проблему та провів необхідні роз'яснення, таких протестів та скандалів можна було б уникнути.

Я згадав про "синдром червоної кнопки". Це свого роду байка серед колег консультантів. Суть у тому ж. Кожен користувач в тій чи іншій мірі хоче, щоб кількість рутинних операцій, що виконуються ним день у день, якимось фантастичним чином виконувалося в системі автоматично. Тобто. Користувач входить до системи, а інтерфейс системи складається з однієї великої червоної кнопки. Користувач натискає кнопку і система сама виконує всі необхідні операції. А користувач тим часом чай п'є. Консультантський фольклор трансформував червону кнопку на червону педальку. Навіщо педаль? Тому, що тоді жати можна ногою, і обидві руки вільні. Однією – чай п'єш, інший – пасьянс розкладаєш. J Це все, звичайно, жарти, але дуже багато користувачів не втомлюються дивуватися, як система, впроваджена за такі гроші, не може «трохи подумати за людину».

Помилка №2: Впровадження системи дозволить «розвантажити» кінцевих користувачів

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

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

Хочу описати ще один приклад із мого досвіду. Я не знаю, конкретно до якої помилки його віднести, до №1 чи №2. Він (приклад) тією чи іншою мірою стосується обох.

Для великої компанії однією з провідних світових консалтингових фірм було написано методику роздільного обліку витрат. Вимоги до методики висувалися дуже жорсткі. Пророблення положень методики та високий рівень деталізації підсумкових результатів розподілу витрат для компанії Замовника була дуже важливою. Другим етапом процесу розробки методики була її автоматизація, яка провадилася засобами системи SAP BW. Методика була автоматизована, користувачі навчені, виконано перевірку якості роботи з боку фірми-розробника методики. Замовник був повністю задоволений результатами роботи. Однак, для роботи методики в SAP BW, потрібен був досить великий обсяг вихідної інформації (як я вже писав, замовник приділяв велика увагадеталізації розподілу витрат). Частина даних підвантажувалася із SAP ERP. Частина даних із прикладних систем. Частина заводилася вручну в MS Excel та за допомогою спеціальних форматівпідвантажувалась у BW. Для цієї роботи навіть було виділено спеціальних людей. Начебто все було добре. Однак, через деякий час компанію Замовника стали залишати співробітники, які були головними ідеологами використання розробленої методики, брали участь у її розробці та прийманні. Це були люди, які, окрім іншого, розуміли важливість підготовки необхідного обсягу. первинної інформаціїдля одержання коректних результатів фінального розподілу. Далі, через ще якийсь час, від Замовника було отримано вимоги про спрощення ступеня деталізації розрахунків. Основна причина – надто великий обсяг вихідних даних, які необхідно готувати. Спрощення було зроблено в кілька ітерацій (знову ж таки в міру надходження вимог від Замовника). І в результаті, від детальної аналітичної моделі залишився «обрубок», який показував якісь узагальнені дані. Про колишній рівень деталізації говорити вже не доводилося.

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

До речі, на початку статті я згадав ситуацію, коли Замовник вимагає надати із системи якусь модель (план, прогноз), що базується на наявних даних. Теж дуже поширена помилка. Але я не окремо виділятиму його. Це також стосується помилок №1 та 2 (або десь між ними). Суть у тому, що керівництво компанії Замовника або власник бізнесу не зовсім розуміє різницю між алгоритмом та вихідними даними. Будь-яка модель, прогноз, методика складаються з:

А. Якогось алгоритму, вираженого у чітких та зрозумілих математичних/статистичних формулах;

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

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

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

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

Помилка №3: ​​Систему завжди можна «прогнути» під бізнес

• не пам'ятаю, де я це бачив (десь на просторах інтернету), але фразу я запам'ятав дуже добре: "…Ти є будь-який, щоб зробити це і консультант повинен перевірити його на SAP", - is start of a big problem.

«…Це завжди працювало в такий спосіб, і завдання консультанта продублювати процес у системі SAP», - це початок великої проблеми.

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