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