Автоматизация управления рисками

2 сентября 2009

Автоматизация управления рисками и внутреннего контроля: подходы, методология, особенности

В современных условиях роль рисков в деятельности компании становится все более значимой.

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

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

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

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

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

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

Построение автоматизированной системы управления рисками и внутреннего контроля.

Внедрение автоматизированной системы управления рисками и внутреннего контроля в компании позволяет обеспечить:

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

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

На сегодняшний день для целей управления рисками рынок предлагает множество ИТ-решений. К примеру, система MOSASO (Microsoft Office Solution Accelerator for Sarbanes-Oxley) предоставляет широкие возможности по управлению рисками и системой внутреннего контроля. В частности, кроме рисков финансовой отчетности, в рамках закона Sarbanes-Oxley в этой системе могут учитываться риски контрольные процедуры, результаты аудиторских проверок по любым бизнес-процессам (производственным, управленческим и т.д.). Но главное преимущество использования MOSASO заключается в возможности подключения к системе неограниченного количества пользователей, поскольку нет необходимости в закупке пользовательских лицензий, за исключением лицензий на серверное программное обеспечение. В этом отношении по сравнению с другими системами MOSASO значительно выигрывает. В свою очередь, удобный и интуитивно понятный интерфейс этого решения позволяет новым сотрудникам быстро включиться в выстроенную в компании систему управления рисками и начать в ней полноценно работать. Кроме того, MOSASO легко интегрируется с другими используемыми в компании информационными системами.

В частности, у GMCS есть опыт реализации проектов по автоматизации управления рисками и внутреннего контроля в компаниях с холдинговой структурой. Консультанты GMCS участвовали в создании единого автоматизированного комплекса системы внутреннего контроля (ЕАК СВК) в ОАО «Ростелеком». В результате нескольких проектов были построены система формирования регламентов бизнес-процессов на базе Casewise Corporate Modeler Suite, система протоколирования исполнения и мониторинга контрольных процедур на базе MOSASO, проведена интеграция этих систем как между собой, так и с системой управления персоналом. На сегодняшний день пользователями ЕАК являются свыше 6000 сотрудников компании-заказчика, включая ее топ-менеджмент. Внедрение MOSASO в качестве системы управления рисками и внутреннего контроля у другого нашего заказчика позволило сформировать единую базу данных рисков, организовать коммуникации и документооборот по управлению рисками, осуществлять мониторинг регулярной работы и хода выполнения планов по реагированию на риски и формировать отчеты по управлению рисками для менеджмента.

Возможность интеграции автоматизированной системы управления рисками с другими системами

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

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

Формула успеха

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

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

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

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

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

Самый очевидный риск, на мой взгляд, заключается в том, что при несогласованной стратегии компании и стратегии автоматизации, деньги компании на автоматизацию будут потрачены впустую. Подобный риск в равной степени касается любого проекта автоматизации, будь то закупка корпоративного сервера или выполнение проекта по внедрению 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 системы, величина накладных расходов и пр.).

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

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