У мене є багаторічний досвід впровадження і подальшого супроводу інформаційних систем на різних підприємствах. Досвід, у більшості випадків, був успішним - але тут я хочу поговорити, в першу чергу, про причини, що ведуть до невдачі в цій справі, застерегти вас від можливих помилок. Я означу власний метод впровадження, який я використовував неодноразово і який допомагає уникнути більшості з них.
Перша і найголовніша причина провалу: некоректно поставлена мета для інформаційної системи.
Це одне з основних питань для будь-якого проекту взагалі. Замовник часто вибирає мету, яка не має до інформаційної системи ніякого відношення, або ж залежить від неї незначно. Приклади: збільшення продажів, зайняття більшої частки ринку, створення іншої культури управління підприємством тощо. Але якщо компанія виробляє товар, попит на який падає - як тут допоможе інформаційна система? Проблему тут має вирішувати підрозділ маркетингу. Якщо потрібно змінити культуру підприємства - це питання управління персоналом і генерального директора. У деяких, однак, жевріє надія, що варто віддати гроші за інформаційну систему - і проблеми, пов'язані з організацій бізнесу, вирішаться самі собою. Обіцянки продавців, які «впарюють» дорогі, іноземного виробництва, багаторазово перевірені і побудовані на «кращих світових бізнес-практиках» системи лише зміцнюють цю віру. Але насправді компанія з неефективним стилем управління залишиться неефективною, тільки вже з інформаційною системою. Якщо на вашу продукцію впав попит, він теж не зміниться ніяк. Правда, інформаційна система дозволить вам швидко і точно підрахувати збитки, в тому числі і від її впровадження.
Коректно поставлена мета впровадження інформаційної системи - запорука успіху цього впровадження. Правильні цілі, пов'язані з обробкою інформації: зберігання, пошук даних, завдання, пов'язані з розрахунками, угрупованням, аналізом. При впровадженні системи все це вимагати менше часу. Пам'ятайте, однак, що прискорення невдалих процесів призведе до ще більш невдалого результату для компанії, ніж було б без системи.
Ось один з недавніх випадків на переговорах із замовником. Замовник хоче змінити систему конфігурування виробу, сподіваючись, що це впорядкує роботу виробництва. З його слів, нова система повинна надати тільки обмежений вибір доступних опцій виробів. Тоді виробництву і відділу узгодження буде простіше працювати, з'явиться набір стандартних рішень. У замовника, однак, вже є конфігуратор. Відразу виникло питання: навіщо змінювати? Відповідь приголомшлива: інший конфігуратор «змусить нас працювати правильно», створити необхідну документацію на виріб, змінити схеми обробки замовлень і скоригувати культуру роботи із замовником. Виходить, менеджери розуміють, у чому проблема, але розписуються у власному безсиллі змінити ситуацію і перекладають труднощі щодо реорганізації бізнес-процесів на підрозділ, який за це не відповідає. Як правило, такий проект завершується крахом або затягується на довгі роки.
Навіть якщо припустити, що фахівці-інформаційники знають, як слід змінити бізнес-процеси (з логікою у нас порядок), у них все одно немає потрібного адміністративного ресурсу, та й очікуваний результат залежить, в першу чергу, не від програмного забезпечення. Тут явно плутається слідство і причина. Припустимо, є підприємство А з інформаційною системою ABC. Підприємство працює стабільно, немає авралів, плутанини, замовлення виконуються в строк, є планомірна діяльність налагодженого механізму. Можна зробити висновок, що все добре завдяки системі ABC, але це 100% не так. Наявність системи ABC у підприємства A, скінчено ж, робить свій внесок у бізнес, але не є ключовим. Якщо керівництво якогось підприємства Б вирішило впровадити у себе систему ABC в надії, що після її впровадження підприємство Б теж буде працювати так само, як A, його чекає сюрприз. Гроші будуть витрачені, але очікуваний ефект не настане, тому що методика роботи на підприємстві Б не зміниться.
Ефективні цілі
Повторюся - цілі, які я вважаю ефективними при впровадженні інформаційної системи, пов'язані з прискоренням існуючих бізнес-процесів або створенням нових для обробки даних. Не варто перекладати на інформаційну систему завдання інших підрозділів, особливо без права впливати на ці процеси.
Впровадження інформаційної системи дозволяє запустити бізнес-процеси, які раніше не мали права на існування через неприйнятні терміни виконання. Більше того, я вважаю, що запуск нових бізнес-процесів - обов'язкова умова для успішного впровадження системи. Очевидно, якщо раніше ми використовували напильник для виконання робіт, а тепер у нас верстат, це буде інший процес. Якщо планування було налагоджено погано, верстат, через свою продуктивність, принесе компанії ще більший збиток.
Отже, з цілями ми визначилися, тепер залишилося правильно скласти технічне завдання.
Технічне завдання
Це друга за важливістю складова успіху при впровадженні інформаційної системи. Нагадаю, ефективна мета - прискорення бізнес процесів, яких може бути ще не існує. Замовник тільки в загальних рисах розуміє, що йому потрібно. Хорошим варіантом вважається вже на перших етапах роботи скласти докладне багатосторінкове ТЗ. Це працює, особливо для виконавця за контрактом. Замовник все підписує, не до кінця розуміючи, що саме зробить виконавець. А між тим, за кожне нове поле або форму, не записані в ТЗ, виконавець запросто попросить із замовника ще грошей. У підсумку замовник отримає процес з неповними або надлишковими даними, хоча формально контракт був виконаний в точній відповідності з вимогою. Замовник буде незадоволений і вдруге до цього виконавця не звернеться.
Виходить, що не замовник підписав невідповідне ТЗ, а виконавець розробив і запропонував зовсім не те - не вгадав, про що мріяв замовник. Помічаєте парадокс? Виконавець сам для себе пише ТЗ, але при цьому повинен вгадати, чого насправді хоче замовник. В принципі, це можливо (для учасників шоу «Битва Екстрасенсів»), але малоймовірно. У мене був досвід створення докладних ТЗ, які на етапі впровадження зазнавали змін близько 30%. Звичайна історія: в процесі роботи над проектом у замовника з'являлися нові ідеї, їх доводилося враховувати, відмовляючись від попередніх рішень. Тому я не прихильник дуже докладних ТЗ. Вони забирають багато часу, а в підсумку будуть скориговані на етапі дослідної експлуатації та впровадження. Якщо не зробити коригування, можна зіпсувати відносини з замовником. При спробі послатися на докладне ТЗ у відповідь ви почуєте - «ну, ви ж фахівці, повинні були самі все знати заздалегідь».
Я вважаю, в ТЗ повинні бути відображені тільки загальні блоки робіт з описом очікуваних результатів. Нехай воно досить точно описує, що хоче отримати замовник, і що повинен зробити виконавець. Коригування ТЗ неминуче через те, що при появі нового інструменту у замовника обов'язково з'являться нові бізнес-процеси. Спроба зберегти колишні бізнес-процеси призведе до провалу проекту. Звичайно, не все старе позначається повністю, воно коригується відповідно до збільшених можливостей підприємства за наявності інформаційної системи. Максимум, на чому має зупинятися ТЗ - списки документів для обробки системою з їх зразками. Таким чином, складене ТЗ не зміниться в частині загальних вимог, фактично воно буде уточнюватися в процесі впровадження, аж до конкретних полів і процесів. При цьому виконавець у будь-якому випадку знає очікуваний обсяг робіт. Для успішного проекту потрібно 1-2 ітерації: впроваджується певний обсяг виконаних робіт, і за результатами замовник погоджує корекцію з виконавцем. Час, який можна було витратити на зайву деталізацію ТЗ, набагато ефективніше використовувати для ітераційних коригувань системи відповідно до результату тестової експлуатації.
Є ще один варіант складання ТЗ: у ньому декларується кінцева мета замовника. І тут ви можете відразу помітити протиріччя з попереднім написаним тестом. Це випадок складання проекту, в якому інформаційна система є тільки частиною. У мене був досвід впровадження комплексної системи управління компаній, де основна сума по контакту виплачувалася в разі, якщо замовник отримає збільшення обороту в два рази. Питається, це як? Відповідь проста: цілі замовника - автоматизація та оптимізація бізнес процесів копанні, прискорення процесу роботи з клієнтами, точний облік витрат за контрактами, точний розрахунок бонусів менеджерам, які беруть участь у контрактах, фінансове планування. Виходячи з того, що всі ці завдання не були вирішені, я підписав контракт. На жаль, досягти 100% збільшення обсягу обороту у замовника за 1 рік не вдалося, але 83% теж добре. Моя винагорода була виплачена пропорційно.
Наступним важливим документом для успішного виконання робіт є план-графік робіт.
План-графік робіт
План-графік - документ, що містить план конкретних робіт, в якому описані дії, які повинні виконати як замовник, так і виконавець. План-графік потрібен для оперативного контролю за роботою обох сторін. Як правило, в ньому перераховуються всі системи і підсистеми зі своїми процесами, документами, звітами, які будуть розроблені і впроваджені. Наприклад: дії замовника, пов'язані з організацією робочих місць, прокладанням комунікацій, навчанням персоналу тощо. На кожному пункті плану-графіка може бути проставлена ціна і тривалість, це дає можливість робити взаєморозрахунки між виконавцем і замовником. Роботи, звичайно, можуть йти паралельно. Добре використовувати діаграми Ганта або щось аналогічне, але не обов'язково.
Запуск системи в роботу
Запуску системи передує тестування виконавцем системи на прикладах замовника. Після отримання позитивних результатів починається робота з реального впровадження та запуску системи. Якщо дослідна експлуатація робиться тільки на дослідних прикладах без участі рядових виконавців замовника, без використання реальних завдань, вона не досягне поставленої мети. Метою ж є збір зауважень, які необхідно усунути для переведення в промислову експлуатацію. Даний етап правильніше було б назвати розширеним тестуванням із залученням виконавців замовника. Реальна дослідна експлуатація починається після впровадження системи за участю, як мінімум, 50-70% відсотках робочих місць.
Персонал проходить навчання, для користувачів складаються короткі інструкції. Цей етап може тривати від декількох хвилин до декількох тижнів. Добре працюють методи екстремального програмування, коли зауваження від співробітників виконавця відразу усуваються кваліфікованими розробниками замовника, бажано на місці у замовника. Тим самим за один, максимум два тижні можна вирішити основну масу проблем, пов'язаних із запуском і адаптацією системи. Без масштабного запуску з неухильною вимогою керівництва замовника введення в експлуатацію може затягуватися на довгі місяці. Якщо немає жорсткої вимоги керівництва, люди будуть працювати по-старому. При будь-яких нововведеннях у людей лише виникне відчуття, що їм хтось заважає жити.
Після етапу дослідної експлуатації відразу слідує промислова. Відмінність між ними тільки в кількості зауважень, які повинні бути усунені, і у відсутності критичних проблем, при наявності яких експлуатація стає неможливою.
У підсумку ми отримуємо такі етапи запуску та впровадження системи:
- Тестування із залученням співробітників замовника на реальних прикладах;
- Дослідна експлуатація з негайним усуваємо виникаючих проблем;
- Промислова експлуатація.
Цей метод був перевірений мною багаторазово на підприємствах різних масштабів. Співробітники компанії замовника в деякі моменти відчувають дискомфорт, як і співробітники виконавця. Але, на щастя, дискомфорт цей швидко сходить нанівець, і підприємство переходить в планомірну роботу при конструктивному підході до вирішення виникаючих завдань.
