Ноу Інти, лекція, практикум

Попередня ◈ Наступна

9.8. Планування проекту та звітність

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

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

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

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

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

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

За рахунок використання плану-графіка проекту досягається наступне:

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

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

Проект впровадження системи CRM складається з наступних основних етапів (деякі можуть здійснюватися паралельно):

  1. Планування впровадження:
    • Зустріч із запуску проекту (Kick-Off Meeting).
    • Збір вимог бізнес-користувачів.
    • Створення структури поділу робіт.
    • Розробка узагальненого плану-графіка проекту.
    • Затвердження детального опису обсягів робіт.
  • Визначення потреб та дизайн-системи:
    • Розробка і документування архітектури системи високого рівня.
    • Розробка і документування моделі даних.
    • Розробка і документування уявлень (екранів) додатків - контрагенти, контакти, потенційні угоди, і т.д ..
    • Визначення користувачів і їх прав доступу.
    • Розробка і документування формату інтеграції з існуючими інформаційними системами.
    • Аналіз і вдосконалення моделі даних.
    • Розробка і документування схем конвертації даних (логічна прив'язка таблиць і полів даних в інтегрованих системах).
    • Затвердження остаточної документації по архітектурі системи.
  • Конвертація даних:
    • Розробка детальної схеми конвертації даних.
    • Розробка скриптів імпорту.
    • Розробка скриптів очищення / переформатування даних (в разі необхідності).
    • Здійснення конвертації даних.
    • Перевірка правильності конвертації даних.
    • Запуск механізму резервного копіювання даних.
    • Затвердження результатів конвертації.
  • Установка і розгортання системи:
    • Конфігурація серверів, мережі, установка системного ПО.
    • Установка СУБД.
    • Установка сервера синхронізації даних (в разі необхідності).
    • Установка альфа-версії доробок і знову розроблених компонентів.
    • Установка конвертованих даних.
    • Тестування альфа-версії доробок і компонентів.
    • Конфігурація системи для бета-тестування користувачами.
    • Запуск в роботу першої групи користувачів.
    • Затвердження остаточних версій додатків.

    Зустріч із запуску проекту (Kick-Off Meeting)

    Дуже важлива подія в історії проекту впровадження. Напруга, пов'язане з процесом вибору системи і постачальника, вже позаду. З іншого боку, учасники проекту ще не занурилися в рутину впровадження, багато хто навіть не розуміють своєї ролі в проекті. Грамотно проведена зустріч із запуску проекту може заощадити нерви і ресурси на наступних етапах, коли виправдання типу "я думав (а), що потрібно робити такѕ" і "мені ніхто не сказав, що я повинен (на) підготувати ці документиѕ" почнуть сипатися зі усіх боків.

    Під час зустрічі із запуску проекту вирішуються такі питання:

    • Обговорення конкретних цілей, яких даний проект повинен домогтися.
    • Розробка планів і графіків реалізації.
    • Розподіл обов'язків і виділення ресурсів.

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

    План-графік проекту

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

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

    Визначення функціональних вимог

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

    • Загальний хід бізнес-процесів.
    • Існуючі вузькі місця в проходженні бізнес процесів.
    • Детальне розуміння найбільш критичних потреб.
    • Системні параметри системи.
    • Вимоги до безпеки на робочих місцях.
    • Потреби в настройках системи.
    • Узагальнені функціональні вимоги до інтеграції з іншими додатками;
    • Вимоги, які випадають за межі можливостей ПО (такі, як зміни процедур і регламентів роботи).
    • Вимоги до основних звітів.

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

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

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

    Доробки системи CRM

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

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

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

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

    Ми впевнені, що кращий спосіб створення оптимальної системи - постійний контакт з кінцевими користувачами цієї системи в процесі внесення в неї доробок і змін. Коли завдання з доопрацювання затверджена і запущена в роботу, фахівець вносить відповідні виправлення в систему і відразу ж подає їх користувачам для отримання від них зворотного зв'язку. Часто необхідні зміни можуть бути внесені за лічені хвилини і відразу ж на місці представлені для розгляду, якщо вбудований інструментарій архітектурного проектування (такий, як SalesLogix Architect або Siebel Tools) дозволяє це зробити. Таким чином, користувачам надається можливість брати участь у процесі побудови системи ще до навчання її використання.

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

    Конвертація даних

    Якщо інформація про клієнтів існує в електронному форматі, вона зазвичай може бути конвертована у формат будь-CRM-системи. Найбільш зручним форматом файлів для конвертації є "текст, розділений комою" (* .csv). Більшість програм для керування контактною інформацією - такі, як Microsoft Access, Excel надають дану опцію для експорту.

    Також можливо підключити дані безпосередньо через таблиці лише у віддаленій базі даних, такий як Access, Oracle або Microsoft SQL. Надалі ці зв'язки між таблицями можна використовувати для імпорту даних.

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

    Схожі статті

    • Попередня ◈ Наступна