Автор: руководитель проектов «АиБ Цифровизация» Дмитрий Смирнов. Более 15 лет руковожу проектами внедрения «1С:Управление производственным предприятием», «1С:ERP Управление предприятием», «1С:Управление холдингом».
3 базовых вида обследований 1С
Часто встречаю ситуацию: предприятия путаются в вопросе, какое обследование им нужно и не вполне понимают, что какое обследование должно дать в результате, сколько должно стоить, как оценить, было ли обследование проведено качественно или нет. И потом, на рынке появляются гибриды разных обследований, с которыми также часто возникает путаница. Попробую внести ясность в эти вопросы.
По сути, основными видами обследований являются:
экспресс-обследование,
полное предпроектное обследование
и функциональное моделирование информационной системы (далее – ИС).
От чего зависит оценка обследования
Обратите внимание: все параметры, влияющие на оценку, в большинстве случаев будут известны уже на этапе анкетирования, и тем более они будут известны на этапе экспресс-обследования.
На оценку влияют:
размер предприятия по численности сотрудников, количество ключевых пользователей, полное количество пользователей;
состав процессов, состав функциональных блоков
и параметры интеграции.
Вот эти основные факторы и определяют оценку всех этапов, кроме одного – этапа доработок, поскольку понять, что нужно дорабатывать в системе, можно только по итогам функционального моделирования, после того, как мы в системе промоделировали все процессы предприятия и получили полную картину того, как они работают, согласовали с пользователями, и поняли, что именно нужно дорабатывать. Только тогда становится понятно, сколько стоит этап доработок. Повторюсь, все остальные этапы, они константы.
Переходим непосредственно к видам обследований
Экспресс-обследование – это обследование, которое проводится на самом начальном уровне. Основная цель экспресс-обследования с целью внедрения «1С» – познакомиться с предприятием, сформулировать цели проекта, тщательно осмотреть производство, оценить функциональный контур проекта, найти подводные камни [неочевидные, уникальные, исторические особенности предприятия, которые будут влиять на реализацию проекта]. Полученные данные будут в какой-то мере влиять не столько на оценку, сколько на ТЗ и отдельные моменты, связанные с реализацией проекта.
Безусловно, нужно оценить риски, разработать требования к оборудованию, описать интеграции, но без объектового уровня [в таком случае предприятием не получит плана, расписанного пошагово, поточечно, с описанием что именно, когда и как будет переноситься, переводиться, реализовываться], и разработать ТЗ для будущего тендера. Вот это классический контур экспресс-обследования.
Ограничения экспресс-обследования:
1) его целесообразно проводить на предприятиях с численностью до 2000 человек, поскольку предприятия больших размеров требуют уже несколько иного подхода;
2) оно функционально охватывает такие классические подсистемы «1С:ERP Управление предприятием» и «1С:ERP Управление холодингом» как управление закупками, продажами, договорами, складским учётом, учётом производства (без планирования учёта производства, без управления производством на внутритеховом уровне), бухгалтерским и налоговым учётом, раздельным учётом по ГОЗ, казначейством, зарплатой и персоналом, плюс интеграции. Более сложные подсистемы экспресс-обследование не охватит.
В качестве результата, как я уже сказал, это:
ТЗ для тендера,
дорожная карта
и бюджет проекта.
Проводится экспресс-обследование в среднем это около 2-4 недель. Погрешность оценки будущего проекта относительно небольшая – где-то 10-20%.
Преимущество данного обследования в том, что оно проводится быстро и недорого, и предприятие, компания уже получает определённую оценку проекта.
Недостатки в том, что, соответственно, невозможно охватить сложные подсистемы, и погрешность оценки всё-таки имеет место быть, в связи с тем, что не понятно, какие нужны доработки.
Заказчик обычно прибегает к экспресс-обследованию, когда хочет получить итоговую оценку всего проекта в его типовом варианте, при этом он понимает, что после функционального моделирования эта оценка будет меняться, и ему придётся выбирать: либо принимать решение в пользу применения типового функционала, чтобы не выходить за тот бюджет доработок, который был оценён изначально, либо доплатить за доработки, чтобы добиться необходимого уровня функциональности системы ERP.
Следующий вид обследования – полное предпроектное обследование
Полное предпроектное обследование к внедрению систем «1С:ERP», «1С:ERP УХ» подразумевает описание всех текущих процессов.
В отличие от экспресс-обследования, у нас появляется задача описать текущие бизнес-процессы предприятия как есть, описать функциональные требования более детально, то есть не на уровне «должны быть внедрены такие-то отдельные блоки», а с погружением в процесс, с описанием, какие конкретно функциональные требования предъявляются к какому шагу процесса бизнеса.
В предпроектном обследовании исполнитель должен выявить недостатки
бизнес-процессов, оценить состояние блока нормативно-справочной информации (НСИ), проработать план её нормализации и описать интеграции уже по объектовому уровню, в отличие от экспресс-обследования очень подробно: какие объекты какой системы каким образом куда должны быть интегрированы.
Основная задача этого обследования – понять, нужно ли автоматизировать то,
что сейчас есть на предприятии.
Если предприятие хочет критично посмотреть на состояние своих процессов и решить, нужно что-то автоматизировать в прежнем виде или это нужно менять, или если на предприятии уже знают наверняка, что нужно что-то менять, но не знают, как это сделать, и простым советом не обойдёшься, то этот вид обследования абсолютно необходим, потому что здесь происходит как раз изучение и описание процессов «как есть».
Опять же, если предприятие не планирует углубленную оптимизацию процессов, и ему достаточно типового варианта автоматизации, то без предпроектного обследования можно обойтись.
Преимущества: руководство предприятия получает возможность оценить текущие процессы и необходимость их изменения, это обследование поможет сократить стоимость последующего функционального моделирования условно на 1/3 [Функциональное моделирование в классическом виде включает в себя предпроектное обследование, подробное описание требований по интеграциям и функциональности. Соответственно, второй раз его проводить уже не потребуется. будет уже проведено на этапе полного обследования].
Недостаток: сохраняется погрешность оценки, потому что, опять-таки, при данном виде обследования не проводится функциональное моделирование, то есть объём и состав доработок нам по-прежнему неизвестен.
Ну и третий, самый полный тип обследований – функциональное обследование информационной системы
Обращаю внимание, что функциональное обследование с точки зрения автоматизации, это не обследование процессов информационной системы с приведением их к состоянию «как должно быть» – это обследование для цели проектирования информационной системы. То есть уже проектируется архитектура системы, описываются настройки системы, требования к НСИ и порядок ее нормализации, целевые процессы уже «как они должны быть» с привязкой к работе в системе.
Хорошая практика, когда компания, ведущая внедрение системы использует нотацию, в которой бизнес-процесс идёт сразу с определением действий в системе, доработками в системе на данном шаге, если она требуется, с описанием, какие печатные формы отчёта применяются.
Интеграции описываются, соответственно, тоже на детальном объектовом уровне, описывается методика учёта затрат, как наиболее, скажем так, сложный элемент финансового учёта. Описывается порядок переноса исходных данных и остатков, функциональные разрывы.
Функциональные разрывы
В качестве результата функционального моделирования информационной системы мы получаем документ «Функциональная модель», получаем план бюджета, дорожную карту проекта и ТЗ для тендера на имплементацию функциональной модели.
Период проведения обследования – от 3 до 6 месяцев. Срок уже не зависит от локации предприятия, но по-прежнему зависит от:
масштаба предприятия,
состава процессов,
и от времени, которое само предприятие отводит на проект, поскольку ключевой пользователь проекта – это обычно функциональный руководитель предприятия или его заместитель [это новый фактор].
Наверное, стоит пояснить по поводу времени ключевых сотрудников: выделить из рабочего процесса ключевых управляющих лиц предприятия тот объём времени, который хотелось бы интегратору, не всегда возможно, поэтому этот фактор тоже следует принимать во внимание.
В функциональном моделировании ИС при внедрении систем «1С:ERP Управление предприятием», «1С:ERP Управление холдингом» погрешность оценки стоимости проекта внедрения, по сути, составляет 0%. Итоговая стоимость проекта известна абсолютно железобетонно. И в этом преимущество данного вида обследования.
Соответственно, недостатки заключаются в том, что у нас всё равно возникает необходимость проводить экспресс-обследование, потому требуется предварительное знакомство с предприятием.
Второе: не проводится описание бизнес-процессов из ИС, соответственно мероприятия по адаптации бизнес-процессов тоже остаются за рамками обследования и результирующего документа. К слову, в некоторых случаях оно и не нужно, поскольку зачастую предприятия на этапе автоматизации не хотят менять, перестраивать бизнес-процессы, их устраивает текущее состояние процессов, нужно просто внедрить современную информационную систему или провести импортозамещение.
Полное предпроектное обследование и функциональное моделирование частично пересекаются в описании функций системы и интеграции.
Функциональное моделирование не охватывает описание бизнес-процессов в ИС, потому что с точки зрения создания информационной системы нужны процессы «как должно быть». Как предприятие к ним перейдёт, это уже как бы вопрос отдельный.
Коррекция процессов – бывает после функционального моделирования или нет?
Сразу нужно оговорюсь, что в ряде случаев коррекция некоторых отдельных процессов происходит даже после завершения функционального моделирования, но нужно понимать, что это не то же самое, что глобальная модернизация бизнес-процесса в целом. Подразумевается, что владелец процесса, понимая, что есть более удобные инструменты ИС, которые позволят ему лучше справиться со своим процессом, и команда разработчиков помогает подправить ему эти локальные нюансы. И это нормально, потому что владельцы процессов всегда должны работать над улучшением этих процессов. Грамотные руководители прекрасно это понимают и в подобных случаях воспринимают такую ситуацию как возможность опять что-то улучшить.