База знаний

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

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

1. Сроки внесения изменений
2. Кто инициатор изменений и какие требования он выставляет
3. Какие проекты нужны для поддержки этих изменений (не обязательно каждое изменение требует проекта)
4. Как определить и зафиксировать объем работ.

Картинка ниже иллюстрирует модель, о которой мы будем говорить.

Release management и scope management в рамках программ по внедрению SAP значительно зависят от тех условий, в которых мы работаем. Поэтому в качестве примера рассмотрим большую компанию, глобальную и региональную, в которой есть множество бизнес-процессов, причем они в достаточной степени централизованы и унифицированы.

Кроме того, у нас есть глобальный темплэйт или Global Reference Model, как это иногда называют - некоторые общие правила, процессы, конфигурация SAP и так далее.

Что у нас должно быть обязательно?

1. бизнес-спонсор проекта. То есть это не айтишный проект.
2. ключевые пользователи, с опытом работы в системе.
3. централизованный IT, то есть есть центр компетенции, который занимается SAP, а также хорошие айтишники, которые «железом» занимаются, локальной сетью и так далее.
4. консолидированный технический ландшафт - то есть SAP у нас не разбросан в виде зоопарка по разным странам, местам и океанам.
5. централизованные некие функции типа shared services – например, финансы.

Безусловно, это модель, близкая к идеалу. И в рамках этой идеальной компании мы рассмотрим challenges – вызовы, связанные с изменениями, и основные моменты работы с ними. Когда у нас есть Global Reference Model или Global Template – мы должны в нее некоторые проектные требования добавить, чтобы это сложилось в общую картинку. Если компания глобальная, такими требованиями могут быть:

1. локальное законодательство
2. конкретный специфический бизнес-процесс
3. любая специфика.

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

Как мы определяем и планируем релизы? Прежде всего, давайте сформулируем критерии релизов, так как релизы могут быть разные, могут друг с другом пересекаться и комбинироваться.

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

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

Есть масса определений, что такое release management. Мне нравится определение «организация набора желаемых или необходимых изменений в одну целостную программу или рабочий пакет, компоненты которого могут быть разработаны вместе». Разработка – это в широком смысле, не только программирование: изменения могут быть перенесены в тестовое окружение, совместно протестированы и перенесены в продуктивную систему как одно большое изменение - собственно, оно и называется релизом.

Понятно, что здесь есть разные способы, подходы и методики. Мы рассмотрим тот опыт, который был реализован в рамках Program Management Office. В чем основные задачи этого органа?

1. определение ограничений и требований, которые помогают объединить проекты в релиз.
2. «реперные точки» проекта (milestones), фазы, этапы – и те действия, которые будут сопровождать внедрение.
3. ресурсы, которые потом необходимо использовать. Если, допустим, технический ландшафт централизован – технические ресурсы нужно будет делить между проектами, нельзя базис отделить для одного проекта и для другого. Разработка – конечно, можно разработчиков поделить, но лучше централизовать.
4. общие правила для того, чтобы группировать все эти проекты.

Мне очень нравится аналогия, что release management – это как незавершенное производство, work in progress. По сути, на вход поступает масса запросов – так же, как материалы поступают на вход производственного процесса завода. Потом эти материалы должны быть приватизированы, распределены и пропущены через все цеха, оборудование, чтобы в конце получить некий продукт: мы должны автомобиль BMW получить в конце, а не по отдельности мотор, колеса и багажник. Понятно, что отдельными изменениями очень легко управлять – отдельный проект, отдельный модуль. Но, в конце концов, когда-то все эти изменения сольются таким образом, что либо будут мешать друг другу, либо их нужно будет внедрять вместе, чтобы получилось единое решение.

Когда мы говорим о релизах, есть три основных проблемы, которые надо принимать во внимание.

1. то, что называется code collision – когда в код вносятся параллельные изменения. Каждое в отдельности работает прекрасно. А вместе – одно мешает другому. Когда я был на стороне клиентской, я всегда думал – почему изменения в систему SAP вносит так долго? Я сам у себя могу это запрограммировать за пару дней – и все хорошо работает, а SAP нужно 2 месяца! Когда я поближе познакомился с тем, как работает SAP, я понял, что не все так просто. Когда у меня одна инсталляция, одна страна, конкретная конфигурация – легко все это сделать. Но когда мне нужно поддерживать 69 версий страны, насколько я понимаю, в FCM сейчас 69 различных версий – я должен сделать таким образом, чтобы этот код не помешал 68 другим странам. Плюс все те бизнес-сценарии, которые могут быть использованы даже в рамках этой конкретной страны – вот это все… У SAP, кстати, организован некий процесс, чтобы избежать вот этого code collision.
2. неправильная расстановка приоритетов: последствия ее могут быть таковы, что у машины-то каркас сделали, а мотор туда запихать ну никак нельзя. Или колеса не нацепить. А так, в общем, колеса круглые, все хорошо.
3. использование ресурсов. Когда у нас много проектов, их как-то надо все делать, и если всех программистов направить на один проект – встанет другой, а первый не может без второго дальше продвинуться.

Следующий важный момент – инсталляции SAP, которые используют одни и те же компоненты. Приведу опять же пример из своей практики. У нас была отдельная инсталляция ACC, отдельная инсталляция FCM, так как по требованиям законодательства в разных странах они не могли быть установлены в единую базу данных, но BW был единый. Простой вопрос: если я вношу какие-то изменения в FCM, который влияет на BW, или мне нужно апгрейд сделать BW, чтобы в FCM что-то заработало – это повлияет на мою ERP-систему? Планируя что-то, обязательно нужно обдумывать подобные вопросы.

С другой стороны, я должен понимать: а что SAP планирует делать? Когда он выпустит очередную версию, очередной enhancement pack, и так далее, и тому подобное?

Дальше нужно понимать, что некоторые проекты и изменения будут вести к изменениям той функциональности, которую используют уже существующая компания, существующие рынки, существующие юридические лица. Это означает, что я не могу просто-напросто на 10 месяцев запустить проект, все в девелоперской системе порушить и ждать, когда запустится моя новая разработка. Отсюда сразу вытекает требование о построении параллельного ландшафта. Ландшафт-1, темплэйт-1, ландшафт-2, темплэйт-2, темплэйт-3 и так далее, и тому подобное. Опять же, по моему опыту, больше двух параллельных ландшафтов – вряд ли нужно.

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

Мой опыт также показывает, что проекты по внедрению SAP не должны быть больше 9-10-ти месяцев. Если что-то больше – разбивайте на части, делите на волны.

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

Вот исходя из таких основных моментов, мы должны определяться с нашими релизами. Что это означает? Что у нас не может быть один тип релиза. Мы должны каким-то образом для себя, исходя из наших требований, бизнеса и так далее определиться с типами релизов, в рамках которых мы будем работать. Соответственно, нам нужны какие-то критерии для того, чтобы определить типы релизов. Вот основные критерии, на которые, собственно, стоит обращать внимание.

1. Нужен или нет параллельный ландшафт? Если вы 40% системы будете сносить – скорее всего, понадобится.
2. Нужно ли во время какого-то релиза полностью или частично устраивать hard freeze? Если вы делаете в операционном ландшафте что-то и начали менять систему, то понятно, что вы уже не можете после этого какие-то изменения вносить. Следовательно, об этом надо тоже думать. И это очень важный момент.
3. Нужна ли контролируемая поддержка операционных изменений? Вот, по-моему, замечательный пример. Есть у меня один ландшафт, есть параллельный ландшафт. В нем я внедряю абсолютно новую функциональность или новый бизнес-процесс, по-новому работающий. Но в этом ландшафте вдруг произошло изменение законодательства или какое-то новое требование пришло. Я не могу в основном ландшафте что-то менять, забыв о том, что у меня в параллельном ландшафте тоже что-то меняется. Значит, я должен это как-то контролировать. С одной стороны, мы сказали, что операционными изменениями мы не занимаемся, наша программа только занимается проектами. А с другой стороны, я-то должен понимать, что там происходит, они должны понимать, что делаю я.
4. Нужно ли регрессионное тестирование? Поскольку тут ресурсы влияют: обычно в регрессионном тестировании участвуют ключевые пользователи.
5. Нужно ли нам новое «железо»? Как ни странно, вот это как раз айтишный вопрос, но если я перехожу абсолютно на новое «железо» – это очень серьезное требование.

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

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

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

Первый релиз – это когда у нас обязательно параллельный ландшафт, обязательно должно быть регрессионное тестирование, потому что это либо изменение существующей функциональности, которая сейчас уже используется, это либо интеграционные проекты. Что я имею в виду? Вот была наша компания №3 в мире, мы купили №5 – и теперь их надо интегрировать. Один из вариантов – когда мы меняем наш Global Template. Как только мы его начинаем менять – меняются бизнес-процессы, меняется конфигурация, меняется все, включая тренинг Change Management, и прочее, прочее. А любой апгрейд – это, конечно, тоже работа. И даже enhancement pack – иногда это легко ставится, а иногда все-таки нужно регрессионное тестирование делать. Ну и существенное изменение железа, да. Значит, фазы, которые я здесь привел, и примерная их длительность – опять же, это на опыте, это то, как вот по нашему эмпирическому опыту происходило.

Это всегда индивидуально, хотя, в принципе, если у вас Fit-Gap или Blue-Print при 9-месячном проекте больше одного месяца идет –наверное, это многовато. То есть Fit-Gap – это уже когда более-менее команда сформирована и более-менее понятно, что надо делать. До начала проекта вы можете еще два года потратить на то, чтобы только понять: а что же это такое, зачем это нужно? Понятно, что поэтому у нас один релиз в год. Хотя бывают случаи, когда, уж извините, 1 января надо запуститься, потому что с 1 января поменялось все законодательство. И что ж тогда делать? Тогда в ночь с 31-го на 1-ое не спим и работаем.

Второй тип релиза – это когда мы наши изменения пропускаем через операционный ландшафт, то есть когда нам не нужно строить параллельный ландшафт. Обычно это когда совершенно новая функциональность для существующих рынков или юридических лиц. Ну, не было у нас CRM’а – теперь появился. Он, конечно, повлияет на закупки каким-то образом. В принципе, не очень – тут можно контролировать операционные изменения. Просто работать в операционном ландшафте и не тратить деньги на параллельный. Либо у нас появился совершенно какой-то новый рынок, новая компания – и мы внедряем то, что уже внедрено для других компаний. Например, ввели новый завод, новый план, пытаемся для него работать. Хотя тоже там есть интеграционный момент. Либо если у нас какие-то новые компоненты SAP, но они не влияют серьезно на ландшафт. Приведу пример. Вот у нас был проект SWIFTNet. Внедряли SWIFTNet. Это некий компонент, который позволяет с банками общаться через SWIFT, через специальную функциональность. Это у SAP есть специальная функциональность. Она устанавливается там на XI. Ну, на что она повлияет? Она даже на AСС не влияла, поскольку в FCM было уже все настроено. Это означает, что в данном случае, скорее всего, регрессионных тестов не нужно. Однако может понадобиться четкий запрет на некоторые изменения. Надо очень внимательно это проанализировать и продумать. И может быть, что и контролируемый процесс операционных изменений тоже должен быть. Может быть, не на все изменения, но если, допустим, CRM внедряем – значит, нужно смотреть, что с точки зрения закупок, какие операционные изменения происходят. Все равно это большой проект. Даже 6-8 месяцев. Хотя он в ландшафте операционном. Поэтому все равно один релиз в течение года.

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

Ну и последний релиз. Обычно, когда мы берем некие операционные изменения – их много, но они не очень срочные. И тогда, чтобы сэкономить ресурсы, время, как-то это сделать так, чтобы они друг на друга особо не влияли – мы их просто объединяем их и в течение 2-3 месяцев делаем в виде некоего проекта. Хотя, конечно, можно сделать и отдельно – просто это контролируется хуже. Вот здесь от 1 до 3 релизов, опять же из моего опыта, происходит. А отсюда получается следующее: обычно всегда есть один крупный релиз. Но если параллельно ландшафт идет – обычно никогда у меня не было в операционном ландшафте и в параллельном ландшафте, чтобы было два крупных релиза, потому что просто тяжело. Хотя можно. И даже несколько мелких.

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

1. есть ли изменения функциональности для существующих рынков или компаний
2. есть ли новые компоненты SAP
3. нужно ли делать апгрейд
4. проекты какого масштаба входят в объем.
5. цель изменений
6. надо ли менять «железо».

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

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

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

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

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

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

И исходя вот из этих разных критериев, обсуждая с бизнесом, вы понимаете – вот это, скорее всего, и будут мои проекты, которым я должен уделять внимание сейчас, в следующем году или через два года, и так далее. Как мы вообще релизы планируем? Я обычно планировал на три года, потому что на пять - это слишком много, за 5 лет все поменяется, на 1 год – это слишком мало. 3 года – нормальный срок. Понятно, что каждый год составлялся как бы опять план на 3 года, прошлый план уточнялся. Но, когда мы набрали эти проекты, мы определились, какие типы релизов у нас есть. Затем мы должны сгруппировать свои проекты и сказать, что вот с этим мы будем работать.

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

1. проекты, которые мы в операционном ландшафте делаем и они параллельно с проектами, параллельно ландшафту идут.
2. небольшие проекты или проекты, которые не влияют сильно на существующую функциональность.
3. проекты, которые работают в параллельном ландшафте, и некий выраженный случай, потому что все равно между параллельными ландшафтами всегда есть какое-то время. Например, мы сделали один проект, все внедрили, перешли в продакшн, соответственно, у нас один ландшафт получился. Какое-то время прошло, пошел новый релиз, новый параллельный ландшафт нужен… Вот между этими периодами что-то можно попробовать сделать, небольшие проекты запустить в операционном ландшафте.

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

Первая группа – это только релиз, вы помните, первый тип релиза, когда в параллельном ландшафте.

Третий – это только в маленький релиз последний там, который два-три месяца, и так далее, и тому подобное.

Это означает, что как только я мои проекты классифицировал, я могу уже начать наполнять мои релизы и могу смотреть, какая у меня корзинка получается. После того, как я понял, какая у меня корзинка, я возвращаюсь на шаг 1, номер раз, и говорю: «Ребята, вот я не могу за два месяца 255 проектов сделать, даже если они маленькие. Но, исходя из моих критериев, они вот так вот приоретизированы, исходя из моих ресурсов, я могу сделать этот, этот, этот. Вы согласны, что из 25 у меня будет 4?». И каким-то образом вот этот объем мы как-то фиксируем. Для меня всегда было важно одно – что теремок закрывался в определенную дату. Условно говоря, 1 октября у меня мой объем и типы релизов на следующий год были определены. Кто не успел, тот опоздал.

Об авторе

Андрей Трегубов – занимает должность директора подразделения Globalization Services в SAP Lab CIS. Обладает опытом работы в сфере системного анализа и вычислений, занимал высокие руководящие и исследовательские посты в сфере ИТ, имеет уникальный практический опыт. С 1998 года занимается сложными внедрениями ERP-систем и решениями для управления логистическими цепочками. Андрей имеет богатый опыт в области управления программами и проектами в больших международных компаниях. Опыт работы Андрей внес большой вклад в развитие информационных технологий на территории бывшего СССР, управлял ERP-проектами в крупных международных компаниях AT&T, Technip, PepsiCo, Procter & Gamble, CdF, Gillette, BBH Brewing Holding, KONE и NOKIA.

Более 14 лет руководил внедрением проектов SAP в глобальном офисе JT International. Обладает богатым опытом внутрикорпоративного управления, планирования поставок и потребностей, а также в проектировании бизнес-процессов.