ERP- и WMS-системы: топка для банкнот или двигатель прогресса?

Сергей Муратов,
генеральный директор MCTLab

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

Разрушим до основанья, а затем?

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

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

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

Комментарий
Андрей Шекин , USN Projects

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

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

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

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

Кроме того, чтобы у заказчика не трещал по швам бюджет, у него всегда есть выбор: заключать контракты по схеме \"fix price\" или \"time&material\". Если консалтинговая компания не уверена в своих возможностях, то вряд ли она согласится работать на условиях фиксированных сроков и бюджетов.

«А заглянешь в душу – обыкновенный крокодил!»

Такой фразой герой Жарова в фильме «Медведь» описывал обманчивость женской натуры. Натура продавца компьютерных программ не менее обманчива.

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

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

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

Поставщик, накажи себя сам!
Или «за что я вам деньги плачу, дармоеды?!»

Сегодня чаще всего ТЗ поручают разрабатывать самому поставщику, причем после того, когда он определен. Это не есть хорошо. Мы верим, что есть реальные энтузиасты и профессиональные консультанты, однако не факт, что они достанутся именно вам.

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

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

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

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

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

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

Хороший контракт юрист не сделает

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

Результаты внедрения в договоре должны быть сформулированы в терминах бизнеса, а не компьютерных технологий. Например, вместо формулировки «Система должна автоматизировать заказ товара» лучше написать «Регистрация заявки покупателя должна занимать не более 20 секунд”.

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

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

дата: 00.00.0000 00:00:00 просмотров: 1239

рейтинг:

(Нет голосов)