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

Моделирование бизнес-процессов: компания определяет желаемые или обязательные бизнес-процессы.

Составление карты процессов предприятия относительно процессов, поддерживаемых SAP: компания указывает стандартные процессы и функциональности SAP, которые отвечают требованиям смоделированных процессов.

Анализ пробелов: компания оценивает расхождения или пробелы между стандартной функциональностью SAP и требованиями смоделированных процессов.

Окончательное определение рамок проекта внедрения SAP: компания определяет рамки внедрения SAP, то есть указывает, какие процессы будут внедрены вместе с SAP.

Настройка системы SAP: компания конфигурирует базовые параметры SAP с помощью Руководства по внедрению, чтобы удовлетворить ранее установленным требованиям (см. раздел «Конфигурация через Руководство по внедрению» в главе 12). Все настройки осуществляются в клиенте 001.

Тестирование настроенной системы SAP: функциональность сконфигурированной системы тестируется с использованием реальных данных.

Обнаруженные пробелы в функциональности могут устраняться с помощью следующих мер:

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

Программирования желаемой функциональности в ERP через пользовательские настройки.

Установки дополнительных программных продуктов других фирм, сертифицированных на совместимость с системой SAP через Программу дополнительного программного обеспечения SAP (CSP).

Отложенного внедрения данной функциональности до внедрения следующей версии SAP или следующей модернизации, в которой данная функциональность будет предусмотрена.

Радикального изменения бизнес-процесса таким образом, чтобы он был совместим с функциональностью SAP и достижения того же самого результата.

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

В системе SAP предусмотрена полноценная среда R/3 Business Engineer для помощи при внедрении SAP. При моделировании бизнес-процессов SAP возможно использовать любой из следующих инструментов: IDS Sheer ARIS, Microsoft VISIO, IntelliCorp LiveModel и Enterprise Charter. Они базируются на Справочной модели R/3 и обеспечивают прямой интерфейс для взаимодействия с функциональностью системы R/3. Это значительно облегчает понимание системы, потому что позволяет начинать специфические транзакции SAP прямо из среды моделирования: с другой стороны, предоставленные этими системами модели процессов, обеспечивают полноценный контекст той или иной транзакции SAP.

Справочная модель R/3 и упомянутые выше инструменты используют рекомендованную SAP технологию моделирования, которая называется «Управляемая событиями последовательность процессов» (Event-Driven Process Chain, ЕРС). В своей основе эта технология моделирует процессы как упорядоченный набор процедур, которые запускаются событиями внутри системы. Эти события могут происходить в базах данных (например, обновление) или на экране - когда, например, пользователь выбирает пункт меню или нажимает ссылку на Web-странице.

Процедурная модель SAP

Это традиционная модель внедрения SAP, она полностью интегрирована с системой SAP. Эта модель была представлена в 1995 году, одновременно с системой SAP R/3 3.0. Иногда использование Процедурной модели SAP ставится под вопрос: возникает ощущение, что эта модель устарела, и от нее надо отказаться в пользу AcceleratedSAP. Однако надо учитывать, что методология AcceleratedSAP в основном рассчитана на средние и малые предприятия, в то время как для крупных компаний Процедурная модель SAP остается лучшей методологией внедрения SAP. Так как в этой книге мы в основном рассматриваем внедрение SAP для средних и малых предприятий, здесь я представлю краткое описание Процедурной модели SAP, которая идеально подходит для компаний с доходами от 1,2 млрд. долларов.

На рис. 5.8 схематически представлена Процедурная модель SAP.

Рис. 5.8. Процедурная модель SAP.

Процедурная модель SAP состоит их четырех фаз:

1. Организационный и концептуальный дизайн

Подготовка проекта

Организация среды разработки

Обучение команды проекта

Определение функций и процессов

Определение интерфейсов и усовершенствований

Концептуальный дизайн и организация проверки качества.

2. Детальный дизайн и установка системы

Конфигурация основных параметров

Установка организационной структуры

Подготовка основных данных

Конфигурация процессов и функций

Внедрение интерфейсов и усовершенствований

Установка отчетности

Организация управления архивами данных

Последнее тестирование

Детальный дизайн и установка системы для проверки качества.

3. Подготовка к запуску

Создание пользовательской документации

Данная заметка адресуется бизнесу, заказчикам, которые начинают думать о внедрении новой системы, будь то SAP или не SAP. Мне удалось поработать со стороны заказчика, со стороны консалтинга (не только SAP), что дает чуть более широкое понимание проблем с обеих сторон. Хочу также отметить, что проблемы, или, давайте назовем это задачами, одинаковые для любой страны. Я могу судить по работе на проектах в США, Норвегии, Венгрии, России. Исключительно мой опыт.

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

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

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

Методология это самый большой объем работы на проекте. Скажу по секрету, что часто говорят о необходимости унифицировать процессы, а на практике процессы занимают процентов 10 от реальной работы по унификации. Основное это бумажки и расчеты, и зачастую это связано с требованиями законодательства, в то время как процессы практически не регламентируются законами. Под методологией я понимаю алгоритмы расчета тех или иных величин, правила заполнения отчетов и выходных форм. На входе в проект заказчик любит оперировать цифрами 80/20, 70/30 или иными конкретными величинами измеряющими результат унификации. С одной стороны какая разница сколько будет видов оплаты, ведь это всего лишь справочник? А с другой стороны необходимо на всех уровнях понимать что такое фонд оплаты труда, что такое затраты на персонал (это понятие обычно шире, чем фонд оплаты труда). В моем понимании идеальная унификация стремится к нулю, к упрощению до максимального уровня, не противоречащего закону и целям бизнеса.

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

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

План мероприятий по подготовке к проекту внедрения SAP HCM

Сломайте, чтобы построить. Этот подход часто используется в задачах по построению интеграции между системами. Отключите одну систему и посмотрите, что произойдет. Если ничего не произойдет, то эта система или связь не нужны. На практике это означает планомерное отключение (избавление) шагов по передаче отчетов из одного подразделения в другое, сокращение использования тех или иных справочников (виды оплаты, графики, временные данные, НСИ). Очень часто при новом внедрении системы бизнес хочет перенести все что есть. Но никто не может сказать для чего. Множество аналитик были реализованы по тем или иным причинам годы назад для конкретного случая, который уже неактуален, но эту аналитику все еще продолжают заполнять по инерции. Какие управленческие решения принимаются сегодня на основании этой аналитики?

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

Процессы . Пожалуй это самое популярное слово при внедрении. Все хотят упростить, унифицировать процессы. Если посмотреть на процессы после внедрения SAP и до, то отличий будет не так много, сколько было шума вокруг этого. Унифицировать процессы без привязки к системе очень просто. Берем самый простой вариант процесса и самый сложный (как выше в примере с заводом и продавцами). Смотрим чем они отличаются (с большой степенью вероятности отличия будут в количестве коммуникаций и выходных формах), приводим процессы к наисложнейшему по всем предприятиям. А потом откусываем шаги согласно первому принципу «сломайте, чтобы построить». Не нужно строить красивых диаграмм и поэм - в реальной повседневной жизни никто не заглядывает в эти многотомники. Простая табличка в Excel поможет.

Бумажки . Вторая после методологии больная тема. Бумажки это все то, что не нужно закону. В одной компании был проведен эксперимент с изъятием принтеров. Люди физически не могли напечатать документы. Через полгода количество документов по электронной почте сократилось в разы. Вместо «где отчет?» стал возникать вопрос «где посмотреть?». Я верю, что есть документы, которые нельзя унифицировать. Например, дополнительные соглашения к трудовым договорам. Достаточно переработать документы по наиболее массовым случаям и их унифицировать и автоматизировать. Все остальное вынести за рамки проекта и унификации как в ситуации с премией за результат. При массовом подборе и найме в розничном бизнесе документы легко унифицируются и автоматизируются, но зачем это делать для промышленных гигантов?

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

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

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

Для чего проект разделен на фазы, и каким принципом, как правило, руководствуются при дроблении проекта по фазам?

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

Создание проектного офиса

Первая и, как правило, самая короткая фаза проекта. Очень часто её название вводит в «ступор» заказчика. Однажды, когда я имел честь работать во внутренней команде одного бравого металлургического предприятия, со стороны ТОП-менеджмента звучали довольно ехидные вопросы: «А что, на этом этапе они стулья расставлять будут?».

На самом деле, конечно же, в данном случае расставляются не стулья и даже не столы. Продуктом данной фазы проекта на самом деле являются основные документы по управлению проектом: приказ о начале проекта, устав проекта, подробный календарный план, план управления рисками, план коммуникаций и т.д.

Часто название фазы выбирают другим, мне лично нравится именно это, т.к. на самом деле максимально отвечает содержанию.

Обследование

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

Лучшей практикой считается подготовка описания бизнес-процессов в виде диаграмм в каком-либо CASE-продукте. Такую схему называют «Схема бизнес-процессов «Как есть (AS-IS)». Но, к сожалению, из-за дороговизны программных продуктов, а также низкой востребованностью со стороны заказчика, эта технология очень редко используется на проектах. А жаль, ведь её использование позволяет производить различные аналитические заключения о состоянии бизнес-процессов, производить оптимизацию и, самое главное, в дальнейшем при концептуальном проектировании и построении модели «Как должно быть» (TO-BE) позволяет производить сравнительный анализ, т.е. позволяет прогнозировать выгоды от внедрения ERP-системы. Результатом данной фазы также зачастую является уточненное техническое задание.

Концептуальное проектирование (модель TO-BE)

Фаза Концептуального проектирования на самом деле должна включать в себя и работы, проводимые на фазе Обследование, но с точки зрения управления проектом, а в особенности бюджетом и сроками, я считаю их лучше разделить. Дело в том, что на фазе обследования подрядчику уже может стать ясной необходимость корректировки календарного плана и состава работ, вопрос об этом должен быть вынесен на обсуждение и приняты соответствующие меры. Если этого не сделать на данном этапе, то сделать потом практически невозможно (хотя и в данном случае необходимо проявить чудеса дипломатии).

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

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

Реализация

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

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

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

Первоначальная поддержка

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

Известно, что маркетинговые заявления вендоров порой серьезно расходятся с реальностью. Однако, принято считать, что авторитетные игроки рынка к подобной практике не прибегают. Однако, руководитель проекта внедрения SAP Business One в небольшой российской компании на личном опыте убедился, что «ничто человеческое не чуждо» и респектабельным компаниям.

Грани выживания

Несколько лет назад практически все мировые разработчики ERP-систем начали движение в сторону сегмента СМБ, который был объявлен чуть ли не самым перспективным и приоритетным. На рынок были представлены новые продукты, ориентированные на небольшие компании, с небольшими бюджетами на ИТ. Не стал исключением и российский рынок бизнес-приложений. В отечественной прессе появились убедительные статьи, информирующие российских бизнесменов о том, что в условиях ужесточающейся конкуренции (в том числе, при вступлении в ВТО) они не смогут выжить, если у них не будет современной, автоматизированной системы управленческого учета, планирования и контроля. Приводимые доводы были вполне убедительны. В результате руководство многих средних и малых предприятий России всерьез задумалось о переходе «на что-то лучшее, чем Excel и 1С». Наша компания также принадлежит к сегменту СМБ и в силу указанных выше факторов, приняла предложение одного из партнеров корпорации SAP на внедрение тогда нового для рынка продукта - SAP Business One (B1).

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

Вот - новый поворот

Компания SAP не стала исключение в мировой гонке за предприятиями СМБ и несколько лет назад заявила о «серьезных изменениях в продуктовом портфеле компании» и решении совершить «тотальный разворот в сторону рынка СМБ» и включить в свою продуктовую линейку решение, ориентированное на небольшие развивающиеся компании. Более того, было объявлено, что рынок решений для СМБ является одним из приоритетных для компании SAP. Управляющий директор SAP СНГ Алексей Шлыков тогда прокомментировал этот шаг так: «SAP вовремя распознала момент, когда рынок крупного бизнеса, на которые, прежде всего, были ориентированы бизнес-приложения компании, оказался близок к насыщению, и пришло время искать следующие рынки сбыта».

В результате в 2003 году на российский рынок была выведена локализованная версия SAP Business One - решения, принципиально отличающегося от того, чем SAP занималась раньше. Впрочем, SAP Business One не является разработкой немецкой компании: продукт был приобретен у израильских разработчиков. Любопытно, что выход SAP Business One не сопровождался масштабными рекламными кампаниями - все усилия по продвижению вылились в несколько информационных статей в прессе и серию региональных семинаров, которые для потенциальных клиентов организовывали партнеры SAP. Также было официально объявлено, что стоимость одного рабочего места «под ключ» (лицензии плюс консалтинг по внедрению) составит €2500–€3000, а продолжительность внедрения не будет превышать 8 недель. Кроме того, было известно, что продукт имеет одно существенное преимущество по сравнению с альтернативными предложениями – он настраивается, его не надо программировать, в отличие от решений «1С», и он уже содержит готовые бизнес-процессы.

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

Суровая реальность

После трех месяцев внедрения стало понятно, что функциональность SAP Business One откровенно недостаточна для ведения даже небольшого (70 сотрудников) бизнеса в российских условиях. Почему мы этого не поняли раньше? Сложный вопрос.

Продукт, как нам сказали, на то и ориентирован на рынок СМБ, чтобы не втягивать компании в долгий этап обследования с последующим многотомным техническим заданием. В результате после этапа тестирования настроенного продукта мы столкнулись со списком «багов» на три с лишним листа, причем таких, без исправления которых переводить систему в рабочее состояние просто бессмысленно. Часть из них касалась именно ошибок в работе продукта, другая же касалась проблем недостаточности функционала решения. По составленному нами списку компания-внедренец была готова «доработать» около 30% требований, остальные же изменить без участия SAP было невозможно, потому что код продукта закрыт. Реализация тех «доработок», которые способен выполнить партнер своими силами, увеличила стоимость проекта сразу вдвое. Мотивировалось это тем, что «продукт нужно доработать в соответствие со спецификой бизнес-процессов». При этом, доработки действительно были необходимы, но только не под нашу «специфику», а просто, чтобы реализовать в продукте, в общем-то, стандартную модель ведения бизнеса. Никаких необычных требований с нашей стороны не предъявлялось.

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

Необходимо также отметить несколько серьезных недостатков SAP Business One, которые на первых презентациях неочевидны, а «всплывают» только в процессе:

• семантика БД системы практически не описана;
• хранимых процедур практически нет;
• система медленная и ресурсоемкая;
• отсутствуют печатные формы, соответствующие российским стандартам учета;
• не реализована функция резервирования (например, продукции) ;
• не реализован учет основных средств;
• не реализован учет расчетов с подотчетными лицами;
• некорректно реализован учет платежей;
• отсутствует возможность отнесения прямых и косвенных затрат на себестоимость продукции;
• не реализована подержка ячеистого склада, невозможно вести учет в разрезе партий товаров;
• не реализована возможность вести приход партии по разным ценам;
• MRP не работает в разрезе склада.

При этом, SAP Business One начисляет суммовые разницы только в национальной валюте, отчет по суммовым разницам составляется, исходя из курса на сегодняшний день, что приводит к некорректному начислению суммовых разниц при платежах.

Перечисленные «недоработки» вообще делают невозможным предоставление корректной информации о деятельности компании. При этом не вполне понятно, как в таком случае можно позиционировать SAP Business One в качестве системы управленческого учета. Розница, оптовая торговля и другой быстроразвивающийся бизнес с этой системой работать не сможет в силу ограничений ее производительности. Сохранение документа с 40-50 позициями приводит систему в ступор. Если таких документов будет хотя бы 200-300 в день, то все просто перестает работать.

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

Из разговора с компанией-внедренцем мы узнали, что SAP, вообще говоря, вынуждает партнеров самостоятельно дорабатывать функционал и писать так называемые add-ons (дополнительные компоненты). Эти компоненты можно также получить в готовом виде на коммерческой основе у других партнеров, которые уже реализовали данную функциональность. Например, для учета операций с основными средствами требуется купить соответствующий add-on, то же самое, если мы хотим вести учет фактических и плановых затрат, другой отдельный модуль предназначен для стыковки решения с системой банк-клиент. Кроме того, что стоимость проекта увеличивается, есть еще одна сторона: если мы покупаем add-on у другой компании, то нам надо либо привлекать их к внедрению за, опять-таки, дополнительные деньги, либо наш партнер-внедренец будет разбираться с этим самостоятельно, но тоже не бесплатно. Фактически, получается своеобразная «пирамида», которая разрастается тем сильнее, чем более широкая функциональность требуется предприятию.

Продать и забыть?

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

Сразу скажу, что ни один из указанных нами пунктов не был исправлен. Вместо этого была долгая переписка партнера с ответственными лицами SAP, которую, в конце концов, нам партнер даже показал. Большая часть ответов (вежливые, но короткие отписки с паузой в неделю) сводилась к тому, что о том или ином «баге» они прекрасно знают и активно над этим работают, так как не мы одни на это жалуемся. Практически все запрашиваемые нами моменты якобы исправлялись в новой версии SAP Business One. Которую мы ожидаем уже около полутора лет.

В результате, у нас сложилось мнение, что продемонстрированная «техническая поддержка» отражает общий подход вендора к бизнесу с предприятиями СМБ. Компания SAP в России ориентирована именно на крупных клиентов, потому что они имеют возможность инвестировать в проект неопределенное количество времени и средств. А вот СМБ бесконечно ждать не может и «кормить» консультантов SAP все это время - тоже. Более того, судя по «оперативности» и «содержательности» ответов на наши запросы, сложилось впечатление, что SAP заинтересована только в продаже лицензий, а конкретно по продукту ничего не делается. Примечателен и тот факт, как часто меняются в SAP люди, ответственные за клиентов по SAP Business One. Часть из них после старта проекта SAP для СМБ очень быстро переключилась с решения вопросов по продвижению SAP Business One на создание собственной карьеры внутри SAP, другая часть перешла в другие компании.

Арифметика маркетинга

Особый шарм маркетологам SAP-а придает заявление «SAP Business One - это система для управленческого учета». Повторюсь, какой может быть учет, если система не в состоянии предоставить истинную информацию о деятельности предприятия? Если система «со скрипом натягивается на бизнес» несчастными партнерами, которые просто вынуждены загонять компанию в рамки этого «решения»?

С самого начала запуска продукта SAP Business One на российский рынок было заявлено, что это решение для среднего и малого бизнеса. Так ли это на самом деле? Самой компанией SAP в СМИ была заявлена стоимость 1 рабочего места «под ключ» (то есть лицензия + внедрение) - около €2,5-€3 тыс. Кроме того, было объявлено (как преимущество продукта), что цена – конечная.

Для того чтобы действительно автоматизировать ключевые бизнес-процессы в небольшой компании, скажем со штатом 100-200 человек (финансы, продажи, склад, закупки), необходимо приобрести порядка 10-15 АРМ. То есть, рассчитывать надо на сумму порядка €30-€45 тыс. Как показывает практика, собственники российских небольших компаний, которые зарабатывают каждую свою копейку «потом и кровью», не так-то просто выплатят 30 тысяч евро/долларов за «софт». Тем более что налоговый учет и бухгалтерию в системе вести невозможно и, как минимум, «1С: Бухгалтерия» все равно будет нужна. Более того, если присмотреться к уже объявленным внедрениям, то видно, что полноценные проекты - редкое исключение и речь, как правило, идет о 3-5 лицензиях. Выводы напрашиваются сами собой.

Таким образом, по нашему опыту, SAP Business One может работать при условии существования не более 10 пользователей, в компании, где нет полноценного склада продукции, при этом может обрабатываться реально не более 2-3 заказов продукции в день. Возникает вопрос: «А нужна ли такая система небольшой развивающейся компании по две с лишним тысячи евро за рабочее место? Зачем, если на таком уровне достаточно использовать просто Excel?».

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

Если же говорить конкретно о российской действительности, то, может, причина в том, что последние 10 лет SAP здесь существовал в слишком комфортных условиях? Достаточно вспомнить даже официальные суммы инвестиций в ИТ наших промышленных монстров. И когда дело дошло до реальных действий, нормального развития и продвижения конкретного продукта, возможно, здесь потребовались навыки и компетенция, которые не требовались раньше? И проекты стали более прозрачными и теперь уже не так просто замолчать проблемы, как в масштабных внедрениях, где слишком много задействовано интересов, чтобы подвергнуть неприглядные результаты огласке.

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

Кстати, дополнительно об этой позиции SAP: на «круглом столе» 15 ноября 2006 года было официально объявлено о новых подходах к работе с партнерами, работающими с СМБ. SAP заявляет, что внедрение продуктов будет полностью осуществляться партнерами. А сам вендор «будет осуществлять общее руководство и размещение заказов». Что ж, позиция вполне логична, с точки зрения полного снятия с себя ответственности за результат проекта. То есть, с одной стороны, для российских руководителей за принятие решения о покупке ПО будет аргумент о солидности бренда разработчика, с другой же стороны, заказчики «один на один» останутся с партнером. А последний, в свою очередь, - «один на один» с продуктом. Если Вы еще сомневаетесь внедрять или не внедрять SAP Business One, постарайтесь поговорить напрямую с собственником компании, в которой якобы работает это решение. Попробуйте также задать менеджеру по продажам решения SAP Business One хотя бы часть из тех вопросов, что были подняты в этой статье.

Владлен Татарский