Меню

Управление проектом как способ реализации изменений. Часть 3

Принципы достижения успеха. Соблюдение ряда общих правил. Автономия и ответственность. Необходимое разнообразие. Эмоциональный ум. Автоматизированный офис проекта. Работа в команде. Эффективная обработка рисков. Ловушки, которых необходимо избегать. Изоляция проекта. Один размер для всех. Перенос ответственности на вторую волну. Конкурс на место водителя. Незнание возможностей организации. Иллюзия полного контроля.

4.4 Принципы достижения успеха

Если компании требуется провести успешное внедрение среды SAP, необходимо применить некоторые основные принципы. В этом разделе рассматриваются основные принципы, которые необходимо соблюдать.

4.4.1 Соблюдение ряда общих правил

Для большинства успешных программ определены своды нерушимых правил. Все спонсоры должны явно согласиться неукоснительно соблюдать эти правила. Далее приводятся примеры таких правил:

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

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

4.4.2 Автономия и ответственность

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

  • Необходимо организовать комитеты проверки для предотвращения любых неожиданностей. Если группа по программе принимает определенное решение, необходимо соответственно проинформировать владельцев предприятия, которые должны подтвердить свое согласие.
  • Привлечение внутреннего аудита обеспечивает выполнение следующих факторов:
    • Наличие минимального набора внутренних средств контроля.
    • Надлежащее делегирование обязанностей.
    • Соответствие нормативным директивам, например, закону Сарбейнса- Оксли для открытых компаний, BASEL II в Европе и FDA (часть 11) для организаций в сфере биотехнологий и фармацевтики.
    • Независимый ракурс бизнес-случая внедрения SAP.
    • Поддержка в области управления рисками.

Автономность также означает, что сотрудники в проектной группе формально присваиваются и размещаются в проектной группе. Можно назвать два основных преимущества автономных групп:

  • Фундаментальным преимуществом автономной группы является концентрированность на определенном результате. Все действия членов и руководителя группы направлены на достижение успеха.
  • Вторым преимуществом является оптимальная многофункциональная интеграция. Автономные группы могут более свободно привлекать и выбирать участников, чем другие структуры программы.

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

4.4.3 Необходимое разнообразие

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

Эта идея заимствована из теории мышления систем (Ashby, 1956). Например, если проектная группа должна разработать и внедрить среду SAP для химического завода, необходимо привлечь инженеров этого завода по производственным установкам. При этом важно обеспечить, что в группе по программе будет представлена каждая сторона, влияющая на проект, а также каждая сторона, на которую этот проект влияет.

4.4.4 Эмоциональный ум

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

4.4.5 Автоматизированный офис проекта

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

4.4.6 Работа в команде

Вообще говоря, члены группы по программе, по существу, имеют две основных сферы ответственности: собственная функциональная сфера ответственности и ответственность в группе.

Функциональные сферы ответственности

Функциональные сферы ответственности принимаются отдельным членом основной группы как представителем определенной функции (Clark & Wheelwright, 1992):

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

Сферы ответственности группы

Члены основной группы также несут определенную ответственность. Основная группа несет ответственность за успешность программы. В случае неудач в области управления программой, выполнения проектов и задач и обеспечения согласованного в начале уровня производительности члены этой группы могут винить только себя. Группа имеет следующие сферы ответственности (Clark & Wheelwright, 1992):

  • Общая ответственность за результаты группы.
  • Задачи и содержимое восстановления.
  • Создание отчетов и других организационных отношений.
  • Участие в контроле и оптимизации производительности группы.
  • Общая ответственность за обеспечение эффективности процессов в группе.
  • Рассмотрение вопросов с исполнительной точки зрения (ответ на вопрос: “Действительно ли это адекватный бизнес-ответ для компании?”).
  • Описание, распознание и ответственное решение проблем, связанных с программой и процессами в группе.

4.4.7 Эффективная обработка рисков

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

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

Рис. 4.7. Оценка рисков и обработка рисков

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

4.5 Ловушки, которых необходимо избегать

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

4.5.1 Изоляция проекта

Тот факт, что программа имеет собственную цель (и), бюджет, организацию, ресурсы и управление не является причиной, по которой

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти