Реально ли запустить 1С:ERP 2 на градообразующем предприятии за 3 месяца?

 

Где внедряли проект

 

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

 

 

Я буду рассказывать о реальном кейсе – внедрение на Пикалевском глиноземном заводе, градообразующем предприятии, где работает 3 тысячи сотрудников. В рамках проекта было автоматизировано 170 рабочих мест – это в принципе средний по размеру проект.

У заказчика было более-менее типовое внедрение УПП. Что значит «типовое» в моем понимании? Это то, что мы автоматизировали блоки регламентированного учета, склад, закупки, продажи. Из нестандартных вещей – блок планирования закупок, обеспечение потребностей.

Задача следующая: бизнес генерирует какие-то требования, ответственным за развитие ИТ-систем понятно, что УПП рано или поздно надо будет менять, также понятно, что часть требований, которые у бизнеса есть, решаются в рамках типового продукта 1С:ERP.

Поскольку выполнение требований в рамках УПП – это:

• во-первых, гарантированная переделка в ближайшем будущем: ты платишь за одну и ту же функциональность два раза – первый раз за внедрение ее в УПП, второй раз – за перенос на ERP;
• второй минус – ты платишь за изобретение велосипеда, который уже изобрели в рамках 1С:ERP 2.

Отсюда задача – с ограниченным бюджетом и как можно быстрее перейти на новую систему.

 

Lean-подход

 

 

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

 

 

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

Он заключается в следующем: деятельность компании, в том числе компании-внедренца, направлена на создание ценности для заказчика. Ключевое понятие этой философии, этого подхода – ценность. Мы определяем ценность, мы определяем критерии.

Основные задачи заказчика я сказал:

•  он хотел внедрить как можно быстрее;
•  у него был ограниченный бюджет – он хотел внедрить как можно дешевле;
•  и он хотел сохранить конфигурацию ERP максимально типовой, чтобы ее было проще и дешевле сопровождать.

Lean-подход говорит:

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

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

 

Виды потерь

 

 

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

Основные виды потерь и классификация этих потерь следующая:

• перепроизводство – мы производим то, что нужно заказчику, но слишком много;
• дефекты – потери, связанные с постоянной переделкой: мы что-то сделали, но не так, и переделываем. С точки зрения заказчика, с точки зрения ценности – это потеря, потому что все затраты на переделку неэффективны для заказчика, они ему не нужны;
• запасы. Классический пример – каскадный проект, где очень много запасов, очень много незавершенки. Потому что мы часто начинаем с обследования, потом идет проектирование, разработка ТЗ, разработка, подготовка к опытной эксплуатации… Но что тут ценного для заказчика? Ведь заказчик никогда не заказывает ТЗ для того, чтобы получить ТЗ. Он заказывает ТЗ для того, чтобы получить систему, которую он будет использовать в своей реальной деятельности;
• лишняя обработка – это когда мы делаем что-то другого сорта. Допустим, заказчик хочет Жигули, а мы делаем Bentley. Но ему-то были нужны Жигули, и проблема здесь не в качестве, а именно в другом сорте;
• ожидание;
• лишние движения;
• потери на транспортировку;
• неиспользуемый талант сотрудников – это отношения типа «я заказчик, ты дурак» или же отношения иерархии – «я начальник, ты дурак», «ты начальник, я дурак». В этом мировоззрении, в этой картине мира, конечно, талант сотрудников использовать сложно.

 

Концентрация на ключевых процессах

 

 

Второй подход, который вытекает из первого – это концентрация на ключевых процессах. Если Lean – это общая философия, общий фреймворк мышления, то дальше мы идём по конкретным практикам, техникам.

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

• Ключевые процессы – это те процессы, которые доставляют непосредственную ценность заказчикам нашего заказчика. Допустим, у нас есть заказчик, у него есть какой-то бизнес, он что-то продает, и все, что стоит на потоке создания этой ценности, – это основные процессы.
• Вспомогательные процессы – это, например, бухгалтерия. Если только ваш заказчик не занимается бухгалтерским аутсорсингом, потому что тогда это будет основной процесс. В зависимости от бизнеса заказчика вы всегда можете проанализировать, что относится к основным и к вспомогательным процессам.

Главная особенность заключается в том, что:

• если мы говорим об основных процессах, то количество транзакций относительно велико, но вариативность транзакций низкая. Другими словами, у нас есть основной бизнес, есть конкретные виды операций (конкретные варианты их исполнения) – количество вариантов ограничено, но зато количество самих операций очень большое.
• если говорим про вспомогательные процессы, ситуация обратная – вариантов операций много, но количество операций мало.

Пример, который я часто привожу, – это блок основных средств. Изменение основных средств, как правило, происходит редко, но вариантов их изменения много (расконсервация, разделение основных средств, ремонт основных средств, хозяйственный способ, подрядный способ и т.д.).

 

Scrum

 

 

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

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

 

Дорожная карта

 

 

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

На слайде показана дорожная карта реального проекта, который мы сделали. Проект занял три месяца. Где-то в середине четвертого спринта (за полтора месяца до начала квартала), старая система была закрыта для ввода данных в новые периоды – понятное дело, что в старых периодах бухгалтерия обычно закрывается еще долго.

Это был поэтапный запуск.

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

Обратите внимание: левая часть – это основные процессы, а правая часть – вспомогательные. Почему мы так делаем? Чтобы сократить риски проекта.

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

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

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

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

 

Ручное тестирование против автоматизированного тестирования

 

 

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

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

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

 

 

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

Покрывать все процессы, особенно типовую функциональность, нет смысла – но, конечно, можно и нужно покрывать ключевые процессы, чтобы быть уверенным, что бизнес заказчика не встанет. Тем более что это дешевле, чем ручное тестирование.

 

Технические задания и инструкции

 

 

Мы достаточно давно прекратили практику написания технических заданий и инструкций.

• техническое здание мы пишем немного в другом формате – больше в формате User Story;
• а инструкции, если честно, практически вымерший формат, потому что если мы говорим про вспомогательные процессы, то вариативность большая, и описывать все варианты исполнения данной операции сложно и долго. Скорее, вы будете описывать медленнее, чем будет изменяться типовое решение.

 

 

Нет никакого смысла писать инструкции – есть портал ИТС, на который бухгалтер войдет и посмотрит, что нужно делать.

 

 

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

С кладовщиками такая фишка не прокатит. Кладовщики, мастера цехов – это не те сотрудники, которые должны и будут сидеть на портале ИТС. Учетные сотрудники – бухгалтерия, финансисты, экономисты – это те, кто воспримут этот формат, и вам будет от них польза.

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

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

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

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

Понятно, что с первого раза это не сработает, со второго и с третьего тоже, может быть, не сработает. Но с 21-го раза пользователь поймет, что ему все равно придется на этот сайт идти вбивать запрос и прекратит звонить в поддержку. Это сэкономит очень много времени.

 

 

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

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

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

 

 

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

 

Решение проблемы запутанных обменов

 

 

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

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

Если мы используем современные подходы, эволюционную архитектуру, то мы делаем несколько вещей:

• мы обеспечиваем себе беспроблемный запуск систем;
• мы делаем полезную вещь для заказчика – мы уйдем, а подход к построению архитектуры у заказчика останется, у него останутся инструменты, с которыми он сможет интегрировать не только УПП и ERP, а ERP сайт, ERP и CRM-систему, еще что-то. У него останутся сотрудники, которые умеют работать с данными продуктами.

 

 

Обычно, когда 1С-ник начинает настраивать обмен, то даже если ему кто-то предложит обмениваться через брокер сообщений, он ответит: «Зачем? Есть же планы обмена, и вообще можно через папку обмениваться». Потом договариваются, что лучше не через папку, а через веб-сервис. А дальше – типовые проблемы онлайн-обменов и так далее. Все это понятно, и, кажется, что в мире 1С другого решения нет. Или, во всяком случае, не было.

Сейчас решение есть – это БИТ.АДАПТЕР.

Если вам не нравится название «бит» или «адаптер», вы можете сделать все то же самое самостоятельно: мы выложили компоненту для интеграции с Rabbit MQ в открытый доступ, на гитхаб. Мы рекомендуем БИТ.АДАПТЕР, потому что мы сами его используем. Изначально мы сделали его для собственных нужд, но вы можете сделать все то же самое самостоятельно, используя бесплатную компоненту с открытым исходным кодом на С++. Кстати, она на Инфостарте тоже выложена.

 

Инструменты для управления проектом

 

 

С точки зрения управления, конечно же, то, что уже обсуждалось:

•  это Jira – причем, она используется для поддержки уже запущенных блоков;
•  и это Канбан доска.

 

 

Несмотря ни на что, мы используем классический Scrum:

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

Для поддержки мы используем доски Канбан с установкой WIP лимитов – на рынке есть куча инструментов, которые позволят это делать эффективно. В нашем случае это линейка продуктов от Atlassian – она интегрирована (мы используем Confluence и Bitbucket), поэтому нам удобно. Вы можете использовать что-то еще, но важно запомнить, что Канбан – это действительно хорошая рекомендация.

 

Решение организационных проблем

 

 

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

 

 

Когда мы встречаем ошибку в типовой конфигурации, почему-то вызывает откровение, что первое, что нужно сделать, – это зайти на сайт v8.1c.ru и посмотреть, что на этот счет пишут. Там же есть партнерский форум, где тоже имеет смысл посмотреть.

Сейчас у нас на этот счет даже есть правило: если консультант, разработчик или внедренец решают исправить типовую конфигурацию, они обязаны зарегистрировать ошибку через линию поддержки. И так как у нас все через Канбан, через Jira, через Scrum-доску, то задача не принимается в разработку до тех пор, пока там не появится ссылка на зарегистрированный и присвоенный номер ошибки с ответом разработчиков 1С по этому поводу.

Почему это важно?

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

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

 

Решение проблемы непонятной терминологии – обучение пользователей и механизм хозяйственных операций

 

 

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

У нас на этот счет тоже есть требование: перед запуском проекта мы требуем от заказчика, чтобы все ключевые пользователи прошли рекомендованные нами курсы – обычно это дистанционные курсы Учебного центра № 3, но вы в принципе можете рекомендовать все, что угодно, в том числе курсы своей компании.

Важно, чтобы все ключевые пользователи более-менее понимали то, что вы говорите. А для этого нужно, чтобы у них было представление о системе, которая будет внедряться. Поэтому не пожалейте 3-4  тысячи рублей на сотрудника (именно такова стоимость интерактивного курса) – это реально сэкономит кучу времени, сил и денег.

 

 

Следующий лайфхак – используйте механизм хозяйственных операций 1С: ERP.

В 1С:ERP есть документы, и можно говорить о том, что есть «Поступление» и есть «Приобретение». Но вы устанете объяснять пользователям, в чем разница. Особенно, если они привыкли к УПП, и там был один документ. На данном этапе это ни к чему. Когда вы обсуждаете с пользователем хозяйственные операции, используйте терминологию хозяйственных операций. Вытащить хозяйственные операции и сгруппировать внутри них документы, которые используют данную хозяйственную операцию, можно элементарным отчетом, который делается за 15 минут.

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

 

Коммуникации

 

 

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

 

 

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

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

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

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

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

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

 

Эффективное взаимодействие

 

 

Мы используем Slack и активно рекомендуем использовать подобный мессенджер.

 

 

Более того, наши заказчики имеют доступ в наш Slack, имеют доступ к определенным каналам, и общение структурировано – оно теперь происходит не в почте, а в конкретных каналах, всегда можно посмотреть, что происходит.

 

Просмотр истории хранилища

 

 

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

 

 

Если вы будете выгружать изменения в Git, то у вас реально проблем не будет.

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

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

 

Анализ качества кода

 

 

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

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

 

 

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

 

Что в итоге получил заказчик

 

 

Я завершаю свой рассказ результатом, который получил заказчик.

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

 

 

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

• Он получил оптимизацию всех базовых процессов, потому что УПП была внедрена больше 10 лет назад, на большинство вопросов, которые мы задавали, ответ был «так сложилось исторически».
• А поскольку мы внедряем типовую ERP, то не можем действовать «как исторически сложилось», мы можем действовать так, как в типовой ERP. Поэтому неизбежно базовые процессы, вопреки желанию конкретных сотрудников, функциональных руководителей заказчика, были оптимизированы. Много дурных вещей было просто убрано, потому что заказчик не смог объяснить, почему это делается, кроме аргументации «у нас так принято». Почему еще убирали более-менее свободно? Потому что ERP предлагает некие хорошие практики для каждого процесса и варианты реализации этих процессов. И если у тебя есть опыт автоматизации типовой ERP, то в принципе ты достаточно уверен в своих решениях. И, кроме того, у нас нет глобальных ошибок, мы можем ошибаться, и ошибаемся, но не фатально, потому что у нас короткие итерации. Мы быстро откатываемся назад, учимся на своих ошибках и с учетом вновь полученной информации действуем дальше.
• Это все преимущества последней версии ERP-системы. Обслуживать ее гораздо дешевле, чем жутко кастомизированную УПП, и, тем более, ERP.
• Что касается сроков, все было сделано за 3 месяца. Некоторые наши коллеги успевают за это время обследование провести, в лучшем случае начать проектирование. За тот же самый срок заказчик получил не отчет об обследовании и даже не ТЗ на систему, он получил работающую систему, которая работала. И даже не через 3 месяца, а раньше, поскольку она запускалась блоками, и первый блок был запущен на 2 неделе от начала работ.

У меня все. Спасибо.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.