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

«Две со­ста­вля­ю­щие Value Management: ко­рпо­ра­ти­вный интеллект и ко­рпо­ра­ти­вная культура»
Олег Точенюк:
Напомнило...   Выходит мужик к железной дороге. В какой стороне Таллин он не знает. Видит старик на дрезине едет. Мужик: - Скажите, пожалуйста, до Таллинна далеко? - Нетт, не талеко. -...

Мероприятия

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

Цикл создания ценности или стоимости в рамках IT-проектов или SAP-проектов

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

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

Цикл создания ценности или стоимости в рамках IT-проектов или SAP-проектов

Докладчик: Андрей Лукьянов, руководитель центра экспертизы стратегических отраслей SAP CIS

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

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

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

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

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

Следующий этап — создание офиса управления проектами и выстраивание процессов управления по ценности, по результату, составление и реализация планов проектов. Само по себе наличие бизнес-кейса не гарантирует достижений — на этапе внедрения могут возникнуть сложности, их недооценивать нельзя. Но пока мы находимся на этапе plan или на этапе прогнозирования бизнес-кейса. Проектный офис отвечает за процедуры и документы, по которым мы работаем. В частности, для защиты проекта у нас есть инвестиционные формы, где мы показываем, какую прибыль можно получить от данного проекта. Также со стороны IT участвует business relationship manager — он рассчитывает, какие затраты компания понесет на внедрение и на поддержку. Бизнес-подразделения прогнозируют результаты, которые проект позволит получить в качестве периодических или разовых выгод. Сопоставляя это, мы можем измерить возможный эффект от проекта тремя способами. Важно, что мы говорим о реальной экономии: даже если в результате проекта задачи какого‑то сотрудника уменьшатся на 30 %, все равно мы должны учитывать его как полноценную рабочую единицу.

Затем мы показываем, какими способами целесообразно проводить измерения и по каким критериям. И, наконец, обосновываем результаты — чего планируется достичь. Также есть так называемый intangible benefits: это не бизнес-выгоды, но очень важные факторы, которые мы также обосновываем перед руководством. По сути, руководство покупает возможности, описанные в этом треугольнике, и это может быть даже не всегда подкреплено проектными выгодами, которые «оцифрованы» — то есть определен конкретный денежный эквивалент предполагаемых результатов. Даже с такими intangible benefits мы показываем, каким образом будем их замерять. Как минимум, мы сможем собрать обратную связь от различных подразделений и посмотреть, действительно ли проект вышел на тот уровень, который мы прогнозировали.

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

Часто есть бизнес-кейсы, где сложно материализовать выгоды. Во-первых, существует бизнес-кейс, где вы не можете снизить количество кадров на 30 %, или можете, но это вызовет сопротивление и проблемы. Они могут хоть кофе пить, но сократить их нельзя. Что мы должны здесь делать? Задать вопрос немножко по другому: компания растущая или не растущая, можем ли мы избежать найма новых сотрудников? Если компания растет, обычно нанимаются новые сотрудники, а можно ли в данном случае этого избежать?

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрев основные моменты планирования проекта, перейдем к следующей стадии — проектированию, созданию решения (build). Вновь приведу пример «Северстали»: проект по внедрению SAP утверждался Советом директоров компании во главе с А. А. Мордашовым. В рамках совета директоров есть IT-комитет, который регулярно собирается. Это внедрение воспринимается не только как IT-проект — компания понимает, что выбор сделан в пользу платформы, охватывающей большинство бизнес-процессов, способной поддержать все процессы, включая финансы, производственное планирование, транспорт, закупки, управление персоналом. Такой подход не имеет ничего общего с кусочной, «лоскутной» автоматизацией.

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

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

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

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

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

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

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

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