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