ERP-системы *

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

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

История началась в далеком 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-решений при ИСП РАН.

Давайте честно: интегрированное бизнес-планирование редко ассоциируется с чем-то увлекательным. Но если оглянуться назад, можно проследить путь развития — от учета пива и зерна у шумеров до сложных систем, которые сегодня управляют целыми корпорациями в условиях постоянной неопределённости.
Меня зовут Глеб Канин, я продуктовый директор «Оптимакрос», и сегодня мы погрузимся в историю, которая началась с шумеров и египтян, а развилось в методолгию IBP.

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

Заказчик ведет учет в 1С: ERP, принимает от давальца материалы в переработку, производит одинаковую продукцию для себя и для давальца в одних и тех же подразделениях. Учет по назначениям не ведет.

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

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

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

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