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

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

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


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

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

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

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

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

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

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

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