10.09.2018 | Добавил: OleshkoV | Просмотров: 180
Engico: волшебства не бывает

Engico – это вымышленное название большой скандинавской инжиниринговой компании. Андреас Дейдрих (Andreas Diedrich), изучивший и впервые описавший этот кейс, решил изменить название компании и имена участников проекта, т.к. проект был провальным. Автор описывает компанию следующим образом: она специализируется на производстве компонентов и узлов для тяжелого машиностроения и производства электроприборов, является мировым лидером во многих продуктовых сегментах. В организации занято около 30 тыс. сотрудников в 50 странах мира. Компания разбита на шесть продуктовых дивизионов, имеющих одинаковую организационную структуру.

Итальянская компания Engico, специализирующаяся на разработке и производстве упаковочного оборудования, к данному кейсу отношения не имеет.

В предыдущей заметке мы рассматривали кейс об опыте компании Форд и системе BPR, которую по лицензии успешно используют и в других компаниях. В большинстве случаев такая передача проходила успешно, но есть и обратный пример – компания Engico. Эта история началась в 1999 году, когда руководство Engico познакомилось с достижениями Ford и также захотело внедрить у себя эту систему. К этому моменту в компании уже был опыт применения ряда инструментов управления знаниями (картирование знаний, базы знаний, базы лучших практик, система дистанционного обучения), однако эффект от их применения не устраивал руководство. Одной из ключевых проблем, над которой бились специалисты компании, являлся перенос лучших практик между дивизионами и производственными площадками, т.к. на «повторное изобретение колеса» тратились немалые ресурсы. Именно поэтому кейс Ford вызвал такой интерес, но переговоры о покупке BPR не увенчались успехом, поэтому было принято решение самостоятельно построить аналогичную систему.

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

В начале 2000го года в компании взялись за разработку собственного программного продукта (Best Practice Tool, BPT). Команда проекта состояла из восьми человек – инженеров, руководителей среднего звена и ИТ-специалистов. Для того, чтобы ВРТ успешно работал, необходимо было запустить сообщества практиков. Подразумевалось, что они будут организованы вокруг различных этапов производственного процесса и разных областей знаний (например, дизайн машин, сборка, металлургия и т.п.). Внутри ВРТ для каждого сообщества создавалась своя страница. Сообщества должны были отвечать за перенос лучших практик между заводами и дивизионами. Планируемая структура СоР: глава сообщества (Community Head) отвечал за работу сообщества и за принятие в работу или отклонение лучшей практики; координаторы лучших практик (Best Practice Coordinator) находились на заводах и должны были выявлять, описывать в специальных формах в ВРТ и отправлять на рассмотрение главе сообщества локальные лучшие практики. Если глава сообщества одобрял заявку, система автоматически рассылала уведомление о новой практике всем заинтересованным лицам. Получатели информации на других заводах должны были обсудить возможность внедрения идеи у себя и дать ответ в системе: внедряют или нет и почему нет, а если да, то поделиться планом внедрения и отчитаться о результатах.

Разработчики системы были настоящими «евангелистами» - они «болели» идеей BPТ-процесса и верили в то, что ее так же восторженно воспримут другие сотрудники компании. По их мнению, выгоды от внедрения ВРТ настолько очевидны, что не требуют дополнительной рекламы:

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

На момент старта проекта в основе ИТ-инфраструктуры компании лежала платформа Lotus Notes. На ней была настроена электронная почта и создано множество локальных баз данных, в которых была собрана информация о продуктах и проектах компании. Lotus Notes была понятной и привычной для пользователей, но не устраивала руководство компании. В 2000 г. была куплена разработка одной американской компании - CoolSnake Intranet, которая представляла собой инструмент управления жизненным циклом продукта и считалась одной из самых передовых на тот момент. CoolSnake должна была заменить Lotus Notes и помочь унифицировать множество локальных баз данных. Надо отметить, что рядовые сотрудники были не в восторге от этой идеи. Они сами спроектировали и настроили под себя свои базы, привыкли к работе в Lotus Notes, и их в принципе все устраивало. Очевидным решением было бы развернуть ВРТ на платформе Lotus Notes, но топ-менеджмент придерживался другого мнения. Руководство компании решило, что ВРТ станет первым приложением, развернутым на CoolSnake, чтобы продемонстрировать все преимущества этой системы с т.з. комплексного управления всем жизненным циклом документа. Поэтому разработка ВРТ шла параллельно с внедрением CoolSnake.

В ноябре 2000 г. была запущена первая, самая простая, версия ВРТ. Сотрудники на местах получили возможность описывать свои лучшие практики и делиться ими через систему. Но почему-то не спешили это делать. У каждого инженера была своя сложившаяся сеть связей – коллеги, с которыми он общался лично, по телефону и по электронной почте. И им этого хватало для решения своих задач. У них не было потребности более широко обмениваться знаниями с другими подразделениями компании, не было осознания масштабов проблемы «повторного изобретения колеса». Одним из немногих заводов, включившихся в работу, была производственная площадка в Германии. За первую неделю после запуска системы они внесли 8 проверенных идей в качестве лучших практик. Но прекратили эту работу, т.к. не получили отдачи – другие подразделения не захотели делиться своими наработками, обмена не получилось. Для первопроходцев ситуация выглядела так, будто они только дают, а все остальные только берут.

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

Еще одна трудность, с которой столкнулись пользователи системы, - это необходимость рассчитывать экономический эффект от внедрения лучших практик. Они просто не понимали, как это делать. Никто не обеспечил их методикой расчета и не обучил ею пользоваться.

Но участники проекта не понимали всего этого и искренне недоумевали, почему никто не хочет пользоваться их системой. В итоге они решили, что всему виной платформа CoolSnake. С внедрением этой платформы действительно были проблемы – на нее поступало много жалоб. Развертывание такой платформы, которая должна была заменить собой привычный для всех Lotus Notes, локальные базы данных и даже частично электронную почту, - само по себе является сложным проектом. Пользователи жаловались на сложность, жесткость и ненадежность CoolSnake, на недостаточную поддержку со стороны поставщика платформы. Ко всему добавились проблемы с сетью, которые усложняли загрузку информации в систему в таких странах как, например, Индия (напомню, речь идет о начале 2000х – тогда еще Интернет не был таким скоростным и удобным в большинстве стран мира). Создание документов в ВРТ занимало слишком много времени.

Через год борьбы команда проекта признала, что первый запуск системы провалился, и в ноябре 2001 г. взялась за доработку ВРТ. Параллельно продолжалось внедрение платформы CoolSnake. На протяжении года команда проекта не только дорабатывала систему, чтобы сделать ее более удобной для пользователей, но и была вынуждена постоянно адаптироваться к бесконечным обновлениям CoolSnake. Вместо того, чтобы сосредоточиться на удержании тех немногих пользователей ВРТ, что уже были, и вовлечении новых, команда тонула в решении технических проблем. Но следующая версия ВРТ не стала ни более простой, ни более легкой в использовании. А платформа CoolSnake, напротив, стала еще более сложной и нестабильной. Но альтернатива развернуть ВРТ на платформе Lotus Notes высшим руководством даже не рассматривалась – эта платформа считалась слишком устаревшей и изжившей себя. Топ-менеджмент упорствовал в желании заменить ее на CoolSnake.

Одновременно с конца 2001 г. в компании попытались развернуть акцию по продвижению ВРТ – издали небольшой информационный буклет, в котором рассказывали о системе и тех выгодах, которые она должна принести компании. Его распространяли в электронном и бумажном виде на протяжении нескольких месяцев. Также команда проекта провела серию тренингов для потенциальных пользователей по работе с системой. Но поддержки со стороны высшего руководства в виде выступлений перед сотрудниками, писем или публикаций в корпоративной газете от лица топов не было. Приложенных усилий оказалось недостаточно - переубедить сотрудников оставить Lotus Notes и начать пользоваться ВРТ не получилось.

В общей сложности на попытку создать и запустить систему, аналогичную BPR Ford, у Engico ушло около четырех лет, но результат так и не был получен. В конце 2003 г. проект был признан провалившимся и свернут. Исследователи выделили несколько причин, которые привели к этому провалу:

  • Перед стартом проекта не были изучены имеющиеся в компании процессы обмена знаниями, и эти процессы не использовались как фундамент для новой системы.
  • Вместо привычного всем Lotus Notes руководство компании решило параллельно внедрять новую платформу и развернуть ВРТ уже на ней. Это очень усложнило работу команды проекта и с технической, и с организационной точки зрения.
  • Проект был запущен без какого-либо информационного сопровождения и явно выраженной поддержки со стороны высшего руководства: считалось, что система «сама себя продаст». Старт PR-компании через год после начала проекта уже не мог исправить ситуацию.
  • Созданный процесс не помогал сотрудникам в решении их проблем, но нагружал дополнительной работой: его развернули как обязательный к исполнению, а не как средство помощи.
  • Разработчики не прислушивались к обратной связи от пользователей. Когда ожидаемый эффект не был получен, инициаторы не стали работать с пользователями и выяснять причины сопротивления, а сразу занялись доработкой самого инструмента.
  • В компании слишком долго отказывалась верить в провал и настойчиво пытались оживить то, что оживить было невозможно. Причиной этого могла стать слишком крепкая вера инициаторов в силу технологий. Другими словами, они были уверены в том, что сам по себе разработанный инструмент прекрасен и уже только поэтому должен успешно работать, но совсем не уделили внимание человеческому фактору – в том числе мотивации сотрудников делиться своими наработками.

Этот кейс очень показателен. В управлении знаниями нет «волшебных таблеток» - нельзя решить проблему только самим инструментом. Нужно работать над созданием необходимой корпоративной культуры, над мотивацией сотрудников и их вовлечением - в общем, учитывать все классические принципы управления изменениями.

Кейсы компаний / 10.09.2018 | Просмотров: 180 | Добавил: OleshkoV | Всего комментариев: 0 / Теги: Управление знаниями, Ford, кейс
ОБ АВТОРЕ
Виктория Олешко Олешко Виктория, бизнес-тренер, консультант, главный редактор сайта SixSigmaOnline.ru. Автор книги “Управление знаниями: коротко о главном” и блога “Управление знаниями”.
Хотите узнать больше об управлении знаниями? Присоединяйтесь к группе на facebook.
Есть вопросы по управлению знаниями? Интересует корпоративное обучение? Пишите или обращайтесь через мой профиль в сети LinkedIn.

ПОХОЖИЕ МАТЕРИАЛЫ


  Добавить комментарий
avatar
SixSigmaOnline.ru © 2009-2018            Хостинг от uWeb