Как провести изменения и остаться в живых

04.08.17

Управление проектом

Неважно, запланирован проект в вашей организации или сторонней, главное – чтобы он был успешно реализован. Но что значит «успешно реализован», и как этого действительно добиться? Ответы на эти вопросы предложены в статье.

Вместо вступления

Мы привыкли к идее, что изменения в организации необходимо проводить как "проекты". Но очень часто случается печальная ситуация, когда проект призван обеспечить изменение и даже запускает изменение, но потом это изменение затухает, глохнет. Обычно это объясняют тем, что проект управлялся плохо. И бросаются организовывать обучение управлению проектами или создавать проектный офис.

На самом деле проект здесь ни при чем. Заглохло изменение, потому что никто им не управлял. Более того, если вы работаете у стороннего заказчика,  то управление изменениями – это не ваша прерогатива. Управление изменениями – это прерогатива заказчика, это его изменения. Но поскольку организациям редко приходится заниматься изменениями, они просто не умеют им управлять. И, значит, вам придется помогать заказчику и в этом.

Если вы не понимаете, как проходят изменения, тогда шансов,  что ваш проект будет успешным, немного. В 3 случаях из 4 изменения проходят, как получается. И по статистике, 75% IT-проектов неуспешны. То есть они либо не попадают в график по времени, либо не попадают в бюджет, либо то, что делается, не соответствует техзаданию. А бывают и такие ситуации, когда все соответствует требованиям, но изменение никому не нужно.

Почему проекты не получаются? И, главное, каким образом они "не получаются"?

1.       Изменения даже не начинаются.

Почему не происходят изменения, хотя текущее положение дел никого не устраивает? Например, потому что оно кого все-таки устраивает. Или кто-то боится, что станет хуже. Или кому-то непонятно, что именно надо менять. Еще есть люди, которые говорят, что все перемены ведут к худшему, и вообще что-то менять бессмысленно. 

2.       Изменение, вроде, началось, но застряло.

В чем это выражается? Например, в том, что начальство с одной стороны изменения подталкивает, а с другой – тормозит. Или вообще все сроки прошли, потихоньку  что-то идет, деньги «вбухиваются», как в черную дыру.  А бывает, что пока совещались и решали, что надо делать, оказалось, что делать надо абсолютно другое. Или очень много раз приходится все согласовывать и сдвинуться с мертвой точки невозможно.

3.       Проект завершился, но все работает по-старому.

Самая печальная ситуация, когда, вроде бы, все получилось, ИТ работает, но ничего не изменилось. Почему это происходит? Во-первых, людям свойственно работать так, как они работали. Все новое – неудобно. Не важно, какие именно новшества, они все равно неудобны. И вообще все новое – это страшно! И все новое придумывают начальники, чтобы «заэксплуатировать» сотрудника и выжать из него все соки. Для этого автоматизация и есть…

Тем не менее, владельцы бизнеса декларируют, именно декларируют, что им нужны успешные изменения.  Считается, что у успешных менеджеров руководители покупают успешные изменения.

 

И возникает вопрос, что такое успешное изменение, и что вообще мы считаем успехом проекта?

Каждый человек по-разному оценивает успех проекта. Но главное – как оценивает это тот, кто нас оценивает:  владелец бизнеса, топ-менеджер. Если выяснить, что для них успех проекта, можно под эти требования подстроиться.

Часто говорят, что успех проекта или изменения – это достижение целей бизнеса. Возможно. Но у "бизнеса" нет своих целей. Бизнес - это люди. Цели - в головах людей. Узнать цели бизнеса – это очень непростая вещь. И если вы не являетесь собственником или хотя бы лицом, имеющим право голоса, то о целях бизнеса рассуждать вам будет очень сложно.

А знает ли топ-менеджер цели бизнеса? Что он считает успехом? Ведь бывает, что IT-директор подчиняется именно ему. А иногда – не самому главному топ-менеджеру, а финансовому или исполнительному директору. И тогда непонятно, что именно надо делать, если интересы непосредственного босса и верховного начальника отличаются.

Это вообще очень сложная вещь, понять, что нужно делать. Поэтому иногда получается, что даже когда мы ставим систему, она никому не нужна. Из-за такой ситуации ¾ пользователей не хвастаются проектами, даже если они успешны. Вроде что-то сделали, системы поставили и они работают, но успеха нет.

В целом, конечно, цель изменений – это устранение какой-то проблемы. Но далеко не всегда мы решаем ту проблему, которая декларирована. Например, в моей практике целый проект делался для того, чтобы поддержать вновь пришедшего директора. Нужен был успешный проект только для того, чтобы его приняли остальные топы. В этом смысле желательно зарубать такие проекты, которые, хотя бы в вашем представлении, не соответствуют целям бизнеса.

Подготовка к проекту

 

Мы привыкли счиатать, что проблема - это плохо. Увы, это "плохо" не для всех, иначе ее решили бы до нас. Она бы даже не возникла. Если проблема есть, значит она кому-то дает важное преимущество. Надо только понять, для кого эта проблема – преимущество.

Приведу пример из своей практики. Как-то я работал консультантом в одной стоматологической компании. В ней владелец, хотя тоже был стоматологом, своих подчиненных ни во что не ставил. В компании были очень жесткие законы и штрафы, а собственник бизнеса часто заявлял, что заменить одного из его стоматологов труда не составит, поскольку таких специалистов выпускают ежегодно в большом количестве. В итоге работники не чувствовали, что на них держится бизнес. Они чувствовали себя расходным материалом. Среди обязанностей стоматологов было не только лечить пациентов, но и продавать им сопутствующие средства, материалы, устройства. Врачи не отказывались, но продавать у них не получалось, не покупал никто. Им дали процент, чтобы увеличить продажи, потом еще увеличили возможную прибыль. Но что бы ни делалось, все становилось еще хуже.

Кому и что эта ситуация давало хорошего, нужного и ценного? Врачам. Они таким образом, возможно не осознавая этого, давали понять, что хотят лечить, а не стоять за прилавком и торговать. И восстанавливали самоуважение.

Понятно, что если бы эти врачи почувствовали к себе серьезное уважение, то порекомендовать своим пациентам зубную пасту, ирригатор или другую продукцию им было бы несложно. И 9 из 10 пациентов даже купили бы эти товары, несмотря на то, что в клинике они дороже.

Если бы владелец стоматологической компании это осознал, проблема бы рассосалась сама. Ничего не надо было бы для этого делать. Не понадобилась бы учетная система, чтобы учитывать, кто и что продает, не понадобилось бы контролировать разговоры, ничего не понадобилось.

Этим примером я хотел показать, что если есть проблема и она существует долго, значит, она кому-то нужна. И если организация ее решит, она что-то потеряет. Если удастся понять, что это такое и дать возможность организации получить эту же выгоду, например, уважение, другим способом, тогда проблема уйдет сама. И тогда можно будет хорошо сделать проект. И он имеет шансы на успех.

В традиционном менеджменте есть такое понятие, как модель Глейчера. Она показывает, как должны быть сделаны успешные изменения.

Если мы находимся в точке А (текущее состояние) и нам надо в точку В (желаемое), надо туда как-то пройти.  На этом пути есть точка D. Она показывает первый малюсенький шаг. Исходя из формулы Глейчера, изменение успешно, если:

- уровень неудовлетворенности текущим положением достаточно высок

и/или

- есть четкое представление о желаемом состоянии

и/или

- первые шаги по изменению достаточно безопасны.

Если произведение уровня неудовлетворенности на представление и на безопасность первого шага меньше чем то, как люди воспринимают стоимость изменения, то есть шансы провести изменение успешно. При этом все эти вещи субъективные. Если, например, уровень удовлетворенности слишком маленький (людям и так хорошо), то надо сделать, чтобы людям стало плохо. Тогда они захотят что-то менять. Если они недостаточно хорошо представляют себе, куда надо идти, тогда надо сделать так, чтобы они представили себе возможные перспективы. А первый шажок, он должен быть очень безопасным. 

Каким он может быть, расскажу на примере из собственной практики. В центре КЕЙ мне пришлось внедрять в IT-отделе новую систему управления. Но я не стал объяснять, какие красивые вещи мы получим от нее, как все будет круто. Я сделал маленький шажок: предложил посадить человека, который будет фиксировать все заявки и передавать их айтишнику. Тогда работник сможет работать только по заявкам, времени на саму работу останется больше, и специалистов никто не будет отвлекать. Кроме того, когда будет организована работа по заявкам, появится контроль, сделал айтишник свою работу или нет. И мы четко знаем, кто и сколько работает. А главное, когда работа выполнена, он нажимает на кнопочку, оператор понимает, что все готово и уведомляет об этом пользователя.  Ведь, одна из существовавших проблем – отсутствие оперативной и полноценной информации. Получалось, айтишник все сделал, а пользователь об этом не знает. Или один работник знает,  что проблема уже устранена, а другой – нет. И вот такой маленький первый шажок прошел, ведь это было очень просто – посадить оператора, который будет принимать заявки. А дальше понеслось: пошла стопроцентная фиксация заявок, постепенно начали разрабатывать и внедрять остальные этапы. В общем, понятно: первый шаг должен быть безопасным и очень небольшим.

Для успешного внедрения проекта важно понимать, кто в организации заинтересован в изменениях, а кто заинтересован их провалить.  Как этого добиться, я рассказать сейчас просто не успею, но если вы этого не знаете, то шансов на успешный проект немного.

Например, вы ставите 1С в бухгалтерию, а там «баба Маня», которой полгода до пенсии. Она знает бухгалтерию и вдоль, и поперек, и по диагонали. Но компьютер она не то что не знает, она его боится и ненавидит. Насколько такой работник будет рад изменению? Конечно, она будет против. Но можно ее вызвать и сказать: «На вас вся надежда. Вы наша опора. Потому что налоговая требует эту «железку», а молодым специалистам доверять пока нельзя. Назначаем Вас главной по внедрению новой системы. Надо бы присмотреть за всеми этими работниками». Конечно, «баба Маня» ничем помочь не сможет, но она перестанет мешать. А если ей еще и премию небольшую пообещать за эффективное внедрение, то она будет первым заинтересованным в проекте лицом.

В принципе надо нарисовать поле сил: кто за, кто – против. И хорошо понять, почему кто-то за и почему кто-то против. И дальше можно с этим что-то делать. Кстати, в поле сил должно войти примерно 10 человек, которые на предприятии, действительно, что-то значат.  Это поможет четко понимать, кто будет за изменение и кто будет против него.

Реализуем проект

В менеджменте есть стандартный цикл изменений. Сначала надо разморозить ситуацию, воспользовавшись формулой Глейчера, например, сделать, чтобы всем было плохо, провести какие-то мощные совещания и рассказать, как будет хорошо, когда мы будем «там».

Если не размораживать ситуацию, будет плохо. Помните, власти проводили монетизацию льгот, когда пенсионерам меняли лекарства на деньги, и народ вышел на улицы. Но важно не то, что сделали, а как – указом.  В советское время такие вещи делали намного умнее. Сначала запускали серию газетных статей, в которых рассказывали, что деньги воруют и покупают не то, что надо. Потом пошли бы письма трудящихся, что лучше бы людям деньги дали. Позже выступил бы какой-то эксперт, который заявил бы, что нашим людям нельзя давать деньги, потому что они все пропьют.  После достаточных обсуждений вышел бы гарант, и заступился за народ. Сказал бы, что российский человек – правильный, и он знает, как правильно делать. Затем в порядке исключения или в качестве эксперимента в какой-то области начали монетизацию льгот, а потом аккуратно ввели бы повсеместно. И люди были бы к этому готовы. Это и есть размораживание.

Если удается поменять поле сил так, что за изменение выступает больше людей, чем против, изменение начнет дрейфовать и, соответственно, приходит в точку 2 – туда, где и должно быть. Там надо его заморозить: новыми должностными инструкциями, KPI , чтобы у людей не было возможности вернуться к старому. Тогда будет шанс на успешный проект. Иначе все вернется туда, откуда началось.

Очень часто забывают про размораживание и про замораживание. Но оба этапа очень важны.

Вместо заключения

Все, о чем вы читали до сих пор, – входит в обычный курс менеджмента. Но сейчас я хочу поделиться тем, к чему пришел занимаясь организационной психологией и изучая коучинг. Этого нет в учебниках, поэтому доказать свои размышления ссылкой на учебник я не могу. Но вещи, о которых пойдет речь, можно прочувствовать «шкурой».

Есть такая идея, что когда владелец создает организацию, он создает ее для чего-то. Иногда он сам не осознает, для чего он ее создавал. Например, я пытался понять, для чего владелец фирмы, где я работал 18 лет, создавал ее. Некоторые говорят, что ради денег. Но это не так. Потому что сами по себе они не очень нужны. Что с ними можно сделать? Бумажки! Печку топить! В целом, они нужны, чтобы купить покой, власть, драйв, комфорт. По-разному бывает. Там, где я работал, компания создавалась в 90-х, и надо было поднимать семью и детей, покупать свое жилье, заработать на счастливую пенсию. Это хорошие принципы. Но организация с такими принципами должны быть обязательно очень большой, на всю страну? Нет. Более того, она не имеет права ею быть, потому что это опасно: организация растет, и одновременно повышаются риски. А значит, под угрозу ставятся и принципы, и мечты об обеспеченной старости.

А можно ли в такой организации пытаться проводить какие-то инновации? Нет. Ведь, счастливой старостью рисковать нельзя. Поэтому разговоры о том, как сильно вырастет бизнес после проекта, здесь бессмыслены. Перемен тут боятся.

Но если в такую компанию прийти и сказать, что в результате изменения снизятся определенные риски, то это услышат. Поэтому если вы понимаете, для чего на самом деле создавалась организация, у вас есть шансы провести успешное изменение. Если не понимаете, их нет.

Если организация создавалась для драйва, драйва будет много. Она будет то расти, то падать. Если создавалась для власти, то она будет большой. Владелец будет идти в традиционную власть, а потом возвращаться. Для чего ее создавали, для того она и будет.

Как я себе представляю само появление компании. Есть некий социум, какие-то люди. У них есть желания. Среди этих людей есть предприниматели – им вечно надо что-то «предпринимать».  Они тоже чего-то хотят. Есть у них свои идеи, но дополнительно они ловят идеи социума. В итоге появляется идея бизнеса, своего рода продукт.

Например, если говорить о компании, где я работал, здесь был уловлен важный посыл социума в 90-х гг.: людям хотелось, чтобы в магазинах на полках было много продуктов, а продавцы всем улыбались. Если в целях создания организации больше от "желаний" социума, то бизнес успешен и социум платит за это деньги. Если компания появилась только от желания предпринимателя, бизнес умрет быстро. 

Это ДНК называется лидирующим или ведущим принципом. Если вы хотите быть успешными в проектах и изменениях, надо понять, для чего создавалась организация. Тогда у вас есть шанс. Иначе шансов на успех нет. 

 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2734    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14236    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5821    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

Предыдущие мои статьи на тему управления проектами носили концептуальный характер – ради чего мы делаем проекты, почему мы не получаем поддержку от коллектива пользователей, где найти помощь и мотивацию, как победить сложного заказчика. Теперь от концепций перейдем к технологии. Первая часть будет посвящена вопросам декомпозиции проектных задач на подзадачи для выявления узких мест нашего проекта.

10.02.2023    4657    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2733    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4153    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10596    0    biimmap    79    

73

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13030    0    Evil Beaver    17    

116
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. IvanovAV 131 04.08.17 12:38 Сейчас в теме
Поставил плюс за фотку с домом, по ржал ))) На тех проектах где я занимался автоматизацией, основная моя работа заключалась, уменьшить время на выполнение рутинных операций, путем написания различных обменов или групповых - пакетных обработок, следовательно экономия рабочего времени сотрудников. На одном проекте за 1 год работы удалось сократить отдел менеджеров с 25 человек до 5 человек, а выручку увеличили в 3 раза, просто запустили сайт, и заявки с действующей клиентской базой пошли по сайту, 90% работы клиенты стали делать сами на сайте, а менеджеры только обрабатывали готовые заявки. Как говорил тот директор "Должна работать машина она не болеет, в отпуска и декрет не ходит, зарплату и налоги с ФОТ платить не надо, Леша сделай мне проект и я поделюсь с тобой частью прибыли". Я тогда квартиру купил на этом проекте, пахали по 12 часов, 7 дней в неделю))) Но таких директоров единицы )))
На другом проекте директор на совещании сказал своим руководителям подразделений "Кто будет саботировать внедрение проекта, в понедельник заявление по собственному желанию, мне пофигу на ваш опыт и регалии, не хотите автоматизации значит мне с вами не по пути, работайте в другом месте!"
Был еще один интересный проект, завод делал противопожарные двери, под конкретный дверной проем, а их технолог постоянно бухал и требовал премии, но так как только он знал правильную технологию раскройки и списания материала, он был незаменимым человеком. Мы прописали в программе ТиС 7.7 свой документ в котором алгоритмы, сколько какого материала на какую дверь требуется по формулам и размерам дверного проема, и через 2 недели этого технолога уволили, минус одна штатная единица.
Аналогично избавились от одного логиста, когда прописали систему доставки и загрузки товаров.
Как говорил мой РП, 1 программист = 5 менеджеров.
Deslime; rpgshnik; SiAl; Garik-1980; klinval; PowerBoy; kredko; UniversaLL; igo1; +9 Ответить
2. Bassgood 1424 04.08.17 13:15 Сейчас в теме
(1) Автоматизация бизнеса никого не щадит ;)
newdigger; IvanovAV; +2 Ответить
3. ZUL_MTFKA 14 04.08.17 13:55 Сейчас в теме
Плюсанул за название, прочитал позже.)
Написано верно, но все же лучше документально утвердить постановщика и приемщика задач со стороны Заказчика, который и будет пинать и мотивировать своих сотрудников.
4. webester 26 05.08.17 04:31 Сейчас в теме
Перестал читать на середине. Очень много воды.
rpgshnik; sergelemon; klinval; sasha777666; charushkin; Светлый ум; +6 Ответить
5. WanGoff 138 07.08.17 02:32 Сейчас в теме
Хочу попросить автора - раз уж Вы взяли на себя работу по публикации данной статьи, то сделайте статью, а не компиляцию презы с инфостарта.
А в остальном - спасибо, такие вещи способствуют на новый виток размышлений. Считаю, что статья недооценена судя по 15 "звездам".
Winstoncuk; +1 Ответить
Оставьте свое сообщение