О преимуществах Microsoft Dynamics AX 2012 на примере "Заказа на покупку"
ERP систем существует сейчас много и сравнить каждую с каждой сложно, даже не стоит пытаться. Но чтобы объяснить некоторые преимущества системы AX 2012 мы все же сличим ее с другими, но не целиком, а на одном маленьком примере. Рассмотрим вопрос на примере закупки товара у поставщика.
В Аксапте много чего есть. Касаемо вопросов закупки - это и механизмы учета прайс-листов поставщиков, и разделение склада, и интерфейсы по операциям приемке с учетом ответственности, но мы сейчас выкинем это из рассмотрения. Большинство малых и средних предприятий в эти детали не вдаются (подробный учет приемки товара на небольшом складе смысла не имеет, а цены поставщиков если их хранить в виде прайс-листа не становятся от этого более предсказуемыми). Закупка у таких компаний сводиться к своевременной приобретению нужного товара. Причем даже вопросы длительности поставок (которые решаются в Аксапте с помощью модуля «Сводное планирование») обычно держат в голове, например, по тому что закупаются на ближайшем оптовом складе.
Все лишнее исключено НЕ для того, чтобы показать функциональную насыщенность этого блока Аксапты, а чтобы продемонстрировать концепцию построения интерфейсов системы.
То что осталось отображается в большинстве ERP систем двумя документами: «счетом на оплату» от поставщика (из которого формируется оплата) и «приходной накладной». Ведь это правильно? Что еще нужно? Мы регистрируем фактические события. Оператор вводит первый документ, потом из него получает второй...
Интерфейс Аксапта построен принципиально иначе.
Сперва мы прикидываем (ну или рассчитываем в модуле "Сводное планирование"), что нам нужно и вводим наши желания в Закупку. Это не документ – это наш интерфейс. Опят же, можем Закупку не вводить а сформировать из модуля "Сводное планирование", но не в этом суть. После этого создаем первый документ, который называется «Заказ на покупку». Т.е. мы запрашиваем у поставщика то, что мы хотим. Затем фиксируем ответ документом «Счет на оплату». Все что поставщик готов нам поставить и свои цены он прислал нам в «Счете». Что то поставщик отгрузить не может и это осталось на потом. Это «потом» сразу видно в нашем интерфейсе. На этом этапе имеет смысл сравнить счета от разных поставщиков по ценам и по товарам. Факт поставки товара фиксируется «накладной» и мы сразу видим в «Закупке» что уже пришло, а что еще ждем... Мы всегда видим, то что мы хотим, но еще не пришло и можем сформировать документы на оставшийся товар или запросить этот товар у другого поставщика...
Данный маленький пример характеризуем общие принципы построения интерфейсов системы Аксапта. Например здесь в Закупке мы имеем целую систему отслеживания, которая выполняет большую часть того, что можно отнести к CRM (по взаимодействию со всеми контрагентами, а не только с клиентами). И это все работает даже без подключения модуля CRM.
Подобным образом построены и другие инструменты системы. Конечно такой подход имеет и свои минусы: интерфейсы менее привычны для обычного клерка, который не привык строить свою работу в системе, а привык все держать в голове и отчитываться по факту. Но если все же барьер понимания пройден (а это тот вопросы которому мы уделяем самое большое внимание), то такой интерфейс становится личным инструментом каждого специалиста компании.
Интерфейс системы Аксапта построен от идеи которая сидит в голове у пользователя, от задумки, и он таков на все уровнях (у каждого специалиста на любом уровне управления). Такая архитектура дает очень многое. Это уже не просто учетно-контрольная система руководства, а созидательно-управленческий инструмент всей компании...
Мартынов Дмитрий
|
