Rambler's Top100
Статьи ИКС № 8 2006
Г. ДМИТРИЕВ  01 августа 2006

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

Вместо предисловия

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

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

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

Однако позднее (а это был период «свободного предпринимательского плавания») я вновь испытал полузабытое чувство защищенности и одновременно порабощенности магией начертанных планов и отметок о ходе их выполнения. В то время я являлся членом совета генеральных конструкторов одного из первых отечественных коммерческих космических спутников.

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

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

Начинаем внедрять ИСУП и… проигрываем?

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

К 2001 г. мы достигли рубежа более 100 проектов в год (в основном капитального строительства систем связи и ИТ), для реализации которых 100–150 менеджерам ежегодно приходилось готовить до 10 тыс. документов. Ситуация усугублялась тем, что финансирование многих проектов было связано с бюджетными циклами, которые не совпадали с циклами их реализации. Это вызывало дисбаланс в движении cash-flow, а «сезонность» готовности к работам госзаказчиков порождала и простои, и штурмовщину.

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

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

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

а) красивые обещания поставщика P3e, сопровождаемые демонстрацией все тех же диаграмм Ганта;

б) всеобщий подъем и оптимизм при разработке методик управления проектами, их планирования и контроля, серьезная методическая работа по «отделению зерен от плевел»;

в) неизбежный «бунт на корабле», вызванный повышением требований к производственной дисциплине и формализации процессов;

г) усмирение бунта путем корректного распределения ролей и ответственности;

д) почти год старательной работы «по плану»;

е) еще почти год мучений при ощущении полной ката строфы и бесполезности системы у всех, кто занимался ее внедрением. Обычная картина: еженедельные планерки и отчеты, уже знакомые заверения в том, что «работы идут по графику, но есть объективные трудности» и достоверность представления данных в системе «с вероятностью 50% – может, да, а может, и нет». И самое интересное – не по злому умыслу или халатности, а просто на основании субъективных оценок состояния дел.

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

Как оказалось, это не было следствием сочетания субъективных факторов…

Из монолога руководителя проекта

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

То ли дело без этой вражеской технологии! Не успел что-то – ну и бог с ним. Доделаем завтра, в крайнем случае – послезавтра. У кого-то на послезавтра были другие планы? Отпуск? День рождения? Что ж, придется не делать этого вообще, или подкрасим потом... снаружи, если дотянемся... и если краска не загустеет...».

Вот такая получается технология...

Модная игрушка для видимости прозрачности

В какой-то момент многие российские компании почувствовали непреодолимую тягу к внедрению ERP. Крупные корпорации и предприятия самых разных отраслей и секторов экономики бойко рапортовали о внедрении информационных систем этого класса. Однако в большинстве таких «внедрений» сущность ERP-систем оказалась полностью выхолощенной. В качестве примера приведу разговор с главным бухгалтером одной известной торговой системы, про успех внедрения ERP в которой много писала наша ИТ-пресса:
  • – Кассовые машины и склад?
  • – Наши программисты сами написали программу...
  • – Бухучет?
  • – Конечно, в 1С…
  • – ERP?
  • – Какая ERP? Ах, эта... Ну, мы туда финансовому директору данные выгружаем, и он что-то в ней считает...
В итоге вместо интеграции всех хозяйственных процессов, их прозрачности и оперативности, за деньги акционеров и инвесторов надежно обеспечивалась полная несопоставимость данных бухгалтерского и управленческого учета. А о том, что в аббревиатуре ERP ключевым является слово Planning, лучше, наверное, вообще не упоминать…

Конечно, бывают и исключения из правил. Мне лично известно о нескольких успешных внедрениях и ИСУП, и ERP. Но, во-первых, их единицы, а во-вторых, они являются результатом самоорганизации небольших групп сотрудников, а никак не предприятий или корпораций в целом. И в любом случае на выходе этих систем оказывались достоверными только те результаты, в основу которых были положены объективные данные, занесенные на входе.

Как этого добиться, или Дело в менталитете

Вариант 1. Разместить весь российский бизнес в Германии или в Голландии в надежде на дисциплину их исполнителей.

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

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

В 2003 г., когда неэффективность внедрения ИСУП была нами вполне осознана и стало ясно, что отсутствие надежных инструментов финансового и бухгалтерского учета начинает тормозить процессы управления проектами, мы выбрали вариант 3 и поставили задачу внедрения ERP – Microsoft Navision Attain, отвечающей главному требованию – возможности интеграции общей информационной среды офиса.

Ошибки, на которых мы учились

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

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

Допущенные в начале реализации проекта просчеты не поколебали нашу уверенность в том, что при полноценном внедрении и большинство ИСУП, и все ERP могут и должны полностью охватывать и пронизывать насквозь деятельность любого предприятия, являясь средствами повседневного планирования и управления, которыми пользуются абсолютно все менеджеры и исполнители.

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

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

Новый подход к ИСУП

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

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

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

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

Решение всех вопросов

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

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

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

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

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

Итак, если удалось настроить ERP так, что любой исполнитель или руководитель проекта способен создать документ по каждому связанному с ним событию, то что мешает нам исключить возможность создания такого документа вне связи с запланированной работой проекта?

Дальнейшая реализация – вопрос техники.

Как это в итоге работает

Представим нашу деятельность в виде совокупности проектов. Все денежные поступления происходят в результате некоторых запланированных действий, а расходы, включая ежемесячную выплату зарплаты бухгалтерии и амортизацию основных средств, связаны с необходимостью эти действия обеспечить. Распространив этот подход на всю свою хозяйственную деятельность, вы сможете получать прогноз чистой прибыли своего предприятия в совокупности и любых разрезах, в которые вы сгруппировали эти реальные и «квази»проекты.
  1. Присваиваем каждому запланированному событию уникальный идентификатор, а тем из них, которые подлежат контролю, ставим в соответствие определенный, возможно будущий, документ в ERP, исключив возможность создания в системе ERP документа без присвоения ему идентификатора события из ИСУП.
  2. Вводим такое разграничение доступа, при котором видеть, использовать и вносить изменения в коды работ имеют право только ответственные за них лица. Разграничение доступа к использованию идентификаторов гарантирует, что эти лица смогут создавать документы только в отношении «своих» проектов.
  3. Как только документу присвоен идентификатор, в него тут же попадают из ИСУП сведения о сроках и бюджете, предположенных и утвержденных для этой работы. Ваше дело, какие выводы делать при сопоставлении этих сведений с реальными данными документа – разрешить превышение бюджета, согласиться на отклонения по срокам, поощрить за экономию на этом этапе и т.д. Главное, что все покупки и продажи, списания и актирования немедленно сопоставляются с одобренными когда-то общими планами и отклонениями от них можно управлять еще до того, как они зафиксированы в балансе.
  4. Ну а дальше – в обратную сторону: фактическое состояние документов переносится в ИСУП и отражается на работах. При этом возможно внедрение любых правил по изменению их статуса и условий завершения. Главное, при работе ERP в реальном времени вы и состояние проектов видите в реальном времени.
Заметим, что эта технология применима также и к сложным административным конструкциям, в которых процессы выделения средств и управление проектами оказываются оторванными от реального финансового или хозяйственного учета.

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

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

Внедрение такой системы в inCOMa позволило существенно снизить издержки управления: сократить численность персонала планово-финансовых служб с 15 до 7 человек, уменьшить количество работ, выполняемых с отклонением по дате начала или окончания, до 5% – с 600 до менее 30 в месяц.

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

Вместо заключения

Внимание!

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!
Поделиться: