Pull to refresh

Тестируем ERP-систему. Часть 3

ERP-systems *
Продолжаем тестировать ERP систему. Первая часть здесь, вторая часть здесь.
Сегодня попробуем разобраться с производством и проектами. А в следующей части поговорим уже об отчетности и всяких инструментах для принятия решений.
Начнем, пожалуй с проектов. С ними более понятно.
Сначала определимся с понятием. Могу ошибаться, если что поправите меня.

Что это и зачем это в ERP

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

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

А теперь «внимание, вопрос». Сколько вы заработали на этой сделке?
Еще нюанс. Прошел год. некоторые участники проекта уволились. Хочется посмотреть, как шел тот или иной процесс при разработке проекта, кто кому и что писал.
Ну, и много других вопросов.

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

Вот для этого и нужно в ERP-системах управление проектами. Тестируем.

Для начала попросите просто показать вам список проектов.
Можно из списка понять, в каком состоянии находится проект? Закончен он, в процессе, или как?
Как из проекта посмотреть, какие были поставки по нему? Вот конкретно, где их видно? Где видно, что поставляли, как и когда за это было оплачено и т.д.? Где видно переписку участников проекта с заказчиками или третьими сторонами?
Где видно все расходы по проекту? Кому, сколько, когда оплачено и за какие услуги? Оказаны эти услуги или еще нет? Оказаны? А где это видно?
Где посмотреть, кто, когда и куда ездил в командировки по проекту?

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

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

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

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

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

Производство

Пожалуй, самая сложная и непонятная часть всего этого тестирования. Я долго думал, как придумать для производства универсальные тесты, но это оказалось не так просто. Поэтому я напишу только те тесты, которые точно будут работать. По минимуму.
Итак, вы производите нечто. Сначала предлагаю разобраться с вопросами, которые мучают тех, кто производит.
  • Что я должен делать?
  • Что мне для этого нужно?
  • Могу я это начинать делать?
  • Когда я должен начинать?
  • Из чего я должен сделать?
  • Как сделать вовремя?
  • Какая у меня себестоимость?


Ну, пожалуй, все. Остальные вопросы, либо относятся к продажам, либо к финансам, либо к поставкам.

Где видно, что компания должна произвести, чтобы удовлетворить заказы клиентов? Короче говоря, график производства в студию!
Если вам покажут объемно-календарное планирование, то задайте простой вопрос. Что делать, если я сегодня не выполнил запланированный объем? Я тут как-то писал по этому поводу. В общем на западе давно уже поняли, что такой метод планирования ничего не решает и не улучшает ситуацию на производстве.

Где в графике производства видно, что и в какой очередности я должен делать? Нельзя же делать все одновременно, правда?

Далее. Задайте простой вопрос: «Какие методики управления производством использует ваша система? Что это за методики? Какие производственные показатели эти методики способны улучшить и за счет чего?» За счет применения каких именно методик достигается производство вовремя?

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

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

Когда создается производственное задание, состав компонентов создается автоматически? Можно в него внести изменения? Как конкретно происходит замена компонента на аналог?

Вот вам, для разминки, фрагмент из тестирования одной очень известной ERP системы (XXX).

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


Так что внимательно разбирайтесь в том, как именно формируется потребность, по какому конкретно алгоритму

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

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

К чему я это? Да к тому, что в компании все должно быть органично. Если хочется круто все учитывать и автоматизировать, то и культура в компании должна быть соответствующей и сотрудники. Какую-то гармонию надо соблюдать. Не надо пытаться автоматизировать гужевой транспорт. Надо его сначала сменить.
Tags:
Hubs:
Total votes 29: ↑24 and ↓5 +19
Views 4.3K
Comments 33
Comments Comments 33

Posts