9. Управление логистикой: невозможно.
Более подробно эта история изложена на сайте http://www.avasystems.ru/press/prezent_erp.
Как можно пользоваться таким продуктом? Где эти пресловутые «наилучшие решения», Best Practice? Я не верю, что такая система может работать и на Западе, а в России приобретение подобного продукта однозначно приведет к потере времени и денег. И вот тут стоит отметить, что внедрять ERP-систему желательно с первого раза. Второй попытки внедрить что-то подобное компания может и не перенести, если сотрудники потеряют веру в непогрешимость и эффективность топ-менеджеров, восприняв очередной проект внедрения очередной ERP как очередную забаву руководства.
Примерный список требований к ERP-системеERP-система, как и любой другой продукт, имеет свои потребительские характеристики – и эти характеристики надо четко представлять. Не забывайте, что требования необходимо закладывать с учетом роста компании: то, что кажется избыточным сегодня, может оказаться жизненно важным впоследствии. Приведенный пример – безусловно, не истина в последней инстанции, но он дает представление об основных вопросах, которые нужно рассмотреть при выборе ERP-системы.
1. Управление бизнес-процессами предприятия в рамках нескольких родственных компаний.
1.1. Привязка всех документов и процессов к «своим» компаниям.
1.2. Нумерация счетов-фактур, приказов и других документов отдельно по каждой «нашей» компании.
1.3. Упрощенная система налогообложения.
1.4. Отчетность в разрезе компании.
2. Работа с клиентами.
2.1. Организация схемы «клиент – несколько юридических лиц». Контроль взаиморасчетов в разрезе клиента в целом.
2.2. ABC– и XYZ-категоризация клиентов.
2.3. Настройка скидок в зависимости от категории клиента.
2.4. Просмотр всех счетов, отгрузок, платежей, накладных и других документов по клиенту непосредственно на его карточке.
2.5. Закрепление менеджера за клиентом. Регулирование доступа менеджеров к своим клиентам, счетам и другим документам.
2.6. Формирование прайс-листа.
2.7. Учет ребейтов.
2.8. Установка и контроль лимита дебиторской задолженности для клиента.
2.9. Подарки клиентам.
2.10. Организация распродаж, акций.
2.11. Отгрузка товара на реализацию.
2.12. Настройка управленческих выборок по клиентам.
3. Управление поставками.
3.1. Фиксирование плановых сроков поставки по каждому поставщику и каждой группе товаров.
3.2. Организация цепочек поставок и их сквозной контроль.
3.3. Учет затрат на поставку и включение их в себестоимость.
3.4. Поставки «под заказ».
3.5. Учет ГТД.
3.6. Планирование платежей поставщикам.
3.7. Учет кредитов от поставщика.
3.8. Планирование потребностей в закупках.
3.9. Учет входящих документов.
3.10. Выбор лучшего поставщика.
3.11. Резервирование товаров в поставках.
3.12. Оптимизация сроков поставки.
4. Договорная деятельность.
4.1. Формирование и ведение базы договоров.
4.2. Процедура согласований и утверждений договоров.
4.3. Формирование текстов договоров на базе шаблонов.
4.4. Хранение отсканированного договора и других файлов в базе данных.
4.5. Контроль сроков окончания договоров.
4.6. Типизация договоров.
4.7. Маршруты согласований договоров.
4.8. Уровни финансовых полномочий сотрудников на подписание договоров.
5. Классификатор товаров.
5.1. Возможность организации древовидной структуры. Перенос позиций из ветки в ветку.
5.2. Просмотр текущей скользящей себестоимости товара и истории ее изменения.
5.3. Детализация логистических срезов.
5.4. Ограничение доступа пользователей на просмотр себестоимости и другой информации по товару.
5.5. Настройка аналогов, аксессуаров, совместимостей и других взаимосвязей товарных позиций.
5.6. Хранение в БД изображения товара, инструкций и др.
5.7. Просмотр истории движения товара по складу и истории остатка.
5.8. Поиск документов по товару.
6. Редактор отчетов.
6.1. Возможность настройки и коррекции шаблонов документов.
6.2. Выгрузка любого документа в такие форматы, как PDF, .xls, .doc, Open Office и др.
7. Ценообразование.
7.1. Автоматический расчет средневзвешенной себестоимости при приходе товара на склад.
7.2. Ожидаемая себестоимость.
7.3. Ручная коррекция себестоимости.
7.4. Возможность настройки различных зависимостей отпускной цены от себестоимости для разных групп товаров.
7.5. Настройка полномочий по минимально возможным ценам (или максимальным скидкам) для разных пользователей.
7.6. Настройка рекомендуемых скидок по клиентам, категориям клиентов, товарам, группам товаров, срокам, скидкам от количества и другим параметрам.
8. Сквозной учет товара.
8.1. Учет партий, серий, серийных номеров.
8.2. История партии, серийного номера.
9. Первичные документы.
9.1. Правильное отражение ГТД в счетах-фактурах при разных партиях товара.
9.2. Формирование таких документов, как счет, счет-фактура, акт выполненных работ, торг-12, доверенность, акт сверки, ТТН, договор, приказы по кадрам и др.
9.3. Учет возврата первичных документов.
10. Склад.
10.1. Учет серийных номеров изделий, история серийного номера.
10.2. Внесение в базу серийных номеров через сканер штрихкода (желательно).
10.3. Полноценное резервирование товара на складе.
10.4. Возможность частичной отгрузки товара.
10.5. Подбор товара на складе.
10.6. Распоряжения на отгрузку и на прием товара.
10.7. Учет товара на полках.
10.8. Перемещение товара между складами.
11. Система управления доступом пользователей.
11.1. Настройка функциональных ролей пользователей.
11.2. Привязка ролей к штатному расписанию.
11.3. Ограничение доступа пользователей к процессам и объектам системы.
11.4. Возможность ограничения доступа пользователей к документам в ходе процесса.
11.5. Ограничение кладовщиков доступом только к «своему» складу.
11.6. Ограничение кассиров доступом только к «своей» кассе.
12. Управление кадрами.
12.1. Настройка структуры подразделений компании.
12.2. Настройка штатного расписания компании.
12.3. Прием, увольнение сотрудников.
12.4. Формирование и печать приказов и трудовых договоров.
12.5. Расчет зарплаты.
12.6. Премии/штрафы.
13. Управление затратами.
13.1. Структура статей затрат.
13.2. Маршруты согласований заявок на затраты.
13.3. Уровни финансовых полномочий сотрудников на подписание заявок.
13.4. Начисление затрат.
13.5. Учет основных средств и закрепление их за сотрудниками.
14. Финансы.
14.1. Стандартные отчеты о прибылях и убытках, о движении денежных средств, баланс, дебиторы, кредиторы.
14.2. Отдельно показатели по задолженности поставщиков перед нами, нас перед ними и итоговой. То же самое с клиентами.
14.3. Анализ значений показателей отчетности в разрезе сделок, клиентов, менеджеров, товаров, товарных групп, «наших» фирм.
14.4. История показателей за прошедшие периоды, например история выручки за год по месяцам.
14.5. Конвертация валюты.
14.6. Многовалютность учета и финансовой отчетности.
14.7. Банковские кредиты и овердрафты.
14.8. Оформление займов у «своих» фирм.
14.9. Неопознанные платежи.
14.10. Налоговые компенсации.
14.11. Внереализационные доходы.
14.12. Открытие и закрытие «своих» компаний и расчетных счетов.
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 дней – зачем указывать этот срок для каждой модели отдельно, достаточно задать его для товарной группы. Иными словами, система планирования должна быть применима практически, в противном случае потеря времени и сил гарантирована. Не говоря уже про деньги.
Haute Couture, или Ближе к народу?Большинство 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 рабочие недели). На третьем этапе выполняется тиражирование решения (установка финальной версии на все КПК и обучение персонала). В частности, доработка системы в соответствии с условиями модельного ТЗ потребовала 8 ч (стоимость – около 4000 руб.[1]).
Дополнительные возможности. Помимо процесса формирования заказа программа в базовой версии позволяет отображать контактную информацию (например, звонок по заданному телефону из адресной книги КПК/коммуникатора) и работать с ней. В БД имеются данные о предыдущих отгрузках и о дебиторской задолженности клиента. Агент может продемонстрировать покупателю фотографии товара.
Особенности и отличия системы. Прежде всего это возможность индивидуальной доработки. Финальная версия будет в точности соответствовать бизнес-процессам заказчика, программа содержит только необходимую для работы функциональность. Система разработана на Си++ с использованием WTL 7.5 и STL (что на практике означает отсутствие необходимости устанавливать на терминалы такие компоненты, как SQL Server Mobile или .NET Compact Framework) и позволяет добиться стабильной работы комплекса даже на не слишком мощном оборудовании. Кроме того, имеется отдельный модуль редактирования печатных форм (для Van-selling), позволяющий быстро настроить внешний вид и содержание документов. Предусматриваются модули обмена с пакетами «1С» 7.7 и 8.Х, Microsoft Dynamics NAV, «СБиС++» 1.9 и 2.Х
Обмен данными с КИС происходит с помощью внешнего отчета «1С» (ExchangePDA.ert); на КПК данные передаются в файлах DBF, обмен информацией возможен как локально, так и дистанционно (по каналам GPRS, WiFi; пользователь может контролировать частоту и масштаб сеансов связи).
Описание решения. Для решения базового набора задач использовано два программных продукта. Модуль «Создание заказов» (Pre-selling) позволяет на основе актуальной (на момент последнего соединения) информации о складских остатках и взаиморасчетах сформировать предварительный заказ, опираясь на рекомендованный перечень товаров для торговой точки и историю предыдущих заказов (анализируя динамку). Модуль «Выездная торговля» (Van-selling) позволяет отгружать товар непосредственно в торговую точку за наличный или безналичный расчет с печатью всех необходимых первичных документов (вид и содержание документов могут меняться администратором системы); при необходимости агент может сделать предварительный заказ. При этом учитывается актуальная информация по остаткам на мобильном складе (автомобиле) и истории взаиморасчетов.
Отметим, что комплекс специально разделен на два продукта, главным образом из-за различий в технологии работы агентов. В реальной жизни практически никогда не возникает необходимости решать одновременно обе задачи. Все управление группами пользователей, рабочей товарной номенклатурой и т. д. выполняется в среде «1С».
Для автоматизации сбора мерчендайзинговой информации также используется программа «НАПОЛЕОН. Создание заказов (Pre-selling)», агент может собирать информацию о наличии товарных единиц в витринах торговых точек.
Разработчик отмечает, что принципиально не реализует всю функциональность в рамках базовой версии. Обычно этого не требуют условия задания, тем более что избыток функций заметно усложнит работу с программой для торговых агентов. Кроме того, согласно комментариям представителей компании дополнительные функции не должны требовать замены стационарного и мобильного оборудования, а общая стоимость доработок (если в них возникнет необходимость) не превысит половины стоимости программного обеспечения в рамках данного проекта (т. е. менее 70% за весь список функций).