15. Производство.
15.1. Формирование структуры изделия.
15.2. Плановая и фактическая себестоимость изделий.
15.3. Формирование сводной потребности в производимых изделиях.
15.4. Формирование и диспетчеризация сменных заданий.
15.5. Маршрут изделия.
15.6. Определение и формирование потребностей в материалах.
15.7. Производство «под заказ».
15.8. Серийное производство.
А теперь возьмите этот перечень, добавьте в него то, чего, по вашему мнению, недостает. Имея на руках такой список, можно смело приступать к тестированию ERP-системы – в ходе знакомства делайте пометки по каждому требованию.
Разработчики давно поняли, что клиентам нужны именно ERP-системы. И поступают очень просто: называют ERP-системами свои продукты. Хотя в действительности больше половины продуктов на рынке не способны не только планировать, но даже учитывать. Сегодня любой программный продукт, умеющий печатать счета-фактуры, называют ERP- системой. Просто потому, что «клиенты хотят ERP».
В погоне за клиентом разработчики готовы называть ERP-системой любой продукт.
Как результат – термин девальвировался, и теперь уже непонятно, что есть ERP, а что не ERP. Поэтому самое надежное при выборе решения – отбросить терминологию и оперировать потребительскими характеристиками продукта: «Система должна уметь это, это и вот это. Покажите, пожалуйста. Желательно на конкретных примерах».
В противном случае могут быть сюрпризы. Однажды мне довелось присутствовать на презентации некой ERP-системы, частью которой был модуль MRP (Material Requirement Planning, планирование потребности в материалах). Это, пожалуй, самая сложная часть в планировании, и наличие такого модуля – серьезное преимущество. Но … На практике все свелось к тому, что система автоматически формировала заказ, если остаток того или иного ресурса оказывается ниже «страхового запаса». Ни сроки поставок, ни тренды продаж, ни сезонность, ни текущие поставки не учитывались. И вот это доблестные продавцы системы (западные, замечу) назвали MRP. Мало того, страховой запас нужно было указывать для каждой товарной позиции отдельно. Легко представить, как это будет работать при наличии тысяч эдак тридцати учетных позиций.
Современное планирование запасов просто обязано учитывать плановые сроки поставок по поставщикам и желательно по этапам поставки, чтобы при планировании учитывать, что если груз только заказан, значит, он будет через N дней, а если есть товарная накладная – значит, через X дней. Инициировать пополнение склада материалов нужно не в момент, когда запас уже вошел в «красную зону», опустившись ниже границы страховой части, а так, чтобы он оставался стабильным. Страховые запасы и плановые сроки поставок желательно планировать по группам однотипных товаров. Если поставщик доставляет любые ноутбуки за 60 дней – зачем указывать этот срок для каждой модели отдельно, достаточно задать его для товарной группы. Иными словами, система планирования должна быть применима практически, в противном случае потеря времени и сил гарантирована. Не говоря уже про деньги.
Большинство ERP-систем сегодня строится по принципу «чем дороже, тем лучше». Почти каждый проект уникален и эксклюзивен, делается под заказ. Так долго продолжаться не может. Единственный выход состоит в радикальном упрощении ERP решений, они должны стать проще в освоении и запуске. Пора отходить от традиционной концепции, когда ERP считается эксклюзивом, когда на каждом предприятии целая команда «внедренцев» делает каждый раз одно и то же, а клиенты платят деньги не столько за развитую функциональность, сколько за совершенно элементарные возможности.
Нередко со стороны консультантов в сторону заказчика звучат фразы: «Вы скажите, как вам надо, и мы сделаем». Да консультантов для того и приглашают, чтобы они подсказали, как делать нельзя, и что-то подправили в бизнесе. Но если консультант сам только что из института, откуда ему знать, как все сделать правильно?
Полноценно и с хорошим качеством внедрить ERP – задача, сопоставимая с созданием самого бизнеса. Но если ее решить, то бизнес станет управляемым, как хороший автомобиль.
Мобильная торговля: склад в кармане
Решения класса АСМТ (автоматизированная система мобильной торговли) – один из наиболее популярных способов оптимизации деятельности торговых компаний.
Как и всегда, в рубрике «Типовое решение» мы подготовили модельное ТЗ, попросив разработчиков сделать небольшой анализ, описывающий способ решения модельной задачи средствами их систем. В России сегодня довольно много компаний, создающих АСМТ; на наше предложение откликнулись фирмы «Гильдия разработчиков» (система «НАПОЛЕОН»), «Паритет» («Моби-С») и «Нео Матрикс» (с одноименным продуктом).
Участник уточнил базовую задачу так: модельная компания, занимающаяся оптово-розничными поставками товаров косметики, гигиены, бытовой химии, имеет четыре отдела, специализирующихся на дистрибуции нескольких коллекций национальных и импортных марок, а также два отдела, занятых реализацией бытовой химии. Общая товарная номенклатура насчитывает 50 тыс. наименований.
В компании имеется 50 мобильных сотрудников (торговых агентов) и шесть руководителей (супервайзеров), работу которых предстоит автоматизировать. Сорок агентов (торговых представителей из разных отделов) работают по схеме Pre-selling (сбор предварительных заказов «в полях») с возможностью сбора мерчендайзинговой информации. Каждый агент работает со «своим» перечнем товаров (максимум 20 тыс. наименований). Десять торговых представителей из отделов, занимающихся дистрибуцией, работают по схеме Van-selling (реализация товаров с мобильных складов, торговля «с колес») с возможностью оформления предварительного заказа. Их БД отражает реальное наличие товара на борту автомобиля и не превышает 300 наименований. В случае необходимости они могут принять предварительный заказ на маршруте.
Организация решения. При торговле используется следующая схема ценообразования: агент работает с базовыми «клиентскими» ценами, по необходимости предоставляя скидку в указанных пределах. Супервайзеры контролируют работу агентов (количество посещений, объем реализации, сбор информации), а также оформляют отчеты для руководителей территориальных подразделений (заполняя в Microsoft Excel типовую форму, утвержденную центральным офисом).
Для решения базового набора задач потребуется два программных продукта: «НАПОЛЕОН. Создание заказов (Pre-selling, мерчендайзинг)» и «НАПОЛЕОН. Выездная торговля (Van-selling)». Для реализации функций контроля работы торговых представителей и автоматизации процесса предоставления отчетности можно использовать модуль Microsoft Excel, данные предоставляет серверная часть комплекса «НАПОЛЕОН».
Чем обосновано такое решение? Во-первых, при переходе на другую КИС потребуется замена только модуля обмена данными (в «1С» готовые типовые модули обмена имеются в наличии). Простая схема обмена позволяет быстро разработать соответствующий модуль силами сотрудников ИТ-отдела компании (если потребуется). Во-вторых, ускоряется и удешевляется процесс внедрения. В-третьих, упрощается унификация в соответствии с принятыми компанией стандартами в области ПО.
Порядок реализации проекта. На первом этапе базовая версия системы (в которой возможно выполнение поставленных задач) инсталлируется на три КПК, проводится обучение пользователей и оператора, а также пилотный запуск (3–5 рабочих дней). На втором этапе производятся доработка системы и подготовка финальной версии с учетом пожеланий (1–2 рабочие недели). На третьем этапе выполняется тиражирование решения (установка финальной версии на все КПК и обучение персонала). В частности, доработка системы в соответствии с условиями модельного ТЗ
