Замкнутий цикл виробництва порожніх фантиків

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

Автор частівки не відомий

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

Кожен бізнесмен знайомий особисто чи отримує від колег інформацію про завалені проекти. Але впроваджувати треба – користь очевидна і без глибокого аналізу. Бізнесмен шукає вихід там, де він має бути – і намагається купити перевірене рішення. Цей шлях дає чудовий результат в інших питаннях, але в питанні впровадження ERP лише посилює ризики.

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

Допустимо нам десь вдалося успішно впровадити ERP систему, наприклад у сільгосп компанії. Ми робимо прес-реліз та піднімаємо свій рейтинг. Чи можна розвинути успіх? У процес впровадження систему довелося опрацьовувати під нестандартні завдання. Тепер усі ці доопрацювання можна оголосити галузевим рішенням. У прес-релізі буде написано фразу: «Впроваджено власне галузеве рішення для сільського господарства». Лукавство тут у тому, що жодного рішення на момент започаткування проекту не існувало. Була домовленість щодо впровадження стандартної ERP системи. Ні, воно не було створено впроцесі впровадження. Фактичних його не існує! А як нові корисні функції?

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

Замкнений цикл

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

Обмежений доступ

Для прочитанняповної версіїстатті необхідно зайти якзареєстрований користувач.

Сподобалось 1 людині

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

1. Платимо двічі, та на жаль це напевно 95% впроваджень, а тому що так простіше і йдемо за накатаною схемою, ніж розбиратися як воно насправді працює. До речі, тут так само велика проблема інтегратора, тому що консультанта намагаються завантажити на 120% і відповідно часу навивчення функціональності, дослідження системи, у людини просто немає часу, тому і заштовхують консультанти, що вже десь було перевірено і фіг з ним що криво чи нехай абапер допилить, тому що - ЧАСУ НІ!

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

3. А ось це ось про баги не треба і про відділи тестування великих компаній теж.. як то кажуть, хто не бачив абапівський код стандарту, той нехай постоїть і покурить осторонь, а тому що нервових просимо не дивитися :-).

4. Ну це знову ж таки проблеми з пункту 0 і 1, часу на приведення розробки до осудного виду немає, розробляли дійсно під одного клієнта і т.д. Мені свого часу якось запропонували взяти участь у реалізації одного пакетного галузевого рішення після впровадження на одному із проектів. Відмовився, пояснивши, що галузеве рішення, можу почати робити, після впровадження цієї функціональності ну як мінімум після 3-4 клієнтів, тоді в мене буде досвід та уявлення, а один клієнт це ніяке не галузеве, а приватні докрутки.

Поки що нікому не сподобалося

Сподобалось 2 людям

2. Не можу не погодитися з Олегом Точенюком, що 99% впроваджень виконується в умовах жорстких, а іноді й найжорстокіших обмежень щодо часу та ресурсів. А як відомо "дешево", "добре" та "швидко" не буває. Тож не треба дивуватися очевидним речам.

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