Журнал «Компьютерра» № 16 от 25 апреля 2006 года - Компьютерра (бесплатная библиотека электронных книг txt) 📗
Как видно из приведенного примера, руководитель отдела Сергей Петрович может быть вовсе не заинтересован во внедрении. Неприятие ERP вовсе не обязательно связано с неэффективностью или даже нечистоплотностью сотрудника. Многие люди просто не любят перемен. Кого-то устраивает старая система, к которой он уже привык. Так или иначе, многим будущим пользователям новая система не нужна, и они всячески сопротивляются внедрению.
Часто еще на этапе предпроекта специалисты и руководители на местах открыто заявляют, что с новой системой работать не будут. Если руководство стоит на своем, то сопротивление принимает форму саботажа. Специалисты отказываются встречаться с консультантами, кивая на занятость. Если и после этого руководство четко обозначает свою позицию, то саботаж приобретает более скрытые и изощренные формы.
Можно ли сделать новую систему нужной пользователю? И да, и нет. Заточка системы под каждого пользователя – дело трудоемкое. А если учесть текущую стоимость работы программистов и консультантов, то еще и дорогое. Но даже заигрывание с пользователем без «давления сверху» ничего не даст. Единственный выход из заколдованного круга состоит в том, чтобы дать понять пользователю, что система будет внедрена независимо от его желаний и действий.
Я не знаю, как идет сигнал,
Я не знаю принципа связи,
Я не знаю, кто клал кабель,
Едва ли я когда-нибудь услышу тебя, тебя, тебя…
Руководителю необязательно знать технические детали. Для него ERP – это черный ящик (рис. 1).
![Журнал «Компьютерра» № 16 от 25 апреля 2006 года - _636a18r2.jpg](https://goldenlib.ru/frontend/web/pic/1/4/7/6/3/14763/1386612892/_636a18r2.jpg)
Данные в систему вводят операторы (то есть специалисты с низкой эффективностью труда), а информацию о состоянии дел в компании получают руководители среднего и высшего звена (специалисты с высокой эффективностью труда). По сути, единственное, что должен знать директор компании об устройстве ERP (да и вообще практически любой ИТ-системы): мусор на входе приводит к мусору на выходе. Чтобы получать правильные и актуальные отчеты, сначала нужно организовать своевременный и безошибочный ввод данных в систему.
Эффективный инструмент для этого – приказ директора о вводе ERP-системы в опытную эксплуатацию. Приказ должен содержать:
список рабочих мест и перечень информации, подлежащей отражению в ERP-системе (эту часть приказа готовят консультанты по ERP);
поощрение сотрудников, чей объем работы в результате ввода системы в эксплуатацию увеличивается;
штраф за ввод ошибочной информации;
штраф за несвоевременный ввод информации.
Чтобы упростить процесс контроля ввода данных, имеет смысл расширить полномочия руководителя проекта на период развертывания и опытной эксплуатация системы. Можно применять и более жесткие меры: например, приравнять ввод неправильной информации в систему к сознательной попытке дезинформировать руководство компании (если при использовании наличных расчетов определенная сумма получена, но в систему вовремя не введена, это можно приравнять к краже).
Еще один эффективный способ повышения актуальности данных – запрет выполнения следующей операции до тех пор, пока не введена вся информация по предыдущей операции. Такой пункт гарантирует своевременность ввода данных даже в большей мере, чем система штрафов.
Однако на первых порах я не рекомендую применять жесткие меры по той причине, что появление новых обязанностей, новых программ и интерфейсов вызывает у пользователей стресс, приводящий к увеличению ошибок. По той же причине не стоит ожидать качественных отчетов в первые недели опытной эксплуатации.
В конечном счете именно влияние руководства – соответствующий приказ и меры по его обеспечению – являются ключевыми. Пользователю система не нужна, она нужна руководству, и руководство должно помнить об этом.
– Хозяйка, опасности подстерегали нас на каждом шагу…
– Пули свистели над головой, просим увеличить награду.
– Меньше можно, больше ни-ни!
В феврале 2002 года в известной оптово-розничной компании в результате запуска ERP в опытную эксплуатацию (на тот момент в ERP была настроена только оптовая торговля) оптовый оборот упал на треть.
К такому результату привело сочетание двух факторов: наличие приказа об обязательном вводе данных и неготовность системы, то есть ошибки в настройках, не позволявшие вводить операции. Это привело к частичной остановке бизнеса. Стоянка и двор при складе компании были забиты фурами, которые не разгружались и не загружались из-за невозможности ввода операций в систему… Так что же важнее: бизнес или ERP? Ответ однозначный – бизнес.
Часто неготовность системы к запуску выявляется на этапе внедрения. В этом случае следует выяснить причины сбоев и ошибок, а затем отменить запуск вплоть до устранения причин. Чем быстрее это будет сделано, тем меньше простоит бизнес. А некоторый простой, скорее всего, неизбежен – ведь ИТ-специалисты должны разобраться, в чем причины неудачи, чтобы этот сценарий не повторился при следующей попытке.
Отмена приказа о внедрении – это удар по авторитету руководителя. Степень риска бывает разная. Бывает даже, что руководитель предпочитает не останавливать опытную эксплуатацию, а пожертвовать временной остановкой бизнеса. Именно так и было сделано в приведенном примере. В таком случае специалистам ИТ следует немедленно искать пути решения проблем. Часто дело заканчивается полной перенастройкой системы. Каждый час, потраченный на переделки, – это час простоя бизнеса. В такой период на предприятии и появляются шутки про программистов, которых можно застать на работе в девять утра только потому, что они там и ночевали.
– Посмотри, у нас мигалка работает?
– Работает, не работает, работает, не работает…
Обнаружение неработоспособности системы на этапе ее развертывания, увы, дело обычное. Первая причина – это, как я уже говорил, низкое качество предпроекта. Но ситуация может возникнуть, даже если предпроект выполнен удовлетворительно или хорошо, то есть хорошими и заинтересованными результатом специалистами, внимательно, по правилам, с документацией и т. д. А все дело в тестировании.
Вторая причина – невозможность протестировать систему в условиях, близких к боевым. Почти все операции в ERP взаимосвязаны. Протестировать взаимное влияние всех операций друг на друга невозможно, слишком много понадобилось бы тестов.
Зачем тестировать любые варианты, если реальная работа ограничена определенным набором операций? Проблема в том, что правильно определить этот набор совсем не просто. Тут не поможет консультант по системе (его компетенции недостаточно, чтобы судить о бизнесе), ни специалист из бизнеса (он пока еще плохо знает систему). Кстати, одна из важных задач предпроекта – добиться от консультантов по системе хорошего понимания данного бизнеса. Это пригодится не только при настройке, но и при подготовке сценариев тестирования.
Кроме того, тестирование проводится на ограниченном количестве рабочих мест. В боевых условиях с системой одновременно работают множество специалистов. Количество операций, выполняющихся одновременно или последовательно, оказывается заметно больше, чем проверялось на тестовых примерах. Тут-то и выплывают различные неприятные моменты, которые не были заметны при тестировании в «щадящем режиме».
Третья причина в том, что персонал компании обычно тестирует систему невнимательно. Специалисты из бизнеса смотрят на придуманные консультантами цифры через незнакомые интерфейсы и не готовы вникать в детали. Это может усугубляться высокой текущей занятостью и отсутствием ответственности за некачественное тестирование.