Левін С.В., керівник проектів компанії "ІнтКом Альянс" www.1c-enter.ru
Складовою частиною процесу автоматизації середніх і великих підприємств проводяться за проектною технологією є етап обстеження. Зважаючи на складність відчуття його результату від групи закупівлі замовника часто доводиться чути приблизно такі питання: Навіщо потрібно витрачати стільки часу на обстеження? Що воно нам дасть? За що тут платити? і т.д. Відповіді на ці та багато інших питань ви знайдете в статті керівника проектів компанії «ІнтКом Альянс» Сергія Льовіна www.1c-enter.ru
Обстеження - що це?
На попередніх переговорах про впровадження будь-якого програмного продукту потенційний виконавець, розповідаючи про те, як він збирається досягти поставлених цілей, згадує в якості першого етапу необхідних робіт - обстеження (проектне обстеження, передпроектну обстеження, експрес обстеження - імен не злічити). З одного боку зрозуміло, що за допомогою нього виконавець хоче краще розібратися в проблемі, з іншого боку вартість цього етапу може досягати до третини від вартості всього проекту, що потенційному замовнику може здатися надмірним.
Спробуємо розібратися в тому, наскільки цей етап необхідний, і які реальні завдання він перед собою ставить.
- обстеження,
- Адаптація ПО,
- Наповнення бази даних початковими даними,
- Навчання користувачів,
- Дослідна експлуатація,
- Введення в промислову експлуатацію.
Звертаю вашу увагу на те, що п.п. 2-4 можуть йти паралельно і / або слідувати в довільному порядку.
Перш ніж переходити до нашої основної мети, а саме обговорення Обстеження як такого, для повноти картини, коротко розглянемо всі вище перераховані етапи.
- Адаптація ПО. Як правило, впроваджувана програма є тиражним універсальним рішенням, тобто розробляли її не для вас, а створювали для вашої сфери діяльності або області обліку. Звідси в програмі є весь або майже весь необхідний вам функціонал, але він в деяких випадках недостатній або, навпаки, надмірний. Власне процес адаптації і покликаний «заточити» ПО «під руку» замовника.
- Наповнення бази даних. Щоб користувачі могли почати працювати, необхідно ввести базові дані (наприклад, списки складів і товарів; заборгованість клієнтів і постачальникам; там, де потрібно, вибрати вид обліку і т.п.). Зазвичай в цей етап включають і настройку прав користувачів до даних, але іноді така робота виноситься в окремий етап параметричних налаштувань.
- Навчання користувачів. Якщо доведеться з чимось працювати, то дуже бажано, щоб він володів необхідними навичками, інакше він не буде працювати, або буде працювати, але дуже погано. Мета даного етапу - дати користувачам необхідні знання, вміння та навички для роботи в новій програмі.
- Дослідна експлуатація. На даному етапі необхідно перевірити функціонування нової автоматизованої системи в умовах «близьким до бойових».
- Введення в промислову експлуатацію. Завершальний етап проекту, результат - ПЗ впроваджено і всі поставлені проблеми вирішені.
Але повернемося до першого етапу впровадження - обстеження. Для початку визначимося з цілями обстеження. Почнемо з змісту договорів на реалізацію проектів. У них зазвичай пишуть, що виконавець з одного боку зобов'язується надати послугу, а замовник з іншого боку її оплатити. А яку послугу? Де описано, що повинен зробити виконавець і, що, власне, повинен оплачувати замовник? Простіше кажучи, потрібна формалізація змісту послуг. Документ, що містить таку формалізацію, що є частиною договору і критерієм, за яким будуть здійснюватися приймально-здавальні роботи, і буде матеріальним результатом обстеження.
Це, з необхідністю, вимагає двох договорів - одного на обстеження, а іншого на реалізацію проекту. З цих же причин виконавець вкрай не охоче йде на підписання єдиного договору - зобов'язання за результатами проекту чітко не визначені і не зрозуміло - під ніж підписуватися.
Однак головне завдання обстеження складається в іншому. Згадаймо, що мета будь-якого проекту - це рішення будь-якої проблеми замовника (інакше не зрозуміло, навіщо замовник затіяв дорогі процедури). Але справа в тому, що виконавець не вирішує проблему, а робить якийсь комплекс робіт спрямований на вирішення цієї проблеми. Якщо роботи були сплановані правильно і виконані з прийнятною якістю, то проблема буде вирішена, в іншому випадку - як пощастить. Простіше кажучи, виконавець хоче отримати гроші за виконані роботи і не виконувати безкоштовні роботи. Замовник же готовий платити за вирішення проблеми і не хоче породження нових проблем. У наявності, якийсь конфлікт інтересів. Вирішується він спільною роботою виконавця і замовника. Результатом цієї роботи буде спільно вироблений шлях по досягненню мети. Сам результат фіксується в документі, зазвичай званим «Звітом про обстеження», який в подальшому буде підставою для проведення проектних робіт. Саме на етапі обстеження абстрактна мета ( «Автоматизуйте мені облік» або «Впровадити CRM») перетворюється в комплекс чітких завдань.
До слова, комплекс деталізованих завдань можна оцінити з дуже великою точністю. Справа в тому, що на перших зустрічах виконавець не знає - скільки коштує проект, він передбачає його вартість з деякою точністю (зазвичай спираючись на свій досвід вирішення схожих проблем). Але вартість для конкретного замовника - він не знає. У комерційних пропозиціях, як правило, чітко прописують вартість обстеження, а суми по реалізації, хоча і показують, але попереджають, що ці вони можуть бути змінені після обстеження. При цьому похибка може становити плюс / мінус 10 до 30 відсотків від початкових оцінок.
Скажу кілька слів про «Звіті про обстеження». Він складається з трьох частин:
- Загальна частина. Вона містить загальні дані по проекту: цілі, завдання, обмеження, поточний стан автоматизації, список відповідальних осіб і т.д. Іншими словами, інформацію про які стоять проблеми і про підходи до їх вирішення. Також там міститься опис середовища проекту: кількість користувачів, віддалені підрозділи, взаємодія з уже існуючим у замовника ПО і т.п. Але, що найважливіше, повинна бути описана концепція автоматизованої системи. Де вона «живе», як вона взаємодіє із зовнішнім середовищем, вказати інформаційні потоки і т.д.
- Перелік робіт. Являє собою ієрархічну структуру робіт. Виходить вона в такий спосіб: береться етап, який розбивається на завдання, завдання розбиваються на підзадачі, .... а до кожної подзадаче пропонується рішення у вигляді однієї або декількох робіт.
Наведемо приклади можливих робіт:
- Кодування - виконавець вносить зміни в код програмного продукту. Зазвичай це пов'язано з якоюсь особливістю процесів замовника, які повністю не лягають на функціонал типової програми. Для якісного кодування потрібно описати бізнес-процес замовника (в повному обсязі, а з точки зору завдань автоматизації) і зміни, які побачать користувачі. Як виконавець доб'ється необхідних змін в даному контексті не важливо - власне, його, в тому числі, для цього і найняли.
- Налаштування прав доступу і інтерфейсів. Зазначу тут одну особливість - опис тут орієнтоване на користувача, тобто текст повинен бути зрозумілий людям не знають внутрішню архітектуру ПО.
- Навчання. Тут все просто, вказується, кого вчимо (бажано поіменно) і чому (з деталізацією за темами). Важливо відзначити, що виконавець не може гарантувати факт навчання. Яким би прекрасними не були б викладачі виконавця, вони не можуть дати гарантію навчання, особливо якщо студент захворів і не з'явився на заняття або звільнився до закінчення проекту. Тому роботи з навчання полягають у відпрацьованих зі студентами годиннику. І хоча це не відноситься до цілей обстеження, варто відзначити, що замовнику вже на цьому етапі варто продумати систему мотивації, для отримання найбільшого ефекту від навчання.
- Перенесення даних. Під перенесенням даних зазвичай мається на увазі створення інструментарію по перенесенню даних. Немає сенсу переносити цю секунду стан складів (припустимо з електронних таблиць), якщо проект буде запущений в промислову експлуатацію тільки через місяць. Тому потрібен інструмент, який «по одній кнопці» допоможе перенести необхідні дані, в той момент, коли це знадобитися. Для цілей перенесення даних в «Звіті про обстеження» необхідно вказати - звідки, які, куди і яким чином переносяться дані.
- Установка ПО. У цій частині звіту вказуються параметри комп'ютерів, параметри локальної мережі, додаткове ПО, рівень необхідних для установки прав і т.д.
- Роботи зі створення документації (опис автоматизованої системи, інструкції користувачів і т.д.). Тут, перш за все, необхідно зрозуміти призначення документації. Бажано вказати в якому вигляді вона повинна бути надана. Погодьтеся є різниця між файлом відправленим по електронній пошті і паперовим тиражем в кілька сот примірників.
- План-графік робіт. Залежно від кількості робіт може бути представлений у вигляді простої таблиці або мережевий діаграми. У плані-графіку вказуються дати початку і закінчення робіт, учасники проекту та відповідальні особи за виконання і приймання робіт.
Перерахуємо ще ряд цілей, які досягаються обстеженням.
До них можна віднести вирішення проблеми: «а чи правильно виконавець розуміє замовника, кажуть вони на одній мові?». Виконавець з замовником можуть використовувати одні і ті ж терміни, але в різних значеннях. Особливо це проявляється в виробничих областях, де термін специфікація може означати, що завгодно. Саме з цього іноді відбувається подорожчання або здешевлення проекту Замовник хотів автоматизувати бюджетування, але процесі обстеження може з'ясуватися, що під бюджетуванням він розумів, як довгострокове фінансове планування, але і казначейство (короткострокове планування руху грошових коштів) - це збільшить вартість проекту, а фактично змінить проект. Можуть бути і зворотні випадки, коли виконавець припускав будь-які роботи, але в процесі обстеження, з'ясувалося, що вони не потрібні.
Як проходить обстеження?
Основний метод проведення обстеження - інтерв'ю. Після чого відбувається документування отриманої інформації і узгодження документів.
Цей процес може повторюватися кілька разів. Коли інформація зібрана і оброблена, результат оформляється у вигляді «Звіту про обстеження», потім затверджується.
Як бути з нюансами?
Якщо взяти проект з будівництва будинку, то, як би ми не спускалися вниз по кресленнях, ми завжди будемо зустрічати докладний опис виробів, всі матеріали будуть мати ГОСТ, всюди будуть інструкції, аж до описів умов проведення робіт. В IT-сфері в масі своїй документація не розроблена або закрита. Фактично «Звіт про обстеження» є єдиним документом, що описує всі проектні роботи (іноді його розбивають на частини і дають їм різні назви). Виникає питання: А наскільки він повинен бути докладний? Очевидним є зміст відповіді: Він повинен бути дуже докладний, і не допускати подвійних тлумачень! Але.
Візьмемо просту задачу додавання нового реквізиту в екранну форму документа. Реалізація даного завдання справу однієї хвилини. Тепер спробуйте її докладно описати, не забудьте намалювати, як буде виглядати нова екранна форма, а також узгодьте отримане опис з зацікавленою особою. Ситуація в прикладі свідомо перебільшена, але з нього видно, що якщо ми спробуємо створити дуже детальну документацію, то на неї піде основна вартість проекту. Вихід в компромісі і цей компроміс виконавцю і замовнику слід досягати разом.
На закінчення зазначу, що в частині підготовки документації не все так погано. Незважаючи на те, що в цілому стандартизованої документації немає (вірніше у деяких компаній документація може бути розроблена, але в масі своїй вона носить закритий характер і не є загальним стандартом для галузі) - існують методички з навчання, стандарти з написання коду, опису побудови інтерфейсів і т.д. Все це в сумі дозволяє створювати робочу проектну документацію.