Как стать автором
Обновить

Правда о внедрении интранет-портала

Время на прочтение9 мин
Количество просмотров6.4K

Автор: Мелдажис Павел, ведущий специалист департамента корпоративных решений нашего IT-агентства.


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




Корни проблем


Эта статья — ответ на вопрос клиента: «Мы к вам обратились, так как вы профессионалы, внедрите нам портал?». Чаще мы слышим этот вопрос от IT-директора, которому поставили аналогичную задачу, реже от HR или маркетолога.


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


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


Как правило, интранет-порталы внедряют агентства веб-разработки. До этого они делали сайты, потом у Битрикса появился продукт «Корпоративный портал», и агентства стали заниматься и им тоже. Открыли профильные отделы, так как разработка модулей на портале сложнее, чем на сайте. Потом кто-то в этом преуспел, переквалифицировался и назвал себя интегратором. Как бы то ни было, агентство — технари: кто-то классно рисует дизайн, кто-то профессионал в брендинге, кто-то в маркетинговых исследованиях, кто-то хорошо кодит и знает, как интегрироваться с различными системами.


Но, клиенты забывают или не осознают, что агентство — не бизнес-тренер. Перед ним не стоит задача «выявить внутренние проблемы клиента и изменить бизнес-процессы, чтобы компания работала как часы». Агентство может их подкорректировать в момент автоматизации и наложения в IT-среду, подсказать удобное решение или вовсе отговорить от автоматизации, но не стать её инициатором.


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

И, когда вы как заказчик приходите к интеграторам с просьбой все грамотно и красиво сделать или вы как агентство беретесь за проект внедрения корпоративного портала, возникает вопрос — куда двигаться дальше?


Два подхода к внедрению


I подход. Отталкиваться от функций системы.


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


Плюсы:


  • Бюджетно — используется стандартный инструментарий.
  • Быстро — по той де причине.
  • Система почти не меняется, обновлять её проще.

Минусы:


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

Такой подход — удел молодых агентств. Их цель — отгрузить лицензию, а не заработать на поддержке и развитии.



II подход. Отталкиваться от проблемы клиента.


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


Плюсы:


  • Система подстраивается под клиента, а не клиент под систему — решение точечное.
  • Чем больше сделаешь, тем круче поедет, тем больше разовьются аппетиты, тем больше инструмент будет востребован и станет приносить пользу.

Минусы:


  • Это долго. Уходит время на изучение задачи, погружение, согласование, реализацию задуманного.
  • Это дорого. Индивидуальные решения и специальные разработки дороже, чем стандартная отгрузка портала.
  • Выше риски, если не заработает (в первую очередь финансовые). Это напрямую связано с грамотностью разработчика, его честностью и добросовестностью агентства. Не все проблемы может решить портал, о чем желающие заработать агентства благополучно умалчивают.
  • Реальность и легкость обновления портала в будущем напрямую зависит от «пряморукости» разработчика.

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


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

Получается замкнутый круг, чтобы понять «Зачем портал?» — нужно попробовать, чтобы попробовать — нужно понять «Зачем он нужен?». Тут, кстати, выручает облачная версия портала (для пробы регистрируйтесь, устанавливаете и тестируете облако).


Картина мира интегратора


Подобная логика (разделения на попроще и посложнее) прослеживается и в сегментации платформ. Получается очень интересная картина.


Есть решение на MS SharePoint, это большие неповоротливые системы, дорогие в обслуживании и разработке. Но важно то, что разработка таких интрасетей отталкивается от потребностей клиента и его бизнеса. Да, существуют пакеты решений, закрывающие многие типовые потребности (мессенджер, форум, карточка сотрудника, структура, фотоальбом), но, как правило, все пишется «с нуля» под индивидуальные задачи клиента. Каждый бизнес-процесс проговаривается, и реализуется автоматизация. Такие решения в итоге имеют более долгий срок жизни и они считаются более эффективными внедрениями. Системы подобные MSS выбирают уже зрелые компании, у которых сформировано понимание ключевых задач — «что нужно от портала». Не сложно догадаться — внедрение MSS идет по II подходу.


В противовес MSS портал Битрикс24 поставляется уже пакетом, не претерпевая серьёзных изменений. У Битрикс24 мало индивидуальности, он не всегда закрывает потребности клиента. Каждый бизнес хоть и похож, но каждый имеет существенные отличия. Процесс внедрения портала на Б24 в большинстве случаев — I подход.


Напрашивается вопрос: «Почему бы не применить II подход во внедрении Битрикса?». И это верная мысль.


Над её реализацией мы работаем долго и упорно. И сформировали для себя общие принципы внедрения портала. Они написаны нашим потом и кровью: с чего начинать внедрение и к чему стремиться, на какие вопросы отвечать. Ниже шаги на пути к рабочему инструменту — идеалу заказчика и агентства.


Общие рекомендации по внедрению


1. Определить цели и задачи внедрения


Хотя бы понять, где плохо и что хочется сделать лучше. Чем конкретнее цель, тем вероятнее её достижение.


Удачные примеры:


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

Неудачный пример:


  • Автоматизировать внутренние бизнес-процессы компании, например, заказ такси, заявка на отпуск, заявка на командировку.

С одной стороны вроде конкретно, но одна проблема. Агентство может не озадачиться всерьез этим пожеланием. Неподкованный менеджер ответит заказчику: «В Битриксе уже есть стандартный бизнес-процесс заявки на командировку, можете пользоваться им». Проблема вскроется позже, когда клиент поймет — стандартный процесс ему не подходит, не отрабатывает нужные ступени согласования. Доработка слишком дорогая или агентство в принципе некомпетентно оказывать консультацию. В итоге клиент не доволен результатом, ничего толком не работает. Агентство, получив свою долю за лицензии, ретируется. А произошло это потому что:


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

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


2. Обозначить зоны ответственности


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


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


Развею миф: заказчик думает, что агентство при каждом удобном случае ищет путь усложнить решение и заработать больше денег, — это не так. Если у агентства достаточно работы, специалисты технически грамотны и уже имели опыт с подобными задачами, то они действительно предлагают наиболее оптимальный вариант. Доверьтесь им и не ищите подвоха.


3. Найти горящие глаза


На стороне клиента должно быть ответственное лицо, у которого «свербит». Ему хочется одно, второе, третье… Он активно пользуется порталом, и втягивает коллег в процесс. Важно, чтобы у этого человека была поддержка со стороны руководства. Безынтересный, ничего не желающий крайний — не про хорошую работу. Если «горящих глаз» нет, то, скорее всего, проект провалится.


4. Расставить приоритеты


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


5. Внедрять частями


Вплоть до того, что сначала на портале ВООБЩЕ НИЧЕГО НЕТ.


Поясню почему:


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

6. Тестировать


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


7. Дать порталу нагрузку


Вы покупаете новый телефон, и первые дни испытываете дискомфорт. Старый был «привычнее». Но не возвращаться же к устаревшей модели? Звонишь, пишешь, скролишь, пользуешься телефоном каждые полчаса — быстро привыкаешь и со временем жить без него не можешь.


Это все к чему!? Нужно завязывать на портале бизнес-процессы и не дать обратного пути. Появление ресурса — не волшебная палочка, по мановению которой все начнут пользоваться порталом и радоваться результатам. Хороший итог — работа обеих сторон.


Если что-то можно сделать на портале, то нужно делать это на портале, запретив остальные инструменты (но важно, чтобы это было удобно и быстро!).


Удачный пример. Объявления и важные новости сотрудникам рассылаются по почте. Сообщение затеряется, плюс нет оперативной обратной связи: кто прочел, кто проигнорировал, кто не увидел. В портале сообщение от имени компании прилетает всем. Комментарии оставляют тут же. Пропустить запись не получится — уведомление будет висеть (и действовать на нервы) пока сотрудник не нажмет кнопку «ознакомлен». Быстро, удобно, эффективно — работать будет.


Неудачный пример. Каждый в своей работе использует файлы. Как правило, в компании есть сетевой диск, и коллеге можно скинуть «путь» к файлу. Особенно это подходит небольшим компаниям, с единой системой хранения. Обязать обмениваться документами только через портал — плохая идея. Кинуть ссылку коллеге значительно быстрее. С другой стороны, через портал можно назначить ограничения прав доступа на конкретный файл, отправить его «во вне сети», запаролив или ограничив ссылку по времени действия. В этом случае портал хорош. Для каждого сценария — свои инструменты и задача агентства рассказать о возможностях.


8. Определить критерии успешности внедрения


Я бы разделил критерии на два тесно связанных лагеря.


Первый. Решение конкретных задач. Автоматизация процесса «командировка от заявки до отчета», внедрение Help-desk и т.д. Это понятные задачи, которые анализируются/проектируются/реализуются/запускаются в опытную эксплуатацию.


Второй. Полезность внедрения. Его сложно измерить эмпирически, он ощущается на уровне быта сотрудников. Если они ссылаются на портал как на авторитетный источник, именно там ищут нужную информацию — это самый главный показатель пользы портала. Когда в офисе можно услышать фразы типа: «я не знаю, какая версия регламента/приказа последняя, посмотри на портале, там точно свежая» или «я тебе в задаче на портале откомментировал и файлик приложил...», «я на портале идею подал, проголосуй за неё» или «задай всем вопрос в портале, уверен, кто-то сталкивался с такой же проблемой» и т.д. можно считать, что портал успешно запущен.


Итого, что надо помнить для внедрения портала:
1. Четко сформулированные цели и задачи.
2. Кто за что в ответе.
3. Приоритетность, порционность и последовательность задач.
4. Тестовая группа преимущественно из руководства.
5. Обязательна нагрузка на портал, без задач он «умрет».

Вот базовые принципы, следуя которым на выходе получается рабочий инструмент. Если вы потенциальный заказчик и читаете нас, то помните — не все в руках digital-агентства. Оно не сможет сделать бизнес рентабельнее без вашей помощи. А если вы агентство, то помните — выпытываете у заказчика всю необходимую информацию, уточняйте, и поговорите о зонах ответственности заранее. И конечно следуйте нашим рекомендациям!

Теги:
Хабы:
Всего голосов 2: ↑0 и ↓2-2
Комментарии0

Публикации

Истории

Работа

Ближайшие события

2 – 18 декабря
Yandex DataLens Festival 2024
МоскваОнлайн
11 – 13 декабря
Международная конференция по AI/ML «AI Journey»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань