Типичные ошибки, допускаемые при внедрении информационных систем

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

В своем посте Software product management Максим Смирнов - архитектор из Билайн - правильно указал на пять классических ошибок, которые совершают внедренцы. Я хочу привести свое видение проблемы. Некоторые мои ошибки пересекаются со списком Максима, некоторые - дополняют его.

1. Моя команда начала проект со сбора требований, а не с обучения пользователей продукту. Т.е. обучение было произведено, однако философию продукта и детали его использования представители заказчика не поняли, а мы не смогли их им объяснить.
   
   Как правило у сотрудников предприятия, которые будут пользоваться вновь внедряемой системой, есть выработавшиеся привычки, касающиеся двух моментов: бизнес-процессов компании и юзабилити той системы, которой они уже пользуются (если таковая имеется).
   
   По-отношению к бизнес-процессам существует две политики: внедряемая система кастомизирутеся в соответствии с бизнес-процессами заказчика или эти процессы подгоняются под возможности системы. Какой политики придерживаться при внедрении в общем случае сказать невозможно, т.к. каждое предприятие индивидуально. Из общих правил можно выделить следующее: бардак лучше не автоматизировать, потому что ни к чему хорошему это не приведет. Если есть возможность разобраться и произвести структурное описание бизнес-процессов, то лучше сделать это с учетом возможностей внедряемой системы. Так же хорошо, если внедряемая система содержит гибко настраиваемые средства автоматизации бизнес-процессов (например, BPEL- или BPMN-движок), еще лучше, если она позволяет интегрироваться с BPM-системой стороннего производителя.
   
   С точки зрения юзабилити ситуация следующая: как правило никто не хочет переучиваться, да и не всегда данный процесс прост. У сотрудников заказчика всегда будут возникать претензии ко внедряемой системе, просто потому что она выглядит и ведет себя не так, как они привыкли. Если начинать процесс внедрения со сбора требований этих специалистов, то получится так, что для их удовлетворения проще разработать новую систему с нуля, нежели кастомизировать внедряемую. Здесь важно, чтобы руководитель проекта имел сталь в нужных местах и настоял на обучении сотрудников заказчика пользоваться внедряемой системой. Как правило за время обучения люди понимают, что какие-то действия в системе выполняются по другому, какие-то больше вообще не нужны, т.к. полностью автоматизированы, а какие-то возможности внедряемой системы вообще лишние и использоваться не будут. Если внедряемая система правильно поделена на модули, то отключение лишней функциональности является довольно тривиальной операцией.


2. В системе не было развитых средств интеграции и встраивания в IT-ландшафт заказчика. Считаю, что в данном случае именно это и привело к краху проекта, т.к. заказчик надеялся, что именно на основе внедряемой системы он сможет структурировать бизнес-процессы компании и перейти к использованию BPMS-решения. Как можно избежать повторения данной ошибки? Прежде всего, внедряемая система должна иметь развитый и хорошо документируемый API, который должен быть доступен из внешних приложений, например посредством веб-сервисов, JCA-коннекторов или других интеграционных технологий. Под термином "развитый" я понимаю то, что API должен обеспечивать доступ ко всей основной функциональности системы. В идеале не должно быть разницы между функциональностью, доступной через API и через интерфейс пользователя.


3. Не было продуманной методики внесения изменений. Несмотря на то, что система была модульной, в ней не было SDK для разработки своих модулей. Считаю, что наличие такого SDK, который в простейшем случае представляет собой JavaDoc-описание базовых классов и интерфейсов системы, набор интерфейсов, а так же краткую инструкцию о том, как собрать и запустить свой модуль, может являться существенным конкурентным преимуществом.


4. Кстати, ситуация осложнялась как раз тем, что заказчик хотел провести внедрение своими собственными силами. Понятно, что компания-разработчик системы может выполнить любую ее кастомизацию, включая удовлетворение всех требований ко внешнему виду и интеграцию с чем угодно, однако действительно коробочный продукт отличается тем, что для его внедрения не нужны ни специалисты компании-разработчика, ни исходники. Кстати, история 1С, SAP, OeBS учит нас, что вокруг таких коробочных продуктов складывается отдельный бизнес - бизнес компаний-партнеров и независимых консультантов по их внедрению, что приносит дополнительных доход и компании-разработчику. Если же данной ситуацией грамотно воспользоваться, то можно организовать и бизнес третьего порядка - курсы для консультантов-внедренцев и пользователей, платная документация и т.д.

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

З.Ы. На вопросы какой продукт, какой компании и где внедрял отвечать не буду, дабы не разгласить важную военную коммерческую тайну.

Понравилось сообщение - подпишитесь на блог