10.2.Система продолжает работать – сопровождение корпоративной системы

Данную книгу об управлении проектами внедрения ERP-системы можно было бы завершить на предыдущем разделе – вместе с завершением проекта внедрения. Но нужно рассмотреть для полноты понимания процессы, которые выходят за его рамки, т. к. все же проект внедрения – это не самоцель для компании, цель – работающая система, автоматизация бизнес-процессов и получение различных бизнес-преимуществ от автоматизации. А для того, чтобы система продолжала успешно работать, нужно приложить определенные усилия, в том числе и по ходу самого проекта, заложив необходимые возможности для обновлений и развития системы в процессе ее сопровождения.

К задачам сопровождения корпоративной системы относятся:

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

Важно отметить, что сопровождение корпоративной системы помимо самой системы учета и автоматизации бизнес-процессов включает поддержку аппаратной части и прочего программного обеспечения:

• рабочие станции пользователей и серверы;
• доступ к сетевым ресурсам;
• принтеры и прочее офисное оборудование.

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

ITIL (англ. IT Infrastructure Library) – библиотека инфраструктуры информационных технологий, описывает лучшие из применяемых на практике способы организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

Вся деятельность в области повышения квалификации специалистов по корпоративному сопровождению опирается на стандарты и своды лучших практик:

• свод лучших практик и библиотека ITIL;
• стандарты серии ГОСТ Р ИСО/МЭК 20000 «Информационные технологии. Управление услугами»;
• стандарты жизненного цикла ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Процессы жизненного цикла программных средств» и ISO/IEC 14764:2006 Software Engineering – Software Life Cycle Processes – Maintenance;
• стандарт ГОСТ Р ИСО 9001 «Системы менеджмента качества. Требования».

1С:Технология корпоративного сопровождения () – это технология управления предоставлением услуг сопровождения информационных систем, разработанных на платформе «1С:Предприятие 8». Разработанная технология корпоративного сопровождения состоит из трех основных элементов:

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

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

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

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

SLA (англ. Service Level Agreement, соглашение об уровне предоставления услуги) – термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и ее поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.

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

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

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

Таким инструментом автоматизации может выступить решение «1С:ITIL Управление информационными технологиями предприятия». Подробно с возможностями конфигурации можно ознакомиться на сайте .

Рис. 10.1. Возможности решения 1С:ITIL КОРП

Рассмотрим некоторые понятия и определения, вводимые ITIL.

• Запрос на обслуживание (Service Request) – запрос от пользователя на предоставление информации на стандартное изменение или на доступ к ИТ-услуге.
• Инцидент (Incident) – незапланированное прерывание предоставления ИТ-услуги или снижение качества ИТ-услуги.
• Изменение (Change) – добавление, модификация или удаление чего-нибудь, что имеет влияние на ИТ-услуги.
• Проблема (Problem) – неизвестная причина одного или более инцидентов.
• Событие (Event) – изменение состояния, которое имеет значение для управления конфигурационной единицей или ИТ-услугой.
• Сбой (Failure) – потеря способности функционировать в соответствии со спецификацией или предоставлять требуемый результат.
• Ошибка (Error) – изъян в проекте или неверное функционирование, вызывающее сбой одной или более конфигурационной единицы или ИТ-услуги. Ошибка, совершенная сотрудником, или нарушение процесса, которое влияет на конфигурационную единицу или ИТ-услугу, также являются ошибкой.
• Известная ошибка (Known Error) – проблема, для которой определены и документированы корневая причина и обходное решение.
• Релиз (Release) – совокупность аппаратных средств, программного обеспечения, документации, процессов или других компонентов, требующихся для внедрения одного или нескольких согласованных изменений в ИТ-услугах.
• Центр обслуживания пользователей (Service Desk) – система, предназначенная для обеспечения поддержки пользователей, быстрого и удобного поиска необходимых документов, запросов на обслуживание, инцидентов, проблем, запросов на изменение, релизов, задач.

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

При организации поддержки корпоративной системы нужно решить, какой временной формат будет использоваться: 24/7 или 8/5, то есть работы службы круглосуточно или только в рабочие часы.

Потребность режима 24/7 может быть вызвана наличием филиалов в различных часовых поясах или форматом работы предприятия, если там организована посменная работа без выходных. От нагрузки на службу поддержки зависит состав ее участников (посменная работа или специалисты из разных часовых поясов). Возможно, компании подойдет промежуточный вариант 12/5, когда у специалистов поддержки будет временной сдвиг прихода-ухода в офис, чтобы перекрыть 12-часовой диапазон в рабочие дни.

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

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

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

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

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

При обновлении 1С:ERP обработчики обновления делятся:

• на монопольные – выполняются последовательно, блокируют работу пользователей;
• фоновые – выполняются в несколько потоков (параллельно), работу пользователей не блокируют, но могут ограничивать доступ к необработанным документам или искажать данные в отчетах.

Обработка данных на многоядерных серверах в несколько потоков (например, 16 ядер сервера дают 16 потоков обработки) выполняется быстрее, практически с кратным числу потоков ускорением обработки, и в итоге фоновые обработчики выполняются за время самого медленного из них.

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

Если совсем не удается найти время для останова работы пользователей и обновления данных, можно использовать следующую последовательность действий:

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

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

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

Отправить