Intelligent Enterprise: В своем докладе Сергей Малахов, руководитель центра ИС "Силовых машин", подчеркнул, что нужно как можно раньше оценить рамки проекта. Эта же идея звучала и в других выступлениях. В какой момент, на ваш взгляд, должно происходить определение рамок проекта?
Андрей Крылович: В начале проекта предприятие должно определить
цели проекта. Если цели проекта сформулированы нормально, то должна произойти
их декомпозиция на задачи. И задачи в общем уже описывают функциональные области
проекта и ключевые процессы, это уже рамки проекта. Традиционно рамки проекта
выглядят следующим образом. Первое - география, то есть на каких бизнес-единицах
планируется внедрение системы: одно предприятие, филиалы и т. д. Второе - функциональные
области. Третье - основные бизнес-процессы, которые требуется покрыть системой.
Четвертое - это интерфейсы с существующими системами. Пятое - дополнительные
расширения и шестое - отчеты. Это основные рамки проекта.
Естественно, что сразу получить от предприятия ответ на все эти вопросы можно очень редко. Поэтому, как правило, в самом начале, обсуждая основы проекта, опираются на некоторую практику внедрения ERP-систем, а согласование рамок проекта выносят либо на предпроект, либо на первый этап проекта. При этом может случиться так: зафиксировали стоимость проекта, потом провели обследование, и выяснилось, что рамки проекта и стоимость не согласуются. Создаются предпосылки для инициации процедуры управления изменениями. Либо предприятие понимает, что нужны большие ресурсы, большие финансы или сроки, либо начинается совместный поиск компромисса. Например, в проекте по внедрению Oracle e-Business Suite в компании "Альфастрахование" сложилась именно такая ситуация. Требования заказчика на этапе экономического обоснования проекта должны были, на первый взгляд, достаточно легко реализоваться. Впоследствии, когда был проведен детальный анализ операций, возникло множество уточнений, касающихся расчета специальных коэффициентов, применяемых в страховом бизнесе. Первоначально расчет этих коэффициентов планировался в рамках финансовой системы, но выяснилось, что необходимо создавать отдельное аналитическое хранилище данных. Все эти уточнения привели к тому, что образовался отдельный подпроект по созданию подсистемы управленческих расчетов. Было проведено расширение первоначального проекта, добавлены консультанты, создана отдельная группа.
К рамкам проекта имеет отношение еще одна важная деталь. В "Альфастраховании" возникло расширение в рамках одного проекта. Нельзя было cоздавать подсистему управления расчетов в рамках отдельного проекта, потому что это должно происходить параллельно с задачами создания страховой и финансовой системы. Однако нередко в проекте внедрения возникают опасные тенденции и стремления "объять необъятное". Проекты внедрения комплексных систем в ряде случаев затрагивают вопросы изменения процессов деятельности, учетной политики, разработки системы управленческого учета и т.д. Необходимо своевременно принимать решение об ограничении инициатив по расширению и открытию других проектов. В противном случае все согласованные сроки и ожидаемые результаты будут недостижимы.
В докладе Сергея Малахова прозвучала еще одна интересная мысль: когда обсуждается вопрос старта проекта, не нужно проводить консультации с поставщиками услуг, объявлять тендер, а просто надо сделать маленький прототип…
Да, в ряде случаев мы сталкивались с подобной практикой. Прежде чем принять решение по старту большого ERP-проекта или его части, предприятия хотят получить более подробную информацию о функциональных возможностях системы и некоторых специальных проектных решениях, которые могут быть предложены стандартной функциональностью. В результате может быть инициирован относительно краткосрочный проект по подготовке базового прототипа системы на уровне концепции, чтобы можно было понять основную схему решения, оценить рамки, затраты и так далее. При этом, компания снабжает консультантов достаточным минимумом необходимой информации, сформулировать в общих чертах требования. На основании анализа прототипа, менеджеры заказчика могут принять решение, тем самым существенно снижая риски. Компания жертвует небольшими деньгами, консультанты показывают приблизительный эскиз решения, менеджеры задают вопросы и оценивают риски. И таким образом приближаются к принятию серьезных решений.
Такого рода пилотный проект мы делали на КнААПО, о чем рассказывал на конференции Владимир Игнатенко, начальник отдела внедрения и эксплуатации систем КнААПО. И предприятие на основании этого пилотного проекта уже смогло сделать вывод, насколько ERP-система подходит к его оргструктуре, задачам и так далее. По сути, такой пилотный проект - это более детальная демонстрация стандартных возможностей системы.
Однако, необходимо отметить, что пилотный проект - имеет и другую сторону. Внедрение системы, естественно, предполагает адаптацию знаний и требований представителей предприятия к концепциям и принципам, заложенным в ее основы. Существует опасность, что в ходе пилотного проекта представители компании не найдут в системе именно то, что ожидают увидеть. В результате пилотный проект может завершиться отказом от внедрения ERP-системы. "Силовые машины" уже сделали стратегический выбор ERP-системы и от него не отходят. И пилотный проект они запускают для того, чтобы посмотреть, стоит ли идти на расширение или нет. А когда предлагается сделать пилотный проект для того, чтобы выбрать ERP-систему, - это большой риск, так как пилотный проект может быть использован в целях сбора критических замечаний. Поэтому пилотный проект лучше всего использовать для уточнения принципиально важных для предприятия возможностей системы, либо для предварительной углубленной подготовки проектной группы.
В своем докладе Андрей Володин, вице-президент по технологическому развитью компании "Евросеть", рассказал, что, с его точки зрения, главная причина успеха ERP-проекта - собственный руководитель проекта и сильная собственная команда технических специалистов. Насколько этот совет универсален?
Компания "Евросеть" пошла по пути использования консультантов по схеме time&materials. Есть два подхода к использованию консультантов: на основе схемы time&materials или fixed price. При работе по схеме fixed price (Fixed Budget) затраты на консультантов зафиксированы, и имеется разделенная по договору ответственность между заказчиком и консультантами. При работе по схеме time&materials основная работа по организации проекта возлагается на заказчика. Если есть возможность создать сильную команду внутри предприятия, и оно стремится таким образом сэкономить деньги, предприятие осознанно берет на себя эти функции. Тогда проектная группа заказчика стремиться в обозримые сроки разобраться в системе, разработать и принять проектные решения, а консультанты приглашаются для оказания помощи и решения возникающих проблем. Планирование и управление проектом осуществляется руководителем проекта от заказчика, вызов консультантов, как правило, осуществляется по предварительно согласованным ставкам (как на плановой, так и внеплановой основе). Но должен сказать, что сейчас очень мало компаний работают с консультантами по схеме time&materials.
На ERP-форуме не было ни одного доклада, где бы тактикой внедрения ERP-системы был выбран "большой взрыв". Практически на всех проектах осуществлялось поэтапное внедрение ERP-системы. Вообще, о проектах с "большим взрывом" не слышно. Может быть, такие проекты просто невозможны?
Стратегия внедрения "большой взрыв" возможна, но все равно такие проекты не охватывают всего и вся, а имеют определенные рамки. В "большом взрыве" происходит настройка, тестирование запуск в эксплуатацию относительно большого состава модулей одновременно. Такие проекты требуют тщательной организации и мониторинга. В TopS BI мы также стремимся внедрить все необходимые для ключевых бизнес-процессов модули и функциональные возможности системы, но в ряде проектов при стратегии большого охвата придерживаемся тактики поэтапного запуска. И здесь тоже есть разные концепции внедрения. Например, настраивая большую совокупность модулей системы в качестве первого запуска планируем функциональность по закупкам, продажам, запасам, дебиторам, кредиторам и управлению движением денежных средств. Данный перечень позволяет охватить информационной поддержкой процессы обработки входящего и исходящего материального и денежного потока, отработать всю необходимую для дальнейшего развития нормативно-справочную информацию и подготовиться к запуску производства и планирования. Этот подход в ряде случаев позволяет получить промежуточный эффект от внедрения уже в ходе проекта внедрения. Кроме этого имеются объективные ограничения: нельзя внедрить планирование, если не все отклассифицировано и пронормировано, если нет актуальной информации об остатках, о работе службы закупки. Чтобы выйти на автоматизацию планирования, нужно сначала поднять всю учетную часть. Поэтому идет объективный поэтапный процесс приближения к планированию. Иногда менеджеры предприятия предлагают: у нас задача - планирование, давайте с него и начнем. И мы вынуждены отвечать: да, мы начнем с планирования, но только, чтобы начать с планирования, сначала надо сделать вот это, это и это.
Какой этап проекта самый сложный? Мнения на форуме высказывались разные. Одни считают, что это самый первый этап - вхождение в проект. Другие выделяют как самый сложный проходящий через все этапы процесс работы с людьми.
На каждом этапе есть свои ключевые моменты. Если брать первый этап определения стратегии - то это уточнение и окончательное согласование рамок проекта. На этапах анализа операций и проектирования очень важно согласовать все проектные решения, о чем говорил в своем докладе Андрей Рыжов директор по внедрению систем "Северсталь-метиз". Потому что каждое проектное решение предполагает альтернативу. И очень важно по всем проектным вариантам принять принципиальное решение. Потому что пока компания колеблется, что выбрать, нельзя делать проектирование системы. И этот момент принципиально важен, от него зависит скорость развития проекта в целом. Допустим, возникает ситуация, когда консультант вместе с проектной группой проработал варианты проектных решений. Но окончательное решение принимает заказчик, и время принятия решения может существенно сказаться на сроках проекта, потому что это решение обсуждается, увязывается с другими службами. Поэтому, как правило, в договорах оговаривается, что в случае задержки с принятием решения мы согласованно применяем процедуру управления изменениям.
Потом, на этапе настройки системы и разработки, важный момент - минимизация кастомизации. Если возникает кастомизация, то на проекте сразу возникает ресурсная проблема. Ведь заранее не известно, сколько кастомизации будет, и если заказчик подталкивает нас к тому, чтобы писать много расширений, тем самым он начинает размывать ресурсы проекта. Естественно, чем больше компания сделает кастомизации, тем сложнее потом эту систему будет внедрять и сопровождать. Поэтому, когда принимаются проектные решения, нужно как можно больше сократить кастомизацию.
Наконец, очень важно при передаче ERP-системы в эксплуатацию предварительно подготовить группу сопровождения. Это суперважно, потому что на начальном этапе эксплуатации ERP-системы выявляется основное количество проблем, и необходимые службы нужно наладить до запуска системы. И здесь, в начале эксплуатации ERP-системы, консультанты нужны. Потому что они знают систему и довольно быстро могут устранять проблемы. Но цель этой консультационной поддержки заключается не в том, чтобы обеспечить на данном промежутке времени поддержку как таковую. Основная цель - передача поддержки заказчику (об этом говорил Андрей Рыжов). То есть наиболее эффективно, когда в течение этого периода консультанты помогают службе сопровождения решать эти проблемы так, чтобы специалисты предприятия сами научились их решать. Хотя в некоторых случаях мы берем на себя поддержку ERP-системы и дальше, но в рамках отдельного договора на поддержку.
