Помилкові цілі проектної команди

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

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

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

І різність цілей часто призводить до неспроможності продукту, «звареного» в даному казанку суперечливих ідей.

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

Становлення проблеми

Зазвичай першим кроком при впровадженні ERP є впорядкування одиниць обліку - довідкових даних (етап MDM). ERP до довідкових даних відноситься дуже примхливо. Якщо для кейсів статі автоматизованого обліку достатньо пошуку і порівняння по найменуванню в EXCEL, то казанок ERP вимагає однозначних ID. Крім того, багаторазове введення довідкових даних у різних системах це чималі трудовитрати. Виходячи з опису проблеми, ми маємо спільну мету - «Створити єдину систему довідкових даних (MDM) і навести порядок у веденні довідників». Але вона сформована не чітко і ми вже на цьому етапі стикаємося з розбіжностями на рахунок єдиної мети:

• Бізнес вже рахує, скільки осіб/годин можна економити за рахунок автоматизації довідників;
• Підрядник вже готує кошторис - це досить швидка вигода з мінімальними трудовитратами;
• Команда розробки намагається «мапити» об'єкти систем з різними структурами даних для мінімізації доробок і намагається знайомитися з новим «чужорідним тілом» у своєму інформаційному ландшафті
• Бізнес користувачі висловлюють все більше «хотілок» з метою залишити, як було і не зламати існуючі процеси, обґрунтування «навіщо Вам це потрібно» часто домогтися складно і в деяких випадках йдуть на компроміси

Короткостроковий результат

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

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

Перші плоди

На наступному етапі впровадження системи ERP (почали віддавати документи) трапилася біда, у якої досить багато симптомів і причин їх виникнення, але першопричина одна. Я почну з перерахування деяких «симптомів» і причин їх виникнення.

• З поточних систем неможливо видалити довідкові дані, а в ERP вирішили не тягнути весь обсяг довідників. Тому частина даних залишилася без ERP ID. І, як виявилося, довідковими даними, які не мали «зв'язку з ERP» помилково активно користувалися, що призвело до неможливості обробки безлічі документів
• Деякі об'єкти системи ERP мали «термін життя». Наприклад, у ERP контрагент може бути активним і не активним. Не вдалося створити документ на некоректному контрагенті, а вони створювалися в системах джерел помилково
• Можливості ERP виявилися набагато ширшими за можливості LS (успадкованих систем) і бізнес процеси, які обіцяли не використовувати користувачі активно почали використовувати у зв'язку переходом на нові етапи життєвого циклу системи. Іншими словами LS виявилися менш гнучкими по відношенню до ERP.

І таких прикладів було досить багато. А першопричина одна - мета системи.

Визначення причини провалу

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

Якби була поставлена саме ця мета, то:

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

Наслідки

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

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

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

Висновки

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

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

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

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

3. Найчастіше мети дізнатися досить складно.

Але там де мета явно не описана я про них здогадуюся і погоджую їх з усіма учасниками.

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