В статье представлен кейс параллельного внедрения двух команд – внутренней команды заказчика и нашей команды-интегратора. Рассмотрим, как выстроить эффективный тандем между ними и наладить совместную работу.
Сначала кратко расскажу о нашей компании и о клиенте. Затем перейдем к основным целям проекта, которые ставились заказчиком. Отдельно коснемся технологии, применявшейся в ходе реализации. Технология классическая, но важно подчеркнуть ее значимость.
После этого перейдем к сути – одному из ключевых вопросов, с которыми сталкиваются подобные проекты: как разделить зоны ответственности между двумя командами, чтобы не мешать друг другу, не дублировать работу и не создавать хаос в коммуникации. Этому вопросу уделим особое внимание.
Разберем схемы взаимодействия в рамках бизнес-процессов, разделим участников на две группы – аналитиков и разработчиков, посмотрим, в каких точках они пересекаются на разных этапах проекта и как именно взаимодействуют в этих точках.
В конце подведем итоги и обсудим сложности, с которыми мы столкнулись в ходе проекта. Уверен, с подобными трудностями придется столкнуться и тем, кто будет реализовывать проекты по аналогичному сценарию.
О нашей компании и о клиенте
Мы работаем на рынке более 10 лет, специализируемся на проектах ERP, УХ и ERP+УХ. Наши клиенты – производственные компании. В штате есть все необходимые специалисты: руководители проектов, архитекторы и другие эксперты.
Наш клиент – один из лидеров российского рынка микроэлектроники. Это крупная, динамично развивающаяся и растущая организация – активный и заинтересованный партнер, с которым приятно работать.
Цели проекта со стороны заказчика
Какие цели ставил клиент перед нами в рамках проекта? Прежде всего – переход с исторической системы. В данном случае это была Управление торговлей 10, которую клиент собственными силами дорабатывал почти 20 лет, прежде чем принять решение перейти на более современное решение.
После этого команда заказчика – достаточно крупная, как вы позже увидите – в течение пяти лет продолжала развивать систему, добавляя и улучшая отдельные блоки. Когда стало ясно, что динамика не та и необходимо ускорять процессы, мы начали сотрудничество.
Среди целей проекта – автоматизация управленческой отчетности. На тот момент в компании уже действовала внутренняя KPI-система и собственная BI-система на веб-платформе. Ее трижды переписывали с нуля, и в итоге заказчик пришел к выводу, что стоит перейти на платформенные решения. В рамках проекта было решено внедрить 1С:Аналитику.
Кроме того, в компании хорошо развито проектное управление. Было принято решение упорядочить работу менеджеров проектов, стандартизировать процессы и перенести управление в платформенное решение на базе 1С:ERP+PM – это тоже вошло в наш контур.
И, конечно, важной задачей проекта стало развитие функционала экономики – автоматизация бюджетирования и расчета себестоимости в рамках единой системы.
Особенности проекта и внутренней команды заказчика
Первая и основная особенность – мы вошли в проект уже в действующую систему. На тот момент были запущены блоки казначейства, производства, закупок и складов. Этим занималась внутренняя команда заказчика – отдел бизнес-процессов (ОБП). Это примерно 20 человек, в составе которых есть собственные аналитики и разработчики. Именно они отвечали за развитие функционала внутренней ERP-системы.
Компания насчитывает около 1500 сотрудников и занимается производством микроэлектроники. При этом у нее два направления деятельности:
-
оптовая торговля со склада,
-
производство и реализация проектно-компонуемого оборудования, включая крупные проекты сроком от года до пяти лет.
Еще одна важная особенность – компания быстро развивается, из-за чего структура стала сложной и многослойной. Появилось много обособленных департаментов, между которыми выстроена сложная схема внутренних взаиморасчетов. Работа с ней доставила немало трудностей, особенно учитывая, что схема постоянно менялась в ходе проекта.
Подход к внедрению: Поэтапный запуск вместо «большого старта»
Кроме того, в этом проекте мы использовали не совсем классический подход к внедрению. Обычно переход на новую систему происходит «с Нового года» – с переносом остатков и запуском всех процессов одновременно.
Здесь мы пошли другим путем и выбрали поэтапный запуск. В процессе работы стало ясно, что некоторые департаменты развиваются особенно быстро и начинают захлебываться в документообороте. Наша задача состояла в том, чтобы как можно быстрее перевести их работу в ERP-систему.
Мы выстроили очередь внедрения по приоритету, начиная с наиболее нагруженных подразделений. Этот подход оказался эффективным – кейс можно рассматривать как отдельный пример успешного поэтапного внедрения. Все департаменты в итоге были запущены в ERP.
Используемая методология: Классический водопад
Технология использовалась классическая – «водопад». Сначала проводилось предпроектное обследование, на котором собирались бизнес-требования, служащие основой для дальнейшей декомпозиции в рамках всего проекта.
На этом этапе формировалось ТКП, после чего заключался контракт и начиналось полноценное обследование. Здесь подключались все участники команды и линейные руководители. Мы детализировали бизнес-цели, декомпозировали бизнес-процессы, готовили техническое задание на моделирование и переходили к следующему этапу.
Этап моделирования понятен большинству специалистов: на нем декомпозированные бизнес-процессы перекладываются на функционал системы. Мы демонстрируем заказчику последовательные фрагменты будущей работы системы до тех пор, пока он не подтвердит, что все соответствует ожиданиям.
Результатом становятся подписанные заказчиком функциональные модели и реестры критических доработок, необходимых для полноценной работы системы. После этого начинается этап внедрения – адаптация, выполнение доработок, тестирование, обучение пользователей, перенос остатков и переход в промышленную эксплуатацию.
Разделение зон ответственности: Поэтапное уточнение
Перейдем к ключевому вопросу – как разделить зоны ответственности в рамках такого проекта. Задача несложная, но крайне важно начать ее решать как можно раньше – уже на этапе предпроектного обследования.
Когда собираются базовые требования, клиент определяет, над какими блоками работает внутренняя команда, а какие передаются нам. На этом этапе появляются первые крупные контуры ответственности: например, управление договорами, продажи и закупки – с нашей стороны, а производство и склады – за внутренней командой.
Далее следует этап обследования, на котором выполняется детальная декомпозиция бизнес-процессов. Мы разбиваем каждый блок на элементы, строим схемы и уже на этом уровне можем четко увидеть границы между командами. Визуально выделяем, какие процессы относятся к нашей зоне ответственности, а какие – к внутренней команде заказчика.
Следующий этап – моделирование. Здесь бизнес-процессы и схемы перекладываются на конкретные цепочки документов в системе. Именно на этом этапе происходит окончательное разграничение: вплоть до уровня документов фиксируется, какой документ относится к нашей зоне, а какой – к внутренней команде.
Таким образом мы добились максимально четкого, «ювелирного» разделения зон ответственности. В результате удалось избежать типичных проблем – дублирования, перекладывания задач и спорных ситуаций. Этот подход показал себя эффективным и может служить рабочим кейсом для аналогичных проектов.
Точки соприкосновения команд на разных этапах проекта
Рассмотрим подробнее точки соприкосновения и взаимодействия между командами на разных этапах проекта.
На этапе обследования мы всегда привлекали внутреннюю службу – отдел бизнес-процессов. Поскольку историческая система дорабатывалась более 20 лет, в ней появилось множество специфических документов, к которым пользователи привыкли. Мы могли даже не знать об их существовании, но для заказчика они были важны, поэтому необходимо было предложить им эквивалент или более современный аналог. Здесь внутренний отдел сыграл ключевую роль: специалисты объясняли назначение каждого документа и его функционал, а наши аналитики подбирали наиболее близкие к типовым механизмы.
Мы придерживаемся принципа: по возможности использовать типовые решения, а не переносить «один в один» старую, глубоко доработанную систему в ERP. Задача аналитиков – аккуратно и осознанно адаптировать уникальные процессы под стандартные инструменты платформы.
На этапе моделирования внутренняя команда также активно участвовала. Даже типовые механизмы необходимо было учитывать с оглядкой на уже внедренные доработки: за пять лет ERP-система претерпела значительные изменения благодаря внутренним разработчикам. Они помогали нам выявлять участки, где используется нестандартный доработанный функционал, чтобы мы могли корректно интегрировать новые решения.
Также было важно понимать не только то, что сделано, но и то, что будет сделано. На этом этапе они делились с нами планами, и мы это тоже учитывали в рамках моделирования.
На этапе устранения функциональных разрывов все наши технические задания проходили согласование с внутренней службой. Бизнес утверждал бизнес-цели, а отдел внедрения бизнес-процессов проверял ТЗ с архитектурной точки зрения, чтобы система получилась согласованной.
Обучение и техническая поддержка: Совместная модель
Очень важным и насыщенным этапом с максимально плотным взаимодействием между командами стало обучение и тестовая эксплуатация.
Команда интегратора обычно сопровождает клиента в момент перехода: мы внедряем систему, проводим тестовую эксплуатацию, помогаем пользователям адаптироваться к новой среде – и постепенно передаем управление заказчику. Клиент же остается с системой на долгие годы, поэтому логично, что при наличии внутренней службы численностью около 20 человек они могут самостоятельно обеспечивать дальнейшую поддержку – для них, как минимум, это будет дешевле.
Поэтому сотрудников внутренней команды мы привлекали ко всем обучающим мероприятиям. Они проходили обучение вместе с пользователями, чтобы понимать, как работает функционал, внедренный нашей стороной, и как им пользоваться в дальнейшем. Это позволило в будущем замкнуть техническую поддержку на внутреннюю команду.
Более того, программа их обучения была расширенной. Такой подход оказался ключевым: он помог избежать перегрузки команды интегратора и обеспечить плавное перераспределение ответственности за поддержку системы.
Перенос остатков: Синхронизация действий
Еще один этап с очень плотным взаимодействием – перенос остатков. Здесь крайне важно синхронизировать работу обеих команд и составить единый план действий, чтобы каждый четко понимал свою роль и зону ответственности.
Назначается конкретная дата, и в едином ритме – зачастую в выходные – мы выполняем перенос всех остатков. Переносилось буквально «все, что можно»: десятки тысяч позиций.
Из-за выбранного поэтапного подхода это было особенно интересно. Обычно перенос остатков выполняется один раз, единым блоком. В нашем случае, поскольку департаменты запускались последовательно, перенос выполнялся частями – по каждому подразделению отдельно. Таким образом, процесс получился немного нестандартным.
Модель технической поддержки после внедрения
Вернемся к этапу технической поддержки – логическому продолжению обучения. Благодаря тому, что внутренняя команда прошла полноценное обучение, нам удалось существенно снизить нагрузку на специалистов интегратора в первые месяцы эксплуатации системы.
На начальном этапе мы закрывали первую линию поддержки, а внутренняя команда брала на себя вторую. Постепенно происходило перераспределение: внутренняя служба начинала решать все больше типовых и оперативных задач, а мы переключались на архитектурные и методологические вопросы.
Такая схема взаимодействия показала себя эффективной. Грамотно выстроенное обучение внутренних специалистов позволило выстроить устойчивую систему перераспределения нагрузки в плане технической поддержки.
Сотрудничество разработчиков: Единые стандарты и практики
В проекте участвовали разработчики как со стороны заказчика, так и со стороны интегратора. Это была полноценная коллаборация, направленная на то, чтобы заказчику в дальнейшем было проще поддерживать и развивать систему собственными силами.
Для согласованной работы были подготовлены единые регламенты и требования к коду. Все доработки проходили проверку на этапе code review – когда накопившиеся изменения объединялись в общий пакет, и раз в неделю выполнялось совместное обновление системы. Выкатывание релизов происходило при участии обеих команд – наших и внутренних разработчиков.
Такое взаимодействие оказалось продуктивным: команды делились опытом и совместно оптимизировали различные процессы.
Итоги и сложности проекта
Хочу выделить несколько сложных моментов, с которыми мы столкнулись в ходе проекта, а также то, как мы их решали.
Одна из ключевых особенностей – частично запущенная и при этом динамично развивающаяся система. Это накладывает серьезные ограничения и требует особого подхода к управлению проектом. В таких условиях крайне важно, как уже упоминалось, четко разделить зоны ответственности между командами и установить контроль изменений.
Мы фиксировали согласованную модель, на которой договаривались с заказчиком, и откладывали все новые идеи и правки на этап развития. После ввода основной модели в промышленную эксплуатацию, мы внедряли те изменения, которые получили после согласования.
Отдельно стоит отметить еще один интересный момент. Проект был достаточно длительным – более двух лет. За это время мы постоянно взаимодействовали с конечными пользователями, в частности со службой техподдержки. Постепенно пользователи перестают воспринимать нас как внешнюю коммерческую команду: для них мы становимся частью внутреннего коллектива. Они видят, что мы решаем те же задачи, что и их собственные специалисты, и начинают относиться к нам как к коллегам.
Из-за этого может смещаться фокус ответственности. Начинаются просьбы вроде: «Давайте перенесем обучение на две недели – сейчас неудобно», или «Зачем проводить тестовую эксплуатацию в январе, когда праздники?».
В таких ситуациях мы нашли единственный работающий способ – напоминать о том, что: «Мы – коммерческая организация. За каждый час нашей работы платит ваше руководство. Любое смещение сроков означает простой, и за простой вы тоже платите».
Это простое, но важное напоминание помогает вернуть фокус и дисциплину в процесс. Когда пользователи начинают воспринимать время интегратора как ресурс, за который платят, повышается уважение к срокам и эффективность работы обеих команд.
Еще одна серьезная сложность – работа с требованиями. Постоянная динамика, изменения и рост запросов – неизбежная часть любого большого проекта.
Мы всегда говорим заказчикам: весь проект – это, по сути, управление ясностью. На этапе обследования мы заходим с бизнес-целями, а в ходе работы постепенно декомпозируем их до мельчайших деталей. Иногда это доходит до уровня пожеланий вроде «сделайте кнопку зеленой, а не бежевой» – и это тоже требование, которое нужно зафиксировать.
Мы не можем игнорировать пожелания клиента, но обязаны структурировать их. Все требования фиксируются, приоритизируются по очередям – первая, вторая, третья – и проходят согласование. Если клиент готов оплачивать реализацию «зеленых кнопок», пожалуйста, реализуем. Если нет – значит, доработка откладывается или исключается.
Важно, чтобы каждая задача имела коммерческую и функциональную целесообразность. Поэтому мы постоянно ведем реестр запросов, регулярно их агрегируем и отчитываемся: какие требования из первоочередных уже реализованы, какие из второй очереди ожидают решения и так далее.
Следующая сложность – синхронизация работы проектных команд. Без этого невозможно обеспечить стабильное и предсказуемое внедрение.
Эта часть проекта строится исключительно на коммуникациях. Очень важно, чтобы обе стороны воспринимали цели как общие и стремились достигать их совместно, не перекладывая ответственность друг на друга.
Для этого необходима четкая декомпозиция задач и постоянная координация действий. Мы создавали тематические чаты по конкретным направлениям, оперативно информировали коллег о любых изменениях и согласовывали шаги в реальном времени.
Грамотно выстроенный диалог между командами – ключевой фактор успеха таких проектов.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
