Long long way: почему проект по автоматизации может длиться несколько месяцев

Автоматизация в компании – как правило, растянутый во времени процесс. И это одна из причин, почему некоторые предприниматели оттягивают внедрение нового IT-решения. Все опасаются того, что работать в нормальном режиме во время реализации проекта по автоматизации не получится. О том, почему внедрение сложных IT-программ может растягиваться на месяцы и как придать ускорение этому процессу, порталу Biz360.ru рассказал Алексей Бояршинов, руководитель компании «Корада».

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

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

Дальше от заказчика поступает примерно такой пул вопросов. Почему так долго? Мы же не собираемся разрабатывать программный продукт «с нуля». Мы же оплачиваем готовую систему. Вы её привозите, устанавливаете, настраиваете, обучаете наших специалистов, делаете какие-то доработки, которые нам понадобятся. Но почему так долго получается? Что там делать год? 

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

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

• Обследование бизнеса заказчика.

• Моделирование бизнес-процессов.

• Реализация.

• Обучение-запуск.

• Опытная эксплуатация. 

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

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

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

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

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

Мы просим руководителя проекта заказчика участвовать во всех интервью. Просим об этом же представителей руководства. Во время интервью мы «вытаскиваем» из коллективного бессознательного, как работает компания. Мы получаем интересную информацию, с которой руководство компании может сразу что-то сделать. Возможно, принять какие-то управленческие решения. У топ-менеджмента появляется реальная картина того, как на самом деле работают на своих участках сотрудники компании. Это очень интересно и полезно. Упускать такую пользу нет смысла, раз уж всё равно эти интервью проводятся. 

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

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

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

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

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

Мы в «Кораде» отдаём эту информацию в виде документа. В нём – всё то, о чём мы говорили во время интервью, и это те процессы, которые мы выявили благодаря сотрудникам заказчика. Заказчику надо прочитать весь документ и подтвердить, что всё так и есть. Другой вариант – прочитать и дать правки. 

Речь идёт про 100-страничный или 150-страничный документ. Да, это не 100 страниц сплошного текста, там много иллюстраций, схем, таблиц. Но, тем не менее, надо прочитать, осознать, понять, подумать. Иногда нужно ещё собраться внутри компании и всё обсудить. Бывает так, что мнения разных отделов расходятся: например, один и тот же процесс в том виде, в котором он будет автоматизирован, они видят иначе. 

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

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

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

Подрядчик берёт процессы, которые нарисованы им в документе и согласованы с заказчиком, и проходит их в выбранном типовом IT-решении. Само собой разумеется, что решение выбирается сторонами совместно, с учётом бизнес-задач и особенностей компании. 

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

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

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

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

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

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

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

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

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

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

Исполнитель на этом этапе может ждать какие-то данные от клиента. Например, у компании будут обмены с другими системами, например с новым сайтом. А сам новый сайт ещё не готов. Значит разработчики со стороны подрядчика, который внедряет 1С, не могут сделать под форматы сайта какие-нибудь выгрузки и загрузки. Всё это тоже задерживает этап реализации. Он вместо двух-трёх месяцев спокойно может занять полгода и даже больше. 

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

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

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

Здесь только управленческая воля может придать ускорение этапу и не дать саботажу растянуть его, уйти на бесконечные круги обучения. Руководитель компании должен принять решение в духе – «Всё, мы запускаемся с первого сентября, и никак иначе. Начинаем работать с тем, что есть». Если собственник сможет это сделать, запуск произойдёт. 

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

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

Это уже не так страшно, потому что система работает, но хочется закончить и поставить в проекте точку. 

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

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

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

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

Если вам удобнее воспринимать информацию в формате видео, то в этом ролике Алексей Бояршинов подробно рассказывает о том, от чего зависит срок реализации проекта по автоматизации:

biz360