Решить проблему необоснованных вложений в ИТ российские компании могут, приняв новый подход к выделению средств и распределению ответственности за использование технологий. В большинстве российских и восточноевропейских компаний бизнес-подразделения не несут ответственности за эффективность использования ИТ, поэтому бизнес-менеджеры легко соглашаются на любые суммы, выделяемые на них из общего бюджета, и не стараются определить свои «технологические» потребности, считая, что это дело ИТ-специалистов.
Один восточноевропейский банк за пять лет потратил около 50 млн евро на создание системы управленческой информации. Он приобрел самую производительную платформу (аналогичную используют Wal-Mart и другие крупнейшие ритейлоры) и три года содержал команду консультантов, которые «настраивали функциональность системы управленческой информации». Однако, по признанию финансового директора, у руководства банка до сих пор нет данных, необходимых для управления издержками и принятия стратегических решений (например, о выводе на рынок нового продукта).
Что же было сделано не так? Дело в том, что решения в данном случае принимались по обычному для таких ситуаций алгоритму: задом наперед. Внедряя MIS, призванную обеспечить необходимой информацией руководителей компании, в первую очередь нужно было определить, какая информация нужна им. Если, как чаще всего бывает в таких случаях, технические специалисты самостоятельно принимают решения, то они исходят из технических качеств системы и не ориентируются на требования бизнеса.
Очевидно, что грамотно расставить приоритеты ИТ-проекта и выбрать конкретное решение практически невозможно без продуктивного взаимодействия бизнеса и ИТ-подразделения, которое должно взять на себя роль советчика бизнеса и помочь ему определить свои потребности в этой сфере. Отсутствие такого взаимодействия — одна из самых характерных проблем при реализации крупных ИТ-инициатив. В то же время она имеет вполне тривиальное решение. Оно заключается в том, чтобы создать у бизнес-подразделения, которое инициировало проект или ради которого он был запущен, прямую материальную заинтересованность в достижении его максимальной отдачи. Так, при реализации проектов автоматизации, направленных на сокращение издержек, одна высокотехнологичная американская компания урезает бюджет подразделения, заказавшего ИТ-проект, уже в момент его начала.
Финансирование уменьшается на сумму, равную 50% от предполагаемой. Топ-менеджеры крупной европейской страховой компании ежемесячно получают отчеты об эффективности ИТ-проектов; при этом критерии оценки оговариваются еще до их начала. Благодаря такому подходу подразделения предлагают лишь те проекты, в необходимости которых они полностью уверены, и прикладывают все усилия, чтобы внедрение новой системы как можно быстрее принесло результаты.
Четкое обоснование для реализации проекта — лишь половина дела. Ведь множество начинаний губят ошибки на стадии внедрения. Провести крупный ИТ-проект в запланированные сроки, без перерасхода средств и с ощутимой долгосрочной отдачей (а именно эти три условия мы предлагаем считать критериями успешности) — очень непростая задача, ведь руководители проекта действуют в рамках жестких ограничений.
Так, если говорить о внедрении комплексной системы, то, например, современные ERP-системы состоят из более чем десяти модулей — от финансового до управления персоналом, и для полномасштабного их внедрения нужен не один год. В то же время опыт показывает, что проекты, затягивающиеся больше чем на полтора года, обычно терпят неудачу, поскольку за это время меняется и сама компания, и внешние условия. Это актуально прежде всего для стран с развивающейся экономикой.
Высокая вероятность неудачи ИТ-проекта требует высочайшей дисциплины от всех его участников, и обеспечить ее можно, только правильно организовав проект и задействовав различные инструменты управления, которые обеспечат своевременное участие всех необходимых сторон, решение возникающих проблем, контроль за достижением результатов и т. д. Особенно внимательно к созданию механизмов управления ИТ-проектами стоит отнестись российским компаниям, ведь часто у их сотрудников нет навыка проектной деятельности, многие из них привыкли работать в иерархичных структурах, поэтому боятся принимать решения и неохотно берут на себя инициативу. Наконец, не стоит сбрасывать со счетов и давнюю российскую традицию строительства потемкинских деревень.
Как управиться с основными рисками, сделать так, чтобы проект не начал буксовать, а сотрудники не потеряли веру в его успех? Рамки статьи не позволяют нам дать исчерпывающее описание всех аспектов управления крупным проектом, но мы сформулируем несколько основных правил и обратим внимание на некоторые подводные камни.
Во-первых, нужно как можно раньше определить масштаб проекта и стратегию внедрения. Опыт многочисленных внедрений свидетельствует, что, определив ожидания компании от ИТ-проекта, разумнее сначала внедрять лишь ту функциональность, которая обеспечит быстрый и наглядный результат. Более сложная функциональность успешнее реализовывается на последующих этапах проекта, когда у представителей бизнес-подразделений появляется доверие к программному решению и благодаря опыту практической работы складывается представление о его возможностях.
Выше мы уже говорили о важности установленных бизнесом приоритетов ИТ-проекта. Такие ориентиры нужны не только на стадии выбора технологического решения, но и — быть может, еще в большей степени— непосредственно при реализации проекта. Известно, что внедрение крупных электронных систем, как правило, требует приведения бизнес-процессов компании в соответствие с заложенными в систему алгоритмами, что, естественно, влечет за собой значительное количество доработок и изменений в программном решении.
Вопрос учета в системе требований бизнеса относится к важнейшим, поскольку касается управления масштабом проекта. Изменения неизбежны, но, если не расставить приоритеты, коррективы могут вноситься бесконечно. В одной российской компании на всю работу по изменениям было отведено 2000 человеко-дней, однако, когда все бизнес-подразделения сформулировали свои требования, оказалось, что нужно 8000 человеко-дней! Изучив ситуацию, мы обнаружили, что запустить проект можно было без солидной части предлагаемых изменений; более того, во многих предложенных изменениях не было ровным счетом никакой необходимости.
Радикальный способ избежать хаоса в процессе внесения изменений — в определенный момент ввести запрет на внесение любых изменений, кроме обусловленных регулирующими или нормативными процедурами. В некоторых компаниях процесс внесения изменений распределяется между разными этапами проекта — этот подход хорошо зарекомендовал себя. Получая по завершении того или иного этапа опыт практической работы с новыми технологиями, бизнес-подразделения понимают, что не все изменения, казавшиеся им жизненно важными, на самом деле так уж и нужны.
Во-вторых, у проекта должен быть жесткий план внедрения, реализацию которого нужно постоянно контролировать. Когда становится понятно, что именно компания хочет получить от проекта, можно переходить к составлению подробного списка мероприятий, которые необходимо реализовать, чтобы проект считался успешно завершенным, и уже затем браться за разработку
реалистичного плана внедрения. Реализацию масштабного проекта логично разбить на легко управляемые этапы продолжительностью 6–9 месяцев, при этом оценивать промежуточные результаты нужно не реже, чем раз в три месяца, хотя предпочтительнее отслеживать их еженедельно. Заранее наметив результаты каждого небольшого этапа, руководители проекта и компании облегчат себе задачу контроля за его ходом.
Своевременность реализации ИТ-проекта в значительной степени зависит от того, насколько ответственные за него люди учли все возможные риски реализации, создали ли они инструменты постоянного сбора и анализа информации о ходе проекта и разработали ли механизмы решения возникающих проблем. Наш опыт свидетельствует, что контроль за соблюдением сроков и результатов, несмотря на очевидную важность этой работы, часто превращается в формальную процедуру — отчеты не отражают реального положения дел, обсуждения принимают абстрактный характер.
Кроме того, многие компании считают «бюрократическими выдумками» такие инструменты обеспечения бесперебойной реализации проекта, как системы управления рисками или базы данных по возникающим проблемам. В результате из-за отсутствия достоверной информации остаются неясными причины проблем, неизбежно возникающих в любом комплексном проекте, а без заранее разработанных алгоритмов их решения даже небольшой сбой становится серьезным препятствием для всего проекта. Не стоит недооценивать важность инструментов управления проектами, ведь даже такой, казалось бы, второстепенный инструмент, как база данных по выявленным проблемам, может в определенный момент сыграть спасительную роль.
В одной восточноевропейской финансовой компании крупный ИТ-проект явно пошел не по плану (рассчитанный на два года, он растянулся на три, а бюджет был превышен на 40%), все его основные участники пребывали в полной растерянности, любая активность казалась бессмысленной. К примеру, миграция данных была названа проблемой, потому что «ничего не работает». Нам потребовалось больше недели, чтобы понять, что на самом деле означало это «ничего не работает». Все свелось к двум проблемам — одной довольно мелкой технической и еще одной организационной.
Была создана база данных, в которую заносили все возникающие проблемы в структурированном виде, что позволяло работать над ними. За две недели база данных пополнилась информацией о 25 неполадках, и их устранили примерно за шесть недель. Благодаря этому простому шагу, более высокой дисциплине обсуждения проблем и «работе над ошибками» удалось возродить проект.
Наконец, в-третьих, чтобы финальный продукт соответствовал интересам бизнеса, а проект не вышел за пределы намеченных сроков,необходимо обеспечить постоянное участие бизнеса в реализации проекта. Выше мы уже упомянули о том, как важно, чтобы бизнес-менеджеры ответственно относились к обоснованию целесообразности проекта. Однако для успешной реализации проекта сотрудники бизнес-подразделений должны участвовать в нем на постоянной основе и следить за тем, чтобы принимаемые решения соответствовали их потребностям.
Нередко бизнес-подразделения формулируют свои требования, а затем на долгие месяцы «забывают» о проекте и начинают проявлять активность уже в момент испытаний системы, которые, при таком отношении со стороны бизнеса, как правило, оказываются неудачными. Хотя после утверждения технических спецификаций общее направление проекта обычно не меняется, примерно 80% решений, напрямую сказывающихся на удобстве и полезности системы для пользователя, принимаются уже после разработки спецификаций и до приемочного тестирования. Таким образом, если будущие пользователи системы не участвуют постоянно в процессе принятия решений, то впоследствии они обнаруживают, что результат не соответствует их ожиданиям, возникает масса ошибок в процессах, которые проявляются потом при взаимодействии с клиентами, и компании приходится вносить все новые коррективы.
Научившись реализовывать технологические проекты в срок, не превышая бюджет и с долгосрочным эффектом для бизнеса, компании смогут переосмыслить роль информационных технологий и обрести уникальный опыт управления комплексными проектами, важный не только в технологической сфере.
Комментариев нет:
Отправить комментарий