Pull to refresh

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

Reading time 7 min
Views 7.2K
Вторую часть, пожалуй, начну с ответов на некоторые вопросы по прошлой части. Некоторые читатели обвинили меня в бессистемности, сказав, что вот, мол, непонятно чем тут занимается, какой-то НДС в бланках смотрит. Нет, чтобы думать о более высоких материях. Понимаете, мне эти высокие теории и материи… Я внедрением уже 10 лет как занимаюсь и хочу, чтобы рано или поздно любое внедрение стало простым и формализованным процессом. Ни у кого не возникает вопрос, когда нужно взять и настроить сеть, потому что ее просто берут и настраивают, и всем понятно, как именно это нужно делать. Вот и при внедрении ERP нужно стремиться к тому же.

У нас ежемесячно выходит новая версия. Она проходит жесткий тестинг перед тем, как ее поставят клиентам. Это такая инструкция на 6 листах. И версия не выходит пока все не будет тип-топ. Тестер почти не думает, просто тестирует по инструкции и все. Проколы, конечно, случаются, но не часто, да и то мелкие. После каждого прокола карта тестирования дорабатывается. Вот и то тестирование, о котором я тут толкую, тоже должно проходить по аналогичному принципу. Есть ряд простых, мелких, но жизненноважных тестов. Просто делаешь их и смотришь на результат. Прошло тестирование успешно, значит можно продолжать разговор о внедрении, разработке ТЗ и о более высоких материях. Не прошло тестирование – до свидания. Все!


И упаси вас боже, думать, что тестирование, о котором я пишу – это какой-то эталон. Это просто мой вариант. Но попробуйте найти другой.

Напомню, смотрим, как в высшей математике, необходимый, но не достаточный функционал. Для кого какой достаточный, каждый уже сам доработает.

Поставки «под заказ».

В предыдущей части мы останавливались на поставках. Однако, там речь шла о так называемых поставках на склад, когда вы просто привозите товар и пополняете, таким образом, складской запас. Это нецелевые закупки. А есть и целевые. Это когда к вам приходит клиент, платит деньги за то, чего у вас нет, а вы ему это «что-то» поставляете. Это называется «поставки под заказ», очень модный (да и действительно необходимый) функционал. Основная проблема состоит в том, что клиент, который заказал у вас товар не получает ни какой гарантии. Он платит вам деньги, вы закупаете и сдаете на склад. После чего другой менеджер запросто этот товар продает другому клиенту. Сплошь и рядом такое творится. Когда вас десять человек, у вас есть шанс договориться друг с другом, что надо спрашивать, прежде чем продать, когда вас тридцать – шансов уже нет. Задача этого функционала – обеспечить клиенту 100% гарантию получения товара, если он сделал заказ (и тем паче сделал предоплату).

Есть и другой нюанс. Клиент заказал у вас 20 наименований. Одно наименование вы купите за 2 дня, а второе за 20. Вопрос: как менеджеру по закупкам понять, когда начинать процесс закупки по каждому наименованию?

Тестируется просто. Выписываем клиенту заказ (или счет, не важно, как это устроено в системе). Затем формируем заявку на закупку. Опять же, маленький нюанс. Выписываем два наименования, одно из которых есть на складе, а второе как раз и надо привезти «под заказ». Первое резервируем, а второе отправляем в закупку. Медленно и неспешно попросите показать, как именно отправить в закупку второе наименование (я уж не говорю про более сложный случай, когда вот этого второго наименования 1шт. есть на складе, а еще 2 шт. надо закупить). Едем дальше. Где менеджер по закупкам увидит, что именно это наименование нужно закупить? Попросите показать это место. Какие товарные позиции попадают в это место? Все или только те товары, заказы по которым предоплачены (или получено добро руководства на закупку без оплаты)?

Дальше проводим закупку и принимаем на склад закупленные товары. А теперь внимание! Идем в наш заказ (или счет) и смотрим, зарезервирован ли товар на складе. Нет? Ну, тогда цитируем «показывальщику» следующую фразу: «Какого х… ты компостируешь мне мозги?». Автоматическое резервирование товара по завершении процесса закупок – это и есть суть поставок «под заказ». Нет резервирования – нет функционала.

Однажды при тестировании мне было гордо заявлено, что система поддерживает стандарт MRP. Вот как это выглядело на деле:
Мне показали некую форму для планирования, где якобы менеджер по закупкам увидит, в одном месте, что именно он должен купить. Каково же было мое удивление, когда я обнаружил, что в форму планирования попадают товары, на которые клиентам просто выписаны счета. Т.е. вы просто выписываете счет клиенту, и менеджер по закупкам автоматически это видит к закупке. То, что счет запросто может быть неоплаченным – это никак не учитывается. Товар будет закуплен, привезен на склад, но клиент его не заберет, т.к. передумает вообще даже счет оплачивать. Прямой путь к затовариванию склада. Такое вот MRP, понимаешь.

Так что, тестируя продукт, выкиньте из головы все эти термины и просто тестируйте функционал. Как он при этом называется, не важно.

Склад.

Поэкспериментируйте-ка для начала с кладовщиками. Заведите два склада. Попросите разделить доступ кладовщиков по складам. Ну, это же ненормальная ситуация, когда каждый кладовщик запросто сможет отгрузить товар с любого склада, а не только со своего. А иначе, какой смысл в материальной ответственности? Зайдите в программу под этим кладовщиком и убедитесь, что он может совершать операции только по своему складу.

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

Адресное хранение. Не могу сказать, что это действительно необходимая функциональность, но меня обвинят, что это не ERP, раз нет адресного хранения (модная штука). Это может пригодиться в нескольких случаях:
1. Очень-очень большой склад.
2. Огромное желание не зависеть от кладовщиков и от их знания, что где лежит.
3. Огромное количество наименований и мелкого товара.
4. Высокая дисциплина этих самых кладовщиков.

Если хотя бы одно условие не соблюдается, есть опасения, что у вас не получится внедрить адресное хранение. В моей практике удалось однажды. Драконовская дисциплина была у ребят.

С точки зрения функционала ничего сложного нет. Вот есть склад, вот его места хранения, а вот какие товары можно класть на каждое место хранения. Принимает кладовщик товар, система требует указать адрес. То же самое при отгрузке. Более сложный функционал — это уже WMS, который в обычных компаниях не нужен. Тут можно дальше развивать тему про терминалы сбора данных, сканеры штрих-кода и т.д., но я этот функционал не отношу к жизненноважному, без него можно пережить.

Система должна давать возможность, быстро, зная товар, посмотреть его историю движения по конкретному складу, по всем складам. Посмотреть историю остатка товара на конкретном складе. Может быть еще что-то, но мне ничего в голову не приходит, что можно отнести к необходимому функционалу. Если что забыл, пишите комменты, дополню.

Договоры

Ну, во-первых, давайте посмотрим на реестр договоров. Что должно быть понятно?
1. Кто и с кем заключил этот договор.
2. Это договор с клиентом или с поставщиком (хотя, может быть, это и не важно).
3. Сроки действия, номер, подписывающие лица.
4. Вид (тип) договора, если они как-то разделяются.
5. Номенклатура поставки (если договор не рамочный).
6. Текущее состояние договора. Подписан, согласован, закрыт и т.д.
7. Скан договора.
Может быть, еще что-то.

Если договор на поставку определенной спецификации товара или оказание конкретных услуг, то, как понять, поставлен ли товар, оказаны ли эти услуги, все ли оказаны или только часть?

Если договор рамочный, то, значит, на него должны ссылаться регулярные отгрузки. Вот и посмотрите в этих самых отгрузках, видно где-нибудь (кроме комментария, разумеется), что эта отгрузка именно по этому договору? Загляните в торг-12, есть там ссылка на договор?

Как происходит движение договора. Если договор простой, типовой, то все понятно. Чего там согласовывать? А если не типовой, как происходит процедура согласования? Какие цепочки согласований уже есть и как они модифицируются? Как, ответственный за согласование того или иного этапа, узнает, что он вообще должен что-то согласовывать? Это должно быть какое-то рабочее место, где видны только те договоры, которые нуждаются в согласовании, или уведомление или еще что-то. Короче говоря, попросите показать, как это реализовано. Именно сам бизнес-процесс.

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

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

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

Может ли система сама формировать тексты шаблонных договоров? Попросите это сделать. Понимает ли система, что такое родительный падеж фамилии, должности? Заполняет ли соответствующим образом преамбулу договора? Умеет ли она правильно формировать реквизиты сторон в тексте договора? Можно ли сформированный текст выгрузить в какие-нибудь общепринятые форматы (pdf, doc, например)?

Затраты

Если вы начали внедрение ERP системы, то ваша цель, конечно же, не в том, что бы печатать из нее счета фактуры. Хотя это тоже важно, но цель не в этом. Цель в том, чтобы контролировать предприятие, понимать его эффективность, состояние, иметь возможность принимать какие-то решения. Иными словами – контролировать чистую прибыль бизнеса и заниматься ее ростом, заниматься оптимизацией ассортимента, клиентской базы и т.д… Вот это уже цели.

С вашего позволения, я покажу тут картинку. Никаких логотипов, просто картинка.
image

Вот такую картину (или что-то в этом роде) должен видеть ежедневно руководитель компании. Это отчет о прибылях и убытках. Весь не влез, но суть понятна – ниже идут еще показатели, после которых идут показатели «Операционная прибыль», «Прибыль до уплаты налогов», «Чистая прибыль».
Чтобы получить такой отчет, необходима внятно работающая система управления затратами (и не только).

Вот нужно потратить деньги на аренду (связь, командировку и т.д.). Как это происходит? Кто и что заполняет, кто и что утверждает (согласовывает) и т.д. Попросите показать, как конкретно происходит вот эта процедура?

Вам принесли счет за аренду за февраль 2010 года. Но принесли вам его 5 марта 2010. Оплатите вы его десятого марта. Где видно, что на себестоимость эти деньги «легли» именно в февраль, а по движению денег именно в март? В этой ситуации, это означает, что в отчете о прибылях и убытках эта сумма должна быть отражена в феврале, а в отчете о движении денежных средств в марте.

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

Этим заканчиваю очередную часть. В следующей части поговорим о проектах, управлении запасами, производстве, оптимизации ассортимента, финансовой отчетности и еще о чем-нибудь.
Tags:
Hubs:
+25
Comments 14
Comments Comments 14

Articles