лабораторная. Внедрение ИС. Нарваткина Н. С. Внедрение информационных систем 2019
 Скачать 0.94 Mb.
|
|
Сценарий поэтапной замены Один из возможных способов поэтапной замены старой системы — бережное внедрение. Перечисляемая ниже последовательность не является догмой — некоторые этапы могут быть переставлены местами. Рассмотрим информационную систему предприятия, состоящую из нескольких компонентов (см. рис. 1). Унаследованная система, подлежащая замене, выделена красным цветом. Рассмотрим самый сложный вариант — замену одной из ключевых информационных систем предприятия, которая поддерживает повседневные бизнес-операции и тесно интегрирована с другим программным обеспечением. Остановка или перерыв в работе такой системы лишает персонал возможности выполнять производственные обязанности и влечет за собой массу неприятных последствий, вплоть до прямых финансовых убытков. Как правило, подобные системы активно взаимодействуют со своим ИТ-окружением, происходит оперативный обмен документами и данными (в том числе мастер-данными) с другими транзакционными или справочными приложениями (системы 1 и 2 на рис.1). С системой работают бизнес-пользователи, данные из нее выгружаются в различные BI- приложения и системы учета «постфактум». Например, выгрузка документов для целей бухгалтерского учета или периодическая выгрузка операций в систему формирования корпоративной отчетности. Такие выгрузки на рисунке обозначены пунктирными линиями к системам 3–5 на рис.1. Этап 1. Анализ ситуации и выбор функционала для замены Сначала необходимо определить в заменяемой системе ключевой функционал, который нужно изменить в первую очередь. Для его замены выбирается и адаптируется наиболее подходящее готовое решение или создается (по сути, разрабатывается) новое решение. Готовых рецептов выделения участков для первоочередной замены не существует. Это скорее искусство, чем известная формальная процедура. Основная цель на этом этапе — получить наибольший эффект от новой системы путем снятия самых острых проблем. Если решено сменить старую систему из-за ее неспособности поддерживать необходимые темпы изменений и реализовать новый функционал, то, скорее всего, внедрение новой системы стоит начать с поддержания именно этих новых функций. Заказчиком изменений в этом случае чаще всего выступает бизнес. Если же причины для смены унаследованного ПО лежат в технологической плоскости (устаревшая ИТ-платформа, потеря ключевых разработчиков, проблемы с производительностью), то для первоочередной замены имеет смысл выделять критические для устойчивости, безопасности или масштабируемости участки системы. В данном случае инициатором изменений, скорее всего, будет выступать ИТ-подразделение. При планировании этого и последующих этапов нужно учитывать, что размер каждого изменения (нового внедряемого функционала) не может быть очень большим, чтобы, в том числе, не потерялся темп изменений. На всех рисунках красными стрелками обозначены связи между системами, которые подлежат замене или удалению на очередном этапе бережной замены. Этап 2. Включение новой системы в работу По окончании первого этапа можно перевести часть пользователей на работу в новой системе (см. рис. 2), которая связана со старой, и обе функционируют одновременно. По мере замены функционал новой системы нарастает, а старой — постепенно отмирает. Поскольку старая система еще поддерживает некоторые ключевые операционные процессы, в нее продолжают вноситься соответствующие изменения. Эти изменения должны также поддерживаться и в новой системе. Вероятно, на этом этапе потребуется синхронизация данных старой и новой систем в реальном времени. Очень важно при проектировании разделения функционала систем добиться того, чтобы пользователям не приходилось работать в двух системах одновременно. Когда, например, часть документов по-прежнему ведется в старой системе, а часть — уже в новой, пользователям новой системы необходимо обеспечить «прозрачность» работы: они должны видеть все документы. Для этого необходимо установить связь — обеспечить соответствующие интерфейсы между системами. Успех существенно зависит от открытости — возможности доработки и адаптации — заменяемой и новой систем. Как правило, в каждом конкретном случае такие возможности находятся — либо через доступ к базе данных или стандартный интерфейс обмена данными, либо в результате разработки дополнительных программных интерфейсов. Если же таких возможностей нет, то вполне вероятно, что сценарий бережной замены реализовать не удастся. Этап 3. Лишение самостоятельности На этом этапе мы можем перевести всех пользователей на работу в новой системе (см. рис. 3). Из старой системы данные передаются в новую по мере необходимости. Весь информационный обмен предприятия по-прежнему осуществляется через старую систему. В результате новая система бесшовно встроена в старый ландшафт: ее внедрение повлияло только на работу заменяемого приложения. Другие информационные системы практически не затронуты. Новая система общается с ними через посредничество старой. Такая схема на некоторое время усложняет информационную систему предприятия в целом, но при этом подготавливает плавную замену старой системы на новую. Параллельно могут быть установлены связи и непосредственный обмен данными новой системы с прочими компонентами информационной системы предприятия (синие стрелки на рис.3). Этап 4. Переключение информационных потоков Теперь переключаем все входящие информационные потоки на новую систему (см. рис. 4). Заменяемое приложение становится фактически офлайновой системой. При необходимости (например, для формирования корректной отчетности) данные из новой системы выгружаются в старую. Таким образом, старая система превращается в «адаптер» для новой, и он интегрирует ее в существующий ИТ-комплекс предприятия. На этом этапе имеет смысл остановить развитие старой системы. Отныне все новые возможности для поддержки бизнес-функций стоит создавать только в новой. Если раньше, на предыдущих этапах, требовалась синхронизация в реальном времени заменяемой и новой систем, то теперь от нее можно отказаться и перейти на периодические асинхронные (ежедневные, еженедельные и т.п.) выгрузки данных из новой системы в старую. Это сильно упрощает работу информационной системы предприятия в целом. Этап 5. Переключение оперативного информационного обмена и ликвидация Из старой системы по-прежнему выгружается редкая отчетность и данные для учета «постфактум». В таком виде (см. рис. 5), с «прозрачной» для пользователей старой системой предприятие может существовать как угодно долго, но для упрощения ИТ- ландшафта все-таки необходимо провести ее ликвидацию. Информационные потоки по мере выявления переносятся или переключаются на новую систему. Именно на этом этапе в какой-то момент принимается волевое решение об остановке старой системы (см. рис. 6). Дополнительные комментарии Мы рассмотрели случай замены «один на один». Возможны различные варианты: новая система заменяет собою несколько старых или одна унаследованная система заменяется на несколько новых. В любом случае можно провести замену, следуя приведенным выше этапам бережного внедрения. Описанная нами последовательность этапов может быть избыточна. На практике, в зависимости от свойств конкретных систем, некоторые шаги можно будет пропустить. Принципиально важно, чтобы новая система была доработана до такой степени, чтобы ее можно было бесшовно встроить в существующий ИТ-ландшафт. Понятно, что сценарий бережного внедрения требует проработки с руководством предприятия концептуальной архитектуры и проекта модернизации информационной системы в целом. Руководству важно представлять, из каких компонентов состоит ИТ- ландшафт предприятия и какие последствия для бизнеса возникнут на каждом этапе бережной замены. Необходима высокая квалификация исполнителей проекта внедрения новой системы. Исполнители подрядчика должны глубоко погрузиться в предметную область предприятия- заказчика — чтобы бизнес-процессы не страдали ни на одном из этапов. Они также должны разобраться в деталях реализации старой системы — чтобы корректно поддержать перенаправление информационных потоков на различных этапах замены. Должна существовать возможность адаптации нового решения под бизнес-процессы предприятия. Без этого условия невозможно смягчить болезненный процесс переключения бизнес- пользователей на работу в новой системе. Необходимо понимать, что запустить процесс бережной замены можно только при определенной открытости старого решения. Сценарий бережного внедрения неоднократно реализовывался нами на практике: мы проводили замену чужого ПО, модернизировали собственные морально устаревшие разработки и даже содействовали управляемой ликвидации собственных систем. Сценарий бережного внедрения незаменим в «боевых условиях», когда бизнес заказчика не может быть остановлен ни на минуту. Более того, такой сценарий позволяет поддержать темпы развития ПО в соответствии с требованиями бизнеса. Процесс внедрения управляем и предсказуем в любой момент. "МЯГКОЕ" ВНЕДРЕНИЕ ИЗМЕНЕНИЙ Организационные изменения Эта статья на тему, которую автор затрагивал в трех своих книгах, пытался раскрыть в семинарах, и которую не рассчитывает сколь-нибудь полно проработать и здесь – в лучшем случае осветить еще один аспект. Внедрение изменений на предприятии. То, что составляет 90% работы топ-менеджера, то, за что имеет смысл платить консультанту. То, что позволяет фирме развиваться. Существует масса теорий о «самообучающихся» и «саморазвивающихся» организациях, для которых вопрос изменений вроде бы и не стоит. Однако, как практик, много лет занимающийся внедрением изменений, рискну заявить: «саморазвивающаяся» организация движется в нужную сторону, когда ее удается заставить. В противном случае «коллективный разум» поддается коньюктурному давлению сиюминутных интересов, фактору сохранения стабильности отношений, решает важнейшие задачи лишь в рамках сложившегося баланса власти и имеющейся корпоративной культуры. Он готов, по примеру Форда, «красить машины в любой цвет, пока он остается черным». В жизни каждого предприятия существуют этапы, когда изменения должны проводиться насильственно, поскольку требуют от людей выполнения новой для них работы, новой системы отношений, новой ответственности за результат. Это происходит, когда фирма вырастает из «семейной» структуры 40 чел. численности, и экстенсивное развитие только снижает ее эффективность. Это происходит при освоении новых рынков и создании новых подразделений. Это происходит при переходе на холдинговые отношения, слиянии, поглощении, разделении компаний. И это вновь происходит в холдинговых подразделениях, которые, в свою очередь, растут от «семейных» структур до дивизиональных, сливаются, делятся – совершенствуются. Термин «насильственно» тем не менее, не предусматривает исключительно силового давления в проведении реформ. Наоборот, именно жесткие методы внедрения часто дают противоположный желаемому эффект. Если бы битьем удавалось добиться от коровы молока, «удои» на ниве управления превзошли бы любые ожидания. Фирме действительно нужно, чтобы люди делали конкретную новую работу, но далеко не безразлично, как они ее будут делать. На одном предприятии, например, консалтинговая фирма блестяще разработала новую схему учета эффективности производства. Благодаря жесткому стимулированию (не справился – «на вылет») загрузка производственных мощностей поднялась с 80% до 96%. Однако спустя 3 месяца ряд ключевых специалистов уволился, оставив фирму на уровне 73% загрузки, превысить который она уже не могла. В другом случае была разработана комплексная стратегия холдинга, чей менеджерский состав «вписали» в схему с помощью должностных инструкций и контроля за рабочим временем. Почти год фирма успешно «раскручивалась», а потом три года уверенно «тормозила», поскольку снова и снова приглашать консультантов для коррекции стратегий в меняющейся рыночной ситуации казалось нерентабельным, а своих менеджеров уже приучили следовать букве инструкции под страхом увольнения. Наконец, показателен пример фирмы, в которой жесткими методами не удалось добиться даже временных результатов. Там директор по маркетингу, наделенный чрезмерными полномочиями, пытался заставить сбытовиков собирать рыночную информацию (что само по себе имеет смысл). Не найдя взаимопонимания, он начал штрафовать менеджеров по результатам каждого дня, дойдя к концу месяца до 90% вычета из их зарплат. В ответ сбытовики принципиально не продавали ходовую продукцию со склада, грамотно спланированного директором по маркетингу, предлагая клиентам работать с аналогами под заказ. (Решением затянувшегося конфликта стало увольнение всех его участников). «Мягкое» внедрение – это разработка необходимых систем и технологий силами менеджеров предприятия. «Насильственность» заключается в том, что людей заставляют разрабатывать нужные вещи с нужным качеством в нужный срок. Для этого необходим «двигатель прогресса», которым обычно выступает руководитель, и консультант (которым может быть тот же руководитель, если изменения производятся самостоятельно). Этот подход требует бόльших затрат времени на подготовительном этапе, но имеет ряд несомненных преимуществ. Во-первых, то, что человек «изобрел сам», он понимает, и, скорее всего, готов выполнить. Во-вторых, он способен изобрести нечто похожее (скорректировать технологию) при определенных изменениях ситуации. В-третьих, стоимость консалтингового сопровождения (если оно вообще применяется) на порядок ниже стоимости проекта «под ключ», который, к тому же, не всегда работоспособен. Мы будем рассматривать изменения с помощью консультанта, т.к. наибольший опыт автора наработан именно в данной области. Хотя, повторюсь, своевременная коррекция технологий по ситуации – постоянная задача руководителя фирмы, которую он должен решать независимо от доступности консалтингового ресурса. Диагностика предприятия Диагностика, проводимая консультантом, имеет целью, в том числе, создание предварительного плана реформ. Итог в виде списка проблем, которые надо решать, или абстрактной картины «светлого будущего» не имеет для заказчика смысла. Первое он, в основном, знает, разве что описывает «ненаучными» терминами, второе может увидеть в любом учебнике. Основной результат дает как раз внедрение, поэтому именно оно начинает прорабатываться с первого момента диагностики. Главным методом является обычно глубинное интервью – разговор «тет-а-тет» с руководителями бизнеса, ключевыми менеджерами и специалистами на ответственных участках. Кроме снятия действительно глубинной информации о предприятии (вплоть до признаний менеджера в воровстве с разъяснением, как и почему он ворует – случай из практики), интервью позволяют выявить, какие идеи сотрудники предприятия выдвигают, какие поддерживают, и каким противостоят. Это дает консультанту картину будущего сопротивления изменениям (в том, что оно последует, можно не сомневаться). В беспроблемных случаях (т.е. в отсутствие конфликтов на предприятии и относительно общем понимании цели) во время диагностики можно начать и более масштабную подготовку – обсудить с менеджерами свои гипотезы о путях и методах развития предприятия, получить предварительное согласование новых идей. В ряде случаев согласие будет достигнуто, в других – сформулированы позиции сторон, что позволит грамотно спланировать политику внедрения. Отчет по результатам диагностики содержит основные характеристики цели, путь и методику ее достижения (безразлично, решается ли задача построения сбытовой сети, структуры или системы управления холдингом). Формулируется суть, а не детали, предлагается метод, а не инструкция. (Детальная проработка многоступенчатого алгоритма здесь просто не имеет смысла, т.к. без изменений может быть внедрен только первый шаг). Отчет включает как факты, подтвержденные данными предприятия, так и гипотезы о работе новой схемы. Для проверки гипотез нередко планируется эксперимент. Проект базируется на имеющихся или доступных людских ресурсах, которые уже наложили ограничения на спектр возможных решений. Реальное внедрение изменений начинается с презентации отчета заказчику. Предложенная программа почти всегда требует изменений в первую очередь от него. Иногда речь идет об отказе от привычных методов стимулирования персонала. Часто – о новых полномочиях владельца и топ-менеджеров. В случае нескольких собственников это может быть перераспределение их обязанностей. Отчет, одобренный в общем и целом, может вызывать сопротивление заказчика в части, требующей новых для него действий, отношений, делегирования полномочий. На этом этапе необходимо получить согласованную программу внедрения, которую будет осуществлять, главным образом, заказчик. Для проведения реформ в короткие сроки желательно подкрепить экспертную власть консультанта властью должности руководителя (при самоустранении руководителя от внедрения процесс затягивается раза в три). Руководителю не обязательно соглашаться со всеми пунктами отчета. Например, нередки разногласия в части перспектив «любимых» бизнесов – «красивого магазинчика», «карманного турагентства», и т.п. Но главная линия изменений должна одинаково пониматься заказчиком и консультантом. В практике автора, в начале консультационной деятельности, был случай, когда заказчик «предпринял волевое усилие» для согласования позиций. Не будучи убежден в предлагаемых мерах, он, тем не менее, озвучил их персоналу на общем собрании. Ему пришлось выступать по бумажке и отказаться от ответов на вопросы. В результате реформы затянулись на три месяца, т.к. персонал, чувствуя неуверенность руководителя, активно сопротивлялся переменам. Говоря о согласовании позиций, нужно понимать, что оно должно быть сознательным, и задачей консультанта является достаточное обоснование предлагаемых мер. Процесс внедрения Формальным началом внедрения изменений обычно является презентация отчета ключевому персоналу (практически тем людям, с которыми консультант проводил интервью). Иногда заказчик сокращает материал в части рекомендаций руководству и принципов стимулирования. Отчет предварительно раздается для изучения, а затем презентуется консультантом – не как догма, а в качестве схемы, требующей доработки совместными усилиями. Программа реформ принимается «на ура», и … ни один человек не выполняет ни одного нового действия, даже если эти действия прописаны по часам. Почему это происходит? Во-первых, принимая программу в целом, каждый одобрял изменения, которые должен в своей области провести сосед. «Отдел снабжения действительно должен добиваться лучших скидок от поставщиков, маркетологи – давать больше информации, а директор – делегировать больше прав. А что касается сбыта, – тут как раз и нужна доработка, позволяющая применять старую технологию, поскольку она единственно верная». По отношению к собственному отделу каждый способен привести «непробиваемые» доводы, почему именно там не нужно ничего менять. Так, на предприятии, где сбытовики работали в одном большом зале, начальник отдела с выкладками и фактами объяснял преимущества информационного обмена в едином помещении. На фирме, где продавцы сидели в пяти разных комнатах, начальник доказывал необходимость тишины, позволяющей сосредоточиться. Оба были весьма убедительны, и оба отказывались понимать, что возможны другие решения по размещению. Что уж говорить о технологии продаж… Во-вторых, предлагаемые реформы затрагивают «сквозные» процессы, требуют согласованных действий разных людей и отделов. Каждый из них не слишком верит в готовность других к реформам, и, по крайней мере, ждет, что сосед начнет первым. В-третьих, даже в отсутствие предыдущих факторов, остается неясность: когда именно и как начинать, какой сделать первый шаг? В общем и целом, все понятно, но что касается конкретики…? Наконец, если новые действия запланированы для руководителя, «хорошим тоном» будет подождать, пока он своим примером «даст отмашку». Чтобы дело сдвинулось с мертвой точки, необходимо явным образом определить, кто, что и когда будет делать. Причем эту нагрузку менеджеры должны взять добровольно (пусть даже потому, что не найдут достаточных аргументов против). Поскольку позитивные изменения в «епархии» соседа приветствует каждый, работу по раздаче ответственности лучше вести коллективно, в совете директоров (менеджеров). Тогда по любому конкретному вопросу руководитель будет иметь большинство в лице тех, кому этот вопрос решать не придется, и одного «сомневающегося» (сопротивляющегося), от которого требуется решение. Здесь важно обсудить последовательность действий по каждому пункту программы и по конкретным шагам, наметить сроки выполнения. Нужно, чтобы сроки устанавливали сами исполнители – только в этом случае они берут на себя ответственность перед руководством и коллегами. (Если устанавливать даты сверху, работает алгоритм: «попробую – а там что получится»). На этом этапе стоит подготовиться к аргументам, что «У нас есть текущая работа, которую никто не отменял. Сделаем, если успеем». Ответ выглядит примерно так: «В сутках 24 часа, в неделе 7 дней. Реформу можно провести в сжатый срок, но нельзя перепрыгивать пропасть мелкими шагами». Реальный резерв ресурсов лежит в делегировании привычных полномочий от начальников отделов подчиненным менеджерам – в половине случаев руководители высвобождаются для новых дел. На первом совещании по запуску изменений надо попытаться обсудить всю последовательность новой работы по всем направлениям. Иногда это не получается, т.к. много времени занимает пошаговое рассмотрение отдельных технологий. В этом случае оставшиеся вопросы обсуждаются через неделю, т.к. у людей действительно есть текущая работа, а с другой стороны, им необходимо свыкнуться с мыслью о переменах. Все сроки по всем работам сводятся в таблицу руководителем, возглавляющим проект, и разбиваются по контрольным точкам. Каждое задание, пусть и с трехмесячным сроком исполнения, контролируется с интервалом раз в неделю. Обычная картина изменений такова, что человек вспоминает о «домашнем задании», которое ему не так уж хочется выполнять, только к сроку сдачи. Если проработка занимает три месяца, и в процессе не контролируется, руководитель получит через 90 дней отписку на страницу или перечень причин, по которым к заданию не приступали. Еженедельное обсуждение промежуточных результатов, во-первых, показывает серьезность намерений руководителя в отношении реформ, во-вторых, заставляет менеджеров поддерживать исполнительскую дисциплину (краснеть раз за разом на еженедельных совещаниях из-за невыполнения взятых на себя обязательств достаточно неприятно – не то, что раз в три месяца), в-третьих, еженедельный режим позволяет уточнять и корректировать вводимые технологии, взвешивая реально достигнутые результаты. Обычно совещания проходят с участием консультанта, который работает как с коллективом, так и с отдельными руководителями по их проблематике. Руководитель проекта может (и желательно, чтобы он это делал, несмотря на загрузку собственными разработками) обсуждать реформы с отдельными менеджерами дополнительно к сетке совещаний. Намеченные на первом этапе сроки практически не могут быть выдержаны. Несмотря на обсуждение основных шагов, менеджеры не представляют действительный объем работ по реформам. Через две-три недели сроки должны быть скорректированы, и уже тогда руководитель должен требовать от менеджеров их преимущественного соблюдения. Темпы реформ должны быть максимальными, которые способен выдержать персонал. Процесс изменений никогда не идет гладко и плавно. Для преодоления привычных представлений большинства менеджеров необходимо множество подходов – практически «баталий» за утверждение новых точек зрения. Если руководитель с менеджером четко договорились, как должна выполняться работа, менеджер выполнит ее все-равно по- другому. Коллективно решили ввести прямые продажи – начальник сбыта станет корректировать систему скидок для дилеров. Договорились о делегировании полномочий – менеджер снова придет за инструкциями. Решили собрать новую информацию – в новый отчет будет внесена старая. Сделать работу привычным образом на порядок легче, чем изобрести новое, даже если оно буквально разложено по операциям. При первой итерации руководитель обсуждает с менеджером новые технологии, полномочия, ответственность, перспективы. При кажущемся полном взаимопонимании, менеджер на самом деле усвоил лишь часть – какими будут его статус, власть и зарплата. Естественно, что он все делает по-старому, максимум, с «косметическим ремонтом». Вторая итерация (обсуждение того же самого) снова дает иллюзию взаимопонимания, но, «наученный горьким опытом», руководитель уже готов поймать менеджера «за руку», когда тот выйдет за рамки соглашения. И его ожидания оправдываются – менеджер начинает строить схему, которую видел на прежнем месте работы. Все просто: с ним говорили, что нужно делать, но забыли сказать, чего делать нельзя. После третьей итерации соглашение уже имеет шанс сработать, но, если менеджеров на фирме десяток, и с каждым нужно по три раза проговаривать одно и то же, руководитель проекта должен запастись терпением. (Консультант может снять примерно половину нагрузки по согласованиям, но не решить проблему в целом). Кроме стержневых, заранее проработанных вопросов, множество решений должно приниматься в процессе внедрения. Разработка технологий менеджерским составом не уловка, а реальный способ преобразования бизнеса. По отдельным моментам следует ожидать несовпадения точек зрения руководителя проекта, консультанта и ответственного за участок менеджера. Проблемные вопросы всесторонне рассматриваются, после чего решение принимается руководителем проекта. Однако если вариант, предлагаемый менеджером, в принципе работоспособен, решение должно быть принято в пользу данной точки зрения. В этом случае менеджер приложит максимум усилий для достижения результата (а в противном – будет иметь моральное оправдание саботажа). После того как топ-менеджмент, наконец, выработает общую линию поведения, весь процесс практически полностью повторяется. Теперь в целесообразности и возможности реформ предстоит убедить следующий уровень иерархии – рядовых менеджеров, которые и будут выполнять работу. Здесь заказчиками внедрения выступают руководители отделов, и уже они по три раза договариваются с подчиненными об одном и том же, пытаясь получить конструктивное сотрудничество. Проработка реформ изначально идет устно и письменно: обсуждаются варианты решений, затем менеджеры по своим зонам ответственности письменно фиксируют достигнутые соглашения. На первом этапе подготовленные документы не соответствуют договоренностям. Приняв под давлением аргументов коллег одно решение, менеджер вписывает в технологию другое – свое. Если письменной частью пренебречь, при иллюзии общего согласия каждый будет делать примерно то, что делал всегда. За две-три итерации документы приводятся в соответствие с решениями, и тогда им может быть придан статус закона. Следующим серьезным этапом внедрения является переход от проработки технологий к реальному их выполнению. Здесь менеджеры уже свыклись с мыслью, что когда-то жить придется по новой схеме, но не готовы применить ее прямо сейчас. Как всегда, не хватает людей, времени и денег, подготовлена только часть решений, а «текучки» стало не меньше, а больше. Тем не менее, готовые технологические цепочки необходимо внедрять в практику параллельно с проработкой «полуготовых» - иначе вся процедура будет иметь абстрактный смысл, и внедрение просто не состоится. Для перевода в практическую плоскость необходимо еще одно «волевое» усилие руководителя, который должен «пробить» в совете менеджеров решение о дате старта. Когда разработанная технология внедряется в практику, все принятые ранее решения, пусть даже оформленные документально, могут быть оспорены менеджерами. На момент, когда они принимались, мало кто представлял, что на практике означает то или иное соглашение. Например, договариваясь о преимущественно рыночных целях Торгового Дома в холдинге, директор производства не думает повышать качество своей продукции. При запуске новой схемы он сталкивается с отказом со стороны сбытовиков брать неликвиды и брак, что, естественно, вызывает желание пересмотреть договоренность. Пересмотр основных соглашений имеет смысл блокировать (предполагается, что начальная проработка была обоснованной), детали на данном этапе могут быть уточнены. Т.к. наличие и подтверждение договоренностей не означает их исполнения, несколько рабочих циклов каждой новой технологии должны пооперационно контролироваться. Весьма вероятно, что на первом шаге персонал выполнит только четверть операций, проигнорировав клиентскую, информационную, учетную части. Если изначально требовать полного выполнения принятых решений, новый порядок работы будет введен относительно безболезненно. В противном случае в традицию войдут полумеры, которые потом будет сложно скорректировать. |