Нам всем нужна энергия для реализации проектов. К сожалению, иногда бывают такие ситуации, когда проекты умирают именно из-за отсутствия этой самой жизненной энергии. Например, проект пробивается на бюджетном комитете, формируется команда, выделяются ресурсы и помещения, например, целый этаж. И люди сидят там, работают, что-то делают. Но никто не знает, что именно они делают. Другие сотрудники в организации могут называть это подразделение «секретным отделом», потому что никто не знает, чем они занимаются.
Проходит, например, одиннадцать месяцев, двенадцать месяцев, интерес к проекту потихоньку спадает, руководители тоже проявляют все меньше вовлеченности. Через полтора-два года все начинают разбегаться. В таком случае можно сказать иносказательно, что проектам не хватает энергии. Поэтому очень важно, чтобы проект выдавал какие-то позитивные результаты. Желательно, чтобы период между этими позитивными результатами был относительно небольшим, например, три месяца или шесть месяцев.
Почему это важно? Потому что позитив нужен всем: позитив нужен руководству, позитив нужен команде, позитив нужен другим сотрудникам. То есть нам периодически нужно выдавать позитивные новости. Наоборот, затягивание результатов зачастую может служить признаком того, что дела идут не очень хорошо и даже непонятно. Проект становится «мутным». Поэтому лучше, чтобы были какие-то конкретные, видимые результаты.
Здесь уместно рассказать одну историю. В одной из компаний мы внедряли две подсистемы. Нам нужно было внедрить систему для управления товарами: закупками, продажами, логистикой. С другой стороны, нужно было внедрить блок, связанный с казначейством. Внедрение товарного блока мы могли сделать за двенадцать месяцев — такая была специфика компании, и запустить его мы могли только с 1 января следующего года. Запустить же казначейство мы могли гораздо быстрее, за несколько месяцев, примерно за четыре или пять.
И здесь существует две методологии. Одна из них говорит: при внедрении систем вначале надо настроить все одновременно и потом разом проводить изменения в бизнес-процессах. Чаще всего такой методологии придерживался в свое время SAP — это была их логика. Вторая методология, на тот момент от компании Microsoft, гласила, что лучше проводить внедрение по частям. Хотя в этом случае могут возникнуть определенные разрывы между бизнес-процессами. Понятно, что между казначейством и товарным контуром мог возникнуть некий разрыв, который пришлось бы закрывать «на коленках», возможно, с помощью Excel или других средств. Но такой подход может дать лучший эффект.
Сейчас я расскажу, какой эффект он дал в нашем случае. Действительно, через четыре месяца, когда мы настроили модуль казначейства, мы начали его внедрять и обучать людей. Во-первых, это было гораздо легче, потому что мы внедряли лишь часть функциональности системы, и людям было проще ее воспринять. Но другой неожиданный факт возник через двенадцать месяцев, когда мы внедряли уже весь товарный контур. Мы удивились, потому что сотрудники воспринимали это внедрение не как запуск новой системы целиком, что могло бы вызвать большое сопротивление. Нет, они воспринимали это гораздо проще. Как будто к существующей системе просто добавили несколько экранов, которые автоматизируют товарные процессы. Это облегчило принятие изменений людьми, и для нас работа была гораздо легче.
При этом хотелось бы отметить, что успехи должны быть вполне реальными. Это не должны быть фейковые достижения, но их можно заранее запланировать. Если у вас будет возможность в рамках вашего проекта придумать, как через несколько месяцев работы вы получите реальные успехи, вы сможете получить соответствующие позитивные результаты.
