Наталя Заверуха
Наталя Заверуха: На даному етапі дуже велике значення має діалог із клієнтом. Ми готуємо кілька рішень та обираємо разом із замовником оптимальний варіант. Ринок уже зрілий, тому клієнт не задовольняється всього одним або двома рішеннями. Під час розробки кожного варіанту ми оцінюємо, наскільки нововведення обумовлене інтересами бізнесу замовника, чи реально визначено терміни проекту, як ми можемо зекономити та максимально ефективно використати його ресурси під час упровадження проекту й на етапі його експлуатації.
Наприклад, замовник хоче побудувати певну систему за три місяці. Якщо ми бачимо, що цей термін зовсім або за деякими критеріями не відповідає вимогам якості — чесно і обґрунтовано повідомляємо про це. Потім ми оцінюємо, за який реальний термін і з якими ресурсами можемо реалізувати проект. Зазвичай, у 90% випадків наших сил достатньо, щоб виконати всі роботи: від розробки проектної документації — до передачі реалізованого рішення, як кажуть, «під ключ». Якщо ресурсів не вистачає, можемо задіяти партнерів, яких ми прискіпливо відбирали протягом 15-ти років праці на ринку України. Словом, на етапі підписання договору всі крапки над «і» вже потрібно розставити.
PCWeek/UE: Якщо замовник не обирає оптимальний, на вашу думку, варіант, ви погоджуєтесь чи вважаєте за краще відмовитися від проекту взагалі?
Н. З.: В такій ситуації ми завжди намагаємось продовжити роботу із замовником, щоб зрозуміти, які фактори призвели до вибору іншого варіанту, на якому етапі ми помилилися.
На жаль, вирішальним фактором для замовника залишається ціна. Якщо є два варіанти проекту і перший набагато дешевший, то клієнт найчастіше обере саме його. Нерідко він не бачить різниці — йому здається, що обидва проекти схожі.
Зазвичай ми погоджуємося з рішенням замовника, але водночас пропонуємо разом з нашими технічними спеціалістами проаналізувати, до чого може привести такий вибір. Не секрет, що ціна проекту знижується за рахунок не дуже якісних матеріалів та обладнання, або коли не передбачені технічна підтримка чи навчання обслуговуючого персоналу замовника.
Наш досвід показує, що клієнта часто можна переконати, якщо чесно, виважено і обґрунтовано роз’яснити всі деталі проекту. Були випадки, коли він обирав саме нашу пропозицію, хоч вона й була дорожча. На жаль, часто це трапляється з великим запізненням. Наприклад, клієнт дзвонить нам через півроку після тендеру і повідомляє, що обраний ним варіант все одно не працює — просить виправити всі проблеми за планом, який ми пропонували ще на початку діалогу.
PCWeek/UE: Як вибираєте субпідрядника? Чи бувало таке, що субпідрядники вас підводили?
Н. З.: Якщо в проекті, який реалізуємо, нам не вистачає власних ресурсів або кваліфікації, ми звертаємося до субпідрядника. Але обов’язково повідомляємо про це замовника, оскільки робота з субпідрядником — це великий ризик.
Взагалі вибір субпідрядника — дуже відповідальна процедура. Як правило, ми співпрацюємо з кількома компаніями, які дуже ретельно відбираємо. Кожних півроку переглядаємо оцінку наших субпідрядників. Це передбачено процедурою ISO, і ми суворо дотримуємося всіх вимог.
Як я вже казала, приблизно 90% проектів виконуємо своїми силами, зокрема й у регіонах. Наприклад, нашою конкурентною перевагою є представництва в десяти областях. Єдина комплексна структура гарантує якісну роботу.
PCWeek/UE: Яку роль відіграють бізнеспроцеси в реалізації успішного проекту?
Н. З.: Оскільки ринок системної інтеграції досить розвинений, в портфелі кожної компанії є переважно сталий набір послуг. Щоб виділитися на фоні інших, інтегратори намагаються залучити до свого портфеля хоча б кілька унікальних продуктів, а також отримати сертифікат ISO, навчати та своєчасно сертифікувати спеціалістів.
Я завжди розказую клієнтам, як наші напрацьовані бізнес-процеси можуть допомогти їхньому бізнесу. Адже ми вже серйозно вдосконалили власні бізнес-процеси. Тому бачимо, за рахунок чого можна оптимально використати час, бюджет та інші ресурси.
Процес удосконалення проектів та оцінка якості — це постійна фіксація зауважень і побажань, що документуються та складаються в теку по проектам. Після підписання акту (коли замовник прийняв нашу роботу) ми ініціюємо процес оцінки та аналізу результатів згідно з інформацією із папки проекту. Анкетуємо проектні команди — нашу і замовника. Працівники компаніїклієнта мають оцінити нашу роботу та висловити побажання і зауваження.
Отримані результати зводяться воєдино. Це дає змогу оцінити, наскільки проект був вдалим, скільки балів він отримав. На наступному етапі представник якості з команди проекту і від вищого керівництва замовника проводять «розбір польотів» за тими етапами, що отримали низьку оцінку. Це допомагає проаналізувати дії відповідальних співробітників і вилучити проблему з бізнес-моделі. Отже, ми отримуємо замкнений цикл покращення нашої роботи.
Така модель «жива» і постійно розвивається. Описані й задокументовані бізнес-процеси — це завжди сталість і стабільність роботи. Вся компанія безперервно працює над удосконаленням результатів. І якщо замовник запитує, як ми будемо вирішувати ту чи іншу проблему, показуємо йому задокументовані на цей час варіанти розвитку ситуації.
PCWeek/UE: Які підводні камені треба враховувати при складанні SLA*?
Н. З.: Основне запитання — чи справді замовнику потрібний договір з прописаними умовами SLA? Дуже часто це буває лише даниною моди. Представники бізнесу та ІТ завжди вважають, що ІТ-аутсорсинг скоротить їхні витрати.
При правильному підході так і буде: витрати скоротяться, а навантаження на ІТ-персонал зменшиться. Знову ж таки, ІТ-аутсорсинг надає конкурентні переваги компанії. Адже для вирішення цієї задачі завжди обирається підрядник з більш високою кваліфікацією та ширшим набором експертизи, ніж у персоналу компанії. Це обов’язкова умова, оскільки інакше ІТ-аутсорсинг узагалі не має сенсу. Отже, варто звернути увагу на досвід компанії та її компетенції.
Важливо, щоб у таких договорах був задіяний не тільки представник ІТ, а й бізнесу. Обов’язково треба розуміти, як ІТ-сервіси впливають на бізнес. Крім того, має бути виписаний так званий глосарій: завдяки йому і замовник, і підрядник зможуть говорити однією мовою. Особливо це важливо, якщо переговори ведуться з представником бізнесу, а не ІТ. Також до договорів щодо SLA обов’язково треба включати пункт про умови виходу будь-якої зі сторін із контракту. Подібні контракти, як правило, підписують не на півроку і навіть не на рік. Замовник має наполягати на прописані обставин, які можуть призвести до виходу з договору, особливо якщо це перші проекти з аутсорсингу. Адже в деяких випадках клієнт не отримував потрібного результату або очікував чогось іншого. Водночас в контракті прописують обов’язки і штрафи.
Бажано також перевірити фінансовий стан системного інтегратора перед тим як мати з ним справу. Це має бути стабільна компанія. Інакше одного дня вона, можливо, просто перестане надавати задекларовані послуги.
Часто замовник та інтегратор не можуть домовитися про умови компенсації і штрафні санкції. Всі штрафи мають бути співрозмірними. Жодна зі сторін не має відчувати, що її права обмежуються.
Дуже важливо включити до контракту пункт щодо захисту інформації. Ідеться про те, що вся інформація про компанію замовника, до якої має доступ ІТ-аутсорсер, не повинна залишати межі компанії навіть після закінчення контракту. До цих питань звичайно підходять дуже формально, але вони надзвичайно важливі для бізнесу клієнта.
PCWeek/UE: На які ще моменти треба звернути увагу під час роботи над проектом? З яких причин найчастіше трапляються провальні проекти?
Н. З.: Великий ризик невдалого завершення проекту існує в тому випадку, коли в договорі погоджено не всі деталі й під час реалізації виникають різні зауваження та побажання. Треба розуміти, що системний інтегратор не є працівником компанії клієнта — він виконує роботу в рамках, обумовлених договором. Коли замовник ставить ще якісь завдання вже після підписання договору, підрядник не зобов’язаний їх виконувати, якщо вони не фіксуються додатковими письмовими угодами до договору. Такі випадки часто призводять до конфліктів і невдоволення обох сторін.
Ще одна поширена проблема договорів із ІТ-аутсорсингу — не до кінця розподілена відповідальність за вирішення тих чи інших завдань. Адже доволі рідко компанії повністю віддають весь свій ІТ-напрям на аутсорсинг, за деякі сервіси відповідають їхні працівники. В результаті можуть з’явитися «нічийні» сервіси. А коли виникає проблема у їх функціонуванні, кожна зі сторін намагається скинути з себе відповідальність.
Підхід до будь-якого ІТ-проекту має бути схожий на проект будівництва будинку. Тобто спочатку з дизайнером обираємо загальну концепцію. Далі разом з архітектором розробляємо проектне завдання. І тільки потім шукаємо постачальників, будівельників і малярів, які будуть втілювати розроблену концепцію в життя. В реальному житті замовники часто переходять одразу до останнього етапу: підрахунок вартості проекту, виходячи з його специфікації. В результаті проект часто реалізують неоптимально, він не приносить користі для бізнесу компанії. І тоді вже керівництво запитує: а навіщо ми витратили такі гроші? В підсумку виникає недовіра до самої ІТ-служби. А основна причина в тому, що немає попередньої ретельної аналітичної роботи та єдиної стратегії розбудови ІТ-архітектури компанії.
Іноді треба витратити кошти на попередній кваліфікований консалтинг, аби зрозуміти, чи потрібен узагалі певний ІТ-проект, і як його найкраще реалізувати. Думаю, що це забезпечило б успішніші та ефективніші проекти.
* SLA (Service Level Agreement) — угода про рівень сервісу між постачальником послуг і користувачем про кількісні та якісні характеристики наданих послуг, такі як їх доступність, підтримка користувачів, час виправлення несправності та інше.
