Этап моделирования и проектирования в рамках внедрения «1С:ERP» на предприятии можно назвать последней возможностью для руководства и собственников компании-заказчика определиться с необходимостью реализации проекта. После уже начнется процесс разработки. Моделирование системы позволяет заказчику «пощупать» систему, попробовать «руками», что она из себя представляет, причём не на вымышленных тестовых данных, а на реальных.
Кроме того, по тому, как проведен этот этап можно окончательно выявить компетенции команды внедрения, которая должна не только предложить решения по настройке типовых процессов, но и смоделировать те возможности будущей системы, которых в конфигурации «из коробки» нет.
В нашей статье рассмотрим основные нюансы этапа моделирования процессов и проектирования информационных систем на примерах из практики внедрения «1С:ERP» специалистами «Гигабайт».
Место моделирования и проектирования в проекте внедрения 1С ERP
Этап моделирования/проектирования обычно следует за предпроектным обследованием. Его цель отразить во внедряемой системе бизнес-процессы заказчика и зафиксировать функциональные разрывы, для исключения которых система в дальнейшем будет дорабатываться.
В рамках предпроектного обследования внедренцы получают информацию о бизнес-процессах и формируют предварительное представление о том, каким образом эти процессы соотносятся с типовым функционалом, заложенным в 1С систему.
На этапе моделирования и проектирования информация уточняется и отражается в виде объектов системы – справочников, документов, отчетов и т.д. На этом этапе внедрения «1С:ERP 2» выбираются конкретные способы отражения данных, производятся необходимые настройки. При этом упор делается не на текущую реализацию процессов, которая по различным причинам может быть далека от оптимальной, а на их целевое состояние.
Приведем такой пример.
В действующей системе учета на предприятии для управления продажами заказчик использует файлы Excel с информацией о контактах с клиентами, коммерческие предложения в виде файлов Word, складскую учётную систему для оформления отгрузок и бухгалтерскую для контроля дебиторской задолженности. В рамках моделирования мы показываем, как этот процесс будет оптимизирован в «1С:ERP»: в модельную базу будет введён клиент с историей взаимодействия, доступной из его карточки, и связанной последовательностью документов от коммерческого предложения до реализации, а также сформированными отчётами, показывающими задолженность как по конкретной поставке, так и по клиенту в целом.
Если какие-то процессы могут быть отражены различными способами, проводится анализ этих вариантов, в том числе с пробным вводом и изучением данных, и выбирается оптимальный вариант.
Результатом моделирования будет информационная база, которая является прототипом будущей системы учета на предприятии. В ней можно будет посмотреть реализацию основных процессов, наглядно увидеть взаимодействие между отдельными блоками, убедиться в правильности настройки отдельных рабочих мест (АРМов).
Кроме того, важным результатом этапа моделирования и проектирования в рамках внедрения «1С:ERP» является более точная, в сравнении с оценкой по итогам предпроектного обследования, финансовая составляющая проекта. Теперь исполнитель может озвучить более конкретную стоимость предстоящих работ.
Роль заказчика на этапе моделировании информационной системы
Не следует думать, что разработка Целевой модели и архитектуры ERP-системы задача только для специалистов компании-внедренца. Не менее важно постоянное участие ключевых лиц заказчика, причём не только в рамках своего участка работы, но и в части взаимодействия с другими подразделениями.
При переходе на новую систему часто образуются взаимосвязи между объектами и процессами, которых раньше не было, и выявить их на этапе обследования не всегда возможно, а анализ новых взаимосвязей может привести к необходимости изменить бизнес-процессы или архитектуру решения. Особенно это важно для ключевых при проектировании «1С ERP» объектов, задействованных в нескольких функциональных подсистемах и предполагающих работу с ними большого количества пользователей.
У одного из наших клиентов, которому мы внедряли «1С:ERP», перечень объектов основных средств и составных частей этих объектов отражался в разных файлах Excel с разной структурой иерархии для нужд нескольких подразделений. Каждое подразделение редактировало свой файл, отражая там нужные только им параметры. Поскольку в новой системе этот перечень должен отражаться в едином справочнике, потребовалось определить структуру, устраивающую все подразделения и назначить ответственных за ведение справочника лиц. Заказчику было последовательно предложено несколько решений, из которых было выбрано одно наиболее, по его мнению, подходящее.
Чем раньше каждый ответственный сотрудник заказчика увидит, как ему предстоит выполнять привычные операции в новой системе, и поймёт, что подобный способ его устраивает и не противоречит нуждам его коллег, тем больше вероятность, что внедрение пройдёт успешно. Если же будут обнаружены противоречия, то на данном этапе разрешить их будет проще и дешевле, чем на этапе, когда система уже разработана и передана в эксплуатацию, уверены в «Гигабайт».
Приведем такой пример.
В одной компании практически весь учёт вёлся «на бумаге». Штат компании на момент начала проекта внедрения 1C:ERP был укомплектован не полностью, поэтому на этапе обследования и далее при моделировании требования были сформированы имеющимися сотрудниками, а также сотрудниками головной компании.
Перед завершением этапа моделирования в компанию приняли коммерческого директора, который категорически не согласился с предложенной моделью отражения в системе справочника производимой продукции, устраивающей начальника производства и специалистов головной компании. Коммерческий директор имел существенную роль в компании, поэтому модель пришлось переделать и дополнительно согласовать со всеми ответственными. Поскольку система ещё не была реализована, проблема была решена с небольшими трудозатратами, однако если бы такая ситуация произошла на этапе ввода в эксплуатацию, сроки и бюджет проекта значительно бы увеличились.
Функциональные разрывы на этапе моделирования и проектирования
ERP-система «из коробки», какой бы многофункциональной она ни была, не покрывает все потребности заказчика, поэтому часть операций отразить типовыми средствами не удастся. В таких случаях фиксируются функциональные разрывы – несоответствия возможностей системы потребностям заказчика.
Для каждого функционального разрыва описывается необходимая доработка системы, которая позволит реализовать соответствующее требование. Приводится ее краткое содержание в виде концептуального описания, также может быть приведён примерный внешний вид разрабатываемого объекта. Если этот объект предназначен для ввода данных, то он может быть уже на этом этапе реализован в виде формы, в которую можно ввести и при необходимости сохранить данные, но без полной функциональности, которую предстоит разработать далее. Если объект предназначен для вывода данных (в частности, отчёт), может быть приведён его внешний вид из существующей системы, если в новой системе он не изменится, либо смоделированный в Excel.
Когда однозначно оптимальный вариант выбрать нельзя, моделируются разные варианты и описываются достоинства и недостатки каждого варианта, а какой вариант будет выбран для работы, должен определить заказчик. Варианты могут быть как в части использования того или иного объекта (например, справочника) в рамках одной конфигурации, так и в части использования той или иной конфигурации для какого-либо функционального блока.
Часто такой вопрос актуален для учёта зарплаты и кадров, бухгалтерского и налогового учёта – где-то эти блоки автоматизируют в «1С:ERP», где-то выносят в отдельную специализированную конфигурацию. Ситуация характерна и для специфических модулей (например, управление ремонтами, управление автотранспортом).
При моделировании процессов доставки продукции у нашего клиента мы выявили следующую ситуацию: в системе необходимо хранить определённую информацию об автомобилях и формировать путевые листы.
«1С:ERP» – основная конфигурация, на базе которой проводилось внедрение, – такого функционала не имеет. В качестве основы можно было использовать либо модуль «Управление автотранспортом для 1С:ERP», встраиваемый в эту конфигурацию, либо отдельную конфигурацию «1С:Управление автотранспортом», с которой настраивать обмен данными. При этом функционал и модуля, и отдельной конфигурации избыточен для задач клиента, а приобретать в случае их выбора потребуется не только саму программу, но и отдельные отраслевые лицензии. Затраты на это сопоставимы с разработкой с нуля специфического функционала в «1С:ERP» под нужды заказчика, а явных преимуществ ни у одного из вариантов не было. По итогам моделирования заказчику были предложены 3 варианта, из которых он выбрал индивидуальную доработку системы без приобретения отраслевых программ.
Сроки этапа моделирования информационной системы 1С ERP
Обычно этап моделирования и проектирования системы разбивают на функциональные блоки. Длительность работ по моделированию и проектированию одного блока составляет приблизительно 1-2 месяца, включая время на согласование документов.
По окончании этапа заказчик получает:
-
Прототип системы в виде базы с типовым функционалом, в котором отражены бизнес-процессы в формате «как будет»;
-
Документ «Отчёт о моделировании» ( либо «Целевая модель»), содержащий описание бизнес-процессов в формате «как будет» на примерах из прототипа системы и описание функциональных разрывов.
Вместе с передачей результатов этапа обычно производится демонстрация прототипа и пояснения по возникающим вопросам.
В большинстве случаев параллельно разрабатываются модели по 2-3 функциональным блокам. Таким образом, спустя примерно 2-4 месяца после начала проекта заказчик может увидеть в действии (на модельных примерах) часть будущей информационной системы.
Оценка производительности и архитектуры информационной систем
Для некоторых проектов ключевое значение имеют вопросы не столько выбора конфигураций или способов отражения различных операций, сколько архитектуры информационных баз и производительности. Это актуально для клиентов с очень большим документооборотом, наличием трудоёмких операций и территориально распределённых.
Например, вопросы к команде внедрения в таких проектах могут быть следующими:
-
Работать в одной или нескольких базах, если управляющая компания в Москве, а филиалы по всей России?
-
Что делать, если в отдельных магазинах нет надёжной связи, но остатки по всей компании хочется видеть в режиме реального времени?
-
Сколько будет формироваться отчёт по складским остаткам, если количество товародвижений – десятки тысяч в день?
-
Смогут ли пользователи нормально работать, когда происходит закрытие месяца?
Ответы на них так же можно получить по итогам моделирования и проектирования. Только в данном случае проектироваться будут такие процессы как: одновременная работа пользователей, выгрузка и загрузка данных и т.д. Для этого могут быть созданы специальные тесты, имитирующие эти процессы. Результатом этой работы будет специальный отчет для заказчика, содержащий результаты моделирования и проектирования.
Однако в таком деле есть свои тонкости. На этапе функционального моделирования, описанного выше, целевой конфигурации системы ещё нет, поэтому может оказаться, что полностью смоделировать процесс для определения архитектурных особенностей нет возможности. Например, значительную часть в объёме документооборота составляет документ, которого в типовой системе нет и который будет разрабатываться с нуля. Поэтому моделирование для определения архитектурных особенностей и вопросов производительности логично выполнять отдельным этапом после разработки функционала (либо разработки большей части функционала).
Итак, мы рассмотрели этап моделирования процессов и проектирования информационной системы «1С ERP» с различных сторон: установили цели, определили роль заказчика, рассмотрели некоторые нюансы работ, а также отметили ограничения, то есть, дали некоторое представление об этом процессе и его результатах.
А в заключение отметим еще одну важную задачу моделирования и проектирования как этапа внедрения «1С ERP» — это проверка самой компании-заказчика. Дело в том, что иногда руководство и сотрудники оказываются не готовы к тем переменам, которые несет внедрение ERP-системы. Этап проектирования максимально наглядно показывает какие бизнес-процессы должны быть доработаны, устранены или кардинально изменены, и зачастую (по разным причинам) бизнес не может на это пойти.
В лучшем случае с помощью опытных внедренцев будет найден подходящий компромисс в реализации проекта, в худшем — проект приостанавливается, либо сужается его функциональный или организационных периметр.
В любом случае, моделирование и проектирование позволяет заказчику «увидеть» и «понять» будущую систему гораздо детальнее, чем в рамках предварительных демонстраций. Ключевые пользователи заказчика знакомятся с внедряемой системой, начинают понимать ее нюансы, что безусловно сказывается положительно на успешности проекта и достижении поставленных целей.
Читайте также:
Остались вопросы?
