Диплом МВА на тему Совершенствование системы управление командой сопровождения критичной для бизнеса автоматизированной системы.

Содержание:

Введение. 3

1. Теоретические аспекты управления командой сопровождения
критичной для бизнеса автоматизированной системы.. 5

1.1. Общие представления о порядке и особенностях
сопровождения автоматизированной системы   5

1.2. Функционирование команды сопровождения
автоматизированной системы.. 7

1.3. Критерии оценки эффективности управления командой
сопровождения автоматизированной системы.. 11

2. Практические аспекты управления командой сопровождения
критичной для бизнеса автоматизированной системы на примере ПАО Сбербанк в
Екатеринбурге. 14

2.1. Общая характеристика деятельности ПАО Сбербанк в
Екатеринбурге. 14

2.2. Анализ существующей системы управление командой
сопровождения критичной для бизнеса автоматизированной системы.. 17

3. Возможности совершенствования системы управление командой
сопровождения критичной для бизнеса автоматизированной системы.. 21

3.1. Разработка рекомендаций по совершенствованию системы
управление командой сопровождения критичной для бизнеса автоматизированной
системы.. 21

3.2. Оценка эффективности экономической эффективности
предложенным мероприятий  21

3.3. Анализ управление рисками внедрения рекомендаций. 24

Заключение. 28

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

Приложения  36

Введение:

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

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

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

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

Исходя из актуальности
темы была определена цель исследования – сформулировать возможности
совершенствования системы управление командой сопровождения критичной для
бизнеса автоматизированной системы на примере ПАО Сбербанк города
Екатеринбурга.

Достижение цели
потребовало решения следующих задач:

—
дать общее представление о порядке и особенностях сопровождения
автоматизированной системы;

—
рассмотреть вопросы функционирования команды сопровождения автоматизированной
системы;

—
выявить критерии оценки эффективности управления командой сопровождения
автоматизированной системы;

—
дать общую характеристику деятельности ПАО Сбербанк в Екатеринбурге;

—
провести анализ существующей системы управление командой сопровождения
критичной для бизнеса автоматизированной системы;

—
разработать рекомендации по совершенствованию системы управление командой
сопровождения критичной для бизнеса автоматизированной системы;

—
оценить эффективность экономической эффективности предложенным мероприятий;

—
проанализировать управление рисками
внедрения рекомендаций. Объектом исследования
выступило ПАО Сбербанк города Екатеринбурга, а предметом — система управление
командой сопровождения критичной для бизнеса автоматизированной системы.

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

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

Цель и задачи
исследования определили структуру работы, которая представлена введением, тремя
главами, заключением и списком литературы. Во введении определены актуальность,
цель, задачи, объект и предмет исследования.

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

Заключение:

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

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

По результатам оценки
эффективности предложенных рекомендаций можно сделать вывод, что вложения в
данный проект окупятся и принесут дополнительный денежный поток.
Аргументировать результирующее значение ROI в 110,8%, несмотря на поправку на
риски, стоит упором инвестиционной кампании на управление взаимоотношениями с
клиентами, ведь главным мероприятием является внедрение CRM-системы
«bpm’online» и её интеграция с уже внедренной и функционирующей АСУ.

Фрагмент текста работы:

1.
Теоретические аспекты управления командой сопровождения критичной для бизнеса
автоматизированной системы

1.1.
Общие представления о порядке и особенностях сопровождения автоматизированной
системы Сопровождение всегда
признавалось одним из основных этапов жизненного цикла программного
обеспечения. Уже к середине 70-х годов было признано, что сопровождение – это
этап, занимающий более 50% затрат на разработку и внедрение программного
средства (ПС) [10].

От эффективности работ на
этапе поддержки и сопровождения зависит непрерывность бизнес-процессов и
сохранность корпоративной информации, необходимой для жизнедеятельности
компаний [3].

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

Итак, от того как будет
организован процесс сопровождения системы зависит эффективность её использования.

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

Второй вопрос – как будет
осуществляться поддержка? Перечень задач, условия и сроки оказания услуг
необходимо подробно описать в регламенте сопровождения. В качестве примера
можно использовать предлагаемые ITIL (IT Infrastructure Library) соглашения об
уровне сервиса SLA (Service Level Agreement), задающие параметры качества
предоставляемых бизнесу ИТ-услуг и позволяющие управлять ожиданиями
пользователей. Перечень основных разделов SLA [8]:

1. Определение предоставляемого сервиса,
стороны, вовлеченные в соглашение, и сроки действия соглашения.

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

3. Число и размещение пользователей и/или
оборудования, использующих данный сервис.

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

5. Описание процедуры запросов на изменение
системы.

6. Спецификации целевых уровней качества
сервиса, включая:

· среднюю доступность, выраженную как
среднее число сбоев на период предоставления сервиса;

· минимальную доступность для каждого
пользователя;

· среднее время отклика сервиса;

· максимальное время отклика для каждого
пользователя;

· среднюю пропускную способность;

· описания расчёта приведённых выше
показателей и частоты отчётов.

1. Описание платежей, связанных с
сервисом.

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

3. Процедура разрешения рассогласований,
связанных с предоставлением сервиса.

4. Процесс улучшения SLA.

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

Когда регламент
сопровождения определен, следует озадачиться подбором или созданием удобного
средства регистрации обращений пользователей, которое позволит организовать и
контролировать процесс обслуживания [3]. Даже самая простая система, в которой пользователь
может в заявке описать проблему и способ её воспроизведения, прикрепить для
наглядности скриншот (снимок экрана), позволяет оперативно поручать задачи
исполнителям, устанавливать приоритет каждой заявки, плановые сроки её
отработки и контролировать их. Добавив в эту систему описание способа решения
проблемы и полнотекстовый поиск, можно получить готовую базу знаний, которая
сэкономит время не только пользователям, но и самим специалистам поддержки. Так
как не нужно будет повторно (по уже задокументированным вопросам) тратить время
на выяснение, что это: баг (ошибка программиста); глюк (заблуждение
пользователя, неподдающиеся воспроизведению) или фича (недокументированная
возможность системы, неожиданная для самого разработчика) [6]. Анализируя количество и характер
обращений, можно выявлять проблемные места системы и «проблемных»
пользователей, которым необходимо повторное обучение, а также формулировать
требования на изменение АСУ, инициировать актуализацию пользовательских
инструкций и описания системы. Дополнительно по заявкам можно вести учет
трудозатрат и рассчитывать фактическую стоимость обслуживания.

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