Компьютерра - Журнал «Компьютерра» № 16 от 25 апреля 2006 года

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

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

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

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

— Хозяйка, опасности подстерегали нас на каждом шагу…

— Пули свистели над головой, просим увеличить награду.

— Меньше можно, больше ни-ни!

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

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

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

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

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

— Работает, не работает, работает, не работает…

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

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

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