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

1. Ціль та задачі
2. 1. Огляд підходів впровадження корпоративних інформаційних систем
3. 2. Проектні документи типових етапів реалізації проекту
4. 2.1. Етап підготовки проекту
5. 2.2. етап проектування
6. 2.3. етап реалізації
7. 2.4. Етап підготовки до дослідно-промислової експлуатації
8. 2.5. Етап дослідно-промислової експлуатації
9. 2.6. Етап переходу до продуктивної експлуатації
10. 3. Залежність підготовлених документів від етапів проекту
11. Результати та Висновки
12. література
13. вихідні дані

Подробиці Опубліковано: 14.07.2018 21:24 Степанов Дмитро Юрійович Переглядів: 7522

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

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

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

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

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

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

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

Мал. 1. Основні підходи впровадження КІС

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

Мал. 2. Типові етапи реалізації проекту впровадження КІС

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

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

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

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

Мал. 3. Типові етапи впровадження корпоративних інформаційних систем із зазначенням вихідних документів

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Залежність підготовлених документів від етапів проекту

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

Мал. 4. Послідовність підготовки проектних документів при проектуванні системи, навчанні користувачів, перехід до використання системи та міграції даних

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

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

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

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

література

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. A Guide to the 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 Like a 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. - c.208-228.
10. Степанов Д.Ю. Формування універсальних вимог до призначених для користувача програм при підготовці специфікації на ABAP-розробку // Актуальні проблеми сучасної науки. - 2014. - т.78, №4. - c.258-268.

вихідні дані

Степанов Д. Ю. Огляд проектних документів при впровадженні корпоративних інформаційних систем // Питання економічних наук. - 2014. - т.70, №6. - c.54-62. - URL: http://stepanovd.com/science/29-article-2014-1-docflows .