Существует несколько вариантов запуска внедрения и самого внедрения. Я знаю следующие алгоритмы:
1. Ставится задача перед внешним провайдером - Команда внедренцев прорабатывает проект - Проект презентуется руководству заказчика - Проект внедряется директивно сверху-вниз
2. Ставится задача перед внутренним подразделением - Прорабатывается проект - Внутреннее подразделение занимается внедрением внутри организации
3. Ставится задача - собирается команда "внедренцев", включая заинтересованных лиц и руководство организации - распределяются роли - прорабатывается проект на всех слоях организации - внедряется там, где требуется
Я назвала основные возможные пути развития. Их сочетаний в действительности гораздо больше, но основное отличие - это вовлечение заинтересованных лиц, включая непосредственных пользователей внедрения, или их исключение.
Не так давно пыталась прорисовать возможные вариации развития событий в зависимости от выбранного варианта, учитывая риски, плюсы и возможности.
Конечно, основным критерием успеха любого внедрения в организации является вовлечение его руководства. Это обязательное условие, но, увы, недостаточное.
Директивный способ распространения информации не дает гарантии его принятия - в большинстве случаев данный способ дает обратный эффект в виде итальянской забастовки.
Как правило, если процесс или необходимость его внедрения/изменения не принят на местах, то люди будут только имитировать его реализацию, продолжая выполнять свою работу так, как считают нужным, удобным, эффективным - "мало ли что там кажется наверху - мы то эксперты своего дела!". Без поддержки руководства мероприятие маловероятно будет успешным - "что-то сами там придумали, не зная бизнеса, и теперь пытаетесь нам это навязать, даже руководство не принимает это, лучше работать как работали - только время наше тратят".
Мой опыт субъективен, но тем не менее. Намного проще продвигать идею, если в процессе подготовки и самого внедрения участвуют не только руководители высшего звена, но и те, кто впоследствии будет использовать внедряемый продукт в своей работе.
Это не означает, что конечных пользователей нужно привлекать сразу же для разработки продукта - важно определить тот момент, когда их обратная связь и даже помощь в виде экспертизы не только желательна, но и обязательна.
В своей работе, при разработке электронных курсов, моделей профессиональных компетенций или автоматизации процессов, я всегда использовала экспертизу экспертов стороны пользователей - только они могут по достоинству оценить конечный результат.
Думаю, проще потратить усилия на начальном этапе, чтобы сделать из них союзников и приверженцев продукта на этапе разработки, чем вкладываться в рекламу и продвижение того, что на входе не принимается, так как "их не спросили, не учли, не подумали".
Да, заказчики, как правило говорят, что им нужно готовое решение и чтобы их не трогали - "просто дайте нам то, что мы хотим!". Но чаще всего угадать правильный вариант без уточнения у заказчика пожеланий и видения, его заочного принятия, практически невозможно - итогом является решение "не его, заказчика".
Если заказчик не находится в команде "внедренцев" в качестве "главного" эксперта, это означает, что этап "установление контакта" проигнорирован и не пройден. В итоге существует риск, что он в итоге не примет окончательный вариант внедряемого продукта, так как у него не было возможности принять его в качестве "своего" решения. Для "своего" мы всегда найдем аргументы в его пользу - для принятия "чужого" решения требуется сильная аргументация и желание принятия, что часто не хватает в действительности.
Почему же мы чаще всего предпочитаем исключать заказчиков и конечных пользователей из процесса разработки?
С уважением,
Денисова Елена
Комментариев нет:
Отправить комментарий