Применимость Scrum для создания небольшого приложения, как правило, не вызывает вопросов. Но проект внедрения 1С:ERP на 700 рабочих мест в крупном холдинге с использованием этого фреймворка выглядит нетривиальной задачей. Ниже мы расскажем от том, как начинать проект по Scrum на примере автоматизации холдинга ТДЛ Текстиль.
Подписывайтесь на наш телеграмм канал https://t.me/bit_erp там вы найдете актуальные новости, анонсы, опыт и истории от команды БИТ:ERP.
Подробности о результатах проекта можно прочитать в статье "Компания "ТДЛ Текстиль" автоматизировала учет на базе "1С:ERP" на сайте 1С:Проект года.
Любой проект у нас начинается с определения ценности его результата для бизнеса Заказчика. Ценности, сформулированные инвесторами и ключевыми стейкхолдерами, мы фиксируем в реестре заинтересованных сторон. Далее на каждом планировании спринта его цели будут соотносится с этими ценностями.
После определения ценности поставляемого продукта его содержание разбивается на функциональные блоки, порядок запуска которых определяется по поставляемой ценности. На описываемом проекте функциональные блоки детализировались до хозяйственных операций с принципами приоритезации по ценности и по массовости операций.
Запуск осуществляется спринтами длительностью 2 недели каждый. Цель каждого спринта – поставить небольшую ценность, которую можно сразу использовать. Как правило, запустить за спринт целый блок невозможно. Поэтому на каждом спринте выделялась операция, которую пользователи по итогам спринта могли оформлять в рабочей базе. Например, по блоку закупок сначала запускали user story по закупкам у российских поставщиков, потом импорт, затем закупки по схеме товаров в пути и так далее. При этом запуск каждой следующей операции блока происходил быстрее и легче, так как у нас уже была обратная связь и устраненные замечания по аналогичным операциям.
С подходами к формированию и управлению user stories много экспериментировали. Пробовали использовать карты памяти и различные инструменты формирования схем. Самым удобным инструментом, который мы опробовали в конце проекта – оказался FeatureMap.
Итеративный подход предполагает, что обязательно будут изменения в уже запущенных блоках. Например, после запуска блока продаж и казначейства, оказалось, что нужно распределять выручку по направлениям деятельности в момент продажи. Тогда как в запущенной реализации распределение выручки по направлениям деятельности происходило постфактум. Сложности добавило ограничение типовой ERP: один документ продажи – одно направление деятельности. Новое требование также реализовали итеративно:
1 итерация. Создали документы контейнеры по заказу клиенту, реализации товаров и услуг, возврату товаров от клиента. Тут с первого раза не взлетели. Нужно было еще организовать структуру по договорам с контрагентами, когда один юридический договор соответствовал нескольким направлениям деятельности. По обратной связи стало понятно, что нужно развивать заполнение заказов клиентов. Однако после этой итерации уже получили результат, который можно демонстрировать заказчику. Дополнительно наткнулись на еще одно ограничение типовой – учет розничных продаж ведется без учета по направлениям деятельности.
2 итерация. Обеспечили распределение оплат от клиентов по направлениям деятельности. Сначала закрыли потребность в распределении постоплаты, так как это основной объем операций. Далее решили вопросы с отнесением аванса на направление деятельности и затем сделали обработку, которая сворачивала развернутое сальдо по взаиморасчётам в рамках одного договора по разным направлениям деятельности.
3 итерация. Вернулись в заказ клиента и добавили механизмы для автоматического заполнения направления деятельности по номенклатуре и добавили контроли.
4 итерация. Расшили решение по нескольким направлениям деятельности для розничных продаж и комиссионных отгрузок. Выстроенный и стабилизированный процесс по основным операциям позволил быстро реализовать доработки для частных случаев.
Результаты проекта показывают, что реализация крупного 1С-проекта может быть с самого начала осуществлена с использованием фреймворка Scrum. При этом итеративный запуск функциональных блоков – это единственный способ 100% гарантии работоспособности системы.
* Пример носит иллюстративный характер и не содержит какую-либо информацию о ТДЛ Текстиль.
Материал подготовила:
Ксения Короткова, Product Owner, БИТ:ERP.