К сожалению, не все промышленные предприятия могут похвастаться хорошим ИТ-директором в команде управленцев. Это такая роль, в компетенцию которой, как минимум, входят:
- Правильное представление и знание способов применения ИТ-технологий и инструментов для бизнес-улучшений и поддержки достижения целей предприятия;
- Понимание технологии ИТ-изменений: этапность проводимых изменений и необходимые условия для их успешного выполнения;
- Административный или политический вес, достаточные полномочия для осуществления изменений в процессах функциональных отделов и подразделений предприятия;
Из-за вакантности такой роли у управленческой команды складывается упрощенное отношение к ИТ- изменениям в системе управления предприятия, что приводит к обманчивым и ошибочным подходам к внедрению ERP-системы:
1) Коробочное решение – готовая таблетка для предприятия: можно просто купить программный продукт, установить его и начать работать в нем;
2) Управлять внедрением ERP-системы должны собственные ИТ-специалисты (как правило, 1-2 штатных программистов – вполне справятся);
3) Для того, чтобы понять, как нам работать в системе – достаточно пройти обучение типовому программному продукту. Отправим функциональных пользователей поучиться продукту – и они самостоятельно смогут настроить его под себя;
4) Мы сможем самостоятельно разобраться и внедрить систему на своем предприятии.
Есть еще несколько типовых заблуждений, но для экономии времени и лаконичности публикации – давайте остановимся на этих.
Хорошо, если нашим экспертам повезло познакомиться с такими «заблуждающимися» предприятиями на стадии подготовки к проекту – у нас еще остается возможность пояснить им природу заблуждений и помочь избежать ошибок и проблем (как правило, дорогостоящих). Но, к сожалению, не всегда удается в рамках непродолжительных переговоров донести или переубедить (не ИТ) руководителей в ошибочности их подходов. И тогда нам с моральным грузом неисполненного долга приходится наблюдать со стороны за самостоятельным (но гордым!) проектом внедрения системы – хождением клиента по «граблям» и набиванием шишек.
Хуже, когда знакомишься с клиентом на стадии бесконечно затянувшегося запуска такого проекта в эксплуатацию. В лучшем случае, при таких подходах у клиента запускаются самые-самые базовые задачи (например, количественный складской учет приход-расход на центральных складах), но в целом, система напоминает «песочницу» - игрушку, в которой методом проб и ошибок функциональные пользователи вместе с ИТ-специалистами лихорадочно пытаются добиться того, чтобы она как-то заработала.
Давайте разберем, в чем заключается самообман ошибочных принципов, описанных выше.
1) Ни одна современная коробочная ERP-система, внедряемая для управленческих задач, не является готовым инструментом, «таблеткой».
Ни 1С:ERP, ни 1С:УПП, ни решения на платформах SAP, Oracle, BaaN и пр. Коробка – это технический, логически связанный набор функционала, для которого должен быть определен конкретный вариант использования под конкретные и всегда специфические нужды системы управления конкретного предприятия. Коробка – это набор «строительных материалов», «кирпичиков», обладающих своими характеристиками и правилами использования. А одной из задач проекта является компоновка из этих «кирпичиков» той конфигурации системы, которая позволит решить задачи предприятия.
Например, можно посмотреть 2 отраслевых предприятия-конкурента, которые успешно внедрили ERP-систему из одинаковой коробки – и их внедренные решения будут существенно отличаться. Один из наших клиентов металлургической отрасли в поисках подходящей системы управления производством объехал десяток металлургических предприятий с внедренными ERP-системами на производстве – и ни в одной системе не увидел себя на 100%
2) ИТ-специалисты не могут быть ответственными, «локомотивами» внедрения ERP-системы.
Несмотря на то, что ERP-система – это ИТ-инструмент – она является только техническим результатом проекта. А полным результатом проекта являются организованные процессы и работающие в них люди, которые используют правильно настроенную систему для выполнения своих задач. Такой результат является правильным, а вменять ответственность за организацию функциональных процессов ИТ-специалисту, как правило, неперспективно – это не его поле боя. В среднем, в правильно организованном проекте внедрения автоматизационные ИТ-задачи составляют 30-40% от общего объема работ. Остальное – это задачи функциональных руководителей по определению требований к процессам и внедрению организационных изменений в процессах работы.
Конечно, бывают вырожденные варианты проектов внедрения – от функционала программы с изменением процессов предприятия под возможности системы. Но,
а) При таком подходе все равно требуется определение методики работы в системе и настройка вариантов использования типового, недоработанного функционала (определять методику штатные ИТ-специалисты готовы далеко не всегда);
б) Такой подход практически не применим для более-менее серьезных промышленных предприятий.
3) Обучение типовому функционалу не дает представления о варианте использования системы для вашего конкретного предприятия (хотя, безусловно, является полезным для подготовки к проекту внедрения).
Причина в том, что любое групповое обучение людей с разных предприятий функционалу типового продукта нацелено на изучение «строительных материалов», «кирпичиков», их характеристик и свойств. Но без погружения в особенности процессов, задач и проблем вашего предприятия – ни один лектор не сможет показать вам макет «здания», которое вы хотите построить. В лучшем случае, при правильно сформулированных конкретных вопросах о специфике ваших задач лектор сможет предложить варианты использования продукта. Но, рассчитывать на получение после обучения модели учета вашего предприятия – бессмысленно. Это отдельный этап технологии внедрения системы.
4) Внедрение новой ERP-системы силами собственных специалистов возможно, но при одновременной обеспеченности специалистами по проектной технологии: а) готовых обеспечивать ее соблюдение; б) способных грамотно сформулировать требования к системе; в) знающих типовой функционал и умеющих определять варианты его использования под требования процессов и задач предприятия.
Эти специалисты должны иметь успешный опыт выполнения подобных задач. Одновременно весь арсенал подобных людей на промышленных предприятиях я не встречал – все-таки это достаточно узкоспециализированные ИТ-специалисты. А без обеспеченности такими людьми – самостоятельный проект внедрения напоминает самолечение, причем, от довольно сложной «болезни».
Сравнение с лечением неслучайно, потому что ИТ так же, как и медицина или юридические услуги – являются отраслью профессиональных услуг. При этом, если человек серьезно болен или возникла серьезная юридическая проблема – он обращается за помощью к профессиональным экспертам своего дела. А вот в случае ИТ – «самолечение» почему-то кажется приемлемым вариантом. Пример из практики – на 2-х производственных заводах-площадках холдинга были запущены проекты комплексной автоматизации на 1С:УПП – на одном – с нашим участием, на 2-м – собственными силами. С нашим участием проект был выполнен за 4 месяца, система запустилась, и предприятие получило ожидаемые результаты. На «самостоятельном» внедрении проект с аналогичными задачами запускался в течение 1,5 лет. К тому времени на первом заводе все участки учета были прозрачными, управляемыми и контролируемыми, и были инициированы новые проекты и задачи. Кто остался в выигрыше?