В предыдущих 2 статьях (статья 1, статья 2) я рассказал, как с помощью 5 артефактов полностью описать ERP систему будь то 1С или SAP, на русском или китайском языке.
Бизнес‑процессы
Функции
Инструкции
Объекты метаданных
Требования
С помощью их дополнительных аналитических разрезов контролировать множество ИС большой группы организаций
Проект
Топик
Слой
Проектный документ
Организация
Графическая схема
Backlog
Заказчики
Полученные данные можно крутить‑вертеть, модифицировать новыми требованиями и все равно модель будет стоять на прочном фундаменте и не позволять аналитикам запутаться. Если вы не прочитали эти статьи — настоятельно рекомендую ознакомиться с ними — так будет более понятна проблематика этой. Как и следовало ожидать — это были не просто теоретическое рассуждение — это методологическая основа, заложенная в мой авторский программный продукт ERP‑tools. Ввиду глубоким недовольством MS office вся работа команды от аналитика/разработчика до руководителя проекта была перенесена в единую программу с 3 мощными подсистемами.
На самом деле я люблю Excel, но в него слишком легко добавлять колонки исходя из конкретного случая, а когда разрабатываешь Методологию — приходится все стандартизировать. Центральное ядро «Функциональное моделирование» прошло множество циклов потребность‑реализация‑анализ и уже к окончанию первого пилотного проекта перехода с SAP на ERP УХ его удалось привести к сбалансированности — к вот именно этой картинке.
А проекты с его применением
Программно‑методологический комплекс ERP‑Tools является единственным инструментом внедрения и поддержки ERP систем с незасекреченной методологией и публичными описаниями и демонстрациями, который можно купить. Одно из последних опубликованных видео — автоматическое выявление функциональной модели в уже работающей ERP системе и этот кейс может быть интересным не только в переходах на 1С ERP, но и компаниям, которые уже перешли на 1С ERP как с помощью интеграторов, так и самостоятельно. И увы, в обоих случаях часто наблюдаются следующие проблемы
Получен файлоархив проектных документов значительного объема — под тысячу страниц текстов, картинок, которые совсем не востребованы теми, кто управляет проектом после начала промышленной эксплуатации
Нарисованные UML, BPMN диаграммы представлены в виде png картинок, то есть непригодны для будущей модификации
В момент ОПЭ продолжалась модификация решения без редактирования «Функциональных моделей» и с каждым месяцем полученный красивый файл становится все менее надежным источником
Текущая разработка плохо организована и часто идет не по ТЗ, а по сообщениям в чатах
Обновление вендора становится проблемой, так как непонятно — что сломается из доделок проекта
Отсюда простой вывод — начало промышленной эксплуатации является фактическим началом Проекта, а все что было до него — это предпроектные работы. И даже если вы наняли Интегратора — вы столкнетесь с тем, что поддержка ERP является сложным и дорогим делом. Часто заказчики просто не готовы остаться один на один с конфигурацией и проблемы с закрытием месяца начинаются, как только интегратор покинул проект. Отсюда такой большой процент недовольных от внедрения ERP.
Реальный кейс
К нам обратилась компания ‑производственный бизнес среднего размера с просьбой довнедрить ERP после одного из крупнейших интеграторов, которые почему‑то не смог завершить проект. Давайте спокойно проверим проектную документацию, оставленную клиенту.
Пример документации не очень успешного проекта
Внедрение произошло в январе 2026 года и ни один месяц до сих пор на закрыт, и заказчик всерьез обсуждает вопрос «отступить» обратно в 1С БП 3.0 На просьбу предоставить инструкции пользователям федеральный интегратор предоставил архив видеозаписей встреч аналитиков с бизнесом и посоветовал посмотреть и все подробности оформления увидеть там. Как я писал в 1 статье — инструкции являются самым узким местом — практически никто их не делает. Что же в итоге дал федеральный интегратор своему клиенту? Вот такую таблицу с его процессами. Здесь и далее все картинки переработаны ИИ чтобы убрать действительные клиентские данные, но сохранив их суть. Названия колонок не изменены. Но события и процессы довольно стандартные.
Уже на этом этапе возникает вопрос: это действительно результат применения единой методологии или рабочая таблица, созданная случайным образом для этого проекта? Выделено 3 вида Бизнес‑процесса
Глобальный процесс
Бизнес‑процесс
Процесс
И отдельно
Операция в ERP
При этом глобальных процессов — 11 штук и их примеры
Проработка условий на оказание услуг ГОЗ
Выполнение работ по договору оказания услуг/выполнению работ ГОЗ
Завершение работ по договору оказания услуг/выполнению работ ГОЗ
Бизнес‑процессов — 65 единиц и их примеры
Перевод ориентировочной стоимости работ в фиксированную цену
Закрытие работ по услуге
Потребность по доходным договорам
Коммерческое предложение по доходным договорам
Договор и счет по доходным договорам
Первые три это некое действие, напоминающее Процесс, последние 2 — просто название объектов системы. Почему закрытие работ по услуге отдельно от открытия — непонятно. Какая граница разделяет Глобальный процесс от обычного?
Просто Процессов — 270 единиц
Передает информацию о потребности в выдаче средств
Формирует перечень заявок на выдачу средств для согласования
Запускает процесс согласования
Согласуют служебную записку и заявки на оплату ОХР/ОПР в Excel
И примерно 80 строк уникальных действий в ERP
Загрузка поступлений из банка, Ввод Поступления безналичных денежных средств, Ввод счет‑фактуры выданной (аванс)
Ввод карточки ресурсной спецификации
Заполнение карточки ресурсной спецификации, Ввод номенклатуры, Ввод Видов работ сотрудников
Правда действий больше, но как поступить — если на 1 Процесс в Excel есть только 1 ячейка? Правильно — 2 действия поместить в одну ячейку через запятую. Наличие в ячейках формул говорит о том, что это не выгрузка из специальной базы (например, СППР).
Все действия по фильтру «спец» (так я пытался найти все упоминания Ресурсных Спецификаций)
Ввод карточки ресурсной спецификации
Заполнение карточки ресурсной спецификации, Ввод номенклатуры, Ввод Видов работ сотрудников
Корректировка ресурсной спецификации
Чем ввод отличается от заполнения? Это точно все действия с ключевым справочником на промышленном предприятии? Ни одного упоминания спецодежды, спецостастки. И это не инструкция, просто общее название действия в 1С.
Целых 80 действий в ERP, а всего таблица содержит — солидных 700 строк? О чем 620 строк (точнее 279 без указания действий ERP )? — Аналитики провели большую работу и зачем‑то описали бизнес‑процессы, не покрываемые ERP системой и нарисовали 50 диаграмм последовательности в формате png. Уверен что для этого в штате есть специальный Технический писатель. Почему бы не передать заказчику исходные файлы?
Получается парадокс: большая часть описанных событий происходит за пределами ERP, тогда как непосредственно работа пользователей в ERP описана значительно слабее.
Что можно сделать по нашей проектной методологии
Провести анализ задействованных объектов метаданных текущей системы. Пользователи даже без инструкций что‑то делают. Это полезно и не отнимет времени на интервью
На основании практики прошлых проектов составим перечень функций системы — реальных действий пользователей в ERP. Все что за ее рамками мы либо проигнорируем, либо укажем непосредственное событие как основание для функции: Получили факс (внешнее событие) — Создание Заказа клиента (функция системы).
Быстро упакуем полученный массив функций. В среднем мы регистрируем от 500 до 700 функций на производственных предприятиях (против 80) и упаковываем их в примерно 100 бизнес‑процессов по примерно 10 функциональным разделам: Продажи, производство, закупки и так далее
Только на этом этапе обратимся к бизнесу и уточним — какие процессы у них вызывают вопросы и по их функциям составим подробные визуальные инструкции с пошаговым выполнением и обязательно обучим сотрудников. Тут мы выявим функции, которые вообще не выполняются и, допустим, остались в Excel. Очевиден большой методический провал в учете затрат и их распределении для корректного расчета себестоимости. Все‑таки придется пересматривать видео встреч, чтобы не отвлекать пользователей.
По документам интегратора складывалось впечатление, что внедрение было без доработок. Но это не так — просто доработки делала другая компания. И на этом этапе нужно выявить модификации объектов метаданных — это просто. Достаточно посмотреть на новые объекты, новые реквизиты. По каждому из них сформировать требование — это даст картину — что именно дорабатывалось. С модификацией бизнес‑логики чуть сложнее, но все точечные изменения также нужно сформулировать в качестве Требований. В любом случае в таблице нет никаких столбов, где говорится о наличии доработки. Если бы таблица интегратора была стандартной (по их Методологии) — то колонка бы сушествовала и была бы не заполнена с комментарием «вне рамок проекта». Еще одно доказательство, что методология отсутствует и перед нами обычная рабочая таблица руководителя проекта.
Так, за пару недель становится возможным провести функциональное моделирование полученной ERP системы и взять ее под контроль, особенно область доработок. Выявив существующие, предприятие сможет выполнять новые, но уже по Методологии, подробно описанной в статье 2.
Даже если проект небольшой и не очень выгодный — он все еще достаточно дорогой для конечного заказчика и это не значит, что его не нужно должным образом оформлять.
Будем держать вас в курсе проекта, а если вы хотите провести аудит вашего проекта и быстро сформировать его ОКИС (операционная карта информационной системы) — обращайтесь. Будем рады помочь
Emelian
А удачные, бывают в природе? Если да, то, почему бы их не разобрать?
Как говорил обергруппенфюрер Мюллер штандартенфюреру Штирлицу: «Верить никому нельзя! Мне можно!».
Вы точно уверены, что вам можно верить?
«Бороздить космические просторы Вселенной» мы все – горазды, но, возьмем задачу попроще, тем более, что вы претендуете на универсальность. Средняя производственная фирма, порядка 1000 человек сотрудников. Главная проблема – учет заработной платы и учет ресурсов, поскольку типовые конфигурации не давали нужного функционала. Основные требования – внешняя отчетность, с которыми типовые конфы не слишком дружили. Другая проблема – неудобство работы в типовых конфигурациях, поскольку они всегда делались и делаются по принципу: «Нам с ними не работать!» и «Наши конфы не поддерживают ваши бизнес-процессы? Меняйте свои бизнес процессы! Ради вас мы типовые конфигурации переделывать не будем!». Третья проблема – преемственность и стоимость проектов внедрения и сопровождения. Особенно, если фирма не готова платить заметные деньги на автоматизацию собственного учета, просто потому, что их у неё нет. А преемственность потребовалась при переходе от украинского учета к учету по законодательству ЛНР, а затем и РФ (самая жестокая боль – смена Плана Счетов на ходу).
Разве можно было бы решать подобные проблемы (дешевизна, удобство работы, удовлетворение всех хотелок главбуха по внешней и внутренней отчетности и всякого рода клиент-банков, зарплатных проектов, заодно, попутно, легкий учет рабочего времени, быстрый переход с одного законодательства на другое и т.д. и т.п.) решить в рамках стандартных конфигураций, хоть с ERP или без него?
Так что, все ваши конструкции у человека, который кормился порядка двадцати лет на собственной системе учета, финансово совершенно не обременительной для фирмы, вызывают лёгкую улыбку.
С таким подходом, я бы далеко не уехал.
У фирмы «1С» самое главное достижение – это платформа «1С77», реально, система быстрой разработки, аналогов которой не существует. Благодаря ей, мой первый рабочий прототип учета заработной платы «взлетел» уже через три месяца. Да, потом я его еще, около двух лет, шлифовал, с утра до вечера, но при этом система постоянно работала на реальном производстве, все шероховатости и претензии я быстро устранял.
Затем я разработал и внедрил учет ресурсов. Единственное, что более-менее работало в наших условиях – это «ПУБ (Производство, Услуги и Бухгалтерия) для Украины», которую я затем адаптировал для «ПУБ для ЛНР,» а затем постепенно интегрировал в «ПУБ для РФ».
«Зарплата» у меня всегда была автономной, а оперативный учет новая главбухша перевнедрила с моего «Учета Ресурсов», на «ПУБ для Украины», что заметно отразилось на удобстве учета. Как она говорила: «В ПУБ я играть умею, а в твой Учет Ресурсов – нет!». А вот «зарплату», при всем своём желании и моей искренней помощи (я ей нашел в Интернете порядка десяти программ, включай ЗУП) она перевнедрить не смогла. Ибо наши бизнес процессы не соответствовали типовым.
Что я могу сказать по методологии учета в типовых? На мой взгляд, она не оптимальна. Фирма «1С» стремиться не к легкости, простоте и красоте, а к банальному зарабатыванию «бабосов».А разве на простой и понятной программе заработаешь лишние монгольские тугрики?
Не оптимальны не только типовые конфигурации, но и сама платформа «1С». Сколько я себя помню, всегда хотел создать собственный вариант а-ля «1С77», вроде «2С» (этот опенсорсный проект реально существует, написан на C++ / MFC, как и оригинальная платформа, но развития не получил, да и концепция там была реализована так себе). Может быть, с использованием «Искусственного Идиота», когда-нибудь вернуть к этой идее.
Про «восьмерку» («1С8х») и говорить не приходится. Её девиз: «всё усложняем, усложняем и еще раз усложняем!», чтобы в итоге родить монстров типа: «1С:ERP» и «1С:MES». Да, на «восьмерке» можно неплохо зарабатывать в силу её сложности, поэтому, если бы я начинал свою карьеру сейчас, заново, то выбрал бы её.
Но, скорее всего, пошел бы по такому пути:
• Покупаем лицензионную версию выбранной типовой конфигурации (в рамках среднего предприятия).
• Весь реальный внутренний учет ведём не в «Экселе», а в «1С77», в 100%-но собственной конфигурации.
• В официальную «1С8х» экспортируем свои данные из «1С77», с помощью собственной обработки «КД» («Конвертация Данных»), поддерживающей и обратный импорт.
• Формируем официальную внешнюю отчетность и сдаём её, включая всякие разные там: электронные больничные листы и трудовые книжки, отчетность в Налоговую, Пенсионный Фонд, Статистику и т.д. и т.п.
Я начал было идти по этому пути, но нашу фирму (после перехода под юрисдикцию РФ) приобрёл новый собственник, а у него оказались свои представления о «прекрасном», поэтому, фирму он ликвидировал. Ибо, «капитализьм», блин. А в социализм мы вернемся еще не скоро (лет через десять, не раньше).
Так что чужая система это хорошо, но если она сильно жесткая, сложная и малоудобная, то лучше поискать более дешевые и комфортные альтернативы, хотя бы рамках продуктов фирмы «1С».
Так что Мюллер был прав: «Верить никому – нельзя! …» :)