Меня зовут Юрий Силантьев, я руководитель практики «ERP и финансы» в К2Тех, отвечаю за проекты внедрения 1С.
Мы занимаемся крупными внедрениями уже 15 лет. В нашей практике проекты со сложной архитектурой, высокой нагрузкой и широким функциональным объемом. В прошлом году, например, мы рассказывали, как за семь месяцев перевели крупное химическое предприятие ПАО «КуйбышевАзот» с Oracle на 1С:ERP. В результате автоматизировали девять подсистем и 284 бизнес-процесса.
В таких проектах быстро становится понятно: успех зависит не столько от количества разработчиков, сколько от методологии. Если этапы не структурированы, роли не определены, а р��зультаты не отделимы друг от друга, даже сильная команда будет постоянно догонять сам проект.
Это первая статья из цикла, где я подробно разберу подход, применяемый нами в крупных внедрениях 1С. По шагам — от подготовки и предпроекта до эксплуатации: какие инструменты используем, как фиксируем договоренности и за счет чего удерживаем проект в управляемом состоянии.
Коротко про структуру нашей методологии
Для начала давайте разберемся, как в целом устроена методология внедрения и что в ней такого необычного.
Если коротко, методология внедрения — это последовательность проектных этапов и правил работы на каждом из них. Звучит формально, но именно эта рамка делает проект прозрачным по объему, управляемым и, что особенно важно, с отторгаемыми результатами на каждом этапе и даже внутри этапов.
В методологию входят:
структура и последовательность этапов;
набор задач внутри каждого этапа;
фиксируемые результаты: документация, модели, реестры — все, что сохраняет ценность после завершения этапа;
технологический стек — с помощью каких инструментов управляем проектом.
Методология делится на 9 этапов – каждому будет посвящена отдельная публикация в этой серии:
Этап 1. Предпроектное обследование. Многие до сих пор воспринимают предпроект как формальность: поговорили, написали сто страниц отчета об обследовании и положили на полку. В К2Тех к этому этапу отношение другое. Предпроект — это фундамент, на котором мы собираем каталог целевых бизнес-процессов, проектируем целевую архитектуру и дорожную карту внедрения. Эти артефакты позволяют сформировать образ целевого результата — внедряемой системы. Без этого этапа невозможно определить, к какому результату должна прийти команда по итогу проекта, а значит — в любой момент проект может стать неуправляемым.
Этап 2. Моделирование целевых бизнес-процессов. Если предпроект ответил на вопрос что мы будем делать, то здесь — как это будет работать в системе. Весь этап посвящен синхронизации ожиданий заказчика и команды проекта относительно процессов и их реализации. Берем каталог процессов, утвержденный заказчиком, моделируем процессы и проводим демонстрации. На выходе получаем не просто протокол, а набор договоренностей о том, как будет осуществляться работа в системе по каждому бизнес-процессу, и что для этого должно быть доработано:
описания моделей, чтобы все говорили на одном языке;
требования к системе;
список доработок;
реестр объектов миграции;
каталог точек интеграции до объекта системы.
На этом этапе происходит адаптация процессов заказчика под систему, и адаптация системы под процессы заказчика. Чем меньше гибкости в процессах, тем больше доработок потребуется выполнить в системе, чтобы подогнать ее под привычный заказчику процесс.
Этап 3. Проектирование доработок. Здесь мы переходим от списка доработок к их проектированию. По каждой позиции из списка разрабатываем функциональный дизайн (иногда э��о называют техническим проектом). Для сложных интеграций проектируем механизмы регистрации и обмена данными. Отдельно создаем шаблоны и инструменты для миграции данных. Параллельно готовимся к испытаниям системы..
Этапы 4. Разработка и тестирование. Разберем, как мы организуем разработку, чтобы она не напоминала пожарную команду, и тестирование, чтобы баг-лист не становился бесконечным.
Этапы 5. Приемо-сдаточные испытания. На этом этапе проводим комплексные испытания системы, позволяющие убедиться, что система готова к эксплуатации. Проверяется корректность выполнения сквозных цепочек бизнес-процессов, интеграционное взаимодействие со смежными системами, соответствие требованиям производительности.
Этапы 6. Подготовка к вводу в эксплуатацию. На этом этапе важно обеспечить организационную подготовку, чтобы каждый пользователь понимал, с какого момента и по каким операциям осуществляется переход в новую систему. Должно быть организовано обучение пользователей, доведены инструкции, организована техническая поддержка с оперативными каналами коммуникации. Кроме подготовки пользователей осуществляется подготовка и развертывание самой системы: производится настройка серверного оборудования, развертывание и настройка необходимого программного обеспечения, тонкая настройка СУБД, ОС, сред виртуализации, кластера приложений системы, наполнение системы НСИ и историческими данными, предоставление доступов пользователям, проверка работы внутренних сервисов.
Этап 7. Проведение эксплуатации. Это может быть опытная эксплуатация, опытно-промышленная или сразу промышленная эксплуатация. По данному этапу рассмотрим более подробно вопросы технической поддержки пользователей: SLA, эскалация, распределение инцидентов. Отдельно — как организовать команду поддержки пользователей на стороне заказчика, чтобы снять нагрузку с команды проекта и сформировать центр компетенции у заказчика.
Как видите, ничего сверхъестественного здесь нет. Но именно эта простота и строгая последовательность этапов и задач важны, потому что жизнь всегда вносит коррективы. Меняются не только приоритеты, но и люди в командах подрядчика и заказчика. И вот тут отделимость результата спасает: команда не теряет уже сделанную работу, новые участники быстро погружаются в проект, а команда управления легко адаптируется к новым условиям.
Подготовка исполнителя к проекту и проектная синхронизация с заказчиком
Теперь расскажу о самом первом и очень важном этапе — подготовке и проектной синхронизации. Как исполнителю и заказчику договориться до старта, чтобы через три месяца не выяснять, кто должен был готовить методику, кто — выделять экспертов, а кто — согласовывать бюджеты.
Начинаем с ресурсного плана — инструмента, с которого начинается проектное управление. На нем мы собираем проект: понимаем, кто, когда и с какой загрузкой нам нужен. Ставим задачи. Формируем команду.
По сути, это карта потребностей. Неважно, в каком формате ее вести — хоть в Excel, хоть в специализированном ПО. Главное, чтобы план отвечал на вопрос: на каком этапе и в каком объеме нужны конкретные люди.
Вот так выглядит наш шаблон карты потребностей:
Обычная таблица, но с осью времени и раскладкой по ролям. Наглядно видно, когда этап обследования требует аналитика, когда подключаются разработчики, а когда — архитектор.
Этот же документ мы используем на стадии оценки проекта. Заказчику не нужно читать сложные расчеты — достаточно взглянуть на шкалу ресурсов, чтобы увидеть динамику загрузки команды и бюджетную емкость каждого этапа.
Как мы нарезаем задачи
Есть ресурсный план — подбираем людей. Есть люди — планируем задачи.
Здесь важно не схлопнуть все в одну гигантскую задачу по типу «разработать систему» или «провести обследование». Мы нарезаем задачи на простые, однотипные компоненты. Иначе клиент и мы сами не увидим реальной динамики: вроде по статусам – все «в работе», а по факту — тишина.
На картинке реестр задач, в нем перечислены процессы по одному функциональному блоку, который будет автоматизироваться. Исполнитель берет процесс, моделирует, отдает заказчику на согласование. Про��есс утвержден — задача закрыта. Процесс ушел в доработку — видно сразу, по какой именно задаче. В результате по каждому процессу отдельно формируется модель бизнес-процесса, которая согласовывается с клиентом.
Так мы уходим от ситуации, когда несколько месяцев формируется один большой сложный документ, а затем начинается его длительное согласование и переделка. При такой разбивке мы согласовываем каждый отдельный процесс — и делаем это по кусочкам, по мере того как процессы смоделированы в системе. Пока коллега доделывает четвертый процесс, первый уже утвержден, по второму получены замечания, третий — в работе.
Благодаря этому:
снижается риск крупных переделок в конце этапа. Потому что переделать один процесс из десяти — это неделя работы. А вот переделать том на 200 страниц — катастрофа;
повышается управляемость работами;
мы четко видим динамику этапа: сколько процессов смоделировано, сколько осталось, какие задачи на чьей стороне. Это понятно и команде, и клиенту.
После нарезки задач вносим их в удобный таск-менеджер, шарим его с командой и назначаем регулярные митинги для контроля динамики, планирования и ретроспективы.
Шаблоны документов для фиксации работ по проекту
В любом проекте, особенно в крупных внедрениях, важна стандартизация результирующих артефактов. Поэтому при подготовке к проекту важно:
сформировать унифицированные шаблоны документов;
договориться о структуре документов с клиентом.
Мы во всех проектах используем стандартизированные шаблоны документации, принятые в К2Тех. Договоренность по структуре проектной документации мы фиксируем с клиентом еще на этапе предпроекта — в разрабатываемом техническом задании на внедрение.
Для контроля статуса выполнения проекта мы формируем детальный план-график проекта и назначаем регулярные еженедельные встречи с командой клиента.
Так выглядит наш отчет о статусе, который используем в своих проектах. Очень важно указывать здесь задачи как исполнителя, так и заказчика, чтобы команда заказчика тоже могла сфокусироваться на том, что уже сделано и что еще необходимо сделать с ее стороны.
А это наглядный статус по моделированию процессов. Здесь проект разложен по задачам и стадиям их выполнения. В цифрах можно увидеть динамику хода работ. Это очень удобно, понятно и команде, и клиенту.
Это шаблон для повестки встречи с клиентом: открытые вопросы, сложности, предложения — все, что нужно проговорить и зафиксировать:
Отдельный раздел под принятые решения и договоренности. В нем фиксируем все важные моменты, по которым достигнуты договоренности с клиентом.
Обязательно также ведем блок рисков. Здесь перечисляются проектные риски, которые считаем важным донести до клиента, чтобы фиксировать их и в дальнейшем управлять ими.
Подготовка заказчика к проекту внедрения
Самое главное — организовать проектную команду заказчика. В идеале она должна состоять из следующих участников:
1. Менеджер проекта со стороны заказчика — такой человек критически важен для проекта. Когда его нет, либо он обладает недостаточными компетенциями, проект движется сложнее, с бóльшим количеством трудностей и проблем. Это очень важная компетенция, которая обязательно должна быть на стороне клиента.
В рамках проекта менеджер:
управляет проектными задачами;
организует работу проектной команды;
принимает решения по проектным вопросам;
помогает разрешать сложные ситуации на стороне клиента;
отвечает за согласование и приемку результатов проектных работ.
2. Технический архитектор проекта — по сути, это руководитель технической части проекта на стороне заказчика:
принимает технические решения;
согласовывает результаты работ в технической части (например, проектные решения);
отвечает на вопросы, связанные со смежными системами, с которыми нам предстоит взаимодействовать;
отвечает за организацию инфраструктуры.
3. Владельцы бизнес-процессов и функциональные эксперты. С этими экспертами в рамках проекта будет очень много взаимодействия. Им предстоит работать в новой системе, поэтому именно они с нами на всех этапах: от первых интервью до приемки. Они объясняют, как сейчас устроены процессы, помогают находить узкие места, тестируют доработки. Поэтому важно сразу учитывать, что процент участия этих людей в проекте крайне высок. И нужно заранее проговорить с клиентом, чтобы он мог сбалансировать их текущую загрузку на время проекта.
Функциональные эксперты участвуют в:
функциональных интервью;
предоставлении информации о целевых бизнес-процессах;
описании методологии и алгоритмов расчетов;
моделировании бизнес-процессов;
формировании требований к системе;
тестировании системы.
4. Системный администратор — специалист, который будет администрировать инфраструктуру заказчика и организовывать доступы пользователей.
5. Команда поддержки пользователей — специалисты, которые будут обеспечивать поддержку пользователей на этапе опытной или опытно-промышленной эксплуатации. Как минимум — первая линия поддержки.
Обязательно нужно проговорить с клиентом формирование этих перечисленных проектных ролей и убедиться, что клиент сможет обеспечить эти функции. Если не сможет — важно подумать заранее, как и кем будут закрываться эти зоны ответстве��ности.
Загрузка сотрудников на стороне клиента
Часто на этом этапе клиенты спрашивают об уровне загрузки своих сотрудников в проекте. Точные трудозатраты оценить, конечно, сложно, но примерное вовлечение ключевых специалистов клиента можно представить в виде графика.
Динамика вовлечения по этапам:
Предпроектное обследование: начинаем постепенно вовлекать ключевых специалистов. Проводим функциональные интервью, согласовываем перечень бизнес-процессов и ключевые требования.
Моделирование бизнес-процессов в целевой системе: на этом этапе вовлечение сотрудников клиента — максимальное. Мы детально рассматриваем каждый бизнес-процесс, показываем, как он реализован в системе, собираем требования, обсуждаем функциональные разрывы, необходимость доработок функционала, согласовываем решения на уровне процессов.
Проектирование и разработка: после завершения моделирования вовлечение функциональных экспертов снижается. В этот период можно запланировать отпуска. На этом этапе исполнитель проектирует доработки и занимается разработкой функционала.
Вовлечение функциональной команды клиента начинает снова увеличиваться на этапе тестирования системы и достигает максимума на этапе опытно-промышленной эксплуатации, когда команда заказчика должна начать работать в системе.
Доработка смежных систем
Следующая важная задача заказчика — предусмотреть ресурсы на доработку смежных систем в рамках проекта. Это обязательно нужно сделать, чтобы у нас не возникло технических разрывов на этапе разработки и тестирования. Например, когда интеграция с нашей стороны уже готова, а на стороне смежных систем возникают проблемы, потому что работы не были спланированы заранее.
Поэтому важно заранее говорить с клиентами о планировании таких работ. Они могут касаться интеграции с новой внедряемой системой или изменения функционала самих смежных систем.
Важный момент! Если смежные системы поддерживают внешние команды, необходимо провести с ними синхронизацию и предусмотреть их работы в общем плане проекта.
Методологическая база
По тем блокам, где есть сложные и неунифицированные алгоритмы и расчеты, для их автоматизации нужна методология: конкретные методики и формулы.
Например, практически всегда этот вопрос возникает в блоках планирования и бюджетирования:
Какие бюджетные формы должны быть реализованы?
Как они рассчитываются?
Какова взаимосвязь между ними?
Как в целом происходит бюджетный процесс?
Как прогнозируются показатели?
И так далее.
Здесь важно договориться с заказчиком, что если в проекте есть такие блоки, где вообще непонятно, как процесс должен работать, нужно зафиксировать одно из двух решений:
Заказчик самостоятельно к определенному сроку предоставит необходимую информацию.
Нужно предусмотреть отдельный методологический этап, где мы выступим методологами и поможем заказчику разработать методологию.
Эти работы нужно выполнить до начала этапа проектирования целевых бизнес-процессов, чтобы, приступая к моделированию в системе, у нас уже было четкое понимание того, что именно мы моделируем.
Перечень технических и программных средств
В рамках проекта мы согласовываем с заказчиком состав технических и программных средств, необходимых для обеспечения работы новой системы.
Со стороны заказчика нужно:
подготовить необходимое оборудование;
приобрести лицензии;
организовать рабочие места.
Всё это требуется для того, чтобы к моменту запуска системы у нас была подготовлена вся необходимая инфраструктура. Учитывая скорость поставки оборудования, эту работу необходимо начинать уже с предпроекта.
Нормализация исторических данных
Отдельная тема — исторические данные. Обычно к моменту внедрения у заказчика есть остатки, обороты, справочники, накопленные годами. Всё это лежит в старой системе, часто — в разрозненном виде, с дублями, ошибками, разной степенью заполненности. Просто взять и перелить это в новую систему нельзя.
Поэтому перед загрузкой нужна нормализация. Надо решить:
какие справочники чистим и объединяем;
что делаем с дублями;
как приводим остатки к актуальному состоянию;
что вообще имеет смысл переносить, а что можно оставить в архиве.
И ложится это именно на плечи заказчика, так как у него есть экспертиза, чтобы отличить важное от неважного, актуальное от устаревшего.
Важный момент! Нормализация должна быть завершена до того, как мы начнём загрузку в продуктив. Потому что в момент старта ОПЭ система должна работать уже на чистых, согласованных данных. Если мы будем чистить и грузить параллельно — получим хаос, в котором никто не поймёт, что же является истиной.
Подготовка к обучению и работе в системе
К моменту старта опытно-промышленной эксплуатации у заказчика должно быть готово два важных блока.
Первый — инфраструктура для обучения. Если обучаем пользователей удаленно, то нужны средства удаленной связи или записи вебинаров. Если офлайн — учебные классы, проекторы, расписание. Мелочь, но именно она всплывает в последний момент: «а у нас в переговорке розеток не хватает», «а у них корпоративный VPN не пускает внешних». Договариваемся о формате и проверяем готовность заранее.
Второй — обеспечить ресурсы для организации поддержки пользователей на этапе опытно-промышленной эксплуатации. Требуется команда, которая будет отвечать на простые, базовые вопросы пользователей, связанные с:
интерфейсом новой системы;
доступом;
вопросами, описанными в пользовательских инструкциях. И так далее.
Что дальше?
В этой статье я рассказал о том, с чего начинается проект — с подготовки и синхронизации. Разобрали, зачем нужен ресурсный план, как мы нарезаем задачи, почему шаблоны документации экономят нервы, и что должен сделать заказчик до старта работ.
Во следующей статье поговорим о самом первом этапе внедрения — предпроектном обследовании. Расскажу:
чем предпроект от К2Тех отличается от классического отчета об обследовании на 300 страниц;
как мы собираем каталог бизнес-процессов и не сходим с ума;
почему без нормальной архитектуры любое внедрение превращается в заведомо проигрышную игру «угадай потребность клиента».
Если есть вопросы или темы, которые стоит раскрыть подробнее — пишите в комментарии, постараюсь учесть в следующей публикации.
