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

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

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2012-2013) Все мероприятия

Андрей Трегубов. Управление ИТ программами: когда бюрократия может быть полезной (RUS)

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

Андрей Трегубов

После того, как будет достигнута ясность о том, что такое программы по внедрению SAP, как эффективно управлять объемами, релизами систем и как обеспечить правильную коммуникацию между теми, кто участвует в разных аспектах проекта, возникает вопрос о ресурсах - кто это может делать. И с эти связан очень интересный момент - разумная бюрократия на программах и проектах. Это в первую очередь относится к офису управления программами трансформации (PMO, Program management office).

По сути, PMO – это бюрократическая настройка над нашей программой, своего рода правительство: если оно работает удачно, без него не обойтись. Зачем нужен PMO? Чтобы не наступать на грабли, на которые постоянно, регулярно наступают участники проектов. Чтобы этого не было, нужно наладить процедуры, правила – тогда, если и наступить на грабли, будет не так больно и последствия не будут слишком разрушительными.

Иными словами, Program management office – это некий центр, в котором ведется управление и гармонизация самыми разными процессами и проектами, связанными с внедрением SAP. Очень часто, особенно в крупных компаниях, ведется несколько проектов по внедрению SAP. По системам, которые уже внедрены, ведется операционная поддержка. Параллельно, если все идет нормально, всегда происходит benefit realization – оценка и управление полученными преимуществами, определение дальнейшего развития внедренных систем.

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

В моей практике этот центр обычно управляет 4-мя видами деятельности:

  1. Технические – базис, секьюрити, разработка, архивация – если они требуются в рамках проекта. Так как было бы неправильно эти задачи разложить по отдельным проектам и больше на них не обращать внимание.
  2. Тестирование - в основном, регрессионные тесты, но и интеграционные тоже.
  3. Управление интеграцией (integration management), так как проекты друг от друга зависят, вход одного – это выход другого. Есть масса видов деятельности, которую надо как-то связывать.
  4. Управление изменениями (change management).

Program management office – это и есть те «бюрократы», которые придумывают все эти процессы и процедуры, а потом контролируют их выполнение. Именно PMO, по моему опыту, определял, каким будет ландшафт SAP, осуществлял оценку качества ведения проектов и определял правила, по которым проекты работают.

Рекомендация
От PMO должны поступать рекомендации по различным аспектам внедрения – от организационных до технологических, именно на уровне всей компании и всей системы, а не отдельных компонентов.

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

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

  1. стратегия самой программы, подходы, структура, управление должны быть обсуждены и приняты до того, как мы ее начали. Если у нас спонсора проекта или программы нет – нельзя начинать проект. Если мы не согласовали все правила игры с партнерами – нельзя начинать проект. Или можно, но нужно быть готовым к серьезным сложностям.
  2. высшее руководство компании, где будет проводиться программа, должно понимать, что реализация этой программы нужна бизнесу как воздух. Это тоже достаточно сложный момент, но очень важно его пройти. Должны быть наблюдательные советы из топ-менеджмента, должна быть их вовлеченность. То, что представители SAP входят в ваш наблюдательный совет, не просто желательно, это очень рекомендуется. И на самом деле очень удивительно, что этого не происходит почему-то в России. Насколько мне известно, в большинстве программ внедрений в других странах это просто обязательно требование. И, кстати, это одна из составляющих стоимости проекта.
  3. понять, какая у нас юридическая и географическая структура, где, что и как мы будем внедрять. Невозможно, чтобы в середине проекта нам вдруг сказали: «Вы знаете, а мы теперь решили все переорганизовать и слить все наши юридические лица в одно». Либо это должно быть целью программы, тогда мы договариваемся, что в рамках этой программы, например, мы еще занимаемся созданием share services и делаем такой центр, например, по финансам. Понятно, что тогда, возможно, придется все объединить в одно юридическое лицо или, например, создать единую бухгалтерию. То же самое с организационной структурой.
  4. Определиться с IT-инфраструктурой. У меня был пример, когда система SAP изначально была установлена на S-400 - нормальные, хорошие мэйнфреймы, DB2, все хорошо. И вдруг в середине проекта нам сказали: «А давайте-ка мы на Microsoft все переведем, на NT и на MS SQL, так нам будет дешевле». Пришлось сказать: «Давайте закончим, а потом будем думать о переводе и так далее».

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

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

Важно, что план программы – это на самом деле не один документ, а целый набор документов.

  1. планы каждого проекта,
  2. планы центральных групп, команд, видов деятельности, которые у нас существуют.

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

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

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


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

Рекомендация
Назначайте персональных ответственных за выполнение тех или иных задач на каждом уровне программы. Указывайте их в документах. В случае, если не определен ответственный за данный участок, ответственность за него возлагайте на руководителя уровнем выше.

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

Соответственно, как только мы создали такую программу, надо понимать, что у нас есть отдельные планы конкретных проектов. Здесь обязательно использовать стандартные шаблоны, некую методологию. Мы пользовались АСАПом (ASAP). Можно рассуждать об отличиях методологии ASAP и PMO, но главное – какая-то методология обязательно должна здесь использоваться.

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

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

Обязательно нужно использовать связи между проектами, чтобы понимать, как в целом процесс должен двигаться. Поэтому я использовал определенную вещь под названием depended c in, depended c out. То есть либо наша конкретная задача влияет на задачи других проектов, либо мы от кого-то зависим. И эти связи должны были быть установлены жестко и четко. Потому что, в конце концов, это нужно для того, чтобы избежать такого привычного ответа «это не моя проблема».

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

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

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

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

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

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

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

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

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

Регламент проекта – это объемный документ, в котором все четко расписано: кто, что, когда должен делать на уровне проектов, на уровне программы, что можно, что нельзя. Однако написать мало – нужно еще и отслеживать выполнение. В управлении рисками задействованы различные группы лиц - от Program management office до всех членов команды. И, конечно, не все риски лежат в сфере проекта или программы внедрения. Есть масса внешних рисков. Приведу пример из нашей практики проекта в Малайзии. У них есть такая тенденция - в октябре менять налоговое законодательство, да еще в середине месяца, но задним числом. Например, 15-го числа приходит сообщение, что все акцизы теперь будут считаться по-другому, но с 1 октября. Это тот риск, с которым мы ничего не можем сделать. Но мы должны над ним задуматься и попытаться понять, как мы все-таки можем уменьшить его влияние. Кончилось тем, что мы просто держали там каждый октябрь по 10 программистов в полной боевой готовности, чтобы они могли, если такое изменение опять случится, быстренько все переделать и переписать. Потому что понятно, что SAP точно бы не успел задним числом все это быстро сделать. Вот таким сложным иногда бывает управление рисками.

Управление проблемами и запросами на изменения

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

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

По моему опыту, есть 3 области, где могут локализоваться и распознаваться проблемы.

  1. Собственно program office, сам PMO - в рамках всей программы они могут заметить проблему, зарегистрировать ее и начать над ней думать.
  2. Участники каждого конкретного проекта.
  3. Ключевые пользователи.

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

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

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

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

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

Еще один важный момент в процессе управления изменениями – изменение объемов в рамках программы. Допустим, мы с вами зарегистрировали, утвердили объем проекта и делаем его в этом объеме. Но жизнь есть жизнь, и регулярно у бизнеса возникают вопросы: «А вот можно мы еще и это сделаем? У нас произошли изменения, и теперь нам нужно еще и их отразить». Либо изменения внешние – например, законодательство изменится. Или бывает, что такие сюрпризы возникают при слияниях и поглощениях. Однажды я столкнулся с такой ситуацией на середине этапа апгрейда внедренного решения. Конечно, способ можно найти, но это достаточно сложно, и опять-таки – этот процесс должен быть тоже четко задокументирован.

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

Для этого есть специальное образование – SAP program integration team. Собственно, одна из задач этой команды – управление интеграцией различных систем. Управление изменениями, задачами и рисками, на мой взгляд, должно быть задачей небольшой группы людей с навыками в этих областях. Именно они объединяют различные проекты в единое целое – программу.

У них очень много процессов под контролем. Например, процесс status reporting – это любимый процесс, все это любят, все делают, поэтому можно очень много рассказывать. Должны быть стандартные шаблоны для всех проектов, команд. Раз в неделю каждый проект должен создать свой статус-отчет. Что мы включали в этот отчет? Определенные стандартные milestones, виды деятельности, для всех одинаковые. Даже если в каком-то проекте такиъх задач нет, для консолидации все равно строчка в отчете есть.

В этом статус-отчете всегда пишут риски, основные issues. Легко проверить - если нет номера, фамилии, значит, что-то плохо. Либо нет связи с системой регистрации рисков – в ней риск есть, а в статус-отчете его нет, это тоже плохо. Аналогично проверяется связь с общим планом проекта или программы. В результате получается очень информативный отчет по проекту, который раз в две недели передается в PMO. Там это консолидировалось уже на уровне всей программы, было видно, какие у нас проекты, команды, кто насколько успешен.

Но в результате каждый месяц все равно нужно было делать «одну страничку для большого начальства» - monthly brief, где в виде основных точечек и линеечек, светофорчиков можно было видеть, что происходит с каждым проектом, а также с некоторыми основными видами деятельности. Понятно, что некоторые топ-менеджеры начинали смотреть, что же скрывается за некоторыми красными «светофорчиками»: что происходит в проекте, почему отставание, на каких участках? И доходили, например, до уровня управления данными или Unicode Conversion, и выяснялось, что там что-то завалено. Понятно, что к этому всегда добавлялись какие-то focus topic materials, то есть описания. Но в целом это был некий единый пакет и единый процесс, который и позволял понимать, что происходит, как, на что обратить внимание. Он был четко ориентирован на конкретную аудиторию. Основная мысль очень простая: status reporting в рамках программы – это некая иерархия, поток информации, задокументированный процесс.

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

Рекомендация
Средства управления программой могут быть любыми, но они должны быть подготовлены до начала программы. Нельзя заниматься управлением программой на коленке. И одним из основных средств для руководителя Program Management Office является проектный календарь.

Все основные события, которые регулярно происходят, должны быть задокументированы, вывешены, все должны быть с этим ознакомлены. И от этого нельзя отступать. А за каждым из таких событий – и вот это бюрократия, это скучно, - должна быть такая формочка, в которую вводятся данные: что за событие, для чего оно делается, как часто проводится, какова повестка дня. Повестка дня важна, чтобы совещание не превратить в базар. Я всегда начинал так: первый вопрос повестки дня – а что же мы решили на прошлом совещании, что мы для этого сделали, и что результат этого дела? В данном случае это integration management team, потом давайте обсудим production support overview, потому что тут возникали вопросы, операционные изменения, они влияют на наши проекты.

Далее – вопросы интеграции, взаимосвязи проектов, и другие вопросы по бизнес-задачам программы, если они есть.

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

Документооборот: бюрократия или спасение от хаоса?

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

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

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

И когда мы говорим о финальном проекте, то там два основных раздела. Один - управление проектом, статус-репорты, планы, протоколы совещаний, бюджетные вещи и так далее, устав проекта. Второй - финальные документы, которые устраивались по основным фазам: fit-gap, testing, date-менеджмент и так далее. Внутри этого тоже определенные разделы, где по шаблонам, которые были определены, выкладываются или попадают в финальные документы данные от проектов.

У вас может быть своя структура, но она должна быть определена изначально. Жизнь после запуска системы не заканчивается, даже у программы, у проекта. Да, в какой-то момент проект закончился, но только не в первый день после перехода к производственной эксплуатации. Еще идет post go life support, он продолжается от двух недель до нескольких месяцев. И это тоже некий процесс, процедуры, которые надо документировать, а потом показывать аудиторам, они тоже это очень любят.

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

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

Об авторе

Андрей Трегубов – занимает должность директора подразделения Globalization Services в SAP Lab CIS. Обладает опытом работы в сфере системного анализа и вычислений, занимал высокие руководящие и исследовательские посты в сфере ИТ, имеет уникальный практический опыт. С 1998 года занимается сложными внедрениями ERP-систем и решениями для управления логистическими цепочками. Андрей имеет богатый опыт в области управления программами и проектами в больших международных компаниях.

Опыт работы

Андрей внес большой вклад в развитие информационных технологий на территории бывшего СССР, управлял ERP-проектами в крупных международных компаниях AT&T, Technip, PepsiCo, Procter & Gamble, CdF, Gillette, BBH Brewing Holding, KONE и NOKIA.

Более 14 лет руководил внедрением проектов SAP в глобальном офисе JT International. Обладает богатым опытом внутрикорпоративного управления, планирования поставок и потребностей, а также в проектировании бизнес-процессов.