Ещё по теме

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

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

Мероприятия

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

Управление ценностью: проектирование

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

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

Наша задача — проанализировать подход, который по-английски называется Benefits realisation, а по-русски — «получение выгод», в частности, от программы внедрения, которая ведется в компании. Это подход, который, с одной стороны, автоматизирует бизнес-процесс, а с другой стороны, помогает проводить изменения в бизнесе.

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

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

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

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

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

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

Второе — это понимание, что любая сложная программа — это не только внедрение IT-инструментов. Если вы автоматизируете хаос, вы получите автоматизированный хаос. Речь в крупных проектах идет об изменении процессов, изменении организационной структуры, изменении требований к навыкам, знаниям и умениям людей, которые их исполняют, людей и KPI процессов, и уже следствием из этого является выбор и внедрение IT-инструментов.

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

Тут есть две крайности. Первая — это когда бизнес имеет более сильное влияние. В этом случае IT выполняет роль «Да, сделаем», не спрашивая, почему. Это не очень хорошая точка. Но и в случае, когда IT слишком сильны и не очень интересуются мнением бизнеса, это тоже ни к чему хорошему не приводит.

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

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

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

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

Первый шаг — задуматься о реинжиниринге процессов. Второй — об организационных изменениях, которые должны произойти в компании. Почему именно об этом? Потому что зачастую процесс может быть прекрасно спроектирован, но плохо выполняться, потому что в организации не проведены соответствующие изменения или нет исполнителей для новой конфигурации процесса. Третий — определить KPI процессов: даже в идеальном процессе ключевым фактором являются люди и структурные подразделения, которые его осуществляют, и если это не измерять, то не будет информации о качестве этого процесса. Четвертое — контроль и ответственность за ту работу, которая должна быть проделана для успешной реализации программы. Что я имею в виду? Когда вы начинаете программу, вы не можете представить себе во всех деталях тот объем дополнительных действий, которые придется выполнить для достижения запланированного результата. Одна из задач value-менеджера и change-менеджера — это, как минимум, регистрация этих дополнительных изменений и определение — кто отвечает за выполнение того или иного изменения?

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

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

Давайте рассмотрим случай отчетности. Во-первых, с точки зрения финансовой отчетности, должен быть финансовый KPI — по нему вы будете оценивать успешность процесса преобразований в целом. Также у вас есть ключевые изменения процессов в рамках отчетности. То есть, должны быть процессные KPI и финальный KPI — на уровне всей программы.

Как реализовать планирование, финансовое или операционное, с точки зрения оборачиваемости того или иного продукта? Важный вопрос. Организация всегда взаимодействует с другими: клиентами, поставщиками, партнерами, и среди них могут быть как добросовестные, так и недостаточно ответственные. К тому же и бизнес-подразделения внутри самой компании не всегда четко формулируют свои цели. Такое хаотичное взаимодействие может приводить к фатальным ошибкам. Но на самом деле, определить, чего хочет бизнес, можно — и ключевые показатели эффективности как раз одна из таких возможностей. Если у вас есть информация о бизнес-подразделении, то, скорее всего, вы знаете и о проектах, которыми они занимаются в данный момент. Как правило, это 3-4 основных проекта. Из этого можно понять, как развивается то или иное бизнес-подразделение.

Необязательность поставщиков — к сожалению, это факт, реальность. Но я знаю проекты, которые как раз направлены на то, чтобы дополнительно развивать поставщиков. Этот вопрос, скорее, из отдельной области: как повысить эффективность управления цепочкой поставок.

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

В принципе, когда мы говорим о программе, мы говорим не только о внедрении бизнес-приложений, но и об управленческом консалтинге. Задача Value Management офиса, если он есть (или Project Management офиса, если Value Management не выделен) состоит в том, чтобы, с одной стороны, решить четкие и понятные технические задачи, с точки зрения классического внедрения SAP, а с другой стороны — задачи на уровне структуры и стратегии компании, чтобы проект был успешен и внедренная система хорошо работала после старта.

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

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

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

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

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

Этот процесс, соответственно, нужно измерять — насколько он эффективен, для чего сформировать финансовые и операционные KPI и понять, откуда будет браться информация для оценки. И то, что называется baseline, основа. В начале проекта желательно сделать срез по тем индикаторам, которые вы собираетесь улучшить, причем очень точно замерить. Потом это вам пригодится для обоснования результатов: «Два года назад продажи в нашей компании были вот такие-то, а сейчас вот такие-то, и это потому, что мы сделали программу». Желательно сразу по тем областям, где вы планируете в бизнес-кейсе реализовать дополнительную выгоду, замерить текущий уровень производительности, затрат или выгод.

Вот данные, которые наша компания собрала в американской юзер-группе — то есть это результаты тех компаний, которые внедряют решения SAP. 28% компаний измеряют выгоду в ходе программ и проектов, 72% — нет. Именно после того, как мы увидели эти результаты, возникла идея включить эту тему, управление ценностью, в курс нашей Академии лучших практик.

Соответственно, из тех, кто не ведет таких текущих замеров, заявленной цели внедрения достигают только 11% компаний. Из тех 28%, которые измеряют — 73% достигают цели. Поэтому мы решили рассказать о каждом этапе управления ценностью и посвятить этому несколько докладов.

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

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

Есть и третий вид KPI — так называемые stability KPI. Когда вы запускаете проект, очень важно для ваших спонсоров, которые обычно от бизнеса, а не от IT, в первые две-три недели рассказывать, насколько успешно проше запуск, какие ошибки выявлены, как быстро на них реагирует и исправляет проектная команда. Почему это может быть интересно? Потому что можно начать сравнивать бизнес в ситуации использования старого решения и разрабатываемого нового.

Приведу реальный пример из моей практики. Это компания, которая занимается производством и продажей масел. Их интересовало сравнение: как сейчас идет, по сравнению с прошлым годом, выставление счетов, насколько оперативно работает соответствующая служба, сколько sales orders в день формируется, как быстро ведутся отгрузки и насколько оперативно выставляются счета клиентам. Сравнивалась результативность работы до и после внедрения решения. Поэтому с точки зрения взаимодействия и установления нормальных коммуникаций с бизнесом очень важно в первые дни работы в новой программе иметь такие KPI, чтобы можно было по ним оценить и сказать: да, количество sales orders выросло, это означает, что мы достигли цели, которую определяли. Или, допустим, это количество уменьшилось — тогда нужно понять, в чем причина: технические проблемы или нормальный сезонный спад? Но для этого нужно иметь данные: если вы просто показываете, что сегодня было 5 ошибок критичных, 20 не критичных и 100 незначительных, генеральному директору или директору по продажам это ни о чем не скажет. Третий вид KPI важен именно на этапе старта проекта, и с бизнесом нужно это обязательно обсудить и получить нужные данные, но после запуска этот KPI можно будет постепенно уже не отслеживать.

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

Промежуточный аудит проекта

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

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

Из ресурсной отрасли этот подход был перенесен в IT. Вам нужно определить для каждого проекта, каждой программы точки, на которых вы будете проверять не только формальные параметры (завершение описания проекта или конфигурирования системы), но и степень достижения планируемых выгод. Это может привести к тому, что вы решите частично или полностью прекратить проект или часть проекта, программы. И в этом нет ничего ужасного. Если что-то не приносит выгоды, зачем это делать?

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

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

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

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

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

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

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

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

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

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

Об авторе

ЭРНСТ КРЕНКЕЛЬ

SAP СНГ

Эрнст Кренкель руководит департаментом Business Transformation Services САП СНГ. У Эрнста за плечами многолетний опыт руководства программами, проектами и экспертиза в области управления решениями SAP для крупных компаний, включая управление их жизненным циклом; управление сложными проектами бизнес-трансформации в нефтегазовой отрасли, отрасли производства товаров народного потребления (FMCG). Эрнст также обладает обширным опытом создания и управления командами внедрения/ эксплуатации решений САП в многокультурном и географически распределенном окружении, накопленным более чем за 17 лет работы в ИТ/управленческом консалтинге в крупных международных и российских компаниях.