Как достичь реальной эффективности производственно-логистической системы

Питеркин С.В., CPIM

Аннотация

Борьба за «эффективность производства» в РФ, для подавляющего большинства предприятий переходит в вялотекущую стадию. Объясняется это тем, что хорошо разрекламированные методы, как давно и успешно используемые «там» (Lean (Бережливое производство), автоматизация с ERP/APS/MES/… системами), так и «новомодные», типа Industry 4.0 либо не дают вообще никаких улучшений эффективности, либо дают непропорционально малые по сравнению с затраченными усилиями или ожиданиями, либо просто не запускаются.

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

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

Важные комментарии

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

Рано или поздно у любой ИТ компании (аутсорс или продуктовой) возникает желание организовать собственное пространство, где можно хранить информацию по проектам, сотрудникам, продажам. Вести рабочую переписку и обсуждать задачи/стратегии/документы. Чаще всего, такие компании начинают кодить все сами или пилят что-то для Битрикс24 и тд. В данной серии статей я расскажу о нашем велосипеде — опыте автоматизации процессов. Как положено, почти все self-hosted, opensource и постараемся обойтись почти без кодинга.

Так, собираем истории самых шизанутых собеседований, приемов на работу и компаний, где вам приходилось бывать. Мне как-то везло обычно, сильно больших отклонений от нормы не встречал. Ну там полиграф бывал, посылать интервьюера приходилось, однажды даже устроил обратное собеседование – начальник ИТ, узнав мою зарплату на текущем месте, захотел ко мне работать пойти, даже простым программистом.

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

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

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

Все вы, наверное, слышали, что 1С-ники жалуются на свою систему, считая язык 1С недостаточно низкоуровневым, скучным и т.п. Все они с тоской поглядывают в сторону "настоящих" языков программирования. Так вот, господа, они неправы. В системе 1С есть места, где можно размять программерский мозг и получить удовольствие от низкоуровневой техники. Предлагаю вам погрузиться в недра виртуальной машины 1С и понять, как она работает. Там есть свой "ассемблер" и сегодня мы будем писать на нем рабочий код для 1С. Заходите под кат, будет весело!

Мне часто говорят – эй, где технические статьи? Чё ты всякую чушь пишешь, про менеджеров, директоров, отношения с персоналом, корпоративные дрязги, ноешь про бессмысленность нашей работы и вообще. Мы хотим технические статьи!

Я, если честно, плохо понимаю, что такое «технические статьи». Я понимаю, что такое «задача» и что такое «решение». Еще я понимаю, что решение одной и той же задачи можно найти на разных уровнях – от «железного» до философского. Какой уровень правильнее – не знаю.

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

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

Всем привет! 11 февраля в офисе Lamoda прошел Dynamics 365 & Power Platform Meetup. В гости пришли 80 человек, трое из которых прилетели к нам аж из Владивостока :)



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

Написать эту статью я решил после посещения одного офиса – там не оказалось черного чая. Зеленого было полно, а черного не было. И с кофе были перебои.

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

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

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

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

Эти статьи не несут собой целью рассказать миру о том, какой я крутой реализатор или о том, что я лучше всех знаю как надо реализовывать такие проекты. Если вы скажете, что это «очередная статья неудачника, который ну прямо все понимает неправильно» — это тоже будет для меня ценностью, так как ожидаю, что кто-то поделится своими соображениями в комментариях.

Пятый и завершающий пост о моём знакомстве с Vue Storefront. IMHO, самым современным с технической точки зрения решением в сфере e-commerce на данный момент. Ссылки на предыдущие посты:

• Vue Storefront: Второй подход к снаряду
• Vue Storefront: Поднимаем backend
• Vue Storefront: Заливаем данные в ES
• Vue Storefront: Импорт каталога из Magento 2

Под катом краткое описание особенностей этого этапа и итоговое резюме.

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

Привет, Хабр!

Продолжаем исследовать применимость принципов функционального программирования при проектировании ERP. В предыдущей статье мы рассказали зачем это нужно, заложили основы архитектуры, и продемонстрировали построение простых сверток на примере оборотной ведомости. По сути, предлагается подход event sourcing, но за счет разделения БД на иммутабельную и мутабельную часть, мы получаем в одной системе комбинацию преимуществ map / reduce-хранилища и in-memory СУБД, что решает как проблему производительности, так и проблему масштабируемости. В этой статье я расскажу (и покажу прототип на TypeScript и рантайме Deno), как в такой системе хранить регистры мгновенных остатков и рассчитывать себестоимость. Для тех, кто не читал 1-ю статью — краткое резюме:

1. Журнал документов. ERP, построенная на базе РСУБД представляет собой огромный мутабельный стейт с конкурентным доступом, поэтому не масштабируется, слабо-аудируема, и ненадежна в эксплуатации (допускает рассогласование данных). В функциональной ERP все данные организованы в виде хронологически-упорядоченного журнала иммутабельных первичных документов, и в ней нет ничего кроме этих документов. Связи разрешаются от новых документов к старым по полному ID (и никогда наоборот), а все остальные данные (остатки, регистры, сопоставления) являются вычисляемыми свертками, то есть кэшируемыми результами работы чистых функций на потоке документов. Отсутствие стейта + аудируемость функций дает нам повышенную надежность (блокчейн на эту схему прекрасно ложится), а бонусом мы получаем упрощение схемы хранения + адаптивный кэш вместо жесткого (организованного на базе таблиц).

Привет, Хабр! Сегодня мы хотели бы поговорить с вами об устройстве такого явления, как SAP-хостинг. В ходе статьи мы:

• расскажем о нашем опыте взаимодействия с компанией itelligence в формате построения совместной услуги;
• обсудим рыночные причины перехода бизнеса к облачным провайдерам от on-premise решений;
• аргументированно разберем отличия модели SAP-хостинга от on-premise и сравним затраты;
• рассмотрим некоторые сценарии миграции из on-premise в облако.

В интерфейсе каждого современного приложения в том или ином виде присутствуют списки объектов. При работе с ними у пользователя часто возникают потребности в однотипных действиях вроде сортировки, фильтраций, экспорта и так далее. Реализация этих операций часто осложняется тем, что списки могут быть “динамическими”. В этом случае данные будут по мере необходимости считываться не только с сервера на клиент, но и с сервера базы данных на сервер приложений.

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

Подсистема складского учета в программном продукте «1С.Комплексная автоматизация 2» позволяет работать с моделью ордерного склада и использовать адресную схему хранения. С ее помощью появляется возможность реализовать следующие требования:

✓ Организовать процесс адресного хранения товаров в складских ячейках.

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

✓ Автоматически размещать поступающий товар в ячейки в соответствии с настраиваемыми в подсистеме правилами размещения.

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

✓ Получать в удобном виде информацию о текущем распределении товара по ячейкам склада в любой момент времени.

✓ При соответствующей настройке, в подсистеме возможно использовать специализированные электронные устройства, например, терминал сбора данных (ТСД) или сканнер штрих-кодов. Это позволяет заменять ручной ввод и значительно минимизировать ошибки.

✓ Разделять процесс приемки и отгрузки на уровне отдельных автоматизированных рабочих мест. Использовать мобильные рабочие места сотрудников склада.

✓ Отражать общие операции товародвижения: перемещение, сборка/разборка товаров, порча, оприходование, пересортица и другие.

В нескольких словах дадим определение адресному складу. Что же подразумевается под этим термином? Адресный склад – это по сути процесс оптимизации хранения товара на складе, при котором склад разбивается на множество ячеек, за каждой из которых закрепляется уникальный идентификатор – адрес, отличающий ее от остальных ячеек. Ячейки, в свою очередь, объединяются условиям хранения товаров, по их назначениям, по характеристикам размещаемых товаров.

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

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

Главное – принципы и подход

Опыт управления в ресторанном бизнесе более пяти лет помог теперешнему руководителю мне построить IT-компанию, где сейчас работает более 30 программистов, а география проектов — Польша, Беларусь, Россия, Казахстан и другие страны ближнего зарубежья.

Эта компания была создавалась нуля, постепенно она становится сервисной. Бизнес последние два года дает ежегодный прирост в 15 % каждые.

Напрашивается вполне резонный вопрос: как, не будучи программистом, мне удалось основать перспективный и рентабельный IT-бизнес?

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

У нас изначально действует несколько принципов, которых партнеры и сотрудники не нарушают по сей день:

1. Клиенту надо давать больше, чем он ожидает.
2. Клиенту здесь не продают часы, а дают решение задачи и проблемы.
3. Клиент прозрачно должен понимать, как обстоит ситуация с проектом и первым узнавать о всех проблемах, которые появились.

Привет, Хабр!

В этой статье мы попробуем взглянуть на архитектуру учетных систем (ERP, CRM, WMS, MES, B2B, ...) с позиций функционального программирования. Существующие системы сложны. Они базируются на реляционной схеме данных, и имеют огромный мутабельный стейт в виде сотен связаных таблиц. При этом единственным «источником правды» в таких системах является хронологически-упорядоченный журнал первичных документов (отпечатков событий реального мира), которые, очевидно, должны быть иммутабельными (и это правило соблюдается в аудируемых системах, где корректировки «задним числом» запрещены). Журнал документов составляет от силы 20% объема БД, а все остальное — промежуточные абстракции и агрегаты, с которыми удобно работать на языке SQL, но которые требуют постоянной синхронизации с документами, и между собой.

Если вернуться к истокам (устранить избыточность данных и отказаться от хранения агрегатов), а все бизнес-алгоритмы реализовать в виде функций, применяемых непосредственно к потоку первичных документов — мы получим функциональную СУБД, и построенную на ней функциональную ERP. Проблема производительности решается благодаря мемоизации, а объем функционального кода будет вполне соизмерим с объемом декларативного SQL, и не сложнее для понимания. В данной статье мы продемонстрируем подход, разработав простейшую файловую СУБД на языке TypeScript и рантайме Deno (аналог Node.js), а также протестируем производительность сверток на примере типичных бизнес-задач.

Почему это актуально

1) Мутабельный стейт + избыточность данных — это плохо, особенно когда необходимо обеспечивать его постоянную синхронизацию с потоком документов. Это источник потенциальных расхождений учетных данных (баланс не сходится) и трудно обнаруживаемых побочных эффектов.

Привет, Хабр!

После того, как несколько моих коллег независимо друг от друга прислали линк к этой статье, мне подумалось, что, возможно, она будет полезна и для тех, кто не говорит по-немецки. Посему предлагаю Вашему вниманию перевод статьи из немецкой версии журнала CIO от 30 декабря 2019.

Ваш,

m_OO_m

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

LIDL, Почта Германии (Deutsche Post), Немецкий Банк (Deutsche Bank) и Отто: список проваленных проектов по внедрению SAP в больших немецких концернах можно продолжать долго. Шеф Liqui Moly Эрнст Прост (Ernst Prost) выразился по поводу провала проекта по внедрению Microsoft AX на своем предприятии следующим образом: «Это хуже, чем Брексит, Трамп и торговые войны» — возмущался он во Всеобщей Франкфуртской Газете (Frankfurter Allgemeine Zeitung) 10.07.2019. То есть, не играет роли, о какой ERP системе идет речь – не она, в первую очередь, виновата в возникших проблемах. Гораздо более вероятно, что проект по внедрению Системы Управления Предприятием провалился из-за одной из следующих причин…

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

Выводы по итогам чтения доклада:

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

Для кого статья

Если вы что-то производите на заказ, то вы наверняка сталкивались с простоями из-за отсутствия достаточного количества проектов.

Если у вас высока доля переменных затрат, то все ок — вы сокращаете производство и затраты сокращаются. Но если наоборот, превалирует доля постоянных затрат, то встает вопрос привлечения объема заказов, необходимого для покрытия постоянных расходов.

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

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