На сьогоднішній день погляд на проекти автоматизації облікових процесів зводиться до рекомендації придбання систем сімейства «1С:Підприємство», або аналогічних за функціональними можливостями. Для великої кількості українських підприємств таке рішення може бути достатнім, але далеко не для всіх. Виходячи з поставлених замовником цілей, проект створення такої системи автоматизації може реалізовуватися як впровадженням типової системи з подальшою її адаптацією так і створенням комплексної системи автоматизації під конкретного замовника.
На практиці, на етапі ініціації програмного проекту, в рамках групи процесів ініціації, проводиться ряд заходів, які забезпечують створення початкової концептуальної моделі майбутньої системи автоматизації. Метою концептуального моделювання (Conceptual Modeling) – є розуміння проблем, задач і методів їх рішення до того, як розпочнеться їх безпосереднє вирішення. Основою для даного процесу є робота зі збору, аналізу та формалізація бізнес-вимог (Business Requirements), які входять до групи функціональних вимог і визначають цілі високого рівня для організації або клієнта (споживача) – замовника системи автоматизації [1].
Успішність проекту створення системи автоматизації облікових процесів може бути визначена на етапі розробки концепції системи. Подальший процес роботи з вимогами виконується, зазвичай, за методом декомпозиції вимог, які відображені в концептуальній моделі. Як результат існує пряма залежність між якістю і повнотою розробленої концепції і відповідністю створеної на її основі системи автоматизації потребам конкретного бізнесу. Така система може повністю відповідати затвердженому технічному завданню і, навіть, може бути введеною в експлуатацію. Проте, якщо концепція системи розроблялася без глибокого аналізу потреб користувачів та замовників, то програмний продукт приречений на відторгнення внутрішньою корпоративною структурою підприємства, чиї облікові процеси підлягали автоматизації. Саме процесу управління вимогами до програмного продукту в процесі розробки концепції такого продукту необхідно приділити найбільшу увагу щоб забезпечити успішность проекту автоматизації та довготривалість життєвого циклу створеної системи автоматизації [2].
Існуючі правила та стандарти програмної інженерії передбачають конкретні методології роботи з вимогами до програмних продуктів. Але, на жаль, навіть керуючись класичними прийомами збору та аналізу потреб, функціональних, не функціональних та системних вимог досить часто модель системи автоматизації є далекою від потреб конкретного підприємства. Процес збору та аналізу вимог, який детально описується в галузевій літературі, тісно перекликається з процесами управління зацікавленими сторонами проекту, які в останній редакції PMBoK розглядаються як окрема область знань [3].
До ключових зацікавлених сторін проектів створення систем автоматизації облікових процесів можемо віднести дві наступні групи:
- керівники та власники бізнесу, що здебільшого виступають замовниками подібних проектів;
- виконавці та учасники процесів підлягаючих автоматизації, що є безпосередньо користувачами створюваних систем.
Основною помилкою в процесі роботи з вимогами та формування концепції системи автоматизації є ігнорування потреб (повністю або частково) однієї з цих груп. В ідеальному варіанті система автоматизації повинна забезпечити зручність, простоту у використанні та відповідність прийнятим на підприємстві бізнес-процесам для задоволення потреб безпосередніх користувачів, а також, бути засобом накопичення, аналізу та обробки інформації про поточний стан підприємства для прийняття управлінських рішень керівництвом. В залежності від того, хто виступає ініціатором створення системи автоматизації подібного типу, зазвичай відбувається зміщення пріоритетів в ту чи іншу сторону.
До основних конфліктних питань між представниками вказаних груп зацікавлених сторін можна віднести:
-рівень автоматизації елементарних облікових процесів;
-рівень прозорості та повноти інформації, що буде накопичуватися в системі автоматизації;
-рівні доступу до інформації;
-деталізація та рівні контролю роботи виконавців.
Основною метою першої групи є накопичення та ефективний аналіз інформації, а другої – оптимізація процесів шляхом максимальної автоматизації повсякденної діяльності.
При нерівномірній увазі до вищезгаданих груп зацікавлених сторін проекту виникає ризик не лише спотворення початкової концепції системи автоматизації, а й виникнення протидії сторони чиї інтереси не враховуються або враховуються не в достатній мірі, що призведе до явного або неявного супротиву цієї сторони в процесі безпосереднього впровадження створеної системи автоматизації.
Література.
1. A Guide to Software Engineering Base of Knowledge (SWEBOK). [електронний ресурс] – режим доступу: http://www.swebok.org/
2. Мацяшек Л.А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML / Мацяшек Л.А. – М. : Издательский дом "Вильямс", 2002. – 432 с.
3. A Guide to the Project Management Body of Knowledge. (PMBOK Guide) - Fifth edition. Project Management Institute, 2013. - 589 c.
Перша публікація: "Тези доповідей Х міжнародної конфенеції "Управління проектами у розвитку суспільства"
Комментариев нет:
Отправить комментарий