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

    За последние полгода я натестировался ERP систем по полной программе. Участвовал в обзоре российского рынка ERP систем. Интересные вещи всплывали, признаюсь я вам. И ладно, если бы эти интересности всплыли, если бы я во время обзора представлялся от имени редакции издания, которое этот обзор и проводило. Но мы намеренно сделали так, что представлялся я от имени совершенно реального клиента. То есть побывал в шкуре самого натурального клиента и увидел все своими глазами. Подробности обзора рассказывать не буду, их можно будет почитать на страницах издания (как выйдет обзор, выложу пост). Вывод прост – надо быть готовым к тому, что тебя будут пытаться «немножко обмануть». Попробую дать некоторые рекомендации, чтобы этого не случилось.

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

    Ну, во-первых, не надо думать, что этот вопрос можно решить за пару часов. На качественное тестирование и изучение продукта в сопровождении представителя уходит 6-10 часов. У меня.

    Универсального метода тестирования, который бы избавлял вас от рисков на 100%, я думаю, нет. Но, все же есть некоторые советы, которые помогут эти риски снизить. Поговорим о некоторых функциональных возможностях erp-систем, которые я бы отнес к фундаментальным, на которых строится все остальное. Не будем тут говорить о сложных алгоритмах и всяких «фишках», так как к их тестированию нужно подходить со специальной подготовкой и это сделать непросто. Попробуем убедиться, что система имеет нормальные инструменты для учета, анализа и документооборота.

    Свои фирмы

    От имени какого количества юридических лиц вы работаете? Если от имени одного, то это одно, а если от имени двух, то это уже гораздо сложнее. Тестируем.

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

    Не лишним было бы проверить, что система поддерживает упрощенную систему налогообложения. Занесите свою компанию, которая не является плательщиком НДС. А теперь выпишите от нее счет. Есть НДС в бланке?

    Еще более сложный случай – разный НДС на разные товары. Продукты питания, игрушки. Если у вас это есть, то попросите занести в программу такой товар и посмотрите, где это указывается. Выпишите счет, проверьте НДС.

    Первичка

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

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

    Внимательно изучите сам бланк счета фактуры. Вы дадите такой клиенту? Нормально он заполнен? Все реквизиты на месте?

    Маленький нюанс со счетами фактурами. Там есть такой реквизит «К платежно-расчетному документу», это номер платежного поручения и его дата. Клиенты очень не любят, когда этот реквизит не заполнен. Убедитесь, что он работает. Это просто. Допустим ваш счет-фактура от 01.07.2009 года. Сделайте платежное поручение от 30.06.2009 и посмотрите счет-фактуру. Есть там номер и дата? А теперь тест посложнее. Сделайте платежное поручение от 05.07.2009. И снова смотрим счет фактуру. Если заполнено, то плохо. Разумеется, здесь должны отражаться только те платежные поручения, которые были до отгрузки, а не после, потому что счет фактура не может знать, о том, что будет в будушем. И если клиент платил дважды, сначала до отгрузки, а потом часть денег после, то в счете фактуре должна быть только первая платежка.

    Попросите показать торг-12, внимательно проверьте все реквизиты. Если презентующий на вопрос «А где половина реквизитов?» утверждает, что они просто не заполнены, то попросите заполнить и показать еще раз. А вообще это очень странно, что система дает печатать полупустые бланки строгой отчетности.

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

    Ну, а чтобы вы не расслаблялись, приведу фрагмент одной истории тестирования:
    Учет ГТД. Итак, я попросил купить товар и указать в поставке ГТД. Указали. Потом попросил сделать продажу и посмотреть на счет-фактуру. И вот тут самое интересное. Сделали отгрузку, в счете фактуре оказалась та самая ГТД, однако страна была совсем другая, чем указанная в поставке. То есть та, которая указана в классификаторе для этого товара, которая к поставке не имеет отношения. Разве обратит внимание на этот «пустячок» потенциальный заказчик? Конечно, нет.

    Так что, как говорили «наперсточники», смотрим внимательно – выигрываем обязательно.

    Едем дальше. Клиенты.

    Я думаю, многие сталкивались с ситуацией, когда у клиента несколько юридических лиц. Вот и давайте проверим, понимает это система или нет. Для начала, зачем это нужно. Я думаю, если этот пост читает человек, работавший с клиентами, он поймет. Вот у вас клиент, у него три юридических лица. Сегодня он у вас купил товар по одному своему юрику, а завтра по-другому. Вопрос на засыпку – чему равна дебиторская задолженность клиента?
    Это вашему бухгалтеру абсолютно «фиолетово» реальная дебиторка «всего» клиента, а вас-то интересует, конечно, суммарная, то есть по клиенту в целом, а не по каждому его юр лицу отдельно. Кстати, насчет бухгалтера. Попросите-ка ребят показать вам, как из программы сделать акт сверки. И вот там-то как раз все должно быть строго по каждому юридическому лицу клиента отдельно.

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

    Ну, я не буду тут останавливаться на всякой CRM функциональности. Думаю, это и самостоятельно проверить не сложно. Главное, внимательно смотреть.

    Еще немного логистики. Вот клиенту выписан счет. В нем некий товар в количестве 10 шт. Нужно отгрузить 5 шт. со склада, а остальные 5 отправить в закупку. Ну, не повезло клиенту и не хватило. С кем не бывает.

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

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

    Кстати, насчет прошлого квартала. А как блокируется доступ на изменение данных в этом самом прошлом квартале? Попросите показать и продемонстрировать, что действительно нельзя исправить. Когда у вас в компании 3 человека, вы можете договориться, чего делать можно, а чего нельзя. А когда вас 30, договориться сложно. Нужна система.

    А вот фрагмент из тестирования одной очень известной ERP-системы:
    Так вот, самое интересное началось, когда я попросил показать на экран торг-12. И увидел там, в качестве плательщика, почему-то название самого клиента, а не юридического лица. Как такое возможно? Ведь название клиента – это просто общее название вашего партнера. Как оно может фигурировать в официальных документах? Я попросил убрать эту оплошность и в качестве плательщика указать название юр лица, а не название клиента. И вот тут-то все и выяснилось. Это юридическое лицо сразу перестало иметь хоть какое-то отношение к нашему клиенту. Это значит, что при эксплуатации XXX вам придется выбирать. Или вы не сможете контролировать финансовые показатели по клиенту в целом или вы не сможете формировать из XXX первичные документы.

    Немного про закупки.


    Где видно, что я должен купить? Вот я менеджер по закупкам на производстве. Комплектующих тысячи. Одновременно компания может испытывать потребность в покупке сотен, а может и тысяч наименований? Вот мне как понять, что я должен покупать сейчас в первую очередь, что во вторую, а что пока вообще покупать не надо, потому что оно может и подождать? Короче, график закупок в студию!

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

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

    Простая ситуация: вы начали эксплуатацию системы. Куча заказов поставщикам, сотни. Вот как в этом списке понять, какие заказы обработаны, а какие нет? Если есть какой-то статус заказа, то как он меняется? Автоматически или как? Может быть какие-то цвета, или еще что-нибудь?

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

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

    Счет оплатили. Вам везут груз. Но и тут нюанс. Этот вредный поставщик разбил счет на две накладных. Одну привез сегодня, а вторую довезет на следующей неделе (в России такое случается, на западе реже, но бывает, что разбивают заказы на несколько инвойсов). Попросите отразить эту неприятность. Да, не забудьте включить в себестоимость товара в накладной цену доставки. А кто именно вам оказал эту доставку, хочется знать? А где это видно, кто ее оказал? А где видно, что доставка оказана и вы получили документы по ней? А где видно задолженность перед тем, кто оказал доставку? Вы ведь ее еще не оплатили…

    Опять про коммуникации. Как менеджер по закупкам сообщит кладовщику (особенно, если складов несколько), какой груз тому ожидать и когда?

    Заводские (серийные) номера.

    Некоторые компании, поставляющие сложное оборудование, которое нуждается в обслуживании и гарантии, хотят учитывать серийные номера. Я тут не буду вдаваться в тонкости, а просто дам несколько советов. Вот вы отгрузили товар. Где, после отгрузки, можно посмотреть, какие именно серийные номера отгружены?
    Другой тест такой. Откройте общий список серийных номеров. Видно в серийном номере, где он вообще сейчас находится? Попросите показать историю движения конкретного номера, то есть где купили, по какому документу, от какого поставщика, кому продали, по какому счету (заказу) и т.д.

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

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

    Подробнее
    Реклама

    Комментарии 58

      +3
      Супер! Как всегда информативно и интересно! Спасибо.
        0
        Спасибо за статью. А планируете сделать статью с реальными примерами ERP систем? Думаю многие слышали о 1С и SAP, но вот кроме них я больше ничего не знаю и с ними всё ясно вполне. Но вот хотелось бы узнать какие существуют альтернативы в примерах, возможно опен сурс? Думаю, не только мне будет интересно почитать об этом.
          +1
          Есть OpenERP. Сам не пробовал ее.
            0
            Опен сорс есть несколько еще. Но их потестировать самостоятельно сложно. А показывать некому…
              0
              Ananas, но пока для весьма узкого круга задач.
              Но надежды не теряем…
                0
                Ананас я посмотрел как-то, интерфейс был просто ужасен.
                  0
                  Интерфейс дизайнера я когда-то подпилил малость…
                  После 0.9.3 должно было быть немного интереснее.
                  Старался для любителей 1С, чтоб им удобнее было и привычнее.
                  А в самой конфигурации, какой нарисовать, такой и будет.
                  Qt, однако…
                  Возможностей там не мало заложено.
                  Достойный интерфейс нарисовать можно.
                  Если потребителю захочется, естественно…

                  P.S.
                  Из уважения к топикстартеру обсуждать системы, им не предложенные к рассмотрению, не буду,
                  чтоб не гадить в чужую песочницу ;)
                    0
                    Да нет, я не против. С анансом сам не сталкивался, ничего сказать не могу. Ни плохого, ни хорошего. Поэтому готов почитать и ваш опыт.
                    Внедрения промышленные есть хотя бы человек на 30?
                      +1
                      Промышленное внедрение от стороннего разработчика, первое на планете, кроме демо от команды Ананас и их собственных внедрений — моё ;)
                      Примерно 4 года назад.

                      Пользователей было 7 человек. Направление — логистика.
                      Конфигурация выложена в открытый доступ и информация о ней есть на сайте Ananas. Там же и примеры. Я же и автор примеров ;) В стиле «Заметки на манжетах».
                      С примером конфигурации для кадрового учета выступал в Киеве на OSDN…
                      До промышленного состояния конфигурация не доведена.

                      Человек на 30 на то время внедрить было просто невозможно из-за отсутствия нормального многопользовательского режима и механизмов блокировки.
                      Достоверно известно, что успешные внедрения решений на Ананасе есть, с кассовым оборудованием и т.п.

                      Но сам интерфейс уже в то время можно было делать достаточно гибкий и удобный.
                      У меня есть извращенное пристрастие к динамическим формам.
                      Месяца 4 жестокого садо-мазо, изучение новых для меня инструментов, и задача пошла в эксплуатацию.
                      Успешно заменил пачки табличек Exel…
                      Отчеты всякие для контрагентов, в требуемых форматах создавал, сотрудники фирмы, в которой я тогда работал, остались довольны. Два года успешной эксплуатации.
                      В ходе разработки навешал багов в трекер Ананаса.
                      Часть из них оперативно была закрыта командой, часть закрыл сам. Несколько моих коммитов пошло в основную ветку.
                      Существенно переработал интерфейсы дизайнера, после чего к проекту возрос интерес со стороны разработчиков 1С.

                      После смены места работы мой интерес к продукту, к сожалению, угас.
                      Текущее состояние дел не отслеживаю, так как есть некоторые собственные идеи, которых в Ананасе, скорее всего нет и не будет.

                      Будет ли мой собственный проект? Скорее всего — нет.

                      Краткое резюме: Вполне достойный продукт в своей нише.
                      Малые предприятия, автономные торговые точки и т.п.
                      Возможность читать/генерить XML позволяет организовать обмен практически с любой ERP, чем существенно «облегчить» общую стоимость внедрения.
                      Опять же, на рабочих местах любимый мной Linux, что дополнительно добавляет маны и здоровья.
                      Широкий выбор СУБД, что так же в плюс.
                      Самостоятельного сервера приложений нет, что меня и огорчает.
                        0
                        Хм, а как тот проект поддерживается и кем, если вы «соскочили»?
                          0
                          Так я ж его и не поддерживал…
                          Даже в команду официально не входил…
                          Пару патчей выродил…
                          Конфигурацию поддерживать и не планировал, потому как она очень узкоспециализирована. Отдал на примеры, так как их там было…

                          А проект, как и раньше, поддерживают Валерий Гражданкин и Андрей Паскаль…

                          Вся инфа на ananas.su (не сочтите за рекламу)
          0
          Интересно, есть ли опыт работы\тестирования системы «ИТ-Предприятие»?
            0
            У нас на предприятии лет 5 пытались внедрить, но забуксовали на себестоимости. Сейчас своими силами на 1с допиливаем. Лично у меня IT-Предприятие вызывает стойкий рвотный рефлекс, но это только мое личное мнение.
            0
            Да, есть реальные тестирования SAP B1, 1С, Навижн, Аксапта, SAGE, Галактика. Скоро будет JDE.
            Я пока не буду пока выкладывать результаты тестов, пока они не опубликованы в PCMagazine. После публикации посмотрим.
            ИТ-Предприятие, к сожалению нет. Но нет ничего невозможного. :-)
              +1
              Нормальное, такое, железобетонное тестирование. Именно так и следует подходить к проверке продукта, в который вы собираетесь вложиться и добиться с его помощью каких-то улучшений.

              Но к такому тестированию нужно заранее подготовиться (если только вы не собираетесь запоминать все цифры, которые заносите в тестируемую систему). И такое развлечение на 2-3 человека со стороны заказчика максимум. Которые, при этом, так же хорошо, как и вы, понимают важность процесса тестирования и не будут пытаться его «ускорить».
                0
                это не железобетонное тестирование, а тестирование за день.
                железобетонные длятся намноооого дольше.
                +1
                А вы проводите какие-либо тесты ERP которые отображают общую производительность, масштабируемость, расширяемость функционала системы? Есть ли у вас какие-либо рекомендации на этот счёт? А то с точки зрения одного пользователя система может быть идеальной, а когда этих пользователей сотни, да ещё и они разбросаны территориально, да ещё и когда первичных документов генерируется большое количество, вот тогда очень красивая и сложная система может стать очень головной болью. И, как правило, такой она становится через некоторое время после введения в эксплуатацию.
                Да, кроме этого основная цель любой ERP системы по сути — не только в регистрации первички (это конечно тоже важно), но и в представлении результатов. То есть очень важно понять в каком виде мы получим отчеты и сможем ли мы что-то планировать по результатам таких отчетов. Тоже хотелось бы узнать ваше мнение по этому поводу.
                  0
                  Согласен, как раз насчет представления результатов будут следующие части. Для того, чтобы были результаты и внятная отчетность, нужны правильные первичные данные. Если их нет, не будет никакой отчетности.
                  Общая производительность, масштабируемость, расширяемость — это слишком «аморфные» понятия и для их тестирования такую простую инструкцию написать сложно. Лучше такие вещи, кстати, смотреть и реальных клиентов. Просто ехать и смотреть.
                  +5
                  Просить внедренца протестировать функционал — одно, а посадить потенциального пользователя и предложить ему сделать те же действия — совсем другое…
                  Однажды, в ходе внедрения одного, шибко крутого продукта, имел место такой казус:
                  В интерфейсе есть кнопка с надписью «Квота No»…
                  Ни один из сотрудников не смог понять, что обозначает эта надпись и что выплюнет программа при нажатии на неё.
                  В компании термин «квота» устаканился с некоторым лимитом, выделяемым каждому торговому представителю на календарный период.
                  Как оказалось, надпись «Квота No» в понимании внедренцев обозначала «Quote №» (тупая транслитерация, а символ № заменен) и за этой кнопкой был скрыт список счетов, с одного из которых нужно было производить оплату.
                  Кэп Очевидность в это время маялся поносом и подсказать нашим сотрудникам ни чего не мог…

                  Внедренцы же очень быстро клацали по элементам управления формы и быстро выполняли все просимые тестовые приседания и зеленые свистки в бубен.

                  Иными словами, после успешной демонстрации всей функциональности комплекса требуйте отстоя пены посадите за рояль своего сотрудника, специфики данного интерфейса не знающего, но владеющего устоявшимися терминами предметной области.
                    0
                    Да, тестирование нужно проводить медленно. Если что-то не понятно, требовать повторить до тех пор, пока не станет понятно. Попытки консалтеров быстренько понажимать на кнопки, чтобы было непонятно, нужно пресекать.
                      0
                      Я предпочитаю требовать сделать так, чтоб сразу все было понятно. Интуитивно…
                      Тот персонал, который проходит обучение «из первых рук» и/или принимает участие в процессе внедрения имеет привычку увольняться.
                      На его место приходит совсем другой персонал.

                      А его учить уже некому, внедренцы получили свое и слиняли…

                      Если на этапе постановки ТЗ прощелкали вопросы usability, то потом будет больно…

                      Таки напрашивается «Часть 0. Постановка ТЗ на разработку и внедрение ERP» ;)
                        +2
                        На самом деле, конечно, лучше, чтобы все было понятно не интуитивно, а по документации. :-)
                        Интуиция у всех разная, однако.
                        А такие понятия, как удобно-не удобно, они слишком субъективны.

                        Более того, ни один разработчик ERP никогда не будет переделывать основы своего интерфейса под конкретного клиента. Или он вам нравится или нет. Интерфейс какой есть, такой он и останется. Может быть и поменяется, но системно, и не чаще, чем чем один раз в несколько лет.
                    0
                    Какие-то странные вещи тестируются в ERP. Ни бизнес-процессы, ни интеграция, ни возможности по оптимизации бизнес изменений, а наличие НДС в бланке…
                    Как-то иначе я себе ERP представлял
                      0
                      Написано же — Часть 1.
                        0
                        Тогда извините, не понял структуру повествования.
                        А в какой части про сам «Enterprise Resource Planing» будет?
                          0
                          На этом планирую акцентироваться в 3-4 части.
                      +1
                      А вы могли бы сделать хорошее дело, тиснув книжку с подробной инструкцией по тестированию и внедрению ERP-системы и бланками для отметок. У вас хорошо получается.
                        0
                        Сложный вопрос. Не думал об этом.
                          +2
                          Вопрос более чем сложный.
                          И начинается он с осознания того, что же нам (предприятию) нужно на самом деле…
                          Жонглирование терминами «ERP», «CRM», «ERP-II» чаще всего приводит к тому, что за достаточно большие деньги приобретается, разрабатывается и внедряется совсем не то, что нужно данной конкретной фирме.

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

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

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

                            +1
                            Тут мы с вами уже полезли в сложный вопрос внедрения. Конечно, одно дело выбрать, другое внедрить. Я когда закончу про тестирование, напишу свое видение этого процесса, классические ошибки и т.д. Потом опишу одно из последних внедрений буквально по косточкам. Отдельный топик можно будет посвятить и разработке ТЗ
                              +2
                              Я, с вашего позволения, с позиции «Бабы-Яги», которая всегда против, буду акцентировать внимание на возможных проколах и недостатках…
                              Не из вредности и/или желания критиковать ваш пост,
                              а из концепции экстремального программирования, кода ваш напарник, через плече, быстрее замечает ошибки.

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

                              Идеальный тестер…
                              ;)

                              P.S.
                              И обязательно уделить вниманию «транспортному уровню»…
                              То есть, правильному проектированию сети, серверной инфраструктуры и т.п…

                              Будет очень полезно.
                                0
                                Конструктивная критика еще ни кому не мешала :-)
                                  +2
                                  Нет…
                                  Это не конструктивная критика…
                                  Это больше похоже на игру «хороший-плохой» полицейский…

                                  Это осознанная постановка себя на место потенциального пользователя комплекса, одного из «игроков», участников процесса эксплуатации.
                                  И анализ каждой «шероховатости».
                                  При этом разделяются замечания, обусловленные неправильным обучением пользователя, его предыдущим опытом, или замечания, обусловленные неправильной постановкой ТЗ.

                                    0
                                    Я уже перестаю понимать, о чем вы…
                                    Поконкрентнее и попонятнее, pls
                                      0
                                      Это я о «конструктивной критике»…
                                      Её, как таковой, не будет.

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

                                      Если кратко, то в виде «хорошо бы еще и это».

                                      Но и это, в принципе, не обязательно, так как уровень изложения весьма высокий.
                                      Может быть и не понадобится…
                                        0
                                        А. понял. Да, давайте. Я, конечно, могу чего-то упустить…
                              0
                              В результате, годами устоявшиеся бизнес-процессы ломаются и перекраиваются в угоду совершенно левой логике, заложенной в купленную систему.


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

                              Обычно все упирается в одного конкретного человека, который не понимает или не желает понимать предложенный вариант и тупо настаивает на своем. Даже если его вариант не выдерживает критики, главный контраргумент «мне виднее, мы уже N лет так работаем». А обойти этого человека стороной не всегда возможно.
                                0
                                Тут есть два варианта:
                                1) Тупой и упертый пользователь (еще хуже, с полномочиями)
                                2) безбашенный внедренец, которому на нужды пользователя плевать, а из аргументов у него ссылка на рекомендации всегалактической ассоциации сабаководов.

                                Оба варианта тупиковые и пагубные.

                                Да, некоторые «устоявшиеся» бизнес-процессы следовало бы и поломать… Что-то стандартизировать.
                                Но осознанно, и ни как иначе.
                                А это полноценное предпроектное обследование, документирование всех БП, подлежащих автоматизации, составление перечня рекомендаций и обязательное _письменное_ подтверждение со стороны заказчика готовности изменить что-то и как-то, и согласие его на то, что кнопка с надписью «Соль» теперь будет выдавать «сахар», несмотря на то, что на пиктограмме нарисована «гречка».

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

                                  так вот, у них и свой склад с запчастями, и учет ГСМ (весьма хитрожопый), и моточасы, и пробеги и еще миллион вещей, которых я уже и не помню, благо 4 года с тех пор прошло. они ведь тоже люди, хотят «нажми на кнопку, получишь результат» ;)
                                    0
                                    Согласен, удовлетворить финдепартамент обычно проще…
                                    Но это не значить, что нужно быстренько его удовлетворить, срубить денег и слинять…
                                    Если предприятие транспортное, то задачи «транспортного цеха» более важны для бизнеса, а финдепартамент только обслуживает трансплортные задачи.
                                    Обеспечивает правильные финансовые потоки…
                                    Такая же обслуга, как и наши ИТ, по большому счету.

                                    Опять приходим к правильной постановке ТЗ, поиску разумных компромисов и забегаем перед паровозом.

                                    Терпим и ждем статьи на тему постановки ТЗ ;)

                                    Я не хуже вас понимаю естественный антагонизм между заказчиком и внедренцем.
                                    Побывал по обе стороны фрона :)

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

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

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

                                      И с транспортными предприятиями я не сталкивался, слава б-гу ;)
                                        0
                                        Последовательность написания статей обсуждать не будем.
                                        Пройдено…

                                        Внедренцы ТЗ под себя не пишут, а только помогают заказчику правильно его поставить.
                                        Если это хорошие внедренцы, естественно ;)
                                        Если они действительно заинтересованы в том, чтобы заказчик получил хороший продукт, остался им доволен и после успешного внедрения остался на сопровождении, а в случае необходимости (когда и если) обратился за доработкой.
                                        Или же за новыми модулями, расширяющими функционал системы…
                                        Тот же SAP внедряется поэтапно, модульно и на следующий модуль можно пригласить совсем другого внедренца.

                                        Тут очень сложно выдержать баланс между интересами заказчика и своей головной болью…

                                        Приглашать же стороннего консультанта на постановку ТЗ, так же чревато, так как он может не знать всей специфики бизнеса и требований участников процесса…
                                        Либо его нужно посвящать в некоторые тонкости, в которые посторонним совать нос не следует…

                                        Но, похоже, я уже всунул свой пятак в чужой огород :)

                                        Давайте наберемся терпения и дождемся продолжения цикла…
                                        Мне-то написать полноценную статью не по силам…
                                        Я только короткие (почти) замечания и комментарии могу…
                                        +1
                                        Я намеренно сначала начал описывать именно тестирование, а затем уже разработку ТЗ на внедрение. Сначала нужно выбрать (и здесь тоже нужно фактически ТЗ, бизнес-кейсы, требования), а потом внедрять. ТЗ писать, все таки, должны внедренцы. В противном случае вы получите ситуацию, когда «писатели ТЗ» будут тыкать на внедренцев, а те наоборот.
                                          0
                                          Да.
                                          ТЗ — это документ, где формализованным языком описаны «хотелки» заказчика.
                                          Писать его должны внедренцы, но так, чтобы те, кто свои хотелки озвучивал, нашли их в этом ТЗ без посторонней помощи.

                                          Тот еще труд, должен заметить…
                                            0
                                            Да, непростая задача. Согласен
                                0
                                Коллеги, мне кажется это слишком суровый подход к своим пользователям, к себе и к продаванам. Гораздо проще и лучше в рамках написания того же ТЗ на подбор системы накидать N сценариев ключевых пользователей.
                                Выдать сценарии консалтам, дать тем недельку подготовиться, а затем с чувством с толком, расстановкой украсть у каждого из ключевых юзверей пол часа бесценного времени, на вдумчивое прохождение сценария вместе с консалтом и вами. Итого выходит сурьёзная экономия времени и нервов, а самое важное, вы будете проверять не абстрактные примеры, а вполне конкретные сценарии ваших бизнес-процессов.
                                  0
                                  Хочешь сделать важное дело как надо — сделай сам. Другим поручишь — они забьют или перепоручат третьим. В итоге «все хорошо, прекрасная маркиза!» и никто ни за что не отвечает.
                                    +1
                                    Друзья, вы начали обсуждать уже мой следующий топик (который будет после тестирования), посвященный внедрению. Повремените немного. :-)
                                      0
                                      Не готов я сам тестировать функционал предназначенный для менеджера по логистике — слишком много нюансов, все эти ожидаемые приходы, коносаменты, объёмный вес и палетная организация склада, не готов.
                                      Лучше я ключевого юзверя допеку и буду стоять у него над душой во время тестирования и задавать вопросы, но сам за это дело не возьмусь.
                                        0
                                        Самому за это дело браться и не нужно…
                                        Этим делом нужно руководить…
                                        Не командовать, а направлять.

                                        Сконцентрировать внимание ключевого пользователя, удержать его в рамках шагов данного теста, не дать ему углубиться и отклониться по дереву вариантов.
                                        И, самое главное, не дать внедренцу «зомбировать» ключевого пользователя, отвлечь его внимание от недостатков, замыли глаза «маркетоидными» терминами.
                                          0
                                          не готовы, не беритесь. Если подключать ключевых юзверей, тестирование можно не начинать, потому как оно ничем не закончится. Тут проблема в ответственности. Зачем она «юзверю»?
                                        0
                                        Вот этот обзор, о котором я писал в начале топика, он так и делался. Был разработан конкретный бизнес-кейс, где детально была описана определенная цепочка, по которой мы и тестировали все продукты. Выложу эту цепочку в одном из следующих топиков
                                          +1
                                          Надо было описание с этого и начинать, а то выглядит всё дилетантски — смотрим какие-то реквизиты форм, при этом совсем не очевидно, что они для нас являются ключевыми.
                                          ** Да здравствует системный поход к изложению материала ;)
                                            0
                                            Секондочку. Здесь речь идет о некоторых важных, но мелких, формальных тестах. Простых и формальных. Если их не получается проходить, нет смысла просто тратить время на проект. Вот и все. Прошли мелкие тесты, идем дальше, смотрим уже бизнес-процессы, думаем как это внедрять и т.д.
                                        0
                                        И будет чудом! если качество продуктов поднимется. Но хотя бы обмануть себя не дадим.
                                          +1
                                          А я считаю главное при выборе продута выбирать нужно не продукт а команду внедренцев — и если выбрать правильно, то не услышите от них «Это программа не умеет». Сам являюсь внедренцем и своим клиентам мы закрываем 100% их желаний, которые они могут выразить в письменном виде (это не шутка, добиться что бы клиент сам понял, что он хочет очень важно). Так же при внедрении того или иного функционала нужно понимать, зачем он нужен заказчику, т.к. часто заказчик просит что то сделать, что бы решить некую проблему, и если узнать, что это за проблема, то будет видно правильно ли заказчик выбрал путь ее решения.
                                          А по поводу перестройки бизнеспроцессов при внедрении — так их надо перестраивать, как правило одной из причин внедрения новой программы на предприятии, является желание навести порядок в бардаке, и если не сделать реинжиниринг бизнес-процессов, то в результате вы из простого бардака сделаете автоматизированный бардак
                                            0
                                            Вот как раз для того, чтобы защититься от «правильных» внедренцев, которые никогда честно не говорят «наш продукт вот этого не умеет и это нам надо разрабатывать» я и пишу эти статьи.

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

                                          Самое читаемое