PC Magazine/RE - Журнал PC Magazine/RE №11/2009
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 – задача, сопоставимая с созданием самого бизнеса. Но если ее решить, то бизнес станет управляемым, как хороший автомобиль.
Типовое решение
