9 ½ недель на автоматизацию. Когда клиент хочет быстро

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

Руководство компании Инфолио изучило нас, подходы в работе, взаимодействие с клиентами, четкие и понятные инструкции. Все это было близко клиенту, поэтому он выбрал нас для сотрудничества.

В Инфолио использовался программный продукт «1С: Управление торговлей 10». Недостатки продукта:

• Система старая;

• В системе выполнены значительные доработки в части механизмов расчета;

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

Были сформулированы цели внедрения новой информационной системы 1С:

1. Старая система портила аналитику. Например, если у товара были другие характеристики, в системе заводилась новая карточка номенклатуры. Таким образом в системе появлялось несколько карточек одной и той же номенклатуры. Аналитику по товару производить было сложно. Для этого делалась выгрузка в excel и уже там производились операции для анализа товаров.

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

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

Старт проекта состоялся 1 сентября 2022 года. 

С кем может получиться, а с кем - нет

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

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

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

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

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

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

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

Новые инструменты в технологии управления проектами

• Обследование – 2 месяца;

• Моделирование – 2 месяца;

• Реализация – 3 месяца;

• Обучение и инструкции – 1 месяц;

• Запуск и опытная эксплуатация – 1 месяц.

В описываемом проекте было сделано:

• Обследование – 2 месяца. Да, да, обследование заняло половину проекта. На этом этапе целью было посмотреть, как будет идти приемка, убедиться в скорости принятия решений. Из всех классических этапов нужно было выделить один фундаментальный этап, который бы описывал целостную картину компании заказчика. Это могло быть или Обследование, или Моделирование. Мы решили, что это будет Обследование. Подробное изучение бизнес-процессов в Обследовании позволило на лету подбирать модели реализации. Ровно в срок документы Обследование и Концепция были готовы. По итогам Обследования стало понятно, что заказчик может и хочет достичь поставленной цели проекта. В ходе выполнения этапа мы придумывали, в каких этапах можно сократить срок. Было принято решение объединить Моделирование и Реализацию.

• Моделирование и Реализация – 1,5 месяца. Почему это стало возможно? В нашей классической технологии Моделирование включает типовые модели плюс функциональные требования на доработки, а после согласования – выполнение доработок. Мы поняли, что описание – это самое долгое в этом этапе. Поэтому мы презентовали руководству Инфолио новую технологию и решили: мы ничего не пишем. Мы не писали функциональные требования, что очень опасно для обычных проектов. Мы не писали документ Модель. Мы писали только редкие и сложные документы - функциональные требования, которые были нужны заказчику, чтобы подумать и принять решение. Таких документов было не более шести. Это были «фундаментальные» для этого проекта доработки: возвраты, номенклатура партнеров и т.п. Так как решения нужно было принимать быстро и не хватало времени на переписку, в которой бы описывались варианты ответов, возникла идея проводить встречи ежедневно. Утром до начала рабочего дня проводились статус-встречи продолжительностью 30 минут. Это позволило вчерашние вопросы, которые возникли у команды разобрать с заказчиком.

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

• Для данного подхода пришлось изменить стандартный способ оценки и оплаты: сначала описываются, оцениваются работы, затем оценка фиксируется и составляется смета, после которой начинается реализация. В этом случае после выполнения доработки и принятия ее заказчиком, доработка попадала в счет. Счет выставлялся один раз в неделю или один раз в месяц, в зависимости от того как быстро набирались работы для выставления счета. По договоренности, было установлено определенное количество часов, до которого не нужно было согласование оценки. Например, если реализация задачи попала в первый приоритет и его согласовали, значит мы ее просто делаем. Это вписывалось в подход Time & Material, при котором клиент оплачивает часы занятых на проекте специалистов. Фиксированная оценка была произведена только для встреч по Модели и встреч по доработкам.

• Обучение заняло 2 недели вместо 1 месяца. Девиз этого этапа - «Никаких инструкций!». Обучение происходило с записью видео. Сначала теория под запись видео, затем запись останавливалась, пользователи задавали вопросы. После этого запись возобновлялась. Это было сделано для того, чтобы каждый пользователь мог вернуться и повторно прослушать запись. Памятки были написаны только по тем блокам, где ранее не было автоматизации (блоки Склад и Производство). Обучение шло 2 раза в день. Параллельно шло два разных обучения двумя разными людьми: руководителем проекта и аналитиком. Это позволило сократить время обучения и обучить всех пользователей, всех видов и всех функций. Конечно же мы отложили пересчет и инвентаризацию, бухгалтерское закрытие месяца, так как понимали, что они точно не понадобятся к моменту запуска.

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

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

Процесс

Встречи по проекту на этапе Обследование проходили ежедневно по 2 часа.

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

На этапе Моделирование + Реализация мы продолжили практику ежедневных двухчасовых встреч. Рабочая группа была расширена, в нее включили руководителя отдела закупок, логиста, руководителя отдела продаж, представителя отдела продаж, главного бухгалтера. Эти люди могли пояснить процессы и смотреть на свои модели работы. Решения по-прежнему принимали 3 человека.

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

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

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

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

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

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

Запуск и эксплуатация: как все не смазать

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

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

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

В ходе проекта много раз возникали спорные ситуации – делать какой-то функционал или подождать формального согласования? Переделывать то, что ранее было сделано и согласовано, или настаивать на своем? Ограничивать число выездов обычным объемом, или ездить до тех пор, пока не будет достаточно? Мы постоянно принимали решения в пользу проекта и быстрого и успешного запуска.

Заказчик в январе в период каникул выходил готовить данные вместе с нами. Несмотря на то, что данные приходилось собирать из старой 1С, из excel-файлов, данные были подготовлены вовремя. Это стало еще одним доказательством общей заинтересованности в результате.

Запуск состоялся, как и планировалось - 9 января. Мы продолжали утренние встречи и ведение реестра требований параллельно с запуском. Для ответов на вопросы, возникающие у пользователей, были подключены дополнительно еще два аналитика и еще один разработчик.

В первые две недели запуска пришлось переделать несколько моделей, с которыми мы «не угадали». Также были и задачи, которые не были выбраны в приоритет, а они оказалась «жизненно важными». Разработчики работали в полную силу. Адаптация системы продолжалась еще 1 месяц после запуска.

Заказчик не должен был при запуске почувствовать снижения скорости принятия решений. Через 2 недели после начала запуска вопросы, как и ожидалось, уменьшились. Разработчик продолжал делать доработки из реестра требований в период запуска.Опытная эксплуатация была закончена 15 февраля.

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

Мы получили прекрасный отзыв на свою работу и рады, что в очередной раз принесли пользу.