Поради гендиректора компанії CUSTIS (розробка ІТ-систем) .

Оптимальна ситуація – коли замовник прагнути контролювати 100% експлуатації, 80% супроводу і 20% розвитку ІТ-системи.

«Замовні» і «готові» корпоративні системи не так очевидно один від одного відрізняються, як прийнято вважати. Для початку ми спробуємо з’ясувати, хто їх купує і для чого.

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

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

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

Угода дорожча за гроші

Реалізація великого проекту з високим ступенем кастомізації – дуже специфічний і зв’язаний з ризиками процес. Ризикованим є те, що замовнику і виконавцю може не вдатися домовиться про те, що конкретно потрібно зробити в рамках проекту. Часто підприємці описують завдання загальним чином, без дрібних деталей. А для ІТ-інженерії потрібно опис всіх необхідних подробиць і відсутність невизначеностей.

Виходячи з досвіду, ми можемо стверджувати, що в основі успішної реалізації проекту лежить домовленість про верхньому рівні ІТ-проектування – системної архітектурі. Необхідно спільне складання концептуального проекту системи – документа обсягом в 20-30 сторінок, чого достатньо навіть для великої системи – який замовник (і від бізнесу, і від ІТ) і виконавець розуміють однаково. Це і є системна архітектура проекту – рамкові домовленості про основні ступенях його волі. Така узгоджена архітектура набуває вигляду неокласичного контракту, тобто довгострокового договору в умовах невизначеності, коли всі наслідки угоди неможливо передбачати заздалегідь.

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

У Греції все є?

Існування узгодженої системної архітектури увазі, що вже вибраний прототип (продукт або платформа), на базі якого буде виконаний замовлений проект. В іншому випадку ІТ не зможе дати гарантію на завершення роботи. Час на внесення до прототип необхідних змін безпосередньо залежить від його розміру та складності. Наприклад, простіше побудувати завод на порожньому місці, ніж будувати його і одночасно ламати старий. Наступним чином, другий істотний ризик – правильний вибір прототипу проекту.

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

Варто зауважити, що поки що ми описували ситуацію в статиці. На практиці з часом змінюється і сама системна архітектура, і кількість потрібних доробок. Ми рекомендуємо при виборі прототипу керуватися гаслом «Нічого зайвого!», А не традиційним «У Греції все є!», Так як надлишок функцій проекту потрібно буде «протягнути» через всі зроблені доопрацювання.

Без людей немає ідей

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

Крім того, люди повинні бути орієнтовані на проект – вони зуміють створити архітектуру, яка оптимально «ляже» на інструмент, а це забезпечить майбутній системі розвиток одночасно з бізнесом. Співробітникам повинні бути цікаві нетривіальні завдання і новаторські ідеї.

Життя тільки починається

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

Лояльність слід розуміти в двох різних аспектах. Перший – чи готовий підрядник до швидкого виконання специфічних вимог клієнта. Така готовність сильно залежить від того, чи збирається виконавець тиражувати систему. Якщо він сильно зацікавлений в тиражуванні, то чи не стане охоче виконувати унікальні опції, які не будуть тиражуватися.

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

Найбільш лояльним є внутрішній ІТ-відділ підприємства. Трохи менший рівень лояльності – у дочірніх компаній, які контролюються замовником. Третій рівень лояльності – у невеликих компаній, які спеціалізуються на розробці під замовлення. Вони беруть на себе чіткі гарантійні зобов’язання працювати в інтересах замовника.

Другий критерій, за яким визначається надійність замовника – це проектна харизма, яка передбачає бажання працювати на результат і креативний підхід до виконання. Є зворотна залежність між рівнем лояльності та проектної харизмою. Рівень співпраці з найменшою лояльністю (розробка на замовлення у зовнішнього підрядника) забезпечує на ділі якісну роботу над проектом в довгостроковій перспективі, що робить його найбільш затребуваним. Впливає на це спеціалізація, постійна робота над поліпшенням проектних технологій, розвитком проектної культури, поліпшенням промислової якості інструментів, а також відсутність залученості в рутинні процеси. Проектування у великих організаціях загрожує затягуванням в операційну діяльність проектних працівників, і вони з великою ймовірністю підуть, втративши перспективу.

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

У сухому залишку

Спираючись на наш досвід по роботі з ІТ-системами, яким потрібен високий рівень кастомізації, ми сформулювали основні тези:

• Головний ризик такого проекту в тому, що може бути зроблено не те, що було потрібно. Цей ризик можна зняти за допомогою правильного ставлення всіх сторін до системної архітектурі проекту. Системна архітектура – це всі відповідальні домовленості, узгоджені між підприємством, його ІТ-структурою і підрядником, які зрозумілі підприємству і дозволяють ІТ-стороні дати гарантії реалізованості, термінів і бюджетів.
• У обумовлених проектах потрібно уважно стежити за мінімізацією обсягу системи. Кожен непотрібний функціонал буде серйозно гальмувати внесення змін до системи: чим більшою буде система, тим більше доведеться заплатити за доопрацювання.
• Ще один критичний чинник – віддаленість команди впровадження від авторів прототипу. Чим більше відстань між ними, тим гірше якість кінцевого результату і тим більше обсяг потрібних інженерних робіт, а це негативно позначиться на термінах і ціною проекту.
• Замовнику потрібно постаратися дістати контроль над 100% експлуатації, 80% супроводу і 20% розвитку системи. Практика показує, що це оптимальний варіант як для зниження ризиків, так і для зменшення витрат на ІТ.