На рынке комплексной автоматизации складывается ситуация, когда заказчики вынуждены покупать не проекты, которые обеспечивают рост производительности труда, транспарентность управления и, в конечном счете, эффективность, а какие-то эфемерные услуги якобы автоматизации. В чем причины?
В данном случае под комплексной автоматизацией понимается процесс, когда в цифру переводится более трех взаимосвязанных бизнес-процессов, и мы смело можем употреблять термин ERP-автоматизация. Как правило, на рынке данных услуг, с одной стороны, продавцами выступают консалтинговые фирмы-интеграторы, а с другой – реальный бизнес (крупные холдинги, промышленные предприятия). Продавцы обычно предлагают различные типовые (готовые) информационные конфигурации – технологические решения по автоматизации реальных бизнес-процессов покупателей. Однако на этом рынке существует несколько не изжитых детских проблем, присущих именно отечественному менталитету.
Две проблемы автоматизации
Первая проблема при продаже проекта комплексной автоматизации состоит в том, что типовые решения зачастую «не ложатся» на реальные условия организации бизнеса. Тем самым затрудняется распространение и отладка лучших проектных практик и тормозится технологическое развитие в общем, увеличивается отставание от Запада. Однако дополнительная кастомизация стоит дорого и требует дорогостоящей поддержки. Любая индивидуальная разработка (доработка) кода лишает основного преимущества IT-индустрии – эффекта от масштаба (тиражирования). Чем больше продано лицензий (коробок) – тем меньше накладные затраты на единицу – тем выше маржа.
Второй минус кастомизации – это увеличение трудозатрат при стандартных обновлениях продукта, которые предлагает вендор. Очень часто дополнительные доработки «затираются» при обновлениях программ.
Таким образом, возможности адаптивной доработки кода стандартных типовых конфигураций являются для заказчиков привлекательным решением, но таят в себе медвежью услугу.
Две стратегии автоматизации
Можно и даже нужно процесс комплексной автоматизации рассматривать как полноценный инвестиционный проект, который для бизнеса должен принести явно измеримые выгоды. Поэтому консалтеры и покупатели используют две основных стратегии автоматизации бизнеса.
Первая стратегия:
- Этап первый: обследование бизнеса заказчика. Бизнес-процессы проецируются на типовые решения (конфигурации). Составляется перечень доработок кода «под заказчика».
- Этап второй: оценка проекта. Принимаются решения о доработке – либо бизнес-процессов под типовые решения выбранной конфигурации, либо кастомизации кода под процессы заказчика.
- Этап третий: реализация проекта. Здесь сосредотачивается собственно процесс автоматизации бизнеса со всеми стандартными манипуляциями (обучение, перегрузка наполнения, опытная эксплуатация и прочее).
Вторая стратегия: все то же самое, но без второго этапа. Либо во втором этапе принимается решение о доработке кода и только. Подавляющее большинство использует вторую стратегию. Почему? – спросите вы. Отвечу!
Необходимо осознавать преемственность агентов на рынке и кадровую специфику в стане консалтеров-автоматизаторов. Традиционно в таких фирмах ценились в первую очередь специалисты, которые умеют работать с кодом. А специалисты с сильным бэкграундом в бизнесе, которые могут предложить изменить архитектуру бизнеса – это не только очень редкие, но и очень дорогие кадры. Как правило, грамотно продать целевую картину может человек, который лично проходил через аналогичные преобразования и имеет опыт антикризисного управления. Объективно затраты на такого рода услуги очень велики.
С другой стороны, топ-менеджерам отечественных предприятий уютно в своих креслах и нет стимулов к управлению изменениями. Зачем меняться самим – когда это могут сделать другие (все остальные)? Отсюда и нет спроса на такой вид услуги, как реинжиниринг бизнес-процессов, в том числе под их автоматизацию.
Неразлучные проекты
Оптимизация и реинжиниринг бизнес-процессов при автоматизации бизнеса – это главный залог окупаемости проектов ERP-автоматизации. Эти проекты должны быть неразлучны, и вот почему.
Во-первых, в реализации таких проектов всегда присутствует первый этап – описание всех бизнес-процессов. И второй раз на это тратить деньги не надо.
Во-вторых, переход на цифру заставляет персонал на местах учиться и меняться. Это тоже можно использовать, чтобы не «кошмарить» персонал дважды.
И наконец, любая автоматизация – это процесс, который сам по себе не упрощает и, соответственно, не удешевляет бизнес. Любой опытный менеджер понимает: проще и дешевле работать вообще без документов, подписей, бланков, регламентов, законов, надзора.
И, нужно помнить, что продать проект ERP-автоматизации – это значит продать точную цифру NPV от проекта заказчику. А как ее сможет подсчитать консалтер-автоматизатор без сравнительного анализа альтернатив проекта? По-хорошему, нужно сопоставить минимум два управленческих сценария: без оптимизации бизнес-процессов и с таковой.
Так и получается ситуация, когда заказчики вынуждены покупать эти самые эфемерные услуги якобы автоматизации. Заказчиков, идущих на поводу у таких автоматизаторов, уже в ходе работы ожидает целый букет неприятных сюрпризов. Например, удорожание проекта с вываливанием дополнительных объемов работ, задержки по срокам, недостаточная подготовка бизнес-процессов к опытной эксплуатации ИС.
Вдобавок, излишнее увлечение доработками кода консервирует практики управления отечественным бизнесом и не способствует развитию культуры повышения производительности труда.
А зарубежные практики управления доказывают, что будущее бизнеса – это унификация, стандартизация и, наконец, так называемая макдональдизация. Потеря уникальности архитектуры управления сегодня уже не является трагедией. Можно долго держаться за устаревшие практики, но, в конечном счете, побеждает эффективность.
Удачных отраслевых очень мало....Не программа (одежа) делает фирму (человеков) - а наоборот.
Соглашусь, существует множество решений класса ERP/MIS, предназаначенных для конкретных отраслей. Лучше практики реализованы и опробованы на примере десятков проектов. Если компания изначально согласна перенимать лучший опыт и идет данным путем - бизнес-процессы будут меняться, но форма "to be" уже известна по ключевым вопросам.
Вот прямо вынуждены? То есть заказчики не хотят, плачут, колются, но все равно покупают проекты по автоматизации? Да еще и эфемерные? Да еще и якобы автоматизации? Эх… Причина, видимо, в том, что вам просто фатально везет с клиентами! Обычно они ведут себя с точностью до наоборот. Считают, что автоматизация не панацея в области повышения эффективности управления и у них есть всегда выбор; что в проектах требуется специфицировать результат и прописывать дорожную карту его достижения, а уж о том, чтобы там было бы что-то «якобы» автоматизировано, так это вообще не проходит. Но это шутки, конечно. Если серьезно…
Чтобы заказчики знали, что они покупают, продавец должен знать, что он продает:) Вы, безусловно, вольны понимать под комплексной автоматизацией «более трех бизнес-процессов», но вот смело в этой связи употребить термин ERP-автоматизации вы не можете (извините). Я не к словам придираюсь, тут сущностная, на мой взгляд ошибка. И вот почему.
После того, как термин ERP «пошел в народ», он как-то неприлично оброс мифами и легендами. Дескать, любая солидная фирма должна ее (ерп-систему) себе внедрить. Но давайте простыми словами скажем, что такое ERP. Без туманностей и завирания. В середине 20 века для управления ПРОИЗВОДСТВЕННЫМИ предприятиями возник метод ПЛАНИРОВАНИЯ ПОТРЕБНОСТЕЙ ПРОИЗВОДСТВА - чего и сколько надо, чтобы что-то запланированное произвести – сколько гвоздей, металла, краски… Такой метод ПЛАНИРОВАНИЯ описали и назвали его Material Requirements Planning (MRP). А дальше понеслось…
К планированию материалов прибавили планирование финансов. То есть не просто чего надо купить, но и сколько надо денег на все эти гвозди и краски. И назвали это MRP II.
А потом к материалами и финансам добавили управление людьми и прочими активами и назвали это уже ERP-стратегией. Когда, кроме материалов и денег, мы включаем в контур планирования еще и людей, которые должны запланированные нами гвозди забить, красками покрасить, при этом учитываем их квалификацию, и еще, и еще, и еще…
И на этом все! Не надо морочить людям голову! ЕРП – это не консалтинговая или ИТ-шная магия. Это всего лишь способ планирования потребностей (тех или иных) предприятия. Причем тут количество процессов… Я не понимаю, извините:(
Почему я докопалась до вас с этим определением ? Чтобы пояснить, что же именно «покупают заказчики». И если говорить об этом с точи зрения менеджмента, то чем дальше, тем меньше это (ERP) ему (менеджменту) нужно. То есть с идеей полезности ERP-решений все еще продолжают носиться, поскольку это еще приносит какие-то деньги, но важно понимать, что этот слон уже умер. Да, он еще не разложился и не начал дурно пахнуть… Некоторые даже уверяют, что он лишь спит («вы просто неправильно ее внедряете», «вы просто выбрали не того подрядчика или не ту стратегию внедрения»). Но главное, что этот слон уже взаправду мертв. И уже никогда не проснется. А мы все пошли дальше. Некоторым пришлось это делать не все по своей воле, ведь многие слона успели полюбить, выдрессировать, просто-таки сродниться с ним всей душой...
О чем я говорю? Средний срок внедрения полноценной ERP-системы- 2 года. В 50-х годах 20 века это было норм. Да и производство было ключевым драйвером экономического роста. Сейчас мы с вами живем в постиндустриальном обществе, где основной доход находится не у того, кто собирает айфон, и уже даже не у того, кто его придумал, а уже у того, кто придумал, как его прикольнее использовать. За два года умирают и рождаются рынки. А мы планируем зафиксировать и автоматизировать «минимум три процесса» в этих временных рамках?
Как это отражается на заказчиках проектов по внедрению ERP? Они офигивают! Они не понимаю, почему кучу всего можно скачать из плеймаркета, а ERP нельзя? В чем конкретно проблема? – спрашивает у меня какой-нибудь 24-летний генеральный директор. И как ему объяснить, что это так долго, дорого и неэффективно, потому что именно это и есть круто и по-взрослому? Да и в общей массе народ потихоньку догоняет до того темпа, который раньше был свойственен новаторам исключительно.
Руководитель хочет решение сейчас! Нет. Хуже. Он хочет уже не решение. Он хочет СРАЗУ результат. Помните, лет 5-7 назад одна из самых популярных идей для продвижения ИТ-продуктов была про мобильность? «Сидите на пляже на Бали и управляйте своими серверами»? Сейчас эта идея трансформировалась в «отдыхайте на Бали! И не думайте о ваших серверах».
Если под качеством понимать соответствие ожиданий Заказчика фактическому результату, то в текущих условиях добиться каких-то кардинальных улучшений в применении ERP-систем невозможно. И не потому, что они плохие. Просто кардинально изменились требования к качеству решений.
И еще.
Главный залог «окупаемости» проектов ERP-автоматизации – это умение закончить его в запланированное время, в запланированных функциональных рамках и с обозначенными на старте трудовыми ресурсами.
Что до реинжиниринга и повторной траты денег, то тут у вас, как мне кажется, опять что-то не то на уровне матчасти.
Совмещение «реинжениринга» и автоматизации – это штука совершенно убийственная, на мой взгляд. Автоматизация предполагает четкое и ясное описание того, чтобы будет этой автоматизации подвергнуто. А когда вы вписываете заказчика в процесс трансформации его привычных регламентов работы, что вы будете отражать в автоматизированной системе? Состояние неопределенности? 33 точки зрения на процесс принятия решения по второстепенным вопросам? Суммируя риски проекта по организационным изменением с рисками проекта по автоматизации, вы получаете ее большую неопределённость, еще большие риски, которыми управлять невозможно.
А как же быть? Ну, за почти сто лет истории вопроса было придумано несколько вариантов:) Один из:
1. Описывать бизнес-процессы в проекте можно «как есть» и «как надо». Те, что необходимо улучшить, можно сразу описать «как надо», прописывая протокол их трансформации. А там, где нет претензий к эффективности, можно остановиться на их исходном состоянии – «как есть» и так и описать.
2. При анализе и описании функциональных требований заказчика разделить их на те, которые более чем, например, на 50% соответствуют типовому функционалу того технического решения, которое вы предлагаете, и на те, которые требуют расширения функциональных возможностей или существенной модификации.
3. Затем, в разрезе этих двух плоскостей, анализируется бизнес-логика работы предприятия, после чего формируется план работы, который включает, кроме работ по автоматизации, еще и требования к организационным изменениям, которые являются необходимым условием для выполнения работ по внедрению.
Потом пишется технический проект, потом дизайн, потом внедрение… В сущности, ничего сложного. Даже скучно. Вопрос, действительно, на мой взгляд, актуальный, только в том – а оно все это вообще еще надо или уже не надо?
За публикацию данного материала – автору минус.
ERP (MRP) - это Выталкивающая система, в отличие от Вытягивающей системы.
ERP системы для нормальной работы требуют заранее сформированного жесткого графика поставок.
На форумах по ERP системам часто спрашивают: А как мне быть, если поставщик подвёл? - все построения тогда рушатся. Как быстро всё пересчитать?
ERP - лет 20 назад считали панацеей от всех бед, но это ограниченный одним предприятием "взгляд" - это тупик в плане стратегии.
Да и в плане технологии уж не столбовая дорога прогресса тоже.
Интересно, а какова в данном случае альтернатива?
Это было известно давно.
Что касается спора о количестве "3 процесса" :) , о которых пишет автор и с чем спорите:
Есть другое известное название, которое больше подходит к тому, что делалось многие годы в нашей стране - разработка "Корпоративных информационных систем".
В 1998 году было внедрение на "Курском Кондитере" только одного модуля "Финансы" .... из всего" Baan IV, а об этом уже трубили - .... - "Первое внедрение ERP системы" в нашей стране ... реклама, однако :)
А по поводу альтернатив что-то уже говорилось в этой дискуссии, но это сильно выходит за рамки темы. Разработчики давно уже предлагают более широкий спектр различных систем.
За отсутствием логики, смысла в статье, и ... даже правильной интерпретации :) стандартов для ERP систем ... в словах автора проглядывается одна мысль -> теперь продают лучшие!!! практики и призывает даже :)
Автор пишет в статье: А зарубежные практики управления доказывают, что будущее бизнеса – это унификация, стандартизация и, наконец, так называемая макдональдизация. "
Автор пишет в статье: "Первая проблема при продаже проекта комплексной автоматизации состоит в том, что типовые решения зачастую «не ложатся» на реальные условия организации бизнеса. Тем самым затрудняется распространение и отладка лучших проектных практик и тормозится технологическое развитие в общем, увеличивается отставание от Запада".
Ну, если подумать, то тут есть кое-какой смысл (тут должна быть табличка "сарказм").
Только наша российская метода применения лучших практик и стандартизации выродилась в обеспечение требований регуляторов. Например, методы борьбы с требованиями 152 ФЗ (о защите персональных данных) или 54 ФЗ (об on-line кассах) вынуждают бизнесменов искать и лучшие практики, и методы оптимизации и унификации бизнесс-процессов, и чего только не... Последний "приход" по поводу Меркурия и ветсертификатов тому пример.
Вот где бюджеты, перспектива и гарантированный растущий рынок!
Очень злободневная проблема поднята в статье. Одни не могут сформулировать ТЗ, вторые не могут его реализовать. Что посоветовать? "Конторскую книгу", счеты, бубен.