В прошлом месяце мы рассказали о взаимоотношениях заказчика и подрядчика. Продолжаем рассуждением о брифинге, его составляющих, и обязанностях партнеров.
Внедрение портала — процесс индивидуальный, опросника на все случаи жизни нет. Отталкиваясь от N ответов на конкретные вопросы, понять боли, потребности и нужды заказчика невозможно. Есть только опыт, накопление знаний и умение погрузиться в бизнес клиента. Ниже Максим Щенников, коммерческий директор нашего интерактивного агентства, и Павел Мелдажис, ведущий специалист департамента корпоративных решений, опираясь на 15-летнюю практику, делятся личными наблюдениями, фидбеком и подводными камнями.
Следует уточнить, что ключевые аспекты и принципы брифинга никакого отношения к платформе реализации не имеют.
Процессы. Зачем вот это все?
Базисные процессы есть во всех компаниях: учет времени, лента новостей, телефонный справочник, сотрудники, о компании, документы, график отсутствий и так далее. Этот инструментарий корпоративного портала рабочий и в его настройке даже помощь подрядчика может быть не нужна. Однако нужно помнить, что функции портала — следствие из целей и задач внедрения. Про цели и задачи мы так или иначе говорили в первой статье — нужно понимать насколько клиент созрел для внедрения. Если он не дорос, как правило, мы слышим: «О, я хочу такой же инструмент!». А на вопросы: «Зачем? Как это облегчит работу? Есть ли надобность?» — ответ получить сложно.
«Спелый» заказчик что-то почитал, что-то знает про возможности, платформы и приходит с конкретными вопросами, а бывает и формализованными задачами: хотим автоматизировать Оценку 360 градусов, вот регламент, вот структура опроса. Это огромная редкость и плюс для внедренца.
Отдельная история — это индивидуальные процессы без формализованной постановки задачи. Наши партнеры, Фонд развития Дальнего Востока, пришли с задачей автоматизации сквозного процесса рассмотрения заявки. Необходимо переложить в IT-систему её путь, от подачи до поддержки живого проекта. Можно пойти двумя путями: долго-долго брифинговать каждого участника процесса или запросить регламенты. Первое трудозатратно для обеих сторон. Второго не может не быть в компании такого уровня. Ведь сотрудников как-то обучают, по определенным параметрам контролируют процесс ведения проектов.
В случае ФРДВ это была специальная политика, которая отражает путь проекта в Фонде. Мы её детально проанализировали, выделили реперные точки, задали вопросы на уточнение, провели несколько встреч с ответственными за разные процессы. В итоге сформировали решение для проекта.
Итак, что обсуждаем с клиентом?
- Процессы. Какие конкретно задачи должен решать портал. Это определяющий шаг в брифинге, от него строится дальнейшее погружение в бизнес клиента. Желание сделать эти процессы удобнее и легче — причина обращения в агентство.
- Регламенты. Как процессы работают здесь и сейчас, до внедрения. Попутно запрашиваем в компании реестры, уставы, любые описания того, что надо автоматизировать.
- Разочарования. Что в текущих процессах не устраивает. Определяем крупными вехами целевые (желаемые) бизнес-процессы и их отличие от текущих.
Функциональные модули. Как все должно работать?
Каждый бизнес-процесс ложится в основу отдельного функционального модуля, который предстоит создать разработчику.
В этом блоке вопросов исполнитель помогает клиенту предметно и подробно разобраться, как должен выглядеть целевой бизнес-процесс внутри портала, — какая функция и как будет его исполнять.
К сожалению или к радости не все процессы, которые происходят вживую, также происходят в IT. Доску почета в любом виде, — фотографии у входа, ежемесячная рассылка — перенести в IT просто, модуль имеет ту же форму.
Электронный документооборот и бумажный — принципы вроде одинаковые, но на практике отличаются. Мы сталкивались с тем, что заказчик представляет себе конкретную часть процесса и не смотрит на него целиком. Например, процедура согласования договора.
Этот процесс у всех сильно отличается изначально. Цепочка согласований в вакууме: договор надо согласовать с экономистами с юристами отправить руководителю он ставит визу.
Однако договоры не заключаются в вакууме и возникают сложности:
- Кто-то не поставил визу, на какой этап возвращается договор? На первый или остаётся на текущем?
- Как происходит взаимодействие с лицом, с которым заключается договор? С ним общается кто? Должен быть реестр.
- Уведомления посылаются лично или это автоматический режим?
- Внутреннее обсуждение требуется, есть ли какие-то лимиты (временные, тендерные, закупочные)?
- Требуется ли сохранять версионность документов?
- Параллельно ли согласование?
- Делегировать то, что сотруднику уже делегировали ранее, можно? Это автоматический процесс или сотрудник с температурой 40 должен зайти в портал и поставить галочку, что передает задачу? Или это компетенция администратора?
Для выяснения всех нюансов необходимо изучать прописанные регламенты и реальные практики.
Во многих подобных процессах масса заковырок, которые ставят в ступор заказчика. Задача агентства сразу задать точечные вопросы, рассказать о возможных сложностях.
Конечно, различные вариации одинаковых процессов, не говоря о кастомных автоматизациях, подрядчик, даже с миллионом проектов за плечами, знать не может. IT-агентство — не гуру металлургии, строительства, инвестиций.
Подробный предварительный анализ отдельных, наиболее важных функций поможет понять, говорите ли вы на одном языке и насколько заказчику интересен проект, готов ли он погружаться в разработку, болеть за неё и популяризовать проект в компании. Об этих аспектах мы говорили в прошлой статье.
Павел Мелдажис, ведущий специалист департамента корпоративных решений
Что обсуждаем в разговоре о функциях?
- Собственно функциональные модули. Какими инструментами должны решаться задачи. Набор и сложность функциональных модулей напрямую влияет на стоимость, длительность и сложность разработки.
- Подводные камни. Показываем варианты решения задач, объясняем потенциальную сложность различных вариантов реализации функций, если предвидим. Нехитрые на вид разделы и внедрения могут добавляться в состав просто так, без должного внимания. Задача агентства не научить, а обратить внимание на узкие места.
- И снова материалы. Находим существующие (и только!) описания процессов, инструкции, любые материалы, которые помогут понять мнимую или явственную сложность автоматизации.
Права доступа. Все ли стандартно?
HR во время брифинга спрашивает: «А как люди-то на портале появляются?». Это один из абсолютно банальных, но частых и важных вопросов.
В большинстве проектов вопрос решается интеграцией с AD клиента.
Вроде бы стандартная процедура. Есть стандартный шлюз. Но, как обычно, трудности возникают в процессе реализации. Кажущаяся простота интеграции сбивает с толку клиента. Важно пояснить, где могут возникнуть трудности и как их избежать. Например:
- Права доступа напрямую связаны с иерархией. В AD она не всегда правильная — нет двух подчиненностей. Иногда структура выгружается из 1С: ЗУП. В итоге из небольшой по сути задачи настройки доступов на портале вытекает две интеграции: учетные данные из AD, структура из 1С: ЗУП.
- Закрытые данные. В AD хранятся полные сведения о сотрудниках. Правила безопасности не позволяют открыть информацию в интернет. Иногда надо приезжать в офис клиента, сидеть в локальной сети и править структуру.
- Регламент прав доступа. Внутри портала за пользователем определенного уровня закреплен перечень доступных функций и документов. Матрица ролей рождается в больших спорах. Возникают ситуации, когда сотруднику нельзя иметь доступ, но он задействован в этом блоке на определенном этапе в маленькой роли и должен видеть только часть. Процесс такой настройки доступов нетривиальный.
Выдержка из матрицы ролей для одного из наших проектов.
Что еще обсуждаем?
- Пул групп пользователей с перечислением соответствующих доступов. Какие добавить, переименовать, где изменить права.
- Системы, аккумулирующие учетные записи сотрудников. Где лучше отображена иерархия, а где личные данные, с чем придется проводить интеграцию.
- Порядок в структуре AD. Для нужд компании создаются технические пользователи: принтер, условный секретарь. На портале же их быть не должно. Значит структуру надо выправлять. Кто будет это делать? Заказчик, например, руками либо подрядчик кодом.
- Передача данных. Готов ли клиент через защищенные веб-каналы передавать личную информацию.
IT-среда. С чем еще интегрироваться?
В части о правах доступа мы затронули вопрос о внедрении портала в общую IT-инфраструктуру компании. Однако инфраструктура это не только AD, это может быть SAP, всевозможные конфигурации 1С, LMS, калькуляторы на товары/услуги, самописные системы и прочее, и прочее. Интеграция с каждой из них — отдельная тема разговора во время брифинга с профильными специалистами со стороны клиента.
Что выясняем?
- Наличие систем, на которые может повлиять внедрение портала. Это могут быть системы, которые передадут часть своих функции. Например, проводники ОС доступа к локальным дискам трансформируются в дисковое «хранилище файлов» с возможностью отправлять коллегам и партнерам ссылки, ограниченные сроком действия и защищенные паролем.
- Есть ли то, что не устраивает в текущих системах? Что хочется переложить на плечи портала? Например, форум на устаревшем движке (да, они еще живут) переберется в «рабочие группы».
- Особняком стоит возможность интеграции с телефонией. Здесь требуется проговорить различные сценарии использования, начиная от CRM и заканчивая внутренним общением и заменой текущей АТС.
- Предоставление доступов к интегрируемым системам. Заказчик готов их предоставить или его специалисты организуют выгрузку нужных параметров для получения данных из систем клиента.
- Есть ли у клиента специалисты, готовые провести работы на стороне участвующих в интеграции систем или, как минимум, проконсультировать по текущей работе этих систем?
- Портал должен быть внутри локальной сети или возможен доступ снаружи (для использования задач, групп, мобильного приложения и т.д.)? Какие есть ограничения со стороны отдела информационной безопасности?
- Готовы ли специалисты клиента организовать серверную инфраструктуру по требованиям разработчика? Смогут ли организовать DMZ в случае необходимости?
Небольшая часть IT-инфраструктуры личного кабинета юридического лица одного из наших клиентов, которая отображает все элементы синхронизации для правильной работы с внешними системами.
В качестве примера посмотрим на узкие места самых распространенных и «простых» интеграций.
Синхронизация с MS Exchange
Есть Outlook — почта, календари с совместным пользованием, контакты, планировщик собраний, удобный незаменимый инструмент в больших компаниях. Exchange — сервер, где хранятся учетные записи сотрудников, а соответственно и все данные из Outlook.
Пересаживать сотрудников с Outlook на личные календари и почту на портале — плохая идея.
Довод первый. Outlook привычен. Программа закрывает все задачи, а дублирование функций в портале — лишнее время, усилия и деньги.
Довод второй. Возможность безболезненной и успешной синхронизации с Exchange сервером вопрос его версии. Интеграция с 13 и 16 версиями в принципе не поддерживается. Мы открыто говорим, что этот инструмент на портале не рабочий, нет четкого, устоявшегося регламента синхронизации.
Что обсуждаем?
- Версия Exchange. Возможно ли вообще провести интеграцию.
- Рациональность синхронизации. Синхронизация с личными календарями сотрудников из Exchange делает портал глобальным агрегатором рабочих инструментов. Но эта интеграция часто не обоснована в связи со своей сложностью и нерентабельностью для клиента.
- Предложить альтернативу. Некоторые задачи Outlook закрывают стандартные функции — модуль бронирования переговорных Битрикса, переписка в рамках рабочей группы, конкретной задачи, как аналог перегруженного общения по почте.
Интеграция с 1С
1C — гибкий и индивидуальный инструмент, который подстраивается под нужды компании. Встретить одинаково настроенные программы невозможно, никто не использует стандартную конфигурацию.
Возникает ситуация: для интеграции 1C с корпоративным порталом существует типовой модуль, но 1C уже не типовая и модуль не работает. Интеграция все еще возможна, но становится в разы сложней.
Путаницу вносит и обособленный характер обслуживания 1C. Интеграция проводится как на стороне портала, так и на стороне 1С. За исправное функционирование 1С, как правило, отвечает сторонняя компания, внутренний сотрудник, сотрудник на аутсорсе. Это всегда доступ к коммерческой информации. Изменения в 1С проводятся одними руками. Для IT-агентства это чужой огород и лезть туда неправильно, даже если у агентства в штате прекрасные одинэсники.
Следовательно, работы на стороне 1С должен проводить сам заказчик, что добавляет лишнюю ступень взаимодействия, усложняет процесс, увеличивается время интеграции.
И тут клиенту стоит задуматься нужно или нет. Не получится ли бессмысленного дублирования системы. Часто интеграция требуется для согласования счетов, договоров, выгрузки отчетности. Если процессов, завязанных на моментальном взаимодействии с 1C, в портал не заложено, то и сущности без надобности умножать не стоит.
Если мы работаем на базе 1С-Бирикс, Заказчик может возразить: «1C и 1C-Битрикс — одного поля компании, не может быть между ними сложностей». На самом деле ничего общего с технической точки зрения, между продуктами нет. Это абсолютно сторонние решения с различным набором модулей.
Что обсуждаем?
- Необходимость интеграции. Если портал — инструмент согласования, визирования счетов, договоров, то процедура интеграции имеет смысл. Это понятная задача для интернет-магазина, но спорная для интранета, которому не всегда первостепенно взаимодействие с финансовыми данными.
- Выгрузка данных. Готов ли клиент дать какой-либо доступ к 1С, либо он сам будет выгружать нужные поля из программы.
- Дополнительная разработка. Предупредить, что стандартный шлюз для передачи данных не применим в большинстве проектов, требуется его кастомизация.
Интерфейсы. Красоту будем наводить?
Первый контакт пользователя с порталом
Главная страница — первое впечатление, которое получат от портала пользователи. Если им непонятно, сложно, неудобно, то работа по внедрению портала может быть проделана зря.
Корпоративный инструмент не полетит, его забросят и не станут разбираться, потому что по старинке понятнее и быстрее. Конечно, удобный интерфейс лишь малая часть процесса внедрения в корпоративную культуру, но со своей отдельной ролью.
Формирование главной страницы — вопрос не только пользовательского опыта, юзабилити и навигации, но и задач бизнес-заказчиков:
- Почему блок нужно или не нужно выводить?
- Насколько глубоко должны быть спрятаны те или иные инструменты?
- Какие уведомления приоритетны?
Здесь можно отталкиваться от потребностей клиента. Нужен трекер задач — выводим, не нужно ничего, кроме новостей и телефонного справочника — действуем по той же схеме.
Что обсуждаем?
- Приоритетные инструменты. Стейкхолдеры должны быть хорошо знакомы с рутинной работой своих подчиненных, которая станет легче за счет грамотной структуры главной страницы.
- Гипотезы. Что должно стать пользовательской привычкой? Многие элементы прячут с целью не давить и упростить интерфейс — это нормально. Превращать интранет в 1С, где теряешься и не понимаешь, что делать — не практично. Пользуясь вордом ты же прекрасно понимаешь, что три черточки влево — выравнивание по левому краю, а три вправо — по правому. Пользователь работает в системе каждый день и привыкает к новым решениям быстро.
Брендирование
Ежедневно работать в пространстве, которое отражает фирменный стиль компании — поддержание корпоративного духа, культуры и немного гордость. Заказчики и подрядчики видят фирменный стиль по-разному. По факту:
- Изменить шрифты, подложку, добавить логотип — это простая история. Она не требует дополнительных расходов. Базовый уровень.
- Переместить, убрать, добавить блоки, виджеты, изменить модульную сетку — это уже другая история и тоже про дизайн. Продвинутый уровень.
Мы можем полностью видоизменить шаблон оформления от страницы авторизации до кнопки «ок» при создании задачи. Но всегда нужен ответ на вопрос: «А зачем?».
Одна из страниц корпоративного портала Первой грузовой компании. Для проекта не только изменены отдельные интерфейсы, но и поддерживается собственная дизайн-система.
Что обсуждаем?
- Важность и нужность. Для большей части клиентов редизайн — задача опциональна. Необходимой она становится для очень крупных компаний, где вопросы соответствия фирменному стилю прописаны и установлены.
- Брендбуки, гайдлайны, дизайн-системы. Есть ли хоть что-то у клиента? Если логотипа, слогана, символики, корпоративного цвета нет, — возвращаемся к первому пункту или советуем обратиться в брендинговое, маркетинговое агентство.
- Рамки стандартных визуальных изменений. Обозначить, что входит в базовый уровень визуального изменения портала.
- Тонкости и сложности глубокого редизайна.
Взаимодействие и подход к внедрению
На брифинг мы просим клиента позвать всех заинтересованных лиц: это инициаторы проекта, ЛПРы, проджект-менеджеры со стороны клиента, руководители отделов будущих пользователей — в зависимости от типа системы. Возможно, технари, если у них есть конкретное видение и специфичные требования к платформе, хотя мы и считаем, что первичны бизнес-задачи, а не технические ограничения.
Вопросы не про продукт. Они не менее важны и определяют не столько сам результат, сколько способ его достижения. Ответы помогают правильно организовать процесс, расставить приоритеты и спланировать взаимодействие, как на этапе реализации, так и на этапе подготовки решения.
Что обсуждаем?
- Бизнес-заказчиков в компании клиента. От кого исходит задача по внедрению корпоративного портала? Что, когда и с какой этапностью они хотят видеть в качестве бизнес-результата? Есть ли критерии успешности проекта?
- Причины внедрения. Что стало катализатором решения? Связано ли это с какими-либо KPI?
- Формирование бизнес-требований к порталу. Требуется ли помощь исполнителя в сборе обратной связи, формированию бизнес-требований к задачам, выработке бизнес-решений?
- Готовность клиента плотно и регулярно участвовать в процессах внедрения. В первую очередь, выделение отдельного менеджера или рабочей группы на стороне клиента, для реализации проекта. Не менее важно, регулярное участие всех бизнес-пользователей системы в принятии ключевых решений по проекту.
- Отделы, филиалы и департаменты. Задачи в подразделениях совпадают с задачами, которые планируют решать в центральном аппарате, или у них своё видение? Нужно ли его учитывать?
Стейкхолдеров у клиентов много, каждый либо тянет одеяло на себя либо не хочет принимать ответственность за решения. У них может не быть времени что-либо согласовывать, выработать единые инструменты. Агентство пытается их подружить и создать проект полезный для всех. - Негативный предыдущий опыт. Возможно клиент пытался запустить проект с другим подрядчиком — кто-то сказал, что работы на «три дня». Плюс заказчик хотел быстрого результата, ведь среднее по рынку (условно) и есть три дня. И получается никто не донес информацию про нюансы и длительный этап внедрения, а клиент разочаровался в инструменте, в подрядчике, в платформе.
- Дальнейшую эксплуатацию. Как клиент планирует поддерживать и развивать решение? Есть ли у него специалисты или сопровождение ляжет на плечи разработчика?
- Формальности. Сроки и порядок проведения процедур выбора исполнителя. Есть ли у клиента требования к проведению открытых конкурсов, тендеров на ЭТП или это обсуждаемо?
Роль подрядчика в проекте
Участие IT-агентства в проекте по внедрению корпоративного портала может протекать по-разному, в зависимости от потребностей, возможностей и готовности клиента.
На этапе брифинга важно понять какой из возможных вариантов наиболее оптимален для сторон и максимально быстро приведет к ожидаемому результату.
Агентство — только руки
Задачи могут формулироваться как клиентом, так и исполнителем. Тезисно процесс реализации отдельного блока задач (набора функций) выглядит традиционно:
- собираются бизнес-требования с бизнес-заказчиков;
- описываются и расставляются приоритеты;
- проектируются интерфейсы, составляется ТЗ;
- отрисовывается дизайн;
- запускается в реализацию (программирование);
- ввод в эксплуатацию, опытная эксплуатация и сбор обратной связи;
- агрегация следующих задач.
В данном подходе внедренец не является участником процесса формулирования бизнес-задач, оптимизации офлайновых бизнес-процессов и менеджером проекта в целом.
Агентство — еще и менеджер проекта
Агентство, берет на себя ответственность за организацию и взаимодействие с подразделениями клиента, всеми бизнес-заказчиками и пользователями проекта (включая клиентов заказчика), отвечает на вопросы, решает сложности внедрения. Вместе с клиентом стратегически планирует и развивает проект в первую очередь в разрезе внедрения в процессы компании, а не только с точки зрения разработки конкретных функций.
Так много общения и все бесплатно?
С точки зрения стратегии запуска проекта, процесс брифинга нужен для формирования первичного, концептуального решения реализации. Такое решение позволит:
- Определить есть ли точки соприкосновения и понимания между миром исполнителя и миром заказчика. Готовы ли вы работать в одной команде.
- Оценить проект по важным для сделки и дальнейшей реализации параметрам в целом: стек технологий, стоимость, сроки, риски, условия сотрудничества.
- Определить, конкретизировать и заключить сделку по конкретному первому этапу на пути внедрения для первого блока функций.
Насколько глубоко копать и когда остановиться, каждый разработчик решает сам. В зависимости от своих возможностей, компетенций и интересу к клиенту, проекту в целом. Кто-то готов инвестировать в проект свои ресурсы на безвозвратной основе, кто-то сразу же просит оплаты за пресейл, кто-то переносит стоимость работ по подготовке в первый этап работ по проекту (в открытую или закрытую).
Чем более глубокое, продуманное и привлекательное предложение хотим сделать клиенту — тем больше общаемся, больше сотрудничаем командами, больше получаем на выходе результатов, которые не только показывают компетенцию исполнителя, но и представляют для клиента конкретную ценность. Как правило, двух-четырех встреч для первичного сбора информации по большой, многофункциональной системе достаточно.
Максим Щенников, коммерческий директор
Напоследок еще несколько очевидных, но важных принципов, как для клиента, так и для исполнителя:
- Брифинговать только устно, чаще общаться.
- На встречах от клиента недостаточно одного специалиста, даже если это IT-директор. Должны присутствовать руководители всех отделов, на чью работу влияет портал.
- Стратегические и бизнес-вопросы обсуждать на брифинге, на конкретные вопросы про технологии, интеграции и т.д. — отвечать в переписке.
- Не гнаться за детальным проектированием. Когда мы формируем решение, то прекрасно понимаем, что этап подготовки проектной документации уточнит все специфические тонкости бизнеса клиента.
- Относиться к формированию решения на пресейле и брифингу в частности, как к отдельному проекту. Управлять сроками, рисками, коммуникацией. Одним словом — аккаунтить.
Что дальше?
Клиент отправляется ждать презентации предварительного решения от агентства. Исполнитель переходит на этап дополнения информации и собственно выработки решения:
- Аккумуляция и обработка собранных данных, уточнение технических моментов. Брать на каждую встречу технического специалиста не всегда рационально. На точные вопросы надо получать такие же точные ответы в формализованном виде.
- Встречи рабочей группы для формирования и утверждения решения, разработка схемы движения по проекту (методология внедрения, в каком виде реализовывать, стоимость, сроки).
- Формализация решения, пригодного для презентации клиенту — структура, бизнес-логика портала, роли, основные функции, стек технологий, наброски интерфейсов, смета, релизы, дорожная карта и т.п. Перечень зависит от проекта.
***
Процесс брифинга, который мы в общих чертах описали, снимает риски непонимания на этапах непосредственной реализации проекта. Когда клиент уже платит деньги разногласия опаснее и больнее для обеих сторон. А брифинг — идеальная возможность поработать друг с другом.
Агентство оценивает подход клиента, заинтересованность, компетентность, реальность запросов.
Заказчик испытывает подрядчика, готов ли он окунуться в его бизнес-процессы, копает ли он глубже, чем перечень возможностей корпоративного портала в штатной конфигурации.
