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

[@jeppeQue]

Супер! Как всегда информативно и интересно! Спасибо.

[@nonname]

Спасибо за статью. А планируете сделать статью с реальными примерами ERP систем? Думаю многие слышали о 1С и SAP, но вот кроме них я больше ничего не знаю и с ними всё ясно вполне. Но вот хотелось бы узнать какие существуют альтернативы в примерах, возможно опен сурс? Думаю, не только мне будет интересно почитать об этом.

[@elve]

Есть OpenERP. Сам не пробовал ее.

[@erp_shnik]

Опен сорс есть несколько еще. Но их потестировать самостоятельно сложно. А показывать некому…

[@nonname]

Ананас я посмотрел как-то, интерфейс был просто ужасен.

[@erp_shnik]

Да нет, я не против. С анансом сам не сталкивался, ничего сказать не могу. Ни плохого, ни хорошего. Поэтому готов почитать и ваш опыт.
Внедрения промышленные есть хотя бы человек на 30?

[@erp_shnik]

Хм, а как тот проект поддерживается и кем, если вы «соскочили»?

[@NYV]

Интересно, есть ли опыт работы\тестирования системы «ИТ-Предприятие»?

[@bytemdfab]

У нас на предприятии лет 5 пытались внедрить, но забуксовали на себестоимости. Сейчас своими силами на 1с допиливаем. Лично у меня IT-Предприятие вызывает стойкий рвотный рефлекс, но это только мое личное мнение.

[@erp_shnik]

Да, есть реальные тестирования SAP B1, 1С, Навижн, Аксапта, SAGE, Галактика. Скоро будет JDE.
Я пока не буду пока выкладывать результаты тестов, пока они не опубликованы в PCMagazine. После публикации посмотрим.
ИТ-Предприятие, к сожалению нет. Но нет ничего невозможного. :-)

[@Zebr]

Нормальное, такое, железобетонное тестирование. Именно так и следует подходить к проверке продукта, в который вы собираетесь вложиться и добиться с его помощью каких-то улучшений.

Но к такому тестированию нужно заранее подготовиться (если только вы не собираетесь запоминать все цифры, которые заносите в тестируемую систему). И такое развлечение на 2-3 человека со стороны заказчика максимум. Которые, при этом, так же хорошо, как и вы, понимают важность процесса тестирования и не будут пытаться его «ускорить».

[@agathis]

это не железобетонное тестирование, а тестирование за день.
железобетонные длятся намноооого дольше.

[@kaasnake]

А вы проводите какие-либо тесты ERP которые отображают общую производительность, масштабируемость, расширяемость функционала системы? Есть ли у вас какие-либо рекомендации на этот счёт? А то с точки зрения одного пользователя система может быть идеальной, а когда этих пользователей сотни, да ещё и они разбросаны территориально, да ещё и когда первичных документов генерируется большое количество, вот тогда очень красивая и сложная система может стать очень головной болью. И, как правило, такой она становится через некоторое время после введения в эксплуатацию.
Да, кроме этого основная цель любой ERP системы по сути — не только в регистрации первички (это конечно тоже важно), но и в представлении результатов. То есть очень важно понять в каком виде мы получим отчеты и сможем ли мы что-то планировать по результатам таких отчетов. Тоже хотелось бы узнать ваше мнение по этому поводу.

[@erp_shnik]

Согласен, как раз насчет представления результатов будут следующие части. Для того, чтобы были результаты и внятная отчетность, нужны правильные первичные данные. Если их нет, не будет никакой отчетности.
Общая производительность, масштабируемость, расширяемость — это слишком «аморфные» понятия и для их тестирования такую простую инструкцию написать сложно. Лучше такие вещи, кстати, смотреть и реальных клиентов. Просто ехать и смотреть.

[@erp_shnik]

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

[@erp_shnik]

На самом деле, конечно, лучше, чтобы все было понятно не интуитивно, а по документации. :-)
Интуиция у всех разная, однако.
А такие понятия, как удобно-не удобно, они слишком субъективны.

Более того, ни один разработчик ERP никогда не будет переделывать основы своего интерфейса под конкретного клиента. Или он вам нравится или нет. Интерфейс какой есть, такой он и останется. Может быть и поменяется, но системно, и не чаще, чем чем один раз в несколько лет.

[@Vozhdyara]

Какие-то странные вещи тестируются в ERP. Ни бизнес-процессы, ни интеграция, ни возможности по оптимизации бизнес изменений, а наличие НДС в бланке…
Как-то иначе я себе ERP представлял

[@erp_shnik]

Написано же — Часть 1.

[@Vozhdyara]

Тогда извините, не понял структуру повествования.
А в какой части про сам «Enterprise Resource Planing» будет?

[@erp_shnik]

На этом планирую акцентироваться в 3-4 части.

[@serbod]

А вы могли бы сделать хорошее дело, тиснув книжку с подробной инструкцией по тестированию и внедрению ERP-системы и бланками для отметок. У вас хорошо получается.

[@erp_shnik]

Сложный вопрос. Не думал об этом.

[@erp_shnik]

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

[@erp_shnik]

Конструктивная критика еще ни кому не мешала :-)

[@erp_shnik]

Я уже перестаю понимать, о чем вы…
Поконкрентнее и попонятнее, pls

[@erp_shnik]

А. понял. Да, давайте. Я, конечно, могу чего-то упустить…

[@serbod]

В результате, годами устоявшиеся бизнес-процессы ломаются и перекраиваются в угоду совершенно левой логике, заложенной в купленную систему.

Это не так уж и плохо. Иной раз гораздо проще и эффективнее изменить поведение людей, чем поведение программы.

Обычно все упирается в одного конкретного человека, который не понимает или не желает понимать предложенный вариант и тупо настаивает на своем. Даже если его вариант не выдерживает критики, главный контраргумент «мне виднее, мы уже N лет так работаем». А обойти этого человека стороной не всегда возможно.

[@agathis]

ооо, знаете, мне приходилось выслушивать транспортного цеха, и могу вам доложить, что решить задачи финдепартамента обычно проще, хотя бы потому, что они гораздо лучше изучены (и реализованы) внедренцами и разработчиками всех мастей :)

[@agathis]

«начальника транспортного цеха», конечно.

так вот, у них и свой склад с запчастями, и учет ГСМ (весьма хитрожопый), и моточасы, и пробеги и еще миллион вещей, которых я уже и не помню, благо 4 года с тех пор прошло. они ведь тоже люди, хотят «нажми на кнопку, получишь результат» ;)

[@agathis]

Ну вообще странно.

ERP уже протестировали, а ТЗ еще нет :)
Внедренцы, пишущие ТЗ — плохая идея, напишут «под себя». ТЗ должен писать заказчик, возможно специально им нанятый человек, а внедренцам можно оставить ТП; тоже вещь нелишняя.

Какой-то у нас сферический проект в вакууме получается.

И с транспортными предприятиями я не сталкивался, слава б-гу ;)

[@erp_shnik]

Я намеренно сначала начал описывать именно тестирование, а затем уже разработку ТЗ на внедрение. Сначала нужно выбрать (и здесь тоже нужно фактически ТЗ, бизнес-кейсы, требования), а потом внедрять. ТЗ писать, все таки, должны внедренцы. В противном случае вы получите ситуацию, когда «писатели ТЗ» будут тыкать на внедренцев, а те наоборот.

[@erp_shnik]

Да, непростая задача. Согласен

[@oogl]

Коллеги, мне кажется это слишком суровый подход к своим пользователям, к себе и к продаванам. Гораздо проще и лучше в рамках написания того же ТЗ на подбор системы накидать N сценариев ключевых пользователей.
Выдать сценарии консалтам, дать тем недельку подготовиться, а затем с чувством с толком, расстановкой украсть у каждого из ключевых юзверей пол часа бесценного времени, на вдумчивое прохождение сценария вместе с консалтом и вами. Итого выходит сурьёзная экономия времени и нервов, а самое важное, вы будете проверять не абстрактные примеры, а вполне конкретные сценарии ваших бизнес-процессов.

[@serbod]

Хочешь сделать важное дело как надо — сделай сам. Другим поручишь — они забьют или перепоручат третьим. В итоге «все хорошо, прекрасная маркиза!» и никто ни за что не отвечает.

[@erp_shnik]

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

[@oogl]

Не готов я сам тестировать функционал предназначенный для менеджера по логистике — слишком много нюансов, все эти ожидаемые приходы, коносаменты, объёмный вес и палетная организация склада, не готов.
Лучше я ключевого юзверя допеку и буду стоять у него над душой во время тестирования и задавать вопросы, но сам за это дело не возьмусь.

[@erp_shnik]

не готовы, не беритесь. Если подключать ключевых юзверей, тестирование можно не начинать, потому как оно ничем не закончится. Тут проблема в ответственности. Зачем она «юзверю»?

[@erp_shnik]

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

[@oogl]

Надо было описание с этого и начинать, а то выглядит всё дилетантски — смотрим какие-то реквизиты форм, при этом совсем не очевидно, что они для нас являются ключевыми.
** Да здравствует системный поход к изложению материала ;)

[@erp_shnik]

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

[@Dipodidae]

И будет чудом! если качество продуктов поднимется. Но хотя бы обмануть себя не дадим.

[@JYE]

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

[@erp_shnik]

Вот как раз для того, чтобы защититься от «правильных» внедренцев, которые никогда честно не говорят «наш продукт вот этого не умеет и это нам надо разрабатывать» я и пишу эти статьи.