Роль и риски руководителя компании при внедрении ERP

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

(Агата Кристи. Восточный экспресс)

 
В таблице 1 условно показано влияние участия руководства на результаты проекта (оценка автора).

Таблица 1.

Качество предпроекта /	Участие руководства на этапе внедрения системы	/ Успех внедрения
Отличное или хорошее	+	+
Удовлетворительное	+	+
Плохое	Значительное	+
Безобразоное	+

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

Многие опытные интеграторы риск пассивности руководства Заказчика ставят на первое место. Однако в чем суть этого участия? Любой консультант незамедлительно ответит, что руководство должно обеспечивать проект необходимыми ресурсами (деньгами, прежде всего). Оставим финансовые взаимоотношения фирмы с внешними консультантами за рамками статьи и попробуем разобраться в том, какими другими важными ресурсами директор может поделиться с проектом, если его волнует результат.

Кстати, о результате

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

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

— Макар Лукич, вы опаздываете с запуском линии?
— Не волнуйтесь, к пятнадцатому числу линия будет запущена!

Макар Лукич приукрашивает ситуацию. Сам-то он понимает, что к пятнадцатому никак не успеет. Или не уверен, но на совещании говорит убедительно, потому что бережет начальственные нервы. А пятнадцатого числа у Макара Лукича непременно найдется какая-нибудь отмазка, он придумает, на кого списать прокол. И по этой схеме работают все начальники отделов. Если ориентироваться только на их доклады, то о текущем состоянии дел компании сложится неверное представление. Опытный руководитель знает об этой проблеме и отчеты своих подчиненных старается корректировать с учетом своего опыта и интуиции.

Он же является самым информированным лицом компании. Но ERP-система может заметно повысить его информированность. Так, например, кроме клятв менеджера среднего звена у него будет информация о том, что на участке не хватает ни нужных ресурсов, ни требуемого оборудования и к сроку Макар Лукич успеть не сможет.

Кому нужна новая ERP

Как видно из приведенного примера, руководитель отдела Макар Лукич вовсе не заинтересован во внедрении. Неприятие ERP не обязательно связано с неэффективностью или нечистоплотностью сотрудника. Многие люди просто не любят перемен. Кого-то устраивает старая система, к которой он уже привык. Так или иначе, многим будущим пользователям новая система не нужна, и они всячески сопротивляются внедрению.

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

Можно ли сделать новую систему нужной пользователю? И да, и нет. Заточка системы под каждого пользователя — дело трудоемкое. А если учесть текущую стоимость работы программистов и консультантов, то еще и дорогое. Но даже заигрывание с пользователем без «давления сверху» ничего не даст. Единственный выход из заколдованного круга состоит в том, чтобы дать понять пользователю, что система будет внедрена независимо от его желаний и действий.

Где у него кнопка

Я не знаю, как идет сигнал, Я не знаю принципа связи, Я не знаю, кто клал кабель, Едва ли я когда-нибудь услышу тебя…

Борис Гребенщиков, «212-85-06»

Руководителю необязательно знать технические детали. Для него ERP — это черный ящик (рис. 1).

Рис. 1. Качество данных на входе влияет на качество отчетов на выходе

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

Самый эффективный инструмент для этого — приказ директора о вводе ERP-системы в эксплуатацию (сперва в опытную). Приказ должен содержать:

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

Чтобы упростить процесс контроля ввода данных, имеет смысл временно расширить полномочия руководителя проекта на период развертывания и опытной эксплуатация системы. Можно применять и более жесткие меры: например, приравнять ввод неправильной информации в систему к сознательной попытке дезинформировать руководство компании (если при использовании наличных расчетов определенная сумма получена, но в систему вовремя не введена, это можно приравнять к краже).

Строгий последовательный ввод

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

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

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

В чем опасность для руководителя

— Хозяйка, опасности подстерегали нас на каждом шагу… — Пули свистели над головой, просим увеличить награду. — Меньше можно, больше ни-ни!

Мультфильм «Неуловимый фунтик» по книге Валерия Шульжика

Однажды в известной оптово-розничной компании в результате запуска ERP в опытную эксплуатацию (на тот момент в ERP была настроена только оптовая торговля) оптовый оборот упал на треть.

К такому результату привело сочетание двух факторов: наличие приказа об обязательном вводе данных и неготовность системы, то есть ошибки в настройках, не позволявшие вводить операции. Это привело к частичной остановке бизнеса. Стоянка и двор при складе компании были забиты фурами, которые не разгружались и не загружались из-за невозможности ввода операций в систему… Так что же важнее: бизнес или ERP? Ответ однозначный — бизнес.

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

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

Почему ERP не работает

— Посмотри, у нас мигалка работает? — Работает, не работает, работает, не работает…

Анекдот

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

Тогда дело в тестировании. Хотелось бы, но ни как нельзя протестировать систему в условиях, близких к боевым. Дело в том, что операции в ERP взаимосвязаны, протестировать их взаимное влияние друг на друга невозможно, слишком много понадобилось бы тестов. Но зачем тестировать любые варианты, если реальная работа ограничена определенным набором операций? Проблема в том, что правильно определить этот набор совсем не просто. Тут не поможет консультант по системе (его компетенции недостаточно, чтобы судить о бизнесе), ни специалист из бизнеса (он пока еще плохо знает систему). Кстати, одна из важных задач предпроекта — добиться от консультантов по системе хорошего понимания данного бизнеса. Это пригодится не только при настройке, но и при подготовке сценариев тестирования.

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

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

Как проверить систему перед внедрением

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

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

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

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

Неожиданные союзники

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

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

Может сложиться впечатление, что руководитель компании одинок в своем желании внедрить ERP и противостоит остальному коллективу, однако есть сотрудники, которых можно и нужно мотивировать. Это ваши ИТ-специалисты, которые хотят оправдать свою высокую (вы же позаботились об этом?) зарплату и совсем не против получить в резюме запись об участии в успешном и сложном проекте. Заинтересуйте их, и у вас все получится!