воскресенье, 25 сентября 2011 г.

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


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

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


  1. Моя команда начала проект со сбора требований, а не с обучения пользователей продукту. Т.е. обучение было произведено, однако философию продукта и детали его использования представители заказчика не поняли, а мы не смогли их им объяснить.

    Как правило у сотрудников предприятия, которые будут пользоваться вновь внедряемой системой, есть выработавшиеся привычки, касающиеся двух моментов: бизнес-процессов компании и юзабилити той системы, которой они уже пользуются (если таковая имеется).

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

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

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

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

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



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

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

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

6 комментариев:

Skynin комментирует...

С пару месяцев ушел с внедрения. Со стороны заказчика. Машиностроительное предприятие. Причины вобщем-то совпадают - устоявшиеся анархические бизнес-процессы - смерть внедрению любой системы которая требует работы по ним. 1С кстати не требует, но только вот и допиливают бесконечно 1С:УПП после "сдачи системы под ключ".
Но самое ужасное, что аж за всю нашу отрасль программерскую обидно - интеграция с другим ПО. Предоставлять такую возможность должны оба продукта, и тут то и загвоздка, если один, передовой, с хорошим API, то какова вероятность что и второй будет хорош?
Пример - есть "Болт X". Он используется - конструкторами когда рисуют в CADe, технологами, когда рисуют технологические карты, складами цехов, службой снабжения. И все это - разные БД. Заставить программы подключиться к одной БД - весьма трудно, потому что вот и нет в большинстве случаев у них API, а работа с конкретной БД вшита в код.
Смотрел в сторону MDM (Talend), но тоже самое - как заставить работать программы с ней?

В итоге реалистических выхода 2
Лоскутная автоматизация, отдельные программы в лучшем случае обмениваются через файлы импорта-экспорта. Все исполнение и контроль обмена - на людях.
Единая, большая ERP которая умеет делать почти все (у зрелых CAD систем есть API и возможность писать коннекторы наружу)

То есть пункт 2 следует читать: отсутствие реальной возможности интеграции ПО. И это можно сказать - просто всегда.
Да и 1ый пункт в СНГ - анархические, стихийные бизнес-процессы - тоже просто всегда.

Pavel Samolisov комментирует...

Интересный опыт, с машиностроительной тематикой пока не сталкивался.

По поводу интеграции. Если одна из систем не предоставляет сервисов, то их приходится эмулировать с помощью ESB. Сейчас как раз завершаю проект, где приходится интегрировать неинтегрируемое, делаем через буферные таблички в базе данных. Надеюсь, что будет возможность написать об этом подробнее. Но, здесь хорошо, что "неинтегрируемую" систему в каких-то пределах можно кастомизировать, в частности заставить читать данные из буферной таблички. Гораздо хуже, когда систему вообще никак кастомизировать нельзя, только если обратиться к вендору или купить исходники. По сути это - то, что Вы назвали лоскутной автоматизацией.

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

Skynin комментирует...

в частности заставить читать данные из буферной таблички.
Ну вот например, CRM написана на MS Access, PLM - на Aras Innovator (ASP.NET, с MS SQL естественно), создание тех карт (от "Аскон") для технологов на дельфях с вшитой в код работой с Firebird.
"Нагибать" на совместную работу нужно все три продукта.

Вариант внедрения единой ERP ни чем не лучше
Дело в том что другого нет. Либо - лоскутная, либо жирная ERP. Интеграция же ПО возможна в весьма редких случаях.

она требует существенной перестройки бизнес-процессов
Пришел я к выводу что это нужно - всегда.

Допустим - удалось нам интегрировать вышеназванные три продукта. Следующий этап:
Дилер получает, оформляет заказ на разработку.
Конструктор рисует, технолог описывает тех процесс. Это ж - единая транзакция. И обычно - не формализован. Как же нам создать настроить, запрограммировать сложившийся способ совместной работы персонала?
Описать и запрограммировать как есть - нелепо. Потому что лишние люди-передатчики есть, ввиду неформализованного процесса, и есть - "люди-пауки" как я их называю, на которых держится все (напр зам нач дилерского отдела, или зам фин директора по производству). К которым бегут почти всегда и всегда, когда возникают рабочие трения.
При автоматизации часть их функций контроля и разрулирования обязана брать на себя себя система. Но они тем более работают творчески, неформализировано. И без ломки их стиля работы - никак.

Pavel Samolisov комментирует...

Ну вот например, CRM написана на MS Access, PLM - на Aras Innovator (ASP.NET, с MS SQL естественно), создание тех карт (от "Аскон") для технологов на дельфях с вшитой в код работой с Firebird.
"Нагибать" на совместную работу нужно все три продукта.


Именно этим сейчас и занимаюсь: 1С-ки, DMS от IBM, самописные вещи. С помощью Oracle SOA Suite интегрируются, но сами системы приходится существенно дорабатывать. Собственно, построить шину то не сложно, вот доработать системы - это задача.

CGen комментирует...

Обычно коробочные продукты в чистим виде малопригодны. Из этого вытекает необходимость в предпроектном обследовании и сборе требований.
А отсюда уже всё из классики ;-) Т.е. что собрали, то и реализовали. Часто заказчик не хочет понимать, что аналитик нему не пристаёт, а пытается помочь.

Pavel Samolisov комментирует...

Идея статьи в том и заключается, что надо не просто собирать требования и тупо их реализовывать, а обучить заказчика пользоваться системой и только потом делать доработки, причем связанные не с хотелками в виде "хочу кнопку тут", а именно с доработкой бизнес-процессов (например, "у вас тут согласовать документы должны все пользователи, которых я выбрал, а мне надо, что если пользователь А согласовал, то согласование остальными людьми ненужно").

Отправить комментарий

Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!