Брифінг як інвестиція. Впроваджуємо інтранет правильно

В минулому місяці ми розповіли про взаємовідносини замовника і підрядника. Продовжуємо міркуванням про брифінгу, його складових, і обов’язки партнерів.

Впровадження порталу — процес індивідуальний, опитувальника на всі випадки життя немає. Відштовхуючись від N відповідей на конкретні питання, зрозуміти болю, потреби і потреби замовника неможливо. Є тільки досвід, накопичення знань та вміння зануритися у бізнес клієнта. Нижче Максим Щенников, комерційний директор інтерактивного агентства AREALIDEA, і Павло Мелдажис, провідний спеціаліст департаменту корпоративних рішень, спираючись на 15-річну практику, діляться особистими спостереженнями, фідбеком і підводними каменями.

Слід уточнити, що ключові аспекти та принципи брифінгу ніякого відношення до платформи реалізації не мають.

Процеси. Навіщо ось це все?

Базисні процеси є у всіх компаніях: облік часу, стрічка новин, телефонний довідник, співробітники, про компанії, документи, графік відсутностей і так далі. Цей інструментарій корпоративного порталу робочий і в його налаштуванні навіть допомогу підрядника може бути не потрібна. Однак потрібно пам’ятати, що функції порталу — наслідок з цілей і завдань впровадження. Про цілі та завдання ми так чи інакше говорили в першій статті, — потрібно розуміти наскільки клієнт дозрів для впровадження. Якщо він не доріс, як правило, ми чуємо: «О, я хочу такий же інструмент!». А на питання: «Навіщо? Як це полегшить роботу? Є потреба?» — відповідь отримати складно.

«Стиглий» замовник щось почитав, що знає про можливості платформи і приходить з конкретними питаннями, а буває і формалізованими завданнями: хочемо автоматизувати Оцінку 360 градусів, ось регламент, от структура опитування. Це величезна рідкість і плюс для впроваджувача.

Окрема історія — це індивідуальні процеси без формалізованої постановки завдання. Наші партнери, Фонд розвитку Далекого Сходу, прийшли із завданням автоматизації наскрізного процесу розгляду заявки. Необхідно перекласти в IT-систему її шлях від подання до підтримки живого проекту. Можна піти двома шляхами: довго-довго брифинговать кожного учасника процесу або запитати регламенти. Перше трудомістко для обох сторін. Другого не може не бути в компанії такого рівня. Адже співробітників якось навчають, за певними параметрами контролюють процес ведення проектів.

У разі ФРДВ це була спеціальна політика, яка відображає шлях проекту у Фонді. Ми детально проаналізували, виділили реперні точки, задали питання на уточнення, провели кілька зустрічей з відповідальними за різні процеси. У підсумку сформували рішення для проекту.

Отже, що обговорюємо з клієнтом?

1. Процеси. Які конкретно завдання повинен вирішувати портал. Це визначальний крок у брифінгу, від нього будується подальше занурення в бізнес клієнта. Бажання зробити ці процеси зручніше і легше — причина звернення в агентство.
2. Регламенти. Як процеси працюють тут і зараз, до впровадження. Принагідно просимо в компанії реєстри, статути, будь-які описи того, що треба автоматизувати.
3. Розчарування. Що у поточних процесах не влаштовує. Визначаємо великими віхами цільові (бажані) бізнес-процеси та їх відмінність від поточних.

Функціональні модулі. Як все повинно працювати?

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

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

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

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

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

Однак договори не укладаються у вакуумі і виникають складності:

1. Хтось не поставив візу, на який етап повертається договір? На перший або залишається на поточному?
2. Як відбувається взаємодія з особою, з яким укладається договір? З ним спілкується хто? Повинен бути реєстр.
3. Повідомлення надсилаються особисто або це автоматичний режим?
4. Внутрішнє обговорення потрібно, чи є якісь ліміти (тимчасові, тендерні, закупівельні)?
5. Потрібно зберігати версійність документів?
6. Паралельно узгодження?
7. Делегувати те, що співробітнику вже делегували раніше, можна? Це автоматичний процес або співробітник з температурою 40 повинен зайти в портал і поставити галочку, що передає завдання? Або це компетенція адміністратора?

Для з’ясування всіх нюансів необхідно вивчати прописані регламенти і реальні практики.

У багатьох подібних процесах маса заковырок, які ставлять в ступор замовника. Завдання агентства відразу задати точкові питання, розповісти про можливі складнощі.

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

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

Що обговорюємо в розмові про функції?

1. Власне функціональні модулі. Якими інструментами повинні вирішуватися завдання. Набір і складність функціональних модулів безпосередньо впливає на вартість, тривалість і складність розробки.
2. Підводні камені. Показуємо варіанти вирішення завдань, пояснюємо потенційну складність різних варіантів реалізації функцій, якщо передбачаємо. Прості на вид розділи та впровадження можуть додаватися до складу просто так, без належної уваги. Завдання агентства не навчити, а звернути увагу на вузькі місця.
3. І знову матеріали. Знаходимо існуючі (і тільки!) опису процесів, інструкції, будь-які матеріали, які допоможуть зрозуміти уявну або виразну складність автоматизації.

Права доступу. Все стандартно?

HR під час брифінгу запитує: «А як люди на порталі з’являються?». Це один з абсолютно банальних, але частих і важливих питань.

У більшості проектів питання вирішується інтеграцією з AD клієнта.

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

1. Права доступу безпосередньо пов’язані з ієрархією. У AD вона не завжди правильна — немає двох підпорядкування. Іноді структура вивантажується з 1С: ЗУП. У підсумку з невеликої по суті задачі налаштування доступів на порталі випливає дві інтеграції: облікові дані з AD, структура з 1С: ЗУП.
2. Закриті дані. У AD зберігаються повні відомості про співробітників. Правила безпеки не дозволяють відкрити інформацію в інтернет. Іноді треба приїжджати в офіс клієнта, сидіти в локальній мережі і правити структуру.
3. Регламент прав доступу. Всередині порталу за користувачем певного рівня закріплено перелік доступних функцій і документів. Матриця ролей народжується у великих суперечках. Виникають ситуації, коли співробітнику не можна мати доступ, але він задіяний у цьому блоці на певному етапі в маленькій ролі і повинен бачити тільки частину. Такий процес налаштування доступів нетривіальний.

Витяг з матриці ролей для одного з наших проектів.

Що ще обговорюємо?

1. Пул груп користувачів з перерахуванням відповідних доступів. Будь додати, перейменувати, де змінити права.
2. Системи, що акумулюють облікові записи співробітників. Де краще відображена ієрархія, а де особисті дані, з чим доведеться проводити інтеграцію.
3. Порядок в структурі AD. Для потреб компанії створюються технічні користувачі: принтер, умовний секретар. На порталі ж їх бути не повинно. Значить структуру треба виправляти. Хто буде це робити? Замовник, наприклад, руками або підрядник кодом.
4. Передача даних. Готовий клієнт через захищені канали передавати особисту інформацію.

IT-середовище. З чим ще інтегруватися?

У частині про права доступу ми порушили питання про запровадження порталу в загальну IT-інфраструктуру компанії. Однак інфраструктура це не тільки AD, це може бути SAP, всілякі конфігурації 1С, LMS, калькулятори на товари/послуги, самописні системи та інше, та інше. Інтеграція з кожної з них — окрема тема розмови під час брифінгу з профільними фахівцями з боку клієнта.

Що з’ясовуємо?

1. Наявність систем, на які може вплинути впровадження порталу. Це можуть бути системи, які передадуть частину своїх функції. Наприклад, провідники ОС доступу до локальних дисків трансформуються у дисковий «сховище файлів» з можливістю відправляти колегам і партнерам посилання, обмежені терміном дії і захищені паролем.
2. Є те, що не влаштовує в поточних системах? Що хочеться перекласти на плечі порталу? Наприклад, форум на застарілому движку (так, вони ще живуть) перебереться в «робочі групи».
3. Осібно стоїть можливість інтеграцію з телефонією. Тут потрібно проговорити різні сценарії використання, починаючи від CRM і закінчуючи внутрішнім спілкуванням і заміною поточної АТС.
4. Надання доступів до интегрируемым систем. Замовник готовий їх надати чи його фахівці організовують вивантаження потрібних параметрів для отримання даних з систем клієнта.
5. Чи є у клієнта фахівці, готові провести роботи на стороні беруть участь в інтеграції систем або, як мінімум, проконсультувати по поточній роботі цих систем?
6. Портал повинен бути всередині локальної мережі або можливий доступ зовні (для використання завдань, груп, мобільного додатка тощо)? Які є обмеження з боку відділу інформаційної безпеки?
7. Готові фахівці клієнта організувати серверну інфраструктуру по вимогам розробника? Чи зможуть організувати DMZ у разі необхідності?

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

В якості прикладу подивимося на вузькі місця найпоширеніших і «простих» інтеграцій.

Синхронізація з MS Exchange

Є Outlook, пошта, календарі з спільним користуванням, контакти, планувальник зборів, зручний незамінний інструмент у великих компаніях. Exchange — сервер, де зберігаються облікові записи співробітників, а відповідно і всі дані з Outlook.

Пересаджувати співробітників з Outlook особисті календарі і пошту на порталі — погана ідея.

Аргумент перший. Outlook звичний. Програма закриває всі завдання, а дублювання функцій в порталі — зайвий час, зусилля і гроші.

Аргумент другий. Можливість безболісної та успішної синхронізації з сервером Exchange питання його версії. Інтеграція з 13 і 16 версіями в принципі не підтримується. Ми відкрито говоримо, що цей інструмент на порталі не робочий, немає чіткого, усталеного регламенту синхронізації.

Що обговорюємо?

1. Версія Exchange. Можливо взагалі провести інтеграцію.
2. Раціональність синхронізації. Синхронізація з особистими календарями співробітників Exchange робить портал глобальним агрегатором робочих інструментів. Але ця інтеграція часто не обґрунтовано в зв’язку з своєю складністю і нерентабельністю для клієнта.
3. Запропонувати альтернативу. Деякі завдання Outlook закривають стандартні функції — модуль бронювання переговорних Битрикса, листування в рамках робочої групи, конкретної задачі, як аналог перевантаженого спілкування по пошті.

Інтеграція з 1С

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

Виникає ситуація: для інтеграції 1C з корпоративним порталом існує типовий модуль, але 1C вже не типова і модуль не працює. Інтеграція все ще можлива, але стає в рази складніше.

Плутанину вносить і відособлений характер обслуговування 1C. Інтеграція проводиться як на стороні порталу, так і на стороні 1С. За справне функціонування 1С, як правило, відповідає стороння компанія, внутрішній співробітник, співробітник на аутсорсе. Це завжди доступ до комерційної інформації. Зміни в 1С проводяться одними руками. Для IT-агентства це чужий город і лізти туди неправильно, навіть якщо у агентства в штаті прекрасні одинэсники.

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

І тут клієнтові варто задуматися потрібно чи ні. Не вийде безглуздого дублювання системи. Часто інтеграція потрібна для узгодження рахунків, договорів, вивантаження звітності. Якщо процесів, зав’язаних на моментальному взаємодії з 1C, портал не закладено, то і сутності без потреби множити не варто.

Якщо ми працюємо на базі 1С-Бирикс, Замовник може заперечити: «1C і 1C-Бітрікс — одного поля компанії, не може бути між ними складнощів». Насправді нічого спільного з технічної точки зору, між продуктами немає. Це абсолютно сторонні рішення з різним набором модулів.

Що обговорюємо?

1. Необхідність інтеграції. Якщо портал — інструмент погодження, візування рахунків, договорів, то процедура інтеграції має сенс. Це зрозуміла завдання для інтернет-магазину, але спірна для інтранету, якому не завжди першочергово взаємодію з фінансовими даними.
2. Вивантаження даних. Готовий клієнт дати якийсь доступ до 1С, або він сам буде вивантажувати потрібні поля з програми.
3. Додаткова розробка. Попередити, що стандартний шлюз для передачі даних не застосовується в більшості проектів, потрібно його кастомізація.

Інтерфейси. Красу будемо наводити?

Перший контакт користувача з порталом

Головна сторінка — перше враження, яке отримають від порталу користувачі. Якщо їм незрозуміло, важко, незручно, то робота по впровадженню порталу може бути виконана даремно.

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

Формування головної сторінки — питання не тільки користувальницького досвіду, юзабіліті і навігації, але і завдань бізнес-замовників:

1. Чому блок потрібно чи не потрібно виводити?
2. Наскільки глибоко повинні бути заховані ті чи інші інструменти?
3. Які повідомлення пріоритетні?

Тут можна відштовхуватись від потреб клієнта. Потрібен трекер завдань — виводимо, не потрібно нічого, крім новин і телефонного довідника — діємо за тією ж схемою.

Що обговорюємо?

1. Пріоритетні інструменти. Стейкхолдери повинні бути добре знайомі з рутинною роботою своїх підлеглих, яка стане легше за рахунок грамотної структури головної сторінки.
2. Гіпотези. Що має стати користувача звичкою? Багато елементи ховають з метою не тиснути і спростити інтерфейс — це нормально. Перетворювати інтранет в 1С, де губишся і не розумієш, що робити — не практично. Користуючись ворд ти ж прекрасно розумієш, що три рисочки вліво — вирівнювання по лівому краю, а три вправо — по правому. Користувач працює в системі кожен день і звикає до нових рішень швидко.

Брендування

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

1. Змінити шрифти, підкладку, додати логотип — це проста історія. Вона не вимагає додаткових витрат. Базовий рівень.
2. Перемістити, видалити, додати блоки, віджети, змінити модульну сітку — це вже інша історія і теж про дизайн. Просунутий рівень.

Ми можемо повністю видозмінити шаблон оформлення сторінки авторизації до кнопки «ок» при створенні завдання. Але завжди потрібна відповідь на питання: «А навіщо?».

Одна з сторінок корпоративного порталу Першої вантажної компанії. Для проекту не тільки змінені окремі інтерфейси, але і підтримується власна дизайн-система.

Що обговорюємо?

1. Важливість і потрібність. Для більшої частини клієнтів редизайн — завдання опціональна. Необхідною вона стає для дуже великих компаній, де питання відповідності фірмовому стилю прописані і встановлені.
2. Брендбук, гайдлайны, дизайн-системи. Чи є хоч щось у клієнта? Якщо логотипу, слогану, символіки, корпоративного кольору немає, — повертаємося до першого пункту або радимо звернутися до брендингове, маркетингове агентство.
3. Рамки стандартних візуальних змін. Позначити, що входить в базовий рівень візуального зміни порталу.
4. Тонкощі і складнощі глибокого редизайну.

Взаємодія і підхід до впровадження

На брифінг ми просимо клієнта покликати всіх зацікавлених осіб: це ініціатори проекту, ЛПРы, проджект-менеджери з боку клієнта, керівники відділів майбутніх користувачів — в залежності від типу системи. Можливо, технарі, якщо у них є конкретне бачення і специфічні вимоги до платформи, хоча ми і вважаємо, що первинні бізнес-задачі, а не технічні обмеження.

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

Що обговорюємо?

1. Бізнес-замовників в компанії клієнта. Від кого виходить завдання щодо впровадження корпоративного порталу? Що, коли і з якою етапністю вони хочуть бачити в якості бізнес-результату? Чи є критерії успішності проекту?
2. Причини впровадження. Що стало каталізатором рішення? Це пов’язано з якими-небудь KPI?
3. Формування бізнес-вимог до порталу. Потрібна допомога виконавця в зборі зворотного зв’язку, формування бізнес-вимог до завдань, вироблення бізнес-рішень?
4. Готовність клієнта щільно і регулярно брати участь у процесах впровадження. В першу чергу, виділення окремого менеджера чи робочої групи на стороні клієнта, для реалізації проекту. Не менш важливо, регулярна участь всіх бізнес-користувачів системи у прийнятті ключових рішень за проектом.
5. Відділи, філіали і департаменти. Завдання у підрозділах збігаються з завданнями, які планується вирішувати у центральному апараті, або у них своє бачення? Чи слід його враховувати?
   Стейкхолдерів у клієнтів багато, або кожен тягне ковдру на себе або не хоче брати відповідальність за рішення. У них може не бути часу щось погоджувати, виробити єдині інструменти. Агентство намагається їх подружити і створити проект корисний для всіх.
6. Негативний попередній досвід. Можливо клієнт намагався запустити проект з іншим підрядником — хтось сказав, що роботи на «три дні». Плюс замовник хотів швидкого результату, адже середня по ринку (умовно) і є три дні. І виходить ніхто не доніс інформацію про нюанси та тривалий етап впровадження, а клієнт розчарувався в інструменті, у підряднику, в платформі.
7. Подальшу експлуатацію. Як клієнт планує підтримувати і розвивати рішення? Є у нього фахівці або супровід ляже на плечі розробника?
8. Формальності. Строки і порядок проведення процедури вибору виконавця. Чи є у клієнта вимоги до проведення відкритих конкурсів, тендерів на ЕТП або це обсуждаемо?

Роль підрядника у проекті

Участь IT-агентства у проекті із впровадження корпоративного порталу може протікати по-різному, в залежності від потреб, можливостей і готовності клієнта.
На етапі брифінгу важливо зрозуміти, який із можливих варіантів найбільш оптимальним для сторін і максимально швидко призведе до очікуваного результату.

Агентство — тільки руки

Завдання можуть формулюватися як замовником, так і виконавцем. Тезисно процес реалізації окремого блоку завдань (набору функцій) виглядає традиційно:

• збираються бізнес-вимоги до бізнес-замовників;
• описуються і розставляються пріоритети;
• проектуються інтерфейси, складається ТЗ;
• отрісовиваємих дизайн;
• запускається у реалізацію (програмування);
• введення в експлуатацію, дослідна експлуатація та збір зворотного зв’язку;
• агрегація наступних завдань.

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

Агентство — ще і менеджер проекту

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

Так багато спілкування і все безкоштовно?

З точки зору стратегії запуску проекту, процес брифінгу потрібен для формування первинного, концептуального рішення реалізації. Таке рішення дозволить:

1. Визначити чи є точки дотику і розуміння між світом виконавця і світом замовника. Чи готові ви працювати в одній команді.
2. Оцінити проект з важливим для угоди і подальшої реалізації параметрами в цілому: стек технологій, вартість, терміни, ризики, умови співробітництва.
3. Визначити, конкретизувати та укласти угоду з конкретного першого етапу на шляху впровадження для першого блоку функцій.

Наскільки глибоко копати і коли зупинитися, кожен розробник вирішує сам. У залежності від своїх можливостей, компетенцій і інтересом до клієнта, проекту в цілому. Хтось готовий інвестувати в проект свої ресурси на безповоротній основі, хтось відразу ж просить оплати за пресейл, хтось переносить вартість робіт з підготовки до першого етапу робіт за проектом (у відкриту або закриту).

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

Наостанок ще кілька очевидних, але важливих принципів, як для клієнта, так і для виконавця:

1. Брифинговать тільки усно, частіше спілкуватися.
2. На зустрічах від клієнта недостатньо одного фахівця, навіть якщо це IT-директор. Повинні бути присутні керівники всіх відділів, на чию роботу впливає портал.
3. Стратегічні і бізнес-питання обговорювати на брифінгу, на конкретні питання про технології, інтеграції і т. д. — відповідати в листуванні.
4. Не гнатися за детальним проектуванням. Коли ми формуємо рішення, то прекрасно розуміємо, що етап підготовки проектної документації уточнить всі специфічні тонкощі бізнесу клієнта.
5. Ставитися до формування рішення на пресейле та брифінгу зокрема, як до окремого проекту. Управляти строками, ризиками, комунікацією. Одним словом — аккаунтить.

Що далі?

Клієнт відправляється чекати презентації попереднього рішення від агентства. Виконавець переходить на етап доповнення інформації і власне вироблення рішення:

1. Акумуляція і обробка зібраних даних, уточнення технічних моментів. Брати на кожну зустріч технічного фахівця не завжди раціонально. На точні питання треба отримувати такі ж точні відповіді у формалізованому вигляді.
2. Зустрічі робочої групи для формування і затвердження рішення, розробка схеми руху за проектом (методологія впровадження, в якому вигляді реалізовувати, вартість, терміни).
3. Формалізація рішення, придатного для презентації клієнту — структура, бізнес-логіка порталу, ролі, основні функції, стек технологій, начерки інтерфейсів, кошторис, релізи, дорожня карта і т. п. Перелік залежить від проекту.

***

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

Агентство оцінює підхід клієнта, зацікавленість, компетентність, реальність запитів.

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