ERP: внедрили и забыли. Реальность эксплуатации корпоративных информационных систем.

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

Современные ERP-системы сложны и дороги. Их основная задача - поддерживать информационные процессы предприятия, чтобы помогать принимать эффективные управленческие решения, обеспечивать возможность предоставления новых сервисов, повышать производительность персонала. Стремясь получить максимум конкурентных преимуществ, многие предприятия не просто внедряют готовые коробочные решения, а проводят серьезные работы по настройке и доработке готовых продуктов, получая в результате внедрения уникальную систему, «штучный товар». Безусловно, такие внедрения требуют серьезных инвестиций.

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

Вот аналогия: гоночный автомобиль. Уникальный, практически штучный товар. Является весьма важным слагаемым успеха гоночной команды, чьи победы, в свою очередь, способствуют коммерческому успеху автомобильного концерна. Существуют и коммерческие гоночные автомобили, которые Вы можете приобрести для себя, например Ferrari FXX.

Но здравомыслящему человеку не придет в голову, приобретя такой автомобиль, бросить его во дворе под окнами, ограничивая обслуживание ежегодным ТО и сезонной сменой резины. Более того, тот же Ferrari FXX - это целая программа: покупая такой автомобиль за немалые 2,5 миллиона долларов, Вы не увезёте его домой. Ваш автомобиль будет храниться в гаражах Ferrari. Вам будут разрешать поездить на нем на определенных трассах в согласованные с компанией Ferrari дни. И будьте уверены: Ваш автомобиль будет подготовлен к гонке и пройдет нужное обслуживание после её окончания. Иными словами, компания Ferrari обеспечивает Вам весь комплекс услуг по эксплуатации этого уникального автомобиля. Иначе - нельзя. Иначе - Вам дорога к конвейеру, где Вы получите, возможно, хороший, но стандартный автомобиль. Более простой с технической точки зрения, менее выдающийся с точки зрения своих характеристик и притягательности.

Но - простите за лирическое отступление - давайте вернемся к нашим... информационным системам. Вот лишь несколько примеров.

Пример первый. Поддержка пользователей новой системы

Проект заканчивается. Система работает в соответствии с техническим заданием (прошла квалификационные испытания и внедрена в опытную эксплуатацию). Пользователи начинают работать с новой системой и сталкиваются с первыми сложностями. Обнаруживаются первые ошибки: где-то - очевидные (сообщение об ошибке при вызове той или иной функции), где-то - трудноуловимые (неправильные результаты расчетов по некоторым отчётам). Что нужно, чтобы помочь пользователям преодолеть отторжение нового и начать использовать систему на 100%? Хорошо организованная поддержка пользователей. Консультанты покидают компанию, им пора рисовать новую звездочку на фюзеляже - проект закончен. Не занимались они никогда организацией поддержки, да и договором это не предусмотрено. Поддержкой пользователей на предприятии традиционно занимались несколько специалистов. В проекте внедрения ERP они не участвовали, обучение прошли краткое, на уровне первичного инструктажа. Может быть, срочно дать им какой-нибудь инструмент для регистрации обращений? Может быть, вручить им описание процесса управления инцидентами? Но что это даст, когда на них, едва прошедших обучение, обрушится 300 обращений в день? Немного.

А ведь об этом можно было подумать заранее и предпринять, например, следующие шаги:

• подготовить дополнительные ресурсы на период начальной эксплуатации новой системы
• усилить команду поддержки специалистами, участвовавшими во внедрении
• организовать документирование известных ошибок до ухода консультантов
• организовать углубленное обучение специалистов по поддержке новой системы (возможно, обучить их два раза по одним и тем же программам)
• организовать работы по поддержке так, чтобы целенаправленно «вытягивать» знания новой системы из консультантов до окончания опытной эксплуатации

Пример второй. Управление изменениями

Проект закончен, консультанты ушли. Жизнь продолжается. Необходимы доработки - новый функционал, исправление ошибок. Все срочно. Кто что меняет - непонятно. Небольшая на первый взгляд доработка, оказывается, затрагивает многих пользователей (это обычно выясняется уже после ее реализации). График развертывания релизов отсутствует. Требуемый уровень контроля не определен - или любые, даже небольшие, изменения приходится прогонять через проектное управление (благо оно, как правило, в каком-то виде присутствует и обеспечивает нужный контроль) или «заморозить» частые изменения и внедрять релизы не реже одного раза в квартал. Не хватает документации по системе. Да и та, что была написана в ходе проекта (уже чудо), быстро устаревает под напором доработок. В результате система работает нестабильно, каждое новое изменение - серьезный риск (повезет / не повезет), скорость реализации изменений чаще всего низкая и всегда - нестабильная. Вот, например, это изменение реализовано в приемлемые сроки, а другое тянется уже третий месяц.

И опять своевременная подготовка позволяет во многом смягчить эти проблемы:

• до запуска проекта необходимо оговорить с консультантами в договоре документирование системы. В некоторых продуктах для этого даже есть готовые инструменты, которые поставляются заказчику в рамках внедрения бесплатно (например, SAP Solution Manager) и, тем не менее, консультанты часто их не используют, избегая дополнительных трудозатрат
• организовать управление изменениями и релизами (хотя бы только по этой системе). Совместно с консультантами проработать вопросы классификации изменений, правил обновления, тестирования и документирования. Согласовать подход к управлению изменениями с бизнес-руководством, чтобы не создавать неоправданных ожиданий и обеспечить участие заказчиков в управлении системой (в ряде случаев создаются специальные органы управления, состоящие из ИТ-специалистов и представителей бизнес-подразделений, которые совместно решают вопросы проведения изменений - приоритетов, сроков, согласования)
• запускать механизмы управления изменениями и релизами не после окончания проекта, а с самого начала опытной эксплуатации
• включать своих специалистов в команду разработчиков, прививая им знания новой системы и ее внутренних механизмов, доработанных консультантами, не «за школьной партой», а в реальной жизни

Пример третий. Управление архитектурой решений

Проект давно закончен. Причем несколько проектов (например, внедрены несколько модулей крупной системы управления). Более того, эти несколько проектов проводились разными компаниями-подрядчиками. Например, потому что есть обязательные тендерные процедуры (и «голодные студенты» с обширной эрудицией), или потому что консультанты специализируются по областям, или по другим причинам.

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

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

Но кое-что можно было сделать заранее:

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

Работа над ошибками

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

С одной стороны, эта ситуация сложилась исторически. Например, отечественный ГОСТ 34.601 «Автоматизированные системы. Стадии создания» вообще не акцентирует внимание на эксплуатации. С другой стороны, на дворе 2010 год (напомню, упомянутый ГОСТ введен в действие в 1992 году), накоплен значительный опыт в организации эксплуатации информационных систем. Есть международные материалы, например, ITIL®/ITSM. Есть и отечественные стандарты:

• ГОСТ Р ИСО 12207-1999 «Процессы жизненного цикла программных средств» акцентирует внимание на том, что помимо стадий приобретения и внедрения есть не менее важные стадии жизненного цикла «Эксплуатация» и «Сопровождение»
• готовящийся к официальному выходу в свет ГОСТ Р ИСО 20000 перечисляет требования к системе управления ИТ-сервисами (что также во многом связано именно с эксплуатацией систем)

Процессы жизненного цикла программных средств. ГОСТ Р ИСО 12207-1999.

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

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

От слов к делу

Что же необходимо на практике сделать дополнительно к проектным работам по внедрению корпоративной информационной системы? На взгляд автора, следующее:

• организовать внутреннюю деятельность по эксплуатации и сопровождению системы (системное администрирование, управление инцидентами и проблемами, управление изменениями и релизами, управление конфигурациями и документирование)
• организовать внутренний центр компетенции (голова должна быть своя)
• организовать взаимодействие с разработчиками корпоративной информационной системы - внешним консультантом по внедрению или внутренним подразделением разработки информационных систем (вопросы те же: как участвуют консультанты в поддержке пользователей, в реализации изменений, как документируют решения, как «отдают» компетенцию заказчику)
• автоматизировать деятельность по эксплуатации и сопровождению корпоративной информационной системы (внедрить инструмент для управления деятельностью ИТ-специалистов или использовать существующий, если он уже работает)
• подготовить персонал предприятия по вопросам эксплуатации и сопровождения информационной системы (что предполагает обучение как самой системе, так и организации деятельности и взаимодействий)

Пример комплексного решения по эксплуатации и сопровождению корпоративной системы.

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

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

Сноски:

1. Целостности. Профессиональный сленг специалистов в области построения корпоративных информационных систем