Как я писал ТЗ на внедрение 1С:ERP

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

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

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

Введение

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

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

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

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

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

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

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

Готовое решение

Пульт управления производством для 1С:УНФ

Используйте готовое решение для автоматизации бизнес-процессов производства на основе 1С:УНФ

Узнать подробнее

В предпродажной переписке и выставлении коммерческого предложения опыт имел значение, общение с производственниками на одном языке дало старт написанию Функционального моделирования для 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  "Использовать параметризацию ресурсных спецификаций и маршрутных карт".  Возможность такая есть, но без приключений не обойдется.

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

Начнём с более простого - ВыборПоПорогу(<Параметр> <Значение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% от суммы материальных затрат (0.08 копеек на 1 рубль), соцвзносы 31,4% (3,14 рубля на 10 рублей.) от нормативной суммы оплаты труда и другие переменные и постоянные расходы.

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

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

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

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

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

Прямой метод

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

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

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

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

Подход может использоваться для одновременной работы 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 провел инвентаризацию с учётом перемещения излишков на склад, рассчитал себестоимость продукции и сделал план-фактный анализ. Получение финансовых показателей после комплексной детальной проработки подсистем приводит к положительным впечатлениям. Протокол демонстрации, представленный в начале публикации, как раз об этом моменте.

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

Мои практические примеры ФМ в режиме видеозаписи

Для 1С:ERP

Для 1С:УНФ