Как выбрать - какая технология лучше подойдет?
В преддверии мастер-класса по 1С:ТКЛ на Инфостарте, который планируется на следующей неделе, продолжаю публиковать материалы по технологиям от 1С.
На мой взгляд, у вас есть два основных варианта:
Делать проект по Agile - по 1С:ТБР (технология быстрого результата). Этот подход хорош, если:
- Можно разделить проект на несколько независимых модулей, и выдавать каждый в продакшн не реже, чем раз в месяц. Важный момент - что каждый из модулей должен иметь для Заказчика независимую ценность, и работы по проекту можно остановить в любой момент.
- Требования размыты и уточняются по ходу проекта.
- Есть рабочая команда из представителей Заказчика и Исполнителя, где вопросы решаются в рабочем порядке (а не в режиме “мы сейчас отправим этот запрос на изменение на согласование со всеми представителями руководства”)
Делать проект по классическим/гибридным методам - 1С:ТКЛ (технология корпоративного внедрения - ЛАЙТ). Для какой ситуации подходит:
Разделить систему на небольшие независимые модули не получится - в любом случае, система будет запускаться в работу целиком (в лучшем случае - в несколько очередей)- Даже если делить этого слона на кусочки, Заказчик не готов к внедрению системы по частям: им удобнее пока работать в старой системе, а потом единомоментно запустить ОПЭ и перейти на новую. Возможно разделение системы на несколько очередей, но эти блоки будут довольно большими.
- Руководство Заказчика привыкло работать в парадигме “сначала делаем ТЗ и понимаем общий бюджет”.
- Есть запрос (у Заказчика, у руководства Исполнители, по регламентам компании и т. п.) на документирование всех этапов: фиксация бизнес-требований на старте, подписание актов по итогам каждого этапа и т. п.
Разбираем кейс: проект внедрения CRM-системы. После того, как мы помогли заказчику перейти с 1С:УПП на 1С:ERP, возникла задача встроить CRM-систему в ERP-систему. Было принято решение внедрять 1С:CRM. Как будет выглядеть работа по каждой из технологий?
Работа по 1С:ТКЛ - привычнее и понятнее:
- Практически всегда Заказчику важно понимать общий объем проекта и (хотя бы примерно) бюджет. История, что “сначала ТЗ, потом разработка, потом внедрение” - более привычная и простая.
- Не всегда есть возможность внедрять продукт по кусочкам - это могут не позволять бизнес-процессы компании и архитектура решения. В нашей практике были случаи, когда пользователи были категорически против небольших релизов - “нам надоело каждый месяц переучиваться - давайте вы подготовите все изменения сразу, и тогда уже перейдем на новую систему”.
- Набор документов, предлагаемый 1С:ТКЛ отлично подходит, чтобы, с одной стороны, согласовать ожидания с Заказчиком на старте, с другой стороны, четко фиксировать всё происходящее, а с третьей “успокоить” его в процессе, показывая ход работы.
- Процесс работы над проектом предельно четкий и понятный (обратите внимание - сами названия фаз подчеркивают, что мы не разрабатываем принципиально новый функционал, а просто дорабатываем типовой).
Работа по 1С:ТБР - едим слона по кусочкам:
Здесь мы не пытаемся “допилить” продукт целиком, прежде чем выпускать на опытно-промышленную эксплуатацию. А выпускаем в реальную работу сразу по кусочкам: описание доработок, доработка функционала, подготовка к ОПЭ и проведение ОПЭ - делаются сначала по одному модулю, потом по следующему и т. п. Примерно вот так:
То есть в нашем случае, данный проект может выглядеть следующим образом:
Внедрение по 1С:ТБР подойдет для нашего проекта в случае, если:
- Заказчику “надо было вчера”, и он готов запустить CRM-систему по частям - главное, чтобы самый критичный функционал заработал в ближайшее время.
- Сама система и организация рабочего процесса позволяет начать работать в не до конца готовой системе (возможно, придется делать промежуточные интеграции, но в любом случае - результат будет рабочим)
- На старте требования понятны только приблизительно, и планируется все пожелания уточнять “по ходу” - когда первые модули внедрены - понятнее, что делать со следующими.
- Между Заказчиком и Исполнителем отношения неформальные и доверительные - изменения принимаются и согласуются в рабочем порядке. Не возникает подозрений, что Исполнитель специально затягивает работы, опасений, что Заказчик будет подавать на Исполнителя в суд за несоответствие первоначальному ТЗ и т. п.
- У представителей Заказчика высокая мотивация на достижение результата, и они готовы активно включаться в работу проектной команды и оперативно принимать необходимые решения.
Особенности документов, которые предстоит использовать в случае работы по разным технологиям:
1С:ТКЛ - Лёгкая
Устав проекта - основной документ, который расписывает, каковы цели проекта, основные требования, как будет организована работа, каковы этапы проекта, допущения и ограничения и т. п.
Договор - при работе по “классическому подходу” важно, чтобы у Заказчика была уверенность, что он в конце получит имеющий ценность результат, и Исполнитель отвечает за него. Это и должно быть прописано в договоре. Сами себе договоры могут быть и в формате “FixPrice” и в формате “Время и материалы” (для второго варианта нужно несколько больше взаимопонимания и доверия, но в конечном итоге он может оказаться более выгодным для Заказчика)
По нашему опыту, ключевые документы в ходе проекта:
- Реестр заинтересованных сторон (внутренний документ команды, где важно не просто перечислить стейкхолдеров, а сразу продумать план коммуникации и план вовлечения)
- Реестр рисков (очень важно заполнять его не формально “для галочки”, а в привязке к контексту проекта
- Отчет об обследовании (кстати, в ТБР подобный документ называется более скромно - отчет об экспресс-обследовании).
- Протоколы (ПСИ, загрузки НСИ, готовности к ОПЭ, о начале ОПЭ и т. п.)
- ЛУРВы, статус-отчеты, различные журналы - актуальны при работе по любой технологии.
1С:ТБР - Гибкая
🔹 Соглашение о проекте - лаконичный документ, где (кроме целей, организации работы и т. п.) в общих чертах описывается содержание релизов (детали по релизам могут быть определены уже после старта проекта)
🔹 Договора - ключевое условие работы по ТБР - сдача и актирование работ по каждому модулю. Скорее всего, для этого будет заключаться рамочный договор на всё внедрение и доп. соглашения по каждому модулю.
🔹 Проектные документы - важно, чтобы проектные документы закрывали основные вопросы и помогали выстроить работу даже в сложном окружении.
🔹 На этапах внедрения - комплект промежуточных проектных документов должен быть минимальным.
🔹 Отдельно хочу упомянуть в первую очередь ЛУРВ (листы учета рабочего времени), статус-отчеты и журналы по регистрации вопросов/дефектов/запросов на изменения. Эти документы очень важны для уверенной и предсказуемой работы команды.
🔹 Перед закрытием проекта важно подготовить отчет по завершению. Отдельный важный момент - это отдельная презентация для внутреннего совещания по завершению проекта. Это очень важный момент, необходимый, чтобы в полной мере учиться на своих ошибках - зафиксировать “для своих” косяки и извлеченные уроки. Не все из которых касаются Заказчика…
🔹 Для завершения проекта - предлагается использовать готовый чеклист - что необходимо проверить перед завершением проекта? Не забудьте подготовить такой чеклист заранее (а не в формате “пока гром не грянет - мужик не перекрестится”)
Вам, наверное, интересно, какая технология лучше всего подошла в описанном кейсе?
В принципе, можно было бы использовать любую. Но самым выигрышным оказался гибридный вариант: между гибким и “классическим”:
С одной стороны, хотелось запустить систему как можно скорее, хотя бы частично - старая CRM-система (SalesForce) уже была отключена, а работать надо.
С другой, при этом Заказчику важно было четко иметь общую картинку уже на старте, а потом проходить все фазы проекта. Ну и согласовывать результаты по итогам уточнения требований, моделирования отдельной процедурой, а не “в рабочем порядке”. и т. п. Так что ответом стала - “легкая технология” 1С:ТКЛ с разделением внедрения на три “очереди”, и прохождения всех фаз внутри каждой очереди. При этом хочется избежать излишней бюрократизации и подписания кучи бумажек (не всегда нужных и полезных в данном конкретном случае). Для этого в каждой очереди 7 фаз 1С:ТКЛ “склеиваются” в несколько этапов, и акты подписываются уже по итогам каждого этапа:
P.S. В этой статье мы оставили за кадром несколько вариантов:
У вас не средний, а большой (или просто сложный - какой-то функционал нужно фактически пилить “с нуля”) проект внедрения. Тогда вам скорее подойдет 1С:ТКВ (технология корпоративного внедрения)- У вас простой проект - по сути, внедрение “коробочного” решения, практически без доработок. Тогда, если вам нужна технология - вы можете ограничиться 1С:ТСВ (технологией стандартного внедрения) - где всё просто.
P.P.S. Если вам интересно подробнее разобраться в технологии 1С - приходите на мастер-класс Марии Темчиной про применение 1С:ТКЛ на практике.
