Эта статья — ответ на вопрос клиента: «Мы к вам обратились, так как вы профессионалы, внедрите нам портал?». Чаще мы слышим этот вопрос от ИТ-директора, которому поставили такую задачу, реже от HR или маркетолога.
Ответственный за задачу не знает, что делать дальше. И хуже — он не видит вектор движения, не представляет цели, к которой стремится. Это первая проблема.
Озадаченный сотрудник ищет ответ на стороне, обращается в компании, которые уже проходили эту процедуру. Кстати, чаще всего такие клиенты просят поделиться практикой внедрений, ожидая почерпнуть идею. Шаги клиента понятны и правильны: если не знаешь сам, спроси у того, кто знает. Здесь возникает вторая проблема — агентство.
Как правило, интранет-порталы внедряют агентства веб-разработки. До этого они делали сайты, потом у «Битрикса» появился продукт «Корпоративный портал», и агентства стали заниматься и ним. Открыли профильные отделы, так как разработка модулей на портале сложнее, чем на сайте. Потом кто-то в этом преуспел, переквалифицировался и назвал себя интегратором. Как бы ни было, агентство — технари: кто-то классно рисует дизайн, кто-то профессионал в брендинге, кто-то в маркетинговых исследованиях, кто-то хорошо кодит и знает, как интегрироваться с различными системами.
Но клиенты забывают или не осознают, что агентство — не бизнес-тренер. Перед ним не стоит задачи «выявить внутренние проблемы клиента и изменить бизнес-процессы, чтобы компания работала как часы». Агентство может их подкорректировать в момент автоматизации и наложения в ИТ-среду, подсказать удобное решение или вовсе отговорить от автоматизации, но не стать её инициатором.
Не в силах и не в компетенции агентств создавать механизмы работы чужого бизнеса, интеграторы помогают ему быть мобильным и полезным.
И, когда вы как заказчик приходите к интеграторам с просьбой всё грамотно и красиво сделать, или вы как агентство берётесь за проект внедрения корпоративного портала, возникает вопрос — куда двигаться дальше?
Два подхода к внедрению
Первый подход. Отталкиваться от функций системы
Выглядит это так: агентство рассказывает клиенту об инструментах, которые есть в портале. Затем клиент определяет инструменты, которые бы он хотел внедрить. Агентство подробнее рассказывает обо всех возможностях, помогает в настройке, доводке под задачу.
Плюсы:
- Бюджетно — используется стандартный инструментарий.
- Быстро — по той же причине.
- Система почти не меняется, обновлять её проще.
Минусы:
- Клиент подстраивается под систему, а не система под клиента. Решение чаще получается неудобным, неполным. Каждый бизнес — новые особенности.
- Как правило, это автоматизация на уровне «фана», а не решение конкретных проблем бизнеса.
- Чаще всего сотрудники перестают пользоваться такими порталами. Портал живет за счёт контента, нет контента или он устарел — портал умер.
Такой подход — удел молодых агентств. Их цель — отгрузить лицензию, а не заработать на поддержке и развитии.
Второй подход. Отталкиваться от проблемы клиента
Клиент приходит к агентству с проблемой и, разумеется, просьбой её решить. Агентство погружается в задачу, изучает её вместе с клиентом и ищет пути адаптации существующего инструментария или варианты разработки нового. Такой вдумчивый, исследовательский подход, правильнее и эффективнее.
Плюсы:
- Система подстраивается под клиента, а не клиент под систему — решение точечное.
- Чем больше сделаешь, тем круче поедет, тем больше разовьются аппетиты, тем больше инструмент будет востребован и станет приносить пользу.
Минусы:
- Это долго. Уходит время на изучение задачи, погружение, согласование, реализацию задуманного.
- Это дорого. Индивидуальные решения и специальные разработки дороже, чем стандартная отгрузка портала.
- Выше риски, если не заработает (в первую очередь финансовые). Это напрямую связано с грамотностью разработчика, его честностью и добросовестностью агентства. Не все проблемы может решить портал, о чём желающие заработать агентства благополучно умалчивают.
- Реальность и лёгкость обновления портала в будущем напрямую зависит от «пряморукости» разработчика.
Выбор подхода — решение клиента. Если бизнес небольшой, внутренняя коммуникация не предполагает многоступенчатости и запутанности, не нужна кастомизация портала, то и переплачивать, перерабатывать нет смысла. В противном случае, когда компания численностью сотрудников более 500, а портал должен решать вопросы не только учёта времени, постановки задач, корпоративного оповещения, но и документооборота, с интегрированными сторонними системами — решением из коробки не обойдёшься.
Что касается агентств — подход «исследователей и создателей» выбирают только крупные агентства, которые дорожат репутацией. Профи не боятся отказывать не определившимся клиентам. Без чёткой цели нет результата, а негатив быстро распространяется. Агентств, которые круто подкованы технически, мало. Но агентств, которые погружаются во внутреннюю кухню заказчика и потом реализуют это технически, ещё меньше.
Получается замкнутый круг, чтобы понять «Зачем портал?» — нужно попробовать, чтобы попробовать — нужно понять «Зачем он нужен?». Тут, кстати, выручает облачная версия «Битрикса»: для пробы регистрируйтесь, устанавливаете и тестируете облако.
Картина мира интегратора
Подобная логика (разделения на попроще и посложнее) прослеживается и в сегментации платформ. Получается очень интересная картина.
Есть решение на MS SharePoint, это большие неповоротливые системы, дорогие в обслуживании и разработке. Но важно то, что разработка таких интрасетей отталкивается от потребностей клиента и его бизнеса. Да, существуют пакеты решений, закрывающие многие типовые потребности (мессенджер, форум, карточка сотрудника, структура, фотоальбом), но, как правило, всё пишется «с нуля» под индивидуальные задачи клиента. Каждый бизнес-процесс проговаривается, затем реализуется автоматизация в системе. Такие решения в итоге имеют более долгий срок жизни, и они считаются более эффективными решениями. Системы подобные MSS выбирают зрелые компании, у которых сформировано понимание ключевых задач — «что нужно от портала». Не сложно догадаться — внедрение MSS идёт по второму подходу.
В противовес MSS портал «Битрикс24» поставляется готовым пакетом, не претерпевая серьёзных изменений. У «Битрикс24» мало индивидуальности, он не всегда закрывает потребности клиента. Каждый бизнес хоть и похож, но каждый имеет существенные отличия. Процесс внедрения портала на «Битрикс24» в большинстве случаев — первый подход.
Напрашивается вопрос: «Почему бы не применить второй подход во внедрении „Битрикса“?». И это верная мысль.
Над её реализацией мы работаем долго и упорно. И сформировали для себя общие принципы внедрения портала. Они написаны нашим потом и кровью: с чего начинать внедрение и к чему стремиться, на какие вопросы отвечать. Ниже шаги на пути к рабочему инструменту — идеалу заказчика и агентства.
Общие рекомендации по внедрению интранет-портала
1. Определить цели и задачи внедрения
Хотя бы понять, где плохо и что хочется сделать лучше. Чем конкретнее цель, тем вероятнее её достижение.
Удачные примеры:
- Автоматизировать процесс постановки и отслеживания KPI сотрудников. Сейчас процесс реализован в бумажном виде.
- Привить культуру постановки и выполнения задач. К слову, для этого и в «Битрикс24» уже всё есть, но нет регламента. Разработка регламента — задача клиента. Познакомить с функциями платформы — задача агентства.
Неудачный пример:
- Автоматизировать внутренние бизнес-процессы компании: заказ такси, заявка на отпуск, заявка на командировку.
С одной стороны вроде конкретно, но одна проблема. Агентство может не озадачиться всерьёз этим пожеланием. Неподкованный менеджер ответит заказчику: «В „Битриксе“ уже есть стандартный бизнес-процесс заявки на командировку, можете пользоваться». Проблема вскроется позже, когда клиент поймёт — стандартный процесс ему не подходит, не отрабатывает нужные ступени согласования. Доработка слишком дорогая или агентство в принципе некомпетентно оказывать консультацию. В итоге клиент не доволен результатом, ничего толком не работает. Агентство, получив свою долю за лицензии, ретируется. А произошло это потому что:
- клиент не поставил чёткую цель;
- агентство не задало уточняющие вопросы, соответственно, установив минимальную стоимость;
- клиент выбрал по цене (ведь странно платить за бизнес-процесс, когда он уже идет из коробки);
- в указанный бюджет реализовать то, что хочет клиент, агентство не может — не закладывалось;
- клиент недоволен, разочарован и в агентстве, и в продукте.
Вот если задачу сформулировать хотя бы так: «Автоматизировать процесс командирования сотрудника, который происходит согласно регламенту» и обязательно приложить сам регламент, то половина агентств, скорее всего, сразу отсеется. Потому, что это сложно реализовать без соответствующего опыта.
2. Обозначить зоны ответственности
Заказчик должен чётко понимать, где заканчивается зона ответственности исполнителя. Задача исполнителя — донести это до клиента, чтобы не создавалось ложное ощущение, будто ответственность за внедрение портала лежит только на агентстве. Агентство — технарь, максимум — консультант.
А зона ответственности заказчика заканчивается на техническом исполнении. Не нужно учить агентство, как правильно использовать стандартную функцию или навязывать использование модуля списков в целях экономии средств, это не всегда правильно на дистанции (поддержка, обновления, доработки), а иногда и вовсе неудобно с точки зрения юзабилити.
Развею миф: заказчик думает, что агентство при каждом удобном случае ищет путь усложнить решение и заработать больше денег, — это не так. Если у агентства достаточно работы, специалисты технически грамотны и уже имели опыт с подобными задачами, то они действительно предлагают наиболее оптимальный вариант. Доверьтесь им и не ищите подвоха.
3. Найти горящие глаза
На стороне клиента должно быть ответственное лицо, у которого «свербит». Ему хочется одно, второе, третье... Он активно пользуется порталом и втягивает коллег в процесс. Важно, чтобы у этого человека была поддержка со стороны руководства. Безынтересный, ничего не желающий крайний — не про хорошую работу. Если «горящих глаз» нет, то, скорее всего, проект провалится.
4. Расставить приоритеты
Работы по внедрению могут длиться бесконечно, совершенству нет предела. В живой организации всегда будет что автоматизировать, поэтому важно расставить приоритеты по задачам или направлениям. Лучше работать с двумя потоками. Например, электронные заявки и доработка модуля wiki. Если работать по другому, то, во-первых, ответственному лицу со стороны заказчика сложно держать всё в голове. Во-вторых, исполнителю придётся подключать на проект новых программистов (возможны конфликты «с технической точки зрения»). В-третьих, пользователям нужно выдавать результат порционно, а не всё сразу.
5. Внедрять частями
Вплоть до того, что сначала на портале вообще ничего нет.
Поясню почему:
- Каждым инструментом нужно научиться, а потом научить пользоваться. Создать регламент использования. На это нужно время и чистое пространство, чтобы познакомиться с функциональностью и изначально не запутаться в структуре.
- Если сразу вывалить на сотрудников всё, что может портал, они потеряются, глаза разбегутся, пользоваться не научатся.
- Вероятность, что какой-то инструмент работать не будет или будет работать криво, намного выше, если все возможности портала реализованы скопом. Каждый этап не тестировался отдельно, портал не постепенно наполнялся блоками, не выявлены ошибки — отсюда недовольство и отказ от портала.
6. Тестировать
Сначала пилотная группа тестирует портал, потом все остальные. Важно, чтобы руководство было в числе первых.
Как правило, в систему пускают HR и ИТ-специалистов, им проще адаптироваться к новым инструментам.
7. Дать порталу нагрузку
Вы покупаете новый телефон, и первые дни испытываете дискомфорт. Старый был привычнее. Но не возвращаться же к устаревшей модели! Звонишь, пишешь, скролишь, пользуешься телефоном каждые полчаса — быстро привыкаешь и со временем жить без него не можешь.
Это всё к чему?! Нужно завязывать на портале бизнес-процессы и не дать обратного пути. Появление ресурса — не волшебная палочка, по мановению которой все начнут пользоваться порталом и радоваться результатам. Хороший итог — работа обеих сторон.
Если что-то можно сделать на портале, то нужно делать это на портале, запретив остальные инструменты (но важно, чтобы это было удобно и быстро!).
Удачный пример. Объявления и важные новости сотрудникам рассылаются по почте. Сообщение затеряется, плюс нет оперативной обратной связи: кто прочёл, кто проигнорировал, кто не увидел. В портале сообщение от имени компании прилетает всем. Комментарии оставляют тут же. Пропустить запись не получится — уведомление будет висеть (и действовать на нервы) пока сотрудник не нажмёт кнопку «ознакомлен». Быстро, удобно, эффективно — работать будет.
Неудачный пример. Каждый в работе использует свои файлы. Как правило, в компании есть сетевой диск, и коллеге можно скинуть путь к файлу. Особенно это подходит небольшим компаниям с единой системой хранения. Обязать обмениваться документами только через портал — плохая идея. Проще сразу кинуть ссылку коллеге. С другой стороны, через портал можно назначить ограничения прав доступа на конкретный файл, отправить его «во вне сети», запаролив или ограничив ссылку по времени действия. В этом случае портал хорош. Для каждого сценария — свои инструменты, и задача агентства рассказать о возможностях.
8. Определить критерии успешности внедрения
Я разделяю критерии на два тесно связанных лагеря.
Первый. Решение конкретных задач. Автоматизация процесса «командировка от заявки до отчёта», внедрение Help-desk и других инструментов. Это понятные задачи, которые анализируются, проектируются, реализуются, запускаются в эксплуатацию.
Второй. Полезность внедрения. Его сложно измерить эмпирически, он ощущается на уровне быта сотрудников. Если они ссылаются на портал как на авторитетный источник, именно там ищут нужную информацию — это главный признак пользы портала. Когда в офисе можно услышать фразы типа: «Я не знаю, какая версия приказа последняя, посмотри на портале, там точно свежая» или «Я тебе в задаче на портале откомментировал и файлик приложил», «Я на портале идею подал, проголосуй за неё» или «Спроси в портале, уверен, кто-то сталкивался с такой же проблемой», можно считать, что портал успешно запущен.
Итого, что важно помнить
- Чётко сформулированные цели и задачи.
- Кто за что в ответе.
- Приоритетность, порционность и последовательность задач.
- Тестовая группа преимущественно из руководства.
- Обязательна нагрузка на портал, без задач он «умрёт».
Это базовые принципы, чтобы получить работающий интранет-портал. Если вы потенциальный заказчик и читаете нас, то помните — не всё в руках digital-агентства. Оно не сможет сделать бизнес рентабельнее без вашей помощи. А если вы агентство, то помните — выпытывайте у заказчика всю необходимую информацию, уточняйте, и поговорите о зонах ответственности заранее.
По материалам http://www.cossa.ru/trends/172370/