База знаний

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

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

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 месяцев.

Соответственно, сколько релизов можно сделать