Проектування та впровадження іс. Передача інформаційної системи у промислову експлуатацію

Подробиці Розміщено: 14.07.2018 21:24 : розглядаються базові етапи впровадження корпоративних інформаційних систем. Крім того, виконується огляд проектних документів кожного з етапів, а також демонструється залежність даних заданої фази на документи наступних етапів.
Завантажити: PDF.
Ключові слова:документи ERP систем, документування впровадження корпоративних інформаційних систем, документування інформаційних систем, документи в інформаційній системі, проектна документація ERP систем, робоча документаціяІС, технічна документаціяКІС, нормативні документиінформаційної системи, нормативні документи щодо проектування інформаційних систем, документи впровадження ПЗ, документи впровадження інформаційних систем, етапи та документи впровадження програмного продукту, дослідна експлуатація інформаційних систем, ГОСТ Р 54869-2011, ANSI PMBoK.

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

Ціль та задачі

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

• огляд літератури, присвяченої впровадженню КІС;
• розгляд базових етапів імплементації КІС;
• аналіз проектних документів та його залежностей від етапів.

1. Огляд підходів упровадження корпоративних інформаційних систем

Корпоративна інформаційна система є сукупністю інформаційних систем (далі - ІВ), визначальних задану предметну область. Існує кілька підходів застосування ІВ, застосовних як і імплементації КІС (рис.1). Почнемо огляд із підходу, декларованого державою. Йдеться про галузевих стандартах, зокрема, ГОСТ Р 54869-2011 , а також міжнародному стандарті ISO 21500 . Документи містять опис етапів управління проектами від процесу ініціалізації до завершення незалежно від виду системи, що реалізується. Тому можливе використання зазначених стандартів для реалізації технічних, інформаційних та корпоративних систем. Звід професійних знаньз управління проектами, представлений ANSI PMI PMBoK, регламентує процеси планування, виконання, перевірки та впливу від етапу ініціювання до завершення проекту. Аналогічно ГОСТ Р 54869-2011 та ISO 21500 допускається його застосування для керування впровадженням різних видівсистем.

Мал. 1.

Методології Accelerated SAP (далі – ASAP), Accenture Delivery Methods (далі – ADM), а також Microsoft Dynamics Sure Step (далі – MDSS) використовуються компаніями SAP, Accenture та Microsoft відповідно при впровадженні пакетованих КІС рішень. Підходи спрямовані виключно на реалізацію проектів імплементації КІС. У розглянутих вище підходах використовується переважно каскадна схема впровадження КІС. Ця схема характеризується суворою часовою залежністю виконання етапів проекту. Роботи на за даному етапіможуть виконуватися тільки в тому випадку, якщо реалізовано всі активності попередньої фази проекту. Найменування етапів відрізняється від підходу до підходу, проте зміст робіт незмінно. Тому цілком реально сформувати єдиний перелікяк операцій, так і документів, що готуються. Підсумуємо результат аналізу підходів застосування КІС списком типових етапів реалізації проекту (рис.2).

Мал. 2.

2. Проектні документи типових етапів реалізації проекту

У попередньому розділі було виділено типові етапи реалізації проектів щодо впровадження КІС, що включають

• підготовку проекту;
• проектування;
• реалізацію;
• підготовку до дослідно-промислової експлуатації (далі – ОПЕ);
• ОПЕ;
• перехід до продуктивної експлуатації (далі - ПЕ)

та є загальними для методологій ASAP, ADM, MDSS та стандартів. Допускається відсутність етапу ОПЕ, тоді 4-а та 5-та фази проекту забезпечуватимуть підготовку до ПЕ та ПЕ відповідно. Розглянемо документи кожного з етапів докладніше (рис.3).

Мал. 3.

2.1. Етап підготовки проекту

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

2.2. Етап проектування

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

Вимоги замовника порівнюються зі стандартним рішенням КІС (Fit-аналіз) виявлення функціонального дефіциту (GAP-анализ). Функціональний дефіцит вимагає доопрацювання системи, для чого готуються специфікації на розробку, що містять постановку задачі та пропонований вектор рішення. Розробляється концепція ролей та повноважень, що визначає перелік ролей користувачів та правила їх створення та присвоєння співробітникам. Стандартний функціонал КІС, специфікації на розробку та концепція ролей та повноважень необхідні для формування проектних рішень. Проектні рішення містять бізнес-процеси замовника в моделях «як є» та «як буде» із зазначенням доопрацювань системи та ролей користувачів.

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

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

2.3. Етап реалізації

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

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

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

2.4. Етап підготовки до дослідно-промислової експлуатації

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

Далі аналізуються отримані під час навчання зауваження. Продовження проекту можливе, якщо журнал проблем містить зауваження, які не гальмують проведення ОПЕ. У цьому випадку готується список користувачів, що беруть участь в ОПЕ, надаються необхідні ролі. Формується план початку використання системи у режимі ОПЭ, куди входять перелік необхідний кроків задля забезпечення роботи КІС і їх виконання. Конкретні кроки плану містять посилання операції з інструкції з переходу до використання системи. План міграції даних аналогічний плану переходу до використання системи, однак містить посилання на інструкцію з міграції. Клієнт забезпечує заповнення та перевірку даних у шаблонах завантаження. Етап підготовки завершується закладом користувачів у системі проведення ОПЕ, а також міграцією основних та змінних даних.

2.5. Етап дослідно-промислової експлуатації

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

2.6. Етап переходу до продуктивної експлуатації

Успішне завершення етапу ОПЕ дозволяє говорити про перехід до ПЕ. Основна умова переходу – відсутність зауважень у журналі проблем та оновлення всієї проектної документації за результатами виправлення зауважень. Аналогічно етапу підготовки до ОПЕ готуються списки користувачів системи, плани переходу до ПЕ та міграції даних. Заповнюються шаблони завантаження даних. Створивши користувачів у КІС, виконавши всі операції із плану переходу та міграцію даних, починається робота в режимі ПЕ. Починаючи з цього моменту, зауваження та проблеми, що виникають, вирішуються силами групи підтримки клієнта. На етапах реалізації, підготовки до ОПЕ і ОПЭ помилки системи реєструвалися в журналі проблем і виправлялися фахівцями підрядника.

3. Залежність документів, що готуються, від етапів проекту

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

Мал. 4.

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

Результати та висновки

Розгляд методологій впровадження КІС, виявлення типових етапів імплементації систем, а також огляд проектної документації та залежності документів від фаз проекту складають основні результати роботи. Аналіз методологій впровадження ІВ дозволив виділити фази підготовки проекту, проектування, реалізації, підготовки до ОПЕ, ОПЕ та перехід до ПЕ, що є типовими незалежно від обраного стандарту чи методології управління проектом. Опис проектної документації виконано кожного типового етапу імплементації КІС і наочно представлено як каскадної схеми (рис.3). Дано короткий описдокументів та порядок їх підготовки. Основний акцент зроблено призначення документів, а чи не їх зміст.

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

Література

1. ГОСТ Р 54869-2011. Проектний менеджмент. Вимоги до управління проектом. - М.: Стандартінформ, 2011. - 10 с.
2. Zandhuis A., Stellingwerf R. ISO 21500. Guidance on Project Management. A pocket guide. - NL.: Van Haren Publishing, 2013. - 148 p.
3. ANSI/PMI 99-001-2014. Guide до Project Management Body of Knowledge (PMBOK Guide). - Pennsylvan.: Project Management Institute, 2013 - 589 p.
4. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. - NJ.: Sybex Inc, 1999. - 591 p.
5. Kress R. Running IT Як Business: A Step-By-Step Guide to Accenture's Internal IT. – Ely: IT Governance Publishing, 2012. – 140 p.
6. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. - Birmingham: Packt Publishing, 2011. - 360 p.
7. Проектування інформаційних систем: навчальний посібник/ Гвоздєва Т.В., Баллод Б.А. - Ростов н / Д.: Фенікс, 2009. - 508 с.
8. Ковальов С., Ковальов В. Секрети успішних підприємств: бізнес-процеси та організаційна структура. - М.: БІТЕК, 2012. - 498 с.
9. Степанов Д.Ю. Огляд логістичних бізнес-процесів з прикладу закупівельної діяльності підприємства // Логістика сьогодні. - 2014. - Т.65, №5. - С.208-228.
10. Степанов Д.Ю. Формування універсальних вимог до програм користувача при підготовці специфікації на ABAP-розробку // Актуальні проблеми сучасної науки. - 2014. - Т.78, №4. - С.258-268.

Реалізація

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

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

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

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

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

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

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

Обробка результатів проектування

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

Бажано, щоб на етапі проектування вже було побудовано матрицю «функції-сутності». Це фактично формалізоване уявлення про те, що фірма намагається зробити (функції) і яку інформацію потрібно обробити для досягнення результату (сутності). Подібна матриця дозволяє перевірити такі моменти:

• чи має кожна сутність конструктор - функцію, що створює екземпляри сутності (create);
• чи є посилання на цю сутність, тобто чи використовується десь ця сутність (references);
• чи мають місце зміни цієї сутності (update);
• чи має кожна сутність деструктор – функцію, яка видаляє екземпляри сутності (delete).

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

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

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

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

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

Системні модулі

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

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

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

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

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

Засоби моніторингу інформаційної системи

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

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

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

Інтерфейси

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

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

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

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

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

Версії бази даних

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

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

• проконтролювати, які об'єкти даних та дані мають місце в об'єктах завантаження A та B, та завантажити в базу даних лише «різницю» A та B (здійснити оновлення версії);
• проконтролювати, чи не конфліктують зміни, що мають місце в об'єктах вивантаження C і D, порівняно з об'єктом вивантаження A (злиття версій).

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

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

Розміщення логіки обробки

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

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

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

Шаблони

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

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

Тестування

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

Чим складніше проекттим більше буде потреба в автоматизації системи зберігання помилок - bug tracking. Подібна система забезпечує такі функції:

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

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

Власне тести систем можна поділити на кілька категорій:

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

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

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

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

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

Експлуатація та супровід

допитна експлуатація перекриває процес тестування. Як правило, система вводиться в експлуатацію не повністю, поступово.

Введення в експлуатацію проходить принаймні три фази:

накопичення інформації;

вихід на проектну потужність

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

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

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

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

Інші підходи до розробки додатків

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

• Вся увага сконцентрована на екранних формах, а те, що стосується правил обробки даних та системних функцій, залишається за кадром. Є спокуса розпочати роботу зі звітів, тоді як звіт не стартовий, а похідний продукт інформаційної системи.
• Користувачі вважають, що й варіант прототипу узгоджений, то модуль готовий. Насправді це може бути лише картинка з набором «заглушок» для викликів системних функцій та взаємодії з іншими модулями.
• Модулі проектуються ізольовано один від одного (напевно, більшість із вас стикалися з бухгалтерськими програмами, де кожен АРМ є автономним та функції часто дублюються). Наслідком цього є суперечності модулів, дублювання функцій та даних, що може бути виявлено лише при тестуванні комплексу модулів.
• Функціональні можливості нарощуються паралельно у кількох напрямах, отже, структура бази даних має контролюватись жорстко. При УРП схема бази даних перетворюється на смітник, де таблиці «ліпляться» нашвидкуруч, у результаті має місце набір суперечливих і дублюючих даних.
• Документація під час використання методу УРП, зазвичай, відсутня, а точніше, необхідність документувати систему забувають, оскільки створюється ілюзія, що користувач і так розуміє, що відбувається. Коли ж програма починає працювати не так, як припускає користувач, виникає маса проблем.
• Обробка виняткових ситуацій кожного модуля проводиться своя.
• Цілісна система, як правило, не виходить, швидше за все, це буде певний набір автоматизованих робочих місць, які нашвидкуруч пов'язані між собою.

Методи УРП та УРП можна використовувати далеко не завжди, а лише в тому випадку, якщо:

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

Проте методом УРП краще розробляти невеликі та, бажано, автономні частини проекту.

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

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

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

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

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

Метафора (metaphor). Загальний вид системи визначається за допомогою метафори або набору метафор, над якими працюють замовник і програмісти.

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

Простий проект (simple design). У кожний момент часу система, що розробляється, виконує всі тести і підтримує всі взаємозв'язки, що визначаються програмістом, не має дублікатів коду і містить мінімально можливу кількість класів і методів. Це правило коротко можна виразити так: «Кожну думку формулюй один і лише один раз».

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

Тести (тестів). Програмісти постійно пишуть випробування для модулів (unit tests). Зібрані разом ці тести повинні працювати коректно. Для етапів в ітерації замовники пишуть функціональні тести (functional tests), які повинні працювати правильно. Однак на практиці це не завжди можливо. Щоб прийняти правильне рішення, необхідно зрозуміти, скільки обійдеться здача системи із заздалегідь відомим дефектом, і порівняти це з ціною затримки на виправлення дефекту.

При написанні тестів самими програмістами (особливо в умовах понаднормових робіт) ці тести не повнофункціональні, і особливо не враховують особливостей розрахованої на багато користувачів роботи. На просунуті тести у розробників зазвичай бракує часу. Можна, звичайно, побудувати систему розробки так, що всім займатимуться одні й ті самі люди, але все ж таки не варто перетворювати проект на аналог телепередачі «Сам собі режисер». До сказаного необхідно додати, що тестування системи не вичерпується тестами компонентів (units); не менш важливі тести взаємодії між ними, це ж стосується і тестів надійності роботи. Проте метод екстремального програмування не передбачає створення тестів даного класу. Це тим, що самі такі тести можуть представляти досить складний код (особливо це стосується тестів-імітаторів реальної роботи системи). У цій технології також не враховується ще один важливий клас тестів - тести поведінки системи при зростанні обсягів інформації, що обробляється. При високій швидкості зміни версій виконати такий тест технологічно неможливо, оскільки його проведення вимагає стабільного та незмінного коду проекту, наприклад, протягом тижня. Подібні терміни, взагалі кажучи, не гарантуються через частої зміниверсій. У такому разі доведеться або припиняти розробку компонентів, або на час проведення тесту створювати паралельну версію проекту, яка зберігатиметься незмінною, тоді як друга при цьому змінюватиметься. Потім потрібно буде виконувати процес злиття коду. Але в цьому випадку тест доведеться створювати знову, оскільки методи екстремального програмування просто не передбачають розробку засобів, що дозволяють прогнозувати поведінку системи за тих чи інших змін.

Переробка системи (refactoring). Архітектура системи постійно еволюціонує. Поточний проект трансформується, гарантуючи правильне виконання всіх тестів.

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

Програмування у парі (pair programming). Весь код проекту пишуть дві особи, які використовують одну настільну систему.

Виникає питання: хтось бачив двох абсолютно однакових програмістів, кожен із яких до того ж наприкінці робочого дня встигав би писати документацію для партнера? Чи можна знайти таких програмістів-близнюків, згодних у всьому?

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

Безперервна інтеграція (continuous integration). Новий код інтегрується в існуючу систему не пізніше, ніж за кілька годин. Після цього система знову збирається в єдине ціле та проганяють усі тести. Якщо хоча б один із них не виконується коректно, внесені зміни скасовуються.

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

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

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

Замовник із постійною участю (on-site customer). Замовник, який під час роботи над системою перебуває у команді розробників.

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

40-годинний тиждень (40-hour weeks). Обсяг понаднормових робіт не може перевищувати за тривалістю один робочий тиждень. Навіть окремі випадки понаднормових робіт, що повторюються дуже часто, є сигналом серйозних проблем, які потребують невідкладного вирішення.

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

Відкритий робочий простір (open workspace). Команда розробників знаходиться у великому приміщенні, оточеному кімнатами меншої площі. У центрі робочого простору встановлюються комп'ютери, де працюють пари програмістів.

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

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

Можливо, врешті-решт і буде вироблено одне корисне правило: спочатку подумай, потім зроби. У цьому випадку ми матимемо схему, дуже схожу на «водоспад». Чомусь прихильники екстремального програмування переконані, що при використанні «водоспаду» та його клонів цикл розробки обов'язково має бути довгим. Незрозуміло, чим зумовлено таку впевненість. Адже не заборонено подрібнювати проект на етапи. Чомусь вважається, що планування обов'язково буде одноразовим і незмінним, хоча насправді це не відповідає істині, у тому числі й у випадку водоспаду.

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

Комп'ютерПрес 2"2002

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

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

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

1. Розгортання системи на майданчику дослідної експлуатації

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

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

Рисунок 19. – Приклад технічного опису етапу впровадження

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

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

Тим часом 90% часу вже пролетіло.

2. Навчання персоналу замовника роботі з інформаційною системою

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

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

А ми на етапі проектування попереджали, що навчання персоналу замовника не тільки дуже відповідальне завдання, а ще й дуже трудомістке.

3. Виявлення недоліків та дефектів інформаційної системи

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

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

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

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

А тим часом ми досягли дна, відведеного для проекту часу.

4. Узгодження змін у процесі впровадження інформаційної системи

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

Етап узгодження нового рішення дуже важливий як мінімум з двох причин.

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

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

І ось перефразовуючи Єжи Леца: «Коли ми досягли дна відведеного часу, знизу постукали...»

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

5. Доопрацювання інформаційної системи за підсумками дослідної експлуатації

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

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

Власне, настав момент, коли актуальні такі умови:

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

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

Малюнок 20. – Етап впровадження інформаційної системи

Без коментарів…

6. Передача інформаційної системи у промислову експлуатацію

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

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

7. Резюме розділу

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

1. Розгортання системи на майданчику промислової експлуатації, включаючи постачання обладнання, встановлення системного ПЗ, встановлення актуального релізу системи, що впроваджується, тощо;
2. Навчання користувачів роботі із системою, включаючи адміністраторів, спеціалістів з обслуговування обладнання тощо.
3. Виявлення та усунення недоліків та дефектів, виявлених у ході дослідної експлуатації.
4. Погодження змін у роботі системи та приведення її до відповідності контрактним зобов'язанням;
5. Підписання документів щодо виконання договірних зобов'язань. Добуток повного розрахунку за виконані роботи;
6. Введення системи у промислову експлуатацію;

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

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

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

Наслідуючи цю логіку, стає зрозуміло, що хоча корпоративна ІС призначена в цілому для забезпечення всіх користувачів необхідною інформацією, управління розробкою та впровадження КІС є прерогативою вищого керівництва компанії! Чи це розуміють керівники?

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

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

На цей час склався стандартний набір прийомів застосування ІВ. Основне правило: виконувати обов'язкові фази послідовно та не пропускати жодної з них.

Критично важливими для впровадження є такі фактори:

· Наявність чітко сформульованих цілей проекту та вимог до ІВ;

· Наявність стратегії впровадження та використання ІС;

· Проведення передпроектного обстеження підприємства та побудови моделей "Як є" і "Як буде";

· Планування робіт, ресурсів та контроль виконання плану впровадження;

· Участь вищого керівництва у впровадженні системи;

· Проведення робіт з впровадження ІС фахівцями з інтегрування систем спільно з фахівцями підприємства;

· регулярний моніторинг якості виконуваних робіт;

· Швидке отримання позитивних результатів хоча б у частині впроваджених модулів ІВ або в процесі її дослідної експлуатації.

Перед початком розробки проекту впровадження необхідно:

· максимально формалізувати цілі проекту впровадження ІВ;

· оцінити мінімально необхідні витратита статті витрати;

· Встановити високий пріоритет проекту впровадження перед іншими поточними проектами;

· Наділити керівника проекту максимально можливими повноваженнями;

· Провести масову просвітницьку роботу з персоналом підприємства з метою довести до кожного важливість і необхідність майбутніх перетворень;

· Розробити організаційні заходи для застосування нових інформаційних технологій;

· розподілити персональну відповідальністьпо всіх етапах впровадження та дослідної експлуатації.

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

· організаційне управління;

· Організаційно-адміністративне забезпечення;

· Управління бізнес-процесами;

· Управлінський, планово-фінансовий та бухгалтерський облік;

· управління персоналом;

· Управління документацією;

· Управління матеріально-технічним забезпеченням;

· Керування зв'язками з клієнтами та зовнішнім середовищем.

Крім того, що перераховано вище, треба задати технологічні вимоги до впровадження ІВ:

· Системна платформа - впровадження та адаптація готового рішеннявід виробника або розробка на замовлення відповідно до технічного завдання замовника;

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

· адаптованість - система налаштовується відповідно до вимог замовника та на особливості інформаційного поля замовника;

· Розподіл - система може ефективно функціонувати в територіально віддалених підрозділах та філіях підприємства;

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

Основні фази впровадження інформаційної системи

Фаза "Попередні роботи з підготовки проекту впровадження ІВ". У ході передпроектного обстеження підприємства відбувається збір докладної інформації про структурну побудову організації, функціональні зв'язки, систему управління, про основні бізнес-процеси, про потоки всередині підприємства (Control Flow, Data Flow, Work Flow, Cash Flow). відповідних моделей та вибору об'єктів для автоматизації. Оцінюються терміни, ресурси, види та обсяги робіт, номенклатура та вартість програмно-апаратних та телекомунікаційних засобів, вартість навчання персоналу тощо.

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

· Формування проектної та експертної груп;

· Розподіл повноважень та відповідальності;

· Визначення організаційно-технічних вимог до процесу впровадження;

· Уточнення специфікацій та очікувань замовника;

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

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

Фаза "Концептуальне опрацювання проекту". Протягом цієї фази:

· Формується та затверджується концептуальний проект;

· Досягається обов'язкове однозначне розуміння намірів всіх учасників проекту щодо впроваджуваної ІС;

· Уточнюються та конкретизуються цілі та завдання проекту;

· Визначаються розміри прототипу системи;

· Узгоджуються укрупнений план роботи, послідовність етапів та умови дослідної експлуатації, планово-фінансові та звітні показники;

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

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

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

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

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

7. Фактори успіху та причини невдалих впроваджень ІС

моделювання інформаційний реінжиніринг бізнес

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

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

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

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

Перше. Визначте мету проекту

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

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

· Відсутність єдиного формату подання даних управлінського обліку.

· Відсутність регламентів формування управлінських звітів.

· Відсутність єдиного інформаційного середовища

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

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

Глибоке осмислення цілей проекту може призвести до відмови від його здійснення або перенесення його термінів через перегляд пріоритетів.

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

· Скорочення запасів на складі за рахунок більш точного планування виробництва та закупівель;

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

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

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

Друге. Відкрийте проект

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

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

Іншими словами, потрібно чітко розуміти, що проект? це повноцінна організаційна структура, тимчасово створена всередині організації задля досягнення цілком певних цілей.

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

Третє. Забезпечте проект ресурсами

Основні ресурси- це гроші та люди. Тому необхідно затвердити бюджет проекту.

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

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

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

Четверте. Подбайте про мотивацію

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

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

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

П'яте. Підтримка керівництва

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

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

Шосте. Розбийте проект на етапи

Тривалий проект найкраще"розрізати на шматки" і не приступати до чергового етапу, не переконавшись, що завдання попереднього етапу повністю виконані. Дуже важливо визначити, що має стати результатом кожного етапу проекту.

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

Переходити до чергового етапу можна лише після виконання трьох умов:

· Команда проекту виробила єдине розуміння результатів етапу;

· Це розуміння оформлене у вигляді документа;

· Результати етапу прийняті замовником, тобто керівником підприємства.

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

Сьоме. Керуйте цілями та очікуваннями

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

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

Фаза "Попередні роботи з підготовки проекту впровадження ІВ". У ході передпроектного обстеження підприємства відбувається збір докладної інформації про структурну побудову організації, функціональні зв'язки, систему управління, про основні бізнес-процеси, про потоки всередині підприємства (Control Flow, Data Flow, Work Flow, Cash Flow). відповідних моделей та вибору об'єктів для автоматизації. Оцінюються терміни, ресурси, види та обсяги робіт, номенклатура та вартість програмно-апаратних та телекомунікаційних засобів, вартість навчання персоналу тощо.

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

формування проектної та експертної груп;

розподіл повноважень та відповідальності;

визначення організаційно-технічних вимог до процесу впровадження;

уточнення специфікацій та очікувань замовника;

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

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

Фаза "Концептуальне опрацювання проекту". Протягом цієї фази:

формується та затверджується концептуальний проект;

досягається обов'язкове однозначне розуміння намірів усіх учасників проекту щодо впроваджуваної ІС;

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

визначаються розміри прототипу системи;

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

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

Мал. 3. Зразковий зміст репозиторію проекту впровадження

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

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

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

Мал. 4 Зразковий склад документації щодо процесу впровадження ІВ

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