Как мы сделали крупнейший международный проект 1С:ERP

01.09.23

Архитектура - Кейсы автоматизации

В управлении проектами нет однозначных рецептов, особенно при взаимодействии с заказчиком из другой страны и другой культуры в проектах перехода из принципиально другой исторической системы. Расскажем об истории крупнейшего международного проекта перехода с SAP на 1С:ERP.

Олег: Меня зовут Олег Миньков, со мной – мой коллега Алексей Тачеев. Мы работаем в компании-интеграторе Первый БИТ, в подразделении БИТ:ERP, которое специализируется на крупных внедрениях ERP.

Мы работаем по Scrum: я – Scrum-мастер, Алексей – владелец продукта. Мы оба участвовали в проекте, о котором пойдет речь.

Я больше выполнял менеджерские функции, а Алексей тащил всю прикладную часть. Мы решили выступать сегодня вдвоем, чтобы как можно более объемно осветить проект.

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

 

Олег: Я не буду подробно рассказывать, кто такие Product Owner и Scrum Master. На предыдущей конференции Инфостарта я постарался как следует раскрыть эту тему – по ссылке вы можете посмотреть мое выступление на YouTube (или в статье //infostart.ru/pm/1907819/ – текстовый вариант)

На слайде также приведена моя авторская трактовка, что это за роли.

 

 

Олег: К сожалению, из-за NDA мы не можем называть нашего заказчика, но мы очень надеемся, что это не сделает наш рассказ менее интересным.

 

Олег: Мы считаем, что этот доклад может быть интересным, потому что:

  • Для нас самих сейчас важно подвести итоги, отрефлексировать большой, сложный и интересный проект.

  • Во-вторых, по нашим наблюдениям, фирма «1С» делает уверенные шаги по внедрению своих программ за пределами русскоговорящих стран. И мы надеемся, что тот опыт, которым мы собираемся поделиться, будет интересен и полезен командам, участвующим в международных внедрениях.

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

 

О проекте

 

Алексей: Мы расскажем о крупнейшем зарубежном проекте внедрения.

Проект крупнейший, потому что:

  • Мы автоматизировали производство пищевой продукции с ежемесячным выпуском более полутора тысяч тонн изделий. Производство в двух странах, суммарно более 500 пользователей.

  • В проекте были охвачены практически все подсистемы типовой ERP, кроме российского регламентированного учета и бюджетирования. Даже такая небольшая подсистема как «Управление ремонтами» выросла у нас в полноценный модуль по планированию и обслуживанию производственных мощностей. Также мы охватили блок «Зарплата и кадры», именно поэтому мы внедряли именно российскую версию ERP, а не WE, как первоначально планировали.

 

Алексей: Проект зарубежный, потому что:

  • Русский язык использовался на проекте только для коммуникации внутри команды.

  • Английский – это основной язык. Фарси – для печатных форм и для общения пользователей между собой.

  • Наши пользователи никогда ранее не сталкивались с продуктами фирмы «1С» и не были знакомы: с базовыми принципами учета; с тем, как устроена навигация в программе; что такое справочник, что такое документ; и как вообще со всем этим работать.

 

Алексей: Расскажу про цель проекта – как транслировалась нам эта цель на уровне спонсоров и топ-менеджмента.

  • Переход на новое ПО был вызван невозможностью дальнейшего использования SAP в Иране и Сирии в связи с санкциями.

  • Основная цель на самом верхнем уровне ставилась как запуск ERP-системы с минимально необходимой функциональностью для продолжения производства и сохранения бизнеса.

  • На момент подписания контракта до даты планируемого запуска у нас оставалось порядка шести месяцев, поэтому осознанная цель на тот момент – это запустить именно типовую ERP без какой-либо разработки.

  • Исходя из этих предпосылок срок до запуска проекта был оценен примерно в год на команду из девяти человек.

  • Внедрение подразумевало добавление минимально необходимой функциональности, но эти минимальные доработки понимались разными пользователями на разных уровнях совершенно по-разному.

  • В дальнейшем наше внедрение превратилось в масштабную разработку по требованиям пользователей. Как это происходило, мы раскроем в этом докладе.

 

 

Алексей: Если говорить об объекте автоматизации, то компания управляла производственными площадками в двух странах. На каждой из этих площадок был отдельно выделенный физический завод и головной офис.

Если говорить про завод, там автоматизацией были охвачены такие процессы как:

  • Планирование производства и закупок.

  • Само производство продукции – у нас порядка трех переделов производства.

  • Контроль качества.

  • Адресный склад, паллеты и все связанные с этим вещи.

  • Подсистема по обслуживанию и ремонту линий.

  • И блок, который отвечает за расчет производственной себестоимости.

 

 

Алексей: Если говорить про головной офис, то нам нужно было автоматизировать:

  • Планирование продаж.

  • Блок «Зарплата и кадры».

  • Закупки и продажи в части оформления финансовых документов и взаиморасчетов.

  • Казначейство.

  • Регламентированный учет.

  • И отдельную группу, которая занимается подготовкой консолидированной отчетности и отправкой в органы.

 

Команда проекта

 

Олег: Как уже говорилось, мы рассчитывали, что в проекте будет участвовать девять человек с нашей стороны. Но в итоге работала команда из десяти человек, и я немного расскажу о том, как она собиралась.

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

Мы начали активно искать людей.

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

Мы сосредоточились на поиске отдельно – консультантов со знанием языка и ERP. И отдельно – хороших разработчиков.

В итоге у нас сложилась команда, состав которой указан на слайде.

 

Олег: Если говорить о команде заказчика, то здесь сложилась такая структура.

  • На верхнем уровне – топ-менеджмент, который подключался к проекту для отработки разных серьезных рисков, разных препятствий. Мы раз в неделю встречались на комитете по рискам.

  • Руководитель проекта, который по общему мнению стал таким X-фактором, определившим успех нашего проекта.

  • Два проектных координатора, которые помогали выстраивать процессы – каждый в своей стране: один в Сирии, один в Иране.

  • Ключевые пользователи, которые изъяснялись на английском языке, и были способны рассказать нам о процессах.

  • Конечные пользователи, которые английский язык зачастую не знали и с ними работали уже ключевые, а не наша команда.

 

Выбор технологии внедрения и инструментов для взаимодействия

 

 

Олег: После того, как мы дали вводные по проекту, давайте расскажем о некоторых интересностях, которые были замечены нами в ходе и по итогу проекта.

Начнем с описания взаимодействия между заказчиком и исполнителем.

Я напомню, что наш офис специализируется на выполнении проектов по Scrum. И мы постарались использовать подходы и инструменты, которыми пользуемся на наших локальных проектах.

При этом заказчик в принципе не знал, что такое Scrum, что такое Agile. И первое время он старался нас утянуть в работу по диаграмме Ганта.

Также он очень старательно уходил от необходимости как-то приоритизировать задачи, настаивал, что вся работа должна быть сделана.

Но постепенно нам все-таки удалось показать действенность некоторых наших инструментов.

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

 

Олег: Немного о тех инструментах, которые мы использовали.

Мы начали описывать процессы в виде карт пользовательских историй, как мы делаем это на наших обычных проектах. Но заказчик никак не мог их переварить.

Может быть, мы просто со своим английским не могли ему нормально донести наш концепт.

 

Олег: В итоге мы вели работу по утвержденному списку пользовательских историй по каждому блоку – его видно на этом слайде.

Вот эти списки историй составляли верхнеуровневый бэклог по проекту.

 

Олег: Заказчик, конечно, пытался изначально вытянуть нас на написание всеобъемлющей документации, вплоть до каждого клика мышкой.

Но мы договорились ограничиться составлением так называемых reference cards – это такие короткие описания со скриншотами, как вводить ту или иную операцию.

 

Олег: Кроме этих reference cards мы предоставляли заказчику записи с демонстрационных встреч и доступную документацию по 1С и ERP на английском языке, которая, на удивление, оказалась достаточно глубокой и всеобъемлющей. Ее вполне хватило заказчику для погружения в систему.

 

 

Олег: Практически с первых дней проекта мы начали вовлекать заказчика в тестирование пользовательских историй. Все замечания и ошибки по ним мы начали собирать в такую «волшебную» Excel-ку. «Волшебной» она стала, потому что вся работа выстроилась вокруг нее. Она заменила нам Jira и множество других инструментов. И от греха подальше мы каждый день по несколько раз ее сохраняли, чтобы не потерять накопленную аналитику.

Мы начали собирать в эту Excel-ку обратную связь и какие-то ошибки. Начали разделять эту обратную связь на блокирующую запуск и не блокирующую. И таким образом у нас все-таки появилась некоторая гибкость в управлении требованиями.

 

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

 

Олег: И под самое внедрение мы все-таки запустили Service Desk на базе 1С:ITIL. Перевели его на английский язык, сделали для него более-менее юзер-френдли интерфейс. Заказчик до сих пор уже на этапе сопровождения пользуется этой системой.

 

Формирование целей и работа с ожиданиями на разных уровнях

 

 

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

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

По каким-то процессам мы улавливали бизнес-логику и потенциальное воплощение в системе, а какие-то процессы оказывались для нас абсолютно непонятными.

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

Сейчас, уже спустя какое-то время, можно выделить основные причины этой сложности.

  • В первую очередь, это, конечно, английский язык. Дело в том, что для нас английский – неродной, для заказчика английский – неродной, это накладывало определенные ограничения.

  • Также заказчик много использовал собственной корпоративной терминологии.

  • Плюс терминология исторической системы SAP.

  • Плюс довольно интересные в некоторых местах переводы от 1С, которые тоже несколько вносили в это путаницу.

Как мы с этим боролись:

  • Первый действенный способ – это изучение SAP по роликам в YouTube. Это довольно быстро и понятно. Мы таким образом смогли разобраться с несколькими сложными подсистемами, например, с подсистемой переоценки.

  • Следующий способ – мы бесконечно показывали, как работает типовая конфигурация. Заказчики сами нам предложили: «Покажите, как это работает в 1С, и мы сами подумаем, как нам с этим жить. Как мы можем это использовать». И мы показывали. По локальным функциям это привело к определенному успеху. Но сложные сквозные демопримеры, например, финансовый учет от закупки материалов через производство до продажи – оказалось сложно объяснить логику формирования проводок и отчетов по себестоимости. Или, например, планирование производства – возможно, в силу нашего английского нам не удалось продать то, как работает типовое планирование.

  • Но самым действенным стало быстрое прототипирование и обсуждение этих прототипов. Мы видоизменяли формы, дорабатывали переводы, рисовали свои интерфейсы и выходили на совещание с обсуждением этой функциональности. И как только на совещании мы уходили за пределы того, что можем сейчас в системе открыть и посмотреть, мы сразу же фиксировали результат и готовились к следующему совещанию.

 

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

 

Алексей: Следующей такой знаковой особенностью для нас стало то, что пользователи сами практически не знали, как работает их собственная историческая система.

Дело в том, что по замыслу нам предстояло выделить два завода из общей корпоративной системы SAP, в которой одновременно работает несколько десятков заводов.

При этом в силу внутренней автоматизации и оптимизации работы пользователей, каждый пользователь был сконцентрирован на выполнении каких-то своих однотипных операций.

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

Проблема ярко проявилась при распределении производственных затрат и планировании производства. В части распределения нам просто сказали: «SAP считает так, нам нужно так же». А как она посчитала, никто не имел представления.

Важно, что этот вызов в первую очередь требовалось преодолеть не только нашей команде, но и команде заказчика.

Олег: Еще одним интересным открытием было то, что поначалу заказчик не мог нам сказать, кто вводит некоторые операции в систему.

Только спустя несколько недель поисков мы нашли людей, которые занимаются, например, вводом таких распространенных операций, как реализация и приобретение.

Выяснилось, что этим занимается некая отдельно выделенная компания, которая централизована по всем заводам, не только в Иране и Сирии. Она сканирует бумажные документы и вводит соответствующие транзакции в систему.

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

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

  • во-первых, им нужно было понять, что мы от них хотим;

  • во-вторых, как-то перетрясти свои внутренние процессы и разобраться в логике собственной программы, чего в общем-то им до этого не приходилось делать;

  • и, в конце концов, взять уже ответственность за введение информации в новую сложную систему.

 

Баланс между типовой конфигурацией и разработкой

 

Алексей: Следующий важный момент, который хотелось бы отметить – это баланс между типовой функциональностью и разработкой.

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

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

Таким образом, мы перешли от внедрения типовой конфигурации в масштабную разработку.

На данный момент (прим. ред. ноябрь 2022) у нас система работает на версии ERP 2.5.8, и мы не планируем эту конфигурацию обновлять.

По некоторым сложным моментам – там, где в части разработки мы были уже абсолютно бессильны, например, по партионному учету или по трансляции проводок, у нас был контакт с коллегами из 1С, и они нам несколько раз очень хорошо помогли. Пользуясь случаем, хотелось бы выразить им большую благодарность.

 

Запуск проекта

 

 

Олег: Перейдем, наверное, к самому интересному – это командировка.

Сейчас это довольно сложно себе представить, но нашего выезда в Иран на запуск системы могло не состояться. И, честно говоря, это могло бы стать фатальной развилкой. Потому что вполне возможно, что удаленно запустить систему нам бы не удалось. Но в конечном итоге все закончилось хорошо.

Мысль о том, чтобы поехать туда, в самый нужный момент пришла в голову нашему куратору проекта. И ее поддержала команда. Часть из команды преодолела свои предрассудки насчет поездки в Иран. А сейчас об этих предрассудках даже смешно говорить.

Также и со стороны заказчика были определенные сложности, поскольку были серьезные ковидные ограничения на перемещение. Но как раз в тот момент эти ограничения были очень удачно немного ослаблены. И заказчик нам согласовал поездку.

 

 

Алексей: Окончательная дата старта была назначена на 1 января, на начало нового финансового года. И практически сразу после празднования Нового года, в ночь с первого на второе, мы всей командой выехали в Тегеран.

Это был, наверное, самый волнительный момент, поскольку нам предстояло познакомиться, увидеть вживую людей, с которыми мы взаимодействовали уже практически год. И сверить свои фантазии о процессах с их реальным течением.

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

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

Следующее важное открытие, которое хочется отметить – это непосредственно сама технология запуска.

Первые операции в производстве должны были начаться 4 января. Но на случай, если что-то пойдет не так, у каждого пользователя для каждой операции был подготовлен специальный бланк с нужными колонками, в которых требовалось регистрировать выполнение этой операции. И по факту получилось так, что три дня реальный учет велся на таких бумажных бланках. А мы в эти три дня все еще грузили нормативную справочную информацию, стабилизировали систему, грузили остатки.

И только после этого мы собрались в большом зале, куда к нам приносили эти бланки с мест, и начали заносить эти бланки, постепенно догоняя реальный учет в системе. Спустя время нам удалось это сделать и полноценно запустить оперативный контур.

Но это было еще не все, поскольку уже в феврале нас ждала новая поездка в Тегеран – уже на закрытие месяца. Но это – уже совсем другая история.

 

Выводы

 

 

Олег: Мы постарались за полчаса рассказать о проекте, о котором можно рассказывать гораздо дольше. И еще сложнее уместить свои большие выводы в пару тройку тезисов.

Но успех проекта мы связали с двумя факторами.

  • Первый фактор – это наша команда. В ней собрались, возможно, сильнейшие специалисты, с которыми я работал за всю свою долгую карьеру в 1С. Эти специалисты были суперзамотивированы сделать, возможно, одно из самых интересных внедрений в их жизни. У нас не было прямого управления, а мне, как scrum-мастеру, нужно было вначале помочь команде сладиться и потом по ходу дела устранять некоторые препятствия. А дальше на моих глазах начала работать та самая пресловутая самоорганизация, о которой мы читаем в книгах. Алексей не даст соврать, команда потащила проект к цели как локомотив.

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

Подытожим: это внедрение – посещение новой страны и обретение новых друзей – было бы невозможно без английского языка. Мы для себя точно сделали вывод, что его учить нужно, и это никогда не поздно начать. Мы с Алексеем начинали проект на уровне pre-intermediate в плане общения, тем не менее мы решали вопросы, находили взаимопонимание и двигали проект вперед.

Хочу огласить тезис, который мы вынесли по итогам этого проекта:

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

С первым пунктом мы уже точно справились и успешно вышли из зоны комфорта. И как в одном меме говорится: «Коуч, мы вышли из зоны комфорта. Что дальше?» Ну а дальше, по нашему мнению, дело за развитием в каких-то новых областях.

Мы с Алексеем желаем вам большого успеха в их освоении!

 

 

Олег: На этом слайде показаны все 10 героев, которые сделали это внедрение.

Этот проект не был бы до конца международный, не был бы до конца символичный, если бы не тот факт, что в команде с нами участвовало два человека из Украины.

Мы хотим всем пожелать мира!

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

См. также

Кейсы автоматизации Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

12.11.2024    201    0    TUProgrammer    0    

0

Продуктовый подход Кейсы продуктов Бесплатно (free)

В пятом выпуске третьего сезона подкаста Радио “Аналитик“ обсудили, что важно знать и уметь аналитикам для работы с 1С:ERP, поговорили про историю развития 1С:ERP и планы на будущее.

08.11.2024    301    0    Radio_Analyst    0    

3

Кейсы автоматизации Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

29.10.2024    356    0    TUProgrammer    0    

1

Кейсы проектов Руководитель проекта Бесплатно (free)

В управлении проектами нет готовых рецептов – часто приходится опираться на чужой опыт. Расскажем о признаках, которые показывают, что проект становится кризисным, и о реальном кейсе вывода проекта 1С из кризиса.

28.10.2024    662    0    paalferov    2    

5

Кейсы автоматизации Бизнес-аналитик Платформа 1С v8.3 Конфигурации 1cv8 Россия Управленческий учет Бесплатно (free)

Сфера деятельности заказчика: Капитальный ремонт нефтегазовых скважин. Численность сотрудников компании: 4 300 сотрудников. Срок автоматизации системы управления: 6 месяцев. Внедренное решение: Бюджетир.

21.10.2024    410    0    user2092247    0    

2

Кейсы проектов Бесплатно (free)

Управление любым проектом заключается в систематической работе по снижению рисков. Чтобы избежать бесконечного цикла итераций согласования и приемки работ, нужно фиксировать границы проекта в Уставе, обозначать зоны ответственности и внимательно составлять план-график. О практическом опыте избегания рисков на проекте на конференции расскажем в статье.

09.09.2024    596    0    user1231217    1    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. e9504100606 92 02.09.23 20:21 Сейчас в теме
Спасибо за статью!
10 героев - круты. Начал читать с конца, чтобы хэппи-енд увидеть и он потрясающий - за 4 дня внедрить и все стабильно. Интересно, как сейчас живет и развивается проект.

Крутой разработчик, крутые знания ERP, крутые знания английского. Кажется, формула успеха известна ;)
2. Xershi 1555 07.10.23 00:08 Сейчас в теме
В каком режиме работали разработчики?
По оплате на ставку х2 по рынку выходило?
Проект на поддержке?
Мои поздравления!
Оставьте свое сообщение