Що потрібно для успіху інтеграційного проекту корпоративного рівня
У цій статті я хотів би поділитися досвідом компанії RedSys у сфері реалізації та управління проектами системної інтеграції. Сподіваюся, читачам він здасться у чомусь цікавим чи навіть корисним. Під інтеграційними я маю на увазі не проекти з інтеграції таких інфраструктурних елементів, як мережі, сервери та СГД, а ті, в яких необхідно реалізувати набір наскрізних бізнес-процесів, що відповідають специфічним вимогам даної організації. Бізнес-процесів, що базуються на безлічі нерідко різнорідних, прикладних систем та джерел даних. У тексті статті ви не знайдете найменувань будь-яких платформ, вендорів, описів технологій, технічних деталей та архітектурних рішень. Ви не побачите також жодної згадки про реальних замовників, що дозволить нам сконцентруватися на суті обраних для розгляду аспектів: з чого починати, як приймати рішення, оцінювати ризики тощо.
Проекти, в яких є інтеграційний аспект, вважаються одними з найскладніших. Пов'язано це з тим, що рішення, створене під час такого проекту завжди є унікальним, а це означає, що підхід до реалізації та управління подібними проектами також має бути індивідуальним. Якщо ми ще згадаємо, що зобов'язані вкластися у відведені терміни, бюджет і забезпечити необхідну якість, стає очевидно, що братися за реалізацію таких проектів можна лише за наявності висококваліфікованої команди та якісної підтримки проекту всіх рівнях і етапах.
Важливість пресейлу
Запуск проекту може бути ініційований як замовником, так і інтегратором, але в будь-якому випадку починається інтеграційний проект з етапу пресейлу, на якому сторони повинні розібратися в тому, що дійсно хоче замовник і які системи належить інтегрувати. Важливо такожоцінити вимоги до документування: наприклад, підготовка документації з урахуванням ГОСТу чи відповідно до ГОСТу — це, як кажуть, дві великі різниці. Більше того, на цьому етапі можна оцінити реальну зацікавленість клієнта та його фактичну готовність до запланованого проекту. Пресейл передує підписання контракту, і замовник у принципі може проводити подібні роботи одночасно з кількома потенційними підрядниками. Ми переконані, що на боці інтегратора у пресейлі, разом із сейлами мають бути задіяні технічні фахівці, причому саме ті, яким згодом доведеться брати участь у реалізації проекту.
Відповідальність цієї роботи складно переоцінити, оскільки в результаті потрібно прийняти єдине правильне рішення, оперативно вивчивши великий і водночас далеко не повний обсяг інформації, провівши низку досліджень, часто стикаючись з необхідністю застосування нових технологій, сервісів і додатків. І все це в умовах вкрай обмеженого часу: зазвичай, не більше двох тижнів щільної роботи команди з трьох осіб. Помилки на цьому етапі можуть мати катастрофічні наслідки як для виконавця, який зазнає фінансових та репутаційних втрат, так і для замовника, який не зможе в бажані терміни вирішити свої завдання.
Слід зазначити, що на цьому етапі активну роль повинен грати і замовник, який нерідко не до кінця уявляє, що йому по-справжньому потрібно, а що має факультативний характер. Виділення для цієї мети фахівців замовника на довготривалій основі допоможе йому краще розуміти вимоги проекту і не намагатися, як іноді буває, просто виторговувати максимальне зниження ціни на шкоду якості або продуктивності рішення, що створюється. Активне включення замовника до роботи на етапі пресейлустворює передумови для подальшого формування спільної з підрядником команди, яка братиме участь у проектуванні, реалізації та впровадженні системи.
Цілком покладатися на системного інтегратора не слід: ніхто краще за штатних функціональних і технічних фахівців замовника, не знає всю специфіку та особливості його бізнес-процесів. Такі співробітники зазвичай завантажені поточною роботою, і домогтися їхнього залучення на етапі пресейлу буває непросто, але чим раніше вони підключаться до спільної роботи, тим краще для проекту. Не виключено, що в процесі спільної роботи на етапі пресейлу прийде усвідомлення того, що організація не готова до реалізації проекту. Такого висновку боятися не варто, краще буде і для замовника, і для інтегратора зрозуміти це на самому початку і прийняти правильне рішення, яке дозволить усім не втратити свої гроші, а підряднику ще й не поставити під сумнів свою репутацію.
Інтегратору слід попередньо узагальнити всю передісторію роботи з даним клієнтом (за її наявності, зрозуміло): чи були успішні продажі та за якими позиціями (послуги, ліцензії, обладнання), як виник запит на даний проект, з ким із керівництва замовника можна контактувати безпосередньо в ході пресейлу (перші особи, ІТ-керівництво, начальники функціональних підрозділів). Корисно також мати повне уявлення про конкурентне середовище. Знаючи все це, ви зможете зрозуміти можливий рівень підтримки проекту, оцінити реальну зацікавленість клієнта та його фактичну готовність до нього.
Рідко який інтеграційний проект може бути виконаний відповідно до жорстко прописаного техзавдання: завжди виникають нюанси, які важко було спрогнозувати на ранніх етапах. Тому при написанні технічного завдання замовник та виконавець повинні домовитисяпро підхід, який дозволить вирішувати подібні проблеми альтернативними засобами або вносити корективи у функціональність кінцевого рішення, необхідність яких була виявлена вже в ході виконання проекту (скажімо, змінилася нормативна база).
Реалізація та впровадження
Не завжди проектування і прототипування створюваного рішення можна проводити в ІТ-інфраструктурі замовника. Зазвичай ми на своєму майданчику моделюємо інфраструктуру замовника, розгортаємо на ній тестове середовище та намагаємось інтегрувати ті чи інші прикладні системи. Незважаючи на те, що в тестовому середовищі інтеграція перевіряється дуже ретельно, на етапі впровадження в інфраструктурі замовника проблеми трапляються.
Взагалі слід пам'ятати, що будь-який інтеграційний проект через свою складність та унікальність несе з собою безліч ризиків, які на ранніх етапах виявити буває дуже складно. Тому в планах необхідно закладати певний запас за термінами та вартістю з розрахунком на вирішення непередбачених проблем. Крім цього, в процесі реалізації дуже часто виникають незаплановані завдання, вирішення яких може спричинити зсув термінів або необхідність додаткових витрат. Щоб мати можливість оперативного прийняття рішень та зняти у замовника сумніви щодо обґрунтованості додаткових витрат, дуже корисно буває ще на ранніх етапах включити до проектної групи експертів з боку замовника.
Наявність спільної проектної команди, в якій беруть активну участь експерти замовника, забезпечує якісний зворотний зв'язок з його топ-менеджментом та дає вихід на вищих керівників у разі виникнення критично важливих проблем. А ризики бувають різні. Не завжди функціонування програмного продукту повністю відповідає поточнійдокументації вендора. Не всі інтеграційні механізми підтримуються в одного і того ж вендора. Іноді необхідно використовувати недокументовані корисні можливості, для отримання доступу до яких потрібно спеціальне звернення до розробників продукту та додатковий час. Нерідко проблеми, яких не було в тестовому середовищі, виникають після розгортання в ІТ-інфраструктурі замовника через її більшу завантаженість або інші особливості. Та й вимоги замовника за час виконання проекту можуть змінитися як з об'єктивних, так і з суб'єктивних причин (не все було враховано на етапах випуску техзавдання та проектування) — це також ризик. Останнє трапляється зазвичай у тих випадках, коли замовник не має досвіду проведення такого роду проектів (недостатній рівень зрілості). У цьому випадку значно підвищити шанси успішної реалізації дозволить залучення до проекту для роботи на стороні замовника експертів, які мають необхідний досвід.
Такий крок підвищить рівень зрілості замовника та закладе добрий фундамент для супроводу та розвитку впровадженої системи. Крім того, наявність таких людей дозволяє уникнути пастки надмірних очікувань, в яку іноді потрапляють фахівці замовника, далекі від ІТ-проблематики та системної інтеграції. Взагалі моніторинг очікувань замовника повинен здійснюватись виконавцем у ході всього проекту, при цьому системний інтегратор повинен залишатися максимально відкритим та готовим до обговорення найгостріших проблем (а не замовчувати їх). Іноді це дозволяє знаходити конструктивний вихід, здавалося б, безвихідних положень шляхом взаємоприйнятних коригувань техзавдання або окремих функцій.
Мабуть, найвідповідальніший етап проекту – впровадження. Він додатково ускладнюється тим, що інтегратор працює в чужому середовищі таскований жорсткими часовими рамками, а замовник повинен оперативно навчити своїх співробітників і почати експлуатувати систему, не ставлячи під загрозу роботу інших систем та безперервність свого бізнесу в цілому. Тут особливо важливо працювати в щільному контакті з системними аналітиками та бізнес-експертами замовника, які увійшли до проектної команди ще на ранніх етапах і добре знають особливості впроваджуваного рішення.
Що буде після
Навіть після формального завершення проект продовжує жити своїм життям. Впроваджену систему потрібно підтримувати. Іноді це робиться силами ІТ-департаменту замовника, якщо у нього є відповідні спеціалісти, але дуже часто техпідтримкою цим займається інтегратор, який виконував проект. Це досить ефективно, оскільки він краще за будь-кого знає впроваджене рішення, і саме його доцільно залучати на наступні проекти з розвитку та розширення функціональності системи. А подібні проекти — скоріше правило, ніж виняток: на підприємстві впроваджуються нові прикладні системи, з'являються нові бізнес-процеси або кардинально модернізуються існуючі тощо. . Тільки в процесі тривалої роботи на складному проекті виникає найцінніше на мій погляд — спільний досвід і довіра. А якщо є довіра, то багато хто зі згаданих вище проблем втрачає свою гостроту. Формування злагодженої спільної команди — чи не основний фактор успіху: саме вона забезпечить відповідність створюваної системи реальним потребам бізнесу та завершення проекту у прийнятні терміни, а також змікшує основні ризики.
Автор статті - Володимир Недобой, директор Центру інтеграційних рішень компанії RedSys.