Станьте участником SAPLAND и получите доступ к самым интересным публикациям SAPPRO
ЗарегистрироватьсяУ вас недостаточно прав для просмотра полной версии этого материала.
В жизни любой системы возникает момент, когда в нее необходимо внести изменения. Специалисты, ответственные за поддержку и развитие системы, должны обеспечить внесение этих изменений с нужной скоростью и, с другой стороны – так, чтобы это не оказывало негативное влияние на качество уже работающих решений и их непрерывность. Как этого добиться и что для этого нужно учесть?
Представим, что у нас уже есть работающая система, но параллельно в компании еще идут различные проекты по автоматизации, и возникает задача объединить эти проекты в рамках некоей программы.
Эта программа должна учитывать и операционные изменения бизнеса – никуда мы от этого не денемся: меняются требования законодательства, структура бизнеса или отдельные бизнес-процессы – например, логистика. Для управления этими изменениями нужно четко понимать несколько моментов:
Картинка ниже иллюстрирует модель, о которой мы будем говорить.
Release management и scope management в рамках программ по внедрению SAP значительно зависят от тех условий, в которых мы работаем. Поэтому в качестве примера рассмотрим большую компанию, глобальную и региональную, в которой есть множество бизнес-процессов, причем они в достаточной степени централизованы и унифицированы.
Кроме того, у нас есть глобальный темплэйт или Global Reference Model, как это иногда называют - некоторые общие правила, процессы, конфигурация SAP и так далее.
Что у нас должно быть обязательно?
Безусловно, это модель, близкая к идеалу. И в рамках этой идеальной компании мы рассмотрим challenges – вызовы, связанные с изменениями, и основные моменты работы с ними. Когда у нас есть Global Reference Model или Global Template – мы должны в нее некоторые проектные требования добавить, чтобы это сложилось в общую картинку. Если компания глобальная, такими требованиями могут быть:
Когда мы будем говорить о релизах и scope management – нам надо тоже понимать, что эта вещь тоже нелинейная. Это хорошо в теории: определился с релизами, понял, что, как и когда будем делать, распределил это на энное количество проектов, утвердил объем и пошел работать. В реальной жизни это все идет по спирали - через множество обсуждений, решений, фаз.
Как мы определяем и планируем релизы? Прежде всего, давайте сформулируем критерии релизов, так как релизы могут быть разные, могут друг с другом пересекаться и комбинироваться.
Затем нужно определить, каким образом мы классифицируем и проектируем поступившие к нам изменения на входе. Нужны критерии: как мы эти изменения выбираем, проектизируем и включаем в рамки объема нашей программы. Опять же - есть разные цели, разные виды управления программами. Мы исходим из того, наше дело – только управление проектами в рамках программы. И еще важно хорошо понимать разницу между операционным изменением и проектом.
Ну и дальше – как мы эти проекты потом группируем в разные релизы и как фиксируем наш объем задач. Нужно учитывать, что все это – нелинейные процессы, они могут пересекаться, но в какой-то момент завершаются.
Есть масса определений, что такое release management. Мне нравится определение «организация набора желаемых или необходимых изменений в одну целостную программу или рабочий пакет, компоненты которого могут быть разработаны вместе». Разработка – это в широком смысле, не только программирование: изменения могут быть перенесены в тестовое окружение, совместно протестированы и перенесены в продуктивную систему как одно большое изменение - собственно, оно и называется релизом.
Понятно, что здесь есть разные способы, подходы и методики. Мы рассмотрим тот опыт, который был реализован в рамках Program Management Office. В чем основные задачи этого органа?
Мне очень нравится аналогия, что release management – это как незавершенное производство, work in progress. По сути, на вход поступает масса запросов – так же, как материалы поступают на вход производственного процесса завода. Потом эти материалы должны быть приватизированы, распределены и пропущены через все цеха, оборудование, чтобы в конце получить некий продукт: мы должны автомобиль BMW получить в конце, а не по отдельности мотор, колеса и багажник. Понятно, что отдельными изменениями очень легко управлять – отдельный проект, отдельный модуль. Но, в конце концов, когда-то все эти изменения сольются таким образом, что либо будут мешать друг другу, либо их нужно будет внедрять вместе, чтобы получилось единое решение.
Когда мы говорим о релизах, есть три основных проблемы, которые надо принимать во внимание.
Следующий важный момент – инсталляции 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, нужно ли нам новое «железо» ставить, в конце концов,
в) от тех ресурсов, которые вообще у нас есть и которые мы можем использовать.
Вот исходя из таких основных моментов, мы должны определяться с нашими релизами. Что это означает? Что у нас не может быть один тип релиза. Мы должны каким-то образом для себя, исходя из наших требований, бизнеса и так далее определиться с типами релизов, в рамках которых мы будем работать. Соответственно, нам нужны какие-то критерии для того, чтобы определить типы релизов. Вот основные критерии, на которые, собственно, стоит обращать внимание.
Надо понимать, что проекты могут меняться по длительности, но в среднем продолжительность проекта тоже очень важна. Я уже сказал, что длинные проекты всегда делил, разбивал на волны, на этапы – почему не стоит делать проект дольше 10 месяцев? Потому что, по крайней мере, в крупных компаниях в декабре всегда есть мораторий на изменения. Нельзя начинать что-то резко менять в продакшн, потому что надо за год отчитываться, а потом выносить отчетность на какую-нибудь биржу. А в январе обычно закрытие года – и тоже не до изменений, лишь бы все стабильно работало. Вот и получается: 12 минус 2 –10 месяцев.
Соответственно, сколько релизов можно сделать
Ролевое назначение : Руководитель / Manager, SAP Консультант / Consultant
Ключевые слова: Управление проектами / Project Management , Материал мероприятия, Академия передовых практик внедрения и поддержки SAP (2012-2013), Файл