Чтобы эффективно продвигать бренд 1С в других странах, выполнение международных проектов ERP должно быть осуществляться в полном объеме, в срок и в рамках бюджета с одновременным обеспечением внутренней согласованности создаваемых решений, поэтому важным элементом таких проектов является архитектурное сопровождение, а также работа и развитие локальных команд.
Трехуровневая модель работы на международных проектах
На схеме показано, что в международных проектах мы выделяем три уровня взаимодействия.
Нижний уровень – работа на местах с ключевыми и конечными пользователями. За него отвечает международный партнер и его команда, которую он формирует в стране реализации проекта. Их задача – сбор требований ключевых пользователей, согласование их с функциональными заказчиками, а также проведение обучения и тренингов, и поддержка конечных пользователей.
Команда компании 1С отвечает за архитектурную поддержку проектов, за архитектурную целостность создаваемого решения. Силами технических специалистов и разработчиков мы замещаем недостающие компетенции на верхнем уровне: проектирование и доработку типовой системы 1С:ERP, создание сложной функциональности, которую местные специалисты выполнить не могут.
Средний уровень – это зона нашей совместной работы со специалистами партнеров, и здесь мы создаем функциональные и технических решений, обеспечивающие реализацию собранных требований заказчика.
Работа строится следующим образом: в первую очередь мы создаем совместное решение нашими силами, затем обсуждаем его с местной командой. После этого они презентуют это решение – продают и защищают его – объясняя заказчику, где именно он получает новую ценность за счет внедрения системы.
Основная цель международной деятельности: развитие локальных команд
Сейчас реализуется много проектов за рубежом, но значительная часть таких проектов – это так называемые «русские для русских». Это ситуации, когда российская компания, использующая продукты 1С как внутренний стандарт, открывает филиал за рубежом – в Китае, Юго–Восточной Азии, Африке. На место приезжает команда русскоговорящих специалистов, реализует проект и уходит.
Задача компании 1С как вендора решений – создавать и развивать местные команды, чтобы на местах были специалисты, способные создавать комплексные решения на базе систем на платформе 1С:Предприятие и обеспечивать их поддержку.
Подход к развитию команд–партнеров
Каким образом мы осуществляем развитие команд партнеров? В первую очередь через совместное выполнение проектов: выработку решений и их обсуждение внутри команды. Мы проводим внутреннюю защиту и обоснование этих решений нашим коллегам, являющимся представителями партнеров, а уже они «продают» их заказчику.
Второе направление – проведение тренингов. Мы вкладываем много сил и времени в создание учебных тренингов, адаптированных под местную специфику, обучение и развитие местных специалистов, понимая, что после нашего ухода именно они будут создавать решения 1С.
Мы начали с общих тренингов по концепции системы 1С:ERP и по программированию. Затем перешли к специализированным тренингам по производству и управленческому финансовому учету в системе.
В какой–то момент стало понятно, что необходимо рассказывать о том, как управлять проектом и как реализовывать проекты по внедрению ERP.
Кроме того, мы создали тренинги по развитию компетенций специалистов, где объясняем карьерные грейды и требования к каждому уровню развития. Это важно, как для специалистов, чтобы видеть перспективу для своего развития, так и для руководителей и менеджеров партнеров, чтобы понимать, какими ресурсами они располагает, чтобы обеспечивать текущую деятельность и планировать проекты.
Масштабы международных проектов
Масштабы проектов у нас сейчас относительно небольшие – как правило, 100?150 рабочих мест, но это не означает отсутствие спроса или невозможность брать более крупные проекты. Спрос есть, но наша задача не в том, чтобы отправить русскоговорящих специалистов, которые сделают проект, уйдут и не оставят после себя ничего, кроме работающего решения.
Просто местные команды пока относительно небольшие, поэтому именно уровень их численности и зрелости ограничивает масштабы проектов ERP, которые мы можем успешно выполнять. Поэтому основным приоритетом являются вопросы их расширения, развития, накопления ими опыта использования системы 1С:ERP и других продуктов 1С. Данные вопросы актуальны и в России, но являются критически важными за рубежом.
География проектов изменилась. Изначально планировалось ориентироваться в первую очередь на Европу. После известных событий направление сместилось. Сейчас основная зона активности – Юго–Восточная Азия, Ближний Восток, Африка, а также страны, с которыми Россия исторически имеет экономические отношения вследствие их географической или культурной близости: Турция, Сербия и другие.
Специфика международных проектов: возможности и сложности
Самый важный момент – на зарубежных рынках есть спрос на продукты 1С.
В первую очередь, это связано с тем, что сейчас активно развивается производство в странах Юго–Восточной Азии. Китай стал дорогой страной по уровню оплаты труда, и западные компании, а также компании других регионов, ищут возможность сократить издержки и открывают производство в других странах этого региона. И эти предприятия, в процессе своего органического роста переходят к стадии, когда одного Excel им уже недостаточно для решения задач управления, а на системы уровня SAP или Oracle Business Suite у таких компаний нет бюджета.
Но отсутствие большого бюджета это не означает, что у руководителей нет запроса на комплексную автоматизацию и понимание того, что происходит на их предприятиях: где имеются проблемы, где создается прибыль, а где – возникают убытки.
Поэтому запрос на решения 1С присутствует, 1С конкурентоспособна по цене и функциональности. По экспертной оценке, 95% задач закрываются типовой функциональностью, и только около 5% требуют кастомизации и доработки.
Вызовы и ограничения
Из факторов, которые нельзя назвать негативными, но их необходимо учитывать, заходя на эти рынки, можно выделить несколько особенностей.
Во–первых, сразу возникает запрос на комплексные решения. Если вспомнить развитие автоматизации в России, сначала был спрос на бухгалтерский учет, затем появились решения базовой автоматизации производства, позже – УПП, сейчас используется ERP. На международных рынках ситуация иная: меньший бюджет не означает отсутствие понимания конечных целей. Заказчики ожидают комплексное решение, которое включает систему, консалтинг и интеграцию с внешними сервисами, например, площадками электронной коммерции.
Второй важный момент – отсутствие сформированного рынка решений 1С. Отсутствует узнаваемость бренда и нет партнеров, у которых можно взять ресурсы для реализации проектов. Если в России 1С является де–факто стандартом автоматизации, особенно после ухода международных брендов, то на зарубежных рынках это не так. Там необходимо конкурировать, прилагать усилия для продажи систем на платформе 1С и последующего создания решений на их базе.
Также отсутствует пул реализованных крупные проектов, на которые можно ссылаться в ходе проведения пресейлов. Сложно или даже невозможно привести пример компании из той же страны и отрасли, которая уже использует продукты 1С и получает измеримый результат, чтобы заказчик мог ориентироваться на получение аналогичных выгод.
Проблемы коммуникации на международных проектах
По нашей экспертной оценке, трудозатраты на коммуникации в международных проектах примерно в ЧЕТЫРЕ РАЗА ВЫШЕ, чем на российских.
На это оказывают влияние следующие факторы:
Первый фактор – языковой барьер внутри команды. При трудоустройстве члены команды 1С поддержки международных проектов сдают тест на знание английского языка, но то, что язык знаем мы, не означает, что его знают все специалисты в международной команде. Часто приходится работать через переводчика. Общение через переводчика увеличивает время коммуникации не в два, а как минимум в два с половиной раза: сначала говоришь ты, потом переводчик, а твой иностранный коллега слушает, и при этом что–то понимает, а что–то – не понимает и это требует уточнения и разъяснения, и на все это уходит дополнительное время.
Второй фактор – квалификация команды. Много времени уходит на развитие специалистов, объяснение, казалось бы, очевидных вещей, касающихся устройства систем 1С и проведение обучение. На российских проектах многие вопросы решаются быстро: собрались после обеда, поговорили в неформальной обстановке, приняли решение, достигнутые договоренности подтвердили по email и пошли делать работу. На международных проектах практически каждый вопрос требует предварительного планирования и организации совещания.
Есть еще одна особенность. Даже если решение уже подготовлено, его нужно сначала продать коллегам, говорящим на местном языке. Часто необходимо подготовить презентацию, потому что их квалификации и понимания продуктов 1С недостаточно для восприятия аргументов в устной форме. Презентация помогает им затем презентовать и «продать» это решение ключевым пользователям и функциональному заказчику. Но на все это требует дополнительных усилий и времени, и это необходимо учитывать.
Следующая особенность связана с источниками информации. В России мы всегда имеем возможность работать с нормативными и первичными документами: регламентированными документами на уровне Российской Федерации – законам, постановлениям, разъяснительным письмам – а также с внутренними документами предприятия, которое автоматизируем. На международных проектах это в лучшем случае доступно в ограниченном объеме.
Нормативные акты страны, в которой выполняется проект, можно перевести автоматическим переводчиком, но нет никаких гарантий, что при переводе не будут потеряны важные смыслы. И это, не принимая в расчет сложности в понимании нормативных требований, которые могут быть там написаны и которые могут кардинальным образом отличаться от практик, принятых в России.
В части внутренних документов предприятия приходится работать с тем, что получают у заказчика и передают консультанты, что не всегда позволяет сформировать полную картину деятельности предприятия. А каждый дополнительный запрос, каждая перепроверка полученных сведений требуют времени.
В совокупности эти факторы приводят к значительному увеличению сроков и, как следствие, увеличения бюджета международных проектов. Это необходимо учитывать. Если вы как руководители компании–партнера или проекта планируете такую работу, то эти особенности нужно учитывать заранее.
К чему это привело? Необходимость решать перечисленные проблемы показала, что нам необходимо использовать проектные технологии, которые позволят предсказуемо и грамотно выполнять проекты ERP. Первым стремлением было использовать уже существующие технологии. Мы рассмотрели несколько вариантов и вначале попробовали Технологию Быстрого Результата и Agile, то есть гибкие технологии.
Оценка существующих методологий: технологии быстрого результата и Agile
Технология Быстрого Результата (ТБР), рекомендованная 1С, фокусируется на создании системы и ее адаптации. Но, как я уже отмечал, заказчик хочет комплексное решение. Помимо системы туда входят организационные изменения, мероприятия по нормализации данных, разработки и/или адаптации методологии учета. В Технологии Быстрого Результата этого нет. В ней прямо указано, что она ориентирована на внедрение типовых решений. На международных проектах задача иная – создать решение, настроенное под конкретную компанию и в полном объеме отражающее ее бизнес–преимущества на местном и международном рынках.
Еще одна сложность Технологии Быстрого Результата – отсутствие четкой этапности проекта. Мы не можем корректно сообщить заказчику, что уже сделано и какие итоги можно подвести, а также что будет выполняться дальше.
Главная особенность технологий Agile – потребность в значительном объеме коммуникаций. Это справедливо и для Технологии Быстрого Результата, и для Agile–подходов в целом, которые предполагают постоянные коммуникации внутри команды и с заказчиком. На международных проектах коммуникации часто упираются в наличие переводчика и наличие у него свободного времени. Когда над проектом работает несколько подкоманд – производство, продажи и другие блоки – переводчик становится узким местом, ограничивающим решение задач в установленные сроки.
По Agile–технологиям также возникают сложности, касающиеся отсутствия четкой этапности выполнения работ – выполнение проекта представляет собой последовательность спринтов и задач, не сопровождаемых явно выраженными процедурами управления проектом и возможностью четко определять сроки завершения отдельных этапов и проекта в целом – это не устраивало ни нас, ни заказчика.
Оценка классических проектных подходов
Также мы пробовали использовать классические технологии проектной направленности.
Первая – Технология Корпоративного Внедрения компании 1С. И это отличная технология, которая широко применяется в России – многие с ней знакомы и используют ее в своей работе. Чем она нас не устроила?
Во–первых, в ней делается акцент на создание системы, тогда как то, что мы создаем, шире, чем сама система.
Во–вторых – этапность. Этапы представлены укрупненно, особенно этап реализации системы, который включает множество действий. Мы не всегда понимаем, где заканчивается одно действие и начинается следующее и, как следствие, не можем это объяснить заказчику.
Классический проектный подход, описанный в PMBOK, также рассматривался. Здесь возникли другие проблемы, не позволившие использовать его напрямую. Как и в России, он нигде не применяется в том виде, в котором описан в PMBOK. И основная сложность в том, что он совершенно не учитывает особенности предметной области и специфику создания решения ERP на базе системы 1С:ERP и все связанные с этим мероприятия и процедуры.
Проектный методология для международных проектов ERP
Оценив все подходы, мы проанализировали их, взяли из каждого лучшее и создали собственную проектную методологию.
Так выглядит жизненный цикл проекта в этой технологии, включающий 10 этапов. Здесь нет этапов, которые были бы незнакомы или не встречались бы на российских проектах – главное в другом.
Мы явно декларируем, что целью внедрения является создание для заказчика решения ERP и это не только система. Система 1С:ERP важна и она является базой для всех дальнейших мероприятий и работ, но создаваемое решение должно стать частью бизнеса заказчика – эту мысль мы транслируем консультантам и заказчику.
В решение, помимо системы, входят организационные процедуры и трансформация организации, если она необходима. И это часто требуется, поскольку если заказчик обращается за внедрением, очевидно, что он недоволен текущим состоянием процессов, но не понимает исходных причин проблем.
Приведу пример. На одном проекте мы в течение недели объясняли, как в 1С:ERP считается себестоимость и это было нужно потому, что после запуска выяснилось: из 15 филиалов компании три стабильно убыточны. Сначала, детально объяснив механизм расчета, мы убедили в правильности расчетов консультантов партнера и руководителя проекта со стороны заказчика, а уже затем они донесли эти результаты руководству заказчика. Без 1С:ERP и созданного на ее основе решения эти проблемы не были видны и именно поэтому компании приходят за внедрением ERP.
Все это выполняется в рамках проектного подхода, поскольку именно так мы понимаем, что наши действия по созданию решения ERP конечны и проект должен завершиться.
Структура и цели проектной технологии
В рамках предложенного проектного подхода мы определили и описали основные элементы управления проектом и довели их до всех членов проектной команды – как со стороны партнера, так и со стороны заказчика.
Цели и задачи каждого этапа – так мы разделяем совместное видение того, к чему стремимся на каждом этапе и что хотим получить по его завершении.
Ключевые результаты этапов, а также рабочие документы, которые мы используем –таким образом мы консолидируем деятельность всей проектной команды на выполнение определенных работ.
Отдельно важно отметить фокус на четкое определение границ решения ERP. Ключевой момент, которого мы стремимся достичь таким образом – не брать на себя обязательств больше, чем можем выполнить. Как уже было отмечено выше, основная причина здесь в том, что наши проектные команды сейчас достаточно небольшие. Кроме того, их численность невозможно быстро увеличить – так, в России вопросы ресурсного обеспечения проектов можно решить, привлекая дополнительные ресурсы с рынка или «заимствуя» их у других партнеров. На международных проектах такой возможности пока нет, и в ближайшее время она, скорее всего, не появится.
Преимущества новой методологии
Основным преимуществом подхода является формальном выделении этапов создания решения ERP в рамках объединения подходов управления проектом и создания информационной системы ERP – таким образом мы понимаем, где начинается и заканчивается каждый этап, а также критерии его завершения.
На каждом этапе у нас объединены различные уровни проекта ERP, что снижает потребность в коммуникациях – это было для нас важным результатом, так как теперь нам не нужно каждому участнику проекта отдельно объяснять, что и зачем мы делаем – для нас это критично и ранее подчеркивали почему.
Жизненный цикл проекта ERP
Solution Proposal / Предложение решения
Основной целью этапа является конвертация первичного обращения заказчика в решение о начале проекта ERP.
Также необходимо:
• Убедить заказчика, что предлагаемое решение может выполнить заявленные бизнес– требования и создать ценность для его бизнеса;
• Показать заказчику, что мы понимаем ключевые особенности его бизнеса;
• Показать заказчику, что мы обладаем необходимыми компетенциями и опытом.
Чтобы достичь данных целей, необходимо решить следующие задачи:
1. Выявить бизнес–требования;
2. Сформировать видение решения;
3. Презентовать видение решения.
На этапе «Solution Proposal» дополнительно можно выделить следующие подэтапы:
A. Request / Запрос;
B. Proposal / Предложение;
C. Agreement / Соглашение.
Для каждого из этапов/подэтапов определены ключевые входы и результаты и, в качестве примера, рассмотрим такие результаты, которые мы получаем на подэтапе “Request” / «Запрос»:
• [Solution] Видение решения;
• [Solution] Коммерческое предложение;
• [Project] Устав проекта (черновик);
• [Project] Планы управления проектом (черновик).
Обратите внимание, что здесь есть цели для решения ERP, и цели для проекта ERP – то есть, что мы должны сделать в рамках создания решения и управления проектом, а также могут быть выделены цели для создания системы ERP – обычно это документы, оформляющие ее глубокую кастомизацию.
Данные три аспекта управления проектом ERP мы обособляем и отдельно указываем, что должны получить в рамках каждого из них. Префиксы, стоящие перед названиями ключевых результатов, показывают в рамках какого из аспектов управления проектом ERP эти результаты создаются.
Все материалы для партнеров мы предоставляем на английском языке, а они сами могут принять решения об их переводе переводят на местный язык, потому что местные специалисты не всегда хорошо владеют английским.
Solution Discovery / Обследование решения
Основной целью этапа является изучение и анализ бизнес–процессов объекта автоматизации с точки зрения определения исходной точки для создания решения ERP.
Также необходимо:
• Выявить потребности заинтересованных сторон;
• Изучить контекст создания решения ERP: ситуации в отрасли, действий конкурентов, изменения нормативного регулирования и т.п.
Чтобы достичь данных целей, необходимо решить следующие задачи:
1. Провести обследования бизнес–процессов;
2. Подтвердить результаты обследования;
3. Специфицировать требования;
4. Проанализировать и проранжирование требований;
5. Утвердить требований.
Solution Formation / Формирование решения
Основной целью этапа является разработка предварительного варианта архитектуры и сценариев использования решения ERP.
Чтобы достичь данной цели, необходимо решить следующие задачи:
1. Разработать концептуальную модель использования решения;
2. Разработать сценарии использования решения;
3. Декомпозировать решение на функциональные подсистемы;
4. Проработать интерфейсы между подсистемами;
5. Разработать требования к аппаратному обеспечению и сетям.
Solution Simulation / Моделирование решения
Основной целью этапа является получение обратной связи заинтересованных сторон на разработанный прототип решения ERP.
Также необходимо:
• Выявить потребности заинтересованных сторон;
• Изучить контекст создания решения ERP: ситуации в отрасли, действий конкурентов, изменения нормативного регулирования и т.п.
Чтобы достичь данных целей, необходимо решить следующие задачи:
1. Разработать прототип решения;
2. Организовать демонстрацию прототипа решения;
3. Зафиксировать обратную связь заинтересованных сторон.
Здесь мы не будем рассматривать каждый этап, но подобным образом описаны все этапы, их результаты и артефакты проекта, создаваемые в ходе их выполнения.
Практические трудности внедрения методологии
Когда мы разработали данный проектный подход, то в теории все выглядело замечательно, но на практике мы столкнулись с тем, что заказчик не готов оплачивать работу по управлению проектом и создание дополнительных документов.
Создание любого проектного документа – это действия, это дополнительные трудозатраты и за это не необходимо платить деньги, поэтому возникают сложности с тем, чтобы обосновать заказчику почему это не обходимо делать.
Также иногда консультанты партнеров не могут самостоятельно подготовить проектные документы – приходится проводить дополнительные мероприятия по их обучению и развитию.
Но все это необходимые действия, формирующие необходимую базы для перспективного сотрудничества и успешного выполнения проектов ERP.
Упрощение методологии и критические артефакты проекта
Как следствие, имея комплексный подход и понимая, что так он не работает, мы начали его упрощать и выделили так называемые критические артефакты проекта – то, без чего проект абсолютно точно невозможно успешно сделать, невозможно организовать коммуникации внутри проекта и вообще двигаться дальше.
К таким критическим артефактам мы отнесли:
-
Требования к решению ERP;
-
Прототип решения ERP;
-
План миграции данных.
Требования к решению ERP – это то, с чего начинается работа на этапе пресейла, когда мы только приходим к заказчику и выслушиваем его пожелания к будущему решению ERP, и то, чем она заканчивается, когда перед подписанием актов, мы проверяем реестр требований и подтверждаем, что созданное решение им соответствует.
Прототип решения ERP – ключевой артефакт и основное средство коммуникации, вокруг которого мы организуем работу всей команды проекта. Работу как с представителями партнера, так и с функциональными заказчиками и другими заинтересованными сторонами. Мы не просто готовим прототип, демонстрируем его заказчику и забываем про него, но до момента развертывания целевого решения и начала опытно–промышленной эксплуатации данный прототип постоянно используется, развивается и на нем проверяются гипотезы и выработанные решения.
План миграции данных – еще один критический артефакт. Мы должны понимать, откуда возьмутся данные для наполнения решения ERP и как они туда попадут. Потому что часто мы сталкиваемся с представителями заказчика, которые много говорят, выдвигают различные интересные идеи и теории, но не могут поддержать организационными мероприятиями и информационной обеспеченностью своей компании. Поэтому понимание того, откуда мы возьмем данные и как будем наполнять систему, мы начинаем формировать уже на этапе проектирования системы.
Для всего остального мы говорим коллегам: хорошо, мы можем делать все документы, которые описаны в предлагаемом нами подходе и каждый из них будет способствовать уменьшению неопределенности и рисков проекта, но они не такие критичные.
Текущее состояние и перспективы развития
В данный момент:
-
Разработан и описан поэтапный жизненный цикл проекта ERP с указанием выполняемых действий и создаваемых артефактов;
-
Разработан тренинг “ERP Project Management Essentials” / «Основы управление проектами ERP»,
-
Разработано руководство (pocket guide) на основе материалов тренинга.
Продолжаем работать над шаблонами проектных документов.
В планах развитие инструментального обеспечения управления проектом:
-
Выбор базового программного продукта управления проектом;
-
Разработка рекомендаций по его использованию.
Основная задача тут перейти с партнерами к использованию информационной системы в рамках которой будем планировать и координировать нашу совместную работу.
Результаты создания подхода
-
Удалось сформировать основу реализации проектов ERP на базе жизненного цикла проекта, разделяемого как командой исполнителя, так и заказчиком;
-
Определить ключевые результаты для каждого этапа проекта ERP
-
Выделив при этом критические результаты;
-
-
Определить инструменты и действия управления проектом
Фактически, предложив и используя данный подход, мы сформировали фреймворк реализации международных проектов ERP – основу для коммуникации внутри общей проектной команды, а также с представителями заказчика. И теперь каждый на проекте понимает, что мы сейчас делаем, какие результаты получим и почему они важны для заказчика.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.