Введение
Хотелось бы поговорить про ERP системы в 2022 году, и можно было бы здесь описать статьи из wiki про то, что такое ERP система общими словами и многое другое, но я не про это, а про то, есть ли вообще место ERP системам в современно микросервисном мире.
Зачем?
Первое что хотелось бы спросить про такой громкий заголовок это "А зачем?" и на мой взгляд это очень правильный вопрос т.к. с нулевых годов витала постоянно мысль, что ERP очень важная штука для более менее приличной компании, у которой есть какие-то операции, склады, учет и тд. НО! На самом деле технологический мир очень сильно изменился с тех пор и если кратко ответить нужна ли ERP, то НЕТ, она действительно не нужна, тк потеряла свою значимость ведь какой раньше был смысл такой системы?
Почему было так
Какие основные причины были раньше:
Все в одном окне;
Все данные связаны в одной системе и потенциал ошибок маленький;
Много кансалтеров SAP, 1c, Axapta и проч.;
Сложно сделать самому, нужно инвестировать большие средства в команду и бизнес аналитиков;
Большое количество модулей из коробки охватывающий много потенциальных бизнес процессов ( учет, склад, логистика, закупки, производство и тд).
На мой взгляд самое большая причина была в том, что бизнесу казалось, что создавать продукт управления бизнесом это что то экстраординарное и трудоемкое, и это было так, тут не поспоришь, и инерция такого умозаключения осталась....
Что такое ERP
Если посидеть, подумать, и разбить все основные модули классической ERP на функциональные блоки то у нас будет такая структура:
Закупки - отвечающие за то, что мы покупаем;
Учет - всем нужен учет :);
Логистика(склад) - учитывать товары многим нужно;
Сбыт - модуль продаж;
HR - модуль учета сотрудников (достаточно опциональный модуль);
В большинстве случаев это и есть картина классической ERP в бизнесе, но пройдемся по каждому из них и попробуем разобраться из чего они состоят
Закупки - это модуль управляющий закупками компании, давайте заглянем внутрь и посмотрим что должно быть внутри такого модуля
Товар и услуга - ну без него не обойтись, мы же что то закупаем,
Поставщик - мы у кого то покупаем,
Прайс-лист(опция)- не всем это нужно, но в целом давайте его добавим,
Склад(опция) - куда мы хотим этот товар закупить,
Контракт - без контракта в РФ ничего нельзя закупать в целом, поэтому его тоже нужно вести,
Менеджер - тот кто закупать,
Заказ - Сам обьект заказа в котором все вышеперечисленные поля заполнены и есть табличная часть с товарами, по сути это основной и наверное единственный динамический обьект модуля закупки, остальное можно считать мастер-данными,
Счет фактура - Invoice те подтверждающий документ о поступлении товаров.
Я не буду разбирать каждый обьект модуля тк это избыточно и может быть наполнен разными атрибутами, типами и свойствами уже зависящих от специфики работы компании.
В целом на этом все, что бы создать модуль закупки нам действительно нужно создать только эти обьекты
Флоу закупки выглядит примерно так:
Менеджер закупки создает поставщика, заводит контракт, создает заказ на закупку и отправляет поставщику его по edi или почтой, это уже средство доставки
Потом приезжает машина и уже от компании зависит кто вводит подтверждение что заказ пришел, вводит количество, в разных компания по разному, у небольших это один и тот же человек, а в других это работник склада получателя в wms системе или так же в заказе созданным менеджером
Далее сотрудник работающий с первичкой вводит Счет фактуру
А теперь самое главное и ВАЖНОЕ в любой ERP системе - создать транзакцию
Транзакция - это сведение о том, что товар или услуга поступила и она несет в себе самую важную для компании информацию - локация, стоимость, товар/услуга.
Любая хозяйственная операция в ERP системе должна и обязана быть учтена как количественно так и финансово, люди которые думают, что важно просто создать удобный интерфейс закупки и работы с ним это главное, но главное на самом деле это транзакционный лог хозяйственных операций, и по факту это и является основной работой ERP системы, которая и должна учитывать любой чих компании в виде финансовой операций, и бывают транзакции в виде:
Тип | Локация | Продукт | Кол-во | сумма |
Приход товаров | Склад 1 | Печенько | 5 | 25 |
Продажа | Склад 1 | Печенько | -2 | -10 |
Стронирование прихода товаров | Склад 1 | Печенько | -5 | -25 |
Отражение оплаты | Склад 1 | Печенько | 5 | 50 |
Что тут происходит:
Пришел товар Печенько в количестве 5 шт на сумму 25, далее мы продали товар и со склада ушли 2шт товара по стоимости из предыдущей транзакции 10, далее бухгалтер ввел счет фактуру, в которой стоимость печенек стало не 25, а 50, поэтому транзакционность должна быть отсторнированна и скорректирована, и так же на каждом этапе транзакции понятна себестоимость продукция равная сумме сумм поделенное на сумму количеств в каждом моменте времени.
Это примитивный пример, но от отражает основную суть - каждое действие в компании (приход, расход, списание, потери, продажа, инвентаризация, и тд) должно быть выражено с помощью финансово-количественной записью для того, что бы в любой момент времени компания понимала состояние ведение своего бизнеса, в разрезе бизнес юнитов, хозяйственных операций или кагорт товаров и прочими разрезами.
Итак, мы поняли что происходит в закупках, давайте разберемся в следующем модуле
Учет - это модуль бухгатера, помогающий отражать первичные документы, выставлять счета на оплату, управление счетом в банке и прочее, в целом он состоит из таких обьектов как:
Инвойс - это по РФ счет-фактура, или ПТУ или АКТ выполненных работ, те документ отражающий хозяйственную операцию;
Банк - Если система интегрируется с банковскими сервисами;
Платежные поручения - документ отражающий заявки на оплату, например поставщику;
Бухгалтер - пользователь который этим ведует.
И так же как и когда закупщик или склад принимает товар и создается транзакция, так и при вводе инвойса(счет фактуры) происходит транзакция на основе Заказа к поставщику, далее производится оплата с помощью платежного поручения на основе счет фактуры и уходит в банк, а из банка в дальнейшем придет подтверждение, которое с помощью конектора с банком возвращается в систему и процесс закрывается, налоги рассматривать не будем.
Сбыт - модуль сбыта это практически зеркальная копия модуля закупки, только там заказ на продажу, а инвойс не приходит, а выставляется, можно сказать это по сути одинаковые модули, но документы ведут себя наоборот, товар не приходит, а уходит, деньги не уходят а приходят :)
Есть еще более специализированные модули, такие как бюджетирование, производство, маркетинг. Но решение этих задач сложно обобщить, они требуют индивидуальной разработки.
Другие модули я разбирать не буду статья про подход, а не про каждый из них
Промежуточный вывод из примеров
Каждый из модулей ERP в целом содержит несколько уникальных сущностей, но так же имеет общие свойства такие как:
Пользователь - есть у каждого основного документа,
Транзакции - те каждый из модулей генерирует транзакции,
Локации/Склады - почти каждый модуль работает с локациями компании,
И прочие, которые не разбирали.
Какой вывод можно сделать:
Что данный функционал является общим для все и его нужно разрабатывать первостепенно и начиная именно с него, а не с модулей непостредственного ведения бизнеса
Все модули это средства для достижения только 1й цели - создать финансовую транзакцию, И при разработке ERP системы менеджер продукта создающий ее или тим лид команды должен думать только об этом, тк цель всей системы это посчитать все операции и уже предоставить руководству правильные данные, но почему то часто при разработки таких систем об этом забывают.
Что изменилось с 00х
После эпохи классических ERP таких как SAP, 1c, Axapta и проч. изменилось очень многое:
DevOps - стал доступен, те сейчас можно просто купить услуги инфраструктуры у разных компаний и довольно по доступной цене, те не нужно нанимать в штат классических админов и не понимать что же они там делают в своей коморке)).
Развитие web сервисов - сейчас появилось бесчисленное множество платформ для создания веб приложений, на основе которых можно быстро сделать атомарное приложение для бизнеса в тч одно из вышеописанных, где время от ТЗ до MVP будет аля пару месяцев.
Появилось очень много людей, которые знают как правильно создать бизнес приложение.
План действий
Итак мы проговорили, что ERP система это не такая уж умная и недосягаемая штука, которую можно сделать бизнесу самому не привлекая дорогущий консалтинг, ичто нам для этого понадобиться
Самое наверное важное это найти человека который может - это действительно самая важная часть, тк человек, который знает как декомпозировать такую большую задачу как создать ERP на много маленьких и понятных.
Уже нанятому и знающему человеку выбрать платформу, их на самом деле не мало и они отличаются очень кардинально, и тут главное исходить из многих факторов, сроки, функциональности, доступность на рынке разработчиков и проч.
Выбрав платформу декомпозировать на задачи.
Немаловажный пункт второй и тут как раз мы подходим к заголовку статьи - выбор платформы очень важная часть нашей задачи и здесь я упомяну такую платформу как Odoo, она позволяет как говорят - быстро стартануть ввиду уже готовых модулей, что я описал выше, ее можно сравнить с 1с УТ из мира 1с, все в коробке и осталось разобраться как ее варить. Но и упомяну и основные минусы готовых модулей, таких как уже готовые модули из коробки по моему опыту:
Слабо оптимизированны для нагрузки.
Архитектура не самая лучшая для развития и доработок.
Слишком много зависимостей.
Мало разработчиков на рынке знакомые с платформой.
Причем эти минусы относятся почти ко всем коробочным решениям с готовыми модулями
Плюсы
На начальном этапе совсем не нужен фронт, фронт генерируется автоматически, и это позволит существенно сократить бюджет.
Очень много уже платформой заложеных бизнес функций, такие как работа с валютой или логистические операции, или работа в excel и word и многие другие которые являются практически обязательными в Бизнес приложениях.
Много технически батареек нацеленные на бизнес данные.
Много готовых решений (но на них надо очень внимательно смотреть).
В целом Odoo это на мой взгляд очень хорошая платформа для написания почти любого бизнес приложения любой сложности и позволит бизнесу разработать любую функциональность применив наименьшее количество ресурсов
Итог
Данная статья нацелена скорее на бизнес сегмент людей и обьясняет, что любой бизнес продукт можно сделать своими силами и внутренней командой, тк создание даже больших систем не является непостижимой задачей, как и везде главное люди и прежде чем смотреть в сторону покупки "коробки" стоит рассмотреть вариант с созданием собственной системы, в которой можно реализовать практически любой функционал, а не то, что в коробке предлагают.
А хорошо декомпозировав задачу можно сделать приложение на любой современной платформе Django, Odoo, Flask, JavaSpring и другие. и стоимость для бизнеса в среднесрочной и долгосрочной перспективе будет гораздо ниже, при условии конечно качества команды и самого бизнеса.
