Книги

• Разное
• Экономика
• Право
• История
• Шпоры

реклама

4. Етапи розроби проекту з ІТ-консалтингу

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

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

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

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

Надання консалтингових послуг передбачає виконання наступних основних етапів:

діагностика (виявлення проблем);

розробка рішень;

упровадження рішень.

Деякі автори, зокрема, Посадський А.П., вважають [5], що поняття консалтинговий процес ширше, ніж проект, воно, крім проектної, містить передпроектну і післяпроектну стадії. Тобто пропонується п’ятифазова модель консалтингового процесу. Ця модель представлена на рисунку 3.

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

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

Передпроектна стадія	1. ПІДГОТОВКА	Перший контакт із клієнтом
		Попередній діагноз проблеми
		Планування завдання (Визначення задач)
		Пропозиції клієнту щодо завдання на консультування (технічне завдання, фінансові пропозиції)
		Укладання контракту на консультування
Проектна стадія	2.ДІАГНОСТИКА	Збір даних на об’єкті
		Аналіз і синтез фактів
		Виявлення і детальне вивчення проблем
	3. ПЛАНУВАННЯ РІШЕНЬ	Розроблення рішень
		Оцінювання альтернативних варіантів рішень
		Вибір рекомендованих рішень
		Пропозиції керівництву компанії-клієнта
	4. ВПРОВАДЖЕННЯ	Розробка програми впровадження
		Допомога в реалізації пропозицій
		Контроль за впровадженнях
		Оцінювання результатів проекту
		Коригування пропозицій
		Остаточне завершення проекту
		Вихід консультантів з організації-клієнта
Післяпроектна стадія	5. ЗАВЕРШЕННЯ	Аналіз змін, що мали місце у клієнта в результаті реалізації проекту
		Оформлення кінцевого звіту
		Розрахунки по зобов’язанням
		Плани на майбутнє (пошук ідей для нових проектів з цим самим клієнтом)
		Самоаналіз діяльності консультанта по проекту з метою удосконалення його роботи

Рисунок 3 - Модель процесу консультування

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

Проектна стадія здійснюється вже в рамках укладеного контракту.

Фаза 2: діагностика. Вона здійснюється у формі дослідження, метою якого є чітке визначення основних параметрів організації-клієнта (ресурсів, основних результатів господарської діяльності, сильних і слабких сторін, можливості покращення результатів та ін.), що мають відношення до проблеми, для розв’язання якої залучають консультанта. Під час цієї фази сторони разом встановлюють, які зміни потрібні. Чи є основна проблема технологічною, організаційною, інформаційною, психологічною або якоюсь іншою? Якщо вона практично всеохоплююча, який аспект є вирішальним? Як в організації ставляться до змін: чи усвідомлюється їх необхідність, чи потрібно переконувати персонал, що зміни потрібні?

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

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

Звіт про проведені дослідження підсумовує результати діагностики і надається клієнту для схвалення і отримання можливості перейти до наступної фази.

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

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

Фаза 4: впровадження. Четверта фаза консультування ретельно перевіряє правильність і реальність пропозицій. Запропоновані зміни починають ставати реальністю. Щось відбувається так, як планувалось, а щось інакше. Можуть виникати нові проблеми й ускладнення, виявлятися помилкові судження або помилки в плануванні. Можливо доведеться коригувати початковий проект і план дій. Оскільки неможливо точно пердбачити всі зв’язки та події, а реальний хід справ часто відрізняється від плану, дуже важливо слідкувати за реалізацією цієї фази і управляти нею. Тому більшість професійних консультантів прагнуть здійснювати ті зміни, які вони допомагали визначати й планувати.

Консультант може брати участь у реалізації своїх пропозицій:

надаючи поради персоналу, який відповідає за їх впровадження;

коригуючи деякі деталі раніше запропонованих рішень;

навчаючи персонал клієнта.

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

Навколо питання щодо участі консультанта у реалізації змін виникає багато непорозумінь. Дуже часто завдання по консультуванню закінчуються при передачі звіту з пропозиціями, тобто до початку здійспення плану рішень. Наприклад, у США не більше 30-50% завдань по консультуванню включають впровадження. Якщо клієнт сам здатний повністю впоратися з буть-яким етапом процесу змін і хоче цього, немає сенсу використовувати консультанта. Останній може залишити організацію вже після фази діагностики. На практиці часто приймають рішення реалізувати пропозиції консультанта самостійно не тому,  що клієнт упевнений у своїх силах, а тому, що поширеним є представлення, що консультування закінчується прийняттям клієнтом звіту та пропозицій.

Останнім часом поширюється підхід, коли впровадження змін відбувається за підтримки і контролі консультанта, щоб уникнути відхилень від намічених рішень.

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

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

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

Консалтинговий проект у сфері ІТ звичайно розбивається на наступні етапи [1]:

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

Проведення маркетингового дослідження для визначення параметрів майбутнього IТ-проекту.

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

Управління процесом створення IТ-проекту і навчання співробітників компанії.

Роботи по підтримці і розвитку IТ-проекту.

Такий порядок дій не залежить і не повинен залежати від змісту конкретних питань, з якими звертається клієнт. Список етапів може бути продовжений і деталізований і стати достатньо об'ємним.

Слід зазначити, що розробка рішення для клієнта – це завжди творчість, що, втім, не може існувати у відриві від технічної складової, що є інструментом для створення такого рішення.

Наприклад, Кальянов Г.Н виділяє такі етапи розроби проекту з ІТ-консалтингу [3]:

1.             Аналіз первинних вимог і планування робіт. Даному етапу передує ініціація робіт над проектом. Його основними задачами є:

аналіз первинних бізнес-вимог,

попередня економічна оцінка проекту,

побудова плану-графіка виконання робіт,

створення і навчання спільної робочої групи.

2.             Проведення обстеження діяльності підприємства. У рамках даного етапу здійснюється:

попереднє виявлення вимог, що висуваються до майбутньої системи;

визначення організаційної і топологічної структур підприємства;

визначення переліку цільових задач (функцій) підприємства;

аналіз розподілу функцій по підрозділах і співробітниках;

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

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

Початковою інформацією при проведенні обстеження і виконанні подальших етапів є:

дані по організаційній структурі підприємства;

інформація про використовувані технології діяльності;

стратегічні цілі і перспективи розвитку;

результати інтерв'ювання співробітників (від керівників до виконавців нижньої ланки);

пропозиції співробітників по удосконаленню бізнес-процесів підприємства;

нормативно-довідкова документація;

досвід системних аналітиків у частині, що стосується наявності типових рішень.

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

3. Побудова моделей діяльності підприємства. На даному етапі здійснюється обробка результатів обстеження і побудова моделей діяльності підприємства наступних двох видів:

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

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

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

Перехід від моделі "як є" до моделі "як повинно бути" здійснюється наступними двома способами.

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

2) Радикальна зміна технологій і переусвідомити бізнесу-процесів ("жорсткий" реінжиніринг). Наприклад, замість спроб поліпшення бізнес-процесу перевірки кредитоспроможності клієнта, може доцільніше задуматися, а чи потрібна взагалі така перевірка? Можливо витрати на такі перевірки кожного з клієнтів у багато разів перевищують збитки, які може понести компанія в окремих випадках несумлінності (наприклад, у випадку, коли клієнтів багато, а суми закупівлі незначні)!

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

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

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

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

4. Розробка системного проекту. Даний етап є першою фазою розробки власне системи автоматизації - фазою аналізу вимог до системи - на якій вимоги замовника уточнюються, формалізуються і документуються. Фактично на цьому етапі дається відповідь на питання: "Що повинна робити майбутня система?". Саме тут лежить ключ до успіху всього проекту автоматизації. У практиці створення великих програмних систем відомо немало прикладів невдалої реалізації саме через неповноту і нечіткість визначення системних вимог. На цьому етапі визначаються:

архітектура системи, її функції, зовнішні умови її функціонування, розподіл функцій між апаратною і програмною частинами;

інтерфейси і розподіл функцій між людиною і системою;

вимоги до програмних і інформаційних компонентів системи, необхідні апаратні ресурси, вимоги до бази даних, фізичні характеристики компонент системи, їх інтерфейси;

склад людей і робіт, що стосуються системи;

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

Системний проект будується на основі моделі "як повинно бути" і включає функціональну модель майбутньої системи відповідно до одного із загальновживаних стандартів (наприклад, IDEFO або IDEF3), інформаційну модель, наприклад, у відповідності зі стандартом IDEF1X, а також технічне завдання на створення автоматизованої системи (наприклад, у відповідності з ГОСТ 34.602-89).

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

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

описати, "побачити" і скоригувати майбутню систему до того, як вона буде реалізована фізично;

зменшити витрати на розробку і впровадження системи;

оцінити розробку за часом і результатами;

досягнути взаєморозуміння між всіма учасниками роботи (замовниками, користувачами, розробниками, програмістами і т.д.);

поліпшити якість системи, що розробляється, а саме:

створити оптимальну структуру інтегрованої бази даних, виконати функціональну декомпозицію типових модулів.

Системний проект повністю незалежний і відокремлюється від конкретних розробників, не вимагає супроводу його творцями і може бути безболісно переданий іншим особам. Більш того якщо з якихось причин підприємство не буде готове до реалізації проекту, він може бути встановлений "на полицю" доти, поки в ньому не виникне необхідність. Крім того, його можна використати для самостійної розробки або коригування вже реалізованих на його основі програмних засобів силами програмістів ІТ-відділу підприємства.

Книги принадлежат их авторам и выставлены для ознакомления