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

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

Мероприятия

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

Управление IT-программами

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

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


Анна Леммниц

Управление программами ИТ-трансформации можно разделить на три большие группы задач: управление масштабом, управление качеством, управление релизами. Пожалуй, самое важное для успеха программы – четко определить ее масштаб. Пример стратегической программы – перевод ERP-системы на платформу SAP HANA. Проект такого масштаба, безусловно, повлияет на другие проекты, которые в компании ведутся или уже запл анированы: придется перераспределять ресурсы.

В момент приобретения компании SYRUS в 2010 году я занималась управлением слияниями и поглощениями. Я знала, что одним из последствий этих перемен будет, например, то, что одного из моих системных архитекторов переведут на программу по внедрению SAP, как более важную для компании. Тем не менее, этот человек был мне нужен, без него я не могла завершить свою программу. Также требовалось объявить представителям бизнеса, участвовавшим в других программах, что эти начинания не будут реализованы, то есть, по сути, что я не выполню обещания, которые ранее давала. Но как об этом сказать?

Получить согласие стейкхолдеров – это ключ к успеху программы проекта. Когда мы начали программу по внедрению Sybase, у нас было много стейкхолдеров: наш исполнительный совет и бывший генеральный директор Sybase. Генеральный директор Sybase сказал, что он хочет подписать каждый план. А представители исполнительного комитета заявили: проект должен быть реализован в июле 2012 года (мы начали его в 2011 году), вот бюджет, все остальное нас не интересует. А бывший генеральный директор Sybase потребовал то, что считал нужным для успеха своей работы, невзирая на бюджет и сроки.

Рекомендация

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

Иногда инициатива изменений идет сверху – практически, это приказ, и невозможно на него ответить отказом. Но можно сказать по-другому: например, что эта задача может потребовать дополнительных бюджетных средств. Если это стратегически важный проект, как перевод ERP на HANA, вы получите эти средства. Главное, сделайте все вовремя.

Рекомендация

Соберите четкие требования, определите и разъясните то, что от вас ожидают.

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

Я не говорю, что нужен обязательно документ на ста страницах с подписью в конце. Есть много способов формализовать договоренности, главное – прийти к соглашению в каком-то зафиксированном виде. Самое главное, иметь письменное соглашение или иное.

Много зависит от того, какое внедрение планируется. Например, интеграция Sybase изначально шла по методологии Agile, и спустя 4 месяца мы поняли, что это неправильно. Но таково было изначальное требование. Мы решили изменить принцип проведения этой программы. Да, мы потратили время и определенные усилия, возможно, напрасно, но в конечном итоге приняли правильное решение: изменить курс.

Как определяется масштаб?

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

Рекомендация

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

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

Как строится отчетность в ходе проекта? У нас приняты ежемесячные совещания, отчеты перед высшим руководством компании. Они не хотят слышать о проблемах, они ожидают, что им расскажут о результатах, причем хороших. Я очень волнуюсь, когда должна выступать перед руководителями компаний и говорить им о возникающих сложностях. Тем более что о многих из них мы не знали заранее. Я начала заниматься переводом ERP на HANA, второй фазой проекта, не по собственному желанию, а по приказу, по указанию. У меня конечно же, есть определенный опыт, который я могу использовать – но этот опыт базируется на других программах, а опыта проведения программы, аналогичной этой, у меня раньше не было.

Сотрудникам IT-подразделений нужно четко понимать и взвешивать – с кем из бизнес-стейкхолдеров какие темы можно обсуждать и какой информацией делиться. То есть нужно четко понимать, кто из них за что отвечает, в чем компетентен. Это не так просто сделать, но выстроить четкое взаимодействие нужно с каждым представителем бизнеса, задействованным в проекте.

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

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

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

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

Рекомендация

Как можно раньше начните собирать информацию об ожиданиях, собирайте ее максимально подробно и фиксируйте найденное.

Отношение к изменениям и мотивация

Как правило, новая программа полностью меняет привычный уклад работы. В этом случае люди начинают испытывать страх неопределенности. Когда вы обсуждаете с ними ожидания, пытайтесь «заглянуть за зеркало»: возможно, вам будут говорить, что готовы вас поддерживать. Но, как мы говорим в Германии, «за зеркалом», то есть за кулисами, может быть противодействие и непонимание. Попытайтесь в этом разобраться, увидеть эти сомнения и показать людям новые возможности изменить и развить себя.

Определение архитектуры решения

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

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

Управление коммуникациями в процессе изменений

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

Дизайн проекта

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

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

Рекомендация

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

Определение требований

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

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

Часто люди говорят: «Да, я знаю, что я делаю». И потом приходишь к ним и говоришь: «Ну-ка объясни свои процессы, объясни, чем ты тут занимаешься» – и они не могут. Я, кстати, тоже не могу. Меня мама часто спрашивает: «Ты в SAP что делаешь?» А я говорю: «Я там управляю программами». Но объяснить в деталях так, чтоб маме было понятно, я не могу. «Ты что людьми должна управлять, большим коллективом?» – «Да-да-да, 500 человек в коллективе». – «Ну а делаешь-то ты что с ними? На встречи, на совещания, что ли, ходишь?». Я тут тоже не могу объяснить доходчиво. Поэтому, когда вам задают вопрос, чем вы занимаетесь, давайте такие ответы, чтобы людям было понятно. Защищайте свою программу, свою работу, если вы встретите на своем пути сопротивление. Если вы не объясните это правильно, вашу работу могут у вас забрать и лишить вас ее. Запоминайте, слушайте все, что заявляют и говорят стейкхолдеры на каждом уровне, даже на самом низком уровне управленцев. Включайте в свою повестку дня и решайте те вопросы, которые не вписываются в масштаб проекта, которые лежат на периферии. Это не значит, что потом у вас не будет с ним проблем. Потому что в дальнейшем, когда вы будете работать в фазе «build», ваши коллеги скажут: «А почему вы это не учли?». А вы в начале забыли об этом сказать, и возникла проблема, на решение которой у вас нет ресурсов, бюджета иди времени. Вот тут и начинают изменения, запросы. Так что бойтесь вещей, которые не вписываются в масштаб.

Рекомендация

Вы должны определить то, чем вы будете в течение года заниматься, а также определить то, чем вы в течение года не будете заниматься. Потому что если вы четко не определите это, вам потом придется очень непросто, когда бизнес командует: «Делай и все».

Документация

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

Управление качеством

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

Change request management отвечает за процессы, gate management оценивает влияние изменений в процессах на клиента, на организацию. Quality gate manager и quality gate management позволяет определить качество на разных уровнях. Есть 5 этапов проверки качества. Не все из них обязательны к использованию, но, например, на начальном этапе программы, после определения масштаба проекта и бюджета, эта проверка нужна.

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

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

Управление релизами

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

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

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

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

Например, мы в этом году решили в начале июня провести интеграцию систем SAP и Sybase. Но наш план пришлось корректировать, так как запускался большой проект по переводу ERP на HANA, и мы должны понять, когда мы будем это реализовывать.

Срочные релизы нельзя спланировать, на то они и срочные. Это как больничный, который нельзя спланировать. Нормальный обычный релиз раз в месяц, проектный релиз – раз в квартал. Все непредвиденное может, естественно, сильно повлиять на календарь релизов.

Календарь должен отслеживать потребности бизнеса. Он всегда требует от нас быстроты, большего количества инноваций. Несущественное изменение должно быть как можно быстрее реализовано, и IT должно быть более гибким. Но не всегда просто реализовать инновационные проекты и вписать их в наши спланированные релизы. Поэтому работает принцип «Не меняй систему, либо вноси изменения перед «Quoter and Сlose» или после того, как это будет закончено». Проект должен идти строго по календарю, и вы не можете ничего спланировать на экстренный случай. Только после завершения тестирования группа должна сказать: «Да, все хорошо, все о’кей». Если требуется что-то срочное, то это не релиз, это экстренные изменения, которые могут быть внедрены в систему, но они должны быть оттестированы по общим правилам. Все нужно тестировать, работоспособность всего нужно подверждать, и только потом переводить систему в производственную эксплуатацию.

Биографическая справка:
Аня Леммниц работает в SAP с 2000 года. Она отвечает за стратегические проекты
SAP Global IT. Аня обладает богатым опытом по управлению программами и проектами по всему миру. В 2011 году она присоединилась к команде SAP Global IT где она возглавляет стратегическую программу «процессная и системная интеграция» по слиянию с компанией Sybase, где интеграция 27 различных компаний была завершена в июне 2013 года. Параллельно Аня занималась интеграцией приобретенной компании Ariba, а также участвовала в проекте по миграции ERP на платформу HANA.