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

На самом деле можно говорить о «большой взрыве» и в рамках большой программы, например, в большой компании. Вообще трудно представить себе, чтобы в «РЖД», «Газпроме» или каких-то других крупных энергетических, нефтяных компаниях случилось так, чтобы сразу бы разом перешли к новой системе, это невозможно. Так или иначе, вы применяете нашу методологию Global ASAP с формированием шаблона и последующим тиражированием, формированием вертикальных решений и решений на уровне предприятий. Но в рамках вот этой программы все равно можно говорить о «большом взрыве» в рамках каждого конкретного предприятия, например нефтеперерабатывающего завода. То есть вы с точки зрения решения для нефтезавода начинаете и делаете полностью проект, если у вас для этого есть шаблон, допустим, типовое решение. Это в отношении нефтеперерабатывающего завода то же самое – «большой взрыв».

Стратегия внедрения формируется еще до начала проекта. Нужно с самого начала определиться, как вы будете внедрять – сразу все вы хотите получить, или будете двигаться постепенно. И при этом нужно соотносить риски «большого взрыва» и выгоды от его внедрения. Про учет рисков я могу привести пример из своего детства: меня дедушка взял с собой в лес по грибы. Он был высокий, а я – маленький, и шел за ним, пытаясь ему подражать, большими шагами. Он сказал: «Широко шагаешь, штаны порвешь». Риски нужно обязательно принимать во внимание, потому что возможна угроза дестабилизация бизнеса при масштабной трансформации.

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

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

Что касается успеха или неудачи – в моей практике не было неудачных «больших взрывов», но были неудачными постепенные внедрения, потому что руководство устает просто ждать, оно уже забывает про этот проект. Внедрение превращается в чисто IT-шный проект, который длится годами без всякого выхлопа для предприятия. Однажды я приехал к одному заказчику на проверку проекта, а они по 34-му ГОСТу все делают пятый год, запустили в опытную эксплуатацию часть закупок. Ну что можно об этом сказать? К финансовому директору я зашел – он вообще не знает про этот проект.

Что представляет собой «большой взрыв»? Сначала мы готовимся к нему, потом идет запуск в продуктивную эксплуатацию (собственно «взрыв»), и после этого вам нужно будет некоторое время стабилизировать систему.

Здесь перечислены основные шаги, которые присутствуют на этапах подготовки, во время запуска и во время стабилизации. В качестве примеров взяты два проекта: в Украине «Днепроспецсталь» и «Полтаваоблэнерго», Сыктывкарский ЛПК и «Салаватнефтеоргсинтез». Сроки и уровень стабилизиции зависит от объема зет-кода и его качества: чем больше уровень клиенсткого кода, тем дольше будет период стабилизации, больше проблем с производительностью и прочих сложностей.

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

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

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

• ключевые и конечные пользователи обучены,
• владельцы процессов утвердили процесс и орг. изменения,
• роли пользователей определены,
• все пользователи информированы о том, что они будут участвовать и в какой момент вступать в работу,
• новые регламенты разработаны,
• создана группа НСИ,
• подготовлена служба поддержки,
• контрагенты компании тоже подготовлены к тому, что вы будете менять свою систему.

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

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

Ну или, скажем, пример уже в «Салаватнефтеоргсинтезе»: когда прошел период стабилизации, разобрались с отчетностью, оставалась задача перейти к оперативному учету. Что нужно сделать для этого? Мой ответ был, что нужно вводить документы ежедневно – то есть сразу вносить в систему все, что появляется, потому что была укоренившаяся практика в бухгалтерской службе откладывать все на потом, на конец периода. Система ERP требует ежедневной работы, постоянной.

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