Erp

Складская программа C2 WMS 1.1

28.08.2020 16:14:16 |

Автор: admin

Здравствуйте, уважаемые коллеги!

Представляю вашему вниманию исходный код проекта C2 WMS.

Складской программы-платформы, которая использовалась в одном из магазинов запчастей Беларуси в связке с 1С: Бухгалтерия 8.

C2 выросла из приложения Android, поэтому некоторые решения могут вам показаться странными.

Есть ли велосипеды? ДА.
Есть ли ошибки? ДА.
Архитектурные ляпы? ДА!

Часто C2 WMS писалась на коленке на передовой во время вражеской бомбардировки, когда не было времени на красивые решения, а применялись быстрые.

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

Год успешной эксплуатации это показал во всей красе.

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

Почему выкладываются исходники успешной системы?

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

Анализируйте. Внедряйте. Улучшайте.

Блог программы
Скачать

КУПЛЯЙЦЕ БЕЛАРУСКАЕ!

Подробнее..

Категории: Diy или сделай сам , Diy , Java , Erp-системы , Mysql , Цифровизация , Erp , 1с , Склад , C2_wms , Wms

Как мы ускоряли время разгрузки товара на складе

14.07.2020 14:04:30 |

Автор: admin

Терминал сбора данных Zebra WT-40 со сканером-кольцом. Нужен для того, чтобы была возможность быстро сканировать товар, при этом укладывать физически короба на паллету (свободные руки).

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

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

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

История началась шесть лет назад, когда мы присмотрелись к тому, как именно поставщики разгружают фуры у нас на складе. Это было настолько нелогично, но привычно, что сотрудники даже не замечали неоптимальности процесса. Более того, в тот момент у нас не было промышленной системы управления складом, и в основном логистические операции мы доверяли 3PL-операторам, которые использовали свой софт и опыт в построении процессов.

Приёмка товара

Как мы уже говорили, наша компания на тот момент (как, в принципе, и сейчас) стремилась открыть много магазинов, поэтому пришлось оптимизировать складские процессы для увеличения пропускной способности (больше товаров за меньшее количество времени). Это непростая задача, и решить её, просто увеличив персонал, было нельзя хотя бы потому, что все эти люди будут друг другу мешать. Таким образом, мы начали думать о внедрении информационной системы WMS (warehouse management system). Как и полагается, мы начали с описания целевых складских процессов и уже в самом начале обнаружили непаханое поле для улучшений в процессе приёмки товара. Нужно было отработать процессы на одном из складов, чтобы потом накатить их на остальные.

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

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

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

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

Стало так:

Поставщик сам заполняет данные о том, что отправляет к нам и когда. Для этого есть связка из SWP и EDI-порталов. То есть магазин публикует заказ, а поставщики берутся выполнить заявку и поставить товар в нужном количестве. Они же при отправке товара указывают состав паллет в фуре и всю необходимую информацию логистического характера.
Когда машина уехала от поставщика к нам, мы уже знаем, какой товар к нам идёт; более того, с поставщиками налажен электронный документооборот, поэтому мы знаем, что УПД уже подписан. Готовится схема оптимального перемещения этого товара: если это кросс-докинг, то мы уже заказали транспорт со склада, рассчитывая на товар, а также для всех логистических потоков мы уже определили, какое количество складских ресурсов нам понадобится для обработки поставок. В деталях для кросс-докинга предварительный план по транспорту со склада делается на более раннем этапе, когда поставщик только зарезервировал слот на поставку в системе управления складскими воротами (YMS yard management system), которая интегрирована с порталом поставщика. Информация приходит в YMS сразу.
YMS получает номер грузовика (если быть точнее, то номер отгрузки из SWP) и записывает водителя на приёмку, то есть отводит ему необходимый слот времени. То есть теперь водителю, который приехал вовремя, не нужно ждать живой очереди, а под него отведены его законное время и док разгрузки. Это позволило нам, кроме всего прочего, оптимально распределять грузовики по территории и эффективнее использовать разгрузочные слоты. А ещё, поскольку мы заранее составляем график, кто, куда и когда приедет, то знаем, сколько людей и где нужно. То есть это ещё связано с рабочими графиками сотрудников склада.
В итоге этой магии грузчики уже не нуждаются в дополнительной маршрутизации, а лишь ожидают машины для их разгрузки. Фактически их инструмент терминал говорит им, что делать и когда. На уровне абстракции это как API грузчика, но в human-computer interaction-модели. Момент сканирования первой паллеты с грузовика это ещё запись метаданных по поставке.
Разгрузка пока делается всё так же руками, но по каждой паллете грузчик проводит сканером штрихкодов и подтверждает, что данные этикетки в порядке. Система контролирует, чтобы это была правильная паллета, которую мы ожидаем. К концу разгрузки в системе будет точный пересчёт всех грузовых мест. На этой стадии ещё отсеивается брак: если есть явные повреждения транспортной тары, то достаточно просто отметить это в процессе разгрузки или вовсе не принять этот товар, если он совсем негодный.
Раньше паллеты пересчитывались в зоне разгрузки после того, как все будут выгружены из машины. Сейчас уже процесс физической выгрузки является пересчётом. Брак мы возвращаем сразу же, если он очевидный. Если он неочевидный и обнаруживается потом, то мы накапливаем его в специальный буфер на складе. Гораздо быстрее прокинуть паллету дальше в процесс, собрать с десяток таких и дать возможность поставщику забрать всё сразу за один отдельный приезд. Некоторые виды брака переводятся в зону утилизации (это часто касается зарубежных поставщиков, которым проще получить фотографии и прислать новый товар, чем принимать его обратно через границу).
В конце разгрузки подписываются документы, и водитель уезжает дальше по своим делам.

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

Что дальше происходит с товаром?

Дальше, если это не кросс-докинг (и товар уже не уехал в буфер перед отправкой или прямо в док), то его нужно положить в сток на хранение.

Нужно определить, куда этот товар пойдёт, в какую ячейку хранения. В старом процессе нужно было зрительно определить, в какой зоне мы храним товары данного типа, и потом выбрать там место и отвезти, положить, записать, что положили. Сейчас у нас настроены маршруты размещения по каждому товару по топологии. Мы знаем, какой товар в какую зону и в какую ячейку должен попасть, знаем, сколько ячеек занять дополнительно рядом, если это негабарит. Человек подходит к паллете и сканирует её SSCC с помощью ТСД. Сканер показывает: Вези в А101-0001-002. Дальше он везёт туда и отмечает, что положил, тыкая сканером в код на месте. Система проверяет, что всё правильно, и отмечает. Ничего писать не нужно.

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

Итак, в системе сток обновляется в момент приёмки заказа. А запас ячейки в момент постановки паллеты в неё. То есть мы всегда знаем, сколько товара есть на складе итого и где какой лежит конкретно.

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

Обратные потоки брака тоже слегка оптимизированы: если товар на кросс-докинге, то поставщик может забрать его со склада в Москве. Если брак вскрылся уже после открытия транспортной упаковки (и снаружи это было непонятно, то есть он появился не по вине транспортников), то есть зоны возврата в каждом магазине. Брак можно забросить на федеральный склад, а можно отдавать поставщику прямо из магазина. Второе случается чаще.

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

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

По складским процессам большие улучшения заключались в том, чтобы автоматизировать то, что раньше было бумагой, избавиться от лишних этапов в процессе за счёт оборудования и правильно настроенных процессов и соединить все ИТ-системы компании в единое целое, чтобы заказ из ERP (например, в магазине чего-то не хватает на третьей полке слева) в конечном итоге превращался в конкретные действия в системе складского хранения, заказа транспорта и так далее. Сейчас оптимизация больше касается тех процессов, до которых мы ещё не добирались, и математики прогнозирования. То есть эпоха бурного внедрения закончилась, мы сделали те 30 % работы, которые дали 60 % результата, и дальше надо постепенно покрывать всё остальное. Либо двигаться на другие участки, если там можно сделать больше.

Ну и если считать в спасённых деревьях, то переход поставщиков на EDI-порталы тоже очень много дал. Сейчас практически все поставщики не звонят и не общаются с менеджером, а сами в личном кабинете смотрят заказы, подтверждают их и везут товар. По возможности отказываемся от бумаги, с 2014 года уже 98 % поставщиков на электронном документообороте. В общей сложности это сохранённые 3 000 деревьев за год только на отказе от распечатки всех нужных бумаг. Но это без учёта тепла от процессоров, но и без учёта сэкономленного рабочего времени людей вроде тех же менеджеров на телефоне.

За пять лет у нас стало в четыре раза больше магазинов, в три раза больше различных документов, и, если бы не было EDI, у нас было бы в три раза больше бухгалтеров.

Мы не останавливаемся на достигнутом и продолжаем подключать к EDI новые сообщения, новых поставщиков к электронному документообороту.

В прошлом году мы открыли крупнейший распределительный центр в Европе 140 тыс. кв. м и взялись за его механизацию. Об этом я расскажу в другой статье.

Подробнее..

Категории: It-инфраструктура , Управление проектами , Разработка , Оптимизация , Автоматизация , Блог компании леруа мерлен , Erp , Склад

CRM-системы не существуют?

25.08.2020 18:19:47 |

Автор: admin

Привет, Хабр! 22 апреля этого года я написал на Хабр статью про скидки на CRM-системы. Тогда мне казалось, что цена важнейший критерий выбора, а всё остальное я легко решу со своими мозгами и опытом сисадмина. Шеф ждал от меня скорых чудес, сотрудники расселись бездельничать работать по домам, ковид ходил по планете, я выбирал систему мечты. Сегодня 25 августа, и система пока не выбрана, хотя фавориты и определены. Мы с парой коллег прошли через пару десятков презентаций, через мегабайты писем, чатов и голосового трафика. И я неожиданно пришёл к интересному выводу: CRM не существует. Ни одной. Так-то, друзья. И это не кликбейтный заголовок, это аналитическое наблюдение.

Следите за руками

Мой первый пост на Хабре, который написан в апреле, а кажется, вчера.

~~Адская работа, только из дома~~ самоизоляция подарила мне немного лишнего времени но не потому что я мало работаю, а потому что не торчу в дороге суммарно около трёх часов. Вопроса, чем заняться, не стояло я с маниакальным упорством продолжил тестировать CRM-системы, потому что мой шеф хочет выйти из кризиса автоматизированным до зубов и работать по-новому. Его устремления я, конечно, разделяю, но копаться в полутора десятках программ так себе развлечение. Поэтому, дабы разнообразить свою жизнь, я решил подходить к выбору с неоднозначных сторон и периодически писать о наблюдениях сюда, на Хабр.

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

Microsoft Dynamics CRM выбыли из шорт-листа по причине дороговизны и необходимости покупки ряда коннекторов из-за российского учёта
Sales Creatio выбыли из шорт-листа по причине чрезмерной дороговизны и необходимости покупать дополнительную версию ради пары функций
Bitrix24 в шорт-листе
amoCRM в шорт-листе
RegionSoft CRM в шорт-листе
CRM Простой Бизнес в шорт-листе
Клиентская база выбыли из шорт-листа из-за скромной функциональности и некоторых технических особенностей, которые мне пришлись не по душе
Мегаплан выбыли из шорт-листа, т.к. проиграл конкурентам из своей же лиги под крылом 1С
FreshOffice в шорт-листе

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

Итак, моё новое наблюдение: CRM в Россиинет! Если исходить из строгого определения CRM-системы, их в моём списке не существует.

Вообще, я сейчас немного лукавлю: ни одно из выбранных решений нельзя назвать ни ERP, ни CRM, ни BPM. Это универсальные решения с огромным набором возможностей.

Короче, к теме.

Образ CRM в вакууме

Что такое CRM?

Возьмём определение из Википедии: система управления взаимоотношениями с клиентами (CRM, CRM-система, сокращение от англ. Customer Relationship Management) прикладное программное обеспечение для организаций, предназначенное для автоматизации стратегий взаимодействия с заказчиками (клиентами), в частности для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процессов и последующего анализа результатов.

То есть можно выделить несколько типичных признаков CRM-системы.

Она автоматизирует стратегию то есть заменяет часть рутинных процессов программируемыми действиями машины и предоставляет интерфейсы для быстрой и продуктивной работы на всём цикле работы с клиентами.
Она направлена на продажи, маркетинг и поддержку CRM работает со всеми аспектами коммерческой деятельности компании. Важно, чтобы все три подразделения имели доступ к информации в CRM.
Она сохраняет накопленную информацию в СУБД накапливается, обрабатывается и сохраняется информация о сделках, клиентах, ключевых событиях и проч.
Она направлена на анализ результатов благодаря накоплению и сохранению информации CRM-система предоставляет аналитические функции.

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

Как я видел CRM до того, как закопался в тему

У меня в компании продажники и менеджеры довольно пассивные в плане ПО не барское это дело. Поэтому с требованиями у нас средненько: я выбивал их из них практически насильно. Зато я и мой босс чётко видели: пришёл клиент, его внесли в CRM, потом позвонили из CRM, где-то прикрепили документы, посмотрели, сколько этапов он прошёл, закрыли сделку. Потом взяли, проанализировали этапы, кого надо наградили, кого надо поругали, процесс оптимизировался, ура. Для нас CRM была системой для продаж.

Как я вижу CRM после почти 5 месяцев аналитической работы

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

Но как-то так вышло, что начал я с Microsoft Dynamics CRM и это решение, несмотря на сложности и цены, задало несколько иной уровень, а точнее зародило первую мысль: А вдруг мне не нужно покупать ещё и складскую программу? И я нашёл решения со складом на борту, целых четыре! А затем, выслушав презентации других CRM, сидя за спиной своей коллеги, понял, что современные CRM это вполне себе многофункциональные системы, которые могут очень многое. Но а CRM ли это? Не получится ли гиперавтоматизация у бизнеса, который ждал автоматизацию продаж, а получил всё и сразу? Нужна ли она, такая автоматизация? Моя голова полна мыслей я за всю свою админскую и менеджерскую жизнь не думал столько о программном обеспечении!

Если что, я выбираю CRM не для какой-нибудь корпорации, а для небольшой компании, которая занимается оптовыми продажами скучных товаров в B2B. Нас всего 17, но CRM нужна каждому по разным причинам. Почему тогда я так долго копаюсь? Признаюсь, по своей инициативе: хочу найти действительно оптимальное решение по нормальной цене и с минимумом доработок. Мечтатель!

Вот какие CRM не CRM я выделил.

Скорее, BPM с функциями CRM

Вообще я старался избегать решений с BPM на борту, особенно в нотации BPMN. Во-первых, я не очень вижу, как мы сможем выстроить бизнес-процессы в компании, во-вторых, у меня штат такой: я, шеф и толпа коммерческого отдела и продажников, которые не то что BPMN, Excel, как огня, боятся. Однако за время тестирования CRM (а их было уже 17, просто некоторые выбыли ещё на первом созвоне) я понял, что процессы в CRM-системе (не CRM?) быть должны, потому что это сильно упрощает жизнь менеджеров: представьте, вы чётко знаете, что нужно делать, кто и когда должен это сделать, всё это записано, напоминает и шлёт письма. Чудесная история, в которую можно обернуть любую сделку, заключение договора, процесс найма и обучения, отгрузку, промоакцию, да что хочешь.

И да, бизнес-процессы в их хорошей реализации есть в нескольких решениях на рынке. Из тех, что мы с вами ковыряем, процессы в нотации BPMN 2.0 есть в Sales Creatio, в тех или иных нативных формах мне понравились бизнес-процессы в RegionSoft CRM и Bitrix24 они, если фигурально выразиться, человечные, внятные. Нет, надежд, что менеджер по продажам удобрений Иван справится с ними, конечно, у меня нет, а вот то что он спокойно разберётся, как работать с настроенными цепочками в системах, я уверен. Кстати, консультанты amoCRM активно продвигают мысль о том, что воронка продаж это и есть бизнес-процесс ну тут не поспоришь, но это один процесс, все остальные на этом не выстроишь, нужно докупать дорогущее решение третьей стороны и поллитру к нему, чтобы разобраться, ну или партнёры сами настроят процессы в этой штуковине, но за дорого.

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

Скорее, ERP с функциями CRM

Вот здесь всё сложно, потому что универсальность достигает абсолютного пика, но возникают вопросы, как с эти решением обходиться. Первое впечатление это как купить Dodge RAM-3500, а потом думать, как проехать по узким улицам в районе Остоженки, например. Но ведь это ещё и перспективы, и новые широкие возможности, а значит, не всё так однозначно. Итак, если вы не знали, ERP-система это программное обеспечение, которое помогает интегрировать операционную деятельность, производство, управление персоналом, финансовый менеджмент и т.д. Общая модель данных в таких системах помогает оптимизировать и вовремя восполнять ресурсы, выстраивать процессы. Быть полноценной ERP-системой сложно, потому что это история про бюрократические тендеры, какие-то сложные производства, долгосрочные ступенчатые внедрения и т.д. Если честно, я бы сам не хотел связаться с привыкшим к этому уставшим erp-шником. А вот от склада я бы не отказался, и от производства, возможно, тоже.

Всё, что мне нужно с точки зрения дайте кусочек от ERP, я нашёл в двух системах: Microsoft Dynamics CRM и RegionSoft CRM. Майкрософтовское решение хорошо выстраивается под любые задачи, но это выстраивание, как выяснилось, требует больших денег, поскольку CRM/ERP универсальная для международных норм, а в России много специфики и, как следствие, доработок, за которые нужно платить партнёрским компаниям. Когда ты малый бизнес и осознаёшь масштаб, кажется, что тебя сейчас раздавят. Ну или настроение у меня такое карантинное было. Microsoft Dynamics CRM интересное решение, которое само по себе почти ERP (она есть и отдельно), но мне всё больше кажется, что это история для крупных компаний или для международного бизнеса. Я впервые столкнулся с их решениями такого класса и приятно удивлён.

И вот тут, как ни удивительно, RegionSoft CRM хорошо закрывает потребности именно малого бизнеса (думаю, и среднего, и большого, но что о них думать о нас бы кто подумал), поскольку просто устроена, внятно связана между модулями и включает вообще всё: KPI, склад, производство, кое-что из финансового учёта, управление проектами, мультивалютный учёт, кассу, карты лояльности и проч. Короче, есть всё вообще всё, что в современной бизнес-системе можно увидеть. Правда, совсем-совсем всё это доступно в старшей редакции, которая стоит дороже базовой комплектации а кому-то и менее навороченных редакций хватит, вероятно. Но по конечному итогу значительно дешевле Microsoft-а это раз и заточена на все 100% под российский бизнес, без коннекторов (но кое-что и с доработками, думаю я до этого ещё не доходил). А вот чего мне не хватило (раз мы гребём в русле универсальности), так это управления персоналом вроде есть KPI, планирование и карточка сотрудника, но вот этого всего типа учёта кадров нет.Кстати, это ко всем претензия.

Наверное, сюда же отнесу и FreshOffice он тоже явно эволюционирует в сторону универсальности, хотя несколько беднее функционально.

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

Скорее, корпоративный портал с функциями CRM

Bitrix24 очень сложная история в мире CRM, настоящий фантом и оборотень. Если про остальные системы я могу сказать, что это CRM с надстройками или супер CRM, то про Битрикс24 я скорее скажу, что это корпоративный портал с модулем CRM и элементами социальной сети. Чувствуете разницу? В остальных нужно работать, в Битриксе сидеть и контролировать совершенно все стороны работы. С одной стороны, универсальность здесь на уровне, с другой стороны все эти инструменты корпоративного портала отвлекают от работы и до CRM дело может не дойти.

Кстати, у меня для вас печалька: бесплатный Битрикс24 очень обрезанная штука, из которой компания вырастает уже на этапе теста системы. А если серьёзно, действительно, если вам нужен Битрикс24, который не просто что-то там хранит, а работает так, как он задуман, то нужен тариф Команда, а то и Компания. Ну это если вы вдруг задумывались, что на нуле можно далеко уехать.

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

Скорее, CRM?

А как же остальные? Остальные тоже были. В эту группу я выделю amoCRM, CRM Простой Бизнес, Клиентская база. Это CRM-системы для продаж, причём amoCRM строго блюдёт концепцию системы для работы с клиентами, а вот остальные две уже находятся в пути к универсальности решения и к уровню ERP: Простой бизнес чуть выше эволюционировал, КБ ещё в начале. К слову, amoCRM за деньги можно проапгрейдить с помощью аддонов, плагинов и интеграций, но мне такие навороты кажутся дорогими и сложноватыми я как сисадмин морально не готов отвечать за такой зоопарк, оплаты по нему и т.д.

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

Конечно, я не считаю себя самым умным, поэтому посмотрел чужие списки, отзывы, рейтинги. Правда, создалось впечатление, что 90% из них фуфло, потому что на первых местах не Microsoft, не amo, не bitrix24, а какие-то CRM, которые даже рекламой мне за 5 месяцев не подкинулись. Я их посмотрел, даже пару раз прошёл через презентации Ну это серьёзно? На кого они рассчитывают эти прокачанные и проплаченные рейтинги? Ну да ладно, своим умом нужно думать.

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

Подробнее..

Категории: It-инфраструктура , Управление проектами , Crm-системы , Erp-системы , Crm , Терминология it , Erp , Crm или erp , Я выбираю crm

Из песочницы Управление разработкой и производством в Asana

30.08.2020 18:21:45 |

Автор: admin

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

Что в этом такого?

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

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

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

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

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

Немного о знакомстве с Asana

На поиск удобного софта для проектного управления я потратил 10 лет. Trello, Jira, Планфикс, Мегаплан, Битрикс24 и десятки других таск-трекеров не прошли тест на прочность. Потом я нашел Asana. И все сложилось.

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

Мы фанаты Asana, даже прошли сертификацию, чтобы иметь возможность внедрять ее клиентам.

Коротко опишу процесс от продажи до реализации проекта

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

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

Благодаря связке amoCRM + Asana, при передаче сделки из отдела продаж в производство и обратно, работа нигде не прерывается. Голубым цветом обозначена зона ответственности отдела продаж, оранжевым отдела производства, розовым отдела разработки.

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

Итак, когда руководитель принял проект в производство, менеджер по продажам в 1 клик переходит в Asana (скриншот). Из amoCRM проект автоматически создаётся в Asana.

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

Менеджер может запустить в задаче любой из предложенных автоматических бизнес-процессов:

Найти/Создать проект Клиента + Прикрепить туда задачу
Заполнить задачу информацией по сделке
Создать сделку из текущей задачи

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

Эта доска помогает принимать новые проекты в работу. Но контролировать на ней актуальные статусы и наличие проектов в зоне риска неудобно.

Как мы группируем задачи и проекты клиентов

Из общей доски всех проектов менеджер добавляет проект еще на 3 доски:

персональная доска клиента;
портфель активных клиентов;
портфель менеджера.

Разберемся, для чего нам каждая из сущностей.

На скриншоте вы видите персональную доску клиента.

Зачем эта доска?

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

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

Что есть на этой доске?

Наша Asana связана с несколькими сервисами:

CRM-система (для взаимодействия с отделом продаж),
TimeDoctor (для учета времени),
ERP-система (для агрегации всех данных в едином интерфейсе).

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

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

Что дает использование доски?

В итоге в ERP-системе мы видим Отчет по проектам. Статус сделки, участники проекта, бюджет на проект, количество отработанных часов и сроки.

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

Портфели Asana

Эта функциональность реализована в Asana уже давно. Но мы не сразу ее оценили. Сперва мы просто собрали в портфели все проекты наших менеджеров. Оказалось, что за время работы в компании Денис Киселев поработал с 61 клиентом.

Знать это прикольно, но недостаточно, чтобы оправдывать потраченное на сбор время. И мы забили на портфели. Все поменялось, когда мы приравняли проект в Asana к одной сделке в CRM-системе.

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

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

Портфель проектного отдела

На скриншоте вы видите отсортированные по сотрудникам проекты.

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

Руководитель быстро может оценить:

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

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

Портфель сотрудника

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

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

Решение багов и кастомная разработка

Отдельная команда отвечает у нас за разработку. К ней в рамках бизнес-процесса поступают задачи двух типов:

баг,
новая разработка.

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

Процесс разработки, в целом, выглядит так.

Задачи падают на доску разработки в Asana. Вот она.

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

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

После оценки руководитель перемещает задачу в спринт, соответствующий месяцу планируемого завершения. Задачи всегда находятся на нескольких досках одновременно:

на личной доске проектного менеджера,
на доске техподдержки,
на доске разработки.

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

Что получилось, когда мы вернули отделы разработки и производства в единую среду с командой?

Во-первых, клиентские проекты стали более долгосрочными. За счет постоянно пополняемого бэклога вырос средний чек.

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

В-третьих, и сотрудники, и руководители, и клиенты получили полную прозрачность в запланированных и выполненных задачах. Мы научились УПРАВЛЯТЬ проектами, осознали, что это абсолютно технический процесс, из которого можно почти полностью исключить человеческий фактор.

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

Сейчас, видя процесс разработки и технической настройки систем:

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

Получилась win-win-win трансформация, в которой выиграли и мы, и клиенты, и наши партнеры. Буду рад, если вы поделитесь мнением в комментариях: было ли что-то полезное в моей статье и какие методы управления проектами вы используете в разработке!

Подробнее..

Категории: It-инфраструктура , Управление проектами , Разработка , It-компании , Управление разработкой , Crm , Бизнес-модели , Erp , Asana

CRM-системы существуют доказываем

01.09.2020 16:17:46 |

Автор: admin

Читали статью Ивана CRM-системы не существуют?, плакали всем офисом: где-то от смеха, но больше от отчаяния и невероятной тоски. То есть ты вот так 19 лет в автоматизации, 14 лет пилишь и внедряешь свою CRM, пишешь почти полторы сотни статей на Хабр, а тебе заявляют, что CRM не существует. Безобразие! На этот вполне справедливый и аргументированный выпад грамотного и въедливого айтишника нельзя не ответить а раз уж мы на Хабре лидеры хаба CRM, нам и отвечать. Выходные не отдыхали, составляли ответ так что, если что местами не так, просим извинить эмоции и наше профессиональное возмущение.

Итак, заявляем со всей ответственностью: CRM существуют.

Ваша карта бита

Определение CRM-системы

Определение CRM из Википедии соответствует классическому пониманию CRM-системы. Именно таким этот тип программного обеспечения когда-то задумывал Томас Зибель. CRM-системы фактически выросли из категории SFA (Sales Force Automation) систем автоматизации разгона продаж. Изначально CRM-системы были заточены исключительно под продажи, затем довольно быстро к ним присоединились маркетинг и поддержка, поскольку это всё часть концепции CRM (не как системы, а как подхода) управления взаимоотношениями с клиентами. То есть, если коротко, CRM-система это программа для управления взаимоотношениями с клиентами, включая продажи, маркетинг и поддержку. Поставим пока здесь breakpoint

и пойдём дальше.

Теперь давайте разберём несколько вопросов. Они нам пригодятся.

Как в CRM появляются новые функции и возможности?

Есть два пути попадания той или иной возможности в CRM-систему как программу:

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

Соответственно, часто встречающиеся требования клиентов уже значительно расширяют функциональность CRM-системы: так у нас в RegionSoft CRM появился механизм конструктора-калькулятора, редактор бизнес-процессов, сложный и многофакторный механизм расчёта KPI и т.д. И точно так же в новом релизе будут самые востребованные штуки на день релиза (а невостребованные будут выпилены, потому что не тащить за собой легаси-код и легаси-функции ещё один признак хорошего современного программного обеспечения). Итак, клиент формирует CRM.

Почему наряду с прекрасным опенсорсом существует, процветает и побеждает проприетарное ПО в мире CRM?

В мире много опенсорсных CRM некоторые из них достойные, функциональные решения, которые при прямых руках и толковых мозгах вашего программиста или внедренца могут выглядеть очень неплохо. Спрашивается, зачем мы и ещё куча компаний развиваем платные проприетарные решения? Всё просто: во-первых, open source сложен в разворачивании, во-вторых, внедрение такой системы обходится едва ли дешевле, чем покупка или аренда лицензий, поскольку поддержка, работа программиста, обучение, доработки это всё делается за деньги. Увы, в мире корпоративного программного обеспечения опенсорсные решения это скорее маркетинг, чем та самая философия свободного ПО.

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

Почему некоторые компании уходят от CRM в названии?

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

А теперь вернёмся к нашему breakpoint

. Итак, мы остановились на том, что CRM-система это программа для управления взаимоотношениями с клиентами, включая продажи, маркетинг и поддержку. Так было. Сейчас клиент стоит в центре интересов каждой коммерческой компании, потому что а) клиент это деньги; б) информированность клиента максимальная, а сама информация крайне доступная (смотрите, тот же автор поста Иван тестирует нашу RegionSoft CRM наряду минимум с пятью системами и каждый вендор передал ему кучу информации, а ещё есть Хабр, Facebook и масса других сервисов); в) почти не осталось низкоконкурентных отраслей; г) г оно и есть г в условиях российской экономики компании готовы бороться за каждого клиента, потому что то кризис, то ковид, то ещё что-то болит, а кушать хочется всегда. Такая борьба за клиента вынесла его за пределы просто продаж, просто маркетинга, просто поддержки: компании используют всё, от блогов и социальных медиа до бигдаты и машинного обучения, лишь бы отгрузить ООО Ромашка бетонные блоки, кирпич, стекло или бытовую химию. Потому что это деньги.

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

Соответственно, раз изменилась сама стратегия CRM, то и её автоматизация (CRM-системы) должна меняться с тем же вектором. Если у какого-то разработчика CRM это не происходит, он отстаёт от рынка и исчезает с него даже в том случае, если его разработка выстроена лучше, код чище, Agile самый аджайлистый в мире, а сайт новый и красивый. Нет. Работает только соответствие ожиданию клиентов и желательно максимально из коробки.

Универсальные CRM настоящий бизнес-комбайн

Универсальные, функциональные CRM-системы очень круто. Это я вам не как разработчик, а как пользователь говорю. И существование таких систем не просто отходит от концепции CRM, а напротив соответствует самым передовым её пунктам развития. Давайте разберём принципы концепции CRM и софта CRM на примере RegionSoft CRM Professional Plus (это, как модно говорить, cutting edge среди линейки CRM-продуктов, дальше уже ERP).

Потребность клиента, часть CRM-стратегии	Что должны делать сотрудники	Как это реализовано в CRM-системе
Знакомство, поддержание контакта	Знать ФИО клиента, его точные контакты (несколько), особенности компании, профиль деятельности	Карточка клиента, расширенная карточка с самой полной информацией по клиенту
События точно в срок: КП, документы, звонки, встречи	Быть пунктуальным, точным, ценить время клиента	Управление заказами, напоминания, планировщики, бизнес-процессы; встроенная телефония и почтовый клиент, по требованию мессенджеры
Точная информация о продуктах и услугах, включая наличие Оперативная поставка товаров и услуг	Оценивать остатки на складах, работать с прайсами, готовить комм. предложения	Механизм формирования КП, встроенный калькулятор с параметрами, прайсы, учёт скидок и индивидуальных спец.предложений, уровни цен для разных категорий клиентов, модуль управления складом
Точная и полная документация	Оформлять документы в соответствии с нормативными документами, быстро и грамотно	Возможность создания шаблонов документов, красивые индивидуальные печатные формы, иные возможности оформления (добавление фирменной шапки, факсимиле и оттиска печати)
Корректная работа с профессионалами	Быть мотивированным и включённым в работу	Системы оценки персонала: план-фактный анализ, KPI, управление задачами
Гарантированные скидки	Помнить о скидках и программах лояльности, выделять группы no sale	Прайс-листы, учёт скидок, учёт карт лояльности
Исключительный сервис	Реагировать на жалобы, быстро отрабатывать негатив, знать профиль клиента на отлично	Модуль саппорта, логирование информации о клиенте, отчёты по клиенту и т.д.

И это только небольшая, базовая часть того, что сегодня компания делает с клиентом. Что из перечисленного можно выкинуть из системы управления взаимоотношениями с клиентами? Ничего. А значит, всё, что автоматизирует эти запросы, должно быть в CRM-системе, как в системе автоматизации всех отношений с клиентом, а не только продаж как абстрактного понятия.

В чём логическая подмена изначального поста, которому мы оппонируем? В том, что у Ивана компания одного типа (мы знаем какого, но он расскажет сам, мы надеемся), а у Сергея другого, у Ильи третьего, а у Ирины вообще B2C салон красоты. И у каждого из них своя стратегия управления взаимоотношениями с клиентами с разным набором требований, а значит, и CRM своя. Именно поэтому у серьёзных вендоров есть несколько тарифов с разным набором функциональных возможностей, чтобы Ирина с салоном не переплачивала за ненужный ей модуль ТКП и склада, а Илья или Иван не топтались бы на месте без склада, KPI и бизнес-процессов ведь для них это ключевые требования.

Такое разделение есть и у нас вы можете посмотреть его в таблице. Соответственно, RegionSoft CRM Standard базовая CRM для продаж и оперативной работы, а вот RegionSoft CRM Enterprise Plus это фактически RegionSoft ERP.

Бизнес-процессы: до точек над i далеко

Бизнес-процессы, пожалуй, самая недооценённая функциональность в современных CRM-системах. И с ними всё очень непросто:

в любой компании есть бизнес-процессы, но нередко они не оформлены и не отрефакторены;
малый и средний бизнес при выборе CRM-системы редко отдаёт бизнес-процессам приоритет;
в IT-среде бизнес-процессы это первое, о чём говорят при выборе CRM;
компании опасаются подходить к бизнес-процессам в ходе внедрения.

На данный момент бизнес-процессы лежат в основе хорошей CRM-системы, поэтому поднятая Иваном проблема бизнес-процессов в CRM не случайна. Однако наличие механизма бизнес-процессов в CRM не превращает её в BPM-систему, оно даёт эффективный инструмент для управления клиентами и сотрудниками, всей оперативной работой в целом. И, как абсолютно правильно заметили в комментариях к исходной статье, бизнес-процессы можно автоматизировать только в том случае, если они приведены в порядок, системны и имеют такие параметры как этапы, сроки, ответственных и триггеры (набор автоматических действий, которые порождаются при достижении определённых целей). К слову, описать и привести процессы в порядок не так сложно: стоит потрудиться, чтобы CRM-система была внедрена не просто как инструмент записи информации о клиентах, а как супермашина эффективного оперативного управления. Хотя, думается, что одной-двумя статьями для осознания идеи автоматизации бизнес-процессов не обойтись, поэтому

раз пошла такая пьянка, режь последний огурец

А раз на Хабре столько интереса к бизнес-процессам, мы приняли решение: для всех, кто пришёл с Хабра и оставил заявку в форме, бесплатный анализ бизнес-процессов компании будет доступен всегда. Это аналитическая работа наших экспертов, связанная с анализом вашего бизнеса с последующей выработкой рекомендаций и обычно она стоит от 15 000 рублей, но нам для науки хвоста не жалко Хабра ничего не жалко. Записывайтесь, мы с вами свяжемся, назначим время (это займёт далеко не 15 минут) и обсудим бизнес-процессы вашей компании или проблемы с бизнес-процессами. Общение с экспертом не накладывает на вас никаких обязательств.

Мне для науки хвоста не жалко!

Джентльменский набор функций CRM: он есть?

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

Опять же, уровень функциональности может зависеть от редакции или тарифа (у кого как называется). Рассмотрим опять-таки на примере нашей RegionSoft CRM (не потому что реклама, а потому что свой софт мы знаем очень хорошо и готовы отвечать за каждое слово однако у известных CRM на рынке тоже есть разные уровни возможностей за разные деньги). Базовая CRM-система это учёт и управление клиентами, регистрация событий, планировщик задач и воронка продаж. А продвинутая CRM-система, которая приближается к ERP или по факту ей является, даёт дополнительные сложные инструменты, такие как управление складом, учёт проектов, бизнес-процессов, механизмы обработки запросов и обращений клиентов, обработку заказов, работу с поставщиками, прайс-листами, автоматизацией производства, схемы мотивации на основе KPI и многое другое. Т.е. CRM, как продуктовая линейка, базируется на наличии продвинутых и порой очень сложных механизмов именно оперативного учёта, а в ERP, помимо наличия полного объёма возможностей CRM, также добавляются механизмы управления ресурсами.

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

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

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

Если быть очень педантичным и занудным, то называть компьютерную программу CRM вообще категорически неправильно, правильно CRM-система, но это уже какой-то дикий снобизм.

Меняются подходы к клиентам, меняется софт. Вчера было круто, если менеджер брал трубку и здоровался с клиентом по имени (это был WOW-эффект), а сегодня бизнес-процессы, сложные воронки и сплошная персонификация уже обычное дело. И программное обеспечение, которое автоматизирует работу с клиентами на 360 градусов, всегда будет иметь право называться CRM-системой.

Подробнее..

Категории: It-инфраструктура , Софт , Блог компании regionsoft developer studio , Crm-системы , Erp-системы , Crm , Erp , Crm для малого и среднего бизнеса

Как попадает товар в магазины Леруа Мерлен с точки зрения математики заказа

15.12.2020 16:09:41 |

Автор: admin

Ячейка пикинга на первом этаже стеллажа

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

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

Большая часть товаров едет в магазины либо по потоку кросс-докинга (склад перебрасывает паллеты, не открывая и не сохраняя их у себя на стоке), либо напрямую от местных поставщиков. Частично мы эти процессы уже разбирали в прошлом посте. Рассмотрим сложный случай, когда магазину смесители нужны из паллеты, которая лежит на складе в Москве.

Сложность в том, что паллета это довольно много смесителей. А в магазин нужно привезти 50 штук, скажем. Не везти же её целиком? И вот появляется процесс пикинга, когда паллета снимается с ячейки, кладётся вниз, а потом из неё достаётся вложенная тара. Это может быть транспортный короб, иннер и штука. Штуками распределительный центр почти никогда не оперирует, за исключением редкого и дорогого оборудования. Для единиц нужны фулфилмент-центры, но это уже немного другая часть логистики, и в этом посте про них не будет.

В конечном итоге, когда магазину нужен товар, потребность считается в системе прогнозирования GOLD GWR, а в ERP (Oracle RMS) появляется итоговый документ с тем, сколько чего нужно привезти и куда. Он попадает в систему управления складом (WMS) в виде задания Отгрузить туда-то и в систему управления транспортом (TMS) в виде директивы Забрать это на складе таком-то и отвезти в магазин такой-то. Дальше задача TMS обеспечить транспорт (для этого отправляется заявка логистам), а задача WMS обеспечить начало загрузки в момент открытия дока под приехавший грузовик.

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

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

Задача склада всегда уменьшить сток и увеличить его оборачиваемость (т. е. уменьшать срок его хранения). Чем меньше товара лежит без дела, тем выгоднее для компании. Но при этом, когда нужный товар кто-то запросил, а склад его дать не может, это тоже провал. Между двумя этими крайностями и работает вся математика.

Так что с моим смесителем?

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

В конечном итоге компромисс для смесителей выглядит так: выделяется математический оптимум того, как их везти. Иногда бывает выгодно вообще не закупать конкретно эту модель (потому что есть прямой аналог), иногда действительно выгодно закупить и привезти целую паллету и медленно её распродавать со склада магазина. Но чаще всего бывает выгодно везти транспортный короб. Если в коробе 52 единицы, а система магазина подсчитала, что нужно 50, то решение очевидно: будет заказано чуть больше 52. А вот если магазину нужно три единицы, а короб 100 единиц, то уже встаёт вопрос о целесообразности минимума.

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

Формирование потребности у нас работает по принципу покрытия заказа и каждый заказ покрывает товарным запасом до даты доставки следующего заказа.

Например, делаем заказ сегодня, 01.01.2021 года, и у нас на остатке 18 штук. Дата доставки такого заказа будет 07.01.2021 (поставщик возит за одну неделю). Дата следующего заказа 14.01.2021, доставки 21.01.2021.

Представим, что мы продаём по две штуки в день всегда.

Значит, мы должны заказом 01.01.2021 покрыть запасом аж до 21.01.2021, иначе нам нечего будет продавать.

Поэтому до 21.01.2021 нам потребуется 21 * 2 = 42 штуки.

18 штук у нас на остатках есть, поэтому заказываем 24 штуки 01.01.2021.

Конечно же, в каждом заказе есть ещё и доля страхового запаса.

Дальше данные заказа вписываются в тарность. То есть если нужно 45, 48 или 49 штук заказывается минимальный короб в 50. Если нужно 55 штук нужно заказать два короба или оптимизировать модель. Как видите, чем меньше квантование (чем чаще поставки и чем больше управляемых единиц вложенности в таре), тем точнее оптимизация. Поэтому поставки в магазины делаются как можно чаще, и поэтому появляются подкороба в коробах.

Как короб попадает в грузовик?

Итак, из магазина задание поступает в ERP, а оттуда на склад. Склад должен обеспечить упакованный товар в доке, когда туда подъедет машина, заказанная TMS-системой, и заберёт его в магазин.

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

Дальше люди получают конкретные координаты целей (паллет в ячейках) и действия с ними в виде алгоритма. И выполняют их. Разбивается это на шаги в духе: Езжай в ячейку такую-то, возьми паллету. Человек едет, сканирует там её штрихкод, система проверяет, что всё правильно, и даёт следующее действие: Вези туда-то. И так всё время. Мы управляем мобильными терминалами, а грузчики их слушаются. Так мы имеем своего рода API к людям на складе. Следующий шаг, конечно, убрать людей, но про это в другой раз.

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

Когда она готова, на неё печатается отдельная этикетка на терминале, и она теперь учитывается в системе как отдельное место. Можно класть в буфер отгрузки или прямо на док.

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

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

Откуда взялся грузовик?

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

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

Как принимается решение, что товар нужно пополнить на такое-то количество?

Сначала мы смотрим, будет ли ещё закупаться этот товар. Для каждого магазина есть матрицы того, что в нём продаётся, а что нет. Это региональные особенности из-за местных поставщиков, регионального спроса (очень дорогая профессиональная техника для ремонта чаще всего нужна только в Москве), культурных особенностей (в Казахстане огромная зона ковров для декора) и так далее.

Товар может перестать закупаться в магазин из-за окончания сезона: мало кому нужны газонокосилки зимой и ёлочные игрушки летом.

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

Когда товар новый, истории нет. Её нужно либо откуда-то взять, либо управлять товаром вручную. В случае когда это прямой аналог чего-то известного, можно просто указать ему товар-пару в карточке. Были перчатки рабочие одного производителя, пришли другого (или просто артикул либо модель поменялись) указываем пару прошлую, и модель опирается на историю другого товара. Через шесть недель (это магическая константа) товар автоматически отвязывается и у него начинает считаться только собственная история.

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

Поскольку мы пока умеем правильно считать далеко не всё и система может ошибаться, итоговый документ отправляется на утверждение администратору магазина (или человеку, который отвечает за поставки товара). Точнее, обычно это делают менеджеры отделов (в магазине 15 отделов: инструменты, скобянка, сантехника и т. п.). Им выводятся все позиции без исключения, которые могут быть поставлены в рамках отдела, и их количество. То есть если в заказе 0, то там есть позиция и стоит ноль.

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

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

В 99,9 % случаев всё решается на месте в магазине, и администраторы только увеличивают количество того товара, который, по их мнению, продаётся больше и быстрее, чем система может предсказать. Всё же 5060 тысяч SKU очень сложно обрабатывать только вручную. В итоге они вносят минимальные изменения, которые помогают увеличению продаж, чувствуют контроль, но не вносят человеческие ошибки. Всё делается децентрализованно, то есть каждый магазин управляет своим заказом сам за исключением редких случаев.

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

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

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

Откуда склад знает, сколько товара взять и откуда? Теперь вы знаете, как магазин определяет свои потребности. Вы знаете, как это консолидируется и отправляется на склад, а склад должен достать транспорт и отгрузить всё это. Но есть ещё слой: складу нужно всё это обработать.

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

Дальше ещё слой оптимизации: где его выгоднее достать к этому времени? Какой партией? Некоторые поставщики ставят минимальный объём отгрузки (килограмм гвоздей заказать не выйдет), некоторые дают объёмные скидки, ретробонусы и прочие спецусловия. Надо считать, как везти товар и откуда. Эту тему мы только начали прорабатывать, пока она в довольно простом виде. Думаю, через год будет что рассказать.

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

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

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

Подробнее..

3 стратегии сегментации для граничных вычислений

01.04.2021 18:23:17 |

Автор: admin

По прогнозам IDC, в 2024 году размер мирового рынка граничных вычислений (edge computing) достигнет $250,6 млрд, так что эта технология определенно заслуживает пристального внимания. И сегодня мы поговорим о таком ее важном аспекте, как сегментация: что это, зачем она нужна, и как реализуется.

Суть концепции edge computing физически перенести вычисления как можно ближе к конечному потребителю, чтобы предоставлять их максимально быстро и эффективно. Однако в отличие от распределенной архитектуры ЦОД, где информационный обмен между сервисами сводится к взаимодействию кластеров машин, сконцентрированных в одной локации, граничные вычисления подразумевают использование физических устройств, которые рассредоточены на обширной территории (например, банкоматы) и даже могут активно перемещаться в пространстве (складские погрузчики или беспилотные автомобили). Такое резкое увеличение парка и разнообразия устройств, образующих цифровой домен, принципиально меняет архитектурные подходы к распределенным вычислениям, см. Рис. 1.

Рис. 1: Граничные вычисления повышают уровень сегментации распределенных вычислений.

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

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

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

Проблемы на пороге

Вместе с граничными вычислениями в распределенных системах появляется ряд факторов, которые усложняют архитектурное проектирование сегментации. Если классическая среда облачных вычислений относительно однородна и состоит из дата-центров, заполненных стойками серверов x86 или мейнфреймов, которые связаны оптоволоконным Ethernet-ом и общаются по TCP/IP, то граничные вычисления выводят на арену широкий спектр устройств и коммуникационных протоколов на базе различных аппаратных архитектур и чипсетов. Одни из этих устройств, такие как банкоматы, используют стандартные процессоры x86. Другие, например, различные системы на базе микрокомпьютеров Raspberry PI, построены на архитектуре ARM. И наконец, третьи, вроде роботизированных систем или автомобилей, используют узко специализированные чипсеты.

Помимо железа взрыв разнообразия происходит и на уровне коммуникационных протоколов. Одни устройства могут напрямую подключаться Ethernet-кабелем, другие по беспроводному 802.11x, третьи через Bluetooth. И все эти устройства требуется поддерживать.

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

Физическая сегментация

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

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

Одна из таких моделей разбиения получила название туманных вычислений (fog computing) и подразумевает наличие промежуточных дата-центров и точек сбора данных, расположенных между устройствами IoT и главным центром обработки данных, см. Рис. 2.

Рис. 2: Туманные вычисления (fog computing) это способ сегментации физических вычислительных ресурсов между устройствами IoT и главным дата-центром.

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

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

Сегментирование логики

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

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

Эмпирическое правило гласит, что на каждом физическом уровне должно присутствовать столько логики, сколько требуется для выполнения работы на этом участке. Допустим, IoT-устройство это умный складской погрузчик с геолокацией в реальном времени, который может сам находить нужный отсек на складе и забирать оттуда паллету с запрошенным товаром. В этом случае логика безопасного передвижения по складу должна быть реализована на самом погрузчике. Погрузчик не должен постоянно спрашивать сервер, как ему двигаться по складу. Кроме того, непосредственно на погрузчике должна иметься и логика его обновления. Это может быть SSH-сервер, чтобы оператор или bash-скрипт могли делать обновление. Либо это может быть подписчик системы обмена сообщениями, привязанный к расположенному в fog-облаке брокеру и получающий от него сигнал о необходимости обновить свой код и затем связывающийся с fog-сервером с помощью клиента HTTP.

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

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

Рис. 3: В архитектуре граничных вычислений логика должна разделяться согласно ключевым функциям уровня сегментации.

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

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

Сегментирование на уровне данных

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

Впрочем, всегда полезно помнить, что маленькие пакеты проще передаются по сети и быстрее обрабатываются, чем большие. Преобразование данных в двоичный формат, такой как Protocol Buffers, и потоковая передача данных, такая как gRPC, обеспечивают очень быстрый обмен данными. Обратная сторона перехода на двоичные структуры данных и потоковую передачу усложнение архитектуры за счет упаковки и обработки данных. Как бы то ни было, основное правило здесь следующее: маленькие пакеты это хорошо, а потоковые данные еще лучше! Запомним это правило и вернемся к сценарию со складом и умным погрузчиком.

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

Задача погрузчика забрать паллету с нужным товаром из складского отсека. Для этого локальное fog-облако склада отправляет погрузчику соответствующую информацию о заказе.

Причем, fog-облако отслеживает передвижения погрузчика, а также отправляет в ERP-систему данные по выполнению заказа после того, как погрузчик заберет на складе паллету с товаром и загрузит ее в грузовик для доставки клиенту.

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

Теперь займемся сегментацией данных с учетом конечных точек.

Как происходит обмен данными в средах IoT

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

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

Что касается клиентского заказа, то погрузчику достаточно знать лишь ID заказа, идентификатор товара (SKU) и складской отсек, где хранится паллета с этим товаром. Эти три значения можно упаковать в очень маленькое сообщение, которое погрузчик будет получать от fog-облака. Доставку таких сообщений легко организовать с помощью типового запроса-ответа HTTP на RESTful API, а чтобы ускорить передачу информации о заказе, погрузчик и fog-облако могут общаться через двусторонний поток gRPC.

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

Сегментирование данных при обмене между fog-облаком и корпоративным облаком

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

Обмен данными между устройством IoT и fog-облаком должен быть практически мгновенным, то есть измеряться миллисекундами. Обмен данными между fog-облаком и глобальной системой ERP вполне переживет задержку в секунду-две. Кроме того, системе ERP и складскому fog-облаку нужна только информация о выполнении заказа. Иначе говоря, здесь вполне возможен пакетный обмен, когда одно сообщение содержит данные сразу по нескольким заказам. В результате сообщения становятся больше, но это не страшно, поскольку на обмен информацией есть гораздо больше времени, см. рис. 4.

Рис. 4: Сегментация данных это важный аспект корпоративной архитектуры в средах edge computing.

Обмен данными можно упростить за счет использования стандартного HTTP через RESTful API или же передавать их потоковым методом, тут уже дело личных предпочтений. Кому-то работать через REST на уровне ERP покажется намного проще, чем создавать и поддерживать механизмы кодирования-декодирования двоичных потоков данных по открытому и постоянному сетевому соединению. Интересно отметить, что наряду с сегментацией данных с учетом специфики физической среды и решаемых задач, для успешной работы организации требуется и сегментация ИТ-специалистов по профессиональным навыкам, чтобы нужные люди были на нужных местах.

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

Подводим итоги

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

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

Подробнее..

Категории: It-инфраструктура , Интернет вещей , Open source , Iot , Облачные вычисления , Edge computing , Fog computing , Блог компании red hat , Red hat , Erp , Cloud computing , Grpc , Buffers

От забоя до перегрузочного пункта. Пример интеграции GEOVIA Surpac и автоматизированной системы диспетчеризации ГТК

29.06.2020 12:20:00 |

Автор: admin

Что добывают предприятия? Золото, железную руду, уголь, алмазы? Нет!
Каждое предприятие добывает деньги. Это и есть цель каждого предприятия. Если добытая тонна золота или железной руды не принесет вам доход или, хуже того, ваши затраты будут выше, чем прибыль от реализации продукции, какая ценность этой руды для предприятия?
Каждая тонна руды должна приносить максимальный доход или нести минимальные издержки в условиях безопасного производства и соблюдении технологии добычи. Т.е. распределение движения горной массы во времени должно приводить предприятие к цели. Для того чтобы достичь цели, необходимо создать хороший план, который будет моделировать производственный процесс с максимальным достижением объемно-качественных показателей. Каждый план необходимо обеспечивать верными, точными и актуальными данными. Особенно, если речь идет о краткосрочном или оперативном планировании.

Какие данные обеспечивают планирование горных работ? Это маркшейдерская и геологическая информация, данные проектирования и производственно-техническая информация (например, из ERP систем).

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

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

Если говорить о краткосрочном планировании, то важно, чтобы эти данные были не только точными, но еще и актуальными. Необходимо иметь возможность получать информацию в любой момент времени, чтобы реагировать на изменения и оперативно редактировать сценарий производства. Соответственно, нужны такие системы и оборудование, которые позволят повысить эффективность процессов по получению и обработке информации. Лидарные сканеры позволяют оперативно получать данные с высокой точностью, технологии опробования горной массы дают картину положения рудного тела в массиве, системы позиционирования отслеживают положение и состояние оборудования в реальном времени, а системы проектирования и планирования GEOVIA Surpac и GEOVIA MineSched являются инструментами для создания проектов и сценариев развития горных работ. Для максимально быстрого достижения цели системы должны быть связаны в единую продуктивную цепочку. Представьте: вы получаете данные из разных систем и источников, но они доступны вам только по запросу, к тому же эти данные передает вам специалист, который в любой момент может изменить содержимое. Это ведет не только к снижению скорости получения данных, но и к потере точности или достоверности на одном из этапов передачи данных. Поэтому данные должны быть централизованными, храниться на одной платформе, в одной цифровой экосистеме и быть доступными в любой момент времени. Кроме того, важно обеспечить совместную работу всех подразделений, версионность, целостность и безопасность данных. С этой задачей справляется платформа 3DEXPEREINCE.

Информация, полученная из различных источников электронных систем, систем ГГИС (GEOVIA Surpac), ERP-систем, систем автоматизированного планирования горных работ (GEOVIA MineSched), систем управления горными работами (например, ВИСТ Групп) имеет разный формат данных.
Здесь встает вопрос об интеграции систем. Зачастую все решения в цепочке горного планирования и проектирования могут быть в большей или меньшей степени интегрированы между собой.
Но интенсивность потока данных, количество их типов, и изменчивость таковы, что человек не способен в относительно быстрое время произвести конвертацию из одной системы в другую. Будь то геолог или инженер по планированию, специалист должен тратить время не на импорт и экспорт файлов из одной системы в другую, он должен создавать ценность и двигать предприятие к цели. Поэтому процесс интеграции важно автоматизировать, настроить таким образом, чтобы количество манипуляций по обработке данных сводилось к минимуму.

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

Автоматизированный процесс обработки и интеграции данных при маркшейдерском и геологическом обеспечении горных работ с использованием GEOVIA Surpac выглядит следующим образом. Съемка готова, маркшейдер подключает прибор к ПК, открывает GEOVIA Surpac, запускает функцию импорта и обработки данных съемки, выбирает из списка, что необходимо получить в результате.
Система формирует графические и табличные данные, обновляет на сетевом ресурсе рабочий файл и сохраняет предыдущую версию файла. Геолог запускает функции обновления блочной модели по актуальным маркшейдерским данным и/или данным систем диспетчеризации.
Все данные подгружаются с сетевого ресурса/платформы, макрокоманда конвертирует и импортирует необходимые данные, геологу необходимо только выбрать соответствующие настройки. После проверки при помощи соответствующих функций результат сохраняется и экспортируется в другие системы.

Такой процесс реализован в маркшейдерской и геологической службах на Качканарском ГОКе компании ЕВРАЗ.

ЕВРАЗ КГОК входит в пятерку крупнейших в России горнорудных предприятий. Комбинат расположен в 140 км от ЕВРАЗ НТМК, в Свердловской области. ЕВРАЗ КГОК разрабатывает Гусевогорское месторождение титаномагнетитовых железных руд, содержащих примеси ванадия. Содержание ванадия позволяет выплавлять высокопрочные легированные сорта стали. Производственная мощность комбината составляет порядка 55 млн тонн железной руды в год. Основным потребителем продукции ЕВРАЗ КГОКа является ЕВРАЗ НТМК.

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

В 2018 году на ЕВРАЗ КГОКе добыто более 58,5 млн тонн руды, произведено 3,5 млн тонн агломерата, 6,5 млн тонн окатышей, около 2,5 млн тонн щебня.

Добыча руды производится в четырех карьерах: Главном, Западном, Северном, а также карьере Южная залежь. С нижних горизонтов руда доставляется БелАЗами, на дробильную фабрику горная масса перевозится железнодорожным транспортом. В карьерах используются мощные 130-тонные самосвалы, современные локомотивы НП-1, экскаваторы с объемом ковша 12 кубических метров.

Среднее содержание железа в руде составляет 15,6 %, содержание ванадия 0, 13 %.

Технология добычи железной руды на ЕВРАЗ КГОКе следующая: бурение взрывание экскавация транспортировка к месту переработки и вскрыши в отвалы. (Источник )

В 2019 году на Качканарском ГОКе была внедрена автоматизированная система диспетчеризации ВИСТ Групп. Внедрение данного решения позволило увеличить производственный контроль работы горнотранспортного оборудования, движения руды от забоев до перегрузочных пунктов, а также оперативно получать данные по объемно-качественным показателям в забоях и на перегрузочных пунктах. Была произведена двусторонняя интеграция систем АСД ВИСТ и GEOVIA Surpac, что позволило использовать получаемые данные (положение оборудования, степень отработки забоя, баланс горной массы на перегрузочных пунктов, распределение качества на перегрузочных пунктах и т.п.) для оперативного планирования и проектирования горных работ, а также контролировать производственный процесс на уровне линейного руководителя и машиниста экскаватора.

Благодаря разработкам ведущего геолога С.М. Некрасова и главного маркшейдера А.В. Безденежных, специалистами маркшейдерского и геологического отделов с использованием инструментов GEOVA Surpac было автоматизировано большинство процессов по обработке данных маркшейдерской съемки, проектирования, создания печатной документации, создания геологических блочных моделей, обновления геологической и маркшейдерской информации на сетевом ресурсе. Теперь специалистам не нужно выполнять повторяющиеся процессы ежедневно, будь то выгрузка/загрузка съемки с прибора/на прибор, поиск нужных данных для повседневной работы в огромном множестве папок. Макрокоманды GEOVIA Surpac делают это за них. Важно отметить, что эти данные доступны для всех причастных специалистов разных отделов. Например, чтобы открыть последнюю съемку карьера, обновленную блочную модель, блок БВР, коммуникации и т.п., специалисту по планированию не нужно искать это в большом числе маркшейдерских и геологических файлов. Все, что ему требуется для этого открыть в GEOVA Surpac соответствующее меню и выбрать данные, которые нужно загрузить в рабочее окно.

Инструменты автоматизации позволили легко произвести интеграцию GEOVIA Surpac и АСД ВИСТ Групп и сделать этот процесс максимально простым и быстрым.

Выбрав соответствующее меню в панели GEOVIA Surpac, геолог получает из АСД ВИСТ оперативные данные по отработке блока или данные на определенную дату и время. Эти данные используются для анализа текущей ситуации и обновления блочной модели.

После обновления блочной модели и контактов руда/вскрыша в GEOVIA Surpac геолог нажатием одной кнопки загружает эту информацию в систему АСД ВИСТ, после чего данные доступны для всех пользователей в обеих системах.

Благодаря объединению возможности инструментария позиционирования горнотранспортного оборудования в системе АСД ВИСТ Групп и инструментов GEOVIA Surpac были настроены процессы контроля движения горной массы от забоя до перегрузочного пункта, размещения горной массы в секторах перегрузочных пунктов, контроля баланса прихода/ухода горной массы по секторам и ведения мобильных остатков за период оперативного заполнения.
Для этого в GEOVIA Surpac были созданы блочные модели перегрузочных пунктов и разработана методика по их заполнению. По желанию геолога, процесс внесения в блочную модель (БМ) горной массы на виртуальный перегрузочный пункт, как и отгрузку с него, можно осуществлять как целиком за прошедший период, так и в оперативном режиме. Поставив на заполнение БМ с указанием времени окончания, макропрограмма сама производит запрос (через определенный интервал времени) на извлечение данных по экскаваторам, производящих черпание, а также извлекает информацию по движению и выгрузке автотранспорта на перегрузочный пункт.
Таким образом, по окончании работы макропрограммы формируется текущая информация по состоянию склада, наличию на данный период времени горной массы в трехмерном графическом виде и сводная таблица результатов оперативного изменения. Это позволило оперативно отслеживать движение руды, баланс и распределение горной массы на секторах перегрузочных пунктов, а также представлять графически эту информацию в обеих системах и обеспечить быстрый, свободный и безопасный доступ к информации для всех сотрудников. В частности, по словам ведущего геолога С.Н. Некрасова, такой процесс позволил повысить точность планирования отгрузки по качеству с перегрузочных пунктов на железнодорожный транспорт.
Также он отмечает, что если раньше можно было лишь предполагать, что было привезено на перегрузочные пункты и представлять только среднее значение качества по секторам, то сегодня известны показатели на каждом отдельно взятом участке сектора.

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

Подробнее о процессе и результатах интеграции, проведенной на Качканарском ГОКе, вы можете узнать из записи веб-семинара Новый подход к автоматизации планирования, ведения буровзрывных работ и управлению качеством на предприятии по ссылке

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

Подписывайтесь на новости Dassault Systmes и всегда будьте в курсе инноваций и современных технологий.

Dassault Systmes официальная страница

Facebook
Vkontakte
Linkedin
3DS Blog WordPress
3DS Blog on Render
3DS Blog on Habr

Подробнее..

Категории: Инженерные системы , Анализ и проектирование систем , Проектирование и рефакторинг , Erp-системы , Геология , Блог компании dassaultsystèmes , Dassault systemes , Geovia , Minesched , Erp , Surpac , Автоматизированные системы , Горные работы , Планирование горных работ , Маркшейдер

Цифровая трансформация завода (ч. 3) волшебные интерфейсы и оживление железа

30.01.2021 20:16:42 |

Автор: admin

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

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

Часть 3: Волшебные интерфейсы и оживление железа (в этой публикации)

Часть 4: Личные кабинеты, чат-боты и dream team

Влияние рабочего места диспетчера на пропускную способность отгрузки на заводе

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

Рекомендация: Не айтишные книги, которые полезно прочитать айтишнику

Принципы. Жизнь и работа. Рэй Далио
Цель. Процесс непрерывного совершенствования. Элияху Голдратт
Гемба Кайдзен. Путь к снижению затрат и повышению качества. Масааки Имаи

Какие идеи обычно возникают, когда нужно увеличить пропускную способность отгрузки на заводе:

Увеличить количество точек для одновременной отгрузки на заводе.
Увеличить количество КПП для одновременного въезда/выезда на завод.

На первый взгляд ответы правильные и логичные. Остается только найти пару 10 или 100 млн. руб. на инвестиционный проект и реализовать его.

Узкое горлышко найдено, дело за малымЛичный опыт: Не верьте программистам и консультантам

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

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

Еще одна причина:

Программист и консультант никогда не были в гемба и не видели, как именно пользователь работает с системой и насколько это соответствует реальным бизнес-процессам.

Общий счет 5:1 в пользу того, чтобы не верить программистам и консультантам, что у пользователей нет вопросов и проблем.

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

Выявленные на месте явные проблемы (без погружения в детали):

3 рукописных журнала для оперативной работы (при наличии рабочего места в ERP).
2 монитора, чтобы вывести нужную информацию (изображение с 2-х видеокамер, данные с 2-х промышленных весов, программы для вывода текста на Led-табло, монитор для работы в ERP).
Настольный калькулятор (для вычисления max. веса к погрузке по каждой машине).
Ручки и фломастеры (для заполнения настольных журналов).
Поток жалоб от диспетчера на ошибки в рабочем месте ERP и постоянные проблемы со вторым монитором, куда выводятся данные с промышленных весов.

Лайфхак #1: Фотографируйте рабочие места пользователей

Так выглядело рабочее место диспетчера, когда я приехал и это было нормой с 2016 года.

Часть рабочего места диспетчера, вид сверху

Монитор 1 - данные с 2-х камер, данные с 2-х весов, программа для led-табло

Монитор 2 - интерфейс рабочего места в ERP, беспощадный и жестокий

Настольный калькулятор и журналы на столе диспетчера

Журнал прибывших машин на погрузку с отметками плановых точек погрузки на заводе

Журнал с очередью машин (кто и во сколько приехал, когда и кого грузить, кто отгружен)

Журнал выданных номерных пломб (учет по сериям) по сменам диспетчеров

Лайфхак #2: Наблюдайте, слушайте диалоги, задавайте вопросы

Это помогло за одну 12-часовую смену понять суть работы диспетчера:

Регистрация прибытия водителей на погрузку.
Планирование времени отгрузки в журнале (формирование очереди).
Вызов водителей на погрузку по журналу (по очереди из числа прибывших)
Выдача номерных номерных пломб и магнитных карт, их регистрация в ERP (для погрузки).
Ручная отправка задания на промышленные весы (для взвешивания машины до погрузки).
Ручное вычисление max. веса к погрузке (по каждой машине с учетом грузоподъемности и веса пустой машины).
Ручная отправка на промышленные весы задания на погрузку (max. вес к погрузке).
Печать отгрузочных накладных (после окончания погрузки).

Простые замеры времени операций показали, что на заводе высокая скорость погрузки (одна машина грузится ~ 10 минут), но есть простои до 3-х минут между погрузкой машин , потому что диспетчер физически не успевает "обслужить" весь трафик.

Диалоги диспетчера с водителями обнажили бюрократию на рабочем месте и предвзятое отношение к водителям:

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

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

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

Нарисовались следующие задачи, которые были решены

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

На решение задач и автоматизации, которые дали наибольший эффект ~ 2 месяца с учетом покупки и настройки оборудования, закупки партий номерных пломб со штрихкодами, написания ТЗ и других связанных процессов.

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

На гифке сразу виден результат преобразований (автоматическая очередь машин в новом рабочем месте диспетчера в ERP).

Волшебное рабочее место диспетчера в ERP - маленький мир больших машинВремя "обслуживания" диспетчером одной машины сократилось в 10 раз

Автоматическая очередь машин через 1 КПП для 3-х точек отгрузки на заводе.
Автоматическое управление из ERP взвешиванием на промышленных весах.
Вся информация выведена на 1 экран 1 монитора пользователя.
Выдача номерных пломб и магнитной карты водителю с помощью сканера штрихкодов за 5 секунд.
Печать комплекта отгрузочных накладных диспетчером за 5 секунд.
Рабочее место диспетчера без журналов, калькулятора и фломастеров.

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

Так выглядят номерные пломбы для выдачи водителю:

Приходят в коробках по 10 тыс. шт. и соединены друг с другом пластиковыми "ножками" (особенность изготовления).
Изначально был только номер, затем мы заказали с нанесением штрихкодов.
Штрихкод просто кодирует номер самой пломбы.

Пластиковые номерные пломбы со штрихкодами

Чтобы диспетчеру было удобно одновременно выдавать номерные пломбы и магнитные карты, не путаясь в устройствах считывания, мы на магнитные карты наклеили штрихкоды с номером.

Примерка штрихкода для наклеивания на магнитную карту

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

Чтобы сканер различал штрихкоды, мы кодируем первый знак: 1 - штрихкод номерной пломбы, 2 - штрихкод магнитной карты.
Мы доработали подсистему распознавания штрихкодов, чтобы номерные пломбы не нужно было расцеплять до сканирования, и сканировать несколько раз без "задвоения" номеров штрихкодов.

ГЛАВНЙ РЕЗУЛЬТАТ: пропускная способность отгрузки продукции автотранспортом на заводе увеличена в 2 раза без капитальных затрат.

Подробнее, о том, что для этого было сделано, читайте далее...

Электронная очередь для грузового автотранспорта

Фактически очередь начинает формироваться на этапе приема заказов:

> с нашей доставкой, клиент указывает только дату и время выгрузки по адресу доставки.

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

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

Конкурентное преимущество: мы поддерживаем такой высокий уровень сервиса, чтобы клиенты могли получить продукцию завода: "день в день" - для регионов до 300 км, на следующий день - для регионов до 600 км, и через день - для регионов свыше 600 км.

Существующие ограничения на заводе при отгрузке в автотранспорт

Разная продукция завода отгружается в разные часы в течение суток.
Скорость отгрузки продукции на заводе не более 6 машин в час на 1 точку погрузки.
Один вид продукции отгружается с 2-х точек погрузки, второй - с одной точки.
Одновременно на заводе могут находиться не более 8 грузовых машин на всех точках погрузки.
Все машины заезжают на завод и выезжают с завода через 1 КПП и одного диспетчера в смену.

Пример настроек в ERP по действующим ограничениям

Настройки пропускной способности отгрузки в ERP

Настройки вариантов подбора свободного времени отгрузки продукции в ERP

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

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

Автоматический подбор свободного часа погрузки на заводе (по заказу в ERP) для доставки клиенту ко времениВ какой момент формируются 3 разные очереди в ERP

Заказ клиента принят 21.01.2021 в 11:14.
Расстояние от завода до пункта разгрузки у клиента 630 км.
Чтобы доставить заказ клиенту 22.01.2021 к 8:00, машина должна приехать на завод для погрузки 21.01.2021 не позднее 15:00 - это плановая очередь погрузки.
Когда машины приезжают на завод для погрузки - это фактическая очередь прибытия.
По плановому времени погрузки по заказу и фактическому времени прибытия машин на завод строится реальная очередь на отгрузку.

Способы регистрация прибытия водителей на заводе:

через диспетчера
через уличный терминал
через чат-бот Telegram (подробнее в четвертой части)
через распознавание гос. номера машины (в планах на этот год)

Пример регистрации водителей через диспетчера в ERP

Диспетчер отмечает прибытие водителей правой кнопкой мыши в своем рабочем месте в ERP

Машины, которые фактически находятся на погрузке на заводе.
Очередь машин на погрузку по статусам:

- кто еще не прибыл на завод (НЕ ПРИБЛ).

- кто прибыл и ожидает своей очереди (В ОЧЕРЕДИ).

- кто прибыл и автоматически приглашен к погрузке (К ПОГРУЗКЕ).
Динамические данные двух промышленных весов (показ только у диспетчера).
Изображение с двух камер на точках погрузки на заводе.

Пример регистрации водителей через уличный терминал на заводе

Сенсорный антивандальный монитор 24" российского производства (широкоформатный 16:9, TFT TN, 1920х1080, углы обзора 160/160), установлен на КПП завода.
Монитор без собственного ПО для подключения к любому ПК, с особыми характеристиками яркости (1000 кд/м2) и температурного режима (-30/+30), в защищенном корпусе (сталь 2 мм) c закаленным стеклом (4 мм) и весом ~ 20 кг.
Монитор подключен к системному блоку, на котором автоматически запускается ERP и разработанный нами интерфейс для самостоятельной регистрации прибытия водителей на погрузку.

Начальный экран - крупные шрифты, большие кнопки, не промахнешься

Шаг 1: Быстрый поиск по водительскому удостоверению - водитель не найден

Шаг 2: Быстрый поиск по цифрам гос. номера автомобиля

Шаг 3: Найденные по гос. номеру автомобили - выбор и подтверждение

Шаг 4: Проверка данных и регистрация прибытия на погрузку

Таймер обратного отсчета мотивирует водителя выполнять действия быстрее, чтобы не задерживать очередь у терминала.

Этот кейс также относится к теме оживления железа (оживление с помощью разработанного ПО для автономной работы в составе единой информационной системы), но здесь подробно рассматриваться не будет.

Пример регистрации водителей через чат-бот Telegram

Водитель отмечает прибытие на завод для погрузки в чат-боте Telegram

Команда прибытия на погрузку в чат-боте Telegram.
Уведомление водителя с подтверждением времени прибытия.

Чат-бот для водителей в Telegram интегрирован с ERP в режиме онлайн и работает автоматически по заданным сценариям (подробнее в четвертой части).

Как происходит автоматический вызов водителя на погрузку из очереди:

Способ регистрации прибытия	Канал вызова на погрузку
через диспетчера	уличное LED-табло и SMS
через уличный терминал	уличное LED-табло и SMS
через чат-бот Telegram	уличное LED-табло и чат-бот Telegram
через распознавание гос.. номера (в плане)	уличное LED-табло и SMS (в плане)

Пример приглашения водителей на погрузку по SMS

Автоматическое приглашение водителей на погрузку по SMS

Пример приглашения водителя на погрузку в чат-боте Telegram

1 - водитель отметил прибытие на завод, 2 - чат-бот автоматически пригласил на погрузку

На скриншоте ниже видно историю взаимодействия водителей с чат-ботом Telegram в интерфейсе ERP (подробнее в четвертой части).

Автоматическое приглашение водителей на погрузку в чат-боте Telegram

Пример приглашения водителей через уличное Led-табло

Автоматическое приглашение водителей на LED-табло по гос. номеру автомобиля

Размер каждой LED-панели примерно 1,5 х 2 метра.
LED-панели развернуты на 2 стороны стоянки грузовых автомобилей перед заводом.

И если SMS или уведомление в чат-бот Telegram отправляется однократно, то приглашение на уличное LED-табло может выводиться несколько раз в соответствии с тем, как меняется автоматическая очередь в ERP:

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

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

Оживление LED-табло и автоматическое управление из ERP

Уличные LED-панели были куплены еще до начала работ по комплексной автоматизации рабочего места диспетчера, взамен старого (с которым раньше работали диспетчеры через программу для ручного вывода строк).

Фото от российского производителя LED-панелей (1,5 х 2 м), готовых к отправке на завод

Вместе с LED-панелями производитель предоставил программу для вывода строк на табло.

Окно программы для вывода текстовых строк на LED-табло

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

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

Пример 3-х страниц с описанием протокола

Страница 2 описания протокола Страница 5 описания протокола

Страница 5 описания протокола Страница 8 описания протокола

Страница 8 описания протокола

С программистом 1С мы посмотрели протокол и не поняли, как именно управлять выводом очереди машин на табло из ERP.

По нашей просьбе, изготовитель LED-панелей договорился с производителем компонент электроники, из которых оно состоит, чтобы они написали пример кода для программного вывода информации на табло. Пример был написан на языке Pascal, который программист с большим трудом перевел на язык 1С.

Пример кода на языке Pascal (Delphi 10) по использованию протокола

unit ConnTypes;interfaceconst     RecBuffSizeByte=1024;typeTLevel2Pack=packed record  SrcAddr:word; //source address  DstAddr:word; //receiver address  PId:byte;     //Packet id  Cmd:byte;   // Command code  Flags:byte;  //options  Status:byte; //command status  DataLen:word; //length of data  Data:array[0..RecBuffSizeByte-1] of byte;  //data  end;PLevel2Pack=^TLevel2Pack;TLevel2Head=packed record  SrcAddr:word; //source address  DstAddr:word; //receiver address  PId:byte;     //Packet id  Cmd:byte;   // Command code  Flags:byte;  //options  Status:byte; //command status  DataLen:word; //length of data  end;PLevel2Head=^TLevel2Head;TFullPacket=packed record  bSTX:byte;  LenLo:byte;  LenHi:byte;  Data:array[0..RecBuffSizeByte*2-1+32] of byte;  end;  PFullPacket=^TFullPacket;function MakeFullPacket(Src:PLevel2Pack; Dst:Pointer):integer;function EncodeWord(v:word):word;implementationuses CRCUnit;function CS2word(cslo, cshi:byte):word;var b:PByte;beginResult:=0;b:=@Result;b^:=cslo or $80;inc(b);b^:=$80 or ((cslo shr 7) and $01) or ((cshi and $3F) shl 1);end;function EncodeWord(v:word):word;beginResult:=((v and $3F80) shl 1) or (v and $7F) or $8080;end;function DecodeWord(v:word):word;beginResult:=((v and $7F00) shr 1) or (v and $7F);end;function EncodeDataForComm(Src, Dst:Pointer; SrcSize:integer):integer; var PS, PD:PByte;     i:integer;     b:byte;  begin  PS:=Src;  PD:=Dst;  Result:=0;  for i:=1 to SrcSize do    begin    b:=PS^ xor $80;    if (b<$20) or (b=$7F)       then begin            PD^:=$7F;            inc(PD);            PD^:=b or $80;            inc(Result);            end       else PD^:=b;    inc(PS);    inc(PD);    inc(Result);    end;  end;function MakeFullPacket(Src:PLevel2Pack; Dst:Pointer):integer;var cs:word;    PB:PByte;    F:PFullPacket;    PackLen:word;    PackSize:integer;  begin  PB:=Dst;  F:=Dst;  cs:=0;  PackLen:=word(Src^.DataLen+sizeof(TLevel2Head));  CountCSNewW(Src, PackLen, cs);  F^.bSTX:=$02;  PWord(@F^.LenLo)^:=EncodeWord(PackLen);  inc(PB, 3);// add bSTX, LenLo, LenHi  PackSize:=EncodeDataForComm(Src, PB, PackLen);  inc(PB, PackSize);  PWord(PB)^:=EncodeWord(cs);  inc(PB, 2); // add CsLo, CsHi  PB^:=$03;  Result:=PackSize+6;  end;end.

Таким образом, нам удалось реализовать полностью автоматическое управление выводом очереди на LED-табло из ERP.

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

Спасибо, что дочитали до конца!

Подробнее..

Категории: Интерфейсы , Управление проектами , Управление разработкой , Будущее здесь , Ui , Erp-системы , Интеграция систем , Erp , Digital , Завод , Автоматизация предприятия , Пропускная способность , Узкое место

Управление требованиями и сроками в методологии Oracle AIM BF

21.07.2020 18:12:25 |

Автор: admin

При внедрении ERP компания Oracle использует методологию (AIM for BF Application Implementation Method for Business Flow в прошлом, а ныне OUM Oracle Unified Method), в которой применяется итеративный подход ко внедрению системы. Этот подход включает в себя несколько ключевых положений:

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

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

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

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

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

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

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

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

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

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

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

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

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

Резонно возникает вопрос, каким образом организовать процесс таким образом, чтобы не уйти на четвертую, а потом на пятую или шестую итерации? Каким образом избежать риска неконтролируемого изменения и уточнения требований, что складывается естественно по мере погружения в детали, а иногда из-за изменения бизнеса?

Безусловно риск такой есть, и он весьма существенный. На входе в проект требования зафиксированы в договоре, но как правило они сформулированы в общем виде, а дьявол кроется в деталях.

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

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

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

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

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

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

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

Резюме всему вышесказанному:

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

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

Подробнее..

Категории: Управление проектами , Erp-системы , Oracle , Erp , Aim , Oum

Обучение пользователей в эпоху коронавируса

30.08.2020 16:23:02 |

Автор: admin

Карантин пришелся на период подготовки к запуску большой ERP системы на крупном механоремонтном предприятии. Встал вопрос как обучать пользователей системы, коих было около 600 человек? Проблема в том, что это не те люди, которые на ты с компьютером, и которые рвутся учиться работе в новой системе.

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

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

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

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

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

Второе, количество пользователей помноженное на количество бизнес-процессов (~2500), с учетом сменности и доступности пользователей давало значительно число обучающих сессий. Бизнес-процессы разные от самых простых до весьма сложных. Было решено применить комбинированных подход. По самым простым темам пользователям было предложено прочитать инструкцию и проделать самостоятельные задания. Для более сложных, и там где было много пользователей, записали видеоролики. Где было меньше пользователей, а вариантов использования системы больше, проводили онлайн занятия через skype. И наконец для самых продвинутых, там где было по 1-3 человека сделали исключение, и провели очное обучение.

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

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

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

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

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

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

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

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

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

Подробнее..

Категории: Управление проектами , Oracle , Erp , Обучение пользователей

Digital-трансформация завода CRM для ERP, роботизация БП и оживление железа, ЛК, чат-боты и dream team (ч. 1)

18.01.2021 12:13:17 |

Автор: admin

Часть 1: CRM для ERP (в этой публикации)

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

Часть 3: Личные кабинеты, чат-боты и dream team

Текущий уровень автоматизации: 2 года назад

Ситуация на момент моего прихода в компанию на должность CIO:

Коротко о заводе: круглосуточное производство, круглосуточная отгрузка продукции
Необновляемая с 2014 года ERP 2 и платформа 1С, пресс-релиз о внедрении
Бизнес-процессы компании, оторванные от бизнес-процессов в ERP, и как следствие:
- Параллельная вселенная в виде файлов Excel, Google-таблиц и облачных хранилищ
- Присутствие журналов и реестров для ручного заполнения сотрудниками
- Много бумажного документооборот, в т.ч. с контрагентами
Минимум данных в ERP-системе и исторические "костыли" в разработке
Скромный сайт компании без какого-либо функционала и интеграций
Штат ИТ не укомплектован, процессы в дирекции толком не выстроены
Огромный список "зависших" текущих задач, начиная с 2016 года
Поддержка: 2 сисадмина и 1 помощник, консультант 1С и консультант-программист начального уровня на ГПХ
Один договор с одной местной компанией "1С:Франчайзи" на оказание услуг
Авральный режим работы пользователей и бесконечное "тушение" пожаров службой ИТ
Большое желание руководства компании выйти на новый уровень автоматизации

Первая smart-задача: "сделать CRM за 3 месяца!"

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

К счастью, с CRM-системами я был хорошо знаком

Еще с 2016 года, когда я был руководителем проектов внедрений в ИТ-компании, у меня уже были клиенты, которым мы продавали и настраивали 1C:CRM.

В 2018 году я возглавил новое направление в этой же ИТ-компании по внедрению популярных CRM-систем (1C:CRM, amoCRM, Битрикс24.CRM).

Личный опыт придал мне сил и уверенности выполнить задачу в сжатые сроки. А скромный ИТ-бюджет, доставшийся по-наследству, только добавлял драйва и азарта.

"Коробочная" CRM для исторической ERP: это реально!

Неожиданная новость: у нас уже заключен договор на разработку CRM

За 2 месяца до прихода в компанию, мой предшественник заключил договор на разработку CRM-системы (именно разработку новой CRM "с нуля", а не внедрения существующих).

Ко мне на встречу пришел программист 1C, который выполнял разработку CRM-системы для нашей ERP, чтобы сдать проект и подписать акт.

Тщательный аудит и проверка работ на соответствие ТЗ показала, что это была попытка "срубить бабла". Фактически в ERP была включена функциональная опция встроенной подсистемы CRM (набивалка) и настроены статусы документа "Сделка" в качестве "воронки" продаж.

Самое интересное, что ТЗ было написано подрядчиком и весьма не плохо, но до разработки так и не дошло.

Договор был расторгнут по причине невыполнения ТЗ.

Далее по совокупности критериев, здравого смыла, и сохранения режима "одного окна" в ERP для менеджеров по продажам - принято решение встроить "коробочный" модуль 1C:CRM 3.

Первая сложность: актуальный модуль 1C:CRM 3 подходил только для ERP 2.4, а у нас редакция 2.1.

Вторая сложность: историческая ERP сильно кастомизирована, местами очень "криво".

Третья сложность: никто из подрядчиков не соглашался выполнять эту задачу, по вышеуказанным причинам.

Лайфхак: Facebook спешит на помощь

Мой 12-летний опыт внедрения различных конфигураций 1С говорил о том, что эти сложности решаемые, и модуль можно интегрировать с ERP.

Хотя подобных кейсов в интернете и на технических форумах я не нашел, обратился к разработчикам через партнерскую группу в Facebook:

Разработчики честно ответили, что на их практике такого не было, но гипотетически это возможно, если перенести часть БСП из ERP 2.4 в ERP 2.1 (после чего попробовать интегрировать сам модуль).
Один из партнеров с Украины ответил положительно. На их практике было 2 успешных внедрения, когда они встраивали модуль 1C:CRM 3, только в ERP 2.2.

Скриншоты переписки из Facebook я отправил по email потенциальным подрядчикам, и один из них согласился выполнить работу.

Через месяц модуль 1С:CRM 3 был встроен в нашу ERP 2.1.

Еще месяц ушел на интеграцию CRM с почтой, офисной АТС в "облаке" и сервисом отправки SMS.

Еще около месяца ушло настройку новой подсистемы, "воронки" продаж, портрета клиента, обучения менеджеров по продажам.

Smart-задача выполнена в срок.

После запуска в эксплуатацию, CRM получила развитие:

Новый сайт компании, интегрированный с ERP (подробнее во второй части)
Интеграция ERP с Wialon и ЭТРАН
SMS-робот и Email-робот

Ноу-Хау: Самый краткий CRM-отчет для оценки KPI

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

Отчет в CRM для оценки KPI менеджеров по продажам

По данным ERP
По данным звонков и писем с контактным лицам клиентов в CRM
По данным CRM
По данным звонков, сайта и почты в CRM
По данным ERP
По данным ERP
По данным CRM
По данным CRM

Внимание!

С появлением этого отчета, менеджеры тщательно проверяли в нем данные, чтобы не был потерян ни один звонок, ни одно письмо.

Этот отчет мотивирует менеджера по продажам:

- Поддерживать актуальную контактную информацию по всем клиентам.

- Звонить и вести переписку с клиентами с корп. SIM и корп. почты.

- Добиться от ИТ, чтобы CRM работала корректно.

Факты: Фиксация всех входящих и исходящих звонков в ВАТС и CRM

Связка "ВАТС + номер 8-800 + корп.SIM + Софтфон + CRM" иногда сбоила и некоторые звонки не фиксировались. Для решения всех проблем с корп.SIM и номером 8-800 потребовалось около трех месяцев плотной работы с саппортом Мегафон и Рарус.

Мы добились выпуска нескольких обновлений и 100% фиксации звонков в CRM.

Все звонки в ВАТС (8-800, корп. SIM, офисная АТС)

Все звонки в CRM (входящие, исходящие, пропущенные)

Пример: Воронка продаж, портрет клиента, потенциальные сделки

Основные инструменты менеджера по продажам в CRM для работы с клиентами:

Портрет клиента в CRM (детальный)

Воронка продаж в CRM (канбан менеджера)

Потенциальная сделка в CRM (история взаимодействий)

Мы также нашли способ автоматической фиксации фактов встреч менеджеров с клиентами в CRM по данным GPS и мобильной сети (не реализовали только из-за отсутствия полноценного API со стороны сервисов, а ручной режим нам не нужен).

Ниже пример стандартных отчетов в CRM:

Анализ источников привлечения клиентов

Анализ источников привлечения в CRM

Причины потерь потенциальных сделок (клиентов)

Анализ потерь интересов в CRM

SMS-робот и Email-робот для автоматических уведомлений

Модуль 1C:CRM для ERP уже содержал в себе функционал для подключения к SMS-провайдеру и электронной почты, поэтому мы реализовали только автоматические уведомления по SMS и Email, и интеграции с другими сервисами:

Клиентов об отгрузке продукции со складов в автомобили и вагоны (через интеграцию ERP с промышленными весами, подробнее во второй части).
Клиентов об убытие машины с территории завода со ссылкой-треком для отслеживания на карте (через интеграцию ERP с Wialon).
Клиентов о приближение машины у пункту разгрузки (через интеграцию ERP с Wialon).
Клиентов о прибытие вагонов на ЖД станцию для выгрузки (через интеграцию ERP с ЭТРАН).
Клиентов о необходимости разместить заказ (по расписанию для контактного лица).
Менеджеров по продажам о новых заявках клиентов, поступивших в нерабочее время.
Клиентов на самовывозе и перевозчиков - об опоздании водителей на погрузку (через интеграцию ERP с чат-ботом и уличным монитором, подробнее во второй и третьей части).
Перевозчиков о срочных заявках и опоздании водителей на погрузку (через интеграцию ERP с личным кабинетом перевозчика, подробнее в третьей части).
Перевозчиков о штрафах по опозданиям на погрузку и выгрузку (через интеграцию ERP с Wialon).

Как выглядят сообщения SMS-робота в ERP

СМС-робот в ERP для уведомлений

Все SMS отправляются с символьного имени, от лица компании.

Как выглядят письма Email-робота в ERP

Письма с вложениями и без:

Вложения - это отчеты в формате Excel, автоматические сформированные в ERP.
Формы отчетов Excel сразу адаптированы для печати на принтере.
Тексты писем адаптированы для чтения в смартфоне и ПК.
Письма в ERP синхронизованы с почтовым сервером.

Почтовый робот в ERP для уведомлений

Интеграция ERP с Wialon: автоматический сбор данных по GPS

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

Это набор готовых сервисов, связанный в единую подсистему. Срок реализации 2 месяца.

Пример SMS-сообщений показан на скриншоте выше.

Схема интеграции сервисов и данных для SMS-уведомлений клиентов о статусе доставки продукции

Забегая вперед, мы также используем уведомления в чат-бот Telegram (подробнее в третье части). SMS - потому что не у всех контактных лиц клиентов есть доступ в интернет на адресах доставки, а мобильная сеть какая-никакая есть практически всегда.

Пример автоматического отчета для контроля прибытия машин на погрузку и выгрузку

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

Такая система, в связке с личным кабинетов перевозчика и чат-ботом для водителей (подробнее в третьей части):

Дисциплинирует перевозчиков и водителей соблюдать сроки погрузки и доставки
Повышает лояльность клиентов и гарантирует своевременные поставки точно в срок

Спасибо, что дочитали до конца!

Задавайте вопросы, постараюсь на все ответить.

Подробнее..

Категории: Управление проектами , Управление разработкой , Будущее здесь , Crm-системы , Erp-системы , Crm , Crm-система , Кейсы , Erp , Digital , Интеграция , Digital-трансформация , Завод

Digital-трансформация завода CRM для ERP, роботизация БП и оживление железа, ЛК, чат-боты и dream team (ч. 2)

21.01.2021 14:15:10 |

Автор: admin

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

Часть 2: Роботизация бизнес-процессов (в этой публикации)

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

Часть 4: Личные кабинеты, чат-боты и dream team

Роботизация бизнес-процессов на примере закупок (2 кейса)

Как часто выглядит процесс закупок на предприятии (без погружения в детали):

Поиск поставщиков и запрос коммерческих предложений.
Сравнение полученных предложений и выбор поставщика.
Заключение договора и осуществление поставки.

Сразу возникают элементарные вопросы:

Где найти поставщиков и как запросить коммерческие предложения?
Как сравнить полученные коммерческие предложения и выбрать поставщика?
Как заключить договор и проконтролировать поставку?

Обычно это происходит так:

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

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

Обычный рабочий день менеджера по закупкам

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

Какие подготовительные этапы были выполнены в ERP до роботизации бизнес-процессов

Исправление ошибок в исторических данных справочника номенклатуры(сначала автоматически с помощью разработанных алгоритмов; затем визуальная проверка и исправление пользователями того, что не удалось однозначно сделать в автоматическом режиме):

- исправление орфографических ошибки с помощью интеграции сЯндекс.Спеллер

- удаление "мусорных" символов в наименованиях (спец.символы, кавычки, буквы "ё", лишние пробелы)

- замена латинских букв в русских словах на буквы кириллицы, и наоборот

- и другие алгоритмы исправления ошибок в наименованиях (всего 8)
Разработанные алгоритмы исправления ошибок в наименованиях номенклатуры в ERP
Упорядочивание данных в справочнике номенклатуры:

- логическое группирование по видам номенклатуры

- введение аналогов и замен
Обогащение данных в справочниках контрагентов и контактных лиц:

- разработка и заполнение портрета поставщика (частично автоматическое на основе исторических данных о поставках в ERP)

- актуализация контактных данных контрагентов (email, телефоны)

- актуализация данных контактных лиц контрагентов (ФИО, должность, email, мобильные телефоны)

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

Кейс #1: Роботизация процесса проверки поставщиков

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

В одном процессе участвуют 3-4 сотрудника из разных подразделений:

Менеджер по закупкам (ставит задачи менеджеру по документообороту, контролирует ход процесса проверки).
Менеджер по документообороту (запрашивает документы у контрагентов и выполняет их первичную проверку).
Юрист (выполняет юридическую проверку контрагента и документов).
Сотрудник службы безопасности (при необходимости).

ВАЖНО!Чтобы не только правильно выполнялась процедура проверки, но вовремя запрашивалась и поступала информация от поставщиков, вовремя выполнялись и передавались задачи между всем участниками процесса проверки, включая поставщиков.

Для роботизации процесса проверки поставщиков в ERP мы связали в одну систему следующие компоненты:

ERP-система (рабочее место сотрудников).
Сайт компании (интеграция с ERP и сервисом DaData.ru).
Почта Gmail (интеграция с ERP и сайтом).
Сервис DaData.ru (интеграция с сайтом и ERP).
Сервис 1С:Контрагент (интеграция с ERP).

На сайте компании разработана форма для самостоятельного заполнения контрагентом.

Для простоты заполнения к форме сайта подключен сервис DaData.ru - это и заполнение поле из общедоступных справочников и автоматическое заполнение связанных полей.

Пример формы на сайте для заполнения поставщиком

1, 2, 3, 4 - Заполнение по справочникам из сервиса DaData.ru

5 - Список компетенций поставщиков и подрядчиков из ERP

Все формы на сайте адаптивные, можно легко заполнить на смартфоне.

Пример адаптивной формы на сайте для заполнения поставщиком

Адаптивная форма для заполнения на смартфоне

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

Пример формы документа проверки поставщика в ERP

Пользовательский интерфейс в ERP для проверки поставщика

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

Робот автоматически отклоняет проверку контрагентас отрицательным результатом по 10 признакам, и одновременным уведомлением по email поставщика о причине.

Проверка контрагента в ERP автоматически не пройдена

1 - Робот автоматически устанавливает отрицательный статус проверки и завершает бизнес-процесс проверки.

2 - Робот автоматически определяет причина не прохождения проверки, и автоматически отправляет контрагенту письмо с причиной не прохождения проверки.

3 - Менеджер по закупкам всегда может обосновать проведение проверки, отправив ответственному задачу на согласование (бизнес-процесс проверки будет автоматически инициирован при положительном согласовании).

Пример автоматических признаков, которые проверяет робот проверки поставщиков

10 причин автоматического не прохождения проверки контрагента

Пример автоматического письма поставщику, когда проверка не пройдена

Автоматическое письмо поставщику от робота, что проверка не пройдена

Когда у робота нет причин отклонять проверку,в ERP автоматически стартует бизнес-процесси сотрудники начинают получать автоматические задачи.

Пример задачи, которую получает сотрудник на своем рабочем месте в ERP

Автоматическая задача пользователю от робота в ERP

1 - Назначен ответственный

2 - Установлен крайний срок выполнения задачи

3 - Ссылка на документ проверки поставщика

Таким образом,робот автоматически ставит задачи разным сотрудникам(или ролям) при переходе бизнес-процесса проверки на разные этапы.

Пример истории задач сотрудникам при проверке поставщика

История автоматических задач по проверке поставщика в ERP

Все задачи для сотрудников имеют сроки выполнения.Настройки всегда можно изменить в ERP (в пользовательском режиме).

Пример настроек робота в ERP для бизнес-процесса проверки поставщиков

1 - Настройки адресации ролей и сроков выполнения задач ответственными.

2 - Настройка служебных ролей для ожидающих процессов.

3 - Настройка срока ожидания повторного предоставления документов поставщиком (после чего проверка завершается автоматически с отрицательным результатом).

Настройки бизнес-процесса для робота проверки поставщиков

Когда в процессе проверки поставщикасотрудник выявляет недочеты, он устанавливает переключатель в положение "Не соответствует" и указывает причину в комментарии.

Сотрудник выявил несоответствия при проверке

Контрагент получает автоматическое письмо по emailдля устранения выявленных замечаний:

1 - Замечание по каждому документу.

2 - Уникальная ссылка с ограниченным сроком действия.

Робот автоматически отправляет email поставщику со ссылкой для повторного предоставления документов

Форма на сайте, открытая по уникальной ссылке из письма, предлагает загрузитьтолько те документы, которые запрошеныу контрагента повторно.

Пример формы на сайте для повторного запроса документов

Сгенерированная форма на сайте для повторной отправки документов для проверки контрагента

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

Пример истории почтовых писем от робота по одной проверке поставщика

История автоматических писем в ERP в документе проверки контрагента

Все шаблоны автоматических писем настраиваются в ERP (в пользовательском режиме).

Пример настройки почтовой подсистемы для робота проверки поставщиков

1 - Настройки почтовых ящиков для уведомлений.

2 - Настройка почтовых ящиков для загрузки данных с сайта.

3 - Настройка шаблонов автоматических email для различных событий.

Настройки почтовой подсистемы робота проверки поставщиков

Плюсы роботизации бизнес-процесса проверки поставщиков:

1. Из процесса проверки исключен один сотрудник - менеджер по закупкам.

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

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

Высвобождается время у менеджера по документообороту для запроса документов по email, и у поставщика для выяснения вопросов и пересылки писем.

3. Робот автоматически проверяет поставщиков по 10 признакам.

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

4. Робот автоматически ставит задачи сотрудникам разных подразделений.

Сотрудникам не нужно думать о том, кому передать результат своей работы, а задачи не будут забыты или просрочены.

5. Робот автоматически пишет письма поставщикам.

Сотрудникам не нужно тратить время на написание писем, а поставщики всегда получают обратную связь.

6. Не нужно увеличивать штат сотрудников при увеличении числа поставщиков.

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

7. Новые поставщики приходят самостоятельно через сайт компании.

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

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

Настройки и функционал робота проверки статуса ликвидации организаций

Настройки робота проверки статуса ликвидации всех контрагентов в ERP

Ежедневно ночью робот автоматически проверяет всю базу контрагентов в ERP и актуализирует статус ликвидации по каждому ИП и юр. лицу (интеграция с сервисом DaData.ru).

При обнаружения признака ликвидации у контрагента:

1 - Робот автоматически уведомляет ответственных сотрудников.

2 - Робот приостанавливает оплаты в счет контрагента.

3 - Робот маркирует карточку контрагента в ERP.

Виджет проверки статуса ликвидации в карточке поставщика в ERP

Кейс #2: Роботизация процесса запроса КП у поставщиков

Процесс сбора, обработки и согласования коммерческих предложений не менее трудоемкий, чем процесс проверки поставщиков:

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

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

Для роботизации процесса запроса и обработки коммерческих предложений в ERP, мы связали в одну систему следующие компоненты:

ERP-система (рабочее место сотрудников).
Сайт компании (интеграция с ERP).
Почта Gmail (интеграция с ERP и сайтом).

Рабочее место менеджера по закупкам в ERP с функционалом запроса КП через сайт

Шаг 1:Менеджер выбирает позиции (1) для запроса предложений через сайт (2).

Выбор позиций номенклатуры для запроса КП через сайт

Шаг 2:Робот автоматически выбирает (1), и показывает менеджеру подходящих поставщиков (2) и контактных лиц (3) с заполненными email (4), а также компетенции, результаты проверок и последние поставки (5).

Робот выбрал подходящих поставщиков и контактных лиц для запроса КП

Шаг 3:Менеджер выполняет визуальную проверку и запрашивает КП через сайт.

Шаг 4:Для каждого контрагента робот автоматически создает письмо со ссылкой для заполнения коммерческого предложения.

Робот создал и отправил письма с запромо КП каждому поставщику

Письма, отправленные роботом из ERP

На сайте разработана динамическая форма для заполнения поставщиком коммерческого предложения:

1. Условия оплаты (налогообложение, цены с НДС или без, ставка НДС,наличие отсрочки и размер аванса).

2. Условия поставки (способ и срок доставки, наличие и срок гарантии).

3. Товары к поставке (цены, особые условия гарантии, сроков поставки или аналоги).

Пример формы на сайте для заполнения КП поставщиком

Форма на сайте для заполнения коммерческого предложения поставщиком

Таблицу товаров к поставке можно скачать в Excel.

Пример адаптивной формы на сайта для заполнения КП на смартфоне

Форму коммерческого предложения можно заполнить прямо в смартфоне

Важно!Чтобы поставщик не тратил время на подготовку формы коммерческого предложения, ее можно:

Скачать уже заполненную прямо на сайте.
Распечатать, поставить подпись и печать.
Отсканировать и загрузить на сайт.

Пример заполненной формы коммерческого предложения от лика поставщика

Печатная форма коммерческого предложения для скачивания с сайта

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

Такие образом, все коммерческие предложения поступают в ERP автоматически.

После окончания срока приема предложений, в ERP автоматически формируется аналитическая записка.

Робот автоматически формирует аналитическую запискуи сравнивает все предложения от поставщиков по одним и тем же критериям (1), и ранжирует претендентов (2) в порядке убывания.

Аналитическая записка, сформированная роботом в ERP

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

Мы разработали и других роботов, которые работают в режиме 24/7 и облегчают жизнь.

Спасибо, что дочитали до конца!

Задавайте вопросы, постараюсь на все ответить.

Подробнее..

Категории: Управление проектами , Управление разработкой , Будущее здесь , Api , Erp-системы , Интеграция систем , Erp , Digital , Автоматизация рутины , Интеграция сервисов , Роботизация процессов , Завод , Автоматизация предприятия

ERP для собственников. Философское. Часть 1

10.03.2021 00:12:29 |

Автор: admin

Вступление

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

О чем это?

Начну с частного примера. Представьте себе что ты - собственник компании. Ты считаешь что у тебя есть и ERP и CRM (эта эротическая фантазия может возникнуть, например, из-за наличия у тебя BAS ERP).
И вдруг тебе в голову приходит замечательная управленческая инициатива: персонально связываться с регулярными клиентами, которые перестали у тебя покупать: звонить, выявлять причину отказа и оперативно возобновлять сотрудничество.
Для этого у тебя есть много вариантов реализации. Позволь я назову их не-ERPшными вариантами.

Например, ты можешь попросить своего ИТшника сделать отчет. Очень простенький отчет типа отобрать клиента с признаком РЕГУЛЯРНЙ, у которого за последние 60 дней продажи равны 0.
Но есть проблема. Ты этот отчет запустишь только один раз - когда твой ИТшник будет сдавать работу. Ты его похвалишь, подпишешь акт - и забудешь. Отчет потеряется в дебрях встроенных менюшек. Отчеты - Сервисные - Дополнительные - Для руководства - Клиентские - Не покупающие. Я знаю о чем говорю. Моей команде часто заказывают уникальные отчеты, а практически во всех системах есть журналы использования объектов, которые можно использовать как счетчики. Спустя годы максимальное количество запусков заказанного топ-менеджерами отчета была 16 раз, среднее - 3 раза.

Другой вариант - обязать секретаршу приносить этот отчет ежемесячно. Тут тоже есть проблема. Первого числа следующего месяца ты успеешь позвонить первым пяти клиентам.
Алло, Юрий Петрович? Это Жора Сидоров, собственник Сидоров и партнеры, есть пара минут? Последние два месяца вы у нас ничего не покупаете - вот звоню, может случилось чего? Если есть - я готов решить их тут же, для нашего дальнейшего сотрудничества. Менеджер Костя подвел? Извините, пожалуйста - вы никогда больше не услышите Костю. Давайте следующие 2 месяца я лично буду вашим персональным менеджером, а после - я дам вам на сопровождение нашего лучшего сотрудника и 5% скидки. итд, итд, итд. На пятом клиенте - тебя отвлекут. Отчет потеряется среди кипы текущих бумаг.
Через месяц первого числа ты успеешь обзвонить только двух клиентов. Потом тебя отвлекут.
А на третий месяц твоя секретарша просто не принесет тебе этот отчет.

А что делать?

Но есть другой вариант - позволь мне назвать его ERPшным.

Ровно на 61й день у тебя пиликает телефон (или почта или СМСка или клиент ERP\CRM) и на экране написано:
Сценарий 23. Регулярный клиент не покупает 2 месяца. Клиента зовут Юрий Петрович. Нажми ТУТ чтобы начать звонок.
Ты жмешь кнопку и начинаешь заученное Алло, Юрий Петрович? Это Жора Сидоров, собственник Сидоров и партнеры, есть пара минут?.
А после конца разговора у тебя появляется меню действий: Отправить свежий прайс, Оформить отгрузку клиенту, "Сменить менеджера", Перезвонить через 2 недели. И на каждый пункт меню - автоматизированная цепочка действий.

А разница-то в чем?

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

Время философии.

И тут мы приходим к трехуровневой проблеме. Эта проблема - не техническая, она управленческая. Или, возможно, психологическая. Или - философская.
Слушай.

Первый уровень проблемы

Ты должен четко понимать что вот-этот-вот месседж в телефоне - это не прихоть программиста и не спам телефона. Это твой, собственника, личный приказ с прошлого - себе-будущему: "Позвони, сволочь ленивая, Юрию Петровичу".
Понимаешь? Ты привык отдавать себе приказы с помощью ежедневника? Позвонить, поздравить, заехать. Вот это - точно такой же приказ. Твой приказ себе самому.
Как только ты это поймешь - дела с внедрением ERP сразу пойдут лучше. Но есть и другая сторона. Если у тебя нет ежедневника или ты привык опаздывать на встречи или твои подчиненные часами ждут тебя после окончания рабочего дня (проще говоря - ты не привык отдавать приказы себе-будущему) - даже не пробуй внедрять ERP. Напрасная трата денег. Это не для тебя.

Второй уровень проблемы

На втором уровне - восприятие твоих подчиненных.
Представь что, по твоему приказу, этот-вот обзвон должен делать коммерческий директор. Это значит что когда его, коммерческого директора, телефон пропиликает - он должен воспринять это как твой приказ.
Все твои подчиненные тоже должны понять что любое управляющее воздействие, пришедшее от ERP - это не прихоть консультанта, программиста или компьютера. Это - прямой приказ собственника. И неисполнение того что пропиликало (или игнорирование пиликанья или непрочтение того что пропиликало) - должно восприниматься как неисполнение твоего приказа, с соответствующими оргвыводами: выговор, депремирование, увольнение.
Это твой приказ. Точка. Как только твои подчиненные это осознают - дела с внедрением ERP\CRM в твоей компании пойдут ну очень хорошо.

Уровень третий. Самый сложный.

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

И так, ты выбрал какую-то индустриальную модель. В ней - чье-то видение, чьи-то процессы, чьи-то приказы. А вот исполнять эти приказы - тебе. И именно в этом - самая сложная проблема.
Внедрить ERP - значит принять что ты будешь исполнять чужие приказы. И твои подчиненные будут исполнять чужие приказы.
Чужие приказы можно исполнять через веру - веру в лидера или в начальника, или в гуру или в консультанта или в предшественника. Но это не твой путь. Ты потому и стал собственником - а) чтобы не подчиняться чужим приказам б) чтобы ничего не принимать на веру.

Нужны другие пути. О них мы и поговорим в следующих статьях.

Подробнее..

Категории: Управление проектами , Crm-системы , Erp-системы , Crm , Управление продажами , Erp , Ecm/сэд , Processes

ERP для собственников. Часть 2. Технологичное

16.03.2021 12:09:05 |

Автор: admin

Вступление

Привет. Меня зовут Олег и я занимаюсь внедрениями систем управления предприятиями более четверти века.

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

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

ERP для собственников. Часть 1. Философское.

Проектное vs Операционное

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

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

Следствия

А теперь послушай меня внимательно - ибо здесь один из ключей к пониманию роста и устойчивости твоего бизнеса.

Операционное от процессного отличается только зрелостью команды.

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

Изменение зрелости команды для превращения проектного в операционное - твоя, собственника, основная задача.

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

Технологичное

Продолжу вводить определения.

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

Объясню.
Айвазовский за 60 лет своего творчества написал более 6000 картин. Без сомнений, его деятельность была операционной - он был способен выдавать оговоренные заказчиком результаты в срок, с оговоренными качеством и стоимостью. Но его деятельность не была технологичной - она критично зависела от самого Айвазовского, он был критичным ресурсом. С исчезновением художника производство картин остановилось.
А вот современный Айвазовскому Фаберже сделал производство получивших его имя яиц технологичным: он него лично (как и ни от одного другого мастера в его холдинге) конечный продукт не зависел вообще. Я не зря привел столетней давности примеры Айвазовского и Фаберже - этим я хотел акцентировать внимание на том что технологичной основная цепочка создания ценности может быть вообще без компьютеров и программ.

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

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

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

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

И тут я подвожу тебя к моменту истины.

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

Отсюда три вывода.

Вывод 1

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

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

Вывод 2

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

Если хоть у кого-то из топов хоть раз проскользнет выражение не нравится - свободен, другого найду - то получатель такого сообщения (или получатели, если это было сказано при свидетелях) тут же начнет делами доказывать свою незаменимость. То есть - начнет воевать с EPR. То есть - будут хоронить первичную идею.

Ты думаешь - корпоративные кодексы и вежливость зря придумали? А вот нифига, они придуманы потому что проще демонстративно заменить менеджера (например) третьего уровня чем ставить под угрозу технологичность процессов управления на четвертом уровне.
Если ты думаешь что я сказки рассказываю - нифига. Я внедрил ERP для голландских, австрийских, швейцарских, словенских компаний и продолжаю с ними работать - и здесь это осознанная истина.

Вывод 3

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

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

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

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

Читатель, если у тебя нет своего бизнеса - кинь этот линк своему работодателю. Он оценит.

Подробнее..

Категории: Управление проектами , Crm-системы , Erp-системы , Crm , Управление продажами , Erp , Ecm/сэд , Processes

Ваши АСУ ни разу ни У

12.11.2020 18:15:59 |

Автор: admin

АСУ автоматизированные системы управления.

АС понятно. Это ваши любимые CRMки, 1Ски, Склад, Касса, Бухгалтерия, Зарплата и Кадры и прочие программы.

А что такое управление?

Если совсем примитивно, то

Управление это процесс перемещения некого Объекта из точки А в точку Б. Где А текущее положение, Б целевая точка (Цель).

Очевидно, что переход между одинаковыми точками при разных условиях (контекстах) осуществляется разными методами. Например: перемещение по городу в дождь, снег, летом, зимой, в пробки это совсем разные способы и режимы управления автомобилем или даже вертолетом. А может метро?

Как вы уже понимаете, точка может иметь многомерную координату (или вектор состояния) в неком пространстве (необязательно 3D).

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

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

А теперь давайте подумаем

Какие из ваших программ попадают под ранее указанное определение управления?

Открою вам страшную тайну!

На наших предприятиях, в основном, обычные базы данных или, как мы их называем с коллегами набивалки.

Да. Есть набор алгоритмов, которые уменьшают количество ошибок ввода данных, чтобы не было искажения в информации, но не более того.

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

А где, собственно, тут управление? Где определение текущего состояния?
Есть отчет о прибылях и убытках, дебиторка, готовые изделия, воронка продаж.
Допустим. Насколько они отражают действительность? Где постановка целей?
Хм. Гм. Эээ.
Где функции/алгоритмы достижения целей (управления)? Где функции формирования этих алгоритмов?

Мертвая тишина в зале. Катарсис. Занавес.

Ок. Поддамся. Управление в идеале это максимально точное прогнозирование ситуации.

Каким образом можно делать ЭТО?

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

Так же существует множество эмпирических правил, которые изучают в ВУЗах и накапливаются с жизненным опытом. Многие правила можно четко выразить через ЕСЛИ-ТО. Это позволяет проводить математическое моделирование или Прогнозирование.

На производстве (часто) бывают системы планирования и диспетчеризации их уже можно отнести к управлению, так как

Планирование = Прогнозирование

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

А если говорить о мощностях на сегодняшний день за 1000$ можно купить компьютер, который производит триллион (10^12) операций в секунду. Уже не мало. (Это я говорю о GPU например об игровых). По мне, так вполне доступно даже рядовым ИП.

Этой вычислительной мощности достаточно, чтобы в течение минуты расчитать бухгалтерский баланс, налоги, зарплату, прибыль магазина с номенклатурой 10 50 тысяч единиц. А если это сделать с разными параметрами, то мы получаем экономическое моделирование прогноз.

За сутки 24 * 60 = 1440 вариантов будущего компании

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

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

Где в ваших АСу механизмы воздействия? (Прямая связь)

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

Насколько корректно и удобно ваша система отображает необходимую информацию? Желательно адекватную текущему контексту. Ввод информации удобен?

Насколько быстро и качественно ваша АСу перестраивается под ситуацию, изменения законодательства, форс-мажорные обстоятельства, мировую политику, смену/добавление оборудования? Насколько устойчива ваша система к подобным воздействиям? Насколько она управляема?

Обычно кибернетическую систему перестраивают инженеры-программисты и(или) закладывают на будущее (прогнозируют) возможные варианты алгоритмов.

Кибер-система, которая перестраивается сама (желательно быстрее/эффективнее программистов) называется ИИ.

Что она перестраивает?

Правильно. Алгоритмы, функции управления для достижения целей. Да и сами цели она ставит самостоятельно.

Как она это делает сама? Это уже разговор о том, что такое Интеллект. И, как вы уже поняли,

Управление процесс интеллектуальный

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

Насколько быстро работает ваша АСу? Какова ее Мощность?

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

Событие Прогноз Реакция Цель Подстройка Алгоритм

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

Эффективное управление это переход от рефлексии к прогнозированию

А вашим АСу слабо?

Подробнее..

Категории: Научно-популярное , Анализ и проектирование систем , Искусственный интеллект , Erp-системы , Асу , Erp , Асутп , Управление

Цифровизация производства в РФ. Не отрываясь от реальности

01.12.2020 10:20:26 |

Автор: admin

Питеркин Сергей, Райтстеп. 2020г

Тезисы

1.4я промышленная революция (Industry 4.0, цифровизация) подразумевает полную интеграцию:

традиционных информационных потоков планирования и управления производства, поставок
и средств исполнения: люди, машины и механизмы, оборудование

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

2.При этом кибер-физические системы Industry 4.0 (далее I4.0) основываются на фундаменте базовых процессов: проектирования (изделий), планирования/управления производством и поставками, уже используемых сейчас предприятиями (Industry 3.0 I3.0.).

3.Очевидно, что без построения "фундамента" в виде I3.0, попытки внедрить элементыI 4.0 не приведут к принципиальным улучшениям. Т.к. будут работать на локальные области оптимизации, без синхронизации как со всей горизонталью цепочки поставок, так и с вертикалью этапов ЖЦ создания продукции для потребителя. Под ЖЦ имеется в виду жизненный цикл: разработка -> испытания -> ввод в серию (не обязательно переход к массовому производству, но обязательно - вывод из стадии опытного) -> планирование, закупка, производство -> передача потребителю.

4.Таким образом, цифровизация традиционных российских предприятий должна обязательно и первостепенно включать построение фундамента (I3.0), с цифровизацией (внедрением элементов I3.5 и I4.0) только там, где необходимо и оправдано (в узких местах процесса создания продукции для потребителя). Так, как это делали западные, а теперь уже и восточные, более эффективные производства. В любом другом случае все это будет выглядеть (и выглядит, судя по регулярно рапортуемым успехам наших цифровизирующихся заводов. Причем, как правило, не на деньги частных собственников) как попытка...взобраться на 4й этаж со 2го по приставной лестнице, у которой нет перекладин вначале.

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

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

ЭТАП 1: переход на уровень базовой автоматизации управления (Industry 3.0, уровень развития - 1990е гг)

Исходное состояние и задачи

Основная задача, стоящая на данном уровне развития, - переход на следующий уровень, I3.0. С уровня 2.0. (80е гг), на котором, если посмотреть реальности в глаза, находится большинство наших производств, разных размеров и форм собственности.

Для перехода необходимо решение следующих задач:

1) сокращение непроизводительных трудозатрат на процессы управления. Таких, как (пример):

затраты (время, человеко-часы работы) на ручное формирование/корректировка технологических составов изделий (ТСИ),
затраты на ручное (полуручное) планирование, и постоянные исправления ошибок/корректировки ручных планов,
затраты на ручной и/или неточный, неоперативный учет запасов, выполняемых и выполненных работ/поставок,
управление производством и заказами через планерки, совещания, селекторы, силой мозга одного эксперта и пр.

2) синхронизация планов и исполнения всей производственно-логистической цепочки. С постановкой правильных процессов и их автоматизацией. С "разрушением стен между подразделениями и переделами цепочки поставки. "Стен", которые тормозят и искажают информационные и материальные потоки, проходящие сквозь предприятие.

Что и как улучшаем

Разработка продукции переход на электронный состав

Кратко, это переход к формализованным и автоматизированным процессам ведения электронного состава изделий. Для целей не только и не столько конструкторов и технологов, сколько для использования его (эл.состава) в системе планирования.

Уровень 1 автоматизация внутренней и внешней цепочки поставок. До площадки/цеха/участка

ЦЕЛЬ: сделать синхронизированное производство, по всей внутренней (завода) и внешней (поставщики и кооператоры) цепочке поставки [1]. Поставив процессы и автоматизировав их с ИТ-системой класса "СПМ - Система Планирования и Мониторинга производства и поставок" (далее СПМ).

Планирование (алгоритм планирования - "планировщик системы") работает на основании следующих групп данных. Не имея которые про планирование можно забыть

1. Что производим: состав изделия.

Что из чего сделано (что во что входит) количество.
Как делаем: маршрут и технология обработки/сборки (что, где и как делаем).
Временные характеристики (время производства, нормы).

Информация должна автоматически передаваться ("проецироваться") в СПМ из PDM, где ведутся электронные составы. Или вводиться непосредственно в СПМ.

2. Cредства производства.

Люди, их квалификация и доступность (график работы, эффективность).
Оборудование/обрабатывающие центры (ОЦ), их характеристики и доступность (график работы, эффективность).

Информация вводится в СПМ.

3. Что для этого есть: материалы, ПКИ, ДСЕ, инструмент, оснастка, приспособления.

Где, в каком месте цепочки (площадки, склады, цеха, участки, кладовые).
В каком количестве.
В каком статусе.

Информация вводится в СПМ.

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

Что и когда надо запустить/закупить, что нужно выпустить.
Какие ресурсы необходимы, в т.ч. для закупки.
Управление запуском: формирование Заказов поставщикам/кооператорам, формирование и запуск Производственных заданий (Производственных Партий), объектов управления всем циклом производства ДСЕ/сборок (это не сменно-суточные задания!).

Важно! Необходимо сразу проектировать систему (алгоритмы), помогающую и заставляющую работать Точно Вовремя, Точно в количестве. Так потом гораздо проще будет поместить эти базовые процессы в кибер-физическую систему I4.0. При этом, неточности указанной информации, связанные с неточностью данных и/или неоперативностью/ошибочностью ручного ввода, что неизбежно на данном, начальном, уровне развития "гасить" буферами: времени (растянутые циклы), запасов (завышенные уровни покупных, НзП). С последующим их постепенным сокращением.

Уровень 2 локальное (детализированное) планирование и автоматизация исполнения.

ЦЕЛЬ: реализовать продвинутые функции управления исполнением[2] синхронизированных позаказных планов, сделанных СПМ и переданных исполнителям.

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

2. После постановки и уверенной работы с 1м уровнем планирования автоматизация 2го уровня планирования.

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

3. Автоматизация учетных функций: быстрый и простой ввод в систему (цеховые киоски, планшеты, штрих-кодирование) информации о факте: что и когда сделано/скомплектовано, перемещено.

Что должны получить

Как результат данного этапа: автоматизированная базовая производственная система, на уровне Industry 3.0. (см. рис. ниже)

СПМ, в смысле поставленных и автоматизированных процессов, на 1м (среднем) и 2м (детальном) уровнях планирования и мониторинга здесь является "становым хребтом" дальнейшей автоматизации и цифровизации. Без которого все остальные цифровые инициативы останутся попытками локальной оптимизации, НЕ повышающими эффективность всей производственной системы.

Проекты преобразований

Реализация данного этапа может быть осуществлена через следующие (лучше отдельные), последовательные Проекты.

1. Постановка СПМ (Системы Планирования и Мониторинга производства и снабжения[3]) для обеспечения синхронизированного планирования и исполнения планов по всей, внутренней и внешней цепочке поставок. Для следующих областей управления.

ведение Позаказного (производственного) Состава Изделий,
планирование производства и снабжения, до уровня цехо/участко-заходов (переделы /этапы производства/группы операций),
управление поставками и кооперацией,
управление складами (запасами) снабжения и производства,
управление производством: запуск, учет хода производства (запуск/выпуск по участко/цехо-заходам), межучастковые/цеховые передачи,
мониторинг.

2. Постановка процессов продвинутого управления исполнением (СПМ-MES):

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

3. Автоматизация указанных выше учетных действий с использованием:

штрихкодирования,
цеховых терминалов.

ЭТАП 2. Следующий шаг к цифровизации Industry 3.0+

Основные задачи здесь следующие.

1) Сокращение непроизводительных трудозатрат процессов управления и сокращение некоторых традиционных ролей управления, как класса. Например, роли (и отделы): ПДО, ПДБ, ОГТ и/или цеховых технологов и нормировщиков.

2) Сокращение буферов страховых запасов и времени.

3) Сокращение себестоимости продукции.

4) Создание базы (входа) для кибер-физической системы I4.0.

Подчеркнутым курсивом ниже отмечены процессы, которые уже с полным правом и без кавычек можно назвать (началом) цифровой трансформацией.

Шаг 1. Повышение точности планирования - базовые данные

Цель: повысить точность планирования за счет повышения точности входящей информации, используемой при планировании.

1. Что производим: состав изделия.

Что из чего сделано (что во что входит) количество.
Как делаем: маршрут и технология обработки/сборки (что, где и как делаем).
Временные характеристики (время производства, нормы).

Информация автоматически поступает в СПМ из PLM. Используются ИТ-системы управления изделиями и системы имитационного моделирования.

1. В PLM проводится разработка составов изделий (СИ), с учетом корректного описания технологических процессов (вплоть до обрабатывающих программ для станков с ЧПУ) и проверки технологичности производства.

2.Проверка СИ на возможность производства, определение стартовых времен, микро-логистика, выполняется в системе Имитационного моделирования.

2. Средства производства.

Люди, их квалификация и доступность (график работы, эффективность).

Информация доступна для СПМ в автоматическом режиме из следующих систем.

1. Из ИТ-системы управления людскими ресурсами (плановое время работы).

2. Из электронной проходной (в развитии из продвинутой системы распознавания лиц).

3. Информация по эффективности работы каждого сотрудника вычисляется на основе сбора план/факт информации по исполнению (из СПМ см. ниже).

Оборудование/обрабатывающие центры (ОЦ): их характеристики и доступность (график работы, эффективность).

Автоматический цифровой сбор данных по загрузке и доступности оборудования.

1. Информация по прогнозу планового времени работы оборудования: из системы ТОиР, системы управления обслуживанием (Predictive Maintenance), системы Цифровой двойник.

2. По информации из ИТ-системы автоматизированного сбора данных о работе оборудования - MDC (Machine Data Collection).

3. Плюс - план/факт информация по исполнению (из СПМ см. ниже).

3. Что для этого есть: материалы, ПКИ, ДСЕ, инструмент.

Где.
В каком количестве.
В каком статусе.

Система автоматического съема информации через RFID. Автоматический ввод в СПМ через считывание сигналов RFID с объектов учета и/или сопровождающих их документов. И/или, где необходимо и оправдано, автоматизированных складов.

Шаг 2. Повышение уровня детализации исполнения

По результатам планирования в СПМ.

1. Автоматическое создание рабочих заданий и передача исполнителям.

a.На личные мобильные устройства и/или цеховые/участковые экраны.

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

c.Задания на комплектацию производства/перемещения между складами/цехами/участками:

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

d.На оборудование.

По результатам исполнения.

2. Автоматизированный съем факта исполнения рабочих заданий.

a. С оборудования по завершении обработки/этапов обработки.

b. С автоматизированных складов/тележек, о перемещении между складами/участками/цехами.

c. С видеокамер о начале/завершении процесса производства/сборки (технология пока под вопросом)

Комментарий

На уровне интеграции системы продвинутого управления исполнением (MES), могут быть также цифровизированы следующие процессы (если они узкие места производства!)

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

Шаг 3. Повышение точности планирования план/факт

Повышение точности планирования на счет Автокалибровки[4] систем планирования и исполнения.

1. Используем план/факт информацию из п2. Шага 2.

2. Используем информацию по фактической работе/OEE оборудования.

3. Корректируем плановые данные (в СИ, времена производства, перемещения и пр.).

Собираем и предварительно очищаем фактические данные.
Алгоритмически (в т.ч. с алгоритмами работы c Big Data и AI) рассчитываем новые плановые данные.
Алгоритмически (массово, выборочно, условно) замещаем.

4. Далее - очередной автоматический цикл планирования/исполнения/корректировки данных.

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

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

Проекты преобразования

Реализация данного шага к I4.0 может быть осуществлена через следующие проекты.

Реализация процессов PLM, включая систему имитационного моделирования.

моделирование производства и логистики завода,
моделирование производства изделий, с минимизацией времени/себестоимости.

2. Цифровой двойник производства. Возможно пересечение с п.1.

3. ТОиР:

учет оборудования, съем факта работы/простоев (с использованием данных MDC),
расчет будущей эффективности, предсказание поломок, расчет графика ТОиР.

4. HCM (Human Capital Management) - система управления кадрами:

управление кадрами (продвинутые функции),
сбор информации по выработке, расчет эффективности.

5.MDC (Machine Data Collection):

автоматизированный сбор / мониторинг информации о работе оборудования,
расчет ОЕЕ с разными аналитиками.

6. RFID: автоматический учет движений ТМЦ и любых других материальных объектов с использованием маячков.

7. Автокалибровка: расчет плановых временных параметров изделий на основании план/факт отклонений.

Важно! Указанные выше проекты имеют смысл ТОЛЬКО при наличии централизованной общей шины управления (не столько программной, сколько логической) СПМ на уровнях Синхронизированное планирование и Продвинутое Исполнение. К которой присоединяются указанные выше локальные системы. И, за счет этого, начинающие работать не только для достижения локальных оптимумов, но и для принципиального точности и скорости обработки информации, и доведения его до уровня реальной КФС.

Этап 3. Industry 4.0 - цифровой завод

Задача:

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

2) - практически полное устранение прослойки людей в процессах управления (ПДО, ПДБ, кладовщики и т.п.) через замыкание информационных и связанных с ними материальных потоков, на единицах оборудования.

Но при этом:

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

Указанные выше задачи фактически описывают задачи для перехода на уровень I4.0 к функционировани. кибер-физической системы цифрового завода. И решаются они через внедрение соответствующих инструментов, по сценариям и направлениям 1го и 2го этапа, описанным выше. Кратко, это следующие действия (далее будет применятся общеизвестные для I4.0 англоязычные термины или сокращения, без расшифровки).

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

Моделирование новых процессов через средства Имитационного моделирования, Цифровые двойники, видео-съемки с анализом действий персонала с ее последующей оптимизацией.
Роботизация/оптимизация процессов производства через: RPA, IoT, 3D печать.
Оптимизация процессов производства (сборки) с участием людей, через: Cobotы, AR, VR
Оптимизация микро-логистических процессов через: RFID, автоматизированные склады/роботизированные тележки/дроны.

2.Повышение эффективности работы оборудования через: Predictive Maintenance, IoT.

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

4.Повышение эффективности внешней цепочки поставок через использование: Blockchain, SCM Control Tower.

Заключение

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

Но, торопиться надо медленно. Роботизированная тележка, подвозящая комплектующие к роботизированному участку сборки, где немногочисленные операторы, в очках виртуальной реальности, собирают с первого предъявления все, как надо это, безусловно, выглядит круто! Но задайтесь вопросом: кто, как и когда будет на нее грузить то, что нужно именно в этот момент времени? И кто, как и когда определит этот момент? Ежемесячное и неточное планирование, на основании ТСИ, ведущегося в Excel, и запасы из бухгалтерского ПО, - точно не тот "фундамент", на который можно "поставить роботов" Индустрия 4.0 стоит на процессах Индустрии 3.0, не 2. Поэтому - только последовательное эволюционное и итерационное развитие!

Расшифровки по сноскам в тексте

[1] Используются система/алгоритмы и процессы среднего (RCCP-MRP-CRP[1] - по общепринятой классической классификации MRP-II) уровня планирования и исполнения.

[2] Часто и неправильно это называют MES. Хотя MES маркетинговое определение определенного класса ИТ-систем. Правильнее определять этот уровень как SFC (Shop Floor Control - цеховое управление), по общепринятой классической классификации MRP-II. Это уровень, соответствующий нижнему, детальному уровню планирования и исполнения. Тем не менее, для ясности в рамках данной статьи оставим его как MES.

[3] В данном контексте, СПМ можно назвать Производственной ERP.

[4] "Автокалибровка систем планирования и исполнения". Хотя это - всего-лишь реализации классического алгоритма управления с обратной связью, технология автоматического и быстрого применения его для производственных систем - пока на уровне НИР. Но перспективы ее, и прежде всего, для наших производств огромны!

Подробнее..

Категории: Анализ и проектирование систем , Erp-системы , Erp , Industry , Digital factory

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

19.02.2021 16:11:01 |

Автор: admin

Есть компания N, которая занимается продажей спортивных товаров и входит в топ-10 на рыке с неплохими оборотами. Конкуренция растет, и компания понимает, что пора расширяться за счет добавления новых категорий и брендов.

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

Не используйте для разработки ERP-систему

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

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

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

То есть, грубо говоря, система управления заказами (OMS) сама маршрутизирует потоки (подборы товаров, идентификация позиций товаров по конкретным поставщикам и т.д.). Должны быть автоматизированы все процессы системы: управление каталогом, программы лояльности, витрина и т.д.

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

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

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

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

И в конечном итоге компания жалуется на результат, потому что ожидания не совпадают с реальностью. Ждали резкого взлета в продажах, а получили не более 10% от общего оборота. Все это довольно грустно. Но выход есть.

Сделайте выбор в пользу микросервисного подхода

Как раз его используют крупные торговые площадки.

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

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

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

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

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

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

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

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

Как начать работу с проектом по запуску маркетплейса

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

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

формирование ключевых систем автоматизации маркетплейса в формате To be;
построение общей архитектуры компонентов маркетплейса с определением потока данных и нагруженности систем;
описание ключевых требований к платформе и функционалу, который нужен для автоматизации маркетплейса;
формирование ключевых требований к инфраструктуре.

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

Подробнее..

Категории: Микросервисы , Разработка , Развитие стартапа , Бизнес , Erp , 1c , Микросервисная архитектура , 1с , Маркетплейс , Консалтинг , Блог компании rdv , Erp-система , Oms , Дистрибуция

	Русский
	English