«Кот в мешке», или О пользе дотошности

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

Остановив свой выбор на довольно известном готовом решении, мы обратились в компанию Х. Руководитель отдела продаж задал вопросы про бюджет, количество документов за день в компании, и все. Было не очень понятно, как это проливает свет на потребности предприятия в автоматизации. Затем нам предложили заплатить за экспресс-обследование, которое, якобы, прольет свет на все. По причинам, описанным в предыдущей статье, от этого этапа мы отказались, предложив устроить полноценное тестирование системы по нашим функциональным требованиям. Конечно, мы не надеялись, что все до единого требования будут удовлетворены, поскольку идеальных систем не существует. Но чем больше пунктов, по которым система будет соответствовать требованиям, тем выше шансы, что компания-заказчик выберет именно ее.
Итак, для изучения системы были разработаны так называемые «кейсы», то есть реальные бизнес-процессы, по которым и тестировалась ERP.

Презентация
Чтобы компания могла подготовить презентацию, мы отправили им перечень наших требований. Первую презентацию проводил все тот же руководитель отдела продаж.
Представление длилось 4 часа, но вместо демонстрации «боевого» продукта мы видели только жестикулирование, слышали фразы типа «best practice» и тому подобное. В крайнем случае разрешалось посмотреть на названия пунктов меню. Как только мы просили продемонстрировать какой-либо процесс целиком, представитель старался перейти на другие темы или пытался сбить с толку непонятными фразами. Понятна ли она была представителю, также сомнительно. Первую презентацию руководитель отдела продаж покинул в удрученном состоянии, поскольку результат не был им достигнут: клиент не «клюнул».
На вторую презентацию вместе с продавцом приехал бизнес-консультант (подозреваю, только для того, чтобы произвести впечатление). Презентация длилась 8 часов и была очень похожа на первую. А теперь расскажу обо всем подробнее.

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

Работа с клиентами
Выяснилось, что организовать полноценную работу с клиентом по схеме «один клиент — несколько юридических лиц» возможным не представляется. Нам попытались «всучить» идею в качестве юридических лиц клиента использовать адреса, просто добавив к ним несколько «признаков». Кстати, случайно обнаружил, что этот горе-продукт оперирует ценами без НДС. Представляете, как это выглядит? Звонит вам клиент и спрашивает: «Сколько стоит товар?» Вы ему: «Сто рублей». «Отлично, — говорит клиент, — выставляйте счет». Вы ему счет, а там 118 руб. И чтобы сделать 100, придется подгонять цену без НДС к нужной величине. Видимо, в качестве бесплатного приложения к системе прилагаются калькуляторы, чтобы сподручнее было считать.
Контроль над дебиторской задолженностью очень оригинален. Вы готовите отгрузку (о том, как это делается — разговор отдельный), кладовщик полдня собирает заказ на складе, а когда нажимает кнопочку «отгрузить» — вот тут-то система и блокирует возможность отгрузки. Мне искренне жаль кладовщиков. Несколько сотен наименований они будут собирать по всему складу и упаковывать, а когда нажмут пресловутую кнопку, явно вспомнят не самым добрым словом многих родственников разработчиков вышеуказанной ERP-системы. Но эта проблема, по мнению консультанта (подчеркну, консультанта, то есть человека, который помогает правильно организовать бизнес-процессы) решается очень просто — надо дать возможность списывать товар со склада менеджерам по продажам. Вот такой дельный совет. Выписал менеджер сам счет, сам же отгрузил товар по программе. Это не важно, что кладовщик, несущий материальную ответственность за остатки, даже не в курсе, что у него товар списывают без его ведома.
Акты сверки с клиентами, и прочие «штучки», видимо, придется делать в Excel. О них этот продукт ничего не слышал.

Управление поставками
Возможность поставки под заказ отсутствует. Казалось бы, поставка под заказ — это когда вы резервируете товар для клиента и по приходу товара на склад клиент получает свой резерв на складе. В понимании консультантов компании X «поставка под заказ» — это когда вы в заказ поставщику переносите позиции из клиентского заказа. То, что нет никакой связи между поставкой и клиентом, и никто никакой резерв не получит — это стараются не афишировать. Зачем лишние неприятности во время презентации?
Говорить о том, что есть какая-то схема, позволяющая организовать полноценную систему управления цепочками поставок, не приходится. Ее просто нет.

Учет ГТД
На первой презентации его не было вообще. А ко второй презентации, понимая, что эта функция будет проверяться, «склепали» на коленке «заглушку». Итак, просим купить товар и указать в поставке ГТД. Указали. Потом делаем продажу и смотрим счет-фактуру. И вот тут самое интересное. Перед тем, как сделать отгрузку товара, консультант открыл какое-то средство доступа к серверу (что-то типа PL\SQL-девелопера) и запустил там процедуру минут на 10. После того, как процедура отработала, мы получили зеленый свет для отгрузки товара. Сделали отгрузку, в счет фактуре оказалась та самая ГТД. Страна, правда, другая… Но разве обратит внимание на этот «пустячок» потенциальный заказчик? Конечно, нет. Как это все будет работать в реальности, можете представить.
Учет затрат на поставку и включение их в себестоимость тоже реализован весьма оригинально. Сначала товар приходуется на склад, его уже можно продавать, но реальная себестоимость появится потом. Для этого бухгалтер должен занести эти затраты и привязать к правильной поставке. Как он узнает, к какой поставке привязать — это уже вопрос другой. Вероятно, ему об этом логист должен будет сообщить «на бумажке» (или по телефону). А товар к тому времени может быть уже продан. Кто догадается, что при такой схеме невозможно ни оценить потенциальную прибыль по сделке, ни ограничить менеджера по минимально возможной цене в зависимости от себестоимости? Когда вы смотрите на себестоимость товара в классификаторе, верить этой цифре нельзя, так как никто не знает, привязал ли бухгалтер затраты к поставкам, или нет. Консультанты компании X согласились, что вообще-то привязывать затраты к поставке должен логистик, а не бухгалтер, и не после прихода товар на склад, а до. Но согласились они с этим после долгих дебатов. Видимо, просто ни разу это не внедряли.

Планирование
Эта функция в тестируемой ERP-системе называется громким словом MRP. Ну, в смысле, пункт меню так называется. Просто многие клиенты слышали такую аббревиатуру, поэтому должны «клюнуть».
В реальности это работать не может. Оказывается, все предельно просто: вы создаете план продаж по товарным позициям на каждый месяц, а система вам предлагает это количество товара купить. Вот и все MRP. Реальные продажи, всякие там тренды, сезонность, сроки поставок, текущие поставки и прочая «ерунда» никак не учитываются. Кстати, страховые запасы вы создаете в штуках (а не в днях), да еще и для каждой товарной позиции отдельно. Если у вас их 20 000, сочувствую.
Вы не поверите, но я уже не думал, что сейчас еще есть какие-то программные продукты, где нет древовидного справочника товаров с возможностью навигации и т.д.! Что делать если у меня 20 000 наименований — неизвестно. Консультанты компании X сказали мне, что большинство клиентов не испытывают необходимости формирования древовидной структуры классификатора. Я не знаю, что тут можно обсуждать. Мониторинг истории себестоимости товара и ее анализа также невозможен.

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

Ценообразование
Конструктор скидок очень слабый, в компании, где более 1000 наименований и более 100 клиентов, скорее всего, неприменим. Организация распродаж невозможна. Скидки возможны только персонально для клиента, а не для категории клиентов. Нельзя настроить скидку для клиента (не говоря уже о группе клиентов) по определенной группе товаров. Приоритетность работы различных сценариев скидок определить нельзя. Настроить сценарии минимально возможных цен можно только на основании той самой псевдо-себестоимости, о которой было сказано выше. Гибко настроить эти правила по группам товаров и группам пользователей нельзя. Автоматическое регулирование отпускной цены при колебаниях себестоимости невозможно.

Сквозной учет
Пришлось поверить на слово консультантам, что сквозной учет товара есть, поскольку из интерфейса как-то проследить «судьбу» партии не представляется возможным.


Склад
Тут даже не знаю, с чего начать. Серийные номера изделий, похоже, учитываются. Резервирование товара на складе отсутствует. Под резервированием товара я подразумеваю возможность поставить товар в резерв, после чего свободный остаток на складе снизится. На вопрос, есть ли в системе резервирование, ответ был положительным. Видимо, у консультантов компании X свое представление об этом процессе. Они показали какую-то схему, но чтобы зарезервировать эту несчастную партию, ее для начала надо учитывать (я имею ввиду не внутренний партионный учет, а ручной учет партий, то есть их занесение, нумерация и т.д.), а во-вторых, открыть несколько форм, нажать кучу кнопок в определенной последовательности, и тогда, вроде бы, вы сможете зарезервировать часть этой партии. Что будет, если это огромное количество кнопок нажать в «неопределенной» последовательности, я проверять не стал. Представители к тому времени уже и так были весьма расстроены излишней дотошностью потенциального клиента.
Перемещение товара между складами делается одной операцией: в момент списания товара с одного склада он тут же оказывается на другом. Это ничего, что кладовщик склада-приемника ничего про это не знает. Товар на его склад приходуется кладовщиком, который отгрузил товар с первого склада. Хотя груз между складами в реальности может ехать несколько дней. Насчет работы со сканером штрих-кода сказали, что можно. Ну, раз сказали, значит можно. Процесс подбора товара на складе отсутствует. Учет товара на полках — бутафория, в виде признака в классификаторе. Реально положить товар вы можете на любую полку. А где его потом искать — посоветовали клеить бумажки на товар: «Остальные товары искать на такой-то полке».

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

Управление затратами
Опять же, системы нет. Нет даже статей затрат.
«Зато у нас есть система бюджетирования» — гордо сказали представители компании X. Как она работает, вдаваться было уже бессмысленно — после того как выяснилось, что возможность потратить деньги блокируется тогда, когда кассир проводит платеж, а не заранее. Как это «бюджетирование» настраивается, не уточняли. Сил уже не было.

Финансовая отчетность
Прибыли и убытки. Какие-то куски отчета были показаны, но увидеть нормально настроенный полный отчет не удалось. Представители начали рассказывать, что, мол, ну это же демо-версия, вы же понимаете, и т.д. Но ведь именно в демо-версии эти вещи должны работать как часы. А иначе как продавать продукт? Но даже продемонстрированные куски какому бы то ни было анализу не поддаются. Вы можете только увидеть цифру в отчете. Откуда эта цифра взялась — загадка.
Отчет о движении денежных средств не был показан вовсе. Какая-либо детализация финансовых показателей невозможна в принципе. То есть, понять, откуда взялась та или иная цифра, практически невозможно. Все отчеты показываются в виде конечных цифр, которым остается просто верить. Никакой детализации нет. Иными словами, все финансовые отчеты — это просто картинка. Как можно работать с такими цифрами?
Такая вот ERP система… Причем, узнав ее название, вы бы немало удивились.

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

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

Внедрение
Консультант должен поведать вам свое видение процесса внедрения системы. Его подход ко всему проекту должен быть вам понятен. В процессе внедрения всем должно быть ясно, за что отвечает исполнитель, а за что — заказчик. Кто конкретно со стороны заказчика отвечает за внедрение. Желательно составить календарный план внедрения проекта.
Попросите поставщика решения предоставить вам инструкции по работе в системе.
В этой части, как правило, у разработчиков огромные проблемы. Ну и к тому же это большое поле для зарабатывания денег на обучении ваших пользователей. Поэтому возьмите эти инструкции и поработайте в тестовой системе по ним. Постарайтесь понять, насколько они применимы в реальной жизни и насколько понятны. И если вам с серьезным видом будут рассказывать о том, что «мы в каждом случае разрабатываем отдельные инструкции», верить не рекомендую. Чушь полнейшая. Нет инструкций — готовьте деньги на обучение.

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