Этап моделирования и проектирования во внедрениях 1С:ERP
Этап моделирования и проектирования в рамках внедрения « 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-системы. Этап проектирования максимально наглядно показывает какие бизнес-процессы должны быть доработаны, устранены или кардинально изменены, и зачастую (по разным причинам) бизнес не может на это пойти.
В лучшем случае с помощью опытных внедренцев будет найден подходящий компромисс в реализации проекта, в худшем — проект приостанавливается, либо сужается его функциональный или организационных периметр.
В любом случае, моделирование и проектирование позволяет заказчику «увидеть» и «понять» будущую систему гораздо детальнее, чем в рамках предварительных демонстраций. Ключевые пользователи заказчика знакомятся с внедряемой системой, начинают понимать ее нюансы, что безусловно сказывается положительно на успешности проекта и достижении поставленных целей.
Производство без заказа в 1С:Комплексная автоматизация 2.5
В статье расскажем, как работает планирование производства в 1С:Комплексная автоматизация и как можно построить позаказное производство через инструменты планирования.
В частности, рассмотрим:
- Выпуск продукции: документ «Производство без заказа»;
- Ресурсную спецификацию и на что она влияет в работе системы 1С;
- Схему производства в 1С:Комплексная автоматизация 2.5;
- План производства, формирование документа «Производство без заказа» с учетом данных по планированию;
- Расскажем о новой возможности формирования документа «Производство без заказа» на основании документа «Заказ клиента» и дадим рекомендации по использованию данной схемы производства в 1С;
- Кому подходит «Производство без заказа» в 1С:Комплексная автоматизация 2.5, а в каких случаях лучше подойдет 1С:ERP.
Выпуск продукции: документ «Производство без заказа»
В системе 1С:Комплексная автоматизация за выпуск продукции отвечает документ «Производство без заказа». Он позволяет:
- Распределить все затраты на вкладке «Основное»;
- Указать продукцию, которую будем выпускать;
- Указать материалы и работы, которые входят в состав готовой продукции;
- Указать трудозатраты.
Ресурсная спецификация в 1С:Комплексная автоматизация
Чтобы связать в системе документ «Производство без заказа» с заказами клиента, необходимо использовать справочник «Ресурсная спецификация». Он не обязательный, но позволит, например, сформировать на основании заказа клиента документ «Заказ материалов в производство», который заполнится автоматически. Без ресурсной спецификации система не поймет, какие материалы указать.
Соответственно, в справочнике указывается:
- Что производим;
- Из чего производим;
- Трудозатраты;
- Производственный процесс: из каких этапов он состоит, какое подразделение участвует в выпуске продукции.
Схема производства в 1С:Комплексная автоматизация
Полная схема производства в типовом функционале системы представлена ниже. Она предполагает всю цепочку от заказа клиента до обеспечения материалами и передачи в цех с последующим выпуском. Можно обойтись и коротким процессом, не используя заказ и передачу материалов в производство.
На что нужно обратить внимание?
В верхней части вы видите, что входящий запрос фиксируется отделом продаж в документе «Заказ клиента». Он может быть создан как в системе 1С:Комплексная автоматизация, так и, например, через CRM Битрикс24, если она используется на предприятии. Документ «Заказ клиента» является выталкивающим для схемы производства – в табличной части указывают уже готовую продукцию.
Следующий шаг – документ «Заказ материалов в производство». Как мы уже отметили, понадобятся ресурсные спецификации, чтобы не вводить данные вручную. После этого документом «Передача материалов в производство» осуществляется фиксирование факта обеспечения производства.
Как вы могли заметить, на схеме между документом «Производство без заказа» и «Передача материалов в производство» нет связи. Это функциональный разрыв, с которым нужно что-то сделать. Дальше расскажем, как его обойти.
План производства, формирование документа «Производство без заказа» с учетом данных по планированию
Посмотрим, как работает документ «План производства» в 1С:Комплексная автоматизация. Для примера заведем в системе несколько заказов клиента.
В табличной части «Товары» указывается продукция, которую нужно выпустить – то есть фиксируется потребность клиента на получение этой продукции. Ниже выделен реквизит с планируемой датой отгрузки. Именно к этой дате будет привязываться формирование плана производства.
В качестве периода планирования мы будем использовать неделю. В первом заказе на скриншоте две позиции, которые нужно отгрузить 20 апреля. Второй заказ с датой 19 апреля и третий с 20 апреля также попадают в одну неделю. Четвертый заказ попадает уже в следующий период.
Как это отражается в системе? Сформируем документ «План производства».
Здесь важно обратить внимание на два момента:
- Сценарий. В нем указывается настройка периода. Самый популярный вариант – неделя, как и в нашем примере. Месяц – объемный отрезок времени, особенно если у вас много заказов. Отследить выпуск сложнее, а анализ данных более трудоемкий.
- Вид плана. В графе указывается источник для плана производства. В примере это заказы клиентов.
На вкладке «Продукция» нажимаем «Заполнить по правилу».
Система отразит список из трех заказов. Она собирает потребность в производстве готовой продукции, формирует количество и план производства.
Соответственно, если сдвинуть период, то в документе «План производства» отразится продукция из четвертого заказа.
Таким образом на примере видно, что именно в соответствии с установленным периодом программа понимает, какую продукцию и когда нужно произвести.
Дальше с помощью отчета «Исполнения плана производства» можно посмотреть потребность в производстве продукции. В примере отчет формируется сразу за месяц. Пока исполнение плана по нулям, и отклонение 100%.
После выполнения процесса производства и проведения документа «Производство без заказа» система отразит выпуск продукции.
В примере выпуск был произведен по первому плану производства, по второму плану производства отклонение от исполнения так и осталось 100%.
Формирование документа «Производство без заказа» на основании «Заказа клиента»
Главной особенностью системы 1С:Комплексная автоматизация является простая схема производства: видна необходимость факта производства, которая отражается в тот же момент. Именно поэтому документ называется «Производство без заказа».
Такая схема хорошо работает, когда количество одноэтапных заказов небольшое во временной промежуток.
Как это осуществляется на практике? Вы сформировали план производства: например, в нем три номенклатурные позиции. Далее оператор склада – пользователь системы должен сформировать документ «Производство без заказа» самостоятельно, заполнить его и произвести выпуск. Из этого вытекает задача обеспечения материалами, требующая временных затрат и внимания пользователя – до текущего момента данные вводились вручную.
Данный функциональный разрыв решался доработкой системы либо выпуском по схеме, где каждому «Заказу клиента» соответствовал документ «Производство без заказа».
Однако недавно разработчики фирмы 1С добавили в систему 1С:Комплексная автоматизация новый функционал. Теперь в документе «Заказ клиента» при указании номенклатурной позиции, нажатием на иконку «Создать на основании» в выпадающем меню можно выбрать и создать документ «Производство без заказа».
Такой функционал существенно упрощает работу в системе 1С:Комплексная автоматизация. В документ «Производство без заказа» продукция подтягивается автоматически. Заполняется и вкладка «Материалы и работы», поскольку в нашем примере указана ресурсная спецификация на эту продукцию.
Также в документе «Производства без заказа» на вкладке «Продукция» есть столбец «Назначение» – это обособление продукции. На скриншоте выше он пустой, потому что в заказе не поставлена галочка «Обособленно». При выборе галочки в назначении будет надпись: «По заказу клиента №…». Нужно учитывать, что во всех случаях с обособлением привязка к заказу жесткая, и изменить или отменить ее нельзя.
Далее после проведения документа «Производство без заказа» при условии обеспечения материалами, происходит выпуск продукции.
После закрытия периода можно посмотреть себестоимость. Например, «Дерево себестоимости продукции предприятия» на скриншоте ниже.
Обратите внимание, что у нас материалы были обеспечены закупкой – документом «Приобретение товаров и услуг». Программа, согласно настройке учета запасов, распределила их в соответствии со схемой FIFO по дате поступления.
Кому подходит «Производство без заказа» в 1С:Комплексная автоматизация 2.5, а в каких случаях лучше подойдет 1С:ERP
Резюмируя, какая схема возможна при работе с системой? На основании документа «Заказ клиента» можно вывести две параллельные цепочки:
- «Заказ клиента» – создать на основании – «Заказ материалов в производство». Это цепочка обеспечения. Например, «Закупка» и «Передача материалов в производство».
- Когда материалы оказались в производстве, можно произвести выпуск продукции. Это цепочка «Заказ клиента» – создать на основании – «Производство без заказа».
Минус такой схемы: производство нужно строить от каждого заказа клиента, потому что нельзя создать документ «Производство без заказа» по ряду заказов. В системе 1С:Комплексная автоматизация нет документа «Заказ в производство», который мог бы аккумулировать несколько заказов.
При выборе системы мы советуем взвесить все плюсы и минусы непосредственно для вашей компании. Если у вас объемное производство, есть необходимость четко отслеживать материалы, то рекомендуем обратить внимание на систему 1C:ERP: в ней есть документ «Заказ в производство» и четкая привязка к выпуску.
Документ «Заказ в производство» присутствует также в программе 1С:Управление нашей фирмой. В 1С:УНФ реализована полная схема производства, но она кардинально отличается от 1С:Комплексная автоматизация и 1С:ERP, что важно учитывать при стратегическом планировании развития вашей компании и дальнейших потребностей в автоматизации.
Мы будем рады помочь вам оценить возможности и затраты в случае выбора того или иного решения 1С – отправьте заявку, и наши специалисты свяжутся с вами.
Назначение функционального моделирования
Перед тем как отправить новую модель самолёта в свой первый полёт тысячи специалистов выполняют огромную конструкторскую работу. Входящим сигналом для первых этапов проекта является бизнес-требования авиакорпораций (создать более конкурентный продукт), правительственная программа разработки (поддержать производственные предприятия страны), новые достижения науки (появление новых композитных материалов). Но до создания какого-либо прототипа надо определить: полетит ли самолёт вообще? Какие критические углы наклона? Какая подъёмная сила и много другое. До компьютерной революции помогали карандаш, бумага и законы математики и физики.
Выдержка из публикации профессора Н.Е. Жуковского «О парении птиц». 1891 г.
Сегодня же необходимо создать программную модель самолёта, поместить её в виртуальную среду, подать возмущающие воздействия и получить результат в виде сильных и слабых сторон исследования. Нет, это не так просто, но это стало технически возможно. Более того, существуют инженерные авиасимуляторы, например, «X Plane», которые учитывают всю физику происходящего с самолётом и рядом с ним, и, даже если задаться вопросом что произойдёт, когда выпустят интерцептор на крейсерской скорости, то можно получить достаточно точный ответ.
На выходе функциональное моделирование (ФМ) даёт приблизительный результат (точный даст — опытная эксплуатация):
- работает ли концептуальная модель?
- соответствует ли она поставленным техническим- или бизнес-требованиям?
- какие ограничения и границы модели?
- уязвимости, ограничения, экономика проекта и др.
Должен ли владелец бизнеса ответить на те же вопросы при запуске новой системы 1С:Предприятие (1С ERP, КА, УТ и др.) да и всего остального ? Однозначно. Функциональное моделирование как раз для этого и предназначено.
Предлагаю оглавление по документу ФМ:
- Описание бизнес-процессов предприятия (As is/To be).
- Выбор решений программного и аппаратного обеспечений.
- Насколько соответствует типовое решение техническим требованиям и бизнесу?
- Какая допустимая нагрузка на систему / подсистемы?
- Какие условия информационной безопасности?
- Обзор текущей инфраструктуры.
- Какие функциональные разрывы между системой и бизнес-процессами и способы их устранения?
As is/To be
Модель «To be» описывается всегда.
Модель «As is» описывается в случаях работающих (управляемых и осознанных) процессов предприятия, составления стратегии плавной реорганизации, для определения критериев эффективности новой архитектуры.
Типовое решение и функциональные разрывы
Вернёмся к математике, к формуле нормального распределения, график которого имеет следующий вид:
В общих словах, большие отклонения имеют малую вероятность (незаштрихованные области) и чем больше отклонение, тем реже оно встречается. Разработчик массового программного обеспечения должен укладывать функционал системы в среднеквадратическое отклонение (заштрихованную область) — в то, что с наибольшей вероятностью будет использоваться на большинстве предприятий.
В ФМ требуется определить попадание бизнес-процессов в функциональность системы. Если количество редких бизнес-процессов велико, то требуется выбирать иное программное обеспечение (комплекс программ) или значительно дорабатывать существующее. Требуется компетенция аналитика, то есть знание продукта и отсутствие неловкости в вопросах «почему? и «зачем?».
Ниже представлен слайд отчёта фирмы 1С по программному продукту 1С ERP, который резюмирует, что «89% функционала внедряется без доработок или с небольшими доработками».
Возражения пользователей на тему «1С не делает самый необходимый важный функционал» остаются лишь эмоциями.
Нагрузочное тестирование
Фирма 1С разрабатывает и предоставляет внедренцам комплекс программ «1С:Корпоративный инструментальный пакет 8» для повышения успеха проектов, в том числе на этапе функционального моделирования.
Основные задачи «1С:Корпоративного инструментального пакета 8»:
- автоматизированное проведение многопользовательских нагрузок без участия пользователей;
- оценка применимости и масштабируемости системы в соответствии технических требований;
- выбор аппаратного(серверного) и программного обеспечения;
- расчёт показателей производительности системы во время ее нагрузочных испытаний или рабочей эксплуатации;
- информация по динамике производительности системы;
- поиск и «узких мест» и оптимизация кода системы;
- автоматизированное функциональное тестирование конфигураций.
Это больше чем необходимо на ФМ, но крайне важно на средних и крупных проектах (внедрения по технологиям ТБР и ТКВ). Для внедрения ТСВ (Технология стандартного внедрения) допускается не делать нагрузочное тестирование.
Документирование
Результатом функционального моделирования должен стать:
- одноимённый документ, в котором описаны бизнес-процессы, поведения системы, результаты тестирования и требуемые функциональные доработки,
- база(ы) данных.
Несколько моделей предназначены для варианта нескольких кандидатов типовых/отраслевых решений Для принятия правильного решения требуется предоставить сравнительную характеристику, например SWOT-анализ.
Рабочая папка наполняется большим количеством файлов, которые созданы в работе следующим программным обеспечением:
Организация внедрения проекта
В ходе данного этапа организации внедрения проекта выполняется сбор основных сведений о текущей ситуации у Заказчика, проводится интервьюирование ключевых пользователей будущей системы, изучение текущих учетных систем. По итогам предпроектного обследования структурируется полученная информация, которая позволяет оценить сроки, фазы и этапы всего проекта, а также его бюджет. В качестве итогового документа предоставляется «Отчет об экспресс-обследовании».
Основной ценностью этапа предпроектного обследования для Заказчика является получение зафиксированного скоупа проекта и знакомство с ключевыми участниками проектной команды (руководитель проекта, архитектор)
2. ЭТАП 2. Моделирование внедрения проекта 1С
Суть процесса моделирования при внедрении проекта 1С – наложение реальных процессов организации на имеющиеся механизмы отражения подобных бизнес-процессов в типовой конфигурации от 1С и фиксация функциональных разрывов – различий, требующих донастройки или серьезной доработки системы.
На данном этапе разрабатывается функциональная модель целевой системы, формируются требования к подготовке отчетности, утверждаются состав требуемых аналитических разрезов.
Выполняется проработка решений по способам автоматизации с подготовкой прототипа системы и написанием документа «Концептуальный дизайн», в котором фиксируются и описываются все принятые решения на типовом функционале. Будут проведены демонстрации практической реализации различных процессов и настроек в демо-базе, отработаны сквозные примеры, соответствующие специфике бизнес-процессов Заказчика.
Сам процесс моделирования в значительной части проходит в плотном взаимодействии сотрудников Исполнителя и Заказчика: сотрудники Заказчика активно вовлекаются в работу, производится обучение ключевых сотрудников и экспертов Заказчика. Со стороны Заказчика выполняется уточнение и актуализация учетных политик регламентированного и управленческого учета, действующих регламентов и процессов управления. Состав регламентов определяется внедряемыми подсистемами.
Концептуальный дизайн – документ, содержащий описание бизнес-процессов, подлежащих отражению в системе. По сути, это описание системы «To be».
Реестр функциональных разрывов – документ, содержащий перечень требований на доработку с табличным представлением результата.
Моделирование внедрения проекта системы 1С ведётся по блокам, короткими итерациями при наличии активной взаимосвязи по схеме:
создание модели → демонстрация → корректировка модели
3. ЭТАП 3. Проектирование внедрения 1С
На данном этапе положения и требования, зафиксированные ранее, преобразуются в конкретные проектные решения. Проектные решения описываются в частных технических заданиях (ЧТЗ) на каждую модификацию (доработку).
Несмотря на кажущуюся обязательность данного этапа внедрения проекта 1С, наша практика показывает отсутствие необходимости составления единого технического задания и технического проекта на всю систему после выполнения этапа «Моделирование».
Т.к. все функциональные разрывы с типовой конфигурации 1С описываются по итогам этапа «Моделирования», этой информации нашей команде в большинстве случаев достаточно для реализации всех доработок системы.
С учетом тренда на максимальное использование типового функционала при внедрениях, мы стараемся идти по пути минимального количества доработок системы, при этом используется механизм расширений, сохраняющий типовую конфигурацию для беспроблемных обновлений.
Тем не менее в ряде случаем мы включаем данный этап в проект, особенно если предстоит значительная адаптация системы. Выходным документом данного этапа является документ «Техническое задание» (ТЗ), частное технические задание или «Технический проект» (ТП).
4. ЭТАП 4. Разработка и тестирование информационной системы
На данном этапе реализуются доработки в информационной системе, после чего по каждой доработке проводится процедура приемо-сдаточных испытаний (ПСИ). При этом проводится как сценарное тестирование информационной системы, так и нагрузочное (при необходимости).
В случае проведения нагрузочного тестирования информационной системы и подготовки его результатов необходимо привлечение специалистов, компетенция которых подтверждена компанией 1С (сертификация 1С:Эксперт по технологическим вопросам).
5. ЭТАП 5. Обучение пользователей типовой конфигурации 1С
На данном этапе производится обучение участников проектной команды и подготовка пользовательской документации.
В соответствии с разработанным и согласованным планом обучение производится как в очном формате, так и в формате вебинаров. Обучение включает в себя как теоретическую, так и практическую часть.
На основании нашего опыта, мы рекомендуем проводить обучение сотрудников, занятых на проекте как можно раньше, возможно, даже до начала предпроектного обследования. Это позволит сотрудникам быть максимально вовлеченными в процесс за счет лучшего восприятия системы и ее особенностей.
6. ЭТАП 6. Подготовка к эксплуатации информационной системы
На данном этапе выполняется:
· развертывание ИС в рабочей среде;
· настройка системы для отражения всех включенных в проект бизнес-процессов;
· настройка прав и ролей пользователей;
· перенос исторических данных из ранее использовавшихся систем;
· интеграция со смежными системами;
· выверка и корректировка данных;
· развертывание системы на рабочих местах пользователей.
7. ЭТАП 7. Опытно-промышленная эксплуатация информационной системы
Опытная эксплуатация информационной системы проводится Заказчиком при поддержке Исполнителя на реальных данных посредством ввода данных и получения необходимой отчетности одновременно в двух системах – исторической и создаваемой с целью найти отклонения в работе функционала новой информационной Системы. Срок опытной эксплуатации информационной системы устанавливается по согласованию сторон в пределах от 1 до 3 месяцев.
На стадии опытной эксплуатации информационной системы производится поддержка и сопровождение системы силами Исполнителя: происходит устранение замечаний, производится дополнительное обучение пользователей в процессе их работы в реальных условиях, осуществляется консультационная помощь при работе с системой.