Журнал «Компьютерра» № 16 от 25 апреля 2006 года
Шрифт:
Попробую объяснить на примере. На оперативном совещании каждый руководитель подразделения докладывает о состоянии дел по своему направлению.
– Сергей Петрович, вы опаздываете с запуском линии?
– Не волнуйтесь, к пятнадцатому числу линия будет запущена!
Сергей Петрович приукрашивает ситуацию. Сам-то он понимает, что к пятнадцатому никак не успеет. Или просто не уверен, но на совещании говорит убедительно, потому что бережет начальственные нервы. А пятнадцатого числа у Сергея Петровича непременно найдутся объективные обстоятельства, он придумает, на кого списать прокол. И по этой схеме работают все начальники отделов. Если ориентироваться только на их доклады, то о текущем состоянии дел компании
Он же является самым информированным лицом компании. Но ERP-система может заметно повысить его информированность. Так, например, кроме клятв Сергея Петровича у него будет информация о том, что на участке не хватает ни нужных ресурсов, ни требуемого оборудования и к сроку Сергей Петрович успеть не сможет.
Как видно из приведенного примера, руководитель отдела Сергей Петрович может быть вовсе не заинтересован во внедрении. Неприятие ERP вовсе не обязательно связано с неэффективностью или даже нечистоплотностью сотрудника. Многие люди просто не любят перемен. Кого-то устраивает старая система, к которой он уже привык. Так или иначе, многим будущим пользователям новая система не нужна, и они всячески сопротивляются внедрению.
Часто еще на этапе предпроекта специалисты и руководители на местах открыто заявляют, что с новой системой работать не будут. Если руководство стоит на своем, то сопротивление принимает форму саботажа. Специалисты отказываются встречаться с консультантами, кивая на занятость. Если и после этого руководство четко обозначает свою позицию, то саботаж приобретает более скрытые и изощренные формы.
Можно ли сделать новую систему нужной пользователю? И да, и нет. Заточка системы под каждого пользователя – дело трудоемкое. А если учесть текущую стоимость работы программистов и консультантов, то еще и дорогое. Но даже заигрывание с пользователем без «давления сверху» ничего не даст. Единственный выход из заколдованного круга состоит в том, чтобы дать понять пользователю, что система будет внедрена независимо от его желаний и действий.
Я не знаю, как идет сигнал,
Я не знаю принципа связи,
Я не знаю, кто клал кабель,
Едва ли я когда-нибудь услышу тебя, тебя, тебя…
Руководителю необязательно знать технические детали. Для него ERP – это черный ящик (рис. 1).
Данные в систему вводят операторы (то есть специалисты с низкой эффективностью труда), а информацию о состоянии дел в компании получают руководители среднего и высшего звена (специалисты с высокой эффективностью труда). По сути, единственное, что должен знать директор компании об устройстве ERP (да и вообще практически любой ИТ-системы): мусор на входе приводит к мусору на выходе. Чтобы получать правильные и актуальные отчеты, сначала нужно организовать своевременный и безошибочный ввод данных в систему.
Эффективный инструмент для этого – приказ директора о вводе ERP-системы в опытную эксплуатацию. Приказ должен содержать:
список рабочих мест и перечень информации, подлежащей отражению в ERP-системе (эту часть приказа готовят консультанты по ERP);
поощрение сотрудников, чей объем работы в результате ввода системы в эксплуатацию увеличивается;
штраф за ввод ошибочной информации;
штраф за несвоевременный ввод информации.
Чтобы упростить процесс контроля ввода данных, имеет смысл расширить полномочия руководителя
Еще один эффективный способ повышения актуальности данных – запрет выполнения следующей операции до тех пор, пока не введена вся информация по предыдущей операции. Такой пункт гарантирует своевременность ввода данных даже в большей мере, чем система штрафов.
Однако на первых порах я не рекомендую применять жесткие меры по той причине, что появление новых обязанностей, новых программ и интерфейсов вызывает у пользователей стресс, приводящий к увеличению ошибок. По той же причине не стоит ожидать качественных отчетов в первые недели опытной эксплуатации.
В конечном счете именно влияние руководства – соответствующий приказ и меры по его обеспечению – являются ключевыми. Пользователю система не нужна, она нужна руководству, и руководство должно помнить об этом.
– Хозяйка, опасности подстерегали нас на каждом шагу…
– Пули свистели над головой, просим увеличить награду.
– Меньше можно, больше ни-ни!
В феврале 2002 года в известной оптово-розничной компании в результате запуска ERP в опытную эксплуатацию (на тот момент в ERP была настроена только оптовая торговля) оптовый оборот упал на треть.
К такому результату привело сочетание двух факторов: наличие приказа об обязательном вводе данных и неготовность системы, то есть ошибки в настройках, не позволявшие вводить операции. Это привело к частичной остановке бизнеса. Стоянка и двор при складе компании были забиты фурами, которые не разгружались и не загружались из-за невозможности ввода операций в систему… Так что же важнее: бизнес или ERP? Ответ однозначный – бизнес.
Часто неготовность системы к запуску выявляется на этапе внедрения. В этом случае следует выяснить причины сбоев и ошибок, а затем отменить запуск вплоть до устранения причин. Чем быстрее это будет сделано, тем меньше простоит бизнес. А некоторый простой, скорее всего, неизбежен – ведь ИТ-специалисты должны разобраться, в чем причины неудачи, чтобы этот сценарий не повторился при следующей попытке.
Отмена приказа о внедрении – это удар по авторитету руководителя. Степень риска бывает разная. Бывает даже, что руководитель предпочитает не останавливать опытную эксплуатацию, а пожертвовать временной остановкой бизнеса. Именно так и было сделано в приведенном примере. В таком случае специалистам ИТ следует немедленно искать пути решения проблем. Часто дело заканчивается полной перенастройкой системы. Каждый час, потраченный на переделки, – это час простоя бизнеса. В такой период на предприятии и появляются шутки про программистов, которых можно застать на работе в девять утра только потому, что они там и ночевали.
– Посмотри, у нас мигалка работает?
– Работает, не работает, работает, не работает…
Обнаружение неработоспособности системы на этапе ее развертывания, увы, дело обычное. Первая причина – это, как я уже говорил, низкое качество предпроекта. Но ситуация может возникнуть, даже если предпроект выполнен удовлетворительно или хорошо, то есть хорошими и заинтересованными результатом специалистами, внимательно, по правилам, с документацией и т. д. А все дело в тестировании.