Причины успеха и неудач проектов по автоматизации
Сергей Воронин | Генеральный Директор. Интернет-магазин бытовой техники Topmag.ru, Москва.
Михаил Завилейский | Исполнительный директор. Компания DataArt, Санкт-Петербург.
Мария Венедиктова | Директор департамента IT-консалтинга. Аудиторско-консультационная группа «Развитие бизнес-систем» (РБС), Москва.
Алексей Гладченко | Генеральный Директор. Компания «ВоИП Трейд», Москва.
Евгений Гриханов | Генеральный директор. Компания I.Q. Property Management, Москва.
Автоматизация бизнеса — процесс долгий, и отнюдь не всегда он увенчивается успехом. Однако руководители, достигшие цели, могут часами рассказывать о появившихся конкурентных преимуществах и многочисленных плюсах, позволивших сделать бизнес прозрачным и управляемым. Мы пригласили в редакцию Генеральных Директоров и экспертов, которые прошли этот путь. Они постарались выявить возможные предпосылки успеха автоматизации. Отдельное внимание участники дискуссии уделили причинам неудач проектов по автоматизации (см. также статью «Автоматизация бизнеса: опыт руководителей»).
Успех автоматизации зависит от того, кто играет роль инициатора проекта
С. Воронин: По моему опыту, зарождение проекта автоматизации может происходить двумя путями: сверху и снизу. Генеральный Директор, будучи главным стратегом, решает, какие именно бизнес-процессы и как стоит оптимизировать. Но понять самому гораздо легче, чем повести за собой остальных, поэтому автоматизация сверху может либо ни к чему не привести, либо затянуться на долгие годы. Автоматизация снизу дает больший эффект. К примеру, менеджеру страховой компании, обслуживающему от десяти до ста клиентов, вполне достаточно для эффективной работы Microsoft Excel. Но когда количество клиентов увеличивается, то возможностей этой программы и памяти менеджера уже не хватает. Результат: сотрудник сам инициирует начало автоматизации.
Е. Гриханов: Есть еще третий путь — инициатива акционеров. И он, как показывает мой опыт, не всегда ведет к успеху. В этой ситуации Генеральному Директору деваться некуда. Важно, соблюдая субординацию, предупредить собственника обо всех возможных рисках и, если удастся, получить письменное указание внедрить систему. Оно станет своего рода козырем, который поможет впоследствии отражать атаки сверху.
М. Венедиктова: Зачастую Генеральному Директору сложно до начала проекта убедить акционеров в высокой вероятности его неуспешности. Потенциальные риски, даже очень существенные, могут не быть восприняты акционерами всерьез. Я не раз сталкивалась с тем, что следствием неудачного проекта являлось смещение Генерального Директора с поста. Если Вы уверены в неуспехе проекта, лучше уйти сразу, чем сражаться с ветряными мельницами. Если же Вы приняли решение остаться, боритесь до конца. Кстати, успешный IT-проект повышает рейтинг Генерального Директора на рынке.
М. Завилейский: На мой взгляд, если Вы понимаете всю рискованность проекта и осознаете, что виновником провала с высокой долей вероятности будете именно Вы, не занимайтесь самоубийством.
Сформулированная цель — второй шаг к успеху
С. Воронин: Цель проекта может быть простой — повысить эффективность (количественные и финансовые показатели) того или иного бизнес-процесса. К примеру, эффективность работы менеджера среднего звена должна повыситься в десять раз или скорость поступления необходимой Генеральному Директору информации — увеличиться в пять раз.
М. Венедиктова: Цели проекта необходимо зафиксировать в количественном и финансовом выражении. Ни в коем случае нельзя приступать к реализации проекта с мыслью «начнем, а там посмотрим». Анализ даже вполне успешных на первый взгляд внедрений показывает, что они проходили в течение четырех-пяти лет. Это означает, что автоматизация осуществлялась циклично. Начали, чтобы просто начать, затем проанализировали результаты, схватились за головы, переосмыслили отношение к проекту и приступили заново. И так происходит до тех пор, пока не выстраиваются цели проекта и не формулируется концепция их достижения.
Е. Гриханов: Проще всего вести проект в молодых компаниях (таких как наша). Нам изначально было понятно, что обслуживать клиентов, делая записи в амбарной книге, невозможно. Поскольку проект новый, идентифицировать проблемные участки было несложно. Когда мы внедряли систему управления складом, цели были следующие: найти товар на складе, затем не потерять его при комплектации заказа, своевременно отгрузить, правильно посчитать количество операций, произведенных на складе, — словом, организовать прозрачный учет, чтобы партнеру было понятно, за что он заплатил. А чтобы клиент захотел обратиться к нам вновь, мы поставили цель в обязательном порядке блюсти качество обслуживания на складе (соответственно, система должна оперировать необходимыми ключевыми показателями эффективности — KPI).
Затем поставленные цели были трансформированы в функциональную матрицу, при помощи которой выбирался программный продукт.
Если бизнес хаотичен, то автоматизацией заниматься рано
А. Гладченко: Я советую Генеральным Директорам сначала ответить на вопросы: «Правильно ли построен бизнес, которым я руковожу?» и «Формализован ли он?». Любое действие, любая операция должны фиксироваться, чтобы Вы и Ваши подчиненные могли затем управлять полученными данными. Если этого нет, значит, Ваш бизнес хаотичен и никакое внедрение не наведет в нем порядок. Только после формализации «на бумаге» можно приступать к автоматизации.
М. Венедиктова: Генеральный Директор должен не просто видеть свой бизнес формализованным, ему необходимо хорошо понимать, насколько эффективно выстроена система управления этим бизнесом и как в случае необходимости ее реорганизовать. Еще до начала реализации IT-проекта нужно структурировать бизнес-процессы, выделить факторы, критически влияющие на эффективность бизнеса, и провести оптимизацию процессов. Это поможет избежать неприятного сюрприза: деньги вложены, а проект в тупике. Опираясь на свой опыт, замечу: системы управления всех компаний в процессе автоматизации подвергаются изменениям. Это касается обычно и организационно-функциональной структуры, и бизнес-процессов (Этой теме посвящена статья «Как оптимизировать бизнес-процессы»), и методик управления.
А чтобы проект был успешен на всем протяжении, необходимо до его начала оценить все факторы ожидаемой эффективности, все возможные риски и сбалансировать их. Иначе избежать неожиданностей будет очень сложно. Например, удовлетворив потребности финансового аналитика в очень детальной информации о реализованной продукции, можно существенно усложнить жизнь работников склада готовой продукции и даже поставить под угрозу эффективность бизнеса. Поясню на примере: объем аналитической информации, вводимой сотрудниками склада при оформлении отгрузочных документов (накладная, счет-фактура и складской ордер), может существенно увеличить время процедуры, что приведет к потере лояльности клиентов, снижению объемов реализованной продукции и т. д.
М. Завилейский: Я не согласен с тем, что без детального описания бизнес-процессов ничего нельзя сделать. Приведу пример. Мы внедряли у себя систему учета времени — сотрудник должен был фиксировать, что он делал в течение рабочего дня. Сначала мы ввели одну простейшую функцию: отработал — запиши. Не сделав этого, сотрудник не мог получить зарплату. Затем начали реализовываться проекты автоматизации управления ресурсами. Формализация бизнес-процессов шла параллельно с внедрением системы учета времени.
Грамотное распределение ролей — третий шаг к успеху
С. Воронин: Представим — я приглашаю руководить проектом человека извне. Он может требовать с моих подчиненных по максимуму, невзирая на их должности, загруженность или амбиции. И кстати, чтобы командовать, ему необязательно знать IT-продукт. Главное качество руководителя проекта, редко присущее IT-специалистам, — умение контролировать работу. Если такого человека нет в команде, то разработка может затянуться на очень долгий срок.
М. Завилейский: Очень часто Генеральные Директора считают, что ответственный — это тот, кто возьмет на себя вину за неуспех IT-проекта. А поскольку у IT-проектов вероятность провала большая, ответственные за них часто теряют работу. В мировой практике такой потенциально опальной фигурой, как правило, назначают консультанта, который берет большие деньги именно за то, чтобы потом ответить за все и быть изгнанным. Печально, но факт.
А. Гладченко: Человек извне действительно не боится быть уволенным. Помимо этого, он может видеть картину со стороны и отвечать на заявления Ваших подчиненных «у нас так принято», «это не по правилам корпоративной политики» и т. д. простым словом «надо».
Е. Гриханов: Я никогда не назначил бы ответственным за проект автоматизации IT-специалиста. Он бегает к Вам, просит денег на какие-то IT-инструменты, объясняя свои действия грандиозным эффектом от внедрения в будущем. В итоге проект завершается, так и не успев начаться.
По той же причине IT-отдел не должен быть идейным вдохновителем внедрения. Оптимально, если инициатором и заказчиком является одно из бизнес-подразделений компании. А ответственным за автоматизацию лучше всего назначить руководителя этого бизнес-подразделения. Он предпримет максимум усилий для того, чтобы проект завершился, — по своему опыту знаю.
Вообще, я считаю, при реализации проекта нет места жалости как по отношению к себе, так и к подчиненным. Необходимо каждую неделю оценивать результаты работы команды внедрения и, если согласованные показатели не достигнуты, наказывать и штрафовать не выполнивших поручения сотрудников. Ведь именно от их работы зависит, реализуются ли запланированные этапы проекта и удастся ли избежать рисков.
М. Венедиктова: Успех проекта очень сильно зависит от того, насколько хорошо он организован. Причем не только на старте и финише, но и ежедневно, ежеминутно. Если просто выпустить приказ по предприятию о назначении ответственных, распределить роли, а потом об этом забыть, пусть даже на какое-то время, ничего не получится. Через полгода (месяц, неделю), собрав совещание, Вы услышите лишь вал взаимных претензий и жалоб участников проекта. Поэтому мало назначить ответственных, надо создать им условия для работы, втянуть их в процесс, заинтересовать результатами. Это самое сложное. И никто не поручится, что знает, как это сделать.
Эффективная структура управления проектом предполагает наличие двух руководителей — внутреннего функционального заказчика и внешнего консультанта. Внутренний руководитель ставит цели, обеспечивает контроль их достижения, предоставляет внутренние ресурсы для реализации проекта. Внешний руководитель определяет потребность во внутренних и внешних ресурсах, вовремя инициирует их вовлечение в проект, критически оценивает, добивается их адекватности целям и задачам, невзирая на имеющиеся субъективные и объективные препятствия, то есть выступает двигателем, обеспечивающим реализацию проекта.
Что ведет к краху проекта
М. Завилейский: Причина неудач огромного количества проектов — неготовность исполнителя демонстрировать результаты еще не законченной работы и нежелание заказчика смотреть на что-либо, пока оно не работает (ведь надо напрягать воображение и тратить время).
В результате все идет очень хорошо, сдаются формальные отчеты о проделанной работе, автоматически проходятся контрольные точки. А в момент запуска системы случается страшное.
Наладить эффективную работу над проектом не так сложно. Вам необходимо назначать раз в неделю (или раз в две недели) обязательные встречи с командой проекта, на которых исполнитель должен показывать, что уже сделано, и рассказывать о следующих шагах. Проверки дисциплинируют обе стороны. Вы не должны постоянно держать в голове всю информацию о ходе внедрения. Ваша задача — иногда задавать каверзные вопросы. Если, отвечая на них, члены команды начинают спорить друг с другом, значит, в планировании есть проблемы и большие риски данного проекта налицо.
Иногда бывают и непредвиденные ситуации. В одном из проектов все, казалось бы, шло гладко. Руководитель старался на славу, команда делала все по разработанной схеме. Но подвел человеческий фактор. Один из членов команды, назначенный на вспомогательную роль, оказался своего рода серым кардиналом. На предыдущем месте работы он был очень авторитетным начальником и здесь по привычке захватил лидерство в проекте, в итоге «сошедшем с рельсов» по срокам и бюджету.
С. Воронин: На мой взгляд, одна из главных причин неуспеха большинства внедрений в том, что изначально заданные критерии и цели проекта меняются в процессе его реализации. Придерживайтесь заданного курса, пресекайте все попытки Ваших подчиненных совершенствовать находящуюся еще в разработке систему. Если какие-то предложения Вы сочтете разумными, вернитесь к разговору о них, но только после завершения проекта.
Вообще, еще на стадии переговоров можно преду-смотреть многие риски и расписать их по пунктам в карте рисков проекта. Можно продумать и варианты решения проблем. К примеру, сотрудник, разрабатывающий систему, уволился. В этом случае необходимо связаться с компаниейХ, которая имеет всю необходимую информацию о программе. Остальное ложится на плечи IT-отдела.
М. Завилейский: Я согласен с Сергеем [Ворониным]. Лучше еще до начала автоматизации зафиксировать все риски, а также срок реализации проекта. Выделить бюджет с небольшим НЗ. А уже по завершении вносить какие-либо изменения. Вы должны постоянно задавать себе главный вопрос: «С чем мы подойдем к намеченной дате?».
Е. Гриханов: Яркий пример того, о чем говорит Михаил [Завилейский], — внедрение ERP-систем. Если раньше компании заявляли о намерении сделать все быстро и комплексно, то теперь считается успехом внедрение всего-навсего одного модуля ERP-системы. А осуществление 70-80% задуманного — это уже грандиозный успех.
Я считаю, что неуспех больших ERP-проектов во многом объясняется тем, что заказчиками являются фактически все бизнес-подразделения компании. Каждый лоббирует свои интересы. Выход я вижу один: постепенное (помодульное) внедрение. Например, руководить проектом по внедрению финансового модуля Вы доверяете финансовому директору. Затем пальма первенства переходит к следующему бизнес-подразделению. Но ни в коем случае не увлекайтесь деталями. Например, пусть обязанности грузчика по получению документов и доставке товара на склад останутся за кадром автоматизации.
М. Венедиктова: Я в своей практике не раз сталкивалась с последствиями «умерших» проектов -когда компании пытались разработать собственные продукты для автоматизации финансово-хозяйственной деятельности. Проходит год-два, прежде чем наступает осознание полного краха. Причина в том, что IT-разработки для компании- абсолютно непрофильная деятельность. В попытках создать информационную систему сотрудники хаотично стараются что-то сделать (каждый, естественно, в пределах своего видения ситуации). Бухгалтер, мечтающий о формировании отчетности в автоматизированном режиме, неделями ходит к программистам. Те не могут оторваться от насущных дел и к тому же нуждаются в более комплексной постановке задачи, нежели «сделай, чтобы было быстро, удобно и печаталось». Очень много дополнительных обязанностей ложится на конкретных людей, а практика управления проектом отсутствует.
Причины неудач проектов автоматизации
Причины Что делать
1. Проект не разбит на управляемые блоки, не выделены контрольные точки, и в результате сроки реализации проекта затягиваются В зависимости от специфики проекта:
выделите направления, которые необходимо контролировать, назначьте ответственных за каждое из них (например, за технические средства и инфраструктуру, подготовку конечных пользователей, проведение организационных изменений, доработку программного обеспечения, оптимизацию бизнес-процессов и т. д.);
выделите функциональные блоки будущей системы, установите очередность внедрения программных модулей и обязательно зафиксируйте контрольные точки проекта (например, «подготовить наборы данных для тестирования», «сформировать требования для доработки по результатам тестирования» — с конкретными датами)
2. Не определены логические рамки проекта, постоянно возникают новые пожелания, что приводит к затягиванию проекта Утвердите документ (или комплект документов), однозначно определяющий рамки проекта. Это может быть техническое задание, технический проект, проектное решение. Главное — чтобы в документе было четко сформулировано, что такое в Вашем проекте «автоматизация»
Определите цель всего проекта и цели по блокам
3. Ресурсы привлекаются в проект не вовремя, их качество не соответствует решаемым задачам Оцените необходимый объем ресурсов и сроки их вовлечения. Ответьте честно на вопрос, есть ли эти ресурсы сейчас и будут ли в нужный момент
Найдите компромисс между потребностью в ресурсах, их наличием и сроками реализации проекта
4. Персонал компании оказывает сопротивление Информируйте как можно большее количество сотрудников о ходе проекта (на оперативных совещаниях, через корпоративную газету и т. п.), рассказывайте об ожидаемых преимуществах
Демонстрируйте заинтересованность акционеров и руководства в результатах
Выявите зачинщика сопротивления, найдите к нему индивидуальный подход, нейтрализуйте его усилия или увольте
5. Отчетность о ходе проекта носит формальный характер, реальных демонстраций и тестирования функциональных возможностей не происходит. Исполнители проекта затягивают «спокойный период» перед «неизбежным мучительным внедрением» Выделите проектные вехи, связанные с реальными материальными результатами. Продумайте действия по исправлению ситуации в случае срыва сроков. (Например, каждые две недели проектная команда демонстрирует и обсуждает полученные результаты. Если ожидаемый эффект не достигнут, значит, веха не пройдена. Требуются действия по корректировке ситуации.)
6. Отсутствует эффективная система управления проектом (на совещаниях с Вашим участием члены проектной команды спорят между собой, конфликтуют или демонстрируют неуверенность) Привлеките внутреннего или внешнего консультанта с опытом эффективного управления IT-проектами
7. Проект имеет низкий приоритет у исполнителя и выполняется по остаточному принципу. Исполнители не задают Вам вопросов, часто меняются или время от времени исчезают Необходимо вступить в переговоры с исполнителем и проанализировать ситуацию
Если ситуация не изменится, смените исполнителя
8. Не определены цели проекта, не утверждены критерии достижения целей и оценки результатов проекта (при обсуждении и приемке результатов чаще всего звучат оценочные характеристики: «нравится» —«не нравится») Разработайте перечень целей проекта и критериев их достижения
Определите критерии успешности в момент формального завершения этапа внедрения и в ходе эксплуатации — по истечении квартала (месяца, года, трех лет). Например, одним из критериев успешности при завершении блока «Управление отношениями с дебиторами» может быть правильное формирование отчета о состоянии дебиторской задолженности, а по прошествии трех месяцев эксплуатации таким критерием уже должно быть фактическое снижение уровня дебиторской задолженности на 5 (10, 15…)%
По материалам, предоставленным компаниями «Развитие бизнес-систем» (РБС) и DataArt
Как не выйти за рамки бюджета
С. Воронин: Невозможно спрогнозировать, в какую сумму в итоге обойдется автоматизация. Эффективнее всего контролировать изменения в бюджете проекта поэтапно. К примеру, в нашей компании была разработана следующая практика. Досконально просчитываются все затраты на внедрение первого модуля программы. Затем мы делаем финансовое резюме этого мини-проекта и строим прогнозы, касающиеся следующего модуля.
М. Завилейский: Важно учитывать не только прямые расходы, но и скрытые. Обычно подсчитывают затраты на приобретение IT-продукта. Но за кадром остаются расходы на дополнительное использование собственной IT-инфраструктуры, офисных помещений и привлечение сотрудников компании. А это немалая статья расходов. Кстати, на Западе большой успех аутсорсинга объясняется тем, что с внешним подрядчиком гораздо проще контролировать бюджет проекта.
Е. Гриханов: Большой вопрос — что включать в скрытые расходы. Стоит ли учитывать, к примеру, зарплату сотрудников, участвующих в проекте, ведь они и так ее получают? Сверхурочные часы, несомненно, надо фиксировать. Я считаю, что все спорные моменты по контролю над затратами необходимо обговорить и документально зафиксировать решение на стадии формирования проектной команды. Важно, чтобы Генеральный Директор, будучи ответственным перед акционерами за успех и итоговую стоимость проекта, контролировал каждую статью расходов.
А. Гладченко: Согласен с Евгением [Грихановым] полностью. Контроль со стороны Генерального Директора необходим. Но, чтобы не дергать его по каждому вопросу, руководитель проекта должен самостоятельно разработать план, по которому будет контролироваться расходование средств, и затем представить его Генеральному Директору.
Критерии оценки успешности проекта после его завершения
Е. Гриханов: Успешным проект можно назвать в том случае, если итоговые показатели совпадают с запланированными как минимум на 70-80%. Побочные факторы (просроченные даты и потраченные внебюджетные деньги), к сожалению, имеют место очень часто.
С. Воронин: Для меня проект успешен, когда внедренная система удобна всем. Но помимо этого важно учитывать перспективу развития. Любая технология устаревает примерно через три года. Секрет в том, чтобы выбрать именно ту систему, которая соответствует глобальному видению ситуации.
М. Венедиктова: Есть большое количество критериев, по которым можно оценить проект. Но в реальной жизни все гораздо проще. Сказать, что система работает на все сто процентов, можно, только если о ней забывают. Достаточно давно на одном из предприятий мы внедрили крупную ERP-систему. Затем там сменилось руководство и часть штата сотрудников. Когда мы приехали посмотреть, как функционирует система (нас интересовала преемственность технологий), служащие предприятия, ежедневно с ней работающие, даже не смогли вспомнить, как она называется (сыграло роль и то, что пользовательские интерфейсы были максимально адаптированы к специфике работы сотрудников и не содержали товарных знаков разработчика). О системе забыли, так как она позволяет сотрудникам выполнять свои задачи и не доставляет хлопот. Вот это работа!
Еще один из показателей успеха проекта — это отчуждаемость его от внешних консультантов. Речь идет о том, насколько легко каждый работник компании — начиная с Генерального Директора, акционеров и заканчивая кладовщиком — после формального завершения проекта может справляться с системой без помощи извне.
https://www.lobanov-logist.ru/library/all_articles/54935/