Комментарии по теме

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Ко­мпле­ксное решение для эле­ктро­нно­го до­ку­ме­нто­о­бо­ро­та на базе SAP ERP»
Иван Савчук:
Не хватает технической части. В остальном все очень подробно.

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2013-2014) Дата проведения: 10-11 октября 2013 г. Все мероприятия

«Большой взрыв»

Предыдущая Следующая

Для скачивания материала, необходимо войти на сайт или зарегистрироваться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь умение. Умение достигается тренировкой. Определили вы процесс или нет, но на этапе интеграционного тестирования вы создаете специальный сценарий (как минимум один) перехода в продуктивную эксплуатацию. То есть, вы выполняете все шаги по миграции данных, вводу основных данных и вводу остатков, и начали работать. Вот эту всю цепочку нужно делать дважды в интеграционном тестировании, и в ней должны участвовать ключевые пользователи. Наиболее эффективно устроить из этого шоу. Мы сажаем пользователей в одну аудиторию и на экране проходим все шаги по процессу. Да, на это нужно отвлечь часть людей, ключевых пользователей, потратить с ними неделю или две, чтобы провести все цепочки. Но при этом это делают сами ключевые пользователи - они видят, как связаны их действия с соседями, и самое главное, при этом достигается основной эффект. Человек умеет работать – значит, он уже не боится, он уже знает, что он это прошел. Два раза прошли – и ключевые пользователи уже готовы не только сами стартовать, процесс им известен, но и поддержать конечных пользователей.

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

Я могу привести пример по мощности. Наш партнер сделал проект: 8 заводов за 8 месяцев. Я спрашивал руководителя проекта, сколько у него людей работало. Он говорил, что число консультантов, одновременно работавших в этом проекте, достигало 350 человек. За счет чего была реализована такая большая задача? Обеспеченность соответствующей мощностью.

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

Приведу пример проекта на «Днепроспецстали»: программисты заказчика не справились со сложной разработкой. Тогда еще не было регистра материалов, а нужно было фактическую себестоимость считать. Они все обещали, и вроде бы у них что-то получалось, но в конце концов выяснилось, что не работает у них программа. А мы уже стартовали. И мы не можем закрыть месяц из-за того, что программа расчета себестоимости не работает. Мне пришлось стать снова программистом, как когда-то в молодости: я понимал, что они не справятся, и 25 дней потратил на разработку программы, и в конце концов мы ее отладили. В конце концов любые планы Б означают то, что вы подключаете дополнительный ресурс, и у вас должна быть такая возможность.

Теперь - желание, его еще можно назвать мотивацией. Все может быть готово, все у вас будет, но желания не будет делать что-нибудь. Проектная команда должна быть мотивирована на достижение результатов, причем и морально, и материально. Без такой мотивации (например, в госорганизациях редко применяют такие меры по мотивации сотрудников) все идет «ни шатко, ни валко». Мотивация, желание – эти качества очень важны в бизнес-консалтинге, управлении организационными изменениями: чтобы люди захотели работать в новой системе, чтобы не было сопротивления. Цель организационных изменений – чтобы в момент старта в организации был лозунг: «Ура, мы внедряем новую систему, мы будем жить лучше!». Вот такое отношение нужно создавать через агентов влияния, через ключевых пользователей, через руководство и так далее.

Самый лучший пример – это когда генеральный директор спрашивает о ходе проекта. Значит, вся организация знает, что это важно, нужно. Мне повезло: практически всегда у меня управляющий совет возглавлял генеральный директор. Но, правда, этого нужно было добиваться. Однажды я один из проектов держал, не начинал 2 месяца – был конфликт с нашим генеральным директором. Но потом мы ввели все-таки нужных людей в управление проектом, и он был успешным.

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