Многие проекты управления знаниями терпят неудачу, потому что они требуют, чтобы люди делали больше вещей в их повседневной жизни. Реализация любой инициативы QA требует базовых знаний по управлению изменениями и улучшению процессов.
Управление знаниями полно дорогих трупов: документальные системы, которые никто не использует, процедуры, которые никто не применяет, интранет, который служит только для обучения на конференциях и так далее.
В этом типе проекта (и в его кузенах управления качеством) есть основная ошибка: они терпят неудачу, потому что они требуют, чтобы люди делали больше вещей в своей повседневной работе (заполняют форму, кодируют документ, документируют факт), Они также терпят неудачу, потому что они не принимают во внимание первый вопрос, который мы все задаем себе, когда сталкиваемся с какой-либо инициативой: «Что это дает мне?»
Если пользовательский ответ «больше работы», проект, безусловно, потерпит неудачу.
Ошибочно полагать, что этому отношению можно противодействовать, сообщая о преимуществах новой системы, обучая ее использованию или стимулируя к участию.
Специалисты скажут нам, что мы имеем дело с типичной проблемой управления изменениями: « Как заставить людей выполнять свою работу по-разному и / или делать больше? »
Понятно, что если мы продвигаем или «продаем» в нашей организации применение процедуры или системы, которая влияет на рабочий процесс, то это потому, что мы ранее задавали себе два магических вопроса:
- Каковы ключевые процессы, которые повышают ценность моей организации? Как я могу их улучшить?
Это означает, что мы переосмыслили, проанализировали, переосмыслили и упростили любой процесс, прежде чем предлагать процедуру, которая на него влияет. Это также означает, что мы выбрали некоторые из всех возможных процессов.
Чем меньше, тем лучше.
Невозвратный вопрос 01: Это так? Отвечает ли новая процедура или система «реинжинирингу» или предварительному анализу адекватности процесса?
- Если ответ «НЕТ», то, что вы пытаетесь реализовать, наверняка не будет включать в себя больше задач, чем я уже делаю. Вернитесь к стартовой ячейке. Если ответ «ДА» (то есть мы переосмыслили и упростили процесс перед разработкой и продажей системы), мы получим его только в том случае, если в нем задействованы пользователи, клиенты и конечные страдальцы в этом анализе. Мы выдвигаем два квадрата.
Таким образом, у нас уже есть более простой, более эффективный и теоретически более выгодный ключевой процесс для организации. Теперь пришло время разработать систему, которая поддерживает или поддерживает ее, чтобы получить реальное преимущество. Конечно, мы будем задавать больше вопросов:
- Какие знания необходимы? Какие знания генерируются? Как я могу управлять ими? Сколько это будет стоить мне? Это выгодно?
Предположим, мы ответили на все эти вопросы и решили (с утверждением вышеизложенного) продолжить. Я стреляю, потому что это касается меня. Мы падаем в колодец и обнаруживаем, что система выходит из строя.
Вопрос без возврата 02: привлекали ли мы конечных пользователей (в достаточном количестве и с разными профилями) на протяжении всего процесса разработки решения (будь то процедура, система управления документами или любые другие знание)?
- Если ответ «НЕТ», процедура встретит сопротивление, которое не будет преодолено ни обучением, ни стимулами, ни угрозами. Это потребует «возврата» и просмотра его шаг за шагом с выбранной группой пользователей. Это замедлит проект и увеличит его стоимость. Назад десять ящиков. Если ответ «ДА» (то есть мы не только упростили процесс с помощью тех, кто его применяет, но у нас также были конечные получатели системы при ее разработке), мы найдем выигрышный продукт в наших руках. Продвижение к Гусю.
Не забудь об этом…
- Никому не нравится, когда им говорят, что их образ действий или работы не работает или ошибочен. Поэтому любой проект изменений должен основываться на внешних причинах (потребности рынка, появление новых технологий и т. Д.), Чтобы люди понимали необходимость изменений.Не приветствуется и то, что они говорят вам, что вы должны изменить несколько или много вещи, которые вы делаете Вот почему лучше начинать только с тех критических аспектов процесса, которые необходимо изменить. Чем меньше, тем лучше. После того, как эти изменения будут усвоены, мы сможем перейти к другим. Очень важно, чтобы эти изменения были спонсированы «сверху». Но в равной степени важно, чтобы это воспринималось не как навязывание, а как необходимость, основанная на очень четких факторах (прибыльность, потребности клиентов и т. Д.) И хорошо информированная.Одним из фундаментальных условий для работы системы является то, что ее пользователи с самого начала участвовали во всем процессе проектирования и разработки. Никто не знает о чем-то больше, чем кто-то должен это использовать.
