Текст книги "Журнал PC Magazine/RE №05/2010"

Инфраструктура

СМБ: ERP из коробки
Заметки эксперта

Сергей Петров

Задумывая этот обзор, мы настраивались на рутинную работу: сбор программных пакетов, подготовку схемы тестирования, развертывание на стенде очередного программного комплекса и методичный запуск тестовых сценариев. Безусловно, были мысли, что не все просто, будут проблемы, но в пределах разумного. Не зря же редакционная почта полна пресс-релизами об очередном успешном внедрении, сразу решившем все проблемы компании-клиента? Да и сам рынок ERP – сектор довольно зрелый, многие его участники работают уже десятилетия. Казалось бы, логично ожидать, что в их программных продуктах реализовано все необходимое для автоматизации если не крупной транснациональной корпорации, то уж небольшой российской оптово-торговой компании наверняка. Мы ошибались.

Собственно проверки в том смысле, какой вкладывался в это слово на этапе подготовки проекта, не получилось. Дело не в серверах, не в ОС и не в БД. Главный итог почти полугодовой работы оказался таким: в большинстве случаев слова «внедрение ERP-системы» следует читать как «долгий и дорогой проект, который не всегда по силам небольшой компании».

Один из важных, почти философских, вопросов мира ERP – должна ли система сразу работать «из коробки» или доработка под каждый конкретный проект естественна для ERP-решения как феномена ИТ-бытия? Ответ зависит от точки зрения. Компания, заказавшая проект автоматизации на базе модной ERP, разумеется, ожидает как можно более быстрого запуска ее в работу и скорейшей отдачи от немалых (часто очень) сумм, потраченных на проект. (Особенно, если речь идет о сегменте СМБ, где с бюджетами всегда сложно.)

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

Споры не утихают и не утихнут, наверное, еще долго. Тем более что в бравурных пресс-релизах редко рассказывается о трудностях, которые пришлось преодолевать не только им, но и клиентам в ходе внедрения, – иногда даже складывается впечатление, что проблем как бы и не существует. Наверное, именно поэтому столкновение с жестокой реальностью заставляет компании обвинять разработчиков ERP-систем во всех грехах, а статистика успешных внедрений у многих лидеров этого рынка навевает ассоциации скорее с Ватерлоо, чем с Аустерлицем. Разработчики парируют – мол, клиенты сами виноваты, отказываясь от лучших мировых практик, воплощенных в их системах.

Яркий пример этой ситуации глобального недопонимания – недавнее исследование, проведенное аналитической компанией IDC по заказу Microsoft. Изучалась «зрелость внедрений ERP-систем» (не только от Microsoft) в российских компаниях, по завершении работ был созван специальный брифинг. Итоговый отчет содержал множество разнообразных цифр, главной из которых стала оценка: 38 % компаний недостаточно эффективно используют свои системы (имеют значение «индекса зрелости ERP-рынка Microsoft Dynamics ERP Index» ниже среднего показателя в 55 %). В кулуарах же всплывали более интересные данные: в частности, оказалось, что только 7 % компаний практически не прибегали к доработке систем в ходе внедрения. (Представитель Microsoft на вопрос, не думает ли он, что такой процент связан с отрывом ERP-систем от бизнес-реальности, заметил, что нет, не думает. А среди причин, по которым клиенты порой переписывают поставляемые продукты, он отметил «русский менталитет» программистов в штате компании-клиента, которые «все равно все перепишут и если совсем ничего не трогать, то не будет и конкурентных преимуществ». Неочевидные последствия такого «переписывания» – повышение цены технического сопровождения со стороны разработчика системы – остались за скобками.

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

Итак, предмет изучения – базовая функциональность систем автоматизации (насколько ко многим из них применим термин ERP – вопрос, опять же, дискуссионный). Мы никоим образом не возражали против доработок как таковых, но самое интересное – какие возможности система обеспечивает «из коробки», не будучи «перепиленной» разработчиками или внедренцами. Какова функциональность базовой конфигурации и как можно хотя бы примерно, оценить затраты ресурсов на доводку системы до рабочих кондиций?

Изначально для изучения были выбраны пакеты Microsoft Dynamics AX, Microsoft Dynamics NAV, «Галактика ERP», iScala, SAP Business One, продукты «1C» на базе «восьмой» платформы, пакеты Avarda, AVA ERP, Lawson Ms, Sage ERP X3. Выбор был продиктован скорее маркетинговой активностью компаний, чем какими-то специальными соображениями: примерно так же действует потенциальная компания-клиент, изучая специализированную прессу, Интернет, сайты компаний-разработчиков и их партнеров.

Как аксиома был принят тезис: «Тот, кто претендует на роль исполнителя, должен знать систему досконально».

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

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

(Заметим, что после знакомства с модельной задачей представители Avarda, iScala (Epicor) и Lawson M3 потеряли интерес к проекту, но мы бы не стали делать из этого факта какие-то выводы.)

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

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

«Галактика ERP»

«Корпорация Галактика», www.galaktika.ru

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

В целом «Галактика ERP» оставляет хорошее впечатление: сразу видно, что продукт проектировался с учетом российской действительности, в отличие от некоторых западных аналогов. По итогам изучения функциональности самая, пожалуй, серьезная проблема из отмеченных – сложности учета ГТД, если речь идет о товаре, учитываемом по серийным номерам.

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

Не обнаружена возможность наглядно оценить сводную потребность в закупках. Совершенно не очевидно, где менеджер по закупкам должен видеть, что ему следует закупать. Если менеджеру по продажам необходим конкретный товар – в рамках системы он не сможет сообщить об этом отделу закупок (придется пользоваться электронной почтой и другими каналами связи, что и рекомендовал консультант). То же касается рабочего места кладовщика: совершенно не ясно, где ему искать ожидаемые приходы и отгрузки. Здесь доработки будут необходимы.

Система закупок «под заказ», если судить по демонстрации в готовом к использованию виде, отсутствует. Это вообще «болезнь» почти всех рассмотренных решений, кроме AVA ERP и частично Dynamics AX (в Dynamics AX такая функция есть, но только при условии, что поставка пришла на склад, указанный менеджером при оформлении заказа). Модули, связанные с производством, оценить не удалось из-за отсутствия «специалиста, способного их показать».

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

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

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

Модельная задача

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

1. Создание клиента и поставщика.

1.1. Создание двух юридических лиц поставщика, выставление номеров счетов-фактур по каждой.

1.2. Создание клиента, имеющего два юридических лица.

2. Создание заказов (действия по п. 2 должны происходить в рамках одного проекта).

2.1. Создание «заказа № 1» – для юрлица № 1 от юрлица № 1. Заказ предполагает два наименования товара: «навигатор» (учитывается по серийным номерам производителя) и «тепловизор» (учитывается просто по количеству). На эту поставку предварительно должен быть заключен договор. Всего клиентом заказано пять навигаторов, три тепловизора. Один из навигаторов резервируем на «складе № 2», на остальные четыре оформляем заявку для закупки.

2.2. Создание «заказа № 2» – для юрлица № 2 от юрлица № 2. Заказ содержит позицию «эхолот» в количестве трех штук и «отмашка светоимпульсная» – пять штук. Эхолоты есть на складе, резервируем их. «Отмашка» изготавливается самостоятельно, формируем задание на производство (сборку).

2.3. «Отмашка» состоит из корпуса и фонаря. Их на складе нет, поэтому отправляем задание на закупку.

2.4. Выставляем счет клиенту. Или сначала выставляем счет, а затем резервируем уже по счету (в зависимости от подхода, принятого в системе).

2.5. Позиция «Навигатор» требует монтажа – будем монтировать его силами независимой организации.

3. Закупка.

3.1. Закупщик видит все, что нужно приобрести (четыре навигатора, четыре корпуса, четыре фонаря), и формирует два заказа поставщикам: «навигатор» и «корпус» в заданном количестве – одному, «фонарь» – другому.

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

3.3. При оформлении обязателен учет ГТД.

3.4. Затраты на доставку и таможенное оформление всех поставляемых товаров включаем в себестоимость.

3.5. Услуги доставки предоставляет сторонний логистический оператор, покупаем у него эти услуги для нашего юрлица № 2. Услуги таможенного оформления оказывает другая компания, таможенный брокер. Оплачиваем оба счета на доставку и таможню, при этом требуется контролировать задолженность контрагентов (т. е. помимо оплаты фиксировать и факт оказания услуг).

3.6. Фонарь покупаем в России, он российского производства.

4. Завершение процесса.

4.1. Менеджер по закупкам формирует распоряжение на прием всего закупаемого товара на склад № 2, чтобы кладовщик этого склада знал, что именно и когда ожидается. Затем все это нужно перевезти на склад № 1.

4.2. После перевозки отгружаем комплектующие для производства со склада № 1 и сдаем готовое изделие на склад (сам процесс производства не рассматривается).

4.3. Формируем распоряжение на отгрузку товара клиенту по обоим счетам (или заказам, в зависимости от принятых в системе практик).

4.4. Кладовщик соответствующего склада видит распоряжение и отгружает товар.

4.5. Получаем счета-фактуры и формы «торг-12» по обеим отгрузкам.

4.6. Заказываем монтажные работы на стороне, получаем счет от контрагента, оплачиваем его, принимаем работу.

4.7. Клиент оплачивает остаток.

5. Фиксируем отчетность.

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

5.2. Отчет «Движение денежных средств» (или аналог, имеющийся в системе): интересует возможность получения отчета в разрезе проекта. Также интересна возможность детализации показателей отчета в таких разрезах, как «клиент», «документ», «статья расходов», «менеджер».

5.3. Отчет «Баланс предприятия» (или аналог).

5.4. Отчеты, отражающие дебиторскую и кредитную отчетность, запасы, остатки денег на счетах.

Microsoft Dynamics NAV

Microsoft, www.microsoft.com/Rus/dynamics/nav/overview.mspx

Судя по описанию на сайте Microsoft, модельная задача должна была легко решиться средствами системы Microsoft Dynamics NAV, «интегрированной комплексной системы управления предприятием», «объединяющей возможности финансового управления, анализа состояния бизнеса, управления производством, дистрибуцией, электронной коммерцией и взаимоотношениями с клиентами». Тем более что «в России практика по данной системе развивается уже более 15 лет, с 1993 г. – с момента начала внедрения системы Navision Financials в российском представительстве компании Adidas. Microsoft Dynamics NAV известна также по ранее существовавшим названиям Microsoft Business Soluton – Navision, или просто Microsoft Navision (читается как „Навижн“)». Последние сомнения развеивает утверждение: «Microsoft Dynamics NAV – идеальное решение для компаний со сложными бизнес-процессами, нуждающихся в комплексной автоматизации. Оно весьма популярно на предприятиях из сферы торговли и дистрибуции, профессиональных услуг и производства». (Цитаты с официального сайта системы http://www.microsoft.com/Rus/dynamics/nav/overview.mspx.)

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

После выполнения первых шагов на бланке товарной накладной (форма «торг-12») в графе «Плательщик» почему-то появилось… название компании-клиента, а не актуального для сделки юридического лица. Весьма странно; если учесть, что название клиента – просто общее название партнера, как оно может фигурировать в официальных документах? Логично было попросить убрать эту оплошность и в качестве плательщика указать название юрлица, от которого оформляется платеж. Как выяснилось, сделать это можно. Однако данное юридическое лицо сразу превратилось в «автономное», разорвав все связи с тестовым клиентом. Иными словами, в реальной жизни, скорее всего, придется выбирать или отсутствие контроля финансовых показателей «по клиенту», или невозможность формировать из среды NAV первичные документы (при условии, что возникает задача, сходная с модельной).

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

Следующий шаг – закупили товар, но при попытке его отгрузить клиенту товара не оказалось на складе (хотя он только что был оприходован). Выяснилось, что система автоматически (!) списала его со склада. Комментарии консультантов сводились к тому, что такое поведение было результатом специальной настройки.

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

Система автоматизации для компании СМБ должна предоставлять полный набор функций и возможностей.

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

AVA ERP

AVA Systems, www.avasystems.ru

Компания AVA ERP за последние несколько месяцев прославилась рекламной кампанией «интегрированной ERP-системы за 50 тыс. руб.» (на таких условиях предлагается одна из версий системы, адресованная предприятиям СМБ). Слово «интегрированная» в этой рекламе следует понимать буквально: в системе есть практически все, от обязательной для ERP-функциональности до возможностей, о необходимости которых именно в ERP можно спорить (например, базовые средства управления проектами). Тем не менее наличие законченного набора функций в единой «коробке» вполне соответствует реальным потребностям СМБ. Изначально смущала лишь относительная молодость этого программного комплекса.

Систему демонстрировали представители компании-разработчика, а не партнеры-консультанты; по их данным, в России уже имеется около 30 реализованных проектов. Отметим не совсем типичный подход к распространению информации о системе, – в частности, вся документация (и для пользователя, и для администратора) есть на сайте компании, структура ценообразования вполне прозрачна, контакты существующих клиентов – доступны. (Удивительно, но такая, казалось бы, необходимая для принятия взвешенного и обоснованного решения информация не всегда предоставляется всем желающим; некоторые компании иногда скрывают даже снимки экрана своих систем!)

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

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

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

Продолжение следует