Зрозуміло, що через деякий час такий виконавець подучит матчастину, навчиться нормально спілкуватися з клієнтами і звертати увагу на їх побажання та прохання. Або вилетить з ринку. Але поки це станеться, кілька жертв залишаться один на один з незрозумілими папірцями, - у яких, до речі, може і не виявитися потрібних відповідей. Найприкріше, що в Росії збільшення витрат на проект не означає поліпшення якості. Розмір IT-компанії - теж не завжди гарантія високої якості. Буквально - як пощастить.
Вітрини IT-контор підозріло схожі. Ніхто хамити на перших зустрічах не стане, схеми розумні покажуть, різні графіки. Потім, отримавши замовлення, одні просто розслабитися, інші зроблять «що-небудь», і лише треті дійсно зрозуміють, чого потрібно замовнику, та ще подбають про результат. І як же вибирати партнера по автоматизації?
Три гарні прикмети при виборі IT-підрядника
Перш за все, щоб не стати учасником бесід, схожих на недобрі анекдоти, замовник повинен підготуватися:
Усвідомити поточну ситуацію;
Зрозуміти, що саме хочеться змінити;
Оцінити, як ці зміни позначаться на суміжних бізнес-процесах, підрозділах, конкретних співробітників, клієнтів;
Сформулювати задачу.
Це здається настільки банальним, що ніяково навіть згадувати. Тим не менш, найбільший ризик багатьох вітчизняних IT-проектів полягає в тому, що постановкою задачі починають займатися не на нульовому, підготовчому етапі - а де-небудь після оплати товарів/послуг підрядника, впровадження, навчання, доопрацювань, і раптом (несподівано, завжди інтрига) з'ясовується, що це зовсім не те. Чи не тієї якості. Чи погано інтегрується з вже використовуваним софтом.
Перша хороша прикмета - завдання сформульована заздалегідь, чітко, однозначно, і ні в якому разі не ізольовано, а з урахуванням бізнес-процесів компанії і вектора її розвитку. На цій стадії дуже знадобиться думка не тільки спеціалістів замовника, але і IT-компанії. Тому що бізнес знає (повинен знати, принаймні) свої реальні потреби, але далеко не завжди адекватно оцінює рішення. Перегини можливі в обидві сторони.
Багато замовники шукають «чарівну кнопку», одноразове натискання якої призведе їх до вічного процвітання. Зате інші переоцінюють складність, не вірять в те, що взагалі це можна зробити, тим більш швидко і в рамках бюджету. Обговорення з IT-спеціалістами потрібно для уточнення «берегів», прояснення очікувань. Бажано не обмежуватись одним і навіть кількома думками. Як раз зараз, наприклад, ми завершили проект, який інший місцевий виконавець вважав неможливим».
На верхньому рівні деталізації завдання повинна бути пов'язана з бізнес-інтересами компанії замовника. Наприклад:
Утримати існуючих клієнтів;
Контролювати виробництво;
Підвищувати ефективність;
Прояснити собівартість;
Збільшити прозорість таких бізнес-процесів.
На нижньому рівні деталізації завдання повинна бути виражена в термінах, від яких легко перейти до вибору конкретних рішень. Наприклад:
Створити систему лояльності;
Автоматизувати контроль якості продукції;
Впровадити систему ключових показників;
Деталізувати фінансову звітність;
Розвинути документообіг з певними выгрузками.
Зауважте, що спочатку мова необов'язково йде про детально проработанном плані. Технічне завдання (ТЗ) потрібно, зрозуміло, але його наявність - це вже друга хороша прикмета. Тому що ТЗ найважливіше, воно вирішує все. ТЗ може бути на листку паперу з п'яти пунктів (у разі впровадження існуючих прикладних програм) або мати вигляд багатосторінкового тексту, в якому враховані всі дрібниці, аж до схеми укладання проводів по Фен-Шую. Технічне завдання дозволяє прояснити і синхронізувати взаєморозуміння учасників, вони чітко бачать єдину кінцеву мету. Відповідно, тільки на підставі ТЗ можна визначити й кінцеву вартість проекту.
До речі, якісна розробка ТЗ становить відчутну частину цієї вартості. В залежності від складності, технічне завдання «важить» від 10 до 40% бюджету проекту! Багато управлінців в Росії вперто відмовляються розуміти цей факт. Точніше, не виходить донести його до замовників досить твердо, щоб перейти від сумних зітхань крадькома до нормальної, загальносвітовій практиці - і рентабельності, відповідно, а також ризик-менеджменту.
Ще один важливий момент: не можна доручати IT-фахівцям розробку ТЗ «цілком». Інакше система наповниться безліччю функцій, які здаються програмістам просто необхідними, але кінцевими користувачами використовуватися не будуть. IT-фахівці - власні і запрошені з боку постачальника IT-рішення - обов'язково повинні брати участь у розробці ТЗ. Вони повинні відстежити і попередити проблеми сумісності, граничних навантажень, кількості користувачів та інших обмежень, нарешті, допомогти записати в термінах, однозначно зрозумілі фахівцям, які будуть розробляти і впроваджувати. На перший погляд здається, що функціональний склад рішення - теж територія компетенції розробників. Але насправді це не зовсім так. Тут повинні попрацювати й «айтішники», і менеджери замовника - щоб домовитися про конкретику, реалізованості, корисності і витрат.
Є дуже просте правило: все, що не враховано в ТЗ, буде оплачуватися окремо і виконуватися додаткові терміни. Досить подумати про це з такої точки зору, щоб зрозуміти - замовник нітрохи не менше виконавця зацікавлений в якісному технічному завданні.
Залишилося подбати про те, щоб у наявності була третя гарна прикмета. Коротко вона звучить так: знайдіть правильного підрядника і контролюйте його дії. Трохи докладніше:
1) Відразу немає будь-яких рішень, прив'язаним до розробників-индивидуалистам. Тому що вони хворіють, переїжджають, нахабніють, йдуть в армію, загул або депресію - іншими словами, з ними може статися все, що завгодно. Серйозний проект можуть добре реалізувати компанії з досвідом. Аргументів на користь такого висновку багато, його підтверджують практично всі наступні пункти цього списку.
2) Підрядник повинен володіти практичним досвідом - успішним, зрозуміло, та строго по даній ніші. Наприклад, компанія «1С:Франчайзі» за багаторічний досвід впроваджень і підтримки різних продуктів може жодного разу не зіткнутися з 1С:CRM. При зверненні клієнт з великою ймовірністю отримає запевнення в тому, що все буде чудово - але шанси на успіх в реальності досить низькі. Можливо, в штаті підрядника взагалі не виявиться фахівців з потрібними знаннями. Проект, звичайно, завершать. З якою якістю - питання. Проблеми будуть, не сумнівайтеся. Всього наперед не прорахувати, та це і не потрібно. Головне, адекватно оцінити бюджет і терміни, взяти хороший запас і передати оперативне управління фахівцям.
3) Обов'язкова регулярна, навіть часта звітність та уточнення поточних результатів. Не заради бюрократії і не для вчинення розборок - а щоб тримати підрядника в тонусі і самим краще розуміти коригування побажань. Краще раз в день, тиждень, місяць або квартал (залежно від масштабу проекту) обговорювати, що йде не так, і знаходити нові рішення, ніж один раз за підсумками усвідомити зрив і неможливість вже що-небудь виправити.
4) Здана і прийнята інформаційна система - це не просто програмний код, який працює на комп'ютерах, а інструменти, які відповідають бізнес-процесів компанії, зрозумілі працівникам і перевірені в дії. Впровадження без навчання - гроші на вітер.
5) Крім того, моральне старіння системи почнеться рівно в той момент, коли стартує промислова експлуатація. Тому оновлення повинні входити в комплект, і це правило поширюється на інформаційну підтримку теж. Неминуче будуть потрібні ще й доопрацювання за вашим власним новим вимогам - швидше за все, задовго до завершення впровадження, і потім ще неодноразово. Це теж потрібно відобразити в бюджеті, а також враховувати при виборі підрядника.
Отже
Резюмуючи, хочеться порадити - підходьте до справи без зайвих ілюзій, але і без надмірної параної. Перехід на новий IT-рішення вимагатиме більше ресурсів і часу, ніж можна припустити без досвіду впроваджень. Але це окупається. Сучасний бізнес неможливий без IT. Він в значній мірі складається з програмного забезпечення, комунікацій, різних продуктів і сервісів. Це динамічна, неспокійна і слабо прогнозована середовище. Тим не менш, вона дає унікальні переваги, які іншими способами ніяк не забезпечити.
Велика частина IT-інструментів - західні технології. Багато «кращі практики», які містять ці рішення також західні, і на вітчизняний бізнес-ландшафт лягають не дуже гладко. Тому їх краще не сліпо копіювати, а використовувати в якості основи, адаптуючи під місцеві особливості і завдання. Тоді російська «неохота», в якій часто грузнуть чужоземні інформаційні комбайни, з фактора ризику перейде в категорію корисного скептичного ставлення до новинок. Використовуйте її на повну котушку при постановці завдання та виборі рішень. А потім наполегливо досягайте результатів - і вони обов'язково будуть.