Терминология

В своей практике я чаще использую результат первого этапа — «Функциональное моделирование». Этот документ в моём исполнении предусматривает не только технические требования к системе, но и бизнес-процессы с описанием возможностей и ограничений программного продукта 1С:ERP. В содержательной части он даёт широкий горизонт видения по внедрению продукта для всех участников. По желанию заказчика могут быть описаны иные требования, но максимальное внимание уделяется на сопряжение бизнес-процессов и цифровых решений.

Сокращения и обозначения

1С ERP	Комплексный программный продукт фирмы 1С для автоматизации среднего и крупного бизнеса
1С УНФ	Комплексный программный продукт фирмы 1С для автоматизации малого бизнеса
БСП	Инструментарий разработчика «1С:Библиотека стандартных подсистем»
ТЗ	Техническое задание
ФМ	Функциональное моделирование
БП	Бизнес-процесс
НСИ	Нормативно-справочная информация
ВРЦ, РЦ	Вид рабочего центра, Рабочий центр
АРМ	Автоматизированное рабочее место

Введение

Данная публикация несёт ретроспективный характер в которой я постараюсь продемонстрировать аналитическую работу при разработке технического задания на внедрение 1С ERP. Указание конкретного продукта — 1С:EPR — в какой-то мере имеет значение, так как местами буду я опускаться в его технические особенности и описывать сложности с которыми сталкивался. То есть технику и технологии буду комбинировать с методологией, чтобы картина была более полной. Буду выдерживать конфиденциальность, поэтому реальные цифры упразднены или изменены, а деловые разделы будут изложены общей практикой без коммерческих деталей.

Запрос и имеющиеся наработки

На почту пришло стандартное сообщение с запросом «автоматизации дверного производства по спецификациям» и возможности моего участия. 

Получилось так, что на тот момент я параллельно работал с двумя компаниями дверного производства (на базе 1С УНФ) и достаточно понимал технологию производства и способы автоматизации.

Были уже различные наработки и решения:

• Проработки НСИ дверного производства. Пример категории, свойства которого описывают физические и технологические параметры. Полнота описания НСИ дверей позволяет детализировать ведение материального и технологического состава, ценообразование, использовать отборы. 

• Спроектированы и разработаны формульные спецификации. Как видно из письма — сделан акцент на производство по спецификациям. В то время как моя разработка открывала возможности формульного описания расходов материалов и операций. Использовался язык выражений системы компоновки данных. Практика применения тут.

Небольшое отступление. На тот момент ни пахло никакими параметрическими формулами в 1С:УНФ и после одного проекта со схожим функционалом я решил инвестировать свои средства и время в разработку специализированного решения. После его выхода оно продавалось лишь несколько недель — вскоре похожий функционал появился в типовой версии УНФ. Было продано всего 4 лицензии — мои инвестиции закрылись с минусом и огорчением. И даже с язвительными комментариями спустя несколько лет (╯°□°)╯

 

• Созданы АРМ рабочего цеха с пооперационным учетом. Для производства у меня уже были разработаны АРМ рабочего с пооперационным учетом, где рабочий подтверждает выполнение своей операции — создаётся сдельный наряд с начисленной зарплатой — а второму участку, следующим за ним, автоматически отображается следующая по технологии операция. 

За тысячи часов проведенных на разных заводах у меня аккумулировались знания и усреднялись потребности по функционалу которые оформлены в Пульт управления производством и АРМ Начальника производства. Прошу прощения за саморекламу.

В предпродажной переписке и выставлении коммерческого предложения опыт имел значение, общение с производственниками на одном языке дало старт написанию Функционального моделирования для 1С ERP.

План работ Функционального моделирования 1С ERP

Результатом работ первого этапа работ является документ «Функциональное моделирование бизнес-процессов продаж и производства металлических дверей и их материального обеспечения в программе 1С ERP» со следующим содержанием:

• Описание бизнес-процессов продаж по модели «Как надо» (список моделируемых процессов продаж, блок-схема(-ы) с применением объектов системы 1С ERP).
• Построение архитектуры нормативно-справочной информации (номенклатуры, характеристик, спецификаций, в т.ч. параметрических, дополнительных свойств), описание назначения используемых объектов в подсистеме продаж 1С ERP.
• Разработка механизма плановой себестоимости с включением накладных расходов.
• Ценообразование производимой продукции
• Формирование плана продаж в 1С ERP
• Описание бизнес-процессов обеспечения материалов по модели «Как надо» (список моделируемых процессов, блок-схема с применением объектов системы 1С ERP).
• Формирование плана закупок и резервирования материалов
• Описание бизнес-процессов планирования производства и отражения выпуска по модели «Как надо» (список моделируемых процессов, блок-схема с применением объектов системы 1С ERP) в исполнении:
  • производство без заказов,
  • производство по этапам (одноэтапное/многоэтапное),
  • пооперационное планирование,
  • пооперационное MES планирование.
• Описание производственных мощностей – видов рабочих центров (ВРЦ) и рабочих центров (РЦ).
• Формирование плана производства по ВРЦ и РЦ по разным производственным моделям (точно в срок, равномерно, минимальное количество переналадок) в 1С ERP.
• Описание структуры цеховой автоматизации. Изучение вопроса разработки автоматизированных рабочих мест (АРМ) в цехе.
• Учёт трудозатрат выпуска продукции 1С ERP
• Расчет фактической себестоимости в 1С ERP
• План-фактный анализ себестоимости в 1С ERP

Длительность по договору — 3 месяца, а по факту составила 4 месяца с регулярными командировками. Отклонение было адекватным и связано с классическими причинами — где-то требуется дополнительно проработать, осознать, согласовать. Как Заказчику, так и Исполнителю.

С целью минимизации риска сторон ФМ разбили на 2 этапа с авансовым платежом и конечным расчетом по каждому из этапов. 

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

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

 

.

БП и НСИ. Рука об руку

Протокол демонстрации был на финише, а сначала — изучение объекта автоматизации. Начиная работу с описания верхнеуровнего БП, далее опускаясь на детальные подпроцессы, мы их уточняем, наполняем и структурируем НСИ. Возникает приблизительно одинаковая для производств блок-схема следующего вида:

Простая исходная схема усложняется из-за дня в день и по итогу даёт нам описание двери в более сотни (а точнее 170+) свойств характеристик. Если образно представить обследование и проработку ФМ на незнакомом предприятии — то лучше всего это даёт декодирование progressive jpeg. Полагаю пояснения «почему» не требуются. 

Имеется номенклатура продаж  — «Дверь» (можете вставить свой объект) и её характеристики со свойствами (на рисунке общее описание двери, без привязки к конкретному предприятию). Характеристики с описанием свойств — этот стандартный механизм 1С БСП, который может описывать любую конечную продукцию и наработки — диван, кухонный гарнитур, продукция пластмассового или металлического литья, электронагреватель, термосопротивление, и бесконечно далее.   

Конечно для работы с большим списком характеристик требуется помощник и он должен выполнять функции:

1. Помогать работать со списком номенклатуры. Например, заполняя свойство Замок, система должна отобрать из всего справочника номенклатуры только «Вид номенклатуры = Замки».
2. Заполнять некоторые свойства по умолчанию. Например, по умолчанию стандартный уплотнитель.
3. Заполнять некоторые свойства в зависимости от выбранных значений других свойств. Например, установив зеркало на панель, устанавливать глазок по центру не допускается. 
4. Запрещать заполнять некоторые значения в силу технологии производства. Например, допускается высота двери с шагом 5 см или в силу установленных опций. 
5. Динамически рассчитывать стоимость двери и её вес.

Как понимаете, программировать все эти условия — безрассудство, а адекватность за тем, чтобы предоставить пользователю инструменты, которыми он бы пользовался самостоятельно — прописывал условия совместимости. Для этого мне потребовалось спроектировать небольшую систему хранения опций в соответствии с указанными выше функциями. Результат любого проектирования оформляется в Техническую задачу в составе ФМ. Пример вставки:

Требование бизнеса по детальному описанию НСИ ведёт к образованию большого списка свойств, с которым достаточно сложно, а иногда невозможно, работать стандартными средствами 1С. После фиксации проблемы и обоснования её необходимости приступаю к проектированию доработки в виде системы справочников НСИ. Пример технической задачи в виде подсистемы:

Каждый справочник описывается отдельно с содержанием:

• Цели и назначения с точки зрения бизнеса
• Техническая структура данных с атрибутивным описанием и комментариями по назначению
• Вид формы объекта
• Функции объекта

Пример описания создаваемого объекта НСИ — «Допустимые значения свойств»

Цели и назначения с точки зрения бизнеса

Справочник предназначен для хранения допустимых свойств номенклатуры для последующего использования в качестве отбора в механизме «Техническая задача»

Сразу скажу, что в типовой системе 1С ERP (точнее в подсистеме БСП) существует механизм отборов, но он доступен только в пределах Справочника Дополнительные реквизиты. Например, есть «Способ крепления» и «Материал арматуры» — оба представлены типом данных «Справочник Дополнительные реквизиты». Имея такую структуру я могу задать Способ крепления, в случае Материала арматуры = N. На этом, к сожалению, всё. У меня нет возможности заблокировать реквизит, если ширина (числовое значение) < 600, что с точки зрения бизнеса могло бы говорить, что ковку я не могу становить на узкую дверь.

Применение ограничений свойств в БСП

Обосновали необходимость и возвращаемся к планируемому справочнику — описываем реквизиты.

Атрибутивный состав

Визуализируем виды форм, так как Заказчику, особенно функциональному заказчику табличные части могут ничего не сказать.

Формы справочника

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

Способ задания дополнительного и альтернативного условия выполняется через отельную командную кнопку «Дополнительное условие» с открытием новой формы настройки условий в командной панели.

Логику и способ реализации заимствую из формы условий Ресурсной спецификации 1С ERP.

Функции справочника

• Отбирать номенклатуру и свойство из списка таблицы. То есть указание номенклатуры «Престиж» производит отбор всех строк в таблице по этой номенклатуре, а указание свойства «Наружная отделка» отобразит все записи с номенклатурой «Престиж» и свойством «Наружная отделка».
• При выборе свойств предлагать пользователю только те свойства, которые относятся к виду номенклатуры поля номенклатура. Если номенклатура не задана – выводить все свойства.
• При пользовательском создании новой строки программно должен формироваться её уникальный идентификатор, который используется как связь условий со строкой ТЧ.
• Наличие дополнительных и альтернативных условий в основной таблице должны отображаться в соответствующих колонках в виде пиктограмм.

Параметризация — связь НСИ и производство. И не только.

Для серийного производства по отлаженной технологии достаточно описать одну/несколько ресурсных спецификаций, но если ваше изделие постоянно зависит от входящих условий, то удобнее использовать функциональную опцию 1С ERP  «Использовать параметризацию ресурсных спецификаций и маршрутных карт».  Возможность такая есть, но без приключений не обойдется.

ВыборПоПорогу()

Начнём с более простого — ВыборПоПорогу(<Параметр> <Значение1>,<Порог1>, <Значение2>,<Порог2>
<Значение3>,<Порог3>,…), который может выдать необходимое значение от достижения порога. Такая формула может подойти если допустимо сравнивать только с одним условием.  Утеплитель дверей в рулонах я могу задать в зависимости от ширины двери. 

Дубль строки с условием

Скажу откровенно, что формулой ВыборгПоПорогу() я мог воспользоваться редко, так как требуется больше одного условия (особенно на тех предприятиях, которые могут позволить себе внедрять 1С ERP). Основной способ описания спецификаций заключался в многократном создании одного и того же материала, но с разными условиями применяемости. 

Как видно из скрина я указываю много раз материал, например, Листовой металл 1.45, но его нормативное количество будет выбрано за счет выполненного условия. То есть я прописываю нормы расхода металла для всех вариантов изделий, но условие сработает только в одной строке в зависимости от габаритов и количества створок (нормы расхода не линейны и усреднены по категориям). Поясняю картинку ниже: количество 56.3 листового металла потребуется, только в случае Высота двери от 0 до 2120 И Ширина двери от 0 до 1030 И Количество створок = 1. Если же высота окажется более 2120 мм, то данное условие не сработает и система перейдет на следующую строку спецификации. 

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

Главное в этом подходе (многократном указании одного и того же материала) не допустить логических ошибок.

Первопроходец

Работая с детальной проработкой процесса в программе иногда понимаешь что находишься в числе первых, кто это делает. 

В проработке клиентского заказа менеджер указывает в свойствах характеристики петли, замки, фурнитуру как номенклатуру из справочника Номенклатура. Создаю свойство «Петли» и автоподбор в спецификации. Но петли идут комплектами и их может быть 2,3,4,6 штук в зависимости от количества створок и пожеланий клиента. Я не хочу (бизнес не хочет) чтобы менеджер занимался расчетом количества петель в конфигурации двери (свойствах характеристик), так как во многих случаях этот подбор можно автоматизировать. В итоге создан вид номенклатуры с типом Набор.

Но дело в том, что заполнение набора (как в примере выше с Петлей, которое является набором) не работает в 1С ERP  (в редакции 2.4, в 2.5 не проверял) и документы Этап производства, Плановая калькуляция не будут содержать заполненные строки. 

Ещё пару слов об НСИ и её важности

Хотите глаз порадовать? Приведу пример образцово-показательного справочника номенклатура (Кабельное производство). Данные структурированы, детально описаны, понятны пользователю.

В спецификациях тоже порядок.

Подобное описание позволяет:

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

Система класса MDM — там, где много НСИ

Если ИТ-ландшафт построен из множества лоскутно-функциональных информационных баз, то построение НСИ должно строиться в специализированных решениях MDM и средств транспортировки данных. Условно видим структуру так:

Это отдельная тема, главное зафиксировать, что порядок всего учета начинается с порядка НСИ. Если баз несколько, то возрастают требования к ведению НСИ. Не стоит выполнять следующие этапы, если не привести НСИ в порядок — хаос множится кратно; трудозатраты работников на обеспечение системы значительно увеличиваются. 

Технологическая и коммерческая НСИ в 1С ERP

Представим, что я как конструктор/технолог прописываю, что изготовить деталь из нержавеющей стали 08Х18Н9. Закупщику попадает информация о потребности и он закупает «Лист 08Х18Н9». На второй закупке листового металла нет (или дороже) и он приобретает «Рулон нержавеющий 08Х18Н9». На третьей закупке новый поставщик поставил тот же металл нержавейки, только указав американского обозначения AISI304. В итоге кладовщик в 1С создал 3 номенклатурные позиции «Лист 08Х18Н9″ в метрах квадратных, «Рулон 08Х18Н9» в метрах погонных, «Металл AISI304» в килограммах. Функционал «Номенклатура поставщика» не всегда подходит, так как с точки зрения управленческого учета — это позиции с разной себестоимостью и единицей измерения и инвентаризационной комиссии сложно будет согласиться с тем, что 30 м^2 + 2 рулона + 100 кг — это 200 кг.

В то же время система начинает спотыкаться и сообщать об отсутствии обеспечения «Лист 08Х18Н9», но фактически она есть на складе в рулоне или в AISI.

А теперь представим что размеры листов могут быть разные, тем самым множим проблему в разы.

Скрин с видео https://youtu.be/46Eig25BcSw

Полагаю, 1С работает над этой задачей технологической номенклатуры. Ну а пока нет лёгкого решения — вы соблюдаете гигиену цифровых данных — актуализируете ресурсную спецификацию, вносите разрешения на замену, комплектуете сущности.

Плановая калькуляция

Это сладкое, что вы можете попробовать на промежуточном этапе — всего лишь после того, как описали НСИ. Скажем так полюбоваться промежуточным результатом и из «непонятных» работ показать Заказчику плановую цену изделия. Правдивости ради вы ещё должны отправиться к экономистам завода — прорабатывать статьи затрат (НСИ) и их расчет (формулы и базы). В целом это несложно, если не затрагивать сложные бюджетные правила.

Документ Установка нормативов производственных расходов позволяет выполнить многие требования экономистов. Например, я установил прочие расходы 8% от суммы материальных затрат, соцвзносы 31,4% от нормативной суммы оплаты труда и другие переменные и постоянные расходы.

Проведение документа Плановая калькуляция позволяет это увидеть во всех плоскостях:

Немного коснёмся более сложного расчета, когда например статья расхода — Премия за перевыполнение плана, как понимаете по названию — расход зависит от объема выполненной работы. Создаём статью:

Данная статья автоматически в плановую калькуляцию не проставиться, но экономист, по результату месяца, проставит статью в нормативы.

Немного о подходе к исследованию бизнес-процессов

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

Прямой метод

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

Обратный метод

Особенностью метода является изучение результата операции (бумажного или электронного документа, файла или события) и поиском автора документа. Далее определяется кто и зачем сформулировал эту потребность. Цикл этих действий определяет БП в обратном порядке. Например, конечным пунктом деятельности по продаже продукции является передача водителю заказчика «Универсального передаточного документа» , ТТН, Материального пропуска. 

Смешанное использование

Подход может использоваться для одновременной работы 2-х аналитиков или сложного процесса.

Архитектура, подсистемы и их моделирование

Смысл который закладывается в ERP — это управление всеми ресурсами предприятий и продукт 1С ERP позволяет это вам делать. Идеальный ИТ-ландшафт, где существует одна база данных без интеграций (но и это неоднозначно) . Созданный бизнес-процесс остаётся в одной среде, например, обязательство по продаже вашего продукта, перетекает сначала в обязательство обеспечить комплектующими и материалами и затем в обязательство производству выполнить это в назначенный срок и плановую себестоимость. На этом не всё — далее начислить и выплатить работникам за труд, а параллельно всё это отражать в бухгалтерском и налоговом учетах, но и это в одной системе. Если нарисовать эту «упрощенную» схему введённых данных к продвижению процесса, то это выглядит так:

Но если у вас большое предприятие и требуется запустить только одну подсистему, например, материально-техническое снабжения (МТО), то с большой вероятностью вы в качестве базового решения будете использовать 1С ERP. А если вы планируете запустить производство, то тут однозначно базовым решением будет 1С ERP. Идем дальше. Если вам требуется запустить коммерческий блок, то базовым решением будет 1С ERP, либо 1С УТ, но это если вы хотите создать слепую зону, где не видно зависимость заказа покупателя от заказа на производство. 

Диссонанс этой схемы и терминологии заключается в том, что единое ERP является суммой программных продуктов 1C:ERP. Обосновать эту схему можно, а иногда и нужно. Но как понимаете:

1. 1С ERP — это законченный по бизнес-процессу продукт. После производства мы не можем затаривать склад, его надо отгружать — следовательно, когда 1С ERP работает по лоскутному типу, то требуется программист-хирург, который будет вырезать связи подсистем. 
2. Интеграции — это всегда слабое место. Тут чаще всего возникают проблемы, особенно там, где передаются сотни реквизитов только от одного документа. Тут нужен ещё один программист-хирург, который сможет это сшить вместе с аналитиком-реаниматологом.

Лоскутная система — это отдельное ТЗ на каждый лоскут, в том числе на интеграции. Для комплексной системы описание подсистемы — это раздел ТЗ. В качестве примера моего любимого производства (потому что производства, а не потому что дверей):

Описание техпроцесса для ФМ

Это уже физика процесса. Простой пример техпроцесса из моего производственного курса учебного центра 1С. 

А это уже реальный пример проработки техпроцесса с описанием функциональных ролей, длительности операций, полуфабриками (в рамках другого производства). Здесь одной из задач стояло повышение производственной эффективности с поиском «узкого» места. Если интересно, то скорость производства составила скорости создания сварочного шва. То есть, можно всё изделие перевести в длину шва и, зная скорость сварки, определить когда будет изготовлена готовая продукция.

НСИ подсистемы

Переходя от общего к частному, в том числе при описании НСИ, происходит детализация процесса, где требуется детально прописать справочники «второго порядка». Например, для пооперационного учёта в 1С ERP требуется (требовалось) вносить справочник «Маршрутная карта», а он содержит ссылки на Операции, Рабочие центры и Виды рабочих центров. Информация полученная при описании техпроцесса воспроизводится в системе.

Документооборот подсистемы

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

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

Трансформация бизнес-процесса в алгоритм (Шаги)

В 1С ERP поведение и проведение многих документов (Заказа клиента, Этапа производства, Реализации и т.д.) зависит от статуса документа. Не в качестве справочной информации статусов (для этого вам надо ознакомиться в руководстве пользователя), а в качестве примера влияния статусов Этапа производства:

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

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

В содержании вы можете видеть пошаговое описание процесса. Представлю пример шага с постановкой технической задачи.

Текстовое описание шагов по своей сути после запуска системы в эксплуатацию является инструкцией пользователя.

Алгоритм может быть только текстовый по шагам (фрагмент выше), блок-схема (фрагмент ниже) или комбинация блок-схема с описанием. 

Технические задачи

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

Финал

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

Это было интересно, сложно и немного с ностальгией по временам этого фото. Так сказать заключительная командировка — уложился в срок, если вы понимаете о чём я 🙂