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

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

Следует уточнить. Речь пойдет преимущественно о порталах на Битрикс24. Однако ключевые аспекты и принципы брифинга никакого отношения к платформе не имеют.

Базисные процессы есть во всех компаниях: учет времени, лента новостей, телефонный справочник, сотрудники, о компании, документы, график отсутствий и так далее. Этот инструментарий корпоративного портала рабочий и в его настройке даже помощь подрядчика может быть не нужна. Однако нужно помнить, что функции портала — следствие из целей и задач внедрения. Про цели и задачи мы так или иначе говорили в первой статье — нужно понимать насколько клиент созрел для внедрения. Если он не дорос, как правило, мы слышим: “О, я хочу такой же инструмент!”. А на вопросы: “Зачем? Как это облегчит работу? Есть ли надобность?” — ответ получить сложно.

“Спелый” заказчик что-то почитал, что-то знает про возможности, платформы и приходит с конкретными вопросами, а бывает и формализованными задачами: хотим автоматизировать Оценку 360 градусов, вот регламент, вот структура опроса. Это огромная редкость и плюс для внедренца.

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

В случае ФРДВ это была специальная политика, которая отражает путь проекта в Фонде. Мы её детально проанализировали, выделили реперные точки, задали вопросы на уточнение, провели несколько встреч с ответственными за разные процессы. В итоге сформировали решение для проекта.

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

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

К сожалению или к радости не все процессы, которые происходят вживую, также происходят в IT. Доску почета в любом виде, — фотографии у входа, ежемесячная рассылка — перенести в IT просто, модуль имеет ту же форму.

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

Этот процесс у всех сильно отличается изначально. Цепочка согласований в вакууме: договор надо согласовать ➡ с экономистами ➡ с юристами➡ отправить руководителю ➡ он ставит визу.

Однако договоры не заключаются в вакууме и возникают сложности:

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

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

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

HR во время брифинга спрашивает: “А как люди-то на портале появляются?”. Это один из абсолютно банальных, но частых и важных вопросов.

В большинстве проектов вопрос решается интеграцией с AD клиента.

Вроде бы стандартная процедура. Есть стандартный шлюз. Но, как обычно, трудности возникают в процессе реализации. Кажущаяся простота интеграции сбивает с толку клиента. Важно пояснить, где могут возникнуть трудности и как их избежать. Например:

В части о правах доступа мы затронули вопрос о внедрении портала в общую IT-инфраструктуру компании. Однако инфраструктура это не только AD, это может быть SAP, всевозможные конфигурации 1С, LMS, калькуляторы на товары/услуги, самописные системы и прочее, и прочее. Интеграция с каждой из них — отдельная тема разговора во время брифинга с профильными специалистами со стороны клиента.

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

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

Пересаживать сотрудников с Outlook на личные календари и почту на портале — плохая идея.

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

Довод второй. Возможность безболезненной и успешной синхронизации с Exchange сервером вопрос его версии. Интеграция с 13 и 16 версиями в принципе не поддерживается. Мы открыто говорим, что этот инструмент на портале не рабочий, нет четкого, устоявшегося регламента синхронизации.

1C — гибкий и индивидуальный инструмент, который подстраивается под нужды компании. Встретить одинаково настроенные программы невозможно, никто не использует стандартную конфигурацию.

Возникает ситуация: для интеграции 1C с корпоративным порталом существует типовой модуль, но 1C уже не типовая и модуль не работает. Интеграция все еще возможна, но становится в разы сложней.

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

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

И тут клиенту стоит задуматься нужно или нет. Не получится ли бессмысленного дублирования системы. Часто интеграция требуется для согласования счетов, договоров, выгрузки отчетности. Если процессов, завязанных на моментальном взаимодействии с 1C, в портал не заложено, то и сущности без надобности умножать не стоит.

Заказчик может возразить: “1C и 1C-Битрикс — одного поля компании, не может быть между ними сложностей”. На самом деле ничего общего с технической точки зрения, между продуктами нет. Это абсолютно сторонние решения с различным набором модулей.

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

Формирование главной страницы — вопрос не только пользовательского опыта, юзабилити и навигации, но и задач бизнес-заказчиков:

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

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

Мы можем полностью видоизменить шаблон оформления от страницы авторизации до кнопки “ок” при создании задачи. Но всегда нужен ответ на вопрос: “А зачем?”.

Вопросы не про продукт не менее важны и определяют не столько сам результат, сколько способ его достижения. Ответы помогают правильно организовать процесс, расставить приоритеты и спланировать взаимодействие, как на этапе реализации, так и на этапе подготовки решения.

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

Участие IT-агентства в проекте по внедрению корпоративного портала может протекать по-разному, в зависимости от потребностей, возможностей и готовности клиента.

На этапе брифинга важно понять какой из возможных вариантов наиболее оптимален для сторон и максимально быстро приведет к ожидаемому результату.

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

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

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

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

Насколько глубоко копать и когда остановиться, каждый разработчик решает сам. В зависимости от своих возможностей, компетенций и интересу к клиенту, проекту в целом. Кто-то готов инвестировать в проект свои ресурсы на безвозвратной основе, кто-то сразу же просит оплаты за пресейл, кто-то переносит стоимость работ по подготовке в первый этап работ по проекту (в открытую или закрытую).

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

Клиент отправляется ждать презентации предварительного решения от агентства. Исполнитель переходит на этап дополнения информации и собственно выработки решения:

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

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

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

А с какими сложностями на этапе агрегации требований сталкивались вы? Делитесь опытом в комментариях.