План и этапы внедрения 1С:ERP

Проект по внедрению 1С:ERP делится на две основные части:

• подготовка к внедрению системы
• запуск в промышленную эксплуатацию.

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

Расскажем подробно о всех этапах: осветим нюансы, на которые следует обращать особое внимание, продолжительность этапов и то, чем должен завершаться каждый из них. А также ответим на вопрос, на какой период года планировать начало проекта?

Обследование

Подготовка к внедрению начинается с обследования. Обследованию может предшествовать экспресс-аудит с проведением стратегической сессии, когда формируется единство определения границ проекта в команде заказчика.

Дальше мы приступаем к полноценному обследованию бизнес-процессов.

Участвуют специалисты с нашей стороны и со стороны заказчика по каждому блоку учета, которые внедряем. Если внедряем комплексно систему, то речь идет о блоках:

• регламентированный учет;
• оперативный учет, включающий товародвижение (закупки, продажи, складской учет);
• производственный учет, который может быть детализирован, а может ограничиваться только календарным планированием;
• управление персоналом и расчет заработной платы. Блок является частью ERP, но в ряде случаев может быть вынесен в отдельную систему, как и бухгалтерия;
• управленческий учет.

Также ERP позволяет автоматизировать казначейство, бюджетирование, управление автотранспортом, управление техническим обслуживанием собственного оборудования, требующего профилактики, ремонта, замены. Всё это можно объединить в одной системе!

В результате обследования появляется Устав проекта и Иерархическая структура работ (ИСР). Мы понимаем “как есть сейчас” и фиксируем требования к системе: какие задачи нужно решить, какие неудобства в работе исправить. Определяем цели и границы по каждому функциональному блоку, а также критерии оценки автоматизации: “как мы поймем, что задача решена?”, “какие документы, отчеты, показатели должны появится?”. Не всегда ответы получаем сразу. Их порой даже нет у заказчика. Чтобы разобраться в ожиданиях от системы и определить истинные критерии, а не выданные наспех для галочки, требуется провести ряд переговоров с будущими пользователями ERP, обратиться к текущей учетной системе или excel файлам, которые заполняют на предприятии. Именно эта работа обеспечивает по итогам проекта ожидаемый клиентом результат. Именно она позволяет настроить систему под конкретное предприятие и конкретных пользователей. В компании «Новая Цефея» мы серьезно работаем с ожиданиями клиента. Внедрить стандартный функционал системы могут разные компании, но далеко не все беспокоятся о результате и о том, чтобы он по-настоящему помогал специалистам, решал задачи предприятия не только в теории, но и на практике.

Обследование длится от 2 недель до 5 недель. На этом этапе формируются требования к контрольному примеру, который мы будем реализовывать в дальнейшем - на этапе моделирования.

Моделирование

В рамках этого этапа создается функциональная модель системы. Что это значит? В чистой 1С:ERP выполняются верхнеуровневые настройки, вносится минимальное количество данных. Это некая демо-база, приближенная к процессам заказчика. Создаются 2-3 наименования номенклатуры со всеми характеристиками, присущими настоящей номенклатуре предприятия заказчика. Если предприятие производит мебель, то в базе появятся, например, один стул, диван, шкаф, и в характеристиках будут отражены реально используемые параметры (материал, габариты, комплектующие, максимальная нагрузка и прочее). Все процессы, описанные на этапе обследования, пошагово вносятся в ERP, чтобы каждый нашел отражение в рамках типовых возможностей системы.

Бывает, обнаруживаются процессы, которые нельзя реализовать за счет типовых средств. Тогда мы фиксируем ситуацию, описываем отличие процесса заказчика от типовой логики системы. Выносим вопрос на обсуждение руководству проекта. Рабочая группа со стороны заказчика и со стороны компании «Новая Цефея» принимает решения по каждой из таких ситуаций, которые называются функциональными разрывами. По каждому функциональному разрыву решается: будем дорабатывать ERP-систему, то есть изменять типовой функционал и писать дополнительный код или заказчик модифицирует бизнес-процесс, приблизив его максимально к типовой логике, зашитой в ERP.

В функциональной модели заказчик видит, как выглядит интерфейс, как происходит движение документов, какие действия необходимо выполнить, чтобы получить тот или иной результат. Документ, описывающий каждое действие, настроенное в системе, так и называется - Функциональное модель. Принимается как итог работы по моделированию. Второй документ, получающийся в результате этого этапа - Перечень функциональных разрывов. Он передается в производственную службу, чтобы программисты сделали оценку доработки.

Функциональная модель описана настолько детально, что по этому документу - бери и делай. И действительно, некоторые наши заказчики с сильной IT-службой справляются с описанными настройками своими силами.

Итак, по итогу моделирования заказчик четко понимает, как будет выглядеть система и как она будет работать. Поэтому запуск в промышленную эксплуатацию не станет для него сюрпризом.

Это самое ценное - мы погружаем заказчика с начала работы в возможности системы и трепетно относимся к его ожиданиям.

Этап моделирования длится 4-10 недель

Настройка системы и доработка по функциональным разрывам

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

Перенос данных

Хочется отдельно рассмотреть этот процесс, хотя он выполняется в то же время, что и настройка с доработкой, ведь сложность и значение переноса многие недооценивают. Есть большое количество типовых переносов, которые не дают желаемого качества информации, потому что в результате элементарно могут не совпадать характеристики данных. В своей практике мы обязательно проверяем переносы и чаще всего дописываем их, чтобы не потерять ни один параметр номенклатуры заказчика, ни один элемент учета. Бывает так, что нет никакой возможности перенести данные типовыми способами, например, если использовались какие-то старые системы, или не системы 1С, самописные. Тогда перенос полностью пишется.

И вся эта работа должна быть закончена к 31 декабря, потому что ERP-система, если внедряется регламентированный учет, должна внедряться с 1 января.

В другие сроки - можно. Но это “можно” ляжет грузом на плечи бухгалтеров. Ведь большинство отчетов сводится по данным за весь год. Если часть года отработать в одной системе, а другую - в новой, отчетность придется собирать вручную из разных систем. Для крупных компаний это огромный труд и даже риски. Поэтому, когда мы говорим о комплексном проекте ERP, включающем блок регламентированного учета, то в 99% случаев планируем проект так, чтобы 1 января можно было начать полноценную работу в новой системе.

Тестовая эксплуатация и нагрузочное тестирование Желательно включить в проект этап тестовой эксплуатации, иногда плюсом к нему - нагрузочное тестирование. Что это такое? Это возможность проверить незадолго до запуска в промышленную эксплуатацию полноценно настроенную систему с перенесенными данными на текущую дату. Проверить функциональность тест-кейсами. Это тоже особенность нашей технологии внедрения, которая позволяет на определенных примерах, содержащих усложняющие вводные, проверить работоспособность системы и выдаваемый ею результат.

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

И для тестовой эксплуатации, и для нагрузочного тестирования составляются сценарии, они согласуются “на берегу”, до начала работ по этим этапам. Определяются критерии качества - по каким показателям поймем, что тестовая эксплуатация и нагрузочное тестирование прошли успешно.

Обучение

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

Обучение проводим в разных форматах. Например, в группах, когда преподаватель показывает и рассказывает, как работать в системе, а далее пользователями выполняются примеры, чтобы закрепить полученный материал и задать преподавателю вопросы по ходу практики. По окончании обучения проводится экзамен для того, чтобы определить - готов специалист к работе в системе или нет. Если не готов, то прорабатываются мероприятия для дополнительной подготовки. Делаем инструкции на доработанный функционал. На типовой - их составляет сама фирма “1С”. Мы идем в ногу со временем и практикуем видео-инструкции, демонстрирующие экран и какие документы надо открыть, на какие кнопки кликнуть. Запуск в промышленную эксплуатацию Это время, когда все наши консультанты, работавшие с заказчиком на протяжении всей подготовки к запуску, находятся непосредственно на территории заказчика рядом с пользователям. Пользователи прошли обучение, получили инструкции, но помимо всей этой технологической подготовки нужно учитывать влияние психологических факторов на успешность проекта. В том числе, психологические сложности купируются присутствием наших консультантов по каждому блоку на территории заказчика в момент запуска:

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

От 2 недель до 2 месяцев, в зависимости от количества пользователей и масштабов проекта, наши консультанты работают на территории заказчика. Дальше их присутствие постепенно снижается. Сначала они - буквально за соседним компьютером. Потом все так же 100% времени доступны для заказчика, но уже удаленно в Skype, Zoom, Telegram и т.п. Постепенно это взаимодействие сокращается. Если проект большой, содержащий все блоки учета, то период ввода в промышленную эксплуатацию длится 4 полных месяца и заканчивается сдачей квартальной отчетности за первый квартал. По рег. учету критерием того, что система функционирует нормально является формирование отчетности за первый квартал года. Таким образом, из проекта мы фактически выходим в мае. Если автоматизируется не все блоки, либо как минимум нет регламентированного учета, то длительность проекта может быть меньше, потому что оперативный учет, производственный требуют от 1 до 3 месяцев запуска.

Оптимальное время для старта проекта - середина года, июнь-июль.

Часть клиентов, которые не понимают, что запуск системы должен происходить 1 января, начинают интересоваться внедрением ERP после летних отпусков, осенью. В таких случаях мы отвечаем, что осталось мало времени для подготовки к запуску. Предлагаем перенести проект на следующий год. Некоторые компании соглашаются отложить задачу, кто-то находит других подрядчиков, решающихся на экстремальный запуск. Но мы понимаем, удовлетворенных заказчиков от экстремального запуска обычно не бывает. Поскольку нам важен качественный результат работы, не беремся за экстремальный запуск.