Риски проекта автоматизации

Сергей Беспалов

Стратегия компании и проект автоматизации

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

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

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

Следствиями подобного подхода может быть, как минимум, увеличение первоначально установленных сроков и бюджета проекта в среднем в 2-2.5 раза, а как максимум – административное закрытие проекта и списание понесенных компанией затрат на убытки. А, как известно, это не малые суммы.

Взаимодействие с консультантами

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

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

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

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

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

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

Пожалуй, самые трудоемкие этапы проектных работ - это пользовательский интеграционный тест и запуск системы в эксплуатацию. Тут уж действительно требуется значительное по времени участие самих сотрудников компании заказчика, и от этого никуда не уйти. Временные затраты на этом этапе могут составлять от 60 до 100% рабочего времени, в зависимости от объема задач и сроков этапа. Функции руководителя проекта и консультантов на этом этапе сводятся к организации четкого взаимодействия между подразделениями компании, а также технологической и методологической поддержке пользователей. Могу сказать на основании собственного опыта, что этап запуска системы и первичной поддержки пользователей лично мне представляется наиболее сложным. Непосредственный контакт с пользователями, каждый из которых имеет различный уровень знаний, опыта и владения системой - всегда хлопотное дело.

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

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

 «Сроки-бюджет-объем работ»

Говоря о проектных работах, важно оперировать именно этими понятиями. В определенные сроки, при определенном бюджете можно выполнить определенный объем работ с приемлемым для сторон, участвующих в проекте, уровнем качества.

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

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

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

Предположим, необходимо обучить 10 сотрудников компании (например, менеджеров по продажам) силами одного консультанта в течение 5 рабочих дней (40 рабочих часов). Этот срок предусмотрен планом проекта и ему соответствует определенный бюджет. Очевидно, что консультант может потратить на обучение одного сотрудника не более 4 часов. В противном случае, будут нарушены сроки и превышен бюджет, предусмотренные на эту задачу планом проекта. Совершенно ясно, что увеличение срока обучения в два раза, увеличит в два раза бюджет этой задачи, но при этом позволит более качественно отработать с пользователем навыки использования новой функциональности системы.

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

Отношения в команде проекта

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

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

С самого начала необходимо четко определить цели проекта и формальные признаки их достижения, а также приоритет их достижения. Не стоит пытаться объять необъятное. Как известно, это еще никому не удавалось. Целей не должно быть много и они должны быть четко формализованы (идеально, когда цели подходят под определение SMART – «Specialize», «Measurable», «Аchievable», «Resource аnd Time bound»). Не стоит в объем работ включать все, что необходимо, все, что может понадобиться в будущем и все то, что хоть как-то можно соотнести с целями проекта. Такой подход – миф, который вредит проекту. В этом случае не хватит никакого бюджета проекта и никаких ресурсов на его реализацию.

Любой проект, предполагающий автоматизацию нескольких предметных областей (например, логистика, финансы, производство, основные средства, зарплата и кадры и пр.) хорошо бы разделить на четкие этапы, каждый из которых логически замкнут. То есть запущенный функционал системы должен представлять собой логически и технологически замкнутый контур, в рамках которого задействованы соответствующие сотрудники функциональных подразделений. Успешное завершение очередного этапа в запланированные сроки  дает, на мой взгляд, значительный психологический эффект как для проектной команды в целом, так и для каждого сотрудника в отдельности. Согласитесь, всегда приятно наблюдать за результатами своего труда. Полезно остановиться и еще раз критически взглянуть на пройденный путь и сделать необходимые выводы. В моем представлении, проектные работы можно сравнить со спринтерской дистанцией. Рывок, усилие, результат и… успех!  А теперь необходимо восстановить силы и двигаться дальше.

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

Критерии, по которым можно судить о готовности компании к автоматизации

Я бы выделил следующие критерии, по которым можно сделать высоковероятный вывод о готовности компании к началу проекта автоматизации:

●     Четко сформулированные цели проекта, приоритеты их достижения. Как я уже говорил, идеально, когда цели подходят под определение SMART. Крайне важно, когда есть понимание, что поставленные цели достижимы и измеряемы.

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

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

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