Интранет Блог

В последнем выпуске «Культурной точки» на сайте Сообщества внутренних коммуникаторов прозвучал такой вопрос:

В нашем банке в скоро стартует новый Интранет-портал. Есть  ли установленный порядок запуска компонентов при внедрении Интранета? Нам хочется  добиться  наиболее эффективного восприятия и принятия сотрудниками  нового Интранета.

Там есть ответ и небольшое обсуждение. Мой комментарий получился слишком объемным, чтобы добавлять на сайт, и я решила дать его в Интранет блоге. Поэтому благодарю автора вопроса Оксану Золотаренко, за тему для поста.

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

• Выбрать надежную платформу и компанию с опытом внедрения (обычно партнера компании-разработчика продукта);
• Запустить компоненты интранета в правильной последовательности.

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

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

Фокус на решениях и технологиях

Подход

Я часто наблюдаю случаи, когда проект по созданию интранета начинается с выбора платформы. Не столь важно, как происходит выбор, главное, что на этом этапе участники проекта исходят из того, что проблемы компании понятны, задачи интранета известны и неизменны. Можно приступать к решению. Сроки и бюджет проекта заранее определяют и утверждают – объем работ на создание ТЗ, разработку и внедрение можно просчитать.

Почему же в большинстве случаев возникают нереальные дедлайны, размытые задачи, долгие непродуктивные совещания? Почему компании-заказчики остаются недовольны? Они получают сложные и непонятные интерфейсы, неадекватный функционал, хотя формально все соответствует ТЗ. Обычно можно услышать: «Мы всегда находим время на переделку, но никогда – на то, чтобы делать сразу как следует». 

Я бы выделила две причины:

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

Сложность системы не сводится к ее технической составляющей. Интранет решает проблемы организации, а ее формируют разнородные элементы: люди, техника, организационная структура, культурные особенности, влияния внешней среды. Свойства, присущие сложной системе, могут отсутствовать у ее элементов. Поэтому их невозможно понять и учесть при анализе отдельных частей. Все элементы взаимодействуют и влияют друг на друга. Если вы проводили организационные изменения, то знаете, что даже самые простые действия могут вызвать непредсказуемые последствия из-за влияния неучтенных факторов.*

И еще некоторые характеристики комплексных проблем:

• Мы не можем до конца понять проблему, пока не выработаем решение. Как сказал Horst Rittel**, «нельзя понять проблему, не зная контекста; невозможно осмысленно собирать информацию, не имея идеи о концепции решения; нельзя сначала понять, а потом решать». Каждый новый шаг в поиске решения выявляет новые аспекты проблемы, что  требует дальнейших поисков решения.
• Решения не бывают правильными или неправильными. Они просто «лучше», «хуже», «достаточно хорошие» или «недостаточно хорошие». Нет формул для объективной оценки. Решения разрабатываются в социальном контексте, где у каждого заинтересованного лица свои суждения, которые зависят от его целей и ценностей.
• Каждая комплексная проблема/задача по сути уникальна и нова. В динамическом социальном контексте действует так много факторов и условий, что нет и двух похожих проблем. Каждая требует особого изучения и специфического решения. Эксперты накапливают знания о подходах и методах в решении таких проблем, но новая задача всякий раз несет новый опыт.
• Каждый шаг в решении комплексной проблемы не обратим. Это уловка-22: невозможно разобраться в проблеме, не пробуя разные решения. Но каждая попытка может дорого обойтись и повлечь за собой длительные неожиданные последствия, порождающие новые проблемы.

Эти определения помогают понять причины неудач многих проектов и выбрать подходящие методы работы. Правда, это не просто – выбор сегодня очень широк. Не существует лучшего и единственного подхода. Один из наиболее адекватных задаче и ценных по тому вкладу, который он дает заказчикам – Human-centered design, или проектирование систем, ориентированных на человека. В рамках этого подхода выявление требований к интранет-системе и моделирование взаимодействия «человек – система» идут одновременно и влияют друг на друга. Средство моделирования – прототипы интерфейса. Они выполняют и функцию переводчика, позволяют заказчику и исполнителям точно понимать друг друга. За счет этого на каждом шаге можно тестировать новые гипотезы и идеи, вносить быстрые изменения в модель системы, снова оценивать решения и так, итеративно, двигаться к финальному прототипу. В этом случае спецификация (или ТЗ) оказывается скорее приложением к прототипу, поэтому вероятность ее неверной интерпретации резко снижается.

Внедрение

Мы не можем определить, какая последовательность компонентов нужна менеджерам (=бизнесу) или будет лучше воспринята сотрудниками. Люди не живут в реальности SharePoint и не мыслят его абстрактными терминами. У них есть цели, к которым они стремятся, и «больные мозоли» – проблемы, которые не решаются годами, есть текущие ежедневные дела и долгосрочные планы. Нет такого исследования, которое покажет, что сначала надо запускать документы, потом социальные сервисы, а потом еще что-то.  А просто спрашивать, что думают сотрудники, например, с помощью опросов, как известно, плохая практика. Представления и желания людей часто расходятся с реальными потребностями. К тому же, многие просто не знают особенностей платформ и компонентов.

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

Если же мы рассматриваем социальные инструменты исключительно как приятное дополнение к интранету, вне связи с рабочими процессами и задачами, то их запуск на любом этапе будет неуспешным. Я не раз слышала как интранет-менеджеры проклинали тот день, когда открыли форум. Он либо пустует и становится постоянным немым укором за бесцельность, либо переполняется анекдотами и объявлениями купли-продажи, тогда укор возникает со стороны руководства.

Поиск рецептов

Уникальность и новизна, как неотъемлемая особенность комплексных ситуаций, ограничивает возможность применения «best practice». Это как чужой устав для монастыря – трудно адаптировать, а чаще просто не приживается и создает хаос. Нам, как людям западной культуры, свойственен  фокус на решения, «рефлекс ответов». Причем мы стремимся именно к «правильным»и быстрым ответам, ждем их от других и избегаем ситуаций, когда сами не можем ответить в нужный момент. А что если вопрос поставлен неточно или вообще ошибочен? Задавать полезные вопросы сложнее, чем давать ответы. Но именно с помощью вопросов доходя до сути вещей – каковы наши цели, уникальные особенности, условия, какие действия помогут усилить наши преимущества и укрепить слабые стороны – возможно создание общего понимания между участниками и заинтересованными лицами проекта. Этот этап критично важен для будущего интранета, он помогает увидеть целостную картину и выработать гибкий подход к развитию.

Самая большая сложность на этом пути – обеспечить продуктивный диалог между разными сторонами, вовлеченными в проект. Ведь каждый участник приходит со своей повесткой, своими нуждами и картиной мира. Нужна общая основа, система координат, которая будет всем понятна и адекватна как инструмент обсуждения и выработки решений. Здесь выбор на ваше усмотрение, но лучше не изобретать колесо и воспользоваться известными эффективными моделями. Об одной из них я уже писала – это Digital Workplace Maturity Model от IBF. В ее основе лежит идея, что нет единственного правильного курса развития интранета («единого рабочего места» в терминах модели), универсального рецепта для всех. Правильным для организации будет то направление, которое опирается на ее стратегию и организационный контекст. В контексте выделяют 4 измерения: коммуникации и информация, сообщества и совместная работа, сервисы и структура. Модель помогает оценить, что есть сегодня, и договориться о желаемом будущем.

Еще одна полезная модель – Cynefin, разработанная в компании Cognitive Edge. Она дает другие измерения организационного контекста: известное, познаваемое, комплексное, хаотичное и неопределенное. Каждая из областей Cynefin соответствует определенному способу восприятия и понимания проблемы или ситуации. От того, к какой области мы отнесем проблему, будет зависеть наш подход к ее решению. Ни одно из состояний не является более или менее желательным. Ценность модели в том, что она уводит от линейного мышления к пониманию организации как экосистемы, в которой сосуществуют разные среды и действует постоянная внутренняя динамика обмена между ними. Каждая среда имеет свое место и предназначение в системе и требует особого подхода к ее поддержанию и развитию. Что касается «лучших практик», то они применимы только для задач, которые находятся в области Известное, где причинно-следственные связи очевидны, повторяемы и предсказуемы. Пример – стандартные операционные процедуры, известные многим как СОПы.

Резюме

Недавно вышел отчет Deloitte Social Software for Business Performance. В нем много детальных кейсов, на примере которых сделан анализ факторов успешного использования социального ПО для задач бизнеса. Один из выводов отчета в том, что фокус на адаптацию технологий является тупиковой стратегией. Когда главным критерием успеха становится адаптация, результат получается прямо противоположный желаемому. На всех уровнях организации растет сопротивление, и проект терпит неудачу. Думаю, этот вывод применим к интранету в целом.

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

***

Мне кажется, эта тема очень актуальна, и здесь может быть много разных мнений. Давайте обсудим.

 

Сноски:
*Я назвала только некоторые характеристики сложных систем. В интернете можно найти полное описание.
** Horst Rittel, американский профессор в области «Теории и методы дизайна». В 1973 году придумал термин  «wicked problem» и описал 10 основных характеристик таких проблем.

******

Еще сообщения по теме:

3 рабочих контекста интранет-менеджера

Цитаты о стратегии интранета, управлении интранетом

Теги: best practice, адаптация интранета, внедрение интранета