#erpсистемы — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #erpсистемы, aggregated by home.social.
-
Рынок SaaS в России замедляется, но остается устойчивым
Команда аналитического проекта SaaS Rating представила ежегодный рейтинг крупнейших SaaS-компаний России по итогам 2025 года. Исследование подготовлено под руководством Аскара Рахимбердиева, сооснователя и генерального директора ERP-сервиса МойСклад. Рейтинг SaaS-компаний формируется на основе выручки от B2B SaaS-продуктов в России и включает компании с годовой выручкой от 200 млн рублей. При определении SaaS используется международный стандарт NIST: сервис должен соответствовать ключевым характеристикам облачной модели — on-demand self-service, доступ через сеть, масштабируемость, объединение ресурсов и оплата по мере использования.
https://habr.com/ru/companies/moysklad/articles/1029974/
#saas #облачные_сервисы #erpсистемы #автоматизация_бизнеса #рейтинг_сервисов
-
Платформы и приложения Low code
Мы живем во времена, когда даже самые простые бизнес-процессы стараются автоматизировать, цифровизировать и трансформировать, тем самым передавая рутинные операции на исполнение вычислительным машинам. Освободившееся время и ресурсы предполагается отдать человеку на решение более сложных интеллектуальных задач. Подобное возможно за счет искусного комбинирования программного обеспечения и последних техно-инновационных достижений. Аналогично различным классам автоматизации, обеспечивающим работу предприятия на операционном, тактическом и стратегическом уровнях, языки программирования, позволяющие получать готовые программные продукты, бывают низкоуровневые и высокоуровневые. Первый вид довольно сложный и апеллирует машинными командами, в то время как второй – более доступный для понимания и легкий в использовании. Эволюция от сложному к простому, от неструктурированного к упорядоченному, от не готового к полуфабрикату – это поистине лозунг текущего времени. Попытки упростить процесс программирования нашли свое отражение в No-code платформах, представляющих визуальный конструктор для производства программных решений без навыков программирования. Антонимом данной ситуации является классическая кастомная разработка приложений. Тем самым мы блуждаем между крайностями: или просто, или сложно. Пытливый ум попытался найти баланс где-то посередине, предлагая Low-code платформы.
https://habr.com/ru/articles/1026408/
#low_code #no_code #no_code_приложения #no_code_платформа #erpсистема #разработка_по #настройка_по #система_erp #erpсистемы #кастомизация_по
-
Свод знаний по бизнес-анализу BABoK в проектах внедрения корпоративных информационных систем
Появление первых персональных вычислительных машин, их активное внедрение в рабочие процессы, а также безграничный доступ в интернет сделали свое дело. Современное предприятие немыслимо без компьютерных систем и технологий. Рутинные операции отданы на откуп точным программным алгоритмам, в то время как нестандартные задачи – человеку. Популяризация искусственного интеллекта, машинного обучения, интернета вещей и прочих составляющих 4-й промышленной революции, использующих результаты информатизации, привнесли информационные технологии в регулярные процессы жизнедеятельности человека. Теперь программное обеспечение и прочие цифровые сервисы такой же товар как продукция первой необходимости. Под любой запрос есть свой программный продукт. Если компании нужна автоматизация процессов и интеграция с бизнес-партнерами, это одни программные решения, взаимодействие с соцсетями и мессенджерами – другие. Однако кастомное или коробочное программное обеспечение – лишь средство, первичным является осознание и формализация потребности. Если вы выбрали программный продукт и решили его имплементировать, есть классические методологии внедрения: каскадная, итерационная и спиралевидная, а также разные подходу к запуску, например, метод большого взрыва, франчайзинговая стратегия и способ точного броска. Указанные подходы имеют свои отличительные особенности, но в первую очередь разную скорость доставки решения до рынка. И опять, важны потребности и ожиданий стейкхолдеров. Данные примеры затрагивают вопрос понимания потребностей и способов их реализации, чем занимается дисциплина под названием бизнес-анализ. Ключевым источником информации по данному вопросу является свод знаний по бизнес-анализу или BABoK [1], не так часто освещаемый в литературных источниках. Следуя PMBoK, SWEBoK, BPMCBoK, TOGAF и другим сводам знаний [2-5], BABoK может быть применен в проектах разработки и внедрения программных систем.
https://habr.com/ru/articles/1020098/
#babok #erp #erpсистемы #бизнес_анализ #бизнес_кейс #бизнес_кейсы #свод_знаний_babok #свод_знаний_бизнес_анализ #свод_знаний #анализ_erp
-
Применение модели Захмана в проектах внедрения, поддержки и развития ERP-систем
Стремительное развитие корпоративных информационных систем, представленных набором информационных систем, автоматизирующих заданную предметную область, диктуют обязательные требования к построению сбалансированной ИТ-архитектуры. Архитектура разрабатываемого и имплементируемого программного решения должна быть построена таким образом, чтобы заложить гибкие, масштабируемые и технологичные механизмы работы, обеспечивая тем самым возможность оперативного реагирования на любые изменения внешней среды. Доступен ряд научно-популярных работ, описывающих различные подходы к построению ИТ-архитектуры, которые обобщены в терминах корпоративная архитектура и архитектура предприятия. Методологии построения корпоративной архитектуры представлены такими подходами как: FEAF, DoDAF [1], а также широко известная и наиболее популярная TOGAF [2]. Несмотря на кажущееся обилие стратегий к формированию ИТ-архитектуры, по большому счету, они апеллируют едиными сущностями, изначально предложенными в модели Захмана. Не взирая на то, что модель Захмана предоставляет широкий теоретический аппарат, который лежит в основе понимания любой архитектуры предприятия, ее использование как в контексте разработки, так и непосредственно в ходе имплементации корпоративного ПО, часто остается незамеченным [3]. Однако применение именно данной модели делает методологии внедрения ИС такими, какие они есть сейчас: структурированными и гибкими, генерализованными и специализированными, а также прозрачными и эффективными. Цель текущей работы состоит в анализе модели Захмана и ее применимости в проектах реализации корпоративных информационных систем. Достижение сформулированной цели потребует решения следующих задач:
https://habr.com/ru/articles/1014002/
#togaf #togaf_10 #eabok #модель_захмана #захман #корпоративная_архитектура #erp #erpсистемы #erpсистема #babok
-
Замена ERP без рисков: почему важен инженерный подход
В последнее время слово «инженер» мало употребляется в IT-индустрии. Есть программист, разработчик ПО, техлид, архитектор. Но одно только знание технологий не дает гарантии, что человек хорошо выполнит бизнес-задачу. Инженерное мышление — это особый дар, который позволяет решить сложную, возможно, даже ранее не решенную проблему с использованием существующих технологий. Проведу параллель с автоиндустрией. Довольно долгое время привод у автомобилей был только на одно колесо, так как не было механизма, позволявшего ведущим колесам на одной оси вращаться с разной угловой скоростью при поворотах. Были развитые технологии металлообработки и специалисты, способные изготавливать шестерни, валы и прочее. Но задача не решилась, пока инженеры не изобрели дифференциал .
https://habr.com/ru/companies/haulmont/articles/1009258/
#erpсистемы #erpсистема #инженерия #инженер #инженерная_культура
-
Как ИИ находит скрытые ошибки в настройках 1С:ERP
В 1С:ERP сотни настроек. Каждая из них может быть абсолютно правильной — но некоторые их комбинации в процессе эксплуатации начинают конфликтовать друг с другом. Система при этом продолжает работать, только всё хуже и хуже. Бывает и по-другому: настройки выглядят вполне корректно, но на самом деле содержат скрытые проблемы, проявляющиеся по мере эксплуатации. Чтобы находить такие ошибки, была создана экспертная система с использованием искусственного интеллекта. Она анализирует настройки ERP и выявляет потенциальные конфликты. Я участвовал в разработке этой системы и покажу, как она работает на реальных примерах.
https://habr.com/ru/articles/1011102/
#иипомощники #erp #ai #chatgpt #практический_кейс #реальный_опыт #1с #erpсистемы #управление_производством #машинное+обучение
-
Как ИИ находит скрытые ошибки в настройках 1С:ERP
В 1С:ERP сотни настроек. Каждая из них может быть абсолютно правильной — но некоторые их комбинации в процессе эксплуатации начинают конфликтовать друг с другом. Система при этом продолжает работать, только всё хуже и хуже. Бывает и по-другому: настройки выглядят вполне корректно, но на самом деле содержат скрытые проблемы, проявляющиеся по мере эксплуатации. Чтобы находить такие ошибки, была создана экспертная система с использованием искусственного интеллекта. Она анализирует настройки ERP и выявляет потенциальные конфликты. Я участвовал в разработке этой системы и покажу, как она работает на реальных примерах.
https://habr.com/ru/articles/1011102/
#иипомощники #erp #ai #chatgpt #практический_кейс #реальный_опыт #1с #erpсистемы #управление_производством #машинное+обучение
-
Как ИИ находит скрытые ошибки в настройках 1С:ERP
В 1С:ERP сотни настроек. Каждая из них может быть абсолютно правильной — но некоторые их комбинации в процессе эксплуатации начинают конфликтовать друг с другом. Система при этом продолжает работать, только всё хуже и хуже. Бывает и по-другому: настройки выглядят вполне корректно, но на самом деле содержат скрытые проблемы, проявляющиеся по мере эксплуатации. Чтобы находить такие ошибки, была создана экспертная система с использованием искусственного интеллекта. Она анализирует настройки ERP и выявляет потенциальные конфликты. Я участвовал в разработке этой системы и покажу, как она работает на реальных примерах.
https://habr.com/ru/articles/1011102/
#иипомощники #erp #ai #chatgpt #практический_кейс #реальный_опыт #1с #erpсистемы #управление_производством #машинное+обучение
-
Как ИИ находит скрытые ошибки в настройках 1С:ERP
В 1С:ERP сотни настроек. Каждая из них может быть абсолютно правильной — но некоторые их комбинации в процессе эксплуатации начинают конфликтовать друг с другом. Система при этом продолжает работать, только всё хуже и хуже. Бывает и по-другому: настройки выглядят вполне корректно, но на самом деле содержат скрытые проблемы, проявляющиеся по мере эксплуатации. Чтобы находить такие ошибки, была создана экспертная система с использованием искусственного интеллекта. Она анализирует настройки ERP и выявляет потенциальные конфликты. Я участвовал в разработке этой системы и покажу, как она работает на реальных примерах.
https://habr.com/ru/articles/1011102/
#иипомощники #erp #ai #chatgpt #практический_кейс #реальный_опыт #1с #erpсистемы #управление_производством #машинное+обучение
-
Почему российский бизнес проигрывает битву за информацию и как это исправить. Введение и Часть 1
Российский бизнес переживает эпоху «Великого перехода». Санкционное давление и уход западных вендоров заставили компании в спешке мигрировать на отечественное ПО. Но гонка за новыми платформами обнажила старую как мир проблему: наши системы полны «мусора» . На многочисленных проектах по миграции с SAP и западных CRM на российские решения наблюдается одна и та же картина: бизнес ждет «магии» от новой системы, а получает перенос хаоса. Аналитики и ИТ-специалисты приходят к выводу: битва за качество данных проигрывается не из-за отсутствия талантливых разработчиков, а потому что бизнес-анализ как дисциплина в России до сих пор не воспринимает данные как стратегический актив. В этом цикле будут разобраны три фатальные ловушки, в которые попадают компании, и главное — предложены пошаговые рецепты спасения, основанные на реальной практике и современных методологиях.
https://habr.com/ru/articles/1010370/
#системный_анализ #бизнесанализ #миграция_данных #управление_данными #качество_данных #очистка_данных #data_governance #erpсистемы #историчность_данных #требования_к_данным
-
Как компании закладывают риск провала ERP-проекта на этапе выбора платформы и интегратора
Когда речь заходит о выборе ERP-платформы и системного интегратора, почти всегда звучит слово «конкурс». Формально процесс выглядит структурированным: несколько поставщиков, демо, презентации, референсы, коммерческие предложения. Но если посмотреть глубже, картина часто оказывается иной. Не потому, что компании «не умеют выбирать». А потому, что процесс выбора нередко начинается с инструмента, а не с методологии. Иногда стартовая точка — это демо. Иногда — список потенциальных вендоров. Иногда — внутреннее ощущение, что «эти ребята выглядят сильнее». Недавно я обсуждал проект с партнёром, который предложил: «Давайте сделаем серию демо и на основе впечатления выберем». В разговоре выяснилось, что на старте отсутствовали:
https://habr.com/ru/articles/996858/
#проектирование #erpсистемы #1c #управление_проектами #продажи
-
Интеграция 40+ дилеров через REST API: как мы построили портал запчастей для Ростсельмаш
Про эталонный справочник, JWT-авторизацию, требования КИИ и почему 1С-Битрикс вместо Laravel В 2022 году мы получили задачу: автоматизировать заказы запчастей для 40+ дилеров Ростсельмаш. Вызов был не в объёме данных (50,000 SKU), а в разнородности систем дилеров и требованиях безопасности КИИ. Через 18 месяцев 65% заказов пошли через портал без участия операторов. REST API интегрирован с 28 дилерами (70% сети). Время оформления заказа сократилось с 45 минут до 7. Под катом — архитектурные решения, почему эталонный справочник важнее REST API, и как обойти ограничения КИИ.
https://habr.com/ru/articles/995496/
#rest_api #1c_интеграция #b2b #jwt #системная_интеграция #1сбитрикс #erpсистемы #архитектура #кии #дилерская_сеть
-
План-график для проекта внедрения ERP-системы на примере 1С и SAP
Массовое использование информационный систем как в жизни отдельного человека, организации, так и государства в целом привносит очевидные преимущества: высокую скорость выполнения операций, автоматизацию рутинных задач, доступность услуг из любой точки мира и др. При этом без внимания и широкого освещения остается вопрос того, насколько нелегко реализовывать подобные высокосложные ИТ-проекты. Реализация таких проектов – это отдельная наука, вбирающая в себя множество технических дисциплин от программирования и математики до системного анализа и управления проектами. Активность внедрения информационных систем далеко не единственная задача с точки зрения жизненного цикла программного обеспечения. Имплементации программной системы предшествует большая работа по предварительному расчету ключевых параметров проекта. Наиболее полный перечень параметров к проработке предлагает свод знаний по управлению проектами PMBoK [1], именно в нем явно отражается взаимозависимость между содержанием, сроками, ресурсами и бюджетом инициативы. Данные показатели позволяют построить сводную картину о будущем ИТ-проекте, обеспечивая формирование план-графика, ресурсного плана и других важных его составляющих. Подготовка план-графика внедрения информационной системы требует от автора детального понимания всех аспектов выполняемых задач, возможности его сравнения с бенчмарками, привлечения экспертов для детальной проработки технических вопросов, а также терпения при многократных процедурах балансировки четверки «содержание-срок-ресурсы-стоимость». Несмотря на наличие в литературе детально описанных способов формирования планов работ на основе методов критического пути и критической цепи [1], вводящего резервные временные интервалы для обработки непредвиденных ситуаций, их использование в ИТ-проектах не всегда возможно и целесообразно.
https://habr.com/ru/articles/994658/
#erpсистемы #erpсистема #erp #план_график #график_внедрения #план_внедрения #планирование_проектов #планирование_времени #планирование_ресурсов #кис
-
ERP.Next: Архитектура автономных ERP на основе мультиагентного ИИ
ERP-системы непрерывно развивались с самого начала своего создания. Но их архитектура до сих пор опирается на принципы, сформулированные до эпохи повсеместного распространения данных в реальном времени и развития автономного агентного искусственного интеллекта. Соответственно, можно с утверждением говорить, что текущая архитектура ERP-систем не отвечает современным вызовам. В этой статье разберем, почему ей нужен принципиально иной фундамент. Я предлагаю строить его на трех китах: семантический слой данных (USDL), открытая интеграционная среда и продвинутая мультиагентная платформа (AMAP). Далее я подробно представлю архитектуру такой ERP-системы, типы AI-агентов и примеры их работы в реальных бизнес-процессах. Ключевая идея — гибкая автономия под контролем человека. В статье я опираюсь на актуальные разработки и аналитику 2025 года, чтобы показать и возможности, и подводные камни мультиагентных систем в корпоративной ИТ-среде. 1. Вместо введения ERP-системы уже много лет являются центральной нервной системой крупного бизнеса. Они объединяют транзакции, данные и процессы в единый цифровой каркас. Исторически их архитектура заточена под главные задачи эпохи: обеспечить целостность данных, централизованный контроль и стандартизацию. Центральный механизм выполнения рабочих процессов и единая модель данных были главными козырями ERP, которые гарантировали надежную отчетность и соответствие регуляторным требованиям. Но мир изменился. Сегодня компании работают с постоянными потоками данных и телеметрии с IoT-устройств, в сложных цифровых экосистемах, в условиях рынка, где быстрые решения определяют операционные и финансовые результаты. Старая, монолитная архитектура ERP не успевает за новой реальностью.
https://habr.com/ru/companies/mt-integration/articles/992644/
#ERP #AInative_ERP #мультиагентные_системы #Knowledge_Graph #цифровая_трансформация #корпоративная_ИТархитектура #искусственный_интеллект #erpсистемы
-
Как управлять проектами в форс-мажорной ситуации: хакерская атака и ежедневные потери в миллионы рублей
Что делать, когда все корпоративные ИТ-системы, поддерживающие ежедневные операционные процессы, «полетели в трубу»? Как управлять такой масштабной программой восстановления всего ИТ-ландшафта, когда даже один день просрочки приводит к миллионным потерям? Управлять по обычным правилам – не вариант. Важны высокая скорость работы и быстрое принятие решений. Никакого традиционного паспорта проекта, никакого талмуда с требованиями, реестра рисков, концепции, ТЭО и прочего. Максимальная упрощенка. Однако при такой скорости и упрощенном управлении… возникает большой риск что-то недосмотреть, упустить, что в итоге приведет к еще большим финансовым потерям. Так как нужно управлять такой масштабной программой в форс-мажорных обстоятельствах, когда каждый день критически важен для бизнеса? Рассказываю реальный кейс: как мы помогли клиенту выйти из ситуации глубокого кризиса и реализовать программу по восстановлению ключевых корпоративных ИТ-систем с минимальными потерями.
https://habr.com/ru/articles/989920/
#управление_проектами #управление_программой #итсистемы #восстановление_системы #антикризис #антикризисное_управление #менеджмент #проект #хакерская_атака #erpсистемы
-
Жизненный цикл ERP-систем
Качественное и своевременное внедрение корпоративных информационных систем как российского (1С, Галактика, Парус), так и западного производства (ранее преимущественно SAP, Oracle и Microsoft) требует досконального знания методологии имплементации, что накладывается свой отпечаток на жизненный цикл программного обеспечения. Несмотря на наличие гибких методов внедрения, жизненный цикл программных продуктов, по существу, остается единым: начиная с задумки и заканчивая выведением из эксплуатации. Внедрение корпоративных программных систем, представляющих собой имплементирование программного решения в масштабах предприятия или холдинга, имеет схожий жизненный цикл. Однако, если внимательнее к нему присмотреться, выходит, что процесс внедрения является не единственным, а фактически завершающим шагом. Не верите, тогда давайте разберемся в этом вопросе в рамках текущей статьи. Приведем шаги классического жизненного цикла программного обеспечения [1]:
-
Особенности совещаний на проектах внедрения ERP-систем
В этой статье — неочевидный взгляд на эффективность совещаний в ERP-проектах: не количество совещаний или участников, а результат.
https://habr.com/ru/articles/988480/
#управление_проектами #управление_людьми #erpсистемы #1c #совещания
-
Как мы вывезли ИТ-трансформацию, за которую никто не хотел браться, и спасли бизнес от многомиллионных потерь
Несколько лет назад к нам обратился клиент (крупнейшая логистическая компания в России) с проблемой – европейский головной офис отзывает все лицензии действующих ПО, и у клиента есть только год, чтобы импортозаместить 8 ключевых ИТ-систем и несколько дополнительных. При этом проектного офиса в компании нет – ранее все ИТ-проекты делались силами головного офиса. А на то, чтобы создать проектный офис с нуля, времени уже нет. При этом, если не успеть до момента, когда все лицензии прекратят действовать… это приведет к остановке работы в 14 распределительных центрах России компании и ущербу в десятки миллионов рублей. Большинство подрядчиков, к которым клиент обратился до нас, отказались ввязываться в эту историю – потому что даже для внедрения одной ERP-системы требовалось месяцев 16. А тут, кроме ERP, еще 7, и времени всего год. Так как у нас большой опыт в вытаскивании масштабных программ из кризиса, мы согласились. И сразу приступили к работе – в качестве проектного офиса на аутсорсе. Что конкретно мы сделали и как нам удалось помочь компании предотвратить многомиллионные потери, рассказываю в этом кейсе.
https://habr.com/ru/articles/988194/
#управление_проектами #управление_программой #трансформация #erpсистемы #project_management #руководитель_проекта #менеджмент
-
ERP-проекты: как не стать частью провалов
К моменту прихода Ли Якокки (легенда менеджмента производства авто, создатель Форд Мустанг) Крайслер находилась на грани банкротства. Чтобы не потерять бизнес Якока закрывал убыточные заводы, продавал непрофильные активы, изменил отношения с поставщиками, сконцентрировал все усилия на создании новой линейки автомобилей - K-Car и другие. Принятые меры позволили оживить бренд, погасить долги и начать рост бизнеса.
https://habr.com/ru/articles/985404/
#проект #объем_проекта #управление_проектами #управление_проектами_и_командой #erpсистемы
-
Сапёр в эпоху LLM: собираем персонального архивариуса для SPRO, ABAP-кода и Telegram-чата
Принято считать, что экосистема SAP — это закрытый клуб, где вендор намеренно ограничивает доступ к знаниям. В свое время я даже делал доклад «SAP Support Launchpad и другие инструменты, которые облегчают жизнь консультанта», в котором основной темой было — где и как искать необходимую информацию. Но сейчас кажется, что настоящая проблема консультанта кроется не в дефиците информации, а в ее переизбытке. Мы тонем в данных, и нам нужны не новые доступы, а четкие алгоритмы поиска. SAP — это большая платформа, которая рождает огромный «шум»: талмуды документации, которые лежат прямо в системе (и которые зачастую никто не читает), книги, курсы, разрозненные вики. А еще в нагрузку на каждом новом предприятии ты получаешь свой параллельный мир — множество кастомных «уникальных объектов и решений», которые приходится понять и освоить. И вот тут, как мне кажется, можно найти область, где LLM может принести практическую пользу. А именно — помогать структурировать, упаковывать и связывать знания так, чтобы их можно было находить и переиспользовать быстрее. При этом с существующими технологиями каждый может выстраивать свою базу знаний со своей привычной концепцией, не полагаясь на корпоративные практики, которые могут кардинально отличаться от места к месту.
-
MDUI: как отдать UI backend-разработчикам
Как сократить Time-to-Market в 7 раз и научить бэкенд-разработчиков собирать страницы за 15 минут? В этой статье я делюсь опытом внедрения Meta-Driven UI в ERP-системе. Расскажу, как я «душила» легаси с помощью Strangler Fig Pattern, внедрила FSD-архитектуру на Vue 3 и почему Render-функции оказались эффективнее обычных шаблонов.
https://habr.com/ru/articles/980684/
#vuejs #frontendразработка #MDUI #fsd #erpсистемы #refactoring
-
Учебник для искусственного разума: как я сделал ИИ-помощника по планированию для 1С:ERP
В этой статье: Технология создания ИИ-помощника для работы с 1С:ERP. Почему невозможно создать такого помощника, опираясь только на официальную документацию 1С. И почему та же самая документация 1С, при правильной обработке , способна превратить ИИ в супер-помощника – то есть многократно его усилить.
https://habr.com/ru/articles/978406/
#ИИ #искусственный_интеллект #1с #ERP #erpсистемы #Планирование #AI #сезон_ии_в_разработке
-
Раньше было лучше – причины саботажа сотрудников при внедрении
При внедрении новых систем или оптимизации существующих мы часто сталкиваемся с саботажем со стороны, сотрудников организации-заказчика. Это существенно влияет на отношения с заказчиком, соблюдение сроков и другие возникающие риски проекта. Попробуем разобраться с возможными причинами и проявлениями саботажа в разрезе основных отделов компании и понять, как можно работать с возникающими возражениями. Для начала разберемся с тем, что именно подразумевается под словом “саботаж”. * Этимология слова саботаж. Французское происхождение: sabotage от слова sabot — «деревянный башмак, сабо».В XIX веке рабочие во Франции носили такие деревянные башмаки — сабо. По одной версии, когда они протестовали против машин и механизации , они бросали свои сабо в механизмы ткацких станков , чтобы заблокировать их работу. Отсюда — «ломать машины сабо» → «саботировать работу». Таким образом, саботаж со стороны сотрудников - недовольство, частичное или невыполнений функций в новой системе, которое затрудняет процесс внедрения/оптимизации.
https://habr.com/ru/companies/korus_consulting/articles/975418/
#1с #erp #erp_системы #erpсистемы #внедрение_1с #внедрение_1с_erp
-
Как я делал open-source проект, перевёл его на коммерческие лицензии — и это было моим самым лучшим решением
Меня зовут Алексей, я скорее инженер, чем разработчик. Занимался производствами, конструировал приборы и в какой-то момент решил попробовать сделать универсальный конструктор для учёта всего, что мне было нужно на производстве — материалов, заказов, процессов, планирования сроков и т.п. Предполагалось, что мы вместе с разработчиком запилим такую платформу за полгода, будем продавать лицензии и станем миллионерами. Но так как задача оказалась сложной, а через полгода разработки стало понятно, что потребуется чуть больше времени, чем ожидалось, было решено выложить её в open source. Решение было принято под влиянием моды того времени на открытые системы: стартапы получали по 10 млн баксов под таблички без функционала, но зато с MIT-лицензиями, проводились конференции, изо всех утюгов неслось, как здорово на сопровождении все зарабатывают миллионы... В общем, начитавшись всей этой чуши, поставили MIT, залили на GitHub, написали статью на Хабр — и... получили поток комментариев: «Ваш код — УГ» и «Всё надо переделать на Laravel». В итоге, потратив охулиард нервных клеток и набрав 900 звездочек на GitHub, я бросил это опенсорсное занятие и поставил самые обыкновенные платные лицензии. Что не пишут в буклетах про open source
-
Завершение использования ПО
Стремительное развитие информационных систем и технологий породило некогда считавшуюся немыслимой ситуацию: завершение использования программного обеспечения стало обыденностью и возможностью для компании повысить свои конкурентные преимущества. Как бы парадоксально это не звучало, но сейчас дела обстоят именно так. Изначально жизненный цикл программного обеспечения предполагал прохождение ряда состояний, включающих пред-проект внедрения, проект имплементации и пост-проект, на которых доказывалась целесообразность продукта, велась разработка, а далее – поддержка и развитие. До недавнего времени все шло именно так, а сопровождение и развитие решения могли выполняться годами. Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап. Цель данной статьи состоит в рассмотрении заключительного этапа жизненного цикла программного обеспечения, подходов и методов применимых к нему для обеспечения разумного завершения использования софтверного продукта и его замены на прочие решения, что обеспечит непрерывность бизнес-процессов организации. Достижение цели потребует проработки следующих вопросов:
https://habr.com/ru/articles/972278/
#утилизация_по #замена_по #перевнедрение #отказ_от_по #замещение_по #переимплементация_по #erpсистемы #кис #информационные_системы
-
Завершение использования ПО
Стремительное развитие информационных систем и технологий породило некогда считавшуюся немыслимой ситуацию: завершение использования программного обеспечения стало обыденностью и возможностью для компании повысить свои конкурентные преимущества. Как бы парадоксально это не звучало, но сейчас дела обстоят именно так. Изначально жизненный цикл программного обеспечения предполагал прохождение ряда состояний, включающих пред-проект внедрения, проект имплементации и пост-проект, на которых доказывалась целесообразность продукта, велась разработка, а далее – поддержка и развитие. До недавнего времени все шло именно так, а сопровождение и развитие решения могли выполняться годами. Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап. Цель данной статьи состоит в рассмотрении заключительного этапа жизненного цикла программного обеспечения, подходов и методов применимых к нему для обеспечения разумного завершения использования софтверного продукта и его замены на прочие решения, что обеспечит непрерывность бизнес-процессов организации. Достижение цели потребует проработки следующих вопросов:
https://habr.com/ru/articles/972278/
#утилизация_по #замена_по #перевнедрение #отказ_от_по #замещение_по #переимплементация_по #erpсистемы #кис #информационные_системы
-
Завершение использования ПО
Стремительное развитие информационных систем и технологий породило некогда считавшуюся немыслимой ситуацию: завершение использования программного обеспечения стало обыденностью и возможностью для компании повысить свои конкурентные преимущества. Как бы парадоксально это не звучало, но сейчас дела обстоят именно так. Изначально жизненный цикл программного обеспечения предполагал прохождение ряда состояний, включающих пред-проект внедрения, проект имплементации и пост-проект, на которых доказывалась целесообразность продукта, велась разработка, а далее – поддержка и развитие. До недавнего времени все шло именно так, а сопровождение и развитие решения могли выполняться годами. Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап. Цель данной статьи состоит в рассмотрении заключительного этапа жизненного цикла программного обеспечения, подходов и методов применимых к нему для обеспечения разумного завершения использования софтверного продукта и его замены на прочие решения, что обеспечит непрерывность бизнес-процессов организации. Достижение цели потребует проработки следующих вопросов:
https://habr.com/ru/articles/972278/
#утилизация_по #замена_по #перевнедрение #отказ_от_по #замещение_по #переимплементация_по #erpсистемы #кис #информационные_системы
-
Завершение использования ПО
Стремительное развитие информационных систем и технологий породило некогда считавшуюся немыслимой ситуацию: завершение использования программного обеспечения стало обыденностью и возможностью для компании повысить свои конкурентные преимущества. Как бы парадоксально это не звучало, но сейчас дела обстоят именно так. Изначально жизненный цикл программного обеспечения предполагал прохождение ряда состояний, включающих пред-проект внедрения, проект имплементации и пост-проект, на которых доказывалась целесообразность продукта, велась разработка, а далее – поддержка и развитие. До недавнего времени все шло именно так, а сопровождение и развитие решения могли выполняться годами. Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап. Цель данной статьи состоит в рассмотрении заключительного этапа жизненного цикла программного обеспечения, подходов и методов применимых к нему для обеспечения разумного завершения использования софтверного продукта и его замены на прочие решения, что обеспечит непрерывность бизнес-процессов организации. Достижение цели потребует проработки следующих вопросов:
https://habr.com/ru/articles/972278/
#утилизация_по #замена_по #перевнедрение #отказ_от_по #замещение_по #переимплементация_по #erpсистемы #кис #информационные_системы
-
Пока все вайбкодят, мы продолжаем делать freemium базу данных для разработки ERP/LLM-систем
История началась в далеком 2016 году, когда у меня был небольшой свечной заводик. Не свечной, конечно, но все же производство — и нужно мне было на нем сделать автоматизацию. Чтобы компоненты закупались вовремя, списывались со склада в правильном количестве и автоматически планировалось, какие операции делать в рамках рабочего дня. Тогда я впервые подумал, что неплохо бы иметь программируемый конструктор — что-то типа MS Access, но только в web и чтобы логика и запросы программировались одинаково и понятно. То производство закрылось, и я некоторое время занимался тем же самым уже на производстве побольше, а потом — на еще одном, у которого цех был по соседству. Тут и решили не писать всё каждый раз с нуля, а сделать нормальную тиражируемую систему. Как эксель, но по-другому, и уже на ней конструировать такие приложения для цеха. Так появился Тотум Онлайн (который теперь даже в реестр Росийского ПО записан :)
-
Новый подход к оценке производительности облачной инфраструктуры для 1С: от теста Гилева к реальным нагрузочным тестам
Привет, Хабр! В статье поговорим о том, почему традиционные методы оценки производительности серверов для 1С не работают в облачной инфраструктуре и как мы нашли решение этой проблемы. А еще приглашаем вас на бесплатный вебинар 18 ноября в 11:00 мск , где разберем реальные провалы и фатальные ошибки при работе 1С в облаке. Поговорим о том, почему CPU не покажет реальных проблем, расскажем про кейс с дедлоками при нормальных показателях железа и объясним, почему 40% нагрузки должны стать вашим новым максимумом. Всем зарегистрировавшимся пришлем чек-лист по критическим настройкам 1С из практики обслуживания 7000 пользователей.
https://habr.com/ru/companies/beeline_cloud/articles/965744/
#нагрузочное_тестирование #облачные_технологии #тест_гилева #виртуализация #openstack #vmware #iaas #1с #apdex #erpсистемы
-
Новый подход к оценке производительности облачной инфраструктуры для 1С: от теста Гилева к реальным нагрузочным тестам
Привет, Хабр! В статье поговорим о том, почему традиционные методы оценки производительности серверов для 1С не работают в облачной инфраструктуре и как мы нашли решение этой проблемы. А еще приглашаем вас на бесплатный вебинар 18 ноября в 11:00 мск , где разберем реальные провалы и фатальные ошибки при работе 1С в облаке. Поговорим о том, почему CPU не покажет реальных проблем, расскажем про кейс с дедлоками при нормальных показателях железа и объясним, почему 40% нагрузки должны стать вашим новым максимумом. Всем зарегистрировавшимся пришлем чек-лист по критическим настройкам 1С из практики обслуживания 7000 пользователей.
https://habr.com/ru/companies/beeline_cloud/articles/965744/
#нагрузочное_тестирование #облачные_технологии #тест_гилева #виртуализация #openstack #vmware #iaas #1с #apdex #erpсистемы
-
Новый подход к оценке производительности облачной инфраструктуры для 1С: от теста Гилева к реальным нагрузочным тестам
Привет, Хабр! В статье поговорим о том, почему традиционные методы оценки производительности серверов для 1С не работают в облачной инфраструктуре и как мы нашли решение этой проблемы. А еще приглашаем вас на бесплатный вебинар 18 ноября в 11:00 мск , где разберем реальные провалы и фатальные ошибки при работе 1С в облаке. Поговорим о том, почему CPU не покажет реальных проблем, расскажем про кейс с дедлоками при нормальных показателях железа и объясним, почему 40% нагрузки должны стать вашим новым максимумом. Всем зарегистрировавшимся пришлем чек-лист по критическим настройкам 1С из практики обслуживания 7000 пользователей.
https://habr.com/ru/companies/beeline_cloud/articles/965744/
#нагрузочное_тестирование #облачные_технологии #тест_гилева #виртуализация #openstack #vmware #iaas #1с #apdex #erpсистемы
-
Новый подход к оценке производительности облачной инфраструктуры для 1С: от теста Гилева к реальным нагрузочным тестам
Привет, Хабр! В статье поговорим о том, почему традиционные методы оценки производительности серверов для 1С не работают в облачной инфраструктуре и как мы нашли решение этой проблемы. А еще приглашаем вас на бесплатный вебинар 18 ноября в 11:00 мск , где разберем реальные провалы и фатальные ошибки при работе 1С в облаке. Поговорим о том, почему CPU не покажет реальных проблем, расскажем про кейс с дедлоками при нормальных показателях железа и объясним, почему 40% нагрузки должны стать вашим новым максимумом. Всем зарегистрировавшимся пришлем чек-лист по критическим настройкам 1С из практики обслуживания 7000 пользователей.
https://habr.com/ru/companies/beeline_cloud/articles/965744/
#нагрузочное_тестирование #облачные_технологии #тест_гилева #виртуализация #openstack #vmware #iaas #1с #apdex #erpсистемы
-
MES-система
Как управлять предприятием с помощью MES Согласно данным публикации Industry Week, использование программного комплекса MES приводит к увеличению прибыли предприятия в четыре раза. В статье мы рассматриваем детали программного комплекса MES и факторы, способствующие росту прибыли в производстве. Что такое MES или как правильно управлять производством. MES (Manufacturing Execution System) представляет собой систему, которая управляет производственными операциями и включает в себя комплекс программных и аппаратных средств. Она предназначена для эффективного выполнения задач производства, а также для отслеживания и контроля процессов на производственной линии. Эта система обеспечивает повышение прибыльности и эффективности предприятия любого масштаба, предоставляя необходимую информацию и управляя производственными процессами. Она особенно важна для отраслей, таких как производство пищевых продуктов, медицинского оборудования, напитков, фармацевтики, аэрокосмической и оборонной промышленности, авиации и биотехнологий, где требования к прослеживаемости продукции очень строгие. Важно иметь определенные процедуры во время производства, их документирование и возможность легкого отзыва продукции, если это необходимо. Функциональные задачи MES-систем Системы управления производством, такие как системы управления производственными операциями, имеют обширный набор функций и охватывают почти все аспекты, процессы и объекты в производственной сфере. Среди основных функций, которые такое программное обеспечение выполняет:
https://habr.com/ru/articles/927280/
#MES #mesh #itкомпании #it #информационные_технологии #mesсистемы_в_производстве #mesсистемы #индустрия_40 #erpсистемы #итинфраструктура
-
Охватить организацию взглядом: мой инструментарий для контроля бизнес-процессов
В какой‑то момент в организации появляется такое количество важных чатов, ссылок, документов, аккаунтов, папок, людей, проектов, ролей и т. п., что охватить это всё вниманием становится просто невозможно. Начинаются тревоги вида «что же я забыл?» или эпизоды вида «эх, и как я мог забыть!» Как мне кажется, я отыскал один неплохой способ вернуть себе контроль над ситуацией, разгрузить сознание и внимание, и в целом — разобраться, какова же на самом деле структура организации. Делюсь этим способом в статье.
https://habr.com/ru/articles/938358/
#организационная_схема_бизнеса #панель_управления_бизнесом #erpсистемы #crmсистемы #bpms
-
Как мы делали систему управления проектами капстроительства, часть 2
В прошлый раз мы рассказали о том, зачем «Северстали» понадобилась информационная система управления проектами и из чего она состоит. Сегодня продолжим и расскажем о том, как мы управляли проектом внедрения ИСУП и какие уроки для себя вынесли в процессе. На связи снова Павел Архиереев, старший менеджер нашего 1С-центра.
https://habr.com/ru/companies/severstal/articles/785482/
#severstal #severstalitpeople #управление_проектами #исуп #erpсистемы
-
История корпоративных информационных систем в России
Сегодня трудно представить работу современного предприятия без автоматизации процессов его деятельности, реализующих различные производственные и управленческие функции. В России начало внедрения основ автоматизации отдельных участков работы предприятия уходит в эпоху СССР. В Советском Союзе в 1948 г. проблемы развития вычислительной техники становятся общегосударственной задачей. Были развернуты работы по созданию серийных электронно-вычислительных машин ЭВМ первого поколения (термин ЭВМ вместо «компьютер» употреблялся вплоть до конца 1980-х гг.). Первыми изобретателями компьютера в СССР являются И.С. Брук и Б.И. Рамеев, совместно разработавшие проект цифровой ЭВМ с жестким программным управлением. В декабре 1948 г. они получили авторское свидетельство на изобретение «Автоматической цифровой машины». «МЭСМ» (малая электронная счетная машина) – первый компьютер в СССР и в целом в континентальной Европе, была создан в 1951 г. под руководством С.А. Лебедева. Под его же руководством в дальнейшем были разработаны и сконструированы машины серии «М» (М-1, М-2 и другие ее модификации), из которых М-20 в 1960-х гг. была признана в СССР лучшей из отечественных машин. Специализированные ЭВМ, созданные под руководством С.А. Лебедева для системы противоракетной обороны, стали основой достижения стратегического паритета между СССР и США во время холодной войны. В 1950 г. в Институте точной механики и вычислительной техники (ИТМ и ВТ) был организован отдел цифровых ЭВМ для их разработки и создания. В 1951 г. там была спроектирована машина БЭСМ (большая электронная счетная машина), а уже в 1952 г. началась ее опытная эксплуатация.
https://habr.com/ru/articles/898128/
#erpсистемы #КИС #ИС #информационные_системы #история_КИС #история_it #история_ERP
-
План Cutover при имплементации ERP-систем
Существует ошибочная точка зрения, что наиболее критичным этапом внедрения ERP-системы является разработка, это не совсем так. Немаловажны активности, связанные с тестированием, обучением и миграцией данных. Однако все это задачи, выполняются на стороне заказчика. В проект имплементации корпоративной информационной системы вовлечены и прочие заинтересованные стороны, в честности контрагенты [1]. Несмотря на то, что вопрос перехода к продуктивному использованию системы является ключевым в ходе запуска, его важность иногда недооценивается. По крайней мере, до тех пора пока вы не столкнетесь с Cutover’ом вплотную. Да, да, именно так называют план перехода в среде технических специалистов. План перехода включает в себя ряд активностей, выполнение которых решает две основные задачи: техническая подготовка программного решения для функционирования в режиме реального времени, а также взаимодействие с клиентами и поставщиками для обеспечения непрерывной работы с ними. Cutover-план затрагивает технические, бизнес и вопросы, связанные с историческими данными [2]. Формирование плана перехода начинается много раньше промышленного запуска, так как задача в первую очередь требует большого вовлечения сотрудников заказчика, во-вторых, сильно зависит и влияет на технические активности смежных команд. Своевременная подготовка, а она занимает в среднем два-три месяца, и выполнение Cutover-плана, длящегося около двух месяцев, позволяют обеспечить такой режим запуска новой программной системы, который никак или минимально повлияет на клиентов и поставщиков предприятия. Будьте уверены, вы не сможете подготовить план перехода без заказчика. Эту и другие особенности Cutover-плана мы попытаемся рассмотреть в настоящей статье.
https://habr.com/ru/articles/861294/
#cutover #план_перехода #cutoverплан #бизнес_катовер #катовер #технический_катовер #миграция_данных #erpсистемы
-
Парсинг сайта на Python для НСИ
Для проверки определенных типов данных я предлагаю парсинг сайтов, а автоматизация исправления уже на ваш вкус. Например, различные языки программирования. Лично я за весь свой опыт использовал: C#, Python, VBA для работы с Excel, в зависимости от ситуации. Также поделюсь полезным файлом, который можно использовать в автоматизации проверки номенклатурных позиций.
-
ИИ-система по извлечению информации со сканов счетов: от разметки до реализации
Для автоматизации бизнес-процессов часто требуется обработка бумажных документов со сложной структурой — например, счетов, накладных и так далее. Частый сценарий: есть почтовый ящик, на который поступают сканы оплаченных счетов. Этот почтовый ящик разбирается, и информация о счете и дате оплаты вносится в ERP. Однако разбирать такие документы вручную — процесс длительный и трудоемкий. Решение в данном случае может предложить искусственный интеллект. В этой статье мы подробно рассмотрим наш подход к разработке системы, которая распознает информацию с бумажных счетов с помощью технологий компьютерного зрения и машинного обучения.
https://habr.com/ru/companies/agima/articles/849722/
#искусственный_интеллект #erpсистемы #datapipe #label_studio #rabbitmq #ai #ml
-
Обработка отклонений в проектах имплементации ERP-систем
Внедрение крупных программных систем подразумевает использование различных методологий имплементации, например: Accelerated SAP, Microsoft Dynamics Sure Steps или Oracle Unified Method. Прикладная методология, предлагаемая по умолчанию вендором программного продукта, детализирует одну из трех классических моделей имплементации: каскадную, итерационную или спиралевидную. Помимо этого существуют определенные правила по управлению проектами вне зависимости от его содержания, которые называют PMBoK (Project Management Body of Knowledge, свод знаний по управлению проектами) [1]. PMBoK подразумевает выделение в проекте ряда ключевых параметров, каждый из которых необходимо планировать, выполнять и осуществлять его мониторинг. Любые отклонения параметров от плановых значений требуют корректировочного действия. Свод знаний разработан американским институтом PMI и имеет длительную историю. На начало 2022 года в русскоязычной литературе доступна PMBoK шестой версии, а в англоязычной – седьмой. Каждая версия PMBoK дополняется новыми подходами, так ранее широкой огласке получили механизмы искусственного интеллекта в управлении проектами, сейчас же активно обсуждается применение принципов гибкой разработки Agile. Для прочтения книга PMBoK весьма сложна. Определенно знакомство со сводом знаний необходимо начинать, предварительно реализовав хотя бы один проект, в противном случае вы не поймете посыл книжки. В контексте данной статьи, мы ограничимся рассмотрением ERP-проектов. Использование PMBoK в проектах имплементации корпоративных информационных систем выглядит выигрышным, по крайней мере, это позволяет структурировать характеристики проекта и вести их непрерывный контроль. Существенным упущением PMBoK является отсутствие рекомендаций по способам обработки отклонений, что противоречит циклу Деминга [2]. Вполне возможно, это было сделано сознательно, так как невозможно предложить универсальные механизмы для всех предметных областей проектов.
https://habr.com/ru/articles/817609/
#pmbok #обработка_отклонений #erpсистемы #erp #содержание_проекта #риски_проекта #коммуникации_проекта #поставки_проекта #ресурсы_проекта #стейкхолдеры
-
Как создать систему управления проектами в ИТ-интеграторе и не выкинуть деньги на ветер
Когда у вас работают опытные спецы, встроить в работу новые правила управления проектами практически невозможно . Потому что им, ветеранам по внедрению сложнейших ERP-систем, не нужны все эти новомодные регламенты. Они уже съели собаку на таких проектах, и видели в этой жизни всё и даже больше. И, в отличие от современных домашних зумеров , совершали трудовые подвиги еще во времена, когда не было удаленки – сурово и в полевых условиях, разрываясь между несколькими внедряемыми системами в разных городах. Поэтому когда руководство говорит «Теперь будем делать проекты по-другому, системно и правильно, вот вам новый регламент» , у них возникает вопрос – а нам оно надо? Зачем нам все эти новые правила управления, как делать проекты? Почему мы должны полагаться на них, а не на свой опыт, который спасал десятки раз? Однако опыта конкретных сотрудников недостаточно, если вы, как руководитель организации, хотите спать спокойно с уверенностью в результатах. Нужна такая система управления проектами, которая превратит ваших ветеранов труда из скептиков в амбассадоров новых правил. Только в этом случае вложенные инвестиции в их разработку начнут окупаться уже через 3 месяца. Как это сделать – читайте в этой статье на примере кейса ИТ-интегратора.
https://habr.com/ru/articles/911904/
#управление_проектами #it_проекты #менеджмент #руководитель_проекта #методология #erpсистемы #внедрение
-
[Перевод] Распределенный монолит: тихий убийца мечты о микросервисах
Привет, Хаброжители! Сегодня мы делимся с Вами переводом статьи о распределенном монолите. Аннотация Привлекательность микросервисов — гибкость, масштабируемость, отказоустойчивость — часто ведет организации по пути, полному непредвиденных опасностей. В этой статье раскрывается обманчивая архитектурная ловушка: распределенный монолит. То, что начинается как, казалось бы, разумный паттерн проектирования для отделения бизнес-логики от технических проблем путем централизации «основного домена», незаметно превращается в антипаттерн, который сводит на нет все преимущества, обещанные микросервисами. Мы подробно описываем коварные симптомы: кошмары версионирования, паралич развертывания и эрозия автономии команды. На ярком примере из реальной жизни — системе «Drive» и доставки на дом Carrefour — мы раскрываем основную проблему: внутреннюю модель, удерживаемую внешними стандартами. Затем мы раскрываем освобождающие решения: принятие по-настоящему нативных бизнес-моделей и разрыв цепей общих «основных» библиотек кода в пользу явного промежуточного программного обеспечения и надежных API-контрактов. Это путь не только к коду, но и к возвращению обещаний микросервисов.
https://habr.com/ru/companies/piter/articles/961258/
#erpсистемы #микросервисы #монолит #распределенные_системы #облачные_технологии
-
Как управляются современные предприятия
Представьте крупный завод, выпускающий тысячи единиц продукции ежедневно, где каждое решение руководства должно опираться на точные данные, а не интуицию. Но как эти данные получать? Какие системы должны быть интегрированы в процесс производства? В качестве примера возьмем один известный пивоваренный завод. На этом предприятии начальник производства еженедельно анализирует круговую диаграмму, разделенную на секторы: простои из-за аварий, простои из-за переналадок и время эффективной работы оборудования. На основе этого анализа готовится доклад директору с вариантами решений. Если сектор аварий растет, руководитель службы КИП и ТОиР проводит разговор с инженерами и механиками. При увеличении времени переналадок начинается работа над оптимизацией производственного расписания. Но за этой простой диаграммой стоит сложная цифровая экосистема, состоящая из систем управления: ERP и MES. Разберемся, за что каждая из них отвечает. ERP-системы ERP-системы (Enterprise Resource Planning) выполняют роль стратегического планирования и управления ресурсами предприятия. Согласно исследуемым данным, объем рынка российских ERP в 2024 году достиг 100 млрд рублей, показав рост в 20%. [ https://www.tadviser.ru/index.php/Статья:Куда_движется_рынок_ERP_в_России_в_2025_г ] Функциональные особенности ERP формирует календарный план производства на основе стандарта MRPII (Manufacturing Resource Planning - стандартизированная методология планирования производственных ресурсов предприятия, обеспечивающая координацию материалов, производственных мощностей, финансов и персонала через замкнутый цикл планирования, исполнения и контроля):
https://habr.com/ru/articles/924464/
#erpсистемы #MESсистемы_в_производстве #Внедрение_MES #ERP_для_производства #Производственная_аналитика #цифровизация #Производственная_автоматизация #производство #MESсистема #ERPрешения
-
Реализация содержания проекта внедрения ERP-системы
Внедрение любой корпоративной информационной системы достаточно продолжительно по срокам и требует большого объема трудозатрат [1]. В среднем необходимо около одного года на имплементацию ERP-системы, а трудозатраты проектной команды со стороны исполнителя обычно колеблются в диапазоне 1000-3000 человеко-дней. Объем трудозатрат фактически задает перечень тех работ, которые обязуется выполнить интегратор для заказчика. Чем больше объем выполняемых работ, тем актуальнее становится задача по их группировке для более качественного планирования, исполнения и контроля. Именно по этой причине в [2] выделяют уровни внедрения, такие как: процессы, приложения, данные и техника, а также управление проектом и изменениями. Однако и этого деления бывает недостаточно, так как каждый уровень по прежнему остается достаточно трудоемким. По этой причине в работах [3-4] вводится понимание концепции реализации содержания проекта, заключающейся в выделении наиболее критичных областей проекта внедрения ERP-систем, а также предложении состава и порядка выполнения работ для каждой из областей. Примерами областей служат задачи, относящиеся к анализу, проектированию, разработке, миграции, тестированию и др. Состав работ определяется путем рассмотрения всевозможных способов, методов и подходов, позволяющих достигнуть необходимого результата с минимальными рисками задержки продуктивного старта ERP-системы. Объем необходимых работ дает возможность увидеть плановую потребность в человеческих ресурсах, что критично для формирования ресурсного плана проекта, а состав задач обеспечивает понимание всех тонкостей реализации предстоящего проекта. В рамках текущей статьи мы рассмотрим все критичные области ERP-проекта и суммируем способы реализации задач каждой из областей, тем самым расширяя содержание работы [4].
https://habr.com/ru/articles/813925/
#миграция_данных #анализ_требований #проектирование #разработка_приложений #обучение_пользователей #продуктивный_запуск #тестирование_продукта #erpсистемы #erpсистема #pmo
-
Использование Agile Scrum в SAP-проектах
Пожалуй, нет более популярной темы для обсуждения, чем применение Agile в проектах SAP. Несмотря на то, что принципы гибкой разработки были сформулированы ещё в 2001 году [1], их использование в настоящее время становится как никогда востребованным. Связано это в первую очередь с тем, что последнее десятилетие знаменуется массовым использованием информационных технологий (далее – ИТ) в повседневной жизни: порталы государственные услуг, интернет-магазины, электронное правительство и многое другое. Вышесказанное требует как грамотной разработки программного обеспечения (далее – ПО), так и не менее искусного его внедрения.
https://habr.com/ru/articles/802829/
#sap #sap_erp #pmo #agile #agile_scrum #scrum #erpсистемы #erpсистема #внедрение_erp #внедрение_по
-
Как не ошибиться при выборе метода замены ERP: Большой взрыв vs Parallel running
Представьте энергетическую систему международной космической станции — это комплекс солнечных батарей, аккумуляторов и другого оборудования. Его модернизация происходит постепенно, например, в 2019-2020 годах за пять выходов в открытый космос поменяли никель-водородные батареи на литий-ионные. Никто не будет менять такую систему одномоментно. Во-первых, это технически невозможно, во-вторых, слишком велика цена ошибки. Похожая ситуация с ключевыми корпоративными системами, которые отвечают за жизнеобеспечение бизнеса. Вопрос замены ERP актуален для многих компаний, так как требуется перейти на российское ПО или модернизировать технологии. На первый взгляд, задача может выглядеть неподъемной — масштаб проекта огромен, бизнес должен работать непрерывно, сроки и бюджет никто не отменял. Успех или провал во многом зависит от правильного выбора методологии замены ERP. В этой статье речь пойдет о разных подходах к миграции со старой ERP системы и вывода новой системы в эксплуатацию . Разберем, какие варианты существуют, в чем плюсы и минусы каждого, когда какой лучше использовать.
https://habr.com/ru/companies/haulmont/articles/947042/
#erp #erpсистемы #модернизация #большой_взрыв #parallel_running #замена_ERP
-
Функциональная спецификация на разработку ERP-системы на примере ABAP-отчета
Имплементация корпоративной информационной системы требует вовлечения большого числа участников для решения задач управления проектом, моделирования бизнес-архитектуры, реализации программного обеспечения, миграции данных, подготовки технической инфраструктуры и обработки изменений [1]. Ключевым содержанием подобных проектов является разработка программного продукта, а все остальные активности рассматриваются в качестве поддерживающих. Реализация программ может вестись на основе различных стратегий, следуя классическим моделям разработки: каскадной, итерационной и спиралевидной. Проекты имплементации информационных систем «с нуля» преимущественно ведутся на базе каскадной стратегии, а задачи тиражирования и развития систем в последнее время осуществляются с применением итерационных и спиралевидных подходов, например, Agile [2]. Следуя каскадной схеме внедрения программных продуктов, готовится ряд важных проектных документов, описывающих детали предлагаемого решения. В большинстве проектов имплементации систем класса ERP, создаются документы спецификаций на разработку [3]. В России действуют ГОСТ 34, посвященный разработке автоматизированных систем управления (далее – АС). Согласно ГОСТ 34.601-90 этапы разработки системы включают:
https://habr.com/ru/articles/854228/
#техническое_задание #тз #задание_на_разработку #erpсистемы #спецификация_на_разработку
-
ERP2, MES и BI системы российского производства
Обилие предложений на рынке программного обеспечения зачастую западного производства может сформировать ошибочную картину, что в России нет собственных разработок. Это далеко не так, более того российский рынок корпоративных информационных систем представлен не только линейкой продукции от 1С. Всеобъемлющее присутствие международных вендоров в стране, используемые ими маркетинговые трюки и искусственное прививание привычек, притормозили и увели в тень российские разработки. Наступает время, когда компании вынуждены идти по пути импортозамещения, даже те, кто отделился от глобальных корпораций и локализовался. В этой статье хочется провести обзор российского программного обеспечения в разрезе классов информационных систем, что продемонстрирует наличие в России работоспособных программных решений, релевантных для текущего применения уже сейчас. Разнообразие программного функционала породило необходимость использования единого терминологического аппарата, понятного всем. Так были предложены стандарты автоматизации, которые мы будем использовать для удобства повествования, это позволит нам вести обзор отечественного программного обеспечения более структурировано. Наиболее насыщенным является стандарт автоматизации ERP2, включающий в себя совокупность подстандартов: ERP2 = ERP+ (CRM + SRM + PLM + SCM) + ESB, (1) подробно описанных в работе [1]. В стандарт ERP2 входят компоненты, позволяющие автоматизировать практически все процессы в работе компании: регламентированный и управленческий учет, МСФО, взаимоотношения с поставщиками и клиентами, жизненный цикл продукта, цепи поставок и межсистемную интеграцию. Техническая реализация стандарта представляется OLTP-системами, ориентированными на обработку транзакционных данных. Рассмотрим российские программные продукты, относящиеся к данному классу стандартов и систем.
https://habr.com/ru/articles/932662/
#erpсистемы #erpсистема #erp #информационная_система #отечественное_по #российское_по
-
6 основных предпосылок для автоматизации документооборота (на самом деле нет)
Кажется, что крупные компании уж точно не страдают от проблем с согласованием договоров, соглашений, отчетов, положений. А вот и нет — даже у таких компаний эти процессы зачастую недостаточно автоматизированы. В этой статье я хочу поделиться своим видением проблемы, а также расскажу о варианте ее решения на примере кейса с поставщиком продуктов в нефтехимии «АВК». Всех, кто беспокоится о том, что документы «зависают», приглашаю под кат.