Как грамотно организовать проектную работу?

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

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

"Главными факторами при организации любой проектной работы, в том числе работы по внедрению ПО, являются, на мой взгляд, четкое определение стратегических целей проекта, создание плана внедрения и наличие квалифицированного персонала либо возможности его обучения", – говорит Полина Сергеева, ИТ-директор компании "Атомстройкомплекс". Но, в общем и целом, методология остается неизменной как для большинства предприятий, так и для внедрений бизнес-систем различных классов.

Команда для программы

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

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

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

Руководитель проекта

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

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

Например, в компании "Май", занимающейся производством чая и кофе, во главе проекта внедрения ERP-системы Microsoft Dynamics AX встал сам генеральный директор компании Игорь Лисиненко. Именно это обеспечило скорость принятия решений и готовность сотрудников работать на общие цели. "По моему глубокому убеждению, любой масштабный проект затрагивает абсолютно всех сотрудников организации. И проектная команда по внедрению ERP – это тоже весь коллектив компании", – уверен Игорь Лисиненко.

ТЗ и регламенты

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

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

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

Взаимодействие команды

Взаимодействие внутри проектной команды, в том числе между специалистами заказчика и системного интегратора, должно быть четко отлажено. Самое главное, что в этом взаимодействии не должно возникать вакуума, когда одна рука не знает, что делает другая. В Software AG рекомендуют организовывать регулярные, пусть и короткие, совещания рабочей группы по проекту, с уточнением статуса работ и выявлением спорных вопросов. Даже если кажется, что все идет нормально, регулярные встречи позволяют выявить скрытые или намечающиеся проблемы и заранее принять меры для их устранения. Еженедельные встречи продолжительностью не более часа – достаточная частота для проекта средней величины (внедрение, длящееся около года при количестве автоматизированных рабочих мест от 20 до 50 или чуть более), говорят эксперты.

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

Также для поддержания рабочего процесса в ходе внедрения могут потребоваться и экстренные меры. Например, в ходе установки ERP-системы "Компас" в СПб ГУП "Горэлектротранс" проект изначально строился по классической схеме с вертикальным подчинением. "Все руководство проектом велось из центрального офиса. Руководство проектной группы с нашей стороны было поручено мне, начальнику отдела компьютерных технологий", - рассказывает Сергей Смирнов. Однако затем предприятию потребовалась автоматизация процесса выписки путевых листов, учета расхода топлива, заработной платы водителей и так далее в обособленном и удаленном структурном подразделении – автобазе. Всего таких подразделений у предприятия более 20-ти.

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

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

В качестве следующего по важности вопроса выступает область управления рисками и изменениями проекта. Мало компаний, как среди исполнителей, так и заказчиков, которые выполняют идентификацию, оценку рисков, планируют меры по реагированию на риск, превентивные меры, процедуры по управлению рисками и совсем редко устанавливают ответственных за применение запланированных мер, рассказали в "Ай-Теко Бизнес Консалтинг".

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

Молчание – золото

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

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

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

Мотивация участников проекта

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

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

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