Аксель Ферст
Управление программами (Введение)
Докладчик: Аксель Ферст
Я работаю с SAP уже 15 лет, и 12 из них — в консалтинге, проекты были в разных странах мира, в том числе и в России — в 1993 году. Сейчас я занимаюсь разработкой программного обеспечения, внедрением, как консультант, и также выступаю в роли менеджера программ. На основе некоторых моих проектов я постараюсь убедить вас, что бюрократия — это не всегда плохо, в плане отчетности она может быть очень полезной.
Наша жизнь — это большой проект и программа, но мы бесспорно на IT-аспектах пытаемся сфокусироваться.
Мы также рассмотрим отличия программ от проектов — безусловно, ее нужно смотреть в каждом конкретном контексте, но есть и общие различия. И они определяют, что нужно и что не нужно делать, каковы ожидания от различных ролей в компании и в целом тоже. Кроме того, мы рассмотрим, как SAP представляет жизненный цикл управления программ — от инициации до закрытия. И обсудим причины неудачных программ и проектов, так же, как и передовой опыт — все это можно использовать как ценный урок и пример.
Программа и проект: общее и отличия
Что такое программа и проект, и в чем разница между ними — определения этому даны организацией PMA, задача которой — формирование эффективных принципов управления проектами и программами проектов. Проект, согласно PMA — это ограниченное определенными временными рамками предприятие, которое создает уникальный продукт, сервис или результат. А программа — это группа проектов, которые взаимосвязаны, управляются координированно, на основании различных систем показателей эффективности. В SAP мы рассматриваем программы в стратегическом контексте, потому что работаем с большими стратегическими программами, которые имеют высшую приоритетность.
Такой подход за последние годы, однако, немного изменился, сместился в практическую сторону, что позволяет понять, что в каждой конкретной компании лучше реализовывать в ближайшей перспективе. IT обеспечивает поддержку такому подходу, то есть, выбирает путь и обсуждает это с бизнесом. Управление программами — стратегия, а проекты — часть стратегических программ. Проекты включаются туда, но не имеют такой стратегической важности, как программы — по крайней мере, в трактовке, которой придерживается SAP.
Проекты нацелены на конкретные стратегические цели программы. Не всякий крупный проект является программой — нужно уметь отличать эти вещи. Два проекта еще не могут стать программой, так как каждый из них может выполняться отдельно и развиваться отдельно, даже если они лежат в одной области. Даже 20 проектов из одной области — это не программа, это просто 20 отдельных проектов. Программа должна иметь KPI, ключевые показатели эффективности, масштаб, широкие перспективы, там должны реализовываться сквозные процессы.
Это более конкретная информация. Менеджер проекта может управлять крупным проектом. Один проект с отдельными подпроектами — по‑прежнему проект. Уровень программы предполагает руководство отдельными проектами, но в новой роли — если вы программный менеджер, вы работаете на другом уровне, с другими людьми. Программный менеджер отвечает перед комитетом, работает с руководителями, например, SAP. С точки зрения ресурсов, он оперирует всем объемом ресурсов, доступных на уровне компании, а не отдельного проекта.
Знания — это тоже важный момент. Не каждый проектный менеджер является хорошим программным менеджером, потому что объем знаний, который на уровне программы требуется, отличается от проектного уровня. Поэтому вы должны развиваться и становиться из проектного менеджера программным менеджером, приобретать знания. Каждый день в вашей жизни перед вами встает много вопросов.
Если вы программный менеджер в процессе внедрения SAP, то эта тема является очень важной. Как программный менеджер вы 50 % уделяете решению политических вопросов. Управление пакетом проектов — это одно дело, но если вы программный менеджер, вы должны решать политические вопросы, уметь отвечать перед руководителями, перед стейкхолдерами, перед комитетами, защищать важные интересы. А как проектный менеджер вы обычно этого не делаете. Хороший проектный менеджер не может или иногда просто не должен быть вовлечен в управление программами и принимать участие в решении политических вопросов.
Как я уже сказал, программный менеджер должен управлять решениями, чтобы получать выгоды — новую ценность для организации. Если выгоды нечетко обозначены, если вы не понимаете, какие выгоды вы получаете, реализуя эту программу, стоит об этом задуматься — как определить данные выгоды и как их достигнуть. Вы должны поддерживать руководителей компании и заручиться их поддержкой — например, финансовой. Если мы соберем все запросы от бизнеса, например, на новый год и для их реализации потребуется 120 млн евро, а выделяют только 80, ваша задача — составить четкий, аргументированный финансовый прогноз, обосновывающий, что целесообразно все же выделять 120 млн. Другой вопрос, что в начале года делается одно, а остается в конце года совсем другое. Всегда эти вещи отличаются. Например, вместо 120 млн все‑таки получаете только 80 миллионов, но и эту сумму в течение года освоить не удается. Меняются требования, теряются ресурсы.
И последнее, стратегические задачи и управление. Я поклонник, откровенно скажу, бюрократии. Объясню, почему это не звучит плохо, что это хорошо, это облегчает вам жизнь. В некоторых проектах такая бюрократия не нужна — у вас работает 10‑15 человек, и в этом объеме нет необходимости каждую неделю своему программному менеджеру отчитываться и предоставлять информацию, которая у него и так есть. Но уровень отчетности для менеджера, который управляет программами, совсем другой, нежели для проектного менеджера. Поэтому в компании SAP часто бывает так, что нам нужно предоставить множество различных данных — и это, безусловно, необходимо выполнить. А это возможно только в том случае, если она у вас консолидирована, и вы ею правильно управляете. Поэтому в рамках программы необходимо устанавливать базовые концепции бюрократии — то есть, четко объяснить, что и в каком формате вы хотите получать, с какой частотой, в каком формате. Вначале это вызывает много дискуссий, но если не поставить эту работу сразу на должный уровень, в течение года возникает масса проблем с тем, чтобы в нужный момент получить конкретную информацию и организовать этот процесс.
Стоит помнить, что информация о программе будет требоваться огромному количеству вовлеченных лиц, стейкхолдеров. И они постоянно будут ее запрашивать, так что эта информация должна быть у вас в наличии. Это сильно облегчает жизнь.
Программа или проект — как различить?
Важно различать проект и программу. Как уже говорилось, даже большой проект, состоящий, для упрощения управления, из подпроектов, еще не является программой. Если проект достаточно протяженный во времени и связан с решением операционных задач, это тоже не программа. И даже группа проектов, которые не связаны друг с другом, но относятся к одной области, все же не являются программой. Цель программы заключается в том, чтобы управлять проектами в целом, вести их в одном направлении.
Как, например, определить количественно бенефиты, выгоды реализации, как определить параметры эффективности. А как создать эффективные KPI, как измерять качество? Есть ведь способы измерять качество, нужно это уметь определять. И, кстати, возникает конфликт интересов, конфликт стейкхолдеров. То есть анализ стейкхолдеров, этих заинтересованных лиц, очень важен — даже не взирая на то, что все стейкхолдеры важны, одни из них важнее, чем другие. И об этом тоже нужно помнить.
Отчетность, которая предоставляется, не всегда хороша для практического использования — так что же с этим делать? Просто согласиться с этим, работать с ней или все‑таки создать собственную, эффективную систему отчетности? Выбирайте оптимальное решение, потому что не все то, что вам дается по умолчанию, хорошо. Например, если шаблон для отчетности недостаточно хорош, создайте другой, который облегчит вашу жизнь, который может также удовлетворить потребности ваших стейкхолдеров. И, кстати, такая дискуссия и в SAP у нас постоянно идет. Как формировать отчетность для руководителей и менеджеров? Как выбрать максимально оптимально простой шаблон, который будет содержать в себе самую актуальную информацию? Необязательно Excel использовать для этих целей, важно создать такой шаблон, который был бы оптимален и удобен.
И наконец — удовлетворенность клиента. Понимаете, никогда не бывает так, чтобы клиент был полностью доволен: меняется подход, может возникнуть конфликт интересов, с этими вещами тоже нужно уметь управляться. Сделать так, чтоб клиент остался доволен — вот наша задача. Я лично считаю, что нужно оставаться максимально транспарентным, прозрачным в своей активности, в том, что вы делаете, например, в сфере IT. С другой стороны, вы должны четко представлять, что делает клиент, чтобы иметь возможность указать на расхождения или ошибки. Все базируется на такой открытости. И в управлении программами должны присутствовать доверие и открытость, что приводит к высокой клиентской удовлетворенности. Если у вас есть общее понимание того, что вы пытаетесь достичь в вашей программе по бизнесу, по IT-части, гораздо будет легче все сделать так, как надо, и изменить то, что потребуется. И потом вы сможете с помощью вашего партнера в бизнесе изменить это направление движения, если вы с ним сработались, если вы понимаете друг друга и движетесь верно в одном направлении.
Всегда на первом шаге нужно уметь разобраться с этой ситуацией и потом уже работать и менять ее, где можно менять. Например, реализация ERP на HANA, я подключился к этому проекту, когда он был эскалирован. Я был программным менеджером, и мы должны были в середине августа активировать проект. Это было обязательным условием. Другие варианты даже не рассматривались, и оставалась одна-две недели до поставленного срока, хотя были проблемы во многих областях проекта. В этой ситуации не было смысла говорить о проблемах, нужно было придумать решение. Идеально никогда не бывает, всегда что‑то идет не так, поэтому нужно просто оптимальный баланс соблюдать, чтобы вы двигались в правильном направлении.
Для успеха нужен не только компетентный программный менеджер, но и хороший модератор, руководитель-модератор — его задача состоит в том, чтобы управляющий комитет получал отчеты, где статус задач оптимален, не допускать перевеса проблемных или просроченных задач. Кроме того, нужна хорошая команда, которая бы вам подчинялась, работала с вами. Чтобы у вас менеджеры проектов тоже хорошо делали свое дело, а вы, как программный менеджер, пользовались бы их поддержкой. Потому что если они не хотят делать свою работу так, как надо, если настрой — работать с 9 до 5 и потом «умывать руки», хотя нужно иной раз и до 7 остаться, если не хотят вас поддерживать в сложные времена, у вас будут проблемы. Вы, как модератор, как руководитель должны руководить ими так, чтобы, в конечном счете, были довольны проектные менеджеры. Они довольны — вы довольны. Если они дополнительную работу делают, экстрамилю, так сказать, проезжают, как мы выражаемся по‑английски — нормально. А если этот подход не работает — плохо будет вам. Даже если вы сверхурочно будете работать, ничего у вас лично с этим не получится, потому что один в поле не воин, особенно когда речь идет о программах, которые мы обсуждаем.
Помните, конечная цель — это достижение результата. Но есть и другие вещи, которые нужно принять во внимание. Весь этот круг, который изображен на слайде. Часто многие компоненты не принимаются во внимание, когда мы говорим об управлении программами. И во всех этих параметрах требуется поддержка, ведь вы же не сможете это сделать самостоятельно. Именно тут подключается правильная бюрократия, PMO так называемое, управление пакетами проектов. Если эти параметры присутствуют, с ними нужно разобраться. И чем сложнее программа, тем сложнее это все организовать на персональном уровне.
В ERP на HANA у нас 120 таких показателей, так что там больше 20 проектов подключено, и, естественно, с каждым проектным менеджером каждую неделю не поговоришь и не спросишь: «Есть ли у тебя риски? Есть ли проблемы, вопросы?». На это уйдет слишком много времени. Поэтому важно выстроить правильные отношения. Такого рода программы реализуются с помощью специальных автоматизированных инструментов, чтобы можно было понять, каковы самые сложные вопросы, каковы риски, как эти риски снизить.
Подписались ли люди, ответственные за те изменения, которые они просят реализовать? Потому что если вы не сможете это сделать, они придут к вам и скажут: «Вы не сделали! На что вы потратили мои деньги? Вы вышли за рамки бюджета, за рамки проекта, временные рамки проекта, качество страдает!» И единственный ремень безопасности, как мы это называем, это такие документы с подписями начальства, которые можно предъявить участникам комитета, чтобы они поняли, что это они несут ответственность за такие изменения. Так что нужны инструменты и структура для всего этого.
Помните, в октябре я подключился в эскалированную программу? Да, нужно было отвечать перед советом. И по моим оценкам это была не программа, а проект, однако очень важный, так как он касался выплаты зарплат руководителям. Если они деньги не получат, будут проблемы. Я подключился к этому решению и сказал: «Где отчеты? Где масштаб? Как вы этим всем управляете? Где команда? Где коллектив? Кто важный? Кто важные участники коллектива?». И на каждый из вопросов я ответа не получил. Я не получил ни документов по масштабу, ни по отчетности, не увидел правильно организованной структуры. Самые важные вещи, основы отсутствовали. Поэтому я сказал: «Для меня крайне важно, чтобы эти вещи были сделаны с самого начала. Если требуется полчаса, 10 минут для того, чтобы это поднять, сделайте это. Потому как если вам кажется, что это напрасная трата времени в начале, в конце это поможет вам просто банально выжить, если вы выходите на другой уровень, и если вы будете использовать правильную структуру. Если ее не будет, что вы предъявите руководителям для проверки, документы, например? Если его ожидает список документов, 100 документов, это база, это основа, и она должна присутствовать, и она должна быть структурированной. Вот это очень важная вещь для меня, с этого я всегда начинаю».
Интеграция графиков и расписаний работы. Кстати, я в PowerPoint часто пользуюсь функцией «План программы». И вы можете сделать так, чтобы у вас были шаблоны и инструменты для того, чтобы рассмотреть графики и расписание программы, получить эту информацию своевременно и иметь расписание доступное. Многие менеджеры в «SAP» не используют Microsoft Project, им достаточно данных инструментов.
Лидерство очень важно. Как лидер вы должны помочь вашим руководителям проектов, как лидер ответить на их вопросы, чтобы они получили поддержку тогда, когда это требуется. Бывают ситуации, когда менеджер программы идет к менеджеру проекта и говорит: «Так, это твоя задача, сделай, выполни ее». Ваша задача, как программного менеджера — помочь вашим проектным менеджерам, если они приходят к вам и говорят: «У нас есть проблема, что с ней делать?» Они просят помощи, и ваша работа, ваша задача — помочь им, обучить их, дать совет, выступить для них наставником, коучем. Один из таких проектных менеджеров работал по 12‑14 часов в день постоянно, и я его спросил: «Зачем?» Он сказал: «Ой, так много работы!» Я сказал: «Окей, а как вы с этой работой вообще справляетесь?» Выяснилось, что он все делал самостоятельно, не делегировал ответственности своим линейным менеджерам — кстати, я активно пользуюсь делегированием, менеджеры проектов должны постоянно этим пользоваться. Если у вас есть так называемые роли и ответственности, которые можно делегировать, используйте это для того, чтобы вопросы решались, и не пытайтесь объять необъятное самостоятельно.
В конечном счете, тот менеджер смог оптимизировать свое рабочее расписание