Что сложнее - создать что-то новое, или это новое внедрить? Практически любой асушник скажет - внедрить. И будет почти всегда прав. Исключение составляют лишь те сказочные ситуации, когда создается нечто такое волшебно простое и нужное, что само себя внедряет. Эдакий философский камень, который всё может превратить в золото, и никого не надо уговаривать им пользоваться. Но, честно говоря, я не могу вспомнить таких случаев, когда сложные системы внедряли бы себя сами. Однако ради научной строгости мы должны обращать внимание и на такие потенциально возможные ситуации.
И тем не менее, раз мы - сугубые практики, мы, как никто другой, знаем, что сложнее всего - именно внедрение. Особенно, когда это касается систем, которые делают достаточно простые вещи. Причины такой сложности мне здесь не очень важны (о них напишу как-нибудь потом), но важны сами механизмы внедрения.
При этом особый интерес представляют проекты внедрения, в которых речь, кроме всего прочего, идет об изменении мировоззрения пользователей. Например, внедрение системы документооборота. Или внедрения системы управления производственной деятельностью проектного института. Или системы экспертной поддержки принятия решения в контуре оперативного управления. Или системы производственного диспетчерского управления.
Я специально перечислил такие области, в которых сегодня соответствующие задачи уже решаются, традиция их решения имеет историю в несколько десятков лет, и многие поколения специалистов и управленцев "стопроцентно знают", как всё надо делать.
И вот теперь перед нами стоит задача - внедрить что-то существенно лучшее по эффективности и совершенно другое по культуре. Проблема внедрения для опытного асушника очевидна.
Здесь просматривается три основных подхода.
Подход первый - толкать.
Именно этот подход, как правило, везде и используется. Все элементарно, как лом! Вменяем в обязанности, проводим обучение, ставим рядом "нянек", чтобы за руку водили, пока новички будут осваивать азы, а также ставим "погонял", которые будут создавать мотивацию, пинками загоняя личный состав системы управления в светлое кибернетическое будущее.
Подход второй - тянуть.
Встречается очень редко и, как правило, только в очень больших проектах. Когда надо, например, внедрить систему модельного обеспечения процессов прогнозирования. Думаю, что вы о таком и не слышали. Но оно и понятно - сейчас вы не найдете мест, где было бы действительно внедрено модельное обеспечение процессов прогнозирования состояния сложных объектов и ситуаций. Но суть подхода "тянуть" в том, чтобы создать у потенциально заинтересованных лиц, принимающих решение, такой образ будущего, который потом бы у них в критических ситуациях всплывал в мозгу примерно таким образом: "Эх, была бы у меня сейчас та система поддержки принятия решений, которую мне показали (например, в кино), я бы сразу десяток вариантов решений смог бы проработать, а так - и на один-то сил практически нет". И это работает! Если дать "прилипчивый" образ будущего, то он, в итоге, заставит человека сделать шаг в это будущее.
Подход третий - провокация.
Ничего не навязывать и ничем не вдохновлять. А давить задачами и наказывать за провалы так, чтобы у человека, на рабочее место которого или в соответствующую вверенную ему систему управления внедряется новое, естественным образом возникла бы потребность в прогрессивных системах поддержки принятия решений. Однако категорически необходимо давать такому горемыке (а мне его действительно жаль) базовые знания. Иначе такого с дуру нафантазирует, что ... даже вспоминать не хочется про таких фантазеров. В голове у них обычно куча-мала из обывательских представлений о том, как должны работать системы поддержки принятия решений, особенно в условиях высокой неопределенности и конфликта.
На Катакомбе есть и более детальные описания каждого подхода, с описанием конкретных решений и того, как они работают на главную цель - на мотивацию персонала систем управления и ЛПР к совершенствованию систем поддержки принятия решений.
Но самое главное в том, что всегда надо применять сразу три подхода: и тянуть, и толкать, и провоцировать одновременно. Наличие и доля каждого из них в проекте внедрения сильно зависят от конкретики самого проекта и условий его реализации. И тут есть много разных индикаторов, анализ которых позволяет более менее рационально сформировать стратегию внедрения.
Но самая главная аксиома в том, что не существует подходов, механизмов, стратегий и т.п., которые могли бы гарантировать внедрение сложных систем поддержки принятия решений в заданные сроки и при выделенном ресурсе. Это самые рисковые проекты. Поэтому только дурак откажется в таких проектах от помощи тех, кто уже шишки набил. А полный дурак понадеется на "бест-практики".
Такая вот аксиома № N.
ЗЫ. Ну а если какому-то товарищу прапорщику покажется мало N, то пусть будет M !