Внедрение системы управления знаниями. Почему шансы на успех снижаются пропорционально размеру компании
Меня зовут Кирилл Кузнецов, я CEO компании L2U. В этой статье я расскажу о типовых ошибках при внедрении систем управления знаниями и о том, как их избежать. Я не буду «умничать», сыпать терминами и приводить в качестве аргументации «высоколобые» теории в области менеджмента знаний. Это важная часть любого проекта, но она очень сильно сужает проблематику и, по большей части, интересна узким специалистам. Моя задача — подсветить те «грабли», на которые я и мои коллеги уже наступили и тот опыт, который мы из этого вынесли.
При запуске масштабных проектов по внедрению сложных информационных систем часто встречаются ситуации, когда с точки зрения IT, казалось бы, все сделано, проведен успешный пилот, но масштабирование проекта «захлебывается». И таких примеров много. Особенно это актуально для крупных компаний или госструктур. Причин этому масса.
В моей практике были проекты, которые я вел и как руководитель проекта и, как куратор, которые «не взлетели».
Идеальное состояние компании для внедрения большой системы, охватывающей множество процессов выглядит примерно так:
Руководство явно осознает проблему и готово заниматься этим лично, включая регулярный контроль проекта.
- Менеджменту доведены четкие критерии успешности проекта и выданы полномочия на реализацию.
- В коллективе отсутствует «саботажное» настроение, либо «саботажники» известны и есть готовность действовать по отношению к ним решительно.
- Существует культура / практика горизонтальных связей при запуске проектов, когда сотрудники одного подразделения становятся временно «приданными» руководителю проекта, и у него нет необходимости согласовывать каждую, поручаемую им задачу с их непосредственным руководством.
У непосредственного руководителя проекта существует достаточный опыт и мотивация, чтобы заниматься данным проектом.
Но, как мы все понимаем, такая «идеальная картина мира» встречается крайне редко. И часто руководство организации, «подписавшись» под всем вышеперечисленным в ходе реализации проекта:
х «сливается»;
х меняет цели или навязывает способы их достижения;
х сокращает объем полномочий руководителя проекта;
х идет на поводу у прямых или косвенных «саботажников».
Примером косвенного саботажа может, например, быть ситуация, когда у руководства смежного подразделения стоят важные задачи, а людей для их выполнения не хватает. В результате горизонтальное проектное подчинение начинает сыпаться. И дальше начинаются конфликты, головная боль у руководства компании по «разруливанию» этих конфликтов и, как следствие, теряется импульс проекта у всех участников.
Но это совершенно не означает, что в данной ситуации во всем нужно винить руководство компании, которое не обеспечило идеальные условия для проекта и не вытащило проект за его непосредственного руководителя.
Приведу несколько примеров из моей практики, когда непосредственный руководитель не имел возможности уделять проекту того объема внимания, которого мне бы хотелось, и что было сделано, чтобы нивелировать значение этого внимания.
Проект внедрения системы управления проектами в Департаменте информационных технологий Правительства Москвы
Проект стартовал в 2011 году. Меня назначили на него РП. Артем Ермолаев — Министр правительства Москвы, руководитель департамента информационных технологий лично презентовал проект всему коллективу и указал на его важность, срочность и т.д. Было отдельно отмечено, что после запуска системы всю информацию по проектам, включая конкурсную документацию, календарные планы проектов он будет смотреть в системе, и даже все согласования будут осуществляться в ней. Успех? Неа. Практически сразу министра завалило миллионом важных задач и вырвать достаточно его внимания на проект стало крайне сложно.
Почувствовав, что можно без последствий «забить» на проект и работать по старинке, большинство тех, кто должен был работать в системе расслабились и началась годовая борьба с саботажем проекта.
Когда стало очевидным, что проект загибается, я решил изменить тактику — перестал мучить министра, уговаривать коллег работать в системе и стал искать союзников.
А союзники нашлись там, где их и не искали. Я интегрировал систему с системой закупок и бухгалтерской системой и нашел тех закупщиков, юристов и бухгалтеров, которых существовавший хаос не особо устраивал. Я показал им, что количество их работы при рассмотрении документации и согласовании ее в электронном виде сократится минимум процентов на 50%. А поскольку ранее к каждому проекту были прикреплены конкретный бухгалтер, конкретный юрист, конкретный закупщик, то договорившись с некоторыми из них я, решив их проблему (много раз пересогласовывать документацию и не быть уверенным, что по пути что-то из согласованного не будет подменено), решил и свою проблему.
Теперь остальные, ранее не присоединившиеся к этому пилоту юристы, закупщики и бухгалтеры, на примере коллег явно увидели свою выгоду – работать меньше, но эффективнее – присоединились к процессу. Проект ожил, и теперь требования к его развитию полились как из рога изобилия. Со временем и те, кто должен был пользоваться системой, смирившись, стали активно помогать и развитию, и проекту.
Второй пример...
Внедрение системы Облачной бухгалтерии во всех органах власти и учреждениях города Москвы
Проект шел более гладко, чем предыдущий, но в нем было несколько лайфхаков.
Перед стартом проекта было проанализировано, в каких системах работает больше всего учреждений. Анализ показал, что это 2 платформы. Они были выбраны в качестве основных.
Решено было строить систему на 2-х платформах. Это, с одной стороны, повысило стоимость проекта на этапе разработки типового решения, но с другой стороны, существенно снизило уровень саботажа среди будущих пользователей. Им не нужно было кардинально переучиваться (стоимость обучения работе в системе, кстати, удалось существенно сократить, что нивелировало большие затраты на разработку платформы на 2-х решениях).
Далее стояли задачи сложности управления проектом по миграции учета со старых систем на новую и управления огромным количеством субподрядчиков (около 100 субподрядчиков).
Была внедрена система внутреннего аудита хода проекта, которая включала контроль качества работы подрядчиков. Более 25% из них пришлось заменить, что придало мотивации к качественной работе остальным. Но самым главным было опять найти союзников, ими стали наиболее проактивные руководители предприятий.
Также важно то, что в процесс был лично вовлечен министр образования Москвы и его первый заместитель. Это позволило использовать данный фактор в качестве кнута для менее проактивных.
Далее были публичные награждения грамотами, ценными подарками наиболее отличившихся руководителей школ и главбухов и формирование из них «трендсеттеров», идеологов. Таким образом начала складываться система, которая уже развивала сама себя.
Важными общими особенностями обоих проектов было то, что в них:
Были применены принципы проектного управления. Методология в данном случае не важна, но мы применяли IPMA. И те, кто работал со мной на проектах прошли обучение.
Везде использовалась аналитика. Были созданы дашборды на которые выводились основные показатели по проектам: сроки, вовлеченность, пионеры, саботажники и т.д.
- На обоих проектах несколько раз пришлось сменить менеджмент, пока не появились те, кто действительно был профессионален и сильно мотивирован.
Когда тактика переставала работать ее меняли. Это как в бизнесе. Тестировались разные гипотезы и подходы. При попытке воспроизводить один и тот же подход, но более интенсивно результат был отрицательный. Поэтому перешли на быструю проверку гипотез.
Проекты развивали в соответствии с теорией малых побед. Решали сначала те задачи, которые требовали минимальных ресурсов. Руководству демонстрировался результат, что позволяло продолжать проекты. Фактически по пути создавались “потемкинские деревни”, которые потом превращались в реальные. Местами использовался стартаперский принцип Fake it till you make it.
При этом важно отметить, что проекты были долгосрочными и заняли от 3-х до 6 лет. Т.е. планирование велось вдолгую. Именно поэтому результаты на промежуточном этапе – must have.
А теперь вопрос: какое отношение это имеет к системам менеджмента знаний?
Давайте посмотрим, что в себя включают системы менеджмента знаний (Knowledge Management Systems – KMS). Крупными мазками:
- База знаний (БЗ);
- Песочница экспертов, которые делятся знаниями и которым можно задать вопрос;
- Извлеченные уроки и лучшие практики (может быть частью БЗ);
- Внутренне обучение;
- Идеи и их реализация;
- Интранет, в т.ч. профили сотрудников.
Чаще всего, когда потребность в управлении знаниями становится осознанной, не знают с чего начать. Начинается минное поле граблей. Нет мотивации создавать знания. Вместо статей — файлы (“Ну а что, мне же проще закинуть файл в систему, чем написать нормальную статью!”). Система обучения оторвана от всех остальных систем в KMS. Делиться опытом вообще никто не хочет. Отвечать на вопросы тем более.
Причин этому тьма, но основные мы уже обсудили выше. Объяснять сотрудникам, что производительность труда повысится, работы станет меньше, их жизнь станет лучше, а они счастливыми двигающими прогресс – утопия. Будет саботаж.
Нужно искать союзников. На каждом предприятии всегда есть те, кто готов к инновациям. Мотивация может быть разной. Кто-то действительно увлечен, т.н. гики. Кто-то из карьеристких побуждений. Причины могут быть разными. НО еще всегда есть и те, у кого правда болит. Только болеть все и сразу не может, поэтому нужны быстрые победы при поддержке союзников и руководстве профессиональными и мотивированными РП.
А еще, ни в коем случае нельзя замахиваться на внедрения KMS в полном объеме. Двигаться нужно маленькими, но быстрыми шагами с закрепляемым результатом. И обязательно нужно эти результаты масштабно освещать и пиарить. Нужна «доска почета», нужны материальные и нематериальные способы мотивации. Кнут понадобится (если понадобится вообще) только после того, как основной этап внедрения пройдет. Тогда явные саботажники и так будут видны, но они, как правило либо смиряются, либо сами уходят.
Но если у вас есть мощный административный ресурс, который считает для себя эту задачу важнейшим приоритетом (такое случается), то путь можно сократить. У меня были такие проекты, но это скорее исключение из правил.
Успехов!
Если нужна помощь с внедрением KMS — пишите.
Наши проекты: Система управления знаниями InKnowledge
Телеграм канал: https://t. me/Knowledge_manage