ERP-системы *

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

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

В процессе работ был доработан функционал ввода информации на основании документа «Заказ переработчику» для обеспечения минимизации ошибок и для значительного ускорения этого процесса в системе «1С:ERP Управление предприятием». Для реализации данной задачи было:

- разработано расширение, которое позволило снять ограничения использования номенклатуры с видом запасов «давальческие материалы» при вводе документов на основании «Заказа переработчика»;

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

В итоге мы разработали решение «Автоматизация субдавальческой схемы» на основе программы «1С:ERP Управление предприятием». Благодаря этой разработке стало возможным улучшить и сделать удобной работу любой компании, которая пользуется услугами субподрядчиков и передает им материалы для выполнения отдельных технологических операций. Теперь такие операции корректно можно отразить в программе «1С:ERP Управление предприятием», избежать налоговых рисков и облегчить работу бухгалтеров с документами.

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

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

Причиной отсутствия роста производительности и распространения спекуляций в строительной отрасли является качество данных, которыми оперируют участники процессов строительства. В чем основная проблема данных в строительстве? В первую очередь, в отсутствии доверия и прозрачности в системах 3D-7D, что ведёт к появлению рисков, связанных с человеческим фактором, и созданию многоуровневой бюрократии в основных бизнес-процессах строительных компаний.

Сегодня при обмене данными между различными 3D-7D системами мы доверяем хранение наших данных корпорациям. Для поддержания своего влияния на строительную отрасль корпорации, которым невыгодна прозрачность и интероперабельность данных, монополизировали хранение и обработку данных. Вследствие этого поставщики основных CAD и ERP решений постоянно повышают цены за пользование своими продуктами, а простые пользователи вынуждены платить “комиссию” на каждом этапе передачи данных в системах 3D-7D: за подключение, импорт, экспорт и работу с данными, которые пользователи сами создали. 

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

Моя предыдущая статья о том, как корпоративные ERP-системы делают сотрудников неэффективными, оказалась неоднозначной и ваши мнения разделились - это ожидаемо.

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

Если я вижу в заголовке статьи на Хабре, названии доклада на конференции или в статье в СМИ слова «цифровая трансформация», я всегда знаю — будет пресно, скучно и много лжи. Из этого словосочетания делают волшебную палочку: цифровая трансформация как способ освоения бюджетов, цифровая трансформация как повод уволить сотрудников, цифровая трансформация как повод объяснить провалы сервиса, цифровая трансформация как способ поднять репутацию на модном тренде. При этом для многих за этими словами скрывается что угодно, кроме первоначального, идейного смысла. На фоне этого проваливаются более 70% проектов трансформации по всему миру. И так будет, пока в эти два красивых слова будут вкладывать всё что угодно, кроме принятия цифровых технологий внутри всех процессов управления. И это касается и гигантов рынка, и самых небольших компаний. Так почему мы все трансформируемся, трансформируемся, да так и не вытрансформируемся?

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

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

Содержание цикла статей: https://github.com/nomhoi/empire-erp.

Сегодня начнем рассматривать аналитический учет.

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

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

С тех пор как мы начали использовать CRM технологии в работе, около 10-ти лет назад, мы постоянно улучшали процессы компании и старались многое автоматизировать. И когда уровень автоматизации достиг того, что вся работа сотрудников в компании осуществлялась только в программе, тогда и настало то время для отслеживания исполнения SMART-задач. Более подробно остановлюсь именно на них, хотя мы используем еще и другие инструменты.

Самым простым решением оказался бизнес-процесс «Поручение». Он закрывает практически все потребности, связанные с постановкой, исполнением и контролем задач. Но были и более экзотические варианты, когда мы набирались опыта в этом вопросе.

В первой части серии статей про работу с адресами по КЛАДР мы научились импортировать данные этого справочника к себе в базу и превращать их во что-то более удобное для дальнейшей работы.

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

Все больше ABAP разработчиков используют в разработке различные CDS. Внутри CDS можно выбирать данные из таблиц и выполнять некоторые манипуляции с выборками через AMDP-методы и виртуальные элементы. Однако выбрать, например, SAPScript-тексты в CDS не получится, так как тексты хранятся в таблице в бинарном виде. Расскажу о собственном решении и о найденном позже стандартном.

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

Проработав 20 лет в ИТ, 8 из которых в должности CIO, а последние 5 в роли CEO ИТ-компании, я решил написать статью для тех, кто причастен к управлению цифровизацией бизнеса – собственников, CFO, CEO – но не имеет опыта ИТ-менеджера или ИТ-директора.

Речь пойдет о стоимости и рисках принятия управленческих решений по разработке ИТ-систем внутри НЕ ИТ-компаний.

Достаточно часто при работе с вводимыми пользователем адресными данными возникает необходимость сначала подсказать ему, как правильно свой адрес указать, а потом - полученную строку адреса привести в некоторый машинно-читаемый вид.

Таким видом у нас в стране можно считать код по справочникам КЛАДР или ФИАС.

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

Давайте научимся разбирать строку адреса "туда и обратно", а заодно познакомимся с некоторыми алгоритмическими подходами и их реализацией на SQL.

Часть 1: CRM для ERP

Часть 2: Роботизация бизнес-процессов

Часть 3: Волшебные интерфейсы и оживление железа

Часть 4: Автоматические личные кабинеты и чат-боты

Часть 5: Автоматизация на производстве (в этой публикации)

Привет! Меня зовут Валентин Щитов, я CIO компании «‎Магнит». 

До момента прихода в «Магнит» весной 2020 года я руководил IT-департаментом большого e-commerce проекта и за 10 лет сформировал полное представление, как работает онлайн-ритейлер. 

Однако и офлайн-ритейлер с историей в четверть века меня удивил. Приятно или нет — расскажу дальше.

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

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

Одним из таких новых средств визуализации является единое цифровое окно!

Потихоньку начинаю задумываться, на какой технологии буду «въезжать» в пенсионный возраст. Почитываю статьи о том, как люди после 30 лет учатся или переучиваются, какие испытывают трудности в трудоустройстве. Оно и понятно – «старых коней» обычно берут только на технологии, которыми они уже владеют. Самому мне под 40, если что.

Я и сам принимал на стажировку людей в возрасте 35-45 лет, остался только один – чрезвычайно упёртый. Остальные сами убегали, кто через неделю, кто через квартал. Хотя рядом сидят 22-летние студенты, которые и не думают никуда сбегать.

Что интересно – они именно сбегают, причём – назад. Туда, откуда пришли. Если человек с завода, где работа была – не бей лежачего, туда он и спешит вернуться. Если был так-себе-менеджером по продажам, но с инженерным образованием, то быстро сбегает обратно – принимать звонки и оформлять заказы.

Судя по отзывам тех, кто ушёл и тех, кто остался, сбегать заставляет страх. Понятный, даже выраженный в упускаемых деньгах страх не состояться в новой профессии или технологии. Вот и бегут от неё, технологии.

Однако случается, что технология сама приходит к человеку, не спрашивая его мнения. И бежать ему особо некуда, ибо собственные знания продать особо некому – они безнадёжно устарели. Но на заводе, где сидит «возрастной» программист, за эти знания пока платят. Ровно до тех пор, пока старая, уютная, тёплая ламповая информационная система не будет заменена новой, дорогой, блестящей и высокотехнологичной (возьмите в кавычки любое слово, если хотите).

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

Содержание цикла статей: https://github.com/nomhoi/empire-erp.

Попробуем спроектировать базу данных модуля "Бухгалтерия" на PostgreSQL.

В статье приведено описание подхода к решению задачи планирования производства в существующей и работающей системе APS Mespace/APS. Показано теоретическое обоснование высокой скорости работы системы. Приведен подход, сводящий сложность задачи из области конструирования алгоритма в область подбора функций специального вида. Данный подход потенциально может оказать влияние на пути решения сложных задач, в том числе эквивалентности классов P и NP.

Традиционно путь от идеи до ее воплощения выглядит так, словно вначале в статье описывается идея, затем по ней возникает воплощение. Однако на практике обычно всё наоборот и статья является лишь подведением итогов работы. Не будем отступать от реальности. В этой статье изложены результаты реализации системы планирования. Задача планирования производства хорошо известна, состоит из двух связанных подзадач - составления списка всех работ (разузлования) и составления расписания, то есть планирования этих работ на исполнители, и достаточно хорошо описана, например, в классическом труде Пинедо.

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

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