Организация сопровождения SAP ERP

Поздеев М.С.
Выпускник группы MBA CIO 30
Школы IT-менеджмента
РАНХиГС при Президенте РФ

Введение

В жизненном цикле ИТ - продуктов на эксплуатацию приходится от 70 до 80% времени и финансовых средств, оставшаяся часть расходуется на разработку продукта (или его приобретение). Следовательно, для успешного использования ИТ существенное значение имеет качество информационного обслуживания. Это относится к любому типу организаций, больших или малых, общественных или частных, с централизованными или децентрализованными ИТ – услугами, пользующихся аутсорсингом или работающих с внутренними ресурсами. В любом случае услуги должны быть надежными, согласующимися друг с другом, высококачественными и приемлемыми по стоимости.

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

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

Для выработки предложений, направленных на снижение количества инцидентов предлагается следующий подход:

1. Собрать статистику по инцидентам на исследуемом предприятии;
2. Провести анализ статистики инцидентов;
3. Выявить факторы, влияющие на появление инцидентов;
4. Оценить механизм влияния факторов;
5. Разработать мероприятия по снижению инцидентов.

Анализ статистики

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

В целях проведения дальнейшего анализа инциденты распределили на группы по подсистемам (в составе корпоративной информационной системы выделены подсистемы в соответствии с автоматизированными бизнес-процессами), к которым они относятся, и на 3 группы по характеру их появления:

1. Изменения, доработки – связаны с изменчивостью среды;
2. Исправление ошибок – связаны с повышением надежности системы;
3. Прочее.

Исследовали влияние следующих факторов на появление инцидентов данных групп:

1. Сезонность (для инцидентов всех групп);
2. Кастомизация подсистем (для инцидентов группы «Изменения, доработки» и «Исправление ошибок»);
3. Тип подсистем (для инцидентов группы «Изменения, доработки» и «Исправление ошибок»);
4. Количество пользователей и уровень их квалификации (для инцидентов группы «Прочее»).

Сезонность

В ходе анализа выявили пики в периоды сдачи годовой и квартальной отчетности. В эти месяцы пользователи активно формируют отчеты. Особенно заметен временной характер в подсистеме «Налог на прибыль и ПБУ 18/02», где в отчетные периоды происходит формирование налоговых регистров. Инциденты носят явно выраженный временной характер. Пики приходятся на период подготовки годовой и квартальной отчетности. Инциденты, возникающие в этот период, носят срочный характер т.к. ограничены сроки подачи налоговой отчетности. Для выполнения работ привлекаем в эти месяцы дополнительных специалистов по налоговому учету из консалтинговой компании.

Кастомизация подсистем

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

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

Тип подсистем

Для последующего анализа распределили подсистемы на три группы:

1. Подсистемы типа «Источник», которые являются источником данных для других подсистем;
2. Подсистемы типа «Сток», в которые стекаются данные из других подсистем;
3. Подсистемы типа «Сеть», которые участвуют в двустороннем обмене данными.

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

Количество пользователей и уровень их квалификации

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

Заключение

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

1. выявить факторы, влияющие на появление инцидентов;
2. управлять качеством информационного обслуживания;
3. выстраивать модель отношений ИТ с бизнесом на основе взаимной ответственности.

Список литературы

1. ИТ Сервис – менеджмент, введение / пер. с англ. – М.: IT Expert,2003.
2. Ананьин В.И. Границы применения сервиса. ITIL и ИТ-архитектуры // Intelligent Enterprise. – 2008. № 2.