Пользователям бизнес-приложений Microsoft Dynamics нет оснований жаловаться на отсутствие у вендора стратегии. Она регулярно доводится до сведения широкой общественности, более того, всегда указываются четкие сроки реализации тех или иных инициатив. К сожалению, и планы, и сроки эти чуть ли не с той же регулярностью пересматриваются и корректируются. Особенно запутана ситуация с популярной в нашей стране системой Dynamics NAV. Не исключено, что на конференциях, посвященных практике управления предприятиями с помощью данной системы, слушатели заодно надеются услышать и очередные новости о перспективах развития продукта. Что ж, ожидания участников форума “Управленческие решения на базе Microsoft Dynamics NAV”, организованного консалтинговой группой NaviCon совместно с Microsoft, в этом отношении обмануты не были.

Напомним, что выпуск международной версии Dynamics NAV 5.0, в которой планировалось реализовать трехзвенную клиент-серверную архитектуру, перевод базового функционала в форму Web-сервисов и концепцию нового “ролевого” клиентского интерфейса, в свое время был перенесен с 2006-го на 2007-й . Оговаривалось, правда, что указанные новшества будут представлены в два этапа: первый из них должен был завершиться в марте, а второй — в конце 2007-го (см. PC Week/RE, № 44/2006). Под занавес прошлого года в интервью нашему изданию (см. PC Week/RE, № 43/2007) глава подразделения Microsoft Business Solutions Кирилл Татаринов сообщил о том, что версия 5.1, которая должна была бы стать итогом второго этапа, содержала слишком много архитектурных инноваций и потребовала дополнительного функционального насыщения. В результате было принято решение отказаться от редакции 5.1 и выпустить в 2008 г. сразу версию NAV 6.0. А поскольку пятая версия NAV для России к тому времени локализована не была, то пользователям из нашей страны пообещали, что они получат шестую.

И вот из выступления руководителя группы московского офиса Microsoft по продуктам Dynamics Андрея Гладких мы узнали, что планы корпорации вновь скорректированы. В нынешнем году в России все-таки появится усовершенствованная и локализованная версия NAV 5.0 SP1, поддерживающая ОС Vista и Office 2007, имеющая более высокую производительность на платформе СУБД SQL Server 2005 и обладающая рядом дополнительных функций (в их числе -- процедуры одобрения документов). Зато так и не увидит свет NAV 6.0, поскольку принято решение изменить нумерацию версий всех ERP-систем Dynamics, и теперь место шестерки займет NAV 2009: ее локализованная для России редакция появится в 2009--2010 гг. В ней обещано завершить построение ролевого пользовательского интерфейса, создать новый сервер приложений, реализовав тем самым полноценную трехуровневую клиент-серверную архитектуру, обеспечить поддержку Web-сервисов и добавить средства трансформации форм и отчетов в инструментарий Visual Studio. На более отдаленную перспективу намечено включение в продукт средств моделирования бизнес-процессов, библиотек лучших практик и инструментальных расширений Visual Studio.

Не в меньшей степени, чем достоинства самих программных продуктов, клиентов заботит и качество их внедрения. Как не прогадать с консультантом? Кому доверить развертывание системы? На что обращать внимание в первую очередь? Немало любопытных рекомендаций участники форума услышали именно от консультанта — генерального директора NaviCon Group Даниила Моргалюка. Бытует представление о том, что вендор очень часто рекомендует в максимальной степени использовать стандартную функциональность ERP-системы, мотивируя это тем, что в ней зафиксирован мировой опыт в области управления бизнесом. Заказчик же всегда склонен сохранять свои бизнес-процессы неизменными. Собственные исследования NaviCon показали, что это далеко не так. Более того, в ходе реальных проектов позиция клиента претерпевает заметную эволюцию. Если до старта проекта в среднем 74% заказчиков надеялись обойтись небольшими настройками приложения (т. е. использовать по большей части стандартную функциональность), 22% были готовы, сохранив основные бизнес-процессы, провести некоторую их оптимизацию и лишь 4% сознавали необходимость коренного реинжиниринга, то после сдачи системы в эксплуатацию оказалось, что указанные цифры находятся в соотношении 33% -- 51% -- 16%.

Коль скоро двум третям предприятий стандартной функциональности недостаточно, значит, им понадобятся услуги консультантов. Логика вроде бы железная, но на конференции она неожиданно была поставлена под сомнение. Когда Даниил Моргалюк попросил поднять руки представителей тех предприятий, которые пользовались консалтинговыми услугами, то таковые оказались в явном меньшинстве. Очевидно, репутация специалистов в этой области сегодня не столь высока, чтобы доверять им в полной мере. Попытка г-на Моргалюка дать перечень “примет” плохого консультанта была воспринята аудиторией с несомненным интересом. Наряду с такими туманными формулировками, как “у него не горят глаза”, в этом перечне присутствовали и весьма конкретные полезные рекомендации. Так, плохой консультант склонен разговаривать с менеджерами на языке ИТ, а не бизнеса, он невнимателен к деталям, предпочитает опираться на свой предыдущий опыт, а не вникать в реальные проблемы заказчика, начинает разговор с обсуждения цены, “подтягивая” потом к ней свое коммерческое предложение. Обдумывая все эти признаки, трудно избавиться от мысли, что плохой консультант — это хороший продавец. Может быть, в связи с этим стоит задуматься о том, правильно ли решают кадровые проблемы наши консалтинговые компании.

Взгляд на проектный консалтинг со стороны заказчика оказался гораздо проще и рациональнее. По словам Сергея Костромина — генерального директора “Гамма-центра”, известного производителя и поставщика банковского оборудования, внедрившего у себя с помощью NaviCon систему Dynamics NAV, -- основным критерием при выборе исполнителя проекта было то, насколько глубоко консультант разобрался в специфике их бизнеса. И хотя внедрение в “Гамма-центре” признано успешным, Сергей Костромин порекомендовал участникам форума избегать некоторых сделанных в его компании ошибок: не расширять рамки проекта в ходе его реализации, не тратить деньги на построение очень специализированных отчетных форм и, обратите внимание, все-таки стремиться в максимальной степени использовать стандартную функциональность продукта. “Мы выбирали не средство разработки, а систему для управления нашим бизнесом”, — подчеркнул он.