Ідеальне впровадження ERP або керований вибух
У цій статті я хотів би поділитись своїм досвідом роботи впровадження ERP-систем на великих проектах. Стаття була написана в 2013 році в момент впровадження великого проекту на 1С, так би мовити за гарячими слідами.
Вступ: два види клієнтів
Зазвичай використання нової програми буває у випадках: 1. Коли компанія ще не вела облік у спеціальній програмі, а працювали лише в Екселі 2. Коли вела облік у старих програмах, з яких уже зросла — база стала гальмувати, неможливо розвинути функціональність, нестабільну роботу та інше.
У першому випадкукомпанії мають невеликий штат співробітників та обсяг впровадження невеликий. Компанія лише переступила через критичну точку обсягу інформації, коли потрібна якась система обліку. Ручний режим в Екселі більше не влаштовує посібник.
Плюси таких клієнтів — не треба думати про старий функціон системи та перевантаження довідників і залишків, бо її просто немає. Досить простий сам запуск - після створення програми (конфігурації 1С), можна просто почати всім користувачам працювати - у разі будь-яких проблем у програмі у вигляді відсутності передбаченої функціональності робота компанії не зупиняється, т.к. користувачі завжди можуть продовжити працювати по-старому - вручну або в Екселі, поки програмісти допилюють програму 1С.
Мінуси: потрібне навчання користувачів роботі в 1С, завантаження даних з Екселю. Наприклад був у мене клієнт, у якого користувачі були розпещені різноманітністю друкованих форм в Екселі (практично для кожного замовника своя, причому різна для різних його філій), тому вони вимагали зробити таку ж підтримку в 1С. Необхідний великий адміністративний ресурс для того, щоб уніфікувати форми, а також зрушитивикористання з мертвої точки: користувачі почали навчатися, користувачі почали виконувати нову незвичну для них роботу, наприклад, підтримку довідників контрагентів та номенклатури в актуальному стані.
У другому випадкуце перехід зі старих систем, наприклад, програми 1С 7-ї версії або інші застарілі програми, які не відповідають сучасним вимогам, наприклад, у мене був клієнт із програмою RS-Balance 3.16, яка моторошно гальмувала.
Зазвичай це клієнти з великою кількістю робочих місць — понад 100, у них уже ведеться облік на старій системі, тому спочатку потрібно перенести старі бізнес-процеси на нові рейки (на нову платформу 1С 8), так щоб діяльність компанії ні на хвилину не зупинилася. а вже потім доопрацьовувати бізнес-процеси. Є два способи виконати початковий запуск: методом великого вибуху – коли вся компанія переходить на нову програму та методом вбудовування окремих робочих місць – переклад виконується окремим користувачам, при цьому між системами виконується двостороння синхронізація даних. Дані введені в одній системі відразу потрапляють в іншу систему, в результаті пів-фірми може працювати в одній програмі, а частина іншої, що залишилася. Цей спосіб впровадження найзручніший і безпечніший з погляду збереження діяльності компанії, але він найтехнічніший складний для виконавця. Але виявилося можливим для переходу з таких програм як 1С 7.7 та RS-Balance.
Ідеальне впровадження
Це таке впровадження, коли керівництво дізнається про закінчення впровадження після того, як йому приносять на підпис акт про виконані роботи. Тобто. повна відсутність тертя між виконавцем та співробітниками замовника.
Співробітники замовника працюють з 9 до 18, вони працюю у звичному своєму руслі завдань: вони не хочуть напружуватимізки - виконувати нову роботу або навчатися, вони не хочуть мати проблеми з начальством, якщо збоїть програма і через це не можуть виконати свої обов'язки, наприклад, через недоробки програми товар не відвантажується зі складу. Ідеальний випадок - це повторення старого інтерфейсу програми (тоді співробітнику не доведеться навчатися новому) і створення двосторонньої синхронізації даних (у разі збою в новій програмі користувачі не зупиняючись, продовжують працювати в старій програмі)
У цій статті я всіляко агітуватиму за використання двосторонньої синхронізації даних, т.к. це дозволяє уникнути безлічі помилок та забезпечити швидке впровадження нової програми з малою кров'ю.
Один із аргументів — це за такого підходу автоматична реалізація принципу “нічого не забути”, річ у тому, що у момент створення обробок перенесення даних виконується скрупульозне вивчення структури даних старої програми. Вивчається реквізит за реквізитом, таблиця за таблицею. Вже на етапі розробки запитують користувачів старої програми про значення тих чи інших даних. Причому питання задаються про всі 100% даних старої програми, тому ймовірність пропуску чогось важливого вкрай мала, але навіть якщо таке станеться ми завжди можемо тимчасово перевести блоки з нової програми в стару шляхом натискання однієї кнопки.
Керований вибух
Як це робиться
Створюється механізм реєстрації змін об'єктів (наприклад: для 1С 8 підійде вбудований механізм реєстрації або можна використовувати механізм підписки на події, для 1С 7 версії використовується зовнішня компонента Мігратор 1С, для RS-Balance використовуються макроси, що перевизначають стандартні методи запису довідників і документів “Update” та "UpdateDoc").
У 1С 8створюється обробка, що вміє вивантажувати і завантажувати змінені об'єкти між програмами. Крім іншого, вона повинна мати спеціальний монітор коректності перенесення даних. Проблеми перенесення даних повинні відображатися в спеціальній таблиці, де помилки пов'язані з тільки невдалими транзакціями повинні автоматично оброблятися при наступних сеансах обміну, а помилки, що вимагає втручання програміста (наприклад, неправильні сценарії переливу даних) - виправлятися вручну програмістом (спочатку правиться код обробки обміну, ініціюється обмін).
Створюється механізм прав для користувачів, який визначає, в якій програмі вони можуть працювати. Далі встановленням прав визначається робота кожного користувача в тій чи іншій програмі.
Що ми довідалися
Виявляється, що основна продуктивна робота ведеться тоді, коли програма починає впроваджуватись і їй починають користуватися люди. У цей момент з'являється така кількість завдань, які не в змозі швидко виконати команда впроваджувачів. Виявляється, що на етапі обстеження не було враховано мільйон речей, про які одні не знали, а інші не згадували. Наприклад, потрібно було зробити ще один документ обліку шлюбу, передбачити окремий документообіг, зробити звіти, статуси та інше, інше… Тому, щоб врахувати всі фактори — всі бізнес-процеси, потрібно створювати регульований процес впровадження по одному робочому місцю за раз, створювати локальний вибух мозку в рамках одного робочого місця, у рамках роботи з однією людиною. Впровадивши програму на одному робочому місці, переходити до іншого.
Замість епілогу: парадокс впровадження керованим вибухом
Великі компанії (від 100 автоматизованих робочих місць) переходять на нову систему, якщо стара система їх не влаштовує. Цеочевидно. Але чому ж їх не влаштовує? Тому що немає людей, які можуть контролювати нутрощі системи — або відбулася ротація програмістів, або спочатку була обрана слабка платформа, яка не справляється з великим навантаженням, або створено такий набір латок, що простіше перейти на нову систему, ніж намагатися розібратися в існуючій. Найчастіше присутні всі перелічені причини. Розвиток існуючої системи зайшло тупик, тобто. як зараз кажуть – програма більше не задовольняє потреби бізнесу.
Щоб перейти нову систему шляхом керованого вибуху, тобто. послідовно по одному робочому місцю, потрібно детально розумітися на обох системах. Все це потрібно, щоб налаштувати повноцінний інформаційний обмін між двома системами на перехідний період. Інакше нічого не вийде. Але як тільки ви починаєте розбиратися в старій системі і повністю починаєте розуміти механізми роботи, то виходить, що з'являється та людина, яка може контролювати існуючу стару систему і виходить, що вже немає гострої необхідності переходити на нову систему.
Мабуть, парадокс пояснюється тим, що таких людей, які можуть розібратися в недокументованому хаосі інформації, не так багато. З нею не впораються фахівці, які займаються лише підтримкою системи. Дуже важливий момент у тому, що тут потрібна особлива мотивація, яка змусить виконати титанічну роботу, т.к. ця робота не вдячна, її основна маса прихована під водою – цю роботу можна побачити лише як результат переходу на нову програму.
А у нас тут можна отримати грант на тестовий період Яндекс.Хмари. Варто лише у полі «секретний пароль» запровадити «Хабр»