Источник: vc.ru, Брифинг как инвестиция. Внедряем интранет правильно.

Внедрение портала — процесс индивидуальный, опросника на все случаи жизни нет. Отталкиваясь от 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 в случае необходимости?

В качестве примера посмотрим на узкие места самых распространенных и «простых» интеграций.

Синхронизация с 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. Формализация решения, пригодного для презентации клиенту — структура, бизнес-логика портала, роли, основные функции, стек технологий, наброски интерфейсов, смета, релизы, дорожная карта и т.п. Перечень зависит от проекта.

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

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

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