ERP-системы *

Меня зовут Алексей, я скорее инженер, чем разработчик. Занимался производствами, конструировал приборы и в какой-то момент решил попробовать сделать универсальный конструктор для учёта всего, что мне было нужно на производстве — материалов, заказов, процессов, планирования сроков и т.п.

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

Решение было принято под влиянием моды того времени на открытые системы: стартапы получали по 10 млн баксов под таблички без функционала, но зато с MIT-лицензиями, проводились конференции, изо всех утюгов неслось, как здорово на сопровождении все зарабатывают миллионы...

В общем, начитавшись всей этой чуши, поставили MIT, залили на GitHub, написали статью на Хабр — и... получили поток комментариев: «Ваш код — УГ» и «Всё надо переделать на Laravel».

В итоге, потратив охулиард нервных клеток и набрав 900 звездочек на GitHub, я бросил это опенсорсное занятие и поставил самые обыкновенные платные лицензии.

Стремительное развитие информационных систем и технологий породило некогда считавшуюся немыслимой ситуацию: завершение использования программного обеспечения стало обыденностью и возможностью для компании повысить свои конкурентные преимущества. Как бы парадоксально это не звучало, но сейчас дела обстоят именно так. Изначально жизненный цикл программного обеспечения предполагал прохождение ряда состояний, включающих пред-проект внедрения, проект имплементации и пост-проект, на которых доказывалась целесообразность продукта, велась разработка, а далее – поддержка и развитие. До недавнего времени все шло именно так, а сопровождение и развитие решения могли выполняться годами.

Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап.

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

С помощью электронного документооборота физические лица могут получать госуслуги, устраиваться на работу, поступать в ВУЗ, оформлять кредиты, не выходя из дома. Организациям данный механизм позволяет сокращать издержки, связанные с созданием, обработкой и пересылкой документов. Электронный документооборот ускоряет и упрощает процесс обмена документами между компаниями и государственными органами. Более того, подключение к системам ЭДО сейчас нужно не только для удобства, но и в отдельных случаях является необходимостью: некоторыми документами можно обмениваться только в электронном виде. Системы ЭДО требуется для работы с маркированными товарами, прослеживаемостью, маркетплейсами и электронными торговыми площадками, для сдачи отчетности в ФНС и в другие государственные структуры.

Представители бизнеса часто спрашивают, какую информационную систему выбрать. И у меня нет ответа на этот вопрос, ведь все компании разные и, не понимая требований к информационной системе, рекомендовать ИТ‑решение нельзя.

Сразу хочу сказать, что выбор ИТ‑решения — это не техническая задача, а бизнес‑решение, и принимать его нужно не на основе данных в маркетинговых презентациях ИТ‑поставщиков, а на основе прозрачной методологии. В этом материале хочу рассказать о подходе к выбору ИТ‑решений. А уже использовать его или нет — решать вам.

История началась в далеком 2016 году, когда у меня был небольшой свечной заводик. Не свечной, конечно, но все же производство — и нужно мне было на нем сделать автоматизацию. Чтобы компоненты закупались вовремя, списывались со склада в правильном количестве и автоматически планировалось, какие операции делать в рамках рабочего дня. Тогда я впервые подумал, что неплохо бы иметь программируемый конструктор — что-то типа MS Access, но только в web и чтобы логика и запросы программировались одинаково и понятно.

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

Для оправданного участия компании в open source недостаточно одной только публикации кода. Необходимо заниматься множеством связанных аспектов: от маркетинга и обучения аудитории до управления сообществом и взаимодействия с партнерами. Все эти вопросы сегодня активно обсуждаются не только на ИТ-площадках, но и в научной литературе по теме, например, в рамках специальных управленческих фрейворков и концепций.

Однако сегодняшнем материале мы посмотрим на open source-подход с прикладной точки зрения. Делюсь продолжением разговора на эту тему с Михаилом Скворцовым, основателем MK.Lab и сопредседателем консорциума Rudoo, а также Сергеем Коробковым, соучредителем ИнфЦентрПроект и КиржачТелеком.

Недавно у меня был небольшой спор с экономистом клиента. Речь шла о том, как понять — сколько должно стоить изделие. Экономист утверждал, что чем тяжелее по весу изделия или, чем дороже материалы, тем оно должно быть дороже. Я же утверждаю, что стоимость изделия никак не связана с весом или стоимостью материалов, а связана с узким местом компании.

Итак, у нас две принципиальные ситуации с ценообразованием.

Привет, Хаброжители! Сегодня мы делимся с Вами переводом статьи о распределенном монолите.

Аннотация
Привлекательность микросервисов — гибкость, масштабируемость, отказоустойчивость — часто ведет организации по пути, полному непредвиденных опасностей. В этой статье раскрывается обманчивая архитектурная ловушка: распределенный монолит. То, что начинается как, казалось бы, разумный паттерн проектирования для отделения бизнес-логики от технических проблем путем централизации «основного домена», незаметно превращается в антипаттерн, который сводит на нет все преимущества, обещанные микросервисами.

Мы подробно описываем коварные симптомы: кошмары версионирования, паралич развертывания и эрозия автономии команды. На ярком примере из реальной жизни — системе «Drive» и доставки на дом Carrefour — мы раскрываем основную проблему: внутреннюю модель, удерживаемую внешними стандартами. Затем мы раскрываем освобождающие решения: принятие по-настоящему нативных бизнес-моделей и разрыв цепей общих «основных» библиотек кода в пользу явного промежуточного программного обеспечения и надежных API-контрактов. Это путь не только к коду, но и к возвращению обещаний микросервисов.

Внедренный программный продукт подлежит дальнейшему развитию, причин для которого достаточно: изменение законодательства, технологические тренды и новинки, цифровизация не автоматизированных областей и др. Часто подобные активности над ИТ‑системами связывают с запросами на изменение (ЗНИ), относящимися к процессу управления изменениями. Это действительно так, однако работа с ЗНИ требует выстраивания регулярных бизнес‑процессов, вовлекающих как бизнес‑пользователей, так и технических специалистов, обеспечивающих надзор над корпоративной архитектурой предприятия и соблюдение целостности существующих ИТ‑сервисов. Для чего согласно EABoK [4] организуются следующие организационные сущности:

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

Невозможно своевременно выпускать заказы в хаосе. Только случайно. Для начала нужен просто порядок. На основе порядка можно построить качественное управление. Результатом качественного управления как раз и будет своевременный выпуск заказов. А там глядишь и запасы даже станут пониже.

Что же необходимо, чтобы был порядок. Да много чего, но я перечислю основные задачи.

Жизненный цикл программного обеспечения включает в себя множество этапов. Так в работе [1] выделяют активности по предпроектному обследованию, внедрению программного обеспечения и непосредственно пост-проекту имплементации. Этап поддержки и развития относится к пост-проекту внедрения и призван обеспечить непрерывное функционирование разработанной и запущенной в продуктивный режим работы программной системы. По большому счету, это именно тот результат, который изначально ожидается от реализации любого программного продукта: его постоянное и качественное функционирование для удовлетворения нужд пользователей и достижения стратегических целей предприятия.

Существует множество различных сводов знаний, применимых к комплексным программным системам: PMBoK для управления проектами, BABoK для бизнес-анализа, BPM CBOK для управления бизнес-процессам, EABoK для управления кооперативной архитектурой, а также SWEBoK по программной инженерии. Практически во всех сводах знаний делается акцент именно на внедрение и смежные активности, забывая про то, что имплементация программного продукта завершается его передачей в поддержку. Одним из немногих литературных источников по данной тематике является ITIL [2], описывающий четыре домена знаний, позволяющих осуществлять сопровождение решения после его реализации.

В контексте BABoK и расчета бизнес-кейса, выполняемого при предпроектном обследовании, довольно часто рассчитывается показатель TCO (Total Cost of Ownership, совокупная стоимость владения), демонстрирующий постоянные и переменные затраты, которые понесет компания при внедрении программного обеспечения. Одной из постоянных статей затрат является сумма поддержки и развития информационной системы. Таким образом, знание особенностей выполнения этапа поддержки и развития программной системы позволяет рационально планировать затраты и разумно ограничивать содержание проекта имплементации.

Динамические списки использование в разработке редактирования документов выпуска продукции в ERP (часть2)

В статье мы, команда Внедренческого центра «Раздолье», обобщили опыт внедрения 1С:ERP на двух процессных производствах из разных отраслей: пищевой и химической. На их примере руководители проектов постарались описать схему комплексного подхода к автоматизации на подобных предприятиях с охватом важных этапов — от планирования до точного выполнения сменных заданий и обеспечения материалами. 

Для ускорения работы складов мы использовали автоматизированные рабочие места с терминалами сбора данных (ТСД). Предусмотрено автоматическое формирование отчетов и интеграции с системой «Честный знак» для маркировки продукции. По завершении проектов автоматизированным компаниям удалось полностью исключить работу диспетчеров в Excel и с документами на бумажных носителях. Это привело к снижению риска ошибок, более эффективному управлению запасами и росту производительности. Хотя эта статья не является пошаговым учебным инструктажем, все же многим будет полезна.

Когда тебе кажется, что ты уже видел всё в мире корпоративных внедрений 1С, приходит крупная лизинговая компания и говорит: «А давайте сделаем ERP на базе 1С:Бухгалтерия 3.0, но так, чтобы всё было заточено под наши уникальные процессы, ФСБУ-25, МСФО, сложные лизинговые схемы, кредиты, страхование и прочие радости жизни». К этому вызову добавляются сложная релизная политика, требование бесшовной интеграции с действующими смежными системами и жёсткие стандарты качества, которые невозможно было обеспечить без полноценного покрытия автотестами. И вот тут начинается настоящее веселье.

Привет, меня зовут Гродская Ольга, я технический менеджер проекта, и мы в К2Тех за два года переработали типовую 1С:Бухгалтерию 3.0 и превратили её в единую ERP-систему для крупной лизинговой компании. В проекте: 250 доработок, 70 автоматизированных бизнес-процессов, 10 интеграционных потоков, переход на инвестиционную фазу в МСФО, сквозная автоматизация казначейства, лизингового портфеля, кредитов, страхования и др. Результат — поэтапный отказ от старых систем, рост точности отчётности и сокращение трудозатрат большинства служб.

Как аналитикам, продуктовым менеджерам и разработчикам избежать хаоса при переходе на новую ставку НДС (22%) с 1 января 2026 года.

С 1 января 2026 года нас ждет ключевое налоговое изменение: ставка НДС повышается с 20% до 22%. Законопроект уже внесен в Госдуму, и компаниям пора готовиться. Для IT-специалистов, чьи системы так или иначе работают с финансами, это не просто новость, а полноценный проект с жестким дедлайном.

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

Несмотря на упоминание различных способов разработки программных систем, существует три классические модели, применимые в том числе для внедрения коробочных программных решений [1]:

Часть 1. «Цифровая пена» всё сильнее затягивает

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

С другой стороны, начиная с 30-х годов прошлого века, изменения в производственных системах, развитие компьютеров и аналитики, а также миллиарды долларов, вброшенные в консалтинг, породили вокруг бесконечное количество информации, моделей, систем, программных продуктов. Часто начинает казаться, что современные руководители, просто тонут в этой «цифровой пене», не всегда понимая, как соединить «теплое» с «белым», например, внедрение ERP, желание повысить скорость выпуска и сделать завод более рентабельным, а также развивать «мягкие навыки» (soft skills). И вокруг армия консультантов: «Вам нужно внедрить Бережливое производство», «У вас нет нормального управленческого учета», «Вам срочно нужно ERP», «Зачем тратить большие бюджеты, давайте всё сделаем в экселе» и так далее

В России ситуация осложнилась тем, что в 90-е годы была уничтожена советская научная школа управления производством и в течение 20 лет мы утратили собственные наработки и системно не взяли чужие, за исключением лидеров отраслей. В итоге сегодня видим засилье литературы из серии «Богатый папа — бедный папа» или «Коучинг — наше всё», а также разные курсы МВА, где руководителей и собственников бизнеса учат в основном лучшим практикам финтеха и ИТ.

Привет, Хабр! Меня зовут Евгений, я — ведущий разработчик отдела SAP разработки.

Цель этой статьи — «подумать письмом» о том, что такое SAP UI5, каковы его особенности, преимущества и недостатки. Так же, рамках статьи попытаемся ответить на вопрос, стоит ли его использовать, а если стоит то, когда и зачем.

Точнее такой она была изначально. А на самом деле, преследуя исключительно личные корыстные интересы, я решил провести небольшое исследование, на обширную и трудно формулируемую тему «а не посмотреть ли мне в сторону web разработки на SAP UI5».

Основная целевая аудитория — это в первую очередь SAP ABAP разработчики и сочувствующие, которых интересуют похожие вопросы, а во вторую и последнюю — все остальные любопытствующие ИТ‑шники:)

Интересно? Читайте статью под катом.

Продолжаю делиться кейсами организаций, которые развивают свои решения в открытом формате и/или осуществляют вклад в общемировые open source-проекты.

На этот раз опытом поделился Михаил Скворцов, основатель специализированной компании-интегратора по внедрению платформы Odoo в России и сопредседатель Rudoo, российского консорциума разработчиков ERP-решений при ИСП РАН.